Web-Applications mit Java & XML im Sommersemester 2002

Transkript

1 Vorbereitung auf die Prüfung Web-Applications mit Java & XML im Sommersemester 2002 Die folgenden Seiten stellen eine Zusammenfassung des Skriptes von Professor Fischer dar. Ich habe die meiner Meinung nach relevantesten Teile zusammengeschrieben und teilweise ergänzt. Diese Zusammenfassung erhebt keinen Anspruch auf Vollständigkeit. Kommentare und Verbesserungsvorschläge bitte an:

2 Verteilte Anwendungen Vorteile: Eigenschaften: Web: Mehrfachnutzung derselben Daten Einbeziehung von Kunden und Lieferanten Enterprise Applications Verwendung offener Standards laufen auf mehreren Rechnern Transparenz (Orts-, Zugriffs-, Nebenläufigkeitstransparenz) bekannte Benutzerschnittstelle Anwendungslogik auf Server Seite Übertragungsmedium HTTP Kommunicationsmechanismen CORBA: Common Object Request Broker Architecture System- und Implementierungssprachen-unabhängiges verteiltes Objektsystem. Vereinfachte Entwicklung in verschiedenen Teams, Entwickelt von der Object Management Group. Object Request Broker (ORB): Aufgabe ist die transparente Kommunikation verteilter Objekte zu ermöglichen. Ansatz geht weiter als RPC, Auffinden von Objekten möglich. Kommunikation läuft über GIOP (General Inter ORB Protocol) bzw. IIOP (Internet Inter ORB Protocol) Interface Definition Language IDL: Da CORBA sprachenunabhängig ist, muss Interface Sprache standardisiert sein. Stub Skeleton RMI: RPC Remote Method Invocation Java-basierte Alternative zu CORBA, Möglichkeit ganze Objekte übers Netz zu verschicken, keine eigene Interface-Sprache (da Java-basiert) Remote Procedure Call Oberbegriff für verschieden Kommunikationsmechanismen wie CORBA, RMI oder DCOM N Tier Architekturen Vorteile geringe Komplexität der einzelnen Teile Verteilung der Implementierungsaufgaben thin Client Einfache Änderung von Look&Feel erleichterte Wartbarkeit (kein Austausch von Client Software) Skalierbarkeit, Sicherheit Presentation Layer Business Logik Layer Benutzerschnittstelle Eingaben abholen, Ausgaben der Server-Seite darstellen HTML, WML, Java Applets Anwendungslogik (z.b. Warenkorbfunktion) Aufteilung aus Skalierbarkeits- und Sicherheitsgründen möglich in Web-Server Interpretation von Benutzereingaben Aufbereitung von Ergebnissen in HTML oder XML (dyn.) - Seite 2/8 -

