Kas ir RMI pār IIOP?
RMI over IIOP (turpmāk tekstā - RMI-IIOP), ko kopīgi izstrādājuši IBM un Sun, ir jauna RMI (Remote Method Invocation) versija IIOP (interneta starp-ORB protokols), kas apvieno RMI vieglās programmēšanas funkcijas ar CORBA savietojamību. Šī jaunā RMI versija tika oficiāli izlaista jūnijā un bija brīvi pieejama Sun vietnē (informāciju par to, kur to var lejupielādēt, skatiet zemāk sadaļā Resursi). Saules atsauces ieviešana darbojas operētājsistēmās Windows 9x / NT un Solaris. Tas ir standarta paplašinājums, kas atbalsta gan JDK 1.1.6, gan Java 2 platformu.
RMI un CORBA ir neatkarīgi izstrādājuši kā izplatīto objektu programmēšanas modeļus. RMI, kas ir EJB un Jini tehnoloģiju pamats, tika ieviests kā Java balstīts, viegli lietojams programmēšanas modelis izplatītiem objektiem. CORBA (Common Object Request Broker Architecture), ko definējusi OMG (Object Management Group), ir plaši pazīstams izplatīto objektu programmēšanas modelis, kas atbalsta vairākas valodas. IIOP protokols savieno dažādu ražotāju CORBA produktus, nodrošinot to savstarpēju savietojamību. RMI-IIOP savā ziņā ir RMI un CORBA laulība.
Šajā rakstā mēs pieņemam, ka jūs jau esat iepazinies ar CORBA pamatiem. Ja jums nepieciešama papildu palīdzība, lai sasniegtu ātrumu, zemāk esošajā Resursu sadaļā ir noderīga saite.
Pirms RMI-IIOP
Apskatiet zemāk redzamo 1. attēlu. Telpa virs centrālās horizontālās līnijas attēlo RMI sākotnējo domēnu; apakšējais reģions pārstāv CORBA un IIOP pasauli. Šīs divas atsevišķās pasaules, kas attīstījušās patstāvīgi, vēsturiski nav spējušas sazināties savā starpā. Piemēram, RMI vietējais protokols JRMP (Java Remote Method Protocol) nevar izveidot savienojumu ar citiem protokoliem.
Ja vienīgā programmēšanas valoda, kas nepieciešama jaunajā projektā, ir Java, RMI un JRMP izmantošana - kombinācija, kas tiek dēvēta par RMI (JRMP) šī raksta atlikušajā daļā tradicionāli ir bijusi labākā izvēle. Atšķirībā no CORBA, kas prasa izmantot diezgan sarežģīto Interface Definition Language (IDL) valodu, RMI (JRMP) piedāvā Java programmētājiem vieglu programmēšanu. Savukārt CORBA ļauj programmēt sadalītos objektus dažādās platformās un dažādās programmēšanas valodās. Izstrādātājiem ir nepieciešama sadalīto objektu programmēšana ne tikai jauniem projektiem, bet arī mantoto programmatūras resursu izmantošanai. Protams, mantotā programmatūra vairumā gadījumu tiek programmēta citās valodās, nevis Java; šādās situācijās izstrādātājiem ir nepieciešama CORBA, nevis RMI (JRMP).
Tādējādi mums ir centrālā dilemma: RMI (JRMP) priekšrocība ir vienkārša programmēšana, savukārt CORBA nodrošina sadarbspēju starp vairākām programmēšanas valodām dažādās platformās. Diemžēl tradicionāli nav bijis iespējas izmantot šīs abas izcilās tehnoloģijas. To parāda diagramma 2. attēlā, kurā aplis apzīmē situāciju, kurā klients var izsaukt serveri, un X apzīmē gadījumu, kad tas nav iespējams.
Labākais no abām pasaulēm
Agrāk, uzsākot jaunu projektu, bija grūti izvēlēties starp RMI (JRMP) un CORBA. Ja atlasījāt RMI (JRMP), jūs viegli programmējat, taču zaudējāt savietojamību vairākās valodās. Ja izvēlējāties CORBA, jūs ieguvāt savietojamību, taču jums radās sarežģītāks programmēšanas uzdevums. Gan RMI (JRMP), gan CORBA lietotāji, noguruši no šī lēmuma pieņemšanas, vienā balsī ir teikuši: "Lūdzu, savienojiet abus."
Zemāk esošajā 3. attēlā augšējā sadaļa attēlo RMI (JRMP) modeli, vidējā daļa RMI-IIOP modeli un apakšējā daļa CORBA modeli. Bultiņa norāda situāciju, kurā klients var izsaukt serveri. RMI-IIOP pieder IIOP pasaulē zem horizontālās līnijas. Dīvaini var šķist diagonālās bultiņas, kas šķērso robežu starp JRMP pasauli un IIOP pasauli, kas nozīmē, ka RMI (JRMP) klients var izsaukt RMI-IIOP serveri un otrādi. Tas ir dabiski, ka lasītāji uzskata, ka šīs diagonālās bultiņas ir nepareizas - galu galā dažādi protokoli nekad nevar savstarpēji sarunāties, vai ne? Tomēr šīs bultiņas faktiski atrodas īstajā vietā. RMI-IIOP atbalsta abus JRMP un IIOP protokoli.
Servera bināro failu (t.i., klases failu), kas izveidots, izmantojot RMI-IIOP API, var eksportēt kā JRMP vai IIOP. Jums nav jāpārraksta Java avota kods vai jāpārkompilē, pārejot no JRMP uz IIOP vai otrādi. Palaižot, jums ir jāmaina tikai tādi parametri kā Java sistēmas rekvizīti. Varat arī noteikt izmantoto protokolu, norādot to Java avota kodā. Tāda pati elastība attiecas arī uz RMI-IIOP klienta kodu.
Divējāds eksports
Ir vēl viens svarīgs fakts, kas jāpatur prātā, lemjot par JRMP un IIOP protokoliem. Eksportējot RMI-IIOP objektu uz servera, jums nav obligāti jāizvēlas starp JRMP un IIOP. Ja jums ir nepieciešams viens servera objekts, lai atbalstītu gan JRMP, gan IIOP klientus, varat vienlaikus eksportēt savu RMI-IIOP objektu gan uz JRMP, gan IIOP. RMI-IIOP terminoloģijā to sauc duālais eksports.
Diagonālās bultiņas 3. attēlā ir iespējamas, jo RMI-IIOP API atbalsta gan JRMP, gan IIOP protokolus. Tas nozīmē, ka, nepārrakstot RMI (JRMP) objekta avota kodu, to var izsaukt jauns RMI-IIOP klients. Līdzīgi, nepārrakstot RMI (JRMP) klienta pirmkodu, jūs varat aizstāt RMI (JRMP) servera objektu ar jaunu RMI-IIOP objektu, kuru CORBA klients var arī izsaukt. Tādējādi RMI-IIOP saglabā esošos ieguldījumus RMI (JRMP) bināros failos, jo RMI-IIOP ar tiem var sazināties bez avota koda izmaiņām vai atkārtotas kompilēšanas.
Šī sadarbspēja ar RMI (JRMP) bija viens no RMI-IIOP dizaina principiem. RMI-IIOP dizaineri izvairījās no kārdinājuma aizstāt CORBA un RMI ar trešo programmēšanas modeli, jo tas būtu tikai sajaucis sadalīto objektu programmētājus un apgrūtinājis migrāciju no RMI (JRMP).
Savietojamība ar CORBA
Vēlreiz apskatiet 3. attēlu. Sadaļa zem horizontālās līnijas ir IIOP pasaule, kur RMI-IIOP klients izsauc CORBA serveri, bet CORBA klients izsauc RMI-IIOP serveri. Autors RMI-IIOP klients, mēs domājam klienta programmu, kuru ir uzrakstījis RMI programmētājs, kurš neko nezina par CORBA vai IDL. Tāpat a CORBA klients ir klienta programma, kuru ir uzrakstījis CORBA programmētājs, kurš nezina RMI. Saskarnes nodalīšana no ieviešanas ir vispāratzīta metode, kas ļauj programmētājiem piekļūt dažādiem resursiem, nezinot, kā šie resursi tiek īstenoti; ja tiek ievērots šis paņēmiens, gan RMI-IIOP, gan CORBA lietotāji var izmantot otra protokola pakalpojumus, ja viņiem ir piekļuve tā saskarnei. RMI Java saskarnes fails ir saskarne RMI-IIOP lietotājiem, savukārt IDL ir saskarne CORBA lietotājiem; sadarbspēja starp RMI-IIOP un CORBA 3. attēlā tiek panākta, nodrošinot katram lietotājam viņa paredzamo saskarni, vienlaikus paslēpjot faktisko ieviešanu.
Pēdējā detaļa, kas jāpaskaidro 3. attēlā, ir punktota bultiņa, kas norāda RMI-IIOP klientu, kas izsauc CORBA serveri. Kāpēc tikai šī bulta ir punktēta? RMI-IIOP klients nevar obligāti piekļūt visiem esošajiem CORBA objektiem. IDL definēto CORBA objektu semantika ir virsraksts no RMI-IIOP objektiem, tāpēc esoša CORBA objekta IDL ne vienmēr var kartēt RMI-IIOP Java saskarnē. Tikai tad, kad konkrēta CORBA objekta semantika sakrīt ar RMI-IIOP, RMI-IIOP klients var izsaukt CORBA objektu. Punktota bultiņa norāda savienojumu, kas dažreiz - bet ne vienmēr - ir iespējams.
Tomēr šeit nevajadzētu pārspīlēt nesaderību. Ar punktētu bultiņu norādītie ierobežojumi attiecas tikai uz darbībām ar esošajiem CORBA objektiem. Pieņemsim, ka jūs projektējat pilnīgi jaunu izplatītu objektu ar RMI-IIOP Java saskarni. Šajā gadījumā jūs varat automātiski ģenerēt atbilstošo IDL ar rmic rīks. No šī IDL faila jūs varat to ieviest kā CORBA objektu - piemēram, C ++. Šis C ++ objekts ir tīrs CORBA objekts, kuru var izsaukt CORBA klients, un bez ierobežojumiem var izsaukt arī RMI-IIOP klients. RMI-IIOP klientam šis C ++ CORBA objekts tiek parādīts kā tīrs RMI-IIOP objekts, jo to nosaka RMI-IIOP Java saskarne. Īsāk sakot, atšķirība starp CORBA objektu un RMI-IIOP objektu ir tikai ieviešanas jautājums. Tāpat, ja objekts tiek ieviests RMI-IIOP, objekts CORBA klientam tiek parādīts kā CORBA objekts, jo CORBA klients tam piekļūst, izmantojot savu IDL.
Zemāk 4. attēlā parādīta matrica, kurā apkopotas 3. attēlā redzamās bultiņas. Punktētais aplis nozīmē to pašu, ko 3. punktā redzamā punktētā bulta. klientiem. Tāpat, ieviešot savu klientu RMI-IIOP, varat runāt ar vislielāko serveru diapazonu, lai gan esošo CORBA objektu gadījumā ir daži ierobežojumi, kā norāda punktētais aplis.
RMI-IIOP dizaina politika
Bija divi galvenie priekšnoteikumi, kas veidoja RMI-IIOP protokola dizainu: RMI semantika bija jāatstāj pēc iespējas neskarta, un CORBA bija jāuzlabo, lai RMI semantiku varētu īstenot, izmantojot CORBA infrastruktūru. To bija vieglāk pateikt nekā izdarīt. Ja tiktu ieviests trešais programmēšanas modelis, tas tikai mulsinātu programmētājus. Lai izveidotu laimīgu RMI un CORBA laulību, bija nepieciešams panākt kompromisu starp šo laulības partneru atšķirīgo izcelsmi - ja abi partneri noraidītu jebkuru kompromisu, laulība nekur nenonāktu. Par laimi CORBA sabiedrība to atzina un pieņēma noteiktas izmaiņas, lai RMI-IIOP varētu kļūt par realitāti.
Divas galvenās izmaiņas, kuras CORBA pieņēma, bija Objekti pēc vērtības un Java – IDL kartēšana specifikācijas. Pirmais, kas jau ir pieejams RMI lietotājiem Java objektu sērijas veidā, ir CORBA specifikācija, kas paredzēta, lai citas valodas ieviestu līdzīgu iespēju. Pēdējā ir kartēšana, ko izmanto, lai pārveidotu RMI Java saskarnes CORBA IDL definīcijās, un to nedrīkst sajaukt ar IDL-Java kartēšanu, kas jau ir definēta CORBA 2.2. (Saites uz šīm divām jaunajām CORBA specifikācijām skatiet resursos.)
OMG jau oficiāli ir pieņēmusi abas CORBA 2.3 specifikācijas, taču CORBA ieviešanai nāksies panākt šo jauno versiju, pirms šeit aprakstītā jaunā CORBA un RMI laulība kļūst par plaši izplatītu realitāti. Piemēram, kompānija CORL 2.3, kas atbilst CORBA 2.3, ir pieejams Sun, lai to izmantotu kopā ar RMI-IIOP ORB (objektu pieprasījumu starpnieks), taču pašlaik tā ir agrīnas piekļuves versija, kas piemērota tikai vietņu savietojamības izpētei. CORBA un RMI-IIOP, nevis ražošanas vajadzībām. Turklāt Sun izplatītais IDL-Java kompilators, kas paredzēts lietošanai kopā ar Java IDL ORB Java 1.2, neatbilst CORBA 2.3, tāpēc to nevar izmantot, lai pārbaudītu sadarbspēju ar RMI-IIOP. Šī situācija tiks atrisināta tuvāko mēnešu laikā, kad CORBA pārdevēji ievieš jaunas savu produktu versijas, kas atbalsta CORBA 2.3. Piemēram, nākamajā Java 2 platformas Standard Edition izdevumā būs gan RMI-IIOP, gan ražošanas kvalitātes IDL-Java kompilators, kas atbalsta CORBA 2.3.
Izstrādes procedūra
Zemāk 5. attēlā parādītas gan RMI-IIOP serveru, gan klientu izstrādes procedūras. Jūs ievērosiet, ka tie ir gandrīz tādi paši kā RMI (JRMP). Tāpat kā RMI (JRMP), izplatītā objekta definīcija ir tā RMI Java saskarne (MyObject.java 5. attēlā). Atšķirība ir -iiop parametrs rmic sastādītājs. Šo opciju izmanto, lai izveidotu rmic ģenerēt celmus un kaklasaites, kas atbalsta IIOP protokolu. Bez šī -iiop opcija, rmic ģenerē kopu un skeletu JRMP protokolam. Lai gan RMI-IIOP izstrādes procedūra ir tuvu RMI (JRMP), izpildlaika vide ir atšķirīga, jo saziņa notiek caur CORBA 2.3 saderīgu ORB, saziņai starp serveriem un klientiem izmantojot IIOP.
Ja apsverat RMI (JRMP) koda pārveidošanu RMI-IIOP, jums jāapzinās, ka, palaižot IIOP, ir dažas ieviešanas atšķirības. CORBA neatbalsta sadalītu atkritumu savākšanu, kas izmanto skaidru iznīcināšanu un pastāvīgas objektu atsauces ar caurspīdīgu pasivāciju un aktivizēšanu. RMI reģistru aizstāj ar JNDI ar CosNaming vai LDAP pakalpojumu sniedzēju, un RMI aktivizēšanu aizstāj ar portatīvā objekta adapteri. Attālajām objektu atsaucēm jābūt novadītām, izmantojot programmatūru Šaurs() metodi tiešās Java valodas dalībnieku vietā. Citas RMI semantikas, piemēram, objektu serializācija, tiek pilnībā atbalstītas, izmantojot IIOP.
CORBA sadarbspējas procedūra
6. attēlā parādīts, kā panākt RMI-IIOP un CORBA savietojamību. Lai padarītu mūsu diskusiju vienkāršāku, ņemsim vērā divus šādas savietojamības aspektus: CORBA klients, izmantojot RMI-IIOP objektu, kas attēlots 6. attēla kreisākajā sadaļā, un RMI-IIOP klients, izmantojot CORBA objektu, kas attēlots labākajā malā. Attēla centrā ir kopīgi procesi, kas ļauj darboties abām savietojamības formām.
