Zur Zeit befasse ich mit mit der Realisierung von WebServices mit JBossWS in einem JBoss AS 4.2.3.GA. Hier möchte ich kurz zusammenfassen, was ich beachtet habe und wie ich bei der Service-Implementierung vorgegangen bin.

JBoss AS und Java6

Betrieben wird ein JBoss AS 4.2.3.GA (und ein 4.2.2.GA; Java 5 compiled binaries) in einer Java 6 Umgebung. Auf die Gründe, wesghalb kein JBoss AS 5.x eingesetzt wird möchte ich nicht näher eingehen und wir nehmen die Umgebung als gegeben hin. In dieser Umgebung gilt es allerdings folgenden Konfigurationshinweis aus der 4.2.3.GA Distribution zu beachten, die analog für Version 4.2.2.GA gilt:

JBossAS 4.2.3.GA can be compiled with both Java5 & Java6. The Java5 compiled binary is our primary/recommended binary distribution. It has undergone rigorous testing and can run under both a Java 5 and a Java 6 runtime. When running under Java 6 you need to manually copy the following libraries from the JBOSS_HOME/client directory to the JBOSS_HOME/lib/endorsed directory, so that the JAX-WS 2.0 apis supported by JBossWS are used:

  • jboss-jaxrpc.jar
  • jboss-jaxws.jar
  • jboss-jaxws-ext.jar
  • jboss-saaj.jar
  • jaxb-api.jar

JAX-WS und JAX-RPC

“JAX-WS” und “JAX-RPC” laufen einem immer wieder über den Weg, sobald man sich mit WebServices in der Java-Welt beschäftigt. Anfangs stellte sich mir die Frage, was sich hinter diesen Begriffen verbirgt und was dabei der Unterschied ist. Ich fand hierzu einen interessanten Artikel von Vamshi Rapolu in dessen Blog und ich verzichte an dieser Stelle näher auf die Beantwortung meiner Frage einzugehen. Weitere Informationen findet der interessierte Leser in diesem Artikel und sicherlich auch über die Suchmaschine seines Vertrauens.

Warum nicht Axis2?

Warum ich mich für JBossWS als WebService Framework entschieden habe und nicht für Apache Axis2 hat folgende Gründe:

Axis2 eignet sich vor allem für den Einsatz in einem Servlet-Container wie z.B. einem Apache Tomcat – ohne den Rattenschwanz eines Applikationsservers wie dem JBoss (Was ist der Unterschied?). Axis2 wird einfach als eigenständige Applikation “deployed” und steht danach als WebService-Container zur Verfügung, in den wiederum die Services “deployed” werden. Für meine Zwecke war dies eher ungeeignet, da sich der WebService zusammen mit anderen Applikationskomponenten in einem *.ear-Archiv veröffentlicht werden soll. Zwar gibt es Wege auch Axis2 als weitere Applikationskomponente in das Archiv zu packen, doch das erschien mir alles irgendwie “zusammengeflickt”. Außerdem bringt der JBoss AS selbst ein WebService-Framework mit: JBoss WS. Und warum soll man nicht auf vorhandenes zurückgreifen? Ein weiterer Vorteil ist, dass WebServices direkt mit EJB3 Stateless Session Beans implemntiert werden können und innerhalb des Services per Dependency Injection auf vorhandene EJBs zugegriffen werden kann. Dies war schließlich ausschlaggebend für die Entwicklung eines JAX-WS WebServices und damit der Verwendung von JbossWS.

Zur weiteren Lektüre gibt es bei predic8.de einen Vergleich von Axis2, CXF und der JAX-WS Referenzimplementierung.

Das Service-Interface

MyService.java

package de.budisantoso.examples.jaxws;

import javax.ejb.Remote;
import javax.jws.WebService;

@Remote
@WebService()
public interface MyService {
    public static final String ENDPOINT_INTERFACE = "de.budisantoso.examples.jaxws";
    public static final String NAMESPACE = "http://jaxws.examples.budisantoso.de/";
    public static final String SERVICE_NAME = "MyService";

    public String echo(String input);
    public void foo();
}

