Skip to main content

skip to main content

developerWorks  >  Autonomic computing  >

Policy Management for Autonomic Computing: Using three coordinated tools to get managed resources PMAC-ready

developerWorks
Document options

Document options requiring JavaScript are not displayed


Rate this page

Help us improve this content


Level: Introductory

Eric Kirchstein (ekirchst@us.ibm.com), Software Engineer, IBM Software Group, Tivoli Foundation Technologies Design and Development

26 Apr 2005

Learn how the Policy Management for Autonomic Computing (PMAC) system works to create and enforce policies dictating the behaviors of managed resources. Uncover the target data desired from managed resources and see how three tools for gathering that data -- WSDL, WS-RP, and the Managed Resource Prototype -- interact.

Introduction

Managing complex IT resources today requires intelligent management policies. In this article, I detail the Policy Management for Autonomic Computing system, designed to provide policy language and mechanisms for creating and enforcing the policies that dictate the behaviors of managed resources.

In the Information Technology world, one of the greatest challenges for a large or growing company is the management of IT resources. Under a policy-driven system, the IT staff governs how these resources are managed by setting policies that dictate the behavior of these managed resources. The behavior of these resources might include a simple or complex series of events, the outcome of which can be directed through the use of a policy or policies.

PMAC, a tool that can be downloaded from alphaWorks (see Resources.) provides the policy language and mechanisms needed to create and enforce these policies for any given managed resource. A full definition of policy is outside the scope of this article; a more complete discussion can be found in the article, "An introduction to policy for autonomic computing" (see Resources.)



Back to top


Defining the managed resource

So what exactly is a managed resource? The most rudimentary definition is that a managed resource is

an entity that exists in the run-time environment of an IT system that can be managed.

Makes sense, right? This definition will be the one I use for this article.

Let's say there is a "manager" application that is responsible for managing the operation of a particular resource or resources. This manager application uses policies to decide what needs to be done, but these policies depend on data that is sent from each managed resource. So, the manager application needs to collect that data from the resource.

This data might include the following information:

  • Properties that define stateful information of the managed resource
  • Properties that can be changed on the managed resource
  • Operations that can be performed on the managed resource
  • The decisions to be made on this managed resource in regards to policy guidance

Before the manager application can collect the data, it must know what data is available. Unfortunately, data describing the resources is stored in various files.

This is where PMAC comes in. PMAC provides a mechanism that allows for the consolidation of the data, allowing for the creation of meaningful and relevant managed resource-specific policies to be validated and evaluated at run time.

The major theme of this article is to show you how to get managed resources PMAC-ready. First though, take a look at the resources that you have to chase down to gather the needed information -- the managed resource description documents. I'll demonstrate how these documents interact and how their information is correlated into a meaningful managed resource description.

You'll also want to understand how the resulting information is combined to create a managed element descriptor (MED) Java™ object, but that is beyond the scope of this article. Look for a future developerWorks tutorial on MED.



Back to top


Where the data lies

