John DeCarlo <> 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:
phone: 845.433.9401 (t/l 293-9401)
