Hi Fred,
Thanks for writing this up. To
me, the confusion starts before your scenario begins.
How did the managed resource
get installed into the system? Who installed it? Who published
its management interface, and to where? Who made the resource known
to the resource manager (in some cases they will be installed concurrently,
in some cases they will be separate).
I think that part of the scenario
is what drives the WSDL vs EPR starting point. I at least am confused
about how/why a manager would be given a WSDL file. That's not typically
the way a management tool would discover a manageable resource. It
usually finds the resource first (by looking in directories and registries,
or by various scanning techniques), then finds the manageability interface.
I'm not saying that is right or wrong in the new Web Services model,
but I would like to understand that part of the scenario.
Regards,
David E Cox
Fred Carter <>
05/20/2004 06:38 PM
Please respond to
fred.carter
To
"Wsdm (E-mail)"
<>
cc
Subject
[wsdm] Discovery Scenarios
[fred]
<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:
tel:+1.510.433.6525 fax:+1.510.663.6301
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgroup.php.
