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 198553"

(New page: Work in Progress)
 
(Design Considerations)
 
(13 intermediate revisions by 4 users not shown)
Line 1: Line 1:
Work in Progress
+
This page is for discussing the design of [https://bugs.eclipse.org/bugs/show_bug.cgi?id=198553 bugzilla 198553].
 +
 
 +
== Design Considerations ==
 +
 
 +
* We would like to have clean layers in the design.  The web services layer needs to be distinct from the actual implementation of the catalog itself.
 +
** We would like to be able to "bind" to different underlying implementations.  For COSMOS in open source, can we use a simple flat file or do we need a relational DB?
 +
*** Current thinking here is to have an interface that defines the API's for the data store.  This way we can have the user write code to the interface regardless of the underlying implementation being a flat file or a DB or some other persistent store.
 +
 
 +
* In the case of COSMOS and CMDBf, we would NOT choose to expose the MDR via WS-RC. 
 +
 
 +
* What is the mapping of SML onto the schema of the RC?
 +
** If this is a simple mapping, e.g. <EntryRef> = <SMLRef>, <ResourceRef> = <SMLRef w/EPR>, or something like that, can we simply use the existing SML repository that we have now and expose WS APIs that exchange RC entries via an XSLT?  [[SML to WSRC Mapping]]
 +
 
 +
* The WS-RC spec talks about the use of WS-R
 +
 
 +
* Do we need a flat file representation, relational, or both?
 +
** We think both
 +
*** The comments above I think address this issue.  We are planning to use an interface to implement a persistence layer.
 +
 
 +
* What additional dependencies are we bringing in?
 +
** 3rd party code, e.g. xerces, xpath..
 +
*** Currently looking at Qexo as the XQuery engine for this effort.
 +
**** Qexo is available as part of the KAWA framework.  It is freely available under the X11/MIT License.  We will need to investigate this license to see if it will work for this effort. 
 +
**** The web site for Qexo is http://www.gnu.org/software/qexo/
 +
**** I have given this information to Mark Weitzel for submission and approval.
 +
** JVM et..
 +
 
 +
 
 +
* What parts of the spec will we not implement?
 +
** 3.6.4:  Don't need to support meta-epr.
 +
 
 +
* Would prefer an API that does not require intimate knowlege of the resources in the catalog.  XPath is not a good choice for this.
 +
 
 +
== Applications of WS-RC in COSMOS ==
 +
* Management Domain
 +
* Data Broker
 +
** The remote APIs will be WS-RC APIs
 +
 
 +
== Use Cases ==
 +
* Mohammad to enumerate
 +
* [[Initial design of WS-RC]]
 +
 
 +
== Action Items / ToDos ==
 +
* David: First cut at SML - RC mapping
 +
* Jimmy/Mark: Map RC onto the Domain and Data Broker use cases
 +
*
 +
 
 +
 
 +
== Time Line ==
 +
*
 +
 
 +
 
 +
----
 +
[[Category:COSMOS_Bugzilla_Designs]]

Latest revision as of 16:41, 3 December 2007

This page is for discussing the design of bugzilla 198553.

Design Considerations

  • We would like to have clean layers in the design. The web services layer needs to be distinct from the actual implementation of the catalog itself.
    • We would like to be able to "bind" to different underlying implementations. For COSMOS in open source, can we use a simple flat file or do we need a relational DB?
      • Current thinking here is to have an interface that defines the API's for the data store. This way we can have the user write code to the interface regardless of the underlying implementation being a flat file or a DB or some other persistent store.
  • In the case of COSMOS and CMDBf, we would NOT choose to expose the MDR via WS-RC.
  • What is the mapping of SML onto the schema of the RC?
    • If this is a simple mapping, e.g. <EntryRef> = <SMLRef>, <ResourceRef> = <SMLRef w/EPR>, or something like that, can we simply use the existing SML repository that we have now and expose WS APIs that exchange RC entries via an XSLT? SML to WSRC Mapping
  • The WS-RC spec talks about the use of WS-R
  • Do we need a flat file representation, relational, or both?
    • We think both
      • The comments above I think address this issue. We are planning to use an interface to implement a persistence layer.
  • What additional dependencies are we bringing in?
    • 3rd party code, e.g. xerces, xpath..
      • Currently looking at Qexo as the XQuery engine for this effort.
        • Qexo is available as part of the KAWA framework. It is freely available under the X11/MIT License. We will need to investigate this license to see if it will work for this effort.
        • The web site for Qexo is http://www.gnu.org/software/qexo/
        • I have given this information to Mark Weitzel for submission and approval.
    • JVM et..


  • What parts of the spec will we not implement?
    • 3.6.4: Don't need to support meta-epr.
  • Would prefer an API that does not require intimate knowlege of the resources in the catalog. XPath is not a good choice for this.

Applications of WS-RC in COSMOS

  • Management Domain
  • Data Broker
    • The remote APIs will be WS-RC APIs

Use Cases

Action Items / ToDos

  • David: First cut at SML - RC mapping
  • Jimmy/Mark: Map RC onto the Domain and Data Broker use cases


Time Line



Back to the top