(57)【要約】【課題】  パーソナライズされた分析を提供し、フレキシブルなリスク報告を提供し、資産クラス統合を提供し、ポートフォリオ集約を提供し、より安い操作コストを提供し、およびより速い実施を提供するネットワーク・ベースのポートフォリオ管理およびリスク分析ための方法および装置を提供すること。【解決手段】  本発明は、リスク・モデルおよびデータを有し、安全なウェブ・ベースの、対話型のプラットフォーム上に提供され、これによって、ユーザは、複数の資産クラスおよび市場をカバーするカスタマイズされたリスク分析およびレポートを構築することができる。本発明は、更に、ユーザの投資プロセスを最も反映する次元に沿って資産を構成し、かつ分類し、想定されるリスクを決定し、リスクのソースを決定し、ポートフォリオのリスク・エクスポージャを見ることを可能にし、ボラティリティのソースを識別し、かつ定量化し、最新式のリスク報告を提供し、および取引シナリオユーティリティを提供する。
2006516166.tif 000002
【特許請求の範囲】
【請求項１】
ポートフォリオ管理およびリスク分析のための装置であって：
リスク・モデルであって：
カスタマイズされたリスク分析およびレポートを構築し、複数の資産クラスおよび市場をカバーすること；
ユーザの投資プロセスを最も反映する次元に沿って資産を構成し、かつ分類すること；
仮定されるリスクを決定すること；
リスクのソースを決定すること；
ポートフォリオのリスク・エクスポージャを見ること；
ボラティリティのソースを識別し、かつ定量化すること；
リスク報告を提供すること；および
取引シナリオユーティリティを提供することの少なくとも1つのためのメカニズムを有するリスク・モデル；
データベース；および
一時データ記憶、プロセス調整、同期状態管理、および概念上のスペースに存在する一組のオブジェクトを有する通知のための安全な、ウェブ・ベースの、対話型の、N層の、共有オブジェクト・フレームワークを有する装置。
【請求項２】
当該N層フレームワークの各層が、それより上の任意の層へのサービスおよびインターフェースのプレゼンテーションを可能にするように、編成され；
上位層が、それの下の複数のレベルの層のサービスを利用することができ；および
下位層が、それより上の層の知識を有さない請求項1に記載の装置。
【請求項３】
当該N層フレームワークが、
ユーザ入力を集め、およびサーバ・レスポンスを与えるためのユーザ・エージェント(UA)層；
HTTPアプリケーション層(HAL)；
ビジネス・オブジェクト層(BOL)；
分析層(AL)；
インフラストラクチュア・サービス(IS)層；および
データ・アクセス(DA)層を有する請求項1に記載の装置。
【請求項４】
当該ユーザ・エージェント層が：
当該HTTPアプリケーション層を介して当該装置と通信するためのブラウザ・ベースのアプリケーションを有する請求項3に記載の装置。
【請求項５】
当該HTTPアプリケーション層が：
ウェブ-アプリケーション-サーバを有し、当該エージェント層リクエストの解釈および当該装置内の異なるサブシステムに対するワークのディスパッチングを実行するサーブレットを更に有する請求項3に記載の装置。
【請求項６】
当該ビジネス・オブジェクト層が：
リクエストと関連しているテンプレートの一部として格納された複数のイベントをディスパッチし、かつ或る動作を実行するために当該ビジネス・オブジェクト層を呼び出すための手段を有する請求項3に記載の装置。
【請求項７】
当該分析層が、
当該ビジネス・オブジェクト層から呼び出しを受信し、かつ当該ビジネス・オブジェクト層に必要な計算を実行するために、ライブラリおよび分析の何れかを呼び出すための手段を有する請求項3に記載の装置。
【請求項８】
当該インフラストラクチュア・サービス層が：
リモート・メソッド分散、ロード・バランシング、バッチ・ジョブ管理の何れかを含む分散処理、およびデータ・アクセスおよびキャッシング・サービスを提供するための手段を有する請求項3に記載の装置。
【請求項９】
当該分析層が、
複数の分析エンジンを、更に有する請求項7に記載の装置。
【請求項１０】
当該分析層が、
処理が完了しているとき、当該分析エンジンの結果を同期させるための手段を、更に有する請求項9に記載の装置。
【請求項１１】
当該分析層が、
当該分析エンジンにおいて市況を同期させるための手段を、更に有する請求項9に記載の装置。
【請求項１２】
当該オブジェクトの使用を望むプロセスが、当該スペースからオブジェクトを取り出す、またはそれを除去することなくオブジェクト状態を読み取ることができ；
任意のプロセスが、当該スペースへオブジェクトを書き込むことができ；および
リーダのパターンにマッチングするオブジェクトが当該スペースに存在しない場合、プロセスは、オブジェクトが利用可能なとき、非同期的通知をブロック、または登録することができる請求項1に記載の装置。
【請求項１３】
当該分析層が、
任意の計算の一部として、当該計算がローカルに実行されることが必要であるか、またはそれがリモート・マシンに分散されなければならないかを決定する手段を有する請求項3に記載の装置。
【請求項１４】
当該分析層が、
全てのリスク計算に関するエントリポイントを提供するリスク計算器を有する請求項3に記載の装置。
【請求項１５】
当該分析層が、
現行の分析、履歴分析、リスク、最適化、および債券エクスポージャ計算の何れかを含むことが可能な基準に基づいて、特定化された複数の分析エンジンを有する分析ライブラリを有する請求項3に記載の装置。
【請求項１６】
当該分析層が、
計算のための必要な情報を得るために当該分析ライブラリにより使用されるインターフェースを有する複数の分析オブジェクトを有する請求項15に記載の装置。
【請求項１７】
当該分析層が、
リスク計算を実行するためのリスク分析を有する請求項15に記載の装置。
【請求項１８】
当該分析層が、
特定の手段に関する価格付けおよびエクスポージャ計算を実行するための手段分析を有する請求項15に記載の装置。
【請求項１９】
当該インフラストラクチュア・サービス層が：
周期的なタスク、並びに長期のタスクを調整し、およびリモートでジョブを予定に入れ、進行中または動作待機中のジョブをキャンセルし、およびジョブ・ステータスをチェックするためのジョブ・スケジューリングおよびメンテナンス機能；
完了するために2つ以上のリソースを必要とするタスクのため、および利用可能リソースを使用するロードを分散するための分散処理機能；
マスター・タスクを完了する、異なるサブタスクを調整するためのタスク調整機能；
ロード・バランシング機能；および
およびパーシステンス管理機能を有する請求項3に記載の装置。
【請求項２０】
当該データ・アクセス層が、
長期耐久性のパーシステンス；
共有された一時的なパーシステンス；および
キャッシングを有する請求項3に記載の装置。
【請求項２１】
ポートフォリオ管理およびリスク分析のための安全な、ウェブ・ベースの、対話型のフレームワークであって：
カスタマイズされたリスク分析およびレポートを構築し、複数の資産クラスおよび市場をカバーすること；
ユーザの投資プロセスを最も反映する次元に沿って資産を構成し、かつ分類すること；
仮定されるリスクを決定すること；
リスクのソースを決定すること；
ポートフォリオのリスク・エクスポージャを見ること；
ボラティリティのソースを識別し、かつ定量化すること；
リスク報告を提供すること；および
取引シナリオユーティリティを提供することの少なくとも1つのためのメカニズムを有するリスク・モデルを実施する分析層を有し；
当該分析層が、
任意の計算の一部として、当該計算がローカルに実行されることが必要であるか、またはそれがリモート・マシンに分散されなければならないかを決定する手段；
全てのリスク計算に関するエントリポイントを提供するリスク計算器；
現行の分析、履歴分析、リスク、最適化、および債券エクスポージャ計算の何れかを含むことが可能な基準に基づいて、特定化された複数の分析エンジンを有する分析ライブラリ；
計算のための必要な情報を得るために当該分析ライブラリにより使用されるインターフェースを有する複数の分析オブジェクト；および
特定の手段に関する価格付けおよびエクスポージャ計算を実行するための手段分析を有するフレームワーク。
【請求項２２】
当該フレームワークが、
一時データ記憶、プロセス調整、同期状態管理、および概念上のスペースに存在する一組のオブジェクトを有する通知のためのN層の、共有オブジェクト・フレームワークを有する請求項21に記載のフレームワーク。
【請求項２３】
ポートフォリオ管理およびリスク分析のためのN層フレームワークであって：
ユーザ入力を集め、およびサーバ・レスポンスを与えるためのユーザ・エージェント(UA)層；
HTTPアプリケーション層(HAL)；
ビジネス・オブジェクト層(BOL)；
分析層(AL)；
インフラストラクチュア・サービス(IS)層；および
データ・アクセス(DA)層を有するフレームワーク。
【請求項２４】
ポートフォリオ管理およびリスク分析のための方法であって：
カスタマイズされたリスク分析およびレポートを構築し、複数の資産クラスおよび市場をカバーすること；
ユーザの投資プロセスを最も反映する次元に沿って資産を構成し、かつ分類すること；
仮定されるリスクを決定すること；
リスクのソースを決定すること；
ポートフォリオのリスク・エクスポージャを見ること；
ボラティリティのソースを識別し、かつ定量化すること；
リスク報告を提供すること；および
取引シナリオユーティリティを提供することの少なくとも1つのためのメカニズムを有するリスク・モデルを提供するステップ；
データベースを提供するステップ；および
一時データ記憶、プロセス調整、同期状態管理、および概念上のスペースに存在する一組のオブジェクトを有する通知のための安全な、ウェブ・ベースの、対話型の、N層の、共有オブジェクト・フレームワークを提供するステップを有する方法。
【請求項２５】
フレームワークを提供する当該ステップが、
HTTPアプリケーション層を介して通信するためのブラウザ・ベースのアプリケーションを有するユーザ・エージェント層を提供するステップ；
ウェブ-アプリケーション-サーバを有し、当該エージェント層リクエストの解釈および当該フレームワーク内の異なるサブシステムに対するワークのディスパッチングを実行するサーブレットを更に有する当該HTTPアプリケーション層を提供するステップ；
リクエストと関連しているテンプレートの一部として格納された複数のイベントをディスパッチし、かつ或る動作を実行するために当該ビジネス・オブジェクト層を呼び出すためのビジネス・オブジェクト層を提供するステップ；
当該ビジネス・オブジェクト層から呼び出しを受信し、かつ当該ビジネス・オブジェクト層に必要な計算を実行するために、ライブラリおよび分析の何れかを呼び出すための分析層を提供するステップ；
リモート・メソッド分散、ロード・バランシング、バッチ・ジョブ管理の何れかを含む分散処理、およびデータ・アクセスおよびキャッシング・サービスのためのインフラストラクチュア・サービス層を提供するステップ；および
長期耐久性のパーシステンス；共有された一時的なパーシステンス；およびキャッシングを有するデータ・アクセス層を提供するステップを、更に有する請求項24に記載の方法。
【請求項２６】
分析層を提供する当該ステップが、
複数の分析エンジンを提供するステップ；
処理が完了しているとき、当該分析エンジンの結果を同期させるステップ；
当該分析エンジンにおいて市況に同期させるステップ；
任意の計算の一部として、当該計算がローカルに実行されることが必要であるか、またはそれがリモート・マシンに分散されなければならないかを決定するステップ；
全てのリスク計算に関するエントリポイントとしてリスク計算器を提供するステップ；
現行の分析、履歴分析、リスク、最適化、および債券エクスポージャ計算の何れかを含むことが可能な基準にに基づいて、特定化された複数の分析エンジンを有する分析ライブラリを提供するステップ；
計算のための必要な情報を得るために当該分析ライブラリにより使用されるインターフェースを有する複数の分析オブジェクトを提供するステップ；
リスク計算を実行するためのリスク分析を提供するステップ；および
特定の手段に関する価格付けおよびエクスポージャ計算を実行するための手段分析を提供するステップを、更に有する請求項25に記載の方法。
【請求項２７】
ポートフォリオ管理およびリスク分析のための方法であって：
カスタマイズされたリスク分析およびレポートを構築し、複数の資産クラスおよび市場をカバーすること；
ユーザの投資プロセスを最も反映する次元に沿って資産を構成し、かつ分類すること；
仮定されるリスクを決定すること；
リスクのソースを決定すること；
ポートフォリオのリスク・エクスポージャを見ること；
ボラティリティのソースを識別し、かつ定量化すること；
リスク報告を提供すること；および
取引シナリオユーティリティを提供することの少なくとも1つのためのメカニズムを有するリスク・モデルを提供するステップ；
データベースを提供するステップ；および
一時データ記憶、プロセス調整、同期状態管理、および概念上のスペースに存在する一組のオブジェクトを有する通知のための安全な、ウェブ・ベースの、対話型の、N層の、共有オブジェクト・フレームワークを提供するステップを有する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ウェブ・ホスト環境のインターネットの上のリスク分析のデリバリに関する。より詳しくは、本発明は、ネットワーク・ベースのポートフォリオ管理およびリスク分析のための方法および装置に関する。
【背景技術】
【０００２】
最新のポートフォリオ管理およびリスク分析ツールは、専用の、別々の投資家アプリケーションである。このように、一般的に、ユーザがインストールし、かつ維持しなければならない用途特化ソフトウェアの組合せがあり、したがって、ユーザ位置においてアプリケーション・インストールを遅くし、かつユーザ・サポートを難しくする。更に、このようなシステムにおいて、データおよびリスク・モデルは、単一のアプリケーションに統合されず、したがって、重大な統合課題を提示し、かつ潜在的投資およびリスク見通しを分かりにくくしている。
【０００３】
ユーザが彼の投資戦略を最も反映する次元に沿って彼のポートフォリオのリスク特性を調べることができるように、パーソナライズされた分析を提供するネットワーク・ベースのポートフォリオ管理およびリスク分析のための方法および装置を提供することは、有利であろう。このような場合、ユーザは、彼がそれを望んだ所で、リスクを適用し、および彼がそれを望まなかった所で、リスクを最小限に抑えることができるであろう。
【０００４】
調整され、自動化されたリスク報告のための簡単なポイントおよびクリック・コマンドを使用して、彼の会社、またはクライアントの要求事項を満たすために、ユーザが、リスクのビューをカスタマイズすることができるように、フレキシブルなリスク報告を提供するネットワーク・ベースのポートフォリオ管理およびリスク分析のための方法および装置を提供することは、更に、有利であろう。
【０００５】
ユーザが業界基準リスク・モデルおよびリスクの包括的なビューのための分析を使用して、エクイティ、債券、または両方のブレンドを管理することができるように、資産クラス統合を提供するネットワーク・ベースのポートフォリオ管理およびリスク分析のための方法および装置を提供することは、更に、有利であろう。
【０００６】
ユーザが、彼が選択するポートフォリオを何らかの方法で編成することができ、次に、集約の任意のレベルでリスクおよびその基礎をなすソースを見るためにロールアップまたはドリルダウンすることができるように、ポートフォリオ集約を提供するネットワーク・ベースのポートフォリオ管理およびリスク分析のための方法および装置を提供することは、更に、有利であろう。
【０００７】
ユーザがブラウザ・ベースの技術を使用することにより操作費用および技術課題を最小限に抑えることができるように、より安い操作コストを提供するネットワーク・ベースのポートフォリオ管理およびリスク分析のための方法および装置を提供することは、更に、有利であろう。
【０００８】
ユーザが、統合アプリケーション、モデルおよびデータによってシステムの実現時間およびデータ統合課題を減らすことができるように、より速い実施を提供するネットワーク・ベースのポートフォリオ管理およびリスク分析のための方法および装置を提供することは、更に、有利であろう。
【発明の開示】
【課題を解決するための手段】
【０００９】
典型的な業界をリードするリスク・モデルおよびデータを組み込んだネットワーク・ベースのポートフォリオ管理およびリスク分析のための方法および装置は、安全なウェブ・ベースの、対話型のプラットフォーム上に提供され、これによって、ユーザは、複数の資産クラスおよび市場をカバーするカスタマイズされたリスク分析およびレポートを構築することができる。この方法および装置は、更に、ユーザの投資プロセスを最も反映する次元に沿って資産を構成し、かつ分類することを可能にし、想定されるリスクを決定し、リスクのソースを決定し、ポートフォリオのリスク・エクスポージャを見ることを可能にし、ボラティリティのソースを識別し、かつ定量化し、最新式のリスク報告を提供し、および取引シナリオユーティリティを提供する。
【発明を実施するための最良の形態】
【００１０】
典型的な業界をリードするリスク・モデルおよびデータを組み込む、ネットワーク・ベースのポートフォリオ管理およびリスク分析のための方法および装置は、安全なウェブ・ベースの、対話型のプラットフォーム上に提供され、これによって、ユーザは、複数の資産クラスおよび市場をカバーするカスタマイズされたリスク分析およびレポートを構築することができる。この方法および装置は、更に、ユーザの投資プロセスを最も反映する次元に沿って資産を構成し、かつ分類することを可能にし、想定されるリスクを決定し、リスクのソースを決定し、ポートフォリオのリスク・エクスポージャを見ることを可能にし、ボラティリティのソースを識別し、かつ定量化し、最新式のリスク報告を提供し、および取引シナリオユーティリティを提供する。
【００１１】
用語集
次の用語集は、本明細書において議論と関連して提供される：
AI：分析インターフェース(Analytic Interfaces)。
【００１２】
分析エンジン(Analytic Engine)：さまざまな金融算出を実行する役割を果たすプロセス。
【００１３】
分析サーバ(Analytic Server)：第2物理層のマシン。
【００１４】
アプリケーション・サーバ(Application Serve)：HTTPリクエストを処理する第1物理層のマシン。
【００１５】
バインディング(Binding)：具体的なプロトコルおよびデータ・フォーマット仕様。例えば、EventのためのSOAPバインディングは、イベントオブジェクトがSOAPプロトコル・フォーマットで符号化されることを意味する。
【００１６】
BDT：デベロッパー・ツールキット(Developers Toolkit)。リスク分析および資産詳細を提供するインターフェース。BDTは、アプリケーションのためのインターフェースおよび分析を提供する。これは、外部クライアントにより同様に使用されることができるパブリックインターフェースである。
【００１７】
BOL：ビジネス・オブジェクト層(Business Object Layer)。
【００１８】
キャッシュ・フロー手段(Cash Flow Instrument)：その現在価値が公知の将来のキャッシュ・フローにより決定される金融手段。すなわち、エクイティおよびコンポジット以外のほとんどの手段。
【００１９】
計算エンジン(Computation Engin)：分析サーバ上で動作するプロセス（実際にRMIインフラストラクチュアの一部）。全てのBOLサーバサイド・コードは、このプロセスのアドレス空間で動作する。
【００２０】
CSS：カスケーディング・スタイルシートは、ウェブ・ドキュメントにスタイル（例えば、フォント、色、間隔）を加えるためのメカニズムである。
【００２１】
カスタム・タグ(Custom Tags)：カスタム・タグは、JSPページによる用途のための、カスタマイズされた、宣言型、およびモジュール式の機能性を定義するために、JSP技術により提供されるメカニズムである。
【００２２】
EJB：EJB(Enterprise JAVA(登録商標) Beans)は、J2EEアーキテクチャにおいて特定されるサーバサイドBeansを参照する。EJB サーバは、ウェブ・サーバと異なる。
【００２３】
イベント(Event)：ビジネス・オペレーションおよびその関連づけられた入出力データの抽象的な、類型に分けられた定義。具体的には、各BOLイベントは、BOL API関数にマップされる。2つのクラスのBOLイベント：状態‐変更イベントおよび状態-クエリイベントがある。HALに関して、イベントは、タイプ、オペレーション、およびおそらくコンテクスト情報である。イベントは、直列化されたオペレーションのためのグループに組み合わせられることができる。
【００２４】
イベント・バンドル(Event Bundle)：その順序が、処理の間、保存されなければならないイベントのシーケンス。
【００２５】
イベント、ディスパッチ(Event, Dispatch)：トランスポート・メカニズムを通してビジネス・オペレーションを呼び出すために、イベント手段をディスパッチすること。トランスポートの具体例は、負荷分散されたRMI、ソケット上のカスタムRPC、HTTP上のSOAP、リフレクション、JMS上のRPC等を含む。
【００２６】
Event HALコンセプト：HALにより操作されるHTTPリクエストの最も細分化された部分。イベントは、（通常）計算されたデータのリクエスト、またはデータベースまたはセション状態を変更するコマンドの何れかである。
【００２７】
Event Bundle HALコンセプト：全てが、1つのHTTPリクエストに属する一群のイベント（同じリクエストに、他のEvent Bundleが存在することも可能である）。あるBundle内に、必要とされる順序のEventが存在するかもしれない。
【００２８】
イベント定義(Event Definition)：HAL内、おそらくXMLでの、Eventの定義。BOLに関連するEvent Definitionの属性は：メソッド名前、引数定義（名前、データの型、オプショナリティ）、およびローカル対リモート・コンフィギュレーション・ディレクティブである。
【００２９】
ERTest：債券(Fixed Income)の価格およびエクスポージャのバッチ計算のために使用される、TRAMインフラストラクチュアの一部。
【００３０】
HAL：HTTPアプリケーション層。これは、ウェブ・サーバの次に存在し、かつクライアントからのリクエストを処理する層である。用語HALは、本明細書で説明されるFrameworkコンポーネントと交換可能に使用可能である。
【００３１】
ホスト実施(Hosted Implementation)：顧客のサイトに物理的に位置づけられるハードウェアを有するシステム構成。
【００３２】
GUI：グラフィカル・ユーザ・インターフェース。
【００３３】
JSP：JAVA(登録商標) Server Pagesは、ウェブ・クライアントのための動的コンテンツを生成するためにHTMLおよびJAVA(登録商標) Beansコードの混合を可能にする技術である。
【００３４】
名前空間(Namespace)：「URI参照により識別された名前空間とそれらを関連づけることによりXMLドキュメントにおいて使用される要素および属性名に資格を与える」ためのメソッド。
【００３５】
PSS：持続セッション状態(Persistent Session State)。
【００３６】
持続セッション状態(Persistent Session Stat)：BOLが、正常となるためにアクセスしなければならない、HTTPセッションに属する全てのデータのセット。
【００３７】
優先サーバ(Preferred Server)：RPC Infrastructureによりサポートされるセッションの属性。リクエストのための優先分析サーバは、そのセッションのための前のリクエストを処理したサーバである。
【００３８】
責任サーバ(Responsible Server)：それが評価される間のEvent Bundleの属性。Event Bundleのリモート部分を評価している分析サーバ。
【００３９】
RPCインフラストラクチュア(RPC Infrastructure)：リモートEventBundle呼び出しおよび進行モニタリングを管理する役割を果たす、インフラストラクチュア・グループに属しているサブシステム。
【００４０】
直列化／非直列化(Serialization/Deserialization)：本明細書において、直列化は、java.io.Serializableインターフェースの使用を必ずしも意味するわけではない−それは、また、java.io.Externalizableインターフェースまたは自家製のメカニズムの使用を意味する場合もありうる。
【００４１】
サーブレット(Servlet)：ブラウザにおけるユーザからの或る動作に応答して直接呼び出されることができるサーバサイド上のJAVA(登録商標)プログラム。
【００４２】
SOAP  シンプル・オブジェクトアクセス・プロトコル(Simple Object Access Protocol)は：XMLベースの軽量の通信プロトコルである。それは、2つのサブ・プロトコル：SOAP Envelope（アプリケーション層プロトコル）、およびSOAP Encoding（プレゼンテーション層プロトコル）を有する。SOAPは、元来、異種のネットワーク環境におけるRPC呼び出しをカプセル化し、かつ交換するために構想され、更に、HTTP拡張フレームワークも含む。
【００４３】
テンプレート（Template）  テンプレートは、アプリケーションモデルのビューである。その階層的、かつ高品質のXMLパーサが入手自由であるので、XMLは、バインディングとして選ばれる。
【００４４】
Stickiness：別名アフィニティ。同じセッションの前のリクエストを処理したマシンにリクエストを導こうとする或るメカニズム。
【００４５】
戦略(Strategy)：リスク計算の結果に影響を及ぼす全てのユーザ定義可能な設定の組合せ。
【００４６】
テンプレート：テンプレートは、特定のリクエストに基づいて共に異なるJSPページを組み立てる手段である。テンプレートは、異なるページに対する共通のレイアウトを共有するための、および同様に共通のJSPページを共有するためのメカニズムを提供する。
【００４７】
TSpaces：Lindaに基づくIBMからの共有オブジェクト製品。それは、プロセス間でオブジェクトを共有する能力を提供し、イベント通知を有するイン・メモリ共用データベースの働きをする。
【００４８】
ユーザ・エージェント(User Agent)：User Agentは、ブラウザまたはアプリケーションを使用する任意の他のフロントエンドを参照する。
【００４９】
ウェブ・サーバ(Web Server)：ブラウザから入って来るHTTPリクエストを解釈する役割を果たすプロセス。
【００５０】
XMLスキーマ(XML Schema)：XML Schema言語は、「XML 1.0ドキュメントの構造を説明し、およびコンテンツを限定するための機能を提供し、XML Namespace機能を利用するものを含む。それ自体XML 1.0で表され、かつ名前空間を使用するスキーマ言語は、実質的にXML 1.0文書型定義(DTD)において見つけ出された機能を再構成し、かつかなり拡張する。」言語は、構造仕様およびデータ型仕様から成り、およびDTDを置き換えるよう期待される。
【００５１】
XSL：「XSL(Extensible Stylesheet Language)は、スタイル集を示すための言語である。それは、3つの部分：XMLドキュメントを変換するための言語[XSLT]；フォーマッティング・セマンティクスを特定するためのXML語彙[XSL]およびドキュメントの部分に対処するための構文[XPath]から成る。XSLスタイル集は、クラスのインスタンスがフォーマッティング語彙を使用するXMLドキュメントに変換される方法を説明することにより、XMLドキュメントのクラスのプレゼンテーションを特定する。」−W3C
XSLT：XMLドキュメントを、他のXMLドキュメントまたは他のタイプのドキュメント、例えば、HTMLドキュメントに変換するための言語。[XSL]を参照。
【００５２】
XSL FO：[XSL] Formatting Objectsは、プレゼンテーション・デザイナーに利用可能な一組の印刷上の抽象概念である。[CSS]およびDSSSL (Document Style Semantics and Specification Language)に関するワークから引き出して、XSLは、印刷媒体およびスクロール可能なドキュメント・ウィンドウの両方のスタイルに対処しようとする。
【００５３】
ゾーニング(Zoning)：計算の特化。
【００５４】
表記法
次の名前空間プレフィックスが、スキーマ定義のために本明細書において使われる：
2006516166.tif 000003
【００５５】
アーキテクチャの概観
アーキテクチャは、2つのセクション：物理アーキテクチャ（図1を参照）および論理アーキテクチャ（図2を参照）において本明細書で述べられる。
物理アーキテクチャは、プロセスおよびワークが分散される方法に関係する。それは、また、各プロセス内に存在する論理パッケージのセットを含む。
論理アーキテクチャは、システムのコンポーネントを構成するサブシステムまたはパッケージに関する。コンポーネントは、複数のプロセスにおいて存在することができ、および他のパッケージにインターフェースを提示することができる。
【００５６】
パッケージの依存性は、識別され、および詳細な論議は続く。
本発明の好適な実施例は、次のコンポーネントから構成されるN層フレームワークに構築される（図1を参照）：
フロントエンド・ブラウザ11およびアプリケーション層を含むウェブ・サーバ12および複数のマシンに分散された複数の分析エンジン13、14。同様に、システムおよびスケジューリング・ジョブにデータを供給するような、インフラストラクチュア機能性を提供する他のサービスプロセスもある。物理アーキテクチャにおいて定義された他のコンポーネントは、データベース15およびタプル・スペースに似ている共有オブジェクト・メカニズムを使用して、トランザクショナル・パーシステンスを提供する。
【００５７】
第1のコンポーネントは、ブラウザに存在しているフロントエンドGUIである。2つの好適なブラウザは、この時点で、Microsoft Internet ExplorerおよびNetscape Navigatorである。これらのブラウザの両方とも、類似の機能性を提供するが、アプリケーションの最終的な設計で説明されなければならない細かい方法において異なる。
【００５８】
ブラウザは、実施の可能な候補として、JAVA(登録商標)アプレット 21を目標とする多数の拡張を有する。これらのアプレットは、全ての必要な機能性を提供するために、拡張されたJRE (Java Runtime Environment)を必要とするかもしれない。アプリケーションは、最もシン(thin)な、可能なクライアントを必要とするはずである。
【００５９】
ブラウザとホスト・システムへの間のコミュニケーションは、ブラウザが公共インターネットまたは専用の私設通信網16を使用することを要求する。リクエストは、計算-ホスティング・センターに到着し、およびサーバ・ファームにおける多数のウェブ・サーバの1つに送信される。いくつかの実施例において、ブラウザおよびウェブ・サーバ間の接続は、スティキー・セッションを必要とし、このことは、1つのブラウザが、セッションの存続期間の間、常に1つのウェブ・サーバと通信することを意味する。
【００６０】
ウェブ・サーバ自体（図2を参照）は、購入された、またはベンダーから認可された標準的な1つの技術である。それは、システムの要件を満たすために、標準的HTTP機能性と必要なパフォーマンスおよびツールを提供する。
【００６１】
ブラウザおよびウェブ・サーバ間のコミュニケーションは、SSL 3.0以上を使用して、暗号化されることが好ましい。追加の物理的なアプリケーション安全対策は、クライアント・データを保護するためにとられる。
【００６２】
ウェブ・サーバは、サーブレット・コンテナ22のホストをつとめる。この層は、HAL 23と呼ばれる。HALは、ウェブ・サーバからのリクエストを受信し、次に、HTMLまたはXML応答を送信する。このプロセスの詳細は、論理アーキテクチャと関連して更に下記で述べられる。
【００６３】
オペレーションの処理は、BDT 24において発生する。実際の計算は、HALと同じプロセスにおいて、またはAnalytic Engines 13、14の役割をする他のプロセスにおいて発生する。Analytic Enginesは、一般的な、または特定のオペレーションの何れかを実行し、およびバッチ処理に関与する責務を割り当てられることも可能である。処理の場所およびバッチ対リアルタイムとして実行されなければならないことの決定は、プロファイルおよびスケーリングの考慮事項を使用して決定される。
【００６４】
バッチ処理を実行するために、スケジューリング・プロセスのセットは、一日の特定の時間に、またはできるだけ早く、長期のジョブを調整するために存在しなければならない。ジョブは、内外のソースから生じる。他の実施例において、パフォーマンス属性およびシミュレーションが、加えられる。これらのリソース集約型タスクを実施するために、それらは、予め決められた間隔で、またはシステムがリソースを有する時の何れかで発生するように、ユーザにより予定に入れられなければならない。内部のジョブ・スケジューリングは、データに対するアップデートに応答して発生する。このことは、次に、コンポジットおよびベンチマークを再計算させる。
【００６５】
データ・アクセス25は、リレーショナル・データベース15を使用して実行される。現在、アーキテクチャは、データベースベンダー中立であり、唯一の必要条件は、それがJDBCインターフェースを提供するということである。このことは、トランザクショナル持続データにとって充分である。システムは、また、ジョブ情報およびタスクのような、より多くの一時データも必要とする。現在、Tspaces 17（図1を参照）または等価物は、システムのより多くの非常駐の要素を調整するために価値があることを決定された。TSpacesは、プロセスを同期的方法で状態にアクセス可能とする共有オブジェクト・メタファーを提供する。プロファイルおよびサイズ設定の考慮事項は、メカニズムに対して個々のデータ・アイテムの配置を決定する。
【００６６】
論理アーキテクチャ
好適な実施例の論理アーキテクチャは、6層構造（図2）に構築される。層は、最上位から最下位まで以下の通りに構成される：
・ユーザ・エージェント(UA) 11
・HTTPアプリケーション層(HAL) 23
・ビジネス・オブジェクト層(BOL) 24
・分析層(AL) 13, 14
・インフラストラクチャ・サービス(IS) 26
・データ・アクセス(DA) 25
これらの層は、それより上の層へのサービスおよびインターフェースのプレゼンテーションを可能にするように、編成される。上位層は、それの下の複数のレベルの層のサービスを利用することができ、唯一の制限は、下位層がそれより上の層に関するいかなる知識をも有するべきでないということである。下位層は、任意の上位層と独立してテストされるのに充分一般的であるべきである。
【００６７】
User Agentは、Applets21、スクリプト、およびプレーンHTMLから構成されることが好ましいブラウザ・ベースのアプリケーションである。ユーザとの対話は、Apache、Orion、WebLogic、またはWebSphereのような標準Web-Application-Server技術を使用してHTTP Application Layer 27にパスされる。ここで、制御は、リクエストの解釈および異なるサブシステムへのワークのディスパッチを実行するServletに手渡される。
【００６８】
次の層は、HALが必要なオペレーションを決定するためのチャンスを有した後で、呼び出される。これらのオペレーションは、現在、Eventsと呼ばれ、およびリクエストと関連しているテンプレートの一部として、格納される。Eventsは、その後で、HALによりディスパッチされ、および或る動作を実行するために、BDTを呼び出す。動作の具体例は、或る値を計算し、およびデータベースから情報を選択するためにリクエストを行うことを含む。全てのこれらのオペレーションは、インターフェースのセット、すなわちBDTを介して実行される。
【００６９】
次に、BDTは、同じプロセスにおいて直接、またはリモート・プロセスにおいて、Analytics Layerを呼び出す。これは、あとで実行されるパフォーマンス分析に依存する。Analytics Layerは、次に、BDTのために必要なオペレーションを実行するために、JNIライブラリまたはJava Analyticsを呼び出す。分析のためのデータは、BDTまたはInfrastructure Servicesから来る。
【００７０】
Infrastructure Services層は、分散処理、リモート・メソッド分散とロード・バランシングの両方、並びに、バッチ・ジョブ管理、およびシステムのこの適切な機能のために必要なデータ・アクセスおよびキャッシング・サービス28を提供する。これらのサービスは、ジャバ・ベースであることが好ましく、および標準EJB技術を使用する。
【００７１】
各層の詳細およびこれらの層を構成するサブシステムは、タイトルを付けられた下記のセクションにおいて詳述される。
【００７２】
論理アーキテクチャ。実行フローおよびデータ・フローは、Activity Analysisと名付けられるセクションにおいて以下に記載される。
【００７３】
物理アーキテクチャ
以下の説明と関連して図1を参照されたい。
【００７４】
ブラウザ
好適な実施例のブラウザ11は、MS Internet ExplorerまたはNetscape Navigatorの何れかである。ブラウザに配信されるコンテンツは、HTTPを介してであり、およびコンテンツは、複雑さが指図する所でJava Appletsが使用される、HTML、DHTML、XMLまたはPDFにおいてである。標準は、同程度のブラウザ中立を許すように、可能な限り厳しく従われる。
【００７５】
ウェブ・サーバ
ウェブ・サーバ・プロセス12は、HTTPリクエストのための入力のポイントである。このプロセスの中で、アプリケーションの報告機能性を処理するためにリクエストを提供するHAL層がある。拡張性のために動作する複数のウェブ・サーバが存在することが可能である。ウェブ・サーバ・レベルでのLoad Balancingは、ハードウェアによって達成される。
【００７６】
分析エンジン
分析エンジン13、14は、全ての計算をサポートする。このプロセスは、最適化のようなタスクを実行するために、または単一のタイム・スライスを提供するために特殊化されることができる。それは、単一タスクを実行することができる複数のインスタンスによって分散される。フォールトトレランスを考慮すると、オペレーションは、所定のタスクを実行することができるプロセスの任意の1つ上で実行されることを必要とする。
【００７７】
最適化のような長期の外部的に開始されたオペレーションに対して、分析エンジンは、オリジナルのリクエストに関して非同期でオペレーションを処理する。結果は、イニシエータが後でそれらを取り出すことを可能とするように、識別子と関連している。
【００７８】
内部的に開始された長期のバッチ・ジョブ、例えばコンポジットおよび債券のエクスポージャ計算に対して、スケジューラは、オペレーションを完了するために必要とされるタスクのリストを編成する。これらの内部的に開始されるジョブは、予め決められた時間で、または内部のアップデート・イベントに応答して発生する。システムは、処理が終了しているとき、さまざまなエンジンにおける結果の同期を可能にしなければならない。
【００７９】
市況も、また、分析エンジンに対して同期を必要とする。条件がリアルタイムにまたはセション開始のみに同期されることを必要とされる場合、それは、選択の問題である。スケーリングおよびパフォーマンスの考慮事項は、最も効率的なデータ・ハンドリングを決定する。
【００８０】
ジョブ・スケジューラ
1つのインフラストラクチャとして、ジョブ・スケジューラ18は、分散されたまたは長期のジョブを必要とする全てのパッケージに、サービスを提供する。アーキテクチャは、オペレーションが、HTTPタイム・アウトより長くかかる計算に結果としてなる可能性があり、およびセッション自体より長く持続しさえするかもしれない多くの領域を識別した。
【００８１】
ジョブは、また、システム自体内から発生するアップデートまたはフィーダ・イベントから生じることも可能である。これらのジョブは、例えば、コンポジット証券およびベンチマークのエクスポージャまたは債券エクスポージャを計算するために、バッチ処理とすることが可能である。
【００８２】
アップデートおよびデータフィード
データは、BARRAのようなデータ生産設備から到着する。現在、システムへのデータの到着を調整する定義されたビジネス・サイクルがない。データがシステムに利用可能にされるまでには、データは、スキーマおよび完全性確認を通過したと仮定される。アーキテクチャの設計目標は、アップデートおよびユーザ・データ・インポートのための確認メカニズムが可能な限り共有されることである。
【００８３】
Updateメカニズム19は、データベースをアップデートし、およびプルベース(pull basis)でリフレッシュするために、Analyticsデータ・キャッシュ・エンジンによりピックアップされた必要な粗い細分性のメッセージを送る。システムが、彼らの特定の入力および優先権を考慮するすべてのユーザに対してエクスポージャおよびコンポジットを先回りして前処理することは、極めて難しい。それは、ユーザ特定の前処理を実行するために、データ・アップデートばかりでなく前処理をトリガするために任意のオプションのユーザ特定のアップデートにも依存しなければならない。
【００８４】
通常のアップデート／フィードは、データ生産設備データのみのために、前処理をトリガする。好ましい本実施例は、彼らが望む限り彼らの前処理をトリガするために、明示的なProcess Databaseオプションを提供し、および場合によってはユーザに対するオートメーション機能を提供する。ユーザが明示的に前処理をしない場合、彼らが最初に所定の日に関するデータを使用するとき、彼らは、わずかなパフォーマンス劣化を認める。
【００８５】
データベース
好適な実施例において、データベース15は、任意のJDBC対応SQLデータベースであることが可能である。アーキテクチャは、クライアント・ホスト・ソリューションのためのベンダー機能および必要条件の分析を可能とするために、可能な限りベンダー中立のままである。本発明と関連して使用されることが可能な現行のデータベースは、以下を含む：Oracle、Sybase、DB2およびMS SQL。
【００８６】
Databaseへのアクセスは、ORDBマッピング機能を使用して実行される。このことは、直接アプリケーションにおいてSQLを書きかつ維持することなく、リレーショナル・データベースにJAVA(登録商標)オブジェクトを持続させる便利なメソッドを提供する。それは、また、さまざまなデータベースベンダーに抽象層を提供する。
【００８７】
共有された分散オブジェクト(TSpaces)
TSpacesは、一時データ記憶およびプロセス調整のために現在使用される。TSpacesは、Tuple Spacesからの導き出された共有オブジェクト・フレームワークを提供する。フレームワークは、概念上のスペースに存在するオブジェクトのセットである。これらのオブジェクトを使用したいプロセスは、スペースからオブジェクトを取ることができる、またはそれを除去することなくオブジェクト状態を読むことができる。他方で、任意のプロセスは、スペースにオブジェクトを書き込むことができる。
【００８８】
リーダのパターンにマッチングするオブジェクトがスペースに存在しない場合、プロセスは、オブジェクトが利用可能なとき、非同期通知をブロックする、または登録をすることができる。
【００８９】
TSpacesは、スペースからの複数の読み取りおよび取り出しを更に可能にすることにより、タプル・スペース概念を取る。TSpacesは、また、Tuple SpacesまたはJava Spacesの何れよりもずっと豊富なクエリ構文を提供する。
【００９０】
TSpacesを使用することは、分散処理およびアーキテクチャのプロセスの間に発生した状態問題のいくつかを解決する。それは、同期状態管理および通知のための基本構造ブロックを提供する。
【００９１】
論理アーキテクチャ−詳細な論議
層線図
2006516166.tif 000004
2006516166.tif 000005
パッケージの主要な責務およびそれが何のサービスを提供するかの簡単な説明は、上でリストされたサブシステムの各々に対して与えられる。以下のセクションも、また、アーキテクチャの他のパッケージに対する関係およびそれら間の依存性について述べる（再度、図2を参照）。
【００９２】
データ・フローは、Activity Analysisと名付けられるセクションにおいて詳述される。
【００９３】
ウェブ・サーバ／httpアプリケーション層
2006516166.tif 000006
以下の説明と関連して図3を参照されたい。この層内のプロセス・フローの順序は、具体例および説明のために、丸の中に現れる数字により図3で示される。また、この数字は、本明細書において参照される場合、例えば(1)のように括弧に囲まれて示される。
【００９４】
ユーザ・エージェント(User Agent)
ユーザ・エージェント11は、ユーザ入力を集め、およびサーバ・レスポンスを与える役割を果たす。必要であると考えられる場合、それは、ローカル・フォーマッティングおよび確認をオプションとして提供することができる。ユーザ・エージェントに対する入力は、HTTPレスポンス41、ユーザ対話型の入力42またはスクリプトとすることができる。入力に応答して、ユーザ・エージェントは、HTTPリクエストをサーバに送信する。
【００９５】
ユーザ・エージェントは、例えば、以下の異なるメソッドの任意の1つにおいて実施されることが可能である：HTML/CSS、XML/XSLT、JAVA(登録商標)プラグインを有するApplet、Applet w/o JAVA(登録商標)プラグイン、および／またはJscriptを使用するHTML、およびDOM。
【００９６】
サーブレット・コンテナ(Servlet Container)
Servlet Container(SC) 22は、イベント・トランスレータ(Event Translator) 31およびイベント・ハンドラ(Event Handler) 32を次に使用するURLリクエスト・プロセッサ(URL Request Processor) 29にUser Agent HTTPリクエスト42(1)をパスする役割を果たし(2)、および常にレスポンスを満たさなければならないJSPページ 34および結果を得る。SCは、JSPページを実行して、HTTPセッションを管理し、およびHALを呼び出す役割を果たす。Servlet Containerは、アプリケーション・サーバにより提供される。
【００９７】
例えば、WebLogic、Orion、およびWebSphereを含むApplication Serverのための選択の配列がある。
【００９８】
URLリクエスト・プロセッサ(URL Request Processor)
Request processor 29は、各リクエストのために実行された論理を含む。それは、Page Template Factory 35からテンプレート・ページを得る役割を果たし(3)、およびHTTPリクエストに基づくイベントのリストを構成し、およびEvent ControllerおよびDispatcher 31、32を呼び出す(4)。
【００９９】
ページ・テンプレート・ファクトリ(Page Template Factory)
Page Template Factory(PTF) 35は、テンプレート・ページを取り出して解析し、および確証する役割を果たす。それは、また、リーフページを組立て、および効率のためにテンプレート・ページをキャッシュする役割を果たす。リクエストURLおよびテンプレート内の情報は、JSPページのセットおよび所定のリクエストのためのそれらのレイアウトを構成するために使用される。拡張されたJSP DTDおよびXMLは、この実施の用途となることが可能である。
【０１００】
イベント・コントローラーおよびディスパッチャ(Event Controller and Dispatcher)
ECD 31、32は、Eventバンドルを分析する役割を果たし、および必要なEvent Handler Objects(EHO) 36を構成する(5)。それは、必要に応じてイベントキューを作成し、および同期または非同期でイベントを処理する役割を果たす。
【０１０１】
イベント・ハンドラ(Event Handler)
Event Handler 32は、SessionおよびBDTオブジェクト 37に通信し(6)、およびBDTへの同期または非同期の呼び出しをする役割を果たす。Proxy Results Object 38は、BDTからRequest Processorに戻され、このプロセッサは、次に、HTTPセッションにProxy Results Objectを置き(7)、それが処理されるとき、それをJSPページで利用可能にする。
【０１０２】
JSP
JSP(Java Server Pages)34 は、現在、HTML出力を生成するために使用される(8)。各リクエストは、例えば、Banner、Portfolio Tree、および特定のレポート本体と共に、いくつかのJSPページの組立てに結果としてなる。JSPページは、フォーマッティング・オブジェクトを呼び出し(9)、次に、セッション変数からの入力として、Proxy Result Objectを得て(10)、および最終的な表示出力を与える。ビリング・イベント(Billing Events) 43も、また、ここで生成されることが可能であろう。
【０１０３】
フォーマッティング・オブジェクト(Formatting Objects)
Formatting Objects 33は、例えば、口座場所、日付フォーマット、通貨フォーマット、およびコンマ区切りを取り入れる結果をフォーマットする役割を果たす。HTML、PDF、XLSのような特定のフォーマット・レポートを作成するために、並びにグラフを生成するために、異なるフォーマッティング・オブジェクトが存在することが可能であろう。
【０１０４】
セッション・オブジェクト(Session Objects)
Session Objects 37は、Portfolio保有および戦略のようなUser Session情報を堅持するために使用される。Event Handlerは、状態を得ておよびBDTを呼び出すために、Sessionオブジェクトを使用する。Sessionオブジェクトに、全てのStrategyオブジェクト、ユーザ変更部分並びに未変更部分を保存することは、現在好ましい。
【０１０５】
プロセス・フローの概観
以下の説明と関連して図3を参照されたい。
【０１０６】
1.  入って来るHTTPリクエストは、Servlet Container(SC)により受信される。SCは、  
URLおよびパラメータにリクエストを解析し、およびHTTPセッション変数として
それらを格納する。
【０１０７】
2.  SCは、URL Request Processor(URP)を呼び出す。
【０１０８】
3.  URPは、Page Template Factory(PTF)からのレスポンス・ページを取り出し；ペー
ジ・フローおよびイベントオブジェクトを構成する。URPは、必要に応じてSCか
らパラメータを取り出す。PTFは、テンプレート・ページの検索、構文解析、確認、
組立て、およびキャッシングの役割を果たす。
【０１０９】
4.  Eventオブジェクト・バンドルおよびレスポンス・ページは、Event Controller and 
Dispatcher(ECD)にパスされる。
【０１１０】
5.  ECDは、イベント・ハンドラ・オブジェクト(EHO)のインスタンスを生成し、およ
び同期、または非同期の何れかで、それらにイベントをディスパッチする。イベン  
トキューイングは、FIFOである、または管理されることが可能である。
【０１１１】
6.  EHOsは、Proxy Result Objects (PRO)のインスタンスを生成し、それらをセッショ
ン変数に加え、およびイベントを処理するためにBDTを呼び出す。BDTが実結果
オブジェクトに参照を戻す場合、PROは参照を配置される。実結果が充分にすばや
く戻されない場合、IOUは戻される（以下に記載）。
【０１１２】
7.  ECDは、SCへプログラム制御を戻す。
【０１１３】
8.  SCは、JSPページを実行する。
【０１１４】
9.  JSPページは、Formatting Objectsのインスタンスを生成する。
【０１１５】
10.  Formatting Objectsは、セッション変数からPROを取り出し、および結果をフォ
ーマット化する。
【０１１６】
11.  SCは、User Agentへレスポンス・ストリームを送信する。レスポンス・ストリー
ムは、フォーマット化された結果および／またはIOUを含む。
【０１１７】
ビジネス・オブジェクト層(Business Objects Layer)
戦略(Strategy)
Strategy 44は、多数の設定を含む。Strategyは、セッション・レベルで特定されることができ、そして次に、PortfolioツリーのPortfoliosにより、選択的にオーバーライドすることができる。Benchmark、Numeraire、MarketおよびAnalysis Dateのようないくつかのパラメータも、また、同様にMenu Barを使用してオーバーライドされることができる。
【０１１８】
分散分析(Distributed Analysis)
任意の計算の一部として、オペレーションがローカルに実行されることができるか、またはそれがリモート・マシンに分散されなければならないかを決定することが必要である。この分析およびインフラストラクチュア層により実行される、続くロード・バランシングは、ここで開始される。
【０１１９】
オペレーションを実行するための全ての必要情報がローカルに利用可能であるか、または情報を得るコストが演算時間に対して相当に安いか、およびオペレーションが完了するために非同期バッチ処理を必要とするかの基準は、オペレーションの長さである。
【０１２０】
アナライザ45は、ランタイムで、または少なくとも起動時間で構成される。このことは、システムが、実際の実施を変えることなく、それが最も効果的な所に処理を移動させることを可能にする。
【０１２１】
リスク計算機(Risk Calculator)
このオブジェクト46は、BDTで公開される。それは、BDTの一部であり、およびアプリケーションにより実行された全てのリスク計算に関するエントリー・ポイントであるワークホース・オブジェクトを表す。BDTのクライアントは、それらのセッションにおいて表される適切な状態をセットするようにRisk Calculator上で動作する。
【０１２２】
結果オブジェクト(Result Objects)
任意の計算の結果として、BDTは、結果の一般的な集合を有する。結果47は、リクエストの存続期間の間のみに、またはそれは、リクエストの中間の何れかに存続することができる。決定は、結果の一時記憶により発生されたスペースに対して、結果を生成するためにかかった時間の長さに依存している。
【０１２３】
リクエスト間に中間結果を保持することの利点は、それらが、同一データのわずかに異なるビューをリクエストしているのみである、続くリクエストのために使用されることができることである。結果を持続することは、また、ユーザが分類された計算された列にナビゲートするとき、必要とされるサブポートフォリオを計算することをより容易にする。
【０１２４】
結果は、また、IOUとして表されることも可能である。このことは、それらが非同期で生成されていることを示し、およびユーザは、あとでそれらをリクエストすることができる。いくつかの実施例において、全ての結果は、このように現れ、およびクライアントは、結果がそれらにアクセスする前に利用可能か否かを常にチェックし、およびそれらがそうでない場合、結果を待つ。このモデルにおいて、結果は、それらが使用されることができる前に、間接参照されなければならない結果ハンドルとして提示される。このアーキテクチャは、同期またはバッチリクエストを含んでいるリクエストに対して、うまく機能する。
【０１２５】
他の実施例は、結果の遅延評価を可能とする。結果は、その時、クライアントのリクエストを履行するために、オンデマンドの計算または選択を実行する。結果は、実施に依存して、プレフェッチまたは前もって計算するグラニュラリティのレベルを決定することができる。
【０１２６】
ビジネス・オブジェクト(Business Objects)
これらのオブジェクトは、また、BDT 48の一部でもあるが、サブセットのみは、クライアントに公開される。それらは、ポートフォリオ、位置、資産詳細等のような、全て、高水準オブジェクトを表す。いくつかのインターフェースは、Analytics Object Library定義の拡張または実施である。
【０１２７】
ビジネス・オブジェクトは、また、データ・アクセスのためのプライマリ・パスである。これらのオブジェクトは、パーシステンス層により維持されたデータオブジェクトを表し、拡張し、または含む。パーシステンス・マネージャも、オブジェクトを記憶する最良の場所を決定する、または上位層は、パーシステンス・マネージャに最良のパーシステンス・メカニズムを示す。
【０１２８】
分析ライブラリ(Analytics Library)
分析ライブラリ13、14は、システムのための計算フレームワークを収容する。現在、全部のコンテクストが発呼者から供給され、可能な限りステートレスであると仮定される。計算メソッドそれ自身は、それらが実行するオペレーションに必要な情報を得るために、分析オブジェクト49を使用する。
【０１２９】
Current Analysis、Historical Analysis、Risk、OptimizationおよびFixed Income Exposures Calculationsのような基準に基づいて、特定化された多数のAnalytics Enginesの何れかを提供することは、好適である。分析エンジンは、それらが、BOLによりそれらに供給されたインターフェースを通して必要とするデータを得る。
【０１３０】
分析オブジェクト(Analytics Objects)
これらは、実際にオブジェクトでないが、計算のための必要な情報を得るために分析ライブラリにより使用されるインターフェースである。実際のオブジェクトは、パーシステンス法およびキャッシングを決定する責務を有する他の層において実施される。それらは、正しく必要とされるオペレーションを実行するために履行されなければならない他の層と取り決めを形成する。
【０１３１】
リスク分析 50および手段分析 51は、インターフェースに符号化する。
【０１３２】
リスク分析(Risk Analytics)
全てのリスク計算は、ここに存在する。リスク分析は、パーシステンス層からのエクスポージャを使用して、または手段分析により計算される。
【０１３３】
全ての情報は、分析オブジェクトにおいて定義されたインターフェースを通してリスク分析により受信される。追加情報は、直接パーシステンス層から受信されることができる。
【０１３４】
手段分析(Instrument Analytics)
手段分析は、特定の手段に関する価格付けおよびエクスポージャの計算を実行する実際の数理モデルである。これらのライブラリは、一般的に、C++、CまたはFortranにおいてさえ、実施される。システムは、外部ライブラリと通信し、およその結果をJAVA(登録商標)オブジェクトへ戻して伝えるために、JNIを使用する。
【０１３５】
分析用のほとんどのデータは、クライアントからパスされる。データが、Intexを有するMBS価格付けにおけるようにソースから直接に、またはデータベースから来なければならない、いくつかのケースがある。このことは、基礎をなすライブラリおよびパフォーマンス考慮事項の必要条件に依存する。
【０１３６】
インフラストラクチュア(Infrastructure)
インフラストラクチュア26は、Tspaces 17、データベース・キャッシング、Object-Relationalマッピング、Jobスケジューリング、Tracing、Persistence、Security、およびTransaction処理のような多数のサービスを参照する。
【０１３７】
ジョブ管理(Job Management)
ジョブ・スケジューリングおよびメンテナンス機能52は、周期的なタスク、並びに長期のタスクを調整するために必要とされる。このようなタスクの結果は、将来ある時間でタスクを開始したエンティティによりアクセス可能でなければならない。このサブシステムは、リモートでジョブを予定に入れること、進行中または動作待機中のジョブをキャンセルすることが可能でなければならない、およびそれは、ジョブ・ステータスをチェックすることが可能でなければならない。
【０１３８】
分散処理(Distributed Processing)
或るタスクは、完了するために2つ以上のリソースを必要とする。これらのタスクは、一般的に、それらのタスクに割り当てられた時間内で完了するように、複数のマシンおよびプロセッサの介入を必要とする大きいバッチプロセスである。インフラストラクチュアは、これらのタスクの容易な定義および利用可能リソースを使用するロードを分散するメソッドを可能とするために、サービス53を提供しなければならない。Load Balancing 54およびTask Coordination 55モジュールは、同様に含まれる。
【０１３９】
タスク調整(Task Coordination)
2つ以上のプロセスに分散されるタスクに対して、メカニズムは、マスター・タスクを完了する、異なるサブタスクを調整することを必要とされる。コーディネータは、分散処理を必要とするリソース集約的な計算を手伝う。その役割は、オペレーションの再分割された部分に含まれるリソースを管理し、およびさまざまなサブ・コンポーネントからの結果を編成することである。
【０１４０】
ロード・バランシング(Load Balancing)
ロード・バランシングが必要とされる3つの場所：Web Serverレベル、ユーザにより直接呼び出されるAnalytics、およびオーバーナイトのFixed Income Exposures計算がある。Web Serverロード・バランシングは、ハードウェアによって達成される。ソフトウェア・ロード・バランシング・メカニズムは、BDTの下で実施される。バッチ処理のため、並びにユーザ・ジョブのためのエクスポージャ計算は、TSpacesのような技術を使用して実施される。
【０１４１】
分散イベント(Distributed Events)
Tspacesは、データ・アップデートが発生するとき、キャッシュ・データ同期を達成するために、および更に、場合によってはBDTからの非同期要求処理を処理するために、分散イベント・メカニズム56を提供する。
【０１４２】
トランザクション管理(Transaction Management)
トランザクションは、システムの多くの領域において必要とされる。トランザクションは、全体として完了する、またはシステム上で実質効果を有さない、一群のオペレーションとして定義される。データベース・トランザクションは、最も一般的である、しかしトランザクションは、また、1つの計算を実行するために、オペレーションの分散セットに関して発生することも可能である。
【０１４３】
トランザクション管理および前トランザクション状態に状態をロールバックするためのセマンティクスは、このサブシステム57にカプセル化される。実際の実施は、複数のサブシステムにわたることができる。
【０１４４】
パーシステンス管理(Persistence Management)
持続データへの全てのアクセスは、キャッシュされる、またはデータベース上、またはTspacesのような一時記憶内であろうが、この機能58を使用して発生する。いくつかの実施例において、ロギングおよび他の類似のサービスは、パーシステンス管理サブシステムを使用する；他のものにおいて、それらは、フラットファイルまたはデータベースへ直接進む。
【０１４５】
パーシステンス管理は、任意のデータを持続させようと望む全ての上位層に対する1つの接点である。このように、格納される情報の全ての異なる種類のパーシステンスおよびライフサイクルを考慮することは、極めて重要である。それは、全ての必要条件に対応するのに充分フレキシブルであるインターフェースを提供しなければならない、並びに、それが後でパーシステンスの基礎をなすメカニズムを変更するよう望まれる場合に、プロテクションを提供しなければならない。
【０１４６】
ユビキタス・トレーシング(Ubiquitous Tracing)
所望のモジュールが効果的にWeb Applicationsをデバッグするために、詳細の異なるレベルで選択的にTracingをオンにすることが可能であることが必要である。管理コンソールを使用して、必要に応じてトレーシングをオンまたはオフにするリモートAPIが存在しなければならない。
【０１４７】
また、留意することは、リリースのために選択的に除去されることができるアサーションの必要性である。プレプロセッサまたは他のツールは、この目的59を達成するために使用されなければならない。
【０１４８】
データ確認(Data Validation)
データ確認60は、条件、市場データ、およびポートフォリオのような、所有者およびユーザに供給されたデータに必要とされる。重大エラー・メッセージをユーザに報告することが可能であるように適所に充分なチェックを置くことが、必要である。
【０１４９】
ロギング／リモート・トレーシング(Logging / Remote Tracing)
ロギング能力61は、使用分析を提供するために必須であり、および報告された問題をデバッグしている。リモート管理コンソールから必要に応じて詳細の異なるレベルをオンにすることは、必要である。中央側からログを探索、および検査する能力がなければならない。
【０１５０】
データ・アクセス(Data Access)
データ・アクセス層25は、上位層が使用することができる多数の異なる持続メカニズムを提示する。現在識別される持続記憶の3つの異なるタイプがある。それらは、以下の通りである：
・長期耐久性のパーシステンス：これは、トランザクションをサポートし、および安全
な記憶およびロギングを有する商用データベースにより最良に供される。
【０１５１】
・共有された一時的なパーシステンス：一時的な結果が、分散された計算に対して利用
可能にされたサービスを提供するために、このサービスは、複数のプロセスが同期し  
てデータをアクセスすることが可能になる共有オブジェクト・メタファを配信する。
【０１５２】
このタイプの記憶は、また、タスク管理およびイベントのために使用される。
【０１５３】
・キャッシング(Caching)：これは、要求側と同じプロセス内に残るデータへのアクセス
を、メモリ内で速く提供する。データがメモリ内にあるので、それはプロセスの使用
可能メモリに限られている。
【０１５４】
これらの異なる記憶のメソッドを使用すると、現在のシステムの必要条件は、満たされ、およびそれは、将来のリアルタイム機能性を可能にする。
【０１５５】
データベース・アクセス(Database Access)
データベース15は、Oracle、SybaseまたはMS-SQL Serverのような標準関係データベースの1つである。
【０１５６】
データ・オブジェクト(Data Objects)
全てのJDBC詳細を隠し、かつ適宜データベースまたはキャッシュからそれを取ってくることにより、必要なデータを与えるData Access Objects 62を提供することは、必要である。一緒に全ての関連情報を与える集約オブジェクトを有することは、必要である。
【０１５７】
分散オブジェクト(Distributed Objects)
計算結果がマシン境界をパスすることが可能であろうという事実が与えられると、ネットワーク・ラウンドトリップの数を最小限に抑えるために慎重に全ての分散オブジェクト63を設計することは、必要である。
【０１５８】
キャッシング(Caching)
サポートされるユーザの数および全てのユーザの中で共通しているデータ量が与えられると、高パフォーマンスを達成するために、キャッシング・メカニズム28は、TermsおよびConditions、市場データ、モデルデータ、およびポートフォリオのようなアイテムを取り出すために必要とされる。一旦、システムがデータをキャッシュすることを開始すると、データ・アップデートが発生するとき、キャッシュをアップデートすることに気をつける必要がある。好適な実施例において、TSpacesベースのプル・メカニズムが使用される。
【０１５９】
ライセンスおよびパーミッション(Licensing and Permissions)
メカニズム64を提供することは、ユーザのLicensing（申込）に基づいてアクセスを或るベンダーデータに制限するために、好適である。例えば、ユーザがそのデータにアクセスするための前金の申込料金を払った場合のみ、Intex CMOデータ・アクセスは、与えられる。本発明は、また、Organizationsおよびユーザが、Portfolios、Portfolioツリー、およびStrategiesのような多様なアイテムとパーミッションを関連づけることを可能にする。
【０１６０】
スクリーニング・ツール(Screening Tools)
記述的、および前もって計算された値を含む多数の基準に基づいて資産のスクリーニング65をサポートすることは、必要である。好適な実施例は、これを行うために、基礎をなすデータベース・エンジンを使用する。
【０１６１】
ビリング(Billing)
ビリングシステム43は、出力レスポンス生成終了後HALにより呼び出される。照会も、また、クオータ・オーバランに対して任意のセッションの初めに行われる。ビリングシステムは、例えば、以下の領域の情報を得なければならない：ポートフォリオの修正の時間、レポートにおける属性のリスト、ユーザ、およびセッション。
【０１６２】
ビリングシステムは、シングル・ログ・アイテムに、1つのセッションに対する料金が請求できるレベルを繰り返した複数のログ・エントリを組み合わせる役割を果たす。ビリング・サブシステムは、基礎をなす課金イベント構造の変化が、アプリケーションの他の部分に影響を及ぼさないように、システムにおいて可能な限り分離される。ユーザ、クライアント、およびセッションIDを識別することは、セッションに依存し、およびクライアント使用料レベルを得ることは、いくつかのパーシステンス・サービスを必要とする可能性がある。ビリング・レベル情報が残りのデータと共にまたは別々のデータ格納において保持される場合、それは、選択の問題である。
【０１６３】
この時に、ビリングシステムは、リクエストに関して非同期である。システムは、ビリング・イベントが発生したことを記録し、およびビリングシステムは、バックグラウンドでログ・イベントを集める。
【０１６４】
クォータ・チェックおよび強制も、また、この領域に位置づけられる。それは非同期的性質を共有し、およびバックグラウンドでクォータ・チェックを実行する。複数ユーザから単一のクライアントに対して到着する複数のリクエストのオーバーヘッドおよびビリングシステムのトランザクション性質のために、各イベントに対する正当性および結果として生じるクォータ調整を保証することは、必要とされる。ユーザ制限が達せられるとき、強制は実行される。
【０１６５】
この強制は、システムにログインするために、ユーザのリクエストを拒否する。ビリングシステムは、ログオン制限を強制しないが、クォータが達せられたこと、および続くログオンが許可されないことをHALに知らせる。この情報は、入れるまたは取り出すことが可能である。
【０１６６】
ビリング・サブシステムは、別々のサーバ、またはオーバーヘッドに従うサーバのグループに存在することができ、および全体のレスポンス時間に影響を与える必要はない。
【０１６７】
ビリング・ロギング(Billing Logging)
全てのBillingイベントは、持続格納66へ、好ましくは、アプリケーションのパフォーマンスに影響を及ぼさないために独自の別々のデータベースおよびサーバへ進む。
【０１６８】
アクティヴィティ分析(Activity Analysis)
好適な実施例において、設計セッションにおいて使用する省略表現として、各正規のメッセージ・トレースに対する名前を作成することは、有効である。メッセージ・フローのための名称集は、論理アーキテクチャから導き出され、および下記で要約される。詳細な線図に対して、表題をつけられた本明細書のセクションを参照されたい。
【０１６９】
論理アーキテクチャ
層1：ブラウザ・ユーザ・エージェント(Browser User Agent)
HTTP−HTML/XML
アプレット(Applets)
データ・アップロード／ダウンロード(Data Upload/Download)
層2：HTTP アプリケーション層(HTTP Application Layer)
ウェブ・サーバ(Web server)
サーブレット・コンテナ(Servlet Container)
URLリクエスト・プロセッサ(URL Request Processor)
ページ・テンプレート・ライブラリ(Page Template Library)
イベント・ディスパッチャ(Event Dispatcher)
イベント・ハンドラ(Event Handler)
フォーマッティング・オブジェクト(Formatting Objects)
JSP
セッション(Session)
フィード／アップデート(Feed/Update)
層3：ビジネス・オブジェクト(Business Objects)
BDT API
ビジネス・オブジェクト(Business Objects)
分散分析(Distributed Analysis)
結果オブジェクト(Result Objects)
戦略(Strategy)
リスク計算器(Risk Calculator)
層4：分析ライブラリ(Analytics Library)
分析オブジェクト(Analytics Objects)
リスク分析(Risk Analytics)
手段分析(Instrument Analytics)
層5：インフラストラクチュア(Infrastructure)
ジョブ管理(Job Management)
分散サービス(Distributed Services)
タスク調整(Task Coordination)
分散イベント(Distributed Events)
ロード・バランシング(Load Balancing)
トランザクション管理(Transaction Management)
パーシステンス管理(Persistence Management)
ユビキタス・トレーシング(Ubiquitous Tracing)
データ確認(Data Validation)
層6：データ・アクセス(Data Access)
データベース(Database)
データ・オブジェクト(Data Objects)
分散オブジェクト(Distributed Objects)
キャッシング(Caching)
ライセンスおよびパーミッション(Licensing and Permissioning)
スクリーニング(Screening)
それら自身のサブシステムとなるビリング・カテゴリに、いくつかのアイテムがある。それらは、以下の通りに層に論理的に割り振られた：
層3：ビジネス・オブジェクト
ビリングAPI(Billing API)
層5：インフラストラクチュア
ビリング・ロギング(Billing Logging)
層6：データ・アクセス
ビリング記憶(Billing Storage)
ログオン
下記の表「A」は、本発明によるログオン・シーケンスを示す。この表および下記の他の全ての表において、数字、例えば2.1は、図2の論理図に示される層状の要素を参照する。
【０１７０】
表A.  ログオン
2006516166.tif 000007
下記の表「B」は、本発明によるリスク概要のための提示計算リクエストを示す。
【０１７１】
表B.  リスク概要のための提示計算リクエスト
2006516166.tif 000008
2006516166.tif 000009
2006516166.tif 000010
【０１７２】
標準リクエスト処理パターン
下記の表「C」は、システムによる最も多いリクエストのための標準メッセージ・フローを示す。
表C.  標準メッセージ・フロー
2006516166.tif 000011
2006516166.tif 000012
【０１７３】
下記の表「D」は、本発明によるログオフでポートフォリオを保存するためのシーケンスを示す。
表D.ログオフでポートフォリオを保存するためのシーケンス
2006516166.tif 000013
【０１７４】
表「E」は、本発明によるフィードからのデータ・アップデートを示す。
表E.  フィードからのデータ・アップデート
2006516166.tif 000014
【０１７５】
フロントエンド(Front End)
以下の議論は、システムFront End、すなわち、User Agent LayerおよびHTTP Application Layerの設計を説明する（図4も参照）。アーキテクチャの概観、およびフロントエンドがアプリケーション・プロセス・フローを適合させる方法の説明に関して、本明細書のHigh Level Architecture説明を参照されたい。
Front Endは、主に、次の役割を果たす：
・リクエストを処理するために、HTTPリクエストを解釈し、およびビジネス・オブジェクトおよびインフラストラクチュア・サービスを呼び出すこと；
・さまざまなプレゼンテーション・フォーマットに結果を変換し、およびHTTPレスポンスをユーザ・エージェントに配信すること；
・HTTPプロトコルおよびユーザ・エージェント詳細をカプセル化する間、対話機能を提供すること；および
・内部または外部セキュリティ、ロギング、および管理メカニズムにインターフェースすること。
【０１７６】
Front Endは、拡張可能な、データ駆動方法でアプリケーション・ワークフローを処理する；HTTPリクエストをノンブロッキング、非同期イベント駆動型の方法で処理する；ウェブ・アプリケーション・サービスから期待されるスケーラビリティ、障害許容力、および高い有効性をサポートする；およびシステム・アーキテクチャに影響を与えることなく個々のコンポーネントおよびモジュールを置き換える。
【０１７７】
フロントエンドは、2つの主なコンポーネントから成る（後で更に詳細に述べられる）：
1.  フレームワーク(Framework)。Frameworkコンポーネントは、ウェブ・アプリケーションの構造、コンポジション、レイアウト、ナビゲーションおよびプレゼンテーション面に対処する。
2. アプリケーション(Application)。Applicationコンポーネントは、システム機能要件を実施する。
【０１７８】
フロントエンド・アーキテクチャ(Front End Architecture)
Front Endは、JAVA(登録商標)ウェブ・アプリケーション・フレームワークである。それは、ノンブロッキング、非同期イベント駆動型の方法で、HTTPリクエストを処理するように設計される。それは、処理待ち時間の大きいバリエーションを適切に処理することができ、および残りのアプリケーション層をプレゼンテーションおよびHTTPプロトコル詳細から遮断する。
【０１７９】
Front Endは、テンプレート・メカニズム68および一組の再使用可能なUIモジュール上に構築され、およびデータ駆動方法でアプリケーション・ワークフローを処理する。それは、システム・アーキテクチャに影響を最小限に抑えながら、アプリケーション機能性の発展をサポートするように、設計される。Front Endのための設計指標の1つは、可能な限り基礎をなすプラットフォームにより提供されたアプリケーション・サービスにレバレッジを導入することである。設計の焦点は、既存の技術の弱点を補償する一組の必要な抽象概念を導入することである。それは、HTTPプロトコルおよびコミュニケーション詳細のほとんどを処理するように、Webサーバ12およびサーブレット・コンテナに依存する（図2を参照）。テンプレート・メカニズムは、JSPおよびApacheコミュニティにより普及されたXMLベースの設計パターンを組み込む。プロトコル・バインディングは、W3C標準および勧告に厳しく従った。
【０１８０】
Front Endの中心に、イベント・メカニズムおよびテンプレート・メカニズムがある。イベント・メカニズムは、ワークフロー・コマンド生成、コマンドディスパッチ、および結果ランデブーを処理する。テンプレート・メカニズムは、コマンド定義、ワークフロー・モデル化、および結果トランスフォーメーションを説明する。再使用可能なUIモジュールの配列と共に機能して、イベントおよびテンプレート・メカニズムは、著しく、新開発の速度を改善し、およびメンテナンスのコストを減らす。
【０１８１】
障害許容力に対して、Front Endは、イベント・ディスパッチングのためにリトライ・メカニズムを組み込む。セション状態が分散される限り、Webサーバ障害の後の最悪のケースは、ユーザに最後のリクエストを再提出することを強制することであり、これは、システムが極端なロードの下にあるとき、発生することと類似している。
【０１８２】
コンポーネント(Components)
上記のように、Front Endドは、2つのコンポーネントから成る：
・Frameworkコンポーネント、別名HALは、Web アプリケーションの構造、コンポジション、レイアウト、ナビゲーションおよびプレゼンテーション面に対処する。
【０１８３】
・Applicationコンポーネントは、Framework、BOL 24、および機能要件を実施するインフラストラクチュア・サービス上に構築されたアプリケーションモジュールの集合である。
【０１８４】
図5は、Front Endの主要なインターフェースを示すブロック略線図である。
【０１８５】
フレームワーク(Framework) 
Frameworkコンポーネントは、Front Endの基礎である。物理的に、Frameworkコンポーネントは、Web Server上、およびServlet Engineを有する同じプロセス空間に存在する。それは、幾つかの明確に定義されたインターフェースによるBOLおよびインフラストラクチュア・サービスと対話する。コミュニケーションは、値渡しセマンティクスを使用することにより実行される。設計は、フロントエンドを、基礎をなすアプリケーション層から切り離すよう努め、このことは、それらが、独立して拡張され、および必要に応じて物理的に境界にわたって切り離されることを可能にする。
【０１８６】
セッション(Session)
フロントエンドのセション状態は、3つのタイプの情報を含む：
・WorkItem、結果、イベント等のオブジェクト・グラフ；
・フォーム状態、未遂のデータ・エントリ等のオブジェクト・グラフ；および
・セッションid、バージョニング情報、タイマー、などを含むいろいろなセッション属
性
テンプレート定義およびツールボックスのような持続格納から容易にリフレッシュされることができるオブジェクトは、セッションの一部ではない。それらは、わずかに参照されるキャッシュされたメモリに存在する。
【０１８７】
セッションは、ロード・バランシングを処理するために、バージョニング方式を使用する。具体的には、セッション・オブジェクトおよび各オブジェクト・グラフのルート・ノードは、任意の子アイテム上のアップデートの後で増加するバージョン・フラグを伝える。SessionManagerは、パーシステンス格納に対するバージョン情報およびデルタ状態変化を完遂する役割を果たす。
【０１８８】
リクエストがWebサーバに達するとき、SessionManagerは、最初にセッション・オブジェクトのバージョンを持続格納にあるものと比較する。ミスマッチは、オブジェクト・グラフの走査をトリガし、持続格納からメモリにスナップされた失効した、または存在していないオブジェクト・グラフに最終的に結果としてなる。セッションマイグレーションのタイミングおよびグラニュラリティ詳細は、パーシステンス・メカニズムに依存する。
【０１８９】
SessionManagerは、セッションを消去することができ、または非アクティブセッションを停止させることができる。セッションが消去されるとき、オブジェクト・グラフの全部の走査は実行され、および明確な呼び出しがリソースを解放させる。セッションが停止させられるとき、リソースが解放される前に、全てのセション状態は持続させられる。
【０１９０】
一般に、セッションの存続期間≧HTTPセション存続期間であり、それは≧SSLセション存続期間である。SessionManagerは、期限切れのセッションの不要部分を回収(garbage-collect)するためにリーパ・スレッドを維持する。セッションは、また、管理動作で明示的に無効にされることができる、例えば、ユーザのアカウントをロックする。
【０１９１】
リクエスト(Request)
一般的な処理シーケンス
一般に、次のステップは、各一意的なリクエストのために実行される（図6を参照）：
1.   セッションは、確証され、および最新でもたらされる；
2.   リクエストURIは解析され、およびユーザ許可は確かめられる；
3.   workItemは、リクエストのために作成される；
4.   リクエストと関連しているテンプレート・ページは、キャッシュまたは持続記憶の
何れかからロードされる；
5.   一組のイベントは、イベント定義およびテンプレート・ページ定義の命令に従って
構成される；
6.  イベント・インスタンスは、httpリクエスト・パラメタ値によって配置される;
7.  イベントはディスパッチされ、それは、最終的に結果として、対応するBOL API関
数の呼び出しになる；
8.  イベントが十分にすばやく完了される場合、結果オブジェクトは収集され、およびさ
まざまなプレゼンテーション・フォーマット、例えば、HTMLページ、に変換され、
およびクライアントに配信される。そうでなければ、IOUは、その代わりに配信さ
れる；
9.  ブラウザ・クライアントのために、IOUレスポンスは、ユーザにワーク・アイテム・
ステータスのビジュアル・フィードバックを与えるメカニズムを含む；
10.  IOUは、結果が準備完了となる後の時間で自動的に取り戻される;
11.  ビリングおよびアクティビティロギングのような派生イベントは、適切な時間に非
同期でディスパッチされる。
【０１９２】
リクエスト存続期間
リクエストの存続期間は、基礎をなすWorkItemにおいて具体化される。WorkItemがリクエストのために作成された後で、その存続期間は隣接したHTTPリクエスト／レスポンスを越えて持続することができる。それは、以下の最初期まで、セッション中に持続する：
・  ユーザは、例えば、キャンセルボタンをクリックすることにより、明示的にリクエ
ストをキャンセルする、
・  ユーザは、新しいリクエストを提出することにより、暗黙的にリクエストをキャン
セルする、
・  ユーザは、結果を取り戻す、
・  リクエストが完了する前に、セッションは、タイム・アウトする、または他の理由
のために無効になる。
【０１９３】
WorkItem.destroy()メソッドを呼び出すと、既存の結果が破棄され、およびcancel()が進行中のイベントに対するイベント・ハンドラを要求する。キャンセルメカニズムが機能するか、しないかにかかわらず、キャンセルされているWorkItemが、もはやセッションの現行のWorkItemではないので、効果は、ユーザに見えない。
【０１９４】
結果識別
通常処理フローに対して：
・  WorkItemは、各一意的なURIリクエストのために作成される、
・  各URIリクエストは、テンプレート・ページにマップされる、
・  各テンプレート・ページは、1つ以上のウィジェットを含む、
・  各ウィジェットは、1つ以上のイベント参照を含む、
・  各イベントは、1つのAPI呼び出しにマップされる、
・  各API呼び出しは、1つの結果オブジェクトに結果としてなる、
通常、正しい結果オブジェクトを位置づけるためにオブジェクト階層の全部の走査を実行することは、必要でない。或るプログラミング便宜は、提供される。例えば、JspIncludeフォーマッタは、JSPページを呼び出す前に、特別なリクエスト属性として、関連する結果オブジェクトを設定する。JSPページは、その時、結果オブジェクトを取り出すために、リクエスト属性を問い合わせることができる。
【０１９５】
イベント(Event)
EventBundle
BOLイベントは、EventBundlesにおいてディスパッチされる。動機付けは、Event順序を強制し、およびスティックネスを容易にすることである。順位付け情報は、明示的にテンプレート定義のリストに記載されている。
【０１９６】
BOL結果は、ResultBundleにおいて戻され、それはEventBundleの全てのイベントに対する結果から成る。部分的に完了されたResultBundlesのパーシステンスを管理することは、BOLの責務である。BOLイベントからの結果は、実結果または結果の物理的位置に対する参照である。
【０１９７】
BOLイベントおよび結果の両方は、ワイヤ・プロトコルとして、SOAP Encodingを使用する。
【０１９８】
BOLイベントのディスパッチ
一般的なイベント処理シーケンスに対して、図7を参照されたい。
【０１９９】
最適化として、EventBundleの初めのディスパッチの間、hal.eho.BOLEventHandlersは、以下のことが可能である：
・  BOL.EventHandler.dispatchEvent(foo)を呼び出す；
・  Thread.sleep(bar)を呼び出す;
・  BOL.EventHandler.checkProgress(foo)を呼び出す。
【０２００】
第3のステップは、処理が完了した場合、結果オブジェクトを回復する思惑的な試みである。このことは、場合によっては、IOUの受け渡しに含まれる全部のHTTPラウンド・トリップを保存する。
【０２０１】
進行のチェック
進行モニタリングは、EventBundleベースに行われる。進行のチェックは、ユーザ・エージェント、またはHALの何れかにより開始される。
【０２０２】
WorkItemオブジェクトは、簡単な加重方式によるリクエストの全体の進行を評価する。例えば、リクエストが、それぞれ100%および50%完了した2つのイベント・バンドルに分解する場合、WorkItemは、少なくとも50%終了として、リクエストを考える。
【０２０３】
リトライ
サーバ誤りの後、リクエストを再試行するために、WorkItemは、リクエストにより作成されるイベントのプライベートのコピーを保持する。障害が発生した後で、既存の結果は保持される。不成功のEventBundleは、再試行される。再試行されたオペレーションが冪等であることを保証することは、BOL次第である。
【０２０４】
例外
例外的な条件の分類
例外的な条件を説明するために多くの形容詞がある、例えば：
・  システム-レベル対アプリケーション-レベル
・  破局的対修復可能
・  最後対再開可能
・  予想外対予想される
一般に、前者タイプの例外は、システムが整合した状態に容易に復元されることができない、一方、後者はそうすることができることを意味する。
【０２０５】
例外の前者のタイプをキャッチし、かつ処理することは、このような例外がコア・ダンプとして処理されることができるので、より容易である。矛盾している状態から戻ることが問題であるので、人はこのような例外をキャッチする前によく考えてみるであろう。
【０２０６】
プログラム用言語の中の例外メカニズム
JAVA(登録商標)およびC++は、両方とも例外処理のための言語機能を提供する。基本的な姿勢は、終端としてエラーを処理することになっている。エラーは、決定的であり、状況を救い、かつエラーが発生したところに戻す方法がない。実行は、例外ハンドラの直接囲んでいる範囲において続けられるのみである。
【０２０７】
代わりの姿勢は、直接ハンドラが故障条件を訂正することができることを望むことであり、したがって、実行は、誤りが検出されるポイントから続けることができる。それは、修復可能障害のためのリターンコードの明確なチェックを除去することができる強力なコンセプトである。
【０２０８】
再開が最初は魅力的に思われるにもかかわらず、歴史的に、デベロッパーは、再開の例外処理を放棄し、かつ再開不可能なモデルを使用した。理由は、誤り条件がコンテクストに応じているので、あなたが正確なスロー位置を知るようにハンドラを符号化しなければならないからである。それは、複雑かつ冗長な例外処理を行う。
【０２０９】
COMで具体化される第3の姿勢がある。ここで、誤り処理が関係する限り、あなたは、自己責任である。単一のチェックされていないHRESULTは、劇的な障害においてシステムを停止することが可能である。また、重要なアプリケーションにチェックインするための何百または数千のものがある。
【０２１０】
追加的な例外処理機能の必要性
Front Endのための設計目標の1つは、堅牢な例外処理フレームワークを提供することである。強力であるにもかかわらず、JAVA(登録商標)の例外メカニズムは誤り処理の複雑さを処理するのに充分な柔軟性および機能を提供しない。複雑さは、2つの領域、ワークフローおよびプレゼンテーションに現れる。例えば：
単一のBDT API呼び出しは、複数の戻りステータスを有することができ、かつ各々異なるコンテクストの下で異なって処理されることが必要とされる。例えば、ポートフォリオに対する変化を完遂することは、以下を戻すことができる：
・  正常終了、
・  警告、例えば別のユーザによりなお開かれるポートフォリオを伴う正常終了
・  不十分な権利、
・  ポートフォリオが、存在しない、
・  名前の競合、
・  データ確認障害、
・  トランザクション・タイムアウト、
・  詳細不明のシステム障害、など、
戻りステータスを処理する方法は、APIが対話型アプリケーションまたはバッチ・ジョブにおいて呼び出されるか否かに依存して異なる。それは、また、バージョンからバージョンへと異なる可能性がある。
【０２１１】
単一の誤り条件は、複数のビューを有する可能性がある。例えば、データ確認障害のビューは、以下を含む可能性がある：
・  記述的なメッセージと共にエラーを訂正するエンド・ユーザに対するプロンプト、
・  デバッグを容易にする完全なスタックトレース・ログ、
・  システム・ログの入力、
・  電子メールによる自動的に生成された管理アラート、など
これらのビューのシーケンスおよび実際のプレゼンテーションは、時間とともに明らかに変化する。より多くのビューは、また、加えられることができる。
【０２１２】
したがって、Business Object Layerによりスローされる例外を直接キャッチするような、物理的に組み込まれた例外処理メカニズムは、扱いにくく、およびコードを維持するために難しい結果になる。
【０２１３】
例外処理のためのテンプレート・メカニズム
Front Endは、例外的な条件を処理するためのテンプレート・メカニズムを使用する。正常終了状態は、まさに1つの可能な状態である。
【０２１４】
修復性に基づき、Front Endは、例外の2つの基本的なカテゴリを識別する。
【０２１５】
エラー(Error)
エラーは、致命的、かつ再開不可能であると考えられる。エラーは、クリティカル・システム障害および予期しないアプリケーション障害の両方を含む。
【０２１６】
デフォルト動作は、ユーザに通知して、システム・ログに書き込み、および現行のリクエストを中止することである。
【０２１７】
例外(Exception)
例外は、予想され、かつおそらく再開可能である。例外的な条件およびハンドラは、テンプレートのリストに記載されている。テンプレートは、コンテクストおよびプレゼンテーション情報の両方を例外処理に提供する。
【０２１８】
デフォルト動作は、テンプレートで定義される関連するハンドラを呼び出すことである。
【０２１９】
モジュール
エンジン
サーブレット・エントリポイント
概観
全ての入って来るURLリクエストは、単一のサーブレットにマップされる。サーブレット・エントリポイントは、リクエストされたアプリケーション・セッションを確認する役割を果たす。確認結果に従い、リクエストはURL Request Processorに転送されるまたは、ユーザは認証のために促される。
【０２２０】
リクエスト処理エンジンへのリクエストのパス
ハウスキーピング関数、例えばブラウザの嗅ぎ分けの実行
基準
J2EEプラットフォームは、2つの重要なコンテナ、サーブレット・コンテナ、およびEJBコンテナを定義する。HALは、ほとんどのHTTPプロトコルおよびコミュニケーション詳細を処理するために、サーブレット・コンテナに依存する。HAL、および残りのアーキテクチャは、配置および生産コストの実質的な節約をもたらすべきである、EJBコンテナにより提供される任意のサービスに依存しない。URLリクエスト・プロセッサ
URLリクエスト・プロセッサは、入って来るリクエストを処理する役割を果たす。それは、2つのタイプのリクエストを識別する。
【０２２１】
BOLを呼び出さずに処理されることができるリクエスト。
【０２２２】
具体例は、あらかじめ実行依頼された長時間にわたるリクエストのステータスチェック、進行中リクエストのキャンセル、マルチ・ページ・フォームへの実行依頼、または、結果デリバリ確認を含む。パフォーマンス目的のために、この種のリクエストを処理することは、短絡させられる、すなわちインフラストラクチュアのイベント・ディスパッチング・メカニズムを経由しない。
【０２２３】
BOLを呼び出すことにより処理されることを必要とするリクエスト。
【０２２４】
具体例は、認証、リスク分析および報告、インポート／エクスポート、管理リクエスト、などを含むこの種のリクエストは、BOLイベント・ディスパッチング・メカニズムを経由する。
【０２２５】
エンジン(Engine)
Engineは、処理リクエストのためのコントローラである。Engineオブジェクトの存続期間は、入力サーブレットと一致する。
【０２２６】
2006516166.tif 000015
WorkItem
WorkItemは、リクエストおよび結果を一緒にリンクする。それは、リクエストを処理するために実行の論理スレッドに対するコンテクストを提供する。
【０２２７】
ユーザは、ブラウザ上のバック、フォワード、ストップボタンをクリックすることができる、またはレスポンスが配信される前に、別のサイトにナビゲートすることができることに留意されたい。最悪の効果は、ユーザがブラウザ・ウインドウを閉じることに等しい。
【０２２８】
2006516166.tif 000016
2006516166.tif 000017
WorkSet
WorkSetは、WorkItemsのための簡単な集合インターフェースである。WorkSetの存続期間は、アプリケーション・セッションである。現行の必要条件は、セッションにつき1つのアクティブなWorkItemsを可能にするのみである。
【０２２９】
2006516166.tif 000018
Result
Resultは、ビジネスAPI呼び出しからの結果をカプセル化する。BOL結果のワイヤ・フォーマットは、SOAPメッセージである。Resultは、基礎をなすデータを操作するための便宜を意図される。
【０２３０】
Resultオブジェクトは、API呼び出しの戻りステータスを示すステータスCodeを有する。ステータスコードの列挙法は、EVENT定義のリストに記載されている。結果オブジェクトは、実結果、部分的結果または例外的な条件を含む可能性がある。対応するフォーマッティング・オブジェクトは、正しくコンテンツを解釈する役割を果たす。
【０２３１】
2006516166.tif 000019
ResultBundle
ResultBundleは、Resultオブジェクトの簡単な集合インターフェースである。ResultBundleのワイヤ・フォーマットは、マルチパートMIMEデータストリームである。ResultBundleは、基礎をなすデータを操作するための便宜を意図される。
【０２３２】
2006516166.tif 000020
Event ControllerおよびDispatcher
Event ControlleおよびDispatcherは、主にEventおよびEventBundleインスタンスのインスタンスを生成する役割を果たす。それは、また、BOLおよびインフラストラクチュア・イベント・ディスパッチング・メカニズムにインターフェースする。
【０２３３】
EventFactory
EventFactoryは、Eventインスタンスのインスタンスを生成する役割を果たす。EventFactoryの存続期間は、Engineと一致する。イベント作成の速度を最大にするために、以下の最適化が、実施される：
・  直接のDOMクローニング
・  インスタンス・リサイクルおよびプーリング・メカニズム
・  直列化最適化
2006516166.tif 000021
Event
Eventオブジェクトは、API呼び出しを完了するために、以下を含む必要な情報を伝える：
・  GUID;
・  パラメータ名および値;
・  リクエストされたリターン・アイテム;
・  同期してディスパッチするか否かを示すフラグ;
・  現行のイベント状態を示すフラグ。
【０２３４】
BOLイベントに対して、SOAPエンベロープ構造は、BARRA_SOAPという名前をつけられた特別なパラメータにより識別される。
【０２３５】
2006516166.tif 000022
【０２３６】
EventBundle
EventBundleインターフェースは、主にイベントの集合インターフェースである。
【０２３７】
2006516166.tif 000023
EventHandler
EventHandlerは、イベント・ディスパッチングのための共通インターフェースを定義する。同期イベント・ディスパッチングに対して、実行コンテクストは、サーブレット・スレッドである。EventHandlerがステートレス・セッション・ビーンに類似のセマンティクスを有するので、簡単なプーリング・メカニズムはEventHandlerクラスの最も多くのタイプに対して実施されることが可能である。
【０２３８】
2006516166.tif 000024
BOLEventHandler
BOLEventHandlerは、イベントではなくEventBundlesをディスパッチする。
【０２３９】
2006516166.tif 000025
そのBOL等価物は、完全性のために本明細書にリストされる。インターフェースの最終的な署名および実施は、BOLにより決定される。
【０２４０】
2006516166.tif 000026
2006516166.tif 000027
BOLは、EventBundleをローカルで、またはリモートの何れかで処理するべきかに関する決定を行う。一般に、バンドルの任意のイベントがリモートで処理されることを必要とする場合、BOLは、リモートでEventBundleを処理する。dispatch()メソッドは、修復可能条件のための例外をスローする。FailedToAcquireResourceのみが、従来、識別される。HALは、ユーザにサーバがあまりに忙しいことをを示す前に、例外をキャッチし、および数回以上dispatch()を再試行する。SOAP FAULTメッセージは、他の条件、例えば、進行中、クライアントエラー、サーバーエラーのために戻される。
【０２４１】
非BOLイベントのディスパッチ
イベント・ディスパッチングは、ブロッキングまたはノンブロッキングの何れかである。ブロッキングは、ディスパッチ・メソッドが戻るまで、サーブレット・スレッドが、ブロックされることを意味し、それは、通常、望ましくない。別々のディスパッチ・スレッドは、非同期で非BOLイベントをディスパッチするために、便利なメカニズムとして使用されることができる。コンボイ(convoy)問題に起因する待ち時間は、Windows(登録商標) NTの場合、〜10 msである。それは、異なるカーネル・スケジューリング方針に起因する他のプラットフォーム場合より、ずっと少ない。
【０２４２】
セッション
一般に、セッション範囲を有するオブジェクトは、同期問題に対して検討されることを必要とする。セッション・パーシステンス・メカニズムの選択は、妥当と思われる使用シナリオを考慮する必要があり、および定量化可能なパフォーマンス目標を定義する必要がある。
【０２４３】
SessionManager
SessionManagerは、セッション・インスタンスを作成、除去、位置づけ、および移動する役割を果たす。リーパ・スレッドは、周期的に期限切れのセッションを除去する。セッションを格納することに関するアプリケーション・サーバにおいて普及している設計は、メモリ常駐のキャッシュを使用することであり、それはその複製グループ内で繰り返される。フォールトトレランスのために、通常、2つの物理的サーバが、各複製グループのために必要とされる。
【０２４４】
2006516166.tif 000028
2006516166.tif 000029
セッション
2006516166.tif 000030
2006516166.tif 000031
【０２４５】
効用
GUIDGen
2006516166.tif 000032
LRU方針を有するWeakHashMap
java.util.WeakHashMapと類似している。最少使用頻度アイテムは、まず破棄されるであろう。
【０２４６】
BrowserCapabilities
2006516166.tif 000033
HttpPostedFileHandler
HttpPostedFileHandlerは、ユーザ・アップロードされたファイルへのアクセスを提供する。アクセプタを送っているHTTPにより呼び出されるように、実施は、JNIインターフェースを提供するものとする。
【０２４７】
2006516166.tif 000034
MimeEncoderおよびMimeDecoder
極めて大きいMIMEデータ・セットを効率的に処理することができる標準実施を見つけ出す。
【０２４８】
HttpHeaderWriter
例えばブラウザ・キャッシング動作を制御するために、ブラウザ特定のHTTPヘッダを書き込む。
【０２４９】
SmtpHandler
MIMEアタッチメントをサポートするフリーなJAVA(登録商標)実施を見つけ出す。
【０２５０】
SoapSerializer
SOAPEncoding直列化ヘルパー・クラス。
【０２５１】
2006516166.tif 000035
TemplateFactory
TemplateFactoryは、解析されたテンプレート・ページ定義、イベント定義、および結果データ・ディクショナリの弱いキャッシュを維持する。テンプレート定義のためのリクエストがキャッシュから満たされることができない場合、テンプレート・ファクトリは持続記憶からそれを取り出す。
【０２５２】
TemplateFactoryインターフェースは、テンプレートおよび関連した構成情報へのアクセスを提供する。それは、基礎をなす持続メカニズムをカプセル化する。解析された定義の弱いキャッシュは、パーシステンス・マネージャを呼び出す前に参照される。EntityおよびEventおよびデフォルト・ページ定義は、アプリケーション起動時間でプレインストールされる。
【０２５３】
2006516166.tif 000036
PageDefinition
PageDefinitonインターフェースは、解析されたPAGE定義へのアクセスを提供する。
【０２５４】
2006516166.tif 000037
EventDefinition
EventDefinitonインターフェースは、解析されたイベント定義へのアクセスを提供する。
【０２５５】
2006516166.tif 000038
ResultDictionary
ResultDictionaryインターフェースは、解析された結果データ・ディクショナリへのアクセスを提供する。結果データ・ディクショナリは、BOLデータ・ディクショナリのビューである。それは、呈示次第、関連情報を強調する。物理的に、それは、一組の別々のXMLファイル、各BOLオペレーションのための1つとして格納されている。
【０２５６】
2006516166.tif 000039
2006516166.tif 000040
TemplateProcessor
TemplateProcessorインターフェースは、ページ・テンプレートを処理するためのベースインターフェースである。派生されたインターフェースは、Formatter、XSLTProcessor、JspInclude、Form、などを含む。
【０２５７】
2006516166.tif 000041
レイアウト
レイアウト・モジュールは、テンプレート定義のレイアウト命令を処理する役割を果たす。それは、所望のレイアウト構造を実施する対応しているjavascriptおよびHTMLフラグメントを生成する。レイアウト命令は、ネストにすることが可能である。ネストにされたレイアウト命令の範囲セマンティクスは、変化するJAVA(登録商標)のそれと類似している。
【０２５８】
LayoutHandler
LayoutHandlerは、レイアウト構造要素を生成するための共通の呼び戻しインターフェースを定義する。3つの基本的なレイアウト・イベントは、以下のように定義される：
・  startLayout：スタート・タグ、例えば<table>を生成する
・  doLayout：本体タグ、例えば<tr><td>を生成する。
【０２５９】
・  endLayout：エンドタグ、例えば</table>を生成する
テンプレート・ページにおいてリストされた位置および幾何学パラメータが、a)パーセンテージ、b)ピクセル、またはc)絶対単位とすることが可能である。
【０２６０】
2006516166.tif 000042
レイアウト・バインディング
レイアウト・バインディングは、ページ・テンプレート定義のレイアウト属性により指定される。
【０２６１】
2006516166.tif 000043
ナビゲーション
ナビゲーション・モジュールは、テンプレート・ページにおいて宣言されたナビゲーション構造を解釈し、および所望のルックおよびナビゲーションの動作を実施するjavascriptおよびHTMLフラグメントを生成する役割を果たす。ナビゲーションは、ナビゲーション構造を説明するための共通インターフェースを定義する。それは、ナビゲーションリンク・アイテムに集合インターフェースを有する。toHTML()を呼び出すことによって、リンク・アイテム集合の走査が生じ、およびブラウザ中立（可能ならば）javascriptおよび所望の動作を実施するHTMLフラグメントを出力する。
【０２６２】
2006516166.tif 000044
2006516166.tif 000045
LinkItem
LinkItemは、ハイパーリンクを説明するための共通インターフェースを定義する。プレゼンテーションは、バインディング-特定の属性に関連させられ、および派生されたインターフェースに定義される。
【０２６３】
2006516166.tif 000046
【０２６４】
ナビゲーション・バインディング
ナビゲーション・バインディングは、ページ・テンプレート定義のナビゲーション・ノードにより指定される。
2006516166.tif 000047
2006516166.tif 000048
【０２６５】
プレゼンテーション
表示モジュール（図8を参照）は、テンプレート定義のプレゼンテーション命令を実行する役割を果たす。3つの基本的なプレゼンテーション・メカニズムがある：
・  XHTML、XML、XSL FOおよびCSVフォーマットにXML結果セットを変換する
ことを意図されるXSLTトランスフォーメーション
・  jspページ／サーブレットからの出力、生成グラフまたは特別トランスフォーメーシ
ョンを含むことを意図されるjspページ／サーブレットからの出力、
・  ブラウザ・サポート・クライアントサイドXMLトランスフォーメーションを意図さ
れたXML passthrough。
【０２６６】
ネイティブ結果フォーマットとしてXMLを使用する背後の動機付けは、以下を含む：
・  XSLTトランスフォーメーション技術のバンド幅は、許容可能なレベル（〜
400KB/CPU）に改善し、かつ改善し続けている。
・  データは、APIである。内部および外部の両方の使用のために、拡張かつ維持する
より小さいインターフェース。
・  データ操作APIおよび言語は、モジュール構造設計目標とよく適合するW3C標準
である。
・  それは、可能なパイプラインで転送されたレンダリングを行う。
【０２６７】
フォーマッタ
フォーマッタは、JAVA(登録商標)フォーマッティング・クラスのための共通インターフェースを定義する。
2006516166.tif 000049
【０２６８】
派生インターフェース
2006516166.tif 000050
【０２６９】
XSLTFormatter
XSLTFormatterは、XMLコンテンツを変換するために、編集されたまたは独立型XSLTスタイル集を使用する。いくつかのXSLTFormattesは、レンダリングパイプラインを形成するために、一緒に使用されることができる。例えば、セットされるXML結果は、XHTMLグリッド出力に最初に変換される。出力は、次に、第2のフォーマッタに送られる。そして、それは代替パターンにグリッドの背景表示色を変化させる。別の具体例に対して、フォームマークアップは、フィールドがユーザ入力データで満たされるXHTMLフォームに、最初に変換される。フォームは、確認エラーをハイライトするために、再び変換される。
【０２７０】
パイプライン処理セマンティクスは、ペイントオーバー(paint-over)である、すなわち新しく適用されるスタイルが、既存のスタイルを上書きする。
2006516166.tif 000051
【０２７１】
PassThroughFormatter
PassThroughFormatterは、入力ストリームを直接出力にパスする。
XSLTスタイル集uriがセットされる場合、PassThroughFormatterはXML結果に参照を挿入する。ブラウザは、XSLトランスフォーメーションをサポートしなければならない。
【０２７２】
2006516166.tif 000052
2006516166.tif 000053
PagedResult
PagedResultは、ページに分けたビューを実施するBOL結果オブジェクトをおおうラッパである。基礎をなす記憶は、ファイルまたはXMLストリームの何れかであることができる。
2006516166.tif 000054
【０２７３】
特別な出力フォーマット
全ての特別な出力フォーマットは、非JAVA(登録商標)コンポーネントを使用して生成されることが可能であり、以下を提供する：
・  非ジャバ・サードパーティ・パッケージは、取替不能な機能性を提供する、または
・  非ジャバ・サードパーティ・パッケージは、ジャバ・カウンタ一部に対する実質的な価格／パフォーマンス比優位を提供する。
【０２７４】
・  非ジャバ・サードパーティ・パッケージは、より使いやすいAPIを有する。
【０２７５】
非ジャバ・パッケージがJNIインターフェースを提供しない場合、それは、プロセスから離れて、使用されるものとする。利点がかなりコストを上回らない限り、カスタムJNIラッパを拡張し、かつ維持することは賛成されない。
【０２７６】
フォーム
Model-View-Controller(モデル‐ビュー-コントローラー)
Formsモジュールの設計は、フォームのデバイス・インディペンデント・マークアップの方向へ動く一般的な業界傾向に従う。設計は、古典的Model-View-Controllerパターンに従う：
・  フォームのモデルは、そのデータ、処理論理回路および確認制約である。
【０２７７】
・  ビューは、具体的なインターフェース表示である。
【０２７８】
・  コントローラは、フォーム・テンプレート・プロセッサである。それは、中間状態を持続すること、さまざまなフォーマットの中のデータを変換すること、マルチ・ページ・フォームの次／前のページをロードすることなどのようなハウスキーピングタスクを実行する。
【０２７９】
MVC設計の利点は、主にプレゼンテーションから目的の分離である。プレゼンテーション・デバイスの能力の大きな相違により、この場合ブラウザには、複雑なビューの実施における重大なダイバージェンスがある。したがって、ブラウザ差の影響を局所化するためにいくつかの抽象概念を導入することは、必要である。導入される抽象概念は、最低限で保持される。言い換えると、設計は、簡単なことを簡単に保持しようとし、および難しいことを容易にする。
【０２８０】
フォーム要素
簡単なフォームは、HTMLフォームとして表される。複雑なフォームは、XMLマークアップで表され、およびランタイム時にXHTMLフォームまたはAWTアプレットの何れかに拘束される。
【０２８１】
基本要素
2006516166.tif 000055
隠蔽フィールド
隠蔽フィールドに従うことは、フォーム・テンプレート・プロセッサにより複雑なフォームの各ページに挿入される可能性がある、
2006516166.tif 000056
【０２８２】
フォーム
フォーム・インターフェースは、サーバーサイド・フォーム処理のために必要とされるプロパティおよびメソッドを定義する。フォーム・インスタンスが初期化されるとき、それは、XHTMLまたはAWTの何れかに拘束される。XHTMLに拘束されるとき、process()メソッドは、XHTMLおよびjavascriptフラグメント、おそらく、ブラウザがサポートできる最も高水準のHTMLおよびjavascriptとしてフォームを書き込む。スクリプトは、以下を含むクライアントサイド動作を実施するために、DOMイベント・モデルにフックする：
・  DOM操作、
・  データ確認および変換、
・  強調表示、
・  フォーム要素の隠蔽／表示、
・  ポスティング、
・  サーバーサイド動作が必要でない場合制限された計算。
【０２８３】
AWTに拘束されるとき、process()メソッドは、アプレット初期化パラメータとして、またはアプレット初期設定メカニズムに特有な専用のフォーマットとしてフォームを書き込む。
【０２８４】
2006516166.tif 000057
2006516166.tif 000058
【０２８５】
MultiPageForm
マルチ・ページ・フォームは、Previous/NextボタンおよびNumericalリンクの何れによってもナビゲートされる。MultiPageFormのため意図された使用のうちの1つは、インターフェースのwizard-typeをサポートすることである。
2006516166.tif 000059
【０２８６】
FormElement
FormElementインターフェースは、フォーム要素マークアップの詳細を公開する。
2006516166.tif 000060
2006516166.tif 000061
【０２８７】
FormState
確認エラーが発生しない最も自明なフォームを除いて、フォーム状態は、HTTPリクエスト間で持続される必要がある。フォーム状態は、効率的な直列化フォーマットでFormStateオブジェクトにおいて格納されるものとする。FormStateオブジェクトが、フォーム依頼の実行の論理スレッドである存続期間、基礎をなすWorkItem.で具体化される
2006516166.tif 000062
2006516166.tif 000063
【０２８８】
FormStateItem
2006516166.tif 000064
【０２８９】
Toolbox
Toolboxモジュールは、スタイル集、位置決めヘルパー、グラフィックス、データ確認、および変換ルーチン、などを含むUIキャンディの集合にインターフェースを公開する。
【０２９０】
パッケージング
メンテナンス・オーバーヘッドおよび節約しているバンド幅を減らすために、再使用可能なツールは、別々のファイルとしてパッケージ化されるものとする。例えば、再使用可能なjavascriptファイルが、以下のように参照されるものとする：
2006516166.tif 000065
【０２９１】
StyleTools
2006516166.tif 000066
【０２９２】
GraphicsTools
グラフィックス・リソース、例えばナビゲーションGIF、アイコン、ロゴ、などにアクセスするためのルックアップ・インターフェース
2006516166.tif 000067
【０２９３】
ConversionTools
データ変換ルーチン、例えばクライアントサイド日付フォーマッティング、数フォーマッティング・スクリプト、などにアクセスするためのルックアップ・インターフェース
2006516166.tif 000068
【０２９４】
ValidationTools
データ確認ルーチン、例えば数値的な入力確認、データ範囲確認スクリプト、などにアクセスするためのルックアップ・インターフェース
2006516166.tif 000069
複雑なUI要素
以下のブラウザUI要素は、必要である。実施は、再利用を容易にするためにパラメータで表されるものとする。
【０２９５】
2006516166.tif 000070
アプリケーション
Applicationコンポーネントは、Framework、BOLおよびシステム機能要件を実施するインフラストラクチュア・サービスの上に構築された一まとまりのアプリケーションモジュールである。Applicationコンポーネントは、ワークフローおよびERPアプリケーションにより最初に普及されたデータ駆動型設計パターンを採用する。具体的には、アプリケーション・ワークフローおよびプレゼンテーション命令は、テンプレートとしてモデル化される。テンプレートは、大部分は宣言部分である。それが、階層的であり、および高品質のXMLパーサが容易に利用可能であるので、XMLはバインディングに選ばれる。
【０２９６】
SOAPバインディング
SOAP Encodingは、BOL API呼び出しおよびレスポンスのためのワイヤ・プロトコルとして使用される。例えば、BOLイベントは、以下である：
2006516166.tif 000071
【０２９７】
マルチパートMIME
BOL API呼び出しは、イベント・ディスパッチングによる。イベントは、バンドルにおいてディスパッチされる。結果は、バンドルにおいて戻される。EventBundleおよびResultBundleの両方は、マルチパートMIMEデータストリームとして符号化される。BOLイベント／結果バンドルのワイヤ表示は、以下の通りである
2006516166.tif 000072
【０２９８】
PAGE定義
Page定義は、ページの構造、ナビゲーション、コンポジション、例外処理およびプレゼンテーションに関する情報を含む。個人化は、ページ定義にオーバーライドすることにより達成される。ユーザ・オーバライドは組織的オーバーライドに優先し、次にAraneaeデフォルトに優先する
定義
2006516166.tif 000073
2006516166.tif 000074
2006516166.tif 000075
【０２９９】
具体例
2006516166.tif 000076
【０３００】
EVENT定義
Event定義は、Business Object Layerにより公開されるAPI関数を説明する。それは、3つのメイン部を含む：
・  戦略オーバーライド、ポートフォリオ・コンテクストを含んでいる入力パラメータ
・  groupbyおよびsortbyクローズを含んでいる出力パラメータ、
・  リターン結果参照。
【０３０１】
リターン・ステータスコードのハンドラは、ページ定義において説明されるリストに記載されている。明示的に宣言されたハンドラを有しないステータスコードのために、デフォルト・ハンドラは、使用される。
適切なグラニュラリティでイベントを定義することは、重要である。
【０３０２】
定義：
2006516166.tif 000077
2006516166.tif 000078
2006516166.tif 000079
2006516166.tif 000080
【０３０３】
具体例
2006516166.tif 000081
2006516166.tif 000082
【０３０４】
結果データ・ディクショナリ
Result Data Dictionaryは、BOLデータ・ディクショナリ上のビューである。それは、BOL結果を解釈し、かつ提示するために必要なデータのタイプおよび他の情報をリストする。
【０３０５】
定義：
2006516166.tif 000083
【０３０６】
具体例
2006516166.tif 000084
2006516166.tif 000085
【０３０７】
特別な定義
Datatypes
Datatypesは、BOLデータ・ディクショナリのデータタイプ定義部上の特別なビューである。以下のスキーマ定義として参照される上述のテンプレート具体例。
2006516166.tif 000086
【０３０８】
BOL例外
BOL Exceptionは、修復可能BOL故障条件の詳細を説明する。最も見込みのある誤り理由は、クライアントエラーによる。BOL例外は、（ワイヤ表示において）以下のように見える、
2006516166.tif 000087
2006516166.tif 000088
【０３０９】
モジュール
一般的なプロセス・フロー
図9は、機能モジュールの典型的な処理フローを示す。実行の論理スレッドは、クライアントサイドおよびサーバーサイド・アクティビティから成ることに留意されたい。確証セッション、構文解析テンプレート、ディスパッチング・イベント、集合結果およびロギング・アクティビティのような一般アクティビティは、Frameコンポーネントにより処理される。モジュール特定のアクティビティは、テンプレート定義において説明され、および一般的な、または専門のテンプレート・プロセッサのいずれかにより実行される。機能モジュールの実施は、主にデータおよびプレゼンテーション・モデル化の実行である。各モジュールのために、実施が開始する前に、以下を定義する：
・  イベント定義、
・  もしあれば、結果フォーマットおよびデータ・ディクショナリ、
・  ページ定義、
・  モジュール特定のセッション変数、
・  もしあれば、特別なプレゼンテーション必要条件、
・  もしあれば、モジュール特定の誤りハンドラ、
【０３１０】
SOAP
SOAP (Simple Object Access Protocol, http://www.w3.org/TR/SOAP/)は、XMLベースの軽量の通信プロトコルである。それは、2つのメイン部：SOAP Envelope（アプリケーション層プロトコル）およびSOAP Encoding（プレゼンテーション層プロトコル）を有する。この設計文書は、アプリケーション定義されたデータ型のインスタンスを示すために、並びに、BOL呼び出しおよびレスポンスを表すためにSOAP Encoding規則を採用した。SOAPメッセージは、基本的に送信者から受信器への片方向転送であって、およびリクエスト／レスポンスのようなパターンを実施するために、しばしば組み合わせられる。
【０３１１】
文法
SOAPメッセージは、必須SOAPエンベロープ、オプションのSOAPヘッダ、および必須SOAPボディから成るXMLドキュメントである。それは、全ての要素および属性に関する適切なSOAP名前空間を含まなければならず、およびDTDまたはXML処理命令を含んではならない。
【０３１２】
エンベロープ(Envelope)
要素名は、「Envelope」である。要素は、SOAPメッセージに存在しなければならない。要素は、名前空間宣言、並びに追加的な属性を含んでもよい。もし存在するならば、このような追加的な属性は、名前空間修飾されなければならない。同様に、要素は、追加的なサブ要素を含んでもよい。もし存在するならば、これらの要素は、名前空間修飾されなければならず、およびSOAP Body要素に従わなければならない。
【０３１３】
ヘッダ(Header)
要素名は、「Header」である。要素は、SOAPメッセージに存在してもよい。もし存在するならば、要素は、SOAP Envelope要素の最初に直属の子要素でなければならない。要素は、各々がSOAP Header要素の直属の子要素である一組のヘッダ入力を含んでもよい。SOAP Header要素の全ての直属の子要素は、名前空間修飾されなければならない。Header属性は、SOAPメッセージの受信者がそれを処理すべき方法を指示するために使用されることができる。例えば、SOAPは、ヘッダ入力が受信者が処理するために必須またはオプションかを示すために、グローバルな属性が使用されることができることを理解しなければならない。
【０３１４】
ボディ (Body)
要素名は、「Body」である。要素は、SOAPメッセージに存在しなければならず、およびSOAP Envelope要素の直属の子要素でなければならない。それは、もし存在するならば、直接SOAP Header要素に従わなければならない。そうでない場合は、それは、SOAP Envelope要素の第1の直属の子要素でなければならない。要素は、各々SOAP Body要素の直属の子要素である一組のボディエントリーを含んでもよい。SOAP Body要素の直属の子要素は、名前修飾されてもよい。SOAPはSOAP Fault要素を定義し、それはエラーメッセージを示すために使用される。本体要素は、SOAPメッセージ、例えばRPCパラメータまたはエラー報告のペイロードを伝える。SOAP Fault要素は、SOAPメッセージ内でエラーおよび／またはステータス情報を伝えるために使用される。もし存在するならば、SOAP Fault要素は、本体エントリとして現れなければならず、およびBody要素の中で二回以上現れる必要はない。Fault要素は、4つのサブ要素：faultcode、faultstring、faultactor、detailを定義する。
【０３１５】
SOAP Encoding（SOAPエンコーディング）
SOAP型システムは、プログラミング言語、データベースおよび半階層データのタイプ・システムにおいて見つけ出される共通機能の総合である。タイプは、単純（スカラー）型である、または各々タイプを有するいくつかのパートのコンポジットとして、構成される複合型である。
【０３１６】
単純型
単純型に対して、SOAPは、「XML Schema Part 2: Datatypes」 Specificationのセクション「組み込みデータ型(Built-in datatypes)」において見つけ出される全ての型、値および語彙スペースの両方を採用する。
【０３１７】
複合型
SOAPは、2つの構造パターンを可能にする。
SOAP配列は、JAVA(登録商標)オブジェクト配列のようにふるまう。配列は、arrayType属性を用いて特に制限されない限り含まれることが可能である型の任意の混合を含んでもよい。SOAPは、また、多次元配列、スパース配列、および部分的に送られた配列のための符号化規則を定義する。詳細のための仕様を参照されたい。SOAPの現行の実施のいずれも、全てのSOAPを符号化規則をサポートしないことに留意することは、重要である。目的のために充分な最も単純なデータ構造を使用することは、賢明である。
【０３１８】
セッション実施
セッションはクラスタ環境において上手にふるまわなければならない、例えば、状態はクラスタ要素の中ですばやく移動することが可能でなければならない。セッションは、メモリベース、ファイルベース、DBMSベース、またはこれらの混合となることができる、その状態管理メカニズムをカプセル化しなければならない。セッションは、その分割しているメカニズムをカプセル化しなければならない。セッションIDは、セション状態を位置づけることを必要とする唯一の識別子である。状態の物理的位置は、カプセル化されるものとする。セッションは、故障許容でなければならない。サーバが故障するとき、セション状態の分割は利用可能なままでなければならない。
【０３１９】
オブジェクト直列化
戦略に従うことは、ジャバのオブジェクト直列化を強化するために使用されることが可能である：
・  readObject() / writeObject()にオーバーライドする
・  バイト・ストリームに出入りする型の変換のためのJNIを使用する
・  スリムな型の情報を書き込む
・  より良いストリームバッファリングを使用する
・  オブジェクト直列化のためのJDKにより使用された内部のハッシュ・マップの動作にオーバーライドする
これらの組合せは、デフォルト直列化にわたって概略速度改善を達成することができる。
【０３２０】
BOL
BOLの範囲は、THE SYSTEMのビジネス論理の全てを含む。それは、また、それ自身の実施に特有ないくつかのインフラストラクチュアを含む。それは、一般的なインフラストラクチュア・サービスおよびプレゼンテーションを除外する。
【０３２１】
背景モデムまたはコンピュータのオペレーションに対するサーバ。
【０３２２】
アーキテクチャ
図10は、BOLのコンポーネントの物理的配置およびHAL、PersistenceおよびInfrastructureサービスとそれらのインタラクションを示す。
【０３２３】
RPCインフラストラクチュア
このコンポーネントは、リモートEventBundle呼び出し、および進行モニタリングを管理する役割を果たす。
【０３２４】
コンポーネント
図11は、2種類の関係 ― 依存度（矢印は、「依存する」を意味する）およびコンテインメント（ネスティングにより示される）を示す。
【０３２５】
2006516166.tif 000089
【０３２６】
BDT API：BDTは、HALにより呼び出されるインターフェースを公開する。Hosted Implementationのユーザは、また、これらのインターフェースを呼び出すことも可能であるが、彼等は、メソッド・ベースである代替インターフェースを呼び出す可能性がより大きい。（Public BDT API, TBD）。
【０３２７】
bdt proxy：bdt proxyは、ローカルおよびリモートの両方の、RPCインフラストラクチュアを介した非同期評価のために、Event Bundlesを分析する。
【０３２８】
bdt.eventinterpreter：bdt.datadictionaryと共に依存構造解析法を使用することにより、イベントを評価する方法を決定し、および集約メソッドのような属性を解釈する。ユーザ定義の方式もまた、このコンポーネントの責任である。
【０３２９】
bdt.evaluation：イベントのグラニュラリティで公開のメソッド実施、およびグラニュラリティのより細かいレベルでプライベートの実施を含む。イベントは、RPCインフラストラクチュアに属しているスレッドにおいて評価される。
【０３３０】
bdt.session：bdt.sessionは、Persistent Session Stateの存続期間を管理し、およびそれへのアクセスを提供する役割を果たす。
【０３３１】
bdt.result：このコンポーネントは、（cursoredやその他）resultsetsおよび進行モニタリングを管理する役割を果たす。
【０３３２】
bdt.datadictionary：このコンポーネントは、リクエストにおいて参照され、およびbdtインターフェースに結果としてなるデータ・アイテムの定義を提供する。
【０３３３】
bdt.strategy：bdt.strategyは、戦略として定義される情報を管理し、および戦略デフォルティング規則を実施する。
【０３３４】
ai (analytic interfaces)：分析インターフェース。分析ルーチンで使用される全てのデータ抽象化を表す一組のインターフェース。
【０３３５】
BDT API
BDT APIは、BOL層に対するエントリの唯一のポイントである。
【０３３６】
Event BundleおよびResult Bundleは、両方とも、MIMEを符号化する。GUID（HALにより生成される）は、Event Bundleのカスタム・ヘッダに格納される。このGUIDは、getProgress()およびcancel()への呼び出しのEvent Bundleを識別するために使用される。Event Bundleのコンテンツは、SOAP呼び出しである。Result Bundleのコンテンツは、以下の1つである：
・  結果を戻すそれらのSOAP呼び出しに対応する結果のリスト。
・  パーセンテージ完了として、全体のバンドルの進行を報告する1つのSOAPステー
タスメッセージ。
【０３３７】
・  予め決められた障害コードおよび理由のテキスト説明を報告する1つのSOAPステ
ータスメッセージ。
【０３３８】
HALは、送り返されたResult Bundleがエラーまたは結果のリストの何れかを含むまで、dispatch()メソッド、次に、ゼロ回以上、getProgress()メソッドを呼び出す。HALは、最終的なResult Bundleが送り返されていた後で、同じGUIDに対してgetProgress()を呼び出さない。もしエラーが修復可能である、例えば入手不可能な計算リソースならば、HALは、全イベント・バンドルを再試行する。
【０３３９】
bdtプロキシ
bdt.proxyは、bdtインターフェースを実施する。bdtプロキシは、ローカルとリモート評価およびbdt.eventinterpreterの呼び出し間で決めるためにEvent Bundleを分析する役割を果たす。
【０３４０】
bdt.proxyは、上記のように、BDT APIを実施する。
【０３４１】
イベント・ローカリティ(Event locality)
bdt.proxyは、実行時で可変の構成に従って、イベント・バンドルをローカル、またはリモートのいずれかで評価するかを決定する。ローカル対リモートは、Event定義のランタイム構成可能なプロパティである。構成インターフェースは、管理、テスト、およびチューニングのために存在する。このインターフェースは、また、Hosted Araneae Implementationの中に存在する、しかし、それは公開される可能性はない。
【０３４２】
イベント・バンドル分析(Event Bundle Analysis)
Event Bundleは、それらが含むEventの順位付けを定義する。BOLは、任意のイベントがリモートで評価されなければならないか否かを決定するために、Event Bundleを分析する。もし1つ以上のイベントがリモートで評価されなければならないならば、全体のバンドルはリモートで評価される。
【０３４３】
進行モニタリングおよびパーシステンス
bdt.proxyは、結果を持続し、および進行をトラッキングすることと関係するPSSのサブセットにアクセスする。PSSは、優先サーバ、すなわちその新しいリクエストは差別的に導かれるサーバ、および各重要なリクエストのための責任サーバを記録する。もしリクエストがなお進行中である場合、getProgress()メソッドに対する呼び出しは、RMI Infrastructureを介して、責任サーバに導かれる。リクエストが完了した後で、Result Bundleは、持続される可能性がある−この場合、データの全てがPSSにおいて利用可能であるので、getProgress()メソッドに対する呼び出しは、責任サーバを参照せずに履行される。Result Bundleの全ての結果は、最後のgetProcess()呼び出しによって送り返される。結果は、もしそれらが大きいならば、それらを含むResult Bundleに独立して持続される可能性がある。この場合、Result Bundleは、持続格納の結果の位置に参照を含み、およびHALは、それらを消去する役割を果たす。
【０３４４】
HALは、Eventインスタンス毎に格納された名づけられた引数が正しいタイプのあること、および必須引数が存在することを保証するために、Event Definitionsを使用する。Event Handler実施は、実装時間または配置時間で可能である場合、対応するEvent Definitionsに対してチェックされる。
【０３４５】
bdt.eventinterpreter
bdt.datadictionaryと共に依存構造解析法を使用することにより、イベントを評価する方法を決定し、および集約メソッドのような属性を解釈する。ユーザ定義の方式も、また、このコンポーネントの責任である。bdt.eventinterpreterは、Computation Engineにより呼び出される。
【０３４６】
bdt.eventinterpreterが処理するEventsは、実際には、Event Bundleを通過するSOAP呼び出しである。予め決められたQuery Eventsは、評価のための対応するEvent Handlerにディスパッチされる。構成可能なQuery Eventsは、ズーミング動作、集約メソッド、フィルタリングおよびグルーピングのような属性を用いて、必要とされたデータのリストを特定する。bdt.eventinterpreterは、適切なリスク、ルックアップおよび集約オペレーションが実行され、および結果が適切にフォーマット化されることを保証する役割を果たす。
【０３４７】
bdt.evaluation
このコンポーネントは、実際にイベントを評価するコードを含む。これは、実際のビジネス論理である−他の全ては、ライブラリを推測し、またはサポートしている。RPC Infrastructureは、このコンポーネントのメソッドを呼び出す。bdt.evaluationは、CalcRiskSummaryのようなbdt.EventHandlerの実施を含む。これらのクラスは、RiskCalculatorおよびFactorExposuresのようなanalytics.riskのクラスをサポートすることを使用する。このコンポーネントはファクトリ・インターフェースを有する。bdt.proxyまたはbdt.eventinterpreterは、bdt.EventHandlerを実施し、およびinvoke()を呼び出すオブジェクトのインスタンスを生成する。
【０３４８】
bdt.evaluationのクライアントは、bdt.proxyであり、および、bdt.eventinterpreter. bdt.evaluationは、リスク計算を実行するためにanalytics.riskを使用する。
【０３４９】
bdt.session
このコンポーネントは、Persistent Session Stateへのアクセスを管理する。bdt.sessionオブジェクトの存続期間は、ユーザ・ログオンで開始し、およびユーザ・ログアウトまたはセッション・タイムアウトで終了する。言い換えると、それは、HTTPセッションに対応する。正当性のために、ユーザが新しいブラウザ・ウインドウを開くとき、新しいセッションはクローンを作られなければならない、しかし、これは、達成するのが不可能である可能性がある、またはブラウザに不自然な技術を必要とする可能性がある。セッションは、SessionIDsにより識別され、それはログオン時間で割り当てられる。
【０３５０】
bdt.datadictionary
bdt.datadictionaryは、リクエストにおいて参照されるデータ・アイテムの定義を提供し、およびbdtインターフェースに結果としてなる。
【０３５１】
bdt.strategy
戦略設定は、ポートフォリオ、ユーザおよび現行のブラウザ選択と関連している。機能的な仕様は、優先順位の階層に従ってデフォルト値を供給するために規則の複雑な一組を定義する。ユーザがナビゲートするとき、戦略は、変更されなければならず、または再ロードされなければならない。この議論において、「戦略(strategy)」は、（「ポートフォリオ・ツリーノード」のような）1つのソースのために定義される一群の設定を意味する。「全戦略(Total strategy)」は、デフォルティング規則に従って適用可能なソースから全ての戦略を組み合わせる結果を意味する。
【０３５２】
AI（分析インターフェース）
AIパッケージは、JAVA(登録商標)インターフェース定義のみから成る。AIの目的は、BDTのイベントハンドラ実施および分析パッケージ間に、それ以外の場合存在する依存度繰り返しを壊すことである。AIを構成するインターフェースは、データ抽象化、例えばTermsAndConditions、Holding、PortfolioおよびCovarianceMatrixである。
【０３５３】
analytics.risk
リスク計算は、おそらくマトリクス演算のための既製のライブラリの助けを借りて、JAVA(登録商標)においてスクラッチから実施される。それらは、それらが、RPC Infrastructureのスレッド・プールにおいて使用されることができるように、スレッドセーフ(thread-safe)法で実施される。クラスおよびメソッドのグラニュラリティは、ローカルにキャッシュされた中間結果が再利用されることができるように、選択される。
【０３５４】
analytics.optimizer
既存の最適化ライブラリ(OptSrvrnn.dll)が、使用される。オプティマイザが、スレッドセーフでないので、それは一群の別々のプロセスで動作されなければならない。もし最適化がEventのグラニュラリティのレベルにあるならば、それらは、メッセージ・キューにおける最適化としてタグを付けられ、および最適化専用の分析サーバ・プロセスにより評価される。
【０３５５】
analytics.instrument.athena
Athenaライブラリは、キャッシュFlow Instrumentsのための債券ファクタに対して、価格およびエクスポージャを計算する。多くの場合に、通常新しい市場データが利用可能となった後で、CFIの価格およびエクスポージャは、標準的な時間でバッチプロセスにおいて再計算される。
【０３５６】
本発明が好適な実施例を参照して本明細書に説明されるにもかかわらず、当業者は、他のアプリケーションが、本発明の精神および範囲から逸脱することなく、本明細書に記載されるそれらと置き換えされることが可能であることを容易に理解するであろう。したがって、本発明は、添付された請求の範囲により制限されるのみである。
【図面の簡単な説明】
【０３５７】
【図１】本発明に従うポートフォリオ管理およびリスク分析のためのシステムの物理アーキテクチャを示すブロック略線図である。
【図２Ａ】本発明に従うポートフォリオ管理およびリスク分析のためのシステムの論理アーキテクチャを示すブロック略線図である。
【図２Ｂ】本発明に従うポートフォリオ管理およびリスク分析のためのシステムの論理アーキテクチャを示すブロック略線図である。
【図３】本発明に従うポートフォリオ管理およびリスク分析のためのシステムのHTTPアプリケーション層を示すブロック略線図である。
【図４】本発明に従うポートフォリオ管理およびリスク分析のためのシステムのフロントエンドを示すブロック略線図である。
【図５】本発明に従うポートフォリオ管理およびリスク分析のためのシステムのフロントエンド・インターフェースを示すブロック略線図である。
【図６Ａ】本発明に従うポートフォリオ管理およびリスク分析のためのシステムにおけるHTTPリクエストに対するセッション確認を示すフローダイヤグラムである。
【図６Ｂ】本発明に従うポートフォリオ管理およびリスク分析のためのシステムにおけるHTTPリクエストに対するセッション確認を示すフローダイヤグラムである。
【図７Ａ】本発明に従うポートフォリオ管理およびリスク分析のためのシステムにおけるEventBundleモジュールを有するBOL呼び出しを示すフローダイヤグラムである。
【図７Ｂ】本発明に従うポートフォリオ管理およびリスク分析のためのシステムにおけるEventBundleモジュールを有するBOL呼び出しを示すフローダイヤグラムである。
【図８】本発明に従うポートフォリオ管理およびリスク分析のためのシステムにおけるフォーマッティング・メカニズムを示すブロック略線図である。
【図９Ａ】本発明に従うポートフォリオ管理およびリスク分析のためのシステムにおける編集プロファイル・スクリーンに対する処理シーケンスを示すフローダイヤグラムである。
【図９Ｂ】本発明に従うポートフォリオ管理およびリスク分析のためのシステムにおける編集プロファイル・スクリーンに対する処理シーケンスを示すフローダイヤグラムである。
【図１０】本発明に従うポートフォリオ管理およびリスク分析のためのシステムにおけるBDTの物理的配置を示すブロック略線図である。
【図１１】本発明に従うポートフォリオ管理およびリスク分析のためのシステムのBOLコンポーネント関係を示すブロック略線図である。
【符号の説明】
【０３５８】
11  ユーザ・エージェント
12  ウェブ・サーバ
13、14  分析ライブラリ
15  データベース
21  アプレット
22  サーブレット・コンテナ
23  HTTPアプリケーション層
24  ビジネス・オブジェクト層
25  データ・アクセス
26  インフラストラクチュア
【図１】
2006516166.tif 000090
【図２Ａ】
2006516166.tif 000091
【図２Ｂ】
2006516166.tif 000092
【図３】
2006516166.tif 000093
【図４】
2006516166.tif 000094
【図５】
2006516166.tif 000095
【図６Ｂ】
2006516166.tif 000096
【図７Ａ】
2006516166.tif 000097
【図７Ｂ】
2006516166.tif 000098
【図８】
2006516166.tif 000099
【図９Ｂ】
2006516166.tif 000100
【図１１】
2006516166.tif 000101
【図６Ａ】
2006516166.tif 000102
【図９Ａ】
2006516166.tif 000103
【図１０】
2006516166.tif 000104
【国際調査報告】
2006516166.tif 000105