- Java Adventure Builder -

Transkript

1 Westfälische Wilhelms-Universität Münster Juli 2005 Fachbereich 10 - Institut für Informatik Arbeitsgruppe PVS Dozierende: Prof. S. Gorlatch, Dipl.-Inf. J. Dünnweber, Dipl.-Inf. J. Müller SS 2005 Seminar Service-Oriented Architectures zum Thema - Java Adventure Builder - Bearbeitet von: Alexander Schlottmann Mondstraße 1c Münster Diplom Geoinformatik a.schlottmann@gmx.net

2 Inhalt Inhalt...i 1. Einleitung Web Services Aufbau des Java Adventure Builders Grundkonzept des Java Adventure Builders Teilmodule des Java Adventure Builders und ihre Funktionen Ablauf eines Buchungsauftrages Architektur und Design des Kernmoduls Interner und externer Nachrichtenaustausch Datenformat des Nachrichtenaustauschs Kommunikationsarchitektur Designprobleme der Schnittstellen eines Web Services Zusammenfassung Literatur Bücher Internet Parallele und verteilte Systeme i

3 1. Einleitung Service Oriented Architectures 1. Einleitung Das Thema meiner Ausarbeitung im Seminar Parallele und verteilte Systeme lautet Services Computing und Service-Oriented Architectures (SOA). Es wird hierbei auf die Anwendungsarchitektur und das Design des Java Adventure Builder eingegangen. Zunächst ein paar Worte zum Java Adventure Builder. Er ist eine fiktive Applikation, die es dem Nutzer ermöglicht, eine Abenteuerreise als Gesamtpaket zu buchen. Dabei kann er zwischen verschiedenen Angeboten von Transportmöglichkeiten, Unterbringung und Freizeitaktivitäten wählen und vergleichen. Anhand dieser Referenzapplikation soll dem Leser demonstriert werden, wie er portable und interoperable Web Services mit der J2EE- Plattform entwickelt. Er ist die erste vollständige SOA Applikationen innerhalb der Java BluePrints. Der Aufbau der Ausarbeitung gliedert sich in die Kapitel Einleitung, Web Services, Aufbau des Java Adventure Builder, Architektur und Design des Kernmoduls, Designprobleme der Schnittstellen eines Web Services und einer abschließenden Zusammenfassung. Die Kapitel zum Aufbau, Architektur und Design des Kernmoduls, sowie Designprobleme der Schnittstellen eines Web Services werden den Hauptteil der Ausarbeitung umfassen. Jedes Kapitel beinhaltet ein kurzes Fazit Die abschließende Zusammenfassung wirft dann einen Blick auf die gesammelten Erkenntnisse der Hauptkapitel. Somit wären noch die Ziele zu nennen, die diese Seminararbeit erreichen soll. Anhand des Java Adventure Builders werden die darin genutzten Architektur- und Designentscheidungen vorgestellt und beschrieben. Hierzu wird auf die genutzten Technologien und deren Möglichkeiten zur Umsetzung des Java Adventure Builders eingegangen. Es soll weiterhin dargestellt werden, welche Gesichtspunkte bei der Entwicklung eines Web Services beachtet werden sollten. Letztendlich soll auch im Zusammenhang analysiert werden, wie die zur Verfügung stehenden Literatur- und Internetquellen dem Entwickler behilflich sein können. Als Grundlage und Quelle der Seminararbeit dient das als Teil des SUN BluePrint Programms erschienene Buch Designing Web Services with the J2EE 1.4 Platform und die Referenzapplikation Java Adventure Builder selbst, sowie verschiedene Internetquellen zu Web Services. Parallele und verteilte Systeme 1

