Almindelig objektanmodningsmæglerarkitektur - Common Object Request Broker Architecture

Almindelig objektanmodningsmæglerarkitektur
Status Udgivet
Året startede 1991 ; 30 år siden ( 1991 )
Nyeste version 3.3.
Oktober 2012 ; 8 år siden ( 2012-10 )
Organisation Objektstyringsgruppe
Forkortelse CORBA
Internet side corba .org

Den fælles Object Request Broker Architecture ( CORBA ) er en standard defineret af Object Management Group (OMG) designet til at lette kommunikationen af systemer, der er indsat på forskellige platforme. CORBA muliggør samarbejde mellem systemer på forskellige operativsystemer, programmeringssprog og computerhardware. CORBA bruger en objektorienteret model, selvom de systemer, der bruger CORBA, ikke behøver at være objektorienterede. CORBA er et eksempel på det distribuerede objektparadigme.

Oversigt

CORBA muliggør kommunikation mellem software skrevet på forskellige sprog og kører på forskellige computere. Implementeringsdetaljer fra specifikke operativsystemer, programmeringssprog og hardwareplatforme fjernes alle fra ansvaret for udviklere, der bruger CORBA. CORBA normaliserer metoden-opkaldssemantik mellem applikationsobjekter, der befinder sig enten i det samme adresse-rum (applikation) eller i eksterne adresse-rum (samme vært eller fjernhost på et netværk). Version 1.0 blev udgivet i oktober 1991.

CORBA bruger et interface definition definition sprog (IDL) til at specificere de grænseflader, som objekter præsenterer for den ydre verden. CORBA angiver derefter en kortlægning fra IDL til et specifikt implementeringssprog som C ++ eller Java . Standardtilknytninger findes til Ada , C , C ++ , C ++ 11 , COBOL , Java , Lisp , PL / I , Object Pascal , Python , Ruby og Smalltalk . Ikke-standard tilknytninger findes for C # , Erlang , Perl , Tcl og Visual Basic gennemført ved anmodning objekt mæglere (orbs) skrevet til disse sprog.

CORBA-specifikationen dikterer, at der skal være en ORB, gennem hvilken en applikation vil interagere med andre objekter. Sådan implementeres det i praksis:

  1. Applikationen initialiserer ORB'en og får adgang til en intern Object Adapter , der opretholder ting som referencetælling , objekt (og reference) instantieringspolitikker og objektlivspolitikker.
  2. Objektadapteren bruges til at registrere forekomster af de genererede kodeklasser . Genererede kodeklasser er resultatet af kompilering af bruger-IDL-koden, som oversætter definitionen af ​​grænsefladen på højt niveau til en OS- og sprogspecifik klassebase til brug af brugerapplikationen. Dette trin er nødvendigt for at håndhæve CORBA-semantik og give en ren brugerproces til grænseflade med CORBA-infrastrukturen.

Nogle IDL-kortlægninger er sværere at bruge end andre. På grund af Java er f.eks. IDL-Java-kortlægningen ret ligetil og gør brugen af ​​CORBA meget enkel i en Java-applikation. Dette gælder også for kortlægning af IDL til Python. C ++ -tilknytningen kræver, at programmøren lærer datatyper, der går forud for C ++ - standardskabelonbiblioteket (STL). I modsætning hertil er C ++ 11-kortlægningen nemmere at bruge, men kræver tung brug af STL. Da C-sproget ikke er objektorienteret, kræver IDL til C-kortlægning, at en C-programmerer manuelt efterligner objektorienterede funktioner.

For at opbygge et system, der bruger eller implementerer en CORBA-baseret distribueret objektgrænseflade, skal en udvikler enten indhente eller skrive den IDL-kode, der definerer den objektorienterede grænseflade til den logik, systemet vil bruge eller implementere. Typisk inkluderer en ORB-implementering et værktøj kaldet en IDL-kompilator, der oversætter IDL-grænsefladen til målsproget til brug i den del af systemet. En traditionel kompilator kompilerer derefter den genererede kode for at oprette de linkbare objektfiler til brug i applikationen. Dette diagram illustrerer, hvordan den genererede kode bruges inden for CORBA-infrastrukturen:

Illustration af autogenerering af infrastrukturkoden fra en grænseflade defineret ved hjælp af CORBA IDL

