CA2244918C - A management interworking unit and a method for producing such a unit - Google Patents
A management interworking unit and a method for producing such a unit Download PDFInfo
- Publication number
- CA2244918C CA2244918C CA002244918A CA2244918A CA2244918C CA 2244918 C CA2244918 C CA 2244918C CA 002244918 A CA002244918 A CA 002244918A CA 2244918 A CA2244918 A CA 2244918A CA 2244918 C CA2244918 C CA 2244918C
- Authority
- CA
- Canada
- Prior art keywords
- mappings
- context
- management
- objects
- models
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0233—Object-oriented techniques, for representation of network management data, e.g. common object request broker architecture [CORBA]
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99954—Version management
Abstract
In a process (1) an MIU (10) is produced by creating models (4, 5) of the management interfaces to be interworked. Each model has objects representing managed resources. Domain knowledged (7), an interface (8) and a processor (6) create mappings between equivalent parts of the models. The models and mappings form an ICF (11), which communicates using an internal protocol (i1, i2) with a pair of MCFs (12). The MCFs (12) perform format conversion and communicate with the interworked interfaces.
Description
WO 97/3D535 PCTl~97/DDOIO
"A Management Interworking Unit and a Method for Producing such a Unit"
' The invention relates to a management interworking unit (MIU) and to a method for producing such a unit. The invention relates particularly, but not exclusively, to interworking of telecommunication systems.
There are numerous situations where a management interworking unit is required to allow management systems to interoperate. In one typical example, one management system is a PABX supporting a proprietary management interface and the other is a remote manager which supports a standardised interface. The MIU will provide conversion of protocol and information allowing the remote manager to control the PABX.
MIUs typically have a conversion function often referred to as an information conversion function (ICF), and interfaces often referred to as message communication functions (MCFs). An example of an MIU is that described in PCT patent specification No. W095/23469 (British Telecommunications PLC). The ICF includes a mapper 44 and the MCFs includes stacks 40 and 52. While such MIUs are generally quite effective, they are often difficult to produce because there is a large degree of manual input, and they are difficult to modify or expand.
The invention is directed towards providing an improved management interworking unit which has a simpler construction.
Another object is to provide a method for producing a management interworking unit which is more efficient than has heretofore been the case.
According to the invention, there is provided a process for producing a management interworking unit for a pair of maxxagement interfaces comprising the steps of:-producing an information conversion function (ICF) by:-storing a modes associate with each interface, each model comprising objects representing managed resources. and creating mappings including run time conversion functions between equivalent parts of the models; and producing a message communication function (MCF) Z5 associated with each management interface, each MCF
comprising means for performir~.g format conversion between the external protocol of the associated-interfaces and an internal protocol for the ICF;
20 each model comprises objects in a containment hierarchy providing a containment context for each object; and w each object has a class defined by characteristics 25 independently of the contexts and the mappings are between individual objects and between groups of objects having the same class and context, namely context classes.
By creating models and subsequently creating mappings between equivalent parts of the models the production of the iCF may he automated to a large extent. This considerably reduces the lead tixae in producing an MIU. Further, by separating out format conversion as an operation which is performed exclu lively by the MCF, the task of producing the MIU is broken down in a simple manner. All internal communication uses the internal protocol and the MCFs solely carry out the format, conversion which is required for communication with the interworked management interfaces.
Because each model Comprises objects in a containment S hierarchy providing a containment context for each object, the managed resources are represented iri a simple manner which reflects their structure.
As noted, each object has a class defined by characteristics 1o independently of the context. It has been found that by linking the class and the context, a very effective way has been found for automatically identifying equivalent parts of the~two models. This allows a large degree of automation_ 15 Preferably, the models axe created at least partially automatically by loader modules. The processing operations of loader modules may be carried out very efficiently.
In one embodiment, the models are created for management 2o interface specifications, and specification free text is manually converted to the model language. This helps to ensure that any ambiguities which may exist in the specifications are not transferred to the models.
25 Since the mappings are between individual objects and between groups of objects having the same class and context, namely context classes, comprehensive set of mappings is provided.
Preferably, the mappings define context class cardinality. Tn 30 one embodiment, the mappings are created be1_ween context classes, and preferably also between objects, and preferably also between object characteristics.
In one embodiment, the characteristics include object 35 functions (or actions?r relationships, attributes, notificatxon~. and behaviour. It has been found that this set of characteristics comprehensively characterise each object.
"A Management Interworking Unit and a Method for Producing such a Unit"
' The invention relates to a management interworking unit (MIU) and to a method for producing such a unit. The invention relates particularly, but not exclusively, to interworking of telecommunication systems.
There are numerous situations where a management interworking unit is required to allow management systems to interoperate. In one typical example, one management system is a PABX supporting a proprietary management interface and the other is a remote manager which supports a standardised interface. The MIU will provide conversion of protocol and information allowing the remote manager to control the PABX.
MIUs typically have a conversion function often referred to as an information conversion function (ICF), and interfaces often referred to as message communication functions (MCFs). An example of an MIU is that described in PCT patent specification No. W095/23469 (British Telecommunications PLC). The ICF includes a mapper 44 and the MCFs includes stacks 40 and 52. While such MIUs are generally quite effective, they are often difficult to produce because there is a large degree of manual input, and they are difficult to modify or expand.
The invention is directed towards providing an improved management interworking unit which has a simpler construction.
Another object is to provide a method for producing a management interworking unit which is more efficient than has heretofore been the case.
According to the invention, there is provided a process for producing a management interworking unit for a pair of maxxagement interfaces comprising the steps of:-producing an information conversion function (ICF) by:-storing a modes associate with each interface, each model comprising objects representing managed resources. and creating mappings including run time conversion functions between equivalent parts of the models; and producing a message communication function (MCF) Z5 associated with each management interface, each MCF
comprising means for performir~.g format conversion between the external protocol of the associated-interfaces and an internal protocol for the ICF;
20 each model comprises objects in a containment hierarchy providing a containment context for each object; and w each object has a class defined by characteristics 25 independently of the contexts and the mappings are between individual objects and between groups of objects having the same class and context, namely context classes.
By creating models and subsequently creating mappings between equivalent parts of the models the production of the iCF may he automated to a large extent. This considerably reduces the lead tixae in producing an MIU. Further, by separating out format conversion as an operation which is performed exclu lively by the MCF, the task of producing the MIU is broken down in a simple manner. All internal communication uses the internal protocol and the MCFs solely carry out the format, conversion which is required for communication with the interworked management interfaces.
Because each model Comprises objects in a containment S hierarchy providing a containment context for each object, the managed resources are represented iri a simple manner which reflects their structure.
As noted, each object has a class defined by characteristics 1o independently of the context. It has been found that by linking the class and the context, a very effective way has been found for automatically identifying equivalent parts of the~two models. This allows a large degree of automation_ 15 Preferably, the models axe created at least partially automatically by loader modules. The processing operations of loader modules may be carried out very efficiently.
In one embodiment, the models are created for management 2o interface specifications, and specification free text is manually converted to the model language. This helps to ensure that any ambiguities which may exist in the specifications are not transferred to the models.
25 Since the mappings are between individual objects and between groups of objects having the same class and context, namely context classes, comprehensive set of mappings is provided.
Preferably, the mappings define context class cardinality. Tn 30 one embodiment, the mappings are created be1_ween context classes, and preferably also between objects, and preferably also between object characteristics.
In one embodiment, the characteristics include object 35 functions (or actions?r relationships, attributes, notificatxon~. and behaviour. It has been found that this set of characteristics comprehensively characterise each object.
Preferably, the mappings are created interactively using a graphical interface representing the models and the mappings.
This-is a very simple and fast way of creating the mappings.
Ideally, the mappings are predicated by run time rules selected for the mappings.
In one ezubodiment, the process has the further step of pre coxnpiling the models and the mappings to a template to to produce source code.
Ideally, the template is manually modified after pre-compiling and flags are inserted in the template to differentiate automatically generated code from manually generated code.
In one euibodiment, searches are carried out to determine a proposed mapping has previo~u.sly been made for similar characteristics and such mappings may be re-used_ According to another aspect, the invention provides a management interworking unit (MxU) for at Least two management interfaces comprising:- _ an information conversion function (ICF) comprising:-a model associated with each interface, each model comprising objects representing managed 3o resources, and run time conversion mappings between equivalent parts of the models: and a message communication function (MCF~ associated with each management interface, each MCF comprising means for performing format conversion between the external protocol of the associated interface and an internal protocol of the ICF; and each model comprises objects in a containment hierarchy providing a containment context for each object arid each object has a class defined by characteristics independently of the context; and the magpings axe between individual objects and between groups of objects having the same class and context, name3.y context classes.
This structure of MIU stimulates the re--use of individual MCFlICF components.
In one embodiment, the mappings define context class cardinality.
Ideally, mappings link context classes, and pxe~erabl,y also link objects, and preferably also Link object characteristics.
In one embodiment, the object Characteristics include object functions or actions, relationships, attributes, notifications, and behaviour.
In some cases, mappings are predicated by run time rules selected for the mappings.
In one embodiment the internal protocol includes primitives controlling start, end, and rollback of atomic transcations in the ICF.
WO 97!30535 PCT//IP97/000I0 The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which:- ' Fig. 1 is flow chart illustrating a process of the invention for producing a management interworking unit (MIU);
Fig. 2 is a schematic representation of relationships between entities of interworked interfaces;
Fig. 3 is a schematic representation of a manner in which entities are mapped;
Fig. 4 is a sample display screen showing the manner in which the MIU is created; and Figs. 5 and 6 are is a schematic representations of the structure of an MIU.
Referring to Fig. 1, a process 1 is illustrated for the production of a management interworking unit (MIU) 10.
Very briefly, the process 1 involves taking source interface specifications A and B of the management system interfaces to be interworked. In this embodiment, the specification A is of a GDMO (General Description of Managed Objects) interface, whereas the specification B is of a proprietary interface. The specification A is converted to an information model 4 in a Map language representation by loader modules 2. The specification B
is converted to an information model 5 defined in the Map .
langauge by loader modules 3 which parse the specification and convert it to the semantically equivalent Map language representation.
VVO 97/30535 PCTl1E97/00010 Instead of creating the models, they may be previously created as part of the specification or otherwise, and thus simply stored.
Once the models 4 and S in the Map language have been created, a processor 6 operates to generate the MIU 10.
The processor 6 uses stored sets of domain knowledge 7 and inputs from a user interface 8 which are used to create mappings 9 during the process.
The MIU 10 comprises an information conversion function (ICF) 11 and a pair of message communication functions (MCFs) 12. The ICF 1I maps the information contained in one of the models 4 and 5 to that contained in the other to perform run time conversion. There is at least one ICF
11 for each pair of interworked models. The MCFs 12 handle all communication with the external entities. The external communication is according to the relevant protocol, such as CMIS (Common Management Information Services) or MML (Man Machine Language) primitives. There is a defined interface between each MCF 12 and the ICF 11, across which signals are transmitted according to an internal protocol. The internal protocol includes only-ten basic primitives.
Within the architecture of the MIU i0, there is separation of core and optional functionality, functional distribution of the physical architecture, administration, and initialisation operations.
Returning to the process 1, in one example specification A is of a Q3 interface based upon an ETSI (European Telecommunications Standards Institute) standard management model for ATM cross-connects. Specification B
is of a proprietary interface. Specification A is W O 97J30535 CA 02244918 2004-09-23 P CT/IE97J000i0 _ g _ described in GDMO and accessed via the CMIP (Common Management Information Protocol) protocol through which the operations can be performed upon the managed objects.
Specification B is based on a proprietary object oriented information model and communicates using UNIX' message queue.
There is a common internal representation for objects of the information models 4 and 5. The information in each interface is represented as a set of objects in a containment hierarchy. These objects are defined in a language developed for the purpose and called Map which describes not only the information models 4 and 5, but also the mappings 9 defining the relationships which exist between them. The loader modules 2 and 3 operate on the specifications A and B, which are typically stored as ASCII text to convert them into the Map description models 4 and 5. The descriptions which are generated may be annotated interactively using the interface 8 to generate additional Map statements. Alternatively, the user can directly generate the entire models 4 and 5 manually using Map. Parts of the specification written in free text may not be converted automatically by the loader module and so the user must annotate the model. This ensures that any ambiguities arising from free text are not passed into the model. An example is free text representation of managed object behaviours in GDMO specifications.
The manner in which the processor 6 creates the mappings 9 is now described. These mappings include creation relationships which twin entities in the two models. Such mappings between the two models link:
- (a) context classes, and within these:
- (b) objects; and within these:
This-is a very simple and fast way of creating the mappings.
Ideally, the mappings are predicated by run time rules selected for the mappings.
In one ezubodiment, the process has the further step of pre coxnpiling the models and the mappings to a template to to produce source code.
Ideally, the template is manually modified after pre-compiling and flags are inserted in the template to differentiate automatically generated code from manually generated code.
In one euibodiment, searches are carried out to determine a proposed mapping has previo~u.sly been made for similar characteristics and such mappings may be re-used_ According to another aspect, the invention provides a management interworking unit (MxU) for at Least two management interfaces comprising:- _ an information conversion function (ICF) comprising:-a model associated with each interface, each model comprising objects representing managed 3o resources, and run time conversion mappings between equivalent parts of the models: and a message communication function (MCF~ associated with each management interface, each MCF comprising means for performing format conversion between the external protocol of the associated interface and an internal protocol of the ICF; and each model comprises objects in a containment hierarchy providing a containment context for each object arid each object has a class defined by characteristics independently of the context; and the magpings axe between individual objects and between groups of objects having the same class and context, name3.y context classes.
This structure of MIU stimulates the re--use of individual MCFlICF components.
In one embodiment, the mappings define context class cardinality.
Ideally, mappings link context classes, and pxe~erabl,y also link objects, and preferably also Link object characteristics.
In one embodiment, the object Characteristics include object functions or actions, relationships, attributes, notifications, and behaviour.
In some cases, mappings are predicated by run time rules selected for the mappings.
In one embodiment the internal protocol includes primitives controlling start, end, and rollback of atomic transcations in the ICF.
WO 97!30535 PCT//IP97/000I0 The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which:- ' Fig. 1 is flow chart illustrating a process of the invention for producing a management interworking unit (MIU);
Fig. 2 is a schematic representation of relationships between entities of interworked interfaces;
Fig. 3 is a schematic representation of a manner in which entities are mapped;
Fig. 4 is a sample display screen showing the manner in which the MIU is created; and Figs. 5 and 6 are is a schematic representations of the structure of an MIU.
Referring to Fig. 1, a process 1 is illustrated for the production of a management interworking unit (MIU) 10.
Very briefly, the process 1 involves taking source interface specifications A and B of the management system interfaces to be interworked. In this embodiment, the specification A is of a GDMO (General Description of Managed Objects) interface, whereas the specification B is of a proprietary interface. The specification A is converted to an information model 4 in a Map language representation by loader modules 2. The specification B
is converted to an information model 5 defined in the Map .
langauge by loader modules 3 which parse the specification and convert it to the semantically equivalent Map language representation.
VVO 97/30535 PCTl1E97/00010 Instead of creating the models, they may be previously created as part of the specification or otherwise, and thus simply stored.
Once the models 4 and S in the Map language have been created, a processor 6 operates to generate the MIU 10.
The processor 6 uses stored sets of domain knowledge 7 and inputs from a user interface 8 which are used to create mappings 9 during the process.
The MIU 10 comprises an information conversion function (ICF) 11 and a pair of message communication functions (MCFs) 12. The ICF 1I maps the information contained in one of the models 4 and 5 to that contained in the other to perform run time conversion. There is at least one ICF
11 for each pair of interworked models. The MCFs 12 handle all communication with the external entities. The external communication is according to the relevant protocol, such as CMIS (Common Management Information Services) or MML (Man Machine Language) primitives. There is a defined interface between each MCF 12 and the ICF 11, across which signals are transmitted according to an internal protocol. The internal protocol includes only-ten basic primitives.
Within the architecture of the MIU i0, there is separation of core and optional functionality, functional distribution of the physical architecture, administration, and initialisation operations.
Returning to the process 1, in one example specification A is of a Q3 interface based upon an ETSI (European Telecommunications Standards Institute) standard management model for ATM cross-connects. Specification B
is of a proprietary interface. Specification A is W O 97J30535 CA 02244918 2004-09-23 P CT/IE97J000i0 _ g _ described in GDMO and accessed via the CMIP (Common Management Information Protocol) protocol through which the operations can be performed upon the managed objects.
Specification B is based on a proprietary object oriented information model and communicates using UNIX' message queue.
There is a common internal representation for objects of the information models 4 and 5. The information in each interface is represented as a set of objects in a containment hierarchy. These objects are defined in a language developed for the purpose and called Map which describes not only the information models 4 and 5, but also the mappings 9 defining the relationships which exist between them. The loader modules 2 and 3 operate on the specifications A and B, which are typically stored as ASCII text to convert them into the Map description models 4 and 5. The descriptions which are generated may be annotated interactively using the interface 8 to generate additional Map statements. Alternatively, the user can directly generate the entire models 4 and 5 manually using Map. Parts of the specification written in free text may not be converted automatically by the loader module and so the user must annotate the model. This ensures that any ambiguities arising from free text are not passed into the model. An example is free text representation of managed object behaviours in GDMO specifications.
The manner in which the processor 6 creates the mappings 9 is now described. These mappings include creation relationships which twin entities in the two models. Such mappings between the two models link:
- (a) context classes, and within these:
- (b) objects; and within these:
5 PCT/~97/00010 _ g _ - (c) object internal characteristics.
Regarding (a) above, each class is defined by a set of characteristics including:-- function (action), - relationships, - attributes {data members), - notifications, and - behaviour.
A context class is a particular class in a particular context or position in the containment hierarchy.
Regarding {b) above, each object represents a resource managed by the associated management system interface.
They can be at widely different levels of the abstraction, depending on the nature of the management required. One level of abstraction is cross-connect equipment, and a lower-level example is a switching fabric contained within the cross-connect equipment.
Regarding (c) above each object is an instance of a class, i.e. it will have particular characteristic values.
The Map language can describe relationships which specify that when an instance of one context class is created in one model, then an equivalent instance of another context class should be created in the other model. These two instances are said to be twinned and the relationships are . 25 referred to as creation relationships. The processor 6 creates code to support run time mappings between the instances stored in the MIU and instances stored in one of the systems being interworked.
WO 97/30535 PCT/I1;97/OOOIO
Referring to Fig. 2, examples of the creation relationships are illustrated. One such relationship is referred to as a total relationship 20 between a context class 21 and a context class 22, each having objects 23.
Such a relationship is one-to-one. Another type of ' creation relationship is a sub-set relationship 25 in which every instance created in A will lead to a twin creation in B, but not necessarily the reverse. Thus, the mappings include assertions defining cardinality.
Regarding the mapping of context classes, the Map langauge supports a simple set of assertions which are used to relate context classes in two models. These are described as follows:-1. Simple total relationship. Given a context class A in one model and context class B in another, they can be related using the expression (is-total A B). This means that whenever an instance of A is created, an instance of B must be created and vice versa. These instances are said to be twinned. This means that whenever an operation like get, set or action is performed on one, its equivalent must be performed on the other.
2. Subset and predicated relationships. The expression is-subset A B means that if an instance of A is created then an instance of B must also be created but the reverse is not necessarily true, i.e. if an instance of B is created then an instance A is not necessarily created. Determining when to create a twin can be done using predicates. These can be used, for instance, to test the values of attributes in a newly created .
instance of B to determine whether a twin instance of A should be created.
WO 97/30535 PCZY~97JOD0lD
3. Relating attributes or subparts of attributes.
Sometimes classes in two models may be related via an attribute which is a list or a set i.e. a twin instance exists for each member of the list or set.
4. Implicit relationships. These relationships do not imply twinning between two classes. Sometimes, however, an attribute in one model may be used to uniquely identify an instance of a class within another model. This is termed an implicit relationship and is supported in Map with the is_imp assertion.
5. Relating virtual base classes. Allowing inheritance of mappings reduces work in the same way that allowing inheritance in classes does.
Regarding (a) above, each class is defined by a set of characteristics including:-- function (action), - relationships, - attributes {data members), - notifications, and - behaviour.
A context class is a particular class in a particular context or position in the containment hierarchy.
Regarding {b) above, each object represents a resource managed by the associated management system interface.
They can be at widely different levels of the abstraction, depending on the nature of the management required. One level of abstraction is cross-connect equipment, and a lower-level example is a switching fabric contained within the cross-connect equipment.
Regarding (c) above each object is an instance of a class, i.e. it will have particular characteristic values.
The Map language can describe relationships which specify that when an instance of one context class is created in one model, then an equivalent instance of another context class should be created in the other model. These two instances are said to be twinned and the relationships are . 25 referred to as creation relationships. The processor 6 creates code to support run time mappings between the instances stored in the MIU and instances stored in one of the systems being interworked.
WO 97/30535 PCT/I1;97/OOOIO
Referring to Fig. 2, examples of the creation relationships are illustrated. One such relationship is referred to as a total relationship 20 between a context class 21 and a context class 22, each having objects 23.
Such a relationship is one-to-one. Another type of ' creation relationship is a sub-set relationship 25 in which every instance created in A will lead to a twin creation in B, but not necessarily the reverse. Thus, the mappings include assertions defining cardinality.
Regarding the mapping of context classes, the Map langauge supports a simple set of assertions which are used to relate context classes in two models. These are described as follows:-1. Simple total relationship. Given a context class A in one model and context class B in another, they can be related using the expression (is-total A B). This means that whenever an instance of A is created, an instance of B must be created and vice versa. These instances are said to be twinned. This means that whenever an operation like get, set or action is performed on one, its equivalent must be performed on the other.
2. Subset and predicated relationships. The expression is-subset A B means that if an instance of A is created then an instance of B must also be created but the reverse is not necessarily true, i.e. if an instance of B is created then an instance A is not necessarily created. Determining when to create a twin can be done using predicates. These can be used, for instance, to test the values of attributes in a newly created .
instance of B to determine whether a twin instance of A should be created.
WO 97/30535 PCZY~97JOD0lD
3. Relating attributes or subparts of attributes.
Sometimes classes in two models may be related via an attribute which is a list or a set i.e. a twin instance exists for each member of the list or set.
4. Implicit relationships. These relationships do not imply twinning between two classes. Sometimes, however, an attribute in one model may be used to uniquely identify an instance of a class within another model. This is termed an implicit relationship and is supported in Map with the is_imp assertion.
5. Relating virtual base classes. Allowing inheritance of mappings reduces work in the same way that allowing inheritance in classes does.
6. Many-to-one creation assertions. These occur when two or more classes in one model are to be related to the same class in another model.
7. Mappings to functional systems. Many legacy systems use functional interfaces such as 'C' language APIs or MMLs. The Map language specifies interface functions and asynchronous messages for handling these types of functional interface.
Regarding the mapping of objects and their characteristics, this involves describing the ways in which managed resources represented by the objects relate to each other. This relationship is represented by the mapping of the contained characteristics of the objects.
The following are data-mapping cases involving primitives . which accompany the class mappings is total and is subset:
1. Mapping simple attributes. This involves describing data mappings between two attributes of simple type - 12 _ (e. g. enumerated or integer). These mappings will generally take the form of tables for mapping enumerated types and functions for mapping other types such as integers.
2. Mapping complex attributes. Complex attributes are those involving structures, choices, lists or other combinations of the above. The notation for mapping these types is more involved.
3. Compound attribute mappings. This is where several attributes map to one attribute.
4. Mapping actions. Actions in one class may be mapped to one or more actions in a related class. Mapping actions involve two stages. The first stage is to map the action's parameters and return values. This is done in the same way that attributes are mapped. The second stage in mapping actions is to map the critical elements of their behaviours involving gets, sets, creates and actions. This is a complex task.
5. Non-existent mappings for mandatory attributes. This situation occurs when an attribute is required at object creation time but none exists because there is no equivalent information in the interworked interface.
A default value is specified instead.
6. Uncacheable objects. This handles the situation of mapping notifications and what happens when an object can change but does not issue a notification to the MIU. Such objects are marked as uncacheable in the MIU.
The Map language consists of a list of declarations which describe the models 4 and 5 and the mappings 9. Map WO 97/30535 PCTl~97/00010 describes managed interfaces using managed object classes, data type definitions, functions, exceptions, messages, and a containment tree.
To choose an example, a typical datatype is described as S follows:
(deftype drink machine state (enum empty not~empty full)) This is an enumerated type declaration for the type drink machine state which can have one of three values:
empty, nvt empty or full. Structures are declared in a similar fashion as are choices and lists. In addition, there are certain basic types such as integer, natural, string, real, boolean and reference (for referencing other managed objects).
The following is an example of a mapping in the Map language. This mapping relates to the diagram of Fig. 3.
(is total GEquipment Gl2Eguipment (= GType i2)...) In this example, two models have taken a different approach to modelling the same real-world resources. One has chosen to model the set of all GEquipment objects using a single class called GEquipment. The other model has modelled the same type of resources using three different classes: Gl2Equipment, Gl4Equipment and Gl6Equipment which are less general than GEquipment.
GType is an attribute in GEquipment. When, for example, an instance of GEquipment is created with GType=12, its twin will be an instance of Gl2Equipment class.
When GType=24, there is no equivalent mapping. The default decision for a predicated mapping is not to create a twin. The attributes which may be tested are those that must be supplied at creation time, i.e. mandatory attributes.
The general format of an is total relationship is as follows:-(is total source-context-class target-context-class predicate (attribute-maps...] ;; Data mappings attributes (action-maps...) ;; Mappings for attributes (notification-maps...)) ;; Mappings for notifications The attribute-maps statement consists of a list of maps statements which have the general form for simple attribute mappings:
(maps <attribute-component> <attribute-component>
(down <maptable> ( <function>) (up <maptable> ( <function>)) There are two mappings, one in a downward direction, one in an upward direction. These can be described by means of either a maptable which provides explicit translations for enumerated types or by a function which is written programmatically, like an action behaviour, or drawn from a standard set of functions, e.g. per-hour-to-per-minute.
These predefined functions could potentially be provided in a library of separate Map modules. The simplest form of the maps statement is where two attributes are involved, both of which are enumerated types and maptables are used to specify downward and upward mappings. An example of this is illustrated below.
This example involves mapping simple attributes such as enumerated types or integers. Consider the following WO 97/30535 PCT/>E97i00010 types used to describe the attributes drink_machine_state and vending machine-state:
(deftype drink machine-state_type (enum run out ok low)) (deftype vending machine_state~type (enum empty operational)) In order to map an attribute of type drink machine state~type to an attribute of type vending machine state type, we use the following expression.
(attribute-mappings (maps drink machine state vending machine state ;; Mapping drink machine_state down to ;; vending~machine_state (down (maptable (run out empty) ;; run out maps to empty (ok operational) (low operational) )) ;; Mapping vending machine_state back up to ;; drink machine state (up (maptable (empty run out) ;; empty maps to run_out (operational ok) . Mapping tables are not always sufficient for describing a mapping. Where more flexibility is required, mapping functions use the same simple programmatic syntax for describing conversions. Consider the problem of mapping WO 97/30535 PCTlIE97/00010 from an integer attribute X to an integer attribute Y.
The value of Y is always double that of X unless X exceeds 128, in which case Y always takes the value 256. In Map this would be implemented as.
(maps X Y
(down ;; Declare a function with a single parameter ;; param will automatically be instantiated with (func (param) -0 (var integer ?rval) ;; Multiply param (X) by 2 and ;; assign to variable ?rval (assign ?real (* param 2)) ::
;; if ?real exceeds 256 then ;; let ?real = 256 ::
(if (> ?rval 256) (assign ?rval 256) nil __ ) i:
;; Return the final result, ?real (return ?real) ) (up ;;; function to do the opposite of the downward function) It is possible to use predefined or previously defined functions for mapping. For instance, if the values of VVO 97/30535 PCTllE97/OOOIO
attribute X mapped straight to attribute Y and vice versa the mapping could be defined as:
(maps X Y
' (down (function identity)) (up (function identity))) The compiler ensures that the number of arguments for the predefined function match those of the mapping (in this case a single argument is required in each direction).
The processor 6 has a compiler which generates skeletal source code for the MIU 10. Code generation occurs in two stages, namely pre-compiling for generation of a code template, and conversion of the code template into a code ZS output. The code template allows a user to view the automatically generated source code and to customise it by addition of hand-written code. Flags are used to differentiate between the two types of code so that user code is not over-written by the compiler. The compiler generates source code of a high level language such as C++
as well as IDL code. Mapping features implemented include processing of is total and is subset class mappings including aspects such as:
* Implementing mapping predicates, * Mapping 'context classes', * Mapping of class creation, * Propagation of simple/choice/structured data mappings for attributes both to and from the Managing and Managing Systems, * Propagation of actions including parameter and return value mapping, * Mapping set-valued attributes and action parameters, * Mapping of notifications raised by the Managed System.
In addition to a compiler, the processor 6 also uses the user interface 8 as a Map model editor and a mapping definition editor. Referring to Fig. 4, a tool bar 30 displayed by the user interface 8 is illustrated. This tool bar allows the user to select the source and target models to be mapped from the list of models loaded into the system. The screen shown in Fig. 4 is at the beginning of a mapping session in which a mapping has just been drawn between the class FABRIC in model A and the class FAB in model B. This is done simply by clicking on "Create Mapping" in the button arid then selecting the source and target classes for the mapping. A line is then displayed to depict the mapping and the window shown top-right of the figure appears . This is referred to as an assertion window and it allows the user to specify the type and the content of the mapping. Normally the user will begin by specifying the nature of the mapping at a class level and in this example it involves choosing a mapping as being is_total or is subset. Other options could be available such as is_imp, is_total rev, or is subset~rev. The predicate, to describe the run time conditions under which the twinning is to be formed, must be specified. After hitting the predicate button they can type the predicate directly in an editor window. At any stage during modelling or mapping, the user may decide to compile the system down to source code using the menu illustrated.
Tn summary, the process carried out by the processor 6 could be set out briefly in the following table:
STEP 1 Describe the managed interfaces to the two systems being interworked. In general these descriptions will be generated automatically from the existing system specification. For instance, a file containing a GDMO description is imported using a converter which converts the specification to Map.
If it is not possible to do this, then the user will have to describe the managed interface manually using the MIU CE's (Creation Environment) modeller toolbar.
STEP 2 Describe in the Map language the mappings between the two systems. Some of these will be specified by hand, others can be inferred automatically by the Creation Environment.
STEP 3 Compile the resultant Map description of the mappings down to code templates for the MIU. Code templates contain the outline of final MIU source code. They allow the user to see what this code output will look like. Code templates also allows the user to add their own handwritten code to supplement the autogenerated code (See step 4).
STEP 4 Add handwritten source code where necessary and generate final code output. Using code templates means that even if the mappings are recompiled the handwritten parts will not be overwritten.
Referring to Figs. 5 and 6, the MIU 10 which is created is shown in more detail. Fig. 5 shows the MIU broken into the MCFs and the ICF. The MCFs abstract the specifics of the particular communication protocols (e1 and e2). They use a homogeneous set of internal generic management WO 9'7130535 PCT/IE97/OOOIO
primitives to communicate with the ICF over interfaces i1 and i2. The internal structure of the ICF which is used to effect the mappings between the systems at runtime is important. The purpose of the MIU CE (Creation Environment) is to provide support for a process to build the ICF portion of an MIU. The internal protocol which crosses the internal reference points 11 and I2 includes the following primitives:-GET Get is specific to object based models and retrieves the value of an attribute. It is analogous to the CMIS M-GET service element.
SET Set is specific to object based models and sets the value of an attribute. It is analogous to the CMIS M-SET service element.
CREATE Create is specific to object based models and creates a new object instance. It is analogous to the CMIS M-CREATE service element.
DELETE Delete is specific to object based models and deletes an object instance. It is analogous to the CMIS M-DELETE service element.
FUNCTION Function invokes a function across the interface. Such a function could be a CMIS
M-ACTION or could be an MML command to a managed resource. Function can be synchronous in which it waits for the result of the function or asynchronous in which it doesn't wait.
NOTIFY Notify intercepts an event report from the interface. Such an event report could WO 97/30535 PCTl1E97lDOD~O
correspond to a CMIS M-EVENT-REPORT or an asynchronous message from the managed resource.
RECEIVE Receive enables the ICF to receive data from the interface. It would be used where the ICF expects an asynchronous response from an external entity. The receive primitive blocks the ICF waiting for the response.
START-MIU-TRANSACTION
This primitive enables a set of primitives to be invoked as an atomic transaction. If an error occurs during one of the operations which make up the transaction then the previous operation can be undone to revert ZS back to the previous state.
END MIU TRANSACTION
This primitive denotes the end of the transaction and indicates that the transaction was successful and should be committed.
ABORT MIU TRANSACTION
This primitive is used to terminate a transaction in which one of the operations was unsuccessful. It is used to rollback all the operations performed during the transaction and return the system to its previous state.
The MCFs perform the format conversion to these primitives from the relevant external protocol by hard-coded rules.
WO 97/30535 ~ 02244918 2004-09-23 pC~~97100010 The MIU provides the runtime support necessary for system interworking. In order to effect the mappings the MIU
architecture supports some particular runtime structures including:
* A Twinning Table - Given a reference to an object in the MIU it will return a reference to the equivalent object in the managed systems and vice versa.
* An expected events queue - This holds a list of events which are expected, when they are to arrive and what action to take when they arrive.
The Map compiler generates source code for these structures and all related mappings. Where required the MIU can be generated so that it stores its objects persistently using a database. The key to the Map compiler is that it allows flexibility in the type of source code it outputs . The user can insert ' tags ' in the map code allowing him or her to include portions of handwritten source code. This means that even if the mappings change the user's handwritten source code annotations will not be overwritten. Allowing flexible code generation is a great advantage. The invention does not require an expensive, proprietary runtime environment, because it can potentially generate code that will fit into a variety of runtime environments or else provide a 'lightweight' standalone runtime MIU.
The MCF and ICF components of the MIU 10 use CORBA IDL'~' interfaces to communicate with other components. These interfaces are based on primitives for retrieving and setting values of attributes, creating and deleting object instances, invoking a function across the interface, event reporting, enabling the ICF to wait until specified data is received from the interface, enabling a set of primitives to be invoked as an automatic transaction, denoting the end of the transaction, and rolling back a transaction.
There may additionally be primitives for start-up. As can be seen from Fig. 3, each of the component objects contains at least one process and there is also a server process for the DBMS (Database Management System). Both the managed and managing ICFs are DBMS clients and manipulate the managed objects in the MIB (Management Information Base), which is stored in the DBMS. Both the management and the managed ICF
servers act as distinct database clients and so are independent of each other.
Referring again to Fig. 6, the processes and IDL
interfaces of the MIU 10 are illustrated. The ICF 11 acts as a dispatcher for the managed and the managing ICF
interfaces. An MCF 12 is not allowed to associate directly with either the managed or managing ICF
interfaces, but instead associates with the ICF interface, which then passes back a reference to the appropriate managed or managing ICF interfaces. This is done to ensure that the MCFs in an MIU are associated with the correct interfaces.
It will be appreciated that the invention provides a process for producing an MIU which automates the task to a large extent, while at the same time allowing large degree of user interaction to provide the necessary flexibility. The structure of the models and the manner in which the mappings are generated allows the degree of automation, and in addition provides a simple structure which may be easily understood by the user for manual annotation and later modification. Further, because the structure of the MIU is simple, it may be easily modified to either take account of changes in management interfaces which are already interworked, or to add additional WO 97!30535 PCT/IE97/00010 interworking capability. The fact that the format conversion from the external to the internal protocol is performed by the MCFs separately from the ICF is an important feature as it results in a definite boundary between the MCFs and the ICF. Further, within the ICF, the model and mappings structure is relatively simple and allows easy modification.
The invention is not limited to the embodiments hereinbefore described, but may be varied in construction and detail.
Regarding the mapping of objects and their characteristics, this involves describing the ways in which managed resources represented by the objects relate to each other. This relationship is represented by the mapping of the contained characteristics of the objects.
The following are data-mapping cases involving primitives . which accompany the class mappings is total and is subset:
1. Mapping simple attributes. This involves describing data mappings between two attributes of simple type - 12 _ (e. g. enumerated or integer). These mappings will generally take the form of tables for mapping enumerated types and functions for mapping other types such as integers.
2. Mapping complex attributes. Complex attributes are those involving structures, choices, lists or other combinations of the above. The notation for mapping these types is more involved.
3. Compound attribute mappings. This is where several attributes map to one attribute.
4. Mapping actions. Actions in one class may be mapped to one or more actions in a related class. Mapping actions involve two stages. The first stage is to map the action's parameters and return values. This is done in the same way that attributes are mapped. The second stage in mapping actions is to map the critical elements of their behaviours involving gets, sets, creates and actions. This is a complex task.
5. Non-existent mappings for mandatory attributes. This situation occurs when an attribute is required at object creation time but none exists because there is no equivalent information in the interworked interface.
A default value is specified instead.
6. Uncacheable objects. This handles the situation of mapping notifications and what happens when an object can change but does not issue a notification to the MIU. Such objects are marked as uncacheable in the MIU.
The Map language consists of a list of declarations which describe the models 4 and 5 and the mappings 9. Map WO 97/30535 PCTl~97/00010 describes managed interfaces using managed object classes, data type definitions, functions, exceptions, messages, and a containment tree.
To choose an example, a typical datatype is described as S follows:
(deftype drink machine state (enum empty not~empty full)) This is an enumerated type declaration for the type drink machine state which can have one of three values:
empty, nvt empty or full. Structures are declared in a similar fashion as are choices and lists. In addition, there are certain basic types such as integer, natural, string, real, boolean and reference (for referencing other managed objects).
The following is an example of a mapping in the Map language. This mapping relates to the diagram of Fig. 3.
(is total GEquipment Gl2Eguipment (= GType i2)...) In this example, two models have taken a different approach to modelling the same real-world resources. One has chosen to model the set of all GEquipment objects using a single class called GEquipment. The other model has modelled the same type of resources using three different classes: Gl2Equipment, Gl4Equipment and Gl6Equipment which are less general than GEquipment.
GType is an attribute in GEquipment. When, for example, an instance of GEquipment is created with GType=12, its twin will be an instance of Gl2Equipment class.
When GType=24, there is no equivalent mapping. The default decision for a predicated mapping is not to create a twin. The attributes which may be tested are those that must be supplied at creation time, i.e. mandatory attributes.
The general format of an is total relationship is as follows:-(is total source-context-class target-context-class predicate (attribute-maps...] ;; Data mappings attributes (action-maps...) ;; Mappings for attributes (notification-maps...)) ;; Mappings for notifications The attribute-maps statement consists of a list of maps statements which have the general form for simple attribute mappings:
(maps <attribute-component> <attribute-component>
(down <maptable> ( <function>) (up <maptable> ( <function>)) There are two mappings, one in a downward direction, one in an upward direction. These can be described by means of either a maptable which provides explicit translations for enumerated types or by a function which is written programmatically, like an action behaviour, or drawn from a standard set of functions, e.g. per-hour-to-per-minute.
These predefined functions could potentially be provided in a library of separate Map modules. The simplest form of the maps statement is where two attributes are involved, both of which are enumerated types and maptables are used to specify downward and upward mappings. An example of this is illustrated below.
This example involves mapping simple attributes such as enumerated types or integers. Consider the following WO 97/30535 PCT/>E97i00010 types used to describe the attributes drink_machine_state and vending machine-state:
(deftype drink machine-state_type (enum run out ok low)) (deftype vending machine_state~type (enum empty operational)) In order to map an attribute of type drink machine state~type to an attribute of type vending machine state type, we use the following expression.
(attribute-mappings (maps drink machine state vending machine state ;; Mapping drink machine_state down to ;; vending~machine_state (down (maptable (run out empty) ;; run out maps to empty (ok operational) (low operational) )) ;; Mapping vending machine_state back up to ;; drink machine state (up (maptable (empty run out) ;; empty maps to run_out (operational ok) . Mapping tables are not always sufficient for describing a mapping. Where more flexibility is required, mapping functions use the same simple programmatic syntax for describing conversions. Consider the problem of mapping WO 97/30535 PCTlIE97/00010 from an integer attribute X to an integer attribute Y.
The value of Y is always double that of X unless X exceeds 128, in which case Y always takes the value 256. In Map this would be implemented as.
(maps X Y
(down ;; Declare a function with a single parameter ;; param will automatically be instantiated with (func (param) -0 (var integer ?rval) ;; Multiply param (X) by 2 and ;; assign to variable ?rval (assign ?real (* param 2)) ::
;; if ?real exceeds 256 then ;; let ?real = 256 ::
(if (> ?rval 256) (assign ?rval 256) nil __ ) i:
;; Return the final result, ?real (return ?real) ) (up ;;; function to do the opposite of the downward function) It is possible to use predefined or previously defined functions for mapping. For instance, if the values of VVO 97/30535 PCTllE97/OOOIO
attribute X mapped straight to attribute Y and vice versa the mapping could be defined as:
(maps X Y
' (down (function identity)) (up (function identity))) The compiler ensures that the number of arguments for the predefined function match those of the mapping (in this case a single argument is required in each direction).
The processor 6 has a compiler which generates skeletal source code for the MIU 10. Code generation occurs in two stages, namely pre-compiling for generation of a code template, and conversion of the code template into a code ZS output. The code template allows a user to view the automatically generated source code and to customise it by addition of hand-written code. Flags are used to differentiate between the two types of code so that user code is not over-written by the compiler. The compiler generates source code of a high level language such as C++
as well as IDL code. Mapping features implemented include processing of is total and is subset class mappings including aspects such as:
* Implementing mapping predicates, * Mapping 'context classes', * Mapping of class creation, * Propagation of simple/choice/structured data mappings for attributes both to and from the Managing and Managing Systems, * Propagation of actions including parameter and return value mapping, * Mapping set-valued attributes and action parameters, * Mapping of notifications raised by the Managed System.
In addition to a compiler, the processor 6 also uses the user interface 8 as a Map model editor and a mapping definition editor. Referring to Fig. 4, a tool bar 30 displayed by the user interface 8 is illustrated. This tool bar allows the user to select the source and target models to be mapped from the list of models loaded into the system. The screen shown in Fig. 4 is at the beginning of a mapping session in which a mapping has just been drawn between the class FABRIC in model A and the class FAB in model B. This is done simply by clicking on "Create Mapping" in the button arid then selecting the source and target classes for the mapping. A line is then displayed to depict the mapping and the window shown top-right of the figure appears . This is referred to as an assertion window and it allows the user to specify the type and the content of the mapping. Normally the user will begin by specifying the nature of the mapping at a class level and in this example it involves choosing a mapping as being is_total or is subset. Other options could be available such as is_imp, is_total rev, or is subset~rev. The predicate, to describe the run time conditions under which the twinning is to be formed, must be specified. After hitting the predicate button they can type the predicate directly in an editor window. At any stage during modelling or mapping, the user may decide to compile the system down to source code using the menu illustrated.
Tn summary, the process carried out by the processor 6 could be set out briefly in the following table:
STEP 1 Describe the managed interfaces to the two systems being interworked. In general these descriptions will be generated automatically from the existing system specification. For instance, a file containing a GDMO description is imported using a converter which converts the specification to Map.
If it is not possible to do this, then the user will have to describe the managed interface manually using the MIU CE's (Creation Environment) modeller toolbar.
STEP 2 Describe in the Map language the mappings between the two systems. Some of these will be specified by hand, others can be inferred automatically by the Creation Environment.
STEP 3 Compile the resultant Map description of the mappings down to code templates for the MIU. Code templates contain the outline of final MIU source code. They allow the user to see what this code output will look like. Code templates also allows the user to add their own handwritten code to supplement the autogenerated code (See step 4).
STEP 4 Add handwritten source code where necessary and generate final code output. Using code templates means that even if the mappings are recompiled the handwritten parts will not be overwritten.
Referring to Figs. 5 and 6, the MIU 10 which is created is shown in more detail. Fig. 5 shows the MIU broken into the MCFs and the ICF. The MCFs abstract the specifics of the particular communication protocols (e1 and e2). They use a homogeneous set of internal generic management WO 9'7130535 PCT/IE97/OOOIO
primitives to communicate with the ICF over interfaces i1 and i2. The internal structure of the ICF which is used to effect the mappings between the systems at runtime is important. The purpose of the MIU CE (Creation Environment) is to provide support for a process to build the ICF portion of an MIU. The internal protocol which crosses the internal reference points 11 and I2 includes the following primitives:-GET Get is specific to object based models and retrieves the value of an attribute. It is analogous to the CMIS M-GET service element.
SET Set is specific to object based models and sets the value of an attribute. It is analogous to the CMIS M-SET service element.
CREATE Create is specific to object based models and creates a new object instance. It is analogous to the CMIS M-CREATE service element.
DELETE Delete is specific to object based models and deletes an object instance. It is analogous to the CMIS M-DELETE service element.
FUNCTION Function invokes a function across the interface. Such a function could be a CMIS
M-ACTION or could be an MML command to a managed resource. Function can be synchronous in which it waits for the result of the function or asynchronous in which it doesn't wait.
NOTIFY Notify intercepts an event report from the interface. Such an event report could WO 97/30535 PCTl1E97lDOD~O
correspond to a CMIS M-EVENT-REPORT or an asynchronous message from the managed resource.
RECEIVE Receive enables the ICF to receive data from the interface. It would be used where the ICF expects an asynchronous response from an external entity. The receive primitive blocks the ICF waiting for the response.
START-MIU-TRANSACTION
This primitive enables a set of primitives to be invoked as an atomic transaction. If an error occurs during one of the operations which make up the transaction then the previous operation can be undone to revert ZS back to the previous state.
END MIU TRANSACTION
This primitive denotes the end of the transaction and indicates that the transaction was successful and should be committed.
ABORT MIU TRANSACTION
This primitive is used to terminate a transaction in which one of the operations was unsuccessful. It is used to rollback all the operations performed during the transaction and return the system to its previous state.
The MCFs perform the format conversion to these primitives from the relevant external protocol by hard-coded rules.
WO 97/30535 ~ 02244918 2004-09-23 pC~~97100010 The MIU provides the runtime support necessary for system interworking. In order to effect the mappings the MIU
architecture supports some particular runtime structures including:
* A Twinning Table - Given a reference to an object in the MIU it will return a reference to the equivalent object in the managed systems and vice versa.
* An expected events queue - This holds a list of events which are expected, when they are to arrive and what action to take when they arrive.
The Map compiler generates source code for these structures and all related mappings. Where required the MIU can be generated so that it stores its objects persistently using a database. The key to the Map compiler is that it allows flexibility in the type of source code it outputs . The user can insert ' tags ' in the map code allowing him or her to include portions of handwritten source code. This means that even if the mappings change the user's handwritten source code annotations will not be overwritten. Allowing flexible code generation is a great advantage. The invention does not require an expensive, proprietary runtime environment, because it can potentially generate code that will fit into a variety of runtime environments or else provide a 'lightweight' standalone runtime MIU.
The MCF and ICF components of the MIU 10 use CORBA IDL'~' interfaces to communicate with other components. These interfaces are based on primitives for retrieving and setting values of attributes, creating and deleting object instances, invoking a function across the interface, event reporting, enabling the ICF to wait until specified data is received from the interface, enabling a set of primitives to be invoked as an automatic transaction, denoting the end of the transaction, and rolling back a transaction.
There may additionally be primitives for start-up. As can be seen from Fig. 3, each of the component objects contains at least one process and there is also a server process for the DBMS (Database Management System). Both the managed and managing ICFs are DBMS clients and manipulate the managed objects in the MIB (Management Information Base), which is stored in the DBMS. Both the management and the managed ICF
servers act as distinct database clients and so are independent of each other.
Referring again to Fig. 6, the processes and IDL
interfaces of the MIU 10 are illustrated. The ICF 11 acts as a dispatcher for the managed and the managing ICF
interfaces. An MCF 12 is not allowed to associate directly with either the managed or managing ICF
interfaces, but instead associates with the ICF interface, which then passes back a reference to the appropriate managed or managing ICF interfaces. This is done to ensure that the MCFs in an MIU are associated with the correct interfaces.
It will be appreciated that the invention provides a process for producing an MIU which automates the task to a large extent, while at the same time allowing large degree of user interaction to provide the necessary flexibility. The structure of the models and the manner in which the mappings are generated allows the degree of automation, and in addition provides a simple structure which may be easily understood by the user for manual annotation and later modification. Further, because the structure of the MIU is simple, it may be easily modified to either take account of changes in management interfaces which are already interworked, or to add additional WO 97!30535 PCT/IE97/00010 interworking capability. The fact that the format conversion from the external to the internal protocol is performed by the MCFs separately from the ICF is an important feature as it results in a definite boundary between the MCFs and the ICF. Further, within the ICF, the model and mappings structure is relatively simple and allows easy modification.
The invention is not limited to the embodiments hereinbefore described, but may be varied in construction and detail.
Claims (21)
PROPERTY OR PRIVILEGE IS CLAIMED ARE DEFINED AS FOLLOWS:
1. A process for producing a management interworking unit for a pair of management interfaces comprising the steps of:-producing an information conversion function (ICF) by:-storing a model associate with each interface, each model comprising objects representing managed resources, and creating mappings including run time conversion functions between equivalent parts of the models; and producing a message communication function (MCF) associated with each management interface, each MCF
comprising means for performing format conversion between the external protocol of the associated interfaces and an internal protocol for the ICF;
each model comprises objects in a containment hierarchy providing a containment context for each object; and each object has a class defined by characteristics independently of the context; and the mappings are between individual objects and between groups of objects having the same class and context, namely context classes.
comprising means for performing format conversion between the external protocol of the associated interfaces and an internal protocol for the ICF;
each model comprises objects in a containment hierarchy providing a containment context for each object; and each object has a class defined by characteristics independently of the context; and the mappings are between individual objects and between groups of objects having the same class and context, namely context classes.
2. A process as claimed in claim 1, wherein the models are created at least partially automatically by loader modules.
3. A process as claimed in claim 1 or 2, wherein the models are created from management interface specifications, and specification free text is manually converted to the model language.
4. A process as claimed in claim 1, 2 or 3, wherein the mappings define context class cardinality.
5. A process as claimed in claim 4, where mappings are created between context classes.
6. A process as claimed in claim 4 or 5, wherein mappings are created between objects.
7. A process as claimed in claims 4 to 6, wherein mappings are created between object characteristics.
8. A process as claimed in claim 7, wherein the object characteristics include object functions, relationships, attributes, notifications, and behaviour.
9. A process as claimed in any one of claims 1 to 8, wherein the mappings are created interactively using a graphical interface representing the models and the mappings.
10. A process as claimed in any one of claims 1 to 9, wherein mappings are predicated by run time rules selected for the mappings.
11. A process as claimed in any one of claims 1 to 10, wherein the process has the further step of pre-compiling the models and the mappings to a template to produce source code.
12. A process as claimed in claim 11, wherein the template is manually modified after pre-compiling and flags are inserted in the template to differentiate automatically generated code from manually generated code.
13. A process as claimed in any one of claims 1 to 12, wherein searches are carried out to determine if a proposed mapping has previously been made for similar characteristics and such mappings may be re-used.
14. A management interworking unit (MIU) for at least two management interfaces comprising:-an information conversion function (ICF) comprising:-a model associated with each interface, each model comprising objects representing managed resources, and run time conversion mappings between equivalent parts of the models; and a message communication function (MCF) associated with each management interface, each MCF comprising means for performing format conversion between the external protocol of the associated interface and an internal protocol of the ICF; and each model comprises objects in a containment hierarchy providing a containment context for each object and each object has a class defined by characteristics independently of the context; and the mappings are between individual objects and between groups of objects having the same class and context, namely context classes.
15. A management interworking unit as claimed in claim 14, wherein the mappings define context class cardinality.
16. A management interworking unit as claimed in claim 14 and 15, wherein mappings link context classes.
17. A management interworking unit as claimed in any one of claims 14 to 16, wherein mappings link objects.
18. A management interworking unit as claimed in any one of claims 14 to 17, wherein mappings link object characteristics.
19. A management interworking unit as claimed in claim 18, wherein the object characteristics include object functions or actions, relationships, attributes, notifications, and behaviour.
20. A management interworking unit as claimed in any one of claims 14 to 19, wherein mappings are predicated by run time rules selected for the mappings.
21. A management interworking unit as claimed in any one of claims 14 to 20, wherein the internal protocol includes primitives controlling start, end, and rollback of atomic transactions in the ICF.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| IE960137 | 1996-02-15 | ||
| IES960137 | 1996-02-15 | ||
| PCT/IE1997/000010 WO1997030535A1 (en) | 1996-02-15 | 1997-02-14 | A management interworking unit and a method for producing such a unit |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2244918A1 CA2244918A1 (en) | 1997-08-21 |
| CA2244918C true CA2244918C (en) | 2006-05-09 |
Family
ID=11041075
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002244918A Expired - Lifetime CA2244918C (en) | 1996-02-15 | 1997-02-14 | A management interworking unit and a method for producing such a unit |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US6324576B1 (en) |
| EP (1) | EP0880842B1 (en) |
| JP (1) | JP2000504868A (en) |
| CN (1) | CN1166115C (en) |
| AU (1) | AU732374B2 (en) |
| CA (1) | CA2244918C (en) |
| DE (1) | DE69731614T2 (en) |
| WO (1) | WO1997030535A1 (en) |
Families Citing this family (29)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5848415A (en) * | 1996-12-18 | 1998-12-08 | Unisys Corporation | Selective multiple protocol transport and dynamic format conversion in a multi-user network |
| US6785722B2 (en) * | 1998-03-20 | 2004-08-31 | Sun Microsystems, Inc. | Apparatus, methods, and computer program products for transactional support of network management operations |
| US6847384B1 (en) * | 1998-05-14 | 2005-01-25 | Autodesk, Inc. | Translating objects between software applications which employ different data formats |
| US6349332B2 (en) * | 1998-07-29 | 2002-02-19 | Nortel Networks Limited | Mechanism for integration of management functionality in communications networks |
| KR100270916B1 (en) * | 1998-10-17 | 2000-11-01 | 서평원 | How to add network management system and class dynamically |
| US6393425B1 (en) * | 1999-05-05 | 2002-05-21 | Microsoft Corporation | Diagramming real-world models based on the integration of a database, such as models of a computer network |
| BR0010743A (en) * | 1999-05-20 | 2002-04-16 | Lancer Partnership Ltd | Beverage Dispenser, processes for designing a beverage dispenser or reconfiguring an existing beverage dispenser, to receive user input into a beverage dispenser, to send information from a beverage dispenser to a user, to dispense a beverage from a beverage dispenser, external communication for a beverage dispenser, and external communication for a beverage dispenser, system for monitoring frozen refrigerant, process for controlling a refrigeration unit of a beverage dispenser, system for level monitoring liquid, and, process to control a carbonation system of a drink dispenser |
| EP1107152A3 (en) * | 1999-12-03 | 2007-08-29 | Citibank, N.A. | Method and system for managing communication of information |
| US6901588B1 (en) * | 2000-04-17 | 2005-05-31 | Codemesh, Inc. | Sharing components between programming languages by use of polymorphic proxy |
| US7216101B2 (en) * | 2000-12-27 | 2007-05-08 | Gxs, Inc. | Process for creating a trading partner profile |
| US7020660B2 (en) * | 2001-06-29 | 2006-03-28 | Siemens Medical Solutions Health Services Corp. | Data object generator and method of use |
| US8549114B2 (en) | 2002-06-12 | 2013-10-01 | Bladelogic, Inc. | Method and system for model-based heterogeneous server configuration management |
| US7558847B2 (en) * | 2002-09-13 | 2009-07-07 | Intelliden, Inc. | System and method for mapping between and controlling different device abstractions |
| US20040128644A1 (en) * | 2002-10-25 | 2004-07-01 | Walter Hurst | Software architecture for distributed enterprise business applications |
| US20040158836A1 (en) * | 2003-02-11 | 2004-08-12 | Adkins Ronald P. | GSM-SCA unified object model |
| US7966418B2 (en) | 2003-02-21 | 2011-06-21 | Axeda Corporation | Establishing a virtual tunnel between two computer programs |
| EP1687346B1 (en) * | 2003-11-14 | 2012-06-06 | ExxonMobil Chemical Patents Inc. | Propylene-based elastomers and uses thereof |
| US7650590B2 (en) * | 2004-01-13 | 2010-01-19 | Sap Ag | Flexible code generation |
| US7827205B2 (en) * | 2004-05-27 | 2010-11-02 | International Business Machines Corporation | Bi-directional data mapping tool |
| US7555743B2 (en) * | 2004-06-15 | 2009-06-30 | Alcatel-Lucent Usa Inc. | SNMP agent code generation and SNMP agent framework for network management application development |
| US20050278693A1 (en) * | 2004-06-15 | 2005-12-15 | Brunell Edward G | Distribution adaptor for network management application development |
| US20060004856A1 (en) * | 2004-06-15 | 2006-01-05 | Xiangyang Shen | Data management and persistence frameworks for network management application development |
| US20050278709A1 (en) * | 2004-06-15 | 2005-12-15 | Manjula Sridhar | Resource definition language for network management application development |
| US20050278361A1 (en) * | 2004-06-15 | 2005-12-15 | Brunell Edward G | View definition language for network management application development |
| US20060036721A1 (en) * | 2004-06-15 | 2006-02-16 | Dong Zhao | Run-time tool for network management application |
| US20060070082A1 (en) * | 2004-06-15 | 2006-03-30 | Manjula Sridhar | Managed object framework for network management application development |
| US20050278708A1 (en) * | 2004-06-15 | 2005-12-15 | Dong Zhao | Event management framework for network management application development |
| US20100083270A1 (en) * | 2008-09-30 | 2010-04-01 | Rockwell Automation Technologies, Inc. | Resource class binding for industrial automation |
| US8923204B2 (en) * | 2012-05-29 | 2014-12-30 | Alcatel Lucent | Message handling extension using context artifacts |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5291583A (en) * | 1990-12-14 | 1994-03-01 | Racal-Datacom, Inc. | Automatic storage of persistent ASN.1 objects in a relational schema |
| US5471617A (en) * | 1991-06-24 | 1995-11-28 | Compaq Computer Corporation | Computer management system and associated management information base |
| DE69322857T2 (en) * | 1992-08-28 | 1999-05-27 | Ericsson Telefon Ab L M | MANAGEMENT IN TELECOM AND OPEN SYSTEMS |
| US5608720A (en) * | 1993-03-09 | 1997-03-04 | Hubbell Incorporated | Control system and operations system interface for a network element in an access system |
| CA2159001A1 (en) | 1993-03-26 | 1994-10-13 | David Alan Spurgeon Brown | Generic managed object model for lan domain |
| US5491822A (en) * | 1993-12-30 | 1996-02-13 | International Business Machines Corporation | Multi-phase commit processing for creation and deletion of managed objects |
| US5519868A (en) * | 1993-12-30 | 1996-05-21 | International Business Machines Corporation | Compilation of information contained in GDMO name bindings |
| SG47034A1 (en) | 1994-02-28 | 1998-03-20 | British Telecomm | A data storage device |
| JP3521955B2 (en) * | 1994-06-14 | 2004-04-26 | 株式会社日立製作所 | Hierarchical network management system |
| JPH08242286A (en) * | 1995-03-03 | 1996-09-17 | Fujitsu Ltd | Communication network management control system |
| US5903731A (en) * | 1995-06-14 | 1999-05-11 | Us West Technologies, Inc. | System and associated method for re-engineering a telecommunications network support system with object-oriented translators |
| DE69633448T2 (en) * | 1995-07-26 | 2005-09-22 | Telefonaktiebolaget Lm Ericsson (Publ) | UNIVERSAL OBJECT TRANSLATION AGENT |
| US5864862A (en) * | 1996-09-30 | 1999-01-26 | Telefonaktiebolaget Lm Ericsson (Publ) | System and method for creating reusable components in an object-oriented programming environment |
| US5764955A (en) * | 1995-10-19 | 1998-06-09 | Oasys Group, Inc. | Gateway for using legacy telecommunications network element equipment with a common management information protocol |
| US5802146A (en) * | 1995-11-22 | 1998-09-01 | Bell Atlantic Network Services, Inc. | Maintenance operations console for an advanced intelligent network |
-
1997
- 1997-02-14 WO PCT/IE1997/000010 patent/WO1997030535A1/en active IP Right Grant
- 1997-02-14 CN CNB971923485A patent/CN1166115C/en not_active Expired - Fee Related
- 1997-02-14 JP JP9529155A patent/JP2000504868A/en active Pending
- 1997-02-14 DE DE69731614T patent/DE69731614T2/en not_active Expired - Lifetime
- 1997-02-14 EP EP97905370A patent/EP0880842B1/en not_active Expired - Lifetime
- 1997-02-14 CA CA002244918A patent/CA2244918C/en not_active Expired - Lifetime
- 1997-02-14 US US09/125,252 patent/US6324576B1/en not_active Expired - Lifetime
- 1997-02-14 AU AU22274/97A patent/AU732374B2/en not_active Ceased
Also Published As
| Publication number | Publication date |
|---|---|
| EP0880842A1 (en) | 1998-12-02 |
| CN1211364A (en) | 1999-03-17 |
| AU2227497A (en) | 1997-09-02 |
| DE69731614D1 (en) | 2004-12-23 |
| DE69731614T2 (en) | 2005-10-06 |
| WO1997030535A1 (en) | 1997-08-21 |
| CN1166115C (en) | 2004-09-08 |
| JP2000504868A (en) | 2000-04-18 |
| AU732374B2 (en) | 2001-04-26 |
| EP0880842B1 (en) | 2004-11-17 |
| US6324576B1 (en) | 2001-11-27 |
| CA2244918A1 (en) | 1997-08-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2244918C (en) | A management interworking unit and a method for producing such a unit | |
| US5848273A (en) | Method for generating OLE automation and IDL interfaces from metadata information | |
| US6208345B1 (en) | Visual data integration system and method | |
| US6349333B1 (en) | Platform independent alarm service for manipulating managed objects in a distributed network management system | |
| US5960200A (en) | System to transition an enterprise to a distributed infrastructure | |
| US6061721A (en) | Bean-based management system | |
| EP0909058B1 (en) | Network management framework | |
| US20050278693A1 (en) | Distribution adaptor for network management application development | |
| US6182024B1 (en) | Modeling behaviors of objects associated with finite state machines and expressing a sequence without introducing an intermediate state with the arc language | |
| US6996801B2 (en) | System and method for automatically generating program | |
| EP0908816A2 (en) | Method and system for remotely browsing objects | |
| US20030101291A1 (en) | Application programming interface for provision of DICOM services | |
| WO1991009365A2 (en) | Computer-assisted software engineering for cooperative processing | |
| US20060004856A1 (en) | Data management and persistence frameworks for network management application development | |
| JP3013983B2 (en) | Graphic interface command generation and execution tool | |
| US6219802B1 (en) | System for generating test data | |
| Baldassari et al. | PROTOB a hierarchical object-oriented CASE tool for distributed systems | |
| CN114721711A (en) | Tool and method for reducing software research and development configuration based on GraphQL | |
| IE970095A1 (en) | A management interworking unit and a method for producing¹such a unit | |
| Yoda et al. | Object oriented TMN based operations systems development platform | |
| JP2000151743A (en) | Method for designing network control system | |
| Arief et al. | Specifying distributed system services | |
| Genilloud et al. | Managing ANSA objects with OSI Network Management tools | |
| Speaker | A toolkit for developing TMN manager/agent applications | |
| CN115686489A (en) | Automatic generation method and device for transmission service code of flight control system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKEX | Expiry |
Effective date: 20170214 |