Unternehmensweiter Nahverkehr

Wie sich die untersuchten ESB-Suites als zentrale Komponente für die Steuerung von Geschäftsvorgängen eignen, war Thema des ersten Teils des Testsberichts (s. »Herzen für Unternehmensabläufe«, Network Computing 17/06, S. 30ff). Der zweite Teil blickt nun genau unter die Haube der einzelnen Teilnehmer: »AquaLogic Service Bus 2.1« von BEA Systems, »SOA Suite« von Oracle, »Software BusinessWorks 5.3« von Tibco, »SOA 2006 Platform 3.7« von Fiorano Software, »Software ESB 6.5« von Cape Clear, »WebSphere Message Broker 6.0« von IBM, »Enterprise Service Integrator 2.1« der Software AG und »SOA Suite 6.1« von Sonic Software.

BEA Systems AquaLogic Service Bus 2.1
Aqualogic wird innerhalb einer abgespeckten, leichtgewichtigen Version des Weblogic-Servers (WLS) installiert. Im Grunde ist es ein Standalone-J2EE-Produkt. Es lässt sich als Modul in jeden WLS-Container installieren, nicht aber in anderen J2EE-Containern wie »JBoss« oder »Websphere«.

Aqualogic benötigt kein Metadaten-Repository, es sei denn, der Anwender möchte die Berichts- und Monitoringfähigkeiten verwenden. In diesem Fall nutzt das Produkt entweder eine vorhandene relationale Datenbank oder die integrierte »Pointbase«-Datenbank.

Die Einrichtung von Aqualogic geschieht schnell, da die Design-Anwendung vollständig auf Webtechnik basiert. Sie nutzt die HTTP-Sitzungsmanagement-Fähigkeiten von WLS, um zu verfolgen, was der Designer tut. Aqualogics Verwendung eines Web-Browsers als Entwicklungsanwendung ist etwas Besonderes.

Aqualogic unterscheidet zwischen Geschäfts- und Proxy-Diensten. Externe Clients verbinden sich immer mit einem Proxy, während interne Dienste mit beiden Diensten kommunizieren können. Das Produkt unterstützt E-Mail, HTTP/S, verschiedene Dateiformate, JMS (Java-Messaging-Services) und FTP. Im Test wurden ein SMTP-Dienst zum Senden von Mail und ein JMS-Dienst zum Aufruf der »OpenJMS«-Queue erzeugt. Die Orchestrierungsnotation in Aqualogic ist proprietär, aber intuitiv und nah genug an der Business-Process-Modeling-Notation (BPMN). Benutzern wird sie bei der Orchestrierung von Services daher nur wenig Schwierigkeiten machen.

Die Web-Service-Unterstützung in Aqualogic ist exzellent. BEA implementierte die Basic-Security-Profile der WS-I (Web-Services- Interoperability-Organization). Hinzu kommen SAML 2.0 (Security-Assertion-Markup-Language) und das Web-Services-Security-Username/Certificate-Profile. Ein WS-I-Compliance-Test steht bei der Orchestrierung von Webdiensten per Kontrollkästchen zur Verfügung.

Nach der Orchestrierung (Zusammenstellung) des Dienstes lässt sich der resultierende Proxy-Service mit Aqualogics Proxy-Tester prüfen. Leider zeigt der Tester nicht die Ausführungszeiten der einzelnen Schritte im Prozessablauf an.

Aqualogic unterstützt externe Datenquellen wie eine »Oracle9i«-Datenbank nur unzureichend. Das Produkt verlangt, dass eine solche Verbindung andere Mechanismen wie »WebLogic Integration« herstellen. Eine einfache JDBC-Integration (Java-Database-Connectivity) als Teil der Service-Orchestrierung ist nicht möglich.

Fremde JMS-Queues konfiguriert der Anwender mit der WLS-9.1-Administrationskonsole. Unter folgenden Umständen erfolgt die Konfiguration im WLS 9, und nicht in Aqualogic: Codierung der Datenbankverbindung innerhalb der Dienste-Befähigungs-Schicht und Verteilung als Komponente des Servers.

Nach der Orchestrierung aktiviert der Anwender die erzeugte Sitzung. Damit wird auf dem Server automatisch eine neue Version der Orchestrierung eingerichtet. Aqualogic bietet einfache Versionskontrolle und Änderungsverfolgung. Roll-backs sind Sache eines Mausklicks.

