Unternehmensweiter Nahverkehr

Es ist verständlich, dass viele Unternehmen ihre serviceorientierte Architektur (SOA) ausbauen wollen: Die Wendigkeit, die eine SOA der IT und dem Geschäft bietet, verlockt und zahlt sich aus. Die Wiederverwendung von alten Unternehmenslösungen, wenn auch nicht unbedingt des Codes selbst, ist ein oft versprochener Vorteil von EAI (Enterprise-Application-Integration). Dieser ließ sich aber selten umsetzen. Beweglichkeit ist eines dieser Marketingworte, die meistens besser gemieden werden. Hier beschreibt es aber die Möglichkeit, Geschäftsprozesse ohne Codeänderung zu modifizieren. Es verweist auch auf die Fähigkeit, die inneren Abläufe eines Geschäftsprozesses zu ändern, ohne die davon abhängigen Clients und Dienste zu beeinträchtigen. Ein wirklich agiles System erlaubt es beispielsweise, einen Kunden-Suchdienst von einem Cobol-Datenbestand zu einer Oracle-Datenbank zu überführen, ohne dass die Clients davon etwas bemerken.

Versucht ein Unternehmen Änderungen durchzuführen, stellt es fest, dass SOA eine komplexe Angelegenheit ist. Wie bei beim menschlichen Skelett gibt es viele bewegliche Teile, einige davon sind lebenswichtig, auf andere lässt sich notfalls verzichten. Das Ganze ist ein architektonisches Konzept, bei dem viele verschiedene Produkttypen zum Einsatz kommen. Jeder Typ erfüllt seinen Zweck in der Gesamtarchitektur.

Der Aufbau einer soliden SOA-Infrastruktur erfordert einen Enterprise-Service-Bus (ESB). Ist die SOA das Skelett, dann bildet der ESB das Rückgrat. Diese Applikationsinfrastruktur führt ungleiche Dienste zusammen und gewährleistet deren Verfügbarkeit. ESB befähigt dazu, Unternehmenssvorgänge mit Hilfe von Geschäftsprozess-Management-Suites (Business-Process-Management-Suites, BPM) in Prozesse zu verwandeln. Der ESB ist mit allem verbunden und schützt die Informationen, die vom SOA-Gehirn (Registrierung, Repository) zu allen anderen Komponenten fließen. Er bildet die mittlere Ebene eines SOA-Infrastruktur-Stacks: der Klebstoff, der die Prozessabläufe (Orchestrierung) an die Dienste bindet. Aber der ESB ist kein Superkleber: Die Dienste sind nicht sehr eng miteinander verbunden. Dies würde der Agilität zuwiderlaufen. Ein ESB verbindet Dienste locker mit einem Vorgang, der sich entsprechend den Geschäftsanforderungen schnell ändern kann.

Aufgestapelt
Der SOA-Infrastruktur-Stack besteht aus drei Schichten:

• Die Dienste-Bereitstellungs-Schicht (Service-Enablement-Schicht): Applikationen sind oder werden mit Web-Service-Schnittstellen ausgestattet. Konventionelle Enterprise-Application-Integration-Produkte passen hier hinein. Passender aus Sicht der Network Computing sind Produkte von Unternehmen wie IBM, Iona oder Software AG. Diese haben sich darauf spezialisiert, Legacy-Anwendungen mit Web-Service-Schnittstellen zu versehen. Dann lassen sich solche Anwendungen auch in moderneren Architekturen einsetzen. Auf dieser Schicht sind technische Kompetenz und Codiermöglichkeiten gefragt.

• Die Dienste-Anordnungs-Schicht (Service-Orchestration-Schicht): Der ESB ist ein wichtiger Teil dieser Schicht. Er stellt die Verfügbarkeit und das Routing der Dienste sicher. Weiter stellt (orchestriert) der ESB die individuellen Dienste für die Geschäftsvorgänge zusammen, damit sie auf der nächsten Schicht genutzt werden können. Das Repository (oder die Registrierung) befindet sich ebenfalls in dieser Schicht. Auch diese Schicht erfordert technische Kompetenz, Codiererfahrung sollte aber keine Rolle spielen.

