MQ and WebServices

Top

(1) SOAP over Hypertext Transfer Protocol

Process involved in creating and processing the request:

1. The client invokes a method of a class hosted by the server through a proxy of the class accessible to the client.
2. The SOAP layer, such as an implementation of SOAP provided by Microsoft .NET, Apache Axis, or WebSphere Application Server, catches the method call and marshalls the function name and parameters, creating a representation of the call in Extensible Markup Language (XML) form.
3. The XML for the method call is itself wrapped in a SOAP envelope, which is also in XML format.
4. The data built up so far is then sent to the target service as a HTTP request. Implicitly, this is over TCP/IP.
5. The HTTP request is received by a HTTP server, typically, a Web server such as the Microsoft Internet Information Services (IIS) or the Apache Web Server.
6. The SOAP data is passed to the SOAP layer by the HTTP server.
7. The server side SOAP layer parses the SOAP envelope, extracting the XML representation of the method invocation. It then extracts the data for the method call itself.
8. The SOAP layer locates the target service and invokes the function desired by the client.
9. The service runs the function and returns the results.
10. The results are returned to the client in a similar manner.

(2) SOAP over WebSphere MQ

All the steps are the same as for SOAP/HTTP except for steps 4, 5, and 6. Instead of sending the data using HTTP, the SOAP layer passes the SOAP envelope and contents to a SOAP/WebSphere MQ sender. The SOAP/WebSphere MQ sender puts the SOAP message into a queue as a WebSphere MQ message. A process known as SOAP/WebSphere MQ listener then reads the message from the queue and passes the SOAP data to the server side SOAP layer in the same manner that the Web server does in the case of HTTP. The responses are returned in a similar fashion.

SOAP, the Simple Object Access Protocol, is a protocol for exchange of information in a decentralized, distributed environment. It is an XML (Extensible Markup Language) based protocol that consists of three parts:

• an envelope that defines a framework for describing what is in a message and how to process it,
• a set of encoding rules for expressing instances of application-defined data types,
• and a convention for representing remote procedure calls and responses.

In general there are two parts to a Web service:

• The requester, or client, which issues a request to a server.
• The server, who sends a reply to the client.

The Web request has two parts:

• The Uniform Resource Identifier (URI) of a service.
• A stream of data which the remote server processes and responds to. This is often a SOAP or other web service request and response in XML.

A proxy is a class that presents the same interface and method signatures as the service, but instead of directly implementing the desired behavior, invokes the method remotely. The proxy class is generated from Web Services Description Language (WSDL), and compiled and made available locally as part of the deployment process.

In order to create a client for any Web Service, the developer creating the client requires proxy code. This proxy code allows a client developer to call a remote method as though it is a local method. The proxy hides the complexity of the underlying Web Service infrastructure from the client.

WebSphere MQ transport for SOAP allows you to send SOAP formatted messages, used in conjunction with Web services, over WebSphere MQ.

It is implemented for either Apache Axis or Microsoft .NET host environments.
Axis is available on UNIX or Windows platforms, and .NET on Windows only.

MQ Transport for SOAP (pdf)

Top

WebSphere MQ transport for SOAP is based on a traditional request/response model. In the simplest case, using proxy classes, the client program sees this as a remote procedure call.
The SOAP/WebSphere MQ client puts a message to a WebSphere MQ queue. This may be the request queue on the local queue manager or may be a remote queue in which case the message is then transported using WebSphere MQ to the appropriate SOAP/WebSphere MQ request queue.
A dedicated SOAP/WebSphere MQ listener process monitors the request queue for incoming messages and then routes them through to the target Web Service using the appropriate host infrastructure.
Two distinct types of SOAP/WebSphere MQ listener are provided, one for Apache Axis Web Services (SimpleJavaListener) and one for Microsoft .NET web services (amqwSOAPNETListener).
Note that these listeners are distinct from the standard WebSphere MQ listener invoked by the runmqlsr command. The sequence of control for this is as follows:

The client proxy is shown as optional for Axis because Axis supports three programming styles, only one of which requires a proxy, while .NET always requires a proxy.

• the SimpleJavaListener listener is provided for Axis web services and
• the amqwSOAPNETlistener listener for Microsoft .NET services

Generated scripts to manage them:

If you want to run them as a service, specify "-s" to the deployment tool, than will generate defineWMQNlistener.cmd to define the listener as a service.

