SOA meets BPM

Wie grenzt sich SOA gegenüber EAI, ESB und dem von SAP getriebenen Begriff ESA ab?
Diese Frage an den Expertenrat beantworten Florian Mösch von T-Mobile und Karin Sondermann von Microsoft.

Florian Mösch:

EAI ist im Wesentlichen ein rein technischer Ansatz zur Integration von Anwendungssystemen. Die verschiedenen Hersteller haben hauptsächlich proprietäre Produktsuiten herausgebracht, deren Einsatz ein sehr hohes Spezialistenwissen erfordert. Zu SOA hingegen gibt es durchaus erkennbare Standardisierungsbemühungen, beispielsweise:

• JMS (Java Message Service) als Backbone
• JBI (Java Business Integration) als Integrationsschicht
• WSDL / XSD als Servicespezifikation
• SOAP als Transport
• BPEL (Business Process Execution Language) als Workflow-Standard

Aus architektureller Sich kann man durchaus sagen, dass die Infrastruktur einer SOA eine Weiterentwicklung von EAI ist. In der neuesten Ausgabe des “SOA Magazine” gibt Cyrille Thilloy einen recht guten Überblick über die Historie von Enterprise Integration und die Entwicklung über EAI zu SOA. Bestandteil des Architektur-Blueprints einer SOA ist der Enterprise Service Bus (ESB), der allerdings mehr umfasst als der EAI Backbone. Zum ESB zählen auch die Protokoll-Adapter (z.B. Webservices, ebXML,…), das Service Registry, Mapper, Business Process Management und Service Orchestration Engine.

ESA ist die SOA-Geschmacksrichtung von SAP, die sich im Grunde nur dadurch differenziert, dass der Blueprint rund um NetWeaver aufgebaut ist und man dort hauptsächlich SAP-Komponenten als Service-Backends findet.

Karin Sondermann:

Viele Geschäftsprozesse laufen heute IT-gestützt ab und sind in der Regel von mehreren in sich geschlossenen, transaktionsorientierten Anwendungen abhängig. Die Kommunikation zwischen den Anwendungen in Bezug auf Datenformate und –typen ist häufig nicht standardisiert und zu fein granuliert. Traditionell oblag die Aufgabe einer heterogenen Integration zwischen den unterschiedlichen betriebswirtschaftlichen Silo-Anwendungen (ERP, CRM, SCM, etc) innerhalb der Unternehmen den Enterprise-Application-Integration-Lösungen (EAI) und ihren diversen Adaptern als auch entsprechenden Entwicklern. Unzureichende Flexibilität und Agilität der Prozesse und damit der Unternehmen, sowie enorme Wartungskosten sind das heutige Resultat.

Mit dem Aufkommen des Internets, der Web Services und ihrem zunehmenden Reifegrad entwickelte sich eine neue Art der Kommunikation und Integration für systemübergreifende End-to-End Geschäftsabläufe auch über Unternehmensgrenzen hinweg (B2B). Die Hauptmerkmale dieser neuen Welt sind eine auf Standards beruhende Line-of-Business (LOB) oder auch semantische Interoperabiltität zwischen den Anwendungen sowie deren lose Kopplung, die wichtigste Voraussetzung für den Bau flexibler Software-Systeme.

Die Realisierung serviceorientierter Geschäftsmodelle erfordert allerdings ein neues Anwendungsmodell das realisiert werden muss. Es stellt ein Netzwerk von Services dar, das Menschen, Prozesse und Informationen miteinander verbindet. Neu entstehende Anwendungen sind auf die Geschäftsabläufe ausgerichtet und zeichnen sich durch einen hohen Verteilungsgrad aus. Vernetzte Geschäftsabläufe umfassen mehrere Abteilungen eines Unternehmens und gehen auch über die Firmengrenzen hinaus. Anwendungen müssen miteinander nahtlos kommunizieren und Informationen jeder Art austauschen können, unabhängig davon, auf welcher Plattform sie laufen, in welcher Programmiersprache sie entwickelt wurden und welche Technologien ihnen zugrunde liegen.

Im Mittelpunkt stehen hier Services, die eine oder mehrere fachliche Funktionen beschreiben und durch Austausch von Business Objekten in Form von strukturierten Nachrichten kommunizieren. Die fachlichen Services werden Idealerweise durch Web Services implementiert. Der Web Service ist dabei ein atomarer Software Baustein mit fachlichen Funktionen (Methoden). Die verwendete Programmiersprache (Java, C# oder C++) ist nebensächlich, denn Web Services haben eine Adresse und kommunizieren über standardisierte Nachrichten, die das Beschreibungsformat XML benutzen. Die Schnittstellenbeschreibung des Web Services, das Schema, erfolgt mit der Web Services Definition Language (WSDL). Als zugrunde liegendes Architekturparadigma hat sich hier die serviceorientierte Architektur (SOA) etabliert.

Für den Betrieb der Interaktion zwischen den Services und mit den bestehenden Systemen bedarf es einer Kommunikationsinfrastruktur. Für dieses wichtige Element einer SOA hat sich die Bezeichnung Enterprise Service Bus (ESB) etabliert. Der Bus ist nicht eindeutig definiert und wird sich, wie auch SOA, nicht durch ein Produkt alleine abbilden lassen. Zu den Aufgaben des Busses gehört die gesteuerte, zuverlässige, nachrichtenbasierte Kommunikation. Die Voraussetzung für die Kommunikationsinfrastruktur ist die Unterstützung der Web Services Standards sowie das zugrunde liegende Kommunikationsmodell. Das bedeutet, die Kommunikationsinfrastruktur vermittelt den Datenaustausch zwischen Prozessen über verschiedene Systeme hinweg – sei es über SOAP oder über eine Message Oriented Middleware (MOM). Eine weitere fundamentale Funktion stellt die Transformation von Datenformaten und das intelligente Routing von Nachrichten aufgrund von bestimmten vordefinierten Kriterien dar. Schließlich sollte die Kommunikationsinfrastruktur ein Repository unterhalten zur Verwaltung der Adressen und Schnittstellenbeschreibungen (WSDL) aller Web Services.