Web services tools

1. Web services tools David Fergusson

2. Web services tools • Java based • ANT • JWSDP/J2EE/Java Beans • Axis • Tomcat • C based • .Net • gSOAP • Perl based • SOAP::Lite

3. SOAP::Lite • Collection of Perl modules which provides a simple and lightweight interface to Simple Object Access Protocol on both client and server side. • Used for much of the Alien grid implementation

4. C based tools • gSOAP • C and C++ toolkit which provides C/C++ - XML bindings for web services development • Comments from developers suggest that this implementation is fragile and can be buggy • .NET • Microsoft web services implementation based on C# super-set of C. • Comments form developers – easy entry but lacks flexibility in more complex situations

5. XML Parsing • Xerces (originally Java, also C++ now) • Used in JWSDP modules, Axis • DOM (Document Object Model) • Creates representation of document structure in memory • SAX (Simple API for XML) • Simpler but less powerful parsing model

6. Tomcat and Axis • Both containers – add functionality to web servers • Tomcat originally designed to add servlets to web servers – became used to support web services • Axis new development to specifically support web services • Axis also includes a web services development environment

7. Java web services • Free distribution, cross platform • Development environments • Java Web Services Development Package (JWSDP) • Java 2 Enterprise Edition (J2EE) • Java Beans

8. ANT A java based ‘make’ tool

9. Ant • Ant – Another Neat Tool • Ant is a tool for building projects • It is written in Java and is therefore entirely platform independent • It uses a build file, called build.xml, to determine how to build a particular project

10. Understanding Ant • The key to understanding Ant is to understand the build.xml file structure • The root element is project • There are then properties elements, which can be set externally or internally to the file • There are also target elements which specify what actions are to be taken <project ..> <property .../> <target .../> </project>

11. Example Project (1) • The next few slides will demonstrate the use of Ant to build a very simple project • There are three classes in the Project • Person • Contains a name, age and an Address • Address • Contains street, town and country information • Display • Instantiates 3 Person classes and displays their details on the command line

12. Example Project (2) • All the source files are in a package structure in a directory called src • An example output would be:

13. Compile Example • This example will perform a simple compile • There is only one target, which will compile all classes in the same location as the source files <project name="PeopleProject" default="compile" basedir="."> <!-- set global properties for this build --> <property name="src" location="src"/> <target name="compile” > <!-- Compile the java code --> <javac srcdir="${src}"/> </target> </project>

14. More Complex Example • This example will now create a directory called build and put the compiled code in there, preserving package structure <property name="src" location="src"/> <property name="build" location="build"/> <target name="init"> <mkdir dir="${build}"/> </target> <target name="compile" depends="init" > <!-- Compile the java code --> <javac srcdir="${src}" destdir="${build}“ /> </target>

15. Creating JAR files (1) • This build.xml will require two runs: • One to compile and package in to a JAR • One to clean up unnecessary files <project name="PeopleProject" default="dist" basedir="."> <target name="init" description="prepare the environment"> <mkdir dir="${build}"/> <mkdir dir="lib"/> </target> ...

16. Creating JAR files (2) ... <target name="compile" depends="init" > <!-- Compile the java code --> <javac srcdir="${src}" destdir="${build}"/> </target> <target name="dist" depends="compile" > <jar jarfile="lib/PeopleProject.jar" basedir="${build}"/> </target> <target name="clean" description="clean up"> <delete dir="${build}"/> </target> </project>

17. Invoking targets • Here dist invokes clean so we now only require one run of ant <target name="dist" depends="compile" > <jar jarfile="lib/PeopleProject.jar" basedir="${build}"/> <antcall target="clean"/> </target> <target name="clean" description="clean up" > <delete dir="${build}"/> </target>

18. Setting the classpath • To set the classpath, use the classpath task and specify the appropriate pathelement tags • All of the above JAR files will now be on the class path when the source is compiled <javac srcdir="${src}" destdir="${build}"> <classpath> <pathelement path="${basedir}/lib/Jar1.jar"/> <pathelement path="${basedir}/lib/Jar2.jar"/> <pathelement path="${basedir}/lib/Jar2.jar"/> </classpath> </javac>

19. Copying Files • The copy task in ant allow you to copy files and/or directories • This example will copy the file MyFile.file to the Stilo directory under MyFiles <copy file=“AFile.file" toDir="MyFiles/stilo"/>

20. Java Web Services Development Package

21. JWSDP packages • JWSDP • saaj • soap with attachments API for java • jaxp • jax parsing (XML) • jaxb • XML – Java bindings • jaxr • Jax for registries • jax-rpc • Jax remote proceedure call

22. JWSP – JAX-RPC

23. What does jax–rpc do? • The jax-rpc package provides a number of java packages which: • Given WSDL or Java Interface definitions generate ‘stub’ classes for web service providers or consumers. • Handles Java-XML bindings • Handles the generation of SOAP messages

24. Serialiser Serialiser Java Java XML XML-Java bindings XML-Java bindings Note on serialisation • Java web services (also C based ones) allow a developer to treat service classes as if they are local • ie. stubs are created • All web services messages are XML (SOAP) • This means that objects sent across web services must be translated to XML and back • Means that classes seen by either side may not be identical

