AI world

Why do we need to model messages

IIB 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. However, most message formats are not self-defining, and a parser must have access to a predefined model that describes the message, if it is to parse the message correctly.

An example of a self-defining message format is XML. In XML, the message itself contains metadata in addition to data values, and it is this metadata that enables an XML parser to understand an XML message even if no model is available. Another example of a self-defining format is JSON.

Examples of messages that do not have a self-defining message format are CSV text messages, binary messages that originate from a COBOL program, and SWIFT formatted text messages. None of these message formats contain sufficient information to enable a parser to fully understand the message. In these cases, a model is required to describe them.

Even if your messages are self-defining, and do not require modeling, message modeling has the following advantages:

• Runtime validation of messages. Without a message model, a parser cannot check whether input and output messages have the correct structure and data values.
• Enhanced parsing of XML messages. Although XML is self-defining, all data values are treated as strings if a message model is not used. If a message model is used, the parser is provided with the data type of data values, and can cast the data accordingly.
• Improved productivity when writing ESQL. When you are creating ESQL programs for IIB flows, the ESQL editor can use message models to provide code completion assistance.
• Drag-and-drop operations on message maps. When you are creating message maps for IIB message flows, the Graphic Data Mapping editor uses the message model to populate its source and target views. Without message models, you cannot use the Graphical Data Mapping editor.
• Reuse of message models, in whole or in part, by creating additional messages that are based on existing messages.
• Generation of documentation.
• Provision of version control and access control for message models by storing them in a central repository.

To make full use of the facilities that are offered by IIB, model your message formats.

To speed up the creation of message models, importers are provided to read metadata such as C header files, COBOL copybooks, and EIS metadata, and to create message models from that metadata. Additionally, predefined models are available for common industry standard message formats such as SWIFT, EDIFACT, X12, FIX, HL7, and TLOG.

XML Schema 1.0 (XSD) is an open standard modeling language from the World Wide Web Consortium (W3C) that was designed to model and validate XML documents. However, it can also be used to express the logical structure of all data formats. For more information about XML Schema, see XML Schema.

Data Format Description Language 1.0 (DFDL) is an open standard modeling language from the Open Grid Forum (OGF) that builds upon the features of XSD 1.0 in order to model and validate all kinds of general text and binary data. It uses standard XSD model objects to express the logical structure of the data, together with DFDL annotations to describe the text or binary physical representation. For more information about DFDL, see Data Format Description Language (DFDL).

WebSphere Adapter Schema is an IBM® extension to XSD 1.0. It uses the standard XSD model objects to express the logical structure of data, along with special annotations that are used when exchanging data with EIS systems that use the WebSphere Adapters of the broker.

A fragment of a DFDL schema that shows how delimited text data can be modeled.

Consider the following delimited ASCII text data:

int=5;float=-7.1E8

In this data

• int= and float= denote the start of an element. They are initiators.
• The semicolon after 5 marks the boundary between the two elements in a sequence, and is a separator.
• 5 is an integer in ASCII text.
• -7.1E8 is a floating point number in ASCII text.

This is represented in a DFDL schema file as follows:

<xs:complexType name="myNumbers">
  <xs:sequence>

    <xs:annotation>
      <xs:appinfo source="http://www.ogf.org/dfdl/v1.0">
        <dfdl:sequence separator=";" encoding="ascii"/>
      </xs:appinfo>
    </xs:annotation>

    <xs:element name="myInt" type="xs:int">
      <xs:annotation>
        <xs:appinfo source="http://www.ogf.org/dfdl/v1.0">
          <dfdl:element representation="text"
                textNumberRep="standard" encoding="ascii"
                lengthKind="delimited" initiator="int=" …/>
        </xs:appinfo>
      </xs:annotation>
    </xs:element>

    <xs:element name="myFloat" type="xs:float">
      <xs:annotation>
        <xs:appinfo source="http://www.ogf.org/dfdl/v1.0">
          <dfdl:element representation="text"
                textNumberRep="standard" encoding="ascii"
                lengthKind="delimited" initiator="float=" …/>
        </xs:appinfo>
      </xs:annotation>
    </xs:element>

  </xs:sequence>
</xs:complexType>