4 2. Web Services Service Oriented Architectures 2. Web Services Der Java Adventure Builder ist die Referenzimplementierung einer Web Service gestützte E-commerce Lösung zur Onlinebuchung von Abenteuerreisen. Der Java Adventure Builder wird auf Basis der J2EE-Platform entwickelt. An dieser Stelle wird kurz darauf eingehen, was die Java Entwicklungsumgebung unter einem Web-Service versteht und was ihn und seine Leistungsfähigkeit kennzeichnet. 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. [1]. Dieses Zitat aus dem oben erwähnten Buch ähnelt zwar im wesentlichen der gängigen Definition des W3C[3], allerdings greift sie eher technische Aspekte aus der Sicht des Entwicklers auf. Diese Art der Web Service-Definition steht daher auch im Einklang mit dem Grundgedanken der BluePrints; man möchte dem Entwickler die Architektur- und Designentscheidungen erleichtern, ihn dabei unterstützen, indem man konkrete Implementierungsaspekte und die zur Verfügung stehenden Technologien beschreibt. Hierbei wird insbesondere auf die Vor- und Nachteile der einzelnen Technologien eingegangen. Die Beschreibung eines Web Service beschränkt sich aber natürlich nicht nur darauf. Schlagwörter wie Portabilität, Interoperabilität über verschiedene Plattformen und Programmiersprachen, Flexibilität, Entkopplung und Zusammenführung von Softwaresystemen, Effizienz sind weitere häufig genannte Features von Web Services. In dem Hauptteil der Ausarbeitung werden einzelne beim Java Adventure Builder realisierte Architektur- und Designaspekte herausgegriffen und kurz auf die verwendeten Technologien eingegangen. Bei der abschließenden Zusammenfassung kann somit hinterfragt werden, inwieweit die Schlagwörter die einen Web-Service auszeichnen, erkennbar sind. Weiterhin wird diskutiert, ob der Java Adventure Builder eine Serviceoriented architecture (SOA) realisiert. Parallele und verteilte Systeme 2

5 3. Aufbau des Java Adventure Builders Service Oriented Architectures 3. Aufbau des Java Adventure Builders Die Entwickler der Java BluePrints haben mit dem Java Adventure Builder nicht völlig willkürlich einen fiktiven Online-Reservierungsdienst für Reisen entwickelt. Viele Menschen nutzen heutzutage das Internet um beispielsweise Flüge oder Pauschalreisen zu buchen. Daher ist diese Referenzapplikation von der Idee her für den Entwickler nicht etwas völlig neues. In der heutigen Zeit, in der Onlineshops einen immer höheren Stellenwert erlangen, und dabei Web Services ein immer größer werdendes Maß an Aufgaben zugeteilt wird, müssen bei der Entwicklung verschiedene Richtlinien bezüglich der Architektur und dem Design von Web Services beachtet werden. Bei der Entwicklung eines Web Services wird man mit verschiedenen Architektur- und Designproblemen konfrontiert, die gelöst werden müssen, damit eine reibungslose Kommunikation zwischen den Web Services möglich ist. Im Folgenden wird auf das Grundkonzept der Applikation eingegangen, und Entscheidungen, die für den Aufbau der Applikation getroffen worden sind, erläutert. Die Applikation wird dabei von höchster Ebene betrachtet, das heißt aus betriebswirtschaftlicher Sicht. Der Aufbau der Applikation ist abhängig von den Funktionen, die während der Entwicklung des Grundkonzeptes abgeleitet werden. Diese Funktionen müssen zur Verfügung gestellt werden, um eine reibungslose Kommunikation und eine vollständige Bearbeitung eines Buchungsauftrags zu gewährleisten. 3.1 Grundkonzept des Java Adventure Builders Der Java Adventure Builder stellt seiner Kundschaft einen Katalog mit Abenteuerpaketen zur Verfügung, die sowohl Unterkünfte, Freizeitaktivitäten als auch Transportmöglichkeiten beinhalten. Den Zugriff auf diesen Katalog wird den Nutzern durch eine Webseite ermöglicht, die im Java Adventure Builder integriert ist. Mit Hilfe des Browsers kann sich die Kundschaft über die Webseite, den nach ihren Interessen gewünschten Urlaub, zusammenstellen. Die Webseite stellt anhand selektierter Informationen die Anforderung für Buchungsaufträge zusammen. Mittels eines Bestätigen- Buttons, der vom Auftraggeber betätigt wird, werden die Buchungsinformationen zum Order Processing Center (OPC) gesendet. Das OPC ist verantwortlich für die Ausführung des Auftrags und interagiert mit internen Abteilungen, externen Partnern und Lieferanten um den Auftrag zu bearbeiten, vervollständigen und den Auftraggeber über den Status seines Buchungsauftrages zu informieren. Die Webseite wird als Front-End[1] und das Parallele und verteilte Systeme 3

