This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/wiki/do/viewPage/projects.scrm-wg/wiki/Landscape at Thu, 03 Nov 2022 00:16:48 GMT SourceForge : View Wiki Page: Landscape

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin
Search Wiki Pages Project: scrm-wg     Wiki > Landscape > View Wiki Page
wiki1489: Landscape

SCRM Standards Landscape

This is a general strawman proposal for a taxonomy and organization of the specifications that we have listed in the Specification List for Landscape Document, (Excel spreadsheet). https://forge.gridforum.org/projects/scrm/document/landscape-spec-list/en/3

It is just a starting point and is by no means complete. An examination of the current list lead to the conclusion that we must add a number of additional documents to our survey including some proprietary documents that while public are not yet submitted to any standards organization. If we apply a taxonomy like this (or something similar in nature) and can determine our evaluation needs relative to each category in the breakdown I believe that we can form small Òanalysis groupsÓ that can operate in each area to describe the landscape in that area of standardization. Terms

Resource a logical or physical component in some resource domain, for example, a printer, a magnetic storage disk, an application server, a CRM application or a car engine. Resource Interface the native instrumentation interface to the hardware, software or firmware of the resource that enables the creation of a Manageability Interface.

Resource domain an area of knowledge relative to a specific type of resource. Such as Storage Management, Server Management Application Management, etc.

FCAPS (management domain) an acronym for a list of management domains: Fault-management, Configuration, Accounting, Performance and Security. An area of knowledge relative to providing control over, and information about, the behavior, health, lifecycle, etc. of manageable resources.

Manageable resource a resource capable of supporting one or more standard manageability capabilities. (Managed Entities)

Manageability Capability a group of properties, operations, events and metadata, associated with identifiable semantics and information and exhibiting specific behaviors associated with one or more management domains (i.e. FCAPS). Example include: Configurations, Metrics, Control Operations, Status, State

Manageability interface the composition of one or more interfaces to manageability capabilities.

Functional Interface the composition of one or more interfaces to the functional (non- administrative) capabilities. These models may be abstract, representation and protocol agnostic and may specify a particular rendering for the model semantics and syntax, such as UML. (See RFC 3444) Data Models define implementation and protocol specific details for Information Models. Manageability Provider - an instrumentation of a Manageable resource that provides management capability through the Manageability interface.

Management Application - A Manageability Client of one or more Manageable resources

Manageability Client - A process that issues requests for service. Formulating and issuing requests may involve multiple client processes distributed over one or more computer systems. Management Data Repository - a persistence service used to store management data, perhaps with various means of access

Management Infrastructure Services - services use to support the management of resources. Examples include Query, Find, Auto-Discovery, Resource Registry

Resource Information Models

Description: Specifications or standards that provide all or part of an "information model" for system and / or network resources and their relationship to other resources. These models may be abstract, representation and protocol agnostic and may specify a particular rendering for the model semantics and syntax, such as UML. (See RFC 3444) Data Models define implementation and protocol specific details for Information Models.

Examples: CIM, SID.

Actions: We need to determine what each of these models covers and at what depth. How do these model overlap in covering the systems and network instance space ? (Venn Diagram). Are representation (or abstraction) easily translated from one model to another.

ManageableResource2.jpg

Foundational / Protocol Specifications

Description: These are basic protocol or framework specifications that provide the underlying mechanism for simple interoperability. Generally they are not systems or network management specific.

Examples: SOAP, WSDL, WS-Addressing, WS-RF/Notification, WS-Transfer/Eventing/Enumeration

Actions: Many of the basic infrastructure specifications for web services (SOAP, WSDL, WS-Addressing) are common to several competing approaches to management and therefore provide a common foundation. Some higher level protocol standards or proposed specifications enhance these lower level specifications to provide a stateful / contextual interaction model, state change messaging, life-cycle management etc. Ii would be valuable to understand the overlap and differences between these different approaches.

ManagementTaxonomy2.jpg

Low-Level General Frameworks:

Description: These specifications provide very general framework capabilities that can be applied to management but are not strictly management specific (they might be used in a general distributed computing context). They define broad mechanisms and are frequently open ended and support multiple sub-disciplines or approaches. They are generally not management discipline specific. In general they provide a protocol framework for interoperability but require additional discipline specific definition to be useful in a specific management context. In some cases other specifications further define these discipline oriented specifics in the context of these frameworks.

Examples: WS-Security, WS-Policy, OGSA-Basic Profile.

Actions: There are quite a few specifications of this type defined in several standards bodies that clearly overlap. It will be important to determine the maturity, completeness, and adoption status of these specifications. As these are more foundational and oriented toward protocol interoperability the differences between them and the ability to map one-to-another may be important.

Broad Management Frameworks:

Description: These specifications or standards are specifically intended for system and/or network management but are very broad definitions that are not limited to a single particular management discipline. They generally provide their own taxonomy or family in which lower level specifications define more management discipline specific operational and management models. They may also constrain implementation to specific resource information models, foundational protocols, or Low-level general frameworks.

Examples: OGSA, WS-DM, WS-Management

Actions: We need to understand the scope and intent of these broad systems and network management frameworks. We need explicitly recognize their dependencies on other standards and specifications and also how their related Òsub-specificationsÓ fit into their overall architecture. We need to understand how these sub-component may related to similar sub-components that are either stand-alone standards or parts of other Broad Management Frameworks.

Discipline Specific Management:

Description: These specifications are generally particular to management of a specific type of resources (such as network components, telecom resources, grid jobs, etc.) They provide a very domain specific management and operational model. They may be part of one of the Broad Management Specifications (defined above) or be a stand-alone specificiation.

Examples: SNMP, JSDL, CDDLM.

Actions: As these specifications generally address a specific management discipline and limited in scope it is generally fairly easily to identify which overlap. We should examine the scope of these standards in detail to determine the degree to which they duplicate each others functionality and give specific attention to where each has unique function or attributes to offer.

Appendix: Acronyms

CDDLM
- Configuration Description, Deployment, and Lifecycle Management
CIM
- Common Information Model
CRM
- Customer Relationship Management
FCAPS
- Fault-management, Configuration, Accounting, Performance and Security
FW
FirmWare
HW
HardWare
JSDL
- Job Submission Description Language
OGSA
- Open Grid Services Architecture
RFC
- Request For Comments
SCRM
- SDO Collaboration on networked Resource Management
SDO
- Standards Development Organization
SID
- Shared Information and Data model
SNMP
- Simple Network Management Protocol
SOAP
- Simple Object Access Protocol
UML
- Unified Modeling Language
WS
- Web Services
WSDL
- Web Services Definition Language
WSDM
- Web Services Distributed Management
 




The Open Grid Forum Contact Webmaster | Report a problem | GridForge Help
This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/wiki/do/viewPage/projects.scrm-wg/wiki/Landscape at Thu, 03 Nov 2022 00:16:48 GMT