Vortrag WS-Standards mit Metro

Ich war enttäuscht als ich meinen Vortrag zum Web Service Stack Metro auf der letzten OIO Hauskonferenz begann. Nur 8 Teilnehmer, so wenig hatte ich noch nie. Der Track im anderen Raum hatte diesmal einen Großteil der Teilnehmer abbekommen. Okay „Effektives Testen für agile Teams“ ist ein gutes Thema und Steffen Schluff und Björn Feustel sind zwei hervorragende Referenten. Aber so wenige Teilnehmer ist echt bitter. Bevor ich mit dem Vortrag anfing wollte ich erst wie im letzten Jahr wissen, welche Web Services Stacks die Teilnehmer einsetzen.
Das Ergebnis war:

Axis1 1
Axis2 4
CXF 1
JAX-WS RI bzw. Metro 0

Schon wieder eine Enttäuschung. Ich weiß, dass Axis2 den größten Marktanteil an den SOAP Toolkits besitzt. Aber dass so wenige Metro einsetzen hätte ich nicht gedacht. Wenigstens sind einige von Axis1 auf Axis2 umgestiegen. Vielleicht liegt es ja an der geringen Verbreitung von Metro, dass mein Vortrag so wenige Teilnehmer anzog. Mit dieser Erklärung kann wenigstens mein Ego leben.
Die zweite Hälfte meines Vortrages bestand aus einer Lifedemo. In der Demo wollte ich erst einen Web Service und einen Client mit Netbeans erstellen. Anschließend sollte der Service mit WS-Reliable Messaging gesichert werden. Dabei wollte ich die Konfiguration über WS-Policy vorstellen und zeigen, wie komfortabel dies mit Netbeans 6.8 geht und die darin enthaltene Metro 2.0 Version kurz vorgestellen. Normalerweise überziehe ich jeden Vortrag, aber dieses Mal war ich mit der Demo fertig und hatte noch 15 Minuten übrig. In der Zeit konnte ich den Service noch zusätzlich mit WS-Security absichern und zeigen wie Nachrichten mit UsernameToken, Verschlüsselung und Signatur gesichert werden. Netbeans bietet eine gute Unterstützung für Metro, nur so ließ sich in 30 Minuten so viel vorführen. Nach dem Vortrag bekam ich Feedback von einigen Teilnehmern, dass Sie beeindruckt davon sind, wie einfach selbst so komplexe Dinge wie Web Services Security mit Netbeans und Metro zu realisieren sind und dass Sie überlegen auf Metro umzusteigen.
Es bleibt also noch Hoffnung, dass Metro die Verbreitung findet, die es verdient.

.NET 4 – Neues in WCF

