Nicht wenige Softwarehersteller nehmen für sich in Anspruch, im Bereich SOA eine führende Rolle zu spielen und über entsprechend ausgereifte Produkte zu verfügen. Wie aber bewähren sich die Infrastrukturkonzepte in der Praxis? Wo liegen die Unterschiede, wo die Gemeinsamkeiten? Am Beispiel einer konkreten praktischen Realisierung, nämlich der Entwicklung eines Lieferanten-Management-Systems, werden im Folgenden die Ansätze von IBM und SAP miteinander verglichen. Um den gesamten Lebenszyklus bewerten zu können, galt es, die folgenden Phasen zu untersuchen:

• Modellierung (Geschäftsprozess, Anforderungen, fachliche Anwendungsanalyse, technische Konzeption)

• Realisierung (Entwicklung und Test)

• Ausrollen der Services (Build und Deployment, Integration in bestehende Infrastruktur und Repository)

• Betrieb (Überwachen und Fehlerhandling, Rechte- und Zugriffs-Management).

SOA mit IBM

IBM offerierte schon früh ein Portfolio zur Entwicklung von SOA-basierenden Anwendungen. Mit den erweiterten Rational-Produkten gelang es dem Hersteller, eine Modellierungs- und Entwicklungsinfrastruktur für den gesamten SOA-Lebenszyklus aufzubauen (siehe Grafik "SOA-Tools von IBM"). Die zentrale Komponente bildet die "Websphere"-Produktfamilie.

Vorgehensmodell

In der Vergangenheit entwickelte IBM bereits verschiedene Vorgehensmodelle. Sie bezogen sich auf objekt- und komponentenorientierte Ansätze. Bekanntestes Beispiel ist der Rational Unified Process (RUP). Im SOA-Umfeld schickte der Konzern unter anderem "Service Oriented Modeling and Architecture" (Soma) ins Methodenrennen. Generell ist IBM bemüht, das Thema Modellierungsmethodik erschöpfend darzustellen und dabei Rollen und Aufgaben zu definieren. Darüber hinaus gibt es Angaben zur Granularität von Services, aber auch ein Modell für SOA-Schichten - von der Enterprise- bis hin zur Objektschicht. Soma beleuchtet außerdem das Zusammenspiel von Geschäftsmodellen und klassischen objektorientierten Ansätzen wie Use-Case-Modellierung. Bei den einzelnen Websphere-Tools - genauer, bei deren Dokumentation - finden sich dedizierte Hinweise zum IBM-Vorgehensmodell.

Modellierung

Geschäftsprozesse werden in der IBM-Welt mit dem "Business Modeler" erstellt. Im Test kam die Version 6.0 zum Einsatz. In der Simulationskomponente können Kosten und Zeitaufwand für die einzelnen Prozessschritte hinterlegt werden. Der Umgang mit dem Modeler ist intuitiv, allerdings ist die grafische Darstellung von Geschäftsprozessen verbesserungsbedürftig. Auch die langen Wartezeiten bei der Modellierung komplexer Prozesse stören.

Die mit Hilfe des Business Modeler gestalteten Geschäftsprozesse können mittels BPEL (Business Process Execution Language) in den "Websphere Integration Developer" oder in die Entwicklungsumgebung "Websphere Rational Application Developer" integriert werden. Darüber hinaus ist auch der Import in das IBM-eigene Case-Tool (Rational Software Architect/Modeler) möglich. Im Case-Tool lassen sich aus den Geschäftsprozessen die entsprechenden Anforderungen an die einzelnen Services darstellen. Das System generiert bei Bedarf die jeweiligen Web-Service-Rümpfe automatisch.

Entwicklung

Beim "Rational Application Developer" V6 handelt es sich um eine integrierte Entwicklungsumgebung, die auf dem Open-Source-Projekt Eclipse und dem gleichnamigen Framework basiert. Bestandteile sind neben der Entwicklungsumgebung selbst eine Light-Version des IBM-Application Server sowie Funktionen für Test, Debugging und Profiling. Generell überzeugt das System durch seine Geschwindigkeit und Stabilität. Über die Entwicklungsumgebung lassen sich Klassen in ein entsprechendes Diagramm integrieren; mehrere Klassen können auch synchron generiert werden.

