Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "COSMOS Design 218313"

(→‎''' Implementation Detail ''')
 
Line 123: Line 123:
  
 
== ''' Test Coverage ''' ==
 
== ''' Test Coverage ''' ==
−
Unit tests will need to perform the following tests:
+
There will be new JUnits created under org.eclipse.cosmos.example.mdr.registration.tests to exercise the code for the registration manager.  The following list gives an overview of the tests that will be included:
  
−
* Complex tests outlined in the Use Cases section of this document
+
* Register a set of elements.  Expected return value: registration response with accepted elements
−
* Tests using an instance selector, one with 0 results and one with exactly 1 result.  More than one result will be logged as a failure.
+
* Update elements with unchanged time stamp.  Expected return value: registration response with declined elements
−
* Tests using a property value selector, one for each of the following operators:
+
* Update elements with records that have missing time stamp.  Expected return value: registration response with accepted elements
−
** equal (caseSensitive attribute set to true, set to false, and omitted; negate set to true, false, or omitted; string, boolean, time, and integer types used)
+
* Update elements with changed time stamp.  Expected return value: registration response with accepted elements
−
** less (negate set to true, false, or omitted; string, time, and integer types used)
+
* Update a mix of items and relationships with changed time stamp.  Expected return value: registration with accepted elements
−
** lessOrEqual (negate set to true, false, or omitted; string, time, and integer types used)
+
* Update elements that have not been registered.  Expected return value: registration with accepted elements
−
** greater (negate set to true, false, or omitted; string, time, and integer types used)
+
−
** greaterOrEqual (negate set to true, false, or omitted; string, time, and integer types used)
+
−
** contains (caseSensitive attribute set to true, set to false, and omitted; negate set to true, false, or omitted)
+
−
** like (caseSensitive attribute set to true, set to false, and omitted; negate set to true, false, or omitted)
+
−
** isNull (negate set to true, false, or omitted)
+
−
* Tests using a record type selector:
+
−
** type is exact type match
+
−
** type requested is supertype of existing record
+
−
* Tests using an XPath selector:
+
−
** using correct syntax for expression, with and without results
+
−
** using incorrect syntax for expression
+
−
* Tests combining 2 item templates and a relationship template, that use a drop selector to exclude the relationship template and the 2nd item template
+
−
* Tests using a property subset directive
+
−
** with two properties listed
+
−
** with no properties listed
+
−
* Tests using relationship cardinality, using minimum, maximum, and both attributes
+
  
−
== ''' Task Breakdown ''' ==
 
−
<p> The following section includes the tasks required to complete this enhancement along with a PERT chart that displays the dependencies of each task. </p>
 
−
<p> create sql methods to work with existing CBE COSMOS schema
 
−
[[image:QueryService-PertChart.png]]
 
−
</p>
 
−
<p>
 
−
# Create graph representation of query input and response 
 
−
# Create the input transformer 
 
−
# Create the output transformer 
 
−
# Add in the query service as an SML repository operation 
 
−
# Create a generic framework for implementing selectors 
 
−
# Add in the instance id selector   
 
−
# Create JUnit tests for the instance id selector   
 
−
# Add in the record type selector   
 
−
# Create JUnit tests for the record type selector   
 
−
# Add in the property value selector   
 
−
# Create JUnit tests for the property value selector   
 
−
# Add in the xpath selector   
 
−
# Create JUnit tests for the xpath selector 
 
−
# Implement the property subset directive   
 
−
# Ensure that all selectors work with <code>itemTemplate</code> elements   
 
−
# Implement the relationship template constraint   
 
−
# Add Junit tests for querying items and relationships   
 
−
</p>
 
−
 
−
== '''Related Links '''==
 
−
 
−
* [[COSMOS Design 204959|204959 Design for refactoring of this work to be extensible]]
 
−
 
−
== '''Open Issues/Questions '''==
 
−
 
−
All reviewer feedback should go in the [[Talk:COSMOS_Design_200222|Talk page for 200222]].
 
−
 
−
Issues (and potential errors) regarding the CMDBf spec, v0.95.  Email responses from a member of the CMDBf expert group are marked in <font color=red>red</font>.
 
−
*  All of the examples and psuedo-schema in section 4.3.1 for <tt><prefixMapping></tt> have the attributes "prefix" and "'''value'''".  However, the data model XSD in appendix B (and on the CMDBf site) lists the following as the two <tt>prefixMapping</tt> attributes as "prefix" and "'''namespace'''".  When I wrote some <tt><query></tt> testcases based on the samples in the CMDBf spec, the schema validation failed.
 
−
* In the query result example in section 4.4, both <relationship> instances have the same recordId as each other. <font color=red>Agree</font>
 
−
* In the relationship records in that example, the "foo" namespace maps to http://example.com/computerModel in both cases?  Earlier, "comp" was used with that same URL, so it would seem the URL would need to be changed in the "foo" case, or the "foo" example should use "comp" again. <font color=red>Agree</font>
 
−
* On line 1205, it says <nowiki>"http://example.com/administers/PeteTheLabLabTechToLabMachineA"</nowiki>.  Note the "LabLab" typo. <font color=red>Agree</font>
 
