Freitag, 18. Dezember 2009

.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.

Freitag, 13. November 2009

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.

Donnerstag, 30. Juli 2009

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 :-) .

Mittwoch, 29. Juli 2009

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.

Freitag, 10. Juli 2009

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.

Montag, 18. Mai 2009

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.

Freitag, 8. Mai 2009

WSDL Versionierung

Meine Kollegen haben vor Kurzem in unser Registry und Monitoring Tool eine Funktion für die Versionierung von WSDL Dokumenten eingebaut. Seit einer Woche ist diese Version auch für unser öffentliches Web Services Verzeichnis im Einsatz. Wie die Abbildung zeigt haben sich tatsächlich bereits zwei WSDL Dokumente geändert.



Aus der WSDL History lässt sich entnehmen, was sich jeweils wann geändert hat. Wie unten ersichtlich wurde um kurz nach halb vier Uhr morgens ein Port für SOAP 1.2 hinzugefügt.



Ich vermute mal unbeabsichtigt durch ein Update des SOAP Frameworks. Um die Überwachung von WSDL Änderungen weiter zu entwickeln suchen wir noch Pilotanwender für unsere open source Registry. Wer Interesse hat kann sich gerne mit mir in Verbindung setzen.

Was SOA von der Objekt orientierten Programmierung lernen kann! (Teil 1)

Es war einmal eine Zeit, in der die Objektorientierung in Mode kam. Die OO Technologie wurde für Ihre Produktivität und Flexibilität gepriesen. Nicht wenige hielten Sie für einen Erlöser, der die Wiederverwendung und den Weltfrieden mit sich bringen würde. Viele hofften auf die Wiederverwendung und auf Entwurfsmuster die die Kosten auf wundersame Weise reduzieren sollte.
Bald schon wurden ehrgeizige Projekte von tapferen Architekten und Projektleitern gestartet. Mit kleinen Anwendungen und Pilotprojekten für den Aufbau von Erfahrungen wollte sich kaum jemand abgeben. Mit C++ oder sogar Java sollten unternehmenskritische Mainframe Anwendungen abgelöst werden. Für Ordnung und Struktur sorgten mächtige Prozessmodelle und Vorgehensweisen. Detaillierte Pläne für die zu erstellende Software wurden mittels der UML gezeichnet.
Große Horden mit zahlreichen furchtlosen Analysten, Softwaredesignern und Architekten nahmen die ehrenvolle Mission in Angriff. Viele von Ihnen hatten ganz genaue Vorstellungen aber noch wenig oder gar keine Erfahrung mit der neuen Sprache, mit den Werkzeugen und Plattformen. Auf halbem Wege fragten sich einige, ob die Systeme an denen Sie arbeiteten jemals fertig oder stabil und schnell laufen würden. Die anderen bleiben standhaft und haben alles gegeben um erfolgreich zu sein. Aber langsam gingen die Budgets zu Ende und die Abgabetermine waren schon lange verstrichen. Schließlich kam die Ernüchterung und die Objektorientierung, Java und die Mehrschichtenarchitekturen wurden in Frage gestellt. Oft hörte man Sätze wie „Java ist zu langsam“ oder „Entity Beans performen doch nie“.
Nicht alle haben sich von diesen Fehlschlägen entmutigen lassen. Einige haben mit Ihrer Erfahrung aus den erfolglosen Großprojekten neue kleinere Projekte gestartet. Die Methoden wurden entschlackt und reduziert. Praktikablere Vorgehen wurden entwickelt und neue Vokabeln wie Agil oder Extreme Programming wurden eingeführt. Zum Einsatz kamen immer häufiger ganz simple Java Klassen, die man Pojos nannte. Auch die Server wurden von Version zu Version schneller und stabiler. Die Entwickler, die sich nicht entmutigen ließen, fanden neue Tools, die Ihnen viel Arbeit und Mühe abnahmen. Die fleißige Ameise half Ihnen bei Bau der Software und im Schatten der Sonnenfinsternis schrieben sie Ihren Code. Nach den ersten erfolgreichen Miniprojekten wurden mittlere Projekte und schließlich größere in Angriff genommen. Getragen vom Erfolg stieß man in immer mehr Bereiche vor und befreite die IT Landschaft um gefürchtete Altsysteme.
Was genau wurde bei den neuen erfolgreichen Projekten anders gemacht, als bei den erfolglosen?
- Iteratives Vorgehen:
Anstatt ein komplexes System im Stück zu planen und zu realisieren wird ein Projekt in mehrere kleine Iterationen aufgeteilt, bei denen immer eine lauffähige Version erstellt wird, die Iteration für Iteration erweitert wird.
- Vor dem eigentlichen Projekt wird ein Prototyp erstellt.
Der Prototyp soll Hinweise zur Machbarkeit liefern und dient zum Sammeln von Erfahrungen. Der Prototyp kann in die Iteration übergehen. Idealerweise sollte ein Prototyp jedoch nicht weiter entwickelt werden. Das Projekt sollte mit den Erfahrungen von Neuem starten.
- Schlanker Prozess:
Beispielsweise wurden anstatt alles haarklein mit der UML zu beschreiben nur so viel wie nötig modelliert. Oder wie beim XP auf UML verzichtet.
- Teamgröße:
Die Teamgrößen wurden reduziert. Anstatt mehreren Dutzend Entwicklern haben die Teams oft weniger als 10 Mitglieder.
- Bestehende Tools und z. B. Infrastruktur verwenden:
Anstatt eine eigene Persistenz Engine zu entwickeln wird auf fertige Tools wie z. B. Hibernate zurückgegriffen.
Im zweiten Teil werde ich in einem späteren Posting beschreiben, was man von den Erfahrungen und Lektionen der Objektorientierung auf die SOA übertragen kann.

