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.