Aus dem Nähkästchen geplaudert

Ein Einblick in meinen Projektalltag mit Apache Axis2 und Eclipse

Marc Teufel

Apache Axis2 ist mittlerweile sehr gut dokumentiert. Und Eclipse noch viel mehr. Daher möchte ich diesen „My Personal Eclipse“-Artikel nutzen, um einmal aufzuzeigen, wie ich beide Tools in der Praxis einsetze. Ich möchte Einblick in meinen täglichen Projektalltag mit Axis2 und Eclipse geben und zeigen, wie ich meine Web Service-Projekte aufbaue und mit welchen Hilfsmitteln ich arbeite, um den Axis2-Quelltext, den man oft genug sichten muss, zu verstehen.

Eclipse und Apache Axis2 lassen sich wunderbar miteinander verwenden. Anfangs benutzte ich noch die Eclipse Web Tools Platform (WTP), um meine Web-Service-Projekte umzusetzen. Mittlerweile bin ich jedoch dazu übergegangen, sämtliche Projekte gänzlich ohne WTP zu entwickeln. Das heißt aber nicht, dass ich WTP für schlecht halte, ich habe lediglich für mich festgestellt, dass es in manchen Fällen von Vorteil ist, sowohl Entwicklungsumgebung als auch Projektstruktur möglichst schlank zu halten.

In der Firma verwenden wir Apache Axis2, um eine Anbindung unserer in .NET geschriebenen Pocket-PC-Anwendungen an unsere Oracle-Datenbank samt Stored Procedures zu ermöglichen. Dabei gibt es pro Pocket-PC-Anwendung ein Web-Service-Projekt, welches wiederum in Form eines AAR-Files (Axis Archive) in der Axis2-Webanwendung auf einem Tomcat installiert ist. Angesprochen werden unsere Web Services derzeit über das Transportprotokoll HTTP, derzeit evaluieren wir jedoch einen Umstieg auf TCP. Im Folgenden möchte ich kurz beschreiben, wie wir unsere Web-Services-Projekte bauen und wie wir uns Eclipse zunutze machen, um den Axis2-Quellcode zu analysieren.

Simpel muss es sein!

Ein neues Axis2-Projekt beginnen wir mit dem Anlegen eines simplen Java-Projekts in Eclipse. Dabei hat es sich eingebürgert, separate Ordner für Quellen und Kompilate („Create separate source and output folders“) zu erstellen, damit sich nachher unser Ant-Build-Skript aus diesen beiden Ordnern entsprechend bedienen kann. Wer bereits einen Web Service mit Axis2 entwickelt hat, wird wissen, dass zum Deployment eines ebensolchen Services dringend ein so genannter Web Service Deployment Descriptor benötigt wird. Diese Datei, die (zumindest in unseren Projekten) stets den Namen services.xml trägt, legen wir ins src-Verzeichnis.

Im nächsten Schritt legen wir das bereits erwähnte Ant-Build-Script build.xml an, das eigentlich immer die gleiche Struktur hat. Dieses Build-Script verwenden wir, um mit einfachsten Ant-Befehlen das AAR-File zu erstellen, welches schließlich in die Axis2-Webanwendung deployt wird. In Listing 1 sieht man dieses Ant-Script und auf den ersten Blick schon sollte klar werden, dass auch dieses sehr einfach und knapp gehalten ist. Es gibt lediglich zwei Targets: einen zum Erzeugen der AAR-Struktur und einen, welcher schließlich diese Struktur in ein Archiv packt.

Zum Schluss wird das erzeugte AAR-File noch an eine bestimmte Stelle im File-System kopiert. Fertig. Das war sie auch schon, die Grundstruktur mit der wir in Eclipse unsere Axis2 Web Services entwickeln. Apropos entwickeln, eigentlich könnte es ja jetzt losgehen mit dem Schreiben neuer, bahnbrechender Web Services. Doch irgendwie benötigt man dabei immer irgendwelche Bibliotheken Dritter. Einen JDBC-Treiber von Oracle zum Zugriff auf die Datenbank zum Beispiel. Oder das Spring Framework, um mittels Spring JDBC auf einfachste Weise Stored Procedures aufzurufen. Oder gar das Axis2-Framework selbst, wenn man zum Beispiel eigene Message Receiver implementieren möchte.

Um solche Bibliotheken dem Projekt bekannt zu machen, benutzen wir in unseren Projekten das nette Eclipse-Feature der so genannten User Libraries. Verwaltet werden diese User Libraries im Preferences-Dialog im Menü WINDOW | PREFERENCES… und dort im Bereich JAVA | BUILD PATH | USER LIBRARIES (Abb. 1). Man hat hier die Möglichkeit, beliebig viele User Libraries anzulegen und jeder einzelnen Library beliebig viele JAR-Files zuzuordnen. So gibt es bei uns prinzipiell separate User Libraries für Axis2 und den Oracle JDBC-Treiber. Über die Eigenschaften eines Projekts kann man dann diese User Libraries zum Buildpath des entsprechenden Projekts hinzufügen. Vorteil dieser Vorgehensweise ist, dass die sonst üblichen lib-Verzeichnisse in den einzelnen Projekten entfallen, im CVS oder Subversion Libraries nicht mehr redundant gehalten werden und außerdem durch Austauschen einer User Library sehr leicht Releases gewechselt werden können.

