WO2002044896A1 - Improved manageable object oriented software environment - Google Patents

Improved manageable object oriented software environment Download PDF

Info

Publication number
WO2002044896A1
WO2002044896A1 PCT/IB2000/001782 IB0001782W WO0244896A1 WO 2002044896 A1 WO2002044896 A1 WO 2002044896A1 IB 0001782 W IB0001782 W IB 0001782W WO 0244896 A1 WO0244896 A1 WO 0244896A1
Authority
WO
WIPO (PCT)
Prior art keywords
class
language
code
cim
manageable
Prior art date
Application number
PCT/IB2000/001782
Other languages
French (fr)
Inventor
Christophe Ebro
Pascal Bresson
Original Assignee
Sun Microsystems, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Microsystems, Inc. filed Critical Sun Microsystems, Inc.
Priority to AU2001215432A priority Critical patent/AU2001215432A1/en
Priority to PCT/IB2000/001782 priority patent/WO2002044896A1/en
Publication of WO2002044896A1 publication Critical patent/WO2002044896A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/51—Source to source

Definitions

  • This invention generally relates to computer technology, more particularly to manageable object oriented software environments .
  • CIM Common Information Model
  • MOF Managed Object Format
  • modeling languages like the MOF language aim to be purely descriptive, without implementation reference, even if they look like real programming language. This raises problems when implementing the model to real executable code using a given programming language.
  • a general aim of the present invention is to bring a solution to these problems.
  • JDMK Java Dynamic Management Kit
  • JMX Java Management extensions
  • Another purpose of this invention is to enable direct conversion of a management oriented modeling language into manageable executable code, using manageable objects, e.g. into JDMK/JMX manageable executable code, using the known MBean objects.
  • Still another purpose of this invention is to enable a translation or mapping between items of the management oriented modeling language and the manageable executable code.
  • a software development system comprising:
  • At least one software module capable of at least partially converting available code in a first language into executable code based on such manageable software objects.
  • This invention also offers a method of developing software, comprising the following steps :
  • This invention also encompasses a software code, having manageable software objects, adapted to at least partially converting available code in a first language into executable code based on such manageable software objects.
  • FIG. 1 is a general diagram of a computer system in which the invention is applicable;
  • - figure 2 is a general diagram of an object-oriented software environment in a computer system
  • - figure 3 is a partial diagram of an object software system in which this invention may be applicable
  • FIG. 4A is a partial diagram of a structure to handle an object in object oriented descriptive language in an object in manageable executable code according to the invention
  • FIG. 4B is a partial diagram of an object in object oriented descriptive language, and of its instanciation in accordance with the invention.
  • FIG. 5 is a flow chart showing a structure of an object constructor to process object oriented descriptive elements into elements of an executable language
  • FIG. 6 is the continuation of the flow chart figure 5 showing a structure of an object constructor adapted to process object oriented descriptive elements into elements of an executable language;
  • FIG. 7 is a flow chart showing how to check method constraint from object oriented descriptive language to executable language.
  • FIG. 8 represents an HashMap structure of use in an embodiment of the invention.
  • Sun, Sun Microsystems, Solaris, Java, EmbeddedJava, PersonalJava, JavaBeans, Java Naming and Directory Interface, JDBC, Enterprise JavaBeans, Jini and Sun Spontaneous Management are trademarks of Sun Microsystems, Inc.
  • SPARC is a trademark of SPARC International, Inc.
  • Exhibit 1 describes the auxiliary classes JdmkCimQualifier, CimMBeanlnfo, CimMBean, the main CIM representing class, and a java code structure for CIM methods.
  • Exhibit 2 exposes tables of CIM items and the correspondence between CIM data types and java data types.
  • Exhibit 3 describes an exemplary package, in the form of a java package for handling CIM items in java classes.
  • ⁇ Classname> may be used to designate a value of the entity Classname (or "Classname” ) .
  • the notation is the usual one, in accordance with the rules of writing code.
  • the dot notation is used as necessary, for example: "com. sun. jmx.cim" .
  • class is a generic description, which may comprise “properties”, “methods” and, e.g. in java language, "parameters”.
  • a class may be used to generate as many objects ("class instances") as desired, each having a different name.
  • a class may also "extend” a parent class (often termed "superclass”).
  • This invention may apply in a computer system, or in a network comprising computer systems.
  • the hardware of such a computer system is for example as shown in Fig. 1, where:
  • - 11 is a processor, e.g. an Ultra-Sparc (SPARC is a Trademark of SPARC International Inc);
  • - 12 is a program memory, e.g. an EPROM for BIOS;
  • - 13 is a working memory, e.g. a RAM of any suitable techno- logy (SDRAM for example);
  • SDRAM techno- logy
  • - 14 is a mass memory, e.g. one or more hard disks;
  • - 15 is a display, e.g. a monitor
  • - 16 is a user input device, e.g. a keyboard and/or mouse; and - 21 is a network interface device connected to a communication medium 20, itself in communication with other computers.
  • Network interface device 21 may be an Ethernet device, a serial line device, or an ATM device, inter alia.
  • Medium 20 may be based on wire cables, fiber optics, or radio-communi- cations, for example.
  • bus systems may often include a processor bus, e.g. of the PCI type, connected via appropriate bus bridges to e.g. an ISA bus and/or an SCSI bus.
  • processor bus e.g. of the PCI type
  • bus bridges e.g. an ISA bus and/or an SCSI bus.
  • FIG 2 the CPU and hardware of figure 1 is diagrammati- cally shown as 1.
  • the computer system also has an operating system 3, e.g. Solaris (an operating system product and trademark of SUN MICROSYSTEMS). Operating systems other than Solaris may be used in accordance with this invention.
  • An object supporting software 4 may be installed over operating system 3.
  • the object supporting software 4 may e.g. include the necessary software to build a java virtual machine or JVM. It includes an object processor or object provider 41, e.g. the method ClassLoader( ) of the Java language.
  • the object supporting software 4 may then serve to run object oriented application software 5.
  • changes in object oriented application software 5 may be made using software management tools 6.
  • the software management tools may be designed in accordance with the JMX/JDMK specification. However, the invention may apply to other software management tools as well.
  • the invention may apply within a single machine as shown in figure 2. However it will more likely be applied within a distributed environment, as shown in figure 3, in the example of two machines Ml and M2, interconnected by a link 20, e.g. a network medium.
  • the machines may have the exemplary structure of figure 1, or any equivalent structure.
  • the blocks showing the same functions as in figure 2 are identified by the same reference number, immediately followed by the machine identifier.
  • the operating system of machine Ml is noted 3M1.
  • an exemplary architecture may include the object oriented application software 5M1 in machine Ml, and the software management tools 6M2 in machine M2, which thus may be dedicated to software management.
  • Provision for a management dedicated machine is an option.
  • One or more machines may include both application software and management tools, as shown in figure 2. Also, each machine may support one or more java virtual machines or other types of machines or devices.
  • an "object” may comprise, as known, properties and methods, together termed [object] members.
  • object will be used essentially to designate a property. For convenience, the methods are usually identified by their name followed with ( ) . One or more parameters of the method may be inserted between the two round brackets, as necessary.
  • Accessor methods are methods used to read and/or write in an object.
  • a reading method like get ( ) is usually named getter method.
  • a writing method like set ( ) is usually named setter method.
  • JavaBeans More details on specific java objects named JavaBeans may be found at: http: //Java. sun. com/beans/spec . html and/or in the corresponding printed documentation.
  • JDMK Java Dynamic Management Kit
  • JMX Java Management extensions
  • the JDMK may use the well known JavaBeans object classes. It may also use managed beans or MBeans, as described e.g. in JMX. More details on the JMX specification may be found at: http: //Java. sun. co /products/JavaMana ement and/or in the corresponding printed documentation.
  • An MBean is a manageable object implementing a management interface.
  • An MBean may contain accessor methods, e.g. get ⁇ name> ( ) and/or set ⁇ name> ( ) .
  • Such getter and/or setter methods define an "attribute" named ⁇ name> .
  • the getter and/or setter methods of an attribute are generically named "getter/setter pair", even if only a getter method or only a setter method is present for that attribute.
  • an MBean may be a standard MBean or a dynamic MBean:
  • an object in JMX, an object is a standard MBean if its class ⁇ Myclass> . implements an interface ⁇ Myclass>MBean , which declares the manageable methods of the object.
  • the correspondence between the names ⁇ Myclass> and ⁇ Myclass>MBean is called a naming rule or "design pattern".
  • Other more sophisticated rules may apply, e.g. when ⁇ Myclass> does not itself implement an interface ⁇ Myclass>MBean, but a parent class of ⁇ Myclass> does .
  • an object in JMX, an object is a dynamic MBean if it has an internal getMBeanInfo ( ) method, which may return an MBeanlnfo object, containing the methods of its management interface.
  • the management methods are predefined in a rigid management interface (the corresponding ⁇ Myclass>MBean ) , and therefore may not evolve at runtime.
  • the getMBeanlnfof ) method and MBeanlnfo object of a dynamic MBean define a generic interface at an upper level, which is applicable to a variety of objects and is therefore more flexible at any time, including runtime.
  • the Common Information Model is a joint effort from various actors of software industry to propose an information model for system management.
  • the CIM is a sub-committee of the Distributed Management Task Force (DMTF).
  • DMTF Distributed Management Task Force
  • Detailed information on CIM may be found inter alia in the following documents, available from the DMTF as hard copies or on the web site DMTF. org:
  • CIM Common Information Model
  • MOF Managed Object Format
  • this field also includes the so-called “CIM/WBEM manager APIs” (WBEM, standing for Web Based
  • CIM/WBEM manager APIs handles metadata from CIM/MOF language to executable code e.g. java code.
  • CIM/WBEM manager APIs or WBEM SDK represent CIM objects as java classes and manipulate them as Java beans.
  • a CIM object is a computer representation or model of a managed resource, such as a printer, disk drive, or CPU.
  • Standard CIM objects, complying with the CIM-2.1 Specification, may be modeled using the CIM/WBEM manager APIs, which comprises the WBEM Software Development Kit, and its CIM- directed Object Manager.
  • MOF eta- code starting from MOF eta- code:
  • Programmers then can use the corresponding Java interfaces to describe managed objects, and retrieve information about managed objects in a particular system environment. This information is retrieved thanks to CIM-MOF requests adapted to be handled by the java server or thanks to java requests directly handled by the java server.
  • CIM-MOF requests adapted to be handled by the java server
  • java requests directly handled by the java server.
  • a more detailed object of this invention is to offer advances in generating target executable code (in a "second language"), e.g. java code, that can be more closely integrated within the JMX management framework.
  • target executable code in a "second language”
  • the code provided in MOF may be designated as "metacode”, indicating that the MOF code is an upper language level, in comparison with the executable code as used, e.g. java code.
  • another formal language than MOF language may be used in accordance with the invention.
  • the invention may be used with another manageable executable code than java code.
  • CIM entities are in capital letters
  • JDMK entities are in italics.
  • the figures show a non limiting example of application according to the invention using MOF language and java code.
  • a CIM/MOF Parser may be used to read the MOF metacode file, e.g. sequentially, while identifying coherent portions of the MOF metacode. Such portions may then be transmitted to a JDMK object constructor (J-CONS) .
  • the object constructor (J-CONS) may first check MOF items. Then, it may build manageable java objects (e.g. MBeans) with their corresponding accessors, thus serving both to generate object defini- tions (class generator), and to generate object instances from such classes.
  • Such java objects constitute executable code, or, at least, may be used to generate executable code (J-EXE), which is manageable through the JDMK object manager (J-OM) .
  • management oriented requests may be applied to the server, e.g. JDMK management oriented requests (J-REQ), comprising JDMK object manager, to retrieve information on a designed MBean .
  • a programmer may use management oriented CIM/MOF requests (C-REQ) to gain access to a designed MBean and the JDMK object manager via the different elements linking CIM/MOF metacode to executable code. This possibility is symbolized with dotted arrows.
  • C-REQ management oriented CIM/MOF requests
  • CIM rules 901 represents the applicable rules in an information model for system management, CIM in the example.
  • Other information model for system management may be used according to the invention, whether directly enabling generation of executable code, or not.
  • the basic CIM items are a CIM class, or a property, a method, a method parameter in a CIM class.
  • the CIM objects may include e.g.:
  • REFERENCE (a unique name given to a CIM instance, e.g. for building ASSOCIATIONS),
  • MOF tools 902 represents available tools in an object oriented descriptive language, MOF in the example.
  • object oriented descriptive language may be used according to the invention.
  • the CIM-MOF basically uses object characterizing data, named "qualifiers".
  • a qualifier may be viewed as a container for information data about an object item.
  • Each qualifier has: - a type (e.g. boolean or string);
  • scope i.e. the list of CIM objects it may apply to (e.g. "class”, “property”);
  • CIM supports two levels of qualifiers:
  • instance qualifiers which may additionally apply to a particular instance of a class.
  • mapping rules between the MOF and MBean formalisms, in the example.
  • the invention uses one or more auxiliary classes to this effect.
  • Other structures mapping rules and classes may be defined between other object oriented descriptive languages and manageable executable codes according to the invention.
  • a first auxiliary class CAl may be used for providing other object characterizing data, e.g. qualifier data. Its members are the information to be returned when requiring object characterizing data in an object oriented descriptive language, e.g. qualifier data in a CIM message; corresponding accessor methods are provided for.
  • the CAl class may be e.g. the JdmkCimQual ⁇ fier class, as shown with label CAl" in Exhibit 1, which corresponds to import 3.12 in Exhibit 3.
  • all the members of the CAl class are written as text characters (i.e. have the string type).
  • This enables to put them in the form of XML messages, when required instead of in a object oriented descriptive language, e.g. MOF text files (XML, standing for extended Markup Language, is described inter alia in the web site http: //www.w3. orq/TR/REC-xml, or in the booklet "XML Pocket Reference", Robert ECKSTEIN, O'REILLY, U.S.A, October 1999).
  • object characterizing data e.g. a CIM qualifier (in a CIM class or CIM instance) may be represented by an instance of the CAl class.
  • a qualifier named ⁇ item> may be represented by a JdmkCi ⁇ item> instance of the JdmkCimQualifier class.
  • Metadata in object oriented descriptive language for a class corresponding to this language may be represented by using a second auxiliary class CA2.
  • the CA2 class may be e.g. the CimMBeanlnfo class, shown with label CA2 in Exhibit 1.
  • the CA2 class provides a correspondence between CIM objects and the qualifiers being applicable to them.
  • HashMap 40 contains the designations of a plurality of CIM items (410,420, etc.), associated to their qualifiers. For each CIM item (410,420), the qualifiers may be stored in a separated HashMap (510,520).
  • HashMaps enable to separately associate each qualifier name (511, 515 and 521, 525) with its JdmkCim ⁇ Item> instance (5110, 5150 and 5210, 5250) deriving from class CAl.
  • the HashMap(s) expose the qualifiers names associated to their specific information using instances of class CAl (JdmkCimQualifier) .
  • two types of interfaces may be defined, for purpose of retrieving information, e.g. qualifiers, in connection with a CIM class:
  • a "static interface" may have accessors on private informa- tion representing e.g. the class qualifiers or other class level items.
  • an "instance interface” may have accessors on information representing e.g. the instance qualifiers or other instance level items .
  • Such interfaces provide an indirect access to the above mentioned qualifmap or set of qualifmaps .
  • the MBean being created may include qualifiers coming from the class and qualifiers specifically extended for the CIM instance.
  • a qualifier extended for the instance has priority, i.e. its value can override a qualifier value coming from the class.
  • Such a private member may also be initialized upon a call to one of the static methods of the "CA2 static interface", i.e. referring to the CA2 class itself, even if no instance of the CA2 class is created.
  • This static methods enable the user to retrieve class-level information, e.g the class qualifiers.
  • the second auxiliary class (CA2) may be generally seen as an information class, capable of associating items of a class in an object oriented descriptive language e.g. a CIM class, and the corresponding object characterizing data e.g. qualifier data from the first auxiliary class CAl.
  • object oriented descriptive language e.g. a CIM class
  • object characterizing data e.g. qualifier data from the first auxiliary class CAl.
  • Using separate storage of the qualifiers enables to easily re-compute items in case of modification of their class. For example, re-computing of the property and method lists when a CIM class has been modified is made easier, since it is only necessary to deal with qualifiers name. Indeed, the qualifiers specifications, e.g. type, flavor and scope, are separately stocked. Retrieving qualifiers associated to an item, and their specification, is also made easier.
  • a third auxiliary class CA3 may be used.
  • the CA3 class may be e.g. the CimMBean class, shown with label CA3 in Exhibit 1, and which corresponds to import 3.11 in Exhibit 3.
  • a first member of the CimMBean class may be classLevellnfo. It represents additional metadata requested for CIM requests. Main part of the metadata relative to the CIM class can be retrieved from the corresponding MBean class (property name, method name and return type, parameters, etc.) using MBeanlnfo objects. However, the qualifiers are not part of MBeanlnfo. Thus, the classLevellnfo object will provide the CIM-specific metadata for the CIM class.
  • a second member of the CimMBean class may be another indexed table or HashMap, named e.g. instanceLevelQualifMap , associa- ting each basic CIM item (the class itself, a property, a method, a method parameter), using its name, to its qualifiers.
  • the fact of to having a separate qualifier list for each CIM instance is interesting: it enables to update this list of qualifiers for the CIM instance (i.e. the MBean) via Modifylnstance requests. This is used to compute a qualifier closure for a specific instance.
  • a third member of the CimMBean class may be a Boolean entity mylsAssocFlg, initialized to false by default, and set to true if the CIM class is an ASSOCIATION, i.e. has the ASSOCIATION qualifier.
  • the methods of the CimMBean class may comprise the usual accessors to the members, and, in addition:
  • the third auxiliary class may also comprise methods including code adapted to convert expressions written in object oriented descriptive language into expressions written in manageable executable code.
  • Every MBean class representing a CIM class may inherit (directly or via other MBean classes) from the CA3 class.
  • the third auxiliary class CA3 is a manageable class; its members, e.g the classLevellnfo, may be at least partially defined using the second auxiliary class (CA2, or CIMMBeanlnfo in the example ) .
  • a class written in the MOF object oriented descriptive language may be represented by an MBean class, which inherits the third auxiliary class CA3, or CIMMBean .
  • the above mentioned MBean class may be designed as a main class, instituting a correspondence mechanism to translate properties, methods and qualifiers described in CIM-MOF (or another object oriented descriptive language) into properties methods and qualifiers written in manageable executable code.
  • CIM-MOF or another object oriented descriptive language
  • auxiliary classes may support a main CIM representing class C2M.
  • C2M is an abbreviation of Cim ⁇ MBean, standing for CIM to MBean, in accordance with a common abbreviation of "to” into “2" (with “two” sounding like "to”).
  • the C2M class is the one instituting a correspondence between the CIM system and the JDMK implementation. Preferably, it uses one or more of the above auxiliary classes, directly or indirectly. In accordance with this invention, a correspondence may be done between any other formal description of an information system than CIM system and any other executable code based on manageable software objects than java code.
  • the abstract keyword may be used in connection with the ABSTRACT qualifier of CIM, to indicate an abstract class.
  • the abstract keyword may be disconnected from any ABSTRACT CIM qualifier, because generated MBeans are abstract by essence, since they include abstract implementation methods. - if there is no abstract keyword, the optional final keyword may be used if the CIM class to be represented has a TERMINAL qualifier without ABSTRACT qualifier.
  • the C2M class being created will inherit from that CIM superclass, - if the current CIM class is not subclassing another CIM class, the C2M class being created will inherit from the CimMBean class.
  • the keyword implements may be taken into account in two different ways: - since the CimMBean class contains a generic member of CimMBeanlnfo type, it may serve as such for the CIM classes. alternatively, a ⁇ Classname>CimMBeanInfo may be generated for each CIM class (or at least certain of them), with specific qualifier initialization code. This is illustrated below.
  • MOF model contains a class A and another class B derived from A (A is superclass for B) .
  • An ACimMBeanInfo f extending CimMBeanlnfo, will be generated for "A” ;
  • a BCimMBeanlnfo extending ACimMBeanlnfo , will be generated for "B”.
  • one public method may be generated per method of the CIM class.
  • the generated method should be both in the ⁇ CIM-class-name> class and in its ⁇ CIM-class-name>MBean interface.
  • An exemplary code structure for the methods is shown with label CMeth in Exhibit 1.
  • ⁇ CIM-class-name> defines a standard MBean.
  • standard Mbeans are presently preferred for implementing this invention, dynamic Mbeans or other dynamically manageable object might be used as well.
  • the above described object structures may be used to convert a system description based on an object oriented descriptive language into manageable executable software code, while enforcing most or all of the functionalities existing in the descriptive language, including its management features, to any desired extent.
  • FIGS. 5 and 6 show an exemplary structure for a JDMK object constructor of a ⁇ CIM-class-name> class, adapted for converting a CIM object into a JDMK object.
  • CIM entities are in capital letters, while JDMK entities are in italics.
  • the steps in the left side of the figures are tests to be made, on CIM entities in most cases.
  • the other steps in the figures are actions to be made by the object constructor, which should thus contain corresponding constructor code. Writing such code is considered known to those skilled in the art from the flow charts.
  • step order may be:
  • step 802 will call the constructor of the class derived from CimMBeanlnfo, to initialize the qualifier map. Closure is done upon the list of qualifiers.
  • classLevellnfo contains the name of an existing qualifmap for the class.
  • the qualifmap may be loaded for possible use, e.g. if modifications therein are required.
  • Step 803 tests that the size of the parameter is not less than the MIN value and outputs a message if needed.
  • step 804 will test that the parameter size is not greater than the MAX value, and output a message if needed.
  • Step 805 tests that the parameter length is not less than the MINLEN, and outputs a message if needed.
  • step 806 tests that the parameter length in not greater than the MAXLEN value, and outputs a message if needed.
  • Step 807 tests that the parameter value is not less than the MINVALUE value, and outputs a message if needed.
  • step order may be:
  • step 808 tests that the parameter value is not greater than the MAXVALUE value, and outputs a message if needed.
  • step 810 will generate a method with alias name, same parameters and return type, calling the original method; step 811 includes the "aliased" method in the interface.
  • step 812 generates a get ⁇ ppty> () method, where ⁇ ppty> is the name of the property. If test 813 the property has also the ALIAS qualifier, step 814 generates a get ⁇ alias> () method calling get ⁇ ppty> ( ) .
  • step 815 generates a set ⁇ ppty> ( ) method (to be descri- bed in more detail hereinafter). If test 816 determines that the property has also the ALIAS qualifier, step 817 generates a set ⁇ alias> ( ) method calling set ⁇ ppty> ( ) .
  • this message may be outputted in all constructors (default and others) for steps 803, 805, 806 and 807; - on the contrary, test relative to the message may be added only in the default constructor for steps 808 and 804.
  • Figure 7 shows the flow chart to process method qualifiers, specifying constraints, concerning both the method parameters (method input) and the 830 method returns (method output). Also, the flow chart of figure 7 may be applied to the set ⁇ ppty> ( ) method of step 817 of figure 6.
  • step 8310 tests that its size is not greater than MAX value, and outputs a message if needed.
  • step 8320 tests that its size is not lower than the MIN value, and outputs a message if needed.
  • step 8330 tests that its length is not lower than the MINLEN value, and outputs a message if needed.
  • step 8340 tests that its length is not greater than MAXLEN, and outputs a message if needed.
  • step 8350 tests that its value is not lower than the MINVALUE value and outputs a message if needed.
  • step 8360 tests that its value is not greater than the MAXVALUE value, and outputs a message if needed.
  • the verifications of qualifiers may output a warning message, and the generation may go on, or not, depending upon the criticality of the constraint being checked.
  • a dedicated exception deriving from JMX InvalidAttributeValueException (shown as import 3.21 in Exhibit 3) is defined for each constraint, thus defining a set of constraint exceptions (one per constraint); however at least partially, shared exceptions might be used as well.
  • the constraints violation exception are defined into a com . sun . jmx. cim . mof2bean . constraint package, an example of which is shown in the section " Import packages for the processing of exceptions" of Exhibit 3. Writing the code for processing exceptions from the basic InvalidAttributeValueException of JMX is considered accessible to those skilled in the art.
  • CIM data types may be mapped e.g. in java.
  • CIM may use data types (“CIM data types"), which are listed in the left column of Table TO. It should be kept in mind that not all of these CIM types are commonly used in practical applications.
  • the right column shows simple java data types (Short, Integer, etc.), which may be used to represent the CIM data type in the left column on the same row.
  • Special java classes may also be defined as necessary.
  • the CIMDateTime type does not exist at present as a simple type in java.
  • a corresponding CIMDateTime java class may be defined and is provided as import 3.13 in the import package listed in Exhibit 3. Since dates are expressed in string format in CIM, the CIMDateTime JMX class comprises properties and accessors as required, e.g. the self-explanatory methods getCIM ⁇ ayO , setCIMmonth ( ) , setCIMyear ( ) .
  • the reference which corresponds to the name of a CIM object, may be represented as an ObjectName java class, which is provided as import 3.14 in the import package listed in Exhibit 3, and simply comprises the name of the reference.
  • new java classes or sets of java classes may be defined to represent various other CIM data types.
  • CIM data type has a more complex behavior than that of the normally corresponding simple java type
  • a corresponding special java class may be defined, instead of using the corresponding simple java data type.
  • the invention enables the translation of the majority of the MOF language into MBean java language.
  • most of the CIM qualifiers shown in table Tl need only be added into the corresponding MBean item list.
  • Handling a qualifier may e.g. involve generating corresponding code or generating a method skeleton.
  • a generic example of method skeleton is shown as Cmeth in Exhibit 1.
  • the "_do_method" may simply read Attributel if it is local, or include code to obtain a refreshed value if Attributel is remote.
  • Others CIM qualifiers shown in this table Tl may also be implemented, if desired. It has been noted that certain of them are rarely used in MOF, e.g. COUNTER and GAUGE.
  • Corresponding java code may be generated as necessary. For example, if a property has the NULLVALUE qualifier, a isNull ⁇ ppty> ( ) method may be generated in both the MBean class and interface. The isNull ⁇ ppty> ( ) method returns "true” if the property is equal to NULLVALUE value.
  • a reference in CIM may be represented or mapped with a String (for ObjectName) or an ArrayList, both representing a CIM instance (this will be developed hereinafter) ;
  • a CIM array may be mapped to a real java array.
  • a CIM array may also have the ArrayType qualifier. This does not imply special code generation in java except for qualifier storage.
  • properties or method parameters may also be qualified with constraint qualifiers such as
  • MINVALUE/MAXVALUE may be applied to a value, defining a MIN and/or MAX range for the value; similarly, MINLEN/MAXLEN may be applied to specify the MIN, resp. MAX length of the string.
  • a such qualifier may also be applied to array elements: MINVALUE/MAXVALUE for a value of an element, and MINLEN/MAXLEN for an element defined as a string; furthermore, the CIM array itself may have MIN/MAX qualifiers putting a constraint on the number of elements in the array.
  • conversion of a CIM array into java further includes generating code in order to check the constraints in accordance with the CIM constraint mode.
  • the correspondence between CIM and java for MIN/MAX, MINVALUE/MAXVALUE and MINLEN/MAXLEN qualifiers may be defined in an import package according to the same model as the import packages in Exhibit 3.
  • a method may own an OUT qualified parameter.
  • MY_METH0D(P1,P2) where P2 is an OUT qualified parameter. This means that the method will not only have a return value Rl, but also give an updated value P2* to parameter P2.
  • the corresponding method my_method(pl ,p2 ) may be generated to return a single structure including the method return, the OUT qualified parameter, and corresponding read accessors.
  • the structure may be:
  • CIM-specific ASSOCIATION features are now considered.
  • an ASSOCIATION is described using a corresponding CIM ASSOCIATION class.
  • a binary ASSOCIATION will link instances of two given CIM classes together.
  • a n-ary ASSOCIATION will link instances of n given CIM classes together.
  • the classes being linked in an ASSOCIATION are designated by using the keyword REFERENCE, hence the use of the word "reference" in connection with the classes linked in an ASSOCIATION.
  • a binary ASSOCIATION may be illustrated by using the simple example of a teacher-student relation, comprising e.g.: - teacher instance teachl,
  • the CIM class describing that association may be expressed in a form corresponding to the following (in natural language): ASSOCIATION schoolclass teacher REFERENCETeacher MIN 1, MAX 1 student REFERENCE Student MIN 1, MAXn This means that a school class will associate:
  • a so-called “role” is defined in connection with each REFERENCE class: in the example of the schoolclass association, a role is defined for the Teacher (class) and another role for the Student (class). Each role will include instances from its corresponding class, within the limits of its corresponding MIN and MAX qualifiers.
  • a particular school class will be represented in CIM by a plurality of instances of the schoolclass ASSOCIATION class, like: teachl - studl , teachl - stud2 , . . . teachl - studn.
  • each CIM role may be represented as an array, containing all the instances of its corresponding class, e.g. a first array teacher [1 ] for the Teacher class, and a second array student [n ] (n is the dimension of the array) for the Student class.
  • the arrays contain the object name of each instance in the role.
  • the ASSOCIATION as a whole may be represented in a single MBean object, including the arrays representing each role; in the above example, this would result into e.g.: - an array teacher [1 ] (or a string teacher) containing the object name teachl ; - an array student [n] for the n students studl to studn .
  • mapping uses a single Mbean object to represent the association, instead of the multiple instances of the ASSOCIATION class, as used in CIM.
  • the Java (or similar) object used for mapping a CIM ASSOCIATION may link one instance from a class to different instances from another class.
  • Min/Max qualifiers now apply to the number of elements in the above defined Java arrays: a reference having "MIN MyMin, MAX MyMax" may be represented by an array the dimension of which is (MyMax - MyMin + 1); further possibilities may exist, for example using an array the dimension of which is MyMax, and ignoring (MyMin - 1) positions in that array. Since the Min/Max qualifiers apply to the number of elements within the Java arrays representing an ASSOCIATION, they may be re-calculated if new elements (e.g. new student instances) are added.
  • Min/Max constraints as such may be checked within the Java array(s) mapping the CIM ASSOCIATION. If desired, additional code may be written to enforce the CIM constraints of "uniqueness", as described above, e.g. the fact that a student has only one teacher.
  • CIM and java Min/Max qualifiers may be provided in an import package according to the same model as described with reference to the import package 3.22 through 3.27 in Exhibit 3.
  • the object constructor may look for MIN and MAX qualifiers when an array of references is detected, and then may convert these into min and max properties of the corresponding Java arrays, as necessary.
  • MIN and MAX qualifiers are not mandatory in CIM; thus, alternatively, a reference list may also be handled in Java without performing qualifier checking.
  • Add/remove methods may be used in CIM for accessing instances of references in an ASSOCIATION class. It has been found that such add/remove methods are not necessary in Java. This is because the references of an ASSOCIATION class are placed in a Java array. Thus, JMX expects the Java getter/setter methods to address the whole array.
  • Some qualifiers may not be processed, or not fully processed. Examples are the STATIC qualifier for a method and the STATIC qualifier for a property.
  • a property may have the ALIAS qualifier.
  • This ALIAS qualifier is handled in java with specific java code, generated as follows: the generated code creates a java reference for the CIM property; then, an ⁇ alias> named property is created to point to the original property through the java reference.
  • CIM also comprises a DEFAULTVALUES qualifier applied to properties.
  • a DEFAULTVALUES qualifier may be added into qualifier map to keep the default values, if there is any. Default values designate initialization values for properties.
  • a java code is generated to map this DEFAULTVALUES qualifier.
  • CIM comprises KEY properties.
  • a property may be designated with the reserved qualifier KEY.
  • This KEY quali- fier provides an identification for instances of that class. Thus, these instances may be distinguished within a single namespace.
  • an MBean may be generated. This MBean supports MBean ObjectName composed with all KEY qualified properties (and only these one) of the Model. This MBean also implements the MBeanRegistration interface. This interface provides tools to check the consistency between candidate MBean ObjectName against KEY qualified properties of the CIM model.
  • CIM and java may be defined in packages imported in CIM instances classes.
  • a package is defined for each CIM SCHEMA, each CIM class belonging to one CIM class.
  • the package has the following form: "package ⁇ user-package-location>. ⁇ schema name>. ⁇ Class name>” where ⁇ user-package-location> is a command line option showing the path to the package, and having e.g. default value: "com.sun. jmx.cim".
  • the above described embodiment refers to the translation of a management oriented modeling language, e.g. CIM language, into manageable executable code, e.g. java code.
  • the invention may include one or more of the following elements: - an object constructor, e.g. JDMK object constructor, operable upon the parsing of code expressed in a management oriented modeling language, e.g. CIM-MOF (first language), for producing corresponding executable code in another language, e.g. Java (second language); - providing the object constructor with code which may process items in the first language, e.g. MOF qualifiers, so as to enforce tests or constraints existing on such an item, when generating a corresponding item in the second language.
  • an object constructor e.g. JDMK object constructor
  • auxiliary classes may be used to describe object characterizing data (the "qualifiers"), to build classes using such objects, or to define a manageable class.
  • the qualifiifiers object characterizing data
  • a class in the first language may be represented by a main class in the second language, as described.
  • a computer system encompasses one or more machines, which may be real or virtual.
  • This invention is not limited to described management system using the MOF formalism.
  • the invention may apply to other source languages, which may or may not be adapted to generation of executable code. It may also involve other object characterizing data than the CIM qualifiers.
  • the invention may offer advances in generating executable code other than java code, that can be integrated within the management framework.
  • qualifiers and properties qualifiers in CIM, additional qualifiers may be defined and may be processed according to this invention. Conversely, certain methods qualifiers and properties qualifiers may not be processed.
  • This invention has also described the mapping of a CIM
  • the reference to the single instance may be a 1-dimension array or simply, in another embodiment of this invention, a string containing its ObjectName.
  • This invention further covers the proposed software code itself, especially when made available on any appropriate computer-readable medium.
  • 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.
  • the software code basically includes the class structures, and/or import software packages.
  • the items comprise the CIM class itself, a property, a method, a method parameter.
  • classLevellnfo a static member, classLevellnfo, the type of which derives from CimMBeanlnfo.
  • HashMap an HashMap, instanceLevelQualifMap, associating each CIM item (the class itself, a property, a method, a method parameter), using its name, to its qualifiers.

Abstract

This invention enforces direct conversion of a management oriented modeling language e.g. CIM/MOF language into manageable executable code, using manageable objects, e.g. into JDMK/JMX manageable executable code, using the MBean objects (903). To enable this purpose, the invention provides a translation or mapping between items of the management oriented modeling language and the manageable executable code. Software tools (J-CONS, C-PAR) and appropriated code (CA1, CA2, CA3) are also provided to enable this language conversion.

Description

Improved manageable object oriented software environment.
This invention generally relates to computer technology, more particularly to manageable object oriented software environments .
Software information models are now currently used in the design of software systems. An example is the Common Information Model (CIM), and the associated object oriented descriptive language, named "Managed Object Format" (MOF), both of which will be discussed hereinafter in more detail.
However, modeling languages like the MOF language aim to be purely descriptive, without implementation reference, even if they look like real programming language. This raises problems when implementing the model to real executable code using a given programming language.
A general aim of the present invention is to bring a solution to these problems.
The applicant has observed that certain software environments are now offering management f nctionalities . An example is the Java Dynamic Management Kit (JDMK), which is a management framework for developing executable code in Java language. It implements the Java Management extensions (JMX).
Thus, another purpose of this invention is to enable direct conversion of a management oriented modeling language into manageable executable code, using manageable objects, e.g. into JDMK/JMX manageable executable code, using the known MBean objects.
Still another purpose of this invention is to enable a translation or mapping between items of the management oriented modeling language and the manageable executable code.
In accordance with a first aspect of this invention, there is proposed a software development system, comprising:
- a computer, having a development environment, adapted for processing manageable software objects, and
- at least one software module capable of at least partially converting available code in a first language into executable code based on such manageable software objects.
This invention also offers a method of developing software, comprising the following steps :
-a. providing a computer system, having a development environment, adapted for processing manageable software objects,
-b. storing available code in a first language in said computer system, and
-c. at least partially converting said available code in a first language into executable code based on such manageable software objects.
This invention also encompasses a software code, having manageable software objects, adapted to at least partially converting available code in a first language into executable code based on such manageable software objects.
Other alternative features and advantages of the invention will appear in the detailed description below and in the appended drawings, in which :
- figure 1 is a general diagram of a computer system in which the invention is applicable;
- figure 2 is a general diagram of an object-oriented software environment in a computer system; - figure 3 is a partial diagram of an object software system in which this invention may be applicable;
- figure 4A is a partial diagram of a structure to handle an object in object oriented descriptive language in an object in manageable executable code according to the invention;
- figure 4B is a partial diagram of an object in object oriented descriptive language, and of its instanciation in accordance with the invention;
- figure 5 is a flow chart showing a structure of an object constructor to process object oriented descriptive elements into elements of an executable language;
- figure 6 is the continuation of the flow chart figure 5 showing a structure of an object constructor adapted to process object oriented descriptive elements into elements of an executable language;
- figure 7 is a flow chart showing how to check method constraint from object oriented descriptive language to executable language; and
- figure 8 represents an HashMap structure of use in an embodiment of the invention.
As cited in this specification, Sun, Sun Microsystems, Solaris, Java, EmbeddedJava, PersonalJava, JavaBeans, Java Naming and Directory Interface, JDBC, Enterprise JavaBeans, Jini and Sun Spontaneous Management are trademarks of Sun Microsystems, Inc. SPARC is a trademark of SPARC International, Inc.
A portion of the disclosure of this patent document contains material which is 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's rights whatsoever.
Additionally, the detailed description is supplemented with the following Exhibits :
- Exhibit 1 describes the auxiliary classes JdmkCimQualifier, CimMBeanlnfo, CimMBean, the main CIM representing class, and a java code structure for CIM methods.
- Exhibit 2 exposes tables of CIM items and the correspondence between CIM data types and java data types.
- Exhibit 3 describes an exemplary package, in the form of a java package for handling CIM items in java classes.
These 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.
Making reference to software entities imposes certain conventions in notation. For example, in the detailed description:
- the quote sign " and/or italics may be used when deemed necessary for distinguishing software entities from the descriptive text.
- Also, <Classname> may be used to designate a value of the entity Classname (or "Classname" ) .
However, in code examples, the notation is the usual one, in accordance with the rules of writing code. The dot notation is used as necessary, for example: "com. sun. jmx.cim" .
It is assumed that one skilled in the art is to be familiar with the main concepts of object oriented programming languages, e.g. java language. Generally, a "class" is a generic description, which may comprise "properties", "methods" and, e.g. in java language, "parameters". A class may be used to generate as many objects ("class instances") as desired, each having a different name. A class may also "extend" a parent class (often termed "superclass").
This invention may apply in a computer system, or in a network comprising computer systems. The hardware of such a computer system is for example as shown in Fig. 1, where:
- 11 is a processor, e.g. an Ultra-Sparc (SPARC is a Trademark of SPARC International Inc);
- 12 is a program memory, e.g. an EPROM for BIOS;
- 13 is a working memory, e.g. a RAM of any suitable techno- logy (SDRAM for example);
- 14 is a mass memory, e.g. one or more hard disks;
- 15 is a display, e.g. a monitor;
- 16 is a user input device, e.g. a keyboard and/or mouse; and - 21 is a network interface device connected to a communication medium 20, itself in communication with other computers. Network interface device 21 may be an Ethernet device, a serial line device, or an ATM device, inter alia. Medium 20 may be based on wire cables, fiber optics, or radio-communi- cations, for example.
Data may be exchanged between the components of Figure 1 through a bus system 10, schematically shown as a single bus for simplification of the drawing. As is known, bus systems may often include a processor bus, e.g. of the PCI type, connected via appropriate bus bridges to e.g. an ISA bus and/or an SCSI bus.
In figure 2, the CPU and hardware of figure 1 is diagrammati- cally shown as 1. The computer system also has an operating system 3, e.g. Solaris (an operating system product and trademark of SUN MICROSYSTEMS). Operating systems other than Solaris may be used in accordance with this invention. An object supporting software 4 may be installed over operating system 3. The object supporting software 4 may e.g. include the necessary software to build a java virtual machine or JVM. It includes an object processor or object provider 41, e.g. the method ClassLoader( ) of the Java language. The object supporting software 4 may then serve to run object oriented application software 5. When required, changes in object oriented application software 5 may be made using software management tools 6. The software management tools may be designed in accordance with the JMX/JDMK specification. However, the invention may apply to other software management tools as well.
The invention may apply within a single machine as shown in figure 2. However it will more likely be applied within a distributed environment, as shown in figure 3, in the example of two machines Ml and M2, interconnected by a link 20, e.g. a network medium. The machines may have the exemplary structure of figure 1, or any equivalent structure. In figure 3, the blocks showing the same functions as in figure 2 are identified by the same reference number, immediately followed by the machine identifier. For example the operating system of machine Ml is noted 3M1. As shown, an exemplary architecture may include the object oriented application software 5M1 in machine Ml, and the software management tools 6M2 in machine M2, which thus may be dedicated to software management. However, many other combinations are possible, based on two machines or more. Provision for a management dedicated machine is an option. One or more machines may include both application software and management tools, as shown in figure 2. Also, each machine may support one or more java virtual machines or other types of machines or devices. In object oriented programming, an "object" may comprise, as known, properties and methods, together termed [object] members. In the foregoing description, the term "member" will be used essentially to designate a property. For convenience, the methods are usually identified by their name followed with ( ) . One or more parameters of the method may be inserted between the two round brackets, as necessary.
Accessor methods (or more briefly accessors) are methods used to read and/or write in an object. A reading method like get ( ) is usually named getter method. A writing method like set ( ) is usually named setter method.
More details on specific java objects named JavaBeans may be found at: http: //Java. sun. com/beans/spec . html and/or in the corresponding printed documentation.
Certain software environments support the definition of a set of abstract methods, i.e. merely declared methods without underlying code. In Java, this is called an "interface". An object which "implements" an interface will include code for each method declared in the interface it implements.
On another hand, the Java Dynamic Management Kit (JDMK) is a management framework for developing executable code in java language. It implements the Java Management extensions (JMX). In accordance with JDMK/JMX, the management of java objects may be made through one or more interfaces dedicated to management (in short "management interfaces").
The JDMK may use the well known JavaBeans object classes. It may also use managed beans or MBeans, as described e.g. in JMX. More details on the JMX specification may be found at: http: //Java. sun. co /products/JavaMana ement and/or in the corresponding printed documentation. What is termed an MBean is a manageable object implementing a management interface. An MBean may contain accessor methods, e.g. get<name> ( ) and/or set<name> ( ) . Such getter and/or setter methods define an "attribute" named <name> . The getter and/or setter methods of an attribute are generically named "getter/setter pair", even if only a getter method or only a setter method is present for that attribute.
In the example of JMX, an MBean may be a standard MBean or a dynamic MBean: a. in JMX, an object is a standard MBean if its class <Myclass> . implements an interface <Myclass>MBean , which declares the manageable methods of the object. The correspondence between the names <Myclass> and <Myclass>MBean is called a naming rule or "design pattern". Other more sophisticated rules may apply, e.g. when <Myclass> does not itself implement an interface <Myclass>MBean, but a parent class of <Myclass> does . b. in JMX, an object is a dynamic MBean if it has an internal getMBeanInfo ( ) method, which may return an MBeanlnfo object, containing the methods of its management interface.
It will be appreciated that in a standard MBean, the management methods are predefined in a rigid management interface (the corresponding <Myclass>MBean ) , and therefore may not evolve at runtime. By contrast, the getMBeanlnfof ) method and MBeanlnfo object of a dynamic MBean define a generic interface at an upper level, which is applicable to a variety of objects and is therefore more flexible at any time, including runtime.
Tools for modeling software will now be considered.
As indicated, software developers often use a formal descrip- tion of the information system they want to implement.
However, passing from that formal description (source) to executable software code (target) may raise difficulties. Such difficulties will now be set forth, using a non limiting example.
The Common Information Model (CIM) is a joint effort from various actors of software industry to propose an information model for system management. The CIM is a sub-committee of the Distributed Management Task Force (DMTF). Detailed information on CIM may be found inter alia in the following documents, available from the DMTF as hard copies or on the web site DMTF. org:
Common Information Model (CIM) specification ("cim_spec_v22") ;
- Core MOF specification ( "CIM_core22.mof" ) ; - Application MOF specification ( "CIM_Application22.mof" )
- System MOF specification ( "CIM_System22.mof" )
- Devices MOF specification ( "CIM_Device22.mof" )
- Physical MOF specification ( "CIM_Physical22.mof" )
- Network Model MOF specification ( "CIM_Network22.mof" ) - DAP MOF specification ( "CIM_DAP22.mof" )
An object oriented descriptive language, named Managed Object Format (MOF), has been designed for modeling CIM management systems. The MOF language enables users to formally describe a management system they want to implement. Other languages may provide equivalent facilities. Now, the programmers need tools capable of generating executable code corresponding to the formal description in the MOF language or in other similar languages. In the foregoing description, the "source" CIM/MOF language may be named "metacode", to reflect the fact its code is descriptive and cannot be executed or compiled as such.
On another hand, this field also includes the so-called "CIM/WBEM manager APIs" (WBEM, standing for Web Based
Enterprise Management, is a subset of the CIM system) . In addition to "CIM/WBEM manager APIs", this field also includes the so-called "WBEM SDK" (SDK standing for Software Development Kit). The "CIM/WBEM manager APIs" and the "WBEM SDK" both handle metadata from CIM/MOF language to executable code e.g. java code.
These CIM/WBEM manager APIs or WBEM SDK represent CIM objects as java classes and manipulate them as Java beans. In this context, a CIM object is a computer representation or model of a managed resource, such as a printer, disk drive, or CPU. Standard CIM objects, complying with the CIM-2.1 Specification, may be modeled using the CIM/WBEM manager APIs, which comprises the WBEM Software Development Kit, and its CIM- directed Object Manager. In short, starting from MOF eta- code:
- the WBEM Software Development Kit generates metadata corresponding to the MOF metacode;
- these metadata are handled by the CIM-directed Object Manager; - the Object Manager in turn works with the server.
Programmers then can use the corresponding Java interfaces to describe managed objects, and retrieve information about managed objects in a particular system environment. This information is retrieved thanks to CIM-MOF requests adapted to be handled by the java server or thanks to java requests directly handled by the java server. By such a modeling of managed resources using CIM, the objects can be shared across any system that is CIM compliant.
However, despite the fact that CIM/WBEM APIs have been a significant advance, they use regular JavaBeans, and thus cannot benefit the advantages of MBeans in terms of software management . To summarize, users can describe a management system using e.g. the MOF formalism as a source metacode ("first language"). A more detailed object of this invention is to offer advances in generating target executable code (in a "second language"), e.g. java code, that can be more closely integrated within the JMX management framework. In other words, the code provided in MOF may be designated as "metacode", indicating that the MOF code is an upper language level, in comparison with the executable code as used, e.g. java code. In general, another formal language than MOF language may be used in accordance with the invention. Also, the invention may be used with another manageable executable code than java code.
A description of the main features of the invention will now be made, with reference to figure 4A and 4B.
Generally, CIM entities are in capital letters, while JDMK entities are in italics. The figures show a non limiting example of application according to the invention using MOF language and java code.
A CIM/MOF Parser (C-PAR) may be used to read the MOF metacode file, e.g. sequentially, while identifying coherent portions of the MOF metacode. Such portions may then be transmitted to a JDMK object constructor (J-CONS) . The object constructor (J-CONS) may first check MOF items. Then, it may build manageable java objects (e.g. MBeans) with their corresponding accessors, thus serving both to generate object defini- tions (class generator), and to generate object instances from such classes. Such java objects constitute executable code, or, at least, may be used to generate executable code (J-EXE), which is manageable through the JDMK object manager (J-OM) . Thus, as with any manageable executable code, management oriented requests may be applied to the server, e.g. JDMK management oriented requests (J-REQ), comprising JDMK object manager, to retrieve information on a designed MBean .
In addition, a programmer may use management oriented CIM/MOF requests (C-REQ) to gain access to a designed MBean and the JDMK object manager via the different elements linking CIM/MOF metacode to executable code. This possibility is symbolized with dotted arrows.
CIM rules 901 represents the applicable rules in an information model for system management, CIM in the example. Other information model for system management may be used according to the invention, whether directly enabling generation of executable code, or not. The basic CIM items are a CIM class, or a property, a method, a method parameter in a CIM class. Optionally, the CIM objects may include e.g.:
- "ASSOCIATION" (relation between CIM instances),
- "INDICATION" (event to be raised by a CIM instance),
- "REFERENCE", (a unique name given to a CIM instance, e.g. for building ASSOCIATIONS),
- "SCHEMA" (set of CIM classes).
MOF tools 902 represents available tools in an object oriented descriptive language, MOF in the example. Other object oriented descriptive language may be used according to the invention. In the example, the CIM-MOF basically uses object characterizing data, named "qualifiers". A qualifier may be viewed as a container for information data about an object item. Each qualifier has: - a type (e.g. boolean or string);
- a scope, i.e. the list of CIM objects it may apply to (e.g. "class", "property"); and
- a flavor (optional), which indicates one or more inherent features of the qualifier, such as e.g. DISABLEOVERRIDE, RESTRICTED or TRANSLATABLE. CIM supports two levels of qualifiers:
- "class qualifiers", which apply to all instances of that class;
- "instance qualifiers" which may additionally apply to a particular instance of a class.
Now considering a particular class instance, the operation of merging its "class qualifiers" with its "instance qualifiers" (if any) is called "qualifier closure".
It has been found possible to build instances of the MBean classes (903) being adapted to represent CIM instances of the CIM classes, at least in their main features. This involves defining mapping rules between the MOF and MBean formalisms, in the example. The invention uses one or more auxiliary classes to this effect. Other structures (mapping rules and classes) may be defined between other object oriented descriptive languages and manageable executable codes according to the invention.
A first auxiliary class CAl may be used for providing other object characterizing data, e.g. qualifier data. Its members are the information to be returned when requiring object characterizing data in an object oriented descriptive language, e.g. qualifier data in a CIM message; corresponding accessor methods are provided for.
The CAl class may be e.g. the JdmkCimQual±fier class, as shown with label CAl" in Exhibit 1, which corresponds to import 3.12 in Exhibit 3.
In the example, all the members of the CAl class are written as text characters (i.e. have the string type). This enables to put them in the form of XML messages, when required instead of in a object oriented descriptive language, e.g. MOF text files (XML, standing for extended Markup Language, is described inter alia in the web site http: //www.w3. orq/TR/REC-xml, or in the booklet "XML Pocket Reference", Robert ECKSTEIN, O'REILLY, U.S.A, October 1999).
Thus, object characterizing data e.g. a CIM qualifier (in a CIM class or CIM instance) may be represented by an instance of the CAl class. In accordance with an exemplary naming rule, a qualifier named <item> may be represented by a JdmkCiπκitem> instance of the JdmkCimQualifier class.
Metadata in object oriented descriptive language for a class corresponding to this language, e.g. in CIM-specific metadata for a CIM class, may be represented by using a second auxiliary class CA2. The CA2 class may be e.g. the CimMBeanlnfo class, shown with label CA2 in Exhibit 1. Generally, the CA2 class provides a correspondence between CIM objects and the qualifiers being applicable to them.
As shown in figure 8, this correspondence may be stored in an indexed table or "HashMap" 40, named e.g. qualifMap (for qualifier map) . HashMap 40 contains the designations of a plurality of CIM items (410,420, etc.), associated to their qualifiers. For each CIM item (410,420), the qualifiers may be stored in a separated HashMap (510,520).
While each qualifier might be stored in its JdmkCim<Item> instance deriving from class CAl, as defined above, such HashMaps enable to separately associate each qualifier name (511, 515 and 521, 525) with its JdmkCim<Item> instance (5110, 5150 and 5210, 5250) deriving from class CAl. In other words, the HashMap(s) expose the qualifiers names associated to their specific information using instances of class CAl (JdmkCimQualifier) . In fact, two types of interfaces may be defined, for purpose of retrieving information, e.g. qualifiers, in connection with a CIM class:
- a "static interface" may have accessors on private informa- tion representing e.g. the class qualifiers or other class level items.
- an "instance interface" may have accessors on information representing e.g. the instance qualifiers or other instance level items .
Such interfaces provide an indirect access to the above mentioned qualifmap or set of qualifmaps .
Thus, in java, when an MBean is created for representing a given CIM instance, a private member is initialized (together with its accessors) in the MBean to represent the qualifier closure for that CIM class. Thus, the MBean being created may include qualifiers coming from the class and qualifiers specifically extended for the CIM instance. In an embodiment of this invention, a qualifier extended for the instance has priority, i.e. its value can override a qualifier value coming from the class.
Such a private member may also be initialized upon a call to one of the static methods of the "CA2 static interface", i.e. referring to the CA2 class itself, even if no instance of the CA2 class is created. This static methods enable the user to retrieve class-level information, e.g the class qualifiers.
in other words, the second auxiliary class (CA2) may be generally seen as an information class, capable of associating items of a class in an object oriented descriptive language e.g. a CIM class, and the corresponding object characterizing data e.g. qualifier data from the first auxiliary class CAl. Using separate storage of the qualifiers enables to easily re-compute items in case of modification of their class. For example, re-computing of the property and method lists when a CIM class has been modified is made easier, since it is only necessary to deal with qualifiers name. Indeed, the qualifiers specifications, e.g. type, flavor and scope, are separately stocked. Retrieving qualifiers associated to an item, and their specification, is also made easier.
A third auxiliary class CA3 may be used. The CA3 class may be e.g. the CimMBean class, shown with label CA3 in Exhibit 1, and which corresponds to import 3.11 in Exhibit 3.
A first member of the CimMBean class may be classLevellnfo. It represents additional metadata requested for CIM requests. Main part of the metadata relative to the CIM class can be retrieved from the corresponding MBean class (property name, method name and return type, parameters, etc.) using MBeanlnfo objects. However, the qualifiers are not part of MBeanlnfo. Thus, the classLevellnfo object will provide the CIM-specific metadata for the CIM class.
A second member of the CimMBean class may be another indexed table or HashMap, named e.g. instanceLevelQualifMap , associa- ting each basic CIM item (the class itself, a property, a method, a method parameter), using its name, to its qualifiers. The fact of to having a separate qualifier list for each CIM instance is interesting: it enables to update this list of qualifiers for the CIM instance (i.e. the MBean) via Modifylnstance requests. This is used to compute a qualifier closure for a specific instance.
A third member of the CimMBean class may be a Boolean entity mylsAssocFlg, initialized to false by default, and set to true if the CIM class is an ASSOCIATION, i.e. has the ASSOCIATION qualifier. The methods of the CimMBean class may comprise the usual accessors to the members, and, in addition:
- static accessors to retrieve all qualifiers of a class or all qualifiers of an element of the class. - instance accessors to retrieve the same information at the instance level.
- methods to perform CIM messages applicable for a CIM instance.
More generally, the third auxiliary class (CA3 or CIMMBean class) may also comprise methods including code adapted to convert expressions written in object oriented descriptive language into expressions written in manageable executable code.
Thus, every MBean class representing a CIM class may inherit (directly or via other MBean classes) from the CA3 class. The third auxiliary class CA3 is a manageable class; its members, e.g the classLevellnfo, may be at least partially defined using the second auxiliary class (CA2, or CIMMBeanlnfo in the example ) .
In the example, a class written in the MOF object oriented descriptive language may be represented by an MBean class, which inherits the third auxiliary class CA3, or CIMMBean .
In an embodiment of this invention, the above mentioned MBean class may be designed as a main class, instituting a correspondence mechanism to translate properties, methods and qualifiers described in CIM-MOF (or another object oriented descriptive language) into properties methods and qualifiers written in manageable executable code.
In the example, the above described auxiliary classes may support a main CIM representing class C2M. "C2M" is an abbreviation of Cim∑MBean, standing for CIM to MBean, in accordance with a common abbreviation of "to" into "2" (with "two" sounding like "to"). The C2M class is the one instituting a correspondence between the CIM system and the JDMK implementation. Preferably, it uses one or more of the above auxiliary classes, directly or indirectly. In accordance with this invention, a correspondence may be done between any other formal description of an information system than CIM system and any other executable code based on manageable software objects than java code.
The exemplary syntax of the Cim2MBean class definition is shown with label C2M in Exhibit 1. The syntax will now be described:
- the abstract keyword may be used in connection with the ABSTRACT qualifier of CIM, to indicate an abstract class.
Alternatively, the abstract keyword may be disconnected from any ABSTRACT CIM qualifier, because generated MBeans are abstract by essence, since they include abstract implementation methods. - if there is no abstract keyword, the optional final keyword may be used if the CIM class to be represented has a TERMINAL qualifier without ABSTRACT qualifier.
- after the keyword class, <CIM-class-name> stands for the name of the JDMK class being created. - turning to the keyword extends, the inheritance scheme is as follows:
- if the current CIM class is subclassing a CIM superclass, the C2M class being created will inherit from that CIM superclass, - if the current CIM class is not subclassing another CIM class, the C2M class being created will inherit from the CimMBean class.
- the keyword implements may be taken into account in two different ways: - since the CimMBean class contains a generic member of CimMBeanlnfo type, it may serve as such for the CIM classes. alternatively, a <Classname>CimMBeanInfo may be generated for each CIM class (or at least certain of them), with specific qualifier initialization code. This is illustrated below.
It is now assumed a MOF model contains a class A and another class B derived from A (A is superclass for B) . An ACimMBeanInfof extending CimMBeanlnfo, will be generated for "A" ; a BCimMBeanlnfo, extending ACimMBeanlnfo , will be generated for "B".
Now, when the classLevellnfo static member of the CimMBean class is initialized for a CIM class, the initialization is done with an instance of the corresponding specific MBeanlnfo derived class. This provides full consistency with the object scheme, since access to the qualifier map is done only through static or instance accessors.
Basically, one public method may be generated per method of the CIM class. The generated method should be both in the <CIM-class-name> class and in its <CIM-class-name>MBean interface. An exemplary code structure for the methods is shown with label CMeth in Exhibit 1.
It will be appreciated that <CIM-class-name> defines a standard MBean. Although standard Mbeans are presently preferred for implementing this invention, dynamic Mbeans or other dynamically manageable object might be used as well.
Generally, the above described object structures may be used to convert a system description based on an object oriented descriptive language into manageable executable software code, while enforcing most or all of the functionalities existing in the descriptive language, including its management features, to any desired extent.
More detailed aspects of the translation of a management oriented modeling language into a manageable executable code will now be discussed. Thus, the translation of CIM objects into JDMK is illustrated in the detailed foregoing example according to the invention with reference to figures 5 and 6, with Figure 6 continuing figure 5.
The flow charts of figures 5 and 6 show an exemplary structure for a JDMK object constructor of a <CIM-class-name> class, adapted for converting a CIM object into a JDMK object. Again, CIM entities are in capital letters, while JDMK entities are in italics. The steps in the left side of the figures are tests to be made, on CIM entities in most cases. The other steps in the figures are actions to be made by the object constructor, which should thus contain corresponding constructor code. Writing such code is considered known to those skilled in the art from the flow charts.
Turning first to figure 5, the step order may be:
* if test 701 determines that the CIM object has the ASSOCIATION qualifier, initialize mylsAssoc to true in step 801. * if test 702 determines that classLevellnfo is null (no qualifmap existing yet), step 802 will call the constructor of the class derived from CimMBeanlnfo, to initialize the qualifier map. Closure is done upon the list of qualifiers.
Otherwise, classLevellnfo contains the name of an existing qualifmap for the class. The qualifmap may be loaded for possible use, e.g. if modifications therein are required.
* if test 703 determines that a reference has the MIN qualifier, this means that the constructor has a parameter for this reference. Step 803 tests that the size of the parameter is not less than the MIN value and outputs a message if needed.
* if test 704 determines that a parameter is passed to the constructor for the reference and that the reference has the MAX qualifier in step 704, step 804 will test that the parameter size is not greater than the MAX value, and output a message if needed.
* if test 705 determines that a property has the MINLEN qualifier, this means that the constructor has a parameter for this property. Step 805 tests that the parameter length is not less than the MINLEN, and outputs a message if needed.
* if test 706 determines that a parameter is passed to the constructor for a property, and the property has the MAXLEN qualifier, step 806 tests that the parameter length in not greater than the MAXLEN value, and outputs a message if needed.
* if test 707 determines that a property has the MINVALUE qualifier, this means that the constructor has a parameter for this property. Step 807 tests that the parameter value is not less than the MINVALUE value, and outputs a message if needed.
Turning now to figure 6, the step order may be:
* if test 708 determines that a parameter is passed to the constructor for a property, and the property has the MAXVALUE qualifier, step 808 tests that the parameter value is not greater than the MAXVALUE value, and outputs a message if needed.
* if test 709 determines that a property has the REQUIRED qualifier, this means that the constructor has a parameter for this property. Then :
* if the property has the NULLVALUE qualifier, test that parameter value is not equal to NULLVALUE value in step 809, else * test that parameter value is not equal to null in both constructors (default and other) in step 890.
* if test 710 determines that a method has the ALIAS quali- fier, step 810 will generate a method with alias name, same parameters and return type, calling the original method; step 811 includes the "aliased" method in the interface.
* if test 711 determines that a property has a READ qualifier, step 812 generates a get<ppty> () method, where <ppty> is the name of the property. If test 813 the property has also the ALIAS qualifier, step 814 generates a get<alias> () method calling get<ppty> ( ) .
* if test 712 determines that a property has a WRITE qualifier, step 815 generates a set<ppty> ( ) method (to be descri- bed in more detail hereinafter). If test 816 determines that the property has also the ALIAS qualifier, step 817 generates a set<alias> ( ) method calling set<ppty> ( ) .
In the above steps requiring a message : - this message may be outputted in all constructors (default and others) for steps 803, 805, 806 and 807; - on the contrary, test relative to the message may be added only in the default constructor for steps 808 and 804.
Figure 7 shows the flow chart to process method qualifiers, specifying constraints, concerning both the method parameters (method input) and the 830 method returns (method output). Also, the flow chart of figure 7 may be applied to the set<ppty> ( ) method of step 817 of figure 6.
* if test 8301 determines that a parameter/return type has the MAX qualifier, step 8310 tests that its size is not greater than MAX value, and outputs a message if needed.
* if test 8302 determines that a parameter/return type has the MIN qualifier, step 8320 tests that its size is not lower than the MIN value, and outputs a message if needed. * if test 8303 determines that a parameter/return type has the MINLEN qualifier, step 8330 tests that its length is not lower than the MINLEN value, and outputs a message if needed.
* if test 8304 determines that a parameter/return type has the MAXLEN qualifier, step 8340 tests that its length is not greater than MAXLEN, and outputs a message if needed.
* if test 8305 determines that a parameter/return type has the MINVALUE qualifier, step 8350 tests that its value is not lower than the MINVALUE value and outputs a message if needed.
* if test 8306 determines that a parameter/return type has the MAXVALUE qualifier, step 8360 tests that its value is not greater than the MAXVALUE value, and outputs a message if needed.
For methods or properties, the verifications of qualifiers (for example MAXLEN) may output a warning message, and the generation may go on, or not, depending upon the criticality of the constraint being checked.
After the description of figures 5, 6 and 7, it will appear that properties, method parameters and methods returns (i.e. return type of methods) may be constrained through the following qualifiers: MAX, MIN, MAXVALUE, MINVALUE, MINLEN, MAXLEN. MINLEN is provided optionally, although it is not included in the CIM standard.
Including such a constraint qualifier into the MOF model, will result in checking the code generated into MBeans. Violating these constraints will implied trigger of some Exceptions .
In an exemplary embodiment, a dedicated exception deriving from JMX InvalidAttributeValueException (shown as import 3.21 in Exhibit 3) is defined for each constraint, thus defining a set of constraint exceptions (one per constraint); however at least partially, shared exceptions might be used as well. The constraints violation exception are defined into a com . sun . jmx. cim . mof2bean . constraint package, an example of which is shown in the section " Import packages for the processing of exceptions" of Exhibit 3. Writing the code for processing exceptions from the basic InvalidAttributeValueException of JMX is considered accessible to those skilled in the art.
Table TO in Exhibit 2 shows how CIM data types may be mapped e.g. in java. Generally, CIM may use data types ("CIM data types"), which are listed in the left column of Table TO. It should be kept in mind that not all of these CIM types are commonly used in practical applications.
The right column shows simple java data types (Short, Integer, etc.), which may be used to represent the CIM data type in the left column on the same row.
Special java classes may also be defined as necessary. For example, the CIMDateTime type does not exist at present as a simple type in java. Thus, a corresponding CIMDateTime java class may be defined and is provided as import 3.13 in the import package listed in Exhibit 3. Since dates are expressed in string format in CIM, the CIMDateTime JMX class comprises properties and accessors as required, e.g. the self-explanatory methods getCIMάayO , setCIMmonth ( ) , setCIMyear ( ) .
Similarly, the reference, which corresponds to the name of a CIM object, may be represented as an ObjectName java class, which is provided as import 3.14 in the import package listed in Exhibit 3, and simply comprises the name of the reference.
More generally, new java classes or sets of java classes may be defined to represent various other CIM data types. For example, where the CIM data type has a more complex behavior than that of the normally corresponding simple java type, a corresponding special java class may be defined, instead of using the corresponding simple java data type.
The invention enables the translation of the majority of the MOF language into MBean java language. For example, most of the CIM qualifiers shown in table Tl need only be added into the corresponding MBean item list. Handling a qualifier may e.g. involve generating corresponding code or generating a method skeleton. A generic example of method skeleton is shown as Cmeth in Exhibit 1. Considering a getAttributel ( ) accessor method, the "_do_method" may simply read Attributel if it is local, or include code to obtain a refreshed value if Attributel is remote. Others CIM qualifiers shown in this table Tl may also be implemented, if desired. It has been noted that certain of them are rarely used in MOF, e.g. COUNTER and GAUGE.
Corresponding java code may be generated as necessary. For example, if a property has the NULLVALUE qualifier, a isNull<ppty> ( ) method may be generated in both the MBean class and interface. The isNull<ppty> ( ) method returns "true" if the property is equal to NULLVALUE value.
The Parameters/Return types in the methods are mapped in accordance with table TO of Exhibit 2, with the following remarks :
- a reference in CIM may be represented or mapped with a String (for ObjectName) or an ArrayList, both representing a CIM instance (this will be developed hereinafter) ;
- a CIM array may be mapped to a real java array. A CIM array may also have the ArrayType qualifier. This does not imply special code generation in java except for qualifier storage.
- In a CIM array, properties or method parameters may also be qualified with constraint qualifiers such as
MINVALUE/MAXVALUE or MINLEN/MAXLEN . Generally, MINVALUE/MAXVALUE may be applied to a value, defining a MIN and/or MAX range for the value; similarly, MINLEN/MAXLEN may be applied to specify the MIN, resp. MAX length of the string. In CIM, a such qualifier may also be applied to array elements: MINVALUE/MAXVALUE for a value of an element, and MINLEN/MAXLEN for an element defined as a string; furthermore, the CIM array itself may have MIN/MAX qualifiers putting a constraint on the number of elements in the array. If desired, conversion of a CIM array into java further includes generating code in order to check the constraints in accordance with the CIM constraint mode. The correspondence between CIM and java for MIN/MAX, MINVALUE/MAXVALUE and MINLEN/MAXLEN qualifiers may be defined in an import package according to the same model as the import packages in Exhibit 3.
In CIM, a method may own an OUT qualified parameter. Consider for example MY_METH0D(P1,P2) , where P2 is an OUT qualified parameter. This means that the method will not only have a return value Rl, but also give an updated value P2* to parameter P2.
In JMX mapping, the corresponding method my_method(pl ,p2 ) may be generated to return a single structure including the method return, the OUT qualified parameter, and corresponding read accessors. In the example, the structure may be:
{rl, P2*, getRl(), getP2()} This single structure takes the method invocation scheme of the JDMK MBean server into account. More precisely, parameter P2 is passed to the method; if it is updated by the method, the mapped method returns an object of a specific struct-like class, that wraps the original return type Rl and the OUT qualified parameter P2. As many OUT qualified parameters as desired may be processed in this way. CIM also admits a [IN=false, OUT] qualifier (having no "IN" parameter) . In fact, the method is linked to the simple "OUT" qualifier. This [IN=false, OUT] may be handled in java in a specific form: considering for example a function defined as integer f( string a [OUT]...) the return of this function (as defined in the correspondingly generated code) may be an instance of a class, the members of which are:
- "result", which is the integer result of the function, - "a", which is the string parameter of the function returned as an "out" parameter.
The CIM-specific ASSOCIATION features are now considered. In CIM, an ASSOCIATION is described using a corresponding CIM ASSOCIATION class. A binary ASSOCIATION will link instances of two given CIM classes together. A n-ary ASSOCIATION will link instances of n given CIM classes together. In CIM, the classes being linked in an ASSOCIATION are designated by using the keyword REFERENCE, hence the use of the word "reference" in connection with the classes linked in an ASSOCIATION.
A binary ASSOCIATION may be illustrated by using the simple example of a teacher-student relation, comprising e.g.: - teacher instance teachl,
- students instances studl , stud2, . . . , studn .
The CIM class describing that association may be expressed in a form corresponding to the following (in natural language): ASSOCIATION schoolclass teacher REFERENCETeacher MIN 1, MAX 1 student REFERENCE Student MIN 1, MAXn This means that a school class will associate:
- a single teacher object instance, to be instantiated from the class Teacher, and - 1 to n student object instances, to be instantiated from the class Student.
A so-called "role" is defined in connection with each REFERENCE class: in the example of the schoolclass association, a role is defined for the Teacher (class) and another role for the Student (class). Each role will include instances from its corresponding class, within the limits of its corresponding MIN and MAX qualifiers.
In the above example, a particular school class will be represented in CIM by a plurality of instances of the schoolclass ASSOCIATION class, like: teachl - studl , teachl - stud2 , . . . teachl - studn.
This also means that a given teacher is associated to 1 to n students, while a given student is only associated to one teacher ("uniqueness").
Mapping a CIM ASSOCIATION e.g. in Java may be made as follows:
a) each CIM role may be represented as an array, containing all the instances of its corresponding class, e.g. a first array teacher [1 ] for the Teacher class, and a second array student [n ] (n is the dimension of the array) for the Student class. The arrays contain the object name of each instance in the role.
b) besides, the ASSOCIATION as a whole may be represented in a single MBean object, including the arrays representing each role; in the above example, this would result into e.g.: - an array teacher [1 ] (or a string teacher) containing the object name teachl ; - an array student [n] for the n students studl to studn .
The above defined mapping uses a single Mbean object to represent the association, instead of the multiple instances of the ASSOCIATION class, as used in CIM. In other words, the Java (or similar) object used for mapping a CIM ASSOCIATION may link one instance from a class to different instances from another class.
In Java, the Min/Max qualifiers now apply to the number of elements in the above defined Java arrays: a reference having "MIN MyMin, MAX MyMax" may be represented by an array the dimension of which is (MyMax - MyMin + 1); further possibilities may exist, for example using an array the dimension of which is MyMax, and ignoring (MyMin - 1) positions in that array. Since the Min/Max qualifiers apply to the number of elements within the Java arrays representing an ASSOCIATION, they may be re-calculated if new elements (e.g. new student instances) are added.
Thus, the Min/Max constraints as such may be checked within the Java array(s) mapping the CIM ASSOCIATION. If desired, additional code may be written to enforce the CIM constraints of "uniqueness", as described above, e.g. the fact that a student has only one teacher.
The correspondence between CIM and java Min/Max qualifiers may be provided in an import package according to the same model as described with reference to the import package 3.22 through 3.27 in Exhibit 3.
Thus, in a particular embodiment of this invention, the object constructor (mof∑bean) may look for MIN and MAX qualifiers when an array of references is detected, and then may convert these into min and max properties of the corresponding Java arrays, as necessary. However, MIN and MAX qualifiers are not mandatory in CIM; thus, alternatively, a reference list may also be handled in Java without performing qualifier checking.
Add/remove methods may be used in CIM for accessing instances of references in an ASSOCIATION class. It has been found that such add/remove methods are not necessary in Java. This is because the references of an ASSOCIATION class are placed in a Java array. Thus, JMX expects the Java getter/setter methods to address the whole array.
Some qualifiers, more rarely used in MOF, may not be processed, or not fully processed. Examples are the STATIC qualifier for a method and the STATIC qualifier for a property.
Having considered the methods qualifiers, various aspects concerning the properties qualifiers will now be dealt with. Formally, the name of CIM. properties may remain unchanged; they may start with upper-case.
In CIM, a property may have the ALIAS qualifier. This ALIAS qualifier is handled in java with specific java code, generated as follows: the generated code creates a java reference for the CIM property; then, an <alias> named property is created to point to the original property through the java reference.
CIM also comprises a DEFAULTVALUES qualifier applied to properties. A DEFAULTVALUES qualifier may be added into qualifier map to keep the default values, if there is any. Default values designate initialization values for properties. A java code is generated to map this DEFAULTVALUES qualifier.
CIM comprises KEY properties. In a class, a property may be designated with the reserved qualifier KEY. This KEY quali- fier provides an identification for instances of that class. Thus, these instances may be distinguished within a single namespace. In java mapping, an MBean may be generated. This MBean supports MBean ObjectName composed with all KEY qualified properties (and only these one) of the Model. This MBean also implements the MBeanRegistration interface. This interface provides tools to check the consistency between candidate MBean ObjectName against KEY qualified properties of the CIM model.
The correspondence between CIM and java may be defined in packages imported in CIM instances classes. Thus, a package is defined for each CIM SCHEMA, each CIM class belonging to one CIM class. The package has the following form: "package <user-package-location>.<schema name>.<Class name>" where <user-package-location> is a command line option showing the path to the package, and having e.g. default value: "com.sun. jmx.cim".
The above described embodiment refers to the translation of a management oriented modeling language, e.g. CIM language, into manageable executable code, e.g. java code. More generally, the invention may include one or more of the following elements: - an object constructor, e.g. JDMK object constructor, operable upon the parsing of code expressed in a management oriented modeling language, e.g. CIM-MOF (first language), for producing corresponding executable code in another language, e.g. Java (second language); - providing the object constructor with code which may process items in the first language, e.g. MOF qualifiers, so as to enforce tests or constraints existing on such an item, when generating a corresponding item in the second language. - one or more "auxiliary" classes may be used to describe object characterizing data (the "qualifiers"), to build classes using such objects, or to define a manageable class. - a class in the first language may be represented by a main class in the second language, as described.
It will be understood that this invention is not restricted to the above described embodiment, and has features of broader interest.
As described, a computer system encompasses one or more machines, which may be real or virtual.
This invention is not limited to described management system using the MOF formalism. The invention may apply to other source languages, which may or may not be adapted to generation of executable code. It may also involve other object characterizing data than the CIM qualifiers.
On another hand, the invention may offer advances in generating executable code other than java code, that can be integrated within the management framework.
Concerning the methods qualifiers and properties qualifiers in CIM, additional qualifiers may be defined and may be processed according to this invention. Conversely, certain methods qualifiers and properties qualifiers may not be processed.
Also, this invention has been described in detail with reference to a particular class structure, involving classes noted CAl through CA3, and a main supporting class C2M. Only a portion of these classes may be used, if desired. Also, equivalent class structures may also be designed.
This invention has also described the mapping of a CIM
ASSOCIATION in e.g. java ; specifically when the MIN and MAX qualifiers both equal 1, the reference to the single instance may be a 1-dimension array or simply, in another embodiment of this invention, a string containing its ObjectName.
This invention further covers the proposed software code itself, 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. The software code basically includes the class structures, and/or import software packages.
Exhibit 1 - Classes
CAl - JdmkCimQualifier class
* Members
- the qualifier name, a string (CAl.l)
- the qualifier type, a string (CAl.2)
- the qualifier value, a string (CAl.3)
* Methods : accessors to the members
CA2 - CimMBeanlnfo class
* Members
- CIM items, designated by their names. The items comprise the CIM class itself, a property, a method, a method parameter.
* Methods : accessors to the members
CA3 - CimMBean class
* Members:
- a static member, classLevellnfo, the type of which derives from CimMBeanlnfo.
- an HashMap, instanceLevelQualifMap, associating each CIM item (the class itself, a property, a method, a method parameter), using its name, to its qualifiers.
- a Boolean mylsAssocFlg (init false), set to true if the CIM class is an ASSOCIATION, i.e. has the ASSOCIATION qualifier. * Methods :
- accessors to the members.
- static accessors to retrieve all qualifiers of a class or all qualifiers of an element of the class. - instance accessors to retrieve same information at the instance level.
- methods to perform CIM messages applicable for a CIM instance.
C2M - Main CIM representing class
public abstract [final] class <CIM-class-name> extends <CIM-superclass || CimMBean> implements <C/ -c/α_ss-nαme>MBean {
}
Cmeth - java code structure for CIM methods
<return type> method(<parameter list>) {
// code for IN parameter checking against constraints
// Abstract implementation method call _do_method(....)
// Return type and OUT parameter check code against constraints ....
} Exhibit 2 - Tables
Table TO - CIM and java data types
Figure imgf000038_0001
Table Tl - Basic CIM items
AGGREGATE AGGREGATION BITMAP BITVALUES DESCRIPTION DISPLAYNAME IN (supported by default) MAPPINGSTRINGS MODELCORRESPONDENCE NONLOCAL NONLOCALTYPE PROPAGATED REVISION SOURCE SOURCETYPE UNITS VERSION WEAK
EXPENSIVE INVISIBLE LARGE PROVIDER SYNTAX SYNTAXTYPE Table Tl (continuation) - Basic CIM items
COUNTER
GAUGE SCHEMA
VALUEMAP
VALUES
DELETE
IFDELETED TRIGGERTYPE
UNKNOWNVALUES
UNSUPPORTEDVALUES
NULLVALUE
OVERRIDE MIN
MAX
Exhibit 3 - Exemplary package
3. 1- Import packages for classes
3.11 - import com.sun.jmx.cim.mof2bean.CimMBean a java package imported in a java class if this class inherits from CimMBean
3.12 - import com.sun.jmx.cim.mof2bean.JdmkCimQualifier a java package imported in a java class if this class handle at least one CIM qualifier
3.13 - import com.sun.wbem.cim.CIMDateTime a java package handling the CIMDateTime qualifier, imported in a java class if this class has this CIM date time data type for one CIM property/parameter/return type
3.14 - import javax.management. ObjectName a java package imported in a java class if in this class there is one REFERENCE (i.e. a MBean ObjectName, the MBean generated for a CIM ASSOCIATION) to another CIM instance
2- Import packages for the processing of exceptions
3.21 - import javax.management.InvalidAttribute Value
3.22 - import com.sun.jmx.cim.mof2bean.constraint.MaxConstraintViolationException a java package imported in a java class if this class handle the Max qualifier
3.23 - import com. sun.jmx.cim.mof2bean. constraint. MinConstraintViolationException a java package imported in a java class if this class handle the Min qualifier
3.24 - import com.sun.jmx.cim.mof2bean.constraint.MaxLenConstraintViolationException a java package imported in a java class if this class handle the MaxLen qualifier
3.25 - import com.sun.jmx.cim.mof2bean.constraint.MinLenConstraintViolationException a java package imported in a java class if this class handle the MinLen qualifier 3.26 - import com.sun.jmx.cim.mof2bean.constraint.MaxValueConstraintViolationException a java package imported in a java class if this class handle the MaxValue qualifier 3.27 - import com.sun.jmx.cim.mof2bean.constraint.MinValueConstraintViolationExceρtion a java package imported in a java class if this class handle the Min Value qualifier

Claims

Claims
1. A software development system, comprising: a computer system, having a development environment, adapted for processing manageable software objects (903), and
- at least one software module capable of at least partially converting available code in a first language (902) into executable code based on said manageable software objects.
2. The system of claim 1, wherein said first language is an object oriented descriptive language.
3. The system of claim 2, wherein said available code comprises a formal description of an information system.
4. The system of claim 2, wherein said object oriented descriptive language is the Managed Object Format (MOF) (902).
5. The system of claim 1, wherein the software module comprises a first auxiliary class (CAl), capable of describing object characterizing data.
6. The system of claim 5, wherein said object characterizing data comprise qualifier data.
7. The system of claim 5, wherein the software module comprises a second auxiliary class (CA2), capable of associating items of a class described in said first language, and object characterizing data from said first auxiliary class (CAl) .
8. The system of claim 7, wherein the software module comprises a third auxiliary class (CA3), having members at least partially defined using the second auxiliary class (CA2), the third auxiliary class being a manageable class.
9. The system of claim 8, wherein the third auxiliary class (CA3) comprises methods to convert expressions written in said first language into expressions written in manageable executable code.
10. The system of claim 8, wherein said development environment comprises a class generator, capable of building a generated class inheriting said third auxiliary class (CA3), and representing a class written in said first language.
11. The system of claim 10, wherein said class generator is capable of generating at least one object constructor for the generated class inheriting said third auxiliary class (CA3), and representing a class written in said first language.
12. The system of claim 10, wherein the class generator is arranged to institute a correspondence mechanism to translate expressions written in said first language into corresponding expressions written in manageable executable code.
13. The system of claim 12, wherein the correspondence mechanism comprises tests for at least part of said expressions (703,710,803,810).
14. The system of claim 12, wherein the class generator is capable of generating a class method adapted to test at least said part of expressions in said generated class.
15. The system of claim 14, wherein the class generator is arranged to return a message if a test fails.
16. The system of claim 15, wherein the class generator is arranged to return a message if said test fails, using exceptions from an exception software package.
17. The system of claim 10, wherein the software module comprises a main class (C2M) for calling said class generator.
18. A method of developing software, comprising the steps of:
-a. providing a computer system, having a development environment, adapted for processing manageable software objects,
-b. storing available code in a first language (902) in said computer system, and
-c. at least partially converting said available code in a first language (902) into executable code based on such manageable software objects.
19. The method of claim 18, wherein said first language is an object oriented descriptive language.
20. The method of claim 18, wherein said available code comprises a formal description of an information system.
21. The method of claim 18, wherein said object oriented descriptive language is the Managed Object Format (MOF) .
22. The method of claim 21, wherein step c. comprises:
- cl. providing a first auxiliary class (CAl), capable of describing object characterizing data.
23. The method of claim 22, wherein said object characterizing data comprise qualifier data.
24. The method of claim 22, wherein step c. comprises: - c2. providing a second auxiliary class (CA2), capable of associating items of a class described in said first Ian- guage, and object characterizing data from said first auxiliary class (CAl).
25. The method of claim 24, wherein step c. comprises: - c3. providing a third auxiliary class (CA3), having members at least partially defined using the second auxiliary class (CA2), the third auxiliary class being a manageable class.
26. The method of claim 25, wherein the third auxiliary class (CA3) comprises methods to convert expressions written in said first language into expressions written in manageable executable code.
27. The method of claim 25, wherein step c. comprises: - c4. generating a class inheriting said first auxiliary class (CA3) and representing a class written in said first language.
28. The method of claim 27, wherein step c4. further compri- ses generating at least one object constructor for the generated class.
29. The method of claim 28, wherein step c. comprises: - c5. translating expressions written in said first language into corresponding expressions written in manageable executable code.
30. The method of claim 29, wherein step c5. further compri- ses tests for at least a part of said expressions
(703,710,703,810).
31. The method of claim 30, wherein a test in step c5. comprises generating a class method adapted to test at least said part of expressions in said generated class.
32. The method of claim 31, wherein a test comprises returning a message if said test fails.
33. The method of claim 32, wherein the test comprises returning a message if said test fails, using exceptions from an exception software package.
34. The method of claim 27, wherein step c4. further comprises: - c6. providing a main class (C2M) to represent said class written in said first language.
35. A software code, having manageable software objects, adapted to at least partially converting available code in a first language (902) into executable code based on said manageable software objects.
36. The code of claim 35, wherein said first language is an object oriented descriptive language.
37. The code of claim 35, wherein said available code comprises a formal description of an information system.
38. The code of claim 37, wherein said object oriented descriptive language is the Managed Object Format (MOF)
(902).
39. The code of claim 35, comprising a first auxiliary class (CAl), capable of describing object characterizing data.
40. The code of claim 39, wherein said object characterizing data comprise qualifier in the Managed Object Format (MOF) .
41. The code of claim 39, comprising a second auxiliary class (CA2), capable of associating items of a class described in said first language, and object characterizing data from said first auxiliary class (CAl).
42. The code of claim 39, comprising a third auxiliary class (CA3), having members at least partially defined using the second auxiliary class (CA2), the third auxiliary class being a manageable class.
43. The code of claim 42, wherein the third auxiliary class (CA3) comprises providing methods to convert expressions written in said first language into expressions written in manageable executable code.
44. The code of claim 35, comprising a class generator, capable of building a generated class inheriting said first auxiliary class (CA3) and representing a class written in said first language.
45. The code of claim 44, wherein said class generator comprises generating at least one object constructor for the generated class inheriting said third auxiliary class (CA3), and representing a class written in said first language.
46. The code of claim 44, wherein the class generator comprises instituting a correspondence mechanism to translate properties, methods, and object characterizing data written in said first language into properties, methods and object characterizing data written in manageable executable code.
47. The code of claim 46, wherein the correspondence mechanism comprises tests for object characterizing data (703,710,703,810).
48. The code of claim 46, wherein the class generator is capable of generating a class method adapted to test an object characterizing data in said generated class.
49. The code of . claim 48, wherein the class generator comprises returning a message if a test fails.
50. The code of claim 49, wherein the test comprises retur- ning a message if the test fails, using exceptions from an exception software package.
51. The code of claim 50, wherein the software module comprises providing a main class (C2M) for calling said class generator.
PCT/IB2000/001782 2000-11-30 2000-11-30 Improved manageable object oriented software environment WO2002044896A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU2001215432A AU2001215432A1 (en) 2000-11-30 2000-11-30 Improved manageable object oriented software environment
PCT/IB2000/001782 WO2002044896A1 (en) 2000-11-30 2000-11-30 Improved manageable object oriented software environment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IB2000/001782 WO2002044896A1 (en) 2000-11-30 2000-11-30 Improved manageable object oriented software environment

Publications (1)

Publication Number Publication Date
WO2002044896A1 true WO2002044896A1 (en) 2002-06-06

Family

ID=11004006

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2000/001782 WO2002044896A1 (en) 2000-11-30 2000-11-30 Improved manageable object oriented software environment

Country Status (2)

Country Link
AU (1) AU2001215432A1 (en)
WO (1) WO2002044896A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2901389A1 (en) * 2006-05-22 2007-11-23 France Telecom Software application`s administration profile e.g. management bean, constructing method for enterprise, involves creating association table of attributes and operations with attributes and operations of initial profile to manage application

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6023578A (en) * 1997-05-09 2000-02-08 International Business Macines Corporation Systems, methods and computer program products for generating an object oriented application for an object oriented environment
WO2000014629A1 (en) * 1998-09-03 2000-03-16 Kimono Limited A data processing system and development method

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6023578A (en) * 1997-05-09 2000-02-08 International Business Macines Corporation Systems, methods and computer program products for generating an object oriented application for an object oriented environment
WO2000014629A1 (en) * 1998-09-03 2000-03-16 Kimono Limited A data processing system and development method

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2901389A1 (en) * 2006-05-22 2007-11-23 France Telecom Software application`s administration profile e.g. management bean, constructing method for enterprise, involves creating association table of attributes and operations with attributes and operations of initial profile to manage application

Also Published As

Publication number Publication date
AU2001215432A1 (en) 2002-06-11

Similar Documents

Publication Publication Date Title
US7174533B2 (en) Method, system, and program for translating a class schema in a source language to a target language
US7739665B2 (en) Dynamic conversion of object-oriented programs to tag-based procedural code
JP3595340B2 (en) Recoverable proxy objects in an object-oriented environment
US7206827B2 (en) Dynamic administration framework for server systems
US8112738B2 (en) Apparatus and method of customizable model import and export to and from XML schema formats
US7120863B1 (en) Method, system, and program for interfacing with elements in a document
US8073935B2 (en) Pluggable semantic verification and validation of configuration data
US7559052B2 (en) Meta-model for associating multiple physical representations of logically equivalent entities in messaging and other applications
US6907572B2 (en) Command line interface abstraction engine
US7676789B2 (en) Architecture for customizable applications
US7412497B2 (en) Generation of Administration framework for server systems
US6601072B1 (en) Method and system for distribution of application data to distributed databases of dissimilar formats
US20150205778A1 (en) Reducing programming complexity in applications interfacing with parsers for data elements represented according to a markup languages
US20040019669A1 (en) Event notification in an administration framework for server systems
US20040216086A1 (en) XML types in Java
KR101098603B1 (en) System and method for transferring computer-readable objects across a remote boundary
KR20050000352A (en) Common query runtime system and application programming interface
JPH10505693A (en) System and method for providing interoperability between heterogeneous object systems
US8201147B2 (en) Generic XAD processing model
US20060242187A1 (en) Type safe data proxy
US20120284653A1 (en) Object model for a user interface
US20060044318A1 (en) Context attribute determination
WO2002044896A1 (en) Improved manageable object oriented software environment
Turtschi et al. C#. Net Developer's Guide
Sells et al. ATL internals: working with ATL 8

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP