Frische Wege der Integration

In einer Unternehmenslandschaft, in der Anwendungen als Web Services integrierbar sind, ergeben sich neue Möglichkeiten, Geschäftsprozesse abzubilden. Neue Anwendungen können durch das Zusammenwirken bestehender Anwendungen orchestriert werden. Hier kommt der Enterprise Service Bus (ESB) zum Tragen, der diesen Vorgang weiter vereinfacht.

Der ESB stellt folgendes zur Verfügung:

o Verbindung zu bestehenden Anwendungen (Applikationsserver, Einzelanwendungen, Datenbanken und Message Queues)

o Enterprise-Level-Dienste (digitale Signatur, sichere Meldungsübertragung, Authentifizierung und Zugangsrechte, Auffindung von Diensten und Sicherstellung der Qualität)

o Enterprise-Level-Qualität (Clustering, Skalierbarkeit, Fehlertoleranz).

o Werkzeuge, die aus bestehenden Anwendungen Web Services erstellen, betreiben und verwalten (Bereitstellung und Policy-Management).

Das Besondere an einer serviceorientierten Architektur, die über einen ESB technisch unterstützt und implementiert werden kann, ist die Fähigkeit, neue Anwendungen aus bestehenden zu kreieren. Hier kommt die Business Process Execution Language (BPEL) zur Anwendung, die Bestandteil eines ESB ist. BPEL ist eine XML-basierte Sprache zur Beschreibung von Geschäftsprozessen. Unter BPEL beschreiben die teilnehmenden Kommunikationspartner ihre Dienste über WSDL, das heisst, die Partner sind Web Services. BPEL stellt eine Programmiersprache zur Verfügung, die den logischen Fluss zwischen den verschiedenen Web Services definiert und manipuliert. Der BPEL-Prozess selbst ist ein Web Service und verfügt über eine WSDL-Schnittstellenbeschreibung.

Damit ist offensichtlich, dass BPEL die Möglichkeit eröffnet, neue Web Services aus bestehenden zu erstellen. BPEL hat aber eine Reihe weiterer interessanter Eigenschaften, die sie für die Orchestrierung von Diensten geeignet macht: Es ist ein offener Standard der Oasis (Organization for the Advancement of Structured Information Standards). Somit sind BPEL-Skripts portabel - Benutzer sind frei in der Wahl der Werkzeuge und Server und können diese entsprechend ihren Bedürfnissen auswählen.

BPEL-Prozesse sind statusabhängig - im Gegensatz zu reinen Web Services, die möglichst statusunabhängig sein müssen - und können daher auch längere Prozesse abbilden. Ein BPEL-Prozess kann Millisekunden, Minuten, Stunden, Tage oder auch Monate umfassen. Dies erlaubt die Modellierung eines weiten Spektrums an Geschäftsprozessen.

Zumdem ist BPEL eventgetrieben. Sie unterstützt mehrfache Threads, was erlaubt, auf Events zu antworten, wie etwa auf Cancel Forward Events. Dies ermöglicht eine effiziente Implementierung von Diensten, die sehr lange Durchlaufzeiten aufweisen. Es erlaubt auch eine einfache Integration von Prozessen, die sowohl synchrone wie auch asynchrone Dienste verwenden, was bei traditionellen RPC-basierten Systemen etwas problematisch ist.

BPEL ist XML-basiert. Viele Integrationsprojekte nutzen WSDL- und XML-Schemas von Diensten und kompilieren daraus Stubs und Models für eine spezifische Programmiersprache. Dies führt zu Wartungsproblemen. Wenn das WSDL- oder XML-Schema ändert - und diese ändern laufend -, muss die Bindung dazu neu kompiliert werden, was den Integrationscode beeinflusst, der die Bindung benutzt. BPEL arbeitet direkt mit WSDL- und XML-Schemas sowie X-Path. Es gibt keinen Bedarf an Bindung. Dies minimiert den Einfluss, den eine Veränderung des WSDL- oder des XML-Schemas auf die BPEL-Applikation hat.

Ein weiterer, wesentlicher Teil eines ESB sind seine On- und Off-Rampen. Legacy-Systeme, die nicht über eine Web-Service-Schnittstelle verfügen, können über diese bequem als Web Service exportiert und auf dem ESB integriert werden. Dieser Prozess verläuft schonend und ohne direkten Eingriff in die Legacy-Anwendung, indem Daten und Prozesse aus Legacy-Systemen über verschiedenste Quellen integriert werden können - unabhängig davon, ob es sich um Formulare, E-Mails oder Textdateien handelt oder was immer ein Legacy als Schnittstelle anbieten kann.