J2EE-Technologien

JDBC

Ähnlich wie ODBC ist JDBC eine Schnittstelle um von Java auf eine Datenbank zuzugreifen: Java Database Connectivity. Die JDBC-API stellt eine Abstraktionsschicht für den Connect zu praktisch jeder relationalen oder tabellarischen Datenquelle zur Verfügung. Dabei kümmert sich JDBC u.a. um die Authentifizierung, die Connection, SQL-Umsetzung und die Transaktions-APIs. So können Programmierer den selben einen Code für den Zugang zu praktisch jeder Standard-konformen Datenbank benutzen, indem sie den entsprechenden JDBC-Treiber für ihre Datenbankimplementierung benutzen. Oder anders ausgedrückt: Man kann der J2EE-Applikation so - zumindest theoretisch - die Datenbank 'unterm Hintern' austauschen.

JNDI

Die APIs des Java Naming and Directory Interface stellen Schnittstellen für verschiedene Verzeichnisdienste zur Verfügung, beispielsweise über LDAP zu LDAP-Servern, JDBC Datenquellen, EJB Homes, JMS (Java Messaging Service) Connections, Network Information Service (NIS) und Domain Name System (DNS). Diese Namensdienste sind ein essentieller Bestandteil einer J2EE-Umgebung, weil sie der Weg sind, wie J2EE-Komponenten Services, andere Komponenten oder Legacy-Systeme finden. Man kann als Entwickler deklarativ (also einfach durch Angabe eines dafür vergebenen Namens) auf diese Komponentendaten zugreifen. Mit der Einrichtung und Anbindung der Komponenten hat der Entwickler dann gar nichts mehr zu tun. Änderungen werden vom System völlig transparent durchgereicht und erfordern keine Änderungen im Code.

JTA und JTS

Transaktionsmanagement ist ein J2EE-Standardservice, der die Entwicklung von verteilten Softwaresystemen erleichtert. Datenintegrität ist halt am besten gesichert, wenn man darauf hinwirken kann, dass die Richtlinien für den Zugang zu und die Manipulation an Daten strikt eingehalten werden, indem man ein stringentes Transaktionskonzept durchführt. Die Java Transaction API (JTA) erlaubt es einem verteilten transaktionalen System oder einer verteilten transaktionalen Anwendung, auf den Transaktionsmanager zuzugreifen, der von den Java Transaction Services (JTS) zur Verfügung gestellt wird. JTS sorgt dabei nicht nur für die Demarkation und Synchronisierung von Transaktionen, sondern auch für das Ressourcenmanagement und die Informationsübertragung innerhalb der Komponenten einer Transaktion.

Servlets

Die Java Servlet API ist eine vom Container verwaltete (container-managed) Alternative mit Zustand (stateful) zu Common Gateway Applikationen (CGI). Servlets werden von einem ganz speziellen Teil des J2EE-Containers deployed und gemanagt, der besonders eng in das Sicherheits-Subsystem des Containers integriert ist. Der einzige Lebenszweck eines Servlets ist es, HTTP-Requests zu empfangen, dynamisch Daten zu erzeugen (üblicherweise HTML) und das Ganze als HTTP-Antwort auszuliefern. Mit der Java Servlet API wurde außerdem das Konzept einer HTTP-Sitzung (-Session) eingeführt, wodurch erst Anfragen vom Client an den Servlet-Container mit Zwischenspeicherung des Zustands (stateful calls) möglich sind.

Im Gegensatz zu typischen CGI-Applikationen geben Servlets nach dem Abarbeiten eines Requests nicht wieder komplett alle Ressourcen frei, sondern bleiben resident im Container, um für weitere Anfragen der HTTP-Clients schneller zur Verfügung zu stehen. Über die Servlet-Event-Listener hat man Zugriff auf den Lebenszyklus eines Servlets und - seit Servlet 2.3 - können Entwickler Filter-Chains benutzen, um sukzessive Transformationen am HTTP-Request oder -Response vorzunehmen.

JSP

Java Server Pages bieten dem Entwickler eine komfortable Möglichkeit, mit Hilfe von Templates dynamisch erzeugten HTML-Inhalt darzustellen. Üblicherweise ist eine JSP-Seite eine HTML-Seite mit dazwischen liegenden "Code-Schnipseln" (sog. Scriptlets) oder selbstprogrammierten bzw. Standard-Tag-Libraries. Tag-Libraries sorgen von vornherein für eine sauberere Trennung zwischen der View-Schicht und der Controller-Schicht einer Applikation, obwohl man das auch mit bestimmten Techniken und Patterns bei Scriptlets erreichen kann. Tag-Libraries haben aber noch dazu den Vorteil, dass sie den JSP-Entwickler davon befreien, sich um den Javacode auf der Seite zu kümmern, denn man braucht nur diese vorgefertigten HTML-ähnlichen Tags in der JSP-Seite zu benutzen - zur Laufzeit werden sie dann in ein Servlet kompiliert und laufen als Servlet im Container.

