Mark
When
you refer to the end user, do you mean the user of the COSMOS UI? Or do you
mean the developer who is using COSMOS to construct an MDR?
For
the user of the COSMOS UI, I agree that she should not be exposed to XML. The
COSMOS UI should transform the XML into meaningful visualizations.
But
I think the developer of a CMDBf component like an MDR should be exposed to the
XML, almost as a requirement. I don’t see how she could develop an MDR
without knowledge of XML.
A
related topic is performance. Serialization and de-serialization between XML
and POJOs can be expensive. The developer should have the choice, based on the
circumstances, whether to use POJOs or process the XML directly. For example,
searching thru XML for a particular node using an XML parser probably uses less
memory and is faster than the transforming the XML to POJOs and searching thru
the POJOs.
My
original reason for exposing XML was to make COSMOS more compatible with
NON-COSMOS CMDBf components, to increase adoptability. If we require COSMOS
POJOs in our interfaces, don’t we eliminate any possibility of compatibility?
Regards
Bill
From:
cosmos-dev-bounces@xxxxxxxxxxx [mailto:cosmos-dev-bounces@xxxxxxxxxxx] On Behalf Of Mark D Weitzel
Sent: Tuesday, February 12, 2008
10:30 AM
To: Cosmos
Dev
Cc: Cosmos
Dev; cosmos-dev-bounces@xxxxxxxxxxx
Subject: Re: [cosmos-dev] RE:
Registration code and sample
I'd like to think a bit more about one of Bill's
comments below:
<<
Also I do expect XML to be passed in and consumed
by consumers, instead of COSMOS POJOs. >>
I
don't think we want to have the end user, in this case a developer, be exposed
to XML. We need to make sure we have clean layering in our code, and it
makes sense to have a web services layer that performs the serialization and
deserialization. Within this layer, the framework should do as much of
the XML processing as possible. We don't want XML to bleed through into
the different areas of the code. Lots of reasons for this, but perhaps
the most important one is that we can encapsulate the impact of change in a
single area.
If
I were to think of this in programming model terms, I would like the developer
to be using POJOs and not working with XML.
-mw
_______________________________________________________________________________________________________________
Mark Weitzel | STSM | IBM Software Group | Tivoli | Autonomic Computing | (919) 543 0625
| weitzelm@xxxxxxxxxx
|
![]()
|
|
Re: [cosmos-dev] RE:
Registration code and sample
|
|
David Whiteman
|
to:
|
Cosmos Dev
|
02/12/08
09:38 AM
|
|
Sent by:
|
cosmos-dev-bounces@xxxxxxxxxxx
|
Please respond to Cosmos Dev <cosmos-dev@xxxxxxxxxxx>
|
|
|
All our APIs are provisional, which means we shouldn't have to deprecate anything
before 1.0, right? I.e. adopters understand that the APIs are subject to
change at this point. Besides, our set of adopters (while growing) is
still small, so we should be able to notify all those parties about the change,
and therefore not have something to clean up later.
David
|
Hubert H Leung
<hkyleung@xxxxxxxxxx>
Sent by: cosmos-dev-bounces@xxxxxxxxxxx
02/11/2008 06:34 PM
|
Please
respond to
Cosmos Dev
<cosmos-dev@xxxxxxxxxxx>
|
|
|
To
|
Cosmos Dev
<cosmos-dev@xxxxxxxxxxx>
|
|
cc
|
Ali Mehregani <amehrega@xxxxxxxxxx>,
cosmos-dev-bounces@xxxxxxxxxxx, Cosmos Dev
<cosmos-dev@xxxxxxxxxxx>
|
|
Subject
|
Re: [cosmos-dev] RE: Registration code and
sample
|
|
I agree with Bill's comment about changing the "query" API to "graphQuery"
to match the operation name. I will make the refactoring in COSMOS code
tomorrow. To avoid breaking existing code, I will keep the query API and
mark it deprecated. I will remove it in i10.
_________________________
Hubert Leung
IBM Toronto Lab
hkyleung@xxxxxxxxxx
905-413-3382
|
"Muldoon, William H"
<William.Muldoon@xxxxxx>
Sent by: cosmos-dev-bounces@xxxxxxxxxxx
02/11/2008 05:35 PM
|
Please
respond to
Cosmos Dev
<cosmos-dev@xxxxxxxxxxx>
|
|
|
To
|
Ali Mehregani/Toronto/IBM@IBMCA
|
|
cc
|
Cosmos Dev
<cosmos-dev@xxxxxxxxxxx>
|
|
Subject
|
[cosmos-dev] RE: Registration code and sample
|
|
Ali
Actually, I prefer that the parameters should
be typed to match their values. In this case, I assume we are passing mdrIds,
which are really URIs. So I would expect the interface to pass an array of URIs
instead of Strings:
6)public
IDeregisterResponse deregister(URI[] mdrIds) throws DataManagerException
Also I do expect XML to be passed in and
consumed by consumers, instead of COSMOS POJOs. Even though COSMOS POJOs may be
more convenient for COSMOS clients, XML has the advantage of matching the CMDBf
standard and being compatible with NON-COSMOS clients. Using XML, NON-COSMOS
clients are more likely to operate with COSMOS MDRs and the COSMOS UI should be
more likely to operate with NON-COSMOS MDRs. If necessary, COSMOS clients can
always use the COSMOS transformation utilities to convert between the XML and
COSMOS POJOs.
In general, I think that we can maximum COSMOS usability and adoptability by
aligning our COSMOS interfaces, operations and parameters with the standard
definitions.
For example, the COSMOS MDR
“query” operation name doesn’t match the CMDBf standard:
public Element query(Element request)
I would prefer it to be:
public Element graphQuery(Element request)
Since it’s different, COSMOS adopters
will need to understand that the COSMOS MDR “query” operation
really is the same as the CMDBf MDR “graphQuery” operation.
But if we used the same name, then anyone using COSMOS who is familiar with
CMDBf would intuitively realize that this operation must be the CMDBf
“graphQuery” operation.
Regards
Bill
PS I’m including cosmos-dev for other opinions about the COSMOS
interfaces
From: Ali Mehregani [mailto:amehrega@xxxxxxxxxx]
Sent: Monday, February 11, 2008 3:52 PM
To: Muldoon, William H
Cc: Sheldon Lee-Loy; Mark D Weitzel
Subject: RE: Registration code and sample
Bill,
> Shouldn’t the “String[]
mdrIds” be “Element mdrIds”?
Can you explain why 'Element mdrIds' is preferred over 'String[] mdrIds'? There
has been a separate discussion threat with Mark W. about reducing client-side
"XML bleeding". See https://bugs.eclipse.org/bugs/show_bug.cgi?id=217704.
Therefore I need to understand why you think providing an Element
parameter by a client is more suitable than an array of string.
> Also, shouldn’t the server side interfaces “mirror” the
client side interfaces?
Preferably it should but not if it's at the cost of introducing complexity on
the client side. i.e. the methods adopters typically interact with should
be intuitive. That goal shouldn't be overlooked by having symmetric
client/server side interfaces.
e.g. It's completely fine having public Element query(Element
request) on the server side but we can't expect XML fragments
to be passed in and consumed by clients. So the equivalent client side
method should be public IQueryResponse query(IQuery
request).
Thanks,
Ali Mehregani
Phone Number: (905) 413-3712
Service Modeling Language - COSMOS
http://www.eclipse.org/cosmos/
|
"Muldoon, William H"
<William.Muldoon@xxxxxx>
11/02/2008 01:55 PM
|
|
To
|
Ali Mehregani/Toronto/IBM@IBMCA
|
|
cc
|
Sheldon Lee-Loy/Toronto/IBM@IBMCA, "Mark
D Weitzel" <weitzelm@xxxxxxxxxx>
|
|
Subject
|
RE: Registration code and sample
|
|
Ali
The client signatures look good, except for #
6:
6)public
IDeregisterResponse deregister(String[] mdrIds) throws
DataManagerException
Shouldn’t the “String[]
mdrIds” be “Element mdrIds”?
Also, shouldn’t the server side
interfaces “mirror” the client side interfaces?
Regards
Bill
From: Ali Mehregani [mailto:amehrega@xxxxxxxxxx]
Sent: Monday, February 11, 2008 10:33 AM
To: Muldoon, William H
Cc: Sheldon Lee-Loy; Mark D Weitzel
Subject: RE: Registration code and sample
Hi Bill,
Thanks for your feedback.
The method signatures of the client side code is important to be consistent. I
agree FederatingCMDBClient.register(String managementDomainEPR) should be
Federating.register(EndpointReference
managementDomainEPR). However, the method signatures defined on the
server side code are not as visible to adopters. The parameter types
defined for the server side methods need to be serializable to/from XML. A
serializable object doesn't need to be registered if the parameter type is
Element/String. Therefore, I'm reluctant to change the signatures of
org.eclipse.cosmos.dc.mdr.registration.AbstractFederatingCMDB.java.
The method signatures of the client side code (i.e. org.eclipse.cosmos.dc.mdr.registration.client.FederatingCMDBClient) will be
changed to:
1)public
IRegisterResponse register (IRegisterRequest registrationRequest) throws
DataManagerException
2)public
IRegisterResponse register (EndpointReference[] mdrEPRs)throws
DataManagerException
3)public
IRegisterResponse register (EndpointReference[] mdrEPRs, IQuery query) throws
DataManagerException
4)public
IRegisterResponse register (EndpointReference managementDominEPR) throws
DataManagerException
5)public
IDeregisterResponse deregister(IDeregisterRequest deregistrationRequest) throws
DataManagerException
6)public
IDeregisterResponse deregister(String[] mdrIds) throws
DataManagerException
7)public
IDeregisterResponse deregister(IQuery query) throws
DataManagerException
8)public
IDeregisterResponse deregisterAll() throws
DataManagerException
Let me know if you agree with the client-side method signatures.
Thanks,
Ali Mehregani
Phone Number: (905) 413-3712
Service Modeling Language - COSMOS
http://www.eclipse.org/cosmos/
|
"Muldoon, William H"
<William.Muldoon@xxxxxx>
11/02/2008 10:14 AM
|
|
To
|
Ali Mehregani/Toronto/IBM@IBMCA, Sheldon
Lee-Loy/Toronto/IBM@IBMCA
|
|
cc
|
"Mark D Weitzel"
<weitzelm@xxxxxxxxxx>
|
|
Subject
|
RE: Registration code and sample
|
|
Ali
Thanks! This will be very useful. I have a minor
comment. The interface is a little inconsistent with the parameter usage of
EPRs. Some operations accept EPRs in the parameters:
public
Element register (EndpointReference[] mdrEPRs) throws
DataManagerException
While other operations accept EPRs as strings or elements in the parameters:
public
Element register (String managementDominEPR) throws
DataManagerException
public
Element registerMDREntries(Element mdrReferences) throws CMDBfException;
Shouldn’t all operations accept EndpointReference parameters?
Regards
Bill
From: Ali Mehregani [mailto:amehrega@xxxxxxxxxx]
Sent: Friday, February 08, 2008 5:59 PM
To: Sheldon Lee-Loy; Muldoon, William H
Cc: Mark D Weitzel
Subject: Registration code and sample
Hi Sheldon/Bill
The registration code and sample are complete. You will need the
following set of plug-ins to be able to run the sample:
org.eclipse.cosmos/examples/org.eclipse.cosmos.samples.cmdbf.services
org.eclipse.cosmos/examples/org.eclipse.cosmos.example.mdr
org.eclipse.cosmos/examples/org.eclipse.cosmos.example.mdr.registration
org.eclipse.cosmos/data-collection/org.eclipse.cosmos.dc.dataManager.client
org.eclipse.cosmos/data-collection/org.eclipse.cosmos.dc.mdr.client
org.eclipse.cosmos/data-collection/org.eclipse.cosmos.dc.mdr.registration
org.eclipse.cosmos/data-collection/org.eclipse.cosmos.dc.mdr.registration.client
org.eclipse.cosmos/data-collection/org.eclipse.cosmos.dc.mdr.registration.common
org.eclipse.cosmos/tests/common/org.eclipse.cosmos.common.tests
org.eclipse.cosmos/tests/data-collection/
org.eclipse.cosmos.example.mdr.registration.tests
To exercise the registration code, run the following JUnit class:
org.eclipse.cosmos.example.mdr.registration.tests/src/org.eclipse.cosmos.example.mdr.registration.internal.core/TestSampleFederatingCMDB.java
Important: Before running the JUnit test, open
‘testMessages.properties’ under the same package and modify
‘testTempDirectory’ to point to a valid temporary directory.
You may need to modify other variables under this file based on your
configuration.
Studying this JUnit will give you a good overview of the types of APIs that are
available for registration. In summary you can register configuration
items based on:
- A registration request
- Via a query result set submitted to a set of MDRs
- All configuration items of all MDRs
Almost symmetric APIs are available for deregistration. Please let me
know if you have problems running the sample.
Thanks,
Ali Mehregani
Phone Number: (905) 413-3712
Service Modeling Language - COSMOS
http://www.eclipse.org/cosmos/ _______________________________________________
cosmos-dev mailing list
cosmos-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cosmos-dev
_______________________________________________
cosmos-dev mailing list
cosmos-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cosmos-dev_______________________________________________
cosmos-dev mailing list
cosmos-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cosmos-dev
