Initial design of WS-RC
From Eclipsepedia
- 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
