3. アプリケーション設計

3. アプリケーション設計

本章では、WebOTXを使ったクライアントアプリケーション、およびサーバアプリケーションの設計について、パターンごとに説明しています。

3.1. システム構成

Transactionサービスを使ったトランザクションシステムの構成について説明します。 Transactionサービスは2フェーズコミットにより複数のデータベースを確実に更新するとともに、アプリケーション障害等に対してもトランザクションの更新/破棄を完全に行なうため堅牢なトランザクションシステムを構築することができます。次の図は、Transactionサービスを使ったトランザクションシステムにおけるプロセスの構成を示しています。

構成	説明
クライアントAP	クライアントシステム上に存在し、サーバアプリケーションの呼び出しを行うアプリケーションプログラムが動作するプロセスです。三層モデルのプレゼンテーション層に相当するアプリケーションプログラムであり、richクライアントやthinクライアントのServlet/JSPがこれに相当します。これらは利用者がC++言語やJava言語、VB言語で作成します。
サーバAP	APサーバ上に存在し、データベースの更新などトランザクション処理を実際に行うサーバオブジェクトが動作するプロセスです。三層モデルのファンクション層に相当しサーバオブジェクトは利用者がC++言語やJava言語で作成します。
Currentライブラリ	アプリケーション上に位置し、CORBAトランザクションサービスで規定されている Currentインタフェースや暗黙的な伝播を提供します。利用者は、クライアントアプリケーションやサーバアプリケーションで、このCurrentインタフェースを利用してトランザクションの開始や終了を行います。
Recovery Coordination Server (RCS)	トランザクションの異常発生時にリカバリ処理を行うプロセスです。サーバAPの障害を検出して自動的にリカバリを開始します。
ProxyRCS	クライアントアプリケーションで開始されたトランザクションの情報を管理します。richクライアントがトランザクションを実行する場合に使用します。
名前サービス	Object Brokerが提供しているサービスで、 CORBA で規定されている名前サービスを実装しています。クライアントアプリケーションはProxyRCSを使用する場合、名前サーバを使用します。名前サービスを動作させるコンピュータは、Object Brokerの設定で自由に決めることができます。
データベース	三層モデルのデータベース層に相当しアプリケーションが更新・参照を行うデータベースです。データベースには、Oracle、SQL Serverがあります。また、キュー制御にMQSeriesを利用できます。

3.1.1. サーバトランザクションの場合

サーバトランザクションの場合、トランザクションの処理を全てサーバAPで実行します。クライアントAPはサーバAPでトランザクションが実行されているかどうかを意識する必要がないため、プレゼンテーション部分の処理になります。そのため基本的な三層モデルのシステムではこの構成を使用します。

サーバAPが複数のデータベースを更新する場合にこの形態を使用します。この形態ではクライアントからの一回の呼び出しでトランザクションは実行され更新されます。そのためトランザクションは一箇所のサーバに集約されるため管理が容易になりますがトランザクションの処理が1つのコンピュータに集中するためクライアントの台数に応じてコンピュータのスペックを決定する必要があります。サーバオブジェクトがアクセスするデータベースはデータベースサーバ上にありますが、同じコンピュータ上にある場合もあります。

この場合サーバコンピュータにのみTransactionサービスをインストールを行ないます。

サーバトランザクション

上図ではクライアントAPは単にAPサーバ上のサーバオブジェクトを呼び出します。サーバオブジェクトはトランザクションを開始して複数のデータベースを更新した後にコミットを実行します。これらの処理はクライアントから一回の呼び出しで完了します。

「2.1.3. サーバトランザクションモデル」の図も参照してください。

3.1.2. クライアントトランザクションの場合

クライアントトランザクションの場合、新規トランザクションの生成処理はクライアントAPで行いますがトランザクションの情報はサーバ上のProxyRCSによって管理されます。そのためクライアント側にはRCSをインストールする必要がありません。この形態はVBやJava Applet等のrichクライアント側や、thinクライアントのWebコンテナやServlet/JSPで複数のサーバ上のAPをトランザクションとして呼び出す場合に使用します。

この形態の場合サーバ側にトランザクション状態が保存されるので、クライアントに障害が発生した場合データベースをロールバックし、データベースのロックを解除することができます。ただしProxyRCSが動作するサーバはクライアントトランザクションを全て処理するため、クライアントの台数に応じてスペックを決定する必要があります。

この場合クライアントコンピュータにはTransactionサービス実行環境(クライアント)をインストールする必要があります。

上図のクライアントAPは複数回サーバオブジェクトを呼び出し、コミットを実行します。

