Webtechnologien. Vorlesung Informatik Dr. rer. nat. Harald Sack Institut für Informatik Friedrich Schiller Universität Jena. Sommersemester 2006

Transkript

1 Vorlesung Informatik Dr. rer. nat. Harald Sack Institut für Informatik Friedrich Schiller Universität Jena Sommersemester

2 Vorlesung Nr Web Programmierung Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 2

3 Teil I: Internet und WWW 1. Einstieg: Internet 2. World Wide Web 3. Web Programmierung 4. Sicherheit im WWW 5. Web-Services 6. WWW-Suchmaschinen Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 3

4 3. Web Programmierung 3.1 Verteilte Programmiermodelle 3.2 RPC 3.3 RMI 3.4 CORBA 3.5 Java Servlets / Java Server Pages / Java Beans 3.6 Enterprise Java Beans Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 4

5 3.1 Verteilte Programmiermodelle Client-Server Konzept Verteilte Anwendungen im WWW werden (in der Regel) als Client- /Server-System realisiert Vereinfachung durch Trennung von Dienstanbieter (Server) und Dienstbenutzer (Client) Konzepte für die Implementation von Diensten Remote Procedure Call (RPC) Remote Method Invocation (RMI) CORBA Client Server Anforderung auf Ergebnis warten Antwort t t Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 5

6 3.1 Verteilte Programmiermodelle Client-Server Dynamik Serverseitige Funktionen Webserver-Funktionalität Generierung und Auslieferung von HTML-Dokumenten nur Benutzerschnittstelle für Client Verflechtung mit Dritt-Systemen zum Zugriff auf Produktdatenbanken Warenwirtschaftsysteme (Lagerhaltung) Produktionsplanung (Bestellstatus) Buchhaltungssysteme Kreditprüfung, Abwicklung, Zahlung Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 6

7 3.1 Verteilte Programmiermodelle Client-Server Architekturen Two-Tier Architektur Client kommuniziert mit Server-Rechner, der selbst alle anfallenden Aufgaben alleine erledigt Tier 1 Tier 2 Netzwerk Datenbank Client Web Server Application Server Database Server - nicht skalierbar - nicht effizient Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 7

8 3.1 Verteilte Programmiermodelle Client-Server Architekturen Three-Tier Architektur - nicht skalierbar - nicht effizient Trennung Database Server von Web Server / Application Server Application Server delegiert Verarbeitung an Tier 3 Tier 1 Tier 2 Tier 3 Netzwerk Netzwerk Datenbank Client Web Server Application Server Database Server Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 8

9 3.1 Verteilte Programmiermodelle Client-Server Architekturen Client N-Tier Architektur Vollständige Trennung von Funktion und Administration jeder Server für seine Aufgabe optimiert ermöglicht große Zahl gleichzeitiger Zugriffe Internet Datenbank Web Server Application Server Database Server Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 9

10 XML-Derivate XSD JavaApplets DOM XML JavaScript dynamisches HTML CGI Schnittstelle Web Services EJB JSP JavaServlets URI HTML CSS WWW-Server Programmierung Browser Client http WWW Server verteilte Programmiermodelle Caching Cookies WebBugs ssl soap Proxy-Server Caching RPC RMI CORBA Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 10

11 3.2 Remote Procedure Call (RPC) Funktionsaufruf auf entfernten Rechnern über das Internet (RFC 1057 und RFC 1831) Spezifiziert eigene Transfersyntax (XDR, External Data Representation, RFC 1014) zur Koordination von Repräsentant des Remote Objects, übernimmt Kommunikation Client-Requests und Server Responses Client dowork() Server Ermöglicht lokal Ausführung der Methode/Funktion Stub RPC-Layer Skeleton RPC-Layer Transportschicht (TCP/IP) Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 11

12 3.2 Remote Procedure Call (RPC) Client Stub RPC erfolgt transparent Bsp.: lokaler Prozeduraufruf count = read (fd, buff, nbytes) lokaler Stack lokale Variablen Hauptprogramm nbytes Compiler buf fd Linker Bibliothek read Rücksprungadr. lokale Variablen von read Stackpointer Betriebsystem Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 12

13 3.2 Remote Procedure Call (RPC) Client Stub RPC erfolgt transparent Bsp.: entfernter RPC Prozeduraufruf count = r_read (fd, buff, nbytes) Compiler lokaler Stack lokale Variablen Hauptprogramm nbytes buf Linker Bibliothek r_read fd Rücksprungadr. Stackpointer send an remote Server read fd / buff / nbytes Client Stub erzeugt Nachricht mit Aufrufparametern (Marshalling) Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 13

