[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsdm] Discovery Scenarios [fred]
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 mabe 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:email@example.com]
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.
- David E Cox
- John DeCarlo <firstname.lastname@example.org>
- 05/21/2004 11:01 AM
- "Wsdm (E-mail)" <email@example.com>
- David E Cox/Raleigh/IBM@IBMUS
- Re: [wsdm] Discovery Scenarios [fred]
- 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
- 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
- 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: firstname.lastname@example.org
- 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.