Plain Agent Use Case Example

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Define the Service Under Management

The next task in this use case example is to define the service to be managed and to create and assign deployment and runtime policies that ensure the application deploys and performs as required.

A service is a grouping of processes and a process type is a sub-group of processes within a service. (A process type is referred to as a process group in the WLOC Administration Console.) The purpose of a service is to group a collection of processes that work together. The purpose of the process group is to define instances within the service that perform the same function and can be treated as equivalent when an action is taken.

For example, you might have a two tier application with a Web app in one tier and business logic in the other. If the instances of each tier are homogeneous, then each tier could be organized as a process group and the two process groups together could comprise a service.

The distinction between these two groupings becomes important when defining policies. Generally speaking, policies related to deployment are applied across the whole service, whereas runtime policies are applied to a specific process group. Furthermore, process type actions, by default, will generally pick one member of the group to act on. For example, if an action is to stop an instance, the instance that gets stopped is typically not specified and the instance is chosen by the controller.

You configure services using the WLOC Administration Console, on the Inventory > Services page. A service’s configuration is persisted in an XML file named metadata-config.xml. By default, this service metadata configuration file is located in the BEA_HOME/user_projects/controller/config directory. It is possible to configure a service by modifying this service metadata configuration file. However, if you configure a service by modifying its metadata configuration file, you do not receive the benefits of validation and error checking that you get when configuring a service using the Administration Console.

Figure 4-1 illustrates an example of a SOA application that consists of multiple client applications calling into a back-end Web Service using a software load balancer. The back-end Web Service can be hosted on WLS Managed Servers.

Figure 4-1 Sample SOA Application Managed by WLOC

Sample SOA Application Managed by WLOC

In this use case example, we will do the following:

Figure 4-2 illustrates the topology in this example. Note that we are using a Windows environment in this example, but other platforms are also supported. For a list of supported platforms, see BEA WebLogic Operations Control Supported Configurations.

Figure 4-2 Use Case Example Topology

Use Case Example Topology

The tasks in this topic include:

 

Step 1: Create the Service and Process Groups

The first step in defining the service metadata is to define the general properties for the service, and then define the process groups that it will contain.

Our service will have two process groups, one that consists of a WLS Administration Server instance and one that consists of two Managed Server instances. In the WLS domain, these instances are named AdminServer, MS_1, and MS_2. You need to ensure that your WebLogic domain is configured correctly and that the servers can start successfully.

Note: Process groups are referred to as process types in the service metadata XML file.

To define the service and process groups:

  1. Click the Inventory tab in the WLOC navigation bar and click Services in the tree.

    2. Because we have not defined any services yet, there are no services listed in the table.


    Use Case Example Topology

    Note: You can resize the portlets by dragging the portlet resizing icon in the lower right corner of the Inventory pane.
  2. Click New to display the Service Properties page.
  3. Enter the values shown in the following table for the general service properties.

    4. Table 4-1 General Service Properties 
    In this field . . .
    Specify the following information . . .
    Name
    CreditCheckService
    Description:
    Credit Check Service
    Retry Count:
    10 (the default)
    Priority:
    0 (the default)
    Placement Algorithm:
    Prefer resource pools with the most resources


    Use Case Example Topology

  4. Click Next.

    5. The Process Properties page is displayed. We use this page as the starting point to add the process groups in the service.

Define the Administration Server Process Group

