Das Augenmerk beim Herunterladen der beiden Development Kits fällt sicherlich zuerst auf den enormen Unterschied der Dateigrößen. Schlägt das Developer Pack von Sun gerade mal mit rund 35 Mbyte zu Buche, so summiert sich die Dateigröße beim IBM Toolkit auf rund 125 Mbyte. Dies rührt allerdings in erster Linie daher, dass versucht wurde, eine möglichst einheitliche Testumgebung für diesen Artikel zu schaffen. Da im IBM Toolkit ein UDDI Registry Server nicht enthalten ist, musste zusätzlich das IBM WebSphere SDK for Web Services heruntergeladen werden. Dies verschlang letztlich auch den Bärenanteil der gesamten Downloadgröße.

Sind die Development Kits erst einmal heruntergeladen, installiert und konfiguriert, findet man zwei Entwicklungslösungen für Web Services vor, die einander ebenbürtig sind. Um dies zu verdeutlichen, sei an dieser Stelle auf die Featurematrix in Tabelle 1 verwiesen.

 

Entwicklungsparadigmen

Grundsätzlich unterscheiden sich die Development Kits in den einzelnen Entwicklungsschritten nur marginal. Im Wesentlichen sind dies das Erstellen des eigentlichen Web Services, das Beschreiben des Web Services mittels WSDL, das Erstellen eines proprietären Deployment-Deskriptors, der je nach Produkt variiert, und abschließend das Deployment des erstellten Web Services. Dieser Entwicklungsprozess ist in den Abpictureungen 1 und 2 nochmals für die jeweiligen Produkte dargestellt. Außerdem erläutert Tabelle 2 wesentliche Details, in denen sich die beiden Development Kits unterscheiden.  
Nachfolgend sei auf einige Details verwiesen, die während des Tests besonders aufgefallen sind:

• Das Sun Developer Pack verwendet das RMI-Protokoll als Aufsatz auf die eigentlichen SOAP Calls.
• IBMs Implementierung basiert hingegen auf dem Apache Axis-Projekt, welches beim Implementieren eines Web Services keine zusätzlichen APIs benötigt, wodurch sich die Klasse für den Web Service nicht von einer normalen Klasse unterscheidet. Dies spricht vor allem dafür, dass sich nahezu jede Java-Klasse mit nur geringen Aufwand in einen Web Service umwandeln lässt.
• Sämtliche Schritte des Deployments lassen sich beim Sun Developer Pack mit einem grafischen Tool erledigen. Dies erspart vor allem das lästige Erstellen der einzelnen Deployment-Deskriptoren. Zudem läst sich der erstellte Web Service als WAR-Datei auf einen Tomcat-Server spielen, der auf einem Remote-Rechner läuft.

Die Beispielanwendung

Um den zuvor beschriebenen Entwicklungsprozess und die Toolkit-spezifischen Unterschiede zu veranschaulichen, soll im Folgenden ein einfacher Web Service implementiert werden, der es erlaubt, die Preise verschiedener Magazine abzufragen. Um den Preis eines bestimmten Magazins zu erhalten, muss dem Web Service das Kürzel des jeweiligen Magazins übergeben werden. Im Wesentlichen wird dieser Prozess durch die Methode getPrice(String shortName) abgepictureet. In Listings 1 und 2 sind die Web Service-Implementierungen für das zuvor geschilderte Problem dargestellt. Der Quellcode für das Sun Developer Pack enthält dabei sowohl das Interface für den Web Service als auch die eigentliche Klasse.

Listing 1

1. import java.util.Hashtable;
3. public class Magazines
4. {
5. private Hashtable magazines = new Hashtable();
7. public Magazines()
8. {
9. this.magazines.put("ENT", "29.50");
10. this.magazines.put("DOT", "41.00");
11. this.magazines.put("JAV", "52.50");
12. this.magazines.put("LIN", "37.50");
13. this.magazines.put("PHP", "52.00");
14. this.magazines.put("XML", "52.00");
15. }
17. public String getPrice(String shortName)
18. {
19. return (String) this.magazines.get(shortName);
20. }
22. public static void main(String[] args)
23. {
24. String shortName = null;
26. if (args.length == 0)
27. {
28. shortName = "ENT";
29. }
30. else
31. {
32. shortName = args[0];
33. }
35. System.out.println("Short name is: " + shortName);
36. String result = (new Magazines()).getPrice(shortName);
37. System.out.println("Result was: \n" + result);
38. }
39. }

Listing 2

1. package catalogue;
3. import java.rmi.Remote;
4. import java.rmi.RemoteException;
6. public interface MagazinesIF extends Remote
7. {
8. public String getPrice(String shortName) throws RemoteException;
9. }
11. package catalogue;
13. import java.util.Hashtable;
15. public class MagazinesImpl implements MagazinesIF
16. {
17. private Hashtable magazines = new Hashtable();
19. public MagazinesImpl()
20. {
21. this.magazines.put("ENT", "29.50");
22. this.magazines.put("DOT", "41.00");
23. this.magazines.put("JAV", "52.50");
24. this.magazines.put("LIN", "37.50");
25. this.magazines.put("PHP", "52.00");
26. this.magazines.put("XML", "52.00");
27. }
29. public String getPrice(String shortName)
30. {
31. return (String) this.magazines.get(shortName);
32. }
33. }

