Beat Walter ist Geschäftsführer der Walter Systems, Bern.

Enterprise Application Integration hat sich in der Vergangenheit grundlegend gewandelt. Während früher ein Mix verschiedenster konkurrierender Technologien vorhanden war (Corba, DCOM, JMS MQ), die herstellerbezogene Schnittstellen benötigen, gibt es heute eigentlich nur eine Lösung: Web Services. Ein klarer Konsens bezüglich Integrationstechnologien wurde gefunden.

Während einst die Frage lautete «Wie bringt man Anwendung A dazu, mit Anwendung B zu kommunizieren?» ist heute die Frage «Wie veröffentlicht man Anwendung A als Web Service?». Hier hilft der Enterprise Service Bus (ESB) weiter, um Legacy Systeme und Datenquellen, die von sich aus Web Services nicht unterstützen, aufs Netz zu bringen. Aus der Sicht eines Integrators sind dies gute Nachrichten. Hersteller beginnen nun zu ihren Produkten Web Service Adapter anzubieten und machen ihnen dadurch das Leben einfacher.

Ein weiterer wichtiger Punkt sind Open Standards. Diese bringen den Integratoren zwei wichtige Vorteile: Interoperabilität und freie Produktewahl. Offene Standards bedeuten, dass Integratoren zwischen konkurrierenden Produkten auf Basis ihrer Spezialitäten wählen können. Heute nutzen die meisten Integrationsprojekte XML Schemas, Soap (Simple Object Access Protocol) und WSDL (Web Service Description Language). Zusammen bilden sie den Rahmen, um Dienste zu beschreiben und Meldungen auszutauschen. Schnell haben sich zudem WS-Security und WS-Reliable-Messaging etabliert, die Verschlüsselung und Signierung auf der Basis von Web Services ermöglichen.

Das Prinzip von SOA ist letztlich, dass neue Dienste auf Basis von existierenden gebildet werden können. Wenn Firmen ihre bisherigen Integrationsprojekte betrachten, sehen sie heute meist noch Integrationsinseln - unterschiedliche technische Lösungen wurden benutzt um verschiedene Integrationsprobleme zu lösen. Es gab wenig Wiederverwendbares zwischen den einzelnen Integrationsprojekten und daraus resultierte ein ständiger Zuwachs der Wartungskosten.

Der SOA-Ansatz liefert eine Antwort: Die Definition aller Services in einer Form - als Web Services. Damit ist sichergestellt, dass diese mindestens das Potenzial haben, wiederverwendet zu werden. SOA geht aber weiter und ermöglicht das Erstellen von neuen Diensten durch die Kombination von existierenden. Früher wurden frische Dienste durch die Integration von bestehenden Datenbanken und Servern gebildet. Diese einfache Regel führt zu einigen wichtigen Richtlinien: Dienste sollten wenn möglich «stateless» sein. Sate impliziert einen gemeinsamen Kontext zwischen dem Client und dem Dienst. Stateless-Dienste hingegen setzen das nicht voraus, skalieren besser und können in verschiedenen Situationen mit wenig oder sogar ohne Zusatzkosten verwendet werden.

Im Weiteren sollten sich Dienste jeweils nur auf eine Sache konzentrieren, diese aber optimal umsetzen. Dadurch wird die Wiederverwendbarkeit gefördert. Damit ein Dienst rezykliert werden kann, sollte er so unabhängig wie möglich vom jeweiligen Kontext sein, in dem er verwendet wird.

Web Services gelten als einziger verfügbarer Standard im Bereich SOA. Alle grösseren Hersteller von Enterprise-Anwendungen haben daher heute in ihren Produkten Web Services eingebaut und vereinfachen damit die Integration.

Was früher Monate dauerte, braucht dadurch jetzt nur noch Wochen oder gar Tage.

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.