サーバオブジェクトがグローバルトランザクションに参加した場合はデータベースの更新を実施します。サーバAPが呼ばれると、クライアントで開始されたトランザクションにその処理を自動的に関連付けます。クライアントからトランザクションがコミットされると、このサーバオブジェクトで更新した内容がすべてコミットされます。

上図のクライアントAPでAPサーバ上のトランザクションを制御しています。実際にはトランザクションの開始、サーバオブジェクトに処理を要求、トランザクションのコミットを実施します。この場合サーバコンピュータに存在するProxyRCSとサーバAPのCurrentライブラリがトランザクションを制御します。サーバオブジェクトの動作は複数回呼び出す場合と同等です。

「2.1.4. クライアント制御トランザクションモデル」の図も参照してください。

3.1.3. 複合トランザクションの場合

複合トランザクションは、サーバトランザクションがバックエンドのサーバオブジェクトを呼び出す場合や、thinクライアントのケースでJ2EEサーバ上のWebコンテナがサーバオブジェクトを呼び出す場合など多段に呼び出された複数のAPサーバ間でトランザクションを共有します。
サーバオブジェクトで新規トランザクションが生成され、サーバトランザクションの場合と同様にトランザクションの情報がバックエンドのサーバに伝達されトランザクションの更新に連動してバックエンドサーバも更新されます。

トランザクションはトランザクションを開始したアプリケーションのみが管理を行いバックエンドのサーバAPはクライアントトランザクションの場合と同様にトランザクションとしての動作Policyを決定するだけです。

この形態ではデータベースを更新する各APサーバ上にTransactionサービスをインストールする必要があります。

上図のサーバオブジェクト１でトランザクションを制御しています。実際にはトランザクションの開始、サーバオブジェクト２に処理を要求、トランザクションのコミットを実施します。この場合図中の2つのAPサーバの間でトランザクションが共有され、同時に2フェーズコミットが実行されます。

この形態では両方のAPサーバにRCSが存在するため、トランザクションが未完了、あるいは既に2フェーズ目において相手のAPサーバがダウンした場合でもトランザクションを完了することができます。

「2.1.5. 複合形態モデル」の図も参照してください。

3.2. リカバリサーバが必要なシステム構成

Transactionサービスではトランザクションサービスを実現するにあたりRCSを利用します。大部分のケースではRCSでトランザクションを処理することができますが、以下のケースを実現する場合リカバリサーバを使用する必要があります。

3.2.1. 他社OTS製品と接続する場合

RCSを利用することにより従来のリカバリサーバを利用したケースより大幅に性能向上しますが、他社OTS製品とトランザクション連携を行なうことができません。このようなケースではリカバリサーバを使用する必要があります。
この詳細については、他社OTS製品との相互接続についてを参照してください。

3.2.2. ネスティッドトランザクションを使用する場合

ネスティッドトランザクションを使用する必要がある場合はリカバリサーバを使用する必要があります。この場合はトランザクションに参加するAPサーバ全てにリカバリをインストールする必要があります。

上図ではサーバクライアントでトランザクションを開始して、サーバオブジェクトでネスティッドトランザクションを開始します。
サーバでコミットを実行するとデータベース２は更新されず、クライアントで実行されたトランザクションに登録されます。
クライアントのコミットに同期してデータベース２の内容は更新されます。クライアントがロールバックした場合はデータベース２の変更も破棄されます。

3.3. システム構築時の注意

Transactionサービスを利用する最大の利点は、2フェーズコミットメントをサポートしている点です。そのため、複数のデータベースを同期を取って更新する場合にそれらの一貫性を保証します。

データを最適配置したシステムを簡単に作成したい場合に、Transactionサービスは非常に強力なツールになります。システムダウンや通信障害などが発生しても、Transactionサービスがデータベースの一貫性を障害発生時点の状況に合わせて、ネットワーク全体でデータベースをロールバックまたはコミットしますので、データベースの状態は完全な状態(一貫した状態)が維持されます。アプリケーションはほとんど障害に対する処理を考えなくても、簡単にシステムが構築できます。

このネットワーク全体での一貫性を提供しているのが2フェーズコミットの機能です。トランザクションの結果(コミットまたはロールバック)をハードディスク内のファイルに記憶することで、その後の障害に対して耐久性を提供しています。ただ、次のようなシステムの場合にTransactionサービスの機能を適用せずに、ローカルトランザクションとして管理したほうが良い結果となる場合があります。

