Talk:COSMOS Design 204959

This page includes all the discussion for COSMOS Design 204959.

[Sheldon's comment] I assume the apis will throw some sort of exception. For example if a user specifies a data provider that is not supported by the handler it should throw some sort of unsupported exception.

Yes, there are a few exceptions that are included:

• SelectorHandleException
• UnsupportedDataProvider
• UnsupportedSelectorHandler

[Valentina's comment] I still have a hard time mapping the SML repository notion used here to its real meaning. Reading the document content it seems that SML repository in this context is the set of java API’s implemented in COSMOS which allows generic interaction with any repository containing SML compliant data ( or generic SML model ). In this context, SML repository is NOT the COSMOS SML repository we also call Data Center repository. If I got it right I suggest changing the name to 'API for generic SML models' or something similar.

The APIs defined for the SML repository are very generic. The interfaces will allow any generic SML document to be processed. It's only our implementation that extends the set of APIs to include convenience classes for processing facet-based models. I will update the terminologies section of the document but I don't agree with introducing a new term.

Ali, if you introduce or not new terms is irrelevant and less important, my point here is that I don't understand your current SML repository definition and I want you to clarify this.

Please refer to the terminologies section

[Hubert's comment] I am interested in the part of the enhancement that deals with providing custom handlers for processing CMDBf queries. I don't get information from the design page to understand how the framework and handlers work. For example, I have a database (with an arbitrary schema) that contains information about items and relationships. How do I write handlers to process the query? What do the APIs of the handlers look like? Using an example may help with the explanation.

There are two types of handlers available:

org.eclipse.cosmos.dc.cmdbf.services.provisional.query.service.IItemSelectorHandler.java org.eclipse.cosmos.dc.cmdbf.services.provisional.query.service.IRelationshipSelectorHandler.java

As the name suggests, the first handler is used for selectors of an item template and the second handler is used to process the selectors of a relationship template. An adopter can for example provide a handler for the instance id selector of an item template by providing an implementation of the first interface. See the following classes as examples of handlers that have been created for the SML repository: org.eclipse.cosmos.rm.repository.internal.operations.cmdbf.ItemInstanceHandler.java org.eclipse.cosmos.rm.repository.internal.operations.cmdbf.ItemPropertyHandler.java org.eclipse.cosmos.rm.repository.internal.operations.cmdbf.ItemRecordHandler.java org.eclipse.cosmos.rm.repository.internal.operations.cmdbf.ItemXPathHandler.java org.eclipse.cosmos.rm.repository.internal.operations.cmdbf.RelationshipRecordHandler.java

Once the handler classes are complete, a factory class is created to construct instances of the handlers. The factory class is expected to be of type: org.eclipse.cosmos.dc.cmdbf.services.provisional.query.service.ISelectorHandlerFactory.java. See the SML repository factor class as an example: org.eclipse.cosmos.rm.repository.internal.operations.cmdbf.SMLSelectorHandlerFactory.java

The final step is to have the factory class registered with the framework using: org.eclipse.cosmos.dc.cmdbf.services.provisional.query.service.SelectorHandlerFactoryRegistration.java. A factory class is registered with an MDR ID. For example: SelectorHandlerFactoryRegistration.registerHandlerFactory(CMDBfConstants.REPOSITORY_MDRID_URI, SMLSelectorHandlerFactory.getInstance());