Getestet wurden auch die Monitoring- und Berichtsfähigkeiten von Aqualogic. Sie werden auf der Dienstebene konfiguriert und zeigen die Inhalte von Variablen der Prozessebene. Der Anwender kann eine in der Service-Orchestrierung mitzuführende Variable erzeugen und spezifizieren, dass sie überwacht werden soll.

Oracle SOA Suite
Die primäre Komponente der SOA-Suite ist Oracles BPEL-PM 10.1.2. Die SOA-Suite ist ein J2EE-Angebot, das in zahlreiche Container installiert werden kann, darunter IBMs Websphere, BEAs Weblogic, JBoss und Oracle-AS. In der Standardeinstellung richtet die Installationsroutine die Suite in einem Oracle-AS-Container mit integriertem Metadaten-Repository »OracleLite« ein.

Die SOA-Suite unterscheidet sich von den meisten anderen getesteten Produkten, weil keine ihrer Instanzen einer Serviceorchestrierung Zustände speichern (stateless). Sitzungsinformationen legt die Lösung im Repository ab. Obwohl Oracle-Lite das Standard-Repositiory ist, lässt sich die Suite auch zur Nutzung einer relationalen Datenbank (RDBMS) der Enterprise-Klasse konfigurieren. Instanzen der SOA-Suite kommunizieren nicht, so dass sich keine Backup-Knoten bestimmen lassen. Da aber sämtliche Status- und Zustandsinformationen in einem gemeinsamen Repository gespeichert werden, sollten sich Instanzen selbst neu erzeugen können. Failover erfordert ein auf Containerebene konfiguriertes Load-Balancing oder einen externen Hardware-Load-Balancer.

Dank der Präsentation der Daten in der Web-Konsole der Suite lässt sich leicht navigieren. Nur die SOA-Suite ist in der Lage, Orchestrierungen direkt vollständig zu verwalten und mehrfache Versionen derselben Orchestrierung auszuführen. Die Audit-Trail-Fähigkeiten der Produkte von Oracle und BEA sind ausgezeichnet, aber nur bei Oracle stehen diese für alle Instanzen bereit. Dafür ist bei der SOA-Suite das Monitoring nicht sehr detailliert. Die Konfiguration der SOA-Suite für die Kommunikation mit Open-JMS verlief wie erwartet und ist mit den anderen getesteten Produkten auf dem gleichen Stand. RDBMS-Zugriff zu erhalten, war ebenfalls einfach.

Die Entwicklungskomponente der SOA-Suite gibt es als »JDeveloper«- oder Eclipse-Plug-in. Für die Serviceorchestrierung kommt BPEL (Business-Process-Execution-Language) zum Einsatz. Der BPEL-Editor von Oracle machte mehr Eindruck als der von Cape Clear. Oracle nutzt zur Erzeugung von Transformationen eine ähnliche Lösung wie Fiorano, aber Oracles ist einfacher zu benutzen. Beide Ansätze arbeiten grafisch und nutzen Drag-and-Drop-Mechanismen, um Expressions zu erstellen. Bei Oracle kann der Anwender aber die verschiedenen Funktionen wie Concat nutzen, ohne sich dabei mit Parametrisierungen zu beschäftigen müssen.

Die Standard-XSLT-Engine (Extensible-Stylesheet-Language-Transformation) der Suite ist »Xalan« mit »Xerces« als Standard-XML-Parser. Beide lassen sich durch andere Parser und Engines ersetzen. Die NWC-Szenerie ließ sich rasch modellieren und durch das J-Developer-Plug-in schnell verteilen. Apache-Ant-Scripts muss der Anwender jedoch selbst von Hand erstellen.

Das Routing innerhalb einer Orchestrierung kann auf Payload, auf Header oder Prozessvariablen basieren. Die meisten der getesteten Produkte besitzen dieses Funktion. Lediglich IBM routet Nachrichten nur anhand des Headers. Routing und Entscheidungen beruhen auf »XPath«-Ausdrücken. Oracles »XPath Builder« ist prima. Er verlangte kein Ausschneiden/Einfügen wie bei den Produkten von Sonic Software und Software AG.

TIBCO BusinessWorks 5.3
Tibcos Bus-Lösung verwendet wie die von Sonic JMS und zieht Vorteile aus Tibcos »Enterprise Message Service« (EMS). Anders als bei Sonic können Business-Works-Nutzer aber den darunter liegenden Transportmechanismus wählen. EMS lässt sich durch einen anderen Messaging-Backbone ersetzen, beispielsweise durch Sonic-MQ, IBMs MQ-Series oder ein rein mit HTTP arbeitendes System.

