Java 2 Enterprise Edition

Transkript

1 Java 2 Enterprise Edition Informatikseminar Enterprise JavaBeans, e-commerce und UML Peter Haase peter@informatik.uni-rostock.de

2

3 Inhaltsverzeichnis 1 Einführung in die J2EE 4 2 Das J2EE Applikationsmodell Middle Tier Client Tier HTML Basierte Clients HTTP basierte Clients Intranet Clients Andere Client Typen Das Backend-Tier: Enterprise Information Systems J2EE Deklarationen Sicherheitsmodell Die J2EE Plattform J2EE Deployment Java Technologie Standards IETF Standards CORBA Technologie Standards Die J2EE Compatibility Test Suite 13 5 Die J2EE Referenz Implementation 13 3

4 1 Einführung in die J2EE Das Internet und e-commerce haben in den letzten Jahren die Softwareindustrie revolutioniert. Unternehmen in der heutigen Zeit müssen sich bei der Entwicklung von Softwaresystemen neuen Herausforderungen stellen. Die Anwendungen werden zunehmend komplexer, ihre Entwicklungszeit jedoch muss möglichst kurz sein. Des weiteren nehmen die Anforderungen an Anwendungen zu. Zu diesen gehören: Hohe Verfügbarkeit, um den Anforderungen der globalen Geschäftswelt zu genügen Sicherheit, um die Privatsphäre des Nutzers und die Integrität der Unternehmensdaten zu schützen Zuverlässigkeit und Skalierbarkeit, um die zügige und korrekte Abarbeitung der Transaktionen zu gewährleisten. Aus verschiedenen Gründen werden diese Anwendungen oftmals als verteilte Systeme realisiert, bestehend aus mehreren Tiers, z.b. Clients auf der Nutzerseite, Datenbanken im Backend sowie einem oder mehreren Middle-Tiers dazwischen. Ziel der J2EE ist es, die Kosten und Komplexität des Entwickelns solcher Multi- Tier Anwendungen zu reduzieren. Dies wird erreicht durch die Definition einer Standardarchitektur bestehend aus folgenden Elementen: J2EE BluePrints Ein Standard-Applikationsmodell für die Entwicklung von Multi-Tier Anwendungen J2EE Platform Eine Standard-Plattform für J2EE-Anwendungen J2EE Compatibility Test Suite - Eine Sammlung von Kompatibilitätstests zur Überprüfung der Kompatibilität mit dem J2EE- Plattform-Standard J2EE Reference Implementation Eine Referenzimplementation zur Demonstration der Fähigkeiten der J2EE sowie eine operationale Definition der J2EE Plattform Diese Bestandteile werden im Folgenden vorgestellt. 4

5 2 Das J2EE Applikationsmodell J2EE wurde entwickelt, um Anwendungen zu realisieren, die verschiedenste Unternehmensdienste implementieren, so z.b. für Kunden, Angestellte, Partner usw. Solche Anwendungen sind zumeist sehr komplex, greifen auf unterschiedlichste Datenquellen zu und laufen auf einer großen Anzahl von Clients. Um diese Anwendungen besser zu kontrollieren, sind die Business Functions, die diese verschiedenen Nutzer bedienen, im Middle-Tier untergebracht. Der Middle- Tier läuft gewöhnlich auf dedizierter Server Hardware und hat Zugriff auf sämtliche Datendienste des Unternehmens. J2EE Anwendungen nutzen oft den EIS-Tier (EIS: Enterprise Information System), um die unternehmenskritischen Daten zu halten. Diese Daten, und die Systeme die diese Daten verwalten, befinden sich im inneren Kern des Unternehmens. Bisher war die Entwicklung von Multi-Tier Anwendungen sehr kompliziert, da sowohl die Dienste selbst entwickelt werden mussten, aber auch die komplexere Infrastruktur um auf Datenbanken und andere Systemresourcen zuzugreifen. Zudem hatte jeder Multi-Tier Server sein eigenes Applikationssmodell. Das J2EE Applikationsmodell definiert eine Architektur zum Implementieren von Diensten als Multi-Tier Anwendungen, die diese Probleme vermeiden und die nötige Skalierbarkeit und Verfügbarkeit bieten. Das J2EE Applikationsmodell partitioniert die Arbeit zum Implementieren eines Multi-Tier Dienstes in zwei Teile: Die Business und Presentation Logic, die durch den Entwickler implementiert werden muss, und die Standard-Systemdienste, die die J2EE-Plattform zur Verfügung stellt. Der Entwickler kann sich darauf verlassen, dass die Plattform die Lösung für Probleme auf Systemebene liefert. Das J2EE-Applikationsmodell bietet die Vorzüge der Write Once, Run Everywhere - Portabilität und der Skalierbarkeit für Multi-Tier Anwendungen. Damit stellt es einen großen Schritt in Richtung Vereinfachung und Beschleunigung der Applikationsentwicklung dar. Das J2EE Applikationsmodell ist Bestandteil der Sun BluePrints(TM) in Form eines Buches [1] und einer Website [2]. Ergänzender Bestandteil der BluePrints ist eine Beispielapplikation, die das J2EE Applikationsmodell und seine Möglichkeiten demonstriert. 5

