[oslc-core] Discovery document hierarchy should be constant length per provider?

[Dave]

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 <ajberner at us.ibm.com> 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
> ajberner at us.ibm.com
>
> Ready for IBM Rational software partner program -
> http://www.ibm.com/isv/rational/readyfor.html
>
>
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>