Service-orientierte Architekturen: Es beginnt im Kopf

Webservices und Service-orientierte Architekturen (SOA) eröffnen Applikationen einen Kosmos, in dem Integrationsaufgaben lösbar werden. Andererseits ist Integration die Voraussetzung für Vorhaben wie On-Demand- und Utility-Computing sowie für Composite Applications. Doch SOA ist auch eine Denkweise, die top-down in Direktiven umgesetzt werden muss. Entwickler müssen sich an neue Plattformen gewöhnen, die Einteilung nach Betriebssystemen gibt es nicht mehr.
Modell-basierte Tools und Architekturen lösen traditionelle Entwicklungs-Werkzeuge ab, Wiederverwendbarkeit ist mehr als eine Absichtserklärung. Objektorientierung weicht einer Dokumentenorientierung, Schemata statt Klassen werden mehrfach verwendet. Damit Services funktionieren, verlangen Regeln, so genannte Contracts und Policies, Aufmerksamkeit und Sorgfalt.

Mittlerweile gibt es fundierte Erkenntnisse, die bestätigen, dass die Basiskomponenten für ein Webservices-Framework solide funktionieren. Die meisten Bugs sind entfernt, so dass einfache Integrationsaufgaben problemlos zu lösen sind: auf der Sprachebene etwa die Integration von Visual Basic-, C#-, Java-, Java-Script-, Perl- und Cobol-Programmen; auf der Plattformebene die Integration von Unix-, Linux-, Mainframe- und Windows-Systemen. Legacy lässt sich kapseln.

Sicherheit als zentrales Thema

Schwierigkeiten sehen viele Software-Ingenieure noch bei Performance und Skalierbarkeit, Interoperabilität von Produkten, Semantik, Sicherheit, Transaktionsverarbeitung und die Koordinierung beziehungsweise dem Management von Webservice-Infrastrukturen. Doch an Vorstellungen, wie die Unsicherheiten zu lösen sind, mangelt es nicht.

Laut Marc Chanliau, Senior Product Manager bei Netegrity, gibt es derzeit rund 70 verschiedene Standards und Industrie-Spezifikationen zum Thema Webservice-Security. Chanliau war Mitbegründer und erster Vorsitzender des Security Services Technical Committee (SSTC) innerhalb des Industriekonsortiums OASIS (Organization for the Advancement of Structured Information Standards), das die Security Assertion Markup Language (SAML) entwickelt hat.

Bei Netegrity ist er verantwortlich für ein Security Framework, das sich aus den Vorschlägen der verschiedenen Konsortien bedient und den unterschiedlichen Security-Aufgaben zuordnet: Authentifizierung, Identifizierung, Autorisierung und die Verschlüsselung von Nachrichten und Signaturen beispielsweise. Ein solches Framework kann nahezu jedes Sicherheitsbedürfnis abdecken. Das räumt auch Anne Thomas Manes, Analystin der Burton Group, ein, wenngleich die Fachfrau eine Verfechterin der WS-Security-Vorschläge ist, die hauptsächlich von IBM und Microsoft stammen.

Doch ohnehin muss ein Anwender zuerst definieren wie viel und welche Form von Sicherheit er wünscht. Generell gilt, so Chanliau: je mehr Sicherheitsfeatures, um so mehr Overhead und desto langsamer die Prozedur. So muss vielleicht nicht jedes Mal bei Abruf eines Services der gesamte Check durchlaufen werden; es reicht eine Zwischenspeicherung im Cache. Als Quintessenz bleibt, dass Sicherheitsaufgaben lösbar sind. Ein Produkt wie von Netgrity  könne das Handling vereinfachen, zum Beispiel weil Anpassungen und Neuerungen vom Hersteller übernommen werden müssen.

Neue Produkte lösen Grundprobleme

Was die Interoperabilität von Produkten angehe, erläutert Manes, gebe es mittlerweile rund 40 ernsthafte Produkte auf dem Markt, die sich strikt an die Standards hielten und damit interoperable  Web Services ermöglichten. Auch für die anderen Schwierigkeiten sieht sie Lösungen.

