Re: [wsdm] Discovery Scenarios [fred]

[John DeCarlo <jdecarlo@mitre.org>]

+1 from me, too.

If WSDM specifies a "TellMeWhatResourcesYouProvideManageabilityFor" type 
of operation, it would have to be optional (except in some profiles, 
should we get there).

This gives the Manageability Consumer community (especially in Federated 
or other loosely coupled interactions) a simple method for discovering 
resources NOW.  Of course better ways will no doubt be adopted over time 
<g>.

The description of why it is optional would be - if in your situation 
there are adequate Manageable Resource discovery mechanisms, you don't 
need to implement this operation.

And maybe eventually the description might well say it is deprecated 
because of the full adoption of Service Groups or other registry 
mechanisms (or relying on a notification infrastructure) for Manageable 
Resources.

Fred Carter wrote:
> <ScenarioPart>
> 
> My scenario, unless I mentioned another to which I wasn't paying 
> attention during the call, is as follows.
> 
>    Manager is started.  It is given either a WSDL file (which 
> corresponds to an endpoint for a manageability endpoint) or a URL (which 
> corresponds to said endpoint -- assumed to have some known capabilities).
> 
>    Manager wants to use said endpoint to do its manager application 
> thing.  To do so, it needs to find the resources available.
> 
>    Now what?
> 
> that's it.  I think this is the fundamental part of the so-called 
> "WSDL->EPR" requirements.
> 
> </ScenarioPart>
> 
> <FredsCommentary>
> 
> Responses to anticipated issues:
> 
>    Well, why not start with EPR's.
>        1) Cause we didn't.
>        2) Cause many web service applications follow the above pattern
> 
>    Use [insert name] registry here.
>        1) Small site, I don't have one.
>        2) My first implementation will be the simplest one.  Later, I 
> will add complexity with more moving parts, etc.
> 
>    Why should we do this?  Why isn't this left unspecified?
>        1) Our intent, insofar as I can tell, is to provide a 
> specification which is usable as is.  We have made a number of decisions 
> and taken directions based on the capability of extant tools and 
> software stacks, to ensure that the specification is adoptable.  If the 
> we rely on a implementation specific stuff to start up, especially for 
> the simplest case (a small number of resources, one container, no uddi, 
> etc.), I think we have an adoption problem.
>        2) We can certainly argue that there are should be some other 
> [heretofore nonexistent] specification in which the belongs.  And that 
> may even be true.  But we want folks to adopt & implement now, so basing 
> our work on more things that might come real soon now seems fraught with 
> peril.
>        3) One /could/ make whatever a solution might be (say, the 
> ListEPRs operation, for purposes of argument) optional so that "tiny 
> manageability provider endpoints" (or dynamic ones) could function 
> without fear, but I think we should provide the definition nonetheless.
> 
> 
> At a higher level, I think that any system wherein access to said 
> resources is provided by other access providers (e.g. WSRF-based things 
> :-) ) must have a means by which one can determine which resources are 
> accessed via what access provider (modulo permissions, etc.).  This is a 
> bootstrap issue.  It may be that there are options (e.g. use some 
> registry), but then one must be able to find said registry. (Perhaps we 
> define some appropriate fault or property that directs the caller to 
> said registry when necessary.)  Consequently, I tend to think that this 
> is a general problem for WSRF.
> 
> [It may be appropriate higher up in the chain (it may be some of the 
> defined mechanism behind ...Addressing), but since WS-Addressing is 
> agnostic on what the properties are used for, it may not be appropriate 
> there.]
> 
> </FredsCommentary>
> 
> 

-- 

John DeCarlo, The MITRE Corporation, My Views Are My Own
email:      jdecarlo@mitre.org
voice:      703-883-7116
fax:        703-883-3383
DISA cube:  703-882-0593