JAXenter.de

Das Portal für Java, Architektur, Cloud & Agile
X

#Docker-Woche auf JAXenter: Top-Artikel, Tutorials & Videos in unserem Docker-Special!

Teil 3: Axis2 und Spring

Axis2 und Spring zusammenbringen

Marc Teufel

Axis2 ist unabhängig von Spring. Um diese beiden Technologien nun unter einen Hut zu bringen, gibt es in der Praxis mindestens drei unterschiedliche Integrationsoptionen. Der vorliegende Artikel stellt die verschiedenen Möglichkeiten vor.

Axis2-Serie:

Teil 1: Bleibt alles anders?

Teil 2: Happy JAX-WS-ing!

Teil 3: Axis2 und Spring

Mit Spring liegt ein vielfach praxiserprobtes Framework zum Bauen von Enterprise-Anwendungen vor, das sich vorrangig mit Dependency Injection (DI), beziehungsweise Inversion of Control (IoC), Template-Klassen und aspektorientierter Programmierung befasst.

Dependency Injection, Template-Klassen und AOP

In der klassischen objektorientierten Programmierung ist jedes Objekt selbst dafür zuständig, abhängige Objekte und Ressourcen zu erzeugen und zu verwalten. Motivation des "Inversion of Control"-Patterns ist es nun, diese Verwaltung an ein externes Framework (Spring) abzugeben, das für Objekterzeugung und Auflösung von Abhängigkeiten zuständig ist. Bei der Erzeugung eines Objekts werden die abhängigen Objekte dabei über entsprechende Setter-Methoden (oder über den Konstuktur, in Spring ist beides möglich) im wahrsten Sinne des Wortes injiziert. Daher auch der Begriff "Dependency Injection" (DI). In Spring werden so verwaltete Objekte "Spring Beans" genannt. Die Verwaltung erfolgt entweder über eine XML-Konfiguration oder über Annotationen. Liegt eine Konfiguration vor, so erzeugt Spring einen so genannten Application Context, von dem über bestimmte Methoden das Objekt, das man gerade braucht, einfach abgeholt werden kann. Dieser Mechanismus kann demnach auch als Fabrik verstanden werden, die Objekte samt ihrer Abhängigkeiten erzeugt (instanziiert) und fertig zum Einsatz bereitstellt.

Über den IoC-Container hinaus liefert Spring viele nützliche Hilfsklassen, die die Anwendung diverser APIs im Java-Umfeld vereinheitlichen und stark vereinfachen. Gemeinsam haben alle diese Klassen, dass der Klassenname meist auf Template endet. Typische Template-Klassen sind beispielweise JdbcTemplate für den Datenzugriff oder JmsTemplate für den Umgang mit JMS. Charakteristisch bei allen Templates ist eine möglichst einheitliche Klassenstruktur und gleiche Bedienung. Schließlich bietet es sich immer an, Template-Klassen in Verbindung mit Dependency Injection zu verwenden.

Das dritte Standbein von Spring stellt der Bereich der aspektorientierten Programmierung (AOP) dar. Mit AOP kann der Entwickler Code in Klassen "einweben" (Codeweaving), und ihn dann zu einem bestimmten Zeitpunkt ausführen. Vergleichen kann man dieses Konzept mit dem aus Datenbanken bekannten Triggern: So wie in einer Datenbank etwa ein Trigger definiert werden kann, der eine Stored Procedure ausführt, sobald in einer bestimmten Tabelle eine neue Zeile eingefügt wird, so kann im Rahmen von AOP Programmcode (so genannte Aspekte) mithilfe eines speziellen Compilers vor oder nach dem Aufruf einer Methode eingewebt und ausgeführt werden.

Spring-WS

Um das Spring Framework herum entwickelten sich in den letzten Monaten zahlreiche Nebenprojekte, die viele Ideen und Konzepte aus Spring in ihre eigene Domäne transferieren. Prominente Beispiele sind etwa Spring Dynamic Modules, Spring Web Flow und Spring Security. Und auch im Bereich der Web Services bemüht sich das Spring-Ökosystem um Lösungen: So ist für das nächste große Release des Spring Frameworks umfassende Unterstützung für REST vorgesehen, und mit dem separaten Projekt Spring-WS steht ein komplettes Framework zur Entwicklung von Web-Service-Anwendungen bereit. Es stellt sich also zunächst einmal ganz berechtigt die Frage, warum man Axis2 überhaupt mit dem Spring Framework verbinden soll, wenn doch mit Spring-WS eine Alternative zu Axis2 besteht?

Zunächst einmal ist festzuhalten, dass sich Spring-WS naturgemäß gut ins Spring-Universum einfügt. Von der Architektur her ist Spring-WS dabei ähnlich Spring MVC aufgebaut. In Letzterem gibt es beispielsweise ein DispatcherServlet, das Anfragen direkt an Controller-Klassen weiterleitet. In Spring-WS gibt es analog dazu ein MessageDispatcherServlet, das entscheidet, an welchen Endpoint eine bestimmte Nachricht geleitet werden soll. Die Konfiguration erfolgt bei Spring-WS selbstverständlich über den üblichen Application Context.

Beim Entwickeln von Web Services unterscheidet sich Spring-WS dann aber ganz deutlich von anderen WS-Frameworks. So ist es z.B. nicht möglich, Web Services auf Basis von "Code First" zu entwickeln. Man setzt stattdessen voll und ganz auf "Contract First", weicht aber selbst hier von der üblichen Vorgehensweise ab. Während beim klassischen "Contract First" zunächst XML-Schema und WSDL-Dokument zu erstellen sind, aus dem über Codegenerierung dann entsprechende Skeletons für die eigentliche Web-Service-Implementierung erzeugt werden, verzichtet Spring-WS auf das WSDL-Dokument. Es ist also lediglich ein XML-Schema zu erstellen, in dem Datentypen und Nachrichten modelliert sind. Das WSDL wird dann später auf Basis von diesem Schema, der Service-Implementierung und der Konfiguration zur Laufzeit erstellt.

Spring-WS ist ein nachrichtenorientiertes WS-Framework, dementsprechend vielfältig sind hier auch die Möglichkeiten bei der XML-Verarbeitung und dem XML-Data Binding. Im Gegensatz zu Apache Axis2 besitzt Spring-WS jedoch deutlich weniger Features und ist auch bei weitem nicht so erweiterbar. Auch die Tatsache, dass man in ein bestimmtes Programmierparadigma (kein "Code First", eigenwillige "Contract First"-Umsetzung) gezwungen wird, ist gewöhungsbedürftig. Bei der Unterstützung moderner WS-Standards hinkt Spring-WS ebenfalls hinterher. So gibt es derzeit keine Möglichkeit, WS-Policy einzusetzen, oder Web Services auf Basis des allgemeinen Standards JAX-WS zu entwickeln.

 
Verwandte Themen: 

Kommentare

Ihr Kommentar zum Thema

Als Gast kommentieren:

Gastkommentare werden nach redaktioneller Prüfung freigegeben (bitte Policy beachten).