Define the Service Under Management

The next task in the 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 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 be 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. Note, however, that 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 if you configure 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 backend Web Service via a software load balancer. The back end Web Service can be hosted on WLS Managed Servers.

In this use case example, we will use the WLOC Administration Console to create a service named CreditCheckService that will manage the backend Managed Servers, and an Administration Server. The Managed Servers host the Credit Check Web Services as shown in Figure 4-2. We will create two process groups: an Administration Server process group and a Managed Server process group. We will specify a process requirement for each of the process groups that requires a minimum of one Admin Server and one Managed Server be started before the service is deployed. We will also define a runtime policy that executes only after the service is deployed, and will start the second Managed Server if the rule definition (constraint) is violated. Figure 4-2 illustrates the topology in this example. Note that we are using a Windows environment in this example, but other platforms are supported also. For a list of supported platforms, see BEA WebLogic Operations Control Supported Configurations.

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 WebLogic Server Administration Server instance and one that consists of two Managed Server instances. In the WebLogic Server domain, these instances are named AdminServer, MS_1, and MS_2.

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

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

Use Case Example Topology

Click New to display the Service Properties page.
Enter the values shown in the following table for the general service properties.

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

Click Next.

The Process Requirements 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.

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

Use Case Example Topology

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

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.

In the Start from Scratch 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

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

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
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=D:\wls_92\weblogic92\server -Dweblogic.management.discover=true -Dweblogic.Name=AdminServer -Dweblogic.management.username=weblogic -Dweblogic.management.password=weblogic -Djava.security.policy=D:\wls_92\weblogic92\server\lib\weblogic.policy -Dweblogic.RootDirectory=D:\wls_92\user_projects\domains\LOC_base_domain`
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.

Use Case Example Topology

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

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

Click Next.

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.

In the Process Requirements page, click Add Process Group to add the Managed Server process group.
Select Start from Scratch from the Process Requirements drop down menu and click Next.
In the Start from Scratch page, we will first define the Managed Servers process group.

Name the process group ManagedServers
Because we have two Managed Servers in this group, enter 2 in the Number of Processes field.

Define the Managed Server processes by entering the values shown in Table 4-4 for the Process Group Template properties.

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
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
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: Add the following argument required to start Managed Servers: `-Dweblogic.management.server=http://localhost:7001` Change the name of the server: `-Dweblogic.Name=MS_1` The remaining values apply to both the AdminServer and the Managed Servers.
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.

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

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

Click Next.

The Process Requirements 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.

Select the ManagedServers name in the Process Group table. The list of defined processes in the process group is displayed. Note that the second ManagedServer instance created is named MS_11 and the port is automatically incremented to 7003.

Use Case Example Topology

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

Use Case Example Topology

In the Name field, change MS_11 to MS_2.
In the Description field, change MS_1 to MS_2.
In the JVM Args field, change the argument -Dweblogic.Name=MS_1 to -Dweblogic.Name=MS_2.
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.
Click Save. The updated process is shown in the table.

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.

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

Use Case Example Topology

Click Finish.
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.

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

Use Case Example Topology

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

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

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

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. This constraint is automatically bound to the StartJavaInstanceAction

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 5 above, much of the information that we provided manually could have been captured from the config.xml file for the domain.

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.

<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: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.

<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>AdminServerJVM</ns2:description>
                    <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=D:\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=D:\wls_92\weblogic92\server\lib\weblogic.policy</ns2:arg>
                        <ns2:arg>-Dweblogic.RootDirectory=D:\wls_92\user_projects\domains\LOC_base_domain</ns2:arg>
                        <ns2:arg>-cp</ns2:arg>
                        <ns2:arg>D:\wls_92\patch_weblogic921\profiles\default\sys_manifest_classpath\weblogic_patch.jar;
D:\wls_92\JDK150~1\lib\tools.jar;D:\wls_92\WEBLOG~1\server\lib\weblogic_sp.jar;
D:\wls_92\WEBLOG~1\server\lib\weblogic.jar;D:\wls_92\WEBLOG~1\server\lib\webservices.jar;
D:\wls_92\WEBLOG~1\common\eval\pointbase\lib\pbclient51.jar;D:\wls_92\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}W0v+mTzrr9u/PRD30V1XGw==</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>

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 increases the amount of memory available if the memory requirements for a specific JVM grow beyond a specified number of MBs.

WLOC contains a set of predefined constraints, called SmartPacks, 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.

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

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

Use Case Example Topology

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

Use Case Example Topology

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

Use Case Example Topology

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

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 Definitions table.

Use Case Example Topology

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

Use Case Example Topology

Click Assign Policy to assign the policy (the rule and the action to take) to the ManagedServers process group.
In the Policy Properties page, specify the properties of the policy as follows:

In the Service drop-down menu, select CreditCheckService to assign the policy to the service.
In the Process drop-down menu, select ManagedServers to assign the policy to the ManagedServers process group.
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.
In the Definitions drop-down menu, select MaxAverageJVMProcessorLoad to assign the rule definition to the policy.
In the Run Action drop-down menu, select CreditCheckServicestartaction to specify the action to take when the constraint (rule) is violated.
Because we did not define an action pipeline in this example, leave None selected in the Run Pipeline drop-down menu.

Use Case Example Topology

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

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.

.
.
.
<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.