Re: [wsdm] Discovery Scenarios [fred]

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

John DeCarlo <jdecarlo@mitre.org> wrote on 05/21/2004 09:24:58 AM:

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

+1  However, I'm not sure that WSDM needs to define this
interface.  WS-ServiceGroup should be investigated to see if it fits the
bill.

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

+1

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

ServiceGroup is just an interface why would we not adopt it now?


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

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