Ohjelmointi

Kirjoita oma äitisi!

Äiti ymmärretään väärin, eikä MOM saa luottoa. Olet ehkä kuullut tämän aiemmin, mutta hajautettujen järjestelmien areenalla se on totta! Tämä johtuu siitä, että viestikeskeinen väliohjelmisto (MOM) ei ole perinteisesti nauttinut samalla hienostuneisuudella ja tuella kuin muut hajautettujen viestintäkehysten tekniikat.

Mutta ajat muuttuvat. Kehittyneiden ja vankkojen toimittajatarjonnan myötä kiinnostus MOM-järjestelmiä kohtaan kasvaa nopeasti. Hyvät MOM-toteutukset tarjoavat korkean tason sovellusliittymän, palvelun laadun takaamisen ja joukon palveluja, kuten turvallisuus, viestijonot ja hakemistotuki, jotka ovat välttämättömiä "teollisen vahvuuden" hajautetulle viestinnälle.

Hajautetut viestintäkehykset

Hajautetun viestintäkehyksen tarkoituksena on tarjota hyvä tapa hajautetun järjestelmän osille kommunikoida. Kohdekeskeiset kehykset suorittavat tämän tehtävän tarjoamalla hajautetuille esineille tapa viestiä toisilleen.

Eniten huomiota kiinnitetään hajautettuihin objektikeskeisiin kehyksiin, jotka mallintavat viestintää metodikutsuna. CORBA ja RMI ovat kaksi erinomaista esimerkkiä tämäntyyppisestä kehyksestä (katso Resurssit). Näitä järjestelmiä kutsutaan usein RPC-järjestelmiksi. Näiden järjestelmien taika on, että ne soittavat etäprosessi (tai menetelmä) puhelut näyttävät olevan paikallisia menettelypuheluja (LPC).

RPC: t on rakennettu asiakas / palvelin-mallin mukaan. Esimerkiksi CORBA-objekteja, jotka paljastavat etäobjektien kutsuttavat menetelmät, kutsutaan (ja ovat) palvelimiksi.

Esittelyssä MOM

Toisin kuin RPC, MOM: t eivät mallintaa viestejä menetelmäpuheluina; sen sijaan he mallintavat ne tapahtumina tapahtumien jakelujärjestelmässä. Asiakkaat lähettävät ja vastaanottavat tapahtumia tai "viestejä" MOM: n tarjoamien sovellusliittymien kautta. MOM voi esittää hakemistopalveluja, jotka antavat asiakkaiden etsiä toisen palvelimena toimivan sovelluksen, tai se voi tarjota monikäyttöisiä "kanavia", jotka antavat asiakasryhmän kommunikoida vertaisryhminä, tai se voi esittää molemmat vaihtoehdot.

Kaikki sovellukset kommunikoivat suoraan keskenään MOM: n avulla. Sovellusten luomilla viesteillä on merkitystä vain muille asiakkaille, koska MOM itse on vain viestireititin (ja joissakin tapauksissa myös viestijonojärjestelmä).

ÄITIT ovat kaikenlaisia ​​ja kokoja

Kaikilla MOM: illa on kaksi perusominaisuutta: ne mahdollistavat viestien välittämisen ja viestien välittäminen on estämätöntä. Näiden perusteiden lisäksi myyjät voivat toteuttaa minkä tahansa määrän erilaisia ​​rajapintoja ja palveluja.

Monet MOM: t tarjoavat julkaisu- ja tilausliittymän, jonka avulla sovellukset voivat julkaista ja vastaanottaa kiinnostuneita viestejä. Tämä käyttöliittymä voi olla kanavapohjainen järjestelmä tai yksinkertaisempi järjestelmä, jossa asiakas rekisteröi viestityypit. se on kiinnostunut vastaanottamaan.

Perusominaisuudet tarjoavat vain suoria viestejä, ei lisäpalveluja. Edistyneet MOM: t tarjoavat viestijonon ja taatun toimituksen sekä turvallisuuden, alustojen välisen tiedon järjestämisen, skaalautuvuuden ja muita etuja.

ÄITIT yhdellä silmäyksellä

Tässä on lyhyt ohje, joka auttaa sinua käsittelemään MOM: ia.

