3 Axis2-Kernentwickler im Gespräch

Web Services der dritten Generation

Thilo Frotscher

Die beiden Veranstaltungen zu Axis2 auf der ApacheCon Europe im Juli waren bestens besucht. Am Rande der Konferenz ergab sich Gelegenheit zu einem Gespräch mit drei der Kernentwickler des Axis2-Projektes, die alle für die Lanka Software Foundation arbeiten: Eran Chinthaka, Chathura Herath und Ajith Ranabahu.

JM: Ihr arbeitet alle drei bei der Lanka Software Foundation in Sri Lanka. Was genau ist die LSF? Axis2-Team: Die Lanka Software Foundation ist eine Non-Profit-Organisation, die es sich zum Ziel gesetzt hat, die Softwareindustrie und -Entwickler von Sri Lanka zu fördern. Die Finanzierung der LSF kommt dabei von verschiedenen Quellen. So finanziert zum Beispiel SIDA (Swedish International Development Cooperation Program) zwei Projekte und auch IBM hat Geld für einige Projekte gegeben. Vom Ablauf her funktioniert das so, dass die LSF zunächst Beschreibungen von Softwareprojekten anfertigt, die sie angehen möchte. Diese Beschreibungen werden dann bei IT-Firmen in Sri Lanka herumgereicht mit der Bitte, dass diese einen oder mehrere Entwickler dafür entsenden. Die LSF bietet also praktisch Stipendien für Entwickler.Das Hauptziel ist aber, die Softwareindustrie von Sri Lanka zu fördern und der Welt zu zeigen, dass es dort Leute gibt, die gute Software produzieren können. Die LSF nimmt sich Open-Source-Projekten an und versucht, diese zu erfolgreichen Projekten zu machen. Und wenn später Firmen wie IBM diese Open-Source-Software in ihren Produkten einsetzen, werden sie vermutlich Expertise für diese Software benötigen.JM: Das wohl wichtigste von der Lanka Software Foundation entwickelte Projekt ist Axis2. Wie viele Leute entwickeln daran und wie sind die Aufgaben verteilt?Axis2-Team: Wir sind insgesamt acht Kernentwickler und wir diskutieren alle Konzepte von Axis2, wie beispielsweise Deployment oder Axiom, immer gemeinsam. Aber es gibt immer nur eine Person oder maximal zwei, die verantwortlich sind für eine bestimmte Komponente. Wenn du also ein Problem hast oder meldest, wirst du in aller Regel Antwort von diesem Verantwortlichen bekommen.JM: Wie viele Leute entwickeln überhaupt noch an der aktuellen Version Axis 1.2.x? Axis2-Team: Das wissen wir nicht so genau, denn das ist ein komplett anderes Team und wir arbeiten nicht direkt mit ihnen zusammen. Lediglich die ursprünglichen Architekten von Axis 1.x sind auch für die Grundarchitektur von Axis2 verantwortlich. Aber wenn man sich die Mailing-Liste anschaut, dann sieht man, dass nicht mehr allzu viele Leute an Axis 1.x arbeiten. Ursprünglich waren drei Vollzeitkräfte im Axis 1.x-Projekt, die von Computer Associates gespendet wurden und jetzt mit uns an Axis2 arbeiten. Zusätzlich war dann noch Davanum Srinivas als treibende Kraft dabei. Des Weiteren ist Srinath Perera involviert und auch Glen Daniels ist noch dabei und fixt Bugs. Ach ja, und Tom Jordahl auch.JM: Steuern die Unternehmen, die Entwickler oder Geld geben, dann sehr stark, in welche Richtung die Projekte gehen oder welche Projekte Ihr überhaupt macht?Axis2-Team: Entwickler und Geld werden immer für spezielle Projekte gespendet. So zum Beispiel kürzlich für das Axis C++-Projekt. Die LSF startet keine Projekte, bevor sie nicht finanziert sind. Z.B. haben wir von SIDA eine Finanzierung für das Axis 2-Projekt für ein Jahr bekommen. Nach einem Jahr muss man eine neue Finanzierung finden. Aber selbst wenn das nicht klappen sollte: Du weißt, wie Open-Source-Leute so sind: Wenn sie erst mal involviert sind, arbeiten sie notfalls auch in der Freizeit weiter an einem Projekt. Aber keiner von uns Dreien hat irgendwelche Verpflichtungen gegenüber irgendeiner Firma. Und wenn wir jetzt hier im Interview sitzen, repräsentieren wir auch keine Firma, sondern alles was wir sagen, ist unsere persönliche Meinung als individuelle Entwickler.JM: Es wurde Kritik daran geäußert, wie das Axis 1.x-Projekt generell abläuft. So sind für Axis 1.x eine ganze Menge Bugs gemeldet, die offenbar niemals gefixt werden – wie soll das weitergehen? Manche Bug-Meldungen sind Jahre alt und nicht gefixt und einige potenzielle User fragen sich, ob sie diese Software einsetzen sollten, wenn Dutzende Bugs existieren, die vor Monaten oder gar Jahren gemeldet wurden.Axis2-Team: Wir sollten das nicht kommentieren, denn es ist nicht unser Projekt. Weißt du, es gibt auch Benutzer, die melden Bug Reports, weil ihrer Meinung nach irgendein Feature auf die ein oder andere Weise funktionieren sollte. Das entspricht nicht immer den Vorstellungen des Entwickler-Teams und manche Vorschläge werden abgelehnt, z.B. weil wir überzeugt sind, dass sie die Software am Ende schlechter machen oder einfach unvernünftig sind. Aber klar, solche Bug Reports sollten dann wenigstens entsprechend kommentiert und geschlossen werden.JM: Ihr bezeichnet euer Projekt als SOAP-Framework der dritten Generation. Was sind für euch die wichtigsten neuen Features von Axis2?Axis2-Team: (Chatura) Ich denke, Axiom ist das wichtigste neue Feature und damit der späte Aufbau des Objektmodells einer SOAP-Nachricht. Das wird die Geschwindigkeit deutlich verbessern. Dann kommen die Modularchitektur und das Konzept der Phases, also die Erweitungsschnittstellen für die Axis2 Engine. Axis 1.x hatte hierfür das Konzept der Handler Chains. Dieses Konzept ist auch in Axis2 noch da, aber wir haben es logisch unterteilt in die so genannten Phases. Wenn man also Axis2 erweitern möchte, schreibt man einfach ein Modul, sei es nun für Security, Transaktionen, Reliable Messaging oder was auch immer. Zusätzlich zu den Handlern enthält das Modul dann aber auch noch einen Descriptor mit Regeln, die definieren, wann bzw. wo die einzelnen Handler ausgeführt werden sollen. Man könnte so definieren, dass der Security Handler als Erstes aufgerufen wird, egal, welche sonstigen Handler eingerichtet werden. Dies ist die Flexibilität, welche Phases und die Modularchitektur erlauben. Auf dem dritten Platz sehe ich die neuen Client APIs mit ihrem Support für synchrone und asynchrone Kommunikation. Wenn man in Axis 1.x ein Kommunikationsmuster vom Typ IN-only verwenden will, dann wird das intern durch einen ziemlich Hack realisiert: Es wird irgendwo in der Axis Engine ein Flag in den MessageContext gesetzt. Denn zu der Zeit, als Axis 1.x entwickelt wurde, waren die Konzepte für kompliziertere Kommunikationsmuster einfach noch nicht da. Als wir nun damit begannen, die Architektur für Axis2 zu entwerfen, waren uns natürlich all diese Probleme von Axis 1 bekannt, sodass wir besonderes Augenmerk darauf lenken konnten. Mit dem Ergebnis, dass synchrone und asynchrone Kommunikation heute in sehr eleganter Weise gelöst sind. Es gibt nun Callbacks und vor allem ist die Kommunikation vollkommen transportunabhängig. Die Klasse Call bietet nun Methoden, mit denen man bestimmen kann: Sende eine Nachricht mit Transportsprotokoll A und empfange die Antwort mit Transportprotokoll B.(Eran) Für mich ist die stark verbesserte Geschwindigkeit das wichtigste neue Feature. Mit Axis2 haben wir deutlich bessere Antwortzeiten gemessen. Außerdem ist der kleinere Memory Footprint wichtig. Zum Beispiel, dass der Body einer Nachricht erst mal nicht aus dem Stream gelesen wird, sondern dann, wenn der Body auch wirklich verarbeitet wird. Allein das verbessert den Memory Footprint sehr deutlich. Dann die Einführung von Axiom. Man kann jedes beliebige Data Binding Tool als Schicht oben drauf setzen. Und schließlich Hot Deployment.JM: Das hört sich alles ausgesprochen viel versprechend an. Aber für mich als Entwickler, der Axis2 in Anwendungen einsetzen will, ist ein ganz anderes Feature am allerwichtigsten: die Abkehr von RPC/Encoded als Default-Einstellung für den Nachrichtenstil, der verbesserte Support von Document/Literal und die stark verbesserte Unterstützung auch anderer Kommunikationsmuster als nur Request/Response. RPC/Encoded sollte gemäß dem Basic Profile des WS-I ohnehin nicht mehr verwendet werden.Axis2-Team: Das stimmt. Aber auf der anderen Seite können wir RPC/Encoded jetzt nicht einfach unter den Tisch fallen lassen. Es wird immer noch eingesetzt und die Leute verlangen auch danach, dass Axis2 das unterstützt. Deshalb wird auch Axis2 RPC/Encoded unterstützen.JM: Ja klar, das ist eine gute Entscheidung. Denn man kann sich gut vorstellen, dass zukünftig viele Unternehmen ihre Projekte von Axis 1.x auf Axis2 umstellen wollen, allein deshalb, weil es schneller ist und wegen des Memory Footprint. Aber sie werden deshalb keinesfalls den SOAP-Nachrichtenstil ändern wollen, den sie aktuell verwenden, denn dann müsste ja die Kommunikation mit allen Geschäftspartnern neu getestet werden. Axis2 braucht unbedingt auch weiterhin Support für RPC/Literal. Ist denn auch eine Unterstützung für Web Service Metadaten (Annotations) geplant, wie es auch in der nächsten Version von Java EE enthalten sein wird?Axis2-Team: Ja, auf jeden Fall. Allerdings ist die Spezifikation hierfür erst seit kurzem fertig. Aber der Plan ist, mit Annotationen innerhalb einer Klasse anzuzeigen, welche Methoden von außen erreichbar sein sollen und welche nicht. Ganz ähnlich, wie das auch in C# funktioniert. Vor drei Monaten wandte sich einer der Entwickler von Beehive an uns und sagte, er hätte eine Axis-Integration für Beehive implementiert. Er denkt darüber nach, diese an das Axis2-Projekt zu übergeben.JM: Das hört sich sehr interessant an. Ich selbst bin gar nicht sicher, ob ich diesen Ansatz mit Annotations im Zusammenhang mit Web Services mag, weil ich denke, dass dies den Code-First-Ansatz fördert, während ich aber den Contract-First-Ansatz als deutlich bessere Alternative ansehe. Aber dennoch ist es gut, dass es Support geben wird, denn wenn Web-Service-Metadaten erst einmal Bestandteil von Java EE sein wird, werden die Leute es auch verwenden wollen und danach verlangen.Axis2-Team: Das sehen wir ähnlich. Deshalb werden wir nicht sagen, das ist cool, wir werden es nicht so in das Projekt einbauen, dass man es unbedingt verwenden muss, aber wir werden es unterstützen.JM: Wann kann mit einem Release 1.0 gerechnet werden? Wann kann man Axis2 produktiv einsetzen?Axis2-Team: Wir haben noch ein bis zwei Blocker zu lösen, anschließend sind dann noch ein paar Kleinigkeiten aufzuräumen. Natürlich bringen wir erstmal eine Beta und einen Release Candidate. Aber wir denken, wir könnten schon bald soweit sein. Was den Einsatz in produktiven Umgebungen angeht: Von Anfang haben wir uns vorgenommen, dass wir nicht sämtliche geplante Funktionalität sofort im ersten Release bringen. Aber das, was wir tun, wollen wir gescheit machen. Wenn wir jetzt Document/Literal unterstützen, dann ist dieser Support auch gut. Wenn du eine WSDL für einen Document/Literal-Service in Produktion hast, dann kannst du Axis2 auch in Produktion dafür einsetzen. So wollen wir vorgehen: inkrementell, aber was da ist, soll von guter Qualität sein.JM: Programmiert ihr alles von Grund auf neu oder gibt es eine gewisse Wiederverwendung aus Axis 1.2.x?Axis2-Team: Die grundlegende Architektur von Axis2 unterscheidet sich sehr von der in Axis 1. Daher ist Wiederverwendung nicht einfach. Aber wir haben zuerst überlegt, welche Features Axis2 haben soll und dann bei der Planung der Architektur auf die Konzepte von Axis 1 geschaut. Immer wenn es dort eine gute Lösung gab, haben wir sie übernommen. Was den Code angeht, mussten wir letztlich aber doch das meiste neu implementieren. Aber es gibt einige Wiederverwendung in den Tools, wie Java2WSDL oder TCPMonitor. Und dann natürlich die Interfaces, wie z.B. das Handler-Interface.JM: Warum verwendet Axis einen unterschiedlichen Ansatz für Deployment und Konfiguration als Java EE?Axis2-Team: Eigentlich haben wir darauf überhaupt nicht geschaut und versucht, das aus Axis 1.x zu übernehmen. Wir haben einfach im Wesentlichen das übernommen, was es bereits gab, denn das hat immer recht gut funktioniert. Es gab kaum Ärger damit, die Benutzer haben sich nicht über den Deployment-Mechanismus von Axis 1 beschwert. Axis 1.x hatte beim Deployment allerdings das Problem mit dem Classpath. Man konnte zwar ein Remote Deployment machen, aber physikalisch musste man anschließend dann doch die benötigten Klassen in den Classpath des Webcontainers kopieren und eventuell diesen sogar neu starten. Deshalb haben wir jetzt in Axis2 den Upload von .jar-Files eingeführt. Unterm Strich ist das viel bequemer.JM: Der Tool-Support für Web Services ist insgesamt gesehen meiner Meinung nach noch sehr schwach. Das Eclipse WTP bringt nun einige Unterstützung für Axis mit. Es basiert zwar noch auf Axis 1.1, aber es gibt Plug-ins für Code-Generierung, Service Deployment usw. Hattet ihr schon Gelegenheit, euch diese Features anzuschauen und wie gefallen sie euch?Axis2-Team: Sie gefallen uns gut. Auch wenn wir für Axis2 eigene Eclipse-Plug-ins anbieten, so muss man doch froh sein, dass sich endlich etwas auf dem Tool-Markt tut. Auch Axis 1 kam mit zu wenig Tools. Schau dir dagegen an, was Microsoft macht. Die haben ein viel besseres Tooling.JM: Kann man das denn vergleichen? Axis ist ein vergleichsweise kleines Open-Source-Projekt, wohingegen Microsoft über riesige Mengen von Entwicklern verfügt.Axis2-Team: Das stimmt schon. Aber am Ende des Tages müssen wir auch mit deren Lösung konkurrieren, stehen auch mit Microsoft im Wettkampf. Tools spielen eine wichtige Rolle, wenn es um Usability geht. Schau dir den Apache an. Als der noch als einfaches Zip-Archiv ausgeliefert wurde, haben ihn viel weniger Leute einfach mal so ausprobiert. Jetzt gibt es einen netten Installer und seitdem gibt es auch eine wachsende Zahl von Leuten, die sich das Ganze einfach mal runterladen und anschauen. Wenn Tools ins Spiel kommen, beginnen die Leute, das Ganze zu mögen, und benutzen es dann auch. Daher hatten wir von Anfang an einen speziellen Fokus auf Tools. Unsere Tools sollen benutzbar sein und von guter Qualität. Sei es zum Erzeugen von Axis-Archiven, zur Code-Generierung usw. Was immer wir mit Axis2 tun, wir müssen auch gute Tools dafür anbieten.JM: Axis ist nicht das einzige Open-Source-Projekt, das ein SOAP-Framework für Java entwickelt, siehe zum Beispiel XFire. Wie seht ihr das? Begrüßt ihr Vielfalt und Konkurrenz oder denkt ihr, es sollten besser alle an einem Strang ziehen?Axis2-Team: Das ist eine politische Frage (lachen). Es ist letztlich die Wahl des Benutzers, oder?JM: Klar, natürlich. Was ich meinte ist Folgendes: einige der grundlegenden Entwicklungsziele von XFire wie StAX-Parsing, Data Binding mittels XMLBeans oder kleiner Memory Footprint sind deckungsgleich mit euren. Auf der Webseite von XFire findet sich eine Tabelle mit einem Feature-Vergleich verschiedener SOAP-Stacks. Dort sieht man wiederum, dass es neben vielen gemeinsamen auch eine Reihe von wirklich wichtigen Features gibt, die bisher nur von einem der Stacks unterstützt werden, vom jeweils anderen aber nicht. In der Vergangenheit wurden einige Stimmen laut, man sollte lieber zusammen arbeiten, um schneller ans Ziel zu kommen, anstatt dass mehrere Projekte letztlich dasselbe entwickeln. Wie denkt ihr darüber? Konkurrenz ist natürlich immer gut, keine Frage, aber einige Leute finden, die hätte man eigentlich schon genug durch Microsoft.Axis2-Team: Das Ziel von Apache ist es, gute Open-Source-Projekte zu bauen. Wenn also alle Open-Source-Entwickler zusammen arbeiten wollten, wäre das großartig. In der Praxis ist es aber so, dass dies nicht geht. Da kommen Sachen wie die Apache-Lizenz ins Spiel, die beachtet werden muss und am Ende würde es mehr als ein Jahr dauern, um alles zu verhandeln. Aber selbst wenn die rechtlichen Dinge nicht wären: Es ist auch eine Sache der Einstellung der jeweiligen Entwickler. Manche wollen einfach ihr eigenes Ding machen und ihre eigenen Vorstellungen umsetzen. In einem größeren Team müsste man sich gegebenenfalls den Entscheidungen anderer beugen. Und schließlich gibt es auch Projekte, übrigens auch bei Apache, bei denen die Entwickler lieber unter sich bleiben und andere einfach nicht so gerne mitarbeiten lassen wollen.Aber wir vom Axis 2-Projekt können auf alle Fälle sagen, dass wir jederzeit alle Art von Kommentaren, Ideen und Unterstützung von jedermann begrüßen. Auch wenn es manchmal so ist wie neulich: Da sagte ein Entwickler aus Australien, er würde gerne mithelfen. Und dann verbringt man sechs Stunden damit, ihn dabei zu unterstützen, ungefähr 30 Zeilen Code zu schreiben, für die man selbst vielleicht fünf Minuten gebraucht hätte. Aber um zur Frage zurück zu kommen: Wettbewerb zu haben ist super, auch von Microsoft, und es macht uns Spaß zu konkurrieren. Das motiviert uns.JM: Wie viele Leute laden Axis2 denn im Moment schon runter? Habt ihr da Zahlen?Axis2-Team: Das können wir jetzt aus dem Stehgreif nicht so genau sagen, aber vor dem Release von Version 1.0 erwarten wir sowieso nicht so wahnsinnig viele Downloads. Es sind eher Leute wie du, die sich besonders stark mit der ganzen Materie beschäftigen und die jetzt sehen wollen, was das neue Axis bringen wird. Die eigentlichen End-User warten erst mal ab, bis es ein erstes stabiles Release gibt.JM: Arbeitet ihr eigentlich nebenbei auch an den anderen Web-Service-Projekten von Apache mit, wie beispielsweise Sandeesha, Adressing, WSS4J usw.?Axis2-Team: Ja, einer von arbeitet an WS-RM, ein anderer an EWS (Java EE Web Services, JSR 109), das gerade mit Geronimo integriert wurde. Es ging hier darum, dass Geronimo einen SOAP-Stack bekommt. Diese Integration basierte allerdings auf Axis 1.x, denn damals gab es noch kein Axis 2-Projekt oder zumindest nichts, was wir schon in Geronimo hätten einbauen können. Einer von uns noch Committer im Projekt Woden, einer Implementierung von WSDL 2.0. Aus Sicht von Axis2 freuen wir uns auf WSDL 2.0. Wir nutzen bisher unsere eigene Implementierung, aber wir haben keinen Parser.JM: Ist auch die Implementierung von WS-Policy ein Teil eurer Arbeit und wird in Axis2 Unterstützung dafür enthalten sein?Axis2-Team: Es gibt es eigenes Projekt für WS-Policy, dessen Intention es ist, einen Policy Parser zu implementieren. Wir wollen diesen Parser dann in Axis2 integrieren. Policies werden zukünftig eine Schlüsselrolle in der Web-Services-Welt spielen, deswegen hatten wir in unseren anfänglichen Planungen vorgesehen, dass bereits Release 1.0 von Axis2 eine WS-Policy-Unterstützung mitbringen sollte. Allerdings ist der dynamische Teil des Policy-Konzeptes nicht so ganz einfach. Die Policies müssen hin und her geschickt werden, um verschiedene Aspekte der Kommunikation auszuhandeln und die Engine muss zur Laufzeit die richtigen Policies auswählen und entsprechend beachten. Wir haben Unterstützung von vier Leuten von der Universität, die eine Art Policy-Modell entwickelt haben, das jede beliebige WS-Policy in eine normalisierte Form umwandelt. Es wird also daran gearbeitet, aber es gibt noch einiges zu tun. Wenn du dir die Axis2-Dokumentation anschaust, findest du bereits eine Phase mit dem Namen Policy Determination, wo dann die ganzen Policies auswertet werden, bevor die Nachricht an die restliche Handler-Kette weitergereicht wird. Wir vergessen dieses Thema bestimmt nicht, aber wir brauchen noch ein bisschen mehr Infrastruktur, um die ganze Policy-Verarbeitung in die Axis Engine einbauen zu können.JM: Auf der Website der LSF wird ein Projekt namens Axis Mora erwähnt. Was verbirgt sich dahinter? Axis2-Team: Axis 1.x verwendet Reflection für den Service-Aufruf. Nun, wenn du dir eine WSDL ansiehst, kannst du aber eigentlich vorhersagen, wie die SOAP-Nachrichten aussehen werden, die du bekommen wirst. Gäbe also ein Wrapping des eingehenden XML, sodass man kein Reflection mehr verwenden müsste, um den Web Service aufzurufen, würde das die ganze Sache deutlich schneller machen. Aus dieser Idee entwickelte sich ein eigenes kleines Projekt, das von drei Studenten an der Universität realisiert wurde. Sie haben die Axis 1.x-Engine umgeschrieben und sichergestellt, dass das Wrapping gut funktioniert. Außerdem haben sie auch die Serialisierung/Deserialisierung optimiert und mit all diesen Maßnahmen bis zu neunfach bessere Performance gegenüber der damaligen Version von Axis 1.x erreicht. Das Ganze war auch eines unserer wichtigsten Anliegen bei Axis2: endlich diese Reflection loszuwerden. So findet man Axis Mora nun im contrib-Verzeichnis von Axis 1.x und die Konzepte sind von Anfang an in unser Projekt eingeflossen: Axis2 bei der Code-Generierung aus einer WSDL jedes Mal einen Service-spezifischen Message Receiver, der die aufzurufenden Methoden der Service-Klasse kennt und direkt aufrufen kann.JM: Letzte Frage: Wie sieht’s mit einer Integration von Axis und Spring aus? Habt ihr das in Planung? Es gäbe hierfür ja einige Ansatzpunkte, wo das durchaus Sinn machen würde.Axis2-Team: Eine solche Integration wäre eine tolle Sache, absolut. Aber es ist aus unserer Sicht ein nice to have-Feature. Von denen haben wir ohnehin schon eine lange Liste. Für uns ist es jetzt erst mal wichtig, möglichst bald eine Version 1.0 herauszubringen. Spring-Integration braucht man nicht unbedingt, um in Produktion gehen zu können. Was die Leute jetzt erst mal haben wollen, ist eine Version, die alle wirklich wichtigen Features enthält. Das Ganze sollte vor allem natürlich gut funktionieren. Wir werden keine zweite Chance bekommen, einen guten ersten Eindruck zu machen. Wir arbeiten deshalb jetzt erst mal hart daran, dass für Version 1.0 alles zu 100 Prozent funktioniert und dann sehen wir weiter.JM: Vielen Dank für das Gespräch!Das Gespräch führte Thilo Frotscher.


