Discovery Scenarios [fred]

[Fred Carter <fred.carter@amberpoint.com>]

<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>


-- 
Fred Carter / AmberPoint, Inc.

mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301