Montag, 22. Dezember 2008

Marktanteile von Axis1, Axis2, CXF, JAX-WS RI und XFire

Auf der diesjährigen OIO Konferenz zu Java und XML konnte ich die Teilnehmer meines Vortrags über die eingesetzten SOAP Toolkits befragen. Heraus kam dabei folgendes:






Axis111
Axis26
CXF8
JAX-WS0
XFire0

Das Ergebnis entspricht in etwa meinen Erfahrungen in Projekten und Beratungen. Obwohl es inzwischen überholt ist setzen viele noch Axis1 mit JAX-RPC ein. Trotz dass Axis2 eine komplette Neuentwicklung ist, die mit Axis1 nur den Namen und die Entwickler bei Apache gemeinsam hat, sind viele von Axis1 zu Axis2 gewechselt. Von den Befragten gab nur einer an, CXF mit dem JAX-WS Frontend zu verwenden. Die Übrigen setzen das Aegis Binding ein. Der Anteil der Web Services, die mit JAX-WS realisiert sind ist noch relativ gering. Er dürfte jedoch höher sein, als das Ergebnis in der Befragung. Ich vermute, dass sich einige, die JAX-WS mit CXF oder der Referenzimplementierung einsetzen, meinen Vortrag, der Axis, CXF und die RI verglich, erspart haben. Ich glaube, dass sich die Anteile zugunsten von JAX-WS noch verschieben werden, da die Entwicklung mit JAX-WS recht einfach ist und mit CXF sowie die RI zuverlässige und schnelle Implementierungen verfügbar sind.

Mittwoch, 10. Dezember 2008

JAX-WS mit Axis2

Die JAX-WS Spezifikation ist mittlerweile der Standard für die Web Services Entwicklungen mit Java geworden.
Dazu beigetragen haben die JAX-WS Referenzimplementierung und Apache CXF, welches ebenfalls JAX-WS in der Version 2.1 unterstützt. Seit kurzem bietet auch das Axis 2 Projekt Unterstützung für JAX-WS. Um zu entscheiden, ob wir für ein Projekt Axis2 mit JAX-WS einsetzen können, haben wir der JAX-WS Umsetzung von Axis2 in der Version 1.4.1 auf den Zahn gefühlt. Für den Einstieg befindet sich auf der Axis2 Homepage ein JAX-WS Guide, der JAX-WS und JAXB sowie die Entwicklung von Services beschreibt. Die Axis2 Distribution enthält auch einige Beispiele zu JAX-WS. Allerdings beschränken sich die Beispiele auf einfache Operationen, die nur primitive Datentypen und Strings für die Parameter verwenden. Die Komplexität der Beispiele entspricht daher der Signatur der echo Operation:

public String echo (String msg)

Wird in der Signatur ein komplexer Typ in Form eines Beans verwendet so lässt sich der Service bauen und installieren. Bei der Ausführung wirft Axis allerdings eine Exception, die einen darüber informiert, das Axis2 keinen JAXB Kontext anlegen konnte. Der Bug ist bekannt und steht im Bugtracking System JiRA. Dort findet sich auch ein Patch, der sich allerdings nicht mit der Axis2 1.4.1 Version kombinieren lässt. Es besteht also Hoffnung, dass es bald eine Axis2 1.4.2 Version geben wird, die mit komplexen Typen als Parameter funktioniert.
In Axis2 fehlen Werkzeuge, um aus Code oder WSDL „portable Artefakte“ zu erzeugen. Portable Artefakte sind Java Klassen und Beans, die JAX-WS, JWS und JAXB Annotationen enthalten. Diese Klassen werden von der Runtime für das Serialisieren und Deserialisieren von Nachrichten benötigt. Wer mit Axis2 JAX-WS einsetzen möchte muss daher auf Tools einer anderen Implementierung zugreifen. Man kann beispielsweise die Tools wsgen und wsimport der JAX-WS Referenzimplementierung verwenden. In Java 6 ist diese bereits enthalten, d. h. wer Axis2 in Verbindung mit den Java 6 SDK einsetzt, benötigt nichts weiter. Es stellt sich allerdings die Frage, warum man nicht gleich alles mit JAX-WS Referenzimplementierung macht, wenn man diese auch für Axis2 zumindest zur Compile-Zeit benötigt. Zumal die Referenzimplementierung auch mit komplexen Datentypen zurecht kommt und JAX-WS 2.1 unterstützt. Axis2 unterstützt in der Version 1.4.1 nur einen Bruchteil von JAX-WS 2.0 und JAXB 2.0. Auf der Webseite wird die JAXB Umsetzung von Axis2 als experimentell bezeichnet. Die JAX-WS Umsetzung in Axis2 ist in der Version 1.4.1 daher leider nur für sehr einfache Web Services mit Einschränkungen einsetzbar.
Es besteht allerdings Hoffnung, das Axis2 in einer kommenden Version eine brauchbare JAX-WS bieten wird. Dann steht den Entwicklern eine weitere interessante Alternative für die Entwicklung von Web Services mit Java Standards zur Verfügung.

