Service-orientierte Architekturen (SOA) stehen für eine ganzheitliche Betrachtung einer IT-Landschaft, die betriebliche Prozesse unterstützt: Funktionen, die bisher durch einzelne Systeme abgedeckt werden, sollen dank SOA in einer standardisierten Form unternehmensweit und plattformübergreifend zugänglich sein. Im Idealfall sind sie sogar über Unternehmensgrenzen hinweg aufrufbar. Das zumindest versprechen Microsoft, IBM, Oracle und SAP mit ihren SOA-Stacks. Zugrunde liegt diesen Konzepten ein Fünf-Schichten-Modell, nachfolgend als Blueprint bezeichnet.

Im Gegensatz zur klassischen Drei-Schichten-Architektur (Backend, Business Layer, Presentation), die von Sun mit J2EE und Microsoft mit .NET propagiert wird, ist der SOA-Blueprint der Hersteller wesentlich differenzierter. Er bezieht einerseits die Infrastruktur als Basis ein (siehe Grafik: SOA-Grundmodell). Andererseits kommt mit dem "Orchestration Layer" eine neue Schicht hinzu, die den Ablauf eines Applikations-Service steuert.

Virtualized Infrastructure

Die unterste Schicht "Virtualized Infrastructure" umfasst Ressourcen, die zum Betrieb von SOA-Komponenten notwendig sind. Dahinter verbergen sich Hardwareressourcen wie Speicher, Prozessorleistung und das Netzwerk. Das Modell umfasst die Hardware sämtlicher Hersteller und geht dabei nicht von einer zentralen Steuerung dieser Komponenten aus.

Application Layer

Die zweite Schicht besteht aus allen bereits im Unternehmen eingesetzten Applikationen und Datenquellen. Gemeint sind damit Legacy-Systeme, Standardsoftware wie ERP und CRM sowie Systeme, die individuell für die Organisation entwickelt wurden.

Integration Architecture

Die Integrationsschicht ("Integration Architecture") beinhaltet eine Kommunikationsinfrastruktur, die einerseits Services untereinander verbindet. Andererseits erlaubt sie die Interaktion von Diensten mit bestehenden Systemen. Diese Schicht lässt sich auch mittels einer persistenten Messaging-Infrastruktur umsetzen. Als zentrale Komponente zur Verbindung von Diensten hat sich der Enterprise Service Bus (ESB), auch Enterprise Integration Bus genannt, herauskristallisiert. Er findet sich in sämtlichen SOA-Modellen der großen Hersteller.

Im "Services Layer" sind alle Dienste zu finden, die im Rahmen einer auf SOA basierenden Lösung verwendet werden. Jeder Dienst besteht aus drei Komponenten: der Schnittstelle, dem Service Contract und der Service- Implementierung. Die Schnittstellen sind als Zugriffspunkte gedacht. Der Service Contract ist dagegen eine informelle Spezifikation, die beispielsweise Verantwortlichkeiten, Bedingungen und Verwendung eines Dienstes beschreibt. Die Service-Implementierung schließlich bildet die technische Realisierung des Dienstes.

Orchestration Layer

Der "Orchestration Layer" bildet Geschäftsprozesse in einer SOA ab. Eine Anwendung wird dabei als Sequenz von Dienstaufrufen modelliert. Steuern lässt sich die Anwendung über den abgebildeten Prozessfluss und dessen einzelne Schritte, Entscheidungspunkte und Verzweigungen. Damit entwickelt sich Business Process Modelling zu einem zentralen Element für die Spezifikation einer Anwendung. Diese Spezifikation wird in einem konkreten Workflow abgebildet.

Zwar sind bereits verschiedene standardisierte Modellierungstechniken für Workflows verfügbar, beispielsweise ereignisgesteuerte Prozessketten, Action Workflow und Petrinetze. Die SOA-Modelle der Hersteller erfordern jedoch zwingend die Business Process Execution Language (BPEL) in Kombination mit einer grafischen Modellierung. Die Geschäftsprozesse werden als Ablaufdiagramme formalisiert und getestet. Die meisten Hersteller verfügen über die entsprechenden Werkzeuge zur Erstellung solcher Diagramme. Ob nun IBMs "Websphere Business Modeller" oder "Aris" von IDS Scheer für SAP eingesetzt werden - das Resultat einer Geschäftsprozessmodellierung ist immer ein Ablaufdiagramm. Daraus werden BPEL-Dateien erzeugt, die eine Steuerung eines laufenden Prozesses erlauben.

