[Xpert.press] Technologie von Unternehmenssoftware || Nachrichtenorientierte Integration

Kapitel 11Nachrichtenorientierte Integration

And I would send a messageTo find out if she’s talked

But the post office has been stolenAnd the mailbox is locked

Stuck Inside of Mobile with the Memphis Blues AgainBob Dylan1

Zusammenfassung

Die nachrichtenorientierte Integration ergänzt die Integrationsformen über Daten-austausch und Funktionsaufruf. Beide werden durch Nachrichtenaustausch reali-siert, welcher nicht nur synchron sondern auch asynchron, also zeitversetzt, statt-finden kann. Nachrichtenorientierte Middleware bietet dazu Unterstützung und ge-währleistet Diensteigenschaften wie zuverlässige Übertragung, Informationssicher-heit und inhaltsbasierte Zustellung von Nachrichten. SAP Process Integration wirdals Beispiel behandelt.

Lernziel

Aufbauend auf den Kapiteln zur Integration über Datenaustausch und Funktions-aufruf die Konzepte der nachrichtenorientierten Integration kennenlernen.

1 Dylan B (1966) Blonde on Blonde. LP, Columbia Records.

235R. Weber, Technologie von Unternehmenssoftware, DOI 10.1007/978-3-642-24423-0_11,© Springer-Verlag Berlin Heidelberg 2012

236 11 Nachrichtenorientierte Integration

11.1 Interaktionsmuster

In diesem Kapitel sehen wir uns verschiedene Aspekte der nachrichtenorientiertenIntegration an, wie Interaktionsmuster, die Qualität (Zuverlässigkeit, Informations-sicherheit) der Nachrichtenübertragung und Dienstausführung und den Grad derKopplung der Kommunikationspartner. Sie gelten gleichermaßen für die Integrati-on über Datenaustausch wie für die funktionsorientierte Integration.

Die Interaktionen beim Funktionsaufruf (siehe Abb. 10.1) und beim Datenaus-tausch (siehe Abb. 9.2) sind ähnlich: der Sender (Client) sendet eine Nachricht einesbestimmten Aufbaus, in XML codiert, an den Empfänger (Server) und kann ei-ne Antwortnachricht erhalten. Abstrahierend von der Bedeutung können wir diefolgenden Interaktionsmuster des Nachrichtenaustauschs für Web-Services aus-machen (Abb. 11.1). Insofern lassen sich Web-Services auch aufbauend auf demKonzept der Nachricht statt des Funktionsaufrufs (RPC) verstehen, und das Modellgeht somit über übliche RPC-artige Modelle hinaus.

� Anfrage-Antwort (Request-Response): Dieses Interaktionsmuster wird bei Web-Services für einen Funktionsaufruf verwendet: auf die Anfrage folgt die Antwort.Hier stellt sich die Frage, ob der Client blockiert und auf die Antwort wartet (syn-chroner Aufruf) oder ob die Antwort erst später zeitversetzt in einer getrenntenKommunikation erfolgt (asynchron)2. Letzteres lässt sich auch durch eine Ein-wegkommunikation kombiniert mit einer Benachrichtigung (s. u.) ausdrücken.

� Einwegkommunikation (One Way): Es fließt nur eine Nachricht vom Client zumServer. Dies könnte ein Datenaustausch sein (das Anlegen von Daten, ohne Emp-fangsquittierung, vgl. Kap. 9) oder ein asynchroner Funktionsaufruf, bei dem eskeinen Rückgabewert gibt.

� Benachrichtigung (Notification): Dies ist vom Nachrichtenaustausch her gese-hen der umgekehrte Weg zur Einwegkommunikation. Allerdings soll der In-halt lediglich eine Information sein, nicht wie bei der Einwegkommunikationeine ändernde Operation. Dieses Interaktionsmuster kann das Auslösen eines Er-eignisses wiedergeben (vgl. Abschn. 2.4) oder das Ergebnis eines asynchronenFunktionsaufrufs, in Verbindung mit dem Interaktionsmuster Einwegkommuni-kation für den Aufruf.

� Antwort erbitten (Solicit Response): In diesem eher selten verwendeten Inter-aktionsmuster kehren Client und Server ihre Rollen um: der Server beginnt dieInteraktion.

2 Tatsächlich gibt es im Detail wiederum verschiedene Möglichkeiten, wie man sie vom RPCkennt. Der Client kann warten, bis der Server den Aufruf angenommen hat („normaler“ asyn-chroner RPC) oder sich sofort zurückmelden (Einweg-RPC). Ein Spezialfall ist der verzögertesynchrone RPC. Er besteht aus zwei asynchronen RPCs, der erste vom Client zum Server, derzweite vom Server zum Client, um die Ergebnisse zu übergeben. Eine Variante davon ist, dass derClient später selbst nach dem Ergebnis fragt (Tanenbaum und van Steen 2007, S. 158).

11.1 Interaktionsmuster 237

Abb. 11.1 Interaktionsmus-ter (1)

Client ServerAnfage-Antwort

Client ServerEinweg

Client ServerBenachrichtigung

Client ServerAntwort erbitten

Diese Interaktionsmuster werden üblicherweise für Web-Services aufgeführt. Ineinem WSDL-Dokument entscheidet die Reihenfolge der aufgeführten Nachrich-ten, um welchen Interaktionstyp es sich handelt (van Lessen et al. 2011, S. 47). DasInteroperabilitätsprofil WS-I Basic Profile (Web Services Interoperability Organiza-tion 2011) erlaubt allerdings nur Anfrage-Antwort und Einwegkommunikation (vanLessen et al. 2011, S. 84). Es lassen sich beliebig viele weitere Interaktionsmusterfinden, wenn wir nicht von maximal einer Nachricht in Hin- und Rückrichtung aus-gehen (Abb. 11.2):

