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.
- SOAP-based web services
- Other web services standards, such as REST or XML-RPC
- General HTTP messaging, where the payload might be XML
- 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).
For more information about using SOAP messages and message flow nodes, see What is SOAP?
- 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 IBM® MQ Server if you want to use an integration node listener.
Multiple integration nodes can specify the same queue manager, but deploy issues can occur if an attempt is made to reuse a unique endpoint suffix when two different integration nodes share a queue manager and use the integration node listener.
If you use an integration node listener, you must specify a default queue manager for the integration node. For more information, see Interaction between IBM App Connect Enterprise and IBM MQ.
However, if you use HTTP nodes or SOAP nodes with the integration server embedded listener, IBM 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.
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. An exception is generated when the reply is attempted.
You can include the reply node in the same message flow, or in a different message flow:
- If you configure 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 configure 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 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.