Oracle

Oracle besitzt nach den Zukäufen von Siebel (CRM), JD Edwards (ERP) und Peoplesoft (Human Resource Management) einen veritablen Zoo unterschiedlicher Systeme. Hinzu kommen die hauseigenen Anwendungen, die auf "Oracle Applications" basieren. Alle diese Systeme will das Unternehmen in den nächsten Jahren zu einem Service-Stack zusammenfügen. Laut Thomas Kurian, Chef von Oracles Middleware-Sparte, ist dabei ein schrittweises Vorgehen geplant.

Im ersten Schritt werden die gesamten Funktionsbereiche gruppiert und als Application Services bereitgestellt. Die existierenden Anwendungen will Oracle über Business Process Management "nachbauen", so dass Bestandskunden von Siebel oder Peoplesoft die gewohnten Programme wiederfinden. Im zweiten Schritt trennen die Softwerker die Application Services von den Datenbereichen und stellen Letztere als Data Services bereit. Last, but not least plant Oracle, neue Lösungen wie branchenspezifische ERP- oder CRM-Systeme als vorgefertigte Business-Prozesse zu produzieren. Diese Lösungen sollen sich einfach und schnell in eine bestehende Kundenumgebung einpassen lassen.

Data Services

Im Vergleich zu den konkurrierenden Konzepten weist das Oracle-Angebot zwei Besonderheiten aus: Der SOA-Stack beinhaltet explizit Data Services, trennt also bewusst Funktionen und Daten durch eine Abgrenzung verschiedener Servicetypen. Darüber hinaus integriert das Modell mit "Business Activity Monitoring" (BAM) und "Real Time Analytics" auch klassische BI Funktionen (BI = Business Intelligence).

Mit Fusion hat Oracle eine viel versprechende Middleware-Komponente in seinem SOA-Stack. Im Gegensatz zu anderen Herstellern ist das Unternehmen gezwungen, SOA als Basis für die eigenen Produkte zu verwenden. Anders lassen sich Siebel- und Peoplesoft-Module kaum zu einer Lösung kombinieren. Für dieses eine Mal gilt also das Prinzip "Lösung reift beim Kunden" nicht. Andererseits befindet sich Fusion noch in einer frühen Phase. Der Kunde muss etwas länger warten als bei anderen Herstellern, kann jedoch davon ausgehen, dass die Funktionen SOA gut unterstützen.

SAP

SAP geht das Thema SOA über seine Netweaver-Plattform an. Einerseits macht der Hersteller damit seine vielen Komponenten über Web-Services zugänglich. Andererseits erhebt Netweaver den Anspruch, als Integrationsplattform für andere Systeme zentrale Komponenten in einem Unternehmen bereitzustellen. Obwohl die Plattform bereits seit längerem auf dem Markt ist und heute als integraler Bestandteil zu sämtlichen SAP-Auslieferungen gehört, setzen noch nicht viele Kunden Netweaver produktiv ein. Mit dem Project "Mendocino" will SAP die Plattform in Microsofts Office-Welt integrieren. Die Initiative wurde Mitte 2005 gestartet, erste Produkte sollen im laufenden Jahr verfügbar sein. Bis dahin dürfte SAP Netweaver auch für Microsofts .NET-Framework besser zugänglich sein.

