Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Cosmos Architecture Meeting 13-June-08"
(→Meeting Minutes) |
(→231343 comments) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 34: | Line 34: | ||
Jimmy comment -- can we have a 2nd broker in cosmos without conflict with other broker? | 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 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? | 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. | 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. | ||
| Line 42: | Line 44: | ||
Hubert comment -- Is muse a requirement for your work? Have you considered an implementation other than muse. | 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. | 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? | 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 | 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. | + | |
| + | 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. | 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. | 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 | 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? | 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 | 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 | 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? | Naga -- are you moving away from muse? | ||
| + | |||
Hubert -- Mark will need to answer that question. | Hubert -- Mark will need to answer that question. | ||
| + | |||
Jimmy -- will create a use case to cover this work | Jimmy -- will create a use case to cover this work | ||
| + | |||
Hubert -- are you thinking about the topic and base notification? | Hubert -- are you thinking about the topic and base notification? | ||
| + | |||
Naga -- Yes. | 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. | 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. | 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? | Paul -- there's no danger for the information to change? | ||
| + | |||
Bill -- yes the data is static | Bill -- yes the data is static | ||
| − | |||
| − | |||
| − | Hubert -- | + | 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=== | ===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. | 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 | + | |
| + | 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. | 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? | 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. | 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 | 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. | The benefit of this work will make it easier for application to filter content based on meta data. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
====Next Steps==== | ====Next Steps==== | ||
* Sheldon will follow up with Eclipse legal on Dojo | * Sheldon will follow up with Eclipse legal on Dojo | ||
* Bill will create the design and use case for 235898 | * Bill will create the design and use case for 235898 | ||
* Jimmy will create use cases for 212293, 235989,231343 | * Jimmy will create use cases for 212293, 235989,231343 | ||
Latest revision as of 12:56, 19 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?
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