6 3. Aufbau des Java Adventure Builders Service Oriented Architectures OPC als Back-End[1] bezeichnet. Das Front-End dient lediglich als Oberfläche, über das die Kundschaft mit dem Adventure Builder kommuniziert. Das Back-End bearbeitet den Buchungsauftrag. Der Ablauf des Buchungsprozesses ist für die Kundschaft unsichtbar. Die Applikation besteht aus einer Webseite, die der Kundschaft den Zugang zum Service bietet und dem OPC der im Hintergrund läuft, und die vollständige Bearbeitung des Auftrages abwickelt. Es lassen sich verschiedene Typen von Teilnehmer ableiten, die miteinander interagieren (siehe Abb. 1). - Endnutzer: o Kundschaft: die über Interaktionen mit der Webseite Abenteuerreisen nach Ihren Wünschen zusammenstellen und diese in Auftrag geben o Externe Partner und Lieferanten: dies können Fluggesellschaften, Bankunternehmen, Hotels und andere Anbieter sein, die einzelne Komponenten für den Urlaub zur Verfügung stellen bzw. den Zahlungsverkehr regeln - Module des Java Adventure Builders: o Webseite: die es der Kundschaft ermöglicht mit ihr zu interagieren und ihnen einen Katalog von Abenteuerreisen zur Verfügung stellt. Sie kommuniziert mit dem OPC und übermittelt gebuchte Aufträge o Order Processing Center (OPC): es bildet das Kernmodul des Java Adventure Builders und ist verantwortlich für die vollständige Bearbeitung und Koordinierung gebuchter Aufträge. Abbildung 1: Aufbau des Java Adventure Builders Parallele und verteilte Systeme 4

7 3. Aufbau des Java Adventure Builders Service Oriented Architectures Die Interaktion der einzelnen Teilnehmer stellt das Hauptproblem des Java Adventure Builder dar. Bei dem Buchungsprozess ist sichergestellt, dass die Kundschaft erfolgreich über die Webseite mit dem Java Adventure Builder interagieren kann. Er bietet der Kundschaft einen Katalog von Abenteuerpaketen an, bearbeitet und koordiniert übermittelte Buchungsaufträge und teilt der Kundschaft den Status der Buchung mit. Um dieses Problem zu lösen ist es notwendig geeignete J2EE-Applikationen zu entwickeln, die die Architektur und das Design für diese Services bereitstellen und verbinden, damit eine reibungslose Kommunikation möglich ist. Aus diesem Grund wird das Order Processing Center in weitere Module unterteilt, die die Kommunikation und Interaktion sowohl intern als auch mit den externen Partnern übernehmen. 3.2 Teilmodule des Java Adventure Builders und ihre Funktionen Für die Bearbeitung eines Buchungsauftrages innerhalb des OPC treten verschiedene Funktionen auf, die durch logische Teilmodule übernommen werden. Zum einen muss es möglich sein, Buchungsaufträge von der Webseite zu empfangen und diese weiterzuverarbeiten, was einer Koordination von verschiedenen Aktivitäten entspricht. Der Benutzer muss über den Status seiner Buchung informiert werden. Diese Informationen werden durch s versendet oder im Account des Benutzers festgehalten. Weiterhin werden Zahlungsdaten verarbeitet, die Interaktionen mit Kreditinstituten darstellen. Das OPC kommuniziert mit externen Partnern um einen Buchungsauftrag bis zum Ende bearbeiten zu können. Und zu guter letzt ist es noch notwendig, dass ein Katalog zur Verfügung gestellt wird. Aus den Funktionen ergeben sich folgende Teilmodule innerhalb des OPC, die einzelne Bearbeitungsprozesse übernehmen (siehe Abb. 2): Order Receiver Modul; bekommt Buchungsaufträge übermittelt, die durch eine eindeutige Identifikationsnummer markiert werden. Workflow-Manager Modul: verfolgt den Bearbeitungsstatus des Buchungsauftrages, wozu er mit den einzelnen Teilmodulen interagieren muss und die Teilnehmer im Prozessverlauf koordiniert (Kernmodul innerhalb des OPC) Finance Modul: interagiert mit externen Bankunternehmen und Kreditinstituten um finanzielle Informationen zu verarbeiten Parallele und verteilte Systeme 5