Montag, 27. Oktober 2008

Genügt das WS-I Basic Profile?

Das Basic Profile der WS-I Organisation regelt die Interoperabilität von Web Services. Ein konformer Web Service müsste folglich ohne Probleme genutzt werden können. Leider beschreibt das Basic Profile nur die SOAP Nachrichten sowie die Beschreibung von Diensten mit WSDL. Welche XML Schema Features eingesetzt werden können wird nicht beantwortet. Ein Service, der Choices, Vererbung, Simple Types, Attribute, Default Werte und Enumerations verwendet kann durchaus konform zum WS-I Basic Profile sein. Mit all diesen Features dürften aber nur wenige Client Bibliotheken in der Lage sein, einen solchen Service aufzurufen. Ich frage mich, welche Features und Buildin Schema Typen ich einsetzen kann, um kompatibel zu bleiben. Klar, für die Java Frameworks von Axis2, CXF und Metro kenn ich die Unterstützung. Web Services sollen aber auch von anderen Sprachen und Plattformen wie PHP, C++ oder Perl nutzbar sein.

Mittwoch, 15. Oktober 2008

Callbacks killed Client/Server

Asynchronität ist eine Voraussetzung für lang laufende Geschäftsprozesse an denen mehrere Organisationen beteiligt sind. Bei vielen Unternehmen sind mehrstufige Client/Server Architekturen im Einsatz. Dieser Artikel zeigt auf, welche Widersprüche bei der Einführung einer SOA durch das Aufeinandertreffen von Mehrschichtenarchitektur und asynchronen Services entstehen.


Client Server


Die Client Server Architektur wird durch folgende Einschränkungen(Constraints) beschrieben:


  • Der Client ist immer der aktive beim Verbindungsaufbau

  • Der Server ist immer der passive beim Verbindungsaufbau


Durch diese Einschränkungen ergibt sich zwangsläufig das synchrone Message Exchange Pattern. Ein typisches C/S Protokoll ist HTTP. Abbildung 1 zeigt den Ablauf einer HTTP Verbindung.



Für C/S Anwendungen wurden in den vergangenen Jahren die Technologien CORBA, Microsoft DCOM und RMI verwendet. Um Client Code für einen Server zu erstellen wird bei diesen Technologien eine Schnittstellenbeschreibung in Form einer Java Schnittstelle oder einer CORBA IDL benötigt. Diese Schnittstellen wurden meist aus dem Servercode abgeleitet. Der Client ist in Folge dessen abhängig vom Server.



Mehrschichten Architektur


Die Client/Server Architektur kann man sogar als eine Folge dieser Abhängigkeiten ansehen. Ferner ergibt sich aus Client/Server und den Abhängigkeiten zwangsläufig die Mehrschichtenarchitektur. Die Dienste, Funktionen bzw. Service Objekte werden dabei so angeordnet, dass eine Schicht immer nur Schichten weiter unten aufruft. Höher gelegene Schichten dürfen nicht aufgerufen werden. Abbildung 3 zeigt eine typische Architektur:



