Mit dem E-Business-Boom ist in den vergangenen eineinhalb Jahren auch der Bedarf an Middleware für geschäftskritische Anwendungen gestiegen. Je heterogener und größer die IT-Umgebung, desto eher wird dabei ein auf Corba basierender Applikations-Server benötigt.

Durch die Unabhängigkeit von Programmiersprache und Rechnerarchitektur und die im Standard verankerte Interoperabilität unterschiedlicher Produkte ist Corba eine besonders geeignete Plattform für die Integration heterogener Systeme. Ein praktischer Indikator ist das breite Spektrum der durch unterschiedliche Hersteller abgedeckten Programmiersprachen (C++, Java, Smalltalk und Cobol) sowie der Betriebssysteme von Windows über alle wichtigen Unix-Derivate bis hin zu OS/390, das von allen drei untersuchten Produkten unterstützt wird. Diese Eigenschaft wird häufig genutzt, um "Altsysteme" mit einem modernen IDL-Adapter in neue Client-Server-Strukturen einzubinden und damit Investitionsschutz zu gewährleisten.

Auch die Verbindung mit anderen Komponentenplattformen ist bei den Corba-Systemen durch Spezifikationen geregelt. Das gilt insbesondere für Microsofts COM/ DCOM-Technik (Component Object Model/Distributed Common Odject Model), die in einigen Bereichen mit Corba konkurriert. Zudem werden Corba-Komponenten im Einklang mit dem EJB-Standard von Sun definiert. Die aktuellen Applikations-Server setzen diese Möglichkeit auf unterschiedliche Art um und bedienen de facto beide Welten gleichberechtigt. Dennoch weisen die untersuchten Produkte wesentliche Differenzierungsmerkmale auf.

"Orbix OTM" und der "Inprise Application Server" entwickelten sich aus dem ORB als Basistechnologie und bieten eine weit reichende Unterstützung der Corba-Standards sowie nunmehr auch die Integration von EJB (bei Iona mit iPortal).

"Weblogic Enterprise" ging aus dem Transaktionsmonitor "Tuxedo" hervor, der um Corba-Schnittstellen erweitert wurde (die Enterprise-Java-Standards werden durch "Weblogic Server" umgesetzt). Damit liegt bei Bea der Schwerpunkt eher auf Transaktionsverarbeitung, Lastverteilung und Hochverfügbarkeit. Iona und Inprise bieten dagegen Produkte mit soliden Leistungsmerkmalen und umfangreicheren Services an.

Die unterschiedlichen Eigenschaften der Transaktions-Server werden im Folgenden an den Kriterien Objektvermittlung, Transaktions-Management, Messaging, Sicherheit und Systemverwaltung herausgearbeitet.

ObjektvermittlungGrundlegende Voraussetzungen für die Kommunikation verteilter Komponenten sind der Bindevorgang und die Aufrufvermittlung. Von ihnen hängt ganz wesentlich ab, wie flexibel sich aufrufende und aufgerufene Objekte zuordnen lassen. Neben der Verteilungstransparenz und der Unabhängigkeit vom Kommunikationsprotokoll spielen auch Mechanismen zur Lastverteilung eine bedeutende Rolle.

In Corba werden Objekte durch eine abstrakte Referenz (IOR) repräsentiert, deren Inhalt sich nur durch die Corba-Implementierung interpretieren lässt. Anwendungen können Objektreferenzen durch Umwandlung in eine Zeichenkette dauerhaft speichern (etwa in einer Datenbank oder Konfigurationsdatei), um das Zielobjekt zu einem späteren Zeitpunkt wieder zu kontaktieren. Objektreferenzen sind damit eine Art persistente Zeiger.

Um initiale Referenzen zu erhalten, stehen verschiedene Mechanismen zur Verfügung, etwa HTTP (Hypertext Transfer Protocol) bei einem Applet oder das verteilte Dateisystem im Intranet. In größeren Systemen kommt für diesen Zweck jedoch häufig ein Vermittlungsdienst zum Einsatz. Die OMG definiert dazu Schnittstellen (nach der Interface Definition Language, IDL) für die zwei Objektdienste Naming- und Trading-Service (siehe Abbildung "Naming und Trading").