• Die Prozess-Anordnungs-Schicht (Process-Orchestration-Schicht): Auf dieser abstrakten Schicht des SOA-Stacks finden BPM und BAM (Business-Activity-Monitoring) ihren Platz. Sie unterstützen die Geschäftsprozesse, die auf den in der Service-Orchestration-Schicht definierten Geschäftsvorgängen aufbauen. Das ist die Schicht, auf der Geschäftsanalytiker mit Diensten kommunizieren und eines Tages diensteorientierte Geschäftsapplikationen (Service-Oriented-Business-Application, Soba) erzeugen können. Diese Schicht sollte nichttechnische, geschäftsorientierte Benutzer unterstützen.

Das sind drei Schichten, die drei Produktsammlungen bedeuten. Einige Hersteller, darunter Oracle und Sonic Software, sagen, dass sie alle drei Schichten in einer einzelnen SOA-Suite kombinierten. Hier gilt es, daran zu denken: Selbst wenn ein einzelnes Paket die gesamte erforderliche Technik enthält, besitzt der Stack noch immer drei unterschiedliche Schichten. Die SOA sollte dies reflektieren, um eine locker verbundene Architektur zu pflegen und die Vorteile einer gut konstruierten SOA zu nutzen.

Der ESB sollte Services für Geschäftsvorgänge zusammenstellen, oder anders gesagt, Verknüpfungen auf niedrigeren Schichten an einen Geschäftszweck binden. Die Abfrage von Kundeninformationen ist beispielsweise ein Geschäftsprozess, der vielleicht aus vielen Diensten niedrigerer Schichten besteht. Diese Dienste kommunizieren wiederum mit mehreren Systemen, um die verlangten Daten einzusammeln, um sie Prozessmanagementsystemen oder Applikationen höherer Schichten zu übergeben.

Einige ESB-Produkte können zwar Geschäftsprozesse zusammenstellen (orchestrieren). Aber den meisten ESB-Suites fehlen Komponenten, die für das Management und die Entwicklung eines BPM-Systems notwendig sind wie Prozessmanagement, Workflow oder BAM. Ein ESB sollte sich darauf konzentrieren, Geschäftsvorgänge als Anwendungskomponenten für Applikationen auf höheren Ebenen bereitzustellen und die Verfügbarkeit dieser Dienste zu gewährleisten.

Auf den Bus springen
Für den Test aktueller ESB-Angebote schickte Network Computing Einladungen an eine lange Liste von Anbietern. BEA Systems, Cape Clear Software, Fiorano Software, IBM, Oracle, Sonic Software, Software AG und Tibco sagten zu. Die Reise mit jeder der ESB-Implementationen führte über kurvenreiche und manchmal ungepflasterte Straßen; sie war ermüdend. Alle acht Produkte führten von A nach B, und alle stolperten in ein paar Schlaglöcher. Mit den Produkten von BEA, Oracle und Tibco verlief die Reise insgesamt recht bequem. Bei Cape Clear, IBM und Sonic Software musste der Reisende gelegentlich zu einem Erfrischungsgetränk greifen, um dann mit dem Codieren zu beginnen. Allerdings war in der Einladung nicht verlangt, dass es ohne Codierung gehen muss – nachträglich betrachtet ein Fehler.

Webmethods und Sun antworteten positiv, bogen aber irgendwo vorher falsch ab: Von keinem der Hersteller kam ein Produkt. PolarLake fiel einer internen Fehlkommunikation zum Opfer und musste absagen. Microsoft antwortete überhaupt nicht. Iona besuchte die Real-World Labs. Aber nach dem Test der Version 3.0.3 ihres Artix-Produkts war klar, dass es die Testanforderungen nicht erfüllte. Die mittlerweile verfügbare Version 4 erfüllt diese wohl.

