Parametrisierung von EAI Patterns

Größe: px
Ab Seite anzeigen:

Download "Parametrisierung von EAI Patterns"

Transkript

1 Institut für Architektur von Anwendungssystemen Arbeitsbereich Messaging und Enterprise Application Integration Universität Stuttgart Universitätsstraße 38 D Stuttgart Diplomarbeit Nr Parametrisierung von EAI Patterns Bettina Druckenmüller Studiengang: Softwaretechnik Prüfer: Betreuer: Prof. Dr. Frank Leymann Dipl.-Inf. Thorsten Scheibler begonnen am: 07. August 2006 beendet am: 06. Februar 2007 CR-Klassifikation: D.2.11, D.3, H.4.1

2

3 Inhaltsverzeichnis 1 Einführung Einleitung Aufgabenstellung Ablauf der Arbeit Verwendete Technologien Ergebnisse Inhalte der CD Grundlagen Enterprise Application Integration (EAI) Messaging Pattern Coding Pattern Design Pattern Architectural Pattern Workflow Pattern Service Interaction Pattern Enterprise Integration Pattern Web Services und die Service-Orientierte Architektur Business Process Execution Language for Web Services

4 4 INHALTSVERZEICHNIS 3 Parametrisierung der EAI Patterns Die Notation Die Patterns Message Patterns Messaging Endpoints Idempotent Receiver Transactional Client Durable Subscriber Competing Consumers Message Dispatcher Selective Consumer Messaging Channels Datatype Channel Publish-Subscribe Channel Invalid Message Channel Dead Letter Channel Guaranteed Delivery Message Expiration Message Routing Content-Based Router Message Filter Dynamic Router Recipient List Splitter Aggregator Resequencer Message Transformation Message Translator Content Filter

5 INHALTSVERZEICHNIS Content Enricher Claim Check Patterns zur Unterstützung der Modellierung External Service Dependency Channel Kombination der Patterns Patternarten kombinieren Message Endpoint/Message Endpoint Message Endpoint/Filter Message Channel/Message Channel Message Endpoint/Message Channel Message Channel/Filter Filter/Filter Zusammengesetzte Patterns Composed Message Processor Scatter Gather Das System EAI to BPEL Die Anforderungen Bedienung des Systems Die Benutzeroberfläche Ein neues Projekt erstellen Eine EAI-Datei erstellen Ein Message System erstellen Die Patterns verwenden Correlation Aggregator Content-Based Router Content Enricher

6 6 INHALTSVERZEICHNIS Datatype Channel External Service Guaranteed Delivery Message Translator Recipient List Selective Consumer Die BPEL-Generierung Sonstige Funktionen Problems -Tab Drucken Zoom Die Implementierung Eclipse Der Kern der Eclipse-Plattform Die Plugins Verwendete Plugins Eclipse Modelling Framework - EMF Graphical Editing Framework - GEF Das Modell von EAI to BPEL MessageSystem Pipe Filter ExternalService Transformation Routing 1 to Routing 1 to many Aggregator Das BPEL Framework Vorgenommene Änderungen

7 INHALTSVERZEICHNIS Die Patterns Selective Consumer External Service Content Enricher Message Translator Aggregator Content-Based Router Recipient List Datatype Channel Guaranteed Delivery Überprüfung des Systems beim Speichern Die BPEL-Generierung Der BPELWriter Der WSDLWriter Ratgeber zur Erweiterung des Systems Ausblick Zusammenfassung 121 Literaturverzeichnis 122 A Anhang 125 A.1 Beispiel eines Message Systems A.1.1 Das Message System A.1.2 Die WSDL-Datei A.1.3 Die BPEL-Datei

8 1 Einführung 1.1 Einleitung Bei der Enterprise Application Integration (EAI) handelt es sich um die Integration großer Anwendungssysteme (Enterprise Applications). Diese wird in den meisten Fällen nachrichtenbasiert durchgeführt. Ein Integrationsnetz zwischen mehreren Anwendungssystemen lässt sich durch Kombination verschiedener EAI Patterns erstellen. Dabei wechseln sich die nachrichtenverarbeitenden Teile (Filter) und die Kanäle zwischen den Filtern (Pipes) ab und bilden somit einen Graphen. Um die EAI Patterns einsetzen zu können, müssen sie auf den speziellen Fall angepasst werden. Es stellt sich also die Frage, welche Parameter für die unterschiedlichen Patterns benötigt werden, so dass sie einsetzbar sind. Die Geschäftsprozesse innerhalb eines Unternehmens bzw. zwischen mehreren Unternehmen lassen sich als Workflows modellieren. Arbeiten die beteiligten Unternehmen mit Web Services, so bietet es sich an, für die Modellierung des Workflows die Sprache BPEL (Business Process Execution Language) zu verwenden. Diese ermöglicht es, Web Services in einem Prozess zu verknüpfen und die eingehenden bzw. ausgehenden Nachrichten weiter zu verarbeiten. Nach außen wirkt ein BPEL-Prozess wie ein selbstständiger Web Service, der wiederrum in einen anderen BPEL-Prozess eingebunden oder von einem anderen System aufgerufen werden kann. Benutzt man Workflows, um große Anwendungssysteme zu integrieren (EAI), so bietet es sich an, die Workflows mit Hilfe der EAI Patterns zu modellieren. Eine Modellierung mit EAI Patterns ist für den Entwickler zugänglicher, als direkt mit BPEL zu arbeiten. In diesem Fall müssen allerdings die EAI Patterns auf BPEL gemappt werden, so dass man das entworfene Message System aus EAI Patterns in BPEL umsetzen kann. Die vorliegende Arbeit beschäftigt sich deshalb nicht nur mit der abstrakten Parametrisierung von EAI Patterns, sondern auch mit der Umsetzung der Patterns in BPEL. In einem praktischen Teil wird ein graphisches System entwickelt, mit dem der Entwickler ein Message System bestehend aus EAI Patterns erstellen kann, und aus dem automatisch der dazugehörige BPEL Code generiert wird. Die Diplomarbeit gliedert sich in fünf Teile. Der erste Teil beschreibt dabei Randdaten der Diplomarbeit. Dazu gehört der generelle Ablauf der Diplomarbeit, die bei der Entwicklung verwendeten Technologien, und die Ergebnisse der Arbeit. Im darauf folgenden Kapitel wird jeweils eine kurze Einführung in die Grundlagen der Arbeit (EAI, Messaging, Patterns, Web Services/SOA und BPEL) gegeben. Danach folgt der theoretische Teil der Arbeit, der sich 8

9 1.2. AUFGABENSTELLUNG 9 mit der Parametrisierung der EAI Patterns sowohl auf abstrakter Ebene als auch mit dem Hintergrund von BPEL und Web Services beschäftigt. Der vierte Teil der Arbeit beschreibt die Ergebnisse der praktischen Aufgabe der Diplomarbeit. Nach der Beschreibung der Anforderungen an das zu entwickelnde System erfolgt für alle Benutzer ein kleines Handbuch, das den Umgang mit dem System beschreiben soll. Als Hilfe für Entwickler, die mit dem System weiterarbeiten möchten, wird zuerst die Grundlage (Eclipse und die verwendeten Plugins) beschrieben. Danach wird das verwendete Modell erklärt. Da das System außerdem ein Framework aus einer vorherigen Diplomarbeit (siehe [1]) verwendet, wird dieses beschrieben und erklärt, in wie weit das Framework verwendet wird und was verändert werden musste, damit es mit dem aktuellen System kompatibel ist. Danach wird die Umsetzung der einzelnen Patterns und die Generierung des BPEL-Codes beschrieben. Der Teil endet mit einem Ausblick, der Anregung für die Weiterentwicklung und Verbesserung des Systems gibt. Die Arbeit selbst endet mit einem Beispiel Message System, das mit der Anwendung erstellt wurde, und der dazugehörigen BPEL- und WSDL-Datei. 1.2 Aufgabenstellung Die Geschäftsprozesse eines Unternehmens erstrecken sich oft über mehrere Systeme. Um einen möglichst reibungslosen und konfliktfreien Ablauf eines Geschäftsprozesses zu gewährleisten, bietet es sich an, diese Systeme über EAI (Enterprise Application Integration) zu integrieren. EAI Patterns wirken beim Aufbau eines Integrationsnetzes unterstützend, indem sie Tipps und Ratschläge geben. Die Geschäftsprozesse eines Unternehmens können als so genannte Workflows betrachtet werden. Ein Workflow definiert die Art und Weise, wann und wie verschiedene Dienste bzw. Systeme miteinander interagieren. Dafür kann man die workflow-basierte Sprache BPEL verwenden. Bildet man die oben erwähnten EAI Patterns auf BPEL ab, so lässt sich dadurch das zwischen den einzelnen Systemen gespannte Messagingsystem nutzen, um Geschäftsprozesse umzusetzen. Der Vorteil gegenüber einer Erstellung eines BPEL-Prozesses ohne Nutzung von EAI Patterns liegt darin, dass man gebräuchliche Strukturen wie Router, Splitter oder Aggregatoren wieder verwenden und deshalb nicht immer wieder aufs Neue modellieren muss. Dieser Ansatz wurde in einer Diplomarbeit von Florian Schebelle (siehe [1]) umgesetzt. Dieser entwarf ein Java Framework, mit dessen Hilfe man einzelne EAI Patterns in BPEL-Code abbilden kann. Aufbauend auf der Arbeit von Florian Schebelle soll in der aktuellen Diplomarbeit ein Eclipsebasiertes Werkzeug entwickelt werden, mit dem ein Workflow aus den verschiedenen Patterns graphisch zusammengestellt werden kann. Ziel ist es, das Framework von Florian Schebelle so weit möglich in das Werkzeug einzubinden. Mit dem Werkzeug soll dabei nicht nur der entsprechende BPEL-Code erzeugt werden, sondern auch die dazugehörige WSDL-Datei. Für die Erstellung eines solchen Werkzeuges ist es nötig, einige ausgewählte Patterns aus der Arbeit von Florian Schebelle genauer zu untersuchen. Schwerpunkt bei der Untersuchung wird es sein, die eingehenden und ausgehenden Parameter der Patterns zu bestimmen. Über diese Parameter lässt sich unter anderem dann bestimmen, welche Kombination von Patterns möglich ist. Unzulässige Kombinationen sollen von dem zu erstellenden Werkzeug nicht unterstützt werden. Außerdem muss bestimmt werden, wie die gewählten Patterns vom

10 10 KAPITEL 1. EINFÜHRUNG Benutzer durch Einstellungen und Parameter angepasst werden müssen. So muss bei einer eingehenden bzw. ausgehenden Nachricht der Typ festgelegt werden, und bei einem Router muss unter anderem bestimmt werden, wie viele Ausgänge dieser besitzt und anhand welcher Kriterien geroutet wird. Das zu erstellende Werkzeug soll also dem Benutzer die Möglichkeit geben, Geschäftsprozesse mit Hilfe von BPEL, EAI Patterns und Web Services zu erstellen. Diese kann der Benutzer über eine graphische Oberfläche intuitiv zusammenstellen. Das Werkzeug unterstützt ihn dabei, indem es unter anderem die benötigten Eingaben anfordert und fehlerhafte Kombinationen verbietet. 1.3 Ablauf der Arbeit Die Anfangszeit der Diplomarbeit bestand aus einer Einarbeitungsphase. In dieser Phase wurden die grundlegenden Technologien (EAI, Messaging, SOA, BPEL, etc.) genauer betrachtet und beschrieben. Außerdem konnte ich mich in das BPEL-Framework und Eclipse einarbeiten. Die Zeit wurde auch genutzt, um eine kurze Recherche über ähnliche Projekte und eine Anforderungsanalyse durchzuführen. Die Ergebnisse der Einarbeitungsphase sind in Kapitel 2 zu finden. Die erste Hälfte der Diplomarbeit bestand neben der Einarbeitungsphase aus einer theoretischen Untersuchung der EAI Patterns. Schwerpunkt hierbei war die Parametrisierung der einzelnen EAI Patterns. Diese Parametrisierung wurde zuerst auf abstrakter Ebene durchgeführt. Danach wurden für jedes Pattern Überlegungen für eine mögliche Umsetzung in BPEL durchgeführt. Nach der Behandlung der einzelnen Patterns wurde untersucht, wie und wann diese Patterns miteinander kombiniert werden können. In diesem Zusammenhang wurden zwei Patterns beschrieben, die sich aus einzelnen Patterns zusammensetzen. Die Ergebnisse des theoretischen Teils können in Kapitel 3 nachgelesen werden. Die zweite Hälfte der Diplomarbeit wurde auf den praktischen Teil der Arbeit verwendet. Hierbei wurde ein Eclipse-basiertes System zur Abbildung von EAI-Patterns auf BPEL erstellt. Dazu gehört der Entwurf, die Erstellung der Benutzeroberfläche und die Implementierung der BPEL-Generierung. Die Ergebnisse dieses Teils befinden sich auf der beiliegenden CD und in Kapitel Verwendete Technologien Für den praktischen Teil der Arbeit wurden die nachfolgenden Technologien verwendet: Java JDK 5.0 WS-BPEL 2.0 Eclipse Eclipse Visual Editor 1.2 (für die Erstellung der Dialoge) - [25]

11 1.5. ERGEBNISSE 11 Eclipse UML Free Edition 2.1 von Omondo (für den Entwurf) Eclipse GEF 3.2 (für die Erstellung des graphischen Editors) Eclipse EMF 2.2 (für die Modellerstellung) 1.5 Ergebnisse Die Ergebnisse der Arbeit bestehen aus einem theoretischen Teil und einem praktischen Teil. Der theoretische Teil der Arbeit findet sich in dieser Ausarbeitung unter Kapitel 3 wieder. Der praktische Teil der Arbeit besteht aus einem System, mit dem man mit Hilfe von EAI Patterns einen BPEL Prozess erstellen kann. Die Bedienung und Architektur des Systems wird in Kapitel 4 beschrieben. Den Sourcecode sowie weitere Dokumentation befinden sich auf der beiliegenden CD Inhalte der CD Auf der CD ist die PDF-Version dieser Arbeit enthalten. In einem extra Ordner befinden sich die Testdaten, mit denen der funktionale Test der BPEL- Generierung durchgeführt wurde. In einem Word-Dokument sind die vier Testfälle dokumentiert. Die EAI-Dateien der Message Systeme befinden sich im Unterordner official test. Im Unterordner results befinden sich die generierten BPEL- und WSDL-Dateien. Im Ordner Eclipse befindet sich die Zip-Datei der verwendeten Eclipse-Version. Außerdem befinden sich hier die verwendeten Plugins ebenfalls als Zip-Dateien. Schließlich befindet sich auf der CD noch das EAItoBPEL-Eclipse-Projekt aus dem Workspace von Eclipse. Hier findet man die Bin- und Src-Dateien, die plugin.xml, das Klassendiagramm model.ecd (das in einer Eclipse-Version mit den installieren Plugins betrachtet werden kann), die Icons und Bilder des Systems, und die generierten JavaDocs.

12 2 Grundlagen Im folgenden Kapitel sollen kurz die Technologien und Begriffe erläutert werden, die für die aktuelle Arbeit relevant sind. Dazu gehören die Enterprise Application Integration, das Messaging, die Patternarten, Web Services und Service-Orientierte Architektur und die Business Process Execution Language for Web Services. 2.1 Enterprise Application Integration (EAI) Bei einer Enterprise Application handelt es sich um ein System, das persistente Daten benötigt, mit einer großen Menge an Daten (100 GB ist dabei noch harmlos) arbeitet, Hunderte von Zugriffen auf die Daten gleichzeitig hat, viele verschiedene Endbenutzerschnittstellen bietet und Daten mit anderen Enterprise Applications austauschen muss. [3] Unternehmen besitzen dabei Hunderte dieser Systeme. Diese sind entweder speziell für sie entwickelt worden, von einem externen Softwareunternehmen gekauft worden, Teil eines Legacy Systems, oder gar eine Kombination von allem. Sie arbeiten in mehreren Schichten und auf unterschiedlichen Betriebssystemen. [2] Die Benutzer solcher Systeme denken für gewöhnlich nicht in Systemgrenzen, wenn sie mit einem Unternehmen interagieren. Sie führen einen Geschäftsprozess aus und kümmern sich nicht darum, wie viele interne Systeme dieser Geschäftsprozess benötigt. Um diese Geschäftsprozesse zu ermöglichen und dem Benutzer den Eindruck einer einzigen großen Anwendung zu geben, müssen die unterschiedlichen Systeme integriert werden. Dies ermöglicht den Anwendungen, Daten effizient, zuverlässig und sicher untereinander auszutauschen. [2] Anwendungsintegration ist nicht mit einer verteilten Anwendung gleichzusetzen. Bei der Anwendungsintegration bleiben die einzelnen Systeme unabhängig von einander. Jedes System kann alleine betrieben werden. Sie werden aber durch die Anwendungsintegration über eine lose Kopplung koordiniert. Somit kann sich jede Anwendung auf eine umfassende Funktionsmenge konzentrieren und Arbeit an andere Systeme weiterleiten, die ähnliche Funktionen erfüllen. Dabei kommunizieren die Systeme asynchron, d.h. dass die Systeme nicht auf eine Antwort warten müssen. Stattdessen können die Systeme weiterarbeiten, bis sie eine Antwort erhalten. [2] Integration bedeutet im weitesten Sinne die Verbindung zwischen Computersystemen, Firmen oder Menschen. Dabei gibt es sechs Typen von Integration, die am häufigsten vorkommen ([2]): 12

13 2.2. MESSAGING 13 Informationsportale Datenreplikation Geteilte Geschäftsfunktionen Service-Orientierte Architekturen Verteilte Geschäftsprozesse Business-to-Business Integration Anwendungsintegration lässt sich auf verschiedene Arten durchführen. Beim Dateitransfer schreibt ein System seine Daten in eine Datei. Diese Datei kann später von einer anderen Datei gelesen werden. Dabei müssen sich die Systeme auf einen Dateinamen und einen Speicherort, auf das Dateiformat und auf einen Schreib- und Lesezyklus einigen. Es gibt auch die Möglichkeit, dass sich mehrere Systeme eine Datenbank teilen. Allerdings müssen alle Systeme sich dann auf ein Datenbankschema einigen. Bei der Remote Procedure Invocation stellt jedes System seine Funktionalität als Schnittstelle dar, auf die andere Systeme synchron zugreifen können. Diese Methode bricht die oben erwähnte lose Kopplung. Eine sehr variable Lösung ist die des Messagings. Dabei schickt ein System eine Nachricht an einen Channel. Von diesem Channel können andere Systeme später die Nachricht lesen. Dabei müssen sich die beteiligten Systeme auf einen Channel und auf das Format der Nachricht einigen.[2] 2.2 Messaging Bei Messaging handelt es sich um eine Technologie, die asynchrone, zuverlässige Hochgeschwindigkeitskommunikation zwischen Systemen ermöglicht. Dabei senden die Programme Datenpakete, so genannte Messages. Diese Messages werden über Kanäle (Channels) geschickt. Channels sind logische Wege zwischen den Programmen. Hier werden die Messages in einer Art Array gespeichert. Auf dieses Array können mehrere Systeme gleichzeitig zugreifen. Ein Sender ist ein Programm, das Messages verschickt, indem es die Messages auf den Channel schreibt. Ein Receiver oder Empfänger ist ebenfalls ein Programm, das eine Message bekommt, in dem es die Nachricht von einem Channel liest und danach löscht.[2] Die Nachricht (Message) besteht aus einer einfachen Datenstruktur. Die darin enthaltenen Daten können sowohl als einfache Daten, als auch als Beschreibung einer beim Receiver aufzurufenden Funktion, oder als Beschreibung eines beim Sender aufgetretenen Ereignisses interpretiert werden. Eine Nachricht setzt sich aus zwei Teilen zusammen: dem Header und dem Body. Der Header beinhaltet lediglich Metainformationen über die Nachricht. So steht dort zum Beispiel der Sender und der Receiver der Nachricht. Die Informationen im Header werden vom Messagingsystem verwendet und in den meisten Fällen von den eigentlichen Anwendungen ignoriert. Der Body einer Nachricht beinhaltet die Anwendungsdaten, die übermittelt werden sollen. Diese werden für gewöhnlich vom Messagingsystem ignoriert.[2] Beim Messaging werden zwei fundamentale Konzepte angewendet:

14 14 KAPITEL 2. GRUNDLAGEN 1. Send and Forget 2. Store and Forward Möchte ein System eine Nachricht verschicken, so übergibt es diese dem Messagingsystem und damit dem Channel. Sobald das Messagingsystem den Erhalt der Nachricht bestätigt, kann sich der Sender einer anderen Aufgabe widmen. Er kann quasi vergessen, dass er diese Nachricht geschickt hat und muss sich nicht weiter darum kümmern (Send and Forget). Er kann davon ausgehen, dass der Receiver die Nachricht bekommt. Die Nachricht wird im Hintergrund vom Messagingsystem weitergeleitet. Erwartet der Sender eine Antwort, so muss er lediglich ein so genanntes Callback erstellen, das beim Eintreffen einer Antwort aktiviert wird. Das Prinzip von Store and Forward wird vom Messagingsystem umgesetzt. Sobald dieses eine Nachricht vom Sender erhält, speichert es diese auf dem Computer des Senders und schickt diesem daraufhin eine Bestätigung. Danach leitet das Messagingsystem die Nachricht an den Computer des Receivers weiter. Auch hier wird die Nachricht wieder gespeichert. Erst wenn die Nachricht sicher auf dem Computer des Receivers gespeichert ist, kann sie auf der Seite des Senders gelöscht werden. Diese Prozedur wird so oft wiederholt, wie die Nachricht von einem Computer zu einem anderen geschickt wird. Die Nachricht kann dabei auch erst über andere Computer geleitet werden, bis sie schließlich beim Receiver ankommt.[2] Messaging basiert außerdem auf dem Prinzip der losen Kopplung. Hierbei sollen die Annahmen, die zwei Parteien (Komponenten, Anwendungen, Services, Benutzer) voneinander machen, wenn sie Informationen austauschen, verringert werden. Umso mehr Annahmen gemacht werden, umso effizienter ist zwar die Kommunikation, aber umso weniger tolerant verhält sich die Lösung gegenüber Unterbrechungen oder Änderungen. Dies liegt daran, dass die zwei Parteien fest aneinander gekoppelt sind.[2] Bei der losen Kopplung müssen die beiden Parteien nur wenig über einander wissen. Diese Kommunikation ist zwar weniger effizient, doch dafür sehr robust. Bereits bestehende Anwendungen lassen sich einfacher integrieren, wenn dies mit loser Kopplung geschieht. Die Arbeit mit Messaging beinhaltet allerdings auch einige Herausforderungen: So bedingt asynchrone Kommunikation zum Beispiel ein komplexes Programmiermodell, Messagingsysteme garantieren nicht die Einhaltung der Reihenfolge, in der Nachrichten geschickt werden, synchrone Szenarien wie Frage-Antwort lassen sich über asynchrone Kommunikation schwerer realisieren, die Performance sinkt, da Daten erst in Nachrichten gewandelt, dann verschickt, und dann wieder in Daten zurückgewandelt werden müssen, u.s.w. Um die Arbeit mit Messaging zu erleichtern, wurden Methoden und Vorgehensweisen, die sich in verschiedenen Projekten bereits bewährt haben, als Patterns festgehalten. Diese sollen bei zukünftigen Projekten helfen, einige der Schwierigkeiten aufzulösen.[2] 2.3 Pattern Ein Pattern stellt eine zu treffende Entscheidung und die dazugehörigen Überlegungen dar. Eine Patternsprache ist ein Netz bestehend aus vielen Patterns. Dabei verweist ein Pattern

15 2.3. PATTERN 15 auf weitere Patterns, was den Entscheidungsprozess unterstützt. Die Patternsprache erläutert, wie man eine Vielfalt von Problemen innerhalb eines begrenzten Problemgebietes lösen kann. Da aber das eigentliche Problem jedes Mal anders ist, ist auch der gewählte Pfad durch die Patterns und die Art, wie die Patterns angewandt werden, jedes Mal einzigartig. Eine Patternsprache ist eine sehr gute Möglichkeit, Expertenwissen so festzuhalten, dass es für andere leicht verständlich und anwendbar ist.[2] Damit ein Pattern wirklich hilfreich ist, muss das Pattern dokumentieren, warum das Problem schwierig ist. Es muss außerdem mögliche Lösungen, die allerdings nicht funktionieren, berücksichtigen. Ein Pattern muss auch erklären, warum der beschriebene Lösungsweg der zur Zeit bestmögliche ist. Außerdem muss ein Pattern auf andere Patterns verweisen. Damit wird die Möglichkeit gegeben, Lösungen für aufkommende Probleme zu finden, mit denen Anfangs nicht gerechnet wurde.[2] Im Software-Bereich gibt es verschiedene Typen von Patterns: Coding Pattern Design Pattern Architectural Pattern Workflow Pattern Service Interaction Pattern Enterprise Integration Pattern Coding Pattern Coding Patterns werden auch Idioms genannt und sind Patterns, die auf unterster Ebene arbeiten. Sie beziehen sich auf eine spezifische Programmiersprache und beschreiben, wie man spezielle Aspekte von Komponenten oder Beziehungen zwischen Komponenten implementiert, indem man die Eigenschaften dieser Programmiersprache verwendet.[4] Design Pattern Ein Design Pattern liefert ein Schema, um ein Untersystem, eine Komponente eines Softwaresystems oder die Beziehungen untereinander zu verfeinern. Es beschreibt eine häufig vorkommende Struktur von kommunizierenden Komponenten, die ein allgemeines Entwurfsproblem innerhalb eines speziellen Kontextes löst. Die Form des Patterns ist durch Mittel des Softwareentwurfs geprägt, d.h. durch Objekte, Klassen, Vererbung, etc.[4] Eine bekannte Sammlung von Design Patterns ist die der GoF (siehe [5]), die aus Patterns für objektorientierte Programme besteht.

16 16 KAPITEL 2. GRUNDLAGEN Architectural Pattern Mit einem Architectural Pattern wird eine fundamentale, strukturelle Organisation eines Softwaresystems beschrieben. Es bietet eine Menge von vordefinierten Untersystemen, spezifiziert deren Verantwortlichkeiten und beinhaltet Regeln und Richtlinien, um die Beziehungen zwischen diesen zu organisieren.[4] Microsoft bietet online unter anderem eine Sammlung von Architectural Patterns (siehe [6]) Workflow Pattern Workflow Patterns beschäftigen sich mit Geschäftsprozessen. Die Patterns können verwendet werden, um die Leistung eines Workflow Servers zu untersuchen, oder um eine Reihe von Ideen zur Implementierung von gegebenen Geschäftsanforderungen zu bekommen, wenn man schon einen festen Workflow Server besitzt.[7] Sammlungen von Patterns befinden sich auf den Webseiten von (siehe [7]) und der Queensland University of Technology (siehe [8]) Service Interaction Pattern Für den Web Service Bereich (siehe auch Kapitel 2.4) gibt es ebenfalls bereits eine Fülle von Patterns. Sie beschäftigen sich mit den Problemen beim Entwurf und der Implementierung von Web Services. Diese gehen dabei über bilaterale Interaktionen hinaus und beschäftigen sich auch mit multilateralen, konkurrierenden und kausal verbundenen Interaktionen, wie man sie in längeren Geschäftsprozessen findet.[9] Sammlungen von Patterns befinden sich auf den Webseiten von (siehe [9]), von Massimiliano Bigatti (siehe [10]) und von (siehe [11]) Enterprise Integration Pattern Diese Art von Pattern beschäftigt sich mit der in Kapitel 2.1 beschriebenen Enterprise Application Integration. Dabei werden Ratschläge für den Entwurf und die Implementierung von Integrationen beschrieben. Als Methode der Anwendungsintegration wird bei den meisten Patterns von einem Messagingsystem ausgegangen. Am bekanntesten ist dabei das Buch von Gregor Hohpe (siehe [2]). Dieser hat die im Buch beschriebenen Patterns auch auf einer Webseite veröffentlicht (siehe [12]). Gregor Hohpe ist derzeit Softwarearchitekt bei Google. Ebenfalls sehr bekannt ist Martin Fowler, der das Buch Patterns of Enterprise Application Architecture (siehe [13]) geschrieben hat. Martin Fowler ist zur Zeit leitender Wissenschaftler bei ThoughtWorks.[14]

