3. 提供機能

3.1. 概要

3.1.1. 提供機能一覧

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

表3.1.1-1
カテゴリ機能名称ExpressStandardEnterprise
WebサーバHTTP 1.0/1.1
SSL 2.0/3.0、TLS 1.0/1.1/1.2○(*1)○(*1)○(*1)
WebサービスSOAP 1.1/1.2
WSDL 1.1
WS-Security 1.1
WS-SecurityPolicy 1.2
WS-ReliableMessaging 1.2
Java SEJDBC 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 EEEJB 3.1
Servlet 3.0/JSP 2.2
JSTL 1.2
JSF 2.1
JMS 1.1
JPA 2.0
JTA 1.1
JAXR 1.0
JavaMail 1.4/JAF 1.1
JCA 1.6△(*2)△(*2)△(*2)
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
CORBACORBA 2.3/3.0(一部)△(*3)△(*3)
Event サービス△(*3)△(*3)
名前サービス△(*3)△(*3)
インタオペラブル名前サービス△(*3)△(*3)
Transaction サービス△(*3)△(*3)
XMLXML 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 ベースの管理ツール○(*4)○(*4)○(*4)
バッチを含めた自動運転
診断情報採取
システム構成情報のエクスポート・インポート
分散システム運用の仮想化××
アプリケーションの分散配備、一括配備××
システム構成情報の一括設定××
システム構成情報の差異検出××
イベント通知の集約××
負荷分散ラウンドロビン×
重み付けラウンドロビン××
動的負荷分散××
フェイルオーバスタンバイ
高速スタンバイ××
性能計測性能分析用API×
ログアナライザ×
配備可能なコンポーネントJava EE
CORBA Java××
CORBA C++××
COBOL×××(*5)
連携機構既存システム連携△(*6)△(*6)△(*6)
印刷機構帳票印刷×○(*7)○(*7)
ディレクトリサービスLDAP サーバ○(*8)○(*8)○(*8)
SOAJBI 1.0○(*9)○(*9)○(*9)

*1: TLS 1.1/1.2 を利用する場合は、インストール時に WebOTX Webサーバ 2.4 を選択する必要があります。

*2: ACOS VIS と連携する場合にはWebOTX OLF/TP アダプタを別途購入する必要があります。WebOTX OLF/TP アダプタをご利用になる場合は、別途お問い合わせください。

*3: CORBAサーバアプリケーションをWebOTX上に配備して実行する場合は、Enterpriseを購入する必要があります。
Express、StandardもCORBA通信基盤とCORBAサービスを提供していますが、CORBAサーバアプリケーションを動作させることはできません。

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

*5: Open COBOL Factory 21 を別途購入する必要があります。CORBA C++ コンポーネントとして配備できます。

*6: WebOTX VIS Connector もしくはWebOTX OLF/TP Adapter を別途購入する必要があります。WebOTX VIS ConnectorはEnterpriseでのみ利用可能です。WebOTX OLF/TP アダプタおよび、WebOTX VIS Connectorをご利用になる場合は、別途お問い合わせください。

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

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

*9: WebOTX Enterprise Service Bus を別途購入する必要があります。

3.1.2. Javaランタイム

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

3.1.2.1. Java SE Development Kit

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

最新の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
図3.1.3.1-1

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 ではなく3.6.7. 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が提供するサービス群
サービス名称ExpressStandardEnterprise
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つ作成されます。 管理ドメインはそのホスト上で動作するユーザドメインの管理を行います。 管理ドメインを通して以下の操作を行うことができます。

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

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

図3.1.5.3-1
図3.1.5.3-1

3.1.5.4. ドメインの構成

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

Expressドメイン

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

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

図3.1.5.4-1
図3.1.5.4-1

Standard/Enterpriseドメイン

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

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

図3.1.5.4-2
図3.1.5.4-2

Webサーバドメイン

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

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

図3.1.5.4-3
図3.1.5.4-3

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

図3.1.5.4-4
図3.1.5.4-4

APサーバドメイン

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

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

負荷分散構成:

図3.1.5.4-5
図3.1.5.4-5

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

図3.1.5.4-6
図3.1.5.4-6

相互スタンバイ構成:

図3.1.5.4-7
図3.1.5.4-7

マルチシステム構成:

図3.1.5.4-8
図3.1.5.4-8

名前サーバドメイン

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

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

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.31/2.4.16 をバンドルしています。Secure Socket Layer (SSL) 2.0/3.0 およびTransport Layer Security (TLS) 1.0/1.1/1.2 をサポートしており、インターネットを使った安全な通信を提供します。 他にも次に示すWeb サーバを利用することができます。

表3.2.1-1
Web サーバWindowsHP-UXLinux
Microsoft InternetInformation Server (IIS)7.0, 7.5, 8.0 - -
Apache HTTP Server2.2.29/2.4.10 以上 2.2.29/2.4.10 以上2.2.29/2.4.10 以上

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/2.4 をバンドルしています。これらはインストール時の 指定により選択することができます。(インストール時のデフォルトはJava ベースの HTTP サーバです。) これらのHTTP サーバはSSL 2.0/3.0 および TLS 1.0/1.1/1.2 をサポート(TLS 1.1/1.2 は Apache HTTP Server 2.4 でサポート)しており、インターネットを使った安全な通信を提供します。

他にも次に示す 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.29/2.4.10以上 2.2.29/2.4.10以上 2.2.29/2.4.10以上