Getestet wurden primär die Kern-Funktionen der ESB-Produkte: Routingfähigkeiten, Transformationen und Mapping, Protokollunterstützung, Orchestrierungsmechanismen oder konventionelle Managementeinrichtungen. Im Blickfeld war auch, wie gut die Produkte konventionelle Integrationsfunktionen für allgemeine Enterprise-Aufgaben wie Datenbankinteraktionen durchführen. In einer reinen SOA-Welt würden Web-Services solche Integrationen erledigen. Aber einige Situationen und Performanceüberlegungen verlangen, dass die Dienste-Orchestrierungs- Schicht dies übernimmt.

In dem Test ging es darum, mit Hilfe der Produkte einen Service zur Verarbeitung eines Kaufauftrags zusammenzustellen. Der Service musste mit der Oracle-9i-Datenbank der Network Computing zusammenarbeiten und eine JMS-Queue (Java-Messaging-Service) bedienen. Weiter ging es darum, als Web-Service-Konsument zu agieren und eine einfache E-Mail-Benachrichtigung an den Kunden senden. Der ESB hatte die Daten bei der Übergabe (Publish) in die Queue und beim Erzeugen der E-Mail-Benachrichtigung zu transformieren. Über Routing anhand der Daten in der Nachricht musste dann der ESB entscheiden, ob er die Nachricht an die JMS-Queue übergibt.

Unter der Haube
Architektonische, besonders das Routing und Management betreffende Unterschiede der Produkte beeinflussten den Test. Es gibt keine Standardarchitektur, keinen Standardtransportmechanismus auf dem Bus oder Standards für die Implementierung von Web-Services. Alle diese Entscheidungen trifft der Hersteller – und es gibt offenbar keine zwei Hersteller, die dasselbe denken.

Technisch gesehen sind Sonic Softwares SOA-Suite 6.1« und BEAs »Aqualogic-Service-Bus 2.1« J2EE-Applikationen (Java-2-Enterprise-Edition). Dennoch lassen sich beide ausschließlich auf den Plattformen betreiben, für die sie ausgeliefert werden. Sonics Suite verlangt dagegen nur ein JDK (Java-Development-Kit) und bringt gleich das JDK 1.4 von IBM mit. BEAs ESB installiert sich automatisch in einen leichtgewichtigen Weblogic-Server-Container (WLS). Um die WLS-Instanz zu verwalten, war im Test nur ein Zugriff notwendig: Hinzufügen einer Verbindung zur der entfernten »OpenJMS«-Queue.

Oracles »SOA-Suite« und Cape Clears »ESB 6.5« waren ein bisschen schwach beim Enterprise-Services-Plattform-Management. Beide Produkte nutzen aber vorhandene Server und unterstützen die Einrichtung in verschiedenen J2EE-Containern einschließlich BEA-Weblogic, IBM-Websphere oder Oracle-AS.

Interessanteweise benötigen ESB-Produkte, die aus konventionellem EAI-Bereich kommen, einen externen Dienst für die Web-Services-Unterstützung. Das ist unter anderem der Fall bei den Angeboten von Tibco und Fiorano. Zwar nutzen auch die Produkte von BEA und Oracle externe Container für Web-Services. Beide haben aber den Prozess so gut implementiert, dass er Administratoren und Entwicklern transparent erscheint. Bei Fioranos »SOA-2006-Platform 3.7« und Tibcos »Businessworks 5.3« hingegen ist schmerzhaft deutlich, dass der Web-Services-Container nur ein Anhängsel des Kern-ESBs ist. Fiorano verwendet Tomcat/Axis als Container. Dienste mit einem Web-Service-Endpunkt müssen spezifisch als solche eingeführt werden, separat vom zusammengestellten Dienst. Um Tomcat ans Laufen zu bekommen, war außerdem der Download von Suns JDK 1.5 notwendig. Falls ein JDK erforderlich ist, sollte es besser gleich mit dem Produkt ausgeliefert werden. Tibcos Lösung für Web-Services gleicht der von Fiorano, aber der Einrichtungsprozess ist ein wenig flüssiger und benötigt kaum externe Produkte.

