COSMOS Design 218313

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.

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

---