Diese Architektur ist den Software Architekten in den letzten 15 Jahren so ans Herz gewachsen, dass sie diese auch für eine Service orientierte Architektur verwenden. Ein zentraler Punkt bei einer SOA ist die lose Kopplung, die z.B. sich in asynchronen Diensten ausdrückt. Mehrschichtiges Client/Server dagegen ist bedingt durch die Abhängigkeiten und die synchronen Aufrufe nicht gerade lose gekoppelt. Im Gegenteil wir haben hier eine ausgesprochen starke Kopplung.


Asynchronität meets Client/Server


Bei einem asynchronen Aufruf wird das Ergebnis nicht sofort nach dem Aufruf zurückgegeben. Wird das Ergebnis später abgeholt, so spricht man von Polling. Eine andere Möglichkeit ist ein Callback Service. Abbildung 4 zeigt ein Szenario mit Callback.



Als erstes erzeugt der Consumer einen Endpoint, der später die Antwort des Service Provider entgegen nehmen soll. Der Endpoint selbst ist ein Service, der nur temporär zur Verfügung steht. Dann schickt der Consumer seine Nachricht an den Provider über einen OneWay Aufruf. Der Provider nimmt die Nachricht entgegen, schickt aber zunächst keine Antwort. Nach einiger Zeit hat der Provider ein Ergebnis, welches er dem Client mitteilen möchte. Da die Verbindung zwischen Consumer und Provider nicht mehr besteht kann diese für eine Antwort nicht mehr verwendet werden. Da der Consumer mit seinem Aufruf dem Provider eine Callback-Adresse mitgeteilt hat, kann der Provider seine Antwort an diese Adresse schicken. Der Callback Service empfängt die Nachricht und leitet diese an den Consumer weiter. Jetzt kann der Callback Endpoint wieder deaktiviert werden.
Der Consumer ist in diesem Beispiel kein reiner Client im Sinne der Client Server Architektur. Bei der Client Server Architektur ist der Client immer der aktive und der Server der passive. Ein Client öffnet nie einen Port und lauscht nach Verbindungen.


Asynchronität meets Multi-Tier Architecture


Als nächstes betrachten wir, was passiert, wenn wir in einer Mehrschichten Architektur asynchrone Web Services und Callbacks verwenden. Abbildung 5 zeigt wieder unser Beispiel für eine Mehrschichtarchitektur.



Ein Bestellprozess nutzt einen Produktionsservice, um bestellte Waren in Auftrag zu geben. Da die Produktion einige Tage dauert ruft der Prozess eine asynchrone Operation des Produktions-Service auf. Über einen Callback kann der Produktionsservice den Prozess zu einem späteren Zeitpunkt informieren, dass die Produktion fertig ist oder ob es Probleme gibt. Dafür muss der Produktionsservice allerdings den Callback aufrufen, der auf einer höheren Schicht angesiedelt ist. Dies verstößt jedoch gegen die Schichtenarchitektur.


Fazit


Client/Server und Mehrschichten Architektur waren durch die damalige technische Erfordernisse bestimmt. Asynchrone Dienste und die Entkopplung der Abhängigkeit in der Schnittstelle durch eine Service Beschreibung in WSDL stellen heute die Verwendung der Mehrschichtenarchitektur in der SOA in Frage. Gleich berechtigte Dienste müssen nicht mehr in Schichten organisiert werden. Die lose Kopplung wie von der SOA gefordert wird jedoch durch Client/Server und Mehrschichtarchitektur behindert.

Donnerstag, 25. September 2008

Anforderungen an eine SOA Registry