Der Naming-Service ist ein einfacher Verzeichnisdienst, der einen hierarchisch strukturierten Namensraum verwaltet. Er erlaubt die Lokalisierung weiterer Objekte. Die Alternative, der Trading-Service, ermöglicht die Dienstsuche anhand von Eigenschaften und damit auch die Einbeziehung dynamischer Aspekte wie Warteschlangenlänge und Dienstgütemerkmale. Implementierungen des Naming-Service sind inzwischen überwiegend in der Grundausstattung von ORB-Produkten enthalten. Meist ist dies ein zentraler Server-Prozess, der seine Daten im Dateisystem verwaltet. Damit wird gewährleistet, dass der Anwendungsumgebung ein persistenter Namensraum zur Verfügung steht. Die Integration einer Datenbank oder spezieller Produkte (etwa auf Basis von X.500) ist in diesem Funktionsumfang nicht zu erwarten. Außer den Standard-Schnittstellen finden sich oft noch alternative proprietäre Erweiterungen.

Bei Inprise Application Server und Orbix OTM sind dies Proxy-basierte Bind-Mechanismen, die bereits vor der Umsetzung der Naming-Spezifikation angeboten wurden. Sie sind über zum Teil spezielle Funktionalität zugänglich, wie etwa die Lastverteilung mit den "Smart Agents" von Inprise oder dem "Locator" zur Zuordnung logischer Server-Namen zu Rechnern von Iona. "Orbix Names" bietet eine einfache Lastverteilungsoption: Einem Namenseintrag lässt sich eine Gruppe von Objekten zugeordnen, und es kann eine Strategie definiert werden, nach der aufeinander folgende Anfragen für diesen Namen eine Objektreferenz liefern. In der aktuellen Version des Inprise Application Server steht ein gemeinsamer Namensdienst für EJB und Corba zur Verfügung. Enthalten sind unter anderem eine flexible Datenbankanbindung (Pluggable Storage), Clustering und Lastverteilung von Objekten sowie erweiterte Fehlertoleranz (implizites Failover).

Hinsichtlich Skalierbarkeit und Lastverteilung etabliert "Weblogic Enterprise" mit dem "Session Konzentrator" ein richtungsweisendes Konzept zur impliziten Reduzierung benötigter Transportverbindungen. Mit dem Session Konzentrator kann in der Verbindung von Client- und Server-Prozessen das Verbindungsaufkommen auf Transportebene zwischen n Clients und m Servern von potenziell n*m auf n+m reduziert werden. In der Konsequenz bedeutet dies, dass sich durch die Delegation der Aufrufe (bei erhöhtem Kommunikationsaufwand) mehr Verbindungen zu einem Server-Rechner aufbauen lassen, ohne dass die maximale Anzahl von TCP-Verbindungen überschritten wird. Eine weitere Form der Lastverteilung wird durch Factory-basiertes Routing unterstützt. Über eine Factory erzeugte Server-Objekte lassen sich dabei anhand von Parametern auf verschiedenen Rechner platzieren.

Transaktions-ManagementMit dem Object-Transaction-Service (OTS) spezifiziert die OMG Schnittstellen für das Management flacher und (optional) geschachtelter verteilter Transaktionen in Corba-Umgebungen (vgl. Abbildung "Object-Transaction-Service"). Diese erlauben die Kooperation verteilter Objekte unter Zusicherung der Acid-Eigenschaften von Transaktionen. Danach sind Transaktionen atomar, sprich singulär, konsistent (im englischen mit c geschrieben), isoliert von anderen Transaktionen und im Ergebnis dauerhaft. Innerhalb der beteiligten Objekt-Server interagiert der OTS als Transaktions-Manager mit dem jeweiligen Ressourcen-Manager, im allgemeinen ein Datenbank-Management-System (DBMS), um eine Transaktion lokal zu steuern. Der OTS basiert mit dem Distributed Transaction Processing Model (DTP) der X/Open-Group auf einen etablierten Standard. Ressourcen-Manager werden über die XA-Schnittstelle eingebunden, die von allen in der Praxis wichtigen DBMS unterstützt wird.

Die Mehrzahl der Produkte basiert zudem auf einem Transaktionsmonitor. Bei Weblogic Enterprise ist das Tuxedo und "Transarc Encina" bei Orbix OTS. Inprise hat dagegen mit dem Integrated-Transaction-Service (ITS) eine Neuimplementierung vorgenommen. Am Markt agieren außerdem Drittanbieter wie etwa Hitachi, wo ein auf "TP Broker" basierendes Produkt für den "VisiBroker" verwendet wird.