Donnerstag, 23. April 2009

Oracle kauft Sun: Was passiert mit Glassfish/Open ESB?

Oracle hat mit Sun nicht nur Java sondern auch den Glassfish Application Server, den Metro Stack und den Open ESB gekauft. Mit diesen Werkzeugen habe ich die letzten Monate verstärkt mit Begeisterung gearbeitet. Jetzt frage ich mich: Wie sieht die Zukunft dieser Tools aus? Oracle hat bereits mit dem Kauf von BEA im letzten Jahr eine leistungsfähige Plattform für Enterprise Applikationen eingekauft. Oracle hat seinen in die Jahre gekommenen OC4J Server durch BEA´s WebLogic ersetzt.
BEA´s AquaLogic Enterprise Service Bus wurde in Oracle Service Bus umetikettiert. Damals haben sich die technisch besseren Produkte durchgesetzt. Wie Oracle den Services Stack von Sun integriert ist noch vollkommen unklar. Ich denke, dass Oracle langfristig nicht WebLogic und Glassfish weiterentwickeln wird. Die Frage ist auch, ob die Open Source Community, die sich an den Sun Produkten beteiligen konnte dies auch bei den Oracle Produkten tun kann oder möchte.
Fraglich ist auch die Zukunft der Java Business Integration Spezifikation. Der JBI Standard sollte den Anwendern Unabhängigkeit von den Middleware Herstellern bringen und einen Markt von austauschbaren Backend Adaptoren sowie Service Engines schaffen. Oracle favorisiert dagegen die Service Component Architecture kurz SCA.
Wie es weitergeht weiß keiner. Die nächsten Monate werden es zeigen. Ich vermute, dass der Glassfish Application Server, Open SSO, Open Message Queue und Open ESB auslaufen werden. Der Web Services Stack Metro wird ausgeschlachtet und einige Teile davon werden in die Oracle SOA Suite integriert werden. Aber das sind nur meine Vermutungen. Einige Anwender könnten sich auch nach Alternativen umschauen, da eine IT mit Hardware, Betriebssystem, Datenbank und Anwendungsserver vom selben Hersteller nicht jedermanns Sache ist.
Glassfish ESB Anwender könnten zu Apache ServiceMix wechseln, der wie Glassfish ESB die JBI Spezifikation unterstützt. Bestehende Komponenten und Integrationsanwendungen können mit etwas Aufwand migriert werden. Mit CXF bietet Apache auch eine JAX-WS Implementierung mit der einige der WS-* Spezifikationen wie WS-Adressing und WS-Security unterstützt. Bleibt nur noch die Java Plattform, die zukünftig von Oracle kommt. Aber Java steht zum Glück ja unter der GPL Lizenz, sodass es vielleicht bald schon ein Open Source SDK geben könnte, das von einer unabhängigen Community entwickelt wird.
Was werden wohl die Mitarbeiter bei Sun machen, deren Projekte aufgegeben werden, obwohl sie technisch ausgezeichnet sind? Ich hoffe, dass viele von Ihnen neue innovative StartUps gründen werden oder dass Sie sich bei Open Source Projekten einbringen werden. Ich bin mal gespannt, was wir in nächster Zeit von ehemaligen Sun Mitarbeitern an Projekten sehen werden.

Dienstag, 24. März 2009

EIP Patterns mit BPEL

Design Patterns sind strukturierte katalogisierte Lösungen für die objektorientierte Programmierung. Analog zu den Design Patterns gibt es für die Systemintegration die Enterprise Integration Patterns, kurz EIP. Der Apache ServiceMix ESB wird mit zahlreichen Implementierungen dieser Patterns ausgeliefert. Beim Glassfish ESB habe ich jedoch vergeblich nach einer Komponente gesucht, die Pattern wie Splitter, Aggregator oder Content based Router anbietet. Mein Kollege Stefan sagte, als ich ihn darauf ansprach, dass man mit BPEL die EAI Patterns leicht umsetzen könnte. Sein neuster Artikel auf unserer Homepage beschreibt die Realisierung eines XPath Splitters mit BPEL.