The following steps describe how to specify the properties and define a ready metric for the Administration Server process group.

  1. In the Process Properties page, click Add Process Group to add the first process group for this service.


    2. Use Case Example Topology

  2. Select Start from Scratch from the Process Requirements drop down menu and click Next.


    3. Use Case Example Topology

    By selecting the Start from Scratch option, we are prompted on subsequent pages to supply properties for the process group, JVM parameters that are used when adding instances to the process group, and ready metrics that specify when an instance is available as a resource.

  3. In the Process Properties page, we will first define the AdminServer process group. Enter the following values for the Process Group Properties:
    • Process Group: AdminServer
    • Number of processes: 1


      • Use Case Example Topology

  4. In the Process Group Template Properties portion of the window, enter the values shown in Table 4-2 for the AdminServer process group instance.

    5. Table 4-2 AdminServer Process Group Template Properties 
    In this field . . .
    Specify the following information . . .
    Name
    AdminServer
    Description
    AdminServer JVM
    Main Class
    Leave this option selected. Because our service is deployed on WLS, we need to invoke the weblogic.Server main class.
    Main JAR
    Leave this option unselected.
    Host:
    The name of the host machine.
    In this example, we specify localhost.
    The host and port number are used to determine the address the Agent uses to collect JMX metric information from the endpoint.
    Starting Port#
    7001
    JMX Service URL
    In this example, we leave this field blank because we are using a WLS endpoint and we specified values in the Host and Starting Port# fields. If you are using a non-WLS endpoint, you can specify a JMX Service URL in this field as an alternative to providing values in the Host and Starting Port# fields.
    Classpath
    The CLASSPATH for the domain.
    JVM Arguments
    The JVM arguments to be used when the process starts. In this example, we enter the arguments that are appended to the weblogic.Server start command to specify minimum and maximum heap sizes, and to set the WebLogic Server instance name, security credentials, security policy, home and domain directories:
    -Xmx128m -Xms64m -da
    -Dwls.home=C:\wls_92\weblogic92\server
    -Dweblogic.management.discover=true
    -Dweblogic.Name=AdminServer
    -Dweblogic.management.username=weblogic
    -Dweblogic.management.password=weblogic
    -Djava.security.policy=C:\wls_92\weblogic92\server\lib\weblogic.policy
    -Dweblogic.RootDirectory=C:\wls_92\user_projects\domains\LOC_base_domain

    Note: All JVM arguments must be specified on one line, separated by spaces.
    Java Arguments
    In this example, no Java arguments are required.
    UserName
    The username required for authenticating JMX connections.
    In this example, we specify weblogic as both the user name and the password because those are the values required to authenticate to the Administration Server.
    Password
    The password required for authenticating JMX connections.
    Enter weblogic.
    Instance Directory
    Leave this field blank.
    Native Lib Directory
    Leave this field blank.
    Use Native JMX
    Leave this unchecked.
    SSH Enabled
    Leave this unchecked.
    Protocol
    Leave iiop selected.
    Max Copies
    Accept the default, 1. This field is used in conjunction with JVM variables to create multiple copies of a process without having to physically configure duplicates in the metadata configuration. We are not using JVM variables in this use case so we do not need to specify a different value in this field.


    Use Case Example Topology


    Use Case Example Topology

  5. Specify a ready metric for the AdminServer instance by entering the values shown in Table 4-3.

    6. A ready metric indicates when a process has been started and is ready for work. For a WebLogic Server instance, the ServerRuntime MBean has a State attribute. When ServerRuntimeMbean.State=RUNNING, the WebLogic Server instance is ready.

    Table 4-3 AdminServer Ready Metrics 
    In this field . . .
    Specify the following information . . .
    Instance Name
    com.bea:Name=AdminServer,Type=ServerRuntime
    Attribute
    State
    Value
    RUNNING
    Operator
    Value Equals (the default)
    Value Type
    String
    Wait
    300000 (This value ensures the WLS Admin Server instance has time to complete its startup.)


    Use Case Example Topology

  6. Click Next.

    7. Note that the AdminServer process group is listed in the Process Group table.


    Use Case Example Topology

    In the next steps we will define the Managed Server process group.

Define the Managed Servers Process Group