Der OTS kann als dezentraler Transaktions-Manager in jedem Objekt-Server (in Form von Link-Bibliotheken) oder als ein dedizierter zentraler Server-Prozess realisiert sein. Letzterer Ansatz verspricht Vorteile bei der Konfiguration und Administration, stellt gleichzeitig aber auch einen potenziellen Single Point of Failure dar. Der ITS enthält beide Varianten und kann auch gemischt eingesetzt werden. Dagegen sind Orbix OTS und Weblogic Enterprise rein dezentrale Lösungen (auch bezüglich Logging und Recovery). Bei Iona muss abweichend vom Standard noch eine proprietäre Schnittstelle im Modul Orbix OTS für die Initialisierung des Transaktions-Managers im Client benutzt werden.

Server-seitig lassen sich an Orbix OTS alle gängigen Datenbanken anbinden. Bei der Initialisierung des Objekt-Servers wird die XA-Schnittstelle des jeweiligen Ressourcen-Managers explizit angemeldet. Damit besteht keine Abhängigkeit zwischen OTS und Datenbankprodukt. Der Anwender kann so theoretisch jedes XA-konforme System benutzen.

Demgegenüber wird bei ITS diese Integration bereits durch den OTS vorgenommen. Einerseits verhindert dies potenzielle Abstimmungsprobleme mit der Datenbank, andererseits sind aber auch nur bestimmte Produkte und sogar Versionen einsetzbar - gegenwärtig Oracle 7.3 und Sybase 11. Dank der engen Kopplung bietet ITS jedoch mit dem Pooling von Datenbankverbindungen und einer per Konfiguration auf einen PC optimierbaren Transaktionssteuerung zwei Spezialitäten, die sich zur Leistungssteigerung nutzen lassen.

Bei Weblogic Enterprise verschmelzen ORB und Tuxedo durch das auf den Portable-Object-Adapter aufgesetzte Framework zur Objektimplementierung. Damit ist die Transaktionsfähigkeit gegeben. Das Laufzeitverhalten der Objekte ist konfigurierbar. So lässt sich die Vorschrift für die Zuordnung eines Transaktionskontexts durch das Framework und die Aktivierungsstrategie von Server-Objekten festlegen. Grundsätzlich ist auch ein Zugriff auf die von Tuxedo her bekannten Mechanismen möglich, etwa für das Pooling von Datenbankverbindungen.

MessagingStandardmäßig erfolgen Corba-Aufrufe synchron und blockierend. Das Kommunikationsmodell impliziert durch Verwendung von Objektreferenzen eine enge Kopplung zwischen aufrufendem und aufgerufenem Objekt. Applikationen können jedoch auch etwa bei ereignisgesteuerten Szenarien asynchrone Interaktionen und eine schwache Kopplung zwischen Komponenten erfordern. Eine Realisierung auf Basis des synchronen Modells verlangt in solchen Fällen zusätzliche Mechanismen auf Anwendungsniveau wie Threads oder Queues. Eine Unterstützung von Messaging sieht Corba mit dem IDL-Schlüsselwort "oneway" und verzögerten synchronen Aufrufen vor. Diese heben jedoch nicht die enge Kopplung der Interaktionspartner auf.

Der Event-Service erlaubt die (anonyme) Kommunikation eines Erzeugers (Supplier) mit einer beliebigen Anzahl von Verbrauchern (Consumer), die über einen Eventchannel verbunden sind (vgl. Abbildung "Ereigniskanal"). Ereignisse werden nach dem Push- oder Pull-Modell vermittelt und können typisiert oder generisch sein. Die Anwendung des Event-Service gestaltet sich recht einfach, da Eventchannel selbst als Objekte über die IDL-Schnittstelle angesprochen und auch im Vermittlungsdienst registriert werden können. Die meisten Hersteller bieten außer dem ORB auch eine Implementierung des Event-Service an. In der Regel wird dieser in einem eigenen Server-Prozess ausgeführt, unterstützt das häufiger benötigte Push-Modell mit generischen Events und stützt sich auf den synchronen Kommunikationsmechanismus über das Internet Inter-ORB Protocol (IIOP).

Zu beachten sind allerdings einige Einschränkungen: Die persistente Speicherung der Verbindungen oder über die Semantik des Standardaufrufs hinausgehende Zusagen für die Ereignisübermittlung sind nicht spezifiziert und gehören auch nicht zum Leistungsumfang einfacher Implementierungen. Die Verwendung von IIOP bedingt die Zustellung eines Ereignisses durch einen separaten Aufruf an jeden am Eventchannel registrierten Consumer, was in größeren Systemen die Skalierbarkeit begrenzen kann. Iona unterstützt mit dem alternativen Produkt "OrbixTalk" außer einer effizienten Kommunikation per IP-Multicast durch einen Message Store die sichere und garantierte Übermittlung von Ereignissen auch bei Kommunikationsfehlern.