25. JAX-RPC API packages • javax.xml.rpc Core classes for the client side programming model • javax.xml.rpc.encoding Java primatives <-> XML SOAP messages • javax.xml.rpc.handler processing XML messages • javax.xml.rpc.handler.soap • javax.xml.rpc.holders support the use of IO parameters • javax.xml.rpc.server minimal API for web service inplementation • Javax.xml.rpc.soap specific SOAP bindings

26. JAX-RPC Architecture

27. Java web service flow

28. Client operation modes • JAX-RPC allows two modes of operation • Synchronous request – response • One-way RPC • Synchronous • This involves blocking the client until it receives a response • Is similar to a traditional java method call • One – way • No client blocking • Service performs a operation without replying. • Not analogous to traditional method calls

29. Comparing One-way and traditional methods • A traditional java method call like • Public void request (int arg1, int arg2); • Does not return a value to the caller • However if it appeared in a web service interface definition it would be mapped to a synchronous request – response RPC • This is because it indicates that an exception may still need to be thrown to the client. • A one – way RPC cannot throw an exception.

30. Synchronous method invocation Servlet Client Client invokes service Client waits until Server responds Server performs the requested action Response returned to client

31. One – way RPC invocation Servlet Client Client invokes service Server performs the requested action Client does not block While operation is performed

32. Defining a service • A service can be defined starting with: • A java interface • A WSDL document • Which to use? • If the service end point interface is defined in java it may not be interoperable with services/clients defined in other languages • If the service is initially defined in WSDL it will be open

33. Using JAX-RPC to create a service from a Java interface

34. Interface method definitions • The interface must extend java.rmi.remote • Interface methods must declare that it throws java.rmi.RemoteException • Service dependent exceptions can be thrown if they are checked exceptions derived from java.lang.Exception • Method name-overloading is permitted • Service endpoint interfaces may be extensions of other interfaces A java web service end point interface must obey the following rules:

35. Supported data types • Java primitives (eg. bool, int, float, etc) • Primitive wrappers (Boolean, Interger, Float, etc) • Standard java classes (required - java.lang.String, java.util.Calendar, java.util.Date, java.math.BigDecimal, java.math.BigInterger) • Value types • Holder classes • Arrays (where all elements are supported types) Object by reference is not supported

36. Value Types • Class has a public no-argument constructor • May be extended from any other class, may have static and instance methods, may implement any interface (except java.rmi.Remote and any derived) • May have static fields, instance fields that are public, protected, package private or private but these must be supported types.

37. Warning about comparing classes • The values returned by service methods are in fact local classes created by JAX-RPC from the XML serialisation • This means that comparisons using == should be avoided • equals () should be used instead • (inner static classes will not compare correctly)

38. Serializer • If you want to pass an un-supported java class you have to create your own serializer/deserializer to translate to and from XML. • This not a trivial task as there is no JAX-RPC framework.

39. Client side Implementation

40. wscompile • Generates • Compiled class files + optionally source files for stubs to interface with client side JAX-RPC • WSDL file • Model file Example commandline wscompile –gen:client –d output/client –classpath classpath config-file (add –keep –s to retain java source files)

41. config.xml <?xml version=“1.0” encoding=“UTF-8” ?> <configuration xmlns=“http://java.sun.com/xml/ns/jax-rpc/ri/config”> <service name=“……..” targetNamespace=“………………………” typeNamespace=“……………………………..” packageName=“……………………………….”> <interface name=“……………………………”/> </service> </configuration> name = name of service targetNamespace = namespace of WSDL for names associated with the service eg. port type typeNamespace = namespace of WSDL for data types packageName = name of java package

42. Generated files Some of the client side generated files:

43. Service.java file • The Service.java file corresponds to the definition of the interface for the web service, ie it contains the same info as the <service> element in the config file. package servicePackage; import javax.xml.rpc.*; Public interface Service extends javax.aml.rpc.Service { public servicePackage getServicePort(); }

44. Referencing the stub • In order to get an object to reference the stub you have to instantiate Service_Impl. • (Unfortunately this name is only recommended) • Service_Impl service = new Service_Impl (); • value*name = (value)service.getServicePort (); • With this reference you can call the methods of the service.

45. Using JAX-RPC to create a service from a WSDL definition

46. WSDL is an interface definition

47. Getting the WSDL • WSDL can be downloaded from a UDDI registry • If the service uses JAXRPCServlet you can attach ?WSDL (or ?model) to the URL request to get the WSDL (or model file). • Eg http://localhost:8080/Service/Servicename?WSDL

48. A config.xml file <?xml version=“1.0” encoding=“UTF-8”?> <configuration xmlns=“http://java.sun.com/xml/ns/jax-rpc/ri/config”> <wsdl location=“http://localhost:8080/Service/Servicename?WSDL” packageName=“example.wsdlexample.servicename”/> </configuration> Format of config file depends on whether wscompile is given a WSDL file, model file or Java

49. Generate client side artifacts wscompile –gen:client –keep –s generated/client –d output/client –classpath classpath config.xml

50. Some of the client side files generated by wscompile from WSDL