The following steps describe how to specify the properties and ready metrics for both Managed Server instances.

  1. In the Process Properties page, click Add Process Group to add the Managed Server process group.
  2. Select Start from Scratch from the Process Requirements drop down menu and click Next.
  3. In the Start from Scratch page, we will first define the Managed Servers process group.
    1. Name the process group ManagedServers
    2. Because we have two Managed Servers in this group, enter 2 in the Number of Processes field.
  4. Define the Managed Server processes by entering the values shown in Table 4-4 for the Process Group Template properties.

    5. Note that the values that are populated in the template are obtained from the values we provided for the AdminServer process group. We modify them as appropriate for the ManagedServers group.

    The values that we specify on this page are duplicated for all the instances in the group. Therefore, in this example, both of the Managed Server instances will initially contain the same values.

    Table 4-4 ManagedServers Process Group Template Properties 
    In this field . . .
    Specify the following information . . .
    Name
    MS_1. WLOC automatically appends 0 to the first process instance name. For each additional process instance that is configured, a numeric suffix is added to the name starting with 1 and incrementing by 1 for each additional process instance.
    Because we are defining two ManagedServers, the first instance is automatically named MS_10 and the second instance is named MS_11.
    Description
    MS_1 JVM
    Main Class
    Leave this option selected. Because our service is managing WLS Admin and Managed Servers, we need to invoke the weblogic.Server main class.
    Main JAR
    Leave this option unselected.
    Host:
    localhost
    The host and port number are used to determine the address the Agent uses to collect JMX metric information from the endpoint.
    Starting Port#
    7002
    JMX Service URL
    Leave this field blank.
    Classpath
    The CLASSPATH for the domain. This field is prepopulated with the CLASSPATH that we entered for the AdminServer process group.
    JVM Arguments
    The JVM arguments to be used when the process starts. This field is prepopulated with the arguments that we entered for the AdminServer process group. We need to modify them as follows for the MS_1 Managed Server:
    1. Add the following argument required to start Managed Servers:

      2. -Dweblogic.management.server=http://localhost:7001

    2. Change the name of the server:

      3. -Dweblogic.Name=MS_1

    The remaining values apply to both the AdminServer and the Managed Servers.

    Note: All JVM arguments must be specified on one line, separated by spaces.
    Java Arguments
    In this example, we do not need to specify any Java arguments.
    UserName
    The username required for authenticating JMX connections.
    We use weblogic in this example.
    Password
    The password required for authenticating JMX connections.
    We use weblogic in this example.
    Instance Directory
    Leave this field blank.
    Native Lib Directory
    Leave this field blank.
    Use Native JMX
    Leave this unchecked.
    SSH Enabled
    Leave this unchecked.
    Protocol
    Leave iiop selected.
    Max Copies
    Leave this value set to 1.

  5. Define the ready metric for the MS_1 process instance as follows.

    6. Table 4-5 ManagedServers Ready Metrics 
    In this field . . .
    Specify the following information . . .
    Instance Name
    com.bea:Name=MS_1,Type=ServerRuntime
    Attribute
    State
    Value
    RUNNING
    Operator
    Value Equals (the default)
    Value Type
    String
    Wait
    300000

  6. Click Next.

    7. The Process Properties page is displayed listing both the AdminServer and ManagedServers process groups in the table.


    Use Case Example Topology

    We now need to modify the properties for the second Managed Server instance, MS_2.

  7. Select the name ManagedServers in the Process Group table. (Select the name itself, not the check box.) The list of defined processes in the process group is displayed. Note that the second Managed Server instance created is named MS_11 and the port is automatically incremented to 7003.


    8. Use Case Example Topology

  8. Select MS_11 in the Name column. The properties for the process are displayed.


    9. Use Case Example Topology

  9. In the Name field, change MS_11 to MS_2.
  10. In the Description field, change MS_1 JVM to MS_2 JVM.
  11. In the JVM Args field, change the argument -Dweblogic.Name=MS_1 to -Dweblogic.Name=MS_2.
  12. In the Ready Metric section, change the Instance Name field from com.bea:Name=MS_1,Type=ServerRuntime to com.bea:Name=MS_2,Type=ServerRuntime.
  13. Click Save. The updated process is shown in the table.


    14. Use Case Example Topology

    To avoid confusion, we will also change the name of the first Managed Server from MS_10 to MS_1 to match the name of the Managed Server in the WLS domain.

  14. Select MS_10 in the Name column. The process properties are displayed.
  15. In the Name field, change MS_10 to MS_1 and click Save. We now have two processes in the ManagedServers process group named MS_1 and MS_2.


    16. Use Case Example Topology

  16. Click Finish.
  17. Define the resource requirements for the process groups as described in the following section.

