Was ist eigentlich eine serviceorientierte Architektur (SOA)?

Die Idee hinter dem Konzept SOA, also den serviceorientierten Architekturen, klingt bestechend: die Programmlogik ist nicht mehr Bestandteil der einzelnen Programme, sondern wird über mehrere, unabhängige Services verteilt. IT-Prozesse werden so, vereinfacht dargestellt, als eigenständige Services definiert.

Prinzipiell kann man, ähnlich einer komfortablen Programmiersprache, auf einzelne fertige Module zurückgreifen und sich neue Anwendungen durch „Zusammenstecken“ erstellen. Dies funktioniert, weil alle Hersteller dasselbe Sechs-Schichten-Modell verwenden. Eine pragmatische Standardisierung von Schnittstellen sorgt in Verbindung mit XML als einheitlichem Datenformat für die notwendige Interoperabilität.

SOA steht damit für die ganzheitliche Betrachtung einer IT-Systemlandschaft als Unterstützungsfunktion für betriebliche Prozesse. Funktionen, die durch einzelne Systeme abgedeckt werden, sind dank SOA in standardisierter Form unternehmensweit zugänglich. Einmal erstellte Abläufe oder Funktionen können, sofern sie die Schnittstellen aufweisen, also immer wieder verwendet werden. Aus ganzen IT-Prozessen werden so letztlich Programmierbausteine.

Im Prinzip agieren die Dienste untereinander nach demselben Modell wie Webserver und Browser. Mit einer SOA können neue Systeme aufgebaut werden, die Teile der bestehenden IT nutzen. Aufgrund des unbestrittenen Nutzens dieser Standardarchitektur planen immer mehr Unternehmen die Einführung einer SOA. Besonders geeignet für Einführungsprojekte sind Vorhaben, die geschäftskritische Anwendungen betreffen, etwa Modernisierungs- und Migrationsprojekte, Datenintegrationsplattformen oder unternehmensweite, zentrale Lösungen wie beispielsweise Output-Management oder die Stammdatenverwaltung. SOA hilft so neben Zeit- und Kostenersparnis auch, die durchschnittliche Datenqualität in einem Unternehmen zu steigern.

Standardisierung, Kostenersparnis, und Flexibilität

Vorteile von SOA sind in erster Linie Standardisierung, Kostenersparnis, und Flexibilität. Die Kostenersparnis wird durch den Einbezug bestehender Systeme als Services und durch den geringeren Änderungsaufwand bei der Anpassung eines auf SOA basierenden Systems erreicht.

Die Flexibilisierung einer Anwendung erfolgt durch die Aufteilung der Geschäftslogik in statische und dynamische Bereiche. Der statische Bereich wird als Service realisiert, während der dynamische Bereich getrennt davon als Prozess oder als Regel modelliert, generiert und ausgeführt wird. Dadurch rückt die Realisierung von Anwendungen näher an die zentrale Aufgabe eines Unternehmens heran: die Wertschöpfung durch die Umsetzung kundenorientierter Kernprozesse. Auf dem Konzept der SOA basierende Systeme sind änderungsfreundlicher und damit wesentlich flexibler und kostengünstiger im Betrieb als mit konventionellen Mitteln erstellte Anwendungen. Allerdings sollte der Aspekt der Flexibilität nicht das allein entscheidende Kriterium bei der Einführung einer SOA sein, da kein Unternehmen täglich seine Prozesse oder seine IT ändert.

In einer SOA werden zahlreiche einzelne Dienste zu einem funktionierenden Ganzen zusammengefasst. Durch die Steuerung dieser Dienste über optimierte Prozesse wird ein entsprechend auf das Unternehmen abgestimmter Workflow erreicht. Ändert sich der Geschäftsprozess, so ändert sich auch der Workflow.

Dabei muss aber berücksichtigt werden, dass Flexibilität nicht ausschließlich von der technischen Infrastruktur abhängt. Mindestens ebenso wichtig wie die technischen sind die nicht-technischen Prozesse, denn oft ergibt das eine ohne das andere schlicht keinen Sinn. Deutlich wird dies etwa an Monitoring-Prozessen oder Reporting-Funktionen: wenn ein System Alarm schlägt oder einen Bericht erzeugt, muss letzten Endes ein Mensch das Ergebnis sehen und ggf. auch darauf reagieren.

Worauf Sie achten sollten!