Im Interface habe ich ein paar Konstanten definiert, um sie bequem an zentraler Stelle konfigurieren zu können. Die @Remote-Annotation gibt an, dass es sich um ein EJB-Remote-Interface handelt und die @WebService-Annotation gibt an, dass dieses Interface einen WebService definiert.

Die Stateless Session Bean

MyServiceBean.java

package de.budisantoso.examples.jaxws;

import javax.ejb.Stateless;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;

@Stateless
@WebService(endpointInterface = MyService.ENDPOINT_INTERFACE, serviceName = MyService.SERVICE_NAME)
@SOAPBinding(style = javax.jws.soap.SOAPBinding.Style.DOCUMENT)
public interface MyServiceBean implements MyService {
    public static final String ENDPOINT_INTERFACE = "de.budisantoso.examples.jaxws";
    public static final String NAMESPACE = "http://jaxws.examples.budisantoso.de/";
    public static final String SERVICE_NAME = "MyService";

    @EJB
    private AnotherBeanRemote anotherBean;

    @Override
    @WebMethod()
    public String echo(String input) {
        return input;
    }

    @Override
    @WebMethod()
    public void foo() {
        anotherBean.bar();
    }
}

Die Implementierung des Interface erhält drei Annotationen:

  • @Stateless – EJB-Annotation, die angibt, dass es sich um eine Stateless Session Bean handelt
  • @WebService(…) – gibt an, dass es sich bei dieser Klasse um eine WebService-Implementierung handelt
  • @SOAPBinding(…) – hierüber wird das Mapping des WebService auf das SOAP Message Protocol definiert

Weitere Infos zu den WebService-Annotationen gibt es im JBoss Community Wiki bzw. direkt in der JSR-181.

Deployment

Das Service-Interface und die Service-Implementierung können zusammen mit weiteren Applikationskomponenten in einer *.ear-Datei gepackt werden. Auf den genauen Build-, Assembly-und Deploy-Prozess und die Projekt- und Archivstruktur möchte ich jedoch nicht weiter eingehen. Hat man schließlich das *.ear-Archiv erstellt, “schiebt” man es in das Deploy-Verzeichnis des JBoss, z.B. [JBOSS_HOME]/server/default/deploy und startet den Applikationsserver. Zugriff auf die automatisch generierte WSDL erhält man dann über die JBossWS-Webapplikation, die beispielsweise (bei Standardinstallation eines JBoss auf dem lokalen Rechner) unter folgender URL erreichbar ist:

http://localhost:8080/jbossws/

Kurz erwähnen und empfehlen möchte ich an dieser Stelle noch das Tool “soap-UI“, mit dem man WebServices schnell und einfach testen kann.

Der Service-Client

Die Implementierung des Service Client kann auf mehrere Wege erfolgen. Zum einen kann der WebService über JAX-WS Direktzugriff angesprochen werde. Daneben gibt es die Möglichkeit, generierte “Stubs” zu verwenden (z.B. über “wsconsume” oder auch über das Axis2-Tool “WSDL2Java”).

Hier ein Beispiel für den direkten Zugriff:

MyServiceClient.java

package de.budisantoso.examples.jaxws;

import java.net.URL;

import javax.xml.namespace.QName;
import javax.xml.ws.Service;

public class MyServiceClient {

    private static final String _wsdl = "http://localhost:8080/examples/MyServiceBean?wsdl";

    public static void main(String[] args) {
        try {
            URL wsdlLocation = new URL(_wsdl);
            QName serviceName = new QName(MyService.NAMESPACE, MyService.SERVICE_NAME);

            // Load the service implementation class
            Service remoteService = Service.create(wsdlLocation, serviceName);

            // Load a proxy for our class
            MyService myService = (MyService) remoteService.getPort(MyService.class);

            // Execute a WebMethod
            String echo = myService.echo("Hello WebService-World!");
            System.out.println(echo);

            // Execute another WebMethod
            myService.foo();

        } catch (Exception e) {
            e.printStackTrace();
        }
    }

}

Weitere Informationen

Kommentare und Verbesserungsvorschläge zu meinem Artikel sind natürlich sehr willkommen. Und auch falls es Fragen gibt, werde ich versuchen diese zu beantworten – dabei liegt die Betonung auf “versuchen” ;)