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
