Service-orientierte Architekturen (SOA) sind nicht neu. Doch mit SOA sind nun die technischen Rahmenbedingungen und Standards definiert, um Business Process Management erfolgreich umzusetzen und «Composite Applications» zu realisieren. Schlagworte wie BPM (Business Process Management), BPEL (Business Process Execution Language) und BPMN (Business Process Modeling Notation) sind im Moment in aller Munde.

1. 14
E-Business • SOA & BPO
Professional Computing 3-2006
Es ist üblich, dass in grossen Unter-
nehmen die Unternehmensprozesse
aufgenommen, dokumentiert und in
der Produktion umgesetzt werden.
Später werden sie kontrolliert und
gegebenenfalls optimiert. Oft wur-
den die Prozesse in dafür speziali-
sierten Tools erfasst, konnten jedoch
technisch nur schlecht weiterverar-
beitet werden. Dies lag insbesondere
daran, dass es für die einzelnen An-
weisungen keine wirklichen Dienste
gab, die ausgeführt werden konnten.
Diese Prozesse wurden als Busi-
ness-anforderung der IT übergeben,
welche sie dann in monolithischen
Applikationen abgebildet hat. Jede
Änderung des Prozesses bedingte so-
mit eine Änderung der Applikation.
Mit der Service-orientierten Archi-
tektur kam nun der Gedanke, stan-
dardisierte Dienste zu entwickeln,
welche jeweils eine bestimmte Auf-
gabe übernehmen und diese dann zu
neuen Applikationen orchestrieren.
Zuerst war das eher eine technische
Steuerung der Aufrufe von Diensten,
welche innerhalb der Service-Engine
verwendet wurden. Mit BPEL wurde
ein Standard geschaffen, um diese
Prozesse auch auszutauschen und
so wieder zu verwenden. Anbieter
von klassischen BPM-Lösungen zum
Modellieren, Dokumentieren und Si-
mulieren von Prozessen erweiterten
ihre Produkte so, dass Prozesse als
BPEL-Definitionen exportiert wer-
den können. Anbieter von BPEL-En-
gines können so die Prozesse impor-
tieren und ausführen.
Ist SOA eine Voraussetzung
für erfolgreiches BPM?
Business-Prozesse, welche im klassi-
schen Prozess von Mitarbeitern aus
dem Business definiert und erfasst
werden, enthalten Entscheidungen
und Aktivitäten, die in der IT nicht
in jedem Fall vorhanden sind. Das
heisst, dass ein Prozess mit Aktivitä-
ten wie «Check Credit» oder «Place
Order» in der IT meistens zuerst als
Dienst implementiert werden muss.
Nur so lassen sie sich von der BPEL-
Engine aus dem Prozess heraus auf-
rufen.
Das Konzept von SOA ist nicht
neu. Schon Common Object Re-
quest Broker Architecture (CORBA)
und Microsofts Component Ob-
ject Model (COM) stellten SOA-
Funktionalitäten zur Verfügung. Da
beide Architekturen aber eng gekop-
pelt und proprietär waren, konn-
te sich keine echte SOA etablieren.
Auch dies sind jedoch Dienste, die
aus einem Prozess aufgerufen werden
können. Sind solche Services bereits
vorhanden, gibt es keinen Grund,
dass sie neu geschrieben werden
müssen. Jeder Anbieter unterstützt
die Einbindung von CORBA-basier-
ten Diensten oder es kann eine einfa-
che Bridge realisiert werden. Es gibt
jedoch Firmen, in denen Dienste, die
aus Prozess-Aktivitäten aufgerufen
werden können, noch gar nicht imp-
lementiert sind. Für neue Dienste ist
es darum sicher richtig, direkt SOA-
und Standard-basierte Services zu
entwickeln.
Implementierung einer SOA
Der wichtigste Erfolgsfaktor bei der
Einführung einer SOA ist die Im-
plementierung der klar definierten
Layer, die auf offenen Standards und
Technologien beruhen.
Die «Technical Services» sind Diens-
te, die von der IT entwickelt und
Mit SOA zu effizientem
Business Process Management
Service-orientierte Architekturen (SOA) sind nicht neu. Doch mit SOA sind nun die technischen Rahmenbedingungen
und Standards definiert, um Business Process Management erfolgreich umzusetzen und «Composite Applications»
zu realisieren. Schlagworte wie BPM (Business Process Management), BPEL (Business Process Execution Language) und
BPMN (Business Process Modeling Notation) sind im Moment in aller Munde. Doch woher kommt dieser neue Hype
auf Business-Prozesse? Und was haben diese mit SOA und «Composite Applications» zu tun? von Peter Affolter
The Levels of SOA
Get Order Quote Manage Exception OrdersSubmit / Change Order
Order Fulfillment ProcessGenerate Quote Process
Consolidate Order
for Shipment Process
Schedule ShipmentValidate Order Check Credit Check Inventory Create Invoice
Technical Services
"IT Landscape"
Presentation
"User Interface"
Business Processes
"Assembly &
Orchestration"
Business Services
"Business Language"

