管理されるサービスの定義

この使用例の次のタスクでは、管理されるサービスを定義し、アプリケーションが要件に応じてデプロイおよび実行されることを保証するデプロイメントおよび実行時のポリシーを作成し、割り当てます。

サービスはプロセスのグループであり、プロセスタイプはサービス内のプロセスのサブグループです (プロセスタイプは、WLOC Administration Console ではプロセスグループと呼ばれます)。サービスの目的は、連動するプロセスの集まりをグループ化することです。プロセスグループの目的は、同じ機能を実行し、アクションが発生した場合に同等に処理できるサービス内のインスタンスを定義することです。

たとえば、Web アプリケーション層とビジネスロジック層を持つ 2 層のアプリケーションを使用する場合があります。各層のインスタンスが均一である場合は、各層をプロセスグループとして整理し、2 つのプロセスグループをまとめてサービスを構成できます。

これらの 2 つのグループ化の違いは、ポリシーを定義する際に重要になります。一般に、デプロイメントに関連するポリシーはサービス全体に適用されますが、実行時のポリシーは特定のプロセスグループに対して適用されます。さらに、プロセスタイプのアクションでは、デフォルトで、通常は 1 つのグループメンバーが実行の対象として選択されます。たとえば、アクションによってインスタンスが停止される場合、停止されるインスタンスは通常指定されず、コントローラによってインスタンスが選択されます。

サービスのコンフィグレーションでは、WLOC Administration Console の [Inventory｜Services] ページを使用します。サービスのコンフィグレーションは metadata-config.xml という XML ファイルに永続化されます。デフォルトでは、このサービスメタデータコンフィグレーションファイルは BEA_HOME/user_projects/controller/config ディレクトリに置かれます。このサービスメタデータコンフィグレーションファイルを変更して、サービスをコンフィグレーションできます。ただし、メタデータコンフィグレーションファイルを変更してサービスをコンフィグレーションした場合は、Administration Console を使用したサービスのコンフィグレーションで利用可能な検証およびエラーチェック機能のメリットを利用できません。

図 4-1 は、ソフトウェアロードバランサを使用してバックエンド Web サービスを呼び出す複数のクライアントアプリケーションで構成される SOA アプリケーションの例を示します。バックエンド Web サービスは WLS 管理対象サーバでホストすることが可能です。

図 4-2 に、この例のトポロジを示します。この例では Windows 環境を使用していますが、他のプラットフォームもサポートされています。サポートされているプラットフォームの一覧については、WebLogic Operations Control サポート対象のコンフィグレーションを参照してください。

手順 1 : サービスとプロセスグループの作成

サービスメタデータを定義する最初の手順では、サービスの全般的なプロパティを定義し、次に、包含されるプロセスグループを定義します。

作成するサービスには 2 つのプロセスグループが含まれ、1 つは WLS 管理サーバのインスタンス、もう 1 つは管理対象サーバのインスタンス 2 個で構成されます。WLS ドメインで、これらのインスタンスの名前は AdminServer、MS_1、MS_2 です。WebLogic ドメインが適切にコンフィグレーションされ、サーバが正常に起動することを確認する必要があります。

WLOC ナビゲーションバーで [Inventory] タブをクリックし、ツリー内の [Services] をクリックします。

サービスはまだ定義されていないため、テーブルにサービスは表示されていません。

使用例のトポロジ

注意 :

[Inventory] ペインの右下隅にあるポートレットサイズ変更アイコンをドラッグしてポートレットのサイズを変更できます。

[New] をクリックして、[Service Properties] ページを表示します。
全般的なサービスプロパティとして、以下の表に示す値を入力します。

表 4-1 全般的なサービスプロパティ
フィールド	指定する情報
[Name]	CreditCheckService
[Description:]	Credit Check Service
[Retry Count:]	10 (デフォルト)
[Priority:]	0 (デフォルト)
[Placement Algorithm:]	[Prefer resource pools with the most resources]

使用例のトポロジ

[Next] をクリックします。

[Process Properties] ページが表示されます。サービスのプロセスグループを追加するには、このページから開始します。

管理サーバプロセスグループの定義

以下の手順では、管理サーバプロセスグループのプロパティを指定し、準備完了メトリックを定義する方法を説明します。

[Process Properties] ページで [Add Process Group] をクリックして、このサービスの最初のプロセスグループを追加します。

使用例のトポロジ

[Process Requirements] ドロップダウンメニューで [Start from Scratch] を選択し、[Next] をクリックします。

使用例のトポロジ