Define Resource Requirements for the Service

Before we finish creating the service, we need to define the resource requirements for each process group. When you define a resource requirement, you are creating a resource agreement. Resource agreements define requirements that are evaluated before starting a service or instance, which can occur both at deployment and runtime.

To define the resource requirements for the process groups in the CreditCheckService, we complete the following steps.

  1. Select the AdminServer process group check box and click Add Resource Requirements.


    2. Use Case Example Topology

  2. In the Minimum # of Processes field, enter 1 and click Save.

    3. This value specifies the number of instances that will be started when the service is deployed. It will also generate a policy that ensures that the minimum number specified is maintained while the service is running.

    We do not need to specify any other requirements for the AdminServer process group for this example.


    Use Case Example Topology

  3. Repeat steps 1 and 2 for the ManagedServers process group.
  4. Click Finish to create the service.

    5. The CreditCheckService is now shown in the Services table and the Task and Events Viewer at the bottom of the Console indicates that the CreditCheckService was added.


    Use Case Example Topology

View Deployment Policy

When you specify the resource requirements for the service, the deployment policy for the service is created automatically. A policy consists of a constraint and an action to take when the constraint is violated. In this example, we set the minimum number of processes to 1 which indicates that there must be one running instance in both the AdminServer and ManagedServers process groups in order to deploy the service. This constraint is automatically bound to the StartJavaInstanceAction.

To view the deployment policy, select the Policies tab.

Use Case Example Topology

Create Services Using Helper Methods

In this example, we created the service using the Start from Scratch option to demonstrate the complete method for defining process requirements. However, the WLOC Administration Console provides efficient helper methods that simplify this process by importing the information from the WLS domain. These helper methods include:

If you had selected one of these options in step 2 in Define the Administration Server Process Group, much of the information that we provided manually could have been captured from the config.xml file for the domain or by pointing to a running Administration Server.

CreditCheckService Service Metadata Configuration

When you create the service, the associated constraints, actions, and bindings are created automatically. Listing 4-1 shows how the CreditCheckService service configuration is represented in the metadata-config.xml file.

