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
