Implementation of WebSphere transport for SOAP on .NET Framework 1, .NET 2 and Axis 1.4
You might want to write your own IBM MQ SOAP sender and listener. Use the implementation of IBM MQ transport for SOAP on .NET Framework 1, .NET Framework 2, and Axis 1.4 as a guide.
A client program uses the appropriate web services framework in the same way as it would for the HTTP transport. It must also register the jms: prefix. The prefix is registered using either the com.ibm.mq.soap.Register.extension() Java method or the IBM.WMQSOAP.Register.Extension() CLR method.
The Axis 1.4 or .NET Framework 1 or 2 framework marshals the call into a SOAP request message exactly as for SOAP/HTTP.
An IBM MQ service is identified by a URI prefixed with jms:. When the framework identifies the jms: URI, it calls the IBM MQ transport sender code; com.ibm.mq.soap.transport.jms.WMQSender (for Axis 1.4) or IBM.WMQSOAP.MQWebRequest (for .NET1 and 2). If the framework encounters a URI with an http: prefix, it calls the standard SOAP over HTTP sender.
The SOAP message is transported by the IBM MQ SOAP sender using the request queue. The SimpleJavaListener (for Java ) or amqwSOAPNETListener (for .NET) receives the request message.
The IBM MQ SOAP listeners are stand-alone processes and are multithreaded with a customizable number of threads.
The IBM MQ SOAP listener reads the incoming SOAP request, and passes it to the appropriate web service infrastructure.
The web service infrastructure parses the SOAP request message and invokes the service. The procedure is the same as for a message that arrived on an HTTP transport.
The infrastructure formats the response into a SOAP response message and returns it to the IBM MQ SOAP listener.
The listener places the message on the response queue, and the message is transferred to the IBM MQ SOAP sender. The sender passes it to the client web service infrastructure.
The client infrastructure parses the response SOAP message and hands the result back to the client application.
Each application context is served by a separate IBM MQ request queue.
The application context is controlled in Axis 1.4 by ensuring that the IBM MQ SOAP listener and service execute in the appropriate directory. Axis 1.4 sets the correct CLASSPATH for the directory.
Application context is controlled in .NET by the IBM MQ SOAP listener executing the service in a context created by a call to ApplicationHost.CreateApplicationHost. The call specifies the target execution directory. Each service then operates in the directory in which it was deployed.
amqwdeployWMQService generates the request and response queues. It also generates the infrastructure necessary for handling the queues and deploying services to Axis 1.4.