14 3.2 Remote Procedure Call (RPC) Server Stub (Skeleton) Remote Server send an local Server read fd / buff / nbytes (Demarshalling) Ergebnis portmapper Betriebsystem Server Stub (Skeleton) entpackt Parameter und initiiert Prozeduraufruf Server Stub (Skeleton) erzeugt Nachricht mit Ergebnis (Marshalling) remote Stack lokale Variablen Hauptprogramm nbytes buf fd Rücksprungadr. lokale Variablen von r_read Stackpointer Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 14

15 3.2 Remote Procedure Call (RPC) Remote Procedure Call (RPC) Vorgehen: Anwendung wird in Client-Seite und Server-Seite aufgeteilt Verständigung zwischen Client- und Server-Seite via RPC Client-Seite: Deklaration der auf dem Server aufgerufenen Funktionen als remote Compiler bettet RPC-Prozeduren mit in den Code der Anwendung Server-Seite: Implementation der gewünschten remote -Operationen Deklaration der Operationen als RPC-Server-Funktionen RPC nutzt TCP/UDP-Port 111 Portmapper-Daemon muss ankommende Daten an entsprechende Server-Anwendung weiterleiten RPC-Kommunikation erfolgt synchron Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 15

16 3.2 Remote Procedure Call (RPC) Remote Procedure Call (RPC) RPC-Kommunikation erfolgt synchron Remote Prozedur aufrufen Rückkehr vom Prozeduraufruf Client send auf Ergebnis warten receive send t Server Anforderung Lokale Prozedur aufrufen und Ergebnis zurückgeben Antwort receive receive receive t Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 16

17 3.2 Remote Procedure Call (RPC) Client-Server und Remote Procedure Call (RPC) Problem: Unterschiedliche Rechnerarchitekturen (z.b. Big Endian / Little Endian) Unterschiedliche Betriebsysteme Programmierer müssten Umrechnungs-/Konvertierungsroutinen vorsehen External Data Representation (XDR) automatisiert alle notwendige Konvertierungsmaßnahmen kein XDR-Funktionsaufruf notwendig spezieller XDR-Compiler fügt der Datendeklaration die entsprechenden Konvertierungsroutinen hinzu Verwenden einheitliches, Plattform-neutrales Datenformat Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 17

19 3.3 Remote Method Invocation (RMI) Remote Method Invocation (RMI) Objekt-Objekt Kommunikation zwischen verschiedenen Java-Virtual- Machines Klassenbibliothek java.rmi.* RPC-Implementierung in objektorientierter Java-Umgebung erlaubt Lokalisation entfernter Objekte über lokalen Namensdienst (Registry) und Kommunikation mit entfernten Objekten RPC erlaubt lediglich Transfer von Aufruf-Parametern RMI erlaubt vollständige Objekte als Parameter hohes Abstraktionsniveau, d.h. die eigentliche Kommunikation bleibt unsichtbar Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 19

20 3.3 Remote Method Invocation (RMI) Verteilte Objekte Remote Objects Client Rechner Client Client ruft Methode auf Server Rechner Server Status Methoden Objekt Schnittstelle Objekt Proxy / Stub Skeleton Client Betriebsystem Netzwerk Server Betriebsystem Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 20

21 3.3 Remote Method Invocation (RMI) Remote Object Declaration Objekt Schnittstelle // auf Server- und Clientseite import java.rmi.*; Remote Object interface remoteinterfaceid extends Remote{ Methoden } // auf Serverseite class remoteclassid extends UnicastRemoteObject implements remoteinterfaceid{ Implementierung der Methoden } Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 21

22 3.3 Remote Method Invocation (RMI) RMI Naming Service 2 Lokalisierung Naming.lookup() RMI-Registry 1 Registrierung Naming.bind() Server Client Remote Object 3 Aufruf Remote Object Remote Object Remote Object Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 22

23 3.3 Remote Method Invocation (RMI) RMI Registry Naming-Service übernimmt Zuordnung zwischen Namen und Objekt liefert bei Aufruf (Servername, Objektname) eine Objektreferenz (Remote Reference) zurück muss auf jeder Maschine installiert sein, auf der exportierte Objekte existieren Zugriff erfolgt über java.rmi.naming-klasse bind (Registrierung eines entfernten Objekts) rebind lookup (Erzeugen einer Referenz auf ein Stub-Objekt) unbind list Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 23

24 3.3 Remote Method Invocation (RMI) RMI Binding RemoteClassId remoteobjectid; try { Naming.rebind ( Service Name, remoteobjectid); } catch (Exception E) { System.out.println( Registry not found: +e); } Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 24