Businessworks (BW) erfordert einen Laufzeitagenten, der das zentrale Management von der Web-Administrationskonsole aus ermöglicht. »BW Designer«, Tibcos Entwicklungsanwendung, wird mit dem nächsten Release in Richtung »Eclipse« marschieren. Für das Management nutzt Tibco wie Sonic und BEA »Domänen«, die BW-Server für administrative Zwecke in Gruppen zusammenfassen. Dies unterscheidet sich von Clustern, die für Verfügbarkeit und Failover zum Einsatz kommen. Besonders ist das Tibco-Produkt, weil es Management über WSDM (Web-Services-Distributed-Management) unterstützt und dafür Management-Using-Web-Services-Profile (MUWS) nutzt.

Businessworks ist eine Standalone-Applikation als direkt ausführbare Datei (keine Interpretation), die für ihre grafische Administration Apache/Tomcat verwendet. Apache sorgt für die Web-Services-Endpunkte und kommuniziert über einen internen Kanal mit dem Businessworks-Server, um Clientanfragen weiterzugeben. Ein Servlet – Soap- und Policy-Informationen entfernt – reicht dann die Core-Nachricht zur Verarbeitung an die Tibco-Engine weiter.

Sonic, Software AG, Oracle und Cape Clear verlangen, dass alle erforderlichen Schritte innerhalb einer Orchestrierung als atomare Dienste arbeiten. Tibco verfolgt dagegen einen mehr integrationsorientierten Ansatz und bietet unzählige Optionen, um Dienste, Datenbanken oder Enterprise-Applikationen einzubinden. Die einzige ein wenig ungewöhnliche Konfigurationsanforderung ist, dass eine Serie von Verbindungen – eine für JDBC, eine für HTTP und eine für JMS – separat zu definieren ist. Während andere Produkte ein SQL-Statement eng mit einer spezifischen JDBC-Verbindung verknüpfen, erlaubt Tibco dem Benutzer, die JDBC-Verbindung wiederzuverwenden und weitere SQL-Statements auszuführen.

Eine Anforderung war, »XPath« zu nutzen, um variable Daten Schritt für Schritt innerhalb der Orchestrierung einander zuzuordnen (Mapping). Tibcos automatische Generierung der erforderlichen X-Path-Ausdrücke erleichtert dies ein bisschen. Die Anzeige der erstellten X-Path-Ausdrücke Feld für Feld erschwert die Angelegenheit allerdings sehr.

Nach der Orchestrierung des Dienstes war noch eine Web-Service-Schnittstelle zu generieren. Diese erlaubte den Test-Clients, nach dem Deployment der Dienste mit diesen zu kommunizieren. Anders als die Produkte von Sonic und Software AG generierte Businessworks alle für WSDL (Web-Services-Description-Language) erforderlichen Informationen. Diese ließen sich vor der Generierung des Dienstes noch modifizieren.

Zur Verteilung der orchestrierten Dienste galt es, ein Enterprise-Archive (EAR) zu erzeugen und dann ein Prozessarchiv. Zu diesem wurde der Bestellprozess hinzugefügt. Businessworks hat immerhin alle Abhängigkeiten automatisch bestimmt und die entsprechenden Komponenten dem Archiv mitgegeben.

Nach einem Klick auf die mit »Build Archive« beschriftete Schaltfläche war die EAR-Datei fertig und bereit für die Verteilung. Tibco erlaubt keine Verteilung mit Businessworks-Designer. Stattdessen ist dafür entweder ein Script erforderlich oder der eine manuelle Verteilung über die Web-Konsole.

Verteilte Serviceorchestrierungen zu testen, war schwieriger, weil es keine eingebauten Werkzeuge gab. So etwas besaßen beispielsweise die Produkte von Oracle, Cape Clear und BEA. Tests mit Businessworks sind möglich. Dazu muss der Anwender allerdings einen kleinen Test-Service erstellen, der den verteilten Dienst aufruft.

