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]


David,

see inline

David E Cox wrote:
> 
> 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?

This is a good point.  Clearly there is not much we can say about 
provisioning with MUWS, unless we define events associated with key 
lifecycle state changes (and therefore the lifecycle states).

But WSDM could well attack the problem for MOWS.

The reason I said it was out of scope is that *all* management 
applications are out of scope for WSDM.  But they are all good use cases 
for what is needed in WSDM to support them.


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

You are correct.  This is a discussion we need to have once we have 
settled on what options the TC is going to tackle.  And this discussion 
is likely to be influenced by what is going on in WSRF, especially with 
respect to Service Groups, but also other things as discussed already.

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

First, let me say that it is important to have some general agreement on 
the context.  So far, the context has been Web Services, such as defined 
by W3C and so on.  It is my view that addressing the context of 
Management Today may well be useful, though non-normative.  People who 
haven't been intimately involved with the WSDM TC need some context they 
understand to go on.

Second, the Discovery list of items that William (I think) is 
maintaining does indeed call for addressing the issue of discovering the 
manageability interface given the managed resource.  Not sure what we 
will or can do in this case for MUWS, but MOWS could certainly address 
it somehow.  I think the discussion at the last call touched on this a 
bit if I understood some of the WSRF discussions.


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

Yes, setting the context is helpful.  But I think Mike mentioned that 
different types of resources are discovered in different ways.  So we 
need to be careful.

For instance, how do you discover all your networked printers so you can 
properly manage them (say, monitoring if they are up, are out of paper, 
out of toner, etc.)?  I don't know of a universal way.  Simply 
discovering unmanageable network nodes is not enough.  In my experience, 
typically someone manually sets up a management interface to monitor the 
networked printers.  Then any consumer of management has to discover the 
management interface(s) that monitor networked printers and figure out 
which printers are being monitored.

So there are lots of cases to consider, and we want to address the 
highest priority ones first.

-- 

John DeCarlo, The MITRE Corporation, My Views Are My Own
email:      jdecarlo@mitre.org
voice:      703-883-7116
fax:        703-883-3383
DISA cube:  703-882-0593



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