Meta-model for associating multiple physical representations of logically equivalent entities in messaging and other applications

A meta-model for creating models of alternative physical representations of logically equivalent entities, such as alternative wire format representations of logically equivalent messages, includes a logical meta-model and a physical meta-model. The logical meta-model provides logical entity component classes for creating a logical model which describes, in a platform and programming language neutral manner (e.g. as an XML schema), the logical structure of the modeled entity as a hierarchy of logical entity components. The physical meta-model provides classes for creating a physical model which describes the alternative physical representations. The physical meta-model includes Base Classes representative of generic physical representations of the logical entity components, with “correspondence associations” being defined between the Base Classes and corresponding logical entity component classes. The physical meta-model further includes at least one set of physical representation-specific, Derived Classes descendent from the Base Classes.

FIELD OF THE INVENTION

The present invention relates to meta-models (i.e. models for generating models), and more particularly to a meta-model for generating models which represent alternative physical representations of logically equivalent entities, such as alternative wire format representations of logically equivalent messages.

BACKGROUND OF THE INVENTION

In large enterprises, there is often a need to share data and generally intercommunicate between many operating systems, platforms, and applications. A stumbling block to the goal of intercommunication is the fact that each different computer system may represent messages using a different message protocol or physical “wire format” (i.e. manner of laying out a message on the wire).

For example, in a particular wire format, a message M1may be defined to have the following structure:

In another wire format, the same message M1might have a different structure, e.g., where a delimiter is introduced between the fields and the message appears as a single string for example.

In a third wire format which uses tags, the message M1may have still another structure in which tags (e.g. “<tagname>”) identify the separate fields.

Distinct wire formats may further differ in terms of numerous other characteristics such as byte alignment, padding characters, and sign conventions, to name but a few. Some of these differences may be due to the use of different platforms or different compilers on distinct machines for example. Disadvantageously, a target computing system using one wire format may be incapable of receiving or accurately representing the message M1sent in another wire format without a conversion of the message into a wire format suitable for the target system.

As the number of message formats increases, so too does the complexity of introducing a new format, given that one must be able to convert the new format to each existing format and vice versa. Given N message formats, the conversion problem is essentially an N×N problem, which can be onerous to solve.

Beyond the messaging realm, any conversion between numerous alternative physical representations of the same underlying information suffers from the same problem. For example, two doctors may use different approaches for capturing patient information. One may use a proprietary PC-based database management system while another may use a Unix-based file system. In this case, inter-office sharing of patient records may be difficult even though the underlying patient information may have the same logical structure (e.g. a patient address having the usual fields, a medical history, etc.).

What is needed is a manner of modeling alternative physical representations of logically equivalent entities in electronic form which supports conversion between alternative physical representations, for use by a developer of computer-based tools for performing entity conversions for example.

SUMMARY OF THE INVENTION

A meta-model for creating models of alternative physical representations of logically equivalent entities, such as alternative wire format representations of logically equivalent messages, includes a logical meta-model and a physical meta-model.

The logical meta-model provides logical entity component classes for creating a logical model which describes, in a platform and programming language neutral manner, the logical structure of the modeled entity as a hierarchy of logical entity components (i.e. elements, attributes or types). The logical meta-model may constitute classes representing eXtensible Markup Language (XML) schema components, which may be instantiated to create a logical model of the entity in the form of an XML schema.

The physical meta-model provides classes for creating a physical model which describes the alternative physical representations. The physical meta-model includes Base Classes representative of generic physical representations of the logical entity components for which logical entity component classes are defined, with “correspondence associations” being defined between the Base Classes and the corresponding logical entity component classes. The physical meta-model further includes at least one set of physical representation-specific, Derived Classes descendent from the Base Classes. Each set of Derived Classes is associated with a particular physical representation. Alternative physical representations of a particular entity component are each derived from the same Base Class generically representing that component. Each set of Derived Classes may include a default characteristics class whose attributes describe characteristics that are universally applicable to entities of that particular physical representation in the absence of overriding settings. Each Base Class may have an association with the default characteristics class. The absence of a Derived Class for a particular component may be understood to indicate that the component is to take on the default characteristics of the relevant wire format.

If the logical meta-model is insufficient to effectively capture desired logical entity meta-data but it is not desired to extend the logical meta-model (e.g. it is an accepted standard, such as the World Wide Web Consortium (W3C) XML schema standard, from which divergence is not desired), the logical meta-model may effectively be extended through extension classes or additional associations residing in the physical meta-model. For example, the correspondence associations between logical entity component classes in the logical meta-model and corresponding Base Classes of the physical meta-model may be implemented as a mapper class residing in the physical meta-model which has a first association with a logical entity component class and a second association with its corresponding Base Class. Also, if it is desired to carry attributes that are missing from the logical meta-model, then these can be carried in the physical meta-model.

The meta-model is associated with a particular application (e.g. messaging). Different applications may have different meta-models. The operative meta-model is instantiated to create a logical model and associated physical model(s) for the relevant application. Advantageously, the use of a defaults characteristics class in the physical meta-model may reduce redundant entity meta-data, resulting in efficient “sparse” models. Conversion between alternative physical representations is facilitated by the correspondence associations between alternative physical representations and their common logical structure. The conversion problem may thus be changed from an N×N problem to an N×1 problem.

