Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search

Orion/Planning Meeting/Server integration

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

  • File service publishes information on file changes, and search indexer subscribes (for example)
  • Some example technologies:
    • PubSubHubbub
    • RSS feeds
    • Atom pub

Push model for server announcing changes back to client

  • Same PubSub mechanism for server-server interaction could be used for client notification
  • Integration of link to RSS feed or whatever done at the client
  • California is not as warm and sunny as we thought

Back to the top