Dienstag, 22. Mai 2012


Artikel

November 2006 | Artikel

Web Services leicht gemacht mit XFire Fortsetzung, Teil 2

Teil 1   Teil 2   

XFire-Client
Der Client kann mit jedem beliebigen SOAP-Werkzeug erstellt werden. Eine komfortable Art und Weise, einen Client zu entwickeln, ist die Verwendung der XFire-Proxy-Klassen, bei denen ein dynamischer Proxy erzeugt wird. Listing 4 demonstriert die Erstellung eines XFire-Clients. Mithilfe der ObjectServiceFactory wird ein Servicemodell basierend auf der Interface-Definition erstellt, welches die Service-Metadaten enthält. Mithilfe des Service-URL und des Servicemodells kann nun ein dynamischer Proxy über die XFireProxyFactory erstellt werden. Anschließend können wie gehabt die Methoden vom Interface verwendet werden.

  1. Listing 4: XFire Proxy
  2. -----------------------------------------------------------------------------
  3. Service serviceModel = new ObjectServiceFactory().create(ICustomerService.class);
  4. String serviceUrl = "http://localhost:8080/springRemote/services/Customer";
  5. try {
  6. //Proxy erstellen
  7. ICustomerService service = (ICustomerService)
  8. new XFireProxyFactory().create(serviceModel,
  9. serviceUrl);
  10. //Methoden können aufgerufen werden
  11. System.out.println(service.getState("55"));
  12. } catch (MalformedURLException e) {
  13. System.out.println("Call Customer Web Service : EXCEPTION: " + e.toString());
  14. }
XFire in Spring verwenden
Ein tolles Feature von XFire ist auf jeden Fall die Unterstützung unterschiedlicher Container, unter anderem auch Spring. So können die Servicekomponenten vom Container verwaltet und gleichzeitig auch Features des Containers in Anspruch genommen werden. Betrachtet man die Integration zwischen XFire und Spring, so greift XFire auf die schon bekannte Remote-Architektur von Spring zurück und stellt einen passenden XFireExporter zur Verfügung. Neben dem Exporter können Web Services auch mittels Web Service Annotations exportiert werden. Wir betrachten zuerst die Verwendung des Exporters und anschließend nehmen wir die Vorgehensweise mit den Annotations genauer unter die Lupe.

Wie bei Burlap, Hessian oder dem http Invoker von Spring werden auch für XFire die Dienste mithilfe des XFireExporter exportiert. Dieser Exporter implementiert das bekannte RemoteExporter-Interface von Spring. Um den Exporter verwenden zu können, muss zuerst das XFireSpringServlet in der web.xml deklariert werden. Wie anfangs bereits erwähnt, ist XFire eine Servlet-basierte Anwendung.

  1. <servlet>
  2. <servlet-name>xfire</servlet-name>
  3. <servlet-class>
  4. org.codehaus.xfire.spring.XFireSpringServlet
  5. </servlet-class>
  6. </servlet>

Wie für ein DispatcherServlet in Spring existiert auch für das XFireSpringServlet eine passende Konfigurationsdatei mit dem Namen xfire-servlet.xml. In dieser Konfigurationsdatei befinden sich nun die zu exportierenden Web Services. Wie Listing 5 zeigt, werden XFire-spezifische Beans, wie zum Beispiel Service Factories, verwendet. Daher muss noch die xfire.xml-Konfigurationsdatei zu Beginn importiert werden. Alternativ kann diese auch in der web.xml geladen werden.

  1. Listing 5
  2. ---------------------------------------------------------------------
  3. <import resource="classpath:org/codehaus/xfire/spring/xfire.xml"/>
  4. <bean id="customerWS"
  5. class="org.codehaus.xfire.spring.remoting.XFireExporter">
  6. <property name="serviceFactory" ref="xfire.serviceFactory"/>
  7. <property name="xfire" ref="xfire"/>
  8. <property name="serviceBean" ref="customerService"/>
  9. <property name="serviceClass">
  10. <value>at.demolsky.ICustomerService</value>
  11. </property>
  12. </bean>

Die id definiert, unter welchem Namen das Service lokalisiert werden kann. Hier wird auch ersichtlich, dass von XFire definierte Beans verwendet werden, wie zum Beispiel die xfire.serviceFactory und xfire. Die <serviceBean> referenziert auf die Implementierung des Service. Die <serviceClass> legt die Interface-Definition fest. Das war es auch schon.

Leicht gemacht mit Annotations
Mit Java 5 können Beans mit Annotations nach dem JSR 181 versehen werden. Bei dieser Variante werden die Beans mit Web Service Annotations versehen. Es hängt vom Entwickler ab, ob die Annotations in der Implementierung oder im Interface hinterlegt werden. Die Implementierung gegen Interfaces entspricht jedoch einem besseren Programmierstil, daher betrachten wir im Folgenden auch die Interface-Variante: In der passenden Implementierung (ICustomerServiceImpl) des Interfaces befindet sich zu Beginn folgende Annotation:

  1. @WebService(serviceName=“customerService“,
  2. endpointInterface=“ICustomerService“).

Diese Annotation benachrichtigt den JSR 181-Prozessor, dass dieser Service unter dem Namen “customerService“ erreichbar ist und dass das Interface ICustomerService als Endpoint-Interface dient, welches die weiteren Metadaten des Service zur Verfügung stellt. Listing 6 zeigt die notwendigen Annotations im Interface.

  1. Listing 6
  2. ----------------------------------------------------------------------
  3. Web-Service-Annotationenpackage at.demolsky.customer.service;
  4. @WebService
  5. public interface ICustomerService {
  6. @WebMethod
  7. @WebResult(name = "allCustomersResult")
  8. public List loadAllCustomers();
  9. //Other service methods
  10. }