Geeignet für die Umsetzung basierend auf SOA ist jedes geschäftskritische Vorhaben, da kaum ein Unternehmen solche Systeme vollständig getrennt von bestehenden Anwendungen oder Daten realisieren wird. SOA ist die einzige Standardarchitektur, die explizit die Integration bestehender Systeme vorsieht.

Geradezu prädestiniert ist SOA für die Lösung komplexer Aufgabenstellungen wie beispielsweise die Modernisierung bestehender Systeme, also die Weiterverwendung bestehender Assets eines Unternehmens. Der Kostenvorteil, der sich ergibt, wenn man eine bestehende Anwendung und deren Funktionalität weitere Jahre nutzen kann, ist unübersehbar. Zu diesem Zweck muss die Anwendung jedoch so modifiziert werden, dass sich die Funktionalität als Web-Service bereitstellen lässt.

Ein anderes Beispiel ist die schrittweise Migration großer Legacy-Systeme. Auch hier bietet SOA aufgrund der Flexibilität und Mächtigkeit seiner Einzelkomponenten entsprechende Mechanismen. Sie gestatten es, auch sehr große und komplexe Legacy-Systeme geordnet und kontrolliert abzulösen. Gerade hier kann SOA seine Muskeln spielen lassen, denn nach wie vor scheuen insbesondere große Unternehmen davor, ihre über Jahrzehnte gewachsenen Mainframe-Anwendungen zu migrieren. Mit SOA steht ihnen nun erstmals ein Weg offen, der eine Migration auf Client-Server-Systeme ermöglicht, ohne dass bestehende Anwendungen komplett neu geschrieben werden müssen.

Einheitliche Schnittstellen

Zusätzlich lässt sich mittels SOA endlich das leidige Schnittstellenproblem in den Griff bekommen. Schnittstellen verursachen nicht nur die Hälfte des Gesamtaufwands für die Umsetzung einer Lösung, sondern auch knapp die Hälfte aller Fehler. Schnittstellen basierend auf SOA zu bauen, ist ein neuer Ansatz, der sich in der Praxis bewährt hat.

Die Strukturierung von Schnittstellen durch Service Groups, die Bereitstellung spezieller Konversions- und Transformationsdienste und die Steuerung von Abläufen durch die Business Process Execution Language (BPEL), eine XML-basierte Sprache zur Beschreibung von Geschäftsprozessen, erlaubt flexible und rationelle Ansätze beim Schnittstellenbau. In punkto Änderungsfreundlichkeit und Betriebskosten ist dieses Konzept allen anderen weit überlegen.

Viele Analysten und Hersteller überfrachten SOA mit sehr komplexen Modellen und Produktportfolios, die von Entwicklungs- bis hin zu Steuerungs- und Überwachungswerkzeugen reichen. Dahinter steckt die Vorstellung, mit SOA sämtliche Schwierigkeiten lösen zu können, die mit dem Bau, dem Betrieb und dem Unterhalt von Informationssystemen verbunden sind. Hinzu kommt der nahezu unüberschaubare Dschungel aus Standards, die in Zusammenhang mit der Basistechnologie von SOA – Web Services – entwickelt wurden und werden.

SOA muss nicht komplex sein

Beides führt dazu, die zentralen Vorteile zu verdecken und SOA als ein Modell erscheinen zu lassen, das komplex und mit sehr großen Investitionen verbunden ist und nur durch grundlegende Veränderungen der bestehenden IT-Systeme umgesetzt werden kann. Die wahren Stärken von SOA liegen jedoch in der einfachen Erweiterung der üblichen Schichtung von Anwendungen und Architekturen um eine Service- und eine Orchestrierungsebene und in der Möglichkeit, Ordnung in eine bestehende, heterogene Systemlandschaft zu bringen.

Unternehmen sind daher gut beraten, wenn sie mit einem pragmatischen SOA-Ansatz arbeiten, der auf ihre individuellen Belange optimal abgestimmt ist. Die Einführung einer SOA lässt sich am erfolgreichsten im Rahmen der Umsetzung einer geschäftskritischen Anwendung realisieren. Dies garantiert, dass ein Unternehmen dem Vorhaben die notwendige Aufmerksamkeit schenkt.

Von der Realisierung reiner SOA-Prototypen, um die Tauglichkeit des Architekturmodells für ein Unternehmen abzuschätzen, sollte man absehen, da sie keine vernünftigen Resultate erbringt. Meist ist der Prototyp zu eingeschränkt, um relevante Erfahrungen bezüglich des Aufwands, der organisatorischen Auswirkungen und der Kosten zu machen.