Denne figur illustrerer paradigmet på højt niveau for ekstern interprocess-kommunikation ved hjælp af CORBA. CORBA-specifikationen vedrører yderligere datatypning, undtagelser, netværksprotokoller, kommunikations-timeouts osv. For eksempel: Normalt har serversiden den bærbare objektadapter (POA), der omdirigerer opkald til de lokale ansatte eller (for at afbalancere belastningen) til andre servere. CORBA-specifikationen (og dermed denne figur) overlader forskellige aspekter af distribueret system til applikationen for at definere inklusive objektlevetid (skønt der er reference-semantik til rådighed for applikationer), redundans / fail-over, hukommelsesstyring, dynamisk belastningsbalancering og applikations- orienterede modeller såsom adskillelsen mellem display / data / kontrolsemantik (f.eks. se Model – view – controller ) osv.

Ud over at give brugerne et sprog og en RPC-specifikation ( Platform-neutral remote procedure call ) definerer CORBA almindeligt nødvendige tjenester såsom transaktioner og sikkerhed, begivenheder, tid og andre domænespecifikke interface-modeller.

Versioner historie

Denne tabel viser historien om CORBA-standardversioner.

Version Versionsdato Højdepunkter
1.0 Oktober 1991 Første version, C-kortlægning
1.1 Februar 1992 Interoperabilitet, C ++ kortlægning
1.2 December 1993 -
2.0 August 1996 Første større opdatering af standarden, også kaldet CORBA 2
2.1 August 1997 -
2.2 Februar 1998 Java-kortlægning
2.3 Juni 1999 -
2.4 August 2000 -
2.5 September 2001 -
2.6 December 2001 -
3.0 Juli 2002 Anden større opdatering af standarden, også kaldet CORBA 3
CORBA Component Model (CCM)
3.0.1 November 2002 -
3.0.2 December 2002 -
3.0.3 Marts 2004 -
3.1 Januar 2008 -
3.1.1 August 2011 Vedtaget som 2012-udgave af ISO / IEC 19500
3.2 November 2011 -
3.3 November 2012 Tilføjelse af ZIOP

Tjenere

En tjener er påkaldsmålet, der indeholder metoder til håndtering af de eksterne metodeopkald . I de nyere CORBA-versioner opdeles fjernobjektet (på serversiden) i objektet (der er udsat for fjernopkald) og tjener (som den tidligere del videresender metoden kalder til) . Det kan være en tjener pr remote objekt , eller den samme Tjener kan understøtte flere (muligvis alle) objekter, der er forbundet med det givne Portable Object Adapter . Den tjener for hvert objekt kan indstilles eller fundet "én gang og for evigt" (tjener aktivering) eller dynamisk valgt hver gang fremgangsmåden på, at objektet påberåbes (Tjener placering). Både tjenerlokator og tjeneraktivator kan viderestille opkaldene til en anden server. I alt giver dette system et meget effektivt middel til at afbalancere belastningen ved at distribuere anmodninger mellem flere maskiner. I objektorienterede sprog, både remote objekt og dets Tjener er objekter fra det synspunkt af objektorienteret programmering.

Inkarnation er handlingen ved at knytte en tjener til et CORBA-objekt, så det kan serviceanmodninger. Inkarnation giver en konkret tjenerformular til det virtuelle CORBA-objekt. Aktivering og deaktivering henviser kun til CORBA-objekter, mens udtrykkene inkarnation og etherealisering henviser til tjenere. Imidlertid er objekternes og tjenesternes levetid uafhængig. Du inkarnerer altid en tjener, inden du ringer til aktiv_objekt (), men det omvendte er også muligt, create_reference () aktiverer et objekt uden at inkarnere en tjener, og tjenerinkarnation udføres senere efter behov med en Servant Manager.

Det Portable Object Adapter (POA) er CORBA-objektet, der er ansvarlig for at opdele serverens fjernanvendelsesbehandler i det eksterneobjektog detstjener. Objektet udsættes for fjernopkald, mens tjeneren indeholder de metoder, der rent faktisk håndterer anmodningerne. Tjeneren for hvert objekt kan vælges enten statisk (en gang) eller dynamisk (for hver fjernopkald), hvilket i begge tilfælde tillader viderestilling af opkald til en anden server.

På serversiden udgør POA'erne en trælignende struktur, hvor hver POA er ansvarlig for, at et eller flere objekter serveres. Grenene på dette træ kan aktiveres / deaktiveres uafhængigt af hinanden, har den forskellige kode for tjenerplacering eller aktivering og de forskellige politikker for anmodningshåndtering.

Funktioner

