Menu
▾
▴
Re: [Openoss-devel] Question About Association Classes in PM Dependency model
|
From: Flauw, M. <Mar...@hp...> - 2012-08-20 12:05:07
|
Craig,
You are correct, the implementation is not correct.
The association class is mainly a way to add some attributes to an association, so handling it as a true entity is not the best choice in my view.
Today for associations, we create an attribute in the source class with EntityIdentifier datatype.
The PerformanceIndicatorSpecRelationship is a bit special as it associates a class with itself.
Now, if we assume an association class C between A and B, with 2 attributes c1 and c2.
In theory we would need 2 datatypes:
C_AEND and C_ZEND
C_AEND would contain a pointer to A (entity identifier) and c1 and c2
C_ZEND would contain a pointer to B (entity identifier) and c1 and c2
If the association is navigable in both directions, then A would contain an attribute of type C_ZEND and B would contain an attribute of type C_AEND
If there is only 1 direction for navigability (like A-> B), then A would contain an attribute of type C_ZEND and the datatype C_AEND won't be needed.
Question: given that in both cases the pointer will be an entity identifier, would it be possible to simplify and only create C containing an entity identifier + c1 +c2 and use C for the attributes present in A and/or B. This would make things simpler.
Best regards
Marc
-----Original Message-----
From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig Gallen (opennms)
Sent: Wednesday, August 15, 2012 9:09 PM
To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; Craig Gallen (OpenNMS); Pierre Gauthier
Subject: Question About Association Classes in PM Dependency model
Hi,
In the PM dependencies model we have to return to the problem of how do we deal with association classes. It appears that we never satisfactory resolved this issue in the past because we didn't need association classes in our models. It is now returning to haunt us. I have looked carefully at the generated XSD's and it is clear that the present solution in the Soap generator does not work in a useful way. In the JVT generated code I have an alternative solution but it does not match the SOAP generator (see attached Java classes).
The PM Dependency model contains one association class called the PerformanceIndicatorSpecRelationship.
This has one attribute; String relationshipType. This generates the following XSD which has no reference to either end of the relationship.
<xsd:element name="performanceIndicatorSpecRelationship"
type="tns:PerformanceIndicatorSpecRelationship"/>
<xsd:complexType name="PerformanceIndicatorSpecRelationship">
<xsd:annotation>
<xsd:documentation>
<p>An association between two PerformanceIndicatorSpecifications, such as one indicator derived from another.</p>
<p>This association class is optional</p>
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="relationshipType" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A categorization of the relationship, such as derived from, composite/atomic, and so forth.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
Similarly the generated PerformanceIndicatorSpecification entities which
are linked by this association class do not reference the association
class. In fact, it appears that the the association class between PerformanceIndicatorSpecification entities is not generated at all.
<xsd:complexType name="PerformanceIndicatorSpecification">
<xsd:annotation>
<xsd:documentation>
<p>A measure of a specific aspect of the performance of an entity, such as a lost packets or average jitter, defined for a PeformanceSpecification that may trigger the creation of a PerformanceConsequence.</p>
<p>This entity is optional</p>
<p>This entity is extendable</p>
<p>This entity does not generate Object Creation
notifications (NA)</p>
<p>This entity does not generate Object Deletion
notifications (NA)</p>
<p>This entity does not generate Object Discovery
notifications (NA)</p>
<p>This entity generates Attribute Value Change notifications.</p>
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="entity:EntityBase">
<xsd:sequence>
<xsd:element name="name" type="xsd:string" minOccurs="1"
maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A word, term, or phrase by which a PerformanceIndicatorSpecification is known and distinguished from other PerformanceIndicatorSpecifications.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is mandatory</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="description" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A narrative that explains in detail what the PerformanceIndicatorSpecification is.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="perspective" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>The point of view for the PerformanceIndicatorSpecification, such as a single user instance or an aggregation.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="indicatorCategory" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A grouping or set of PerformanceIndicatorSpecifications that are classified together because of common characteristics, such as technology specific, service specific, or technology/service independent.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="indicatorType"
type="perf:IndicatorType" minOccurs="1" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A kind of value that the PerformanceIndicator can take on, such as numeric, text, and so forth.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is mandatory</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="derivationAlgorithm"
type="xsd:string" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>A step-by-step procedure used to calculate the value of the PerformanceIndicator.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="derivationMethod" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>For simple calculations, the method used to calculate the value of a PerformanceIndicator, such as average, minimum, maximum, sum, and so forth.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="collectionType"
type="perf:CollectionType" minOccurs="1" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>The type of the collection such as: gauge, commulative, status inspection. Indicators can be produced using these methods.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is mandatory</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="indicatorUnit" type="xsd:string"
minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>The unit by which the indicator is measured.
For example: seconds, KBs, rate per second, etc.</p>
<p>This element is generated from an attribute.</p>
<p>This attribute is optional</p>
<p>This attribute is AVC enabled</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="ArrayOfPerformanceIndicatorSpecification">
<xsd:sequence>
<xsd:element name="item"
type="tns:PerformanceIndicatorSpecification" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
In short, we are generating an XSD for an assocation class in the model which is not referenced by any entity and which cannot be retrieved across the interface which seems fairly useless.
So my question is;
What is the PerformanceIndicatorSpecRelationship for?
Should association classes actually be treated as Entities so that they can be referenced through entity identifiers and be used for indirection between A and Z end's ( that way when an association changes, it makes sense to send an association value change event) .
Or or should they be treated a data types which are embedded in entities and contain the entity identifier of the other end artefact. Whatever the answer is, we aren't doing anything useful at the moment.
Please see the generated Java implementation attached for some ideas.
This is a blocking issue for completing the RI/CTK code for PM
Craig
|