EJB

Enterprise JavaBeans dienen in einer J2EE-Applikation als Schicht für die Businesslogik. EJBs sind also die eigentlichen Komponenten für eine zustandsbehaftete (stateful), von außen zugängliche (remote), transaktionssichere, überhaupt sichere und skalierbare Business-Logik-Schicht. EJBs sind also nicht dazu gedacht, User-Interfaces zu erzeugen oder Client-Requests zu handeln. Diese Aufgaben werden - wie schon erwähnt - von den Komponenten der Präsentationsschicht übernommen (Servlets, JSPs, Clientanwendungen etc.).Mit den drei Typen von EJBs ( Session Beans, Entity Beans und message-driven Beans), ihrem Deployment und den verschiedenen Möglichkeiten zur Steuerung ihrer Persistenz werden wir uns ja noch ausgiebig beschäftigen.

Speziell die EJB 2.0-Spezifikation brachte Verbesserungen auf dem Feld der Entity Bean Persistence und der Beziehungen zwischen Beans. Man kann als Entwickler nun deklarativ die Beziehungen zwischen Beans in so genannten 'Deskriptoren' beschreiben, ohne sich um die drunterliegenden Strukturen kümmern zu müssen. Mit der EJB 2.0-Spezifikation wurde auch die Syntax der so genannten EJB Query Language (EJBQL), die Integration von Session Beans und JMS mittels message-driven Beans eingeführt, dazu noch die Möglichkeit, zusätzlich zu den Remote Interfaces auch Local Interfaces zu nutzen. Letzteres rationalisiert Aufrufe an eine EJB im selben Container erheblich.

RMI-IIOP

RMI-IIOP ist die Abkürzung für Java Remote Method Invocation over the Internet Inter-ORB-Protocol und ist der Mechanismus im J2EE, der - grob ausgedrückt - die Netzwerktätigkeiten erledigt.
RMI-IIOP ist - im Unterschied zu RMI (Remote Method Invocation) von Java mit der API java.rmi - zu CORBA kompatibel und benutzt sowohl die RMI-API java.rmi als auch die eigene API javax.rmi.

RMI hat ein paar Fähigkeiten, die in RMI-IIOP nicht verfügbar sind, wie z.B. verteilte Garbage Collection, Object Activation und downloadbare Klassen - das ist aber nicht unser Thema, weil das J2EE und EJB eben mit RMI-IIOP arbeiten. Jede J2EE-Server-Implementation (in unserem Falle JBoss 3.0) sollte ihre eigene Implementation von RMI-IIOP mitbringen. Sie sollten es unbedingt vermeiden, Implementationen verschiedener Hersteller (Bea oder Sun) zu mixen.
Also noch mal: RMI ist ein Satz APIs der dazu gemacht wurde, verteilte Java-Applikationen zu schreiben.

Java Serialization (das ist die Codierung und Decodierung von Objekten in bzw. aus einem Datenstrom, der eine Übertragung von Objekten in verteilten System erst ermöglicht) und das Java Remote Method Protocol (JRMP) erlauben Remote Procedure Calls auf Objekte.
Die Objekte und ihre Beziehungen zueinander müssen auf der einen Seite des Calls erfasst und aufgedröselt, und auf der 'Empfängerseite' wieder zusammengesetzt werden - diese Vorgänge nennt man Marshaling und Unmarshaling. Der J2EE-Standard unterstützt JRMP, um Objekten den Zugriff auf andere Objekte in anderen Adressräumen zu ermöglichen. Die Clients benutzen RMI-IIOP, um mit den EJBs zu kommunizieren.

JMS

In einem voll funktionalen J2EE-Produkt ist außerdem die Java Message Service API (JMS) implementiert. Sie unterstützt Enterprise Messaging durch unterschiedliche, interne, produktanhängige System wie beispielsweise Oracle Advanced Queuing (AQ), IBM MQSeries, SonicMQ, SwiftMQ und ähnliche. JMS stellt dem Entwickler ein asynchrones Messaging System zur Verfügung, das es nicht fest miteinander gekoppelten Systemen erlaubt, Information dann zu verarbeiten, wenn es für das jeweilige System am sinnvollsten ist. Verteilte Systeme mit Anwendungen für Buiness to Business (B2B) oder Enterprise Application Integration (EAI) sind meist ganz stark abhängig von einer guten JMS-Implementation: Die Systeme laufen ja rein physikalisch in verschiedenen Firmen und/oder auf verschiedenen Kontinenten und haben ihre Volllastperioden zu unterschiedlichen Zeiten. Mit einem asynchronen Messaging kann die Empfänger-Applikation die Nachricht abarbeiten, wenn es für sie günstig ist, da die Absender-Applikation nicht auf eine direkte Antwort warten muss.

