Hi John, thanks for your responses.
I'm not sure I agree that #1 is completely
out of scope for WSDM. For MOWS, I see it as completely in scope.
For MUWS, it may also be in scope for resources where a management
system can be responsible for install/deploy of the resource (such as software).
I don't know why we tackle metrics, configuration, relationships,
and so on without tacking install / deploy, at least at some point in the
future. It is a perfectly valid management capability. Do we
consider that covered by another group?
For #2, I understand that we can't dictate
how it happens, but we can put requirements on the result so that we can
manage the environment. For example, if we assume the manager has
a WSDL (which is the premise for the scenario) then we have a requirement
on the installation of the resource or on the environment at large that
the management interfaces be published in a registry somewhere that the
management system knows to look at.
Let me get concrete again, to try to
explain myself. For network resources, management tools tend to find
the resources (via broadcast, looking at router tables, etc). The
tool then finds the management interface (try the SNMP port, etc). For
system resources, the tools look for the resources themselves with scanners
(file signatures or registry entries for applications, OS device registry
for hardware, etc) and then looks for the appropriate management interface.
Usually, the management interface is provided by some hosting environment
for the resource (such as the OS or the app server). I can think
of very few scenarios where the management tool discovers or enumerates
the management interfaces first, and then tries to find the resources behind
the interfaces. In those few cases I can think of, the tools would
tend to go to the management interface of the OS or other hosting environment
to enumerate the resources, not to the resource management interface itself.
For example, the manager would ask the OS or SAN about the disk drives;
it wouldn't look for the disk drive's management interface first. If
we're going to change that paradigm, I'd like to understand the underlying
scenario in more detail. I think it puts a new requirement on hosting environments
that we may not be able to dictate.
Please note that I am not trying to
say that your (collective) underlying assumption is false. Finding
WSDLs in a well-known registry is a pretty obvious pattern for discovery.
I'm just trying to bring it down to earth for real resources and
how they will really get discovered.
Regards,
David E Cox
John DeCarlo <>
05/21/2004 11:01 AM
To
"Wsdm (E-mail)"
<>
cc
David E Cox/Raleigh/IBM@IBMUS
Subject
Re: [wsdm] Discovery Scenarios
[fred]
David,
See inline.
David E Cox wrote:
>
> Hi Fred,
>
> Thanks for writing this up. To me, the confusion starts
before your
> scenario begins.
Ah ha!
> How did the managed resource get installed into the system?
There are at least two items to consider here. 1) Installing the
resource and making it available to consumers. 2) Making the resource
manageable.
1) is out of scope for WSDM
2) is not well defined how it happens. (Probably because how you
make a
disk drive manageable will differ from how you make a Web Service
manageable, and even the Web Service may provide its own manageability
or rely on the Execution Environment or something else.) But essentially
it involves some method where the Manageability Provider is linked
enough to the resource to start providing manageability for it.
In the last call, we talked about having an Event defined that says a
resource has now been made manageable.
Otherwise, we really don't know what resources have been made manageable
without talking to the manageability provider.
Not that there aren't lots of good ideas on changing that, like perhaps
registering all EPRs somehow when the resource is made manageable.
Maybe the registries would just subscribe to the "JustNowMadeManageable"
Event, as any other consumer would.
> Who installed it?
Again, make the resource available for consumers is out of scope for
WSDM. Only making it manageable is in scope.
The answer is similar to the last question.
> Who published its management interface, and to where?
This depends on who provides manageability for the resource. The
management interface is defined in WSDL and may already have been
published in a registry somewhere, or the URL to the WSDL has been
provided somehow.
So the manageability provider (whoever that happens to be, and there may
be more than one) publishes the manageability interface in WSDL.
> Who made the resource known to the resource manager (in some
cases they
> will be installed concurrently, in some cases they will be separate).
This is the basic question.
Maybe no one made the resource known the the resource manager. So
it is
required to continually do some sort of discovery.
Maybe if WSDM or another group defines a "just made manageable"
event,
the resource manager could just subscribe to it.
> 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.
Let me word it another way. Management tools are either pre-loaded
with
information about resources to manage, or they have to do some sort of
discovery.
One idea in the MUWS world is to simply discover the Manageability
Endpoint WSDL. Then query the Manageability Provider at that endpoint
to find out what manageable resources there are there.
And where there are multiple manageability interfaces for one resource,
the management tool may or may not care, and may or may not want to use
Identity or Correlatable Names to determine if two resources are the same.
Does this answer your questions?
--
John DeCarlo, The MITRE Corporation, My Views Are My Own
email:
voice: 703-883-7116
fax: 703-883-3383
DISA cube: 703-882-0593
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.