3.2.2. Webコンテナ

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

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

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 では URL 単位の閉塞・閉塞解除機能を提供しています。 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/2.4
Apache HTTP Server 2.2/2.4
Microsoft Internet Information Services
(IIS)
- - -
アドバンスドモード
(IIOP)
WebOTX Webサーバ 2.2/2.4
Apache HTTP Server 2.2/2.4
アドバンスドモード
(AJP)
WebOTX Webサーバ 2.2/2.4
Apache HTTP Server 2.2/2.4
Microsoft Internet Information Services
(IIS)
- - -

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

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 のトランザクション処理過程を最適化するために、メソッドごとに別の属性を与えることができます。

トランザクションサービス自身に関する詳細機能は、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
図3.3.1.4-1

Standard/Enterprise のEJB コンテナ

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

図3.3.1.4-2
図3.3.1.4-2

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

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

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

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

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 をサポートしています。

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

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 Beanhomeステートレス
remoteステートレス
ステートフルSession Beanhomeステートレス
remoteステートフル
Entity Beanhomeステートレス
remoteステートフル
メッセージ・ドリブンBean-ステートレス
シングルトンSession Beanhomeステートレス
remoteステートレス

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

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

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

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

図3.4.2.2-1
図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種類をサポートしています。

表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をサポートしています。

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.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
図3.4.2.11-1

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

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

ポートの設定

WebOTXのIIOPリスナでは、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
図3.4.3.2-1

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

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

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

3.4.3.3. キュー制御

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

図3.4.3.3-1
図3.4.3.3-1

3.4.3.4. 多重実行

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

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

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

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

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以降では、障害解析で原因究明を行ないやすくするために、起動時ログを通常時のログと分けて出力します。

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

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

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

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

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

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

異常終了プロセス再起動

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

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

図3.4.4.2-1
図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
図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
図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
図3.5.1.2-1

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
図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.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 仕様に準拠し、下記のセキュリティトークンをサポートしています。

