EJB CORBA

Dieser Artikel ist im JavaMagazin 4/00 erschienen. Vielen Dank an den Software & Support Verlag für die Genehmigung zur Veröffentlichung auf dieser Webseite!

J2EE-Applikationsserver im Überblick

Zurück in die Zukunft

Lange Zeit führten Applikationsserver ein Schattendasein. In den letzten Jahren gab es aber enorme Fortschritte in den Technologien und deren Standardisierung. Vor allem der Erfolg des Internets zwingt viele Unternehmen, ihre alten Geschäftsmodelle aufzubrechen und neue Wege zu gehen.
In Großunternehmen, aber auch im Mittelstand ist in vielen Jahren eine sehr heterogene Systemlandschaft entstanden. Die Integration dieser Plattformen ist sowohl für interne, für Business-to-Business- als auch für endkundenbezogene Anwendungen Voraussetzung für den Erfolg.
Da kam Java als plattformunabhängige Plattform gerade richtig. Zunächst stand die Sprache im Vordergrund, die vom Palmtop bis zum Großrechner verfügbar ist. Mit den zahlreichen Erweiterungen für die Einbeziehung von Standardprotokollen und -diensten, die in der Java 2 Enterprise Edition gipfelten, ist Java nun auch reif für die Entwicklung von unternehmenskritischen Serveranwendungen.

Abbildung 1: Java 2 Enterprise Edition

Application Server helfen bei der Entwicklung und dem Betrieb von Serveranwendungen. Sie bieten Dienste wie Security, Naming, Transaktionen oder Load Balancing, die vom Anwendungsentwickler nicht mehr explizit berücksichtigt werden müssen. Der Programmierer kann sich auf die fachliche Logik konzentrieren und nutzt nur die standardisierten Schnittstellen. Code für die Anpassung an die reale Systemlandschaft ("glue logic") wird meist nur noch generiert. Dies beschleunigt die Anwendungsentwicklung, reduziert die Fehlerquellen und vereinfacht den Austausch der Systemkomponenten.

Applikationsserver

Applikationsserver bieten ihren Clients Dienste an, in der Regel wickeln diese Server auch den Zugriff auf die Datenbestände ab.

Abbildung 2: Beispiel Mailserver

Ein Beispiel ist ein Mailserver. Dieser bietet seinen Nutzern Postfächer an und erlaubt die Übertragung von Nachrichten zu anderen Mailservern. Dazu verwendet er ein Protokoll. Dabei können für unterschiedliche Zwecke auch verschiedene Protokolle eingesetzt werden, zum Beispiel zwischen Mailservern SNMP und zwischen Mailserver und Clients POP3 oder IMAP. Wichtig ist hier eine Kompatibilität bzw. Standardisierung.
Der Marktdruck durch das Internet hat im Mailbereich bereits dafür gesorgt, dass viele proprietäre Protokolle fallengelassen wurden und fast jeder PC-Nutzer dem anderen eine Mail schreiben kann, egal welches Betriebssystem oder Mailprogramm er einsetzt.

Ein Vorreiter im Bereich der Applikationsserver ist Lotus Notes, eine verteilte Dokumentendatenbank mit Workflow- und Mailfunktionalität. Notes besitzt interessante Ansätze zur verteilten Datenhaltung, -replikation und automatischen Arbeitsabläufen (mittels Agenten), allerdings krankte es lange Zeit an Standardschnittstellen, die erst in jüngerer Zeit nachgerüstet wurden.

Standardisierungen und J2EE

Die meisten Serveranwendungen haben immer wieder die gleichen Anforderungen: Transaktionsunterstützung, Datenbankanbindung, Namensauflösung, Zugriffskontrolle, Austausch strukturierter Daten usw. Den dazu notwendigen Programmcode schreibt man selten selbst, sondern benutzt fertige Lösungen wie z.B. einen Transaktionsmonitor, einen Verzeichnisdienst, RPC-Implementierungen. Nur leider haben all diese Systeme völlig unterschiedliche Programmierschnittstellen und unterstützen oft kein Java.

Die Lösung dieses Problems stellt die Java 2 Enterprise Edition (J2EE) von Sun dar. Dies ist kein Produkt, sondern eine Sammlung von Programmierschnittstellen,
die durch einen Applikationsserver implementiert werden müssen. Durch Suns geschicktes Marketing und den großen Konkurrenzdruck sind nun die Anbieter von
Middleware und Datenbanken gezwungen, ihre proprietären Ansätze zurückzustellen und auf den neuen Standard zu setzen.