Die Schnittstelle des Event-Service überstellt alle Ereignisse immer an alle registrierten Empfänger, eine Selektion durch den Eventchannel ist nicht möglich. Es sind auch keine Dienstgüteparameter etwa für die maximale Dauer oder Zuverlässigkeit der Übertragung vorgesehen. Dieses Problem soll die Spezifikation des Notification-Service beheben. Inzwischen sind auch Implementierungen am Markt verfügbar (zum Beispiel. von Bea und Iona), die vielen Anwendungen eine geeignete Infrastruktur bieten dürften. Bea bietet ab der Version 5.1 einen Event- und Notification-Service, mit dem sich Queues und Publish- und Subscribe-Verfahren unter Quality-of-Service Control entsprechend Corba 3 realisieren lassen. Ein Ereignis wird also garantiert nur einmal ausgeliefert.

Für zukünftige Entwicklungen wird auch die Messaging-Spezifikation der OMG interessant sein, die eine Integration alternativer Aufrufmechanismen (asynchron und zeitunabhängig) im Standardumfang von Corba vorsieht.

SicherheitDie OMG hat für den Bereich Sicherheit vier relevante Spezifikationen erstellt:

-den Objektdienst Security,

-die Integration mit dem Kommunikationsprotokoll unter Wahrung der Interoperabilität (SecIOP),

-eine Integration von IIOP mit den Secure Socket Layers (SSL) sowie

-einen Standard für Firewalls.

Der sehr umfangreiche Security-Service betrifft die Bereiche Authentifikation, Autorisierung, Auditing und Verschlüsselung von Anwendungsdaten. Dabei orientiert sich die Spezifikation an existierenden Technologien wie Kerberos und DCE-Security (Data Communications Equipment). Es werden zwei Sicherheitsstufen unterschieden: Level 1 Security für den (impliziten) Einsatz in Anwendungen mit geringen Anforderungen an die Sicherheit und Level 2 mit expliziten Schnittstellen für die verschiedenen Techniken.

Zum Grundumfang der existierenden Implementierungen zählt die Unterstützung von SSL, die in der IIOP-Implementierung auf TCP/IP aufgesetzt wird. Auf diese Art lässt sich durch Konfiguration des ORB die Kommunikation auf den Sicherheitsstandard aus dem Internet-Bereich heben, ohne am übrigen System Änderungen vornehmen zu müssen. In vielen Unternehmen wird eine Firewall benutzt, um Intranet-Ressourcen vor unbefugten externen Zugriffen zu schützen. Die gängigen Produkte bieten allerdings meist noch keine Unterstützung für IIOP. Um entsprechende Dienste, zum Beispiel durch ein Corba- oder Java-Applet, offerieren zu können, wird in der Regel ein bestimmter Port am Firewall der Behandlung eines dedizierten IIOP-Proxys (wie "Wonderwall" von Iona und "Gatekeeper" von Inprise) überlassen. Diese werden dann durch Techniken wie HTTP-Tunneling oder Proxifizierung von Objektreferenzen automatisch in die IIOP-Kommunikation eingeschaltet und überwachen den Zugriff nach verschiedenen Kriterien: Client-Rechner, Zielobjekt, bestimmte Operationen einer IDL-Schnittstelle etc. Mit der Spezifikation durch die OMG sollen diese derzeit herstellerspezifischen Lösungen auf einen gemeinsamen Nenner gebracht werden.

SystemverwaltungFür den geordneten Produktionsbetrieb eines verteilten Systems werden Mechanismen zur Integration, Konfiguration und Administration der verschiedenen Komponenten benötigt. Die Standards der OMG berücksichtigen dies bis jetzt noch nicht. Entsprechend unterschiedlich stellt sich der Leistungsumfang der auf dem Markt verfügbaren Produkte dar. Durchgängig anzutreffen sind kommandozeilenbasierte Werkzeuge, mit denen einzelne Objekt-Server verwaltet werden können. In der Regel steht dafür auch eine grafische Oberfläche zur Verfügung.