Listing 4-1 CreditCheckService Metadata Configuration 
<ns2:services>
        <ns2:service>
            <ns2:name>CreditCheckService</ns2:name>
            <ns2:description>Credit Check Service</ns2:description>
            <ns2:state>undeployed</ns2:state>
            <ns2:priority>0</ns2:priority>
            <ns2:constraint-bindings>
                <ns2:constraint-binding>
                    <ns2:constraint-key>CreditCheckServicedeploy-key</ns2:constraint-key>
                    <ns2:action-key>CreditCheckServicestartserviceaction</ns2:action-key>
                </ns2:constraint-binding>
                <ns2:constraint-binding>
                    <ns2:constraint-key>CreditCheckServiceundeploy-key</ns2:constraint-key>
                    <ns2:action-key>CreditCheckServicestopserviceaction</ns2:action-key>
                </ns2:constraint-binding>
            </ns2:constraint-bindings>
            <ns2:process-types>
                <ns2:process-type>
                    <ns2:constraint-bindings>
                        <ns2:constraint-binding>
                            <ns2:constraint-key>CreditCheckService-ManagedServers-minprocess</ns2:constraint-key>
                            <ns2:action-key>CreditCheckServicestartaction</ns2:action-key>
                        </ns2:constraint-binding>
                    </ns2:constraint-bindings>
                    <ns2:name>ManagedServers</ns2:name>
                    <ns2:description>ManagedServers-description</ns2:description>
                    <ns2:metadata-key>CreditCheckService-ManagedServersmetakey</ns2:metadata-key>
                </ns2:process-type>
                <ns2:process-type>
                    <ns2:constraint-bindings>
                        <ns2:constraint-binding>
                            <ns2:constraint-key>CreditCheckService-AdminServer-minprocess</ns2:constraint-key>
                            <ns2:action-key>CreditCheckServicestartaction</ns2:action-key>
                        </ns2:constraint-binding>
                    </ns2:constraint-bindings>
                    <ns2:name>AdminServer</ns2:name>
                    <ns2:description>AdminServer-description</ns2:description>
                    <ns2:metadata-key>CreditCheckService-AdminServermetakey</ns2:metadata-key>
                </ns2:process-type>
            </ns2:process-types>
            <ns2:max-failed-event-retry-count>10</ns2:max-failed-event-retry-count>
            <ns2:placement-algorithm>PreferLarger</ns2:placement-algorithm>
        </ns2:service>
    </ns2:services>
    <ns2:connection-factories/>
    <ns2:connection-infos/>
    <ns2:constraints>
        <ns2:deployment-state-constraint>
            <ns2:name>CreditCheckService-service-deploy</ns2:name>
            <ns2:key>CreditCheckServicedeploy-key</ns2:key>
            <ns2:priority>0</ns2:priority>
            <ns2:state>starting</ns2:state>
            <ns2:evaluation-period>0</ns2:evaluation-period>
        </ns2:deployment-state-constraint>
        <ns2:deployment-state-constraint>
            <ns2:name>CreditCheckService-service-undeploy</ns2:name>
            <ns2:key>CreditCheckServiceundeploy-key</ns2:key>
            <ns2:priority>0</ns2:priority>
            <ns2:state>stopping</ns2:state>
            <ns2:evaluation-period>0</ns2:evaluation-period>
        </ns2:deployment-state-constraint>
        <ns2:min-process-constraint>
            <ns2:name>CreditCheckService-AdminServer-minprocess</ns2:name>
            <ns2:key>CreditCheckService-AdminServer-minprocess</ns2:key>
            <ns2:priority>0</ns2:priority>
            <ns2:state>deployed</ns2:state>
            <ns2:evaluation-period>0</ns2:evaluation-period>
            <ns2:value>1</ns2:value>
        </ns2:min-process-constraint>
        <ns2:min-process-constraint>
            <ns2:name>CreditCheckService-ManagedServers-minprocess</ns2:name>
            <ns2:key>CreditCheckService-ManagedServers-minprocess</ns2:key>
            <ns2:priority>0</ns2:priority>
            <ns2:state>deployed</ns2:state>
            <ns2:evaluation-period>0</ns2:evaluation-period>
            <ns2:value>1</ns2:value>
        </ns2:min-process-constraint>
    </ns2:constraints>
    <ns2:notifications/>
    <ns2:pipelines/>
    <ns2:actions>
        <ns2:action>
            <ns2:name>CreditCheckServicestartserviceaction</ns2:name>
            <ns2:key>CreditCheckServicestartserviceaction</ns2:key>
            <ns2:impl-class>com.bea.adaptive.actions.internal.StartServiceAction</ns2:impl-class>
            <ns2:adjudicate>false</ns2:adjudicate>
            <ns2:properties/>
        </ns2:action>
        <ns2:action>
            <ns2:name>CreditCheckServicestopserviceaction</ns2:name>
            <ns2:key>CreditCheckServicestopserviceaction</ns2:key>
            <ns2:impl-class>com.bea.adaptive.actions.internal.StopServiceAction</ns2:impl-class>
            <ns2:adjudicate>false</ns2:adjudicate>
            <ns2:properties/>
        </ns2:action>
        <ns2:action>
            <ns2:name>CreditCheckServicestartaction</ns2:name>
            <ns2:key>CreditCheckServicestartaction</ns2:key>
            <ns2:impl-class>com.bea.adaptive.actions.internal.StartJavaInstanceAction</ns2:impl-class>
            <ns2:adjudicate>false</ns2:adjudicate>
            <ns2:properties/>
        </ns2:action>
        <ns2:action>
            <ns2:name>CreditCheckService-ManagedServers-defaultaction</ns2:name>
            <ns2:key>CreditCheckService-ManagedServers-defaultaction</ns2:key>
            <ns2:impl-class>com.bea.arc.ui.actions.ConsoleNotificationAction</ns2:impl-class>
            <ns2:adjudicate>false</ns2:adjudicate>
            <ns2:properties/>
        </ns2:action>
        <ns2:action>
            <ns2:name>CreditCheckService-AdminServer-defaultaction</ns2:name>
            <ns2:key>CreditCheckService-AdminServer-defaultaction</ns2:key>
            <ns2:impl-class>com.bea.arc.ui.actions.ConsoleNotificationAction</ns2:impl-class>
            <ns2:adjudicate>false</ns2:adjudicate>
            <ns2:properties/>
        </ns2:action>
    </ns2:actions>