3 Annahme und Rückgabe von Daten an Client Web Container enthält Web Server Servlet Engine (z.b. Jakarta Tomcat als stand alone oder kombiniert (Gründe: langsam bei statischen Seiten, Investitionsschutz der Unternehmen) Tools (z.b. zur Interpretation von JSP) Application-Server siehe J2EE: Enterprise Java Beans (EJB) Servlets, JSP, ASP, CORBA, EJB Data Layer Daten Verwaltung mit DB-Servern oder ERP Systemen J2EE Vorteile Diensttypen siehe Vorteile N Tier Architekturen interne Daten nach Außen geben Name Services Deployment Services (flexible Verpackung, Installation und Konf. von Komp.) Transaction Services (Teilung von Transaktionsabläufen in Einheiten) Security Services (Authentifizierung & Autorisation) Dienstschnittstellen JDBC (Java Database Connector) JNDI (Java Naming and Directory Interface) Connector Architecture (Einbindung von ERP) Kommunikation Internet Protokolle (http, TCP, IP, SSL) RMI (Java Remote Method Invocation) OMG (CORBA, IIOP, RMI-IIOP, Java IDL) Message Services (JMS (p2p publish-subscribe), JavaMail) Ablauf: Client stellt Anfrage über HTTP Get oder POST Servlet stellt Verbindung zum Application Server her(rmi-iiop) Zugriff auf Home Interface (Auffinden über JNDI-lookup) Nutzung des Home Interface zur Erzeugung von EJB - create() Entity Beans: find() Methoden zum Auffinden von Objecten Nutzung des Remote Interface für Methoden der Anwendungslogik Nutzung des Home Interface zur Zerstörung der EJB destroy() Stand Alone Client EJB Client in direkter Interaktion mit EJB Server Eigenes GUI Nutzt Java Dienstschnittstellen wie JNDI, JMS, Kommunikation über RMI-IIOP Vorteil: Verteilung der Last auf Client, Transaktionsuntersützung Vorteil: integriertes Sicherheitskonzept, komplexe Datenmodelle (XML) Nachteil: Installation, Firewalls anpassen, komplexer als Web-Clients Java Anwendung mit Zugriff auf ERP (EIS Client) direkter Zugriff auf EIS komplette Anwendungslogik auf Client Seite komplexer als EJB Client Einsatz von JDBC, JCA (Java Connector Architecture) Client mit Zugriff auf dynamischen Web Inhalt - Seite 3/8 -

4 Servlet JSP Java Beans Überwindung der Zustandslosigkeit von HTTP Interfaces: Servlet, ServletRequest, ServletResponse Klassen: GenericServlet, HttpServlet Spez. Schnittstellen: HttpServletRequest, HttpServletResponse Zugriff auf http-umgebungsvariablen Verwaltung von Cookies und Sessions Sicherheitsmechanismen (Benutzeridentification) Erzeugung: Interface Servlet implementieren (immer notwendig) abstrakte Klasse GenericServlet erweitern Meth. service() muss ausprogrammiert werden Klasse HttpServlet erweitern (am komfortabelsten) Meth. service() bereits implementiert doget() und dopost() verwenden Lebenszyklus: init(), beliebig oft service(), destroy() Variante der Servlets (Java-Code in html eingebettet) wird zur Laufzeit in Servlets übersetzt (komplex. Seite Performance Prob.) Vereinfachte Arbeitsteilung: Trennung von Design und Programmierung nicht mit Enterprise Java Beans verwechseln! Idee: Kapselung der Programmlogik im Bean, JSP möglichst einfach halten normale Java Klasse, die mittels <jsp:usebean> in JSP eingebunden wird Cookies Sessions EJB EJB Container Speichern von Informationen auf Client Rechner (zur Wiederverwendung) schlechter Ruf: beliebige Informationen können gespeichert werden u.u. keine Berechtigung zum Speichern von Cookies Servlet-Bib: HttpSession Informationen über Client werden Server-seitig gespeichert. Speicherung von Parametern, deren Werte plus strukturierte Objekte Session ID wird an Client geschickt, mit url-rewriting dann zurück an Server Probleme von 3-Tier: Skalierbarkeit, Sicherheit, unterstützte Dienste, nicht schön bei größeren Projekten Lösung: Realisierung der Anwendungslogik in vierter Stufe alternative Technologien: Socket Kommunikation (komplex zu prog.) Verteilte Objekt Systeme: CORBA, RMI, DCOM (MS) jede Middleware braucht IDL zur Schnittstellendefinition Kommunikation über RMI (Version 1.1), CORBA-IIOP (Version 2.0) Aufruf Bsp.: Cart shoppingcart = home.create( name ); (home) shoppingcart.addbook( bla ); (remote) EJB Container werden in einem Application Server realisiert (z.b. IBM-Websphere oder BEA-Weblogic) EJB Container muss EJBs administrieren: notwendige Aufgaben: Ressourcen und Lebenszyklus Management Entfernter Zugriff und Ortstransparenz (IIOP) Zustandsverwaltung bei Session Beans Transaktionsmanagement Sicherheit (Authentifizierung, Autorisierung) Persistenz Deployment Tools Zusätzliche Aufgaben: Lastbalancierung mit anderen EJB Containern Database Connection Pooling Verteilte Transaktionen Integrierte XML-Unterstützung - Seite 4/8 -

5 Integration von CORBA (leichter seit Version 2.0) EJB Tier eigentliche EJB (z.b. AccountBean.java) Implementierung der Anwendungslogik (Methoden des Remote Interface) Methoden des Home Interface Methoden, die der Container erwartet (z.b. Session, Entity) Client nutzt nur Home- bzw. Remote Interface. Nie die Bean selbst. Homeinterface und Object(wird bei der Inst. erzeugt) (z.b. AccountHome.java) Steuerung des Lebenszyklus der Enterprise Bean Objekte Methodentypen: create gibt Remote Interface zurück find gibt Remote Interface oder Collection zurück remove Remote Interface & Object (wird bei der Inst. erzeugt) (z.b. Account.java) Definition der Anwendungslogik-Methoden, die Client ausführen kann Deployment Descriptoren Festlegung von ablaufspezifischen Eigenschaften Konfiguration bei der Installation Inhalte: Art der Persistenz und Transaktionsverwaltung, Sicherheit container managed transaction Steuerung von Bean oder Container möglich Konfiguration über Deployment Descriptor Sicherheit Session Beans Entity Beans Zentrales Konzept: Rollen Authentifizierung durch Benutzername und Passwort Autorisierung programmatisch: expliziter Aufruf von isuserinrole() Autorisierung deklarativ implizit im Deployment Desciptor Modellierung von Prozessen Ausführung komplexer Aufgaben (zu komplex für Servlet) Aufruf anderer Session- und Entity Beans Transaktionsklammer Kapseln ggf.zugriff auf Entity Beans gegenüber Clients üblicherweise keine Persistenz Sonderform Stateful Session Beans: Attribute, die einem Client zugehörig sind an dessen Lebensdauer gekoppelt Hauptaufgabe daher: Session Tracking z.b. virtueller Einkaufswagen bieten objektorientierte Repräsentation von Anwendungsdaten aus DB/ERP Wiederverwendung möglich, nebenläufiger Zugriff erlaubt überleben Client Sitzung für Zustandsvariablen gibt es get- und set- Methoden Verwendung für persistente bzw. langlebige Daten nicht Client-spezifische Daten Repräsentation von DB-Objekten Bean-managed persistence durch Anwendungsprogrammierer (JDBC-API) Container-managed persistence Zuordnung im Deployment Descriptor: DB-Felder Bean Feldern entsprechende DB-Aufrufe werden generiert ist Qualitätsmerkmal für Container DB Connection Pooling zur Effizient Steigerung häufige Ausführung der Callback Methoden immer konsistent, aber schlechte Performance - Seite 5/8 -

6 Message Driven Beans Probleme EJB Ansatz Verarbeitung asynchroner Nachrichten Message Listener wartet auf Eingang erst ab EJB 2.0 bisher eher selten Modelle werden komplexer kein klares Vorgehen (keine Best Practices) Deployment Descriptoren werden sehr komplex debugging komplex und langsam Data Tier Protokolle JDBC Zugriff auf relationale DB aus Applets, JSP, Servlet, EJB JCO Zugriff auf R/3 JCA allgemeine Lösung für Zugriff auf ERP-Systeme JDBC Treiber Treiber Arten Client greift via JDBC API über JDBC-Treiber des verwendeten Systems auf DB zu JDBC-ODBC Bridge populär unter Windows Treiber übersetzt von JDBC auf ODBC Teilweise Java, teilweise Proprietär ähnlich wie JDBC-ODBC Brige, aber ein Abbildungsprozess weniger DB-Zugangsserver spezieller Rechner, der mehrere Clients mit mehreren Servern verbindet Reine Java-Treiber effizientestes Vorgehen XML XML Datenbeschreibungssprache Trennung von Inhalt und Layout reiner ASCII Text Verständlich für Mensch und Maschine Grundlage für verschiedene Ausgabestile (XSLT) hierarchische Ordnung (Baumstruktur mit genau einer Wurzel) Syntax muss strikt eingehalten werden (wohlgeformtheit) Wurzel wird behandelt wie jedes andere Object (wichtig beim Einbetten) Namenskonventionen wie bei Programmierung Elemente sind grundlegende Komponenten Attribute können im start-tag eines Elementes angegeben werden Beispiel <?xml version= 1.0 encoding= ISO standalone= no?> <!DOCTYPE message SYSTEM 'root.dtd'> <!-- Beginn der Nachricht --> <message> <subject/> <text date= >I love you</text> </message> Anwendungen Deployment Desciptoren Archivierung von Daten - Seite 6/8 -

7 HTML Dokumentenbeschreibungsprache ursprünglich statische Seiten, heute dynamische Seiten Namespaces Valdierung DTD Schema vermeiden Kollisionen von Daten aus mehreren Bereichen <x xmlns:edi= <edi:price units= Eur >30</edi:price> </x> Syntaxkonventionen ermöglichen Verlagerung von Fehlerabfragen von der Application zum Parser Valide Dokumente sind wohl-geformt und konform zu einer Grammatik enthalten Elementdefinitionen welche Elemente Eltern-Kind Beziehungen Attributdefinitionen Entity Definitionen Nachteile: DTD-Syntax in xml-welt unnatürlich keine Datentypen in dtd, nur strings keine Vererbung in dtd Beispiel <?xml version="1.0"?> <!DOCTYPE message [ <!ELEMENT root (name)> <!ELEMENT name (nachname?, vorname+, gebname*)> <!ELEMENT nachname (#PCDATA)> <!ELEMENT vorname (#PCDATA)> <!ELEMENT gebname (#PCDATA)> <!ATTLIST name nationalität CDATA #REQUIRED> <!ATTLIST name nationalität CDATA #IMPLIED> ]> Entitäten sinnvoll um häufig benötigte Textbausteine einzufügen Einfügung von Sonderzeichen Modularisierung von Dokumenten Definition in DTD, Referenzierung in DTD oder xml-dokument geschrieben in XML primitive und komplexe Datentypen, Attribute und Einschränkungen von Datentypen Beispiel <schema> <element name= book > <complextype> <attribute name= title type= string > <attribute name= price type=float > </complextype> </element> </schema> Parser DOM überprüfen wohlgeformtheit, Gültigkeit und ermöglichen das Verwenden der xml Datei in Anwendungen. Unterschieden wird in SAX und DOM Document Object Model definiert Interfaces, die es erlauben Baumstruktur zulesen und zu verändern leicht zu programmieren aber Speicherhungrig - Seite 7/8 -

8 SAX JDOM XSL XPath ereignisbasiert, d.h. Parser durchläuft gesamtes Dokument und informiert Anwendung bei gefundenen Konstruktionselementen über eventhandler wird festgelegt, was bei welchem gefundenen Element zu tun ist Bsp. Xerces enthält fertigen Parser mit beispielhaft implementierten Handlern extrem schnell bei geringem Speicherbedarf, allerdings komplexe Programmierung Alternative zu DOM und SAX, enger an Java, geringe Tool Unterstützung/Konformität extensible Stylesheet Language XSLT Prozessoren konvertieren in andere XML-Dokumente mit anderem Schema transformieren in beliebige andere Formate (zu Layout Zwecken) XSLT Engine z.b. Xalan lässt sich leicht in Servlet oder JSP integrieren XSL Stylesheet ist Sammlung von Regeln, defaut: nur text wird ausgegeben XML-Baum wird depth first abgearbeitet Regel X Y, trifft X zu, dann ist X das Kontextelement, Y ist Aktionsteil Stylesheet ist in XML geschrieben und verwendet typischerweise xml-namespace Regeln: <xsl:template match= xxx >Ersetzung</xsl:template> Bedingungen: werden als XPATH Ausdrücke beschrieben Sprache, um Teile eines XML-Dokuments zu selektieren. Wird verwendet mit XSLT und XPointer Web Services SOAP UDDI WSDL xml-basierter Aufruf entfernter Dienste, wie CORBA, RMI, RPC, DCOM Dienstaufrufe werden in xml beschrieben, Ergebnisse in xml zurückgegeben beruhen auf offenen und standardisierten Protokollen und Sprachen benutzen http und SMTP als Transportprotokolle Simple Object Access Protocol beschreibt im wesentlichen xml-basierten RPC mit http als Transportprotokoll Vorteil: textbasiert (leichtes debugging), überwindet firewalls Envelope (Daten über Sender & Empfänger, Details über Nachricht) Kodierungsregeln für Datentypen RPC-Mechanismus, API für versch. Programmier Sprachen SOAP API stellt Aufrufe zur Datensammlung zur Verfügung übergibt Nachricht an Transportprotokoll empfängt und dekodiert die Nachricht Universal Description, Discovery and Integration Verzeichnisdienst, über den web services gefunden und angekündigt werden Globales Business Verzeichnis (green pages) web services werden bei UDDI registriert Web Service Description Language übergreifende Sprache, in der Dienste und Protokolle beschrieben werden xml-format, wsdl-dtd hätte gereicht - Seite 8/8 -