10 Schritte zu SOA

Ein bewährtes Vorgehen zur Schrittweisen Einführung ist:

• 1. SOA Know-how: Erwerben Sie das notwendige Wissen zum Thema SOA.

• 2. Eigenes SOA-Modell: Entwickeln Sie eine herstellerunabhängige SOA für Ihr Unternehmen als logisches Modell und formulieren die eigenen Ziele.

• 3. Basisdienste definieren: Wenige potenzielle Basisdienste werden isoliert und dokumentiert.

• 4. Einführungsprojekt auswählen: Wählen Sie ein geschäftskritisches Projekt aus, um die Architektur umzusetzen. Ein Prototyping einer kleineren Applikation kann im Vorfeld sinnvoll sein, liefert jedoch keine signifikanten Ergebnisse.

• 5. Prozesse modellieren: Modellieren Sie den vom Einführungsprojekt unterstützte Geschäftsprozess in BPEL.

• 6. Dienste realisieren: Realisieren Sie die für das Einführungsprojekt benötigten Dienste und gleichen Sie diese mit den potenziellen Basisdiensten ab.

• 7. Anwendung bereitstellen: Nehmen Sie das Einführungsprojekt in Betrieb.

• 8. Zielabgleich: Gleichen Sie nach einer längeren Betriebsdauer werden die in Schritt 3 formulierten Ziele mit den Ergebnissen ab.

• 9. SOA-Regeln: Formulieren Sie SOA-Regeln und eine für Ihr Unternehmen verbindliche Architektur.

• 10. Ausbreitung: Kommunizieren Sie das Einführungsprojekt in Ihrem Unternehmen und setzen Sie SOA in weiteren Projekten um.

Selbstverständlich lässt sich der Nutzen einer SOA auch in Rahmen einer ROI Betrachtung rechnen. Es gilt jedoch, was für jede ROI Rechnung in der Informatik gilt: Sie ist komplex, basiert sehr oft auf einer Vielzahl von Annahmen und wird sehr selten nachkalkuliert.

Unstrittig ist aber, dass die Verwendung bestehender Systeme wesentlich günstiger als der Bau eines neuen Systems ist. Unstrittig ist auch, dass eine Änderung der Programmlogik durch die Instrumente auf der Orchestration-Ebene wesentlich günstiger als jede Programmänderung ist. Und dass mit Standardisierung große Skaleneffekte auf Unternehmensebene erreicht werden können. (Daniel Liebhart/mha)

Tipps vom SOA-Experten Daniel Liebhart

tecChannel: Die Vorteile einer SOA mögen vielfältig sein, aber dennoch fragen sich viele IT-Manager, ob eine SOA in ihrem Fall überhaupt angeraten ist. Welche Bedingungen müssen erfüllt sein, damit eine SOA-Strategie sinnvoll und erfolgversprechend ist?

Daniel Liebhart: Meiner Ansicht nach ist eine SOA-Strategie für jedes Unternehmen, welches nicht nur ein betriebliches Informationssystem im Einsatz hat, sinnvoll. Die möglichen Vorteile – Standardisierung, Kostenersparnis und Flexibilität – sind bestechend. Im Weiteren werden alle Hersteller von Standardsoftware wie beispielsweise IBM, Oracle, Microsoft und SAP ihre Produktpalette in Richtung SOA umgestalten. Um nicht einfach dem Diktat eines Herstellers unterworfen zu sein, ist es sinnvoll, dass ein Unternehmen eigene Überlegungen zum Thema SOA anstellt und entsprechende Vorstellungen entwickelt. Erfolg versprechend ist eine SOA für ein Unternehmen dann, wenn ein pragmatischer Ansatz gewählt wird, der auf das Unternehmen und seine bestehenden Systeme und Bedürfnisse abgestimmt ist und auf den drei wichtigsten Standards Web Services, BPEL und XML basiert

tecChannel: Eignen sich manche Unternehmen und Einsatzgebiete besser für eine serviceorientierte Architektur als andere? Von welchen Faktoren hängt dies ab?

