Patent Publication Number: US-2004059802-A1

Title: Modeling states and/or transitions in a computer system

Description:
[0001] The present invention relates to the modeling of a computer system, e.g. a networked computer system.  
       [0002] In published patent application WO/0184313 (and/or corresponding US 2002/0007468 A1), the applicant company has proposed a system and method for achieving high availability in a networked computer system. It has also proposed a system and method for using high-availability-aware components to achieve high availability in a networked computer system.  
       [0003] It has now been found of interest to model the platform and/or the applications which run on it, totally or partially. This invention offers various aspects of such a modeling, which is applicable independently of the high availability aspects. This invention also offers applications of such a modeling, optionally, as it will be seen hereinafter.  
       [0004] Generally, in one of its aspects, this invention offers a program product, comprising:  
       [0005] groups of data, in a common software language, each group of data comprising:  
       [0006] first data modeling components (software and/or hardware), and interactions between such components (e.g. interfaces),  
       [0007] second data modeling a software load, comprising a set of components and a set of interactions, as defined in said first data, and  
       [0008] first software code capable of interacting with the first and second data, for qualifying said second data as defining a valid combination of components.  
       [0009] The first data may include “version” data for the interaction data, and “version range” data related to component data, with the first software code checking that the version of an interaction lies within the version range of both components (e.g. a client and a server) cooperating through that interaction.  
       [0010] In another aspect, said group of data may comprise generic entities for the components, interactions and software load; the generic entities have predefined members; and the first and second data using such generic entities for representing the components, interactions and software load.  
       [0011] In still another aspect, the group of data (or a relevant portion of it) may be stored in accordance with a common tree structure. Third data may be provided for modeling configuration values for loading a software load as defined in the second data.  
       [0012] In still another aspect, fourth data may comprise platform update data for designating a configuration update, having has an update level, and the program product further comprises third software code capable of determining whether a transition to such a configuration update is authorized. A rollback may also be provided for.  
       [0013] All the data may be based on a common software language, which may be a markup language, e.g. XML. 
     
    
    
     [0014] Other alternative features and advantages of the invention will appear in the detailed description below and in the appended drawings, in which:  
     [0015]FIG. 1 is a tree diagram depicting an exemplary physical component hierarchy among hardware components in a networked computer system;  
     [0016]FIG. 2 is a tree diagram depicting an exemplary software component hierarchy among software components in a networked computer system;  
     [0017]FIG. 3 is a representational diagram of an exemplary component that may be used in an embodiment of the present invention;  
     [0018]FIG. 4 is a representational diagram of one embodiment of distributed system services that may be used in an embodiment of the present invention;  
     [0019]FIG. 5 illustratively shows software components, forming client/server combinations;  
     [0020]FIG. 6 shows an exemplary organization of model data, in an embodiment of this invention;  
     [0021]FIG. 7 is a flow-chart of an exemplary version attribute checking tool;  
     [0022]FIG. 8 shows an exemplary naming tree;  
     [0023]FIG. 9 is a block diagram of an embodiment of this invention, at the design level;  
     [0024]FIG. 10 is a block diagram of an embodiment of this invention, at the operational level;  
     [0025]FIG. 11 is a flow chart of an exemplary tool for checking the accuracy of version value intervals;  
     [0026]FIG. 12 is a flow chart of an exemplary tool for checking version consistency;  
     [0027]FIG. 13 is a flow chart of an exemplary tool for checking a configuration update;  
     [0028]FIG. 14 is a “file-oriented” form of the flowchart of FIG. 13;  
     [0029]FIG. 15 is a flow chart of an exemplary platform update;  
     [0030]FIG. 16 is a flow chart of an exemplary tool for checking the compatibility of an update set;  
     [0031]FIG. 17 diagrammatically shows a “software load life cycle”;  
     [0032]FIG. 18 is an exemplary block diagram showing how a given (hardware or software) component may interact with its surroundings, at the design level;  
     [0033]FIG. 19 is an exemplary block diagram showing how a given (hardware or software) component may interact with its surroundings, at the runtime level;  
     [0034]FIG. 20 is an exemplary flow chart showing how a component type configuration MIB may be used when developing a component;  
     [0035]FIG. 21 is an exemplary diagram showing a platform update operation;  
     [0036]FIG. 22 is another exemplary diagram showing a platform update operation, in a different view;  
     [0037]FIG. 23 is an exemplary diagram showing the configuration of a component;  
     [0038]FIG. 24 is an exemplary diagram showing a software update;  
     [0039]FIG. 25 is an exemplary diagram showing a configuration update, made in response to a configuration update event;  
     [0040]FIG. 26 is an exemplary diagram showing a component, and its interactions with its surroundings; and  
     [0041]FIG. 27 is an exemplary diagram showing the operation of two redundant components, and their interactions with the surroundings. 
    
    
     [0042] As they may be cited in this specification, Sun, Sun Microsystems, docs.sun.com, Answerbook, Answerbook2, Solaris, Java, EmbeddedJava, PersonalJava, JavaBeans, Java Naming and Directory Interface, JDBC, Enterprise JavaBeans (EJB), Jini, Sun Spontaneous Management, Java 2 Enterprise Edition (J2EE), JavaServer Pages (JSP) and I-planet are trademarks of Sun Microsystems, Inc. SPARC is a trademark of SPARC International, Inc.  
     [0043] A portion of the disclosure of this patent document contains material which may be subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright and/or author&#39;s rights whatsoever.  
     [0044] Additionally, the detailed description is supplemented with the following Exhibits:  
     [0045] Exhibit Eh1 contains an exemplary Document Type Definition or DTD in XML;  
     [0046] Exhibit Eh2 comprises explanations on XML, and tables summarizing elements of the DTD of Exhibit Eh1;  
     [0047] Exhibit Eh3 is a description of the elements in the exemplary DTD of Exhibit Eh1;  
     [0048] Exhibit Eh4 shows exemplary CGHA-ML code or “CGHA-ML definitions”;  
     [0049] Exhibit Eh5 comprises tables for use in connection with Exhibit Eh4;  
     [0050] Exhibit Eh6 shows exemplary tables of mapping from CGHA-ML;  
     [0051] Exhibit Eh7 shows exemplary LDAP configuration objects;  
     [0052] Exhibit Eh8 contains illustrative tables;  
     [0053] Exhibit Eh9 contains an exemplary LDAP object, i.e. a component type configuration MIB.  
     [0054] In the foregoing description, references to the Exhibits are may be made directly by the Exhibit or Exhibit section identifier: for example, Eh7-O1 would refer to section O1 in Exhibit Eh7 (the prefix designating the Exhibit may be omitted if there is no ambiguity). The Exhibits are placed apart for the purpose of clarifying the detailed description, and of enabling easier reference. They nevertheless form an integral part of the description of the present invention. This applies to the drawings as well.  
     [0055] Now, making reference to software entities imposes certain conventions in notation. For example, in the detailed description, Italics (or the quote sign “) may be used when deemed necessary for clarity. However, in code examples:  
     [0056] quote signs are used only when required in accordance with the rules of writing code, i.e. for string values.  
     [0057] an expression framed with square brackets, e.g. [property=value]* is optional and may be repeated if followed by *;  
     [0058] a name followed with [ ] indicates an array.  
     [0059] Also, &lt;version&gt; may be used to designate a value for the entity named “version” (or version).  
     [0060] The reader is assumed to be familiar with object oriented programming in general, more specifically with Java. Details may be found at http://docs.sun.com. and http://Java.sun.com and/or in the corresponding printed documentation, e.g. “The Java Language Specification”, J. GOSLING, Bill JOY, Guy STEELE, Addison Wesley, 1996, ISBN  0 - 201 - 63451 - 1 . Other printed documentation is currently available at:  
     [0061] http://www1.fatbrain.com/documentation/sun.  
     [0062] The reader is also assumed to be familiar with the extended Markup Language (XML) specification, available from W3C at http://www.w3.org/TR, and/or from the booklet “XML Pocket Reference”, Robert ECKSTEIN, O&#39;REILLY, U.S.A, October 1999.  
     [0063] The reader is further assumed to be able to map from a model in UML to a programming language such as Java or C++, and to be familiar with client-server applications written in C. The Unified Modeling Language, or UML, is defined inter alia in Appendix D of the Common Information Model (CIM) specification, available on the web site of the Distributed Management Task Force (DMTF), http://www.dtmf.org/, or in the corresponding printed documentation.  
     [0064] The reader is again assumed to be familiar with LDAP (Lightweight Directory Access Protocol). A detailed description of LDAP may be found at www.openldap.org/devel/admin/, and in the corresponding printed documentation.  
     [0065] A number of concepts described in the above cited WO/0184313 may be of interest in understanding the context and principles of this invention. Accordingly, the descriptive portion of WO/0184313 and/or US 2002/0007468 A1 is incorporated by reference in this application. Alternatively, reservation is made for the inclusion of their FIGS. 1 through 11, together with their description [i.e. paragraphs [0037] through [0174] of US 2002/0007468 A1 or the corresponding text in WO/0184313), as an additional attachment to this application.  
     [0066] The above described system may be used in a variety of applications. One of these is High Availability Platforms (HA platforms), as used in real time non stop computer networks. In the field of telecommunications, the applicant company has such a project, named Carrier-Grade High Availability Software Platform (CGHA Software Platform).  
     [0067]FIG. 1, FIG. 2, FIG. 3 and FIG. 4 here correspond to FIG. 3, FIG. 4, FIG. 6 and FIG. 9, respectively, in WO/0184313, with the same drawing labels, and will be shortly described here as an exemplary computer platform. Further details may be found in WO/0184313 and/or US 2002/0007468 A1.  
     [0068]FIG. 1 is a tree diagram depicting an exemplary physical component hierarchy (or physical containment relationships) among hardware components in a networked computer system. A network element  300  includes shelves  301  and  302 . The shelf  301  further includes non host system processors or NHSPs  303  and  307 , host system processors or HSPs  305  and  306 , and a hot swap controller HSC  304 . The components that comprise the shelf  301  may themselves contain additional components. For example, the HSC  304  includes fans  308  and power supplies  309 .  
     [0069]FIG. 2 is a tree diagram illustrating exemplary non-physical containment relationships or software component hierarchy among software components in a networked computer system. A network element  400  includes a node-1  401 , node-2  402 , and node-3  403 . Each node may contain additional components. For example, the node-i  401  includes an operating system  404 , Asynchronous Transfer Mode (“ATM”) stack  405 , ATM driver  406 , ethernet driver  407 , and management applications  408 .  
     [0070] Components may be viewed as a fundamental unit of encapsulation, deployment, and manageability. When new applications and devices are added to a networked computer system, they are typically added as new components.  
     [0071] To prevent service outages during normal operation, components may accept dynamic changes in their configuration. It is common for the configuration of network-based applications to change during normal operation. To prevent frequent outages due to these configuration changes, components may be held responsible for recognizing that their configuration has changed and taking this change into account by operating based on the new configuration.  
     [0072] As shown in FIG. 3, a component  601  might contain physical devices and their drivers  600 A, applications  600 B, diagnostic applications  600 D, applications for conducting audits  600 C, and error analysis applications  600 E.  
     [0073] By providing standard class-interfaces through which components interact with management agents and other applications, components may allow developers greater freedom in structuring and implementing components. In FIG. 3, a component manager  601  may function as an interface to a management agent (“MA”)  602  and a component role and instance manager (“CRIM”)  603 . The component  600  may also interface with a component error correlator (“CEC”)  605  and clients  604 .  
     [0074] If newly-supplied components fully support all of the interfaces associated with their class and/or sub-class, they would automatically be manageable within various management contexts.  
     [0075] In an embodiment, distributed system services (“DSS”) may be used—the DSS may include a collection of location-independent mechanisms that enable applications to interact with one another. The DSS may enable applications to interact with one another without knowing where they are running, or where the other applications with which they are communicating are running. Using the DSS, all applications may see the same messaging, event, and configuration services, independently of which node they happen to be running on. In other words, the DSS may allow applications to communicate regardless of their relative locations.  
     [0076] Application services may also interact with their clients through the DSS, allowing them to migrate from one node to another without affecting their clients. The DSS may also facilitate load-sharing and system expansion by allowing work to be distributed among multiple processor nodes.  
     [0077] As an Example, FIG. 4 is a representational diagram of one preferred embodiment of DSS. In FIG. 4, a DSS  900  provides at least seven types of services and/or mechanisms-a cluster naming service (“CNS”)  901 , cluster event service (“CES”)  902 , cluster configuration repository (“CCR”)  903 , cluster replicated checkpoints (“CRC”)  904 , reliable remote procedure calls (“RRPC”)  906 , asynchronous messages (“AM”)  905 , and reliable transport  907 .  
     [0078] The RRPC  906  may provide a mechanism for basic intra-cluster or intra-system communications. Using this mechanism, for example, a client may issue a request to any server in the system without regard to their respective locations and await a response. The RRPC  906  may be suitable for services that require positive acknowledgments for robustness, require distinct requests to be serialized, or offer an automatic retry in case of a server failure.  
     [0079] The AM  905  may also provide a mechanism for basic intra-cluster or intra-system communications. The AM  905  may require responses and may be suited for services that require minimum latency and overhead, do not require explicit acknowledgment or serialization, or can operate properly despite occasional silent failures.  
     [0080] The RRPC  906  and AM  905  may also send calls and/or messages from exactly one sender to exactly one receiver over a pre-arranged point-to-point communication channel.  
     [0081] The CNS  901  may be used to provide a cluster-wide, highly available naming service. Servers may register communication handles (and other things) under well-known names in a hierarchically structured name space provided by the CNS  901 . Clients may look up the names for services they want, and obtain communication handles (or other objects to support the exchange of services). Handles for both the RRPC  906  and AM  905  may also be registered and obtained from the CNS  901 .  
     [0082] The CES  902  may automatically distribute events from a publisher to all processes in a cluster that have subscribed to that type of the event. Using the CES  902 , a publisher may not need to establish an explicit channel with all possible subscribers. Similarly, subscribers may not need to establish an explicit channel with a publisher.  
     [0083] It has now been found of high interest to model such a platform and/or the applications which run on it, totally or partially. This invention offers various aspects of such a modeling, including a new, polyvalent, software language, which may not only be used for theoretical modeling as such, as other modeling languages do, but also is “operational”, i.e. may be accessed by software processing tools, like generators or compilers, other than user interface for edition of the model. Such an Operational Modeling Software Language is hereinafter generically noted in short “OMSL”.  
     [0084] In WO 01/44934, the applicant company has described the preparation of a software configuration, using an XML type programming language. In one of its aspects, the present patent specification now comes to propose a concept for at least partially modeling a platform and/or the application running on it. “At least partially modeling” indicates that the modeling may be restricted to what is required to maintain the platform in operation.  
     [0085] Broadly, the OMSL language being proposed may provide a single description of the interfaces, management information and deployment configuration for application software, system software and/or hardware. This description may also be used by middleware. “Middleware” here refers to various software codes (e.g. the so-called “glue code”) existing between the operating system and the application software.  
     [0086]FIG. 5 illustratively shows seven software components COMP 1  through COMP 7 , which are servers or clients (the version aspects of FIG. 5 will be considered later). Server COMP 2  provides interface I 1  which is used by both clients COMP 1  and COMP 2 . Server COMP 6  provides both interface I 2  which is used by client COMP 7 , and interface I 1 , used by COMP  1 . Client COMP 5  uses both interface I 1 , provided by server COMP 4 , and interface I 2 , provided by server COMP 6 . The case of a component being both client and server is a simple extension of the scheme.  
     [0087] The model data may be organized as shown in FIG. 6, which will be described first, to help in understanding the description of the OMSL language.  
     [0088] The Interface model MO 1  comprises sets of interface data MO 1   x  (e.g. files), representing interfaces like those of FIG. 5. The component model MO 2  comprises sets of component data MO 2   x , based on interface data MO 1   x . The software load model MO 3  comprises sets of software load data MO 3   x , defining a given arrangement of components and of their interfaces in a platform. The configuration update model MO 4  comprises sets of configuration data MO 4   x , which may be viewed as “settings” as required by the platform when a corresponding given arrangement of components is in operation. Finally, the platform update model MO 5  comprises sets of platform update data MO 5   x , each of which defines possible evolutions of the platform, with reference to a “current load” MO 5 CL (which may be viewed as separate from model MO 5 , or included in it).  
     [0089] As shown in FIG. 6, up to five models may be supported. This is exemplary only, and the invention may apply as well where only some of these models would be used, and/or some are mixed together.  
     [0090] In certain flowchart drawing boxes, the identifier of the relevant model is shown in the upper leftmost corner of the box.  
     [0091] The OMSL language may be based on eXtended Markup Language (XML), or on a similar modeling language.  
     [0092] Exhibit Eh1 shows an exemplary document type definition (DTD). As known, the DTDs are one of the current possibilities offered by XML for defining the language rules, and many tools exist to exploit them. However, alternative possibilities offered by XML, like XML schemas, may be used as well. Also, other language rule definitions may be used when using modeling languages other than XML, which may further be converted into XML, if desired. For example, UML may be converted into XML using XMI.  
     [0093] When reading the DTD, attention should be paid to the word type, which may have different meanings:  
     [0094] the type e.g. of a constant, as usual in computer software,  
     [0095] an extended meaning, where type is associated with an identifier, and refers to the nature of the entity to be represented with that name. The type identifier itself is thus a name, but that name further implies consequences as to the nature of the entity being named. In other words, a type defines some kind of specimen of an entity. Usually, a type identifier will have to follow certain rules, e.g. those related to versioning, to be described.  
     [0096] The OMSL language defined by the DTD of Exhibit Eh1 has been termed “CGHA Markup Language (CGHA-ML)”, since it intends to serve in an HA or CGHA platform. Thus, with a view to facilitate understanding, reference may be made here to the system and to its constituents with the label or prefix “CGHA”. It must be clearly understood, however, that “CGHA” or “CGHA-ML” is used here as a convenient label, and that its use does not involve any intended limitation to a CGHA platform, and/or to telecommunication applications, and/or to the exemplary embodiment of CGHA-ML being described.  
     [0097] Turning to the Document Type Definition or DTD shown in Exhibit Eh1, those skilled in the art will appreciate that such a DTD defines a set of tools for modeling various platforms, i.e. hardware and/or software systems. For those being not familiar with XML, Exhibit Eh2 recalls the main concepts of XML, and has tables describing most elements of the DTD of Exhibit Eh1 in natural language.  
     [0098] Exhibit Eh3 describes the syntax and semantics of how to construct the above models when using e.g. the exemplary DTD of Exhibit Eh1.  
     [0099] All of the above models may support versioning. In the example, the version attribute is a positive integer. Other “incrementable” definitions may be used as well, with or without letters and/or separators.  
     [0100] When in use, versioning may be implemented e.g. as follows: a file defining an entity called &lt;Entityname&gt; may be named: &lt;Entityname&gt;.xml, if the entity has no version, or &lt;Entityname&gt;. &lt;version&gt;.xml, if the entity is versioned, with &lt;version&gt; being e.g. 1, 2, 3.  
     [0101] In the exemplary Component Model, at least one ELEMENT has minVersion and maxVersion attributes. As shown in Table Eh2-1, the example shows in fact two such ELEMENTs:cgha:use, and cgha.provide, which may be used to offer two different functionalities:  
     [0102] the cgha:use element (C 2 ) may be used to declare the versions of an interface that are used by a component, considered as a client.  
     [0103] the cgha:provide element (C 5 ) may be used to declare the versions of an interface that are provided through a SAP, by a component considered as a server.  
     [0104] In each case:  
     [0105] minVersion specifies the oldest version of the interface that is used/provided, i.e. the version with the lowest version number.  
     [0106] max Version specifies the most recent version of the interface that is used/provided, i.e. the version with the highest version number. The value of this attribute must be greater than or equal to the value of the minVersion attribute (for the same entity created from use or provide).  
     [0107] It will be appreciated that a number of objects or ELEMENTs in the DTD admit a “version” attribute, which may be required or optional. This is summarized in Table Eh2-2. The fact that version is optional in certain case is an implementation choice, which may reflect the fact that certain ELEMENTS will rarely change. In fact all ELEMENTS might be versioned.  
     [0108] In the exemplary embodiment, versioning is mandatory:  
     [0109] in the interface model, for interfaces and object references, and also for event and the publish aspects, if implemented,  
     [0110] in the other models, for the components, the platform update, configuration update and software load models.  
     [0111] Each versioned “ELEMENT” may be used as an attribute in another ELEMENT, using the cgha:attribute.  
     [0112] The flow-chart of FIG. 7 shows an example of how version attribute checking ( 4500 ) may be made, when creating an entity, e.g. by a dedicated tool which may be incorporated in an OMSL compiler. The entity derives from an ELEMENT generically noted cgha:xxx, where xxx may be one of the elements of the DTD. The type identifier or entity name is “entName” ( 4502 ) Operation  4504  determines whether “entName” already exists, or not. This may use the naming tree to be described in connection with FIG. 8.  
     [0113] In the case of a new name, if version is supported by cgha:xxx ( 4510 ) and mandatory, i.e. “required” ( 4512 ), operation  4514  verifies that version 1 is created (starting at any integer version might also be allowed). If version is not supported, no version number is allowed ( 4518 ). If version is supported, but not required, anything is possible ( 4516 ).  
     [0114] In the case of an existing name, if version is not supported by cgha.xxx ( 4520 ), it is not allowed ( 4528 ), like for  4518 . If it is allowed and required ( 4522 ), a last version is sought ( 4526 ), and the entName should be supplemented ( 4526 ) with a version indication incremented by 1 (or any version number representing a non existing version, preferably a higher version). Then, at least for certain entities, compatibility between version may be checked, optionally ( 4527 ). If version is supported, but not required, operation  4524  determines whether a last version exists for entName; if so, the required path of operations  4526  and  4527  is taken, otherwise the “unversioned” operation  4528  applies.  
     [0115] At  4527 , checking compatibility between versions may be implemented, e.g. for the following CGHA-ML entities along the following exemplary rules:  
     [0116] interface:  
     [0117] Two versions of the same interface must not have an operation, an attribute or a constant with the same name and a different signature. The signature of an operation consists of the number and types of its arguments, its return type and its declared exceptions. The signature of an attribute or a constant is its type (plus its version, if implemented). Note that two attributes with the same name must have the same type. This may be verified by the OMSL compiler.  
     [0118] For a number of other entities whose versioning is optional (e.g. structure, enumeration), there may be no need to mandate any compatibility between two versions of such an entity.  
     [0119] Whatever its internal operation is, a software entity or component is known of other software entities essentially by what it exchanges with them. This may be broadly termed its “interfaces”; however, in practice, a difference is made between interfaces as such, examples of which have been discussed with reference to FIG. 5, and other software “beings”, like the exceptions and events.  
     [0120] First, by using such an OMSL, it is possible to define a collection of interfaces, attributes (in the target software platform, not XML attributes), structure members, parameters, objects or contexts. Each of these can be defined by a group of data having a type, like simple type or structure. Examples of such groups of data are:  
     [0121] a map, which is an unordered set of pairs (key, value), where the key is an arbitrary string and the value is of a base type. All values have the same base type in a given map. A map is specified by setting the map attribute to “yes”.  
     [0122] an array, which is an ordered list of elements of the same base type, indexed by integers. An array is specified by setting the array attribute to “yes”.  
     [0123] The interface model makes it possible to describe sophisticated parameters, as they exist in the interactions of components within a computer platform, and thus to define models of that platform. The models may be represented by OSML files, which are XML files in the example. Other representations may be used as well, e.g. the LDAP representation to be described. Thus, OMSL files (files in the OSML language) may be constructed by platform architects, and stored in a repository (hereinafter called OSML or XML repository).  
     [0124] Except where versioning and update level applies, two different items should have different names (or identifiers). To facilitate this, the repository may be organized as a hierarchical tree, which reflects the structure of the OMSL package hierarchy, also in connection with the naming of OMSL packages, if desired.  
     [0125] An exemplary organization of the OMSL Repository on a customer platform will now be described with reference to FIG. 8. (Note the OMSL is CGHA-ML in the drawings.)  
     [0126] After a main “root” node N 0 , there are three sub-trees with their roots in N 10 , N 20  and N 30 . Then:  
     [0127] the subtree stemming from nexus N 110  (com/sun) may be arranged with a sub-nexus N 1100  (cgha) forming a path to contain predefined OMSL files describing types (interface model) and components (component model). It may be arranged with sub-nexus to distinguish standard OSML Software Platform types (N 1101 ) and internal system components (N 1102  and N 1103 ). This may be called the “system repository tree”.  
     [0128] the tree stemming from root N 120  (con/telco) contains customer-specific OMSL files describing the customer platform and applications (“telco” is used here as a generic name for a customer organization). Its nexus N 1201 , N 1202  and N 1203  may follow an organization similar to those of the system repository tree (N 1101 , N 1102  and N 1103 ). However, other organizations may be chosen as well. For example, the customer-specific portion of the repository could be named fr/telco, or it could be located elsewhere in the file system.  
     [0129] the tree with root N 20  (updates in the example) may contain OMSL files describing successive platform updates of the customer application. These files follow the software load model, the configuration update model or the platform update model.  
     [0130] finally, root N 30  (cghaml.dtd) contains the unmodifiable file or files which define the OMSL syntax, e.g. the Document Type Definition or DTD.  
     [0131] In the exemplary system Repository tree (com/sun sub-tree), only final directories, e.g. N 1101 , contain actual OMSL files (leaves of the tree). The directory N 110  contains standard types and system components:  
     [0132] directory N 1101  contains common interfaces and standard types used in the Software Platform. These “leaf” files follow the OMSL interface model. Subdirectories of N 1101  may be used to receive files describing types specific to system components, for example ccm (N 11031 ), cec (N 11032 ), and crim (N 11033 ).  
     [0133] directory N 1102  contains files defining hardware components. All files related to a hardware component may be located in a subdirectory, which contains the definition of the component as well as optional, specific component types and interfaces. For example, the following hardware component subdirectories may be defined: netrat1 (N 11021 ), networkelement (N 11022 ), shelf (N 11023 ).  
     [0134] The platform software N 1103  directory contains files defining system components of the Software Platform. All files related to a system component may be located in a corresponding subdirectory. This subdirectory contains a file defining the component (component model). It may also contain files defining types and interfaces specific to the component, using the interface type model. For example, the following system components may be defined: bootserver, ccm, cec, ces, cet, chm, cls, cmm, crcs, crim, csum, ma, oscm, slim, sltm.  
     [0135] Turning now to FIG. 9, a repository  2010  contains the model files, which may comprise the DTD  2011 , predefined files  2012 , and custom files  2013 . The custom files may be prepared using an XML editor  2020 , with a user interface  2021 , e.g. the “XML mode” of the GNU “emacs” editor of the GNU.  
     [0136] The rest of FIG. 9, i.e. the frame in dashed line  2030 , may be called OMSL compiler, or, in short, compiler. It may include XML language editing tools, which may use a catalog file, e.g. an XML parser  2031 , with a semantic analyzer  2032  (and, optionally, a syntactic analyzer, not shown). Then, one or more generators  2034  may be used to build files  2035  in other languages and/or formats. Three different languages lang.1, lang.2 and lang.3 are shown, by way of illustration only. In practice, the languages may range from Java and C/RPC to LDAP, HTML, while using corresponding mappings as necessary. Generators  2034  may also be used for other purposes, e.g. with the software load mapping.  
     [0137] Reference is now made to FIG. 10, which shows a system embodying several other inventive aspects.  
     [0138] The repository  1510  may comprise various software packages (XML files and package files), amongst the following: platform update, configuration update, software load, applications, middleware, Operating system, hardware, and types. These may be checked at  2300 , e.g. as described with reference to FIG. 9. At  2320 , software factory tools may be used to build:  
     [0139] component framework code  2340 , which may comprise e.g. client stubs, service skeleton code, and management skeletons code, for example in C or C++;  
     [0140] one or more software load images  1570 ,  
     [0141] LDAP data  2400 , e.g. for use when the target system will internally need information about its own status and constitution, e.g. at runtime, and  
     [0142] a Management agent framework  2500 , e.g. using Mbeans, and the applicant company&#39;s JDMK, i.e. java.  
     [0143] The models of FIG. 6 will now be reviewed in more detail, with reference to the corresponding sections of the exemplary CGHA-ML in Exhibit Eh3, and to the example of FIG. 8.  
     [0144] The interface model MO 1  (Eh3.2) basically describes interfaces, and may also involve e.g. events, and/or exceptions. A given set of modeled interfaces will comprise the the interfaces that may exist in (be provided or used by) components of the platform, or a given part of it. Each interface defines the services that will be provided by, or supplied to, a component (subject to the capability of the component to have that interface).  
     [0145] The interface model MO 1  (used e.g. in N 1101 ) may basically support the specification of Interfaces. It may also support Events.  
     [0146] In the embodiment, other auxiliary entities are also put in the interface model MO 1  Exceptions, Structures, Object references, References, Enumerations.  
     [0147] Certain items of MO 1  may have attributes, e.g. configuration attributes, for which the given set of modeled interfaces may define default values.  
     [0148] Typically, a file might contain one interface, together with the related exceptions and the structures necessary to define this interface. They may be grouped semantically, so that, for example, everything related to one call mechanism will be grouped in one file. However, various interface items may be mixed in the same file.  
     [0149] The interface model MO 1  comprises the same level of functionality as CORBA IDL or Java RMI, with support for inheritance and exceptions. It has new features to cope with versioning, synchronous/asynchronous mode of communication and configuration.  
     [0150] Now, the component model MO 2  (Eh3.3) represents components, using the above mentioned interface items. A component may be represented by a “component type”, together with the interfaces it provides and the interfaces it uses.  
     [0151] The representation of components may use a tree structure, e.g. a hierarchical naming tree where each leaf is an object that implements an interface type. Furthermore, one may associate an object with each node of the naming tree. This is termed a Management Information Base, or MIB.  
     [0152] A dedicated MIB may handle the configuration associated with the component type (e.g. a network element or cluster). A MIB is associated to its container, which may be e.g. a SAP (Service Access Point), a component type, or a cluster. In the MIB, it is possible to override the default value of the configuration, coming from the interface model.  
     [0153] SAPs are used to specify particular aspects of a component, for example management, high availability or service. Each SAP provides a set of interfaces and an optional MIB.  
     [0154] A given set MO 2   x  of modeled components may have the form of component model files, which may be located in the directories stemming from N 1102 , N 1103 , N 1202 , N 1203 . In a simple embodiment, an XML file may contain only one component.  
     [0155] In more general terms, the component model defines component types which may be used on a cluster (whether hardware or software). In the case of software, component instances define the component types which are presently available; component assignments define if and how the component instances are assigned roles dynamically in the Software Platform (this may be also applied to controllable aspects of hardware).  
     [0156] In the example, the versioning follows simple basic rules:  
     [0157] a given entity myEntity created from use (client) or provide (server) must have two version values for its minVersion and maxVersion attributes, respectively;  
     [0158] it is not entitled to offer an interface (or other versioned item) whose version value is denoted &lt;version&gt; unless two conditions are met:  
     [0159] &lt;version&gt; is equal to or greater than the min Version value of myEntity  
     [0160] &lt;version&gt; is equal to or lower than the max Version value of myEntity  
     [0161] If desired, the accuracy of the [minVersion, maxVersion] intervals of the use and provide OMSL elements may be checked, e.g. as shown in the flow chart of FIG. 11. For each component Ci in the component model ( 5010 ), operation  5012  gets the interfaces used by Ci, and, for each such interface gets the [minVersion, maxVersion] interval WUi for use. Operation  5014  checks that the Interface model indeed has an interface for each version within interval Wui. Operation  5018  indicates that the same is done with [minVersion, maxVersion] interval WPi for provide.  
     [0162] Other mechanisms may be constructed, using the version, on the one hand, and the [minVersion, maxVersion] interval, on another hand, based on similar principles.  
     [0163] The software load model MO 3  (Eh3.4) specifies the software loads that are deployed on a given portion of the software platform, for example a Network Element, hereinafter termed a cluster by way of simplification. A software load represents a set of components (software and hardware). Along the exemplary embodiment, multiple versions of the same component are not allowed in a given software load (this would induce a more complicated processing).  
     [0164] In a given software load:  
     [0165] Each component is represented by:  
     [0166] its definition in the OMSL model, in the example a component type configuration MIB, an instance MIB, and an assignment MIB,  
     [0167] a list of software packages, and  
     [0168] a descriptor of its target localization.  
     [0169] The configuration associated with the Network Element or cluster (hosting the components) is handled through a dedicated MIB, called cluster configuration MIB.  
     [0170] The flow chart of FIG. 12 shows how version consistency may be checked, e.g. within a given software load MO 3   x . Starting from a list of coexisting components ( 5000 ) in the software load MO 3   x , the component model is used ( 5002 ) to build groups each of which may be viewed as a client component Ci using Interface Ik provided by a server component Cj. Operation  5004  gets the [minVersion, maxVersion] interval Wi of Ci for Ik as “use”, and the [minVersion, maxVersion] interval Wj of Cj for Ik as “provide”. The components can cooperate if the intersection of Wi and Wj is not nil, as checked by operation  5008 .  
     [0171] A software load defines ingredients of a software platform. A given condition of the settings in a software platform is termed a “configuration”. The interface model MO 1  and the component model MO 2  define two levels of default configuration settings. However, further settings may be made at the time the software load occurs.  
     [0172] Thus, the configuration update model MO 4  (Eh3.5) defines the configuration of a given software load (“configuration load”), and any modifications being made to that configuration. When initially loaded, a configuration is initialized, and then it may be updated.  
     [0173] Each configuration load may be seen as applying to a specific software load. A given configuration load specifies the configuration of all the components of the software load it aims at. Configuration values are applied in terms of type, instance and assignment, and also the configuration of the Network Element, including deployment descriptors, redundancy schema and component relationships (to the extent applicable).  
     [0174] The configuration load section of the configuration update model allows the initialization of a n-uplet of items, which, in the example, is a quadruplet: a cluster configuration, a component type configuration, a component instance configuration and a component assignment configuration. This implies that each component instance and component assignment should be named in a unique fashion, in the above described naming tree.  
     [0175] The Configuration update model basically gives values to variables (in the broadest meaning of the word variable); this has the form Vi=Xi, for a given version, as shown in operation  5030  of FIG. 13. The Software load model is then accessed to know the component Ci being concerned by variable Vi ( 5032 ). The component model in turn indicates which MIB is concerned, and hence, which interface Ii is concerned ( 5034 ). And the interface model indicates the type of variable Vi ( 5036 ). An error is generated ( 5038 ) if any of the above level failed. A different error is generated ( 5040 ) if Variable Vi was found final in any of these levels (except  5030 ). Finally, Vi=Xi is accepted if the type of Vi, as found in the interface model, matches the type of Xi, as defined at  5030 .  
     [0176]FIG. 14 is a “file-oriented” form of the flowchart of FIG. 13.  
     [0177] The platform update model MO 5  (Eh3.6) provides the specification of a platform update. A platform update may be processed by the software factory tools as shown in FIG. 15. It may comprise ( 5050 ) a “current load”, which corresponds to the software load that is currently deployed on the Network Element, and its associated configuration. It may also comprise a list of configuration updates (from zero to N in number), and, optionally, a new software load, if any, that may be loaded on the Network Element in substitution of the current load and the associated configuration.  
     [0178] The simplest role of the platform update model MO 5  is to change the configuration. First, all files involved in the update (and including configuration statements, in the form Vi=Xi) are compared ( 5052 ) with the corresponding files in the current load. If they are compatible ( 5054 , to be developed), the generation of a new current load is allowed ( 5056 ). The new current load may be obtained by simply applying the configuration values being modified, as they were found at operation  5052 . The other configuration values are kept. Then, updated configuration data are generated ( 5058 ).  
     [0179]FIG. 16 shows an exemplary way of checking the compatibility of an update set MO 5   x  at operation  5054 . Operation  50541  builds the list of MIBs (MIBk) being involved in the update (the current load is assumed to have been checked previously in a similar fashion, and to be correct). Operation  50543  accesses the files comprising those MIBs and the corresponding components. Operation  50545  builds the list of all variables to be configured for these. Operation  50547  checks that all these variables are effectively given configuration values in the intended update (or in the current load).  
     [0180] Thus, a Platform Update Model may provide support:  
     [0181] for controlled and deterministic configuration updates to the current software load running on the Network Element.  
     [0182] for upgrading the software running on the Network Element from one release to a different release.  
     [0183] In other words, the Platform Update Model defines the Software Load and the Configuration Updates that are applied on a Network Element. In a configuration quadruplet (cluster, type, instance and assignment), each entity may have an associated update level. Thus, modification of the configuration is made possible without having to build a new Software Load.  
     [0184] The Software Factory tools  2030  may be used for managing this notion of update level. The update level is incremented (or otherwise differentiated) after the update has been checked and authorized. The resulting configuration information may thereafter be provided to each running component instance being “re-configured”.  
     [0185] Let entity be an item in the above mentioned quadruplet: cluster configuration, component type configuration, component instance configuration and component assignment configuration. The configuration of such an item of a component is defined by:  
     [0186] its name &lt;entityName&gt; 
     [0187] its version, e.g. 2, and  
     [0188] its update level, e.g. 3.  
     [0189] The version is known at compilation time. The name is defined when the component entity is created. Conversely, such an entity may be informed that its configuration has changed in an asynchronous fashion by an event, which may indicate the most recent update level. In response, the entity will change its configuration, e.g. by re-booting, which forces it to re-acquire its configuration data; “softer” reconfiguration processes may also be applied, subject to adequately determining the status of the relevant portion of the platform.  
     [0190] To check the consistency of a software load and/or a configuration update in respect of what has been deployed on a Network Element, and to generate the appropriate update levels, the Platform Update Model supports the definition of the current load.  
     [0191] A current load defines the components that have been deployed on a Network Element, defining for each component its type, its version, its instances and its assignments with the associated update levels and configuration. For the cluster, the current load defines its version, its update level and its configuration.  
     [0192] The Software Factory tools generate for each Platform Update the resulting state of the Network Element, using the cgha:currentLoad element. This resulting state should be used as the current load in order to define the next platform update of the Network Element.  
     [0193] Files containing a software load, a configuration update and/or a platform update may be located in an updates subtree (N 20 ). Each file should contain only one definition, named &lt;definitionname&gt;, which can be a software load, a platform update or a configuration update.  
     [0194] Now, rules and guidelines may be established to govern how a platform and its components will be defined in the OMSL language. This concerns both the organization of the files and their actual content. The rules and guidelines may have the following aspects:  
     [0195] the organization of the repository  1520  and the rules to be enforced when naming the software and/or hardware entities.  
     [0196] the rules that must be followed when defining a component.  
     [0197] Further rules that should be followed when defining a cluster may be added, to correctly feature the hardware, and its redundancy features.  
     [0198] OMSL models may be used as such, when conceiving an application (part or all of a system). They may also be mapped to programming languages, e.g. C or Java. This allows to link an application to other components and to the Software Platform, and/or to provide remote manageability of the platform.  
     [0199] Tables Eh6-1, Eh6-2 and Eh6-3 in Exhibit Eh6 show examples of mappings to Java, C/RPC, and LDAP, respectively. Mapping from the OMSL to Java and/or C/RPC may be considered similar to mapping from other modeling languages to Java and/or C/RPC, and therefore will not be described in further detail. By contrast, mapping to LDAP will be described in more detail hereinafter.  
     [0200] It will now be appreciated that the OMSL language has following capabilities, which, of course, may be used only partially:  
     [0201] establish a formalized description of a Software Platform (“information model”). In fact, the OMSL language may be used to model not only the applications that run on the HA Software Platform, but also the constituent entities of the platform itself (hardware, operating system and/or middleware).  
     [0202] use of various user-oriented tools, e.g. validation tools, when establishing that formalized description.  
     [0203] possibility to build a set of specifications and tools to assist developers with the design of components.  
     [0204] the formalized description in turn may be used by various “operational” tools, for example when developing components or when constructing software loads, and their configuration. This may go up to the deployment of the components and of the platform on which they run.  
     [0205] The above defined models apply within what may be called a “software load life cycle”. This concept will now be illustrated with reference to FIG. 17. The notations used in FIG. 17, e.g. to the extent they refer to an XML embodiment of this invention, are purely exemplary. In the tree hierarchy, the top level is “platform update” (N 20 , FIG. 8), which comprises a software load and a configuration.  
     [0206]FIG. 17 shows:  
     [0207] a package repository  1500 , which may store in any appropriate data format, e.g. a file system, the software code to be used in connection with a particular platform, both at the hardware level, e.g. drivers, and at the software level, e.g. application programs. Middleware may also be included, as desired.  
     [0208] an OMSL repository, e.g. an XML repository,  1520 , which may store in any appropriate data format, e.g. a file system, sets of the model data to be used, in the OMSL language.  
     [0209] Thus, a typical software load life cycle may involve:  
     [0210] the installation of one or more components  1530 ,  1531 ,  1532 , which may use both repositories  1500  and  1520 ;  
     [0211] the definition of a software load  1540 ; this may use model repository  1520  only; and produces a representation of the software load, e.g. a softwareLoad version.xml file;  
     [0212] the processing of the software load  1550  may involve a tool, named e.g. ml2swload, which uses that representation, in connection with both repositories  1500  and  1520 , to generate a corresponding list of packages  1552 , named e.g. softwareLoadversion.pkgs.  
     [0213] the final software load build  1600 , which converts the set of packages into a SoftwareLoad image  1570 . The SoftwareLoad image  1570  comprises data loadable in memory for operating a computer system, e.g.  1590 . This uses a Software Load Build Tool also denoted SLBT.  
     [0214]FIG. 17 is made in the form of interconnected blocks, for more clearly showing the interactions between its elements. It will be appreciated that it may also be viewed as a flow chart, having operations  1530  through  1570 . The separation in a plurality of levels of operations is purely illustrative. For example, operations  1550  through  1570  might be considered as a single level of operations as well.  
     [0215] The Component Definition Rules will now be considered.  
     [0216] To begin with, FIG. 18 shows how a given (hardware or software) component  2100  is seen by its surroundings. It has a variety of component-to-component interfaces I 210   x  with other components  210   x . (the x reflects the fact the other components are plural). It also has a component-to-framework interface I 2120  with the framework  2120 .  
     [0217] The framework  2120  may comprises e.g. the following runtime tools:  
     [0218] the Component Role Instance Manager (CRIM)  2121 , which defines the instances and assignments of components,  
     [0219] the Management Agent (MA)  2122 , which may be used to manage software,  
     [0220] the Component Executor and Terminator (CET)  2123 , in charge of having components being put in execution, or, on the contrary, terminated.  
     [0221] Additionally, the component may be associated (L 2130 ) with a component configuration element  2130 . Also, the framework  2120  may be associated (L 2140 ) with a cluster configuration element  2140 . The interactions L 2130  and L 2140  may be separate for each element of the framework, as shown in dashed lines.  
     [0222] In an exemplary embodiment, the items marked by an [X] in FIG. 18 may be defined using the OMSL.  
     [0223]FIG. 18 is a “model view” of a component and its surroundings. As shown, it is centered on a given component; however, a similar view may be made centered on another component as well.  
     [0224] At runtime, there corresponds to the model view of FIG. 18 a “runtime view”, e.g. as shown in FIG. 19. Component  2100  and others components  210 ×interact as shown at D 210   x  to execute their tasks. They have access to a database  2150 , containing configuration data (“configuration” is taken here in its broadest sense), via C 2100  and C 210   x . The component  2100  being considered works under control of the framework  2120 , e.g. the CRIM, MA and CET, as shown by links M 2121 , M 2122 , M 2123 . The elements of the framework  2120 , e.g. the CRIM  2121 , MA  2122  and CET  2123 , may also access the data base  2150 , as shown at C 2121 , C 2122 , C 2123 .  
     [0225] In fact, the framework  2120  will play a similar role for the other components. This is not shown on FIGS. 18 and 19, since they are centered on a given element  2100 .  
     [0226] Having thus defined how a component may be viewed, modeling a component in OMSL will now be considered.  
     [0227] Modeling may comprise defining at least one mandatory MIBs (Management Information Base) at the Component Model level, together with a corresponding SAP. (It is reminded that a MIB may be attached to a SAP, which uses the MIB to deliver information corresponding to the SAP&#39;s “mission”). By so doing, the component having such MIB and SAP follows some sort of “contract” with other components and other surrounding functions.  
     [0228] An exemplary set of MIBs and SAPs will now be described.  
     [0229] The exemplary set of MIBs is set forth in Exhibit Eh4. The SAP names, object names and corresponding object types are summarized in tables Eh5-1, Eh5-2 and Eh5-3 of Exhibit Eh5. It should be clear that these examples and the MIB/SAP names are illustrative, and should not restrict the scope of this invention.  
     [0230] The example involves three mandatory MIBs/SAPs:  
     [0231] whether it is hardware or software, a component will have a component type configuration MIB, to give the framework access to the configuration data of the component.  
     [0232] a software component additionally has a component instance MIB, and a component assignment MIB. Roughly, the instance is how the software component exists; assignment is the role it is currently playing. This distinction between instance and assignment (or role) is of interest in redundant systems. In other systems, a single MIB could be used for both instance and assignment.  
     [0233] Generally, each of these MIBs comprises a well-defined collection of objects, as required for correct platform operation. The fact these MIBs are defined correctly may be checked by the user who models a component and/or by the compiler  2030 .  
     [0234] The objects in the MIBs may be used by the platform services (e.g. items of framework  2120 ) to orchestrate platform behavior correctly. Concerning the names of the mandatory SAPs, of the mandatory objects defined by the MIBs, and the corresponding types of the mandatory objects, those should be predefined by the platform architect, and not be changed thereafter. Now, there may be provided application-specific values to object attributes.  
     [0235] The Component Type Configuration MIB is a collection of software objects which describe the configuration of a component type  
     [0236] Predefined interfaces types may be defined. In the example:  
     [0237] a generic ComponentDescriptor interface, which has three attributes, as shown in table Eh5-4 in Exhibit Eh5. The OMSL description of the attributes of the Component Descriptor interface type may be as shown in Eh4-1.I has two children:  
     [0238] a SoftwareComponentDescriptor, used for software components (Eh4-10); it has two additional attributes: creationDescriptor,deploymentDescriptor, which may be used to describe the component type configuration as required by the CET.  
     [0239] a HardwareComponentDescriptor, used for hardware components (Eh4-11), which is empty, i.e. defines no additional attributes.  
     [0240] One object must be included in the component type configuration MIB. It is a simple object with the name componentDescriptor. The componentDescriptor object implements one the above children of the ComponentDescriptor interface, depending upon it is a hardware of software component. The generic ComponentDescriptor interface type defines the component type configuration required by the framework services  2120 .  
     [0241] For both hardware and software components, the componentDescriptor object describes component type configuration data, e.g. the component category and redundancy model required by the CRIM. It also describes component packaging. For a software component, it additionally describes configuration data, e.g. those needed by the CET to start up and deploy a component. The user needs to define his own attribute values for the componentDescriptor object.  
     [0242] Thus, the componentDescriptor object defined by the Component Type Configuration MIB (N 11011 ) gives the framework ( 2120 ) access to values for the configuration object attributes. For example, some configuration data is needed by the CRIM, such as the availability model of the component. The MIB (N 11011 ) may be extended to hold other objects specific to an application.  
     [0243] Type configuration may be required for each component by the framework entities exploiting the OMSL language, as it will now be described.  
     [0244] In the example, the Component Role and Assignment Manager (CRIM or  2121 ) requires the following component type configuration:  
     [0245] a component category, defined by the componentCategory attribute (Eh4-2),  
     [0246] a redundancy model, defined by the availabilityDescriptor attribute (Eh4-3)  
     [0247] a switchover escalation (see Eh4-4), which consists of count and time window, and tells the CRIM that if the component has been restarted “count times” during the past “time window” period (in seconds), and the component still experiences errors, then the unsuccessful restart recovery should be escalated to the node switchover. The switchover escalation count and switchover escalation time window are defined by the availabilityDescriptor attribute.  
     [0248] a time out (in seconds) for a component to respond to CRIM requests. This is defined by the availabilityDescriptor attribute.  
     [0249] a restartable attribute, a boolean indicating whether the associated component type is restartable and can be recovered from some types of errors by restarting.  
     [0250] In the example, the component type configuration required by the CET (Component Executor and Terminator is provided by the creationDescriptor attribute, and specifies (Eh4-5):  
     [0251] The creation time out of the component. This is the time out value for the component to respond back with initialization completed after the CET has started up the component.  
     [0252] The binarypath of the component, required to start up the component.  
     [0253] The termination time out of a component. This is the time out value for the CET to receive a component termination acknowledgment, after the CET has requested the component to terminate.  
     [0254] The user id and the group id of the component. This is needed by the CET when starting up the component.  
     [0255] A Software Load Build Tool or SLBT may be used. The SLBT requires information regarding the component packages and the target platform and OS. A tool (identified as ml2swload, in the example) may provide this information for the SLBT, using the following component type configuration as input (Eh4-6):  
     [0256] The packaging descriptor, which describes component packages. The platform, OS, and package type (documentation, runtime or development) are described for each package that has a package name.  
     [0257] The deployment descriptor, which describes the target platform and OS on which to deploy a component.  
     [0258] The example in Eh4- 20  shows how the component type configuration MIB may be used when developing a component. The predefined object name (e.g. componentDescriptor) and its corresponding type should be respected; its attribute values may be changed to be specific to a given application.  
     [0259] This example will be described in more detail, with reference to the operations in the flowchart of FIG. 20, and to the sub-sections in the code of example Eh4-20:  
     [0260] operation  4002  (Eh4-20A) imports the relevant package for the types (version 1) of a SoftwareComponentDescriptor, and then defines the name of the component type (here “SoftwareComponentExample”), its version, type and description.  
     [0261] in the MIB, operation  4004  (Eh4-20B) declares the object componentDescriptor, with its type as defined above. Then, one may initialize the desired attribute values for the componentDescriptor object, setting the values according to the platform application to be represented by the MIB.  
     [0262] operation  4006  (Eh4-20C) initializes the componentCategory attribute.  
     [0263] operation  4008  (Eh4-20D) initializes the availabilityDescriptor attribute, a structure having various members.  
     [0264] operation  40010  (Eh4-20E) initializes the creationDescriptor attribute, another structure.  
     [0265] operation  40012  (Eh4-20F) initializes the packagingDescriptor attribute, an array of structures, the contents of which will be understood bty those skilled in the art.  
     [0266] operation  40022  refers to the deploymentDescriptor attribute, another array of structures, which is initialized later, at the software load.  
     [0267] The instanceManagement SAP gives remote clients access to the corresponding mandatory MIB associated with the component instance. This MIB consists of a collection of objects whose role is to provide necessary information associated with a component instance. One can extend the MIB with objects specific to a given application, while respecting the mandatory objects, as shown in example Eh4-21.  
     [0268] A distinct assignmentManagement SAP may be used to give remote clients access to the component assignment MIB. This information may be used by the HA management services, such as the CRIM. One can extend the MIB with other objects specific to an application. The interface type defines attributes related to the assignment management, for example, the usage state.  
     [0269] The OMSL definition of that interface may be as shown in Eh4-30. There is one mandatory object in the component assignment MIB. As the interface is a singleton, the object does not have a name. This object and its related type must be respected so that the platform can function correctly. The object may provide the usage state of a component, which may be idle, or, by contrast actively in use at a specific instant, and if so, whether it has (active) or not (busy) spare capacity for additional users at that instant. The usage state may be reported by the component itself.  
     [0270] This state influences the decision-making aspect of platform behavior, and is required by the HA management services, in particular the CGHA availability services, so that a platform will run correctly. The component gives access to the usage state, which is that of its assignment. A component instance can have only one assignment during its primary role. An example of how to use the assignmentManagement SAP appears at Eh4-31  
     [0271] To sum up, a configuration, when defined by an OMSL like CGHA-ML, may be organized as a set of MIBs, specified using the cgha:mib element. A MIB is a hierarchical tree of objects and contexts, defined using the cgha:object and cgha:context elements. In fact, the OMSL language may be used to define three categories of MIB:  
     [0272] MIBs associated with a specific SAP. This category of MIB is contained within the cgha:sap element. SAP level MIBs are fully initialized during component instance definition or component assignment definition. Component instances and assignments are defined using the cgha:instanceConfiguration element and the cgha:assignmentConfiguration element respectively.  
     [0273] MIBs associated with a specific component type configuration. This category of MIB is contained within the cgha:type element. Component type configuration MIBs are initialized during component load definition, using the c gha:componentLoad element, or during component type configuration, using the cgha:typeConfiguration element.  
     [0274] A MIB associated with the cluster configuration. This MIB is contained within the cgha:cluster element. The cluster configuration MIB is initialized during cluster configuration, using the cgha:clusterConfiguration element.  
     [0275] The Software Load Model is another aspect of this invention.  
     [0276] The purpose of the Software Load Model is to define a set of components to deploy on a network element or cluster. This set of components is known as a software load. Thus, the output of the software load will be a list of packages (e.g. Solaris packages) defining the component part of this software load. The OS (e.g. Solaris) packages are contained in a repository and are therefore referred to by their name.  
     [0277] The exemplary software load model defines three elements:  
     [0278] cgha:softwareLoad, which is mapped to the package list file. The cgha:softwareLoad element is the top element defining a software load and identifies the software load.  
     [0279] cgha:cluster, which is not mapped to the package list file. The cgha:cluster element is used to define the cluster on which the software load will be deployed.  
     [0280] cgha:componentLoad, which is mapped to the package list file. A cgha:componentLoad element defines a component which is part of the software load. The cgha:componentLoad element first generates comments lines in the package list file identifying the component to be added. For a specific component, if no package names can be found, or if only package names common to all platforms and OS are found, a warning message is displayed to the user. The package list is verified to ensure that each package appears once and only once.  
     [0281] A standard ComponentDescriptor interface may be used for:  
     [0282] defining whether the package is specific to one platform and one OS, or common to every platform and every OS (intermediate situations may be covered). When writing the Component Model, the user specifies which package will be on which platform and OS. The targeted platform and OS are defined by their names (for example, sparc and solaris), or the word “common” can be used to point to all platforms and/or OS. Different types of packages may be used, e.g. RUNTIME, DEVELOPMENT or DOCUMENTATION.  
     [0283] defining the platform and OS on which a component will be deployed (these are also known when writing the Software Load Model). This information may be stored in a ComponentDescriptor standard interface, using the initialization clause of the cgha:componentLoad element.  
     [0284] When compiling the Software Load Model, the compiler will look for the ComponentDescriptor standard interface to retrieve information regarding the platform and the OS on which the Software Load will be deployed. With this information, package names will be found. Finally, only package names with RUNTIME type are retained.  
     [0285] AsoftwareLoad Description file maybe used to describe a software load in OMSL, in the following way:  
     [0286] It first shows the description element, then a list of imports needed to use components and interfaces already defined.  
     [0287] It then defines a cluster. Since this definition is not part of the OMSL to Software Load mapping, it is not considered here.  
     [0288] Finally, each component part of this software load is enumerated.  
     [0289] For some components, the platform and OS are initialized (for example the CRIM component).  
     [0290] The Component Descriptor will now be considered. By looking at the Component Model for every component included in the software load previously defined, it is possible to see which package names will be output. For example:  
     [0291] in a BootServer Component, no package names are declared, the structure PackagingDescriptor is not initialized. No package names will appear in the package list.  
     [0292] a CEC component defines package names for every platform and OS, but the platform and OS are not initialized in the software load. Thus, no package names appear in the package list.  
     [0293] there may be package names defined specifically for each platform and each OS, plus some package names that are common to every platform and OS. The software load does not initialize the platform and the OS, but the common package names are output.  
     [0294] turning to the CRIM Component, there may be package names defined specifically for each platform and each OS, plus some package names that are common to every platform and OS. In this example, the software load initializes platform and OS to Sparc and Solaris.  
     [0295] The platform update model is now considered again.  
     [0296] Reference is now made to FIG. 21, which shows how an OMSL language facilitates a platform update operation. In this example, a HA-cluster HACx is considered.  
     [0297] Before the update, cluster HACx is in a previous state st-ante, with a Current Load 1 (denoted cl-ante), comprising software load image swl_ante, and configuration update cnf-ante. This is reflected in the currentLoad.1.xml file or package in the OMSL language, e.g. CGHA-ML.  
     [0298] The update itself is defined in the platform Update. 2.xml file or package. In the example, it comprises softwareLoad.2.xml and configurationUpdate.2.xml.  
     [0299] From these files, the status st-post after the update may be:  
     [0300] defined, by currentLoad.2.xml file or package in the OMSL language, and  
     [0301] prepared to have Current Load 2, denoted cl-post, comprising software load image swl_post, and configuration update cnf-post, which may be loaded into cluster HACx.  
     [0302] As shown in FIG. 22, a platform update may be entirely defined from an XML package PLTF_UPDT, stored in repository  1520 , generically named platformUpdate.&lt;version&gt;.xml, and comprising:  
     [0303] a currentLoad.&lt;version&gt;.xml ( 2820 ),  
     [0304] a softwareLoad &lt;version&gt;.xml ( 2840 ),  
     [0305] one or more configurationUpdate.&lt;version&gt;.xml.( 2860 )  
     [0306] Furthermore, the XML data may be used by a tool (denoted ml2config in the example), to produce a platformUpdate.&lt;version&gt;.next.xml (“next” here means “next current”) at  2840 .  
     [0307] The tree structure used with OMSL may be conveniently represented in a directory system like LDAP. Thus, FIG. 22 additionally shows LDAP data, e.g.:  
     [0308] platform Update.&lt;version&gt;.populate.ldif at  2842   
     [0309] platform Update.&lt;version&gt;.apply.ldif at  2844   
     [0310] platform Update.&lt;version&gt;.rollback.ldif at  2846   
     [0311] platform Update.&lt;version&gt;.remove.ldif at  2848   
     [0312] The LDAP data may be stored at  2400  in FIG. 10, as another representation of the OSML tree, which may be readily accessed at runtime. The aspects of mapping from OMSL to a directory system like LDAP will be described hereinafter. For the time being, the parallel OMSL and LDAP trees are considered commonly as an “OMSL/LDAP tree”.  
     [0313] A platform update process may have different forms:  
     [0314] i) it may update just the configuration associated with a MIB. Such an update of the configuration alone is reflected by incrementing the update level of the MIB.  
     [0315] Ii) it may update both the structure and the configuration associated with a MIB. An update of both structure and configuration is reflected by incrementing the version of the MIB container (cluster or component).  
     [0316] It should be noted that the version and update level are also part of the OMSL/LDAP naming tree.  
     [0317] If the MIB has been updated, then during the platform update process, there are simultaneously two different MIB configurations, with two corresponding sub-trees in OMSL/LDAP, respectively. One corresponds to the MIB configuration before starting the update process, (st_ante in FIG. 21) and the other corresponds to the MIB configuration after the update process (st_post in FIG. 21).  
     [0318] The platform update table may be a part  28422  of item  2842  in FIG. 22, together with the LDAP MIBs  28420 .  
     [0319] To have access to its configuration, a component must know the update level corresponding to each MIB. When a component is running, the update level can change. A uniform mechanism is available to access MIB configuration at runtime, using the platform update table. This platform update table provides a mapping between a MIB container name and the associated configuration tree. The table contains the identifiers (e.g. LDAP Distinguished Names or DNs) of all the MIBs that are defined. A new platform update table is generated for each new platform update. The platform update table is accessed indirectly by means of the version of the software load. Each software load contains the DN of the appropriate version of the platform update table.  
     [0320] To summarize, the Platform Update mechanism is organized in the following way:  
     [0321] Each MIB is fully defined by its container (cluster, component type, SAP), the version of the cluster or the component type and its update level.  
     [0322] A platform update table, containing the identifiers (e.g. LDAP DNs) of all the MIBs defined, is provided for each platform update version.  
     [0323] The identifier (e.g. DN) of the appropriate platform update table is provided for each software load version.  
     [0324] The OMSL/LDAP trees are used in FIGS. 23 through 27, in which the LDAP information is diagrammatically shown.  
     [0325]FIG. 23 considers the configuration of a component, here a cluster CLS 1 , which has an instance “i” and an assignment interface “a”. In FIG. 23:  
     [0326] a component type configuration MIB  3000  reflects the type of the component in the OMSL (e.g. CGHA-ML), and is mapped into a corresponding LDAP sub-tree “CLS 1 , 1 ”.  
     [0327] a component instance MIB  3002  has access to the MIB  3000  (as defining the LDAP sub-tree CLS 1 , 1  which corresponds to the “internal” type of the component). It defines the “instance” of the component using a “SAP name”. This is reflected both internally in the component at  3012 , which is shown as an interface, and is mapped in a corresponding LDAP sub-tree “cls,instance 1 , 1 ”. Other components, and management functions, may thus be aware of what component CLS 1  can do.  
     [0328] a component assignment MIB  3004  has access to the MIB  3002  (as defining what the component can do). It defines the “assignment” of the component using a “SAP name”. This is reflected both internally in the component at  3014 , which is shown as another interface, and is mapped in a corresponding LDAP sub-tree “cls,assignment 1 , 1 ”. Other components, and management functions, may thus be aware of what component CLS 1  actually does.  
     [0329] Thus, a software update may take place as shown in FIG. 24 (The MIBs are not shown, for more clarity in the drawing). New “values” (in fact complete sets of data), suffixed  2 , 1  have been loaded in the repositories and mapped to LDAP. The component CLS 1  initially working under “1,1” is rebooted, and then works as “2,1”. (In fact, as shown, this may also occur when only a node of the cluster is rebooted). Of course, the new values “2,1” need not be entirely different from the old ones “1,1”. In certain cases, they may even remain identical (reboot without change).  
     [0330]FIG. 25 shows a configuration update, made in response to a configuration update event (for example a “sleeping” node should be substituted to a failing node). The situation is similar to that of FIG. 24, except that there is no reboot, and the “cls,instance  1 , 1 ” and the corresponding instance MIB (not shown) is not modified.  
     [0331]FIG. 26 shows again the component CLS 1  of FIG. 23, with its interfaces  3012  (instance) and  3014  (assignment), now under control of management functions  3022  and  3024 . Interface  3016  “exposes” the services offered by the component to other components. Interface  3018  enables the “callback”, used e.g. for connection with the platform services.  
     [0332] Redundancy may be managed as illustrated in FIG. 27. Two “equivalent” components CLS 1 A and CLS 1 B are shown, with the same interfaces as in FIG. 26, suffixed with “A” or “B”. LDAP data  3400  have distinct sub-trees for the instances  3012 A and  3012 B, however the same sub-tree for the assignments  3014 A and  3014 B.  
     [0333] A management agent  3500  accesses interfaces  3012 A,  3012 B and  3014 A, and builds e.g. corresponding Mbeans, assuming the applicant company&#39;s JDMK is being used.  
     [0334] Thus, by having the management agent  3500  accessing the LDAP data, the software management may be conducted with knowledge of what the component CLS 1 A in service can do, and actually does, and of what the “sleeping” component CLS 1 B can do. The management agent  3500 , e.g. via the Mbeans, controls the management interfaces  3012 A,  3012 B and  3014 A accordingly.  
     [0335] While the OMSL language may form a basis for organizing named objects and configuration data, a directory system may be conveniently used to make such objects and data available at runtime. This has been shown in FIGS. 22 through 27, with the directory system being an LDAP directory server in these examples.  
     [0336] This may make use of a mapping from an OMSL to a directory system like LDAP (Lightweight Directory Access Protocol). Such a mapping is now considered. The language being used on the directory system side is hereinafter generically termed Directory System Software Language, or, in short, DSSL.  
     [0337] In this OMSL-to-DSSL mapping section of this specification, reference will be made to LDAP examples as follows:  
     [0338] Exhibit Eh7 shows exemplary LDAP configuration objects,  
     [0339] Exhibit Eh8 contains illustrative tables,  
     [0340] Exhibit Eh9 contains an exemplary LDAP object, i.e. a component type configuration MIB.  
     [0341] In the examples, the directory system is based on LDAP, and the DSSL uses the LDAP Data Interchange Format (LDIF) syntax. The LDIF format is a standard way of representing directory data in a textual format. However, the LDIF format is exemplary only, and other DSSL notations may be used as well.  
     [0342] The diagram Eh7-0 in Exhibit Eh7 shows an exemplary LDAP layout. A corresponding LDAP Schema may adopt the overall organization reflected in the LDAP layout being shown. In accordance with another aspect of this invention, at least some of the layout items have a “version” qualifier or entry. In the example, every layout item has a “version” qualifier or entry.  
     [0343] In accordance with still another aspect of this invention, at least some of the layout items have an “update level” qualifier or entry. In the example, an “update level” is defined for the cluster, types, instances and assignments.  
     [0344] It should also be kept in mind that the LDIF format is “reversed” with respect to the “directory-like” description of a tree structure. For example:  
                                                      the LDIF notation   leaf_node, nexus2, nexus1, root           corresponds to           the directory-like notation   root\nexus1\nexus2\leaf_node                      
 
     [0345] Accordingly, when converting the exemplary LDAP layout (shown in the diagram Eh7-0 in Exhibit Eh7) into in a corresponding tree structure, the respective levels of “update level” and “version” are reversed.  
     [0346] In other words, applying this e.g. to the examples in the diagram Eh7-0 would result into:  
     [0347] mib\update level\version\&lt;referenced object&gt;,  
     [0348] where &lt;referenced object&gt; may be:  
     [0349] cluster  
     [0350] component type\type  
     [0351] sap\component instance\instance  
     [0352] sap\component assignment\assignment  
     [0353] The RDN of the referenced object will be primarily defined, using e.g. the LDAP resources as defined below.  
     [0354] Now, it may be desirable to include in the name of the LDAP object a “version” and/or “update level” qualifier. In accordance with a further aspect of this invention, this may be made as follows:  
     [0355] each MIB is fully defined by its container (cluster, component type, SAP), the version of the cluster or the component type, and its update level;  
     [0356] for each platform update version, there is defined a corresponding platform update table, containing the DNs of all the MIBs being defined in that platform update version;  
     [0357] the DN of the accurate platform update table is provided for each software load version.  
     [0358] Now, in order to obtain the DN of a &lt;referenced object&gt; (as defined above), the relevant platform update table may be used to obtain the version and update level defining the relevant MIB configuration, and to concatenate that with the RDN previously defined for the &lt;referenced object&gt;.  
     [0359] The currently available platform update table may also be searched, e.g. upon a “system event” in the platform to know the names of the current configuration entities, and then read such configurations, as desired.  
     [0360] In an embodiment, only one set of LDAP data (or similar directory data) is available at a given time, in accordance with the current configuration of the platform, except at the time of a platform update, where a new set of LDAP configuration data is also available (e.g. mapped from a new platform update defined in OMSL). This is accompanied with a transactional processing of LDAP data, enabling “commit” if the change from the current configuration to the new one is validated, or, else, a “rollback”. Then:  
     [0361] in the case of a “commit”, the LDAP data corresponding to the previous configuration may be erased, with only the LDAP data of the new configuration remaining;  
     [0362] conversely, in the case of a “rollback”, the LDAP data corresponding to the (would-be) new configuration may be erased, with only the LDAP data of the initial current configuration remaining.  
     [0363] This makes it possible to avoid encumbering the LDAP data with an historical succession of configuration data, which may render it difficult to write new LDAP data, in an LDAP tree being progressively more and more encumbered.  
     [0364] An example of an LDAP implementation will now be described.  
     [0365] LDAP object classes may be defined, e.g. as shown in the rest of Exhibit Eh7. The object classes may comprise generic object classes, and object classes related to the above defined entities of the OSML. Amongst the exemplary generic object classes:  
     [0366] a generic object class cgha-attribute--oc (Eh7-O1) may be provided to name sub-entries corresponding to array or map attributes or to structure type attributes. This object class contains an attribute cgha-attribute-name, which is used to define the RDN of the attribute.  
     [0367] a generic object class cgha-member--oc (Eh7-O2) maybe provided in order to name sub-entries corresponding to map or array members, or members of structure type. This object class contains an attribute cgha-member-name used to define the RDN of the member.  
     [0368] a generic object class cgha-element--oc (Eh7-O3) is provided in order to name the map and array items. This object class contains an attribute cgha-key used to define the RDN of the item.  
     [0369] The syntax used in mapping OMSL attributes to LDAP may be as shown in table Eh8-T1 in Exhibit Eh8: the Directory String syntax may be used for attributes that are RDNs (Relative Distinguished Names), and may be tagged as single value; the Distinguished Name syntax may be used for attributes that contain a DN; the “IA5” String syntax may be used in the remaining cases.  
     [0370] The other object classes will be discussed hereinafter as needed. (The syntax and “value tag” of the attributes in the LDAP object classes is shown in Exhibit Eh7, and will not be commented in the following description).  
     [0371] Thus, an LDAP configuration (more generally, a set of directory system configuration data) may be generated, using such generic attributes and object classes. In the example, these generic entities may be grouped into a single LDIF file, which may be used to populate the LDAP server with directory entries during the initialization of the OMSL Software Platform.  
     [0372] In the exemplary embodiment, the directory system is used to “read” the platform configuration, from within the platform in use. Then, what has to be represented in LDAP is the platform configuration information that is described using the OMSL (e.g. CGHA-ML). Hereinafter, an OMSL entity that contains configuration information is termed “configuration-oriented” (or, in short, “configuration”). For example, a CGHA-ML attribute (cgha:attribute element) is “Configuration-oriented” if it has its configuration attribute set to yes.  
     [0373] The following section describes how “configuration-oriented”. OMSL entities may be mapped to LDAP entries. Other OMSL entities may be mapped to LDAP, if desired.  
     [0374] Generally, each entry is composed of a set of LDAP attributes, which contains the data from the OMSL object, associated with the entry. Sub-entries may also be used, as it will be understood.  
     [0375] As known, LDAP entries may be specified using an LDAP schema, which may be implemented as follows:  
     [0376] the schema of the LDAP server is reflected in an LDAP configuration tree (by contrast with a “user” tree, which contains the user data to be “read” by the platform functions);  
     [0377] the LDAP configuration tree should be updated with corresponding “schema” entries before importing the corresponding configuration of the platform as “user” entries in the LDAP server.  
     [0378] conversely, before a class can be removed from the LDAP schema, the corresponding entries should be removed.  
     [0379] Now, mapping OMSL entities (e.g. types) to LDAP involves generating LDAP attributes and object classes in the LDAP schema, and therefore defining their names.  
     [0380] The common LDAP naming schema of attributes and object classes is a single flat naming space. Thus, when mapping OMSL type identifiers to LDAP, one or more of the following rules may be used, as done in the exemplary embodiment:  
     [0381] certain characters are not allowed in the names of LDAP attributes and object classes. The period character (.) may be replaced in the mapping by the dash character (-). The underscore character (_) may be mapped by removing it and by converting the next character into an uppercase character.  
     [0382] The version of the type is taken into account when this version is provided (LDAP does not offer explicit support for versioning).  
     [0383] The string --oc is added to object class names in order to differentiate them from attribute names.  
     [0384] Each entity has an OID, which may be generated from the name of the entity, e.g. by concatenating the name of the entity in lower case with the addition of the string -oid, as currently required by LDAP servers.  
     [0385] The above will be referred to as “id-mapping rules”, whether taken together or in part.  
     [0386] The first level of mapping refers to generic constructs, which include the OMSL types.  
     [0387] By providing that the LDAP fully qualified name of a type is unique, it may be used as a basis for naming LDAP entities related to this type. Thus, the LDAP naming schema may be further extended to name LDAP attributes corresponding to attributes of interfaces, or members of structures. The resulting name may be obtained by concatenating the type name and the sub-entry name and separating them e.g. by the dash character (-).  
     [0388] Now, a OMSL attribute may be mapped in different ways: an LDAP attribute, or an LDAP entry:  
     [0389] an LDAP entry may be used if the OMSL attribute is of “plural nature” (structure type, or map or array). The LDAP entry is provided with sub-entries, which are used to hold that plurality (members of the structure, or the items of the map or array). In other words, if the attribute is an array or a map, each item of the array or map is mapped to a sub-entry of the entry representing the array or map (as a whole). Thus, an object class containing only the LDAP attribute is generated. The name of this object class is based on the name of the attribute completed with the string --oc.  
     [0390] by contrast, where an OMSL attribute is “single-valued” (simple), it may be mapped directly to an LDAP attribute, tagged as single value. The LDAP attribute may be named as described above (id-mapping rules), along the IA5 String syntax, as shown in table Eh8-T0. In other words, at the object level in the LDAP schema, if the attribute is not an array or a map, the resulting LDAP attribute is part of the object class corresponding to the interface (or other object) containing the OMSL attribute.  
     [0391] Table Eh8-T11 shows an exemplary mapping of OMSL attribute types to LDAP in more detail. With reference to the row labels in Table Eh8-T11:  
     [0392] Row1: a “simple” attribute is mapped to an LDAP attribute.  
     [0393] Row2: in the case of a “simple” type attribute that is an array, an LDAP attribute is created to represent the array, together with an entity adapted to represent the items of the array. The entity may be in turn an object class, containing an attribute. Then, the array items are represented as LDAP sub-entries, instantiating the object class.  
     [0394] Row 3: the case of an enumeration type attribute may be treated similarly: it is mapped to an LDAP attribute, which itself is an attribute of an LDAP object class corresponding to the nature of the original enumeration.  
     [0395] Row 4: turning now to Structure Type Attributes, an attribute of structure type is mapped to LDAP by mapping the structure to LDAP, as described hereinafter. The configuration associated with the attribute is mapped as a sub-entry in the LDAP configuration tree. The name of the attribute is used as the RDN of the sub-entry.  
     [0396] Table Eh8-T12 shows how various OMSL entities (GGHA-ML in the example) may be mapped to an LDAP schema.  
     [0397] Consider for example the case of mapping OMSL members to LDAP Schema, as shown in table Eh8-T12, row 2. A OMSL member is defined from a cgha: member element, in the exemplary CGHA-ML. Now:  
     [0398] If the OMSL member is part of a structure mapped to LDAP, it is itself mapped to LDAP according to its type (for example, simple type, enumeration type, structure type).  
     [0399] otherwise, a simple type member is mapped directly to an LDAP attribute, named as described above and tagged as single value. Concerning the “object class” level:  
     [0400] if the member is not an array or a map, the resulting LDAP attribute is part of the object class corresponding to the structure containing the OMSL member.  
     [0401] if the member is an array or a map, each item of the array or map is mapped to a sub-entry. In this way, an object class containing only the LDAP attribute is generated. The name of this object class is based on the identifier of the attribute completed with the string --oc.  
     [0402] a member that is itself of structure type is mapped to LDAP by mapping the structure to LDAP. The configuration associated with the attribute is mapped as a sub-entry in the LDAP configuration tree. The name of the member is used as the RDN of the sub-entry.  
     [0403] After having defined the mapping the generic constructs, the MIBs will now be considered.  
     [0404] It is reminded that a MIB or Management Information Base is associated with a OMSL entity (SAP, component type configuration, cluster configuration, in the example), and has a corresponding container (cgha:sap, cgha:type, cgha:cluster, respectively)  
     [0405] Each MIB may be mapped to an LDAP tree of entries, which may contain the following:  
     [0406] any OMSL object (when “configuration oriented”, in the example) is mapped in this tree as an LDAP entry, which may have sub-entries.  
     [0407] furthermore, any OMSL object having a nested object (if “configuration oriented”) is also mapped in this tree of entries.  
     [0408] Mapping OMSL configuration to LDAP entries may be considered in the following order:  
     [0409] contents of the MIBs:Maps and Arrays, Init values, Objects, contexts;  
     [0410] binding between the MIBs and the OMSL/LDAP configuration space: Cluster Configuration, Component Type Configuration, Component Instance Configuration, Component Assignment Configuration, and SAPs;  
     [0411] overall platform update configuration: Platform Update, Software Load.  
     [0412] OMSL elements which are designated as a map or an array are mapped to LDAP as sub-entries of the LDAP entry corresponding to the map or array. (This mapping may be used for objects, contexts, attributes and members). The map and array items may be named using the generic object class cgha-element--oc. The sub-entries belong to the LDAP object class corresponding to the type of the element which is a map or an array. If the element is of simple type, the sub-entries belong to the object class that has been created specifically.  
     [0413] Simple type init values are mapped to LDAP using IA5 String syntax, applied to the string that has been used as value in the cgha:init element.  
     [0414] Similarly, Enumeration init values are mapped to LDAP using IA5 String syntax. The string that is stored in LDAP is the value of the enumeration value (cgha:enumvalue element) that has been selected in the cgha:init element.  
     [0415] Mapping OMSL Structures is now considered.  
     [0416] Consider first reflecting in LDAP the fact that a OMSL attribute or member is of structure type. It is mapped to an LDAP entry (which may have sub-entries, e.g. if the attribute or member is an array or a map, or if one of the members of a structure is itself a structure or is an array or a map). The generic object class cgha-structure--oc (Eh7-O4) is used. Its cgha-structure-type attribute defines the fully qualified type name of the structure. A cgha-structure-version attribute holds the structure version, if the structure has a version.  
     [0417] Now turning to Mapping a Structure (contents), the LDAP entry of an attribute or a member which is a structure, but which is not an array or a map, is defined by:  
     [0418] Its DN. The identifier of the OMSL attribute or member is used as RDN.  
     [0419] Its generic object classes:  
                                                  cgha-attribute--oc or cgha-member--oc           cgha-structure--oc.                      
 
     [0420] Its generated object classes based on the type of the structure, following the mapping defined above.  
     [0421] Its attributes, some of which are used to store the values associated with simple type members.  
     [0422] Its sub-entries, used to store the values associated with structure type members.  
     [0423] The case of mapping an Array or a Map of Structures will now be described. The LDAP entry corresponding to a structure type attribute or member that is an array or a map is defined by:  
     [0424] Its DN. The identifier of the OMSL attribute or member is used as RDN.  
     [0425] Its generic object classes:  
                                                  cgha-attribute--oc, or cgha-member--oc           cgha-structure--oc.                      
 
     [0426] Its sub-entries, used to store the values associated with the items of the array or map. Each LDAP sub-entry is defined by:  
     [0427] Its DN. The key of the item is used as RDN.  
     [0428] Its generic object classes:  
                                                  cgha-element--oc           cgha-structure--oc                      
 
     [0429] Its generated object classes, based on the type of the structure, following the mapping defined above,  
     [0430] Its attributes, used to store the values associated with simple type members.  
     [0431] Its sub-entries, used to store the values associated with structure type members.  
     [0432] Mapping Object References is now considered. A OMSL attribute or member that is an object reference is mapped to an LDAP entry, which may have sub-entries, e.g. if the attribute or member is an array or a map. The generic object class cgha-object-reference--oc contains the following four attributes (Eh7-O5):  
     [0433] cgha-object-reference-type, which defines the fully qualified type name of the object reference.  
     [0434] cgha-object-reference-version, which defines the version of the object reference.  
     [0435] cgha-object-reference-mib-dn, which is used to store the DN of the container of the MIB (cluster, component type or SAP), without taking into account the version and update level.  
     [0436] cgha-object-reference-full-name, which is used to store the full name of the referenced object, as described.  
     [0437] Thus, the LDAP entry of an attribute or a member which is an object reference, but which is not an array or a map, may be defined by:  
     [0438] Its DN. The identifier of the OMSL attribute or member is used as RDN.  
     [0439] Its generic object classes:  
                                                  cgha-attribute--oc or cgha-member--oc           cgha-object-reference--oc.                      
 
     [0440] Its generated object classes based on the type of the object reference, following the corresponding mapping, as above defined.  
     [0441] Its attributes.  
     [0442] In order to obtain the DN of the referenced object, the platform update table  28422  (FIG. 22) may be used to obtain the version and update level defining the MIB configuration, and to concatenate that with the RDN previously defined for the cgha-object-reference-full-name attribute.  
     [0443] Mapping an Array or a Map of Object References is now considered. The LDAP entry corresponding to an object reference type attribute or member that is an array or a map is defined by:  
     [0444] Its DN. The identifier of the OMSL attribute or member is used as RDN.  
     [0445] Its generic object classes:  
                                                  cgha-attribute--oc or cgha-member--oc           cgha-object-reference--oc.                      
 
     [0446] Its sub-entries used to store the values associated with the items of the array or map. Each LDAP sub-entry is defined by:  
     [0447] Its DN. The key of the item is used as RDN.  
     [0448] Its generic object classes, cgha-element--oc, cgha-object-reference--oc  
     [0449] Its generated object classes, based on the type of the object reference, following the mapping defined above for Object References.  
     [0450] Its attributes, some of which may be used to store the values associated with simple type members.  
     [0451] Mapping OMSL References is now considered. A OMSL attribute or member that is a reference and that is part of the configuration is mapped to an LDAP entry, which may have sub-entries. Sub-entries are necessary if the attribute or member is an array or a map. The generic object class cgha-reference--oc contains the following two attributes:  
     [0452] cgha-reference-type, which defines the fully qualified type name of the reference.  
     [0453] cgha-reference-dn, which is used to store the DN of the referenced component instance or assignment.  
     [0454] Mapping a Reference (per se) may now be described. The LDAP entry of an attribute or a member which is a reference, but which is not an array or a map, is defined by:  
     [0455] Its DN. The identifier of the OMSL attribute or member is used as RDN.  
     [0456] Its generic object classes:  
     [0457] -cgha-attribute--oc if it is an attribute or cgha-member--oc if it is a member  
     [0458] cgha-reference--oc.  
     [0459] Its generated object classes based on the type of the reference, following the mapping defined above for References  
     [0460] Its attributes.  
     [0461] Turning now to mapping an Array or a Map of References, the LDAP entry corresponding to a reference type attribute or member that is an array or a map is defined by:  
     [0462] Its DN. The identifier of the OMSL attribute or member is used as RDN.  
     [0463] Its generic object classes:  
                                                  cgha-attribute--oc or cgha-member--oc           cgha-reference--oc.                      
 
     [0464] Its sub-entries used to store the values associated with the items of the array or map. Each LDAP sub-entry is defined by:  
     [0465] Its DN. The key of the item is used as RDN.  
     [0466] Its generic object classes:  
                                                  cgha-element--oc           cgha-reference--oc                      
 
     [0467] Its generated object classes, based on the type of the reference, following the mapping defined above for References  
     [0468] Its attributes.  
     [0469] Mapping Objects to LDAP is now considered.  
     [0470] A OMSL object (specified e.g. with cgha:object) that implements an interface containing configuration attributes is called a configuration[-oriented] object. Each configuration object is mapped to an LDAP entry, with LDAP sub-entries if the implemented interface contains map or array attributes or structure type attributes. If the object contains nested objects that are also configuration objects, they are mapped as sub-entries of the entry corresponding to the enclosing object.  
     [0471] The generic object class cgha-object--oc (Eh7-O7) contains one attribute cgha-object-name used to define the RDN of the object in the LDAP tree.  
     [0472] The generic object class cgha-interface--oc (Eh7-O8) contains the following two attributes:  
     [0473] An attribute named cgha-interface-type that defines the fully qualified type name of the interface.  
     [0474] An attribute named cgha-interface-version that holds the version of the interface.  
     [0475] An object that implements a singleton interface and that is a configuration object, is mapped directly in the containing SAP. This means that the generated object class is added to the list of object classes provided by the LDAP entry corresponding to the SAP (as described). If the object contains nested configuration objects and if it is not a configuration object itself, the associated entry belongs only to the object class cgha-object--oc.  
     [0476] Mapping an Object That Is Not a Map to LDAP is now considered. The LDAP entry that corresponds to a configuration object is defined by:  
     [0477] Its DN. The identifier of the OMSL object is used as RDN.  
     [0478] Its generic object classes:  
                                                  cgha-object--oc.           cgha-interface--oc.                      
 
     [0479] Its generated object class(es) based on the type of the interface(s) implemented by the object. There is an object class for the interface implemented by the object and for each of the ancestors of that interface.  
     [0480] Its attributes.  
     [0481] Its sub-entries, used to store the values corresponding to:  
     [0482] Structure type attributes.  
     [0483] Nested objects or contexts.  
     [0484] The generic attributes cgha-interface-type and cgha-interface-version are initialized to define the fully qualified type name and version of the interface that is implemented by the object. The LDAP attribute resulting from mapping the category attribute is initialized based on the value provided in the configuration.  
     [0485] Mapping a Map of Objects to LDAP is now considered. The LDAP entry that corresponds to a map of configuration objects is defined by:  
     [0486] Its DN. The identifier of the OMSL object may be used as RDN.  
     [0487] Its generic object classes: cgha-object--oc and cgha-interface--oc.  
     [0488] Its sub-entries, used to store the values corresponding to each item of the map. Each LDAP sub-entry is defined by:  
     [0489] Its DN. The key of the map item is used as RDN.  
     [0490] Its generic object classes cgha-element-oc and cgha-interface-oc.  
     [0491] Its generated object class(es) based on the type of the interface(s) implemented by the object.  
     [0492] Its attributes.  
     [0493] Its sub-entries (if any).  
     [0494] Mapping OMSL Contexts to LDAP is now considered.  
     [0495] A OMSL context (specified using the cgha:context element) that contains nested configuration objects is mapped to an LDAP entry. The nested configuration objects are mapped as sub-entries of the entry corresponding to the context. If the context corresponds to a map, the items of the map are mapped to sub-entries of the entry corresponding to the context.  
     [0496] The generic object class cgha-context--oc (Eh7-O9) contains one attribute, cgha-context-name, which is used to define the RDN of the entry in the LDAP tree.  
     [0497] Mapping a Context That Is Not a Map to LDAP is now considered. The LDAP entry that is associated with a context that is not a map is defined by:  
     [0498] Its DN.  
     [0499] A generic object class cgha-context--oc.  
     [0500] Its sub-entries, which are used to map nested objects or contexts.  
     [0501] Mapping a Context That Is a Map to LDAP is now considered. The LDAP entry that is associated with a context that is not a map is defined by:  
     [0502] Its DN.  
     [0503] the generic object class cgha-context--oc.  
     [0504] Its sub-entries, which are used to map the items of the map, and nested objects or contexts. Each LDAP sub-entry is defined by:  
     [0505] Its DN. The key of the map item is used as RDN.  
     [0506] Its generic object class cgha-context--oc  
     [0507] Its sub-entries.  
     [0508] Mapping OMSL Cluster Configuration to LDAP is now considered.  
     [0509] The cluster configuration may be mapped as sub-entries of the LDAP entry ou=cluster, o=cgha_root. The cluster configuration may be mapped taking into account its version and its update level. The cluster configuration MIB is mapped as sub-entries of the resulting entry. The first sub-entry corresponds to the version of the cluster configuration. Its update level is nested inside the version sub-entry. The MIB (hierarchical tree of objects associated with the MIB) is nested within the update level sub-entry.  
     [0510] The version is mapped to an LDAP entry that belongs to the generic object class cgha-cluster-version--oc. This object class (Eh7-O10) contains one attribute cgha-cluster-version used to define the version of the configuration.  
     [0511] The update level is mapped to an LDAP entry that belongs to the generic object class cgha-cluster-update-level--oc. This object class (Eh7-O11) contains one attribute cgha-cluster-update-level used to define the update level of the configuration.  
     [0512] Mapping OMSL Component Type Configuration to LDAP is now considered. Component type configuration is mapped as sub-entries of the LDAP entry ou=types,o=cgha_root.  
     [0513] Component type configuration is mapped taking into account the fully qualified type name of the component, its version and its update level. The component type configuration MIB is mapped as sub-entries of the resulting entry.  
     [0514] The fully qualified type name is mapped to an LDAP entry that belongs to the generic object class cgha-component-type--oc. This object class (Eh7-O12) contains one attribute cgha-component-type used to define the fully qualified type name of the component.  
     [0515] The version is mapped to an LDAP entry that belongs to the generic object class cgha-component-type-version--oc. This object class (Eh7-O13) contains one attribute cgha-component-type-version used to define the version of the component.  
     [0516] The update level is mapped to an LDAP entry that belongs to the generic object class cgha-component-type-update-level--oc. This object class (Eh7-O14) contains one attribute cgha-component-type-update-level used to define the update level of the configuration.  
     [0517] Mapping OMSL Component Instance Configuration to LDAP is now considered.  
     [0518] Component instance configuration is mapped as sub-trees of the LDAP entry ou=instances, o=cgha_root. Component instance configuration is mapped taking into account its identifier, the identifier of the SAP containing the configuration, the component type version and the update level of the instance configuration. The MIBs corresponding to the component instance configuration are mapped as sub-entries of the resulting entry.  
     [0519] The component instance identifier is mapped to an LDAP entry that belongs to the generic object class cgha-component-instance-name--oc. This object class (Eh7-O15) contains two attributes:  
     [0520] cgha-component-instance-name used to define the identifier of the instance.  
     [0521] cgha-component-type used to define the fully qualified type name of the instance.  
     [0522] The component instance update level is mapped to an LDAP entry that belongs to the generic object class cgha-component-instance-update-level--oc. This object class (Eh7-O16) contains one attribute cgha-component-instance-update-level used to define the update level of the configuration.  
     [0523] Mapping OMSL Component Assignment Configuration is now considered.  
     [0524] Component assignment configuration is mapped as sub-trees of the LDAP entry ou=assignments, o=cgha_root. Component assignment configuration is mapped taking into account its identifier, the identifier of the SAP containing the configuration, the component type version and the update level of the assignment configuration. The component assignment  
     [0525] configuration MIBs are mapped as sub-entries of the resulting entry. The identifier is mapped to an LDAP entry that belongs to a generic object class cgha-component-assignment-name--oc. This object class (Eh7-O17) contains two attributes:  
     [0526] cgha-component-assignment-name used to define the name of the assignment.  
     [0527] cgha-component-type used to define the component type of the assignment.  
     [0528] The component assignment update level is mapped to an LDAP entry that belongs to a generic object class cgha-component-assignment-update-level--oc. This object class (Eh7-O18) contains one attribute cgha-component-assignment-update-level used to define the update level of the configuration.  
     [0529] Mapping OMSL SAPs to LDAP is now considered. SAPs are defined using the cgha: sap element (as specified above). SAPs are mapped to LDAP as sub-entries of the entry corresponding to the component instance (as described above) or component assignment (as described above) that contains the SAP.  
     [0530] The name is mapped to an LDAP entry that belongs to the generic object class cgha-sap-name--oc. This object class (Eh7-O19) contains two attributes:  
     [0531] cgha-sap-name used to define the name of the SAP.  
     [0532] cgha-sap-access used to specify whether the SAP will be exposed to a supervisor authority, e.g. an OMC (Operation &amp; Management Center).  
     [0533] The value management indicates that the SAP is exposed to the OMC. The value cluster indicates that the SAP is only exposed to cluster components.  
     [0534] Mapping the OMSL Platform Update to LDAP is now considered.  
     [0535] In order to provide a consistent view of the Network Element configuration, it is desirable to generate the list of update levels associated with all the MIBs defined in the platform update (specified using the cgha:platformUpdate element). This list is implemented in LDAP as a sub-entry of the LDAP entry ou=platform_updates, o=cgha_root. The list is implemented taking into account the version of the platform update: the version is mapped as the first sub-entry of ou=platform_updates, o=cgha_root, and the list of update levels is nested inside the sub-entry corresponding to the version. One entry in the list of update levels is generated per MIB.  
     [0536] The version is mapped to an LDAP entry that belongs to a generic object class cgha-platform-update-version-oc. This object class (Eh7-O20) contains one attribute cgha-platform-update-version used to define the version of the platform update.  
     [0537] The list of MIB update levels is implemented in LDAP as a set of entries belonging to a generic object class cgha-update-level--oc. This object class (Eh7-O21) contains three attributes:  
     [0538] the attribute cgha-component-update-level, which is used to define the RDN of the element in the list. Its value is the DN of the MIB including the associated version.  
     [0539] the attribute cgha-component-update-level-dn, which is used to define the DN of the MIB, including its update level.  
     [0540] the attribute cgha-updated, which is used to define if the MIB has been updated in the platform update. This attribute is set to 1 if the MIB has been updated and to 0, otherwise.  
     [0541] Mapping the OMSL Software Load to LDAP is now considered.  
     [0542] The software load version provides the means to access the correct version of the platform update table. This is implemented in LDAP as a sub-entries of the LDAP entry ou=software_loads, o=cgha_root, taking into account the version of the software load.  
     [0543] The version is mapped to an LDAP entry that belongs to a generic object class cgha-software-load-version--oc. This object class (Eh7-O22) contains two attributes:  
     [0544] cgha-software-load-version, used to define the version of the software load.  
     [0545] cgha-platform-update-dn, used to define the DN of the current platform update table. This current platform update table corresponds to that defined by the &lt;prefix&gt;.apply.ldif file (described hereinafter).  
     [0546] A file used to apply the platform update may contain the entry as shown in second place, which sets the current platform update DN.  
     [0547] Removing LDAP Entries is now considered. LDAP entries must be removed before removing object classes and attributes from the LDAP schema. The following syntax is used to remove LDAP entries:  
     [0548] dn: dnValue  
     [0549] changetype: delete  
     [0550] where dn: dnValue corresponds to the DN of the entry to be removed.  
     [0551] The Generated Files are now considered, with reference to FIG. 22. The tool (named e.g. ml2 config) may be used to map naming and configuration data to LDAP, relying on the above described mapping scheme.  
     [0552] The resulting LDAP information is organized into a set of files. Before initialization, these files are uploaded onto the cluster by the software load tools. The files can then be used by the OMSL Software Platform to populate the LDAP server running on each cluster during initialization.  
     [0553] Each file defining a platform update (using the cgha:platformUpdate element) is mapped to a plurality of files, defined below, where &lt;prefix&gt; is the concatenation of the identifier and the version of the platform update, separated by a period character (.). Note that &lt;prefix&gt; is shown as “platformUpdate.version” in FIG. 22. The files may be:  
     [0554] &lt;prefix&gt;.populate.ldif. This file contains:  
     [0555] The attributes and the object classes, resulting from mapping the new OMSL types provided in the platform update.  
     [0556] The entries, resulting from mapping the configuration provided in the platform update.  
     [0557] The MIB update levels table.  
     [0558] &lt;prefix&gt;.apply.ldif. This file defines the current platform update version, corresponding to the current software load. This is done by defining the current platform update table DN in the software load entries.  
     [0559] &lt;prefix&gt;.remove.ldif. This file is used to remove from the LDAP server all the information that does not belong to the current platform update.  
     [0560] &lt;prefix&gt;.rollback.ldif. This file is used to roll back the LDAP server to its state before applying the &lt;prefix&gt;.apply.ldif file.  
     [0561] &lt;prefix&gt;.cleanup.ldif. This file is used to remove from the LDAP server all the entries that have been added by applying the &lt;prefix&gt;.populate.ldif file.  
     [0562] &lt;prefix&gt;.next.xml. This file gives a brief description of the platform in order to be able to perform the next platform update.  
     [0563] The LDIF files can then be loaded onto the LDAP server, depending on the platform update strategy, as described below.  
     [0564] The OMSL Software Platform is updated in a controlled manner in order to apply a new platform update defining a software load and a configuration update to the platform.  
     [0565] First of all, the LDAP server is populated using the &lt;prefix&gt;.populate.ldif described above. The LDAP server can be populated in advance. The &lt;prefix&gt;.apply.ldif file provides the DN of the current platform update table, and hence the platform takes into account the new configuration update and software load. One of two possible scenarios then occurs:  
     [0566] The platform update is successful: the platform and all its components continue to run correctly. In this case, the OMC (Operation &amp; Management Center) gives the instruction to commit. All the information that does not belong to the current platform update must then be removed from the LDAP server, using the &lt;prefix&gt;.remove.ldif file.  
     [0567] The platform update is unsuccessful: one or more components fail to run correctly and the OMC gives the instruction to rollback. In this case, the &lt;prefix&gt;.rollback.ldif file must be used to return the LDAP server to its previous state. This file provides the DN of the previous platform update table, thus enabling the platform to run using the previous configuration load and software load. Finally, in case of rollback, it is necessary to clean up the LDAP server, using &lt;prefix&gt;.cleanup.ldif. This removes all the entries that were added during population of the LDAP server.  
     [0568] In both cases, the platform returns to a stable state after the update process. In the second case, when the OMC gives the instruction to rollback, the new state of the platform is exactly equivalent to the previous one.  
     [0569] Basically, the OMSL-to-LDAP mapping may be applied to the MIBs. By way of example, Exhibit Eh9 shows a mapping of a component type configuration MIB.  
     [0570] The OMSL code (here, CGHA-ML) for the MIB is shown at Eh9-A. The MIB defines an object named component Descriptor, corresponding to version 1 of a boot server. Assuming this is update level 1 of the configuration, the corresponding LDAP (“user”) entry may be as shown at Eh9-B. The relative Distinguished Name or RDN is cgha-object-name=componentDescriptor.  
     [0571] It will be understood that other OMSL entities of the MIBs may be mapped to LDAP, on the basis of the above described mapping schemes. In the exemplary embodiment, only the “configuration oriented” OMSL entities are mapped to LDAP. However, other OMSL entities may be mapped to LDAP as well.  
     [0572] Also, there has been proposed an OMSL language (being both Operational and Modeling), and a mapping to a directory system language (or DSSL) to represent the current condition of the platform (“current load”), and, if desired, a possible new condition (“software load”).  
     [0573] Accordingly, this aspect of this invention allows one or more of the following:  
     [0574] upgrade modification of the schema defining the configuration state of the platform;  
     [0575] downgrade modification of the schema defining the configuration state;  
     [0576] upgrade modification of the configuration state of the platform;  
     [0577] downgrade modification of the configuration state;  
     [0578] commit of the configuration modification;  
     [0579] rollback of the configuration modification;  
     [0580] uniform access to the configuration.  
     [0581] This invention also encompasses a platform, at runtime, having the above described LDAP data, however not the OSML data from which such LDAP data have been mapped. It will also be appreciated that this includes the possibility that the DSSL be directly used as an Operational and Modeling Language, at least in part, e.g. for the configuration oriented information, as described.  
     [0582] This invention is of interest in the case of a redundant platform, as it has appeared from the above description. However, this should not be seen as a necessary feature, and the invention may also apply to a non redundant platform as well.  
     [0583] More generally, this invention covers a platform and/or its parts, whether considered at the level of design, or at runtime. It further covers various corresponding methods, as they may be extracted from the above description.  
     [0584] Thus, there is proposed a method of preparing loadable software for a platform, the method comprising the steps of:  
     [0585] a. preparing first data (e.g. at the model level of items  2010  and  2020  in FIG. 9) defining a given software to be loaded,  
     [0586] b. generating second data from said first data, said second data comprising identifiers of software elements to be loaded (e.g. item  2030  in FIG. 9), and  
     [0587] c. generating third data from said second data, and from a definition of the platform on which the third software load data is to be loaded (e.g. items  1570 ,  2400  and/or  2500  in FIG. 10).  
     [0588] There is also proposed an apparatus for aiding software load in a platform, said apparatus comprising:  
     [0589] a package repository,  
     [0590] a model repository, and  
     [0591] software load aiding code, interacting with the package repository and the model repository,  
     [0592] said software load aiding code being capable of converting an expression of a software load in a model language into a combination of code and configuration data being valid for execution in the platform.  
     [0593] The above method and apparatus are subject, optionally, to all the refinements described herein.  
     [0594] Independently, the features of a platform in operation are encompassed, as well as the methods involved in its operation. This includes, but is not limited to, the directory server and/or LDAP aspects.  
     [0595] This invention also covers the software code as used in this invention, especially when made available on any appropriate computer-readable medium. The expression “computer-readable medium” includes a storage medium such as magnetic or optic, as well as a transmission medium such as a digital or analog signal.  
     [0596] The software code basically includes, separately or together, the codes as used when writing the OSML and/or LDAP files (or equivalent), and/or accompanying executable code or macros (or equivalent), e.g. in LDAP, as well as precursors and/or generators of such codes, and as the resulting code, as applicable e.g. in a platform and/or directory server. The invention also encompasses the combinations of such codes with language dependent and/or hardware dependent code and/or data. The invention also encompasses an operating system, comprising part or all of such code.  
     [0597] Exhibit Eh1—Exemplary Document Type Definition (DTD)  
     [0598] The DTD is as shown in the right column of the following table. The identifying labels in the left column form no part of the DTD.  
                                          &lt;?xml version=“1.0” encoding=“us-ascii” ?&gt;           &lt;!--CGHAML DTDident “@(#)cghaml.dtd 1.34 01/07/19 SMI”--&gt;       A   &lt;!--Generic Elements--&gt;       A1   &lt;!ELEMENT cgha:description (#PCDATA)&gt;       A2   &lt;!ELEMENT cgha:import           (cgha:description?)&gt;           &lt;!ATTLIST cgha:import           href CDATA #REQUIRED&gt;       A3   &lt;!ELEMENT cgha:package           (cgha:description?,           cgha:import*,           ((cgha:interface|           cgha:structure|           cgha:enumeration|           cgha:objectReference|           cgha:reference|           cgha:exception|           cgha:event)*|           cgha:component))&gt;           &lt;!ATTLIST cgha:package           name CDATA #REQUIRED&gt;       B   &lt;!--Interface Model--&gt;       B1   &lt;!ELEMENT cgha:interface           (cgha:description?,           cgha:inherit?,           cgha:constant*,           (cgha:attribute|           cgha:operation)*,           cgha:publish*)&gt;           &lt;!ATTLIST cgha:interface           type CDATA #REQUIRED           version CDATA #REQUIRED           leaf (yes|no) ′no′           native (yes|no) ′no′           singleton (yes|no) ′no′&gt;       B2   &lt;!ELEMENT cgha:inherit           (cgha:description?)&gt;           &lt;!ATTLIST cgha:inherit           type CDATA #REQUIRED           version CDATA #REQUIRED&gt;       B3   &lt;!ELEMENT cgha:constant           (cgha:description?)&gt;           &lt;!ATTLIST cgha:constant           name CDATA #REQUIRED           type CDATA #REQUIRED           value CDATA #REQUIRED&gt;       B4   &lt;!ELEMENT cgha:attribute           (cgha:description?,           cgha:init*)&gt;           &lt;!ATTLIST cgha:attribute           name CDATA #REQUIRED           type CDATA #REQUIRED           version CDATA #IMPLIED           array (yes|no) ′no′           map (yes|no) ′no′           mode (R|RW) ′RW′           configuration (yes|no) ′no′&gt;       B5   &lt;!ELEMENT cgha:init           (cgha:description?,           cgha:init*)&gt;           &lt;!ATTLIST cgha:init           name CDATA #IMPLIED           member CDATA #IMPLIED           attribute CDATA #IMPLIED           reference CDATA #IMPLIED           key CDATA #IMPLIED           value CDATA #IMPLIED           final (yes|no) ′no′&gt;       B6   &lt;!ELEMENT cgha:operation           (cgha:description?,           cgha:request?,           cgha:reply?,           cgha:raise*)&gt;           &lt;!ATTLIST cgha:operation           name CDATA #REQUIRED           mode (rpc|oneway) ′rpc′&gt;       B7   &lt;!ELEMENT cgha:request           (cgha:description?,           cgha:parameter+)&gt;       B8   &lt;!ELEMENT cgha:reply           (cgha:description?,           cgha:parameter+)&gt;       B9   &lt;!ELEMENT cgha:parameter           (cgha:description?)&gt;           &lt;!ATTLIST cgha:parameter           name CDATA #REQUIRED           type CDATA #REQUIRED           version CDATA #IMPLIED           array (yes|no) ′no′&gt;       B10   &lt;!ELEMENT cgha:structure           (cgha:description?,           cgha:member+)&gt;           &lt;!ATTLIST cgha:structure           type CDATA #REQUIRED           version CDATA #IMPLIED&gt;       B11   &lt;!ELEMENT cgha:member           (cgha:description?)&gt;           &lt;!ATTLIST cgha:member           name CDATA #REQUIRED           type CDATA #REQUIRED           version CDATA #IMPLIED           array (yes|no) ′no′           map (yes|no) ′no′&gt;       B12   &lt;!ELEMENT cgha:enumeration           (cgha:description?,           cgha:enumValue+)&gt;           &lt;!ATTLIST cgha:enumeration           type CDATA #REQUIRED           version CDATA #IMPLIED&gt;       B13   &lt;!ELEMENT cgha:enumValue           (cgha:description?)&gt;           &lt;!ATTLIST cgha:enumValue           name CDATA #REQUIRED           value CDATA #IMPLIED&gt;       B14   &lt;!ELEMENT cgha:objectReference           (cgha:description?)&gt;           &lt;!ATTLIST cgha:objectReference           type CDATA #REQUIRED           version CDATA #REQUIRED           referencedObjectType CDATA #REQUIRED           referencedObjectVersion CDATA #REQUIRED&gt;       B15   &lt;!ELEMENT cgha:reference           (cgha:description?)&gt;           &lt;!ATTLIST cgha:reference           type CDATA #REQUIRED&gt;       B16   &lt;!ELEMENT cgha:raise           (cgha:description?)&gt;           &lt;!ATTLIST cgha:raise           type CDATA #REQUIRED           version CDATA #IMPLIED&gt;       B17   &lt;!ELEMENT cgha:exception           (cgha:description?,           cgha:member*)&gt;           &lt;!ATTLIST cgha:exception           type CDATA #REQUIRED           version CDATA #IMPLIED&gt;       B18   &lt;!ELEMENT cgha:publish           (cgha:description?)&gt;           &lt;!ATTLIST cgha:publish           type CDATA #REQUIRED           version CDATA #REQUIRED&gt;       B19   &lt;!ELEMENT cgha:event           (cgha:description?,           cgha:member*)&gt;           &lt;!ATTLIST cgha:event           type CDATA #REQUIRED           version CDATA #REQUIRED&gt;       C   &lt;!--Component Model--&gt;       C1   &lt;!ELEMENT cgha:component           (cgha:description?,           cgha:use*,           cgha:type,           cgha:sap*)&gt;           &lt;!ATTLIST cgha:component           type CDATA #REQUIRED           version CDATA #REQUIRED&gt;       C2   &lt;!ELEMENT cgha:use           (cgha:description?)&gt;           &lt;!ATTLIST cgha:use           type CDATA #REQUIRED           minVersion CDATA #REQUIRED           maxVersion CDATA #REQUIRED&gt;       C3   &lt;!ELEMENT cgha:type           (cgha:description?,           cgha:provide*,           cgha:mib)&gt;       C4   &lt;!ELEMENT cgha:sap           (cgha:description?,           cgha:provide*,           cgha:mib?)&gt;           &lt;!ATTLIST cgha:sap           name CDATA #REQUIRED           scope (instance|assignment) #REQUIRED           access (cluster|management) ′management′&gt;       C5   &lt;!ELEMENT cgha:provide           (cgha:description?)&gt;           &lt;!ATTLIST cgha:provide           type CDATA #REQUIRED           minVersion CDATA #REQUIRED           maxVersion CDATA #REQUIRED&gt;       C6   &lt;!ELEMENT cgha:mib           (cgha:description?,           (cgha:context|           cgha:object)*)&gt;       C7   &lt;!ELEMENT cgha:context           (cgha:description?,           (cgha:context|           cgha:object)*)&gt;           &lt;!ATTLIST cgha:context           name CDATA #REQUIRED           map (yes|no) ′no′&gt;       C8   &lt;!ELEMENT cgha:object           (cgha:description?,           (cgha:init*,           (cgha:context|           cgha:object)*))&gt;           &lt;!ATTLIST cgha:object           name CDATA #IMPLIED           type CDATA #REQUIRED           map (yes|no) ′no′&gt;       D   &lt;!--Software Load Model--&gt;       D1   &lt;!ELEMENT cgha:softwareLoad           (cgha:description?,           cgha:import*,           cgha:cluster,           cgha:componentLoad*)&gt;           &lt;!ATTLIST cgha:softwareLoad           name CDATA #REQUIRED           version CDATA #REQUIRED&gt;       D2   &lt;!ELEMENT cgha:cluster           (cgha:description?,           cgha:provide*,           cgha:mib)&gt;           &lt;!ATTLIST cgha:cluster           version CDATA #REQUIRED&gt;       D3   &lt;!ELEMENT cgha:componentLoad           (cgha:description?,           cgha:init*)&gt;           &lt;!ATTLIST cgha:componentLoad           type CDATA #REQUIRED           version CDATA #REQUIRED&gt;       E   &lt;!--Configuration Update Model--&gt;       E1   &lt;!ELEMENT cgha:configurationUpdate           (cgha:description?,           cgha:import*,           cgha:softwareLoadDefinition,           cgha:clusterConfiguration?,           (cgha:typeConfiguration|           cgha:instanceConfiguration|           cgha:assignmentConfiguration|           cgha:removeInstance|           cgha:removeAssignment)*)&gt;           &lt;!ATTLIST cgha:configurationUpdate           name CDATA #REQUIRED           version CDATA #REQUIRED&gt;       E2   &lt;!ELEMENT cgha:softwareLoadDefinition           (cgha:description?)&gt;           &lt;!ATTLIST cgha:softwareLoadDefinition           name CDATA #REQUIRED           version CDATA #REQUIRED&gt;       E3   &lt;!ELEMENT cgha:clusterConfiguration           (cgha:description?,           cgha:init*)&gt;       E4   &lt;!ELEMENT cgha:typeConfiguration           (cgha:description?,           cgha:init*)&gt;           &lt;!ATTLIST cgha:typeConfiguration           type CDATA #REQUIRED&gt;       E5   &lt;!ELEMENT cgha:instanceConfiguration           (cgha:description?,           cgha:sapConfiguration*)&gt;           &lt;!ATTLIST cgha:instanceConfiguration           name CDATA #REQUIRED           type CDATA #REQUIRED&gt;       E6   &lt;!ELEMENT cgha:assignmentConfiguration           (cgha:description?,           cgha:sapConfiguration*)&gt;           &lt;!ATTLIST cgha:assignmentConfiguration           name CDATA #REQUIRED           type CDATA #REQUIRED&gt;       E7   &lt;!ELEMENT cgha:sapConfiguration           (cgha:description?,           cgha:init*)&gt;           &lt;!ATTLIST cgha:sapConfiguration           name CDATA #REQUIRED&gt;       E8   &lt;!ELEMENT cgha:removeInstance           (cgha:description?)&gt;           &lt;!ATTLIST cgha:removeInstance           name CDATA #REQUIRED&gt;       E9   &lt;!ELEMENT cgha:removeAssignment           (cgha:description?)&gt;           &lt;!ATTLIST cgha:removeAssignment           name CDATA #REQUIRED&gt;       F   &lt;!--Platform Update Model--&gt;       F1   &lt;!ELEMENT cgha:platformUpdate           (cgha:description?,           cgha:import*,           cgha:currentLoadDefinition?,           cgha:softwareLoadDefinition,           cgha:configurationUpdateDefinition*)&gt;           &lt;!ATTLIST cgha:platformUpdate           name CDATA #REQUIRED           version CDATA #REQUIRED           configuration (load|update) ′update′&gt;       F2   &lt;!ELEMENT cgha:currentLoadDefinition           (cgha:description?)&gt;           &lt;!ATTLIST cgha:currentLoadDefinition           version CDATA #REQUIRED&gt;       F3   &lt;!ELEMENT cgha:configurationUpdateDefinition           (cgha:description?)&gt;           &lt;!ATTLIST cgha:configurationUpdateDefinition           name CDATA #REQUIRED           version CDATA #REQUIRED&gt;       F4   &lt;!ELEMENT cgha:currentLoad           (cgha:import*,           cgha:currentCluster,           (cgha:currentType |           cgha:currentInstance |           cgha:currentAssignment)*)&gt;           &lt;!ATTLIST cgha:currentLoad           version CDATA #REQUIRED           platformUpdateName CDATA #REQUIRED           platformUpdateVersion CDATA #REQUIRED           softwareLoadName CDATA #REQUIRED           softwareLoadVersion CDATA #REQUIRED&gt;       F5   &lt;!ELEMENT cgha:currentCluster           (cgha:provide*,           cgha:mib)&gt;           &lt;!ATTLIST cgha:currentCluster           version CDATA #REQUIRED           updateLevel CDATA #REQUIRED&gt;       F6   &lt;!ELEMENT cgha:currentType           (cgha:init*)&gt;           &lt;!ATTLIST cgha:currentType           type CDATA #REQUIRED           version CDATA #REQUIRED           updateLevel CDATA #REQUIRED&gt;       F7   &lt;!ELEMENT cgha:currentInstance           (cgha:sapConfiguration*)&gt;           &lt;!ATTLIST cgha:currentInstance           name CDATA #REQUIRED           type CDATA #REQUIRED           updateLevel CDATA #REQUIRED&gt;       F8   &lt;!ELEMENT cgha:currentAssignment           (cgha:sapConfiguration*)&gt;           &lt;!ATTLIST cgha:currentAssignment           name CDATA #REQUIRED           type CDATA #REQUIRED           updateLevel CDATA #REQUIRED&gt;                  
 
     [0599] Exhibit Eh2—Tables Describing Elements of the DTD  
     [0600] In each table, the upper leftmost cell repeats the label of the element being described, as it appears in the DTD of Exhibit Eh1. The upper rightmost cell repeats the name of the element in the DTD. The next rows discuss attributes, if any. One or more last rows (single column) may recite the sub-elements, if any, and may also include notes.  
                                   A3   cgha:package                  name   Specifies the package identifier.           By convention, the name of a package begins with the reversed           DNS name of the organization that created or controls the package.           That organization can then organize the namespace           of its packages according to its own requirements.                 Sub-elements:       * An optional list of imported files, using cgha:import.       Files that can be imported are files that specify a cgha:package.       * A list of type definitions, from the above set of type definitions.                  
 
     [0601]                                   B1   cgha:interface                  type   Specifies the identifier of the currently defined interface.       version   Specifies the version of the interface, a positive integer.       leaf   Specifies inheritance. If the leaf attribute is set to “yes”, no other interface           may inherit from this one. The default value of this attribute is “no”.       native   Specifies whether code is generated by compilation of the currently defined           interface. If the native attribute is set to “yes”, no code is generated. The           default value of this attribute is “no”. This mechanism allows the smooth           integration of code, developed with specific semantics, into the global model.       singleton   Makes it possible to associate a procedural model with each SAP. A singleton           interface can only be accessed by requiring a reference to the SAP that contains           an instance of it. Therefore, only one object per SAP can be an instance of a           singleton interface. If the singleton attribute is set to “yes”, the interface is           a singleton interface. The default value of this attribute is “no”.                 Sub-elements:       * An optional inheritance field (cgha:inherit).       * An optional list of constants (cgha:constant).       * An optional list of attributes and/or operations (cgha:attribute and/or       cgha:operation).       * An optional list of event types (cgha:publish). All the event types that might be published       by an object implementing the currently defined interface must be present in the list.                    
     [0602]                                   B2   cgha:inherit                  type   Specifies the fully qualified type name of the base interface from           which the currently specified interface inherits.       version   Specifies the version of the base interface.                 Note: An interface with the corresponding type and version       must have been previously defined.                    
     [0603]                                   B3   cgha:constant                  name   Specifies the identifier of the constant.       type   Specifies the type of the constant. This type must be a simple type.       value   Specifies the value of the constant. The value must be compatible           with the type of the constant.                 Sub-elements: none                    
     [0604]                                   B4   cgha:attribute                  name   Specifies the identifier of the interface attribute.       type   Specifies the type of the interface attribute: either a simple type or one of           the following types: a structure, an enumeration, a reference, an object           reference. For all types which are not simple types, the type attribute           specifies the fully qualified type name.       version   Specifies the version of the attribute type (optional).       array   Specifies whether the attribute is an array. If the attribute is set to “yes”,           the attribute is an array. The default value of this attribute is “no”.       map   Specifies whether the attribute is a map. If the map attribute is set to           “yes”, the attribute is a map. The default value of this attribute is “no”.       mode   Specifies the read/write permissions for accessing the attribute from the           perspective of the interface client. The default permissions are read and           write (RW). If the permissions are set to read (R) no write access is           provided to the client.       configuration   Specifies whether the attribute is configuration information. The default           value for the configuration attribute is “no”. Configuration           attributes are stored in the Cluster Configuration Repository (LDAP).           Configuration attributes must be initialized. The initialization is done           using cgha:init elements. This initialization can be done at interface           definition level, at component definition level, at software load definition           level or at configuration update level. The attribute type defined by the           type and version attributes must have been previously defined.                 Sub-elements:       * an optional list of initial values (cgha:init)                    
     [0605]                                   B5   cgha:init                  name   Specifies the identifier of the object being initialized. This attribute must be set           when initializing a specific object in the initialization of a MIB.       member   Specifies the member of a structure being initialized. This attribute must be set           when initializing a specific member in the initialization of a structure.       reference   Identifies the referenced object or component. For a referenced object, the           reference attribute is set to object. For a referenced component, the reference           attribute is set to instance or assignment depending on the scope of the component.           This information enables the value attribute to be interpreted correctly           when reference and object reference type attributes are initialized.       attribute   Specifies which attribute is being initialized. This attribute must be set when           initializing a specific attribute of an object.       key   Specifies the key of the item being initialized. This must be set when initializing           a specific item in an array of items or in a map of items. For a map of items, its           value can be any string. For an array of items, its value must be an integer value.       value   Specifies the value of a simple type attribute or member (leaf in the initialization           tree). The value must be compatible with the type of the attribute or member.       final   Controls the initialization semantics                 Sub-elements: none                    
     [0606]                                   B6   cgha:operation                  name   Specifies the identifier of the operation.       mode   Specifies the semantics of the operation. Two modes can be           specified: synchronous operation, specified using rpc, and           one-way operation, specified using oneway. Synchronous           operation means that the caller of the operation waits for           it to complete before proceeding. One-way operation means that           the caller of the operation does not wait for it to complete before           proceeding. The default mode is rpc.                 Sub-elements:       * An optional request description (cgha:request). When it is defined, this       element specifies the parameters sent from the caller to the callee.       * An optional reply description (cgha:reply). When it is defined, this       element specifies the parameters replied by the callee to the caller.       * An optional list of exceptions that can be raised (cgha:raise).                    
     [0607]                                   B9   cgha:parameter                  name   Specifies the identifier of the parameter.       type   Specifies the type of the parameter: simple type, structure           type or enumeration type. For structures and enumerations,           the type attribute specifies the fully qualified type name           of that type.       version   Specifies the version of the parameter type (optional)       array   Specifies whether the parameter is an array. If the array attribute           is set to “yes”, the parameter is an array. The default value of           this attribute is “no”.                 Sub-elements: none                     B10   cgha:structure       type   Specifies the identifier of the currently defined structure.       version   Specifies the optional version of the structure.                 Sub-element:       * A list of members that defines the members of the structure       (cgha:member). This list cannot be empty.                    
     [0608]                                   B11   cgha:member                  name   Specifies the identifier of the member.       type   Specifies the type of the member, which can be either a           simple type or one of the following types: structure ;           enumeration ; object reference ; reference for all types           which are not simple types. The type attribute is           the fully qualified type name of that type.       version   Specifies the version of the member type (optional)       array   Specifies whether the member is an array. If the array attribute           is set to “yes”, the member is an array. The default           value of this attribute is “no”.       map   Specifies whether a member of a structure is a map. If the map           attribute is set to “yes”, the member is a map. The default           value of this attribute is “no”. Note that the value of the           map attribute must be set to “no” for members of           exceptions and events. The type defined by the type and            version attributes must have been previously defined.                    
     [0609]                                   B12   cgha:enumeration                  type   Specifies the identifier of the currently defined enumeration.       version   Specifies the version of the enumeration (optional).                            
     [0610]                                   B13   cgha:enumeration                  name   Specifies the identifier of the enumeration value. In the same           enumeration it is not possible to have different enumeration values           with the same identifier.       value   Specifies the value of the enumeration value. It must be different           from every other value in the same enumeration. If this attribute is           not defined, the value of the enumeration value is generated auto-           matically.                    
     [0611]                                   B14   cgha:objectReference                  type   Specifies the identifier of the object reference.       version   Specifies the version of the object reference.       referencedObjectType   Specifies the fully qualified type name of the           object pointed to by the reference.       referencedObjectVersion   Specifies the version of the referenced ob-           ject. This attribute must be a positive integer.                            
     [0612]                                                   B15   cgha:reference                          type   Specifies the identifier of the reference.                                    
     [0613]                                   B16   cgha:raise                  type   Specifies the fully qualified type name of the exception. If it is a           structure or an enumeration, the type attribute is the fully qual-           ified type name of that type.       version   Specifies the version of the exception (optional).                            
     [0614]                                   B17   cgha:exception                  type   Specifies the identifier of the currently defined exception.       version   Specifies the version of the exceptional (optional).                                    
     [0615]                                                   B18   cgha:publish                          type   Specifies the fully qualified type name of the event.           version   Specifies the version of the event.                        
     [0616]                                                   B19   cgha:event                          type   Specifies the identifier of the event.           version   Specifies the version of the event.                                                
     [0617]                                   C1   cgha:component                  type   Specifies the identifier of the currently defined component.       version   Specifies the version of the component.                                                    
     [0618]                                   C2   cgha:use                  type   Specifies the fully qualified type name of the interface that           is used by the component. This type must be an interface           type.       minVersion   Specifies the oldest version of the interface that is used (this           corresponds to the version with the lowest version number).       maxVersion   Specifies the most recent version of the interface that is           used (this corresponds to the version with the highest ver-           sion number). This attribute must be greater than or equal to           the minVersion attribute.                    
     [0619]                                   C3   cgha:type                  No attribute                     Sub-elements:       An optional list of provided interfaces. The cgha:provide element       defines the interfaces, including the versions that is used to define       the component type configuration. It is only possible to provide       interfaces without operations and with solely configuration attribu-       tes.       A MIB. The cgha:mib element defines the MIB that is associated with       the component type configuration. To be able to create objects       implementing an interface in the MIB, the interface must be declared       in the list of provided interfaces. If multiple versions of an       interface are provided, the configuration is defined by the most       recent interface (that is, the interface with the highest version       number).                    
     [0620]                                   C4   cgha:sap                  name   Specifies the identifier of the SAP.       scope   Specifies the scope of the SAP with respect to           the HA behavior of the component. The instance           scope binds the SAP to the component instance           life cycle. The assignment scope binds           the SAP to the component assignment life cycle.       access   Specifies if the SAP is visible to the OMC           through the Management Agent. This attribute           can only take one of two values: management           or cluster. If access is set to management,           the SAP is visible to the OMC. If access is           set to cluster, the SAP is not visible to the           OMC. In both cases, the SAP is visible within           the cluster.                 Sub-elements:       An optional list of provided interfaces. The cgha:provide element       defines the interface, including the versions that are provided       through the currently defined SAP.       An optional MIB. The cgha:mib element defines the MIB that is       associated with the SAP. To be able to create objects implementing       an interface in the MIB, the interface must be declared in the       list of provided interfaces. If multiple versions of an interface       are provided, the object implementing this interface must support       all these versions. However, if multiple versions of an interface       are provided, the configuration is defined by the most recent       interface (the interface with the highest version number).                    
     [0621]                                                   C5   cgha:provide                          type   Specifies the fully qualified type name of the               interface. This type must be an interface type.           minVersion   Specifies the oldest version of the interface               that is used (this corresponds to the version               with the lowest version number).           maxVersion   Specifies the most recent version of the               interface that is used (this corresponds to               the version with the highest version number).               This attribute must be greater than or equal               to the minVersion attribute.                         Sub-element: None                        
     [0622]                                   C6   cgha:mib                  No attribute                     Sub-elements:       An optional list of contexts or objects (cgha:context, cgha:object).                    
     [0623]                                   C7   cgha:context                  name   Specifies the identifier of the naming context.       map   Specifies whether or not the element defines           a map of contexts. If the attribute is set           to “yes”, the element defines a map of           contexts. In this case, each context is           identified in the map by a unique key. New           instances can be created at runtime.                 Sub-element:       An optional list of contexts or objects (cgha:context, cgha:object).                    
     [0624]                                   C8   cgha:object                  name   Specifies the identifier of the object. In a           MIB contained in a SAP, it is possible to           associate at most one unnamed object, which           is an instance of a singleton interface.           An unnamed object has no name attribute           specified and must appear directly within           the cgha:mib element, not within a contained           cgha:context. Furthermore, it is not possible           to have named objects that are instances of a           singleton interface. In all other cases, the           objects must be named.       type   Specifies the fully qualified type name of           the interface that the object implements.           This interface must be provided in the element           containing the MIB. The configuration is           defined by the most recent version provided,           that is the version with the highest version           number.       map   Specifies whether the element defines a map of           objects. If the map attribute is set to “yes”,           the element defines a map of objects. In this           case, each object is identified in the map by a           unique key. New instances can be created at           runtime.                 Sub-elements:       An optional list of init values (cgha:init). This list, when defined,       specifies the value of the attributes of the interface implemented       by the object.       An optional list of contexts or objects (cgha:context, cgha:object).       This list, when defined, specifies the contexts and objects that are       nested within the currently defined object.                    
     [0625]                                   D1   cgha:softwareLoad                  name   Specifies the identifier of the software load.       version   Specifies the version of the software load.                 Sub-elements:       An optional list of imported files (using the cgha:import element).       A cluster configuration definition (using the cgha:cluster element).       An optional list of component loads (cgha:componentLoad). A component       load identifies a component and supports initialization of       configuration attributes of objects contained in the component       type configuration MIB. This initialisation is used, for example,       to select the packages that are required for a specific software       load. A software load cannot contain two different versions of the       same component type.                    
     [0626]                                   D2   cgha:cluster                  version   Specifies the version of the cluster           configuration definition.                 Sub-elements:       An optional list of provided interfaces. The cgha:provide element       defines the interface, including the versions that are used to       defined the cluster configuration. It is only possible to have       interfaces without operations and with only configuration       attributes (configuration set to “yes”).       A MIB. The cgha:mib element defines the MIB that is associated       with the cluster configuration. To be able to create objects       implementing an interface in the MIB, the interface must be       declared in the list of provided interfaces. The version of       the interface used to instantiate objects in the MIB is the       most recent version of the interface that is provided, that       is the version with the highest version number.                    
     [0627]                                                   D3   cgha:componentLoad                          type   Specifies the fully qualified type name of               the component.           version   Specifies the version of the component.                         Sub-element:           An optional list of configuration values that, when defined using           cgha:init, specify the values of the attributes of the objects           that are configured.                        
     [0628]                                   E1   cgha:configurationUpdate                  name   Specifies the identifier of the configuration           update.       version   Specifies the version of the configuration update.                 Sub-elements:       An optional list of imported files (cgha:import).       The software load definition. The cgha:softwareLoadDefinition element       identifies the software load on which the configuration is applied.       The optional cluster configuration initialization       (cgha:clusterConfiguration).       A list of component configuration information:       cgha:typeConfiguration       cgha:instanceConfiguration       cgha:assignmentConfiguration       cgha:removeInstance       cgha:removeAssignment                    
     [0629]                                                   E2   cgha:softwareLoadDefinition                          name   Specifies the identifier of the software load.           version   Specifies the version of the software load.                        
     [0630]                                                   E3   cgha:clusterConfiguration                          No attribute                             Sub-element:           An optional list of configuration values that, when defined           using cgha:init, specify the values of the attributes of the           objects that are configured.                        
     [0631]                                                   E4   cgha:typeConfiguration                          type   Specifies the fully qualified type name of the               component that is initialized. This component               type must be part of the associated software load.                         Sub-element:           An optional list of configuration values that, when defined           using cgha:init, specify the values of the attributes of the           objects that are configured.                        
     [0632]                                                   E5   cgha:instanceConfiguration                          name   Specifies the identifier of the instance.           type   Specifies the fully qualified type name of the               component that is initialized. This component               type must be part of the associated software               load. It is not necessary to specify the version               of the component, because it is not possible to               have multiple versions of the same component               in a software load.                         Sub-elements:           An optional list of SAP configuration (using the cgha:sap-           Configuration element). In an instance configuration, it is           only possible to configure SAPs that have an instance scope                        
     [0633]                                                   E6   cgha:assignmentConfiguration                          name   Specifies the identifier of the assignment.           type   Specifies the fully qualified type name of the               component that is initialized. This component               type must be part of the associated software load.                         Sub-elements:           An optional list of SAP configuration (using the cgha:sap-           Configuration element).                        
     [0634]                                                   E7   cgha:sapConfiguration                          name   Specifies the identifier of the SAP that is initialized.                         Sub-elements:           An optional list of configuration values that, when defined           using cgha:init, specify the values of the attributes of           the objects that are configured.                        
     [0635]                                                   E8   cgha:removeInstance                          name   Specifies the identifier of the instance to be removed.                         Sub-element: none                        
     [0636]                                                   E9   cgha:removeAssignment                          name   Specifies the identifier of the assignment to be removed.                         Sub-element: none                        
     [0637]                                   F1   cgha:platformUpdate                  name   Specifies the identifier of the platform update.       version   Specifies the version of the platform update.       configuration   Specifies whether the platform update configuration           is completely new configuration (the configuration           attribute is set to load) or an update of the           existing configuration (the configuration attribute           is set to update).                 Sub-elements:       An optional list of imported files (cgha:import).       An optional cgha:currentLoadDefinition element, which identifies       the current load that is part of the platform update.       An optional cgha:softwareLoadDefinition element, which identifies       the software load that is part of the Platform Update.       An optional list of cgha:configurationUpdateDefinition elements       which identify the configuration updates that are part of the       platform update.                    
     [0638]                                                   F2   cgha:currentLoadDefinition                          version   Specifies the version of the current load.                        
     [0639]                                                   F3   cgha:configurationUpdateDefinition                          name   Specifies the identifier of the configuration update.           version   Specifies the version of the configuration update.                        
     [0640]                                   F4   cgha:currentLoad                  version   Specifies the version of the current load.       platformUpdateName   Specifies the identifier of the current           platform update.       platformUpdateVersion   Specifies the version of the current platform           update.       softwareLoadName   Specifies the identifier of the current           software load.       softwareLoadVersion   Specifies the version of the current software           load.                 Sub-elements:       An optional list of imported files, using the cgha:import element.       These files contain the definition of the component types that are       used in the current load and the definition of interfaces that are       used in the cluster definition.       A specification of the version and update level of the cluster       configuration of the current load (cgha:currentCluster).       An optional list specifying the type, the version and the update       level of each component of the current load (cgha:currentType).       An optional list specifying the name, type and the update level of       each instance of the current load (cgha:currentInstance).       An optional list specifying the name, type and the update level of       each assignment of the current load (cgha:currentAssignment).                    
     [0641]                                   F5   cgha:currentCluster                  version   Specifies the version of the cluster configuration           definition.       updateLevel   Specifies the update level of the cluster           configuration.                 Sub-elements:       An optional list of provided interfaces. The cgha:provide element       defines the interface, including the versions used to defined the       cluster configuration. It is only possible to have interfaces       without operations and with solely configuration attributes       (configuration set to yes).       A MIB. The cgha:mib element defines the MIB that is associated with       the cluster configuration. To be able to create objects implementing       an interface in the MIB, the interface must be declared in the list       of provided interfaces. The version of the interface used to       instantiate objects in the MIB is the most recent version of the       interface that is provided, that is the version with the highest       version number.                    
     [0642]                                                   F6   cgha:currentType                          type   Specifies the fully qualified type name of the               component. Each component type specified must               have been previously defined and imported.           version   Specifies the version of the component.           updateLevel   Specifies the update level of the component               configuration.                         Sub-elements:           An optional list of cgha:init elements used to specify the intial           values of attributes.                        
     [0643]                                   F7   cgha:currentInstance                  name   Specifies the identifier of the instance.       type   Specifies the fully qualified type name of the           component type associated with the instance.       updateLevel   Specifies the update level of the instance           configuration.                 Sub-element:       An optional list of SAP configuration (defined using the cgha:sap-       Configuration element).                    
     [0644]                                   F8   cgha:currentAssignment                  name   Specifies the identifier of the assignment.       type   Specifies the fully qualified type name of           the component type associated with the assignment.       updateLevel   Specifies the update level of the assignment           configuration.                 Sub-elements:       An optional list of SAP configuration (defined using the cgha:sap-       Configuration element).                    
     [0645]                                   TABLE Eh2-1                                   Identif.   ELEMENT   versionMin   versionMax                          C2   cgha:use   Requ.   Requ.           C5   cgha:provide   Requ.   Requ.                        
     [0646]                           TABLE Eh2-2                       Identif.   ELEMENT   Version   UpdateLevel                  B1   cgha:interface   Required           B2   cgha:inherit   Required       B4   cgha:attribute   Optional       B9   cgha:parameter   Optional       B10   cgha:structure   Optional       B11   cgha:member   Optional       B12   cgha:enumeration   Optional       B14   cgha:objectReference   Required       B16   cgha:raise   Optional       B17   cgha:exception   Optional       B18   cgha:publish   Required       B19   cgha:event   Required       C1   cgha:component   Required       D1   cgha:softwareLoad   Required       D2   cgha:cluster   Required       D3   cgha:componentLoad   Required       E1   cgha:configurationUpdate   Required       E2   cgha:softwareLoadDefinition   Required       F1   cgha:platformUpdate   Required   Required       F2   cgha:currentLoadDefinition   Required   Required       F3   cgha:configurationUpdateDefinition   Required   Required       F4   cgha:currentLoad   Required   Required       F5   cgha:currentCluster   Required   Required       F6   cgha:currentType   Required   Required       F7   cgha:currentInstance   —   Required       F8   cgha:currentAssignment   —   Required                    
     [0647] Exhibit Eh3—Description of CGHA-ML  
     [0648] CGHA-ML is an example of an XML-based operational modeling language.  
     [0649] Eh3.0—XML  
     [0650] Generally, the XML syntax is defined in the XML specification available from W3C at http://www.w3.org/TR. The basic markup principle of XML is as follows:  
     [0651] consider the character string “TITLE” (hereinafter termed an identifier),  
     [0652] in an corresponding XML document, what is between “&lt;TITLE&gt;” and “&lt;/TITLE&gt;” is an “element”,  
     [0653] other data may be used to define what an element like “&lt;TITLE&gt;” may contain (including other nested elements, also called “sub-elements”), what attributes it may have. These other data may be separate, i.e. contained in a Document Type Definition (DTD), or have other formats, e.g. the one known as “XML schemas”.  
     [0654] In XML, a DTD follows the same markup principle as XML itself, however with slightly different syntax rules, and reserved words like #PCDATA. The DTD expressions are enclosed between “&lt;!XXXXX” and “&gt;”, where “XXXXX” is a DTD keyword, e.g. “ELEMENT”, and the rest is a name, followed with one or more other arguments or “sub-elements”. The expressions are case-sensitive. The DTD provides a formal definition of the elements with &lt;!ELEMENT . . . &gt;. Each ELEMENT may also have attributes, defined with the syntax &lt;!ATTLIST . . . &gt;). This defines the relationship among the data elements. An &lt;!ENTITY # . . . &gt; clause may be used to build a parameter entity for internal use in the DTD. Finally, comments are enclosed between “&lt;!-” and “—&gt;” markups.  
     [0655] Thus, the syntax of all elements of an OMSL may be defined in a DTD, a detailed example of which appears in Exhibit Eh1.  
     [0656] The main features of the exemplary DTD of will now be commented.  
     [0657] The labels added in the left column for each identifier of Exhibit Eh1 are used in this description and in the tables of Exhibit Eh2.  
     [0658] It will be appreciated that, in a DTD, many elements are interrelated, and may not be commented in all occurrences.  
     [0659] Eh3.1—Generic Constructs  
     [0660] The exemplary document type definition or DTD has generic constructs, used in common to all models.  
     [0661] Elements are characterized by an identifier. An identifier is a string of characters, which should be formed in accordance with specific rules (including naming rules). The identifiers of the DTD will now be considered in more detail.  
     [0662] At A 1 , the DTD has a cgha:description element, which may be used to provide a plain text description of the element in which it is located. Many elements in the DTD may have an optional description using cgha:description a sub-element. This will not be further commented.  
     [0663] An OMSL may be organized in independent documents, implemented as files in an underlying file system.  
     [0664] At label B 5 , the DTD has a cgha:init element which may be used to specify the initial values of attributes. The cgha:init element may also contain an optional list of other cgha:init elements; the list of initialization elements may be used to navigate into the contents of a “plural” entity, for example to initialize the members of a structure.  
     [0665] The usage of cgha:init, i.e. the initialization, may be done at multiple levels: interface definition level, component definition level, software load definition level, configuration update definition level. By default (final attribute set to “no”), it is possible to later overwrite the initialization. Setting final to yes at a given level in the sequence of processing:interface definition level/component definition level/software load definition level/configuration update definition level will prohibit later overwriting. Such a scheme builds a hierarchy of initializations. For example, a default value might be assigned to an attribute in the definition of the interface. This value might be overwritten in the definition of the component providing the interface, and this value might finally be updated in the configuration. If the final attribute is set to “yes”, the value cannot be overwritten thereafter.  
     [0666] An OMSL may provide defined types, which may be organized in packages, e.g. simple types and also new types. Simple types may include all or part of the usual “system” types of software entities, e.g. Boolean, Byte, Short, Int, Long, Float, Double, String, UnsignedByte, UnsignedShort, UnsignedInt, UnsignedLong.  
     [0667] These simple types may further be used in plural types, here:  
     [0668] structure (B 10 ), having members (B 11 );  
     [0669] enumeration (B 12 ), having values called enum Values (B 13 ).  
     [0670] Interface, used to specify services and managed objects provided by a component; e.g. cgha:interface  
     [0671] object reference, used to define references to objects, e.g. cgha:objectReference  
     [0672] Reference, used to define references to component instances or assignments, e.g. cgha:reference  
     [0673] Exception, used to specify exceptions that can be raised during invocations of operations, e.g. cgha:exception  
     [0674] Event, used to specify events in the OMSL, that are published by the software (platform and applications) running on the network element, e.g. cgha: event  
     [0675] Component, used to specify a component that is deployed on the platform, e.g. cgha:component  
     [0676] Each defined type is characterized by its type identifier and by the sub-elements it contains. The type identifier is defined by the type attribute of the element, and may be formed in accordance with specific naming rules. The exemplary DTD supports a single namespace for defined types. Thus, parsers may be used to check that type identifiers are unique within a software load model, that is, that no type definition overwrites another type definition.  
     [0677] When it is necessary to refer to a type from within another package, a fully qualified type name may be used, e.g. in the form of a concatenation of the package identifier and the type identifier.  
     [0678] The types may contain nested sub-elements, e.g. as defined in the exemplary DTD, while distinguishing whether these are optional, or required.  
     [0679] Types of an OMSL may be defined in a package e.g. by means of the cgha:package element, which appears at A 3  in the DTD. Thus, a given cgha: package is related to its own set of type definitions. In the exemplary CGHA-ML, the set comprises the following type definitions: cgha:interface, cgha:structure, cgha:objectReference, cgha:reference, cgha:enumeration, cgha:exception, cgha:event, cgha:component.  
     [0680] Each cgha:package may be specified as an independent file that may not contain anything other than that cgha:package element. The same package may be defined in more than one cgha:package element. The package is made up of all the types defined in all the cgha:package elements with that package name. Every type in a given package must have a different name (identifier) from every other type in the package.  
     [0681] Eh3.2—Interface Model  
     [0682] The interface model of the OMSL will now be described, with the exemplary syntax and semantics of each element which may be used in it.  
     [0683] The cgha: interface element (at B 1  in the DTD) may be used to specify the functionality provided by a component and to define the types of the objects that are instantiated in MIBs (Management Information Bases).  
     [0684] An OMSL may allow interfaces to be specialized, using inheritance, in order to add functionality. The cgha: inherit element (B 2 ) may be used to designate a base interface, if any, that the currently specified interface (then called the derived interface) inherits from. The ancestors of a derived interface are its base interface and the ancestors of that base interface. Only single inheritance is supported in the exemplary embodiment.  
     [0685] The cgha: constant element (B 3 ) is used to define constants in the scope of an interface.  
     [0686] The cgha: attribute element (B 4 ) defines the attributes that are part of an interface. An attribute is a field of the interface that holds data values. In the exemplary embodiment, versioning is supported at the interface definition level. It may be supported at the attribute definition level as well.  
     [0687] The cgha: operation element (B 6 ) defines the operations that are part of an interface specification. Several possibilities exist:  
     [0688] in the example, a oneway operation should not contain a reply description. It is also possible to define a oneway operation that contains no request parameters.  
     [0689] it is possible to define an rpc operation that contains reply parameters without having request parameters. It is also possible to define an rpc operation that contains no request parameters and no reply parameters.  
     [0690] exceptions can be triggered in order to provide out-of-band error support.  
     [0691] The cgha: request element (B 7 ) defines the request part of an operation. It may contain a list of one or more parameters (cgha:parameter; B 9 ). This list, when defined, specifies the parameters associated with the request.  
     [0692] The cgha:reply element (B 8 ) defines the reply part of an operation. It contains a list of one or more parameters (cgha:parameter; B 9 ), which specifies the parameters associated with the reply.  
     [0693] The cgha:structure element (B 10 ) is used to define structures. The cgha:member element (B 11 ) may be used to specify the members of structures, events and exceptions.  
     [0694] The cgha:enumeration element (B 12 ) is used to specify an enumeration type. It may contain a list of enumeration values, which specifies the possible values of the enumeration. Each member of the list may be specified using the cgha:enumValue element (B 13 ). In the example, the values associated with an enumeration are of type Int.  
     [0695] The cgha:objectReference element (B 14 ) is used to define references to objects. In the example:  
     [0696] the data related to a cgha:objectReference element may be initialized by means of the cgha:init element, with the reference attribute of the cgha:init element being set to object.  
     [0697] an object reference may be used as a type of a configuration attribute, only when configuration is set to “yes”. Thus, the cgha:object Reference element only supports references to objects that are in the same MIB as that containing the cgha:object Reference element itself.  
     [0698] The cgha: reference element (B 15 ) is used to define simple references to component instances or assignments. (In the examples, the references are dot-separated names; however, LDAP-like references may be used as well.  
     [0699] In the example:  
     [0700] data related to a cgha:reference element may be initialized using the cgha:init element.  
     [0701] if the referenced component is an instance, the reference attribute of the cgha:init element may be set to instance.  
     [0702] if the referenced component is an assignment, the reference attribute of the cgha:init element is set to assignment.  
     [0703] a reference may be used as a type of a configuration attribute only when configuration is set to “yes”.  
     [0704] For both the objectReference and the reference, dot-separated names are used in the example; however, other notations may be used as well, e.g. LDAP-like references.  
     [0705] The cgha:raise element (B 16 ) should be used to specify the exceptions that might be raised during the invocation of an operation. The cgha: exception element (B 17 ) is used to define an exception that can be generated during the invocation of an operation.  
     [0706] The cgha: publish element (B 18 ) is used to specify the events that might be published by objects implementing the currently defined interface.  
     [0707] The cgha: event element (B 19 ) may be used to specify the events that are handled by the network element software using the event mechanism of the underlying Software Platform. For members of events, the value of the map attribute should be set to “no”.  
     [0708] Eh3.3—Component Model  
     [0709] The Component model of the OMSL will now be described, with the exemplary syntax and semantics of each element which may be used in it.  
     [0710] The cgha: component element (C 1  in the DTD) may be used to define a component type. This definition may include the interfaces that are provided or used by the component, the events that are published by the component and the MIBs of the component.  
     [0711] The component type configuration is initialized to the proper values and partially finalized in order to avoid later overwriting. In the example, up to four SAPs (Service Access Points) may be defined in the component:  
     [0712] an instancemanagement SAP providing access to component instance management.  
     [0713] an assignmentManagement SAP providing access to component assignment management.  
     [0714] a log SAP providing log services.  
     [0715] a control SAP providing control of the log manager.  
     [0716] The cgha:use element (C 2 ) may be used to declare the versions of an interface that are used by a component. The cgha:type element (C 3 ) may be used to define a component type configuration. The cgha:sap element (C 4 ) may be used to define a service access point (SAP) in a component. The cgha:provide element (C 5 ) may be used to declare the versions of an interface that are provided through a SAP.  
     [0717] The cgha:mib element (C 6 ) defines a hierarchical naming tree describing the containment hierarchy of objects. It consists of a number of objects associated with the leaves and nexus of the naming tree. The cgha:mib element is used to define the MIB associated with its container. In the example, the cgha:mib element should always be contained within one of the following elements: cgha: sap, cgha: type, cgha: cluster  
     [0718] In the example, the name space provided by the MIB is local to its container (a SAP if the MIB is associated with a SAP, a component type if the MIB is associated with a component type, a cluster if the MIB is associated with the cluster). This means that the MIB itself does not need to be identified, and therefore does not have a name attribute. Each object is uniquely defined in a MIB by its full name, which describes the location of the object in the name space of the MIB. In other words, the MIB may provide the root of the naming context.  
     [0719] The cgha:context element (C 7 ) is used to define a new naming context in the MIB. The period character (.) may be used as the separator to concatenate names of the naming context tree into a single full name inside a MIB. In a given naming context, two different items (context or object) should not have the same identifier.  
     [0720] The cgha:object element (C 8 ) is used to declare an object inside a specific naming context of a MIB. Each object instantiates an already defined interface. The period character (.) is used as the separator to concatenate the full name of the naming context and the name of the object in order to obtain the full name of the object inside the MIB.  
     [0721] Eh3.4—Software Load Model  
     [0722] The Software Load model of the OMSL will now be described, with the exemplary syntax and semantics of each element which may be used in it.  
     [0723] The cgha: softwareLoad element (D 1 ) is used to specify a software load. In the exemplary embodiment, each cgha: softwareLoad element should be specified in an independent file.  
     [0724] The cgha:cluster element (D 2 ) may be used to define the cluster configuration MIB.  
     [0725] The cgha:componentLoad element (D 3 ) may be used to identify the components that are part of the software load. It supports initialization of configuration attributes of objects contained in the component type configuration MIB. This initialization may be used, for example, to select the OS (e.g. Solaris) packages that are required for a specific software load. The parser of the OMSL should ensure the consistency between the initialization clauses and the MIB.  
     [0726] Eh3.5—Configuration Update Model  
     [0727] The cgha:configurationUpdate element (E 1 ) is used to specify a configuration update. Each such element should be specified in an independent file.  
     [0728] When creating an instance or an assignment, the instance configuration or the assignment configuration should be used. The instance or assignment is referred to in the cluster configuration MIB.  
     [0729] The cgha:softwareLoadDefinition element (E 2 ) may be used to specify the software load configured in the configuration update or platform update.  
     [0730] The cgha:clusterConfiguration element (E 3 ) may be used to initialize configuration attributes of objects contained in the cluster configuration MIB. The parser should ensure the consistency between the initialization clauses and the MIB.  
     [0731] The cgha:typeConfiguration element (E 4 ) may be used to initialize configuration attributes of objects contained in the component type configuration MIB. The parser should ensure the consistency between the initialization clauses and the MIB.  
     [0732] The cgha:instanceConfiguration element (E 5 ) may be used to configure an instance of a component.  
     [0733] The cgha:assignmentConfiguration element (E 6 ) may be used to configure an assignment. In an assignment configuration, it is only possible to configure SAPs that have an assignment scope.  
     [0734] The cgha:sapConfiguration element (E 7 ) may be used to initialize configuration attributes in the MIB associated with the SAP. The parser should ensure the consistency between the initialization clauses and the MIB.  
     [0735] The cgha:removeInstance element (E 8 ) may be used to remove an instance that has been created previously. The cgha:removeAssignment element (E 9 ) may be used to remove an assignment that has been created previously.  
     [0736] Eh3.6—Platform Update Model  
     [0737] The cgha:platformUpdate element (F 1 ) may be used to specify a platform update. Each such element must be specified in an independent file. The software load defined in each configuration update should be the same as that defined in the platform update.  
     [0738] The OMSL parser may check that all attributes with a configuration attribute set to “yes” are initialized. The granularity of the configuration update may be the MIB. This means that if a MIB is created or modified, all the configuration attributes of that MIB must be initialized in one or more cgha:configurationUpdate elements. As indicated, a MM can be created or modified, using the instanceConfiguration, assignmentConfiguration, type-Configuration or clusterConfiguration elements.  
     [0739] Therefore in the case of an update of an existing configuration (configuration attribute set to update), all the configuration attributes of all the MIBs that have been updated must be initialized.  
     [0740] In the case of a completely new configuration (configuration attribute set to load), all the configuration attributes of all the MIBs that are defined in the software load should be initialized. These MIBs are the instance MIBs, the assignment MIBs, the component type configuration MIBs, and the cluster configuration MIB.  
     [0741] The cgha:currentLoadDefinition element (F 2 ) maybe used to specify the current load that is used in the platform update.  
     [0742] The cgha:configurationUpdateDefinition element (F 3 ) may be used to specify the configuration update that is used in the platform update.  
     [0743] The elements labelled F 4 , F 5 , F 6 , F 7 , F 8  are be generated by the Software Factory toolchain for its own use:  
     [0744] The cgha:currentLoad element (F 4 ) may be used to specify in an independent file the current load of a Network Element:component types, component instances, component assignments, and the cluster definition.  
     [0745] The cgha:currentCluster element (F 5 ) may be used to specify the version and the update level of cluster configuration.  
     [0746] The cgha:currentType element (F 6 ) may be used to configure the component type configuration MIB.  
     [0747] The cgha:currentInstance element (F 7 ) may be used to specify each instance of a current load. The cgha:currentInstance  
     [0748] The cgha:currentAssignment element (F 8 ) maybe used to specify each assignment of a current load.  
                               Exhibit Eh4 - Exemplary CGHA-ML code                                            Eh4 - 1 - attributes of the ComponentDescriptor interface           &lt;cgha:package name=“com.sun.cgha.types”&gt;           &lt;cgha:interface type=“ComponentDescriptor” version=“1”&gt;           &lt;cgha:attribute name=“componentCategory”           type=“com.sun.cgha.types.ComponentCategory”           mode=“R” configuration=“yes” /&gt;           &lt;cgha:attribute name=“availabilityDescriptor”           type=“com.sun.cgha.types.AvailabilityDescriptor”           mode=“R” configuration=“yes” /&gt;           &lt;cgha:attribute name=“packagingDescriptor”           type=“com.sun.cgha.types.PackagingDescriptor”           array=“yes” mode=“R” configuration=“yes” /&gt;           &lt;/cgha:interface&gt;           &lt;/cgha:package&gt;           Eh4-2:           &lt;cgha:enumeration type=“ComponentCategory”&gt;           &lt;cgha:enumValue name=“PROXY” value=“0” /&gt;           &lt;cgha:enumValue name=“PROXIED” value=“1” /&gt;           &lt;cgha:enumValue name=“STANDALONE” value=“2” /&gt;           &lt;/cgha:enumeration&gt;           Eh4-3           &lt;cgha:enumeration type=“RedundancyModel”&gt;           &lt;cgha:enumValue name=“HOT_RESTART” value=“0” /&gt;           &lt;cgha:enumValue name=“NON_HA” value=“1” /&gt;           &lt;cgha:enumValue name=“HA_2N” value=“2” /&gt;           &lt;cgha:enumValue name=“HA_N_PLUS_1” value=“3” /&gt;           &lt;/cgha:enumeration&gt;           Eh4-4           &lt;cgha:structure type=“AvailabilityDescriptor”&gt;           &lt;cgha:member name=“redundancyModel”           type=“com.sun.cgha.types.RedundancyModel” /&gt;           &lt;cgha:member name=“restartable” type=“Boolean” /&gt;           &lt;cgha:member name=“switchOverEscalationCount” type=“Int” /&gt;           &lt;cgha:member name=“switchOverEscalationTimeWindow” type=“Int” /&gt;           &lt;cgha:member name=“crimRequestResponseTimeOut” type=“Int” /&gt;           &lt;/cgha:structure&gt;           Eh4-5           &lt;cgha:structure type=“CreationDescriptor”&gt;           &lt;cgha:member name=“timeOut” type=“Int” /&gt;           &lt;cgha:member name=“binaryPath” type=“String” /&gt;           &lt;cgha:member name=“terminationTimeOut” type=“Int” /&gt;           &lt;cgha:member name=“userId” type=“Long” /&gt;           &lt;cgha:member name=“groupId” type=“Long” /&gt;           &lt;/cgha:structure&gt;           Eh4-6           &lt;cgha:enumeration type=“PackageType”&gt;           &lt;cgha:enumValue name=“DOCUMENTATION” value=“0” /&gt;           &lt;cgha:enumValue name=“DEVELOPMENT” value=“1” /&gt;           &lt;cgha:enumValue name=“RUNTIME” value=“2” /&gt;           &lt;/cgha:enumeration&gt;           &lt;cgha:structure type=“PackagingDescriptor”&gt;           &lt;cgha:member name=“platform” type=“String” /&gt;           &lt;cgha:member name=“os” type=“String” /&gt;           &lt;cgha:member name=“type” type=“com.sun.cgha.types.PackageType” /&gt;           &lt;cgha:member name=“packageNames” type=“String” array=“yes” /&gt;           &lt;/cgha:structure&gt;           &lt;cgha:structure type=“DeploymentDescriptor”&gt;           &lt;cgha:member name=“platform” type=“String” /&gt;           &lt;cgha:member name=“os” type=“String” /&gt;           &lt;/cgha:structure&gt;           EH4-10           &lt;cgha:package name=“com.sun.cgha.types”           xmlns:cgha=“http://www.sun.com/CGHA”&gt;           &lt;cgha:import href=“/com/sun/cgha/types/ComponentDescriptor.1.xml” /&gt;           &lt;cgha: interface type=“SoftwareComponentDescriptor” version=“1”&gt;           &lt;cgha:inherit type=“com.sun.cgha.types.ComponentDescriptor”           version=“1” /&gt;           &lt;cgha:attribute name=“creationDescriptor”           type=“com.sun.cgha.types.CreationDescriptor”           mode=“R” configuration=“yes”&gt;           &lt;cgha:init member=“userId” value=“0” /&gt;           &lt;cgha:init member=“groupId” value=“0” /&gt;           &lt;/cgha:attribute&gt;           &lt;cgha:attribute name=“deploymentDescriptor”           type=“com.sun.cgha.types.DeploymentDescriptor”           array=“yes” mode=“R” configuration=“yes” /&gt;           &lt;/cgha:interface&gt;           &lt;/cgha:package&gt;           Eh4-11           &lt;cgha:package name=“com.sun.cgha.types”           xmlns:cgha=“http://www.sun.com/CGHA”&gt;           &lt;cgha:import href=“/com/sun/cgha/types/ComponentDescriptor.1.xml” /&gt;           &lt;cgha:interface type=“HardwareComponentDescriptor” version=“1”&gt;           &lt;cgha:inherit type=“com.sun.cgha.types.ComponentDescriptor”           version=“1” /&gt;           &lt;/cgha:interface&gt;           &lt;/cgha:package&gt;           EH4-20           EH4-20-A           &lt;!--Component type description--&gt;           &lt;cgha:import           href=“/com/sun/cgha/types/SoftwareComponentDescriptor.1.xml” /&gt;           &lt;cgha:component type=“SoftwareComponentExample” version=“1”&gt;           &lt;cgha:description&gt;           . . .           &lt;/cgha:description&gt;           &lt;cgha:type&gt;           &lt;cgha:provide type=“com.sun.cgha.types.SoftwareComponentDescriptor”           minVersion=“1” maxVersion=“1”/&gt;           . . .           EH4-20-B           &lt;cgha:mib&gt;           &lt;cgha:object name=“componentDescriptor”           type=“com.sun.cgha.types.SoftwareComponentDescriptor”&gt;           . . . (initialization)           Eh4-20-C           &lt;cgha:init attribute=“componentCategory”           value=“STANDALONE” final=“yes” /&gt;           . . .           EH4-20-D           &lt;cgha:init attribute=“availabilityDescriptor” final=“yes”&gt;           &lt;cgha:init member=“redundancyModel” value=“HA_2N” /&gt;           &lt;cgha:init member=“restartable” value=“FALSE” /&gt;           &lt;cgha:init member=“switchOverEscalationCount” value=“0” /&gt;           &lt;cgha:init member=“switchOverEscalationTimeWindow” value=“1” /&gt;           &lt;cgha:init member=“crimRequestResponseTimeOut” value=“1” /&gt;           &lt;/cgha:init&gt;           . . .           Eh4-20-E           &lt;cgha:init attribute=“creationDescriptor” final=“yes”&gt;           &lt;cgha:init member=“timeOut” value=“1” /&gt;           &lt;cgha:init member=“binaryPath” value=“ . . . ” /&gt;           &lt;cgha:init member=“terminationTimeOut” value=“1” /&gt;           &lt;cgha:init member=“userId” value=“106573” /&gt;           &lt;cgha:init member=“groupId” value=“55” /&gt;           &lt;/cgha:init&gt;           . . .           Eh4-20-F           &lt;cgha:init attribute=“packagingDescriptor”&gt;           &lt;cgha:init key=“0”&gt;           &lt;cgha:init member=“platform” value=“common” /&gt;           &lt;cgha:init member=“os” value=“common” /&gt;           &lt;cgha:init member=“type” value=“RUNTIME” /&gt;           &lt;cgha:init member=“packageNames”&gt;           &lt;cgha:init key=“0” value=“PKGCOM1” /&gt;           &lt;/cgha:init&gt;           &lt;/cgha:init&gt;           &lt;cgha:init key=“1”&gt;           &lt;cgha:init member=“platform” value=“SPARC” /&gt;           &lt;cgha:init member=“os” value=“Solaris” /&gt;           &lt;cgha:init member=“type” value=“RUNTIME” /&gt;           &lt;cgha:init member=“packageNames”&gt;           &lt;cgha:init key=“0” value=“PKGSOL1” /&gt;           &lt;cgha:init key=“1” value=“PKGSOL2” /&gt;           &lt;/cgha:init&gt;           &lt;/cgha:init&gt;           &lt;cgha:init key=“2”&gt;           &lt;cgha:init member=“platform” value=“SPARC” /&gt;           &lt;cgha:init member=“os” value=“ChorusOS” /&gt;           &lt;cgha:init member=“type” value=“RUNTIME” /&gt;           &lt;cgha:init member=“packageNames”&gt;           &lt;cgha:init key=“0” value=“PKGCHO1” /&gt;           &lt;cgha:init key=“1” value=“PKGCHO2” /&gt;           &lt;/cgha:init&gt;           &lt;/cgha:init&gt;           &lt;/cgha:init&gt;           . . .           Eh4-21 - How to Use the instanceManagement SAP           &lt;cgha:sap name=“instanceManagement” scope=“instance”&gt;           &lt;cgha:description&gt;           This SAP gives access to the mandatory MIB that           must be associated with each component instance.           &lt;/cgha:description&gt;           &lt;cgha:provide type=“com.sun.cgha.types.management.Instance”           minVersion=“1” maxVersion=“1” /&gt;           &lt;cgha:mib&gt;           &lt;cgha:object type=“com.sun.cgha.types.management.Instance”&gt;           &lt;/cgha:object&gt;           &lt;/cgha:mib&gt;           &lt;/cgha:sap&gt;           &lt;/cgha:component&gt;           &lt;/cgha:package&gt;           Eh4-30           &lt;cgha:package name=“com.sun.cgha.types.management”           xmlns:cgha=“http://www.sun.com/CGHA”&gt;           . . .           &lt;cgha:enumeration type=“UsageState”&gt;           &lt;cgha:enumValue name=“IDLE” value=“0” /&gt;           &lt;cgha:enumValue name=“ACTIVE” value=“1” /&gt;           &lt;cgha:enumValue naMe=“BUSY” value=“2” /&gt;           &lt;/cgha:enumeration&gt;           &lt;cgha: interface type=“Assignment” version=“1” singleton=“yes”&gt;           &lt;cgha:attribute name=“usage”           type=“com.sun.cgha.types.management.UsageState”           mode=“R” /&gt;           &lt;/cgha:interface&gt;           . . .           &lt;/cgha:package&gt;           EH4-31 - How to use the assignmentManagement SAP           &lt;!--Generic management types--&gt;           &lt;cgha:import href=“/com/sun/cgha/types/management/Assignment.1.xml” /&gt;           &lt;cgha:component type=“SoftwareComponentExample” version=“1”&gt;           . . .           &lt;cgha:sap name=“assignmentManagement” scope=“assignment”&gt;           &lt;cgha:description&gt;           This SAP provides access to the MO associated with assignments.           &lt;/cgha:description&gt;           . . .           &lt;cgha:provide type=“com.sun.cgha.types.management.Assignment”           minVersion=“1” maxVersion=“1” /&gt;           &lt;cgha:mib&gt;           &lt;cgha:object type=“com.sun.cgha.types.Assignment”&gt;           &lt;cgha:description&gt;           The usage state of a component.           &lt;/cgha:description&gt;           &lt;/cgha:object&gt;           &lt;/cgha:mib&gt;           &lt;/cgha:sap&gt;           . . .           &lt;/cgha:component&gt;                      
 
     [0749] Exhibit Eh5—Tables related to the MIBs and SAPs  
               TABLE Eh5-1                       The Component Type Configuration MIB                                        Mandatory   componentDescriptor       object name       Related   com.sun.cgha.types.ComponentSoftwareDescriptor       object type   or           com.sun.cgha.types.ComponentHardwareDescriptor           Both of these types inherit from:           com.sun.cgha.types.ComponentDescriptor       Attributes   com.sun.cgha.types.ComponentDescriptor:       (and type)   componentCategory (enum type).           availabilityDescriptor (structure).           packagingDescriptor (array of structures).           com.sun.cgha.types.SoftwareComponentDescriptor:           creationDescriptor (structure).           deploymentDescriptor (array of structures).           com.sun.cgha.types.HardwareComponent Descriptor.           No specific attributes found.                  
 
     [0750]               TABLE Eh5-2                       The instanceManagement SAP and its MIB                                                Mandatory   (None: singleton interface)           object name           Related   com.sun.cgha.types.management.Instance           object type           Attributes   (optional)           (and type)           Corresponding   instanceManagement           mandatory SAP                        
     [0751]               TABLE Eh5-3                       The assignmentManagement SAP and its MIB                                        Mandatory object name   (None: singleton interface)       Related object type   com.sun.cgha.types.management.Assignment       Attributes (and type)   usage (enum type).           This is runtime information exposed to           remote clients.       Corresponding   assignmentManagement       mandatory SAP                    
     [0752]               TABLE Eh5-4                          Attributes of the ComponentDescriptor Interface Type                     Attribute   Description               componentCategory   Provides configuration type information           required by the CRIM.       availabilityDescriptor   Provides availability information required           by the CRIM:           The redundancy model of the component.           The switch-over escalation count and           time window.           The time out for a component to respond           to a CRIM request.           Definition of whether the component is           restartable or not.       packagingDescriptor   Provides packaging description required           by the SLBT (via the ml2swload tool).                    
     [0753] Exhibit Eh6—Mapping from CGHA-ML-Exemplary Tables  
               TABLE Eh6-1                          Mapping CGHA-ML Name Tokens to Java MBeans                         CGHA-ML   CGHA-ML           Construct   Identifier   Mapping to Java MBeans               Package   thispackage   com.sun.thispackage       Type   ThisClass   ThisClass       Operation   thisMethod   thisMethod       (Generated       ThisClass.ThisMethodReply       return type)       Attribute   thisAttribute   getThisAttribute       with read       access       Attribute   thisAttribute   setThisAttribute       with write       access       Constant   THIS_CONSTANT   THIS_CONSTANT       Enumeration   ENUM_VALUE   ENUM_VALUE       value                  
 
     [0754]               TABLE EH6-2                          Mapping CGHA-ML Name Tokens to RPC and C                         CGHA-ML   CGHA-ML           Construct   Identifier   Mapping to RPC and C               Package   thispackage   (not mapped)       Type   ThisClass   this_class (prefix)       Operation   thisMethod   this_class_this_method       (Generated       this_class_this_method_reply       return type)       Attribute   thisAttribute   this_class_get_this_attribute       with read       access       Attribute   thisAttribute   this_class_set_this_attribute       with write       access       Constant   THIS_CONSTANT   THIS_CONSTANT       Enumeration   ENUM_VALUE   ENUM_VALUE       value                    
     [0755]               TABLE Eh6-3                          Mapping CGHA-ML Name Tokens to LDAP                                 CGHA-ML   CGHA-ML               Construct   Identifier   Mapping to LDAP                       Package   thispackage   com-sun-                   thispackage           Type   ThisClass   com-sun-this-                   package-ThisClass           Attribute   thisAttr   com-sun-this-package-                   ThisClass-n-thisAttr (*)                                    
     [0756] Exhibit Eh7 
                                  Eh7-0 - LDAP layout               software load &lt;−− software load definition                         version                         dn                 platform update &lt;−− platform update definition                         version                         table                 cluster &lt;−− cluster configuration                         version                         update level                         mib                 types                         component type &lt;−− component type configuration                         version                         update level                         mib                 ...       instances                         component instance &lt;−− component instance configuration                         sap                         version                         update level                         mib                 ...       ...       assignments                         component assignment &lt;−− component assignment configuration                         sap                         version                         update level                         mib                 ...       ...               Eh7- O - LDAP object classes               Eh7-O1 (cgha-attribute--oc)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-attribute-name-oid       NAME ‘cgha-attribute-name’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 # Directory String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: objectclasses       objectclasses: ( cgha-attribute--oc-oid       NAME ‘cgha-attribute--oc’       SUP top       MUST ( cgha-attribute-name ) )       Eh7-O2 (cgha-member--oc)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-member-name-oid       NAME ‘cgha-member-name’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: objectclasses       objectclasses: ( cgha-member--oc-oid       NAME ‘cgha-member--oc’       SUP top       MUST ( cgha-member-name ) )       Eh7-O3 (cgha-element--oc)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-key-oid       NAME ‘cgha-key’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: objectclasses       objectclasses: ( cgha-element--oc-oid       NAME ‘cgha-element--oc’       SUP top MUST ( cgha-key ) )       Eh7-O4 (cgha-structure--oc)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-structure-type-oid       NAME ‘cgha-structure-type’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 # IA5 String       SINGLE-VALUE)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-structure-version-oid       NAME ‘cgha-structure-version’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 # IA5 String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: objectclasses       objectclasses: ( cgha-structure--oc-oid       NAME ‘cgha-structure--oc’       SOP top       MUST ( cgha-structure-type )       MAY ( cgha-structure-version ) )       Eh7-O5 (cgha-object-reference--oc)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-object-reference-type-oid       NAME ‘cgha-object-reference-type’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 # IA5 String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-object-reference-version-oid       NAME ‘cgha-object-reference-version’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 # IA5 String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-object-reference-mib-dn-oid       NAME ‘cgha-object-reference-mib-dn’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 # IA5 String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-object-reference-full-name-oid       NAME ‘cgha-object-reference-full-name’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 # IA5 String       SINGLE-VALUE)       dn: cn=schema       changetype: modify       add: objectclasses       objectclasses: ( cgha-object-reference--oc-oid       NAME ‘cgha-object-reference--oc’       SUP top       MUST ( cgha-object-reference-type $       cgha-cgha-object-reference-version $       cgha-cgha-object-reference-mib-dn $       cgha-cgha-object-reference-full-name ) )       Eh7-O6 (cgha-reference--oc)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-reference-type-oid       NAME ‘cgha-reference-type’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 # IA5 String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-reference-dn-oid       NAME ‘cgha-reference-dn’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 # IA5 String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: objectclasses       objectclasses: ( cgha-reference--oc-oid       NAME ‘cgha-reference--oc’       SUP top       MUST ( cgha-reference-type $       cgha-reference-dn ) )       Eh7-O7 (cgha-object--oc)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-object-name-oid       NAME ‘cgha-object-name’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 # Directory String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: objectclasses       objectclasses: ( cgha-object--oc-oid       NAME ‘cgha-object--oc’       SUP top       MUST ( cgha-object-name ) )       Eh7-O8 (cgha-interface--oc)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-interface-type-oid       NAME ‘cgha-interface-type’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 # IA5 String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-interface-version-oid       NAME ‘cgha-interface-version’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 # IA5 String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: objectclasses       objectclasses: ( cgha-interface--oc-oid       NAME ‘cgha-interface--oc’       SUP top       MUST ( cgha-interface-type $ cgha-interface-version ) )       Eh7-O9 (cgha-context--oc)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-context-name-oid       NAME ‘cgha-context-name’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 # Directory String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: objectclasses       objectclasses: ( cgha-context--oc-oid       NAME ‘cgha-context--oc’       SUP top       MUST ( cgha-context-name ) )       Eh7-O10 (cgha-cluster-version--oc)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-cluster-version-oid       NAME ‘cgha-cluster-version’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 # Directory String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: objectclasses       objectclasses: ( cgha-cluster-version--oc-oid       NAME ‘cgha-cluster-version--oc’       SUP top       MUST ( cgha-cluster-version ) )       Eh7-O11 (cgha-cluster-update-level--oc)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-cluster-update-level-oid       NAME ‘cgha-cluster-update-level’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 # Directory String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: objectclasses       objectclasses: ( cgha-cluster-update-level--oc-oid       NAME ‘cgha-cluster-update-level--oc’       SUP top       MUST ( cgha-cluster-update-level ) )       Eh7-O12 (cgha-component-type--oc)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-component-type-oid       NAME ‘cgha-component-type’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 # Directory String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: objectclasses       objectclasses: ( cgha-component-type--oc-oid       NAME ‘cgha-component-type--oc’       SUP top       MUST ( cgha-component-type ) )       Eh7-O13 (component-type-version--oc)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-component-type-version-oid       NAME ‘cgha-component-type-version’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 # Directory String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: objectclasses       objectclasses: ( cgha-component-type-version--oc-oid       NAME ‘cgha-component-type-version--oc’       SUP top       MUST ( cgha-component-type-version ) )       Eh7-O14 (cgha-component-type-update-level--oc)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-component-type-update-level-oid       NAME ‘cgha-component-type-update-level’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 # Directory String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: objectclasses       objectclasses: ( cgha-component-type-update-level--oc-oid       NAME ‘cgha-component-type-update-level--oc’       SUP top       MUST ( cgha-component-type-update-level ) )       Eh7-O15 (cgha-component-instance-name--oc)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-component-instance-name-oid       NAME ‘cgha-component-instance-name’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 # Directory String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: objectclasses       objectclasses: ( cgha-component-instance-name--oc-oid       NAME ‘cgha-component-instance-name--oc’       SUP top       MUST ( cgha-component-instance-name $       cgha-component-type ) )       Eh7-O16 (cgha-component-instance-update-level--oc)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-component-instance-update-level-oid       NAME ‘cgha-component-instance-update-level’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 # Directory String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: objectclasses       objectclasses: ( cgha-component-instance-update-level--oc-oid       NAME ‘cgha-component-instance-update-level--oc’       SUP top       MUST ( cgha-component-instance-update-level ) )       Eh7-O17 (cgha-component-assignment-name--oc)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-component-assignment-name-oid       NAME ‘cgha-component-assignment-name’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 # Directory String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: objectclasses       objectclasses: ( cgha-component-assignment-name--oc-oid       NAME ‘cgha-component-assignment-name--oc’       SUP top       MUST ( cgha-component-assignment-name $       cgha-component-type ) )       Eh7-O18 (cgha-component-assignment-update-level--oc)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-component-assignment-update-level-oid       NAME ‘cgha-component-assignment-update-level’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 # Directory String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: objectclasses       objectclasses: ( cgha-component-assignment-update-level--oc-oid       NAME ‘cgha-component-assignment-update-level--oc’       SUP top       MUST ( cgha-component-assignment-update-level ) )       Eh7-O19 (cgha-sap-name--oc)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-sap-name-oid       NAME ‘cgha-sap-name’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 # Directory String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-sap-access-oid       NAME ‘cgha-sap-access’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 # Directory String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: objectclasses       objectclasses: ( cgha-sap-name--oc-oid       NAME ‘cgha-sap-name--oc’       SUP top       MUST ( cgha-sap-name $       cgha-sap-access ) )       Eh7-O20 (cgha-platform-update-version--oc)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-platform-update-version-oid       NAME ‘cgha-platform-update-version’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 # Directory String       SINGLE-VALUE)       dn: cn=schema       changetype: modify       add: objectclasses       objectclasses: ( cgha-platform-update-version--oc-oid       NAME ‘cgha-platform-update-version--oc’       SUP top       MUST ( cgha-platform-update-version ) )       Eh7-O21 (cgha-update-level--oc)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-update-level-oid       NAME ‘cgha-update-level’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 # DN       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-updated-oid       NAME ‘cgha-updated’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 # IA5 String       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-update-level-dn-oid       NAME ‘cgha-update-level-dn’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 # DN       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: objectclasses       objectclasses: ( cgha-update-level--oc-oid       NAME ‘cgha-update-level--oc’       SUP top       MUST ( cgha-update-level       $ cgha-update-level-dn       $ cgha-updated ) )       Eh7-O22 (cgha-software-load-version--oc)       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-software-load-version-oid       NAME ‘cgha-software-load-version’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: attributetypes       attributetypes: ( cgha-platform-update-dn-oid       NAME ‘cgha-platform-update-dn’       SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 # DN       SINGLE-VALUE )       dn: cn=schema       changetype: modify       add: objectclasses       objectclasses: ( cgha-software-load-version--oc-oid       NAME ‘cgha-software-load-version--oc’       SUP top MUST ( cgha-software-load-version       $ cgha-platform-update-dn ) )                  
 
     [0757] Exhibit Eh8—Tables Related to LDAP Mapping  
                       TABLE Eh8-T0                       LDAP Syntax   LDAP Code   Definition                  IA5 String   1.3.6.1.4.1.1466.115.121.1.26   values are               case sensitive       Directory String   1.3.6.1.4.1.1466.115.121.1.15   values are not               case sensitive       Distinguished   1.3.6.1.4.1.1466.115.121.1.12   values are DNs       Name                  
 
     [0758]                           TABLE Eh8-T11                                   OMSL Attribute types   LDAP                                                1   Simple   LDAP attribute       2   Simple (array)   LDAP attribute designating an object class           array items   sub-entries instantiating the object class       3   Enum   LDAP attribute designating an object                class + instance(s) of that object class       4   Structure   See table Eh8-T12                    
     [0759]                           TABLE Eh8-T12                                   OMSL   LDAP                                                1   cgha:interface   LDAP object class               (named along id-mapping rules)           attributes   see table Eh8-T11       2   cgha:member           simple   LDAP attribute           others   see table Eh8-T11       3   cgha:structure   LDAP object class               (named along id-mapping rules)           structure members   see cgha:member       4   cgha:objectReference   LDAP object class               (named along id-mapping rules)       5   cgha:reference   LDAP object class               (named along id-mapping rules)                    
     [0760] Exhibit Eh9 
                                  Eh9-A       &lt;cgha:package name=“com.sun.cgha.container.bootServer”&gt;       &lt;cgha:component type=“BootServer” version=“1”&gt;       &lt;cgha:type&gt;       &lt;cgha:mib&gt;       &lt;cgha:object name=“componentDescriptor”       type=“com.sun.cgha.types.SoftwareComponentDescriptor”&gt;       &lt;cgha:init .../&gt;       ...       &lt;/cgha:object&gt;       &lt;/cgha:mib&gt;       &lt;/cgha:type&gt;       &lt;/cgha:component&gt;       &lt;/cgha:package&gt;       Eh9-B       dn: cgha-object-name=componentDescriptor,       cgha-component-type-update-level=1,       cgha-component-type-version=1,       cgha-component-type=com.sun.cgha.container.bootServer.BootServer,       ou=types, o=cgha_root