Bei verteilten Transaktionen ist im Störfall ein einfacher zentraler Zugang für den manuellen Eingriff wichtig. Die beteiligten Prozesse und Logfiles sollten schnell auffindbar und der Transaktionsstatus leicht korrigierbar sein. Einen vollständigen Ansatz verfolgt Inprise: Neben der Entwicklungsumgebung (JBuilder) lassen sich mit dem Appcenter unter einer Oberfläche alle mit der Verteilung und Verwaltung der Komponenten anfallenden Aufgaben erledigen. Der ITS-Administrator erlaubt eine komfortable Konfiguration von Verbindungsprofilen für den Datenbankzugriff, die Überwachung laufender Transaktionen sowie das Einrichten, Anzeigen und Filtern des Transaktions-Logs. Gerade bei dezentralen Transaktions-Managern ist dies nicht selbstverständlich, wie sich bei Orbix-OTM mit dem Programm "Otsadmin" zeigt. Weblogic Enterprise kann über eine grafische Konsole von einem zentralen Rechner administriert werden. Zur Laufzeit lassen sich weitere Prozesse starten und die Session-Konzentratoren sowie die Objektaktivierung und Lastverteilung konfigurieren.

Literatur:

-Jeri Edwards: "Making Objects Mission-Critical. The Bea M3 Object Transaction Manager", Bea Systems Inc., 1998

-Karen Boucher; Fima Katz: "Essential Guide to Object Monitors", Whiley, 1999

-Peter Mandl, Thomas Weise: "Verteilte Transaktionsverarbeitung auf Basis von Corba", in "Objektspektrum" 01/2000

-Object Management Group: "Corbaservices: Common Object Services Specification", Revised Edition 1995, Updated Nov. 1997 (http://www.omg.org/library/)

-Dirk Slama, Jason Garbis, Perry Russel: "Enterprise Corba", Prentice Hall, 1999

*Thomas Springer promoviert an der TU Dresden am Lehrstuhl von Prof. Schill. Seine Arbeitsgebiete sind Mobile Computing, Middleware und mobile Agenten.({springet,schill}@rn.inf.tu-dresden.de)

Thomas Weise ist tätig in der technischen Beratung und Entwicklung im Bereich verteilte objektorientierte Systeme.(tweise@lycosmail.com).

Die untersuchten ProdukteDie am Markt verfügbaren Produkte variieren im Rahmen der nicht durch das Standardisierungsgremium Object Management Group (OMG) spezifizierten Bestandteile.

Bea Weblogic Enterprise: Mitte 1998 brachte Bea Systems für den Corba-Bereich mit "M3" einen ORB und einige Objektdienste auf Basis des Transaktionsmonitors "Tuxedo" auf den Markt. Anfang 1999 wurden diese Komponenten mit der EJB-Plattform zusammengeführt und seitdem in der Produktreihe "Bea Weblogic Enterprise" vermarktet - aktuell in der Version 5.1.

Inprise Application Server: Die Software ist seit Mitte 1998 erhältlich und basiert auf der Java- beziehungsweise C++-Version des ORB "Visi Broker". Neben der Corba-Infrastruktur mit den wichtigsten Objektdiensten wird eine umfassende Unterstützung der Enterprise-Java-Standards geboten. Aktuell die Version 4 des Inprise Application Server.

Orbix-OTM: Iona bietet seit Ende 1997 unter der Bezeichnung "Orbix-OTM" - aktuelle Version 3 - ein Paket aus dem ORB "Orbix/C++" sowie verschiedene Objektdienste und Administrationswerkzeugen an. Seit kurzem werden mit "Orbix 2000" und dem "iPortal Application Server" nun auch Corba 2.3 und der EJB-Standard auf Basis der Corba-Infrastruktur unterstützt.

Abb.1: Naming und Trading

Der Naming-Service findet Dienste in der Art eines hierarchischen Verzeichnisdienstes, während der Trading-Service sie anhand von Eigenschaften ermittelt. Quelle: OMG

Abb.2: Objekt-Transaktion

Der Object-Transaction-Service steuert gemeinsam mit dem Ressourcen-Manager, in der Regel ein Datenbanksystem, die Transaktionen und sorgt für die Einhaltung grundlegender Transaktionsregeln. Quelle: OMG

Abb.3: Der Ereigniskanal

Das Messaging über den Eventchannel dürfte sich verändern, wenn die OMG die Corba-Spezifikationen um asynchrone und zeitunabhängige Aufrufmechanismen ergänzt. Quelle: OMG