[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cosmos-dev] Review of enhancement 200222
|
My own comments based entirely on the
wiki content - I did not attend the architecture meeting on Thursday.
They are also logged on the talk page
1. I don't think this comment is accurate 'According to
the CMDBf specification, a repository will need to provide two services
for it to be considered as an MDR : query and registration'.
I searched the CMDBf spec and couldn't see any normative
requirements that a database MUST implement both services in order to be
an MDR. Since I can't find this in the spec, using my own logic makes me
think that an MDR MUST implement only the QueryInterface since a client
seems to be able to connect directly to an MDR and ask for data. The registration
service is requited when the MDR is part of a CMDB federation where the
federating CMDB uses the push mode to get the data.
- 2. I understand that this design focuses only on the i6
deliverables which as far as I get from this document are as below. We
can probably call this out more clearly
- no federating CMDB
- the client will directly access the MDR and get data through
the query service
- there is going to be only one MDR in COSMOS i6 the user
can query from. This will be the COSMOS SML repository;
- a Query Service will be implemented for the COSMOS SML
repository
- the Registration service, as described by the CMDBf spec
will not be implemented for i6 ( especially since no federating CMDB is
around to make use of it )
The set of goals we
have for i6 make sense to me, having the timeframe and resources allocate
to do this work. I think we should also mark here the work that needs to
be done next in order to declare full CMDBf support. The items that I would
note so that we don't loose track of them:
- taxonomy for common data query/registration support
- The usecase for i6 has only one MDR, which is the COSMOS
SML repository; the data queried by the client is COSMOS SML type agnostic,
which means the client creates a CMDBf query and asks for information using
the COSMOS Data Center model structure. Once we move one step further and
implement multiple MDR support, the client will need a common language
for building a query (I don't think it's viable to assume a client must
know the data structure for every MDR he may communicate with and how this
maps to his own understanding of those notions; as an example, if the user
intention is to query for all computers with os=linux then he will have
to translate this human readable query in a data format that can be understood
by any MDR he is trying to query; in one MDR, a 'computer' may be called
'asset' while in another it may be called 'node').
- the obvious one is implementing a federated CMDB
Thank you,
Valentina Popescu
IBM Toronto Labs
Phone: (905)413-2412 (tie-line 969)
Fax: (905) 413-4850
"Ali Mehregani"
<ali.mehregani@xxxxxxxxx>
Sent by: cosmos-dev-bounces@xxxxxxxxxxx
09/06/2007 02:50 PM
|
Please respond to
Cosmos Dev <cosmos-dev@xxxxxxxxxxx> |
|
|
To
| "Cosmos Dev" <cosmos-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| [cosmos-dev] Review of enhancement 200222 |
|
Summary of the design review for enhancement 200222
The following design document was reviewed during the architecture meeting
on September 6th, 2007:
http://wiki.eclipse.org/COSMOS_Design_200222.
Here's a summary of the review:
1. Mark: General question about the design document of enhancements:
Should a design document include detail about namespaces/package names/WSDM
capabilities/etc… that an enhancement will introduce?
- That level of detail should only be included if it affects
other subproject and/or clients who intend to extend COSMOS.
- The information should also be captured under a separate
wiki page and be accompanied as part of the Eclipse help with the WSDM
tooling.
2. Mark/Joel: The last figure under the architecture section is misleading.
The connection and the operation fetch are not network operations.
The method of fetching and using the query service for MDRs should
be flushed out under enhancement: https://bugs.eclipse.org/bugs/show_bug.cgi?id=200244
- Renamed "client" to "query service provider"
- Added a paragraph after the figure to better explain the
scope
- Further generalized enhancement: https://bugs.eclipse.org/bugs/show_bug.cgi?id=200244
3. David: There is no mention of applying the property subset directive
in the flow diagram:
- This step was missed in the diagram. It is a post
fetch operation that will be handled for itemTemplates.
4. Sheldon: A mirror operation of the output transformer should be
provided for the client to be able to convert an XML query response into
a POJO graph representation.
- Agreed: Modified the design document accordingly
5. Hubert: More detail needs to be provided about the common components
that will reside under the data collection subproject.
- David is working on the input/output transformations and
he will work closely with Hubert to flush out the common components.
- The outcome of their discussions will be posted on the
mailing list.
6. Hubert: How does the client know what to query for without any
pre-knowledge of the data stored in a repository?
- This falls outside the scope of this enhancement but it
is an open question that needs to be addressed by the data collection subproject.
7. Hubert: Why does applying the instance and record type selectors
before property and xpath selectors make a difference in terms of performance?
- This is completely a repository implementation detail.
The SML repository is implemented in a way that will process instance
and record type selectors faster than the property and the xpath selectors.
It is not a common sequence of steps that all MDR query services
are expected to follow.
Please use the talk page included at the bottom of the design document
to add questions/comments/concerns.
_______________________________________________
cosmos-dev mailing list
cosmos-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cosmos-dev