6 2.1 Middle Tier Der Hauptvorteil des J2EE Applikationsmodells findet sich im Middle-Tier. Im J2EE Applikationsmodell sind die Business Functions als Enterprise JavaBeans (EJBs) Komponenten realisiert, wie Abbildung 1 zeigt. Die EJBs erlauben dem Entwickler, sich voll auf die Business Logik zu konzentrieren, und überlassen dem EJB Server die Komplexität des Lieferns eines zuverlässigen, skalierbaren Dienstes. Abbildung 1: EJB-Komponenten implementieren Business Functions im Middle Tier JavaServer Pages (JSPs) und Servlets präsentieren die Middle-Tier Funktionen dem Client-Tier als einfach zugängliche Dienste im Internet-Stil. JSPs erleichtern dem Entwickler der Benutzerschnittstelle das Präsentieren von dynamisch generierten Inhalten für einen beliebigen Browser. Servlets geben dem fortgeschrittenen Java- Entwickler die Möglichkeit, dynamische Präsentationen komplett in Java zu implementieren. 2.2 Client Tier Die J2EE Plattform unterstützt verschiedene Client-Typen. Viele J2EE Dienste werden entwickelt, um Webbrowser-Clients zu unterstützen. Diese Dienste interagieren mit ihren Clients über dynamisch generierte HTML- Seiten und Forms. Anspruchsvollere Dienste interagieren mit ihren Clients, indem sie die Anwendungsdaten direkt austauschen. In diesem Fall werden JSPs und Servlets genutzt, um diese Daten so zu formatieren, dass der Client diese leicht verarbeiten kann. Diese Clients können sowohl Java Applets als auch Java-basierte Anwendungen (Applications) sein. Dabei ist hervorzuheben, dass Sicherheit eine Schlüsselrolle bei allen Multi-Tier Anwendungen spielt. Bei der J2EE werden Sicherheitsmechanismen fast ausschließ- 6

7 lich durch die Plattform und ihre Administratoren realisiert. Zumeist erforden weder der Client noch der Dienst selber vom Entwickler geschriebene Sicherheitslogik HTML Basierte Clients Ein Dienst kann dem Nutzer direkt als dynamisch generierte HTML-Seite präsentiert werden. Dies kann relativ einfach mit JavaServer Pages (JSP) geschehen, wie Abbildung 2 demonstriert. JSPs werden in einer Skriptsprache geschrieben, die HTML und Java kombiniert. Erfordert ein Dienst komplexeren Code, so kann dieser über JavaBeans realisiert werden, auf die über JSP zugegriffen werden kann. Außerdem kann ein Dienst direkt in Java als Servlet implementiert werden. Abbildung 2: Präsentation eines Dienstes über einen Browser HTTP basierte Clients Oftmals ist es nützlich, Funktionalität direkt beim Client zu realisieren. In diesem Fall werden anstelle von HTML Seiten die rohen Daten übertragen. Für diesen Fall bieten sich insbesondere XML-Dokumente an, die über das HTTP-Protokoll zwischen Client und Dienst ausgetauscht werden. Abbildung 3 zeigt, wie dieser Datenaustausch geschehen kann: Die XML-Daten werden im Client-Tier von JavaBeans Komponenten in einem Applet verarbeitet, das automatisch in den Browser des Nutzers heruntergeladen wird. Anstelle des Applets in einem Browser kann natürlich auch eine Java-Application stehen, die als J2EE-Client agiert. Mit diesem flexiblen Client-Modell hat der Entwickler eine große Bandbreite von Möglichkeiten, die Nutzerschnittstelle einer verteilten Anwendung im Internet oder Intranet zu gestalten. 7