Zum Erstellen einzelner Web-Services bietet die IBM-Umgebung einen Wizard an, der die Arbeit erheblich erleichtert. Websphere erstellt im Hintergrund alle notwendigen Hilfsklassen und Deskriptoren, so dass der Entwickler auch bei wichtigen Punkten wie den Übergabeparametern außerhalb des Standards gut unterstützt wird. Die so erzeugten Web-Services können - analog zu Enterprise Javabeans (EJB) - über einen Eclipse-internen Test-Client sofort geprüft werden. Allerdings folgen die generierten Web-Services nicht den gängigen Standards, sondern sind mit proprietären Erweiterungen versehen. Deshalb, aber auch aufgrund der Deskriptor-Erweiterungen, ist eine Portierung auf andere Plattformen allenfalls unter erschwerten Bedingungen möglich. Ähnliches gilt für die Integration anderer Services von Drittanwendungen.

Betrieb

Als einziger Hersteller bietet IBM eine Tool-Landschaft zur systematischen Überwachung von Web-Services innerhalb einer SOA an. Hierbei orientiert sich der Anbieter am Itil-Standard, der auch die Verrechnung von Services einschließt.

SOA mit SAP

SAP ist relativ spät auf den SOA-Zug aufgesprungen, holt aber auf. Die Walldorfer verwenden "Netweaver" als zentrale Integrationsplattform und "Enterprise SOA" (vormals Enterprise Ser- vices Architecture = ESA) als architektonischen Überbau. Bestehende SAP-Anwendungen wie SCM oder CRM werden sukzessive in Richtung Enterprise SOA migriert, so dass sie von anderen Anwendungen, so genannten xApps oder auch Cross Applications, leicht aufgerufen werden können. Eine Migration auf Netweaver, das gerade erst beginnt, den Markt zu durchdringen, ist damit natürlich auch verbunden.

Vorgehensmodell

Grundlage der SAP-Methodik ist der Enterprise Service Community Process. Dieses Modul, das anlässlich der Teched 2005 in Boston vorgestellt wurde, soll als Basis für die Entwicklung der SAP Enterprise Services dienen und zudem Qualitätsstandards für Kundenimplementierungen schaffen. Der Hersteller teilt die Vorgehensweise in vier Stufen ein:

• Discovery-Phase,

• Evaluations-Phase

• Implementierungs-Phase

• Operative Phase.

Alle Phasen sind in mehrere Schritte mit entsprechenden Zielen unterteilt; die Beschreibung ist Web-basiert. Dabei beginnt jede Phase mit einer kurzen Zusammenfassung der Ziele. Word- und Excel-Templates unterstützen die Arbeit der Projektverantwortlichen. Darüber hinaus definiert SAP Rollen, die die Aufgaben innerhalb der Phasen ausfüllen. Beschrieben sind zudem diverse Tools, etwa für die Prozessmodellierung oder die Entwicklung von Web-Services oder Oberflächen.

In der Dicovery-Phase sollen den Kunden die Vorteile von Netweaver und eines Enterprise SOA-Ansatzes - untermauert durch RoI-Untersuchungen - verdeutlicht werden. Ein wichtiger Aspekt ist das Identifizieren von Verantwortlichen (Shareholdern). Eine kundenspezifische Netweaver- und/oder Enterprise-SOA-Roadmap wird anschließend innerhalb der Evaluations-Phase festgelegt. Dazu gehört auch ein Projektplan für die Einführung einer Enterprise SOA.

Im Rahmen der Implementierungs-Phase geht es an die konkrete Umsetzung der Enterprise SOA-Landschaft. Die Projektverantwortlichen starten mit einem Proof of Concept. Das Design der zukünftigen IT-Landschaft auf technischer Ebene ist ein wichtiger Schritt, ebenso Aspekte wie Performance- und Risk-Management. In der Operation-Phase beschreibt das Team den Betrieb und die kontinuierliche Weiterentwicklung.

Modellierung

