Maklerarchitektur der gemeinsamen Objektanfragen

Maklerarchitektur der gemeinsamen Objektanfragen
Abkürzung Corba
Status Veröffentlicht
Jahr begann 1991; Vor 31 Jahren
Letzte Version 3.4
Februar 2021; vor 1 Jahr
Organisation Objektverwaltungsgruppe
Webseite Corba.org

Das Maklerarchitektur der gemeinsamen Objektanfragen (Corba) ist ein Standard definiert durch die Objektverwaltungsgruppe (OMG), um die Kommunikation von Systemen zu erleichtern, die auf verschiedenen Plattformen eingesetzt werden. CORBA ermöglicht die Zusammenarbeit zwischen Systemen auf verschiedenen Betriebssystemen, Programmiersprachenund Computerhardware. CORBA verwendet ein objektorientiertes Modell, obwohl die Systeme, die die CORBA verwenden, nicht objektorientiert sein müssen. CORBA ist ein Beispiel für das verteiltes Objekt Paradigma.

Überblick

CORBA ermöglicht die Kommunikation zwischen Software, die in verschiedenen Sprachen geschrieben wurde und auf verschiedenen Computern ausgeführt wird. Implementierungsdetails aus bestimmten Betriebssystemen, Programmiersprachen und Hardware -Plattformen werden von der Verantwortung von Entwicklern entfernt, die CORBA nutzen. CORBA normalisiert die Methode-Call-Semantik zwischen Anwendungsobjekten, die sich entweder imselben Adressraum (Anwendung) oder in Remote-Adressräumen (gleichem Host oder Remote-Host in einem Netzwerk) befinden. Version 1.0 wurde im Oktober 1991 veröffentlicht.

CORBA verwendet an Schnittstellendefinitionssprache (IDL) Angeben Sie die Schnittstellen an, die Objekte der Außenwelt enthalten. CORBA gibt dann a an Kartierung von IDL zu einer bestimmten Implementierungssprache wie C ++ oder Java. Standardzuordnungen existieren für Ada, C, C ++, C ++ 11, Cobol, Java, Lispeln, Pl/i, Objekt Pascal, Python, Rubin und Smalltalk. Es gibt nicht standardmäßige Zuordnungen für C#, Erlang, Perl, Tcl und Visual Basic implementiert von Objektanforderungsmakler (Orbs) für diese Sprachen geschrieben.

Die CORBA -Spezifikation schreibt vor, dass es eine Kugel geben muss, durch die eine Anwendung mit anderen Objekten interagieren würde. So wird es in der Praxis umgesetzt:

  1. Die Anwendung initialisiert die Kugel und greift auf einen internen zu Objektadapter, was Dinge wie beibehält wie Referenzzählung, Objekt- (und Referenz-) Instanzi -Richtlinien und Objektlebensdauerrichtlinien.
  2. Der Objektadapter wird verwendet, um Instanzen des generierte Codeklassen. Generierte Codeklassen sind das Ergebnis des Kompilierens des Benutzer-IDL-Codes, der die Schnittstellendefinition auf hoher Ebene in eine OS- und Sprachspezifische Klassenbasis für die Verwendung der Benutzeranwendung übersetzt. Dieser Schritt ist erforderlich, um die CORBA -Semantik durchzusetzen und einen sauberen Benutzerprozess für die Vernetzung mit der CORBA -Infrastruktur bereitzustellen.

Einige IDL -Zuordnungen sind schwieriger zu bedienen als andere. Aufgrund der Natur von Java ist die IDL-Java-Mapping beispielsweise ziemlich einfach und macht die Verwendung von CORBA in einer Java-Anwendung sehr einfach. Dies gilt auch für die IDL -to -Python -Mapping. Die C ++ - Mapping erfordert, dass der Programmierer Datenatypen lernt, die vor dem C ++ - Standard -Vorlagenbibliothek (STL). Im Gegensatz dazu ist die C ++ 11 -Mapping einfacher zu bedienen, erfordert jedoch eine starke Verwendung des STL. Da die C-Sprache nicht objektorientiert ist, erfordert die IDL-to-C-Mapping ein C-Programmierer, um objektorientierte Merkmale manuell nachzuahmen.