17 2.4. WEB SERVICES UND DIE SERVICE-ORIENTIERTE ARCHITEKTUR 17 Auch IBM (siehe [15]) und Microsoft (siehe [16]) bieten ihre Patterns online an. Und es gibt noch weitere Sammlungen sowohl online als auch als Bücher veröffentlicht. Dies liegt daran, dass das Thema EAI sich fortwährender Beliebtheit erfreut. Da sich das in dieser Diplomarbeit entwickelte Werkzeug auf das Buch von Hohpe (siehe [2]) und die darin beschriebenen Patterns bezieht, werden nachfolgend die wichtigsten Patterngruppen für eine Anwendungsintegration daraus vorgestellt: Message Patterns beschreiben die möglichen Nachrichtenarten. Eine Nachricht ist dabei ein Datenpaket, das auf einem Channel übermittelt werden kann. Um Daten zu senden, muss eine Anwendung die Daten in ein oder mehrere Pakete unterteilen, diese Pakete in eine Nachricht packen und über den Channel schicken.[2] Channel Patterns beschreiben die Arten von Nachrichtenkanälen. Ein Messagingsystem schickt Daten durch einen Channel, der virtuell den Sender und den Receiver verbindet.[2] Transformation Patterns helfen dabei, Nachrichtenformate so zu transformieren, dass der Receiver die Nachricht verstehen kann. Dies ist genau dann nötig, wenn Sender und Receiver nicht mit dem gleichen Format arbeiten. Damit weder der Sender, noch der Receiver verändert werden müssen, werden so genannten Message Translator zwischen die beiden Parteien geschaltet.[2] Routing Patterns geben Anweisungen, wie man den Weg einer Nachricht über Message Router definieren kann. Ist der Weg einer Nachricht komplex, so ist dem Sender möglicherweise nicht klar, über welche Channels die Nachricht laufen muss. In diesem Fall schickt der Sender die Nachricht an einen Router, der dann den weiteren (Teil-)Weg der Nachricht bestimmt.[2] Endpoint Patterns helfen dabei, einen passenden Endpoint für eine Anwendung, die an ein Messagingsystem angebunden werden soll, zu entwerfen. Da die meisten zu integrierenden Anwendungen nicht die Funktionalität besitzen, mit einem Messagingsystem zu interagieren, wird eine Schicht zwischen Anwendung und Messagingsystem eingefügt, die sich sowohl mit der Anwendung, als auch mit dem Messagingsystem auskennt. Diese Brücke ist eine Menge von koordinierten Endpoints, die es der Anwendung ermöglichen, Nachrichten zu verschicken und zu empfangen.[2] Systems Management Patterns geben Hilfestellung bei der Verwaltung eines Messagingsystems. Dabei gibt es drei Kategorien: Überwachen und Kontrollieren, Beobachten und Analysieren, Testen und Debuggen.[2] 2.4 Web Services und die Service-Orientierte Architektur Bei SOA handelt es sich um ein Architekturmuster, das auf der Verwendung von Services beruht. Ein Service ist eine Art Dienstleistung, die an einem bestimmten Endpoint in einem Netzwerk zur Verfügung steht und in der Lage ist, Messages zu versenden und zu empfangen. Der Service bietet eine bestimmte Funktionalität an und kann dabei auch verschiedene nichtfunktionale Anforderungen (Sicherheit, Transaktion, etc.) unterstützen. Die Schnittstellen zu Services werden in einer einheitlichen Form beschrieben und können durch verschiedene Techniken vom Benutzer gefunden und benutzt werden. In einer Service-Orientierten Architektur

18 18 KAPITEL 2. GRUNDLAGEN werden Geschäftsprozesse durch eine lose Kopplung zwischen verschiedenen Services gebildet. Unter Verwendung von WS-BPEL (siehe Kapitel 2.5) lassen sich aus bereits existierenden Services neue Services kombinieren, die nach außen wie ein einzelner Service fungieren. Dadurch kann man beliebig viele Services rekursiv zusammenstellen. Ändert sich ein Geschäftsprozess eines Unternehmens, so muss im Idealfall kein neuer Service implementiert werden, sondern lediglich die Reihenfolge und Kombination der bestehenden Services geändert werden.[17] SOA selbst ist lediglich ein abstraktes Architekturkonzept, das auf loser Kopplung (siehe Kapitel 2.2) basiert. Dieses Konzept kann auf unterschiedliche Weise umgesetzt werden. Einer der wichtigsten Ansätze ist dabei das der Web Services.[17] Ein Web Service ist ein Softwaresystem, das Interaktionen zwischen Rechnern in einem Netzwerk unterstützt. Er hat eine Schnittstelle, die in WSDL beschrieben ist und von anderen Maschinen verarbeitet werden kann. Andere Systeme arbeiten mit einem Web Service in der Art und Weise, wie sie in der Beschreibung des Web Services festgelegt ist. Dabei werden SOAP Messages verwendet, die meistens über HTTP mit XML Serialisierung in Verbindung mit anderen Standards des Webs übertragen werden.[17] 2.5 Business Process Execution Language for Web Services Ein Web Service selbst ist isoliert und opak. Um dieses Isolation zu umgehen, werden Web Services zu Geschäftsprozesse zusammengeschlossen. Ein Geschäftsprozess legt die Reihenfolge der auszuführenden Web Services fest. Außerdem bestimmt er, welche Daten zwischen den Web Services ausgetauscht werden, welche Partner involviert sind und wie diese im Geschäftsprozess mitwirken, und so weiter. Dadurch können längere Transaktionen über die Web Services hinaus geführt werden. Auch die Konsistenz und Zuverlässigkeit erhöhen sich. WS-BPEL stellt eine Sprache bereit, um diese Geschäftsprozesse zu spezifizieren.[17] Die aktuelle Version von BPEL ist BPEL 1.1, auch bekannt als BPEL4WS. Der neue Standard WS-BPEL 2.0 ist zwar noch nicht erschienen, doch werden die bereits bekannten Neuerungen sowohl in der Arbeit von Florian Schebelle (siehe [1]) als auch in der aktuellen Arbeit berücksichtigt. BPEL ist eine erweiterbare workflow-basierte Sprache, die Web Services aggregiert, in dem sie Service Interaktionen choreographiert. Diese Aggregation ist rekursiv, so dass der Prozess ebenfalls WSDL-Schnittstellen zur Verfügung stellt. Somit kann der dadurch entstandene Service in anderen Choreographien wieder verwendet werden. Der BPEL Prozess ist absichtlich von den Instanzen der Web Services abgekoppelt, damit sich die Web Services noch ändern können. Daten der Choreographie können über XPath manipuliert werden. Die Daten der Web Service Endpoints können als WS-Addressing Endpoint Referenzen ausgetauscht werden.[17] Parteien, mit denen ein BPEL Prozess interagiert (wie zum Beispiel ein Web Service), werden als Partner bezeichnet. Der BPEL Prozess benutzt für die Interaktion eine Menge von PartnerLinks. Diese sind Instanzen von typgebundenen Konnektoren, welche die Porttypen spezifizieren, die der Prozess vom Partner benötigt bzw. dem Partner bietet. Man kann sich einen PartnerLink als Punkt-zu-Punkt-Channel vorstellen.[17]

19 2.5. BUSINESS PROCESS EXECUTION LANGUAGE FOR WEB SERVICES 19 BPEL Prozesse werden durch geschachtelte scopes gebildet. Diese enthalten die Verbindungen zu externen Partnern, Deklarationen der Prozessdaten, Handler für verschiedene Zwecke und die auszuführenden Aktivitäten.[17] Die Daten werden in typgebundenen Variablen gespeichert. Die Werte der Variablen sind entweder Messages, die zwischen dem Prozess und seinen Partnern ausgetauscht werden, oder lokale Daten, die nur der Prozess kennt.[17] Da BPEL eine strenge Typ-Bindung zwischen den Web Service Operationen und den Messages vorschreibt, sind die Struktur der Nachricht und damit auch ihr Typ fest vorgegeben. Auch wenn durch ein Messaging Pattern der Nachrichtentyp für einen Channel nicht eingeschränkt ist, so ist dies in BPEL nicht umsetzbar. Es müssen also für die verschiedenen Typen Redundanzen aufgebaut werden, falls dies nicht in der Nachrichtenstruktur selbst zu lösen ist.[1] Aktivitäten, die sich auf Web Services beziehen sind receive, reply, pick, invoke und event handlers (z.b. onmessage). Über diese Aktivitäten kann ein Prozess Messages mit dem Web Service austauschen. Die assign Aktivität kopiert Daten von einem Ort zu einem anderen. Außerdem gibt es noch strukturierte Aktivitäten, die mehrere Aktivitäten miteinander kombinieren, um eine höhere Geschäftslogik zu erreichen. Dazu gehören die Aktivitäten sequence, if, while und flow. Mit der sequence Aktivität werden die darin enthaltenen Aktivitäten in der angegebenen Reihenfolge ausgeführt. Die if Aktivität bietet einen Entscheidungsbaum an. Über die while Aktivität kann eine loop-funktion ausgeführt werden. Aktivitäten können parallel ausgeführt werden, indem sie in einer flow Aktivität eingebunden werden. Darüber hinaus stehen für BPEL noch weitere Aktivitäten zur Verfügung.[17] Zwischen Aktivitäten können Übergangsbedingungen gesetzt werden. Diese werden nach Abschluss der vorhergehenden Aktivität überprüft. Die nachfolgende Aktivität wird nur dann ausgeführt, wenn die Bedingung erfüllt ist. Genauso können mehrere Aktivitäten auf eine einzelne Aktivität treffen. Dafür wird zwischen den eintreffenden Aktivitäten und der nachfolgenden Aktivität eine join-bedingung gesetzt. Nur wenn die Ergebnisse der eintreffenden Aktivitäten zusammen die join-bedingung erfüllen, wird die nachfolgende Aktivität ausgeführt. Über diese Bedingungen kann ein Prozess zuerst in mehrere parallele Prozesse aufgespaltet werden, und schließlich wieder zu einem Prozess verknüpft werden.[17] Wenn ein Prozess ausgeführt wird, so muss jeder PartnerLink an einen konkreten Endpoint gebunden werden. Dafür gibt es vier Möglichkeiten: Statisches Binding zur Entwurfszeit, statisches Binding zur Deploymentzeit, dynamisches Binding durch Lookup, dynamisches Binding durch Übergabeparameter. Wird das Binding zur Entwurfszeit durchgeführt, so werden die Endpoints in den Geschäftsprozess fest eingebunden. Das Binding zur Deploymentzeit ist nur sinnvoll, wenn alle Instanzen eines Prozesses dieselben Endpoints verwenden. Sobald man variable Endpoints benötigt, bietet sich das dynamische Binding an. Hier kann man einen Web Service entweder über Suchkriterien finden (dieser Prozess ist durch SOA vorgegeben), oder man bekommt den Endpoint als Ergebnis eines anderen Web Services, zum Beispiel über eine invoke oder receive Aktivität.[17] Ein BPEL Prozess bietet höchstens einen Porttype für jeden PartnerLink. Diese werden den Partnern zur Verfügung gestellt und können von diesen aufgerufen werden. WSDL spezifiziert, dass ein Porttype zu einem Port gehört, und somit ist es die Aufgabe des Workflowsystems, diese Ports zu generieren. BPEL gibt weder für das Deployment, noch für die Syntax des Deployment Descriptors eine Spezifikation vor.[17]

20 3 Parametrisierung der EAI Patterns In diesem Kapitel werden die Patterns, die zum Teil bereits in der Arbeit von Florian Schebelle (siehe [1]) auf BPEL gemappt wurden, parametrisiert. Für jedes Pattern wird untersucht, welche Eingaben das Pattern benötigt, welche Ausgaben das Pattern liefert, und welche sonstige Einstellungen der Benutzer vor Gebrauch des Patterns durchführen muss, damit das Pattern seine Funktion erfüllen kann. Dabei werden die einzelnen Patterns erst einmal auf abstrakter Ebene untersucht, d.h. es wird nicht berücksichtigt, dass die Patterns später auf BPEL gemappt werden sollen. Ziel hierbei ist es, die Ein-, Ausgaben und Parameter für ein Pattern unabhängig von der späteren Umsetzung des Patterns zu bestimmen. Nach der abstrakten Parametrisierung des Patterns folgt jeweils eine Überlegung für mögliche Umsetzungen in Bezug auf Web Services und BPEL. Nach der Betrachtung der einzelnen Patterns wird überlegt, wie zwei oder mehrere Patterns miteinander kombiniert werden können. Dabei muss darauf geachtet werden, dass die Eingabe des vorherigen Patterns mit der Ausgabe des nachfolgenden Patterns übereinstimmt. Außerdem muss überlegt werden, ob es Kombinationen von Patterns gibt, die trotz der Übereinstimmung von Ein- und Ausgabe nicht zulässig sind. 3.1 Die Notation Jedes Pattern wird zur besseren Anschauung graphisch dargestellt. Abbildung 3.1 zeigt eine beispielhafte Darstellung eines Patterns. Dabei wird der Pattern-Kasten durch das jeweilige Patternsymbol ersetzt, so dass auf den ersten Blick ersichtlich ist, um was für ein Pattern es sich handelt. Die Eingaben, Ausgaben und Parameter werden in der Zeichnung stichwortartig aufgeführt und im dazugehörigen Absatz genauer erläutert. Da bei der Kombination von Patterns die Ausgaben des ersten Patterns mit den Eingaben des zweiten Patterns übereinstimmen müssen, und da es sich hierbei meist um eine Nachricht, also um wiederrum ein eigenes Pattern, handelt, werden Kombinationen graphisch durch eine Aneinanderreihung der Patterngraphiken dargestellt (siehe auch Kapitel 3.3). 20

21 3.2. DIE PATTERNS Die Patterns Abbildung 3.1: Notation eines Patterns Dieses Unterkapitel gliedert die einzelnen Patterns zusätzlich nach Art des Patterns. Dabei wird unterschieden zwischen Message Patterns, Messaging Endpoints, Messaging Channels, Message Routing und Message Transformation. Gegen Ende des Kapitels werden auch noch Patterns vorgestellt, die bei Hohpe (siehe [2]) nicht auftauchen, die sich aber bei der Modellierung des Systems und bei der Arbeit mit BPEL als hilfreich erwiesen haben. Folgende Patterns werden nicht näher behandelt: Channel Adapter Messaging Bridge Message Bus Routing Slip Process Manager Message Broker Envelope Wrapper Normalizer Messaging Gateway Messaging Mapper Polling Consumer Event-Driven Consumer Service Activator System Management Pattern

22 22 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS Die Gründe für die Nichtbearbeitung der oben genannten Patterns sind vielschichtig. Zunächst einmal konzentrierte sich die Arbeit auf die von Florian Schebelle (siehe [1]) behandelten Patterns. Diese wurden vollständig behandelt. Nach der Behandlung dieser Patterns wurden noch die Patterns hinzugenommen, die sich auf den ersten Blick für eine Umsetzung in BPEL eigneten. Zwar stellte sich hinterher bei einigen der Patterns heraus, dass sie bei der Umsetzung in BPEL nicht nötig waren oder ihre Umsetzung nicht möglich war, sie wurden dann aber trotzdem der Vollständigkeit halber in der Arbeit belassen, da die abstrake Abhandlung über ihre Parameter unabhängig von BPEL ist. Aus diesem Grund hätten auch noch die restlichen Patterns behandelt werden können, allerdings ist dies dann aus zeitlichen Gründen nicht geschehen. Die Zeit wurde stattdessen in das zu implementierende System investiert Message Patterns Die Message Patterns beziehen sich jeweils auf den Aufbau einer Message. Da der Inhalt einer Nachricht allerdings für die Parametrisierung uninteressant ist (nach außen wirkt jedes Message Pattern gleich), werden die Patterns gleich behandelt. Abbildung 3.2 zeigt eine Nachricht mit ihren Ein- und Ausgaben und Parametern. Abbildung 3.2: Parametrisierung des Message Patterns Dieses Pattern besitzt keinerlei Ein- und Ausgaben. Der Grund hierfür liegt darin, dass es sich hier um kein verarbeitendes Pattern handelt. Eine Nachricht selbst ist Ein- bzw. Ausgabe anderer Patterns. Sie tritt also immer zwischen zwei Patterns auf und verknüpft diese miteinander. Wie bereits oben erwähnt unterscheiden sich die unterschiedlichen Nachrichtenpatterns nicht voneinander. Die einzige nötige Angabe bezieht sich auf den Nachrichtentyp. Dieser Typ ist unabhängig von der Art des Patterns und ist für die Arbeit mit dem Pattern sowohl des Senders, als auch des Receivers notwendig. Deshalb muss dieser Typ beim Einsatz des Patterns angegeben werden. Für weitere Informationen siehe auch Kapitel 3.3.

23 3.2. DIE PATTERNS 23 BPEL und Web Services Eine Nachricht wird in BPEL in einer Variablen gespeichert. Deswegen muss für das Pattern der Variablentyp angegeben werden. Dieser entspricht in diesem Fall dem Nachrichtentyp und stammt im Bereich Web Services aus einer WSDL Datei oder entspricht einem XSD Typen Messaging Endpoints Die nachfolgenden Patterns können zusätzlich zu jedem Filter-Pattern verwendet werden. Dazu gehören Message Router und Message Transformatoren. Fügt man eines der Endpoint- Patterns dazu, so verändert man dadurch das Verhalten des Filters. Man kann dem Filter also dadurch bestimmte Eigenschaften und Verhaltensmuster hinzufügen Idempotent Receiver Es kann vorkommen, dass eine einmalig gesendete Nachricht, doppelt beim Empfänger ankommt. Gründe dafür sind zum Beispiel die Art der Implementierung des Patterns Guaranteed Delivery (siehe Kapitel ) oder die Verwendung von unzuverlässigen Protokollen wie HTTP. In vielen Fällen entstehen durch eine doppelte Verarbeitung derselben Nachricht Fehler. Man stelle sich einen Auftrag für eine Bankabbuchung vor, die deshalb doppelt ausgeführt wird. Solche Szenarien sind in diesem Fall also zu vermeiden. Da man auf das Messagingsystem meist keinen Einfluss hat, muss die Fehlervermeidung beim Filter direkt stattfinden. Dieser muss so gestaltet sein, dass ein mehrfacher Empfang derselben Nachricht denselben Effekt hat, wie wenn die Nachricht nur einmal geschickt worden wäre. Abbildung 3.3 zeigt einen Idempotent Receiver mit seinen Ein- und Ausgaben und Parametern. Abbildung 3.3: Parametrisierung des Idempotent Receivers Das Pattern selbst besitzt keinerlei Ein- und Ausgaben. Wie oben schon erwähnt, wird das Pattern zusätzlich zu einem Filter Pattern verwendet. Die Ein- und Ausgabe liegt also beim eigentlichen Filter-Pattern.

24 24 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS Damit das Pattern funktionieren kann, müssen die in den Filter eingehenden Nachrichten einen eindeutigen Schlüssel besitzen, wie zum Beispiel eine Message ID. Über diese ID wird bestimmt, ob die Nachricht bereits schon einmal empfangen wurde oder nicht. Aus diesem Grund müssen sowohl der Nachrichtentyp als auch der Name des eindeutigen Schlüssels bei der Erstellung des Patterns angegeben werden. Zwei wichtige Entscheidungen für das Gelingen des Patterns betreffen die History. In der History werden die Schlüssel der zuletzt empfangenen Nachrichten gespeichert. Trifft eine neue Nachricht ein, so wird in der History nachgeschaut, ob derselbe Schlüssel bereits empfangen wurde. Ist dies der Fall, so wird die Nachricht gelöscht. Ansonsten wird die Nachricht verarbeitet. Da die History Speicherplatz benötigt, kann sie nur eine bestimmte Größe annehmen. Diese Größe muss vorher festgelegt werden. Setzt man allerdings die Größe als zu gering, kann es vorkommen, dass Nachrichten trotzdem doppelt verarbeitet werden, weil der Schlüssel der ersten Nachricht schon wieder aus der History verschwunden ist. Deswegen muss hier abgewogen werden. Eine weitere wichtige Entscheidung betrifft die Persistenz der History. Wird die Liste nicht persistent gemacht, so ist sie nach einem Systemabsturz verloren und der Filter erkennt nicht, dass er eine Nachricht bereits erhalten hat. BPEL und Web Services Die Umsetzung des Patterns orientiert sich hauptsächlich an dem darunter liegenden Filter-Pattern. Gewisse Eigenschaften des Patterns können aber die Umsetzungsmöglichkeiten einschränken. Da für jede neue Nachricht eine Instanz des BPEL-Prozesses erstellt wird, muss sich die History außerhalb von BPEL befinden. Sie wird also in einem Web Service gespeichert, auf den jede Instanz des Prozesses Zugriff hat. Das Pattern schickt bei Erhalt einer neuen Nachricht die Message ID an den Web Service. Dieser überprüft, ob die ID bereits in der History enthalten ist. Wenn ja, so schickt der Web Service eine Nachricht an das Pattern, welches daraufhin die Nachricht ignoriert. Wenn nein, so speichert der Web Service die ID in der History und schickt eine Bestätigung an das Pattern. Soll die History persistent gemacht werden, muss der Web Service diese in einer Datenbank oder Datei abspeichern Transactional Client Das Pattern Transactional Client wird für die Filter verwendet, die größere Transaktionen durchführen möchten. Dazu gehören zum Beispiel Send-Receive -Nachrichtenpaare, bei denen ein Filter eine Nachricht erhält und danach eine Nachricht verschickt, wie es zum Beispiel ein Message Router oder Message Translator tut, oder auch das Senden oder Empfangen einer Gruppe von Nachrichten. Diese Szenarien umfassen mehr als nur eine Nachricht und können auch andere Systeme wie zum Beispiel eine Datenbank beinhalten. In diesen Fällen ist eine Transaktion von Nöten, so dass im Falle des Versagens des einen Teils, der andere erfolgreiche Teil der Transaktion ebenfalls rückgängig gemacht werden kann. Abbildung 3.4 zeigt einen Transactional Client mit seinen Ein- und Ausgaben und Parametern.

25 3.2. DIE PATTERNS 25 Abbildung 3.4: Parametrisierung des Transactional Clients Das Pattern selbst besitzt keinerlei Ein- und Ausgaben. Wie oben schon erwähnt, wird das Pattern zusätzlich zu einem Filter Pattern verwendet. Die Ein- und Ausgabe liegt also beim eigentlichen Filter-Pattern. Als einzigsten Parameter benötigt der Transactional Client eine Transaktionslogik. Dazu gehört, dass eine Transaktion begonnen wird und letztendlich entweder committed oder abgebrochen wird. Die Art, wie eine Transaktion begonnen und beendet wird, hängt von der Implementierung des Filters ab. BPEL und Web Services Die Umsetzung des Patterns orientiert sich hauptsächlich an dem darunter liegenden Filter-Pattern. Möchte man den Filter in BPEL umsetzen, so lassen sich auch hier Transaktionen durchführen. Dafür muss der Filter in eine scope-struktur gesetzt werden. Tritt innerhalb des scopes ein Fehler auf (passiv vom System oder aktiv durch Anwendungsspezifische Daten), so kann durch ein compensate die Arbeit zurückgesetzt werden Durable Subscriber Das Pattern Durable Subscriber ist nur für diejenigen Filter interessant, deren Eingang ein Publish-Subscribe Channel (siehe Kapitel ) ist. Dies liegt daran, dass der Publish- Subscribe Channel der einzige Channel ist, der die Nachrichten nicht speichert, wenn der Empfänger offline ist. Muss ein Empfänger eines Publish-Subscribe Channels offline gehen, möchte aber trotzdem keine Nachricht verpassen, so muss er das Pattern Durable Subscriber umsetzen. Das Pattern betrifft dabei sowohl den Filter als auch den Channel. Dem Filter gibt es die Möglichkeit, aktiv sich aus dem Channel für eine Weile zurück zu ziehen, ohne eingehende Nachrichten dabei zu verpassen. Dafür wird ein neuer Zustand eingeführt, bei dem der Empfänger weder aktiv noch offline ist, sondern lediglich inaktiv. Dieser Zustand signalisiert dem Channel, dass der Empfänger wieder aktiv werden wird und die bis dahin empfangenen Nachrichten lesen möchte. Daraufhin kann der Channel einen Speicher einrichten, in dem er alle Nachrichten speichert. Wird der Empfänger wieder aktiv, so bekommt er die Nachrichten vom Channel zugestellt. Der Channel sollte aber auch von sich aus die

26 26 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS Nachrichten speichern, sobald der Empfänger zum Beispiel abstürzt. In einem solchen Fall ist es dem Empfänger unmöglich, sich noch rechtzeitig als inaktiv zu melden, möchte aber trotzdem keine Nachricht verpassen. Der Channel sollte also selbstständig überprüfen, ob der Empfänger noch online ist oder nicht. Möchte der Empfänger bewusst keine Nachrichten empfangen und diese auch nicht gespeichert haben, so sollte er sich in diesem Fall von dem Channel abmelden. Abbildung 3.5 zeigt einen Durable Subscriber mit seinen Ein- und Ausgaben und Parametern. Abbildung 3.5: Parametrisierung des Durable Subscribers Das Pattern selbst besitzt keinerlei Ein- und Ausgaben. Wie oben schon erwähnt, wird das Pattern zusätzlich zu einem Filter Pattern verwendet. Die Ein- und Ausgabe liegt also beim eigentlichen Filter-Pattern. Es werden auch keine Parameter benötigt. Allerdings müssen Änderungen an der Logik des Filters vorgenommen werden. So muss zum einem der neue Zustand eingeführt werden. Da der Filter mit einem Publish-Subscribe Channel verbunden ist, besitzt der Filter bereits einen Control-Channel zum Publish-Subscribe Channel. Dieser Channel wird benutzt, um einen Controlmessage an den Channel zu schicken, sobald der Filter den neuen Zustand einnimmt. Auch der Publish-Subscribe Channel muss modifiziert werden. Zum einem muss er mit der neuen Controlmessage etwas anfangen können. Zum anderen muss der Channel so gestaltet werden, dass er einen Speicher für die inaktive Zeit des Filters einrichten kann. Er muss auch mit einer Logik versehen werden, die ihn dazu bringt, den Speicher einzurichten, falls der Filter offline geht. BPEL und Web Services Da die Empfänger eines Publish-Subscribe Channels in BPEL nicht abgebildet werden können, sondern in Form von nicht vorher festlegbaren Web Services vorliegen (siehe Kapitel ), kann dieses Pattern in BPEL nicht umgesetzt werden.