アプリケーション開発方法の詳細については[ アプリケーション開発ガイド(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
図3.6.2.2-1

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

図3.6.2.2-2
図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-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 サーバのリファレンスを取得します。

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

図3.6.2.3-3
図3.6.2.3-3

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

図3.6.2.3-4
図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 データソースでは、次のとおり、プール管理するコネクションの数を指定することができます。

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

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

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

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

接続契機

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

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

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

切断契機

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

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する時だけでなく、 6.3.1.5. JDBCデータソースへの設定変更内容の反映を実行することでも実際の動作へ反映することができます。

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

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

また、JDBC データソースでは、JDBC 3.0 以降のOracle のJDBC ドライバを利 用する場合に、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 コネクションの接続などの運用操作を実行することができます。また、 データベースの動的スケールアウトやスケールインへの対応では、6.3.1.5. JDBCデータソースへの設定変更内容の反映でClusterPoolNamesなどの設定を動的に変更することができます。

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

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

データベース

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

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

JDBC ドライバ

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

その他の製品についても、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 などのトランザクションをサポートしないストレージエンジンでは、自動コミットが行われるため、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)に対応しましたが、次の様な制限があります。

  1. 使用できるストレージエンジンは InnoDB だけです。
  2. 1 トランザクションあたり、1 コネクションしか使用できません。
  3. 同一コネクション内で、グローバルトランザクションとローカルトランザクションの切り替えを行うことができません。
  4. データベースサーバの再起動や通信障害が発生した場合、実行中のトランザクションはすべてロールバックされます。そのため、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 などの、2フェーズコミットをサポートしていて実際に運用実績のあるRDBMS を利用するべきです。そのため、次のようなシステムで利用することを推奨します。

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
図3.6.4.1-1

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

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

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

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

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

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

JMS クライアントでの滞留抑止
コネクションレベルでの制御

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

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

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

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

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

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

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

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

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

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

Queue の場合

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

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

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

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

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

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 コネクションとどのように対応づけるかを管理モデルとして選択できます。

コネクションサービスは、サービスタイプとプロトコルタイプ別に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 サーバとの接続を定期的にチェックする機能を提供しています。この機能はデフォルトで動作しますが、監視間隔は変更することができます。

3.6.4.12. JMSサーバクラスタ

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

例えば、

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

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

図3.6.4.12-1
図3.6.4.12-1

図3.6.4.12-2
図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-1

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

図3.6.4.13-2
図3.6.4.13-2

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

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

3.6.4.17. メッセージ移動機能

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

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

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

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

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

図3.6.4.17-1
図3.6.4.17-1

不達メッセージの移動

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

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

図3.6.4.17-2
図3.6.4.17-2

図3.6.4.17-3
図3.6.4.17-3

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

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

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

図3.6.4.17-4
図3.6.4.17-4

図3.6.4.17-5
図3.6.4.17-5

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

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

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

図3.6.4.18-1
図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 を利用したアプリケーションの開発は通常次の手順で行われます。

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

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
図3.6.7.7-1

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

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

図3.6.7.7-2
図3.6.7.7-2

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

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

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

図3.6.7.7-3
図3.6.7.7-3

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

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

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

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

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

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

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

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

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

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

図3.6.7.7-4
図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種類があります。

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

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

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

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

データベースのサポート

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

図3.6.7.7-5
図3.6.7.7-5

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

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

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

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

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

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
図3.6.7.11-1

ThreadPolicy

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

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

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

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

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

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

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

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

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

LifespanPoilcy

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

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

IdAssignmentPolicy

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

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

IdUniquenessPolicy

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

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

ServantRetentionPolicy

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

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

RequestProcessingPolicy

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

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

ImplicitActivationPolicy

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

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
図3.6.7.11-2

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

  1. POA マネージャ

    POA マネージャは、POA に対するクライアントからの要求の流れを制御する管理オブジェクトで す。4つの状態があり、POA マネージャに対するオペレーション、

    により状態が遷移します。

    図3.6.7.11-3
    図3.6.7.11-3

    デフォルトのPOA マネージャはrootPOA にあらかじめ関連付けられており、独自のPOA を生成 する際にPOA::create_POA()の引数にそのPOA マネージャを引き継ぐか、引き継がずに新 たなPOA マネージャを関連づけるかを選択することができます。POA マネージャを分けることに より、いくつかのPOA をグループ化して制御することができます。

  2. サーバントマネージャ

    サーバントマネージャとは、アプリケーション側でCORBA オブジェクトとサーバントの対応付けを 行うもので、サーバントアクティベータとサーバントロケータの2種類があります。 サーバントアクティベータを使用するには、以下の2つのポリシーが必須となります。

    クライアントから要求を受けると、まずAOM を検索し、見つからない場合にのみサーバントアクテ ィベータを呼び出します。サーバントアクティベータが対応するサーバントをPOA に返すと、AOM に登録されて以降の同じオブジェクトに対する要求のディスパッチはAOM の情報で解決されま す。サーバントアクティベータは、ServantActivator インタフェースで定義されている incarnate()とetherealize()を実装しなければなりません。

    一方、サーバントロケータを使用するには、以下の2つのポリシーが必須となります。

    AOM を使用しないため、クライアントからの要求ごとに呼び出され、サーバントをPOA に返しま す。サーバントロケータは、ServantLocator インタフェースで定義されているpreinvoke() とpostinvoke()を実装しなければなりません。

    サーバントアクティベータもサーバントロケータも、登録はPOA::set_servant_manager() で行います。

  3. デフォルトサーバント

    デフォルトサーバントとは、あるPOA のすべてのCORBA オブジェクトに対する要求をひとつのサ ーバントで処理する場合に使用します。この場合、以下の2つのポリシーが必須となります。

    ServantRetentionPolicy を変えることによって、全ての要求をデフォルトサーバントで処理する か、AOM にない場合にだけデフォルトサーバントで処理するかを選択できます。デフォルトサー バントの実装の中でCORBA オブジェクトに依存した処理を行うためには、呼び出しの延長で POACurrent オブジェクトをORB::resolve_initial_references("POACurrent")を 使用して取得します。そして、PortableServer::Current::get_object_id()で対応 するオブジェクトID を取得します。デフォルトサーバントの登録は、 Portable::POA::set_servant()で行います。

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

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

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

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

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

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

Dynamic Invocation Interface (DII)

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

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

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

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

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

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

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

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

Dynamic Skeleton Interface (DSI)

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

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

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

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 を使用することにより、次のことが可能になります。

例として、次のようなIDL 型を動的に扱う場合について説明します。

// IDL
struct MyStruct {
	long member1;
	boolean member2;
}

このような構造体(MyStruct)を動的に生成してany に格納するには、次のような手順で行います。

  1. ORB からファクトリ(DynAnyFactory)を取得します。
    ORB::resolve_initial_references("DynAnyFactory")
    
  2. この構造体に対応する TypeCode を生成します。
    ORB::create_struct_tc()
    
  3. DynAny を生成します。引数には2で生成したTypeCode を指定します。
    DynAnyFactory::create_dyn_any()
    
  4. DynStruct にnarrow します。
  5. 構造体のメンバ値を設定します。
    DynStruct::insert_long() // member1 の設定
    DynStruct::next() // 次のメンバへの位置付け
    DynStruct::insert_boolean() // member2 の設定
    
  6. any を生成します。
    DynStruct::to_any()
    

逆にany に格納されたMyStruct からmember2 の値を取り出すには、次のような手順で行います。

  1. ORB からファクトリ(DynAnyFactory)を取得します。
    ORB::resolve_initial_references("DynAnyFactory")
    
  2. DynAny を生成します。引数には対象とするany を指定します。
    DynAnyFactory::create_dyn_any()
    
  3. DynStruct にnarrow します。
  4. 構造体のメンバ値を取得します。
    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
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
CSIv2

また、開発言語と作成するアプリケーションの対応状況は次の表のとおりです。

表3.6.7.12-2
言語クライアントアプリケーションサーバアプリケーション
Java
C++
Visual Basic(*1)-
COBOL(*2)-
Holon(*3)

*1: CORBA ゲートウェイ,EJB ゲートウェイ(WebOTX Application Server Enterprise に添付) を使用

*2: Open COBOL Factory 21(別途購入要)を使用

*3: HolonEnterprise (別途購入要)を使用

3.6.8. ライフサイクルサービス

WebOTX ではドメイン内で動作する各種サービスをライフサイクル管理しています。ドメイン毎に動作さ せるライフサイクルサービスを選択することができます。

3.6.8.1. 提供するライフサイクルサービス

WebOTX では次のライフサイクルサービスを提供します。ただしエディションにより利用できないサービスがあります。

表3.6.8.1-1
サービス名称ExpressStandardEnterprise
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 に よって行うことができます。

3.6.9. インメモリデータグリッド連携

WebOTXはStandard以上の製品において、インメモリデータグリッド製品、Oracle CoherenceおよびInfinispanと連携し、 スケーラブルなシステムを容易に構築できる機能を備えています。

WebOTXとCoherenceを連携させるには、オプション製品であるCoherence for WebOTXが必要です。

WebOTX V9.2はInfinispan 6.0.2.Finalと連携可能です。InfinispanのWebサイトからダウンロードしてください。

3.6.9.1. 事前準備

Coherence

WebOTXをCoherenceと連携させるには、ドメイン起動前にCoherence for WebOTXのlibディレクトリ内の以下のJarファイルを${INSTALL_ROOT}/lib/extディレクトリにコピーしておく必要があります。

Infinispan

WebOTXをInfinispanと連携させるには、ドメイン起動前にInfinispanのlibディレクトリ内の以下のJarファイルを${INSTALL_ROOT}/modulesディレクトリにコピーしておく必要があります。

また、以下のJarファイルを${INSTALL_ROOT}/lib/extディレクトリにコピーしておく必要があります。

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つの個別設定が作成されており、これを指定することで簡単にデータグリッド連携を行なえます。

どちらも既定ではタイプが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.12. インメモリデータグリッド連携部品 ] を参照してください。

