Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

27.04.2005

Sprachstandard belebt Web-Services

Eric Rotzoll
Über Web-Services sollen übergreifende Prozesse geordnet und kontrollierbar zusammenarbeiten. Ein Standard zur Beschreibung dieser Prozesse kommt mit der Business Process Execution Language (BPEL).

Programmieren war gestern, heute sind Modellieren, Designen, Orchestrieren und Choreographieren angesagt. Hinter diesen Begriffen verbirgt sich ein relativ junges Paradigma für die Gestaltung von Anwendungen, deren Fundament Service-orientierte Architekturen (SOA) sind. Der Mehrwert von SOA liegt darin, dass Unternehmen alle bestehenden IT-Assets - Anwendungen und Systeme - individuell und homogen für die Abbildung kritischer Geschäftsprozesse zusammenführen können, ohne dass die Komplexität der darunter liegenden Systeme sichtbar wird. Dazu lassen sich Programme, die über standardisierte XML-Schnittstellen verfügen - auch als Web-Services bezeichnet - mit Hilfe von Integrationswerkzeugen sehr rasch zu komplexen Applikationen zusammenfügen.

Neben dem einfachen Bau von neuen Anwendungen legen die Ansätze von SOA einen weiteren Schwerpunkt auf die Bereiche Business Process Management (BPM) und Business Activity Monitoring (BAM) - also die Überwachung, Steuerung und permanente Verbesserung von Geschäftsprozessen.

Damit das SOA-Konzept kein Wunschtraum bleibt, sind zwei Voraussetzungen zu erfüllen: Die IT-Architektur sowie die Software und Services müssen SOA-fähig sein. Lösungen sind hierzu bereits in Sicht: Integration Broker oder Process Engines übernehmen die Koordination, Ablaufsteuerung und übergreifende Verknüpfung von Web-Services. Die zweite Voraussetzung besteht in der Business Process Execution Language for Web Services (BPEL4WS) als Basis für die Beschreibung der übergeordneten Prozesssemantik.

Gleichzeitig kann durch BPEL ein lang gehegter Wunsch von Softwareentwicklern in Erfüllung gehen: den Bruch zwischen Modellierung und technischer Implementierung von Anwendungen zu überwinden. Denn die dahinter liegende Idee ist, dass sich Anwendungen ausgehend von der Prozessbeschreibung - den Prozessketten und -modellen in den Fachabteilungen - über das Design bis in die physische Implementierung mit der Schnittstellenbeschreibung auf Basis einer unterbrechungsfreien Methode entwickeln lassen.

Konkret: Ein grafisch erstelltes Prozessmodell, das etwa einen Ablauf im Vertrieb beschreibt und in einem Business-Process-Modeling-Werkzeug entworfen wurde, kann ohne Bruch in die technische Implementierung übernommen werden. Standards sorgen zudem dafür, dass die Modelle zwischen den Tools und Integrationswerkzeugen unterschiedlicher Hersteller austauschbar sind. Ein weiteres Ziel ist es, dass dazu immer weniger programmiert werden muss, sondern die Möglichkeit besteht, für die Implementierung auf "fertige" Softwarebausteine (Business Content) zurückzugreifen und diese beliebig zu konfigurieren. Dazu ist es gleichgültig, ob die einzelnen Module von einem Hersteller geliefert werden oder die Lösungen mehrerer Lieferanten kombiniert werden sollen.

CASE-Tools führten nur bedingt zum Ziel

Bereits in den achtziger Jahren haben Anbieter von CASE-Tools versucht, das Konzept einer durchgängigen Softwareentwicklung - vom Modell zum Code - in die Tat umzusetzen. Das Resultat war jedoch mehr oder weniger komplexer Spaghetti-Code in einer meist proprietären Interpreter-Sprache beziehungsweise herstellerspezifisch erweiterten Standardprogrammiersprache wie Cobol. Bei den Ansätzen haperte es an einheitlichen und vor allem übergreifenden Standards. Daher war es in der Regel nur innerhalb einer Herstellerwelt möglich, logische Modelle ohne größere Klimmzüge in die technische Implementierung zu übernehmen.

Damit der übergreifende Austausch funktionieren kann, ist eine einheitliche Beschreibungssprache nötig, die sowohl durchgängig innerhalb einer Tool-Welt arbeitet als auch von den Plattformen unterschiedlicher Hersteller interpretiert werden kann. Als aussichtsreichster Standardkandidat für die Beschreibung von Prozessen kristallisiert sich dazu BPEL heraus, deren Normierung von der Organization for the Advancement of Structured Information Standards (Oasis) vorangetrieben wird. BPEL4WS folgt dem Ansatz, die Zusammenarbeit von Web-Services für komplexe übergreifende Aufgaben in einer Art Workflow-Sprache auf Basis von XML abzubilden.

