Java Adventure Builder - Parallele und verteilte Systeme
Werbung
Services Computing and Service Oriented Architetures zum Thema - Java Adventure Builder Die Anwendungsarchitektur und die plattformspezifischen Entwurfsmuster Parallele und verteilte Systeme SS 2005 © Ilija Panov, Alex Schlottmann Überblick Einleitung Java Blueprints Aufbau des Java Adventure Builders Architektur und Design des Kernmoduls Entwurfsmuster zur Interaktion von Web Services Verwaltung komplexer Web Service Interaktionen Zusammenfassung 11. Juli 2005 Panov / Schlottmann 2 Einleitung Java Adventure Builder Fiktive Applikation zur Buchung von Abenteuerreisen Erste vollständige service-orientierte Architektur der Java BluePrints Portabel, flexibel und interoperabel Veranschaulicht den Nutzen von Web Services Ermöglicht Entwicklern den Einstieg zur Entwicklung von Web Service gestützt e-commerce Lösungen 11. Juli 2005 Panov / Schlottmann 3 Java Blueprints Sind Hilfsmittel um java-spezifische Design- und Entwicklungsprobleme zu lösen Sie bestehen aus: Richtlinien Entwurfsmustern Code Beispielen Ziel ist die Entwicklung von Web Services und J2EEApplikationen Stellt spezielle Entwurfsmuster für die Interaktion von Web Services bereit 11. Juli 2005 Panov / Schlottmann 4 Java Adventure Builder Aufbau des Java Adventure Builders Grundkonzept: Katalog mit: Unterkünften Transportmöglichkeiten Freizeitaktivitäten Webseite Stellt den Katalog bereit Interaktion mit der Kundschaft Übermittelt gebuchte Aufträge Order Processing Center (OPC) Dient zur vollständigen Bearbeitung von Buchungsaufträgen Kommunikation mit externen Partnern und Anbietern 11. Juli 2005 Panov / Schlottmann 5 Java Adventure Builder Aufbau des Java Adventure Builders Typen von Teilnehmern und Ihre Interaktionen: 1. Endnutzer: Kundschaft: Interagiert mit der Webseite Geben zusammengestellte Abenteuerreisen in Auftrag Externe Partner und Anbieter: Fluggesellschaften, Bankunternehmen, Hotels etc. Bieten Teilkomponenten für Abenteuerreisen an Bearbeiten Teilaufträge 11. Juli 2005 Panov / Schlottmann 6 Java Adventure Builder Aufbau des Java Adventure Builders Typen von Teilnehmern und Ihre Interaktionen: 2. Module der Applikation: Webseite: Stellt Katalog zur Verfügung Übermittelt gebuchte Aufträge an das Order Processing Center Order Processing Center: Kernmodul des Adventure Builders Bearbeitung & Koordinierung der Buchungsaufträge Kommunikation mit externen Partnern und Anbietern 11. Juli 2005 Panov / Schlottmann 7 Java Adventure Builder Aufbau des Java Adventure Builders Aufbau und Kommunikation anhand der identifizierten Teilnehmer 11. Juli 2005 Panov / Schlottmann 8 Java Adventure Builder Aufbau des Java Adventure Builders Teilmodule innerhalb des Order Processing Centers: Order Receiver: Empfängt Buchungsaufträge mit eindeutiger Identifikationsnummer von der Webseite Leitet den Bearbeitungsprozess eines Buchungsauftrags ein Workflow Manager: Kernmodul innerhalb des OPC Koordiniert Buchungsaufträge Verfolgt den Bearbeitungsstatus der Buchungsaufträge Finance: Interagiert mit externen Bankunternehmen und Kreditinstituten Validierung und Liquitition des Auftraggebers Customer Relations Manager (CRM): Beliefert die Webseite mit Statusinformationen bzgl. des Buchungsauftrags Sendet ggf. Email-Nachrichten an den Auftraggeber Order Filler: Regelt den Nachrichtenaustausch mit den externen Partnern und Anbietern 11. Juli 2005 Panov / Schlottmann 9 Java Adventure Builder Aufbau des Java Adventure Builders 11. Juli 2005 Panov / Schlottmann 10 Java Adventure Builder Ablauf eines Buchungsprozesses des Java Adventure Builders 11. Juli 2005 Panov / Schlottmann 11 Java Adventure Builder Aufbau des Java Adventure Builders Hauptprobleme: Kommunikation Extern: Webseite & Order Processing Center Order Processing Center & externen Partnern und Anbietern Intern: Koordinierung und Bearbeitung der Buchungsaufträge innerhalb des Order Processing Center Interaktion Webseite 11. Juli 2005 Panov / Schlottmann 12 Java Adventure Builder Architektur und Design des OPC Entwicklung auf Basis der J2EE-Platform Forderungen sind: Stabilität Interoperabilität Flexibilität Architektur und Design abhängig von: Internem Nachrichtenaustausch Externen Nachrichtenaustausch Nachrichtenaustausch abhängig von: Kommunikationstechnologie Datentypen 11. Juli 2005 Panov / Schlottmann 13 Java Adventure Builder Architektur und Design des OPC Entwicklung auf Basis der J2EE-Platform Forderungen sind: Stabilität Interoperabilität Flexibilität Architektur und Design abhängig von: Internem Nachrichtenaustausch Externen Nachrichtenaustausch Nachrichtenaustausch abhängig von: Kommunikationstechnologie Datentypen 11. Juli 2005 Panov / Schlottmann 14 Java Adventure Builder Web Service-Definition “A Web service is a software application, accessible on the Web (or an enterprise’s intranet) through a URL, that is accessed by clients using XML-based protocols, such as Simple Object Access Protocol (SOAP) sent over accepted Internet protocols, such as HTTP. Clients access a Web service application through its interfaces and bindings, which are defined using XML artifacts, such as a Web Services Definition Language (WSDL) file.” (Singh et al., Designing Web Services with the J2EE 1.4 Platform). 11. Juli 2005 Panov / Schlottmann 15 Java Adventure Builder Architektur und Design des OPC Externer Nachrichtenaustausch Web Services für Kommunikation und Interaktion mit Webseite Externen Anbietern und Partnern Web Services ermöglichen: Entkopplung von Softwaresystemen Aufteilung von Softwaresystemen Externe Partner unabhängig von Wahl ihrer Software 11. Juli 2005 Panov / Schlottmann 16 Java Adventure Builder Architektur und Design des OPC Interner Nachrichtenaustausch Java Message Service (JMS) für Kommunikation innerhalb des OPC Gründe für die Wahl von JMS: JMS bereits in der J2EE-Platform integriert Teilmodule des OPC alle innerhalb derselben Umgebung Kommunikation findet über einen zentralen Manager statt (Workflow Manager) Gekoppelte Kommunikation zwischen den Teilmodulen JMS unterstützt Nachrichtenschlangen und ein AnmeldeVersendesystem Verwalten von asynchronen Nachrichten 11. Juli 2005 Panov / Schlottmann 17 Java Adventure Builder Architektur und Design des OPC Datenformat des Nachrichtenaustauschs Extensible Markup Language (XML) als Datenformat für internen und externen Nachrichtenaustausch Gründe für die Wahl von XML: Bietet eine flexible Datenstruktur der Informationen, abhängig von der Kommunikation mit den externen Diensten Ermöglicht die Umsetzung eines Dokumentorientiertes System Unabhängigkeit und Entkopplung der Teilmodule Unterstreicht die Verwendung des Workflow Managers der sich um die Koordination der Teilmodule kümmert 11. Juli 2005 Panov / Schlottmann 18 Java Adventure Builder Architektur und Design des OPC Kommunikationsarchitektur 11. Juli 2005 Panov / Schlottmann 19 Java Adventure Builder Zwischenübersicht Einleitung Java BluePrints Aufbau des Java Adventure Builders Architektur und Design des Kernmoduls Entwurfsmuster zur Interaktion von Web Services Verwaltung komplexer Web Service Interaktionen Zusammenfassung 11. Juli 2005 Panov / Schlottmann 20 Java Adventure Builder Entwurfsmuster zur Interaktion von Web Services 3 verschiedene Strategien bzw. Entwurfsmuster Correlation identifier Split pattern / join pattern Synchroner vs. asynchroner Modus Können separat oder in Kombination eingesetzt Entwurfsmuster und Strategien kommen in der OPC zum Einsatz Beim Java Adventure Builder werden sie kombiniert Ziel: Unterstützung bei der Entwicklung komplexer und effizienter Web Service-Interaktionen 11. Juli 2005 Panov / Schlottmann 21 Java Adventure Builder Correlation Identifier Identifizierung von Requests, die mehrere Teilaufgaben enthalten Zuordnung der Teilaufgaben zu dem Request Muss eindeutig gewählt sein; vgl. Primärschlüssel in der Datenbankwelt Entwickler muss festlegen, ob Client oder Service den correlation identifier vergibt OPC beim Java Adventure Builder Mögliches Szenario (allgemein): Client übergibt Request und möchte später Bearbeitungsstatus abrufen 11. Juli 2005 Panov / Schlottmann 22 Java Adventure Builder Szenario (Java Adventure Builder): Mehrere Nutzer schicken Buchungsaufträge über die Webseite des Adventure Builder ab (Transport, Hotel, Aktivitäten) Correlation identifier wird an einkommenden Buchungsauftrag angehangen; Beginn der Bearbeitung (order receiver) Verfolgung des Bearbeitungsstatus des Buchungsauftrags; Kommunikation mit Teilmodulen des OPC (workflow manager) Austausch der Teilaufgaben des eingegangenen Buchungsauftrags der Nutzer mit den verschiedenen externen Partnern und Anbietern (order filler) 11. Juli 2005 Panov / Schlottmann 23 Java Adventure Builder Split pattern und Join pattern Split pattern: Request ist mit correlation identifier gekennzeichnet Zerlegung des Requests in mehrere Teilaufgaben Teilaufgaben werden den entsprechenden Web Services zur Bearbeitung übergeben Join pattern: Ensprechend dem correlation identifier werden die abgearbeiteten Teilaufgaben wieder zu einer Response zusammengeführt Szenario (Java Adventure Builder): Betrachtung eines Buchungsauftrags eines Nutzers. Buchungsauftrag wird in Teilaufgaben zerlegt, und später wieder zusammengeführt. 11. Juli 2005 Panov / Schlottmann 24 Java Adventure Builder Request beinhaltet Buchungsauftrag mit Teilaufgaben für die externen Partner; Order receiver vergibt correlation identifier Mittels split pattern wird Request in die Teilaufgaben zerlegt Order filler verschickt Teilaufgaben zur Bearbeitung zu den Web Services der Partner Mittels join pattern werden im die abgearbeiteten Teilaufgaben zur Response zusammengesetzt 11. Juli 2005 Panov / Schlottmann 25 Java Adventure Builder Synchroner vs. asynchroner Modus Adventure Builder Synchroner Modus: Nach versenden des Requests verweilt der Client in einer Art Wartezustand Asynchroner Modus: Client wartet nicht erst auf Response, sondern kann mit anderer Tätigkeit fortfahren Asynchroner Modus wird durch Einsatz von Java Message Service (JMS) erreicht J2EE stellt JMS bereit => Java Adventure Builder nutzt JMS 11. Juli 2005 Panov / Schlottmann 26 Java Adventure Builder Verwaltung komplexer Web Service-Interaktionen Kommunikation und Interaktion der Services basiert auf Austausch vom XML-Kontextdokumenten Interaktion der Services wird komplexer => Komplexität, Struktur und Anzahl der Kontextdokumente nimmt zu 1. Anhängen von Kontextinformationen 2. Handhabung beliebiger Dokumentschemata 3. Konzentration auf zentralen Verwaltungsknoten Command pattern (Gamma, E. et al.(2004): Entwurfsmuster. 1. Aufl., Verlag Addison Wesley. München.) 11. Juli 2005 Panov / Schlottmann 27 Java Adventure Builder 1. Anhängen von Kontextinformationen (1/2) 3 verschiedene Varianten 1. Variante: Einfügen der Information in das XML-Dokument XML-Schema muss geändert werden Gesamtes XML-Dokument muss geparst werden, um Information auslesen zu können Einfache Implementierung 2. Variante: Einfügen der Information in das Web ServiceInterface Eingriff in das Interface Sehr fehleranfällig, schwierige Implementierung 3. Variante: Einfügen der Information in den SOAP-Header Java Adventure Builder 11. Juli 2005 Panov / Schlottmann 28 Java Adventure Builder 1. Anhängen von Kontextinformationen (2/2) priorityProcessing-Parameter im SOAP-Header: Vorteil: kein Eingriff in XML-Schema, logische Trennung zwischen zusätzlicher Information und Nachrichtenrumpf, gesammtes XML-Dokument muss nicht geparst werden Nachteil: komplexe Implementierung, da zusätzlich SOAP-Kenntnisse erforderlich sind 11. Juli 2005 Panov / Schlottmann 29 Java Adventure Builder Command Pattern (Verhaltensmuster) Invoker befiehlt Befehlsobjekt Anfrage auszuführen Receiver führt Operation aus Client erzeugt ConcreteCommand-Objekt und weist es Receiver zu ConcreteCommand ruft über excecute() Receiver auf Kapselt eine oder mehrere Anfragen, bzw. Befehle als ein Objekt So lassen sich Befehle als Parameter übergeben oder in eine Warteschlange einfügen 11. Juli 2005 Panov / Schlottmann 30 Java Adventure Builder 2. Handhabung beliebiger Dokumentschemata Jeder Service verfügt über eigenes XML-Schema Für jedes neues Schema neue Operation im Interface Ständiger Eingriff in das Interface Service A Mit command pattern wird jedes Schema als ein Objekt gespeichert; können dann als Parameter übergeben werden So kann eine Methode beliebige Schemata lesen 11. Juli 2005 Panov / Schlottmann Schema A Service B Schema B Service C Schema C OPC 31 Java Adventure Builder 3. Konzentration auf zentralen Verwaltungsknoten Web Service-Interaktionen werden durch zentralen Verwaltungsknoten gesteuert (centralized manager) Implementiert ist er zwischen dem order filler und den externen Partnern Centralized manager übernimmt Zerlegen und Vereinigung der Teilaufgaben 11. Juli 2005 Panov / Schlottmann 32 Zusammenfassung (1/2) Java BluePrints fokussieren Entwicklung von Web Services und Enterprise Applikationen mit der J2EE Java Adventure Builder fokussiert Entwicklung komplexer Web Service-Interaktionen Geschäftsverflechtungen über Netzwerke immer bedeutender => Web Service-Interaktionen werden komplexer Zentrum bildet OPC als Schalt- und Verwaltungszentrum; Kernmodul des Adventure Builder Idee und Umsetzung der OPC ist übertragbar Entwurfsmuster / Strategien auch für andere Applikationen einsetzbar 11. Juli 2005 Panov / Schlottmann 33 Zusammenfassung (2/2) Eingesetztes Buch der Java BluePrints eignet sich zur Unterstützung für den Entwickler J2EE-Kenntnisse werden vorausgesetzt Kapitel über Adventure Builder sehr oberflächlich Eingestzte Technologien werden in den Kapiteln zuvor beschrieben Java BluePrints-Webseite dient als weitere Informationsquelle (http://java.sun.com/blueprints/enterprise/index.html) Java Adventure Builder zum download Eingesetztes Buch als pdf zum download Viele Code-Bespiele, Erläuterungen, Entwurfsmuster Weitere Referenzapplikation verfügbar (Java Pet Store) 11. Juli 2005 Panov / Schlottmann 34 Danke für Ihre Aufmerksamkeit! Fragen? 11. Juli 2005 Panov / Schlottmann 35