One of the thorniest problems in gathering data from a managed resource is that the data required to define policies might be scattered among disparate documents. PMAC solves this by using three standard XML documents to collect the information:

  • The Web Services Description Language (WSDL). An XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (known as services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate.
  • Web Services Resource Properties (WS-RP). Also known as WS-ResourceProperties, it is a specification for accessing stateful resources. It defines how the data associated with a stateful resource can be queried and changed using Web services technologies, allowing a standard means by which data associated with a WS-Resource can be accessed by clients. It also defines a standard set of message exchanges that lets a requestor query or update the property values of the WS-Resource. The set of properties defined in the resource projection associated with the service interface defines the constraints on the valid contents of these message exchanges.
  • Managed Resource Prototype (MRP). It provides additional information about managed resource properties that will be made available along with the appropriate WS-RP documents, including restrictions on managed resource property values; indications of whether a resource property can be modified; and values that some of those properties might take in real instances.

Figure 1 shows the relationship of the WSDL, WS-RP, and MRP. In the diagram, the WS-RP document would be contained within the WSDL document's type section.


Figure 1. The working relationship of WSDL, WS-FP, and MRP
The working relationship of WSDL, WS-FP, and MRP

PMAC defines a scope as the "definition of the subject of the policy." In this interaction example, the MRP_a documents on the left should be identical and combined to form MRP_Scope1 on the right. The WSDL_1 and WSDL_2 artifacts will be combined to create the WSDL_Scope1 artifact on the right.

In addition, the following attributes of this interaction are worth noting:

  • The WSDL can have portTypes not referred to by the MRP.
  • There is a one-to-one relationship between MRP and scope; therefore, the same scope must have the same MRP.

Now I'll provide more in-depth information on each of these components.

The Web Services Description Language

PMAC uses the WSDL document to gather the allowable sensor and effector operations.

With an autonomic manager, the sensor operation monitors the environment. The autonomic manager analyzes what is found and then plans and executes any actions. Actions are taken through effector operations. Sensors look at the current state of the managed resources; effectors have the ability to change the current state.

The WSDL might also contain the WS-RP instance within the wsdl:types section of the WSDL, although this could be created as a separate document.

Listing 1 is an XML snippet of a skeleton WSDL file. (A more detailed example will be provided later in this article, but this is a good template to create your own version. Note that I included many namespace definitions in the root node of this document; these might not all be used, but are left in for completeness.)


Listing 1. A bare bones example of a WSDL file

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions name="myWSDLname"
          targetNamespace="http://www.ibm.com/namespaces/myWSDLns"
          xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
          xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  	    xmlns:mypre="http://autonomic.ibm.com/myns"
  	    xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
  	    xmlns:basefault="http://basefaults.wsrf.ibm.com"
  	    xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
  	    xmlns:format="http://schemas.xmlsoap.org/wsdl/formatbinding/"
          xmlns:java="http://schemas.xmlsoap.org/wsdl/java/"
          xmlns:wsrp="http://www.ibm.com/xmlns/stdwip/web-services/WS-ResourceProperties" 
  	    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 
 <wsdl:types>
  <!--This is where the WS-RP definition goes. More detail available in WS-RP  
     section below-->
  <schema 
      targetNamespace="http://autonomic.ibm.com/myns"       
      xmlns="http://www.w3.org/2001/XMLSchema">
   
     <!--One example of a generic resource property definition -->
     <element name="MyResourceProperty" type="xsd:int" />
   
     <!--Example of a GlobalElementDescriptor (GED) containing the above 
        resource property-->
     <element name="MyGED">
        <complexType>
           <sequence>
              <element ref="mypre:MyResourceProperty"/>
           </sequence>
        </complexType>
     </element>
   </schema>
 </wsdl:types>

   <wsdl:message name="getResourcePropertyRequest">
      <wsdl:part name="qname" type="xsd:string"/>
   </wsdl:message>

   <wsdl:message name="getResourcePropertyResponse">
      <wsdl:part name="getResourcePropertyReturn" type="xsd:anyType"/>
   </wsdl:message>

   <wsdl:message name="getSomethingRequest">
      <wsdl:part name="getSomethingArg" element="getSomething" />
   </wsdl:message>
   
   <wsdl:message name="getSomethingResponse ">
      <wsdl:part name="getSomethingReturn" type="xsd:int" />
   </wsdl:message>
   
   <wsdl:portType name="testUAPortType" 
                  wsrp:ResourceProperties="uasppol:MyGED">
      
      <!-- Sample operation -->      
      <wsdl:operation name="getSomething">
         <wsdl:input message="uasp:getSomethingRequest" 
                     name="getSomethingRequest" />
         <wsdl:output message="uasp:getSomethingResponse" 
                      name="getSomethingResponse" />
      </wsdl:operation>
      
      <!-- Mandatory operation -->
      <wsdl:operation name="GetResourceProperty" parameterOrder="qname">
         <wsdl:input message="uasp:getResourcePropertyRequest" 
                     name="getResourcePropertyRequest"/>
         <wsdl:output message="uasp:getResourcePropertyResponse" 
                      name="getResourcePropertyResponse"/>
         <wsdl:fault message="uasp:JavaMRException" name="JavaMRException"/>
      </wsdl:operation>
      
   </wsdl:portType>

</wsdl:definitions>

Web Services Resource Properties

In PMAC, the exposed state of each managed resource is represented through an instance of a WS-RP document whose schema is defined in the WSDL for the Web service. In the PMAC world, the WSDL document defines sensor and effector operations. This WSDL document points to a Resource Properties document that specifies the resource properties to be used in operations defined by the WS-RP specification.

While predefined operations (such as Get, Set, Query) are available, the WSDL file can also include operations that go beyond these standard resource properties operations. The WS-RP document can be implemented as a stand-alone document or embedded within the WSDL for the managed resource.

The XML snippet in Listing 2 shows the XML schema that defines the XML types and elements used in the WS-RP specification.


Listing 2. Schema defining XML types and elements in WS-RP

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema 
  xmlns:xs="http://www.w3.org/2001/XMLSchema" 
  xmlns:wsrp=
 "http://www.ibm.com/xmlns/stdwip/web-services/ws-resourceProperties"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  elementFormDefault="qualified" attributeFormDefault="unqualified" 
  targetNamespace=
 "http://www.ibm.com/xmlns/stdwip/web-services/ws-resourceProperties" >

  <!-- defines the Global Attribute Declaration to be included on the
       WSDL 1.1 portType 
  -->
  <xs:attribute name="resourceProperties" type="xs:QName" />

  <!-- this type should be used to contain any XPath 1.0 expression 
       that conforms to the XPath 1.0 grammar 
  -->
  <xs:simpleType name="XPathExpression">
    <xs:restriction base="xs:string" />
  </xs:simpleType>

  <!-- this type should be used to contain only node-set type XPath 1.0 
       expressions that conform to the locationPath production of the 
       XPath 1.0 grammar 
  -->
  <xs:simpleType name="locationPath">
    <xs:restriction base="xs:string" />
  </xs:simpleType>
  
  <!-- Defines the standard Notification Message related to 
       ResourceProperties value change 
  -->
  <xs:complexType name="ResourceChangeNotificationType">
    <xs:sequence>
      <xs:element name="oldValue" minOccurs="1" maxOccurs="1" 
                  xsi:nillable="true">
        <xs:complexType>
          <xs:sequence>
            <xs:any minOccurs="0" maxOccurs="1" />
          </xs:sequence>
        </xs:complexType>
      </xs:element>
      <xs:element name="newValue" minOccurs="1" maxOccurs="1" 
                  xsi:nillable="true">
        <xs:complexType>
          <xs:sequence>
            <xs:any minOccurs="1" maxOccurs="1" />
          </xs:sequence>
        </xs:complexType>
      </xs:element>      
    </xs:sequence>
    <xs:attribute name="location" type="wsrp:locationPath" 
                  use="optional" />
  </xs:complexType>
  
  <xs:element name="ResourceChangeNotification" 
              type="wsrp:ResourceChangeNotificationType" />

</xs:schema>

The Managed Resource Prototype

The MRP document defines additional information about managed resource properties that are made available along with the appropriate Resource Properties documents. Examples of the additional information included in the MRP are:

  • Restrictions on managed resource property values
  • Indications of whether a resource property can be modified
  • Values that some of those properties might take in real instances

The MRP can define managed resource properties as read-only or read-write. For PMAC, read-only properties are considered managed resource sensors, while read-write properties are considered valid sensors and effectors.

The MRP is shared by all instances of the managed resource type it describes. But beware, the MRP documents for two different scopes should not be identical, and PMAC provides you with no enforcement mechanism.

Essentially, the MRP describes how managed resources of a particular type appear and behave when they are created. The MRP is tied to a specific scope in a one-to-one relationship. For more detailed information on the MRP specification, see the ACAB.BO0312 document in Resources.

Listing 3 provides an overview of the structure of an MRP document. Note that the content of an MRP document is extensible and allows additional attributes and content in all places.


Listing 3. Overview of MRP structure

<managedResourcePrototype portType="QName" wsdlLocation="URL"?>
    <property 
  	  path="propertyPath"
        mutability="constant|appendable|mutable" ?
        modifiability="read-only|read-write" ?
        usage="list of NCnames" ?
        units="unit of measurement"
        {anyAttribute} > 

        <validValue extensible="true|false"?>
           {any}*
        </validValue>*

        <initialValue>
           {any}*
        </initialValue>?

        <defaultValue>
           {any}*
        </defaultValue>?

        {any}*

    </property>

    <operation
        operationName="NCName"
        portType="QName"
        {anyAttribute} *> *
        {any} *
    </operation>

    <event ...> *
        ...
    </event>

    {any}*

</managedResourcePrototype>

Following are the major elements and attributes of the MRP as they pertain to PMAC:

  • property: The property element of the MRP allows attributes and values to be associated with not only elements within the WS-RP document, such as the specification details, but also with the further refinement in the PMAC-specific <callout> element. Following are descriptions of each of this element's attributes:
    • path: Refers to a specific managed resource property within a corresponding WS-RP document. While the MRP specification describes this as an XPath statement, PMAC uses internal constructs to associate it with the WS-RP element.
    • mutability: Currently not used by PMAC.
    • modifiability: Indicates whether this property can be used within a policy as a sensor, an effector, or either. Valid values include read-only (default) and read-write.
    • units: Currently not used by PMAC.
    • usage: Currently not used by PMAC.
    • {anyAttribute}: Currently not used by PMAC.
  • validValue: Can be used as a list of valid values for a managed resource property.
    • extensible: Indicates whether this is the complete set of valid values or if the user can add additional ones. The default is to allow additional.
  • initialValue: Currently not used by PMAC.
  • defaultValue: Currently not used by PMAC.
  • {any}: This element allows PMAC (and any other component for that matter) the freedom to define its own policy-specific structure. To aid in the grouping of decision-specific properties, PMAC uses this freedom to define a <callout> element (described in the next section).
  • operation: Makes reference to all operations supported by managed resources within this scope:
    • operationName: The name of the operation defined within the portType of the associated WSDL.
    • portType: The name of the portType in the WSDL within which the operation is defined.
    • {anyAttribute}: Currently not used by PMAC.
    • {any}: Currently not used by PAMC.


Back to top


Making the managed resource documents work together

The MRP document contains a child element callout that provides additional information about the operations to which the managed resource can call. Callouts are operations that allow the managed resource to call on other service interfaces. For PMAC, the callout is used to specify the callout for decision guidance in results- and configuration-based policies; in PMAC, this callout must be named RequestDecisionRequest.

Underneath callout is a calloutDecision element that is used to define the decision name and, optionally, its associated inputs and outputs. The name attribute on this element is the declaration of the decision name.

Listing 4 illustrates the relationships between the calloutDecision and messages in the MRP.


Listing 4. The relationship between calloutDecision and messages in MRP

<callout operationName=="RequestDecisionRequest" portType="AutonomicManagerRemote">
    <!--This represents a property that is defined in the WS-RP-->
    <message name="input1">
          <part name="rpname1" />
          <!--This represents a property variable not defined in the WS-RP-->
          <part name="varname1" type="xsd:string"/>
    </message>
    <message name="input2">
          <part name="rpname2" />
    </message>
    <message name="output1">
          <part name="varname2" />
          <part name="varname3" />
    </message>
    <message name="output2">
          <part name="varname4" />
    </message>
    ...
    <calloutDecision name="decisionname1">
          <!-- The "message" attributes in the following input and output elements work 
               as references to the "name" attributes in the like-named 
               "message" child elements 
               under the "callout" element above -->
          <input message="input1" /> 
          <output message="output1" />
    </calloutDecision>
    <calloutDecision name="decisionname2">
          <input message="input2" />
          <output message="output2" />
    </calloutDecision>
</callout>
...

Callout decisions that reference messages that reference resource variables that are not defined in the WSDL can only apply to result-based policies. Callout decisions that reference messages that only reference resource properties in a WSDL/WS-RP can apply to both result and configuration-based policies.

Operations

WSDL operations are distinguished by the combination of input and output elements. The order of these elements defines the message-exchange pattern.

This document attempts to define these operations in context of a policy. This information is gathered using the MRP operation element attributes portType and operationName. The portType attribute references the WSDL portType child element's name attribute. After that relationship is determined, the operation information is determined using the name attribute on the operation child element of portType. Figure 2 illustrates this relationship.


Figure 2. Discovering the message-exchange pattern relationship
Discovering the message-exchange pattern relationship

Inputs and outputs

Message elements for the operations are included within a WSDL document. These message elements define abstract messages that are used as the input or output of an operation. The input element's message attribute, located within the portType/operation element mentioned in the previous section, correlates with this message name attribute.

Each message element has a part child element with a name and an element attribute. The name attribute refers to a resource property document element in the WS-RP. This resource property document must be the same document as referred to by the wsrp:resourceProperties attribute of the portType element. If there is not an element attribute on the part child, there must be a type element that refers to a recognizable XML schema type.

Listing 5 illustrates the relationships in the WSDL document.


Listing 5. Relationships in the WSDL document


<wsdl:types>
      <xsd:schema targetNamespace=... >
            <xsd:element name="ExampleRscProp" type="xsd:string" />
   
            <xsd:element name="MyResourceProperty">
                  <xsd:complexType>
                        <xsd:sequence>
                              <xsd:element ref="ExampleRscProp" />
                        <xsd:sequence>
                  </xsd:complexType>
            </xsd:element>
      </xsd:schema>

<!-- ========== Message Types for GetResourceProperty  ============ -->
<xsd:element name="GetResourcePropertyRequest" type="xsd:QName" />

<xsd:element name="GetResourcePropertyResponse">
            <xsd:complexType>
			<xsd:sequence>
				<xsd:any maxOccurs="unbounded" minOccurs="0" />
			</xsd:sequence>
		</xsd:complexType>
      </xsd:element>
</wsdl:types>

<portType name="portType1" wsrp:resourceProperties="MyResourceProperty">
      <operation name="GetResourceProperty">
         <!--The message attribute "GetResourcePropertyRequest" is used as a 
                reference to the message with the name attribute value 
                "GetResourcePropertyRequest" below-->
                
         <input name="GetResourcePropertyRequest"
                message="impl:GetResourcePropertyRequest"/>
         <output name="GetResourcePropertyResponse"
                 message="impl:GetResourcePropertyResponse" />
      </operation>
</portType>
    
<wsdl:message name="GetResourcePropertyRequest">
      <!--Referred to by the "GetResourcePropertyRequest" input above-->
      <wsdl:part name="GetResourcePropertyRequest"
                    element="wsrp:GetResourcePropertyRequest" />
</wsdl:message>

<wsdl:message name="GetResourcePropertyResponse">
	<wsdl:part name="GetResourcePropertyResponse"
                 element="wsrp:GetResourcePropertyResponse" />
</wsdl:message>

In Listing 5, the special WS-RP operation of GetResourcePropertyRequest is referenced. Normally, the input and output elements point to explicit parameters to the request. In the GetResourcePropertyRequest the input element points back to a generic entry. The subtlety here is that the list of properties are referenced by the wsrp:resourceProperties attribute of the portType element. Only those properties can be retrieved.

The same rule applies to the SetResourcePropertiesRequest. These relationships are applicable to both input and output messages.

Types

In PMAC, the resource property types are indicated in the WS-RP document. Before delving into the specific PMAC usage of the WS-RP, I should further explain the structure and semantics of the WS-RP document.

The WS-RP document provides the declaration of exposed resource properties associated with a class of managed resources. The WSDL document defines the resource property document it is associated with by declaring a Global XML Element Declaration as an attribute of the portType interface. For example:

<wsdl:portType name="portType1" wsrp:resourceProperties="DB2" >

This Global Element Declaration requires the service to provide the interface to resource properties using a document whose root element is the Global Element Declaration associated with the portType.

Just a bit more about the WS-RP

The WS-RP declaration can either be internal or external in relation to the WSDL document. An internal WS-RP is an XML schema included in the types element in the WSDL document.

As previously explained, the portType must include a resourceProperties attribute that refers to the resource properties described in the WS-RP. Listing 6 is an example of this relationship.


Listing 6. The relationship between the WS-RP declaration and WSDL

<wsdl:types>
      <xsd:targetNamespace=... >

      <!--These are examples of resource property declarations-->
      <xsd:element name="propinttype" type="xsd:integer" />
      <xsd:element name="propstringtype" type="xsd:string" />

      <!--This element is the declaration of the resource properties 
         document that is referenced by the 'wsrp:resourceProperties'
         attribute in the wsdl:portType element below (theInterfaceName)-->
      <xsd:element name="sampleRscProps">
            <xsd:complexType>
                  <xsd:sequence>
                        <xsd:element ref="propinttype" />
                        <xsd:element ref="propstringtype" />
                  </xsd:sequence>
            </xsd:complexType>
      </xsd:element>
</wsdl:types>

<!-- The wsrp:resourceProperties attribute points to the GED above (sampleRscProps) -->
<wsdl:portType name="theInterfaceName" wsrp:resourceProperties="sampleRscProps">
     
</wsdl:portType>



Back to top


Getting the big picture

Figure 3 represents the association between the Web Services Description Language, Web Services Resource Properties, and Managed Resource Prototype documents. Essentially it is a diagram of all the previous explanations in this section, although with much less granular-level detail.


Figure 3. A view of how WSDL, WS-FP, and MRP work together
A view of how WSDL, WS-FP, and MRP work together


Back to top


Conclusion

In this article, you've gained an understanding of how the Policy Management for Autonomic Computing system works to provide the policy language and mechanisms needed to create and enforce policies that dictate the behavior of these managed resources. I've defined the managed resource and outlined the data you need to be able to access from each managed resource in order to use PMAC. This data includes stateful properties definitions, which properties are changeable, which operations can be performed, and which decisions can be made based on policy guidelines.

You've been given a detailed definition of the Web Services Description Language, Web Services Resource Properties, and Managed Resource Prototype documents, the three tools the article uses to collect that data. And I've provided you a context to demonstrate how the three work together.

The resources in this article should get you started in creating an autonomic system capable of more efficient IT resource management.



Resources



About the author

Author photo

Eric Kirchstein is a Software Engineer for IBM working with autonomic computing technologies, where he specializes in XML programming technology and methodology. Before working with autonomic computing technologies, Eric worked on Tivoli Service Level Advisor as a Java programmer and DB2 focal point. He has a B.S. degree in Computer Science from North Carolina State University, is an IBM Certified Specialist in DB2 UDB V6.1/V7.1, and a Level 1 plateau inventor.




Rate this page


Please take a moment to complete this form to help us better serve you.



 


 


Not
useful		Extremely
useful
 


Share this....

digg Digg this story del.icio.us del.icio.us Slashdot Slashdot it!



Back to top