WebSphere Message Broker, Version 8.0.0.7 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

See information about the latest product version

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 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 execution group, 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 execution group listeners by keeping or making the broker listener active, and configuring a subset of execution groups to use the embedded listener. Nodes of the same type within one execution group 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 execution group.

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 execution group that uses the embedded listener on the default port 7800, and a second execution group that uses the broker 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 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 execution group listener, you must deploy the second message flow to the same execution group.
  • If you have configured the HTTPInput node to use the broker-wide listener, you can deploy the second message flow to any other execution group 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 execution group 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 WebSphere Message Broker into an HTTP topology that takes advantage of the load-balancing and failover capabilities of IHS, see Using external web servers with WebSphere Message Broker.

Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2016Copyright IBM Corporation 1999, 2016.

        
        Last updated:
        
        Last updated: 2016-05-23 14:46:26


Concept topicConcept topic | Version 8.0.0.7 | ac56650_con