MOM-edut

  • Yksinkertainen: Asiakkaat julkaisevat ja tilaavat

    julkaisu-ja-tilaa on hyödyllinen korkean tason abstraktio siitä, mitä sovellusten on tehtävä kommunikoida.

  • Helppo: Ei monimutkaista asennusta

    MOM: t on helppo asentaa ja käyttää, toisin kuin monimutkaiset RPC-pohjaiset järjestelmät, kuten CORBA.

  • Yleinen: Samaa MOMia voidaan käyttää useille sovelluksille

    Koska mikä tahansa annettu MOM-järjestelmä on pohjimmiltaan vain yleinen sanomansiirto, sitä voidaan käyttää uudelleen eri sovelluksissa ilman ylimääräistä työtä.

  • Joustava: Kaikenlaiset viestit voidaan välittää

    Äiti voi välittää minkä tahansa viestin. Koska äiti ei ymmärrä viestejä, sillä ei ole väliä mitä ne ovat.

MOM: n haitat

  • Yleinen: Sovellusten on ymmärrettävä viestit

    Sovellusten asettaminen käyttämään viestejä menetelmäpuheluiden sijaan voi olla hankalaa, varsinkin jos sovellus luottaa siihen, että menetelmäpuhelut estetään.

  • Outo: Ei mallintaa menetelmäpuheluja

    Kehittäjillä, jotka eivät tunne viestejä, voi olla vaikeuksia selvittää, miten niitä voidaan käyttää tehokkaasti.

  • Asynkroninen: Viestit eivät ole estäviä

    Viestit ovat luonnollisesti estämättömiä. Tämä vaikeuttaa puheluiden estämistä tarvitsevien sovellusten kirjoittamista.

  • Liian yksinkertainen: Ei tietojen järjestämistä

    Jopa yksinkertaiset RPC-järjestelmät jakavat tiedot oikein. Yksinkertaiset MOM: t voivat vain lähettää viestejä, joissa tavut eivät ole järjestyksessä vastaanottimen kannalta.

  • Ei-standardi: Toimittajat ovat kaikkialla

    Toimittajan MOM-toteutukset tekevät kaiken ... eikä mitään.

    Varoitus Emptor

    on lause, joka on pidettävä mielessä, kun tarkastelet eri toimittajien tarjouksia.

Milloin äidit ovat sopivia?

  • Kun viestit, sovellusten on käytettävä viestejä
  • Kun ohjelmointihenkilöstö ei ole naimisissa asiakas / palvelin ja RPC-järjestelmien kanssa
  • Kun CORBA / RMI ja siihen liittyvät järjestelmät ovat liian monimutkaisia
  • Kun yksinkertaiset RPC-järjestelmät ovat liian alkeellisia

MOM: n suunnittelunäkökohdat

Nyt kun tausta on poissa tieltä, aloitetaan äitimme, Viestiväylä. Käytämme MOMia mahdollistamaan viestinnän hajautetun taulun asiakkaiden välillä. (Katso Resurssit-linkit tietotaulusovelluksen tietoihin, jota olemme työskennelleet viimeisten erien aikana.)

Viestiväylän ajo-ominaisuus on, että se tarjoaa kätevän korkean tason viestintärajapinnan sitä käyttäville sovellusobjekteille.

Koska kanavalla on merkitystä keskuspalveluna, jonka viestiväylän tulisi tarjota, liitäntä viestiväylään on Kanava luokassa. Asiakas käyttää Kanava luokka käyttää kaikkia viestiväylän korkean tason toimintoja tilaamisesta ja julkaisemisesta järjestelmän käytettävissä olevien kanavien luettelointiin.

Kanava luokka paljastaa luokan menetelmät, jotka vaikuttavat koko viestiväylään tai koskevat kaikkia kanavia. Jokainen kanavaesiintymä edustaa järjestelmässä yhtä kanavaa ja paljastaa kanavakohtaiset menetelmät.

Kaksi liitäntää, ChannelListener ja ChannelsUpdateListener, on järjestetty tilaamaan viestien vastaanottaminen kanavalla ja vastaavasti ilmoitusten vastaanottaminen kanavan lisäyksestä.

Alla oleva kuva kuvaa Message Bus -järjestelmän arkkitehtuuria.

Konepellin alle

Konepellin alla Message Bus -sovellus käyttää luokan menetelmiä ja tietorakenteita

Kanava

seurata kanavia. Kanavan kuuntelijat toteuttavat

ChannelListener

