Processing HTTP messages

Hypertext Transfer Protocol (HTTP) is an Internet protocol that is used to transfer and display hypertext and XML documents on the Web.

You can configure message flows that include the HTTP or SOAP nodes to access the HTTP transport to work with the following resources:
  • SOAP-based web services
  • Other web services standards, such as REST or XML-RPC
  • General HTTP messaging, where the payload might be XML
HTTP nodes can process non-secure (HTTP) messages and secure (HTTPS or HTTP over SSL) messages.
For SOAP-based web services, several advantages exist if you use the SOAP nodes and the SOAP message domain instead of the HTTP transport nodes and XMLNSC message domain.
  • Support for WS-Addressing, WS-Security and SOAP headers.
  • A common SOAP logical tree format, independent of the bitstream format.
  • Runtime checking against WSDL.
  • Automatic processing of SOAP with Attachments (SwA).
  • Automatic processing of Message Transmission Optimization Mechanism (MTOM).
Although the HTTP nodes can process SwA messages, you must use the MIME message domain and design your flow to handle the attachments explicitly, and use custom logic to extract and parse the SOAP.

For more information about using SOAP messages and message flow nodes, see What is SOAP?

You can choose how your HTTP and SOAP nodes interact with the TCP/IP network:

  • You can use the integration node listener, which receives HTTP messages on one port, and HTTPS messages on a second port.

    This option is set as the default configuration for HTTP nodes for both existing and new integration nodes.

  • You can use the listener that is embedded within each integration server, which also has two ports for HTTP and HTTPS messages.

    This option is set as the default configuration for SOAP nodes for both existing and new integration nodes.

  • You can use a mixture of integration nodes and integration server listeners by keeping or making the integration node listener active, and configuring a subset of integration servers to use the embedded listener. Message flow nodes of the same type within one integration server must use the same type of listener. For example, you cannot have SOAP nodes that use the embedded listener and SOAP nodes that use the integration node listener within the same integration server.

The integration node listener requires access to system queues on the queue manager specified on the integration node, so you must install WebSphere® MQ Server if you want to use an integration node listener. However, if you use HTTP nodes or SOAP nodes with the integration server embedded listener, WebSphere MQ is not required.

For more information about why you might choose each option, and how to configure them, see HTTP listeners.

The following diagram shows the use of both types of listener, configured on default ports, for HTTP messages.

This diagram shows an integration server that uses the embedded listener on the default port 7800, and a second integration server that uses the integration node listener on default port 7080.

You must always use the correct reply node that matches your input node; you cannot combine an HTTPReply node with a SOAPInput, or a SOAPReply node with an HTTPInput node. The integration node generates an exception when the reply is attempted.

You can include the reply node in the same message flow, or in a different message flow:

  • If you have configured the HTTPInput node or SOAPInput node to use the integration server listener, you must deploy the second message flow to the same integration server.
  • If you have configured the HTTPInput node to use the integration node listener, you can deploy the second message flow to any other integration server defined to the integration node. This is not the case for the SOAPInput node.
  • You must pass the correct reply identifier from the input message flow to the reply node.

If you are using SOAP nodes and HTTP nodes in message flows on a single integration node, you can choose to handle HTTP messages by using either the integration node listener or embedded integration server listeners. If a listener in your configuration receives messages that both SOAPInput and HTTPInput nodes might get, you must carefully check the URL specifications in these nodes. If both URL specifications match an incoming message, the wrong type of node might get the message, and processing might fail or produce unexpected results. This situation occurs if you specify identical values for the Path suffix for URL properties of the HTTPInput node and the SOAPInput node. It can also occur if you use wildcards in either or both specifications, and an incoming message matches both properties.

For more information about using the WebSphere Broker HTTP Transport, see the following topics:

For information about using HTTPS, see Implementing SSL authentication.

You can also use the HTTP Proxy servlet in an external Web servlet container to provide listener support for a larger number of concurrent HTTP sessions. For more information about the servlet and its uses, see HTTP proxy servlet overview.

For information about how to integrate IBM® HTTP Server (IHS) and IBM Integration Bus into an HTTP topology that takes advantage of the load-balancing and failover capabilities of IHS, see Using external web servers with IBM Integration Bus.