Als Basisinfrastruktur der Applikationsserver dienen CORBA und Enterprise Java Beans. Daneben enthält die J2EE-Spezifikation Schnittstellen für die Implementierung der Dienste von CORBA und EJBs (Transaktionsdienst, JDBC, JNDI, RMI) sowie zur Generierung dynamischer Webinhalte (Servlets und JSPs).

Der Nutznießer der Standardisierung ist der Anwender, in diesem Falle der Entwickler. Er hat nun die freie Auswahl zwischen auswechselbaren und zueinander (mehr oder weniger) kompatiblen Systemen. Wodurch differenzieren sich die Applikationsserver?

Keiner will die bestehenden Systeme auf einen Schlag ablösen und von Grund auf die alle unternehmenskritischen Anwendungen neu schreiben. Deshalb ist eine Integration bestehender System wichtig. Für Altsysteme müssen Adapter geschrieben werden, damit sie in die neue Infrastruktur eingebunden werden können.
Weiterhin ist eine hohe Verfügbarkeit und ein guter Durchsatz wichtig. Deshalb ist eine skalierbare Architektur notwendig. Das bedeutet einerseits, dass der Applikationsserver nicht auf einen physischen Rechner beschränkt sein sollte, sondern als Cluster aufgebaut werden kann, das sich auch über mehrere Lokationen hinweg erstrecken kann. Andererseits sollte das Produkt auch auf verschiedenen Plattformen zur Verfügung stehen, um bei Bedarf zum Beispiel vom
Windows-Server zur UNIX-Mehrprozessormaschine migrieren zu können.

CORBA

Abbildung 3: CORBA-Architektur

Die erste Infrastrukturalternative ist CORBA. Dieser OMG-Standard stellt einen Software-Bus zur Verfügung und spezifiziert eine Reihe von Diensten. Die Spezifikation beschreibt exakt die Schnittstellen, so dass darauf aufsetzende Software unabhängig vom jeweiligen Produkt geschrieben werden kann. Leider war der Standard vor allem in früheren Versionen unterspezifiziert, so dass viele Implementierungen untereinander inkompatibel sind. Auch gibt es oft viele verschiedene Alternativen zur Nutzung von Diensten und kein vorgegebenes Entwicklungsmodell, so dass es bei der Entwicklung zu Problemen kommen kann.

CORBA ist schon relativ lange auf dem Markt und es gibt eine ganze Reihe ausgereifter Implementierungen der Basisinfrastruktur und der Dienste. Java ist dabei eine der wichtigsten Implementierungssprache sowohl für die Client- als auch für die Serverseite, es sind jedoch auch andere Programmiersprachen möglich. Die aktuelle Version ist 2.3, in Ausarbeitung befindet sich Version 3 des Standards, die die angesprochenen Kritikpunkte adressiert.

Enterprise Java Beans

Abbildung 4: EJB-Architektur

Die zweite Alternative sind Enterprise Java Beans (EJBs). Diese reine Java-Architektur orientiert sich von der Architektur her an CORBA. Sie vereinfacht jedoch die Programmierung und fügt ein Rollen- und Vorgehensmodell
hinzu. Ein kleiner Satz an Diensten ist fest vorgeschrieben. EJB ist jedoch ein junger Standard, aktuell ist Version 1.1, der in den meisten Großunternehmen noch in der Erprobungsphase ist. Viele Produkte haben noch nicht dieselbe Reife wie im CORBA-Bereich. Dennoch gibt schon ein ganze Reihe leistungsfähiger Implementierungen, die Hersteller von ORBs und objektorientierten Transaktionssystemen auf Basis ihrer bestehenden Produkte entwickelt haben.

Die Anbieter

Anbieter von EJB- und CORBA-Applikationsservern sind in der Regel etablierte Middleware- oder Datenbankhersteller, die durch Eigenentwicklung oder Zukauf
von Technologien und Firmen in diesen neuen Markt mit großem Wachstumspotential drängen.
Sun Microsystems vereint gleich drei Server im neuen Produkt iPlanet Application Server. Neben dem eigenen NetDynamics kamen durch die Allianz mit Netscape und durch den Aufkauf von Forté zwei weitere hinzu, die in diesem Jahr integriert werden sollen.
BEA ist als Hersteller des Transaktionssystems Tuxedo bekannt. Durch Aufkauf der Firma WebLogic mit deren Produkt Tengah, einem Pionier auf dem Gebiet der EJB-Server, bekam BEA Zugriff auf einen Java-Applikationsserver und entwickelt ihn konsequent in Richtung der Java 2 Enterprise Edition weiter.
Oracle ist Marktführer bei den relationalen Datenbanken und bietet mit seiner Architektur des Oracle Application Server mit Applikationserweiterungen (Cartridges) eine Lösung an, die ebenfalls in Richtung Java 2 Enterprise Edition (J2EE) strebt.
IBM vereint sein Know-how aus dem Transaktionsumfeld (CICS, Encina) und dem Datenbankbereich (DB2/UDB) mit dem CORBA-Produkt ComponentBroker im WebSphere Application Server. Dieser dient als Container für EJBs und als ORB, sowie als Laufzeitumgebung für Servlets und JSP, eine volle Unterstützung von J2EE ist jedoch erst mit Version 4.0 vorgesehen.
Borland /Inprise ist mit dem VisiBroker einer der Marktführer im Bereich ORBs und bietet ebenfalls einen Applikationsserver an. Leider bekamen wir aber auf Anfrage keine weiteren Informationen, so dass dieser Server in unserem Vergleich fehlt. Borlands Hauptkonkurrent im Bereich CORBA ist Iona, die vor kurzem ebenfalls einen neuen Applikationsserver namens iPortal vorgestellt haben.

