(file) Return to definitions.dxx CVS log (file) (dir) Up to [Pegasus] / pegasus / doc / DevManual

Diff for /pegasus/doc/DevManual/definitions.dxx between version 1.3 and 1.7

version 1.3, 2001/02/02 18:48:20 version 1.7, 2001/05/06 13:16:16
Line 1 
Line 1 
 /*  
         $Log$  
         Revision 1.3  2001/02/02 18:48:20  karl  
         Doc++ expansion  
   
         Revision 1.2  2001/01/30 23:38:18  karl  
         Add to documentation  
  
         Revision 1.1  2001/01/24 14:18:49  karl  //%/////////////////////////////////////////////////////////////////////////////
         import Dev Doc Files  //
   // Copyright (c) 2000 The Open Group, BMC Software, Tivoli Systems, IBM
   //
   // Permission is hereby granted, free of charge, to any person obtaining a
   // copy of this software and associated documentation files (the "Software"),
   // to deal in the Software without restriction, including without limitation
   // the rights to use, copy, modify, merge, publish, distribute, sublicense,
   // and/or sell copies of the Software, and to permit persons to whom the
   // Software is furnished to do so, subject to the following conditions:
   //
   // THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
   // IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
   // FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
   // THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
   // LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
   // FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
   // DEALINGS IN THE SOFTWARE.
   //
   //==============================================================================
   //
   // Author: Karl Schopmeyer (k.schopmeyer@opengroup.org)
   //
   // Modified By: Karl Schopmeyer (k.schopmeyer@opengroup.org)
   //
   //%/////////////////////////////////////////////////////////////////////////////
   
   /* This file contains the definition of terms used in the Pegasus implementation, the CIM defintions, and the Pegasus documentation.
   WARNING: Because of some limits with DOC++ today, the tags \Ref and @link
   do not work.  Therefore, references to these definitions can only be made with a direct URL as follows:
   
   \URL[Namespace]{DefinitionofTerms.html#NAMESPACE}
   
   Note that this implies the exact name of the file created from this document (DefinitionofTerms.html.  If you change the @name definition below that represents the lead section name, it will change the name of the file and everything else will fall apart.
   Note also that we have a standard form for all definitions
   <B>Namespace</B>\Label{NAMESPACE}
   So that each one has a Name and generates an HTML in page label.
  
         $Author$  
 */ */
   /*
   TODO LIST
   Add classname definition  this is alreadyreferences as CLASSNAME
   */
   
 /** @name Definition of Terms /** @name Definition of Terms
 This section provides definitions of terms and concepts used in the specification of the Pegasus Managability Services Broker and its implementation.  This section provides definitions of terms and concepts used in the specification of the  DMTF CIM and WBEM specifications and of the Pegasus Managability Services Broker and its implementation.
   
   <B>Namespace</B>\Label{NAMESPACE} An object that defines a scope within which object keys must be unique. Multiple namespaces typically indicate the presence
   of multiple management spaces or multiple devices.
   
   The namespace pragma
       <PRE>
           #pragma namespace( )
       </PRE>
   This pragma is used to specify a Namespace path. The syntax
   needs to conform to the following:
       <PRE>
           &lt;namespacetype&gt://&lt;namespacehandle&gt
       </PRE>
  
 <B>Namespace</B>\Label{NAMESPACE} - TBD definition of Namespace  
  
 <B>CIMOM</B> \Label{CIMOM} = TBD Definition of Namespace  <P>The contents of a MOF file are loaded into a Namespace that provides a domain (in other words, a container), in which the instances of the classes are guaranteed to be unique per the KEY qualifier definitions. The term namespace is used to refer to an implementation that provides such a domain.
   Namespaces can be used to:
   <UL>
       <LI>Define chunks of management information (objects and associations) to limit implementation resource requirements, such as database size.
       <LI>Define views on the model for applications managing only specific objects, such as hubs.
       <LI>Pre-structure groups of objects for optimized query speed.
    </UL>
   
   <B>CIMOM</B> \Label{CIMOM}  A CIMOM (CIM Object Manager) is the the terminology used to define the implementation of the CIM_Server defined in the CIM Operations over HTTP specification.  Typically a CIMOM includes the functions of the CIM Server, repositories, providers and the tools to start, run, etc. the CIM server.  CIMOM is an implement term and is not clearly defined in the DMTF documents as opposed to CIM Server which has a clear definition.
  
 <B>Repository</B> \Label{} - The CIM Repository stores the CIM metaschema (class repository) and instance information (instance repository). TheRepository is provided as part of the reference implementation,  but is considered an independent service for the CIMOM. The interfaces to the respository are fixed but the supplied respository can be replaced with a different implementation. <B>Repository</B> \Label{} - The CIM Repository stores the CIM metaschema (class repository) and instance information (instance repository). TheRepository is provided as part of the reference implementation,  but is considered an independent service for the CIMOM. The interfaces to the respository are fixed but the supplied respository can be replaced with a different implementation.
  
Line 26 
Line 78 
  
 <B>CIM INSTANCE</B> \Label{CIMINSTANCE} - ATTN: <B>CIM INSTANCE</B> \Label{CIMINSTANCE} - ATTN:
  
 <B>METHOD</B> \Label{METHOD} - ATTN:  
  
 <B>MOF</B> \Label{MOF} - MOF is the standard language used to define elements of the Common Information Model (CIM). The MOF language specifies syntax for defining CIM classes and instances. Compilation of MOF files provides developers and administrators with a simple and fast technique for modifying the CIM Repository. For more information about MOF, see the DMTF web page at http://www.dmtf.org. <B>MOF</B> \Label{MOF} - MOF is the standard language used to define elements of the Common Information Model (CIM). The MOF language specifies syntax for defining CIM classes and instances. Compilation of MOF files provides developers and administrators with a simple and fast technique for modifying the CIM Repository. For more information about MOF, see the DMTF web page at http://www.dmtf.org.
  
 <B>Association</B> \Label{ASSOCIATION} -An association is a relationship between two classes or between instances of two classes. The properties of an association class include pointers, or references, to the two classes or instances. <B>Association</B> \Label{ASSOCIATION} -An association is a relationship between two classes or between instances of two classes. The properties of an association class include pointers, or references, to the two classes or instances.
  
 Class association is one of the most powerful CIM features. It provides a way to organize a  Class association is one of the most powerful CIM features. It provides a way to organize a collection of management objects into meaningful relationships. For example, a CIM_ComputerSystem object might contain a CIM_Disk, Processor A, and Processor B. The CIM_ComputerSystem has an association with each of the objects it contains. Because this particular association is a containment association, it is represented by a class called CIM_contains. The CIM_contains class contains references to each of the objects that belong to the association. In this case, CIM_contains has a reference to Solaris_Disk and a reference to CIM_ComputerSystem.
 collection of management objects into meaningful relationships. For example, a  
 Solaris_ComputerSystem object might contain a Solaris_Disk, Processor A, and  
 Processor B. The Solaris_ComputerSystem has an association with each of the  
 objects it contains. Because this particular association is a containment association, it is  
 represented by a class called CIM_contains. The CIM_contains class contains  
 references to each of the objects that belong to the association. In this case,  
 CIM_contains has a reference to Solaris_Disk and a reference to  
 Solaris_ComputerSystem.  
  
 <B>WBEM</B> \Label{WBEM} - ATTN: <B>WBEM</B> \Label{WBEM} - ATTN:
  
Line 57 
Line 101 
 http://www.dmtf.org/download/spec/xmls/CIM_HTTP_Mapping10.htm. http://www.dmtf.org/download/spec/xmls/CIM_HTTP_Mapping10.htm.
 1.5 Managed Object Format 1.5 Managed Object Format
  
 <B> </B> \Label{} - ATTN:  
   
  
 <B>QUALIFIERR</B> \Label{qualifier} - Qualifiers <B>QUALIFIERR</B> \Label{qualifier} - Qualifiers
     are values that provide additional information about classes, associations,     are values that provide additional information about classes, associations,
Line 93 
Line 135 
  
 <B>CIM</B> \Label{CIM} -  Common Information Model is the schema of the overall managed environment. It is divided into a Core model, Common model and extended schemas. CIM Schema The schema representing the Core and Common models. Versions of this schema will be released by the DMTF over time as the schema evolves. <B>CIM</B> \Label{CIM} -  Common Information Model is the schema of the overall managed environment. It is divided into a Core model, Common model and extended schemas. CIM Schema The schema representing the Core and Common models. Versions of this schema will be released by the DMTF over time as the schema evolves.
  
 <B>Class</B> \Label{Class} -  A collection of instances, all of which support a common type; that is, a set of properties and methods. The common properties and methods are defined as features of the class. For example, the class called Modem represents all the modems present in a system. Common model A collection of models specific to a particular area, derived from the Core model. Included are the system model, the application model, the network model and the device model.  <B>Class</B> \Label{CLASSDEFINITION} -  A collection of instances, all of which support a common type; that is, a set of properties and methods. The common properties and methods are defined as features of the class. For example, the class called Modem represents all the modems present in a system. Common model A collection of models specific to a particular area, derived from the Core model. Included are the system model, the application model, the network model and the device model.
  
 <B>Core model</B> \Label{Core model} -  A subset of CIM, not specific to any platform. The Core model is set of classes and associations that establish a conceptual framework for the schema of the rest of the managed environment. Systems, applications, networks and related information are modeled as extensions to the Core model. <B>Core model</B> \Label{Core model} -  A subset of CIM, not specific to any platform. The Core model is set of classes and associations that establish a conceptual framework for the schema of the rest of the managed environment. Systems, applications, networks and related information are modeled as extensions to the Core model.
  
Line 123 
Line 165 
  
 Meta schema<B>Meta schema</B> \Label{Meta schema} -  The schema of the meta model. Method A declaration of a signature; that is, the method name, return type and parameters, and, in the case of a concrete class, may imply an implementation. Meta schema<B>Meta schema</B> \Label{Meta schema} -  The schema of the meta model. Method A declaration of a signature; that is, the method name, return type and parameters, and, in the case of a concrete class, may imply an implementation.
  
 <B>Model</B> \Label{Model} - A set of classes, properties and associations that allows the expression of information about a specific domain. For example, a Network may consist of Network Devices and Logical Networks. The Network Devices may have attachment associations to each other, and may have member associations to Logical Networks.  <B>METHOD</B> \Label{METHOD} - Methods represent the behavior relevant for a class. A method is defined as an operation together with its signature. The signature consists of a possibly empty list of parameters and a return type.
   
   A declaration of a signature; that is, the method name, return type and parameters, and, in the case of a concrete class, may imply an implementation.
   
   <B>Model</B> \Label{MODEL} - A set of classes, properties and associations that allows the expression of information about a specific domain. For example, a Network may consist of Network Devices and Logical Networks. The Network Devices may have attachment associations to each other, and may have member associations to Logical Networks.
  
 <B>Model Path</B> \Label{Model Path} -  A reference to an object within a namespace.  <B>Model Path</B> \Label{Model Path} -  A reference to an object within a namespace. Namespace An object that defines a scope within which object keys must be unique.
 Namespace An object that defines a scope within which object keys must be unique.  
  
 <B>Namespath Path</B> \Label{Namespath Path} -  A reference to a namespace within an implementation that is capable of hosting CIM objects. <B>Namespath Path</B> \Label{Namespath Path} -  A reference to a namespace within an implementation that is capable of hosting CIM objects.
  
Line 159 
Line 204 
 //@{ //@{
  
 /** @name NAMESPACE. /** @name NAMESPACE.
 Defintion of thamespace.  Defintion of the namespace.
 */ */
  
  


Legend:
Removed from v.1.3  
changed lines
  Added in v.1.7

No CVS admin address has been configured
Powered by
ViewCVS 0.9.2