Java 2 Enterprise Edition (J2EE)

Java 2 Enterprise Edition (J2EE)
Sascha Baumeister Software Architect Specification Lead JSR086 IBM Deutschland Entwicklung GmbH

Teil II – Java Servlet API
Refresh Teil I Servlets Container Deployment

Projekt „baBay“ Entwicklung einer Web-Site zum Versteigern von Artikeln. Funktion und Grob-Design wird vorgegeben. Einstellen von Auktions-Artikeln, Bieten für Artikel, Darstellung des Ausgangs einer Auktion. Bestanden haben alle, die am Ende eine funktionsfähige Site vorweisen können.

Refresh Teil I Model-View-Controller Programmiermodelle
Java Community Process J2EE Positionierung

Hello World Servlet package com.ibm.ba; import javax.servlet.*; import javax.servlet.http.*; import java.io.*; public class HelloWorldServlet extends HttpServlet { public void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); response.getWriter().println("<HTML><HEAD><TITLE>Hello World</TITLE></HEAD>"); response.getWriter().println("<BODY>Diese Ausgabe wurde durch ein Java Servlet generiert!</BODY></HTML>"); } „Mutter“ aller Service-Methoden, es gibt noch andere. Es gibt kein „main()“ in J2EE! Superklasse aller HTTP Servlets MimeType setzen (optional) Nutzdaten generieren Request URL:

Basics Servlets erben direkt oder indirekt von javax.servlet.GenericServlet bzw javax.servlet.http.HttpServlet Ein Servlet muß eine oder mehrere Service-Methoden implementieren und einen public Default-Konstruktor bereitstellen. Der Service-Parameter „request“ beinhaltet alle Objekte, die mit einem HTTP Request übertragen werden. Der Service-Parameter „response“ beinhaltet alle Objekte, die für die Generierung eines HTTP Response benötigt werden.

Servlet Übersicht java.lang.Object javax.servlet.GenericServlet
init() service(...) doGet(...) doPost(...) ... javax.servlet.http.HttpServlet Servlet1 Servlet2 Servlet3 Servlet4

J2EE Container Servlets laufen in spezielle Java Virtual Machines (JVM), sogenannten Servlet- oder J2EE Containern. Servlet bzw. J2EE Container sind austauschbar und entsprechen dem J2EE Standard. Sie unterschieden sich durch Leistungsmerkmale wie Performance, Stabilität, Preis. Ihre Programmierschnittstelle ist identisch! Beispiele für Servlet- bzw J2EE Container sind TomCat (Open Source), IBM WebSphere Application Server, BEA Server. Das Installieren eines Servlets in einen Container nennt man „Deployment“.

Echo Servlet Bearbeitet nur HTTP Get-Requests URL-Parameter abfragen
package com.ibm.ba; import javax.servlet.*; import javax.servlet.http.*; import java.io.*; public class EchoServlet extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String text = request.getParameter("text"); response.setContentType("text/html"); response.getWriter().println("<HTML><HEAD><TITLE>Echo</TITLE></HEAD>"); response.getWriter().print("<BODY>"); response.getWriter().print(text == null ? "foo!" : text); response.getWriter().println("</BODY></HTML>"); } Bearbeitet nur HTTP Get-Requests URL-Parameter abfragen URL-Parameter können den Wert null haben! Request URL:

URL Parameter Syntax: url?name1=wert1&...&nameN=wertN
Werden in realen Anwendungen oft für Basis-Parameter verwendet, wie zum Beispiel Sprache oder Identität. Vorteil: Sehr einfache Art Parameter an ein Servlet zu übergeben. Nachteile: Die maximale Länge einer URL ist begrenzt, und nicht jedes Zeichen ist in einer URL verwendbar!

