Diskussion:Common Object Request Broker Architecture

Ich spreche mich für die Löschung des folgenden Abschnitts aus:

"Nach den Bemühungen von z. B. Microsoft, eine objektorientierte, CORBA-artige Struktur in ihrem Betriebssystem nachzubilden (OLE, COM, dann im Netzwerk DCOM, MTS, COM+ ) sollte die Entwicklung von Web Services CORBA endgültig ablösen. Dies war zuerst aus mehreren Gründen offensichtlich, galt CORBA doch als zu langsam und oftmals nicht kompatibel genug, wenn es um verschiedene Implementierungen und Standards ging. Jedoch wird CORBA seit dem Jahr 2004 wieder vermehrt eingesetzt, was vor allem daran liegt, dass mittlerweile für die netzwerk- und prozessorintensive CORBA-Struktur genug Rechenleistung zur Verfügung steht und ein ORB nicht stateless vorgeht, wie es bei Web Services der Fall ist, insofern diese das HTTP-Protokoll als Datenübertragungsprotokoll verwenden."

Dieser erweckt den Eindruck, dass CORBA hauptsächlich für WEB-Anwendungen verwendet wurde und heute nicht mehr eigesetzt wird. Dies ist jedoch falsch: in vielen nicht WEB-zentrieten Anwendung ist HTTP vollkommen unbrauchbar, insbesondere auf vielen von CORBA unterstützten BUS systemen (CAN, Profibus,...). Falls es keinen Widerspruch gibt kann ich diese Änderungen vornehmen.

Stimme zu.

Stimme ebenfalls zu. --Bonzai44 11:10, 7. Feb 2006 (CET)

"Meist erzeugt ein so genannter IDL-Compiler Stubs und Skeletons, die mit der eigentlichen Programmlogik ergänzt werden. Der lokale Client ruft nun den Stub-Code auf, der die Daten an einen Object Request Broker (ORB) weitergibt. Dieser ORB reicht die Daten dann an den ORB des entfernten Objekts weiter. Der Aufruf des entfernten Objekts erfolgt mittels der Skeletons."

Diese Beschreibung ist nicht ganz korrekt bzw. irreführend. Client Stubs und Server Skeletons werden nicht mit Programmlogik ergänzt. Die eigentliche Anwendung verwendet Stubs zur transparenten Kommunikation mit den serverseitigen Objekten. Die Server Skeletons dispatchen die Requests an die zuständigen Service-Objekte. Sie übertragen also im eigentlichen Sinne keine Daten, sondern realisieren lediglich einen Remote Procedure Call inklusive Marshaling/Demarshaling auf der Basis des CORBA Kommunikationsprotokolls. Ausserdem würde ich "meist" streichen, denn diese werden eigentlich immer erzeugt.

Michael Klug

Dem Stimme ich zu, der absatz hört sich tatsächlich so an, als ob man am generierten Code erweitern würde, was aber nicht zutreffend ist. Auch das "meist" ist definitiv falsch, da der IDL compiler unbedingt zu einem CORBA ORB dazu gehört - auch wenn prinzipiell eine andere Implementierung des GIOP denkbar wäre.

"Meist erzeugt ein so genannter IDL-Compiler Stubs und Skeletons, die mit der eigentlichen Programmlogik ergänzt werden. Der lokale Client ruft nun den Stub-Code auf, der die Daten an einen Object Request Broker (ORB) weitergibt. Dieser ORB reicht die Daten dann an den ORB des entfernten Objekts weiter. Der Aufruf des entfernten Objekts erfolgt mittels der Skeletons." => Das stimmt so einfach nicht, ich schließe mich da meinen Vorrednern an. Siehe CORBA FAQ:[1] Werner Zirkel