Jump to: navigation, search

Difference between revisions of "Orion/Planning Meeting/Server integration"

Line 21: Line 21:
  
 
* OSLC allows data linking between development artifacts in the development tool domain
 
* OSLC allows data linking between development artifacts in the development tool domain
* Similar data linking approach could be used in other domains
+
* 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.
  
 
How can I write a service that adds extra data to the output of another service
 
How can I write a service that adds extra data to the output of another service
 
+
*
  
 
Service to service contracts
 
Service to service contracts
Line 39: Line 40:
 
* Integration of link to RSS feed or whatever done at the client
 
* Integration of link to RSS feed or whatever done at the client
  
* California is not as sunny as we thought
+
* California is not as warm and sunny as we thought

Revision as of 14:58, 18 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.

Some composite services

  • Some services depend on other services
  • Service discovery
    • REST principles via links
    • Currently have runtime service link injection

No solution yet for cross-domain server integration

    • How does resource link injection work when services reside in different processes, or on different domains


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

How can I write a service that adds extra data to the output of another service

Service to service contracts

    • What do I allow another service to do
  • Use Pubsub for inter-service collaboration
    • File service publishes information on file changes, and search indexer subscribes (for example)
    • HubBubPubSub
    • 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