3. 提供機能

3.1. 概要

3.1.1. 提供機能一覧

WebOTX の各製品で提供する機能一覧を以下に示します。

表3.1.1-1
カテゴリ	機能名称	Express	Standard	Enterprise
OS	Windows(x86/x64)	○	○	○
	HP-UX(IPF)	○	○	○
	Linux(x86/x64)	○	○	○
Webサーバ	HTTP 1.0/1.1	○	○	○
Webサーバ	SSL 2.0/3.0、TLS 1.0	○	○	○
Webサービス	SOAP 1.1/1.2	○	○	○
	WSDL 1.1	○	○	○
	WS-Security 1.1	○	○	○
	WS-SecurityPolicy 1.2	○	○	○
	WS-ReliableMessaging 1.2	○	○	○
Java SE	JDBC 2.0/3.0/4.0/4.1	○	○	○
	RMI-IIOP 1.0	○	○	○
	JNDI 1.2	○	○	○
	JAXP 1.3	○	○	○
	JMX 2.0	○	○	○
	JMX Remote API 1.0	○	○	○
Java EE	EJB 3.1	○	○	○
	Servlet 3.0/JSP 2.2	○	○	○
	JSTL 1.2	○	○	○
	JSF 2.0	○	○	○
	JMS 1.1	○	○	○
	JPA 2.0	○	○	○
	JTA 1.1	○	○	○
	JAXR 1.0	○	○	○
	JavaMail 1.4/JAF 1.1	○	○	○
	JCA 1.6	○(*1)	○(*1)	○(*1)
	JAX-WS 2.2	○	○	○
	JAX-RPC 1.1	○	○	○
	JAX-RS 1.1	○	○	○
	SAAJ 1.3	○	○	○
	StAX 1.0	○	○	○
	JAXB 2.2	○	○	○
	Java EE Management 1.1	○	○	○
	Java EE Deployment 1.2	○	○	○
	JACC 1.3	○	○	○
CORBA	CORBA 2.3/3.0(一部)	○	○	○
	Event サービス	○	○	○
	名前サービス	○	○	○
	インタオペラブル名前サービス	○	○	○
	Transaction サービス	○	○	○
	Notification サービス	×	○(*2)	○(*2)
	Persistent State サービス	×	○(*2)	○(*2)
XML	XML 1.0 Fourth Edition	○	○	○
	XML 1.1 Second Edition	○	○	○
	Namespaces in XML 1.1	○	○	○
	XInclude 1.0	○	○	○
	DOM Level 3	○	○	○
	SAX 2.0.2	○	○	○
	XML Schema 1.0	○	○	○
	XSLT 1.0	○	○	○
	XPath 1.0	○	○	○
オンライントランザクション処理	流量制御	×	○	○
	オブジェクトの事前生成	○	○	○
	マルチプロセス実行	×	○	○
	プロセス障害監視/閉塞	×	○	○
運用・実行制御	システム構成情報の設定・変更・追加	○	○	○
	動的多重度変更	×	○	○
	アプリケーションの登録・変更・削除	○	○	○
	アプリケーションの配備、配備解除	○	○	○
	サービス単位の活性・非活性	○	○	○
	Web ベースの管理ツール	○(*3)	○(*3)	○(*3)
	バッチを含めた自動運転	○	○	○
	診断情報(ログ)採取	○	○	○
	システム構成情報のエクスポート・インポート	○	○	○
	分散システム運用の仮想化	×	×	○
	アプリケーションの分散配備、一括配備	×	×	○
	システム構成情報の一括設定	×	×	○
	システム構成情報の差異検出	×	×	○
	イベント通知の集約	×	×	○
負荷分散	ラウンドロビン	×	○	○
	重み付けラウンドロビン	×	×	○
	動的負荷分散	×	×	○
フェイルオーバ	スタンバイ	○	○	○
フェイルオーバ	高速スタンバイ	×	×	○
性能計測	性能分析用API	×	○	○
性能計測	ログアナライザ	×	○	○
開発言語	Java	○	○	○
	C++	×	○	○
	COBOL	×	○(*4)	○(*4)
連携機構	既存システム連携	○(*5)	○(*5)	○(*5)
印刷機構	帳票印刷	×	○(*6)	○(*6)
ディレクトリサービス	LDAP サーバ	○(*7)	○(*7)	○(*7)

*1: ACOS VIS と連携する場合にはWebOTX OLF/TP アダプタを別途購入する必要があります。

*2: WebOTX CORBA 共通サービス準拠製品を別途購入する必要があります。

*3: きめ細かい運用管理を行ないたい場合はWebOTX Administrator を別途購入する必要があります。

*4: Open COBOL Factory21 もしくはMicro Focus COBOLを別途購入する必要があります。

*5: WebOTX VIS Connector もしくはWebOTX OLF/TP Adapter を別途購入する必要があります。Express ではWebOTX VIS Connector を利用できません。

*6: WebOTX Print Kit を別途購入する必要があります。

*7: エントリ登録数が制限されています。制限を越えるエントリ数を登録する場合別途EnterpriseDirectoryServer を購入する必要があります。

3.1.2. Javaランタイム

WebOTX では、次のJava API やその実装、さらには開発基盤やJava API によって提供されるサービスをサポートしています。

3.1.2.1. Java SE Development Kit

WebOTX はJava の開発・実行環境として、Java SE 7に対応しています。
また、WebOTX 製品媒体には、Oracle 社とのライセンス契約によりJava SE 7 をバンドルしています。

最新のJVM バージョンが必要な場合は、次のWeb サイトから入手してください。

http://www.oracle.com/technetwork/java/javase/overview/index.html

3.1.2.2. JDBC

Java プログラムからのリレーショナル型データベースへの標準アクセスインタフェースです。V8.5以降のLinux(x64)版においては、WebOTXのインストール時に、InfoFrame Relational Store用のJDBCドライバを選択してインストールすることができます。WebOTXには、それ以外のJDBCドライバは含まれていません。JDBCドライバが含まれていない場合は、データベースベンダ製品、もしくはJDBC ベンダ製品の、 JDBC ドライバを使用してください。基本的に、 JDBC 2.0 または、JDBC 3.0、JDBC 4.0、JDBC 4.1 の仕様に準拠しているJDBC ドライバであれば、使用することができます。

動作確認済みの製品およびバージョンについては、 [ セットアップガイド > 1. 使用上の条件 ] または提供機能の [ 3.6.3.7. データベースとJDBCドライバの対応バージョン ] をご参照ください。

3.1.3. Java EE

Java Platform, Enterprise Edition (Java EE) は、エンタープライズ・アプリケーションの設計、開発、組み立て、配備の場面においてコンポーネント・ベースのアプローチを提供するアーキテクチャです。

この Java EE アーキテクチャを満足するアプリケーションサーバは、再利用可能なコンポーネントのための多層分散アプリケーション・モデル、柔軟なトランザクション制御と一体化したセキュリティ・モデル、XML ベースのオープン・スタンダードとプロトコルの上に統合されたデータ交換技術によるWeb サービス支援を提供します。

Java EE テクノロジの進化は、これまでより迅速なマーケットへの革新的ビジネスソリューションを提案するだけでなく、特定のアプリケーションサーバ・ベンダの製品やプログラミング・インタフェースに縛られないプラットフォーム非依存のJava EE コンポーネント・ベース型ソリューションももたらします。

Java EE 仕様はWeb とEJB を中心とするバージョン1.2 から始まり、その後非同期型アプリケーション・モデルの提供とベンダ間の相互接続性の解決に取り組んだバージョン1.3、Web サービス技術の標準統合と運用管理の仕組みやインタフェースを一般化したバージョン1.4 へと進化してきました。 Java EE 5では「開発の容易性(EoD: Ease of Development)」を最大のコンセプトとし、配備記述子を代替するアノテーションによるアプリケーション動作時設定の記述や、POJO(Pure Old Java Object)開発を可能にするEJB インタフェースの簡略化、JPA(Java Persistence API)によるオブジェクト永続化などを含んでいます。

最新のJava EE 6では「開発の容易性」をより押し進めています。サーブレットをアノテーションだけ記述できるようになり、煩雑なweb.xmlの記述は不要になりました。インジェクションの共通仕様である CDI (Contexts and Dependency Injection) が導入され、POJOに対してもインジェクションが可能になりました。その他にも、EJBやJPA等のバージョンアップや、JAX-RSによるRESTful Webサービスのサポートなどの強化が行われています。

WebOTX とJava EE との関わりは、Java EE 技術あるいはJava EE という用語が生まれる前に遡ります。 Java EE が誕生する前は、Java EE に含まれる各種仕様が単独で提案されていました。 WebOTX は、当時のEJB 1.0 仕様から対応を始めています。そして、J2EE 1.2 が最初に提案されて以降、一貫してJava EE に準拠したアプリケーションサーバを製品化しています。

3.1.3.1. Java EEアプリケーションサーバのアーキテクチャ

Java EE プラットフォームでは、アプリケーション動作のために多層の分散アプリケーション・モデルを提供します。

アプリケーション・ロジックは、機能によってコンポーネントに分割されます。そして、1つのJava EE アプリケーションを構成する各種コンポーネントが、そのコンポーネントの属す多層化Java EE環境内の特定の層へ応じたマシンにインストールされます。

下の図は、WebOTX におけるアプリケーションサーバのアーキテクチャの概観を表しています。

図3.1.3.1-1

Web コンポーネントは、Web コンテナが位置するWeb 層で動作します。
EJB コンポーネントは、EJB コンテナが位置するビジネス層で動作します。
データベースやレガシーシステム、UDDI などのレジストリサーバ内のソフトウェアは、エンタープライズ情報システム(EIS)層で動作します。

3.1.3.2. コンテナ

コンテナは、Java EE コンポーネントに対してトランザクション管理やセキュリティなどの下層サービスを提供する実行環境です。上の図では、Web コンテナとEJB コンテナの部分が相当します。 2つを合わせてJava EE コンテナと呼ぶ場合もあります。

JSP やサーブレットのようなWeb コンポーネントは、Web コンテナ内で動作します。 WebOTX では、クライアントからのHTTP/S リクエストを受け付けるサーバとして、Web コンテナ内蔵のWeb サーバを提供します。さらに外部のOS ネイティブなHTTP サーバとWeb コンテナを連携させることも可能です。

EJB テクノロジに準じたコンポーネントであるEnterprise Bean は、EJB コンテナ内で動作します。

3.1.3.3. Web サービス

WebOTX ASではJAX-WSとJAX-RPCをサポートしており、SOAPを利用したWebサービスを構築する事ができます。また、JAX-RSを利用する事でRESTful Webサービスの提供も可能です。

アプリケーションはXML レジストリのためのJava API (JAXR) を使ってコーディングすることにより、XML レジストリサーバへアクセスすることができます。

3.1.3.4. アプリケーションサービス

Java EE プラットフォームでは、コンテナがアプリケーションに各種サービスを提供するようにアーキテクチャが設計されています。

ネームサービス

ネームサービスは、JNDI を使用したオブジェクトを名前に結び付けるネーミングとディレクトリに関するサービスです。Java EE アプリケーションは、意図するJNDI 名をルックアップすることにより、JNDI サーバ内にあるオブジェクトの位置を特定できます。

WebOTX のJNDI サーバは、CosNaming サービスを基盤に持ちます。CosNaming とはCORBA 仕様に準拠したネームサービスです。Java EE ではなくCORBAに基づくCORBA アプリケーションに対しては、CosNaming が提供されます。

トランザクションサービス

トランザクションは、それ以上分割できない、不可分な作業単位です。トランザクション管理を担当するサービス基盤は、各作業単位全体が他のプロセスからの干渉を受けずに完了するか、全体を完了できなければ、その単位で実行された処理全てが元に戻るように保証しています。

Java EE アプリケーションに対しては、JTA (Java Transaction API) を提供しています。さらにJava EE プラットフォームには、アプリケーションにトランザクション制御を意識させなくする「コンテナ管理によるトランザクション」も提供されています。

WebOTX におけるトランザクションサービスは、CORBA Transaction Service 仕様に準拠したサービスが下層で支えています。

セキュリティサービス

Java EE プラットフォームでのセキュリティサービスは、Web やEnterprise Bean のコンポーネントへそのアクセス権限を持つユーザによってのみアクセスできるように保証する設計が施されています。

また、JACC(Java Authorization Contract for Containers)により、コンテナはクライアントの識別情報に基づきながら、コンテナの管理下にあるリソースやサービスに対してもアクセスを制限することができます。

3.1.3.5. 外部システムへのアクセス

アプリケーションは、Java EE プラットフォーム内からサーバの外部に位置するシステムへアクセスすることができます。そのシステムの代表的な例がデータベースサーバです。アプリケーションは、リソースと呼ばれる接続オブジェクトを介して、それら外部システムへ接続します。そのリソースを構成する役割は、システム管理者が担当することになります。Java EE プラットフォームでは、次のようなAPI とコンポーネントによって外部システムへアクセスする手段を提供しています。

JDBC

データベース管理システムは、データの格納、構成、検索などを行うための機能を提供しています。ほとんどのビジネス・アプリケーションは、リレーショナルデータベースシステムを用いています。そのようなアプリケーションは、JDBC API 経由でデータベースサーバにアクセスします。

WebOTX は、JDBC 経由によるデータベース接続のために、データベースサーバの違いを抽象化するAPI としてJDBC データソースを提供しています。JDBC データソースはその他にも豊富な機能を揃えています。詳細は [ 3.6.3. JDBC データソース ] で説明されます。

JMS

JMS は非同期にメッセージを配信するための仕様です。Java EE では、バージョン1.3 からアプリケーションサーバへ標準統合されました。JMS によるメッセージング・システムを利用することで、コンポーネントやアプリケーションの間でメッセージを伝達する手段を得られます。メッセージング・クライアントは、他のクライアントにメッセージを送信したり、他のクライアントからメッセージを受信したりすることが可能になります。

WebOTX では、独自のJMS プロバイダを提供しています。詳細は [ 3.6.4. JMS ] で説明されます。

JCA

JCA (Java EE Connector Architecture) は、ERP、CRM、他のレガシーシステムなどの様々な既存のエンタープライズ情報システム (EIS) とJava EE アプリケーションとの間の統合を可能にします。アプリケーションは、コネクタまたはリソースアダプタと呼ばれるポータブルなJava EE コンポーネントを介してEIS にアクセスできます。JCA は、そのようなシステムと対話するためのインフラストラクチャともいえます。

WebOTX では、JMS サーバへの接続用リソースアダプタをバンドルしています。また、NEC のメインフレームACOS へ接続するためのOLF/TP アダプタをオプショナルで製品化しています。

JavaMail

アプリケーションは、JavaMail API を使うことによって電子メールを送受信するために必要なSMTP サーバへの接続を可能にします。JavaMail API は、SMTP の他にもIMAP4、POP3 プロトコルによるアクセス手段も提供しています。

3.1.3.6. サーバ管理

J2EE 1.3 以前のプラットフォームでは、アプリケーションサーバの管理に関わる仕組みが標準化されていませんでした。そのため、各々のサーバベンダは、独自の実装方式によってサーバ管理を実現していました。J2EE 1.4 ではJMXという技術を利用してそれらの枠組みが標準化されました。

WebOTX ASにおいてもJMX という標準仕様に基づきサーバの実行時性能をモニタリングすることができます。さらに、アプリケーションの配備についてもDeployment API というインタフェースが標準化されています。 WebOTX は、標準仕様に基づいた運用管理のためのコマンドとGUI ツールを提供しています。

3.1.4. COM/.NET Framework対応

Microsoft 社のCOM 技術に対応している WebOTX/COM という製品や CORBA ゲートウェイおよび、EJB ゲートウェイを提供しており、COMや.NET Frameworkアプリケーションからシステムに接続することができます。これにより Visual Basic などの言語で容易にアプリケーションを開発することができます。

WebOTX では、Visual Basic のクライアントアプリケーションから CORBA サーバアプリケーションの通信を実現する CORBA ゲートウェイと、Visual Basic のクライアントアプリケーションから EJB サーバアプリケーションの通信を実現する EJB ゲートウェイ機能を提供しています。

3.1.5. ドメイン管理

WebOTX ではシステムをドメインという構成単位で管理を行います。まずはドメインの構成について説明します。

3.1.5.1. ドメインとは

WebOTX の基本的な構成単位をドメインと呼びます。このドメインはJMX 仕様で定義されているドメインに対応します。

ドメインはWebOTX で管理するリソースやサービス群を論理的にグルーピングしています。ドメインは独立して運用され、コンフィグレーション情報など構成情報はドメイン単位で独立したディレクトリに管理されます。

それぞれの業務システムの要件にあわせてドメインを構成することができます。例えば1つのホストで商用環境と評価環境を構築したい場合、そのホスト上に商用のドメインと評価用のドメインを構成させることができます。また稼動、待機構成のクラスタ構成を行いたい場合は、複数のホストで1つのドメインを定義できます。

3.1.5.2. ドメインの構成要素

ドメインを構成するモジュール群について説明します。ドメインは主に、ドメイン情報を管理する運用管理エージェントとアプリケーションサーバとしての機能を提供するサービス群(以下の表で示します)で構成されます。

運用管理エージェントはそのドメイン内で動作するサービスやコンフィグレーションを管理します。またリモートから運用操作が行えるためのインタフェースを外部に提供します。

サービスには次のものを提供しており、そのドメインで必要なサービスをドメイン作成時に指定します。

表3.1.5.2-1 WebOTXが提供するサービス群
サービス名称	Express	Standard	Enterprise
HTTPサーバ	○	○	○
Webコンテナ	○	○(*1)	○(*1)
EJBコンテナ	○	○(*2)	○(*2)
JNDIサービス	○	○	○
JMSサービス	○	○	○
Object Brokerサービス	○	○	○
Transactionサービス	○	○	○
TPモニタ	×	○	○
WatchServer	×	×	○
キャッシュ名前サーバ	×	×	○

*1: Express のWebコンテナは運用管理エージェントのJava VM 内で動作します。 Standard および Enterprise の Webコンテナは運用管理エージェントとは独立したJava VM 上で動作します。ただし従来どおり運用管理エージェントのJava VM 内で動作させることも可能です。

*2: Express のEJBコンテナは運用管理エージェントのJava VM 内で動作します。 Standard および Enterprise のEJBコンテナは運用管理エージェントとは独立したJava VM 上で動作します。

3.1.5.3. ドメインのタイプ

WebOTXでは大きく2つのドメインにタイプ分けしています。

管理ドメイン

WebOTXをインストールした時点で、ホスト単位で1つ作成されます。管理ドメインはそのホスト上で動作するユーザドメインの管理を行います。管理ドメインを通して以下の操作を行うことができます。

ユーザドメインの作成、削除
ユーザドメインの起動、停止
ユーザドメインの一覧取得
ユーザドメインの依存関係の設定

ユーザドメイン

システム構成によってユーザが任意に作成するドメインです。ドメイン作成時に、そのドメイン上で管理するリソースやサービスを任意に指定することができます (WebOTXのエディションにより指定できるリソースやサービスに制限されます)。ユーザドメインでは、実際の業務システムを構成するアプリケーションやサービスが動作します。

図3.1.5.3-1

3.1.5.4. ドメインの構成

業務システムのユーザドメインの構成について説明します。ドメイン構成は大きく次の5つのグループに分割することができます(DBサーバについては省略します)。これらについてそれぞれ独立したドメインに割り当てることも、同一のドメインに割り当てることも可能ですが、基本的な構成について次に説明します。

Expressドメイン
Standard/Enterprise ドメイン
Webサーバドメイン
APサーバドメイン
名前サーバドメイン

Expressドメイン

Expressで動作するサービスを1つのドメインで動作させます。 Java EEアプリケーションシステムを構築する上でもっともシンプルなドメイン構成です。 1台のマシンで全て動作させる場合やWeb層とAP層を分割する必要のない場合は通常この構成となり以下のサービスが起動します。

HTTPサーバ
Webコンテナ
EJBコンテナ
JNDIサービス
JMSサービス
Transactionサービス
Object Brokerサービス

マルチサーバ構成の場合、マシン単位でドメインを1つ作成し負荷分散装置により分散を行います。

図3.1.5.4-1

Standard/Enterpriseドメイン

Standard/Enterpriseで動作するサービスを1つのドメインで動作させます。システムを構築する上でもっともシンプルなドメイン構成です。 1台のマシンで全て動作させる場合やWeb層とAP層を分割する必要のない場合は通常この構成となり以下のサービスが起動します。

HTTPサーバ
Webコンテナ（独立Java VM）
EJBコンテナ（独立Java VM）
JNDIサービス
JMSサービス
Transactionサービス
Object Brokerサービス
TPモニタ

マルチサーバ構成の場合、マシン単位でドメインを1つ作成し負荷分散装置により分散を行います。

図3.1.5.4-2

Webサーバドメイン

Webサーバ層を構成するドメインでは次のサービスが動作します。

HTTPサーバ
Webコンテナ

Webサーバはクラスタ化する場合、基本的にはマルチサーバ負荷分散構成となります。さらに1つのマシンでは1つのWebサーバ、Webコンテナを動作させる構成が基本です。

図3.1.5.4-3

また、パターンによっては1マシン内でWebサーバとWebコンテナが1対nになるような構成も可能です。この場合はそれぞれ(Webサーバ、Webコンテナ)が独立したドメイン構成となります。

図3.1.5.4-4

APサーバドメイン

APサーバ層を構成するドメインでは次のサービスが動作します。

Web/EJBコンテナ

APサーバ層のクラスタとしては負荷分散がメインですが、稼動待機構成(シングルスタンバイ、相互スタンバイ)も用いられ、また業務の特性に応じてマルチシステム構成となるため、柔軟な構成が望まれています。

負荷分散構成:

図3.1.5.4-5

シングルスタンバイ構成:

図3.1.5.4-6

相互スタンバイ構成:

図3.1.5.4-7

マルチシステム構成:

図3.1.5.4-8

名前サーバドメイン

名前サーバ層を構成するドメインでは次のサービスが動作します。

Object Broker名前サーバ
JNDIサーバ

名前サーバ自身は、負荷分散クラスタなどの負荷を分散する構成にする必要はありませんが、基本的にはシステムで1つの存在であるので、 SPOF(Single Point of Failure)とならないための対策が必要となります。また名前サーバ専用にマシンを割り当てる構成は、コスト的に敬遠されるためさまざまな箇所に配置されることが想定されます。

Webサーバに配置
Webサーバ上に配置する場合は、Webサーバと1対1で配置します。各名前サーバには全てのAPサーバの名前情報が格納されるように設定します。 Webサーバ上の名前サーバは、APサーバ負荷分散実装するために、全てのAPサーバ上の情報を持ち、どのWebサーバ上の名前サーバも同一の情報を保持しています。

図3.1.5.4-9
APサーバに配置
APサーバ上に配置する場合は、APサーバのクラスタ構成によって構成が変わります。

負荷分散構成:
負荷分散構成の場合、1マシンに1名前サーバを配置します。 APサーバ負荷分散実装するために、名前サーバ間でレプリケーションを行い、全てのAPサーバ上の情報を格納します。名前サーバは全て同一の情報を保持しています。

図3.1.5.4-10

シングルスタンバイ構成:
シングルスタンバイ構成の場合、稼動系マシンに1名前サーバとなります。異常時にはAPサーバと同様、名前サーバもフェイルオーバします。この場合、フェイルオーバしても登録情報を引き継げるようにする必要があるため、情報を永続化します。

図3.1.5.4-11

相互スタンバイ構成:
相互スタンバイ構成の場合、APサーバドメイン1つにつき1名前サーバとなります。この場合、縮退時には1マシン上に複数の名前サーバが稼動します。

図3.1.5.4-12

マルチシステム構成:
マルチシステム構成の場合、システムごとに名前サーバを配置するか、1つにするかは要件に依存します。通常は1つで問題はありませんが、本番、テスト系のような構成の場合、名前サーバも本番、テスト系で別運用となるため独立して運用できるようにすることが必要です。

図3.1.5.4-13

図3.1.5.4-14

3.2. Web層

アプリケーションサーバでのWeb 層では、World Wide Web 上で活用されるコンテンツやアプリケーションのビジネスロジックを生成します。この章では、WebOTX の機能階層の中で、特にWeb 層に含まれる、 HTTP サーバとWeb コンテナが提供する機能について説明します。

3.2.1. HTTPサーバ

インターネットの普及とともにWorld Wide Web (WWW)技術は急激に進展しています。当初、WWW は情報共有・情報発信を目的とした静的なコンテンツ配布が中心でしたが、今日では顧客との新しいチャネルや企業間取引き、外出する営業マンのアクセスポイントなどの動的なコンテンツを使った業務システムとして利用されています。アプリケーションサーバは、動的コンテンツを効率良く生成・処理する基盤として発展してきました。

従来、企業内の業務システムで多く使われてきたクライアント・サーバシステムはサーバコンピュータの負荷をクライアントにオフロードし、高い操作性を提供するというメリットがありましたが、技術変化が激しい今日では、クライアントのハードウェア・ソフトウェアの頻繁な入れ替えによるTotal Cost of Ownership (TCO) の増大という新たな問題を発生させました。そのため、WWW 技術をクライアント通信に利用する WebComputing をベースとした業務システムの再構築が行われるようになっています。

HTTPサーバは Web システムの中核を成し、クライアント上のWeb ブラウザからHTTP リクエストを受信し応答を返却するソフトウェアです。静的なHTML に対しては単独でWeb サービスを提供することができます。WebOTX では Web サーバとしてJava ベースのHTTP サーバとApache Software Foundation のApache HTTP Server 2.2.27 をバンドルしています。Secure Socket Layer (SSL) 2.0/3.0 およびTransport Layer Security (TLS) 1.0 をサポートしており、インターネットを使った安全な通信を提供します。他にも次に示すWeb サーバを利用することができます。

表3.2.1-1
Web サーバ	Windows	HP-UX	Linux
Microsoft InternetInformation Server (IIS)	7.0, 7.5, 8.0	-	-
Apache HTTP Server	2.2.25 以上	2.2.25 以上	2.2.25 以上

WebOTX が対象とするクライアントは、World Wide Web のブラウザ(以下Web ブラウザと呼びます)のThin クライアント、Web ブラウザ内で動作するApplet クライアント、Web ブラウザと独立して動作するRich クライアントがあります。Rich クライアントでもクライアントアプリケーションの配送管理を容易にするため、 WebOTX (Standard/Enterprise) は、ダウンローダを提供しています。

Web ブラウザはHTTP サーバとHyper Text Transfer Protocol (HTTP) やSecure Sockets Layer (SSL) で暗号化されたHTTPS プロトコルを使って通信を行います。HTTP プロトコルやHTTPS プロトコルでは、 Uniform Resource Locators (URL) を使って、世界で一意のサーバ上の資源にアクセスします。URL は次のフォーマットを持っています。

スキーム://ホストアドレス［:ポート］/ホスト内資源アドレス

スキームはHTTP プロトコルなら「http」、HTTPS プロトコルなら「https」を指定します。

ホストアドレスはIP アドレスまたはホスト名を指定します。ポートはプロトコルごとのポートで既定値として http は80、https は443と決まっています。ホスト内資源アドレスはホスト内で資源を特定するために使用されるもので一般的にはファイルのディレクトリパスを指定します。

ポートを分けることで、1台のサーバマシン上で本番用、テスト用のように複数のWeb サーバを起動することができます。また、既定値以外のポートを使うことで一般の人からは発見しにくいWeb サーバを運用することもできます。逆にApplication Service Provider (ASP) やInternet Service Provider (ISP) のように1台のサーバマシンで複数のホストアドレスを提供したいという考え方があります。数千、数万の企業に対してデータセンタでWeb サーバを提供するとしても、サーバ台数をそれだけ用意するのは困難です。このような場合、仮想IP アドレスを使って、1つのWeb サーバが複数のホストサーバの振りをして動作します。

負荷分散装置を使った場合には別の概念の仮想IP アドレスが出現します。HTTP サーバの可用性を高めるためにも、スケーラビリティを高めるためにもHTTP サーバを複数台用意して負荷分散を行い、ブラウザからは1つのサーバのように見せることは良く行われている技術です。この場合、各HTTP サーバマシンの実際のIP アドレス(実IP)に対して、負荷分散装置が外に向けて見せるIP アドレスを仮想IP アドレスと呼びます。

WebOTX では HTTP サーバとして、Web コンテナに内蔵された Java ベースの HTTP サーバと、Apache Software Foundation の Apache HTTP Server 2.2 をバンドルしています。これらはインストール時の指定により選択することができます。(インストール時のデフォルトはJava ベースの HTTP サーバです。) これらのHTTP サーバはSSL 2.0 および3.0 をサポートしており、インターネットを使った安全な通信を提供します。

他にも次に示す HTTP サーバを利用することができますので、システム要件に合わせてWeb サーバを選択することができます。

表3.2.1-2
HTTPサーバ	Windows	HP-UX	Linux
Microsoft Internet Information Server (IIS)	7.0, 7.5, 8.0	-	-
WebOTX Web Server(右はApacheのバージョン)	2.2.25以上	2.2.25以上	2.2.25以上

3.2.2. Webコンテナ

Web コンテナは、Web アプリケーションである Servlet/JSP を動作させるための実行基盤です。Web アプリケーションは、Web コンテナの提供する各種機能を使って、クライアントからの入力データを解析し動的な HTML を生成するサーバサイドの Java アプリケーションです 2層のモデルでは Web アプリケーションはプレゼンテーション層からアプリケーション層（ビジネスロジック層）までを実現します。3 層モデルではプレゼンテーション層のみを実現します。

WebOTX の Web コンテナは、この Web アプリケーションの実行環境に加えて、Web コンテナの運用管理を行う機能を提供します。 WebOTX の提供する Web コンテナは、Tomcat 7.0 をベースに以下の機能を独自に強化しています。

性能向上
Web コンテナに求められるのは何より性能です。Servlet/JSP の互換性を維持しつつ、可能な限りの性能向上を図っています。
クラスタ対応
トラフィックの増大に対応するために Web サーバマシンをクラスタ化することができます。クラスタ上の Web コンテナ間でセッション情報とセッション情報に格納されたデータの共有を行うことで、セション情報にアクセスする Servlet/JSP をどのクラスタ上でも動作させることができます。
Web 版統合運用管理コンソール
Web ブラウザからドメインの管理ができる運用管理ツールです。次のような操作が行えます。
- Web アプリケーションの管理(状態表示、閉塞、配備、配備解除)
- 統計情報の表示
- ログ、デバッグ情報設定

3.2.2.1. セッション管理

HTTP/HTTPS プロトコルではWeb ブラウザからの要求とサーバからの応答が一組で動作し、明確なセッションという概念がありません。一方、業務システムではクライアントとの複数回の通信の中で状態を変更して業務を遂行していくスタイルが一般的です。そのため HTTP/HTTPS プロトコル上で論理的なセッションを管理する必要性が出てきました。

HTTP/HTTPS プロトコルのセッション管理は、Cookie、URL Rewriting、Hidden TAG を使うのが一般的です。これらは論理セッションであり、解放プロトコルが存在しません。上位でログオフを作る、またはタイムアウトでセッションの消滅を行うことになります。ログオフ操作は永久に行われないかもしれませんので、業務要件に合わせて、タイムアウト時間を設定し、資源の解放漏れがおこらないようにする必要があります。

Web コンテナでは、Web コンテナとしてのセッション管理に Cookie を利用するか、 URL Rewriting を利用するかを選択できます。この選択は、Webコンテナの「運用管理コンソール」でおこないます。Web サーバは、 Web コンテナの設定した Cookie もしくは URL の値を Web ブラウザに引き継ぎ、 Web ブラウザから送信されたデータとともに Cookie もしくは URL の値を Web コンテナに引き渡します。これらの値は Web コンテナ上で動作する Web アプリケーションから参照することもできます。また、Web アプリケーションで独自の ID を設定することもできます。

Web クライアントが携帯電話などの場合、Cookie を処理することができません。この場合には、URL Rewriting を利用するか、Hidden TAG を利用することになります。

3.2.2.2. URL

Servlet/JSP の特定は URL により行われます。業務システムでは静的なメニューページやログインServlet から順番にターゲット業務を行う Servlet へと遷移していくのが一般的です。 WebOTX ではアプリケーション単位の閉塞・閉塞解除機能を提供しています。 Servlet/JSP を動的に置換すると後続の Servlet/JSP との間で矛盾を起こすことがありえますが、この機能を使えば処理中のトランザクションがなくなった時点で、安全に Web アプリケーションの置換を行うことができます。

3.2.2.3. Web サーバのクラスタ化

負荷分散装置 (サーバスイッチ等) を用いて、複数のWeb サーバをクラスタ化し、Web アプリケーションで買い物かごのようにセッション情報を管理するシステムに対応します。Web アプリケーションへの特別なコーディングなしで、Web サーバのクラスタ化に対応ができます。

この場合、Web アプリケーションでセッションオブジェクトに保存する情報は、シリアライズ可能なオブジェクトになります。また、Web アプリケーションが Web サーバのクラスタ化に対応していることを示すために、配備記述子（web.xml）に<distributable>要素の指定をします。

3.2.2.4. 認証 API の利用

通常、BASIC 認証や FORM 認証では、クライアントからユーザ名とパスワードを受け取り、認証処理を行います。しかし、場合によっては、Servlet/JSP のプログラムで認証をするほうが便利なことがあります。

Servlet/JSP のプログラムでユーザ名とパスワードを指定し、認証 API を呼び出すことにより、BASIC 認証および FORM 認証を行うことができます。

3.2.2.5. Web コンテナの機能構造

Web コンテナは、WebOTX の各エディションによって 2 つの異なる機能構造を持っています。
1 つは、Webコンテナが 1 つのJava 仮想マシン上で動作する機能構造で、もう 1 つは、 Web コンテナが WebOTX アプリケーションサーバへのプラグインとして動作する機能構造です。
前者をスタンダードモードで動作する Web コンテナと呼び、後者をアドバンスドモードで動作する Web コンテナと呼んでいます。
WebOTX の各エディションがサポートする Web コンテナの動作モードは表3.2.2.5-1のようになっています。

表3.2.2.5-1
エディション	スタンダードモード	アドバンスドモード
WebOTX Application Server Express	○	－
WebOTX Application Server Standard	○	○
WebOTX Application Server Enterprise	○	○

スタンダードモード

このモードは、Webコンテナを運用管理エージェントの Java VM プロセス(エージェントプロセス)で動作させるもので、Java EE 技術をベースにした Web ベースのシステムを迅速に開発・運用することができます。 EJB を利用しない Web アプリケーションを動作させるのであれば、アドバンスドモードよりも高速に動作します。また、メモリ消費量も削減されます。その反面、システム障害に対する多重化のような高度な機能を持ちません。

アドバンスドモード

STDENT

このモードは、Web コンテナを TP モニタ内に配置して複数の Java VM プロセスで多重化し TPモニタで制御するもので、高い信頼性が要求される基幹業務システムを構築することができます。 Web アプリケーションから EJB を利用する形態の Java EE アプリケーションであれば、 Web コンテナと EJB コンテナが同一の Java VM 上で動作するので、高速に動作します。また、アドバンスドモードでは、WebOTX システムを載せたマシンを複数台クラスタ構成で構築したより高信頼・高可用性のある運用をサポートします。

スタンダードモードとアドバンスドモードでは、サポートするWebサーバやOSに違いがあります。詳しくは、表3.2.2.5-2を参照してください。

Caution
アドバンスドモードでは、WebOTX Webサーバと Apache HTTP Server のみサポートしています。

表3.2.2.5-2
Webコンテナの動作モード	Webサーバ	Windows (x86)	Windows (x64)	Linux (x86)	Linux (x64)	HP-UX (IPF)
スタンダードモード	WebOTX Webサーバ 2.2	○	○	○	○	○
	Apache HTTP Server 2.2	○	○	○	○	○
	Microsoft Internet Information Services (IIS)	○	○	-	-	-

アドバンスドモード	WebOTX Webサーバ 2.2	○	○	○	○	○
アドバンスドモード	Apache HTTP Server 2.2	○	○	○	○	○

※ 表中の記号の意味は「○」はサポートする、「-」はサポートしない

3.3. AP層

アプリケーションサーバでのビジネス層では、アプリケーションの種別に応じた固有のビジネスロジックに対応し、トランザクション管理、スレッド/プロセス管理、アクセス制御管理などのシステムレベルのサービスを提供します。WebOTX では、Java ベースのEJB コンテナからJava、C/C++言語で書かれた CORBA コンポーネントを扱うハイエンドな動作環境までを提供しています。CORBA コンポーネントは、 WebOTX Enterprise で利用できます。EJB コンテナは、それらのエディションに加えて、 Express から利用可能です。

この層に位置するEJB コンテナは、EIS リソースを使用してWeb 層のコンポーネントやスタンドアロン型アプリケーション・クライアントからの要求にサービスするEnterprise Bean コンポーネントをホストします。この章では、WebOTX のコンポーネント動作サービス機能階層の中で、特にEJB コンテナが提供する機能について説明します。

3.3.1. EJBコンテナ

EJB コンテナは3層モデルにおいてビジネスロジックをEnterprise Java Beans (EJB) アーキテクチャに従って実装した場合のコンテナ処理を行います。アプリケーションはセッション制御やトランザクション制御、セキュリティ制御などをなるべく意識しないで、ビジネスロジックに注力することが望まれます。 EJB コンテナはこれらの制御をアプリケーション(Enterprise Bean と呼ぶ)に代わって実現します。 WebOTX ASではEJB3.1 仕様に準拠したEJB コンテナを提供しています。

EJB コンテナには、Enterprise Bean コンポーネントのトランザクション管理やライフサイクル管理、セキュリティ管理などをサポートする機能があります。さらに、JDBC データソースを介したデータベースサーバへのアクセス、JCA リソースアダプタを介したエンタープライズ情報システムへのアクセスなどを提供します。

3.3.1.1. Enterprise Beanコンポーネント

EJB アーキテクチャは、エンタープライズ・アプリケーションのビジネスロジックを含むコンポーネントを開発しEJB コンテナに配備するためのサーバサイド技術です。このコンポーネントは、拡張性に富み、トランザクション型で、複数ユーザに対するセキュリティが適用されます。これらに適用するサービス提供元がEJB コンテナにあたります。

Enterprise Bean には、Session Bean とEntity Bean、メッセージ・ドリブンBean の3種類があります。Session Bean とEntity Bean には、ホームインタフェースとコンポーネントインタフェースがあります。コンポーネントインタフェースは、EJB 1.1 以前の仕様ではリモートインタフェースと呼ばれていました。ホームインタフェースは、Bean の生成、検索、削除などのメソッドを定義します。コンポーネントインタフェースは、Bean のビジネスロジックを定義します。メッセージ・ドリブンBean には、2つのインタフェースはありません。

Session Bean は、クライアントに代わってサービスを提供するために作成され、通常は単一のクライアント－サーバ・セッションの期間中にのみ生存します。Session Bean はトランザクション型にすることができますが、EJB コンテナがダウンすると回復不能です。

Session Bean には、ステートレスのものと、複数のメソッドやトランザクション間で会話状態を維持できるステートフルのタイプがあります。状態維持のためのオブジェクト管理は、EJB コンテナが行いますが、オブジェクト自体の永続データは、Session Bean 自身が管理する必要があります。

Entity Bean は、データストア内で維持されるデータを表した永続化オブジェクトです。Entity Bean は自身で永続性を管理するか、その機能をEJB コンテナに委譲するかを選択できます。

Entity Bean は、プライマリキーで識別されます。たとえEJB コンテナがダウンしてもEntity Bean オブジェクトや、そのプライマリキー、リモート・リファレンスは残ります。

EJB 2.0 から追加されたメッセージ・ドリブンBean によって、クライアントが非同期でビジネスロジックにアクセスできようになりました。メッセージ・ドリブンBean は、待機しているJMS のキューやトピックから受信した非同期メッセージによって初めてアクティブになります。クライアントは、直接メッセージ・ドリブンBean にアクセスせず、その代わりに、メッセージをJMS サーバにキューやトピックとして送信します。

EJB コンテナには、Enterprise Bean の生成や、他のアプリケーション・コンポーネントがEnterprise Bean にアクセスできるようにネーミング・サービスへBean をバインドしたり、許可されたクライアントだけがEnterprise Bean にアクセスすることを保証したり、Bean の状態を永続化領域に保存したり、Bean インスタンスをキャッシュしたり、必要に応じてBean インスタンスを活性化、非活性化する責任があります。

3.3.1.2. EJBコンテナのサービス

EJBコンテナは、全てのコンポーネントにJava SE の API を提供します。それに加えて、Java EE の API も使用できます。これらのAPの他、アプリケーション・プログラミングが簡素化でき、アプリケーション間のカスタマイズを可能にさせるサービスも用意されています。

ネーミング・サービス

ネーミング・サービスは、アプリケーション・クライアントやEnterprise Bean、Web コンポーネントにJNDI ネーミング環境へのアクセスを提供します。このネーミング環境では、コンポーネントのソースコードを変更することなくコンポーネントをカスタマイズすることができます。EJB コンテナは、コンポーネントの実行環境を実装し、これをコンポーネントにJNDI ネーミング・コンテキストとして提供します。

コンポーネントでは、JTA UserTransaction オブジェクトのようなシステム提供オブジェクトと、EJB 参照、環境エントリ、JDBC データソースやメール送信などのユーザ定義オブジェクトの名前を指定してネーミング・サービスにアクセスできます。EJB コンテナは、そのアクセスに備えて名前サーバに定義オブジェクトをバインドしておく役割を持ちます。

ユーザ定義オブジェクトは、「java:comp/env」という名前空間の先に格納されます。この下には、JNDI サービスによってアプリケーション毎にサブコンテキストが割り当てられます。これにより、たとえ異なるアプリケーションで同一の登録名が与えられていても、それらが実際の登録時に衝突することなくアプリケーション間の独立性が維持できます。

JNDI サービスに関する詳細機能は、JNDIを参照してください。

トランザクションサービス

アプリケーションはトランザクションにより、それ以上分割できない一連の作業ユニットに分割されます。トランザクションをサポートするシステムでは、各ユニット全体は他のプロセスからの干渉を受けずに完了することが保証されます。ユニットは、全体を完了できる場合はコミットされます。全体を完了できなければ、そのユニットで実行された処理全体がシステムによって元に戻されます(ロールバック)。

Enterprise Bean では、Bean 管理とコンテナ管理という2つのトランザクション境界設定方式が用意されています。Bean 管理による場合は、Bean プログラム自身が全てのトランザクション管理工程をコード化しなければなりません。一方、コンテナ管理による場合は、EJB コンテナが配備時のトランザクション属性に基づいて管理します。コンテナが管理する範囲は、トランザクションの開始と終了処理だけでなく、トランザクショナルなオブジェクトの寿命全体を通じてトランザクションコンテキストを維持します。これにより、分散環境におけるトランザクションの場合に、コンポーネント供給者の責任分担とタスクが大幅に簡素化されます。

トランザクション属性は、Enterprise Bean がコンテナ管理によるトランザクション境界設定を使うBean のメソッドに関連付けられた値です。Bean のトランザクション処理過程を最適化するために、メソッドごとに別の属性を与えることができます。

Required
クライアントがトランザクション中であるとき、そのトランザクションでメソッドを実行します。
クライアントがトランザクション中でないとき、新たにトランザクションを開始してメソッドを実行し、メソッドの実行が終了したら、開始したトランザクションをコミットします。
RequiresNew
クライアントがトランザクション中であるとき、コンテナはメソッドを実行する前に、クライアントのトランザクションを中断させ、新たにトランザクションを開始してメソッドを実行します。メソッドの実行が終了したら、開始したトランザクションをコミットして、中断しているクライアントのトランザクションを復帰させます。
クライアントがトランザクション中でないとき、新たにトランザクションを開始してメソッドを実行し、メソッドの実行が終了したら、開始したトランザクションをコミットします (Required と同様) 。
Mandatory
クライアントがトランザクション中であるとき、そのトランザクションでメソッドを実行します(Required と同様)。
クライアントがトランザクション中でないとき、コンテナはクライアントに対し、TransactionRequiredException 例外を送出します。
NotSupported
クライアントがトランザクション中であるとき、コンテナはメソッドを実行する前に、クライアントのトランザクションを中断させ、トランザクションなしでメソッドを実行します。メソッドの実行が終了したら、中断しているクライアントのトランザクションを復帰させます。
クライアントがトランザクション中でないとき、そのままトランザクションなしでメソッドが実行されます。
Supports
クライアントがトランザクション中であるとき、そのトランザクションでメソッドを実行します (Required と同様)。
クライアントがトランザクション中でないとき、そのままトランザクションなしでメソッドが実行されます(NotSupported と同様)。
Never
クライアントがトランザクション中であるとき、コンテナはRemoteException 例外を送出します。
クライアントがトランザクション中でないとき、そのままトランザクションなしでメソッドが実行されます(NotSupported と同様)。

トランザクションサービス自身に関する詳細機能は、JTAとトランザクションサービスを参照してください。

セキュリティサービス

Java EE プラットフォームのセキュリティサービスは、リソースがその使用権限を持つユーザにのみアクセスされることを保証するように設計されています。アクセス制御は、認証と承認のステップに分かれています。

EJB コンテナには、宣言とプログラムによる2種類のセキュリティ方式が用意されています。宣言によるセキュリティは、コンポーネント内に含まれる配備記述子という実行時属性によって指定されます。プログラムによるセキュリティは、プログラム内でアクセスされるセキュリティ機構を指します。EJB 仕様では、その標準API を用意しています。

アクセス制御のステップのうちの認証は、通常、Web コンテナ側のHTTP 基本認証やフォームベース認証などを使用します。認証対象は、ユーザ名などのプリンシパルとなります。EJB コンテナを認証する方法はありませんが、Web からEJB にアクセスする場合、Web コンテナで認証されたプリシパルがEJB コンテナに伝播されます。EJB コンテナは、渡されたプリンシパルが呼び出されたメソッドを起動可能であるかを検査します。承認は、セキュリティ・ロールの概念に基づいています。ロールとは運用者が定義する論理的なユーザ・グループです。ロールは、配備記述子内のプリシパルにマッピングされます。Enterprise Bean の各メソッドに対しては、呼出し元が属するロールを関係付けることが可能です。

3.3.1.3. 通信技術

クライアント－サーバ間や、各種サーバに収容されている共用オブジェクト間の通信機構としてOMG (Object Management Group) プロトコルをサポートしています。このプロトコルを使用すると、EJB コンテナに収容されたオブジェクトと、CORBA 技術を使用して開発されたリモート・オブジェクトが相互にアクセスできます。その主要な通信サービスがRMI-IIOP です。

RMI-IIOP は、IIOP を介したRMI API の実装です。RMI-IIOP を使用すると、アプリケーションがJava プログラミング言語でリモート・オブジェクトにアクセスできます。コンテナ間のIIOP リモート呼び出しでは、セキュリティを必要とする場合があります。Java EE 仕様では、RMI-IIOP を介して行われる安全な呼び出しのために、CORBA 仕様の一部である「CSIv2 (Common Secure Interoperability)」プロトコルをサポートします。CSIv2 では、メッセージの一貫性や機密性の保護や、SSL/TLS などの利用した認証に対応しています。

これらの通信技術は、WebOTX Object Broker という名前のCORBA 製品を用いています。

3.3.1.4. WebOTX ASのEJBコンテナの機能構造

EJB コンテナは、WebOTX エディションによって2つの異なる機能構造となっています。1つは、Express で提供する1つのJava 仮想マシン上で動作する単独EJB サーバです。もう1つは、Standard/Enterprise で提供するWebOTX アプリケーションサーバへのプラグインとしての構造です。

Express のEJB コンテナ

このエディションでは、性能重視型としてStandard/Enterprise よりも軽量なアーキテクチャになっています。また、メモリ消費量も削減されます。その反面、システム障害に対する多重化のような高度な機能を持ちません。また、実行状態のモニタリングは、Standard/Enterprise よりも対象項目が少ないものとなっています。以下に、Express 全体におけるEJB コンテナのシステムを図示します。

図3.3.1.4-1

Standard/Enterprise のEJB コンテナ

このエディションでは、信頼性重視型として高度な運用環境と連携します。さらに、堅牢な実行環境の上層に位置することにより、大規模システムにも対応、拡張できます。以下に、Standard/Enterprise におけるEJB コンテナの関係を図示します。

図3.3.1.4-2

実行時の特徴として、マルチプロセス動作が可能になります。

Standard/Enterprise では、1つのEJB コンポーネントを複数プロセス上で動作させることができます。このとき、クライアントからアクセスされるインスタンスの種類によってオブジェクトとプロセスのマッピングが異なります。

ホームインタフェースとステートレスSession Bean に対するアクセスは、そのEJB が動作している任意のプロセスにマッピングされます。つまりメソッド呼出しごとに処理を行うプロセスが変わります。これにより、メソッド呼び出しが複数プロセスに分散されます。
ステートフル Session Bean とEntity Bean の場合に対するアクセスは、インスタンスが固有の情報をもつため、特定のプロセスにマッピングされます。つまりメソッド呼出しごとに処理を行うプロセスが変わることはありません。異なるプロセス上で実行させるにはホームインタフェースからコンポーネントインタフェースの参照をcreate メソッドやファインダーメソッドで再取得する必要があります。

3.3.1.5. EJBコンテナの付加価値機能

WebOTX ASのEJB コンテナはEJB 3.1 仕様の機能を網羅しています。さらに付加価値機能として、下記の機能を提供しています。

Bean インスタンスプールとキャッシュ
コンカレンシー制御
トランザクションコミットオプション

Bean インスタンスプールとキャッシュ

プールとキャッシュの機能

プールとは、複数のBean インスタンスをコンテナが制御し、複数のクライアントからのリクエストを効率的に処理するためにBean インスタンスが配置されるメモリ領域を指します。プールにはクライアントからのリクエストに対してサービスを提供するために、全てのリクエストごとにBean をインスタンス化し、放棄するオーバーヘッドを軽減させる目的があります。

一方、キャッシュとは、クライアントに迅速なサービスを提供するために特定のID を保持したBean インスタンスが配置されるメモリ領域を指します。クライアントのリクエストにより生成されたBean インスタンスはキャッシュに常駐し、アクセスを高速化させる目的があります。

EJB の種類とプール、キャッシュの関係

プールとキャッシュはEJB の種類によって、そのBean の性質から使用の可否が決まっています。

表3.3.1.5-1
	ステートレスセッションBean	ステートフルセッションBean	エンティティBean	メッセージ・ドリブンBean
プール	○	-	○	○
キャッシュ	-	○	○	-

コンカレンシー制御 (CMP Entity Bean のみ)

複数トランザクションが稼動する環境でリソースに関するロックを取得する方法はコンカレンシー制御と呼ばれます。コンカレンシー制御には、ペシミスティック・ロック(悲観的排他)とオプティミスティック・ロック(楽観的排他)の2種類があります。WebOTX では、この2つの制御方法をサポートしています。

ロックの違い

ペシミスティック・ロック
ペシミスティック・ロックは、「自分が操作している情報は他の人も操作する可能性がある」という悲観的な視点に立っており、トランザクション開始時に排他ロックを獲得し、それをトランザクション終了時まで保持する排他方法です。つまり、ロックを獲得したアプリケーションのみがその行にアクセスすることができ、その行を更新したい他のアプリケーションは待たされることになります。
オプティミスティック・ロック
オプティミスティック・ロックは、「自分が操作している情報は他の人が操作する可能性が低い」という楽観的な視点に立っており、更新時にリソースに変更がないことを確認し、変更がなければ排他ロックを獲得してリソースを更新し、変更があればアプリケーションにエラーを返す排他方法です。データベースから値を読み取るだけであれば他のアプリケーションに影響を与えないため、ロック待ちを解消できるという利点があります。

トランザクションコミットオプション (CMP Entity Bean のみ)

EJB 2.1 仕様ではトランザクションコミットオプションを3つ定義しています。これらは、コミットオプションA・コミットオプションB・コミットオプションC と呼ばれています。WebOTX では、コミットオプションB とC をサポートしています。

コミットオプションB
Bean インスタンスはキャッシュに保持され、プライマリキーは関連付けられていますが永続化フィールド値は関連付けされておらず、データベースとの同期が取られていない状態です。クライアントがビジネスメソッドを呼び出したとき、EJB コンテナは対応する Bean がキャッシュに存在するかどうかプライマリキーを用いて確認を行います。キャッシュに残存していればそのキャッシュされた Bean をそのまま再利用し、永続化フィールド値とデータベースの同期を取るためにキャッシュされたBean のejbLoad()が呼び出されます。もしキャッシュに残存していなければ、コミットオプションC 同様にBean インスタンスをプールから推移し、プライマリキーの関連付けから行われます。
コミットオプションC
キャッシュ領域を利用しないため、Bean インスタンスは常にプールで待機しています。そのため、クライアントからビジネスメソッドが呼び出された場合は、まずejbActivate()が呼び出されBean インスタンスにプライマリキーが関連付けられます。その後、 ejbLoad()によりBean インスタンスにプライマリキー以外の永続化フィールドとデータベースとの同期が取られます。また、クライアントからの呼び出しが終わるとBean に関連付けられたプライマリキーが解放され、Bean インスタンスはプールへ戻されます。

3.4. TPモニタ

業務システムの運用時に重要となるのは、システムの安定稼動です。特にインターネット業務システムでは負荷の予測が困難なため、過負荷時にも安定して動作できるアプリケーションの実行環境が求められます。

WebOTXはメインフレームで培われたオンライントランザクション処理 (OLTP) 技術を取り込んだアプリケーションサーバです。 OLTP技術により、CPU、メモリなどのコンピュータ資源に対し、大量に発生するトランザクション要求を効率良く割り当て、高い並列性・独立性を保ちながら処理することができます。またOLTP技術によってシステムの安定動作も実現しており、障害の検出や局所化、デッドロック発生時の再実行などのリカバリを実現しています。

インターネットで発生する想像を超えた負荷に対し、システムを恒久的に安定動作させることは困難であり、最終的にはCPU、メモリ、サーバ、ネットワークなどのハードウェアの増設が必要になります。しかし、一般にハードウェアの増設は短期間で完了するものではないため、その間システムが不安定な状態では業務システムとして問題です。
WebOTXでは、トランザクション毎の優先度付けと流量制御により、資源の枯渇を防ぎながら重要な業務を過負荷環境下でも安定して動作させることができます。さらに不要な業務を完全に閉塞することで、重要業務以外の負荷を無くすこともできます。

高負荷に対応するためにも、業務の実行基盤は高性能であることが求められます。 WebOTXは世界最高水準の高速動作が可能なObject Request Broker(ORB)コアを採用しており、マルチスレッドやコネクションプーリング、ローカルスタブ(分散オブジェクトのプロセス内呼び出し)により、高性能なアプリケーションの実行環境を提供しています。

WebOTXは、WebサーバやWebアプリケーションサーバで多く使われている負荷分散型クラスタとメインフレームなどの業務システムで使われているフェイルオーバ型クラスタをサポートしています。
負荷分散型クラスタは同一の構成のサーバ台数を増加することで簡単にアプリケーションサーバの可用性を高められ、性能もネットワークや共有リソースの限界まで拡張できますが、多数のサーバハードウェアを構成することでデータベースなどの共用リソースの障害発生確率が高くなるため、業務やアプリケーションで特定のデータ(レコード)へのアクセスの集中を避ける必要があります。
一方、フェイルオーバ型クラスタは集中してアクセスされるデータに対して障害発生確率を低く抑えることができますが、フェイルオーバ発生時の切り替え時間中はサービスを停止または保留することになります。
WebOTXでは、業務特性に応じてこれらを最適に組み合わせてシステムを構築することができます。

WebOTXでは、システムを安定稼動させるためにメインフレームで培われたOLTP技術をStandard/Enterpriseの各エディションに取り込んでいます。これにより、サーバのコンピュータ資源(CPU、メモリ)を効率良く利用でき、一時的なソフトウェア障害に対してもサービス全体を停止することなく安定してサービスを継続できるようにしています。
また、Expressエディションでは、サーバを並列して安定稼動を図るスケールアウトの考え方でシステム構築する構成を想定して、システムの軽量化のためにOLTP機能を一部だけ取り込んでいます。
ここではWebOTXのStandard/Enterpriseの各エディションが提供するOLTP機能について説明します。

3.4.1. アプリケーションの構成

WebOTXでは、OLTP技術を取り込んだTPモニタにより、アプリケーションサーバ上で動作するアプリケーションが管理されます。アプリケーションは、以降で説明するTPシステム、アプリケーショングループ、プロセスグループの単位でグルーピングされて、TPモニタではこれら構成単位毎に起動、停止などの運用制御や状態監視、障害リカバリを行います。

3.4.1.1. TP システム

TPシステムはドメイン単位で構成され、複数の業務アプリケーションを管理します。マルチドメイン構成では1つのマシン上に複数のTPシステムを起動させることができ、クラスタ運用ではダウンしたサーバのシステムをそのまま稼働中のバックアップサーバに引き継ぐことができます。

1つのマシン上に作成できるTPシステムの最大数はプラットフォームによって異なり、以下がそれぞれの環境における最大値となります。

表3.4.1.1-1
OS	最大システム数
Windows	20
HP-UX	105
Linux	105
Solaris	105

3.4.1.2. アプリケーショングループ

アプリケーショングループとは、開始・終了などの運用を共にするアプリケーション群をグルーピングしたものです。例えば、「受発注業務」「在庫数管理業務」といったような業務毎にツリーを分けて管理するといった用途に用います。こうすることで「受発注業務」は10時から17時まで動作させその後は停止させる、「在庫数管理業務」は24時間動作させる、といったアプリケーショングループ単位での独立した運用が行えるようになります。

3.4.1.3. プロセスグループ

プロセスグループとは、ある特定のサービスを提供するプロセス群です。同一のプロセスグループに登録されているコンポーネントは同一のプロセス上でロードされます。 WebOTXはビジネスロジックを記述した1つまたは複数のコンポーネントをプロセスグループに登録し、プロセスとして実行します。 WebOTXでは、プロセスグループ単位に実行多重度(プロセス数、スレッド数) などを設定することができます。

3.4.1.4. モジュール(コンポーネント)

モジュール(コンポーネント)とは、アプリケーションのモジュールファイルを指します。 C++で作られたCORBAアプリケーションの場合はdllファイルやsoファイルなどのダイナミックリンクライブラリ、 Javaの場合はjarなどのJavaアーカイブファイル、 Java EEアプリケーションの場合はearアーカイブファイルを指します。 WebOTXでは、これらのモジュール単位にアプリケーションとして配備を行ないます。

3.4.1.5. オブジェクト(インタフェース)

オブジェクトとは、CORBAやEJBのインタフェースを実装した実行オブジェクトです。 CORBAアプリケーションの場合はIDLで記述したインタフェース単位にオブジェクトが生成され、EJBの場合は各Bean単位でオブジェクトが生成されます。

3.4.1.6. オペレーション

オペレーションとは、サーバアプリケーションのオブジェクトで実装されたクライアントから呼び出し可能なサービスであり、CORBAアプリケーションの場合、IDLファイルで定義したoperation、 C++やJavaアプリケーションではクライアントから参照できるpublicクラスメンバ関数、EJBの場合はHome/Remoteインタフェースで実装したpublicメソッドになります。これらのオペレーションは、クライアントからのオペレーションコールにより実行されます。

3.4.1.7. 共有コンポーネント

複数のコンポーネント間で共有するライブラリを共有コンポーネントといい、共有コンポーネントとして登録されたライブラリやCORBAインタフェースファイル(ifファイル)は全てのコンポーネントから参照が可能となります。
WebOTXではライブラリパスやクラスパスなどの設定を自動で行なうため、共有コンポーネントを参照するための設定を行なわずに使用することができます。ただし共有コンポーネントは複数のコンポーネントから参照されるため、置換時には利用している全てのコンポーネントが停止している必要があります。
以下に共有コンポーネントとして登録できるファイル一覧を示します。

モジュールファイル
Javaの場合はjarとしてアーカイブされたモジュール (EJBからも参照可能)
C++の場合は共有ライブラリとして作成されたモジュール (「.dll」、「.so」)
CORBAインタフェースファイル
複数のコンポーネントが共通して利用するCORBAインタフェースファイル (.if)
CORBA常駐オブジェクト
常駐オブジェクトとして作成されたモジュールファイル

3.4.1.8. 常駐オブジェクト

サーバオブジェクトとは別に事前に生成することができるオブジェクトを常駐オブジェクトといいます。 WebOTXでは、オペレーションの呼び出しタイミングなどのコールバックルーチンを定義した特別なインタフェースをもつライブラリを常駐オブジェクトとして登録することができます。
常駐オブジェクトはWebOTXが提供するAPIで全てのモジュールから参照することが可能で、プロセスのスレッド初期化時にスレッドに対して1つ作成されるため、各コンポーネントで共通で利用するリソースなどの初期化処理を行うことが可能です。
常駐オブジェクトが実装可能なコールバックルーチンは次のとおりです。

オペレーション開始時
オペレーション正常終了時
オペレーション異常終了時
例外発生時

3.4.2. アプリケーション提供機能

3.4.2.1. ステートレス・ステートフル

一部のサーバアプリケーションでは、オブジェクト内で状態を保持するかどうかを指定することができます。状態を保持するオブジェクトをステートフルといい、保持しないオブジェクトをステートレスといいます。

ステートフル:
ステートフルのオブジェクトでは、オブジェクトのインスタンスはクライアントからの処理要求(ファクトリオブジェクトのオブジェクト生成要求)時に初めて生成され、オブジェクトが要求を出したクライアントと1対1にマッピングされます。以降の同一のクライアントから要求は、マッピングされたインスタンスで処理することになります。

ステートレス:
ステートレスのオブジェクトでは、アプリケーションが動作するプロセスの起動時にオブジェクトのインスタンスを一度に生成してプールしておきます。プールされたインスタンスはオペレーションの処理が終了しても消滅せず、プロセス終了時に消滅します。そのため、2度目以降のオペレーション呼び出しでは生成のオーバーヘッドがなくスループットをあげることができます。

WebOTXでは、CORBAアプリケーションに対してその特性に応じてステートレス、ステートフルを設定することができます。ただしステートフルなアプリケーションはクライアント単位でオブジェクトが生成されるため、消費リソースやレスポンス面でステートレスより劣ります。そのため、できるだけアプリケーションはステートレスで作成することを推奨します。
また、EJBアプリケーションはBeanの種類によってステートレス、ステートフルが決定されるため、変更することはできません。

表3.4.2.1-1
Bean の種類	オブジェクト	ステート
ステートレスSession Bean	home	ステートレス
ステートレスSession Bean	remote	ステートレス
ステートフルSession Bean	home	ステートレス
ステートフルSession Bean	remote	ステートフル
Entity Bean	home	ステートレス
Entity Bean	remote	ステートフル
メッセージ・ドリブンBean	-	ステートレス
シングルトンSession Bean	home	ステートレス
シングルトンSession Bean	remote	ステートレス

3.4.2.2. アプリケーションの動的配備

WebOTXではアプリケーションをコンポーネント単位で動的に登録、変更、削除することができます。また、WebOTX V6以降ではCORBAアプリケーションの動的置換で以下の移行期間を設定できます。

下図にあるように、従来は旧コンポーネントの停止・削除後に新コンポーネントの登録・起動を行なっていましたが、この方法では以下の問題点がありました。

旧コンポーネントの停止から新コンポーネントの起動までサービスの停止時間がある。
クラスタなどで複数のサーバにまたがってアプリケーションが存在する構成では、置換後に旧コンポーネントが利用できないことによって新旧のアプリケーションの混在が発生し想定外の状態になる危険性がある。

これらの問題を回避するために、旧コンポーネントと新コンポーネントが共存可能な移行期間が設定できます。この移行期間中は旧コンポーネント、新コンポーネントのどちらも呼び出すことが可能となり、全てのクライアントで旧コンポーネントの利用が終了した段階で、旧コンポーネントを削除できます。

図3.4.2.2-1

3.4.2.3. プロセスグループの設定の動的変更

プロセスの再起動が必要な設定項目を変更したときに、運用によってはプロセスが停止できず、設定を反映することができないことがあります。本機能ではこのような場合に、新設定を反映したプロセスを起動し、新設定のプロセスが起動完了となった時点で旧設定プロセスを停止することで、プロセスグループの設定を動的に反映できます。設定については [ ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.1. TPシステム > 7.1.7. 設定詳細 > 7.1.7.10. プロセスグループの設定の動的変更 ] を参照してください。

3.4.2.4. 予備スレッドの事前生成と活性化

プロセスグループ起動時に予備スレッドを起動しておき、必要に応じて予備スレッドを実行可能な状態にすることにより、Transaction負荷が高い状況に対応することができます。設定については [ ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.1. TPシステム > 7.1.7. 設定詳細 > 7.1.7.11. 予備スレッドの事前生成と活性化 ] を参照してください。

3.4.2.5. アプリケーション初期トランザクション

WebOTXでは、サーバアプリケーション起動前に複数のプロセスグループ間で利用するグローバルデータなどの初期化を行うアプリケーション初期トランザクションを定義できます。アプリケーション初期トランザクションは、アプリケーショングループ起動時に配下のプロセスグループが起動する前に呼び出されます。

3.4.2.6. プロセス間での情報共有

プロセス共有プロパティを使ってサーバアプリケーションのプロセス間で情報を引き継ぎ、共有を行うことができます。プロセス共有プロパティは、プロセス間で共有するデータを管理するために使用する機能で、一般的にいう「共有メモリ」と同様の機能です。 WebOTXではプロパティの作成、削除、排他処理を内部で行なうため、サーバアプリケーションでは共有プロパティを操作するためのAPIを使うだけで、プロパティの設定、取得ができます。

3.4.2.7. 名前サービスへのリファレンス登録

WebOTXのCORBAアプリケーションではクライアントは名前サービスを利用してサーバアプリケーションのオブジェクトリファレンスを取得しますが、オブジェクトリファレンスの名前サービスへの登録名はインタフェース毎に任意に設定することができます。

また、WebOTXではオブジェクトリファレンスの名前サービスへの登録、削除の契機をサーバアプリケーションの起動、停止にあわせる方式(一時的登録)と永続的に登録する方式(永続的登録)から選択できます。
ただしEJBアプリケーションではJNDI名から登録する名前が決定されるため、配備を行なうと自動的に設定が行なわれます。

登録する名前の設定

CORBAアプリケーションの名前サービスへの登録名はcorbaname形式のURLで複数設定することができるので、登録する名前サーバを分散させることも、1つの名前サーバに複数の名前で登録することもできます。また、インタオペラブル名前サービスをサポートする他社の名前サーバに対しての登録も可能です。

リファレンスの登録契機

WebOTXにおけるオブジェクトリファレンスの名前サーバへの登録契機は、以下の2種類をサポートしています。

アプリケーションと同期して登録、削除(一時的登録)
サーバアプリケーションの起動時にオブジェクトリファレンスを登録し、終了時に削除します。
アプリケーションとは独立して、永続的に登録(永続的登録)
サーバアプリケーションの起動、停止とは独立して、永続的にオブジェクトリファレンスを登録します。登録は統合運用管理ツールもしくはコマンドを用いて行います。WebOTX V8.2以降ではこちらが既定値となっています。

表3.4.2.7-1
	一時的登録	永続的登録
名前サーバへのオブジェクトリファレンス登録/削除	名前サーバへの登録はサーバアプリケーション起動時に行われるため、WebOTXサービス起動時には全アプリケーションの登録処理で一時的にAPサーバ、名前サーバの負荷が高くなります。	名前サーバへの登録はサーバアプリケーションの状態に関係なく行われているため、WebOTXサービス起動時には登録の負荷はありません。
サーバアプリケーション未起動時のクライアント動作	名前サーバにオブジェクトリファレンスが登録されていないため、クライアントでは名前サーバからオブジェクトを取得できないエラーとなります。取得済みのオブジェクトを利用した場合は、呼び出しを行ったときにエラーとなります。	名前サーバからオブジェクトリファレンスを取得できるため、クライアントから呼び出しを行ったときにエラーとなります。
マルチサーバ構成での負荷分散	名前サーバのラウンドロビン負荷分散が利用できます。この場合クライアントが名前サーバにアクセスする契機でアクセスするAPサーバが振り分けられ、以降そのオブジェクトを利用する限り同一サーバにアクセスします。	オペレーション呼び出し時のラウンドロビン負荷分散が利用できます。ただし、クライアントがオペレーションを呼び出す度にAPサーバが振り分けられるため、オブジェクトに状態を保持し複数のオペレーションにまたがって値を参照・更新する(ステートフル)構成では利用できません。

CORBAアプリケーションの自動名前登録

配備時に設定することにより自動で名前の登録ができます。これにより、CORBAアプリケーションで名前サーバへのオブジェクトリファレンスの登録を「永続的に扱う」場合に、配備後に手動で名前登録を行う必要がなくなります。設定については、 [ ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.1. TPシステム > 7.1.7. 設定詳細 > 7.1.7.4. 名前サーバへの登録 ] の『CORBAアプリケーションの自動名前登録』を参照してください。

3.4.2.8. 仮想宛先 (VD)

WebOTXではメインフレームの技術を活かすために、仮想宛先(VD)をサポートしています。これにより、VDを利用した帳票印刷や非同期トランザクションの実行を行なうことができます。

WebOTXでは次のVDをサポートしています。

端末型 VD
主に帳票印刷に使用します。サーバAPから端末型VDに帳票電文イメージが送信されると、VDにその電文をキューイングします。 WebOTX Print Kitなどのクライアントがその電文を受信するまで、電文はVD内で保持されます。
トランザクション型 VD
主にサーバAPから他のサーバAPに非同期でオペレーション実行要求を行なうときに利用します。要求元サーバAPがオペレーション実行要求の電文をトランザクション型VDにキューイングし、呼び出されたサーバAPがその電文を引き取るまで、電文はVD内で保持されます。全ての非同期要求はシリアライズされて処理されるので、順序性のある非同期処理に使用します。
間接型 VD
トランザクション型VDを拡張したVDです。間接型VDでは順序性が無い非同期処理を並列に実行させることができます。 VDの振り分け方針については次の2通りがあります。
- ラウンドロビン : ラウンドロビンに振り分けを行います。
- 滞留数優先 : 滞留数の一番小さいトランザクション型VDに振り分けを行います。

3.4.2.9. データベース連携

WebOTXで使用するデータベースに対し、データベースの接続・切断処理を自動的に行います。データベース自動接続はプロセス初期化処理の後で行い、切断はプロセス終了処理の前に行います。さらにオペレーションの実行後に、実行結果に応じて、正常終了の場合はコミットを、異常終了の場合はロールバックを行います。

3.4.2.10. VB連携

WebOTXでは、CORBAインタフェースをCOMインタフェースにマッピングすることでMicrosoft Visual BasicからCORBAアプリケーションを呼び出すことが可能です。このマッピングを行なうためにダウンローダ管理ツールおよび、ダウンローダ管理サービスを提供しています。

図3.4.2.10-1

3.4.2.11. SSLとの連携

「Open SSL」もしくは「SecureWare/セキュリティパック」をWebOTX実行環境に適用することにより、WebOTXのクライアント－サーバ間通信を Secure Socket Layer (SSL) プロトコルで行えます。 SSLは共通鍵暗号化方式と公開鍵暗号化方式、デジタル証明書を併用した認証および暗号化のプロトコルで、WebOTXのクライアント－サーバ間通信においてクライアント、サーバの認証および電文の暗号化を行うことができます。
WebOTXのSSL通信についての特徴を以下に説明します。

図3.4.2.11-1

クライアント・サーバ間の認証

クライアント、サーバでそれぞれ認証を行うための鍵識別子を設定します。クライアントアプリケーションでは起動時の引数、またはAPIで鍵識別子を指定します。サーバアプリケーションではTPシステムの設定として統合運用管理ツールで設定を行います。設定後はクライアントとサーバのコネクション開設時に相互に認証を行います。また、サーバアプリケーションではAPIでクライアントを識別するための証明書情報を取得することが可能です。

ポートの設定

WebOTXのIIOPリスナでは、SSLを使用した通信と使用しない通信を同時にサポートするため、通信用のポート番号をそれぞれ独立して設定することが可能です。これにより、ファイアウォールを越える通信はSSLを利用し、ローカル内での通信はSSLを利用しない通信と振り分けて利用することが可能です。

通常ポート
SSLを利用しない場合に使用するポート番号です。
SSLクライアント認証ありポート
SSLを利用し暗号化を行い、なおかつクライアント、サーバ認証を行う場合のポート番号です。
SSLクライアント認証なしポート
SSLを利用し暗号化は行うが、サーバ側でクライアントの認証は行わない場合のポート番号です

3.4.3. トランザクション、プロセス制御

3.4.3.1. リソース制御

TPモニタはサービス開始時にTPシステムを管理するために必要なリソース(主にメモリ)を確保します。事前にリソースを確保することにより、運用中にリソース不足による動作の不安定な状況を避けることができます。
WebOTXでは、システム規模に応じたリソース配分を行なうために、TPシステム単位で以下のシステム・パラメータの設定を行えます。

表3.4.3.1-1
パラメータ	既定値	最大値
アプリケーショングループ数	985固定
プロセスグループ数	985固定
コンポーネント数	1000	3844
インタフェース数	2000	10000
オペレーション数	10000	2147483647
最大プロセス数	100	985
最大スレッド数	300	9850

3.4.3.2. 流量制御

WebOTXにおけるクライアントからのオペレーション要求の処理フローを以下に示します。

図3.4.3.2-1

WebOTXアプリケーションサーバは、サーバアプリケーションの制御を行なうTPモニタおよび、クライアントのオペレーション要求、応答処理を行なうIIOPリスナ、実際に業務ロジックを実行するプロセスグループ群から構成されます。また、プロセスグループ単位では要求受信用のキューを備えており、プロセスグループ単位で設定した実行多重度(プロセス数、スレッド数)を超えた要求は、キュー内で保留されます。プロセスグループはWebOTXの制御部分(ベースライブラリ、オブジェクトマネージャ)とユーザが作成したコンポーネントから構成されています。以下にその構成部分について説明します。

ベースライブラリ
OLTP機能を提供するライブラリです。IIOPリスナへの要求の送受信、プロセス・スレッド管理、障害監視、優先度制御などを行います。
オブジェクトマネージャ
CORBAやEJBの制御部分を行うライブラリです。ベースライブラリからの要求をCORBAやEJBの呼び出しに変換してユーザコンポーネントを実行し、各種コールバックAPIを提供します。 EJBの実行基盤であるEJBコンテナもここに含まれます。
サーバコンポーネント
ユーザが作成したCORBAもしくはEJBコンポーネントです。クライアントからの要求に対してビジネスロジックを提供します。

IIOPリスナはクライアントからのオペレーション要求を受け付けると、要求を処理するプロセスグループを判別し、該当プロセスグループのキューに要求をキューイングします。ベースライブラリでは、該当プロセスグループのうち処理実行待ちのスレッドにその要求を割り当て、オブジェクトマネージャに処理を渡します。オブジェクトマネージャでは、オペレーション要求に応じたユーザコンポーネントの該当オペレーションの呼び出しを行います。ユーザコンポーネントで実際のビジネスロジックが処理され、オペレーションの処理結果はオブジェクトマネージャ、ベースライブラリを通してIIOPリスナの持つ送信用キューにキューイングされます。 IIOPリスナは送信用キューに処理結果がキューイングされると、該当クライアントに応答を返します。

クライアントからプロセスグループの実行多重度を超えた要求があった場合、要求はキューイングされ空きスレッドができるまで処理を保留します。また、キューイング要求上限数（アプリケーションごとに設定可能）を超えた要求に対してはクライアントにエラーを返します。サーバの資源に応じてプロセスグループの実行多重度(プロセス・スレッド)、キューイング数を適切に設定することにより、想定外の大量のトランザクション要求に対しても、サーバリソースが枯渇して動作が不安定となる状況を回避し、リソースの範囲内で安定した動作を行わせることができます。またトランザクション毎にプライオリティ(実行優先度)を設定でき、高負荷で様々な処理がキューイングされている状態においても、重要な処理を優先的に実行することが可能です。

3.4.3.3. キュー制御

WebOTXでは、予測できない急激な負荷変動に対しても重要度の高い業務やユーザに対してサービスを継続させるために、以下のような様々なキュー制御を行なっています。

プロセスグループ単位のキュー制御
WebOTXではプロセスグループ単位でキュー管理を行なっています。このため、ある1つのプロセスグループの負荷が高くても、他のプロセスグループには影響しません。
プライオリティ管理
ある１つのプロセスグループの負荷が高い場合、通常であればそのプロセスグループで実行されるプロセス全体に影響が及びます。しかしWebOTXでは、オペレーション単位で実行優先度を設定することで、実行優先度が高いオペレーション要求を、低いオペレーション要求がキューイングされた状態でも優先的に実行させることが可能です。
キュー滞留数閾値設定
クライアントからの要求はプロセスグループの高負荷時には一時的にキューに滞留しますが、プロセスグループの慢性的なスローダウンではキュー滞留が増加し、システム全体のレスポンスが悪化してしまいます。そのような事態にならないように、WebOTXではキュー滞留数に閾値を設定し、その数以上の要求をエラーとしてクライアントに返すことが可能です。このキュー滞留数の閾値は運用中に動的に変更することができます。

図3.4.3.3-1

3.4.3.4. 多重実行

WebOTXでは、アプリケーションを複数のプロセスに分散して実行するマルチプロセス構成と、各プロセスでシングルスレッドやマルチスレッドを動作させるマルチスレッド構成がとれます。
マルチスレッド構成では、すべてのプロセス上のスレッド群は単一のキューに対してデータの到着を待ち合わせるので、空きスレッドに効率良くトランザクション要求をディスパッチすることができます。
マルチプロセス構成では、アプリケーションの一時的な障害に対してサービスの継続が可能になり、データや環境、タイミングなどの要因でアプリケーション障害が発生しても、そのプロセスだけが異常終了し、他のプロセスは影響を受けません。そのため、システム全体でサービスを中断させることがありません。

しかしマルチプロセス構成はマルチスレッド構成に比べてより多くのリソースを必要とします。システムで多数のプロセスが起動する構成ではマシンのリソース不足を招き、サーバ自体が不安定になる恐れがあります。そのため、マルチプロセス構成は予期せぬアプリケーション障害に備えての多重化とし、クライアントからの同時実行に備えての多重化はできる限りマルチスレッドで行う構成が望ましいといえます。

また、システム運用中に発生した想定外の大量のトランザクション要求に対して、動的にアプリケーション多重度(スレッド、プロセス)を増加させることが可能です。これにより、大量のトランザクション要求をサーバ側が処理しきれずにキューに滞留し、結果としてレスポンスの悪化を招く事態が避けられます。また、負荷が下がったときに安全に実行多重度を元に戻すこともできます。

以下の測定値はWindowsのアプリケーションプロセスで最低限必要となるメモリ使用量です。システム構築時のチューニングの参考としてください。ただし、実際のアプリケーションではユーザロジックで確保しているメモリ使用量を考慮に入れる必要がある点と、メモリ使用量はOSやJavaのバージョンにより異なる点はご注意ください。

マルチプロセスシングルスレッド構成の場合
メモリ使用量(JavaAP) = 33MB × プロセス数
メモリ使用量( C++AP) = 10MB × プロセス数

シングルプロセスマルチスレッド構成の場合

表3.4.3.4-1
スレッド数	メモリ使用量(JavaAP)	メモリ使用量(C++AP)
1	33MB	10MB
2	35MB	11MB
5	38MB	14MB
10	43MB	19MB
20	54MB	29MB
50	85MB	60MB
100	138MB	112MB

注）メモリ使用量はタスクマネージャの仮想メモリサイズ

マルチプロセスマルチスレッド構成の場合
1プロセス当たりのメモリ使用量を測定し、プロセス数をかけて見積もります。
例）5プロセス10スレッド構成の場合
メモリ使用量(JavaAP) = 43MB × 5プロセス = 215MB
メモリ使用量( C++AP) = 19MB × 5プロセス = 95MB

3.4.3.5. アプリケーショングループ停止処理時間の短縮

プロセスグループの強制停止処理時に即時強制停止することができます。即時強制停止ではプロセスグループに対して即時にシグナル送信(Windowsの場合はTerminateProcess())を行います。設定については、 [ ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.1. TPシステム > 7.1.7. 設定詳細 > 7.1.7.12. アプリケーショングループ停止処理時間の短縮 ] を参照してください。

3.4.4. TPモニタの障害に対する機能

Standard/EnterpriseではTPモニタ機能により、プロセスグループで動作するアプリケーションプロセスの状態を常に監視しています。ここではTPモニタによる障害に対する機能について説明します。

3.4.4.1. ログ採取

WebOTXではシステムの動作を確認できる各種のログやトレースを提供しています。またAPIを用いることによりユーザロジックの中でログ出力、トレース出力ができ、障害解析や性能分析に役立てることができます。 WebOTX V6.2以降では、障害解析で原因究明を行ないやすくするために、起動時ログを通常時のログと分けて出力します。

通常時ログ
V5と同様のログを採取できます。また、従来どおりサイズやレベルの設定が行なえます。
起動時ログ
アプリケーションが起動できなかった場合や初期化処理に問題があった場合の解析を容易にするため、アプリケーション起動時のログを通常ログから切り離して作成します。これにより起動時のログを確実に残し、起動後のログにより上書きされる状況を防ぐことができます。
log4jアペンダ提供
Javaコンポーネントでは、V5まではユーザロジック中でログ出力を行なう場合、オブジェクトマネージャが提供するログ出力APIを利用する必要がありましたが、 V6以降ではJavaで一般的にログ出力APIとして用いられているlog4jのAPIを利用できるようにlog4jアペンダを提供します。これによりlog4jで出力したログもサーバAPログにマージされて出力されます。
Javaスタックダンプ採取
以下の契機でJavaアプリケーションのスタックダンプを出力することで、不具合の原因究明をより行ないやすくします。
- ユーザロジック中でcatchしていない例外が発生したとき
- ストール監視の実行時間上限を設定し、実行時間がその上限を越えたとき
- アプリケーションを強制終了時に、終了要求に応じないスレッドがあるとき
ログの退避機能
動作していないプロセスのログをsaveディレクトリ配下に退避します。

3.4.4.2. プロセスグループで動作するアプリケーションプロセスの異常終了に対する機能

WebOTXではOLTP技術を取り込んだTPモニタによりアプリケーションサーバ上で動作するアプリケーションが管理されます。アプリケーションはTPシステム、アプリケーショングループ、プロセスグループの単位でグルーピングされ、TPモニタはこれら構成単位毎に起動、停止などの運用制御や状態監視、障害リカバリを行います。

アプリケーションアボート監視

クライアントからのトランザクション要求に対してサーバアプリケーションが不正な処理を行い、例外が発生した場合に、該当スレッドを閉塞して、例外の発生をコールバックAPIでアプリケーションに通知します。アプリケーションは、データベースのロールバック前に障害情報の保存などの後処理を行うことができます。

アプリケーションストール監視

クライアントからのトランザクション要求に対して、あらかじめ設定した時間が経過してもサーバアプリケーションが応答を返さない場合に、アプリケーションを異常終了させて該当プロセスを閉塞します。これにより、クライアントに応答が返らない事態やサーバの資源を無制限に消費する事態を回避できます。

異常終了プロセス再起動

上記事象によりアプリケーションプロセスが異常終了した場合に、そのプロセスが使用していたリソース(コネクション、共有メモリ、データベース資源)をWebOTXが解放し、設定に応じてプロセスの再起動を行います。この機能により、障害発生後もプロセス異常終了前と同じ処理能力を維持することができます。

アプリケーションプロセスの異常終了が検出されると、TPS15-01107メッセージがイベントログ・シスログに出力されます。 異常が発生した場合はまずはイベントログ・シスログを確認してください。

図3.4.4.2-1

アプリケーション異常終了時の継続運用

プロセスグループがマルチプロセス構成の場合、その中の一つのアプリケーションプロセスが異常終了しても、他のアプリケーションプロセスは通常どおり処理を行うことができます。このため、プロセスグループとしては異常終了したアプリケーションプロセスが再起動されるまでの間もサービスの継続性を確保できます。

アプリケーションプロセスの再起動に回数を設定し、プロセスの異常終了時にはこの指定に応じて再起動が行なえます。ただし障害が再現性のあるものである場合、障害発生後に自動的に再起動させても、同じ障害が再度発生して、再起動が繰り返される可能性があるので注意が必要です。また自動的に再起動させてしまうと障害の発生に気付かない恐れがあるので、テスト環境で使用する場合は再起動させない設定とし、本番運用では再起動する設定とする構成を推奨します (統合運用管理ツールの[TPシステム]-[上限設定]-[プロセス障害時の再起動回数])。

C++で作成されたサーバアプリケーションでは、異常終了発生後にオペレーションを閉塞状態にしてクライアントから実行させないようにすることができます。閉塞されたオペレーションが呼び出されるとTPS10-03201メッセージがイベントログ・シスログに出力され、問題のオペレーションは実行されません。この機能ではオペレーション単位で閉塞状態にすることができるので、正常動作している他のオペレーションは引き続き動作します。アプリケーション作成者は、この間にプログラムのチェックを実施することになります。
オペレーションの閉塞に関する設定は統合運用管理ツールのプロセスグループの[スレッド制御]-[オペレーションを異常終了時に閉塞させる]で行います。
なお、V5までは閉塞する対応がデフォルトの設定となっていましたが、V6以降では閉塞させない対応がデフォルトの設定となります。

リクエスト保障

オペレーション実行中に何らかの障害でプロセスが終了した場合、TPモニタがそのプロセスに代わりエラー応答をクライアントに返し、イベントログ・シスログに情報を残します。このときキューで処理を待っていたリクエストは別プロセスが引き継いで処理をすることができますが、他に起動中のアプリケーションプロセスがなく、かつプロセス再起動回数を使い果たした場合は要求を別プロセスに引き継げません。しかしこの場合でもエラー応答をクライアントアプリケーションに返すため、サーバアプリケーションの異常終了に影響されてクライアントアプリケーションが無応答になることはありません。

クライアントアプリケーションに返却されるエラーコードの詳細は [ 例外一覧 ] を参照してください。

障害情報記録(Java)

WebOTXでは、オペレーション実行中にJavaランタイム例外が発生するとアプリケーションプロセスを異常終了させますが、この際に捕捉した例外のスタックトレースをシステムトレースに記録します。この情報から、Javaソースのどの行が原因で異常終了したかを特定することができます。

デフォルトでは以下の場所にアプリケーションログを出力しています。

${INSTANCE_ROOT}/logs/tpsystem/<アプリケーショングループ名>/<プロセスグループ名>

なお、異常終了の場合はログがsaveディレクトリに移動するため、saveディレクトリも確認してください。

ファイル名 : <プロセスグループ名>.<時間をベースとした識別子>.<プロセスID>.log

障害情報記録(C++)

WebOTXでは、オペレーションの実行中にネイティブ例外が発生すると該当スレッドを閉塞させ、スレッドの残りがない場合はプロセスを終了させます。また、このときイベントログ・シスログにメッセージと、ネイティブ例外エラーコードを出力します。システムトレースに記録されたライブラリロードアドレスと開発時のmapファイルを使用することで、障害箇所を特定できる可能性があります。

例外発生時の情報はアプリケーションログに出力されます。デフォルトでは以下の場所にアプリケーションログを出力しています。

${INSTANCE_ROOT}/logs/tpsystem/<アプリケーショングループ名>/<プロセスグループ名>

なお、異常終了の場合はログがsaveディレクトリに移動するため、saveディレクトリも確認してください。

ファイル名 : <プロセスグループ名>.<時間をベースとした識別子>.<プロセスID>.log

アプリケーションエラーが発生したとき、アプリケーションログにエラーメッセージを出力します。このメッセージを確認することで、エラーが発生したオペレーション呼び出しを特定することが可能です。またV8.3以降では、アプリケーションログにスタックトレースを出力するか、もしくは例外ハンドルの設定を無効にしてワトソンログ出力を有効にすることができます。例外ハンドルの設定は統合運用管理ツールの[TPシステム]-[例外ハンドル]-[WebOTXで例外処理を行う]で行なえます。

出力されたスタックトレースを解析するには、 [ トラブルシューティングガイド > 2. 障害解析 > 2.5. 機能別リンク > 2.5.1. TPシステム(Standard/Enterprise) > プロセス突然終了への対応 ] を参照してください。

異常終了時のオペレーション状態記録

システムトレースにはアプリケーションプロセスが異常終了した時点で実行中だった未完了のオペレーションの状態が記録されるため、異常終了したオペレーションを絞り込むことができます。この機能は、アプリケーションプロセスが実行されるたび共有メモリに記録している情報を元に出力しているので、アプリケーションの終了の要因に関わらず利用できます。
一方で、オペレーションの絞込みは障害情報記録(Java)、障害情報記録(C++)の情報で行なえる場合もありますが、これらの機能はアプリケーションプロセス中で実行される機能であるため、killコマンドやタスクマネージャで強制終了された場合などの状況によっては機能しないことがあります。

3.4.4.3. 無応答障害に対する機能

Standard/Enterpriseでは、アプリケーションプロセスが無応答や極度の遅延に陥った場合に、状態を検出し、情報を採取してリカバリを行う機能を実装しています。

プロセス起動停止の実行時間超過の検出および全スレッドストールの検出

プロセス起動処理(Java VMの起動,ORB初期化など)やプロセス終了処理(ORB解放,JavaVM停止など)で無応答となった場合に、プロセスのストール検出機能により障害を検出し、該当アプリケーションプロセスを強制終了する機能です。この障害で強制終了されたプロセスがあらかじめ再起動設定を行なっていた場合、起動処理時の障害時に再起動が実行されます。また、以下で説明する [ スレッド起動停止の実行時間超過の検出 ] や [ オペレーション実行時間超過の検出と自律復旧 ] などの、アプリケーションプロセス中の制御スレッドで実装されている監視機能が正常に機能しないような異常状態になった場合であっても、プロセスのストール監視機能により障害を検出し、アプリケーションプロセスを強制終了します。タイマの設定方法は [ 高度な管理と運用サイクルガイド > 2. チューニング > 2.1. APサーバ > 2.1.4. その他チューニングに関する設定 > 2.1.4.2. 起動・停止タイムアウト(プロセス終了) ] を参照してください。

スレッド起動停止の実行時間超過の検出

この機能では、スレッド起動処理(サーバオブジェクトや常駐オブジェクト作成)やスレッド終了処理(サーバオブジェクトや常駐オブジェクト削除)が無応答になった場合に障害として検出し、プロセスを強制終了します。この機能で強制終了されたプロセスがあらかじめ再起動設定を行なっていた場合、起動処理中に障害が発生した時に再起動が実行されます。この機能で使用するスレッド初期化タイムアウト時間はプロセスグループ単位に設定できます。タイマの設定方法は [ 高度な管理と運用サイクルガイド > 2. チューニング > 2.1. APサーバ > 2.1.4. その他チューニングに関する設定 > 2.1.4.1. 起動・停止タイムアウト(メッセージ表示) ] を参照してください。

オペレーション実行時間超過の検出と自律復旧

サーバアプリケーションで実行したオペレーションが無応答のときに、その状態を無応答障害として検出し、警告メッセージをシスログ(Windowsの場合はイベントログ)に、アプリケーションログにスタックトレースを出力する機能です。この機能では、サーバアプリケーションが実行時間上限を超えても応答がない場合、WebOTX　はアプリケーションプロセスが無応答障害に陥っていると判断し、警告メッセージとスタックトレースを出力します。あらかじめ実行時間上限の設定をしていた場合は、アプリケーションプロセスを強制終了し、再起動設定を行なっていればプロセスの再起動を実行します。この機能により、クライアントに応答が返らない事態や、サーバの資源を無制限に消費する事態を回避できます。実行時間上限値はオペレーション毎に設定することができます。設定方法は [ 高度な管理と運用サイクルガイド > 2. チューニング > 2.1. APサーバ > 2.1.4. その他チューニングに関する設定 > 2.1.4.4. 実行時間タイムアウト ] を参照してください。

この機能では、データベースのデッドロックなどの再試行可能な障害であればそのオペレーションを自動的にやり直したり、データベースのオーバーフローなどでは更新系のサービス(オペレーション)だけを停止するなど、障害の原因によってきめ細かいリカバリ処理を行うこともできます。

リクエスト保証(AP応答監視タイマ)

AP応答監視タイマ機能では、サーバアプリケーションの無応答障害を検出し、別プロセスが異常状態のアプリケーションプロセスに成り代わってクライアントアプリケーションにエラー応答(NO_RESPONSE(3920))を返します。これによりサーバアプリケーションの無応答障害が発生しても、クライアントアプリケーションは無応答状態を回避して応答を受け取ることができます。 AP応答監視タイマ機能はプロセスグループ毎に設定することができます。設定方法は [ 高度な管理と運用サイクルガイド > 2. チューニング > 2.1. APサーバ > 2.1.4. その他チューニングに関する設定 > 2.1.4.3. 呼び出しタイムアウト ] を参照してください。

スレッド状態表示

WebOTXではサーバアプリケーションの全スレッドそれぞれで実行されている処理の情報を取得することができます。この機能では、各スレッドの状態(IDLE状態/実行状態など)、実行中のオペレーション名、実行中オペレーションの開始時刻、接続しているクライアントアプリケーションのIPアドレスが確認できます。この機能を利用して、無応答障害が発生している最中にこの情報を確認することで障害原因を絞り込んだり、CPU時間を確認することでCPUループを引き起こしているオペレーションを特定することができます。

Caution
Linux版、Solaris版では各スレッドのCPU時間を採取できません

また、この機能では各プロセスのCPU使用率、CPU使用時間(ユーザモード/システムモード)、メモリ使用量（仮想/物理）コンテナ状態（起動処理の進み具合）も採取することができます。

Caution
Linux版ではCPU情報を採取できません

図3.4.4.4-1

障害情報記録(スタック採取)

この機能では、無応答障害に陥っているアプリケーションプロセス(Java)のスタックトレースを採取することができます。この情報より、サーバアプリケーション中のどの箇所で無応答となっているかを特定することができます。前述の実行時間上限監視機能では、無応答障害を検出すると、同様のスタックトレースを採取してAPトレースに記録します。

この機能では、無応答障害発生中に任意のタイミングでスタックトレースをAPトレースに記録することも可能です。この機能を統合運用管理ツールから使用するには、プロセスグループ名を右クリックして「スタックトレースの採取」を実行してください。コマンドを使用する場合は、マニュアルの [ リファレンス集運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.6. TPシステム > 4.6.5. wostack ] を参照してください。

また、実行時間上限監視機能が無応答障害を検出すると、終了直前に実行中だった未完のオペレーションの状態がシステムトレース( [ ドメイン構築・基本設定ガイド > 8. ログ > 8.3. その他 > 8.3.3. Standard/Enterprise上のアプリケーションのログ出力 > 8.3.3.1. サーバアプリケーショントレース採取 ] )に記録されます。この情報から異常終了の原因をオペレーション単位で絞り込むことができます。

3.4.4.4. ネットワーク/クライアント障害に対する機能

通信の監視(無通信監視)

この機能では、一定時間オペレーション呼び出しがないクライアントアプリケーションの接続を強制的に切断することができます。これにより、長時間使用されていない不必要と思われる接続を抑止し、ネットワークリソースの消費を抑えることができます。設定方法は [ 高度な管理と運用サイクルガイド > 2. チューニング > 2.1. APサーバ > 2.1.4. その他チューニングに関する設定 > 2.1.4.5. クライアント無通信監視間隔 ] を参照してください。

また、WebOTX が提供するコールバック用のAPIを利用すると、CORBAサーバアプリケーションがクライアント障害の発生の通知をシステムから受け取って、独自の後処理を行うことができます。

図3.4.4.4-1

アライブチェックによる監視

TCPレベルのkeepalive機能を設定し、アライブチェックを行うことができます。これによりネットワーク障害で使用不可能となった接続を検出して切断することができます。 keepalive機能自体はOSが持つ監視機能となり、WebOTXではOSのkeepalive機能使用有無のみを設定します。keepalive機能のアライブチェック間隔は各OSに依存します。 WebOTXに対する設定は [ トラブルシューティングガイド > 2. 障害解析 > 2.5. 機能別リンク > 2.5.1. TPシステム(Standard/Enterprise) > クライアント接続数オーバーへの対応 ] を参照してください。

3.4.4.5. 運用アシスタント

運用アシスタント機能は、定期的に採取した情報をもとにシステムの稼働状況を学習・分析し、適切な運用を支援する自律運用機能です。運用アシスタントでは以下の設定の最適化と、適正値算出のコスト削減をはかることができます。また、稼働状況の変化に合わせて、システムの設定を動的に変更させることも可能です。

多重度の最適化支援

システムの稼働状況から、設定されている多重度（プロセス数/スレッド数）が適切かどうか分析します。多重度は少なすぎると性能問題を引き起こし、多すぎると不必要にリソースを消費してしまいます。本機能では、多重度が少なすぎる/多すぎると判断すると、統合運用管理ツールなどを通じてオペレータに通知します。また、オプション設定によって、システムの稼働状況に合わせて多重度を自動設定することもできます。

実行時間上限の適正値算出

計算では求めづらく、また設定箇所の多い「実行時間の上限」を、運用アシスタント機能により自動的に算出します。「実行時間の上限」はオペレーションのストール障害復旧の要となる重要な設定です。オペレータは一つの操作だけで、全オペレーションに対して適切な実行時間上限を設定することができます。

スローダウン障害監視

オペレーションの呼び出し時間の統計データより、平常時よりオペレーション実行時間が長くなっている場合に、スローダウン障害を検出して統合運用管理ツールなどを通じてオペレータに通知します。本機能では一般的な監視機構とは違って、オペレーションごとの閾値設定なしでスローダウン障害を検出できます。また、スローダウン状態が長期化している場合は、更に警告を通知します。このときには自動的にスタックトレースも採取するので、スローダウン障害発生時の情報の消失を防ぎ、障害調査を容易にします。

本機能ではスローダウン発生時にイベントログ・シスログにメッセージを出力します。さらにV8.2以降では、アプリケーションログにスタックトレースを3秒間隔で5回出力するので、これらを確認することでどの処理で遅延が発生しているか特定できる場合があります。

オペレーションのスローダウンを検出してから「スローダウンの継続を監視する間隔」を超えてなお、スローダウン状態が継続していると「長期にわたるスローダウン状態」を検出し、イベントログ/syslog,webotx_agent.log(webotx_tpmmgr.log)にメッセージを出力するとともに、該当プロセスグループのスタックトレースを採取します。このAPログに出力されるスタックトレースを参照することで、スローダウンの原因を調査することができます。詳しくは [ ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.1. TPシステム > 7.1.13. 運用アシスタント ] を参照してください。

スローダウン検出後は、ジャーナル、オペレーションジャーナル、イベントジャーナルなどの統計データから原因を絞り込むことができます。詳しくは [ トラブルシューティングガイド > 2. 障害解析 > 2.5. 機能別リンク > 2.5.1. TPシステム(Standard/Enterprise) > オペレーション遅延への対応 ] を参照してください。

3.5. ネットワーク通信

3.5.1. ネットワークプロトコル

3.5.1.1. RMI over IIOP

従来、Java のプログラム間通信手段としてはRMI が使われていました。しかし、Java EE が要求するトランザクション・セキュリティ技術に対応するには独自プロトコルによる拡張が必要であったため、ベンダ固有の通信となってしまい相互接続性がありませんでした。 RMI over IIOP は、これらの問題を解決し、CORBAの高い相互接続性とJava 言語への親和性の高い通信を両立するものです。 WebOTX では、WebOTX Object Broker というORB の通信コアを含んでおり、RMI over IIOP 1.0 仕様に準拠しています。

3.5.1.2. SOAP

SOAP はXML 文書を交換するためのプロトコル仕様です。HTTP やSMTP などの既存のプロトコルに乗せて使うことが想定されている上位プロトコルです。図にSOAP メッセージの構造を示します。

図3.5.1.2-1

SOAP Message
HTTP のヘッダなども含めたSOAP メッセージ全体を指します。
SOAP Part
XML で書かれるメッセージ本体の領域を指します。
Attachment Part
添付データの領域を指します。Attachment Part は、複数の領域をあとに続けて確保することができます。
SOAP Envelope
SOAP メッセージの一番外側の要素です。
SOAP Header
SOAP 通信やWeb サービスのアプリケーションが動作する上で必要な付帯事項を書き込む要素です。
SOAP Body
通信したいメインの内容を書き込む要素です。
MIME Headers
添付データのMIME エンコーディングに関するヘッダを書き込む部分です。
Content
MIME エンコーディングした添付データを書き込む部分です。

3.6. 提供サービス

3.6.1. Webサービス

一般的なWeb サービスの概念と、それに対応したWebOTX の提供機能を紹介します。

3.6.1.1. Webサービスとは

Web サービスとは、広い意味で「Web の世界に存在するサービス」を指します。例えば、自動的にメールを返信する業務アプリケーションがあったとします。この業務アプリケーションには、配信先を登録したり、本文に相手の名前を挿入したりといったさまざまな機能が含まれているでしょう。このように、アプリケーションは1つ1つの機能をまとめることで動作するということができます。これらの機能を構成する要素 (コンポーネント)1つ1つをサービスと言います。

これまでも、こうした様々な場所に点在するコンポーネントを連携させるコンポーネント技術は発達してきました。CORBA やCOM などが代表的なコンポーネント技術ですが、複数コンポーネント技術が存在することで、コンポーネント技術間の連携が面倒なものとなっていました。もっと自由に、世界中、インターネット中に散らばっているいろいろなサービスを結び付けて、アプリケーションを作ることができたらいいのに、という考え方から生まれたのが「Web サービス」です。現在、Web サービスはコンポーネント技術の業界標準、よりオープンなビジネスソリューションを実現するための技術として捉えられ、広く普及しています。

Web サービスは、コンポーネント技術の標準を目指しているということで、データ交換の手段として最も標準的な言語仕様である「Extensible Markup Language (XML)」を採用しました。また、XML データをやり取りするための決まりとして「Simple Object Access Protocol (SOAP)」というプロトコルが、Web サービスのインタフェースを公開するための言語仕様として「Web Service Description Language (WSDL)」が、レジストリに登録されているWeb サービスを検索するための技術とレジストリにWeb サービスを登録するための技術である「Universal Description, Discover and Integration (UDDI)」が定義され、全てをXML のやり取りで解決するコンポーネント技術として確立されています。

図3.6.1.1-1

またJavaEE 6仕様からは、Webサービスの通信にSOAPを用いずにRESTと呼ばれるスタイルでインターネット越しのソフトウェアを利用する形態が提供されています。

3.6.1.2. Webサービスの基本仕様

Simple Object Access Protocol (SOAP)

SOAP は、XML 文書を交換するためのプロトコル仕様です。HTTP やSMTP などの既存のプロトコルに乗せて使う上位プロトコルです。

WebOTX はSOAP 1.1、SOAP 1.2 仕様に対応したSOAP ランタイムを提供しています。SOAP ラインタイムは、トランスポートプロトコルとしてHTTP に対応しており、 SOAP メッセージの送受信・解析・生成をJava で行うためのAPI を提供します。

Web Services Description Language (WSDL)

WSDL は、Web サービスについての情報をXML で記述する方法を定めた仕様です。Web サービスの名前、ロケーション、インタフェースやWeb サービスと通信する方法が記述されます。一般的に、Web サービスを作成したときにWSDL を作成します。Web サービスを公開する場合は、Web 上でWSDL を直接公開したり、UDDI に登録したり、あるいはその両方を行います。Web サービスのクライアントは、WSDL を元に作成します。

WebOTX は、WSDL 1.1 仕様に対応しており、Java プログラムからWSDL を生成する機能、WSDL からSOAP ランタイムを使用してSOAP メッセージを送受信・解析・生成するためのJava ソースコードを生成する機能を提供します。

Universal Description, Discovery and Integration (UDDI)

人間が目的のホームページを見つける時には「検索エンジン」を使います。同じように目的のWeb サービスを検索するための仕様、それがUDDI です。UDDI は、Web サービスを登録するところとして「UDDI レジストリ」を定義し、UDDI レジストリを検索してWeb サービスを探し出す方法を決めています。登録する情報はXML 形式で、検索にSOAP を使います。UDDI レジストリには、「UDDI ビジネスレジストリ」と「プライベートレジストリ」の2種類があり、前者はインターネット上に1つだけ存在するように見えるレジストリで、世界中の誰もが利用することができます。後者は企業内やポータルサイト内のようにある閉じられた空間の中に存在、または構築するUDDI レジストリです。

WebOTX はJAXR に対応しており、UDDIレジストリにアクセスするアプリケーションの作成を支援します。

Web Services-Interoperability Organization Basic Profile (WS-I BP)

WS-I はWeb サービスアプリケーションの相互接続性を高めていくことを目的として設立された団体で、そこで様々なWeb サービス技術の仕様について議論されています。Basic Profile はSOAP、WSDL、UDDI の仕様のあいまいさを取り除き、相互接続性を高めるためにWeb サービスアプリケーションはどう作るべきかというガイドラインを定めている仕様です。

WebOTX は JAX-RPC ではWS-I BP 1.0 に、 JAX-WS ではWS-I BP 1.2/2.0 に対応し、WS-I BP に沿った Web サービスアプリケーションの作成を支援します。

図3.6.1.2-1

3.6.1.3. Java EE 6 対応

Java EE 6 に規定された次の仕様に対応した機能を提供します。

SOAP with Attachments API for Java (SAAJ)

Java 言語でSOAP メッセージや添付ファイルつきのSOAP メッセージを作成したり、読み込んだりするときに使用する標準API です。

Java API for XML Web Service (JAX-WS)

Java EE 6 から新規に追加されたWeb サービス仕様で、XML/HTTP バインディングや非同期通信を可能にします。

Java API for XML-Based RPC (JAX-RPC)

SOAP、WSDL を使ってJava 言語でRPC を実現するときに使用する標準API やWeb サービスアプリケーションの実装方法などについて定義した仕様です。

Java API for XML Registries (JAXR)

UDDI やebXML などのXML ベースのレジストリサービスにアクセスするときに使用するJava 言語の標準API です。

Web Services for Java EE (WSEE)

Java EE サーバ (Web コンテナ/EJB コンテナ) でWeb サービスアプリケーションを動作させるときのWeb サービスアプリケーションの実装方法、Web サービスアプリケーションのポータビリティについて定めている仕様です。

Java Architecture for XML Binding (JAXB)

Java とXML のデータバインディングのためのAPI やJava オブジェクトとXML スキーマのマッピング、相互変換を可能にする仕様です。

The Java API for RESTful Web Services (JAX-RS)

JavaでRESTful Web Services実現するときに使用する標準APIについて定めている仕様です。

3.6.1.4. Webサービス拡張仕様

WS-Security

Webサービスの通信における完全性(改竄検知)、秘匿性(盗聴防止)、送信者認証(認証、および否認防止)等のセキュリティ技術に関する仕様です。 WebOTXは、WS-Security 1.1 仕様に準拠し、下記のセキュリティトークンをサポートしています。

UsernameToken
ユーザ名・パスワードを用いて認証を行うためのセキュリティトークンです。 Username Token Profile 1.0/1.1 仕様に準拠したUsernameTokenを使用できます。
X509Token
X.509証明書を用いて認証を行うためのセキュリティトークンです。 X.509 Token Profile 1.0 仕様に準拠したX509Tokenを使用できます。
SecuremasterToken
SECUREMASTER製品と連携して認証を行うためのセキュリティトークンです。SecuremasterTokenはWebOTX独自に定義したセキュリティトークンです。
SECUREMASTERとは、ID情報や認証・認可情報の統合管理などを実現するセキュリティ製品であり、SecuremasterTokenを利用したセキュリティ機構では、SECUREMASTER/AccessControlPlugInを使用してユーザ認証・認可を実行します。SECUREMASTER/AccessControlPlugIn Ver7.0に対応しています。

アプリケーション開発方法の詳細については[ アプリケーション開発ガイド（Java EE） > 1. Webサービスアプリケーションの開発 > 1.2. プログラミング・開発ガイド > 1.2.13. WS-Security ]を参照してください。

WS-Seculityのサポート範囲は、[ アプリケーション開発ガイド（Java EE） > 1. Webサービスアプリケーションの開発 > 1.2. プログラミング・開発ガイド > 1.2.13. WS-Security > WS-Securityのサポート範囲 ]を参照してください。

WS-SecurityPolicy

WSDL定義の一部としてWS-Security仕様に準拠したセキュリティ構成を定義するための仕様です。 WebOTXは、WS-SecurityPolicy 1.2 仕様に準拠しています。

WS-SeculityPolicyのサポート範囲は、[ アプリケーション開発ガイド（Java EE） > 1. Webサービスアプリケーションの開発 > 1.2. プログラミング・開発ガイド > 1.2.13. WS-Security > WS-SecurityPolicyのサポート範囲 ]を参照してください。

WS-ReliableMessaging

WS-ReliableMessaging は、エンドポイント間で信頼性の高いメッセージの送受信を実現するための技術で、欠落したメッセージの再送、再送メッセージの重複の防止、メッセージ順序の保障等の機能を提供しています。

WebOTXでは、WS-ReliableMessaging のメッセージシーケンスの中で送受信されるメッセージを、WS-ReliableMessaging キューおよびデッドキューと呼ばれるデータストアに格納します。WS-ReliableMessaging キューは、アクティブなシーケンスの情報およびメッセージを格納し、WS-ReliableMessaging デッドキューは、タイムアウトまたは有効期限切れのシーケンスの情報およびメッセージを格納します。

WebOTX は、WS-ReliableMessaging 1.2 仕様に準拠しています。アプリケーション開発方法の詳細については[ アプリケーション開発ガイド（Java EE） > 1. Webサービスアプリケーションの開発 > 1.2. プログラミング・開発ガイド > 1.2.14.2. Webサービスの作成および 1.2.14.3. Webサービスクライアントの作成 ] を参照してください。

Memo
WS-ReliableMessaging は、データストアとしてデータベースを使用します。詳細については[ アプリケーション開発ガイド（Java EE） > 1. Webサービスアプリケーションの開発 > 1.2. プログラミング・開発ガイド > 1.2.14.1. 事前準備 ] を参照してください。

3.6.2. JNDI

Java EE 環境下におけるネームサービスは、Enterprise Bean や Web コンポーネントに、JNDI ネーミング環境へのアクセスを提供します。

Java EE コンポーネントは、ネーミング機能とディレクトリ機能を持つサーバへのアプリケーションインタフェースである JNDI を使用して Java プログラミングします。任意の部品コンポーネントを JNDI で登録することで名前を指定してターゲットのクラスオブジェクトを取得することができ、アプリケーションのポータビリティの向上を図ることができます。

WebOTX では、JNDI のサービスを提供するサーバ(JNDI サーバ)として CosNaming サーバ(CORBA 用) と Serial Context Provider (RMI 用)を提供しています。WebOTX Enterprise では、JNDI サーバ (CosNaming サーバ、Serial Context Provider)の二重化運用をサポートしており、システム全体の可用性を確保することができます。WebOTX はJNDI 1.2 仕様に準拠しています。

3.6.2.1. JNDIとは

あらゆるコンピューティングシステムの基本機能は、ネームサービスです。ネームサービスによって、名前とオブジェクトを関連付け、名前をもとにしてオブジェクトを検出する方法が提供されます。従来のシステムでは、多くの場合、ネームサービスは単体では機能しません。通常は、ファイルシステム、ディレクトリサービス、データベース、デスクトップ、メールシステム、カレンダなど、その他のサービスと統合されます。たとえば、ファイルシステムには、ファイルとディレクトリ用のネームサービスが組み込まれています・

Java Naming and Directory Interface (JNDI) は、Java プラットフォーム用の標準拡張機能で、Java テクノロジに対応したアプリケーションに、企業内の複数のネーミングおよびディレクトリサービスへの統一したインタフェースを提供します。 JNDI は、Java Enterprise API セットの一部として、異機種システムの混在したネーミングおよびディレクトリサービスへのスムーズな接続を可能にします。開発者は、この業界標準機能を使用することで、強力かつ移植性の高いディレクトリ対応アプリケーションを構築することができます。

Java EE では、JNDI がさまざまな場面で用いられています。例えば、EJB のホームインタフェースの取得、Java EE アプリケーションで使用するリソースの取得、環境エントリ取得などで使用されます。

JNDI アーキテクチャは、JNDI API およびJNDI SPI から構成されます。 JNDI API とは、JNDI を使用するためのインタフェースを定義しているクラスライブラリです。 JNDI SPI とは、JNDI の実装を提供するクラスライブラリで、JNDI の提供ベンダから提供されます。 JNDI の利用者は環境プロパティによってどの SPI を使用するかを指定することにより、使用する JNDI の実装を選択して使用します。

3.6.2.2. WebOTXの提供するJNDIについて

動作概要

WebOTX のJNDI サーバは、RMI-IIOP 通信を行うサーバプロセスで、名前空間の情報をメモリ中に保持します。JNDIクライアントは、通信先の JNDI サーバのホスト名、ポート番号を接続先 URL に指定することによってJNDIサーバにアクセスすることができます。

WebOTX V8 までのJNDI サーバは、既定で Object Broker の CosNaming サーバをバックエンドの名前サーバとして使用していました。 WebOTX V9 以降で、 CosNaming サーバを介した JNDI サーバアクセスを行う場合は、JNDIサービスの設定で CosNaming サーバへの登録を有効にし、JNDIクライアントの接続先 URL に corbaname 形式を使用する必要があります。設定の詳細については [ アプリケーション開発ガイド（共通） > 4. JNDIアプリケーションの開発 > 4.1. プログラミング・開発ガイド > 4.1.1. 環境設定 > 4.1.1.4. 環境プロパティの必須プロパティの 2.corbaname形式 ] を、動作の概要について[3.6.2.3. CosNaming サーバを使用した場合の動作 ] を参照してください。

レプリケーション

WebOTX のJNDI サーバは複数のサーバで同じ名前空間を管理することができます。これをレプリケーションと呼びます。

JNDI サーバのレプリケーションを行うためには、クライアント側で接続先URL にレプリケーション対象のJNDI サーバのホスト名、ポート番号をすべて列挙します。設定の詳細については [ アプリケーション開発ガイド（共通） > 4. JNDIアプリケーションの開発 > 4.1. プログラミング・開発ガイド > 4.1.1. 環境設定 > 4.1.1.4. 環境プロパティの必須プロパティの 1.rmiiiop形式 ] を参照してください。

レプリケーションを行った場合、各JNDI サーバで保持している情報が同じものでなければなりません。この同期処理はJNDI クライアントが行います。つまりbind、unbind などの名前空間の情報を変更するようなメソッドを実行する際は JNDI クライアントはその名前空間を管理しているJNDI サーバ全てに対してメソッド実行を行います。

図3.6.2.2-1

このとき、それぞれのJNDI サーバに対するメソッド呼び出しは非同期に行われるため、メソッド実行が複数の JNDI サーバに対して行われることによる性能劣化は最小限に抑えられています。 lookup などの名前空間の情報を参照する処理は、どれかひとつのJNDI サーバに対してメソッド実行を行います。障害などによりそのJNDI サーバが停止している場合は、別のJNDI サーバに対してメソッド実行を行います。

図3.6.2.2-2

これらの処理はWebOTX JNDI が提供するSPI クラスの中で行われます。つまり、JNDI クライアント側では通常のJNDI メソッドを呼び出すだけです。

3.6.2.3. CosNaming サーバを使用した場合の動作

動作概要

JNDI サーバは起動時に CosNaming サーバの特定のコンテキスト配下に自身のホスト名で自身の RMI-IIOP サーバオブジェクトを登録します。 JNDI サーバを使用するクライアントは CosNaming サーバの特定のコンテキスト配下から JNDI サーバオブジェクトの参照を取得します。そして、JNDI サーバオブジェクトに対してバインド、アンバインドなどの名前空間にアクセスするメソッド要求を実行します。

図3.6.2.3-1

レプリケーション

図3.6.2.3-1
図3.6.2.3-2

JNDI サーバのレプリケーションを行うためには、各JNDI サーバが使用するCosNaming サーバを同一の設定にします。このように設定して各JNDI サーバを起動すると、CosNaming サーバの特定のコンテキスト配下に複数のJNDI サーバの参照が登録されます。これらのJNDI サーバは同じ名前空間を管理することになります。

ただしCosNaming サーバを1つしか指定していない場合、JNDI サーバ全てがそのCosNaming サーバに依存することになってしまいます。よって通常はそれぞれのJNDI サーバで動作しているCosNaming サーバを全て列挙して指定します。このように指定するとJNDI サーバは起動時に、列挙した全てのCosNaming サーバに自身の RMI-IIOP サーバオブジェクトを登録します。このため一つのCosNaming サーバが停止しても、別の CosNaming サーバからJNDI サーバのリファレンスを取得することができます。

クライアント側でも同様に接続先URL に複数のURL を列挙して指定することにより、動作中のCosNaming サーバからJNDI サーバのリファレンスを取得します。

図3.6.2.3-3

図3.6.2.3-4

これらの処理はWebOTX JNDI が提供するSPI クラスの中で行われます。つまり、JNDI クライアント側では通常のJNDI メソッドを呼び出すだけです。

JNDI サーバは名前空間の情報をメモリ中に保持しているため、障害などによって再起動された場合、登録されていた名前が全て消えてしまいます。このため、再起動時にCosNaming サーバの特定のコンテキスト配下に登録されている JNDI サーバから名前空間の情報を全て取得し、自身の名前空間の情報とマージします。これによって他のJNDI サーバとの同期を行います。

3.6.3. JDBCデータソース

トランザクションの実行性能を上げるためには、JDBC コネクションのプール管理によって、コストの高いデータベースとの物理的な接続および切断処理を、繰り返し行わないようにすることが重要です。

WebOTX では、JDBC のコネクションをプール管理するためのJDBC データソースを提供しています。このJDBC データソースは、Web コンテナやEJB コンテナ上のServlet やEJB から利用することができます。さらに、CORBA のJava アプリケーションからも利用することができます。

JDBC データソースは、JTA 仕様を実現するWebOTX Transaction Service と組み合わせることで2フェーズコミットメントにも対応でき、複雑に分散したデータベースにまたがるトランザクションをデータベースの一貫性を保障して簡単に実現することができます。

JDBC コネクション (java.sql.Connection インスタンス) の取得は、データベースとの物理的なコネクションの接続処理をともないますので、非常に時間を要します。そのため、JDBC コネクションのプール管理を行うことが一般的です。また、アプリケーションを記述するうえでは、データベースや接続プロトコルによらず、統一的なインタフェースが提供されていることが望まれます。 JDBC データソースでは、これらの要求を満たすための機能を備えた、JDBC コネクションのファクトリインタフェースを提供します。

3.6.3.1. コネクションプール機能

JDBC データソースは、JDBC Optional Package で規定されているコネクションプール機能を提供します。

JDBC データソースは、JDBC コネクションを解放することなく、内部のプールに管理して再利用します。このため、アプリケーションは、接続にかかるコストを気にすることなく、業務処理を行うたびに、毎回、JDBC コネクションを取得することができます。

JDBC データソースでは、次のとおり、プール管理するコネクションの数を指定することができます。

最大プールサイズ [maxPoolSize]
コネクションプールから同時に払い出されるコネクション数の上限を指定することができます。
最小プールサイズ [minPoolSize]
コネクションプールに常時保持しておくコネクションの数を指定できます。
初期プールサイズ [initialPoolSize]
最初のコネクション払い出しの際に複数のコネクションをまとめてプールすることができます。

また、JDBC データソースでは、次のとおり、プール管理されているコネクションの状態監視を行うことができます。

無通信時間の上限 [maxIdleTime]
コネクションが一定時間使用されなかった場合に、そのコネクションを破棄することができます。
データベースサーバの状態監視オプション [checkServerOption]
定期的にSQL 命令を発行してデータベースの状態を確認し、異常を検知した場合に、コネクションプール内のコネクションを破棄することができます。
コネクションのガベージコレクト機能の動作オプション [checkGarbageOption]
コネクションのクローズ漏れを検知し、クローズやロールバックといった後処理を行うと同時に、そのコネクションが払い出された場所をログに出力することができます。この機能は、デバッグ用の機能です。

ほかに、次のとおり、プール管理されているコネクションの解放契機を調整することができます。

コネクション解放までの待ち合わせ時間 [shrinkDelayTime]
minPoolSize プロパティで指定した数を超えて払い出されたコネクションの解放を一定時間遅らせることができます。それにより、多くのコネクションが同時に利用される負荷が高い状況で、コネクションの接続および切断の頻度を下げることができます。

このように、きめ細やかなコネクションプールの管理を行うことができます。

これらの設定に応じて、コネクションの接続および切断契機は次のようになります。

接続契機

initialPoolSize に、0より大きい数を指定した場合は、指定した数のコネクションが、アプリケーションプロセス起動時に接続されます。ただし、CORBA や単体のJava アプリケーションの場合には、プロセス起動時には接続されません。これらの場合、アプリケーションがコネクション取得API をプロセス内で最初に呼び出した際に、指定した数のコネクション接続が行われます。

initialPoolSize に0を指定した場合は、アプリケーションがコネクション取得API を呼び出した際に、コネクションプール内に未使用のコネクションがない場合に、コネクション接続が行われます。

また、コネクション接続のためのAPI 呼び出しまたは運用操作を実行することで、maxPoolSize で指定された数まで接続を行うことができます。

切断契機

コネクションのクローズを行った時、または、トランザクションが完了した時に、次のいずれかの条件を満たした場合に切断されます。

minPoolSize で指定した数を超えて払い出されたコネクションで、shrinkDelayTime で指定した時間が経過した
使用されないまま maxIdleTime で指定した時間が経過した
コネクション一括破棄のための API 呼び出しまたは運用操作を実行した
checkServerOption の指定により、データベースサーバ側の障害が検出された
checkGarbageOption の指定により、コネクションのクローズ漏れが検出された
JDBC ドライバからコネクション障害が通知された
JDBC データソースのコネクション返却処理で障害が発生した

3.6.3.2. 分散トランザクション連携機能

アプリケーションは、Java Transaction API (JTA)を使用して、2フェーズコミットに参加することができます。複数のデータベースにまたがったトランザクションを実行するような場合には、Transaction サービスによって、データの一貫性が保証されます。特に、EJB のコンテナでトランザクションの管理を行うように設定した場合には、アプリケーションでは、分散トランザクションに参加するための特別な処理を記述する必要はありません。

また、useMultiUsersPerTransaction プロパティを指定することで、接続先のデータベースが同じでユーザアカウントが異なるJDBC コネクションを同一グローバルトランザクション内で同時利用することができます。

3.6.3.3. JNDIサーバとの連携機能

JDBC データソースをJNDI サーバに登録するための運用管理機能を提供しています。 JDBC データソースの運用管理コマンド、または、WebOTX の統合運用管理コマンドや統合運用管理ツールを使用することで、JDBC データソースのプロパティ情報を登録し、JNDI サーバに登録することができます。一度JNDI サーバに登録されたJDBC データソースの情報は、JNDI サーバを再起動した場合にも保持されます。この機能を使うことによって、アプリケーションは、JNDI API やjavax.sql.DataSource インタフェースといったJava 標準のインタフェースを使用してデータベースにアクセスすることができますので、移植性の高いビジネスロジックを記述することができます。

JDBCデータソースの属性やプロパティの変更内容は、JNDIサーバからJDBCデータソースをlookupする時だけでなく、「設定変更内容の反映」操作を実行することでも実際の動作へ反映することができます。

3.6.3.4. コネクション制御機能

JDBC データソースでは、defaultAutoCommit プロパティで、コネクションを払いだす際の自動コミットモードのデフォルト値を指定することができます。デフォルトでは、コネクションを払い出す際に、必ず自動コミットとなるように調整されます。アプリケーションで必ずコミットを発行する場合に、デフォルト値を非自動コミットに設定することで、自動コミットモード変更処理のプログラミングを行う必要がなくなります。ただし、JTA のトランザクションを実行する場合は例外で、必ず、非自動コミットになります。

また、JDBC データソースでは、JDBC 3.0 以降のOracle のJDBC ドライバとバージョン5.3 のSequeLink を利用する場合に、maxStatements プロパティで、ステートメントのプール数を指定することができます。この指定を行うことで、性能を改善することができます。

そのほか、JDBC データソースでは、コネクションの接続に失敗した場合のリトライ回数(connectRetryMax プロパティ) やリトライ間隔 (connectRetryInterval プロパティ)、初期接続の接続リトライ有無 (reconnectInitialPool プロパティ) を指定することができます。

3.6.3.5. コネクションの共有範囲

JDBC データソースでは、コネクションの共有範囲を変更することができます。特別な指定を行わない場合、 jndiName プロパティが同じJDBC データソースインスタンスから払い出されたコネクションは、Java VM (*1) 内で共有されます。このため、同じJava VM 内で動作する複数のアプリケーション間でコネクションを共有することができ、容易に、コネクションの数を最小限に抑えることができます。これに対して、useStaticPool プロパティにfalse を設定すると、同一のJDBC データソースのインスタンスを使用する範囲内に閉じてコネクションが共有されます。

*1: 正確には、Java のクラスローダ内での共有となります。同一のJava VM 内であっても、Web コンテナではコンテキスト毎、EJB コンテナではEJB 毎、アプレットではコードベース毎に、複数のクラスローダが生成されます。

3.6.3.6. コネクションプールのクラスタ制御機能

JDBC データソースでは、複数のJDBC データソースの定義を組み合わせることで、稼動待機、または、負荷分散型でデータベースサーバの呼び出しを行うことができます。

clusterPoolOption プロパティに”roundrobin”を指定した場合は、clusterPoolOption プロパティを指定したJDBC データソースとclusterPoolNames プロパティに列挙したJDBC データソースをラウンドロビンに呼び出します。 clusterPoolNames プロパティに列挙した各JDBCデータソースに重み(clusterPoolWeight)を設定することによって、異なる処理能力のデータベースサーバの負荷を適切に分散できます。重みが高く設定されたJDBCデータソースの使用頻度が高くなり、そのJDBCデータソースのコネクションを優先的に払い出すことができます。これにより、データベースサーバの負荷分散を実現することができます。

また、clusterPoolOption プロパティに”standby”を指定した場合は、最初にclusterPoolOption プロパティを指定したJDBC データソースを使用し、データベースサーバの障害検出時にclusterPoolNames プロパティに列挙したJDBC データソースに切り替えます。この機能と、データベースサーバの障害監視や、初期接続の接続リトライ機能を組み合わせることにより、データベースサーバで障害が発生した際に、復旧時間を短縮することが可能となります。

コネクションプールの切り替え契機は、アプリケーションがコネクション取得API を呼び出した時です。そのため、アプリケーションでは、業務処理を行う際に、その都度、JDBC コネクションを取得する必要があります。

また、JDBC データソースは、JDBC データソースの有効化および無効化操作で一時的にJDBC コネクションの払い出しができないようにすることができます。これにより、運用停止後のデータベースサーバのメンテナンス時に、データベースサーバの監視等で呼び出しが行なわれないようにすることができます。また、クラスタ制御対象のJDBC データソースを呼び出し対象から一時的にはずすこともできます。これにより、アプリケーションからの呼び出しを抑制しながら、JDBC コネクションの接続などの運用操作を実行することができます。また、データベースの動的スケールアウトやスケールインへの対応では、「設定変更内容の反映」操作でClusterPoolNamesなどの設定を動的に変更することができます。

3.6.3.7. データベースとJDBCドライバの対応バージョン

JDBC データソースは、次のデータベースとJDBC ドライバをサポートします。

データベース

Oracle Database 10g Release 2 (10.2.0)
Oracle Database 11g Release 1 (11.1.0)
Oracle Database 11g Release 2 (11.2.0.4)
Oracle Database 12c Release 1 (12.1.0.1.0)
DB2 V9.1
DB2 V9.7
DB2 V10.1
Microsoft SQL Server 2005
Microsoft SQL Server 2012
Sybase Adaptive Server Enterprise 12.5
SequeLink 5.0
Cloudscape 3.0.3
Apache Derby 10.2.2- Apache Derby 10.8.2
PostgreSQL 8.1 (JDBC ドライバ 8.1-401) 以降、 PostgreSQL 9.1.9 (JDBC ドライバ 9.2-1004)まで
InfoFrame Relational Store V2.2

大規模システムや高い性能が要求されるシステムでは、Cloudscape とPostgreSQL 以外のデータベースをお使いになることをお薦めします。

WebOTX Enterprise Edition のインストール時に、InfoFrame Relational Store用のJDBCドライバを選択してインストールすることができます。

JDBC ドライバ

データベースに含まれるJDBC ドライバの他に、次のJDBC ドライバをサポートします。

SequeLink バージョン5.0 以降
UCP for JDBC (Oracle Database 11g Release 1 以降)

その他の製品についても、JDBC 2.0 または、JDBC 3.0、JDBC 4.0、JDBC 4.1 の仕様に準拠しているJDBC ドライバであれば、使用することができます。ただし、十分な評価を行ってください。WebOTX のJava EE の互換性テスト (CTS)では、DataDirect Connect for JDBC バージョン3.6 を使用した実績があります。そのほか、MySQL Connector /J 5.0 の評価実績があります。

どのJDBC ドライバをご利用になる場合でも、アプリケーションでは、その種別を意識した記述を行う必要はありません。JDBC データソースの定義情報を変更し、JNDI サーバに登録し直すことで、使用するJDBC ドライバを切り替えることができます。

3.6.3.8. MySQLとそのJDBCドライバ

MySQL の概要

MySQL はスウェーデンのMySQL AB 社によって開発されている、人気の高いオープンソースのデータベース管理システムです。マルチストレージエンジン・アーキテクチャの採用により、用途や目的に合わせてデータの格納エンジンを変更できることが特徴の一つです。

デュアルライセンス方式を採用しており、利用形態に応じて、商用ライセンスと無償ライセンス(GPL)のいずれかを選択することができます。有償契約により正規のサポートを受けることができ、国内にも複数の代理店を持つなど、ビジネスとしての利用も広がっています。

他のデータベース管理システムと比較して、特に性能を重視した設計となっており、アクセス負荷の高いWeb システムのバックエンドとして採用されるなどの利用実績も豊富です。反面、標準のストレージエンジンではトランザクション機能や外部キーをサポートしないなど、当初、関係データベースとしての機能に多くの制限がありました。

MySQL 3.23.34 およびMySQL 4.0 以降、トランザクションなどをサポートしたストレージエンジンが使用できるようになり、2005年10月にリリースされたMySQL 5.0 では、ストアドプロシージャやトリガー、ビューに対応するなど、機能面での充実が図られるようになりました。今後、高機能化に伴い、エンタープライズ分野での利用範囲が拡大していくものと思われます。

ストレージエンジン

MySQL は、内部データの格納に用いるストレージエンジンとして、次の型を選択することができます。

高速だがトランザクションなどをサポートしない、比較的低機能なMyISAM
若干低速ながらトランザクションなどをサポートする、高機能なInnoDB
MERGE, MEMORY(HEAP), BDB(Berkeley DB), およびその他のストレージエンジン

MyISAM などのトランザクションをサポートしないストレージエンジンでは、自動コミットが行われるため、Java EE トランザクションのトランザクション制御を行うためには利用できません。アプリケーションから直接、java.sql.Connection クラスのcommit やrollback メソッドを呼び出す場合も同様です。

コミットやロールバックといったトランザクションの制御を行うためには、トランザクションをサポートするInnoDBやBDBを利用する必要があります。

JDBC ドライバの概要

MySQL のJDBC ドライバはMySQL Connector/J という名称で、開発元のMySQL AB 社より提供されています。MySQL Connector/J は、Pure Java のType4 のドライバであり、MySQL サーバと直接通信を行います。MySQL Connector/J は、JDBC 3.0 に対応しています。

JTA の実装の制限

MySQL Connector/J は、バージョン5.0 において、JTA(分散トランザクションのためのAPI)に対応しましたが、次の様な制限があります。

使用できるストレージエンジンは InnoDB だけです。
1 トランザクションあたり、1 コネクションしか使用できません。
同一コネクション内で、グローバルトランザクションとローカルトランザクションの切り替えを行うことができません。
データベースサーバの再起動や通信障害が発生した場合、実行中のトランザクションはすべてロールバックされます。そのため、2 フェーズコミットでトランザクションが準備状態になったとしても、コミットの成功が保証されません。

これらの問題に対する、WebOTXでの対応について、[3.6.3.9. WebOTXでのMySQL対応] で説明します。

3.6.3.9. WebOTXでのMySQL対応

MySQL に対するWebOTX の対応方針について説明しています。

汎用のデータソースの種別 "JDBC API"

WebOTX のJDBC データソースでは、JDBC ドライバごとにデータソースの種別として文字列を定義することで、簡単にJDBC ドライバやロードするクラスを変更することができます。しかし、現在のところWebOTX のJDBC データソースはMySQL 専用のデータソースの種別を提供していません。そのため、MySQL に接続する場合、データソースの種別には汎用のデータソースの種別 "JDBC API"を指定します。

WebOTXで専用のデータソースの種別を提供する目的の一つに、JDBCドライバのJTAの機能に対応することがあります。しかし、[JTA の実装の制限] で説明したように、MySQLのJDBCドライバにはJTAの実装に制限があるため、現在のところ専用のデータソースの種別を提供していません。

汎用のデータソースの種別 "JDBC API"を利用することにより、[JTA の実装の制限] で説明した制限のうち、(b)と(c)の制限を解除することができます。また、WebOTXの1 フェーズコミット対応リソースとして扱われるため、2フェーズコミットのトランザクションに参加することができます。

3.6.3.10. MySQLの適用領域

WebOTXで推奨するMySQLと各ストレージエンジンの適用領域について説明します。

InnoDB ストレージエンジンの適用領域

ストレージエンジンにInnoDB を使用する場合、汎用のデータソースの種別 "JDBC API"を指定することで、1 フェーズコミット対応リソースの機能により2 フェーズコミットを実現することができます。しかし、この機能にはいくつかの制限があるため、高い信頼性を求められるミッションクリティカルなシステムでの利用には適していないといえます。2 フェーズコミットを行う必要がある場合は、Oracle などの、２フェーズコミットをサポートしていて実際に運用実績のあるRDBMS を利用するべきです。そのため、次のようなシステムで利用することを推奨します。

ミッションクリティカルでない、1 フェーズコミットだけを行うシステム

MyISAM ストレージエンジンの適用領域

ストレージエンジンにMyISAM を使用する場合、トランザクション制御を行うことができないという制限があります。そのため、Java EE のトランザクション制御を行う場合には利用できません。その代わり、実行性能ではInnoDB を上回っており、データ更新の取り消しが必要のない次の様な用途で利用することが考えられます。

トランザクションデータやログの格納域
キャッシュなどの一時的なデータの管理

MySQL の適用領域

InnoDB 、MyISAM より、MySQLは比較的単純な、または、高速に処理を行う必要のあるデータを扱う場合に、その利点が生かされるといえます。また、導入コストが低く抑えられるだけでなく、オープンソースソフトウェアでありながらサポートも充実しているなど、業務での利用に適した面があります。反面、分散トランザクション環境下のシステムでの利用に適していないなど、注意が必要な面もあります。更に商用での利用実績において、他のデータベース管理システムに及ばないという課題もあります。

3.6.4. JMS

Java Message Service (JMS) とは、Java で非同期通信を実現するための標準 API です。この API を使用することで、メッセージ作成や、キューやトピックと呼ばれる宛先(デスティネーション)を介したメッセージ送受信を容易に行うことができます。

WebOTX JMS は、JMS 1.1 に準拠した機能を提供しています。また、JCA 1.5 に準拠したリソースアダプタ機能や、JMX 1.2 に対応した運用管理機能をサポートしています。

3.6.4.1. JMSの概要

JMS の概要について説明します。

メッセージングモデル

WebOTX JMS では、次の2つのメッセージングモデルを提供します。配信対象のコンシューマアプリケーションの数に応じて、お使いになるモデルを選択してください。

ポイントツーポイント(PTP)

1つのプロデューサアプリケーションが、ただ1つのコンシューマアプリケーションにメッセージを送信する1対1通信のモデルです。デスティネーションオブジェクトを拡張したキューと呼ばれる名前付のオブジェクトを使います。プロデューサはこのキューにメッセージを送信し、コンシューマはこのキューからメッセージを受信します。

図3.6.4.1-1

パブリッシュ／サブスクライブ(Pub/Sub)

1つのプロデューサアプリケーションが、複数のコンシューマアプリケーションにメッセージを送信する1対ｎ通信のモデルです。デスティネーションオブジェクトを拡張したトピックと呼ばれる名前付オブジェクトを使います。ポイントツーポイントとは異なり同じメッセージを複数のコンシューマが受信することができます。

図3.6.4.1-2

メッセージタイプ

WebOTX JMS では、次の5つのメッセージタイプを提供します。 JMS クライアントアプリケーション間で交換したいデータの構成に応じて選択することができます。

BytesMessage

バイト配列のメッセージです。コンシューマは受け取ったバイト配列の内容を解釈できる必要があります。

TextMessage

String 型のメッセージです。

MapMessage

「String オブジェクトの名前」と「Java プログラミング言語のプリミティブデータ型の値」のセットのメッセージです。名前を指定してランダムに値を読み込むことができます。

StreamMessage

Java プログラミング言語のプリミティブデータ型の値を含むStream のメッセージです。ランダムに値を読み書きすることはできません。コンシューマは、プロデューサが書き込んだ順番で読み込む必要があります。

ObjectMessage

Java プログラミング言語の直列化可能なオブジェクト (Java オブジェクト) のメッセージです。

メッセージの永続性モード

WebOTX JMS では、メッセージ配信に関して、次の2つの永続性モードを提供します。メッセージの重要性に関して、2つのモードを選択することができます。

NON_PERSISTENT モード

メッセージは永続ストアに格納されず、回線障害等の要因でロストし、配信されないことがあります。ただし永続ストアにアクセスするためのオーバーヘッドが無いので高速なメッセージ配信を行うことができます。

PERSISTENT モード

メッセージは永続ストアに格納され、信頼性の高い配信を行うことができます。ただし永続ストアへのメッセージ格納のオーバーヘッドは発生します。

WebOTX JMS では、永続データの格納先として、標準で提供しているファイルベースのデータストア、もしくはJDBC 対応データベースを利用することができます。

メッセージの確認応答

PERSISTENT モードの場合、プロデューサから送信されたメッセージは、WebOTX JMS によって永続ストアに格納された後、コンシューマに送信されます。コンシューマでは、受信したメッセージに対して acknowledge メソッドを呼び出して、メッセージ受信完了をWebOTX JMS に通知する必要があります。この通知を確認応答と呼びます。

WebOTX JMS では、コンシューマからの確認応答を受けて、該当するメッセージを確認応答受信待ちリストから削除し、メッセージの永続情報を削除します。コンシューマは必要に応じてWebOTX JMS に「確認応答を行っていないメッセージ」の再送要求を行うことができます。

WebOTX JMS では、次の4つの確認応答モードを提供します。

AUTO_ACKNOWLEDGE

WebOTX JMS で自動的に確認応答を行います。このモードでは、メッセージを受信するたびに毎回確認応答を発行します。コンシューマが明示的に確認応答を行う必要はありません。ただしメッセージの再送要求を行うことはできません。

CLIENT_ACKNOWLEDGE

コンシューマがWebOTX JMS 提供のインタフェースを呼び出し、確認応答を行います。配信されたメッセージそれぞれに確認応答を行うこともできますが、配信された複数のメッセージに対して一括して確認応答を行うこともできます。また必要に応じてメッセージの再送要求を行うことができます。

DUPS_OK_ACKNOWLEDGE

WebOTX JMS で自動的に確認応答を行います。このモードの動作はJMS の実装に依存しており、WebOTX JMS では、10件のメッセージを受信すると確認応答を発行します。また必要に応じてメッセージの再送要求を行うことができます。

Caution
WebOTX V5 では、このモードは、AUTO_ACKNOWLEDGE と同様の動作 (メッセージを受信するたびに毎回確認応答を発行) をしていました。

NO_ACKNOWLEDGE

確認応答が不要なWebOTX JMS 独自の拡張モードです。確認応答のための通信が行われないため高速な配信が行えますが信頼性は低下します。メッセージの再送要求も行うことはできません。

メッセージの同期受信と非同期受信

WebOTX JMS ではコンシューマがメッセージを受信するときのモードとして次の2つを提供します。

同期受信

メッセージが配信されるまでコンシューマアプリケーションはブロックされます。配信されるメッセージがない場合に、指定した時間が来るまでブロックされるようにしたり、まったくブロックされないようにしたりすることも可能です。

非同期受信

メッセージが配信されている、いないにかかわらずコンシューマアプリケーションはブロックされません。ただし、配信されたメッセージを受け取るためのリスナを登録する必要があります。メッセージが配信されるとこのリスナに通知され、コンシューマアプリケーションはメッセージを受信することができます。

コンシューマがメッセージ受信を待ち合わせている間に回線障害など、システムに障害が発生した場合、待ち合わせしているスレッドに異常が通知されない場合があります。WebOTX JMS ではシステムに障害が発生した場合にアプリケーションに異常を通知する機能を提供しています。コンシューマは、メッセージを受信するために使うコネクションオブジェクトごとに例外リスナを登録することで該当するコネクションに障害が発生した場合、例外通知を受けることができます。この例外通知を受け取って必要な復旧処理を行うことができます。

トランザクション

JMS でのトランザクションは、プロデューサからのメッセージ送信、コンシューマでのメッセージ受信を最小単位としています。

プロデューサからのコミット要求でコンシューマへのメッセージ配信が開始され、コンシューマからのコミット要求でJMS サーバ内のメッセージが削除されます。また、プロデューサからロールバックが要求されると送信したメッセージは破棄され、受信したメッセージはJMS サーバ内で保持されます。ロールバックされたメッセージは、トピックの場合は同じサブスクライバに対して再送されますが、キューの場合はどのレシーバに再送されるかは規定されていません。

WebOTX JMS ではトランザクションを制御する方法として以下の2つの方法を提供します。1つ目は、JMS のローカルトランザクションを使用する方法で、2つ目は分散トランザクションを使用する方法です。それぞれの方法について以下に説明します。

ローカルトランザクション

JMS でローカルトランザクションを使用する場合は、Session オブジェクト生成時に、transacted パラメータにtrue を指定して、トランザクションセッションを生成する必要があります。トランザクションは最初にメッセージを送受信した時点で自動的に開始され、以降はコミット／ロールバックした時点で自動的に次のトランザクションを開始します。

分散トランザクション

JMS を分散トランザクションに参加させるには、JMS が提供するリソースアダプタを使用する必要があります。また、2フェーズコミットメントを使用する場合は、使用するリソースアダプタをトランザクションサービスのJCA リソースとして登録する必要があります。

トランザクションセッションではWebOTX JMS がトランザクション処理を行うため独自の確認応答の制御を行います。したがってクライアントアプリケーションはメッセージの確認応答の制御を行うことはできません。確認応答モードの設定は無視されます。

トランザクションセッションの使い方については [ アプリケーション開発ガイド（Java EE） > 7. JMSアプリケーションの開発 > 7.2. プログラミング・開発ガイド > 7.2.5. その他の機能を使用したプログラムの開発 > 7.2.5.3. JMSのトランザクション機能を使用したプログラム ] を参照してください。

メッセージのフィルタリング

WebOTX JMS のメッセージには、メッセージの属性を表す標準のヘッダフィールドと、アプリケーション固有の情報を含めることができるプロパティフィールドがあります。

JMS サーバではプロデューサから送信されたメッセージのヘッダフィールド、プロパティフィールドに格納されている情報をもとにメッセージのフィルタリングを行い、必要なメッセージだけをコンシューマに配信することができます。フィルタリングにはセレクタと呼ばれる単純な構文の文字列を使い、コンシューマを作成するときに指定します。

フィルタリングを使って不要なメッセージの配信を抑制することでネットワークへの負荷を軽減する効果も得られます。

メッセージのフィルタリングの使い方については [ アプリケーション開発ガイド（Java EE） > 7. JMSアプリケーションの開発 > 7.2. プログラミング・開発ガイド > 7.2.5. その他の機能を使用したプログラムの開発 > 7.2.5.2. メッセージのフィルタリングを使用したプログラム ] を参照してください。

3.6.4.2. メッセージのスケジューリング

WebOTX JMS では、メッセージの配信時間をスケジューリングする独自の拡張機能を提供しています。プロデューサは、将来のある特定の時間にメッセージをコンシューマに配信することができます。

また、WebOTX JMS では「確認応答を行っていないメッセージ」の再配信時間を遅延させる機能を提供しています。障害などでコンシューマがメッセージを受信する準備ができていないときに、メッセージの再配信を遅延させて、その間にメッセージを受信するための準備を行うことができます。

メッセージのスケジューリングの使い方については [ リファレンス集開発編（共通） > 3. リソース > 3.2. JMS > 3.2.2. 拡張インタフェース ] を参照してください。

Caution
WebOTX JMS V6 以降では、V5 で規定した拡張インタフェースのAPI 仕様を変更しています。V5 で作成したアプリケーションは変更する必要があります。

3.6.4.3. メッセージフロー制御

メッセージが滞留するような状況 (高負荷、コンシューマ遅延、コンシューマ不在) になると、メモリ不足によりパフォーマンス低下やプロセスダウンなどの問題を引き起こす可能性があります。WebOTX JMSでは、このような問題を未然に防ぐために、次のようなメッセージフロー制御に対応しています。

JMS サーバでの滞留抑止

サーバ単位での制御

すべての送信先で滞留するメッセージを監視して、JMS サーバ内での滞留を抑止することができます。サーバ全体で滞留可能なメッセージの最大数と総メモリ量を設定して制御します。

この他に、1つのメッセージで許容するサイズを制限する機能や、滞留しているメッセージの有効期限をチェックする間隔を設定して定期的にメモリを回復させる機能も提供します。

送信先レベルでの制御

送信先に滞留するメッセージを監視して、JMS サーバ内での滞留を抑止することができます。送信先単位で、滞留可能なメッセージの最大数、総メモリ量、そしてその制限到達時の振る舞いを設定して制御します。制限到達時の振る舞いには、以下のものがあります。

FLOW_CONTROL : プロデューサからの送信をスローダウンします。
REMOVE_OLDEST : 滞留中の最古のメッセージを破棄します。
REMOVE_LOW_PRIORITY : 滞留中の最低プライオリティのメッセージを破棄します。
REJECT_NEWEST : メッセージの受付を拒否します。

Caution
これらの振る舞いは、WebOTX V5 の送信先生成時に指定した「メッセージ廃棄ポリシー」に相当しますが、WebOTX V5 のLIFO に対応する振る舞いはサポートしていません。

メモリ監視による制御

メモリ使用量を監視して、4つの状態 (green: 使用可能なメモリが十分にある、yellow: JMS サーバのメモリが減っている、orange: JMS サーバのメモリが不十分である、red: JMS サーバのメモリが不足している) に応じたメモリ回復のための制御として、GC (Garbage Collector)の実行、メッセージの受付抑止、JMS クライアントの接続拒否を行います。状態毎のメモリ使用率、メッセージフローカウントを設定して制御します。

それぞれの状態に遷移した際に行われる制御は次のとおりです。

green : 指定されたメッセージフローカウントに到達すると受付を抑止します。 GCは行いません。
yellow : 指定されたメッセージフローカウントに到達すると受付を抑止します。 GCを1回行います。
orange : 指定されたメッセージフローカウントに到達すると受付を抑止します。 GCを5回行います
red : 指定されたメッセージフローカウントに到達すると受付を抑止します。 GCを10回行います。

JMS クライアントでの滞留抑止

コネクションレベルでの制御

コンシューマでのメッセージ処理が遅延すると、JMS クライアントに配信され続けるメッセージがJMS クライアント内に滞留することになります。これを抑止するためには、コネクション上のすべてのコンシューマ群での滞留可能なメッセージ数の制限値をコネクションファクトリに設定して制御します。JMS サーバは、この制限値に到達するとメッセージの配信を停止し、下回ると配信を再開します。

コンシューマレベルでの制御

個々のコンシューマ単位に、滞留可能なメッセージ数の制限値と配信を再開するポイントをコネクションファクトリに設定して制御します。JMS サーバは、この制限値に到達するとメッセージの配信を停止し、配信再開値を下回ると配信を再開します。

この制御は、マルチコンシューマ間の負荷分散や、混在するコンシューマ間で相互に影響を与えないようにするために有効です。

その他のフロー制御

制御メッセージのフロー促進

JMS サーバとクライアントの間では、メッセージの送受信だけでなく、確認通知のような数多くの制御データもやり取りされています。そのため、JMS サーバからクライアントに対するメッセージ配信が連続するような高負荷が続くと、確認通知が遅延することによってメッセージの滞留につながる場合があります。

この問題を回避するためには、メッセージを連続して配信する数の制限値をコネクションファクトリに設定して制御します。JMS サーバは、この制限値に到達すると一時的にメッセージの配信を停止して制御データのフローを促進します。

制御データを数多く使用するのは、次のような機能を利用する場合です。

CLIENT_ACKNOWLEDGE、AUTO_ACKNOWLEDGE モード
メッセージの永続化
トランザクション
キューブラウザ
Broker への接続／切断繰り返し

3.6.4.4. マルチコンシューマ負荷分散

WebOTX JMS では、接続している複数のコンシューマへの負荷分散配信機能を提供します。

Queue の場合

負荷分散の対象とするアクティブなコンシューマの数とそのバックアップとなるコンシューマの数を送信先に設定すると次のように制御します。

アクティブなコンシューマの数とそのバックアップとなるコンシューマの数の合計値を超えるコンシューマの接続は拒否します。
当該Queue に接続した順序で、設定した最大数個分のアクティブなコンシューマに対してメッセージを1個以上バッチ的に順次配信します。その数はメッセージの滞留状況に応じて変化しますが、コンシューマで許される滞留数を超えることはありません。
アクティブなコンシューマへの配信が失敗した場合、バックアップの先頭のものをアクティブなコンシューマとして扱います。

Caution
WebOTX V5 ではQueue に接続している複数のコンシューマへの配信は不定でした。

Topic の場合

Standard / Enterprise において、メッセージ・ドリブン Bean (MDB) やJMS の非同期受信を行うCOBRA アプリケーションをTP モニタ上で起動する場合、その多重度の設定によっては複数のコンシューマが動作します。WebOTX JMS では、自動的に複数のコンシューマをひとつのグループとして扱い、Topic からの配信を同じグループの中のひとつのコンシューマに対してだけ行うように制御します。

グルーピングするには、次の情報を一致させる必要があります。

クライアント識別子
サブスクリプション識別子（DurableSubscriber の場合）
セレクタ

クライアント識別子は、次の方法で設定することができます。

コネクションファクトリリソースの属性に設定（統合運用管理ツール、運用管理コマンド）
プログラム上でConnection.setClientID()メソッドで設定 *CORBA アプリケーションのみ
配備記述子で設定 *MDB のみ

CORBA アプリケーションの場合は、明示的に設定しなくても、デフォルトでアプリケーショングループ名_プロセスグループ名が設定されます。MDB の場合は、クライアント識別子の共有を許可するフラグと共に必ず明示的に設定する必要があります。

3.6.4.5. セキュリティ

WebOTX JMS では、ユーザ認証、アクセス制御、メッセージの暗号化の3つのセキュリティ機能を提供します。

ユーザ認証

JMS クライアントからのコネクション確立時に、指定したユーザ名とパスワードをあらかじめ定義されたユーザ管理情報と照合して認証を行います。

アクセス制御

JMS クライアントからの操作 (コネクション、送信先、送信先自動作成) に対して、あらかじめ定義されたアクセス制御情報を照合して承認を行います。

メッセージの暗号化

Java Secure Socket Extension (JSSE)に基づいた、サーバの自己署名型証明書によるメッセージのSSL暗号化に対応しています。メッセージを暗号化することで、機密性の高い重要な情報が外部に漏れないようにすることができます。

3.6.4.6. データストア

WebOTX JMS では、永続化すべきデータの格納先として、標準で提供しているファイルベースのデータストア、もしくはJDBC 対応データベースを利用することができます。データストアには、次のような情報が格納されます。

メッセージ
送信先
永続サブスクリプション
トランザクション

3.6.4.7. コネクション制御スレッドのプール管理

WebOTX JMS では、コネクションサービスでJMS クライアントとJMS サーバとの間で確立されるTCP コネクションを管理しています。これらのコネクションに必要なスレッドは、プール管理して有効に利用できるようになっています。プール管理はスレッドの最小数と最大数の2つを指定して制御します。

コネクションを確立してスレッドが必要になると、確保したスレッドをスレッドプールに順次追加していきます。最小数を超えると、コネクションを解放するタイミングに不要になったスレッドを、最小数を下回らない範囲で解放します。一時的な高負荷で最大数に到達した場合、それ以上の新たなスレッドは確保せずに、スレッドの空きができるまで待ち合わせます。

また、プール管理されたスレッドリソースを、TCP コネクションとどのように対応づけるかを管理モデルとして選択できます。

dedicated: スレッド専用モデル
1つのコネクションに対して、受信用と送信用の2つのスレッドを固定的に割り付ける方式です。高いパフォーマンスを得ることができますが、実際に接続できるコネクションの数は最大数の半分になります。
shared: スレッド共有モデル
1つのコネクションに対して、固定的にスレッドを割り当てず、実際に送受信処理が必要になった時点でスレッドを動的に割り当てる方式です。動的な割り当てを行う監視スレッドは、監視対象コネクション数のプロパティに指定された複数のコネクションの入出力事象を監視します。

コネクションサービスは、サービスタイプとプロトコルタイプ別に4種類(jms、admin、ssljms、ssladmin) 存在します。

3.6.4.8. 送信先の自動生成

WebOTX JMS では、送信先の自動生成をサポートしています。通常は、運用管理コマンドなどからあらかじめ送信先を定義しておく必要がありますが、この機能を有効にすることにより、必要なタイミングで送信先が自動生成されるようになります。ただし、自動生成される送信先は、メッセージが存在しないと一定時間経過後に削除されますので、開発時の簡単な動作確認などの場合に有効です。

この機能を利用する場合には、あらかじめアクセス制御で許可しておく必要があります。

3.6.4.9. 再配信の遅延と回数制限

ロールバックされたメッセージを再配信する時間の遅延と、再配信回数を制限することができる機能です。

遅延の設定については、コンシューマ用のAPI や、コネクションファクトリの属性でコンシューマごとに設定可能です。また、メッセージ・ドリブン Bean (MDB) では、コネクションファクトリの属性か配備記述子で設定可能です。

再配信回数を制限は、コンシューマが処理できないメッセージの存在が原因で、再配信が延々と行われるような状況に陥り、システム全体のスループットが低下してしまう事態を未然に防ぐような場合に利用します。再配信回数の制限値に到達したメッセージは破棄されますが、破棄せずに別の送信先に蓄積することもできます（破棄メッセージの転送機能）。再配信の遅延時間と回数は、送信先の属性か、JMS サービスの属性として設定します。

3.6.4.10. 破棄メッセージの転送機能

再配信の回数制限値を超過したメッセージ(不達メッセージ)や、有効期限に到達したメッセージはデフォルトでは破棄されますが、これらをあらかじめ用意した送信先に転送することができる機能です。この送信先からメッセージを取得するプログラムを作成し、ロギングやリカバリを行う処理を組み込むことが可能になります。

不達メッセージの転送先は、送信先の属性か、JMS サービスの属性として設定します。また、有効期限切れの転送先は、JMS サービスの属性として設定します。

JMS サーバクラスタの場合、転送先はコンシューマのホームブローカの送信先になります。

3.6.4.11. クライアント・サーバ間の相互監視

WebOTX JMS は、サーバとクライアント間の相互通信にTCP/IP プロトコルを利用していますが、データ受信を主体としている場合、ネットワークの異常を検知できないような事象（簡単な例だと、相手側のケーブルが抜けたような場合）が発生する場合があり、次のような問題を引き起こす可能性があります。

JMS サーバが、クライアントの異常を検知できずに、クライアントに関するリソースがパージできない。
JMS クライアントが、サーバの異常を検知できずに、メッセージ配信を待ち続けてしまい、JMSサーバのクラスタ切り替えに対応できない。

このような問題を防ぐために、クライアントアプリケーションのライブラリレベルで、JMS サーバとの接続を定期的にチェックする機能を提供しています。この機能はデフォルトで動作しますが、監視間隔は変更することができます。

3.6.4.12. JMSサーバクラスタ

JMS サーバの多重化を行うための機能です。JMS クライアントの接続数や、送受信メッセージ数の増加に応じて、JMS 利用システムを拡張することが可能になります。また、メッセージ・ドリブン Bean (MDB) 利用アプリケーションや、ESB によるメッセージ処理の負荷分散や異常時のサービス継続を実現します。

例えば、

トピックによる情報配信を行うシステムで、クライアント数の増加によるネットワークリソース消費を多重化したサーバに分散
キューによる業務受付を行うシステムで、コネクション切断により、コンシューマアプリケーションのダウンを検出し、多重化したキューに接続している他のアプリケーションに転送

といった利用法が考えられます。

ドメイン単位に1つのJMS サーバを起動しますので、JMS サーバの多重化を行う場合は、多重化する数だけドメインが必要になります。

図3.6.4.12-1

図3.6.4.12-2

クラスタを構成するJMS サーバは、他のすべてのJMS サーバと相互に接続して、送信先の生成／削除、コンシューマの登録／削除といった情報を交換します。

クライアントは、コネクションファクトリの「アドレスリスト」を利用して、クラスタ内の1つのJMS サーバと直接通信し、そのJMS サーバが唯一のJMS サーバであるかのようにメッセージの送受信を行います。実際には、クライアントが接続しているJMS サーバが他のJMS サーバと協調動作し、接続中のすべてのクライアントに対してメッセージ配信サービスを提供します。

クライアントの接続先は、JMS クライアントランタイムが、コネクションファクトリに設定された「アドレスリスト」から、プライオリティ(リストに記述された順番)、あるいは、ランダムに決定します。これにより、複数のJMS サーバ間でクライアントコネクションを分散させることが可能となります。

以降、JMS サーバクラスタ構成でのメッセージの送受信や、JMS サーバ間での情報の送受信の動作について説明します。

JMS サーバクラスタ内のメッセージ送受信

JMS サーバクラスタ構成では、各JMS サーバが送信先とコンシューマに関する以下の情報を共有しています。

クラスタ内のすべての物理的な送信先の名前、タイプ、および属性
各コンシューマの名前、場所、および配信対象メッセージ
送信先や、コンシューマに対する更新 (削除、追加、または再設定)

これらの情報によって、各JMS サーバは、自身に接続しているプロデューサからのメッセージをリモートのコンシューマに配信することができるようになります。

一方、クライアントは、1つのJMS サーバに接続し、それがクラスタ内の唯一のJMS サーバであるかのようにメッセージの送受信を行います。このクライアントが接続したJMS サーバを「ホームブローカ」と呼びます。

クライアントの接続先は、一度接続すると以降は固定で、動的に変更されません。

上記のとおり、各JMS サーバはコンシューマの情報は共有しますが、プロデューサの情報は共有しません(プロデューサが追加されても、その情報はクラスタ内には伝播しません)。プロデューサから送信されたメッセージは、ホームブローカ上の送信先にのみ存在し、ホームブローカは、ローカル、リモートにかかわらず、受信可能なコンシューマが存在すればメッセージを配信するようになっています。

JMS サーバクラスタ内の送信先

物理的な送信先は、以下のような作成方法の違いによって、クラスタ内での伝播情報が異なります。

運用管理コマンドや、統合運用管理ツールから作成した送信先
自動作成された送信先
一時送信先

次に、伝播するものの一覧と、その範囲を示します。

表3.6.4.12-1
送信先種別	JMS サーバクラスタ内での情報伝播
運用管理コマンド／統合運用管理ツールで作成	作成	伝播する。
運用管理コマンド／統合運用管理ツールで作成	削除	伝播する。
自動生成	作成	プロデューサが接続する送信先が存在しない場合: 伝播しない。プロデューサのホームブローカ上にのみ送信先が作成される。コンシューマが接続する送信先が存在しない場合: 伝播する。
自動生成	削除	管理コマンドでの削除: 伝播する。自動削除: 伝播しない。自動作成された送信先は、以下の場合には、JMS サーバ毎に削除される。一定時間、コンシューマまたはメッセージがない場合 JMS サーバの再起動時に、その送信先にメッセージがない場合
一時	作成	伝播する。
一時	削除	伝播する。

送信先の属性

送信先の属性は、クラスタ内のJMS サーバに伝播するものとしないものがあります。次に、その一覧を示します。

server.jms-service.jms-physical-destination.physical-destination-name :

表3.6.4.12-2
属性名		JMS サーバクラスタ内での情報伝播
コンシューマへのフロー制限数	consumerFlowLimitNum	伝播する
制限到達時の振る舞い	limitBehavior	伝播する
アクティブコンシューマの最大数	maxNumActiveConsumers	伝播する
バックアップコンシューマの最大数	maxNumBackupConsumers	伝播する
ローカル配信のみ	isLocalOnly	伝播する
ローカル配信優先	localDeliveryPreferred	伝播する
再配信時の順序保証	supportOrderedRedelivery	伝播する
再配信遅延時間	wojmsRedeliveryDelay	伝播する
再配信回数	wojmsRedeliveryLimit	伝播する
不達メッセージ転送先	wojmsRedeliveryDestination	伝播する
1メッセージ当たりの最大サイズ	maxBytesPerMsg	伝播しない
メッセージの最大数	maxNumMsgs	伝播しない
プロデューサの最大数	maxNumProducers	伝播しない
メッセージの最大合計サイズ	maxTotalMsgBytes	伝播しない

JMS サーバクラスタの同期化

JMS サーバクラスタ環境では、以下の情報が、すべての起動中のJMS サーバに即座に伝播するようになっています。

クラスタ内のすべての物理的な送信先の名前、タイプ、および属性
各コンシューマの名前、場所、および配信対象メッセージ
送信先や、コンシューマに対する更新 (削除、追加、または再設定)

しかし、障害などで停止していたJMS サーバはこれらの変更通知を受け取ることができません。

この問題に対処するため、クラスタ内に、変更情報を記録するためのJMS サーバとして、「マスターブローカ」を設定することができます。再起動するJMS サーバは、マスターブローカが記録した変更情報を参照して、必要な更新を行ってから起動するため設定情報の同期を取ることが可能です。

マスターブローカは、JMS サーバクラスタ内で1つ設定します。マスターブローカを設定した場合、クラスタ内のJMS サーバはマスターブローカであるJMS サーバの起動を待ち合わせます。また、マスターブローカに障害が発生した場合、以下の操作は行うことができません。それ以外のメッセージ送受信などの処理はそのまま継続できます。

物理的な送信先の生成／削除／プロパティ更新
永続サブスクリプションの削除

マスターブローカを設定しなかった場合、障害発生などで停止しているJMSサーバには、設定変更を反映することができません。

3.6.4.13. 再配信メッセージの順序保証

JMS サーバは、効率よくメッセージを配信するために、「メッセージフロー制御」で説明した機能により、メッセージをあらかじめコンシューマに事前配信しています。そのため、トランザクションのロールバックによってメッセージの再配信が行われた場合、そのメッセージは事前配信されたメッセージ群の最後尾に位置づけられてしまい、配信順序が狂ってしまいます。

図3.6.4.13-1

このように、トランザクションのロールバックが発生した場合でも配信順序を保証するための機能が「再配信メッセージの順序保証」です。フロー制御の設定は無効になり、メッセージの受信が確定するまでは、事前配信を行わないようにします。設定は、物理的な送信先単位に行います。

図3.6.4.13-2

再配信メッセージの順序保証が利用できるのは、次の環境に制限されます。

送信先タイプはキューであること
JMS サーバクラスタ構成では、送信先の「ローカル配信のみ (isLocalOnly) 」の設定を有効(true) にして、ローカルコンシューマ (送信先が作成されたブローカに接続しているコンシューマ) だけにメッセージを配信するようにおく必要があります。
コンシューマのメッセージ受信はトランザクション内で行われること
送信先に接続するコンシューマ数は1であること
送信先に接続できるコンシューマ数は、1に制限されます。また、メッセージ・ドリブン Bean (MDB) の場合は、多重度を1に制限しておく必要があります。

3.6.4.14. 他社JMSプロバイダ接続

JCA1.5 準拠の汎用的なJMS リソースアダプタを提供します。

メッセージ・ドリブン Bean (MDB) や ESB(JMS BC) において、リソースアダプタが提供されていない他社 JMS プロバイダとの間でコネクションプール機能や XA トランザクションを利用したシステム連携が可能になります。

3.6.4.15. メッセージ送信機能

送信先に対する操作により、メッセージを送信する機能です。

コンシューマアプリケーションの開発や環境構築において、プロデューサアプリケーションを作成することなく、受信動作や設定の評価で利用できます。また、簡単なものであれば、コマンドベースでの送信機能を構築することができます。

次に、本メッセージ送信機能でサポートする設定項目を示します。なお、1回の操作で送信できるメッセージは 1件です。

表3.6.4.15-1
設定項目	説明	既定値
メッセージタイプ	送信するメッセージのタイプ次のタイプを指定可能。 TextMessage : メッセージボディにString を含むもの Message : メッセージボディのない軽量なメッセージ BytesMessage : メッセージボディにバイト配列を含むもの	TextMessage
メッセージボディの指定方法	メッセージボディの指定方法 text : メッセージボディに指定された文字列をボディそのものとして設定 file : メッセージボディに指定された文字列をファイル名として、指定されたファイルの内容をメッセージボディに設定	text
メッセージボディ	メッセージボディ TextMessage の場合 : メッセージボディタイプのtext、file をサポート。 Message の場合 : メッセージボディなし。指定されていても無視する。 BytesMessage の場合 : メッセージボディタイプはfileのみ有効。指定されたファイルの内容をバイト配列に変換して設定する。	-
配信モード (JMSDeliveryMode)	メッセージを永続化するかどうか PERSISTENT : 永続化する NON_PERSISTENT : 永続化しない	PERSISTENT
有効期限 (JMSExpiration)	メッセージの有効期限(ミリ秒)	0 (有効期限なし)
優先順位 (JMSPriority)	メッセージの優先順位(0-9)	4
相関ID (JMSCorrelationID)	メッセージを対応付けるための文字列指定可能な値は、String のみ。	-
応答用送信先 (JMSReplyTo)	メッセージを受信したコンシューマが返信する送信先	-
応答用送信先のタイプ	応答用送信先のタイプ	queue
タイプ (JMSType)	任意の文字列	-
配信遅延時間	配信遅延時間 WebOTX JMS 固有の拡張機能で、相対時間(秒)での指定のみ可能。	0 (遅延時間なし)
メッセージプロパティ	メッセージプロパティ設定可能なプロパティ値は、String のみ。	-

3.6.4.16. コネクションクローズ機能

JMS サービスに対する運用操作として、JMS クライアントとのコネクションを強制的にクローズする機能です。

何らかの異常が発生しているJMS クライアントのコネクションを強制的にクローズすることで、占有しているネットワークリソースの解放や、JMS クライアントが実装する例外リスナによる復旧を試みることができます。

図3.6.4.16-1

3.6.4.17. メッセージ移動機能

送信先に対する運用操作として、送信先に滞留している通常メッセージや、不達メッセージ(再配信回数の上限を超えたメッセージ)、有効期限切れのメッセージを別の送信先に移動する機能です。

本機能は、ローカルトランザクションを利用して、移動元から受信したメッセージを移動先へ送信するようなアプリケーションとして実装しています。

Memo
WebOTX V8 では有効期限切れメッセージは対象外でした。

通常メッセージの移動

送信先に滞留しているJMS メッセージを別の送信先に移動します。

たとえば、ある送信先に接続しているコンシューマにおいて処理が遅延していたり、障害により処理が停止していたりするような場合に、メッセージを移動して別の送信先のコンシューマに肩代わりさせることができます。

図3.6.4.17-1

不達メッセージの移動

再配信回数の上限超過で転送先に移されたメッセージを、本来の送信先に戻す、あるいは、別の送信先に移動します。

これまでは、コンシューマの障害などにより不達メッセージの転送先に移動されたメッセージを再度処理させる場合、転送先にコンシューマを接続しなければなりませんでした。このような場合に、コンシューマの障害復旧後に本機能を利用することにより、不達メッセージを本来の送信先で再度処理させる、別の送信先で処理させることができます。

図3.6.4.17-2

図3.6.4.17-3

有効期限切れメッセージの移動

有効期限切れで転送先に移されたメッセージを、転送前の送信先に戻す、あるいは、別の送信先に移動します。

これまでは、転送先に移動された有効期限切れメッセージを再度処理する場合、転送先にコンシューマを接続しなければなりませんでした。このような場合に、本機能により移動先を指定することで、有効期限切れメッセージを転送前の送信先や、別の送信先で処理させることができます。なお、移動後のメッセージには有効期限は設定されません。

図3.6.4.17-4

図3.6.4.17-5

3.6.4.18. 滞留メッセージの優先順位変更

送信先に滞留しているメッセージの優先順位を変更するための機能です。

たとえば、障害からの復旧後、送信先に滞留しているメッセージのうち、優先的に処理したいメッセージの優先順位を変更することによって、先にコンシューマに配信することが可能になります。

図3.6.4.18-1

3.6.4.19. イベント通知機能

コネクション切断／再接続や、送信先に対するコンシューマの存在に関するイベントを通知する機能です。

コネクションイベント通知

コネクションイベントリスナを利用することによって、コネクション切断や、コネクション再接続のタイミングで通知を受けることが可能になります。通知されるイベントでは、コネクションが切断された理由や、どのJMSサーバに再接続したかなどの情報が取得できます。

次に、コネクションイベントリスナが通知するイベントと、イベントから取得できる情報を示します。

表3.6.4.19-1
イベント	説明
ConnectionClosedEvent	JMSサーバとの接続がクローズしたことを通知する。イベントオブジェクトから次の情報を取得できる。コネクションがクローズされた原因を示すコード CONNECTION_CLOSED_ERROR ： JMSサーバ側のエラーによるクローズ CONNECTION_CLOSED_KILL ：管理者がコネクションをクローズ CONNECTION_CLOSED_LOST_CONNECTION ：ネットワークやJMSサーバ異常によるクローズ CONNECTION_CLOSED_SHUTDOWN ：管理者がJMSサーバをシャットダウンしたことによるクローズコネクションオブジェクト接続していたJMSサーバのアドレスコネクションがクローズされる原因となったJMSException例外オブジェクト
ConnectionReconnectedEvent	JMSサーバに再接続したことを通知する。イベントオブジェクトから次の情報を取得できる。コネクションオブジェクト再接続したJMSサーバのアドレス
ConnectionReconnectFailedEvent	JMSサーバとの再接続に失敗したことを通知する。イベントオブジェクトから次の情報を取得できる。コネクションオブジェクト接続しようとしたJMSサーバのアドレスコネクション再接続失敗の原因となったJMSException例外オブジェクト

コンシューマイベント通知

コンシューマイベントリスナを利用することによって、特定の送信先に対して、コンシューマが存在するかどうかの通知を受けることができます。例えば、プロデューサアプリケーションでは、コンシューマの有無に基づいて、特定の送信先に対してメッセージ送信の開始や停止を行うことが可能になります。

次に、コンシューマイベントリスナが通知するイベントと、イベントから取得できる情報を示します。

表3.6.4.19-2
イベント	説明
ConsumerEvent	監視する送信先のコンシューマの接続状況を通知する。イベントオブジェクトから次の情報を取得できる。コンシューマの接続状況を示すコード CONSUMER_READY ：メッセージを受信できるコンシューマが存在する CONSUMER_NOT_READY ：メッセージを受信できるコンシューマは存在しない。INACTIVE状態の永続サブスクリプションは「存在しない」とみなすコネクションオブジェクトイベントを送信したJMSサーバのアドレス送信先オブジェクト

属性値について

説明中の各属性の詳細については、 [ リファレンス集運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.7. JMS > 1.7.2. JMS設定項目一覧 ] を参照してください。

3.6.5. JTA

JTA(Java Transaction API)とは、アプリケーションやアプリケーションサーバからトランザクションの開始や完了といったトランザクションに対する操作を行うためのAPI です。

トランザクションを実行するためには、アプリケーションやDBMS に代表されるリソース、アプリケーションサーバ、2フェーズコミットメントによる分散トランザクションの制御を行うためのTransaction サービスなどが協調動作する必要があります。JTA は、それらの各種コンポーネントが協調して動作するための仲介者となります。

WebOTX では最新仕様1.1 に対応しているため、WebOTX 上で動作するアプリケーションでは、リソースの種類やTransaction サービスの実装などを意識せずにトランザクションに参加することができます。

またWebOTX では、JTA とTransaction サービス間のインタフェースを規定するJTS(Java Transaction Service) に対応しています。Java EE で標準となっているJTA インタフェースとCORBA 共通サービスで規定されている CORBA Transaction Service（OTS）との連携を実現します。

WebOTXが提供するTransactionサービスでは、JTA、およびOTSを利用したトランザクションの管理を一手に行なっています。Transactionサービスの提供する機能、およびOTSについての詳細については、[ 3.6.7. CORBAサービス > 3.6.7.7. トランザクションサービス ] の章をご参照ください。

3.6.6. EIS接続サービス(JCA リソースアダプタ)

インターネット業務システムや企業内の業務システムを強化するために、既存の業務システムがカバーできていた部分もすべて作り直していたのでは、市場に対するスピードが問題となります。また、多くの場合、既存の業務システムは企業の戦略システムとしてデータベースや業務アプリケーションに有益な情報やノウハウが詰まっています。Enterprise Application Integration (EAI)は、このような基幹となっているエンタープライズ業務システム(EIS) を有効利用して新しいサービスを提供しようとする考え方です。企業内の複数のサブシステムを統合したシステムを構築し終えた後も、サブシステム毎に部分的な改良を続けながら、システム全体を強化していくことができます。

WebOTX は、企業システムで使われている既存の業務システムをオブジェクトに見せてラッピングする、 JCA(Java EE Connector Architecture) 仕様の各種コネクタ製品を提供しています。既存の業務システムはまったく影響を受けないか、わずかな変更で新しいシステムの部品として使うことができるようになり、スピーディな新サービスの提供、システムの部分的な改良を現実のものとしています。

3.6.7. CORBAサービス

ここでは、CORBA 、及びCORBA アプリケーションから利用できる部品であるサービスについて説明します。

3.6.7.1. CORBAとは

はじめに、CORBAについて説明します。

OMG とは

Object Management Group (OMG)は米国の民間の標準化団体です。会員の提案にもとづいた仕様策定を行っています。会員には、内外の主要なコンピュータメーカ、ソフトベンダやそれらのユーザ企業、他の標準化組織などが参加しています。

CORBA とは

Common Object Request Broker Architecture (CORBA)はOMG が規定した分散オブジェクトに関する標準仕様です。分散オブジェクトの開発時の仕様と実行時の仕様に分けられます。開発時の仕様には、記述するプログラミング言語に独立したInterface Definition Language (IDL)言語によるオブジェクトの外部仕様の表現方式と各種プログラミング言語からの利用方法を規定する言語マッピングがあります。実行時の仕様には、分散環境下に存在するオブジェクト間の通信プロトコルであるGeneral Inter-ORB Protocol/ Internet Inter-ORB Protocol (GIOP/ IIOP)などがあります。

CORBA を利用すると、オブジェクト指向言語であるJava やC++では通信に関連するプログラミングを意識せずに、Java やC++のオブジェクトを呼び出す感覚で分散環境下での通信プログラムを記述することができます。引数や戻り値には整数や文字列などの基本型のほかに、構造体や配列などの複雑な型を利用できますので、通信電文の設計やバイトオーダ(メモリ上でのデータの格納順序)の変換などに時間を割く必要がありません。呼び出されるオブジェクトの記述言語と呼び出されるオブジェクトの記述言語は異なってもかまいません。クライアントをJava で記述し、サーバ側ではJava はもちろんのこと、C++や COBOL などで記述することもできます。CORBA での通信は関数呼び出しと同様の動作となる要求応答型(リクエストレスポンス型)です。一方、ファイル転送や画像配信などのデータ送信方向が片道であるストリーム型通信には適していません。

WebOTX はCORBA仕様に基づいた分散オブジェクト技術をサポートしています。CORBA で開発したアプリケーション(オブジェクト)は部品として再利用が容易です。また各種既存システムと連携するためのコネクタを提供しているため、既存のシステムをオブジェクト部品としてラッピングして再利用することも可能です。これにより、既存資産を生かした速やかなシステム構築を実現したり、システムの保守性を確保したりすることができます。これらオブジェクト指向による部品化技術とWindows やUNIX、Linux などの多様なプラットフォームへの対応により、急激なIT 技術の変化にも柔軟に対応することができます。

WebOTX はCORBA 2.3/3.0(一部)仕様に対応しており、CORBA 2.0 以降仕様の他社製品に対する実証された相互接続性がありますので、マルチベンダ環境のシステムの統合も容易に実現できます。また、さまざまな言語でアプリケーションを作成することが可能なため、業務への適性とアプリケーション開発者の得手・不得手に対し、最適なものを選択することができます。

IDL からのスタブスタブ／スケルトンの生成

CORBA を利用したアプリケーションの開発は通常次の手順で行われます。

IDL 言語でオブジェクトの外部仕様であるインタフェースを記述する (記述物をIDL 定義と呼びます)。
IDL コンパイラでIDL 定義からスタブおよびスケルトンを生成します。
クライアントおよびサーバ(オブジェクト)の処理をそれぞれの開発言語で記述します。
クライアントではスタブを、サーバではスタブおよびスケルトンをプログラムと同時にコンパイルして使用します。

IDL コンパイラはIDL 定義ファイルから、クライアントおよびサーバで使用するスタブと呼ばれるプログラムと、サーバで使用するスケルトンというプログラムを生成します。クライアントではクライアントでの処理を記述したプログラムとスタブをコンパイルして使用します。また、サーバでは、サーバの処理を記述したプログラムとスタブおよびスケルトンをコンパイルして使用します。

実行時の通信概要

CORBA ではサーバオブジェクトの識別情報はInteroperable Object Reference (IOR)で表現されます。 IOR 中にはサーバオブジェクトのIP アドレスあるいはホスト名とTCP ポート番号が含まれています。 CORBA の実装内部ではこれらの情報を使ってサーバオブジェクトとのTCP コネクションを確立して通信を行います。主な通信は、処理要求であるリクエストメッセージと処理結果を返すレスポンスメッセージで行われます。

言語マッピングを使用するアプリケーションプログラムからは、関数呼び出しの延長として通信が行われますので、通信の詳細について意識する必要はありません。

GIOP/IIOP

WebOTX Object Broker は異なるORB 間の接続のためのCORBA 標準プロトコルGeneral Inter-ORB Protocol/ Internet Inter-ORB Protocol (GIOP/ IIOP)を内部プロトコルとしても使用しています。このため、マルチベンダのシステムでも通信性能を損なうことがありません。現在GIOP/ IIOP には、1.0、1.1、 1.2 の3つのマイナーバージョンがありますが、GIOP/ IIOP はバージョン混在を前提に設計されていますので、これらのバージョンのいずれかをサポートしていればWebOTX Object Broker と通信することができます。ただし、バージョン混在時は低いバージョンで通信されますので、一部機能が制限されることがあります。

GIOP には、バイトオーダ(整数型、浮動小数点型などのメモリ上の格納順序)を変換する機能がありますが、これについては、CORBA を使用することにより自動的に処理され、アプリケーションはこのことについて意識せずにプログラムを記述することができます。

コードセット

文字コードの変換をする機能です。string 型およびwstring 型に適用されます。クライアントで SJIS、サーバでEUC など異なる文字コードを使用しているときに、変換をCORBA に任せることができます。文字コードの指定方法は、 [ リファレンス集運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.10. Object Broker > 1.10.1. Object Broker設定項目・設定方法 ]、または、 [ アプリケーション開発ガイド（CORBA） > 1. CORBA アプリケーション > 1.2. プログラミング・開発ガイド > 1.2.2. Object Broker ] (プログラム開発者がプログラム中で指定する場合)をごらんください。

3.6.7.2. ORB

WebOTX のORB はCORBA が規定するInternet Inter-ORB Protocol (IIOP)を使用します。WebOTX ではIIOP 1.2/1.1/1.0 をサポートしているのでIIOP に準拠する他のORB 製品と容易に通信ができます。またIIOP over SSL をサポートしているのでIIOP の通信をセキュアに行うこともできます。 WebOTX は Java,C++ともCORBA 2.3/3.0(一部)仕様の言語マッピングに準拠した開発環境を提供します。通信に関する部分はORB で管理されるので、アプリケーション開発者は通信部分をプログラミングする必要がありません。またObject Adapter にはPortable Object Adapter (POA)を使用しているので他のORB 製品からの移植もスムーズに行うことができます。

3.6.7.3. 名前サービス

名前サービスは、ネットワーク上に分散するオブジェクトリファレンスを一箇所に登録して、階層的な名前を付けて管理するためのCORBA のサービスで、OMG が公布する「Naming Service Specification 1.1 (formal/2001-02-65)」を実装しています。

CORBA では通信相手であるオブジェクトを識別するためにオブジェクトリファレンスを使用します。クライアントは通信をする前に通信相手のオブジェクトリファレンスを入手しなければなりません。オブジェクトリファレンスを受け渡す方法にはいくつかありますが、もっとも一般的な方法は名前サービスを使用することです。オブジェクトリファレンスとその名前をあらかじめ名前サービスに登録しておき、クライアントは名前をもとにオブジェクトリファレンスを入手します。

WebOTX では名前サービスを実現するサーバプロセスを提供します。このプロセスを名前サーバと呼びます。名前サーバではファイルシステムのように階層化してオブジェクトリファレンスを管理します。名前コンテキストはファイルシステムのディレクトリに相当するもので、このコンテキストが集まり木構造を作ります。名前コンテキストのうち、ファイルシステムのルートディレクトリに相当するものを特にルートコンテキストと呼び、ファイルシステムと同様に名前コンテキストの下に名前コンテキストを置くことができます。

3.6.7.4. インタオペラブル名前サービス

WebOTX の名前サービスはCORBA 2.4 で規定されているインタオペラブル名前サービスに対応しています。そのため他社製ORB 製品をWebOTX の名前サーバに登録したり、他社製の名前サーバへオブジェクトの登録、参照をしたりすることができます。

3.6.7.5. インタフェースリポジトリ

インタフェースリポジトリは厳密にはCORBA Service ではありませんが、CORBA アプリケーションが他のサービス同様に利用できるためここにあげています。CORBA 2.3 仕様を実装しています。実行時にオブジェクトのインタフェース情報を取得するために使用します。

スタブやスケルトンを使用する通常のアプリケーションでは必要ありません。主にDII やDSI などの利用時に使用します。データの登録はIDL コンパイラが生成するファイルを用いて行います。

3.6.7.6. セキュリティサービス

セキュリティを実現するサービスとして、次のIIOP over SSL、CSIv2 が提供されています。

IIOP over SSL

Security Service 1.2 仕様にしたがっています。IIOP 通信で使用する通常のTCP/IP ソケットの代わりにSSL を使用する通信方式です。通信データがSSL により保護されます。IIOP over SSL で通信を行うためには、SSL で使用する「証明書」が必要です。

CSIv2

セキュリティ認証情報をIIOP プロトコルで伝播するためにCORBA 2.6 で規定された仕様です。

3.6.7.7. トランザクションサービス

Transaction サービスはCORBA 共通サービスの1つであるTransaction Service(OTS) 1.4 仕様に準拠しており、WebOTX のアプリケーションに対してトランザクションの原子性、一貫性、独立性、永続性を提供します。これにより、アプリケーションは分散されたデータベースなどの複数のリソースに対する更新を安全に行うことができます。またJTA の章でも記載したとおり、WebOTX が提供するTransaction サービスではJava EE 仕様の JTA インタフェースとOTS との連携を規定するJTS にも対応しており、Transaction サービスでJTA、および OTS を利用したトランザクションの管理を一手に行なっています。

また、ACOS とオープンサーバのリアルタイム連携を実現するためのランタイムライブラリ「ACOS Access Toolkit」が提供するJDBC ドライバと連携することで、本来は2フェーズコミットメントをサポートしていない ACOS 上のトランザクションをWebOTX が管理する2フェーズコミットメントトランザクションに参加させることができるように強化を図っています。これによってACOS 上のデータベースと、オープンサーバ上のデータベース(Oracle など)の同時更新が可能になります。昨今のレガシーマイグレーション需要の増加に伴い、従来の業務系システムの一部をオープン化し、メインフレームとオープンシステム間でアプリケーション連携を実現する事例が増えています。例えば、従来のデータはメインフレーム上で管理、新規に追加された部分のデータ管理はオープンサーバ上で、という要件には適しています。概要については、後述する [ ACOS 上トランザクションの2フェーズコミットメント参加 ]、詳細については [ ドメイン構築・基本設定ガイド ] をご参照ください。

提供機能

トランザクションサービスの役割

WebOTX Transaction Service では従来のRecovery Server によるトランザクションに加え、Recovery Coordination Server を導入して、トランザクションを高速に管理する機能を提供しています。従来のRecovery Server はCORBA Transaction Service の仕様に準拠しており、高い相互接続性があります。しかし、トランザクションの開始・終了時にアプリケーションとRecovery Server との間でCORBA Transaction Service が規定する通信が必要でした。Recovery Coordination Server では、トランザクションの開始や終了処理をアプリケーションプロセス内で実行し、大幅な性能の改善を図りました。ただし、CORBA Transaction Service 仕様を一部拡張しているため、相互接続性はありません。

V7.1 以降では、従来別プロセスとして動作させていたRecovery Coordination Server をドメイン管理プロセス内で動作させるようにしました。これにより、メモリ使用量の削減やドメイン起動時間の短縮が図られています。 WebOTX 上で動作するアプリケーションは堅牢なプロセスになるため、サーバトランザクションを実行する際に Recovery Coordination Server を使用するのが最も適した形になります。

図3.6.7.7-1

フラットトランザクションとネスティッドトランザクション

フラットトランザクションは、ネットワーク全体で単一のトランザクションとしてリソースのコミット、ロールバックを行う単純な形態です。そのため、あるアプリケーションで障害が発生した場合はトランザクション全体がロールバックしてしまいますが、トランザクションの一貫性(consistency)を保つという点ではこの形態を使用するのが一般的です。

図3.6.7.7-2

ネスティッドトランザクションは、全体のトランザクションを多段のサブトランザクションにツリー上に分割して実行する形態です。サブトランザクション内のリソースに障害があってロールバックされても、全体のトランザクションには影響を与えないようにすることができます。一方、サブトランザクションのコミットはトップレベルのトランザクションがコミットされるまで実行されません。

Transaction サービスの提供するネスティッドトランザクションはCORBA トランザクションサービスに完全に準拠していますが、仕様自身に相互接続性がありません。したがってWebOTX のTransaction サービスと、それ以外のCORBA トランザクションサービスとの間でサブトランザクションを実行できるという保証はありませんので注意してください。

ネスティッドトランザクションはリカバリサーバのみのサポートです。RCS はサポートしておりません。

図3.6.7.7-3

トランザクションコンテキストの管理方法

Transactionサービスが提供するトランザクションサービスでは、トランザクションの管理のためにトランザクションコンテキストを使います。

トランザクションコンテキストは、トランザクションに参加しているアプリケーションやリソース、トランザクションの状態といったトランザクションに関する情報をもっています。Transaction サービスあるいはアプリケーションプログラムは、トランザクションコンテキスト内の情報を変更/参照することにより、トランザクションの制御を行います。例えば、アプリケーションをトランザクションに参加させるには、アプリケーションをトランザクションコンテキストに関連付けることで実現します。

アプリケーションがトランザクションコンテキストを管理する方法として次の方法があります。

間接的なコンテキスト管理

間接的なコンテキスト管理とは、アプリケーションとトランザクションコンテキストの関連付けをTransaction サービスが自動的に管理します。アプリケーションはTransaction サービスが提供するインタフェースを使用するだけでトランザクションの制御を行うことができます。

詳細は[アプリケーション開発ガイド（CORBA）] を参照してください。

トランザクションコンテキストの伝播

トランザクションコンテキストを伝達することで、クライアントアプリケーションが呼び出したサーバオブジェクトを、クライアントが開始したトランザクションに参加させることができます。サーバオブジェクトは、伝達されたトランザクションコンテキストを使ってトランザクションに参加し、トランザクションの制御を行うことができるようになります。このトランザクションコンテキストの伝達を伝播といいます。伝播には次の2種類があります。

暗黙的な伝播
明示的な伝播

暗黙的な伝播は、Transactionサービスが伝播を行います。間接的なコンテキスト管理によりアプリケーションのスレッドにトランザクションコンテキストが関連付けられているときにサーバオブジェクトが呼び出されるとトランザクションサービスは暗黙の伝播を行います。アプリケーションは伝播のために特別な処理を行う必要はありません。伝播が行われるかどうかは、サーバオブジェクトのOTSPolicyによって決まります。

明示的な伝播は、アプリケーションが伝播を行います。アプリケーションがサーバオブジェクトのオペレーションを呼び出す時、引数にトランザクションコンテキストを指定することで行います。

図3.6.7.7-4

OTSPolicy による伝播の管理

WebOTX では、CORBA Transaction Service の最新仕様(OTS)である1.4 に対応しています。OTS 1.2/1.3 と同様にOTSPolicy を設定することにより、トランザクションとして動作させることができます。なおOTS 1.2 からトランザクションの伝播はサーバアプリケーションが登録されたPOA のPolicy によって設定されます。OTSPolicy はREQUIRES、FORBIDS、ADAPTS の3種類があります。

REQUIRES
オブジェクトは必ずトランザクション内で動作する必要があることを示します。そのため、REQUIRES が設定されたオブジェクトを呼び出すクライアントはトランザクションを開始しておかなければなりません。トランザクションを開始していない状態で呼び出すとCORBA::TRANSACTION_REQUIRED 例外が発生します。
FORBIDS
オブジェクトは必ずトランザクション外で動作する必要があることを示します。クライアントでトランザクションが開始されている場合、サーバアプリケーションを呼び出すかどうかはNonTxTargetPolicy によって決定します。WebOTX Transaction Service はNonTxTargetPolicy の既定値をPERMIT としているため、トランザクションコンテキストを伝播させずにサーバアプリケーションの呼び出しを行います。NonTxTargetPolicy をPREVENT に設定した場合、トランザクションが開始されていると CORBA::INVALID_TRANSACTION 例外が発生します。
ADAPTS
オブジェクトはトランザクション内でもトランザクション外でも動作できることを示します。クライアントでトランザクションが開始されていればトランザクションコンテキストを伝播し、トランザクションが開始されていなければトランザクションコンテキストを伝播せずにサーバアプリケーションを呼び出します。OTS 1.1 のCosTransactions::TransactionalObject を呼び出す場合はOTSPolicy がADAPTS であるものとみなして動作します。

ルートPOA や明示的にOTSPolicy を設定しない子POA のOTSPolicy はFORBIDS として動作します。OTS 1.2 ではサーバアプリケーションはCosTransactions::TransactionalObject を継承していてもトランザクションとしては動作しませんが、オブジェクトマネージャへの登録時にADAPTS を設定することでOTS 1.1 のアプリケーションをそのまま動作させることができます。クライアントアプリケーションはOTSPolicy が設定されていないサーバアプリケーションを呼び出す場合CosTransactions::TransactionalObject を継承しているかチェックを行い伝播するため、OTS 1.1 に対する互換性は保証されます。

トランザクションのコミットメント

Transaction サービスでは、トランザクションを終了する場合、次の2種類のコミットメント制御を使用します。

1フェーズコミットメント
トランザクションに参加しているリソースが1つの場合は、そのリソースに対して即座にコミットを要求します。
2フェーズコミットメント
トランザクションに参加しているリソースが複数の場合は、リソース全体のコミットを実施します。この際にトランザクションの終了処理は次の2つのフェーズに分けて行います。
- 第1フェーズ
  トランザクションに参加している全リソースに対してプリペアを要求します。リソース側ではこれを要求されると、アクセスしたデータを更新可能であり、トランザクションをコミットできるかどうかを通知します。リソースのうちのいずれかがコミット不可能であると通知してきた場合、自動的にトランザクションはロールバックします。
- 第2フェーズ
  第1フェーズの結果に基づいて、トランザクションのコミットあるいはロールバックを全リソースに対して要求します。

トランザクションに参加したリソースが単一か複数かを判断してWebOTX が自動的に必要となるコミットメント制御を行いますので利用者は意識する必要がありません。

データベースのサポート

Transaction サービスは、X/Open 分散トランザクション処理にしたがってデータベースをサポートします。 X/Open 分散トランザクション処理では、トランザクションサービスを提供する部分をトランザクションマネージャ、データベースなど永続的なリソースを提供する部分をリソースマネージャと呼びます。トランザクションマネージャとリソースマネージャとのインタフェースはXA インタフェースと呼ばれるインタフェースが使われます。

図3.6.7.7-5

Transaction サービスは、トランザクションマネージャとして以下のXA インタフェースをサポートするデータベースなどと協調してトランザクションとして動作します。

グローバルトランザクションとローカルトランザクション

Transaction サービスは、X/Open 分散トランザクション処理にしたがって次の2つのトランザクションをサポートします。

グローバルトランザクション
トランザクションサービスの制御の元にあるトランザクションで、ネットワーク上全体としてコミットまたはロールバックされます。
ローカルトランザクション
トランザクションサービスでの制御とは独立に、コミット、ロールバックを行うトランザクションです。ローカルトランザクションを完了させるためには、SQLのCOMMIT文またはROLLBACK文を使用する必要があります。

グローバルトランザクション内でローカルトランザクションを行うと、ネスティッドトランザクションのように一部分だけ全体のトランザクションの結果に独立したデータの更新ができます。ネスティッドトランザクションと異なるのは、コミット制御も独立に行うことができる点です。

トランザクションブランチ

XAインタフェースにおいて基本となる概念にトランザクションブランチがあります。トランザクションブランチとは、各スレッドおよびリソースマネージャ上に生成されるリカバリの最小単位です。例えば、1つのトランザクション内で複数のアプリケーションスレッドが連携して動作する場合、スレッドごとにトランザクションブランチが生成されます。トランザクションブランチは、アプリケーションがトランザクション処理を実行する前にそのスレッド上で開始され、アプリケーションがトランザクション処理を終了後にそのスレッド上で終了します。トランザクションブランチを開始・終了することで、トランザクションマネージャはリソースマネージャに対してリカバリの対象となるトランザクション処理の範囲を示します。

Transaction サービスは、サーバオブジェクトの呼び出しと戻りで、自動的にトランザクションブランチの開始および終了を行います。また、トランザクションの開始、終了時にも自動的にトランザクションブランチの開始および終了を行います。

トランザクション識別子

トランザクションブランチを識別するためにトランザクション識別子が使われます。

トランザクション識別子は、OTS(JTS)とXA インタフェースでは形式が異なりますが、基本的にはフォーマット識別子、グローバルトランザクション識別子、ブランチ識別子の3つからなります。フォーマット識別子はトランザクションサービス/トランザクションマネージャを識別するコードです。グローバルトランザクション識別子はグローバルトランザクションを識別するバイト列です。ブランチ識別子はトランザクションブランチを識別するバイト列です。

密結合と疎結合

密結合とは、1つのグローバルトランザクション内の複数のトランザクションブランチがデータベースの同一エントリを更新することを認めるものです。

逆に、同一エントリの更新を認めない動作を疎結合と呼びます。提供される結合度についてはデータベースに依存します。

最も強力な密結合は、トランザクションブランチが別のプロセスや別のマシンの場合でも、同一エントリの更新を認めます。密結合はトランザクション識別子のブランチ識別子を同一にしてデータベースにアクセスすることで実現します。

Transaction サービスでは、同一のグローバルトランザクション内で同一のオブジェクトに対する複数のメソッド呼び出しは密結合として動作させます。異なるオブジェクトや異なるプロセス、マシンへの呼び出しは疎結合として動作させます。分散トランザクションで複数のマシン、複数のプロセスで同一のデータベースエントリを更新することは、データベース破壊などの危険な状況を起こしやすいので、これを避けるためにこのような制御を採用しています。

静的登録と動的登録

トランザクションマネージャは、一般に、アプリケーションが接続しているデータベースすべてに対してトランザクションブランチを開始します。

これを静的登録と呼びます。この場合、トランザクションマネージャは、どのデータベースへのアクセスが行われるかを判断できないため、実際にはアクセスされないデータベースが存在しても、すべてのデータベースでトランザクションブランチを開始してしまいます。この場合無駄なトランザクションブランチも開始することになります。

そこでリソースマネージャがアプリケーションからデータベースにアクセスがあった場合にのみ、トランザクションブランチを開始する方法があります。これを動的登録と呼びます。動的登録が行われると、本当に必要なデータベースに対してのみトランザクションブランチが開始され、コミットプロトコルに参加するようになるので、無駄がなくなります。

Transaction サービスは、静的登録、動的登録どちらにも対応していますので、データベース側が動的登録をサポートしていれば、効率のよいトランザクションを実行することができます。

データベースの識別方式

Transaction サービスは、データベースをデータベース識別名により一意に識別しています。C++で使用するデータベース識別名は、データベースの種類を示すリソースタイプとオープン文字列、クローズ文字列を代表する名前です。また、Java で使用するデータベース識別名は、接続文字列やユーザ名といったJDBC データソースのプロパティ情報に対応してデータベースに接続する際のコネクション情報に対応する名前です。

ACOS 上トランザクションの2フェーズコミットメント参加

Transaction サービスでは、ACOS Access Toolkit(AAT)が提供するJDBC ドライバと連携することで、本来は2 フェーズコミットメントをサポートしていないACOS 上のトランザクションをWebOTX が管理する2フェーズコミットメントトランザクションに参加させることができます。

それを実現するために、Transactionサービスでは、ACOS上のデータベースを管理するために使用する「1フェーズコミット対応リソース」を実装しており、ここからAAT提供のJDBCドライバを経由してデータベースの更新処理を行います。

Transaction サービスでは、同一グローバルトランザクションへの、1つの1フェーズコミット対応リソースと、任意の数の2フェーズコミット対応リソース(従来からTransaction サービスが提供するデータベースアクセス用のリソース)の登録ができるようになっています。

つまりこれによってACOS 上のデータベースと、オープンサーバ上のデータベース(Oracle など)の同時更新が可能になります。

なお、本来であれば1フェーズコミットメントでの動作を前提としているものを2フェーズコミットメントトランザクションに参加させているため、いくつかの制限、および運用操作上の注意事項を設けています。それらの詳細については、 [ ドメイン構築・基本設定ガイド > 7.4. Transactionサービス]をご参照ください。

システム構成について

Transaction サービスでは、アプリケーションがネットワーク上のどこにあるかを意識する必要はありません。ネットワーク上の最適な位置にアプリケーションを再配置することができます。従って、Transaction サービスを使うと、1台のサーバで集中して処理を行う集中型のシステムや複数サーバ・クライアントが協調して処理を行う分散型のシステムなど、さまざまな業務形態に合わせたシステムを構築することができます。

Transaction サービスを使ったトランザクションシステムの構成は基本的に、「サーバトランザクションモデル」「クライアントトランザクションモデル」、およびこれらを組み合わせた「複合形態モデル」に分けられます。それぞれの詳細については [ システム設計ガイド ] をご参照ください。

3.6.7.8. イベントサービス

「CORBA Service (98-12-09)」にしたがっています。イベントサービスは、イベントチャネルオブジェクトを媒介として、any 型のデータを1イベントとする非同期通信を提供します。データの供給側(サプライア)、データの消費側(コンシューマ)とも、プル型とプッシュ型のデータ交換が可能です。プッシュ型では、供給者がクライアントとなり、消費側オブジェクトを呼び出します。プル型では、消費者がクライアントとなり、供給側オブジェクトを呼び出します。なお、イベントチャネルを介して通信しますので、供給者、消費者でプッシュ型、プル型を混在させて使用することができます。

3.6.7.9. ノティフィケーションサービス

Notification Service 1.0 仕様にしたがっています。ノティフィケーションサービスは、非同期通信を実現するイベントサービスを拡張したサービスです。イベントサービスが提供する機能のほかに、サービス品質の設定やフィルタリングといった機能を提供します。サービス品質の設定では、優先度が高い順にコンシューマにイベントを送信することや、イベントチャネルにキューイングされてから一定の期間が経過したイベントを自動的に廃棄すること、コネクション情報とイベントメッセージの永続性を保証して、システム障害などでイベントを失わないようにすることができます。また、イベントのフィルタリングを行うことで、コンシューマに送信するイベントの種類を限定することができます。

3.6.7.10. Persistent State サービス

Persistent State Service (PSS) は CORBA サーバアプリケーション開発者のためのサービスです。アプリケーションを構成する Servant から Datastore domain (データベースなど)にアクセスするために利用するインタフェースinternal interface を提供します。

WebOTX ではPersistent State Service 2.0 仕様に準拠したデータベースを利用するサーバアプリケーションの開発環境を提供します。

3.6.7.11. CORBA実行環境

WebOTX が提供するCORBA 実行環境であるWebOTX Object Broker が提供する機能について説明します。

Portable Object Adapter (POA)

Portable Object Adapter (POA)は、CORBA 2.2 で追加された標準的なオブジェクトアダプタであり、サーバアプリケーションのポータビリティを実現します。

POA の主な機能は、CORBA オブジェクトとサーバントのライフサイクルを管理し、クライアントからのオブジェクトに対する呼び出しを適切なサーバントにディスパッチすることです。サーバントとは、CORBA オブジェクトを実装したC++やJava などの言語上のオブジェクトのことです。

それまでのBOA と大きく異なる点は、複数のCORBA オブジェクトをひとつのサーバントに対応付けることができることです。例えば、データベースの個々のデータに対応する膨大な数のCORBA オブジェクトをひとつのサーバントで処理させることが可能になります。

図3.6.7.11-1

ThreadPolicy

要求をシングルスレッドで処理させるか、ORB に依存したマルチスレッドで処理させるかを設定します。

ORB_CTRL_MODEL: ORB 依存のマルチスレッドで処理します。(既定値)。必ずスレッドセーフに処理を実装しなければなりません。
SINGLE_THREAD_MODEL: シングルスレッドで処理します。

ORB_CTRL_MODEL の場合にWebOTX Object Broker が提供するマルチスレッドについて説明します。

C++版: 次の3つのスレッド処理を選択できます。

スレッドを使用しません。(既定値)
要求毎にスレッドを作成して処理します。
プールされたスレッドを使用して処理します。

選択は、プログラムで設定するか、レジストリやファイルまたは環境変数で行う方法があります。

Java 版: 次の2つのスレッド処理を選択できます。

クライアント毎にスレッドを作成して処理します。(既定値）
プールされたスレッドを使用して処理します。

選択は、プログラムで設定するかプロパティやファイルで行う方法があります。

これらの設定方法の詳細については、 [ リファレンス集運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.10. Object Broker > 1.10.1. Object Broker設定項目・設定方法 ]、または、 [ アプリケーション開発ガイド（CORBA） > 1. CORBA アプリケーション > 1.2. プログラミング・開発ガイド > 1.2.2. Object Broker ] をごらんください。

LifespanPoilcy

CORBA オブジェクトを一時オブジェクトとして作成するか、永続オブジェクトとして作成するかを設定します。

TRANSIENT: 一時オブジェクト。サーバプロセスの生存期間内でのみ有効です。(既定値)
PERSISTENT: 永続オブジェクト。サーバプロセスの生存期間を超えて有効です。

PERSISTENT の場合、CORBA オブジェクトを作成して、その後サーバプロセスを停止・再起動しても、クライアントは同じリファレンスで引き続き同じオブジェクトにアクセスすることができます。

IdAssignmentPolicy

CORBA オブジェクトのオブジェクトID をアプリケーションで割り当てるか、ORB で自動的に割り当てるかを設定します。

SYSTEM_ID: ORB が自動的に割り当てます。(既定値)
USER_ID: アプリケーションで割り当てます。

オブジェクトID をデータベースアクセスのキーとして使用する場合など大量のオブジェクトに1つのサーバントを割り当てるときには、USER_ID を使用します。

IdUniquenessPolicy

CORBA オブジェクトとサーバントの対応付けを1対1とするか、多対1とするかを設定します。

UNIQUE_ID: 1対1で対応付けます。(既定値)
MULTIPLE_ID: 多対1で対応付けます。

MULTIPLE_ID を設定する典型的なケースは、後述するデフォルトサーバントを使用する場合です。

ServantRetentionPolicy

Active Object Map (AOM) を使用するか否かを設定します。AOM とは、CORBA オブジェクトとサーバントの対応付けを管理する対応表です。

RETAIN: AOM を使用します。(既定値)
NON_RETAIN: AOM を使用しません。

NON_RETAIN を選択するには、後述するサーバントマネージャを作成して、アプリケーション自ら対応付けを行うか、デフォルトサーバントを使用することになります。このほかにも、RETAIN を選択してサーバントマネージャかデフォルトサーバントを実装することもできます。

RequestProcessingPolicy

クライアントからの要求をどのサーバントにディスパッチするかを設定します。

USE_ACTIVE_OBJECT_MAP_ONLY: AOM だけを使用します。(既定値)
USE_DEFAULT_SERVANT: デフォルトサーバントを使用します。
USE_SERVANT_MANAGER: サーバントマネージャを使用します。

USE_DEFAULT_SERVANT でもUSE_SERVANT_MANAGER の場合でも、ServantRetainPolicy に RETAIN が設定されているときには、まずAOM でサーバントを検索し、見つからない場合にだけディスパッチします。

ImplicitActivationPolicy

暗黙的な活性化を行うか否かを設定します。

NO_IMPLICIT_ACTIVATION: 暗黙的な活性化を行いません。(既定値)
IMPLICIT_ACTIVATION: 暗黙的な活性化を行います。

NO_IMPLICIT_ACTIVATION を選択する場合、POA::activate_object() や POA::activate_object_with_id()により明示的に活性化しなければなりません。

IMPLICIT_ACTIVATION を選択する場合、まだ活性化されていないサーバントでも、 POA::servant_to_reference()やPOA::servant_to_id()の呼び出しのタイミングで暗黙的に活性化され、オブジェクトリファレンスやオブジェクトID が返されます。

ORB はすべて既定値のPOA ポリシーをもつrootPOA を提供しています。RootPOA は、 ORB::resolve_initial_references("RootPOA")オペレーションで取得できます。

アプリケーションが独自のPOA ポリシーを持ったPOA を必要とする場合には、rootPOA を基点として階層的に自由に生成(POA::create_POA)することができます。

図3.6.7.11-2

図中にあるPOA マネージャ、サーバントマネージャ、アダプタアクティベータ、そしてデフォルトサーバントについて簡単に説明します。

POA マネージャ
POA マネージャは、POA に対するクライアントからの要求の流れを制御する管理オブジェクトです。4つの状態があり、POA マネージャに対するオペレーション、
- OAManager::activate()
- OAManager::discard_requests()
- OAManager::hold_requests()
- OAManager::deactivate()
により状態が遷移します。

図3.6.7.11-3
- HOLDING … クライアントからの要求はPOA にディスパッチせずにキューイングします。(初期値)
- ACTIVE … クライアントからの要求をPOA にディスパッチします。
- DISCARDING… クライアントからの要求は全て破棄しクライアントにTRANSIENT 例外を返却します。
- INACTIVE … クライアントからの要求は全て拒否します。
デフォルトのPOA マネージャはrootPOA にあらかじめ関連付けられており、独自のPOA を生成する際にPOA::create_POA()の引数にそのPOA マネージャを引き継ぐか、引き継がずに新たなPOA マネージャを関連づけるかを選択することができます。POA マネージャを分けることにより、いくつかのPOA をグループ化して制御することができます。
サーバントマネージャ
サーバントマネージャとは、アプリケーション側でCORBA オブジェクトとサーバントの対応付けを行うもので、サーバントアクティベータとサーバントロケータの2種類があります。サーバントアクティベータを使用するには、以下の2つのポリシーが必須となります。
- ServantRetentionPolicy : RETAIN
- RequestProcessingPolicy : USE_SERVANT_MANAGER
クライアントから要求を受けると、まずAOM を検索し、見つからない場合にのみサーバントアクティベータを呼び出します。サーバントアクティベータが対応するサーバントをPOA に返すと、AOM に登録されて以降の同じオブジェクトに対する要求のディスパッチはAOM の情報で解決されます。サーバントアクティベータは、ServantActivator インタフェースで定義されている incarnate()とetherealize()を実装しなければなりません。

一方、サーバントロケータを使用するには、以下の2つのポリシーが必須となります。
- ServantRetentionPolicy : NON_RETAIN
- RequestProcessingPolicy : USE_SERVANT_MANAGER
AOM を使用しないため、クライアントからの要求ごとに呼び出され、サーバントをPOA に返します。サーバントロケータは、ServantLocator インタフェースで定義されているpreinvoke() とpostinvoke()を実装しなければなりません。

サーバントアクティベータもサーバントロケータも、登録はPOA::set_servant_manager() で行います。
デフォルトサーバント
デフォルトサーバントとは、あるPOA のすべてのCORBA オブジェクトに対する要求をひとつのサーバントで処理する場合に使用します。この場合、以下の2つのポリシーが必須となります。
- IdUniquenessPolicy : MULTIPLE_ID
- RequestProcessingPolicy : USE_DEFAULT_SERVANT
ServantRetentionPolicy を変えることによって、全ての要求をデフォルトサーバントで処理するか、AOM にない場合にだけデフォルトサーバントで処理するかを選択できます。デフォルトサーバントの実装の中でCORBA オブジェクトに依存した処理を行うためには、呼び出しの延長で POACurrent オブジェクトをORB::resolve_initial_references("POACurrent")を使用して取得します。そして、PortableServer::Current::get_object_id()で対応するオブジェクトID を取得します。デフォルトサーバントの登録は、 Portable::POA::set_servant()で行います。

最後にCOBRA オブジェクトの数に応じたサーバタイプについて説明します。

CORBA オブジェクトの数が少ない場合

AOM だけを使用するポリシー設定が適しており、プログラミングも簡易にできます。オブジェクトの数が増えるとAOM の対応情報が増えるため、メモリ不足等の問題を引き起こすことがあります。また、永続オブジェクトを使用する場合には、起動時のオブジェクト活性化に要する時間を考慮する必要があります。

ServantRetentionPolicy : RETAIN
RequestProcessingPolicy : USE_ACTIVE_OBJECT_MAP_ONLY

CORBA オブジェクトの数が多い場合

オブジェクトの数が多く、実際にはそのうちの少数しか利用されないケースでは、全てのオブジェクトをあらかじめ活性化しておくよりも、必要時に活性化を行いAOM に登録するという、AOM とサーバントアクティベータ併用のパターンが適しています。

ServantRetentionPolicy : RETAIN
RequestProcessingPolicy : USE_SERVANT_MANAGER

ただし、このパターンでは、一度活性化されたオブジェクトはAOM に登録されるため、利用されるオブジェクトが多くなると最終的にAOM だけを使用するパターンと同様にメモリの問題が懸念されます。このような場合には、サーバントロケータを使用して、対応付けをアプリケーション側で完全に制御し、オブジェクトをキャッシュして管理するような仕組みを実装します。

デフォルトサーバントを使用すると全てのオブジェクトをひとつのサーバントで対応するためオブジェクトの数に依存せずにスケーラブルに対応できます。これは、データベースのキーをオブジェクトID に対応づけるようなシステムに最適です。

RequestProcessingPolicy : USE_DEFAULT_SERVANNT

WebOTX Object Broker は、POA ポリシーの組み合わせで実現できるいろいろなサンプルプログラムが用意しています。内容については、サンプル集をごらんください。

Dynamic Invocation Interface (DII)

動的起動インタフェースDII は、IDL コンパイラが生成するスタブ・スケルトンを使用せずに、実行時に動的に要求を組み立ててオブジェクトを呼び出す機能です。

CORBA 2.4 で追加された仕様についてはサポートしていません。

一般的には、次のようなケースで利用します。

クライアントを開発する時点で、サーバが提供するinterface が確定していない場合やインタフェースが頻繁に変更、追加されることが想定されている場合。
利用者にメニューからサービスを選択させて、サーバに処理を依頼するような汎用的なクライアントの場合。
一度に大量の要求を発行する必要のあるクライアントの場合。

DII では、クライアントは次のような手順でサーバ呼び出しを行います。

Request オブジェクト(CORBA::Request)を作成します。
Request オブジェクトに引数情報(CORBA::NVList)を設定します。
要求を発行します。
Request オブジェクトから結果を取得します。

不特定のオブジェクトを扱うような場合には、インタフェース情報をインタフェースリポジトリに登録しておき、そこから取得した情報をRequest オブジェクトの作成に使用します。

要求の発行には、4つの方法があります。

同期オペレーション
サーバに要求を送信して応答を待ち合わせます。
oneway オペレーション
サーバに要求を送信するだけで応答を待ち合わせません。
遅延同期オペレーション
要求の送信と応答の受信を非同期に行います。
複数リクエストの発行
oneway もしくは遅延同期オペレーションによる複数の要求を同時に送信します。

Request やNVList の生成や発行方法については、[ アプリケーション開発ガイド（CORBA） ]をご覧下さい。

Dynamic Skeleton Interface (DSI)

動的スケルトンインタフェースDSI は、IDL コンパイラが生成するスケルトンを使用せずにサーバ処理を実装し、クライアントからの要求を動的に処理する機能です。とくにインタフェースに依存しないサーバ処理を実装する場合に必要となります。

DSI では、サーバは次のような手順でクライアントからの要求処理を行います。

言語マッピングで定められているPortableServer::DynamicImplementation クラスを継承してサーバ処理をinvoke()に実装します。
クライアントからの要求の延長でinvoke()が呼び出され、ServerRequest オブジェクト (CORBA::ServerRequest)を引数として渡されます。
ServerRequest オブジェクトからオペレーション名を取得します。
ServerRequest オブジェクトから引数情報(CORBA::NVList)を取得します。
オペレーション名に対応するサーバ処理を実行します。
ServerRequest オブジェクトに結果を設定します。
リターンします。

ServerRequest やNVList の生成や発行方法については、[ アプリケーション開発ガイド（CORBA） ]をご覧下さい。

DII のRequest オブジェクトとDSI のServerRequest オブジェクトは、共にオペレーションの引数情報を保持するために同じNVList オブジェクトを使用しています。このため、クライアントからの要求を DSI で受け取り、その引数をそのままDII でサーバに要求を発行するようなゲートウェイプログラムの実装にも利用することができます。後述するDynamicAny やインタフェースリポジトリを使用して、特定のインタフェースに依存しない処理を実装することもできます。

DynamicAny

DynamicAny は、実行時にIDL コンパイラが生成するコードを使用せずに動的にany 型を扱う機能です。

CORBA 2.2 で最初に追加されましたが、CORBA 2.3 で大きく仕様が変更されています。WebOTX Object Broker Java(TM)は、CORBA 2.3 の仕様をサポートしています。

DynamicAny を使用することにより、次のことが可能になります。

any に任意の型のデータを動的に構築する。
any に格納された任意の型のデータを動的に走査し、構成要素を取得する。

例として、次のようなIDL 型を動的に扱う場合について説明します。

// IDL
struct MyStruct {
	long member1;
	boolean member2;
}

このような構造体(MyStruct)を動的に生成してany に格納するには、次のような手順で行います。

ORB からファクトリ(DynAnyFactory)を取得します。
```
ORB::resolve_initial_references("DynAnyFactory")
```
この構造体に対応する TypeCode を生成します。
```
ORB::create_struct_tc()
```
DynAny を生成します。引数には2で生成したTypeCode を指定します。
```
DynAnyFactory::create_dyn_any()
```
DynStruct にnarrow します。

構造体のメンバ値を設定します。

DynStruct::insert_long() // member1 の設定
DynStruct::next() // 次のメンバへの位置付け
DynStruct::insert_boolean() // member2 の設定

any を生成します。
```
DynStruct::to_any()
```

逆にany に格納されたMyStruct からmember2 の値を取り出すには、次のような手順で行います。

ORB からファクトリ(DynAnyFactory)を取得します。
```
ORB::resolve_initial_references("DynAnyFactory")
```
DynAny を生成します。引数には対象とするany を指定します。
```
DynAnyFactory::create_dyn_any()
```
DynStruct にnarrow します。

構造体のメンバ値を取得します。

DynStruct::next() // 次のメンバへの位置付け
DynStruct::get_boolean() // member2 の取得

以上のように、IDL コンパイラが出力する支援コード(Java マッピングの場合はHelper やHolder を指す) を使用する必要がありません。

Interceptor (フック）

Interceptor は、CORBA 2.3 で追加されたクライアントとCORBA オブジェクトとの間の呼び出しルートにおいて割り込み処理を実現する機能です。リクエストレベルとメッセージレベルの割り込み処理を実装してリクエストの引数を変更したり、メッセージを変更したりすることができます。CORBA サービス(例えばセキュリティのアクセス制御)をプラグイン的に実装するような用途としても考えられています。ただし、この仕様にはあいまいな部分(例えば、native 型で宣言されながら各言語マッピングにはそれが定義されていない）が存在します。また、既にCORBA 2.5 で全く新しい仕様に変わることが分かっています。

WebOTX Object Broker の将来のバージョンではこの新しい仕様をサポートする予定ですが、従来から提供しているWebOTX Object Broker 独自のフック機能が現バージョンでは利用できます。

フック機能は、Interceptor と同様のリクエストレベルとメッセージレベルに加えて、応答送信完了時に呼び出されるフックやクライアントとサーバ間のコネクション切断時に呼び出される、サーバ側のフックを登録できます。

Objects by Value

Objects by Value は、CORBA 2.3 で追加されたオブジェクトの値渡しを実現する機能です。

Value

Value は、interface とstruct 定義の中間に位置し、オペレーションやメンバを定義することができます。valuetype というIDL キーワードを使用して定義します。

// IDL
valuetype Names {
	public Names next;
	private string name;
	private string kind;
	public Names oya;
	void print();
};

interface と異なるのは、interface の場合はそのオブジェクトリファレンスが渡される(参照渡し)のに対し、valuetype の場合にはそのコピーが渡される(値渡し)ことになります。そのため、オブジェクトに対するオペレーションはローカルな呼び出しとなり、メンバの値変更も、ローカルなオブジェクトに閉じた変更となります。

struct と異なるのは、継承・再帰定義が可能であることと、共有とnull の概念をサポートしている点です。これにより、送信元の再帰的なリストや木構造をそのままのイメージで送信先に渡すことが可能になります。

一般的に、値渡しには通信コストがかかります。Value オブジェクトのメンバ情報をシリアライズして転送するためです。しかし、以降のオブジェクトへの呼び出しは全てローカルなものになるため、逆に通信コストはかかりません。その反面、値渡しされたValue オブジェクトに対してのアクセスとなるため、サーバ側での更新が反映されないことになります。Value オブジェクトは、このような特性をよく理解して利用することが必要です。

Value Box

Value Box は、メンバを一つだけ持つValue のことです。

// IDL
valuetype Name string;

とくに有効なstring とwstring については、標準で次の定義をサポートしています。

// IDL
module CORBA {
	valuetype StringValue string;
	valuetype WStringValue wstring;
}

あるオペレーションの引数に、メンバにstring 型のデータをもつstruct が多数リンクされており、かつそのデータが全て同じ文字情報を持っているような場合、通常その個数分シリアライズされて送信され、送信先では異なるstring 型のデータとして復元されてしまいます。しかし、string 型の代わりに Value Box であるStringValue 型を使用すると同じ文字情報は最初のものだけがシリアライズされ、残りはすべてそこを参照する形でシリアライズされます。送信先においても、ただひとつの文字情報が復元されます。このように、共有の概念をプリミティブな型においても取り入れることが可能になります。

Abstract Interface

Abstract Interface は、あるオペレーションの引数にオブジェクトを指定する場合に、Value として渡すか、 interface のオブジェクトリファレンスとして渡すかを、IDL 定義時ではなく、実際の呼び出しの時点で決定する仕組みを提供します。

abstract interface というIDL キーワードを使用して定義します。

// IDL
abstract interface Print {
	void print_op();
};

例えば、次のようなケースで利用することができます。

サーバがクライアントに対し、何らかの情報を提供するオブジェクトを渡すような場合で、リアルタイムな情報を利用するクライアントに対しては参照渡しを行い、呼び出し時点で固定された情報で十分なクライアントに対しては値渡しをするような場合。
セキュリティ上、信頼できないクライアントにはアクセス制御を通るように参照渡しを行い、信頼できるクライアントには値渡しをするような場合。

RMI over IIOP

RMI over IIOP は、CORBA 2.3 で追加された、Java 特有の機能です。

Java では分散オブジェクトプログラミングを可能にするRemote Method Invocation (RMI)が標準でサポートされていますが、CORBA で作成されたプログラムと通信することができません。RMI over IIOP は、 RMI で作成されたプログラムのインタフェースを変更することなく、CORBA の標準プロトコルであるIIOP を使って実行する機能です。これにより、RMI と CORBA の相互運用性を実現できます。

WebOTX Object Broker Java(TM)は、EJB の実行基盤としてサポートしています。

サーバプロセスの起動方法

WebOTX Object Broker でのCORBA アプリケーションの起動方法には、クライアントの呼び出しによりサーバプロセスが自動的に起動される「自動起動」とクライアントの呼び出しを実行するまえにあらかじめサーバプロセスを立ち上げておく「手動起動」とがあります。自動起動は次のoadj (Java) およびoad (C++)により行われます。

オブジェクト活性化デーモン (oad）

oad は呼び出しが発生した時点で該当するサーバプロセスが立ち上がっていない(応答が極端に低下した場合も含みます)ときに、サーバプロセスを自動的に立ち上げます。このとき、立ち上げを許可するファイル名をexeallow ファイルにあらかじめ記述しておく必要があります。このほか、特定のファイルの実行を不可能にする設定ファイルや、特定ホストからの要求のみ自動起動を可能にする設定などがあります。詳しくは、 [ リファレンス集運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.10. Object Broker > 1.10.3. Object Broker C++における環境設定 ]をごらんください。

Java 用オブジェクト活性化デーモン (oadj)

oadj による自動起動を行うためには、instimpl コマンドでサーバプロセスを起動するためのコマンドイメージを登録しておく必要があります。自動起動を行う場合のオブジェクトリファレンスは、POA の LifespanPolicy をPERSISTENT に設定して作成します。

詳しくは、 [ ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.2. Object Broker > 7.2.1. Object Brokerの運用操作 ]、または、 [ アプリケーション開発ガイド（CORBA） > 1. CORBA アプリケーション > 1.2. プログラミング・開発ガイド > 1.2.2. Object Broker ] をごらんください。

3.6.7.12. CORBAバージョンと追加機能およびWebOTX Object Brokerでの実装状況

CORBA の各バージョンの主な追加機能とWebOTX Object Broker での対応状況は次の表のとおりです。

表3.6.7.12-1
CORBAバージョン	機能	WebOTX Object Broker
CORBAバージョン	機能	Java	C++
CORBA 2.0	GIOP/IIOP 1.0	○	○
	インタフェースリポジトリ	○	○
	DII	○	○
	CDR	○	○
CORBA 2.2	GIOP/IIOP 1.1	○	○
	POA	○	○
	コードセット	○	○
	DSI	○	○
	DynamicAny	○	×
	longlong型	○	○
	long double型	-	○
	fixed型	○	○
CORBA 2.3	GIOP/IIOP 1.2	○	○
	Objects by Value	○	○
	RMI over IIOP	○	-
CORBA 2.5	Portable Interceptors	○	○
CORBA 2.6	IIOP over SSL	○	○
CORBA 2.6	CSIv2	○	○

また、開発言語と作成するアプリケーションの対応状況は次の表のとおりです。

表3.6.7.12-2
言語	クライアントアプリケーション	サーバアプリケーション
Java	○	○
C++	○	○
Visual Basic(*1)	○	-
COBOL(*2)	-	○
Holon(*3)	○	○

*1: CORBA ゲートウェイ,EJB ゲートウェイ(WebOTX Application Server Enterprise に添付) を使用

*2: OpenCobolFactory21(別途購入要)を使用

*3: HolonEnterprise (別途購入要)を使用

3.6.8. ライフサイクルサービス

WebOTX ではドメイン内で動作する各種サービスをライフサイクル管理しています。ドメイン毎に動作させるライフサイクルサービスを選択することができます。

3.6.8.1. 提供するライフサイクルサービス

WebOTX では次のライフサイクルサービスを提供します。ただしエディションにより利用できないサービスがあります。

表3.6.8.1-1
サービス名称	Express	Standard	Enterprise
HTTP サーバ	○	○	○
Web コンテナ	○	○(*1)	○(*1)
JNDI サービス	○	○	○
EJB コンテナ	○	○(*2)	○(*2)
JMS サービス	○	○	○
Object Broker サービス	○	○	○
Transaction サービス	○	○	○
TP モニタサービス	×	○	○
ダウンローダ管理サービス	×	○	○

*1: StandardおよびEnterprise でアドバンスドモード選択時のWeb コンテナは運用管理エージェントのJava VM とは独立したJava VM で動作します。

*2: StandardおよびEnterprise のEJB コンテナは運用管理エージェントのJava VM とは独立したJava VM で動作します。

3.6.8.2. サービスの運用

WebOTXの内部サービスの運用について説明します。サービスに関する設定はライフサイクルサービスのMBean によって行うことができます。

サービスの追加・削除
サービスの追加・削除はドメイン作成時に選択します。ドメイン作成時にそのドメインで動作させたいサービスを選択します。
サービスの起動・停止
サービスの起動・停止は運用管理コマンドで行うことができます。サービス毎に起動・停止させることが可能です。
サービスの自動起動
追加したサービスはデフォルトではドメイン起動時に自動起動します。ドメイン起動時にサービスを自動起動させたくない場合は、コマンドにて設定を変更することが可能です。
サービスの依存関係
サービス間で依存関係を持つものがあります。基本的にはWebOTX で依存関係の制御を行います。依存関係のあるサービスが起動していない場合は、サービスの起動を行うことができません。また依存関係のあるサービスを停止しようとする場合も、サービスが起動していれば停止することはできません。

3.6.9. インメモリデータグリッド連携

WebOTXはStandard以上の製品において、インメモリデータグリッド製品、Oracle CoherenceおよびInfinispanと連携し、スケーラブルなシステムを容易に構築できる機能を備えています。

WebOTXとCoherenceを連携させるには、オプション製品であるCoherence for WebOTXが必要です。

WebOTX V9.2はInfinispan 5.3.0.Finalと連携可能です。InfinispanのWebサイトからダウンロードしてください。

3.6.9.1. 事前準備

Coherence

WebOTXをCoherenceと連携させるには、ドメイン起動前にCoherence for WebOTXのlibディレクトリ内の以下のJarファイルを${INSTALL_ROOT}/lib/extディレクトリにコピーしておく必要があります。

coherence.jar
je.jar

Infinispan

WebOTXをInfinispanと連携させるには、ドメイン起動前にInfinispanのlibディレクトリ内の以下のJarファイルを${INSTALL_ROOT}/modulesディレクトリにコピーしておく必要があります。

infinispan-core-5.3.0.Final.jar
jboss-logging-3.1.1.GA.jar
jgroups-3.3.1.Final.jar

また、以下のJarファイルを${INSTALL_ROOT}/lib/extディレクトリにコピーしておく必要があります。

jboss-marshalling-1.3.15.GA.jar
jboss-marshalling-river-1.3.15.GA.jar
staxmapper-1.1.0.Final.jar

3.6.9.2. データグリッド設定

データグリッド連携をするためのドメイン共通の設定を行なえます。通常は設定を変更する必要はありません。同一ネットワーク内に他のデータグリッドクラスタが存在する、あるいは他のソフトウェアとポートが衝突するなど、設定変更が必要な場合があります。

Coherence

server.data-grids.coherence-cluster-fileとして、${INSTANCE_ROOT}/config/datagrid/coherenceディレクトリにあるCoherenceクラスタ設定ファイルを指定します。既定値は"webotx-coherence-cluster1.xml"です。設定変更が必要な場合、ファイルを書き換えるか、別のファイルを配置してserver.data-grids.coherence-cluster-fileを変更してください。 Coherenceクラスタ設定ファイルについてはOracle Coherence開発者ガイド「7 クラスタの設定」を参照してください。

Infinispan

server.data-grids.infinispan-cluster-nameとして、Infinispanのクラスタ名を指定します。既定値は"webotx-infinispan-cluster1"です。同一ネットワーク内に複数のInfinispanクラスタが存在する場合、クラスタ名をクラスタごとにユニークな文字列に変更してください。

server.data-grids.infinispan-jgroups-fileとして、{INSTANCE_ROOT}/config/datagrid/infinispanディレクトリにある、JGroups(*)設定ファイルを指定します。 JGroups設定ファイルについては、Infinispan User Guide 「1.4. Clustered Configuration」を参照してください。

(*)Infinispanが利用しているクラスタ通信基盤ライブラリ。

3.6.9.3. データグリッド個別設定

セッションレプリケーションやJPAなど、データグリッド製品を利用するモジュールごとに、個別の設定を使用することが可能です。

統合運用管理ツール、運用管理コンソール、運用管理コマンドより"データグリッド個別設定"を作成し、利用モジュール側の設定でデータグリッド個別設定の名前を指定します。

また、WebOTXインストール時に以下2つの個別設定が作成されており、これを指定することで簡単にデータグリッド連携を行なえます。

__default_http_session
__dafault_jpa

どちらも既定ではタイプがdisabledになっています。実際に使用する際には、タイプをcoherenceあるいはinfinispanに変更する必要があります。

3.6.10. インメモリデータグリッド連携部品

WebOTXでは、高拡張、高可用、高性能な「分散、インメモリー、キーバリューストア」の Oracle CoherenceとInfinispanのインメモリデータグリッド製品を活用するための連携部品であるJPAプロバイダを提供します。

WebOTX JPAプロバイダでは、利用するデータグリッド製品に応じてモジュールの切り替えを行います。また、WebOTX JPAプロバイダを通してJPAインタフェースを利用することにより、データベースのスキーマ設計を意識せずアプリケーションを開発することができます。
「データプリロード機能」を利用することにより、事前にエンティティをデータグリッドへ登録し、初回アクセス時から応答の性能を向上させることができます。また、困難なパフォーマンスチューニングを容易にするために、JPA の性能情報のプロファイルデータを提供します。
これらの機能を利用するには、統合運用管理ツールの「永続化サービス」で設定を行います。

(※)JPAとは、Java Persistence API の略称です。RDBのデータを扱う Java SE および Java EEのアプリケーションを開発するためのJava用フレームワークです。

3.6.10.1. WebOTX JPAプロバイダ

アプリケーション開発者向けのフレームワークとして、Oracle Coherence やInfinispan などのデータグリッド製品を透過的に扱うことでできる独自のJPAプロバイダを提供しています。
EclipseLinkをベースとしたWebOTXのキャッシュ実装において、複数のデータグリッド製品の選択を可能とします。データグリッドを利用するための指定もEclipseLinkでの指定方法に加え、WebOTX独自の指定方法の提供により JPAエンティティクラスの修正やアプリケーションの再配備をすることなく変更が可能です。
WebOTXキャッシュ実装において、利用するデータグリッド製品に応じてモジュールの切り替えを行う拡張APIを提供します。

PersistenceProvider

アプリケーションサーバWebOTX Application Server Standard、WebOTX Application Server Enterprise、Coherence for WebOTX Application Server のPersistenceProviderの既定値としてWebOTX JPAプロバイダが使用されます。
尚、WebOTX Application Server Expressは、EclipseLinkのJPAプロバイダが使用されます。
他のプロバイダを使用する場合や、スタンドアローンで動作させる場合は、 JPAアプリケーションに付属するディスクリプタ(persistence.xml)内の<provider>タグにてプロバイダクラスの指定を行います。

persistence.xml

persistence.xmlとは、JPAエンティティを含んだ永続性アーカイブ・ファイルであることを宣言するディスクリプタです。永続化ユニット情報を定義します。 JPAアプリケーション作成の詳細については、 [ アプリケーション開発ガイド（JavaEE） > 10. JPAアプリケーションの開発] を参照してください。

データグリッド製品の選択

WebOTX上で動作するJPAアプリケーションのL2キャッシュのバックボーンとなるデータグリッド製品を選択できます。
この方法で設定を変更した場合は、アプリケーションの再配備をすることなくデータグリッドの変更が可能です。ただし、変更前と変更後でキャッシュデータは引き継がれません。
何も指定しない場合はEclipseLinkのL2キャッシュを使用します。

L2キャッシュとして利用するデータグリッドの設定は、統合運用管理ツールで行います。
統合運用管理ツールの設定値の詳細については、 [ リファレンス集運用管理・設定編 > 1.19. インメモリデータグリッド連携 ] を参照してください。
、データグリッド製品の選択は、[ リファレンス集運用管理・設定編 > 1.19. インメモリデータグリッド連携 > 1.19.1. インメモリデータグリッド連携全般の設定項目・設定方法 > 1.19.1.1. インメモリデータグリッド設定 ]で事前にデータグリッドを登録し、設定します。「L2キャッシュとして利用するデータグリッド」には、このデータグリッド名を指定してください。

永続化サービス

統合運用管理ツールの「永続化サービス」でJPAアプリケーションの永続化の定義を行うことにより永続化サービスを利用することができます。ただし、各JPAアプリケーションのディスクリプタ(persistence.xml)に設定された永続化ユニット情報が優先されます。
永続化サービスの設定についての詳細は、 [ リファレンス集運用管理・設定編 >1.19. インメモリデータグリッド連携 ] を参照してください。

3.6.10.2. データプリロード機能

データプリロード機能を利用して事前にエンティティをデータグリッドへ登録することにより初回アクセスのキャッシュ時間を短縮することができます。また、読込設定や性能情報を利用した効率的な読み込みが可能となります。
統合運用管理ツールの「永続化サービス」の設定でそれぞれのエンティティをデータプリロードの対象とするかどうかの設定を行います。
読み込み対象は、JPAの性能情報のランキングデータを元に、ランキング順に読み込むことも可能です。
データプリロードは、ドメイン起動時、もしくは、運用管理コマンド(otxadmin)のデータプリロード開始(start-data-preload)コマンドにより実行します。

データプリロード機能の設定

データプリロードの設定はドメイン単位に統合運用管理ツールで行います。
データプリロードの設定についての詳細は、 [ リファレンス集運用管理・設定編 >1.19.3. データプリロードに関する設定 ] を参照してください。

データプリロードの読み込みモード

データプリロードの読み込みは、同期・非同期のどちらか選択できます。
同期の場合はエンティティ単位に1つずつ読み込みを行います。読み込み完了まで、次のエンティティの読み込みを行いません。
非同期の場合は、複数のエンティティを同時に読み込みます。読み込み中にタイムアウトのタイマ値を超えた場合は、その時点までで読み込みを中断します。

読み込み対象の設定

読み込み対象をエンティティ単位に設定します。
エンティティ単位に細かな設定ができます。

分散環境下でのデータプリロード

同一データグリッド内で分散して読み込ませるかを指定します。
同一データグリッド内では、同じアプリケーション構成とする必要があります。

データプリロードの読み込み対象の指定

読み込む対象を、エンティティ全て、採取した性能情報から生成したランキング順、または、任意のエンティティIDを指定する方法から選択できます。
その他、読み込み最大件数、読み込みタイムアウトのタイマ値などが指定できます。
読み込み最大件数を増やした場合、読み込みタイムアウトのタイマ値をチューニングする必要があります。
チューニングの詳細については、 [ 高度な管理と運用サイクルガイド > 2. チューニング > 2.11. インメモリデータグリッド連携部品 ] を参照してください。

読み込む順序としてJPAランキング情報を利用する場合、既定値では、以下のファイルが利用されます。
${ AS_INSTALL }/config/jpa/Profile/Ranking/ENTITY_ranking.dat

JPAランキング情報生成コマンドを複数回実行した場合、 ENTITY_ranking.datファイルは、最後にコマンドを実行したランキング情報となります。
既存のファイルは、${ AS_INSTALL }/config/jpa/Profile/Ranking/backupディレクトリ配下に、ファイル名を時刻を付与した形式
[対象]_ranking_[YYYYMMDDHHmmSS]
にリネームし、移動します。
データプリロードで利用したいランキング情報のファイル名が、既定値から変更されている場合は、対象とするランキング情報のファイルを明示的に指定してください。

優先度

読み込み対象のエンティティ間で、読み込む優先順位を指定することができます。

次のエンティティの読み込み待ち合わせ

次のエンティティの読み込み処理開始までの時間を指定することができます。「プリロードの読み込みモード」が「非同期」の場合有効です。

3.6.10.3. 性能情報採取機能

パフォーマンスチューニングに必要な、JPAアプリケーションの性能情報のプロファイルデータを採取する機能、およびそのランキング情報を提供します。
JPAアプリケーションの性能情報を、スレッド、JPAエンティティ、APIの3つの視点から採取します。採取した性能情報の回収は、業務処理に影響を与えないようにするため、専用スレッドを利用し、非同期に実行します。
また、採取した性能情報から、JPAランキング情報を生成するコマンドを提供します。

性能情報採取

性能情報採取の開始、停止、および、採取情報のリセットコマンドを提供します。操作は、運用管理コマンド、もしくは統合運用管理ツールで行います。統合運用管理ツールの設定値の詳細については、 [ リファレンス集運用管理・設定編 > 1.19. インメモリデータグリッド連携 ] を参照してください。

提供するコマンドを以下に示します。

コマンド名	説明
start-jpa-performanceinfomation	性能情報採取を開始します
stop-jpa-performanceinfomation	性能情報採取を停止します
reset-jpa-performanceinfomation	採取した性能情報をリセットします。性能情報採取中は実行できません。

運用管理コマンド(otxadmin)を利用する場合、コマンドの詳細については、 [ リファレンス集運用管理・設定編 > 4. 運用管理コマンドリファレンス >4.2. 運用管理コマンド(otxadmin) ] を参照してください。

性能情報データ出力ファイル

性能情報採取で採取したデータは以下のファイルに出力されます。
${AS_DOMAIN}/logs/jpa/Profile/Work/<YYYYMMDDHHmmss>_<PID>_profile.dat

性能情報採取対象API

以下のクラスが性能情報の採取対象となります。
各クラスのメソッド、および詳細については、 [ 3.7.12.5. JPAの性能情報プロファイルデータ ] を参照してください。

JPAランキング情報生成コマンド

JPAランキング情報生成コマンド(create-jpa-ranking)を実行することにより、採取した性能情報から、処理時間、もしくは、呼び出し回数で並べ替えたランキング情報を作成します。

コマンドについての詳細は [ リファレンス集運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.11. インメモリデータグリッド連携部品コマンド] および、 [ 3.7.12.5. JPAの性能情報プロファイルデータ ] を参照してください。

3.6.10.4. Webアプリケーションのセッションレプリケーション機能

インメモリデータグリッド連携により、Webアプリケーションのセッション情報を Infinispanに登録する機能を提供しています。
セッションレプリケーションに Infinispanを利用した場合、JNDIやデータベースを利用した場合に比べて拡張性が高く、スケールアウトした場合の性能劣化も大幅に抑えることができます。

Infinispanが提供する様々な機能は、統合運用管理ツールから、WebOTXが提供するデータグリッド設定項目においてユーザが容易にカスタマイズすることが可能です。カスタマイズ可能な項目の詳細については、 [ リファレンス集運用管理・設定編 > 1.19. インメモリデータグリッド連携 ] を参照してください。

Infinispanを利用したセッションレプリケーションの設定方法については、 [リファレンス集運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.4. Webコンテナ > 1.4.7. HTTPセッション管理について > 1.4.7.3. セッションレプリケーション > Infinispanを利用するレプリケーション設定] を参照してください。

3.7. 運用管理

WebOTX の運用管理が提供している技術や特徴的な機能について説明します。

3.7.1. Java Management Extensions (JMX)

WebOTX の運用管理基盤で、Javaで標準仕様とされている以下の仕様に対応しています。 WebOTXが提供するシステム管理ツールを利用してシステムを運用管理行う上ではこの仕様をほとんど意識する必要はありませんが、システム構成を検討したり、システム構築したり、運用管理APIを使って独自の運用管理アプリケーションを作成する上で参考になります。それぞれの仕様の詳細についてはそれぞれの JSRより公開されている仕様を参照してください。

Java Management Extensions (JMX) - JSR-3
Java Management Extensions (JMX) Remote API - JSR-160
Java EE Management - JSR-77

WebOTXにおけるJMXの実装について説明します。

JMX仕様はJava言語によるネットワークマネージメントアーキテクチャで、マルチサーバで構成されたシステムをリモートの運用管理アプリケーションから一元的に運用管理するためのAPIやサービスを提供します。 WebOTXではJMXで規定された運用管理基盤を提供しています。

JMXのアーキテクチャ

JMXアーキテクチャは次の3レベルで構成されており、運用管理エージェントを通して運用管理クライアントから管理リソースを制御する仕組みとなっています。

Instrumentation level
Agent level
Distributed services level

図3.7.1-1

3.7.1.1. Instrumentation level

Instrumentation levelはJMX 管理リソースの実装を提供します。 JMX 管理リソースは具体的にはサービス、デバイス、ユーザ、アプリケーションを指します。この管理リソースをJMX準拠のJava BeanであるManaged Bean(MBean)によって管理します。MBeanは運用管理エージェントにより管理されます。 Instrumentation levelではさらにNotification メカニズムを提供します。 Notification機能により管理リソースで発生したさまざまなイベント(状態の変更、コンフィグレーションの変更、重大障害の発生など)をリモートの運用管理クライアントに通知することができます。

MBean

MBeanは対象管理リソースのマネージメントインタフェースを提供するJavaオブジェクトです。管理リソースごとにMBeanは提供されます。

MBeanの要素

MBeanのマネージメントインタフェースは次の要素を提供します。

属性 (Attribute)
管理リソースのコンフィグレーション情報を属性として定義します。MBeanの属性を取得、設定することによりコンフィグレーション情報の参照、更新が行えます。 MBeanは属性を取得、設定するためのメソッド(getterメソッド、setterメソッド)を提供します。
オペレーション (Operation)
起動、停止など管理リソースに対する操作をオペレーションとして定義します。
通知 (Notification)
管理リソースから通知するイベントをnotificationとして定義します。運用管理クライアントはNotificationを受信することにより管理リソースで発生したイベントをリアルタイムで知ることができます。
コンストラクタ (Constructor)
コンストラクタのインタフェースを提供することにより、MBeanを生成し運用管理エージェントに登録を行うことができます。

MBeanの属性およびオペレーションはJavaのpublicメソッドとして提供されます。運用管理クライアントは管理対象リソースの運用管理を行うため、運用管理エージェントを通じてMBeanの属性を取得、設定したり、オペレーションを実行したり、Notificationイベントを受信したりします。

MBeanのタイプ

JMXは4つのタイプのMBeanを規定しています。WebOTXでは全てのMBeanをModel MBeanとして提供しています。よって本書ではこれ以降MBeanと表現している箇所は全てModel MBeanとして扱います。

Standard MBean
もっともシンプルなデザインのMBeanであり、実装したMBeanでのメソッド名がそのままマネージメントインタフェースとなります。
Dynamic MBean
特定のインタフェースをインプリメントし、実行時に動的にマネージメントインタフェースを提供することができます。
Open MBean
Dynamic MBeanの一種で、属性やオペレーションやコンストラクタの型がBasic Datatype（プリミティブな型）で構成されており、ユーザフレンドリな管理環境を提供します。
Model MBean
Dynamic MBeanの一種で、起動時に自動生成され、リソースを動的に効率よく管理するためのさまざまなポリシーが実装されています。

Notification

Notificationは運用管理クライアントにリソースの状態やコンフィグレーションが変更されたことを通知するために利用します。

運用管理クライアントはリスナーを該当リソースのMBeanに登録します。 MBeanは登録しているリスナーに対して1度のみイベントの通知を行ないます。 JMXの仕様ではNotificationモデルはMBeanと同じJVMにあるAgent間の通知について規定しており、リモートプロセスへの通知についてはサポートしていませんが、 JMX Remote APIでリモートへの通知をサポートしておりWebOTXでもリモートプロセスへの通知を実装しています。

以下にJMXで規定されているNotificationインタフェースについて説明します。

Notificationクラス
発生したイベントの内容を定義します。 JMXでは次の内容が規定されています。
1. Notification Type
  発生したNotificationがどのようなイベントかを特定するための識別子です。Notificationごとに一意に識別できる’.’セパレートの文字列です。なおJMXで規定されているNotificationは”jmx.”というプレフィックスをつけています。WebOTXで規定されているNotificationは”webotx.”というプレフィックスをつけています。
2. Sequence Number
  運用管理エージェントごとに発生したNotificationを識別するための番号です。イベントが発生するたびにインクリメントされます。
3. Time Stamp
  イベントが発生した時間
4. Message
  イベントの詳細を説明する文字列
5. User Data
  リスナーにイベントについて補足するための任意の情報
  WebOTXではNotificationクラスを拡張したWebOTXEventNotificationクラスを提供し次の独自の情報を追加しています。
6. Subsystem ID
  イベントの発生元のサブシステムを識別するためのID
7. Catalog ID
  イベントの発生元のモジュールを識別するためのID
8. Message ID
  発生したイベントの種別を識別するためのID
MonitorNotificationクラス
Notificationからの派生クラスで、モニタリングイベントを受信するための実装です。MBeanの属性のモニタリングを行なうためにモニタリング設定を行い、閾値オーバーなどのイベントが発生した場合にMonitorNotificationで定義している内容が通知されます。
NotificationListenerインタフェース
MBeanから送られるイベントを受信するための実装です。イベントを受信したいクライアントは運用管理エージェントにリスナーの登録を行います。具体的にはNotificationListenerインタフェースをMBeanServerのaddNotificationListenerメソッドにより運用管理エージェントに登録します。
NotificationFilterインタフェース
MBeanから送られる通知をフィルタリングするための実装です。該当MBeanが提供するNotificationについて受信したいNotificationを特定するためにフィルタを設定します。例えばNotification TypeやSubsystem IDなどでフィルタを設定することができます。なおフィルタはリスナー登録時(MBeanServerのaddNotificationListenerメソッド)に設定します。
NotificationEmitterインタフェース
MBeanが通知を行うための実装です。NotificationをサポートするMBeanは必ず実装しなければなりません。WebOTXで提供するMBeanは全てNotificationEmitterインタフェースを実装しています。
MBeanNotificationInfoクラス
JMXではMBeanがどのようなNotificationをサポートしているかを事前に取得することが可能です。それがMBeanNotificationInfoクラスでNotificationについてのさまざまな情報を得ることができます。

Model MBeanのポリシー

Model MBeanはリソース管理を容易に行えるようにするためさまざまなポリシーが規定されています。なおMBeanのポリシーの詳細については [ 3.7.4.2. ポリシー ] を参照ください。

Notificationポリシー
Notificationロギングポリシー
Persistenceポリシー
Cacheポリシー
Protocol Mapポリシー
Exportポリシー
Visibilityポリシー
Presentationポリシー

MBeanインタフェース

WebOTXの提供するMBeanはModelMBeanインタフェースを実装しています。ModelMBeanインタフェースは管理リソースをコントロールするためのインタフェースについて規定しています。以下にその概要を示します。

MBean情報(MBeanInfo)の提供
MBeanがどのような属性、オペレーション、コンストラクタ、Notificationを提供しているかを取得するインタフェースです。またMBean、属性、オペレーション、コンストラクタ、Notificationが提供しているディスクリプタについてもMBeanInfoを通して取得することができます。
属性の取得/設定
MBeanの属性の取得/設定するためのインタフェースです。
オペレーションの実行
MBeanのオペレーションを実行するためのインタフェースです。
MBeanの永続化
MBeanが持つ永続化ポリシーの設定がある属性の値を外部ストレージに格納したり、外部ストレージからその属性値を復元したりするためのインタフェースです。WebOTXでは永続化情報はxmlファイルとして格納します。
Notificationリスナーの登録/削除
MBeanが提供するNotificationを受信するためのインタフェースです。
Notificationの通知
MBeanにNotification通知を行わせるためのインタフェースです。

3.7.1.2. Agent level

Agent levelは運用管理エージェントの実装を提供します。運用管理エージェントは直接管理リソースをコントロールし、リモートのマネージメントアプリケーション(運用管理クライアント)からリソースの利用を可能にします。

JMX Agentは MBeanServer と MBean を扱うためのサービス群で構成されています。Distributed Service levelで運用管理エージェントにアクセスするためのアダプタやコネクタを利用します。

MBeanServer

MBeanServerは運用管理エージェント内で1つ作成され、運用管理エージェントに登録された全てのMBeanを管理します。外部モジュールに対してMBeanにアクセスするためのインタフェースを提供します。ただしMBeanServerインタフェースは運用管理エージェント内の同一Java VMにあるモジュールで利用することができますが、リモートプロセスに対してそのインタフェースを公開していません。リモートプロセスに対してのインタフェースについてはJMX Remote APIで規定されています。

MBeanServerインタフェース

MBeanServerが提供するインタフェースは、以下のような操作を提供します。

Notificationリスナーの登録/削除
MBeanの作成/登録/削除
登録されているMBeanの数の取得
MBeanの検索
指定したMBeanの属性取得/設定
指定したMBeanのオペレーション実行
ドメイン名の取得

MBeanの識別

MBeanは運用管理エージェントにより一元管理されます。よって運用管理エージェントやクライアントがMBeanを一意に識別するための識別子が必要となります。 JMXではObjectNameを、各MBeanを識別するための識別子として規定しています。以下にObjectNameのフォーマットについて説明します。クライアントはMBeanを特定するのにObjectNameを使用することになります。

[フォーマット]

[domainName]:property=value[,property=value,…]

[説明]

表3.7.1.2-1
domainName	大文字・小文字を区別する文字列で、MBeanの名前空間を指定します。MBeanServer自身のDomainNameはデフォルトドメイン名として扱われ、省略することができます。省略した場合はMBeanServerにより自身のDomainNameを補完してMBeanの検索を行います。これにより運用管理クライアントはドメイン名を知らなくても省略してプロパティ値のみでMBeanの指定を行うことができます。DomainNameは’.’セパレートされたネットワークドメイン名とは逆の記述で表現します。例) jp.co.nec.mydomain
property=value	個々のMBeanを一意に決定するためのプロパティとその値を示す文字列です。少なくとも必ず1つは指定しなければなりません。

Memo

ObjectNameのフォーマットについてはJava EE Management仕様でさらに詳細に規定されています。 WebOTXのMBeanのObjectNameについてはJava EE ManagementのObjectNameフォーマットに準拠しています。

MBeanの検索

クライアントが管理リソースに対して何かアクション(属性の取得、設定、オペレーションの実行、Notificationリスナーの登録)を行う場合、まずそのリソースに対応するMBeanのObjectNameを取得する必要があります。MBeanServerインタフェースでMBeanにアクセスするためのメソッドの引数には必ずObjectNameを指定します。そこでMBeanServerのインタフェースではMBeanを検索するためのメソッド(queryNames,queryMBeans)を提供しています。JMXにおけるMBeanの検索方法について説明します。

queryNames,queryMBeansメソッドの引数は同じです。違いは返却値が条件にマッチするObjectNameクラスかMBeanクラスかにあります。なお、返却値はコレクションのjava.util.Setの実装クラスとして返されます。

queryNames,queryMBeansメソッドの第一引数はObjectNameです。このObjectNameでは以下のワイルドカードを使用することが可能です。指定したObjectNameにマッチするMBeanを検索することになります。

‘*’ :空の1つを含むどんな文字シーケンスとも一致します。

‘?’ :1つのどんな単一文字とも一致します。

以下に例を示します。次のObjectNameでMBeansがMBeanServerに登録されると仮定します。デフォルトドメイン名は”DefaultDomain”とします。

MyDomain:description=Printer,type=laser
MyDomain:description=Disk,capacity=2
DefaultDomain:description=Disk,capacity=1
DefaultDomain:description=Printer,type=ink
DefaultDomain:description=Printer,type=laser,date=1993
Socrates:description=Printer,type=laser,date=1993

“*:*” はMBeanサーバの全てのオブジェクトと一致します。パターンとして使用される無効のストリング・オブジェクトあるいは空のストリング("")名は、"*:*"と等価です。
“:*” はデフォルトのドメイン(DefaultDomain)の全てのオブジェクトと一致します。
“MyDomain:*”はMyDomainの中の全てのオブジェクトが一致します。
“??Domain:*”はMyDomainの中でオブジェクトとすべて一致します。
“*Dom*:*”はMyDomainとDefaultDomainの中の全てのオブジェクトと一致します。
“*:description=Printer,type=laser,*” は、次のオブジェクトと一致します。
MyDomain:description=Printer,type=laser
DefaultDomain:description=Printer,type=laser,date=1993
Socrates:description=Printer,type=laser,date=1993
“*Domain:description=Printer,*” は、次のオブジェクトと一致します。
MyDomain:description=Printer,type=laser
DefaultDomain:description=Printer,type=ink
DefaultDomain:description=Printer,type=laser,date=1993

queryNames,queryMBeansメソッドの第二引数はQueryExpです。 QueryExpはユーザ定義の属性値を基にMBeanのフィルタリング条件を指定します。なおQueryExpをnullに指定するとフィルタリングは行いません。 QueryExpは属性値のconstraints(数値については“equals”や”less-than”、文字列については”matches”のようなもの)から構成されています。このconstraintsは”and”や”or”のようなオペレーションも含みます。

例えば次のようなExpressionが定義できます。

“Retrieve the MBeans for which the attribute age is at least 20 and the attribute name starts with G and ends with ling”

(属性”age”の値が少なくとも20であり、属性”name”の値がGから始まりlingで終わるMBeanを検索する)

AgentService

AgentServiceはMBeanServerにデフォルトで登録されているMBeanのオペレーションを実行するためのオブジェクトです。JMXでは次に示すAgentServiceを規定しています。WebOTXの運用管理エージェントでもサポートしています。

Dynamic class loading
management applet(m-let)のを利用して、任意のネットワークロケーションから動的にMBeanのクラスやライブラリをロードするサービスです。
Monitors
MBeanの属性値を監視し、更新があった場合、他のいくつかのオブジェクトに通知を行うサービスです。
Timers
one-time alarm clockでの通知もしくは周期的に繰り返す通知ベースのスケジューリングメカニズムを提供するサービスです。
Relation service
relation typeを元にMBean間の関連を管理するサービスです。

3.7.1.3. Distributed Service level

Distribute Services level はJMX Managerの実装を提供します。Agentを操作するまたはAgentを階層化するためのインタフェースやコンポーネントについて定義します。

これらのコンポーネントの機能について以下に説明します。ただしJMX 1.2ではDistribute Services levelについて具体的な仕様を規定していません。

コネクタを通して運用管理エージェントにアクセスするためのインタフェースを提供します。
リソースを運用管理するためのさまざまな形態のクライアントを提供します。
複数の運用管理エージェントの運用管理を提供します。
セキュリティ(ユーザ認証、暗号化)を提供します。

コネクタ・アダプタ

リモートの運用管理クライアントが、管理リソースをコントロールするにはMBeanに対してアクションするためのインタフェースと通信プロトコルおよびリモート通信におけるセキュリティが必要です。このインタフェースと通信プロトコルおよびセキュリティを提供するのがコネクタ・アダプタです。JMXで規定されたクライアントと運用管理エージェントとの間で利用するのがコネクタで、既存プロトコル(HTTPを利用したWebブラウザやSMTPを利用した運用管理アプリケーション)を使用するアプリケーションから運用管理エージェントにアクセスを行うために利用するのがアダプタです。アダプタは既存プロトコルからJMXのプロトコルにプロトコル変換を行う機能を有しています。

コネクタについてはJMX Remote APIで仕様が規定されています。

運用管理クライアント

運用管理クライアントは大きく2種類に分かれます。なお以下のツールの詳細については [ 3.7.6. システム管理ツール ] を参照ください。

JMX準拠の運用管理クライアント
JMX(厳密にはJMX Remote API)で規定しているAPIを用いて運用管理エージェントにアクセスするクライアントです。
既存プロトコルを利用している運用管理クライアント
HTTPやSMTPなど既存で定義されているプロトコルを用いて運用管理エージェントにアクセスするクライアントです。

WebOTXでは運用管理を行うため、次のクライアントを提供しています。これ以外にも運用管理APIを利用して独自にカスタマイズした運用管理クライアントを作成することが可能です。

統合運用管理ツール
JMX準拠のインタフェースで運用管理エージェントにアクセスするGUIクライアントです。複数サーバに分散している全ての運用管理エージェントにアクセス可能です。
運用管理コンソール
HTTPアダプタを通してHTTPプロトコルで運用管理エージェントにアクセスするWebベースのGUIクライアントです。
運用管理コマンド
JMX準拠のインタフェースで運用管理エージェントにアクセスするコマンドベースのクライアントです。シェルスクリプトやバッチファイルから利用できます。

3.7.2. JMX Remote API

WebOTX におけるJMX Remote API の実装について説明します。

JMX 仕様ではリモートの運用管理クライアントからアダプタ・コネクタを用いて運用管理エージェントにアクセスするというガイドラインのみ示し、詳細仕様はJMX Remote API で規定しています。JMX Remote API ではJMX 準拠の運用管理クライアントが利用するコネクタの仕様について規定しています。WebOTX ではJMX Remote API で規定されたコネクタとそのコネクタを利用したJMX 準拠の運用管理クライアントを提供しています。

3.7.2.1. コネクタ

リモートの運用管理クライアントからMBeanServerにアクセスするためにJMX Remote APIではいくつかのプロトコルを利用したコネクタインタフェース(MBeanServerConnectionインタフェース)について規定しています。コネクタインタフェースについてはプロトコルに依存せず、MBeanServerのインタフェースと同様な機能を提供しています。

コネクタの種類

JMX Remote APIとしては、クライアント、サーバ間の通信プロトコルにより、標準で次の2つのコネクタについて規定しています。

RMIコネクタ
リモート呼び出しを行う場合、 Javaで一般的に用いられているRemote Method Invocation (RMI)で通信を行います。
Genericコネクタ
クライアント、サーバ間で JMX Remote APIで独自に規定したメッセージをやりとりすることにより通信を行うコネクタです。実際に通信に利用するプロトコルについては任意ですが、JMX Remote APIではTCPベースのJMX Messaging Protocol (JMXMP)について実装を提供しています。

WebOTXでは以下のコネクタを提供しています。

RMI(JRMP)コネクタ
JMXMPコネクタ

運用管理エージェントへの接続

コネクタを利用して運用管理エージェントに接続する方式について説明します。JMX Remote APIでは次の方式について規定しています。

JMXServiceURLでサーバを指定
クライアントが運用管理エージェントのアドレス、ポート番号、コネクタのサポートプロトコルがわかっている場合、 JMXServiceURLを用いて運用管理エージェントに直接アクセスすることができます。Webブラウザが直接URLを指定して目的のホームページにアクセスするのと同じイメージです。
JMXServiceURLは次の様な形式をとります。
service:jmx:protocol://host[:port][url-path]
例) service:jmx:jmxmp://agent1:6212
ホスト名”agent1”のJMXMPコネクタ(ポート6212)にアクセスする場合

コネクタを利用してWebOTX内の運用管理エージェントに接続する場合は、次のJMXServiceURLを使用します。

RMI(JRMP)コネクタ : service:jmx:rmi:///jndi/rmi://<ホスト名>:<ポート番号>/management/rmi-jmx-connector
JMXMPコネクタ : service:jmx:jmxmp://<ホスト名>:<ポート番号>

Notification

JMX Remote APIではリモートの運用管理クライアントに対して運用管理エージェントで発生したイベントを通知する機能(Notification)について規定しています。JMX Remote APIのNotificationは非同期で実装されており、バッファ上にイベントが存在する限り、そのイベントを受け取ることができます。WebOTXでもこれに基づいたリモートへのNotificationを提供します。

コネクタは全てのMBeanで発生するNotificationイベントをハンドルして運用管理クライアントに通知する機能を実装しています。そのためにコネクタはMBeanの作成、削除イベントを監視し、MBeanが作成されると、リスナーのプロキシ(下図のL’)をMBeanServerに登録します。こうして、コネクタは運用管理クライアントの接続の有無にかかわらず、運用管理エージェントで発生する全てのイベントをハンドルします。非同期通知を実装するため、コネクタはハンドルしている全てのNotificationイベントを格納するNotificationBufferを保持しています。NotificationBufferはシーケンス番号を元にイベントを管理しており、新しいイベントは前回のシーケンス番号をインクリメントして割り振られます。また、バッファのサイズは有限であり、もしバッファがいっぱいになった場合は、最も古いイベントが削除されます。

クライアント側でaddNotificationListenerメソッドにより運用管理エージェントに対してリスナーの登録を行うと、クライアントコネクションは次に検索するシーケンス番号を保持します。コネクタ側で、クライアントが持つシーケンス番号からイベントを検索しフィルタ条件に一致するイベントがあれば、そのイベントを運用管理クライアントに通知します。

図3.7.2.1-1

WebOTXでは、JMX Remote APIの通信プロトコルとしてJMXMP (JMX Messaging Protocol)、JRMP(Java Remote Method Protocol)をサポートしています。以下にJMXMPプロトコルについて説明します。なおJMX Remote APIを利用する場合には、プロファイル情報をサーバ／クライアントで一致させる必要があります。

3.7.2.2. 使用するプロファイル情報

WebOTXで利用しているJMX Remote APIのプロファイル情報は以下のとおりです。

表3.7.2.2-1
プロパティ	説明
jmx.remote.profiles	"TLS SASL/PLAIN"
jmx.remote.tls.socket.factory	(証明書の情報から作成したSSLScocketFactoryオブジェクト)
jmx.remote.tls.enabled.protocols	"TLSv1"
jmx.remote.tls.enabled.cipher.suites	"SSL_RSA_WITH_NULL_MD5"
jmx.remote.sasl.callback.handler	(クライアント) new com.nec.webotx.enterprise.admin.jmx.remote. client.UserPasswordCallbackHandler(user, password)) (サーバ) new com.nec.webotx.enterprise.admin.jmx.remote. server.PropertiesFileCallbackHandler (“${INSTANCE_ROOT}/config/keyfile”)

Callback関数は、wosv-rt.jarで提供されています。

3.7.3. Java EE Management

WebOTX におけるJava EE Management の実装について説明します。

Java EE Management 仕様は、Java EE においてJava エンタープライズ・マネージメントやモニタリング・サービスを実現するための共通フレームワークとして、JMX を基盤機能として規定しています。Java EE Management 仕様の目的は、Java EE が提供する情報にアクセスするために、より良い定義モデルを提供するJava EE アーキテクチャに対して、基本的な管理機能の概観を抽象化することにあります。加えて、この仕様ではプラットフォームリソースのモニタリングやコントロールに関わるJava EE コンポーネントに対し、共通の標準API を定義しています。Java EE Management 仕様で規定している基本機能は次のとおりです。

ディスカバリ : 管理システムの管理オブジェクトを発見したり操作したりする機能
イベント : 管理オブジェクトで発生した重要なイベントの通知を受け取る機能
状態管理 : 管理オブジェクトの実行状態を監視しコントロールする機能
パフォーマンス : 管理オブジェクトの基本性能統計をモニタリングする機能

なお、Java EE Management 仕様は上記以外に既存マネージメントプロトコル(SNMP/CIM)とのマッピングについても規定していますが、これについてはWebOTX AS では未サポートであるため説明は省略します。

3.7.3.1. 管理オブジェクト

Java EE Management仕様では、管理リソース単位で管理オブジェクト(Managed Object以下MOと略します)を定義しています。管理オブジェクトはリソースのコンフィグレーションの取得や設定、状態管理、パフォーマンス情報の取得をするためのメソッドを提供します。管理オブジェクトはJMX仕様で規定されているMBeanで実装されています。Java EE Management仕様では、Java EEアプリケーションサーバを構成する全ての管理リソースについて具体的に管理オブジェクトのインタフェースを規定しています。これに従いWebOTXも全ての管理リソースを管理オブジェクトとしてJMXのModel MBeanの形式で提供しています。

またJava EE Management仕様では、次に示す管理オブジェクトとしての振る舞いを規定しています。MOはMBeanであるため、属性、オペレーション、コンストラクタ、notificationをインタフェースとして提供します。

WebOTXでは、基本的にはJava EE Management仕様に準拠したMOとして実装していますが、一部のMBean（統計情報を管理するMBeanなど）については以下に示すObjectNameフォーマットに従っていないものもあります。

ObjectName

JMX仕様で個々のMBeanを識別するための情報としてObjectNameが用いられていますが、Java EE ManagementでもMOの識別にはObjectNameを使用しています。Java EEのObjectNameはJMXフォーマットで定められた形式であり、いくつか必須のプロパティを規定しています。

[フォーマット]

[domainName]:J2EEType=j2eeType,name=name, <parent-j2eeType>=<parent ManagedObject name> [,property=value,…]

[説明]

表3.7.3.1-1
domainName	JMX仕様	大文字・小文字を区別する文字列で、MBeanの名前空間を指定します。 MBeanサーバ自身のdomainNameはデフォルトドメイン名として扱われ、省略することができます。省略した場合はMBeanサーバにより自身のdomainNameを補完してMBeanの検索を行います。これにより運用管理クライアントはドメイン名を知らなくても省略してプロパティ値のみでMBeanの指定を行うことができます。 domainNameは’.’でセパレートされたネットワークドメイン名とは逆の記述で表現します。例) jp.co.nec.mydomain
J2EEType=j2eeType	Java EE仕様	MOの種別を表します。Java EEにおいていくつかのJ2EETypeが規定されています。WebOTX独自のJ2EETypeもいくつか規定しており、それらはWebOTXのプレフィックスをつけています。必須プロパティです。
name=name	Java EE仕様	個々のMOにつけられたオブジェクト名称です。必須プロパティです。
<parent-j2eeType>= <parentManagedObject name>	Java EE仕様	MO間の親子関係を識別するため、子のMOについては親のJ2EETypeとそのnameプロパティの値を指定します。子のMOについては必須プロパティです。
property=value	JMX仕様	上記のプロパティ以外で、個々のMOを一意に決定するためのプロパティとその値を示す文字列です。

例）

ドメイン名がFirstEverBankの、J2EEDomain管理オブジェクトのobjectName
FirstEverBank:j2eeType=J2EEDomain,name=FirstEverBank
このドメインのJ2EEServer
FirstEverBank:j2eeType=J2EEServer,name=BankServer1
このJ2EEServerに配備したJ2EEApplication
FirstEverBank:j2eeType=J2EEApplication,name=AccountsController,J2EEServer=BankServer1
そのJ2EEApplicationのEJBModule
FirstEverBank:j2eeType=EJBModule,name=BankAccount,J2EEApplication=AccountsController,J2EEServer=BankServer1
EJBModuleのエンティティBean
FirstEverBank:j2eeType=EntityBean,name=Account,EJBModule=BankAccount,J2EEApplication=AccountsController,J2EEServer=BankServer1

Memo
Java EE仕様ではMOの種別を表すプロパティとしてj2eeTypeを用いますが、WebOTXが提供するMOの一部はtypeプロパティを用いています。

必須属性

MOとして必ず持たなければならない属性がJava EE Management仕様により規定されています。MOがどのような特性をもつのかを表します。これらの属性は J2EEManagedObject インタフェースで規定されており、MOは必ずこのインタフェースを実装しなければなりません。

boolean stateManageable
trueであればMOが状態管理を行っていることを示します。
boolean statisticsProvider
trueであればMOがパフォーマンス情報を提供していることを示します。
boolean eventProvider
trueであればMOがイベント通知を行うことを示しています。イベントはJMXのNotification機能を利用して通知されます。

3.7.3.2. 状態管理

Java EE Management では状態のあるリソースのMO には状態管理を行い、運用管理クライアントに対してその状態を取得できるインタフェースを提供するように規定されています。さらに状態に変更があった場合、その変更をイベントとして通知することも規定されています。状態管理を行うためのインタフェースとしてStateManageable インタフェースが用意されており、MO はそのインタフェースを実装するようになっています。WebOTX で提供するMBean も状態管理を提供するものは全てこのインタフェースを実装しています。

StateManageable インタフェースの概要を以下に示します。

状態を表す属性
開始した時刻を示す属性
開始メソッド
停止メソッド

3.7.3.3. パフォーマンスモニタリング

Java EE Managementでは管理リソースのパフォーマンス情報を提供するため、リソース毎に提供すべきパフォーマンス情報について規定しています。それぞれのMOに対して提供すべきパフォーマンス情報を定義するインタフェースを規定しています。例えば、EJBのMOについてはEJBStatsというインタフェースを規定し、そのインタフェースを実装したMOを提供しています。パフォーマンス情報を提供するために以下のインタフェースを規定しています。なお、パフォーマンスモニタリングの詳細については [ ドメイン構築・基本設定ガイド > 9. モニタリング ] を参照してください。

Statisticインタフェース

Statisticインタフェースおよびそのサブインタフェースは、パフォーマンスデータを供給するのに必要なアクセサを規定します。以下のインタフェースが規定されています。

Statistic
パフォーマンスデータとして基本的な属性を提供します。

表3.7.3.3-1
属性名	概要
name	パフォーマンスデータの名称
unit	パフォーマンスデータの単位
description	パフォーマンスデータの概要
startTime	パフォーマンスデータを採取し始めた時間
lastUpdateTime	パフォーマンスデータを最後に取得した時間

CountStatistic
カウンタで表されるパフォーマンスデータのためのインタフェースです。例えばオペレーションの呼び出し回数などが該当します。

表3.7.3.3-2
属性名	概要
count	パフォーマンスデータの値(回数)

TimeStatistic
時間で表されるパフォーマンスデータのためのインタフェースです。例えばオペレーションのレスポンスタイムが該当します。

表3.7.3.3-3
属性名	概要
count	パフォーマンスデータを採取した回数。
maxTime	採取した中での最大値。
minTime	採取した中での最小値。
totalTime	採取したパフォーマンスデータの合計値。countで割ると平均値となる。

RangeStatistic
値が増減するパフォーマンスデータのためのインタフェースです。例えば単位時間あたりのオペレーション呼び出し回数が該当します。

表3.7.3.3-4
属性名	概要
highWaterMark	採取した中での最大値。
lowWaterMark	採取した中での最小値。
current	カレント値

BoundaryStatistic
上限値、下限値をもつパフォーマンスデータのためのインタフェースです。

表3.7.3.3-5
属性名	概要
upperBound	上限値
lowerBound	下限値

BoundedRangeStatistic
RangeStatisticとBoundedRangeStatisticを派生したインタフェース、値が増減し上限値、下限値をもつパフォーマンスデータのためのインタフェースです。

表3.7.3.3-6
属性名	概要
highWaterMark	採取した中での最大値。
lowWaterMark	採取した中での最小値。
current	カレント値
upperBound	上限値
lowerBound	下限値

Statsインタフェース

Statsインタフェースおよびそのサブインタフェースは、おのおの指定されたMOのためのパフォーマンスデータのアクセサを規定します。各Statsインタフェースは提供するパフォーマンスデータを適切なStatisticインタフェースとして提供します。 Java EE Managementとして以下のインタフェースが規定されています。なお、WebOTXでは以下に加え独自の統計情報を取得するためのStatsインタフェースを拡張しています。拡張したインタフェースについては [ ドメイン構築・基本設定ガイド > 9. モニタリング ] を参照してください。

EJBStats
EJBに関するパフォーマンスデータ
EntityBeanStats
Entity Beanに関するパフォーマンスデータ
JavaMailStats
JavaMailに関するパフォーマンスデータ
JCAStats
JCAリソースアダプタに関するパフォーマンスデータ
JDBCStats
JDBCに関するパフォーマンスデータ
JMSStats
JMSに関するパフォーマンスデータ
JTAStats
JTAに関するパフォーマンスデータ
JVMStats
JVMに関するパフォーマンスデータ
MessageDrivenBeanStats
メッセージ・ドリブンBeanに関するパフォーマンスデータ
ServletStats
Servletに関するパフォーマンスデータ
SessionBeanStats
Session Beanに関するパフォーマンスデータ
StatefulSessionBeanStats
ステートフルSession Beanに関するパフォーマンスデータ
StatelessSessionBeanStats
ステートレスSession Beanに関するパフォーマンスデータ
URLStats
URLに関するパフォーマンスデータ

3.7.3.4. イベント

Java EE Management では、イベント通知の実装についてはJMX のNotification モデルで実装することを規定しています。WebOTX でもJMX およびJMX Remote API のNotification モデルをサポートします。以下にWebOTX が標準的に提供するイベントの概要について示します。

MO(MBean)が登録された、削除された
MO(MBean)の属性値の値が更新された
WARNING レベル以上の問題が発生した
サービスのアライブチェックで生存確認に失敗した
統計情報のモニタリングで閾値を設定し、その閾値を越えた

3.7.4. WebOTX Model MBean

WebOTX では、全ての管理リソースはJMX で規定されているModel MBean として定義しています。これにより次の操作をJMX インタフェースで行うことが可能です。

ドメインの作成、削除
ドメインの開始、停止
サービスの開始、停止
コンフィグレーション情報の取得、設定
統計情報の取得
リソースの登録、削除
アプリケーションの配備、配備解除
JMX Notification の取得

Model MBean はJMX 仕様で規定されているMBean であり、WebOTX ではこのModel MBean を独自に機能強化しています。WebOTX Model MBean の機能と特長について説明します。

3.7.4.1. ディスクリプタ

Model MBean ではさまざまなポリシーについての定義を行うためディスクリプタを規定しています。ディスクリプタはポリシーについての設定を定めるフィールドとその値を保持しています。ポリシーは各フィールドに設定された値によって決定されます。ディスクリプタはModelMBeanInfo のgetDescripter()メソッドにより取得することができます。

3.7.4.2. ポリシー

Model MBeanはリソース管理を容易に行えるようにするためさまざまなポリシーが規定されています。以下にModel MBeanで規定されているポリシーについて説明します。

なお以下に説明するポリシーのフィールドについてはWebOTX側で適切な値を設定しています。利用者がその値を変更することはできません。

Notificationポリシー

Model MBeanは提供する属性に対して更新 (setAttribute/setAttributesメソッドが実行された) があった場合、属性変更通知 (jmx.attribute.change) を通知する実装がなされています。

Notificationロギングポリシー

MBeanで発生した全てのNotification通知をログファイルに記録する仕組みを実装しています。ログ採取の有無やログファイル名を設定します。

なお、WebOTXで提供するMBeanについてはNotificationロギングポリシーフィールドを設定しません。

表3.7.4.2-1
フィールド名	型	概要
Log	boolean	ロギングを行うかどうか
logFile	String	ログファイル名

Persistenceポリシー

MBeanのコンフィグレーション情報などを永続的に扱うために、Model MBeanではファイルなど外部リソースに属性の値を格納するインタフェースをサポートしています。永続化をサポートしない場合、MBeanの属性値は一時的なものになり、システムの再起動などを行った場合、設定された値はリセットされます。WebOTXでは永続化が必要なものについてはMBean毎にxmlファイルとして永続化する実装を行っています。

また、永続化するタイミングについて以下に示すポリシーをPersistPolicyフィールドに設定します。これらはMBeanの属性の特性に応じて設定します。

Never:
永続化をサポートしません。属性は一時的です。
OnTimer:
persistPeriodで指定した間隔で、その間に属性値の更新が合った場合、外部リソースに保存します。
OnUpdate:
属性値の更新を行ったタイミングで外部リソースに保存します。
NoMoreOftenThan:
属性値の更新を行ったタイミングで、なおかつ前回更新時より persistPeriod経過している場合、外部リソースに保存します。これは頻繁に更新されるデータに対して更新回数を抑えられる特長を持ちます。

表3.7.4.2-2
フィールド名	型	概要
persistPorlicy	String	PersistPolicyの値以下うちいずれか Never,OnTimer,OnUpdate,NoMoreOftenThan
persistLocation	String	永続情報を格納するディレクトリ名
persistName	String	永続情報を格納するファイル名
persistPeriod	int	persistPolicyフィールドの値がOnTimerまたはNoMoreOftenThanである場合のみ、有効です。OnTimerについては、その属性はその値が最初に設定する時に始まる各persistPeriodの最初の部分で格納されます。NoMoreOftenThanについては、前回の格納以来persistPeriodが経過していない場合を除き、更新されるごとに属性は格納されます。

Cacheポリシー

MBeanでは属性もしくはオペレーションの戻り値に対して、キャッシュポリシーとともにデータのキャッシュ値および既定値を保持しています。運用管理クライアントから、属性値の取得要求があった場合、キャッシュポリシーに従い保持しているキャッシュ値が有効であると、リソースに対してデータ取得要求を行わず、キャッシュ値を返却する仕組みを実装しています。リソースとの直接のやりとりが行われないため、実行時のアプリケーションリソースと性能の管理活動のインパクトを最小限にすることができます。

MBeanの属性で、秒単位で表現されるcurrencyTimeLimitフィールド(キャッシュ値の有効期限)とlastUpdatedTimeStampフィールド (前回更新時刻) が設定でき、運用管理クライアントから属性取得要求があった時刻がlastUpdateTimeStamp+currencyTimeLimitを過ぎている場合、属性値は無効と判断され、過ぎていない場合有効と判断されます。有効と判断された場合は即座にキャッシュ値を返却し、無効と判断された場合はgetMethodフィールドで設定されたgetterメソッドを呼び出してリソースに対して属性値取得要求を行います。 getMethodフィールドでgetterメソッドが定義されていない場合、常にdefaultフィールドで設定された既定値が返されます。

表3.7.4.2-3
フィールド名	型	概要
currencyTimeLimit	int	valueがセットされるときから最新であり古くない秒単位の期間。valueがcurrentの場合、保存された値は返され、getMethod(もし定義されれば)は起動されません。 currencyTimeLimitが0である場合、値はすべてのリクエストのために検索されなければなりません。currencyTimeLimitが-1である場合、値は古くなりません。
default	String	valueがセットされず、getMethodが定義されない場合、返されることになっている値です。
getMethod	String	属性の値を検索するために使用されるオペレーション・ディスクリプタからのオペレーション名。返されたオブジェクトは、valueフィールドで保存されます。
lastUpdatedTimeStamp	int	valueフィールドが最後に更新された時のタイムスタンプです。
setMethod	String	管理されたリソースの中で属性の値をセットするために使用されるオペレーション・ディスクリプタからのオペレーション名です。新しい値もvalueフィールドで保存されます。
value	String	もしセットされていれば、このフィールドの値は属性の現在値を表わすオブジェクトです。これはcurrencyTimeLimitが古くなっていない場合、返される属性はキャッシュされた値です。

Protocol Mapポリシー

MBeanのデフォルト動作とAPIはほとんどのアプリケーションの管理ニーズを満たすことになっています。しかしながらModel MBeanは複雑なリソース管理のシナリオも提供します。Model MBean APIはアプリケーションのMBeanの属性とMIBやCIMオブジェクトのような既存マネージメントデータモデルとのマッピングをProtocolMapフィールドの定義に従って行うことができます。

例えばMIB generatorは運用管理エージェントと相互に作用し、SNMP管理システムによってロードされたMIBファイルを作成します。作成したMIBファイルは運用管理エージェントによって知られているresource情報を表現します。

なお、WebOTXで提供するMBeanには、ProtocolMapフィールドを設定していません。

表3.7.4.2-4
フィールド名	型	概要
protocolMap	String	このフィールドの値はディスクリプタ・オブジェクトでなければなりません。プロトコル名とマップされたプロトコル値のペアのセットを含んでいます。これは、特別のプロトコル用に属性が特別の識別子(CIMスキーマ、SNMP MIB Oidなど)に関係していることを可能にします。このディスクリプタは管理されたリソースによってセットされ、管理アプリケーションにこの属性を表わすためにヒントとしてアダプタによって使用されるべきです。

Export ポリシー

運用管理エージェントがマルチ環境で動作する場合、適切なディレクトリかルックアップサービスで存在および有効性を公示することができるMBeanの運用管理を、各運用管理エージェントが容易に行うことができるようにします。 JMXでは MBeanが現在どの運用管理エージェントに登録されているかを、他の運用管理エージェントからも位置を確定できるようするしくみを提供しています。このようにディレクトリおよびルックアップサービスによりMBeanの位置を公示する場合は、Exportフィールドを定義するようになっています。

なお、WebOTXで提供するMBeanには、Exportフィールドを設定していません。

表3.7.4.2-5
フィールド名	型	概要
export	String	値はシリアライズ可能でMBeanの位置を確定できるようにするために必要な情報を含んでいるすべてのオブジェクトに存在する可能性があります。nullは、MBeanが他の運用管理エージェントに公開されてはならないことを示します。定義された値は、MBeanが他の運用管理エージェントに公開されるべきでありさらに、運用管理エージェントのアドレスが未知の場合、検出可能であるべきであることを示します。 MBeanとMBeanサーバのexportがサポートされない場合、このフィールドは無視されます。

Visibility ポリシー

運用管理を行うにあたって、運用管理クライアントをGUIで提供することは必要であるが、多種多様なMBeanの属性やオペレーションをどのように見せるかについてポリシーを規定しています。

例えば、エンタープライズマネージャは全ての情報を見て、より高いレベルの管理オブジェクトを確認する場合が殆どです。また、ドメインマネージャは、一般にアプリケーションの内容だけを見たい場合が殆どです。JMXではこのようにユーザの関心度に対応したクライアントビューを見せる仕組みを提供しています。

VisibilityフィールドはMBean、属性あるいはオペレーション単位に1～4の整数で設定します。最大は1で、ユーザの関心度が最も高いことを示しています。最小は4であまり重要性のない、特別の場合だけ必要な情報であることを意味しています。なおJMX仕様はこれら1-4のレベルを厳密に定義していません。MBean作成者に定義を委ねています。WebOTXの統合運用管理ツールでは、通常ユーザではVisibilityが1のものしか表示しません。

表3.7.4.2-6
フィールド名	型	概要
visibility	int (1-4)	MBeanの細分性のレベルを示す1～4の整数です。1は、最もよく見られるMBeanであることを表します。4は最も小さく、見られる度合いが最も少ないMBeanを表します。この値はアダプタあるいは管理アプリケーションによって使用されます。

Presentation ポリシー

PresentationStringフィールドは任意のディスクリプタに定義することができる文字列です。この文字列はコンソールに関するヒントを提供するための、XMLにフォーマットされた文字列であると規定されています。しかしながらJMX 1.2ではプレゼンテーションフィールドの標準のセットはまだ定義されておらず、WebOTXでもPresentationStringについては何も設定しません。

表3.7.4.2-7
フィールド名	型	概要
presentationString	String	どのように属性を示さなければならないか説明するXMLにコード化された文字列です。

3.7.4.3. Notification

WebOTX Model MBean ではシステムの運用管理を行なうためのさまざまなNotification を提供します。これらのNotification は統合運用管理ツールがリアルタイムに通知を受け取り、システム稼動に影響がある問題が発生したことを即座に確認することができます。

Model MBeanはJMX仕様で規定されているMBeanであり、WebOTXではこのModel MBeanを独自に機能強化しています。WebOTX Model MBeanの機能と特長について説明します。

イベントNotification

運用管理エージェントがWARNING 以上の問題を検出すると、通常その内容はOS のイベントログやシスログに出力しますが、それに加えイベントNotification を発行します。

アライブチェックNotification

WebOTX 上で動作するサービスやサーバAP プロセスなど状態管理を行なっているリソースに対してアライブチェックを行なうことができます。アライブチェックは一定時間ごとに行なわれ、生存確認が行なえなくなった場合アライブチェックNotification を発行します。

モニタリングNotification

MBean 上で統計情報として提供している属性に関して閾値を設定しモニタリングを行なうことができます。モニタリングは一定時間ごとに行なわれ、閾値を越えた場合、モニタリングNotification を発行します。

3.7.4.4. MBeanのタイプ

MBeanは以下に示すタイプで分類され、そのMBeanの持つObjectNameのcategoryプロパティでその識別を行います。以下にWebOTXで提供するMBeanのタイプについて説明します。

コンフィグMBean(category=config)

ドメインに関する構成情報を格納します。設定値は全てドメイン構成情報ファイル(domain.xml)に格納されます。

ランタイムMBean(category=runtime)

WebOTXの内部サービスやリソースに対応したMBeanで、Java EE Management仕様で規定されたMOとして実装しています。サービスやリソースに対する設定やオペレーションが行えます。
[ 3.7.5. 管理対象リソース・サービス ] に記述しているMBeanが該当します。

モニターMBean(category=monitor)

パフォーマンス情報を管理するWebOTX専用のMBeanやモニタリングを行なうMonitor MBeanが該当します。管理対象リソースのパフォーマンス情報を取得するgetterメソッドおよび子モニターMBeanの一覧を取得するオペレーションを提供します。
[ ドメイン構築・基本設定ガイド > 9. モニタリング ] に記述しているMBeanが該当します。

3.7.4.5. DottedName(CLIName)

ObjectNameはMOを一意に識別するための識別子として用いますが、MO間の親子関係を簡潔に示すためにCLINameという識別子も定義されています。 ObjectNameとCLINameは1対1でマッピングされています。WebOTXではこのCLINameを統合運用管理ツールのツリー表示や運用管理コマンドでMOを指定する識別名として利用しています。

[フォーマット]

CLINameはルートから区切り文字’.’で親MOのNameプロパティの値で連結したものです。例えば上記例にもあるObjectName “domain1:j2eeType=J2EEApplication,name=AccountsController,J2EEServer=server”のCLINameは

“server.applications.j2ee-application.AccountsController”

と表されます。

なお先頭に現れるルート識別子について以下に説明します。

表3.7.4.5-1
ルート識別子	説明
domain	ドメインのMOが該当します。
server名 (通常”server”となっている)	Java EEサーバで管理しているコンフィグMBeanを示しています。配備されたアプリケーション、登録されているリソース、動作するサービスなどのMOが該当します。
tpsystem	アプリケーショングループやプロセスグループなどStandard/EnterpriseにおけるTPモニタ関連のMOが該当します。
applications	Standard/Enterprise でプロセスグループに配備したアプリケーションおよび共有コンポーネントのMOが該当します。

なおDottedNameについては運用管理コマンド(otxadmin)のlistコマンドで一覧を確認でき、getコマンドやsetコマンドで属性値の取得/変更が可能です。なお具体的な運用管理コマンドについての説明は [ リファレンス集運用管理・設定編 > 4. 運用管理コマンドリファレンス ] を参照してください。

3.7.5. 管理対象リソース・サービス

WebOTX でMBean として提供する管理対象リソース・サービスについて説明します。MBean の持つ ObjectName のJ2EEType プロパティでその識別を行います。以下に主に使用されるMBeanについて説明を記載します。

表3.7.5-1
MBean名	説明
J2EEDomain	ドメインに対応しているMBean です。各ドメインで必ず1つ作成されます。
J2EEServer	ドメイン内の運用管理エージェントに対応しているMBean です。各ドメインで必ず1つ作成されます
J2EEApplication	ドメイン内で配備されているアプリケーション(ear)に対応しているMBean です。配備されているアプリケーションに応じて作成されます。
AppClientModule	ドメイン内で配備されたアプリケーション・クライアントモジュール(jar)に対応しているMBean です。配備されているクライアントモジュールに応じて作成されます。
EJBModule	ドメイン内で配備されたEJB モジュール(jar)に対応しているMBean です。配備されているEJB モジュールに応じて作成されます。
WebModule	ドメイン内で配備されたWeb モジュール(war)に対応しているMBean です。配備されているWeb モジュールに応じて作成されます。
ResourceAdapterModule	ドメイン内で配備されたリソースアダプタモジュール(rar)に対応しているMBean です。配備されているリソースアダプタモジュールに応じて作成されます。
EntityBean	ドメイン内で配備されたEntity Bean に対応しているMBean です。配備されているEntity Bean に応じて作成されます。
StatefulSessionBean	ドメイン内で配備されたステートフルSession Bean に対応しているMBean です。配備されているステートフルSession Bean に応じて作成されます。
StatelessSessionBean	ドメイン内で配備されたステートレスSession Bean に対応しているMBean です。配備されているステートレスSession Bean に応じて作成されます
MessageDrivenBean	ドメイン内で配備されたメッセージ・ドリブンBean に対応しているMBean です。配備されているメッセージ・ドリブンBean に応じて作成されます。
Servlet	ドメイン内で配備されたServlet に対応しているMBean です。配備されているServlet に応じて作成されます。
JVM	ドメイン内のJVM に対応しているMBean です。Java VM 単位で1つ作成されます。

WebOTXでは全てのリソースやサービスをJava EE Managementで規定されるManaged Object(JMX仕様ではMBean)として提供しています。これにより、運用管理操作は全てJMXインタフェースで行なうことが出来ます。なお提供するMBeanについては[リファレンス集運用管理・設定編 > 2. MO定義リファレンス ]を参照ください。

3.7.6. システム管理ツール

WebOTX では業務システムを容易に構築し、運用管理を行うためにさまざまなシステム管理ツールを提供しています。システム管理ツールにより、マルチドメインで構成された業務システムを一元的に運用管理することが可能になります。

WebOTXではアプリケーション実行環境を運用操作するための次のツールを提供しています。これらのツール群を利用することでリモートの運用コンソールより複数の実行環境(Webサーバ,APサーバ)の統合的な運用ができます。

システム管理ツールの詳細については[運用ツールガイド > 1. Web版統合運用管理コンソール]及び [運用ツールガイド > 2. 統合運用管理ツール(WebOTX Administrator)]を参照してください。

3.7.6.1. 統合運用管理ツール

マルチドメインで構成されたWebOTX システムを一元的に運用管理するためのGUI ツールです。コンフィグレーション、アプリケーションの配備、状態監視、障害監視、複数のサーバに分散した環境など全ての運用操作がこの統合運用管理ツールで行なうことができます。

また、JMX Agent内で発生したモニターイベントや障害通知などのNotificationイベントを受信し、画面にその内容を表示することができるため、各コンポーネントやサービスの動作状況をリアルタイムに確認することができます。

3.7.6.2. 統合運用管理コンソール

Web ブラウザを利用して管理するツールです。Ajax を利用したブラウザベースの GUI により、分散した複数のサーバの運用操作が一箇所で行なえます。
セキュリティ上の配慮から、統合運用管理ツールに比べていくつか機能の制限があります）

3.7.6.3. 運用管理コマンド

WebOTX ではオペレータを介することなく自動で運用を行うためのバッチファイルやシェルスクリプトで使用できるコマンドを提供しています。これにより自動でアプリケーションの展開、サービスの開始、停止、設定の変更等、コマンドベースでコマンドライン上から運用操作が行えます。

運用管理コマンドでは全ての運用操作を行うことができます。

3.7.6.4. 運用管理API

WebOTX ではJMX Remote API インタフェースを提供しています。これにより該当システムに特化したコマンドや運用管理ツールをJMX のAPI を利用して開発することができます。

これを用いることで、プログラミングを使用し、独自の統合運用管理ツールを作成することができます。標準のJMXおよびJMX Remote APIを利用してプログラミングすることが可能です。

3.7.7. ユーザ管理

WebOTX では、WebOTX を管理する運用ユーザ、Web アプリケーションを利用するユーザの管理に LDAP サーバを利用することができます。

3.7.7.1. LDAPサーバ

LDAP とは、「Lightweight Directory Access Protocol」の略で、つまりディレクトリサービスにアクセスするための軽量なプロトコルということになります。ディレクトリサービスとは、ネットワークを利用するユーザ名やマシン名などの様々な情報を管理するためのサービスのことで、ユーザ名などのキーとなる値から様々な情報を検索することが可能です。つまりLDAP サーバとは、LDAP と呼ばれるプロトコルを用いて参照することができるディレクトリサービスとなります。

WebOTX では、以下のLDAP サーバを利用することができます。

EnterpriseDirectoryServer V6.0(Windows, Linux, HP-UX)
OpenLDAP V2.0

LDAP サーバにWebOTX の運用に使用するユーザ、Web アプリケーションで利用するユーザを登録しておくことによって、WebOTX はLDAP サーバからユーザ情報を取得することができます。

3.7.8. サーバ管理

WebOTX AS では、WebOTX AS が動作するサーバの管理を行う機能を提供しています。

3.7.8.1. データベースサーバ管理

WebOTX AS では、データベースサーバの管理を行う機能（データベースコントローラ）を提供しています。

データベースコントローラは、JMX の運用管理インタフェースを介して、WebOTX AS のドメインからデータベースの起動や停止、状態監視を簡単に行うための機能を提供します。

データベースコントローラは、WebOTX Developer のテストサーバでJava SE 6 を利用する環境では、自動的にJavaDB(Apache Derby)のデータベースと接続を行うためのJDBC データソースの定義を作成しますので、インストールと同時に利用可能となります。

データベースの起動停止機能

データベースコントローラは、「起動コマンド」、「停止コマンド」を使い、データベースの起動や停止を行います。「起動コマンド」、「停止コマンド」はそれぞれ複数の登録が可能です。また、「コマンド発行の待ち合わせ時間(ミリ秒)」を任意に設定することで、処理に時間を要するようなコマンドにも対応します。さらに、「ドメイン起動時の連動起動使用有無」を設定することで、ドメインの起動や停止と合わせて、データベースの起動や停止を行うことができます。

データベースの状態監視機能

データベースコントローラは、制御対象のデータベースのJDBC データソースをJNDI サーバよりlookup し、SQL 命令を発行することで、状態監視を実現します。

通常、状態監視のためのSQL 命令は、JDBC データソースの「データベースサーバの状態監視コマンド」を使用します。しかし、JDBC データソースの「データベースサーバの状態監視コマンド」が設定されていない場合には、データベースコントローラで登録する「データベースの状態監視コマンド」を使用することができます。

データベースの状態監視を行うためには、状態監視モードが設定され、制御対象のデータベースの JDBC データソースが登録されている必要があります。状態監視が行われない場合には、データベースの状態として、「起動コマンド」や「停止コマンド」を発行した時の状態を保持します。

データベースの状態監視は、運用管理エージェント内で実施されます。データベースコントローラでは、JDBC データソースの「useStaticPool」プロパティにfalse を設定し、「初期プールサイズ」に0を設定します。こうすることで、状態監視では、常に１つのJDBC コネクションを使いまわすことになり、初期プールサイズが指定されているJDBC データソースを利用する場合でも不要なリソース消費を回避します。

3.7.8.2. Working Domain Coordinator

クライアントからの一時的なアクセス増が予想されるような場合、最大限の負荷を想定してサーバの増設を行うとコストがかかってしまいます。この問題を解決するために、限られた資源を有効活用し、高負荷時にも安定した業務アプリケーションの運用を可能とする機能をWorking Domain Coordinator は提供します。

Working Domain Coordinator は、負荷分散装置の利用を前提として構築された複数のサーバを効率よく利用するために、業務アプリケーションの負荷に応じて、処理を行うサーバの数を調節します。WebOTX AS 上で動作する業務アプリケーションそれぞれの負荷を監視し、負荷の低い業務アプリケーションのドメインを負荷の高い業務アプリケーションのドメインに切り替え、負荷分散装置に対して振り分け先の設定を行います。

図3.7.8.2-1

上図のような構成の場合、Working Domain Coordinator への設定の流れは次のようになります。

ビジネスロジックグループの登録
業務A、業務B をそれぞれビジネスロジックグループとして登録します。
ビジネスロジックの登録
ビジネスロジックグループ配下に、監視の対象となるプロセスグループ名をビジネスロジックとして登録します。
制御対象サーバの登録
サーバ1、サーバ2、サーバ3をそれぞれ制御対象サーバとして登録します。
制御対象ドメインの登録
各サーバのドメインを、各サーバ配下に制御対象ドメインとして登録します。この制御対象ドメインに、1.で登録したビジネスロジックグループ名を登録します。サーバ1のドメインであれば業務A のビジネスロジックグループ名を登録します。

このように、監視制御のための様々な設定を行うためのビジネスロジックグループと、制御対象ドメインを分けて登録することで、新規のサーバ(ドメイン)を登録する際に、ビジネスロジックグループ名を指定するだけで済むようになっています。

設定内容の詳細については、[ リファレンス集運用管理・設定編 > コンフィグレーション(設定一覧) > 1.13. Working Domain Coordinator ]、または、[ 高度な管理と運用サイクルガイド > 2.チューニング > 2.10. Working Domain Coordinator ]を参照してください。

負荷監視機能

Working Domain Coordinator は、通常時、一定間隔で負荷監視対象の業務アプリケーションが動作するプロセスグループのキュー滞留数を監視します。定期監視中、キュー滞留数上限値を超える負荷を検出した場合、高負荷時の監視設定に切り替え、負荷状態の継続性を判定するため、監視を続けます。高負荷時の監視では、高負荷時監視間隔で、設定されたサンプリング回数分、キュー滞留数の採取を行います。サンプリングの結果、そのうちの何割がキュー滞留数上限値を超えているかを算定し、この割合が負荷超過率を超えていた場合、継続的な高負荷状態であると判断し、その高負荷業務アプリケーションと処理に対して余力のある低負荷業務アプリケーションの切り替えを行います。

図3.7.8.2-2

業務アプリケーションの稼動時間や優先度に応じて、監視条件の設定値を調整することで、より正確に高負荷を検出することが可能となります。

また、定期監視で得られた負荷情報は、高負荷業務アプリケーションと低負荷業務アプリケーションの切り替え時の基準値として利用されます。

ビジネスロジックの切り替え機能

負荷監視機能により、継続的な高負荷状態を検出すると、高負荷業務アプリケーションを処理するサーバを増やすための切り替え処理を行います。切り替え処理は、業務アプリケーションに対する処理に余力のあるサーバをひとつ選び、そのサーバ内で稼動するドメインを停止させ、継続的な高負荷状態にある業務アプリケーションのドメイン起動を行います。低負荷業務アプリケーションは、負荷監視機能の定期監視で得られた負荷情報をもとに選択されます。また、各業務アプリケーションに設定された優先度に応じて切り替え対象の選択を調整することができます。以下の項目を業務アプリケーション毎に設定することが可能です。

優先度
業務アプリケーション毎の優先度を設定することができます。複数の異なる優先度の業務アプリケーションが動作していた場合、最も優先度が低い業務アプリケーションが停止の対象となります。また、設定が可能な最高値の優先度を設定された業務アプリケーションは、停止の対象とはなりません。
稼動サーバ数上限値
特定の業務アプリケーションが稼動するサーバ数の上限値を設定することができます。高負荷状態と判断された業務アプリケーションが稼動しているサーバ数がこの稼動サーバ数の上限値に達している場合は、切り替え処理は行われません。
稼動サーバ数下限値
特定の業務アプリケーションが稼動するサーバ数の下限値を設定することができます。余裕があり停止可能と判断された業務アプリケーションが稼動しているサーバ数がこの稼動サーバ数の下限値の場合は、そのサーバは切り替え対象のサーバとして選択されません。

高負荷業務アプリケーションが検出されても、切り替えの対象となる低負荷の業務アプリケーションが存在しない場合は、業務アプリケーションの切り替えは行われません。

負荷分散制御装置（LB）の制御機能

Working Domain Coordinator は、高負荷業務アプリケーションと低負荷業務アプリケーションの切り替えを行う際、起動および、停止するドメインのLB への振り分け先の制御を行う機能を提供します。多種多様なLB に対応するため、LB の振り分け先設定の制御タイプを３タイプ設けています。以下に各制御モードを説明します。

(1) LB 制御あり

LB の振り分け先制御をWorking Domain Coordinator が自動で行うモードです。

Working Domain Coordinator がインストールされたサーバからLB 制御コマンドを発行することで、LB の振り分け先を制御することができる場合、このモードを利用することができます。このモードでは、 Working Domain Coordinator は、切り替え処理中、停止対象のドメインに設定されたLB の振り分け先削除用コマンドを発行します。コマンド発行後、そのドメインで動作中のプロセスグループの状態を確認し、クライアントからのリクエストを処理中であれば、処理の終了を待ち合わせます。処理中のリクエストがなくなったことを確認後、ドメインを停止します。また、ドメインの起動時は、ドメインの起動処理が完了したことを確認した後、そのドメインに設定されたLB の振り分け先追加用コマンドを発行します。

(2) LB 制御なし

LB の振り分け先設定をLB のヘルスチェック機能で制御するモードです。

このモードでは、Working Domain Coordinator は、高負荷時の切り替え処理で対象のサーバを選択すると、停止対象ドメインの停止処理を行います。このとき、LB は自身のヘルスチェック機能により、停止したドメインの閉塞を検出し、そのドメインを振り分け先から削除します。次に、Working Domain Coordinator は起動対象のドメインの起動を行います。LB は、ドメイン停止時と同様、自身のヘルスチェック機能により、起動したドメインを検出し、そのドメインを振り分け先に追加します。

(3) LB 制御依頼

LB がWeb 管理ツールのみしかサポートしていないなどの理由により、コマンドを発行することで振り分け先を制御することができない場合、ドメイン停止処理を一時停止し、その間に運用管理者が振り分け先を制御するモードです。

このモードでは、Working Domain Coordinator は、高負荷時の切り替え処理でサーバを選択すると、停止対象ドメインの振り分け先からの削除依頼メッセージをイベントログ（Unix ではsyslog）に出力します。

運用担当者は、このメッセージに記載されたドメインをLB の振り分け先から削除し、Working Domain Coordinator に対してドメインの停止処理を再開する操作を行います。ドメインの停止処理の再開の通知を受けたWorking Domain Coordinator は、そのドメインの停止処理を行います。

次に、Working Domain Coordinator は起動対象のドメインの起動を行います。そのドメインの起動が完了すると、起動したドメインの振り分け先への追加依頼メッセージをイベントログ（Unix ではsyslog）に出力します。運用担当者は、このメッセージに記載されたドメインをLB の振り分け先に追加します。

振り分け先からの削除依頼や振り分け先への追加依頼のためにイベントログ（Unix ではsyslog）に出力されるメッセージID は、次のいずれかです。

OTX22040012 停止対象ドメインの振り分け先からの削除依頼メッセージ
OTX22040011 起動したドメインの振り分け先への追加依頼メッセージ

制御対象サーバのメンテナンス支援機能

Working Domain Coordinator により制御されるサーバにメンテナンスの必要が生じた場合、そのサーバに対してのみ、負荷分散制御の対象から一時的に除外する機能を提供します。制御対象から除外されたサーバには、Working Domain Coordinator の負荷の監視や高負荷業務アプリケーションと低負荷業務アプリケーションの切り替え処理などの制御は行われません。

なお、制御対象サーバを負荷分散制御の対象から除外した状態で、Working Domain Coordinator の再起動を行うと、負荷の監視は再開されます。

BIG-IP 連携機能

Working Domain Coordinator は、BIG-IP のiControl API に対応しています。このAPI を利用して、BIG-IP のプールに対し、自動的にドメインのアドレス登録や登録解除を行う機能を提供します。これによって、簡単な設定を行うだけで、エラーが発生することなく、ドメイン上で動作させる業務の切り替えを行うことができます。

障害監視機能

ドメインやその内部の各種サービスで障害が発生した際に、LB が監視するHTTP コネクション等が有効のままである場合、ドメインが負荷分散装置の振り分け先から削除されるまでの間、リクエストに対するエラーが発生し続けてしまいます。そうした状況を避けるため、ドメインやその内部の各種サービスの障害を検出し、該当ドメインを自動的に負荷分散装置の振り分け先から削除する機能です。逆に、障害が復旧した際には、自動的に負荷分散装置の振り分け先に再登録することも可能です。

3.7.8.3. 分散管理サーバ

仮想化環境やクラウド・コンピューティングによる業務システムでは、数十台～数百台からなるサーバを用いて負荷分散環境を構築します。また、スケールアウトによるサーバ増強の際には、VMwareなどの仮想化ソフトウェアを用いて既存のサーバ環境を複製し、新たな実行環境を構築する手法が取られます。

分散管理サーバは、そのような分散配置されたサーバ上のドメイン（業務実行環境）群をグルーピングし、個々のドメインへのアプリケーション配備や設定作業を一元化する運用基盤を新たに提供します。スケールアウトによるサーバ追加時にも単一の操作でグルーピング対象とすることができるようになり、規模の大きい負荷分散システムの構築・運用コストを大幅に削減します。

分散管理サーバの主な特徴を以下に示します。

グループによる複数のドメインの一括管理

分散管理サーバでは、プロキシドメインと呼ばれるドメイン上で、分散配置された複数のサーバ上のドメインをグルーピングして管理します。グルーピングされた個々のドメインは、プロキシドメインからのドメイン起動/停止要求や設定更新要求を受け取り、処理を実行します。また、個々のドメインで発生するイベントはプロキシドメイン上から確認することができるため、システムの保守・運用者は、統合運用管理ツールなどから全てのドメインに接続する必要はなく、プロキシドメインに接続するだけでグルーピングされた全てのドメインの稼動状況を把握することができます。
同様の構成からなる複数台のサーバによる負荷分散システム構築においては、分散管理サーバ上でドメインを管理することで、その構築、運用・保守のための作業コストを大幅に削減することができます。
分散配備

分散管理サーバでは、グルーピングされた個々のドメインに対して、様々な組み合わせのアプリケーションを一括して配備することができます。また、アプリケーションの配備だけでなく、環境構築のための設定情報をファイルに定義することで、配備操作によりシステム設定を一括して行うことができるようになります。
システムの保守に伴い、アプリケーションや設定の追加/更新が伴う場合にも、上述のグルーピング機能と分散配備機能を使用することで、運用・保守のための作業が大幅に短縮します。

分散配備についての詳細は、[ 3.8.3. 分散配備 ] を参照してください。
複製されたサーバ環境からのシステム構築を簡素化

分散管理サーバは、仮想化ソフトウェアなどを使用してマスタサーバから複製されたドメイン環境を、単一の操作で新規サーバ上に移すための仕組みを提供しています。具体的には、複製されたドメイン環境に含まれるサーバ依存情報(ホスト名など)を新規サーバ環境に適用する形で分散管理サーバが自動的に変換処理を行います。
これまで、システムの増強においては、新規サーバ上でドメインを再構築し、アプリケーションの配備や設定更新を再度行わなければなりませんでしたが、分散管理サーバを使用することで、システムのスケールアウト化に伴う作業コストを大幅に短縮することができます。

3.7.9. 診断サービス

WebOTX には、ドメインの診断サービスという機能があります。これは障害が起きた場合に、障害解析に必要な情報を収集して、ひとつのアーカイブファイルにまとめる機能です。問い合わせ窓口に問い合わせる際には、診断機能を実行してアーカイブファイルを作成し、これを送付することで、調査部隊に必要な情報を送付することができます。

また、診断サービスには、スローダウン障害対策機能、およびメモリ不足障害対策機能があります。これらは、APサーバ内での障害の発生または発生の予兆を独自の方法で判断・分析し、それを契機に、業務プロセスでのリクエストの処理量を制御してサーバの負荷を軽減するためのフェイルセーフ処理を実施します。また、障害が発生した際にはスレッドダンプやヒープダンプなど、障害解析に有益となる情報を自動で採取します。
これらの機能により、システム障害の発生に伴う被害を最小限に留めます。

3.7.9.1. 収集情報の種類

診断サービスで収集される情報は以下のような種類があります。

システム情報
WebOTX AS が動作しているシステムに関する情報を収集します。OS 名、OS のバージョン、CPU、メモリ・ディスクの使用状況、プロセスの一覧、ネットワークの状態、OS のログなどを収集することができます。
システム情報
WebOTX AS インストール時の情報を収集します。インストール時のログ、WebOTX AS の設定ファイル、環境変数、WebOTX AS のエディションやバージョンなどの情報を収集することができます。
コンフィグレーション情報
ドメインの設定に関する情報を収集します。ドメインの設定ファイル、JVM のエラーログファイルなど、ドメインのconfig ディレクトリ配下の情報を収集します。
配備アプリケーション情報
配備されているアプリケーションに関する情報を収集します。配備記述子ファイル、ドメインの applications ディレクトリ配下や、generated ディレクトリ配下の、配備アプリケーション設定ファイルを収集します。
ログ情報
ログを収集します。運用管理エージェントのJava VM 上の標準出力・標準エラー出力のログファイル、エージェントサービスに関するログファイルなど、ドメインのlogs ディレクトリ配下のファイルを収集します。
モニタリング情報
ドメインのモニタリング（統計）情報を収集します。
JVM 情報
運用管理エージェントのJava VM に関する情報を収集します。Java のバージョン、Java VM のメモリ、Java VM のスレッドダンプを収集します。

なお、収集される情報の詳細については、「診断サービス」を参照してください。

以降では、診断サービスの概要について説明します。

3.7.9.2. 診断サービスとは

診断サービスとは、アプリケーションサーバに障害が起きたときに、障害解析に必要な情報を収集する機能です。収集する情報は、アプリケーションサーバのログや、OSの種類やバージョン、JVMのスレッドダンプなど様々なものがあります。 WebOTXの診断サービスには、リモートモードとローカルモードという２つのモードが存在します。下の図は、２つのモードについて簡単に表したものです。

図3.7.9.2-1

リモートモード

リモートモードは、統合運用管理ツールまたは運用管理コマンドから実行できます。これは、ドメインに対するエージェントプロセスを経由して、実行するため、遠隔地からも操作を行うことができます。ただし、収集した情報をネットワーク経由で取得することはできません。アプリケーションサーバが稼動しているマシン内に保存されます。

ローカルモード

ローカルモードは、運用管理コマンドで、localオプションをtrueとすることで、実行できます。ローカルモードは、ドメインに対するエージェントプロセスを経由せずに、情報を収集するため、アプリケーションサーバが稼動しているマシン上でしか実行できません。しかし、ドメインに対するエージェントプロセスを経由しないため、ドメインに対するエージェントプロセスが起動していなくても情報が収集できるという利点があります。

診断サービス実行の流れ

診断サービスの実行は、次のような手順で行われます。

1.　収集したい情報を設定します

統合運用管理ツール、または運用管理コマンドを用いて、収集したい情報の属性値をtrueにします。ただし、この変更はドメインが起動しているときのみ可能であり、ドメインが停止しているときは変更できません。ドメインが停止している場合は、直前に設定した値がそのまま使用されます。

2.　診断サービスを実行します

統合運用管理ツール、または運用管理コマンドを用いて診断サービスを実行します。統合運用管理ツールの場合は、ドメインが起動していなければ接続できないため、リモートモードでの実行となります。運用管理コマンドの場合は、 localオプションをtrueにした場合に、ローカルモードで実行されます。

3.　診断レポートを確認する

診断サービスを実行すると、設定された情報を収集して、1つのzipファイルとして出力します。 zipファイル名は、ユーザが任意に指定できます。また、各情報が実際に収集できたかを確認するために、 zipファイルと同名のテキストレポートが、zipファイルと同じディレクトリに出力されます。各収集項目の収集結果が、 OKかNGで出力されています。NGの場合は、収集できなかった原因に関するメッセージがwebotx_agent.logに出力されているので、そちらを確認してください。

zipファイル名を指定しなかった場合は、ドメイン名と実行された時間から次のような名前で出力します。
・診断レポート（zipファイル）出力ディレクトリ : ${INSTANCE_ROOT}/diagnostic-reports
・診断レポート（zipファイル）名 : <診断対象ドメイン名>_<実行日時>_report.zip
・テキストレポート : <zipファイル名>.txt

例）
・診断レポート（zipファイル）出力ディレクトリ : C://WebOTX/domains/domain1/diagnostic-reports
・診断レポート（zipファイル）名 : domain1_2008-6-3_18-27-1_report.zip
・テキストレポート : domain1_2008-6-3_18-27-1_report.txt

3.7.9.3. スローダウン障害対策機能

スローダウンが継続的に発生する状況を検出した際に、業務リクエストに対する応答を一定時間遅らせるとともに、動作スレッド数を一定の割合で抑制することで、業務が動作するプロセスにかかる負荷の抑制、および、処理時間の改善を図ります。状況が改善できなければプロセスを異常終了させることでスローダウン障害からの復旧を行います。

3.7.9.4. メモリ不足障害対策機能

OutOfMemoryError の発生やメモリ使用量が非常に多い状況を検出した際に、業務リクエストに対する応答を一定時間遅らせるとともに、動作スレッド数を一定の割合で抑制することで、業務が動作するプロセスのメモリ使用量の抑制、および、処理時間の改善を図ります。状況が改善できなければプロセスを異常終了させることでメモリ不足障害からの復旧を行います。

3.7.10. セキュリティ

インターネット業務システムでは、外部からの不正侵入に対するセキュリティが重要です。また、イントラネットの業務システムでも、社員ID の一元管理などのSingle Sign On 技術が要求されています。 WebOTX では、各種のセキュリティ製品との連携でセキュリティの高い業務システムを構築できます。例えば、ファイアウォール製品との連携が容易にできるようにサーバ側のポートの固定化や、インターネット上に仮想の専用線を構築するVirtual Private Network (VPN)を実現する製品SOCKSVPN との連携、インターネットで最も多く使われている暗号化技術Secure Socket Layer (SSL)を使ったCORBA 通信、 HTTP 通信、などができます。

アプリケーションは、セキュリティ技術を意識しないか、標準のセキュリティアプリケーションインタフェースを使うことができますので、将来、セキュリティ技術が変更されても、柔軟に対応することが可能です。

3.7.11. 負荷分散

WebOTX ではスケーラビリティを向上するためにアプリケーションサーバ、Web サーバを複数台並列に配置した負荷分散運用を行うことができます。負荷分散運用を行うことにより、大量のトラフィックに耐え得る安定したシステム運用が可能になります。また負荷分散運用を行うことによりサーバ障害時にも縮退運転を行いシステムに対する影響を最小限にすることができます。

負荷分散装置による負荷分散

負荷分散装置を利用して、Web サーバの負荷分散を行うことが可能です。現在では、負荷分散装置も多種多様なものが出回っており、これらを利用することで複数台の Web サーバを負荷状況によって切り分けることができます。セッションを維持して同じクライアントからのリクエストは、常に同じ Web サーバで処理することも可能です。また、障害が発生した場合も、動作可能な Web サーバを自動的に選択します。負荷分散の方法は、単純なラウンドロビン方式や、重み付けを付加したものなど、装置によりさまざまな方法が提供されています。

3.7.12. 性能計測

WebOTX ではシステムの稼動状態を確認するため統計情報を提供しています。

3.7.12.1. MBean 統計情報

WebOTX では稼動状況を把握するための各種統計情報をMBean として実装しています。この統計情報をJMX API や運用管理コマンドを利用して取得することができます。

統合運用管理ツールを通して、リアルタイムに稼動状況を確認することができます。また閾値を設定すると、閾値を越えた時点でJMX Notification 通知を受けることができます。

3.7.12.2. ジャーナル

ジャーナルはWebOTX の稼働状況を評価するための性能及び統計情報を各種レポートとして以下の項目について採取します。

アクティビティレポート
指定された時間間隔におけるWebOTX 全体の動作状況を表示します。表示項目はCPU 使用量（秒）、CPU 使用率（％）、オペレーション処理数（件数、％）、スループット、レスポンス時間（最大、最小、平均）、キュー滞留数(最大、最小、平均)です。
トランザクション・サマリレポート
アプリケーショングループ、プロセスグループ単位に発生したオペレーション処理状況を表示します。表示項目はCPU 時間の合計（秒、使用率）、オペレーション処理件数の合計（件数、％）、レスポンス時間（最大、最小、合計）、キュー滞留数(最大、最小、平均)です。
CPU 時間タイムチャート
全体、アプリケーショングループ、プロセスグループ単位に、一定時間間隔におけるオペレーション処理とCPU 時間の推移を表示します。表示項目は単位時間あたりのCPU 時間の合計とそのグラフ化です。
トランザクション件数タイムチャート
全体、アプリケーショングループ、プロセスグループ単位に、一定時間間隔におけるオペレーション処理件数の推移を表示します。表示項目は単位時間あたりのオペレーション件数の合計とそのグラフ化です。
トランザクション件数レスポンス時間グラフ
全体、アプリケーショングループ、プロセスグループ単位に、一定レスポンス時間内で処理されたオペレーション処理数の一覧表示です。表示項目はオペレーション処理件数とそのグラフ化です。

3.7.12.3. イベントジャーナル

イベントジャーナルは個々のオペレーション処理に関して処理の流れを詳細に採取します。システムの詳細な性能分析をすることが可能になります。以下にイベントジャーナルの主な採取ポイントを以下に示します。

図3.7.12.3-1

表3.7.12.3-1
コンポーネント	番号	採取ポイント
通信リスナ (IIOPリスナ)	01	レスポンスをキューアウト時
	02	リクエストをキューイン時
	03	リクエストを受信完了時
	04	リクエストを送信完了時
ベースライブラリ	01	オブジェクトマネージャ呼び出し時
	06	レスポンスキューイング時
	07	リクエストキューアウト時
	08	オブジェクトマネージャ戻り時
オブジェクトマネージャ	call in	ユーザオペレーション呼び出し時
オブジェクトマネージャ	call out	ユーザオペレーション戻り時

3.7.12.4. オペレーションジャーナル

オペレーションジャーナルは、システムの稼働状況・統計をオペレーション単位でレポート出力します。

オペレーションごとの実行時間情報（平均値・最大値・最小値）、オペレーションの実行回数、プロセスグループごとの稼動スレッド数(起動中のスレッドのうち実際にオペレーションを実行しているスレッド数)を知ることができます。それぞれの情報について、全体の統計と単位時間ごとの推移がレポート出力されます。

R6.3 からはこれに加えて、オペレーションのCPU 使用時間（ユーザモード、カーネルモード）の平均・最大・最小、プロセスグループのCPU 使用率・CPU 使用時間(ユーザモード、カーネルモード)をレポート出力します。

またオペレーション情報のサマリに「実行時間の上限の推奨値」が追加されました。実行時間上限を設定する際の参考にしてください。

3.7.12.5. JPAの性能情報プロファイルデータ

インメモリデータグリッド連携部品では、性能情報採取機能によりJPAの性能情報を採取し、ランキング情報を生成することにより、パフォーマンスチューニングに必要なプロファイルデータを提供します。
また、ランキング情報は、データプリロードの読み込む順序として利用することができます。
情報採取は、ドメイン単位で行います。

性能情報採取対象

性能情報採取機能では、JPAアプリケーションに組み込まれた以下のクラスのメソッドが性能情報の採取対象となります。

表3.7.12.5-1 性能情報対象メソッド一覧
クラス名　javax.persistence.EntityManager
	メソッド名
	public void persist(Object entity)
	public <T> T merge(T entity)
	public void remove(Object entity)
	public <T> T find(Class<T> entityClass, Object primaryKey)
	public <T> T find(Class<T> entityClass, Object primaryKey, Map<String, Object> properties)
	public <T> T find(Class<T> entityClass, Object primaryKey, LockModeType lockMode)
	public <T> T find(Class<T> entityClass, Object primaryKey, LockModeType lockMode, Map<String, Object> properties)
	public <T> T getReference(Class<T> entityClass, Object primaryKey)
	public void flush()
	public void lock(Object entity, LockModeType lockMode)
	public void lock(Object entity, LockModeType lockMode, Map<String, Object> properties)
	public void refresh(Object entity)
	public void refresh(Object entity, Map<String, Object> properties)
	public void refresh(Object entity, LockModeType lockMode)
	public void refresh(Object entity, LockModeType lockMode, Map<String, Object> properties)
	public void detach(Object entity)
	public boolean contains(Object entity)
	public LockModeType getLockMode(Object entity)
	public Query createQuery(String qlString)
	public <T> TypedQuery<T> createQuery(CriteriaQuery<T> criteriaQuery)
	public <T> TypedQuery<T> createQuery(String qlString, Class<T> resultClass)
	public Query createNamedQuery(String name)
	public <T> TypedQuery<T> createNamedQuery(String name, Class<T> resultClass)
	public Query createNativeQuery(String sqlString)
	public Query createNativeQuery(String sqlString, Class resultClass)
	public Query createNativeQuery(String sqlString, String resultSetMapping)
	public void joinTransaction()
	public void close()
	public EntityTransaction getTransaction()

クラス名 javax.persistence.Query
	メソッド名
	List getResultList()
	Object getSingleResult()
	int executeUpdate()
	Query setMaxResults(int maxResult)
	int getMaxResults()
	Query setFirstResult(int startPosition)
	int getFirstResult()

クラス名 javax.persistence.TypedQuery
	メソッド名
	List<X> getResultList()
	X getSingleResult()
	TypedQuery<X> setMaxResults(int maxResult)
	TypedQuery<X> setFirstResult(int startPosition)

クラス名 javax.persistence.EntityTransaction
	メソッド名
	public void begin()
	public void commit()
	public void rollback()

クラス名 javax.persistence.Cache
	メソッド名
	public boolean contains(Class cls, Object primaryKey)
	public void evict(Class cls, Object primaryKey)
	public void evict(Class cls)
	public void evictAll()

クラス名 javax.persistence.PersistenceUnitUtil
	メソッド名
	public Object getIdentifier(Object entity)

クラス名 javax.persistence.criteria.CriteriaQuery
	メソッド名
	CriteriaQuery<T< select(Selection<? extends T< selection)
	CriteriaQuery<T> multiselect(Selection<?<... selections)
	CriteriaQuery<T> multiselect(List<Selection<?<< selectionList)
	CriteriaQuery<T> where(Expression<Boolean> restriction)
	CriteriaQuery<T> where(Predicate... restrictions)
	CriteriaQuery<T> groupBy(Expression<?<... grouping)
	CriteriaQuery<T> groupBy(List<Expression<?<< grouping)
	CriteriaQuery<T> having(Expression<Boolean> restriction)
	CriteriaQuery<T> having(Predicate... restrictions)
	CriteriaQuery<T> orderBy(Order... o)
	CriteriaQuery<T> orderBy(List<Order> o)
	CriteriaQuery<T> distinct(boolean distinct)
	List<Order> getOrderList()
	Set<ParameterExpression<?>> getParameters()

クラス名 avax.persistence.criteria.Subquery
	メソッド名
	Subquery<T> select(Expression<T> expression)
	Subquery<T> where(Expression<Boolean> restriction)
	Subquery<T> where(Predicate... restrictions)
	Subquery<T> groupBy(Expression<?>... grouping)
	Subquery<T> groupBy(List<Expression<?>> grouping)
	Subquery<T> having(Expression<Boolean> restriction)
	Subquery<T> having(Predicate... restrictions)
	Subquery<T> distinct(boolean distinct)
	<Y> Root<Y> correlate(Root<Y> parentRoot)
	<X, Y> Join<X, Y> correlate(Join<X, Y> parentJoin)
	<X, Y> CollectionJoin<X, Y> correlate(CollectionJoin<X, Y> parentCollection)
	<X, Y> SetJoin<X, Y> correlate(SetJoin<X, Y> parentSet)
	<X, Y< ListJoin<X, Y> correlate(ListJoin<X, Y> parentList)
	<X, K, V< MapJoin<X, K, V< correlate(MapJoin<X, K, V< parentMap)
	AbstractQuery<?> getParent()
	Expression<T> getSelection()
	Set<Join<?, ?>> getCorrelatedJoins()

クラス名 org.eclipse.persistence.transaction.AbstractTransactionController
	メソッド名
	void beginTransaction(AbstractSession session)
	void commitTransaction(AbstractSession session)
	void rollbackTransaction(AbstractSession session)
	void markTransactionForRollback()

クラス名 org.eclipse.persistence.descriptors.DescriptorEventManager
	メソッド名
	public void executeEvent(DescriptorEvent event)

クラス名 org.eclipse.persistence.eis.EISAccessor
	メソッド名
	public Object basicExecuteCall(Call call, AbstractRecord translationRow, AbstractSession session)

クラス名 org.eclipse.persistence.exceptions.OptimisticLockException
	メソッド名
	protected OptimisticLockException(String theMessage, ObjectLevelModifyQuery query)

クラス名 org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor
	メソッド名
	public Object basicExecuteCall(Call call, AbstractRecord translationRow, AbstractSession session)
	public void closeStatement(Statement statement, AbstractSession session, DatabaseCall call)
	public Integer executeDirectNoSelect(Statement statement, DatabaseCall call, AbstractSession session)
	public ResultSet executeSelect(DatabaseCall call, Statement statement, AbstractSession session)
	public Object processResultSet(ResultSet resultSet, DatabaseCall call, Statement statement, AbstractSession session)
	protected Vector buildThreadCursoredResult(final DatabaseCall dbCall, final ResultSet resultSet, final Statement statement, final ResultSetMetaData metaData, final AbstractSession session)

クラス名 org.eclipse.persistence.internal.databaseaccess.DatabasePlatform
	メソッド名
	public boolean wasFailureCommunicationBased(SQLException exception, Connection connection, AbstractSession sessionForProfile)

クラス名 org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor
	メソッド名
	public void connect(Login login, AbstractSession session)
	public void disconnect(AbstractSession session)
	public void beginTransaction(AbstractSession session)
	public void commitTransaction(AbstractSession session)
	protected void reconnect(AbstractSession session)
	public void rollbackTransaction(AbstractSession session)

クラス名 org.eclipse.persistence.internal.databaseaccess.DynamicSQLBatchWritingMechanism
	メソッド名
	protected PreparedStatement prepareBatchStatement(AbstractSession session)
	protected Statement prepareJDK12BatchStatement(AbstractSession session)

クラス名 org.eclipse.persistence.internal.databaseaccess.ParameterizedSQLBatchWritingMechanism
	メソッド名
	protected PreparedStatement prepareBatchStatements(AbstractSession session)

クラス名 org.eclipse.persistence.internal.descriptors.ObjectBuilder
	メソッド名
	public Object buildObject(ObjectBuildingQuery query, AbstractRecord databaseRow, JoinedAttributeManager joinManager)

クラス名 org.eclipse.persistence.internal.identitymaps.IdentityMapManager
	メソッド名
	public CacheKey acquireDeferredLock(Object primaryKey, Class domainClass, ClassDescriptor descriptor)
	public CacheKey acquireLock(Object primaryKey, Class domainClass, boolean forMerge, ClassDescriptor descriptor)
	public CacheKey acquireLockNoWait(Object primaryKey, Class domainClass, boolean forMerge, ClassDescriptor descriptor)
	public CacheKey acquireLockWithWait(Object primaryKey, Class domainClass, boolean forMerge, ClassDescriptor descriptor, int wait)
	public void acquireReadLock()
	public CacheKey acquireReadLockOnCacheKey(Object primaryKey, Class domainClass, ClassDescriptor descriptor)
	public CacheKey acquireReadLockOnCacheKeyNoWait(Object primaryKey, Class domainClass, ClassDescriptor descriptor)
	public boolean containsKey(Object key, Class theClass, ClassDescriptor descriptor)
	public Vector getAllFromIdentityMap(Expression selectionCriteria, Class theClass, Record translationRow, int valueHolderPolicy, boolean shouldReturnInvalidatedObjects)
	public void invalidateObjects(Expression selectionCriteria, Class theClass, Record translationRow, boolean shouldInvalidateOnException)
	public CacheKey getCacheKeyForObjectForLock(Object primaryKey, Class theClass, ClassDescriptor descriptor)
	public CacheKey getCacheKeyForObject(Object primaryKey, Class theClass, ClassDescriptor descriptor, boolean forMerge)
	public Object getFromIdentityMap(Object key, Class theClass, boolean shouldReturnInvalidatedObjects, ClassDescriptor descriptor)
	public Object getFromIdentityMap(Expression selectionCriteria, Class theClass, Record translationRow, int valueHolderPolicy, boolean conforming, boolean shouldReturnInvalidatedObjects, ClassDescriptor descriptor)
	public Object getFromIdentityMapWithDeferredLock(Object key, Class theClass, boolean shouldReturnInvalidatedObjects, ClassDescriptor descriptor)
	public Object getWrapper(Object primaryKey, Class theClass)
	public Object getWriteLockValue(Object primaryKey, Class domainClass, ClassDescriptor descriptor)
	public CacheKey putInIdentityMap(Object domainObject, Object keys, Object writeLockValue, long readTime, ClassDescriptor descriptor)
	public Object removeFromIdentityMap(Object key, Class domainClass, ClassDescriptor descriptor, Object objectToRemove)
	public void setWrapper(Object primaryKey, Class theClass, Object wrapper)
	public void setWriteLockValue(Object primaryKey, Class theClass, Object writeLockValue)

クラス名 org.eclipse.persistence.internal.oxm.XMLObjectBuilder
	メソッド名
	public Object buildObject(ObjectBuildingQuery query, AbstractRecord databaseRow, JoinedAttributeManager joinManager)

クラス名 org.eclipse.persistence.internal.queries.StatementQueryMechanism
	メソッド名
	protected void setCallFromStatement()

クラス名 org.eclipse.persistence.internal.sessions.AbstractSession
	メソッド名
	public void log(int level, String category, String message, Object[] params, Accessor accessor, boolean shouldTranslate)
	public void log(int level, String message, Object[] params, Accessor accessor, boolean shouldTranslate)
	public void logThrowable(int level, String category, Throwable throwable)
	public Object executeQuery(DatabaseQuery query, AbstractRecord row, int retryCount)

クラス名 org.eclipse.persistence.internal.sessions.DatabaseSessionImpl
	メソッド名
	protected void preConnectDatasource()

クラス名 org.eclipse.persistence.internal.sessions.MergeManager
	メソッド名
	public void mergeChangesFromChangeSet(UnitOfWorkChangeSet uowChangeSet)

クラス名 org.eclipse.persistence.internal.sessions.UnitOfWorkImpl
	メソッド名
	public void rollbackTransaction()
	public Object assignSequenceNumber(Object object, ClassDescriptor descriptor)
	protected void assignSequenceNumbers(Map objects)
	protected void commitToDatabaseWithChangeSet(boolean commitTransaction)
	protected void mergeChangesIntoParent()
	public Object mergeClone(Object rmiClone, int cascadeDepth)
	public Object registerExistingObject(Object objectToRegister, ClassDescriptor descriptor, Object queryPrimaryKey)
	public synchronized Object registerNewContainerBean(Object newObject)
	public synchronized Object registerNewContainerBeanForCMP(Object newObject)
	protected Object registerNewObject(Object implementation, ClassDescriptor descriptor)
	public void registerNewObjectForPersist(Object newObject, Map visitedObjects)
	protected Object registerObject(Object object, ClassDescriptor descriptor)

クラス名 org.eclipse.persistence.internal.sessions.coordination.ProfileDiscoveryStartedCommand
	メソッド名
	public void executeWithSession(AbstractSession session)

クラス名 org.eclipse.persistence.internal.sessions.coordination.ProfileDiscoveryStoppedCommand

	メソッド名
	public void executeWithSession(AbstractSession session)

クラス名 org.eclipse.persistence.internal.sessions.coordination.ProfileMessageReceiveCommand

	メソッド名
	public void executeWithSession(AbstractSession session)

クラス名 org.eclipse.persistence.internal.sessions.coordination.ProfileMessageSentCommand
	メソッド名
	public void executeWithSession(AbstractSession session)

クラス名 org.eclipse.persistence.internal.sessions.coordination.ProfileRemoteChangeSetCommand
	メソッド名
	public void executeWithSession(AbstractSession session)

クラス名 org.eclipse.persistence.platform.database.SQLServerPlatform
	メソッド名
	public Object executeStoredProcedure(DatabaseCall dbCall, PreparedStatement statement, DatabaseAccessor accessor, AbstractSession session)

クラス名 org.eclipse.persistence.platform.database.SybasePlatform
	メソッド名
	public Object executeStoredProcedure(DatabaseCall dbCall, PreparedStatement statement, DatabaseAccessor accessor, AbstractSession session)

クラス名 org.eclipse.persistence.queries.DatabaseQuery
	メソッド名
	public void checkPrepare(AbstractSession session, AbstractRecord translationRow, boolean force)

クラス名 org.eclipse.persistence.queries.ReadAllQuery
	メソッド名
	public Object execute(AbstractSession session, AbstractRecord row)

クラス名 org.eclipse.persistence.queries.ReadObjectQuery
	メソッド名
	protected Object checkEarlyReturnLocal(AbstractSession session, AbstractRecord translationRow)

クラス名 org.eclipse.persistence.sessions.SessionEventManager
	メソッド名
	public void missingDescriptor(Class missingClass)
	public void moreRowsDetected(DatabaseCall call)
	public void noRowsModified(ModifyQuery query, Object object)
	public void outputParametersDetected(Record outputRow, DatasourceCall call)
	public void postAcquireClientSession()
	public void postAcquireConnection(Accessor accessor)
	public void postAcquireUnitOfWork()
	public void postBeginTransaction()
	public void postCommitTransaction()
	public void postCommitUnitOfWork()
	public void postConnect(Accessor accessor)
	public void postExecuteQuery(DatabaseQuery query, Object result)
	public void postReleaseClientSession()
	public void postReleaseUnitOfWork()
	public void postResumeUnitOfWork()
	public void postRollbackTransaction()
	public void postDistributedMergeUnitOfWorkChangeSet(UnitOfWorkChangeSet changeSet)
	public void postMergeUnitOfWorkChangeSet(UnitOfWorkChangeSet changeSet)
	public void preBeginTransaction()
	public void preCalculateUnitOfWorkChangeSet()
	public void postCalculateUnitOfWorkChangeSet(UnitOfWorkChangeSet changeSet)
	public void preCommitTransaction(
	public void preCommitUnitOfWork()
	public void preExecuteQuery(DatabaseQuery query
	public void preLogin(Session session)
	public void postLogin(Session session)
	public void prepareUnitOfWork()
	public void preReleaseClientSession()
	public void preReleaseConnection(Accessor accessor)
	public void preReleaseUnitOfWork()
	public void preRollbackTransaction()
	public void preDistributedMergeUnitOfWorkChangeSet(UnitOfWorkChangeSet changeSet)
	public void preMergeUnitOfWorkChangeSet(UnitOfWorkChangeSet changeSet)

クラス名 org.eclipse.persistence.sessions.server.ClientSession
	メソッド名
	public ClientSession(ServerSession parent, ConnectionPolicy connectionPolicy, Map properties)

クラス名 org.eclipse.persistence.sessions.server.ConnectionPool
	メソッド名
	public synchronized Accessor acquireConnection(
	public synchronized void releaseConnection(Accessor connection)

クラス名 org.eclipse.persistence.transaction.AbstractSynchronizationListener
	メソッド名
	public void afterCompletion(Object status)
	public void beforeCompletion()

性能情報の採取方法

性能情報の採取を開始する場合、性能情報採取開始コマンドの実行、もしくは統合運用管理ツールにより設定してください。

otxadminコマンドによる実行
実行例)

otxadmin> start-jpa-performanceinfomation --user admin --password adminadmin

性能情報の出力先

性能情報のデータファイルは以下のディレクトリに格納されます。
データの各項目は、":"(コロン)区切りで出力されます。

表3.7.12.5-39　性能情報の出力先
性能情報の出力先フォルダ	ファイル名
${AS_DOMAIN}/logs/jpa/Profile/Work/	YYYYMMDDHHmmss_PID_profile.dat

性能情報採取データの出力項目

出力項目は以下の通りです。

表3.7.12.5-40　性能情報採取データ　出力項目
名前	説明
タイムスタンプ（ミリ秒）	性能情報登録時のシステムミリ秒
タイムスタンプ（ナノ秒）	性能情報登録時のシステムナノ秒
スレッド名	性能情報登録を行ったスレッド名
スレッドID	性能情報登録を行ったスレッドID
メッセージ	性能情報メッセージ。以下の性能情報、もしくは、例外情報が格納されます。

表3.7.12.5-41　メッセージ(性能情報)出力項目
名前	説明
NO	シーケンスNo（１～Long.MAX_VALUE）
レコードタイプ	「P」固定（Profile）
I/O	メソッド開始時：Ｉメソッド終了時：Ｏ
API名	"クラス名#メソッド名"　の形式で出力
エンティティ名	エンティティ名（完全修飾名）
エンティティID	エンティティＩＤ
クエリ	クエリ名 or JPQL or SQL

表3.7.12.5-42　メッセージ(例外情報)出力項目
名前	説明
NO	シーケンスNo（１～Long.MAX_VALUE）
レコードタイプ	「E」固定（Exception）
API名	"クラス名#メソッド名"　の形式で出力
エンティティ名	エンティティ名（完全修飾名）
エンティティID	エンティティＩＤ

JPAランキング情報

JPAランキング情報生成コマンド(create-jpa-ranking)を使用することにより、出力した性能情報のファイルからJPAのランキング情報の作成を行うことができます。
また、生成したJPAランキング情報は、データプリロードの読み込み順序として利用することができます。
コマンドについての詳細は [ リファレンス集運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.11. インメモリデータグリッド連携部品コマンド] を参照してください。

3.8. アプリケーション配備

Java EE では、アプリケーションの登録・削除を配備(デプロイ)、配備解除(アンデプロイ)と呼びます。 WebOTX ASでは、GUIツールである統合運用管理ツールを用いて配備・配備解除できます。また運用管理コマンドを利用する事により、シェルスクリプトやバッチファイルから配備・配備解除することもできます。

3.8.1. アプリケーションの種類

WebOTX ASは以下に示す8種類のアプリケーションをサポートします。アプリケーションは種類ごとにアーカイブの形式や拡張子が仕様で定められています。

表3.8.1-1
	拡張子	アーカイブ形式の仕様
Webアプリケーション	.war	Java EE
EJBアプリケーション	.jar	Java EE
エンタープライズ・アプリケーション	.ear	Java EE
アプリケーション・クライアント	.jar	Java EE
リソースアダプタ	.rar	Java EE
OSGiバンドル	.jar	OSGi
CORBAアプリケーション	.cpk	WebOTX AS固有
共有コンポーネント	.spk	WebOTX AS固有

Webアプリケーション(Web Application)

WebアプリケーションはWebアプリケーションのためのコンテンツを格納します。静的なHTMLを提供するだけでなく、サーブレットやJSPを利用して動的にコンテンツを生成することもできます。

EJBアプリケーション(EJB Application)

EJBアプリケーションにはEJB(Enterprise JavaBeans)を格納します。またEJBが利用するユーティリティクラスを含めることもできます。

エンタープライズ・アプリケーション(Enterprise Application)

エンタープライズ・アプリケーションは、Webアプリケーション,EJBアプリケーション,アプリケーション・クライアント,リソースアダプタなどを1つ以上格納した統合アプリケーションです。Java EEのアプリケーションを提供する場合、1つのEARでアプリケーションを組み立てることもできますし、また個別にWebアプリケーションやEJBアプリケーションなどを配備してアプリケーションを組み立てても構いません。さらには各アプリケーションを異なるサーバ上に配備することでアプリケーションを分散することができます。

アプリケーション・クライアント(Application Client)

Java EEアプリケーション・クライアントはクライアントコンテナ上で動作するアプリケーションです。アプリケーション・クライアントはRMI-IIOP経由でEJB等のサーバサイドアプリケーションにアクセスします。

リソースアダプタ(Resource Adapter)

リソースアダプタアーカイブにはリソースアダプタを格納します。リソースアダプタとは、EJBやWebアプリケーションが外部のエンタープライズシステムにアクセスできるようにするためのコンポーネントです。

OSGiバンドル (OSGi Bundle)

OSGiアライアンスが定める仕様に沿って作成されたJarファイルです。 OSGiバンドルの中でサービスを定義する事で、他のアプリケーションからそのサービスを利用する事ができます。

CORBAアプリケーション(CORBA Application)

OMGが標準化を行っているCORBAという仕様に準拠したアプリケーションです。Javaだけではなく、C/C++やCOBOLで実装することもできます。CORBAアプリケーションの形式にはR5形式とR4形式が存在します([ アプリケーション開発ガイド（CORBA） ] 参照)。

共有コンポーネント(Shared Component)

プロセスグループ間で共有するライブラリです。

3.8.2. 配備

作成したアプリケーションをWebOTX AS 上で動作させるためには、アプリケーションをWebOTX AS に配備する必要があります。配備は運用管理コマンドや統合運用管理ツールを用いて行うことができます。詳細は [ ドメイン構築・基本設定ガイド > 5. アプリケーション ] を参照してください。

3.8.3. 分散配備

分散管理サーバの分散配備サービスでは、様々な組み合わせのアプリケーションを一括して配備することができます。また、配備操作は、複数のドメインに対して並行して実行することができますので、コマンドを順番に実行するのと比較して、配備時間を大幅に短縮することができます。詳細については、[ ドメイン構築・基本設定ガイド > 7.7. 分散管理サーバ ] を参照してください。

配備の基本機能

配備対象としては、次のコンポーネントをサポートします。

Java EEアプリケーション (EAR)
EJBコンポーネント (JAR)
Webコンポーネント (WAR)
リソースアダプタ (RAR)
アプリケーション・クライアントコンポーネント (JAR)
ESB SA (ZIP)
CORBAアプリケーション (CPK)
共有コンポーネント (SPK)
設定ファイル (properties)

これらに対して、distribute(配備)やstart(開始)、deploy(配備と開始)、stop(停止)、undeploy(停止と配備解除)、replace(置換と開始)を行うための機能を提供します。
WebOTX固有の配備記述子を含まないアプリケーションを配備するためのデプロイメントプラン(配備記述子からなるjarファイル)は、コンポーネントリポジトリのその他のコンポーネントとして登録した上で、そのコンポーネントIDを配備対象のコンポーネントの付属情報として設定してください。

配備結果の確認機能

統合運用管理ツールから配備操作を実行した場合、要求はすぐに完了し、実際の配備操作は非同期に行われます。そのため、現在の配備状況を確認するための操作を提供しています。配備結果は、xml形式で指定された数分保存しておくこともできます。
これに対して、統合運用管理コマンドから配備操作を実行した場合は、配備操作が完了するまでコマンドが終了しません。そのため、配備完了が前提の運用操作等を、独自に待ち合わせ処理を行うことなく続けて実行することができます。

以下に配備結果のXMLファイルの一部（例）を示します。ファイルは、${INSTANCE_ROOT}/ddeploy/resultディレクトリに出力されます。


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<DDDeployInformation>
 <ID>DDInvoke-20100330160257272</ID>
 <DomainGroupName>domain1</DomainGroupName>
 <Operation>DEPLOY</Operation>
 :
 <Status>DONE</Status>
 <Message>The operation normal end.</Message>
 <Options>
 :
 </Options>
 <DDDomainInformation>
  <Name>domain1</Name>
  <Host>apserver.local</Host>
  <Port>6212</Port>
  :
  <Status>DONE</Status>
  <Message></Message>
  <DDComponentInformation>
   <Name>tpwar61.ear</Name>
   <ID>test.ear</ID>
   <Type>JAVAEE</Type>
    :
   <Status>DONE</Status>
   <Detail>NONE</Detail>
   <Message></Message>
   <Dependencies>
    :

ファイル中に、<Status></Status>で囲まれたものが操作の結果を表します。結果は、配備操作全体、ドメイン、コンポーネントそれぞれにあり、以下の表に示すものがあります。

表3.8.3-1
結果	意味	説明
NONE	未処理（初期値）	まだ配備操作を実施していない場合
RUNNING	処理中	配備操作の実行中
DONE	正常終了	正常に配備操作が終了した場合
ERROR	エラー終了	エラー発生により終了した場合
WARNING	警告終了	一部失敗した処理がある場合
TIMEOUT	タイムアウト	処理がタイムアウトした場合処理中であったコンポーネントに対する実際の処理は継続されている可能性があります。配備先サーバのログ等から状況を確認してください。
CANCELING	配備中止処理中	配備中止処理中
CANCELED	配備中止完了	配備中止処理が完了した場合
IGNORE	処理なし	動作モードがRECOVERYで既に配備済みの場合配備済みや配備解除済み等で処理を行う必要がない場合
RESERVED	自動配備待ち	ドメイン起動時の自動配備予約対象となった場合

様々な配備制御機能

配備操作をなるべく継続するため、あるいは、逆に異常を検出してすぐに配備を中断するための様々な制御機能を提供しています。

配備制御モード

通常（normal:配備操作の既定動作）、リカバリ（recovery）、厳密（strict）、強制（force）の４つがあります。

表3.8.3-2
モード	制御の内容
normal	配備解除時に配備対象コンポーネントが存在しない場合など、操作と状況が一致しない場合、警告が発生します。ただし、設定ファイルの場合、MOや属性が見つからないことによる例外は無視します。
recovery	配備失敗後の再配備とみなして既に配備済みの場合に配備操作をスキップします。ただし、設定ファイルの場合は、normalの場合と同じ動作となります。
force	すでに配備済みのコンポーネントも強制的に再配備します。何らかの例外が発生した場合も処理を続行します。
strict	配備時に何らかの警告や例外が発生した場合、エラーとして扱います。

障害が発生した場合の動作
配備操作でエラーが発生した際に、次のコンポーネントの配備を継続して実行するか、配備操作全てを停止するかを指定することができます。
構成に差異がある場合の動作
配備対象サーバが存在しないなどの構成の差異があった場合に、その対象サーバを飛ばして配備操作を継続するかどうかを指定することができます。
配備時閉塞オプション
分散配備での配備処理中、自動閉塞するかどうかを指定することができます。閉塞する場合、配備操作の前後で配備対象の制御ドメインに登録されているLB制御コマンド(削除・追加)を呼び出します。
配備操作前の停止
CORBAアプリケーション、共有ライブラリの配備操作前に、配備対象のアプリケーショングループ、プロセスグループを停止するかどうかを指定することができます。
ドメイン起動時の自動配備オプション
配備先ドメインが正常停止している場合に、ドメインが起動した際、自動的に配備操作を行うかどうかを指定することができます。
配備の中止
現在実行中のコンポーネントの配備までで配備操作を中止するための操作を提供しています。
配備操作の再実行
配備結果をもとに、配備操作に失敗したコンポーネントのみを再実行します。

3.9. アプリケーション開発

業務システムの構築において益々重要度が高くなっている要素の一つとして、短期間開発、があります。市場の変化が激しい現在において、業務システムを市場や企業戦略に合わせてスピーディに変更・強化していくことが望まれます。

WebOTX では、サーバアプリケーションの開発言語としてJava、C/C++、COBOL、Holon を使うことができ、クライアントアプリケーションの開発言語としてJava、Visual Basic、C/C++、COBOL、Holon を使うことができます。これらの開発言語は、業務への適性とアプリケーション開発者の得手・不得手から考えて最適なものを選択することができます。それぞれの言語で使用する統合開発環境(IDE)製品は、プラットフォームに依存して最適なものを選択できます。

現在WebOTX では、Java 言語の開発はWebOTX Developer’s Studio を、Visual Basic やC/C++の開発ではMicrosoft 社のVisual Studio を推奨しており、これらIDE 上で容易にWebOTX 上のアプリケーションを開発できるようにするプラグインを提供しています。COBOL はOpen COBOL Factory 21 を、Holon はHolonEnterprise を使うことで、統合された開発を行うことができます。

WebOTX では、オブジェクト指向などの新技術に対する開発者の負担を下げるために、各種開発支援ツールを提供しています。Rich クライアント・アプリケーションを自動生成するクライアントAP やFlash 通信ライブラリ、Thin クライアント用のプレゼンテーションロジックを生成するWebAP、各種コネクタを自動生成するコネクタ開発環境を提供します。データベースアクセスについては、Persistent State Service や Enterprise JavaBeans のEntity Bean を使うことでWebOTX が自動的に行い、開発者はビジネスロジックに専念することができます。

3.9.1. WebOTX Developerとは

WebOTX V9 は高い生産性と保守性を持つ統合開発環境を提供します。デファクトスタンダードな統合開発環境Eclipse をベースに、NEC で独自に開発したJava EE 6 対応アプリケーション開発機能としてWeb アプリケーション開発環境や、Web サービス開発環境、EJB 開発環境、OLF/TP アダプタ開発環境を提供します。ソース編集機能やCVS による版管理、JUnit によるテスト環境、WebOTX のテスト用サーバなどを兼ね備えており生産性を向上させることができます。

アプリケーション開発ガイド（概要）

3.9.1.1. Developer ’s Studioとは

[ アプリケーション開発ガイド（概要） > 1. Developer(with Developer's Studio) ]

3.10. プロファイル

3.10.1. 概要

Java EEは、バージョンが上がるにつれて機能が追加され、仕様が肥大化していきました。 Java EE 6では軽量化の一環として、仕様のサブセットを「プロファイル」という考え方で提供しています。 Java EE 6の標準仕様では、Java EEの全ての機能をサポートする「フル・プロファイル」と、Webサイト構築に特化した「Webプロファイル」という、2つのプロファイルを定義しています。さらに、WebOTX ASではWebサーバのみを実行する最小構成を提供する「Webサーバ・プロファイル」を提供しています。また、WebOTX ASでは、プロファイルをカスタマイズし、ユーザ独自のプロファイルを作成することもできます。

なお、CORBAのプロセスグループについては、Java EEの環境ではないためプロファイルの適用対象外です。

3.10.2. 標準で提供するプロファイル

WebOTX ASでは、「フル・プロファイル」、「Webプロファイル」、「Webサーバ・プロファイル」の3つのプロファイルを標準で提供しています。各プロファイルの詳細を以下の表に示します。

表3.10.2-1
プロファイル名	説明
フルプロファイル (full-profile)	このプロファイルは、Java EE 6のすべての機能を提供します。 Webサイトの構築から基幹システムの構築まで、あらゆるシステムに適用可能です。
Webプロファイル (web-profile)	このプロファイルは、Webサイトを構築するために必要な機能を提供します。リモートのEJBやWebサービス等の実行環境は省かれており、その分軽量化されています。
Webサーバプロファイル (web-server-profile)	Webサーバのみを起動する最軽量プロファイルです。 WebOTXの管理機能からWebサーバの起動や停止等の運用操作を行うことが可能です。

3.10.3. プロファイルのカスタマイズ

統合運用管理ツールを利用することで、ユーザ独自のプロファイルを作成して実行環境に適用することができます。プロファイルを構成する機能は「フィーチャ」と呼ばれ、自由に取り付けや取り外しが可能です。