8 3. Aufbau des Java Adventure Builders Service Oriented Architectures Customer Relations Manager Modul(CRM): beliefert die Webseite mit Informationen bzgl. des Buchungsauftrags und sendet ggf. -Nachrichten an den Auftraggeber Order Filler Modul: tauscht hinsichtlich der Bearbeitung des Buchungsauftrags Informationen mit den verschiedenen externen Partner und Anbietern aus Abbildung 2: Teilmodule des Order Processing Centers 3.3 Ablauf eines Buchungsauftrages Bevor der Auftrag verarbeitet wird, stellt das Finance-Modul eine Anfrage an das Kreditinstitut, um die Daten des Auftragsgebers zu verifizieren und überprüft, ob der Kunde das nötige Geld hat um den Auftrag zu bezahlen. Ist dies nicht der Fall, wird der Auftrag storniert und der Kunde durch eine informiert. Anderenfalls wird der Auftrag unterteilt. Einzelne Bestände werden an die dafür zuständigen Teilmodule durch das Workflow-Manager Modul weitergeleitet. Die Bearbeitung beginnt. Die Teilmodule senden hierbei Anfragen an die jeweiligen externen Partner, die ihrerseits den Auftrag bearbeiten, und die Ergebnisse an das OPC zurücksenden. Während des Bearbeitungsprozesses werden zwischen den Teilmodulen Nachrichten ausgetauscht, so zum Beispiel beim Workflow-Manager Modul, das während des gesamten Prozesses mit Parallele und verteilte Systeme 6

9 3. Aufbau des Java Adventure Builders Service Oriented Architectures den einzelnen Teilmodulen interagiert, um den Status des Auftrages zu erfragen und ggf. den Kunden mittels -Nachrichten informiert. Abbildung 3: Ablauf der Bearbeitung eines Buchungsauftrags Die Anwendungsarchitektur und die Kommunikation ergeben sich aus den Teilnehmern und den Funktionen, die der Java Adventure Builder für die vollständige Bearbeitung eines Buchungsauftrages leistet. Die Funktionen, wie zum Beispiel das überprüfen der Kontodaten, werden durch einzelne Teilmodule realisiert. Die Interaktionen mit den internen und externen Modulen werden durch das Workflow-Manager Modul koordiniert. Anhand dieser Aufteilung lässt sich bereits erkennen, dass der Java Adventure Builder einen komplexen Kommunikations- und Interaktionsprozess leisten muss, um seiner Aufgabe als Service-orientierte Architektur zur Online-Buchung von Abenteuerreisen gerecht zu werden. Parallele und verteilte Systeme 7

