OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [wsdm] Discovery Scenarios [fred]

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.

David E Cox

Fred Carter <fred.carter@amberpoint.com>

05/20/2004 06:38 PM
Please respond to

"Wsdm (E-mail)" <wsdm@lists.oasis-open.org>
[wsdm] Discovery Scenarios [fred]


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.



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


Fred Carter / AmberPoint, Inc.

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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]