Kaj je RMI prek IIOP?
RMI over IIOP (RMI-IIOP v nadaljevanju), ki sta ga skupaj razvila IBM in Sun, je nova različica RMI (Remote Method Invocation) za IIOP (Internet Inter-ORB Protocol), ki združuje enostavne programske funkcije RMI in interoperabilnost CORBE. Ta nova različica RMI je bila uradno izdana junija in je bila prosto dostopna na spletnem mestu Sun (za informacije o tem, kje jo lahko prenesete, glejte spodnji razdelek Viri). Referenčna izvedba Sun se izvaja v sistemih Windows 9x / NT in Solaris. Je standardna razširitev, ki podpira tako JDK 1.1.6 kot tudi platformo Java 2.
RMI in CORBA sta se neodvisno razvila kot model programiranja z razdeljenimi predmeti. RMI, temelj tehnologij EJB in Jini, je bil uveden kot programski model za porazdeljene predmete, ki je enostaven za uporabo na Javi. CORBA (Common Object Request Broker Architecture), ki jo definira OMG (Object Management Group), je dobro znan model programiranja z razdeljenimi objekti, ki podpira številne jezike. Protokol IIOP povezuje izdelke CORBA različnih ponudnikov in tako zagotavlja medsebojno delovanje med njimi. RMI-IIOP je v nekem smislu zakonska zveza RMI in CORBA.
Za namene tega članka predvidevamo, da že poznate osnove CORBE. Če potrebujete dodatno pomoč pri pospeševanju hitrosti, je v spodnjem razdelku Viri koristna povezava.
Pred RMI-IIOP
Oglejte si sliko 1 spodaj. Prostor nad osrednjo vodoravno črto predstavlja prvotno domeno RMI; spodnja regija predstavlja svet CORBE in IIOP. Ta dva ločena sveta, ki sta se razvila neodvisno, v preteklosti nista bila sposobna komunicirati med seboj. Izvorni protokol RMI, na primer JRMP (Java Remote Method Protocol), se ne more povezati z drugimi protokoli.
Če je edini programski jezik, ki ga potrebujete v novem projektu, Java, uporaba RMI in JRMP - kombinacija, imenovana RMI (JRMP) za preostanek tega članka - tradicionalno najboljša izbira. Za razliko od CORBE, ki zahteva uporabo precej zapletenega jezika vmesniške definicije (IDL), RMI (JRMP) ponuja enostavno programiranje za ljubitelje Java. CORBA pa omogoča programiranje porazdeljenih predmetov na različnih platformah in različnih programskih jezikih. Razvijalci potrebujejo programiranje porazdeljenih predmetov ne samo za nove projekte, temveč tudi za uporabo starejših programskih virov. Seveda je stara programska oprema v večini primerov programirana v jezikih, ki niso Java; v takih situacijah razvijalci potrebujejo CORBA in ne RMI (JRMP).
Tako imamo osrednjo dilemo: RMI (JRMP) ima prednost enostavnega programiranja, medtem ko CORBA zagotavlja interoperabilnost med več programskimi jeziki na različnih platformah. Žal pa tradicionalno ni bilo mogoče uporabiti obeh teh odličnih tehnologij. To prikazuje grafikon na sliki 2, v katerem krog pomeni situacijo, v kateri lahko odjemalec pokliče strežnik, X pa primer, v katerem to ni mogoče
Najboljše iz obeh svetov
Včasih je bilo pri izbiri novega projekta težko izbirati med RMI (JRMP) in CORBA. Če ste izbrali RMI (JRMP), imate enostavno programiranje, vendar ste izgubili interoperabilnost v več jezikih. Če ste izbrali CORBA, ste dobili interoperabilnost, vendar ste se soočali z bolj zastrašujočo programsko nalogo. Tako uporabniki RMI (JRMP) kot CORBA, ki so se utrujeni od te odločitve, so v en glas rekli: "Prosim, povežite oba."
Na sliki 3 spodaj zgornji del predstavlja model RMI (JRMP), srednji del model RMI-IIOP in spodnji del model CORBA. Puščica predstavlja situacijo, v kateri lahko odjemalec pokliče strežnik. RMI-IIOP spada v svet IIOP pod vodoravno črto. Nenavadno so lahko diagonalne puščice, ki prečkajo mejo med svetom JRMP in svetom IIOP, kar pomeni, da lahko odjemalec RMI (JRMP) pokliče strežnik RMI-IIOP in obratno. Za bralce je naravno, da mislijo, da so te diagonalne puščice napačne - navsezadnje se različni protokoli nikoli ne morejo pogovarjati, kajne? Vendar so te puščice dejansko na pravem mestu. RMI-IIOP podpira oba JRMP in Protokoli IIOP.
Binarni strežnik (tj. Datoteko razreda), ustvarjen z uporabo API-jev RMI-IIOP, lahko izvozite kot JRMP ali IIOP. Pri prehodu iz JRMP v IIOP ali obratno ni treba prepisovati izvorne kode Java ali jo prevajati. Pri zagonu morate spremeniti le parametre, kot so lastnosti sistema Java. Lahko pa določite uporabljeni protokol tako, da ga navedete v izvorni kodi Java. Enaka prilagodljivost velja za odjemalsko kodo RMI-IIOP.
Dvojni izvoz
Pri odločanju med protokoloma JRMP in IIOP je treba upoštevati še eno pomembno dejstvo. Ko izvozite objekt RMI-IIOP na strežnik, vam ni nujno, da izbirate med JRMP in IIOP. Če potrebujete en strežniški objekt za podporo odjemalcev JRMP in IIOP, lahko svoj objekt RMI-IIOP izvozite hkrati v JRMP in IIOP. V terminologiji RMI-IIOP se to imenuje dvojni izvoz.
Diagonalne puščice na sliki 3 so možne, ker API-ji RMI-IIOP podpirajo protokola JRMP in IIOP. To pomeni, da ga lahko novi odjemalec RMI-IIOP pokliče brez prepisovanja izvorne kode objekta RMI (JRMP). Podobno lahko brez prepisovanja izvorne kode odjemalca RMI (JRMP) nadomestite strežniški objekt RMI (JRMP) z novim objektom RMI-IIOP, ki ga lahko pokliče tudi odjemalec CORBA. Tako RMI-IIOP ohranja obstoječe naložbe v binarne datoteke RMI (JRMP), saj lahko RMI-IIOP komunicira z njimi brez kakršnih koli sprememb izvorne kode ali ponovne kompilacije.
Ta interoperabilnost z RMI (JRMP) je bila eno od načel načrtovanja RMI-IIOP. Oblikovalci RMI-IIOP so se izognili skušnjavi, da bi CORBA in RMI izrinili s tretjim programskim modelom, saj bi to samo zmedlo programerje z razdeljenimi predmeti in še bolj otežilo selitev iz RMI (JRMP).
Interoperabilnost s CORBA
Ponovno poglejte sliko 3. Odsek pod vodoravno črto je svet IIOP, kjer odjemalec RMI-IIOP pokliče strežnik CORBA, odjemalec CORBA pa strežnik RMI-IIOP. Avtor Odjemalec RMI-IIOP, mislimo na odjemalski program, ki ga je napisal programer RMI, ki ne ve ničesar o CORBA ali IDL. Prav tako a Stranka CORBA je odjemalski program, ki ga je napisal programer CORBA, ki ne pozna RMI. Ločevanje vmesnika od izvedbe je dobro uveljavljena tehnika, ki programerjem omogoča dostop do različnih virov, ne da bi morali vedeti, kako se ti viri izvajajo; če se ta tehnika upošteva, lahko uporabniki RMI-IIOP in CORBA uporabljajo storitve drugega protokola, če lahko dobijo dostop do njegovega vmesnika. Vmesniška datoteka RMI Java je vmesnik za uporabnike RMI-IIOP, medtem ko je IDL vmesnik za uporabnike CORBA; interoperabilnost med RMI-IIOP in CORBA na sliki 3 je dosežena tako, da se vsakemu uporabniku zagotovi njegov pričakovani vmesnik, pri čemer je dejanska izvedba skrita.
Zadnja podrobnost, ki jo je treba razložiti na sliki 3, je pikčasta puščica, ki kaže odjemalca RMI-IIOP, ki kliče strežnik CORBA. Zakaj je le ta puščica pikasta? Odjemalec RMI-IIOP ne more nujno dostopati do vseh obstoječih objektov CORBA. Semantika objektov CORBA, opredeljena v IDL, je nadmnožica objektov RMI-IIOP, zato IDL obstoječega objekta CORBA ni vedno mogoče preslikati v vmesnik Java RMI-IIOP. Šele ko se semantika določenega predmeta CORBA ujema s semantiko RMI-IIOP, lahko odjemalec RMI-IIOP pokliče objekt CORBA. Črtasta puščica označuje povezavo, ki je včasih - vendar ne vedno - mogoča.
Vendar pa tu nezdružljivosti ne smemo preceniti. Omejitve, označene s pikčasto puščico, veljajo samo pri obravnavi obstoječih predmetov CORBA. Denimo, da načrtujete povsem nov porazdeljeni objekt z vmesnikom Java RMI-IIOP. V tem primeru lahko z ID-jem samodejno ustvarite ustrezen IDL rmic orodje. Iz te datoteke IDL jo lahko implementirate kot objekt CORBA - na primer v C ++. Ta objekt C ++ je čisti objekt CORBA, ki ga lahko pokliče odjemalec CORBA in ga lahko brez omejitev pokliče tudi odjemalec RMI-IIOP. Za odjemalca RMI-IIOP je ta objekt C ++ CORBA prikazan kot čisti objekt RMI-IIOP, ker ga definira vmesnik Java RMI-IIOP. Skratka, razlika med objektom CORBA in objektom RMI-IIOP je le izvedbena zadeva. Če je objekt implementiran v RMI-IIOP, se odjemalcu CORBA prikaže kot objekt CORBA, ker odjemalec CORBA dostopa prek svojega IDL.
Slika 4 spodaj prikazuje matriko, ki povzema puščice na sliki 3. Črtast krog pomeni isto kot pikčasta puščica na sliki 3. Slika 4 kaže, da imate, če strežnik implementirate v RMI-IIOP, najširšo izbiro stranke. Podobno, če odjemalca implementirate v RMI-IIOP, se lahko pogovarjate z največjim številom strežnikov, čeprav obstajajo nekatere omejitve v primeru obstoječih objektov CORBA, kot kaže pikčasti krog.
Politika oblikovanja RMI-IIOP
Za zasnovo protokola RMI-IIOP sta bila oblikovana dva glavna predpogoja: semantiko RMI je bilo treba pustiti čim bolj nedotaknjeno, CORBA pa je bilo treba izboljšati, da se lahko semantika RMI izvaja z uporabo infrastrukture CORBA. To je bilo lažje reči kot narediti. Če bi bil uveden tretji model programiranja, bi programerje le zmedel. Za srečen zakon med RMI in CORBO je bilo treba doseči kompromis med različnimi okoliščinami teh zakonskih partnerjev - če bi oba partnerja zavrnila kakršen koli kompromis, zakon ne bi prišel nikamor. Na srečo je skupnost CORBA to prepoznala in sprejela nekatere spremembe, da je lahko RMI-IIOP postal resničnost.
Dve glavni spremembi, ki jo je sprejela CORBA, sta bili Predmeti po vrednosti in Preslikava Java-to-IDL specifikacije. Prva, ki je uporabnikom RMI že na voljo v obliki serializacije objektov Java, je specifikacija CORBA, katere namen je, da drugi jeziki uvedejo podobno zmožnost. Slednje je preslikava, ki se uporablja za pretvorbo vmesnikov Java RMI v definicije CORBA IDL in je ne smemo zamenjevati s preslikavo IDL v Java, ki je že definirana v CORBA 2.2. (Glejte Vire za povezave do teh dveh novih specifikacij CORBA.)
OMG je že uradno sprejel obe specifikaciji za CORBA 2.3, vendar bodo morale implementacije CORBE dohiteti to novo različico, preden bo novi zakon CORBA in RMI, ki je opisan tukaj, postal razširjena resničnost. Na primer, prevajalnik IDL-to-Java, ki ustreza CORBA 2.3, je na voljo pri podjetju Sun za uporabo skupaj z RMI-IIOP ORB (posrednik zahtev za objekte), vendar je trenutno različica za zgodnji dostop, primerna samo za raziskovanje interoperabilnosti CORBA in RMI-IIOP, in ne za proizvodno uporabo. Poleg tega prevajalnik IDL v Javo, ki ga je Sun distribuiral za uporabo z Java IDL ORB v Javi 1.2, ni v skladu s CORBA 2.3, zato ga ni mogoče uporabiti za preizkušanje interoperabilnosti z RMI-IIOP. To stanje se bo rešilo v naslednjih nekaj mesecih, ko bodo prodajalci CORBA predstavili nove različice svojih izdelkov, ki podpirajo CORBA 2.3. Na primer, naslednja izdaja platforme Java 2, Standard Edition, bo vključevala RMI-IIOP in kakovostni prevajalnik IDL-to-Java, ki podpira CORBA 2.3.
Razvojni postopek
Slika 5 spodaj prikazuje razvojne postopke za strežnike RMI-IIOP in odjemalce. Opazili boste, da so skoraj enaki kot pri RMI (JRMP). Tako kot v RMI (JRMP) je tudi definicija porazdeljenega predmeta njegov vmesnik Java RMI (MyObject.java na sliki 5). Razlika je v -iiop parameter parametra rmic prevajalnik. Ta možnost se uporablja za izdelavo rmic ustvari škrbine in kravato, ki podpirajo protokol IIOP. Brez tega -iiop možnost, rmic ustvari škrbino in okostje za protokol JRMP. Čeprav je razvojni postopek za RMI-IIOP podoben postopku za RMI (JRMP), je izvajalno okolje drugačno, saj komunikacija poteka prek ORB, skladnega s CORBA 2.3, z uporabo IIOP za komunikacijo med strežniki in odjemalci.
Če razmišljate o pretvorbi kode RMI (JRMP) v RMI-IIOP, se morate zavedati, da pri izvajanju IIOP obstajajo nekatere razlike v izvedbi. Porazdeljenega zbiranja smeti ne podpira CORBA, ki uporablja eksplicitno uničenje in trajne sklice na objekte s pregledno pasivizacijo in aktivacijo. Register RMI se nadomesti z JNDI z CosNaming ali ponudnika storitev LDAP, aktivacijo RMI pa nadomesti prenosni objektni vmesnik. Sklice na oddaljene predmete je treba znižati s programom ozek () namesto neposredne oddaje jezika Java. Druga semantika RMI, na primer serializacija objektov, je v celoti podprta prek IIOP.
Postopek interoperabilnosti CORBA
Slika 6 prikazuje, kako doseči interoperabilnost med RMI-IIOP in CORBA. Da bo naša razprava enostavnejša, razmislimo o dveh vidikih takšne interoperabilnosti: odjemalec CORBA, ki uporablja objekt RMI-IIOP, prikazan v skrajnem levem delu slike 6, in odjemalec RMI-IIOP, ki uporablja objekt CORBA, prikazan v skrajnem desnem delu. V središču slike so tisti skupni procesi, ki omogočajo delovanje obeh oblik interoperabilnosti.
