Java Enterprise: Einführung

Um auf einer Plattform die gesamte Fachlichkeit ("(e)-Business") abzubilden definiert die JEE (früher J2EE) Spezifikation ein mehrschichtiges objektorientiertes (ggf.) verteiltes Komponentenmodel auf Basis der Programmiersprache Java. Neben einer Java Laufzeitumgebung (JVM) benötigen diese Komponenten einen Applicationserver. Dieser kapselt einen Großteil der systemnahen Funktionalität transparent für die Entwickler. Hierdurch wird eine Unabhängigkeit von diesen Systemfunktionalitäten erreicht. Zur weiteren Herstellerneutralität dient die Bereitstellung von vielen standardisierten APIs z.B. zum Thema Sicherheit (JAAS), XML oder Datenbankzugriff (JDBC). Die Unterstützung von CORBA erlaubt hierbei die objektorientierte Kommunikation mit Legacysystemen.

Verteilte Anwendungen / Komponenten

Eine verteilte Anwendung nutzt die Ressourcen verschiedener anderer Rechner um einen hohen Grad an Wiederverwendbarkeit und Flexibilität zu erreichen und gleichzeitig relativ schlank in der eigenen Implementierung zu bleiben. Hierzu werden die Geschäftsprozesse in einzelne Teilgeschäftsprozesse unterteilt und auf Wiederverwendbarkeit untersucht. Jeder wiederverwendbare Teilgeschäftsprozess wird dabei in mindestens einem EJB (Enterprise Java Bean) gekapselt.

Flexible Anwendungen / Komponenten

Die JEE Spezifikation erlaubt den Zugriff über verschiedenste Mechanismen auf die selben Daten und Funktionen. So ist der Datenbankzugriff z.B. über eine JSP mit Bean, JSP ohne Bean, Servlet, Applikation, Applikation als EJB Client, Applet usw. oder auch direkt vom EJB aus realisieren. Gleichzeitig werden durch CORBA, RMI und XML/SOAP für den Zugriff verschiedene Protokolle angeboten.

Business-Schicht, Präsentations-Schicht, Persistenz-Schicht

Die JEE Spezifikation bietet vordefinierte Möglichkeiten zur üblichen Trennung in einem mehrschichtigen Komponenten Model. Für die Business-Schicht, welche normalerweise ausschließlich auf dem Server liegt, kommen normalerweise Session Beans [EJB] zum Einsatz, die Präsentationsschicht wird häufig durch Applets, Applikation, Servlets oder JSPs realisiert und für die Persistenzschicht sind nicht selten Entity Beans im Einsatz.

Der Applicationserver

Der Applicationserver ist ein Middlewaresystem, welches meist einen Webserver mit Servlet-Engine und einen EJB Server beinhaltet. Der EJB Server wiederum inkludiert einen EJB Container, in welchem die einzelnen EJBs ihr Dasein fristen. Hierbei wird ein "Component-Container"-Vertrag durch die JEE API definiert, wodurch JEE Komponenten in jedem JEE-konformen Applicationserver laufen. Wie die Schnittstellen der JEE implementiert werden bleibt jedoch dem einzelnen Hersteller überlassen. Er stellt insgesamt gesehen eine Java Laufzeitumgebung für die JEE-Komponenten zur Verfügung, um die Entwickler von systemnahen Aufgaben zu der eigentlichen Anwendungslogik zu bringen. Jeder Applicationserver muss

Persistenz
Synchronisierte Datenzugriffe
Transkationen
Objektverteilung
Sicherheit und
Naming

unterstützen.

Kommunikation

Die Kommunikation der Komponenten erfolgt voll objektorientiert - meist über "RMI over IIOP". Dabei verhalten sich die Objekte jeweils als Client <=> Server. Das Server Objekt stellt hierzu eine Reihe von Operationen für den Aufruf durch den Client zur Verfügung, welche über RMI, CORBA oder auch SOAP angesprochen werden können. Die eigentliche Kommunikation wird hierbei für den Komponentenentwickler transparent über Stellvertreter Objekte - Stubs und Skeletons übernommen. Das Stub Objekt repräsentiert das Server-Objekt (lokal) beim Client. Das Skeleton läuft im Server und delegiert die Methodenaufrufe an das eigentliche Server Objekt. Diese Trennung wird insbesondere für die Aufgaben des Applicationsserver benötigt, der hierdurch sich z.B. für Optimierungen zwischen den Skeleton und Server Objekt schalten kann. Sowohl die Art der Kommunikation als auch die Lokalität der Server Objekte bleibt hierbei vollständig transparent für den Client. Hierzu werden sowohl Stub als auch Skeleton generiert, so dass eine gesonderte Programmierung entfällt. Zum auffinden der Server Objekte wird ein Nameservice wie DNS, RMI Registry, DBMS oder auch LDAP benötigt. Dieser wird benutzt um das Business Objekt aufzufinden. Zurückgeliefert wird dabei das Stub Objekt, auf welchem schließlich die einzelnen Operationen aufgerufen werden können.

Enterprise Application Integration [EAI]

Die Nutzung der vorhandenen Module und somit die Investitionssicherheit ist ein wesentlicher Punkt für den Einsatz von JEE. So werden verschiedene APIs mit dieser Zielsetzung bereitgestellt. Hierzu gehören

JDBC - für Datenbankzugriff
JNI - für Legacy Systeme
Connectoren - für ERP-Zugriff
Message Queuing - für den asynchronen Verarbeitungsprozess
Mailing - für den asynchronen Benachrichtigungsprozess
WebService - für die Anbindung anderer Systeme

jeweils unter Berücksichtigung von Sicherheits- und Transaktionsaspekten.

JEE vs. JSE ?

Die JEE besteht aus einer speziellen Spezifikation und APIs für Business Aufgaben und ist ein Aufsatz zu JSE. Die JSE beinhaltet zahlreiche APIs, welche im Rahmen der JEE für die Aufgabenbewältigung benötigt werden.

Rollen der JEE

Die JEE Spezifikation kennt verschiedene Rollen:

JEE Produkt Anbieter - für die Bereitstellung des Applicationservers
Komponenten Entwickler - für die Entwicklung von EJB, JSP, Servlet, ...
Anwendungsentwickler - für das Zusammenstellen der Komponenten z.B. in einem *.war
Anwendungsverteiler - für die Bereitstellung, Konfiguration und Ausführung der Anwendung in einem Applicationserver
Administrator - für die Bereitstellung, Konfiguration und Ausführung des Applicationservers sowie der Benutzerverwaltung
Werkzeughersteller - als Anbieter von weitergehenden Hilfsmitteln