In an exemplary meta-model used for messaging, the logical meta-model provides components (e.g. XML element, attribute or type definition classes) which may be instantiated to represent message components (e.g. fields within the message or the data types of the fields) cumulatively describing the structure of a message. Each set of Derived Classes in the physical meta-model represents the message in a particular wire format (e.g. XML or CWF). The default characteristics class for a wire format represents universal message characteristics, e.g. field delimiters or sign conventions, that are universally applicable to all messages of the wire format within a message set unless they are overridden in other Derived Classes. A message set is a set of messages defined for a particular application, e.g., banking, insurance, or travel. Instantiation of the meta-model produces a logical model (e.g. an XML schema defining the logical structure of a message) and a physical model which efficiently defines the message in a number of alternative wire formats. This model, which can be represented in serialized XML Metadata Interchange (XMI) format, may then be traversed to create a compiled form of the model used for conversion.

In accordance with an aspect of the present invention there is provided a meta-model for defining message models comprising: a logical meta-model capable of defining a logical model describing the logical structure of one or more messages in a platform and programming language neutral manner; and a physical meta-model capable of defining a physical model describing at least one physical representation of the one or more messages whose logical structure is described in the logical model.

In accordance with another aspect of the present invention, there is provided a meta-model for defining entity models comprising: a logical meta-model capable of defining a logical model describing the logical structure of an entity in a platform and programming language neutral manner; and a physical meta-model capable of defining a physical model describing at least one physical representation of the entity whose logical structure is described in the logical model.

The figures illustrate UML schemas using the standard nomenclature for UML as set out in, for example, Grady Booch, Ivar Jacobson, James Rumbaugh, “The Unified Modeling Language User Guide”, Addison-Wesley, 1999, the contents of which are hereby incorporated by reference.

DETAILED DESCRIPTION

FIG. 1illustrates a computing system10storing a meta-model100and a model800exemplary of the present invention. The computing system10consists of a computing device20having a processor in communication with memory in which said meta-model100and model800are stored. Computing device20includes a display16and multiple input peripherals, such as a keyboard22and mouse24, and may include hardware to network with other computers (not shown).

In the present case, the meta-model100and model800pertain to messaging. The purpose of meta-model100is to provide classes for generating a logical model of one or more messages in a platform and programming language independent manner and for generating a physical model of alternative wire format representations of those messages. The model800is an instantiation of the meta-model100and includes such a logical model and physical model. The model800is used to support conversion of messages from one wire format to another as will be described. The meta-model100and model800may be loaded into computing system10from a computer program product26having a computer readable medium, which could be an optical or magnetic disk, tape, or chip for example.

FIGS. 2 to 7illustrate, in Unified Modeling Language (UML) notation, the meta-model100ofFIG. 1. The meta-model100is made up of a logical meta-model200(shown inFIG. 2) and a physical meta-model300(shown inFIGS. 3 to 7).

FIG. 2illustrates the logical meta-model component200of the meta-model100. In the present embodiment, the logical meta-model200is an XML schema model. More specifically, the XML schema model shown inFIG. 2is a known XML schema model published by Eclipse, an open source group whose goal is to build an open development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software across their lifecycle (see Eclipse.org). For a description of XML schemas generally, the reader is referred to the text XML Applications by Frank Boumphrey et al., 1998, Wrox Press, which text is hereby incorporated by reference herein.

The logical meta-model200of the present embodiment includes various classes representative of XML schema components. For example, the abstract XSDComponent class202generically represents an XML schema component and serves as a parent class for the other classes ofFIG. 2. The XSDSchema class204serves as a container for all objects defined in a particular XML Schema Definition (XSD) file. The abstract XSDTypeDefinition class206generically represents an XML schema type definition, acting as the parent class for the XSDSimpleTypeDefinition class208and the XSDComplexTypeDefinition class210. The XSDSimpleTypeDefinition class208represents simple or basic types, e.g., string or integer. The XSDComplexTypeDefinition class210represents complex types. Complex types are composed of elements, which themselves can have simple or complex types. Element declarations defined locally within a complex type are referred to as local element declarations. Local element declarations can reference a type defined at the root of an XML Schema or they can have their type defined locally and nested within the complex type. Alternatively, element declarations can be included by reference if such declarations are defined at the root of an XML Schema, i.e., if they are declared as global elements.

The XSDElementDeclaration class212represents the basic unit of information in an XML schema, which has a name, a type and possibly attributes. The XSDModelGroupDefinition class214allows elements to be grouped together so that they can be used to build up the content models of complex type. Elements within the group can be constrained to appear in sequence (same order as they are declared), choice (only one of the elements may appear in an instance), or all (all elements within the group may appear once or not at all and they may appear in any order).

The logical meta-model200includes further classes representative of various other XML schema components. Like the classes already briefly described, these classes will be familiar to those skilled in the art.

FIGS. 3 to 7illustrate the physical meta-model component300of the meta-model100. Physical meta-model classes are identifiable by the “MR” prefix in their class names.

FIG. 3illustrates a portion of the physical meta-model300showing various Base Classes of the physical meta-model300. The term “Base Classes” is used herein to refer to the physical meta-model's generic (i.e. of indeterminate wire format) counterparts to the logical message component classes of the logical meta-model200(FIG. 2). The term “Base Classes” is to be distinguished from the lowercase term “base classes”, which may be used to describe any class from which another class is derived. The latter type of “base classes” are referred to herein as parent classes or superclasses. A class derived from a parent class is referred to herein as a descendent class.