� Sitzung: Mehrere zusammengehörige Nachrichten fließen vom Client zum Ser-ver. Sie werden im Rahmen einer Sitzung (Session) ausgetauscht. Die Dienstauf-rufe, realisiert durch die Nachrichten, stehen in Abhängigkeit zueinander undkönnen zu dem Zweck auf den Sitzungszustand, im Hauptspeicher gehaltenegemeinsame Daten, zugreifen.

� Beliebig: In diesem allgemeinsten Fall werden mehrere Nachrichten zwischenden Kommunikationspartnern in einer abgestimmten Reihenfolge ausgetauscht.Die Rollen „Client“ und „Server“ erscheinen bei dieser freien Interaktionsformnicht mehr passend.

Und schließlich können wir die Kommunikation von zwei auf beliebig vieleKommunikationspartner ausweiten. Oft wird dies in eine Reihe von Zweierkom-munikationen zerlegt. Ein wichtiger Sonderfall wird die Kommunikation über einenNachrichten-Broker sein (siehe Abschn. 11.3.2).

Die Interaktionsmuster „Anfrage-Antwort“ bis „Antwort erbitten“ lassen sich alsModelle eines Methodenaufrufs eines Geschäftsobjekts bzw. einer Aktivität in ei-nem Geschäftsprozess sehen. Das Interaktionsmuster „Beliebig“ gibt dagegen einenkooperativen Geschäftsprozess bzw. eine Sicht darauf wieder. Hierbei kommuni-zieren zwei oder mehr Anwendungen inner- oder zwischenbetrieblich in mehrerenSchritten miteinander. Das Interaktionsmuster „Sitzung“ ist ein Grenzfall: es könn-te als Komposition einfacherer Methoden oder Aktivitäten zu komplexeren gesehenwerden oder als ein Geschäftsprozess. Die Komposition und Koordination von Ak-


Abb. 11.2 Interaktionsmus-ter (2)

Client ServerSitzung

P1 P2beliebig, zwei Partner

P1 P2beliebig, N Partner Pn

tivitäten bzw. Diensten, insbesondere hinsichtlich Geschäftsprozesse, werden wiruns in Kap. 12 ansehen.

Die Integrationsformen „Datenaustausch“, „Funktion“ und „Geschäftsprozess“sind also eng miteinander verzahnt. In der Informatik kennen wir die Integrati-onsmittel „gemeinsamer Speicher“ und „Nachrichtenaustausch“ bei parallelen, ver-teilten Systemen. Den gemeinsamen Speicher (in unserem Fall persistent) habenwir in Form der Datenintegration bei operativen Systemen sowie bei analytischenSystemen kennengelernt. Nachrichtenaustausch findet in einer innerbetrieblichenSystemlandschaft sowie bei der zwischenbetrieblichen Integration statt.

11.2 Zuverlässigkeit

Anders als beim lokalen Funktionsaufruf können beim entfernten FunktionsaufrufKommunikationsfehler beim Übermitteln der Anfrage- oder Antwortnachricht auf-treten. Auch können Client oder Server zeitweise nicht verfügbar sein, nämlich derServer vor oder während des Aufrufs, der Client nachdem die Anfrage übermitteltwurde. Entsprechend gibt es verschiedene „Aufrufsemantiken“:

� „vielleicht“ (maybe, Best Effort): Keine Fehlerbehebungsmechanismen werdeneingesetzt. Geht alles gut, verhält sich der entfernte Aufruf wie ein lokaler, bisauf die Performanz und eingeschränkte Möglichkeiten zur Parameterübergabe,z. B. wird kein Call-by-Reference verwendet. Bei lesenden Zugriffen kann dies

11.3 Nachrichtenorientierte Middleware 239

ausreichend sein; glückte der Aufruf nicht, führt ihn der Client bei Bedarf späternoch einmal aus.

� „mindestens einmal“ (at least once): Erhält der Client keine Antwort, wird derAufruf wiederholt übertragen und ausgeführt, solange bis eine Antwort kommtoder eingeschätzt wird, dass keine Antwort in absehbarer Zeit zu erwarten ist.Für viele Funktionen ist eine wiederholte Ausführung nicht sinnvoll. Der „Klas-siker“ ist die Überweisung auf ein Konto. Der Unterschied zu „vielleicht“ ist,dass sich das Laufzeitsystem, nicht der Client, um die wiederholte Übertragungkümmert.

� „höchstens einmal“ (at most once): Dies ist ähnlich wie „mindestens einmal“.Allerdings werden hier Duplikate des Aufrufs entdeckt und herausgefiltert. DerServer speichert die Antwortnachricht ab und übermittelt diese bei Bedarf mehr-mals, führt die Funktion allerdings nicht erneut aus.

� „genau einmal“ (exactly once): Dies wird i.a. in Unternehmenssoftware beischreibenden Zugriffen gefordert. Die Aufrufsemantik „genau einmal“ wirdmit Hilfe von Transaktionsmechanismen auf Client- und Serverseite (getrennteTransaktionen) sowie mithilfe des Web-Service-Standards Reliable Messagingerreicht. Durch die Transaktionen auf Client- und Serverseite wird die Übermitt-lung des Aufrufs persistiert. Das Nachrichtenübertragungssystem kann dadurcheinen Aufruf wiederholen, selbst wenn Client, Server oder das Nachrichtenüber-tragungssystem selbst zeitweilig nicht verfügbar sind (Systemabsturz). „ReliableMessaging“ garantiert durch wiederholte Übertragung, dass die Nachricht tat-sächlich vom Client- zum Serversystem gelangt. Eine detaillierte Behandlungdavon, insbesondere Sequenzdiagramme, findet sich in Huvar et al. (2008,S. 119 ff.).

