Enterprise Service Bus (ESB) als Grundlage SOA basierender Geschäftsprozess-Automatisierungen

Inhaltsverzeichnis

1. Geleitwort

2. Begriffe
2.1. Enterprise Application Integration (EAI)
2.2. MOM
2.3. Service-oriented Architecture (SOA)

3. Enterprise Service Bus
3.1. Eigenschaften eines ESB
3.2. Studie zu Integrationslösungen unter Zuhilfenahme des ESB

4. Fazit

Abbildung 1: SOA-Konzept.de, abgerufen am 07.05.2005

Abbildung 2: Aufbau eines ESB

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Orchestrierung eines ESB

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Schematischer Aufbau eines ESB, vgl. O.V., Der Enterprise

Service Bus nimmt Fahrt auf, Messaging- Infrastruktur für Web-Services -

Baustein für eine dienstorientierte Struktur, www.computerwoche.de, abgerufen am 07.05.2005

1. Geleitwort

Diese Seminararbeit gibt vorrangig einen Einblick in Enterprise Service Bus, im Hinblick auf die service-oriented Architecture. In Kapitel 2 wird allgemein auf die Begriffe Enterprise Application Integration (EAI), Message-Oriented Architecture (MOM) und Service-Oriented Architecture (SOA) eingegangen. In Kapitel 3 wird dann der Enterprise Service Bus erklärt und anhand einer aktuellen Studie werden die Softwareanforderungen aufgezeigt. Im letzten Kapitel folgt noch ein Fazit.

Viel Spaß beim Lesen!

2. Begriffe

2.1. Enterprise Application Integration (EAI)

EAI setzt sich zum Ziel getrennt voneinander entwickelte, spezifische Software zu integrieren. Dass die verschiedenen Applikationen so miteinander kommunizieren, dass sie als ein Ganzes geschäftsorientiert und im betriebswirtschaftlichen Sinne harmonisieren. EAI wird auch als grenzenlose Möglichkeit zum Informationsfluss zwischen beliebigen Systemen auf Präsentations-, Anwendungs- und Datenbankebene gesehen. Dabei müssen keine vorhandenen Anwendungen und Datenbestände geändert werden.¹ Die Architektur einer EAI-Lösung besteht aus drei Komponenten: Dem Kommunikationsmodell Den Integrationsmechanismen Und der Middleware.

Im Kommunikationsmodell unterscheidet man zwischen der Art und Weise wie Applikationen sich untereinander austauschen. Man differenziert zwischen synchroner und asynchroner Kommunikation. Für die synchrone Kommunikation muss man stets auf eine Rückantwort warten, bevor der Fall weiterverarbeitet werden kann. Im Gegensatz dazu, die asynchrone Kommunikation, bei der ich keine Rückantwort abwarten muss.

Die Intergrationsmechanismen sind:

- Messaging,
- Schnittstellendefinition und
- Adapter.

Beim Messaging werden die Nachrichtendaten übermittelt, während die beiden anderen Systeme über definierte Schnittstellen funktionieren. Ein weiterer Bestandteil der EAI-Architektur ist die Middleware. Sie dient dazu plattformunabhängige Kommunikation und Datenaustausch zwischen den unterschiedlichsten Systemen und Anwendungen zu ermöglichen. Es gibt folgende Typen von Middleware:

Remote Procedure Calls (RPC),

Message-Oriented Middleware (MOM), Middleware für den Datenbankzugriff, Verteilte Objekttechnologien und Transaktionsmonitore.

Grundsätzlich bedeutet RPC ein Protokoll, das Aufrufe und Funktionen bei verteilten Systemen steuert. Eine Stufe weiter gehen die objektorientierten Middleware-Ansätze. Sie legen nach dem Prinzip der Kapselung Einheiten zurecht, auf deren Funktionalität über Schnittstellen zugegriffen werden kann. Beispiele hierfür sind CORBA und Enterprise Java Beans (EJB). Transaktionsmonitore sorgen für zuverlässige Ausführung von Transaktionen. Da diese Techniken nichts mit dem eigentlichen Thema zu tun haben, wird hier nicht näher darauf eingegangen.²

2.2. MOM