käyttöliittymä ja objektit, jotka haluavat saada päivityksiä kanavasta, lisää

ChannelsUpdateListener

käyttöliittymä. Rekisteröityjä kuuntelijaobjekteja kutsutaan takaisin

Kanava

aina kun tapahtuu jotain mielenkiintoista. Kaikki viestintä ulkomaailman kanssa tapahtuu liikennekohtaisella toteutuksella

MessageBus

käyttöliittymä, kuten

MessageBusSocketImpl

.

Jokainen MessageBus toteutus välittää viestit puhumalla vastaavalle viestin välittävälle palvelimelle, jota kutsutaan välittäjäksi, jaetun verkkoliikenteen, kuten pistorasioiden tai URL-osoitteiden / palvelinsovellusten, kautta. Välittäjä reitittää viestit kesken MessageBus tapauksia, joista kukin vastaa a Kanava luokassa.

Koska nämä kuljetuskohtaiset toteutukset toteuttavat kaikki MessageBus käyttöliittymässä, ne ovat keskenään vaihdettavissa. Esimerkiksi servlet-pohjainen MessageBus ja välittäjä voi käyttää Kanava pistorasioiden sijasta MessageBus ja välittäjä.

Viestibussimme on yksinkertainen kanaviin perustuva vertaisverkko-järjestelmä, joten se soveltuu käytettäväksi vertaisverkko-sovelluksessa, kuten yhteistyöjärjestelmässä.

Viestiväylän käyttäminen asiakassovelluksessa

Nämä vaiheet antavat asiakkaalle mahdollisuuden käyttää viestiväylää:

  1. Määritä instanssi MessageBus.

     Channel.setMessageBus (uusi MessageBusSocketImpl (BROKER_NAME, BROKER_PORT)); 

    Tässä puhelussa uusi MessageBus toteutus luodaan, välittäjä tunnistetaan rakentajan kutsun argumenteilla.

  2. Tilaa kanava.

     Channel textChannel = Channel.subscribe ("text_channel", tämä); 

    Tämä kutsu palauttaa kanavan esiintymän, joka vastaa kanavan nimen argumenttia. Jos kanavaa ei ole, se luodaan järjestelmään.

    Syöttäminen Tämä argumenttina tarkoittaa, että soittaja on itse a ChannelListener. Soittaja voi tilata paitsi itsensä myös minkä tahansa ChannelListener kanavalle tai mikä tahansa määrä kuuntelijoita yhdelle kanavalle.

  3. Julkaise viesti kanavalle.

     textChannel.publish (uusi merkkijono (myID + "sanoo Hei!")); 

    Viestin julkaiseminen on helppoa ja ei vaadi muuta kuin soittamista julkaista() valitulla kanavan esiintymällä. Huomaa, että viesti voi olla minkä tahansa tyyppinen objekti, kunhan muut kanavan asiakkaat ymmärtävät sen ja palvelimella on pääsy viestiluokkatiedostoihin (kuten Viestiväylän käyttäminen -osiossa on kuvattu)

Muita valinnaisia ​​vaiheita ovat:

  • Peruuta kuuntelijan kanavan tilaus.

     textChannel.unsubscribe (ChannelListener); 

    Tämä menetelmä peruuttaa nimetyn tilauksen ChannelListener kanavalta, mikä tarkoittaa, että kuuntelija ei saa uusia viestejä. Kuuntelijoiden tilaus tulisi lopettaa tällä tavalla, kun heitä ei enää tarvita.

  • Hanki luettelo kanavien nimistä.

     Luettelokanava.getChannelNames (); 

    Tämä menetelmä palauttaa kaikkien viestiväylällä käytettävissä olevien kanavien nimet.

  • Tilaa saadaksesi uusia kanavia.

     Channel.subscribeChannelsUpdate (ChannelsUpdateListener); 

    A ChannelsUpdateListener voi tilata päivityksiä, kun kanavat lisätään viestiväylään.

  • Lopeta uusien kanavien vastaanottaminen.

     Channel.unsubscribeChannelsUpdate (ChannelsUpdateListener); 

    A ChannelsUpdateListener voidaan peruuttaa kanavanlisäyspäivitykset. Kuuntelijoiden tilaus tulisi lopettaa tällä tavalla, kun heitä ei enää tarvita.

  • Lisää lisää kuuntelijoita kanavalle.

     textChannel.subscribe (ChannelListener); 

    Tämän menetelmän avulla soittaja voi tilata lisää kuuntelijoita kanavalle.

     Merkkijono textChannel.getName (); 

    Tämä menetelmä palauttaa tämän kanavan esiintymän nimen.

