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 rsum 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 Suns 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

http://localhost/soapdispatcher in your browser.

order

to

access

the

Web

service

framework,

enter

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> <servletclass>com.inqmy.services.servlets_jsp.server.SoapServlet</servletclass> </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 beans 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. - 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>.
<bean> <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.

- 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.
<method-descriptor>

- 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.
<request-header> <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 beans 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 beans 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/additionalor <SAPj2eeEngine_install_dir>/alone/additionallib/inqmysoap.jar 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 <SAPj2eeEngine_install_dir>/cluster/server/additional-lib/ or in <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 the compiled proxy files in it.

specified jarname and includes

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.InQMySOAPT ransport (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
Lets 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 in the form: reference <app_name> library:webservices

<SAPj2eeEngine_install_dir>/cluster/server/managers/reference.txt an entry

18/26

Web Services

Usage In order to support such user classes several classes and interfaces are defined. exactly what data is needed in order to produce 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.
A is a class, which knows DataMarshaler instance of

DataMarshaler getDataFieldList() : DataFieldList unmarshal(DataFieldList, SOAPContext) : Object marshal(Object, SOAPContext) : DataFieldList

DataFieldList DataFieldList(String className) add(DataField) add(int index, DataField) item(int index) : DataField remove(int index) size() : int clear()

* 1 name : String dataClass : Class data : Object isUnbounded : boolean

DataField

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() : String getDataClass() : Class getData() : Object ubounded() : boolean

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

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.
Object unmarshal(DataFieldList, SOAPContext)

Now

MarshalDescription.xml file, in the root directory of the beans JAR file. If your

you

must

include

this

class

to

your

bean,

and

create

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 <methoddescriptor 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 classs name. The <methoddescriptor 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 methods 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 methods 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 <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 1 * data-marshaler marshaler-classname : String marshaled-class : String

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 beans methods.
Location Source Client Proxy Client Tester reference.txt line WSDL Calculator/Server/calc.ear Calculator/Server/source/*.* Calculator/Client/source/CalcService/CalcService.java Calculator/Client/source/CalcService/CalcServiceTester.java none 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 Source Client Proxy Client Tester reference.txt line WSDL Simple/Server/simple.ear Simple/Server/source/*.* none 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 Source Client Proxy Client Tester reference.txt line WSDL Complex1/Server/complex1.ear Complex1/Server/source/*.* reference Complex1 library:webservices 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 Source Client Proxy Client Tester reference.txt line WSDL

Complex2/Server/complex2.ear Complex2/Server/source/*.* reference Complex2 library:webservices 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 Source Client Tester reference.txt line EchoServlet/Server/echo.ear EchoServlet/Server/EchoServlet.java EchoServlet/Client/EchoServletCaller.java 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/WDsoap12-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-part220011002/.) 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-120010502/.) 4. W3C Recommendation "XML Schema Part 2: Datatypes", Paul V. Biron, Ashok Malhotra, 2 May 2001. (See http://www.w3.org/TR/2001/RECxmlschema-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-xml20001006/.) 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

http://jcp.org/aboutJava/communityprocess/first/jsr101/

API

for

XML

Based

RPC

(JAXRPC)

v0.5

9. UDDI4J IBMs 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 12. Java

http://www.w3.org/TR/wsdl.
API for

Services

Definition XML

Language

1.1

(Note) 0.94

http://java.sun.com/xml/jaxm/index.html.

Messaging

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