I think I understand the issue, Andy. Two observations: 1 - Looking at the current round of Core-based specs coming along: CM, RM and QM, I see that they leave the service-nesting structure of the service provider docs up to the implementation.
2 - I've been assuming that products have such different service nesting, project/folder requirements that this was an areas where we cannot set a standard structure or depth. I wonder... Is the issue of "how does a client programmatically determine which creation factory to use to create or query for a given type" still open? We have given creation factories, query capabilities and dialogs "type" and "usage" properties, but don't clients still have to navigate a hierarchy of possibly nested services to get to those? How does a client know which nested service to use? Thanks, - Dave On Fri, Jul 9, 2010 at 8:30 AM, Andrew J Berner <[email protected]> wrote: > The OSLC specs on purpose do not specify the "method of discover" for a > provider, leaving it up to the provider to deal with differences in their > basic data structures. Also, I believe we have a general principle (not > sure if this is written down though!) that URL's for service calls should > be discovered rather than either cached or constructed from "smart keys". > > For some of the specs, that's working just fine: The CM spec > implementations do discovery differently, because, for example, ClearQuest > "user databases" are in a different structure from RTC "project areas". > But for each one, there's a fixed path you take. > > In some discussions around RM tools (my exposure to these discussions has > been around implmenetation rather than in the spec workgroup so far), a > complication has arisen. Some tools have hierarchical "folder like" > structures. And the folders in that hierarchy change dynamically of > course. When you have a Factory URL, since the created requirement must be > put into a folder, the question comes up of what the "discovery" structure > should be. One possibility, that I think is a problem but is very > tempting, is to have a hierarchy of discovery documents: You start with a > top level, which gives the URL of the discovery document (note I'm not > saying "service document" vs. "catalog"---let's lump them all together as > "discovery document"), which gives the URLs for the multiple "project > discovery documents" based on whatever projects are currently available > (similar to the CM ones); a project discover document gives the URL's of > the multiple "folder discovery documents"---and a folder discovery document > has several things, perhaps: URL's for the factories to create resources > in that folder, and URL's for subfolder discovery documents. You then > recursively go down the folder hierarchy discovering the urls of discovery > documents till you get to the one you want, and then get the URL of the > factory. > > I believe this is taking "discovery" too far. In practice, if this is > what's being done, we'll find that the "opaque urls" probably in fact are > constructed in some way from the "url for the folder" (even if that folder > isn't yet exposed as a resource!!!) and that URL of the folder is > permanent, just like it was a resource. > > I think there should be a spec around this, and that "discovery" should > have a constant length hierarchy for any provider, and not require > recursive search just to get the call you want to make. Then we won't > tempt consumers to start caching the URL's instead of that recursive > search. > > Comments? > > Andy Berner > Lead Architect, ISV Technical Enablement and Strategy > IBM Rational Business Development > 972 561-6599 > [email protected] > > Ready for IBM Rational software partner program - > http://www.ibm.com/isv/rational/readyfor.html > > > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net >