10 4. Architektur und Design des Kernmoduls Service Oriented Architectures 4. Architektur und Design des Kernmoduls Der Java Adevnture Builder wird auf Grundlage der J2EE-Plattform entwickelt. Dies umfasst verschiedene Technologien, die für die Realisierung der Interaktionen und Kommunikationen zum Einsatz kommen können, z.b. EJB, JSP, JMS, RMI/IIOP, Web Services. Jede dieser Technologien ist für verschiedene Fälle am besten geeignet. Das Grundproblem, dass beim Java Adventure Builder gelöst werden muss, ist der Nachrichtenaustausch zwischen den einzelnen Teilmodulen des Order Processing Centers, den externen Partnern und der Webseite. Die Nachrichten werden hierbei mit Hilfe von Dokumenten ausgetauscht die von verschiedenen Typen sein können. Um die Stabilität, Interoperabilität und auch die Flexibilität, die an die Applikation gestellt werden, zu gewährleisten, müssen Designentscheidungen getroffen werden, die diesen Nachrichtenaustausch unterstützen. 4.1 Interner und externer Nachrichtenaustausch Um dem hohen Maß an Interoperabilität und Flexibilität gerecht zu werden, werden für den Nachrichtenaustausch zwischen dem OPC und den externen Partnern Web Services verwendet. Durch die Verwendung von Web Services sind die externen Partner und Anbieter unabhängig von der Wahl ihrer eigenen Software, um Anfragen die durch den Adventure Builder gestellt werden, zu bearbeiten. Web Services bieten somit eine gute Schnittstelle für die Aufteilung und Entkopplung von Softwaresystemen. Die Webseite ist Teil des Java Adventure Builders. Die Kommunikation der Webseite mit dem OPC wird ebenfalls durch einen Web Service realisiert, um eine Entkopplung der Komponenten zu erreichen, da die Webseite auf verschiedenen Hard- und Softwareplattformen gehosted werden kann. Innerhalb des Java Adventure Builders wird für die Kommunikation zwischen den Teilmodulen JMS (Java Message Service) benutzt. JMS ist ein Application Programming Interface (API), das für den Austausch von Nachrichten zwischen mehreren Java-Clients von SUN Microsystems entwickelt wurde. Der Service unterstützt dabei das Versenden von Nachrichtenschlangen und ein Anmelde-Versendesystem. Der Grund für diese Wahl ist zum einen, dass die Umgebung auf Grundlage der J2EE- Platform entwickelt wurde, die JMS bereits als Teilkomponente beinhaltet. Außerdem wird die Umgebung durch das OPC umgesetzt, das die einzelnen Teilmodule beinhaltet und Parallele und verteilte Systeme 8

11 4. Architektur und Design des Kernmoduls Service Oriented Architectures koordiniert. Die Kommunikation innerhalb ist also gekoppelt. Noch dazu ist JMS in der Lage, asynchrone Nachrichten zu verwalten. 4.2 Datenformat des Nachrichtenaustauschs Der nächste Schritt, der eine wichtige Rolle für den Nachrichtenaustausch spielt, sind die Formate über die die Interaktionen und der Nachrichtenaustausch stattfinden. Nachrichten werden extern mittels eines Web Services und intern mittels JMS über XML-Dokumente (Extensible Markup Language) verschickt. Der Java Adventure Builder ist durch die Verwendung von XML ein dokument-orientiertes System. Die Extensible Markup Language ist ein Standard zur Erstellung von maschinen- und menschenlesbaren Dokumenten in Form einer Baumstruktur. Sie definiert hierbei die Regeln für den Aufbau der Dokumente. Der Grundgedanke ist dabei, die Daten und ihre Repräsentation zu trennen. Die Strukturelemente lassen sich frei wählen und ein Element kann unterschiedliche Daten beinhalten. XML ist ein Standard zur Definition von beliebigen, in ihrer Grundstruktur jedoch stark verwandter Auszeichnungssprachen. Dies ermöglicht eine Unabhängigkeit und Entkopplung der Teilmodule, da der Austausch nicht über Java Objekte stattfindet. XML bietet eine flexible Datenstruktur der Informationen, die abhängig von der Kommunikation mit den externen Diensten ist. Aus einem XML-Dokument können auch nur relevante Information extrahiert werden, die für einen Teilprozess der Bearbeitung notwendig sind. XML unterstreicht somit die Verwendung des Workflow-Manager Moduls, das sich um die Koordination der Teilmodule kümmert. 4.3 Kommunikationsarchitektur Hinsichtlich der Designentscheidungen und Wahl der Technologien ergibt sich die Kommunikationsarchitektur. Das OPC ist für die vollständige Bearbeitung eines Buchungsauftrages verantwortlich. Es benutzt einen Workflow Manager, der die Teilnehmer an dem Prozess der Bearbeitung koordiniert und den Status der Bearbeitung verfolgt. Jedes Teilmodul empfängt ein XML-Dokument, bearbeitet dieses gemäß seiner Aufgabe und sendet das Ergebnis an den Workflow Manager zurück, der den nächsten Schritt in der Bearbeitung ermittelt und diesbezüglich erneut eine passenden Anfrage in Form eines XML-Dokuments an einen Teilnehmer absendet. Die Teilmodule haben keine Kenntnis über den gesamten Ablauf des Bearbeitungsprozesses. Die Kommunikation Parallele und verteilte Systeme 9

