COSMOSTPTPQuereryIntrfaceNotes

Proposed initial data types are table, hierarchy, and graph. The API will return strings and object references?

Our long term goal is for the query interface to support strongly typed result sets, but the short term is based on tables. We want to implement stats and hierarchy first. The APIs will be provisional (and internal) for now. The new implementations will support coexistance with the existing EMF models.

Joe Toomey pointed out a few observations with EMF: Regardless of its warts, the object oriented EMF data models deliver a lot of value that should not be lost. He is uncomfortable with generic interfaces that deliver a less formalized and complete data model, and suggests that we should agree to provide some formalized representation of the data model, be it a database schema, XML schema or UML model.

The key issue is that we have conflicting goals of functionality versus performance.(Don) Marius is less clear than Joe that we require a POJO for each part of the schema. This led to the discussion of if we are promoting a programming model v. an OO model.

• We did not discuss this from the standpoint of a "service" type of model but perhaps we should (Mark W.)

We all agreed that:

• Must not expose schema as part of the API
• Must not expose the data model as part of the API

Both of the above led to great pain and discomfort in the TPTP project.

Initial design

We talked at the F2F about simple (mostly programatic) vs POJO (with or without EMF) data model, I (Marius) think that we will have something in between and we may not surface/use EMF at the instance level.

The initial set of POJO classes would be very limited and we may also include a simple generic mechanism to represent structured data (typed or untyped) similar with SDO (initially much simpler, as we may end up using SDO at some point).

Cosmos-DMS-All-class-diagram.gif

Above is the current state of the class diagram for Cosmos data access API (DMS data management services) where most of the components will come from TPTP DMS.

For COSMOSEcliseCon2007Demo this diagram should cover the Hierarchy (we need to see if we can find a better name), Statistical and Log domains.

For COSMOSEcliseCon2007Demo the Hierarchy data will reside in SML/SML-IF files so we will provide an IDataStoreProvider for SML/SML-IF files.

The Statistical and Log data will be stored in a database and we will create an IDataStoreProvider that will be shared by both data services implemented on top of a Derby database. As the data will be the current TPTP data we will use the TPTP large resource support schema plus some new views created specifically for this DMS interactions, this will easily let us populate the data store (using TPTP workbench).

The BIRT scripted data sources defined in COSMOS-Demo-EclipseCon2007.zip will eventually use the IDataAccessController and the specific IDataService's to build the report input data.

Comments on Initial Design

• The IDataAccessController contains API that contains information about a registration of domains. This should be factored out into a distinct interface. The lifecycle of the service is distinct from the operation, e.g. transaction

• This model does not yet reflect the IResourceDataService

• We would like to see the same kind of diagram for the hierarchy model.

• Describe how the data service is initialized. We indicated that for the demo, we could hard code this.

• Data services are intended to be added via extension points. We need to document what this extension point is as it’s a candidate API.

• When performing lookups of the components, there should be a layer of indirection so that we can dynamically bind them together.
  • Each component will need a way to describe itself

• There are multiple deployment targets where this layer may run.
  • Tomcat and OSGi

Comments on IResourceDataService

Currently this interface has defined four methods, each of which returns a command that gets executed.

IDataServiceCommand getNodes(IDataSource ds, IDataContext context, IDataOutputFormat dof);

IDataServiceCommand getRefs(IDataSource ds, IDataContext context, IDataOutputFormat dof);

IDataServiceCommand getNodeProperties(IDataSource ds, IDataContext context, IDataOutputFormat dof);

IDataServiceCommand addResources(IDataSource ds,IDataContext dataContext,String inputDataFile, String inputDataFileFormat); }

This interface already is combining the read and write behavior. We had wanted to keep these separate.

Adding resources should be in a different interface.

The API we are discussing is what is immediately below the blue line in the picture above. What we have is a generic API. It is completely un-typed and has no notion of the kinds of resources that are returned. If we contrast this with the IStatisticalDataService, these have an API that is more specific to statistical data, e.g. getOberservations().

The resource API should be modified so that we are not talking about ‘nodes’ but resources. The API may look like

getResource(String uriOfResourceType)

We should understand the model that was used underneath the Managed Agent Explorer because it has some of the same concepts, although it may not be applicable.

The conversion in to nodes should happen in the user interface layer b/c this is where we need a completely generic API.