| SOA-Tools: IBM und SAP im Vergleich | |
| Übergreifende Aspekte beider Hersteller |
Keine Kommentare
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).
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.
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.
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.
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.
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.
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.
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.
Soap: Simple Object Access Protocol;
WSDL: Web-Services Description Language;
UDDI: Universal Description, Discovery and Integration;
WSBPEL: Web Services Business Process Execution Language;
ebXML: Electronic Business XML; eine XML-basierende Beschreibung von Web-Services.
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.
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.
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.
Jetzt Premium-Inhalt, Preisvorteil und exklusive Prämie sichern! Weitere Informationen gibt es im Aboshop der COMPUTERWOCHE.
