Co je RMI přes IIOP?
RMI over IIOP (dále RMI-IIOP), vyvinutý společně IBM a Sunem, je nová verze RMI (Remote Method Invocation) pro IIOP (Internet Inter-ORB Protocol), která kombinuje snadné programovací funkce RMI s interoperabilitou CORBA. Tato nová verze RMI byla oficiálně vydána v červnu a byla volně dostupná na webu společnosti Sun (informace o tom, kde si ji můžete stáhnout, najdete níže v části Zdroje). Referenční implementace Sun běží na Windows 9x / NT a Solaris. Jedná se o standardní rozšíření, které podporuje JDK 1.1.6 i platformu Java 2.
RMI a CORBA se vyvinuly samostatně jako programovací modely distribuovaných objektů. RMI, základ technologie EJB a Jini, bylo představeno jako snadno použitelný programovací model založený na Javě pro distribuované objekty. CORBA (Common Object Request Broker Architecture), definovaná OMG (Object Management Group), je známý model programování distribuovaných objektů, který podporuje řadu jazyků. Protokol IIOP spojuje produkty CORBA od různých dodavatelů a zajišťuje jejich interoperabilitu. RMI-IIOP je v jistém smyslu manželstvím společností RMI a CORBA.
Pro účely tohoto článku předpokládáme, že jste již obeznámeni se základy CORBA. Pokud potřebujete další pomoc s rozběhem, v části Zdroje níže je užitečný odkaz.
Před RMI-IIOP
Podívejte se na obrázek 1 níže. Prostor nad střední vodorovnou čarou představuje původní doménu RMI; dolní region představuje svět CORBA a IIOP. Tyto dva samostatné světy, které se vyvinuly samostatně, nebyly historicky schopné vzájemně komunikovat. Například nativní protokol RMI, JRMP (Java Remote Method Protocol), se nemůže připojit k jiným protokolům.
Pokud jediným programovacím jazykem, který v novém projektu potřebujete, je Java, bude použití RMI a JRMP - kombinace označovaná jako RMI (JRMP) pro zbytek tohoto článku - je tradičně nejlepší volbou. Na rozdíl od CORBA, který vyžaduje použití poměrně komplikovaného rozhraní Language Definition Language (IDL), nabízí RMI (JRMP) pro milovníky Javy snadné programování. CORBA na druhé straně umožňuje programování distribuovaných objektů napříč různými platformami a různými programovacími jazyky. Vývojáři potřebují programování distribuovaných objektů nejen pro nové projekty, ale také pro využití starších softwarových prostředků. Samozřejmě, starší software je ve většině případů programován v jiných jazycích než Java; v takových situacích vývojáři potřebují CORBA, ne RMI (JRMP).
Máme tedy naše ústřední dilema: RMI (JRMP) má výhodu snadného programování, zatímco CORBA poskytuje interoperabilitu mezi více programovacími jazyky na různých platformách. Bohužel však tradičně neexistuje způsob, jak obě tyto vynikající technologie použít. To ukazuje graf na obrázku 2, ve kterém kruh znamená situaci, kdy může klient volat server, a X znamená případ, kdy to není možné
Nejlepší z obou světů
Při zahájení nového projektu bylo těžké vybrat si mezi RMI (JRMP) a CORBA. Pokud jste vybrali RMI (JRMP), máte snadné programování, ale ztratili jste interoperabilitu ve více jazycích. Pokud jste vybrali CORBA, získali jste interoperabilitu, ale narazili jste na náročnější programovací úlohu. Uživatelé RMI (JRMP) i CORBA, unavení tímto rozhodnutím, řekli jedním hlasem: „Prosím, spojte je.“
Na obrázku 3 níže představuje horní část model RMI (JRMP), střední část model RMI-IIOP a spodní část model CORBA. Šipka představuje situaci, ve které může klient volat server. RMI-IIOP patří do světa IIOP pod vodorovnou čáru. Co může vypadat divně, jsou úhlopříčné šipky, které překračují hranici mezi světem JRMP a světem IIOP, což znamená, že klient RMI (JRMP) může volat server RMI-IIOP a naopak. Je přirozené, že si čtenáři myslí, že tyto diagonální šipky jsou špatné - koneckonců, různé protokoly na sebe nikdy nemohou mluvit, že? Tyto šipky jsou však ve skutečnosti na správném místě. RMI-IIOP podporuje oba JRMP a IIOP protokoly.
Serverový binární soubor (tj. Soubor třídy) vytvořený pomocí rozhraní API RMI-IIOP lze exportovat jako JRMP nebo IIOP. Při změně z JRMP na IIOP nemusíte přepisovat jeho zdrojový kód Java ani jej znovu kompilovat nebo naopak. Při jeho spuštění potřebujete změnit pouze parametry, jako jsou vlastnosti systému Java. Alternativně můžete určit použitý protokol zadáním ve zdrojovém kódu Java. Stejná flexibilita platí pro klientský kód RMI-IIOP.
Duální export
Při rozhodování mezi protokoly JRMP a IIOP je třeba mít na paměti ještě jednu důležitou skutečnost. Při exportu objektu RMI-IIOP na server nemusíte nutně volit mezi JRMP a IIOP. Pokud potřebujete jeden objekt serveru pro podporu klientů JRMP i IIOP, můžete svůj objekt RMI-IIOP exportovat do JRMP i IIOP současně. V terminologii RMI-IIOP se tomu říká duální export.
Diagonální šipky na obrázku 3 jsou možné, protože rozhraní API RMI-IIOP podporují protokoly JRMP i IIOP. To znamená, že bez přepsání zdrojového kódu objektu RMI (JRMP) jej může volat nový klient RMI-IIOP. Podobně, bez přepisování zdrojového kódu klienta RMI (JRMP), můžete nahradit objekt serveru RMI (JRMP) novým objektem RMI-IIOP, který může také volat klient CORBA. RMI-IIOP tedy zachovává stávající investice do binárních souborů RMI (JRMP), protože RMI-IIOP s nimi může komunikovat bez jakýchkoli změn zdrojového kódu nebo rekompilace.
Tato interoperabilita s RMI (JRMP) byla jedním z konstrukčních principů RMI-IIOP. Návrháři RMI-IIOP se vyhnuli pokušení přemístit CORBA a RMI pomocí třetího programovacího modelu, protože by to jen zmátlo programátory distribuovaných objektů a migraci z RMI (JRMP) o to obtížnější.
Interoperabilita s CORBA
Podívejte se znovu na obrázek 3. Část pod vodorovnou čárou je svět IIOP, kde klient RMI-IIOP volá server CORBA a klient CORBA volá server RMI-IIOP. Podle Klient RMI-IIOP, máme na mysli klientský program, který napsal programátor RMI, který neví nic o CORBA nebo IDL. Podobně, a Klient CORBA je klientský program, který byl napsán programátorem CORBA neznalým RMI. Oddělení rozhraní od implementace je zavedená technika umožňující programátorům přístup k různým zdrojům, aniž by museli vědět, jak jsou tyto zdroje implementovány; při dodržení této techniky mohou uživatelé RMI-IIOP i CORBA využívat služeb druhého protokolu, pokud mohou získat přístup k jeho rozhraní. Soubor rozhraní RMI Java je rozhraní pro uživatele RMI-IIOP, zatímco IDL je rozhraní pro uživatele CORBA; interoperability mezi RMI-IIOP a CORBA na obrázku 3 je dosaženo poskytnutím každého uživatele jeho očekávaného rozhraní při zachování skryté implementace.
Poslední detail, který bude vysvětlen na obrázku 3, je tečkovaná šipka označující klienta RMI-IIOP volajícího server CORBA. Proč je tečkovaná pouze tato šipka? Klient RMI-IIOP nemůže nutně přistupovat ke všem existujícím objektům CORBA. Sémantika objektů CORBA definovaných v IDL je nadmnožinou objektů RMI-IIOP, a proto nelze IDL existujícího objektu CORBA vždy mapovat do rozhraní Java RMI-IIOP. Pouze když sémantika konkrétního objektu CORBA odpovídá sémantice RMI-IIOP, může klient RMI-IIOP volat objekt CORBA. Tečkovaná šipka označuje připojení, které je někdy - ale ne vždy - možné.
Inkompatibilita by zde však neměla být přeceňována. Omezení označená tečkovanou šipkou platí pouze při jednání s existujícími objekty CORBA. Předpokládejme, že navrhnete zcela nový distribuovaný objekt s rozhraním Java RMI-IIOP. V tomto případě můžete automaticky vygenerovat odpovídající IDL pomocí rmic nářadí. Z tohoto souboru IDL jej můžete implementovat jako objekt CORBA - například v C ++. Tento objekt C ++ je čistý objekt CORBA, který lze volat klientem CORBA a lze jej také bez omezení volat pomocí klienta RMI-IIOP. Pro klienta RMI-IIOP se tento objekt C ++ C ++ C ++ zobrazí jako čistý objekt RMI-IIOP, protože je definován rozhraním Java RMI-IIOP. Stručně řečeno, rozdíl mezi objektem CORBA a objektem RMI-IIOP je pouze otázkou implementace. Podobně, pokud je objekt implementován v RMI-IIOP, objeví se objekt jako objekt CORBA klientovi CORBA, protože klient CORBA k němu přistupuje prostřednictvím svého IDL.
Obrázek 4 níže ukazuje matici, která shrnuje šipky na obrázku 3. Tečkovaný kruh znamená to samé jako tečkovaná šipka na obrázku 3. Obrázek 4 ukazuje, že pokud implementujete svůj server v RMI-IIOP, máte nejširší výběr klienty. Podobně, pokud implementujete svého klienta v RMI-IIOP, můžete hovořit s největší škálou serverů, i když v případě existujících objektů CORBA existují určitá omezení, jak je naznačeno tečkovaným kruhem.
Zásady návrhu RMI-IIOP
Návrh protokolu RMI-IIOP formovaly dva hlavní předpoklady: sémantika RMI musela být ponechána co nejvíce neporušená a bylo třeba vylepšit CORBA, aby bylo možné sémantiku RMI implementovat pomocí infrastruktury CORBA. To se snadněji řeklo, než udělalo. Pokud by byl zaveden třetí programovací model, programátory by to jen zmátlo. K vytvoření šťastného manželství společností RMI a CORBA bylo nutné dosáhnout kompromisu mezi různým zázemím těchto manželských partnerů - pokud by oba partneři jakýkoli kompromis odmítli, manželství by se nikam nedostalo. Komunita CORBA to naštěstí uznala a přijala určité změny, aby se RMI-IIOP mohl stát realitou.
Dvě hlavní změny, které CORBA přijala, byly: Objekty podle hodnoty a Mapování Java na IDL Specifikace. První z nich, který je již uživatelům RMI k dispozici ve formě serializace objektů Java, je specifikací CORBA, která má umožnit implementaci podobných schopností v jiných jazycích. Posledně jmenované je mapování používané k převodu rozhraní RMI Java na definice CORBA IDL a nesmí být zaměňováno s mapováním IDL-to-Java již definovaným v CORBA 2.2. (Odkazy na tyto dvě nové specifikace CORBA najdete v Zdrojích.)
OMG již oficiálně přijal obě specifikace pro CORBA 2.3, ale implementace CORBA budou muset tuto novou verzi dohnat, než se nové manželství CORBA a RMI zde popsané stane rozšířenou realitou. Například kompilátor IDL-to-Java, který vyhovuje CORBA 2.3, je k dispozici od společnosti Sun pro použití ve spojení s RMI-IIOP ORB (broker požadavku na objekt), ale v současné době je to verze s předčasným přístupem vhodná pouze pro zkoumání interoperability CORBA a RMI-IIOP, nikoli pro produkční použití. Kromě toho kompilátor IDL-to-Java distribuovaný společností Sun pro použití s Java IDL ORB v prostředí Java 1.2 není v souladu s CORBA 2.3, takže jej nelze použít k testování interoperability s RMI-IIOP. Tato situace bude vyřešena během několika příštích měsíců, protože prodejci CORBA představí nové verze svých produktů, které podporují CORBA 2.3. Například příští vydání platformy Java 2 Standard Edition bude obsahovat jak RMI-IIOP, tak kompilátor IDL-to-Java v produkční kvalitě, který podporuje CORBA 2.3.
Postup vývoje
Obrázek 5 níže ukazuje vývojové postupy jak pro servery RMI-IIOP, tak pro klienty. Všimnete si, že jsou téměř stejné jako u RMI (JRMP). Stejně jako v RMI (JRMP) je definicí distribuovaného objektu jeho rozhraní RMI Java (MyObject.java na obrázku 5). Rozdíl je v -iiop parametr parametru rmic překladač. Tato možnost se používá k výrobě rmic generovat pahýly a kravaty, které podporují protokol IIOP. Bez toho -iiop volba, rmic generuje útržek a kostru protokolu JRMP. Ačkoli je vývojový postup pro RMI-IIOP blízký postupu pro RMI (JRMP), běhové prostředí se liší v tom, že komunikace probíhá prostřednictvím ORB kompatibilního s CORBA 2.3, s použitím IIOP pro komunikaci mezi servery a klienty.
Pokud uvažujete o převodu kódu RMI (JRMP) na RMI-IIOP, měli byste si být vědomi, že při běhu přes IIOP existují určité implementační rozdíly. Distribuovaný sběr odpadu není podporován CORBA, která používá explicitní destrukci a trvalé odkazy na objekty s transparentní pasivací a aktivací. Registr RMI je nahrazen JNDI znakem CosNaming nebo poskytovatel služeb LDAP a aktivace RMI je nahrazena adaptérem přenosného objektu. Vzdálené odkazy na objekty musí být pomocí programatiky skandovány úzký() místo přímého obsazení jazyka Java. Další sémantika RMI, například serializace objektů, jsou plně podporovány přes IIOP.
Postup interoperability CORBA
Obrázek 6 ukazuje, jak dosáhnout interoperability mezi RMI-IIOP a CORBA. Aby byla naše diskuse jednodušší, uvažujme o dvou aspektech takové interoperability: klientovi CORBA používajícímu objekt RMI-IIOP, který je znázorněn v levé části obrázku 6, a klientovi RMI-IIOP používajícímu objekt CORBA, který je zobrazen v pravé části. Ve středu obrázku jsou ty sdílené procesy, které umožňují fungování obou forem interoperability.
