Lange Zeit war Apache Axis mit seiner Implementierung des JAX-RPC-Standards sicherlich unangefochten das am meisten eingesetzte Framework, wenn es darum ging, Web Services auf der Java-Plattform zu entwickeln. Doch das klassische Axis kam in die Jahre. So ist Axis 1.x beispielsweise sehr stark auf Request-Response-basierte Kommunikation ausgelegt, während sich andere Kommunikationsmuster nur umständlich oder gar nicht umsetzen lassen. Weiterhin fällt noch immer an vielen Stellen auf, dass man Axis 1.x ursprünglich mit Fokus auf das SOAP-Nachrichtenformat RPC/Encoded entwickelt hat. Es wuchs jedoch der Bedarf an dokumentenbasierter Kommunikation, so wie es unter anderem auch von Basic Profile bevorzugt wird. Ein weiteres Problem hat Axis 1.x mit seiner langsamen Performance. SOAP-Nachrichten werden in Axis 1.x, bedingt durch den enthaltenen DOM-basierten Parser, zunächst komplett eingelesen und erst dann verarbeitet. Diesem aufwendigen Verfahren kann man in der heutigen Zeit jedoch Dank solch innovativer Technologien wie StAX entgegenwirken. Durch die mit StAX mögliche Technik des so genannten Pull Parsing, bei dem eine SOAP-Nachricht immer nur so weit geparst wird, wie es zum aktuellen Zeitpunkt der Verarbeitung erforderlich ist, fällt unnötiger Ballast ab, und ein nicht von der Hand zu weisender Geschwindigkeitsschub ist die Folge. Die Entwicklung, das Deployment und die Administration von Web Services sind mit Axis 1.x an einigen Stellen aufwendig, komplex und so in der Zeit von "Ease of use" nur noch bedingt tragbar. Das Einbinden von externen Data-Binding-Frameworks wie beispielsweise JAXB, XMLBeans oder JiBX ist mit Axis 1.x ebenfalls nur umständlich möglich (weil schlecht dokumentiert), und zu guter Letzt gibt es mittlerweile eine ganze Reihe neuer Web-Service-Technologien, die vom klassischen Axis nur rudimentär oder gar nicht unterstützt werden.
So begann man also bei Codehaus mit der Implementierung eines neuen SOAP-Frameworks das alle oben erwähnten Nachteile von Axis 1.x beseitigen sollte. Ungefähr zur gleichen Zeit fiel mit dem Projekt AxisMoria, wo es darum ging, Axis 1.x mit StAX-Unterstützung auszustatten, auch in Sri Lanka bei der Apache Software Foundation der Startschuss zum neuen Axis-Projekt. Die ursprüngliche Idee, auf Basis von Axis 1.x weiterzuentwickeln, wurde jedoch verworfen und man entschied, Axis von Grund auf neu zu entwickeln. An beiden Projekten wird natürlich nach wie vor entwickelt. Axis2 implementiert von Haus aus zunächst keine von Sun standardisierten APIs, was einen großen Unterschied zu Axis 1.x und XFire darstellt. Man arbeitet im Lager von Axis mittlerweile jedoch an einer Implementierung der neuen Web-Service-Spezifikation JAX-WS (Nachfolger von JAX-RPC), die in Axis2 1.1 vermutlich in einer ersten, experimentellen Fassung enthalten sein wird. Unterstützung für Spring und die Anbindung an Script-Sprachen wie Groovy sind ebenfalls in Arbeit beziehungsweise werden mit dem Release 1.1 von Axis2 verfügbar sein.
In den Reihen von XFire hat man sich darauf verständigt, ein Bündnis mit den Kollegen aus dem Celtix-Projekt einzugehen und beide (Web-Service-)Projekte zu verschmelzen. Ein entsprechendes Proposal für das Projekt CeltiXfire (CXF) wurde auch bereits bei der Apache Software Foundation eingereicht. Das bedeutet, dass bei XFire derzeit am Merge von XFire und Celtix gearbeitet wird, wobei aber auch hier der Schwerpunkt auf JAX-WS liegt. XFire 1.x enthält zwar bereits eine erste Version von JAX-WS (Early Access Support), doch für die zukünftigen Releases möchten die Entwickler lieber auf die Celtix-Implementierung zurückgreifen. Man hat ferner vor, in Zukunft neben SOAP auch REST zu bedienen. Die Data Bindings sollen verbessert werden und für die Spezifikation WS-Reliable Messaging – hier geht es um Verfahren zur garantierten Zustellung von Nachrichten – ist ebenfalls eine Implementierung vorgesehen.
Die Entwickler von XFire teilen in diesem Zusammenhang weiterhin mit, das Web-Service-Anwendungen, die auf XFire 1.x basieren, zwar nicht mehr hundertprozentig mit der neuen CeltiXFire-Plattform kompatibel sein werden, man aber noch lange Support und Bugfixes für XFire 1.x zur Verfügung stellen will. Zusätzlich plant man einen speziellen Layer für Benutzer von XFire 1.x, der die Migration hin nach CeltiXFire erleichtern soll. Da sich CeltiXFire derzeit in Entwicklung befindet, liegt diesem Artikel XFire in der Version 1.2.2 zugrunde.
Gemeinsamkeiten
Zunächst kann man festhalten, dass sowohl Axis2 als auch XFire durch konsequente Verwendung von StAX deutlich schneller sind als Axis 1.x. Dieser Umstand macht die beiden Kontrahenten sicherlich zu den schnellsten SOAP-Frameworks, die derzeit auf der Java-Plattform verfügbar sind (berücksichtigen sollte man dabei jedoch, dass die Performance auch stark vom jeweils verwendeten Data-Binding-Framework abhängig ist). In beiden Projekten wurde schon während der Entwicklung darauf geachtet, dass man in andere Produkte eingebettet werden kann – ein Feature, das von Axis 1.x nur sehr stiefmütterlich behandelt wurde. Das Erzeugen von Web Services aus POJOs geht auf beiden Seiten sehr einfach von der Hand, Spring-Support war bis vor kurzem nur in XFire vorhanden, doch mit Axis2 1.1 ist derselbige nun auch hier verfügbar.Für beide Projekte existiert IDE-Unterstützung in Form von Plug-ins. Axis2 bringt Plug-ins für Eclipse und IntelliJ IDEA mit, mit deren Hilfe man Codegerüste aus WSDL-Beschreibungen und umgekehrt, also WSDL aus bestehendem Code, erzeugen kann. Ferner gibt es bei Axis2 ein Plug-in, das beim Deployment von Web Services hilfreich zur Seite steht. XFire kommt lediglich mit einem Werkzeug zur Codegenerierung aus WSDL und beschränkt sich auf Eclipse. Beide Projekte liefern selbstverständlich entsprechende Möglichkeiten, um Codegenerierung auch auf der Kommandozeile oder in einem Ant-Task durchzuführen, wobei sich XFire hier ebenso auf die Generierung von Code aus WSDL beschränkt.
Eine weitere Gemeinsamkeit kann man in beiden Projekten beim Verschicken von großen oder binären Dateien mit der SOAP-Nachricht verzeichnen. Eine Möglichkeit wäre an dieser Stelle, auf die Technik "Soap with Attachments" (SwA) zurückzugreifen, die bereits zu Zeiten von Axis 1.x zur Verfügung stand und natürlich weiterhin in Axis2 angeboten wird. Mit MTOM (Message Transmission Optimization Mechanism) und XOP (XML Optimized Packaging) gibt es hier aber mittlerweile optimierte Alternativen. Bei SwA wird der binäre Datenteil, vergleichbar mit einem Anhang in einer E-Mail, einfach ans Ende der SOAP-Nachricht gehängt. Dies führt zu einem doppelten Datenmodell in der Nachricht: XML auf der einen, binäre Daten auf der anderen Seite. Dies kann in rein XML-basierten Verarbeitungsszenarien, zum Beispiel im Zusammenhang mit DTDs, zu Problemen führen. MTOM versucht, dieses Problem zu lösen, indem es ein Verfahren zur Verfügung stellt, bei dem der binäre Anteil zwar immer noch angehängt ist, das es aber trotzdem ermöglicht, den Anhang im Rahmen der XML-Verarbeitung als Bestandteil der SOAP-Nachricht zu betrachten. Axis2 unterstützt SwA und MTOM, XFire beschränkt sich auf MTOM.
Standards und Spezifikationen
Beide Konkurrenten sind konform zu Basic Profile 1.1, ein sehr wichtiger Aspekt, denn hierbei handelt es sich um einen von vielen namhaften Firmen unterstützten Industriestandard, der beschreibt, wie man Web-Services-Technologien verwenden soll, um bestmögliche Interoperabilität zu erreichen. SOAP wird von beiden Projekten in den Versionen 1.1 und 1.2 in voll unterstützt, Selbiges gilt für WSDL 1.1. WSDL 2.0 ist in beiden Projekten noch in Arbeit. Ein weiterer Kernstandard ist sicherlich SAAJ (SOAP with Attachments API for Java). Auch wenn der Name den Schluss zulässt, dass es sich hier um ein API handeln könnte, mit dem man ausschließlich SOAP-Nachrichten mit Attachments erzeugen kann, so ist diese Vermutung falsch. Tatsächlich handelt es sich bei SAAJ um ein API, das generell zum Aufbau und zum Zugriff auf SOAP-Nachrichten verwendet wird. Andere wichtige APIs, wie beispielsweise JAX-RPC, verwenden SAAJ. In XFire ist aktuell keine Unterstützung für SAAJ enthalten, Axis2 kann hier punkten. Bei JAX-RPC handelte es sich um eine Standardspezifikation, die ein API- und Programmiermodell für die Web-Service-Entwicklung in Java definierte. Wesentliche Bestandteile von JAX-RPC waren das Type Mapping zwischen Java und WSDL sowie die Programmiermodelle auf der Server- und Client-Seite. JAX-WS ist der Nachfolger von JAX-RPC. Während Axis 1.x noch JAX-RPC kannte, fehlt diese Unterstützung nun sowohl in XFire als auch in Axis2.Einen weiteren, neuen Standard stellt der JSR 181 – Web Services Metadata – dar, legt dieser doch Annotations fest, mit denen man sich die Web-Service-Entwicklung sehr viel leichter machen kann. So ist es beispielsweise möglich, durch Setzen der Annotation @WebService eine komplette Klasse zum Web Service zu machen. Der JSR 181 definiert eine Vielzahl solcher Annotations, viele auch im Rahmen von JAX-WS genutzt, mit denen man zum Beispiel bestimmen kann, welche Methoden einer Klasse im Web Service verfügbar sein oder welche Nachrichtenstile verwendet werden sollen u.v.a.m. Anders ausgedrückt bietet sich hier eine Fülle von Möglichkeiten, um Einfluss auf SOAP oder WSDL zu nehmen. Axis2 unterstützt den JSR 181 derzeit nicht. XFire hat hier gegenüber Axis2 deutlich mehr zu bieten, denn es glänzt nicht nur mit einer vollständigen Unterstützung des JSR 181, XFire bietet darüber hinaus sogar Unterstützung des JSR 181 für Java 1.4 an. Erreicht wird dies durch Verwendung des Projektes Commons Attributes, eines Teils von Jakarta Commons, in dem man Attribute (hier synonym zu Annotations) in Form von Kommentaren in den Code einstreut. Die Idee stammt aus der .NET-Welt und kann als Alternative zu Annotations betrachtet werden. Wenn man also gezwungen ist, mit Java 1.4 zu arbeiten, so bleiben einem mit XFire die vielfältigen Möglichkeiten des JSR 181 nicht verschlossen.
Die Welt der Web Services ist sehr umfangreich und komplex. So verwundert es auch nicht, dass es mittlerweile eine große Anzahl an zusätzlichen Spezifikationen und Erweiterungen gibt: Nicht umsonst spricht manch einer hier gerne vom WS*-Universum. Alle diese Erweiterungen sollen Web Services sicherer machen, asynchrone Kommunikation ermöglichen oder sich mit der Problematik beschäftigen, wie man das Zustellen von SOAP-Nachrichten garantiert. Im Rahmen dieses Artikels kann nicht jede einzelne Erweiterung besprochen werden, daher sind am Ende einige interessante Verweise ins WS*-Universum abgedruckt. Axis2 und XFire unterstützen WS-Adressing und WS-Security. WS-Policy ist in Axis2 fest eingebaut. Darüber hinaus gibt es für Axis2 noch Erweiterungen, mit denen man WS-Coordination, WS-AtomicTransaction, WS-BusinessActivity (Apache Kandula2) und WS-Reliable Messaging (Apache Sandesha2) nachrüsten kann.