Die folgende Aufzählung stellt meine Wunschliste an eine SOA Registry dar:



  • Integration mit bestehenden Web Services Plattformen und Frameworks

  • Web Frontend zum Suchen

  • Remote Schnittstelle zur Einbindung in andere Systeme

  • XML Export und Import

  • Nicht nur XML Schemas sollte verwaltet werden, sondern auch deren Bestandteile wie z.B. Elemente und Complex Types

  • Informationen zur Wiederverwendung von Elementen und Typen in verschiedenen Diensten

  • Dynamischer Client zum Test von Services

  • Service Lifecycle Management mit selbst definierbaren Statis

  • Anbindung an Monitoring und Management. Ich möchte im Repository sehen, ob ein Service verfügbar ist.

  • Hierarchische Klassifikation und Web 2.0 artige Tags sowie Tagcloud

  • Versionierung von Schnittstellen und Dokumentation der zeitlichen Entwicklung

  • Verwaltung von Abhängigkeiten

  • Verwaltung von Highlevel und konkreten (WS-Policy) Policies und Richtlinien

  • Qualitätssicherung von WSDL und Schema Beschreibungen gegen öffentliche Profile z.B. WS-I Basic Profile als auch gegen interne Guidelines und Styleguides.

SOA Registry Alternativen

Die Registry war ein fester Bestandteil der Web Services Vision lange bevor der Begriff SOA eingeführt wurde. SOAP war das Protokoll, WSDL die Beschreibung und UDDI die Registry. Das Dreamteam SOAP und WSDL hat in den letzten Jahren eine starke Verbreitung erfahren. UDDI konnte sich aufgrund einiger Probleme und Schwächen nicht durchsetzen. Als Folge davon ist die Rolle der Metadata Registry im heutigen SOAs verweist. Abgesehen von einigen UDDI Alibi Installationen, die die Rolle nicht wirklich ausfüllen. Die Zahl der Web Services in den Unternehmen wird langsam unüberschaubar und das Fehlen eines standardisierten Metadata Repository für Services wird zum limitierendem Faktor. Um Informationen über Dienste zu verwalten hat der Anwender heute die folgenden Möglichkeiten:



  • Einsatz einer reinen UDDI Registry. Anbindung aller UDDI konformen Plattformen wie z.B. IBM Websphere. Andere wie Axis bleiben aussen vor oder werden von Hand gepflegt.

  • Einsatz einer proprietären Registry mit UDDI Schnittstelle. Das Datenmodell der Registry ist einer Obermenge des UDDI Modells. Über UDDI kann ein Teil der Funktionalität abgerufen werden. Darüber hinaus gehende Funktionen wie zum Beispiel Service Lifecycle Management stellt eine Insel dar.

  • Verwendung einer non-UDDI Registry, die nicht den Limitationen z.B. dem tModel einer UDDI Registry ausgesetzt ist. Daten aller Services müssen von Hand oder über selbsterstellte Agenten eingepflegt werden.

  • Verzicht auf eine spezialisierte Registry bzw. Metadata Repository. Pflege der Daten über Services in einem anderen System z.B. Wiki oder Datenbank.


Leider füllt keiner dieser Ansätze die verwaiste Registry Lücke komplett auf. Dies ist allerdings kein Grund, die Metadaten zu den eingesetzten Diensten nicht zu verwalten.

Montag, 22. September 2008

Code First Development mit Enunciate

Fabian hat mich auf ein vielversprechendes Tool für Services aufmerksam gemacht. Enunciate kann den Sourcecode einer API in Dienste umwandeln. Alle notwendigen Informationen werden im Code hinterlegt, der zur Überprüfung auch compiliert werden kann. Das Enunciate Tool erzeugt aus dem Code dann eine Web Application und Client Bibliotheken. Die Webapp kann sofort in einen Container der Wahl kopiert werden. Die Web Anwendung stellt dann mehrere Endpoints für SOAP, REST, JSON, GWT-RPC und AMF zur Verfügung. Die Client Bibliotheken werden aus dem Quellcode, nicht aus WSDL erstellt. Dadurch bleibt die javadoc Dokumentation erhalten. Die erzeugten XML Schema Datentypen sollen auch übersichtlicher sein, als aus WSDL generierte Schemas. Clients werden zur Zeit für Java 1.4 und Java 1.5 erzeugt. Geplant sind Module für C++, .NET und PHP Clients. Enunciate ist ein interessantes Tool, das den Aufwand für die Erstellung von Remote Schnittstellen weiter reduzieren dürfte.

Donnerstag, 18. September 2008

Daumenwerte für Web Services Performance