I det følgende beskrives nogle af de mest betydningsfulde måder, som CORBA kan bruges til at lette kommunikationen mellem distribuerede objekter.

Objekter ved reference

Denne reference er enten erhvervet gennem en strenget Uniform Resource Locator (URL), NameService-opslag (svarende til Domain Name System (DNS)) eller videresendt som en metodeparameter under et opkald.

Objektreferencer er lette objekter, der matcher grænsefladen for det rigtige objekt (fjernt eller lokalt). Metoden kalder på referenceresultatet i efterfølgende opkald til ORB og blokering på tråden mens du venter på et svar, succes eller fiasko. Parametrene, eventuelt returneringsdata og undtagelsesdata marshaleres internt af ORB i henhold til det lokale sprog og OS-kortlægning.

Data efter værdi

CORBA-grænseflades definitionssprog giver den sprog- og OS-neutrale inter-objektkommunikationsdefinition. CORBA-objekter videregives ved henvisning, mens data (heltal, fordoblinger, strukturer, enum osv.) Videregives efter værdi. Kombinationen af ​​Objects-by-reference og data-by-value giver midlerne til at håndhæve stor datatypning under kompilering af klienter og servere, men alligevel bevare den fleksibilitet, der ligger i CORBA-problemrummet.

Objekter efter værdi (OBV)

Bortset fra fjerne objekter definerer CORBA og RMI-IIOP begrebet OBV og Valuetypes. Koden inde i metoderne til Valuetype-objekter udføres som standard lokalt. Hvis OBV er modtaget fra den eksterne side, skal den nødvendige kode enten være på forhånd kendt for begge sider eller downloades dynamisk fra afsenderen. For at gøre dette muligt indeholder posten, der definerer OBV, kodebasen, der er en plads-adskilt liste over webadresser, hvorfra denne kode skal downloades. OBV kan også have fjernmetoderne.

CORBA Component Model (CCM)

CORBA Component Model (CCM) er en tilføjelse til familien af ​​CORBA-definitioner. Det blev introduceret med CORBA 3, og det beskriver en standard applikationsramme for CORBA-komponenter. Selvom det ikke er afhængigt af "sprogafhængige Enterprise Java Beans (EJB)", er det en mere generel form for EJB, der leverer fire komponenttyper i stedet for de to, som EJB definerer. Det giver en abstraktion af enheder, der kan levere og acceptere tjenester gennem veldefinerede navngivne grænseflader kaldet porte .

CCM har en komponentcontainer, hvor softwarekomponenter kan implementeres. Containeren tilbyder et sæt tjenester, som komponenterne kan bruge. Disse tjenester inkluderer (men er ikke begrænset til) underretning , godkendelse , vedholdenhed og transaktionsbehandling . Dette er de mest anvendte tjenester, som ethvert distribueret system kræver, og ved at flytte implementeringen af ​​disse tjenester fra softwarekomponenterne til komponentbeholderen reduceres kompleksiteten af ​​komponenterne dramatisk.

Bærbare interceptors

Bærbare interceptorer er "kroge", der bruges af CORBA og RMI-IIOP til at formidle de vigtigste funktioner i CORBA-systemet. CORBA-standarden definerer følgende typer interceptorer:

  1. IOR- interceptors formidler oprettelsen af ​​de nye referencer til de eksterne objekter, præsenteret af den aktuelle server.
  2. Klientinterceptorer formidler normalt fjernmetodeopkald på klientsiden (kalderen). Hvis objektet Servant findes på den samme server, hvor metoden påberåbes, formidler de også de lokale opkald.
  3. Serverinterceptorer formidler håndteringen af ​​opkald til fjernmetoden på serveren (handler).

Aflytterne kan vedhæfte den specifikke information til de beskeder, der sendes, og IOR'er, der oprettes. Denne information kan senere læses af den tilsvarende interceptor på den eksterne side. Interceptors kan også kaste videresendelsesundtagelser og omdirigere anmodning til et andet mål.

Generel InterORB-protokol (GIOP)

Hovedartikel: Generel Inter-ORB-protokol

Den GIOP er en abstrakt protokol, hvorved Object anmodning mæglere (kugler) kommunikerer. Standarder, der er knyttet til protokollen, opretholdes af Object Management Group (OMG). GIOP-arkitekturen giver flere konkrete protokoller, herunder:

  1. Internet InterORB Protocol (IIOP) - Internet Inter-Orb Protocol er en implementering af GIOP til brug over internettet og giver en kortlægning mellem GIOP-meddelelser og TCP / IP- laget.
  2. SSL InterORB Protocol (SSLIOP) - SSLIOP er IIOP over SSL , der giver kryptering og godkendelse .
  3. HyperText InterORB-protokol (HTIOP) - HTIOP er IIOP over HTTP , hvilket giver gennemsigtig proxy-omgåelse.
  4. Zippet IOP (ZIOP) - En zip-version af GIOP, der reducerer båndbreddeforbruget.

