Web Services

Web Services

SAP J2EE Engine 6.20

Web Services

Contents

1. Introduction to Web Services ............................................................3 SOAP ..............................................................................................3 WSDL..............................................................................................3 UDDI ..............................................................................................3

2. Overview of the Web Services Toolkit ................................................4 3. Features ..........................................................................................5 4. Setting up Web Service Framework ...................................................6 5. Enabling and Disabling SOAP Support................................................7 6. Server Side - Service Endpoints .........................................................8

6.1. Session Beans...........................................................................8 6.2. JMS Destinations.....................................................................13

7. Client Side – Accessing Services ......................................................14 7.1. SAP J2EE Engine SOAP Proxy Generator ...................................14

8. UDDI4J Pluggability ........................................................................16 9. WSIL Integration............................................................................17 10. DataMarshalers ............................................................................18 11. Examples .....................................................................................22

Example 1 – Calculator...................................................................22 Example 2 – Simple .......................................................................23 Example 3 – Complex1...................................................................23 Example 4 – Complex2...................................................................23 Example 5 – EchoServlet ................................................................24 Example 6 – UDDI4J ......................................................................24

12. References...................................................................................25

2/26

Web Services

1. Introduction to Web Services

The growing need of fast, secure and efficient bussines-to-bussines communications imposes Web Services as a main technology. Web services are offered via the Internet as they use an XML-based communication protocol (SOAP).

The interaction between Web Services and business applications is simple and productive. The application sends a request to a service at a specified URL. The request is then processed by the service and the response is sent back to the application. A short résumé of additional technologies related to Web Services is given below.

For more information about this topic and the matters presented below, see the drafts released by the W3C organization.

SOAP

SOAP (Simple Object Access Protocol) is an XML-based protocol, which is developed to allow network communication between different applications via the World Wide Web. Its language and platform independence along with the opportunity to run over HTTP, make it an excellent choice for exchanging information over the Internet.

WSDL

WSDL (Web Service Description Language) is the primary means for describing Web Services. It is based on XML and is used to define Web Services. In addition the WSDL describes the operations (methods) that the particular Web Service exposes and how and where to access them.

UDDI

UDDI (Universal Description, Discovery and Integration) is a new technology that allows services and businesses to be published in the Internet. These services (or businesses) are stored in UDDI repositories and can be accessed through a particular client (web browser).

3/26

Web Services

2. Overview of the Web Services Toolkit

The Web services toolkit provides a framework for handling the emerging Web service issues. Using the new features and tools one can easily use Web service technologies either on the client or on the server sides. This document will provide information for the following topics:

• Overview of the supported by the framework features • Setting up the SAP J2EE Engine • Using Enterprise Java Beans as Web service endpoints • Configuration of a Web service • Client side proxy generation

For more detailed information about Web services concepts and technologies refer to JSR 109.

4/26

Web Services

3. Features

Here is an outline of the standards supported by the framework. This page will be changed in the future in order to be up-to-date with any new features added.

• Full implementation of Sun’s Java XML Pack Winter 01 o JAXP 1.2 o JAXM 1.0 o JAX-RPC 0.6 o JAXR 0.7

• Any session bean as Web service • SOAP headers on client and server side • Configurable WSDL generation on server side • Proxy generation on client side • UDDI4J pluggability • SOAP 1.1 + attachments support • Web Services Inspection Language (WSIL)

5/26

Web Services

4. Setting up Web Service Framework

In order to access the Web service framework, enter http://localhost/soapdispatcher in your browser.

6/26

Web Services

5. Enabling and Disabling SOAP Support

You can enable and disable the SOAP Support of SAP J2EE Engine 6.20 through the global-web.xml file located in <SAPj2eeEngine_install_dir>/cluster/server/services/servlet_jsp or <SAPj2eeEngine_install_dir>/alone/services/servlet_jsp directory. By default the SOAP Support is enabled. To disable it, remove the following tags from the global-web.xml file:

<servlet> <servlet-name>soapdispatcher</servlet-name> <servlet-class>com.inqmy.services.servlets_jsp.server.SoapServlet</servlet-class> </servlet>

and

