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 "COSMOS Design 238450"
(→Purpose) |
(→Requirements) |
||
Line 65: | Line 65: | ||
=Requirements= | =Requirements= | ||
+ | Add a level of abstraction around the query and registration processing framework to make it optional, and make it possible to replace the processing framework with another implementation. | ||
+ | |||
== Use case == | == Use case == | ||
+ | [http://wiki.eclipse.org/COSMOS_Use_Cases#Use_Case:_Create_a_Data_Manager 2.1.1 Use Case: Create a Data Manager] | ||
=Design= | =Design= |
Revision as of 14:26, 25 June 2008
Make query and registration processing engines pluggable
Contents
Change History
Name: | Date: | Revised Sections: |
---|---|---|
Hubert Leung | June 25, 2008 |
|
Workload Estimation
Process | Sizing | Names of people doing the work |
---|---|---|
Design | 0 | Hubert Leung |
Code | 0 | |
Test | 0 | |
Documentation | 0 | |
Build and infrastructure | 0 | Saurabh Dravid |
Code review, etc.* | ||
TOTAL | 0 |
'* - includes other committer work (e.g. check-in, contribution tracking)
Purpose
The framework for query and registration web services assumes users will use the cosmos query and registration processing framework provided in org.eclipse.cosmos.dc.cmdbf.services project. However, the framework is proven to be not generic enough for all types of MDRs. From the experience of writing example MDRs and prototypes, we have concluded that it is difficult to have a common query processing engine that work for all MDRs.
This enhancement is to adjust the framework code for query and registration web services so that we don't mandate the use of the query and registration processing frameworks in org.eclipse.cosmos.dc.cmdbf.services. Also, we want to let users plug-in another query/registration processing engine using well-defined APIs.
Requirements
Add a level of abstraction around the query and registration processing framework to make it optional, and make it possible to replace the processing framework with another implementation.
Use case
2.1.1 Use Case: Create a Data Manager