Consider an optional ListResources
operation on a resource manager, which returns all known resources it is
managing. If this function exists, it does not necessarily imply
anything about how the data got there. And consumers of the management service
don't necessarily care how the data got there.
I think different ways of taking resources
under management fall into 2 categories. Either the manager discovers the
resources on its own, or it's told to manage the resources. It could be told by
a human, by the resources self-registering, or anything else. Both techniques
are commonly used.
If we have a "ListResources"
operation, should the spec discuss how the manager knows when to update
the list? We might want to avoid doing that. It
may be a slippery slope which leads to strapping a rocket booster to
a Toyota.
IMO this is also the problem with covering install / deploy. Metrics have
a base set of primitive stuff, some kind of greatest common denominator across
all kinds of different "stuff": counts, up/down, etc. Install / deploy varies so
widely that greatest common denominator isn't big enough to be
useful.
From: David E Cox [mailto:]
Sent: Friday, May 21, 2004 11:49 AM
To: John
DeCarlo
Cc: Wsdm (E-mail)
Subject: Re: [wsdm] Discovery
Scenarios [fred]
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.
