C++ CORBA C++ CORBA
C++ CORBA カートリッジ・アプリケーション カートリッジ・アプリケーション カートリッジ・アプリケーション カートリッジ・アプリケーション
C++ CORBAカートリッジは、C++プログラム言語で分散オブジェクト指向の業務アプリ
ケーションを構築するためのコンポーネント・アーキテクチャを定義します。このカート リッジは、アプリケーション開発における開発、配布および実行時の局面に対応します。
C++ CORBAカートリッジにより、アプリケーション開発者は、容易にアプリケーションを
作成できます。このカートリッジのランタイムにより、開発者はトランザクション、マルチ スレッド、リソース・プールなど、低レベルの詳細に関わる必要がありません。
C++ CORBAカートリッジは、実行時にC++ CORBAカートリッジ・コンテナによって作成
および管理されます。このコンテナはOracle Application Serverによって提供されます。タ イムアウト値や状態など、カートリッジの設定は、アプリケーションの配布時にカスタマイ ズされます。C++カートリッジのインプリメント方法やクライアントに提供する機能に関わ らず、カートリッジの一貫したビューがクライアントに提供されます。
C++アプリケーションは1つ以上のC++カートリッジで構成されます。通常、C++カート リッジはC++アプリケーションの業務ロジックを提供します。このカートリッジでは、ク ライアントから実行して処理を行うことができるメソッドを定義します。
共通アプリケーション・プログラミング・モデル 共通アプリケーション・プログラミング・モデル 共通アプリケーション・プログラミング・モデル 共通アプリケーション・プログラミング・モデル
Oracle Application Serverのアーキテクチャは、アプリケーション設計の3つの基本的なア
プローチに適しています。
■ リクエスト・レスポンス・モデル
■ セッション・モデル
■ トランザクション・モデル
アプリケーションを設定する際、インストールするカートリッジまたはECO/Java/EJBコン ポーネントのタイプを知っておくと便利です。カートリッジまたはコンポーネントをインプ リメントする開発者は、前述のどのアプローチがアプリケーションに適しているかを理解し ている必要があります。
リクエスト・レスポンス・モデル リクエスト・レスポンス・モデル リクエスト・レスポンス・モデル リクエスト・レスポンス・モデル
リクエスト・レスポンス・モデルを使用するアプリケーションは、各クライアントのリクエ ストに個別に応答します。アプリケーションが要求されたコンテンツを返した後、クライア ントやリクエストに関するデータはすべて失われます。状態を保持しないという点で、通常 のHTTPリクエストと一貫性があります。
通常、このモデルのアプリケーションはリクエストを識別し、要求された内容を返送し、状 態を保存せずにリターンします。たとえば、HTMLページのリクエストはリクエスト・レス ポンス・モデルです。
セッション・モデル セッション・モデル セッション・モデル セッション・モデル
Oracle Application Serverのセッション・モデルを使用するアプリケーションは、クライア
ントとアプリケーションの特定のカートリッジ・インスタンスとの間の継続的な結合を維持 します。同じクライアントから発行される後続のリクエストは、同じカートリッジ・インス タンスによって処理されます。セッションは、アプリケーションのアイドル状態がタイムア ウト時間（設定可能）になるまで、またはアプリケーションが結合を解除するまで継続され ます。
このモデルのアプリケーションは、クライアントに関する状態データをアプリケーションの コンテキスト構造体に保存します。セッション・メカニズムによって、クライアントとカー トリッジ・インスタンス間の結合が保証されるため、アプリケーションは、単一のクライア ントと対話しているかのように動作します。たとえば、ユーザー・アプリケーションのコン
る場合、このようなカウンタは、カートリッジ・サーバー内のすべてのカートリッジ・イン スタンスによって共有されます。
たとえば、個人情報の入力および更新ができる人事管理アプリケーションを開発している場 合、アプリケーションのセッションを使用してユーザー・データを維持できます。ユーザー が別のページへ移動しても、カートリッジ・インスタンスはそれまでにユーザーが入力した データを表示できます。カートリッジ・インスタンスには1人のユーザーのデータのみ含ま れます。
トランザクション・モデル トランザクション・モデル トランザクション・モデル トランザクション・モデル
ユーザーが製品を購買できるアプリケーションには、通常トランザクション・モデルを使用 します。ユーザーが製品の支払いを行う際に、支払システムと出荷システムの間でトランザ クション・サービスが使用されます。トランザクションは、両方のシステムからリクエスト が承認されたときのみコミットされます。どちらか一方または両方のシステムがリクエスト を拒否した場合、トランザクションは中止されます。
通常、このモデルのアプリケーションは、複数のHTTPリクエストにまたがるデータベー ス・トランザクションを実行します。これらのアプリケーションは、トランザクション・
サービスAPIを使用します。これは、Oracle Application ServerのEnterprise Editionでの み使用可能です。トランザクション・サービスAPIの詳細は、第11章「トランザクション を使用可能にする」を参照してください。
トランザクション・アプリケーションは、リクエストを受け取ると、そのリクエストがトラ ンザクションの開始用であるかどうかを確認します。リクエストがトランザクションの開始 用であれば、トランザクションが開始され、そのトランザクションのコンテキスト内で後続 のリクエストが実行されます。トランザクションをいつコミットまたはロールバックするか は、アプリケーションによって決定されます。
注意 注意注意
注意: リクエスト・レスポンス・モデルとセッション・モデルのどちら を使用しても、クライアント・データをカートリッジ・インスタンスのア プリケーション・コンテキスト構造体に保存できます。ただし、リクエス ト・レスポンス・モデルの場合は、同じクライアントが発行する次のリク エストが別のカートリッジ・インスタンスによって処理されることもある ため、これを行う意味はありません。
注意 注意注意
注意: トランザクション・モデルのアプリケーションは、リクエスト・
レスポンスの場合もセッション指向の場合もあります。クライアントから のリクエストを、同じカートリッジ・インスタンスに指示する必要はあり ません。
アプリケーションへのリクエストのトレース アプリケーションへのリクエストのトレース アプリケーションへのリクエストのトレース アプリケーションへのリクエストのトレース
Oracle Application Serverは、Webブラウザ・クライアントからのHTTPリクエストと、
CORBAクライアントからのCORBA/IIOPリクエストの両方を、クライアントのORB経由
で処理します。
HTTP HTTP HTTP
HTTP リクエスト リクエスト リクエスト リクエスト
図7-2は、Webブラウザ・クライアントがサーバー側のアプリケーションにHTTPリクエス トを発行したときのイベントの順序を示しています。
ディスパッチャは、使用可能なカートリッジ・インスタンスのキャッシュを管理します。 特 定のカートリッジに対するリクエストを受信すると、ディスパッチャはキャッシュに入って いる該当するタイプのカートリッジ・インスタンスの1つにそのリクエストをルーティング します（使用可能なカートリッジ・インスタンスの数の制約については9-16ページの
「チューニング・パラメータの設定」を参照してください）。
図 図図
図7-2 HTTPリクエストのライフ・サイクルリクエストのライフ・サイクルリクエストのライフ・サイクルリクエストのライフ・サイクル
カートリッジ・サーバー HTTPリクエスト
レスポンス
リクエスト レスポンス ブラウザ
ディスパッチャ ディスパッチャ ディスパッチャ ディスパッチャ リスナー
リスナー リスナー リスナー
カートリッジの インスタンス
Oracle Application Server