Ab Mitte der 90-er Jahre begann sich die Corba-Technologie im industriellen Umfeld zu etablieren. Corba bildet heutzutage die Basistechnologie für eine Vielzahl von geschäftskritischen Anwendungen. Typischerweise erfolgt die Implementierung der Softwarekomponenten im Applikations-Server in C++; der Client-Zugang wird meist in Form von Java-Applikationen oder Applets auf Basis von Internet-Inter-ORB-Protocol (IIOP) umgesetzt.

Mittlerweile ist das Zeitalter des E-Business angebrochen. Neben der traditionellen Nutzung der Geschäftsanwendungen im internen Bereich ist die Anbindung an das Internet Gebot der Stunde. Themen wie HTTP, Web-Server, Servlets und Java Server Pages (JSP) wurden zur Selbstverständlichkeit und bilden die technologische Grundlage für eine Vielzahl von Internet-Anwendungen. Sun setzte mit der Einführung von J2EE hierfür einen signifikanten Industriestandard.

Die GemeinsamkeitenEs gibt inzwischen verschiedene Möglichkeiten, ein Enterprise Application Integration (EAI) mit Corba und J2EE vorzunehmen. Die größten Gemeinsamkeiten beider Systemarchitekturen bestehen in der Bereitstellung von Infrastrukturdiensten. Zu nennen sind hier primär technische Basisfunktionalitäten wie etwa Transaktions-Management, Namensdienst, Verteilungstransparenz und asynchrone Kommunikation (Messaging). Eine Stärke von Corba liegt in der Unabhängigkeit von Programmiersprachen. Corba-Komponenten können etwa in C++ implementiert werden, deren Nutzung beispielsweise in einer Java-Umgebung (Java-Applet oder Applikation) möglich ist.

Die klaren Vorteile des J2EE-Ansatzes sind in den folgenden Bereichen zu sehen: Standardisierung von Internet-Technologien (Servlets und Java Server Pages), Bereitstellung einer Vielzahl von genormten Infrastrukturdiensten, flexible Konfigurierbarkeit von Komponenten und Verfügbarkeit durchgängiger Entwicklungsumgebungen. Auch wenn derzeit Produktreife und Qualität der führenden Corba-Implementierungen höher einzuschätzen sind (Stichwort: Fortschreibung der EJB-Spezifikation), ist davon auszugehen, dass im Laufe dieses Jahres die wichtigsten J2EE-Implementierungen nachziehen werden. Zudem muss man beachten, dass es noch keine kommerzielle Implementierung der Corba-Components-Spezifikation gibt, die erstmals ein standardisiertes Komponentenmodell für Corba-Anwendungen festlegt.

Die im Folgenden dargestellten Szenarien unterscheiden sich in erster Linie durch zwei Annahmen: Wie zum einen die Verteilung von Anwendungskomponenten auf die beiden Plattformen Corba und J2EE erfolgt und zum anderen das Kommunikationsmuster zwischen den Komponenten aussieht. Im ersten Fallbeispiel dominiert die J2EE-Umgebung: Die Corba-Umgebung nimmt die Rolle eines Legacy-Systems ein. Der Betrieb von ausgewählten Corba-Komponenten in einer J2EE-Umgebung ist Kern des zweiten Szenarios. Schließlich wird die volle Integration und Interoperabilität beider Plattformen betrachtet.