The physical meta-model300includes a MRMsgCollection class302which is representative of a message collection. A message collection is a container for definitions of one or more messages in both logical form and physical form, with the physical form possibly comprising multiple alternative physical representations of the same message(s) in different wire formats. When serialized, an instantiated message collection comprises a .xsd file containing a logical model and a .msd file of the same name containing a corresponding physical model in the present embodiment. The MRMsgCollection class302has a containment relationship with the MRMessage class306which represents a wire format neutral physical message. The MRMessage class306is descendent from the abstract MRBaseElement class310which is itself descendent from the abstract MRBase class308. The MRBase class308is the topmost abstract class and contains attributes which are applicable to all objects in the physical meta-model300. The MRBaseElement class310contains additional attributes which help to identify the message set in which the respective physical meta-model object was created or last modified.

As shown inFIG. 3, the abstract MRBaseElement class310acts as a parent class for many Base Classes of the physical meta-model300, including the MRAttribute class312, the MRLocalElement class314, the MRGlobalElement class316, the MRElementRef class318, the MRSimpleType class320, the MRAttributeGroup class322, the MRGroupRef class324, the MRAttributeGroupRef class326, the MRLocalGroup class328, the MRGlobalGroup class330, and the MRComplexType class332. The correlation of these physical meta-model Base Classes with classes of the logical meta-model200is shown in Table I.

As will become apparent, the correlations shown in Table I are represented in the instantiated model800by way of correspondence associations (defined below) between corresponding physical and logical components.

The content attribute is specific to messaging applications and is not expressly defined in the W3C XML Schema recommendation referenced above. This attribute has three enumerations representing alternative types of constraints of a message's elements that may be applicable to a message received “on the wire.” The added enumerations provide a mechanism for use by a developer of tools which convert messages between alternative wire formats for indicating (to, e.g., a message parser referencing the model800or a compiled version thereof) that it is acceptable if additional elements exist in a message bit stream as long as it has all the elements as defined in the logical model in the appropriate order. That is, the enumerations may be used to indicate that a particular message should match a partial message definition of the logical model when it is received, and in the case where the received message has additional elements, the additional elements may be ignored or processed by applications that are aware of the presence of additional elements.

The three added content type enumerations are:1. Closed—Default enumeration indicating that a message bit stream is to match the definition of the message in the logical model exactly (as implicitly defined in the XML Schema recommendation);2. Open Defined—indicates that a message bit stream can contain any elements which have been defined in the relevant message set (defined below); and3. Open—the message bit stream can contain any elements, even those that have been defined in different message sets.

The composition attribute extends the standard composition type attribute supported by XML schemas with enumerations useful for messaging applications, which enumerations are indicative of possible composition types for physical messages. The composition kind attribute extends the standard composition types of XML schemas (choice, sequence, and all) with the following two added enumerations:1. Unordered Set—similar to “sequence” (which requires all elements of a message to appear in sequence) except that elements within the set may occur in any order.2. Message—a restricted form of “choice” in which a complex type may have element references only to those global elements for which a message has been defined in the relevant message set.

Referring again toFIG. 3, the MRMessage class306has a unidirectional association, having the rolename “messageDefinition”, with the MRGlobalElement class316. This relationship is for tying a defined message to a global element of an XML schema which defines the message's logical structure.

The MRMessageCollection class302has a further containment relationship with a XSDToMRMapper class304. The XSDToMRMapper class304(also referred to simply as the “mapper class”) forms part of the physical meta-model300despite lacking an “MR” prefix in its class name. The XSDToMRMapper class304defines a “correspondence association” between a Base Class and a corresponding logical entity component class (here, a logical message component class). A correspondence association permits mapping of a logical entity component of a logical model instantiated from logical meta-model200to a corresponding physical entity component of a physical model instantiated from physical meta-model300, and vice versa. The correspondence association of the present embodiment is implemented through a first association (with rolename “SchemaObject”) from the mapper class304to the XSDComponent class202and a second association (with rolename “mrObject”) from the mapper class304to the MRBase class308. The motivation for representing the correspondence association in this manner, rather than adopting a more direct approach, e.g., in which the XSDComponent class202and the MRBase class308each directly refer to one another, is that the logical meta-model in the present case is an accepted standard from which divergence is not desired. That is, the “alternative approach” would entail extension of the XML schema model (e.g. the addition of an association from a logical XML schema object to a physical object), which would extend and thereby deviate from an accepted standard; this would compromise coherence with the standard which is preferably maintained. Of course, deviation from accepted standards may be deemed acceptable in alternative embodiments.

FIG. 4illustrates a portion of the physical meta-model300pertaining to message sets. A message set is a set of messages defined for a particular application, e.g., banking, insurance, or travel. A message set acts as a container for all the logical and physical representations of a set of messages and provides a business context for the messages (in that the messages of the set are tailored for a particular business application). A message set may include one or more message collections defining numerous alternative physical representations or wire formats.

The MRMessageSet class340ofFIG. 4is a container class for containing the messages defined in a message set, and may act as an anchor point in an instantiated physical model from which to navigate to various message-related constructs (e.g. message collections or individual messages) defined in the message set. The MRMessageSet class340has an aggregation relationship with the MRMsgCollection class302described above. The MRMessageSetlD class342represents a unique identifier assigned to a message set. Often it is necessary to define a new version of a message set that is based on an existing message set. The set of associations from the MRMessageSet class340to the MRMessageSetlD class342help to identify and manage the version of the message set.

The MRMessageSet class340has a containment relationship with the abstract MRMessageSetRep class346, which in turn acts as a parent class for the MRMessageSetWireFormatRep class348. The latter class348itself acts as a parent class for three distinct wire format specific Derived Classes, namely, the MRXMLMessageSetRep class402, MRCWFMessageSetRep class502and MRTDSMessageSetRep class602. The term “Derived Class” is used herein to refer to a wire format specific class derived from a Base Class. Derived Classes are illustrated with a heavy border. As will be described, each of the MRXMLMessageSetRep class402, MRCWFMessageSetRep class502and MRTDSMessageSetRep class602defines default characteristics for a distinct wire format.