Die Migration unserer Projekte von Axis2 1.0 auf Axis2 1.1 bestand somit nur darin, die entsprechende User Library auszutauschen, hätte etwas nach dem Umstieg nicht funktioniert, wäre ein Wechsel zurück zur alten Version innerhalb kürzester Zeit möglich gewesen. Damit alle Entwickler mit den gleichen User Libraries arbeiten können, gibt es bei uns ein globales „jarlib“-Projekt in dem sämtliche JAR-Files für die einzelnen User Libraries abgespeichert sind. Dieses Projekt ist dann selbstverständlich auch in der Quellcodeverwaltung eingecheckt.




includes=“**/*.*“
excludes=“*.xml“/>



includes=“services.xml“/>










Abb. 1: Mit User Libraries kann man oft benutzte Bibliotheken einfach zusammenfassen und wieder verwenden.

Abbildung 2: Einfacher geht’s nicht: Die Grundstruktur unserer Projekte für neue Web Services
Diving into the Sources!

Bei Apache Axis2 handelt es sich um ein Open-Source-Projekt, bei dem auch die Sourcen bezogen und eingesehen werden können. Diese Tatsache wird oft als einer der größten Vorteile von Open Source genannt, denn bietet sich hier die doch Gelegenheit, bei Problemen einfach in den Quelltext zu sehen und das Problem zu „fixen“. Tatsächlich ist das aber leichter gesagt als getan. Denn das Einarbeiten in „fremden“ Quelltext ist nicht leicht. Gerade bei Projekten, die in objektorientierten Programmiersprachen wie Java geschrieben sind, die aus Unmengen von Klassen bestehen und durch das Package-System von Java in einer schier endlosen Verzeichnisstruktur ausarten, ist es schwer, den Überblick zu behalten.

Bei der Analyse von solch umfangreichen Projekten ist der Entwickler daher auf Tool-Unterstützung angewiesen. Diese Unterstützung erhält man – wie soll es anders sein – natürlich mit Eclipse, denn mit Eclipse ist es ein Leichtes, Quelltexte zu analysieren, ja durch sie zu browsen und zu debuggen. Als Quelle dient dabei das Verzeichnis mit den Sourcen oder ein ZIP oder JAR, in dem alle Sourcen enthalten sind. So ist es in den meisten Fällen möglich, die Source-Distribution einer bestimmten Open-Source-Software herunterzuladen und diese direkt in Eclipse zu verwenden. Dies gilt auch für Apache Axis2.

Den Quelltext sichten und browsen

Am besten beginnt man damit, sich über den Open-Type-Dialog der über die Tastenkombination STRG + UMSCHALT + T erreichbar ist, beispielsweise die Klasse RPCServiceClient in den Editor zu holen. Nachdem man im Dialog den Klassennamen eingetragen hat, versucht Eclipse die entsprechende Klasse im Quelltexteditor anzuzeigen. Findet Eclipse keinen Source, zeigt es nur die Methoden-Signaturen der Klasse an. In dieser Ansicht gibt es dann jedoch mit dem Knopf ATTACH SOURCE… die Möglichkeit, das ZIP mit den Sourcen einzubinden, aus dem Eclipse sich dann den entsprechenden Quelltext ziehen und anzeigen kann. Es ist wichtig zu verstehen, dass die Sourcen – wenn einmal ausgewählt – nicht automatisch für alle Klassen aus Axis2 zur Verfügung steht, sondern nur für die Klassen innerhalb des jar-Files, in dem sich die Klasse befand, für die der letzte Quelltext angefordert wurde.

Das liegt daran, dass Eclipse pro jar-File im Buildpath die Source-Information als so gennantes Source-Attachment hinterlegt. Die Axis2-Klasse BeanUtil befindet sich zum Beispiel innerhalb des jar-Files axis2-adb.jar. Innerhalb der User-Library-Konfiguration kann man sehen, für welche jar-File Source-Attachments hinterlegt sind. Abbildung 3 zeigt, dass für dieses jar-File die Sourcen vorliegen, folglich wird Eclipse den Quelltext anzeigen können. Die Klasse OMElement jedoch befindet sich im Archiv axiom-api-1.2.jar, da hierfür kein Source-Attachment vorliegt, wird Eclipse hier keine Quellen finden können und folglich wieder die Ansicht mit den Methodensignaturen solange anzeigen, bis auch hier ein Source-Attachment vorliegt.

Abb. 3: Für alle Klassen aus axis2-adb-1.1.jar wird Eclipse Sourcen finden, in axiom-api-1.2.jar jedoch nicht, weil hier kein Source-Attachment vorliegt.
Ein paar Tastenkombinationen

Während der täglichen Arbeit im eigenen Code, aber auch im beim Browsen der Quellen von Axis2 gibt es eine Reihe nützlicher Tastenkombinationen in Eclipse, die sehr hilfreich sein können. Da wäre zum Beispiel die Tastenkombination STRG + O zu nennen, sie zeigt ein kleines, gelbes Fenster an, in dem eine „Outline“ der gerade aktiven Klasse dargestellt wird. Damit hat man die Möglichkeit, sich auf der einen Seite einen schnellen Überblick über die Konstanten, Felder und Methoden der Klasse zu verschaffen und auf der anderen Seite aber auch ein äußerst bequemes Navigationsmittel, um mittels der Cursor-Tasten schnell zu einer bestimmten Stelle innerhalb einer Klasse zu springen. Ebenfalls interessant ist auch die Tastenkombination STRG + T. Diese zeigt die Vererbungshierarchie einer Klasse an. Auch hier besteht die Möglichkeit, sehr leicht mittels Cursor-Tasten in der Vererbungshierarchie zu navigieren, um so beispielsweise ganz schnell in die Klasse ServiceClient zu springen, von der sich RPCServiceClient ableitet.

Sogar ein „Browsen“ im Axis2-Quelltext ist möglich. Hält man die STRG-Taste gedrückt und fährt mit der Maus im Editor über einen beliebigen Klassen-Namen, so ändert sich seine Darstellung dahingehend, dass dieser unterstrichen dargestellt ist. Der Klassenname wird dann zu einer Art Link, ein Mausklick führt sofort in den Quelltext der angeklickten Klasse. Mit diesen Hilfsmitteln lassen sich auch umfangreiche Java-Projekte sehr leicht analysieren und bearbeiten.

Axis2-Quelltext erforschen mit Eclipse – ein kleines Beispiel

Natürlich kann man auch direkt in den Axis2-Quelltext hineindebuggen. Es ist gängige Praxis, im Rahmen einer Debug-Session zu analysieren, welche Klassen und Methoden innerhalb von Axis2 aufgerufen werden, wenn beispielsweise ein SOAP Request eingeht.

Alles was man für eine erfolgreiche Analyse wissen muss, ist, welches die Einsprungsklasse ist, bei der man mit dem Debugging ansetzt. Wenn man einen SOAP-Request verfolgen will, ist das relativ einfach, denn solche Requests werden bei Verwendung der Axis2-Webanwendung immer von einem Servlet entgegengenommen. Also kann man über die web.xml der Axis2-Webanwendung herausfinden, dass der Breakpoint in der Klasse org.apache.axis2.transport.http.AxisServlet gesetzt werden muss, daher sollte man sich diese nun mittels Tastenkombination STRG + UMSCHALT + T in den Editor laden. Bei genauerer Betrachtung des Quellcodes fällt zunächst auf, dass es sich um ein gewöhnliches Servlet handelt, welches HttpServlet erweitert und somit also die typischen doGet– und doPost-Methoden enthält. Man sieht außerdem, dass AxisServlet das Interface org.apache.axis2.transport.TransportListener implementiert, dessen Quellcode gesichtet werden kann, in dem man in der Klasse AxisServlet den Cursor mit gerückter STRG-Taste über den Namen des Interfaces bewegt. Im Quelltext dieses Interfaces schließlich angekommen, bringt die Tastenkombination STRG + T eine Baumstruktur auf den Schirm, in der man auf einen Blick erkennen kann, welche Klassen dieses Interface implementieren. Darunter findet sich natürlich auch das AxisServlet. Mit den Cursor-Tasten kann man sich innerhalb dieser Ansicht bewegen und hat so die Möglichkeit wieder in den Source von AxisServlet zu wechseln. Wieder zurück im AxisServlet könnte das Erforschen des Axis2-Quelltext jetzt weitergehen, in dem man zunächst in die Methode doPost springt, wo die SOAP Requests ankommen werden und in dieser einen Breakpoint setzt und eine Debug-Session beginnt.

Das war’s! Ich habe ein bisschen aus meinem Projektalltag erzählt und gezeigt, wie wir Eclipse einsetzen, um Axis2 zu programmieren. Die Vorgehensweisen, die ich in diesem Rahmen geschildert habe, sind allerdings nur ein möglicher Weg von vielen und sie nehmen für sich auf keinen Fall in Anspruch, das Maß aller Dinge zu sein. Das soeben besprochene Thema hat sich eben für mich als praktikabel herausgestellt und ist somit „My Personal Eclipse“.

Marc Teufel ist Softwareentwickler bei hama und beschäftigt sich hier mit Oracle, Java, Eclipse RCP und natürlich Axis2. Er ist Autor zahlreicher Fachartikel zu Java und .NET und außerdem einer der Autoren von „Java Web Services mit Axis2“ welches demnächst bei entwickler.press erscheinen wird.

Geschrieben von
Marc Teufel
Kommentare

Schreibe einen Kommentar

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