� „genau einmal in der richtigen Reihenfolge“ (exactly once in order): Dies be-trifft das Interaktionsmuster „Sitzung“, wo die einzelnen Nachrichten in derkorrekten Reihenfolge übermittelt und verarbeitet werden müssen.

11.3 Nachrichtenorientierte Middleware

11.3.1 Warteschlangensysteme

Nachrichten laufen über einen Kommunikationskanal; bei Web-Services nahmenwir zunächst an, dass dieser HTTP ist. Die Kommunikation ist synchron in demSinne, dass der Sender wartet, bis er die Antwortnachricht erhält, und erst dannsein Programm fortsetzt. Die Nachrichten werden nicht dauerhaft gespeichert, siebestehen nur während des Kommunikationsvorgangs, sind nur „auf der Leitung“.In diesem Kapitel verwenden wir lieber die Bezeichnung „Sender“ als „Client“, daso die Richtung der Nachrichtenübertragung deutlich wird; teilweise ist der Serverder Sender, nämlich wenn die Antwortnachricht getrennt übertragen wird.


bisher:S E

Request-Nachricht

Response-NachrichtHTTP überTCP/IP-

Verbindung

synchron

jetzt:

S E

(persistente) Wartschlange von E

(persistente) Wartschlange von S

asynchron

Abb. 11.3 Nachrichtenorientierte Kommunikation

Diese synchrone Kommunikation mit transienten Nachrichten ist nur eine Spiel-art der nachrichtenorientierten Integration (Abb. 11.3). Sehen wir uns in derselbenAbbildung den unteren Teil „jetzt“ an. Es handelt sich dabei um ein Warteschlan-gensystem (Message Queuing System), allgemeiner auch nachrichtenorientierteMiddleware (Message-oriented Middleware, MOM) oder Nachrichtenübertra-gungssystem genannt. MOM bietet noch weitere Funktionalität, wie ein Verfalls-datum oder eine Priorität, welche für eine Nachricht angegeben werden können(Alonso et al. 2004, S. 62), Lastverteilung und Ausfallsicherheit (Illik 2007, S. 45).

