Hvad er RMI over IIOP?
RMI over IIOP (RMI-IIOP i det følgende), udviklet i fællesskab af IBM og Sun, er en ny version af RMI (Remote Method Invocation) til IIOP (Internet Inter-ORB Protocol), der kombinerer RMIs lette programmeringsfunktioner med CORBAs interoperabilitet. Denne nye version af RMI blev officielt frigivet i juni og gjort frit tilgængelig fra Suns websted (se afsnittet Ressourcer nedenfor for information om, hvor du kan downloade det). Sun-referenceimplementeringen kører på Windows 9x / NT og Solaris. Det er en standardudvidelse, der understøtter både JDK 1.1.6 og Java 2-platformen.
RMI og CORBA har udviklet uafhængigt som distribuerede objekter programmeringsmodeller. RMI, et fundament for EJB og Jini-teknologier, blev introduceret som en Java-baseret, brugervenlig programmeringsmodel til distribuerede objekter. CORBA (Common Object Request Broker Architecture), defineret af OMG (Object Management Group), er en velkendt distribueret objekt-programmeringsmodel, der understøtter en række sprog. IIOP-protokollen forbinder CORBA-produkter fra forskellige leverandører og sikrer interoperabilitet blandt dem. RMI-IIOP er på en måde et ægteskab mellem RMI og CORBA.
Med henblik på denne artikel antager vi, at du allerede er fortrolig med det grundlæggende i CORBA. Hvis du har brug for yderligere hjælp til at komme op i fart, er der et nyttigt link i afsnittet Ressourcer nedenfor.
Før RMI-IIOP
Se figur 1 nedenfor. Rummet over den centrale vandrette linje repræsenterer det oprindelige domæne for RMI; den nedre region repræsenterer CORBA og IIOP-verdenen. Disse to separate verdener, der har udviklet sig uafhængigt, har historisk ikke været i stand til at kommunikere med hinanden. For eksempel kan RMIs indfødte protokol, JRMP (Java Remote Method Protocol), ikke oprette forbindelse til andre protokoller.
Hvis det eneste programmeringssprog, du har brug for i et nyt projekt, er Java, er brugen af RMI og JRMP - en kombination kaldet RMI (JRMP) resten af denne artikel - har traditionelt været det bedste valg. I modsætning til CORBA, som kræver brug af det ret komplicerede Interface Definition Language (IDL), tilbyder RMI (JRMP) nem programmering til Java-elskere. CORBA tillader derimod programmering af distribuerede objekter på tværs af forskellige platforme og forskellige programmeringssprog. Udviklere har brug for programmering af distribuerede objekter ikke kun til nye projekter, men også til at udnytte ældre softwareressourcer. Naturligvis er ældre software i de fleste tilfælde programmeret på andre sprog end Java; i sådanne situationer har udviklere brug for CORBA, ikke RMI (JRMP).
Således har vi vores centrale dilemma: RMI (JRMP) har fordelen ved nem programmering, mens CORBA giver interoperabilitet mellem flere programmeringssprog på tværs af forskellige platforme. Desværre har der dog ikke traditionelt været en måde at bruge begge disse fremragende teknologier på. Dette vises i diagrammet i figur 2, hvor en cirkel står for en situation, hvor en klient kan ringe til en server, og en X står for en sag, hvor dette ikke er muligt
Det bedste fra begge verdener
Det plejede at være vanskeligt at vælge mellem RMI (JRMP) og CORBA, når man startede et nyt projekt. Hvis du valgte RMI (JRMP), fik du nem programmering, men mistede interoperabilitet på tværs af flere sprog. Hvis du valgte CORBA, fik du interoperabilitet, men stod over for en mere skræmmende programmeringsopgave. Både RMI (JRMP) og CORBA-brugere, der er trætte af at tage denne beslutning, har sagt med én stemme: "Forbind venligst de to."
I figur 3 nedenfor repræsenterer det øverste afsnit RMI (JRMP) -modellen, det midterste afsnit RMI-IIOP-modellen og det nederste afsnit CORBA-modellen. En pil repræsenterer en situation, hvor en klient kan ringe til en server. RMI-IIOP hører hjemme i IIOP-verdenen under den vandrette linje. Hvad der kan se mærkeligt ud er de diagonale pile, der krydser grænsen mellem JRMP-verdenen og IIOP-verdenen, hvilket indebærer, at en RMI (JRMP) -klient kan ringe til en RMI-IIOP-server og omvendt. Det er naturligt for læsere at tro, at disse diagonale pile er forkerte - trods alt kan forskellige protokoller aldrig tale med hinanden, ikke? Imidlertid er disse pile faktisk på det rigtige sted. RMI-IIOP understøtter begge JRMP og IIOP-protokoller.
En server binær (dvs. en klasse fil) oprettet ved hjælp af RMI-IIOP API'er kan eksporteres som enten JRMP eller IIOP. Du behøver ikke omskrive sin Java-kildekode eller kompilere den igen, når du skifter fra JRMP til IIOP eller omvendt. Du skal kun ændre parametre, f.eks. Java-systemegenskaber, når du kører det. Alternativt kan du bestemme den anvendte protokol ved at angive den i Java-kildekoden. Den samme fleksibilitet gælder for RMI-IIOP-klientkode.
Dobbelt eksport
Der er endnu en vigtig kendsgerning at huske på, når man beslutter mellem JRMP og IIOP-protokollerne. Når du eksporterer et RMI-IIOP-objekt på din server, behøver du ikke nødvendigvis vælge mellem JRMP og IIOP. Hvis du har brug for et enkelt serverobjekt til at understøtte både JRMP- og IIOP-klienter, kan du eksportere dit RMI-IIOP-objekt til både JRMP og IIOP samtidigt. I RMI-IIOP-terminologi kaldes dette dobbelt eksport.
De diagonale pile i figur 3 er mulige, fordi RMI-IIOP API'er understøtter både JRMP- og IIOP-protokoller. Dette betyder, at det uden at omskrive kildekoden til et RMI (JRMP) objekt kan kaldes op af en ny RMI-IIOP-klient. Uden at omskrive kildekoden til en RMI (JRMP) -klient kan du ligeledes erstatte et RMI (JRMP) -serverobjekt med et nyt RMI-IIOP-objekt, som en CORBA-klient også kan kalde. Således bevarer RMI-IIOP eksisterende investeringer i RMI (JRMP) -binarier, fordi RMI-IIOP kan kommunikere med dem uden ændringer i kildekoden eller rekompilering.
Denne interoperabilitet med RMI (JRMP) var et af designprincipperne for RMI-IIOP. RMI-IIOP-designerne undgik fristelsen til at fortrænge CORBA og RMI med en tredje programmeringsmodel, da dette kun ville have forvirret distribuerede objekter programmører og gjort migrering fra RMI (JRMP) desto vanskeligere.
Interoperabilitet med CORBA
Se på figur 3 igen. Afsnittet under den vandrette linje er IIOP-verdenen, hvor en RMI-IIOP-klient kalder en CORBA-server, og en CORBA-klient kalder en RMI-IIOP-server. Af en RMI-IIOP klient, vi mener et klientprogram, der er skrevet af en RMI-programmør, der ikke ved noget om CORBA eller IDL. Ligeledes en CORBA-klient er et klientprogram, der er skrevet af en CORBA-programmør, der er uvidende om RMI. Adskillelse af grænseflade fra implementering er en veletableret teknik til at give programmører adgang til forskellige ressourcer uden at skulle vide, hvordan disse ressourcer implementeres; hvis denne teknik følges, kan brugere af både RMI-IIOP og CORBA bruge tjenesterne i den anden protokol, hvis de kan få adgang til dens grænseflade. En RMI Java-interfacefil er grænsefladen til RMI-IIOP-brugere, mens IDL er grænsefladen til CORBA-brugere; interoperabilitet mellem RMI-IIOP og CORBA i figur 3 opnås ved at give hver bruger sin forventede grænseflade, mens den faktiske implementering holdes skjult.
Den sidste detalje, der skal forklares i figur 3, er den stiplede pil, der indikerer en RMI-IIOP-klient, der kalder en CORBA-server. Hvorfor er kun denne pil stiplet? En RMI-IIOP-klient kan ikke nødvendigvis få adgang til alle eksisterende CORBA-objekter. Semantikken for CORBA-objekter defineret i IDL er et supersæt af RMI-IIOP-objekter, hvorfor et eksisterende CORBA-objekts IDL ikke altid kan kortlægges i en RMI-IIOP Java-grænseflade. Det er kun, når et bestemt CORBA-objekts semantik tilfældigvis svarer til dem fra RMI-IIOP, at en RMI-IIOP-klient kan kalde et CORBA-objekt. Den stiplede pil indikerer en forbindelse, der undertiden - men ikke altid - er mulig.
Uforeneligheden her bør dog ikke overvurderes. Begrænsningerne angivet med den stiplede pil gælder kun, når der behandles eksisterende CORBA-objekter. Antag at du designer et helt nyt distribueret objekt med en RMI-IIOP Java-grænseflade. I dette tilfælde kan du automatisk generere dets tilsvarende IDL med rmic værktøj. Fra denne IDL-fil kan du implementere den som et CORBA-objekt - for eksempel i C ++. Dette C ++ - objekt er et rent CORBA-objekt, der kan kaldes af en CORBA-klient og kan også kaldes af en RMI-IIOP-klient uden nogen begrænsninger. For RMI-IIOP-klienten vises dette C ++ CORBA-objekt som et rent RMI-IIOP-objekt, fordi det er defineret af en RMI-IIOP Java-grænseflade. Kort sagt, forskellen mellem et CORBA-objekt og et RMI-IIOP-objekt er kun en implementeringssag. Ligeledes, hvis et objekt er implementeret i RMI-IIOP, vises objektet som et CORBA-objekt til en CORBA-klient, fordi en CORBA-klient får adgang til det gennem dets IDL.
Figur 4 nedenfor viser matrixen, der opsummerer pilene i figur 3. Den stiplede cirkel betyder det samme som den stiplede pil i figur 3. Figur 4 viser, at hvis du implementerer din server i RMI-IIOP, har du det bredeste valg af kunder. Ligeledes, hvis du implementerer din klient i RMI-IIOP, kan du tale med det største udvalg af servere, selvom der er nogle begrænsninger i tilfælde af eksisterende CORBA-objekter, som angivet med den stiplede cirkel.
RMI-IIOP designpolitik
Der var to hovedforudsætninger, der formede designet af RMI-IIOP-protokollen: RMI-semantikken måtte efterlades så intakt som muligt, og CORBA skulle forbedres, så RMI-semantikken kunne implementeres ved hjælp af CORBA-infrastrukturen. Dette var lettere sagt end gjort. Hvis en tredje programmeringsmodel blev introduceret, ville det kun forvirre programmører. For at skabe et lykkeligt ægteskab mellem RMI og CORBA var det nødvendigt at nå et kompromis mellem de forskellige baggrunde for disse ægteskabspartnere - hvis begge partnere afviste ethvert kompromis, ville ægteskabet ikke komme nogen steder. Heldigvis anerkendte CORBA-samfundet dette og accepterede visse ændringer, så RMI-IIOP kunne blive en realitet.
De to store ændringer, som CORBA accepterede, var Objekter efter værdi og Java-til-IDL-kortlægning specifikationer. Den tidligere, der allerede er tilgængelig for RMI-brugere i form af Java-objektserialisering, er en CORBA-specifikation beregnet til at få andre sprog til at implementere en lignende kapacitet. Sidstnævnte er den kortlægning, der bruges til at konvertere RMI Java-grænseflader til CORBA IDL-definitioner og må ikke forveksles med den IDL-til-Java-kortlægning, der allerede er defineret i CORBA 2.2. (Se ressourcer for links til disse to nye CORBA-specifikationer.)
OMG har allerede officielt accepteret begge specifikationer for CORBA 2.3, men CORBA-implementeringer bliver nødt til at indhente denne nye version, før det nye ægteskab mellem CORBA og RMI, der er beskrevet her, bliver en udbredt virkelighed. For eksempel er en IDL-til-Java-kompilator, der overholder CORBA 2.3, tilgængelig fra Sun til brug i forbindelse med RMI-IIOP ORB (objektanmodningsmægler), men det er i øjeblikket en version med tidlig adgang, der kun er egnet til at undersøge interoperabiliteten mellem CORBA og RMI-IIOP og ikke til produktionsbrug. Desuden er IDL-til-Java-compileren distribueret af Sun til brug med Java IDL ORB i Java 1.2 ikke i overensstemmelse med CORBA 2.3, så den kan ikke bruges til at teste interoperabilitet med RMI-IIOP. Denne situation vil blive løst i løbet af de næste par måneder, da CORBA-leverandører introducerer nye versioner af deres produkter, der understøtter CORBA 2.3. For eksempel vil den næste udgave af Java 2-platformen Standard Edition omfatte både RMI-IIOP og en IDL-til-Java-compiler af produktionskvalitet, der understøtter CORBA 2.3.
Udviklingsprocedure
Figur 5 nedenfor viser udviklingsprocedurerne for både RMI-IIOP-servere og klienter. Du vil bemærke, at de er næsten de samme som RMI (JRMP). Ligesom i RMI (JRMP) er definitionen af et distribueret objekt dets RMI Java-interface (MyObject.java i figur 5). En forskel er -iiop parameter for rmic kompilator. Denne mulighed bruges til at lave rmic generere stubber og binde, der understøtter IIOP-protokollen. Uden dette -iiop mulighed, rmic genererer en stub og et skelet til JRMP-protokollen. Selvom udviklingsproceduren for RMI-IIOP er tæt på den for RMI (JRMP), er runtime-miljøet forskelligt, da kommunikation foretages via en CORBA 2.3-kompatibel ORB ved anvendelse af IIOP til kommunikation mellem servere og klienter.
Hvis du overvejer at konvertere RMI (JRMP) -kode til RMI-IIOP, skal du være opmærksom på, at der er nogle implementeringsforskelle, når du kører over IIOP. Distribueret affaldsindsamling understøttes ikke af CORBA, som bruger eksplicit ødelæggelse og vedvarende objektreferencer med gennemsigtig passivering og aktivering. RMI-registreringsdatabasen erstattes af JNDI med CosNaming eller LDAP-tjenesteudbyder, og RMI-aktivering erstattes af den bærbare objektadapter. Eksterne objektreferencer skal nedkastes ved hjælp af en programmatik smal() metode i stedet for et direkte Java-sprog cast. Anden RMI-semantik, såsom objektserialisering, understøttes fuldt ud over IIOP.
CORBA-interoperabilitetsprocedure
Figur 6 viser, hvordan man opnår interoperabilitet mellem RMI-IIOP og CORBA. For at gøre vores diskussion enklere, lad os overveje to aspekter af sådan interoperabilitet: en CORBA-klient, der bruger et RMI-IIOP-objekt, afbildet i afsnittet til venstre i figur 6, og en RMI-IIOP-klient, der bruger et CORBA-objekt, afbildet i det yderste afsnit. I midten af figuren er de delte processer, der tillader begge former for interoperabilitet at arbejde.
