Talk:COSMOS Design 197868

General Comments

• Domain is used only for boot strapping. It's primary purpose is to hold onto a well defined set of EPRs.

The EPRs will be made available via resource properties.

• The following resource properties should be available:

DataBroker http://www.eclipse.org/cosmos/DataBroker

• Is the assembly necessary?
• Can we simplify the domain to remove the assembly?

• Why do we need to persist the contents of the domain?
• Why does domain extend abstract query?

• Use the wsdm tooling to create the endpoint.

• We need to reorganize the code to separate the domain from the broker to maximize deployment options

Using WS-RF

The design and the class diagram seem to be out of sync. For example, the class diagram indicates that the ManagementDomain will have a property called "dataBroker". There is only one of these. However, the operations, et. in the design indicate that there could not only be multiple databrokers w/in a domain, but also a "service brokers".

The reason behind the domain is to provide a single place for a DataManager to go and get the other infrastructure components it needs. Because the Domain will be a WSDM endpoint, the DataBroker can simply use the "getResourceProperty(http://org.eclipse.cosmos/DataBroker)" method. No additional API should be required.

Events/Topics

What events will the Domain either emit or subscribe to?

Metadata Exchange

What is expected when we do a MEX with the Domain? Who does it and under what circumstances? Does the Domain need to support MEX?

WSDM Capabilities

"Identity"

What is the URI of the Domain?

• The base URI and namespace for the domain will be: http://cosmos.eclipse.org/ManagementDomain/1.0

How do we identify it?

What should be returned when the WSDM identity property is asked for?

Operational Status

The Domain, Broker, and MDRs should support the Operational Status capability.

See // make sure the broker is loaded... DataBrokerClient.loadDataBrokerContext( brokerHostAddress, runtimePort); This should be replaced with an operational status query.

• • ManagementDomain.pingManagementDomain() should be replaced

http://docs.oasis-open.org/wsdm/wsdm-muws2-1.1-spec-os-01.htm

Testing

• update org.eclipse.cosmos.dc.tests to include the junits (will need to convert to tptp test framework)

All other thoughts...

• Where do we get the "classifications"? See DataBrokerTests.testDataBrokerClient() This references something called "Performance" as a classification.

Bill's comments

Regarding persistence, consider the following scenario:

• 1. Domain initializes
• 2. Broker initializes and registers itself with the Domain
• 3. Clients can locate the Broker thru the Domain successfully
• 4. Domain is shutdown for maintenance (or crashes) and is restarted
• 5. New Clients attempt to locate the Broker
• 5a. with Domain persistence, the new clients can successfully locate the Broker thru the Domain
• 5b. without Domain persistence, the new clients will fail to locate the Broker (because the Broker registration in the Domain was lost during step 4)

A similar scenario applies to the Broker and Data Manager. The benefit of persistence is that it adds resilence to both the Domain and Broker components.

The assembly is necessary for the DC runtime to generate the WSDM endpoint (it extends abstractquery because its a query assembly).

Does the DC runtime currently have the ability to use the WSDM tooling to generate WSDM endpoints from a POJO? If yes, I missed this in the code (please show me where and how). If no, then we need an ER to add this ability as a prerequisite for this proposal.

The classification values are defined by the Brokers themselves during registration. For example, we may have Data Brokers and Service Brokers. The same applies to the Data Managers (they define their classification values during registration with the Broker).

Last, I think we already have the operational status capability.