Obwohl ich überzeugter Java Jünger bin blicke ich von Zeit zu Zeit zu Microsofts .NET. Ganz sicher werde ich in meinem Alter nicht zu C# oder Visual Basic wechseln. Mein Blick gilt vielmehr den Innovationen rund um das frühzeitige Erkennen von Trends, die in die Java und Web Services Welt überschwappen könnten. Mit .NET 4 kommen auch zahlreiche Neuerungen im WCF. In diesem Post werde ich nur Neuerungen beschreiben, die auch für nicht .NET Entwickler interessant sind.
Zur Familie der WS-*Standards kommt in .NET Version 4 WS-Discovery hinzu. Über WS-Discovery können Services Endpoints bekannt machen und Clients können gezielt nach Services Adressen suchen. In lokalen Netzen kann für Suche und Bekanntmachungen die Multicast Funktionalität von UDP verwendet werden. Zwischen verschiedenen Netzwerken kann mittels SOAP ein Discovery Proxy befragt werden.
WS-Discovery enthält einiges was ich mir vor fast einem Jahrzehnt von UDDI versprochen habe. Beispielsweise eine einfache API für die Suche nach Adressen über Kriterien. Hoffentlich zieht Sun bzw. Oracle bald nach und bietet .NET Kompatibilität im Metro Stack an. Damit wäre dann WS-Discovery auch für Java verfügbar.
Neu in WCF ist auch der Routing Service. Über eine Basisklasse lassen sich mit nur wenigen Zeilen Code und etwas Konfiguration verschiedenste Routing Aufgaben lösen, für die wir in der Java Welt oft komplexeste ESB Produkte einsetzen. So unterstützt der Routing Service alle von WCF unterstützten Protokolle und Message Exchange Patterns. Werden mehrere Protokolle verwendet, so arbeitet der Router als Protocol Bridge z. B. zwischen SOAP und UDP. Über Filter können die Enterprise Integration Patterns Recipient List und Content Based Router realisiert werden. Selbst Load Balancing ist mittels alternativer Endpunkte leicht zu realisieren.
Einige Features für REST Services wurden in .NET 4 aus dem WCF REST Starter Kit übernommen. Praktisch finde ich die Automatic Help Page, die für installierte REST Services erzeugt wird. Über Sie bekommt man Informationen über die unterstützten HTTP Methoden oder Nachrichtenformate wie z.B. XML, JSON usw.. Aufgerufen wird die Help Page durch das Anhängen von help an eine REST Endpoint URL. Für XML Nachrichten wird ein XML Template sowie ein XML Schema erzeugt, aus dem der Aufbau über Nachricht ersichtlich wird. Um Caching in Verbindung mit REST zu erleichtern, erzeugt .NET aus der Angabe eines Profils automatisch die passenden HTTP Header.
Der „BPEL Killer“ Workflow Services, der bereits in .NET 3.5 enthalten war, wurde in .NET 4 um weitere Features ergänzt. Die Workflows sind für langlaufende Prozesse gedacht, bei denen auf externe Ereignisse gewartet werden muss. Mit den Visual Studio 2010 Designer können Workflows grafisch erstellt und als XAML Dateien abgespeichert werden. Ein Workflow wird wie ein BPEL Prozess aus Aktivitäten zusammengebaut. Die Namen der Aktivitäten wie zum Beispiel Receive, SendReply und Sequence ähneln denen von BPEL. Auch der von BPEL bekannte Correlation Mechanismus steht dem Entwickler zur Verfügung. Die in der BPEL Entwicklung lästigen Partnerlinks und PartnerLinkTypes fehlen allerdings. Dafür arbeitet man direkt mit Endpoints. Die Entwicklung mit Microsofts Workflow Services sieht so einfach aus, wie man das vergeblich von BPEL erwartet hatte. Eine Persistierung der wartenden Prozesse in eine Datenbank ist selbstverständlich möglich. Besonders die Verbindung von Web Services, Workflows und XAML Oberflächen für die Human Interactions lassen mich in Microsoft Workflow einen BPEL Killer sehen. Ich hoffe, dass die Workflow Services eine Vereinfachung bei der nächsten BPEL Version bewirken.
Mit .NET bleibt Microsoft weiterhin der Schrittmacher in der Web Services Welt. Der Java Welt bleibt nichts anderes übrig als zu folgen.

Open Source SOA Monitoring/Governance

Unsere beiden open source Werkzeuge Membrane SOA Monitor und Membrane SOA Registry haben unter http://www.membrane-soa.org/ ein neues Zuhause gefunden.

X-Forwarded-For oder Woher kommst Du?

Das Forwarding von HTTP Anfragen aus dem Internet über die DMZ erledigt der Membrane Monitor jetzt problemlos. Das letzte Problem war, dass unsere logfiles alle so aussahen:

127.0.0.1 - - [30/Jul/2009:09:47:27 +0000] "GET /open-source/soap-monitor-howto.htm HTTP/1.1" 200 3178
127.0.0.1 - - [30/Jul/2009:09:47:31 +0000] "GET /open-source/jaxws-client-monitor-howto.htm HTTP/1.1" 200 3968
127.0.0.1 - - [30/Jul/2009:09:47:32 +0000] "GET /membrane-add-rule.png HTTP/1.1" 200 27561
127.0.0.1 - - [30/Jul/2009:09:47:34 +0000] "GET /open-source/ HTTP/1.1" 200 2822
127.0.0.1 - - [30/Jul/2009:09:47:36 +0000] "GET /open-source/soa-registry-repository/ HTTP/1.1" 200 4981

Anstatt der IP Adresse des Rechners auf dem der Browser läuft wird die IP Adresse des reverse Proxy abgespeichert. Für das Durchschleusen der IP Adresse des ursprünglichen Clients haben die Entwickler des Squid caching Proxy Servers das HTTP Header Feld X-Forwarded-For eingeführt. Dabei handelt es sich nicht um einen richtigen Standard sondern nur um einen Defacto Standard, der aber ganz gut akzeptiert ist. Ab der Version 0.9.3 ergänzt Membrane Monitor jetzt weitergeleitete HTTP Anfragen um dieses Feld. Damit Tomcat das Feld in eine Accesslog Datei schreibt mussten wir noch die Konfiguration für das AccessLogValve ändern. Damit die IP Adresse des Clients mit dem Wert von X-Forwarded-For ausgetauscht wird haben wir das Log Pattern combinded mit einzelnen Werten nachgebaut.

