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.

<mdw> I agree with the general concept that adding persistence in the broker and domain may improve the qualities of service that we offer. The issue I raised is that we have not completely thought through these scenarios.

For example, what is the difference b/t initialization of the domain vs. recovery of a crash? How do we know this? What are the "initialization" steps of the domain (and by extension broker). These are undefined at this point.

Given where we are, let's just write a file down. We won't have to worry about sql, jdbc, db schema, et. All we have to do is serialize the EPRs. This would allow you to use notepad for system initialization. The initialization scenario is like this: read the file and inflate the EPRs.

We would end up with the Domain being a subclass of Object. It would have a single property, dataBroker. The property could be either a string or a muse EPR. We'd have the following methods:

initialize() //reads the file persist() //writes it's contents

To me, this is the most simple thing we can do and is all we need at this point. </mdw>

<bill> although using a simple file sounds trivial, it introduces some issues:

a. Security is relegated to OS file permissions. (A database has built-in security)

b. Concurrency must be enforced in the code: updates require code to lock the entire file, impeding scalability. (A database can use row level locking and transactions to allow read/write concurrency)

c. a file is more vulnerable to corruption. (A database has built-in recovery mechanisms)

d. a file requires serialization/deserialization code. (iBatis alleviates the need for sql and jdbc code to use the database)

</bill>

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

<mdw>The real issue is whether the Domain should be a query assembly. I think the Domain (and Broker) are subclasses of something much more simple, e.g. Object, not abstractquery. If we choose to persist the contents of the domain, we may choose to use an assembly, but that should not be required.

We can add a wsdm endpoint onto anything, we don't need an assembly for for this. </mdw>

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.

<mdw> Short answer: yes. Longer answer.....

I think we need to separate out some concepts here.

The DC runtime is a framework for accessing and transforming data from a database. It introduced the notion of a container to help manage itself.

WSDM is a pattern of exposing stateful resources and their management through web services.

Right now, assemblies are the king of everything and everything they do is exposed as its own resource--through the annotations. This is another area where I think we can simplify by encapsulating the assemblies inside the Data Manager. I think the assemblies should be an optional component, not a required one.

The result is that the annotation work that we have in COSMOS blends the two things together in a way that sometimes confuses and obfuscates the architectural layers. It's difficult to separate the framework from the implementations of the framework, from the remote layer.

The way the WSDM tooling works is that you define the endpoint that you want to expose, then bind it to an implementation. The layers are very clear when you do this b/c of the way things are generated. So.... To expose the DC components, you would start by defining the capabilities (a.k.a. remote interfaces) that you want, then, through the deployment descriptor, bind them to the implementation classes that we've coded up.

We have a number of enhancement requests to reconcile these two things and establish when it's appropriate to use annotations vs. a "wrapper". Both have their advantages/disadvantages, but in general, I'd like to bring these things closer together. That's one reason for bringing in the WSDM tooling. One key thing about using the wrapper approach is that it's very clear what you are doing and how things work. I'd like to start moving more towards this approach. </mdw>

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).

<mdw> Right now, in i7 & i8, we have only data brokers. In fact, only a data broker. So while I agree there could be other services that the framework offers, I think it's premature to define the classification scheme. It seems like another piece of complexity that for i7 & i8, we could eliminate. </mdw>

Last, I think we already have the operational status capability. <mdw> Great! </mdw>

<bill>

The wrapper approach sounds like an interesting implementation alternative. It's independent of the file vs. database issue. And the internal implementation is encapsulated behind the external client API.

I suggest that we wait until the wrapper approach evolves from an ER into a concrete design and then revisit this suggestion.

</bill>