FIG. 5illustrates a further portion of the physical meta-model300showing various context-specific characteristics classes including the MRElementRep class354, MRAttributeRep class356, MRlnclusionRep class358and MRStructureRep class360, as well as their relationships with certain Base Classes of the physical meta-model300. The purpose of context-specific characteristics classes is to describe characteristics of a message component that are particular to a context of the message component with respect to a message. The context-specific characteristics classes may be used to override default message characteristics or define new characteristics for message components, e.g., when the message component is nested within another message component, when the message component is an aggregate of other message components (i.e. is a multi-part message), or when the message component exists at a root or global level of a message for example. These classes are not themselves intended to be instantiated (they are abstract), but rather act as parent classes for concrete, wire format specific Derived Classes in which the default characteristics may be overridden or new ones defined. The context-specific characteristics are thus specific to a message component context and a particular wire format. The types of characteristics which may be overridden may include byte alignment, skip count, repeat count, tag name, component rendering, delimiter, tag length, tag data separator, padding character, sign convention and precision for example, depending upon which characteristics are defined in the meta-model100.

The abstract MRElementRep class354defines the context-specific physical characteristics of an element when it is in standalone mode, i.e. when it is at a global level of a message. The MRGlobalElement class316has a containment relationship with class354.

The MRAttributeRep class356is analogous to the MRElementRep class354, except it pertains to attributes versus elements. The MRAttributeRep class356defines the context-specific physical characteristics of a global attribute. The MRAttribute class312has a containment relationship with class356.

The MRlnclusionRep class358defines the context-specific physical characteristics of a message component when it is contained in another component such as a complex type or global/local group. This may be used, e.g., if it is desired to indicate in an instantiated physical model that an element of type integer within a complex type should be aligned on a full word boundary for a particular wire format. Each of the MRLocalElement class314, MRAttribute class312, MRAttributeGroupRef class326, MRElementRef class318, and MRGroupRef class324has a containment relationship with the MRlnclusionRep class358.

The MRStructureRep class360defines the context-specific physical characteristics associated with a structure defined by way of a model group, complex type or attribute group. Each of the MRLocalGroup class328, the MRGlobalGroup class330, the MRComplexType class332and the MRAttributeGroup class322has a containment relationship with the class360.

The MRBaseRep class350is a common parent class for the four context-specific characteristics classes described above. This class has an important association, identified by the rolename “messageSetDefaults”, with the abstract MRMessageSetRep class346, which allows a wire format specific message component (defined in a Derived Class descendent from class350) to easily access a class capturing the default characteristics for the operative wire format (defined in a Derived Class descendent from class346).

FIG. 6illustrates a set of Derived Classes of the physical meta-model300pertaining to a particular wire format, namely, the XML wire format. The XML wire format allows customization of XML-based messages in accordance with requirements for exchanging messages using XML which may be set between business partners for example. The XML-specific Derived Classes ofFIG. 6are identifiable by the prefix “MRXML” in their class names and by the heavy borders which identify Derived Classes.FIG. 6employs a naming convention whereby XML-specific Derived Classes with a class name of “MRXML<componentidentifier>Rep” are understood to be descendent from a Base Class of the physical meta-model300with the class name of the form “MR<componentidentifier>Rep” (e.g. the MRXMLlnclusionRep class412is descendent from the MRlnclusionRep class258).

The XML-specific Derived Classes include the MRXMLMessageSetRep class402, MRXMLAttributeRep class404, MRXMLStructureRep class406, the MRXMLElementRep class408, MRXMLMessageRep class410and MRXMLlnclusionRep class412. It will be appreciated that each of these XML-specific Derived Classes has an association with the default characteristics class MRXMLMessageSetRep402by way of the “messageSetDefaults” association between the MRMessageSetRep class246and the MRBaseRep class250.

The MRXMLMessageSetRep class402is a default characteristics class which captures, in the form of attributes, all of the default characteristics for messages defined for the XML wire format message set in the meta-model100. The default characteristics for a wire format represent physical message characteristics, e.g. representation of Boolean true/false values, encoding of null, delimiters, sign conventions, or similar parameters, that are universally applicable to messages of the wire format unless they are overridden in other Derived Classes of the set. For example, in the case of the MRXMLMessageSetRep class402, the attributes include booleanTrueValue and booleanFalseValue attributes which define TRUE and FALSE booleans to be strings with the value “true” and “false” respectively. The characteristics defined in the Derived Classes are all wire format specific; indeed, the definition of characteristics that are defined for one wire format in another wire format may not make sense in the context of the latter wire format. For example, the “xmlName” attribute of classes404,408,410and412describe an XML tag name that will be associated with the respective message component on the wire, which does not make sense for tagless wire formats such as CWF. Another example is the “render” attribute of classes410and412which indicates how the containing message component is to be “rendered” (i.e. transmitted) on the wire: as an element or an attribute. The Derived Classes could be expanded to include other characteristics not presently described; in this sense the classes are extensible and modifiable to meet the purposes of the application at hand (here, to describe characteristics associated with XML wire format messages).

The MRXMLAttributeRep class404defines physical representation characteristics of attributes for an XML wire format in the event that its representation differs from that defined in the logical model.

The MRXMLStructureRep class406defines characteristics of XML wire format message structures of containing message component objects which may differ from default characteristics defined for structures of the XML wire format in the meta-model100or which are undefined in the default characteristics class402. Although no overriding or new characteristics are defined here, this class is included for extensibility reasons (i.e. in case overriding or new characteristics are defined later).

