Die Progress-Tochter Sonic Software hat erst kürzlich eine neue Version ihrer SOA Suite veröffentlicht und darüber hinaus die Übernahme des SOA-Management-Plattform-Anbieters Actional bekannt gegeben. David Chappell, Chief Technology Evangelist und Vice President des Unternehmens, hat sich im Zuge dessen den Fragen des Java Magazins gestellt und ein Unternehmens-Update gegeben.

Java Magazin: Letztes Jahr haben Sonic, AmberPoint und Systinet das SOA-Maturity-Modell vorgestellt. Es identifiziert fünf verschiedene Reife-Level, die eine Organisation im Lauf der Zeit erreichen kann, wenn sie eine SOA aufbaut. Wie ist das Feedback von Ihren Kunden und sehen Sie, dass die Unternehmen das Modell annehmen?
David Chappell: Das Feedback zum SOA-Maturity-Modell ist sehr positiv ausgefallen. Im Vorfeld hatten wir bei Progress/Sonic eine Reihe von SOA-Foren auf der ganzen Welt durchgeführt, mit Gruppen von Architekten, Managern und Projektleitern – ich selbst allein habe mich mit über 4.000 Leuten in mehr als 80 Städten weltweit getroffen –, und wir haben dort alle Dinge diskutiert, die mit der Einführung einer SOA zusammenhängen. Die Anforderungen an das SOA-Maturity-Modell sind aus diesen Foren erwachsen.
Wir glauben, dass das Modell zu einem wichtigen Werkzeug geworden ist, um ein Kommunikationsmittel zwischen unterschiedlichen Gruppen innerhalb einer Organisation zur Verfügung zu stellen, damit die Geschäftsvorteile, die mit dem Erreichen jedes einzelnen Reife-Levels verbunden sind, artikuliert und die notwendige Ausrichtung von IT und Business gewährleistet werden können.

JM: Progress hat eingangs des Jahres mit Actional einen SOA-Management-Plattform-Anbieter erworben. Wie passen die Produkte von Actional in das Sonic-Portfolio?
Chappell: Actionals SOA-Management- und SOA-Governance-Produkte sorgen für die Transparenz, Sicherheit und Kontrolle der Services-Aktivitäten sowie der End-to-End-Geschäftsprozesse in der Laufzeitumgebung. Ohne Anwendungen neu schreiben zu müssen und ohne Performance-Verluste geht Actional über die Geschäftsprozesse, korreliert IT-Metriken mit dem jeweiligen Geschäftskontext und richtet SOA-Operationen wirksam nach Geschäftskriterien aus.
Actional kontrolliert aktuelle Geschäftsprozessverläufe, passt automatisch Änderungen an und deckt auf transparente Weise die Ursachen von Policy-Verletzungen auf. Actional spürt darüber hinaus die Aktivitäten von unkontrollierten, betrügerischen Services auf und räumt dadurch die Security- und Compliance-Risiken einer unerwarteten Nutzung und eines unerwarteten Deployments der Services aus der Welt.
Die Actional-Produktlinie kann nun in Verbindung mit dem Sonic ESB verwendet werden, aber auch mit den ESBs anderer Hersteller oder ohne ESB. Mit der Actional-Plattform wird die Transparenz der End-to-End-Geschäftsprozesse und die Kontrolle über deren Verfügbarkeit gewährleistet, während die Serviceaufrufe eine Reihe von Protokollen und Transportwegen, Plattformen und Anwendungen durchlaufen.