VMCID (leverandør mindre kodesæt-id)

Hver standard CORBA-undtagelse indeholder en mindre kode til at betegne undtagelsens underkategori. Mindre undtagelseskoder er af typen usigneret lang og består af et 20-bit "Vendor Minor Codeset ID" (VMCID), som optager den høje orden på 20 bit, og den mindre mindre korrekte kode, der optager den lave orden 12 bit.

Mindre koder for standardundtagelserne er forud for VMCID'en, der er tildelt OMG, defineret som den usignerede lange konstante CORBA :: OMGVMCID, som har VMCID'en tildelt OMG, der optager 20 bit i høj orden. De mindre undtagelseskoder, der er knyttet til standardundtagelserne, der findes i tabel 3–13 på side 3-58, er or-ed med OMGVMCID for at få den mindre kodeværdi, der returneres i ex_body-strukturen (se afsnit 3.17.1, "Standard Undtagelsesdefinitioner ", på side 3-52 og afsnit 3.17.2," Standard mindre undtagelseskoder ", på side 3-58).

Inden for en leverandør tildelt plads overlades tildelingen af ​​værdier til mindre koder til sælgeren. Leverandører kan anmode om tildeling af VMCID'er ved at sende e-mail til tagrequest@omg.org. En liste over aktuelt tildelte VMCID'er kan findes på OMG-webstedet på: http://www.omg.org/cgi-bin/doc?vendor-tags

VMCID 0 og 0xfffff er forbeholdt eksperimentel brug. VMCID OMGVMCID (afsnit 3.17.1, "Standardundtagelsesdefinitioner", på side 3-52) og 1 til 0xf er forbeholdt OMG-brug.

Mægleren for anmodning om fælles objekt: arkitektur og specifikation (CORBA 2.3)

Corba-placering (CorbaLoc)

Corba Location (CorbaLoc) henviser til en streng objektreference for et CORBA-objekt, der ligner en URL.

Alle CORBA-produkter skal understøtte to OMG-definerede webadresser: " corbaloc: " og " corbaname: ". Formålet med disse er at give en menneskelig læsbar og redigerbar måde at specificere en placering, hvor en IOR kan opnås.

Et eksempel på corbaloc er vist nedenfor:

corbaloc :: 160.45.110.41: 38693 / StandardNS / NameServer-POA / _root

Et CORBA-produkt understøtter muligvis formaterne " http: ", " ftp: " og " file: ". Semantikken ved disse er, at de giver detaljer om, hvordan man downloader en streng IOR (eller rekursivt downloader en anden URL, der til sidst vil give en streng IOR). Nogle ORB'er leverer yderligere formater, som er proprietære for den ORB.

Fordele

CORBAs fordele inkluderer sprog- og OS-uafhængighed, frihed fra teknologikædte implementeringer, stærk datatypning, høj grad af indstilling og frihed fra detaljerne i distribuerede dataoverførsler.

