Supported web services

Code that has been written to run as a web service does not need to be modified to use the IBM MQ transport for SOAP. You do need to deploy services differently to run with the IBM MQ transport for SOAP rather than using HTTP.


Description

From IBM MQ Version 8.0.0, Fix Pack 2, the IBM MQ transport for SOAP is deprecated.

The IBM MQ transport for SOAP provides a SOAP listener to run services for .NET Framework 1 and .NET 2, and for Axis 1.4. The IBM MQ custom channel for Microsoft Windows Communication Foundation runs services for .NET Framework 3. WebSphere Application Server and CICSĀ® provide support for running services over IBM MQ transport for SOAP. Create a custom Export to use WebSphere Enterprise Service Bus or WebSphere Process Server.

The IBM MQ SOAP listener can process SOAP requests transactionally. Run amqwdeployWMQService using the -x option. The two-phase option is only supported for listeners using server bindings. Other environments might provide transactional support for the IBM MQ transport for SOAP. Consult their documentation.

IBM MQ transport for SOAP currently does not support the emerging industry standard SOAP over JMS protocol that has been submitted to W3C. We can distinguish a SOAP/JMS message written to the new standard by looking for the JMS BindingVersion property. IBM MQ transport for SOAP does not set the BindingVersion property.


Axis 1.4

A Java class can typically be used without modification. The types of any arguments to the methods in the web service must be supported by the Axis engine. Refer to Axis documentation for further details. If the service uses a complex object as an argument, or returns one, that object must comply to the Java bean specification. See the examples in Figure 3, Figure 4, and Figure 5:

  1. Have a public parameter-less constructor.
  2. Any complex types of the bean must have public getters and setters of the form: getsetcomplex-type

Prepare the service for deployment using the amqwdeployWMQService utility. The service is invoked by the IBM MQ SOAP listener which uses axis.jar to run the service.

The only two-phase transaction manager supported for Axis 1.4 is IBM MQ.

The supplied deployment utility does not support the case where a service returns an object in a different package to the service itself. To use an object returned in a different package, write your own deployment utility. We can base your deployment utility on the supplied sample, or capture the commands it produces, using the -v option. Amend the commands to produce a tailored script.

If the service uses classes that are external to the Axis infrastructure and the IBM MQ SOAP run time environment, you must set the correct CLASSPATH. To change CLASSPATH, amend the generated script that starts or defines the listeners to include the services required, in one of the following ways:

  • Amend the CLASSPATH directly in the script after the call to amqwsetcp.
  • Create a service-specific script to customize the CLASSPATH and invoke this script in the generated script after the call to amqwsetcp.
  • Create a customized deployment process to customize the CLASSPATH in the generated script automatically.


.NET Framework 1 and .NET Framework 2

A service that has already been prepared as an HTTP web service does not need to be modified for use as an IBM MQ web service. It needs to be deployed using the amqwdeployWMQService utility.

The only two-phase transaction manager supported for .NET Framework 1 and .NET 2 is Microsoft Transaction Server (MTS).

If the service code has not been prepared as an HTTP web service you must convert it to a web service. Declare the class as a web service and identify how the parameters of each method are formatted. You must check that any arguments to the methods of the service are compatible with the environment. Figure 1 and Figure 2 show a .NET class that has been prepared as a web service. The additions made are shown in bold type.

Figure 1 uses the code-behind programming model for a .NET web service. In the code-behind model, the source for the service is separated from the .asmx file. The .asmx file declares the name of the associated source file with the Codebehind keyword. IBM MQ has samples of both inline and code-behind .NET web services.

.NET web services source must be compiled before deployment by the amqwdeployWMQService deployment utility. The service is compiled into a library ( .dll ). The library must be placed in the ./bin subdirectory of the deployment directory.


.NET Framework 3

Create an IBM MQ custom channel for Microsoft Windows Communication Foundation (WCF) to invoke services deployed to .NET Framework 3. See Developing WCF applications with IBM MQ for a description of how to configure WCF to use the IBM MQ transport for SOAP.


WebSphere Application Server

We can invoke web services hosted by WebSphere Application Server using the IBM MQ Transport for SOAP; see Use SOAP over JMS to transport web services.

You need to modify the WSDL generated by deployment of a JMS service to WebSphere Application Server in order to generate a web services client. The WSDL created by deployment to WebSphere Application Server includes a URI with a JNDI reference to the JMS InitialContextFactory. You need to modify the JNDI reference to Nojndi and provide connection attributes as described in URI syntax and parameters for web service deployment.


CICS

We can invoke CICS applications using the IBM MQ Transport for SOAP. See Configure your CICS system for web services.


WebSphere Enterprise Service Bus and WebSphere Process Server for Multiplatforms

WebSphere ESB and WebSphere Process Server for Multiplatforms support SOAP over JMS, with a ready built binding, only when using the default WebSphere Application Server messaging provider. Create a custom binding for JMS to support IBM MQ transport for SOAP. See JMS data bindings. See also Web services with SOAP over JMS in IBM WebSphere Process Server or IBM WebSphere Enterprise Service Bus, Part 2: Using the IBM MQ JMS provider.


Example

Figure 1. Service definition for .NET Framework 2: Quote.asmx
<%@ WebService Language="C#" CodeBehind="Quote.asmx.cs" Class="Quote.QuoteDotNet" %>
Figure 2. Service implementation for .NET Framework 2: Quote.asmx.cs
 <%@ WebService Language="C#" CodeBehind="Quote.asmx.cs" Class="Quote.QuoteDotNet" %>
using System;
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;

namespace Quote {
    [WebService(Namespace = "http://www.example.org/")]
    [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
    public class QuoteDotNet : System.Web.Services.WebService {
        [WebMethod]
        public string getQuote(String symbol){
            return symbol.ToUpper();
        }
    }
}
Figure 3. Java JAX-RPC service interface using a complex type
package org.example.www;
public interface CustomerInfoInterface extends java.rmi.Remote {
    public org.example.www.CustomerRecord 
           getCustomerName(org.example.www.CustomerRecord request) 
           throws java.rmi.RemoteException, org.example.www.GetCustomerName_faultMsg;
}
Figure 4. Java JAX-RPC service implementation using a complex type
package org.example.www;
public class CustomerInfoPortImpl implements org.example.www.CustomerInfoInterface{
    public org.example.www.CustomerRecord 
           getCustomerName(org.example.www.CustomerRecord request) 
           throws java.rmi.RemoteException, org.example.www.GetCustomerName_faultMsg {
    	request.setName(request.getID().toString());
    	return request;
    }
}
Figure 5. Java JAX-RPC service bean implementation of a complex type
package org.example.www;
public class CustomerRecord {
    private java.lang.String name;
    private java.lang.Integer ID;
    public CustomerRecord() {}
    public java.lang.String getName() {
        return name; }
    public void setName(java.lang.String name) {
        this.name = name; }
    public java.lang.Integer getID() {
        return ID; }
    public void setID(java.lang.Integer ID) {
        this.ID = ID; }
}