(57)【要約】  一実施形態において、本発明は、ユーザ双方向記録フィールドを伴うワールドワイドウェブアプリケーションを備えた計算システムを開示する。記録フィールドは、記録フィールドエントリーを受け取る。アプリケーションは、コンテクスト変更要求を受け取る。このコンテクスト変更要求に応答して、アプリケーションは、記録フィールドエントリーを、データベースに記憶すべくサーバーへ動的に送信する。
2005516272.tif 000002
【特許請求の範囲】
【請求項１】
記録フィールドエントリーを受け取るためのユーザ双方向記録フィールドを含むワールドワイドウェブアプリケーションを備え、
上記アプリケーションは、コンテクスト変更要求を受け取り、そしてその要求を受け取るのに応答して、上記記録フィールドエントリーを、データベースに記憶すべくサーバーへ動的に送信するように構成された計算システム。
【請求項２】
上記コンテクスト変更は、ワールドワイドウェブブラウザビュー変更を含む請求項１に記載の計算システム。
【請求項３】
上記コンテクスト変更は、アクティブなアプレット変更を含む請求項１に記載の計算システム。
【請求項４】
上記コンテクスト変更は、編集のために選択された記録フィールドの変更を含む請求項１に記載の計算システム。
【請求項５】
上記記録フィールドエントリーを記憶するためのクライアントキャッシュを更に備えた請求項１に記載の計算システム。
【請求項６】
上記アプリケーションは、上記記録フィールドエントリーが上記サーバーへ送信されるまで上記キャッシュに上記記録フィールドエントリーを維持する請求項５に記載の計算システム。
【請求項７】
上記アプリケーションは、上記サーバーとの全クライアント通信を制御する請求項１に記載の計算システム。
【請求項８】
ユーザ双方向記録フィールドを含むワールドワイドウェブアプリケーションを使用することにより記録フィールドエントリーを受け取り、
上記アプリケーションを使用することによりコンテクスト変更要求を受け取り、そして
その要求を受け取るのに応答して上記アプリケーションを使用することにより、上記記録フィールドエントリーを、データベースに記憶すべくサーバーへ動的に送信する、
という段階を備えた方法。
【請求項９】
上記コンテクスト変更要求は、ワールドワイドウェブブラウザビュー変更を含む請求項８に記載の方法。
【請求項１０】
上記コンテクスト変更要求は、アクティブなアプレット変更を含む請求項８に記載の方法。
【請求項１１】
上記コンテクスト変更要求は、編集のために選択された記録フィールドの変更を含む請求項８に記載の方法。
【請求項１２】
クライアントキャッシュを使用することにより上記記録フィールドエントリーを記憶することを更に含む請求項８に記載の方法。
【請求項１３】
上記アプリケーションは、上記記録フィールドエントリーが上記サーバーへ送信されるまで上記キャッシュに上記記録フィールドエントリーを維持する請求項１２に記載の方法。
【請求項１４】
上記アプリケーションは、上記サーバーとの全直接通信を制御する請求項８に記載の方法。
【請求項１５】
プロセッサにより実行されたときに、そのプロセッサが、
ユーザ双方向記録フィールドを含むワールドワイドウェブアプリケーションを使用することにより記録フィールドエントリーを受け取り、
上記アプリケーションを使用することによりコンテクスト変更要求を受け取り、そして
その要求を受け取るのに応答して上記アプリケーションを使用することにより、上記記録フィールドエントリーを、データベースに記憶すべくサーバーへ動的に送信する、
という段階を備えた方法を遂行するようにさせる命令のセットが記憶されたコンピュータ読み取り可能な媒体。
【請求項１６】
上記コンテクスト変更要求は、ワールドワイドウェブブラウザビュー変更を含む請求項１５に記載の媒体。
【請求項１７】
上記コンテクスト変更要求は、アクティブなアプレット変更を含む請求項１５に記載の媒体。
【請求項１８】
上記コンテクスト変更要求は、編集のために選択された記録フィールドの変更を含む請求項１５に記載の媒体。
【請求項１９】
クライアントキャッシュを使用することにより上記記録フィールドエントリーを記憶することを更に含む請求項１５に記載の媒体。
【請求項２０】
上記アプリケーションは、上記記録フィールドエントリーが上記サーバーへ送信されるまで上記キャッシュに上記記録フィールドエントリーを維持する請求項１９に記載の媒体。
【請求項２１】
上記アプリケーションは、上記サーバーとの全直接通信を制御する請求項１５に記載の媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、データ処理の分野に係る。より詳細には、本発明は、ワールドワイドウェブアプリケーション用の非セーブデータを暗示的にコミットするための計算システム及び方法に係る。
【背景技術】
【０００２】
通常、ＣＲＭ実施戦略は、次の項目を考えることが必要である。
−  知識の管理：有効なＣＲＭ実施の重要なファクタの１つは、顧客に関する情報の収集、その分析、共有及び追跡である。又、競争効果に知識を利用することと一体的に、その知識の結果としてどんなアクションがとられるか従業員に分かる。
−  データベース・コンソリデーション：有効且つ効率的なＣＲＭ解決策の別の重要な特徴は、顧客情報を単一のデータベースに合併しそして顧客にまつわるビジネスプロセスをリエンジニアリングすることである。ここでの目標は、顧客との全ての相互作用（対話，interaction）を一箇所に記録し、製造、マーケティング、販売及び顧客サポート活動を推進することである。
【０００３】
−  チャンネル及びシステムの一体化：ＣＲＭアプリケーション／ソフトウェアにとって、ｅ−メールであるか、電話であるか、ウェブベースのユーザインターフェイスであるか等々に関わらず、選択したチャンネルを経て一貫した高品質のやり方で顧客に応答する能力を備えていることが非常に重要である。これには、種々の通信チャンネルを顧客又は企業のデータベースと継ぎ目なく一体化することが必要である。又、ＣＲＭを会社のビジネスシステム及びアプリケーションの他の部分と一体化することも必要となる。
【０００４】
−  技術及びインフラストラクチャー：顧客サービスを向上させるために、ＣＲＭアプリケーション／ソフトウェアは、オンライン顧客サービスを自動化し且つ合理化するための種々のツールを含む。例えば、自己ヘルプモデルは、通常、これらツールの組合せを使用して実施することができる（例えば、直観的サーチ能力、エージェント技術又は自動化ｅ−メール等を伴う知識ベースの）。
【０００５】
一般に、ｅビジネスアプリケーションは、ウェブ、コールセンター、フィールド、転売者、小売店及び卸売業者ネットワークを含む多数のチャンネルにわたり顧客への販売、マーケティング及びサービスを容易にする顧客情報の単一ソースを組織が形成できるように設計される。進歩型のｅビジネスアプリケーションは、通常、コンポーネントベースのアーキテクチャーで構築され、そしてウェブベースであるように設計されると共に、移動クライアント、接続クライアント、シンクライアント、及びハンドヘルドクライアント等々を含む多数の計算プラットホームにおいて種々の形式のクライアントに対してサポートを与えるように設計される。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
最近のウェブ急増に伴い、ウェブベースの環境においてｅビジネスアプリケーションの機能を提供することが望まれる。更に、このｅビジネスアプリケーションは、ウェブベースの環境において、既にユーザに馴染み深いデスクトップベースのｅビジネスアプリケーションのルックアンドフィールを保持するように動作することが望ましい。
ワールドワイドウェブ文書は、ユーザ双方向データフィールドを伴うフォームをしばしば含み、これを経てユーザは情報を入力することができる。情報は、通常、アルファニューメリックキャラクタを含む。エントリーをサーバーデータベースにセーブするために、ユーザは、通常、「セーブ」又は「提示(submit)」と示されたボタンを押圧する。ユーザは、エントリーをセーブしようとするたびに「セーブ」又は「提示」ボタンを押圧しなければならないので、時間がかかり、面倒な上に、不快になる。又、ユーザが情報をセーブする前にウェブブラウザビューをログオフするか又は別のウェブページに切り換える場合には、情報が失われることがある。
【課題を解決するための手段】
【０００７】
一実施形態において、本発明は、ユーザ双方向記録フィールドを伴うワールドワイドウェブアプリケーションを備えた計算システムについて説明する。記録フィールドは、記録フィールドエントリーを受け取る。アプリケーションは、コンテクスト変更要求を受け取る。コンテクスト変更要求に応答して、アプリケーションは、記録フィールドエントリーを、データベースに記憶すべくサーバーへ動的に送信する。
【発明を実施するための最良の形態】
【０００８】
ワールドワイドウェブアプリケーション（「ウェブアプリケーション」）の非セーブデータがコンテクスト変更に応答してサーバーへ暗示的にコミットされる計算システム及び方法について説明する。ユーザは、例えば、セーブボタンを押す必要がない。
この説明において、送信及び配達という語は、交換可能に使用される。又、セーブ及びコミットという語も、交換可能に使用される。非セーブデータ、変更及び更新という語も、交換可能に使用される。
本発明の特徴及び効果は、添付図面を参照した以下の説明から完全に理解されよう。
以下の詳細な説明において、本発明を完全に理解するために多数の特定の細部について述べる。しかしながら、当業者であれば、本発明は、これら特定の細部がなくても理解でき且つ実施できることが明らかであろう。
【０００９】
Ｉ．システムの概要及び全体的アーキテクチャー
一実施形態において、本発明の教示が実施されるシステムは、図１に示すような多層アーキテクチャーとして論理的に構成することができる。一実施形態において、図１に示すような論理的多層アーキテクチャーは、種々のアプリケーションをサポートするための一般的サービスに対するプラットホームを形成する。これらのサービスは、ユーザインターフェイス層１１０、オブジェクトマネージャー層１２０、データマネージャー層１３０、及びデータ交換層１４０を含む。
【００１０】
一実施形態において、ユーザインターフェイス層１１０は、１つ以上のアプリケーションに関連したアプレット、ビュー、チャート及びレポート等を与える。一実施形態において、ユーザインターフェイス層１１０を経て種々の形式のクライアントをサポートすることができる。これら種々の形式のクライアントは、慣習的な接続クライアント、リモートクライアント、イントラネットを経てのシンクライアント、Ｊａｖａ（登録商標）シンクライアント又は非ウインドウズベースのオペレーティングシステム、インターネットを経てのＨＴＭＬクライアント等を含む。
【００１１】
一実施形態において、オブジェクトマネージャー層１２０は、１つ以上のアプリケーションに関連したビジネスルール又はビジネスコンセプトの１つ以上のセットを管理し、そしてユーザインターフェイス層１１０とデータマネージャー層１３０との間のインターフェイスを形成するように設計される。一実施形態において、ビジネスルール又はコンセプトは、ビジネスオブジェクトとして表わすことができる。一実施形態において、ビジネスオブジェクトは、会計、交信、機会、サービス要求、解決策等の種々のビジネスルール又はコンセプトの構成可能なソフトウェア表示として設計される。
【００１２】
一実施形態において、データマネージャー層１３０は、その基礎となるデータの論理的ビューを維持すると共に、データが記憶された基礎的なデータ構造体又はテーブルとは独立してオブジェクトマネージャーが機能するのを許すように設計されている。一実施形態において、データマネージャー１３０は、データをアクセスするために構造問合せ言語（ＳＱＬ）をリアルタイムで発生するような幾つかのデータベース問合せファンクションを備えてもよい。一実施形態において、データマネージャー１３０は、データベーススキーマを定義する貯蔵ファイル１６０内のオブジェクト定義に基づいて動作するように設計される。一実施形態において、データ記憶サービス１７０は、１つ以上のアプリケーションに関連したデータモデルに対するデータ記憶を与える。
【００１３】
一実施形態において、データ交換層は、１つ以上の特定のターゲットデータベースとの相互作用を取り扱うと共に、データマネージャー層１３０とその基礎となるデータソースとの間のインターフェイスを与えるように設計される。
図２は、本発明の教示が実施されるシステムコンフィギュレーションの一実施形態のブロック図である。
【００１４】
一実施形態において、多層アーキテクチャーは、１つ以上のソフトウェア層が異なるマシンに存在するのを許す。例えば、一実施形態において、ユーザインターフェイス、オブジェクトマネージャー及びデータマネージャーは、全て、専用のウェブクライアントに存在することができる。ワイヤレスクライアントのような他の形式のクライアントについては、一実施形態において、オブジェクトマネージャー及びデータマネージャーがシステムサーバーに存在することができる。当業者であれば、図２に示すシステムコンフィギュレーションは、説明のためのもので、本発明の教示の特定の実施及びアプリケーションに基づいて変化し得ることが明らかであり理解されよう。
【００１５】
一実施形態において、図２に示すシステム環境は、２つ以上のデータベース２９０を備えている。データベース２９０の１つ以上のサブセットを複写マネージャーにより生成又は複写することができる。更に、移動ウェブクライアントは、付加的なリモートデータベース（ローカルデータベースとも称する）をもつことができる。一実施形態において、移動ウェブクライアントに関連したリモート又はローカルデータベースがリードオンリデータベースとして定義されない限り、これらの移動ウェブクライアントは、データをローカルで生成しそして更新することができ、該データは、最終的に、各移動ウェブクライアントがシステムサーバーと同期したときに一次データベースまで伝播される。
【００１６】
一実施形態において、データベース２９０は、予め定義されたデータスキーマ（例えば、テーブルオブジェクト、インデックスオブジェクト等）、貯蔵オブジェクト（例えば、ビジネスオブジェクト及びコンポーネント、ビュー定義及び可視性ルール等）、並びにユーザ又は顧客データを含む種々の形式のデータを記憶するように設計される。一実施形態において、他の形式のクライアントに関連して動作するものを含む専用ウェブクライアント及びサーバーコンポーネントは、データベース２９０に直結することができ、そしてリアルタイムで変化することができる。一実施形態において、移動ウェブクライアントは、サーバーデータのサブセットをローカルで使用するようにダウンロードできると共に、システムサーバーを経てサーバーデータベースと周期的に同期して、ローカル及びサーバーデータベースの両方を更新することができる。
【００１７】
一実施形態において、データベース２９０に含まれる種々のテーブルは、論理的に次の形式、即ちデータテーブル、インターフェイステーブル、貯蔵テーブル等に編成することができる。
一実施形態において、データテーブルは、ユーザビジネスデータ、管理データ、シードデータ、トランザクションデータ等を記憶するのに使用される。一実施形態において、これらのデータテーブルは、種々のアプリケーション及びプロセスによりポピュレーションされそして更新される。一実施形態において、データテーブルは、ベーステーブル、交差テーブル等を含む。一実施形態において、ベーステーブルは、種々のアプリケーションにより定義されそして使用される列を含む。一実施形態において、ベーステーブルは、そのビジネスコンポーネントのテーブル特性で指定されたビジネスコンポーネントに対する列を与えるように設計される。一実施形態において、交差テーブルは、２つのビジネスコンポーネント間の多数対多数(many-to-many)関係を実施するのに使用されるテーブルである。又、これらは、各関連性に関する情報を記憶する交差データ列も保持する。一実施形態において、交差テーブルは、関連性アプレットに対するデータ構造を与える。
【００１８】
一実施形態において、インターフェイステーブルは、ベーステーブルのグループを、外部プログラムをインターフェイスできる単一テーブルへと正規化解除(denormalize)するのに使用される。一実施形態において、これらは、データをエクスポート及びインポートするためのステージエリアとして使用される。
一実施形態において、貯蔵テーブルは、次のものに関する１つ以上のアプリケーションを指定するオブジェクト定義を含む。
−  クライアントアプリケーションコンフィギュレーション
−  データをインポート及びエクスポートするのに使用されるマッピング
−  データを移動クライアントへ転送するためのルール
【００１９】
一実施形態において、ファイルシステム２９５は、アプリケーションサーバーに配置することのできるネットワークアクセス可能なディレクトリーである。一実施形態において、ファイルシステム２９５は、種々のアプリケーションにより生成された物理的ファイル、例えば、第三者テキストエディタにより生成されたファイル、及びデータベース２９０に記憶されていない他のデータを記憶する。一実施形態において、ファイルシステム２９５に記憶された物理的ファイルは、種々のネーミング規定のもとで圧縮しそして記憶することができる。一実施形態において、専用ウェブクライアントは、ファイルをファイルシステム２９５から直接読み取りそして書き込むことができる。一実施形態において、移動ウェブクライアントは、それらがサーバーベースのファイルシステム２９０と周期的に同期させるところのローカルファイルシステムをもつことができる。一実施形態において、ワイヤレスクライアント及びウェブクライアントのような他の形式のクライアントは、システムサーバーを経てファイルシステム２９０にアクセスすることができる。
【００２０】
一実施形態において、企業サーバー２５０は、システムサーバー２５５の論理的グループであり、これは、共通のテーブル所有者又はデータベースを共有し、共通のゲートウェイサーバーを指し、そしてサーバーマネージャー２６０を使用してグループとして管理することができる。一実施形態において、ゲートウェイサーバーへの接続は、ＴＣＰ／ＩＰを経て確立することができる。一実施形態において、企業サーバー２５０は、多数のシステムサーバー２５５をその企業サーバー２５０に配備することにより有効に拡張することができ、従って、アプリケーションの中間段(tier)に高度な拡張性を与えることができる。
【００２１】
一実施形態において、サーバー２５５は、１つ又は多数のサーバープログラムを実行する。これは、到来する処理要求を取り扱い、サーバーにおける全プロセスの状態を監視する。一実施形態において、サーバープログラムは、データをインポート及びエクスポートし、データベースを構成し、ワークフロー及びプロセス自動化を実行し、データ同期及び複写に対する移動ウェブクライアントをサポートするように処理し、ビジネスルールを施行し、等々を含む１つ以上の特定のファンクション又はジョブを実行するように設計されそして構成される。一実施形態において、サーバー２５５は、ＮＴサービス（ウインドウズＮＴオペレーティングシステムのもとにある）であるか、又はＵＮＩＸ（登録商標）オペレーティングシステムのもとにあるデーモン（例えば、バックグランドシェルプロセス）である。一実施形態において、サーバー２５５は、マルチプロセス及びマルチスレッドコンポーネントの両方をサポートし、そしてバッチ、サービス及び双方向モードにおいてコンポーネントを動作することができる。
【００２２】
一実施形態において、サーバーマネージャー２６０は、サーバー２５５及び企業サーバー２５０のための異種プログラムにわたって共通の制御、管理及び監視を許すユーティリティとして構成される。一実施形態において、サーバーマネージャー２６０は、次のタスクを実行するのに使用することができる。即ち、サーバー２５５、コンポーネント及びタスクをスタートし、ストップし、休止しそして再開し、企業サーバー内の多数のタスク、コンポーネント及びサーバーに対する状態を監視しそしてその統計学的情報を収集し、更に、企業サーバー、個々のサーバーの個々のコンポーネント及びタスク等を構成する。
【００２３】
一実施形態において、ゲートウェイサーバーは、サーバーにアクセスするための単一エントリーポイントとして働く論理的エンティティとして構成することができる。一実施形態において、これは、企業サーバーにわたる改善された拡張性、負荷バランス及び高い利用性を与えるように使用することができる。一実施形態において、ゲートウェイサーバーは、名前サーバー及び接続ブローカーコンポーネントを含む。一実施形態において、名前サーバーは、サーバーに関連したパラメータを追跡するように構成される。例えば、サーバーに関連した利用性及び接続性情報は、名前サーバーに記憶することができる。システムにおける種々のコンポーネントは、サーバーの利用性及び接続性に関する種々の情報に対して名前サーバーに問合せすることができる。ウインドウズＮＴ環境では、名前サーバーは、ＮＴサービスとして実行することができる。ＵＮＩＸ環境では、名前サーバーは、デーモンプロセスとして実行することができる。一実施形態において、接続ブローカーコンポーネントは、クライアント接続要求を適当なサーバー（例えば最もビジーでないサーバー）へ向けるような負荷バランス機能を遂行するのに使用される。
【００２４】
一実施形態において、図２に示すように、システムによりサポートすることのできる種々の形式のクライアントは、次のクライアント、即ち専用ウェブクライアント、移動ウェブクライアント、ウェブクライアント、ワイヤレスクライアント、及びハンドヘルドクライアント等を含む。
一実施形態において、専用ウェブクライアント（接続クライアントとも称される）は、ＬＡＮ又はＷＡＮ接続を経てデータアクセスするためにデータベースサーバーに直結される。一実施形態において、これらの接続又は専用ウェブクライアントは、データをローカルに記憶しない。又、これらの専用ウェブクライアントは、ファイルシステムに直接アクセスすることもできる。一実施形態において、多層アーキテクチャーのユーザインターフェイス、オブジェクトマネージャー及びデータマネージャー層は、専用ウェブクライアントに存在する。
【００２５】
一実施形態において、移動ウェブクライアントは、ローカルデータをアクセスするように設計及び構成され、従って、それら自身のローカルデータベース及び／又はローカルファイルシステムをもつことができる。一実施形態において、移動ウェブクライアントは、ゲートウェイサーバーを経てシステム内の他のコンポーネントと相互作用することができる。同期により、ローカルデータベース及びサーバーデータベースからの変更を交換することができる。移動ウェブクライアントについては、以下に詳細に述べる。一実施形態において、ウェブクライアントは、クライアントのマシンから標準ブラウザフォーマットで動作する。一実施形態において、ウェブクライアントは、ウェブサーバーを経てシステムサーバー２５５に接続することができる。一実施形態において、システムサーバー２５５は、ビジネスロジックを実行しそしてデータベース２９０及びファイルシステム２９５からデータをアクセスするように設計及び構成される。一実施形態において、ここに述べるウェブクライアントは、本発明の教示に基づき、双方向モードで動作するように設計及び構成される。一実施形態において、ここに述べる双方向ウェブクライアントフレームワークは、サーバー側のオブジェクトに対応するブラウザ側のＪａｖａＳｃｒｉｐｔにおいて実施された動的に生成されるオブジェクトを利用する。一実施形態において、ブラウザ側のこれらの動的に生成されたオブジェクトは、現在ビュー及びそれに対応するアプレット、現在ビジネスオブジェクト及びそれに対応するビジネスコンポーネント等を含む。ウェブクライアントは、以下に詳細に述べる。
【００２６】
一実施形態において、ワイヤレスクライアントは、本質的に、ワイヤレス装置においてイネーブルされるシンクライアントである。ワイヤレスクライアントは、ワイヤレスアプリケーションプロトコル（ＷＡＰ）ベースのユーザインターフェイスを使用して、システムサーバーと通信しそしてそれと情報／データを交換することができる。
図２に示すシステムコンフィギュレーションは、説明のための例として、種々の構造、データベース、テーブル、ファイルシステム等を参照して、以下に詳細に説明する。
【００２７】
図３は、本発明の教示に基づいてアプリケーションを構築できる多層アーキテクチャーの別の論理的表示を示すブロック図である。この場合も、図３に示す多層アーキテクチャーは、種々のアプリケーションをサポートするように設計及び構成された種々の共通のサービスのためのプラットホームを備えている。一実施形態において、これら種々のサービスは、アプレットマネージャー及びユーザインターフェイス層３１０に対応するプレゼンテーションサービスロジック層３１５と、オブジェクトマネージャー（ＯＭ）層３２０及びデータマネージャー（ＤＭ）層３３０に対応するアプリケーションサービス論理層３２５と、データベース層３４０に対応するデータサービス論理層３４５とを含む。
【００２８】
一実施形態において、プレゼンテーションサービス３１５は、種々の形式のクライアントをサポートするように設計及び構成され、そしてそれらにユーザインターフェイスアプレット、ビュー、チャート及びレポート等を与える。上述したように、ワイヤレスクライアント、ハンドヘルドクライアント、ウェブクライアント、移動ウェブクライアント及び専用（接続）クライアント等を含む多数の様々なクライアントをサポートすることができる。一実施形態において、アプリケーションサービス３２５は、ビジネス論理サービス及びデータベース相互作用サービスを含む。一実施形態において、ビジネス論理サービスは、ビジネスオブジェクト及びビジネスコンポーネントのクラス及び振舞いを与える。一実施形態において、データベース相互作用サービスは、ビジネスコンポーネントからのデータに対するユーザインターフェイス（ＵＩ）要求を取り上げ、そしてその要求を満足するのに必要なデータベースコマンド（例えば、ＳＱＬ問合せ等）を発生するように設計及び構成される。例えば、データ相互作用サービスは、データに対するコールを、ＤＢＭＳ特有のＳＱＬステートメントへと変換するのに使用される。
【００２９】
一実施形態において、データ記憶サービス３４５は、種々のアプリケーションの基礎として働く基礎的なデータモデルのためのデータ記憶を与えるように設計及び構成される。例えば、データモデルは、コールセンター、販売、サービス、マーケッティング等を含む種々のソフトウェア製品及びアプリケーションと、ｅファイナンス、ｅインシュランス、ｅコミュニケーション、ｅヘルスケア等の種々の産業用の垂直的製品及びアプリケーションとをサポートするように設計及び構成される。
【００３０】
図４は、本発明の教示が実施されるアプリケーションフレームワークの一実施形態を示すブロック図である。図４に示すように、アプリケーションフレームワークは、ビジネスのニーズ及び環境に基づいて特定のアプリケーションを設計及び構成するのに使用できる種々の形式のサービス及び種々の形式のツールの種々の論理的グループを含む。
【００３１】
一実施形態において、コアサービスは、アプリケーションが実行するフレームワークを与えるように設計及び構成される。一実施形態において、コアサービスは、次のものを含む。
−  中間段のアプリケーションサーバーである企業サーバー
−  全ての断片を一緒にリンクするネットワーク
−  イベントマネージャー及びデータ複写のようなファシリティであって、種々のアプリケーションの多数のインスタレーション間、及び種々のアプリケーションと他の外部アプリケーションとの間でデータの共用を許すファシリティ
−  認証及びアクセス制御、セキュリティファシリティ
【００３２】
一実施形態において、アプリケーション一体化サービスは、このフレームワークに基づいて構築された種々のアプリケーションが外部世界と通信するのを許すように設計及び構成される。一実施形態において、この論理的グループの種々の形式のサービスは、外部アプリケーションとのリアルタイム、ほぼリアルタイム及びバッチ式の一体化を与えるように設計及び構成される。例えば、これらの一体化サービスは、利用可能な方法、技術及びソフトウェア製品を使用して外部アプリケーションと内部アプリケーションとの間で通信を行えるようにするために使用される。一実施形態において、アプリケーション一体化サービスは、システム又はアプリケーションが他の外部企業アプリケーションとデータを共用しそして複写するのを許す。従って、これらのサービスは、特定のアプリケーション又はシステムが、情報を要求しているクライアント、及びそこから要求された情報を有しているサーバーの両方となることを許す。
【００３３】
一実施形態において、ビジネスプロセスサービスは、クライアントがアプリケーションを通してビジネスプロセスを自動化するのを許すように設計及び構成される。一実施形態において、これらの種々のビジネスプロセスサービスは、次のものを含む。
−  アサイメントマネージャーによるタスクの指定
−  ワークフローマネージャーによるビジネス規定の施行
−  ビジネスサービスによるカスタムビジネスロジックの再使用
−  製品コンフィギュレーター及び価格コンフィギュレーターによる適切な製品コンフィグレーション及び価格の確保
【００３４】
一実施形態において、これらビジネスプロセスの生成は、ランタイムツール、例えば、個人化デザイナー、ワークフローデザイナー、スマートスクリプトデザイナー、アサイメントアドミニストレーションビュー、モデルビルダー等により行うことができる。
一実施形態において、一体化サービスは、クライアントにユーザインターフェイス及びシンクライアントサポートを与えるように設計及び構成される。一実施形態において、これらは、ウェブベースのアプリケーションを構築して維持し、ユーザプロフィールマネージメント、合併サービス、ｅ−メール及びファックスサービス、並びに進歩型スマートスクリプト等のウェブサポートファシリティを与える能力を含む。
【００３５】
一実施形態において、デザイン時間ツールは、一体化ポイントをカスタマイズし、デザインし、形成し、そしてアプリケーションを維持するためのサービスを提供するように設計及び構成される。これら種々のツールは、アプリケーションを定義するための１つの共通の場所を与える。
一実施形態において、アドミニストレーションサービスは、アプリケーション環境を監視しそして管理するためのサービスを提供するように設計及び構成される。一実施形態において、これらのサービスは、ユーザがグラフィックユーザインターフェイス（ＧＵＩ）を経て又はコマンドライン等からアプリケーションを管理するのを許す。
【００３６】
ＩＩ．システムフレームワーク又はインフラストラクチャー
図５Ａは、本発明の一実施形態に基づき図２の双方向ウェブクライアント２０５及び移動ウェブクライアント２１０をサポートするための例示的システムフレームワーク又はインフラストラクチャー５００を示す。図５Ｂは、図５Ａに示された例示的システムフレームワーク又はインフラストラクチャー５００の別の図である。
【００３７】
このフレームワーク又はインフラストラクチャー５００は、双方向ウェブクライアント２０５（図２に示す）及び移動ウェブクライアント２１０（これも図２に示す）をサポートすることができ、そしてウェブクライアント及び移動ウェブクライアントの双方向性及び性能を高めると共に、通常のアクションに対するページリフレッシュの数を減少するといったある基準を満足することができる。
【００３８】
フレームワーク又はインフラストラクチャー５００は、オブジェクトマネージャーにより管理される対応オブジェクト５０４を模擬するようにブラウザにおいて動的に生成することのできるオブジェクト５０２を含むことができる。一実施形態において、オブジェクトマネージャー（ＯＭ）により管理されるオブジェクト５０４は、オブジェクト指向の規範をサポートするＣ＋＋＋のようなプログラム言語を使用して構築することができる。
【００３９】
図５Ａ及び５Ｂに示すように、ＯＭにより管理される例示的オブジェクト５０４は、ビューを表わすオブジェクト５０６即ちＣＳＳＷＥＶｉｅｗ５０６を含むことができる。ビューは、一般に、アプレットの特定配列より成るディスプレイパネルである。一実施形態において、１つのアクティブなビューを所与の時間に表示することができる。ＯＭにより管理される別の例示的オブジェクトは、アプレットを表わすオブジェクト５０８即ちＣＳＳＷＥＡｐｐｌｅｔ５０８である。アプレットは、一般に、ビューの一部分としてスクリーン上に現われる視覚アプリケーションユニットである。ＯＭにより管理される他の例示的オブジェクトは、ビジネスコンポーネントを表わすオブジェクト５１０（ＣＳＳＢｕｓＣｏｍｐ５１０）と、ビジネスオブジェクトを表わすオブジェクト５１２（ＣＳＳＢｕｓＯｂｊ５１２）と、フレームを表わすオブジェクト５１４（ＣＳＳＷＥＦｒａｍｅ５１４）とを含むことができる。一実施形態において、ビジネスオブジェクトは、会計、交信、機会、サービス要求、解決策等の種々のビジネスルール又はコンセプトの構成可能なソフトウェア表示として設計される。この実施形態では、ビジネスコンポーネントは、通常、ラップオーバーテーブルの層と、基礎的テーブル以外のアプレット基準ビジネスコンポーネントとを与える。更に、フレームは、一般に、ビューのサブコンポーネントであり、１つ以上のアプレットを含む。
【００４０】
一実施形態において、ブラウザにおけるオブジェクト５０２は、ＪａｖａＳｃｒｉｐｔを使用して構築することができる。図５Ａ及び５Ｂに示すように、ブラウザ側における例示的オブジェクト５０２は、ＪＳＳＢｕｓＯｂｊ５１６、ＪＳＳＢｕｓＣｏｍｐ５１８、ＪＳＳＶｉｅｗ５２０及びＪＳＳＡｐｐｌｅｔ５２２を含み、これらは、各々、ＯＭにより管理されるオブジェクト５０４であるＣＳＳＢｕｓＯｂｊ５１２、ＣＳＳＢｕｓＣｏｍｐ５１０、ＣＳＳＷＥＶｉｅｗ５０６及びＣＳＳＷＥＡｐｐｌｅｔ５０８と鏡像関係である。
【００４１】
図５Ｃは、更新を暗示的にコミットするのに適した計算システムの一実施形態を示す。この計算システム５００は、クライアント５０２がＲＰＣモジュール５２８を経てサーバー５０４へ接続されて示されている。クライアント５０２は、ＲＰＣモジュール５２８に接続されたアプリケーション５２４と、アクティブなアプレット５２２と、アプレット５１０とを備えている。アクティブなアプレット５２２は、ディスプレイ５８０に接続される。アクティブなアプレット５２２は、記録フィールドでよい。ディスプレイ５８０は、アクティブなアプレット５２２に対する記録値を表示するためのユーザ双方向ディスプレイでよい。又、ディスプレイ５８０は、ディスプレイオブジェクト５１６にも接続される。アプレット５２２及び５１０は、各々、ビジネスコンポーネント５１８及び５７２に接続される。ビジネスコンポーネント５１８は、キャッシュ５６８を含む。ユーザは、アクティブなアプレット５２２に対する部分記録値を、ディスプレイ５８０を経て入力することができる。又、アプリケーション５２４は、コマンドマネージャー５７４、ローカルオブジェクト５７６及びアラームマネージャー５８４にも接続される。アクティブなアプレット５２２は、記録フィールドでよいが、より一般的には、種々のフィールドを含む。
【００４２】
サーバー５０４は、貯蔵部５５２に接続される。クライアント５０２のオブジェクトは、サーバー５０４のオブジェクトのプロキシーオブジェクトを含む。例えば、アプリケーション５２４は、フレームマネージャー５２６のプロキシーであり、ディスプレイ５８０は、ディスプレイ５５８のプロキシーであり、アクティブなアプレット５２２は、アクティブなアプレット５０８のプロキシーであり、アプレット５１０は、アプレット５５６のプロキシーであり、そしてビジネスコンポーネント５１８及び５７２は、各々、ビジネスコンポーネント５１０及び５６６のプロキシーである。ディスプレイ５５８は、ビジネスオブジェクト５１２に接続される。ビジネスオブジェクト５１６は、ビジネスオブジェクト５１２のプロキシーである。
【００４３】
クライアント５０２とＲＰＣモジュール５２８との間の通信要求は、アプリケーション５２４を経て処理される。この通信要求は、コンテクスト変更要求を含むことができる。本発明の一実施形態において、コンテクスト変更要求は、新たなウェブページに対するユーザ要求を含むことができる。本発明の別の実施形態では、コンテクスト変更要求は、アクティブなアプレット５２２からタブ付けするためのユーザ要求を含むことができる。本発明の更に別の実施形態では、コンテクスト変更要求は、クライアント５０２により発生されたコンテクスト変更を含むことができる。
【００４４】
アプリケーション５２４は、コンテクスト変更要求を受け取るのに応答してアクティブなアプレット５２２に非セーブデータム要求を自動的に送信することができる。非セーブデータム要求は、アクティブなアプレット５２２が非セーブデータムを含むかどうか問合わせる。アクティブなアプレット５２２は、キャッシュ要求を受け取るのに応答して、ビジネスコンポーネント５１８へキャッシュ要求を自動的に送信することができる。ビジネスコンポーネント５１８は、キャッシュ要求を受け取るのに応答して、キャッシュ５６８が非セーブユーザエントリーを含むかどうか自動的に決定する。ビジネスコンポーネント５１８は、キャッシュ通知要求をアクティブなアプレット５２２へ送信する。このキャッシュ通知要求は、非セーブデータを含むか、又はキャッシュ５６８が非セーブデータを含まないという通知を含む。
【００４５】
アクティブなアプレット５２２は、キャッシュ通知要求を受け取るのに応答して配達要求をトリガーすることができる。配達要求は、キャッシュ５６８からの非セーブデータを含むことができる。又、アクティブなアプレット５２２は、非セーブデータなし要求をアプリケーション５２４へ送信することもできる。この非セーブデータなし要求は、キャッシュ５６８が非セーブデータを含まないことを指示できる。ビジネスコンポーネント５１８は、キャッシュ通知要求を送信した後にキャッシュ５６８をクリアすることができる。
【００４６】
アプリケーション５２４は、配達要求又は非セーブデータなし要求のいずれかを受け取るのに応答して、ＲＰＣモジュール５２８を経てサーバー５０４へコンテクスト変更要求を自動的に送信することができる。アプリケーション５２４は、ＲＰＣモジュール５２８を経てサーバー５０４へ配達要求を転送することができる。
【００４７】
サーバー５０４は、配達要求を受け取るのに応答して配達要求を自動的に処理することができる。サーバー５０４は、それが非セーブデータをデータベースへコミットするのを望むかどうか決定することにより配達要求を処理することができる。サーバー５０４は、サーバー通知をクライアント５０２へ送信することができる。サーバー通知は、非セーブデータがデータベースに首尾良くセーブされたことを指示する成功メッセージ、又は非セーブデータをデータベースにセーブできないことを指示するエラーメッセージのいずれかを含むことができる。
【００４８】
アプリケーション５２４は、サーバー５０４からＲＰＣモジュール５２８を経てエラーメッセージを受け取るのに応答してディスプレイ５８０にエラーメッセージを表示することができる。アプリケーション５２４は、サーバー５０４からエラーメッセージを受け取るのに応答してサーバー５０４へのコンテクスト変更要求の送信を保留することができる。又、アプリケーション５２４は、サーバー５０４からＲＰＣモジュール５２８を経て成功メッセージを受け取るのに応答して、ＲＰＣモジュール５２８を経てサーバー５０４へコンテクスト変更要求を自動的に送信することができる。
【００４９】
サーバー５０４は、コンテクスト変更要求を受け取るのに応答してコンテクスト変更要求を自動的に処理することができる。サーバー５０４は、ＲＰＣモジュール５２８を経てクライアント５０２へ要求された新たなコンテクストを送信することにより、コンテクスト変更要求を処理することができる。要求されたコンテクストは、アプレット又はウェブページを含むことができる。アプリケーション５２４は、ＲＰＣモジュール５２８を経て新たなコンテクストを受け取ることができる。サーバー５０４から受け取ったウェブページは、ディスプレイ５８０を経て表示されたウェブページに置き換わることができる。サーバー５０４から受け取られたアプレットは、アクティブなアプレットとしてアプレット５２２に置き換わることができる。
【００５０】
ブラウザにおけるオブジェクト５０２、及びＯＭにより管理されるオブジェクト５０４は、１つの計算装置又は多数の計算装置に存在して動作するように構成できる。図６Ａは、ブラウザにおけるオブジェクト５０２、及びＯＭにより管理されるオブジェクト５０４が、クライアント６０２及びサーバー６０４を含む多数の計算装置６０２、６０４に存在して動作するような例示的コンフィギュレーション６００を示す。図６Ｂは、ブラウザにおけるオブジェクト５０２、及びＯＭにより管理されるオブジェクト５０４が、１つの計算装置６５２に存在して動作するような例示的コンフィギュレーション６５０を示す。
【００５１】
図５Ａ及び５Ｂに戻ると、ブラウザにおけるオブジェクト５０２は、一般に、ＯＭにより管理される対応するオブジェクト即ち鏡像関係のオブジェクト５０４と同期される。同期は、リモート手順コール（ＲＰＣ）メカニズム５２８及び通知メカニズム５３０を経て達成することができる。ＲＰＣメカニズム５２８及び通知メカニズム５３０は、以下に詳細に説明する。
【００５２】
ブラウザにおけるオブジェクト５０２のうちのＪＳＳＡｐｐｌｉｃａｔｉｏｎオブジェクト５２４は、通常、ユーザセッション全体にわたって存在する。ＪＳＳＡｐｐｌｉｃａｔｉｏｎオブジェクト５２４は、ユーザがアプリケーションをスタートするときに最初にロードされねばならない。アプリケーションは、一般に、ユーザがデスクトップのアイコン又はスタートメニューからアプリケーションのサブセットをインボーク(invoke)するときにスタートされる。ＪＳＳＡｐｐｌｉｃａｔｉｏｎオブジェクト５２４は、一般に、ＣＳＳＭｏｄｅｌオブジェクト５３４と同様の役割を遂行する。このＣＳＳＭｏｄｅｌオブジェクト５３４は、一般に、グローバルセッションオブジェクトで、これは、使用中の貯蔵オブジェクト、メモリにおける現在ビジネスオブジェクトインスタンス、現在ビジネスオブジェクトとそれに含まれたビジネスコンポーネントとの関係、及びユーザのグローバル状態情報へのアクセスを与えるものである。ＣＳＳＭｏｄｅｌオブジェクト５３４は、一般に、貯蔵部５３２にアクセスして、必要な情報を得る。貯蔵部５３２は、一般に、アプリケーション又は１組のアプリケーションを定義するのに使用されるオブジェクト定義のセットである。しかしながら、ＪＳＳＡｐｐｌｉｃａｔｉｏｎオブジェクト５２４は、一般に、１つのビュー、追跡されるビューに関連したアプレット、１つのビジネスオブジェクト、及びビューに使用されるビジネスコンポーネントを追跡するようにスケールダウンされる。
【００５３】
ＪＳＳＡｐｐｌｉｃａｔｉｏｎオブジェクト５２４とは異なり、ＪＳＳＶｉｅｗオブジェクト５２０、ＪＳＳＡｐｐｌｅｔオブジェクト５２２、ＪＳＳＢｕｓＯｂｊオブジェクト５１６、及びＪＳＳＢｕｓＣｏｍｐオブジェクト５１８は、通常、一時的即ち非永久的エンティティであり、そして一般的に、ページリフレッシュが生じるときに置き換えられる。例えば、新たなビューへナビゲートする要求は、ＪＳＳＶｉｅｗ５２０、ＪＳＳＡｐｐｌｅｔ５２２、ＪＳＳＢｕｓＯｂｊ５１６及びＪＳＳＢｕｓＣｏｍｐ５１８オブジェクトの新たなセットを、ブラウザ上で実行するように生成させる。
【００５４】
従って、ブラウザにおけるオブジェクト５０２は、一般的に、ＯＭにより管理される鏡像関係の即ち対応するオブジェクト５０４の軽い重みの表示として説明することができる。ブラウザにおける各オブジェクト５０２は、通常、ＯＭにより管理される対応するオブジェクト５０４に含まれた機能のサブセットを含む。例えば、ＣＳＳＶｉｅｗオブジェクト５０６と同様に、ＪＳＳＶｉｅｗオブジェクト５２０は、一般に、アプレットの集合を表わす。ＣＳＳＢｕｓＯｂｊオブジェクト５１２と同様に、ＪＳＳＢｕｓＯｂｊオブジェクト５１６は、一般に、アクティブなビジネスコンポーネント間の種々の１対多(one-to-many)関係を管理し、これらのアクティブなビジネスコンポーネントが問合せを介してポピュレートされたときに正しい関係が使用されるようにする。ＪＳＳＢｕｓＯｂｊオブジェクト５１６は、一般に、現在ビューの寿命中にブラウザに存在し、そしてそれに対応するＣＳＳＢｕｓＯｂｊオブジェクト５１２との同期を保持しなければならない。
【００５５】
一実施形態において、ブラウザが、新たなビューへナビゲートするための要求をウェブエンジン５２６へ提出すると、ウェブエンジン５２６は、データのないビューレイアウトを含む応答を送信する。次いで、ウェブエンジン５２６は、ビューをポピュレートするためのデータのストリングを含む応答を送信する。
【００５６】
ＪＳＳＡｐｐｌｉｃａｔｉｏｎオブジェクト５２４は、一般に、ブラウザにおけるオブジェクトへ流入したりそこから流出したりする通信を管理する。一実施形態において、ブラウザのオブジェクトでインボークされたメソッドは、通常、そのインボークされたメソッドが、ＯＭにより管理されるオブジェクト５０４を再びターゲットとすべき場合には、ＪＳＳＡｐｐｌｉｃａｔｉｏｎオブジェクト５２４へ向けられる。ＪＳＳＡｐｐｌｉｃａｔｉｏｎオブジェクト５２４は、一般に、ＲＰＣメカニズム５２８を使用して、インボークされたメソッドを、ウェブエンジン５２６を経て、ＯＭにより管理される適切なオブジェクト５０４へルーティングする。ウェブエンジン５２６は、通常、ＯＭにより管理されるオブジェクト５０４からブラウザにおけるオブジェクト５０２へ返送通知及びデータを送信するのに使用される。ウェブエンジン５２６は、一般に、通知メカニズム５３０を使用して、通知及びデータを、ＪＳＳＡｐｐｌｉｃａｔｉｏｎオブジェクト５２４を経て、ブラウザにおけるオブジェクト５０２へルーティングする。
【００５７】
ブラウザのオブジェクト５０２は、一般に、リモート手順コール５２８を使用して、ＯＭにより管理されるオブジェクト５０４に対するメソッドをインボークする。これらのリモート手順コール５２８は、一般に、ＨＴＴＰ要求としてパッケージされる。ＯＭにより管理されるオブジェクト５０４からの応答は、通知並びにそれに関連した状態情報及びデータを含むＨＴＴＰ応答としてパッケージされる。一実施形態において、リモート手順コールは、ブラウザにおけるオブジェクト５０２と、ＯＭにより管理されるオブジェクト５０４との間の同期を確保するためにブロッキングがイネーブルされた状態で行われる。ブロッキングがイネーブルされると、制御は、通常、被呼リモート手順が実行を終了するまで発呼コードへ戻されない。
【００５８】
リモート手順コール（ＲＰＣ）
ＲＰＣモデルは、一般に、従来のプログラムと同じ手順的抽象概念を使用するが、手順コールが２つのコンピュータ間の境界をまたぐことを許す。図７は、ＲＰＣ規範をいかに使用して、プログラム７００を、個別の計算装置７０２、７０４で実行できる断片に分割できるかの一例を示す。この図は、多数の手順を有する分散型プログラムを一般的に示す。Ｍａｉｎ（）７０６、ｐｒｏｃ＿１（）７０８、ｐｒｏｃ＿２（）７１０、ｐｒｏｃ＿３（）７１２、ｐｒｏｃ＿５（）７１４、ｐｒｏｃ＿６（）７１６、及びｐｒｏｃ＿７（）７１８は、第１計算装置即ちクライアント７０２に存在して動作し、そしてｐｒｏｃ＿４（）７２０及びｐｒｏｃ＿８（）７２２は、第２計算装置即ちサーバー７０４に存在して動作する。手順ｎから手順ｍへの実線７２４は、ｎからｍへのコールを表わす。破線７２６は、リモート手順コールの間に１つの計算装置から別の計算装置へ制御がいかに通過するかを示す。
【００５９】
図８は、リモート手順コールと共に使用される例示的な実行モデル８００を示す。この図において、実線７２４は、計算装置内の流れ制御を示すために一般的に使用され、そして破線７２６は、リモート手順コール中に１つの計算装置から別の計算装置へ制御がいかに通過するかを示すために一般的に使用される。
【００６０】
このように、リモート手順コールは、一般に、発呼コードからの個別のアドレススペースに配置された手順を実行する。ＲＰＣモデルは、一般に、ローカル手順コールのプログラミングモデルから導出され、そして各手順が手順の宣言を含むという利点を取り入れる。手順の宣言は、発呼コードと被呼手順との間のインターフェイスを定義する。手順の宣言は、手順のコールシンタックス及びパラメータを定義する。手順へのコールは、通常、手順の宣言に合致しなければならない。
【００６１】
リモート手順コールを使用するアプリケーションは、ローカルアプリケーションのように見え且つそのように振舞う。しかしながら、ＲＰＣアプリケーションは、２つの部分、即ちリモート手順を１セット以上与えるサーバーと、ＲＰＣサーバーへリモート手順コールを行うクライアントとに分割される。サーバー及びそのクライアント（１つ又は複数）は、一般に、個別のシステム上に存在して、ネットワークを経て通信する。ＲＰＣアプリケーションは、それらに対するネットワーク通信を制御するためにＲＰＣランタイムライブラリーに依存する。ＲＰＣランタイムライブラリーは、一般に、クライアントに対するサーバーを見つけそしてサーバーを管理するといった付加的なタスクをサポートする。
【００６２】
分散型アプリケーションは、一般に、中央処理ユニット（ＣＰＵ）、データベース、装置及びサービスのような散在計算リソースを使用する。以下のアプリケーションは、分散型アプリケーションを例示するものである。
・許可されたユーザが他のユーザのパーソナルカレンダーにアクセスするのを許すカレンダーマネージメントアプリケーション；
・ＣＰＵにおいてデータを処理しそしてワークステーションに結果を表示するグラフィックアプリケーション；及び
・異なるコンピュータに配置された設計、在庫、スケジューリング及び会計プログラムの間で組み立てコンポーネントに関する情報を共有する製造アプリケーション。
【００６３】
ＲＰＣソフトウェアは、一般に、次のものを含む分散型アプリケーションの基本的要求を満足しなければならない。
・適当なサーバーを見出すクライアント；
・異種環境において動作するためのデータ変換；及び
・ネットワーク通信。
【００６４】
分散型アプリケーションは、通信を管理し、サーバーを見出し、セキュリティを与える等のタスクを含む。スタンドアローンの分散型アプリケーションは、全てのこれらタスクそれ自体を実行する必要がある。これらの分散型計算タスクに対する便利なメカニズムがないと、分散型アプリケーションの書き込みは、困難であり、経費がかかり且つエラーの傾向となる。
【００６５】
ＲＰＣソフトウェアは、通常、コードと、被呼ＲＰＣスタブと、アプリケーションに対する分散型計算タスクを実行するＲＰＣランタイムライブラリーとを与える。ＲＰＣスタブと、ＲＰＣランタイムライブラリーは、クライアント及びサーバーアプリケーションコードとリンクしてＲＰＣアプリケーションを形成しなければならない。
【００６６】
テーブル１は、一般に、分散型アプリケーションのクライアント及びサーバーに対する基本的タスクを示す。手順をコールしそしてリモート手順を実行すること（イタリック体で示された）は、アプリケーションコードによって実行される（ローカルアプリケーションの場合と同様に）が、ここでは、それらは、クライアント及びサーバーアドレススペースにある。他のタスクについては、あるものは、スタブ及びＲＰＣランタイムライブラリーにより自動的に実行されるが、他のものは、アプリケーションコードにおいてＡＰＩを経てＲＰＣランタイムライブラリーにより実行される。
【００６７】
テーブル１：ＲＰＣアプリケーションの基本的タスク
2005516272.tif 000003
【００６８】
図９は、ＲＰＣクライアント９０２及びＲＰＣサーバー９０４におけるＲＰＣアプリケーションコードセグメント９０４及び９１４、ＲＰＣインターフェイス９０６及び９１６、クライアント及びサーバースタブ９０８及び９１８、並びにＲＰＣランタイムライブラリー９１０及び９２０の例示的区画９００を一般的に示す。
【００６９】
ＲＰＣクライアント９０２又はＲＰＣサーバー９１２は、通常、ＲＰＣアプリケーションコードセグメント９０４及び９１４、ＲＰＣインターフェイス９０６及び９１６、スタブ９０８及び９１８、並びにＲＰＣランタイムライブラリー９１０及び９２０を備えている。ＲＰＣアプリケーションコードセグメント９０４及び９１４は、一般に、アプリケーションデベロッパーにより特定のＲＰＣアプリケーションに対して書き込まれたコードである。ＲＰＣアプリケーションコードセグメント９０４及び９１４は、一般に、コールリモート手順を実施すると共に、ＲＰＣランタイムライブラリーにおけるコール要求ルーチン又は手順も実施する。ＲＰＣスタブ９０８、９１８は、一般に、インターフェイス特有のコードモジュールで、ＲＰＣインターフェイス９０６、９１６を使用して、アーギュメントを通過しそして受け取るものである。クライアント９０２及びサーバー９１２は、通常、各共有ＲＰＣインターフェイス９０６、９１６に対して相補的なＲＰＣスタブ９０６、９１６を含む。ＲＰＣランタイムライブラリー９１０、９２０は、一般に、ＲＰＣアプリケーションに対する通信を管理する。更に、ＲＰＣランタイムライブラリー９１０、９２０は、ＲＰＣアプリケーションコードにより使用されるアプリケーションプログラミングインターフェイス（ＡＰＩ）をサポートし、ＲＰＣアプリケーションをイネーブルして、それらの通信を設定し、サーバーに関する情報を操作し、そしてサーバーを遠隔管理したりセキュリティ情報にアクセスしたりといった任意のタスクを遂行しなければならない。
【００７０】
ＲＰＣアプリケーションコードセグメント９０４、９１４は、通常、クライアントとサーバーで異なる。サーバー９１２におけるＲＰＣアプリケーションコード９１４は、通常、１つのＲＰＣインターフェイスを実施するリモート手順を含む。対応するクライアント９０２におけるＲＰＣアプリケーションコード９０４は、通常、これらのリモート手順へのコールを含む。
【００７１】
ＲＰＣスタブ９０８、９１８は、一般に、リモート手順コールに対する基本的なサポートファンクションを実行する。例えば、ＲＰＣスタブ９０８、９１８は、異なる形式のデータ表示でシステム間の通信を行うための入力及び出力アーギュメントを準備する。ＲＰＣスタブ９０８、９１８は、ＲＰＣランタイムライブラリー９１０、９２０を使用して、クライアント９０２とサーバー９０４との間の通信を取り扱う。クライアント９０２におけるＲＰＣスタブ９０８は、ローカルＲＰＣランタイムライブラリー９１０も使用して、クライアント９０２のための適切なサーバーを見つけることができる。
【００７２】
図１０は、クライアントデータ構造とサーバーデータ構造との間の例示的なマーシャリング（変換）及びアンマーシャリング（復元）を一般的に示す。クライアントＲＰＣアプリケーションコードがリモート手順をコールするときには、クライアントＲＰＣスタブ９０８が送信のために入力アーギュメント１００２を準備しなければならない。送信のためにアーギュメントを準備するためのプロセスが「マーシャリング」として知られている。
【００７３】
マーシャリング１００４は、一般に、入力又はコールアーギュメント１００２をバイトストリームフォーマットに変換し、そしてそれらを送信のためにパッケージする。コールアーギュメントを受信すると、サーバーＲＰＣスタブ９１８は、それらをアンマーシャリングする（１０１４）。アンマーシャリング１０１４は、一般に、スタブが到来するネットワークデータを分解し、そしてローカルシステムに分かるフォーマットを使用してそれをアプリケーションデータに変換するプロセスである。マーシャリング１００４、１０１６及びアンマーシャリング１０１４、１００６の両方は、リモート手順コールごとに２回生じる。クライアントＲＰＣスタブ９０８は、入力アーギュメント１００２をマーシャリングし（１００４）、そして出力アーギュメント１００８をアンマーシャリングする（１００６）。サーバーＲＰＣスタブ９１８は、入力アーギュメント１００６をアンマーシャリングし（１０２４）、そして出力アーギュメント１００８をマーシャリングする（１０１６）。マーシャリング及びアンマーシャリングは、クライアント及びサーバーシステムが同等のデータに対して異なるデータ表示を使用するのを許す。例えば、図１０に示すように、クライアントシステムは、ＡＳＣＩＩデータ１００２、１００８を使用することができ、そしてサーバーシステムは、ユニコードデータ１０１８を使用することができる。
【００７４】
ＩＤＬコンパイラー（アプリケーション開発のためのツール）は、アプリケーションデベロッパーにより書かれたＲＰＣインターフェイス定義をコンパイルすることによりスタブを発生する。このコンパイラーは、プラットホーム独立のＩＤＬデータ形式に対してマーシャリング及びアンマーシャリングルーチンを発生する。ＲＰＣアプリケーションに対してクライアントを構築するために、デベロッパーは、クライアントアプリケーションコードを、アプリケーションが使用する全てのＲＰＣインターフェイスのクライアントスタブにリンクする。サーバーを構築するために、デベロッパーは、サーバーアプリケーションコードを、それに対応するサーバースタブにリンクする。
【００７５】
１つ以上のＲＰＣスタブに加えて、各ＲＰＣサーバー及びＲＰＣクライアントは、ＲＰＣランタイムライブラリーのコピーにリンクされねばならない。ＲＰＣランタイムライブラリーは、一般に、クライアントとサーバーとの間の通信を制御しそして要求に応じてクライアントに対するサーバーを見出すといったランタイムオペレーションを与える。クライアント及びサーバーにおけるＲＰＣスタブは、通常、クライアント及びサーバーに対して各々ローカルであるＲＰＣランタイムライブラリーを経てアーギュメントを交換する。クライアントにおけるＲＰＣランタイムライブラリーは、通常、リモート手順コールをサーバーへ送信する。サーバーにおけるＲＰＣランタイムライブラリーは、一般に、クライアントからリモート手順コールを受信し、そしてサーバーにおける適切なＲＰＣスタブへ各コールを発送する。ＲＰＣランタイムライブラリーは、次いで、各コールの結果をクライアントにおけるＲＰＣランタイムライブラリーへ送信する。
【００７６】
サーバーにおけるＲＰＣアプリケーションコードは、サーバーが始動しそして遮断するときにサーバーにおけるＲＰＣランタイムライブラリーのルーチンをコールするサーバー初期化コードも含まねばならない。クライアントにおけるＲＰＣアプリケーションコードも、初期化の目的でＲＰＣランタイムライブラリールーチンをコールすることができる。更に、サーバーにおけるＲＰＣアプリケーションコード及びクライアントにおけるＲＰＣアプリケーションコードは、ＲＰＣスタブサポートルーチンへのコールを含むこともできる。ＲＰＣスタブサポートルーチンは、一般に、アプリケーションが、メモリを割り当てそして解放するといったプログラミングタスクを管理するのを許す。
【００７７】
図１１は、一般に、リモート手順コール中のＲＰＣアプリケーションコードセグメント９０４及び９１４と、ＲＰＣインターフェイス９０６及び９１６と、ＲＰＣスタブ９０８及び９１８と、ＲＰＣランタイムライブラリー９１０及び９２０との役割を例示する。クライアントのアプリケーションコード又は発呼コード９０８は、リモート手順コールをインボークし(invoke)、入力アーギュメント１００２を、クライアントのＲＰＣインターフェイス９０６を経てクライアントスタブ９０８へ通過させる。クライアントスタブ９０８は、入力アーギュメント１００２をマーシャリングし、そしてクライアントのＲＰＣランタイムライブラリー９１０へコールを発送させる。クライアントのＲＰＣランタイムライブラリー９１０は、入力アーギュメント１００２をサーバーのＲＰＣランタイムライブラリー９２０へ送信し、これは、被呼手順のＲＰＣインターフェイス９１６に対するサーバースタブ９１８へコールを発送する。サーバーのスタブ９１８は、入力アーギュメント１００２をアンマーシャリングし、そしてそれらを被呼リモート手順９１４へ通過させる。サーバーのアプリケーションコード又はリモート手順９１４は、出力アーギュメント１００８を実行して、サーバースタブ９１８へ返送する。サーバースタブ９１８は、出力アーギュメント１００８をマーシャリングし、そしてそれらをサーバーのＲＰＣランタイムライブラリー９２０へ返送する。サーバーのＲＰＣランタイムライブラリー９２０は、出力アーギュメント１００８をクライアントのＲＰＣランタイムライブラリー９１０へ送信し、これは、それらアーギュメントをクライアントスタブ９０１へ発送させる。クライアントスタブ９０８は、出力アーギュメント１００８をアンマーシャリングし、そしてそれらを発呼コード９０４へ返送する。
【００７８】
一実施形態において、リモート手順コールは、ブラウザにおけるオブジェクト５０２と、ＯＭにより管理されるオブジェクト５０４（図５Ａ及び５Ｂに示す）との間に同期を確保するためにブロッキングがイネーブルされた状態で行われる。ブロッキングがイネーブルされた状態では、制御は、通常、被呼リモート手順が実行を終了するまで発呼コードへ戻されない。
【００７９】
図１２は、分散型ＲＰＣアプリケーションを構築する例示的プロセス１２００の概要を一般的に示す。このプロセスは、一般に、次の基本的タスクを含む。
・アプリケーションを設計し、どんな手順が必要であり且つそれら必要な手順のどれがリモート手順であるか判断し、そしてそれらリモート手順をいかにＲＰＣインターフェイスにグループ編成するか判断する（ブロック１２０５）；
【００８０】
・ユニバーサルユニーク識別子（ＵＵＩＤ）ジェネレータを使用して、各ＲＰＣインターフェイスに対してＵＵＩＤを発生する（ブロック１２１０）；
・インターフェイス定義言語（ＩＤＬ）を使用して、プランニングされたデータ形式及びリモート手順に対してＲＰＣインターフェイスを記述する（ブロック１２１５）；
・ＩＤＬコンパイラーを使用してＩＤＬ記述をコンパイルすることによりクライアント及びサーバースタブを発生する（ブロック１２２０）；
【００８１】
・ＲＰＣスタブに適合するプログラミング言語を使用してアプリケーションコードを書き込み又は変更し、アプリケーションコードがスタブと共に作用するようにする（ブロック１２２５）；
・アプリケーションコードからオブジェクトコードを発生する（ブロック１２３０）；及び
・ローカルＲＰＣランタイムライブラリーと、アプリケーションコードから発生されたオブジェクトコードをリンクして、実行可能なコードを発生する（ブロック１２３５）。
【００８２】
図１３は、ローカルＲＰＣランタイムライブラリーと、アプリケーションコードから発生されたオブジェクトコードとをリンクすることを一般的に示す。クライアントの場合には、クライアントスタブ９０８のオブジェクトコードと、クライアントアプリケーションコード又は発呼コード９０４と、クライアントのＲＰＣランタイムライブラリー９１０とが、リンカー１３０２を使用してリンクされて、クライアント実行コード１３０４を発生する。サーバーの場合には、サーバースタブ９１８のオブジェクトコードと、サーバーの初期コード１３０８と、サーバーのアプリケーションコード又はリモート手順９１４と、サーバーのＲＰＣランタイムライブラリー９１６とが、リンカー１３０２を使用してリンクされて、サーバー実行コード１３０６を発生する。
【００８３】
慣習的に、発呼コード及び被呼手順は、同じアドレススペースを共有する。ＲＰＣアプリケーションでは、発呼コード及び被呼リモート手順は、リンクされず、むしろ、ＲＰＣインターフェイスを経て間接的に通信する。ＲＰＣインターフェイスは、一般に、リモート手順のセットに対する契約として働くオペレーション、データ形式及び定数の論理的グループである。ＲＰＣインターフェイスは、通常、インターフェイス定義言語（ＩＤＬ）を使用してアプリケーションデベロッパーにより書き込まれた公式のインターフェイス定義からコンパイルされる。
【００８４】
分散型アプリケーションを開発する際に、インターフェイス定義がＩＤＬにおいて定義されねばならない。ＩＤＬコンパイラーは、一般に、インターフェイス定義を使用して、ヘッダーファイル、クライアントスタブファイル、及びサーバースタブファイルを発生する。ＩＤＬコンパイラーは、ヘッダーファイルを標準プログラミング言語で発生すると共に、スタブをソースファイル又はオブジェクトファイルとして発生することができる。あるアプリケーションについては、インターフェイス定義を伴う属性コンフィギュレーションファイル（ＡＣＦ）が定義されてもよい。ＡＣＦが存在する場合には、ＩＤＬコンパイラーは、それがインターフェイス定義をコンパイルするときにＡＣＦを解釈する。ＡＣＦの情報は、コンパイラーが発生するコードを変更するのに使用される。
【００８５】
各ＲＰＣインターフェイスのヘッダーは、通常、エンティティを独特に識別する１６進数であるユニバーサルユニーク識別子（ＵＵＩＤ）を含む。ＲＰＣインターフェイスを識別するＵＵＩＤは、一般に、インターフェイスＵＵＩＤとして知られている。インターフェイスＵＵＩＤは、考えられる全てのネットワークコンフィギュレーションにわたってインターフェイスを独特に識別できるよう確保する。インターフェイスＵＵＩＤに加えて、各ＲＰＣインターフェイスは、大小のバージョン番号を含む。インターフェイスＵＵＩＤ及びバージョン番号は、一緒に、システムにわたり且つ時間を通じてＲＰＣインターフェイスのインスタンスを識別するインターフェイス識別子を形成する。
【００８６】
通知
図５Ａ及び５Ｂに戻ると、ブラウザにおけるオブジェクト５０２は、一般に、ＯＭにより管理される対応する又は鏡像関係のオブジェクト５０４と同期され、変化を反映できるようにされる。同期は、リモート手順コール（ＲＰＣ）メカニズム５２８及び通知メカニズム５３０により達成することができる。
通知メカニズム５３０は、一般に、ＯＭにより管理される対応するオブジェクト５０４においてデータ又は状態（例えばＣＳＳＢｕｓＣｏｍｐ５１０）が変化したときに、ブラウザのオブジェクト５０２におけるデータ（例えばＪＳＳＢｕｓＣｏｍｐ５１８）を更新することのできる手段を与える。一実施形態において、ＣＳＳＳＷＥＶｉｅｗオブジェクト５０６は、１つ以上の通知を収集し、そしてそれらをビューショーサイクルの終りにブラウザのオブジェクト５０２へ送信する。
【００８７】
一実施形態において、次の例示的又は説明のための通知を送信することができる。以下に挙げる通知の幾つかはパラメータを必要とすることに注意されたい。他の場合には、フレームワークは、これらの通知に対するコンテクストを、その現在状態を知るだけで理解することができる。
・ＮｏｔｉｆｙＢｅｇｉｎＮｏｔｉｆｙｓ−通知のセットの開始を指示する。
・ＮｏｔｉｆｙＥｎｄＮｏｔｉｆｙｓ−通知のセットの終了を指示する。
・ＮｏｔｉｆｙＳｔａｔｅＣｈａｎｇｅｄ−状態の変更があったことを指示する。状態の変更が生じる例示的シナリオは、システムが問合せ状態に入り（そこで、ユーザは、問合せ条件を入力して、問合せを実行することができ）、次いで、コミットペンディング状態に入った（そこで、ユーザは、データ値を更新することができる）ときである。
【００８８】
・ＮｏｔｉｆｙＢｅｇｉｎＱｕｅｒｙ−ビジネスコンポーネントが、問合せ条件を受け入れる準備のできた状態にあることを指示する。
・ＮｏｔｉｆｙＥｘｅｃｕｔｅ−ビジネスコンポーネントが実行された（即ちデータベースについて問合せを実行しそしてフレッシュデータでそれ自身を再ポピュレートした）ことを指示する。この通知は、問合せ仕様を与えるための任意のパラメータを含むことができる。
・ＮｏｔｉｆｙＥｎｄＱｕｅｒｙ−問合せが完了したことを指示する。
・ＮｏｔｉｆｙＤｅｌｅｔｅＲｅｃｏｒｄ−データベースから記録が削除されたことを指示する。
【００８９】
・ＮｏｔｉｆｙＤｅｌｅｔｅＷｏｒｋＳｅｔ−ワーキングセットから記録が除去されたことを指示する。この通知は、除去する必要のあるワーキングセット行のインデックスを与えるパラメータを含むことができる。
・ＮｏｔｉｆｙＩｎｓｅｒｔＷｏｒｋＳｅｔ−現在ワーキングセットに記録が追加されたことを指示する。この通知は、ワーキングセットにおける次の記録のインデックスを与えるためのパラメータを含むことができる。
・ＮｏｔｉｆｙＩｎｓｅｒｔＷＳＦｉｅｌｄＶａｌｓ−ワーキングセットにおけるフィールドにある値（１つ又は複数）を追加する必要があることを指示する。
【００９０】
・ＮｏｔｉｆｙＮｅｗＡｃｔｉｖｅＦｉｅｌｄ−新たなフィールドがアクティブ又は現在であることを指示する。
・ＮｏｔｉｆｙＮｅｗＡｃｔｉｖｅＲｏｗ−新たな行（即ち記録）がアクティブ又は現在であることを指示する。
・ＮｏｔｉｆｙＮｅｗＤａｔａ−データに変化が生じたことを指示する。
・ＮｏｔｉｆｙＮｅｗＤａｔａＷＳ−ワーキングセットのデータに変化が生じたことを指示する。
・ＮｏｔｉｆｙＮｅｗＦｉｅｌｄＤａｔａ−特定フィールドが新たなデータを有することを指示する。この通知は、フィールドの名前を与えるパラメータを含む。
【００９１】
・ＮｏｔｉｆｙＮｅｗＦｉｅｌｄＱｕｅｒｙＳｐｅｃ−特定フィールドが新たな問合せ又はサーチ仕様を有することを指示する。
・ＮｏｔｉｆｙＮｅｗＰｒｉｍａｒｙ−新たな記録が一次記録となったことを指示する。
・ＮｏｔｉｆｙＮｅｗＲｅｃｏｒｄ−新たな記録が生成されたことを指示する。
・ＮｏｔｉｆｙＮｅｗＲｅｃｏｒｄＤａｔａ−新たに生成された記録が新たなデータを有することを指示する。
・ＮｏｔｉｆｙＮｅｗＲｅｃｏｒｄＤａｔａＷＳ−新たに生成された記録が、ワーキングセットへとポピュレートされるべき新たなデータを有することを指示する。
【００９２】
・ＮｏｔｉｆｙＮｅｗＳｅｌｅｃｔｉｏｎ−記録の選択及び選択解除を指示する。
・ＮｏｔｉｆｙＮｅｗＳｅｌｌｄｓ−多数の記録の選択を指示する。
・ＮｏｔｉｆｙＰａｇｅＲｅｆｒｅｓｈ−ＵＩをリフレッシュする必要があることを指示する。この通知は、通常、データを更新するだけではなく、ＵＩにおける一般的に実質的な変化が要求されたときに使用される。この通知は、新たなページをフェッチしそしてそれをブラウザに表示するようにサーバートリップを生じさせることができる。
・ＮｏｔｉｆｙＳｃｒｏｌｌＤａｔａ−記録をアップ又はダウン方向にスクロールする必要があることを指示する。リストアプレットのようなあるユーザインターフェイスオブジェクトは、この通知を使用して、異なる行を示すようにアップ及びダウン方向にスクロールすることができる。
【００９３】
・ＮｏｔｉｆｙＣｈａｎｇｅＳｅｌｅｃｔｉｏｎ−記録選択に変化が生じた（即ち現在行が選択されたか又は選択解除された）ことを指示する。
・ＮｏｔｉｆｙＳｅｌＭｏｄｅＣｈａｎｇｅ−選択モードの変化を指示する。一実施形態において、２つの選択モードがあり、それらは、（ｉ）一度に１つの記録を選択する；及び（ｉｉ）多数の記録を同時に選択する（例えば、１つのコマンドで多数の記録を削除する）ことを含む。
・ＮｏｔｉｆｙＴｏｔａｌｓＣｈａｎｇｅｄ−合計値を変更する必要があることを指示する。ある場合には、多数の記録が表示されるときに、あるフィールドは、全ての記録において値の概要を表示してもよい。この通知は、合計値が変化したことを指示する。
【００９４】
・ＮｏｔｉｆｙＬｏｎｇＯｐＰｒｏｇｒｅｓｓ−長い（即ち時間のかかる）アクションが進行中であることを指示する。この通知は、どの程度のタスクが現在完了したかを示す進行又は状態バーを指示するといったフィードバックをユーザに与えるためにユーザインターフェイスにより使用される。
・ＮｏｔｉｆｙＧｅｎｅｒｉｃ−これは、上述した通知のセットではカバーされない幾つかの特殊な条件をユーザインターフェイスオブジェクトに通知するために使用される一般的な通知である。各形式の一般的な通知は、ある形式の一般的な通知を別の形式の一般的な仕様から区別できるように、一般的な通知に対する名前を与えるパラメータを含むことができる。
【００９５】
一般的な通知プロセス
上述したように、ブラウザにおけるオブジェクトと、ＯＭにより管理されるオブジェクトは、１つ又は多数の計算装置に存在して動作するように構成することができる。上記で示したように、図６Ａは、ブラウザにおけるオブジェクト５０２、及びＯＭにより管理されるオブジェクト５０４が、クライアント６０２及びサーバー６０４を含む多数の計算装置６０２、６０４に存在して動作するような例示的コンフィギュレーション６００を示す。図６Ｂは、ブラウザにおけるオブジェクト５０２、及びＯＭにより管理されるオブジェクト５０４が、１つの計算装置６５２に存在して動作するような例示的コンフィギュレーション６５０を示す。
【００９６】
図１４は、図６Ａに示す多装置コンフィギュレーション６００において動作するブラウザ側又はクライアント側オブジェクト５０２とサーバー側オブジェクト５０４との間で通信を行う例示的プロセス１４００を一般的に示す。図１４の例示的通信プロセス１４００は、通常、ユーザ入力によるもので、最初に、ブラウザ側アプレットであるＪＳＳＡｐｐｌｅｔにおいて取り扱われる（ブロック１４０５）。ユーザがリンク又は他のユーザインターフェイス特徴をクリックすると、インボークメソッドが発生される。ＪＳＳＡｐｐｌｅｔは、通常、発生されたインボークメソッドを受け取る第１オブジェクトである（ブロック１４１０）。ＪＳＳＡｐｐｌｅｔは、次いで、ＪＳＳＡｐｐｌｉｃａｔｉｏｎによりリモート手順コールを発信して、サーバー側アプレットであるＣＳＳＷＥＡｐｐｌｅｔへインボークメソッドを再ターゲットとすることができる（ブロック１４１５）。このターゲットとされるサーバー側アプレットであるＣＳＳＷＥＡｐｐｌｅｔは、一般に、状態フラグをセットすることにより、ブラウザ側アプレットであるＪＳＳＡｐｐｌｅｔからのＲＰＣインボークメソッドに応答することができる（ブロック１４２０）。一実施形態において、状態フラグは、次の値の１つにセットすることができる。
【００９７】
・Ｃｏｎｔｉｎｕｅ−この値は、一般に、サーバー側アプレットであるＣＳＳＷＥＡｐｐｌｅｔが、インボークメソッドを取り扱うというその役割を実行したことを指示すると共に、ブラウザのＪＳＳＡｐｐｌｅｔがそのアクションを完了する必要があることを指示する。通知が応答において与えられるが、しばしば空である。
・Ｃｏｍｐｌｅｔｅｄ−この値は、一般に、サーバー側アプレットがインボークメソッドの取り扱いを完了したことを指示すると共に、ブラウザが、応答に与えられた通知に応答する以外の更なるアクションを実行する必要がないことも指示する。
【００９８】
・ＮｅｗＰａｇｅ−この値は、一般に、インボーク要求又は他のコマンドに対する応答が、全ての一時的ブラウザ側オブジェクトの再発生を含むブラウザにおけるページリフレッシュを要求することを指示する。ＵＲＬがブラウザへ送信され、新たなページを得ることができる。しかしながら、通知は存在しない。この値は、通常、異なるビューへのドリルダウンが要求された場合にセットされる。
・Ｅｒｒｏｒ−この値は、一般に、インボークメソッド要求が失敗したことを指示する。Ｅｒｒｏｒ状態を受け取ると、ＪＳＳＡｐｐｌｅｔは、通常、エラーページを表示する。
【００９９】
ブラウザ側アプレットであるＪＳＳＡｐｐｌｅｔがＲＰＣによりサーバーをコールするときには、ブラウザ側アプレットが、通常、応答において状態フラグを見て、それを取り扱う（ブロック１４２５）。返送される状態がＥｒｒｏｒである場合には、ブラウザ側アプレットは、エラーページを示す。返送される状態がＣｏｍｐｌｅｔｅｄである場合には、サーバーは、一般に、インボークメソッドを既に取り扱ったことを指示すると共に、ブラウザが行うべきことは何も残されていないことも指示する。返送される状態がＣｏｎｔｉｎｕｅである場合には、サーバーは、一般に、インボークメソッドを取り扱わないことを指示する。ブラウザ側アプレットは、一般に、Ｃｏｎｔｉｎｕｅの返送状態に応答して、ＪＳＳＢｕｓＣｏｍｐオブジェクトにおいてメソッドを直接インボークすることによりＪＳＳＢｕｓＣｏｍｐオブジェクトへメソッドを再指向する。ＪＳＳＢｕｓＣｏｍｐオブジェクトは、インボークメソッド要求を満足することができるか、又はＪＳＳＡｐｐｌｉｃａｔｉｏｎを経てそれに対応するサーバー側ビジネスコンポーネントへそれ自身のＲＰＣコールを送信しなければならない。
【０１００】
図１５は、ブラウザ側アプレットがＪＳＳＢｕｓＣｏｍｐオブジェクトにおいてメソッドを直接インボークする例示的通信プロセス１５００を示す。図１５のプロセス１５００は、図６Ａに示された多装置コンフィギュレーションにおいてプロセスが生じたかのように以下に説明することに注意されたい。ブロック１５０５において、ブラウザ側アプレットＪＳＳＡｐｐｌｅｔは、メソッドをＪＳＳＢｕｓＣｏｍｐオブジェクトへリダイレクトする。ブロック１５１０において、クライアント側ビジネスコンポーネントオブジェクトＪＳＳＢｕｓＣｏｍｐは、次いで、ＪＳＳＡｐｐｌｉｃａｔｉｏｎオブジェクトを経てサーバー側ビジネスコンポーネントＣＳＳＢｕｓＣｏｍｐへリモート手順コールを発生する。サーバー側ビジネスコンポーネントは、一般に、ＲＰＣメソッドコールを処理し、状態をセットして返送すると共に、適当なケースにおいて通知のセットを返送する（ブロック１５１５）。一実施形態において、状態フラグは、次の値をもつことができる。
【０１０１】
・Ｃｏｍｐｌｅｔｅｄ−この値は、一般に、サーバー側ビジネスコンポーネントＣＳＳＢｕｓＣｏｍｐが一般にインボークメソッドを首尾良く処理したことを指示する。通常、通知が生じる。
・Ｅｒｒｏｒ−この値は、一般に、サーバー側ビジネスコンポーネントＣＳＳＢｕｓＣｏｍｐがインボークメソッドコールを首尾良く処理しなかったことを指示する。Ｅｒｒｏｒの返送状態を受け取ると、ブラウザは、通常、エラーページを表示する。
【０１０２】
ブロック１５２０において、クライアント側ビジネスコンポーネント（ＪＳＳＢｕｓＣｏｍｐ）は、返送された状態フラグを検査し、そして適宜に応答する。インボークメソッドコールが、ブラウザとサーバービジネスコンポーネントとの間に同期を必要とするアクションを実行する場合には、サーバーにコンタクトすることに注意されたい。更に、ＪＳＳＢｕｓＣｏｍｐオブジェクトが、サーバーにコンタクトする必要なく要求をローカルで取り扱うことができる環境が存在することにも注意されたい。このような環境は、例えば、ユーザが次の記録オペレーションを実行し、次いで、データを変更せずに以前の記録オペレーションを実行するときである。
【０１０３】
ブラウザ側オブジェクトにより潜在的にサポートされるメソッド
一実施形態において、ブラウザ側オブジェクトによって潜在的にサポートすることのできるメソッドは、次のカテゴリー、即ちベースオブジェクトメソッド、アプリケーションメソッド、ビジネスコンポーネントメソッド、サービスメソッド、及びアプレットメソッドに分割することができる。説明上、各カテゴリーにおける例示的メソッドを挙げて以下に一般的に説明する。
ほとんどのブラウザ側オブジェクトは、通常、次のベースオブジェクトメソッドを継承する。
【０１０４】
ＡｄｄＥｒｒｏｒＭｓｇ（ｅｒｒｃｏｄｅ、ｐａｒａｍｓ、ａｐｐｅｎｄ）
一般的説明：現在オブジェクトに対するエラーチェーンにエラーメッセージを追加する。
ＡｄｄＥｒｒｏｒＭｓｇＴｅｘｔ（ｅｒｒＣｏｄｅ、ｅｒｒＭｓｇ、ａｐｐｅｎｄ）
一般的説明：現在オブジェクトに対するエラーチェーンにエラーメッセージを追加する。
ＣｌｅａｒＥｒｒｏｒＭｓｇ（）
一般的説明：現在オブジェクトに対するエラーチェーンをクリアする
ＣｏｐｙＥｒｒｏｒｍｓｇ（ｉｎｐｕｔＯｂｊｅｃｔ）
一般的説明：パスしたオブジェクトｉｎｐｕｔｏｂｊｅｃｔから現在オブジェクトへエラーチェーンをコピーする
【０１０５】
ＦｏｒｍａｔＳｔｒｉｎｇ（ｆｏｒｍａｔ、ｐａｒａｍｅｔｅｒｓ）
一般的説明：フォーマットにおける「％Ｗ」エスケープを、ｐａｒａｍｓアレーで指定された等価パラメータに置き換えることにより、パラメータをフォーマットに代入する。
ＧｅｔＡｐｐｌｉｃａｔｉｏｎ（）
一般的説明：グローバルアプリケーションオブジェクトを返送する。
ＧｅｔＥｒｒｏｒＣｏｄｅ（）
一般的説明：エラーチェーンにおける最も上位のエラーコードを返送する。エラーコードは、一般に、ストリングである。空のストリングは、通常、エラーがないことを指示する。
【０１０６】
ＧｅｔＥｒｒｏｒＣｏｕｎｔ（）
一般的説明：現在オブジェクトに対するエラーチェーンの長さを返送する。
ＧｅｔＥｒｒｏｒＭｓｇ（ｉｎｄｅｘ）
一般的説明：現在オブジェクトに対するエラーチェーンから第ｎ番目のエラーメッセージテキストストリングを返送する。インデックスは、ゼロベースであることに注意されたい。
ＧｅｔＮｔｈＥｒｒｏｒＣｏｄｅ（ｉｎｄｅｘ）
一般的説明：現在オブジェクトに対するエラーチェーンから第ｎ番目のエラーコードを返送する。
【０１０７】
ＨａｓＥｒｒｏｒＭｓｇ（）
一般的説明：現在オブジェクトが何らかの登録されたエラーを有するかどうか調べるためにチェックする。
ＬｏｃｋＥｒｒｏｒＭｓｇ（）
一般的説明：付加的なエラーが現在オブジェクトに対して登録され又はクリアされるのを防止する。
ＳｅｔＥｒｒｏｒＭｏｇ（ｅｒｒＣｏｄｅ、ｐａｒａｍｓ、ｃｈｉｌｄ）
一般的説明：現在オブジェクトに関するエラーを登録する。ＥｒｒＣｏｄｅは、一般に、メッセージテーブルに登録されてエラーメッセージフォーマットストリングへとマップされたキーである。Ｐａｒａｍｓは、フォーマットが、パラメータ、即ちストリングパラメータ値を含むアレー又は「％１」に代入される単一値を必要としない場合にナルである。
【０１０８】
ＳｅｔＥｒｒｏｒＭｓｇＴｅｘｔ（ｅｒｒＣｏｄｅ、ｅｒｒＭｓｇ）
一般的説明：現在オブジェクトに関するエラーを登録する。
ＴｅｘｔＴｏＨＴＭＬ（ｔｅｘｔ）
一般的説明：入力されたテキストに対してＨＴＭＬ安全ストリングを返送する
ＴｒａｎｓｌａｔｅＥｒｒｏｒ（ｅｒｒＣｏｄｅ、ｐａｒａｍｓ）
一般的説明：指定のメッセージキー及びパラメータに対してフォーマットされたストリングを返送する。
ＵｎＬｏｃｋＥｒｒｏｒＭｓｇ（）
一般的説明：エラー登録を取り扱いそして現在オブジェクトをクリアするのを再開する。
【０１０９】
一実施形態において、各ブラウザ側アプリケーションオブジェクトは、通常、次のアプリケーションメソッドをサポートすることができる。
ＡｄｄＢｕｓｏｂｊ（ｂｕｓＯｂｊ）
一般的説明：インスタンス生成されるビューに対してＢｕｓＯｂｊを追加する。ＳＷＥによってのみコールされる。
ＡｄｄＲｏｗＣｏｕｎｔｅｒＴｅｍｐｌａｔｅ（ｋｅｙ、ｔｅｍｐｌ）
一般的説明：考えられる行カウンタフォーマットの１つに対してストリングフォーマットテンプレートを追加する。
【０１１０】
ＡｄｄＶｉｅｗ（ｖｉｅｗ）
一般的説明：新たなビューオブジェクトを追加する。
ＣａｎＩｎｖｏｋｅＭｅｔｈｏｄ（ｎａｍｅ）
一般的説明：所与のメソッドをインボークすることができるかどうか確認する。
ＣｌｏｓｅＰＯＰＵＰ（）
一般的説明：アクティブなポップアップアプレット／制御をクローズする。
ＣｒｅａｔｅＯｂｊ（ｊｓｓＯｂｊＮａｍｅ）
一般的説明：タイプ名が与えられると、ＪａｖａＳｃｒｉｐｔオブジェクトを生成する。
【０１１１】
ＤｉｓｐａｔｃｈＢＣＮｏｔｉｆｉｃａｔｉｏｎｓ（ｒｅｔｕｒｎＰｒｏｐＳｅｔ）
一般的説明：ＲＰＣによりＳＷＥサーバーへ返送された通知を適当なＢｕｓＣｏｍｐインスタンスへルーティングする。
ＥｎｕｍＢｕｓＯｂｊｓ（ｆｉｒｓｔ）
一般的説明：アプリケーションに登録されたビジネスオブジェクトを通して繰り返す。
ＥｎｕｍＳｅｒｖｉｃｅｓ（ｆｉｒｓｔ）
一般的説明：クライアントによりロードされたサービスを通して繰り返す。
ＥｎｕｍＶｉｅｗｓ（ｆｉｒｓｔ）
一般的説明：アプリケーションに登録されたビューを通して繰り返す。
【０１１２】
ＧｅｔＢｕｓＯｂｊ（ｎａｍｅ）
一般的説明：名前によりビジネスオブジェクトを返送する。
ＧｅｔＢｕｓＯｂｊＺｏｎｅ（ｚｏｎｅ）
一般的説明：ビジネスオブジェクトに関連したウェブエンジン（ＷＥ）「ゾーン」を返送する。
ＧｅｔＣｏｍｍａｎｄＭｇｒ（）
一般的説明：ツールバー及びメニューに対するＵＩコマンドを取り扱いそして発送するトップレベルコマンドマネージャーを返送する。
ＧｅｔＥｄｉｔＣａｐｔｉｏｎ（）
一般的説明：編集モードアプレットに対するキャプションを返送する。
【０１１３】
ＧｅｔＥｄｉｔＣｔｌＴｙｐｅ（）
一般的説明：編集モードアプレットに対する制御形式を返送する。
ＧｅｔＨｔｍｌＦｒａｍｅＭｇｒ（）
一般的説明：新たなコンテンツをダウンロードするためのフレームを管理するオブジェクトを返送する。
ＧｅｔＪｓｓＩｎｆｏ（ｂｕｓＯｂｊＺｏｎｅ、ａｐｐｌｅｔＮａｍｅ、ｕｒｌ）
一般的説明：ＨＴＭＬフレームマネージャーを使用して、指定のＵＲＬをロードする。
ＧｅｔＬｏｃａｌＳｔｒｉｎｇ（ｋｅｙ）
一般的説明：指定のキーに対する変換されたキーを返送する。これらの変換されたストリングは、通常、メッセージテーブルに記憶され、そして始動時にクライアントにダウンロードされる。
【０１１４】
ＧｅｔＬｏｃａｌｅ（）
一般的説明：ローカルオブジェクトを返送する。
ＧｅｔＭａｉｎＶｉｅｗ（）
一般的説明：アプリケーションの現在ビューを返送する。
ＧｅｔＰａｇｅＵＲＬ（）
一般的説明：現在トップレベルページに対するＵＲＬを返送する。
ＧｅｔＰｒｏｆｉｌｅＡｔｔｒ（ａｔｔｒＮａｍｅ）
一般的説明：命名されたプロフィール属性の値をサーバーへ返送する。
ＧｅｔＲｏｗＣｏｕｎｔｅｒＴｅｍｐｌｅｔｅ（ｋｅｙ）
一般的説明：行カウンタフォーマットの１つに対するストリングフォーマットテンプレートを返送する。
【０１１５】
ＧｅｔＳｅｒｖｉｃｅ（ｎａｍｅ）
一般的説明：指定のサービスオブジェクトをローカルで且つサーバーにロードする。指定のサービスが既にロードされている場合には、基準カウントを単に増加する。
ＧｅｔＶｉｅｗ（ｂｕｓＯｂｊＺｏｎｅ）
一般的説明：ビジネスオブジェクトの「ゾーン」に対応するビューを得る。
ＩｎｖｏｋｅＭｅｔｈｏｄ（ｎａｍｅ、ｉｎｐｕｔＰｒｏｐＳｅｔ）
一般的説明：アプリケーションにおいて命名されたメソッドをインボークする。
ＰｒｏｃｅｓｓＣｌｏｓｅＰｏｐｕｐ（ｒｅｔｕｒｎＰｒｏｐＳｅｔ）
一般的説明：配達処理されたときにポップアップをクローズする。
ＰｒｏｃｅｓｓＣｏｎｆｉｒｍＤｉａｌｏｇ（ｅｒｒＯｂｊ、ｒｅｔｕｒｎＰｒｏｐＳｅｔ）
一般的説明：配達処理されたときに確認ダイアログを取り扱う。
【０１１６】
ＰｒｏｃｅｓｓＥｒｒｏｒ（ｏｂｊｅｃｔ）
一般的説明：所与のオブジェクトに登録されたエラーに対するエラーダイアログを持ち出す。
ＰｒｏｃｅｓｓＮｅｗＰａｇｅ（ｒｅｔｕｒｎＰｒｏｐＳｅｔ）
一般的説明：配達処理されたときに新たなページ発生をインボークする。
ＰｒｏｃｅｓｓＲＰＣＥｒｒｏｒｓ（ｅｒｒＯｂｊ、ｒｅｔｕｒｎＰｒｏｐＳｅｔ）
一般的説明：コールによりサーバー上のウェブエンジンへ返送されたエラーを取り扱う。
ＰｒｏｃｅｓｓＲＰＣＮｏｔｉｆｉｃａｔｉｏｎｓ（ｅｒｒＯｂｊ、ｒｅｔｕｒｎＰｒｏｐＳｅｔ）
一般的説明：コールにおいてウェブエンジンへ返送される通知を取り扱う。
ＰｒｏｃｅｓｓＲＰＣＲｅｔＰｒｏｐＳｅｔＳｔｒ（ｅｒｒＯｂｊ、ｒｅｔｕｒｎＰｒｏｐＳｅｔＳｔｒ）
一般的説明：コールからウェブエンジンへ返送された特性セットを取り扱う。
【０１１７】
ＲｅｌｅａｓｅＳｅｒｖｉｃｅ（ｓｅｒｖｉｃｅ）
一般的説明：基準カウントに関わりなくサービスを直ちに解除する。
ＲｅｍｏｖｅＢｕｓＯｂｊ（ｂｕｓＯｂｊ）
一般的説明：アクティブなもののリストからビジネスオブジェクトを除去する。
ＲｅｍｏｖｅＯｂｊＦｒｏｍＡｒｒａｙ（ｏｂｊ、ａｒｒａｙＯｂｊ）
一般的説明：オブジェクトのアレーからオブジェクトを除去する。
ＷＥＡｐｐｌｅｔＣａｎＩｎｖｏｋｅ（ａｐｐｌｅｔＮａｍｅ、ｖｉｅｗＮａｍｅ、ｂｕｓＯｂｊＺｏｎｅ、ｍｅｔｈｏｄ）
一般的説明：ウェブエンジンをコールし、アプレットに基づいてメソッドをインボークすることができるかどうか決定する。
ＷＥＡｐｐｌｉｃａｔｉｏｎＣａｎＩｎｖｏｋｅ（ｍｅｔｈｏｄ）
一般的説明：ウェブエンジンをコールし、アプリケーションに基づいてメソッドをインボークすることができるかどうか決定する。
【０１１８】
ＷＥＢｕｓＣｏｍｐＣａｎＩｎｖｏｋｅ（ｂｕｓＣｏｍｐＮａｍｅ、ｂｕｓＯｂｊＺｏｎｅ、ｍｅｔｈｏｄ）
一般的説明：ウェブエンジンをコールし、ビジネスコンポーネントに基づいてメソッドをインボークすることができるかどうか決定する。
ＷＥＣａｌｌＡｐｐｌｅｔ（ａｐｐＮａｍｅ、ｖｉｅｗＮａｍｅ、ｂｕｓＯｂｊＺｏｎｅ、ｍｅｔｈｏｄ、ｉｎｐｕｔＰｒｏｐＳｅｔ）
一般的説明：ウェブエンジンをコールし、アプレットに基づいて指定のリモート手順コールをインボークする。
ＷＥＣａｌｌＡｐｐｌｉｃａｔｉｏｎ（ｍｅｔｈｏｄ、ｉｎｐｕｔＰｒｏｐＳｅｔ）
一般的説明：ウェブエンジンをコールし、アプリケーションに基づいて指定のリモート手順コールをインボークする。
ＷＥＣａｌｌＢｕｓＣｏｍｐ（ｂｕｓＣｏｍｐＮａｍｅ、ｂｕｓＯｂｊＺｏｎｅ、ｍｅｔｈｏｄ、ｉｎｐｕｔＰｒｏｐＳｅｔ）
一般的説明：ウェブエンジンをコールし、ビジネスコンポーネントに基づいて指定のリモート手順コールをインボークする。
【０１１９】
ＷＥＣａｌｌＳｅｒｖｉｃｅ（ｓｅｒｖｉｃｅＮａｍｅ、ｍｅｔｈｏｄ、ｉｎｐｕｔＰｒｏｐＳｅｔ）
一般的説明：ウェブエンジンをコールし、サービスに基づいて指定のリモート手順コールをインボークする。
ＷＥＬｏａｄＳｅｒｖｉｃｅ（ｎａｍｅ）
一般的説明：ウェブエンジンをコールし、新たなサービスをロードする。
ＷＥＳｅｒｖｉｃｅＣａｎＩｎｖｏｋｅ（ｓｅｒｖｉｃｅＮａｍｅ、ｍｅｔｈｏｄ）
一般的説明：ウェブエンジンをコールし、サービスに基づいてメソッドをインボークすることができるかどうか決定する。
ＳｅｔＥｄｉｔＣａｐｔｉｏｎ（ｅｄｉｔＣａｐｔｉｏｎ）
一般的説明：編集モードに使用されるキャプションを設定する。
【０１２０】
ＳｅｔＥｄｉｔＣｔｌＴｙｐｅ（ｅｄｉｔＣｔｌＴｙｐｅ）
一般的説明：編集モードに使用される制御形式を設定する。
ＳｅｔＨｔｍｌＦｒａｍｅＭｇｒ（ｈｔｍｌＦｒａｍｅＭｇｒ）
一般的説明：ＨＴＭＬフレームマネージャーインスタンスを設定する。
ＳｅｔＭａｉｎＶｉｅｗ（ｖｉｅｗ）
一般的説明：メインビューを定義する。
ＳｅｔＰａｇｅＵＲＬ（ｐａｇｅＵｒｌ）
一般的説明：アプリケーションに対してベースＵＲＬを設定する。
【０１２１】
ＳｅｔＰｒｏｆｉｌｅＡｔｔｒ（ａｔｔｒＮａｍｅ、ｖａｌｕｅ）
一般的説明：命名されたユーザプロフィール属性を指定の値に変更する。
ＳｅｔＷＳＦｒａｍｅ（ｗｅＦｒａｍｅＮａｍｅ）
一般的説明：ＨＴＭＬフレームマネージャーに対して特殊なフレームを定義する。
ＳｈｏｗＰｏｐｕｐ（ｕｒｌ、ｈｅｉｇｈｔ、ｗｉｄｔｈ）
一般的説明：ポップアップアプレット又は制御を向上させる。
【０１２２】
一実施形態において、各ブラウザ側ビジネスコンポーネントオブジェクトは、通常、次のビジネスコンポーネントメソッドをサポートすることができる。
ＡｄｄＦｉｅｌｄ（ｎａｍｅ、・・・）
一般的説明：ビジネスコンポーネントを初期化するときにフィールドに対するコンフィギュレーション情報を指定する。
ＡｄｄＰｉｃｋＬｉｓｔ（ｆｉｅｌｄＮａｍｅ、ｐｉｃｋｌｉｓｔ）
一般的説明：ビジネスコンポーネントを初期化するときにフィールドに対するピックアップコンフィギュレーションを指定する。
ＡｄｄＲｅｃｏｒｄ（ｒｅｃｏｒｄ）
一般的説明：ビジネスコンポーネントを初期化するときに初期記録データを指定する。
【０１２３】
ＡｄｄＵｓｅｒＰｒｏｐ（ｐｒｏｐＮａｍｅ、ｖａｌｕｅ）
一般的説明：初期化中にビジネスコンポーネントに対し構成されたユーザ特性を指定する。
ＡｄｄＦｉｅｌｄＵｓｅｒＰｒｏｐ（ｆｉｅｌｄＮａｍｅ、ｐｒｏｐＮａｍｅ、ｖａｌｕｅ）
一般的説明：ビジネスコンポーネントの初期化中にフィールドに対し構成されたユーザ特性を指定する。
ＣａｌｌＳｅｒｖｅｒＢＣ（ｍｅｔｈｏｄ、ｉｎｐｕｔＰｒｏｐｓ）
一般的説明：メソッドをサーバー上のビジネスコンポーネントへ送信する。
ＣａｎＤｅｌｅｔｅ（）
一般的説明：ユーザが現在ビジネスコンポーネントから現在記録を削除できるかどうか決定する。
【０１２４】
ＣａｎＩｎｓｅｒｔ（ｄｙｎａｍｉｃ）
一般的説明：現在ビジネスコンポーネントに新たな記録を挿入できるかどうか決定する。
ＣａｎｉｎｖｏｋｅＭｅｔｈｏｄ（ｍｅｔｈｏｄ）
一般的説明：命名されたメソッドを現在ビジネスコンポーネントにおいてインボークすることができるかどうか決定する。
ＣａｎＭｅｒｇｅＲｅｃｏｒｄ（）
一般的説明：現在ビジネスコンポーネントにおいてユーザが記録を合体できるかどうか決定する。
ＣａｎＱｕｅｒｙ（）
一般的説明：現在ビジネスコンポーネントが問合せをサポートできるかどうか決定する。
【０１２５】
ＣａｎＵｐｄａｔｅ（ｄｙｎａｍｉｃ）
一般的説明：現在記録を更新できるかどうか決定する。
ＣａｎＵｐｄａｔｅＦｉｅｌｄ（ｆｉｅｌｄＮａｍｅ）
一般的説明：指定のフィールドを更新できるかどうか決定する。
Ｃｌｅａｎｕｐ（）
一般的説明：オブジェクトが破壊される前にクリーンアップを実行する。
ＣｌｅａｒＵｐｄａｔｅ（）
一般的説明：サーバーへ送信されなかった現在記録に対する保留中更新を除去する。
ＣｏｐｙＲｅｃｏｒｄ（ｂｅｆｏｒｅ）
一般的説明：新たな記録を生成し、そして現在記録の値を新たな記録へコピーする。
【０１２６】
ＤｅｌｅｔｅＲｅｃｏｒｄ（）
一般的説明：現在記録を削除する。
ＤｉｓａｂｌｅＮｏｔｉｆｙ（）
一般的説明：通知メッセージを保留する。
ＥｎａｂｌｅＮｏｔｉｆｙ（）
一般的説明：通知メッセージの送信を再開する。
Ｅｎｄ（）
一般的説明：現在記録を最後の記録へ移動する。
ＥｎｕｍＦｉｅｌｄｓ（ｆｉｒｓｔ）
一般的説明：ビジネスコンポーネントにおいて定義されたフィールドを経て繰り返す。
【０１２７】
ＥｎｕｍＵｓｅｒＰｒｏｐｓ（ｓｔａｒｔ）
一般的説明：ビジネスコンポーネントにおいて定義されたユーザ特性を経て繰り返す。
ＥｎｕｍＦｉｅｌｄＵｓｅｒＰｒｏｐｓ（ｓｔａｒｔ、ｆｉｅｌｄＮａｍｅ）
一般的説明：命名されたフィールドにおいて定義されたユーザ特性を経て繰り返す。
ＧｅｔＡｃｔｉｖｅＦｉｅｌｄＡｒｒａｙ（）
一般的説明：現在アクティブなフィールドの名前のアレーを返送する。
ＧｅｔＡｃｔｉｖｅＲｏｗ（）
一般的説明：現在行のワーキングセットへインデックスを返送する。
【０１２８】
ＧｅｔＢｕｓＯｂｊ（）
説明：現在ビジネスコンポーネントを所有するビジネスオブジェクトを返送する。
ＧｅｔＦｉｅｌｄＤｅｆ（ｆｉｅｌｄＮａｍｅ）
一般的説明：命名されたフィールドに対するフィールドオブジェクトを返送する。
ＧｅｔＦｉｅｌｄＩｎｄｅｘ（ｆｉｅｌｄＮａｍｅ）
一般的説明：インデックスをフィールドアレーへ返送し、そして所与のフィールドに対するアレーを記録する。
ＧｅｔＩｄＶａｌｕｅ（）
一般的説明：現在記録に対する行ＩＤ値を返送する。
【０１２９】
ＧｅｔＦｉｅｌｄＴｏｔａｌ（ｆｉｅｌｄＮａｍｅ）
一般的説明：命名されたフィールドに対する合計を返送する。
ＧｅｔＦｉｅｌｄＶａｌｕｅ（ｆｉｅｌｄＮａｍｅ）
一般的説明：現在行からの命名されたフィールドの値を返送する。
ＧｅｔＦｏｒｍａｔｔｅｄＶａｌｕｅ（ｆｉｅｌｄＮａｍｅ、ｆｏｒｍａｔ）
一般的説明：現在ローカル設定に対してフォーマットされそしてフィールド形式に基づく現在行からの命名されたフィールドの値を返送する。
ＧｅｔＬｏｃａｌｅ（）
一般的説明：システムに対するローカルオブジェクトを返送する。
【０１３０】
ＧｅｔＮａｍｅ（）
一般的説明：ビジネスコンポーネントの名前を返送する。
ＧｅｔＮｏｔｉｆｙＯｂｊ（ｎｔｆｙＩｄ）
一般的説明：所与のＩＤに対する通知オブジェクトを返送する。
ＧｅｔＮｕｍＲｏｗ（）
一般的説明：現在ビジネスコンポーネントから見た行の数のカウントを返送する。
ＧｅｔＰａｒｅｎｔＢＣ（）
一般的説明：もし得られれば、現在ビジネスコンポーネントの親ビジネスコンポーネントを返送する。
ＧｅｔＰｉｃｋＬｉｓｔ（ｆｉｅｌｄＮａｍｅ）
一般的説明：命名されたフィールドに対するピックリストオブジェクトを返送する。
【０１３１】
ＧｅｔＲｏｗＮｕｍ（）
一般的説明：行番号を返送する。
ＧｅｔＳｅａｒｃｈＳｐｅｃ（）
一般的説明：現在問合せに有効なサーチ仕様を返送する。
ＧｅｔＦｉｅｌｄＳｅａｒｃｈＳｐｅｃ（ｆｉｅｌｄＮａｍｅ）
一般的説明：指定されたフィールドに有効なサーチ仕様を返送する。
ＧｅｔＳｏｒｔＳｐｅｃ（）
一般的説明：現在問合せに有効な分類仕様を返送する。
ＧｅｔＵｓｅｒＰｒｏｐ（ｐｒｏｐｎａｍｅ）
一般的説明：現在ビジネスコンポーネントにおける命名されたユーザ特性の値を返送する。
【０１３２】
ＧｅｔＦｉｅｌｄＵｓｅｒＰｒｏｐ（ｆｉｅｌｄＮａｍｅ、ｐｒｏｐＮａｍｅ）
一般的説明：指定のフィールドにおける命名されたユーザ特性の値を返送する。
ＨａｎｄｌｅＳｅｒｖｅｒＮｏｔｉｆｉｃａｔｉｏｎ（ｐｒｏｐＳｅｔ）
一般的説明：現在ビジネスコンポーネントに対しサーバーからの通知メッセージを処理する。このメソッドは、サーバーから返送される付加的な情報を収集して、その内部状態を更新する。又、これは、通知メッセージを適宜に伝播する。
ＨａｓＰｉｃｋＬｉｓｔ（ｆｉｅｌｄＮａｍｅ）
一般的説明：所与のフィールドが規定のピックリストを有するかどうか決定する。
ＨａｓＦｉｅｌｄＴｏｔａｌｓ（）
一般的説明：ビジネスコンポーネントが任意のフィールドの合計を計算できるかどうか決定する。
【０１３３】
Ｈｏｍｅ（）
一般的説明：現在行を問合せにおける第１行にセットする。
Ｉｎｉｔｉａｌｉｚｅ（）
一般的説明：ビジネスコンポーネントの状態を、それが完全にロードされた後であって且つその最初の使用の前に設定する。
ＩｎｖｏｋｅＭｅｔｈｏｄ（ｎａｍｅ、ｉｎｐｕｔＰｒｏｐＳｅｔ）
一般的説明：現在ビジネスコンポーネントにおける命名されたメソッドをコールする。
ＩｓＣｕｒＷＳＲｅｃＡｃｔｉｖｅ（ｎｔｆｙＩｄ）
一般的説明：この通知オブジェクトの現在記録がビジネスコンポーネントのワーキングセットにおける現在記録であるかどうか決定する。
【０１３４】
ＩｓＣｕｒＷＳＲｅｃＳｅｌｅｃｔｅｄ（ｎｔｆｙＩｄ）
一般的説明：この通知オブジェクトの現在記録がビジネスコンポーネントにおいて選択されたかどうか決定する。
ＩｓＮｕｍＲｏｗｓＫｎｏｗｎ（）
一般的説明：問合せからの記録の全数が既知であるかどうか決定する。
ＮｅｘＲｅｃｏｒｄ（）
一般的説明：ビジネスコンポーネントにおける現在記録を問合せにおける次の記録へ移動する。
ＮｅｘｔＳｅｔ（）
一般的説明：ワーキングセットをダウン方向にスクロールする。
ＮｅｗＡｃｔｉｖｅＲｏｗ（ｉｎｄｅｘ）
一般的説明：現在行が変化するときに内部状態を更新する。
【０１３５】
ＮｅｗＦｉｅｌｄＤａｔａ（ｆｉｅｌｄＮａｍｅ、ｖａｌｕｅ）
一般的説明：サーバーにおいてフィールド値が変化するときに内部状態を更新する。
ＮｅｗＲｅｃｏｒｄ（ｂｅｆｏｒｅ）
一般的説明：ビジネスコンポーネントにおける新たな記録をデフォールトフィールド値で生成する。
ＰｏｓｉｔｉｏｎＢｙＩｄ（ｉｄ）
一般的説明：現在問合せにおける記録を指定のＲＯＷ−ＩＤで探索し、そしてそれを現在記録とする。
ＰｒｉｏｒＲｅｃｏｒｄ（）
一般的説明：現在記録を現在問い合わせにおいて１行後退する。
ＰｒｉｏｒＳｅｔ（）
一般的説明：ワーキングセットをアップ方向にスクロールする。
【０１３６】
ＲｅｄｏＲｅｃｏｒｄ（）
一般的説明：以前に除去された変化を再適用する。
ＲｅｇＮｏｔｉｆｙＯｂｊ（ｎｏｔｉｆｙ）
一般的説明：通知オブジェクトをビジネスコンポーネントに登録する。
ＳｅｔＡｃｔｉｖｅＲｏｗ（ｒｏｗ）
一般的説明：ビジネスコンポーネントにおける現在行を、ワーキングセットへの指定のインデックスにセットする。
ＳｅｔＢｕｓＯｂｊ（ｂｕｓＯｂｊ）
一般的説明：現在ビジネスコンポーネントを所有するビジネスオブジェクトをセットする。
ＳｅｔＦｉｅｌｄＶａｌｕｅ（ｆｉｅｌｄＮａｍｅ、ｖａｌｕｅ）
一般的説明：現在記録における指定フィールドの値を所与の値に変更する。
【０１３７】
ＳｅｔＦｏｒｍａｔｔｅｄＶａｌｕｅ（ｆｉｅｌｄＮａｍｅ、ｖａｌｕｅ、ｆｏｒｍａｔ）
一般的説明：現在記録における指定フィールドの値を所与の値にセットする。
ＳｅｔＮａｍｅ（ｎａｍｅ）
一般的説明：ビジネスコンポーネントの名前をセットする。
ＳｅｔＰａｒｅｎｔＢＣ（ｂｕｓＣｏｍｐ）
一般的説明：親ビジネスコンポーネントを子に対してセットする。
ＳｅｔＳｅａｒｃｈＳｐｅｃ（ｓｐｅｃ）
一般的説明：初期問合せに有効なサーチ仕様をセットする。
ＳｅｔＦｉｅｌｄＳｅａｒｃｈＳｐｅｃ（ｆｉｅｌｄＮａｍｅ、ｓｐｅｃ）
一般的説明：指定のフィールドに有効なサーチ仕様をセットする。
【０１３８】
ＳｅｔＳｏｒｔＳｐｅｃ（ｓｐｅｃ）
一般的説明：分類仕様を初期問合せに有効にセットする。
ＳｅｔＴｏｔａｌｓＲｅｃｏｒｄ（ｒｅｃｏｒｄ）
一般的説明：現在問合せに対する合計値を含む記録をセットする。
ＳｅｔＷｏｒｋＳｅｔＳｉｚｅ（ｎｔｆｙＩｄ、ｓｉｚｅ）
一般的説明：指定の通知オブジェクトに対しワーキングセットに表示される記録の数をセットする。
ｔｏＳｔｒｉｎｇ（）
一般的説明：ビジネスコンポーネントの名前を含むストリングを返送する。
ＵｎｄｏＲｅｃｏｒｄ（）
一般的説明：最後のＷｒｉｔｅＲｅｃｏｒｄ（）がインボークされて以来の全ての変化を取り消す。
【０１３９】
ＵｎＲｅｇＮｏｔｉｆｙＯｂｊ（ｎｔｆｙＩｄ）
一般的説明：ＩＤにより識別された通知オブジェクトの登録を除去する。
ＵｐｄａｔｅＲｅｃｏｒｄ（）
一般的説明：現在記録を、ＳｅｔＦｉｅｌｄＶａｌｕｅ（）がコールされるモードに入れる。
ＷｒｉｔｅＲｅｃｏｒｄ（）
一般的説明：保留中の変更をサーバーへ送信し、そしてそれらをデータベースへ書き込む。
ＷＳＥｎｄ（ｎｔｆｙＩｄ）
一般的説明：指定の通知オブジェクトに対する現在記録を問合せの終りへ移動する。
ＷＳＧｅｔＦｉｅｌｄＶａｌｕｅ（ｎｔｆｙＩｄ、ｆｉｅｌｄＮａｍｅ）
一般的説明：指定の通知オブジェクトの現在記録からフィールド値を返送する。
【０１４０】
ＷＳＧｅｔＦｏｒｍａｔｔｅｄＶａｌｕｅ（ｎｔｆｙＩｄ、ｆｉｅｌｄＮａｍｅ、ｆｏｒｍａｔ）
一般的説明：現在通知オブジェクトに対する現在記録からフィールド値を返送する。
ＷＳＧｅｔＢｅｇＲｏｗ（ｎｔｆｙＩｄ）
一般的説明：指定の通知オブジェクトのワーキングセットにおける第１記録に対応する行数を返送する。
ＷＳＧｅｔＣｕｒｒＲｏｗ（ｎｔｆｙＩｄ）
一般的説明：指定の通知オブジェクト内の現在記録のインデックスを返送する。
ＷＳＨｏｍｅ（ｎｔｆｙＩｄ）
一般的説明：指定の通知オブジェクトに対する現在記録を問合せの開始へ移動する。
【０１４１】
ＷＳＮｅｘｔＲｅｃｏｒｄ（ｎｔｆｙＩｄ）
一般的説明：現在記録を、指定の通知オブジェクトに対する次の記録へ移動する。
ＷＳＳｅｌｅｃｔＲｏｗ（ｎｔｆｙ、ｒｏｗ）
一般的説明：指定の通知オブジェクトに対する現在記録をこのワーキングセット内の指定のインデックスへ移動する。
ＷＳＳｅｌｅｃｔＲｏｗＢｙＩｄ（ｎｔｆｙＩｄ、ｉｄ）
一般的説明：行ＩＤ及びコールＷＳＳｅｌｅｃｔＲｏｗ（）によりこの通知オブジェクト内の行を見つける。
ＷＳＳｅｔＣｕｒｒＲｏｗ（ｎｔｆｙＩｄ、ｃｕｒｒｏｗ）
一般的説明：行ＩＤにより識別された問合せにおける通知オブジェクト記録に対する現在記録を移動する。
【０１４２】
一実施形態において、各ブラウザ側サービスオブジェクトは、通常、次のサービスメソッドをサポートする。
ＡｄｄＲｅｆ（）
一般的説明：基準をサービスに追加して、それが自動的に解除されないようにする。
ＣａｎＩｎｖｏｋｅＭｅｔｈｏｄ（ｎａｍｅ）
一般的説明：命名されたメソッドを現在サービスにおいてインボークすることができるかどうか決定する。
ＦｉｎｄＡｐｐｌｅｔ（ｎａｍｅ）
一般的説明：命名されたアプレットをメインビューで見つける。
ＧｅｔＡｐｐｌｉｃａｔｉｏｎ（）
一般的説明：グローバルアプリケーションオブジェクトに対するポインタを返送する。
【０１４３】
ＧｅｔＢｕｓＣｏｍｐ（）
一般的説明：現在サービスに関連したビジネスを返送する。
ＧｅｔＮａｍｅ（）
一般的説明：現在サービスの名前を返送する。
ＩｎｖｏｋｅＭｅｔｈｏｄＡｓＳｔｒｉｎｇ（ｎａｍｅ、ａｒｇＳｔｒｉｎｇ）
一般的説明：このメソッドは、一般に、ストリングが既にフォーマットされた特性セットであるときにはＩｎｖｏｋｅＭｅｔｈｏｄ（）に対する便利なインターフェイスである。実施のためにＩｎｖｏｋｅＭｅｔｈｏｄ（）をコールする。
Ｉｎｖｏｋｅｍｅｔｈｏｄ（ｎａｍｅ、ｉｎｐｕｔＰｒｏｐＳｅｔ）
一般的説明：現在サービスにおけるメソッドをインボークする。
【０１４４】
Ｒｅｌｅａｓｅ（）
一般的説明：サービスの解除を許すために、ＡｄｄＲｅｆ（）により生成された基準を除去する。
ＳｅｔＡｐｐｌｉｃａｔｉｏｎ（ａｐｐ）
一般的説明：サービスにおけるアプリケーションオブジェクトポインタをセットする。
ＳｅｔＢｕｓＣｏｍｐ（ｂｕｓＣｏｍｐ）
一般的説明：ビジネスコンポーネントを現在サービスでセットする。
ＳｅｔＮａｍｅ（ｎａｍｅ）
一般的説明：初期化中にサーバーの名前をセットする。ＳＷＥのみによりコールされる。
ＳｔｒｉｎｇＴｏＰｒｏｐＳｅｔ（ｓｔｒｉｎｇ）
一般的説明：アーギュメントストリングを特性セットに変換する。
【０１４５】
一実施形態において、各ブラウザ側アプレットは、通常、次のアプレットメソッドをサポートすることができる。
ＡｄｄＣｏｎｄｉｔｉｏｎａｌ（ｓｐａｎＩＤ、・・・）
一般的説明：アプレットにより実施されるべき条件を設定する。
ＡｄｄＣｏｎｔｒｏｌ（ｎａｍｅ、・・・）
一般的説明：アプレットにおける制御を設定する。
ＡｄｄＭｅｎｕ（ｍｅｎｕ）
一般的説明：アプレットに関連したメニューを設定する。
ＡｄｄＵｓｅｒＰｒｏｐ（ｐｒｏｐＮａｍｅ、ｖａｌｕｅ）
一般的説明：アプレットに対するユーザ特性を設定する。
【０１４６】
ＡｄｄＣｏｎｔｒｏｌＵｓｅｒＰｒｏｐ（ｃｏｎｔｒｏｌＮａｍｅ、ｐｒｏｐＮａｍｅ、ｖａｌｕｅ）
一般的説明：制御のためのユーザ特性を設定する。
ＢｕｔｔｏｎＭｅｔｈｏｄ（ｎａｍｅ、ｉｎｐｕｔＰｒｏｐＳｅｔ）
一般的説明：このメソッドは、一般に、アプレットがアクティブなアプレットであることを最初に確保するＩｎｖｏｋｅＭｅｔｈｏｄ（）に対するインターフェイスである。
ＣａｌｌＳｅｒｖｅｒＡｐｐｌｅｔ（ｍｅｔｈｏｄ、ｉｎｐｕｔＰｒｏｐｓ）
一般的説明：現在アプレットに対応するＷＥフレームへメッセージを転送する。
ＣａｎＩｎｖｏｋｅＭｅｔｈｏｄ（ｎａｍｅ）
一般的説明：所与のメソッドを現在アプレットにおいてインボークすることができるかどうか決定する。
【０１４７】
ＤｅｌｅｔｅＰｏｐｕｐ（）
一般的説明：現在アプレットからアクティブなポップアップをクローズする。
Ｃｌｏｓｅ（）
一般的説明：ビューから現在アプレットを除去する。ポップアップアプレットの場合には、親アプレットにおいて状態を回復する。
Ｃｌｅａｎｕｐ（）
一般的説明：オブジェクトが破壊される前に任意の状態をクリーンアップする。
ＥｎｕｍＵｓｅｒＰｒｏｐｓ（ｓｔａｒｔ）
一般的説明：現在アプレットにおいて定義されたユーザ特性を経て繰り返す。
ＥｎｕｍＣｏｎｔｒｏｌＵｓｅｒＰｒｏｐｓ（ｓｔａｒｔ、ｃｏｎｔｒｏｌＮａｍｅ）
一般的説明：命名された制御におけるユーザ特性を経て繰り返す。
【０１４８】
ＧｅｔＢｕｓＣｏｍｐ（）
一般的説明：現在アプレットの基礎となるビジネスコンポーネントを返送する。
ＧｅｔＣｏｎｔｒｏｌ（ｃｏｎｔｒｏｌＮａｍｅ）
一般的説明：命名された制御に対する制御データ構造を返送する。
ＧｅｔＦｉｅｌｄＣｏｎｔｒｏｌ（ｆｉｅｌｄＮａｍｅ）
一般的説明：命名されたフィールドの頂部に位置する制御オブジェクトを返送する。
ＧｅｔＦｉｅｌｄＳｏｒｔｉｎｇ（ｆｉｅｌｄＮａｍｅ）
一般的説明：命名されたフィールドに対する分類状態を返送する。
ＧｅｔＩｄ（）
一般的説明：現在アプレットに関連したＩＤを返送する。
【０１４９】
ＧｅｔＩｎｐｕｔＶａｌｕｅ（ｉｎｐｕｔ）
一般的説明：所与のＩＮＰＵＴ（制御）エレメントに含まれた値を返送する。
ＧｅｔＩｎｐｕｔＶａｌｕｅＢｙＮａｍｅ（ｎａｍｅ）
一般的説明：命名された制御のための入力から値を返送する。
ＧｅｔＮａｍｅ（）
一般的説明：アプレット名を返送する。
ＧｅｔＮｏｔｉｆｙＯｂｊ（）
一般的説明：初期化中にアプレットにより登録された通知オブジェクトを返送する。
ＧｅｔＴｉｔｌｅ（）
一般的説明：アプレットのタイトルを返送する。
【０１５０】
ＧｅｔＶａｒｉａｂｌｅ（）
一般的説明：現在アプレットを指す変数のＨＴＭＬ名を返送する。
ＧｅｔＵｓｅｒＰｒｏｐ（ｐｒｏｐＮａｍｅ）
一般的説明：命名されたユーザ特性の値を返送する。
ＧｅｔＣｏｎｔｒｏｌＵｓｅｒＰｒｏｐ（ｃｏｎｔｒｏｌＮａｍｅ、ｐｒｏｐＮａｍｅ）
一般的説明：所与の制御に対して命名されたユーザ特性の値を返送する。
ＧｅｔＶｉｅｗ（）
一般的説明：現在アプレットに対する親ビューを返送する。
ＧｅｔＰｏｐｕｐＭｅｔｈｏｄ（）
一般的説明：ポップアップアプレットの内部状態を返送する。
【０１５１】
ＧｅｔＰｏｐｕｐＣｏｎｔｒｏｌ（）
一般的説明：ポップアップアプレットの制御を返送する。ＪａｖａＳｃｒｉｐｔフレームワークによりコールされる。
ＧｅｔＰｏｐｕｐＡｐｐｌｅｔ（）
一般的説明：ポップアップアプレットの内部状態を返送する。
ＧｅｔＰｏｐｕｐＢｏｏｋｍａｒｋ（）
一般的説明：ポップアップアプレットの内部状態を返送する。
ＧｅｔＰａｒｅｎｔＡｐｐｌｅｔ（）
一般的説明：ポップアップアプレットの親アプレットを返送する。
Ｉｎｉｔｉａｌｉｚｅ（）
一般的説明：アプレットの状態を、それが生成された後であって且つそれが使用される前に設定する。
【０１５２】
ＩｎｖｏｋｅＭｅｔｈｏｄ（ｎａｍｅ、ｉｎｐｕｔＰｒｏｐＳｅｔ）
一般的説明：このアプレットにおいて特殊なメソッドをインボークする。これは、アプレット登録の新たなメソッドを特殊化する主たる方法である。
ＩｓＡｃｔｉｖｅＡｐｐｌｅｔ（）
一般的説明：現在アプレットがビュー内でアクティブなものであるかどうか決定する。
ＬｅａｖｅＦｉｅｌｄ（ｆｉｅｌｄ）
一般的説明：このメソッドは、通常、焦点が制御に対応する入力エレメントから去るときにコールされる。
Ｐｏｐｕｌａｔｅ（）
一般的説明：アプレットにおける全てのＵＩエレメントをビジネスコンポーネントからの状態で設定する。
ＰｒｏｃｅｓｓＥｒｒｏｒ（ｏｂｊｅｃｔ）
一般的説明：所与のオブジェクトに登録されたエラーに対するエラーダイアログを持ち出す。
【０１５３】
ＳｅｔＡｐｐｌｅｔＡｃｔｉｖｅ（ｉｓＡｃｔｉｖｅ、ｎｅｗＡｃｔｉｖｅＡｐｐｌｅｔ）
一般的説明：指定のアプレットをアクティブ又はインアクティブにセットする。第１アーギュメントが真である場合には、指定のアプレットがアクティブにされる。
ＳｅｔＢｕｓＣｏｍｐ（ｂｕｓＣｏｍｐ）
一般的説明：現在アプレットの基礎となるビジネスコンポーネントを設定する。
ＳｅｔＤｏｃｕｍｅｎｔ（ｄｏｃ）
一般的説明：現在アプレットに対するＨＴＵＬ文書オブジェクトを設定する。
ＳｅｔＨｉｇｈｌｉｇｈｔＣｌａｓｓｅｓ（ｅｌｅｍｅｎｔＩＤ、ａｃｔｉｖｅＣｌａｓｓ、ｉｎａｃｔｉｖｅＣｌａｓｓ）
一般的説明：アクティブアプレットをハイライト表示するように状態を設定する。
【０１５４】
ＳｅｔＩｄ（ｉｄ）
一般的説明：現在アプレットをビュー内の他のアプレットから区別するために現在アプレットのＩＤをセットする。
ＳｅｔＩｎｐｕｔＶａｌｕｅ（ｉｎｐｕｔ、ｖａｌｕｅ）
一般的説明：入力エレメント現在値の現在値を指定値にセットする。
ＳｅｔＮａｍｅ（ｎａｍｅ）
一般的説明：アプレットの名前をセットする。
ＳｅｔＮｏｔｉｆｙＯｂｊ（ｎｏｔｉｆｙＯｂｊ）
一般的説明：所与の通知オブジェクトをこのアプレットに対するアクティブなものとしてセットする。
【０１５５】
ＳｅｔＴｉｔｌｅ（ｔｉｔｌｅ）
一般的説明：アプレットのタイトルをセットする。
ＳｅｔＰｏｐｕｐＭｅｔｈｏｄ（ｐｏｐｕｐＭｅｔｈｏｄ）
一般的説明：ポップアップアプレットの状態をセットする。
ＳｅｔＰｏｐｕｐＣｏｎｔｒｏｌ（ｐｏｐｕｐＣｏｎｔｒｏｌ）
一般的説明：ポップアップアプレットの状態をセットする。
ＳｅｔＰｏｐｕｐＡｐｐｌｅｔ（ｐｏｐｕｐＡｐｐｌｅｔ）
一般的説明：ポップアップアプレットの状態をセットする。
ＳｅｔＰｏｐｕｐＢｏｏｋｍａｒｋ（ｐｏｐｕｐｂｏｏｋｍａｒｋ）
一般的説明：ポップアップアプレットの状態をセットする。
【０１５６】
ＳｅｔＰａｒｅｎｔＡｐｐｌｅｔ（ｐａｒｅｎｔＡｐｐｌｅｔ）
一般的説明：ポップアップアプレットの親アプレットをセットする。
ＳｅｔＶａｒｉａｂｌｅ（ｖａｒｉａｂｌｅ）
一般的説明：アプレットオブジェクトを指すＨＴＭＬ変数をセットする。
ＳｅｔＶｉｅｗ（ｖｉｅｗ）
一般的説明：現在アプレットの親ビューをセットする。
ｔｏＳｔｒｉｎｇ（）
一般的説明：アプレット名を含むストリングを返送する。
【０１５７】
ＴｒｙＣｏｎｄｉｔｉｏｎ（ｓｅｒｖｉｃｅ、ｍｅｔｈｏｄ、ａｒｇｓ）
一般的説明：所与の条件が真を返送するかどうか決定する。ＴｒｙＣｏｎｄｉｔｉｏｎ（）は、サービスメソッドをインボークし、そして状態を返送する。
ＵｐｄａｔｅＣｏｎｄｉｔｉｏｎａｌｓ（）
一般的説明：ある顕著な状態が変化したことについてここで条件を再評価する。
ＵｐｄａｔｅＲｏｗＣｏｕｎｔｅｒ（）
一般的説明：行カウンタストリングを再発生し、そして表示された行カウンタを更新する。
【０１５８】
コマンドマネージャー
一実施形態において、ツールバー、メニュー、キーボード制御器（ここでは、キーボードショートカット又はキーボードアクセラレータとも称される）等の種々のユーザインターフェイスアイテム又は制御器を使用して、ユーザが種々のアクション又はコマンドを開始するための手段が与えられる。一実施形態において、ツールバーは、ブラウザウインドウにおいてアプリケーションの頂部付近でそれら自身のフレームに現われるように設計及び構成され、そしてアプリケーションメニュー（例えば、ファイル、ビュー、ヘルプ等）は、一次タブ（例えば、第１レベルナビゲーション）バー付近に現われるように設計及び構成される。一実施形態において、アプレットレベルメニューは、アプレットの頂部の制御バナーにおいてアプレットメニューボタンからインボークすることができる。図１６、１７及び１８は、各々、ツールバー、アプリケーションレベルメニュー及びアプレットレベルメニューの例を示す。一実施形態において、ツールバー、アプリケーションレベルメニュー、アプレットレベルメニュー、或いは特定キーボードショートカット又はキーボードアクセラレータ（例えば、ＣＲＴＬ＋Ｎ）における各ユーザインターフェイスアイテム又はオブジェクトは、各ユーザインターフェイスアイテムのユーザ選択又はアクチベーション（例えば、メニューアイテムをクリックしたり、ＣＴＲＬ＋Ｎ等のキーボード組合せを押したりする）に応答して実行されるべき特定のコマンドに関連されるか又はそれにマップされるように構成できる。一実施形態において、各コマンドは、１つ以上の特定のメソッドをインボークして、ユーザにより要求された１つ以上の特定のファンクション又はアクションを実行するように設計及び構成できる。一実施形態において、ここでコマンドオブジェクトと称されるデータ構造は、特定のコマンドを表わすように設計及び構成することができ、それを実行すると、各コマンドオブジェクトに関連した１つ以上の特定のメソッドがインボークされる。コマンドオブジェクトは、以下で詳細に説明する。
【０１５９】
一実施形態において、ツールバーアイコン又はメニューアイテムの選択又はアクチベーション（例えば、ユーザがツールバーアイコン又はメニューアイテム等をクリックする）は、通常、インボークメソッドへのコールに変換され、これは、ブラウザ又はサーバーにおけるサービスに存在するか、或いはブラウザアプリケーション又はサーバーインフラストラクチャーにおけるクラス（例えば、アプレット又はビジネスコンポーネントクラス、ＳＷＥフレームマネージャー、モデル等）に存在する。一実施形態において、ツールバーアイコン、メニューアイテム又はキーボードショートカット等のユーザインターフェイスアイテムは、メソッド名、メソッドハンドラー（これが見つからない場合には自動的に再ターゲットとされる）、及び任意であるが、サービスをターゲットとするように構成される。
【０１６０】
一実施形態において、アプリケーションレベルアイテム（ツールバーアイコン、アプリケーションレベルメニュー、及びキーボードショートカット等を含む）は、ツールにおけるコマンドオブジェクト定義を使用することにより実施でき、これらは、次いで、ツールバーアイテム又はメニューアイテムオブジェクト定義へとマップされる。一実施形態において、アプレットレベルメニューは、コマンドオブジェクト定義を使用せず、それに対応するメソッドをターゲットとしそしてそれをインボークするのに使用される特性のセットは、コマンドオブジェクト形式で見つかるものと同様である。
【０１６１】
一実施形態において、ウェブエンジンテンプレートでは、ツールバータグは、命名されたツールバー（ここでは、名前は、貯蔵部のツールバーオブジェクト定義における名前特性に対応する）を指定するのに使用でき、そしてツールバー開始タグと終了タグとの間のツールバーアイテムタグは、貯蔵部からのそのツールバーに対し全てのツールバーアイテムを繰返し検索する。
【０１６２】
一実施形態において、設計時間メニューアクチベーション／抑制特徴がアプレットレベルメニューに対して与えられる。この特徴は、所与のクラス及びそのサブクラスのアプレットに対してメニューアイテムをグローバルに利用できるようにし、次いで、それが望まれない特定のアプレットにおいてそれを抑制する能力を与える。一実施形態において、設計時間メニューアクチベーション／抑制特徴は、クラスメソッドメニューアイテムオブジェクト形式を使用して実施することができ、これは、抑制メニューアイテム特性により定義されたように抑制される場所を除き、指定のアプレットクラスの全アプレットのアプレットレベルメニューにおいてメニューアイテムを実施するのに使用できる。アプレットメソッドメニューアイテム、クラスメソッドメニューアイテム、及びメニューアイテムの抑制は、以下に詳細に説明する。
【０１６３】
図１９は、種々のコマンドの構成及び実行に使用される種々のオブジェクトを生成するためのプロセス１９００の一実施形態を示すフローチャートである。図１９に示すように、プロセスは、次のアクションを含む。
・１つ以上のコマンドオブジェクトを生成する（ブロック１９１０）。
・１つ以上のツールバーオブジェクトを生成する（ブロック１９２０）。
・１つ以上のツールバーアイテムオブジェクトを生成する（ブロック１９３０）
・１つ以上のアプリケーションレベルメニューオブジェクトを生成する（ブロック１９４０）
・１つ以上のアプリケーションレベルメニューアイテムオブジェクトを生成する（ブロック１９５０）、
・１つ以上のアプレットメソッドメニューアイテムオブジェクトを生成する（ブロック１９６０）、
・１つ以上のクラスメソッドメニューアイテムオブジェクトを生成する（ブロック１９７０）、
・ここでキーボードショートカット、ショートカットキーとも称される１つ以上のキーボードアクセラレータオブジェクトを生成する（ブロック１９８０）
【０１６４】
図２０は、本発明の教示に基づきコマンドオブジェクトを生成するためのプロセス２０００の一実施形態を示すフローチャートである。コマンドオブジェクトの生成は、一般に、コマンドオブジェクト定義を行い（ブロック２０１０）、そしてその定義されたコマンドオブジェクトに関連した特性（プロパティ）を指定する（ブロック２０２０）ことを含む。
【０１６５】
図２１は、本発明の教示に基づくコマンドオブジェクトの特性の一実施形態を示す。一実施形態において、コマンドオブジェクトは、次の特性、即ちターゲット２１１０、ビジネスサービス２１２０、メソッド２１３０、メソッドアーギュメント２１４０、ショーポップアップ２１５０、ＨＴＭＬポップアップ寸法２１６０、ビットマップ／ＨＴＭＬビットマップ２１７０、及びツールチップテキスト２１８０を含む。コマンドオブジェクト及びそれらの特性は、以下に詳細に述べる。
【０１６６】
一実施形態において、コマンドオブジェクト定義は、コマンドに関連したツールバーアイコン又はアプリケーションレベルメニューアイテムが実行されたときにどのインボークメソッドがコールされるか指定するように生成及び構成される。更に、コマンドオブジェクト定義は、ツールバーアイテムに対してツールバーアイコンにどのビットマップが現われるか特定するのにも使用される。一実施形態において、コマンドオブジェクト定義は、ツールバーアイテム又はメニューアイテムオブジェクト定義により参照される。図２１に示すように、コマンドオブジェクト定義は、一般に、次の特性を有する。
【０１６７】
・ターゲット特性２１１０は、一般に、コマンドがコールしたインボークメソッドをどのエンティティが取り扱うか指定する。一実施形態において、利用可能なオプションは、次の通りである。
・ブラウザ：この場合に、メソッドハンドラーは、サービスがビジネスサービス特性で指定されるかどうかに基づいて、ブラウザにおけるＪａｖａＳｃｒｉｐｔサービスであるか又はＪａｖａＳｃｒｉｐｔアプリケーションである。
・サーバー：この場合に、メソッドハンドラーは、サービスがビジネスサービス特性で指定されるかどうかに基づいて、サーバーにおけるオブジェクトマネージャーサービスであるか又はオブジェクトマネージャーインフラストラクチャー（例えば、ＳＷＥ  ＵＤＦローダー、又は二次的にモデル）である。
【０１６８】
・ビジネスサービス特性２１２０は、一般に、インボークメソッドを取り扱うサービス（ターゲット特性に基づいてブラウザ又はサーバーのいずれかにある）を指定する。一実施形態において、特性が左ブランクである場合には、特定のサービスではなく、ブラウザ又はサーバーインフラストラクチャーがターゲットとなる。一実施形態において、サービスが指定された場合には、それが、メソッド特性で指定されたメソッドに対するＣａｎＩｎｖｏｋｅＭｅｔｈｏｄ及びＩｎｖｏｋｅＭｅｔｈｏｄを取り扱う。
【０１６９】
・メソッド特性２１３０は、一般に、ユーザインターフェイスアイテム（例えば、メニューアイテム、ツールバーアイコン等）が選択されたときにインボークすべきメソッドの名前を指定するために使用される。一実施形態では、この特性は要求された特性である。
・メソッドアーギュメント特性２１４０は、一般に、メソッド特性で指定されたインボークメソッドへアーギュメントを通過させるメカニズムを与えるために使用される。例えば、新たなウインドウをオープンしそしてそのウインドウにおいてＵＲＬへナビゲートするコマンドアイテムは、メソッド特性及びＵＲＬにおいてＧｏｔｏＵＲＬメソッドを指定し、メソッドアーギュメント特性へナビゲートする。
【０１７０】
・ショーポップアップ特性２１５０。一実施形態において、この特性は、メソッドをインボークする前に新たなブラウザウインドウがオープンされることを指定するためにＴＲＵＥ（真）にセットされる。又、これは、現在ブラウザウインドウにおいてメソッドがインボークされることを指定するためにＦＡＬＳＥ（偽）にセットされる。
・ＨＴＭＬポップアップ寸法特性２１６０。一実施形態において、この特性は、ショーポップアップ特性２１５０がＴＲＵＥであるときにポップアップウインドウの寸法（ピクセル単位）を指定するのに使用される。その一例は、６４０ｘ６４０である（ブランクスペースを伴わずに「ｘ」で指定される）。
【０１７１】
・ビットマップ／ＨＴＭＬビットマップ特性２１７０。
・ツールチップテキスト特性２１８０。一実施形態において、カーソルをツールバーアイコン上に長々置いたときに現われるツールチップテキストを指定するのに使用される。一実施形態において、ビルドインメソッドの場合に、ツールチップテキストは、ブランクのままでなければならず、これは、メソッドがテキストを動的に供給しそして言語ローカライゼーションがこのプロセスの一部分として実行されることを指示する。デベロッパー定義メソッドの場合には、リテラルテキストをこの特性に対して入力することができる。一実施形態では、リテラルテキストがこの特性に対して入力されるときに、このツールチップテキストに対して言語ローカライゼーションをターンオフする。
【０１７２】
図２２は、本発明の教示に基づきツールバーオブジェクトを生成するためのプロセス２２００の一実施形態を示すフローチャートである。ツールバーオブジェクトの生成は、一般に、ツールバーオブジェクトを定義し（ブロック２２１０）、そしてその定義されたツールバーオブジェクトに関連した特性を指定する（ブロック２２２０）ことを含む。
【０１７３】
図２３は、本発明の教示に基づくツールバーオブジェクトの特性の一実施形態を示す。一実施形態において、ツールバーオブジェクトは、次の特性、即ちクラス２３１０、名前２３２０、名前表示２３３０、及びポップアップインジケータビットマップ２３４０を含む。ツールバーオブジェクト及びそれらの特性は、以下に詳細に述べる。
【０１７４】
一実施形態において、アプリケーションのツールバーごとに、ツールバーオブジェクト定義をオブジェクトリストエディタにおいて生成することができる。これは、種々のアプリケーションにおいてユーザがアクチベート又はデアクチベートすることのできる命名されたツールバーを与え、これに対してツールバーアイコン（例えば、ツールバーアイテムオブジェクト定義）を関連させたり又は除去したりすることができる。アプリケーションに対するツールバー機能は、ＨＴＭＬツールバーを使用して実施することができる。一実施形態において、ＨＴＭＬツールバーでは、ボタンは、静止像であって、使用不能であることを指示するために薄暗くされるが、その他の点では、ブラウザのプログラムロジックでは操作されない。これに対して、ＣＴＩ（コンピュータ電話一体化）アプリケーションは、コールが到来するときに特定のツールバーアイコンを明滅するように、事象に応答して変更することのできるツールバーアイコンを必要とする。一実施形態では、これは、Ｊａｖａツールバーの使用を必要とする。一実施形態において、ツールバーがＪａｖａ形式のものであることを指定するために、クラス名がクラス特性において入力される。図２３に示すように、ツールバーオブジェクトは、次の特性を含む。
【０１７５】
・クラス特性２３１０。一実施形態において、この特性は、ＨＴＭＬツールバーに対してブランクのままであり、そしてＪａｖａツールバーに対して指定される（例えば、ツールバーを実施するＪａｖａクラスの名前が入力される）。
・名前特性２３２０。一実施形態において、この特性は、他のオブジェクト定義により参照されると共に、「ｎａｍｅ＝」節においてツールバータグにより参照される。
【０１７６】
・名前表示特性２３３０。一実施形態において、この特性は、履歴ボタンとして使用され、名前によりツールバーを示したり隠したりする。
・ポップアップインジケータビットマップ特性２３４０。一実施形態において、この特性は、サイドウェイツールバーポップアップを指定するのに使用される。
【０１７７】
図２４は、本発明の教示に基づきツールバーアイテムオブジェクトを生成するためのプロセス２４００の一実施形態を示すフローチャートである。ツールバーアイテムオブジェクトの生成は、一般に、ツールバーアイテムオブジェクトを定義し（ブロック２４１０）、そしてその定義されたツールバーアイテムオブジェクトに関連した特性を指定する（ブロック２４２０）ことを含む。
【０１７８】
図２５は、本発明の教示に基づくツールバーアイテムオブジェクトの特性の一実施形態を示す。一実施形態において、ツールバーアイテムオブジェクトは、次の特性、即ちコマンド特性２５１０、ＨＴＭＬ形式特性２５２０、名前特性２５３０、シーケンス特性２５４０、及び位置特性２５５０を含む。ツールバーアイテムオブジェクト及びそれらの特性は、以下に詳細に述べる。
【０１７９】
一実施形態において、ツールバーアイテムオブジェクトは、コマンドオブジェクト定義（これは、名前によりツールバーアイテムオブジェクトのコマンド特性における特性として識別される）をツールバーオブジェクト定義（これは、ツールバーアイテムオブジェクトの親である）に関連付けるように定義及び構成される。一実施形態において、これは、この関連付けは、ビットマップ像、インボークメソッド及びターゲットがコマンドオブジェクト定義で指定されるツールバーアイコンを、指定のツールバーにおいて所与の位置（例えば、そのツールバーにおける他のツールバーアイコンに対する位置）に配置させる。一実施形態において、図２５に示すように、ツールバーアイテムオブジェクトは、次の特性を含むように定義される。
【０１８０】
・コマンド特性２５１０。一実施形態において、この特性は、各ツールバーアイテムに対してビットマップ、メソッド及びターゲットを与えるものであるコマンドオブジェクト定義の名前を指定する。一実施形態において、アイコン間にセパレータを挿入することをシステムに通知するために、コマンドオブジェクトの名前に代わって１つ以上のハイフンを指定することができる。
【０１８１】
・ＨＴＭＬ形式２５２０。一実施形態において、この特性は、ブラウザにおける対応ツールバーに表示されるべき制御の形式を識別するのに使用される。一実施形態において、種々のオプションは、ＣｏｍｂｏＢｏｘ、Ｂｕｔｔｏｎ、Ｅｄｉｔ、Ｌａｂｅｌ、Ｈｙｐｅｒｌｉｎｋ、ＭｉｎｉＢｕｔｔｏｎ、Ｔｉｍｅｒ等を含む。
・名前特性２５３０。一実施形態において、この特性は、ツールバーアイテムの名前を指定する。一実施形態において、名前特性は、ツールバーの範囲内で独特であることを必要とする。
【０１８２】
・シーケンス特性２５４０。一実施形態において、この特性は、親ツールバーにおけるツールバーアイテムを左から右へ順序付けする整数を指定する。例えば、他のツールバーアイテムに対して高いシーケンス番号は、このアイコンを他のものより更に右へ配置する。
・位置特性２５５０。一実施形態において、この特性は、サイドウェイツールバーに対して使用される。例えば、０．１、０．２等の値を使用することができる。
【０１８３】
一実施形態において、各アプリケーションレベルメニューに対してメニューオブジェクトを定義及び構成することができる。一実施形態において、メニューオブジェクトは、対応するメニューアイテムオブジェクトの親とみなされる。メニューアイテムオブジェクトは、親メニューオブジェクト定義内のアプリケーションメインメニュー又はメニューアイテムを定義するのに使用される。
【０１８４】
図２６は、本発明の教示に基づきメニューアイテムオブジェクトを生成するためのプロセス２６００の一実施形態を示すフローチャートである。メニューアイテムオブジェクトの生成は、一般に、メニューアイテムオブジェクトを定義し（ブロック２６１０）そしてその定義されたメニューアイテムオブジェクトに対する特性を指定する（ブロック２６２０）ことを含む。
【０１８５】
図２７は、本発明の教示に基づくメニューアイテムオブジェクトの特性の一実施形態を示す。一実施形態において、メニューアイテムオブジェクトは、次の特性、即ち名前特性２７１０、コマンド特性２７２０、キャプション特性２７３０、及び位置特性２７４０を含む。これらの特性は、以下に詳細に説明する。
【０１８６】
・名前特性２７１０。一実施形態において、この特性は、メニュー又はメニューアイテムを独特に識別するのに使用される。
・コマンド特性２７２０。一実施形態において、この特性は、各メニューアイテムに対してメソッド及びターゲットを与えるのに使用される対応するコマンドオブジェクト定義の名前を指定する。
・キャプション特性２７３０。一実施形態において、この特性は、メニュー又はメニューアイテムにおいて表示されるテキストを指定する。
【０１８７】
・位置特性２７４０。一実施形態において、この特性は、メニューツリー内のメニュー又はメニューアイテムの位置を指定する。例えば、メニューの最上位レベル位置（それらの中のアイテムではなく）は、１、２及び３（又は１０、２０及び３０）のような単一の整数である。メニューアイテムの位置の値（例えば、メニューツリーにおいて第２レベル以下）は、ドット表示を使用して指定することができ、ここで、最も右のドットの右側の値は、そのレベルにおけるアイテムの順序を指定し、そしてそのドットの左側の値（１つ又は複数）は、親メニュー又はメニューアイテムを指定する。例えば、３．１は、最上位レベルメニューの第３アイテムのサブメニューにおける第１アイテムとして定義することができる。あるレベルにおける値は、連続的である必要がないことに注意されたい。例えば、値１１１０、１１１５、１１２０及び１１３０を使用して、同じレベルにおける４つのメニューアイテムを指示することができ、そしてそれらのシーケンスは、メニューにおける表示の順序を決定する。
【０１８８】
一実施形態において、アプレットメソッドメニューアイテムオブジェクトは、親アプレットオブジェクト定義に対するアプレットレベルメニューにおけるメニューアイテムを定義するのに使用される。一実施形態において、アプリケーションレベルメニューとは異なり、アプレットメニューは、コマンドオブジェクトをベースとしていない。しかしながら、メソッドをターゲットとするのに使用される特性のセットは、コマンドオブジェクト形式で見られるものと同様である。図２８は、本発明の教示に基づきアプレットメソッドメニューアイテムオブジェクトを生成するためのプロセス２８００の一実施形態を示すフローチャートである。アプレットメソッドメニューアイテムオブジェクトの生成は、一般に、アプレットメソッドメニューアイテムオブジェクトを定義し（ブロック２８１０）、そしてその定義されたアプレットメソッドメニューアイテムオブジェクトに対する特性を指定する（ブロック２８２０）ことを含む。
【０１８９】
図２９は、本発明の一実施形態に基づくアプレットメソッドメニューアイテムオブジェクトの特性を示す。一実施形態において、アプレットメソッドメニューアイテムオブジェクトは、次の特性、即ちメニューテキスト特性２９１０、ターゲット特性２９２０、メソッド特性２９３０、ビジネスサービス特性２９４０、抑制メニューアイテム特性２９５０、及び位置特性２９６０を含む。これらの特性は、以下に詳細に説明する。
【０１９０】
・メニューテキスト特性。一実施形態において、この特性は、メニューアイテムに表示されるテキストを指定するのに使用される。
・ターゲット特性。一実施形態において、この特性は、メソッド特性で指定されたインボークメソッドをどのエンティティが取り扱うか指定するのに使用される。一実施形態において、次のオプションを利用できる。
【０１９１】
・ブラウザ。この場合に、メソッドハンドラーは、サービスがビジネスサービス特性で指定されるかどうかに基づいて、ブラウザにおけるＪａｖａＳｃｒｉｐｔサービスであるか、或いはブラウザにおけるＪａｖａＳｃｒｉｐｔアプレットクラス（又は二次的にＪａｖａＳｃｒｉｐｔビジネスコンポーネントクラス）である。
・サーバー。この場合に、メソッドハンドラーは、サービスがビジネスサービス特性で指定されるかどうかに基づいて、サーバーにおけるオブジェクトマネージャーサービスであるか、或いはアプレット及びビジネスコンポーネント及びそれらのスーパークラスである。
【０１９２】
・メソッド特性。一実施形態において、この特性は、対応するメニューアイテムが選択されたときにインボークされるべきメソッドを指定するのに使用される。
・ビジネスサービス特性。この特性は、それが指定された場合には、指定のメソッドをインボークすべきところのサービスを識別する。指定されない場合には、指定のメソッドが、ブラウザ又はサーバー（ターゲット特性で指定された）のアプレットクラスにおいてインボークされ、その後、それが取り扱われない場合にターゲットが決め直される。
【０１９３】
・抑制メニューアイテム特性。一実施形態において、この特性のデフォールトは、ＦＡＬＳＥにセットされる。この特性がＴＲＥＵにセットされた場合には、この特性が指定されたアプレットにおいてアプレットレベルメニューから指定の名前のクラスレベルメニューアイテムを除去させる。
・位置特性。一実施形態において、この特性は、メニューアイテムの単一レベルリストにおいてメニューアイテムのシーケンスを指定するのに使用される。
【０１９４】
図３０は、本発明の一実施形態に基づいてクラスメソッドメニューオブジェクトを生成するためのプロセス３０００の一実施形態を示すフローチャートである。一実施形態において、クラスメソッドメニューアイテムは、指定のアプレットクラス及びそのサブクラスの全アプレットに対してアプレットレベルメニューにおいてメニューアイテムを追加又は抑制するように定義及び構成することができる。クラスメソッドメニューアイテムオブジェクトの生成は、一般に、クラスメソッドメニューアイテムオブジェクトを定義し（ブロック３０１０）、そしてその定義されたクラスメソッドメニューアイテムオブジェクトに対する特性を指定する（ブロック３０２０）ことを含む。
【０１９５】
図３１は、本発明の一実施形態に基づくクラスメソッドメニューアイテムの特性を示す。一実施形態において、クラスメソッドメニューアイテムオブジェクトは、次の特性、即ちターゲット特性３１１０、メニューテキスト特性３１２０、メソッド特性３１３０、ビジネスサービス特性３１４０、抑制メニューアイテム特性３１５０、及び位置特性３１６０を含む。これらの特性は、以下に詳細に説明する。
【０１９６】
・ターゲット特性。一実施形態において、この特性は、メソッド特性で指定されたインボークメソッドをどのエンティティが取り扱うか指定するのに使用される。一実施形態において、次のオプションを利用できる。
・ブラウザ。この場合に、メソッドハンドラーは、サービスがビジネスサービス特性で指定されるかどうかに基づいて、ブラウザにおけるＪａｖａＳｃｒｉｐｔサービスであるか、或いはブラウザにおけるＪａｖａＳｃｒｉｐｔアプレットクラス（又は二次的にＪａｖａＳｃｒｉｐｔビジネスコンポーネントクラス）である。
・サーバー。この場合に、メソッドハンドラーは、サービスがビジネスサービス特性で指定されるかどうかに基づいて、サーバーにおけるオブジェクトマネージャーサービスであるか、或いはアプレット及びビジネスコンポーネント及びそれらのスーパークラスである。
【０１９７】
・メニューテキスト特性。一実施形態において、この特性は、メニューアイテムに表示されたテキストを指定するのに使用される。
・メソッド特性。一実施形態において、この特性は、対応するメニューアイテムが選択されたときにインボークされるべきメソッドを指定するのに使用される。
・ビジネスサービス特性。この特性は、それが指定された場合には、指定のメソッドをインボークすべきところのサービスを識別する。指定されない場合には、指定のメソッドが、ブラウザ又はサーバー（ターゲット特性で指定された）のアプレットクラスにおいてインボークされ、その後、それが取り扱われない場合にターゲットが決め直される。
【０１９８】
・抑制メニューアイテム特性。一実施形態において、この特性のデフォールトは、ＦＡＬＳＥにセットされる。この特性がＴＲＥＵにセットされた場合には、このクラス及びそのサブクラスから導出された全アプレットにおいてアプレットレベルメニューから指定の名前のアプレットレベルメニューアイテムを除去させる。
・位置特性。一実施形態において、この特性は、メニューアイテムの単一レベルリストにおいてメニューアイテムのシーケンスを指定するのに使用される。
【０１９９】
図３２は、本発明の一実施形態に基づきツールバーオブジェクトと、ツールバーアイテムオブジェクトと、コマンドオブジェクトとの間の関係を示す図である。図３２に示すように、ここに述べるツールバーオブジェクトは、一般に、１つ以上のツールバーアイテムオブジェクトに関連付けることができる。一実施形態において、各ツールバーアイテムオブジェクトは、それに対応するコマンドオブジェクトに関連付けることができ又はそれにマップさせることができる（例えば、各ツールバーアイテムオブジェクトのコマンド特性を使用することにより）。換言すれば、コマンドオブジェクトは、上述したようにコマンドオブジェクトの名前を指定するために、ツールバーアイテムオブジェクトのコマンド特性を使用してツールバーアイテムオブジェクトにより参照することができる。
【０２００】
図３３は、メニューオブジェクトと、メニューアイテムオブジェクトと、コマンドオブジェクトとの間の関係を示す図である。図３３に示すように、ここに述べるメニューオブジェクトは、一般に、１つ以上のメニューアイテムオブジェクトに関連付けることができる。一実施形態において、各メニューアイテムオブジェクトは、それに対応するコマンドオブジェクトに関連付けることができ又はそれにマップさせることができる（例えば、各メニューアイテムオブジェクトのコマンド特性を使用することにより）。換言すれば、コマンドオブジェクトは、上述したようにコマンドオブジェクトの名前を指定するために、メニューアイテムオブジェクトのコマンド特性を使用してメニューアイテムオブジェクトにより参照することができる。
【０２０１】
図３４は、アプレットレベルメニューオブジェクトと、アプレットメソッドメニューアイテムオブジェクトと、クラスメソッドメニューアイテムオブジェクトとの間の関係を示す図である。図３４に示すように、アプレットレベルメニューは、一般に、１つ以上のアプレットメソッドメニューアイテムオブジェクトに関連付けることができる。一実施形態において、各アプレットメソッドメニューアイテムオブジェクトは、クラスメソッドメニューアイテムオブジェクトに関連付けることができ又はそれにマップさせることができる（例えば、ここに述べる抑制メニューアイテム特性を使用することにより）。
【０２０２】
メニューアイテム及びツールバーアイテムのアクチベーション及び抑制
本発明の一実施形態において、メニューアイテム（例えば、アプリケーションレベル及びアプレットレベルの両方）、並びにツールバーアイテムは、ランタイムに、ＣａｎＩｎｖｏｋｅＭｅｔｈｏｄメカニズムを使用することにより、イネーブル又はディスエイブルすることができる。一実施形態において、ＣａｎＩｎｖｏｋｅＭｅｔｈｏｄ（コマンド、アプレットメソッドメニューアイテム、又はクラスメソッドメニューアイテムオブジェクト等で指定されたメソッドに対する）は、各アイテムに対し、メニュー又はツールバーを表示する前に自動的にコールされる。ＣａｎＩｎｖｏｋｅＭｅｔｈｏｄがＦＡＬＳＥに復帰すると、ツールバーアイテム又はメニューアイテムがディスエイブルされる（例えば、表示されない）。ＣａｎＩｎｖｏｋｅＭｅｔｈｏｄのロジックは、一般に、ブラウザアプリケーションからサーバーにおけるアプレットクラスハイアラーキーへそしてそこからビジネスコンポーネントクラスハイアラーキーへ再ターゲット付けされる。このターゲット付けシーケンスは、以下に詳細に述べる。
【０２０３】
ここに述べるように、一実施形態では、設計時に個々のアプレットレベルメニューアイテムの抑制及びアクチベーションは、クラスメソッドメニューアイテム及びアプレットメソッドメニューアイテムのオブジェクト形式において抑制メニューアイテム特性を使用することによりサポートされる。一実施形態において、このメカニズム又は特徴は、アプレットレベルメニューに適用することができ、アイテムが明確に追加又は除去されるアプリケーションレベルメニュー又はツールバーには適用されない。アプレットレベルメニューに対する設計時のメニューアクチベーション／抑制は、所与のクラス及びそのサブクラスのアプレットに対してメニューアイテムをグローバルに利用し、そして望ましくない特定のアプレットにおいてそれを抑制するようなメカニズムを与える。例えば、種々のアプレットレベルメニューアイテムは、実質上全てのアプレット（複写、編集、削除等の）に現われ、他のものは、実質上全てのリストアプレット（表示された列等の）に現われ、等々となるが、アプレットクラスの「標準」メニューアイテムが特定のアプレットに対して抑制される必要がある場合も幾つかある。
【０２０４】
一実施形態において、アプレットクラスレベルメニューアイテムを追加するために、クラスメソッドメニューアイテムが所与のアプレットクラスの標準メニューアイテムに対して追加される。一実施形態において、このメニューアイテムは、メニューアイテムが現われるべきアプレットにおいてアプレットメソッドメニューアイテムオブジェクト定義として再び含まれる必要はない。一実施形態において、アプレットメソッドメニューアイテムオブジェクト定義は、メニューアイテム（アプレットのクラスによりまだ与えられていない）をアプレットに追加するか、又はアプレットが通常継承するアプレットクラスレベルアイテムの表示を抑制するといった２つの環境において生成される。後者の場合には、アプレットメソッドメニューアイテムオブジェクト定義は、抑制されるべきアプレットクラスレベルメニューアイテムと同じ名前で生成され、そして抑制メニューアイテム特性に対してＦＡＬＳＥの値が入力される。
【０２０５】
インボークメソッドのターゲット化
ここに述べる本発明の一実施形態によれば、メソッド、ビジネスサービス及びターゲット特性は、コマンドオブジェクト形式（ツールバー及びアプリケーションレベルメニューに使用する）、並びにクラスメソッドメニューアイテム及びアプレットメソッドメニューアイテムオブジェクト形式（アプレットレベルメニューに使用する）に含まれる。一実施形態において、ターゲット特性については、２つの設定又はオプションが次の振舞いと共に得られる。
【０２０６】
・ブラウザターゲット：このターゲットに対するメソッドハンドラーは、ブラウザ側におけるＪａｖａＳｃｒｉｐｔアプリケーション、ＪａｖａＳｃｒｉｐｔアプレット、又はＪａｖａＳｃｒｉｐｔサービスである。一実施形態において、どのエンティティがメソッドハンドラーであるかに関わらず、メソッド特性においてメソッド名を指定することが必要である。一実施形態において、サービス名がサービス特性において指定された場合にはサービスがターゲットとされる。サービスがサービス特性において指定されない場合には、メソッドの取り扱いは、発呼エンティティがアプリケーションレベルであるかアプレットレベルであるかに基づいて次のように相違する。
・アプリケーションレベル：ＪａｖａＳｃｒｉｐｔアプリケーションにおいて指定のメソッドをターゲットとする。この場合に、再ターゲット化はない。
・アプレットレベル：ＪａｖａＳｃｒｉｐｔアプレットにおいて指定のメソッドをターゲットとする。取り扱われない場合には、対応するＪａｖａＳｃｒｉｐｔビジネスコンポーネントにおける指定のメソッドを再ターゲットとする。この場合には、継承も付加的な再ターゲット化もない。
【０２０７】
・サーバーターゲット：このターゲットは、サービス又はインフラストラクチャーのいずれかにおいてサーバー上のメソッド（例えば、サーバー上のＣ＋＋クラスのメソッド）をインボークするためのものである。サービス特性値が指定されない場合には、インボークメソッドがインフラストラクチャーをターゲットとするようにされる。メソッドをインボークするメニュー又はツールバーアイコンがアプレットレベル（メニューのみ）であるかアプリケーションレベル（メニュー又はツールバー）であるかに基づいてインフラストラクチャーが次のように異なるやり方でターゲットとされる。
・アプリケーションレベル：メソッドハンドラーは、最初、サーバー側ではＳＷＥ  ＵＤＦローダーであり、そして二次的にモデルである。
・アプレットレベル：メソッドハンドラーは、最初、アプレットが属するアプレットクラスであり、アプレットクラスハイアラーキーを経てＣＳＳＳＷＥＦｒａｍｅへと次々に再ターゲット化される。まだ取り扱われない場合には、取り扱いがアプレットビジネスコンポーネントのビジネスコンポーネントクラスを再ターゲットとされ、そしてビジネスコンポーネントクラスハイアラーキーを経てＣＳＳＢｕｓＣｏｍｐへと次々に上方に進む。
【０２０８】
サービスがサービス特性で指定される場合には、メソッドハンドラーは、指定のサービスである。このターゲット化も、発呼メニューアイテム又はツールバーアイコンがアプレットレベルであるかアプリケーションレベルであるかに基づいて次のようになる。
・アプリケーションレベル：メソッドハンドラーは、指定のＯＭサービスである。この場合には、再ターゲット化はない。
・アプレットレベル：メソッドハンドラーは、ＳｅｔＢＣコールを実行して、アプレットのビジネスコンポーネントへセットし、次いで、指定のＯＭサービスをコールする。この場合には、再ターゲット化はない。
【０２０９】
以下のマトリクス又はテーブルは、本発明の一実施形態に基づきアプレット及びアプリケーションレベルにおけるターゲット及びビジネスサービス特性の考えられる設定の結果を示している。
2005516272.tif 000004
【０２１０】
図３５は、本発明の教示を実施できるシステムコンフィギュレーション３５００の一実施形態のブロック図である。このシステムコンフィギュレーション３５００は、システムのユーザにより開始された種々のコマンドの処理を、各コマンドに関連した特性において指定された情報に基づいて管理するように構成されたクライアント側コマンドマネージャーを備えている。図３５に示すように、システムコンフィギュレーションは、更に、コマンドマネージャーサービスと、サーバー側コマンドマネージャーとをサーバー側に備えている。一実施形態において、コマンドマネージャーサービスは、サーバーに対してターゲットとされたコマンドをクライアント側コマンドマネージャーから受け取るように構成される。一実施形態において、コマンドマネージャーサービスは、コマンドを受け取って、その受け取ったコマンドをサーバー側コマンドマネージャーへ転送するための焦点として働く。一実施形態において、サーバー側コマンドマネージャーは、サーバーをターゲットとするこれらのコマンドを処理するように構成される。一実施形態において、サーバー側コマンドマネージャーは、各コマンドに関連した特性に基づいて、各コマンドで指定されたメソッドをどのエンティティが取り扱うか決定するように構成される。上述したように、コマンドは、ユーザインターフェイスアイテム（ここでは、コマンドアイテム、制御又は制御アイテムとも称される）、例えば、ツールバーアイテム、メニューアイテム、キーボードアクセラレータアイテム（キーボードショートカット又はショートカットキーとも称される）等へとマップすることができる。一般に、コマンドのユーザ選択又は開始（例えば、ツールバーアイコンやメニューアイテムをクリックするか、又はキーボード組合せを押圧する等による）は、ブラウザ又はサーバーにおけるサービス、或いはブラウザアプリケーション又はサーバーインフラストラクチャーにおける対応クラス（例えば、アプレット又はビジネスコンポーネントクラス等）に存在するインボークメソッドへのコールに変換される。上述したように、ツールバーアイコン、メニューアイテム、又はキーボードアクセラレータアイテムは、メソッド、メソッドハンドラー（見つからない場合にはそこから自動的に再ターゲット化される）、及び任意であるが、サービスをターゲットとするように構成される。
【０２１１】
図３６は、本発明の一実施形態に基づくプロセス３６００のフローチャートである。ブロック３６１０において、メニュー、ツールバー又はキーボードに関連したコマンドアイテムがイネーブルされるかどうか（例えば、コマンドアイテムに関連したメソッドをインボークできるかどうか）決定される。上述したように、メニューアイテム（アプリケーションレベル及びアプレットレベルの両方）と、ツールバーアイテムは、ランタイムに、上述したようにＣａｎＩｎｖｏｋｅＭｅｔｈｏｄメカニズムを使用することによりイネーブル又はディスエイブルすることができる。一実施形態において、ＣａｎＩｎｖｏｋｅＭｅｔｈｏｄは、メニュー又はツールバーを表示する前に各アイテムに対してコールされる。一実施形態において、ＣａｎＩｎｖｏｋｅＭｅｔｈｏｄは、コマンドアイテムがイネーブルされない（例えば、メソッドをインボークできない）ことを指示する値（例えば、ＦＡＬＳＥ）と、コマンドアイテムがイネーブルされる（例えば、メソッドをインボークできる）ことを指示する別の値（例えば、ＴＲＵＥ）とを返送する。一実施形態において、各コマンドアイテムがイネーブルされない（例えば、ＣａｎＩｎｖｏｋｅＭｅｔｈｏｄがＦＡＬＳＥ値を返送する）場合には、各アイテムがユーザによってアクセスできない（例えば、メニュー又はツールバーアイテムが表示されないか、暗くなって消される等々である）。ブロック３６２０において、各アイテムがイネーブルされた（例えば、ＣａｎＩｎｖｏｋｅＭｅｔｈｏｄがＴＲＵＥ値を返送する）場合には、各アイテムを選択できることをユーザに指示する（例えば、メニューアイテム又はツールバーアイテムをユーザに表示することで）。ブロック３６３０において、各コマンドアイテムのユーザ選択（例えば、メニュー又はツールバーアイテムをユーザがクリックするか又はショートカットキーを押す等々）に応答して、各アイテムに関連されたコマンドは、上述したように、ターゲット及びサービス特性に基づき且つ発呼エンティティがアプレットレベルであるかアプリケーションレベルであるかに基づいて、処理のために適当な行先（例えば、メソッドハンドラー）へルーティングされる。ブロック３６４０では、選択されたコマンドアイテムに関連したコマンドが処理される。
【０２１２】
図３７は、本発明の一実施形態に基づくプロセス３７００のフローチャートである。ブロック３７１０において、上述したようにコマンドオブジェクトが定義される。ブロック３７２０において、上述したように、ユーザインターフェイスアイテムオブジェクト（例えば、ツールバーアイテムオブジェクト、メニューアイテムオブジェクト、キーボードアクセラレータアイテムオブジェクト等）が定義される。ブロック３７３０にいて、ユーザインターフェイスアイテムオブジェクトがそれに対応するコマンドオブジェクトに関連付けされる。一実施形態では、ランタイムに、サーバーがコマンドオブジェクト定義に基づいてコマンドを準備する。一実施形態では、種々のコマンドがそれに対応するコマンドアイテムにアタッチされる（例えば、メニューアイテム、ツールバーアイテム、キーボードアクセラレータ等）。一実施形態では、ユーザにより選択又は開始されたときにコマンドを処理するのに必要な特性（例えば、ターゲット特性、メソッド特性、ビジネスサービス特性等）を含むストリングとしてコマンドが準備される。ブロック３７４０において、上述したように、ユーザインターフェイスアイテム（例えば、メニューアイテム、ツールバーアイテム等）がイネーブルされるかどうか決定される。ブロック３７５０において、アイテムがイネーブルされた場合に、それを選択できることをユーザに指示する。ブロック３７６０において、コマンドアイテムのユーザ選択に応答して、選択されたコマンドに関連したターゲット特性及びビジネスサービス特性を含む上記種々のファクタ、並びに発呼エンティティがアプレットレベルであるかアプリケーションレベルであるかに基づいてその選択されたコマンドを処理するために適当なエンティティ（例えば、メソッドエンティティ）が決定される。ブロック３７７０において、選択されたコマンドが、決定されたターゲット（メソッドハンドラー）へルーティングされる。ブロック３７８０において、選択されたコマンドが処理される（例えば、選択されたコマンドに関連した指定のメソッドをインボークする）。
【０２１３】
変更時即時配達(Immediate Post-When-Change)
図３８は、本発明の一実施形態に基づく種々のオブジェクト間の関係を示すブロック図である。図３８に示すように、ビジネスオブジェクトは、種々のビジネスコンポーネントの論理的グループ又はマッピングとして定義及び構成することができる（例えば、ビジネスオブジェクトは、通常、１つ以上のビジネスコンポーネントを情報の論理的単位へグループ編成する）。図３８に示されてここに説明するように、ビジネスコンポーネントは、基礎的テーブル（例えば、データベーステーブル）の論理的グループ又はマッピングとして定義及び構成することができる。換言すれば、ビジネスコンポーネントは、通常、基礎的テーブルをラップオーバーする層を与える。各基礎的テーブル（例えば、データベーステーブル）は、通常、多数の記録又は業を含む。各記録又は行は、複数の列又はフィールドを含むことができる。
【０２１４】
図３９は、本発明の一実施形態に基づくビジネスコンポーネントの論理的構造を示すブロック図である。図３９に示すように、ビジネスコンポーネントは、各ビジネスコンポーネントに関する特性のセット（例えば、ビジネスコンポーネントの論理的な名前を指定するＮＡＭＥ、基礎的テーブルの実際の名前を指定するＴＡＢＬＥ  ＮＡＭＥ等）を含むことができる。又、ビジネスコンポーネントは、フィールドのセットも含み、その各々は、関連する特性のセットを有することができる。例えば、あるフィールドは、フィールドの名前を識別するＮＡＭＥ特性、各フィールドがマップされる基礎的テーブルの列を識別するＣＯＬＵＭＮ  ＮＡＭＥ等を含むことができる。
【０２１５】
通常、特定フィールドの値は、別のフィールドの値に依存してもよい。フィールドの値とフィールドの値との間の依存性又は相互依存性は、種々の方法で存在し得る。例えば、ユーザが、種々のフィールドを通常含むアドレスを入力したいと仮定すれば、特定フィールド（例えば、州フィールド）に対してユーザが入力する値は、ユーザが別のフィールド（例えば、市フィールド）に入力することのできる有効値のセットを決定することができる。別の例として、特定フィールドは、別のフィールドの値が変化するときにディスエイブルされてもよいし又はリードオンリーとされてもよい。更に、特定フィールドを示すために使用されるユーザインターフェイス制御又はフォーマットの形式を、別のフィールドに入力された値に基づいて変更できるケースもある。例えば、特定フィールドに対するユーザインターフェイス制御は、ユーザが任意の値を入力できるテキストボックスから、ユーザが既存の値のリストから選択しなければならないコンボボックスへと変化するように構成されてもよい。
【０２１６】
従来、クライアントサーバー環境では、クライアントは、ユーザが変更のセットの入力を終了するのを待機し、変更を処理のためにサーバーへ配達し、次いで、フィールド値とフィールド値との間の従属情報と共に別のページをユーザに示す。例えば、従来のアプリケーション又はシステムでは、クライアントは、ユーザが、ＳＴＡＴＥ、ＣＩＴＹ等の全アドレス情報の入力を終了するのを待機し、次いで、全ての変更をサーバーへ配達する。サーバーは、次いで、新たなページを、ユーザへ表示するためにクライアントに送信し、これは、フィールドとフィールドとの間の当該従属情報を含む。この従来の方法、又はフィールド値とフィールド値との間の依存性又は相互依存性を取り扱いそして処理する従来のやり方は、有効ではない。というのは、フィールド値とフィールド値との間の相互依存性による変化がユーザによって直ちに見えず、従って、ユーザインターフェイス環境を、かなり双方向性の悪いものにするからである。例えば、ユーザが特定フィールドの値を変更した後（別のフィールドの値及び／又はレイアウトがそれに依存する）、ユーザは、全ての変更がサーバーに配達されて新たなページが表示されるまで、その変更の影響を認識せず又は分からない。
【０２１７】
上記問題を解消するために、本発明の１つの態様によれば、他のフィールドの値、フォーマット又は機能が依存するところのフィールドの値の変化が、処理のためにサーバーへ即時配達される方法（ここでは、変更時即時配達特徴又は変更時即時配達メカニズムとも称される）が提供される。
【０２１８】
本発明の一実施形態によれば、他のフィールドが依存するところのフィールドは、貯蔵部において変更時即時配達としてマークされる。それ故、この情報は、メタデータの一部分として得られる。一実施形態において、クライアント側フレームワークは、この情報を使用して、フィールド値の変更を処理のためにサーバーへいつ送信すべきかを判断する。次いで、サーバーは、上述した通知メカニズムを使用して応答し、サーバーにより処理された変更の結果として、依存変更を返送する。例えば、特定フィールドの値が変化したことを検出すると（この特定フィールドは、変更時即時配達としてマークされたものである）、クライアントは、この特定フィールドの値と、変化した他のクライアント側フィールドの値とを処理のためにサーバーへ直ちに提出する。次いで、サーバーは、通知メカニズムを使用して応答し、依存変更に基づいて適当なアクションを取るためにクライアントに対する依存変更を返送する。例えば、第１フィールドの値が変化して、第２フィールドの値及び／又はフォーマットを変化させた場合には、サーバーから通知を受け取ると、クライアントは、第２フィールドの値及び／又はフォーマットを適宜に変更させる。一実施形態において、変更時即時配達プロセスを実行するためのロジックは、クライアント側で実行されるＪａｖａＳｃｒｉｐｔコードの一部分として実施される。
【０２１９】
図４０は、本発明の一実施形態に基づくビジネスコンポーネントフィールドの幾つかの特性又は属性を示す。ＮＡＭＥ、ＣＯＬＵＭＮ等の典型的な特性又は属性に加えて、ビジネスコンポーネントフィールドは、上述した変更時即時配達処理に対して各ビジネスコンポーネントフィールドをマークするのに使用される特性又は属性も含むことができる。説明上、この特性は、変更時即時配達(IMMEDIATE POST-WHEN-CHANGE)特性と称することができる。一実施形態において、この特性は、対応するビジネスコンポーネントフィールドが変更時即時配達処理に対してマークされたことを指示するためにある値（例えば、ＴＲＵＥ）にセットすることができると共に、さもなければ、別の値（例えば、ＦＡＬＳＥ）にセットすることができる。上述したように、この情報は、フィールド値に対する変更を処理のためにサーバーへいつ送信するか判断するためにクライアント側フレームワークにより使用される。
【０２２０】
図４１は、本発明の教示に基づくプロセスの一実施形態のフローチャートである。ブロック４１１０において、他のフィールド（１つ又は複数）が依存するところの１つ以上のフィールドが識別される。ブロック４１２０において、識別されたフィールドが、変更時即時配達処理に対してマークされる。上述したように、一実施形態において、識別されたフィールドが貯蔵部においてマークされ（例えば、これらフィールドの適当な特性を特定の値にセットすることにより）、従って、この情報は、メタデータの一部分として得られる。ブロック４１３０において、ランタイム中に、クライアントは、マークされたフィールドの値が変化したかどうか検出する。ブロック４１４０において、マークされたフィールドの値が変化した場合には、クライアントは、それらの値と、変化した他のクライアント側フィールドの値とを処理のためにサーバーへ送信する。ブロック４１５０において、サーバーは、変化を処理し、そして通知メカニズムを使用して応答し、依存変化をクライアントに返送する。
【０２２１】
ビジー状態マネージャー
慣習的なＨＴＭＬ又はウェブベースのアプリケーションにおいて経験する問題の１つは、クライアント（例えば、ブラウザ）が処理のためにサーバーへ要求を送信したときに、ある時間周期内にサーバーが応答しなかった場合に時間切れとなることである。この時間切れ状態は、要求の形式、サーバーにおいて利用できるリソース、サーバーにより処理されている又は処理されるべく待機している要求の数等の種々のファクタに基づいて、ある要求を処理するのに長い時間を要したとしても、発生する。例えば、慣習的なウェブベースのアプリケーション又はＨＴＭＬアプリケーションにおけるクライアントは、非常に時間のかかる問合せオペレーションを大きなデータベースに伴う要求を提出することがある。この要求は、時間切れ状態が発生するまでに終了しないことがある。
【０２２２】
本発明の一実施形態によれば、サーバー側にロングラン即ち時間のかかるオペレーションを伴う要求をクライアントがサーバーへ提出したときに、サーバーが上述した通知メカニズムを使用して適宜クライアントに通知できるようなメカニズムが提供される。要求に関してサーバーにより与えられる情報に基づいて、クライアントは、要求の状態をユーザに通知するために適当なアクションをとることができる（例えば、どれほどのタスクがそれまでに完了したかを示す進行バーを表示する等によって）。一実施形態において、要求の状態及び進行に関する通信は、以下に詳細に述べるように管理することができる。
【０２２３】
図４２は、本発明の教示に基づくシステムコンフィグレーションの一実施形態を示すブロック図である。図４２に示すように、クライアントは、サーバーにより与えられた情報（例えば、要求処理の状態及び進行に関してサーバーにより与えられた通知）に基づいて、サーバーへ提出された要求の状態及び進行を監視してそれをユーザに通知するように構成されたビジー状態マネージャーと称されるコンポーネントを含むことができる。一実施形態において、サーバーも、クライアントから受け取られた要求の状態及び進行をクライアントに通知するように構成されたビジー状態マネージャーをサーバー側に含むことができる。一実施形態において、サーバー側のビジー状態マネージャーは、クライアントから要求を受け取ったときに、要求がロングランのサーバーオペレーションを含むか又は終了までに長時間を要するかを種々のファクタに基づいて決定するように構成される。一実施形態において、これら種々のファクタは、要求の形式、要求のプライオリティ、要求の処理に利用できるリソース、処理されている要求及びサーバーにより処理されるべき待ち行列に待機している要求を含む保留中要求の数等を含むことができる。
【０２２４】
一実施形態において、クライアントから受け取られた要求が処理に長時間を要すると決定されると（例えば、要求はロングランのサーバーオペレーション等を含む）、サーバーは、クライアントに適宜通知する。一実施形態において、クライアントが、サーバーにより、要求の処理に長時間を要すると通知されたときに、クライアントは、要求の処理が開始されそして要求がサーバーにより処理されている時間中にユーザインターフェイスをロックすることをユーザに通知することができる。一実施形態において、サーバーは、要求の進行をクライアントに通知し続け、そしてクライアントは、要求処理が終了するまでユーザに適宜通知するように適当なアクションをとることができる。例えば、通知によりサーバーから進行情報を受信すると、クライアントは、その時点でどれほどのタスクが完了したかユーザに示すために進行バーを更新することができる。一実施形態において、ユーザインターフェイスは、要求処理が完了するまでロックされ続ける。
【０２２５】
図４３は、本発明の一実施形態に基づくプロセス４３００のフローチャートである。ブロック４３１０において、クライアントは、サーバーに要求を送信する。ブロック４３２０において、サーバーは、要求を処理するのに長時間を要する（例えば、要求は、ロングランのサーバーオペレーション等を伴う）と決定する。ブロック４３３０において、サーバーは、要求を終了するのに長時間を要することをクライアントに通知する。一実施形態において、サーバーは、上述した通知メカニズムを使用してこの情報をクライアントへ通信する。ブロック４３４０において、クライアントは、ユーザインターフェイスをロックし、要求処理がスタートして終了に長時間を要することをユーザに通知する。ブロック４３５０において、サーバーは、要求処理の進行をクライアントに通知する。ブロック４３６０において、クライアントは、サーバーにより与えられた情報に基づいて要求処理の進行をユーザに通知する（例えば、進行バーを使用して）。ブロック４３７０において、クライアントは、ユーザインターフェイスをロックし続け、そして要求処理が完了するまで、サーバーにより与えられた進行情報に基づいて要求の進行をユーザに通知する。
【０２２６】
ＩＩＩ．キャッシング
上述したように、ブラウザにおけるオブジェクト、及びＯＭにより管理されるオブジェクトは、１つ又は多数の計算装置に存在して動作するように構成できる。上述したように、図６Ａは、ブラウザにおけるオブジェクト５０２、及びＯＭにより管理されるオブジェクト５０４が、クライアント６０２及びサーバー６０４を含む多数の計算装置６０２、６０４に存在して動作するような例示的コンフィギュレーション６００を示す。図６Ｂは、ブラウザにおけるオブジェクト５０２、及びＯＭにより管理されるオブジェクト５０４が、１つの計算装置６５２に存在して動作するような例示的コンフィギュレーション６５０を示す。
【０２２７】
図４４は、一般に、図６Ａに示されそして図６Ａを参照して上述したコンフィグレーション６００と同様の多装置コンフィギュレーション４４００において動作するフレーム又はインフラストラクチャーの部分ブロック図である。図４４は、クライアント４４０４において動作するブラウザ４４０２を示す。このブラウザ４４０２は、上記で詳細に述べたＲＰＣメカニズム４４０８及び通知メカニズム４４１０を使用してサーバー４４０６と通信する。
【０２２８】
ビュー又はＪＳＳＶｉｅｗオブジェクト４４１２、及び複数のアプレット又はＪＳＳＡｐｐｌｅｔオブジェクト４４１４1、４４１４2、・・・４４１４N（Ｎは正の整数）は、ブラウザ４４０２において動作するように示されている。ＪＳＳＶｉｅｗオブジェクト４４１２は、一般に、ビューを表わす。上述したように、ビューは、一般に、アプレットの特定配列より成るディスプレイパネルである。上述したように、アプレットは、一般に、ビューの一部分としてスクリーン上に現われる視覚アプリケーションユニットである。各アプレット又はＪＳＳＡｐｐｌｅｔオブジェクト４４１４1、４４１４2、・・・４４１４Nは、ビュー又はＪＳＳＶｉｅｗオブジェクトにより表わされたビューに関連したアプレットを表わす。
【０２２９】
クライアント４４０４は、性能を改善するためにビューを一般的に記憶するキャッシュ４４１６を備えている。時々、ユーザは、新たなビューへナビゲートし又は切り換えて、クライアント４４０４が、新たなビューへナビゲートするための対応する要求をサーバー４４０６へ提出できるようにする。上述したように、クライアント４４０４がビューへナビゲートするための要求をサーバー４４０６へ提出すると、サーバー４４０６は、データのないビューレイアウトを含む応答又は通知を送信する。従って、ビューレイアウト及びビューカスタムオプションをサーバー４４０６から検索するには、サーバー４４０６へのラウンドトリップ（クライアント４４０４からサーバー４４０６への要求と、サーバー４４０６からクライアント４４０４への応答又は通知とを含む）が通常必要となる。ビューレイアウト及びビューカスタムオプションは、図４５に一般的に示され、そして図４５を参照して以下に一般的に説明する。各ラウンドトリップは、貴重な計算リソースを占有し、そして時間遅延を生じさせることに注意されたい。ビューレイアウト及びビューカスタムオプションをクライアント４４０４へ送信した後に、サーバー４４０６は、ビューをポピュレートするためのデータを含む応答を送信する。
【０２３０】
性能を改善するために、１つ以上のビューレイアウト及びビューカスタムオプションをキャッシュに記憶することができる。そのレイアウト及びカスタムオプションがキャッシュに記憶されると、ビューは、一般に、キャッシュされたビューと称することができる。ユーザが、キャッシュされたビューへナビゲートする場合には、クライアント４４０４は、ビューレイアウト及びビューカスタムオプションをサーバーではなくキャッシュから検索することができる。ビューレイアウト及びビューカスタムオプションをキャッシュから検索することにより、サーバー４４０６へのラウンドトリップを排除して、システム性能を改善することができる。
【０２３１】
図４５は、本発明の一実施形態に基づく例示的キャッシュ４４１６の構造を一般的に示す。この図に示すように、キャッシュ４４１６は、複数のキャッシュエントリー４５１８1、４５１８2、・・・４５１８Mを含むことができ、但し、Ｍは正の整数である。一実施形態において、各キャッシュエントリー４５１８1、４５１８2、・・・４５１８Mは、ビューのレイアウト４５２０を記憶するように設計することができる。上述したように、ビューは、一般に、アプレットの特定配列より成るディスプレイパネルである。従って、ビューのレイアウトは、一般に、ビューに関連したアプレットのレイアウト４５２４1、４５２４2、・・・４５２４Nを含むことができる。
【０２３２】
一実施形態において、各キャッシュエントリー４５１８1、４５１８2、・・・４５１８Mは、ビューに関連したカスタマイズされたオプション４５２２に対して設計することもできる。一実施形態において、ビューのカスタマイズされたオプション４５２２は、キーボードアクセラレータ４５２６及び好み４５２８を含むことができる。キーボードアクセラレータ４５２６は、一般に、コマンドオブジェクトへマップされる一連のキー又はキーストロークである。コマンドオブジェクトの一例を図示して一般的に上述した。好み４５２８は、一般に、デフォールトであるか、又はユーザ選択されたディスプレイオプションである。好みは、例えば、フォント、フォントサイズ、フォントカラー、行及び列の巾等を含むことができる。
【０２３３】
図４６は、ビューをキャッシュする例示的プロセス４６００の概要を一般的に示す。ブロック４６０５において、クライアントは、あるビューへ切り換えるためのユーザからの要求を受け取る。クライアントは、ビューがキャッシュに現在セーブされているかどうか決定する（ブロック４６１０）。ビューがキャッシュに現在セーブされていない場合には、クライアントは、ビューレイアウト及びビューカスタムオプションをサーバーから検索する（ブロック４６１５）。ビューレイアウト及びビューカスタムオプションは、図４５に示され、これを参照して上述した。ブロック４６２０において、クライアントは、キャッシュがいっぱいであるかどうか決定する。キャッシュにまだ使用可能な記憶スペースがある場合には、クライアントは、ビューをキャッシュすることで処理を進める。キャッシュがいっぱいである場合には、クライアントは、キャッシュをフラッシュして、ビューのためにキャッシュの記憶スペースを空け（ブロック４６２５）、次いで、ビューをキャッシュ記憶する。ビューのキャッシュ記憶は、ビューレイアウトをキャッシュ記憶することを含む（ブロック４６３０）。ビューのキャッシュ記憶は、更に、ビューカスタムオプションをキャッシュ記憶することも含む（ブロック４６３５）。
【０２３４】
図４７は、あるビューへ切り換える例示的プロセス４７００の概要を一般的に示す。ブロック４７０５において、クライアントは、あるビューへ切り換えるためのユーザからの要求を受け取る。クライアントは、そのビューがキャッシュに現在セーブされているかどうか決定する（ブロック４７１０）。ビューがキャッシュに現在セーブされていない場合には、クライアントは、ビューレイアウト及びビューカスタムオプションをサーバーから検索する（ブロック４７１５）。ビューレイアウト及びビューカスタムオプションは、図４５に示され、これを参照して上記で一般的に説明されたことに注意されたい。
【０２３５】
ビューがキャッシュに現在セーブされている場合には、クライアントは、ビューレイアウト及びビューカスタムオプションをキャッシュから検索する（ブロック４７２０）。クライアントは、ビューレイアウト及びビューカスタムオプションをキャッシュから検索することによりサーバーへのラウンドトリップをセーブし、システム性能を改善する。ビューレイアウト及びビューカスタムオプションを検索した後に、クライアントは、ビューレイアウトを使用してビューを表示し（ブロック４７２５）、そしてビューカスタムオプションをビューに適用する（ブロック４７３５）。ビューを表示した後に、クライアントは、ビューのためのデータをサーバーから検索する（ブロック４７３５）。サーバーからデータを受信した後に、クライアントは、検索されたデータでビュー内のフィールドをポピュレートする（ブロック４７４０）。
【０２３６】
図４８は、更新を暗示的にコミットするための方法の一実施形態を示すフローチャートである。ブロック４８１０において、記録フィールドが更新を受け取る。更新は、以前の記録フィールド値に対する追加、削除又は変更である。更新は、クライアントにキャッシュ記憶される。ブロック４８２０において、アプリケーションモジュールは、コンテクスト変更要求を受け取る。ブロック４８３０において、アプリケーションモジュールは、キャッシュ記憶された更新をアプリケーションモジュールへ送信するように記録フィールドに要求する。ブロック４８４０において、アプリケーションモジュールは、記録フィールドから更新を受け取る。ブロック４８５０において、アプリケーションモジュールは、記録フィールドから受け取った更新をサーバーへ送信し、その更新をデータベースへコミットする。ブロック４８６０において、サーバーは、更新が首尾良くコミットされたことを指示する通知をアプリケーションへ送信する。ブロック４８７０において、アプリケーションモジュールは、コンテクスト変更要求をサーバーへ送信する。ブロック４８８０において、サーバーは、コンテクスト変更要求を処理し、そして新たなコンテクストをアプリケーションモジュールへ返送する。
【０２３７】
図４９は、表示の実施例を示す。表示４９３８は、ウェブブラウザ４９００のコンポーネントとして示される。表示４９３８は、記録フィールド５２２の更新値Ｎｅｗ  Ａｃｃｏｕｎｔを示す。この更新値は、コンテクスト変更に応答して暗示的にコミットされる。図５０は、新たな記録フィールドの表示５０３０が選択されたコンテクスト変更を示す。
【０２３８】
本発明のこれら及び他の実施形態は、これらの教示に基づいて実現することができ、そして本発明の広い精神及び範囲から逸脱せずにこれらの教示において種々の変更や修正がなされ得ることが明らかであろう。従って、本明細書及び添付図面は、単なる例示に過ぎず、それらに限定されるものではなく、本発明は、特許請求の範囲のみによって限定されるものとする。
【０２３９】
更に、上述した方法を遂行するための命令は、他の形態のコンピュータ読み取り可能な媒体に記憶することもできる。マシン読み取り可能な媒体は、マシン（例えば、コンピュータ）により読み取り可能な形態で情報を与える（例えば、記憶及び／又は送信する）いかなるメカニズムも包含する。例えば、マシン読み取り可能な媒体は、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光学的記憶媒体、フラッシュメモリデバイス、電気的、光学的、音響的又は他の形態の伝播信号（例えば、搬送波、赤外線信号及びデジタル信号）を包含する。
【図面の簡単な説明】
【０２４０】
【図１】本発明の教示が実施される多層システムアーキテクチャーを示す図である。
【図２】本発明の教示が実施されるシステムコンフィギュレーションの一実施形態を示すブロック図である。
【図３】本発明の教示に基づいてアプリケーションを構築することのできる多層アーキテクチャーの別の論理的プレゼンテーションを示すブロック図である。
【図４】本発明の教示が実施されるアプリケーションフレームワークの一実施形態を示すブロック図である。
【図５Ａ】図２の双方向ウェブクライアント及び移動ウェブクライアントをサポートするためのフレームワーク又はインフラストラクチャー５００の一例を示す図である。
【図５Ｂ】図５Ａに示したフレームワーク又はインフラストラクチャーの別の例を示す図である。
【図５Ｃ】更新を暗示的にコミットするのに適した計算システムの実施形態を示す図である。
【図６Ａ】ブラウザのオブジェクト、及びオブジェクトマネージャー（ＭＯ）により管理されるオブジェクトが、クライアント及びサーバーを含む多数の計算装置に存在して動作するコンフィギュレーションを例示する図である。
【図６Ｂ】ブラウザのオブジェクト、及びＭＯにより管理されるオブジェクトが、１つの計算装置に存在して動作するコンフィギュレーションを例示する図である。
【図７】プログラムを、別々の計算装置において実行できる断片に分割するために、リモート手順コール（ＲＰＣ）パラダイムをいかに使用できるかの一例を示す図である。
【図８】リモート手順コールと共に使用される実行モデルの一例を示す図である。
【図９】ＲＰＣクライアント及びＲＰＣサーバーにおいてＲＰＣアプリケーションコードセグメント、ＲＰＣインターフェイス、スタブ、及びＲＰＣランタイムライブラリーの区画例を一般に示す図である。
【図１０】ＡＳＣＩＩデータとＥＢＣＤＩＣデータとの間のマーシャリング及びアンマーシャリングの例を一般的に示す図である。
【図１１】リモート手順コール中のＲＰＣアプリケーションコードセグメント、ＲＰＣインターフェイス、ＲＰＣスタブ及びＲＰＣランタイムライブラリーの役割の一例を一般的に示す図である。
【図１２】分散型ＲＰＣアプリケーションを構築する例示的プロセス１２００の概要を一般的に示す図である。
【図１３】ローカルＲＰＣランタイムライブラリーと、アプリケーションコードから発生されたオブジェクトコードとのリンクを一般的に示す図である。
【図１４】図６Ａに示された多装置コンフィギュレーションにおいて実行されるブラウザ側又はクライアント側オブジェクトとサーバー側オブジェクトとの間の通信の例示的プロセスを一般的に示す図である。
【図１５】ブラウザ側アプレットがＪＳＳＢｕｓＣｏｍｐオブジェクトにおいてメソッドを直接インボークする例示的通信プロセスを示す図である。
【図１６】ツールバーの一例を示す図である。
【図１７】アプリケーションレベルメニューの一例を示す図である。
【図１８】アプレットメニューメニューの一例を示す図である。
【図１９】種々のコマンドの構成及び実行に使用される種々のオブジェクトを生成するためのプロセスの一実施形態を示すフローチャートである。
【図２０】本発明の教示に基づくコマンドオブジェクトを生成するためのプロセスの一実施形態を示すフローチャートである。
【図２１】本発明の教示に基づくコマンドオブジェクトの特性の一実施形態を示す図である。
【図２２】本発明の教示に基づくツールバーオブジェクトを生成するプロセスの一実施形態を示すフローチャートである。
【図２３】本発明の教示に基づくツールバーオブジェクトの特性の一実施形態を示す図である。
【図２４】本発明の教示に基づくツールバーアイテムオブジェクトを生成するプロセスの一実施形態を示すフローチャートである。
【図２５】本発明の教示に基づくツールバーアイテムオブジェクトの特性の一実施形態を示す図である。
【図２６】本発明の教示に基づくメニューアイテムオブジェクトを生成するプロセスの一実施形態を示すフローチャートである。
【図２７】本発明の教示に基づくメニューアイテムオブジェクトの特性の一実施形態を示す図である。
【図２８】本発明の教示に基づくアプレットメソッドメニューアイテムオブジェクトを生成するプロセスの一実施形態を示すフローチャートである。
【図２９】本発明の一実施形態に基づくアプレットメソッドメニューアイテムオブジェクトの特性を示す図である。
【図３０】本発明の一実施形態に基づくクラスメソッドメニューオブジェクトを生成するプロセスの一実施形態を示すフローチャートである。
【図３１】本発明の一実施形態に基づくクラスメソッドメニューアイテムの特性を示す図である。
【図３２】本発明の一実施形態に基づくツールバーオブジェクトと、ツールバーアイテムオブジェクトと、コマンドオブジェクトとの関係を示す図である。
【図３３】メニューオブジェクトと、メニューアイテムオブジェクトと、コマンドオブジェクトとの関係を示す図である。
【図３４】アプレットレベルメニューオブジェクトと、アプレットメソッドメニューアイテムオブジェクトと、クラスメソッドメニューアイテムオブジェクトとの関係を示す図である。
【図３５】本発明の教示が実施されるシステムコンフィギュレーション３５００の一実施形態のブロック図である。
【図３６】本発明の一実施形態に基づくプロセスのフローチャートである。
【図３７】本発明の一実施形態に基づくプロセスのフローチャートである。
【図３８】本発明の一実施形態に基づく種々のオブジェクトの関係を示すブロック図である。
【図３９】本発明の一実施形態に基づくビジネスコンポーネントの論理的構造を示すブロック図である。
【図４０】本発明の一実施形態に基づくビジネスコンポーネントフィールドの幾つかの特性又は属性を示す図である。
【図４１】本発明の教示に基づくプロセスの一実施形態のフローチャートである。
【図４２】本発明の教示に基づくシステムコンフィギュレーションの一実施形態のブロック図である。
【図４３】本発明の一実施形態に基づくプロセスのフローチャートである。
【図４４】一般的に、図６Ａに示されそして図６Ａを参照して上述したコンフィギュレーションと同様の多装置コンフィギュレーションにおいて動作するフレーム又はインフラストラクチャーの部分ブロック図である。
【図４５】本発明の一実施形態に基づく例示的キャッシュの構造を一般的に示す図である。
【図４６】本発明の一実施形態に基づきビューをキャッシング記憶する例示的プロセスの概要を一般的に示す図である。
【図４７】本発明の一実施形態に基づきビューへ切り換える例示的プロセスの概要を一般的に示す図である。
【図４８】更新を暗示的にコミットする方法の実施形態を示すフローチャートである。
【図４９】表示の一例を示す図である。
【図５０】新たな記録フィールドの表示が選択されたコンテクスト変更を示す図である。
【図１】
2005516272.tif 000005
【図２】
2005516272.tif 000006
【図３】
2005516272.tif 000007
【図４】
2005516272.tif 000008
【図５Ａ】
2005516272.tif 000009
【図５Ｂ】
2005516272.tif 000010
【図５Ｃ】
2005516272.tif 000011
【図６Ａ】
2005516272.tif 000012
【図６Ｂ】
2005516272.tif 000013
【図７】
2005516272.tif 000014
【図８】
2005516272.tif 000015
【図９】
2005516272.tif 000016
【図１０】
2005516272.tif 000017
【図１１】
2005516272.tif 000018
【図１２】
2005516272.tif 000019
【図１３】
2005516272.tif 000020
【図１４】
2005516272.tif 000021
【図１５】
2005516272.tif 000022
【図１６】
2005516272.tif 000023
【図１７】
2005516272.tif 000024
【図１８】
2005516272.tif 000025
【図１９】
2005516272.tif 000026
【図２０】
2005516272.tif 000027
【図２１】
2005516272.tif 000028
【図２２】
2005516272.tif 000029
【図２３】
2005516272.tif 000030
【図２４】
2005516272.tif 000031
【図２５】
2005516272.tif 000032
【図２６】
2005516272.tif 000033
【図２７】
2005516272.tif 000034
【図２８】
2005516272.tif 000035
【図２９】
2005516272.tif 000036
【図３０】
2005516272.tif 000037
【図３１】
2005516272.tif 000038
【図３２】
2005516272.tif 000039
【図３３】
2005516272.tif 000040
【図３４】
2005516272.tif 000041
【図３５】
2005516272.tif 000042
【図３６】
2005516272.tif 000043
【図３７】
2005516272.tif 000044
【図３８】
2005516272.tif 000045
【図３９】
2005516272.tif 000046
【図４０】
2005516272.tif 000047
【図４１】
2005516272.tif 000048
【図４２】
2005516272.tif 000049
【図４３】
2005516272.tif 000050
【図４４】
2005516272.tif 000051
【図４５】
2005516272.tif 000052
【図４６】
2005516272.tif 000053
【図４７】
2005516272.tif 000054
【図４８】
2005516272.tif 000055
【図４９】
2005516272.tif 000056
【図５０】
2005516272.tif 000057
【国際調査報告】
2005516272.tif 000058
2005516272.tif 000059