AdminServer Process Group Metadata Configuration

Listing 4-2 shows how the AdminServer process group configuration is represented in the metadata-config.xml file. The ready metric configuration is shown in bold type.

Listing 4-2 AdminServer Process Group Metadata Configuration 
<ns2:metadata-group>
            <ns2:name>CreditCheckService-AdminServermeta1</ns2:name>
            <ns2:key>CreditCheckService-AdminServermetakey</ns2:key>
            <ns2:instances>
                <ns2:jvm-instance>
                    <ns2:name>AdminServer</ns2:name>
                    <ns2:description>AdminServer JVM</ns2:description>
                    <ns2:max-copies>1</ns2:max-copies>
                    <ns2:variables/>
                    <ns2:main-class>weblogic.Server</ns2:main-class>
                    <ns2:ready-information>
                        <ns2:check-type>ValueEquals</ns2:check-type>
                        <ns2:max-wait-period>300000</ns2:max-wait-period>
                        <ns2:instance>com.bea:Name=AdminServer,Type=ServerRuntime</ns2:instance>
                        <ns2:attribute>State</ns2:attribute>
                        <ns2:value>RUNNING</ns2:value>
                        <ns2:value-type>java.lang.String</ns2:value-type>
                    </ns2:ready-information>
                    <ns2:jvm-args>
                        <ns2:arg>-Xmx128m</ns2:arg>
                        <ns2:arg>-Xms64m</ns2:arg>
                        <ns2:arg>-da</ns2:arg>
                        <ns2:arg>-Dwls.home=C:\wls_92\weblogic92\server</ns2:arg>
                        <ns2:arg>-Dweblogic.management.discover=true</ns2:arg>
                        <ns2:arg>-Dweblogic.Name=AdminServer</ns2:arg>
                        <ns2:arg>-Dweblogic.management.username=weblogic</ns2:arg>
                        <ns2:arg>-Dweblogic.management.password=weblogic</ns2:arg>
                        <ns2:arg>-Djava.security.policy=C:\wls_92\weblogic92\server\lib\weblogic.policy</ns2:arg>
                        <ns2:arg>-Dweblogic.RootDirectory=C:\wls_92\user_projects\domains\WLOC_base_domain</ns2:arg>
                        <ns2:arg>-cp</ns2:arg>
                        <ns2:arg>C:\wls921\patch_weblogic921\profiles\default\sys_manifest_classpath\weblogic_patch.jar;