−
* All of the included examples (such as on line 1086) begin with <tt><query></tt>.  I believe they should instead look like this: <tt><query xmlns="http://schemas.cmdbf.org/0-9-5/datamodel"></tt> Making this change will make the query service code a lot easier to write, as the SAX validating parser only works if it has the correct <code>xmlns</code> value.  It looks like some revisions of the document did include an <code>xmlns</code> attribute, but for some reason it was not included in the current one available at cmdbf.org. <font color=red>That's definitely the namespace for the <query> so including it is certainly correct & you should feel free to do so.</font>
 
−
* Line 757 should be </contains> instead of </stringContains> <font color=red>Agree</font>
 
−
* According to the pseudo schema of xpath1Selector, there are 0 or more prefix mappings that can be included under <xpath1Selector>.  The CMDBf data model schema does not specify a minOccurs/maxOccurs for the prefixMapping element.  <code><xs:element name="prefixMapping" type="cmdbf:PrefixMappingType" /></code> should be: <code><xs:element name="prefixMapping" type="cmdbf:PrefixMappingType" minOccurs="0" maxOccurs="unbounded"/></code>
 
 
----
 
----
 
[[Category:COSMOS_Bugzilla_Designs]]
 
[[Category:COSMOS_Bugzilla_Designs]]

Latest revision as of 15:36, 6 March 2008

Extend the registration libraries to make it easier to maintain data integrity between MDRs and federating CMDBs

Change History

Name: Date: Revised Sections:
Ali Mehregani 03/06/2008
  • Initial creation

Workload Estimation

Rough workload estimate in person weeks
Process Sizing Names of people doing the work
Design 0.5 Ali
Code 0.5 Ali
Test 1 Ali
Documentation 0.5
Build and infrastructure 0.1
Code review, etc.* 0.1
TOTAL 2.7
  • - includes other committer work (e.g. check-in, contribution tracking)

Terminologies/Acronyms

The terminologies/acronyms below are commonly used throughout this document. The list below defines each term regarding how it is used in this document:

Term Definition
MDR management data repository
CMDBf specification for a CMDB that federates between multiple MDRs[1]
federating CMDB the CMDB that federates between MDRs, offering a common access point to clients and correlating identifying record data
CMDB configuration management database
Query service MDRs make data available to Clients via a Query service. Queries may select and return items, relationships, and/or graphs containing items and relationships.
Registration service MDR configuration items and relationships are reconciled by a federating CMDB via the registration service provided by the federating CMDB

Purpose

MDRs are required to periodically update/notify a federating CMDB of any changes to configuration items or relationships that have been registered. This will ensure data integrity between what is stored in MDRs and federating CMDBs. As part of enhancement https://bugs.eclipse.org/bugs/show_bug.cgi?id=215267, COSMOS provides a set of libraries for the registration service and client. The intend of this enhancement is to extend the registration client to make it easier for adopters to maintain data integrity. The code for this enhancement will reside in org.eclipse.cosmos.dc.mdr.registration.client.

Implementation Detail

A new class called RegistrationManager will be added to org.eclipse.cosmos.dc.mdr.registration.client to handle update notifications. The diagram below pictorially depicts the work flow for providing periodic updates.

RegistrationManager.png

An MDR is responsible to notify the registration manager of any items or relationships that's been changed. The registration manager will construct a request accordingly and send it to the registration service. The registration manager will contain the following APIs: 

/**
 * Returns an instance of the data manager based on the EPR passed
 * in.
 */
public static RegistrationManager instance (EndpointReference epr)

/**
 * Registers a set of graph elements with an associated federating CMDB.  
 * This is the first method that the MDR is expected to invoke when
 * initially registering a set of elements
 */
 public IRegisterResponse register(IGraphElementCollection elements);

 /**
  * Updates a set of elements that may have possibly changed.  This method 
  * will check the last modified time stamp of each record and will only 
  * include a graph element in the registration request if the time stamp
  * has changed.  A graph element is always included if it has an associated 
  * record with a missing last time stamp.
  *
  * Graph elements will be included in the registration request irregardless
  * of last time stamp if 'force' is set to true.
  */
 public IRegisterResponse update (IGraphElementCollection changedElements, boolean force)

 /**
  * Equivalent to update (changedElements, true)
  */
 public IRegisterResponse update (IGraphElementCollection changedElements)

Test Coverage

There will be new JUnits created under org.eclipse.cosmos.example.mdr.registration.tests to exercise the code for the registration manager. The following list gives an overview of the tests that will be included:

  • Register a set of elements. Expected return value: registration response with accepted elements
  • Update elements with unchanged time stamp. Expected return value: registration response with declined elements
  • Update elements with records that have missing time stamp. Expected return value: registration response with accepted elements
  • Update elements with changed time stamp. Expected return value: registration response with accepted elements
  • Update a mix of items and relationships with changed time stamp. Expected return value: registration with accepted elements
  • Update elements that have not been registered. Expected return value: registration with accepted elements
Retrieved from "https://wiki.eclipse.org/index.php?title=COSMOS_Design_218313&oldid=86227"

This page was last modified 15:36, 6 March 2008 by Eclipsepedia user Amehrega.ca.ibm.com.

Back to the top