So erzeuge XML zwar eine Menge Overhead, was sowohl die Performance eines Netzes beeinträchtigen als auch zu Lasten von Prozessorleistung gehen könne. Allerdings gebe es Beschleuniger, die XML zu HTML transformierten und komprimierten, so dass XML-basierte Verarbeitungsroutinen bis zu 40 Mal kürzere Antwortzeiten aufwiesen und eine bessere System-Performance die Folge sei, so die Fachfrau. Die Transformation von Extensible Style Language Transformation (XSLT) ließe sich um das 20fache verbessern.

Außerdem könnten zumindest zwei Webservice-Plattformen diese Schwierigkeiten beheben: Fabric von Web Methods (ehemals ‘Gaia’ von The Mind Electric) sowie Wasp von Systinet. Für den ehemals tschechischen Anbieter, der nun im amerikanischen Cambridge angesiedelt ist, hat Manes selbst gearbeitet. Gegenüber Apache etwa seien beide Plattformen 30 bis 40 mal schneller. Im Vergleich zu RMI arbeiteten sie doppelt so schnell. Zudem verfügen die Plattformen auch über hilfreiche Security-Features. Somit adressieren diese Plattformen auch noch andere Bedenken von Programmierern und Anwendern, die Zuverlässigkeit und die Handhabung von Webservices.

Doch speziell für diese Bedürfnisse eignen sich Webservice-Management-Produkte, beispielsweise von Amberpoint, Confluent, oder Actional. Sie ermöglichen die zentrale Überwachung und Kontrolle des Webservice-Verkehrs. Zum Beispiel lassen sich Agenten im Proxy unterbringen. System-Management-Konsolen wie Unicenter von Computer Associates oder Tivoli von IBM können die entsprechenden Informationen nutzen.

Großbank implementierte Transaktionsbus

Nach wie vor unvereinbar scheinen Webservices und Transaktionsverarbeitung. Doch die Bank Merrill Lynch hat jetzt auch Transaktionssysteme in seine Webservice-Infrastruktur eingebunden, und zwar über den Transaktionsmonitor CICS von IBM, berichtet Anne Thomas Manes von ihrem “liebsten Anwenderbeispiel”. Vor zwei Jahren stand das Bankhaus vor der Aufgabe, einen CICS-Integrationsbus zu bauen und zwar für ein System mit rund 40.000 CICS/Cobol-Transaktionen auf dem Mainframe. Das Programm selbst wurde nicht angetastet, nur mit Interfaces versehen. Die CICS-Transaktionen erscheinen als Webservice, der Cobol-Code ist mit WSDL-Schnittstellen versehen. Heute laufen rund 30 Applikationen auf dem System. Das entspricht einer Last von zirka 400.000 CICS-Transaktionen.

Die technische Alternative wäre eine Lösung gewesen, die mit Hilfe der Messaging-Software von IBM MQ Series (heute: Websphere MQ) umgesetzt worden wäre. Eine solche Implementation hätte rund 800.000 Dollar gekostet. Für die Webservice-Plattform hat das Finanzunternehmen hingegen bisher 30.000 Dollar ausgegeben. Darin enthalten sind sogar die Entwicklungskosten der Plattform, da es zum Projektstart noch kein marktfähiges vergleichbares Produkt gab.

Die Burton-Group-Expertin Manes sieht im Fall Merill Lynch ein Vorbild für Service-Architekturen, beziehungsweise für den Aufbau einer Network Application Plattform. Der Begriff stammt von ihr. Herz einer solchen Plattform ist ein Bus, der auf Webservice-Standards basiert und über den Webservices miteinander kommunizieren.

Mit Sicherheit werden sich service-orinentierte Architekturen nicht von heute auf morgen verwirklichen lassen. Doch ein Putsch ist auch nicht unbedingt nötig, so die Meinung aller Experten. Soap und XML lassen sich zuerst für einfache Integrationsaufgaben nutzen. Nach und nach gelangen immer mehr Systeme in ein System loser Kopplung, es bildet sich eine Abstraktionsschicht und ein Integrationsbus. “Die Technik ist noch unreif, aber hinreichend funktionsfähig”, sagt Manes und setzt hinzu: “Es ist nie zu früh, durchzustarten.”