Gerippe für Java-Seifenkisten

Frameworks zur Entwicklung von SOAP Web Services

Bernhard Löwenstein

Durch den Einsatz leistungsfähiger Frameworks kann sich der Java-Programmierer seine mühevolle Arbeit deutlich erleichtern. Zur Entwicklung von SOAP Web Services und zugehöriger Clients existieren ebenfalls solche Systeme. Der Artikel stellt dazu die bedeutendsten Vertreter vor.

Enterprise Java Web Services

Die Serie „Enterprise Java Web Services“ ist erstmals im Java Magazin erschienen und umfasst vier Teile:

In den ersten beiden Teilen dieser Artikelserie beschäftigten wir uns mit den Java-Web-Services-Standards und lernten JAX-WS (Java API for XML-based Web Services) [1] und JAX-RS (Java API for RESTful Web Services) [2] kennen. Dieses Mal stehen Frameworks im Mittelpunkt, die dem Entwickler bei der Realisierung von SOAP Web Services sowie Clients hilfreich sind. Im Zentrum unserer Betrachtungen stehen dabei vorrangig die über den Standard hinausgehenden Funktionalitäten dieser Rahmenwerke. Eines folgt überhaupt einem gänzlich davon abweichenden Ansatz.

Tabelle 1: Die Eckdaten der bedeutendsten Java-Frameworks zur Entwicklung von SOAP Web Services

Name Version Community Website Lizenz JAX-WS
Apache Axis2 1.5.4 Apache http://axis.apache.org/axis2/java/core/ ASL 2.0 Ja (fast)
Apache CXF 2.4.0 Apache http://cxf.apache.org ASL 2.0 Ja
Metro 2.1 Java.net http://metro.java.net CDDL 1.1
GPL 2 with CPE
Ja
Spring-WS 2.0.2.RELEASE Spring http://static.springsource.org/spring-ws/sites/2.0/ ASL 2.0 Nein
Begleitendes Beispiel: Kalkulator

Die praktische Vertiefung erfolgt anhand des einfachen Berechnungsdienstes aus dem ersten Artikel. Lassen Sie uns deshalb nochmals einen Blick auf dessen Funktionen sowie das damals mit JAX-WS umgesetzte SEI (Service Endpoint Interface) werfen (Listing 1):

  • Addition zweier Zahlen
  • Division zweier Zahlen
  • Anmeldung bei einem mathematischen Newsletter
  • Überprüfung einer Zahl auf Primzahleigenschaft
Listing 1
...
@WebService
public interface CalculatorWS {
  public long sum(long a, long b);
  public double div(double a, double b) throws CalculatorException;
  public void subscribeToNewsletter(User user);
  public boolean isPrimeNumber(String number) throws CalculatorException;
}

Noch ein Hinweis: Sollten im Folgenden Codebeispiele für Handler beziehungsweise Interceptors angeführt werden, bewirken diese stets die Ausgabe der empfangenen SOAP-Nachricht auf der Standardkonsole.

Apache Axis2

Axis2 folgte im Jahr 2005 der weit verbreiteten Erstversion. Es basiert auf einer neuen Architektur, die eine flexible Erweiterung über Module erlaubt. Neben SOAP Web Services auf Basis einer fast kompatiblen JAX-WS-Implementierung lassen sich mithilfe dieses Frameworks auch eingeschränkte RESTful Web Services erstellen. Sowohl Code First als auch Contract First sind denkbar. Auf der Website befinden sich Plug-ins für unterschiedliche Programmierumgebungen und Build-Werkzeuge. Des Weiteren kann man von dort Module beziehen, die verschiedene WS*-Features implementieren. So setzt z. B. Rampart die Spezifikation von WS-Security um.

Zur Entwicklung von Web Services bietet Axis2 seinem Nutzer ein alternatives Programmiermodell, das deren Realisierung in Form von einfachen Klassen erlaubt. Auf Interfaces und Annotationen kann er dabei vollends verzichten. Dafür muss er die Webdienste unter META-INF/services.xml entsprechend konfigurieren (Listing 2). Bei Bedarf kann er dort noch jede Menge weitere Einstellungen vornehmen. Für die Auslieferung muss er die kompilierten Klassen und die Konfigurationsdatei in ein Java-Archiv mit der Endung .aar packen.

Listing 2

    de.javamagazin.calculator.CalculatorWS
  

Mit ADB (Axis Data Binding), JAXB (Java Architecture for XML Binding), JiBX und XML Beans stehen dem Entwickler einige gängige Data-Binding-Frameworks zur Wandlung der Daten von XML nach Java und zurück zur Verfügung.

