services computing and service oriented architetures zum thema - java adventure builder - parallele...

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


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


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



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:


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



Typen von Teilnehmern und Ihre Interaktionen:

1. Endnutzer:


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



Typen von Teilnehmern und Ihre Interaktionen:

2. Module der Applikation:




Aufbau und Kommunikation anhand der identifizierten Teilnehmer


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



Teilmodule innerhalb des Order Processing Centers:



Ablauf eines Buchungsprozesses des Java Adventure Builders


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



Hauptprobleme:



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




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


“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).


Web Service-Definition


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



Externer 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 Anmelde-

Versendesystem Verwalten von asynchronen Nachrichten



Interner Nachrichtenaustausch


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



Datenformat des Nachrichtenaustauschs




Kommunikationsarchitektur



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


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


Entwurfsmuster zur Interaktion von Web Services



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



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)


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.

Split pattern und Join pattern



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


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


Synchroner vs. asynchroner Modus

AdventureBuilder


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


2. Handhabung beliebiger Dokumentschemata 3. Konzentration auf zentralen Verwaltungsknoten

Command pattern(Gamma, E. et al.(2004): Entwurfsmuster. 1. Aufl., Verlag Addison Wesley. München.)


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


1. Anhängen von Kontextinformationen (1/2)

3 verschiedene Varianten


priorityProcessing-Parameter im SOAP-Header:


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


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)


Client erzeugt ConcreteCommand-Objektund weist es Receiver zu

Invoker befiehlt Befehlsobjekt Anfrage auszuführen

ConcreteCommand ruft über excecute() Receiver auf

Receiver führtOperation aus


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


2. Handhabung beliebiger Dokumentschemata

Service A Service CService B

OPC

Schema A Schema B Schema C


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


3. Konzentration auf zentralen Verwaltungsknoten


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


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)


Danke für Ihre Aufmerksamkeit!

Fragen?

services computing and service oriented architetures zum thema - java adventure builder - parallele...

Documents