Similarly, the MRXMLElementRep class408defines characteristics of XML wire format message elements of a containing global element message component which may differ from default characteristics defined for elements of the XML wire format in the meta-model100or which are undefined in the default characteristics class402.

The MRXMLMessageRep class410defines characteristics of a containing XML wire format message object which may differ from default characteristics defined for messages of the XML wire format in the meta-model100or which are undefined in the default characteristics class402.

Finally, the MRXMLlnclusionRep class412defines characteristics of a containing XML wire format message component object that is included within another XML wire format message component (typically within a complex type) which may differ from default characteristics defined for the XML wire format in the meta-model100for that message component or which are undefined in the default characteristics class402.

FIG. 7illustrates a further set of Derived Classes of the physical meta-model300, in this case pertaining to the CWF wire format. The CWF wire format is a wire format for messages in which data elements are adjacent to one another in the message byte stream, not being separated by delimiters or tags.FIG. 7employs analogous naming conventions to those employed inFIG. 6.

The CWF-specific Derived Classes ofFIG. 7include the MRCWFMessageSetRep class502, MRCWFAttributeRep class504, MRCWFStructureRep class506, the MRCWFElementRep class508, MRCWFMessageRep class510, MRCWFlnclusionRep class512, MRCWFBaseRep class514, MRCWFAggregateRep class516, MRCWFSimpleRep class518, and MRCWFSimpleTD class520. It will be appreciated that each of these CWF-specific Derived Classes has an association with the default characteristics class MRCWFMessageSetRep502by way of the “messageSetDefaults” association between the MRMessageSetRep class246and the MRBaseRep class250.

The MRCWFMessageSetRep class502is a default characteristics class which captures, in the form of attributes, all of the default physical characteristics for messages defined for the CWF wire format message set using the instant meta-model100. The MRCWFMessageSetRep class502is analogous to the MRXMLMessageSetRep class402ofFIG. 6. It will be appreciated that the default characteristics defined for the MRCWFMessageSetRep class502differ from those defined for the MRXMLMessageSetRep class402. This illustrates the fact that each alternative physical representation (here, each different message wire format) of a physical meta-model300may have its own, representation-specific characteristics for which default settings may be defined.

The Custom Wire Format uses the Object Management Group (OMG) type descriptor model, available at http://www.omg.org, in its definition. Only where the OMG type descriptor model is deficient in describing the wire format characteristics for CWF are extensions made through the MRCWFBaseRep class514, MRCWFAggregateRep class516, and MRCWFSimpleRep class518to carry additional attributes. These classes inherit directly from classes defined in the OMG type descriptor model (e.g. the AggregatelnstanceTD class517or SimplelnstanceTD class519) and mix in the MRCWF<component>Represent classes.

The MRCWFSimpleTD class520is the base abstract class for defining wire format characteristics of simple types such as strings, integer, float, decimal, date and time. Each of the concrete classes516,518and520defining the wire format characteristics of simple types inherits directly from the respective type descriptor class and mixes in the MRCWFSimpleTD class520, to ensure that these classes are accessible from the MRCWFSimpleRep class518. This approach represents the best of both worlds—compatibility with the OMG type descriptor model combined with the ability to define additional characteristics for messages which are not supported in the OMG type descriptor model.

FIG. 8is a schematic diagram illustrating the composition of the model800instantiated from the meta-model100(FIG. 1). The model800is made up of a logical model900and physical model1100stored within electronic files in serialized form. The logical model900consists of a file “tadets.xsd” (shown inFIGS. 9A-9C) storing a serialized instance of the logical meta-model200(specifically, an XML schema) describing the logical structure of a message in XML format. The physical model1100consists of a pair of files “messageSet.mset” (the contents of which are shown inFIG. 11) and “tadets.msd” (the contents of which are shown inFIGS. 13A-13E) storing a serialized instance of the physical meta-model300in XML Metadata Interchange (XMI) format. The breakdown of the logical model900and the physical model1100into files is implementation-specific and may differ in other embodiments. The XMI notation used in FIGS.11and13A-13E is consistent with XMI as described in, for example, Timothy J. Grose, Gary C. Doney and Stephen A. Brodsky, “Mastering XMI: Java Programming with XMI, XML, and UML”, John Wiley & Sons, 2002, ISBN 0471384291, the contents of which are hereby incorporated by reference.

FIGS. 9A-9Cillustrate the logical model900(i.e. the serialized XML schema of the file “tadets.xsd” ofFIG. 8) in greater detail. The logical model900defines the logical structure of a single message, which in the present example pertains to an employee record. The model900ofFIGS. 9A-9Cis perhaps best viewed in conjunction withFIG. 10A, which illustrates a COBOL copybook1000analogous to the logical structure of the model900upon which the model900is based.

As may be seen inFIG. 10A, the COBOL copybook1000has a top level field EmployeeInfo (line1) which has four sub-fields, namely, an EmployeeType (line2) sub-field representing an employee type, a Name sub-field (lines3-6) representing an employee name, an Address sub-field (lines7-9) representing an employee address, and a salary sub-field (line10) representing an employee salary. The Name sub-field has three sub-fields FirstName, MiddleName, and LastName, each of type string, having lengths of 10, 1 and 20 respectively. The Address field has two sub-fields, namely, a sub-field StreetNo of type integer and a sub-field City of type string of length20.

FIG. 10Billustrates a corresponding C language structure1050analogous to copybook1000ofFIG. 10Awhich may assist comprehension for those unfamiliar with COBOL.

