Jump to: navigation, search

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

(Add Category Orion)
 
(2 intermediate revisions by 2 users not shown)
Line 9: Line 9:
 
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.
 
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
+
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.
* Some services depend on other services
+
  
* Service discovery
+
== Service discovery ==
 
** REST principles via links
 
** REST principles via links
 
** Currently have runtime service link injection
 
** Currently have runtime service link injection
 +
** No solution yet for cross-domain server integration
  
No solution yet for cross-domain server integration
+
== Data linking ==
** 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
 
* OSLC allows data linking between development artifacts in the development tool domain
Line 24: Line 22:
 
* 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 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
+
* 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
  
* Service to service contracts
+
We agreed that the server should adopt some publish-subscribe mechanism for broadcasting changes between services.
* What do I allow another service to do
+
* File service publishes information on file changes, and search indexer subscribes (for example)
 
+
* Some example technologies:
* Use Pubsub for inter-service collaboration
+
** PubSubHubbub
** File service publishes information on file changes, and search indexer subscribes (for example)
+
** HubBubPubSub
+
 
** RSS feeds
 
** RSS feeds
 
** Atom pub
 
** Atom pub
Line 40: Line 38:
  
 
* California is not as warm and sunny as we thought
 
* California is not as warm and sunny as we thought
 +
 +
[[Category:Orion]]

Latest revision as of 18:51, 11 February 2014

  • 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