Montag, 16. März 2009

Web Services Security Standards Portfolio

Im unten angezeigten Portfolio habe ich Standards zu Web Services Sicherheit bezüglich Verbreitung und Komplexität eingeordnet.



Als Tokenformat dient dabei oft SAML. Um den Performanceverlust aus einer assymetrischen Verschlüsselung zu vermeiden liebäugeln einige Softwarearchitekten mit WS-Secure Conversation. Die Bananen im Portfolio geben wieder an, für wie ausgereift ich einen Standard halte. Die Größe der Kugeln entspricht dem Potential des Standards. Auf den ersten Blick sieht man, dass die Standards sich auf zwei Quadranten aufteilen. Im Quadrant oben links ist die Verbreitung hoch und die Komplexität gering. Bei den in diesem Quadranten aufgeführten Standards handelt es sich um gar keine Web Services Standard. Allerdings werden diese „Standards“ am häufigsten für die Absicherung von Web Services verwendet. In der rechten unteren Ecke sind komplexere Standards zu finden, die jedoch erst eine geringe Verbreitung erfahren haben. Über der Mittellinie befindet sich bereits der OASIS Standard Web Service Security. Dieser Standard ist eine Basis für komplexere Security Lösungen. WSS bietet von UsernamToken über die Verschlüsselung bis hin zu Signaturen mit X509 Zertifikaten einiges. In der Praxis wird das UsernameToken oft zusammen mit SSL eingesetzt. Zunehmend wird auch Verschlüsselung und Signaturen auf Nachrichtenebene verwendet. Einige Unternehmen haben bereits Pilotprojekte für das Single Sign On von Web Services mit WS-Trust gestartet.

Montag, 16. Februar 2009

Web Services Standards Portfolio (ohne Security)

Für Web Services gibt es eine Fülle von Standards, die zunehmend in der Praxis eingesetzt werden. Meine Erfahrung zur Verbreitung und Akzeptanz der Standards habe ich in einem Portfolio verdichtet, welches ich hier gerne vorstellen möchte.



Auf der X-Achse lässt sich die Komplexität und auf der Y-Achse die Verbreitung ablesen. Die Größe der Kugeln entspricht dem Potential des jeweiligen Standards. Mit der Banane drücke ich die Reife des Standards aus. Gelb bedeutet ausgereift. Grüne Bananen stehen für noch unreife Standards.
Die Web Service Urgesteine SOAP und WSDL sind mit Abstand am weitesten verbreitet. Der SOAP Standard ist relativ simpel. WSDL verwendet für die Beschreibung von Datentypen XML Schemas und ist daher schon wesentlich komplexer. SOAP und WSDL sind etabliert und genießen eine hohe Verbreitung. Die anderen Standards sind verglichen mit SOAP und WSDL Randerscheinungen. Für das Portfolio habe ich einen logarithmischen Maßstab verwendet. Sie Abbildung ist so verzerrt, dass alles auf Bild passt. SOAP ist ca. 100-mal stärker verbreitet als WS Adressing oder WS Policy. WS Reliability habe ich nur in Demos und Tutorials angetroffen, jedoch noch nicht in der Praxis. WS Adressing und WS Policy haben jedoch bereits die Verfolgung aufgenommen. Es gab eine Zeit in der UDDi in einem Atemzug mit SOAP und WSDL genannt wurde. Wegen Designfehlern konnte sich UDDi nie wirklich durchsetzen. Allerdings gibt es einige SOA Produkte, deren Registry eine UDDi Schnittstelle bietet. Diese Registries wurden hauptsächlich in Großkonzernen eingesetzt. Von den wenigen UDDi Registries, die ich in Betrieb gesehen hatte, war keine gepflegt. Jede enthielt nur Daten über wenige Services. Dies liegt daran, dass kaum eine SOAP Engine ihre Dienste automatisch in eine Registry einträgt. Besonders die Open Source Tools besitzen keine UDDi Anbindung.
Die größte Kugel steht für BPEL. Die dazugehörige Banane ist noch etwas grün. Das die Verbreitung von BPEL gering ist, hängt sicher auch mit der großen Komplexität zusammen. Das große Interesse an BPEL führt vielleicht dazu, dass eine BPEL-Blase mit zunehmender Reife aufsteigt und wer weiß, vielleicht sogar die Mittellinie überschreitet. Soweit meine ganz persönliche Sich auf die Web Services Standards ohne Security im ersten Quartal 2009. Ich hoffe, dass sich bald Änderungen ergeben und ich ein aktualisiertes Portfolio vorstellen kann.