The logical structure of the data structures ofFIGS. 10A and 10Bis reflected in the logical model900ofFIGS. 9A-9Cin a platform and programming language independent manner. The schema is defined to have a complex type “Employeelnfo” (lines5to48ofFIG. 9A) having four fields represented by the elements “employeetype” (lines8-20), “name” (lines22-28), “address” (lines30-36) and “salary” (lines38-45). The “name” element references the global group “employeeinfo_name” which is defined at lines50ofFIGS. 9A to 93ofFIG. 9B. The group is defined as a sequence of local elements “firstname”, “middlename” and “lastname” comprising strings commensurate in length to those defined in the C structure1000ofFIG. 10. The “address” element references the global group “employeeinfo_address” which is defined at lines95ofFIGS. 9B to 121ofFIG. 9C. This group is defined as a sequence of two local elements comprising a “streetNo” short integer element and a “city” string element of length20. A global element “emplnfo” of complex type “Employeelnfo” is declared at line123ofFIG. 9C.

FIG. 11illustrates the contents of the file “messageSet.mset” (FIG. 8) comprising the physical model1100. The “messageSet.mset” file is a serialized representation of a message set instantiated from the physical meta-model300. It contains default characteristics of each of the wire formats in which the message set is represented. The defaults for a particular wire format are applicable to all messages within the message set of that wire format.FIG. 11may best be viewed in conjunction withFIG. 12, which illustrates the “messageSet.mset” file ofFIG. 11in the form of an object tree or instance tree.

At the top level of the physical model1100, a message set object is declared (lines3-5ofFIG. 11, object1202ofFIG. 12). This object is an instantiation of the MRMessageSet class340(FIG. 4) and declares a message set with the name “SampleMessageSet” and an XMI-provided ID “MRMessageSet_1”. Contained within the message set “SampleMessageSet” are two objects representative of the default characteristics of two distinct wire formats.

The first default characteristics object (lines7-10ofFIG. 11, object1204ofFIG. 12) having the name “Default_XML” is an instance of the MRXMLMessageSetRep class402(FIG. 6) and represents the default physical characteristics for messages of the XML wire format in this message set. The heavy border on object1204ofFIG. 12reflects the fact that this object is an instance of a Derived Class. The object “Default_XML” overrides two attributes, namely, “doctypeSystemlD” and “doctypePublicID”, from their default values set within the MRXMLMessageSetRep class402(FIG. 6), e.g. to assign a system ID and public ID for identifying documents to be exchanged in a particular wire format. It will be appreciated that the other attributes of the default characteristics MRXMLMessageSetRep class402whose values are not overridden in this fashion retain their default values.

The second default characteristics object (lines12-14ofFIG. 11, object1206ofFIG. 12) having the name “Default_CWF” is an instance of the MRCWFMessageSetRep class502(FIG. 7) and represents the default physical characteristics for messages of the CWF wire format. This object is analogous to the “Default_XML” object described above and also overrides a number of default characteristics values.

Also contained in the message set object “SampleMessageSet” is a message set ID object (lines16-17ofFIG. 11, object1208ofFIG. 12) representative of a unique message set ID generated for the “SampleMessageSet” message set.

FIGS. 13A-13Eillustrate the contents of the file “tadets.msd” (FIG. 8) comprising a further portion of the physical model1100. The “tadets.msd” file contains a serialized representation of a single message collection instantiated from the physical meta-model300, which message collection is contained by the message set object “SampleMessageSet” (FIGS. 11 and 12). It will be appreciated that the containment relationship between the message set object “SampleMessageSet” and the message collection ofFIGS. 13A-13Eis not serialized in the messageSet.mset file (FIG. 11) because the relationship is derived as shown inFIG. 4. The present implementation of this derived relationship is based on a directory/folder structure of the file system of computing device20(FIG. 1). A message set is represented as a directory/folder containing all message collections (i.e. pairs of .xsd and .msd files). To obtain a list of all message collections, a list of the .msd files of the current directory/folder is obtained using the file system Application Programming Interface (API), and then the .msd files are read to retrieve MRMsgCollection objects.FIGS. 13A-13Emay best be viewed in conjunction withFIGS. 14A-14B, which illustrate portions of the physical model1100ofFIGS. 13A-13Ein the form of an object tree.

Logically contained within the message set object “SampleMessageSet” of physical model1100is a message collection object (lines3-267ofFIGS. 13A-13E; object1402ofFIG. 14A). This object is an instantiation of the MRMsgCollection class302(FIG. 3). The value of the name attribute “tadets.msd” (line5ofFIG. 13A) of this object indicates the filename of the file containing the serialized representation of this message collection.

The message collection object1402contains thirteen mapper objects having XMI-provided id's of “XSDToMRMapper_1” to “XSDToMRMapper_13” inFIGS. 13A to 13E. These mapper objects comprise correspondence associations between various logical message components of the logical model900and their physical message components of the physical model1100. Four exemplary mapper objects are illustrated inFIGS. 14A to 14B.