Um ein System zu erstellen, das eine CORBA-basierte verteilte Objektschnittstelle verwendet oder implementiert, muss ein Entwickler den IDL-Code entweder erhalten oder schreiben, der die objektorientierte Schnittstelle zur Logik definiert, die das System verwendet oder implementiert. In der Regel enthält eine Orb -Implementierung ein Tool namens IDL -Compiler, das die IDL -Schnittstelle in die Zielsprache übersetzt, um in diesem Teil des Systems zu verwenden. Ein herkömmlicher Compiler kompiliert dann den generierten Code, um die Linkable-Object-Dateien zur Verwendung in der Anwendung zu erstellen. Dieses Diagramm zeigt, wie der generierte Code innerhalb der CORBA -Infrastruktur verwendet wird:

Illustration of the autogeneration of the infrastructure code from an interface defined using the CORBA IDL

Diese Figur zeigt das hochrangige Paradigma für die Remote-Interprozesskommunikation mithilfe von CORBA. Die CORBA -Spezifikation befasst sich mit der Typisierung von Daten, Ausnahmen, Netzwerkprotokollen, Kommunikationszeitüberschreitungen usw. Zum Beispiel: Normalerweise hat die Serverseite die Tragbarer Objektadapter (POA), das Aufrufe entweder an den lokalen Ruf weiterleitet Diener oder (um die Last auszugleichen) auf die anderen Server. Die CORBA-Spezifikation (und damit diese Abbildung) überlässt der Anwendung verschiedene Aspekte des verteilten Systems, um einschließlich Objektlebensdauer zu definieren (obwohl für Anwendungen die Semantik der Referenzzählungen verfügbar sind), Redundanz/Ausfall, Speichermanagement, dynamische Lastausgleich und Anwendung- Orientierte Modelle wie die Trennung zwischen Anzeige-/Daten-/Kontrollsemantik (z. B. siehe siehe Model View Controller), etc.

Neben der Bereitstellung einer Sprache und einer Plattform-neutral Remote -Verfahrensanruf (RPC) Spezifikation, CORBA definiert häufig erforderliche Dienste wie Transaktionen und Sicherheit, Ereignisse, Zeit und andere domänenspezifische Schnittstellenmodelle.

Versionen Geschichte

Diese Tabelle zeigt die Geschichte von CORBA -Standardversionen.[1][2]

Ausführung Versionsdatum Highlights
1.0 Oktober 1991 Erste Version, C -Mapping
1.1 Februar 1992 Interoperabilität, C ++ Mapping
1.2 Dezember 1993 -
2.0 August 1996 Erstes großes Update des Standards, ebenfalls genannt CORBA 2
2.1 August 1997 -
2.2 Februar 1998 Java -Mapping
2.3 Juni 1999 -
2.4 August 2000 -
2.5 September 2001 -
2.6 Dezember 2001 -
3.0 Juli 2002 Zweites großes Update des Standards, ebenfalls genannt CORBA 3
CORBA -Komponentenmodell (CCM)
3.0.1 November 2002 -
3.0.2 Dezember 2002 -
3.0.3 März 2004 -
3.1 Januar 2008 -
3.1.1 August 2011 Als Ausgabe 2012 von ISO/IEC 19500 übernommen
3.2 November 2011 -
3.3 November 2012 Zugabe von ZIOP
3.4 Februar 2021

Diener

A Knecht ist das Aufrufziel, das Methoden zum Umgang mit dem enthält Remote -Methodenaufrufe. In den neueren CORBA -Versionen wird das Remote -Objekt (auf der Serverseite) in die aufgeteilt Objekt (Das ist Fernaufrufe ausgesetzt) und Knecht (zu dem der erstere Teil vorwärts die Methode ruft auf). Es kann eins sein Knecht pro Fernbedienung Objektoder der gleiche Diener kann mehrere (möglicherweise alle) Objekte unterstützen, die dem angegeben sind Tragbarer Objektadapter. Das Knecht für jeden Objekt Kann "einmal und für immer" (Dieneraktivierung) oder dynamisch ausgewählt werden, wenn die Methode auf diesem Objekt aufgerufen wird (Dienerort). Sowohl Diener Locator als auch Dieneraktivator können die Anrufe an einen anderen Server weiterleiten. Insgesamt bietet dieses System ein sehr leistungsstarkes Mittel, um die Last auszugleichen und Anforderungen zwischen mehreren Maschinen zu verteilen. In den objektorientierten Sprachen beide Remote Objekt und sein Knecht sind Objekte aus dem Gesichtspunkt der objektorientierten Programmierung.

