COSMOS Design 209987

Create an example CMDBf Management Data Repository backed by a relational database

Change History

Name:	Date:	Revised Sections:
John Todd	12/11/2007	Initial version (was WIP)
Bill Muldoon	3/04/2008	Updated purpose and content

Workload Estimation

Rough workload estimate in person weeks

Process	Sizing	Names of people doing the work
Design	unknown	TBA
Code	unknown	TBA
Test	unknown	TBA
Documentation	unknown	TBA
Build and infrastructure	unknown	TBA
Code review, etc.*	unknown	TBA
TOTAL	unknown	TBA

'* - 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

Purpose

Currently the COSMOS Example MDR uses XML files as its store. However, many management repositories use relational databases to store their management data. We would like to have a more sophisticated exemplar MDR, called the RDBMS MDR, that can access these relational databases. The advantages are:

• Potential adopters can use the RDBMS MDR to access their current management databases.
• The RDBMS MDR can utilize the database security mechanism as an example implementation of COSMOS security.
• The RDBMS MDR can illustrate the transformations between the native data representation and SML.

Requirements

The RDBMS MDR needs to support the CMDBf Query Service and CMDBf Service Metadata.

Implementation details

CMDBf Query Service

The RDBMS MDR will process a CMDBf graphQuery request as follows:

1. Connect to the database using the security credentials from the client

2. Transform the CMDBf graphQuery request into a relational database query

3. Execute the relational query against the database

4. Process any database error, or

5. Transform the query result into a CMDBf graphQuery response

6. Disconnect from the database

CMDBf Service Metadata

The RDBMS MDR service metadata will be constructed from the database catalog.

Test Coverage

<TODO>

Open Issues

Which databases should the RDBMS MDR support?

Derby? MySQL? SQLServer? Oracle? DB2?

<March Summit Update> Since we decided on an API, this question is moot. </March Summit Update>

Should the RDBMS MDR use generic JDBC to any database or should it be specific to a management database API (like Aperi DBAccess)?

<Bill's comments>

Mark, I took a look at http://www.eclipse.org/aperi/ and it looks like a storage management standard for access to a database containing information about disks, tapes, SANs, etc. There is an Aperi API called DBAccess which internally uses JDBC to access the database.

For this ER, should we build an MDR using the Aperi DBAccess API to expose this specific storage management information? Such an MDR would be mainly useful to Aperi users.

Or do we want to provide a more generic MDR that can access any relational database that supports JDBC? The advantage of a generic MDR is that it would work with any database (which includes the Aperi database). I think this would be more valuable to COSMOS adopters, especially ones that are interested in using their existing databases with COSMOS. Also as an example, it would be more useful to provide an MDR that uses JDBC instead of the Aperi DBAccess API.

Thanks, Bill

</Bill's comments>

<Mark's comments>

Bill,

A couple of thoughts on your previous comment, with the caveat that we should confirm this with the Aperi team as well. I've copied Martine Wedlake on this enhancement.

I don't think we should be adding CMDBf APIs directly on their databases via JDBC. The reason is that this tightly couples us against a fixed database schema. Any change in the schema would potentially break all of the CMDBf work. Also, this is a completely alternate API that would need to be maintained, versus a layering on top of an existing API. Given these reasons, I think the target we should be going after is the DBAccess API, not straight JDBC.

That said, I think Aperi is a good representation of what we will find in the management space. Most management products have some kind of API sitting on top of the data store. Where I think this is important for COSMOS to demonstrate is b/c I think we will be forced to address the following issues:

• security, e.g. access to the database
• model translation--from how Aperi represents things into an SML (or SML-IF)

representation

• deployment--how do you deploy the cosmos wrapper along side, on top of, et...

the management product (this also has to do with security as well)

</Mark's comments>

<March Summit Update> After a discussion, we decided to use the Aperi API. </March Summit Update>

What are the packaging issues?

What components of the underlying database do we need to re-distribute in the package (JDBC drivers, database client API interfaces?)?

Are there any associated licensing or IP issues?

---