Daniel Liebhart: Im Prinzip eignen sich SOA für jedes betriebliche Informationssystem. SOA ist vor allem für größere Unternehmen geeignet, die mehr als einen Hersteller und mehr als eine einzige Technologie einsetzen. SOA ist geradezu prädestiniert für die Lösung von komplexen Aufgabenstellungen wie beispielsweise die Modernisierung bestehender Systeme, die Migration großer Legacy-Systeme, die Lösung des leidigen Schnittstellenproblems in einem heterogenen Umfeld und für die Realisierung unternehmensweiter Lösungen, wie beispielsweise die Stammdatenverwaltung oder das Output-Management. In jedem Fall sollten neu zu erstellende Individuallösungen mit moderner Technologie (Java oder .NET) so gestaltet werden, dass eine Integration der Lösung in eine SOA nicht verhindert wird.

tecChannel: Die Unternehmens-IT steht heute unter großem Kostendruck, daher hinterfragen Verantwortliche natürlich auch den Nutzen neuer Investitionen. Lässt sich berechnen, wie viel eine Implementierung kostet und wann sich die Einführung lohnt?

Daniel Liebhart: SOA hat offensichtliche Kostenvorteile und solche, die erst zur Laufzeit eines Systems sichtbar werden. Selbstverständlich versuchen die großen Hersteller und die Hersteller von Middleware SOA als investitionsintensiv darzustellen, um Ihre neuen Produkte verkaufen zu können. Dies ist berechtigt und der Einsatz der angebotenen Instrumente ist in vielen Fällen sinnvoll, jedoch oftmals überdimensioniert. So ist beispielsweise der Einsatz eines ESB in einer SOA keineswegs zwingend. In vielen Fällen genügt eine BPEL-Engine. Ein Unternehmen sollte ein pragmatisches SOA-Modell nutzen, um Kosten zu sparen.

Auf jeden Fall lohnt sich die Einführung im Falle einer zwingenden Weiterverwendung bestehender Systeme. So kann die Lebenszeit und damit die Amortisation vorhandener Assets verlängert werden. Für neue Systeme gilt: Die Investitionskosten für den Neubau eines Systems bleiben gleich, ob das System nun basierend auf SOA oder basierend auf einer anderen Architektur realisiert wird. Zur Laufzeit gilt jedoch: je änderungsresistenter eine Anwendung ist, desto teuerer ist der Betrieb. Da ist SOA klar im Vorteil. Selbstverständlich lässt sich eine Implementierung rechnen, so wie jedes Informationssystem gerechnet wird. Die Einführung lohnt dann, wenn mehr als eine Technologie zum Einsatz kommt, wenn Standardprodukte mit Individuallösungen kombiniert werden oder wenn unter-nehmensübergreifend Services angeboten werden sollen.

tecChannel: Können Sie sich auch Konstellationen vorstellen, in denen Sie Unternehmen von der Einführung einer SOA abraten würden?

Daniel Liebhart: SOA ist nicht geeignet für Real-Time-Systeme, Dies gilt jedoch auch für andere Standard-Architekturen. Falls ein Unternehmen nur und ausschließlich Standardpro-dukte eines Herstellers einsetzt, ist eine Einführung nicht zwingend. Das wird der Hersteller in zukünftigen Versionen so oder so erledigen.

SOA-Glossar – Application Platform bis Architekturstile

Sämtliche Begriffe sind aus dem Buch „SOA goes Real“ von Daniel Liebhart, welches soeben im Hanser Verlag erschienen ist.

Application Plattform: Die SOA-Architektur von Microsoft wird auch als Application Plattform bezeichnet und ist als Service-Architektur in drei logische Ebenen - Expose, Compose und Consume - aufgeteilt.

Architektur des SOA-Modells: Sie umfasst die Ebenen Presentation (GUI), Orchestration (Prozesse und Geschäftsregeln), Services, Integration Architecture, Applications und Virtualized Infrastructure.

Architekturmodelle des W3C: Das SOA Meta Model des W3C basiert auf der WWW-Architektur des W3C und umfasst vier Modelle, die "teilweise geschichtet" miteinander korrelieren (Message Oriented Model, Resource Oriented Model, Policy Model und Service Oriented Model).

Architekturstile: SOA unterstützt verschiedene Architekturstile, ist jedoch für sich gesehen kein Architekturstil, sondern eine Standardarchitektur. Mit den Elementen von SOA lassen sich praktisch alle Architekturstile realisieren.

SOA-Glossar – Basisoperationen bis Business Scenarios

Basisoperationen für Dienste: Als Basisoperation für Dienste gelten die Operationen Publication, Discovery, Selection und Binding.

Bestandteile eines Services: Ein Service muss aufrufbar sein, eine definierte Funktionalität aufweisen und definierte Rahmenbedingungen einhalten. Jeder Dienst besteht aus mindestens drei Komponenten: der Schnittstelle, dem Service Contract und der Service Implementation