25 3.3 Remote Method Invocation (RMI) RMI Look-Up Objektreferenz (remote reference) RemoteInterfaceId localobjectid; try { localobjectid = (RemoteInterfaceId) Naming.lookup (url + Service Name ); } catch (Exception e) { System.out.println( No such service or registry\n ); } Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 25

26 3.3 Remote Method Invocation (RMI) Remote Method Invocation (RMI) Client Java Remote Method Protocol (JRMP) Server Stub Remote Reference Layer Transportschicht (TCP/IP) Skeleton Verwendete Kommunikationsprotokolle: RMI IIOP zur Integration in CORBA JRMP (Java Remote Method Protocol) = Standardprotokol für RMI RMI über HTTP getunnelt zur Umgehung von Firewalls RMI über SSL zur sicheren Kommunikation Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 26

27 3.3 Remote Method Invocation (RMI) RMI Ablauf Client ruft Repräsentanten (Stub, wird mit RMI-Compiler rmic erzeugt) des Remote-Objekts auf dem Stub gegenüberliegender Kommunikationsendpunkt (Skeleton) verwaltet RMI auf Server-Seite vermittelt Aufruf und übergebene Parameter an angefragte Methode (Marshalling) übergebene Objekte (Call-by-Value) müssen zuvor serialisiert werden dynamisches Laden von Byte-Code, wenn benötigte Klasse nicht auf dem Ziel-Rechner definiert ist (RMIClassLoader) abschliessend übergibt Skeleton die Rückgabewerte (Demarshalling) zurück an Stub Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 27

29 3.4 Common Object Request Broker (CORBA) standardisierte Middleware-Architektur zur Realisierung von verteilten Anwendungen in einer heterogenen Rechnerumgebung Rechnerarchitekturen Betriebsysteme Programmiersprachen 1994 von Object Management Group spezifiziert definiert eine sprachunabhängige Schnittstellenbeschreibung (Interface Definition Language) RPC-Layer wird durch Schlüsselkomponente Object Request Broker (ORB) realisiert erlaubt transparente Anfrage an ein Server-Objekt: ermöglicht Auffinden des Server-Objekts, Parameterübergabe an das Server-Objekt und Transport der Rückgabewerte an den Client Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 29

30 3.4 Common Object Request Broker (CORBA) CORBA Architektur Client IDL Server IDL Server IDL Stub Skeleton Skeleton Object Request Broker 1 IIOP Object Request Broker 2 -General InterORB Protocol (GIOP) definiert Nachrichtenformat -Internet Inter-ORB Protocol (IIOP) spezifiziert Austausch von GIOP-Nachrichten Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 30

31 3.4 Common Object Request Broker (CORBA) CORBA Common Object Request Broker Server Client Language Binding Cobol C++ Ada Java C IDL IDL rein deklarativ, keine Implementation Stub Skeleton Object Request Broker IIOP -IDL spezifiziert -Attribute, Super-Klassen, Exceptions, Ereignisse, Methoden Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 31

32 3.4 Common Object Request Broker (CORBA) CORBA Common Object Request Broker CORBA Services stellen Basis-Infrastrukturdienste zur Verfügung Naming Service Zuordnung zwischen Namen und Objektreferenzen (White Pages) Object Trader Service Lokalisation von Objekten nach angebotenem Dienst (Yellow Pages) Event Service Austausch von Nachrichten über Ereignisse Transaction Service Transaktionsorientierte Verarbeitung für verteilte Anwendungen Database Services Schnittstelle für Datenbankoperationen Distributed Component Object Model (DCOM) Microsofts auf ActiveX basierende CORBA Variante (nur für Windows und MAC OS verfügbar) Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 32

33 3.4 Common Object Request Broker (CORBA) CORBA Common Object Request Broker Vorteile: offener Herstellerunabhängiger Standard es existieren zahlreiche Implementierungen Plattform- und Programmiersprachenunabhängig besonders für den Einsatz in heterogenen Umgebungen geeignet. Nachteile: kommerzielle ORBs sind relativ teuer hoher Implementierungs-Overhead bei kleinen Anwendungen relativ hoher Einarbeitungsaufwand (insbesonders bei C++). hoher Protokoll-Overhead (insbesonders bei IIOP). Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 33

34 3.4 Common Object Request Broker (CORBA) CORBA - Anwendungsentwicklung 3 5 Client 1 Definition der Schnittstelle mit OMG IDL 2 IDL Compiler für Java/C++ C++ Skeleton Code C++ Header 4 Implementierung der Schnittstelle Implementierung des Servers 6 7 Compiler Linker Server Anwendung Server Java Stub Client Implementierung Java Compiler = Aus IDL-Datei generierter Code = Vom Entwickler erstellter Code = erzeugt = include Beziehung Client Anwendung Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 34

