Skip to main content

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.

Jump to: navigation, search

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

Change History

Name: Date: Revised Sections:
Hubert Leung June 25, 2008
  • Initial version

Workload Estimation

Rough workload estimate in person weeks
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

Design

Impacts of this enhancement

Open Issues/Questions

Back to the top