The first exemplary mapper object1404(FIG. 14A) (lines7-17ofFIG. 13A) provides a correspondence association between the “Employeelnfo” complex type of the logical model900(lines5-48ofFIG. 9A) and the corresponding physical representations of that complex type in the physical model1100. This is done by way of a first association “schemaObject” to an instance1406of the XSDComplexTypeDefinition class210(FIG. 2) which has an “href” attribute referencing the “Employeelnfo” complex type (FIG. 9A, reference A) and a second association “mrObject” to an instance1408of the MRComplexType Base Class332(FIG. 3). Again, the “href” reference is defined to be from the physical model1100to the logical model900, not the other way around, because the logical model is not capable of being “aware” of the physical model, as it is a standard XML schema. An instance1410(FIG. 14A) of the MRCWFStructureRep Derived Class506(FIG. 7) inherits this association. The MRCWFStructureRep object1410also has an association “messageSetDefaultRep” with the MRCWFMessageSetRep object1206(FIG. 12, reference D) indicating that the default characteristics defined therein for CWF wire format messages are applicable to this complex type. Moreover, because the MRCWFStructureRep object1410lacks of any overriding settings, all of the default characteristics are understood to apply.

The second exemplary mapper object1412ofFIG. 14A(lines19-46ofFIG. 13A) provides a correspondence association between the “employeetype” local element of the logical model900(lines8-20ofFIG. 9A) and the physical representations of that element in the physical model1100, in both the CWF wire format and the XML wire format. This is again achieved by way of a first association “schemaObject”, which in this case refers to an instance1414of the XSDElementDeclaration class212(FIG. 2) having an “href” attribute referencing the “employeetype” element (FIG. 9A, reference C), and a second association “mrObject” referring to an instance1416of the MRLocalElement Base Class314(FIG. 3). The latter instance1416has two set of objects descendent therefrom: objects1418,1420, and1422; and object1424.

Objects1418,1420, and1422all pertain to the CWF wire format. Object1418is an instance of the MRCWFlnclusionRep Derived Class512(FIG. 7) which defines characteristics for the “employeetype” element when it constitutes a local element (i.e. it is nested within a complex type) of a CWF message. The association “messageSetDefaultRep” with the MRCWFMessageSetRep object1206(FIG. 12, reference D) indicates that the default CWF message set characteristics defined therein are applicable to this local element in the case where a CWF wire format message is rendered. The contained objects1420and1422(also being instances of Derived Classes pertaining to the CWF wire format) override some of the default settings for a simple type comprising an external decimal representation.

Object1424is an instance of the MRXMLlnclusionRep Derived Class412(FIG. 6) which defines characteristics for the “employeetype” element when it constitutes a local element of an XML wire format message. The association “messageSetDefaultRep” with the MRXMLMessageSetRep object1204(FIG. 12, reference B) indicates that the default XML message set characteristics defined therein are applicable to this local element in the case where an XML wire format message is rendered. Two characteristics are defined in the object1424which are undefined within the default message set characteristics. The first is the “xmlName” attribute, which is set to “EmployeeType”. The second is the “render” attribute, which is set to “XMLAttribute”. In combination, these attributes indicate that when the instant local “employeetype” element is rendered on the wire within a complex type of an XML wire format message, it should be rendered as an attribute (as opposed an element) having an attribute name of “EmployeeType” instead of as an employeetype element as defined in logical model900(at line8ofFIG. 9A).

It will be appreciated that the attributes of the MRXMLlnclusionRep object1424that are not overridden are understood to retain their default settings as indicated in the MRXMLlnclusionRep class412(FIG. 6), as with all of the classes of the physical model1100. In conjunction with the use of the “messageSetDefualtRep” references to default characteristics, this reduces the physical model1100to a “sparse tree” in which redundant message characteristics information is significantly reduced or eliminated.

The third exemplary mapper object1430(FIG. 14B) (line103ofFIG. 13Bto line129ofFIG. 13C) provides a correspondence association between the “firstname” local element of the logical model900(starting at line53ofFIG. 9A) and the corresponding physical representations of that element in the physical model1100, in both the CWF wire format and the XML wire format. This is achieved in an analogous fashion to the second mapper object1412, with a pair of associations to an instance1432of the XSDElementDeclaration class212(FIG. 2) (having an “href” attribute referencing the “firstname” element atFIG. 9A, reference F) and an instance1434of the MRLocalElement Base Class314(FIG. 3). Objects1436,1438and1440pertain to the CWF wire format and object1442pertains to the XML wire format. Of interest is the fact that this particular local element is set to be rendered differently on the wire from the “employeetype” local element. In particular, it is set to be rendered as a “val” attribute of an XML element by way of the “XMLElementAttrVal” enumeration.

The fourth exemplary mapper object1444(lines251-257ofFIG. 13E) provides a correspondence association between the “empinfo” global element of the logical model900(line123ofFIG. 9C) and a corresponding physical representation of that element in the physical model1100in an indeterminate wire format. This is similarly achieved with a pair of associations to an instance1446of the XSDElementDeclaration class212(having an “href” attribute referencing the “emplnfo” element atFIG. 9C, reference G) and an instance1448of the MRGlobalElement Base Class316(FIG. 3).

In addition to the thirteen mapper objects, the message collection object “tadets.msd” (1402ofFIG. 14A) further contains an instance1450(lines259-264ofFIG. 13E) of the MRMessage Base Class306(FIG. 3) representative of a message contained in the instant message collection (which, in the present example, is the only message contained in the message collection). The value “MRGlobalElement_1” of “messageDefinition” association of this instance1450identifies the MRGlobalElement object1448as the Base Class defining the structure of the message (this association being represented inFIG. 14Bas a dotted arrow1451). A single instance1452of the MRXMLMessageRep Derived Class410(FIG. 6) defines characteristics of the message when rendered as an XML message which are undefined within the relevant default characteristics object1206(FIG. 12). The “xmlName” attribute defines the name of the message object to be “EmployeelnfoMsg”.