Software AGs Enterprise-Service-Integrator nutzt »JBoss«, kann aber auch auf anderen Enterprise-Services-Plattformen arbeiten. Die Web-Services-Unterstützung entspricht großenteils der von Tibco. Eine Ausnahme ist, dass mit der Web-Administrationskonsole ein »Portal« zu definieren ist. Dieses Portal ist an eine bestimmte Konfiguration der Reihenfolge (Orchestration) gebunden. Dabei stellt das Portal einen Einstiegspunkt dar, der auf einem Protokoll wie Soap (Simple-Object-Access-Protcol) oder JMS (Java-Messaging-Service) beruht. Wie bei Sonics Produkt ist die Grenze zwischen Entwicklung und Administration nicht ganz klar erkennbar.

IBMs »Websphere-Message-Broker 6.0« ist insofern einmalig, als dass innerhalb der Orchestrierung lediglich eine URI zu definieren ist. Dann lassen sich mit Hilfe des Message-Brokers Web-Services-Anfragen abhören und verarbeiten. IBM unterscheidet nicht zwischen Soap- und HTTP-Listener, sondern bestimmt stattdessen, ob eine Anfrage, die über einen HTTP-Port hereinkommt, Soap oder XML ist. Dieser Ansatz ist interessant, da sich so eine Soap-Nachricht mit wenig Aufwand sowohl über HTTP als auch MQ (Message-Queueing) verarbeiten lässt.

Nach IBM war die Konfiguration von Sonics SOA-Suite 6.1 wie ein Schritt in ein anderes Universum. Alles basiert auf JMS, und End- sowie Ausgangspunkte sind für jeden Dienst einschließlich Web-Services nötig. Endpunkte konfiguriert der Benutzer in der Fat-Client-Management-Konsole. Anschließend setzt der Administrator schrittweise die Endpunkte als Eigenschaften innerhalb einer Orchestrierung in der Entwicklungsumgebung.

Die Knochen von Soap verbinden
Ein Hauptthema bei der Auswahl eines ESB sind die unterstützten Protokolle. Bei den Inbound-Protokollen gibt es einige Unterschiede zwischen den Produkten. Jedes Produkt beherrscht HTTP und JMS. Dann hören die Gemeinsamkeiten aber auch schon auf. Beispielsweise ließ sich nicht in jedem Produkt die Verarbeitung von eingehenden FTP- oder SMTP-Anfragen leicht implementieren. Fehlende FTP-Unterstützung kann problematisch sein, denn FTP ist für viele Geschäftstransaktionen noch immer das Haupttransportmittel.

Noch beunruhigender ist die fehlende Unterstützung einiger anderer populärer Protokolle innerhalb einer Orchestrierung. JMS und HTTP sind durchgängig mit dabei. Aber es fehlt SMTP ebenso häufig auf der Liste der Kommunikationsmechanismen (IBM und Cape Clear) wie die Unterstützung einfacher Abfragen gegenüber einem RDBMS (Cape Clear, BEA, IBM). In den drei zuletzt genannten Fällen war es notwendig, für den Zugriff auf die Oracle-9i-Datenbank Code zu schreiben. Dieser war dann als Service einzurichten, bevor er in die Orchestrierung aufgenommen werden konnte.

IBMs Lösung zur Unterstützung von RDBMSs enthält proprietäre Compute-Knoten, die eine Codierung in Java oder ESQL (Extended-SQL) erfordern. Sonics Produkt benötigte Javascript-Code, um irgendeine Art von Routing anhand von Nachrichtendaten innerhalb einer Orchestrierung durchzuführen. Zu bevorzugen ist die auf Xpath basierende Methode der anderen getesteten Produkte.

Sonic bietet vielfältige Protokollunterstützung, sofern der Anwender die Protokollanforderungen in eine JMS-Welt übersetzen kann. Alle Protokolle sind in Services umzuwandeln, was ja bei einer Service-Orchestrierung nichts Ungewöhnliches ist. Aber sämtliche Protokollunterstützung muss aus JMS-ähnlichen Eingangs- und Ausgangspunkten bestehen, und das ist manchmal verwirrend und schwierig zu konfigurieren.

