Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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

Back to the top