Menschwerdung Ist der Akt, einen Diener mit einem CORBA -Objekt zu verknüpfen, damit er Anfragen stellt. Die Inkarnation bietet eine konkrete Dienerform für das virtuelle CORBA -Objekt. Die Aktivierung und Deaktivierung beziehen sich nur auf CORBA -Objekte, während die Begriffe Inkarnation und Etherealisierung auf Diener beziehen. Die Lebensdauer von Objekten und Dienern sind jedoch unabhängig. Sie inkarnieren immer einen Diener, bevor Sie ACTECTATE_OBJECT () aufrufen, aber das Gegenteil ist auch möglich, create_reference () aktiviert ein Objekt, ohne einen Diener zu inkarnieren, und Diener -Inkarnation wird später mit einem Dienermanager auf Bedarf durchgeführt.

Das Tragbarer Objektadapter (POA) ist das CORBA Objekt und sein Knecht. Das Objekt ist für die Remote -Aufrufe freigelegt, während der Diener die Methoden enthält, die tatsächlich die Anforderungen bearbeiten. Der Diener für jedes Objekt kann entweder statisch (einmal) oder dynamisch (für jeden Remote -Aufruf) ausgewählt werden, in beiden Fällen, in denen die Anrufweiterleitung an einen anderen Server weiterleitet.

Auf der Serverseite bildet die POAs eine baumähnliche Struktur, wobei jede POA für eine oder mehrere Objekte verantwortlich ist, die bedient werden. Die Zweige dieses Baumes können unabhängig voneinander aktiviert/deaktiviert werden, verfügen über den unterschiedlichen Code für den Dienerstandort oder die Aktivierung und die unterschiedlichen Richtlinien zur Bearbeitung von Anforderungen.

Merkmale

Das Folgende beschreibt einige der wichtigsten Möglichkeiten, wie CORBA verwendet werden kann, um die Kommunikation zwischen verteilten Objekten zu erleichtern.

Objekte durch Bezugnahme

Diese Referenz wird entweder über eine Zeichenfolge erworben Einheitlicher Ressourcen -Locator (URL), NamenService -Lookup (ähnlich wie Domainnamensystem (DNS)) oder als Methodenparameter während eines Aufrufs übergeben.

Objektreferenzen sind leichte Objekte, die der Schnittstelle des realen Objekts (Remote oder Lokal) übereinstimmen. Methodenaufrufe auf die Referenz resultieren zu nachfolgenden Aufrufen der Kugel und blockieren auf dem Thread, während Sie auf eine Antwort, Erfolg oder Misserfolg warten. Die Parameter, Rückgabedaten (falls vorhanden) und Ausnahmedaten werden intern von der ORB gemäß der lokalen Sprache und der OS -Zuordnung gesucht.

Daten nach Wert

Die CORBA-Schnittstellendefinitionssprache bietet die Kommunikationsdefinition von Sprach- und OS-neutral. CORBA -Objekte werden mit Referenz übergeben, während Daten (Ganzzahlen, Doppel, Strukturen, Enums usw.) mit Wert übergeben werden. Die Kombination von Objekten für Referenz und Daten zu Wert bietet die Möglichkeit, eine großartige Daten zu erzwingen, während Kunden und Server die Flexibilität erhalten, die dem CORBA-Problemraum inhärent ist.

Objekte nach Wert (obv)