For Axis web services, a sender is implemented in the final class com.ib.mq.soap.transport.jms.WMQSender which is derived from the org.apache.axis.handlers.BasicHandler class.
For Microsoft .NET services, a sender is implemented in the sealed class IBM.WMQSOAP.MQWebRequest. This class is derived from System.Net.WebRequest and System.Net.IwebRequestCreate.

Top

SOAP/WebSphere MQ is installable as part of the standard WebSphere MQ install mechanism.
It is included as part of the "Java Messaging and SOAP Transport" install option in both the server and client installation CDs.

The following components are provided with WebSphere MQ transport for SOAP:

• WebSphere MQ sender transport code for both Apache Axis and Microsoft .NET environments
• Microsoft .NET and Apache Axis SOAP/WebSphere MQ listeners for polling request queues and invoking target services
• A deployment tool, for defining web services to the host infrastructure.
  \\MQ\bin\amqwdeployWMQService.cmd
• Sample source code for a deployment tool.
• Sample Web client and Web service software that can be built, deployed and tested. Sample programs are listed in "Samples" on page 22.
• An Installation Verification Test (IVT) system for running the supplied demonstrations
  \\MQ\tools\soap\Samples\runivt.cmd
• Various set up and utility scripts
  \\MQ\tools\soap\Samples\setupWMQSOAP.cmd & \\MQ\tools\soap\Samples\SOAPCleanup.cmd

• \\MQ\tools\soap\Samples\regenDemo.cmd
• \\MQ\tools\soap\Samples\msdemobuild.cmd

The prerequisites for WebSphere MQ transport for SOAP are:

• IBM Java 2 SDK and Runtime environment, V 1.4.2
• One or both of - Apache Axis V1.1 - Microsoft .Net Framework redistributable V1.1 with Service Pack 1
• For .NET only, one of - Microsoft .NET Framework SDK V1.1 - Microsoft Visual Studio .NET 2003
• On Windows 2000 only, Microsoft Internet Information Services

A version of the Apache Axis runtime is also included in the WebSphere MQ installation media, in the prereqs/axis directory, together with a text file, axis_readme.txt, giving instructions on how to install it. It is not installed as part of the WebSphere MQ installation process. The supplied Axis.jar has been specifically patched.

Copy it to "\\MQ\java\lib\soap"

Verify the WebSphere MQ transport for SOAP using the runivt command. The command runs a number of demonstration applications and ensures that the environment is correctly set up after installation.

Before you run the runivt command, ensure that you have the following runtime environments:

• To run on Axis only:
  you must have a JavaT SDK (within SOE) available on your system. You must also include the location of the java.exe and javac.exe commands in the systems PATH environment variable.
• To run a test on .NET only (supported only on Windows):
  you must have both a Java SDK and the .NET compilers and tools on your system. To do so, access either a Visual Studio command prompt or the Microsoft Windows SDK command prompt, then add the location of the java.exe and javac.exe files to the PATH environment variable.
• To run all available the tests:
  for Windows platforms, the environment must be configured as described in the .NET test run. On UNIX and Linux platforms, the environment must be configured as described in the Axis only test run.

KC 7.5

Before running the IVT, set the environment variable WMQSOAP_HOME to specify the WebSphere MQ installation directory.

Change to a directory under which you want the IVT to deploy. Run the IVT by executing the \\MQ\tools\soap\Samples\runivt.cmd script.

The full set of tests can be executed by entering the command "runivt" with no arguments.
If you want to use the IVT to run only a single test, the name of the test should be the first argument supplied to the utility.

If we run it from "VS2013 Developer Command Prompt", then it improves a bit:

El que tenim es

I al disc

Un cop posem el fitxer a lloc, avancem un altre petit pas:

Here it says :
On Windows, if errors are reported from amqswsdl, try issuing the following command to register .asmx files as services.

The problem typically occurs on systems where IIS has not been installed, or IIS has been installed after NET. The problem is encountered when amqswsdl generates the .wsdl files. Note: The registry keys are also required to permit the listener to invoke the services. If you use your own customized deployment procedures, you might not encounter the problem until run time.

Still

Everytime building WSDL fails, we have a message in MQ log :

On a "fresh" machine (win 7, mq 7.5.0.0, VS 12, Java 1.8.0_05) all works ok

(url) If you are generating a 64-bit Java program, and your PATH envir var has the libs in this order :

Top

Samples for Java:
The following sample services and client applications are supplied for the Java environment. These can all be run using the supplied IVT.

