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.