Der Sender kommuniziert die Anfragenachricht nun asynchron und übermitteltdiese an eine persistente Warteschlange für den Empfänger. Zwar sind auch transi-ente Warteschlangensysteme möglich (Tanenbaum und van Steen 2007, S. 166 ff.),üblich sind aber die persistenten. Ist die Nachricht in der Warteschlange abgelegt,ist die Arbeit für den Sender erst einmal erledigt. Im Falle des Datenaustauschsreichte dies schon aus. Der Empfänger nimmt irgendwann die Nachricht aus derWarteschlange und arbeitet sie ab, z. B. führt er den gewünschten Funktionsaufrufaus. Je nachdem ob eine Antwortnachricht nötig ist, erzeugt sie der Empfänger.In gleicher Weise wie bei der ersten Nachrichtenübermittlung geschieht in demFall eine zweite in der Rückrichtung. Da die beiden Nachrichtenübermittlungenentkoppelt sind, muss dafür gesorgt werden, dass die Antwortnachricht mit derAnfragenachricht korreliert wird, z. B. durch eine Sequenznummer, wie es bei derDatenkommunikation üblich ist. Außerdem muss der Empfänger die Adresse desSenders (bzw. dessen Sendewarteschlange; jede Anwendung hat eine Sende- und ei-ne Empfangswarteschlange (Tanenbaum und van Steen 2007, S. 174) kennen, damitdie Antwortnachricht zurückgeschickt werden kann. Bei HTTP war diese Adressewährend des Wartens auf die Antwortnachricht implizit bekannt.


S

E1

E2

E3gemeinsameWarteschlangevon E1, E2, E3

einer von den dreienbekommt die Nachricht

Abb. 11.4 Gemeinsame Warteschlange

Nachrichtenorientierte Kommunikation zwischen Menschen ist uns durch E-Mail vertraut. Wenn wir eine Nachricht an das E-Mail-System übergeben, vertrauenwir darauf, dass sie ausgeliefert wird. Die Erfahrung zeigt, dass dies leidlich gut,wenn auch nicht perfekt funktioniert. Bei einer nachrichtenorientierten Kommuni-kation zwischen Anwendungen erwarten wir dagegen höchste Zuverlässigkeit.

Im Gegensatz zur funktionsorientierten Integration, wie wir sie in Kap. 10 ken-nengelernt haben, und entsprechend dem aus der Programmierung bekannten Funk-tionsaufruf ist die Kommunikation hier asynchron: der Sender übermittelt seine An-fragenachricht und braucht nicht unmittelbar auf die Antwortnachricht zu warten.Irgendwann wird er sie natürlich in seiner Warteschlange empfangen und bearbei-ten, aber es entsteht eine zeitliche Entkopplung. Dieser Vorteil zur Laufzeit kannsich in einer höheren Komplexität bei der Erstellung von Anwendungen zur Defi-nitionszeit niederschlagen, da dieses Programmiermodell weniger vertraut ist. Beidieser Entkopplung muss der Empfänger nicht sofort zur Bearbeitung bereit ste-hen. Er muss nicht einmal betriebsbereit sein, sein System könnte also temporärnicht verfügbar sein, sofern seine Warteschlange aufnahmebereit ist. PersistenteWarteschlangen können also die zuverlässige Nachrichtenübertragung (s. u.) ge-währleisten, man nennt sie daher auch transaktionale Warteschlangen (Alonso et al.2004, S. 64).

Eine Variante zeigt Abb. 11.4. Hier teilen sich mehrere Empfänger eine ge-meinsame Warteschlange. Die Idee hierbei ist, dass zur Lastverteilung mehrereEmpfänger als „Bedieneinheiten“ vorgesehen sind. Jeder dieser Empfänger könntejede Anfragenachricht gleichermaßen bearbeiten. Durch die Anpassung der Emp-fängeranzahl kann die Leistung skaliert werden.

Es ist möglich, neben den Warteschlangen der Anwendungen und ihren War-teschlangenmanagern Zwischenknoten einzuführen, Router oder Relais genannt.Somit wird der Kommunikationsmechanismus Store-and-Forward verwendet. DieRouter könnten in einem Warteschlangennetz mit dynamischer Topologie dasRouting-Wissen haben, die Warteschlangenmanager der Anwendungen brauchendann nur noch ihren nächsten Router zu kennen (Tanenbaum und van Steen 2007,S. 173).

Sender und Empfänger kommunizieren mit der MOM über ein API. Ein üblichesist der Java Messaging Service (JMS) (recht ausführlich in Mandl (2009, S. 153 ff.)


Abb. 11.5 Nachrichten-Broker E1

E2

E3

Nachrichten-Broker

......... .........

S

beschrieben), welcher aber nichts über das interne Arbeiten der MOM oder ihreKommunikation mit anderen MOM-Systemen aussagt.

11.3.2 Nachrichten-Broker

Bei dieser Variante einer MOM steht zwischen Sendern und Empfängern ei-ne vermittelnde Komponente, der Nachrichten-Broker (Message-Broker, sieheAbb. 11.5), auch Integration-Broker oder bei serviceorientierten ArchitekturenService-Bus genannt. Der Nachrichten-Broker ist das zentrale Konzept der Enter-prise Application Integration (EAI ). Man kann ihn als ein Warteschlangensystemmit Zusatzfunktionalität sehen. Die Sender adressieren nicht direkt einen Emp-fänger, vielmehr richten sie die Anfragenachricht an den Nachrichten-Broker. DerNachrichten-Broker ermittelt für eine eingehende Nachricht, welchen Empfän-gern sie zugestellt werden soll. Man nennt dies Routing . Es kann sein, dass eineNachricht an mehrere Empfänger gehen soll (implizites Multicast). Die Grund-lage der Entscheidung, wer die Nachricht erhalten soll, können insbesondere derNachrichtentyp (z. B. „Bestellung“) oder sogar Teile des Nachrichteninhalts sein.Selbstverständlich kann der Empfänger auch explizit angegeben werden, die Nach-richt wird dann lediglich durchgeschleust. Damit der Nachrichten-Broker dasRouting durchführen kann, ist ein Teil des Anwendungs- bzw. Integrationswissensbei ihm abgelegt. In diesem Fall hat er nicht nur technisches Kommunikations-wissen. Für die Nachvollziehbarkeit und das Debugging zur Fehlersuche ist dieseverteilte Information hinderlich. Auch die Performanz könnte darunter leiden –letztlich soll der Nachrichten-Broker die Nachrichten ja schnell verteilen (Alonsoet al. 2004, S. 75).

Ein Nachrichten-Broker kann eine Nachricht nicht nur unangetastet an die ge-eigneten Empfänger leiten. Möglicherweise verwenden Sender und Empfängerzwar inhaltlich äquivalente Nachrichten, jedoch sind die Nachrichtenformate un-terschiedlich. In dem Fall kann der Nachrichten-Broker die Formate konvertieren(Mapping) (Abb. 11.6). Wichtig ist dabei natürlich, dass die Zielinformation aus derQuellinformation „berechnet“ werden kann. Für das Mapping sind verschiedeneTechniken verwendbar (siehe Abschn. 9.3.5).


Anfrage-Nachrichtm1

Anfrage-Nachrichtm1‘

Nachrichten-Broker

Antwort-Nachrichtm2

Antwort-Nachrichtm2‘

Sender Empfänger

Abb. 11.6 Mapping

ekopS-dna-buHtknuP-uz-tknuP

Broker

Abb. 11.7 Hub-and-Spoke-Architektur

Bei einem Nachrichten-Broker, welcher zwischen Sendern und Empfängernvermittelt, ergibt sich eine Hub-and-Spoke-Architektur (Nabe und Speichen)(Abb. 11.7) statt Punkt-zu-Punkt-Verbindungen. Die kommunizierenden Syste-me sind als kleine Kreise dargestellt. Bei Punkt-zu-Punkt-Verbindungen gibt esdirekte Verbindungen zwischen den Systemen, jedoch muss nicht jedes mit jedemanderen verbunden sein. Bei der Hub-and-Spoke-Architektur sind alle Systeme nurmit dem Nachrichten-Broker verbunden, indirekt ist dabei jedoch theoretisch jedesSystem mit jedem anderen verbunden. Entsprechend eignet sich eine solche Archi-tektur für die innerbetriebliche Anwendungsintegration. Vom Nachrichten-Brokeraus können zwar auch Nachrichten nach außen an Partnerunternehmen gehen, aberunabhängige Unternehmen werden üblicherweise keine zentrale Steuerung ihrerAnwendung akzeptieren. Daher kommt er zur zwischenbetrieblichen Integration indieser Form eher nicht zum Einsatz (Alonso et al. 2004, S. 127).

Bei Punkt-zu-Punkt-Verbindungen gibt es topologisch n * (n � 1)/2 Ver-bindungen, bei der Hub-and-Spoke-Architektur nur n Stück. Allerdings betrifftdiese Aussage nur die Systemverbindungen – und am lokalen unternehmensinternenNetz hängen in der Regel sowieso alle Systeme, daher sollte man diese Aussagerelativieren. Wichtiger ist nämlich, dass zwischen zwei Systemen Anwendungen(Programme, Prozesse) kommunizieren, insofern können mehrere Anwendungs-verbindungen bestehen. In Abb. 11.8 sehen wir vier Anwendungsverbindungen,welche durch den Nachrichten-Broker gehen. Zwischen dem Sender und Empfän-


Sender

Empfänger 1

Empfänger 2

Empfänger 3

1

2

3

4

Nachrichten-Broker

Abb. 11.8 Anwendungsverbindungen

ger 1 gibt es zwei Anwendungsverbindungen mit Nummern 1 und 2, z. B. für zweiverschiedene Dienstoperationen. Die Anwendungsverbindung Nummer 3 geht da-gegen vom Sender sowohl zu Empfänger 2 als auch zu Empfänger 3; der schwarzePunkt deutet die Aufspaltung an. Schließlich gibt es noch eine vierte Anwendungs-verbindung, diesmal zwischen dem Sender und Empfänger 3. In diesem Fall sindalso drei Punkt-zu-Punkt-Anwendungsverbindungen vorhanden und eine, welcheeinem Multicast entspricht.

Vorteile kann die zentrale Stelle Nachrichten-Broker dennoch auch in diesemFall bringen:

� Es kann verfolgt werden, welche Verbindungen in einem Systemverbund genutztwerden,

� alle Daten werden zentral protokolliert (Logging),� die Administration der Kommunikation kann sich auf den Nachrichten-Broker

konzentrieren.

Wenn sich selbst in Szenarien geringerer Integration Vorteile beim Einsatz einesNachrichten-Brokers ergeben, was spricht dann gegen seinen Einsatz (siehe auchAlonso et al. 2007, S. 81 f.)?

� Aufwand: Ein Nachrichten-Broker erfordert Aufwand verschiedener Art. Zu-nächst natürlich die Software-, Hardware- und Personalkosten (Administration)für den Betrieb des Nachrichten-Brokers. Daneben die Einführungskosten, ins-besondere die Gestaltung oder Anpassung (Kapselung) der Anwendungen der-art, dass sie zum Einsatz für den Nachrichten-Broker tauglich sind. Eine einzelnePunkt-zu-Punkt-Verbindung ist dagegen meistens weniger aufwändig.

� Performanz: Alle Nachrichten durch den Nachrichten-Broker zu „schleusen“kostet Performanz. Natürlich kann die Protokollierung z. B. beim Aufde-cken von Fehlern Nutzen bringen. Leistungsmessungen im Rahmen einer


Fallstudie haben ergeben, dass der Unterschied im Vergleich zu Punkt-zu-Punkt-Funktionsaufrufen groß sein wird (Schmitt 2007, S. 166 ff.)3.

� Abhängigkeit vom Nachrichten-Broker: Hierbei ist nicht nur der Nachrichten-Broker als „Single-Point-of-Failure“ zur Laufzeit gemeint. Die Verbindung voneinem Anwendungssystem zu einem Nachrichten-Broker und die Entwicklun-gen im Nachrichten-Broker (z. B. Abbildungen zwischen Nachrichten) könnenrecht spezifisch für das eingesetzte Nachrichten-Broker-Produkt sein und müs-sen bei einem Produktumstieg nachgezogen werden.

� Teil der Anwendungslogik im Nachrichten-Broker: Der Nachteil wurde bereitsoben erwähnt.

11.3.3 Veröffentlichen und Abonnieren (Publish and Subscribe)

Ein Konzept, welches sich mit Nachrichten-Brokern verwirklichen lässt, ist Veröf-fentlichen und Abonnieren, gebräuchlicher unter dem englischen Namen Publishand Subscribe (Abb. 11.9). Hierbei abonniert (subcribe) ein Abonnent ein Thema4.„Thema“ ist ein abstrakter Begriff, es könnte z. B. der Nachrichtentyp wie „Be-stellung“ sein, „Bestellung für den Lieferanten 4711“ oder auch „Bestellung 501“.Zu diesem Zweck gibt es im Nachrichten-Broker eine Abonnementtabelle. Für einThema kann es mehrere Abonnenten geben. Trifft eine Nachricht zu dem Themaein, erhalten alle Abonnenten die Nachricht (bzw. eine Kopie davon) zugestellt. Istein Abonnent nicht mehr an einem Thema interessiert, löscht er sich aus der Abon-nementtabelle. Das Konzept „Veröffentlichen und Abonnieren“ wird auch bei derKommunikation per Ereignis eingesetzt. Die Ereignisse entsprächen den Nachrich-ten, die Ereignisbehandler den Abonnenten. In der Literatur findet sich dafür derName „Event-Condition-Action-Paradigm“, z. B. in Alonso et al. (2004, S. 263).Ereignisbehandler werden demnach nur dann angestoßen, wenn die in der Abonne-menttabelle formulierte Bedingung über den Ereignisparametern erfüllt ist.

Das Thema kann beim Abonnement auf Typ- oder Instanzebene sein. Das obigeBeispiel „Bestellung“ ist auf Typebene: der Empfänger wartet auf eine beliebigeBestellung. Dagegen ist „Bestellung 501“ auf Instanzebene: der Abonnent wartetnur auf eine Antwort zur Bestellung mit der Nummer 501, andere interessieren ihnnicht.

3 Das Ergebnis hängt natürlich davon ab, was womit verglichen wird (z. B. RPC oder SOAP-basierte Web-Services). In Schmitt (2007) werden verschiedene Techniken verglichen und Leis-tungsmessungen durchgeführt.4 Dies ist die Terminologie von JMS. Eine andere Sprechweise wäre „Nachrichten eines be-stimmten Typs“, wobei aber auch ein Instanzbezug möglich ist. Alonso et al. (2004, S. 76)unterscheiden zwischen typbasiertem Abonnement, wobei auch geschachtelte Subtypen möglichsind, z. B. PurchaseOrder.newPurchaseOrder, und parameterbasiertem Abonnementder Art „type = ... and customer = ... and quantity = ...“.


Abb. 11.9 Publish and Subs-cribe

E1

E2

E3

......... .........

S

Thema Abonnenten

E1, E3

E1, E5

........ .............

Abonnementtabelle:

Nachrichten-Broker

Der oben erwähnte JMS hat neben Punkt-zu-Punkt-Operationen auch Publish-and-Subscribe-Operationen in seinem API (Alonso et al. 2004, S. 76).

11.4 Zwischenbetriebliche gegenüberinnerbetrieblicher Integration

Haben die innerbetriebliche und die zwischenbetriebliche Integration auch gemein-same Ziele, wie durchgängige, beschleunigte Geschäftsprozesse, so ergeben sichdoch bei der zwischenbetrieblichen Integration besondere Anforderungen (Alonsoet al. 2004, S. 126):

� Unternehmen stehen in Konkurrenz zueinander. Eine zentrale Steuerung von An-wendungen verschiedener Unternehmen, wie durch einen Nachrichten-Broker,wird im Allgemeinen nicht gewünscht. Vielmehr werden die UnternehmenPunkt-zu-Punkt miteinander kommunizieren.

� Wegen der Übermittlung über öffentliche Netze, unsicherer als ein Intranet,sind stärkere Sicherheitsmechanismen erforderlich. Bei Web-Services werdensie technisch durch den Standard WS-Security (OASIS 2002) bereitgestellt,welcher andere Web-Service-Standards ergänzt. WS-Security definiert, welcheSOAP-Kopfattribute für die Authentifizierung verwendet werden können, z. B.UserNameToken für Benutzer/Passwort und BinarySecurityToken fürZertifikate (Alonso et al. 2004, S. 193). Außerdem spielt Verschlüsselung, zu-mindest von Teilen einer Nachricht, eine Rolle. Lassen sich Web-Services bereitsmit einer gewissen Sicherheit per HTTPS übertragen, so ist oftmals doch eineEnde-zu-Ende-Verschlüsselung sinnvoll.

11.5 Diensteigenschaften 247

� Tendenziell ist die Kopplung zwischen Unternehmen loser als unternehmensin-tern. Asynchrone Kommunikation, wie wir sie von EDI kennen, ist verbreiteterals synchrone Funktionsaufrufe. Denn beim Empfang einer Nachricht kann zurBearbeitung z. B. eine innerbetriebliche Abstimmung nötig sein, so dass sichlange Bearbeitungszeiten ergeben.

11.5 Diensteigenschaften

Das Senden einer Anfragenachricht und das Empfangen der Antwortnachricht(wenn sie nötig ist) können wir – in Fortsetzung unserer Diskussion über serviceori-entierte Architektur (siehe Kap. 10) – als Dienst bzw. genauer als Dienstoperationbezeichnen. Wiederum abstrahieren wir von der Art des Dienstes (Datenaustausch,Funktionsaufruf). Festlegungen können zudem für mehrere Dienstaufrufe nachein-ander (transaktional, in der korrekten Reihenfolge) getroffen werden. Betreiben wirden Dienstaufruf mit einer MOM-Infrastruktur, so können wir Diensteigenschaf-ten festlegen, welche die Infrastruktur gewährleisten oder zumindest unterstützenkann. Sie geben die in den vorigen Abschnitten genannten Kriterien wieder. Wirorientieren uns bei der Darstellung an Huvar et al. (2008, S. 115 ff.):

� Interaktionsmuster: Diese haben wir uns in Abschn. 11.1 angesehen.� Blockierung: Wartet der Sender auf die Antwortnachricht und blockiert daher

(blockierend bzw. synchron) oder macht er unmittelbar weiter, üblicherweise mitanderen Aufgaben (nicht blockierend bzw. asynchron)?

� Sitzung: Finden mehrere Dienstaufrufe nacheinander statt, sind diese vollkom-men unabhängig voneinander (zustandslos)? Oder wird eine Sitzung aufgebaut,in der nacheinander mehrere Dienstoperationen geschehen und der Zustand zwi-schen den Aufrufen gehalten wird (zustandsbehaftet)?

� Zuverlässigkeit: Ist die Übertragung unzuverlässig, d. h. kann es sein, dass dieNachricht den Empfänger zum Beispiel aufgrund eines Kommunikationsfehlersnicht erreicht? Oder ist die Übertragung garantiert (zuverlässig, d. h. „genau ein-mal“ oder gar „genau einmal in der richtigen Reihenfolge“)?

� Transaktionsverhalten: Dies betrifft die Kapselung mehrerer aufeinanderfolgen-der Dienstaufrufe zu einer Transaktion. Wenn die Eigenschaft „transaktional“gesetzt ist, werden entweder alle oder keiner der Dienstaufrufe ausgeführt.

� Commit-Handling: Soll ein Commit zum Abschluss einer Transaktion automa-tisch von der Infrastruktur ausgelöst werden oder explizit vom Aufrufer (mitCommit/ohne Commit)?

Für jeden Dienst (eigentlich für jede Dienstoperation) können diese Eigenschaf-ten angegeben werden. Dabei sind jedoch nicht alle Kombinationen möglich odersinnvoll. Korrelationen bestehen zwischen:

� Interaktionsmuster und Blockierung: Für Anfrage-Antwort ist meist „synchron“sinnvoll, jedoch nicht zwingend.


� Blockierung und Zuverlässigkeit: „Nicht blockierend“ und „zuverlässig“ istmeist eine gute Kombination.

Als weitere Diensteigenschaften lassen sich sehen, auch wenn sich diese inhalt-lich, nicht durch Konfiguration ergeben:

� Dienstinhalt: Ist der Dienstinhalt ein Datum oder ein Funktionsaufruf ?� Adressierung: Wird der Empfänger direkt adressiert oder indirekt (z. B. über

einen Nachrichten-Broker identifiziert oder nach dem Prinzip „Veröffentlichenund Abonnieren“)?

In Aufgabe 11.2 können Sie überlegen, welche Eigenschaften für verschiedeneDienste angemessen sind.

11.6 Beispiel: SAP Process Integration

Ein üblicher Verwendungszweck von SAP Process Integration (SAP PI) (Krimmelund Orb 2010) ist es, SAP-Systeme zu verbinden, zusätzlich eventuell noch ei-nige Nicht-SAP-Systeme. SAP-Systeme sind bereits für SAP PI mit Software zumNachrichtenaustausch vorbereitet. SAP PI hieß früher SAP Exchange Infrastructure(SAP XI), was den Nachrichtenaustausch deutlicher herausstellte.

Ausgetauscht werden sog. PI-Nachrichten. Dies sind prinzipiell SOAP-Nach-richten der Art, wie wir sie bereits kennengelernt haben. Neu ist, dass

� der Nachrichtenkopf verwendet wird und darin Information wie synchro-ne/asynchrone Übertragung und verschiedene weitere Informationen in PI-spezifischen Laufzeit-, Performanz- und Fehlerattributen gesetzt werden,

� Anlagen (Attachments) vorhanden sein können.

Zur Beschreibung der Dienste wird ein eingeschränktes WSDL verwendet(Krimmel und Orb 2010, S. 96).

Abbildung 11.10 zeigt die Interaktion eines SAP-Anwendungssystems mitdem PI Integration Server, dem Nachrichten-Broker von SAP PI. Das SAP-Anwendungssystem tauscht mit dem PI Integration Server PI-Nachrichten aus.Die Beschreibung ist hier unabhängig davon, ob das SAP-Anwendungssystem zumSenden oder Empfangen (oder beidem) verwendet wird. Die vom Sender geschick-te Anfragenachricht und die vom Empfänger erhaltene Anfragenachricht müssennicht übereinstimmen, vielmehr können sie durch eine Abbildung (Mapping) ange-passt worden sein (Entkopplung). Gleiches gilt natürlich für die Antwortnachricht.Die Nachrichten geben Schnittstellen von Diensten wieder, welche im EnterpriseService Repository abgelegt sind (vgl. Abschn. 10.6).

Der zentrale Teil des PI Integration Server ist die Integration Engine. Ein SAP-Anwendungssystem hat eine lokale Integration Engine, womit es mit dem PI In-tegration Server die Kommunikation über PI-Nachrichten abwickelt. Möchte ein

11.6 Beispiel: SAP Process Integration 249

SAP-Anwendungssystem

lokaleIntegration

Engine

PI Integration Server

IntegrationEngine

PI-Protokoll

PI-Nachricht

Anwendungs-programm

Proxy

Proxy-Laufzeit

Abb. 11.10 SAP PI: Verbindung SAP-Anwendungssystem – Integration Server

Adapteradapter-

spezifischesProtokoll

PI-Nachricht

Nicht-SAP-Anwendungssystem PI Integration Server

Abb. 11.11 SAP PI: Verbindung Nicht-SAP-Anwendungssystem – Integration Server

Anwendungsprogramm eine Nachricht kommunizieren (senden/empfangen), wirddazu ein Proxy verwendet (dies entspricht unserem Stub, wie in Kap. 10 beschrie-ben). Während der Proxy dienstspezifisch ist, sind die in der Folge verwendeteProxy-Laufzeit und die lokale Integration Engine generische Komponenten. DieProxy-Laufzeit schreibt z. B. den Sender in den PI-Nachrichtenkopf.

Anders gestaltet sich die Kommunikation des PI Integration Server mit einemNicht-SAP-Anwendungssystem (Abb. 11.11). Dieses ist nicht von sich aus befähigt,das PI-Protokoll zu sprechen, d. h. PI-Nachrichten zwischen Integration Enginesauszutauschen. Stattdessen wird das Nicht-SAP-System über einen Adapter an-geschlossen, welcher üblicherweise spezifisch für das Nicht-SAP-System ist. DerAdapter setzt eine Nachricht in das PI-Nachrichtenformat um und umgekehrt. SAPoder Partnerfirmen haben für einige gängige Softwaresysteme Adapter entwickelt.Manche Adapter sind generisch, wie der Dateiadapter.


Je nach Anforderung an den Nachrichtenaustausch kommen unterschiedlichmächtige und performante Verfahren zum Einsatz (Krimmel und Orb 2010,S. 26 ff.):

� Für den zustandsbehafteten Austausch von Nachrichten dient die Business Pro-cess Engine: hier besteht eine Prozessdefinition bzw. ein Protokoll, dass be-stimmte Nachrichten in einer festgelegten Reihenfolge auszutauschen sind (vgl.Kap. 12).

� Für den zustandsfreien Nachrichtenaustausch dient die Advanced Adapter En-gine, welche immer noch Routing und eine Abbildung der Nachrichtenformate(Mapping) durchführen kann, jedoch keine Bearbeitung durch die IntegrationEngine erfordert, was die Performanz verbessert.

� Sind auch Routing und Mapping nicht erforderlich, kann die Kommunikationdirekt erfolgen, bei nochmals verbesserter Performanz. Die Dienste der zentralenKonfiguration und des Monitoring werden jedoch weiterhin verwendet.

Technisch baut SAP PI sowohl auf einem ABAP- als auch auf einem Java-Applikationsserver auf (vgl. Kap. 3).

11.7 Übungen und Lösungsvorschläge

11.7.1 Übungen

Aufgabe 11.1 (Verschiedene Integrationsarten, inklusive Nachrichten-Broker):

Diese Aufgabe betrifft alle bisher behandelten Integrationstechniken.Ein Sachbearbeiter möchte sowohl Kundenstammdaten als auch -kontakte erfas-

sen, ansehen und suchen. Die Daten befinden sich in einem ERP- bzw. in einemCRM-System.

a) Welche Integrationsmöglichkeiten (Benutzeroberfläche, Anwendungslogik, Da-ten) zwischen den beiden Systemen sind hierbei denkbar und wie sähen diesejeweils im konkreten Fall aus?