読み込む順序として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より公開されている仕様を参照してください。

WebOTXにおけるJMXの実装について説明します。

JMX仕様はJava言語によるネットワークマネージメントアーキテクチャで、 マルチサーバで構成されたシステムをリモートの運用管理アプリケーションから 一元的に運用管理するためのAPIやサービスを提供します。 WebOTXではJMXで規定された運用管理基盤を提供しています。

JMXのアーキテクチャ

JMXアーキテクチャは次の3レベルで構成されており、運用管理エージェントを通して運用管理クライアントから管理リソースを制御する仕組みとなっています。

図3.7.1-1
図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のマネージメントインタフェースは次の要素を提供します。

MBeanの属性およびオペレーションはJavaのpublicメソッドとして提供されます。 運用管理クライアントは管理対象リソースの運用管理を行うため、運用管理エージェントを通じてMBeanの属性を取得、 設定したり、オペレーションを実行したり、Notificationイベントを受信したりします。

MBeanのタイプ

JMXは4つのタイプのMBeanを規定しています。WebOTXでは全てのMBeanをModel MBeanとして提供しています。よって本書ではこれ以降MBeanと表現している箇所は全てModel MBeanとして扱います。

Notification

Notificationは運用管理クライアントにリソースの状態やコンフィグレーションが変更されたことを通知するために利用します。

運用管理クライアントはリスナーを該当リソースのMBeanに登録します。 MBeanは登録しているリスナーに対して1度のみイベントの通知を行ないます。 JMXの仕様ではNotificationモデルはMBeanと同じJVMにあるAgent間の通知について規定しており、 リモートプロセスへの通知についてはサポートしていませんが、 JMX Remote APIでリモートへの通知をサポートしておりWebOTXでもリモートプロセスへの通知を実装しています。

以下にJMXで規定されているNotificationインタフェースについて説明します。

Model MBeanのポリシー

Model MBeanはリソース管理を容易に行えるようにするためさまざまなポリシーが規定されています。なおMBeanのポリシーの詳細については [ 3.7.4.2. ポリシー ] を参照ください。

MBeanインタフェース

WebOTXの提供するMBeanはModelMBeanインタフェースを実装しています。ModelMBeanインタフェースは管理リソースをコントロールするためのインタフェースについて規定しています。以下にその概要を示します。

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が提供するインタフェースは、以下のような操作を提供します。

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

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の運用管理エージェントでもサポートしています。

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. システム管理ツール ] を参照ください。

WebOTXでは運用管理を行うため、次のクライアントを提供しています。これ以外にも運用管理APIを利用して独自にカスタマイズした運用管理クライアントを作成することが可能です。

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つのコネクタについて規定しています。

WebOTXでは以下のコネクタを提供しています。

運用管理エージェントへの接続

コネクタを利用して運用管理エージェントに接続する方式について説明します。JMX Remote APIでは次の方式について規定しています。

コネクタを利用してWebOTX内の運用管理エージェントに接続する場合は、次のJMXServiceURLを使用します。

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
図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を一意に決定するためのプロパティとその値を示す文字列です。

例)

Memo
Java EE仕様ではMOの種別を表すプロパティとしてj2eeTypeを用いますが、WebOTXが提供するMOの一部はtypeプロパティを用いています。
必須属性

MOとして必ず持たなければならない属性がJava EE Management仕様により規定されています。MOがどのような特性をもつのかを表します。 これらの属性は J2EEManagedObject インタフェースで規定されており、MOは必ずこのインタフェースを実装しなければなりません。

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インタフェースおよびそのサブインタフェースは、パフォーマンスデータを供給するのに必要なアクセサを規定します。以下のインタフェースが規定されています。

Statsインタフェース

Statsインタフェースおよびそのサブインタフェースは、おのおの指定されたMOのためのパフォーマンスデータのアクセサを規定します。 各Statsインタフェースは提供するパフォーマンスデータを適切なStatisticインタフェースとして提供します。 Java EE Managementとして以下のインタフェースが規定されています。なお、WebOTXでは以下に加え独自の統計情報を取得するためのStatsインタフェースを拡張しています。 拡張したインタフェースについては [ ドメイン構築・基本設定ガイド > 9. モニタリング ] を参照してください。


3.7.3.4. イベント

Java EE Management では、イベント通知の実装についてはJMX のNotification モデルで実装することを規 定しています。WebOTX でもJMX およびJMX Remote API のNotification モデルをサポートします。以 下にWebOTX が標準的に提供するイベントの概要について示します。


3.7.4. WebOTX Model MBean

WebOTX では、全ての管理リソースはJMX で規定されているModel MBean として定義しています。これ により次の操作をJMX インタフェースで行うことが可能です。

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の属性の特性に応じて設定します。

表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 サーバを利用することができます。

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を設定します。こ うすることで、状態監視では、常に1つのJDBC コネクションを使いまわすことになり、初期プールサイズ が指定されているJDBC データソースを利用する場合でも不要なリソース消費を回避します。

3.7.8.2. Working Domain Coordinator