8 Abbildung 3: JavaBeans Komponenten in einem Browser Intranet Clients HTML basierte und HTTP basierte Clients können natürlich sowohl im Internet als auch im Intranet eines Unternehmens eingesetzt werden. Zusätzlich bietet das Intranet die nötige Infrastruktur, um auf EJBs direkt innerhalb der Intranetdomäne zuzugreifen Andere Client Typen Ein Ziel der Enterprise JavaBeans Technologie ist die Definition des CORBA Standards RMI-IIOP als Interoperabilitätsmechanismus. Damit wird jeder J2EE Dienst zugänglich für jeden CORBA-Client, wodurch eine komplette Integration der J2EE Plattform und bestehenden Enterprise Information Systems möglich wird. Der größte Teil dieses Standards ist bereits komplett, an kleineren Teilen wird noch gearbeitet. In Zukunft wird CORBA-Interoperabilität integraler Betandteil der J2EE sein. 2.3 Das Backend-Tier: Enterprise Information Systems Ein Dienst des Middle-Tier muss natürlich in der Lage sein, auf Daten des EIS- Tier zuzugreifen. Die folgenden Standard Java APIs erlauben den Zugriff auf diese Systeme: JDBC: das Standard API für den Zugriff auf relationale Datenbanken Java Naming and Directory Interface (JNDI): das Standard API für den Zugriff auf Informationen aus Namens- und Verzeichnisdiensten eines Unternehmens Java Message Service (JMS): das Standard API für das Senden und Empfangen von Nachrichten über Messaging Systeme eines Unternehmens (z.b. IBM MQ Series) 8

9 JavaMail: das Standard API für das Senden von s JavaIDL: das Standard API für den Aufruf von CORBA-Diensten 2.4 J2EE Deklarationen Wie bereits erwähnt, ist es ein bedeutendes Ziel des J2EE Applikationsmodells, den Programmieraufwand zu minimieren. Ein Weg dies zu erreichen ist das Verlagern der Implementierung von häufig genutzten Funktionalitäten in die J2EE-Plattform. Diese umfassen z.b. die Kontrolle der Sicherheit, Implementierung der Transaktionssemantiken, sowie das Anbinden von Komponenten an andere Komponenten oder Resourcen. J2EE bietet eine einfache und deklarative Möglichkeit, dieses Verhalten zu spezifizieren. Diese Deklarationen sind getrennt vom Code der Komponenten in sogenannten Deployment-Deskriptoren gespeichert. Sie sind XML-basiert und erlauben dem Deployer der Anwendung, das Verhalten der Anwendung zu ändern, ohne die Komponenten selbst zu verändern. 2.5 Sicherheitsmodell Im Gegensatz zu anderen Applikationsmodellen, die plattformspezifische Sicherheitsmechanismen in der Anwendung erfordern, bietet die J2EE eine Sicherheitsumgebung, die es ermöglicht, Sicherheitsbeschränkungen zum Zeitpunkt der Installation der Anwendung (Deployment) zu definieren. Dadurch, dass die Anwendung von der Komplexität der Sicherheitsimplementierung befreit ist, bleibt sie portabel und kann die verschiedenen Sicherheitsmechanismen nutzen, die die J2EE Plattform zur Verfügung stellt. Die J2EE Plattform definiert deklarative Standardregeln für die Zugriffskontrolle, die durch den Anwendungsentwickler gesetzt werden, und bei der Installation interpretiert werden. Ausserdem verlangt der J2EE Standard, dass die Plattform einen Login- Mechanismus bereitstellt, so dass dieser nicht in der Anwendung implementiert werden muss. Dadurch kann ein Programm in verschiedenen Sicherheitsumgebungen laufen, ohne dass Änderungen am Quellcode vorgenommen werden müssen. 9