We shall use "Axis" even under guindows, as there is some problem with .Net and "amqwdeployWMQService.cmd"

• StockQuoteAxis.java
  Defines the stock quote service. This file is used to generate the proxies required by the client code.
• SQAxis2Axis.java
  This sample provides an example of a request to an Axis service providing stock quotes.

Transport for SOAP (pdf)

Top

Apache Axis client and service applications must be written in Java.

Microsoft .NET client and service applications must be written in C#, Visual Basic, or other .NET CLR languages.

For Java, WebSphere MQ provides access to web services using the Apache Axis Web Services infrastructure.

Axis supports three programming styles: SOAP style, WSDL style and PROXY style.

• SOAP style
  Assumes that the client knows about the location and signature of the service and does not use a WSDL definition of the service.
• WSDL style
  Uses WSDL to locate the service, but still relies on the client to know the signature and prepare the parameters accordingly.
• Proxy style
  Assumes that a proxy to the service has been pregenerated from WSDL. The client calls the service via an instantiation of the proxy object and the service signature is checked at compile-time. This is likely to be the simplest and easiest option.

All three of these styles are supported in the SOAP/WebSphere MQ Java client environment.
However, SOAP style offers limited flexibility and ease of use. So, samples are provided only for WSDL and Proxy styles.

Sample \\mq/tools/soap/samples/java/clients/WsdlClients.java shows an example of a simple Java client WebSphere MQ transport test.
This calls an Axis service from an Axis client environment using WSDL Axis calls.
The programmer is responsible for referencing the correct WSDL (which can be held locally or accessed over HTTP), and using appropriate ports and bindings.

Sample \\mq/tools/soap/samples/java/clients/SqAxis2Axis.java is an example of a simple Java WebSphere MQ transport test.
This calls an Axis service from an Axis client environment using automatically generated proxy classes.
The programmer must reference the correct proxies, and the proxies will have been generated to get the remaining information correct.

Top

A web service is specified using a Universal Resource Identifier (URI). This section specifies the URI format that is supported in WebSphere MQ transport for SOAP.

The URI syntax is as follows:

This is an example of a simple URI for an Axis service:

Top

Deployment is the process of configuring the host web services infrastructure (Axis or Microsoft .NET) to recognize the prepared web service.

A deployment utility is provided as part of WebSphere MQ transport for SOAP. This consists of a Java program, com.ibm.mq.soap.util.amqwdeployWMQService, and command files amqwdeployWMQService.sh and amqwdeployWMQService.cmd, which invoke it {c:\MQ\bin\}.

Source code functionally equivalent to amqwdeployWMQService is also supplied so you can use it as the basis of your own deployment utility : {\\MQ\tools\soap\Samples\DeployWMQService.java}

Syntax diagram

Steps or actions and verifications

Top

Editem el servidor:

Editem els clients:

Editem test:

Esborrem anterior:

Generem entorn nou (as runivt.class) i executem els 3 tests:

O be, executem un sol test:

De fet, un sol test hauria de ser aixi, pero no va be:

Els 3 test Axis i els 3 de DotNet i el conjunt son :

From AMQERR01.LOG entry, we find

From now on, when I run "runivt.cmd DOTNET", a FDC is created, containing "System.IO.FileNotFoundException"

Lets split runivt.cmd into parts:

• ivt_verify.cmd : verify al pre-requisites
• ivt_create.cmd : create directories, copy files, queue manager, objects,
• ivt_run.cmd : run a test
• ivt_clean.cmd : remove files, logs
• ivt_delete.cmd : remove qmgr, etc

Top

• MQ Transport for SOAP, csqzau00.pdf - First edition (May 2005) This edition of the book applies to IBM WebSphere MQ, Version 6.0

• WebServices intro [ibm]

• MQ v8 SOAP reference [*****], as :
  • amqwdeployWMQService.cmd - deploy Web service utility. See output files, usage notes for amqwdeployWMQService

  • runivt - MQ transport for SOAP installation verification test

  • amqswsdl: takes a Web service written for .NET Framework 1 or 2, and generates the WSDL for the class, inserting the URI you provide for the WebSphere MQ transport for SOAP into the generated WSDL.

• SG24-7115 redbook : MQ Version 6 and Web Services
  I find this redbook describes MQ Transport for SOAP somewhat better than the PDF supplied with the product. - mr Tongai at mq series.net

• Apache Axis