b) Würden Sie hierbei einen Nachrichten-Broker verwenden? Was spricht in unse-rem Fall dafür, was dagegen?

Aufgabe 11.2 (Identifizieren von Diensten):

In einem Pilotprojekt „Dienstorientierter Vertrieb“ soll bei einem Unternehmengeprüft werden, wie der dienstorientierte Gedanke für einen Teilbereich des Ver-triebs eingesetzt werden kann. Im Unternehmen werden drei Systeme eingesetzt:ERP, CRM und ein Data Warehouse System. Im Pilotprojekt soll eine neue Web-

11.7 Übungen und Lösungsvorschläge 251

Anwendung erstellt werden, welche die folgenden Dienste verwenden soll. DieDienste sollen durch Kapselung von Funktionen der Anwendungssysteme bereit-gestellt werden. Überlegen Sie, welche Systeme bei den Diensten involviert sindund welche Laufzeiteigenschaften (bzgl. Interaktionsmuster, Blockierung, Zuver-lässigkeit, Commit-Verhalten und Sitzung) die Dienste haben sollten.

a) Kundenstammdaten anlegenb) Abfrage von Kundendatenc) Auftrag erfassend) Rechnung per EDI (Electronic Data Interchange) sendene) Umsatzstatistik der Kunden für kürzere Zeiträume (z. B. letzte Woche) und län-

