Browse Prior Art Database

Handling Messages of Unpredictable Formats

IP.com Disclosure Number: IPCOM000122919D
Original Publication Date: 1998-Jan-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 2 page(s) / 101K

Publishing Venue

IBM

Related People

Hanson, SM: AUTHOR [+3]

Abstract

In a communication system where messages of differing and unpredictable formats are being received from remote systems, identification of the message format can cause a problem.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Handling Messages of Unpredictable Formats

      In a communication system where messages of differing and
unpredictable formats are being received from remote systems,
identification of the message format can cause a problem.

      The improved described system is typically applied to a
configuration consisting of an application program running in a
system with an attached communications medium.  The system receives
incoming messages and presents them to the application program in a
form that the application program can interpret.  In order to
decouple the application from dependencies on the precise layout of
data in the message, the system uses a library of message definitions
held on an external database to analyze an incoming message and
present it to the application as a set of constituent fields.

      To do this, the system represents every message by a dynamic
Message object, consisting of a number of Field objects, one per
field in the message.  If the application knows the format of the
message that it is receiving it creates a predefined Message object
to receive  it.  The definition of a pre-defined Message object is
held on an external database and read when the Message object is
created.  Each definition lists the Field objects and their
attributes (name, data type,  length, position in message).  The
system sets the Field objects to values read from the message, and
returns the Message object to the application.

      This arrangement works well if the application knows the format
of the incoming message, and thus knows what pre-defined Message
object to create.  However there are cases when the application may
be expecting  several possible formats of message (for example a
normal and an error  response to a command may have different
formats), requiring a mechanism  that allows the appropriate Message
object definition to be selected.

      In the general case, the designer of the application has no
control over the design of the sending applications, hence, over the
choice of formats of the messages that the application will receive.
The system, thus, has to present the application with several
strategies, described below.

      To support these strategies an additional concept - the empty
Message object - is introduced.  A Message object can initially
either be "empty" or "pre-defined".  An empty Message object is one
that has no  Field objects to start with and is constructed from a
received message  dynamically.  A pre-defined Message object is one
that starts with a series of Field objects and is completed from a
rece...