Newcomer gibt es viele in diesem heiß umkämpften Markt. Einer der erfolgreichsten ist die Firma Silverstream, die schon früh einen Java-basierten
Applikationsserver anboten, der mittlerweile in der Führungsgruppe derjenigen ist, die den J2EE-Standard erreichen wollen.

Vergleich

Der Trend ist klar erkennbar. Fast alle Produkte streben auf eine Unterstützung der J2EE-Plattform hin oder haben die noch sehr junge Spezifikation (12/99) schon erfüllt. Eine endgültige Zertifizierung ist jedoch erst dann möglich, wenn Sun die entsprechenden Testsuiten freigibt. Besonders weit fortgeschritten sind BEA WebLogic und der Silverstream Application Server. IBM hingegen hält die Spezifikation für zu aufgeblasen und möchte nur Teile implementieren. Dies ist verwunderlich, denn die Firma hatte selbst großen Anteil an der EJB-Spezifikation, die sehr ähnlich zu dem schon vor der Spezifikation existenten ComponentBroker ist. Vielleicht schreckt IBM jedoch auch nur das Lizensierungsmodell von Sun ab, bei dem kein klares Konzept zu erkennen ist. Zunächst hatte Sun ja Lizenzgebühren für Java verlangt, wollte die Sprache aber durch ein internationales Gremium standardisieren lassen. Nun zogen sie den Standardisierungsvorschlag wieder zurück, lassen die Gebühren für die Standard Edition fallen, für die Enterprise Edition sollen die Lizenznehmer jedoch wieder zahlen...

Im CORBA-Bereich sind 2.2 bzw. 2.3 state of the art. Richtig spannend wird es wieder, wenn die Version 3 des Standards verabschiedet wird, denn diese bringt einige Neuerungen, zum Beispiel ein Komponentenmodell und die Einbeziehung von EJBs.

Plattformen

Von der Leistung und der Skalierbarkeit sind derzeit Unix-Server am interessantesten. Kein Wunder, dass alle Anbieter ihre Server für verschiedene Dialekte anbieten, zum Beispiel Solaris, AIX, UP-UX, aber auch Linux ist im Kommen. Windows NT ist bei allen im Angebot.
Wer den Applikationsserver direkt am Host laufen lassen möchte, ist mit IBM WebSphere und BEA WebLogic gut bedient. Für ein Unternehmen mit starken Mainframes ist dies durchaus interessant, da hier der Netzwerktraffic reduziert wird, baugleiche Applikationsserver (z.B. am Host mit Datenbankzugriff und am Webserver mit der Outputgenerierung) direkt miteinander kommunizieren können und damit Strategien zum Performancetuning leicht aufeinander abgestimmt werden können. Wer hingegen weg von der Verarbeitung vom Host will oder Angst davor hat, dass neue Sprachen (Java) und Protokolle (z.B. TCP/IP, IIOP) am Großrechner eingesetzt werden oder gar direkte Zugriff aus dem Intranet/Internet erfolgen, der ist mit einer separaten Schicht 2 z.B. auf einem Unix-Cluster besser bedient.

Persistenz

Die dauerhafte Speicherung der Objektzustände erfolgt in Datenbanken. Dies können relationale Datenbanken sein, aber auch Legacy Systeme wie IMS oder Adabas. Java stellt mit JDBC einen Standard zum Zugriff auf relationale Datenbanken zur Verfügung. Dies reicht in der Regel aber nicht aus, denn die Daten können sich über mehrere Datenbanken hinweg erstrecken. Selbst wenn in die Daten in einer der Datenbanken erfolgreich geschrieben werden können, muss diese Aktion rückgängig gemacht werden, wenn in einer anderen Probleme auftreten. Dies adressiert erst JDBC 2.0, für das es aber kaum Treiber gibt. Außerdem ist das Mapping von Objekten auf eine flache Tabellenstruktur eine schwierige Aufgabe. Diese Probleme lösen so genannte Persistenzframeworks. Die meisten Applikationsserver bringen diese selbst mit, andere setzen auf Produkte von Fremdherstellern, zum Beispiel TopLink von The Object People (seit kurzem von BEA aufgekauft).