12 4. Architektur und Design des Kernmoduls Service Oriented Architectures findet intern mittels JMS statt. Für die externe Kommunikation mit den Partnern steht ein zentralisierter Endpunkt zur Verfügung, in dem die einzelnen Web Services integriert sind, mit Ausnahme des Finance-Moduls, für das ein eigener Web Service entwickelt wurde. Abbildung 4: Kommunikationsarchitektur In diesem Kapitel wurde genauer auf die Architektur und das Design der Teilmodule eingegangen. Der Java Adventure Builder wird auf Grundlage der J2EE-Platform entwickelt, wodurch sich verschieden Möglichkeiten ergeben, die Kommunikation und die Interaktion zwischen den Teilmodulen als auch den externen Partnern durch unterschiedliche Technologien umzusetzen. Web Services bieten hinsichtlich der externen Kommunikation auf Grund ihrer Interaktion mit verschiedener Software, mittels XML basierten Nachrichten und internet-basierten Protokollen, ein hohes Maß an Interoperabilität und Flexibilität. Dies sind die Forderungen an den Java Adventure Builder. Im Gegensatz zur internen Kommunikation, in der die Teilmodule an eine Umgebung, der J2EE-Platform, gekoppelt sind und diese bereits eine bewährte Technologie, JMS, mitbringt. Parallele und verteilte Systeme 10