Häufig kann eine Anfrage eines Servicenehmers nicht direkt bearbeitet und synchron beantwortet werden. Beispielsweise wenn der Auftrag eine nicht automatisierbare Arbeit mitbringt. In diesen Fällen braucht man eine asynchrone Nachrichtenverwaltung zur Koordination, Speicherung und Weiterleitung der Aufträge. Middleware-Ansätze, die die asynchrone Nachrichtenverwaltung Enterprise Service Bus (ESB) als Grundlage SOA basierender Geschäftsprozess- 7 unterstützen, nennt man MOM. Produkte dieser Gattung sind der Microsoft Message Queue Server (MSMQ) oder IBM Websphere Mqseries.³ Für das Web ist diese Form aus vielen Gründen besser geeignet. Einmal aus Performance- Gründen. Anhand von MOM kann das System bestimmen, wann und wie eine Nachricht gesendet wird. Und es kann bestimmen, wohin die Nachricht gehen soll. Somit ergibt sich für das System die Option, die Nachrichtenlasten zu verteilen. Außerdem sind die einzelnen Bestandteile in einer web-basierten Architektur voneinander unabhängig, also ist die Kopplung viel loser. Zusätzlich können Nachrichten protokolliert und gesichert werden. MOM eignet sich aus folgenden Gründen besonders für web-basierte Architekturen: Die Komponenten können zeitlich entkoppelt werden - Produzent und Konsument müssen nicht zur gleichen Zeit aktiv sein. Die Komponenten können örtlich entkoppelt werden - Produzent und Konsument werden auch, wenn sie auf andere Netzknoten versetzt werden, gefunden.

Asynchrone Interaktion - der Client muss nicht auf die Antwort des Servers warten.

Skalierbarkeit - es können beliebig viele Server eingesetzt werden, die Clientaufträge bearbeiten können.

Ereignisorientiert - Ereignisse werden als eine spezifische Nachrichtenart behandelt und verursachen keinen Mehraufwand.

Einfachheit - nachrichtenorientierte Kommunikation ist die einfachste Art der Verständigung zwischen zwei voneinander entfernten Objekten. Zuverlässigkeit - im Gegensatz zu anderer Middleware benötigt MOM keine totale Zuverlässigkeit. Was soviel heißt, wie es muss nicht jede Nachricht ankommen und nicht jede Nachricht beantwortet werden. Wenn eine Nachricht nicht ankommt, dann wird sie nochmals gesendet, auf diesem Weg erhalte ich eine höhere Fehlertoleranz.

Eignung für das Netz - durch die Eigenschaft große Nachrichtenmengen in einer möglichst kurzen Zeit zuweisen zu können, hat MOM anderen

Enterprise Service Bus (ESB) als Grundlage SOA basierender Geschäftsprozess- 8

Techniken gegenüber einen großen Vorteil. Es gibt drei Typen von MOM- Systemen:

Message Parsing

Publish/Subscribe und Message Queuing.

Message Parsing Systeme transportieren eine Nachricht von einem Netzknoten zum Anderen. Der Sender bestimmt dabei, wohin die Nachricht geht. Der Empfänger bestimmt, was mit der Nachricht passiert. Das nennt man eine einfache 1:1-Kommunikation.

Publish/Subscribe Systeme sorgen dafür, dass jeder den die Nachricht interessiert, eine zugesendet bekommt. Dieser Typ ist intelligenter und der Sender muss nicht an jeden Empfänger einzeln senden. Es handelt sich um eine 1:n Kommunikation. Message Queuing Systeme stellen eine virtuelle Rohrpost zur Verfügung. Sender können es beliebig mit Nachrichten zu posten und Empfänger holen ihre Nachrichten je nach Bedarf ab. Die Middleware administriert quasi das Rohr. Entsteht wegen zu vieler Nachrichten ein Stau, dann werden diese umgeleitet. Der letztere Middleware-Typ wird in einem Enterprise Service Bus verwendet. Das Bedeutendste an MOM ist die Entkopplung von Sender und Empfänger. Diese Middleware ist intelligent und verwaltet die Nachrichten.⁴

2.3. Service-oriented Architecture (SOA)

SOA beschreibt Systemarchitekturen, die sich hauptsächlich aus Diensten zusammensetzen.⁵ Gewöhnlich ist eine Systemarchitektur durch Konnektoren und Konfiguration von Komponenten erklärt. Eine bestimmte Architektur bildet dabei gerade eine konkrete Architektur. Wird dieses Prinzip auf das SOA-Konzept übertragen, dann spiegeln sich in den Komponenten die Dienste wider und in den Konnektoren die Interaktionen zwischen den Diensten.

[...]

¹ Vgl. Sneed, H., Sneed S., Web-basierte Systemintegration

² Vgl. Ruh, W., Maginnis F., Brown W., Enterprise Application Intergration

³ Vgl. Zwißler, S., Electronic Commerce Electronic Business

⁴ Vgl. Sneed, H., Sneed, S., Web-basierte Systemintegration

⁵ Vgl. www.software-kompetenz.de