gere Zeiträume (z. B. die letzten 10 Jahre).

11.7.2 Lösungsvorschläge für die Übungen

Aufgabe 11.1 (Verschiedene Integrationsarten, inklusive Nachrichten-Broker):

a)

� Benutzeroberfläche: Die Sachbearbeiter pflegen Kundenstammdaten und Kon-takte im Portal, beide Anwendungen können nebeneinander erscheinen. DasPortal verwendet Single Sign-on, damit sich die Sachbearbeiter nicht zweimalanmelden müssen. Nach der Suche von Kundenstammdaten können die Sachbe-arbeiter die dazugehörigen Kontakte sehen, wenn dies z. B. per ereignisorientier-ter Kommunikation so implementiert ist.

� Anwendungslogik: Z.B. im ERP-System wird eine neue Anwendung geschrie-ben, welche per Web-Service die Kontakte liest und in der neuen Anwendungdarstellt.

� Daten: Kundenstammdaten werden von ERP nach CRM übermittelt, z. B. inHintergrund-Jobs. Das technische Format kann XML oder eine CSV-Datei sein.

b)

� Dafür: Sichere Übertragung von Daten (hier: Kundendaten), inkl. Protokollie-rung, Offenheit für spätere Integrationen.

� Dagegen: Überdimensionierte Lösung, wenn es wirklich nur um diese eine Inte-grationsaufgabe geht. Dieses Argument wird hier überwiegen.