BPEL ist eine Abstraktionsschicht und legt fest, welche Dienste ein Geschäftsprozess nutzt. Sie ist entstanden aus einer Kombination der proprietären Konzepte Web Services Flow Language (WSFL) von IBM und XLANG, der Business Process Language, die Microsoft für seinen Bizztalk-Server entwickelt hat. Ein Vorteil der Plattformunabhängigkeit von BPEL ist, dass Unternehmen ihre eigenen internen Kommunikationsprotokolle beibehalten und ändern können, ohne jedoch die Daten ändern zu müssen, die für eine Kommunikation mit Externen nötig sind.

Als Datenmodell zieht BPEL das XML-Schema heran. Die Beschreibung der Services erfolgt mit der Standard Web Services Definition Language (WSDL), wobei BPEL auf WSDL aufsetzt und diese erweitert. Zusätzlich zu den Port- und Message-Typen sowie Containern für Metadaten werden Typen in Partnerbeziehungen, etwa Zulieferer, Kunden und Produzenten, beschrieben. Über Links lassen sich einer oder mehrere dieser Typen in unterschiedlichen Prozessen wiederverwenden. In den Workflow-Konstrukten, die BPEL bereitstellt, kann man unter anderem Parameter wie Antwortzeit, Ausnahmebehandlung und Transaktions-Management definieren, die bei Standard-WSDL nicht beschrieben sind.

Breite Unterstützung der Industrie zeichnet sich ab

Analysten wie Gartner räumen BPEL ein großes Potenzial ein. Für den Kenner der hiesigen Integrationsszene Richard Nußdorfer, Geschäftsführer von CSA Consulting aus München, ist BPEL gar die Lingua Franca der Prozessmodellierung und -implementierung. Sehr wichtig für den Erfolg eines Standards ist neben den Vorschusslorbeeren der Fachleute auch die Bereitschaft der Industrie, an einem Strang zu ziehen. Hier kann sich BPEL einer breiten Front aus Akteuren wie IBM, Microsoft, SAP und Oracle erfreuen, die in ihren Lösungen BPEL-Unterstützung bereits anbieten oder in Aussicht gestellt haben. Erste Implementierungen wie die SAP-Netweaver-Komponente Exchange Infrastructure (XI) und SAPs Master Data Management (MDM), IBMs Websphere sowie Oracles BPELs Process Manager sind in der Lage, BPEL4WS zu interpretieren. Die Aris-Suite von IDS Scheer soll zudem die BPEL-Prozess-Szenarien von XI und vom SAP Solution Manager importieren können. Auch die Open-Source-Gemeinde hat BPEL entdeckt und hält unter "ActiveBPEL.org" ein gleichnamiges kostenfreies Tool sowie eine Dokumentation bereit.

Grafische Editoren erleichtern den Einstieg

In Kontakt mit BPEL kommen Designer oder Entwickler in der Praxis mit grafischen Editoren, wie sie in Modellierungswerkzeugen zu finden sind. Eingebettet sind die BPEL-Werkzeuge auch in Integrations-Tools. Mit den zurzeit vorhandenen Produkten lassen sich Modelle auf sehr ähnliche Art und Weise bauen. Unterschiede gibt es allerdings in der grafischen Darstellung der Symbole. Um die BPEL-Editoren gesellt sich eine Reihe von Zusatzkomponenten und Hilfe-Features, die neben der Modellierung gleichzeitig den Aufbau von Integrationsprozessen, das Daten-Mapping, Debugging sowie Prozess-Management und -Monitoring unterstützen.

Was BPM-Werkzeuge enthalten sollten

Zu den wesentlichen Komponenten von BPM-Werkzeugen, etwa von SAPs XI, gehört ein grafischer Prozess-Editor als Bestandteil des Integration Builder. Modellierungs-, Design- und Orchestrierungs-Features mit BPEL sowie Pattern und Templates etwa für Business-Szenarien erweitern das Funktionsspektrum. Daneben unterstützten Wizards die Konfiguration von Prozessen. In der Regel lassen sich auch Interaktionen von Menschen (Human Workflows) sowie strukturierte und unstrukturierte Workflows integrieren. Darüber hinaus bieten die Werkzeuge Funktionen für Prozess-Monitoring und -optimierung.

