5 WWW-IS2 - AG Netzbasierte Informationssysteme
Werbung
Arbeitsgruppe Vorlesung Netzbasierte Informationssysteme Web-basierte Informationssysteme II Prof. Dr. Adrian Paschke Arbeitsgruppe Corporate Semantic Web (AG-CSW) Institut für Informatik, Freie Universität Berlin [email protected] http://www.inf.fu-berlin.de/groups/ag-csw/ § Dynamische Webanwendungen (Fortsetzung) § Mehrschichtige Verteilte Architekturen § Middleware § OMG‘s CORBA § J2EE Application Server § Architektur des Webs § Architekturstil und REST § URIs § HTML Server-Side Scripting § In HTML-Seiten werden zusätzliche HTML-generierende Quellen integriert (beliebig viele). § Typische Vertreter: § PHP - Personal Home Page § ASP - Active Server Pages (Microsoft IIS) § JSP - Java Server Pages HTML HTML Datenbank Scripting Scripting AnwendungsLogik Varianten Anwendung erstellen Laufzeit <HTML> Anwendung erstellen <HTML> <xsp:...> <xsp:...> </HTML> </HTML> Interpreter ÜbersetzungsZeit (einmalig) Compiler Ausführbares Programm Laufzeit HTMLDokument HTMLDokument Variante 2, JSP Ablauf HTTPServer Servlet Generierung aus JSP (HTML + Scripting) JSPpage Client Datenbank Verbindungsaufbau Anfrage Servlet SQL Anfragen Antwort Ergebnisse Zustand Java Server Pages (JSPs) § JSPs haben eine andere Syntax als Servlets: § Servlets produzieren HTML-Code innerhalb von Java-Code § JSPs betten Java-Code in HTML-Code ein § JSPs werden vom Web Container intern in Servlets umgewandelt § Vorteile von JSPs: § “Separation of responsibilities” – Logikprogrammierung kann in Java von Programmierern übernommen werden; Design der pages kann von Web Designern übernommen werden § Übersichtlichkeit § Komponentenartigkeit § Struktur ist normales HTML mit zusätzlichen Basistags: § Scriptlets, Expressions, Declarations, Directives Model-View-Controller Servlet Container HTTP Request Controller Controller (Servlet) WWWBrowser (Client) Model (JavaModel Beans) HTTP Response View View (JSP) Client-seitige WWW-Anwendungen § Viele Aufgaben können aus Gründen der Lastverteilung am Client ausgeführt werden § § § § Prüfung von Benutzereingaben Erstellung von Graphiken Manipulation von WWW-Dokumenten Zusätzliche Möglichkeiten für die Gestaltung der Benutzerschnittstelle § Möglichkeiten zur Realisierung Client-seitiger Erweiterungen § § § § Browser Plug-Ins (z.B. Macromedia Flash) Skriptsprachen (JavaScript, …) Java Applets Microsoft ActiveX § Sicherheitsproblematik!!! Java-Applet import java.applet.* java.applet.*; import java.awt.*; public class FirstApplet extends Applet { //Diese Methode paint stellt das Applet dar public void paint(Graphics g) { g.drawString(„Hello World!“, 25, 50); } Java-fähiger Browser (Windows XP) } /* Class FirstApplet */ 0efc345f6b7723ba83f2d90ca4 (...) Java-fähiger Browser (Linux) Beispiel: Client-seitige Anwendung Präsentation/ Interaktion Server-Prozess AnwendungsLogik Datenbank Daten WWW und Java Applets § Ein geeigneter Browser (mit Java Interpreter) kann Applets ausführen § Animationen, Darstellung von Graphiken, Audio-Funktionalität § Lokale Interaktionen (Maus, Keyboard) § TCP/IP-Verbindungen zu Server-seitigen Anwendungen § Sicherheit § § § § keine Zeiger Prüfung beim Kompilieren Prüfung des Bytecodes durch den Bytecode Verifier Applets haben keinen Zugriff auf das lokale Dateisystem (Trusted Applets schon!) § Häufige Politik des Browser: Netzwerkverbindungen von Applets nur zu dem Host, von dem das Applet geladen wurde! Zusammenfassung § State of the Art: § Starke Verbreitung von Servlets und Serverseitigem Scripting § Bei starker Interaktion und komplexer Benutzerführung § Client-seitige Erweiterung (JavaScript, Java Applets, ActiveX) § Reduziert Kommunikationsaufwand zwischen Client und Server § Keine „beste Lösung“ für alle Fälle § Kriterien im Einzelfall entsprechend Anforderungen gewichten § Immer zu beachten: § Schneller technologischer Fortschritt DB-Zugriff mit Java (3-Stufen-Architektur) Applet wird geladen Java-fähiger Browser WWWWWW-Server und GatewayGateway-Server DatenbankDatenbank-Server Datenbank--Server Datenbank Server § Mehrstufige Client-Server-Architekturen können das Problem der eingeschränkten Netzwerkverbindungen umgehen. § Über den Gateway-Server können auch mehrere Datenbanken angesprochen werden. § Kommunikation von Applet zu Gateway-Server § Verschiedene Verteilungsarchitekturen möglich Exkurs: Ziele, Eigenschaften und Herausforderungen an verteilte Systeme § Ziel § Transparente, offene und skalierbare Verbindung von Nutzern und Ressourcen § Eigenschaften § Offenheit § Jedes Subsystem ist kontinuierlich offen für Interaktion mit anderen Systemen § Skalierbarkeit § Vorteile eines skalierbaren, offenen Systems gegenüber einem komplett abgeschlossenen Systems § Herausforderungen § Monotonität § Sobald etwas in einem offenen System veröffentlicht ist, kann es nicht zurückgenommen werden. § Pluralismus § Unterschiedliche Subsysteme eines offenen, verteilten Systems können heterogene, überlappende und eventuell konfliktäre Informationen enthalten. Es gibt keine zentrale Autorität in offenen, verteilten Systemen. § Unbounded non-determinism § Asynchrone, unterschiedliche Subsysteme können hinzukommen und wegfallen und Kommunikationslinks können ein- und ausgehen zwischen den Subsystemen eines offenen verteilten Systems Topologien Verteilter Systeme (1) § Zentralisiert § Typisches Client-Server Pattern benutzt in Datenbanken, Web Server, und anderen einfachen verteilten Systemen § Alle Funktionen und Informationen sind zentralisiert auf einem Server, an den sich mehrere Clients direkt verbinden. § Viele “Peer-to-Peer" haben eine zentralisierte Komponente § Beispiel: SETI@Home ist eine voll zentralisierte Architektur mit dem Job Dispatcher” als Server. § Ring § Ein Cluster von Maschinen im Ring angeordnet § Gruppe an Knoten, welche identische Funktionen anbieten und Fail-over und Load Balancing unterstützen § Kommunikation zwischen den Knoten koordiniert gemeinsame Zustände § Ringsysteme nehmen typischerweise an, dass alle Maschinen im Netzwerk nahe beieinander sind und zu einer einzige Organisation gehören Topologien Verteilter Systeme (2) § Hierarchisch § Lange Historie im Internet § Beispiel: Im Internet der Domain Name Service (DNS), wo Autorität vom Root Name Server auf die Server mit registrierten Name übergehen; oft über mehrere Serverebenen § Dezentralisiert § Alle Peers kommunizieren symmetrisch und haben gleiche Rollen § Die Internet Routing Architektur ist weitgehend dezentralisiert, mit dem Border Gateway Protocol, welches benutzt wird um die Links zwischen den autonomen Systemen zu koordinieren § Beispiel: Gnutella. Viele andere File-sharing Systems sind auch dezentralisiert, z.B. Freenet oder OceanStore. Hybride Topologien § Zentralisiert + Ring § § § § Zentralisiert + Zentralisiert § § § § Web Server Anwendungen haben oft einen Ring als Server für Load Balancing und Failover Das Serversystem selbst ist ein Ring, aber das System als Ganzes (inklusive die Clients) ist hybrid: ein zentralisiertes System wo der Server selbst ein Ring ist. Vorteil: Einfachheit eines zentralisierten Systems mit der Robustheit eines Rings. Server in einem zentralisierten System ist ein Client eines order mehrerer anderer Server. Schichtung mehrerer zentralisierter Systeme ist der Kern eines n-Ebenen Anwendungsframeworks. Zentralisierte Systeme sind oft geschichtet um Funktionen zusammen zu stellen. Zentralisiert + Dezentralisiert § § § Zentralisierte Systeme eingebetet in dezentralisierte Systeme. Beispiel: Internet Email. Mail Clients haben eine zentralisierte Verbindung mit spezifischen Mail Servern, aber Mail Servers selbst verteilen Emails dezentral. Beispiel: FastTrack File-sharing System in KaZaA and Morpheus. Die meisten Peers haben eine zentralisierte Verbindung zu einem “Superknoten" und leiten alle Dateianfragen an diesen Server (ähnlich wie z.B. ein Napster Client Anfragen an den Napster Server schickt). Aber die Superknoten sind allein, sondern verbinden sich in einem Gnutella-ähnlichen dezentralisierten Netzwerk, in dem Anfragen weitergeleitet werden. “Coupling” Ansätze § Strong coupling § Interaktion durch stabile Schnittstellen § API Aufruf ist fest kodiert § Schwer zu ändern, da nachfolgende Änderungen in der Implementierung benötigt werden (-) § Loose coupling § Lose Verbindung zwischen 2 oder mehr Systemen mit einer Art Austauschbeziehung § Jedes Ende der Transaktion macht die Anforderungen explizit und trifft Annahmen über das andere Ende § Erhöhte Flexibilität; eine Änderung in einem Modul verlangt keine Änderung in der Implementierung eines anderen Moduls (+) § Beispiel: Web Services, welche über Schnittstellen aufgerufen werden; Dienst hinter der Schnittstelle kann einfach ausgetauscht werden § Decoupled § § § § § § Entkoppelt in der Zeit durch z.B. Message-oriented Middleware (MoM) Asynchrone Kommunikation (+) Parallel Prozessierung (+) Schwierig Transaktionsintegrität zu gewährleisten (-) Pflege der Synchronisation aufwändig (-) Beispiel: Ereignis-Gesteuertes Publish/Subscribe; Ereignisse werden empfangen und gesendet Internet Epoche – Mehrschichtige Internet-basierte Informationssysteme SNA, TRANSDATA, … Mainframe DB Server TCP/IP Application Server Mainframe DB Server HTTP Internet/ Intranet/ Extranet TCP/IP Mainframe Web Server Application Server Typische Komponenten Internet-basierter betrieblicher Informationssysteme Webserver 1 Anwendung 1 Webserver 2 WebBrowser Portalserver Webserver 3 Webserver n Applikationsserver EAIServer Anwendung 2 Anwendung 3 Anwendung n Middleware Anwendung Anwendung Middleware Middleware Betriebssystem Betriebssystem § § Middleware ist die Verbindungssoftware welche aus einer Reihe von Diensten besteht, die es mehreren Prozessen erlaubt auf einer oder mehreren Maschinen zu laufen und miteinander in einem Netzwerk zu interagieren. Middleware-Dienste stellen funktionale Application Programming Interfaces (APIs) bereits, um es einer Anwendung zu erlauben: § § § § Andere Dienste oder Anwendungen zu lokalisieren und mit diesen zu kommunizieren Unabhängig von den Netzdienste zu sein Verlässlich und erreichbar zu sein Skalierbar zu sein ohne Funktionalität zu verlieren *Schreiber, Richard. "Middleware Demystified." Datamation 41, 6 (April 1, 1995): 41-45. Verbreitete Middleware-Ansätze § § § § § § § § § § Datenbankkommunikationsprodukte (ODBC, JDBC …) Message-oriented Middleware (Websphere MQ) OSF’s Distributed Computing Environment (DCE) Microsoft's COM/DCOM (Component Object Model) Transaktionsmonitore OMG’s CORBA (Verteilte Objektsysteme) J2EE Application Server JavaSpaces (basierend auf Linda) WebServices (in späteren Einheiten) Grid Computing Transaktionsmonitore Anwendung TP Monitor Datenbankserver Datenbankserver § § Transaktionsmonitore waren die ersten Produkte, die als Middleware eingesetzt wurden. Sicherung der “Atomicity” verteilter Transaktionen durch 2-Phase-Commit § Transaktion wird allen Beteiligten bekannt gegeben, diese senden Commit § Wenn alle Beteiligten Commit senden wird die Transaktion abgeschlossen, sonst rückgängig gemacht § § Transaktionsmonitore bieten Transaktionsmanagement für verschiedene Datenbanken und Dateisysteme. Bekannte Produkte: CICS (IBM), Tuxedo (BEA), Encina und MTS (Microsoft) BEA Tuxedo Workflow Overview Warteschlange Service 1 Anfragen Transaktion Worker Worker A Service 2 Item 1 . . . Service n Prozess Warteschlange Service 1 Transaktion Worker Worker B Service 2 . . . Service n . . . Item 2 2-Phase Commit (2PC) Ein oder mehrere “no”s Phase 1 Phase 2 Transaction manager abort() Rollback Transaction manager Transaction manager prepare() yes_or_no commit() Alle “yes” Resource manager Resource manager Verteilte Objektsysteme ORB Client § § § ORB Server Verteilte Objektsysteme wie CORBA, DCOM und Java RMI ermöglichen die Verteilung von Prozessen/Objekten auf verschiedene Knoten im Netzwerk Entwickler von Client-Anwendungen können “direkt” auf Serverobjekte zugreifen (ohne “low-level” Netzwerkprogrammierung) Verteilte Objektsysteme ermöglichen im Gegensatz zu Message-oriented Middleware auch synchrone Kommunikation zwischen den Komponenten Beispiel: CORBA § § § § § Common Object Request Broker Architecture § § § § § § Standard der OMG (seit 1992) Beruht auf dem objekt-orientierten Paradigma Liefert abstrakte Beschreibung der Schnittstellen mit IDL Einheitliches Protokoll für Interoperabilität (GIOP/IIOP) Zahlreiche Systemdienste Beispiel: MICO Open Source CORBA Implementierung § www.mico.org CORBA Interoperabilität § Zwischen verteilten Objekten § ORB ermöglicht Methodenaufrufe § Zwischen Programmiersprachen § IDL entkoppelt § Zwischen ORBs § Allgemeines standardisiertes Inter-ORB-Protokoll (seit CORBA 2.0) § Zwischen Verteilungsplattformen § Übergang durch Gateways, z. B. von CORBA nach Microsoft DCOM Client-Server-Interaktion Client Obj Impl Client Obj Impl IDL IDL IDL IDL Netzwerk OSI OSI TCP/IP ORB TCP/IP ORB Static Invocation Interface Client Objekt (Server) IDL Stub IDL Skeleton § Verpacken (engl. marshaling) von Anwendungsdaten in Pakete § Auspacken der Daten (engl. demarshaling) und Transformation Object Request Broker § Vergabe von eindeutigen Objektreferenzen (engl.: interoperable object reference, IOR) § Entgegennahme von Aufrufen vom Client § Transport der Aufrufe zum Server § Ggf. Aktivierung eines Serverobjektes § Übergabe des Aufrufs zum Serverobjekt § Entgegennahme von Ergebnissen und Transport / Umwandlung / Rückgabe zum Client Interface Definition Language (IDL) module Count { interface Counter { readonly attribute long sum; void reset (in long value); long increment(); }; }; • IDL beschreibt angebotene Funktionalität (Dienst) eines Serverobjektes • Ein Objekt unterstützt ein Interface, wenn es zu allen seinen Operationen eine Implementierung bietet • aus der sprachunabhängigen IDL-Definition werden Stubs/Skeletons für verschiedene Implementierungssprachen erzeugt Methodenaufruf Client Server obj1 obj2 obj1->increment() obj2->increment() increment() increment() Object Request Broker • synchron: blockiert bis zum Erhalt des Reply • deferred synchron: Client arbeitet nach Absenden des Requests weiter und erfragt später, ob Reply vorliegt (nur bei DII) • oneway: keine Antwort Statischer Methodenaufruf Client Anwendung 1) Aufruf IDL Stub Objekt Implementierung IDL 5) Auspacken und Aufruf IDL Skeleton 2) Parameter einpacken und Aufruf weiterleiten 4) Weiterleiten an Schnittstelle Object Adapter 3) Transport über den ORB Object Request Broker Core 4b) Aktivieren Implementation Repository 4a) Ermitteln der Implementierung Objekt Adapter § Akzeptiert Requests für Dienste der Server-Objekte § Verteilen der passenden Methodenaufrufe zu den ServerObjekten § Registrieren der unterstützten Klassen und ihrer Instanzen im Implementation Repository § (Basic/Portable) Object Adapter § Erlaubt Festlegung von Policies für Objektverhalten (z.B. LifespanPolicy, Activation, ...) Objekt (Server) IDL Skeleton DSI Objekt Adapter Aufruf des Object Adapter (OA) § Client Request wird an den OA des ORB geleitet. § Es wird festgestellt welcher Server angesprochen wird § Ist dieser Server bereits aktiv? § Wenn nicht, dann Starten des Servers § Existiert im Server schon das angesprochene Objekt ? § Wenn nicht, Aufruf des Objektes § Abarbeitung der Operation und zurückliefern des Resultats Dynamic Invocation Interface • Client Server • • DII DSI Dynamisches Einbinden von ServerObjekten zur Laufzeit ohne feste IDL Stubs Keine Festlegung zum Zeitpunkt des Kompilierens Schritte: 1. Interface Name finden (z.B. über Trader) 2. Methodenbeschreibung aus dem Interface Repository holen 3. Parameter erzeugen 4. Request abschicken Object Adapter Interface & Implementation Repository § Interface Repository § Datenbank mit Objektdefinitionen (Metadaten zu jedem Objekt) § Ermöglicht Klienten Schnittstellen zur Laufzeit zu entdecken (Dynamic Invocation Interface) § Implementation Repository § Enthält Information, die es dem ORB erlaubt, Objektimplementierungen zu finden und zu aktivieren § Bietet Information über Klassen, die der Server zur Verfügung stellt, die Objekte, die instantiiert wurden, und deren IDs Object Management Architecture Application Objects Common Facilities Object Request Broker (ORB) CORBA Services CORBA: Basis der OMG / OMA - Architektur • Anwendungsobjekte (application objects): Vom Anwendungsprogrammierer zu erstellen • Objektdienste (CORBA services): Angebot allgemeiner Dienste zur Objektbearbeitung • Common Facilities (CORBA facilities): Angebot anwendungsnaher, spezieller Dienste Wichtige CORBA Services § CORBA Object Naming Service § Findet Objekte über Namen § CORBA Object Trader Service § Bewerbung/Suche nach Objekten über Eigenschaften § CORBA Event Service § Registrieren eines Objektes für bestimmte Events (push und pull-Modell) § CORBA Transaction Service § 2-Phasen-Commit-Protokoll für verteilte Objekte Naming Service § Finden eines Objektes, das mit einem Namen in einem bestimmten Kontext übereinstimmt § CORBA definiert 2 Schnittstellen zur Implementierung des Naming Services § Über diese Schnittstellen können Namensräume für Objekte aufgebaut, abgefragt, und organisiert werden § bind, rebind: Speichert eine Objekt-Referenz (IOR) unter einem Namen (lesbarer Text-String) § resolve: Sucht in der internen Liste nach dem Namen und gibt die zugehörige Objekt-Referenz zurück Trader Service § Ein neuer Dienste-Anbieter wird seine Dienste erst bei einem Trader registrieren § Der Anbieter stellt folgende Information bereit § Eine Objektreferenz § Eine Beschreibung des angebotenen Services § Trader Services können zusammen arbeiten (engl. federated tradering services) § Der CORBA Trader stimmt in vielen Bereichen mit dem Trading Service des ISO Reference Model für Open Distributed Processing (ODP) überein TRADER import reply import request export Service invocation Importer service reply Exporter J2EE und J2EE Application Server Black-Box Komponenten in betrieblichen Informationssysteme Black-Box-Software-Komponenten § White-box Softwarekomponenten § Grosse Frameworks sind oft schwer wartbar § CORBA-basierte Enterprise Application Frameworks § Black-box Softwarekomponenten § verbergen die Implementierung der Komponenten § Container bieten Anwendungsumgebung für diese Komponenten § GUI-Komponenten, z. B. Visual Basic Controls, OLE Custom Controls – OCX, JavaBeans § Server-seitige Komponenten, z.B. EJBs, DCOM-Komponenten § Ziel: § Markt für Container § Markt für Softwarekomponenten 3-/4-Schichten-Modell in J2EE Quelle: Sun, J2EE Blueprint, 2002 J2EE-Spezifikationen § § § § § § § § § JSPs, Java-Servlets JDBC Java Transaction API (JTA/JTS) für verteilte Transaktion Java Naming and Directory Service (JNDI): Verzeichnisdienst für Java Remote Method Invocation (RMI): entfernter Methodenaufruf über Prozessgrenzenhinweg, inzwischen mit CORBA-Integration Enterprise Java Beans (EJB) Java Messaging Service (JMS): asynchrones, zuverlässiges verschicken von Nachrichten in Objektform Java Connectors (zur standardisierten Integration von ERP-Systemen wie SAP) … Enterprise Java Beans § Serverseitiges Komponentenmodell zur Entwicklung und Auslieferung von Unternehmenslogik: § Transaktional, verteilt, skalierbar, sicher, portabel … § In EJBs kommen viele andere J2EETechnologien zur Anwendung (z. B. JDBC, JNDI, JTA usw.) § EJB ist eine Spezifikation keine Implementierung Die J2EE-Spezifikationen und Mehrschichtige Architekturen Quelle: Sun, J2EE Blueprint, 2002 EJBs - Grundsätzliche Architektur § Eine EJB ist eine Menge von Java-Klassen mit genormter Schnittstelle und Struktur § Instanzen dieser Klassen kommen in einem sogenannten EJB-Containern zur Ausführung § Der EJB-Container ist (eine Repräsentation) ein(es) Applikations-Servers § Klienten können über den EJB-Container auf EJBs zugreifen und deren Methoden aufrufen § Die Methodenaufrufe erfolgen üblicherweise über RMI (Remote Method Invocation) § Der EJB-Container nimmt den Aufruf entgegen und delegiert ihn an eine entsprechende EJB 2 Arten von EJBs § Session Beans § Realisieren Anwendungslogik und Dienste § Mit Zustand (stateful) oder zustandslos (stateless) § Nicht persistent § Entity Beans § Repräsentieren Zustand und Verhalten realer Objekte (zum Beispiel eines Artikels) § Werden persistent in einer Datenbank gespeichert Application-Server § EJB-Container (Application-Server) sind fertige Produkte, die von verschiedenen Herstellern angeboten werden und sich gemäß Sun‘s EJB-Spezifikation verhalten (sollten) § EJB-basierte Serverprodukte verwenden oft CORBA (IIOP), um mit Nicht-Java-Objekten zu kommunizieren § IIOP ist Teil der EJB Spezifikation § CORBA und EJBs sind komplementäre Technologien und bauen aufeinader auf (RMI-IIOP) § Alternative Technologien von Microsoft: MTS (Microsoft Transaction Server) und (D)COM § EJBs kann man „fertig“ kaufen und dann für den eigenen Gebrauch anpassen bzw. einbetten Kommunikationsmodelle Quelle: Sun, J2EE Blueprint, 2002 EJB-Container § Zahlreiche EJB-Container-Produkte § § § § Weblogic von Bea Websphere von IBM JBoss (open source) – www.jboss.org Auch Datenbankhesteller wie Oracle und Sybase bieten EJB-Container (mit) an EJB im Detail § Besteht aus mindesten 3 (Java) Klassen bzw. Interfaces § Die Bean-Klasse implementiert die Funktionalität der Bean (zentrale Klasse) § Das Home-Interface definiert eine Schnittstelle zum Erzeugen, Finden und Löschen von EJBs durch Klienten § Das Remote-Interface stellt die „öffentlichen“ Methoden aus der Bean-Klasse den Klienten (für den Aufruf über RMI) zur Verfügung § Analog zu Home- und Remote-Interface können noch zwei weitere Klassen (Local-Home- und Local-RemoteInterface) für nicht-RMI-Zugriffe auf Beans hinzukommen... Grundsätzliche Architektur Quelle: Sun, J2EE Blueprint, 2002 Rolle von JNDI § Die Klient besorgt sich Zugriff auf einen als bekannt vorausgesetzten JNDI-Server § Über JNDI (dem Java Verzeichnis-Dienst) sucht (und findet) der Klient das Home-Interface der entsprechenden EJB § Das wird ermöglicht durch das entsprechende EJB-Home-Interface, das mit einem Namen (einem Java-String) im JNDI-Verzeichnis registriert sein muß § Über das Home-Interface kann man dann EJBs mit speziellen findund create-Methoden finden bzw. erzeugen § Man erhält eine RMI-Referenz auf eine Bean. Die Referenz implementiert das Bean-Remote-Interface Übersicht EJB Container/Server Client Code 3. Anfordern eines neuen EJB Objektes Home Object (Object Factory) 5. Rückgabe der EJB Objekt Referenz 4. Kreiert ein EJB Objekt 1. Suche nach Home Object Referenz 6. Aufruf einer Methode 7. Delegation des Aufrufes zur Bean 2. Home Object Referenz EJB Object 10. Rückgabe des Ergebnisses zum Client JNDI Naming Service Enterprise Beans 8. Rückgabe des Ergebnisses Remote Interface Hello package hello; /** * HelloBean remote interface. */ public interface Hello extends javax.ejb.EJBObject { /** * Die eine Methode - hello – gibt einen String an den Client zurück. */ public String hello() throws java.rmi.RemoteException; } EJB HelloBean package hello; import javax.ejb.SessionContext; // Zustandslose Session Bean. public class HelloBean implements javax.ejb.SessionBean { // EJB-required methods public void ejbCreate() {} public void ejbRemove() {} public void ejbActivate() {} public void ejbPassivate() {} public void setSessionContext(SessionContext ctx) {} // Business methods public String hello() { return "Hello, World!"; } } Home Interface package hello; /** * Die create() Methode ist im Home Interface und * korrespondiert zur ejbCreate() Methode in HelloBean. */ public interface HelloHome extends javax.ejb.EJBHome { /* * Diese Methode kreiert das EJB Object. * @return Das neue EJB Object. */ Hello create() throws java.rmi.RemoteException, javax.ejb.CreateException; } HelloClient.java package hello; import javax.naming.Context; import javax.naming.InitialContext; import java.util.Properties; public class HelloClient { public static void main(String[] args) throws Exception { Properties props = System.getProperties(); // JNDI initial context beziehen. Context ctx = new InitialContext(props); // Referenz auf hello home Objekt Object obj = ctx.lookup("ejb/local/examples/HelloWorld"); HelloHome home = (HelloHome) javax.rmi.PortableRemoteObject.narrow(obj, HelloHome.class); // Instanz der Hello EJB krieren Hello hello = home.create(); // hello() Methode des EJB aufrufen System.out.println(hello.hello()); // EJB Instanz entfernen hello.remove(); } } Deployment von EJBs § Beans sollen installiert (deployed) werden können während der EJB-Server arbeitet (hot deployment) § Wichtig, wenn der EJB-Server kritische Anwendungen birgt § Beispiel Banking-Server, Einkaufsportal ... § Deployment Prozess hängt vom EJB-ServerProdukt ab § JBoss: entspr. Dateien in ein spezielles Verzeichnis kopieren ... Deployment Format § Das Deployment-Format ist im EJB-Standard spezifiziert § Die kompilierten Klassen einer EJB werden in ein Java-Archiv gepackt (.jar Datei) § Zusätzlich: Meta-Informationen über die EJB in einer XML-Datei – dem Deployment Descriptor § ear-Dateien § .jar und xml Datei werden (mit einigen weiteren Dateien) zu einem Enterprise Archiv (.ear Datei ähnlich zu .jar Datei) geschnürt. § Diese Datei wird dann „deployed“. JAR, WAR, EAR J2EE Application J2EE Application Depl. Descr. .ear-Datei J2EE Application Client Enterprise Bean Web Component J2EE Appl. Client Depl. Descr. Java Application EJB DD, EJB Class, Remote Home Web Comp. Depl. Descr. JSP, Servlets, GIFs, HTML .jar-Datei .jar-Datei .war-Datei Deployment Deskriptor § Enthält viele wichtige Info‘s für den EJB-Container, damit dieser weiß, wie eine EJB behandet werden soll § U. a. beschreibt der Deskriptor wie eine Bean zu verwalten ist bzgl.: § § § § § Transaktionalität Zugriffrechten und Schutz Persistenz Failover (Verhalten beim Absturz der EJB-Servers...) Nebenläufigkeit § Aufbau des Deskriptors ist Teil des EJB-Standards Der HelloWorld-Deskriptor <ejb-jar> <enterprise-beans> <session> <ejb-name>Hello</ejb-name> <home>hello.HelloHome</home> <remote>hello.Hello</remote> <local-home>hello.HelloLocalHome</local-home> <local>hello.HelloLocal</local> <ejb-class>hello.HelloBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> </enterprise-beans> </ejb-jar> Entity Beans § Repräsentieren persistente Zustände § Die Daten werden meist in einer relationalen Datenbank gespeichert § Der Standard für Entity-Beans ist auf ein (simples) O/R-Mapping ausgelegt § Es können auch andere Persistenzmechanismen (z. B. OODBMS) unterstützt werden Entity Beans § Persistenz kann § vom EJB-Container (transparent) erledigt werden (CMP – container managed persistence) § oder von Hand in der Entity Bean programmiert werden (BMP – bean managed persistence) § Bei BMP kann man JDBC einsetzen § Bei CMP übernimmt der Container die Implementierung/Umsetzung der ejbLoad(), ejbStore(), ejbCreate(), ejbRemove() – Methoden § Detaillierte Mapping-Infos werden im DeploymentDeskriptor und in container-spezifischen XML-Dateien beschrieben Entity Bean – Beispiel Code § Repräsentiert Personen-Objekte mit Namen und Id (Schlüssel) § Bean-Managed Persistence (BMP) § Daten werden über JDBC in rel. Datenbank gespeichert § Neben Standard Bean-Klassen gibt es noch die PersonPK die den DB-Schlüssel Id repräsentiert § DB besteht aus einer Tabelle Person(id, ownerName) Person.java Remote Interface package examples; import javax.ejb.*; import java.rmi.RemoteException; public interface Person extends EJBObject { public String getName() throws RemoteException; public void setName(String name) throws RemoteException; public String getID() throws RemoteException; public void setID(String id) throws RemoteException; } PersonHome.java package examples; import javax.ejb.*; import java.util.Collection; import java.rmi.RemoteException; public interface PersonHome extends EJBHome { public Person create(String id, String ownerName) throws CreateException, RemoteException; // findByPrimaryKey muss deklariert werden // weitere findBy … üblich public Person findByPrimaryKey(PersonPK key) throws FinderException, RemoteException; } PersonPK.java package examples; import java.io.Serializable; public class PersonPK implements java.io.Serializable { public String personID; public PersonPK(String id) { this.personID = id; } public PersonPK() {} public int hashCode() { return personID.hashCode(); } public boolean equals(Object person) { return ((PersonPK)person).personID.equals(personID); } } PersonBean.java (1) package examples; import import import import java.sql.*; javax.naming.*; javax.ejb.*; java.util.*; public class PersonBean implements EntityBean { protected EntityContext ctx; // Referenz auf den Container private String id; private String pName; … public public public public void setOwnerName(String name) { pName = name; } String getOwnerName() { return pName; } String getID() { return id }; void setID(String id) { this.id = id; } PersonBean.java (2) public void ejbRemove() throws RemoveException { PersonPK pk = (PersonPK) ctx.getPrimaryKey(); //PK des EJB-Objektes, // das mit der Bean assoziiert ist String id = pk.id; PreparedStatement pstmt = null; Connection conn = null; try { conn = getConnection(); pstmt = conn.prepareStatement("delete from persons where id = ?"); pstmt.setString(1, id); if (pstmt.executeUpdate() == 0) { throw new RemoveException("Person " + pk + " failed remove."); } } catch (Exception ex) { throw new EJBException(ex.toString()); } finally { /* ... schließen der JDBC Ressourcen ... */ } } PersonBean.java (3) public void ejbLoad() { PersonPK pk = (PersonPK) ctx.getPrimaryKey(); String id = pk.id; PreparedStatement pstmt = null; Connection conn = null; try { conn = getConnection(); pstmt = conn.prepareStatement( "select ownerName from persons where id = ?"); pstmt.setString(1, id); ResultSet rs = pstmt.executeQuery(); rs.next(); ownerName = rs.getString("ownerName"); } catch (Exception ex) { throw new EJBException("Person " + pk + " failed to load.", ex); } finally { // ... close JDBC resources... } } PersonBean.java (4) public PersonPK ejbFindByPrimaryKey(PersonPK key) throws FinderException { PreparedStatement pstmt = null; Connection conn = null; try { conn = getConnection(); pstmt = conn.prepareStatement("select id from persons where id = ?"); pstmt.setString(1, key.toString()); ResultSet rs = pstmt.executeQuery(); rs.next(); return key; } catch (Exception e) { throw new FinderException(e.toString()); } finally { // ... close JDBC resources... } } PersonBean.java (5) public public public public public void void void void void ejbActivate() {} ejbPassivate() {} setEntityContext(EntityContext ctx) { this.ctx = ctx; } unsetEntityContext() { this.ctx = null; } ejbPostCreate(String accountID, String ownerName) {} public void ejbStore() { // ... Ähnlich wie ejbLoad ... } public PersonPK ejbCreate(String id, String ownerName) throws CreateException { // ... Ähnlich wie ejbFindByPrimaryKey ... } PersonBean.java (6) public Connection getConnection() throws Exception { try { Context ctx = new InitialContext(); javax.sql.DataSource ds = (javax.sql.DataSource) ctx.lookup("java:comp/env/jdbc/ejbPool"); return ds.getConnection(); } catch (Exception e) { throw e; } } Zusammenfassung § Großteil JDBC Zugriffe die Tabellenzeilen auf EJB-Felder abbilden § PersonBean erweitert javax.ejb.EntityBean und muss § ejbLoad() zum Laden der Bean aus der DB und § ejbStore() zum Speichern den Bean in DB implementieren § sowie einige weiter Methoden implementieren § ejbFind...() Methoden dienen zum Finden von Enitity Beans über Suchkritierien § Es werden dann (meist) Mengen von Schlüsseln zurückgegeben. Alternativen § Verbreitete Open Source J2EEFrameworks § Web Framework § Apache Struts § Persistenzframeworks § Hibernate (POJO) § Java Data Objects Zusammenfassung Web Browser HTTPS Java Servlet Web Server Servlet Engine EJB Container EJB EJB EJB Database Connection Pools J2EE Application Server J D B C Datenbank Die Architektur des Web Das Web § Drei Grundlagen der Web Architektur: § Interaktion durch Protokolle wie HTTP § Identifikation durch Uniform Resource Identifiers URI § Datenformate wie HTML oder XML § (Informations-)Ressourcen werden identifiziert und durch Interaktion sind sie durch Übermittlung einer Nachricht in einer Repräsentation zugänglich http://www.mi.fu-berlin.de/kvv/?semester=12 KVV <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta httpequiv="content-type" content="text/html; charset=ISO-8859-1"> <title>Freie Universit&auml;t Berlin - Institut f&uuml;r Informatik - Kommentiertes Vorlesungsverzeichnis</title> HTTP Anforderungen § Anforderungen: § Für Nutzer: Hypermedia als Schnittstelle gewählt § Einheitliche Schnittstelle § Einfache Navigation § Einfache Suchmöglichkeiten Hypertext/Hypermedia H-Dokumente Präsentation Repräsentation § Für Autoren: § Unabhängigkeit vom Gesamtsystem § Informationen vor ihrer Entstehung referenzieren § Für Anwendungsentwickler: § Einfachheit H-Werkzeuge Navigation Suche Erstellung Anforderungen § Erweiterbarkeit § Einfachheit ohne Erweiterbarkeit verhindert Evolution § Anforderungen an das System ändern sich § Architektur muss erweiterbar sein § Verteiltheit § Repräsentationen von Informationen liegen an unterschiedlichen Orten § Nutzer soll keine zusätzliche Latenz spüren § Architektur muss Interaktionen über das Netz minimieren Anforderungen § Skalierbarkeit auf Internet-Größe § Ungestörter Betrieb bei Änderungen außerhalb der eigenen Organisation § Klienten sind unabhängig vom Wissen über alle Server § Server sind unabhängig vom Wissen über alle Klienten § Hypermedia Dokumente sind unabhängig von den Verweisen auf sie § Als Normalfall verzichtet man auf Sicherheit weil Authentifizierung Abhängigkeit von einer Vertrauensdomäne bedeutet § Unabhängige Evolution der Komponenten Wahl des Architekturstils § Das Web folgt dem Client-Server Stil § Trennung von § Aspekten der Nutzerschnittstelle (beim Klienten) § Aspekten der Datenhaltung (beim Server) § Höhere Portabilität der Nutzerschnittstelle § Bessere Skalierbarkeit der Server durch Einfachheit § Skalierbarkeit: Fähigkeit der Architektur, das aktive Zusammenspiel einer großen Menge von Komponenten oder einer großen Menge von Interaktionen zu unterstützen § Trennung erlaubt unabhängige Evolution der Komponenten Wahl des Architekturstils § Interaktion zwischen Klient und Server ist zustandslos § Anfrage nicht relativ zu einem Kontext auf Server § Zustand muss beim Klienten gehalten werden § Visibility erhöht, da nur eine Mitteilung betrachtet § Visibility: Fähigkeit von Komponenten der Architektur, Interaktionen zweier anderer Komponenten zu beobachten oder zu vermitteln § Zuverlässigkeit erhöht, weil nach Fehlern keine Historie nachgespielt werden muss § Skalierbarkeit erhöht, weil der Server keine Zustandsinformation speichern und managen muss § Nachteil: Mehr Netzverkehr wg. Zustandsübermittlung Wahl des Architekturstils § Mitteilungen können in einem Cache ($) gespeichert und später wiederverwendet werden § Ausgetauschte Mitteilungen müssen als zwischenspeicherbar erkennbar sein § Interaktionen werden vermieden, Netzwerklatenz sinkt § Nachteil: Zuverlässigkeit kann durch Inkonsistenzen sinken Wahl des Architekturstils § Zwischen Komponenten existieren einheitliche Schnittstellen § § § § Gleiche Identifikation von Ressourcen Ressourcen werden über Repräsentationen modifiziert Selbstbeschreibende Mitteilungen Hypermedia als Ausführungssystem Wahl des Architekturstils § Schichtenarchitektur § Reduktion von Komplexität und Abhängigkeiten § Nachteil: Overhead durch Verarbeitung über mehrere Schichten hinweg § Ausgeglichen durch Caches Wahl des Architekturstils § Code on demand § Funktionalität des Klienten kann durch nachgeladenen Code ( ) erweitert werden § Nachteil: Visibility sinkt REST Architektur / Daten § Ressourcen: Abstraktion von einer Information („Wetter in Berlin“) § Ressource ist eine Abbildung zu einer Zeit auf eine Menge von § Repräsentationen (HTML-Seite mit Beschreibung des Wetters,Bild) § Identifikationenen (URL der Beschreibungsseite, des Bilds) § Konzept von Ressourcen § Abstrahiert von einer möglichen Repräsentation § Erlaubt späte Bindung eines Werts an die Identifikation § Identifizierungen werden dezentral gewählt und verwaltet § Repräsentation § Darstellung des Zustands einer Ressource § Bytestrom + Metadaten § Kontrolldaten: Was soll mit der Repräsentation wie geschehen (z.B. PUT Methode oder Antwortcode) § Medientyp REST Architektur / Connectors § Conntector: Schnittstelle über die mit anderen Komponenten kommuniziert wird § Vorteile der Zustandslosigkeit: § § § § Connector muss keinen Zustand halten Keine Abhängigkeiten zwischen Interaktionen ð Parallelität Zwischengeschaltete Komponenten „verstehen“ komplette Interaktion Zwischenspeichern komplett möglich § Typen in REST: § § § § § Client (HTTP-Bibliothek beim Klienten) Server (HTTP-Bibliothek beim Klienten) Cache (im Browser) Resolver (DNS) Tunnel (SSL über HTTP) REST Architektur / Komponenten § Component: Ausgeführter Prozesse, nach seiner Aufgabe getypt § Typen in REST § § § § User agent (Browser) Origin server (Apache) Proxy – vom Klienten gewählt (CERN Proxy etc.) Gateway – vom Server festgelegt (CGI) § REST ganz kurz: § Alles ist komplett durch eine URI beschrieben § Ein Zugriff auf eine URI ist komplette Interaktion Identifikation URIs URI, URL, URN § Uniform Resource Identifier URI: „A Uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource“ [RFC 2396] § Request For Comments-Dokumente (RFC) definieren alle technischen Aspekte des Internet § RFC 1738 : T. Berners-Lee, L. Masinter, und M. McCahill. Uniform Resource Locators (URL). RFC 1738, Internet Engineering Task Force, December 1994. § Internet Engineering Taskforce IETF erstellt RFCs http://www.ietf.org/rfc.html § Standardisierungsprozess ist als RFC standardisiert: The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force, RFC 3160, August 2001 URI, URL, URN § Uniform Resource Identifier URI: „A Uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource“ [RFC 2396] § Lediglich Syntax: schema:schemaspezifischer_Teil § URI-Schema typisiert URIs: § § § § § § § § ftp://ftp.is.co.za/rfc/rfc1808.txt gopher://spinaltap.micro.umn.edu/00/Weather/Los%20Angeles http://www.math.uio.no/faq/compression-faq/part1.html#sec1 mailto:[email protected] news:comp.infosystems.www.servers.unix telnet://melvyl.ucop.edu/ urn:isbn:n-nn-nnnnnn-n fon:+49-838-0 URI, URL, URN § Uniform Resource Locator URL: „[…]a compact string representation for a resource available via the Internet.“ [RFC 1738] § Ist ein URI, dessen Schema auf die Zugreifbarkeit der Ressource im Netz hinweist § z.B. ftp://ftp.is.co.za/rfc/rfc1808.txt § Uniform Resource Name URN: „[…] intended to serve as persistent, location-independent, resource identifiers and are designed to make it easy to map other namespaces“ [RFC 2141] § Ist eher URI, der Eigenschaft der Ressource beschreibt § urn:isbn:n-nn-nnnnnn-n § URN-Namensraum strukturiert URNs (isbn,….) Registrierte URI Schemas [http://www.iana.org/assignments/uri-schemes.html] URI Scheme acap cid crid data dav dict dns fax file ftp go gopher h323 http https im imap Description application configuration access protocol content identifier TV-Anytime Content Reference Identifier data dav dictionary service protocol Domain Name System fax Host-specific file names File Transfer Protocol go The Gopher Protocol H.323 Hypertext Transfer Protocol Hypertext Transfer Protocol Secure Instant Messaging internet message access protocol Reference [RFC2244] [RFC2392] [RFC4078] [RFC2397] [RFC2518] [RFC2229] [RFC4501] [RFC2806] [RFC1738] [RFC1738] [RFC3368] [RFC4266] [RFC3508] [RFC2616] [RFC2818] [RFC3860] [RFC2192] info Information Assets with Identifiers in Public Namespaces [RFC-vandesompel-infouri-04.txt] ipp Internet Printing Protocol [RFC3510] Registrierte URI Schemas [http://www.iana.org/assignments/uri-schemes.html] URI Scheme iris.beep Description iris.beep Reference [RFC3983] ldap Lightweight Directory Access Protocol [RFC-ietf-ldapbis-url09.txt] mailto mid modem mtqp mupdate news nfs nntp opaquelocktoken pop pres rtsp service sip sips snmp Electronic mail address message identifier modem Message Tracking Query Protocol Mailbox Update (MUPDATE) Protocol USENET news network file system protocol USENET news using NNTP access opaquelocktokent Post Office Protocol v3 Presence real time streaming protocol service location session initiation protocol secure session initiation protocol Simple Network Management Protocol [RFC2368] [RFC2392] [RFC2806] [RFC3887] [RFC3656] [RFC1738] [RFC2224] [RFC1738] [RFC2518] [RFC2384] [RFC3859] [RFC2326] [RFC2609] [RFC3261] [RFC3261] [RFC4088] Registrierte URI Schemas [http://www.iana.org/assignments/uri-schemes.html] URI Scheme snmp soap.beep soap.beeps tag tel telnet tftp tip urn vemmi xmlrpc.beep xmlrpc.beeps xmpp z39.50r z39.50s Description Simple Network Management Protocol soap.beep soap.beeps tag telephone Reference to interactive sessions Trivial File Transfer Protocol Transaction Internet Protocol Uniform Resource Names (click for registry) versatile multimedia interface xmlrpc.beep xmlrpc.beeps Extensible Messaging and Presence Protocol Z39.50 Retrieval Z39.50 Session Reference [RFC4088] [RFC3288] [RFC3288] [RFC4151] [RFC2806] [RFC4248] [RFC3617] [RFC2371] [RFC2141] [RFC2122] [RFC3529] [RFC3529] [RFC4622] [RFC2056] [RFC2056] URN Namensräume [http://www.iana.org/assignments/urn-namespaces] IETF [RFC2648] liberty [RFC3622] PIN [RFC3043] IPTC [RFC3937] ISSN [RFC3044] UUID [RFC4122] OID [RFC3061] UCI [RFC4179] NEWSML [RFC3085] CLEI [RFC4152] OASIS [RFC3121] tva [RFC4195] XMLORG [RFC3120] fdc [RFC4198] publicid [RFC3151] ISAN [RFC4246] ISBN [RFC3187] NZL [RFC4350] NBN [RFC3188] oma [RFC4358] WEB3D [RFC3541] IVIS [RFC4617] MPEG [RFC3614] S1000D [RFC-rushing-s1000d-urn-00.txt] mace [RFC3613] fipa [RFC3616] swift [RFC3615] Mehrsprachige Web Adressen § URIs können nur aus einer kleinen Zeichenmenge zusammengesetzt sein § RFC 3986: Uniform Resource Identifier (URI): Generic Syntax § § § § § scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) path-abempty = *( "/" segment ) segment = *pchar pchar = unreserved / pct-encoded / sub-delims / ":" / "@" unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" § RFC 2234. Augmented BNF for Syntax Specifications: ABNF: § ALPHA = %x41-5A / %x61-7A ; A-Z / a-z Mehrsprachige Web Adressen § Mehrsprachige Bezeichner sind einfacher zu merken, zu interpretieren, zu erraten, für Markenbildung nötig [W3C. An Introduction to Multilingual Web Addresses, http://www.w3.org/Internation al/articles/idn-and-iri/] § Schema: Nur ASCII § Domain: International Domain Name, IDN [RFC 3490, 3491, 3492, 3454] § Pfad: Internationalized Resource Identifier, IRI [RFC 3987] IDN Auflösung § Problem: Nicht alle DNS Server können Unicode § -> Punycode § JP? ? .? .jp § Normalisierung (Leerzeichen, Kleinschreibung etc.) § Punycode-Bildung § xn- Markierung § - umfasst normale Zeichen § weiteres § xn--jp-cd2fp15c.xn--fsq.jp wird von DNS aufgelöst IRI Auflösung § Problem: Unterschiedliche Systeme nutzen unterschiedliche Zeichenkodierung bei der Pfadauflösung § /dir1/? ? ? ? .html § Normalisierung § Transformierung nach UTF-8 § An den Server geht per HTTP: GET /dir1/%E5%BC%95%E3%81%8D%E5%89%B2%E3%82%8A.html HTTP/1.1 Host: xn--jp-cd2fp15c.xn--fsq.jp § Mittlerweise in Internet Explorer 7, Firefox, Mozilla, Netscape, Opera, Safari implementiert HTML Nutzung Hypertext Markup Language § Dominierende Sprache zur Auszeichnung von Dokumenten im Internet § Definiert vom World Wide Web Consortium, W3C: § MIT (Massachusetts Institute of Technology, Computer Science and Artificial Intelligence Laboratory (CSAIL)) § ERCIM (European Research Consortium in Informatics and Mathematics) § Keio University of Japan § Jedes Informationssystem im Netz muss: § HTML Informationen integrieren können § HTML Ausgaben erzeugen § Mit HTML-Mitteln mit Nutzern interagieren Hypertext Markup Language § Konzepte: § Informationen werden als Dokumente aufgefasst § Dokumenteninhalte werden als Klartext dargestellt § Dokumententeile werden durch Markierungen/Elemente/Tags ausgezeichnet § Inhaltlich (<h1>Einleitung</h1>, <em>wichtig</em>) § Gestalterisch (<b>wichtig</b>) § Dokumente werden durch Links zu einem Hypertext verbunden (dadurch entsteht ein Netz, das Web) Quellanker mit Ankertext Foo bar blah blah blah foo bar. blah blah blah. Link Foo bar blah blah blah foo bar. blah blah blah. Zielanker mit Ankertext Verwendung von HTML Elementen nach Google Erhebung[http://code.google.com/webstats] Verwendung von HTML Elementen nach Google Erhebung[http://code.google.com/webstats] Verwendung von HTML Elementen nach Google Erhebung[http://code.google.com/webstats] § Verwendung von http-equiv und name bei <meta>: Literatur § Servlet und JSP Online Tutorial: § § § § § Servlet und JSP Buch: § § § § http://java.sun.com/j2ee/ Hibernate § § http://www.omg.org/gettingstarted/corbafaq.htm SUN‘s J2EE Site § § Turau, V.: Techniken zur Realisierung Web-basierter Anwendungen, Informatik Spektrum, 22 (1999) 1, S. 3-12. OMG‘s CORBA § § Hall, M.: Core Servlets and Java Server Pages; Sun Microsystems Press/Prentice Hall PTR, 2000. Übersichtsartikel: § § http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/ http://developer.java.sun.com/developer/onlineTraining/ JSPIntro/contents.html http://www.galileocomputing.de/openbook/javainsel5/, Chapter 17 http://www.hibernate.org Roy T. Fielding and Richard N. Taylor. Principled design of the modern Web architecture. ACM Transactions on Internet Technology (TOIT), 2(2), May 2002, pp. 115-150. Roy T. Fielding. Architectural styles and the design of network-based software architectures. PhD Thesis, University of California, Irvine, 2000. http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm W3C Webseiten