JM: Zur neuesten Sonic-ESB-Version, welche im Frühjahr veröffentlicht worden ist. Was sind für Sie die hervorzuhebenden neuen Features?
Chappell: Sonic ESB 7.0 stellt eine der produktivsten, großflächigsten SOA-Entwicklungsumgebungen zur Verfügung. Es führt erstens neue Eclipse-basierte Tools ein, mit denen man die Konfiguration, das Testen und das Deployment von ESB-Projekten in komplexen, verteilten Umgebungen beschleunigen kann.
Hier ist insbesondere die Sonic Workbench als Bestandteil des ESB zu nennen. Sie ist eine Eclipse-basierte SOA-Entwicklungsumgebung, die Prozesse und Services, die die Produkte der Sonic-ESB-Produktfamilie verwenden, modelliert, konfiguriert, testet und deployt. Mit der grafischen Umgebung ist es einfach, die Geschäftsprozesse zu modellieren und nach und nach Konfigurationen und Deployment-Details zu spezifizieren, wobei sie einen intuitiven Top-down-Ansatz für den SOA-Entwicklungs-Lifecycle unterstützt.
Mit der Workbench können Sonic-ESB-Prozesse und Services schnell lokal konfiguriert und getestet und im Anschluss daran im Netzwerk deployt und einem Debugging unterzogen werden, wobei sie beim Debugging Realtime-Tracking- und zum Step-Through-Tools verwenden.
Einige der Neuerungen der Workbench schließen einen verteilten Prozess-Debugger mit ein, der die Produktivität der Entwickler in komplexen verteilten Deployments dadurch erhöht, dass er einen visuellen Step-through-Debugger für ESB-Prozesse zur Verfügung stellt. Der Debugger wird die verteilten Prozesse selbst dann durchsuchen, wenn die ESB-Services, die durch den Prozess hervorgerufen wurden, nur indirekt deployt werden.
Ein anderes neues Feature ist das integrierte Testen der Services, wodurch schnellere und verlässlichere SOA-Entwicklungs-, Test- und Deployment-Zyklen erlaubt werden. Die Workbench enthält vorgefertigte „Szenarien“, die das Testen individueller Services innerhalb der Workbench-Umgebung zulassen. Die zur Verfügung gestellten Szenarien schließen Web Services Callout, Datenbank-Zugang, XSLT-Transformationen, inhaltsbasierte Router und vieles anderes mehr mit ein. Die Workbench startet automatisch all die ESB-Komponenten, die für den Test des Service-Aufrufs notwendig sind.
Zweitens kommt der neue Sonic ESB mit den ersten stabilen Implementierungen der Web-Services-Standards WS-ReliableMessaging, WS-Addressing, WS-Security und WS-Policy, die für eine verlässliche, sichere und Event-gesteuerte SOA benötigt werden. Als erster ESB, der diese Spezifikationen integriert, vereinfacht er die Entwicklung von serviceorientierten Architekturen auf offene und kompatible Weise.
Etablierte Web-Services-Standards wie SOAP und HTTP stellen allgegenwärtige SOA-geeignete Protokolle zur Verfügung. Jedoch sind sie begrenzt in Hinblick auf die Sicherheit und Betriebsfestigkeit von Enterprise-Anwendungen. Außerdem lässt das synchrone SOAP-/HTTP-Modell nur eingeschränkt SOA-Applikationen zu. Diesen Basisstandards mangelt es an spezifischer Unterstützung für eine asynchrone Interaktion. Deshalb wurden die neuen Web-Services-Spezifikationen ins Spiel gebracht, um Event-gesteuerten Architekturen offener und interoperabler zu nutzen.
WS-ReliableMessaging, WS-Addressing, WS-Security und WS-Policy setzen also hierbei an. Im Verbund sie die Säulen für verlässliche und sichere Web Services im Rahmen von kompatiblen, Event-gesteuerten Architekturen, indem sie aufgrund von offenen Standards die Kommunikation definieren und Features wie asynchrones Antworten und Fehlerbehandlung, Authentifizierung, Unterzeichnung und Verschlüsselung etc. regeln.

JM: Sonic ist auch an dem Apache Synapse-Projekt beteiligt. Um was handelt es sich hierbei? Inwieweit ist Sonic daran beteiligt und was ist der Status des Projekts?
Chappell: Synapse ist Projekt zur Entwicklung eines Mediation Framework, welches innerhalb des Spektrums von ESBs, Web-Services-Management-Plattformen und Web-Services-Anbietern genutzt können werden soll. Synapse ist im Augenblick noch in der Milestone-Release-Phase. Die 0.9-Version ist vorgeschlagen, wurde aber bislang noch nicht weiterverfolgt.
Das Progress/Sonic-Produktteam hat während der gesamten Projektlaufzeit sich mit Input mit Fokus auf die Architektur beteiligt. Das Coding wird hauptsächlich von WS02 betrieben, einer Consulting-Firma, die sich auch stark am Apache Axis-Projekt beteiligt. Wir sind sehr gespannt auf die weiteren Entwicklungen im Synapse-Projekt. Wir schauen aber auch interessiert auf die aktuellen Entwicklungen in Apache Axis2 und haben das Ziel, es als "pluggable" Web Services Stack in der nächsten Generation unserer ESB-Architektur zu verwenden.

JM: Ich bedanke mich für das Gespräch.

Die Fragen stellte Java Magazin-Redakteur Alexander Neumann.