C:\wls921\JDK150~1\lib\tools.jar;C:\wls921\WEBLOG~1\server\lib\weblogic_sp.jar;C:\wls921\WEBLOG~1\server\lib\weblogic.jar;
C:\wls921\WEBLOG~1\server\lib\webservices.jar;C:\wls921\patch_weblogic921\profiles\default\sys_manifest_classpath\weblogic_patch.jar;
C:\wls921\JDK150~1\lib\tools.jar;C:\wls921\WEBLOG~1\server\lib\weblogic_sp.jar;C:\wls921\WEBLOG~1\server\lib\weblogic.jar;C:\wls921\WEBLOG~1\server\lib\webservices.jar;
;C:\wls921\patch_weblogic921\profiles\default\sys_manifest_classpath\weblogic_patch.jar;
C:\wls921\JDK150~1\lib\tools.jar;C:\wls921\WEBLOG~1\server\lib\weblogic_sp.jar
;C:\wls921\WEBLOG~1\server\lib\weblogic.jar;C:\wls921\WEBLOG~1\server\lib\webservices.jar;
;C:\wls921\WEBLOG~1\common\eval\pointbase\lib\pbclient51.jar;C:\wls921\WEBLOG~1\server\lib\xqrl.jar;;
;C:\wls921\WEBLOG~1\common\eval\pointbase\lib\pbclient51.jar;C:\wls921\WEBLOG~1\server\lib\xqrl.jar;
;C:\wls921\WEBLOG~1\common\eval\pointbase\lib\pbclient51.jar;C:\wls921\WEBLOG~1\server\lib\xqrl.jar</ns2:arg>
                    </ns2:jvm-args>
                    <ns2:java-args/>
                    <ns2:native-lib-dir></ns2:native-lib-dir>
                    <ns2:instance-dir></ns2:instance-dir>
                    <ns2:native-jmx>false</ns2:native-jmx>
                    <ns2:protocol>iiop</ns2:protocol>
                    <ns2:host>localhost</ns2:host>
                    <ns2:port>7001</ns2:port>
                    <ns2:username>weblogic</ns2:username>
                    <ns2:password>{Salted-3DES}tkGybm3FYNQvTYnIKW3B7Q==</ns2:password>
                    <ns2:ssh-enabled>false</ns2:ssh-enabled>
                    <ns2:wait-for-ssh>false</ns2:wait-for-ssh>
                    <ns2:priority>0</ns2:priority>
                    <ns2:copies-at-create/>
                    <ns2:copies-at-shutdown/>
                </ns2:jvm-instance>
            </ns2:instances>
        </ns2:metadata-group>
    </ns2:metadata>

 

Step 2: Define the Adaptive Runtime Policies

Now that we have defined the service and the initial deployment policies, we need to define the runtime policies.

WLOC policies specify runtime requirements (constraints or rules) for a service and actions to take when the service operates outside of the constraints. These policies define service level agreements (SLAs) for your services. For example, you can define a policy that starts another JVM if the constraint is violated.

WLOC contains a set of predefined constraints, called Smart Packs, that you can use to place requirements on some common measurements of service health and performance. In this example, we will define a runtime policy for the ManagedServers process group using the MaxAverageJVMProcessorLoad constraint that is provided as part of the Smart Pack constraints.

For the runtime policy, we will define a rule (constraint) in which we specify a value of 0.8 for the MaxAverageJVMProcessorLoad constraint. This value indicates that when the average JVM processor load exceeds 80%, an action must occur. In this example, a second Managed Server instance will be started.