クライアントからの一時的なアクセス増が予想されるような場合、最大限の負荷を想定してサーバの増 設を行うとコストがかかってしまいます。この問題を解決するために、限られた資源を有効活用し、高負 荷時にも安定した業務アプリケーションの運用を可能とする機能をWorking Domain Coordinator は提供 します。

Working Domain Coordinator は、負荷分散装置の利用を前提として構築された複数のサーバを効率よく 利用するために、業務アプリケーションの負荷に応じて、処理を行うサーバの数を調節します。WebOTX AS 上で動作する業務アプリケーションそれぞれの負荷を監視し、負荷の低い業務アプリケーションのド メインを負荷の高い業務アプリケーションのドメインに切り替え、負荷分散装置に対して振り分け先の設 定を行います。

図3.7.8.2-1
図3.7.8.2-1

上図のような構成の場合、Working Domain Coordinator への設定の流れは次のようになります。

  1. ビジネスロジックグループの登録
    業務A、業務B をそれぞれビジネスロジックグループとして登録します。

  2. ビジネスロジックの登録
    ビジネスロジックグループ配下に、監視の対象となるプロセスグループ名をビジネスロジックとして 登録します。

  3. 制御対象サーバの登録
    サーバ1、サーバ2、サーバ3をそれぞれ制御対象サーバとして登録します。

  4. 制御対象ドメインの登録
    各サーバのドメインを、各サーバ配下に制御対象ドメインとして登録します。この制御対象ドメイン に、1.で登録したビジネスロジックグループ名を登録します。サーバ1のドメインであれば業務A の ビジネスロジックグループ名を登録します。

このように、監視制御のための様々な設定を行うためのビジネスロジックグループと、制御対象ドメイン を分けて登録することで、新規のサーバ(ドメイン)を登録する際に、ビジネスロジックグループ名を指定 するだけで済むようになっています。

設定内容の詳細については、[ リファレンス集 運用管理・設定編 > コンフィグレーション(設定一覧) > 1.13. Working Domain Coordinator ]、または、[ 高度な管理と運用サイクルガイド > 2.チューニング > 2.10. Working Domain Coordinator ]を参照してください。

負荷監視機能

Working Domain Coordinator は、通常時、一定間隔で負荷監視対象の業務アプリケーションが動作する プロセスグループのキュー滞留数を監視します。定期監視中、キュー滞留数上限値を超える負荷を検 出した場合、高負荷時の監視設定に切り替え、負荷状態の継続性を判定するため、監視を続けます。 高負荷時の監視では、高負荷時監視間隔で、設定されたサンプリング回数分、キュー滞留数の採取を 行います。サンプリングの結果、そのうちの何割がキュー滞留数上限値を超えているかを算定し、この 割合が負荷超過率を超えていた場合、継続的な高負荷状態であると判断し、その高負荷業務アプリケ ーションと処理に対して余力のある低負荷業務アプリケーションの切り替えを行います。

図3.7.8.2-2
図3.7.8.2-2

業務アプリケーションの稼動時間や優先度に応じて、監視条件の設定値を調整することで、より正確に 高負荷を検出することが可能となります。

また、定期監視で得られた負荷情報は、高負荷業務アプリケーションと低負荷業務アプリケーションの 切り替え時の基準値として利用されます。

ビジネスロジックの切り替え機能

負荷監視機能により、継続的な高負荷状態を検出すると、高負荷業務アプリケーションを処理するサー バを増やすための切り替え処理を行います。切り替え処理は、業務アプリケーションに対する処理に余 力のあるサーバをひとつ選び、そのサーバ内で稼動するドメインを停止させ、継続的な高負荷状態にあ る業務アプリケーションのドメイン起動を行います。低負荷業務アプリケーションは、負荷監視機能の定 期監視で得られた負荷情報をもとに選択されます。また、各業務アプリケーションに設定された優先度 に応じて切り替え対象の選択を調整することができます。以下の項目を業務アプリケーション毎に設定 することが可能です。

高負荷業務アプリケーションが検出されても、切り替えの対象となる低負荷の業務アプリケーションが 存在しない場合は、業務アプリケーションの切り替えは行われません。

負荷分散制御装置(LB)の制御機能

Working Domain Coordinator は、高負荷業務アプリケーションと低負荷業務アプリケーションの切り替え を行う際、起動および、停止するドメインのLB への振り分け先の制御を行う機能を提供します。多種多 様なLB に対応するため、LB の振り分け先設定の制御タイプを3タイプ設けています。以下に各制御モ ードを説明します。

