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