Eine Sprache für SOA – BPEL kennenlernen - JAXenter

Eine Sprache für SOA – BPEL kennenlernen

Auswirkungen auf die Arbeitsweise der Entwickler und der Fachseite

Nachdem dem Überblick darüber, was BPEL ist, soll kurz der Einfluss dieser Sprache auf die Architektur von heutigen Softwareprojekten und insbesondere auf die veränderte Arbeitsweise für Entwickler und die Fachseite beleuchtet werden. Betrachtet man die Softwareentwicklung allgemein, so werden häufig Anforderungen der Fachabteilung „über den Zaun“ in die IT-Abteilung geworfen, von der dann eine entsprechende Softwarelösung implementiert werden soll. In diesem Vorgehen zeigt sich die vielzitierte Lücke zwischen Business und IT.

Schaut man sich Abbildung 2 an, so kann ein BPEL-Prozess als Bindeglied zwischen fachlichen Prozessen und technischen Services gesehen werden. Mit BPEL kann die Lücke zwischen Business und IT dahingehend verkleinert werden, dass nun beide Seiten nur über jeweils einen Prozess sprechen, den es umzusetzen gilt. In der Fachabteilung wird dazu mit den gängigen Modellierungswerkzeugen gearbeitet (IDS Scheer Aris, Telelogic System Architect, diverse UML-Tools, etc.) und das Ergebnis in Form von EPKs, BPMN- oder UML-Diagrammen präsentiert.

Abb. 2: Unterschiedliche Designebenen

Der Entwickler steht nun in der Pflicht, den fachlichen Prozess IT-technisch umzusetzen. Dafür muss er BPEL als eine neue Programmiersprache beherrschen. Von den Herstellern gibt es dazu erste Ansätze, die automatisierte Übergänge aus ihren fachlichen Modellierungs-Tools in Richtung BPEL versprechen. Bis solch ein Übergang gut funktioniert (und dies, als Roundtrip, auch in beide Richtungen) wird jedoch noch einige Zeit vergehen. Daher wird man heute in der Regel eine manuelle Überführung in BPEL vornehmen, bei der viele Detailentscheidungen getroffen werden müssen, so zum Beispiel Serviceverwendung, Ausnahmebehandlung oder für die Strukturierung in Unterprozesse.

Für Entwickler ändert sich aber noch ein weiteres wichtiges Detail. Verglichen mit der „normalen“ Anwendungsentwicklung geben sie ein Stück Kontrolle ab. Die Businesslogik wird in Form von Services bereitgestellt, die Anwendung im herkömmlichen Sinne existiert nicht mehr und der BPEL-Prozess übernimmt die Steuerung. Dies ist recht interessant, da dadurch der Kontrollfluss aus den Anwendungen herausgelöst und um eine Abstraktionsebene angehoben wird. In der Praxis ist dies nur für einige Teile einer Anwendung sinnvoll, bringt dann aber deutlich mehr Transparenz. Auch die Kommunikation mit dem Fachbereich wird deutlich leichter, da dieser „seine“ Prozessflüsse wieder erkennt. Ein Nichtprogrammierer wird, wenigstens teilweise, in die Lage versetzt, Ablauflogik zu „implementieren“, was in der Praxis bedeutet, dass er sie grob vorgeben kann. Wichtig ist, BPEL als eine Programmiersprache zu sehen, weshalb auch explizit BPEL-Entwickler benötigt werden. Zukünftig wird also eine weitere Rolle auf die Entwickler zukommen, in der sie mal den Hut des „Servicedesigners/-implementierers“ und mal den Hut des „BPEL-Designers/-Implementierers“ aufsetzen. Aber auch die Fachseite wird neue Qualifikationen erwerben müssen.

Das Echtzeitunternehmen wird Realität

Die Business Process Execution Language (BPEL) erlaubt es uns, prozessorientierte Anwendungen zu schreiben, wodurch fachliche Prozesse nun direkt in IT-Umsetzungen sichtbar werden, was bisher nicht der Fall war.

Hat man sich einmal für BPEL entschieden, kommen weitere spannende Themen in Reichweite: Sehr naheliegend ist der Überbau der technischen Prozesse mit einer fachlichen Prozessmodellierung in Ereignisgesteuerte Prozessketten (EPK), Business Process Modeling Notation (BPMN) oder Unified Modeling Language (UML) und deren Verbindung zu BPEL-Prozessen und den Services der SOA im Unternehmen. Hierzu gibt es heute bereits vielversprechende Ansätze. Auf der Visionsseite steht noch die Generierung der BPEL-Prozesse aus fachlichen Prozessen mit kompletter Roundtrip-Unterstützung, gemeinsamen Repositories, Lifecycle-Management etc.

Ein weiteres spannendes Feld ist die Etablierung von fachlichem Monitoring, dem Business Activity Monitoring (BAM). Hiermit lässt sich heute bereits ein Echtzeit Prozess-Controlling realisieren, das im Gegensatz zu Datawarehouse-Ansätzen sofortige Reaktionen auf aktuelle Problemsituationen erlaubt.

Aufgrund der bisherigen positiven Erfahrungen aus Praxisprojekten lautet die Empfehlung heute schon eindeutig: Riskieren Sie einen Blick! Bauen Sie einen ersten Prototyp! Wir sind an einem Punkt angekommen, an dem das flexible Echtzeitunternehmen in greifbarere Nähe rückt. Nutzen wir die Chance…

Torsten Winterberg ist Bereichsleiter Anwendungsentwicklung bei der OPITZ CONSULTING GmbH. Er besitzt langjährige Erfahrung als Trainer, Projektcoach und Architekt rund um die Erstellung von Java-EE-Anwendungen. Sein besonderes Interesse liegt im Design und der Entwicklung von komplexen IT-Systemen unter Berücksichtigung von BPM, BPEL, ESB, BAM sowie allgemein den serviceorientierten Architekturen.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.