Revision as of 14:23, 19 March 2011

Need back end API for data store to enable deployment to cloud environments for example

Store JSON for metadata

Persist relationships between services in a separate link store or meta store

Most of the remaining discussion centered around the problem of service to service integration. The starting assumpion is that we are in a large world of discrete, decoupled services rather than a single monolith server. How do these services interact and remain decoupled as much as possible?

We used the motivating example of a file service and a search service. The file service knows about a set of files directories. The search service knows how to crawl files to build an index, and perform queries on those file. The search and file services might reside on different hosts.

The starting point for integration in Orion will be the client. Integration between services starts when a user installs a plugin in the Orion browser client.

In some cases there will also be composite services - services depending on other services. Service integration is via REST API, or via linking in the service data.

Service discovery

REST principles via links

Currently have runtime service link injection

No solution yet for cross-domain server integration

Data linking

OSLC allows data linking between development artifacts in the development tool domain

This works will in a particular well-defined domain such as ALM where the kinds of artifacts and their relationships is defined

How do we adopt a similar data linking approach in other domains, or in the general case where services don't occupy a common domain where relationships are well defined.

There is a need for clear service to service contracts

What do I allow another service to do

What kind of data does a service expose

We agreed that the server should adopt some publish-subscribe mechanism for broadcasting changes between services.