Transaktionen

Sun hat mit JTS (Java Transaction Service) eine Schnittstelle zum Zugriff auf Systeme zur Transaktionssteuerung definiert. Mit einem Transaktionssystem wird sichergestellt, dass ein Aufruf entweder komplett oder gar nicht durchgeführt wird, es vermeidet somit inkonsistente Zustände. Konkurrierende Aufrufe werden gegeneinander abgeschirmt. Das Ausmaß an Schutz kann beim Aufruf spezifiziert werden. Dabei ist zwischen Präzision, Aktualität und Performance abzuwägen.

Einige Produkte enthalten einen integrierten objektorientierten Transaktionsmonitor, die meisten bieten jedoch auch die Möglichkeit an, bestehende Transaktionssysteme wie CICS, Tuxedo oder Encina einzusetzen.
Die kann kritisch für die Entscheidung für einen bestimmten Applikationsserver sein, denn der Wechsel des Transaktionssystems ist sehr aufwendig.

Naming

Um Ressourcen und auch Objekte lokalisieren zu können, braucht man einen Namensdienst. Sowohl CORBA (via CosNaming) als auch EJB (via JNDI = Java Naming and Directory Interface) bieten die Möglichkeit, bestehende Namensdienste einzubinden. Mittlerweile hat sich LDAP etabliert und fast alle Applikationsserver bieten die Möglichkeit, diesen Dienst zu nutzen. Eine Ausnahme bildet IBM WebSphere Enterprise Edition, das auf DCE aufsetzt. Der Aufbau und die Pflege eines zweiten Namensdienstes in einem Unternehmen kann jedoch teuer werden. Deshalb plant auch IBM für die Zukunft eine Unterstützung von LDAP, in der Advanced Edition ist dies schon gegeben.

CORBA-Dienste

CORBA definiert eine große Zahl von Diensten, deren Implementierung aber (im Gegensatz zur EJB-Architektur) nicht Pflicht ist. Und so variieren die vorgestellten Applikationsserver hier stark. Ein sinnvoller Vergleich war uns aber hier nicht möglich, da wir nur unzureichende Angaben der Hersteller erhielten.

Entwicklungstools

Die Marktführer unter den integrierten Java-Entwicklungswerkzeugen, IBM mit VisualAge und Borland mit JBuilder, haben in den Profiausgaben ihrer Tool bereits Wizards und andere Entwicklungshilfen für die Entwicklung von CORBA- und EJB-Anwendungen integriert. Insbesondere die Erstellung von Enterprise Java Beans ist sehr komfortabel möglich, bei VisualAge beeindruckt auch die praktische Testumgebung. Ein Vorteil der EJB-Architektur ist, dass diese Komponenten nun auf jedem Application Server eingesetzt werden können.

Der zweite Schritt ist das Deployment, das heißt das Einbringen der EJBs oder CORBA-Module in die Laufzeitumgebung des Servers (Container bei EJBs bzw. Repositories bei CORBA). Dies ist mit der Konfiguration der Persistenz- und Transaktionsanbindung an die gegebene Systeminfrastruktur verbunden. Dafür stellen die Hersteller spezielle Werkzeuge zur Verfügung.

Sun bringt seinen eigenen Application Builder mit und möchte auf die Entwicklungsumgebung von Forté wechseln, Silverstream hat einen eigenen Designer und Oracle liefert mit dem JDeveloper ein Derivat von Borlands JBuilder. BEA hat kürzlich die VisualCafé von Symantec erworben. Daneben können bei allen auch externe Entwicklungswerkzeuge verwendet werden. Die IBM nutzt dabei den Vorteil besonders gut aus, dass sie selbst Hersteller einer IDE ist (VisualAge) und bietet eine besonders enge Integration an.

Literatur

[1] Robert Orfali, Dan Harkey: Client/Server Programming with Java and CORBA, Second Edition, John Wiley, 1998

[2] Sun Microsystems: J2EE, www.javasoft.com/j2ee

[3] Sun Microsystems: EJB Specification, www.javasoft.com

[4] OMG: CORBA Specification, www.omg.org

© 2006 Hawlitzek IT-Consulting GmbH,
Marketing&Design Kirsten Literski-Hawlitzek

Seitenanfang