Abgesehen von entfernten Objekten die CORBA und Rmi-iiop Definieren Sie das Konzept des OBF- und Valuetypes. Der Code in den Methoden von Valuetype -Objekten wird standardmäßig lokal ausgeführt. Wenn das OFF von der abgelegenen Seite eingegangen ist, muss der benötigte Code entweder sein a priori bekannt für beide Seiten oder dynamisch vom Absender heruntergeladen. Um dies zu ermöglichen, enthält der Datensatz, das OBF definiert wird URLs Woher sollte dieser Code heruntergeladen werden. Das OFF kann auch die Remote -Methoden haben.

CORBA -Komponentenmodell (CCM)

Das CORBA -Komponentenmodell (CCM) ist eine Ergänzung zur Familie der CORBA -Definitionen.[3] Es wurde mit CORBA 3 eingeführt und beschreibt ein Standard -Anwendungsrahmen für CORBA -Komponenten. Obwohl nicht abhängig von "sprachabhängig abhängig Enterprise Java Beans (EJB) ", ist es eine allgemeinere Form von EJB, die vier Komponententypen anstelle der beiden bereitstellt, die EJB definiert. Es bietet eine Abstraktion von Unternehmen, die Dienste über gut definierte benannte Schnittstellen genannt können und annehmen können und akzeptieren können und akzeptieren können. Häfen.

Der CCM verfügt über einen Komponentencontainer, in dem Softwarekomponenten bereitgestellt werden können. Der Container bietet eine Reihe von Diensten, die die Komponenten nutzen können. Diese Dienste umfassen (sind jedoch nicht beschränkt) Benachrichtigung, Authentifizierung, Beharrlichkeit und Transaktionsverarbeitung. Dies sind die am häufigsten verwendeten Dienste, die ein verteiltes System benötigt, und durch Verschieben der Implementierung dieser Dienste von den Softwarekomponenten in den Komponentencontainer wird die Komplexität der Komponenten dramatisch reduziert.

Tragbare Abfangjäger

Tragbare Interceptors sind die "Hooks", die von CORBA und verwendet werden Rmi-iiop die wichtigsten Funktionen des CORBA -Systems zu vermitteln. Der CORBA -Standard definiert die folgenden Arten von Interceptors:

  1. Ior Interceptors vermitteln die Erstellung der neuen Verweise auf die vom aktuellen Server dargestellten Remote -Objekte.
  2. Client -Interceptors vermitteln normalerweise die Remote -Methodenaufrufe auf der Seite Client (Anrufer). Wenn das Objekt Knecht Auf demselben Server, auf dem die Methode aufgerufen wird, vermitteln sie auch die lokalen Anrufe.
  3. Server -Interceptors vermitteln die Handhabung der Remote -Methodenaufrufe auf der Seite Server (Handler).

Die Interceptors können die spezifischen Informationen an die gesendeten Nachrichten und die Erstellung von IORs anhängen. Diese Informationen können später vom entsprechenden Interceptor auf der Fernseite gelesen werden. Interceptors können auch Weiterleitungsausnahmen veröffentlichen und Anforderungen an ein anderes Ziel weiterleiten.

General Interorb -Protokoll (GIOP)

Hauptartikel: Allgemeines Inter-ORB-Protokoll

Das Giop ist ein abstraktes Protokoll, durch das Objektanforderungsmakler (Kugeln) kommunizieren. Mit dem Protokoll verbundene Standards werden von der aufrechterhalten Objektverwaltungsgruppe (OMG). Die GIOP -Architektur bietet mehrere konkrete Protokolle, darunter:

  1. Internet Interorb Protocol (IIOP)-Das Internet-Inter-ORB-Protokoll ist eine Implementierung des GIOP zur Verwendung über die Internetund bietet eine Zuordnung zwischen GIOP -Nachrichten und den TCP/IP Schicht.
  2. SSL Interorb Protocol (SSLIOP) - SSLIOP ist iiop over SSLBereitstellung Verschlüsselung und Authentifizierung.
  3. Hypertext Interorb Protocol (HTIOP) - HTIOP ist iiop over HttpBereitstellung von transparenten Proxybypeation.
  4. Reißverschluss IOP (ZIOP) - Eine Reißversion von GIOP, die die Bandbreitennutzung reduziert.

VMCID (Anbieter -Minor -Codeset -ID)

