Ws WSDM LTR PDF

Understand Web Services Distributed Management (WSDM)
Skill Level: Introductory Mr. Martin Brown (mc@mcslp.com) Professional writer MCslp
19 Jul 2005 Management through Web services simplifies the numerous interfaces and solutions that provide management tools for network-attached systems and devices. These range from simple printers to more complex operating system management issues. The Web Services Distributed Management (WSDM) standard defines two different environments, Management Using Web Services (MUWS) and Management of Web Services (MOWS), that define the structure and environment required to support these systems. This tutorial looks in detail at the definition and implementation issues of WSDM and how you can use WSDM within grid environments for the management of grids and grid services.
Section 1. Start here

Who should take this tutorial?
The Web Services Distributed Management (WSDM) specification defines the methods, structure, and specification of a system for managing network resources (printers, routers, servers and services, for example) and for managing Web services (used to support your network functionality). You can also use WSDM to manage the Web services that support your business applications. If you are interested in developing WSDM services, either to support your resources, or as a consumer, this tutorial will help you understand the basic mechanics and implementation fundamentals required to build your WSDM environment.
Understand Web Services Distributed Management (WSDM) Copyright IBM Corporation 1994, 2008. All rights reserved.
Page 1 of 28
developerWorks
ibm.com/developerWorks
What is this tutorial about?

The main content of this tutorial describes the WSDM specification with respect to deploying the solution within your network. The tutorial includes background information on the standard along with basic implementation notes on generating the necessary XML used to support the standard and Java code required to manipulate and use them. The tutorial incorporates the following topics: WSDM overview WSDM Management Using Web Services (MUWS) WSDM Management of Web Services (MOWS) WSDM events WSDM in grids The first half of the tutorial is devoted to the conceptual ideas behind the WSDM standard, covering the basic mechanics of the standard and how it fits into your existing network and Service-Oriented Architecture (SOA) environment. The second half of the tutorial covers the basics of implementation of the WSDM standard, including looking at sample WSDL and XML schema files that could be used to build a sample system. The examples in this tutorial use the "network printer" model. OASIS uses this model in its documentation, and it should enable you to connect the descriptions given here to the specific components of the WSDM specification in the official OASIS documentation.
Prerequisites
You will not need any specific tools to understand the majority of the content of this tutorial. However, some of the examples do require understanding of the OASIS standards and Web services mechanics such as WS-Addressing, WS-ResourceFramework, and WS-Notification. The Resources section at the end of this tutorial contains links to the specifications for WSDM, WSDL, WSRF, and other specifications discussed in this tutorial. To be successful with this tutorial, you should understand XML, XML Schemas, and the Web Services Description Language (WSDL). You will also benefit from having
Understand Web Services Distributed Management (WSDM) Page 2 of 28
Copyright IBM Corporation 1994, 2008. All rights reserved.
developerWorks
knowledge of the Web Services Resource Framework (WSRF) standard that is used during the definition of resources and capabilities of WSDM resources. You might find the Emerging Technologies Toolkit (ETTK) useful; it contains some examples and utilities that demonstrate some of the WSDM principles. For information on the ETTK and download links, look at the ETTK page.
Section 2. Overview of WSDM

Modern management
Ask most system administrators what their biggest issue with administration in the enterprise is and they will probably answer, "management tools." Ask those in the heterogeneous enterprise the same question and the answer will be the same. The problem is that while there are plenty of management tools and infrastructures available that provide management of specific services within specific environments, obtaining tools that work across environments of the modern network are hard to find, difficult to work with, and generally based on proprietary technology. The WSDM standard aims to solve many of these problems through the use of open standards for the definition of management tools and interfaces used in combination with Web services to provide the functional requirements of the service. WSDM also defines a standard for managing Web services in the enterprise. This should give WSDM broader appeal than simple system-level administration and management. Because the standard is being designed as a practical method for managing resources and information, WSDM can also be used for other systems that might be used within a distributed environment. WSDM is expected to be a practical standard for the management of business process information. For example, adding a WSDM interface to your order process system might enable clients and partners to place orders, raise invoices, and even to automatically re-order goods or adjust invoicing costs.
WSDM target audiences