2. 15
E-Business • SOA & BPO
Professional Computing 3-2006
definiert werden. Sie sind meist sehr
fein-granular und widerspiegeln die
einzelnen Funktionalitäten der Back-
end-Systeme. Diese werden oftmals
mit BPEL zu «Business Services» or-
chestriert. Dabei ist es wichtig, dass
bereits zu diesem Zeitpunkt Vertre-
ter der Business-Anwendungen mit
einbezogen werden. Nur so lassen
sich die Dienste und deren Granula-
rität so definieren, dass sie von den
Prozessen auch wirklich verwendet
werden können.
Mit dem Ansatz einer pragmatischen
SOA müssen diese Dienste nicht alle
vorab definiert werden. Es ist mög-
lich, sie je nach Bedarf bei der Rea-
lisierung der Prozesse zu entwickeln.
Die Prozesse können dann direkt via
BPEL aus einem PBM-Tool impor-
tiert und die einzelnen Aktionen mit
den entsprechenden Services in die
SOA verbunden werden. Typischer-
weise braucht es hier auch IT-Fach-
leute, um die Prozesse mit Fehler-
behandlung und gegebenenfalls mit
einem Userinterface zu versehen.
Je schneller ein zentrales Repository
mit entsprechenden Diensten inner-
halb einer Firma aufgebaut wird,
um so rascher ist es möglich, neue
Business-Dienste oder -Prozesse
durch reine Konfiguration zu neuen
Composite Applications zusammen-
zustellen. Dank dem Anwachsen des
Repositorys und der damit verbun-
denen hohen Wiederverwendbarkeit
werden die Entwicklungszeiten neu-
er Prozesse reduziert und damit die
Kosten massiv gesenkt. Auch wenn
anfangs für die Implementierung
neuer Prozesse noch mit erhöhtem
Aufwand gerechnet werden muss,
so zeigt sich in der Regel bereits
ab der dritten neuen Anforderung
eine deutliche Kosten- und Zeitre-
duktion.
Die Komponenten einer SOA
Um die benötigten Dienste rasch und
ohne riesige Umstellung der gesam-
ten IT zu realisieren, ist es wichtig,
eine integrierte Plattform zu haben,
die es ermöglicht, die Services rasch
und einfach zu entwickeln. Verschie-
denste Backend-Systeme und Integ-
rationen sollten vorwiegend durch
Konfiguration und ohne grosse Pro-
grammierung eingebunden werden
können. Dies gilt auch für B2B-In-
tegration oder das Extrahieren und
Laden von grossen Datenfiles (ETL).
Mit Hilfe einer sauber integrierten
Produkte-Suite und einer einfachen,
gemeinsamen Entwicklungsumge-
bung kann die Produktivität erheb-
lich gesteigert werden. IT-Spezialis-
ten und Business-Analysten müssen
mit dem gleichen Tool arbeiten kön-
nen. Wichtig dabei ist jedoch, dass
Sie – je nach Aufgabengebiet – nur
die entsprechenden Komponenten
sehen können.
Java Composite Application Platform Suite
Sun erweitert Open-Source-
Strategie in Richtung SOA
Sun Microsystems gibt schrittweise weitere Java Tech-
nologien frei, um schliesslich eine komplette SOA-
Plattform für die Integration von Unternehmensan-
wendungen sowie die Einrichtung von Web Services
als Open Source zur Verfügung zu stellen. Zu den
Technologien zählen der Sun Java Studio Creator, der
Sun Java System Portal Server, die Engine der Business
Process Execution Language (BPEL) aus der Sun Java
Composite Application Platform Suite (CAPS), das
NetBeans Enterprise Pack, die Message Queue aus
dem Sun Java Message System (JMS) und die Web Ser-
vices Interoperabilitätstechnologie (WSIT).
Details zu den einzelnen Technologien und deren
Open-Source-Status:
Alle Komponenten des Sun Java System Portal Server
7 werden über das Java Open Portal Projekt http://
portal.dev.java.net zugänglich gemacht. Sun wird zu-
nächst ein Portlet Repository zur Verfügung stellen,
gefolgt von einem standardisierten Portlet Contai-
ner sowie Implementierungen von Web Services für
Remote Portlets (WSRP).
Aus der SeeBeyond-Akquisition stammt die Java CAPS
BPEL Engine, die nun als Teil der Open Java ESB Com-
munity unter http://java.sun.com/integration/commu-
nity.jsp verfügbar ist. Die Business Process Execution
Language steuert komplexe Geschäftsprozesse und
Arbeitsabläufe.
Das Werkzeug Sun Java Studio Crea-
tor, mit dem visuell Web Services er-
stellt werden können, soll im Lauf des
Jahres als Open Source freigegeben
werden.
Die Message Queue ist zugänglich un-
ter http://mq.dev.java.net, dem Open
Java MQ Projekt des Java Message
Systems.
Das NetBeans Enterprise Pack, mit Code aus Sun Java
Studio Enterprise, ist unter http://www.netbeans.org/
products/enterprise offengelegt. Das Enterprise Pack
enthält ein komplettes Paket mit Web Services auf Ba-
sis von UML (Unified Modeling Language) und BPEL
sowie weitere XML-Werkzeuge.
Die Web Services Interoperabilitätstechnologie (WSIT)
ist eine Sammlung von Web Services, die zusammen
mit Microsoft im Hinblick auf plattformübergreifende
Web Services zwischen der Java-Plattform und dem
.NET Framework von Microsoft entwickelt wurden.