Kennzeichnend für SAPs SOA-Stack ist die Stellung eines ERP-Systems als Master. Der Walldorfer Konzern geht davon aus, dass Systeme außerhalb der eigenen Welt mittels SOA integriert werden können. Das ist bereits heute mit Netweaver möglich. Die Verwendung einzelner SAP-Module als Services in einer Umgebung, in der SAP nicht das dominierende System ist, gestaltet sich jedoch etwas umständlicher: SAP unterstützt noch nicht alle SOA-Standards vollständig. Eine weitere Besonderheit des SAP-Stacks ist die Tatsache, dass für die Orchestrierung das Aris-Toolset genutzt wird. Geht es um das Modellieren von Geschäftsprozessen, ist Aris seit Jahren führend. Die Modellierung erfolgt jedoch noch mittels ereignisgesteuerter Prozessketten, erst vor kurzem stellte der Anbieter auf BPEL um. Inwieweit sich die SAP-Gemeinde mit der neuen Modellierungssprache anfreunden kann, ist offen.

IBM

Im Vergleich zu den anderen Branchenschwergewichten offeriert IBM den differenziertesten SOA-Stack. Als einziger Hersteller bezieht Big Blue Komponenten ein, die den Betrieb von Diensten unterstützen: Die Schicht "Service Level Automation and Orchestration" beispielsweise beschreibt die Itil-Tätigkeiten Problem Management und Configuration Management als spezielle Dienstegruppe. Die Verwaltung der Services und die Darstellung ihrer Qualitätsmerkmale werden durch weitere Elemente in der Schicht "Utility Business Services" unterstützt. Sogar an die Verrechnung von Diensten hat IBM gedacht. Der Billing-Service, eine wichtige Grundlage zur internen und externen Verrechung der Dienstenutzung, fehlt in den SOA-Stacks der anderen Hersteller.

IBM hat als Hersteller die längste Erfahrung im Bereich Enterprise Service Bus (ESB) und mit "MQSeries" das am weitesten verbreitete Produkt im Portfolio. Eine Stärke des IBM-Systems ist das Reliable Messaging, das eine garantierte Meldungsübermittlung erlaubt. In einem lose gekoppelten Umfeld ist diese Art von Kommunikation indes nicht immer die beste Lösung, vor allem dann, wenn Dienste nicht sehr oft und nicht zeitkritisch verwendet werden sollen. Der Kunde muss sich also fragen, ob er die damit verbundene Komplexität auf sich nehmen will.

IBM setzt auf Infrastruktur

Ohne Zweifel hat IBM die meisten Produkte in seinem Stack und ist in den Bereichen Virtualisierung und ESB führend. Im Gegensatz zu den anderen Herstellern bietet der Konzern aber vor allem die Infrastruktur an, wenn auch in einer besonders ausgereiften Form. Das konkrete System im Unternehmen muss auf dieser Basis gebaut werden. Damit bleibt den Kunden die schwierige Aufgabe, eine heterogene Systemlandschaft zu einem flexiblen und funktionierenden Ganzen zusammenzufügen.

Microsoft

Microsoft gibt sich in Sachen SOA vergleichsweise zurückhaltend, obwohl der Hersteller im Bereich Web-Services als treibende Kraft auftritt und sich an Initiativen für Standardisierung und Interoperabilität beteiligt. Die Windows-Company bildet das SOA-Grundmodell nicht in einem eigenen vollständigen Stack ab. Vielmehr betont das Management die SOA-Fähigkeiten der Produkte "SQL Server 2005", "Biztalk" und des ".NET Framework". Im Mittelpunkt dieser Strategie steht der Biztalk Server, den die Microsoft-Verantwortlichen als "SOA Building Block" positionieren. Sie definieren das System als Kombination aus Enterprise Service Bus und Orchestration Layer, das über eine Schnittstelle BPEL in- und exportieren kann. Kaum ein Kunde setzt indes Biztalk als unternehmensweiten ESB ein. Man darf gespannt sein, was das gemeinsam mit SAP propagierte Mendocino-Projekt diesbezüglich bringen wird.

Microsofts Stärke liegt im oberen Bereich des Stacks: Kaum ein anderer Hersteller bietet Entwicklungswerkzeuge, die SOA-Standards so gut integrieren. Die .NET-Entwicklungsplattform unterstützt vor allem das Erstellen neuer Dienste und den Aufruf bestehender Services besser als die Konkurrenz. Als einziger der großen Player propagiert Microsoft zudem den Rich Client als Graphical User Interface für SOA Lösungen. (wh)