[UArch] Scope, with more words

[John DeCarlo <jdecarlo@mitre.org>]

Hello,

Here are some additional words we need to agree on so we can capture the 
scope of this document.  Please consider whether this fully agrees with 
the Concepts and other sections of the document.  Also consider overlap 
and whether that it useful or should be removed.
All comments welcome.

------
2.1.  MUWS Architecture. 

The MUWS Architecture being addressed in this document consists of the 
pieces needed for management using Web Services of generic Information 
Technology resources.  This requires that manageability of the 
manageable resource be presented via Web Services, whether or not the 
resource is a Web Service itself.  The Introduction/Context section 
(Section 1) placed this work in the larger context of Web Services 
Architecture and following sections will provide more detail about the 
components of the MUWS Architecture.

2.2.  MUWS Architecture Scope. 

The MUWS Architecture being defined consists of the Web Services 
endpoint(s), service(s), and interface(s) that expose the manageability 
capabilities for the manageable resource.  The manageability endpoint 
provides access to the manageable resource and also provides access to 
one or more manageability capabilities for the manageable resource.    
The manageability service, like any Web Service, is an aggregation of 
one or more endpoints and provides one or more interfaces.   The 
manageability interface, like any Web Services interface, defines a set 
of named messages that could be exchanged and their format.

The MUWS Concept UML diagram and accompanying text in section 2.3 below 
will provide more detail on the relationships involved between these 
components and the underlying components such as a manageable resource..

The following items are explicitly out of scope for the MUWS 
Architecture, as described:
      o) The Manager (see Section 1 for definition). 

            The Manager must be able to make use of the manageability 
interface(s) provided by manageable resources.  This is a clear 
constraint on what is referred to as a Manager in the MUWS 
Architecture.  Conventional management applications that do not support 
MUWS will not be addressed at all in the MUWS Architecture.  The Manager 
in this document must be able to send messages to, receive responses 
from, and receive notifications from the manageability interface.  The 
Manager must be able to make use of the information provided from a 
manageable resource.  NOTE:  It is important to note that not every 
Manager will have the same capabilities.  For example, some may be able 
to process WSDL dynamically, others may not.  Some may only be able to 
do monitoring, others may be able to do monitoring and configuring.  
This MUWS Architecture will refer to the Manager in a generic sense, not 
requiring any particular implementation to provide any particular 
capability.

      o) The Manageable Resource.  No constraints or requirements will 
be placed on the actual resource itself.

           In particular, the constraints and requirements will be put 
on the manageability endpoint and manageability interface to properly 
provide what manageability capabilities are available for that 
manageable resource via Web Services.  It is entirely possible for there 
to be manageability capabilities that are not directly supplied by the 
manageable resource, but are inferred or calculated by another entity 
and offered by the manageability endpoint.

      o) Required services.  Examples include, but are not limited to, a 
Registry, a Policy Repository, or a Security service.  They will be 
mentioned in the document where appropriate, and MUWS has requirements 
on these services, but they will not be defined here.  Also, much of 
this work will be addressed via the MUWS Platform requirements.


-- 

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