Eine Rahmenbedingung oder ein Constraint für die Architektur von verteilten Systemen ist die Performance für einen einzelnen Aufruf. Um vergleichen zu können verwende ich die Roundtrip Zeit eines lokalen Aufrufs. Vor einigen Jahren mit frühen Axis 1 oder Apache SOAP Versionen betrug diese ca. 100 ms. Letzte Woche haben wir mal wieder die Roundtripzeit gemessen. Für den Aufruf verwenden wir einen Service im Document/Literal Stil, der ein komplexes Objekt mit drei enthaltenen Werten übergeben bekommt. Der Roundtrip benötigte diesmal im Schnittt nur 1,3 ms. Für den Test verwendeten wir Dual Core Desktops mit 2 GHz und Windows Vista Business. Als SOAP Engine kam Apache CXF Version 2.1.2 mit JAX-WS Frontend zum Einsatz. Mit etwas leistungsfähigerer Hardware sind bestimmt auch Zeiten nahe oder unter der Millisekunde möglich. Das entspricht dann 60000 Aufrufen in der Minute. Folglich kann der Overhead für SOAP Web Services meist getrost ignoriert werden.

Dienstag, 9. September 2008

Sollen ESB Dienste mit WSDL beschrieben werden?

Dienste auf einem JBI konformen Enterprise Service Bus lassen sich mit WSDL beschreiben. Für die Beschreibung der Schnittstellen genügt abstraktes WSDL, d.h. ein WSDL Dokument ohne Binding und Service Element. Die Nachrichten auf dem Bus müssen jedoch nicht das SOAP Format verwenden. Mit WSDL lassen sich auch andere Schnittstellen beschreiben. Die Möglichkeit die Schnittstellen der Dienste mit WSDL zu beschreiben wird von den einzelnen ESB Produkten unterschiedlich ausgelegt. Integrationslösungen für den Apache ServiceMix verwenden meist gar keine WSDL Beschreibungen für Dienste, die innerhalb des Buses kommunizieren. Beim OpenESB dagegen muss jede Komponente mit WSDL beschrieben werden. Selbst die Konfiguration, z.B. der File Komponente, erfolgt meist über WSDL Erweiterungen. Ich frage mich was der richtige bzw. sinnvolle Ansatz ist. Für eine Beschreibung mit WSDL spricht die Dokumentation der Endpunkte sowie die Möglichkeit, dass GUI Tools die in WSDL enthaltenen Metadaten auswerten können. Andererseits ist es aufwendig, für jeden Service Endpoint eine WSDL zu erstellen. Viele Dienste sind auch nicht auf eine enge Schnittstelle begrenzt. Eigentlich alle Komponenten, welche die XML Idee aufgreifen. Zum Beispiel ein Splitter der über einen XPath Ausdruck eine Nachricht in mehrere aufsplittet oder ein XSLT Transformer, der ein regelbasiertes Stylesheet verwendet. Richtige regelbasierte Stylesheets verarbeiten nicht nur ein starres Format. XSLT ist dann auch in der Lage zum Zeitpunkt der Entwicklung noch unbekannte Formate zu verarbeiten. Solche flexiblen Stylesheets verwenden anstatt unflexible foreach Konstrukte apply-templates und überlassen den XSLT Prozessor die Wahl des nächsten Schrittes. Gerade diese Flexibilität macht eine Integration mit XML aus. Um diese Flexibilität mit WSDL Beschreibungen zu erreichen, könnten dort die Nachrichten mit xsd:any definiert werden. Das ist aber auch nicht im Sinne einer strikten Schnittstellenbeschreibung. Ich bevorzuge daher WSDL nur für die Schnittstellen des ESB nach außen, also für die Binding Components einzusetzen. Nicht für die Kommunikation zwischen Service Engines.

Donnerstag, 7. August 2008

Auswirkung von Web Service Security auf die Performance