Sollen alle Methoden eines Interfaces als Web Service exportiert werden, so muss die Annotation @WebMethod nicht für jede Methode angegeben werden. Wir wollen in diesem Beispiel nur die Methode loadAllCustomers als Service zur Verfügung stellen. Auch die Annotation @WebResult ist eine optionale Angabe und definiert lediglich den Methodennamen in der WSDL.

Nachdem die Services mit Annotations versehen wurden, gibt es nun mehrere Möglichkeiten, XFire für die Web Annotations zu konfigurieren:

1. Wird das XFireConfigurableServlet verwendet (ohne Container), so muss in der service.xml nur die <serviceFactory> mit dem Wert jsr181 gesetzt werden:

  1. <service>
  2. <serviceClass>at.demolsky.customer.ICustomerService</serviceClass>
  3. <serviceFactory>jsr181</serviceFactory>
  4. </service>

2. Wird das XFireSpringServlet verwendet, kann dies mit einem Handler Mapper gelöst werden.

Im Folgenden wird nun die Variante mit dem XFireSpringServlet und einem passenden Handler Mapper etwas näher beleuchtet. Das Servlet wurde bereits in der web.xml definiert und wird weiterhin durch die Konfigurationsdatei xfire-servlet.xml konfiguriert.

  1. Listing 7: Web Service Annotations
  2. ---------------------------------------------------------------------
  3. <!--
  4. <bean id="webAnnotations"
  5. class="org.codehaus.xfire.annotations.jsr181.Jsr181WebAnnotations"/>
  6. <bean id="handlerMapping"
  7. class="org.codehaus.xfire.spring.remoting.Jsr181HandlerMapping">
  8. <property name="typeMappingRegistry">
  9. <ref bean="xfire.typeMappingRegistry"/>
  10. </property>
  11. <property name="xfire">
  12. <ref bean="xfire"/>
  13. </property>
  14. <property name="webAnnotations">
  15. <ref bean="webAnnotations"/>
  16. </property>
  17. </bean>
  18. <bean id="customerService"
  19. class="at.demolsky.ICustomerServiceImpl"/>
  20. <bean class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
  21. <property name="urlMap">
  22. <map>
  23. <entry key="/">
  24. <ref bean="handlerMapping"/>
  25. </entry>
  26. </map>
  27. </property>
  28. </bean>

Bei der Verwendung der Konfiguration in Listing 7 werden alle Beans mit den entsprechenden Annotations automatisch exportiert. Daher ist es auch wichtig, dass die Services mit Annotations erst nach dem handlerMapping Bean definiert werden. Es muss nicht sein, dass Fehler auftreten, aber es ist zu empfehlen, dass die Services erst nachher definiert werden. Das Service wird entsprechend den Metadaten in den Klassen exportiert, d.h., der Kundenservice ist unter dem Namen customerService erreichbar.

Performance und andere Features
Beim Schlagwort Performance haben Web Services einen Nachteil, da sie viele Ressourcen in Anspruch nehmen. Doch XFire punktet hier durch die Verwendung der Streaming API for XML (StAX) [Alesandro Costa Peireira, Falk Hartmann: Der Mittelweg. Lesen und Schreiben von XML-Dokumenten mit dem Streaming API for XML, in Java Magazin 7.2006] und erzielt eine weitaus bessere Performance als vergleichsweise andere Produkte in diesem Bereich. Auf der Website von XFire befinden sich interessante Erfahrungs- und Vergleichsberichte bezüglich der Performance.

Durch das junge Alter von XFire ist dieses Framework im Vergleich zu anderen noch etwas eingeschränkt im Hinblick auf Funktionalität und Features. Die wichtigsten Features finden Sie im nebenstehenden Kasten zusammengefasst.

Features von XFire im Überblick

  • Native Data Binding Support für POJOs, XMLBeans, JAXB und Castor
  • Streaming API for XML (StAX) für die Verarbeitung von XML-Dokumenten
  • Verschiedene Transportprotokolle wie http oder JMS
  • Unterstützung für Web-Service-Standards (SOAP, WSDL, WS-Addressing, WS-Security, etc.)
  • JBI-Support
  • Container-Unterstützung (Spring, PicoContainer ...)
  • Eclipse-Plug-in
Fazit
XFire hilft bei der Entwicklung von Web Services erheblich. Der Nachteil von XFire liegt aber sicherlich im Alter. Es fehlen einfach noch die notwendigen Erfahrungswerte aus realen Projekten, wie es zum Beispiel bei Apache Axis der Fall ist. XFire punktet vor allem bei der Performance. Nicht zu vergessen ist die einfache Integration in das Spring Framework. Entwickler, die mit der Remote-Architektur von Spring vertraut sind, können mit Leichtigkeit nun auch Web Services erstellen. Auch das API von XFire ist sehr leicht zu verwenden. Alles in allem wird XFire in Zukunft auch ein heißer Kandidat für serviceorientierte Anwendungen sein.

Markus Demolsky beendete vor kurzem sein Studium der Wirtschaftsinformatik. Derzeit ist er noch mit seinem Zweitstudium Informatik (Software Engineering & Internet Computing) an der TU Wien beschäftigt. Neben dem Studium arbeitet er bei der Icodex Software AG als Software Engineer. Seine Interessensschwerpunkte liegen bei Softwarearchitekturen und Open-Source-Technologien im Java EE-Bereich.

  1. Apache Axis
  2. XFire

Teil 1   Teil 2   

Kommentare