Chapter 3. Mediation with WebSphere Message Broker 39
3.4.4 Message transformation with message flows
Messages have a defined structure that is known and agreed upon by the
message sender and receiver. Applications typically use a combination of
messages, including those that are defined by the following structures or
򐂰 C and COBOL data structures
򐂰 Industry standards such as X12 or EDIFACT
򐂰 XML DTDs or schemas
Mediation flows must be able transform a message from one structure to another
without drawbacks and with acceptable throughput. Messages in WebSphere
Message Broker can be transformed using one of the following ways:
򐂰 Extensible Stylesheet Language Transformations (XSLT)
򐂰 Mapping node (graphical)
򐂰 JavaCompute node
򐂰 Runtime message set and definition
When a message arrives from a transport protocol wired to the message flow run
time, the message bit stream is parsed using a physical format, such as XML.
See Figure 3-10.
Figure 3-10 WebSphere Message Broker runtime architecture
When the message format is known, the broker parses an incoming message bit
stream, using the message set and definition defined on the flow configuration,
and converts it into a logical
message tree for later manipulation. After the
Input Output
WebSphere Message Broker Runtime
Request Physical
Format associated
with a Message Set
Response Physical
Format associated
with a Message Set
Parse Content
associated with a
physical wire
Parsed Logical
associated with a
physical wire
40 Using IBM WebSphere Message Broker as an ESB with WebSphere Process Server
message has been processed by the message flow, the broker converts the
message tree back into a message bit stream. The transformation includes
reformatting the message, concatenating the strings, or changing the element
The following physical formats are supported by the broker run time:
This format is used as the default runtime configuration. The message
structure is validated and transformed using the parser specification defined
inside the message flow.
The tagged delimited string (TDS) physical format is designed to model
messages that consist only of text strings. Examples of TDS messages are
those that conform to the ACORD AL3, EDIFACT, HL7, SWIFT, and X12
standards. The TDS physical format allows a high degree of flexibility when
defining message formats and is not restricted to modeling specific industry
standards. Therefore, you can use the TDS format to model your own
The Custom Wire Format (CWF) is a physical representation of a message
that is composed of a number of fixed format data structures or elements,
which are not separated by delimiters. The CWF physical format is typically
used to describe messages that are mapped to a C structure, a COBOL
copybook, or any other programming language data structure definition.
WebSphere Message Broker typically supplies a range of parsers to parse and
write message formats. Some message formats are self-defining and can be
parsed without reference to a model. An example of a self-defining message
format is XML. In XML, the message itself contains metadata as well as data
values, enabling an XML parser to understand an XML message even if no
model is available.
Most message formats, however, are not self-defining. That is, a binary message
originating from a COBOL program and a SWIFT formatted text message do not
contain sufficient metadata to enable a parser to understand the message. The
parser must have access to a model that describes the message to parse it
Message set: A message set can have one or more physical formats on
each XML, TDS, and CWF format.

Get Using IBM WebSphere Message Broker as an ESB with WebSphere Process Server now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.