Cosmos Architecture Meeting 13-June-08

These are the minutes for the Architecture Meeting for 13/6/08.

Attendees

• JT
• Bill,
• Jimmy
• Hubert
• Martin
• David
• Paul
• Shrinivas
• Ali
• Jason
• Naga

Agenda

• Discuss ER 212293, i.e. the Event Broker - Jimmy Mohsin
  • Is this containable in COSMOS i12?
  • CA will volunteer the resources, assuming it is containable
  • Hubi, what are the implications of this ER, given that the COSMOS Management Domain is no more?

• Discuss ER 235898, i.e. Need to add additional non-instance data to the COSMOS Broker - Jimmy Mohsin
  • Bill has volunteered for this effort
  • Determine if anyone else has requirements for this ER

• Discuss ER 231343, i.e. Need getQueryServiceMetadataFromAllMDRs method on the COSMOS Broker - Jimmy Mohsin
  • Is this containable in i12?

Meeting Minutes

Jimmy comment -- What should we name the Event Broker? An Event or Notification

Naga introduction: technical rep from CA currently working on ws notification broker for CA team.

Jimmy comment -- can we have a 2nd broker in cosmos without conflict with other broker?

Hubert comment -- yes we can have a second broker without conflict

Hubert concern that we don't want to have new features. Will this violate i12 features?

Naga comment -- We have a requirement to take the muse we notification and extend it to create a broker. Currently there's no ws notification broker based on muse.

We should create a use case to capture this work

Hubert comment -- Is muse a requirement for your work? Have you considered an implementation other than muse.

Naga comment -- We are targeting muse. We use other features from muse. Muse is a very active community. Has a good base and work... we could leverage their work.

Hubert comment -- What kind of events are you going to publish?

Naga comment -- we are in system management domain. we have different management system.based on CI. CI are removed or updated. These are the topics that we publish and subscribe. This is one part. We also want a generic platform

Hubert comment -- How does this compliment the CMDBf standard.

Naga comment -- This is total separate requirement. CMDBf has a web service interface. We want something in CDMB if someone updates cmdb we want topics that clients can subscribe to if CI are updated. We want a platform for people can leverage to implement their own point-to-point solution.

Hubert -- I remember that muse has a standard... they have 2 kinds of standard.. more for point-to-point communication.. the other is a pub/sub scenario.. the pub/sub was not complete at the time last year.

Naga -- you are refering to Howard Abrums that worked on the pub/sub work in muse

Paul -- why did we step back from muse in the last iteration?

Hubert -- there were several reasons... make the solution more light weight.. Internal adopters was not conforming to the standard because we were using muse. Our SOAP message contains extra messages that makes it work with Muse. All this made this difficult to make it clean with the standards The target platform was the Web Server. The anotation work was new and not stable for production use. This is why we moved to axis2 Naga -- are you moving away from muse?

Hubert -- Mark will need to answer that question.

Jimmy -- will create a use case to cover this work

Hubert -- are you thinking about the topic and base notification?

Naga -- Yes.

Bill -- We need more information in the broker. Right now the broker has basic information such as the EPR. We need a way to indicate what type of schema a MDR supports. It would be nice for components to have a central location to determine the schema. The soap version and mdr id is part of the registration information with the broker.

Paul -- there's no danger for the information to change?

Bill -- yes the data is static

Hubert -- the namespace will identify the langauge it supports. We already have a namespace for each data manager. From the wsdl you can tell which xsd is supported by this web service. Right now we don't get the payload from the cmdbf graph response. From a technical point of view there's no problem adding attributes to the broker. we need to scrutinize what we want to save in the broker so that we reduce the need to synchronize the attributes between the mdr and broker.

Hubert -- can we consolidate the datamanager id and mdr id ? Who's responsible to configure the mdr id? Does the id come from the application or the MDR layer? I have a related ER for getting the display name and MDR id from the data manager from the web services(233690). Getting the mdrid from an mdr is not part of the standard. There's no standard interface to get the mdrid.

231343 comments

we add another service on the broker to get all service meta data. Not all information should be stored on the broker. This information is dynamic.

Hubert comment -- why can't the client do this work. why are we asking the broker doing this. This is a convenient api.

Bill -- This opens a question to a broker.... our goal is not to query the individual MDR to get dynamic data.

Martin -- why can't you have a web service to query the web service. Where do we situate the code? Hubert -- the code is more appropriate for the client.

Ali -- can't you extend the broker client? Adopters can extend the broker client. I agree it shouldn't be part of the broker service

The benefit of this work will make it easier for application to filter content based on meta data.

Next Steps

• Sheldon will follow up with Eclipse legal on Dojo
• Bill will create the design and use case for 235898
• Jimmy will create use cases for 212293, 235989,231343