 | Level: Intermediate Heather Kreger (kreger@us.ibm.com), Lead Architect for Web Services and Management for Standards and Emerging Technologies, IBM
11 Mar 2005 Uncover the motivation behind the development of Web Services Distributed Management (WSDM) 1.0, a new standard that OASIS just approved. This paper gives you an overview of the specification and shows you some of the key design tenants.
The problem that needed wisdom
The industry has been wrestling with the complexity of managing its business systems for years. This complexity stems from the variety of IT resource providers and application providers that enterprises use to build their business systems. A variety of management systems already co-exist to be able to manage the breadth of resources. Ultimately, this creates a classic integration issue: the problem of management integration.
OASIS has just approved a new standard from the Web Services Distributed Management Technical Committee (WSDM) as the first step to solving the management integration problem of Web Services Distributed Management: Management Using Web Services (MUWS) and Web Services Distributed Management: Management of Web Services (MOWS) specifications.
WSDM provides significant value to three major groups:
- Customers with heterogeneous IT environments: WSDM allows management software from different vendors to interoperate more easily, enabling end-to-end and even cross-enterprise management.
- ISVs producing management software: WSDM provides standards for identifying, inspecting, and modifying characteristics of resources in the IT environment. Management applications can take advantage of these to deliver functionality and increase the number and type of resources that management software can address. Over time this will reduce the cost of such applications and broaden their potential function.
- Manufacturers of devices: WSDM provides the ability to expose management interfaces using Web services in a standard way, regardless of how the internal instrumentation is done. Any management vendor can use these Web services interfaces, reducing the amount of custom support required.
The approval of WSDM as an OASIS standard is of interest to all three groups, as well as industry analysts concerned with systems management or Web services.
Overview of WSDM
The Web Services Distributed Management: Management Using Web Services (MUWS) 1.0 specifications define how to represent and access the manageability interfaces of resources as Web services. Standard manageable resource definitions create an integration layer between managers and the different management protocols used to instrument resources. They are the foundation of enabling the use of Web services to build management applications and allowing many managers with one set of instrumentation to manage resources.
The Web Services Distributed Management: Management of Web Services (MOWS) 1.0 specification defines how to manage Web services as resources and how to describe and access that manageability using MUWS. It provides mechanisms and methodologies that enable manageable Web services applications to interoperate across enterprise and organizational boundaries. The MOWS specification allows integration of management with Web services-based business applications and processes.
WSDM uses Web services as a platform to provide essential distributed computing functionality, interoperability, loose coupling, and implementation independence. Therefore, the WSDM specifications depend on the WS-I Basic Profile (BP) plus other Web services foundation specifications being standardized in OASIS:
- WS-Resource Framework (WS-RF) Resource Properties (WSRP) for properties
- WS-Notification (WSN) Base Notifications (WSBN) for management event transport
- WS-Addressing (WSA) for service references
WSDM also utilizes WS-RF Service Groups (WSSG) and WS-Notification WS-Topics (WST) in optional function. WSDM will evolve as the Web services platform and the specifications that WSDM depends on evolve and become standards.
The following lists some of the key design goals for WSDM:
- Resource orientation -- WSDM was representing access to manageable resource interfaces directly as Web services.
- Agent architecture agnostic -- Because Web services easily supports proxy and redirection architectures it is possible to represent and offer the resources as Web services rather than through interfaces on the traditional agent. It might be true that the resource is accessed through an agent or other proxy. It might also be true that the resource, like an application server, supports its manageable resource directly. This implementation choice is not reflected in the interface to the resource or how the manager interacts with it.
- Composability -- Since resources vary dramatically in their capacity and management features, it is important that management capabilities as well as Web services qualities of service, like security, only need to be supported when absolutely necessary. Composability allows scaling down into small devices as well as up to enterprise class environments.
- Design time and run-time inspection -- Management systems must do discovery of environments and resources during run-time, which is usually after they are introduced into existing systems, and on an ongoing basis in order to maintain an accurate understanding of ever-changing environments. Management systems also need to be able to inspect and integrate new resources without having to interact with an instance of the resource. For example, in installation, deployment, and just-in-time resource activation scenarios, the resource might not exist when a manager starts to interact with it.
- Model agnostic -- WSDM does not define what information resources should provide in their management interfaces; this is what a resource model does. WSDM compliments the model by defining how to express that model in XML schema and access the model using Web services.
Let?s take a closer look at the WSDM V1.0 specifications.
Management using Web services
The WSDM MUWS specification provides interoperable, base manageability for monitoring and control managers using Web services. It defines a basic set of manageability capabilities which can be composed to express the capability of the management instrumentation. WSDM MUWS also defines a standard management event format to improve interoperability and correlation. WSDM MUWS 1.0 has been defined in two specifications: MUWS Part 1 (MUWS1), which defines the base architectural concepts and required components and MUWS Part 2 (MUWS2), which defines standard composable support for manageability capabilities.
Manageability capabilities
A manageability capability is a composable set of properties, operations, events, metadata, and other semantics that supports a particular management task. It captures concepts common in most resource information models. Manageability capabilities identify a "contract" that a manageable resource asserts it can offer to clients. A manageability capability can be thought of as an abstract interface, similar to "marker" interfaces in Java or other programming languages. WSDM MUWS defines a set of foundation manageability capabilities for basic management concepts. New or domain-specific capabilities can extend existing foundational capabilities as appropriate.
Expressing capabilities enables more efficient discovery of and introspection of resources since clients (in other words, managers), typically focus on a particular management task or domain, and therefore need to be able to easily and efficiently determine the relevant capabilities of a manageable resource.
There are a few common behaviors for all capabilities. First, each manageability capability is identified by a standard URI. Second, each capability has a WS-Notifications topic used to identify and categorize capability-specific notifications. Third, each capability has metadata defined for its properties and operations. The standard capabilities defined by WSDM MUWS 1.0 include the following:
- Identity -- The Identity capability is the only required capability and is used only to determine if two resources being managed are the same resource. It contains exactly one property, ResourceId, which is unique for the resource. If two manageable resources share the same ID, then they are managing the same resource.
- Description -- The Description capability describes the managable resource?s set of captions, descriptions, and version.
- Manageability Characteristics -- The Manageability Characteristics capability describes the properties of the management interface of the resource. It contains one property, ManageabilityCapability, which contains a list of the URIs of the manageability capabilities supported by the management interface for the resource.
- Correlatable Properties -- The Correlatable Properties capability defines the set of properties that together determine if two manageable resources with different identities are still the same resource. This might happen when a resource is managed by multiple independent providers that are unaware of each other and assign different identities for the resource.
- Metrics -- The Metrics capability defines how to represent and access a collected value during a collection period as well as the current time on the resource. Metrics in particular need metadata to provide context, in other words, when it was collected, how it was collection, how it changes value. Metric property value changes trigger publication of a standard property change event on a standard metrics topic.
- Configuration -- The Configuration capability allows a client to influence the behavior of a resource by setting properties or invoking operations. A standard WS-RF property changed event is used and sent to the configuration topic.
- State -- The State capability a client define a simple property, state, generic state transition event, and state transition topics. Specific state models determine the valid values of state and sub states.
- Operational Status -- The Operational Status capability defines three very simple status levels (available, unavailable, and unknown) as well as events for status changes for interoperability. The resource must understand which states and state changes will map to the more coarse-grained statuses.
- Advertisement -- The Advertisement capability defines a standard event to be sent when a new manageable resource is created.
Figure 1 shows how composability is used to combine qualities of service from the Web services platform with manageability capabilities and resource-specific manageability capabilities. Resource management models help define the contents of resource-specific capabilities.
Figure 1. WSDM composability (MUWS)
Relationships
WSDM supports two kinds of relationships: relationships that are simple data representations of some actual relationship that exists between resources, and relationships between resources that have their own properties and behavior. Data representations of relationships can contain a Web service reference to access the relationship Web service. WSDM defines interfaces to query a manageable resource about the relationships it participates in directly, such as a containment relationship. WSDM also defines an interface for a service that offers relationship information for many manageable resources enabling a relationship registry. Manageable resources do not have to be aware that they are participating in relationships. WSDM does not define any standard relationship types. Listing 1 shows an example relationship from the WSDM MUWS specification:
Listing 1. Example relationship from WSDM MUWS specification
<muws-p2-xs:Relationship>
<muws-p2-xs:Name>SCSI disk attached to the host computer</muws-p2-xs:Name>
<muws-p2-xs:Type>
<scsi:Attached>
<bus:Connected>
<generally:Linked/>
</bus:Connected>
</scsi:Attached>
</muws-p2-xs:Type>
<muws-p2-xs:Participant>
<muws-pl-xs:ManageabilityEndpointReference>
...EPR1...
</muws-p1-xs:ManageabilityEndpointReference>
<muws-p1-xs:ResourceID>urn:uuid:123</muws-p1-xs:ResourceID>
<muws-p2-xs:Role>urn:role:bus:host</muws-p2-xs:Role>
<netop-xs:HostName>myhost.myorg.org</netop-xs:NostName>
</muws-p2-xs:Participant>
<muws-p2-xs:Participant>
<muws-p2-xs:Role>urn:role:bus:device</muws-p2-xs:Role>
<scsi-xs:Port>2</scsi-xs:Port>
<scsi-xs:CH>0</scsi-xs:CH>
<scsi-xs:BusID>5</scsi-xs:BusID>
<scsi-xs:LUN>0</scsi-xs:LUN>
<mows-xs:EndpointReference>
...EPR2...
</mows-xs:EndpointReference>
<.muws-p2-xs:Participant>
</muws-p2-xs:Relationship>
|
It describes a Attached.Connected.Linked relationship between a host and a device.
WSDM Event Format
The WSDM Event Format is an extensible XML format that defines a set of basic, consistent, data elements that allow different types of management event information to be carried in a consistent manner. The WSDM Event Format enables programmatic processing, correlation, and interpretation of events from different products, platforms, and management technologies.
The WSDM Event Format is organized into three categories for management event data: the event reporter, the event source, and situation data. Each category defines a few standard properties that are found in most management events and can be extended to add event and situation-specific data. The situation data includes situation time, situation category, situation disposition priority, severity, message, and substitutable message elements. WSDM also defines a standard set of priorities, severities, and situation categories, including StartSituation, StopSituation, and CreateSituation, to facilitate common understanding of events received from a variety of resources, resource instrumentation, and management infrastructure.
Discovery and advertising While there are many ways to advertise and discover resources, the WSDM specification provides some support for the following three methodologies:
- Advertisement events: WSDM defines an advertisement capability that defines a standard event to be sent when a new manageable resource is created.
- Relationships: WSDM defines relationships that can be traversed from a resource or through a registry to find additional manageable resources as participants.
- Registration: WSDM recommends how to use WS-RF Service Groups as queryable manageable resource registries.
Management of Web services
WSDM's Management of Web Services specification extends MUWS to define how to specifically manage a resource that is a Web service. Web services, like other resources, have identity, metrics, configuration, and other capabilities to enable management. For Web services the composability characteristic is especially interesting because it allows the business function of a service and the management function for a service to be composed together into a single service. This makes it very easy to have business processes that seamlessly move from using a service as a task, to managing the service if the task fails, providing either compensation, re-routing, or correction of the failure in automated real-time.
Manageability capabilities for Web services
WSDM MOWS defines the following MUWS capabilities for Web services:
- Identity -- The MUWS Identity capability defines a unique identity for the Web service.
- Identification -- Identification capability defines a reference to the Web service being managed.
- Metrics -- The MOWS Metrics capability defines a set of basic metrics for a Web service: NumberOf Requests, NumberOfFailedRequest, NumberOfSuccessfulRequests, ServiceTime, MaxResponseTime, and LastResponseTime.
- OperationalState -- The MOWS Operational State capability provides the current operational state of the service. The valid states are Up with substates of Busy and Idle and Down with substates of Stopped, Crashed, and Saturated.
- OperationalStatus -- The MUWS Operational Status capability provides the high-level status of the services: all Up states return Available and all Down states return as status of Unavailable, except for Saturated which returns PartiallyAvailable.
- RequestProcessingState -- The MOWS Request Processing State capability defines a request state diagram and provides a mechanism to define events to be sent when request processing states change.
Example
Figure 2 shows how a manageable Web printer service could be composed, according to the WSDM MOWS specification (MOWS). The functional interface for the printer is a simple Print operation defined and accessed as a WSDL operation. The Resource management interface, which manages the printer device itself, offers two properties -- PrintedPageCount and AvailableTonerCapacity -- and an Enable operation. The properties are advertised in the Resource Properties Document and are accessible through the WS-RF GetProperties operation. Finally the Manageability Capability for managing the printer Web service offers the MOWS metrics, NumberOfRequests, and the additional operational status control operations: Start and Stop.
Figure 2. Manageable printer
This produces a resource properties document that defines both the Resource Manageability Capability and Web services manageability properties as global element declarations in the schema, as Listing 2 shows:
Listing 2. Definition of properties for a manageable printer
?
<xs:element name="ResourceId" type="xs:anyURI"/>
<xs:element name="PrintedPageCount" type="xsd:positiveInteger" />
<xs:element name="AvailableTonerCapacity" type="xsd:positiveInteger" />
<xs:element name="NumberOfRequests" type="mows-xs:IntegerCounter" />
<xs:element name="NumberOfSuccessfulRequests" type="mows-xs:IntegerCounter" />
<xs:element name="NumberOfFailedRequests" type="mows-xs:IntegerCounter" />
<xs:element name="ServiceTime" type="mows-xs:DurationMetric" />
<xs:element name="MaxResponseTime" type="mows-xs:DurationMetric" />
<xs:element name="LastResponseTime" type="mows-xs:DurationMetric" />
?
|
The WSDL interface would contain 4 operations and the WSRF GetProperty operations, as Listing 3 shows:
Listing 3. Definition of operations for a manageable printer
<portType name="ManageablePrinter"
wsrf-rp:ResourceProperties="Printers:PrinterProperties">
<wsdl:operation name="Print" >
<wsdl:input ? />
<wsdl:output ? /></wsdl:operation>
<wsdl:operation name="Enable" >
<wsdl:input ? />
<wsdl:output ? /></wsdl:operation>
<wsdl:operation name="Stop" >
<wsdl:input ? />
<wsdl:output ? /></wsdl:operation>
<wsdl:operation name="Start" >
<wsdl:input ? />
<wsdl:output ? /></operation>
<wsdl:operation name="GetResourceProperty">
<wsdl:input name="GetResourcePropertyRequest"
message="wsrp:GetResourcePropertyRequest" />
<wsdl:output name="GetResourcePropertyResponse"
message="wsrp:GetResourcePropertyResponse" />
<wsdl:fault name="UnknownResource"
message="wsrp:ErrorMessage" />
<wsdl:fault name="InvalidResourcePropertyQName"
message="wsrp:ErrorMessage" /></wsdl:operation>
? (other operations)
</portType>
|
If the printer also supported notifications when metrics changed, the event schema would be as shown in Listing 4:
Listing 4. WSDM Event Format for a metric property change event
<muws-p1-xs:ManagementEvent ...
muws-p1-xs:ReportTime="2004-11-11T18:06:00Z">
<muws-p1-xs:EventId>urn:uuid:384329757082303</muws-p1-xs:EventId>
<muws-p1-xs:SourceComponent ...>
<muws-p1-xs:ResourceId>urn:ibm:printer2110</muws-p1-xs:ResourceId>
<muws-p1-xs:ComponentAddress>9.62.101.41</muws-p1-xs:ComponentAddress>
</muws-p1-xs:SourceComponent>
<muws-p2-xs:Situation>
<muws-p2-xs:SituationCategory>ReportSituation
</muws-p2-xs:SituationCategory>
<muws-p2-xs:SuccessDisposition>Sucessful
</muws-p2-xs:SuccessDisposition>
<muws-p2-xs:SituationTime>2004-11-11T18:06:00Z
</muws-p2-xs:SituationTime>
<muws-p2-xs:Severity>1</muws-p2-xs:Severity>
<ws-rf-rp-xs:ResourcePropertyValueChangeNotification>
<ws-rf-rp-xs:OldValue>
< muws-p2-xs:NumberOfRequests
LastUpdated="2004-11-11T18:06:00Z">10
</ muws-p2-xs:NumberOfRequests>
</ws-rf-rp-xs:OldValue>
<ws-rf-rp-xs:newValue>
< muws-p2-xs:NumberOfRequests
LastUpdated="2004-11-11T18:01:00Z">9
</ muws-p2-xs:NumberOfRequests>
</ws-rf-rp-xs:NewValue>
</ws-rf-rp-xs:ResourcePropertyValueChangeNotification>
</muws-p1-xs:ManagementEvent>
|
The WS-Notification topics would be:
Listing 5. WS-Notification topic:
<wstop:Topic name="MetricsCapability" messageTypes="muws-xs1:ManagementEvent" />
|
Conclusion
The WSDM 1.0 specifications lay the foundation for using Web services as a management platform. Now that the specification has been approved, there will be activities to educate the industry and align it with other system management activities. WSDM will continue to evolve in many ways. WSDM will evolve as the specifications it depends on become OASIS and W3C standards. WSDM will evolve as it begins to be applied in the Distributed Management Task Force (DFTM) and other management organizations and adds new functionality to its scope. WSDM will also evolve as the industry sorts out competing and overlapping specifications.
Resources - Find the DMTF CIM Schema on the Distributed Management Task Force, Inc. Web site.
- Get the following specfiications (some of which are still in committee or working draft):
- Find more information by visiting the following technical committees:
- Browse for books on these and other technical topics.
- Get involved in the developerWorks community by participating in
developerWorks blogs.
- The IBM developerWorks team hosts hundreds of technical briefings around the world which you can attend at no charge.
- Want more? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
About the author | | | Heather Kreger is a lead architect for Web Services and Management in the Standards and Emerging Technologies area. She is currently co-lead of the OASIS Web Services Distributed Management Technical Committee and member of several related DMTF Work Groups. Heather was an IBM representative to the W3C Web Services Architecture Working Group as well as co-lead of JSR109, which specifies Web services deployment in J2EE environments, and a contributor to the Java Management Extensions (JMX) specification. Heather is also the author of numerous articles on Web services and management in the IBM Systems Journal, Communications of ACM, Web Services Journal, and other public technical work including "Web Services Conceptual Architecture," WS-Manageability, and her book Java and JMX, Building Manageable Systems. |
Rate this page
| |