Sproguafhængighed
CORBA blev designet til at befri ingeniører fra begrænsningerne ved at koble deres design til et bestemt softwaressprog. I øjeblikket er der mange sprog understøttet af forskellige CORBA-udbydere, de mest populære er Java og C ++. Der er også C ++ 11, kun C, Smalltalk, Perl, Ada, Ruby og Python-implementeringer, for blot at nævne nogle få.
OS-uafhængighed
CORBAs design er beregnet til at være OS-uafhængig. CORBA fås i Java (OS-uafhængig) såvel som indbygget til Linux / Unix, Windows, Solaris, OS X, OpenVMS, HPUX, Android, LynxOS, VxWorks, ThreadX, INTEGRITY og andre.
Frihed fra teknologier
En af de største implicitte fordele er, at CORBA giver neutrale spilleregler for ingeniører, der er i stand til at normalisere grænsefladerne mellem forskellige nye og ældre systemer. Når C, C ++, Object Pascal, Java, Fortran, Python og ethvert andet sprog eller OS integreres i en enkelt sammenhængende systemdesignmodel, giver CORBA midlerne til at udjævne feltet og give forskellige hold mulighed for at udvikle systemer og enhedstest, der senere kan blive sammenføjet til et helt system. Dette udelukker ikke behovet for grundlæggende systemtekniske beslutninger, såsom trådning, timing, objektlevetid osv. Disse problemer er en del af ethvert system uanset teknologi. CORBA gør det muligt at normalisere systemelementer til en enkelt sammenhængende systemmodel.
For eksempel er designet af en flerlagsarkitektur gjort simpelt ved hjælp af Java Servlets i webserveren og forskellige CORBA-servere, der indeholder forretningslogikken og indpakning af databaseadgangene. Dette gør det muligt at ændre implementeringen af ​​forretningslogikken, mens interfaceændringerne skal håndteres som i enhver anden teknologi. For eksempel kan en database indpakket af en server få ændret databaseskemaet af hensyn til forbedret diskbrug eller ydeevne (eller endda hele databaseleverandørændring) uden at påvirke de eksterne grænseflader. På samme tid kan C ++ ældre kode tale med C / Fortran ældre kode og Java-databasekode og kan levere data til en webgrænseflade.
Datatypning
CORBA giver fleksibel datatypning, for eksempel en "ALT" datatype. CORBA håndhæver også tæt koblet datatyping, hvilket reducerer menneskelige fejl. I en situation, hvor Name-Value-par sendes rundt, kan det tænkes, at en server leverer et nummer, hvor en streng blev forventet. CORBA Interface Definition Language giver mekanismen til at sikre, at brugerkoden overholder metodenavne, retur-, parametertyper og undtagelser.
Høj afstemningsevne
Mange implementeringer (f.eks. ORBexpress (Ada, C ++ og Java-implementering) og OmniORB (open source C ++ og Python-implementering)) har muligheder for at indstille funktionerne til trådning og forbindelsesadministration. Ikke alle ORB-implementeringer har de samme funktioner.
Frihed fra dataoverførselsoplysninger
Ved håndtering af lavt niveau tilslutning og gevindskæring giver CORBA et højt niveau af detaljer under fejlforhold. Dette er defineret i det CORBA-definerede standardundtagelsessæt og det implementeringsspecifikke udvidede undtagelsessæt. Gennem undtagelserne kan applikationen afgøre, om et opkald mislykkedes af grunde som "Lille problem, så prøv igen", "Serveren er død" eller "Henvisningen giver ikke mening." Den generelle regel er: At ikke modtage en undtagelse betyder, at metodekaldet er gennemført med succes. Dette er en meget kraftig designfunktion.
Kompression
CORBA marcherer sine data i binær form og understøtter komprimering. IONA, Remedy IT og Telefónica har arbejdet på en udvidelse til CORBA-standarden, der leverer kompression. Denne udvidelse kaldes ZIOP, og dette er nu en formel OMG-standard.

Problemer og kritik

Mens CORBA leverede meget på den måde, som kode blev skrevet og software konstrueret, har det været genstand for kritik.

Meget af kritikken af ​​CORBA stammer fra dårlige implementeringer af standarden og ikke mangler ved selve standarden. Nogle af svigtene i selve standarden skyldtes den proces, hvor CORBA-specifikationen blev oprettet, og kompromiserne, der er forbundet med politik og forretning med at skrive en fælles standard, der kommer fra mange konkurrerende implementatorer.

