Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Orion/Planning Meeting/Server integration"
< Orion | Planning Meeting
(New page: Back end API for data store to enable deployment to cloud environments for example ** Store JSON for metadata ** Persist relationships between services How does the search service know w...) |
(Add Category Orion) |
||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | * Need back end API for data store to enable deployment to cloud environments for example | |
** Store JSON for metadata | ** Store JSON for metadata | ||
| − | ** Persist relationships between services | + | ** 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 | ** REST principles via links | ||
** Currently have runtime service link injection | ** 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 | * 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 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 | ** RSS feeds | ||
** Atom pub | ** Atom pub | ||
| Line 38: | Line 37: | ||
* 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 |
| + | |||
| + | [[Category:Orion]] | ||
Latest revision as of 19: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