To create the runtime policy and assign it to the ManagedServers process group:

  1. Select the Policies tab in the WLOC navigation bar, select the Definitions tab, and then select the Rules tab.

    2. The list of the process constraint deployment polices are shown in the table.


    Use Case Example Topology

  2. Click Add Policy Definition.
  3. In the Policy Properties page, enter MaxAverageJVMProcessorLoad in the Name field.
  4. Select Based on a named attribute from the Type drop-down menu and click Next.


    5. Use Case Example Topology

  5. In the Rule Properties page, accept the default for the Name and Priority fields.
  6. In the Attribute field, select MaxAverageJVMProcessorLoad from the drop-down menu.


    7. Use Case Example Topology

  7. Specify the remaining values as shown in the following table and click Finish.

    8. In this field . . .
    Do the following . . .
    Value
    Enter 0.8.
    Evaluation Period
    Enter 10000. This is the amount of time, in milliseconds, to wait before reevaluating the constraint.
    Service State
    Select deployed from the drop-down menu. This indicates that the service must be deployed before the constraint will be evaluated.


    Use Case Example Topology

    The new policy rule is added to the Rules table and the confirmation message New policy created successfully is displayed.


    Use Case Example Topology

  8. Select the Policies subtab to return to the Active Policies page.


    9. Use Case Example Topology

  9. Click Assign Policy to assign the policy (the rule and the action to take) to the ManagedServers process group.
  10. In the Policy Properties page, specify the properties of the policy as follows:
    1. In the Service drop-down menu, select CreditCheckService to assign the policy to the service.
    2. In the Process drop-down menu, select ManagedServers to assign the policy to the ManagedServers process group.
    3. In the Instance drop-down menu, select All Instances for ManagedServers to assign the policy to all the Managed Server instances in the process group.
    4. In the Definitions drop-down menu, select MaxAverageJVMProcessorLoad to assign the rule definition to the policy.
    5. In the Run Action drop-down menu, select CreditCheckServicestartaction to specify the action to take when the constraint (rule) is violated.
    6. Because we did not define an action pipeline in this example, leave None selected in the Run Pipeline drop-down menu.
    7. Leave the Automatic Console Notification checkbox selected. This setting automatically generates a console notification when the specified constraint for the SLA is violated. A notification is also automatically generated when the action taken to rectify the SLA violation has completed.


      8. Use Case Example Topology

  11. Click Finish to finish assigning the policy to the process group.

    12. The policy assignment is created and the Binding created successfully confirmation message is displayed.

    Note that the MaxAverageJVMProcessorLoad policy is now assigned to the ManagedServers process group in the Active Policies table.


    Use Case Example Topology

Runtime Policy Metadata Configuration

Listing 4-3 shows how the MaxAverageJVMProcessorLoad configuration for the constraint binding, custom constraint, and associated action is represented in the metadata-config.xml file.

Listing 4-3 Runtime Policy Metadata Configuration 
.
.
.
<ns2:process-types>
                <ns2:process-type>
                    <ns2:constraint-bindings>
                        <ns2:constraint-binding>
                            <ns2:constraint-key>CreditCheckService-ManagedServers-minprocess</ns2:constraint-key>
                            <ns2:action-key>CreditCheckServicestartaction</ns2:action-key>
                        </ns2:constraint-binding>
                        <ns2:constraint-binding>
                            <ns2:constraint-key>MaxAverageJVMProcessorLoad</ns2:constraint-key>
                            <ns2:action-key>CreditCheckServicestartaction</ns2:action-key>
                        </ns2:constraint-binding>
                    </ns2:constraint-bindings>
                    <ns2:name>ManagedServers</ns2:name>
                    <ns2:description>ManagedServers-description</ns2:description>
                    <ns2:metadata-key>CreditCheckService-ManagedServersmetakey</ns2:metadata-key>
                </ns2:process-type>
.
.
.
<ns2:custom-constraint>
            <ns2:name>MaxAverageJVMProcessorLoad</ns2:name>
            <ns2:key>MaxAverageJVMProcessorLoad</ns2:key>
            <ns2:priority>0</ns2:priority>
            <ns2:state>deployed</ns2:state>
            <ns2:evaluation-period>10000</ns2:evaluation-period>
            <ns2:constraint>MaxAverageJvmProcessorLoad</ns2:constraint>
            <ns2:value>0.8</ns2:value>
        </ns2:custom-constraint>
.
.
.
ns2:action>
            <ns2:name>CreditCheckServicestartaction</ns2:name>
            <ns2:key>CreditCheckServicestartaction</ns2:key>
            <ns2:impl-class>com.bea.adaptive.actions.internal.StartJavaInstanceAction</ns2:impl-class>
            <ns2:adjudicate>false</ns2:adjudicate>
            <ns2:properties/>
        </ns2:action>

 

What’s Next?

Now that we have defined the service to be managed and assigned deployment and runtime policies, we need to deploy the service as described in Deploy the Service Against Available Resources.


  Back to Top       Previous  Next