Jede Standard -CORBA -Ausnahme enthält einen kleinen Code zur Bestimmung der Unterkategorie der Ausnahme. Kleinere Ausnahmecodes sind lang nicht signiert und bestehen aus einem 20-Bit-"-Kanal-Moll-Codeset-ID" (VMCID), der die hohe Bestellung 20 Bit einnimmt, und der zuständige Moll-Code, der die niedrige Bestellung 12 Bit einnimmt.

Kleinere Codes für die Standardausnahmen werden von der VMC voranggestützt, die OMG zugeordnet ist, definiert als die nicht signierte lange Konstante Corba :: omgvmcid, bei der das VMCID, das OMG die hohe Ordnung 20 Bit einnimmt, zugewiesen wird. Die mit den Standardausnahmen verbundenen kleinen Ausnahmecodes, die in Tabelle 3–13 auf Seite 3-58 enthalten sind Ausnahmedefinitionen ", auf Seite 3-52 und Abschnitt 3.17.2," Standard-Moll-Ausnahmegelemente ", auf Seite 3-58).

Innerhalb eines von Anbieter zugewiesenen Raums wird die Zuordnung von Werten zu kleineren Codes dem Anbieter überlassen. Anbieter können die Zuordnung von VMCIDs anfordern, indem sie E -Mails an [email protected] senden. Eine Liste der derzeit zugewiesenen VMCIDs finden Sie auf der OMG -Website unter: http://www.omg.org/cgi-bin/doc?vendor-tags

Die VMCID 0 und 0xFFFFF sind für den experimentellen Gebrauch reserviert. Das VMCID OMGVMCID (Abschnitt 3.17.1, "Standard-Ausnahmendefinitionen", auf Seite 3-52) und 1 bis 0xf sind für die Verwendung von OMG reserviert.

Der Common Object Request Broker: Architektur und Spezifikation (CORBA 2.3)

CORBA -Standort (Corbaloc)

CORBA -Standort (CORBALOC) bezieht sich auf eine String -Objektreferenz für ein CORBA -Objekt, das einer URL ähnlich aussieht.

Alle CORBA-Produkte müssen zwei OMG-definierte URLs unterstützen: "corbaloc:" und "Korbaname:". Der Zweck dieser besteht darin, eine menschliche lesbare und bearbeitbare Möglichkeit zu bieten, einen Ort anzugeben, an dem ein IOR erhalten werden kann.

Ein Beispiel für Corbaloc ist unten gezeigt:

Corbaloc :: 160.45.110.41: 38693/Standardns/Namenserver-poa/_root

Ein CORBA -Produkt kann optional die "unterstützen"http:","FTP:" und "Datei:"Formate. Die Semantik davon ist, dass sie Details zum Herunterladen eines angestrichenen IOR (oder rekursiv eine andere URL herunterladen können, die letztendlich einen angestrahlten IOR liefert). Einige Kugeln liefern zusätzliche Formate, die für diese Kugel geschützt sind.

Vorteile

Zu den Vorteilen von CORBA zählen die Sprach- und OS-Unabhängigkeit, die Freiheit von technologisch verbundenen Implementierungen, starke Data-Tying, hohes Maß an Abstimmbarkeit und Freiheit von den Details verteilter Datenübertragungen.