Axis2 – was ist neu?

Ein Kernpunkt von Axis2 ist die Abkehr von DOM, bei dem für alle eingehenden Nachrichten zunächst ein kompletter Objektbaum erzeugt wurde, der den Inhalt der Nachricht repräsentiert. Stattdessen setzt man nun auf StAX-basiertes XML-Parsing. SOAP-Nachrichten werden immer nur soweit geparst, wie es zu einem gegebenen Zeitpunkt während der Verarbeitung notwendig ist. Durch dieses verschobene Parsing wird beispielsweise verhindert, dass ein SOAP Body unnötigerweise geparst wird, obwohl die Nachricht bereits aufgrund der Header abgelehnt wird.Aufbauend auf StAX wurde für Axis2 ein leichtgewichtiges Objektmodell namens Axiom entwickelt, welches Zugriff auf die einzelnen Nachrichteninhalte bietet. Da Axiom natürlich kein standardisiertes API darstellt, wird es darauf aufbauend eine dünne Adapterschicht geben, die zu JAX-WS 2.0 (früher JAX-RPC) konform ist. Allein der Umstieg von DOM auf Axiom brachte nach Aussagen der Entwickler deutliche Verbesserungen hinsichtlich Geschwindigkeit und Speicherverbrauch gegenüber Axis 1.x.Die bereits aus Axis 1.x bekannten Handler werden in Axis2 in Phases eingeklinkt, die unterschiedliche Phasen der Nachrichtenverarbeitung darstellen. In diesem Zusammenhang können Regeln definiert werden, die beschreiben, in welcher Phase ein Handler an welcher Position beheimatet sein soll. Beispielsweise könnte man definieren, dass ein Handler A immer an erster oder an letzter Stelle innerhalb einer Phase aktiviert werden oder immer vor Handler B an der Reihe sein soll, sollte dieser ebenfalls installiert sein. Eine oder mehrere Handler-Klassen werden gemeinsam mit dem Regeldokument zu Modulen zusammengefasst (Dateiendung .mar) und dann als Axis-Erweiterung auf einfache Weise installiert. Die Verknüpfung von Handlern und Modulen mit in Betrieb genommenen Services erfolgt dann über die gegenüber Axis 1.x deutlich erweiterte Webschnittstelle.Services selbst werden künftig ebenfalls paketiert, und zwar in sog. Service Archive Files. Die Inbetriebnahme erfolgt dann durch Hochladen des Service-Archivs über die Webschnittstelle von Axis2. Manuelles Kopieren der Klassen entfällt also künftig.Weitere neue Features sind verbesserter Support für asynchrone Kommunikation und beliebige MEPs (Message Exchange Patterns), REST- und MTOM-Support, und nicht zuletzt einige Eclipse-Plug-ins zur Unterstützung bei der Entwicklung. Außerdem gibt es ein neues Client API und der Code-Generator für Client Proxies soll eines Tages sogar .NET-Code erzeugen können.

Geschrieben von
Thilo Frotscher
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.