35 3.4 Common Object Request Broker (CORBA) CORBA Mini-Anwendungsbeispiel Interface-Definition: ServerInfo.idl interface ServerInfo{ boolean getserverenv( in string varname, out string varvalue); }; IDL-File kompilieren: idl ServerInfo.idl für Server ServerInfo.cpp ServerInfo.h ServerInfo_skel.cpp ServerInfo_skel.h für Client Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 35

36 3.4 Common Object Request Broker (CORBA) CORBA Server-Definition Header-File: ServerInfo_Impl.h Class ServerInfo_impl: virtual public POA_ServerInfo{ virtual CORBA::Boolean getserverenv( const char* varname, CORBA::String_out varvalue) throw(corba::systemexception); }; Skeleton beinhaltet abstrakte Klasse POA_ServerInfo Server muss virtuelle Methoden der Skeleton-Klasse implementieren (Servant). Object-Adapter (POA) ruft virtuelle Methode getserverenv() im Skeleton auf Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 36

37 3.4 Common Object Request Broker (CORBA) CORBA Server-Definition (2) Implementierung ServerInfo_Impl.cpp CORBA::Boolean ServerInfo_impl::getServerEnv( const char* varname, CORBA::String_out varvalue) throw(corba::systemexception) { char* val= getenv(varname); if (val) varvalue= CORBA::string_dup(val); else varvalue= CORBA::string_dup(""); return val!= 0; } Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 37

38 3.4 Common Object Request Broker (CORBA) CORBA Server-Definition (3) Main-Funktion des Serverprozesses (C++) int main(int argc, char* argv[]) { CORBA::ORB_var orb; try { Initialisierung des ORBs orb = CORBA::ORB_init(argc, argv); Initialisierung des Object-Adapters (POA)CORBA::Object_var poaobj= orb->resolve_initial_references("rootpoa"); PortableServer::POA_var rootpoa = PortableServer::POA::_narrow(poaObj); Aktivierung des POA-Managers PortableServer::POAManager_var manager = rootpoa->the_poamanager(); manager->activate(); Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 38

39 3.4 Common Object Request Broker (CORBA) CORBA Server-Definition (4) Instanzierung und Registrierung des Servants ServerInfo_impl sinfoimpl(rootpoa); ServerInfo_var sinfo= sinfoimpl._this(); Speichern der serialisierten IOR (Interoperable Object Reference) CORBA::String_var ior= orb->object_to_string(sinfo); ofstream out("serverinfo.ref"); out << ior << endl; Starten des ORBs orb->run(); Abfangen von CORBA System-Exceptions } catch(const CORBA::Exception &ex) { } return 0; } Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 39

40 3.4 Common Object Request Broker (CORBA) CORBA Java Client public static void main(string[] args) { try { ímport org.omg.corba.* ORB initialisieren: orb = ORB.init(args, null); Lesen der Objektreferenz (IOR) BufferedReader in = new BufferedReader( new FileReader("ServerInfo.ref")); org.omg.corba.object obj= orb.string_to_object(in.readline()); ServerInfo sinfo= ServerInfoHelper.narrow(obj); Zugriff auf (entferntes) CORBA-Objekt StringHolder varvalue= new StringHolder(); boolean defined = sinfo.getserverenv("os",varvalue)); }catch (org.omg.corba.systemexception ex){ } } Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 40

42 3.5 Java Servlets, Java Server Pages und Java Beans Java Servlets Serverseitige Java Komponenten werden in speziellem Servlet-Container auf dem WebServer ausgeführt Web-Server WWW-Client HTTP Servlet Container Servlet 1 Servlet 2 Aufgaben Servlet-Container: Lifecycle Management der Komponenten Multithreading der Methodenaufrufe bei Client Anfragen DBMS JDBC Servlet 3 Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 42

43 3.5 Java Servlets, Java Server Pages und Java Beans Java Servlet Lebenszyklus Server Servlet Code Load Laden der Servlet-Klasse Erzeugen einer Instanz Ausführen der init()-methode Servlet Code Server Client prüfen auf neuere Version des *.class-files: ev. neu laden Handle Client Requests Ausführen der Methode service() Server Servlet Code Unload z.b. Herunterfahren des Servers Ausführen der destroy()-methode garbage collection Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 43