3. 16
E-Business • SOA & BPO
Professional Computing 3-2006
Bedeutung der Standards
in einer SOA
Bei der Verwendung einer Suite darf
die Integrierbarkeit nicht ausser Acht
gelassen werden. Um eine Lockin-Si-
tuation zu vermeiden, müssen alle
Level der SOA auf offenen Standards
und Technologien basieren. So ist
sichergestellt, dass die Dienste und
Prozesse jederzeit auch von anderen
Umgebungen wiederverwendet wer-
den können. Heute sind für alle Lay-
er die entsprechenden Standards wie
Java/J2EE, WebServices, BPEL, JSPs
und Portale verfügbar.
Darüber hinaus wird es in Zukunft
immer wichtiger, dass auch die ein-
zelnen Komponenten der Runtime-
Umgebung auf Standards basie-
ren und so austauschbar sind. Die
Runtime-Umgebungen (Enterprise
Service Bus, ESB) werden heute meis-
tens mit eingebauten BPEL-Engines
und einer eigenen Administration
ausgeliefert.
Der Standard der Zukunft hierfür
wird sicher Java Business Integrati-
on (JBI; JSR208) sein, welcher den
Erfolg von SOA und BPM weiter
unterstützen wird. JBI definiert eine
offene und pluggable Architektur für
den Service-Bus. Die Engines (BPEL,
Rules ...) lassen sich hier einfach
einbinden und zentral administrie-
ren, egal von welchem Lieferanten
sie kommen. Dies erlaubt, mit Hilfe
eines «Composite Service Descrip-
Peter Affolter
ist Elektro- und
Software-Inge-
nieur und ar-
beitet seit gut
15 Jahren in
der Software-
entwicklung.
Davon ist er seit 10 Jahren im
Consulting-Bereich für Java/J2EE
tätig, beispielsweise für Firmen
wie Netscape, Silverstream und
BEA-Systems. Seit Februar 2006 ist
er als Software Architekt für Sun
Microsystems (Schweiz) AG im Ein-
satz.
tor», eine Composite Application
mit einem einzigen Dokument zu
beschreiben und – je nach Bedürf-
nis – auf unterschiedlichen Platt-
formen auszuführen. Die Compo-
site Application besteht aus einem
Userinterface, den BPEL-Prozessen,
welche die entsprechenden Services
aufrufen. Diese Prozesse wenden
gegebenenfalls auch Regeln an, die
von Rule-Engines ausgeführt werden
und so Bestandteil der Composite
Application sind.
Durch die Verbreitung dieser Stan-
dards und durch die konsequente
Umsetzung einer SOA kann BPM
in einer Firma schnell realisiert wer-
den. Bereits ab dem dritten Projekt
bringt dies Kosten- und Zeiteinspa-
rungen.
JBI - Java Business Integration
Engines
WS-I JMS EDI
BPEL xForm Rules
Bindings
Admin
RulesBPEL
Services