Re: [wsdm] Discovery Scenarios [fred]

[Tom Maguire <tmaguire@us.ibm.com>]

I think it is perfectly reasonable to be able to locate WS-Resource
qualified endpoint references.
I also think it is perfectly reasonable to standardize an interface for
querying/retrieving a collection
or related WS-Resources.  (BTW, there is one of these already
WS-ServiceGroup ;-) )

I think it is unreasonable (perhaps even outright wrong) to require that
the management endpoint
interface and the interface for querying/retrieving a collection MUST be
implemented by the same
endpoint.



Fred Carter <fred.carter@amberpoint.com> wrote on 05/20/2004 06:38:22 PM:

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

More precisely you mean that a manager is "given" a service element and
port,
somehow.

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

Today

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

It is fine if you "want" to implement an interface that provides query and
retrieval
on the same endpoint as the management interfaces.  That is clearly an
implementation
choice; requiring ALL implementations to make that same choice is overly
constraining.

>
>     Why should we do this?  Why isn't this left unspecified?

Not asking for the interfaces to be left unspecified but rather requesting
that we give the implementers latitude in where and how they implement that
interface.

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

But you are relying on implementation stuff.  You are suggesting (I think)
that EVERY implementation MUST provide this interface.  If we create
hardened
requirements for collocation of interfaces in an implementation we
introduce a
fragility in the standard that will eventually cause us grief/pain perhaps
even
thwarting adoption.

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

Lots of questions here.  What do you think the product adoption cycle of a
standard is?  As always wrt dependencies on other work; however,
reinventing,
over-sepcifying, or ignoring other work are equally 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.

+1 to this.  Normatively describe the interface and make it optional.

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

Some aspect of this may be WSRF.  However, I think you will find that WSRF
TC
will not standardize service implementations.  They MAY standardize a fault
mechanism (which is an interesting idea).

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

<snip/>

T o m   M a g u i r e

STSM, On Demand Architecture
Poughkeepsie, NY  12601

internet:                 tmaguire@us.ibm.com
phone:                     845.433.9401 (t/l 293-9401)