44 3.5 Java Servlets, Java Server Pages und Java Beans Java Servlet Programmierung erweitert abstract class javax.servlet.http.httpservlet (Subklasse von GenericServlet) service() wird nicht überschrieben überschreiben der Methoden doget(), dopost(), doput(), dodelete() Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 44

45 3.5 Java Servlets, Java Server Pages und Java Beans Java Servlet Programmierung Hello World package hello_world; import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class HelloWorld extends HttpServlet { public void doget(httpservletrequest req, HttpServletResponse res) throws ServletException, IOException { res.setcontenttype("text/html"); PrintWriter out = res.getwriter(); out.println("<html>"); out.println("<head><title>hello World</TITLE></HEAD>"); out.println( <BODY><H1>Hello World</H1></BODY></HTML>"); } } Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 45

46 3.5 Java Servlets, Java Server Pages und Java Beans Java Servlet Bereitstellung Standardisiert über Web-Archiv (WAR) statische HTML-Seiten Dynamische Ressourcen WEB-INF Index.html Deployment Descriptor web.xml classes Servlet1.class Servlet2.class WAR Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 46

47 3.5 Java Servlets, Java Server Pages und Java Beans Java Servlet Bereitstellung Deployment Descriptor web.xml teilt Laufzeitumgebung mit, wie die dynamischen Komponenten zubehandeln sind z,.b. Zuordnung Servletname Servlet-Klasse / URL <?xml version="1.0" encoding="iso "?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" " <web-app> <servlet> </servlet> <servlet-mapping> </servlet-mapping> </web-app> Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 47

48 3.5 Java Servlets, Java Server Pages und Java Beans Java Server Pages Deklarative API für den Zugriff auf JavaBeans-Komponenten Aus JSP-Dokumenten wird beim ersten Aufruf automatisch ein Servlet generiert Web-Server WWW-Client HTTP Servlet Container bilden Schnittstelle zum WWW-Client JSP 1 JSP 2 Servlet 1 Servlet 2 JDBC Bsp. Tomcat Servlet 3 DBMS Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 48

49 3.5 Java Servlets, Java Server Pages und Java Beans Java Server Pages Konstrukte Scriptlets <% out.println( helloworld ); %> JSP-Ausdrücke <%= request.getparameter( user ); %> Deklarationsanweisungen <%! Public String[] Liste = { a, b }; %> Interpreter-Anwesungen <%@ include file= foobar.jsp %> Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 49

50 3.5 Java Servlets, Java Server Pages und Java Beans Java Server Pages Beispiel import= java.util.* %> import= java.text.* %> <HTML> <HEAD><TITLE>Datum</TITLE></HEAD> <BODY> <H1> <% // Hole das Aktuelle Datum, formatiere es und gib es aus SimpleDateFormat formatter = new SimpleDateFormat ("yyyy.mm.dd G 'at' hh:mm:ss a zzz"); Date currenttime = new Date(); String datestring = formatter.format(currenttime); out.println(datestring); %> </H1> </BODY> </HTML> Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 50

51 3.5 Java Servlets, Java Server Pages und Java Beans JavaBeans - Komponentenmodell Komponenten: eindeutig identifizierbare, wiederverwendbare Software mit wohldefinierten Schnittstellen, die mit anderen Komponenten zusammen innerhalb eines Containers interagieren kann und vermittels einer visuellen Benutzerschnittstelle manipuliert werden kann einzelne JavaBeans Bean Container aus JavaBeans zusammengesetzte neue Komponente Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 51

52 3.5 Java Servlets, Java Server Pages und Java Beans JavaBeans Komponentenmodell JavaBean zeigt Methoden, Eigenschaften und Events (Interface) Informationen via BeanInfo Klasse sichert aktuellen Zustand in.ser-datei, die in einem JavaArchiv (JAR) archiviert wird erlaubt Anpassungen im Design über Customizer BeanInfo Konventionen: -Default-Konstruktor -keine public-variablen -getxxxx (Abfrage) -setxxxx (Zuweisung) - Methods Properties JavaBean Component Events Customizer Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 52 JAR (.jar)

53 3.5 Java Servlets, Java Server Pages und Java Beans JavaBeans Beispiel //Customer.java package test.shop.data; public class Customer private String user = new String(); private String password = new String(); // Default Konstruktor public Customer(){} public Costomer(String user, String password) { this.user = user; this.password = password; } // getxxx / setxxx Methoden public String getuser() {return user;} public String setpassword(string password) { this.password = password; } Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 53

54 3.5 Java Servlets, Java Server Pages und Java Beans JavaBeans und JSP JSP bietet für den Zugriff auf JavaBeans deklarative Methoden Methoden sind in XML kodierte, standardisierte JSP-Tags Neues Objekt erzeugen <jsp:usebean id= bezeichner class= Klassenname /> Bean Properties lesen <jsp:getproperty name= bezeichner property= propertyname /> Bean Properties manipulieren <jsp:setproperty name= bezeichner property= propertyname value= wert /> Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 54

55 3.5 Java Servlets, Java Server Pages und Java Beans JavaBeans und JSP - Beispiel...  <jsp:usebean id= customer class= shop.customer />  <jsp:setproperty name= customer property= * /> <h3><table> <tr><td>user:</td><td><%=customer.getuser()%></td></tr> <tr> <td>password:</td> <td><%=customer.getpassword()%></td> </tr> </table></h3> Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 55

56 3.5 Java Servlets, Java Server Pages und Java Beans JavaBeans und JSP Kontexte Java Servlets und JSP werden als Komponenten in Web-Container ausgeführt Zugriff auf Daten abhängig vom jeweiligen Kontext Application Kontext HTTP Session Kontext Client 1 Request Kontest Request Kontest Session Kontext Client 2 Request Kontest Request Kontest Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 56

57 3.5 Java Servlets, Java Server Pages und Java Beans Komplexere JSP/JavaBeans Anwendungen Einbindung dynamischer Daten in HTML bisher über JSP- Scriptlets oder über Java Beans Scriptlets erlauben Höchstmaß an Präsentationskontrolle Mischung von HTML-Code und Programmcode (Scriptlets) erschwert Wartung Zugriff auf Java Beans erfolgt über JSP-Aktionen (deklarativ) Java Beans unterstützen als Datencontainer lesende/schreibende Zugriffe, aber keine Kontrolle der Präsentation Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 57

58 3.5 Java Servlets, Java Server Pages und Java Beans JSP Custom Tags Implementierung und Deployment (Nutzung) von JSP Custom Tags erfordern: JSP Datei taglib uri= mytaglib.tld prefix= mtl" %> <mtl:hello /> Tag Library Descriptor Java Tag Handler Class <tag> <name>hello</name> <tagclass> mytaglib.hellotag </tagclass> </tag> public class HelloTag extends TagSupport { public HelloTag() { } } Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 58

59 3.5 Java Servlets, Java Server Pages und Java Beans JSP Custom Tags Java Tag Handler Class package mytaglib import javax.servlet.jsp.*; import javax.servlet.jsp.tagext.tagsupport; public class HelloTag extends TagSupport { public HelloTag() { super(); } public int dostarttag() throws JspException { try { JspWriter out = pagecontext.getout(); out.print ( Hello World! ); } catch (IOException ioe) { throw new JspException(); } return SKIP_BODY; } Default Konstruktor Definiert volle Funktionalität des neuen Tags Zugriff auf JSP-Seite, z.b. -Attribute im Page Scope -Request / Response -JspWriter Inhalt des neuen Tags soll nicht ausgewertet werden Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 59

60 3.5 Java Servlets, Java Server Pages und Java Beans JSP Custom Tags Tag Lib Descriptor mytaglib.tld <tag> <name>hello</name> <tagclass> mytaglib.hellotag </tagclass> <bodycontent> empty </bodycontent> </tag> -enthält für jedes neue Tag einen <tag> Eintrag -verknüpft Tag Handler Class mit XML-Elementnamen Zusammenfassung neu definierter Tags in Tag Libraries JSP Standard Tag Library (JSTL) Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 60

61 3.5 Java Servlets, Java Server Pages und Java Beans Programmiermodell Java Servlets, JSP und JavaBeans werden im Sinne des Model-View- Controller Modells (MVC) eingesetzt Trennung von Web-Design und Software-Entwicklung HTTP Request CONTROLLER Servlet 1: operate Business Object MODEL [1.1: operate] 2: select Value Object HTTP Response JSP VIEW [2.1: use] JavaBeans Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 61

62 3.5 Java Servlets, Java Server Pages und Java Beans Web Frameworks Framework implementiert Programmiermodell und gibt damit die Anwendungsarchitektur vor Umkehr der Kontrolle: Programmierer registriert konkrete Implementierungen Implementierung wird durch das Framework gesteuert und benutzt z.b. Struts Open Source Framework für Java Web-Anwendungen implementiert MVC Programmiermodell für Präsentationsschicht (View) Java Server Faces (JSF) erlaubt einfache Einbindung von Komponenten für Benutzerschnittstellen Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 62

64 3.6 Enterprise Java Beans (EJB) EJB Enterprise Java Beans Standard von SUN Microsystems für Entwicklung und Einsatz von komponentenbasierten JAVA-Serveranwendungen Serverobjekt = (Enterprise Java) Bean EJB enthält ausschließlich Anweisungen zur Ausführung von Aktionen auf hohem Abstraktionsniveau (Business Logic) Systemnahe Standardfunktionen (Transaktionsmanagement, Sicherheit, Ressourcenverwaltung, Fehlertoleranz etc.) werden von EJB-Server zur Verfügung gestellt EJB-Server stellt notwendige Laufzeitumgebung für benötigte Komponenten über EJB-Container zur Verfügung wichtigste Unterschiede zu RMI/CORBA: Client erzeugt und löscht Objekte direkt auf dem Server vollständig verteilte objektorientierte Umgebung LowLevel-Management übernimmt EJB-Server Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 64

65 3.6 Enterprise Java Beans (EJB) EJB Architektur EJB Server EJB Container EJB Komponente: Enterprise Bean Klasse Remote-Interface Home-Interface Primary Key Deployment Descriptor EJB-Jar-File Home create() remove EJB Server EJB Container remote EJBObject Businessmethods Bean Client Client agiert nie direkt mit Bean-Klasse, sondern über Home/Remote-Interface remote EJBObject Businessmethods Bean Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 65

66 3.6 Enterprise Java Beans (EJB) EJB Container ist verantwortlich für die Verwaltung der Beans bietet den Beans eine vollständige Laufzeitumgebung stellt Schnittstellen und Mechanismen bereit für den Zugriff auf verschiedene Systemdienste: Namensvergabe Lebenszyklus Persistenz Transaktionen Messaging Sicherheit Packaging Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 66

67 3.6 Enterprise Java Beans (EJB) EJB HomeInterface Home Interface definiert die Methoden für die Erzeugung, Zerstörung und das Auffinden von EJB-Objekten (Lebenszyklus) erweitert javax.ejb.ejbhome Home Object liefert Referenz auf das EJB-Objekt an den anfragenden Client zurück EJB Container 1. Fordert neues EJB-Objekt an Home Object 2. Erzeugt neues EJB-Objekt Client-Code 3. Rückgabe Objekt-Referenz remote EJBObject Businessmethods Bean Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 67

68 3.6 Enterprise Java Beans (EJB) EJB Remote Interface Remote Interface exportiert Methoden des Beans erweitert javax.ejb.ejbobject EJB Container Home Object Client-Code 1. ruft Methode auf 4. return Wert remote EJBObject Businessmethods 3. return Methode 2. delegiert Methode an Bean Bean Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 68

69 3.6 Enterprise Java Beans (EJB) EJB Deployment Descriptor enthält Deklaration der Anforderungen an die Middleware Dienste Container untersucht Deployment Descriptor und erfüllt die Anforderungen Bean-Entwickler hinterlegt folgende Informationen: um welchen Bean-Typ handelt es sich (Entity-, Session oder Message-driven-Bean). Name des Beans im Namen- und Verzeichnis -Dienst Name des Home-Interfaces, des Remote-Interfaces und der Bean-Klasse Informationen zur Zugriffskontrolle Informationen zum Transaktionsverhalten Informationen zum Bean-Lebenszyklus und Persistenz Erzeugung wird oft interaktiv via Eigenschaftsdialogen abgewickelt Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 69

70 3.6 Enterprise Java Beans (EJB) EJB Deployment Descriptor <?xml version= 1.0?> <!doctype ejb-jar PUBLIC -//Sun Microsystems, Inc./ /ejb-jar_1_1.dtd > <ejb-jar> <enterprise-beans> <entity> <description> Liefere eine Zufallszahl zwischen 0 und 100 </description> <ejb-name> MagicNumber </ejb-name> <home> com.examples.magicnumberhome </home> <remote> com.examples.magicnumber </remote> <ejb-class> com.examples.magicnumberbean </ejb-class> </entity> </enterprise-beans> Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 70

71 3.6 Enterprise Java Beans (EJB) EJB JAR File spezielle Archiv-Dateien, die zum Packen von Java-Klassen/JavaBeans, EJBs verwendet werden beinhaltet Bean-Klasse, Remote-Interface, Home-Interface, Primärschlüssel-Klasse (nur bei Entity-Beans), serialisierten Deployment-Deskriptor und ein Manifest (==Inhaltsverzeichnis). Container liest Deployment Deskriptor, um notwendige Informationen über EJBs im.jar-file zu erhalten Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 71

72 3.6 Enterprise Java Beans (EJB) EJB Beans-Varianten Session Beans führen Anwendungslogik auf Servern aus wird für jeden Client/Zugriff eigens exklusiv konstruiert Lebensdauer = Zeit des Zugriffs, wenn Zugriff beendet, zerstört der Container die Instanz des Session Beans Transient Stateless Beans Zustandslos, vorangegangene Interaktionen werden nicht berücksichtigt z.b. Zahlung via Kreditkarte Übermittlung Betrag, Kreditkartennummer Statefull Beans JavaBean Component Zustandsbehaftet, vorangegangene Interaktionen bestimmen den weiteren Verfauf der Interaktion z.b. Online-Shop Warenkorbsystem Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 72

73 3.6 Enterprise Java Beans (EJB) EJB Session Beans 1. Retrieve Home Object Reference Naming Service Client 3. Create new EJB-Object 5. Return EJB-Object Reference 2. Return Home Object Reference Home Object 6. Invoke Business-Method remote EJBObject Businessmethods 4. Create EJB-Object EJB Container Bean 7. Delegate Request to Bean Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 73

74 3.6 Enterprise Java Beans (EJB) EJB Beans Varianten Entity Beans Repräsentieren persistente Daten in einer Datenbank Lebensdauer entspricht Dauer der Speicherung in der Datenbank (langlebig) benötigen PrimaryKey alle Clients greifen auf dieselbe Instanz gemeinsam zu überlebt sogar EJB-Server Absturz (Transaktionsorientiert) Bean-Managed EJBs Komponentenentwickler steuert Datenbankzugriffe selbst (JDBC) Persistenz liegt in der Hand des Entwicklers Container-Managed Beans Entwickler beschreibt lediglich den Datenzugriff, Ausführung obliegt dem Container Unabhängig vom eingesetzten Datenbanksystem JavaBean Component Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 74

75 3.6 Enterprise Java Beans (EJB) EJB Beans Varianten Message Driven Beans Erlaubt asynchrone Kommunikation mit Beans via JMS (Java Messaging Service) Aufruf wird von EJB-Server in Warteschlage verwaltet, Client setzt Verarbeitung unmittelbar fort und wartet nicht auf Ergebnis EJB-Server benachrichtigt Client über das Ergebnis via JMS Message Driven Bean ist transient und stateless JavaBean Component Bsp. Order-Auftrag mit mobilem Endgerät in Online-Shop Verbindung wird unmittelbar nach Auftragseingang beendet, komplexe Auftragsbearbeitung auf Server, Benachrichtigung des Auftraggebers via SMS Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 75

76 3.6 Enterprise Java Beans (EJB) EJB Beispiel Remote Interface import java.rmi.remoteexception; public interface Transferable extends javax.ejb.ejbobject{ public String getmagicnumber() throws RemoteException; } Home Interface import java.rmi.remoteexception; import java.ejb.createexception; public interface TransferableHome extends javax.ejb.ejbhome{ public Transferable create() throws CreateException, RemoteException; } Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 76

77 3.6 Enterprise Java Beans (EJB) EJB Beispiel Bean Klasse import java.ejb.*; public class MagicNumberBean implements javax.ejb.sessionbean{ public void ejbcreate(){ } public String getmagicnumber(){ return "Your magic number is "+ (int)(math.random()*100); } public void ejbload(){ } public void ejbstore() { } public void ejbactivate()throws RemoteException{ } public void ejbpassivate()throws RemoteException { } public void ejbremove() { } } Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 77

78 3.6 Enterprise Java Beans (EJB) EJB Beispiel Client (1) import java.io.*; import javax.ejb.*; import javax.naming.*; import javax.rmi.portableremoteobject; public class MagicNumberClient { public static void main(string[] args) { // lookup home // create bean // call business code } } Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 78

79 3.6 Enterprise Java Beans (EJB) EJB Beispiel Client (2) try { InitialContext context = new InitialContext(); Object ref = context.lookup( MagicNumber"); MagicNumberHome home = (MagicNumberHome) PortableRemoteObject.narrow( home, MagicNumber.class); MagicNumber bean = home.create(); System.out.println(bean.getMagicNumber()); bean.remove(); } catch (NamingException ex) { ex.printstacktrace(); } catch (CreateException ex) { ex.printstacktrace(); } Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, sack@minet.uni-jena.de 79

81 Literatur Ch. Meinel, H. Sack: WWW Kommunikation, Internetworking, Web Technologien, Springer, H. Wöhr: Web Technologien, dpunkt, Dr.rer.nat. Harald Sack, Institut für Informatik, FSU Jena, Ernst-Abbe-Platz 2-4, D Jena, 81