Der Quelltext in Listing 3 veranschaulicht die Implementierung des Clients, der letztlich den Web Service aufruft, mit Hilfe des IBM Toolkits. Es fällt auf, dass der Programmieraufwand, der beim Entwickeln des Web Services gespart wurde, in diesem Fall verhältnismäßig groß ist. Dies bestätigt sich im Vergleich zur Client-Anwendung, die mittels Sun Developer Kit umgesetzt wurde (siehe Listing 4). Allerdings darf an dieser Stelle nicht unterschlagen werden, dass der größte Teil des Client-Codes beim Sun Developer Kit in Form so genannter Stubs dynamisch generiert wird. Das heißt, der größte Teil der SOAP-Aufrufe ist im Beispiel nicht sichtbar.

Listing 3

1. import java.util.Vector;
2. import java.net.URL;
3. import javax.xml.namespace.QName;
4. import com.ibm.wstk.WSTKConstants;
5. import com.ibm.uddi4j.wsdl.client.UDDIWSDLProxy;
6. import com.ibm.uddi4j.wsdl.definition.ServiceDefinition;
7. import com.ibm.uddi4j.wsdl.provider.ServiceProvider;
8. import org.apache.wsil.WSILDocument;
9. import org.apache.wsil.client.WSILProxy;
10. import org.apache.axis.encoding.ser.BeanDeserializerFactory;
11. import org.apache.axis.encoding.ser.BeanSerializerFactory;
12. import org.apache.axis.client.Service ;
13. import org.apache.axis.client.Call;
14. import org.uddi4j.datatype.Name;
16. public class Client
17. {
18. private static final String M = "Magazines";
20. private static final QName MqName =
21. new QName("urn:Magazines-types", "String");
23. public static void main(String[] args) throws Exception
24. {
25. if (args.length == 0)
26. {
27. System.out.println("Usage: java Client [short name of a magazine]");
28. System.exit(0);
29. }
31. try
32. {
33. String shortName = args[0];
34. String wsdlURL = null;
36. wsdlURL = findUDDI(M + "Service");
38. if (wsdlURL != null)
39. {
40. System.out.println(getPrice(wsdlURL, shortName));
41. }
42. else
43. {
44. System.out.println(
45. "The Magazines Service could not be found");
46. }
47. }
48. catch (Exception e)
49. {
50. e.printStackTrace();
51. }
52. }
54. private static Object getPrice(String wsdlURL, String shortName) throws Exception
55. {
56. QName serviceM = new QName("http://" + M, M + "Service" );
57. QName portM = new QName("http://" + M, "magazine");
58. Service service = new Service(new URL(wsdlURL), serviceM );
59. Call call = (Call)service.createCall(portM, "getPrice");
60. call.registerTypeMapping(String.class,
61. MqName,
62. new BeanSerializerFactory(String.class, MqName),
63. new BeanDeserializerFactory(String.class,MqName));
64. return (String)call.invoke( new Object[] { shortName } );
65. }
67. public static String findUDDI(
68. String service)
69. throws Exception {
70. try {
71. UDDIWSDLProxy uwp =
72. new UDDIWSDLProxy(WSTKConstants.UDDI_INQUIRY_URL,
73. WSTKConstants.UDDI_PUBLISH_URL,
74. WSTKConstants.UDDI_USERID,
75. WSTKConstants.UDDI_CRED,
76. WSTKConstants.TRANSPORT_CLASS);
77. Vector providerNameVector = new Vector();
78. providerNameVector.add(new Name("WSTK 3.2 Tutorial"));
79. ServiceProvider[] sps =
80. uwp.findAllServiceProviders(null, providerNameVector,
81. null,null,null,null,true);
82. if (sps.length > 0) {
83. ServiceDefinition sd = sps[0].getServiceDefinition(service);
84. return sd.getServiceImplementation().getWSDLFilename();
85. } else {
86. return null;
87. }
88. } catch (Exception e) {
89. System.out.println(e.getMessage());
90. System.exit(0);
91. return null;
92. }
93. }
94. }

Listing 4

1. package catalogue;
3. import javax.xml.rpc.Stub;
5. public class Client
6. {
7. public static void main(String[] args)
8. {
9. try
10. {
11. Stub stub = createProxy();
12. MagazinesIF magazines = (MagazinesIF)stub;
13. System.out.println(magazines.getPrice(args[0]));
14. }
15. catch (Exception ex)
16. {
17. ex.printStackTrace();
18. }
19. }
21. private static Stub createProxy()
22. {
23. // Note: MyMagazines_Impl is implementation-specific.
24. return (Stub)(new MyMagazines_Impl().getMagazinesIFPort());
25. }
26. }

Abschließend sollen noch Beispiele für die Deployment-Deskriptoren aufgeführt werden (siehe Listings 5 und 6). Diese werden benötigt, um den Web Service auf dem jeweiligen Server zu installieren. Es sei nochmals darauf verwiesen, dass zumindest beim Sun Developer Pack der Deployment-Deskriptor nicht von Hand erstellt werden muss, obwohl dies mit Sicherheit nur einen geringen Aufwand verursacht.

