Mikä on RMI yli IIOP: n?
IBM: n ja Sunin yhdessä kehittämä RMI over IIOP (jäljempänä RMI-IIOP) on uusi versio IIOP: lle (Internet Inter-ORB Protocol) tarkoitetusta RMI: stä (Remote Method Invocation), joka yhdistää RMI: n helpot ohjelmointiominaisuudet CORBA: n yhteentoimivuuteen. Tämä uusi RMI-versio julkaistiin virallisesti kesäkuussa ja se oli vapaasti saatavana Sunin verkkosivustolta (katso alla olevat resurssit-osio, josta voit ladata sen). Sun-viitetoteutus toimii Windows 9x / NT- ja Solaris-käyttöjärjestelmissä. Se on vakiolaajennus, joka tukee sekä JDK 1.1.6: ta että Java 2 -alustaa.
RMI ja CORBA ovat kehittäneet itsenäisesti hajautettujen objektien ohjelmointimalleja. RMI, EJB- ja Jini-teknologioiden perusta, esiteltiin Java-pohjaisena, helppokäyttöisenä ohjelmointimallina hajautetuille esineille. OMG: n (Object Management Group) määrittelemä CORBA (Common Object Request Broker Architecture) on tunnettu hajautettujen objektien ohjelmointimalli, joka tukee useita kieliä. IIOP-protokolla yhdistää CORBA-tuotteita eri toimittajilta varmistaen niiden välisen yhteentoimivuuden. RMI-IIOP on tavallaan RMI: n ja CORBA: n avioliitto.
Tässä artikkelissa oletetaan, että olet jo perehtynyt CORBA: n perusteisiin. Jos tarvitset lisäapua nopeuttamiseen, alla olevassa Resurssit-osiossa on hyödyllinen linkki.
Ennen RMI-IIOP: ta
Katso alla olevaa kuvaa 1. Keskimmäisen vaakasuoran viivan yläpuolella oleva tila edustaa RMI: n alkuperäistä aluetta; alempi alue edustaa CORBA: n ja IIOP: n maailmaa. Nämä kaksi erillistä maailmaa, jotka ovat itsenäisesti kehittyneet, eivät ole historiallisesti kyenneet kommunikoimaan keskenään. Esimerkiksi RMI: n natiiviprotokolla, JRMP (Java Remote Method Protocol), ei voi muodostaa yhteyttä muihin protokolliin.
Jos ainoa uudessa projektissa tarvitsemasi ohjelmointikieli on Java, RMI: n ja JRMP: n käyttö - yhdistelmä, johon viitataan RMI (JRMP) tämän artikkelin loppuosaan - on perinteisesti ollut paras valinta. Toisin kuin CORBA, joka vaatii melko monimutkaisen käyttöliittymän määrityskielen (IDL) käyttöä, RMI (JRMP) tarjoaa helpon ohjelmoinnin Java-ystäville. CORBA puolestaan mahdollistaa hajautettujen objektien ohjelmoinnin eri alustoilla ja eri ohjelmointikielillä. Kehittäjät tarvitsevat hajautettujen objektien ohjelmointia paitsi uusiin projekteihin myös vanhojen ohjelmistoresurssien hyödyntämiseen. Tietysti vanhat ohjelmistot on useimmissa tapauksissa ohjelmoitu muilla kielillä kuin Java; tällaisissa tilanteissa kehittäjät tarvitsevat CORBA: ta, ei RMI: tä (JRMP).
Siten meillä on keskeinen ongelma: RMI: llä (JRMP) on etu, että ohjelmointi on helppoa, kun taas CORBA tarjoaa yhteentoimivuuden useiden ohjelmointikielien välillä eri alustoilla. Valitettavasti molempia näitä erinomaisia tekniikoita ei kuitenkaan ole perinteisesti ollut tapana käyttää. Tämä näkyy kuvion 2 kaaviossa, jossa ympyrä tarkoittaa tilannetta, jossa asiakas voi soittaa palvelimelle, ja X tarkoittaa tapausta, jossa tämä ei ole mahdollista
Parhaat puolet eri vaihtoehdoista
Aiemmin oli vaikeaa valita RMI (JRMP) ja CORBA välillä aloittaessaan uuden projektin. Jos valitsit RMI: n (JRMP), ohjelmointi on helppoa, mutta menetit yhteentoimivuuden useilla kielillä. Jos valitsit CORBA: n, sinulla on yhteentoimivuus, mutta edessäsi on pelottavampi ohjelmointitehtävä. Sekä RMI: n (JRMP) että CORBA: n käyttäjät, jotka ovat kyllästyneet tekemään päätöksen, ovat sanoneet yhdellä äänellä: "Yhdistä nämä kaksi."
Alla olevassa kuvassa 3 yläosa edustaa RMI (JRMP) -mallia, keskiosa RMI-IIOP-mallia ja alaosa CORBA-mallia. Nuoli kuvaa tilannetta, jossa asiakas voi soittaa palvelimelle. RMI-IIOP kuuluu IIOP-maailmaan vaakasuoran viivan alapuolelle. Outo voi näyttää diagonaalisilta nuolilta, jotka ylittävät JRMP-maailman ja IIOP-maailman välisen rajan, mikä tarkoittaa, että RMI (JRMP) -asiakas voi soittaa RMI-IIOP-palvelimelle ja päinvastoin. Lukijoiden on luonnollista ajatella, että nämä diagonaaliset nuolet ovat väärät - loppujen lopuksi eri protokollat eivät voi koskaan puhua keskenään, eikö? Nämä nuolet ovat kuitenkin oikeassa paikassa. RMI-IIOP tukee molempia JRMP: tä ja IIOP-protokollat.
RMI-IIOP-sovellusliittymien avulla luotu palvelinbinaarinen (eli luokkatiedosto) voidaan viedä joko JRMP- tai IIOP-tiedostona. Sinun ei tarvitse kirjoittaa uudelleen Java-lähdekoodia tai kääntää sitä uudelleen, kun vaihdat JRMP: stä IIOP: ksi tai päinvastoin. Sinun on muutettava vain parametreja, kuten Java-järjestelmän ominaisuuksia, kun suoritat sitä. Vaihtoehtoisesti voit määrittää käytetyn protokollan määrittämällä sen Java-lähdekoodiin. Sama joustavuus koskee RMI-IIOP-asiakaskoodia.
Kaksoisvienti
On vielä yksi tärkeä seikka, joka on pidettävä mielessä, kun päätetään JRMP- ja IIOP-protokollien välillä. Kun viet RMI-IIOP-objektin palvelimellesi, sinun ei tarvitse välttämättä valita JRMP: n ja IIOP: n välillä. Jos tarvitset yhden palvelinobjektin tukemaan sekä JRMP- että IIOP-asiakkaita, voit viedä RMI-IIOP -objektisi samanaikaisesti sekä JRMP- että IIOP-tiedostoihin. RMI-IIOP-terminologiassa tätä kutsutaan kaksoisvienti.
Kuvion 3 diagonaaliset nuolet ovat mahdollisia, koska RMI-IIOP-sovellusliittymät tukevat sekä JRMP- että IIOP-protokollia. Tämä tarkoittaa, että uusi RMI-IIOP-asiakas voi kutsua sen kirjoittamatta uudelleen RMI (JRMP) -objektin lähdekoodia. Vastaavasti kirjoittamatta RMI (JRMP) -asiakasohjelman lähdekoodia, voit korvata RMI (JRMP) -palvelinobjektin uudella RMI-IIOP-objektilla, jolle CORBA-asiakas voi myös soittaa. Siten RMI-IIOP säilyttää nykyiset investoinnit RMI (JRMP) -binaareihin, koska RMI-IIOP voi kommunikoida heidän kanssaan ilman lähdekoodimuutoksia tai uudelleen kääntämistä.
Tämä yhteentoimivuus RMI: n (JRMP) kanssa oli yksi RMI-IIOP: n suunnitteluperiaatteista. RMI-IIOP-suunnittelijat välttivät houkutusta korvata CORBA ja RMI kolmannella ohjelmointimallilla, koska tämä olisi vain hämmentänyt hajautettujen objektien ohjelmoijia ja vaikeuttanut siirtymistä RMI: stä (JRMP).
Yhteentoimivuus CORBA: n kanssa
Katso kuvaa 3 uudelleen. Vaakasuoran viivan alapuolella on IIOP-maailma, jossa RMI-IIOP-asiakas kutsuu CORBA-palvelinta ja CORBA-asiakas kutsuu RMI-IIOP-palvelinta. Tekijä an RMI-IIOP-asiakas, tarkoitamme asiakasohjelmaa, jonka on kirjoittanut RMI-ohjelmoija, joka ei tiedä mitään CORBA: sta tai IDL: stä. Samoin a CORBA-asiakas on asiakasohjelma, jonka on kirjoittanut CORBA-ohjelmoija, joka ei tunne RMI: tä. Käyttöliittymän erottaminen toteutuksesta on vakiintunut tekniikka, jonka avulla ohjelmoijat voivat käyttää erilaisia resursseja tarvitsematta tietää, miten nämä resurssit toteutetaan. jos tätä tekniikkaa noudatetaan, sekä RMI-IIOP: n että CORBA: n käyttäjät voivat käyttää toisen protokollan palveluja, jos he pääsevät sen käyttöliittymään. RMI Java -liittymätiedosto on rajapinta RMI-IIOP-käyttäjille, kun taas IDL on käyttöliittymä CORBA-käyttäjille; RMI-IIOP: n ja CORBA: n yhteentoimivuus kuviossa 3 saavutetaan tarjoamalla jokaiselle käyttäjälle odotettu käyttöliittymä pitäen tosiasiallinen toteutus piilossa.
Viimeinen kuvassa 3 selitettävä yksityiskohta on katkoviiva, joka osoittaa RBA-IIOP-asiakkaan, joka kutsuu CORBA-palvelinta. Miksi vain tämä nuoli on pisteviiva? RMI-IIOP-asiakas ei välttämättä voi käyttää kaikkia olemassa olevia CORBA-objekteja. IDL: ssä määriteltyjen CORBA-objektien semantiikka on supersetti RMI-IIOP-objekteista, minkä vuoksi olemassa olevan CORBA-objektin IDL: ää ei voida aina yhdistää RMI-IIOP Java -käyttöliittymään. Vasta kun tietyn CORBA-objektin semantiikka sattuu vastaamaan RMI-IIOP: n semantiikkaa, RMI-IIOP-asiakas voi soittaa CORBA-objektille. Pisteviivalla varustettu nuoli osoittaa yhteyden, joka on joskus - mutta ei aina - mahdollista.
Yhteensopimattomuutta ei kuitenkaan pidä yliarvioida. Pisteviivalla merkitty nuoli koskee vain olemassa olevia CORBA-objekteja. Oletetaan, että suunnittelet upouuden jaetun objektin RMI-IIOP Java -käyttöliittymällä. Tässä tapauksessa voit luoda automaattisesti vastaavan IDL: n rmic työkalu. Tästä IDL-tiedostosta voit toteuttaa sen CORBA-objektina - esimerkiksi C ++: ssa. Tämä C ++ -objekti on puhdas CORBA-objekti, jonka CORBA-asiakas voi kutsua ja jota RMI-IIOP-asiakas voi kutsua myös rajoituksetta. RMI-IIOP-asiakkaalle tämä C ++ CORBA -objekti näkyy puhtaana RMI-IIOP-objektina, koska sen määrittelee RMI-IIOP Java -rajapinta. Lyhyesti sanottuna CORBA-objektin ja RMI-IIOP-objektin välinen ero on vain toteutusasia. Vastaavasti, jos objekti on toteutettu RMI-IIOP: ssa, objekti näkyy CORBA-objektina CORBA-asiakkaalle, koska CORBA-asiakas käyttää sitä IDL: n kautta.
Alla olevassa kuvassa 4 on matriisi, joka esittää yhteenvedon kuvion 3 nuolista. Pisteviiva tarkoittaa samaa kuin kuvion 3 katkoviiva. Kuva 4 osoittaa, että jos palvelimesi toteutetaan RMI-IIOP: ssa, sinulla on laajin valinta asiakkaita. Samoin, jos otat asiakkaasi käyttöön RMI-IIOP: ssa, voit puhua suurimman palvelinvalikoiman kanssa, vaikka olemassa oleville CORBA-objekteille on joitain rajoituksia, kuten katkoviiva osoittaa.
RMI-IIOP-suunnittelupolitiikka
RMI-IIOP -protokollan muotoilussa oli kaksi pääedellytystä: RMI-semantiikka oli jätettävä mahdollisimman ehjäksi ja CORBA: ta oli parannettava, jotta RMI-semantiikka voidaan toteuttaa CORBA-infrastruktuurin avulla. Tämä oli helpommin sanottu kuin tehty. Jos käyttöön otettaisiin kolmas ohjelmointimalli, se vain hämmentäisi ohjelmoijia. RMI: n ja CORBAn onnellisen avioliiton aikaansaamiseksi oli välttämätöntä päästä kompromissiin näiden aviopuolisoiden eri taustojen välillä - jos molemmat kumppanit hylkäävät kompromissin, avioliitto ei pääse mihinkään. Onneksi CORBA-yhteisö tunnusti tämän ja hyväksyi tietyt muutokset, jotta RMI-IIOP voisi tulla todellisuudeksi.
Kaksi suurta muutosta, jotka CORBA hyväksyi, olivat Objektit arvon mukaan ja Java-IDL-kartoitus tekniset tiedot. Edellinen, joka on jo RMI-käyttäjien saatavilla Java-objektien sarjallisuuden muodossa, on CORBA-määritys, jonka tarkoituksena on saada muut kielet toteuttamaan samanlainen ominaisuus. Jälkimmäinen on kartoitus, jota käytetään RMI Java -rajapintojen muuntamiseen CORBA IDL -määrittelyiksi, eikä sitä pidä sekoittaa IDBA-Java-kartoitukseen, joka on jo määritelty CORBA 2.2: ssa. (Katso linkit näihin kahteen uuteen CORBA-määritykseen Resursseista.)
OMG on jo virallisesti hyväksynyt molemmat CORBA 2.3: n spesifikaatiot, mutta CORBA: n on oltava kiinni uudesta versiosta ennen kuin tässä kuvatusta uudesta CORBA: n ja RMI: n avioliitosta tulee laajalle levinnyt todellisuus. Esimerkiksi CORBA 2.3: n mukainen IDL-Java-kääntäjä on saatavana Sunilta käytettäväksi yhdessä RMI-IIOP ORB: n (objektipyynnön välittäjä) kanssa, mutta se on tällä hetkellä varhaisen käyttöoikeuden versio, joka soveltuu vain CORBA ja RMI-IIOP, eikä tuotantokäyttöön. Lisäksi Sunin jakama IDL-Java-kääntäjä käytettäväksi Java 1.2: n Java IDL ORB: n kanssa ei ole CORBA 2.3: n mukainen, joten sitä ei voida käyttää testaamaan yhteentoimivuutta RMI-IIOP: n kanssa. Tämä tilanne ratkaistaan lähikuukausina, kun CORBA-toimittajat esittävät tuotteilleen uusia versioita, jotka tukevat CORBA 2.3: ta. Esimerkiksi seuraava Java 2 Platform -versio, Standard Edition, sisältää sekä RMI-IIOP: n että CORBA 2.3: ta tukevan tuotantolaatuisen IDL-Java-kääntäjän.
Kehitysmenettely
Alla olevassa kuvassa 5 on esitetty sekä RMI-IIOP-palvelinten että asiakkaiden kehitystavat. Huomaat, että ne ovat melkein samat kuin RMI: n (JRMP). Aivan kuten RMI: ssä (JRMP), hajautetun objektin määritelmä on sen RMI Java -käyttöliittymä (MyObject.java kuvassa 5). Ero on -iiop parametri rmic kääntäjä. Tätä vaihtoehtoa käytetään rmic luoda IIOP-protokollaa tukevat tynkä ja solmio. Ilman tätä -iiop vaihtoehto, rmic luo tynkä ja luuranko JRMP-protokollalle. Vaikka RMI-IIOP: n kehittämismenettely on lähellä RMI: n (JRMP) kehitystapaa, ajonaikaiset ympäristöt ovat erilaiset, koska viestintä tapahtuu CORBA 2.3 -yhteensopivan ORB: n kautta, käyttäen IIOP: ta palvelinten ja asiakkaiden väliseen viestintään.
Jos harkitset RMI (JRMP) -koodin muuntamista RMI-IIOP: ksi, sinun tulisi olla tietoinen siitä, että IIOP: n yli suoritettaessa on joitain toteutuseroja. CORBA ei tue jaettua roskien keräystä, joka käyttää nimenomaista tuhoamista ja pysyviä objektiviittauksia läpinäkyvällä passivoinnilla ja aktivoinnilla. RMI-rekisteri korvataan JNDI: llä CosNaming tai LDAP-palveluntarjoaja, ja RMI-aktivointi korvataan kannettavalla objektisovittimella. Etäobjektiviittaukset on vähennettävä ohjelmallisesti kapea() menetelmä suoran Java-kielen suoratoiston sijaan. Muut RMI-semantiikat, kuten objektien sarjallisuus, ovat täysin tuettuja IIOP: n kautta.
CORBA-yhteentoimivuusmenettely
Kuvassa 6 on esitetty, miten RMI-IIOP: n ja CORBA: n välillä voidaan saavuttaa yhteentoimivuus. Jotta keskustelumme olisi yksinkertaisempi, tarkastellaan kahta tällaisen yhteentoimivuuden näkökohtaa: CORBA-asiakas, joka käyttää RMI-IIOP-objektia, joka on esitetty kuvan 6 vasemmassa reunassa, ja RMI-IIOP-asiakas, joka käyttää CORBA-objektia, joka on kuvattu oikeanpuoleisimmassa osassa. Kuvion keskellä ovat ne jaetut prosessit, jotka mahdollistavat molempien yhteentoimivuuden muotojen toiminnan.