Fiorano SOA Platform 2006 3.7
Fiorano-SOA-Platform-2006 ist ein J2EE-ESB mit mehreren entfernbaren Komponenten. Die gesamte Administration erfolgt über fette Java-Clients. Fiorano nutzt eine Peer-to-Peer-Hybridarchitektur. Das verlangt die Definition von Peer-Servern als die Knoten, auf denen dann ESB-Prozesse laufen. Dies hat zur Folge, dass alle Serviceorchestrierungen auf bestimmten Knoten eingerichtet werden müssen. Während der Einrichtung kann der Administrator Backup- und Failover-Knoten angeben.

Für das Management der Komponenten nutzt Fiorano JMS. Alle BPEL-Prozesse werden im Fiorano-Studio zusammengestellt (orchestriert). In künftigen Versionen wird auch das Modellierungswerkzeug, gegenwärtig ein Java-Client, in diesem Werkzeug enthalten sein. Fiorano-Studio erledigt auch das gesamte JMX-Management (Java-Management-Extensions): Es ist aber unübersichtlich und wenig flexibel.

Peer-Server definiert der Administrator mit Hilfe von Profilen. Dieses Konzept kennen die JBoss-/Websphere-Administratoren bereits. Peer-Server werden so konfiguriert, dass sie ihre Konfigurationen vom ESB-Server erhalten. Die Kommunikation zwischen Peer- und dem ESB-Server erfolgt über JMS. Die Kommunikation zwischen Peer-Servern nutzt aber ein proprietäres Protokoll über JMS.

Im Produkt steckt ein umfangreiches sicherheits- und regelorientiertes Modell, das definiert, welche Komponenten auf jedem Peer-Server laufen dürfen. Der Services- und Security-Manager ist leicht zu verstehen. Die Regeln, die die Ausführung von Komponenten auf bestimmte Peer-Server limitieren, lassen sich leicht konfigurieren. Fioranos Ereignis-Prozess-Orchestrator (EPO) enthält eine Option, die Nutzung von Ressourcen zu überprüfen. Diese markiert Orchestrierungen, deren Komponenten-Verteilungs-Konfigurationen gegen diese Regeln verstoßen, als Fehler.

EPO offeriert standardmäßig viele Protokolle und Datenformate. Bei der für den Test gestellten Anforderung, eine Open-JMS-Connectivity und eine JDBC-Verbindung zur Oracle9i-Datenbank zu konfigurieren, gab es Probleme. Sonst bereitete die Modellierung der NWC-Szenerie keine Schwierigkeiten. Fiorano unterstützt BPEL, aber die primäre Serviceorchestrierung nutzt einen proprietären Modellierungsbegriff.

Fiorano-Studio war ein bisschen eigenartig, was Verbindungen betrifft: Diese ließen sich nicht mehr verschieben, sobald sie eingerichtet waren. Fioranos Integration von BPEL ist auf gleichem Stand mit der von Software AG. Kleinere Orchestrierungen lassen sich mit beiden Produkten mit BPEL modellieren und dann als Web-Services darstellen. Anschließend werden diese in die jeweiligen Orchestrierungsbereichen der Produkte eingefügt. Der Fiorano-Mapper war eines der besten visuellen Mapping-Werkzeuge im Test. Felder ließen sich einfach per Drag-and-Drop verknüpfen. Ebenso einfach waren XSLT-Funktionen einzubinden. Nimmt der Benutzer Datenzulieferungs- (Feeder) und Display-Komponenten in die Orchestrierung auf, erlaubt Fiorano ihm, Orchestrierungen vor der Verteilung zu testen. Mit einer Feeder-Komponente lässt sich beispielsweise eine Nachricht mit dem für eine Orchestrierung geeigneten Protokoll injizieren. Die Display-Komponente zeigt das resultierende Ausgabedokument.

Wie bei den anderen Produkten in diesem Test, die aus der EAI-Welt (Enterprise-Application-Integration) abstammen, liefert Tomcat/Axis die Web-Services-Unterstützung. Die Integration ins Produkt ist nicht gut gelungen. Das Modell musste als separater Web-Service-Prozess erzeugt und dann in Axis importiert werden, um einen Soap-over-HTTP-Eingangspunkt in der Orchestrierung zu erstellen. Die Unterstützung der Konsumenten der Web-Services war zufriedenstellend. Es traten aber beim Einfügen eines externen Web-Dienstes in die Orchestrierung ein paar Probleme auf. Beispielsweise fehlte das Benutzer-Feedback beim Import externer WSDL-Dateien.

