Difference between revisions of "Cosmos Architecture Meeting 13-June-08"

Revision as of 13:59, 13 June 2008

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? David -- we 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 -- r u thinking about the topic and base notification? Naga -- Yes.

Bill -- the idea we need more information in the broker... right now it has basic informatoin such as the EPR.

   -- have a way to indicate what type of schema ... it would be nice for components to have a central location to determine what kind of schema 
   -- the soap version... anyone wanting to talk to the broker would know what 
   -- and mdr id  
   -- this is part of the registration information

Paul -- there's no danger for information will change Bill -- yes this is static Hubert -- the first may not be static...... -- the namespace will identify the langauge it supports. It's more for the data schema information --- informatoin that is static and doesn't get stale and the client does not need to query the mdr every time Hubert --- we already have a namespace for each data manager. The namespace tells the broker that ... From the wsdl you can tell the xsd supported by this web service. --- today it's a cdmbf query service.. you will see the cmdbf query namespace ... from the you can create a remote client for this service.. --- right now we don't get the payload from the cmdbf graph response...

--- from a technical point of vew there's no problem adding attributes to the broker --- there's minimum required... and reduce the need to syncronize the attributes between the mdr and broker. Keep this list short. --- we need to scrutinize what to save in the broker.

-- can we consolidate the datamanager id and mdr id ? How'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 not standard interface to get the mdrid.

231343 -- we add another service on the broker to get all service meta data .

-- this is not all information to be stored on the broker. -- this is a dynamic. -- why can't the client do this work... why are we asking the broker doing this. -- if we did this... this is a convients api. -- this opens a question to a broker.... our goal is not to query the individual to get dynamic data. Martin -- why can't u have a web service to query the web service... where do we situate the code. Hubert -- this is more appropriate to this from the client.

Ali -- can't u extend the broker client ... They can provide an extend the broker client... i agree it shouldn't be part of the broker service

COSMOS client ...

make it easier for application to filter content of the meta data.-- see value...

is this containable in i12...

Use case one for 231343 -- have some filtering thought that we have...

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