Entscheidet er sich gemäß Contract First vorzugehen, kann er sich vom Tool wsdl2java einen Web Services Skeleton generieren lassen, den er anschließend mit sinnvollen Befehlen zu füllen hat. Die Konfiguration und Archivierung unterscheidet sich verglichen mit vorhin nicht.

Ein eigenes Interceptor-Konzept hat Axis2 ebenfalls zu bieten, wenngleich in diesem Zusammenhang von Handlern gesprochen wird. Sie ermöglichen dem Nutzer, sich sowohl client- als auch serverseitig vor und nach dem eigentlichen Dienstaufruf in den Verarbeitungsprozess einzuhängen (Abb. 1). Auf diese Art kann er den Nachrichteninhalt auswerten und manipulieren, bei Bedarf sogar die Weiterleitung ganz unterbinden. Jede SOAP-Nachricht durchläuft bei Axis2 eine Pipeline. Die Handler lassen sich per Konfiguration einer bestimmten Phase zuteilen, wobei neben den vorgegebenen Systemphasen auch eigene definierbar sind. Implementierungstechnisch handelt es sich bei Handler um Klassen, die entweder das Interface org.apache.axis2.engine.Handler implementieren oder von der abstrakten Klasse org.apache.axis2.handlers.AbstractHandler beziehungsweise einer Unterklasse abgeleitet sind (Listing 3). Sie werden in kompilierter Form inklusive der Konfigurationsdatei META-INF/module.xml als Java-Archiv mit der Endung .mar ausgeliefert. In Axis2 spricht in diesem Zusammenhang von Modulen. Und so schließt sich der Kreis zu vorhin, d. h. die von Axis2 bereitgestellten Module sind allesamt bloß Archivdateien, die Handler enthalten.

Abb. 1: Bei Apache Axis2 kann man sich mittels Handler in den Verarbeitungsprozess einhängen
Listing 3
...
public class MyLoggingHandler extends AbstractHandler {
  @Override
  public InvocationResponse invoke(MessageContext context) throws AxisFault {
    System.out.println("Message: " + context.getEnvelope());
    return InvocationResponse.CONTINUE;
  }
}

Das Ausrollen der Web Services geschieht in Form einer Webapplikation. Das hat den Vorteil, dass sich die Dienste mit jedem Servlet-Container hochziehen lassen. Ein entsprechendes Gerüst für eine solche Webanwendung liegt dem Axis2-Release bei. Ihr kommt aber nicht nur die Aufgabe eines Containers zu, sie stellt zusätzlich eine Verwaltungsoberfläche im Browser bereit. Das Servlet org.apache.axis2.transport.http.AxisServlet dient als Front Controller. Die Konfiguration erfolgt standardmäßig unter WEB-INF/conf/axis2.xml. Neben den gängigen Verzeichnissen enthält eine Axis2-Webapplikation noch zwei zusätzliche Ordner: WEB-INF/modules und WEB-INF/services. In den ersten Ordner kopiert der Entwickler die Module (*.mar), in den zweiten die Services (*.aar). Darüber hinaus liefert das Framework einen eigenständig ausführbaren Server mit.

Mithilfe der Klasse org.apache.axis2.client.ServiceClient beziehungsweise einer Unterklasse lässt sich auf einen Web Service zugreifen. Dem Nutzer stehen dabei unterschiedliche Aufrufmethoden zur Verfügung, die sich an den MEPs (Message Exchange Pattern) orientieren. Es gibt nun keine Hindernisse mehr für eine asynchrone Operationsausführung auf programmatischem Weg (Listing 4). Wer es komfortabler mag, erstellt sich mit dem Tool wsdl2java einen statischen Client-Stub und nutzt diesen zum Dienstaufruf.

Listing 4
Options options = new Options();
options.setTo(new EndpointReference("http://localhost:8080/axis2/services/CalculatorWS"));

RPCServiceClient client = new RPCServiceClient();
client.setOptions(options);

QName operation = new QName("http://calculator.javamagazin.de", "isPrimeNumber");
Object[] parameters = new Object[] {"78787"};

client.invokeNonBlocking(operation, parameters, new AxisCallback() {
  @Override
  public void onMessage(MessageContext context) {
    SOAPBody body = context.getEnvelope().getBody();
    System.out.println("Result: " + body.getFirstElement().getFirstElement().getText());
  }
  ...
});
Geschrieben von
Bernhard Löwenstein
Kommentare

Schreibe einen Kommentar

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