Die Verteilung orchestrierter Services war mit einem Klick erledigt. Fiorano kann Änderungen in einem orchestrierten Service mit bereits auf dem Server laufenden Prozessen synchronisieren. Die Fähigkeiten des Produkts, auf den Servern laufende Services zu verwalten, sind aber limitiert.

Cape Clear ESB 6.5
Das Produkt von Cape Clear ist wegen seines Ursprungs interessant: Der ESB 6.5 hat seine Wurzeln in einer reinen Web-Services-Welt. Cape Clear und BEA sehen den ESB als Serviceorchestrierungs-Mechanismus und enthalten keine konventionelle Integration. Beide Hersteller nutzen eine von Metadaten getriebene Zusammenstellung, um die Funktionalität zu implementieren. Aber Cape Clear stützt sich dabei auf BPEL.

ESB 6.5 basiert auf J2EE und lässt sich mit fast jeder beliebigen Enterprise-Services-Plattform bereitstellen. Das Produkt wird mit JBoss ausgeliefert. Die Orchestrierung verlangt ein BPEL-Repository, beispielsweise die eingebettete Hibernate-Datenbank oder Oracle9i. Möchte der Administrator später zu einer anderen Datenbank migrieren, dann muss er dafür die Konfigurationsdateien manuell modifizieren oder die Applikation neu installieren.

Die Entwicklungsanwendung von Cape Clear ist ein Eclipse-3.1-Plug-in. Dieses erlaubt es, sowohl individuelle Dienste als auch Orchestrierungen zu entwickeln. Services, die JMS-Queues und Datenbanken integrierten, ließen sich im Test einfach erzeugen. Es fehlte aber ein einfacher Mechanismus für SMTP – hier war Codierung gefragt.

Die Integration eines fremden JMS ist eine Kleinigkeit und erfordert nur wenige Eingaben über die Web-Konsole. Sobald eine Integration definiert ist, fügt der Administrator nur noch einen Adapter hinzu und ruft dann die JMS-Queue von der Orchestrierung auf.

Die Orchestrierung mit Cape Clears BPEL-Editor funktionierte gut. Mancher Administrator wird aber Oracles Produkt bevorzugen. Jeder auf dem Server publizierte Service wird automatisch der eingebauten UDDI-2-Registry (Universal-Description, Discovery-and-Integration) hinzugefügt. ESB 6.5 ist eines der wenigen Produkte, das weder UDDI 3 unterstützt, noch der Laufzeitkomponente Zugriff auf externe Registrierungen erlaubt. Funktionen für interne und externe Registrierungen sind aber vollständig in die Entwicklungsanwendung integriert.

Sind Services erst einmal erzeugt und orchestriert, erfordert die Bereitstellung nur noch eine Veröffentlichung der erzeugten Archive auf dem Server. Im Gegensatz zu den Produkten von BEA und Oracle generiert Cape Clear Code für jede Orchestrierung. Cape Clears Web-Services-Tester macht es einfach, Dienste zu testen. Der Zugriff auf den Tester erfolgt direkt aus Eclipse heraus.

Die Prozessmanagementfunktionen von ESB sind ein Pluspunkt, aber deren Möglichkeiten sind deutlich begrenzter als die in Oracles Produkt. Es ließen sich aber laufende Prozesse beobachten und einzelne Komponenten zur Laufzeit starten und stoppen.

IBM WebSphere Message Broker 6.0
Websphere-Message-Broker ist eine C/C++-Applikation, die IBMs MQ-Series-Message-Middleware vorteilhaft nutzt. Jeder Broker benötigt eine MQ-Instanz, die er für Management und Bereitstellung verwendet. Für MQ selbst ist nur wenig Management erforderlich, da es für die Service-Orchestrierung nicht benötigt wird. Die Verteilung der Archivdateien über MQ funktioniert zuverlässig.

Websphere-Message-Broker speichert die Metadaten, die eine Orchestrierung beschreiben, in einer lokalen Datenbank – Cloudscape oder DB2. Andere RDBMSs, darunter Oracle und SQL-Server, lassen sich aber ebenfalls konfigurieren. IBM nutzt eine ähnliche Terminologie wie BEA: Der Anwender orchestriert Dienste als Message-Flow, und nicht als Orchestrierung, Modell oder Prozess. Das IBM-Produkt unterscheidet flexibel Dokument- und Leitungsformate (Wire). Der Anwender kann entscheiden, wie Dokumente über den Bus transportiert werden, und wählen, welche Protokolldaten genutzt werden. Diese Flexibilität sorgt für Geschwindigkeit, erfordert weniger Transformationen und ermöglicht einen einfacheren Umgang mit Formaten.

