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.