10 3 Die J2EE Plattform Die J2EE Plattform ist die Standardlaufzeitumgebung für J2EE Anwendungen. Sie setzt sich aus den folgenden Bestandteilen zusammen: Komponenten Java Applications, Applets Servlets und JSPs EJBs Container stellen die Laufzeitumgebung für Komponenten dar. Ein Container bietet seinen Komponenten eine föderierte Sicht auf die J2EE APIs. Über Deployment-Deskriptoren kann eine Komponente transparent J2EE Dienste wie Sicherheitsmechanismen und Transaktionsmanagement nutzen. Resource Manager Drivers sind Treiber auf Systemebene, die die Netzwerkverbindung zu externen Resourcen realisieren. Dies kann z.b. geschehen, indem ein Standard API wie JDBC im Falle eines Datenbanktreibers implementiert wird. Datenbank Die J2EE Plattform enthält eine Datenbank zum Speichern der Unternehmensdaten. Auf sie kann über JDBC zugegriffen werden. Abbildung 4 gibt eine Übersicht über die J2EE Plattformarchitektur. Abbildung 4: Die J2EE Plattformarchitektur 10

11 Die Standards, die in der J2EE Plattformspezifikation beschrieben werden, lassen sich in folgende Kategorien einteilen: J2EE Deployment Spezifikation - ein Standard, der spezifiziert, wie Anwendungen ausgeliefert werden sollen, um sie auf einer beliebigen J2EEkompatiblen Plattform verwenden zu können Java Technologie Standards - eine Menge von Standards, die jede J2EE Plattform unterstützen muss IETF Standards - eine Menge von Standards der Internet Engineering Task Force, die jede J2EE Plattform unterstützen muss CORBA Standards - eine Menge von CORBA Standards auf welchen die die Middle-Tier Interoperabilität der J2EE Plattform aufbaut Diese Standards werden im folgenden kurz erläutert. 3.1 J2EE Deployment Eine J2EE Anwendung besteht aus einer oder mehreren Standardeinheiten (units), die auf einer beliebigen J2EE Plattform eingesetzt werden können. Jede dieser Einheit enthält eine oder mehrere funktionale Komponenten (EJB, JSP, Servlet, Applet, etc.), einen Deployment-Deskriptor, sowie J2EE Deklarationen, die durch den Anwendungs-Developer und Assembler spezifiziert wurden. Eine einmal produzierte Einheit kann nun auf einer beliebigen J2EE Plattform eingesetzt werden, wie Abbildung 5 zeigt: Abbildung 5: Die Installation einer J2EE Anwendung 11