Erzeugt der Anwender einen neuen Message-Flow und spezifiziert als Eingabeformat XML, dann nutzt das System den Default-Xerces-Parser. Aber auch andere XML-Parser und XSLT-Engines lassen sich konfigurieren. Zur Auswahl stehen außerdem viele Datenformate.

Eingehende Daten setzt das System in ein neutrales, hierarchisches Format um, falls der Anwender nichts anderes spezifiziert hat. Alle Schritte im Message-Flow beziehen sich auf die Daten in ihrem ursprünglichen Zustand. Das verlangt aber leider auch die Nutzung von Nachrichten-Sets und Transformationen selbst für die einfachsten XML-zu-XML-Daten-Mappings. Die erforderlichen XSLTs generiert das System automatisch aus der erstellten Message-Map.

Die Erzeugung der Konsumentenverbindung zum Web-Dienst war ein schwieriger Prozess, der – zugegeben – mit einer bereits vorhandenen Registry ein wenig einfacher gewesen wäre. Websphere-Message-Broker besitzt keinen Eingangspunkt für ankommende Soap-Nachrichten, sondern verlangt einfach, dass sie mittels XML gekennzeichnet sind. Eine Orchestrierung als Web-Service bereitzustellen beziehungsweise zu veröffentlichen, erfordert nur deren URI in der Konfiguration anzugeben und die Zusammenstellung zu veröffentlichen.

Innerhalb der Orchestrierung auf die Datenbank zuzugreifen, glich einem Abenteuer. Zuerst musste der ODBC-DSN (Data-Source-Name) erstellt werden. Anschließend war es immer noch erforderlich, ein Stück ESQL (Extended-SQL) oder Java zu schreiben, um einen simplen Lookup durchzuführen. Die Verbindung innerhalb der Entwicklungsanwendung zu konfigurieren, war hingegen einfach. Zur Bereitstellung der Orchestrierung erzeugt der Anwender eine Archivdatei, die er dann per Drag-and-Drop in eine Execution-Gruppe überträgt. Der Gesamteindruck von IBMs Websphere-Message-Broker als ESB war zufriedenstellend. Allerdings erfordert das System eine Menge Training.

Software AG Enterprise Service Integrator (ESI) 7.2
Die Installation von Enterprise-Service-Integrator (ESI) verlangte ein paar Systemaktualisierungen: Microsoft-Installer 3.1 war notwendig, um Tamino, die XML-Datenbank der Software AG (SAG), zu installieren. Tamino verlangt einen externen Apache-Server, bevor es sich einrichten lässt. Ansonsten lief der Vorgang glatt.

ESI ist ein J2EE-System, das sich in der Standardeinstellung in einen JBoss-Container installiert, obwohl auch BEA-Weblogic- oder IBM-Websphere-Container möglich sind. Die Tamino-XML-Datenbank speichert Prozessdaten und ermöglicht Load-Balancing-/Failover-Konfigurationen. ESI war das einzige Produkt im Test, das als Kommunikationsprotokoll zwischen seinen Standalone-Connection-Factories und dem ESI-Core-Server Java-RMI (Remote-Method-Invocation) nutzte. Nachrichten transportiert das System im XML-Format über den Bus. SAG nutzt die Bezeichnung »Sequenz« für orchestrierte Dienste und speichert diese Sequenzen als auf XML basierende Metadaten im Centrasite-SOA-Repository. Der Aufruf von Sequenzen erfolgt über Portale, mit denen Clients via Soap/HTTP oder JMS kommunizieren. Im Test löste der Versand eines Soap/HTTP-Dokuments an ein Portal die richtige Sequenz in der Component-Factory aus.

Die meisten Administrations- und Konfigurationsaufgaben erledigt der Administrator mit der Web-Konsole von ESI. Der größte Kritikpunkt ist hier, dass die Konsole keinen Zugriff auf Logdateien erlaubt. Die ersten Versuche, einen Web-Dienst bereitzustellen, schlugen fehl, und es dauerte eine Ewigkeit, die richtigen Logdateien zu finden, um das Problem zu lösen können.