Sprachunabhängigkeit
CORBA wurde entwickelt, um Ingenieure von Einschränkungen der Kopplung ihrer Entwürfe an eine bestimmte Softwaresprache zu befreien. Derzeit gibt es viele Sprachen, die von verschiedenen CORBA -Anbietern unterstützt werden, die beliebtesten Java und C ++. Es gibt auch C ++ 11, C-Nur-C-, SmallTalk-, Perl-, ADA-, Ruby- und Python-Implementierungen, nur um nur einige zu erwähnen.
OS-Unabhängigkeit
Corbas Design soll OS-unabhängig sein. CORBA ist in Java (OS-unabhängig) sowie für Linux/Unix, Windows, Solaris, OS X, OpenVMS, HPUX, Android, Lynxos, VXWorks, Threadx, Integrität und andere erhältlich.
Freiheit von Technologien
Einer der wichtigsten impliziten Vorteile ist, dass CORBA den Ingenieuren ein neutrales Spielfeld bietet, um die Schnittstellen zwischen verschiedenen neuen und Legacy -Systemen zu normalisieren. Bei der Integration von C, C ++, Objekt Pascal, Java, Forran, Python und jeder anderen Sprache oder OS in ein einzelnes kohäsives Systemdesignmodell bietet CORBA die Möglichkeiten, das Feld zu bewerten und unterschiedliche Teams zu ermöglichen, Systeme und Unit -Tests zu entwickeln, die später können können zu einem ganzen System verbunden sein. Dies schließt nicht die Notwendigkeit grundlegender Systementechnikentscheidungen wie Threading, Timing, Objektlebensdauer usw. aus. Diese Probleme sind unabhängig von der Technologie Teil eines Systems. Mit CORBA können Systemelemente in ein einzelnes kohäsives Systemmodell normalisiert werden.
Zum Beispiel das Design von a Multitier Architektur wird einfach mithilfe Java Servlets Auf dem Webserver und verschiedenen CORBA -Servern, die die Geschäftslogik enthalten, und die Datenbankzugriffe einwickeln. Dies ermöglicht es, dass sich die Implementierungen der Geschäftslogik ändern, während sich die Schnittstellenänderungen wie in jeder anderen Technologie behandeln müssten. Beispielsweise kann eine Datenbank, die von einem Server verpackt ist, sein Datenbankschema ändern, um eine verbesserte Festplattennutzung oder -leistung (oder sogar die Änderung des Datenbankanbieters im gesamten Maßstab) zu ändern, ohne die externen Schnittstellen zu beeinflussen. Gleichzeitig kann C ++ Legacy -Code mit C/FORTRAN -Legacy -Code und Java -Datenbankcode sprechen und Daten an einer Weboberfläche bereitstellen.
Data-typing
CORBA bietet eine flexible Datentypisierung, z. B. einen "beliebigen" Datenatyp. CORBA erzwingt auch eine eng gekoppelte Datentypisierung und reduziert menschliche Fehler. In einer Situation, in der Namenswertepaare weitergegeben werden, ist es denkbar, dass ein Server eine Zahl bereitstellt, in der eine Zeichenfolge erwartet wurde. Die CORBA-Schnittstellendefinitionssprache bietet den Mechanismus, um sicherzustellen, dass der Benutzercode den Methodennamen, Rückkehr-, Parametertypen und Ausnahmen entspricht.
Hohe Abstimmung
Viele Implementierungen (z. B. Orbexpress (ADA, C ++ und Java -Implementierung)[4] und Omniorb (Open Source C ++ und Python -Implementierung)))[5] verfügen über Optionen zum Tuning der Funktionen von Threading- und Verbindungsverwaltungen. Nicht alle Orb -Implementierungen bieten die gleichen Funktionen.
Freiheit von Datenübertragungsdetails
Bei der Behandlung von Verbindungen und Fäden auf niedriger Ebene bietet CORBA ein hohes Detailniveau bei Fehlerbedingungen. Dies ist im CORBA-definierten Standardausnahmessatz und im implementierungsspezifischen erweiterten Ausnahmessatz definiert. Durch die Ausnahmen kann die Anwendung feststellen, ob ein Anruf aus Gründen wie "kleinem Problem fehlgeschlagen ist. Versuchen Sie es also erneut", "der Server ist tot" oder "die Referenz macht keinen Sinn". Die allgemeine Regel lautet: Wenn Sie keine Ausnahme erhalten, bedeutet dies, dass die Methode erfolgreich abgeschlossen wurde. Dies ist eine sehr leistungsstarke Designfunktion.
Kompression
CORBA shiert seine Daten in einer binären Form und unterstützt die Komprimierung. Iona, beheben es und Telefónica haben an einer Erweiterung des CORBA -Standards gearbeitet, der Komprimierung liefert. Diese Erweiterung heißt ZIOP und dies ist jetzt ein formeller OMG -Standard.

Probleme und Kritik