全てのデータ更新が1つのデータベースに限定されるシステム
Transactionサービスは、単一データベース資源の場合には1フェーズコミットメントを使用しますが、オーバヘッドがTransactionサービスを使わない時に比べて、無視できないレベルで存在します。これはTransactionサービスがCORBAトランザクションサービス仕様に完全に準拠していることによります。1フェーズコミットメントを使用し、かつ高い性能を期待するなら、Transactionサービス無しのほうが有利です。
データベースの特定レコードへアクセスが集中するシステム
2フェーズコミットメントを使うと、障害が発生した場合、業務を再開するまでに時間がかかる場合があります。これは障害発生時点でのデータベース状態をネットワークで一貫した状態にする必要があり、トランザクションの結果を即時に入手できるか保証されないからです。そのため、特定レコードの更新ができるまでシステム全体が止まってしまう可能性があります。
Transactionサービスを適用する場合、銀行業務のように各トランザクションが要求するレコードが分散している形態か、信頼性の高いサーバでTransactionサービスを起動しシステム全体の停止時間を最小にするような設計が必要になります。
データベース障害に対する耐久性を重視するシステム
基幹業務などで使われるマスタデータベースで、データベース障害に対する復旧を全セーブあるいは全リストアなどで行うと、Transactionサービスが管理しているトランザクションの結果でコミットやロールバックしても、データベース側はそれらの情報を保存していないためにトランザクションの結果に矛盾が生じてしまい、ヒューリスティック障害(人為的障害)となります。
これは、分散データベースを利用する場合、Transactionサービスの導入に関係無く問題になりますが、このような障害が発生した場合にネットワーク分散されたデータベースの状態を一貫性のある状態に復帰させるのが難しくなります。すなわち、1つのデータベースはリストアされた時点の状態になり、1つのデータベースはセーブ時点以降動作した正常トランザクション分だけ更新されてしまうというケースが発生するからです。アプリケーションのレベルで個別のデータベースに対する復旧処理を行う必要があります。
一般に、多少のデータベース障害は目をつぶってもう一度データを入れ直す、運用は夜中に停止して複数のデータベースを同期してセーブする、データベース障害時点ではセーブ時点から再開すれば良いなどという、人事管理システムなどのデータベースのようにデータベース障害が業務に致命的でない場合にTransactionサービスを導入するとアプリケーションの設計、製造は非常に簡単で、かつ安全なシステムになります。システム障害、ネットワーク障害、アプリケーションアボートなどのアプリケーション障害に対する後処理はすべてTransactionサービスが行うからです。

またTransactionサービスでは、ACOS Access Toolkit(AAT)が提供するJDBCドライバと連携するための「1フェーズコミット対応リソース」を実装しており、それを使用することで、2フェーズコミットメントに対応していないACOS上のトランザクションをWebOTXシステムの2フェーズコミットトランザクションに参加できる機能を提供しています。つまり同一のトランザクションで、ACOS上のデータベースとオープンサーバ上のデータベース(Oracleなど)の同時更新を管理することができます。

ただし、本来であれば1フェーズコミットメントでの動作を前提としているものを、いわば無理やり2フェーズコミットトランザクションに参加させているため、トランザクション完了処理の際にヒューリスティックとなる可能性が高くなります。つまりトランザクション全体をコミットしていいのかロールバックしていいのかTransactionサービス(トランザクションマネージャ)で判断がつかなくなる状態となります。

トランザクションのコミット時には、まず2フェーズコミットメントに対応しているリソース群に対して第1段階(プリペア)が行われ、それが正常に完了したら、ACOS側データベースに対してAATが提供するJDBCドライバを経由してコミット要求を発行します。これの結果に従ってトランザクション全体をコミットするかロールバックするかの判断をするわけですが、例えばACOSとの通信障害などによりこれが失敗すると上述のような状態に陥ります。1フェーズコミットメントが前提のリソースに対して、プリペアが実施されずにいきなりコミット要求が発行されることによる弊害です。

通信障害が発生していたとしてもACOS上のデータ更新は正常にコミットされて完了しているかもしれません。その場合はトランザクション全体をコミットする必要があります。逆に、処理要求自体がACOS側に到達していない可能性もあります。その場合はトランザクション全体をロールバックして更新を無効にしてあげなければなりません。

最終的にはACOS上のデータベースの更新状況をログなどで判断した後に、WebOTXが提供する統合運用管理ツール、あるいは運用管理コマンドにより強制的にトランザクションを完了させる必要があります。

流れなどの詳細については運用編(運用操作)に記述していますのでそちらをご参照ください。