Der Ablauf von der Modellierung zur Implementierung gestaltet sich wie folgt: Im ersten Schritt wird beispielsweise ein Geschäftsprozess in einem Modellierungswerkzeug erfasst. Der Vorteil der grafischen Darstellung der Prozesse und der verständlichen Symbolik ist, dass auch Nicht-IT-Fachleute wie Prozessverantwortliche und Anwender die Abläufe sehr leicht verstehen können. Die Diagramme lassen sich je nach Detaillierungsgrad weiter verfeinern und durch Datenbeschreibungen sowie Workflow-Anweisungen ergänzen.

Unterschiedliche Symbole für allgemeingültige Aktionen

Die Symbole für die grafische Beschreibung von Prozessen haben die Anbieter zwar unterschiedlich gestaltet, die Aktionen oder Prozessschritte sind jedoch allgemeingültig. Grundsätzlich unterscheidet BPEL zwischen einfachen (primitiven) und strukturierten Aktionen. Dazu gehören unter anderem: Sendeschritt, Empfangsschritt, Transformationsschritt (Umformung von Nachrichten, Mehrfachbedingung), Container-Operation (Zuweisen von Werten in einen Container, der die Informationen speichert), Block (Zusammenfassen von Einzelschritten, um diese als Einheit abzuarbeiten), paralleler Abschnitt und Schleife.

Diagramme lassen sich in einem nächsten Schritt in BPEL übersetzen. Dieser Code kann in eine BPEL-kompatible Integrations-Engine überführt und für die technische Implementierung verwendet werden. Die Integrations-Engine übersetzt das BPEL-Programm in die Integrationsanweisungen, zieht dazu aus einem entsprechenden Repository alle Softwarebausteine oder Komponenten heran, die für die Ausführung des Prozesses notwendig sind, und integriert sie gemäß dem Modell. Diesem Repository kommt eine sehr große Bedeutung zu. Denn dort wird, vereinfacht ausgedrückt, die Verbindung zwischen den BPEL-Anweisungen und den im Unternehmen verwendeten Protokollen, Schnittstellen und Systemen hergestellt. Das Repository repräsentiert die IT-Landkarte des Unternehmens, zu der Applikationen und auch Server gehören. Wird beispielsweise SAP eingesetzt, sind in dem Integrations-Repository und dem System Landscape Directory (SLD) alle vorhandenen SAP-Systeme sowie die Integrationsmechanismen (etwa BAPI oder Idoc) beschrieben. Die nötigen Komponenten, um einen Prozess abbilden zu können, lassen sich also recht komfortabel herausfinden.

Voraussetzung ist eine Landkarte der Unternehmens-IT

SAP visualisiert in XI anhand so genannter Swimlanes (Schwimmbahnen) dem Entwickler, welche IT-Systeme vorhanden sind, um den gestalteten Prozess unterstützen zu können, und wo die Übergabepunkte liegen. Der Fachprozess wird dabei in die technischen Komponenten heruntergebrochen. In der Praxis dürfte jedoch eine homogene IT-Landschaft die Ausnahme sein - gerade in größeren Unternehmen sind 50 oder mehr Applikationen von unterschiedlichen Lieferanten keine Seltenheit, wie die Analysten von Gartner immer wieder betonen. Sollen also Anwendungen von Fremdanbietern integriert werden, deren Beschreibungen nicht im SLD vorhanden sind, können technische Schnittstellen-Adapter zum Einsatz kommen, die eine Integration mit Drittsystemen erlauben. Anders ausgedrückt: Bei der Modellierung lassen sich Geschäftsprozesse zwar über System- und Unternehmensgrenzen hinweg grafisch gestalten. Die Implementierung kann allerdings je nach Güte und Vollständigkeit des SLD sehr aufwändig sein. Ein Ziel der Unternehmen sollte es daher sein, ihre Systemlandschaft zu kartieren.

Eine weitere wichtige Voraussetzung für die durchgängige Modellierung und Implementierung ist, dass die benötigten Softwarebausteine BPEL-fähig sind. Dabei wird man sich die Frage stellen, ob es sinnvoller ist, ein vorhandenes Programm mit den entsprechenden Schnittstellen zu ummanteln (Wrapping) oder es durch ein moderneres Produkt abzulösen. Hier gilt es, Aufwand und Nutzen genau abzuwägen.

Dass SOA die Zukunft gehört, darin sind sich Fachleute einig. Analysten fordern daher die Unternehmen auf, sich verstärkt mit Standards wie BPEL auseinander zu setzen. Schließlich seien sie nicht nur die Basis für eine durchgängige und flexible Entwicklung von Anwendungen, sondern legten auch den Grundstein für ein Business Activity Monitoring. (ue)