Beim Testen der Fähigkeiten des neuen Netbeans 6.5 MS1stellte sich uns die Frage, welchen Einfluss das Signieren und Verschlüsseln von Web Services mit dem Standard Web Services Security auf die Performance hat.
Zur Klärung der Frage implementierten wir einen einfachen Web Service mit Metro in Netbeans. Der Web Service beinhaltet eine einzelne Methode, die dazu dient Anfragen entgegen zu nehmen ohne diese weiter zu verarbeiten.
Bei unseren ersten Tests lag die Roundtrip-Zeit des ungesicherten Web Service bei ca. 40ms für eine einzelne Anfrage, was bei einem Notebook mit 2.000Mhz CPU mit 2GB RAM entschieden zu lange dauerte. Die Ursache hierfür war der aktivierte HTTP Monitor des Glassfish Servers.
Nach Deaktivierung des Monitors erreichten wir eine Roundtrip-Zeit von unter 4ms für eine einzelne Anfrage, dies entsprach unseren eigentlichen Erwartungen.
Zum Verschlüsseln des Web Service wählten wir die von Netbeans angebotene Methode „Username Authentication with symmetric Key“, die ein X509 Token zur Autehntifizeirung, sowie einen 128 bit Algorithmus zur Verschlüsselung der Übertrageung verwendet. Der Client verschlüsselt den symmetrischen Key mit dem öffentlichen Schlüssel des Service:

encryptedKey=encrypt(publicKeyServer, symKey)

Der Server bekommt den symmetrischen Schlüssel durch das Entschlüsseln mit seinem privaten Schlüssel:

symKey=decrypt(privateKeyServer, encryptedKey)

Die public/private Key Verschlüsselung wird nur für den wenige Bytes großen symmetreischen Schlüssel verwendet. Die Payload der Nachricht wird mit dem symmetrischen Key verschlüsselt, welcher nun beiden Seiten bekannt ist. Bei großen Nachrichten wird durch die schnelle symmetrische Verschlüsselung Zeit und Rechenleistung gespart. Je größer die Nachricht ist, desto mehr kann der Zeitaufwand für das Verschlüsseln vernachlässigt werden. Da es sich in unserem Beispiel um eine sehr kurze Nachricht handelte, hatte das symmetrische Verfahren keinen messbaren Vorteil. Die verschlüsselte Variante des Service stellte daher mit ca. 45ms Roundtrip-Zeit ein erwartet unbefriedigendes Ergebnis dar. Als nächstes wollten wir Testen, ob die Etablierung eines sicheren Kontextes mit WS-SecureConversation zu besseren Ergebnissen führt, da nicht mit jeder Nachricht erneut der symmetrische Schlüssel übertragen und entschlüsselt werden muss.
In Netbeans lässt sich dies sehr einfach durch Setzen eines einzigen Häkchens realisieren.
Das Ergebnis enttäuschte jedoch mit 35ms. Begründet darin, dass immer noch jede Nachricht mit einem private und public Key signiert wird, versuchten wir das Signieren zu deaktivieren. Leider ist es mit Netbeans bisher nicht möglich auf die Signierung der Nachrichten zu verzichten. Auch eine Anpassung der in WSDL eingebettete Policies brachte nichts. Hier bleibt nur die Hoffnung auf Nachbesserung Seitens der Netbeans-Entwickler, da es sich bei dem Web Service Security Standard ja immer noch um eine relativ neue Technologie handelt. Erst dann könnten Roundtrip-Zeiten der Größenordnung von unverschlüsselten Nachrichten erreicht werden.

Dienstag, 29. Juli 2008

Erfahrungen mit BPEL Designer und Engine in Netbeans 6.1

Vor kurzem habe ich die neue 6.1er Version von Netbeans auf ihre Unterstützung für BPEL getestet. Über den BPEL Designer und die BPEL Laufzeitumgebung berichte ich getrennt. Zunächst zum BPEL Designer. Der graphische Designer war in den bisherigen Versionen bereits recht gut. In der Version 6.1 bedient er sich noch etwas besser. Mit Drag & Drop und Cut & Paste lassen sich schnell die Aktivitäten eines Prozesses gruppieren. Für die Feinarbeit wird dann XPath benötigt. Den komfortablen Mapper für das graphische Editieren von XPath Ausdrücken gibt es bereits länger. Neu ist ein Editor für Prädikate, mit dessen Hilfe auch XPath Einsteiger komplexe XPath Ausdrücke meistern können. Der Screenshot zeigt wie ein Prädikat graphisch editiert werden kann.