13 5. Designprobleme der Schnittstellen Service Oriented Architectures 5. Designprobleme der Schnittstellen eines Web Services Dieses Kapitel betrachtet die Schnittstellen der Web Services zu den externen Partnern und Anbietern, bei denen unterschiedliche Aspekte berücksichtigt werden müssen. Folgende Web Services werden unterschieden: Web Service zwischen dem OPC und der Webseite Order-tracking Web Service zur Abfrage von Statusinformationen des Buchungsauftrags Web Services zwischen dem OPC und den externen Partnern und Anbietern Um einen Web Service zu implementieren muss man die Entscheidung treffen, welche Vorgehensweise man zur Entwicklung des Interfaces wählt. Betrachtet man das Interface zwischen dem OPC und der Webseite, und geht davon aus, dass sie beide von einer Organisation entwickelt und kontrolliert werden, entscheidet man sich für die Web Service Description Language, da sie einen programmiersprachenunabhängigen XML-Standard zur Beschreibung von Schnittstellen bietet. WSDL wird auch für die Schnittstellen zu den externen Partnern und Anbietern verwendet. Folgend muss man sich Gedanken machen, ob die Schnittstelle vorwiegend in einer Webarchitektur oder EJB-Architektur eingesetzt wird. Enterprise Java Beans sind standardisierte Komponenten innerhalb des J2EE-Servers, die die Entwicklung von verteilten und mehrschichtigen Systemen in Java erleichtert. EJB`s beschreiben den Mechanismus, die Schnittstelle eines Webservices auf eine EJB Schnittstelle abzubilden. Enterprise Beans gibt es in mehreren unterschiedlichen Ausprägungen für verschiedene Klassen von Anwendungsfällen. Bei der Webarchitektur verwendet man vorwiegend JAX-RPC, das ein Application Programming Interface bereitstellt, um den Nachrichtenaustausch zwischen Web Services bzw. Applikationen zu vereinfachen. Der Java Adventure Builder kommuniziert vorwiegend über XML-Dokumente mit den externen Partnern, hier wird JAX-RPC verwendet. Der Web Service sollte abhängig von den Dokumenten das es bearbeitet entwickelt werden. Für die Schnittstelle zwischen dem OPC und der Webseite werden Objektparameter verwendet, abgebildet durch JAX-RPC Werte, die die Komplexität und das Manipulieren von XML-Dokumenten verhindern. Die Interfaces zwischen dem OPC und den externen Partnern und Anbietern müssen die XML-Dokumente, die ausgetauscht werden, validieren und ggf. in interne Datenmodelle transformieren. Das Order-Tracking Parallele und verteilte Systeme 11

14 5. Designprobleme der Schnittstellen Service Oriented Architectures Interface arbeitet dabei synchron, während die übrigen Interfaces asynchron arbeiten, da die Bearbeitung zeitabhängig ist. Diese Schnittstellen nutzen JMS-Nachrichten. Wir haben jetzt einen kurzen Überblick über die Aspekte bekommen, die für das Schnittstellendesign des Java Adventure Builders wichtig sind. Parallele und verteilte Systeme 12

15 6. Zusammenfassung Service Oriented Architectures 6. Zusammenfassung In der abschließenden Zusammenfassung wird analysiert, inwieweit der Java Adventure Builder die Forderungen an eine Web-Service gestützte e-commerce Lösung für Onlinebuchungen von Abenteuerreisen auf J2EE Basis erfüllt. Des Weiteren wird diskutiert, ob das Buch Designing Web Services with the J2EE 1.4 Platform Entwicklern einen Einstieg zur Entwicklung solcher Systeme bietet. Hierbei werden Schlagwörter wie Service-Oriented Architecture und Web Services berücksichtigt, und auf die zur Verfügung stehenden Informationsquellen Bezug genommen. Betrachtet man die Definition des W3C eines Web Services und die Tatsache, dass eine Kombination mit und eine Kommunikation über mehrere Web Services möglich ist, die über XML-Dokumente realisiert ist, dann machen diese Merkmale den Adventure Builder zu einer Service-orientierten Architektur. Auch die Interoperabilität, Flexibilität und Portabilität der einzelnen Services ist gewährleistet, da die J2EE-Plattform verschiedene Technologien (z.b. EJB, JAX-RPC) zur Verfügung stellt. Hiermit ist auch gleichzeitig der Begriff Service-Oriented Architectures abgedeckt, der Technologien für vernetzte Computersysteme hinsichtlich automatischer Abwicklung von Geschäftsprozessen über Unternehmensgrenzen hinweg beinhaltet. Die grundlegenden Mechanismen wie Web- Services, SOAP und XML stellen eine universelle Verteilungsplattform bereit. Das Buch Designing Web Services with the J2EE 1.4 Platform bietet einen guten Einstieg für die Entwicklung von Web Services, es beschreibt wichtige verwendete Technologien. Nur Kapitel zum Java Adventure Builder ist ein wenig zu oberflächig ausgefallen. Allerdings beschreibt es das Grundkonzept der Kommunikation die man beachten muss, um eine Service-orientierte Architektur mit Web Services zu entwickeln, aus der sich ein grundlegender Aufbau ergibt. Um die Entwicklung verstehen zu können, werden vor allem Grundlagen zu der J2EE-Platform vorausgesetzt. Hierzu bieten verschiedene Internetquellen eine gute Möglichkeit sich dieses Wissen anzueignen, allerdings sucht man nach Newsgroups zum Java Adventure Builder vergebens. Die detailreichsten Informationen findet man auf der Java BluePrints Webseite, auf der dem Leser die Gründe für die Entwicklung des Java Adventure Builders nahe gelegt werden. Parallele und verteilte Systeme 13

16 7. Literatur Service Oriented Architectures 7. Literatur 7.1 Bücher [1] Singh, I. et al. (2004): Designing Web Services with the J2EE 1.4 Platform. 1. Aufl., Verlag Addison Wesley. San Francisco. 7.2 Internet [2] Java BluePrints: [3] Web-Service-Definition: Parallele und verteilte Systeme 14