Jump to: navigation, search

Initial design of WS-RC

  • Use cases input to design:
    • Service registry
      • XPath 2.0 query support instead of just XPath 1.0
      • ability to address entries and resource cache elements as separate resources for performance reasons on updates.
  • Production requirements
    • a database backed catalog for performance
    • xquery support in database for efficiency
  • WS-RP limitations in Muse
    • Only xpath 1.0 queries supports
    • Entire DOM is loaded into memory per query, won't work for large catalogs, need a stax parser or db/xquery support.
    • Only QName dialect supported on set operations therefore can't target entries by ID.
  • Code re-use from earlier prototype
    • None of the code can be re-used. It was written with little structure and used an internal XQuery engine with proprietary APIs. Converting it into a Muse capability will take much more effort than writing a Muse WS-RC capability from scratch.
  • Plan for Sept 14
    • Provide a simple, file based WS-RC muse capability that uses Muse's default WS-RP implementation for query support.
      • XPath 1.0 WS-RP queries only
      • Entry insertion possible but updates or deletion of particular entries not possible
      • Client side api:
        • Allows Catalog creation
        • Xpath 1.0 queries
        • Convenience query methods (eg: get entry by ID) that return an object model to work with. These queries will be translated to WS-RP XPath requests by the simple client implementation underneath the covers.
    • Design it such that database functionality can be plugged in via a deployment descriptor in a subsequent release
    • Design it so the Muse service group capability can be plugged in or the base WS-RC capability can be extended to provide separate resource views for entries and resource cache elements in a subsequent release
    • The following features won't be supported:
      • 3.2.2 Advertising Using WS-Policy
      • 3.6 Meta references
  • Issues to discuss
    • Catalog intitialization: do we always want a default empty catalog or a "factory" service that accepts proprietary requests to create a new catalog