Während CORBA viel in der Art und Weise lieferte, wie Code geschrieben und Software erstellt wurde, war es Gegenstand von Kritik.[6]

Ein Großteil der Kritik an CORBA beruht auf schlechten Implementierungen des Standards und nicht der Mängel des Standards selbst. Einige der Fehler des Standards selbst waren auf den Prozess zurückzuführen, durch den die CORBA -Spezifikation geschaffen wurde, und die Kompromisse, die der Politik und dem Geschäft des Schreibens eines gemeinsamen Standards vieler konkurrierender Implementoren inhärent sind.

Erste Implementierungsinkompatibilität
Die anfänglichen Spezifikationen von CORBA definierten nur das IDL, nicht das Format auf dem Draht. Dies bedeutete, dass die Quellcode-Kompatibilität die beste war, die mehrere Jahre lang zur Verfügung stand. Mit CORBA 2 und später wurde dieses Problem gelöst.
Standorttransparenz
CORBAs Begriff der Ortentransparenz wurde kritisiert; Das heißt, dass Objekte, die sich im gleichen befinden Adressraum und zugänglich mit einem einfachen Funktionsaufruf werden genauso behandelt wie Objekte, die an anderer Stelle leben (verschiedene Prozesse auf derselben Maschine oder verschiedene Maschinen). Dies ist ein grundlegender Designfehler,[7][Fehlgeschlagene Überprüfung] Da der gesamte Objektzugriff so komplex ist wie der komplexeste Fall (d. H. Remote -Netzwerkaufruf mit einer breiten Klasse von Fehlern, die in lokalen Aufrufen nicht möglich sind). Es verbirgt auch die unausweichlichen Unterschiede zwischen den beiden Klassen und macht es den Anwendungen unmöglich, eine geeignete Nutzungsstrategie auszuwählen (dh ein Aufruf mit 1µs Latenz und garantierte Rendite werden sehr unterschiedlich als ein Aufruf mit 1S -Latenz mit einem möglichen Transportversagen verwendet, bei dem der Zustellstatus möglicherweise unbekannt ist und möglicherweise die 30er Jahre dauert.
Entwurfs- und Prozessdefizienzen
Die Schaffung des CORBA -Standards wird häufig auch für seinen Prozess von zitiert Entwurf durch Komitee. Es gab keinen Prozess, um zwischen widersprüchlichen Vorschlägen zu schlichten oder über die Hierarchie der Probleme zu entscheiden. Somit wurde der Standard erstellt, indem eine Vereinigung der Merkmale in allen Vorschlägen ohne Rücksicht auf ihre Kohärenz eingenommen wurde.[8] Dies machte die Spezifikation komplex, teuer zu implementieren und oft mehrdeutig.
Ein Designkomitee, das sich aus einer Mischung aus Implementierungsanbietern und Kunden zusammensetzt, schuf unterschiedliche Interessen. Diese Vielfalt machte schwierig zu einem zusammenhängenden Standard. Standards und Interoperabilität erhöhten den Wettbewerb und die Bewegung der Kunden zwischen alternativen Implementierungen. Dies führte zu vielen politischen Kämpfen innerhalb des Ausschusses und zu häufigen Veröffentlichungen der Überarbeitungen des CORBA -Standards, die einige Orb -Implementierer ohne proprietäre Erweiterungen schwer zu verwenden waren.[6] Weniger ethische CORBA-Anbieter förderten die Kundensperrung und erzielten starke kurzfristige Ergebnisse. Im Laufe der Zeit übernahm die Orb -Anbieter, die die Portabilität fördern, Marktanteil.
Probleme mit Implementierungen
In seiner Geschichte wurde CORBA von Mängel in schlechten Implementierungen von Orb geplagt. Leider sind viele der Papiere, die Corba als Standard kritisieren, einfach Kritikpunkte einer besonders schlechten CORBA -ORB -Implementierung.
CORBA ist ein umfassender Standard mit vielen Funktionen. Nur wenige Implementierungen versuchen, alle Spezifikationen zu implementieren,[8] und erste Implementierungen waren unvollständig oder unzureichend. Da es keine Anforderungen an eine Referenzimplementierung gab, waren die Mitglieder frei, Merkmale vorzuschlagen, die nie auf Nützlichkeit oder Implementierbarkeit getestet wurden. Implementierungen wurden durch die allgemeine Tendenz des Standards, ausführlich zu sein .
In der Vergangenheit waren robuste Implementierungen von CORBA sehr schwer zu erwerben, sind aber jetzt viel einfacher zu finden. Die Sun Java SDK wird mit CORBA eingebaut. Einige schlecht gestaltete Implementierungen wurden als komplex, langsam, inkompatibel und unvollständig. Es wurden robuste kommerzielle Versionen auftraten, aber für erhebliche Kosten. Als gute qualitativ hochwertige kostenlose Implementierungen verfügbar wurden, starben die schlechten kommerziellen Implementierungen schnell.
Firewalls
Corba (genauer gesagt, Giop) ist nicht an einen bestimmten Kommunikationstransport gebunden. Eine Spezialisierung von GIOP ist das Internet-Inter-ORB-Protokoll oder IIOP. IIOP verwendet RAW TCP/IP Verbindungen, um Daten zu übertragen.
Wenn der Kunde hinter einer sehr restriktiven Firewall steht oder transparenter Proxy Serverumgebung, die nur zulässt Http Verbindungen zu außen über Port 80 können die Kommunikation nicht möglich sein, es sei denn, der betreffende Proxy -Server erlaubt das HTTP Connect Methode oder Socken Verbindungen auch. Zu einer Zeit war es schwierig, Implementierungen zu zwingen, einen einzelnen Standardport zu verwenden - sie neigten dazu, stattdessen mehrere zufällige Ports auszuwählen. Bis heute haben aktuelle Kugeln diese Mängel. Aufgrund solcher Schwierigkeiten haben einige Benutzer zunehmend verwendet Internetdienste anstelle von corba. Diese kommunizieren mithilfe Xml/SEIFE über Port 80, der normalerweise über einen HTTP -Proxy in der Organisation offen gelassen oder gefiltert wird, zum Webstöbern über HTTP. Jüngste CORBA -Implementierungen unterstützen jedoch Unterstützung SSL und kann leicht so konfiguriert werden, dass sie an einem einzigen Port arbeiten. Einige Kugeln, wie z. Tao, Omniorb und Jacorb unterstützen auch die bidirektionale GIOP, was CORBA den Vorteil bietet, eine Rückrufkommunikation zu nutzen, anstatt den für Webdienst -Implementierungen charakteristischen Wahllokalansatz. Außerdem unterstützen die meisten modernen Firewalls GIOP & IIOP und sind somit corba-freundliche Firewalls.

Siehe auch

Softwareentwicklung

Komponentenbasierte Softwaretechnologien

Sprachbindungen

Verweise

  1. ^ "Geschichte von Corba". Objektverwaltungsgruppe. Abgerufen 12. März 2017.
  2. ^ "Geschichte von Corba". Objektverwaltungsgruppe. Abgerufen 4. Juni 2017.
  3. ^ "Das CORBA -Komponentenmodell". Dr. Dobbs Journal. 1. September 2004. Abgerufen 13. März 2017.
  4. ^ "Orbexpress: Echtzeit Corba Orb".
  5. ^ "Omniorb: Free Corba Orb". SourceForge.net. Abgerufen 9. Januar 2014.
  6. ^ a b Chappel, David (Mai 1998). "Problem mit Corba". Davidchappel.com. Archiviert von das Original am 3. Dezember 2012. Abgerufen 15. März 2010.
  7. ^ Waldo, Jim; Geoff Wyant; Ann Wollrath; Sam Kendall (November 1994). "Ein Hinweis zum verteilten Computing" (PDF). Sun Microsystem Laboratorien. Abgerufen 4. November 2013.
  8. ^ a b Henning, Michi (30. Juni 2006). "Der Aufstieg und Fall von Corba". ACM -Warteschlange. Verband für Rechenmaschinen. 4 (5): 28–34. doi:10.1145/1142031.1142044. S2CID 12103742. Abgerufen 15. März 2010.

Weitere Lektüre

Externe Links