(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 は、次のいずれかです。

制御対象サーバのメンテナンス支援機能

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.7.9. 診断サービス

WebOTX には、ドメインの診断サービスという機能があります。これは障害が起きた場合に、障害解析 に必要な情報を収集して、ひとつのアーカイブファイルにまとめる機能です。問い合わせ窓口に問い合 わせる際には、診断機能を実行してアーカイブファイルを作成し、これを送付することで、調査部隊に必 要な情報を送付することができます。

また、診断サービスには、スローダウン障害対策機能、およびメモリ不足障害対策機能があります。 これらは、APサーバ内での障害の発生または発生の予兆を独自の方法で判断・分析し、それを契機に、 業務プロセスでのリクエストの処理量を制御してサーバの負荷を軽減するためのフェイルセーフ処理を 実施します。 また、障害が発生した際にはスレッドダンプやヒープダンプなど、障害解析に有益となる情報を自動で 採取します。
これらの機能により、システム障害の発生に伴う被害を最小限に留めます。

3.7.9.1. 収集情報の種類

診断サービスで収集される情報は以下のような種類があります。

なお、収集される情報の詳細については、「診断サービス」を参照してください。

以降では、診断サービスの概要について説明します。

3.7.9.2. 診断サービスとは

診断サービスとは、アプリケーションサーバに障害が起きたときに、障害解析に必要な情報を収集する機能です。収集する情報は、アプリケーションサーバのログや、OSの種類やバージョン、JVMのスレッドダンプなど様々なものがあります。 WebOTXの診断サービスには、リモートモードとローカルモードという2つのモードが存在します。下の図は、2つのモードについて簡単に表したものです。


図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. スローダウン障害対策機能

スローダウンが継続的に発生する状況を検出した際に、業務リクエストに対する応答を一定時間遅らせるとともに、動作スレッド数を一定の割合で抑制することで、業務が動作するプロセスにかかる負荷の抑制、および、処理時間の改善を図ります。状況が改善できなければプロセスを異常終了させることでスローダウン障害からの復旧を行います。

詳細は[ ドメイン構築・基本設定ガイド > 10. 診断サービス > 10.4. 障害対策機能 > 10.4.1. スローダウン障害対策機能 ] を参照してください。

3.7.9.4. メモリ不足障害対策機能

OutOfMemoryError の発生やメモリ使用量が非常に多い状況を検出した際に、業務リクエストに対する応答を一定時間遅らせるとともに、動作スレッド数を一定の割合で抑制することで、業務が動作するプロセスのメモリ使用量の抑制、および、処理時間の改善を図ります。状況が改善できなければプロセスを異常終了させることでメモリ不足障害からの復旧を行います。

詳細は[ ドメイン構築・基本設定ガイド > 10. 診断サービス > 10.4. 障害対策機能 > 10.4.2. メモリ不足障害対策機能 ] を参照してください。

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 の稼働状況を評価するための性能及び統計情報を各種レポートとして以下の項目について採取します。

3.7.12.3. イベントジャーナル

イベントジャーナルは個々のオペレーション処理に関して処理の流れを詳細に採取します。システムの詳細な性能分析をすること が可能になります。以下にイベントジャーナルの主な採取ポイントを以下に示します。

図3.7.12.3-1
図3.7.12.3-1

表3.7.12.3-1
コンポーネント 番号 採取ポイント
通信リスナ
(IIOPリスナ、AJPリスナ)
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(1〜Long.MAX_VALUE)
レコードタイプ「P」 固定(Profile)
I/Oメソッド開始時:I
メソッド終了時:O
API名"クラス名#メソッド名" の形式で出力
エンティティ名エンティティ名(完全修飾名)
エンティティIDエンティティID
クエリクエリ名 or JPQL or SQL
表3.7.12.5-42 メッセージ(例外情報)出力項目
名前説明
NOシーケンスNo(1〜Long.MAX_VALUE)
レコードタイプ「E」 固定(Exception)
API名"クラス名#メソッド名" の形式で出力
エンティティ名エンティティ名(完全修飾名)
エンティティIDエンティティ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. 分散管理サーバ ] を参照してください。

配備の基本機能

配備対象としては、次のコンポーネントをサポートします。

これらに対して、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 自動配備待ち ドメイン起動時の自動配備予約対象となった場合


様々な配備制御機能

配備操作をなるべく継続するため、あるいは、逆に異常を検出してすぐに配備を中断するための様々な制御機能を提供しています。


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

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. プロファイルのカスタマイズ

統合運用管理ツールを利用することで、ユーザ独自のプロファイルを作成して実行環境に適用することができます。 プロファイルを構成する機能は「フィーチャ」と呼ばれ、自由に取り付けや取り外しが可能です。

3.11. インストール/アンインストール

3.11.1. Windows版

Windows版のWebOTX製品は、新旧の複数バージョンのインストールと、同一バージョンの複数位置へのインストールは行えません。
既に旧バージョンのWebOTXか本バージョンのWebOTXがインストールされている場合は、WebOTXのサービス群を停止した後にアンインストールを行なってください。
操作手順については、ご利用になっているバージョンのマニュアルをご参照ください。

また、各 WebOTX 製品のインストールにおいて、既に他の WebOTX 製品がインストールされている場合、「インストール先フォルダ」には同じフォルダを指定してください。

3.11.1.1. 通常インストール

ウィザード画面に従い、インストールに必要な項目を入力しながらインストールすることを通常インストールと呼びます。

通常インストールを行う場合は、ランチャ(wo_setup.exe)からインストールを実行してください。
詳細は、[セットアップガイド > 2. インストール > 2.2.1. Windows] を参照してください。

3.11.1.2. サイレントインストール

コマンドプロンプトから、インストールに必要なパラメータを引数に与え、インストールを行うことをサイレントインストールと呼びます。サイレントインストールを行うことで、バッチファイルや環境構築ツールからの自動インストールを行うことが可能です。

サイレントインストールの詳細は、[セットアップガイド > 2. インストール > 2.2.3.1. Windows] を参照してください。

3.11.1.3. ワンタッチインストール

ウィザードでに、ライセンスキーの入力だけ行い、インストール時のパラメータを全て既定値で インストールする場合は、ワンタッチインストールを行うことで作業の簡略化できます。 ワンタッチインストールに対応している製品は以下となります。

ワンタッチインストールを行う場合は、各製品のsetup.exeを直接起動してください。

3.11.1.4. Server Coreへのインストール

WebOTX Application ServerはServer Coreとして運用している環境にインストール可能です。 この場合は、Windowsにログイン後に表示されるコマンドプロンプトより、上記いずれかのインストール方法を 実行してください。

3.11.1.5. アンインストール

各 WebOTX 製品のアンインストールにおいて、複数のWebOTX製品が インストールされている環境から、一つの WebOTX 製品のみのアンインストールを実施する場合には 「定義情報の削除」オプションを選択しないでください。