BPEL: Die Business Process Execution Language wird auch als Lingua Franca von SOA bezeichnet. Mit BPEL lässt sich ein Prozess beschreiben und abbilden. Diese Beschreibung erfolgt graphisch mittels eines BPEL Editors. Im Unterschied zu den anderen Techniken kann aus dem modellierten Geschäftsprozess direkt die Steuerung der Workflow Engine (BPEL Engine) erzeugt werden. Mittels BPEL lassen sich verschiedene Dienste zu einer Gesamtanwendung verknüpfen.

Business Components: Business Components sind Komponenten, die Logik darstellen - im Gegensatz zu Business Entities.

Business Entities: Business Entities sind Komponenten, die Daten darstellen.

Business Process Management (BPM): Business Process Management betrachtet ein Unternehmen als Ganzes, als unabhängige Sammlung von Geschäftsprozessen, die auf externe und interne Ereignisse reagiert. Die Geschäftstätigkeit wird als Ganzes modelliert und strukturiert. Man nennt diese Strukturierung auch Prozesslandschaft. Sie setzt sich aus Kern- und Unterstützungsprozessen sowie deren Makro-, Mikro- und Teilprozessen zusammen.

Business Scenarios: Eine Sammlung zusammengehörender Geschäftsvorfälle.

SOA-Glossar - Composite Applications bis Geschäftsregel

Composite Applications: Composite Applications sind Anwendungen, die auf SOA basieren. Sie sind als Grundgerüst bereits vorhanden und werden aufgrund der verwendeten Dienste und Geschäftsfälle zu einem funktionierenden Ganzen zusammengestellt.

Enterprise Service Architecture: Die Enterprise Service Architecture (ESA) ist die SOA-Realisierung von SAP. Sie wird als eine Reihe von Prinzipien definiert, die zum Ziel haben, eine Service-orientierte IT-Architektur für adaptive betriebliche Informationssysteme zu entwickeln.

Enterprise Service Bus: Der ESB wird von vielen Herstellern als zentraler Bestandteil einer SOA angesehen, die die Integration Architecture Ebene abdecken soll.

Fusion Middleware: Fusion Middleware ist die Technologieplattform von Oracle für die Realisierung einer SOA. Oracle Fusion besteht einerseits aus der Technologieplattform Oracle Fusion Middleware und den Oracle Fusion Applications. Mit Oracle Fusion Applications sind diejenigen Systeme gemeint, die mittels Fusion Middleware integriert und vom Hersteller heute als eigenständige Produkte geführt werden (Oracle Applications, JD Edwards, Siebel, People-Soft, Retex etc.).

Geschäftsregel: Geschäftsregeln (Business Rules) sind ein integraler Bestandteil des Geschäftsprozessmanagements. Sie steuern das Verhalten von Prozessen. Eine Business Rule ist eine Aussage, die einen Aspekt eines bestimmten Geschäftsfalls definiert oder begrenzt.

SOA-Glossar – Presentation bis Orchestration

Presentation: Das User Interface einer auf SOA basierenden Applikation wird auf dieser Ebene realisiert. Es wird entweder als Portal, als Office Applikation oder als Client Applikation realisiert. Client Applikationen können sowohl als Rich Client wie auch als Web Client umgesetzt werden.

Integration Architecture: Die Integration Architecture-Ebene ist für die Verknüpfung diverser Dienste und zur Verbindung von Diensten mit bestehenden Anwendungen oder Datenbanken sowie zur Koppelung von Services mit den Bestandteilen der Presentation-Ebene zuständig. Die entsprechenden Mechanismen können entweder als logische Integration (ohne ESB), als Enterprise Service Bus oder als Datenintegration realisiert werden.

OASIS Referenzmodell für SOA: OASIS versteht SOA als Paradigma für die Organisation und Nutzung verteilter Ressourcen, die dezentral verwaltet sein können. Services werden als ein Mechanismus verstanden, der Anforderungen und Ressourcen zusammenbringt. Das Referenzmodell konzentriert sich auf die Dynamik einzelner Services.

Open Source SOA-Modell: Das SOA-Modell der Open Source-Gemeinde versteht SOA als Basisinfrastruktur für die Realisierung von Anwendungen mit Open Source Tools und Frameworks. Im Zentrum der Betrachtung stehen die Infrastrukturkomponenten für die Modellierung und Ausführung von Prozessen, die zentrale Registrierung von Diensten und der Enterprise Service Bus.