J2EE-dominiertes SzenarioZum ersten Fall: Dieser Handlungsentwurf orientiert sich an dem J2EE-Anwendungsmodell (vgl. http://java.sun.com/j2ee/blueprints). GUI-Anwendungen werden entweder Browser-basierend oder als Java-Applets beziehungsweise Applikationen realisiert, die mittels Servlets/JSP oder Remote Method Invocation (RMI) mit den EJB-Komponenten kommunizieren. Die Implementierung der Prozesssteuerung erfolgt meist auf Basis des Model-View-Control-Ansatzes im Zusammenspiel von Servlets/JSP und entsprechenden Session Beans. Das dem Anwendungssystem zugrunde liegende Geschäftsmodell wird auf Basis von Enterprise Javabeans (EJB) umgesetzt: Entity Beans implementieren die imBusiness Object Model vorkommenden fachlichen Typen wie Organisationen (beispielsweise Institut, Filiale oder Geschäftsbereich) oder Ressourcen (etwa Vertrag, Konto oder Kunde). Serviceorientierte Dienstleistungen werden auf Basis von Session Beans implementiert. Diese kapseln typischerweise (die fein-granularen) Entity Beans und stellen höherwertige Dienste bereit.

Aus Sicht von J2EE nimmt die Corba-Umgebung die Rolle einer externen Anwendung ein. Die Corba-Komponenten übernehmen häufig folgende Aufgaben:

-Kapselung weiterer Systeme: Vor allem im Finanz- und Versicherungsbereich wurden in den vergangenen Jahren Corba-Komponenten entwickelt, die fachliche Dienstleistungen von Mainframe-basierten Anwendungssystemen (etwa CICS- oder IMS-Transaktionen) kapseln. Dies wird auch künftig so sein.

-Service-Dienstleister: Nutzung vorhandener und ausgereifter Funktionalitäten, die über eine Corba-Schnittstelle verfügen.

Aufgabenteilung im GesamtsystemDas vorliegende Szenario findet man vor, wenn eine mehr oder weniger vollständige Web-Applikation gekauft oder selbst entwickelt wurde, die auf unternehmensweiteDaten beziehungsweise Dienstleistungen zugreifen muss. Liegen im Unternehmen bereits ausgereifte Corba-Komponenten vor, welche die hierfür notwendigen Funktionalitäten mitbringen, liegt es nahe, diese auch zu nutzen. Es ergibt sich eine klare Schichtung und Aufgabenteilung zwischen J2EE- und Corba-Teil des Gesamtsystems. Das J2EE-System nimmt die Rolle einer (gewöhnlichen) Corba-Client-Applikation ein. Die technische Kommunikation erfolgt mittels IIOP auf Basis einer uni-direktionalen Aufrufbeziehung von der J2EE-Anwendung zu den Corba-Komponenten. Eine performante und hochverfügbare Anbindung zwischen beiden Plattformen kann durch die Nutzung von IIOP Connection Pools erfolgen.

Das zweite Szenario, also Corba-Komponenten innerhalb von J2EE, lässt sich folgendermaßen beschreiben: In Corba-Anwendungsarchitekturen werden häufig Komponenten eingesetzt, die sich aus einer Client- und einer Server-Personality zusammensetzen (siehe Abbildung). Die Rolle der Client-Personality besteht darin, den Client-Stub der Corba-Komponente zu kapseln und eine höherwertige Schnittstelle bereitzustellen. Typischerweise werden Client-Personalities für GUI-Applikationen entworfen, die zum einen eine optimierte Datenübertragung (gekoppelt mit einem Client-seitigen Caching) erbringen und zum anderen die zugrunde liegende Kommunikationsinfrastruktur mit der Server-Personality kapseln. Die Implementierung der Server-Personality erfolgt in der Corba-Komponente auf dem Applikations-Server.

Ausgefeiltes Call BackSoll die Server-Personality der Client-Personality asynchron Nachrichten zukommen lassen (zum Beispiel die Signalisierung von bestimmten Zuständen oder die Terminierung von gestarteten Berechnungen auf dem Server), ist es erforderlich, dass in der Client-Personality selbst Corba-Objekte implementiert werden. Hierdurch ist es möglich, ausgefeilte Call-Back-Szenarien zwischen Server- und Client-Personality umzusetzen.

Client-Personalities mit in Java entwickelten Corba-Objekten können in einer J2EE-Umgebung betrieben werden. Die Grundidee des Ansatzes ist, dass J2EE eine Corba-Laufzeitumgebung mit sich bringt - nämlich die der Java-2-Plattform. In einem J2EE-Applikations-Server können somit EJB- wie auch Corba-Komponenten ablaufen.

Der Reiz dieses Ansatzes ist offensichtlich: Liegt eine Corba-Infrastruktur mit einer Komponentenarchitektur basierend auf Client- und Server-Personalities vor, können die wesentlichen Elemente und Fachkomponenten der Anwendungsarchitektur direkt wiederverwendet werden. Meist kann mit geringem technischen Aufwand die Einbettung einer Client-Personality in die J2EE-Umgebung erfolgen; eine Adaption der Server-Personality ist nicht erforderlich. Da sich die Client-Personality wie auch deren Nutzer (zum Beispiel Session Beans) innerhalb einer Java-Laufzeitumgebung betreiben lassen, ist keine Prozess-übergreifende Kommunikation für den Zugang zur Client-Personality notwendig.

Mehr EntwicklungsfreiheitDie volle Integration und Interoperabilität beider Plattformen zeichnet sich dadurch aus, dass Teile des Geschäftsmodells unter J2EE und Corba implementiert werden. Bei der Komponentenentwicklung hat man die Freiheit, entweder das EJB-Modell und Java oder den Corba-Ansatz und C++ beziehungsweise Java zu nutzen. Diese Freiheiten können zum eigenen Vorteil umgemünzt werden, wenn etwa in den Implementierungsteams unterschiedliche Skill-Profile (zum Beispiel erfahrene Java- und C++-Entwickler) vorhanden sind. Ferner können innovative Produkte wie Arcstyler eingesetzt werden, welche die architekturgetriebene und modellbasierende Anwendungsentwicklung in allen Phasen des Entwicklungsprozesses unterstützen.

Liegt eine hohe Mischung von EJB- und Corba-Komponenten vor, ist es empfehlenswert, einen Applikations-Server einzusetzen, der eine einzige Laufzeitumgebung für den Betrieb von EJB- und Corba-Komponenten bereitstellt. Dies bringt nicht nur Vorteile in Bezug auf das Transaktions-Management und die Laufzeit-Performance (insbesondere bei der intensiven Nutzung von Call-Back-Mechanismen), sondern ermöglicht die Administration der Laufzeitumgebung (beispielsweise Deployment und Restart von Komponenten, Failover oder Lastverteilung) mit einem Werkzeug. Dies ist gerade für den Betrieb von skalierbaren, stark verteilten Anwendungssystemen von unschätzbarem Wert.

Fazit: In Bezug auf den Einsatz von J2EE und Corba muss es kein Entweder-oder geben. Obwohl beide Technologien vom Grundsatz her recht ähnlich sind, bringt jede Plattform spezifische Stärken mit sich. Wie sich diese koppeln lassen, hängt von den Voraussetzungen in den IT-Abteilungen ab - den einen, richtigen Ansatz gibt es nicht.

*Dr. Bernhard Hollunder leitet den Bereich Architectural Services bei der Interactive Objects Software GmbH in Freiburg (hollunder@io-software.com).

Eigenschaften, Stärken und Defizite

/ Corba / J2EE

Infrastrukturdienste (Persistenz, Transaktions-Management, Messaging, Verteilungstransparenz, Naming, Anfragesprache etc.) / Festlegung durch die Corba-Spezifikation und Object Services / Festlegung in den EJB-, JMS- und JNDI-Spezifikationen

Implementierungssprache für Server-Komponenten / C++, Java, C und weitere / Java

Komponentenmodell und Festlegung verschiedener Komponententypen / erst mit Corba Components - Service Components - Session Components - Process Components - Entity Components / Enterprise Javabeans (EJB) - Session Beans - Entity Beans - Message-driven Beans

Internet-Technologien und Web-Zugang / nicht spezifiziert / Servlets, Java Server Pages (JSP)

Kommunikationsprotokoll / IIOP / RMI über IIOP

Produkte / hohe Stabilität und Reife der wichtigsten Implementierungen / Konsolidierungsphase steht an

Durchgängige Entwicklungsumgebungen / sehr geringe Verfügbarkeit / Produktmarkt entsteht, zum Beispiel Arcstyler (http://www.Arcstyler.com)

Anbindung beziehungsweise Integration weiterer Technologien / meist produktspezifisch / hohe Abdeckung durch die J2EE-Spezifikation (JDBC, Javamail, Connector Architecture)

Konfigurierbarkeit der Anwendung / proprietäre Lösungen; Standardisierung erst durch Corba Components / Standardisierung von Deployment-Deskriptoren für Web- und EJB-Komponenten.

Abb: Nischenarchitektur mit J2EE und Corba

Nutzung von EJB- und Corba-Komponenten in einem J2EE-Applikations-Server: Client-Personalities mit in Java entwickelten Corba-Objekten können in einer J2EE-Laufzeitumgebung betrieben werden. Quelle: Interactive Objects Software