WebSphere Extended Deployment, Version 6.0.x
             Operating Systems: AIX, HP-UX, Linux, Solaris, Windows, z/OS


Defining a service policy

A service policy is used to categorize and prioritize work requests. A service policy is a user-defined business goal, and correlates to transaction and work class components. The service policy creates the goal, while the work classes connect specified information such as URIs (Uniform Resource Identifiers) to that goal. IIOP type work classes use Enterprise JavaBeans (EJB) and EJB method names to map to the goal. Java Message Service (JMS) type work classes use bus and destination names to map to the goal.

Before you begin

Procedure

  1. From the administrative console click Operational policies > Service Policy. You can select an existing service policy to edit, or click New to create a service policy. To edit an existing service policy, click the service policy name.
  2. Create a name, description, and a goal type for your new service policy.
    1. Provide a name for the service policy. The name must be unique among all the service policies and must conform to certain naming criteria. The naming criteria is outlined in the help panel for the service policy console.
    2. Optional: Provide a description of the service policy.
    3. Select a goal type. The goal type can be either discretionary, average response time, percentile response time, or queue wait time:
      • Discretionary goals indicate work that does not have significant value. As a result, work of this type can see a degradation in performance when resources are constrained.
      • Average response time goals are indicative of work with a higher priority than discretionary. The average response time goal is assigned a specific time goal on the following panels.
      • Percentile response time goals are another measure for work with a higher priority than discretionary. The percentile response goals are defined with specific criteria on the following panel. The percentile response time target is the percentage of requests whose response time is T or less that should be P or more; a target has particular values for T and P.
      • Queue time goals are available for long-running applications. When the goal reaches this limit, more servers are needed. Type the maximum. wait time acceptable for this service policy and the units for it, for example, seconds, minutes or hours.
  3. Optional: If you select a goal type of average response time, percentile response time or queue time, you are prompted to define the specifics and select an importance. For average response time goals, define these fields:
    1. Type a goal value for the new service policy. Type the maximum allowable time for the service policy. WebSphere® Extended Deployment tries to stay below the goals that are defined. If the requests exceed the value or nearly surpass the goal, Extended Deployment acts when the environment is in automatic or supervised modes.
    2. Associate an importance with the service policy. The options for importance vary from lowest to highest. Some planning is essential to select the right importance value, because negative results can occur if all work is rated as highest. This rating can create a bottleneck within the environment.
    3. [Version 6.0.1 and later] Select Monitor for persistent policy violations to set up the creation of a runtime task when a policy violation occurs. To define a policy violation, specify the following values:
      1. In the Goal delta value field, type an integer to indicate the maximum allowable amount of time that exceeds the configured goal value. Acceptable values are 0 to 3000 milliseconds, 0 to 300 seconds, and 0 to 2147483647 minutes.
      2. In the Time period value field, type an integer to indicate the milliseconds, seconds or minutes after which the goal value is in violation. This can be 0 to 1 day, inclusive.
    For percentile response time, define these fields:
    1. Set the goal percentile. Set this value to the percentage of requests that must meet the goal value that is defined in the next field.
    2. Type a goal value for the new service policy. Type the maximum allowable time for the service policy. WebSphere Extended Deployment continually adjusts to get the most balanced result. For example, if the requests exceed the value or nearly surpasses the goal, WebSphere Extended Deployment acts when the environment is in automatic or supervised modes.
    3. Associate an importance with the service policy. The options for importance vary from lowest to highest. Some planning is essential to select the right importance value, because negative results can occur if all work is rated as highest.
    4. [Version 6.0.1 and later] Select Monitor for persistent policy violations to set up the creation of a runtime task when a policy violation occurs. Do the following to define a policy violation:
      1. In the Goal delta percentage field, type an integer that indicates the percentage of requests below the goal value for which to monitor. This can be 0 to 100, inclusive.
      2. In the Time period value field, type an integer that indicates the milliseconds, seconds or minutes after which the goal value is in violation.
    For queue time, define these fields:
    1. Type a goal value for the new service policy. Type the maximum allowable time for the service policy. WebSphere Extended Deployment tries to stay below the goals that are defined. If the requests exceed the value or nearly surpass the goal, Extended Deployment acts when the environment is in automatic or supervised modes.
    2. Associate an importance with the service policy. The options for importance vary from lowest to highest. Some planning is essential to select the right importance value, because negative results can occur if all work is rated as highest. This rating can create a bottleneck within the environment.
    Click Next when you complete this panel.
  4. Associate transaction class members to the service policy or create a new transaction class. If the transaction class that you are seeking does not exist, follow these steps to create a new transaction class.
    1. Click New.
    2. Provide a name for the transaction class. The name must be unique among all transaction classes and conform to the naming criteria that is outlined in the help panel for the administrative console.
    3. Optional: Provide a description of the transaction class.
    Click Next when you complete the transaction class membership panels. Your new transaction class is displayed as a member of your new service class.
  5. To create a work class for your service policy, from the administrative console click Applications > Enterprise Applications > application_name > Service Policies. Select an existing service policy and for the request type, click New.
  6. From the Service Policies tab, expand the work request type that you want to create and click New. To create the new service policy, complete the following steps:
    For HTTP:
    1. In the Name field type a name for the work class and click Next. For example, to create a work class that trades stock, name it StockTradeWork. Click Next.
    2. From the Module list, select a module.
    3. From the Available list, select the members to add and click Add.
    4. In the Custom URI Pattern field, if you need to use a custom URI, type its name and click Add Pattern. For example, a custom URI is necessary to do JavaServer Pages (JSP) work.
    5. After completing this page, click Next.
    6. Confirm that the changes are accurate by clicking Finish. To revise your choices, click Previous.
    For SOAP:
    1. In the Name field type a name for the work class and click Next. For example, to create a work class that trades stock, name it StockTradeWork. Click Next.
    2. From the Module list, select a module.
    3. From the Available list, select the Web service operations to add and click Add.
    4. After completing this page, click Next.
    5. Confirm that the changes are accurate by clicking Finish. To revise your choices, click Previous.
    For IIOP:
    1. In the Name field type a name for the work class and click Next. For example, to create a work class that trades stock, name it StockTradeWork. Click Next.
    2. From the Module list, select a module.
    3. From the Available list, select the EJB methods to add and click Add.
    4. In the Custom EJB name and Custom EJB method fields, if you need to use a custom EJB, type the information and click Add Pattern.
    5. After completing this page, click Next.
    6. Confirm that the changes are accurate by clicking Finish. To revise your choices, click Previous.
    For JMS:
    1. In the Name field type a name for the work class and click Next. For example, to create a work class that trades stock, name it StockTradeWork. Click Next.
    2. From the Module list, select a module.
    3. From the Bus list, select a defined bus. You can also select the Filter by bus checkbox to filter by the selected bus.
    4. From the Available list, select the EJB methods to add and click Add.
    5. In the Custom bus name and Custom bus destination fields, if you need to use a custom bus, type the information and click Add Pattern.
    6. After completing this page, click Next.
    7. Confirm that the changes are accurate by clicking Finish. To revise your choices, click Previous.
  7. Optional: If you want to create a rule for your work class, you have two options. If you are familiar with the rule builder, select Quick edit to quickly set up a new rule. Alternatively, from the Service policies tab, expand the work request type and the work class for which you want to create a rule, and click Add Rule > Rule Builder and take the following actions:
    1. Click Add. From the next panel, select the type of rule, such as Group ID. Click OK. This displays the rule builder panel. Continue to build a rule, specify the transaction class, or click OK.
    2. Click the new rule to set its operators. A predefined set of operators displays for the type of rule condition that is selected.
    3. Select the operator that you want to use and enter the appropriate information in the provided field. For example, you can classify incoming requests for the StockTradeWork work class by a group ID to use a different transaction class. Select the (=) operator and type HTTP in the provided field, to provide a different transaction class for HTTP requests.
    4. Click OK, and click OK again.
    5. Click Apply or OK to commit your new rule settings.
  8. Optional: If you want to define HTTP or SOAP routing policies for your application and editions, from the Routing policies tab, expand the work request type that you want to work with.
    Option Description
    You can classify the rule to an existing transaction class.
    1. Selecting one of the following options:
      • Permit routing to: From the Select edition name here list select the edition name.
      • Reject routing with return code: From the Select edition name here list select the edition name and in the Enter in return code field, type the return code.
      • Redirect routing to: From the Select edition name here list select the edition name and in the Enter URI to redirect to field, type the URI.
      • Permit routing with affinity to: From the Select edition name here list select the edition name.
    2. Click Apply.
    Alternatively, you can apply new classification rules by clicking Add Rule and taking the following actions:
    • If you know your rule name, perform the following steps:
      1. Select the Select box and in the If field, type your new routing rule name.
      2. From the Then list, select one of the following options:
        • Permit routing to: From the Select edition name here list select the edition name.
        • Reject routing with return code: From the Select edition name here list select the edition name and in the Enter in return code field, type the return code.
        • Redirect routing to: From the Select edition name here list select the edition name and in the Enter URI to redirect to field, type the URI.
        • Permit routing with affinity to: From the Select edition name here list select the edition name.
      3. Click Apply or OK.
    • Build a new rule by taking the following actions:
      1. Click Rule builder to build the rule.
      2. From the rule Condition list, select the type of rule that you want to create, for example, protocol and click Add. The new rule displays in the Available list.
      3. Click the new rule to set its operators. A predefined set of operators displays for the type of rule condition selected.
      4. Select the operator that you want to use and enter the appropriate information in the field provided.
      5. Click OK and click OK again.
      6. Click Apply or OK to commit your new rule settings.

Results

You have defined a business goal and applied that goal to application URIs using the service policy and routing rules. Your WebSphere Extended Deployment system can now categorize and prioritize work.



Related reference
Routing and service policies work classes
Administrative roles and privileges
Task topic    

Terms of Use | Feedback

Last updated: Nov 30, 2007 3:58:31 PM EST
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=/com.ibm.websphere.xd.doc/info/odoe_task/todrpolicy.html