Browse Prior Art Database

Message Definition Language

IP.com Disclosure Number: IPCOM000014531D
Original Publication Date: 2000-Dec-01
Included in the Prior Art Database: 2003-Jun-19
Document File: 3 page(s) / 46K

Publishing Venue

IBM

Abstract

Current generation messaging systems or Message-Oriented-Middleware (MOM) provide facilities for reliable communication of messages from one system to another, for putting messages on queues, getting messages from queues, publishing and

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 50% of the total text.

Page 1 of 3

Message Definition Language

Current generation messaging systems or
Message-Oriented-Middleware (MOM) provide facilities for reliable
communication of messages from one system to another, for putting
messages on queues, getting messages from queues, publishing and
subscribing to topics and so on. A weakness these systems have in
common is that they have nothing to say about the content or
format of the messages that they transmit - this information is
typically thought to be application dependent.

     For heterogeneous multi-platform, multi-language
inter-operability MOM is lacking in the following areas:
* How to construct arbitrary messages in a program written in
language A, and receive and interpret them in another program

   TMwritten in language B. (For example, how can a Java
(trademark of Sun Microsystems, Inc.) program exchange
messages with a COBOL application?)
* How to construct messages on one platform, and receive and interpret them on another platform to accommodate character set encodings, numeric type-sizes and endian-ness).
* How to integrate quality of service / message context information with a message without impacting application design, separation of systems programming and applications programming concerns. * Management and maintainability of message formats used by applications.

     A Message Definition Language or MDL is proposed to address these issues. MDL is to messaging as IDL is to the world of RPCs and distributed objects.

     An MDL based system comprises: the MDL language, MDL compilers which produce language bindings for stubs and skeletons, a mechanism for marshalling MDL messages, and a mechanism for flowing request context with messages.

     MDL has several advantages over hand-crafted message manipulation: * The MDL files themselves form a succinct and language independent definition of message content * Storing MDL in a repository and providing a dynamic invocation interface (DII) would provide the ability for applications to dynamically receive and interpret new message types (this is akin to the DII and interface repository which the OMG's CORBA standard defines for distributed objects). * Maintainability is enhanced because the MDL can be compiled to produce stubs for a given environment long after the initial application development without the error-prone need to reverse engineer application code * Reliability is enhanced because the generated stub classes eliminate errors in translation of message content * Request context can be transparently flowed with messages * System and application concerns are clearly separated * Skeletons can be generated for message processing

In a preferred embodiment, MDL is an extension to the IDL defined by the OMG

1

Page 2 of 3

for the CORBA standard. An MDL file is a text file which defines the fields of a message as a message type. The fields have a name and type (any valid IDL type and name).

For example:

module Banking {
message withdrawal {
account : Banking::AccountNumber;
amount :...