Because WSDM is based on open standards, companies can produce Web services
Page 3 of 28
developerWorks
that any Web service client can use to support specific areas of functionality. For example, an Original Equipment Manufacturer (OEM) such as Hewlett Packard could create a WSDM-defined interface for switching a printer between online and offline modes. Other printer manufacturers could provide the same functionality through WSDM on their products. Then, using a suitable Web service-enabled client, a user could control any printer, regardless of the manufacturer. You can see from this example that WSDM will help users, independent software vendors (ISVs), and OEMs: Customers will be able to manage the equipment, systems, and services in their networks much more easily due to implementation of WSDM. A single management application could be used to manage and monitor all the systems within either a homogenous or heterogeneous network. ISVs will be able to produce software that supports the management process users require. Because the WSDM standard is employed across the components and systems in the network, developing the management application should be a simple case of applying the WSDM standard and using the resources published by WSDM-compliant systems. Manufacturers will benefit because it will simplify the exposure of their devices and systems to the outside world for the purposes of management. Many companies, OEMs especially, spend millions of dollars each year developing the software that allows users and administrators to interface to their products. By using WSDM, they can simplify the external interface, and make both their lives and their client's lives significantly easier. You can see the relationships, and the audiences affected, in Figure 1. Figure 1. Where WSDM fits in your network
developerWorks
Now we'll take a closer look at the WSDM standard.
What is WSDM?
The WSDM standard is an attempt to resolve the problems described in the previous section. Essentially, WSDM is a standard for describing the management information and capabilities for a particular device, application, or component. All the descriptions are produced using the Web Services Description Language (WSDL) and at the time of writing this tutorial, no specifications exist, implied or otherwise, for implementing the WSDM standard to achieve your goals. The WSDM standard is actually made up of two different standards: Web Services Distributed Management: Management Using Web Services (WSDM-MUWS)
Page 5 of 28
developerWorks
Web Services Distributed Management: Management of Web Services (WSDM-MOWS) WSDM-MUWS provides the definition for how to represent and access interfaces to MUWS resources. For example, the MUWS standard provides the necessary structure for advertising the service, the services capabilities, and the information that needs to be supplied or received to manage the resource. WSDM-MOWS provides the definition for managing Web services. MOWS uses many of the concepts and systems defined by the MUWS standard, but also adds resources and capabilities specific to the needs of management of Web services. The MOWS component provides the methods and systems to enable Web services to be managed remotely. It is MOWS that is expected to be used more for the management of business processes.
WSDM in your network

You will likely come across WSDM in your network either as a user, ISV, or manufacturer. Take a closer look at these environments and how WSDM would affect your network. You can see in Figure 2 the relationship between MUWS, MOWS, and traditional Web services with respect to the management and usage of a printer. Users will interface to the printer using a standard Web services interface; this is how they will print documents. Print managers -- computerized or human -- will manage the printer using MUWS. IT Managers will be able to control the printer using MUWS and the Web services that support MUWS and the print service (used by users to submit documents for printing) using MOWS. Figure 2. Web Services, MOWS, and MUWS in action
developerWorks
You'll see in more detail later in this tutorial the differences and similarities between these two systems at the definition level.
WSDM and Service-Oriented Architecture (SOA)

The Service-Oriented Architecture (SOA) is the definition for a new way of deploying services across your network. Instead of centralized servers managing single operations, you use a number of servers in a distributed and flexible structure, accessed through a Web services model. Because we are not tied to the capabilities or power of one server, it is easy to expand and enhance the system. Also, because the system is built on top of Web services, it is easy to use and is compatible with a much wider range of systems. WSDM is an important part of the move to the Service Oriented-Architecture because it provides the methodologies required to manage both the resources on the main network and the Web services used to support SOA itself.
Page 7 of 28
developerWorks
WSDM security
WSDM does not include any kind of security mechanism. Instead, WSDM will use the Web services platform on which WSDM is based to provide the necessary security mechanisms. This does not mean that we can ignore security within WSDM, but you should be aware of the potential security threats from: Message alteration Security keys Authentication Accounting/accountability You should be familiar with the WS-Security (WSS) standard and its use within the rest of the Web services framework.
Section 3. WSDM, WSDL, and other standards

