WebSphere MQ Web Services Transport

WebSphere MQ Web Services Transport is a service that connects Web services clients that use the HTTP protocol for messaging.

Web services clients use non-persistent, non-transactional messaging to communicate with other applications. WebSphere Business Integration Message Broker provides support to allow these clients to communicate with other applications through message flows in a broker.

The clients are either service providers or service requesters. Service providers publish their services, defined in WSDL, to a registry. The service requesters query the service registry to find information about available services, including where these services are and how to bind to them.

The ability to communicate with a broker means that Web services clients can communicate with applications that use other supported protocols and transports, if the message flow is configured to provide this function.

For more information, follow the Web services link on the developerWorks Web site.

Web services message format

Messages that pass across this transport have an XML format that provides platform-independence. The XML content that defines specific operations, and error situations (SOAP Fault), is defined by the SOAP standard. Because delivery is not guaranteed, applications must provide recovery in the event of system or network failures.

A message contains components that are appropriate to its type:

Command string
A request message contains the command POST followed by a URL. The command string ends with HTTP/1.0.
Status line
A response message contains a status line that starts with HTTP/1.0 , and indicates the success or failure of the request with a code and text, for example 200 OK, 404 Not Found, 500 Server Error.
Headers
The headers used by the Web services protocol are HTTP headers that consist of a name followed by the characters colon and (optionally) a space, followed by the value (contents) of the header. Each header is followed by the characters CRLF. The final header is followed by CRLFCRLF, which creates a blank line. Data following this line is interpreted as message body data. Headers are described in Web services headers.
Body
The message body is the data following the headers in the message (that is, following the characters CRLFCRLF). For an inbound message received by the HTTPInput or HTTPRequest node, this data is typically parsed according to the settings of the message properties in the node. For outbound messages, the data is typically parsed according to the settings of the message properties in the Properties folder received by the HTTPReply or HTTPRequest node that parses the message from message tree to bit stream.

In most cases, the body of a message is XML. However, an inbound message can contain a different format if the receiving node is configured to handle that format and the appropriate parsers are available. An outbound message can contain a body of any format that is accepted by the Web service to which it is sent.

An error that is generated by a component other than a Web service (for example, 404 Not Found) might result in a message that is in HTML format.

The bit stream containing headers and body are parsed and represented within the message tree when an input request is received by an HTTPInput node, or when a response from a Web service is received by the HTTPRequest node. A bit stream is created by parsers from the appropriate parts of the message tree when a reply is sent to the client by the HTTPReply node, and when a request is sent to a Web service by the HTTPRequest node. For further details about these actions, see the individual node descriptions.

Web services headers

When a message is received from a Web service client or Web server, the HTTPInput or HTTPRequest node that receives that message must parse the HTTP headers to create elements in the message tree. When an HTTPReply or HTTPRequest message sends a message to a Web service client or Web server, it parses the HTTP headers from the message tree into a bit stream.

