SOA mit Hilfe von MDA

Ein Grossteil der Unternehmensprozesse wird heute durch verschiedenste strategische Legacy-Systeme wie SAP, Oracle oder Host-basierende Anwendungen unterstützt. Informationen und Ereignisse, die in einem System entstehen, können aber nicht mit einfachen Mitteln an anderer Stelle verfügbar gemacht werden. Systemgrenzen müssen dann entweder manuell oder durch Schnittstellenentwicklungen überbrückt werden.

Solcher Integrationsdruck entsteht aber nicht nur bei der Bewirtschaftung von Geschäftsprozessen, sondern auch auf überge-ordneter wirtschaftlicher Ebene, wie etwa durch Unternehmenszusammenschlüsse, Veränderungen rechtlicher Aspekte, sowie zunehmende Marktdynamik.

So verwundert es nicht, dass viele Unternehmen einen grossen Teil ihrer IT-Budgets für die Lösung von Integrationsproblemstellungen ausgeben. Davon wird aber nur ein überraschend geringer Teil für Lizenzen von Integrationssoftwareprodukten verwendet, während der Rest weiterhin in klassische Softwareentwicklung investiert wird. Trotz der hohen Kosten können jedoch viele dieser Projekte die gesetzten Ziele hinsichtlich Realisierung der Anforderungen, Zeitvorgaben und Kosten nicht erreichen.

Integrationsprojekte sind also trotz der verfügbaren Plattformen nach wie vor teuer und risikoreich, wodurch viele Unternehmen sie nur zögerlich in Angriff nehmen. Die Probleme sind dabei aber nicht nur in der technischen Problemstellung, sondern auch in organisatorischen Hürden begründet. Letztere sind vor allem auf Kommunika-ti-onsprobleme zwischen Fach- und IT-Abtei-lung zurückzuführen. Aufgrund proprietärer Lösungen haben klassische Integrationsprojekte zudem die Tendenz, die Komplexität der bestehenden Systemlandschaft durch neue Abhängigkeiten zu erhöhen, was sich wiederum in den Kosten nachfolgender Vorhaben niederschlägt.

Warum sind serviceorientierte Architek-turen (SOA) für Integrationsvorhaben so interessant? Sie versprechen die bislang
von Protokoll und Schnittstellenstandards bestimmten, komplexen und wenig transparenten Integrationsdiskussionen auf eine Liste von in Geschäftssemantik benannten Diensten («Verfügbarkeit Prüfen»), deren Beschreibung in einer Textdatei (WSDL) und die Kommunikation mit einfachen und breit genutzten Protokollen (SOAP/HTTP) zu reduzieren. Durch Standardisierung und lose Kopplung von Webservice-Schnittstellen sind Dienstanbieter und Konsumenten in der Lage, unabhängig voneinander zu agieren.
SOA-Lösungen stellen fachliche Dienste bereit, welche ganze Geschäftsfälle oder einzelne Prozessschritte abbilden. Die öffentlichen Schnittstellen sind hier viel weniger granular als in herkömmlichen Architekturen. Die fachlichen Dienste müssen aber letztendlich mit Hilfe bestehender Legacy Systeme erbracht werden. Dazu werden die benötigten Funktionalitäten dieser Systeme zunächst mit Hilfe einer Integrationsplattform als atomare Services verfügbar gemacht. Diese werden dann orchestriert und als fachliche Composite-Services publiziert.
Integrationsplattformen spielen also für SOA eine zentrale Rolle, da sie technologieabhängige Backend-Systemfunktionen zu technologieunabhängigen fachlichen Diens-ten zusammensetzen und diese damit von den darunter liegenden Systemen und Plattformen abstrahieren.

Die E2E Bridge von E2E Technolgies aus Basel ist ein Spezialfall unter den Integra-tionsplattformen. Sie erlaubt als erste Lösung durchgehend modellba--sier-tes Arbeiten im Sinne von der Object Management Group propagierten Model Driven Architecture (MDA). Im Gegensatz zu herkömmlichen Integrationsplattformen kommt die E2E Bridge ganz ohne klassische Quellcode--basierte Softwareentwicklung aus, da sie UML-Modelle in einer Laufzeitumgebung direkt ausführen und deren Logik dienstbasiert zur Verfügung stellen kann.
Die E2E-Entwicklungsumgebung ist in No Magic"s MagicDraw integriert und erlaubt den Import von WSDL, Java JAR, SAP IDoc-Dateien und BAPI-Interfaces. Der E2E Model Compiler validiert die UML-Modelle auf Konsistenz und optimiert sie für die Ausführung in der Laufzeitumgebung. Mit dem E2E Model Debugger werden automatisch Test-Cases für die im Modell definierten Service-Schnittstellen generiert. Trace Informationen werden in UML-Sequenz- und Aktivitätsdiagramme zurückgewandelt und zusammen mit den Laufzeitinformationen dargestellt.