Listing 5

1. <deployment
2. xmlns="http://xml.apache.org/axis/wsdd/"
3. xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"
4. name="test">
6. <service name="magazin" provider="java:RPC">
7. <parameter name="className" value="Magazines" />
8. <parameter name="allowedMethods" value="getPrice" />
9. </service>
10. </deployment>

Listing 6

1. <?xml version="1.0" encoding="UTF-8"?>
2. <webServices
3. xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/dd"
4. version="1.0"
5. targetNamespaceBase="http://com.test/wsdl"
6. typeNamespaceBase="http://com.test/types"
7. urlPatternBase="/ws">
9. <endpoint
10. name="MyMagazines"
11. displayName="Magazines Service"
12. description="A simple web service"
13. interface="catalogue.MagazinesIF"
14. implementation="catalogue.MagazinesImpl"/>
16. <endpointMapping
17. endpointName="MyMagazines"
18. urlPattern="/magazines"/>
20. </webServices>

Der fertige Web Service

Wurde der Web Service korrekt installiert, kann er von beinahe jeder Programmiersprache aufgerufen werden. Um dies zu veranschaulichen, ist der zugehörige Aufruf des Clients in Abpictureung 3 dargestellt. In diesem Beispiel werden die Preise für Magazine wie zum Beispiel das Java Magazin (Kürzel JAV) abgerufen.

Fazit

Beiden Toolkits kann attestiert werden, dass sie den für einen Web Service notwendigen Entwicklungsprozess ausreichend abpictureen. Sun hat die meisten Tools in das Apache Ant Build Tool integriert, sodass man von den bereits vorhandenen build-Dateien abkupfern kann. Zudem automatisiert das in Abpictureung 4 dargestellte Deployment-Tool von Sun den kompletten Deployment Prozess, was man beim IBM Toolkit zum Teil vermisst. Ursprünglich wollte ich in meiner Beispielanwendung auch das Deployment mittels einer UDDI Registry beschreiben. Allerdings produzierte das IBM Deployment-Tool beim Einlesen der WSDL-Files Fehler, die für mich in der Kürze der Zeit nicht nachvollziehbar waren.
Abgesehen von den zuvor geschilderten Problemen, stellen beide Toolkits eine hervorragende Lösung für das Entwickeln von Web Services dar. Dieser Eindruck wird durch eine sehr umfangreiche Dokumentation und durch verschiedene praktische Werkzeuge abgerundet. Einziger Wehrmutstropfen wird für manchen das Fehlen diverser APIs wie der JAXB API zur Datenanbindung sein. Diese Sun-API fehlt nach wie vor im Sun Developer Kit. Darüber hinaus sind die Entwicklungsparadigmen der beiden Toolkits in wesentlichen Punkten grundlegend verschieden, sodass Umsteigern das Einarbeiten in das jeweils andere Toolkit unnötig erschwert wird. Dies wird aber vielleicht dadurch ausgeglichen, dass Sun das für Web Services aufgebohrte J2EE Deployment-Tool mit seinem Developer Pack ausliefert. Mit diesem werden sich vor allem J2EE-Veteranen schnell zurecht finden.

Müsste ich an dieser Stelle bezüglich der beiden Toolkits ein ganz persönliches Statement abgeben, so würde ich sagen, dass IBM die größere Erfahrung in diesem Umfeld mitbringt. Dies zeigt sich im Umfang des Toolkits sowie den zusätzlichen APIs wie zum Beispiel dem Web Services Invocation Framework. Letztlich lassen sich aber mit beiden Toolkits ebenbürtige Ergebnisse erzielen.

Links und Literatur

• [1] James Snell, Doug Tidwell & Pavel Kulchenko, Programming Web Services with SOAP, O'Reilly (ISBN: 0-596-00095-2)
• [2] Ethan Cerami, Web Services Essentials, O'Reilly (ISBN: 0-596-00224-6)
• [3] Simon St. Laurent, Joe Johnston & Edd Dumbill, Programming Web Services with XML-RPC, O'Reilly (ISBN: 0-596-00119-3)
• [4] IBM Web Services Toolkit 3.2.2: www.alphaworks.ibm.com/tech/webservicestoolkit/
• [5] IBM WebSphere SDK for Web Services: www-106.ibm.com/developerworks/webservices/wsdk/
• [6] Sun Web Services Website: java.sun.com/webservices/
• [7] Sun Web Service Developer Pack v1.0_01: java.sun.com/webservices/webservicespack.html
• [8] Jakarta Tomcat Servlet und JSP Container: jakarta.apache.org/tomcat/index.html
• [9] Apache Axis SOAP-Implementierung: xml.apache.org/axis/index.html
• [10] IBM WSDL4J API Website: www-124.ibm.com/developerworks/projects/wsdl4j/
• [11] UDDI4J API Web Site: www.uddi4j.org/
• [12] IBM Web Services Invocation Framework: www.alphaworks.ibm.com/tech/wsif/