[Start from Scratch] を選択すると、プロセスグループのプロパティ、プロセスグループへのインスタンス追加時に使用される JVM パラメータ、リソースとして使用可能なインスタンスの状況を指定する準備完了メトリックを指定するための各ページが表示されます。

[Process Properties] ページで、まず AdminServer プロセスグループを定義します。[Process Group Properties] に、以下の値を入力します。

[Process Group:] AdminServer
[Number of processes:] 1

使用例のトポロジ

ウィンドウの [Process Group Template Properties] で、AdminServer プロセスグループのインスタンスについて、表 4-2 に示された値を入力します。

フィールド

指定する情報

[Name]

AdminServer

[Description]

AdminServer JVM

[Main Class]

このオプションは選択したままにします。サービスは WLS にデプロイされるため、weblogic.Server メインクラスを呼び出す必要があります。

[Main JAR]

このオプションは未選択のままにします。

[Host:]

ホストマシンの名前。

この例では、localhost を指定します。

このホストとポート番号は、エージェントが JMX メトリック情報をエンドポイントから収集するために使用するアドレスの決定に使用されます。

[Starting Port#]

7001

[JMX Service URL]

この例では、WLS エンドポイントを使用し、[Host] および [Starting Port#] の各フィールドに値を指定しているため、このフィールドは空のままにします。WLS 以外のエンドポイントを使用する場合は、[Host] および [Starting Port#] の各フィールドに値を指定する代わりに、このフィールドに JMX サービス URL を指定できます。

[Classpath]

ドメインの CLASSPATH。

[JVM Arguments]

プロセスの起動時に使用される JVM 引数。この例では、最小および最大ヒープサイズを指定し、WebLogic Server インスタンス名、セキュリティ資格、セキュリティポリシー、ホームディレクトリとドメインディレクトリを設定するために、weblogic.Server 開始コマンドに追加する引数を入力します。

-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

注意 :

すべての JVM 引数は、スペースで区切って 1 行で指定する必要があります。

[Java Arguments]

この例では、Java 引数は必要ありません。

[UserName]

ユーザ名は JMX 接続の認証に必要です。

この例では、管理サーバに対する認証で必要となるため、ユーザ名とパスワードの両方に weblogic を指定します。

[Password]

パスワードは JMX 接続の認証に必要です。

weblogic と入力します。

[Instance Directory]

このフィールドは空のままにします。

[Native Lib Directory]

このフィールドは空のままにします。

[Use Native JMX]

チェックを外したままにします。

[SSH Enabled]

チェックを外したままにします。

[Protocol]

iiop を選択したままにします。

[Max Copies]

デフォルトの 1 を使用します。このフィールドは、メタデータコンフィグレーションで重複を物理的にコンフィグレーションせずにプロセスの複数コピーを作成するために JVM 変数と共に使用されます。この例では JVM 変数を使用しないため、このフィールドに異なる値を指定する必要はありません。

使用例のトポロジ

AdminServer インスタンスの準備完了メトリックを指定するため、表 4-3 に示された値を入力します。

準備完了メトリックは、プロセスが開始されて、作業の準備が整った状況を示します。WebLogic Server インスタンスの場合、ServerRuntime MBean には State 属性が含まれています。ServerRuntimeMbean.State=RUNNING である場合、WebLogic Server インスタンスは準備完了の状態にあります。

表 4-3 AdminServer 準備完了メトリック
フィールド	指定する情報
[Instance Name]	com.bea:Name=AdminServer,Type=ServerRuntime
[Attribute]	State
[Value]	RUNNING
[Operator]	[Value Equals] (デフォルト)
[Value Type]	String
[Wait]	300000 (この値により、WLS 管理サーバインスタンスが起動を完了するための時間が確保されます。)

使用例のトポロジ

[Next] をクリックします。

AdminServer プロセスグループが [Process Group] テーブルに表示されます。

使用例のトポロジ

次の手順では、管理対象サーバプロセスグループを定義します。

管理対象サーバプロセスグループの定義

以下の手順では、2 つの管理対象サーバインスタンスのプロパティを指定し、準備完了メトリックを指定する方法を説明します。

[Process Properties] ページで [Add Process Group] をクリックして、管理対象サーバプロセスグループを追加します。
[Process Requirements] ドロップダウンメニューで [Start from Scratch] を選択し、[Next] をクリックします。
[Start from Scratch] ページで、まず管理対象サーバプロセスグループを定義します。

プロセスグループに ManagedServers という名前を付けます。
このグループには 2 つの管理対象サーバが含まれるため、[Number of Processes] フィールドに 2 と入力します。

表 4-4 に示す [Process Group Template] プロパティの値を入力して、管理対象サーバのプロセスを定義します。

テンプレートに設定されている値は AdminServer プロセスグループに指定した値から取得されています。ManagedServers グループではこれらの値を適切な値に変更します。

このページで指定した値は、グループ内のすべてのインスタンスで複製されます。このため、この例では、両方の管理対象サーバインスタンスに最初は同じ値が含まれています。

フィールド

指定する情報

[Name]

MS_1。WLOC では最初のプロセスインスタンス名に 0 が自動的に付加されます。コンフィグレーションされた追加の各プロセスインスタンスでは、追加の各プロセスインスタンスごとに、1 で始まり 1 ずつ増える数値のサフィックスが名前に追加されます。

ここでは 2 つの ManagedServers を定義するため、最初のインスタンスには自動的に MS_10 という名前が付けられ、2 つ目のインスタンスには MS_11 という名前が付けられます。

[Description]

MS_1 JVM

[Main Class]

このオプションは選択したままにします。サービスでは WLS 管理サーバと管理対象サーバを管理するため、weblogic.Server メインクラスを呼び出す必要があります。

[Main JAR]

このオプションは未選択のままにします。

[Host:]

localhost

このホストとポート番号は、エージェントが JMX メトリック情報をエンドポイントから収集するために使用するアドレスの決定に使用されます。

[Starting Port#]

7002

[JMX Service URL]

このフィールドは空のままにします。

[Classpath]

ドメインの CLASSPATH。このフィールドには、AdminServer プロセスグループに入力された CLASSPATH があらかじめ設定されています。

[JVM Arguments]

プロセスの起動時に使用される JVM 引数。このフィールドには、AdminServer プロセスグループに入力された引数があらかじめ設定されています。MS_1 管理対象サーバではこれらの値を以下のように変更する必要があります。

管理対象サーバの開始に必要な以下の引数を追加します。

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

サーバ名を変更します。

-Dweblogic.Name=MS_1

残りの値は管理サーバおよび管理対象サーバの両方に適用されます。

注意 :

すべての JVM 引数は、スペースで区切って 1 行で指定する必要があります。

[Java Arguments]

この例では Java 引数を指定する必要はありません。

[UserName]

ユーザ名は JMX 接続の認証に必要です。

この例では weblogic を使用します。

[Password]

パスワードは JMX 接続の認証に必要です。

この例では weblogic を使用します。

[Instance Directory]

このフィールドは空のままにします。

[Native Lib Directory]

このフィールドは空のままにします。

[Use Native JMX]

チェックを外したままにします。

[SSH Enabled]

チェックを外したままにします。

[Protocol]

iiop を選択したままにします。

[Max Copies]

この値は 1 に設定されたままにします。

MS_1 プロセスインスタンスの準備完了メトリックを、以下のように定義します。

表 4-5 ManagedServers 準備完了メトリック
フィールド	指定する情報
[Instance Name]	com.bea:Name=MS_1,Type=ServerRuntime
[Attribute]	State
[Value]	RUNNING
[Operator]	[Value Equals] (デフォルト)
[Value Type]	String
[Wait]	300000

[Next] をクリックします。

[Process Properties] ページが表示され、AdminServer および ManagedServers プロセスグループがテーブルに表示されます。

使用例のトポロジ

次に、2 つ目の管理対象サーバインスタンス MS_2 のプロパティを変更する必要があります。

[Process Group] テーブル内の名前 [ManagedServers] を選択します (チェックボックスではなく、名前を選択します)。プロセスグループに定義されたプロセスのリストが表示されます。作成された 2 つ目の管理対象サーバインスタンスに MS_11 という名前が付けられ、ポートが自動的に 7003 に増分されています。

使用例のトポロジ

[Name] カラムで MS_11 を選択します。プロセスのプロパティが表示されます。

使用例のトポロジ

[Name] フィールドで、MS_11 を MS_2 に変更します。
[Description] フィールドで、MS_1 JVM を MS_2 JVM に変更します。
[JVM Args] フィールドで、引数 -Dweblogic.Name=MS_1 を -Dweblogic.Name=MS_2 に変更します。
[Ready Metric] セクションで、[Instance Name] フィールドを com.bea:Name=MS_1,Type=ServerRuntime から com.bea:Name=MS_2,Type=ServerRuntime に変更します。
[Save] をクリックします。更新されたプロセスがテーブルに表示されます。

使用例のトポロジ

混乱を避けるため、WLS ドメインの管理対象サーバの名前に合わせて、最初の管理対象サーバの名前を MS_10 から MS_1 に変更します。

[Name] カラムで MS_10 を選択します。プロセスのプロパティが表示されます。
[Name] フィールドで、MS_10 を MS_1 に変更し、[Save] をクリックします。これで、ManagedServers プロセスグループに MS_1 と MS_2 の 2 つのプロセスが作成されました。

使用例のトポロジ

[Finish] をクリックします。
以下の節の説明に従って、プロセスグループのリソース要件を定義します。

サービスのリソース要件の定義

サービスの作成を完了する前に、各プロセスグループのリソース要件を定義する必要があります。リソース要件を定義する場合は、リソースアグリーメントを作成します。リソースアグリーメントでは、サービスまたはインスタンスの開始前に評価される要件が定義され、これはデプロイメントおよび実行時の両方で使用できます。

CreditCheckService のプロセスグループのリソース要件を定義するには、以下の手順を実行します。

[AdminServer] プロセスグループのチェックボックスを選択し、[Add Resource Requirements] をクリックします。

使用例のトポロジ

[Minimum # of Processes] フィールドに 1 と入力し、[Save] をクリックします。

この値によって、サービスのデプロイ時に開始されるインスタンスの数が指定されます。また、サービスの実行中に指定された最小数のプロセスの維持を確保するポリシーも生成されます。

この例では、AdminServer プロセスグループにその他の要件を指定する必要はありません。

使用例のトポロジ

ManagedServers プロセスグループについて手順 1 と 2 を繰り返します。
[Finish] をクリックしてサービスを作成します。

CreditCheckService が [Services] テーブルと、コンソール下部の [Task and Events] ビューアに表示され、CreditCheckService が追加されたことが示されます。

使用例のトポロジ

デプロイメントポリシーの表示

サービスのリソース要件を指定すると、サービスのデプロイメントポリシーが自動的に作成されます。ポリシーは、制約および制約を違反した場合に実行されるアクションで構成されます。この例では、最小プロセス数を 1 に設定します。これは、サービスをデプロイするために AdminServer と ManagedServers プロセスグループの両方で実行中の 1 つのインスタンスが存在する必要があることを示します。この制約は自動的に StartJavaInstanceAction にバインドされます。

デプロイメントポリシーを表示するには、[Policies] タブを選択します。

ヘルパーメソッドを使用したサービスの作成

この例では、プロセス要件を定義する完全な方法を示すため、[Start from Scratch] オプションを使用してサービスを作成しました。ただし、WLOC Administration Console では、WLS ドメインから情報をインポートすることでこの処理を簡素化する効率的なヘルパーメソッドが提供されます。これらのヘルパーメソッドには、以下のものがあります。

「管理サーバプロセスグループの定義」の手順 2 でこれらのオプションのうちのいずれかを選択した場合は、手動で指定した情報の大部分がドメインの config.xml ファイルから取得されるか、または実行中の管理サーバを参照することで取得されます。

CreditCheckService サービスのメタデータコンフィグレーション

サービスを作成すると、関連付けられた制約、アクション、およびバインドが自動的に作成されます。コードリスト 4-1 に、CreditCheckService サービスのコンフィグレーションが metadata-config.xml ファイルでどのように表現されるかを示します。

<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 プロセスグループのメタデータコンフィグレーション

コードリスト 4-2 に、AdminServer プロセスグループのコンフィグレーションが metadata-config.xml ファイルでどのように表現されるかを示します。太字部分に、準備完了メトリックのコンフィグレーションを示します。

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

手順 2 : 順応的な実行時ポリシーの定義

サービスと初期デプロイメントポリシーが定義できたので、実行時ポリシーを定義する必要があります。

WLOC ポリシーでは、サービスの実行時の要件 (制約またはルール) と、サービスの動作が制約を越えた場合に実行されるアクションが指定されます。これらのポリシーではサービスのサービスレベルアグリーメント (SLA) が定義されます。たとえば、制約に違反した場合に別の JVM が開始されるポリシーを定義できます。

WLOC には Smart Packs というあらかじめ定義された制約のセットが含まれており、これを使用して、サービスの状態およびパフォーマンスに関する一般的な測定値に要件を付与することができます。この例では、Smart Pack 制約の一部として提供される MaxAverageJVMProcessorLoad 制約を使用して、ManagedServers プロセスグループの実行時ポリシーを定義します。

実行時ポリシーでは、MaxAverageJVMProcessorLoad 制約の値を 0.8 に指定するルール (制約) を定義します。この値は、JVM プロセッサの平均負荷が 80% を超えた場合にアクションが発生する必要があることを示します。この例では、2 つ目の管理対象サーバインスタンスが開始されます。

実行時ポリシーを作成し、ManagedServers プロセスグループに割り当てるには :

WLOC ナビゲーションバーで [Policies] タブを選択し、[Definitions] タブ、[Rules] タブの順に選択します。

プロセス制約のデプロイメントポリシーのリストがテーブルに表示されます。

使用例のトポロジ

[Add Policy Definition] をクリックします。
[Policy Properties] ページで、[Name] フィールドに [MaxAverageJVMProcessorLoad] と入力します。
[Type] ドロップダウンメニューで [Based on a named attribute] を選択し、[Next] をクリックします。

使用例のトポロジ

[Rule Properties] ページで、[Name] および [Priority] フィールドのデフォルト値を使用します。
[Attribute] フィールドで、ドロップダウンメニューの [MaxAverageJVMProcessorLoad] を選択します。

使用例のトポロジ

残りの値を以下の表のとおりに指定し、[Finish] をクリックします。

フィールド	処理内容
[Value]	0.8 と入力します。
[Evaluation Period]	10000 と入力します。これは、制約を再評価するまで待機する時間 (ミリ秒) です。
[Service State]	ドロップダウンメニューで [deployed] を選択します。これは、制約を評価する前にサービスがデプロイされる必要があることを示します。

使用例のトポロジ

新しいポリシールールが [Rules] テーブルに追加され、確認メッセージ [New policy created successfully] が表示されます。

使用例のトポロジ

[Policies] サブタブを選択して、[Active Policies] ページに戻ります。

使用例のトポロジ

[Assign Policy] をクリックして、ManagedServers プロセスグループにポリシー (ルールおよび実行されるアクション) を割り当てます。
[Policy Properties] ページで、ポリシーのプロパティを以下のように指定します。

[Service] ドロップダウンメニューで、[CreditCheckService] を選択して、サービスにポリシーを割り当てます。
[Process] ドロップダウンメニューで、[ManagedServers] を選択して、ManagedServers プロセスグループにポリシーを割り当てます。
[Instance] ドロップダウンメニューで、[All Instances for ManagedServers] を選択して、プロセスグループのすべての管理対象サーバインスタンスにポリシーを割り当てます。
[Definitions] ドロップダウンメニューで、[MaxAverageJVMProcessorLoad] を選択して、ポリシーにルール定義を割り当てます。
[Run Action] ドロップダウンメニューで、[CreditCheckServicestartaction] を選択して、制約 (ルール) に違反した場合に実行されるアクションを指定します。
この例ではアクションパイプラインを定義していないため、[Run Pipeline] ドロップダウンメニューの [None] が選択されたままにします。
[Automatic Console Notification] チェックボックスが選択されたままにします。この設定により、SLA に指定された制約に違反した場合はコンソール通知が自動的に生成されます。通知は、SLA 違反を訂正するために実行されたアクションが完了した際にも自動生成されます。

使用例のトポロジ

[Finish] をクリックして、プロセスグループへのポリシーの割り当てを完了します。

ポリシーの割り当てが作成され、確認メッセージ [Binding created successfully] が表示されます。

[Active Policies] テーブルで、[MaxAverageJVMProcessorLoad] ポリシーが ManagedServers プロセスグループに割り当てられています。

使用例のトポロジ

実行時ポリシーのメタデータコンフィグレーション

コードリスト 4-3 に、制約のバインド、カスタム制約、および関連付けられたアクションの MaxAverageJVMProcessorLoad コンフィグレーションが metadata-config.xml ファイルでどのように表現されるかを示します。

次の作業

管理対象のサービスの定義とデプロイメントおよび実行時ポリシーの割り当てが完了したので、「使用可能なリソースへのサービスのデプロイ」で説明する手順に従って、サービスをデプロイする必要があります。

Plain Agent の使用例

管理されるサービスの定義

手順 1 : サービスとプロセス グループの作成

管理サーバ プロセス グループの定義

管理対象サーバ プロセス グループの定義

サービスのリソース要件の定義

デプロイメント ポリシーの表示

ヘルパー メソッドを使用したサービスの作成

CreditCheckService サービスのメタデータ コンフィグレーション

AdminServer プロセス グループのメタデータ コンフィグレーション

手順 2 : 順応的な実行時ポリシーの定義

実行時ポリシーのメタデータ コンフィグレーション

次の作業

手順 1 : サービスとプロセスグループの作成

管理サーバプロセスグループの定義

管理対象サーバプロセスグループの定義

デプロイメントポリシーの表示

ヘルパーメソッドを使用したサービスの作成

CreditCheckService サービスのメタデータコンフィグレーション

AdminServer プロセスグループのメタデータコンフィグレーション

実行時ポリシーのメタデータコンフィグレーション