Cosmos Architecture Meeting 29-May-08

These are the minutes for the Architecture Meeting for 5/29/08.

Attendees

• Jack
• Ali
• JT
• Martin
• Bill
• Sheldon
• Mark
• Paul
• Hubert
• David
• Jason
• Srinivas

Agenda

• CMDBf query to SQL mapping (Hubert)
• Confirm that i12 will address 231343 -- Need getQueryServiceMetadataFromAllMDRs method on the COSMOS Broker (Jimmy)
• Close on the design for 231400 -- MDR requiring authentication (login-id and password) [COSMOS_Design_231400] (Jimmy)

Meeting Minutes

Motivation for CMDBf query to SQL mapping work

• each example will teach our users how to write an mdr.
• See if we can generalize the method to create a MDR that uses a relational database...
• going through the experiment to create an MDR will allow us to determine if our tooling is sufficient or useful
• We need some guidelines how to use the framework and determine the kinds of tooling we want to create
• We start by looking at one MDR closely and see if we can generalize the creation of a MDR

Bill comment - this is a good idea...there's a ER already open 209990

Paul comment -- The Aperic MDR doesn't use the current methodology.. what was the reason for that?

Bill comment -- wanted to use as much of the COSMOS tooling component as possible. Ran the wizard to build an MDR... Took that wizard and used JDBC... wanted to use all the CMDBf services. The most useful service was the transformation service. I wanted to use the CMDBf query services but had problems because the way it's structure. I needed to look at the problem at a higher level rather than lower level granularity. By using the query service I ended up with an MDR with poor performance(Multiple queries).

Hubert comment -- the current framework utilizes main memory processing instead of back end processing. The MDR is a wrapper that interfaces the application to the COSMOS infrastructure. For example, asking for teacher by name will result in all teacher bing in memory and then processing the list in memory to get the specific teacher. This is a problem. The framework also processes the queries in a certain order. It process the items then the relationships. This order may not be correct for a certain query. Some handlers may also be related. This is another limitation... Currently one query is associated with one handler. However there are cases where queries are related to each other.

Mark comment -- First thing we should assert... we should go off and address issues. This is going to stop adoption in Commercial products. What I would like to do is make sure that if we're going to spend the time to correct this that we do so in a way that satisfies the issues. In the case for CA you guys don't have a relation backend. We have this notion of pluggable back ends. but we have to balance those concerns. We should look at designing a general handler framework for CMDBf and data managers in general. We need to carve out some time and come back with an alternative design detailing what we have now and where we want to take it.

Bill comment -- Our components will work right now that is file base. A good idea is to look at the Aperi experience and build tools for the other cases that have a relational back end. Add more services to the MDR component. Mapping the graph query operator to sql operators is useful along with other common operations when creating a MDR. We can eventually create tools for SQL related to CMDBf.

Work Items

---

Bill will create a new ER to capture this work and mark it as a dup of 209990.

Hubert comment -- One thing to do in i11 is to look the Example sections in the CMDBf query to SQL mapping wiki page. Start with an implementation and extract design pattern from the implementation...

Mark comment -- Lets take the aperi issues and understand the impact. If it's containable then we should do that. Then turn around and look at the all the suggestions relative to figuring out ways to improve our mdr framework.

Ali comment -- we should make a simple SQL version of student teacher example. A hello world for relational database... because of the configuration pain for user to set up Aperi.

Bill comment -- I asked permission to distribute the APERI sample database. The COSMOS build team will add sample database to build COSMOS will distribute a basic simplified APERI mdr that support only a dozen table. The Aperi project would take that mdr and use the full table list.

Mark comment -- Is there is a set of reports that we can do based on CMDBf query that will provide a minimal level of information based on CMDBf queries that will show configuration items based on BIRT Reports. We should have a report based on a Aperi Data. We need to talk with aperi to determine the kinds of reports that we can create. We also need to find some way to make a generalized CMDBF report (similar to the graph viewer). Both scenarios are valid. It would be good if we have a report that can be immediately applied to a commercial CMDB (work done in the open that can reused). Lets distill out what our real requirements. We want to show CMDBf and BIRT working together. A great example is on top of aperi work. We should enable our work to allow Aperi to pick up and ship our COSMOS MDR version. We need to figure out how to make this open. Aperi Ships the MDR as a feature. Basically, APERI can use the same set of code that COSMOS uses so that Aperi can pick up and ship the MDR Bill to determine what kind of report would be useful for the APERI example database.

Meta data

Mark comment -- For 231343 we should look at discussing meta data exchange instead of using the api discussed in 231343 One question to think about... If you a cmdbf service, am I allowed to have different operation like get metadata or do I need a particular end point to be spec compliant? Does the MDR have to be it's on WSDL or not? This will effect whether or not we need 2 services or 1. My hope is to do just 1.. Let's look at MEX here and look at MEX pattern. CMDBf does not define how to get the CI. What do we want to do with 231343 and when? This work will effect various components of COSMOS. This will effect how meta data is changed and stored in the broker.. Change the way we get the url from the broker... Change the way we display info in UI. I assume there is no security concerns showing metadata.

Will this work(metadata exchange) lead to other benefits? Not sure.. It will show CMDBf folks how MEX can be used with CMDBf

Do we want to do 231343 in i12? How much is it a requirement for CA? Answer:Requirements comes from several adopters. We will move this ER to i12 and Plan review will determine if it will be included in i12

Jimmy's offline comment -- CA intends to demonstrate this capability at our annual event in November. Thus, it would be needed in i12. If the scope of the work is containable, we could wait up to i13; but that would be cutting it close. Also, there are no additional Security requirements.

Security ER

Code is checked in. Bill will verify changes.