Für die Modellierung steht in der SAP-Welt primär das Aris-Toolset ("Aris for SAP Netweaver") zur Verfügung, das sehr gut in Netweaver integriert ist.

Entwicklung

SAP bietet mit seiner eigenen J2EE-Infrastruktur ("Web Application Server/WAS 6.4" und "Netweaver Developer Studio") die Möglichkeit, Web-Services in gewohnter Weise zu entwickeln, zu nutzen und zu testen. Ebenso wie das IBM-System ist auch die SAP-Entwicklungsumgebung Eclipse-basiert. Hier ist zu beachten, dass SAP EJB 2.0 unterstützt, IBM hingegen EJB 2.1. Darüber hinaus stellt der WAS eine Ablaufumgebung für Web-Services bereit, bei der die Nutzer auf keinen gewohnten Standard verzichten müssen. Somit bietet SAP eine vollständige Infrastruktur für SOA auf der Basis von Web-Services an.

Die Walldorfer wären aber nicht der Marktführer im Bereich Standardsoftware, wenn sie es dabei hätten bewenden lassen. Enterprise SOA erweitert das Web-Services-Konzept um Business-Funktionen. Das heißt: Die einzelnen Services stellen einen Teil eines Geschäftsprozesses dar. Enterprise SOA basiert auf anerkannten Standards wie WSDL/XML-Schemata.

Über den in der SAP-Umgebung integrierten Wizard lassen sich rasch die entsprechenden Benutzeroberflächen erstellen. Dies hat - wie bei derartigen Tools üblich - seine Tücken: Bei einer Neugenerierung werden die bestehenden Codeteile überschrieben. Dies lässt sich aber durch entsprechende Angaben im Vorfeld vermeiden. Auch kann der Entwickler den generierten Code im Nachgang manuell bearbeiten.

Um Unternehmen bei der Realisierung von xApps zu unterstützen, greift SAP auf das Composite Application Framework (CAF) zurück. Dabei handelt es sich um ein Rahmenwerk zur Erzeugung von Web-Services, das eine effiziente Entwicklung von xApps unter Ausnutzung aller Integrationsebenen erlaubt. Netweaver stellt alle nötigen Funktionen zur Verfügung - von der Oberflächenerstellung über das Enterprise Portal (EP) in Form von "iViews" (SAP-spezifische Portlets die nicht den gängigen Standards gehorchen) und "Web Dynpros" bis hin zum Object Access Layer des Web Application Servers.

Mit mindestens 2 GB Arbeitsspeicher ist der Speicherbedarf der SAP-Infrastruktur (WAS und CAF) sehr hoch. Wie bei der IBM-Lösung sind auch hier Wartezeiten bei der Entwicklung und Übersetzung noch an der Tagesordnung. Im Bereich Betrieb und Monitoring hat SAP noch eine Menge Entwicklungspotenzial. In der Vergangenheit griffen die Walldorfer hier vielfach auf Partner zurück. Hinsichtlich der Abrechnung von Services (Billing) lässt SAP Ansätze erkennen.

Übergreifende Aspekte beider Hersteller

Ein wichtiger Punkt bei der Entscheidung für einen Infrastrukturhersteller ist das Potenzial an vorhanden Services und die Offenheit der jeweiligen Infrastruktur für Services anderer Hersteller. Hier sind IBM und SAP bemüht, jeweils ein Service-Repository mit eigenen und von Partnern entwickelten Services aufzubauen. Beim konkreten Test eines Lieferanten-Management-Systems wurde in beiden Repositories nach Services im Bereich Einkauf gesucht. Dass dabei keine verwertbaren Services gefunden wurden, mag daran liegen, dass beide Hersteller mit dem Aufbau eines entsprechenden Repository erst vor kurzem begonnen haben. Ähnlich sieht die Situation bei der Berücksichtigung von Services-Standards aus. Zwar bemühen sich beide Hersteller, einschlägige Spezifikationen einzuhalten. Andererseits aber entwickeln beide eigene proprietäre Erweiterungen. Diese erschweren es erheblich, Services von Dritten in die eigene Landschaft zu integrieren.