Hva er RMI over IIOP?
RMI over IIOP (RMI-IIOP heretter), utviklet av IBM og Sun, er en ny versjon av RMI (Remote Method Invocation) for IIOP (Internet Inter-ORB Protocol) som kombinerer RMIs enkle programmeringsfunksjoner med CORBAs interoperabilitet. Denne nye versjonen av RMI ble offisielt utgitt i juni og gjort fritt tilgjengelig fra Suns nettsted (se seksjonen Ressurser nedenfor for informasjon om hvor du kan laste ned den). Sun-referanseimplementeringen kjører på Windows 9x / NT og Solaris. Det er en standard utvidelse som støtter både JDK 1.1.6 og Java 2-plattformen.
RMI og CORBA har utviklet seg uavhengig som programmeringsmodeller for distribuerte objekter. RMI, et grunnlag for EJB- og Jini-teknologiene, ble introdusert som en Java-basert, brukervennlig programmeringsmodell for distribuerte objekter. CORBA (Common Object Request Broker Architecture), definert av OMG (Object Management Group), er en velkjent distribuert objekt-programmeringsmodell som støtter en rekke språk. IIOP-protokollen kobler sammen CORBA-produkter fra forskjellige leverandører, og sikrer interoperabilitet blant dem. RMI-IIOP er på sett og vis et ekteskap mellom RMI og CORBA.
I forbindelse med denne artikkelen antar vi at du allerede er kjent med det grunnleggende i CORBA. Hvis du trenger ytterligere hjelp til å komme opp i fart, er det en nyttig lenke i Ressurser-delen nedenfor.
Før RMI-IIOP
Se på figur 1 nedenfor. Rommet over den sentrale horisontale linjen representerer det originale domenet til RMI; den nedre regionen representerer CORBA og IIOP-verdenen. Disse to separate verdenene, som har utviklet seg uavhengig, har ikke historisk vært i stand til å kommunisere med hverandre. For eksempel kan RMIs innfødte protokoll, JRMP (Java Remote Method Protocol), ikke koble til andre protokoller.
Hvis det eneste programmeringsspråket du trenger i et nytt prosjekt, er Java, bruk av RMI og JRMP - en kombinasjon referert til som RMI (JRMP) for resten av denne artikkelen - har tradisjonelt vært det beste valget. I motsetning til CORBA, som krever bruk av det ganske kompliserte Interface Definition Language (IDL), tilbyr RMI (JRMP) enkel programmering for Java-elskere. CORBA tillater derimot programmering av distribuerte objekter på tvers av forskjellige plattformer og forskjellige programmeringsspråk. Utviklere trenger programmering av distribuerte objekter ikke bare for nye prosjekter, men også for å bruke eldre programvareressurser. Naturligvis er eldre programvare i de fleste tilfeller programmert på andre språk enn Java; i slike situasjoner trenger utviklere CORBA, ikke RMI (JRMP).
Dermed har vi vårt sentrale dilemma: RMI (JRMP) har fordelen av enkel programmering, mens CORBA gir interoperabilitet mellom flere programmeringsspråk på tvers av forskjellige plattformer. Dessverre har det imidlertid ikke tradisjonelt vært en måte å bruke begge disse utmerkede teknologiene på. Dette vises i diagrammet i figur 2, der en sirkel står for en situasjon der en klient kan ringe en server, og en X står for et tilfelle der dette ikke er mulig
Det beste fra begge verdenene
Det pleide å være vanskelig å velge mellom RMI (JRMP) og CORBA når man startet et nytt prosjekt. Hvis du valgte RMI (JRMP), fikk du enkel programmering, men mistet interoperabilitet på flere språk. Hvis du valgte CORBA, fikk du interoperabilitet, men møtte en mer skremmende programmeringsoppgave. Både RMI (JRMP) og CORBA-brukere, lei av å ta denne avgjørelsen, har sagt med én stemme: "Vennligst koble de to."
I figur 3 nedenfor representerer den øverste delen RMI (JRMP) -modellen, den midterste delen RMI-IIOP-modellen og den nedre delen CORBA-modellen. En pil representerer en situasjon der en klient kan ringe en server. RMI-IIOP hører hjemme i IIOP-verdenen under den horisontale linjen. Det som kan se rart ut er de diagonale pilene som krysser grensen mellom JRMP-verdenen og IIOP-verdenen, noe som innebærer at en RMI (JRMP) -klient kan ringe en RMI-IIOP-server, og omvendt. Det er naturlig for leserne å tro at disse diagonale pilene er gale - tross alt kan forskjellige protokoller aldri snakke med hverandre, ikke sant? Imidlertid er disse pilene faktisk på rett sted. RMI-IIOP støtter begge JRMP og IIOP-protokoller.
En server binær (dvs. en klassefil) opprettet ved bruk av RMI-IIOP APIer kan eksporteres som JRMP eller IIOP. Du trenger ikke å omskrive Java-kildekoden, eller kompilere den på nytt når du bytter fra JRMP til IIOP, eller omvendt. Du trenger bare å endre parametere som Java-systemegenskaper når du kjører den. Alternativt kan du bestemme protokollen som brukes ved å spesifisere den i Java-kildekoden. Den samme fleksibiliteten gjelder RMI-IIOP klientkode.
Dobbel eksport
Det er et viktig faktum å huske på når du velger mellom JRMP og IIOP-protokollene. Når du eksporterer et RMI-IIOP-objekt på serveren din, trenger du ikke nødvendigvis å velge mellom JRMP og IIOP. Hvis du trenger et enkelt serverobjekt for å støtte både JRMP- og IIOP-klienter, kan du eksportere RMI-IIOP-objektet til både JRMP og IIOP samtidig. I RMI-IIOP terminologi kalles dette dobbel eksport.
De diagonale pilene i figur 3 er mulige fordi RMI-IIOP APIer støtter både JRMP og IIOP-protokoller. Dette betyr at, uten å omskrive kildekoden til et RMI (JRMP) -objekt, kan det ringes opp av en ny RMI-IIOP-klient. Uten å omskrive kildekoden til en RMI (JRMP) klient, kan du på samme måte erstatte et RMI (JRMP) serverobjekt med et nytt RMI-IIOP-objekt som en CORBA-klient også kan ringe. Dermed bevarer RMI-IIOP eksisterende investering i RMI (JRMP) binærfiler, fordi RMI-IIOP kan kommunisere med dem uten endringer i kildekoden eller rekompilering.
Denne interoperabiliteten med RMI (JRMP) var et av designprinsippene til RMI-IIOP. RMI-IIOP-designerne unngikk fristelsen til å fortrenge CORBA og RMI med en tredje programmeringsmodell, siden dette bare ville ha forvirret programmerere av distribuerte objekter og gjort migrering fra RMI (JRMP) desto vanskeligere.
Interoperabilitet med CORBA
Se på figur 3 igjen. Avsnittet under den horisontale linjen er IIOP-verdenen, der en RMI-IIOP-klient kaller en CORBA-server, og en CORBA-klient kaller en RMI-IIOP-server. Av en RMI-IIOP-klient, vi mener et klientprogram som ble skrevet av en RMI-programmerer som ikke vet noe om CORBA eller IDL. Likeledes a CORBA-klient er et klientprogram som ble skrevet av en CORBA-programmerer som er uvitende om RMI. Separasjon av grensesnitt fra implementering er en veletablert teknikk for å la programmerere få tilgang til forskjellige ressurser uten å måtte vite hvordan disse ressursene implementeres; hvis denne teknikken følges, kan brukere av både RMI-IIOP og CORBA bruke tjenestene til den andre protokollen, hvis de kan få tilgang til grensesnittet. En RMI Java-grensesnittfil er grensesnittet til RMI-IIOP-brukere, mens IDL er grensesnittet for CORBA-brukere; interoperabilitet mellom RMI-IIOP og CORBA i figur 3 oppnås ved å gi hver bruker sitt forventede grensesnitt, samtidig som den faktiske implementeringen blir skjult.
Den siste detalj som skal forklares i figur 3 er den stiplede pilen som indikerer en RMI-IIOP-klient som kaller en CORBA-server. Hvorfor er bare denne pilen stiplet? En RMI-IIOP-klient kan ikke nødvendigvis få tilgang til alle eksisterende CORBA-objekter. Semantikken til CORBA-objekter definert i IDL er et supersett av RMI-IIOP-objekter, og det er grunnen til at et eksisterende CORBA-objekts IDL ikke alltid kan kartlegges til et RMI-IIOP Java-grensesnitt. Det er bare når et bestemt CORBA-objekts semantikk tilfeldigvis samsvarer med det fra RMI-IIOP, at en RMI-IIOP-klient kan kalle et CORBA-objekt. Den stiplede pilen indikerer en forbindelse som noen ganger - men ikke alltid - er mulig.
Imidlertid bør inkompatibiliteten her ikke overvurderes. Restriksjonene som er angitt med den stiplede pilen, gjelder bare når du arbeider med eksisterende CORBA-objekter. Anta at du designer et splitter nytt distribuert objekt med et RMI-IIOP Java-grensesnitt. I dette tilfellet kan du automatisk generere sin tilsvarende IDL med rmic verktøy. Fra denne IDL-filen kan du implementere den som et CORBA-objekt - for eksempel i C ++. Dette C ++ -objektet er et rent CORBA-objekt som kan ringes av en CORBA-klient og kan også kalles av en RMI-IIOP-klient uten noen begrensninger. For RMI-IIOP-klienten vises dette C ++ CORBA-objektet som et rent RMI-IIOP-objekt fordi det er definert av et RMI-IIOP Java-grensesnitt. Kort fortalt er forskjellen mellom et CORBA-objekt og et RMI-IIOP-objekt bare en implementeringssak. På samme måte, hvis et objekt er implementert i RMI-IIOP, vises objektet som et CORBA-objekt for en CORBA-klient fordi en CORBA-klient får tilgang til det gjennom IDL-en.
Figur 4 nedenfor viser matrisen som oppsummerer pilene i figur 3. Den stiplede sirkelen betyr det samme som den stiplede pilen i figur 3. Figur 4 viser at hvis du implementerer serveren din i RMI-IIOP, har du det bredeste utvalget av klienter. På samme måte, hvis du implementerer klienten din i RMI-IIOP, kan du snakke med det største utvalget av servere, selv om det er noen begrensninger når det gjelder eksisterende CORBA-objekter, som angitt av den prikkede sirkelen.
RMI-IIOP designpolitikk
Det var to hovedforutsetninger som formet utformingen av RMI-IIOP-protokollen: RMI-semantikken måtte være så intakt som mulig, og CORBA måtte forbedres slik at RMI-semantikk kunne implementeres ved bruk av CORBA-infrastrukturen. Dette var lettere sagt enn gjort. Hvis en tredje programmeringsmodell ble introdusert, ville den bare forvirre programmerere. For å produsere et lykkelig ekteskap mellom RMI og CORBA, var det nødvendig å komme til et kompromiss mellom de forskjellige bakgrunnene til disse ekteskapspartnerne - hvis begge partnere avviste noe kompromiss, ville ekteskapet komme ingen vei. Heldigvis anerkjente CORBA-samfunnet dette og aksepterte visse endringer slik at RMI-IIOP kunne bli en realitet.
De to store endringene CORBA aksepterte var Objekter etter verdi og Java-til-IDL-kartlegging spesifikasjoner. Den tidligere, som allerede er tilgjengelig for RMI-brukere i form av Java-objektserialisering, er en CORBA-spesifikasjon ment for å få andre språk til å implementere en lignende mulighet. Sistnevnte er kartleggingen som brukes til å konvertere RMI Java-grensesnitt til CORBA IDL-definisjoner, og må ikke forveksles med IDL-til-Java-kartleggingen som allerede er definert i CORBA 2.2. (Se Ressurser for lenker til disse to nye CORBA-spesifikasjonene.)
OMG har allerede offisielt akseptert begge spesifikasjonene for CORBA 2.3, men CORBA-implementeringer må innhente denne nye versjonen før det nye ekteskapet til CORBA og RMI som er beskrevet her, blir en utbredt virkelighet. For eksempel er en IDL-til-Java-kompilator som er i samsvar med CORBA 2.3 tilgjengelig fra Sun for bruk i forbindelse med RMI-IIOP ORB (objektforespørselsmegler), men den er for øyeblikket en tidlig tilgangsversjon som bare er egnet for å utforske interoperabilitet CORBA og RMI-IIOP, og ikke for produksjonsbruk. Videre er ikke IDL-til-Java-kompilatoren distribuert av Sun for bruk med Java IDL ORB i Java 1.2 ikke i samsvar med CORBA 2.3, så den kan ikke brukes til å teste interoperabilitet med RMI-IIOP. Denne situasjonen vil bli løst de neste månedene når CORBA-leverandører introduserer nye versjoner av sine produkter som støtter CORBA 2.3. For eksempel vil neste utgave av Java 2-plattformen Standard Edition inneholde både RMI-IIOP og en IDL-til-Java-kompilator av produksjonskvalitet som støtter CORBA 2.3.
Utviklingsprosedyre
Figur 5 nedenfor viser utviklingsprosedyrene for både RMI-IIOP-servere og klienter. Du vil legge merke til at de er nesten de samme som RMI (JRMP). Akkurat som i RMI (JRMP) er definisjonen av et distribuert objekt RMI Java-grensesnittet (MyObject.java i figur 5). En forskjell er -iiop parameteren til rmic kompilator. Dette alternativet brukes til å lage rmic generere stubber og slips som støtter IIOP-protokollen. Uten dette -iiop alternativ, rmic genererer en stubbe og et skjelett for JRMP-protokollen. Selv om utviklingsprosedyren for RMI-IIOP er nær den for RMI (JRMP), er kjøretidsmiljøet annerledes ved at kommunikasjon er laget gjennom en CORBA 2.3-kompatibel ORB, ved bruk av IIOP for kommunikasjon mellom servere og klienter.
Hvis du vurderer å konvertere RMI (JRMP) -kode til RMI-IIOP, bør du være oppmerksom på at det er noen implementeringsforskjeller når du kjører over IIOP. Distribuert søppelinnsamling støttes ikke av CORBA, som bruker eksplisitt ødeleggelse og vedvarende objektreferanser med gjennomsiktig passivering og aktivering. RMI-registeret erstattes av JNDI med CosNaming eller LDAP-tjenesteleverandør, og RMI-aktivering erstattes av den bærbare objektadapteren. Eksterne objektreferanser må nedkastes ved hjelp av et program smal() metode i stedet for en direkte Java-rollebesetning Annen RMI-semantikk, for eksempel objektserialisering, støttes fullt ut over IIOP.
CORBA interoperabilitetsprosedyre
Figur 6 viser hvordan man oppnår interoperabilitet mellom RMI-IIOP og CORBA. For å gjøre diskusjonen enklere, la oss se på to aspekter av slik interoperabilitet: en CORBA-klient som bruker et RMI-IIOP-objekt, avbildet i den venstre delen av figur 6, og en RMI-IIOP-klient som bruker et CORBA-objekt, avbildet i den høyre delen. I midten av figuren er de delte prosessene som gjør at begge former for interoperabilitet kan fungere.
