[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [UArch] Scope, with more words
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]