Chat Servlet Keine gute Idee! package com.ibm.ba;
import javax.servlet.*; import javax.servlet.http.*; import java.io.*; public class ChatServlet extends HttpServlet { private static StringBuffer buffer = new StringBuffer(); public void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { String name = request.getParameter("name"); String text = request.getParameter("text"); buffer.append(name + ": " + text + "<p>"); response.setContentType("text/html"); response.getWriter().print(buffer.toString()); } Keine gute Idee! Request URL:

J2EE Container Servlet-Instanzen werden HTTP-Requests vom J2EE-Container zugeteilt, daher kann State-Information nicht wie üblich in eigenen Instanzvariablen abgelegt werden! Aus dem gleichen Grund werden vom J2EE Container bei der Instantiierung von Servlets nur Default-Konstruktoren verwendet! Servlet1 Servlet2 Servlet3 Container

Virtuelle J2EE Container
Servlets können über mehrere Prozesse skaliert sein, daher ist die Verwendung von statischer Zustands-Information ebenfalls eingeschränkt! Lastbasierter URL Redirector Servlet1 Servlet1 Servlet2 Servlet2 Servlet2 Servlet3 Servlet3 Servlet4 Servlet4 Container 1 Container 2 Container 3 Virtueller Container

Problem Wie kann Zustands- oder Session-Information in Servlets abgelegt werden? Request Servlet1 Response Browser Response Servlet2 Request

Lösung Session-Context Information kann als URL-Parameter in generierten HTML-Seiten encodiert werden. Diese Methode funktioniert immer! Session-Context Information kann ebenfalls im Session-Context des Request-Objekts abgelegt werden. Diese Methode ist zwar theoretisch „sauberer“, funktioniert jedoch nur im Applikations-Context, und auch dort nicht immer  Cookie-Problematik! Alle andere Arten von Information sollten persistent gemacht werden, zum Beispiel in einer relationalen Datenbank.

MP3 Servlet Nicht gerade praktisch!
package com.ibm.ba; import javax.servlet.*; import javax.servlet.http.*; import java.io.*; public class MP3Servlet extends HttpServlet { public void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { byte[] buffer = new byte[0x10000]; String filename = request.getParameter(„name"); InputStream inputStream = new FileInputStream("E:/Audio/MP3/" + filename + ".mp3"); response.setContentType("audio/mp3"); int bytesRead = inputStream.read(buffer); while (bytesRead != -1) { response.getOutputStream().write(buffer, 0, bytesRead); bytesRead = inputStream.read(buffer); } Nicht gerade praktisch! Was passiert wenn das File nicht existiert? Wo ist der Packagename? Request URL:

Exceptions „Interne“ IOExceptions und ServletExceptions können normalerweise nicht behandelt werden, da die Ausgabe einer HTML Fehlerseite nicht mehr möglich ist  Log Normale IOExceptions und alle anderen Exceptions (inlusive RuntimeExceptions und Errors) sollten dem Anwender gemeldet werden  Log + HTML Fehlerseite In der Praxis ist es üblich in jeder Service-Methode mindestens einen try/catch Block unterzubringen.

Konfiguration Konfigurations-Information wird aus einem Servlet über die Methode getServletConfig() abgefragt. Die Konfigurations-Information selbst wird als Name/Wert Paare in einer Datei namens web.xml abgelegt: <web-app id="WebApp"> <display-name>samples</display-name> <servlet> <servlet-name>MP3Servlet</servlet-name> <display-name>MP3Servlet</display-name> <servlet-class>com.ibm.ba.MP3Servlet</servlet-class> <init-param> <param-name>mount</param-name> <param-value>E:/Audio/MP3/</param-value> </init-param> </servlet> </web-app>

WAR Files Ein WAR-File ist ein JAR/ZIP-File mit einer spezifischen Verzeichnis-Struktur. Alle für Servlets relevanten Files werden in solche WAR-Files verpackt.WAR-Files stellen eine Art Install-File für Servlet-basierte Web-Anwendungen dar! Der Ordner /WEB_INF/classes ist Root für alle applikations-spezifischen Java Class-Files und zugehörige Package-Ordner Der Ordner /WEB_INF enthält das Konfigurations-File web.xml Im einfachsten Fall wird ein WAR-File in einen Container deployed indem das File in einen vorbestimmten Ordner kopiert wird  TomCat.

Ausblick Die Generierung von HTML in Java ist selbst bei geringen Anforderungen nicht praktikabel  View (JSPs) Jede reale J2EE Anwendung wird Daten persistent speichern wollen  Model (JDBC, EJBs) Servlets übernehmen in realen Anwendungen nur die Steuerung  Controller

Teil III – JNDI / JDBC / JSP
Refresh Teil II Java Naming and Directory Interface (JNDI) Java Database Connectivity (JDBC) Java ServerPages (JSP)

Refresh Teil II Grundlagen Web Technologie Servlets Container

Force-Load Servlet package com.ibm.ba; import javax.servlet.*;
import javax.servlet.http.*; import java.io.*; public class ForceLoadServlet extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException { response.getWriter().print(„<HTML><HEAD><SCRIPT>“); response.getWriter().print(„function load() {this.location =´“ + request.getParameter(„url") + „´;}“); response.getWriter().println(„</SCRIPT></HEAD><BODY ONLOAD= ´javascript:load()´></BODY></HTML>“); } Request URL:

JNDI Das Java Naming and Directory API (JNDI) dient zum Zugriff auf „benamte“ und üblicherweise hierarchische Information  Model, hierarchische Datenbestände JNDI ist Teil von J2SE, da das API für alle Programmiermodelle geeignet ist. Wird hauptsächlich für Konfigurationsinformation verwendet, die über eine Installationseinheit hinaus sichtbar sein soll JNDI-Information wird heute üblicherweise in relationalen Datenbanken persistent gemacht

JNDI Übersicht java.lang.Object java.naming.Context
verwaltet Information Sub-Context verwaltet lookup() bind() rebind() unbind() java.naming.InitialContext Root-Context

JNDI Servlet Root-Context instantiieren JNDI erzeugt NamingExceptions
package com.ibm.ba; import javax.servlet.*; import javax.servlet.http.*; import java.io.*; import javax.naming.*; public class JNDIServlet extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { try { String name = request.getParameter(„name"), value = request.getParameter(„value"); Context context = new InitialContext(); if (value == null) { value = (String) context.lookup(name); } else { context.rebind(name, value); } response.getWriter().println("<HTML><HEAD><TITLE>JNDI</TITLE></HEAD><BODY>"); response.getWriter().println(„Name: „ + name + „<P>“ + „Value: „ + value + "</BODY></HTML>"); } catch (NamingException exception) { exception.printStackTrace(response.getWriter()); } Root-Context instantiieren JNDI erzeugt NamingExceptions Request URL:

JDBC Java Database Connectivity (JDBC) ist das Basis-API zum Zugriff auf SQL basierte Datenbanken  Model, relationale Datenbestände JDBC ist Teil von J2SE, da das API für alle Programmiermodelle geeignet ist. JDBC besteht hauptsächlich aus Interfaces. Hersteller von Datenbanken liefern eine JDBC Implementierung mit aus, die über ein Plug-In Verfahren eingeklinkt wird.

JDBC Übersicht javax.sql.DataSource java.sql.Connection
erzeugt Factory für Datenbank-Verbindungen Datenbank-Verbindung erzeugt java.sql.Statement SQL-Statement erzeugt java.sql.ResultSet java.sql.PreparedStatement Virtuelle Tabelle java.sql.CallableStatement

javax.sql.DataSource Repräsentiert eine Factory für Datenbank-Verbindungen Instanzen werden über JNDI konfiguriert und abgefragt „Pooled DataSources“ erlauben das transparente Vorhalten von Datenbank-Verbindungen  Connection-Pooling „XA DataSources“ unterstützen zusätzlich das 2-Phase-Commit Protokoll  Resource-Manager Das Interface löst die Klasse java.sql.DriverManager ab, da diese für das zentrische Programmiermodell ungeeignet ist  Connection-Pooling ist essentiell für J2EE!

java.sql.Connection Repräsentiert eine Factory für Datenbank-Verbindungen  Protokoll-Verbindung Das Erzeugen einer Datenbank-Verbindung ist teuer  Connection-Pooling! Ein J2EE Container kann gleichzeitig sowohl multiple Verbindungen zu verschiedenen Datenbanken vorhalten, als auch multiple Verbindungen zur gleichen Datenbank mit eventuell unterschiedlichen Eigenschaften

java.sql.Statement Instanzen dieses Interfaces repräsentieren SQL-Befehle Direkte Instanzen dieses Interfaces sind darauf ausgelegt bei jedem Datenbank-Zugriff unterschiedliche SQL-Befehle abzusetzen  „dynamisches SQL“ Query-Zugriffe geben virtuelle Tabellen als Ergebnis zurück, Update/Insert/Delete-Zugriffe geben die Anzahl der modifizierten Tabellenzeilen zurück. Jede Instanz dieses Interfaces kann zu einer Zeit nur für einen Datenbank-Zugriff verwendet werden! Zur Laufzeit-Optimierung ist asynchrone Stapelverarbeitung von SQL-Befehlen möglich

java.sql.PreparedStatement
Direkte Instanzen dieses Interfaces sind darauf ausgelegt den gleichen SQL-Befehl mehrfach hintereinander mit verschiedenen Parametern abzusetzen  „statisches SQL“ Als Laufzeit-Optimierung in J2EE nur in Verbindung mit applikations-spezifischem Statement-Pooling sinnvoll  besser: SQL Stored Procedures verwenden!

java.sql.CallableStatement
Instanzen dieses Interfaces sind für den Aufruf von SQL Stored Procedures ausgelegt Vorteil: SQL Stored Procedures erlauben massive Laufzeitgewinne, sowohl durch datenbankseitige Vorcompilierung von SQL-Befehlen als auch durch automatisch erzeugte und gewartete Redundanzen in der Datenbank-Struktur! Nachteil: SQL Stored Procedures sind wesentlich wartungsintensiver als dynamisches oder statisches SQL!

java.sql.ResultSet Repräsentieren virtuelle Tabellen, in denen mittels Cursor navigiert werden kann Erlauben neben der Abfrage von Werten auch Update/Insert/Delete Operationen! ResultSets halten eine aktive Verbindung zu betroffenen Tabellenzeilen in der Datenbank  Locking!

Query Servlet DataSource über JNDI abfragen
package com.ibm.ba; import javax.servlet.*; import javax.servlet.http.*; import java.io.*; import javax.naming.*; import javax.sql.DataSource; import java.sql.*; public class QueryServlet extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException { try { String queryString = request.getParameter(„queryString"); Context context = new InitialContext(); DataSource dataSource = (DataSource) context.lookup(this.getServletConfig().getInitParameter(„DataSourceName“)); Statement statement = dataSource.getConnection().createStatement(); ResultSet resultSet = statement.executeQuery(queryString); ResultSetMetaData metaData = resultSet.getMetaData(); while (resultSet.next()) { response.getWriter().print(„Row-Index = „ + resultSet.getRow()); for (int index = 0; index < metaData.getColumnCount(); index++) response.getWriter().print(„, „ + metaData.getColumnLabel(index) + „ = „ + resultSet.getString(index)); response.getWriter().println(„<P>“); } } catch (Throwable exception) exception.printStackTrace(response.getWriter()); DataSource über JNDI abfragen Connection & Statement erzeugen SQL query absetzen Daten und Meta-Daten abfragen Request URL:

JDBC Grundregeln Das Vorhalten von Datenbank-Verbindungen sollte immer der DataSource überlassen werden  Skalieren über Konfiguration, nicht über Code! Erst Verwendung von dynamischem SQL, dann Optimierung von kritischen SQL-Befehlen mittels SQL Stored Procedures! Stapelverarbeitung von SQL-Befehlen ist im zentrischen Programmiermodell immer aufwendig! Update/Insert/Delete Operationen sollten wegen des impliziten Lockings immer über ResultSets abgesetzt werden, nie über SQL-Befehle!

JSP Java ServerPages (JSP) ist eine Erweiterung von HTML für das Design von dynamischen Web-Seiten  View JSP-Seiten bestehen aus standard HTML, JSP Direktiven, JSP Scripting, und JSP Aktionen JSPs werden mittels eines JSP-Compilers in Java Servlets übersetzt  „verkehrte“ Servlets

Wichtigste JSP Direktiven
JSP Direktiven teilen dem JSP-Compiler für die Übersetzungsphase relevante Information mit. Syntax: Direktive %> Die Page-Direktive teilt dem JSP-Compiler Meta-Information über die JSP-Seite mit: Threadsicherheit, Servlet-Superklasse, etc. Die TagLib-Direktive erlaubt die Verwendung von benutzerdefinierten Tags in einer JSP-Seite Die Include-Direktive weist den JSP-Compiler an den Inhalt eines Files in das zu generierende Servlet aufzunehmen.

JSP Direktiven - Beispiel
<HTML> <HEAD> <TITLE>JSP Direktiven</TITLE> page buffer=”none” isThreadSafe=”no” errorPage=”/fehler.jsp” %> </HEAD> <BODY> taglib uri=” prefix=”custom” /> include file=”Seiteninhalt.html” %> </BODY> </HTML>

JSP Scripting JSP Scripting erlaubt die direkte Verbindung von Java Code mit HTML Deklarationen deklarieren Methoden und Variablen für das zu generierende Servlet  Syntax: <%! Deklaration %> Scriptlets sind Java-Codefragmente, die der JSP Compiler in die Service-Methode des zu generierenden Servlets einbauen soll  Syntax: <% Scriptlet %> Expressions sind Java-Ausdrücke, deren Evaluierungs-Ergebnis der JSP Compiler in das zu generierenden Servlet einbauen soll  Syntax: <%= Expression %>

JSP Scripting - Beispiel
<HTML> <HEAD> <TITLE>JSP Scripting</TITLE> </HEAD> <BODY> Millisekunden seit 1970: <%= System.currentTimeMillis() %> <P><P> <%! private int timesThree(int multiplier) { return multiplier * 3; } %> Vielfache von 3: <P> <% for (int index =0; index < 10; index++) { %> <%= index %>.Vielfaches: <%= this.timesThree(index) %> <P> <% } %> </BODY> </HTML> zur Laufzeit Evaluierungs- Ergebnis in HTML einfügen Definition einer Servlet-Methode Iteration Aufruf der neuen Servlet-Methode

JSP Aktionen JSP Aktionen sind Tags, die in Java-Code übersetzt werden und ähnlich wie Scriptlets/Expressions in die Service-Methode des zu generierenden Servlets einfließen Standard Aktionen werden von jedem JSP Compiler ünterstützt, benutzerdefinierte Aktionen sind über die Include-Direktive einbindbar Sobald Standard Aktionen ausgereift sind sollten JSP-Entwickler nur noch JSP Direktiven und JSP Aktionen benötigen, jedoch kein JSP Scripting! JSR 052 definiert eine neue Standard Tag Library für JSPs, die Spezifikation ist zur Zeit als Proposed Final Draft verfügbar.

Wichtigste Standard Aktionen
Die <jsp:useBean> Aktion assoziiert ein neues oder übergebenes Java-Objekt mit einem Namen Die <jsp:getProperty> Aktion liest ein Property aus einem Java-Objekt aus, konvertiert es in einen String und fügt das Ergebnis in die HTML-Ausgabe ein Die <jsp:setProperty> Aktion modifiziert ein Property aus einem Java-Objekt aus, indem es den gegebenen String in den passenden Java-Typ konvertiert Es gibt bis heute keine (verabschiedeten) Standard-Tags zum Zugriff auf Arrays oder Collections, dafür aber Standard-Tags zum Einbinden von Servlets oder JSPs.  Häufig fundamentales Mißvertändnis der J2EE Architektur mit kritischen Folgen für die Wartbarkeit!

JSP Aktionen - Beispiel
<HTML> <HEAD> <TITLE>JSP Aktionen</TITLE> </HEAD> <BODY> <jsp:useBean id=„datum“ class=„java.util.Date“ /> Stunde: <jsp:getProperty name=„datum“ property=„hours“ /> <P> Minute: <jsp:getProperty name=„datum“ property=„minutes“ /> <P> Sekunde: <jsp:getProperty name=„datum“ property=„seconds“ /> <P> </BODY> </HTML>

ViewBeans ViewBeans sind benutzerdefinierte Java-Klassen, die dem JavaBean Layout entsprechen ViewBeans sollten nur Properties besitzen, die Java Basis-Typen oder Strings sind  leichte Konvertierbarkeit für JSP Aktionen! ViewBeans werden aus Modell-Daten erzeugt, Exceptions beim Konvertieren werden in Servlets bearbeitet ViewBeans werden JSPs zur Darstellung/Modifikation übergeben  Komponenten-Vertrag zwischen Servlets und JSPs

Applikations-Architektur
Datenbank-Modellierer J2EE-Entwickler JNDI rufe Model Servlet JDBC erzeuge ViewBeans rufe View, übergebe ViewBeans JSP Web-Designer Model - View - Controller

Beispiel - JSP <HTML> <HEAD>
<TITLE>Artikel-Details</TITLE> </HEAD> <BODY> <jsp:useBean id="artikel" class="com.ibm.ba.ArtikelViewBean" scope="session" /> Name: <jsp:getProperty name="artikel" property="name" /> <P> Bestand: <jsp:getProperty name="artikel" property="quantity" /> <P> </BODY> </HTML> unter diesem Namen muß ein Servlet das ViewBean übergeben wichtig bei Übergabe von ViewBeans an JSPs File: jsp/ArtikelView.jsp

Beispiel - ViewBean package com.ibm.ba; public class ArtikelViewBean {
private final String name; private final int quantity; public ArtikelViewBean(String name, int quantity) { this.name = name; this.quantity = quantity; } public String getName() { return this.name; public int getQuantity() { return this.quantity;

Beispiel - Servlet im JSP definierter Name
package com.ibm.ba; import javax.servlet.*; import javax.servlet.http.*; import java.io.*; import javax.naming.*; import javax.sql.DataSource;import java.sql.*; public class ArtikelAbfrageServlet extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException { try { String artikelName = request.getParameter("name"); Context context = new InitialContext(); DataSource dataSource = (DataSource) context.lookup(this.getServletConfig().getInitParameter("DataSourceName")); Statement statement = dataSource.getConnection().createStatement(); ResultSet resultSet = statement.executeQuery ("SELECT * FROM SBAUMEI.ARTICLE WHERE NAME = '" + artikelName + "'"); resultSet.next(); ArtikelViewBean artikel = new ArtikelViewBean(resultSet.getString("NAME"), resultSet.getInt("QUANTITY")); request.getSession(true).setAttribute("artikel", artikel); this.getServletConfig().getServletContext().getRequestDispatcher("jsp/ArtikelView.jsp").forward(request, response); } catch (Throwable exception) { exception.printStackTrace(response.getWriter()); } im JSP definierter Name das Servlet übergibt das ViewBean im Session-Context, daher scope=session im JSP! Request URL:

Teil IV – Entwicklung Refresh Teil III Entwicklungs-Umgebungen
Kommandozeile Eclipse IBM WebSphere Studio Application Developer Container Tomcat BEA WebLogic IBM WebSphere Application Server

Refresh Teil III JNDI JDBC JSP

Entwicklungs-Umgebungen
Kommandozeile Überall verfügbar Not-Behelf Eclipse open source verfügbar für Windows und Linux IBM WebSphere Application Developer professionelle Entwicklungsumgebung auf Basis von Eclipse Integrierte J2EE Unterstützung weitere Java Entwicklungs-Umgebungen verfügbar

Kommandozeile - Installation
Standard Java Development Kit (JDK) java.sun.com J2EE Standard-Bibliotheken servlet.jar  Servlet API Bibliothek jndi.jar  JNDI API Bibliothek jdbc.jar  JDBC API Bibliothek xerces.jar  Standard XML Bibliothek CLASSPATH Die Umgebungsvariable CLASSPATH muß um einige dieser JAR-Files erweitert werden

Kommandozeile - Prozess
Aufbau der J2EE Verzeichnisstruktur Verzeichnis WEB-INF Verzeichnis WEB-INF/classes Übersetzung der Klassen in WEB-INF/classes javac [options] source-file Erstellen der Datei WEB-INF/web.xml Texteditor Erstellen eines WAR-Files jar cvf samples.war *.*

Eclipse Open Source Projekt  http://www.eclipse.org/
IBM-initiiertes Geschenk an die Java-Community Offenes Plug-In Design „Perspektiven“-Philosophie Quellcode wird beim speichern übersetzt Integrierter Debugger Zum Testen von Servlet/JSP Applikationen geeignet 

IBM WSAD WebSphere Studio Application Developer
Professionelle J2EE-Entwicklungsumgebung Basiert auf Eclipse Integrierte J2EE Unterstützung Integrierter J2EE Container für Test und Debug

Tomcat Teil des Apache Jakarta Projekts
Referenz-Implementierung für Servlet Container Open Source Projekt  Unterstützt Servlets und JSPs

BEA WebLogic Professioneller J2EE Container http://www.bea.com/
Vor allem bei kleinen und mittelgroßen Firmen beliebt War bis 2001 Marktführer

IBM WebSphere Application Server
Professioneller J2EE Container Vor allem bei mittleren und großen Firmen beliebt Seit 2002 Marktführer

Teil V –EJBs & Servlet Conversations
Einführung in Enterprise JavaBeans Entity Beans Session Beans Message Driven Beans Servlet Conversations

Enterprise JavaBeans - Definition
Die Enterprise JavaBeans Architektur ist eine Komponenten-Architektur für die Entwicklung und das Deployment von komponenten-basierten und verteilten Geschäftsanwendungen. Applikationen die der Enterprise JavaBeans Architektur entsprechen sind skalierbar, transaktional und multi-user secure.

Enterprise JavaBeans Enterprise JavaBeans integrieren viele J2EE Aspekte in einer einheitlichen und konsistenten Architektur  JDBC, JTA, JMS, IIOP, etc Enterprise JavaBeans sind immer noch in der Entwicklung begriffen. Mit der Verfügbarkeit von EJB 2.0 Containern wird dieses Jahr die erste „erwachsene“ Entwicklungsstufe erreicht.

Enterprise JavaBeans Es gibt drei Arten von Enterprise JavaBeans:
Entity Beans modellieren persistente Entitäten im Sinne der relationalen Algebra  Model, Business-Objekte Session Beans modellieren Vorgangsdaten  Model, Conversational State Message Driven Beans modellieren Observer, die auf asynchrone Nachrichten reagieren  Model, asynchrone Datenverarbeitung Enterprise JavaBeans existieren in speziellen EJB Containern  nicht verwechslen mit Servlet Containern!

Entity Beans Entity Beans lösen den klassischen Konflikt zwischen Datenmodellierung und Objektmodellierung Entity Beans sind persistent und bilden Relationen untereinander. Entity Beans vereinigen Model-Daten mit Geschäfts-Logik Entity Beans sind seit EJB 1.1 Standard und sind seit EJB 2.0 wesentlich erweitert id name straße ort vereinfacht modelliert jedes Entity Bean eine Tabelle einer relationalen Datenbank, und jede Entity Bean Instanz eine Zeile darin. Kunden-Tabelle

Entity Beans - Beispiel
* 1 .. * EmmyAward Person winner * 1 participant Entity-Relationship Diagramme können 1:1 in ein Entity Bean basiertes Objekt-Modell übersetzt werden. 1 .. * 1 .. * poster 1 1 winner 1 1 picture EmmyAsset MediaEntity 1 video 1 * background material 1 Series Episode 1 *

Entity Beans - Interfaces
Jedes Entity Bean externalisiert sein gesamtes Verhalten über eine Reihe von Interfaces. Home Interfaces definieren die Funktion der „Klasse“ eines Entity Beans, während Instanz-Interfaces die Funktionen der Instanzen externalisieren. Typische Aufgaben für Home Interfaces sind das Erzeugen und Auffinden von Instanzen. Home Interfaces sind Singletons, die über JNDI abgefragt werden. Home Interface local remote Entity Bean Instance Interface local remote

Entity Beans - Interfaces
Remote Interfaces erlauben den container-übergreifenden Zugriff auf Entity Beans, Local Interfaces dagegen sind auf Zugriffe innerhalb eines Containers beschränkt! Remote Interfaces propagieren Parameter und Resultate als Kopien, lokale Interfaces dagegen als Referenzen! Lokale Interfaces gibt es erst seit EJB 2.0! Remote Home Interface Methoden geben immer die Remote-Sicht auf Instanzen zurück, Local Home Interfaces Methoden immer die lokale Sicht auf Instanzen! Home Interface local remote Entity Bean Instance Interface local remote

Entity Beans - Persistenz
Die Persistenz von Entity Beans kann auf zwei Arten erreicht werden: „Bean Managed Persistence“ verlangt Code vom EJB Programmierer zur Persistierung von Entity Beans. Dafür ist diese Methode auf alle Arten von Datenspeichern anwendbar. „Container Managed Persistence“ verlangt nur ein symbolisches Mapping von Entity Bean Properties auf Datenbankfelder während des EJB Deployments. Dafür ist diese Methode im Normalfall auf relationale Datenbanken beschränkt. Container Managed Persistence sollte bevorzugt verwendet werden, da durch diese Vorgehensweise eine Abstraktion des Anwendungs-Codes von der unterliegenden Datenbank-Struktur erreicht wird!

Session Beans Session Beans modellieren nicht-persistente Sitzungen zwischen jeweils einem Client und einem Server „Stateful Session Beans“ vereinfachen das Verwalten von Session-Context Information über viele Servlets hinweg. Der Spezialfall „Stateless Session Beans“ wird oft für Remote-APIs verwendet. Session Beans sind seit EJB 1.0 Standard. Servlet 1 Servlet 2 Servlet 3 sessionId=42 sessionId=42 Session Bean

Session Beans - Interfaces
Analog zu Entity Beans externalisieren Session Beans Ihr Verhalten in bis zu 4 Interfaces: Remote Home Interface, Local Home Interface, Remote Interface, Local Interface. Home Interfaces definieren die Funktion der „Klasse“ eines Session Beans, während Instanz-Interfaces die Funktionen der Instanzen externalisieren.Typische Aufgaben für Home Interfaces sind das Erzeugen und Auffinden von Instanzen. Home Interfaces sind Singletons, die über JNDI abgefragt werden. Home Interface local remote Session Bean Instance Interface local remote

Message Driven Beans Message Driven Beans stellen Konsumenten für asynchrone Nachrichten dar. Message Driven Beans finden überall dort Verwendung wo eine synchrone Informationsverarbeitung nicht möglich oder erwünscht ist  Stapelverarbeitung, Workflow Message Driven Beans sind seit EJB 2.0 Standard Da Message Driven Beans nie von Clients direkt referenziert werden, erfüllen alle den gleichen Home und Instance-Interface Kontrakt.

Servlet Conversations
Servlet Conversations bilden Abläufe zwischen mehreren Servlets/JSPs. HTML Forms werden verwendet um Benutzereingaben entgegenzunehmen. Die Daten stehen wie URL Parameter im Request-Objekt des Nachfolge-Servlets zur Verfügung. URL Parameter und Session Beans sollten verwendet werden um Servlet Context Informationen über mehrere Seiten hinweg zu speichern. Servlet JSP HTML Servlet

HTML Forms – Vorgänger-JSP
<html> <head> <title>Servlet Form Test</title> </head> <body> <h1><font color="magenta">This form invokes a servlet as its action.</font></h1> <form METHOD=GET ACTION=„ <h4>Please enter your company's name:</h4> <input TYPE="text" NAME="companyname" SIZE="30"> <h4>What web services does your company need?</h4> <p> <br><input TYPE="checkbox" NAME="hosting" CHECKED> Web Server Hosting <br><input TYPE="checkbox" NAME="design" CHECKED> Web Page Design <br><input TYPE="checkbox" NAME="javadev" CHECKED> Java Servlets and JSP Development <h4>How many people are in your company?</h4> <p> <input TYPE="radio" NAME="numberofpeople" VALUE="oneplus"> 1 to 99 <br> <input TYPE="radio" NAME="numberofpeople" VALUE=" hundredplus"> 100+<br> <p><input TYPE="submit" VALUE="Submit Form"> </form> </body> </html>

HTML Forms – Nachfolge-Servlet
public void doGet ( HttpServletRequest request, HttpServletResponse response ) { String companyname = request.getParameter("companyname"); String numberofpeople = request.getParameter("numberofpeople"); String hosting = request.getParameter("hosting"); String design = request.getParameter("design"); String javadev = request.getParameter("javadev"); ... }

Typische Anwendungs-Struktur
Session Bean sessionId=42 sessionId=42 Servlet 1 Servlet 2 Servlet 3 Form-Daten Form-Daten JSP 1 JSP 2 JSP 3 Entity Bean 1 Entity Bean 2 Entity Bean 3 JDBC

Kleine Beispiel-Anwendung
Abfragen/Ändern von User-Id und Password Verwendung von Servlets, JSPs, Session Beans, und HTML Forms

Teil VI –EJB 1.1 Refresh Teil V
Programmierung von Enterprise JavaBeans Session Beans Entity Beans Ejb-JAR Files e-Business Beispiel

Externer Session Bean Lifecycle
NoSuchObjectException nicht existent und nicht referenziert nicht existent und referenziert Referenz freigeben Container Crash Bean Timeout System Exception ejbObject.remove() home.remove(handle) home.create(...) container crash bean timeout existent und nicht referenziert Referenz freigeben existent und referenziert handle.getEJBObject() Business Logik

Interner Session Bean Lifecycle
nicht existent create(...) newInstance() setSessionContext(sc) ejbCreate(...) ejbActivate() Time-Out ejbRemove() ejbPassivate() bereit

Session Bean Komponenten-Vertrag
(Remote) Home Interfaces erben von javax.ejb.EJBHome EJBObject create(...) throws java.rmi.RemoteException, javax.ejb.CreateException (Remote) Instance Interfaces erben von javax.ejb.EJBObject void remove() javax.ejb.Handle getHandle() javax.ejb.EJBHome getEJBHome() Business Methoden - müssen java.rmi.RemoteException deklarieren! Session Bean Implementierungen erben von java.lang.Object Default-Konstruktor void setSessionContext(javax.ejb.SessionContext) javax.ejb.SessionContext getSessionContext() void ejbCreate(...) throws javax.ejb.CreateException void ejbRemove() throws javax.ejb.RemoveException void ejbActivate(), void ejbPassivate() Business Methoden – dürfen nicht java.rmi.RemoteException deklarieren!

Session Bean Handles Session Bean Servlet 1 Servlet 2 Servlet 3 JSP 1
serialized SB handle serialized SB handle Servlet 1 Servlet 2 Servlet 3 Form-Daten Form-Daten JSP 1 JSP 2 JSP 3 Entity Bean 1 Entity Bean 2 Entity Bean 3 JDBC

Session Beans - Zusammenfassung
Session Beans leben bis zu einem im EJB-Container einstellbaren Time-Out, bis sie explizit per remove() gelöscht werden, oder aber bis zu einem EJB-Container-Crash Session Bean Instanzen können vom Container temporär in den „nicht existent“ Zustand versetzt (i.e. serialisiert) werden, daher Vorsicht beim Verwenden von transienten Variablen Zustandsbehaftet Session Beans werden verwendet um auf Session Context Information über viele Web-Server hinweg zuzugreifen  Handles Stateless Session Beans werden verwendet um APIs remote zugreifbar zu machen  Fassade

Externer Entity Bean Lifecycle
NoSuchObjectException nicht existent und nicht referenziert nicht existent und referenziert Referenz freigeben ejbObject.remove() home.remove(Handle) home.remove(EJBObject) SQL DELETE home.create(...) home.remove(Handle) SQL DELETE SQL INSERT Referenz freigeben existent und nicht referenziert existent und referenziert home.find(...) oder handle.getEJBObject() Business Logik

Interner Entity Bean Lifecycle
nicht existent newInstance() + setEntityContext(ec) unsetEntityContext(ec) - ejbLoad() - ejbStore() ejbFindX(...) - ejbCreate(...) + ejbPostCreate(...) ejbActivate() pooled bereit - ejbRemove() ejbPassivate()

Entity Bean Komponenten-Vertrag
(Remote) Home Interfaces erben von javax.ejb.EJBHome EJBObject create(...) throws java.rmi.RemoteException, javax.ejb.CreateException EJBObject/Collection findByX(...) throws java.rmi.RemoteException, javax.ejb.FinderException (Remote) Instance Interfaces erben von javax.ejb.EJBObject void remove() javax.ejb.Handle getHandle() javax.ejb.EJBHome getEJBHome() Business Methoden - müssen java.rmi.RemoteException deklarieren! Entity Bean Key Implementierungen erben von java.lang.Object equals(java.lang.Object) implementiert Inhalts-Vergleich, nicht Referenz-Vergleich! hashcode() basiert auf Inhalt, nicht auf Referenz!

Entity Bean Komponenten-Vertrag
Entity Bean Implementierungen erben von java.lang.Object void setEntityContext(javax.ejb.EntityContext) void unsetEntityContext() Key ejbCreate(...) throws javax.ejb.CreateException void ejbPostCreate(...) throws javax.ejb.CreateException Key/Collection ejbFindX(...) throws javax.ejb.CreateException void ejbRemove() throws javax.ejb.RemoveException void ejbActivate(), void ejbPassivate() void ejbLoad(), void ejbStore() Business Methoden – dürfen nicht java.rmi.RemoteException deklarieren! Entity Bean Zusatzkontrakt für Container Managed Persistence ejbRemove() , ejbLoad() und ejbStore() müssen keine Aktionen enthalten ejbCreate(...) muß nur den Objektzustand initialisieren ejbFindX(...) müssen nicht implementiert werden Mappings werden in Zusatz-Dateien definiert (container-abhängiges Format)

Entity Beans - Zusammenfassung
Entity Beans leben bis sie explizit per remove() gelöscht werden Entity Bean Instanzen können vom Container temporär in den „nicht existent“ Zustand versetzt (i.e. serialisiert) werden, daher Vorsicht beim Verwenden von transienten Variablen Bei Bean Managed Persistence müssen die ejbCreate(), ejbRemove(), ejbLoad() und ejbStore() Methoden die Persistenz handhaben Bei Container Managed Persistence wird die Persistenz beim Deployment über ein Mapping definiert Bean Managed Persistence und Container Managed Persistence kann gleichzeitig verwand werden

EJB-JAR Files Ähnlich wie WAR Files sind EJB-JAR Files JAR/ZIP-Files mit einer spezifischen Verzeichnis-Struktur. Alle für EJBs relevanten Files werden in solche EJB-JAR Files verpackt. EJB-JAR Files stellen eine Art Install-File für EJBs dar! Der Ordner /bin enthält alle applikations-spezifischen Compilate Beim Deployment werden in /bin zusätzliche Klassen generiert  Stubs, Skeletons & Ties Der Ordner /ejbModule/META-INF enthält das Konfigurations-File ejb-jar.xml

Beispiel e-Business Entity Bean „Artikel“ mit den Attributen identitaet, name und preis Session Bean „Einkaufswagen“ mit einer Liste von Artikel-Identitäten und Stückzahlen Servlet+JSP mit Liste aller Artikel, Möglichkeit per Klick einen Artikel in den Einkaufswagen zu bewegen, und Button zum Verzweigen auf eine zweite Bestellseite Servlet+JSP mit Inhalt des Einkaufswagens zum Bestellen Utility-Servlet zum Initialisieren des Artikel-Bestandes

Beispiel e-Business Einkaufswagen Artikel Servlet Bestell Servlet
serialized SB handle & Form Daten Bestell Servlet Bestell JSP Artikel JSP Artikel EJB (CMP) JDBC

Java 2 Enterprise Edition (J2EE)

Ähnliche Präsentationen

Präsentation zum Thema: "Java 2 Enterprise Edition (J2EE)"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Java 2 Enterprise Edition (J2EE)

Ähnliche Präsentationen

Präsentation zum Thema: "Java 2 Enterprise Edition (J2EE)"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback