Date post: | 05-Apr-2015 |
Category: |
Documents |
Upload: | beate-edelbrock |
View: | 106 times |
Download: | 0 times |
Services Computing and Service Oriented Architetures
zum Thema
- Java Adventure Builder -
Parallele und verteilte SystemeSS 2005© Ilija Panov, Alex Schlottmann
Die Anwendungsarchitektur und die plattformspezifischen Entwurfsmuster
11. Juli 2005 Panov / Schlottmann 2
Ü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 3
Einleitung
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
Java Adventure Builder
11. Juli 2005 Panov / Schlottmann 4
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 J2EE-Applikationen
Stellt spezielle Entwurfsmuster für die Interaktion von Web Services bereit
11. Juli 2005 Panov / Schlottmann 5
Java Adventure Builder
Aufbau des Java Adventure Builders
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
Grundkonzept:
11. Juli 2005 Panov / Schlottmann 6
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
Java Adventure Builder
Aufbau des Java Adventure Builders
Typen von Teilnehmern und Ihre Interaktionen:
1. Endnutzer:
11. Juli 2005 Panov / Schlottmann 7
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
Java Adventure Builder
Aufbau des Java Adventure Builders
Typen von Teilnehmern und Ihre Interaktionen:
2. Module der Applikation:
11. Juli 2005 Panov / Schlottmann 8
Java Adventure Builder
Aufbau des Java Adventure Builders
Aufbau und Kommunikation anhand der identifizierten Teilnehmer
11. Juli 2005 Panov / Schlottmann 9
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
Java Adventure Builder
Aufbau des Java Adventure Builders
Teilmodule innerhalb des Order Processing Centers:
11. Juli 2005 Panov / Schlottmann 10
Java Adventure Builder
Aufbau des Java Adventure Builders
11. Juli 2005 Panov / Schlottmann 11
Java Adventure Builder
Ablauf eines Buchungsprozesses des Java Adventure Builders
11. Juli 2005 Panov / Schlottmann 12
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
Aufbau des Java Adventure Builders
Java Adventure Builder
Hauptprobleme:
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
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 15
“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).
Java Adventure Builder
Web Service-Definition
11. Juli 2005 Panov / Schlottmann 16
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
Java Adventure Builder
Architektur und Design des OPC
Externer Nachrichtenaustausch
11. Juli 2005 Panov / Schlottmann 17
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 Anmelde-
Versendesystem Verwalten von asynchronen Nachrichten
Architektur und Design des OPC
Java Adventure Builder
Interner Nachrichtenaustausch
11. Juli 2005 Panov / Schlottmann 18
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 Dokument-orientiertes System
Unabhängigkeit und Entkopplung der Teilmodule Unterstreicht die Verwendung des Workflow
Managers der sich um die Koordination der Teilmodule kümmert
Java Adventure Builder
Architektur und Design des OPC
Datenformat des Nachrichtenaustauschs
11. Juli 2005 Panov / Schlottmann 19
Java Adventure Builder
Architektur und Design des OPC
Kommunikationsarchitektur
11. Juli 2005 Panov / Schlottmann 20
Java Adventure Builder
Entwurfsmuster zur Interaktion von Web Services Verwaltung komplexer Web Service Interaktionen Zusammenfassung
Zwischenübersicht
Einleitung Java BluePrints Aufbau des Java Adventure Builders Architektur und Design des Kernmoduls
11. Juli 2005 Panov / Schlottmann 21
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
Java Adventure Builder
Entwurfsmuster zur Interaktion von Web Services
11. Juli 2005 Panov / Schlottmann 22
Java Adventure Builder
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
Correlation Identifier
11. Juli 2005 Panov / Schlottmann 23
Java Adventure Builder
Szenario (Java Adventure Builder):Mehrere Nutzer schicken Buchungsaufträge über die Webseite des Adventure Builder ab (Transport, Hotel, Aktivitäten)
Verfolgung des Bearbeitungsstatus des Buchungsauftrags; Kommunikation mit Teilmodulen des OPC (workflow manager)
Correlation identifier wird an einkommenden Buchungs-auftrag angehangen; Beginnder Bearbeitung (order receiver)
Austausch der Teilaufgaben des eingegangenen Buchungsauftrags der Nutzer mit den verschiedenen externen Partnern und Anbietern (order filler)
11. Juli 2005 Panov / Schlottmann 24
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
Java Adventure Builder
Szenario (Java Adventure Builder):Betrachtung eines Buchungsauftrags eines Nutzers. Buchungsauftrag wird in Teilaufgaben zerlegt, und später wieder zusammengeführt.
Split pattern und Join pattern
11. Juli 2005 Panov / Schlottmann 25
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 26
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
Java Adventure Builder
Synchroner vs. asynchroner Modus
AdventureBuilder
11. Juli 2005 Panov / Schlottmann 27
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
Verwaltung komplexer Web Service-Interaktionen
Java Adventure Builder
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 28
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 Service-Interface Eingriff in das Interface Sehr fehleranfällig, schwierige Implementierung
3. Variante: Einfügen der Information in den SOAP-Header Java Adventure Builder
Java Adventure Builder
1. Anhängen von Kontextinformationen (1/2)
3 verschiedene Varianten
11. Juli 2005 Panov / Schlottmann 29
priorityProcessing-Parameter im SOAP-Header:
Java Adventure Builder
1. Anhängen von Kontextinformationen (2/2)
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 30
Kapselt eine oder mehrere Anfragen, bzw. Befehle als ein Objekt So lassen sich Befehle als Parameter übergeben oder in eine
Warteschlange einfügen
Command Pattern (Verhaltensmuster)
Java Adventure Builder
Client erzeugt ConcreteCommand-Objektund weist es Receiver zu
Invoker befiehlt Befehlsobjekt Anfrage auszuführen
ConcreteCommand ruft über excecute() Receiver auf
Receiver führtOperation aus
11. Juli 2005 Panov / Schlottmann 31
Jeder Service verfügt über eigenes XML-Schema
Für jedes neues Schema neue Operation im Interface
Ständiger Eingriff in das Interface
Mit command pattern wird jedes Schema als ein Objekt gespeichert; können dann als Parameter übergeben werden
So kann eine Methode beliebige Schemata lesen
Java Adventure Builder
2. Handhabung beliebiger Dokumentschemata
Service A Service CService B
OPC
Schema A Schema B Schema C
11. Juli 2005 Panov / Schlottmann 32
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
Java Adventure Builder
3. Konzentration auf zentralen Verwaltungsknoten
11. Juli 2005 Panov / Schlottmann 33
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 34
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)
Zusammenfassung (2/2)
11. Juli 2005 Panov / Schlottmann 35
Danke für Ihre Aufmerksamkeit!
Fragen?