12 Die Installation einer J2EE Anwendung geschieht meist mit einem Deployment Tool, mit dessen Hilfe spezifische Informationen (z.b. lokaler Datenbankname) erfasst werden können. 3.2 Java Technologie Standards Der wichtigste Bestandteil der J2EE Plattform ist ihre Liste der Java Standards, die alle J2EE Produkte unterstützen müssen. Mit Unterstützung ist in diesem Sinne gemeint, dass sämtliche APIs vollständig in die Plattform integriert sein müssen. Damit ist eine konsistente Umgebung für das Erstellen von J2EE Anwendungen gewährleistet. Die folgende Tabelle gibt einen Überblick über die Standard APIs der J2EE: API EJB JNDI Servlets und JSPs JMS JTS JDBC JavaMail JAF Beschreibung Server Komponenten-Modell Java Naming and Directory Interface: für Namens- und Verzeichnisdienste Server Komponenten in WebServern zum dynamischen Generieren von Web-Seiten Java Messaging Service: asynchrone Kommunikation über Queues oder Publish/Subscribe Java Transaction Service Datenbankzugriff protokollunabhängiger Standard für Mailing-Dienste Java Activation Framework: Standard Service, um den Typ von Daten zu bestimmen 3.3 IETF Standards Die Entwicklung des Internet hatte großen Einfluss darauf, wie Anwendungsentwicklung geschieht. Diese Revolution basiert auf Standards, die durch die Internet Engineering Task Force gesetzt wurden. Dazu gehören HTML, HTTP, und neuerdings XML. Java hat sich mit diesen Standards entwickelt und wurde damit die bevorzugte Programmiersprache für diese Technologien. Das Applikationsmodell der J2EE setzt diesen Weg fort. In der aktuellen Fassung unterstützt die J2EE Plattform HTML und HTTP Clients, und optional XML Clients. Zukünftige Versionen der J2EE werden verstärkt XML als Mittel zur plattformunabhägigen Datenkommunikation einsetzen, wie es schon jetzt mit den Deployment-Deskriptoren geschieht. 12

13 3.4 CORBA Technologie Standards Die Object Management Group (OMG) hat in Zusammenarbeit mit Sun die RMI- IIOP Spezifikation erarbeitet. Dieser Standard definiert, wie das CORBA IIOP Protokoll über Java Remote Method Invocation genutzt wird. Die EJB-Spezifikation sieht RMI-IIOP als Standard für den Aufruf von EJBs vor. Umgekehrt ist es über den Java IDL-Standard möglich, CORBA-Objekte in einer Java Anwendung zu benutzen. 4 Die J2EE Compatibility Test Suite Hersteller von J2EE Plattformen müssen in der Lage sein, die Übereinstimmung ihrer Implementation mit der J2EE Plattformspezifikation zu überprüfen. Dazu können die Hersteller die J2EE Compatibilty Test Suite (CTS) von Sun Microsystems lizensieren. Die Lizenznehmer lassen die CTS auf ihrer Plattform laufen. Die Tests überprüfen, ob alle APIs korrekt implementiert wurden, und ob alle J2EE Komponenten vorhanden sind und korrekt zusammenarbeiten. Die CTS umfasst außerdem voll funktionsfähige J2EE Anwendungen, mit denen überprüft werden kann, ob sie sich erfolgreich installieren und ausführen lassen. 5 Die J2EE Referenz Implementation Die J2EE Referenzimplementation hat verschiedene Aufgaben. Ihre Hauptaufgabe ist ihre Funktion als operationale Definition der J2EE Plattform. Sie wird von Herstellern als Referenz genutzt, um zu überprüfen, wie sich ihre Implementation unter bestimmten Umständen verhalten muss. Sie wird auch genutzt, um die Portabilität einer Anwendung zu verifizieren. Nicht zuletzt wird sie als Standardplattform für die Compatibility Test Suite verwendet. Die Referenzimplementation ist kein kommerzielles Produkt, die Lizenz verbietet sogar explizit kommerziellen Gebrauch. Sie ist aber als Quell- und Binärcode frei verfügbar für Demonstrationen, Prototypen und Forschung. Damit kommt ihr besondere Bedeutung bei der Verbreitung der J2EE Technologie zu. 13

14 Literatur [1] Nicholas Kassem. Designing Enterprise Applications with the Java 2 Platform, Enterprise Edition. Sun, [2] Nicholas Kassem. Designing Enterprise Applications with the Java 2 Platform, Enterprise Edition [3] Ed Roman. Mastering Enterprise JavaBeans and the Java 2 Platform, Enterprise Edition. John Wisley & Sons, [4] Sun. Java 2 Platform Enterprise Edition Specification, v [5] Sun. Simplified Guide to the Java 2 Platform, Enterprise Edition. guide.pdf, [6] Sun. The Java 2 Enterprise Edition Developers Guide [7] Sun. Java 2 Platform Enterprise Edition Specification, v1.3, Proposed Final Draft [8] Anne Thomas. Java 2 Platform, Enterprise Edition: Ensuring Consistency, Portability, and Interoperability