JMS gibt es in zwei Modellen: publish-and-subscribe (pub/sub) und point-to-point (ptp).
Publish-and-Subscribe benutzt man, wenn mehrere Prozesse (die subscriber = 'Abonnenten') die selbe Nachricht von einem anderen Prozess (dem publisher ='Nachrichtendienst' ) bekommen.
Von Point-to-Point Messaging spricht man, wenn ein Prozess direkt eine Nachricht an einen ihm bekannten anderen Prozess schickt.

Message-driven Beans sind ein spezieller (neuer) Typ EJB, der JMS kapselt, um es J2EE-Applikationen zu ermöglichen, Prozesse asynchron abzuwickeln.

JavaMail

Die JavaMail API bietet protokoll-unabhängige Unterstützung für Email-Syteme. Sie verfügt über die üblichen Funktionen zum Lesen, Schreiben und Versenden von Emails und hat eingebaute Implementationen für die bekannten Standard-Mail-Protokolle IMAP, POP3 und SMTP. Von diesen abstrakten Klassen kann der Entwickler dann Unterklassen ableiten, um auch andere Protokolle wie MAPI, NNTP, LotusNotes ö.ä. zu bedienen.

JAF

Das JavaBeans Action Framework (JAF) integriert MIME (Multipurpose Internet Mail Extensions) in die Java-Plattform. Das Framework unterstützt das Mapping von Dateitypen auf MIME-Typen und ist eng mit der JavaMail API verbandelt, damit Email-Attachments verarbeitet werden können.

JAXP

Wie Sie vielleicht schon wissen, werden alle J2EE-Deskriptoren als XML-Dateien geschrieben. So ist es nur logisch, dass die XML-Technologie ebenfalls ein wichtiger Bestandteil der Java-Plattform ist. Die Java API for XML Processing (JAXP) unterstützt das Prozessieren von XML-Dokumenten über XSLT, und zwar implemenationsunabhängig.
Es gibt zwei wichtige APIs für die Repräsentation und das Parsen von XML-Dokumenten: Das Document Object Model (DOM) basiert auf einem Baumstruktur- Modell; beim Parsen des Dokuments wird im Parser der gesamte Baum des XML-Dokumentes aufgebaut. Dagegen ist die Simple API for XML (SAX) eine Event-basierte API; beim Parsen eines Dokuments 'merkt' sich der Parser sozusagen ein Muster aus Event-Schaltern (z.B. Start und Ende eines Elements), die ein Application-Handler zum Auslösen von bestimmten Aktionen benutzen kann.
Extensible Stylesheet Language Transformation (XSLT) erlaubt die Überstzung von XML-Dokumenten in andere strukturierte Dokumentformate (XML, HTML, PDF...) auf der Basis von Vorlagen (Templates).

JAXP hat implementationunabhängige Schnittstellen. So kann ein Entwickler immer diejenige Parser-Implementation benutze, die für diese Aufgabe die beste ist: Parser haben unterschiedliche Stärken, z.B. mag der eine schnell sein, aber viel Speicher brauchen, während ein anderer besonders sparsam mit Arbeitsspeicher umgeht.. Man kann dann je nach Anspruch den geeigneten nehmen, ohne Code umschreiben zu müssen.

JAAS

Der Java Authentication and Authorization Service (JAAS) wurde geschaffen, um dem Entwickler eine standardisiertes, gemeinsames, rein-Java-basierendes Framework und eine entsprechende API zu geben, um User-Privilegien zuweisen, authentifzieren und überprüfen zu können.
JAAS stellt Unterstützung für so genannte Pluggable Authentication Modules (PAM) zur Verfügung, die auf unterschiedliche 'Authentication Provider' zugreifen können, wenn ein User authentifiziert werden soll: LDAP, andere JNDI-Quellen, Betriebssystem-(Passwort-)Dateien oder -Systeme, XML-Dateien usw. JAAS ermöglicht darüber sogar Single Sign-On und das Management von Access Control Policies für User-basierte, Gruppen-basierte oder Rollen-basierte Authentifizierung.

JCA

Die Java Connector Architecture (JCA) stellt eine weiter standardisierte, abstrakte API dar, um EJBs und Enterprise Applications an so genannte Enterprise Information Systems (EIS) verbinden zu können, die äußersten Schichten des J2EE-3-Tier-Systems.

26 -08-2003 Petra Haberer Version 0.0.9