The message collection object1402also contains a reference1454(FIG. 14B) to the XSDSchema class204(FIG. 2). The purpose of this object is to cross reference the logical model900from the physical model1100.

As can be seen inFIGS. 13A-13EandFIGS. 14A-14B, the “sparse tree” representation of messages and message components significantly reduces or eliminates redundant information in the physical model1100. This provides efficiency of storage and representation of even large message sets. Supporting this “sparseness” is the fact that the default message set characteristics for a wire format are understood to apply in the absence of a Derived Class instance for any message component in the set. Moreover, any changes made at the message set level advantageously become applicable to all messages unless specifically overridden. This facilitates quick global updates to a model in cases where one or more universally applicable characteristics are changed.

The model800is typically traversed at tooling time in order to generate a compiled representation of the model that is designed for efficiency of run-time use. The compiled version of the model typically “flattens” the model800, i.e. more deeply nested components or attributes are promoted to a higher level, for speed of access. Unlike the model800, which strives to limit or eliminate redundant information, the compiled version may intentionally contain redundant information, again for speed of access at run time. For example, information appearing in only one place within the “sparse tree” model800may be duplicated to appear within a number of different types of objects in the compiled model, so that different types of traversals of the compiled model which visit these distinct object types may still have access to commonly needed information. Although it is possible, the model800is not typically used at run time for message conversion due to the above noted efficiency benefits of using a compiled version of the model. It is important to note that the compiled version is a read only version, thus any redundancy that is introduced to support gains in processing efficiency during reading of the model at run time does not detrimentally result in performance inefficiencies during model updating or maintenance, since no such updating or maintenance is performed on this version of the model.

To generate a compiled version of the model800, the model800is typically traversed starting from a message set object. Initially, a list of .xsd files comprising the logical model is obtained (e.g. via a file system API). The traversal then “walks” down the logical model (i.e. examines the logical model .xsd file by .xsd file). For each logical construct in the current .xsd file, the corresponding physical object is retrieved from the associated .msd file through a search of the XSDToMRMapper objects list. For example, in the case of the exemplary physical model1100, the traversal walks down the logical model of the sole .xsd file “tadets.xsd”. For each construct identified therein, the list containing the thirteen mapper objects XSDToMRMapper_1to XSDToMRMapper_13(shown in serialized form inFIGS. 13A-13E) is traversed to identify the corresponding physical object. If a Base Class object is found to exist, any wire format specific descendent classes are examined for any new or overriding physical characteristics which, if found, are deemed to take precedence over the default settings for the relevant wire format. Otherwise, the default message set characteristics (as may be identified by the “messageSetDefaultRep” association) are understood to apply.

FIG. 15illustrates an XML message instance1500which conforms to the XML wire format settings of physical model1100ofFIGS. 13A-13E. The effect of various context-specific characteristics settings within the physical model1100(i.e. the overriding of default settings of the XML wire format or definition of new characteristics) are apparent in the instance1500, as perhaps best seen when the message1500ofFIG. 15is contrasted againstFIG. 16, which illustrates an instance1600of the same message, but in the absence of any overriding of the XML wire format default characteristics.

As can be seen inFIG. 16(at lines2and18), the default value of the message tag name is “emplnfo” as defined in the logical model900(at line123ofFIG. 9C). This tag name is changed to “EmployeelnfoMsg” in the message1500(lines2,16ofFIG. 15), by way of the instance1452(FIG. 14B) of the MRXMLMessageRep class410(FIG. 6). Another distinction is that the “employee type” element appears as an attribute of the EmployeelnfoMsg object (line2,FIG. 15) as opposed to its default representation as an element (line7ofFIG. 16), this being achieved by way of the MRXMLlnclusionRep object1424ofFIG. 14A(lines40-44ofFIG. 13A). Finally, the firstname, middlename, and lastname local elements (defined in the logical model900at F ofFIGS. 9Aand H, ofFIG. 9Brespectively) are rendered as empty elements with a “val” attribute (lines7-9ofFIG. 15) as opposed to their default representation as standard elements (lines9-11ofFIG. 16). For the firstname local element, this is achieved by way of the MRXMLlnclusionRep object1442ofFIG. 14B(line127ofFIG. 13C); the remaining two local element characteristics are analogously overridden (lines156,157ofFIG. 13C and 185,186ofFIG. 13D).

It will be appreciated that conformity of messages such as 1500 or 1600 to the applicable physical model (e.g. physical model1100) is typically achieved by a message parser applying the message structure rules defined in (a compiled version of) the model to messages being received or sent on the wire.

If the message structures ofFIGS. 15 and 16were to represent structures used by two enterprises seeking to intercommunicate, the default characteristics exemplified inFIG. 16could be defined in one XML wire format for a message set in the physical meta-model300and the changed characteristics exemplified inFIG. 15could be defined in another XML wire format for the message set. Conversion between them would then be facilitated through their associations with the common logical model900.

The compiled form of the message set (also referred to as a run time dictionary) parses the message received on the wire and converts it from a physical model representation to a corresponding logical model representation. Then, when the message is to be output, the target wire format characteristics are applied to create a physical model representation of the message from the logical model representation which is rendered on the wire.

As will be appreciated by those skilled in the art, modifications to the above-described embodiment can be made without departing from the essence of the invention. For example, alternative embodiments may employ other types of logical meta-models, which may or may not be XML schema-based.

As well, though the meta-model100and model800of the present embodiment pertain to messages, the meta-models and models of alternative embodiments may pertain to other entities and may be used in conjunction with applications that are unrelated to messaging.

Other modifications will be apparent to those skilled in the art and, therefore, the invention is defined in the claims.