3.11.2. UNIX版

3.11.2.1. 通常インストール

WebOTXの製品はインストールスクリプトを使用して、コマンド・ラインから対話的にインストールします。

WebOTX AS Express/Standard/Enterprise/Developer/Administrator/Client/マニュアルは、WebOTX MediaのDVD-ROMのマウント・ポイント・ディレクトリ直下にあるインストールスクリプト(WOINST.SH)を使用します。 詳細は、[セットアップガイド > 2. インストール]をご覧ください。

それ以外のオプション製品のインストールに関しては、各オプション製品のセットアップガイドを参照してください。

UNIX版の利用に際しては、次の点に留意してください

3.11.2.2. サイレントインストール

サイレントインストールを利用することにより、WebOTX製品を非対話的にインストールすることが可能です。 UNIX版のサイレントインストールでは、サイレントインストール用の設定ファイルをインストールスクリプト(WOINST.SH)に読み込ませて実行します。 インストールスクリプト(WOINST.SH)は、設定ファイルを作成/確認する機能及び設定ファイルの内容に従いインストールを実行する機能を提供します。

サイレントインストールの対象となる製品は以下の通りです。

詳細は、[セットアップガイド > 2. インストール > 2.2. インストール > 2.2.3. サイレントインストール > 2.2.3.2. HP-UX、Linux]をご覧ください。

サイレントインストールに関しては、次の点に留意してください

3.11.2.3. インストーラ圧縮ファイル

リモートでの作業などDVD媒体を使用できない場合、インストーラ圧縮ファイル(tar.gz形式)を利用してインストールすることが可能です。
インストーラ圧縮ファイルの作成は、WebOTX MediaのDVD-ROMのマウント・ポイント・ディレクトリ直下にあるインストーラ圧縮ファイル作成スクリプト(WOMKTGZ.SH)を使用して行います。 作成したインストーラ圧縮ファイルは対象マシンに転送して展開し、展開先のインストールスクリプト(WOINST.SH)を使用してインストールを行います。

インストーラ圧縮ファイルの作成が可能な製品は以下の通りです。

詳細は、[セットアップガイド > 2. インストール > 2.2. インストール > 2.2.2. HP-UX、Linux > 2.2.2.11. インストーラ圧縮ファイル]をご覧ください。

インストーラ圧縮ファイルに関しては、次の点に留意してください

3.11.2.4. アンインストール

WebOTX ASやAdministrator、Developerは複数のインストール・パッケージから構成されています。 そのため、WebOTX製品をアンインストールする際には、アンインストールスクリプト(wouinst.sh)を使用して全ての製品をアンインストールしてください。
※一部のオプション製品は専用のアンインストールスクリプトを提供しています。

詳細は、[セットアップガイド > 3. アンインストール]をご覧ください。
それ以外のオプション製品のインストールに関しては、各オプション製品のセットアップガイドを参照してください。

3.11.3. 複数バージョンインストール

3.11.3.1. 概要

WebOTX製品はV9.3からUNIX版において同一マシンへの複数バージョンインストールをサポートします。
また、V9.2まではWebOTX製品のインストール・ベースディレクトリ(※)は/opt固定でしたが、V9.3からインストール時に変更することが可能です。
※UNIX版のパッケージ(RPM/デポ)のインストール時に起点として使用するディレクトリ

製品バージョン(メジャーバージョンとマイナーバージョン)が異なる場合に複数バージョンのインストールが可能となります。
(例)WebOTX AS V9.2とWebOTX AS V9.3
※9.2と9.3が製品バージョンであり、製品の型番が異なります。

同一製品バージョンの同一マシンにおける複数位置へのインストールはサポートされません。
また、リリース時期により詳細バージョンが異なる場合もサポートされません。
(例)9.30.00.000と9.31.00.00
※詳細バージョンであり、製品の型番は同じです。

複数バージョンインストールをサポートするプラットフォームは以下の通りです。

※Windows(x86),Windows(x64)はサポートされません。

複数バージョンインストールに対応している製品は以下の通りです。 ※製品バージョンは省略

*1 サポートするプラットフォームと共存対象バージョンが異なります。詳細は WebOTX Enterprise Service Bus のマニュアルを参照してください。

上記製品とその他の製品を同じマシンに両方インストールする場合、インストール・ベースディレクトリは/optとする必要があります。
この場合、同一マシンに複数バージョンをインストールすることはできません。

また、上記製品のインストール・ベースディレクトリを"/opt"以外に変更する場合、上記に記載されている製品のみ追加インストールが可能です。
この場合、複数バージョンインストールに未対応の製品を追加インストールすることはできません。
 

本バージョンの複数バージョンインストールの共存対象バージョンは、2個前のメジャーバージョンかつ本バージョンが諸元としてサポートしているOSの範囲内です。

表3.11.3.1-1
プラットフォーム V6以前 V7 V8 V9 備考
HP-UX - Itanium 対象外 V7.1 V8.2-8.4 (*1) V9.2 (*1) *1 V8.1,V9.1はHP-UX(IPF)版の製品出荷はありません
Linux - Intel x86 対象外 対象外 V8.2-8.4 (*1) V9.1-9.2 *1 RHEL 5はV8.2以降でサポート
Linux - Intel 64 対象外 対象外 V8.2-8.5 (*1) V9.1-9.2 *1 RHEL 5はV8.2以降でサポート

本バージョンでインストール・ベースディレクトリとして/optを使用する場合、製品インストール後のディレクトリ構成はV9.2と同じになります。

本バージョンでインストール・ベースディレクトリとして/opt以外を使用する場合、製品インストール後のディレクトリ構成は以下のようになります。