The WSDM application model
The WSDM standard uses Web services as a platform to provide all of the essential functionality that supports the distributed management platform. The advantage of this is that much of the technology and experience is built-in. It also means that we do not have to worry about the technicalities of platform independence -- that is what the Web services platform already provides. WSDM relies directly on other standards from OASIS, so implementation relies on the following systems: WS-I Basic Profile WS-Resource Framework (WSRF) and WS-Resource Properties (WSRP) for the properties and description used to define the capabilities of the WSDM components.
developerWorks
WS-Notification (WSN) and WS-Base Notifications (WSBN) for management events (we'll cover events later in The event model section). WS-Addressing (WSA) for service references and to define the end points for individual services. The next section looks at WS-Addressing; we'll cover the specifics of the other technologies when we take a closer look at the details of the implementations of the WSDM standard later in this tutorial.
WSDM and WS-Addressing

WS-Addressing is used by WSDM -- as with all other Web services -- to define the endpoint reference, which in turn is simply the address and resource ID required to identify the resource. From an implementation point of view, the endpoint reference is vital because it is the information you need to initiate communication with a resource. Here is a sample endpoint reference, including a ResourceID.
<wsa:EndpointReference> <wsa:Address> http://mcslp.com/ibm/wsdm/services/printerservice </wsa:Address> <wsa:ReferenceProperties> <tns:ResourceID>Inkjet-9994</tns:ResourceID> </wsa:ReferenceProperties> </wsa:EndpointReference>
The endpoint reference is the only piece of information required by all the components of the system, as it's the one element that enables the components to communicate with each other.
Section 4. Management Using Web Services (WSDM-MUWS)

MUWS overview
Page 9 of 28
developerWorks
MUWS consists of two main standards: MUWS Part 1 (MUWS1) defines the base architectural concepts and required components; and MUWS Part 2 (MUWS2) defines the standard used to specify support for manageability capabilities. MUWS1 defines the properties of the resource that are required to interface to the Web services. For example, MUWS1 part components in the definition might define the resource ID used to identify the system. MUWS2 defines components of the entity. For example, descriptions, systems, and interfaces to the entity are the responsibility of the MUWS2 specification. The definition of the resource is handled through capabilities. These define the functionality, properties, and other settings. Some of these are required (for example, the identity of the resource), and others are optional and generally specific and unique to the resource in question. Next, take a closer look at their capabilities and how they relate to the functionality of the resource.
MUWS capability definitions

The MUWS system relies on a defined set of properties, operations, events, metadata, and other components that support a particular management task. For example, our printer resource will use the MUWS specification to describe the functionality available to a management application, such as the ability to enable or disable the printer, or to get the basic properties of the printer such as the page count, toner levels, and so on. The manageability capabilities are what define this information. A manageability capability is best thought of as an interface to the internal workings of the Web services that support them. Essentially each manageability capability is a marker that points to a specific capability; for example, a marker would exist that points to the Web service and necessary parameters required to enable the printer (that is, switch it from offline to online mode). The role of the manageability capability is to list the available operations on a resource so that management software can get a list of the available operations. The entire capability list is the contents page of functionality for the resource. Capabilities are defined using XML and might share similar attributes. Standard capabilities defined within the MUWS standard are designed to define specific capabilities or operations. The MUWS standard includes definitions for the following capabilities:
developerWorks
Identity -- the identity of the resource Description -- defines the list of captions, descriptions, and version information used to provide a human-readable identity for the resource Manageability Characteristics -- describes the properties of the interface for managing this component Correlatable properties -- defines the properties that determine if two manageable resources with different identities are actually the same resource Metrics -- defines how to represent and access information about a specific property Configuration -- defines how to change the configuration of a resource State -- defines how to change the state of a resource Operational Status -- defines the status levels for a resource. The MUWS specification includes three basic states (available, unavailable, and unknown) Advertisement -- defines the event to be raised when a new manageable resource is created Note that the above list is only a list of standard manageability capabilities; you are free to define your own as required by the resource you are defining.
MUWS relationships
Relationships define the interaction between components. For example, in a high-end printer, the printer unit and a stapler unit might be separate manageable components, but the manageability capabilities of both units interrelate. The MUWS relationship definition is a way of defining this relationship so that management software is aware that management of one resource might have an impact on other resources. These can be related components, as in the printer/stapler example here, or it could be a relationship through containment, for example the hard disk resource that is part of a larger computing resource. Check the MUWS Part 2 documentation for more information on relationships and their definition (see Resources ).
Page 11 of 28
developerWorks
Basic implementation
The implementation of the WSDM standards is actually relatively straightforward. We'll ignore the requirements of building the specific Web services for individual systems in our sample resource. You don't need to worry at this stage about how you actually implement an operation like a page count. The bulk of the implementation of MUWS relates to building the correct WSDL, WSRP, and WSRF documents that define the properties and capabilities of the system. To start, any resource must first define the property information that specifies the ResourceID -- the only required component of the system. A ResourceID is used to identify a resource throughout the life of the resource. ResourceIDs must be unique for a specific resource. To define the ResourceID for our sample printer, you would use a schema document like the one below.
<?xml version="1.0" encoding="utf-8"?> <xs:schema targetNamespace="http://mcslp.com/ibm/wsdm/services/BasicPrinter.xsd" xmlns:muws-p1-xs="http://docs.oasis-open.org/wsdm/2004/12 /muws/wsdm-muws-part1.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:import namespace="http://docs.oasis-open.org/wsdm/2004/12/muws/wsdm-muws-part1.xsd" schemaLocation="http://docs.oasis-open.org/wsdm/2004/12/muws/ wsdm-muws-part1.xsd"/> <xs:element name="BasicPrinter"> <xs:complexType> <xs:sequence> <xs:element ref="muws-p1-xs:ResourceId"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
You can see that this defines one very simple property, the ResourceID. The bulk of the document is made up of the namespace definitions required for the rest of the document.
Defining resource properties

Now we'll expand on the previous example and add the properties for the printer. Remember that properties define information about the printer, so you might want to know the following:
developerWorks
Page Count (useful for monitoring usage) Toner Capacity (useful to monitor when you might need to replace a cartridge) Operational Status (whether the printer is online or offline) You can specify this by extending the XSD definition for a specific printer model. The example below is for a mythical inkjet.
<?xml version="1.0" encoding="utf-8"?> <xs:schema targetNamespace="http://mcslp.com/ibm/wsdm/services/InkjetPrinter.xsd" xmlns:muws-p1-xs="http://docs.oasis-open.org/wsdm/2004/12/ muws/wsdm-muws-part1.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:import namespace="http://docs.oasis-open.org/wsdm/2004/12/muws/ wsdm-muws-part1.xsd" schemaLocation="http://docs.oasis-open.org/wsdm/2004/12/muws/ wsdm-muws-part1.xsd"/> <xs:import namespace="http://docs.oasis-open.org/wsdm/2004/12/muws/ wsdm-muws-part2.xsd" schemaLocation="http://docs.oasis-open.org/wsdm/2004/12/muws/ wsdm-muws-part2.xsd"/> <xs:element name="InkjetPrinter"> <xs:complexType> <xs:sequence> <xs:element name="ResourceID" ref="muws-p1-xs:ResourceId"/> <xs:element name="PageCount" ref="xsd:positiveInteger"/> <xs:element name="TonerCapacity" ref="xsd:positiveInteger"/> <xs:element name="OperationalStatus" ref="muws-p2-xs:OperationalStatus"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
Two changes of note in this definition. First, we've imported the MUWS Part 2 XSD. This is because we need the definition of the OperationalStatus capability within our definition. OperationalStatus provides a string representation of the high-level status of a service; in this case, the status of the printer itself. You can see this defined in XSD model for MUWS Part 2, as seen here in Figure 3. Figure 3. OperationalStatus potential values
Page 13 of 28
developerWorks
We are still dealing with schemas; it is up to the implementation to provide the correct response in this situation.
Obtaining resource properties

To access resource properties, you need to create a WSDL file that contains the operations for determining the resources. The header has been dropped from the following WSDL sample for brevity:
<wsdl:portType name="InkjetPrinter" wsrf-rp:ResourceProperties="rxs:InkjetPrinter"> <wsdl:operation name="GetResourceProperty"> <wsdl:input name="GetResourcePropertyRequest" message="wsrp:GetResourcePropertyRequest"/> <wsdl:output name="GetResourcePropertyResponse" message="wsrp:GetResourcePropertyResponse"/> </wsdl:operation> </wsdl:portType>
This defines the basic operation of how to request a property, the response, and what to do when there is a fault. Actually returning the properties is a simple case of building a suitable Web service to return the property data. Note that we've referenced the schema definition for the InkjetPrinter for our resource within the WSDL portType definition. You will also need to import the schema into the namespace:
xmlns:rxs="http://mcslp.com/ibm/wsdm/services/InkjetPrinter.xsd"
This ensures that you know the format of the resources that might be loaded through the main (and required) operation of obtaining the properties for the printer. Now you need to add the binding information required to obtain the information. To that end, you should adjust the WSDL specification to include the SOAP action required to get a property:
developerWorks
<wsdl:binding name="InkjetSoapHttpBinding" type="rxs:InkjetPrinter"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="GetResourceProperty"> <soap:operation soapAction="http://mcslp.com/ibm/wsdm/Printer/ManagementProvider/ GetResourceProperty"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding>
This now provides you with the basic framework for getting information about the printer; that's the first step towards providing a management interface. You could also have defined it by specifying an endpoint service that would have acted as a prefix to a SOAP operation defined above. From a management perspective, some of the properties for your resource would be "read-only"; that is you read the property value to determine a static piece of information, such as the page count of the printer. Other properties might be "read-write;" for example, the settings for the number of copies generated with each request or the size of paper in a particular tray.
Adding manageability capabilities

Now that we have the basic structure of the properties for the resource, we need to add in the manageability capabilities. These are added as further options to the WSDL for the resource. Some operations that are valid for the printer would be the simple operations of enabling and disabling the printer (or, switching between online and offline mode). Again, adding the WSDL definitions is straightforward:
<wsdl:operation name="Enable"> <soap:operation soapAction="http://mcslp.com/ibm/wsdm/Printer/ ManagementProvider/Enable"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output>
Page 15 of 28
developerWorks
</wsdl:operation>
The background implementation is again specific to the resource we are managing. In the case of our printer, our Web service would be a simple wrapper around the printer's internal firmware that enabled and disabled the printer accordingly.
MUWS resource summary

You can see from the previous sections that the core of the MUWS specification is really just extensions to existing standards such as WSRP and WSRF in combination with the WSDL that describes the location of various Web services used to access and control the resource. The key component is the definition of the services available to us to control, and the schemas which provide the information about the different elements and properties and their expected contents that we need to use to integrate with those services. Behind these definitions is the actual implementation of the services in question. Providing a Web service for returning properties is straightforward (see Resources at the end of this tutorial for some examples). Web services implementations for specific manageability capabilities -- for example, enabling or disabling a printer -are implementation-specific, but again, are based on the basic principles of Web services. Up to now, however, we have been working with the client side of the process. The management side -- that is, the software that will use the information generated by the resources and their definitions -- is more complex.
Manageability consumer
The manageability consumer is the name of an application that uses WSDM schemas and definitions to communicate with and manage a resource. The obvious example would be a management application that would enable a systems administrator to monitor and manage printers, routers, and other devices. The diagram demonstrating the connectivity between the consumer and the resource is surprisingly easy and is shown here in Figure 4. Figure 4. Consumers and resources
developerWorks
The manageability consumer has a number of roles and responsibilities: It must know the Web service endpoint of the resource it is managing. In our example, the management software must know the endpoint reference of the printer so that it knows to whom to talk. Once an endpoint reference is known, the consumer must contact the resource (the printer) and determine what can be done with the resource. The primary method of determining this information is to download the schema for the resource or to use a Web service that returns the XML (and WSDL if necessary) describing the functionality of the device. A manageability consumer might also subscribe to WSDM events. Events are used to communicate information, such as a change of configuration or a change of simple metrics (an increase in one of the manageability properties -- page count, for example). These events help monitor the system without relying on developing complex Web services to communicate the information. Actually using the information from a resource is relatively straightforward; the manageability consumer downloads the WSDL and schema and then parses this information to determine what is possible. Similarly, exposing the configuration information is also straightforward. In fact, you could simply provide the required elements as bare files either served directly, or available through part of the Web services interface, to supply the files back. Performing those operations is straightforward, but slightly beyond the scope of this tutorial. One last part of the puzzle needs to be discussed - how do you determine what resources are available to manage?
Determining what is available

Unfortunately, the WSDM standard doesn't yet provide a solution to the problem of
Page 17 of 28
developerWorks
determining what resources are available to manage. There are a number of possible options, but the most obvious is simply to standardize on a way to bootstrap the endpoint reference for a given resource so that the information required to manage it can be downloaded. For example, within our consumer we'd supply the URL of the resource, such as http://inkjet.mcslp.com/wsdm, and this would return the true endpoint reference, and thus the resource ID, and then the information to download the WSDL and XML required to manage the resource. Until some decision is made, you can't determine what the final solution will be. However, the complexity of WSDM is in the definition of available resources and manageability endpoints, and these are simple XML documents. Once downloaded, the rest of the process is remarkably easy.
Section 5. Management of Web services (WSDM-MOWS)

MOWS overview
The WSDM-MOWS specification is an extension of WSDM-MUWS that defines how to manage a Web service. Since a Web service is essentially just another resource on your distributed network, it makes sense that you should be able to control and manage it with the same WSDM system that you would use to manage the printer, and therefore the same Web services style interface you would use to manage the printer and submit print jobs. MOWS enables you to configure the same basic parameters for an administration service as for the Web service itself. For example, the Web service that provides the Print service in our sample printer would have its own identity, metrics, configuration, and other capabilities just as the Print action itself does. When considering non-device-based services, MOWS can combine both the business function and the management function through Web services. From an administration point of view, it means that we cannot only publish the Web services provided by a system, but we must also publish the services that manage it. The key to MOWS is the capability definitions. These are similar to the MUWS definitions you've already seen, but designed for Web services. Take a closer look.
developerWorks
Setting up
MOWS capabilities are similar to MUWS definitions, but the standard schemas provide information about properties specific to the process of managing Web services. In particular, the MOWS standard includes definitions for the following: Identity -- a unique identity for the service Identification -- a human readable identification of the resource (printer name, caption, location) Metrics -- a number of basic metric information is defined within the standard, including NumberOfRequests, NumberOfFailedRequests, NumberOfSuccessfulRequests, ServiceTime, MaxResponseTime, and LastResponseTime. All this information will be useful to a management application to determine the status of the Web service you are managing. OperationalState -- the MOWS operational state provides two main states, Up and Down, with sub states; Busy and Idle for Up; Stopped, Crashed, and Saturated for Down. OperationalStatus -- a summary of the current status, based on the MUWS OperationalStatus. Within MOWS, all Up states return Available, and all Down states return Unavailable, except Saturated, which returns PartiallyAvailable. Note that additional capabilities and properties can be defined with the appropriate schema definition. Check the MOWS schema for examples of the standard definitions given above. The MOWS schema also includes standard definitions for a number of metric types, including IntegerCounter (as used for the NumberOfRequests metric) and DurationMetric (as used for MaxResponseTime).
Adding MOWS capabilities to the printer

Adding MOWS properties to the schema for our inkjet printer requires adding further property definitions to the XSD schema we created in MUWS overview. For example, we might want to add the following standard property types:
<xs:element name="NumberOfRequests" type="mows-xs:IntegerCounter" /> <xs:element name="NumberOfSuccessfulRequests" type="mows-xs:IntegerCounter" />
Page 19 of 28
developerWorks
<xs:element <xs:element <xs:element <xs:element
name="NumberOfFailedRequests" type="mows-xs:IntegerCounter" /> name="ServiceTime" type="mows-xs:DurationMetric" /> name="MaxResponseTime" type="mows-xs:DurationMetric" /> name="LastResponseTime" type="mows-xs:DurationMetric" />
Make sure that you add a namespace definition to your schema if you are adding these. Endpoints to control the Web services on the machine are defined in our WSDL document:
<wsdl:operation name="Start"> <soap:operation soapAction="http://mcslp.com/ibm/wsdm/Printer/Start"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="Stop"> <soap:operation soapAction="http://mcslp.com/ibm/wsdm/Printer/Stop"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> </wsdl:operation>
As before, we use literals as values for the input and output of the SOAP messages, the exact information here will depend on the implementation, and what information you want to communicate during the process.
Section 6. WSDM events

The event model
WSDM events communicate information between different components in a WSDM system. Each WSDM is an XML file that contains the information required to notify or record a specific event within the scope of management. For example, a WSDM event might be used to notify a management application when the toner in our sample printer goes below a certain level, say 10%.
developerWorks
WSDM events can also be used within the realm of MOWS in that you can use a WSDM event to advertise a WSDM service to a management application. For example, when management software contacts the printer, WSDM events describe the capabilities to the management application. This makes WSDM self-managing; providing the management application can decode the XML that defines each event. WSDM also allows you to use the relationship definitions and the service groups component of WSRF to register these capabilities. If you are familiar with WS-Notification, the basics of WSDM events are very similar. The manageability consumer "subscribes" to an event topic and is then notified each time a particular event within that topic occurs. Both the MOWS and MUWS standards define a number of standard topics, which you'll see next.
Event format
A WSDM event is just an XML document that contains information about the event. The WSDM Event Format is designed to provide a flexible framework for reporting information in a way that makes it easy for manageability consumers to understand the event and extract the necessary information. According to the WSDM standard, the WSDM Event Format must provide the following essential information: The identification of the resource experiencing an event (the source) The identification of the reporter of an event (the reporter) Generally the source and reporter will be identical. The format also includes elements that can define the date and time of the event, a unique ID for the event, and of course the event information. The following is the XML representation of the WSDM-MUWS management event:
<muws-p1-xs:ManagementEvent muws-p1-xs:ReportTime="xs:dateTime"?> <muws-p1-xs:EventId>xs:anyURI</muws-p1-xs:EventId> <muws-p1-xs:SourceComponent> <muws-p1-xs:ResourceId>xs:anyURI</muws-p1-xs:ResourceId> <muws-p1-xs:ComponentAddress>[address]</muws-p1-xs:ComponentAddress> </muws-p1-xs:SourceComponent> <muws-p1-xs:ReporterComponent>
Page 21 of 28
developerWorks
<muws-p1-xs:ResourceID>xs:anyURI</muws-p1-xs:ResourceId> <muws-p1-xs:ComponentAddress>[address]</muws-p1-xs:ComponentAddress> </muws-p1-xs:ReporterComponent> </muws-p1-xs:ManagementEvent>
Part 2 of MUWS defines additional fields such as the category for the event, disposition (typically the result of an operation), and so on. MOWS events describe events that affect the Web services. For example, the manageability consumer might want to subscribe to messages about the Web service being enabled or disabled so that it could monitor the status if another consumer changed the state of the service.
Event topics
Both MUWS and MOWS include a number of default topics, although as usual you can create your own. The MUWS topics are self explanatory: IdentityCapability ManageabilityCharacteristicsCapability CorrelatablePropertiesCapability DescriptionCapability StateCapability OperationalStatusCapability MetricsCapability ConfigurationCapability RelationshipsCapability RelationshipCreated RelationshipDeleted RelationshipAccessCapability RelationshipResourceCapability ManageabilityEndpointCreation ManageableResourceCreation ManageabilityEndpointDestruction
developerWorks
ManageableResourceDestruction MOWS topics follow the notifications for Web services you might expect: IdentificationCapability MetricsCapability OperationalStateCapability OperationalStatusCapability RequestProcessingStateCapability RequestProcessingObservations RequestReceived RequestProcessing RequestCompleted RequestFailed RequestProcessingObservationsWithAttachments RequestReceived RequestProcessing RequestCompleted RequestFailed For more information on WS-Notification, subscriptions, topics, and how to create the event XML, see the Resources at the end of this tutorial for an introduction on Using WS-Notification.
Section 7. WSDM in grid environments

WSDM in grids overview
Within a grid environment, determining the functionality of a grid node is one of the
Page 23 of 28
developerWorks
hardest processes and often requires the use of static WSDL documentation that the grid management computers know about before they start using the node, rather than determining the capabilities on the fly. WSDM within a grid environment will therefore make it easier to deploy a grid network because much of the complexity of the process (supplying applications and recording which nodes have which facilities, registration, and so on) can be handled by WSDM. When it comes to execution, MOWS will be most useful. You'll be able to use MOWS to manage the Web services required to support the grid environment. This will simplify the role of the grid manager, allowing it to enable and disable grid nodes directly. Again, this will simplify the deployment of grid solutions by reducing -- and in all probability, eliminating -- grid node code required to provide remote administration. Events within grid environments will offer a way for grid nodes to communicate their status to the grid management node.
WSDM in grid deployment

The main role of MUWS in grid development will be in the management of the Web services used to control the execution of grid tasks and in providing the interfaces required to describe the status and resource availability of the grid node during its lifetime. You can see a summary of this in Figure 5. Figure 5. Grid management with WSDM
developerWorks
For example, the following resources could be easily defined through a suitable schema for monitoring through WSDM: Current status (Up, Idle, Running, Busy, Overloaded) Processed Work Units Waiting Work Units Average Performance From a management perspective, you can use MUWS for: Starting and stopping the grid service remotely Configuring availability Configuring priorities Management of queues and work unit processing
Page 25 of 28
developerWorks
The benefit with WSDM is that because these capabilities and parameters are defined on the node, your grid should be self-managing. When you add a node to the grid, you update your node database with the reference to the node required to load its capabilities. The management software then parses the schema and WSDL and is automatically aware of the capabilities of the node. These are simply node-side parameters. You could also use WSDM to manage other components, such as a database and storage servers, and allow suitably endowed nodes to determine the capabilities and resources available when looking for or submitting data.
Section 8. Summary
This tutorial has looked at the WSDM standard and the fundamental elements required to understand how you can implement it. WSDM is basically a standard for defining the capabilities and properties of resources on a network and how you can manage them through Web services. The basics of the WSDM are simply a combination of WSDL and XSD schemas that define methods of communicating with, and defining information about, a specific resource. Once you understand how to create a sample WSDL file and the schemas required to define the capabilities, the remaining element is then to code the Web services that support the WSDL you have defined. This tutorial has also looked at the role of the manageability consumer, which parses the WSDL and WSDM schemas to determine how to manage the different resources, and at the role of WSDM within a grid environment, where WSDM can form part of the grid service and the management of that service. Finally, you've also seen the role of WSDM events, a mechanism for communicating information about the status, and status changes, for a resource. You should now have enough information to build your own WSDM definitions; the implementation of the Web services used to support a resource are of course specific to the resource in question, but they will generally be a wrapper around existing functionality built into the resource.
developerWorks
Resources
Get the following specifications: Web Services Distributed Management: Management Using Web Services (MUWS 1.0), Part 1 Web Services Distributed Management: Management using Web Services (MUWS 1.0) Part 2 Web Services Distributed Management: Management of Web Services (WSDM-MOWS) 1.0 Web Services Security: SOAP Message Security 1.0 Basic Profile Version 1.1 Web services Description Language (WSDL) 1.1 Web Service Resource Framework (includes WS-ResourceProperties, WS-ResourceLifetime, WS-BaseFaults, and WS-ServiceGroup) Web services Addressing Web Services Notification (includes WS-BaseNotification, WS-BrokeredNotification, and WS-Topics) Find more information by visiting the following technical committees: WSRF OASIS technical committee WSDM OASIS technical committee A little wisdom about WSDM provides an introduction to the WSDM standard (developerWorks, March 2005). The Globus Toolkit 4 Early Access: WSRF includes a WSRF implementation(developerWorks, October 2004). Using WS-Notification provides more information on WS-Notification, including how to create messages, support notifications and subscriptions, and manage the data (developerWorks, April 2005). Understanding WSRF, Part 1: Using WS-ResourceProperties is the first in a four-part series covering WSRF (developerWorks, March 2005).
Page 27 of 28
developerWorks
About the author

Mr. Martin Brown Martin Brown has been a professional writer for over seven years. He is the author of numerous books and articles across a range of topics. His expertise spans myriad development languages and platforms -- Perl, Python, Java, JavaScript, Basic, Pascal, Modula-2, C, C++, Rebol, Gawk, Shellscript, Windows, Solaris, Linux, BeOS, Mac OS/X and more -- as well as Web programming, systems management, and integration. Martin is a regular contributor to ServerWatch.com, LinuxToday.com, and IBM developerWorks, and is a regular blogger at Computerworld, The Apple Blog, and other sites, as well as a Subject Matter Expert (SME) for Microsoft. He can be contacted through his Web site at: http://www.mcslp.com.

Ws WSDM LTR PDF

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Ws WSDM LTR PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Understand Web Services Distributed Management (WSDM)

Section 1. Start here

What is this tutorial about?

Understand Web Services Distributed Management (WSDM) Page 2 of 28

Copyright IBM Corporation 1994, 2008. All rights reserved.

Section 2. Overview of WSDM

WSDM target audiences

Understand Web Services Distributed Management (WSDM) Page 4 of 28

Copyright IBM Corporation 1994, 2008. All rights reserved.

Now we'll take a closer look at the WSDM standard.

WSDM in your network

Understand Web Services Distributed Management (WSDM) Page 6 of 28

Copyright IBM Corporation 1994, 2008. All rights reserved.

WSDM and Service-Oriented Architecture (SOA)

Section 3. WSDM, WSDL, and other standards

Understand Web Services Distributed Management (WSDM) Page 8 of 28

Copyright IBM Corporation 1994, 2008. All rights reserved.

WSDM and WS-Addressing

Section 4. Management Using Web Services (WSDM-MUWS)

MUWS capability definitions

Understand Web Services Distributed Management (WSDM) Page 10 of 28

Copyright IBM Corporation 1994, 2008. All rights reserved.

Defining resource properties

Understand Web Services Distributed Management (WSDM) Page 12 of 28

Copyright IBM Corporation 1994, 2008. All rights reserved.

Obtaining resource properties

Copyright IBM Corporation 1994, 2008. All rights reserved.

Adding manageability capabilities

MUWS resource summary

Understand Web Services Distributed Management (WSDM) Page 16 of 28

Copyright IBM Corporation 1994, 2008. All rights reserved.

Determining what is available

Section 5. Management of Web services (WSDM-MOWS)

Copyright IBM Corporation 1994, 2008. All rights reserved.

Adding MOWS capabilities to the printer

<xs:element <xs:element <xs:element <xs:element

Section 6. WSDM events

Understand Web Services Distributed Management (WSDM) Page 20 of 28

Copyright IBM Corporation 1994, 2008. All rights reserved.

<muws-p1-xs:ResourceID>xs:anyURI</muws-p1-xs:ResourceId> <muws-p1-xs:ComponentAddress>[address]</muws-p1-xs:ComponentAddress> </muws-p1-xs:ReporterComponent> </muws-p1-xs:ManagementEvent>

Understand Web Services Distributed Management (WSDM) Page 22 of 28

Copyright IBM Corporation 1994, 2008. All rights reserved.

Section 7. WSDM in grid environments

WSDM in grid deployment

Understand Web Services Distributed Management (WSDM) Page 24 of 28

Copyright IBM Corporation 1994, 2008. All rights reserved.

Understand Web Services Distributed Management (WSDM) Page 26 of 28

Copyright IBM Corporation 1994, 2008. All rights reserved.

About the author

Understand Web Services Distributed Management (WSDM) Page 28 of 28

Copyright IBM Corporation 1994, 2008. All rights reserved.

Das könnte Ihnen auch gefallen