27 3.2. DIE PATTERNS Competing Consumers Wenn ein Filter Nachrichten nicht so schnell verarbeiten kann, wie sie auf den Channel gelegt werden, bietet es sich an, das Pattern Competing Consumers anzuwenden. Dabei wird der Filter vom Message System vervielfacht und alle Kopien lauschen an dem gleichen Datatype Channel (siehe Kapitel ). Die Nachrichten auf dem Channel werden dann vom Message System an die einzelen Consumer verteilt. Hat ein Filter eine Nachricht vom Channel gelesen, so kann sofort die nächste Nachricht von einem anderen Filter gelesen werden. Abbildung 3.6 zeigt einen Competing Consumer mit seinen Ein- und Ausgaben und Parametern. Abbildung 3.6: Parametrisierung des Competing Consumers Das Pattern selbst besitzt keinerlei Ein- und Ausgaben. Wie oben schon erwähnt, wird das Pattern zusätzlich zu einem Filter Pattern verwendet. Die Ein- und Ausgabe liegt also beim eigentlichen Filter-Pattern. Für die Logik der Verteilung gibt es zwei Möglichkeiten (die Wahl der Möglichkeit hängt im Bereich des Messaging meist von dem verwendeten Message System ab: 1. Message Dispatcher: Der Channel besitzt einen Message Dispatcher (siehe Kapitel ), der die Nachrichten verteilt (dieser wird von dem Message System automatisch implementiert und stellt sicher, dass jede Nachricht nur an einen Empfänger geht). In diesem Fall wird dann auch das Pattern des Message Dispatchers angewendet. 2. Selbst organisiert: In diesem Fall verteilt das Message System die Nachrichten zum Teil an mehrere Filter gleichzeitg. Diese versuchen, die Nachricht in einer Transaktion zu lesen. Der Filter, der seine Transaktion als erster committed, gewinnt den Kampf. Möchten die anderen Filter ihre Transaktion committen, so können sie dies nicht tun, weil die Nachricht bereits vom Channel gelesen wurde. Daraufhin müssen sie ein Rollback der Transaktion durchführen. Diese Möglichkeit benötigt zwar nur ein weniger gutes Message System, sorgt aber dafür, dass die eingesparte Zeit für die Verarbeitung einer Nachricht bedeutend höher ist.

28 28 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS Natürlich muss bei der Anwendung des Patterns auch angegeben werden, wie viele Kopien des Filters erstellt werden sollen. BPEL und Web Services Da für jede neue Nachricht eine neue Instanz des BPEL- Prozesses gebildet wird, treten bei der Umsetzung des Patterns mit Möglichkeit 2 Probleme auf, da hier die Empfänger selbst auf den Channel zugreifen und die Nachricht lesen. Dies ist so nicht umsetzbar, da sich die Nachricht in einer Instanz befindet, auf welche die anderen Instanzen keinen Zugriff haben. Es empfiehlt sich also die Anwendung von Möglichkeit 1 und somit des Patterns Message Dispatcher Message Dispatcher Der Message Dispatcher erlaubt es, mehrere Empfänger an einem beliebigen Channel lauschen zu lassen. Dabei ist es der sogenannte Dispatcher, der am Channel lauscht und die eingehenden Nachrichten an die Empfänger verteilt. Die Verteilung kann dabei auf bestimmten Eigenschaften beruhen, wie zum Beispiel die Auslastung der Empfänger. Die Empfänger selbst sind Kopien des Filters, auf den das Pattern angewendet wird. Es besteht die Möglichkeit, dass sich die Kopien auf einen bestimmten Messagetyp spezialisieren. Dies wird in der Arbeit aber nicht weiter beleuchtet, da hier davon ausgegangen wird, dass aufgrund der Beschaffenheit von BPEL und Web Services jeweils nur ein bestimmter Nachrichtentyp über den Channel geschickt wird. Abbildung 3.7 zeigt einen Message Dispatcher mit seinen Einund Ausgaben und Parametern. Abbildung 3.7: Parametrisierung des Message Dispatchers Das Pattern selbst besitzt keinerlei Ein- und Ausgaben. Wie oben schon erwähnt, wird das Pattern zusätzlich zu einem Filter Pattern verwendet. Die Ein- und Ausgabe liegt also beim eigentlichen Filter-Pattern. Als Parameter muss die Logik angegeben werden, welche die Nachrichten an die Kopien verteilt. Natürlich muss bei der Anwendung des Patterns auch angegeben werden, wie viele Kopien des Filters erstellt werden sollen.

29 3.2. DIE PATTERNS 29 BPEL und Web Services Die Anwendung des Patterns ist in BPEL nur sinnvoll, wenn es sich bei den Empfängern um Web Services handelt. Ist der Empfänger eine Aktivität in BPEL, so kann diese Aktivität nicht überlastet werden, da für jede neue Nachricht eine Instanz des BPEL-Prozesses gebildet wird. Ist der Empfänger aber ein Web Service, so kann dieser von mehreren Instanzen gleichzeitig angesprochen werden. Hier macht es Sinn, mehrere Kopien desselben Web Services laufen zu lassen. Das Pattern könnte dann zum Beispiel bei allen Kopien nachfragen, ob sie für eine weitere Nachricht bereit sind, und dementsprechend die Nachricht weiterleiten. Es kann aber auch ein einfacherer Algorithmus angewendet werden, bei dem über Zufall eine Kopie angesprochen wird Selective Consumer Das Pattern Selective Consumer setzt eine Prüfinstanz vor den eigentlichen Filter. Diese Instanz, der Selective Consumer, überprüft die Nachricht auf dem Channel auf bestimmte Kriterien. Erfüllt die Nachricht die Kriterien des Selective Consumer, so leitet dieser die Nachricht an den eigentlichen Filter weiter. Ansonsten wird die Nachricht ignoriert. Abbildung 3.8 zeigt einen Selective Consumer mit seinen Ein- und Ausgaben und Parametern. Abbildung 3.8: Parametrisierung des Selective Consumers Das Pattern selbst besitzt keinerlei Ein- und Ausgaben. Wie oben schon erwähnt, wird das Pattern zusätzlich zu einem Filter Pattern verwendet. Die Ein- und Ausgabe liegt also beim eigentlichen Filter-Pattern. Damit das Pattern anwendbar ist, muss der Sender bestimmte Werte in die Nachricht setzen, anhand derer die Kriterien angewendet werden. Beim Selective Consumer selbst müssen die erwarteten Attribute und deren Werte angegeben werden. Diese werden dann in der eingehenden Nachricht gesucht und überprüft. BPEL und Web Services Die Filterung kann in BPEL umgesetzt werden, unabhängig von der weiteren Umsetzung des Filters. Dabei werden über XPATH die Filterkriterien überprüft. Sind diese erfüllt, wird die Nachricht an den Filter weitergegeben. Wenn nicht, wird die Nachricht ignoriert.

30 30 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS Messaging Channels Bei den nachfolgenden Patterns handelt es sich zum Teil um Channels, die zwei Filter miteinander verbinden. Es ist zu beachten, dass diese Channels Quality of Services beeinhalten. Diese müssen auch für den vorhergehenden bzw. nachfolgenden Filter angewendet werden, der einen Web Service aufrufen, so dass der Aufruf des Web Services unter den gleichen Bedingungen stattfindet Datatype Channel Bei einem Datatype Channel handelt es sich um einen Point-to-Point Channel, der allerdings typgebunden ist, d.h. es können nur Nachrichten eines bestimmten Typs über diesen Channel geschickt werden. Dies macht es vor allem für den Empfänger recht einfach, da dieser genau weiß, was für eine Nachricht er über den Channel empfängt und wie er mit dieser umzugehen hat. Abbildung 3.9 zeigt einen Datatype Channel mit seinen Ein- und Ausgaben und Parametern. Abbildung 3.9: Parametrisierung des Datatype Channels Die Ein- und Ausgabe eines Datatype Channels ist jeweils eine Nachricht (siehe Kapitel Message Patterns 3.2.1). Dabei muss der Nachrichtentyp der Eingabe mit dem der Ausgabe übereinstimmen. Deshalb wird bei der Erstellung eines Datatype Channels der Nachrichtentyp festlegt. Da es sich hier um einen Channel handelt, muss für diesen eine logische Adresse definiert werden. Über diese logische Adresse können sowohl Sender als auch Empfänger auf die dort

31 3.2. DIE PATTERNS 31 abgelegten Nachrichten zugreifen. Der Channel selbst kann die unterschiedlichsten Formen annehmen: Er kann eine Datei sein, eine Datenbank, ein Channel in einem Messaging System, oder auch nur eine CD. Die logische Adresse ist dabei das Entscheidende, denn mit Hilfe dieser findet man den Channel. Im Falle der CD wäre das vielleicht das Regal oder Fach, in dem diese lagert. Im Falle einer Datei ist es der Name und der Pfad. Analoges gilt für alle anderen Channelarten. Abhängig von der Implementierung, ist es nötig, bei Erstellung des Channels die Puffergröße festzulegen. Umso größer der Puffer, umso mehr Nachrichten kann der Channel speichern. Ebenso kann es erforderlich sein, die maximale Nachrichtengröße festzulegen. Außerdem können für einen Channel noch bestimmte Quality of Services festgelegt werden. Diese bestimmen, welche Leistung der Channel bietet. Darunter fallen unter anderem die Punkte Zuverlässigkeit, Sicherheit und transaktionelles Verhalten. Wird bei einem Channel Wert auf Zuverlässigkeit gelegt, so wird der Channel dermaßen gestaltet, dass die Wahrscheinlichkeit einer erfolgreichen Übertragung einer Nachricht vom Sender zum Empfänger in gewünschter Art und Weise so hoch wie möglich ist. Eine 100- prozentige Wahrscheinlichkeit lässt sich zwar nicht erreichen, doch lässt sich die Wahrscheinlichkeit durch Maßnahmen wie zum Beispiel die Persistenz von Nachrichten erhöhen. Werden die gesendeten Nachrichten persistent gemacht, so gehen diese auch bei einem Systemabsturz nicht verloren. Eine Möglichkeit, die Zuverlässigkeit eines Channels zu erhöhen, wird durch das Pattern Guaranteed Delivery (siehe Kapitel ) beschrieben. Weitere Maßnahmen sind zum Beispiel die Einhaltung der Reihenfolge der Nachrichten - dafür gibt es das Pattern des Resequencers (siehe Kapitel ) - und die Garantie, dass jede Nachricht genau einmal ausgeliefert wird - hierfür gibt es das Pattern Idemptotent Receiver (siehe Kapitel ). Die Sicherheit des Channels zeichnet sich darin aus, wie viel Aufwand in die Verschlüsselung der gesendeten Daten gesteckt wird. Dies kann durch die Wahl des Transportprotokolls passieren und sich deshalb direkt auf die Art des Channels auswirken. Es ist auch möglich, dass Sicherheit durch Verschlüsselung der Nachricht geschieht - dies hat wiederrum weniger mit dem Channel selbst zu tun, sondern ist Sache des Senders und des Empfängers. In manchen Fällen ist es auch notwendig, dass Nachrichten in transaktionsähnlichen Verhältnissen versendet und empfangen werden. Das fängt bei den einfachen Transaktionen wie das Versenden oder Empfangen einer einzigen Nachricht an, kann sich aber auch auf Nachrichtengruppen usw. beziehen. Transaktionen folgen dem ACID Prinzip: Atomizität, Konsistenz, Isolation und Dauerhaftigkeit. Dabei ist die einzelne Nachricht bereits atomar. Dauerhaftigkeit lässt sich wie oben beschrieben zum Beispiel über das Pattern Guaranteed Delivery erreichen. Somit müssen Nachrichtentransaktionen zusätzlich noch konsistent und isoliert sein. Die meisten Message Systeme unterstützen die einfachen Transaktionen des Sendens und Empfangens von Nachrichten. Größere Transaktionsszenarien müssen aber extra implementiert werden. Dafür kann man zum Beispiel das Pattern Transactional Client (siehe Kapitel ) verwenden. Soll der Channel Gültigkeit oder Alter der gesendeten Nachrichten berücksichtigen und gegebenfalls abgelaufene Nachrichten aus dem Verkehr ziehen, so muss dafür ein Dead Letter Channel (siehe Kapitel ) angegeben werden. Zusätzlich müssen dem Channel die Bedingungen mitgeteilt werden, die erfüllt sein müssen, damit eine Message als tot behandelt

32 32 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS wird. Dazu kann zum Beispiel das Pattern Message Expiration (siehe Kapitel ) gehören. Der Channel muss in diesem Fall also nicht nur mit Sender und Empfänger, sondern auch mit einem Dead Letter Channel verbunden sein. Der Datatype Channel stellt eine Schnittstelle zwischen zwei Patterns dar. Über ihn lässt sich feststellen, ob die jeweiligen Ein- und Ausgangspatterns zusammenpassen. Dies lässt sich über den eingehenden und ausgehenden Nachrichtentyp bestimmen. Ausführlichere Informationen über die Kombination von Patterns sind in Kapitel 3.3 zu finden. BPEL und Web Services Der Datatype Channel stellt den Standard-Channel in BPEL dar. Es ist zwar möglich, Nachrichten einer bestimmten Art (wie zum Beispiel XML) unabhängig von der darin enthalteten Struktur (zum Beispiel dem XML Schema) zu verschicken, allerdings ist es den verarbeitenden Teilen in BPEL nur möglich, Nachrichten einer speziellen Struktur zu verarbeiten. Nachrichten mit einem anderen XML Schema als erwartet, werden also verschickt, aber nicht bearbeitet. Logisch gesehen entspricht dies also einem Datatype Channel, da nur der Versand eines bestimmten Nachrichtentyps (definiert durch das XML Schema) Sinn macht. Möchte man unterschiedliche Nachrichtentypen verschicken, so müssen mehrere Channels eingesetzt werden. Dies hat allerdings auch zur Folge, dass die den Channel umgebenden Patterns (d.h. die Filter) mehrfach implementiert werden müssen, da auch diese sich auf einen bestimmten Nachrichtentyp spezialisieren. Die Implementierung des Channels hängt u.a. von der Wahl der Quality of Services ab. Dies beeinflusst also automatisch die Art der logischen Adresse des Channels. Im Bereich Web Services und BPEL könnte ein Channel über folgende Möglichkeiten realisiert werden: 1. BPEL Link (innerhalb eines Flow-Konstruktes) in Zusammenhang mit den Ein- und Ausgangsvariablen der Filterpattern mit zusätzlicher Unterstützung durch einen Web Service Der BPEL Link sorgt dafür, dass nach einem bestimmten Filter-Pattern ein anderes Filter- Pattern ausgeführt wird. Er gibt also die Reihenfolge der einzelnen Patterns vor. Allerdings handelt es sich hier nur um einen Control Connector. Beim Datatype Channel wird zusätzlich noch eine Nachricht verschickt, weshalb es sich hier um einen Data Connector handelt. Einen Data Connector gibt es in BPEL aber nicht explizit. Hier werden keine Daten verschickt. Allerdings wird das Ergebnis des vorherigen Filters in einer Variablen gespeichert, welche dann vom nächsten Filter als Eingangsvariable gelesen wird. Es macht also Sinn, die Variablen zwischen den beiden Filtern, die ein Link verbindet, noch zum eigentlichen Channel dazuzuzählen. Da die Umsetzung der Quality of Services für einen Channel eine komplexe Aufgabe darstellt, wird hier nur ein denkbarer Vorschlag diskutiert. Dabei handelt es sich um Punkt 2 der oberen Liste. Um einen zuverlässigen Channel in BPEL zu implementieren, benötigt man Zugriff auf eine persistente Speicherstruktur. Dies ist zum Beispiel über einen Web Service möglich. Die Nachricht wird also vom Channel als erstes über eine zuverlässige Verbindung (zum Beispiel WS-ReliableMessaging) an einen Web Service weitergeleitet. Dieser speichert die Nachricht zum Beispiel in einer Datenbank oder einer Datei ab. Danach kann der Channel die Nachricht

33 3.2. DIE PATTERNS 33 wie sonst auch an den Empfänger weiterleiten. Sobald der Empfänger ein Acknowledge an den Channel schickt, kann dieser die Nachricht über den Web Service wieder löschen. Für den Zugriff auf den Web Service bieten sich auch noch andere Standards aus dem Web Service Bereich an, die Quality of Services bereitstellen. Dazu gehören zum Beispiel WS- Security und WS-AtomicTransaction. Der Parameter Puffergröße ist im BPEL-Bereich nicht nötig. Dies liegt daran, dass BPEL im Vergleich zu einem normalen Patternfluss instanzbasiert ist. Das bedeutet, dass pro versendeter Nachricht eine Instanz des BPEL-Prozesses erstellt wird. Somit befindet sich immer nur eine Nachricht auf dem Channel. Möchte man aber einen zuverlässigen Channel mit Hilfe eine Web Services verwenden, so muss hier bedacht werden, dass alle Instanzen denselben Web Service verwenden. Damit Nachrichten zweier Instanzen nicht vertauscht werden, muss hier ein zusätzlicher Mechanismus eingebaut werden, der eine Nachricht mit seiner Instanz verbindet Publish-Subscribe Channel Der Publish-Subscribe Channel erlaubt es, eine Nachricht an mehrere Empfänger gleichzeitig zu schicken. Somit besitzt der Publish-Subscribe Channel eine gewisse Ähnlichkeit zum Pattern Recipient List (siehe Kapitel ). Die Empfänger sind beim Publish-Subscribe Channel allerdings vorher nicht festgelegt. Sie schreiben sich aktiv beim Channel in eine Subscriber-Liste ein. Jeder Empfänger bekommt eine Kopie der eingehenden Nachricht. Die Empfänger haben allerdings die Möglichkeit, bei ihrer Einschreibung sogenannte Wildcards zu definieren. Durch diese Wildcard können die verschickten Nachrichten gefiltert werden. Ein Empfänger bekommt in diesem Fall nur die Nachricht, die zu seiner Wildcard passt. Abbildung 3.10 zeigt einen Publish-Subscribe Channel mit seinen Ein- und Ausgaben und Parametern. Die Ein- und Ausgabe eines Publish-Subscribe Channels ist jeweils eine Nachricht (siehe Kapitel Message Patterns 3.2.1). Dabei muss der Nachrichtentyp der Eingabe mit dem der Ausgabe übereinstimmen. Deshalb wird bei der Erstellung eines Publish-Subscribe Channels der Nachrichtentyp festlegt. Damit sich die Empfänger beim Channel einschreiben können, muss ein Control-Channel zum Publish-Subscribe Channel existieren. Dafür müssen sowohl der Channel als auch die Empfänger den Nachrichtentyp der Control-Message kennen. Außerdem müssen die Empfänger eine Subscribe/Unsubscribe-Logik besitzen, um sich selbstständig ein- und auszutragen. Der Channel selbst benötigt eine Subscriber-Liste. In ihr werden die Empfänger und ihre Wildcards gespeichert. Da es sich hier um einen Channel handelt, treffen hier auch viele Parameter wie für den Standardchannel, den Datatype Channel, zu. Dazu gehören in diesem Fall die logische Adresse, die Quality of Services, die Größenparameter und der Dead Letter Channel. Diese Parameter können in Kapitel detaillierter nachgelesen werden.

34 34 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS Abbildung 3.10: Parametrisierung des Publish-Subscribe Channels

35 3.2. DIE PATTERNS 35 Als Ergänzung zu den Quality of Services gibt es für die Empfänger der Nachricht auch noch das Pattern Durable Subscriber (siehe Kapitel ). Dieses ist nötig, wenn der Empfänger sämtliche Nachrichten erhalten möchte - auch wenn er eine Zeit lang offline ist. Im Normalfall gehen diese Nachrichten verloren. Der Publish-Subscribe Channel stellt eine Schnittstelle zwischen zwei Patterns dar. Über ihn lässt sich feststellen, ob die jeweiligen Ein-und Ausgangspatterns zusammenpassen. Dies lässt sich über den eingehenden und ausgehenden Nachrichtentyp bestimmen. Ausführlichere Informationen über die Kombination von Patterns sind in Kapitel 3.3 zu finden. BPEL und Web Services Für den Publish-Subscribe Channel gelten die gleichen Bedingungen und Möglichkeiten wie für den Datatype Channel (siehe Kapitel ). Allerdings benötigt der Publish-Subscribe Channel etwas mehr Logik als der Datatype Channel. Er muss für jeden Eintrag in der Subscriber-Liste überprüfen, ob die Nachricht dorthin geschickt werden muss. Und wenn ja, dann muss er natürlich die Nachricht an den Empfänger schicken. Da für jede eingehende Nachricht eine Instanz des BPEL-Prozesses erstellt wird und deshalb mehrere Instanzen parallel arbeiten können, muss eine dynamische Subscriber-Liste außerhalb von BPEL in einem Web Service gespeichert werden. Über diesen Web Service kann jede BPEL-Instanz auf die Subscriber-Liste zugreifen. Die Control Messages, welche die Subscriber-Liste verändern sollen, werden in diesem Fall von den Empfängern direkt an die Schnittstelle des Web Services geschickt. Soll die Liste persistiert werden, so kann dies ebenfalls der Web Service übernehmen. Handelt es sich um eine statische Subscriber-Liste, die zur Laufzeit nicht verändert wird, so kann sie in BPEL direkt gespeichert sein. Arbeitet der Publish-Subscribe Channel mit dynamischen Empfängern, lassen sich bei der Erstellung des Patterns keine Empfänger festlegen. Man kann also hinter einen Publish- Subscribe Channel zum Beispiel nicht direkt einen Message Translator setzen, der über einen Link mit dem Channel verbunden ist, da zur Zeit des Entwurfs die Empfänger nicht feststehen. Der Channel kann daher die Nachricht nur an Web Services schicken, deren Daten er in der dynamischen Liste z.b. per WS-Addressing bekommt. Diese Web Services sind allerding nicht Teil des BPEL-Prozesses. Möchte man nun die Antworten der Web Services wieder in den BPEL Prozess einfließen lassen, so sollte man einen generischen Empfänger hinter den Publish-Subscribe Channel setzen, der den Web Services eine Schnittstelle bietet, an die sie ihre Nachrichten schicken können. Der generische Empfänger kann dann diese Nachrichten an das nächste Pattern weiterleiten. Möchte man die Antworten des generischen Empfängers wieder in den BPEL-Prozess einfließen lassen, so ergeben sich hier Probleme: Die Anzahl der Empfänger ist unbekannt. Es ist auch nicht bekannt, welche Empfänger eine Antwort schicken. Es bietet sich an, einen Aggregator hinter den generischen Empfänger zu setzen (mit einem Datatype Channel als Verbindung), der lediglich einen Eingang besitzt. Dieser lauscht eine vorgegebene Zeit auf diesem Eingang und schickt nach Ablauf der Frist die angesammelten Nachrichten gebündelt als eine Nachricht weiter. Dieses Vorgehen entspricht dem Pattern Scatter-Gather, das in Abschnitt näher beschrieben ist.

36 36 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS Invalid Message Channel Der Invalid Message Channel kann an einen Filter als zusätzlicher Ausgangschannel gesetzt werden. Er bietet also eine Alternative zum eigentlichen Weg der Nachricht. Der Filter kann dann auf diesen Channel alle Nachrichten legen, die zwar bei ihm ankamen, aber die von ihm nicht verarbeitet werden konnten. Dafür kann es viele Gründe geben. Möglicherweise ergeben manche Property-Werte keinen Sinn, der Body kann nicht geparst werden, oder es handelt sich um Validierungsfehler. Abbildung 3.11 zeigt einen Invalid Message Channel mit seinen Ein- und Ausgaben und Parametern. Abbildung 3.11: Parametrisierung des Invalid Message Channels Die Ein- und Ausgabe eines Invalid Message Channels ist jeweils eine Nachricht (siehe Kapitel Message Patterns 3.2.1). Dabei muss der Nachrichtentyp der Eingabe mit dem der Ausgabe übereinstimmen. Deshalb wird bei der Erstellung eines Invalid Message Channels der Nachrichtentyp festlegt. Der Invalid Message Channel muss nicht unbedingt einen Ausgang besitzen. Er kann aber

37 3.2. DIE PATTERNS 37 nötig sein, wenn die Nachrichten weiterverarbeitet werden sollen. Ist kein Ausgang vorhanden, müssen die Nachrichten auf jeden Fall im Channel zwischengespeichert werden, bis sie manuell von einem Administrator gelöscht werden. Für den Channel bedeutet das, dass er selbst der Empfänger ist. Da es sich hier um einen Channel handelt, treffen hier auch viele Parameter wie für den Standardchannel, den Datatype Channel, zu. Dazu gehören in diesem Fall die logische Adresse, die Größenparameter und die Quality of Services. Diese Parameter können in Kapitel detaillierter nachgelesen werden. Wird ein Invalid Message Channel an einen Filter gesetzt, so müssen auch beim Filter Änderungen durchgeführt werden. Die Logik des Filters muss so angepasst werden, dass die entsprechenden Nachrichten auf den Invalid Message Channel geleitet werden. Dafür muss natürlich erst einmal festgelegt werden, unter welchen Bedingungen eine Nachricht als ungültig gilt und deshalb auf den Channel geleitet wird. BPEL und Web Services Für den Invalid Message Channel gelten die gleichen Bedingungen und Möglichkeiten wie für den Datatype Channel (siehe Kapitel ). In BPEL ist es irrelevant, ob der Channel einen Ausgang besitzt oder nicht. Die Nachrichten werden in beiden Fällen in einem Web Service gespeichert. Deswegen fällt hier die Wahl weg und der Channel muss mit den Daten eines Web Services versehen werden, der die Nachrichten speichern soll Dead Letter Channel Der Dead Letter Channel kann an einen Channel als zusätzlicher Ausgang gesetzt werden. Er bietet also eine Alternative zum eigentlichen Weg der Nachricht. Das Message System kann dann auf den Dead Letter Channel alle Nachrichten legen, die an den eigentlichen Empfänger nicht ausgeliefert werden können. Dafür kann es viele Gründe zu geben. Möglicherweise ist die Nachricht nicht mehr aktuell, d.h. ihre Gültigkeit ist abgelaufen (siehe Kapitel ). Gregor Hohpe beschreibt auch die Möglichkeit, dass eine Nachricht einen Content-Based Router (siehe Kapitel ) erreicht, die an keinen Ausgang weitergeleitet werden kann. In diesem Fall kann laut Hohpe der Router die Nachricht auf den Dead Letter Channel legen, anstatt sie zu löschen (siehe [2]). Dem kann ich nicht zustimmen. Meiner Meinung nach sollte hier stattdessen der Invalid Message Channel (siehe ) verwendet werden, da der Router die Nachricht zwar empfangen hat, aber nicht verarbeiten kann. Der Dead Letter Channel hingegen tritt in Kraft, wenn die Nachricht erst gar nicht den Router erreicht. Aus diesem Grund wird der von Gregor Hohpe beschriebene Fall in dieser Arbeit nicht weiter berücksichtigt. Abbildung 3.12 zeigt einen Dead Letter Channel mit seinen Ein- und Ausgaben und Parametern. Die Ein- und Ausgabe eines Dead Letter Channels ist jeweils eine Nachricht (siehe Kapitel Message Patterns 3.2.1). Dabei muss der Nachrichtentyp der Eingabe mit dem der Ausgabe

38 38 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS Abbildung 3.12: Parametrisierung des Dead Letter Channels

39 3.2. DIE PATTERNS 39 übereinstimmen. Deshalb wird bei der Erstellung eines Dead Letter Channels der Nachrichtentyp festlegt. Der Dead Letter Channel muss nicht unbedingt einen Ausgang besitzen. Er kann aber nötig sein, wenn die Nachrichten weiterverarbeitet werden sollen. Ist kein Ausgang vorhanden, müssen die Nachrichten auf jeden Fall im Channel zwischengespeichert werden, bis sie manuell von einem Administrator gelöscht werden. Für den Channel bedeutet das, dass er selbst der Empfänger ist. Da es sich hier um einen Channel handelt, treffen hier auch viele Parameter wie für den Standardchannel, den Datatype Channel, zu. Dazu gehören in diesem Fall die logische Adresse, die Größenparameter und die Quality of Services. Diese Parameter können in Kapitel detaillierter nachgelesen werden. Wird ein Dead Letter Channel an einen Channel gesetzt, so müssen auch beim Channel Änderungen durchgeführt werden. Die Logik des Channel muss so angepasst werden, dass die entsprechenden Nachrichten auf den Dead Letter Channel geleitet werden. Dafür muss natürlich erst einmal festgelegt werden, unter welchen Bedingungen eine Nachricht als tot gilt und deshalb auf den Channel geleitet wird. BPEL und Web Services Für den Dead Letter Channel gelten die gleichen Bedingungen und Möglichkeiten wie für den Datatype Channel (siehe Kapitel ). In BPEL ist es irrelevant, ob der Channel einen Ausgang besitzt oder nicht. Die Nachrichten werden in beiden Fällen in einem Web Service gespeichert. Deswegen fällt hier die Wahl weg und der Channel muss mit den Daten eines Web Services versehen werden, der die Nachrichten speichern soll Guaranteed Delivery Bei Guaranteed Delivery handelt es sich nicht um ein eigenständiges Channel-Pattern. Es kann aber zusätzlich zu einem Channel-Pattern verwendet werden. In diesem Fall modifiziert es den Channel so, dass der Channel zuverlässiger wird. Das Pattern konzentriert sich also auf die Quality of Services. Wird das Pattern angewendet, so müssen die Nachrichten, die über den Channel geschickt werden, persistent gemacht werden. Sie dürfen erst dann gelöscht werden, wenn der Empfänger die Nachricht erfolgreich angenommen hat. Stürzt das Messagingsystem vorher ab, so verringert sich die Wahrscheinlichkeit, dass die Nachricht verloren geht. Abbildung 3.13 zeigt das Pattern Guaranteed Delivery mit seinen Ein- und Ausgaben und Parametern. Das Pattern selbst besitzt keinerlei Ein- und Ausgaben. Wie oben schon erwähnt, wird das Pattern zusätzlich zu einem Channel Pattern verwendet. Die Ein- und Ausgabe liegt also beim eigentlichen Channel-Pattern. Auch die restlichen Parameter sind sehr gering, da das Pattern selbst nur geringfügig konfiguriert wird. Es ist zum einen notwendig, den Messagetyp der zu speichernden Nachrichten anzugeben, zum anderen muss natürlich auch die Logik des Channels verändert werden, so dass die Nachrichten zum Beispiel in einer Datenbank gespeichert werden.

40 40 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS Abbildung 3.13: Parametrisierung des Guaranteed Delivery Patterns BPEL und Web Services In BPEL selbst können Daten nicht persistent gemacht werden. Stürzt der BPEL-Prozess ab, so gehen auch die Daten verloren. Möchte man dieses Pattern also anwenden, bietet es sich hier an, einen Web Service aufzurufen, der die Nachrichten persistent macht, in dem er sie in einer Datenbank oder Datei abspeichert. Ist die Nachricht abgespeichert, so kann versucht werden, sie an den Empfänger weiterzuleiten. Erst wenn der Empfänger die Nachricht ohne Fehler angenommen hat, darf der Web Service die Nachricht wieder löschen. Stürzt der BPEL-Prozess allerdings vor dem Abspeichern einer Nachricht ab, so geht diese trotzdem verloren. Es stellt sich auch die Frage, wie die abgespeicherten Nachrichten nach einem Absturz des BPEL-Prozesses wieder automatisch eingebunden werden können. Für weitere Informationen siehe auch Kapitel Message Expiration Bei diesem Pattern handelt es sich eigentlich nicht direkt um ein Channel-Pattern. In erster Linie handelt es sich um ein Message-Pattern. Es sorgt dafür, dass eine Nachricht eine Art Verfallsdatum bekommt. Ist dieses abgelaufen, so darf die Nachricht nicht mehr verarbeitet werden, da die darin enthaltenen Daten nicht mehr gültig sind. Die Nachricht soll dann gelöscht oder auf den Dead Letter Channel (siehe Kapitel ) geschickt werden. Dies betrifft allerdings den Inhalt einer Nachricht und somit auch den Nachrichtentyp. Wie in Kapitel schon erwähnt, ist der Inhalt eines Patterns für die Parametrisierung nicht von Bedeutung. Das Pattern beinhaltet allerdings einen zweiten Aspekt, der hier von Bedeutung ist. Wird eine Nachricht mit einem Verfallsdatum versehen, so muss der die Nachricht versendende Channel darauf abgestimmt sein. Das heißt, das Message System muss wissen, dass die Nachricht möglicherweise ein Verfallsdatum besitzt. Besitzt die Nachricht ein Verfallsdatum, so muss das Message System dieses überprüfen bevor die Nachricht auf den Channel gelegt wird bzw. vom Channel gelesen wird. Der Channel ist also dafür zuständig, noch gültige Nachrichten

41 3.2. DIE PATTERNS 41 an den Empfänger weiterzuleiten und bereits ungültige Nachrichten aus dem Verkehr zu ziehen. Deswegen ist dieses Pattern wie Guaranteed Delivery (siehe ) als Zusatzpattern für einen Channel zu betrachten. Es wird meist im Zusammenhang mit einem Dead Letter Channel verwendet, so dass das Message System die abgelaufene Nachricht vom Hauptchannel auf den Dead Letter Channel schicken kann. Abbildung 3.14 zeigt das Pattern Message Expiration mit seinen Ein- und Ausgaben und Parametern in Bezug auf den Channel. Abbildung 3.14: Parametrisierung eines Channels mit Message Expiration Das Pattern selbst besitzt keinerlei Ein- und Ausgaben. Wie oben schon erwähnt, wird das Pattern zusätzlich zu einem Channel Pattern verwendet. Die Ein- und Ausgabe liegt also beim eigentlichen Channel-Pattern. Auch die restlichen Parameter sind sehr gering, da das Pattern selbst nur geringfügig konfiguriert wird. Es ist zum einen notwendig, den Messagetyp der zu überprüfenden Nachrichten anzugeben, zum anderen muss natürlich auch die Logik des Message Systems verändert werden. Dazu gehört erst einmal, dass festgelegt werden muss, was mit einer abgelaufenen Nachricht passieren soll. Sie kann einfach gelöscht werden, oder auf einen Dead Letter Channel geschickt werden. Dafür muss ein Dead Letter Channel mit dem Channel verbunden sein. Es ist auch wichtig, dass das Message System weiß, wie es die Gültigkeit der Nachricht zu bestimmen hat. Eine Nachricht besitzt als Verfallsdatum einen Timestamp. Dieser kann absolut oder relativ angeben werden. Ist er absolut, so werden Datum und Uhrzeit festgelegt, wann die Nachricht ihre Gültigkeit verliert. Ein relativer Timestamp gibt eine Anzahl von Sekunden oder Minuten an. In Zusammenhang mit der Angabe, wann die Nachricht erstellt wurde, kann das Message System dann bestimmen, ob die Nachricht bereits abgelaufen ist. Dafür addiert er das Erstellungsdatum und die Gültigkeitsdauer und vergleicht das Ergebnis mit dem aktuellen Datum. Damit klar ist, welches Attribut den Timestamp beeinhaltet, muss auch der Name des Attributes angegeben werden.

42 42 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS BPEL und Web Services Die Änderungen am Message System und somit am Channel, um Message Expiration umzusetzen, können sowohl in BPEL als auch in einem Web Service durchgeführt werden. Die Wahl, wie ein Channel also letztendlich umgesetzt wird, wird von diesem Pattern nicht eingeschränkt. Dafür müssen die restlichen Patterns hinzugezogen werden, die den Channel definieren. Möchte man das Pattern in BPEL umsetzen, so könnte man den Channel in ein scope- Konstrukt packen und diesem mit einem EventHandlet onalarm versehen, der nach einer gewissen Zeit die Nachricht an den Dead Letter Channel weiterleitet Message Routing Bei den nachfolgenden Patterns handelt es sich um Routing Patterns. Die meisten davon lassen sich auf die ein oder andere Weise komplett in BPEL umsetzen. BPEL bietet dafür mehrere Möglichkeiten. Zum einen lassen sich If/ElseIf/Else-Abfragen erstellen, die den Inhalt der Nachricht überprüfen können. Aber auch die BPEL-Links ermöglichen eine gewisse Routing-Logik. So kann man für jeden Link eine Bedingung (TransitionCondition) festlegen, die erfüllt sein muss, so dass der Link ausgeführt wird. Besitzt ein Pattern mehrere eingehende Links, so lassen sich für diese Links eine weitere Bedingung (JoinCondition) angeben, die erfüllt sein muss, so dass das Pattern ausgeführt wird. Hier könnte man zum Beispiel verlangen, dass alle Links ausgeführt werden müssen, oder nur ein bestimmter Link. Die JoinCondition ist vor allem für das Pattern Aggregator interessant Content-Based Router Der Content-Based Router ist eines der wenigen Patterns, das zwar nur einen Eingang hat, aber mehrere Ausgänge besitzt. Allerdings wird bei der Benutzung des Patterns jeweils immer nur ein Ausgang angesprochen. Welcher Ausgang gewählt wird, hängt dabei vom Inhalt der Nachricht ab. Und natürlich von der gewählten Routing-Logik. Abbildung 3.15 zeigt einen Content-Based Router mit seinen Ein- und Ausgaben und Parametern. Die Ein- und Ausgabe eines Content-Based Routers ist jeweils eine Nachricht (siehe Kapitel Message Patterns 3.2.1). Da der Router die Nachricht lediglich weiterleiten soll ohne sie zu verändern, muss der Nachrichtentyp der Eingabe mit dem der Ausgabe übereinstimmen. Deshalb wird bei der Erstellung eines Content-Based Routers der Nachrichtentyp festlegt. Um mit dem Content-Based Router arbeiten zu können, muss zuerst einmal die Anzahl der Ausgänge n festgelegt werden. Es handelt sich hierbei um eine statische Zahl n, die zur Entwurfszeit festgelegt werden muss. Zu dieser Anzahl n kommt automatisch noch ein weiterer Ausgang dazu. Dieser Ausgang stellt den else-zweig dar. Dort werden die Nachrichten hingeschickt, die zu keinem der vorhandenen Ausgänge passen. Es kann eingestellt werden, ob dieser Ausgang auf empty gesetzt werden soll, oder ob der Ausgang genutzt werden soll. Wird der Ausgang auf empty gesetzt, so wird mit der Nachricht nichts gemacht und die Nachricht geht verloren. Für jeden anderen der n Ausgänge muss jeweils eine Routing-Logik angegeben werden.

43 3.2. DIE PATTERNS 43 Abbildung 3.15: Parametrisierung des Content-Based Routers Damit die angrenzenden Channel die richtige Nachricht bekommen, müssen die intern im Router angelegten Ausgänge noch auf die jeweiligen Channel gemappt werden. Man benötigt also eine Tabelle, die der Ausgangsnummer eine Channel-ID zuordnet. Diese Tabelle hilft gleichzeitig auch, nicht den Überblick zu verlieren. BPEL und Web Services Die Umsetzung des Content-Based Routers unterscheidet sich hauptsächlich durch die Wahl und Implementierung der Routing-Logik. Hierfür können unterschiedliche Methoden angewendet werden. Im Bereich BPEL und Web Services bieten sich vor allem zwei Alternativen an: 1. Routing durch BPEL Code 2. Routing durch einen Web Service Im ersten Fall wird die eingehende Nachricht über BPEL durch eine einfache Überprüfung des Inhalts geroutet. Hierbei können allerdings keine komplexen Verfahren angewendet werden, da die Arbeit mit BPEL beschränkt ist. Bei der zweiten Möglichkeit wird der eigentliche Router als Web Service umgesetzt. Dabei wird in BPEL der Web Service aufgerufen, der dann die Nachricht untersucht und den weiteren Weg der Nachricht bestimmt. Der Web Service gibt durch einen invoke-aufruf einen Wert zurück, aufgrund dessen die Nachricht dann in BPEL geroutet wird.

44 44 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS Message Filter Beim Message Filter handelt es sich um eine Vereinfachung des Content-Based Routers (siehe Kapitel ). Anstatt einer variablen Anzahl von Ausgängen besitzt der Message Filter lediglich einen Ausgang. Seine Aufgabe ist es also nicht, die eingehende Nachricht an einen bestimmten Channel weiterzuleiten, sondern jede eingehende Nachricht darauf zu überprüfen, ob sie überhaupt weitergeleitet wird. Nachrichten, die nicht die geforderten Kriterien erfüllen, werden vom Message Filter gelöscht. Dies passiert auch beim Content-Based Router; und zwar mit Nachrichten, die keinem Channel zugewiesen werden können. Somit handelt es sich in der Tat um einen Content-Based Router mit nur einem Ausgang. Diese Vereinfachung wirkt sich auch auf die Parameter des Patterns aus. Abbildung 3.16 zeigt einen Message Filter mit seinen Ein- und Ausgaben und Parametern. Abbildung 3.16: Parametrisierung des Message Filters Die Ein- und Ausgabe eines Message Filters ist jeweils eine Nachricht (siehe Kapitel Message Patterns 3.2.1). Da der Filter die Nachricht lediglich weiterleiten soll ohne sie zu verändern, muss der Nachrichtentyp der Eingabe mit dem der Ausgabe übereinstimmen. Deshalb wird bei der Erstellung eines Message Filters der Nachrichtentyp festlegt. Da festgelegt ist, dass nur ein Ausgang benötigt wird, fallen die meisten Parameter des Content-Based Routers für diesen Fall weg. Dazu gehört auch die Option des else-zweiges. Es wäre zwar möglich, die herausgefilterten Nachrichten zu verarbeiten, aber das Pattern ist laut Hohpe et al (siehe [2]) nicht dafür vorgesehen. Deshalb muss für den Message Filter lediglich eine Filterlogik angegeben werden. Diese kann beliebig kompliziert sein. Es ist zum Beispiel möglich, mit Hilfe der Filterlogik den Message Filter zustandsbehaftet zu gestalten. Dadurch kann man den Message Filter dazu verwenden, doppelte Nachrichten zu entfernen. BPEL und Web Services Die Umsetzung des Message Filters unterscheidet sich hauptsächlich durch die Wahl und Implementierung der Filterlogik. Hierfür können unterschiedliche Methoden angewendet werden. Im Bereich BPEL und Web Services bieten sich vor allem zwei Alternativen an:

45 3.2. DIE PATTERNS Filtern durch BPEL Code 2. Filtern durch einen Web Service Im ersten Fall wird die eingehende Nachricht über BPEL durch eine einfache Überprüfung des Inhalts gefiltert. Hierbei können allerdings keine komplexen Verfahren angewendet werden, da die Arbeit mit BPEL beschränkt ist. Bei der zweiten Möglichkeit wird der eigentliche Router als Web Service umgesetzt. Dabei wird in BPEL der Web Service aufgerufen, der dann die Nachricht untersucht und den weiteren Weg der Nachricht bestimmt. Der Web Service gibt durch einen invoke-aufruf eine Wert zurück, aufgrund dessen die Nachricht dann in BPEL weitergeleitet wird oder nicht Dynamic Router Wie auch beim Content-Based Router (siehe Kapitel ) gibt es beim Dynamic Router mehrere Ausgänge. Im Gegensatz dazu bietet der Dynamic Router die Möglichkeit, dynamisch festzulegen, welche der Ausgänge benutzt werden. Zwar muss auch hier fest definiert sein, welcher Ausgang zu welchem Channel gehört, aber ob dieser dann auch bedient wird oder nicht, wird dynamisch während der Laufzeit festgelegt. Dies bietet den Vorteil, dass sich die an den Channel hängenden Dienste selbstständig beim Router ein- und austragen können. Geht ein bestimmter Dienst also offline, so kann er sich beim Router austragen. Geht er wieder online, muss er sich lediglich beim Router wieder eintragen, und schon kann der Router wieder Nachrichten an den Dienst schicken. Bei einem statischen Router würde eine solches On- und Offline-Gehen eine Veränderung des Routers voraussetzen. In einem Szenario, in dem sich die zu bedienenden Ziele häufig ändern, kann dies schnell zu einem Wartungsalbtraum werden. Damit der Dynamic Router funktioniert, hat er nicht nur mehrere Ausgänge; er ist auch eines der wenigen Patterns mit mehr als einem Eingang. Abbildung 3.17 zeigt einen Dynamic Router mit seinen Ein- und Ausgaben und Parametern. Die normale Ein- und Ausgabe eines Dynamic Routers ist jeweils eine Nachricht (siehe Kapitel Message Patterns 3.2.1). Da der Router die Nachricht lediglich weiterleiten soll ohne sie zu verändern, muss der Nachrichtentyp der Eingabe mit dem der Ausgabe übereinstimmen. Deshalb wird bei der Erstellung eines Dynamic Router der Nachrichtentyp festlegt. Zusätzlich zur normalen Eingabe benötigt der Dynamic Router noch eine Schnittstelle, um Control-Messages zu empfangen. Auch bei diesen handelt es sich um normale Nachrichten. Sie sind aber meist von einem anderen Typ als die oben erwähnten Nachrichten. Die über diese Schnittstelle empfangenen Nachrichten kommen von den potentiellen Diensten des Dynamic Routers. Sie beinhalten Anweisungen an den Router: Wird der mit dem Dienst verbundene Ausgang als Routingziel hinzu- oder weggenommen, und - bei einer Hinzunahme des Ausganges - die Routinglogik für den Ausgang. Für diese Control-Messages muss ebenfalls ein Nachrichtentyp angegeben werden. Der Router benötigt für die Speicherung der in den Control-Message vorhandenen Daten eine Regelbasis. Dies ist ebenfalls ein großer Unterschied im Vergleich zu anderen Patterns. In dieser Regelbasis steht die aktuelle Konfiguration der einzelnen Ausgänge, auf die sich der

46 46 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS Abbildung 3.17: Parametrisierung des Dynamic Routers

47 3.2. DIE PATTERNS 47 Router stützt. In manchen Fällen ist es sinnvoll, diese Regelbasis persistent zu machen, damit bei einem Systemabsturz die in der Regelbasis vorhandenen Daten nicht verloren gehen. Um mit dem Dynamic Router arbeiten zu können, muss wie beim Content-Based Router die Anzahl der Ausgänge n festgelegt werden. Es handelt sich hierbei um eine statische Zahl n, die zur Entwurfszeit festgelegt werden muss. Zu dieser Anzahl n kommt automatisch noch ein weiterer Ausgang dazu. Dieser Ausgang stellt den else-zweig dar. Dort werden die Nachrichten hingeschickt, die zu keinem der vorhandenen Ausgänge passen. Es kann eingestellt werden, ob dieser Ausgang auf empty gesetzt werden soll, oder ob der Ausgang genutzt werden soll. Wird der Ausgang auf empty gesetzt, so wird mit der Nachricht nichts gemacht und die Nachricht geht verloren. Die anderen n Ausgänge werden mit den potentiellen Channels des Routers verbunden. Ob diese freigeschaltet werden und mit welcher Routing-Logik, wird dynamisch über die Control-Messages bestimmt. Damit die angrenzenden Channel die richtige Nachricht bekommen, müssen die intern im Router angelegten Ausgänge noch auf die jeweiligen Channel gemappt werden. Man benötigt also eine Tabelle, die der Ausgangsnummer eine Channel-ID zuordnet. Diese Tabelle hilft gleichzeitig auch, nicht den Überblick zu verlieren. Da die Routing-Logik der jeweiligen Ausgänge dynamisch festgelegt wird, kann es vorkommen, dass sich die Logik zweier Ausgänge miteinander überschneidet. Für diesen Fall muss dem Dynamic Router eine Konfliktlösungsstrategie mitgeteilt werden. Laut Hohpe (siehe [2]) gibt es drei mögliche Lösungsstrategien für einen solchen Router: 1. alle Control-Messages, die mit der aktuellen Regelbasis kollidieren, werden ignoriert 2. die Nachricht wird an den ersten Ausgang geschickt, dessen Kriterien auf die Nachricht zutreffen 3. die Nachricht wird an alle Ausgänge geschickt, deren Kriterien auf die Nachricht zutreffen Eine der drei Strategien muss also bei Erstellung des Dynamic Routers in der Logik des Routers umgesetzt werden. Auch für die Befüllung der Regelbasis gibt es unterschiedliche Strategien: 1. bei Systemstart schickt jedes Ziel, das Nachrichten empfangen möchte, eine Control- Message an den Router 2. der Router schickt über einen zusätzlichen Publish-Subscribe-Channel (siehe Kapitel ) eine Aufforderung an alle Ziele, damit diese eine Control-Message schicken; in diesem Fall muss die Regelbasis nicht unbedingt persistent sein, da der Router nach einem Absturz erneut eine Aufforderung an die Ziele schicken kann 3. die Ziele können eigenständig Control-Messages an den Router schicken, mit denen sie sich in der Regelbasis anmelden oder von der Regelbasis abmelden Bei der Erstellung eines Dynamic Routers muss man sich ebenfalls für eine der drei Strategien entscheiden und diese dann in der Logik des Routers umsetzen. Die eigentliche Logik des Dynamic Routers setzt sich also aus der Regelbasis, der Strategie zur Befüllung der Regelbasis und der Konfliktlösungsstrategie zusammen.

48 48 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS BPEL und Web Services Für die Umsetzung des Dynamic Routers in BPEL muss die Regelbasis in einem Web Service gespeichert werden. Dieser Web Service muss eine Schnittstelle anbieten, über welche die Ziele ihre Control-Messages an den Web Service senden können. Der Web Service empfängt die Control-Messages und speichert die darin enthaltenen Daten. Bekommt der Router eine Nachricht, so schickt er diese an den Web Service, der dann mit Hilfe der Regelbasis bestimmt, an welchen Ausgang die Nachricht geschickt wird. Dieses Ergebnis wird dann an den BPEL-Prozess zurück geschickt, der daraufhin die Nachricht routet. Diese Möglichkeit erlaubt es nicht nur, die Regelbasis persistent zu gestalten, in dem der Web Service diese zum Beispiel in einer Datenbank abspeichert. Für den Empfang der Control- Messages reicht für den Web Service eine einzige Schnittstelle, unabhängig davon, wie viele Ausgänge der Router besitzt. Als Regelbasis-Strategie kommt hier nur die zweite Möglichkeit in Frage. Bekommt der Router eine Nachricht, so schickt er als erstes über eine Recipient List (Publish-Subscribe ist in BPEL nur eingeschränkt möglich) eine Aufforderung an alle seine Empfänger, so dass diese die Regelbasis auf den neuesten Stand bringen. Ist dies erledigt, kann der Router auf die Regelbasis zugreifen und die Nachricht dementsprechend routen. Die anderen beiden Möglichkeiten können in BPEL nicht umgesetzt werden, da die Ziele nicht gleich mit Arbeiten anfangen, wenn das System startet. Stattdessen werden sie nur ausgeführt, wenn sie explizit über einen aufgerufen werden. Handelt es sich bei den Zielen um externe Dienste, die unabhängig vom System laufen, so können auch die anderen beiden Möglichkeiten umgesetzt werden Recipient List Das Pattern Recipient List erlaubt, eine einzige Nachricht gezielt an mehrere bestimmte Empfänger zu verschicken. Im Gegensatz zum Publish-Subscribe Channel (siehe Kapitel ), bei dem der Sender nicht sicher sein kann, welcher Empfänger seine Nachricht erhält, kann er hier eine Liste der Empfänger angeben, welche die Nachricht bekommen sollen. Die Recipient List verhält sich analog zu einer . Auch hier gibt man jeden einzelnen Empfänger an. Man kann dadurch im Gegensatz zum Publish-Subscribe Channel sicher gehen, dass die Nachricht nicht in falsche Hände gerät. Wie bei einem Content-Based Router (siehe Kapitel ) besitzt die Recipient List für jeden potentiellen Empfänger einen Ausgang. Anstatt die Nachricht nun an nur einen Ausgang weiterzuleiten, wird anhand der Liste die Nachricht an alle Ausgänge geschickt, die in der Liste enthalten sind. Abbildung 3.18 zeigt eine Recipient List mit ihren Ein- und Ausgaben und Parametern. Die Ein- und Ausgabe einer Recipient List ist jeweils eine Nachricht (siehe Kapitel Message Patterns 3.2.1). Da die Recipient List die Nachricht lediglich weiterleiten soll ohne sie zu verändern, muss der Nachrichtentyp der Eingabe mit dem der Ausgabe übereinstimmen. Deshalb wird bei der Erstellung einer Recipient List der Nachrichtentyp festlegt. Um mit der Recipient List arbeiten zu können, muss zuerst einmal die Anzahl der Ausgänge n festgelegt werden. Es handelt sich hierbei um eine statische Zahl n, die zur Entwurfszeit festgelegt werden muss. An diese Ausgänge werden alle möglichen Empfängerchannel angehängt. Somit muss die Anzahl der Ausgänge mit der Anzahl aller möglichen Empfänger übereinstimmen.

49 3.2. DIE PATTERNS 49 Abbildung 3.18: Parametrisierung der Recipient List Damit die angrenzenden Channel die richtige Nachricht bekommen, müssen die intern in der Recipient List angelegten Ausgänge noch auf die jeweiligen Channel gemappt werden. Man benötigt also eine Tabelle, die der Ausgangsnummer eine Channel-ID zuordnet. Diese Tabelle hilft gleichzeitig auch, nicht den Überblick zu verlieren. Um für jede Nachricht zu bestimmen, an welche der Ausgänge sie gesendet werden soll, muss eine Liste der Empfänger berechnet werden. Hierfür gibt es laut Hohpe (siehe [2]) drei unterschiedliche Möglichkeiten: 1. die Liste ist bereits in der Nachricht enthalten und muss nur noch ausgelesen werden 2. die Liste befindet sich in einer externen Quelle und muss von dort abgefragt werden 3. die Liste wird anhand der in der Nachricht enthaltenen Daten selbst bestimmt Die Logik der Recipient List unterscheidet sich für alle drei Möglichkeiten und muss dementsprechend implementiert werden. Aber auch die Logik des Senders bzw. vorheriger Patterns muss angepasst werden, sollte man sich für Möglichkeit eins oder zwei entscheiden, da in diesem Fall die Liste der Empfänger bereits vor dem Pattern Recipient List erstellt werden muss. Dies kann zum Beispiel durch den Sender selbst geschehen oder durch ein Content Enricher Pattern (siehe Kapitel ).

50 50 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS BPEL und Web Services Die Umsetzung der Recipient List unterscheidet sich hauptsächlich durch die Wahl und Implementierung der oben genannten Logik. Hierfür können unterschiedliche Methoden angewendet werden. Im Bereich BPEL und Web Services bieten sich vor allem drei Alternativen an: 1. Routing durch BPEL Code 2. Routing durch einen Web Service Im ersten Fall wird die eingehende Nachricht über BPEL allein geroutet. Die Liste muss in diesem Fall entweder bereits in der Nachricht enthalten sein, oder sie wird anhand der Daten der Nachricht berechnet. Hierbei können allerdings keine komplexen Verfahren angewendet werden, da die Arbeit mit BPEL beschränkt ist. Bei der zweiten Möglichkeit wird die Nachricht durch einen Web Service geroutet. Bekommt die Recipient List eine Nachricht, so schickt sie diese an den Web Service, der dann entweder eine zuvor abgespeicherte Liste an den BPEL-Prozess zurück schickt oder dynamisch anhand der Daten der Nachricht den Empfänger berechnet Splitter Die Besonderheit des Splitters ist die Tatsache, dass der Splitter als Ausgabe mehr als nur eine Nachricht hat - und das auf dem selben Channel. Dies liegt daran, dass die Aufgabe des Splitters darin liegt, die eingehende Nachricht in kleinere Nachrichten aufzuteilen, die unabhängig voneinander verarbeitet werden können. Grund für eine solche Aufteilung kann zum Beispiel sein, dass der Inhalt der Nachricht von verschiedenen Diensten verarbeitet werden muss. Teilt man die Nachricht auf und verschickt die Einzelnachrichten hinterher mit einem Router parallel an die unterschiedlichen Dienste, spart man nicht nur Zeit, sondern geht auch sicher, dass jeder Dienst nur die Daten erhält, die ihn etwas angehen. Abbildung 3.19 zeigt einen Splitter mit seinen Ein- und Ausgaben und Parametern. Die Ein- und Ausgabe eines Splitters ist jeweils eine Nachricht (siehe Kapitel Message Patterns 3.2.1). Da der Splitter die Nachricht verändert, muss der Nachrichtentyp der Eingabe mit dem der Ausgabe nicht übereinstimmen. Trotzdem muss festgelegt sein, von welchem Typ die Ein- und Ausgaben sind. Im allgemeinen Fall des Patterns wäre es denkbar, dass die ausgehenden Nachrichten jeweils einen unterschiedlichen Typ besitzen. Im Hinblick auf die vorherrschende Aufgabe, in der es lediglich typgebundene Channels gibt, und unter Berücksichtigung der Tatsache, dass den Splitter nur ein Channel verlässt, müssen in diesem Fall alle ausgehenden Nachrichten vom selben Nachrichtentyp sein. Über den eigentlichen Inhalt ist damit aber nichts gesagt - dieser wird sich höchstwahrscheinlich immer unterscheiden; dies ist ja auch der Zweck des Splitters. Die restliche Parametrisierung des Splitter-Patterns ist recht simpel. Intern wird zwar zwischen iterativen und statischen Splittern unterschieden (siehe auch Hohpe [2] und Schebelle [1]), doch diese Unterscheidung bringt für die Parametrisierung keine weitere Neuerung. Beide Möglichkeiten verlangen eine Logik, die sich um die Aufteilung der eingehenden Nachricht kümmert. Ob diese Logik nun iterativ oder statisch vorgeht, ist von außen betrachtet irrelevant und liegt im Ermessen des Entwicklers.

51 3.2. DIE PATTERNS 51 Abbildung 3.19: Parametrisierung des Splitters BPEL und Web Services Die Umsetzung des Splitters unterscheidet sich hauptsächlich durch die Wahl und Implementierung der oben genannten Logik. Hierfür können unterschiedliche Methoden angewendet werden. Im Bereich BPEL und Web Services bieten sich vor allem drei Alternativen an: 1. Aufteilung durch BPEL Code 2. Aufteilung durch einen Web Service 3. Sammeln der Ausgangsnachrichten in einem Web Service Im ersten Fall wird die eingehende Nachricht über BPEL allein aufgeteilt. Dies ist laut Florian Schebelle mit BPEL 2.0 ausreichend. Falls man sich aber doch eingeschränkt fühlt, empfiehlt sich die zweite Möglichkeit. Im zweiten Fall wird der eigentliche Splitter als Web Service umgesetzt. Dabei wird in BPEL der Web Service aufgerufen, der dann die Nachricht aufteilt und durch einen invoke-aufruf ein Nachrichten-Array zurückgibt mit Nachrichten, die dann in BPEL weitergeleitet werden. Bei der dritten Möglichkeit handelt es sich um einen Spezialfall des ersten Falls. Wird die Nachricht in einer Schleife (zum Beispiel foreach) aufgeteilt, so überschreibt BPEL die Nachricht jedesmal (siehe [1]). Deswegen werden die neuen Nachrichten einem Web Service übergeben, der diese während der Erstellung weitere Teilnachrichten zwischenspeichert. Die Aufteilung erfolgt also in BPEL und die neuen Nachrichten werden in einem Web Service zwischengespeichert Aggregator Der Aggregator zeichnet sich durch eine besondere Eigenschaft aus: Er kann mehrere Channels als Eingang besitzen. Über diese Channels kann er von unterschiedlichen Diensten Nachrichten empfangen. Dabei ist es aber nicht nötig, dass pro Channel eine Nachricht empfangen

52 52 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS werden muss. Es ist auch denkbar, dass ein Channel eine oder mehrere Nachrichten schickt. Dies kommt auf die Implementierung des Channels an. Der Aggregator hat die Aufgabe, eingehende Nachrichten zu sammeln und bei Erfüllung einer gewissen Bedingung, eine Nachricht auf den Ausgangschannel zu legen. Bei dieser Nachricht kann es sich um eine Kombination der eingehenden Nachrichten handeln. Es kann aber auch einfach nur die beste Nachricht weitergeleitet werden. Abbildung 3.20 zeigt einen Aggregator mit seinen Ein- und Ausgaben und Parametern. Abbildung 3.20: Parametrisierung des Aggregators Die Ein- und Ausgabe eines Aggregators ist jeweils eine Nachricht (siehe Kapitel Message Patterns 3.2.1). Da der Aggregator die Nachricht verändert, muss der Nachrichtentyp der Eingabe mit dem der Ausgabe nicht übereinstimmen. Trotzdem muss festgelegt sein, von welchem Typ die Ein- und Ausgaben sind. Es ist möglich, dass die eingehenden Nachrichten jeweils einen unterschiedlichen Typ besitzen. Das muss dann aber pro Channel angegeben werden. Außerdem schränkt das die Arbeit mit dem Aggregator ein, da auch der Ausgangschannel typgebunden ist. Eine First-Best-Strategie oder ähnliches wie in Hohpe (siehe [2]) beschrieben, ist in diesem Fall nicht mehr möglich, da die Ausgabe auf einen bestimmten Nachrichtentyp beschränkt ist. Um mit dem Aggregator arbeiten zu können, muss zuerst einmal die Anzahl der Eingänge n festgelegt werden. Es handelt sich hierbei um eine statische Zahl n, die zur Entwurfszeit festgelegt werden muss. Es ist denkbar, dass n = 1 ist, wenn die Nachrichten von einem Sender kommen.

53 3.2. DIE PATTERNS 53 Für jeden Eingang muss der Nachrichtentyp der darauf eingehenden Nachricht angegeben werden. Damit die Nachrichten der angrenzenden Channel auf den richtigen Eingang geschickt werden, müssen die intern im Router angelegten Eingänge noch auf die jeweiligen Channel gemappt werden. Man benötigt also eine Tabelle, die der Eingangsnummer eine Channel-ID zuordnet. Diese Tabelle hilft gleichzeitig auch, nicht den Überblick zu verlieren. Das Entscheidende beim Aggregator ist die dahinter steckende Logik. Diese lässt sich der Übersicht halber in zwei Teile aufteilen: 1. Completeness Condition 2. Kombinationslogik Der erste Punkt legt die Strategie fest, mit der festgestellt wird, wann der Aggregator nicht mehr auf neue Nachrichten warten muss und eine Nachricht schicken kann. Gregor Hohpe beschreibt dafür fünf Strategien, die in [2] nachzulesen sind. Möglich wäre es zum Beispiel, lediglich auf die erste Nachricht zu warten. In manchen Fällen muss aber auch auf Antwort von allen Channeln gewartet werden. Der zweite Punkt ist eng mit dem ersten verbunden. Er beschreibt, wie die gesammelten Nachrichten nach Erfüllung der Completeness Condition aggregiert werden. Hohpe beschreibt auch dafür drei Strategien. Wurde zum Beispiel lediglich auf die erste Nachricht gewartet, so macht es Sinn, diese als Ergebnis weiterzuleiten. Hat man mehrere Nachrichten angesammelt, kann man die Inhalte der Nachrichten in eine einzige Nachricht kopieren. Diese Logik ist sehr fallspezifisch und kann daher nicht durch einfache Parameter beschrieben werden. Sie muss individuell implementiert werden. Es ist auch möglich, den zweiten Eingang (siehe Abbildung 3.20) zu nutzen. Über diesen kann vorab an den Aggregator eine Control-Message verschickt werden. Dafür muss natürlich der Nachrichtentyp dieser Control-Message angegeben werden. Eine solche Nachricht kann dann Daten enthalten, welche die oben genannte Logik beeinflusst, wie zum Beispiel Schwellenwerte für die Completeness Condition. BPEL und Web Services Die Umsetzung des Aggregators unterscheidet sich hauptsächlich durch die Wahl und Implementierung der oben genannten Logik. Hierfür können unterschiedliche Methoden angewendet werden. Im Bereich BPEL und Web Services bieten sich vor allem drei Alternativen an: 1. Aggregation durch BPEL 2. Aggregation durch einen Web Service 3. Speicherung mit Hilfe eines Web Services

54 54 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS Im ersten Fall werden die eingehenden Nachrichten in BPEL gesammelt und aggregiert. Im zweiten Fall wird der eigentliche Aggregator als Web Service umgesetzt. Dabei wird in BPEL für jede Nachricht der Web Service aufgerufen, der dann die Nachrichten sammelt und aggregiert. Der Web Service gibt durch einen invoke-aufruf die aggregierte Nachricht zurück, die von BPEL dann weitergeleitet wird. Eine dritte Möglichkeit wäre, die Nachrichten einem Web Service zu übergeben, der diese während der Ansammlung weiterer Nachrichten zwischenspeichert. Die Aggregation erfolgt also in BPEL und die eingehenden Nachrichten werden in einem Web Service zwischengespeichert. Dies ist dann hilfreich, wenn die Nachrichten im Aggregator in einer Schleife (zum Beispiel foreach) empfangen werden und sich gegenseitig überschreiben. Sollen Control Messages empfangen werden, so werden diese über einen Datatype Channel zwischen Sender (zum Beispiel ein Splitter) und Aggregator gesendet. In diesem Fall beginnt der Aggregator seine Arbeit mit der Auswertung der Control Message. Ist der Eingang des Aggregators mit einem generischem Empfänger (siehe Kapitel ) verbunden, so muss damit gerechnet werden, dass über diesen Eingang mehrere Nachrichten empfangen werden. Eine Möglichkeit, damit umzugehen, wäre, den generischen Empfänger und einen Teil des Aggregators in einer Schleife zu verbinden. Bekommt der generische Empfänger eine Antwort, so leitet er diese an den Aggregator weiter, die die Nachricht einem Web Service zur Speicherung übergibt. Danach beginnt die Schleife von vorne und der generische Empfänger kann eine weitere Nachricht empfangen. Wann der Aggregator aufhört zu lauschen, wird durch die Completeness Condition festgelegt. Am Ende der Lauschzeit ruft der Aggregator den Web Service erneut auf, der entweder ein Array der gesammelten Nachrichten zurückgibt, so dass der Aggregator die Nachrichten in BPEL aggregieren kann (es handelt sich dabei um die dritte oben aufgelistete Möglichkeit), oder die bereits aggregierte Nachricht zurückgibt (das wäre dann Möglichkeit zwei) Resequencer Der Resequencer wird genau dann benutzt, wenn es für die nachfolgenden Ziele wichtig ist, die Nachrichten in der richtigen Reihenfolge zu erhalten. Obwohl der Sender die Nachrichten in der richtigen Reihenfolge abschickt, kann es vorkommen, dass die Nachrichten auf ihrem Weg durch das Messagingsystem durcheinanderkommen. Dies liegt an der asynchronen Verarbeitung der Nachrichten. Dabei kann es passieren, dass eine spätere Nachricht schneller bearbeitet und weitergeleitet wird, als eine frühere Nachricht. Dies tritt vor allem dann auf, wenn die einzelnen Nachrichten unterschiedliche Wege gehen. Um diese Nachrichten wieder in die richtige Reihenfolge zu bringen, fängt der Resequencer sie auf und schickt sie in der richtigen Reihenfolge weiter. Abbildung 3.21 zeigt einen Resequencer mit seinen Ein- und Ausgaben und Parametern. Die Ein- und Ausgabe eines Resequencers ist jeweils eine Nachricht (siehe Kapitel Message Patterns 3.2.1). Da der Resequencer die Nachricht lediglich weiterleiten soll ohne sie zu verändern, muss der Nachrichtentyp der Eingabe mit dem der Ausgabe übereinstimmen. Deshalb wird bei der Erstellung eines Resequencers der Nachrichtentyp festlegt.

55 3.2. DIE PATTERNS 55 Abbildung 3.21: Parametrisierung des Resequencers Der Resequencer selbst muss nur wenig personalisiert werden. Seine Aufgabe, und somit auch seine Logik ist in jedem Fall dieselbe: Anhand des Message Sequence Identifiers in der ankommenden Nachricht erkennt der Resequencer, welche Position die Nachricht hat. Hat der Resequencer also zum Beispiel bereits die Nachrichten der Position 1 bis 3 verschickt, und es erreicht ihn die Nachricht mit der Position 4, so kann er diese sofort weiter auf den Channel schicken. Hat die Nachricht aber die Position 5, so muss diese Nachricht zwischengespeichert werden, bis Nachricht Nr. 4 eintrifft. Ist die vierte Nachricht verschickt, kann auch Nachricht Nr. 5 verschickt werden. Der Resequencer muss also manche Nachrichten in seinem Puffer halten. Dieser ist natürlich nicht beliebig groß. Die Größe muss bei Erstellung des Resequencers angegeben werden. Um einen Pufferüberlauf zu vermeiden, kann man den Resequencer so gestalten, dass er regelmäßig eine Control-Message an den Sender verschickt, in der er diesem mitteilt, wieviel Platz sein Puffer noch zur Verfügung hat. Mit diesem Wissen kann der Sender dann höchstens die Anzahl von Messages verschicken. Somit wird vermieden, dass Nachrichten beim Resequencer ankommen, ohne dass Platz dafür ist. Möchte man diese Möglichkeit nutzen, so muss man natürlich auch noch den Nachrichtentyp der Control-Message angeben. BPEL und Web Services Wenn aus dem System ersichtlich ist, dass pro Instanz des BPEL-Prozesses nur eine Nachricht an den Resequencer geschickt wird, diese Nachrichten aber Instanz-übergreifend in der richtigen Reihenfolge verschickt werden müssen, muss ein externer Web Service dafür sorgen, dass die Nachrichten in der richtigen Reihenfolge verschickt werden. Dieser Web Service merkt sich die bereits verschickten Nummern. Bekommt der Resequencer eine Nachricht, so frägt er beim Web Service nach, ob die aktuelle Nachricht verschickt werden darf. Wenn ja, so speichert der Web Service die Nummer der neuen Nachricht ab und gibt dem Resequencer sein OK. Daraufhin kann der Resequencer die Nachricht weiterleiten. Stellt der Web Service fest, dass die aktuelle Nachricht noch nicht verschickt

56 56 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS werden darf, so muss der Resequencer eine gewisse Zeit warten, um dann den Web Service erneut zu fragen. Ein Puffer ist in diesem Fall nicht nötig, da jede Instanz nur eine Nachricht speichert. Deswegen ist es auch nicht nötig, dass der Resequencer Control Messages verschickt. Wenn der Resequencer innerhalb eines BPEL-Prozesses allerdings mehrere Nachrichten bekommen kann, so benötigt der Resequencer einen Puffer. Er könnte sich hierbei wie bei der obigen Möglichkeit eines Web Services bedienen, an den er alle Nachrichten verschickt und der diese zwischenspeichert. Der Web Service gibt dann die Nachrichten zurück, die verschickt werden können. Hierbei handelt es sich allerdings noch um keine ausgereifte Idee. Es ist zu beachten, dass die Nachrichten bereits nach dem nächsten Filter wieder aus der Reihenfolge sein können. Der Resequencer lohnt sich also nur an den Stellen im Prozess, an denen ein Filter folgt, der die Nachrichten unbedingt in der richtigen Reihenfolge benötigt. Gibt es mehrere solcher Filter in einem Prozess, so sollte vor jedem Filter ein Resequencer gesetzt werden Message Transformation Message Translator Die eingehende Nachricht unterscheidet sich beim Message Translator grundsätzlich immer von der ausgehenden Nachricht. Allerdings kommt es auf die Logik des Translators an, in wiefern sich die beiden Nachrichten voneinander unterscheiden. In manchen Fällen stimmen die Nachrichtentypen miteinander überein, lediglich der Inhalt ändert sich. In den meisten Fällen aber verlässt den Translator eine Nachricht eines anderen Types. Abbildung 3.22 zeigt einen Message Translator mit seinen Ein- und Ausgaben und Parametern. Abbildung 3.22: Parametrisierung des Message Translators

57 3.2. DIE PATTERNS 57 Die Ein- und Ausgabe eines Message Translators ist jeweils eine Nachricht (siehe Kapitel Message Patterns 3.2.1). Da der Translator die Nachricht verändert, muss der Nachrichtentyp der Eingabe mit dem der Ausgabe nicht übereinstimmen. Trotzdem muss festgelegt sein, von welchem Typ die Ein- und Ausgaben sind. Als weiteren Parameter benötigt der Translator lediglich noch eine Transformationslogik. BPEL und Web Services Die Umsetzung des Message Translators unterscheidet sich hauptsächlich durch die Wahl und Implementierung der Transformationslogik. Hierfür können unterschiedliche Methoden angewendet werden. Im Bereich BPEL und Web Services bieten sich vor allem drei Alternativen an: 1. Transformation durch BPEL Code 2. Transformation durch einen Web Service 3. Transformation durch XSL-T Im ersten Fall wird die eingehende Nachricht über BPEL durch einfache assign-anweisungen transformiert. Hierbei können allerdings keine komplexen Verfahren angewendet werden, da die Arbeit mit BPEL beschränkt ist. Bei der zweiten Möglichkeit wird der eigentliche Translator als Web Service umgesetzt. Dabei wird in BPEL der Web Service aufgerufen, der dann die Nachricht umwandelt. Der Web Service gibt durch einen invoke-aufruf die transformierte Nachricht zurück, die dann in BPEL weitergeleitet wird. Die dritte Möglichkeit bietet ein Standard, um ein XML-Dokument (in diesem Fall eine Nachricht) in ein anderes XML-Dokument zu transformieren (siehe auch [21]). Dieser Standard wird mittlerweile auch von graphischen Tools unterstützt, so dass man die eingehende Nachricht graphisch auf die ausgehende Nachricht mappen kann. Die Transformation selbst wird in einer XSLT-Datei definiert, die also entweder manuell, oder über ein graphisches Werkzeug erstellt wird. In BPEL lässt sich die Transformation dann durch die Funktion doxsltransform aufrufen. Diese muss wie in Möglichkeit 1 in eine assign-anweisung gepackt werden, die das Ergebnis der Funktion auf eine Variable kopiert Content Filter Der Content Filter ähnelt dem Message Translator (siehe Kapitel ). Auch hier unterscheidet sich die ausgehende Nachricht von der eingehenden Nachricht. Allerdings muss sich dabei nicht unbedingt der Nachrichtentyp verändern. Vielmehr ist der Content Filter eine Spezialisierung des Message Translators, der sein Hauptaugenmerk auf die Vereinfachung der eingehenden Nachricht legt. Diese Vereinfachung kann zum Beispiel darin bestehen, dass sicherheitskritische Daten aus der Nachricht entfernt werden. Es ist aber auch möglich, die Nachrichtenstruktur zu vereinfachen, in dem zum Beispiel wichtige, tief geschachtelte Daten

58 58 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS Abbildung 3.23: Parametrisierung des Content Filters auf oberste Ebene kopiert werden und unwichtige Daten weggelassen werden. Abbildung 3.23 zeigt einen Content Filter mit seinen Ein- und Ausgaben und Parametern. Die Ein- und Ausgabe eines Content Filters ist jeweils eine Nachricht (siehe Kapitel Message Patterns 3.2.1). Da der Filter die Nachricht verändert, muss der Nachrichtentyp der Eingabe mit dem der Ausgabe nicht übereinstimmen. Trotzdem muss festgelegt sein, von welchem Typ die Ein- und Ausgaben sind. Als weiteren Parameter benötigt der Filter lediglich noch eine Filterlogik. Diese ähnelt der Transformationslogik eines Message Translators. Wie oben erwähnt ist hier der Freiheitsgrad der Logik eingeschränkter. Die Aufgabe eines Content Filters ist die Vereinfachung einer Nachricht, während der Message Translator zwischen zwei unterschiedlichen Nachrichtentypen vermittelt und somit zwei nicht kompatible Dienst miteinander kompatibel gestaltet. Da die Logik allerdings auf den speziellen Fall angepasst werden muss und sich von der Art des Nachrichtensystems unterscheidet, sind die Parameter beider Patterns identisch. Florian Schebelle bezweifelt in seiner Arbeit (siehe [1]) den Sinn einer komplexen Nachrichtentransformation (wie zum Beispiel die Restrukturierung einer Nachricht) in einem Content Filter. Diese Funktionalität eines Content Filters ist allerdings bei Gregor Hohpe (siehe [2]) mit aufgelistet. Somit ist es generell möglich, den Content Filter dafür einzusetzen. Dies bietet sich an, wenn zusätzlich zur Transformation auch Daten aus der Nachricht gefiltert werden sollen. Wird die Nachricht lediglich transformiert, so ist der Content Filter meiner Meinung nach das falsche Pattern, auch wenn die Restrukturierung zu einer Vereinfachung führt. Hier macht in der Tat der Message Translator mehr Sinn. Für die Behandlung einer Transformation inklusive Filterung gibt es also zwei Möglichkeiten: 1. die komplette Logik wird durch einen Content Filter umgesetzt: Dies hat möglicherweise zur Folge, dass die Logik des Filters recht komplex wird. Wartungsarbeiten können dadurch erschwert werden und auch die Fehlerwahrscheinlichkeit erhöht sich dadurch.

59 3.2. DIE PATTERNS die Logik wird auf einen Content Filter und einen nachfolgenden Message Translator aufgeteilt: Dadurch lässt sich eine schöne Trennung der Filterung und der Transformation herbeiführen. Dies führt zu einer besseren Übersichtlichkeit. Allerdings macht diese Trennung nicht immer Sinn, da in manchen Fällen beide Verfahren so eng miteinander verknüpft sind, so dass bei der Änderung des einen Verfahrens, automatisch auch das andere Verfahren angepasst werden muss. Möglicherweise ist eine Trennung auch erst gar nicht möglich. BPEL und Web Services Die Umsetzung des Content Filters unterscheidet sich hauptsächlich durch die Wahl und Implementierung der Filterlogik. Hierfür können unterschiedliche Methoden angewendet werden. Im Bereich BPEL und Web Services bieten sich vor allem drei Alternativen an: 1. Filtern durch BPEL Code 2. Filtern durch einen Web Service 3. Filtern durch XSL-T Im ersten Fall werden die benötigten Daten der eingehende Nachricht über BPEL durch einfache assign-anweisungen auf die ausgehende Nachricht kopiert. Dies ist im Falle des Content Filters die einfachste und praktischste Möglichkeit, wenn sich die beiden Nachrichtentypen nicht stark voneinander unterscheiden. Die nicht benötigten Daten werden nicht kopiert und fallen somit weg. Bei der zweiten Möglichkeit wird der eigentliche Filter als Web Service umgesetzt. Dabei wird in BPEL der Web Service aufgerufen, der dann die Nachricht filtert und umwandelt. Der Web Service gibt durch einen invoke-aufruf die gefilterte Nachricht zurück, die dann in BPEL weitergeleitet wird. Die dritte Möglichkeit bietet ein Standard, um ein XML-Dokument (in diesem Fall eine Nachricht) in ein anderes XML-Dokument zu transformieren (siehe auch [21]). Dieser Standard wird mittlerweile auch von graphischen Tools unterstützt, so dass man die eingehende Nachricht graphisch auf die ausgehende Nachricht mappen kann. Die Transformation selbst wird in einer XSLT-Datei definiert, die also entweder manuell, oder über ein graphisches Werkzeug erstellt wird. In BPEL lässt sich die Transformation dann durch die Funktion doxsltransform aufrufen. Diese muss wie in Möglichkeit 1 in eine assign-anweisung gepackt werden, die das Ergebnis der Funktion auf eine Variable kopiert. Die letzten beiden Möglichkeiten machen nur Sinn, wenn zusätzlich zur einfachen Filterung auch noch eine Nachrichtentransformation durchgeführt werden soll, d.h. wenn der eingehende Nachrichtentyp auf einen sich unterscheidenden ausgehenden Nachrichtentyp gemappt werden soll.

60 60 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS Content Enricher Der Content Enricher stellt das Gegenstück zum Content Filter (siehe Kapitel ) dar. Hierbei sollen also nicht Informationen aus einer Nachricht entfernt, sondern fehlende Informationen einer Nachricht hinzugefügt werden. Somit unterscheidet sich der Content Enricher auch vom Message Translator (siehe Kapitel ). Der Message Translator ist lediglich dafür da, die bereits vorhandenen Informationen in einer Nachricht neu zu strukturieren. Der Content Enricher muss dazu noch neue Informationen besorgen und hinzufügen. Dafür muss die eingehende Nachricht in den meisten Fällen Daten enthalten, mit denen die gewünschten Informationen gefunden werden können, wie z.b. eine ID. Der Content Enricher kontaktiert mit diesen Schlüsseldaten eine externe Quelle und fordert davon die Informationen an. Diese werden der eingehenden Nachricht hinzugefügt. Die Schlüsseldaten können gleichzeitig aus der Nachricht entfernt werden, wenn sie nicht mehr benötigt werden. Durch dieses Vorgehen kann sich der Nachrichtentyp verändern. Es gehört aber nicht zur eigentlichen Aufgabe des Content Enrichers, eine Nachricht zu transformieren. Dafür sind der Message Translator und bedingt der Content Filter zuständig. Abbildung 3.24 zeigt einen Content Filter mit seinen Ein- und Ausgaben und Parametern. Abbildung 3.24: Parametrisierung des Content Enrichers Die Ein- und Ausgabe eines Content Enrichers ist jeweils eine Nachricht (siehe Kapitel Message Patterns 3.2.1). Da der Enricher die Nachricht verändert, muss der Nachrichtentyp der Eingabe mit dem der Ausgabe nicht übereinstimmen. Trotzdem muss festgelegt sein, von welchem Typ die Ein- und Ausgaben sind. Als weiteren Parameter benötigt der Enricher lediglich noch eine Anreicherungslogik. Diese Logik muss festlegen, wie die neuen Informationen bestimmt werden, wie diese der Nachricht hinzugefügt, und ob die Schlüsseldaten aus der Nachricht entfernt werden müssen. Da die Logik auf den speziellen Fall angepasst werden muss und sich von der Art des Nachrichtensystems unterscheidet, lässt sich dieser Punkt nicht genauer bestimmen.

61 3.2. DIE PATTERNS 61 BPEL und Web Services Die Umsetzung des Content Enrichers unterscheidet sich hauptsächlich durch die Wahl und Implementierung der Anreicherungslogik. Hierfür können unterschiedliche Methoden angewendet werden. Im Bereich BPEL und Web Services bieten sich vor allem drei Alternativen an: 1. Anreichern durch BPEL Code 2. Anreichern durch einen Web Service 3. Anreichern mit Daten eines Web Services Im ersten Fall müssen die hinzuzufügenden Daten bereits in BPEL Variablen gespeichert sein. Die Schlüsseldaten der eingehenden Nachricht können dann durch eine Fallbedingte Untersuchung dazu beitragen, die neuen Daten aus einer Menge von Daten auszuwählen. Diese Daten werden dann zusammen mit den benötigten Daten der eingehenden Nachricht durch assign-anweisungen auf die ausgehende Nachricht kopiert. Dies ist eine sehr einfache Umsetzung eines Content Enrichers. Da die neuen Daten allerdings fest in BPEL codiert sein müssen, lassen sich hier nur statische Anreicherungen durchführen. Dies ist nur in den wenigsten Fällen ausreichend. Bei der zweiten Möglichkeit wird der eigentliche Enricher als Web Service umgesetzt. Dabei wird in BPEL der Web Service aufgerufen, der dann die Nachricht anreichert und umwandelt. Der Web Service gibt durch einen invoke-aufruf die angereicherte Nachricht zurück, die dann in BPEL weitergeleitet wird. Die dritte Möglichkeit arbeitet ebenfalls mit einem Web Service, lässt diesen aber die Nachricht nicht verarbeiten. Es handelt sich um eine Kombination der ersten beiden Möglichkeiten. Die Schlüsseldaten der Nachricht oder die Nachricht selbst werden an einen Web Service weitergeleitet. Der Web Service findet daraufhin die neuen Daten und gibt diese an den BPEL Prozess zurück. Der BPEL Prozess fügt dann die Daten in die Nachricht ein und entfernt gegebenenfalls die Schlüsseldaten. Dies geschieht am besten mit Hilfe der in Kapitel beschriebenen Funktion doxsltransform. Der Vorteil dieser Möglichkeit ist, dass man sowohl dynamische Daten der Nachricht hinzufügen kann (im Gegensatz zu Möglichkeit 1), und der verwendete Web Service nicht mit dem Nachrichtentyp umgehen muss (im Gegensatz zu Möglichkeit 2). Es ist z.b. möglich, dem Web Service eine Kundennummer zu übergeben, der dann in einer Datenbank nach der Adresse des Kunden sucht und diese an den BPEL Prozess zurück gibt. Dadurch kann der Web Service auch von anderen Diensten verwendet werden, da er nicht eng gekoppelt ist Claim Check Das Claim Check Pattern stellt eine Erweiterung zum Content Filter (siehe Kapitel ) dar und bietet in Kombination mit dem Content Enricher (siehe Kapitel ) eine Möglichkeit, Daten temporär aus einer Nachricht zu entfernen, um diese später wieder hinzuzufügen. Somit gehen die entfernten Daten nicht verloren. Dadurch lassen sich sicherheitskritische

62 62 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS Abbildung 3.25: Parametrisierung des Claim Checks Daten vor externen Diensten verstecken, die Performance wird verbessert, und auch das Debuggen wird leichter, da weniger Fehlerquellen vorhanden sind. Abbildung 3.25 zeigt einen Claim Check mit seinen Ein- und Ausgaben und Parametern. Die Ein- und Ausgabe eines Claim Checks ist jeweils eine Nachricht (siehe Kapitel Message Patterns 3.2.1). Da der Claim Check die Nachricht verändert, muss der Nachrichtentyp der Eingabe mit dem der Ausgabe nicht übereinstimmen. Trotzdem muss festgelegt sein, von welchem Typ die Ein- und Ausgaben sind. Wie der Content Filter benötigt der Claim Check noch eine Filterlogik. Der einzige Unterschied besteht darin, dass die gelöschten Daten nicht verschwinden. Für diese wird ein eindeutiger Schlüssel generiert. Unter diesem Schlüssel werden die Daten abgespeichert. Der Schlüssel wird dann der gefilterten Nachricht hinzugefügt. Ein Content Enricher kann dann mit diesem Schlüssel die gelöschten Daten wiederherstellen. Da der Claim Check eine Erweiterung des Content Filter ist, gelten hier die gleichen Bedingungen und Voraussetzungen, nachzulesen in Kapitel BPEL und Web Services Die Umsetzung des Claim Checks unterscheidet sich hauptsächlich durch die Wahl und Implementierung der Filterlogik. Hierfür können unterschiedliche Methoden angewendet werden. Im Bereich BPEL und Web Services bieten sich vor allem drei Alternativen an: 1. Zwischenlagern im BPEL Code 2. Zwischenlagern durch einen Web Service 3. Speichern über einen Web Service

63 3.2. DIE PATTERNS 63 Im ersten Fall werden die benötigten Daten der eingehenden Nachricht über BPEL durch einfache assign-anweisungen auf die ausgehende Nachricht kopiert. Dies ist im Falle des Content Filters die einfachste und praktischste Möglichkeit, wenn sich die beiden Nachrichtentypen nicht stark voneinander unterscheiden. Die original Nachricht wird in einer Variablen abgespeichert. Der später folgende Content Enricher kann dann auf diese Variable wieder zugreifen. Dies funktioniert aber nur im aktuellen BPEL-Prozess, da die gefilterten Daten nicht persistent gemacht werden. Bei der zweiten Möglichkeit wird der eigentliche Claim Check als Web Service umgesetzt. Dabei wird in BPEL der Web Service aufgerufen, der dann die Nachricht filtert, umwandelt, einen Schlüssel hinzufügt und die original Nachricht in einer Datenbank abspeichert. Der Web Service gibt durch einen invoke-aufruf die gefilterte Nachricht zurück, die dann in BPEL weitergeleitet wird. Da die Daten durch den Web Service in eine Datenbank geschrieben werden, sind diese persistent und können auch von anderen Diensten, die den Schlüssel kennen, wiedergewonnen werden. Der später folgende Content Enricher muss dann ebenfalls über einen Web Service auf die hinterlegten Daten zugreifen. Die in Kapitel beschriebene dritte Möglichkeit mit XSL-T ist hier nicht möglich, da eine Speicherung der Daten über XSL-T nicht gegeben ist. Denkbar wäre höchstens eine Kombination aus der ersten bzw. zweiten und dritten Möglichkeit, bei der die zu entfernenden Daten zuerst gespeichert werden, und dann die Nachricht durch XSL-T restrukturiert wird. Dafür gibt es hier eine weitere Möglichkeit, die sich aus einer Mischung der ersten beiden Möglichkeiten zusammengesetzt. Dabei wird wie in Möglichkeit 1 in BPEL die gefilterte Nachricht zusammengestellt und verschickt. Die original Nachricht wird allerdings nicht in BPEL gespeichert, sondern einem Web Service übergeben, der die Nachricht wie in Möglichkeit 2 abspeichert Patterns zur Unterstützung der Modellierung Um mithilfe von Patterns einen BPEL Prozess graphisch abbilden zu können, benötigt man noch weitere Patterns, die z.b. externe Dienste darstellen. Diese Patterns werden nachfolgend kurz beschrieben External Service Möchte man einen externen Dienst, also einen Web Service, ansprechen, dessen Funktion mit keinem der oben genannten Patterns übereinstimmt, so benutzt man dieses Pattern. Soll es sich dabei um einen asynchronen Aufruf handeln, so benutzt man am besten zwei externe Services: der erste verschickt die Nachricht; danach können weitere Patterns folgen, die in der Wartezeit andere Aufgaben erfüllen; der zweite externe Service empfängt dann die Antwort. Abbildung 3.26 zeigt einen Web Service mit seinen Ein- und Ausgaben und Parametern. Die Ein- und Ausgabe eines externen Services ist jeweils eine Nachricht (siehe Kapitel Message Patterns 3.2.1). Da der externe Service die Nachricht verändern kann, muss der Nachrichtentyp der Eingabe mit dem der Ausgabe nicht übereinstimmen. Trotzdem muss festgelegt sein, von welchem Typ die Ein- und Ausgaben sind.

64 64 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS Abbildung 3.26: Parametrisierung des External Services Für den Prozess ist es wichtig zu wissen, ob eine Nachricht zum Web Service geschickt werden soll, oder ob eine Nachricht vom Web Service in den BPEL-Prozess stößt, oder ob der Web Service angesprochen wird und eine Antwort sendet. Dementsprechend verändern sich Ein- und Ausgaben. Die Art der Ein- und Ausgabe (nämlich eine Nachricht) bleibt dabei immer gleich. Falls eine Ein- bzw. Ausgabe vorhanden ist, so muss zusätzlich auch noch der Nachrichtentyp angegeben werden. Diese Angaben sind wichtig, um die Kompatibilität mit anderen Patterns zu überprüfen. Die Richtigkeit der Angaben über den Web Service bleibt allerdings dem Benutzer überlassen. Damit der externe Service angesprochen werden kann, muss die logische Adresse und die Aufrufart festgelegt werden. BPEL und Web Services In BPEL wird das Pattern als PartnerLink und dem dazugehörigen Aufruf umgesetzt. Die logische Adresse ist also der PartnerLink. Für den Aufruf selbst muss die Operation und der Porttype angegeben werden. Außerdem muss angegeben werden, welche Aufrufart (invoke, reply, receive oder pick) verwendet werden soll. Dabei sollten die passenden Ein- bzw. Ausgänge für die jeweilige Aufrufart existieren (d.h. ein reply-aufruf benötigt zum Beispiel einen Eingang, ein receive-aufruf einen Ausgang, etc.) Dependency Channel Besteht eine Abhängigkeit zwischen zwei Patterns, die besagt, dass das zweite Pattern erst nach dem ersten ausgeführt werden soll, bei der aber keine Nachricht von dem einen zum anderen Pattern fließt, so kann man das Pattern Dependency Channel anstatt eines normalen Channels verwenden. Abbildung 3.27 zeigt einen Dependency Channel mit seinen Ein- und Ausgaben und Parametern.

65 3.3. KOMBINATION DER PATTERNS 65 Abbildung 3.27: Parametrisierung des Dependency Channels Der Dependency Channel besitzt keinerlei Ein- bzw. Ausgaben. Er kann also auch nur an Patterns gesetzt werden, die keine Ausgabe haben bzw. keine Eingabe erwarten (wie zum Beispiel ein External Service). Alternativ kann man den Channel auch als Zusatzein-/ausgang zwischen zwei Filtern setzen. Da keine Nachricht verschickt wird, benötigten die Patterns auch keinen nachrichtenverarbeitenden Ein- bzw. Ausgang. Der Channel benötigt auch keine Parameter. Seine Aufgabe ist lediglich, eine Verbindung zwischen den beiden Patterns herzustellen. BPEL und Web Services Der Dependency Channel wird wie alle Channel in BPEL als Link in einem Flow-Konstrukt umgesetzt. Der Unterschied besteht darin, dass bei der Erstellung des Channels keine Angabe über die zu versendende Nachricht gemacht werden muss. Da nichts verschickt wird, müssen auch keinerlei Quality of Services berücksichtigt werden. 3.3 Kombination der Patterns Grundsätzlich lassen sich alle Patterns miteinander kombinieren, deren Ausgabe mit der Eingabe des nachfolgenden Patterns übereinstimmt. Man könnte also nach einem Message Translator direkt einen Content-Based Router setzen. Dies widerspricht allerdings dem generellen Messagingpattern Pipes und Filters, das besagt, dass sich sogenannte Pipes (in unserem Fall Message Channel Patterns) und Filters (in unserem Fall gehören dazu Message Transformation Patterns, der External Service und Message Routing Patterns) abwechseln sollen. Der Vorteil dabei ist, dass man den Partner am einen Ende eines Channels austauschen kann, ohne dass der Partner am anderen Ende des Channels verändert werden muss. Dieser Architekturstil soll hier beibehalten werden. Außerdem muss jedem Channel (außer dem Dependency Channel) ein Message Pattern zugeordnet sein. Es gibt aber auch noch andere Arten von Kombinationen zwischen Patterns. Diese Kombinationsmöglichkeiten beziehen sich nicht auf eine sequentielle Kombination von Patterns, sondern auf eine Parallele, d.h. mehrere Patterns treten gleichzeitig in Kraft. So kann man zum Beispiel einen Filter mit einem Message Endpoint kombinieren. Man kann auch mehrere Message Endpoints dazu fügen, muss aber dann beachten, dass sich die Message Endpoints nicht untereinander ausschließen und dass jedes der Endpoint Patterns zum Filter passt. Genauso kann man einen Channel mit anderen Channel Patterns erweitern. Diese fügen dem Channel entweder weitere Eigenschaften hinzu, oder schließen sich als Extra-Channel an diesen an. Hat man einen Filter mit einem oder mehreren Message Endpoint Patterns, so

66 66 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS muss man auch überprüfen, ob die Endpoint Patterns zu dem nachfolgenden oder vorherigen Channel passen. Die unterschiedlichen Kombinationsarten werden in dem nachfolgenden Unterkapitel (siehe Kapitel 3.3.1) genauer beschrieben. Hier werden auch alle nicht möglichen Kombinationen zwischen den Patterns besprochen. Ein weiteres Unterkapitel behandelt die zwei Patterns Composed Message Processor (siehe Kapitel ) und Scatter Gather (siehe Kapitel ). Diese Patterns sind jeweils eine Kombination der im oberen Kapitel besprochenen Patterns. Sie können nicht nur beispielhaft zeigen, wie Patterns kombiniert werden können, sondern sind auch sehr hilfreiche Patterns, die man als eigenen Baustein in einem Patternablauf benutzen kann Patternarten kombinieren Message Endpoint/Message Endpoint Idempotent Receiver Der Idempotent Receiver kann mit allen anderen Endpoint Patterns kombiniert werden. [2] Transactional Client Benutzt man das Pattern Transactional Client, so sollte man weder gleichzeitig das Pattern Message Dispatcher, noch das Pattern Competing Consumer verwenden, da hier Probleme auftreten können. [2] Dies liegt daran, dass in beiden Fällen die Nachricht von mehr als einer Instanz gelesen wird. Beim Message Dispatcher holt der Dispatcher die Nachricht vom Channel und übergibt sie dann einem Receiver. Die Transaktion müsste sich in diesem Fall sowohl über den Dispatcher als auch über den Receiver erstrecken. Bei den Competing Consumers lesen mehrere Receiver gleichzeitig die Nachricht. Dies kann hohen Aufwand verursachen, da alle Receiver bis auf einen ein Rollback durchführen müssen. Durable Subscriber kombiniert werden. [2] Der Durable Subscriber kann mit allen anderen Endpoint Patterns Competing Consumers Eine Kombination der Competing Consumers mit einem Transactional Client ist nicht sinnvoll. [2] Es lesen mehrere Receiver gleichzeitig die Nachricht. Dies kann hohen Aufwand verursachen, da alle Receiver bis auf einen ein Rollback durchführen müssen. Message Dispatcher Die Kombination des Patterns mit einem Transactional Client kann sich als schwierig erweisen. [2] Der Dispatcher holt die Nachricht vom Channel und übergibt sie dann einem Receiver. Die Transaktion müsste sich in diesem Fall sowohl über den Dispatcher als auch über den Receiver erstrecken.

67 3.3. KOMBINATION DER PATTERNS 67 Selective Consumer kombiniert werden. [2] Der Selective Consumer kann mit allen anderen Endpoint Patterns Message Endpoint/Filter Die in dieser Arbeit besprochenen Filter können mit allen Message Endpoint Patterns kombiniert werden Message Channel/Message Channel Datatype Channel An einen zusätzlichen Ausgang kann beim Datatype Channel der Dead Letter Channel gesetzt werden. Dabei muss der Nachrichtentyp beider Patterns übereinstimmen. Außerdem können die Patterns Guaranteed Delivery und Message Expiration zusätzlich verwendet werden. Andere Kombinationen sind nicht möglich. Publish-Subscribe Channel Der Publish-Subscribe Channel kann zusätzlich mit den Pattern Guaranteed Delivery und Message Expiration verwendet werden. Andere Kombinationen sind nicht möglich. Invalid Message Channel Der Invalid Message Channel kann zusätzlich mit den Pattern Guaranteed Delivery und Message Expiration verwendet werden. Andere Kombinationen sind nicht möglich. Dead Letter Channel Der Dead Letter Channel kann an einen Datatype Channel gesetzt werden. Dabei muss der Nachrichtentyp beider Patterns übereinstimmen. Der Dead Letter Channel wird in diesem Fall nicht an den eigentlichen Ausgang des Datatype Channels gesetzt, sondern an einen zusätzlichen Ausgang. Außerdem können die Patterns Guaranteed Delivery und Message Expiration zusätzlich verwendet werden. Andere Kombinationen sind nicht möglich. Dieses Pattern kann mit allen anderen Channel Patterns kombi- Guaranteed Delivery niert werden. Message Expiration werden. Dieses Pattern kann mit allen anderen Channel Patterns kombiniert

68 68 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS Message Endpoint/Message Channel Datatype Channel Der Datatype Channel kann nicht an einen Filter mit dem Pattern Durable Subscriber angebracht werden. Dies ist vollkommen unnötig, da ein Datatype Channel automatisch die Nachrichten zwischenspeichert, wenn der Receiver nicht erreichbar ist. Publish-Subscribe Channel Der Publish-Subscribe Channel lässt sich nicht an einen Filter mit dem Pattern Competing Consumers anschließen. In diesem Fall würde jeder Consumer als extra Receiver angesehen und nicht als ein Receiver behandelt werden. Invalid Message Channel Der Invalid Message Channel kann unabhängig von den Message Endpoint Patterns an einen Filter angeschlossen werden. Dead Letter Channel Da der Dead Letter Channel nur an einen anderen Channel, nicht aber an einen Filter, angeschlossen wird, haben die verwendeten Message Endpoint Patterns keinen Einfluss auf ihn. Guaranteed Delivery Das Pattern Guaranteed Delivery kann unabhängig von den verwendeten Message Endpoint Patterns zu einem Channel hinzugefügt werden. Message Expiration Das Pattern Message Expiration kann unabhängig von den verwendeten Message Endpoint Patterns zu einem Channel hinzugefügt werden Message Channel/Filter Datatype Channel Der Datatype Channel kann an jeden Filter angeschlossen werden. Einzigste Bedingung dabei ist, dass die Nachrichtentypen der beiden Patterns übereinstimmen. Publish-Subscribe Channel Der Publish-Subscribe Channel kann an jeden Filter angeschlossen werden. Einzigste Bedingung dabei ist, dass die Nachrichtentypen der beiden Patterns übereinstimmen. Im Falle von BPEL kann der Publish-Subscribe Channel nur an einen generischen Empfänger angeschlossen werden. Dieser nimmt stellvertretend für die eigentlichen Empfänger des Channels den Platz im BPEL-Prozess ein und empfängt eventuelle Antworten. Invalid Message Channel Der Invalid Message Channel kann an jeden Filter angeschlossen werden. Einzigste Bedingung dabei ist, dass die Nachrichtentypen der beiden Patterns übereinstimmen.

69 3.3. KOMBINATION DER PATTERNS 69 Dead Letter Channel werden. Der Dead Letter Channel kann an keinen Filter angeschlossen Guaranteed Delivery Das Pattern kann unabhängig von dem vorherigen oder nachfolgenden Filter verwendet werden. Message Expiration Das Pattern kann unabhängig von dem vorherigen oder nachfolgenden Filter verwendet werden Filter/Filter Wie in Punkt 3.3 bereits erwähnt soll es nicht möglich sein, hinter einen Filter einen weiteren Filter zu schalten Zusammengesetzte Patterns Nachfolgend werden zwei Patterns von Gregor Hohpe (siehe [2]) behandelt, die sich aus bereits besprochenen Patterns zusammensetzen. Dies soll gleichzeitig demonstrieren, wie sich die einzelnen Patterns kombinieren und verbinden lassen Composed Message Processor Muss eine Nachricht verarbeitet werden, die aus einzelnen Teilen besteht, und müssen diese Teile von unterschiedlichen Diensten bearbeitet werden, dann kann man das Pattern Composed Message Processor verwenden. Das Pattern besteht aus einer Reihe von Patterns, welche die Nachricht aufspalten, bearbeiten und die Ergebnisse wieder in einer Nachricht vereinen. Abbildungen 3.28 und 3.29 zeigen den Aufbau des Patterns mithilfe der in Kapitel 3.2 vorgestellten Patternnotationen. Die Patterns External Service sind nur beispielhaft eingefügt und können durch jeden anderen Filter ersetzt werden. Damit das Pattern funktioniert, müssen für jedes Unterpattern die Parameter festgelegt werden. Außerdem müssen die Ausgaben mit den Eingaben übereinstimmen. Das Gesamtpattern wirkt nach Außen wie ein geschlossenes System: eine Nachricht tritt ein, eine andere Nachricht tritt aus. Für die vorherigen oder nachfolgenden Patterns ist es irrelavant, was innerhalb des Patterns geschieht. Die in den Abbildungen 3.28 und 3.29 gezeigte Zusammenstellung aus einzelnen Patterns ist auf das Minimalste reduziert. In der Praxis bietet es sich an, noch zusätzliche Patterns zu verwenden. Dazu gehören die Messaging Endpoint Patterns, aber auch weitere Channel Patterns wie zum Beispiel der Dead Letter Channel und der Invalid Message Channel.

70 70 KAPITEL 3. PARAMETRISIERUNG DER EAI PATTERNS Abbildung 3.28: Aufbau des Composed Message Processors (Teil 1) Abbildung 3.29: Aufbau des Composed Message Processors (Teil 2)

71 3.3. KOMBINATION DER PATTERNS Scatter Gather Muss eine Nachricht an mehrere Empfänger versendet werden, und müssen die Antworten der Empfänger in einer einzelnen Nachricht zusammengefasst werden, dann kann man das Pattern Scatter Gather verwenden. Das Pattern besteht aus einer Reihe von Patterns, welche die Nachricht verteilen, bearbeiten und die Ergebnisse wieder in einer Nachricht vereinen. Abbildung 3.30 zeigt den Aufbau des Patterns mithilfe der in Kapitel 3.2 vorgestellten Patternnotationen. Die Patterns External Service sind nur beispielhaft eingefügt und können durch jeden anderen Filter ersetzt werden. Abbildung 3.30: Aufbau des Scatter Gather Patterns Damit das Pattern funktioniert, müssen für jedes Unterpattern die Parameter festgelegt werden. Außerdem müssen die Ausgaben mit den Eingaben übereinstimmen. Das Gesamtpattern wirkt nach Außen wie ein geschlossenes System: eine Nachricht tritt ein, eine andere Nachricht tritt aus. Für die vorherigen oder nachfolgenden Patterns ist es irrelavant, was innerhalb des Patterns geschieht. Die in der Abbildung 3.30 gezeigte Zusammenstellung aus einzelnen Patterns ist auf das Minimalste reduziert. In der Praxis bietet es sich an, noch zusätzliche Patterns zu verwenden. Dazu gehören die Messaging Endpoint Patterns, aber auch weitere Channel Patterns wie zum Beispiel der Dead Letter Channel und der Invalid Message Channel. Es ist auch möglich, die Nachricht über das Pattern Recipient List zu verteilen, und nicht wie im Beispiel gezeigt über einen Publish-Subscribe Channel.

72 4 Das System EAI to BPEL In diesem Kapitel wird das System EAI to BPEL, das im Zuge der Diplomarbeit entstanden ist, beschrieben. Dabei werden zuerst noch einmal kurz die anfänglichen Anforderungen beschrieben. Es wird auch dargestellt, in wie weit die Anforderungen letztendlich erfüllt wurden. Danach wird die Bedienung des Systems erläutert. Dazu gehört eine Auflistung der Features des Systems und ein verkürztes Handbuch. Dieser Teil richtet sich also an jeden, der mit dem System arbeiten möchte. Der letzte Teil dieses Kapitels richtet sich an Entwickler, die das Systems weiterentwickeln möchten. Für diese wird der Umgang mit EMF und GEF erläutert. Danach wird das Modell erläutert, auf dem das System basiert. Da im System das BPEL Framework von Florian Schebelle (siehe [1]) verwendet wird, wird erklärt, in wiefern das Framework verwendet wird und was an der Originalversion verändert werden musste, um mit dem System kompatibel und auf dem Stand von BPEL 2.0 zu sein. Danach werden die Umsetzung der Patterns und die daraus resultierende BPEL-Generierung erläutert. Als kleine Zusammenfassung werden in einem Unterkapitel die Packages und Klassen aufgelistet, bei denen man für eine Weiterentwicklung ansetzen kann. Dabei wird auch erklärt, was an diesen Stellen erweitert werden kann, und wie diese Erweiterung durchgeführt werden kann. Das Kapitel schließt mit einem Ausblick auf zukünftige Diplomarbeiten. Hier werden offene Punkte und Weiterentwicklungsmöglichkeiten aufgezeigt. 4.1 Die Anforderungen Im Laufe der Diplomarbeit tauchten mehrere Anforderungen für das System auf. Die meisten davon standen zwar schon bei Beginn der Diplomarbeit fest, doch kristallisierten sich in der Anfangsphase der Implementierung in den Gesprächen detailliertere Anforderungen heraus, die hier mit aufgeführt werden. 72

73 4.1. DIE ANFORDERUNGEN 73 Tabelle 4.1: Anforderungen und ihre Umsetzung Anforderung System soll Eclipse-basiert sein es soll möglich sein, aus EAI Patterns einen Workflow zusammenzustellen folgende Patterns sollten umgesetzt werden: Content Enricher, Datatype Channel, Aggregator, Message Translator, Recipient List die zu generierende BPEL-Datei soll in WS-BPEL 2.0 sein die Generierung soll automatisch geschehen, ohne dass der Benutzer in den BPEL-Code eingreifen muss in das System soll das BPEL Framework von Florian Schebelle eingebunden werden unzulässige Kombinationen von Patterns sollen verhindert werden die Patterns müssen mit Parametern versehen werden können, um ihr Verhalten festzulegen als Ergebnis der Generierung sollen eine BPEL-Datei und die dazu gehörige WSDL-Datei entstehen Umsetzung System ist Eclipse-basiert im Editor lassen sich die einzelnen EAI Patterns zu einem Message System kombinieren; nach Eingabe der benötigten Parameter lässt sich aus diesem System ein BPEL-Prozess erstellen; dieser kann dann in einer Workflow Engine ausgeführt werden es wurden für alle Patterns die benötigten Schnittstellen eingebaut, so dass eine Erweiterung leicht möglich ist; außerdem wurden folgende Patterns umgesetzt: Content Enricher, Datatype Channel, Aggregator, Message Translator, Recipient List, External Service, Selective Consumer, Guaranteed Delivery, Content-Based Router da die BPEL-Generierung mit Hilfe des BPEL Frameworks umgesetzt wurde, und dieses noch auf dem Stand von BPEL 1.1 war, wurde das BPEL- Framework an den betreffenden Stellen an den Standard 2.0 angepasst die Generierung geschieht automatisch, so dass der Benutzer nicht in den BPEL-Code eingreifen muss; wie gewünscht ist der BPEL-Code im System auch nicht einsehbar das System arbeitet bei der Generierung der BPEL-Datei mit dem BPEL Framework (siehe [1]); allerdings musste das Framework angepasst werden, damit es mit dem System funktioniert das verwendete Modell schränkt den Benutzer auf eine gültige Zusammenstellung des Message Systems ein; so muss zum Beispiel nach jedem Filter ein Channel folgen die Patterns müssen konfiguriert werden, damit die Generierung durchgeführt werden kann; bei der Konfiguration kann man zwischen unterschiedlichen Alternativen der Patterns auswählen bei der Generierung entsteht die BPEL-Datei mit dembpel-prozess und die dazu gehörige WSDL-Datei

74 74 KAPITEL 4. DAS SYSTEM EAI TO BPEL 4.2 Bedienung des Systems Das nachfolgende Kapitel soll den Anwender mit der Bedienung des Systems vertraut machen. Dabei wird zuerst einmal die Benutzeroberfläche beschrieben. Danach wird erklärt, wie man ein neues EAI Projekt erstellt und in diesem ein Message System zusammenstellt. In diesem Zusammenhang wird auch die Bedienung der bereits umgesetzten Patterns erläutert. Es wird erklärt, wie man die BPEL- und WSDL-Datei generieren lassen kann. Zum Schluss wird noch auf Extra-Funktionen eingegangen Die Benutzeroberfläche Falls man nach dem Start des Programms noch nicht in der EAI to BPEL -Perspektive ist, so kann man mit folgenden Schritten in die richtige Perspektive wechseln: Über das Hauptmenü Window kommt man an den Menüpunkt Open Perspective. Hier wählt man den Punkt Other.... In dem sich öffnenden Fenster Open Perspective kann man nun die gewünschte Perspektive auswählen. Nach diesem Schritt befindet man sich in der EAI to BPEL -Perspektive (siehe Abbildung 4.1). Diese besteht im Großen und Ganzen aus vier Teilen: Auf der linken Seite befindet sich der Navigator. Dieser gibt einen Überblick über die im Workspace enthaltenen Projekte und die darin enthaltenen Dateien. Im zentralen Bereich von Eclipse öffnet sich der Editor, wenn man auf eine EAI-Datei doppelklickt. Dieser besteht aus der Zeichenfläche und einer Palette. In der Palette befinden sich sämtliche Werkzeuge, die man zur Erstellung eines Message Systems benötigt. Mit diesen Werkzeugen kann man auf der Zeichenfläche ein Message System erstellen. Im rechten unteren Bereich befinden sich zwei Fenster: der Properties-Tab und der Problems- Tab. Der Properties-Tab zeigt die Properties des aktuell ausgewählten Objektes im Editor. Ist kein Objekt selektiert, so werden im Properties-Tab die Properties des Message Systems angezeigt. Als Properties werden hierbei 1:1 die Attribute des jeweiligen Java-Objektes angezeigt. Es handelt sich hier also um Implementierungsdetails. Deswegen sind die Properties nicht immer selbsterklärend und reichen nicht aus, um ein Objekt mit den benötigten Parametern zu versehen. Dafür gibt es für jedes Objekt noch die Configuration -Dialoge. Sowohl die Properties als auch die Configuration -Dialoge werden im Zuge mit den Pattern-Beschreibungen später im Kapitel erläutert. Der Problems-Tab listet eventuelle Fehler im Message System auf. Diese Fehler werden angezeigt, wenn man das System speichert. Eine genauere Beschreibung des Problems-Tabs findet sich in Abschnitt Im linken unteren Bereich befindet sich die Outline-View. Diese dient als eine Art Minimap des Editors. Sie ist vor allem dann hilfreich, wenn das Message System über den Rand des Editors hinausgeht. Per Klick in die Minimap lässt sich dann gezielt zu einem gewünschten Bereich im Editor springen.

75 4.2. BEDIENUNG DES SYSTEMS 75 Abbildung 4.1: EAI to BPEL -Perspektive Ein neues Projekt erstellen Möchte man ein Message System erstellen, so benötigt man als erstes ein Projekt, in dem das System gespeichert werden kann. Dazu erreicht man über das Hauptmenü File den Unterpunkt New. Hier wählt man den Punkt Project... aus. In dem sich öffnenden Fenster New Project öffnet man den Ordner EAI to BPEL und wählt hier den Punkt EAI to BPEL Project. Danach betätigt man den Button Next, um zum nächsten Fenster zu gelangen. Hier gibt man den Namen des zu erstellenden Projektes an. Falls das Projekt außerhalb des Workspaces erstellt werden soll, so entfernt man den Haken bei Use default location und gibt den Ordner an, in dem das Projekt erstellt werden soll. Indem man den Button Finish betätigt, schließt man den Dialog und erstellt das neue Projekt Eine EAI-Datei erstellen In einer EAI-Datei wird das Message System erstellt. Den passenden Editor kann man nur über eine solche Datei aufrufen. Deswegen benötigt man für die Erstellung eines Message Systems eine.eai-datei. Indem man auf das Projekt, in dem die Datei erstellt werden soll, mit der rechten Maustaste klickt, öffnet sich ein Kontextmenü. Hier wählt man den Menüpunkt New und dort den Punkt Other....

76 76 KAPITEL 4. DAS SYSTEM EAI TO BPEL Es öffnet sich das Fenster New, in dem sich eine Reihe von Datei-Wizards befindet. Hier navigiert man zum Ordner EAI to BPEL, öffnet diesen, und wählt den Punkt EAI to BPEL File. Danach betätigt man den Button Next, um zum nächsten Fenster zu gelangen. In diesem Fenster selektiert man das Projekt, in dem die Datei erstellt werden soll, und gibt im Feld File name den Namen der zu erstellenden Datei ein. Man beachte, dass die Datei die Endung.eai besitzen muss. Indem man den Button Finish betätigt, schließt man den Dialog und erstellt die neue Datei Ein Message System erstellen Möchte man ein Message System erstellen, so benötigt man dafür eine EAI-Datei. Indem man die EAI-Datei doppelklickt, öffnet sich der Editor. Das Grundelement einer EAI-Datei ist das Message System. Es ist durch die weiße Zeichenfläche abgebildet. In der Zeichenfläche wird links oben der Name des Message Systems angezeigt. Ist die EAI-Datei neu erstellt, so ist der Name noch auf null gesetzt. Mit einem Rechtsklick in der Zeichenfläche öffnet sich ein Kontextmenü. Hier wählt man die Option Configuration Dialog. In dem sich öffnenden Fenster kann man das Message System konfigurieren (siehe Abbildung 4.2). Notwendig sind die Einträge der Target Namespaces für die BPEL- und WSDL-Datei. In den beiden Tabellen werden zusätzliche Namespaces für die jeweiligen Dateien angezeigt. Ein neuer Namespace kann über den Button Add angelegt werden. Über den Edit Button kann man einen selektierten Eintrag bearbeiten. Der Delete -Button erlaubt das Löschen eines selektierten Eintrags. Gleiches gilt für die letzte Tabelle. Hier werden die Correlation Sets des Prozesse verwaltet. Der Correlation Set definiert sich über einen Namen und kann eine oder mehrere Properties besitzen. Möchte man für einen Correlation Set mehrere Properties angeben, so gibt man den jeweiligen Einträgen in der Tabelle denselben Namen. Diese Einträge werden bei der Generierung dann als ein Correlation Set behandelt. Erstellt man oder bearbeitet man einen Namespace, so öffnet sich ein weiteres Fenster, in dem die Attribute Prefix und Namespace angegeben werden können. Der Prefix eines Namespaces wird unter Umständen in anderen Patterns verwendet, um z.b. auf Messagetypes in einer externen WSDL-Datei zu verweisen. Erstellt man oder bearbeitet man ein Correlation Set, so öffnet sich ein weiteres Fenster, in dem die Attribute Name, Prefix und Property angegeben werden können. Es ist zu beachten, dass der hier verwendete Prefix in der Tabelle der Namespaces für BPEL definiert werden muss. Die erstellten Correlation Sets können dann in den Patterns eingesetzt werden, die einen externen Web Service aufrufen (siehe auch Abschnitt ). Im Properties-Tab finden sich einige der Konfigurationsmöglichkeiten wieder (siehe Abbildung 4.3). So kann hier auch ohne Verwendung des Dialogs der Name und die Targetnamespaces verändert werden. Bei der Erstellung eines gültigen Message Systems sind einige Regeln zu beachten. So müssen sich in der Abfolge des Systems IMMER (!) Filter und Channel abwechseln. Das bedeutet, dass vor und hinter jedem Filter-Pattern ein Channel-Pattern gesetzt sein muss. Genauso

77 4.2. BEDIENUNG DES SYSTEMS 77 Abbildung 4.2: Message System erstellen - 1 Abbildung 4.3: Message System erstellen - 2

78 78 KAPITEL 4. DAS SYSTEM EAI TO BPEL muss vor und hinter jedem Channel-Pattern ein Filter-Pattern stehen. Ausnahmen sind die Anfangs- und Endpatterns des Systems. Diese können allerdings nur Filter sein. Ein Filter kann außerdem mit Message Endpoint bzw. einem Invalid Message Channel verbunden sein. Ein Message Channel kann im Gegenzug dazu mit Channel-Addons bzw. einem Dead Letter Channel verbunden sein. Folgende Patterns fallen unter die Rubrik Filter (siehe auch Abbildung 4.4): External Service Aggregator Content-Based Router Dynamic Router (noch nicht implementiert) Message Filter (noch nicht implementiert) Recipient List Resequencer (noch nicht implementiert) Splitter (noch nicht implementiert) Claim Check (noch nicht implementiert) Content Enricher Content Filter (noch nicht implementiert) Message Translator Abbildung 4.4: Die Filter-Patterns Folgende Patterns fallen unter die Rubrik Channel (siehe auch Abbildung 4.5:

79 4.2. BEDIENUNG DES SYSTEMS 79 Datatype Channel Publish-Subscribe Channel (noch nicht implementiert) Die nachfolgenden Patterns sind keine eigenständigen Channels, sondern müssen an einen Filter bzw. einen Channel gesetzt werden (siehe auch Abbildung 4.5). Allerdings können sie die gleichen Channel AddOns besitzen wie normale Channels. Invalid Message Channel (noch nicht implementiert) Dead Letter Channel (noch nicht implementiert) Folgende Patterns fallen unter die Rubrik Channel AddOn (siehe auch Abbildung 4.5: Guaranteed Delivery Message Expiration (noch nicht implementiert) Abbildung 4.5: Die Channel-Patterns und ihre AddOns Folgende Patterns fallen unter die Rubrik Message Endpoint (siehe auch Abbilding 4.6: Idempotent Receiver (noch nicht implementiert) Message Dispatcher (noch nicht implementiert) Selective Consumer Transactional Client (noch nicht implementiert) Die einzelnen Patterns lassen sich über Connections verbinden (siehe Abbildung 4.7). Es gibt vier unterschiedliche Konnektoren, die Filter mit Channel und umgekehrt verbinden. Da bei diesen angegeben werden muss, welche Art von Message fließt, muss beachtet werden, dass der Messagetype, der in einen Channel hineinfließt, mit dem Nachrichtentyp, der aus

80 80 KAPITEL 4. DAS SYSTEM EAI TO BPEL Abbildung 4.6: Die Message Endpoint-Patterns dem Channel herausfließt übereinstimmen muss. Genauso gibt es Filter, die den Messagetype verändern, und andere, die den Type nicht verändern können. Dementsprechend dürfen sich dann auch nicht die Messagetypes vom eingehenden und ausgehenden Konnektor eines Filters unterscheiden. Die Filter to Channel Connection wird angewendet, wenn man einen Filter mit nur einem Ausgang mit einem Channel verbinden möchte. Ist der Filter ein Router, der möglicherweise mehrere Ausgänge besitzen könnte (wie zum Beispiel das Pattern Recipient List ), so benutzt man in diesem Fall den Konnektor Router to Channel Connection. Diese Konnektoren bekommen automatisch eine laufende Nummer zugeordnet, damit man von dem jeweiligen Pattern auf den richtigen Channel zugreifen kann. Die Channel to Filter Connection wird angewendet, wenn man einen Channel mit einem Filter verbinden möchte. Ausnahme bildet hierbei der Aggregator. Dieser benötigt einen eigenen Konnektor, da der Aggregator mehrere Eingänge besitzen kann. Der Konnektor für den Aggregator heißt Aggregator to Channel Connection. Wie bei einem Router bekommen die Aggregator-Konnektoren eine laufende Nummer zugeteilt. Möchte man einen Message Endpoint oder einen Invalid Message Channel mit einem Filter bzw. ein Channel-AddOn oder einen Dead Letter Channel mit einem Channel verbinden, so verwendet man hierbei die Part-Of Connection. Diese unterscheidet sich visuell von den normalen Konnektoren durch eine entsprechende Beschriftung. Dies erleichtert es später, die Grafik des Message Systems zu verstehen. Bilden zwei Patterns mit Zugriff auf einen externen Web Service ein Receive/Reply- bzw. ein Pick/Reply-Paar, so verbindet man die beiden Filter mit einem Receive-Reply/Pick-Reply Partners -Konnektor. Dieser Fall tritt meist bei dem eingehenden und ausgehenden External Service des Message Systems auf. Durch die Verbindung der beiden Filter mit dem Konnektor wird sichergestellt, dass die beiden Services über denselben Porttype und dieselbe Operation laufen.

81 4.2. BEDIENUNG DES SYSTEMS 81 Abbildung 4.7: Die Konnektoren Die Patterns verwenden Im nachfolgenden Abschnitt wird der Umgang mit den einzelnen Patterns beschrieben Correlation Für alle nachfolgenden Patterns gilt, dass sie, sobald sie einen externen Web Service verwenden, Correlations zugeordnet bekommen können. In diesem Fall kann im jeweiligen Configuration Dialog des Patterns der Button Edit Correlations betätigt werden. Dieser öffnet einen weiteren Dialog mit einer Tabelle aller gesetzten Correlations (siehe Abbildung 4.8). Abbildung 4.8: Die Correlation-Liste eines Patterns Per Add und Edit können neue Einträge hizugefügt bzw. existierende Einträge bearbeitet werden. Hierfür öffnet sich erneut ein Dialog, in dem die Daten der Correlation eingegeben werden können. Hier hat man als Name der Correlation die Correlation Sets zur Auswahl, die man im Message System erstellt hat (siehe Kapitel 4.2.4). Außerdem kann man die Parameter initiate und pattern setzen. Für initiate hat man die Werte yes, no oder join zur Auswahl. Für pattern die Werte request, response oder request-response. Möchte man das pattern -Attribut nicht setzen, so kann man den Wert n.a. (not available) auswählen. In diesem Fall wird das Attribut bei der BPEL-Erstellung ignoriert.

82 82 KAPITEL 4. DAS SYSTEM EAI TO BPEL Aggregator Der Aggregator findet sich in der Palette im Ordner Message Routing. Hat man einen Aggregator auf der Zeichenfläche platziert, so kann man mit einem Rechtsklick auf den Aggregator das Kontextmenü öffnen. Hier wählt man die Option Configuration Dialog. In dem sich öffnenden Fenster kann man den Aggregator konfigurieren (siehe Abbildung 4.9). Abbildung 4.9: Der Aggregator - 1 Ist der Aggregator mit einem oder mehreren Channel to Aggregator Connection verbunden, so befinden sich in der Tabelle dementsprechend viele Einträge. Hier sind die Channelnummern bereits gesetzt. Selektiert man einen Eintrag und betätigt den Edit Entry -Button, so öffnet sich ein weiteres Fenster, in dem man den Namen des Channels setzen kann. Da die Nummer automatisch vergeben wird, kann diese nicht verändert werden. Für einen Aggregator muss eine Completeness Condition ausgewählt werden. Entsprechend der ausgewählten Condition werden die benötigten Felder im Dialog freigeschalten: Die wait for all und first best Bedingungen benötigen keine weiteren Angaben. Wählt man die timeout Bedingung aus, so muss man die Dauer angeben, wie lange gewartet werden soll. Bei der external event Bedingung gibt man den Channelnamen an, über den eine Nachricht eintreffen muss, damit der Aggregationsprozess gestartet werden kann. Es ist dabei egal, was für eine Nachricht über den Channel eintrifft. Es handelt sich hierbei im Idealfall um einen Control-Channel, der den Aggregator anspricht. Der Inhalt der Nachricht wird beim Aggregationsprozess nicht berücksichtigt. Ist kein Haken bei external web service does aggregation gesetzt, so übernimmt BPEL den Aggregationsprozess. In diesem Fall wird automatisch die Aggregationsstrategie best

83 4.2. BEDIENUNG DES SYSTEMS 83 answer gesetzt. Damit diese durchgeführt werden kann, muss man den Namen des Elements angeben, das bestimmt, welche Nachricht die beste ist. Dabei ist zu beachten, dass es sich um einen XPath Ausdruck handeln muss. Das System setzt automatisch bei der Generierung $Variablenname davor. Außerdem muss angegeben werden, ob das Element maximal oder minimal sein muss, um als bestes angesehen zu werden. Die Aggregationsstrategie funktioniert also nur für numerische Elemente. Ist ein Haken gesetzt, so übernimmt ein Web Service den Aggregationsprozess. In diesem Fall müssen die Daten des Web Services (Prefix, Porttype, Operation) angegeben werden, damit der Web Service angesprochen werden kann. Es ist zu beachten, dass der Web Service und seine WSDL nicht vom System generiert werden - d.h. sie müssen bereits vorhanden sein oder noch erstellt werden. Der verwendete Prefix muss beim Message System als Zusatz-Namespace für die BPEL- und WSDL-Datei angegeben sein. Der Web Service muss außerdem eine weitere Operation zur Verfügung stellen, mit dem die Ergebnis-Message angefordert werden kann (die Callback Operation). Das Message System wird bei der Ausführung für jede eingehende Nachricht den Web Service mit der Operation extra aufrufen und zum Schluss die Callback Operation aufrufen. Im Properties-Tab finden sich einige der Konfigurationsmöglichkeiten wieder (siehe Abbildung 4.10). So können hier auch ohne Verwendung des Dialogs einige Parameter verändert werden. Abbildung 4.10: Der Aggregator - 2 Die aggregation strategy spielt nur eine Rolle, wenn kein externer Web Service verwendet wird. In diesem Fall macht zur Zeit nur der Eintrag best answer Sinn, da die anderen Aggregationsstrategien noch nicht umgesetzt wurden. Die Felder bestpropertymin und nameofbestproperty werden benutzt, wenn kein Web Service verwendet wird und die Aggregationsstrategy auf best answer gesetzt ist.

84 84 KAPITEL 4. DAS SYSTEM EAI TO BPEL Wird ein externer Web Service verwendet, so sind folgende Felder wichtig: call (dieses Feld sollte auf invoke gesetzt sein), callbackoperation, interfacetoexternalwebservice (dieses Feld ist bei Verwendung eines Web Services true, ansonsten false), operationforinvokecall, porttypeforinvokecall und prefixforporttype. Das Feld completenesscondition enthält einen String mit der Bezeichnung der Condition. Lautet diese Bezeichnung external event, so muss außerdem das Feld channelnameforexternalevent ausgefüllt sein. Lautet die Bezeichnung timeout, so muss das Feld duration ausgefüllt sein Content-Based Router Der Content-Based Router findet sich in der Palette im Ordner Message Routing. Hat man einen Content-Based Router auf der Zeichenfläche platziert, so kann man mit einem Rechtsklick auf den Content-Based Router das Kontextmenü öffnen. Hier wählt man die Option Configuration Dialog. In dem sich öffnenden Fenster kann man den Content-Based Router konfigurieren (siehe Abbildung 4.11). Abbildung 4.11: Der Content-Based Router - 1 Ist der Content-Based Router mit einem oder mehreren Router to Channel Connection verbunden, so befinden sich in den Tabellen dementsprechend viele Einträge. Hier sind die Channelnummern bereits gesetzt. Selektiert man einen Eintrag und betätigt den Edit Entry - Button, so öffnet sich ein weiteres Fenster, in dem man die restlichen Parameter der Tabelle setzen kann. Da die Nummer automatisch vergeben wird, kann diese nicht verändert werden.

85 4.2. BEDIENUNG DES SYSTEMS 85 Für die Bedienung des Content-Based Routers gibt es zwei Möglichkeiten: Entweder wird die Nachricht an einen externen Web Service übergeben, der den Namen des Channels zurückgibt, an den die Nachricht geroutet werden soll, oder BPEL übernimmt den Routing-Prozess und bestimmt mit Hilfe der unteren Tabelle den Empfänger. Soll BPEL die Bestimmung des Empfängers übernehmen, so muss die unterste Tabelle vollständig ausgefüllt werden. Für jeden Channelausgang muss angegeben werden, welches Element in der Nachricht welchen Wert einnehmen muss, damit die Nachricht an den Channel weitergeleitet wird. Dabei ist zu beachten, dass es sich bei dem Elementennamen um einen XPath Ausdruck handeln muss. Das System setzt automatisch bei der Generierung $Variablenname/ davor. Außerdem muss angegeben werden, ob das Element größer, kleiner oder gleich sein muss, wie der Vergleichswert. Der Content-Based Router funktioniert also in diesem Fall nur für numerische Elemente. Abbildung 4.12: Der Content-Based Router - 2 Soll ein Web Service den Empfänger bestimmen, so müssen die Daten des Web Services angegeben werden. Es ist zu beachten, dass der Web Service und seine WSDL nicht vom System generiert werden - d.h. sie müssen bereits vorhanden sein oder noch erstellt werden. Der verwendete Prefix muss beim Message System als Zusatz-Namespace für die BPEL- und WSDL-Datei angegeben sein. Es muss außerdem festgelegt werden, ob dem Content-Based Router ein Else-Zweig hinzugefügt werden soll. Ist dies der Fall, so muss der Name des Channels angegeben werden, an den die Nachricht geschickt werden soll, wenn keine der angegebenen Bedingungen erfüllt sind, bzw. wenn der Web Service einen unbekannten Namen zurück gibt.

86 86 KAPITEL 4. DAS SYSTEM EAI TO BPEL In jedem Fall sollte die erste Tabelle ausgefüllt sein. Sie ermöglicht es, den Ausgangschanneln Namen zuzuordnen. Dies ist vor allem für die zweite Möglichkeit wichtig. Sie aber auch dann wichtig, wenn ein Else-Zweig dem Content-Based Router hinzugefügt werden soll. Die beiden Tabellen des Content-Based Routers entsprechen den Tabellen der Recipient List (siehe ). Im Properties-Tab finden sich einige der Konfigurationsmöglichkeiten wieder (siehe Abbildung 4.12). So können hier auch ohne Verwendung des Dialogs einige Parameter verändert werden. Wird ein Else-Channel benutzt, so muss das Feld elseempty auf false gesetzt werden. Außerdem muss dann das Feld elsechannel gesetzt sein. Wird kein Else-Channel verwendet, muss das Feld elseempty auf true gesetzt sein. Wird ein externer Web Service verwendet, so sind folgende Felder wichtig: call (dieses Feld sollte auf invoke gesetzt sein), prefixformessagetype, interfacetoexternalwebservice (dieses Feld ist bei Verwendung eines Web Services true, ansonsten false), operationforinvokecall, porttypeforinvokecall, messagetypeofreturneddata und prefixforporttype Content Enricher Der Content Enricher findet sich in der Palette im Ordner Message Transformation. Hat man einen Content Enricher auf der Zeichenfläche platziert, so kann man mit einem Rechtsklick auf den Content Enricher das Kontextmenü öffnen. Hier wählt man die Option Configuration Dialog. In dem sich öffnenden Fenster kann man den Content Enricher konfigurieren (siehe Abbildung 4.13). Für den Content Enricher muss zuerst einmal festgelegt werden, welche Aufgabe der externe Web Service übernimmt. Entweder übernimmt der Web Service die komplette Arbeit, oder er gibt lediglich eine Message mit den neuen Daten zurück. In beiden Fällen müssen die Daten des Web Services (Prefix, Porttype, Operation) angegeben werden, damit der Web Service angesprochen werden kann. Es ist zu beachten, dass der Web Service und seine WSDL nicht vom System generiert werden - d.h. sie müssen bereits vorhanden sein oder noch erstellt werden. Der verwendete Prefix muss beim Message System als Zusatz-Namespace für die BPEL- und WSDL-Datei angegeben sein. Gibt der Web Service lediglich die Daten zurück, so muss außerdem angegeben werden, von welchem Messagetype die zurückgegebene Nachricht ist. Es ist zu beachten, dass Nachrichtentyp und seine WSDL nicht vom System generiert werden - d.h. sie müssen bereits vorhanden sein oder noch erstellt werden. Der verwendete Prefix muss beim Message System als Zusatz- Namespace für die BPEL-Datei angegeben sein. Zusätzlich zum Messagetype muss auch noch eine URN des Stylesheets, das die Originalnachricht und die Nachricht mit den neuen Daten in die Ausgangsnachricht transformiert. Benutzt die URN des Stylesheets einen Prefix, so muss dieser ebenfalls beim Message System als Zusatz-Namespace für die BPEL-Datei angegeben sein. Es ist außerdem zu beachten, dass die XSL-Datei nicht vom System generiert wird, sondern schon vorhanden sein oder noch erstellt werden muss. Schließlich muss auch noch angegeben werden, ob an den Web Service die komplette eingehende Nachricht oder nur ein Schlüsselwert geschickt werden soll. Soll der Schlüsselwert geschickt werden, so muss

87 4.2. BEDIENUNG DES SYSTEMS 87 angegeben werden, welcher Wert das ist. Dabei ist zu beachten, dass es sich um einen XPath Ausdruck handeln muss. Das System setzt automatisch bei der Generierung $Variablenname davor. Abbildung 4.13: Der Content Enricher Im Properties-Tab finden sich einige der Konfigurationsmöglichkeiten wieder. So können hier auch ohne Verwendung des Dialogs einige Parameter verändert werden. Da bei einem Content Enricher immer ein externer Web Service aufgerufen wird, muss das Feld interfacetoexternalwebservice auf true gesetzt sein. Außerdem müssen die Felder operationforinvokecall, porttypeforinvokecall und prefixforporttype gesetzt sein. Das Feld call muss auf invoke gesetzt sein. Ist das Feld webservicereturnsdata auf true gesetzt, so müssen außerdem die Felder messagetypeofreturneddata, prefixformessagetype und stylesheeturi gesetzt sein. Ist das Feld keydeterminesdata auf true gesetzt, so muss das Feld key gesetzt sein Datatype Channel Der Datatype Channel findet sich in der Palette im Ordner Message Channels (siehe Abbildung 4.14). Er muss nicht konfiguriert werden. Die Konnektoren von und zum Channel finden sich in der Palette im Ordner Connections. Hat man einen Konnektor zwischen einen Filter und einen Channel platziert, so kann man mit

88 88 KAPITEL 4. DAS SYSTEM EAI TO BPEL einem Rechtsklick auf den Konnektor das Kontextmenü öffnen. Hier wählt man die Option Configuration Dialog. In dem sich öffnenden Fenster kann man den Konnektor konfigurieren (siehe Abbildung 4.14). Abbildung 4.14: Der Datatype Channel und der Konnektor Für jeden Konnektor muss der Messagetype der Nachricht, die von einem Pattern ins nächste verschoben werden soll, angegeben werden. Außerdem muss der Prefix der WSDL-Datei angegeben werden, in der der Messagetype definiert ist. Es ist zu beachten, dass der Messagetype und seine WSDL nicht vom System generiert werden - d.h. sie müssen bereits vorhanden sein oder noch erstellt werden. Der verwendete Prefix muss beim Message System als Zusatz- Namespace für die BPEL-Datei angegeben sein. Im Properties-Tab finden sich die Konfigurationsmöglichkeiten wieder. So können hier auch ohne Verwendung des Dialogs beide Parameter verändert werden. Handelt es sich bei dem Konnektor um einen Konnektor von einem Router oder zu einem Aggregator, so findet man im Properties-Tab eine weitere Property. Diese lautet entrynumber bzw exitnumber und wird automatisch vom System vergeben. Sie wird im Konfigurationsdialog des jeweiligen Filters verwendet External Service Der External Service befindet sich auf der Hauptebene der Palette. Hat man einen External Service auf der Zeichenfläche platziert, so kann man mit einem Rechtsklick auf den External Service des Kontextmenü öffnen. Hier wählt man die Option Configuration Dialog. In dem sich öffnenden Fenster kann man den External Service konfigurieren (siehe Abbildung 4.15).

89 4.2. BEDIENUNG DES SYSTEMS 89 Da es sich beim External Service immer um einen Web Service-Aufruf handelt, muss zuerst einmal die Art des Aufrufes (invoke, reply, receive oder pick) festgelegt werden. Bei einem invoke-aufruf müssen die Parameter Porttype, Prefix und Operation gesetzt werden. Es ist zu beachten, dass der Web Service und seine WSDL nicht vom System generiert werden - d.h. sie müssen bereits vorhanden sein oder noch erstellt werden. Der verwendete Prefix muss beim Message System als Zusatz-Namespace für die BPEL- und WSDL-Datei angegeben sein. Bei einem receive-/reply-/pick-aufruf müssen nur Porttype und Operation gesetzt werden. Dies liegt daran, dass es sich dabei um einen Porttype des MessageSystems handelt. Er wird also in der eigenen WSDL-Datei deklariert. Der Pick-Aufruf kann zum derzeitigen Stand nur eine Nachricht empfangen. Auch die OnAlarm - Funktion ist nicht möglich. Im Properties-Tab finden sich einige der Konfigurationsmöglichkeiten wieder. So können hier auch ohne Verwendung des Dialogs die Parameter verändert werden. Abbildung 4.15: Der External Service Da bei einem External Service immer ein externer Web Service aufgerufen wird, muss das Feld interfacetoexternalwebservice auf true gesetzt sein. Außerdem müssen die Felder operationforinvokecall und porttypeforinvokecall gesetzt sein. Das Feld call kann entsprechend der Aufrufart gesetzt werden. Handelt es sich dabei um den Call invoke, muss außerdem das Feld prefixforporttype gesetzt werden.

90 90 KAPITEL 4. DAS SYSTEM EAI TO BPEL Guaranteed Delivery Das Pattern Guaranteed Delivery befindet sich in der Palette im Ordner Message Channels. Hat man eine Guaranteed Delivery auf der Zeichenfläche platziert, so kann man mit einem Rechtsklick auf die Guaranteed Delivery das Kontextmenü öffnen. Hier wählt man die Option Configuration Dialog. In dem sich öffnenden Fenster kann man die Guaranteed Delivery konfigurieren (siehe Abbildung 4.16). Abbildung 4.16: Die Guaranteed Delivery Da es sich bei der Guaranteed Delivery immer um einen Web Service-Aufruf handelt, müssen die Parameter Porttype, Prefix und Operation gesetzt werden. Es ist zu beachten, dass der Web Service und seine WSDL nicht vom System generiert werden - d.h. sie müssen bereits vorhanden sein oder noch erstellt werden. Der verwendete Prefix muss beim Message System als Zusatz-Namespace für die BPEL- und WSDL-Datei angegeben sein. Der aktuelle Stand erlaubt lediglich, die Nachricht, die über den Channel läuft, in einem Invoke-Aufruf an einen externen Web Service weiterzugeben, der diese zwischenspeichert. Die gespeicherte Nachricht wird vom System weder gelöscht noch anderweitig verwendet. Dies muss manuell von einem Administrator geschehen. Im Properties-Tab finden sich einige der Konfigurationsmöglichkeiten wieder. So können hier auch ohne Verwendung des Dialogs die Parameter verändert werden. Es müssen die Felder operation, porttype und prefix gesetzt sein Message Translator Das Pattern Message Translator befindet sich in der Palette im Ordner Message Transformation. Hat man einen Message Translator auf der Zeichenfläche platziert, so kann man

91 4.2. BEDIENUNG DES SYSTEMS 91 Abbildung 4.17: Der Message Translator mit einem Rechtsklick auf den Message Translator das Kontextmenü öffnen. Hier wählt man die Option Configuration Dialog. In dem sich öffnenden Fenster kann man den Message Translator konfigurieren (siehe Abbildung 4.17). Zuerst einmal muss festgelegt werden, ob die Nachricht durch einen Web Service oder über ein XSLT-Stylesheet transformiert werden soll. Wird ein Web Service verwendet, so müssen die Parameter Porttype, Prefix und Operation gesetzt werden. Es ist zu beachten, dass der Web Service und seine WSDL nicht vom System generiert werden - d.h. sie müssen bereits vorhanden sein oder noch erstellt werden. Der verwendete Prefix muss beim Message System als Zusatz-Namespace für die BPEL- und WSDL-Datei angegeben sein. Wird kein Web Service verwendet, so muss eine URN des Stylesheets, das die Eingangsnachricht in die Ausgangsnachricht transformiert, angegeben werden. Benutzt die URN des Stylesheets einen Prefix, so muss dieser ebenfalls beim Message System als Zusatz-Namespace für die BPEL-Datei angegeben sein. Es ist außerdem zu beachten, dass die XSL-Datei nicht vom System generiert wird, sondern schon vorhanden sein oder noch erstellt werden muss. Im Properties-Tab finden sich einige der Konfigurationsmöglichkeiten wieder. So können hier auch ohne Verwendung des Dialogs einige Parameter verändert werden. Ist das Feld interfacetoexternalwebservice auf true gesetzt, so müssen die Felder operationforinvokecall, porttypeforinvokecall und prefixforporttype gesetzt sein. Das Feld call muss auf invoke gesetzt sein. Ist es auf false gesetzt, so muss das Feld stylesheeturi gesetzt sein.

92 92 KAPITEL 4. DAS SYSTEM EAI TO BPEL Recipient List Die Recipient List findet sich in der Palette im Ordner Message Routing. Hat man eine Recipient List auf der Zeichenfläche platziert, so kann man mit einem Rechtsklick auf die Recipient List das Kontextmenü öffnen. Hier wählt man die Option Configuration Dialog. In dem sich öffnenden Fenster kann man die Recipient List konfigurieren (siehe Abbildung 4.18). Abbildung 4.18: Die Recipient List - 1 Ist die Recipient List mit einem oder mehreren Router to Channel Connection verbunden, so befinden sich in den Tabellen dementsprechend viele Einträge. Hier sind die Channelnummern bereits gesetzt. Selektiert man einen Eintrag und betätigt den Edit Entry -Button, so öffnet sich ein weiteres Fenster, in dem man die restlichen Parameter der Tabelle setzen kann. Da die Nummer automatisch vergeben wird, kann diese nicht verändert werden. Für die Bedienung der Recipient List gibt es drei Möglichkeiten: Entweder handelt es sich um eine statische Empfängerliste, die entweder schon in der zu versendenden Nachricht enthalten ist oder von einem externen Web Service angefordert werden muss, oder die Empfänger werden dynamisch über den Inhalt der Nachricht bestimmt. Abbildung 4.18 zeigt die Einstellung, wenn die Empfänger dynamisch ermittelt werden sollen. Dabei muss die unterste Tabelle vollständig ausgefüllt werden. Für jeden Channelausgang muss angegeben werden, welches Element in der Nachricht welchen Wert einnehmen muss,

93 4.2. BEDIENUNG DES SYSTEMS 93 damit die Nachricht an den Channel weitergeleitet wird. Dabei ist zu beachten, dass es sich bei dem Elementennamen um einen XPath Ausdruck handeln muss. Das System setzt automatisch bei der Generierung $Variablenname davor. Außerdem muss angegeben werden, ob das Element größer, kleiner oder gleich sein muss, wie der Vergleichswert. Die Inhaltsbasierte Recipient List funktioniert also nur für numerische Elemente. Abbildung 4.19 zeigt die Einstellung, wenn die statische Empfängerliste von einem Web Service angefordert werden soll. Dafür müssen die Daten des Web Services und der vom Web Service zurückgegebenen Nachricht angegeben werden. Es ist zu beachten, dass der Web Service und seine WSDL nicht vom System generiert werden - d.h. sie müssen bereits vorhanden sein oder noch erstellt werden. Der verwendete Prefix muss beim Message System als Zusatz-Namespace für die BPEL- und WSDL-Datei angegeben sein. Dasselbe gilt für den Nachrichtentyp. Abbildung 4.19: Die Recipient List - 2 Die Verwendung einer statischen Recipient List setzt voraus, dass die erste Tabelle vollständig ausgefüllt ist. Dabei muss jedem Channelausgang ein Namen gegeben werden. Die Message, in der die Liste enthalten ist, muss diese Channelnamen als boolean-properties (!) enthalten. Ist die Property auf false gesetzt, so wird die Nachricht nicht an den Ausgang geschickt. Im Properties-Tab finden sich einige der Konfigurationsmöglichkeiten wieder (siehe Abbildung 4.20). So können hier auch ohne Verwendung des Dialogs einige Parameter verändert werden.

94 94 KAPITEL 4. DAS SYSTEM EAI TO BPEL Abbildung 4.20: Die Recipient List - 3 Von den beiden boolean-werten interfacetoexternalwebservice und contentbased darf höchstens ein Wert auf true gesetzt. Sie legen fest, wie die Recipient List bestimmt wird. Ist interfacetoexternalwebservice true, so wird von einem Web Service die statische Liste abgefragt. Ist contentbased true, so wird die Nachricht inhaltsbasiert verteilt. Sind beide Werte false, so befindet sich die statische Liste bereits in der Nachricht. Wird ein externer Web Service verwendet, so sind folgende Felder wichtig: call (dieses Feld sollte auf invoke gesetzt sein), prefixformessagetype, interfacetoexternalwebservice (dieses Feld ist bei Verwendung eines Web Services true, ansonsten false), operationforinvokecall, porttypeforinvokecall, messagetypeofreturneddata und prefixforporttype Selective Consumer Der Selective Consumer findet sich in der Palette im Ordner Messaging Endpoints. Hat man einen Selective Consumer auf der Zeichenfläche platziert, so kann man mit einem Rechtsklick auf den Selective Consumer das Kontextmenü öffnen. Hier wählt man die Option Configuration Dialog. In dem sich öffnenden Fenster kann man den Selective Consumer konfigurieren (siehe Abbildung 4.13). Die Tabelle enthält alle Elemente, die der Selective Consumer filtern soll. Über den Add - Button lassen sich weitere Einträge hinzufügen. Über den Edit -Button kann man einen selektierten Eintrag bearbeiten. Der Delete -Button löscht einen selektierten Eintrag. Möchte man einen neuen Eintrag erstellen oder einen bereits existierenden Eintrag verändern, so öffnet sich ein weiteres Fenster. Hier kann man den Namen des Elements angeben. Dabei ist zu

95 4.2. BEDIENUNG DES SYSTEMS 95 Abbildung 4.21: Der Selective Consumer beachten, dass es sich um einen XPath Ausdruck handeln muss. Das System setzt automatisch bei der Generierung $Variablenname davor. Außerdem hat man die Wahl zwischen den drei Vergleichsoperatoren <, > und =. Schließlich gibt man noch einen Referenzwert an. Der Wert der eingehenden Nachricht muss also kleiner, größer oder gleich dem Vergleichswert sein, um an den Filter weitergeleitet zu werden. Im Properties-Tab kann man für den Selective Consumer keine Einstellungen vornehmen Die BPEL-Generierung Hat man ein vollständiges Message System erstellt, so kann man sich daraus die zugehörige BPEL- und WSDL-Datei erzeugen lassen. Dies geht entweder über das Hauptmenü EAI to BPEL und dann über den Menüpunkt Generate BPEL oder über das entsprechende Shortcut-Icon (siehe in Abbildung 4.22 links neben Generate BPEL ). Bestätigt man den Vorgang, so erscheint ein weiteres Fenster, das einen über den weiteren Vorgang unterrichtet. Nach einer weiteren Bestätigung öffnen sich nacheinander zwei Speichern unter -Dialoge, in denen man zuerst den Namen und Speicherort der BPEL-Datei und dann den der WSDL-Datei angeben muss. Wurde die Generierung erfolgreich durchgeführt, so erscheint jeweils für die BPEL- und die WSDL-Datei eine Bestätigungsmeldung. Ansonsten erscheint eine Fehlermeldung. ACHTUNG: Bevor die generierten Dateien verwendet werden können, müssen in beiden Dateien die import-anweisungen für die verwendeten Namespaces angegeben werden. Dies geschieht jeweils nach dem Hauptknoten mit folgender Anweisung:

96 96 KAPITEL 4. DAS SYSTEM EAI TO BPEL Abbildung 4.22: BPEL-Generierung - 1 <import namespace= anyuri location= anyuri importtype= anyuri /> In der BPEL-Datei muss auch eine Import-Anweisung für die generierte WSDL-Datei eingefügt werden, so dass diese gefunden werden kann Sonstige Funktionen Problems -Tab Bei jedem Speichern wird das Message System auf Fehler überprüft. Werden Fehler gefunden, so werden diese in der Problems-Tab angezeigt (siehe Abbildung 4.23). Die Fehlermeldungen bestehen aus einer Beschreibung des Fehlers, der Datei, in der der Fehler ist, der Pfad innerhalb des Workspaces zu der Datei, und der Location (dem Element, das den Fehler verursacht hat). Da die einzelnen Patterns in einem Message System nicht eindeutig identifizierbar sind (durch eine ID oder einen Namen), wird im Feld Location nur der Typ des fehlerhaften Patterns angezeigt. Sind Fehler vorhanden, so lässt sich die BPEL-Generierung nicht durchführen. Sind lediglich Warnungen vorhanden, so lässt sich die BPEL-Generierung zwar durchführen, doch sollte man sicher gehen, dass die Warnungen beachtet wurden. Ist die Fehlerbeschreibung zu groß, um in der Tabelle angezeigt zu werden, lässt sich mit einem Rechtsklick auf den Fehler der Menüpunkt Properties auswählen. Dieser öffnet ein Informationsfenster, in dem der Fehler lesbarer erscheint.

97 4.3. DIE IMPLEMENTIERUNG 97 Abbildung 4.23: Die Problems-Tab Drucken Möchte man das Message System aus dem Editor drucken, so lässt sich die eingebaute Druckoption von Eclipse nutzen. Beim Drucken ist zu beachten, dass sämtliche Patterns in schwarz/weiß gedruckt werden (keine Grautöne). Außerdem muss auf die Größe der Zeichenfläche Acht gegeben werden. Ist das Message System zu breit, um im Hochformat gedruckt zu werden, so wird das Message System auf zwei Seiten gedruckt. Dies kann unter Umständen nicht das gewünschte Ergebnis sein. Hier empfielt es sich, entweder die Patterns zurecht zuschieben, oder das System im Querformat zu drucken Zoom Die Zeichenfläche des Editors ist mit einer Zoomfunktion versehen. Diese befindet sich oberhalb des Editors. Mit Hilfe einer Combo-Box lässt sich die Zoomstufe einstellen (siehe Abbildung 4.24). Diese gehen von 50% bis 400%. 4.3 Die Implementierung Das nachfolgende Kapitel soll den Leser mit der Implementierung des Systems vertraut machen. Es richtet sich vor allem an Entwickler, die das System verstehen, verbessern oder weiterentwickeln wollen. Dafür werden die verwendeten Plugins GEF und EMF erklärt. Danach wird das verwendete Modell vorgestellt. Da das BPEL-Framework Teil des Systems ist,

98 98 KAPITEL 4. DAS SYSTEM EAI TO BPEL Abbildung 4.24: Die Zoom-Funktion wird dokumentiert, was das Framekwork ist, was vom Framework übernommen wurde, und wie es verändert wurde. Danach erfolgt für jedes Pattern die Beschreibung der Implementierung. Außerdem wird der Prozess der BPEL-Generierung genauer erläutert. Das letzte Unterkapitel fasst zusammen, an welchen Punkten bei einer Weiterentwicklung anzusetzen ist, und wie am besten dabei vorzugehen ist Eclipse Da das zu erstellende Werkzeug auf Eclipse basiert, werden nachfolgend die Architektur von Eclipse und die in dieser Arbeit verwendeten Plugins vorgestellt (siehe auch Abbildung 4.25). Abbildung 4.25: Die Eclipse Architektur Eclipse selbst besteht aus einer relativ kleinen Kernapplikation. Diese ist für die Ausführung von Plugins zuständig. Die eigentliche Funktionalität von Eclipse wird über eine Vielzahl von Plugins umgesetzt. Dies ermöglicht es, Eclipse sowohl durch neue Plugins zu erweitern, als auch vorhandene Funktionalität aus der ausgelieferten Plattform zu entfernen. Dies soll in der aktuellen Arbeit in sofern geschehen, dass Eclipse über ein selbstgeschriebenes Plugin erweitert wird, mit dem man eine Kombination von EAI Patterns in BPEL-Code wandeln kann.[18]

Verbesserung eines EAI Pattern Editors

Verbesserung eines EAI Pattern Editors Institut für Architektur von Anwendungssystemen Universität Stuttgart Universitätsstraße 38 D 70569 Stuttgart Studienarbeit Nr. 2123 Verbesserung eines EAI Pattern Editors Christian Strempfer Studiengang:

Mehr

Business Process Execution Language. Christian Vollmer Oliver Garbe

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

Mehr

Gemusterte Kamele. Systemintegration mit Java und Apache Camel. Tobias Israel tobias.israel@buschmais.com

Gemusterte Kamele. Systemintegration mit Java und Apache Camel. Tobias Israel tobias.israel@buschmais.com Gemusterte Kamele Systemintegration mit Java und Apache Camel Tobias Israel tobias.israel@buschmais.com Die Monolithen sterben aus! Eine Applikation = Viele Applikationen Interaktion Kooperation Verfügbarkeit...

Mehr

Integrationsmuster am Beispiel von Apache Camel

Integrationsmuster am Beispiel von Apache Camel Integrationsmuster am Beispiel von Apache Camel @berlin.jar buschmais GbR Inhaber Torsten Busch, Frank Schwarz, Dirk Mahler und Tobias Israel Adresse Leipziger Str. 93 01127 Dresden info@buschmais.de http://www.buschmais.de

Mehr

Geschäftsprozessmodellierung essmodellierung mit BPEL

Geschäftsprozessmodellierung essmodellierung mit BPEL Geschäftsprozessmodellierung essmodellierung mit BPEL Autor: Stefan Berntheisel Datum: 8. Januar 2010 Stefan Berntheisel Hochschule RheinMain Fachseminar WS 09/10 Agenda Grundlagen Business Process Execution

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Model-Driven Software Development

Model-Driven Software Development Model-Driven Software Development BPEL 2.0 Robert Siebert Das Forschungs- und Entwicklungsprojekt OrViA wird mit Mitteln des Bundesministeriums für Bildung und Forschung (BMBF) gefördert, die innerhalb

Mehr

Tutorial zu WS-BPEL. Veranstaltung: Entwicklung verteilter Softwaresysteme mit Webservices im Sommersemester 2008

Tutorial zu WS-BPEL. Veranstaltung: Entwicklung verteilter Softwaresysteme mit Webservices im Sommersemester 2008 Tutorial zu WS-BPEL Veranstaltung: Entwicklung verteilter Softwaresysteme mit Webservices im Sommersemester 2008 Universität Hamburg Department Informatik Arbeitsbereich VSIS Gruppe 01: Johannes Kuhlmann,

Mehr

Business Process Execution Language for Web Services (BPEL4WS)

Business Process Execution Language for Web Services (BPEL4WS) Hauptseminar und Vorlesung Web Services WS 2003/04 Business Process Execution Language for Web Services (BPEL4WS) Patrick Sauter 2/17 Vortrag - Überblick Definition, Zielsetzung und Allgemeines einfacher

Mehr

POIS-Praktikum 2007. Prozessimplementierung, RosettaNet PIPs 3A

POIS-Praktikum 2007. Prozessimplementierung, RosettaNet PIPs 3A POIS-Praktikum 2007 Prozessimplementierung, RosettaNet PIPs 3A Manuel Blechschmidt, David Foerster, Michael Leben, Mike Nagora, Jonas Rogge, Paul Römer Gliederung 2 Einleitung Was war unsere Aufgabe? Was

Mehr

9. Business Process Execution Language

9. Business Process Execution Language 1 9. Business Process Execution Language Beobachtung: häufige Änderungen der Geschäftsprozesse dies erfordert leichte und schnelle Software-Anpassung Idee: Software in (Web-)Services gliedern ( SOA) diese

Mehr

Workflow, Business Process Management, 4.Teil

Workflow, Business Process Management, 4.Teil Workflow, Business Process Management, 4.Teil 24. Januar 2004 Der vorliegende Text darf für Zwecke der Vorlesung Workflow, Business Process Management des Autors vervielfältigt werden. Eine weitere Nutzung

Mehr

Web Services Composition (BPWS4J )

Web Services Composition (BPWS4J ) Web Services Composition (BPWS4J ) Hager Markus, Kober Christoph, Linde Kai, Ott Florian, Erdmann Dennis Programmierung verteilter Systeme Lab Institut für Informatik Universität Augsburg Universitätsstraße

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

Abschlusspräsentation Projekt Loan Broker mit BizTalk 2010

Abschlusspräsentation Projekt Loan Broker mit BizTalk 2010 Abschlusspräsentation Projekt Loan Broker mit BizTalk 2010 Vortrag im Rahmen der Vorlesung Integration Engineering Dozent: Prof. Dr. Martin Buchheit SS 2011 Referenten: Florian Kalisch, Denis Radjenovic

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

1. Wie können Forms und SOA integriert werden?

1. Wie können Forms und SOA integriert werden? Forms goes SOA Jüssen, Stefan Senior Consultant 03.02.2011 Jede Änderung im Geschäftsprozess muss umgehend in der unterstützenden Software abgebildet werden können. Professionelle Systementwicklung basiert

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

Software-Architekturen für das E-Business

Software-Architekturen für das E-Business Sebastian Herden Jorge Marx Gömez Claus Rautenstrauch Andre Zwanziger Software-Architekturen für das E-Business Enterprise-Application-Integration mit verteilten Systemen Mit 60 Abbildungen 4y Springer

Mehr

Software Engineering II (IB) Serviceorientierte Architektur

Software Engineering II (IB) Serviceorientierte Architektur Serviceorientierte Architektur Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Webservices Ziel: flexible programmatische Zusammenarbeit zwischen Servern Bereitstellung

Mehr

TransConnect Business Integration Platform. universeller Server zur Integration von Daten, Anwendungen und Geschäftsprozessen

TransConnect Business Integration Platform. universeller Server zur Integration von Daten, Anwendungen und Geschäftsprozessen TransConnect Business Integration Platform universeller Server zur Integration von Daten, Anwendungen und Geschäftsprozessen Einleitung TransConnect ist die zentrale Serverplattform für den Aufbau einer

Mehr

Zustandsgebundene Webservices

Zustandsgebundene Webservices Zustandsgebundene Webservices Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel oer@uni-paderborn.de Universität Paderborn 25. September 2005 Zustandsgebundene Webservices Seite

Mehr

Bachelorarbeit. Modellierung interaktiver Web Service Workflows. Thema: Benjamin Koch. von

Bachelorarbeit. Modellierung interaktiver Web Service Workflows. Thema: Benjamin Koch. von Bachelorarbeit Thema: Modellierung interaktiver Web Service Workflows von Benjamin Koch Gliederung Beispiel Interaktive Workflows Komponenten o BPEL o Web Service o Web-Interface o Eclipse-Plugin Vorführung

Mehr

Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication

Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication Frank Kargl Torsten Illmann Michael Weber Verteilte Systeme Universität Ulm {frank.kargl torsten.illmann weber} @informatik.uni-ulm.de

Mehr

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung IBM WebSphere Process Server Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung AGENDA 1. Überblick 2. WebSphere Process Server 3. Komponenten 4. Präsentation

Mehr

5. Übung zur Vorlesung Service-orientierte Architekturen

5. Übung zur Vorlesung Service-orientierte Architekturen 5. Übung zur Vorlesung Service-orientierte Architekturen Webservices und WSDL SoSe 2011 Anmerkung Hausaufgabe 03 BPMN Auch hier gilt: Layout! Zu Unterschieden zw. BPMN und eepk Relative Aussagen sind geschickter

Mehr

Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design

Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design Softwaretechnik (Medieninformatik) Überblick: 6.1 Einleitung 6.2 Verfeinerung des Klassenmodells 6.3 Sequenzdiagramme 6.4 Umsetzung der Analysekonstrukte in das Design 6.5 Fallstudie 6.6 Software Kontrakte

Mehr

Geschäftsprozessmanagement: Einführung in»business Process Modelling Notation«(BPMN)

Geschäftsprozessmanagement: Einführung in»business Process Modelling Notation«(BPMN) Geschäftsprozessmanagement: in»business Process Modelling Notation«(BPMN) Eugen Labun Fachhochschule Gießen-Friedberg Fachbereich MNI Institut für Softwarearchitektur Serviceorientierte Architekturen bei

Mehr

objectif / SOA /.NET Inhalt Technologien ObjectiF Beispiel Vergleich: ObjectiF Rational Rose Quellenverzeichnis 20.01.2008 Christian Reichardt 2 Technologien 20.01.2008 Christian Reichardt 3 Methodenaufruf

Mehr

Business Process Management und Enterprise Service Bus

Business Process Management und Enterprise Service Bus Business Process Management und Enterprise Service Bus Gegner oder doch eine gute Ergänzung? Author: Date: Markus Demolsky Soreco International 08. November 2010 Vortragender Warum über Integration nachdenken?

Mehr

Enterprise Java Beans Einführung

Enterprise Java Beans Einführung Enterprise Java Beans Einführung Vorlesung 8 Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht EJBs im JEE Umfeld Verschiedene Typen von EJBs Von der Javaklasse

Mehr

Dokumentation zur Verwendung eines SOAP-Webservices in SAP PI

Dokumentation zur Verwendung eines SOAP-Webservices in SAP PI Betriebswirtschaftliche Anwendungen 2: Serviceorientierte Anwendungsintegration Dokumentation zur Verwendung eines SOAP-Webservices in SAP PI Umrechnung von Währungen Steffen Dorn, Sebastian Peilicke,

Mehr

.NET-Networking 2 Windows Communication Foundation

.NET-Networking 2 Windows Communication Foundation .NET-Networking 2 Windows Communication Foundation Proseminar Objektorientiertes Programmieren mit.net und C# Fabian Raab Institut für Informatik Software & Systems Engineering Agenda Grundproblem Bestandteile

Mehr

Von der UML nach C++

Von der UML nach C++ 22 Von der UML nach C++ Dieses Kapitel behandelt die folgenden Themen: Vererbung Interfaces Assoziationen Multiplizität Aggregation Komposition Die Unified Modeling Language (UML) ist eine weit verbreitete

Mehr

Using Workflows to Coordinate Web Services in Pervasive Computing Environments

Using Workflows to Coordinate Web Services in Pervasive Computing Environments Using Workflows to Coordinate Web Services in Pervasive Computing Environments Vortrag im Rahmen des Seminars SOA 2005 im Fachbereich Informatik angefertigt von Volker Henke Agenda 1. Ubiquitous Computing

Mehr

Einrichten der Outlook-Synchronisation

Einrichten der Outlook-Synchronisation Das will ich auch wissen! - Kapitel 3 Einrichten der Outlook-Synchronisation Inhaltsverzeichnis Überblick über dieses Dokument... 2 Diese Kenntnisse möchten wir Ihnen vermitteln... 2 Diese Kenntnisse empfehlen

Mehr

Praktikum Internetprotokolle - POP3

Praktikum Internetprotokolle - POP3 Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik/Rechnernetze 19. Mai 2008 1 Aufgabenstellung Praktikum

Mehr

SWN-NetT Webmail. Benutzerhandbuch für SWN-NetT Webmail. SWN-NetT Webmail finden Sie unter: http://webmail.swn-nett.de

SWN-NetT Webmail. Benutzerhandbuch für SWN-NetT Webmail. SWN-NetT Webmail finden Sie unter: http://webmail.swn-nett.de SWN-NetT Webmail Benutzerhandbuch für SWN-NetT Webmail SWN-NetT Webmail finden Sie unter: http://webmail.swn-nett.de Übersicht Einstieg... 2 Menü... 2 E-Mail... 3 Funktionen... 4 Auf eine neue Nachricht

Mehr

Konzepte und Anwendung von Workflowsystemen. Kapitel 8: Workflow Ausführungssprache BPEL

Konzepte und Anwendung von Workflowsystemen. Kapitel 8: Workflow Ausführungssprache BPEL Vorlesung Wintersemester 2011/12 Konzepte und Anwendung von Workflowsystemen Kapitel 8: Workflow Ausführungssprache BPEL Lehrstuhl für Systeme der Informationsverwaltung, Prof. Böhm Institut für Programmstrukturen

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 2: Einführung in Service-Orientierte Architekturen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha Alda

Mehr

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

Webmail. Anleitung für Ihr online E-Mail-Postfach. http://webmail.willytel.de

Webmail. Anleitung für Ihr online E-Mail-Postfach. http://webmail.willytel.de Webmail Anleitung für Ihr online E-Mail-Postfach http://webmail.willytel.de Inhalt: Inhalt:... 2 Übersicht:... 3 Menü:... 4 E-Mail:... 4 Funktionen:... 5 Auf neue Nachrichten überprüfen... 5 Neue Nachricht

Mehr

Java Forum Stuttgart 2008

Java Forum Stuttgart 2008 Professionelle Open Source SOA in 45 Minuten! Java Forum Stuttgart 2008 Dr. Halil-Cem Gürsoy, CDI AG Der Referent Insgesamt ca. 10 Jahre Beratung, davor Forschung Senior Consultant - JEE Evangelist Hauptsächlich

Mehr

Einführung in git. Ben Oswald. 27. April 2014. Im Rahmen der Vorlesung Entwicklung mobiler Anwendungen

Einführung in git. Ben Oswald. 27. April 2014. Im Rahmen der Vorlesung Entwicklung mobiler Anwendungen Einführung in git Im Rahmen der Vorlesung Entwicklung mobiler Anwendungen Ben Oswald 27. April 2014 Inhaltsverzeichnis 1 Einleitung 1 1.1 Was ist git?..................................... 1 1.2 Warum sollten

Mehr

Userhandbuch. Version B-1-0-2 M

Userhandbuch. Version B-1-0-2 M Userhandbuch Version B-1-0-2 M Inhaltsverzeichnis 1.0 Was bietet mir SERVRACK?... 3 1.1 Anmeldung... 3 1.2 Passwort vergessen?... 3 1.3 Einstellungen werden in Realtime übernommen... 4 2.0 Die SERVRACK

Mehr

... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128

... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128 ... Einleitung... 15 1... Grundlagen der Modellierung von Enterprise Services... 23 1.1... Serviceorientierte Architekturen... 26 1.1.1... Merkmale serviceorientierter Architekturen... 27 1.1.2... SOA

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

EAI - Enterprise Application Integration

EAI - Enterprise Application Integration EAI - Enterprise Application Integration Jutta Mülle WS 2005/2006 EAI - Folie 1 Überblick und Begriffsbildung Zusammenfassung und Ausblick hinweise EAI - Folie 2 Conclusion EAI Enterprise Application Integration

Mehr

Buzzword Bingo Game Documentation (Java based Game)

Buzzword Bingo Game Documentation (Java based Game) Buzzword Bingo Game Documentation (Java based Game) Meppe Patrick Djeufack Stella Beltran Daniel April 15, 2011 1 Inhaltsverzeichnis 1 Einleitung 3 2 Aufgabenstellung 3 3 Allgemeines zu Buzzword Bingo

Mehr

Softwarewiederverwendung und Patterns

Softwarewiederverwendung und Patterns Begrifflichkeiten und Beschreibungssystematik Begriffe Literatur zu Patterns Übersicht über die behandelten Konzepte Beschreibungsschema 97 Begriffe Glossar Patterns (Muster) sind ein Mittel der Wiederverwendung

Mehr

Java Web Services mit Apache Axis2 Entwickler

Java Web Services mit Apache Axis2 Entwickler Thilo Frotscher, Dapeng Wang, Marc Teufel Java Web Services mit Apache Axis2 Entwickler Vorwort 15 1 Einleitung 25 1.1 Entstehung 26 1.2 Unterstützte Standards 28 1.3 Was beinhaltet Axis2? 29 1.4 Warum

Mehr

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Harald Lange sd&m Lübecker Str. 1 22087 Hamburg harald.lange@sdm.de Abstract: Mit der Einführung eines Buchungs-

Mehr

Software Engineering II

Software Engineering II Software Engineering II Codegenerierung für den SmartIO Editor mit der Modeling Workflow Engine Wintersemester 10/111 Fachgebiet Software Engineering Albert Zündorf / Wiederholung Bisher im Laufe des Semesters

Mehr

Aufgabenstellung und Zielsetzung

Aufgabenstellung und Zielsetzung Aufgabenstellung und Zielsetzung In diesem Szenario werden Sie eine Bestellung, vorliegend im XML-Format, über einen Web-Client per HTTP zum XI- System senden. Dort wird die XML-Datei mittels eines HTTP-Interfaces

Mehr

Übungen zu Softwaretechnik

Übungen zu Softwaretechnik Prof. Dr. Dr. h.c. M. Broy Lösungsblatt 9 Dr. H. Ehler, S. Wagner 11. Januar 2007 Übungen zu Softwaretechnik Aufgabe 15 Systemerstellung / Systemarchitektur nach dem V- Modell XT Machen Sie sich mit den

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Dateisysteme mit Plugin-Funktion

Dateisysteme mit Plugin-Funktion Dateisysteme mit Plugin-Funktion Basierend auf Reiser 4 unter Linux http://llugb.amsee.de/logo.gif Ausgearbeitet und vorgetragen von Michael Berger 1/23 Agenda Die Idee Dateisysteme mit Plugin-Funktion

Mehr

Das Interceptor Muster

Das Interceptor Muster Das Interceptor Muster Implementierung des Interceptor Musters basierend auf OSGi and Friends Benjamin Friedrich Hochschule für Technik und Wirtschaft des Saarlandes Praktische Informatik - Entwurfsmuster

Mehr

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Die Unified Modeling Language Die UML (hier in der Version 0.9) ist ein Satz von Notationen zur Beschreibung objektorientierter Softwaresysteme.

Mehr

Die nächste Revolution in der modelgetriebenen Entwicklung?

Die nächste Revolution in der modelgetriebenen Entwicklung? Die nächste Revolution in der modelgetriebenen Entwicklung? Me Johannes Kleiber Software Engineer bei FMC Johannes.Kleiber@fmc-ag.com Themen Überblick Window Workflow Foundation Workflows modellieren WF

Mehr

Software Engineering Übung 4 Architektur, Modulentwurf

Software Engineering Übung 4 Architektur, Modulentwurf software evolution & architecture lab Software Engineering Übung 4 Architektur, Modulentwurf 1 Informationen 1.1 Daten Ausgabe Di 27.10.2009 Abgabe So 08.11.2009 bis 23:59 Uhr Besprechung am Di 17.11.2009

Mehr

0. Inhaltsverzeichnis

0. Inhaltsverzeichnis 0. Inhaltsverzeichnis 0. Inhaltsverzeichnis...1 1. Kurze Einführung WebService Architektur...2 1.1 Synchrones Modell:...2 1.2 Asynchrones Modell:...2 1.3 Vorteile:...3 1.4 Voraussetzungen...3 2. Testseite

Mehr

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen Daniel Liebhart SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen ISBN-10: 3-446-41088-0 ISBN-13: 978-3-446-41088-6 Inhaltsverzeichnis Weitere Informationen oder Bestellungen

Mehr

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen 9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.

Mehr

Integration Services - Dienstarchitektur

Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Dieser Artikel solle dabei unterstützen, Integration Services in Microsoft SQL Server be sser zu verstehen und damit die

Mehr

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte DWH Projekt, Methodik, Stärken und Schwächen, Übersicht, Weg der Daten,

Mehr

Perzentile mit Hadoop ermitteln

Perzentile mit Hadoop ermitteln Perzentile mit Hadoop ermitteln Ausgangspunkt Ziel dieses Projektes war, einen Hadoop Job zu entwickeln, der mit Hilfe gegebener Parameter Simulationen durchführt und aus den Ergebnissen die Perzentile

Mehr

VB.net Programmierung und Beispielprogramm für GSV

VB.net Programmierung und Beispielprogramm für GSV VB.net Programmierung und Beispielprogramm für GSV Dokumentation Stand vom 26.05.2011 Tel +49 (0)3302 78620 60, Fax +49 (0)3302 78620 69, info@me-systeme.de, www.me-systeme.de 1 Inhaltsverzeichnis Vorwort...2

Mehr

Kapitelübersicht. Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge. Was bedeutet Objektorien+erung?

Kapitelübersicht. Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge. Was bedeutet Objektorien+erung? Kapitelübersicht Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge Was bedeutet Objektorien+erung? ObjektorienCerte Analyse und Design die Objektmodellierung

Mehr

Implementierung von Geschäftsprozessen in der Verwaltung mit Hilfe von SOA

Implementierung von Geschäftsprozessen in der Verwaltung mit Hilfe von SOA E-Gov Fokus Geschäftsprozesse und SOA 31. August 2007 Implementierung von Geschäftsprozessen in der Verwaltung mit Hilfe von SOA Im Vortrag werden die Vor- und Nachteile von Geschäftsprozessen in der öffentlichen

Mehr

Man liest sich: POP3/IMAP

Man liest sich: POP3/IMAP Man liest sich: POP3/IMAP Gliederung 1. Einführung 1.1 Allgemeiner Nachrichtenfluss beim Versenden von E-Mails 1.2 Client und Server 1.2.1 Client 1.2.2 Server 2. POP3 2.1 Definition 2.2 Geschichte und

Mehr

ODEX Enterprise. ODEX Enterprise. Beratungsbüro Kasch GmbH & Co. KG. Beratungsbüro Kasch GmbH & Co KG Hemsener Weg 73 D-29640 Schneverdingen

ODEX Enterprise. ODEX Enterprise. Beratungsbüro Kasch GmbH & Co. KG. Beratungsbüro Kasch GmbH & Co KG Hemsener Weg 73 D-29640 Schneverdingen ODEX Enterprise Beratungsbüro Kasch GmbH & Co. KG ODEX Enterprise Im Firmenalltag müssen Geschäftsdokumente zuverlässig und effizient ausgetauscht werden, ansonsten drohen schwerwiegende finanzielle Konsequenzen.

Mehr

SmartExporter 2013 R1

SmartExporter 2013 R1 Die aktuelle Version wartet mit zahlreichen neuen Features und umfangreichen Erweiterungen auf. So können mit SmartExporter 2013 R1 nun auch archivierte Daten extrahiert und das Herunterladen der Daten

Mehr

IKONIZER II Installation im Netzwerk

IKONIZER II Installation im Netzwerk Der IKONIZER II ist netzwerkfähig in allen bekannten Netzwerken. Da jedoch etwa 95% der Installationen lokal betrieben werden, erfolgt diese grundsätzlich sowohl für das Programm wie auch für den lizenzfreien

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Yellowbill Adapter Spezifikationen Voraussetzungen Datum : 22.08.2013 Version : 1.0.0.2 22.08.2013 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung...3 2 Architektur...3 2.1 Grundsätze

Mehr

Dokumentation Softwareprojekt AlumniDatenbank

Dokumentation Softwareprojekt AlumniDatenbank Dokumentation Softwareprojekt AlumniDatenbank an der Hochschule Anhalt (FH) Hochschule für angewandte Wissenschaften Fachbereich Informatik 13. Februar 2007 Betreuer (HS Anhalt): Prof. Dr. Detlef Klöditz

Mehr

Modellierung von Geschäftsprozessen mit BPEL4WS

Modellierung von Geschäftsprozessen mit BPEL4WS Seminararbeit von Abstract Die Business Process Execution Language for Web Services (BPEL4WS) ermöglicht es, sowohl Geschäftsprozesse zu beschreiben, welche Web Services nutzen, als auch Geschäftsprozesse

Mehr

Filterregeln... 1. Einführung... 1. Migration der bestehenden Filterregeln...1. Alle eingehenden Nachrichten weiterleiten...2

Filterregeln... 1. Einführung... 1. Migration der bestehenden Filterregeln...1. Alle eingehenden Nachrichten weiterleiten...2 Jörg Kapelle 15:19:08 Filterregeln Inhaltsverzeichnis Filterregeln... 1 Einführung... 1 Migration der bestehenden Filterregeln...1 Alle eingehenden Nachrichten weiterleiten...2 Abwesenheitsbenachrichtigung...2

Mehr

ITSM Infoday 2013. Mit Business Process Service Management zu mehr Flexibilität, Transparenz und Stabilität. Peter Brückler

ITSM Infoday 2013. Mit Business Process Service Management zu mehr Flexibilität, Transparenz und Stabilität. Peter Brückler ITSM Infoday 2013 Mit Business Process Management zu mehr Flexibilität, Transparenz und Stabilität Peter Brückler Copyright 2013 NTT DATA EMEA Ltd. Agenda Der Druck auf Unternehmen Business Process Management

Mehr

Diplomarbeit von Lars Gohlke. University of Applied Sciences Brandenburg

Diplomarbeit von Lars Gohlke. University of Applied Sciences Brandenburg Diplomarbeit von Lars Gohlke University of Applied Sciences Brandenburg Inhalt Motivation Skype SOA in 5 Schritten Anwendung + Demo Seite 2 Motivation Kommunikation einfach - schnell preiswert - verläßlich

Mehr

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen Mit der aktuellen Version hält eine komplett neu konzipierte webbasierte Anwendung Einzug, die sich neben innovativer Technik auch durch ein modernes Design und eine intuitive Bedienung auszeichnet. Angefangen

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Zeiterfassung-Konnektor Handbuch

Zeiterfassung-Konnektor Handbuch Zeiterfassung-Konnektor Handbuch Inhalt In diesem Handbuch werden Sie den Konnektor kennen sowie verstehen lernen. Es wird beschrieben wie Sie den Konnektor einstellen und wie das System funktioniert,

Mehr

VPN Tunnel Konfiguration. VPN Tunnel Konfiguration IACBOX.COM. Version 2.0.2 Deutsch 11.02.2015

VPN Tunnel Konfiguration. VPN Tunnel Konfiguration IACBOX.COM. Version 2.0.2 Deutsch 11.02.2015 VPN Tunnel Konfiguration Version 2.0.2 Deutsch 11.02.2015 Dieses HOWTO beschreibt die Konfiguration eines VPN Tunnels zu einem (zentralisierten) OpenVPN Server. VPN Tunnel Konfiguration TITEL Inhaltsverzeichnis

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Anleitung E-Mail Konfiguration sowie Übersicht Mailprogramm roundcube Inhaltsverzeichnis

Anleitung E-Mail Konfiguration sowie Übersicht Mailprogramm roundcube Inhaltsverzeichnis Anleitung E-Mail Konfiguration sowie Übersicht Mailprogramm roundcube Inhaltsverzeichnis Einführung... 2-3 Servereinstellungen für die Einrichtung auf dem E-Mail Client... 4 E-Mail Adresse / Postfach einrichten...

Mehr

Testen von webbasierten Benutzeroberflächen

Testen von webbasierten Benutzeroberflächen Studiengruppe: IB6C Email: qasmi@hm.edu Dozent: Michael Theis 1 Agenda: Das eine basierte Testumgebung 2 Wer kennt diese Situationen nicht? =>Typische Fehler bei Webanwendungen! 3 Fehler wie diese sollten

Mehr

Dokumentation zur Anlage eines JDBC Senders

Dokumentation zur Anlage eines JDBC Senders Dokumentation zur Anlage eines JDBC Senders Mithilfe des JDBC Senders ist es möglich auf eine Datenbank zuzugreifen und mit reiner Query Datensätze auszulesen. Diese können anschließend beispielsweise

Mehr

WI EDI Solution. Stand 17.02.2012

WI EDI Solution. Stand 17.02.2012 WI EDI Solution Stand 17.02.2012 WIAG Überblick 2011 - SAP, SAP BW, SAP SEM/BPS, SAP BPC, SAP R/3, ABAP, Netweaver sind eingetragene Warenzeichen der SAP AG, Walldorf Folie 1 Inhalt Was ist WIEDIS? IDOC

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Paynet Adapter Spezifikationen Voraussetzungen Datum : 21.07.08 Version : 1.0.0.2 21.07.2008 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung... 3 2 Architektur... 3 2.1 Grundsätze

Mehr

Integration von. ERP-Systemen und epages 6. mit Webservices

Integration von. ERP-Systemen und epages 6. mit Webservices Integration von ERP-Systemen und epages 6 mit Webservices - Stand 10/2011 - Einleitung... 2 Grundlagen... 2 Überblick Datenaustausch... 3 Ablauf... 4 Verbindungstest... 4 Testen mit Beispieldaten... 4

Mehr

Projekt für Systemprogrammierung WS 06/07

Projekt für Systemprogrammierung WS 06/07 Dienstag 30.01.2007 Projekt für Systemprogrammierung WS 06/07 Von: Hassan Bellamin E-Mail: h_bellamin@web.de Gliederung: 1. Geschichte und Definition 2. Was ist Virtualisierung? 3. Welche Virtualisierungssoftware

Mehr

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek Speaker Andreas Holubek VP Engineering andreas.holubek@arlanis.com arlanis Software AG, D-14467 Potsdam 2009, arlanis

Mehr

Installation und Benutzung AD.NAV.ZipTools

Installation und Benutzung AD.NAV.ZipTools Installation und Benutzung AD.NAV.ZipTools Version 1.0.0.0 ALTENBRAND Datentechnik GmbH Am Gelicht 5 35279 Neustadt (Hessen) Tel: 06692/202 290 Fax: 06692/204 741 email: support@altenbrand.de Die Komponente

Mehr

PLATTFORMÜBERGREIFENDE ENTWICKLUNG MITHILFE MODELLGETRIEBENER METHODEN UND TECHNOLOGIEN

PLATTFORMÜBERGREIFENDE ENTWICKLUNG MITHILFE MODELLGETRIEBENER METHODEN UND TECHNOLOGIEN PLATTFORMÜBERGREIFENDE ENTWICKLUNG MITHILFE MODELLGETRIEBENER METHODEN UND TECHNOLOGIEN Mathias Slawik, WI (M), 3. FS Aktuelle Themen der Wirtschaftsinformatik, HTW Berlin, WS 10/11 Gliederung 2 Methode

Mehr

RAID. Name: Artur Neumann

RAID. Name: Artur Neumann Name: Inhaltsverzeichnis 1 Was ist RAID 3 1.1 RAID-Level... 3 2 Wozu RAID 3 3 Wie werden RAID Gruppen verwaltet 3 3.1 Software RAID... 3 3.2 Hardware RAID... 4 4 Die Verschiedenen RAID-Level 4 4.1 RAID

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG ALM mit Visual Studio Online Philip Gossweiler Noser Engineering AG Was ist Visual Studio Online? Visual Studio Online hiess bis November 2013 Team Foundation Service Kernstück von Visual Studio Online

Mehr