<Context>
<Valve className="org.apache.catalina.valves.AccessLogValve"
prefix="praxis-godesberg.de." suffix=".txt"
pattern='%{x-forwarded-for}i %l %u %t "%r" %s %b "%{referer}i" "%{user-agent}i"'/>
</Context>


Jetzt steht dem Betrieb mehrerer Web Server an einer festen IP nichts mehr im Weg. Zeit einen neuen Server zu bestellen :-) .

Java Reverse Proxy

Der Prototyp des Java reverse Proxy für den Betrieb mehrere Server an einer festen IP-Adresse hatte zunächst noch ein wenig Performance Probleme. Nach einer Umstellung auf ein lazy on demand Lesen der Nachrichten gibt es durch den Proxy keine messbaren Verzögerungen mehr. Es kommt was über die Leitung geht. Lokal sind sogar ca. 5 MByte pro Sekunde möglich. Schade wir wollten eigentlich mal das Java NIO API ausprobieren. Nachdem die Performance absolut ok ist haben wir festgestellt, dass in den Logfiles jetzt immer 127.0.0.1 steht. Wir würden aber gerne wissen von wo unsere Seiten abgerufen werden. Für die Weitergabe der Requestor Adresse gibt es das X-Forwarded-For http Header Feld. Mal sehen. Ob das Feld von unserem Tomcat aus gelesen wird.

Mehrere IP Adressen mit T-DSL Business?

Wir haben in der Firma einen T-DSL Business mit dem wir äußerst zufrieden sind. Für einen moderaten Preis haben wir ausreichend Konnektivität und können auch einen Server mit fester IP Adresse betreiben. Für den Web Server verwenden wir Apache Tomcat. Tomcat erlaubt viele virtuelle Server mit einer IP Adresse. Neben Tomcat möchten wir jedoch noch weitere Server wie Glassfish, JBoss und Apache HTTPd einsetzen, die jeweils auf einem eigenem Rechner laufen. Der sehr leistungsfähige Speedport W900V Router unterstützt NAT und ermöglicht Anfragen pro Port an einen speziellen Rechner zu senden. Dann läuft aber jeder Web Server auf einem anderen Port. Um jeden Server auf Port 80 betreiben zu können ist pro Server eine feste IP Adresse notwendig. Laut Hotline der Telekom (Gespräch vom 10.7.2009) kann man zu T-DSL aus technischen Gründen keine weiteren IP Adressen zukaufen. Bei Standleitungen ist das möglich. Allerdings ist eine Standleitung für uns noch überdimensioniert. Bis dahin benötigen wir eine Lösung für T-DSL Business. Da wir nur Web Server betreiben möchten, könnte ein HTTP Router Anfragen auf den Rechner mit der festen IP entgegennehmen und dann an andere Server verteilen.
Unser eigener Router unterstützt momentan nur ein Routing über den Pfadanteil einer URL. Über einen Custom Interceptor könnte man diesen jedoch um ein Routing auf der Basis des HTTP Host Headerfeldes erweitern. Nächste Woche werden wir das mal versuchen.

Axis, CXF, JAX-WS RI u. XFire Stammbaum

Die Beziehungen zwischen den SOAP Toolkits und den Spezifikationen für Web Services mit Java zeigt der folgende "Stammbaum":



Angefangen hat alles mit SOAP4J, das IBM an Apache übergeben hat. Daraus wurde dann das weit verbreitete Axis. Axis1 ist noch heute die Implementierung für JAX-RPC. Da die neueren Tools den RPC/Encoded Nachrichtenstil nicht mehr unterstützen kommt Axis1 immer noch zum Einsatz. Aufgrund der Mängel der JAX-RPC Spezifikation (eigenes Binding Framework, keine Annotationen,...) ist der Nachfolger JAX-WS eine vollkommene Neuentwicklung, die auf den JDK 1.5 Annotationen und dem XML Binding Framework JAXB basiert. Seit neustem unterstützt Axis2 auch JAX-WS. Allerdings nur teilweise. Axis2 verwenden eine Reihe von Apache Projekten wie das SCA Framework Tuscany oder Apache Synapse, ein leichtgewichtiger ESB. Auch die IBM WebSphere Community Edition verwendet Axis2.
Ein weiteres Apache Projekt, welches JAX-WS vollständig implementiert ist CXF. CXF ist aus XFire und Celtix hervorgegangen. Da Xfire und CXF auf Spring basieren wurden sie oft in anderen Projekten als Web Services Komponenten verwendet.
Beispielsweise gibt es für ServiceMix jeweils einen SOAP Konnektor, der auf XFire und CXF basiert.
CXF unterstützt neben JAX-WS für SOAP auch noch JAX-RS. Mit JAX-RS kann man RESTful Web Services mit Java nutzen und realisieren.