Processing HTTP messages

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

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

• You can use the broker-wide 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 brokers.

• 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 brokers.

• You can use a mixture of broker and integration server listeners by keeping or making the broker listener active, and configuring a subset of integration servers to use the embedded listener. 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 broker listener within the same integration server.

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.

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 broker 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 broker-wide listener, you can deploy the second message flow to any other integration server defined to the broker. 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 broker, you can choose to handle HTTP messages by using either the broker 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 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.