複数バージョンインストールに関しては、次の点に留意してください

3.11.3.2. 互換シンボリックリンク管理スクリプト

UNIX版では複数バージョンインストールのサポートに伴い、インストール時に/usr/lib配下のシンボリックリンクの作成を行わなくなりました。
そのため、Transactionサービスなどの旧互換ライブラリ等で必要となるシンボリックリンクを作成/削除する機能を互換シンボリックリンク管理スクリプト(MNGCMPSL.SH)にて提供しています。
互換シンボリックリンク管理スクリプトの詳細は、[セットアップガイド > 2. インストール > 2.3. インストール後の作業 > 2.3.9. 互換シンボリックリンクについて]をご覧ください。

互換シンボリックリンク管理スクリプト利用に際しては、次の点に留意してください。

3.11.3.3. Web版統合運用管理コンソール


3.11.3.4. Object Broker

バンドル製品(Application ServerやDeveloperなど)の場合
複数バージョンインストールに対応しています。
V9.2までの既存製品との動作上の競合を避けるために、次のような変更を行っています。
利用に際しては、次の点に留意してください。

【サービス】
起動シェルスクリプトの名前をバージョン識別子が付与されたものに変更しました。
直接実行する場合は、必ず当該バージョンのものを使用してください。
V9.2まで V9.3の場合
ObjectSpinner ObjectSpinner113





【コマンド】
Object Brokerが提供しているコマンドのシェルスクリプト版を作成しました。
Object Brokerの運用操作を行う場合、必ずシェルスクリプト版(拡張子"sh")を使用してください。
コマンド シェルスクリプト版
instif instif.sh
listif listif.sh
rmif rmif.sh
cnscom cnscom.sh
chconf chconf.sh
convndf convndf.sh
ospistop ospistop.sh
i2j i2j.sh












※コマンドは、<インストール・ベースディレクトリ>/ObjectSpinner/binに格納されています。
従来のコマンドを実行すると、次のような影響があります。

【C++アプリケーション】
ライブラリへのシンボリックリンクが作成されないため、次のような影響があります。 ビルドでは、Object Brokerのライブラリが格納された次のディレクトリを、LD_LIBRARY_PATH環境変数に指定するか、ロードパスを指定するビルドオプションに指定してください。
<インストール・ベースディレクトリ>/ObjectSpinner/namespace/lib



実行については、ドメイン内で動作するアプリケーションについては、特に留意する点はありません。
ドメイン外で動作するアプリケーションについては、次の対応が必要です。
既定のインストールディレクトリ(/opt)以外にインストールした場合、互換ライブラリをリンクしたアプリケーションは動作できません。

【Javaアプリケーション】
インストール・ベースディレクトリを/opt(デフォルト)から変更する場合、CLASSPATH環境変数やアプリケーションのビルド・実行時に指定するObject Broker Javaのライブラリへのパスを次のように修正してください。
<インストール・ベースディレクトリ>/WebOTX/modules/wo-orb110.jar
<インストール・ベースディレクトリ>/WebOTX/modules/omgorb110.jar
<インストール・ベースディレクトリ>/WebOTX/modules/jsocks.jar




関連製品Object Broker C++/JavaTMの場合
関連製品Object Broker C++/Javaは、複数バージョンインストールに対応していません。
基本的に従来どおりの利用が可能ですが、次の点に留意してください。

【サービス】
起動シェルスクリプトの名前をバージョン識別子が付与されたものに変更しました。
直接実行する場合、必ず当該バージョンのものを使用してください。
V9.2まで V9.3の場合
ObjectSpinner ObjectSpinner113




3.11.3.5. JMS

3.11.3.6. Transactionサービス

V9.2までの既存製品との動作上の競合を避けるため、Transactionsサービスのライブラリを指すシンボリックリンクをOS標準のライブラリロードパス(/usr/lib等)に作成しません。

C++アプリケーションの利用に際しては、次の点に留意してください。Javaアプリケーションに関しては、特に留意する点はありません。


【C++アプリケーション】
ライブラリへのシンボリックリンクが作成されないため、次のような影響があります。
単一バージョンインストール環境の場合、および、複数バージョンインストール環境の場合で 本バージョンのTransactionsサービスのライブラリでコンパイル、実行を行う場合には、 インストール完了後に互換シンボリックリンク管理スクリプト(MNGCMPSL.SH)を使用してライブラリ へのシンボリックリンクを作成してください。
互換シンボリックリンク管理スクリプトの詳細は、[セットアップガイド > 2. インストール > 2.3. インストール後の作業 > 2.3.9. 互換シンボリックリンクについて]をご覧ください。

コンパイル時、Object Brokerのライブラリに関する設定が必要です。詳細は[ 3.11.3.4. Object Broker-【C++アプリケーション】]をご覧ください。

実行については、ドメイン内で動作するアプリケーションについては、特に留意する点はありません。
ドメイン外で動作するアプリケーションについては、コンパイル時と同様、Object Brokerのライブラリに関する設定(詳細は[3.11.3.4. Object Broker-【C++アプリケーション】])と、さらに 次の対応が必要です。

3.11.3.7. TPモニタ


3.11.4. クラウド環境へのインストール

WebOTX は以下のクラウド環境での動作をサポートしております。下記以外のクラウド環境のサポートについては別途お問い合わせください。

3.11.4.1. NEC Cloud IaaS 環境へのインストール

NEC Cloud IaaS の環境へWebOTX をインストールする場合は、以下の点に留意ください。

3.11.4.2. Amazon Web Services 環境へのインストール

AWSの環境へ WebOTX ASをインストールする場合は、以下の点に留意ください。