This Schema was generated by the OSS through Java XML Toolkit Doclet 3-30-2005 15:26 The <CODE>HierarchicalPrimaryKey</CODE> interface represents an inventory key based on a hierarchy. The DN (Distiguished Name) of the inventory object is composed of the RDN (Relative Distiguished Name)and the DN of the parent. In case the entity is directly under the top of the hierarchy (i.e. the parent is "top") the parent DN is a null <CODE>String</CODE> . The HierarchicalName interface (see the interface definition below) represents a key based on a hierarchy, e.g., X.500 or LDAP directory. Every object in the hierarchy has a Distinguished Name (DN), which is made up of a sequence of Relative Distinguished Names (RDNs). The RDNs are separated by commas. An RDN is unique for given base in the hierarchy. A DN is unique to the entire hierarchy. Here is an example of a DN: "network=Canada,subnetwork=Ottawa,device=OttawaRouter1" The RDNs of this DN are: <ul> <li>RDN => network=Canada <li>RDN => subnetwork=Ottawa <li>RDN => device=OttawaRouter1 </ul> The parent DN of the "OttawaRouter1" object is "network=Canada,subnetwork=Ottawa". This is the base from which all entity value interfaces are derived. Entities are represented in the CBE package as managed entities (according to the OSS through Java definition of managed entity). <CODE>EntityValue</CODE> inherits from <CODE>ManagedEntityValue</CODE> all methods for population, generic attribute access and serialization. <CODE>EntitySpecificationValue</CODE> is the base for all specification entities. An entity specification captures characteristics and constraints applicable to instances of the same entity type. For example a "<CODE>GoldBroadbandAccessServicespecification</CODE>" will capture the characteristics, configuration and QoS parameter ranges, specific to a "<CODE>Gold</CODE>" Broadband Access service offering. Several specification instances may exist for the same entity type. "<CODE>Gold</CODE>", "<CODE>Silver</CODE>" and "<CODE>Bronze</CODE>" specifications may be defined for a "<CODE>BroadbandAccessService</CODE>". Catalogues are collections of entity specifications (e.g. service catalogue composed of service specifications, product catalogue composed of product specifications, resource catalogue composed of resource specifications). An entity instance is defined by a single entity specification. The same entity specification may be used to define multiple entity instances. An association exists between the entity specification and the entity instances, defined by this specification (the values of the <CODE>describingSpecification</CODE> attributes of the entities are set with the key of the specification). The specification defines default values for all attributes of the corresponding entity type. Entity specifications provide a factory method for the attribute constraints they contain. Note that the CBE package does not specify through how attribute constraints are defined. Specific implementations of the CBE interfaces should define the concrete attribute constraint interfaces and the methods on the entity specification that allow to get and set these constraints. Entity specifications are represented as managed entities (according to the OSS through Java definition of managed entity). <CODE>EntitySpecification</CODE> instances have their own key and can be retrieved through API specific <CODE>JVTSession</CODE> interfaces. The following example show how to use the Inventory API to update a <CODE>ProductSpecification</CODE>: <pre> <CODE> JVTInventorySession jvt = ...; EntitySpecificationKey key = ...; ProductSpecificationValue value = (ProductSpecificationValue)jvt.getEntitySpecificationByKey(key); value.setAttributeValue("..."); jvt.setEntitySpecificationByValue(value); </CODE> </pre> The specification for a given entity type may be used as a factory for value objects or for creating entity instances of this entity type. For example using the Inventory API: <pre> <CODE>JVT<...>InventorySession.make<...>EntityValueFromSpecification()</CODE> and the <CODE>JVT<...>InventorySession.create<...>EntityFromSpecification()</CODE> methods. </pre> Entity specifications are uniquely identified by their keys. See {@link EntitySpecificationKey} for more information. <CODE>EntitySpecificationValue</CODE> inherits from <CODE>ManagedEntityValue</CODE> all methods for population, generic attribute access and serialization. The <CODE>EntitySpecificationKeyResult</CODE> interface is used in bulk best effort JVT operations. This interface encapsulates all the information necessary to indicate the result of a best effort update operation on a specific entity specification(during a best effort update operation each entity specification involved in the operation is processed in a separate atomic action). The <CODE>EntitySpecificationKey</CODE> interface represents a unique key for an entity specification. The <CODE>EntitySpecificationKeyResult</CODE> interface is used in bulk best effort JVT operations. This interface encapsulates all the information necessary to indicate the result of a best effort update operation on a specific entity specification(during a best effort update operation each entity specification involved in the operation is processed in a separate atomic action). The <CODE>EntityKey</CODE> interface This is the base for all the first class CBE Managed Entities These first class objects may be in one of the following categories: <ul> <li>entities <li>entitiy specifications, describing entities <li>associations, representing binary relationships between entities or specifications </ul> CBEManagedEntityValue is the base value type interface for the CBE Entity, Entity Specification and Association Values. This interface defines the <CODE>CBECoreType</CODE> enumeration. The type of a CBE object may be one of the following: <ul> <li> entity <li> entity specification <li> association </ul> The <CODE>Cardinality</CODE> defines the numeric relationships between occurrences of the entities on either end of a relationship. This interface defines the cardinality value of the association's end. The <CODE>Cardinality</CODE> interface is used in {@link AssociationRule AssociationRules}. An association rule defines the constraints for a particular association type and the cardinality is one of the constraints defined in the rule. The cardinality is accessed through the {@link AssociationRule#getAEndCardinality getAEndCardinality()} and {@link AssociationRule#getZEndCardinality getZEndCardinality()} methods of the {@link AssociationRule AssociationRule} interface. The <CODE>AssociationValue</CODE> is the base from which all association interfaces are derived. Associations are represented in the CBE package as managed entities (according to the OSS through Java definition of managed entity). <CODE>Association</CODE> instances have their own keys. The following attributes of an <CODE>AssociationValue</CODE> are set at creation: <ul> <li>EntityKey <li>the key of object A (A end) <li>the key of object Z (Z end) </ul> Note that other attributes could be defined by concrete association values derived from this base interface. However these attributes should be specific to this association and should not depend on the state of other objects. The roles are captured in the definition of the association attributes and in the corresponding {@link AssociationRule AssociationRule}. For example in a "<CODE>SupportedBy</CODE>" type of association for one of the objects will be defined an attribute "<CODE>supporting</CODE>" and "<CODE>supported</CODE>" for the other. The corresponding <CODE>AssociationRule</CODE> will define the A and Z end roles as "<CODE>supporting</CODE>" and "<CODE>supported</CODE>". An {@link AssociationRule AssociationRule} is provided for every concrete association type. The rule defines the constraints for this association type (e.g. roles, cardinality, association constraints). Associations are uniquely identified by their keys. See {@link AssociationKey AssociationKey} for more information. The <CODE>AssociationValue</CODE> inherits from <CODE>ManagedEntityValue</CODE> all methods for population, generic attribute access and serialization. An <CODE>AssociationRuleViolationException</CODE> is thrown to indicate that an update operation (e.g. a creation of an association or a set operation on an entity involved in the association) violates the constraints defined in the <CODE>AssociationRule</CODE> for this association type (e.g. roles, cardinality, association constraints). An association rule defines the constraints for the corresponding association type. An association rule should be provided for every concrete association type. Association Rules define: <ul> <li>the roles at each association end <li>the cardinality of the association at each association end <li>the type of entities or specifications involved at each association end <li>the constraints applicable to this association </ul> If the constraints defined in an association rule are not respected during an update operation (e.g. a creation of an association or a set operation on an entity involved in the association) an <CODE>AssociationRuleViolationException</CODE> is thrown. The <CODE>AssociationKeyResult</CODE> interface is used in bulk best effort JVT operations. This interface encapsulates all the information necessary to indicate the result of a best effort update operation on a specific association (during a best effort update operation each association involved in the operation is processed in a separate atomic action). The <CODE>AssociationKey</CODE> interface