Jump to content

Web-Based Enterprise Management: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Line 40: Line 40:
# the client will use the HTTP (or [[https|HTTPS]]) protocol to pass the request, encoding in [[CIM-XML]], to the WBEM server
# the client will use the HTTP (or [[https|HTTPS]]) protocol to pass the request, encoding in [[CIM-XML]], to the WBEM server
# the WBEM server will decode the incoming request, perform the necessary authentication and authorization checks and then consult the previously created model of the managed device to see how to handle the request. This model makes the architecture so powerful: it represents the pivot point of the transaction, with the client simply interacting with the model and the model interacting with the real hardware or software. The model uses the Common Information Model standard; the [[Distributed Management Task Force|DMTF]] has published many models for commonly managed devices and services: [[multilayer switch|IP routers]], [[file server|storage servers]], [[desktop computer]]s, etc.
# the WBEM server will decode the incoming request, perform the necessary authentication and authorization checks and then consult the previously created model of the managed device to see how to handle the request. This model makes the architecture so powerful: it represents the pivot point of the transaction, with the client simply interacting with the model and the model interacting with the real hardware or software. The model uses the Common Information Model standard; the [[Distributed Management Task Force|DMTF]] has published many models for commonly managed devices and services: [[multilayer switch|IP routers]], [[file server|storage servers]], [[desktop computer]]s, etc.
# for most operations, the WBEM server determines from the model that it needs to communicate with the actual hardware or software. So-called "providers" handle the interaction: small pieces of code interface between the WBEM server (using a standardised interface known as [[Common Manageability Programming Interface|CMPI]]) and the real hardware or software. Because the interface is well-defined and the number of types of call is small, it is normally easy to write providers. In particular, the writer of the provider knows nothing of the GUI, BUI, or CLI used by the operator.
# for most operations, the WBEM server determines from the model that it needs to communicate with the actual hardware or software. So-called "providers" handle the interaction: small pieces of code interface between the WBEM server (using a standardised interface known as [[Common Manageability Programming Interface|CMPI]])<ref>[http://www-01.ibm.com/support/knowledgecenter/linuxonibm/liaav/cmpi-overview.pdf The Common Manageability Programming Interface]</ref> and the real hardware or software. Because the interface is well-defined and the number of types of call is small, it is normally easy to write providers. In particular, the writer of the provider knows nothing of the GUI, BUI, or CLI used by the operator.


==WBEM specifications==
==WBEM specifications==

Revision as of 18:16, 17 March 2015

Web-Based Enterprise Management
AbbreviationWBEM
StatusPublished
Year started2004
OrganizationDistributed Management Task Force
Base standardsCIM and WS-Management
DomainSystems management
Websitewww.dmtf.org/standards/wbem

Web-Based Enterprise Management (WBEM) is a set of systems-management technologies developed[by whom?] to unify the management of distributed computing environments. WBEM is based on Internet standards and Distributed Management Task Force (DMTF) open standards:

Although the name refers to WBEM as being "web-based", it is not necessarily tied in any way to a particular user interface (see below). Other systems-management approaches include remote shells, proprietary solutions and network-management architectures like SNMP.

Features

WBEM allows the management of any element in a standard and inter-operable manner.

WBEM provides the technology underlying different management initiatives in information technology:

Architecture

To understand the WBEM architecture, consider the components which lie between the operator trying to manage a device (configure it, turn it off and on, collect alarms, etc.) and the actual hardware and software of the device:

  1. the operator will invoke some form of graphical user interface (GUI), Browser User Interface (BUI), or command-line interface (CLI). The WBEM standard has nothing to say about this interface (although the definition of a CLI for specific applications has started): WBEM operates independently of the human interface, since human interfaces can change without the rest of the system needing to note such changes.
  2. the GUI, BUI or CLI will interface with a WBEM client through a small set of application programming interfaces (API). This client will find the WBEM server for the managed device (typically on the device itself) and construct an XML message containing the request.
  3. the client will use the HTTP (or HTTPS) protocol to pass the request, encoding in CIM-XML, to the WBEM server
  4. the WBEM server will decode the incoming request, perform the necessary authentication and authorization checks and then consult the previously created model of the managed device to see how to handle the request. This model makes the architecture so powerful: it represents the pivot point of the transaction, with the client simply interacting with the model and the model interacting with the real hardware or software. The model uses the Common Information Model standard; the DMTF has published many models for commonly managed devices and services: IP routers, storage servers, desktop computers, etc.
  5. for most operations, the WBEM server determines from the model that it needs to communicate with the actual hardware or software. So-called "providers" handle the interaction: small pieces of code interface between the WBEM server (using a standardised interface known as CMPI)[1] and the real hardware or software. Because the interface is well-defined and the number of types of call is small, it is normally easy to write providers. In particular, the writer of the provider knows nothing of the GUI, BUI, or CLI used by the operator.

WBEM specifications

  • Mappings
    • URI (WBEM URI Mapping Specification 1.0)
    • XML (xmlCIM as used in CIM-XML)
    • XML (WS-CIM as used in WS-Management)
    • UML
  • Protocols
  • Discovery
    • SLP (WBEM Discovery using SLP; SLP Template)
  • Query Language
    • CQL (CIM Query Language 1.0)
    • FQL (Filter Query Language 1.0)

Implementing support

So, which pieces of this does a device manufacturer or service provider have to write?

  • Firstly the model.
This is normally done by extending as necessary one of the standard models published by the DMTF.
  • Then the BUI, GUI, or CLI.
The client and server usually do not need to be written because there are many open-source and commercial implementations available (see External links below)
  • Then the providers
In summary, the WBEM architecture allows the manufacturer of a device or developer of a service to provide a standards-compliant management interface to that device simply and cheaply.

Implementations

WBEM in operating systems

WBEM implementations

  • WS
  • OpenPegasus, open-source client and server written in C++
  • Open Management Infrastructure, open-source client and server written in C
  • OpenWBEM, open-source client and server written in C++
  • WBEM Services, Java
  • SBLIM (pronounced "sublime") Standards Based Linux Instrumentation for Manageability, C, C++, Java
  • PyWBEM, open-source WBEM library written in Python
  • Purgos, open-source management client for Windows written in C++ (Product now discontinued and has reached End Of Life)

See also

  • SMI-S, Storage Management Initiative - Specification. Based on WBEM, used for SAN devices
  • JSR-48, Java API for developing WBEM Clients and WBEM Providers
  • CMPI, C provider API for developing WBEM Providers

References