Danach findet man die durch das Prädikat eingeschränkte Menge im Mapper und kann diese einfach verwenden. BPEL Prozesse lassen dich bereits während der Entwicklung auf Mausklick graphisch debuggen. Der BPEL Debugger bietet alles, was man von Debuggern so kennt:

  • Breakpoints
  • Watches
  • Call Stack

Lässt man nach einem Breakpoint den Debugger mit Resume weiterlaufen, so kann man der Ausführung seines Prozesses zusehen. Das ist dann wie BPEL Television, vorausgesetzt man hat ein paar Services, die die Ausführung etwas bremsen, damit nicht alles zu schnell für das Auge abläuft.



Mit dem BPEL Editor kann man auch die Features Correlation und Compensation in seinen Prozessen verwenden. Ob diese dann in der Engine ausgeführt können beschreibe ich als nächstes.
Die als JBI Komponente realisierte BPEL Engine läuft im Open ESB, der typischerweise wieder in einem Glassfish Application Server ausgeführt wird. Nach der Installation von Netbeans sind die Server bereits alle fertig eingerichtet, so dass man sofort loslegen kann. Das Deployment eines BPEL Prozesses dauert nur Sekunden. Auch die Ausführung eines Prozesses erfolgt zügig in wenigen Millisekunden. Allerdings führt die SOAP Engine nicht alles aus, was man mit dem Designer erstellt hat. Compensation und Correlation funktioniert nur mit den einfachsten Beispielen. Leichte Modifikationen führen zu nichtssagenden Exceptions. Oft reicht die Umstellung der Reihenfolge um Fehler zu verursachen oder zu beheben. Die Unterstützung für die Synchronisation von nebenläufigen Aktivitäten mittels Link fehlt noch immer. Baut man die Links manuell ein, meldet bereits der Editor, dass die Engine keine Links unterstützt. Die Engine beherrscht zwar die forEach Aktivität von BPEL 2.0, nicht jedoch die parallele Ausführung mittels:

<forEach ... parallel="yes">
...
</forEach>

Für den ernsthaften Einsatz fehlt dem Team Netbeans, Open ESB und BPEL Komponente noch die Unterstützung der Correlation, Compensation und Synchronisation. Correlation und Compensation sind ja bereits vorhanden, so dass Hoffnung auf Bugfixes in der nächsten Version besteht.

Mittwoch, 23. Juli 2008

WSS, WS-Trust und WS-SecureConversation mit NetBeans 6.1

Dieser Eintrag beschreibt meine Erfahrungen und Eindrücke mit Standards zur Web Services Sicherheit mit der neuen NetBeans 6.1 Version. Die Unterstützung für den OASIS Standard "Web Services Security" hatte mich bereits bei den NetBeans Versionen 5.0 und 5.5 mit Enterprise Pack, welcher umfangreiche Unterstützung für SOA enthält, begeistert. Zunächst wurde ich aber enttäuscht, da ein Absichern der Kommunikation mit WSS nicht mehr funktionierte. Der Client erzeugte keinen Security Header und der Server wies daraufhin alle Anfragen ab. Nach einiger Reschersche fanden wir den Hinweis, dass man dem Client einige Bibliotheken vom Glasfish Application Server zur Verfügung stellen muss. Dannach funktionierte das Signieren und Verschlüsseln von Nachrichten wieder wie gewohnt. Darüber hinaus wird jetzt WS-SecurityPolicy eingesetzt, um den Initiator einer Anfrage über die erwünschte Art der Absicherung, z.B. Signatur oder Token, zu informieren. Inzwischen bekommt man mit NetBeans 6.1 selbst Projekte mit WS-Trust und WS-SecureConversation ans Laufen.

Mittwoch, 11. Juni 2008

none-UDDI SOA Repository

Endlich ist eine Beta-Version unseres öffentlichen Web Services Repository online. Das Repository
zeigt Metadaten von Web Services und erlaubt das Aufrufen von Operationen über einen generischen SOAP Client.