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

XML domain message flows

If you are not using the SOAP domain, your message flow must take account of the bitstream format of the Web service messages with which you are working. A different logical tree format is used by each domain.

If the messages are SOAP, you can use either the XMLNSC domain or the MRM XML domain. Both domains offer validation. The XMLNSC domain is more efficient, while the MRM XML domain can be useful if you have specific message transformation requirements (for example, if your message flow also uses binary data formats).

If the messages use MIME (for example, SOAP with Attachments or MTOM), you can use the MIME domain. In this case, your message flow typically needs to identify at least the MIME part that corresponds to the SOAP payload, then explicitly parse this part by using the XMLNSC or MRM domain.

In the SOAP domain, WSDL is used to configure your nodes automatically with the appropriate endpoint information. If you are not using the SOAP domain, select and configure the transport nodes manually. Typical WSDL bindings are:
  • SOAP/HTTP; in which case, implement a flow by using HTTP nodes. Use the HTTPInput and HTTPReply nodes if a flow implements a Web service, or use the HTTPRequest node if a flow calls a Web service.
  • SOAP/JMS; where you implement a flow by using JMS or MQ nodes.

You can configure message flows that receive input messages from clients by using one transport, and interact with a Web service or legacy application by using another.

You can propagate a message to more than one location. For example, the Web service response to be returned to a client by an HTTPReply node might first be sent to an auditing application by using an MQOutput node, after making any required adjustments to the message headers.

Nodes are used together in the following basic patterns, by using HTTP nodes as example transports:
  • As a Web service provider, for example:
    An HTTPInput node is connected to an HTTPReply node
  • As a Web service consumer, for example:
    An input node is connected to an HTTPRequest node, which is connected to an output node
  • As a Web service facade, for example:
    An HTTPInput node is connected to an HTTPRequest node, which is connected to an HTTPReply node

If required, you can use the SOAPExtract and SOAPEnvelope nodes in conjunction with these patterns to respectively extract the SOAP payload and rebuild a SOAP Envelope.

To enable your message flow to validate messages, deploy an appropriate application, library, or message set with the flow. The application, library, or message set must contain a WSDL file. You can import a WSDL file into an application or library, or you can generate a WSDL from an existing message set. For details about importing existing WSDL, see Importing from WSDL. For details about generating WSDL from an existing message set, see Message Sets: WSDL generation.

If you have generated a WSDL file from a message set, the generated message set contains message definitions for the relevant SOAP Envelope version and for the XML payload data defined by the WSDL. If you have imported a WSDL file into an application or library, message roots are created instead of message definitions. In the XMLNSC domain, messages can be validated against the message set, application, or library. In the MRM domain, messages can be validated against a message set only. For more details, see Validating messages.

Notices | Trademarks | Downloads | Library | Support | Feedback

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

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


Concept topicConcept topic | Version 8.0.0.7 | ac34520_