Käyttöliittymä ChannelListener

ChannelListener käyttöliittymän on oltava jokaisen objektin, joka haluaa päivittyä, kun viesti tulee tietylle kanavalle.

julkinen käyttöliittymä ChannelListener {public void messageReceived (kanavakanava, objektiviesti); } 

Useimmissa tapauksissa asiakas, joka pyytää a Kanava instanssi tilaa itsensä kanavalle ja toteuttaa tämän käyttöliittymän itse, mutta se ei ole välttämätöntä. JDK 1.1 -tapahtumasovittimien mukaisesti asiakas voi tilata toisen objektin kanavalle siten, että se kuluttaa kanavan luomia viestejä.

Itse asiassa yksi kuuntelijaobjekti voi tilata useita kanavia, jotka kutsuvat kuuntelijan viesti vastaanotettu() joka kerta, kun viesti tulee millä tahansa kanavalla. viesti vastaanotettu () menetelmäpuhelu tarjoaa pääsyn kanavalle, jolla viesti ilmestyi, sallien viesti vastaanotettu () erotella viestit lähtökanavan mukaan.

Käyttöliittymä ChannelsUpdateListener

ChannelsUpdateListener on toteutettava kaikilla esineillä, jotka haluavat päivittyä, kun kanava lisätään.

julkinen käyttöliittymä ChannelsUpdateListener {public void channelAdded (String name); } 

Luokka Kanava

Kanava luokka palvelee kahta tarkoitusta:

  • Se tarjoaa yksinkertaisen abstraktion käyttöliittymänä asiakkaalle Message Bus -palvelua käyttämällä
  • Se ylläpitää käytettävissä olevien kanavien globaalia tilaa ja välittää viestejä kanavilta MessageBus ja saa päivityksiä MessageBus toteutus

Kanava esiintymät luodaan ja tallennetaan Kanavastaattinen koodi. Viittaukset niihin välittyvät Channel.subscribe () asiakkaan pyynnöstä. Jokainen Kanava esiintymä on ainutlaatuinen JVM-prosessissa.

julkisen luokan kanava {

suojattu staattinen looginen väyläSet = false; suojattu staattinen MessageBus-väylä; suojatut staattiset Hashtable-kanavat = uusi Hashtable (); suojatut staattiset vektorikanavatUpdateListeners = new Vector ();

julkinen staattinen synkronoitu void setMessageBus (MessageBus mb) heittää IOException {if (! busSet) {bus = mb; bus.initBroker (); busSet = tosi; } else System.out.println ("MessageBusia ei voi asettaa useammin kuin kerran ajon aikana!"); }

julkinen staattinen merkkijono getBrokerName () {return bus.getBrokerName (); }

julkinen staattinen luettelo getChannelNames () {return channels.keys (); }

Nämä luokkamenetelmät sallivat MessageBus asetetaan kerran kullekin ajonajalle ja palautetaan väylä- ja kanavanimien tiedot.

 julkinen staattinen synkronoitu kanavatilaus (merkkijonon nimi, ChannelListener cl) heittää IOException {Channel ch; if (kanavat.sisältääAvain (nimi)) ch = (Kanava) kanavat.get (nimi); else {bus.addChannel (nimi); ch = uusi kanava (nimi); kanavat.put (nimi, ch); } ch.subscribe (cl); paluu ch; } 

Tämä luokka-menetelmä palauttaa kanavan nimen vastaavan kanavan esiintymän. Se luo kanavan ja soittaa MessageBus lisätä se järjestelmään, jos sitä ei vielä ole olemassa. Heti kun kanava on luotu, sen alkuperäinen kuuntelija rekisteröidään siihen.

// asiakkaiden kutsuu rekisteröimään ChannelsUpdateListener public static void subscribeChannelsUpdates (ChannelsUpdateListener cul) {channelsUpdateListeners.addElement (cul); }

// asiakkaiden kutsuu poistamaan kanavanUpdateListener public static void unsubscribeChannelsUpdates (ChannelsUpdateListener cul) {channelsUpdateListeners.removeElement (cul); }