Die unterschiedliche Unterstützung von Protokollen innerhalb der Service-Orchestrierung liegt dicht im Zentrum der Kontroverse, was einen ESB zu einem ESB macht. Die eine Seite sagt, dass der ESB die natürliche Evolution von EAI sei und damit in der Lage sein müsse, mehr als lediglich Web-Services zu integrieren. Er muss also mehr als Soap über JMS und HTTP beherrschen. Die andere Seite argumentiert, der ESB sei eine neue Schöpfung. Diese diene zwar einem der Integration ähnlichen Zweck. Aber der ESB sei auf einer höheren Schicht des SOA-Stacks angesiedelt als eine reine Integrationstechnik.

Die Wahrheit liegt wohl in der Mitte. Network Computing stimmt zwar zu, dass die Integration von alter Technik wie »CICS«, Cobol oder »CORBA« auf der Dienste-Befähigungs-Schicht erfolgen sollte. Einige Integrationsaufgaben sind jedoch so, dass sie besser auf der Dienste-Orchestrierungs-Schicht aufgehoben sind. Beispielsweise sollte ein Datenbankzugriff keine Codierung erfordern -- abgesehen vom SQL für die Abfrage. Ein Datenbankzugriff muss nicht noch zusätzlich zur Performance reduzierenden JDBC-Verbindung auch noch einen Overhead mit sich herumschleppen, um servicefähig zu sein. Verwenden Enterprise-Applikationen anwendungsspezifische Datenbanken oder spezielle API-Aufrufe wie für Peoplesoft, SAP oder Siebel, sollten sie nicht auf der Dienste-Bereitstellungs-Schicht angesiedelt sein. Solche Verbindungsfunktionen sind oder werden bald üblich sein. Sie sollten daher leicht den Weg in Enterprise-Anwendungen finden, deren Aufgabe es ist, zu kommunizieren und Services miteinander in Beziehung zu setzen. Die Bewertung der Adapterunterstützung in der Integrationskategorie dieses Tests reflektiert diese Ansicht.

Einen Plan zeichnen
Transformation und Mapping sind wichtige Funktionen eines ESB. Da Daten in einem bestimmten Format eintreffen, muss der ESB sie transformieren, bevor er sie an andere Systeme weiterleitet. Das erfordert, die Felder eines Dokuments denen eines anderen Dokuments zuzuordnen. Der von den Produkten dafür verwendete Mechanismus variiert. Fiorano nutzt beispielsweise ein sehr elegantes visuelles Mapping-Werkzeug, IBM einen vielstufigen Prozess.

Fioranos und Oracles visuelle Werkzeuge sind prima. Felder und XSLT-Funktionen per Drag-and-Drop zu verarbeiten, um sowohl einfache als auch komplexe Transformationen zu konstruieren, ist ein großes Plus. BEAs Drag-and-Drop-Schnittstelle ist ebenfalls gut, setzt aber ein gewisses Verständnis von Xquery/Xpath voraus, das auf der Dienste-Orchestrierungs-Schicht nicht notwendig sein sollte. Tibcos Businessworks verlässt sich wie die meisten anderen Produkte auf Xpath und konstruiert den Xpath für den Benutzer. Businessworks setzt aber im Gegensatz zu Aqualogic kein Verständnis von Xpath voraus, und das ist viel besser.

IBMs Setup verlangt, die geeigneten Schemata zu importieren und dann mit Hilfe eines visuellen Mechanismus einen Zuordnungsplan zu erstellen. Anschließend erstellt das System anhand des Plans eine XSLT-Vorlage, die sich dann in der Orchestrierung verwenden lässt. IBM kennt zwei Formate für Daten: Protokoll und Intern (Wire). Letzteres beschreibt die Daten, wie sie intern durch den Bus laufen. Im Protokollformat kommen die Daten herein und verlassen den ESB wieder. IBMs Flexibilität ist hier beeindruckend, und nützlich, die Fähigkeit, zwischen internem und Protokollformat zu unterscheiden. Für allgemeinere Szenerien wie XML-zu-XML-Mappings ist aber etwas weniger Komplexes wünschenswert.

