Java Enterprise: Einführung
Aus Wikibooks
Um auf einer Plattform die gesamte Fachlichkeit ("(e)-Business") abzubilden definiert die 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.
Inhaltsverzeichnis |
[Bearbeiten] Verteilte Anwendungen / Komponenten
Eine verteilte Anwendung nutzt die Resourcen 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.
[Bearbeiten] Flexible Anwendungen / Komponenten
Die J2EE 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 u.s.w oder auch direkt vom EJB aus realisieren. Gleichzeitig werden durch CORBA, RMI und XML/SOAP für den Zugriff verschiedene Protokolle angeboten.
[Bearbeiten] Business-Schicht, Präsentations-Schicht, Persistenz-Schicht
Die J2EE 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.
[Bearbeiten] 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 J2EE API definiert, wodurch J2EE Komponenten in jedem J2EE-konformen Applicationserver laufen. Wie die Schnittstellen der J2EE implementiert werden bleibt jedoch dem einzelnen Hersteller überlassen. Er stellt insgesamt gesehen eine Java Laufzeitumgebung für die J2EE-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.
[Bearbeiten] 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.
[Bearbeiten] Enterprise Application Integration [EAI]
Die Nutzung der vorhandenen Module und somit die Investitionssicherheit ist ein wesentlicher Punkt für den Einsatz von J2EE. 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.
[Bearbeiten] J2EE vs. J2SE ?
Die J2EE besteht aus einer speziellen Spezifikation und APIs für Business Aufgaben und ist ein Aufsatz zu J2SE. Die J2SE beinhaltet zahlreiche APIs, welche im Rahmen der J2EE für die Aufgabenbewältigung benötigt werden.
[Bearbeiten] Rollen der J2EE
Die J2EE Spezifikation kennt verschiedene Rollen:
- J2EE 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