Orchestration: Die Orchestration-Ebene bildet Geschäftsprozesse und Geschäftsregeln in einer Service Oriented Architecture ab. Sie ist für den dynamischen Bereich der Business-Logik einer auf SOA basierenden Anwendung zuständig.

SOA-Glossar – Service bis Service Ebene

Service: Der Service ist die zentrale Grundkomponente jeder SOA. Ein Service ist eine sich selbst beschreibende, offene Komponente, die eine schnelle und kostengünstige Zusammenstellung von verteilten Applikationen ermöglicht. Services werden durch so genannte Service Provider bereitgestellt. Service Provider sind Organisationen, die eine Service Implementation bereitstellen, die Service-Beschreibung publizieren und den technischen und kaufmännischen Support für einen Service zur Verfügung stellen. Dienste sind Software-Module, die über ihren Namen via Schnittstelle aufgerufen werden, typischerweise in einem Anfrage-Antwort(Request/Reply)-Modus. Ein Service-Nehmer (Service Consumer) ist eine Software, die einen Dienst in Form eines Interface Proxy intern darstellt.

Service Contract: Der Service Contract ist eine informelle Spezifikation der Verantwortlichkeit, der Funktionalität, der Bedingungen und Einschränkungen sowie der Verwendung des Service.

Service Ebene: Die Service-Ebene des SOA-Modells umfasst neben den standardisierten Serviceschnittstellen die Mechanismen zur Verwaltung von Diensten sowie spezialisierte Dienste.

SOA-Glossar – Service Implementation bis Service Management

Service Implementation: Die technische Realisierung des Service, also die Umsetzung der Business-Logik sowie das persistente Vorhalten eventuell notwendiger Daten sind die wichtigsten Bestandteile.

Service Interface: Schnittstellen des Dienstes, die den Zugriffspunkt darstellen (ein und derselbe Dienst kann dabei verschiedene Schnittstellen aufweisen).

Service-Landkarten: Service-Landkarten strukturieren Services in verschiedene Klassen. Es kann zwischen einer technischen und einer fachlichen Strukturierung unterschieden werden. Die technische Strukturierung von Diensten gliedert Dienste aufgrund ihrer Nähe zur technischen Infrastruktur. Die fachliche Strukturierung erfolgt aufgrund der Prozesslandschaft eines Betriebs.

Service Management: Die Anforderungen an SOA Service Management sind die Erfassung der organisatorischen Verantwortlichkeiten von Service Providern und Service Consumern, die Klassifizierung der Services, die Bereitstellung von nachvollziehbaren Lebenszyklen, die Planung der Einführung verschiedener Dienste, die Verwaltung verschiedener Versionen desselben Service, die Instrumente zum Testen von Diensten, die Zuordnung von Service Level Agreements und unternehmensweite Verrechnungsmöglichkeiten für Dienste.

SOA-Glossar – Service Typen bis WS-BPEL Extension for People

Service Typen: Services können anhand der Struktur der Schnittstelle unterschieden werden. In einer SOA kommen drei grundlegend verschiedene Interface-Typen zum Einsatz; Method-Centric Interfaces, Message-Centric Interfaces und Resource-Centric Interfaces.

SOA Foundation: Die SOA Foundation ist als Referenzarchitektur der Rahmen um das IBM Produktangebot für SOA. Sie besteht aus dem Enterprise Service Bus, den verschiedenen Service-Kategorien und einer Reihe unterstützender Bereiche

Web Services: Web Service ist der zentrale Standard zur Realisierung von Service Schnittstellen.

Workflow Management-Systeme: Workflow Management-Systeme (WFMS) sind die technische Basis jeder Business Process Engine, die in BPEL modellierte Geschäftsprozesse ausführen kann. Obwohl diese Technologie erst durch die Standards BPEL, SOAP und WSDL zu einem wichtigen Bestandteil einer SOA wurde, existiert sie schon seit mehr als 10 Jahren. Die Workflow Management Coalition (WFMC), eine Vereinigung von über 300 Konzernen und Universitäten, veröffentlichte 1995 ein Workflow Reference Model.

WS-BPEL Extension for People: BPEL4People erweitert BPEL mit einer Reihe von "Human Interaction Features", um die mangelnde Unterstützung der Ausführung von Prozess-Schritten durch den Menschen zu kompensieren.