Das Versprechen vieler Hersteller von Modellierungs-Tools, Programmierer könnten aus den Prozessmodellen quasi per Mausklick Code erzeugen, stößt in der Praxis schnell an seine Grenzen. Die automatische Codegenerierung lässt sich meist nur in Teilen eines Entwicklungsprojekts einsetzen, so zum Beispiel für die statischen Eigenschaften einer Applikation. Die Prozesslogik selbst, also der dynamische Teil einer Anwendung, muss dagegen in der Regel von Hand programmiert werden. Zwar versucht man mit den heute üblichen Codegeneratoren, auch die dynamischen Aspekte abzudecken, dies erfolgt jedoch auf einem hohen Abstraktionsgrad: Sprachstandards wie die Business Process Modeling Notation (BPMN) oder Business Process Execution Language (BPEL) liefern Prozessmodelle, bei denen sich auch dynamische Aspekte einer Anwendung automatisieren lassen. Sie setzen allerdings voraus, dass bereits grob granulare Softwareservices verfügbar sind.
Kooperation mit IDS Scheer
Die Firmen E2E und IDS Scheer haben gegen Ende vergangenen Jahres die Lösung "Aris Bridge" vorgestellt. Sie kombiniert Elemente aus dem Aris-Portfolio mit der E2E Bridge. Die Partner sprechen von einer sehr guten Ergänzung ihrer Tools. Während Aris die modellbasierende Prozessgestaltung und das Design abdecke, lasse sich mit E2E die bestehende IT vollautomatisch hinzugenerieren. Das Tool der Schweizer erweitere die von IDS kommende fachliche Sicht auf die Prozesse in Richtung operativer IT. Projektlaufzeiten würden um ein Vielfaches beschleunigt und die Gesamtkosten deutlich gesenkt.
Die Praxis sieht jedoch anders aus. In der Regel findet man in den Unternehmen sehr heterogene IT-Landschaften, eine Mischung aus alten und neuen Systemen, die zum Beispiel auf Web-Ser- vice-Techniken, Corba und handgestrickten Interfaces basieren. Die Verbindung solcher Infrastrukturen mit den in Business-orientierten Sprachen erzeugten Modellen muss nach wie vor manuell programmiert werden. Dieser Medienbruch zwischen modellierten Prozessen und den händisch erstellten, oft undokumentierten Schnittstellen zu existierenden Softwarekomponenten sei auch der Grund, weshalb die meisten SOA-Initiativen bereits früh scheitern, so die Experten.
Das Problem will die in Basel ansässige Firma E2E Technologies mit ihrer E2E Bridge lösen. Das Tool nutzt die Unified Modeling Language (UML) und verfolgt laut Hersteller ein grundlegendes Ziel: Modellgestütztes Arbeiten soll im gesamten Entwicklungszyklus durchgesetzt werden (E2E steht für End-to-End), Programmierer sollen also kaum noch gezwungen sein, sich auf die Codeebene begeben zu müssen. Dabei konzentrieren sich die Schweizer weniger auf das Anwendungs-Design, das von anderen Herstellern wie IDS Scheer und dessen Aris-Modellierungswerkzeugen ohnehin sehr gut abgedeckt wird, sondern auf das Integrations-Design. Im Rahmen von Model Driven Integration sollen bestehende Interfaces, deren Import, Kompilierung, Test und Deployment auf die Modellebene gehoben werden, um dort solche Arbeiten automatisieren zu können.
E2E Bridge enthält als Entwicklungsumgebung den E2E Builder und ein zum XMI-Standard (XML Metadata Interchange) kompatibles UML-Modellierungs-Tool. Hinzu kommen der E2E Server (Runtime-Umgebung) und die E2E Konsole. Innerhalb der Entwicklung geht es zunächst darum, bestehende und meist angepasste Schnittstellen zu erfassen und nachzudokumentieren. E2E Builder, als Java-Plug-in für XMI-1.0-fähige UML-Modellierungs-Tools implementiert, bietet einige Automatismen, um die entsprechenden Metadaten aufzugreifen und in UML-Modelle umzuformen. Importfunktionen gibt es beispielsweise für WSDL- und Java-JAR-Dateien, für W3C-Schemata sowie für applikationsspezifische Metadaten und Funktionen wie Idoc- und BAPI-Schnittstellen von SAP. Damit sind solche Schnittstellen servicefähig.
UML-Design-Phase
Im nächsten Schritt setzen sich Entwickler und Fachabteilung zusammen, um die für eine Anwendung erforderliche Kombination der Schnittstellen festzulegen und damit einen Prozess zu automatisieren. Hier bewegt man sich in der klassischen UML-Design-Phase, wobei sich E2E zur Beschreibung der Integrationsszenarien auf fünf UML-Diagrammtypen beschränkt:
• Use-Case-Diagramme zur Modellierung von Requirements, Rollen, Services etc.,
• Klassendiagramme (statischer Aspekt) beschreiben die Interfaces beziehungsweise das semantische Zusammenspiel der Applikationen,
• Zustands- und Aktivitätsdiagramme umfassen den dynamischen Prozess (Servicelogik, Entscheidungen und Serviceorchestrierung),
• Deployment-Diagramme zur Beschreibung der Systemarchitektur sowie
• Sequenz- und Aktivitätsdiagramme für Serviceprofile und -Debugging.
Im klassischen Entwicklungszyklus würden nun die Implementierung und das Testen folgen. Nicht so bei E2E, denn mit Hilfe des im Tool enthaltenen Compilers lassen sich die Modelle automatisch validieren und in direkt ausführbaren Code für Integrationsdienste überführen, der sich vollautomatisch testen lässt - der Hersteller spricht von UML-Bytecode.
Herzstück der E2E Bridge ist das Server-Modul, das technisch gesehen eine UML Virtual Machine als Laufzeitumgebung für den UML-Bytecode darstellt. Zu dieser Komponente gehören ferner diverse Backend-Adapter etwa für Datenbanken, andere Systembestandteile und Messaging-Formate. Via Java JAR Importer lassen sich zum Beispiel bestehende Java-Schnittstellen wieder verwenden. Schließlich stellt die E2E Konsole ein Web-basierendes Kontrollportal inklusive Transaktions-Monitoring zur Verfügung, um die Integra- tionsservices während ihrer Laufzeit zu überwachen.
Schnittstellen kein Problem
Als entscheidenden Vorteil seiner Lösung betont der Hersteller, dass die zur Integration notwendige Implementierung von Schnittstellen vollständig entfällt. In mehreren Großprojekten, in denen die Integration und Pflege der Interfaces noch manuell vorgenommen wurde, habe sich gezeigt, dass man mit Hilfe der E2E Bridge gegenüber der klassischen Methode einen Zeitgewinn um den Faktor fünf bis zehn erzielen konnte.