Software AG muss noch etwas tun. Mit dem Service-Integrator musste das XSLT-Stylesheet von Grund auf gebaut werden. Zwar besitzt das Produkt einen Xpath-Expression-Builder. Dieser lässt sich von fast allen Stellen aufrufen, die Xpath erfordern – aber eben nicht von allen. Das verlangte mehr als einmal Kopieren-Ausschneiden-Aktionen, um die gewünschten Xpath-Ausdrucke zu bekommen. Der Service-Integrator ist Sonics Stylus-Studio trotzdem um Lichtjahre voraus. Stylus-Studio verlangt ebenfalls, Xpath-Ausdrucke von Grund auf zu schreiben. Alternativ gab es eine Kopieren-Ausschneiden-Routine innerhalb einer hierarchischen Baumstrukturansicht für das Dokument, welches gerade in Bearbeitung war. Beispielsweise war es notwendig, eine Xpath-Abfrage zu erstellen, um den »PROD_NO«-Wert des eingehenden XML-Dokument dem entsprechenden Datenbankparameter zuzuordnen. Anschließend ging es darum, alle erforderlichen Namensbereiche (Name-Spaces) dem Schritt in der Orchestrierung hinzuzufügen.

Nun dirigiere, Maestro
Die Orchestrierung und das Service-Management gehören zum Herzen des ESB-Managements. Entwickler müssen die Services nicht nur zusammenstellen, sondern sie auch debuggen und testen. Administratoren haben dann die Aufgabe, diese Services zu verwalten. Im Test hatte keines der Produkte ein Problem mit der Orchestrierung. Frustrierend waren lediglich IBMs komplexe Modellierungsfunktionen. Bunt gemischt waren jedoch die Resultate beim Debuggen und Testen der zusammengestellten Services.

Die in den meisten Produkten eingebauten Fähigkeiten zum Debugging der Service-Orchestrierung waren beeindruckend. BEAs Testwerkzeug bietet viele Optionen und eine detaillierte Verfolgung jedes einzelnen Schritts in der Orchestrierung und beim Blick in die Daten. Hier schlüsselte das System direkt vom Browser aus nach Header und Nutzdaten auf. Oracles Testwerkzeug arbeitete wie das von BEA mit dem Browser und lieferte noch mehr Details. Dazu gehörten Ausführungszeiten auf Basis der Orchestrierungsschritte. Die Debugging-Möglichkeiten von Tibcos Businessworks sind exzellent.

Software AG liefert mit ihrem XML-Mediator-Studio einen Debugger. Dieser erlaubt es, Breakpoints zu setzen oder sogar Werte in den Dokumenten zu verändern, während diese durch die Orchestrierung wandern. Zur Verfügung steht außerdem eine Testoberfläche, um Web-Services auszuführen. Trotzdem ist das Angebot der Software AG nicht so beeindruckend wie das von BEA. Fioranos Testeinrichtungen erlaubten es, Nachrichten zu senden und zu empfangen, aber die Schritte dazwischen sind nicht einsehbar. Aber das ist immer noch besser als gar nichts, und gar nichts ist das, was die meisten anderen Produkte bieten.

Cape Clears Orchestration-Manager zeigt ebenfalls die Ausführungszeiten pro Schritt an. Aber es gibt keine Möglichkeit, die Nachricht anzuschauen, während das System diese Schritt für Schritt weiterreicht. Aber bei Oracle und BEA ist dies anders. Zu beachten ist, dass deren Testwerkzeuge und Debugger die Nachricht an jedem eingestellten Breakpoint stoppen und so direkt Analysen und Modifikationen erlauben.

Tibcos Businessworks zeigt Details für viele Ausführungen und Ausführungszeiten, aber leider nur auf der Prozessebene. Das bedeutet, dass der Administrator genauer in die Prozesse hineinschauen muss, um herauszufinden, wie oft die JDBC-Query ausgeführt wurde und wie lang die durchschnittliche Ausführungszeit war. Als die JDBC-Abfrage innerhalb der Orchestrierung von einem anderen Prozess aufgerufen wurde, gab es keine Betrachtungsfunktionen, die es erlaubt hätte von der äußeren zu inneren Orchestrierung zu kommen. Die Aufmerksamkeit, die Details geschenkt wird, ist aber in Ordnung.

