...einen JAX-WS WebService mit JBoss 5.1 erstellen.

von Roman Seibold

Vorgeschichte: der WebService

"Nur mal kurz" geht in der IT gar nicht. Musste ich neulich wieder feststellen. Eigentlich ging es hauptsächlich überhaupt nicht um einen WebService, aber ich brauchte einen, um etwas anderes tun zu können. Ist ja jetzt ganz einfach, mit Java EE 5 und JAX-WS. Dachte ich. Der WebService, als POJO nicht als EJB, ist mit JAX-WS tatsächlich schnell geschrieben. Hier, auch was den Rückgabetyp betrifft, sehr vereinfacht dargestellt:

import javax.jws.WebMethod; 
import javax.jws.WebService;

 
@WebService 
public class WebService 
{   
  @WebMethod
  public String getContent()
  {
     return "Juhu, tut!";
  } 
} 

Das ist schon alles. Mit @WebService erkläre ich die Klasse zum Web-Service, mit @WebMethod wird klar, was als Operation für den Service im WSDL verfügbar wird.

Deployment

Jetzt beginnt der proprietäre Teil. Ein Java-EE-compliant Application- Server ist nur verpflichtet, einen Web-Access-Point für JAX-WS zur Verfügung zu stellen. Wie ist nicht gesagt. Das macht jeder Server anders, z.B. indem er einen automatisch aktivierten WebService- Router zur Verfügung stellt, wenn JAX-WS-Services erkannt werden. JBoss verfährt so nicht. Es gibt verschiedene Möglichkeiten, mit WebServices umzugehen. Mein POJO-WebService wird nur von außen erreichbar, wenn ich ihn als Servlet (!) definiere. Das sieht im Deployment-Deskriptor so aus:

<servlet>
  <servlet-name>JaxWSServlet</servlet-name>
  <servlet-class>
    com.aformatik.biblio.service.BiblioAccessService
  </servlet-class>
</servlet>
<servlet-mapping>
  <servlet-name>JaxWSServlet</servlet-name>
  <url-pattern>/BiblioAccess</url-pattern>
</servlet-mapping>

Das war schon die erste, nicht ganz intuitive Hürde. Weiterhin ist mein Projekt folgendermaßen - eigentlich recht simpel - strukturiert:

WebServiceEAR.ear 
+-- WebServiceWeb.war 

Das heißt, dass der WebService in einem Web-Modul definiert ist, das einem EAR-Modul zugeordnet ist. Das ganze schnell auf einen JBoss AS 5.1 deployed. Fehlerfrei. Gut.

Nur noch kurz...

Jetzt "nur noch kurz" den Client dazu... Geht eigentlich auch einfach. Man importiert das vom Server gemäß JAX-WS generierte WSDL-File und lässt sich die entsprechenden Client-Klassen erstellen und arbeitet damit. Die Frage ist nur: wo ist denn das WSDL-File? Angeblich gibt es bei JBoss eine URL unter der die deployten Services erreichbar sind. Bei mir sollte dies http://localhost:8080/jbossws/services sein. Tatsächlich, da ist auch was. Wenn man aber auf den Link zum Service klickt, dann kommt "Not Found". Hmmm...

Nach längerer Zeit wurde ich im "data"-Verzeichnis des Servers fündig, da liegt das generierte WSDL ebenfalls. Na gut, dann nimmt man halt das. Auf dieser Basis den Client generiert - und nichts tat. Not found. Ich habe also ein WSDL für einen Service, der angeblich verfügbar ist, aber nicht auf Zugriff reagiert. Das stimmte mich miß. Hier schloß sich nun eine längere Zeit für Recherche und Tests an. Offenbar war ich einem Problem begegnet, das noch niemand so hatte. Es ließ sich jedenfalls nicht auf die Schnelle im Internet etwas finden. Macht keiner WebServices, oder nicht mit JBoss, oder (noch) nicht mit JAX-WS?

Die Lösung

Auf einer einzigen, etwas versteckten JBoss-JIRA-Bug-Tracking Webseite, die eigentlich einen Bug im Zusammenhang mit JBoss ESB thematisierte, wurde ich fündig: die JBoss-native WebService-Implementierung hat einen Bug in der ausgelieferten Version 3.1.2. Der Bug kommt aber nur zur Geltung, wenn eine WAR-Datei, die einen Web-Service definiert, in einem EAR deployt wird. War bei mir ja der Fall. Lösung: die neuere Implementierung der WebServices 3.2.0 verwenden. Leider, leider ist die neueste Server-Version, die man von JBoss herunterladen kann, die 5.1 GA. Punkt. Kein Service-Release, kein sonstwas. Ist aber vom Mai, jetzt haben wir November. Haben die kein Release-Management? Na gut, dann basteln wir uns eben einen gepimpten Server. In einem Blog  fand ich, wie man eine andere WebService-Implementierung ("Metro") aktualisiert. Ich wollte aber die JBoss-native. In diesem Beitrag ist die Download-Adresse der Metro-Implementierung angegeben, wenn man aber versucht, einfach mal ins Verzeichnis zu schauen, um nach den anderen Implementierungen zu suchen, dann klappt das aus Berechtigungsgründen nicht. Man muss den Dateinamen schon wissen! Jetzt hilft mal wieder nur "inspiriertes Raten" und es klappte mit dem URL http://jboss.org/file-access/default/members/jbossws/downloads/jbossws-native-3.2.0.GA.zip. War jetzt auch nicht so schwer. Danach die Steps ausgeführt, die der Kollege mit dem unaussprechlichen Namen "Prakashbabu" vorschlägt, und - voila - JBoss bootet noch (!) und zeigt im Log:

JBoss Web Services - Native Server 
3.2.0.GA 

Und, oh Wunder, jetzt tut sofort alles, wie beschrieben. Unter http://localhost:8080/jbossws/services/WebService?wsdl ist mein WSDL verfügbar, der Eclipse-Testclient und ein generierter Client-Code können sofort auf den Service zugreifen. Super! War ja auch ganz einfach. Naja, JAX-WS schon, nur der konkrete Teil mit Produkten und Versionen, der war mal wieder unschön.

Komisch aber schon, dass dieser Fehler kein größeres Echo hervorgerufen hat und dass die seit Mai verfügbare Download-Version von JBoss AS 5.1 immer noch diesen Bug beinhalten darf und dass es keine aktualisierte gibt. Das lässt schon den Verdacht etwas keimen, dass JAX-WS-WebServices noch nicht so verbreitet sind. Oder dass niemand die native Implementierung verwendet. Oder...