Die Konfiguration der Verbindung mit Open-JMS war bis zu der Stelle einfach, an der JAR-Dateien dem Classpath hinzugefügt werden mussten. Es ist sehr lästig, jede einzelne JAR-Datei per Hand in ein kleines Textfeld eintragen zu müssen.

Wenig gefällig war das Repository für die Entwurfphase, das mit der Entwicklungsanwendung »XML Mediator Studio« über »WebDAV« kommuniziert. Besser wäre eine Lösung, die Standardprotokolle wie UDDI Version 2 oder 3 nutzt – so macht es die Konkurrenz. Problematisch war ferner die fehlende Integration von Gateways in das Repository.

Die Orchestrierung erledigt der Anwender mit XML-Mediator-Studio, einer Standalone-Java-Applikation. Diese soll künftig Eclipse ersetzen. Die Orchestrierung der Dienste war zunächst einfach, wurde aber problematisch, als es Zeit war, eine Transformation zu konfigurieren. Das Produkt besitzt zwar einen Abschnitt für die Transformation, verlangt aber, die XSLT per Hand zu codieren. Außerdem setzt das Produkt ein tiefes Verständnis von X-Path voraus. Der enthaltene X-Path-Editor lässt sich zwar einfach benutzen, ist aber nicht sehr gut integriert.

SAGs Debugging-Werkzeug hingegen ist exzellent und schlägt selbst das von Oracle. Der Anwender kann Werte zur Laufzeit modifizieren und Variable während der Sequenzausführung betrachten. Das verkürzt die Zeit, die beim Debuggen fehlerhafter X-Path-Ausdrücke verloren geht.

Sonic Software SOA Suite 6.1
Sonics SOA-Suite stützt sich so sehr auf Messaging-Technik und -Architektur, dass sie vor allem auf Queueing setzt und sich weniger an einer SOA orientiert. Dafür glänzt Sonic natürlich dort, wo sich Messaging-Erfahrung vorteilhaft nutzen lässt. Die auf J2EE basierende Standalone-Suite besitzt auch entfernbare Teile. Sonic vertraut auf ihren Messaging-Bus »SonicMQ« als Backbone und nutzt Multipart-Nachrichten, die über JMS transportiert werden. Das Management wird wie bei Fiorano über JMX abgewickelt. Aber Sonic versteckt die Komplexität und die Hässlichkeit von JMX viel besser hinter der Schnittstelle als Fiorano.

Die SOA-Suite transformiert alles in Dienste auf dem Bus und routet Nachrichten gemäß Orchestrierung zu Services. Manchmal sind die Beziehungen zwischen Eingangs- und Ausgangspunkten auf dem Bus und die Definition eines Dienstes nur schwer zu verstehen. Nachrichten kommen über eine Einganspunkt rein und gehen über eine Ausgangspunkt wieder raus. Darüber hinaus gibt es keine weiteren Beziehungen. Für JMS ist das in Ordnung, in einer SOA-Welt hingegen merkwürdig.

Um einen auf der Oracle-9.1-Datenbank beruhenden Dienst zu erzeugen, war zuerst eine Verbindung zu definieren. Dann ging es darum, das passende SQL zu schreiben und die Quelle der Parameter zu anzugeben. Bei Sonic ist SQL per Hand zu erstellen.

Daten in einer Orchestrierung zu mappen, verlangt zu viel Domänen-Know-how. Im Test wurde deshalb X-Path bevorzugt, um Werte aus einem eingehenden Dokument zu extrahieren. Dies war so, obwohl die X-Path-Ausdrücke manuell erstellt werden mussten. Sind Dienste erzeugt, kann der Anwender sie in eine Serviceorchestrierung aufnehmen. Dazu wählt er sie einfach im Domänen-Manager aus der Liste der verfügbaren Dienste aus. Die getestete Version enthielt keine Registry-Unterstützung. Sonic sagt aber, in einem der kommenden Releases sei Systinets Business-Service-Registry integriert. »Stylus Studio«, das künftig durch Eclipse-Plug-ins ersetzt werden soll, nutzt Sonic-MQ für die Kommunikation mit dem Message-Broker. Von diesem bezieht es Konfigurationsinformationen sowie verfügbare Dienste und Prozesse. Sonic verlangt vom Anwender, ein auf Inhalten basierendes Routing als separaten Dienst zu konfigurieren und in einem zusätzlichen Schritt der Orchestrierung hinzuzufügen.

dj@networkcomputing.de