Die anderen getesteten Produkte bieten schlicht keinen Mechanismus zur Anzeige von Details zur Service-Zusammenstellung. Nur Oracle und Tibco erlauben, lang andauernde oder fehlerhafte Orchestrierungen zu beenden. Cape Clear bietet wenigstens während der Einrichtung dazu eine Option. Diese bestimmt, wie der Server bei zu lang andauernden oder fehlerhaften Orchestrierungen reagiert: Löschen oder ein Recovery versuchen. Alle Produkte benötigen ein wenig mehr Kontrolle über die Service-Orchestrierung auf Server-Ebene.

Geschwindigkeitsbeschränkungen
Die Reise über den Enterprise-Service-Bus begann mit der Absicht, die Performance der Szenerie der existierenden NWC-Infrastruktur zu testen. Gegen Ende des Trips war klar, dass sich der ESB-Markt generell auf die Protokolle und Standards geeinigt hat, die ein ESB unterstützen muss. Aber es gibt zwei Ausnahmen: JDBC und SMTP. Viele Suites unterstützen beides, aber einige erfordern die Entwicklung von Compute-Knoten (IBM) oder Java-Web-Services (BEA und Cape Clear). Nach vielen Versuchen war klar, dass Network Computing die Performancetests als Bewertungskriterium herausnehmen musste. Es war nicht wirklich möglich, Äpfel mit Äpfeln zu vergleichen.

Die Produkte, bei denen sich Performancetests durchführen ließen, zeigten, dass in jedem Fall viel Tuning nötig ist. JVM-Speichernutzung (Java-Virtual-Machine), die Anzahl der für HTTP erlaubten Verbindungen oder der Code, der einen Service implementiert: All diese Faktoren beeinflussen die Gesamtperformance. Außerdem ist die Fähigkeit, In-Memory-Calls zwischen orchestrierten Services auszuführen, unbedingt erforderlich. Das gilt besonders dann, wenn die Orchestrierung Soap über HTTP verwendet. Den Overhead einer TCP-Sitzung zu entfernen, wenn Services auf ein und derselben Maschine ablaufen, beeinflusst die Performance positiv. Diese Verfügbarkeit dieser Option sollte also geprüft werden.

Die Ausführung komplexer Style-Sheets sowie Ver- und Entschlüsselung beeinflussen die Performance ebenfalls. Transformationen schnell und effizient ausführen zu können, hat direkten Einfluss auf die Schnelligkeit eines jeden ESB. Auch die Wahl des XML-Parsers hat einen Einfluss. Hinzu kommen eventuelle Beschränkungen bei der Größe der XML-Dokumente, die der Parser verarbeiten kann. Aus diesem Grund wurde jeder Hersteller gefragt, ob sich XML-Parser und XSLT-Engine austauschen lassen oder die Lösung mit externer Hardware zusammenarbeite.

BEA fährt den Bus
Am Ende der Reise erhielt BEAs Aqualogic-Service-Bus die Auszeichnung »Referenz« der Network Computing. Knapp hinter BEA auf dem zweiten Platz landete Oracle, gehindert durch eine große Lücke im Preisgefüge. Aqualogic-Service-Bus fehlt die Integration von Oracles SOA-Suite. Aber BEA macht dies wett durch eine exzellente Orchestrierungsoberfläche sowie elegante Monitoring- und Berichtsfeatures.

Tibcos Businessworks fiel nicht weit hinter die Spitzenreiter zurück. Gebremst wurde dieses Produkt primär von seinem Management und seinen weniger eleganten Transformations- und Mapping-Fähigkeiten. Businessworks erzielte mehrmals deutlich höhere Punktzahlen als Fioranos SOA-2006-Platform und Cape Clears ESB.

Eine individuelle Besprechung der getesteten Produkte lesen Sie in einer der folgenden Ausgaben der Network Computing.
dj@networkcomputing.de