Developing IBM MQ web service clients for IBM MQ transport for SOAP

Use your normal development environment to develop web service clients for use with the IBM MQ transport for SOAP.

Before you begin

Create the service. We can use one of the examples in Developing web services for IBM MQ transport for SOAP.

Make choices about how you are going to develop, deploy and use the clients, and where to go to get the WSDL for client generation.

Decide on your approach to developing clients and services for IBM MQ transport for SOAP.

There are two approaches.

1. Use standard development tools, develop an HTTP service and client, and then use the URL for WebSphere MQ transport for SOAP.
2. Use the tools and samples supplied with IBM MQ transport for SOAP.

If you take the HTTP route, we can run the service on an HTTP server and also run it using IBM MQ transport for SOAP. To run it using IBM MQ transport for SOAP, configure the appropriate IBM MQ listener for SOAP and set up the paths and deployment descriptors to run the service. The tools provided by IBM MQ transport for SOAP do the configuration for you. Alternatively, we can configure the environment to run the listeners.

The tools supplied with IBM MQ transport for SOAP are useful in getting started and learning how to deploy the transport. For production work, there are benefits in using standard tools, and deploying the same service accessible to different SOAP transports.

Decide on the type of client to develop

You must decide what type of web service client to develop. The choice depends on whether you know the service interface and the address of the service.

If the interface is known, use Axis or .NET tools to generate proxy client classes from the service interface. The proxy client classes make it easier to write a client to call the service. If the location of the service is known when you develop the client, then use the static proxy interface. If the location of the service changes, for example if the service is redeployed onto a production server, then use the dynamic proxy interface.

If the service interface is not known at the time you develop a client, on Axis, we can create a Dynamic Invocation Interface (DII) client for Axis 1.4. A DII client uses a generic interface to call any service. To pass parameters to a particular service correctly, you need to build the specific service interface programmatically. Build the interface programmatically in the client, or by loading the WSDL for the service into the client. On Axis2, we can create a Dispatch client. The Dispatch client uses a document model to describe the client request, whereas a DII client uses a call model. Both work on building the request dynamically.

Obtain the WSDL for the service

Except for the case of the service interface being built programmatically, you must first obtain the service WSDL in order to create a web service client. The service WSDL is obtainable from three different sources:

1. Directly from the web service implementation using a tool such as java2wsdl (Axis) or disco (.NET).
2. By querying the web service using the URL: Web service http url ?wsdl.
3. From a file, either on a file system, or from a registry such as UDDI or WebSphere Service Registry and Repository.

Note: If the service is not accessible using HTTP, then the WSDL query does not work. The service itself might only be available using the IBM MQ transport for SOAP.

The WSDL generated by amqwdeployWMQService is not the same as WSDL generated using java2wsdl or disco. The generated WSDL is also different to any WSDL you might have started with to create the service "Top Down". On Axis, the server-config.wsdd deployment descriptor maps the SOAP message produced by a client to an operation and service. amqwdeployWMQService generates a different deployment descriptor from Eclipse.

The WSDL we use to build clients depends on how the service is deployed:

Deployed using amqwdeployWMQService

Use the WSDL generated by amqwdeployWMQService. Specify the -w flag and select rpcLiteral WSDL. For compatibility, we can select rpcEncoded WSDL. rpcEncoded WSDL works only with .NET and Axis 1.4 clients.

Manual deployment using SimpleJavaListener

Use one of the following WSDL files:

1. WSDL used to define the service, or stored in a repository.
2. WSDL generated from the service by java2wsdl.
3. WSDL queried using the URL Web service http url ?wsdl, if available from an HTTP server. You might run a tool such as Web Services Explorer to import the service definition directly into Eclipse.

You might need to change the URI for the service. Change it from the address of the HTTP service, to the URI for the IBM MQ transport for SOAP.

Manual deployment using amqSOAPNETListener.

Use one of the following WSDL files:

1. WSDL used to define the service, or stored in a repository.
2. WSDL obtained from the .NET service class (.asmx). using disco.
3. WSDL queried using the URL web services http url ?wsdl, if available. You might run a tool such as Web Services Explorer to import the service definition directly into Eclipse.
4. WSDL obtained by running amqswsdl against the .NET service class (.asmx).

You might need to change the URI for the service. Change it from the address of the HTTP service, to the URI for the IBM MQ transport for SOAP.

Deployed to Windows Communication Foundation

Obtain the service WSDL by using the URL Web service http url ?wsdl. The service must be defined with the serviceMetaData behavior configuration as part of the service definition.

Deployment to a different server platform.

Follow the guidance provided with the platform about how to obtain the correct service WSDL.

About this task