MESSAGE MODELLING

Much of the business world relies on the exchange of information between applications. The information is contained in messages having a defined structure, which is known and agreed, by the sender and the receiver. You will probably find that your applications use a combination of messages, including those defined by: C and COBOL data structures Industry standards such as SWIFT or EDIFACT XML DTD or schema

You can model a wide variety of message formats which can be understood by WebSphere Business Integration Message Broker message flows. Once the message format is known, the broker can parse an incoming message bit stream and convert it into a logical message tree for manipulation by a message flow. After the message has been processed by the message flow, the broker converts the message tree back into a message bit stream. Message modeling concepts Message modeling is a way of predefining the message formats used by your applications. Once you have modeled your messages, products like WebSphere Business Integration Message Broker can use your message models to automatically parse and write your message formats. When you model messages you need to understand the following concepts: Message set projects Message sets Message definition files Message categories Model importers Model editors Model generators Model validator Domains and parsers

A message set project is a specialized project (container) in which you create and maintain all the resources associated with exactly one message set. A message set is a logical grouping of your messages and the objects that comprise them (elements, types, groups). The content of a message set is:
Exactly Zero Zero

one message set file

or more message definition files or more message category files

The message set file provides message model information that is common across all the messages in the message set. You can create this information using the message set editor. Once you have created a message set, you typically import application message formats described by XML DTD, XML Schema, C structures or COBOL structures, creating and populating message definition files. You can then edit the logical structure of your messages, and create and edit physical formats that describe the precise appearance of your message bit stream during transmission, using the message definition editor. Alternatively, you can create an empty message definition file and create your messages using just the editor. When your message definition files are complete, you can then generate the message set in a form that can be used by an application. This could be as: A message dictionary for deployment to a broker
An

XML Schema for use by an application to validate XML messages for a Services Description Language (WSDL) for a web services client (as HTML) to give to programmers or business analysts

particular physical format

Web Documentation

Messages can be optionally grouped into message categories, both for convenience and to aid the generation of WSDL. You can add messages to message categories using the message category editor.

Message categories
Message category files have the suffix .category. These files are optional. You can have many message category files in a message set. A message category provides another way of grouping your messages, perhaps for documentation or convenience purposes, or for assisting in the generation of Web Services Description Language (WSDL) files. A message set category file is created using the New Message Category File wizard. When you have created your message category file, you must specify one key property.

Message Category Kind This indicates whether the message category is to participate in the generation of WSDL files. See Generate Web Services Description Language (WSDL). You can then add messages to the message category file. If the message category is to participate in WSDL generation, you should assign appropriate values to the Role Name and Role Type properties of each member message.

Message category identification

The name of a message category is provided by the name of the .category file. You can change the message category name by renaming the file. Each time you save a message set file, message definition file or message category file, the content is validated to ensure that the message model you are creating follows certain rules. There are rules for both the logical structure and the physical formats. The validation ensures the integrity of your model, but does not necessarily prevent you saving an invalid message model file. A product such as WebSphere Business Integration Message Broker typically supplies a range of parsers to parse and write message formats. Each parser is suited to a particular class of messages (fixed-length binary, delimited text, XML and so on) known as a message domain. Each message set you create specifies a domain, which determines the parser that is used when parsing and writing messages defined within that message set.

Which message domain and format to use?

Each message set you create specifies a domain, which determines the parser that is used when parsing and writing all messages defined within that message set. Each domain is suited to a particular class of messages (fixed-length binary, delimited text, XML and so on). Additionally, some domains support several physical formats (sometimes called wire formats). When you create a message set you need to decide which domain and physical format to use. You can select one of the following domains:

The MRM domain

The MRM domain can be used for modeling a wide range of messages. The key features of the MRM domain are: Support for modeling messages from legacy applications written in C, COBOL, PL/1 and other languages, using the Custom Wire Format (CWF) physical format. This support includes the ability to create a message model directly from a C header file or COBOL copybook. Support for modeling XML messages, including those that exploit XML namespaces, using the XML Wire Format (XML) physical format. This

support includes the ability to create a message model directly from an XML DTD or XML Schema file. Support for modeling formatted text messages, perhaps with field content identified by tags or separated by specific delimiters or both, using the Tagged Delimited String Format (TDS) physical format. This includes industry standards such as SWIFT, EDIFACT and X12. Easy transformation from one physical format to another. For example, a model can be created by importing a C header file, and the equivalent XML Schema can be generated for use by a different application. The MRM domain comes with a specialized parser that is used by runtime products such as WebSphere Business Integration Message Broker. Once you have completed your message set, you generate a message dictionary, which is deployed to the runtime product. The MRM parser then uses the dictionary to parse and write messages that are defined within that message set. The MRM parser can perform runtime validation of messages against the deployed dictionary.

The XML domains

The XML and XMLNS domains can be used for modeling messages conforming to the W3C XML standard. The XMLNS domain should be used if your messages exploit the namespaces feature of the XML specification. Note that it is often not essential to model messages in the XML or XMLNS domains at all. For example, WebSphere Business Integration Message Broker parses XML and XMLNS domain messages without reference to any message model.

The JMS domains

The JMSMap and JMSStream domains can be used for modeling messages produced by the WebSphere MQ implementation of the Java Messaging Service standard. These message types map naturally to the XML domain, and are therefore supported in an identical fashion to XML domain messages. The XML domain supports messages conforming to the W3C XML standard that do not exploit XML namespaces. If your JMS messages exploit XML namespaces you should use the XMLNS domain instead. Alternatively you can define JMS messages in the MRM domain if you choose, and so take advantage of the extra features of the MRM domain such as message validation. Choose the domain which best fits your messaging needs:

If your messages are in XML, use either the XML Wire Format in the MRM domain, or use the XML or XMLNS domains. Usually, you will find that the MRM domain offers more flexibility. See XML messages in the MRM and XML domains for more details on the relative strengths and weaknesses of these options. If your messages come from a legacy application written in a language such as C or COBOL or PL/1, or consist of fixed-format binary data (possibly including null-terminated strings), use the Custom Wire Format in the MRM domain. If your messages consist of formatted text, perhaps with field content identified by tags or separated by specific delimiters or both, use the Tagged Delimited String Format in the MRM domain. If you use JMS messages, use either the XML domain, or one of the JMS domains.

Alternatively, you can specify your own domain. You would typically do this if you were using WebSphere Business Integration Message Broker and had written a custom plugin parser to parse your messages, instead of using the MRM or XML parsers.