Der Entwicklungsprozess beginnt mit dem Identifizieren der abzubildenden Geschäftsfälle in Use-Case-Diagrammen. Diese werden in UML-Aktivitäts- und Zustandsdia-grammen grob beschrieben und mit bestehenden Applikationen und Datenquellen in Beziehung gesetzt.
Auf Basis dieser geschäftsorientierten Grobspezifikationen identifiziert dann ein Entwickler die für die Implementierung der ausgewählten Dienste benötigten Funktionen und Daten bestehender Softwareapplikationen. Das von E2E entwickelte Konzept der Automatic Service Extraction erlaubt dem Entwickler, die Schnittstellensignaturen und Metadaten dieser Applikationen direkt zu importieren. Dabei werden automatisch Service-Wrapper generiert, die die Funktionen der Systeme als wiederverwendbare Dienste und Datenmodelle zur Verfügung stellen. Zum Beispiel lassen sich so Metadaten und BAPI-Schnittstellen aus einem SAP direkt extrahieren und in Webservices umwandeln. Das gleiche Konzept lässt sich auch auf bestehende Java JAR Files anwenden.
Transformationen zwischen Datenmodellen unterschiedlicher Systeme sind auf Basis der UML-Klassendiagramme mit Hilfe von UML Action Semantics möglich. Komplexere Transformationen, die beispielsweise eine Entscheidungslogik erfordern, werden über referenzierte Aktivitätsdiagramme realisiert.
Die Implementation neuer Dienste erfolgt durch die Modellierung eigener Service Schnittstellen auf Basis einer Klassendefinition unter Verwendung vorgegebener Stereotypen. Jede Service Operation wird einem Aktivitätsdiagramm zugeordnet, welches die Logik der Operation spezifiziert. Dabei können beliebige Zustände persistiert werden, was eine transaktionssichere Servicearchitektur ermöglicht.

Die angebotenen Dienste und verwendeten Plattformen werden schliesslich als System Nodes in Deployment-Diagrammen modelliert. Hier werden IP-Adressen, Protokoll-Spezifikationen, Port-Adressen und Zugangsparameter der Backend-Systeme mit Hilfe von Tagged Values festgelegt. Es können mehrere alternative Deployment-Konfigurationen für Entwicklungs-, Test- und Produktivumgebungen modelliert werden.
Besondere Bedeutung für Entwickler von hochgradig verteilten Applikationen haben Simulation und Fehlersuche. Im Gegensatz zur klassischen Anwendungsentwicklung, die im Wesentlichen auf eine Plattform zugreift, sind Fehler in einer hochverteilten Service-Landschaft oft schwer zurückzuverfolgen oder zu reproduzieren.
Die E2E Bridge bietet hier eine durchdachte Lösung zur Qualitätssicherung von SOA. Anhand der vollständigen Dienstbeschreibungen in den Modellen kann der E2E Builder automatisch Test Cases generieren. Bei der Ausführung dieser Test Cases liefert die E2E Bridge dann vollständige Trace-Informationen an die Modellierungsumgebung zurück, die alle Datenströme, Performance-Profile und Fehlermeldungen enthalten, welche zwischen den involvierten Systemen aufgetreten sind. Diese werden vom Debugger in ein UML-Modell zurückübersetzt, welches in Form vollständig navigierbarer Sequenz- und Aktivitätsdiagramme dargestellt wird. Daduch bleiben auch bereits im Einsatz befindliche Lösungen zur Laufzeit absolut transparent.

Die E2E Bridge hat ihre Vorzüge bereits in Integrationsaufgaben unterschiedlichster Grösse bewiesen. So wurde beispielsweise im Rahmen der Fusion von SBV und SBG zur heutigen UBS die E2E Bridge eingesetzt, um die Beratungs-, Verkaufs- und Abwicklungsplattform für die Kerngeschäfte im Retail Banking termingerecht zu realisieren. Die Lösung läuft dort heute auf 16500 Arbeitsstationen in 230 Filialen und wird von 10000 Mitarbeitenden genutzt, von denen etwa 3500 gleichzeitig mit dem System arbeiten. Dabei werden täglich 3,2 Millionen Transaktionen über die E2E Bridge abgewickelt.
Auch im B2B-Umfeld ist die E2E Bridge einsetzbar. So wurde bei Agrano, einer Tochter der deutschen Oetker-Gruppe, eine schwer wartbare Schnittstelle zwischen der Logistiksoftware von Agrano und dem zent-ralen SAP-System im Haupsitz durch die E2E Bridge ersetzt, die nun täglich 2000 bis 2800 Operationen transaktionssicher und transparent über das Internet abwickelt. Die Schnittstelle trennt Geschäftslogik von Integrationslogik und harmonisiert die involvierten Datenmodelle.

Die Kombination von Serviceorientierung und modellbasierten Ansätzen verspricht zum einen die konsequente Kapselung der Funktionalität von Backendsystemen und zum anderen deren Wiederverwendbarkeit in Dienstform, was für eine schnelle Anpassbarkeit von IT Systemen an sich ändernde Geschäftsprozesse eine entscheidende Rolle spielt.
Die E2E Bridge ist die erste Integrationsplattform, die diese Ansätze zusammenführt und durchgängig die Transformation plattformunabhängiger Modelle in lauffähige, platt-formabhängige Modelle erlaubt, ohne dafür Quellcode generieren zu müssen. Die Mo-delle werden in einer Laufzeitumgebung ähnlich einer Virtual Machine direkt ausgeführt. Die Trennung von Code und Modell ent-fällt, und damit erübrigt sich auch die Not-wendigkeit separater Dokumentationen.
Die E2E Bridge ermöglicht eine nie dagewesene Transparenz von Integrations- und Migrationsprojekten, da der Entwicklungsstand zu jedem Zeitpunkt dem Do-kumen-ta-tionsstand entspricht. Daraus resultieren nicht nur geringere Projektaufwände durch die verbesserte Kommunikation zwischen Fachabteilungen und Entwicklern, sondern auch wesentliche Einsparungen beim Unterhalt einer Integrationsinfrastruktur.

* Jan Möhr ist Senior Consultant bei Unic Internet Solutions, Zürich, www.unic.com