Indledende implementeringskompatibiliteter
De oprindelige specifikationer for CORBA definerede kun IDL, ikke on-the-wire-formatet. Dette betød, at kildekodekompatibilitet var det bedste, der var tilgængeligt i flere år. Med CORBA 2 og senere blev dette problem løst.
Placering gennemsigtighed
CORBAs opfattelse af placeringsgennemsigtighed er blevet kritiseret; det vil sige, at objekter, der er bosat i det samme adresserum og tilgængelige med et simpelt funktionsopkald , behandles det samme som objekter, der er bosat andre steder (forskellige processer på den samme maskine eller forskellige maskiner). Dette er en grundlæggende designfejl, da den gør al objektadgang så kompliceret som det mest komplekse tilfælde (dvs. fjernnetværksopkald med en lang række fejl, der ikke er mulige i lokale opkald). Det skjuler også de uundgåelige forskelle mellem de to klasser, hvilket gør det umuligt for applikationer at vælge en passende brugsstrategi (det vil sige et opkald med 1 µs latenstid og garanteret returnering vil blive brugt meget forskelligt fra et opkald med 1 s latenstid med mulig transportfejl , hvor leveringsstatus muligvis er ukendt og kan tage 30'ere at time out).
Design og proces mangler
Oprettelsen af ​​CORBA-standarden er også ofte citeret for sin designproces af komitéen . Der var ingen proces til at skille mellem modstridende forslag eller til at træffe beslutning om hierarkiet af problemer, der skal tackles. Standarden blev således skabt ved at tage en forening af funktionerne i alle forslag uden hensyntagen til deres sammenhæng. Dette gjorde specifikationen kompleks, dyr at implementere fuldstændigt og ofte tvetydig.
En designkomité sammensat af en blanding af implementeringsleverandører og kunder skabte et varieret sæt interesser. Denne mangfoldighed gjorde en vanskelig sammenhængende standard vanskelig. Standarder og interoperabilitet øgede konkurrencen og lette kundernes bevægelse mellem alternative implementeringer. Dette førte til meget politisk kamp i udvalget og hyppige udgivelser af revisioner af CORBA-standarden, som nogle ORB-implementatorer sikrede, var vanskelige at bruge uden proprietære udvidelser. Mindre etiske CORBA-leverandører tilskyndede kundelås og opnåede stærke kortsigtede resultater. Over tid overtog ORB-leverandørerne, der tilskynder til bærbarhed, markedsandele.
Problemer med implementeringer
Gennem sin historie har CORBA været plaget af mangler ved dårlige ORB-implementeringer. Desværre er mange af papirerne, der kritiserer CORBA som standard, simpelthen kritik af en særlig dårlig CORBA ORB-implementering.
CORBA er en omfattende standard med mange funktioner. Få implementeringer forsøger at implementere alle specifikationerne, og de første implementeringer var ufuldstændige eller utilstrækkelige. Da der ikke var krav om at levere en referenceimplementering, kunne medlemmerne foreslå funktioner, der aldrig blev testet for anvendelighed eller implementerbarhed. Implementeringer blev yderligere forhindret af standardens generelle tendens til at være ordentlig og den almindelige praksis med at gå på kompromis ved at vedtage summen af ​​alle indsendte forslag, som ofte skabte API'er, der var usammenhængende og vanskelige at bruge, selvom de enkelte forslag var helt rimelige .
Robuste implementeringer af CORBA har tidligere været meget vanskelige at erhverve, men er nu meget lettere at finde. SUN Java SDK leveres med indbygget CORBA. Nogle dårligt designede implementeringer har vist sig at være komplekse, langsomme, uforenelige og ufuldstændige. Robuste kommercielle versioner begyndte at dukke op, men til betydelige omkostninger. Da gratis implementeringer af god kvalitet blev tilgængelige, døde de dårlige kommercielle implementeringer hurtigt.
Firewalls
CORBA (mere præcist, GIOP ) er ikke bundet til nogen særlig kommunikationstransport. En specialisering af GIOP er Internet Inter-ORB Protocol eller IIOP. IIOP bruger rå TCP / IP- forbindelser til at overføre data.
Hvis klienten står bag en meget restriktiv firewall eller et gennemsigtigt proxyservermiljø , der kun tillader HTTP- forbindelser udefra gennem port 80, kan kommunikation være umulig, medmindre den pågældende proxyserver tillader HTTP CONNECT- metoden eller SOCKS- forbindelser også. På et tidspunkt var det vanskeligt, selv at tvinge implementeringer til at bruge en enkelt standardport - de havde tendens til at vælge flere tilfældige porte i stedet. Fra i dag har nuværende ORB'er disse mangler. På grund af sådanne vanskeligheder har nogle brugere gjort stigende brug af webtjenester i stedet for CORBA. Disse kommunikerer ved hjælp af XML / SOAP via port 80, som normalt er åben eller filtreret gennem en HTTP-proxy inde i organisationen, til browsing via HTTP. Nylige CORBA-implementeringer understøtter dog SSL og kan let konfigureres til at arbejde på en enkelt port. Nogle ORBS, såsom TAO , omniORB og JacORB , understøtter også tovejs GIOP, hvilket giver CORBA fordelen ved at være i stand til at bruge tilbagekaldskommunikation snarere end polling-tilgangen, der er karakteristisk for implementering af webservices. De fleste moderne firewalls understøtter også GIOP & IIOP og er således CORBA-venlige firewalls.

Se også

Software Engineering

Komponentbaseret softwareteknologi

Sprogbindinger

Referencer

Yderligere læsning

eksterne links