The HTTP headers in a message depend on the type of message that is processed. There are four message types recognized in a message flow, and a parser is associated with each of these.

  1. Input. An input message is received by the HTTPInput node from a Web service client. The HTTP headers in the input message (data up to and including the CRLFCRLF) are parsed by the HTTPInput parser and are included in the message tree under the correlation name HTTPInput. The headers shown in the following table are expected in an input message; others might also be present.
    Header Content Example
    Host The hostname to which the client issued the message. localhost
    Content-Length The length of the body of the input message in decimal (that follows the CRLFCRLF after the last header). 520
    Content-Type The type of the body data. text/xml; charset=utf-8
    SOAPAction   "" (empty string)
  2. Reply. A reply message is sent by the HTTPReply node to the Web service client that sent the corresponding input message. The Web service headers in the reply message are created in the message tree under the correlation name HTTPReply, which is also the name of the parser used to parse that part of the message tree to a bit stream. You can choose to create your own HTTPReply header in a Compute node, or you can configure the HTTPReply node to create it using default values, or values taken from the HTTPInput or HTTPRequest trees in the input message, or both. If the HTTPReply node creates a default HTTPReply header, it contains the Web service headers and values shown in the following table.
    Header Value
    Content-Length (if present in the input message) The calculated length of the reply message body in decimal.
    Content-Type text/xml; charset=utf-8
  3. Request. A request message is sent to a Web server by the HTTPRequest node. The HTTP headers in this message must be created in the message tree under the correlation name HTTPRequest, and are parsed by the HTTPRequest parser when the message tree is parsed to a bit stream. You can choose to create your own HTTPRequest header in a Compute node, or you can configure the HTTPRequest node to create it using default values, or values taken from the HTTPInput or HTTPRequest trees in the input message, or both. If the HTTPRequest node creates a default HTTPRequest header, it contains the Web service headers and values shown in the following table.
    Header Value
    Host Value set in the Default Web Service URL property.
    Content-Length The calculated length of the request message body in decimal.
    Content-Type text/xml; charset=utf-8
    SOAPAction "" (empty string)
  4. Response. A response message is received by the HTTPRequest node from the Web server to which the corresponding request message was sent. The HTTP headers in the response message (data up to and including the CRLFCRLF) are parsed by the HTTPResponse parser and are included in the message tree under the correlation name HTTPResponse. The header shown in the following table is expected in a response message (though not required); others might also be present.
    Header Content Example
    Content-Length The length of the response message body in decimal. 1585

Example messages provides example messages that include these headers.

Example messages

The following message provides an example of a request sent by an HTTPRequest node to a Web service that provides a look-up service:

POST /greenpages/servlet/rpcrouter HTTP/1.0
Host: localhost
Content-Type: text/xml; charset=utf-8
Content-Length: 520
SOAP Action: ""
Cookie: JSESSIONID=0000B5OSLFIUDMQZFAUXKHD5ZDQ:-1

<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schema.xmlsoap.org.soap/envelope/"
                   xmlns:xsi="http://www.w3/2001/XMLSchema-instance"
                   xmlns:xsd="http://www.w3/2001/XMLSchema">
<SOAP-ENV:Body>
<ns1:getUserByName xmlns:ns1="http://tempuri.org/imb.GreenPages"
                   SOAP-ENV:encodingStyle="http:/schemas.xmlsoap.org/soap/encoding/">
<nameField xsl:type="xsd:string">bloggs, joe</nameField>
</ns1:getUserByName>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

The following message is an example of the response that might be returned to the HTTPRequest node:

HTTP/1.0 200 OK
Server: WebSphere Application Server/4.0
Content-Type: text/xml; charset=utf-8
Content-Length: 1585
Content-Language: en
Connection: close

<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schema.xmlsoap.org.soap/envelope/"
                   xmlns:xsi="http://www.w3/2001/XMLSchema-instance"
                   xmlns:xsd="http://www.w3/2001/XMLSchema">
<SOAP-ENV:Body>
<ns1:getUserByNameResponse xmlns:ns1="http://tempuri.org/imb.GreenPages"
                   SOAP-ENV:encodingStyle="http:/schemas.xmlsoap.org/soap/encoding/">
<return xmlns:ns2="http://www.greenpages.com/schemas/GreenPagesRemoteInterface"
        xsi:type="ns2:imb.UserRecord">
<fullName xsi:type="xsd:string">Joseph Bloggs</fullName>
<empNum xsi:type="xsd:int">65874</empNum>
<deskPhone xsi:type="xsd:string">(718)545-3623</deskPhone>
</return>
</ns1:getUserByNameResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Related concepts
Message flows
Generate Web Services Description Language (WSDL)

Related tasks
Developing message flow applications
Generating a Web Service Definition from a message set
Deploying message flow applications

Related reference
WebSphere MQ Web Services Transport

developerWorks Web site