<servlet-mapping> <servlet-name>soapdispatcher</servlet-name> <url-pattern>/soapdispatcher/*</url-pattern> </servlet-mapping>

In order for the changes to take effect, restart the server.

Add the above tags in the global-web.xml file in order to activate the SOAP Support. In this case a restart of the server is also required.

7/26

Web Services

6. Server Side - Service Endpoints

6.1. Session Beans

6.1.1. General

Session beans are the preferred kind of J2EE component for an implementation of a Web service. Using the Web service framework, any session bean can be easily transformed into a Web service (and for simple ones you will not have to write a line of code).

To expose a bean as a Web service, it must be deployed.

Using the Web service framework you can use any existing session bean as a Web service. After deploying it, you just have to go to http://localhost/soapdispatcher, and browse through the deployed beans until you find the right one. Clicking on it will generate a WSDL, which can be used to access that bean. Another way of getting the WSDL is by loading directly: http://localhost/soapdispatcher?WSDL=<beanName>. For example: http://localhost/soapdispatcher?WSDL=Calc, for a bean named “Calc”.

In order to access a particular bean you can use the generated proxy from the bean’s WSDL. The generation of the proxy is executed by the ProxyGenerator. For more information, see “7.1. SAP J2EE Engine SOAP Proxy Generator” section.

By default the framework can automatically handle the following types:

• All Java simple types - byte, short, int, long, char, float, double, boolean, along with their wrapper classes - Byte, Short, Int, Long, Character, Float, Double, Boolean.

• java.lang.String • Arrays of any value and dimension • Java Bean Styled objects – These are classes, which only meaningful

parameters are either public variables, or get() or set() methods. By default this is used to handle all kinds of special objects, which do not have any DataMarshaler associated.

• For all kinds of classes, which do not fall into these categories, there is a DataMarshaling framework, which allows serialization or nonserialization and correct WSDL generation for any user class, by providing user DataMarshalers. This topic will be covered later.

8/26

Web Services

6.1.2. WSDL Generation

The rules for generation of WSDL definitions of a bean follow the concepts lined out in the JAX-RPC specification. If the default naming is not correct for some application there is a way to change the behavior of the WSDL generator. A list of the rules used to generate the names of the elements in the WSDL definitions is provided below. The default rules can be overloaded by an entry in the MarshalDescriptor.xml. This will be covered next.

In the following description MD:<xxx> means – the content of the tag <xxx> in the MarshalDesctiptor.

• AppName := <ApplicationName> | MD:<soap-name>. • When the Schema for complex types is generated, each complex type

has either the classname of the type, or a mapping specified in the MarshalDescriptor – <name-mapping> tags for each bean.

• MessageNames o MethodMessages := AppName + <MethodName> + “_” +

(“Request” | “Response”) • PartName := (“P” + <ParameterIndex>) | MD:<param>.

o Header Messages := <MethodName> + (“_RequestHeaders” | “_ResponseHeaders”) The names of the “part” elements are the names of the headers, and their type is the type of the header.

o ExceptionMessages := <ExceptionName> + “Message” ExceptionMessages have only one part named “errorMessage”, of type “xs:string”.

• PortTypeName := AppName + “Interface” o Operation.Name := <MethodName> o Operation.Input := <MethodName> + “Request” o Operation.Output := <MethodName> + “Response” o Operation.Fault := <ExceptionName>, the type is the type of the

specified exception message. Each exception has a specific message.

• BindingName := AppName + “SOAPHTTPBinding” • Headers – If the method needs to have some Request or Response

header entries in the definition. You must use the MarshalDescription.xml.

9/26

Web Services

6.1.3. Marshal Description

This is an XML file, used to specify additional configuration needed for generation of the WSDL or runtime of a Web service. It must be located in the root directory of exactly one JAR inside an EAR, and is valid for all the beans in the application. It must be named “MarshalDescription.xml”. This is the Schema definition of this XML file:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="marshal-descriptor" type="marshalDescriptorType"/> <xs:complexType name="marshalDescriptorType"> <xs:sequence> <xs:element name="bean" type="beanType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="data-marshaler" type="dataMarshalerType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="beanType"> <xs:sequence> <xs:element name="soap-name" type="xs:string" minOccurs="0"/> <xs:element name="method-descriptor" type="methodType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="name-mapping" type="extensibleClassNameMappingType" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="class" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="methodType"> <xs:sequence> <xs:element name="soapAction" type="xs:string" minOccurs="0"/> <xs:element name="request-header" type="methodHeaderType" minOccures="0" maxOccurs="unbounded"/> <xs:element name="response-header" type="methodHeaderType" minOccures="0" maxOccurs="unbounded"/> <xs:element name="param" type="paramType" maxOccurs="unbounded" minOccurs='1'/> </xs:sequence> <xs:attribute name="method" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="methodHeaderType"> <xs:all> <xs:element name="header-name" type="xs:string"/> <xs:element name="header-type" type="xs:string"/> </xs:all> <xs:attribute name="isRequired" type="xs:boolean"/> </xs:complexType>

10/26

Web Services

<xs:complexType name="paramType"> <xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="type" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="extensibleClassNameMappingType"> <xs:all> <xs:element name="java-name" type="xs:string"/> <xs:element name="wsdl-name" type="xs:string"/> </xs:all> </xs:complexType> <xs:complexType name="dataMarshalerType"> <xs:all> <xs:element name="create-method" type="xs:string"/> <xs:element name="marshaler-classname" type="xs:string"/> <xs:element name="marshaled-class" type="xs:string"/> </xs:all> </xs:complexType> </xs:schema>

Each Marshal descriptor starts with a <marshal-desriptor> tag. Then several <bean> and several <data-marshaler> tags might follow.

<bean> - describes one specific bean of the application. To specify the bean, both the “name” and “class” attributes must be supplied. The “class” specifies the RemoteInterface class. There are three types of descendant elements <soap-name>, <method-descriptor> and <type-mapping>.

<soap-name> - specifies the name, which will be used when generating the WSDL, instead of the name of the bean. If the bean is “ExampleBean”, and you want in the WSDL, ExampleWebService to be displayed, you should use this tag.

<method-descriptor> - this element allows you to specify additional options for each method. These include - <request-header>, <response-header> and <param>. The method name is specified by the “method” attribute.

<request-header> - each element specifies a header, which is required or allowed in the SOAP request. Using the “isRequired” attribute you might specify, whether to set the required attribute on the soap:header or not. Further you should set the <header-name> and <header-type> elements. Currently only headers of type String and int are supported.

<response-header> - similarly to the <request-header> element. This element specifies headers, which could be returned by the service.

<param> - each of these tags specifies a mapping for the name of a method parameter. Since there is no way to take the names of the parameters using

11/26

Web Services

Java Reflection, by default their names are mapped like “p0”, “p1”, … and so on. If you would like to perform an overload, you have to specify a <param> element for each of the parameters in the method signature, in the correct order. The <param> element has two descendants – the new name, and the Java type of the parameter. The Java type is required in order to distinguish the methods when there are overloaded methods.

<name-mapping> - this element is used to overload the default naming of complex types generated in the <definition> element of the WSDL. By default, when the WSDL generator encounters some complex Java type, it creates a complex Schema type, which name is the class name of the Java type. If the WSDL needs to be independent of the implementation, you must use a name mapping.

6.1.4. Soap Headers – Server Side

A short explanation of how to design your session bean to use SOAP headers will be presented. Later in the topic will be explained how to use the generated proxy to set Request, or get Response headers.

To enable your bean to receive or send SOAP headers along with the Response, you must perform three tasks:

• RemoteInterface – Instead of extending EJBObject, you have to extend com.inqmy.lib.soap.headers.SOAPHeadersInterface. The latter on the other hand should extend EJBObject.

• Session bean class – Instead of implementing SessionBean, you have to implement com.inqmy.lib.soap.headers.SOAPSessionBean

• <SAPj2eeEngine_install_dir>/alone/managers/reference.txt or <SAPj2eeEngine_install_dir>/cluster/server/managers/reference.txt – you will have to add two entries to this configuration file: o reference <appName> library:webservices o reference SOAPDispatcherServlet

The bean implementation, which extends SOAPSessionBean, includes the following methods, derived from SOAPSessionBean:

• public Hashtable getRequestHeaders() throws RemoteException • public Hashtable getResponseHeaders() throws RemoteException • public Object getRequestHeader(String name) throws

RemoteException • public Object getResponseHeader(String name) throws

RemoteException

• public void setRequestHeader(String name, Object value) throws RemoteException

12/26

Web Services

• public void setResponseHeader(String name, Object value) throws RemoteException

Using them you can access the headers, and get or set them.

6.1.5. Soap Faults

Since there is no standard way to specify the fault:actor, fault:code, fault:string and fault:detail using WSDL, there is a special kind of exception, which you might throw in your methods - com.inqmy.lib.jaxm.soap.SOAPFaultException. When the SOAPDispatcher catches such an exception, it reads the special fields, and generates a proper soap:fault response. Then in the generated proxy, you might catch this exception (it is the same class) and check the proper fields. The available constructors are:

• public SOAPFaultException(String fcode, String factor, String fstring, String fdetail, Throwable t);

• public SOAPFaultException(String fcode, String factor, String fstring, String fdetail);

6.2. JMS Destinations

Currently we are working of a way to allow the Web service endpoint to be a JMS destination, which will be accessed though SOAP/HTTP Binding. That is, the requests will go to the SOAPDispatcher, which will route them to the JMS destination. So the Service Requestor, will not be informed that its request was sent through JMS.

The other possibility is the SOAP/JMS Binding, where the Service Requestor publishes the requests to a JMS destination and takes the responses from there.

Both kinds of connections are under development. If you have any questions or request, please feel free to send an email, to help us clarify the architectural questions.

13/26

Web Services

7. Client Side – Accessing Services

ProxyGenerator provides an easy way to access a Web service using the Web services toolkit.

7.1. SAP J2EE Engine SOAP Proxy Generator

7.1.1. Usage

This is the first, and currently the most reliable way to use proxies on the client side. There are a number of options, which allow you to customize the SOAP Request, for a specific server, since not all SOAP servers available now on the market have full SOAP 1.1 support. There is also a way to handle SOAP headers in the SOAPRequest and SOAPResponse.

Invoking a proxy method generates a SOAP message, which is sent to the server. The SOAP message is processed and the bean’s method is invoked. The result, which the server returns is again a SOAP message, which is then processed by the client. This SOAP message contains the result of the bean's method invocation on the server side.

If you want to access the bean, the proxy from the bean’s WSDL must be generated. The ProxyGenerator handles this task.

The class of the ProxyGenerator is com.inqmy.lib.wsdl.ProxyGenerator. It is located in <SAPj2eeEngine_install_dir>/cluster/server/additional-lib/inqmysoap.jar or <SAPj2eeEngine_install_dir>/alone/additional-lib/inqmysoap.jar file. In addition the following JAR files must be included in your classpath - mail.jar, activation.jar, inqmyxml.jar, inqmysoap.jar, located in <SAPj2eeEngine_install_dir>/cluster/server/additional-lib/ or <SAPj2eeEngine_install_dir>/alone/additional-lib/ directory. You need also the inqmy-lib.jar file in <SAPj2eeEngine_install_dir>/cluster/server/lib/ or<SAPj2eeEngine_install_dir>/alone/lib/ directory in order to run the generator. An example clarifying these issues is given below:

java –cp <absolute_jarfiles_path> com.inqmy.lib.wsdl.ProxyGenerator <wsdl_file> <proxy_output_directory> [options]

where:

14/26

Web Services

• <absolute_jarfiles_path> - specifies the full path the required JAR files.

• <wsdl_file> - the WSDL file, for which a proxy will be generated. • <proxy_output_directory> - the directory where the proxy files will be

generated.

A list of the available options follows:

• [-p package] – name of the package. • [-c] – compile the generated files. • [-j jarname] - creates JAR file with the specified jarname and includes

the compiled proxy files in it.

When generating the proxy classes, the following WSDL to Java is used (the same as described in JAX-RPC 0.7):

7.1.2. Generated Stuff

wsdl:service – for the wsdl:service tag a class is generated, having the same name as the “name” attribute of the service tag. This class has a method:

public com.inqmy.lib.wsdl.base.ProxyPortBaseSOAP getPort(String name)

which returns the port associated with this name. The returned class has to be casted to the port class. For example

Calc calcPort = (Calc)calcService.getPort(“Calc”);

wsdl:port – for each port in the service a class is generated, which has the same name as it is in the “name” attribute of the wsdl:port tag.

wsdl:operation – for each operation of this port, a method in the port class is generated having the same name and signature as described in the input and output messages. Later in this document the mapping between Schema types and Java types will be described.

7.1.3. Advanced Features

7.1.3.1. Setting HTTP Proxy

7.1.3.2. Changing Namespace Modes

7.1.3.3. Using SOAP Headers

15/26

Web Services

8. UDDI4J Pluggability

The SAP J2EE Engine Web services framework can be also plugged as a transport protocol into the IBM UDDI4J implementation. In order to perform this task, you must set as system property the following:

org.uddi4j.TransportClassName=com.inqmy.lib.soap.uddi4j.InQMySOAPTransport (for UDDI4J v2)

and include the following classes in your classpath:

• Web services framework o inqmyxml.jar o inqmysoap.jar

• HTTPS support (Required by the Publish API) o jsse.jar o jnet.jar

• Generic libraries o activation.jar o mail.jar o jaxm.jar

16/26

Web Services

9. WSIL Integration

Web Services Inspection Language (WSIL) is an xml-based protocol, which allows inspecting the Web services hosted by a server. The WSIL port of the SAP J2EE Engine is: http://<server-addr>/soapdispatcher/inspection.wsil.

17/26

Web Services

10. DataMarshalers

Let’s consider the following example of a class and a method, using this class:

public class A implements Serializable { private int b; public int getB() { return b; } public void setB(int b) { this.b = b; } }

-- and in the bean the following method is included:

public String readA(A a);

There is no way for the framework to be informed exactly which methods to call in order to set the variable b, and give an instance of the class A to the method. In this case DataMarshaler is used.

Introduction to DataMarshalers

The idea is that using a DataMarshaler and a MarshalDescription.xml (which associates the DataMarshaler classes with user classes), the framework can easily find out what kind of data should be transferred in order to get all the information from a user object. The DataMarshaler also cares for instantiating new objects using the data received, and using an object, to return a list of DataFields, which describe the object. The DataMarshaler is also used during the generation of the WSDL definition of the bean. For each user class, a DataMarshaler is searched and after that the getDataFieldList() method is invoked to see what DataFields are needed by this DataMarshaler. Then these fields are recursively described in the WSDL. In this way you only need to write a simple class specifying what kind DataFields you wish to expose and then using this DataFields, to return an instance, or using an instance to return the fields.

Note: If your application uses DataMarshalers you must add in the <SAPj2eeEngine_install_dir>/alone/managers/reference.txt or <SAPj2eeEngine_install_dir>/cluster/server/managers/reference.txt an entry in the form: reference <app_name> library:webservices

18/26

Web Services

Usage

In order to support such user classes several classes and interfaces are defined.

A is a class, which knows exactly what data is needed in order to produce DataMarshaler instance of a specific class. Also with a specified instance – what fields to expose. The Marshaling framework uses DataFieldList objects to hold the data. A DataFieldList object consists of several DataField objects. The DataField object holds information for exactly one data field of the class. It has a name, a dataClass, and a value – an instance of the data class.

getDataFieldList() : DataFieldListunmarshal(DataFieldList, SOAPContext) : Objectmarshal(Object, SOAPContext) : DataFieldList

DataMarshaler

DataFieldList(String className)add(DataField)add(int index, DataField)item(int index) : DataFieldremove(int index)size() : intclear()

DataFieldList

DataField(String name, Class dataClass)DataField(String name, Class dataClass, boolean isUbounded)reuse(String name, Class dataClass)reuse(String name, Class dataClass, boolean isUbounded)reuse(Object data)getName() : StringgetDataClass() : ClassgetData() : Objectubounded() : boolean

name : StringdataClass : Classdata : ObjectisUnbounded : boolean

DataField1

*

Usage of the methods of DataMarshaler class is explained below:

• DataFieldList getDataFieldList() – this method must return a DataFieldList, which consists of the DataFields the user wants to expose. Only the name and the dataClass should be initialized – this method is used, when generating the WSDL of the service in order to describe what kind of objects must be supplied to the framework.

19/26

Web Services

• Object unmarshal(DataFieldList, SOAPContext) – this method is used when the framework needs to create an instance of a user class and use it. The framework provides a fully initialized DataFieldList object, which has the same DataFields in the same order as they were provided by the getDataFieldList() method. Now the objects carried by the DataFields are actually instances. The user must use these objects to create an instance of the marshaled class, and return it to the framework.

• DataFieldList marshal(Object data, SOAPContext) – this method is invoked by the framework, when a user object needs to be converted to XML data. The user must use the provided Object and return a DataFieldList, with DataFields of type and order exactly as returned by the getDataFieldList() method.

Now you must include this class to your bean, and create a MarshalDescription.xml file, in the root directory of the bean’s JAR file. If your application has several beans, this file must be in exactly one JAR. It describes what DataMarshalers are provided by the user and for which classes.

The MarshalDescription.xml can also include additional information about the WSDL generation. The tag <bean name=”xxx”>, where xxx is the name of the bean, and his descendants <soapname> and <method–descriptor class=”xxx” method=”yyy”> contain this information. Neither of them is required. If any of them is omitted, the standard way of creating names (according to JSR-109) is used. The <soapname> encloses the name, which you want to be used instead of the remote class’s name. The <method–descriptor class=”xxx”

method=”yyy”>, where xxx is the name of the class from which WSDL is generated and yyy is his method, identifies the method. This tag has as many descendants as method’s parameters. The descendants have the following form: <param name=”xxx” type=”yyy”>, where xxx is the name of the parameter to be used in message and port type generation and yyy is their type. If <method-descriptor> is present his descendant must correctly describe the method’s parameter number, order and type. If any of this parameters is not correct then it is used p0, p1 … as parameters names (order respectively) and no exception will be thrown.

20/26

Web Services

MarshalDescription.xml

marshaler-classname : Stringmarshaled-class : String

data-marshaler

1

*

<marshal-descriptor><bean name="calculator"> <soapname>tester</soapname> <method-descriptor class="mycal.calRemote" method="add"> <param name="first" type="float"/> <param name="second" type="float"/> </method-descriptor> </bean> <data-marshaler> <marshaler-classname>ADataMarshaler</marshaler-classname> <marshaled-class>A</marshaled-class> </data-marshaler>

<data-marshaler> <marshaler-classname>BDataMarshaler</marshaler-classname> <marshaled-class>B</marshaled-class> </data-marshaler></marshal-descriptor>

marshal-desctiption

21/26

Web Services

11. Examples

This section will provide a short guide to the examples, supplied with the distribution. The examples can be found in <SAPj2eeEngine_install_dir>/docs/examples/WebServices/soap/ directory.

Example 1 – Calculator

This is the simplest example provided - an application, which is also shipped with the SAP J2EE Engine. It is just an Enterprise Java Bean, which has several methods for doing simple calculations on float numbers. The whole process is handled by the framework automatically.

The following procedure will show the process of deploying the bean as a Web service, generating the WSDL, generating proxy and calling the proxy methods:

1. Deploy the calc.ear file using the DEPLOY shell command or the Deploy Tool coming with the installation.

2. Use the Web services framework to access the deployed bean. This issue is covered in “4. Setting up Web Service Framework” section of this document.

3. Browse to save the WSDL in the desired directory. For additional information about the WSDL, see the table below.

4. Use the ProxyGenerator Tool to generate a proxy from the WSDL file. For more information, see “7.1. SAP J2EE Engine SOAP Proxy Generator”.

5. Run the CalcServiceTester.java. It uses the generated proxy to call bean’s methods.

Location Calculator/Server/calc.ear Source Calculator/Server/source/*.* Client Proxy Calculator/Client/source/CalcService/CalcService.java Client Tester Calculator/Client/source/CalcService/CalcServiceTester.java reference.txt line

none

WSDL http://localhost/soapdispatcher?WSDL=Calc

22/26

Web Services

Example 2 – Simple

This example also is handled fully by the framework. But it uses several Java simple types, as well as simple types wrapper classes like Integer, Short, etc. Also arrays are internally supported.

Location Simple/Server/simple.ear Source Simple/Server/source/*.* Client Proxy - Client Tester - reference.txt line none WSDL http://localhost/soapdispatcher?WSDL=SimpleBean

Example 3 – Complex1

This example shows a very simple use of DataMarshalers. The EJBean takes one class, and the DataMarshaler handles this class. Again the framework handles the WSDL generation, but this time using the provided DataMarshaler. In order to deploy and run this example you must add the line specified in the table below to the <SAPj2eeEngine_install_dir>/alone/managers/reference.txt or <SAPj2eeEngine_install_dir>/cluster/server/managers/reference.txt, so that the server can find the classes.

Location Complex1/Server/complex1.ear Source Complex1/Server/source/*.* Client Proxy - Client Tester - reference.txt line reference Complex1 library:webservices WSDL http://localhost/soapdispatcher?WSDL=Complex1Bean

Example 4 – Complex2

This is the most complex example provided. It uses two user classes, the one used by the other. Also two DataMarshalers are provided. Again you must add an additional line to <SAPj2eeEngine_install_dir>/alone/managers/reference.txt or <SAPj2eeEngine_install_dir>/cluster/server/managers/reference.txt file, which is specified in the providing table.

23/26

Web Services

Location Complex2/Server/complex2.ear Source Complex2/Server/source/*.* Client Proxy - Client Tester - reference.txt line reference Complex2 library:webservices WSDL http://localhost/soapdispatcher?WSDL=Complex2Bean

Example 5 – EchoServlet

This example shows the usage of JAXMServlet to receive SOAPMessages in a servlet and to return responses. In addition keep in mind that the corresponding line in the table below must be added in <SAPj2eeEngine_install_dir>/alone/managers/reference.txt or <SAPj2eeEngine_install_dir>/cluster/server/managers/reference.txt file. In order to run the example the following JAR files must be added to your classpath - inqmyxml.jar;inqmysoap.jar;activation.jar;mail.jar;jsse.jar;jnet.jar. These files are located in <SAPj2eeEngine_install_dir>/cluster/server/additional-lib/ or <SAPj2eeEngine_install_dir>/alone/additional-lib/ directory. It is not necessary to include jaxm.jar file in your classpath, because it is part of the inqmysoap.jar file.

Location EchoServlet/Server/echo.ear Source EchoServlet/Server/EchoServlet.java Client Tester EchoServlet/Client/EchoServletCaller.java reference.txt line reference Echo library:webservices

Example 6 – UDDI4J

The folder <SAPj2eeEngine_install_dir>/docs/examples/WebServices/soap/uddi4j/ contains several examples taken from the IBM UDDI Package. Before running them you must perform the steps required to set up the UDDI4J package to work with SAP J2EE Engine. For more information see “8. UDDI4J Pluggability” section.

24/26

Web Services

12. References

1. W3C Working Draft "SOAP Version 1.2 Part 1: Messaging Framework", Martin Gudgin, Marc Hadley, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 2 October 2001 (See http://www.w3.org/TR/2001/WD-soap12-part1-20011002/.)

2. W3C Working Draft "SOAP Version 1.2 Part 2: Adjuncts", Martin Gudgin, Marc Hadley, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 2 October 2001 (See http://www.w3.org/TR/2001/WD-soap12-part2-20011002/.)

3. W3C Recommendation "XML Schema Part 1: Structures", Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 2 May 2001. (See http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/.)

4. W3C Recommendation "XML Schema Part 2: Datatypes", Paul V. Biron, Ashok Malhotra, 2 May 2001. (See http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.)

5. W3C Recommendation "Namespaces in XML", Tim Bray, Dave Hollander, Andrew Layman, 14 January 1999. (See http://www.w3.org/TR/1999/REC-xml-names-19990114/.)

6. W3C Recommendation "Extensible Markup Language (XML) 1.0 (Second Edition)", Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 6 October 2000. (See http://www.w3.org/TR/2000/REC-xml-20001006/.)

7. W3C Note "Simple Object Access Protocol (SOAP) 1.1", Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah Mendelsohn, Henrik Nielsen, Satish Thatte, Dave Winer, 8 May 2000. (See http://www.w3.org/TR/SOAP/.)

8. Java API for XML Based RPC (JAXRPC) v0.5 - http://jcp.org/aboutJava/communityprocess/first/jsr101/

9. UDDI4J – IBM’s UDDI Implementation – http://www.uddi4j.org/.

10. Java API for XML Parsing - http://java.sun.com/xml/jaxp/index.html/.

25/26

Web Services

11. Web Services Definition Language 1.1 (Note) - http://www.w3.org/TR/wsdl.

12. Java API for XML Messaging 0.94 - http://java.sun.com/xml/jaxm/index.html.

13. Java API for XML Registries 0.7 (JAXR). Public Review Draft 2: 11/13/2001 - http://java.sun.com/xml/jaxr/index.html.

26/26