Aufgabe 11.2 (Identifizieren von Diensten):

a) b) c) d) e)

BeteiligteSysteme

ERP,CRM

ERP,CRM

ERP ERP ERP, DWH

Interak-tions-muster

Einweg-kommuni-kation

Anfrage-Antwort Einweg-kommuni-kation

Einweg-kommuni-kation

Anfrage-Antwort

Blockierung Nein Ja Nein Nein Ja

Zuverläs-sigkeit

Ja Nein Ja Ja Nein

CommitHandling

Ja Nein Ja Ja Nein

Sitzung Nein Nein Nein Nein Nein/ja

11.8 Literatur

Alonso G, Casati F, Kuno H, Machiraju V (2004) Web Services. Springer, BerlinHeidelberg New York

Huvar M, Falter T, Fiedler T, Zubev A (2008) Anwendungsentwicklung mit Enter-prise SOA. Galileo Press, Bonn

Illik JA (2007) Verteilte Systeme. Expert, Renningen

Krimmel M, Orb J (2009) SAP NetWeaver Process Integration. 2. Auflage. GalileoPress, Bonn

van Lessen T, Lübke D, Nitzsche J (2011) Geschäftsprozesse automatisieren mitBPEL. dpunkt, Heidelberg

Mandl P (2009) Master-Kurs Verteilte betriebliche Informationssysteme. Vie-weg+Teubner, Wiesbaden

OASIS (2002) http://www.oasis-open.org/specs/index.php#wssv1.0. Abgerufen am27.09.2011

Pohl T, Peter M (2009) Entwicklung von Enterprise Services für SAP. Galileo Press,Bonn

Schmitt T (2007) SAP/.Net Prozessintegration. entwickler.press, Unterhaching

Stumpe J, Orb J (2005) SAP Exchange Infrastructure. Galileo Press, Bonn

http://www.oasis-open.org/specs/index.php#wssv1.0

11.8 Literatur 253

Tanenbaum A, van Steen M (2007) Verteilte Systeme. 2. Auflage. Pearson Studium,München

Web Services Interoperability Organization (2011) WS-I Basic Profile http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile Abgerufen am10.08.2011

http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile

http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile

Documents

[Xpert.press] Technologie von Unternehmenssoftware || Nachrichtenorientierte Integration