Web Services mit Spring-WS – Teil 3

Spring-WS und Spring Security

Thorsten Kamann

Die beiden ersten Teile dieser Artikelserie befassten sich mit der Implementierung von Web Services. Als Client kam bisher nur SoapUI zum Einsatz, ein richtiger Client fehlt uns noch. Mit diesem Thema beschäftigt sich jetzt der letzte Teil. Zusätzlich werfen wir gemeinsam einen Blick auf die Themen Sicherheit und Test.

In den bisherigen Teilen dieser Serie haben wir gemeinsam einen Web Service entwickelt. Im ersten Teil haben wir dafür den JDomPayloadEndpoint verwendet, d. h. die Implementierung war sehr nah an XML und dem SOAP-Body. Für einfache Web Services, die mal eben schnell implementiert werden sollen, ist das völlig ausreichend. Eine andere Möglichkeit haben wir im zweiten Teil genutzt. Mit JAXB2 [3] haben wir uns aus dem zugrunde liegenden XML Schema ein Java-basiertes API generieren lassen und damit den Web Service entwickelt. Der Vorteil hierbei ist, dass wir nicht mehr mit XML oder SOAP direkt in Berührung kommen.

Der Web Service

Als Beispiel für diese Artikelserie dient ein einfacher Services, der eine Liste von Produkten (Products) zurückliefert, die in einem bestimmten Zeitraum geliefert wurden. Die Anfrage enthält Informationen über die Warengruppe (Category), den Lieferanten (Supplier) und einen Datumsbereich (DateRange).

Ein einfacher Client

Das Spring Framework bietet ein einheitliches Programmiermodell, das wiederum als Abstraktionsschicht zu Frameworks ein so genanntes Template anbietet. Das sind üblicherweise eine oder mehrere Java-Klassen, von denen man erben kann und die die Verwendung vereinfachen, indem sie viel Komplexität verstecken. So auch bei Spring-WS: Es gibt das WebServiceTemplate, das genutzt werden kann, ohne einen Spring-Kontext aufzubauen. Dieses Feature verwenden wir jetzt in einem einfachen Client. Das WebServiceTemplate bietet einige Methoden an, die für den Konsum von Web Service geeignet sind. Es gibt eine Reihe von sendSourceAndReceive*-Methoden. Eine dieser Methoden machen wir uns zunutze, indem wir den Request als XML an den Web Service senden und den XML-Response als Antwort zurückbekommen. Die einzige Angabe, die wir für Spring-WS machen müssen, ist der URI, unter dem der WebService erreichbar ist (Listing 1).

Listing 1

public class ProductServiceClient {
 private final WebServiceTemplate webServiceTemplate;

 public static void main(String[] args){
  new ProductServiceClient().simpleSendAndReceive();
 }
 
 public ProductServiceClient(){
  webServiceTemplate = new WebServiceTemplate();
  webServiceTemplate.setDefaultUri(
      "http://localhost:8080/articles-spring-ws-dom/productService/");
 }

    public void simpleSendAndReceive() {
        StreamSource source = 
   new StreamSource(getClass().getResourceAsStream(
       "/ProductServiceRequest.xml"));
        StreamResult result = new StreamResult(System.out);
        webServiceTemplate.sendSourceAndReceiveToResult(source, result);
    }
}

Der benötigte Code für einen Client reduziert sich mit dem Template auf ein Minimum. Allerdings muss das XML für den Request selbst erstellt werden. Dazu erhalten Sie erst einmal keine Hilfe, aber das XML Schema (aus Teil 1, das den Web Service beschreibt) gibt die Struktur dazu vor (Listing 2).

Listing 2

2Toys3Toys and more LTD.02-01-201002-28-2010

Der Response besteht auch aus XML. Listing 3 zeigt die Antwort aus dem Request aus Listing 2. Sie müssen die Daten jetzt selbst verarbeiten. U. U. artet das in aufwändiger XML-Verarbeitung aus. Falls Sie vermeiden wollen, viele neue Anhängigkeiten in Form von Unmengen von JARs in ihrem Projekt zu bekommen, ist das eine pragmatische Lösung, da Sie sich hierfür lediglich die Spring-WS-Abhängigkeit einhandeln.

Listing 3

Product1Toys and more LTD.ToysProduct2Toys and more LTD.Toys
Geschrieben von
Thorsten Kamann
Kommentare

Schreibe einen Kommentar

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