(57)【要約】モバイルウェブ（210）のための方法、システム及び装置を提供する。1つの実施例において、本発明は、ウェブアプリケーションを動作させる方法である。前記方法は、クライアント（210）からのリクエストを受信することを含んでいる。さらに、前記方法は、ウェブエミュレータを用いて前記リクエストを処理することを含んでいる。また、前記方法は、利用できるデータから前記リクエストを提供することを含んでいる。
2005505055.tif 000002
【特許請求の範囲】
【請求項１】
クライアントウェブブラウザからのリクエストを受信する段階と、
ウェブエミュレータを用いて前記リクエストを処理する段階と、
利用できるデータから前記リクエストを提供する段階と、を備えているウェブアプリケーションを動作させる方法。
【請求項２】
前記利用できるデータが、ネットワークを介して利用できることを特徴とする請求項１に記載の方法。
【請求項３】
前記利用できるデータが、ネットワークに対するアクセスなしにローカルに利用できることを特徴とする請求項１に記載の方法。
【請求項４】
ネットワークを介して利用できるデータに対するアクセスを試行する段階をさらに備えている請求項１に記載の方法。
【請求項５】
前記ネットワークを介して成功したアクセスにおいて、前記リクエストを提供する段階が、前記ネットワークから利用できるデータを利用することを特徴とする請求項４に記載の方法。
【請求項６】
前記ネットワークを介して失敗したアクセスにおいて、前記リクエストを提供する段階が、前記ローカルデータからの利用できるデータを利用することを備えている請求項４に記載の方法。
【請求項７】
ネットワークを介して利用できるデータに対するアクセスを試行する段階を備え、
前記リクエストを提供する段階が、成功したアクセスにおいて前記ネットワークからの利用できるデータを利用し、失敗したアクセスにおいてローカルデータからの利用できるデータを利用することをさらに備えている請求項１に記載の方法。
【請求項８】
前記ウェブエミュレータがウェブサーバに対するプラグインであり、前記プラグインが前記リクエストをウェブエンジンに通過させ、前記ウェブエンジンがデータマネージャに関連して前記リクエストを提供することを特徴とする請求項１に記載の方法。
【請求項９】
前記利用できるデータがネットワークを介して利用できることを特徴とする請求項８に記載の方法。
【請求項１０】
前記利用できるデータがネットワークに対するアクセスなしにローカルに利用できることを特徴とする請求項８に記載の方法。
【請求項１１】
前記データマネージャが、ネットワークを介して利用できるデータに対するアクセスを試行することを備え、前記データマネージャが、成功したアクセスにおいて前記ネットワークからの利用できるデータを利用し、前記リクエストを提供するのに失敗したアクセスにおいてローカルデータから利用できるデータを利用することをさらに特徴とする請求項８に記載の方法。
【請求項１２】
前記リクエストがクライアントから前記ネットワークにデータを送信する段階を含むことを特徴とする請求項１に記載の方法。
【請求項１３】
前記リクエストが前記ネットワークからのデータを受信する段階を含むことを特徴とする請求項１に記載の方法。
【請求項１４】
前記リクエストがデータを送受信する段階をさらに含むことを特徴とする請求項１に記載の方法。
【請求項１５】
クライアントからのリクエストを受信する段階と、
ウェブエミュレータを用いて前記リクエストを処理する段階と、
データベースにおいて利用できるデータから前記リクエストを提供する段階と、を備えているデータベースに関連して利用するウェブアプリケーションを動作させる方法。
【請求項１６】
前記リクエストがクライアントウェブブラウザから生じることを特徴とする請求項１５に記載の方法。
【請求項１７】
前記利用できるデータがメインデータベースにおいてネットワークを介して利用できることを特徴とする請求項１５に記載の方法。
【請求項１８】
前記利用できるデータがネットワークに対するアクセスなしにローカルデータベースにおいてローカルに利用できることを特徴とする請求項１５に記載の方法。
【請求項１９】
ネットワークを介してメインデータベースにおいて利用できるデータに対するアクセスを試行することをさらに備えている請求項１５に記載の方法。
【請求項２０】
前記ネットワークを介して成功したアクセスにおいて、前記リクエストを提供する段階が、前記ネットワークを介して前記メインデータベースからの利用できるデータを利用することを特徴とする請求項１９に記載の方法。
【請求項２１】
前記ネットワークを介して失敗したアクセスにおいて、前記リクエストを提供する段階が、ローカルデータベースにおいてローカルデータからの利用できるデータを利用することを特徴とする請求項１９に記載の方法。
【請求項２２】
クライアントウェブブラウザからのリクエストを受信する手段と、
前記リクエストを処理する手段と、
利用できるデータからの前記リクエストを提供する手段と、を備えているウェブアプリケーションを動作させる装置。
【請求項２３】
プロセッサによって実行される場合に、前記プロセッサが、
クライアントウェブブラウザからのリクエストを受信する段階と、
ウェブエミュレータを用いて前記リクエストを処理する段階と、
利用できるデータから前記リクエストを提供する段階と、を備えている方法を実現できる、命令を組み入れているマシン読み取り可能な媒体。
【請求項２４】
前記プロセッサによって実行される場合に、前記プロセッサが、前記利用できるデータがネットワークを介して利用できる前記方法を実現できる、命令をさらに組み入れている請求項２３に記載のマシン読み取り可能な媒体。
【請求項２５】
前記プロセッサによって実行される場合に、前記プロセッサが、前記利用できるデータがネットワークに対するアクセスなしにローカルに利用できる前記方法を実現できる、命令をさらに組み入れている請求項２３に記載のマシン読み取り可能な媒体。
【請求項２６】
前記プロセッサによって実行される場合に、前記プロセッサが、
ネットワークを介して利用できるデータに対するアクセスを試行する段階を備える前記方法であって、
前記リクエストを提供する段階が、成功したアクセスにおいて前記ネットワークから利用できるデータを利用し、失敗したアクセスにおいてローカルデータから利用できるデータを利用することをさらに備える前記方法を実現できる、命令をさらに組み入れている請求項２３に記載のマシン読み取り可能な媒体。
【請求項２７】
プロセッサによって実行される場合に、前記プロセッサが、
クライアントウェブブラウザからのリクエストを受信する段階と、
ウェブエミュレータを用いて前記リクエストを処理する段階と、
データベースにおいて利用できるデータから前記リクエストを提供する段階と、を備えている方法を実現できる、命令を組み入れているマシン読み取り可能な媒体。
【請求項２８】
前記プロセッサによって実行される場合に、前記プロセッサが、前記利用できるデータがメインデータベースにおいてネットワークを介して利用できる前記方法を実現できる、命令をさらに取り入れている請求項２７に記載のマシン読み取り可能な媒体。
【請求項２９】
前記プロセッサによって実行される場合に、前記プロセッサが、前記利用できるデータがネットワークに対するアクセスなしにローカルデータベースにおいてローカルに利用できる前記方法を実現できる、命令をさらに取り入れている請求項２７に記載のマシン読み取り可能な媒体。
【請求項３０】
前記プロセッサによって実行される場合に、前記プロセッサが、ネットワークを介してメインデータベースにおいて利用できるデータに対するアクセスを試行する段階をさらに備えている前記方法を実現できる、命令をさらに取り入れている請求項２７に記載のマシン読み取り可能な媒体。
【請求項３１】
前記プロセッサによって実行される場合に、前記プロセッサが、前記ネットワークを介して成功したアクセスにおいて前記リクエストを提供する段階が前記ネットワークを介して前記メインデータベースから利用できるデータを利用する前記方法を実現できる、命令をさらに取り入れている請求項３０に記載のマシン読み取り可能な媒体。
【請求項３２】
前記プロセッサによって実行される場合に、前記プロセッサが、前記ネットワークを介して失敗したアクセスにおいて前記リクエストを提供する段階がローカルデータベースにおいてローカルデータから利用できるデータを利用することをさらに備えている前記方法を実現できる、命令をさらに取り入れている請求項３０に記載のマシン読み取り可能な媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、データ処理の分野に関する。より詳細には、本発明は、モバイルウェブクライアントに対する方法、装置及びシステムに関する。
【背景技術】
【０００２】
本出願は、2001年9月29日に提出された“METHOD, APPARATUS AND SYSTEM FOR A MOBILE WEB CLIENT”の名称にかかる特許番号60/326,741を有する仮出願に対する優先権を主張する。
【０００３】
技術が進歩し続け、ビジネス環境がますます複雑かつ多様になるにつれて、より多くの会社が、様々な顧客関係管理（CRM）ソフトウェア及びeビジネスアプリケーションに依存してきており、それらの企業ビジネスの様々な側面を実行管理している。一般に、eビジネスアプリケーションは、その顧客、パートナー、供給者、分配者、従業員等を有する相互に作用するネットワーク（例えば、インターネット、イントラネット、エクストラネット等）を介して会社又は企業がそのビジネスを遂行できるように設計される。eビジネスアプリケーションは、コアビジネスプロセス、サプライチェーン、バックオフィスオペレーション、及びCRM機能を含んでいる。一般に、CRMは、会社が販売及び/又はサービスに対してその顧客と共に有する相互作用の様々な形勢を含んでいる。高いレベルでは、顧客関係管理は、顧客の要求を理解し、この理解を機能させて、売上を伸ばしサービスを改善することに集束される。CRMアプリケーション及びソフトウェアは、一般に、販売及びサービスの間の有効かつ効率のよい相互作用を提供するように設計され、顧客の周囲の会社の作業を統一し、顧客の満足を通して顧客共有及び顧客保有を増大させる。
【０００４】
典型的には、CRM導入戦略は、以下を考慮する必要がある。
【０００５】
知識管理：有効なCRM導入の重要な要素の１つは、顧客情報の獲得、その分析、共有及び追跡である。また、競争の優位性のために知識利用に対して絶対必要なのは、この知識の結果としてどのような行動が取られるかを従業員が理解することである。
【０００６】
データベース整理統合：有効かつ能率のよいCRMソリューションは、単一データベースでの顧客情報の整理統合及び顧客の周囲のビジネスプロセス改良である。ここで、目的は製造、マーケティング、販売及び顧客サポート作業を駆動させるために１つの場所に記憶される顧客と全ての相互作用を有することである。
【０００７】
チャネル及びシステムの統合：CRMｓアプリケーション/ソフトウェアが、それがeメール、電話、ウェブベースのユーザインターフェース等であろうとなかろうと、首尾一貫した顧客に対する応答能力、及びそれらの選択チャネルを介して高い品質の手法を提供することは非常に重要である。これは、顧客又は企業データベースを有する様々な通信チャネルのシームレスな統合を必要とする。また、それは、会社のビジネスシステム及びアプリケーションの他の部分とのCRMの統合を必要とする。
【０００８】
技術及びインフラストラクチャー：顧客サービスを強化するために、CRMアプリケーション/ソフトウェアは、オンライン顧客サービスを自動化して合理化する様々なツールを含んでいる。例えば、典型的には、自立モデルがツールの結合を利用して実現され得る（例えば、直感的サーチ能力を有する知識ベース、エージェント技術又は自動化されたeメール等）。
【０００９】
一般に、eビジネスアプリケーションは、組織が、ウェブ、コールセンター、フィールド、転売、小売り、及びディーラーネットワークを含む多数チャネルを介して顧客に販売し、購入し、供給するのをより簡単にする単一ソースの顧客情報を作ることができるように設計される。進歩したeビジネスは、典型的には、構成要素に基づいた構成で確立され、ウェブベースで設計され、モバイルクライアント、接続クライアント、シン・クライアント、及びハンドヘルドクライアント等を含む多数の計算プラットフォームの様々なタイプのクライアントに対してサポートするように設計される。
【００１０】
近年のウェブが急増している状況では、ウェブベース環境のeビジネスアプリケーションの機能性を提供することが望まれる。さらに、ユーザが既に熟知しているデスクトップベースのeビジネスアプリケーションのルックアンドフィールを保持することが、ウェブベース環境で機能するeビジネスアプリケーションに対して望まれる。
【００１１】
また、ウェブアプリケーションの出現で、前記アプリケーションの機能に対してインターネット又はワールドワイドウェブのようなネットワークを利用する依存状態に到達した。しかしながら、ネットワーク環境又は状況と対応する非ネットワーク環境又は状況との両方を動作させる確固とした解決策は、ウェブアプリケーションのモバイルユーザに対して有用であることが評価されるであろう。前記ウェブアプリケーションは、すぐには利用できない。
【００１２】
本発明は、添付図の制限なしに例を通して説明される。
【００１３】
モバイルウェブクライアントに対する方法、装置及びシステムを描写する。以下の描写では、説明の目的で、多数の特定の詳細を記載し、本発明の完全な理解を提供する。しかしながら、当業者にとっては、本発明がこれらの特定の詳細なしに実行され得ることは明らかである。他の例としては、構造及び装置を、本発明を不明瞭にすることを避けるためにブロック図の形態で示している。
【００１４】
“１つの実施例”又は“ある実施例”に対する明細書における基準は、実施例と関連して描写される特定の特徴、構造、又は特性が、本発明の少なくとも１つの実施例に含まれていることを意味する。明細書中の様々な場所の“１つの実施例における”というフレーズの出現は、全てが必ずしも同じ実施例に対して言及していることではなく、他の実施例を相互に両立しない分離した又は択一的な実施例ということでもない。
【発明の開示】
【課題を解決するための手段】
【００１５】
システム概観及び全体構成
１つの実施例において、本発明の教示が実現されるシステムは、図１に示すようなマルチレイヤー構成として論理的に構築され得る。１つの実施例において、図１に示すような論理的なマルチレイヤー構成は、共通サービスに対するプラットフォームを提供し、様々なアプリケーションをサポートする。これらのサービスは、ユーザインターフェースレイヤー110、オブジェクトマネージャレイヤー120、データマネージャ130、及びデータ交換レイヤー140を含んでいる。
【００１６】
１つの実施例において、ユーザインターフェースレイヤー110は、アプレット、表示、チャート及びレポート等を提供し、1つ又は複数のアプリケーションと協働する。1つの実施例において、様々なタイプのクライアントは、ユーザインターフェースレイヤー110を介してサポートされ得る。これらのタイプのクライアントは、従来の接続クライアント、遠隔クライアント、イントラネットを介したシン・クライアント、Java（登録商標）シン・クライアント又は非ウインドウズ（登録商標）ベースのオペレーティングシステム、及びインターネットを介したHTMLクライアント等を含んでいる。
【００１７】
１つの実施例において、オブジェクトマネージャレイヤー120は、1つ又は複数のアプリケーションと協働する1つ又は複数のセットのビジネスルール又はビジネスコンセプトを管理するように設計され、ユーザインターフェースレイヤー110とデータマネージャレイヤー130の間のインターフェースを提供している。１つの実施例において、ビジネスルール又はコンセプトは、ビジネスオブジェクトとして表され得る。１つの実施例において、ビジネスオブジェクトは、アカウント、コンタクト、オポチュニティ、サービスリクエスト、ソリューション等のような様々なビジネスルール又はコンセプトを代表する設定可能なソフトウェアとして設計される。
【００１８】
1つの実施例において、データマネージャレイヤー130は、下位データの論理的表示を維持し、オブジェクトマネージャが、データが記憶される下位データの構造又はテーブルについて独立して機能するように設計されている。また、1つの実施例において、データマネージャ130は、データにアクセスするためにリアルタイムで構造化照会言語（structure query language（SQL））の発生のような一定のデータベース照会機能を提供する。１つの実施例において、データマネージャ130は、データベーススキーマを定義するリポジトリファイル160のオブジェクト定義を動作させるように設計されている。１つの実施例において、データ記憶装置170は、１つ又は複数のアプリケーションと協働するデータモデルに対するデータ記憶を提供する。
【００１９】
1つの実施例において、データ交換レイヤーは、1つ又は複数の特定のターゲットデータベースと関連して処理し、データマネージャレイヤー130と下位データソースの間のインターフェースを提供するように設計されている。
【００２０】
図２は、本発明の教示が実現される１つの具体的なシステム配置のブロック図を示す。
【００２１】
1つの実施例において、マルチレイヤー構成により、1つ又は複数のソフトウェアレイヤーが異なるマシンに存在可能になる。例えば、１つの実施例において、ユーザインターフェース、オブジェクトマネージャ、及びデータマネージャは、全て、専用ウェブクライアントに存在し得る。ワイヤレスクライアントのような他のタイプのクライアントに対して、1つの実施例では、オブジェクトマネージャ及びデータマネージャは、システムサーバに存在し得る。図２に示すシステム配置は例証して説明する目的のものであり、本発明が教示する特定の実装及びアプリケーション次第で変化することは、当業者によって評価され、理解されるべきである。
【００２２】
1つの実施例において、図２に例証されるシステム環境は、2つ以上のデータベース290を含んでいる。1つ又は複数のデータベース290の部分は、複製マネージャによって作り出されるか又は複製される。加えて、モバイルウェブクライアントは、付加的な遠隔データベース（ローカルデータベースとも言う）を有し得る。1つの実施例において、モバイルウェブクライアントと協働する遠隔又はローカルなデータベースが、リードオンリーデータベースとして定義されない場合であって、各モバイルウェブクライアントがシステムサーバと同期する場合、これらのモバイルウェブクライアントは、最後にメインデータベースにまで伝搬されるデータをローカルに作り出し更新することができる。
【００２３】
1つの実施例において、データベース290は、定義済みデータスキーマ（例えば、テーブルオブジェクト、インデックスオブジェクト等）、リポジトリオブジェクト（例えば、ビジネスオブジェクト及びコンポーネント、表示定義、及びビジビリティルール等）、及びユーザの又は顧客のデータを含む様々なタイプのデータを記憶するように設計されている。1つの実施例において、専用ウェブクライアント及びサーバコンポーネントは、他のタイプのクライアントに関連して動作するものを含んでおり、直接、データベース290に接続し、リアルタイムで変更することができる。1つの実施例において、モバイルウェブクライアントは、一部のサーバのデータをダウンロードし、ローカルに利用でき、システムサーバを介して周期的にサーバデータベースと同期して、ローカル及びサーバデータベースの両方を更新することができる。
【００２４】
1つの実施例において、データベース290に含まれる様々なテーブルは、以下のタイプ：データテーブル、インターフェーステーブル、及びリポジトリテーブル等に論理的に組織化される。
【００２５】
1つの実施例において、データテーブルは、ユーザビジネスデータ、事務管理データ、シードデータ、及びトランザクションデータ等を記憶するのに用いられる。
【００２６】
1つの実施例において、これらのデータテーブルは、様々なアプリケーション及びプロセスを介して取り込まれ、更新される。1つの実施例において、データテーブルは、ベーステーブル及びインターセクションテーブル等を含んでいる。1つの実施例において、ベーステーブルは、様々なアプリケーションによって定義されて利用される列を含んでいる。1つの実施例において、ベーステーブルは、ビジネスコンポーネントのテーブル特性において特定されるビジネスコンポーネントに対する列を提供するように設計されている。1つの実施例において、インターセクションテーブルは、2つのビジネスコンポーネント間の多対多の関係を実現するのに用いられるテーブルである。
【００２７】
また、それらはインターセクションデータ列を保持し、各関連付けに適する情報を記憶する。1つの実施例において、インターセクションテーブルは、データ構造に関連アプレットを提供する。
【００２８】
1つの実施例において、インターフェーステーブルは、ベーステーブルのグループを単一テーブルに正規化しないようにするために利用され、外部プログラムはそれにインターフェースで連結できる。１つの実施例において、それらは、データのエクスポート及びインポートに対する準備のための場所として利用される。
【００２９】
1つの実施例において、リポジトリテーブルは、以下を考慮する1つ又は複数のアプリケーションを特定するオブジェクト定義を含んでいる。
【００３０】
・クライアントアプリケーション構成
・データをインポート及びエクスポートするために用いられるマッピング
・モバイルクライアントに対する転送データのためのルール
【００３１】
1つの実施例において、ファイルシステム295は、アプリケーションサーバに位置し得るネットワークアクセス可能なディレクトリである。１つの実施例において、ファイルシステム295は、第三者のテキスト編集者によって作られるファイルのような様々なアプリケーションによって作り出される物理的ファイルを記憶し、他のデータはデータベース290に記憶されない。1つの実施例において、ファイルシステム295に記憶された物理的ファイルは、様々な命名規則の下で圧縮され、記憶され得る。1つの実施例において、専用ウェブクライアントは、ファイルシステム295へ及びから直接的にファイルを読み出しと書き込みを行うことができる。１つの実施例において、モバイルウェブクライアントは、ローカルファイルシステムを有し、それらは、周期的にサーバベースのファイルシステム290と同期する。１つの実施例において、ワイヤレスクライアント及びウェブクライアントのような他のタイプのクライアントは、システムサーバを介してファイルシステム290にアクセスすることができる。
【００３２】
1つの実施例において、企業サーバ250は、共通テーブル所有者又はデータベースを共有し、共通ゲートウェイサーバを指示し、サーバマネージャ260を利用するグループとして管理され得る、システムサーバ255の論理グルーピングである。1つの実施例において、ゲートウェイサーバに対する接続は、TCP/IPを介して確立され得る。1つの実施例において、企業サーバ250は、企業サーバ250の多数のシステムサーバ255を配置することによって効果的に拡張され、これにより、アプリケーションの中間層の高い拡張性を提供する。
【００３３】
1つの実施例において、サーバ255は、1つ又は多数のサーバプログラムを実行する。それは、入力処理リクエストを処理し、サーバの全プロセスの状態をモニターする。1つの実施例において、サーバプログラムは、データをインポート及びエクスポートすることを含み、データベースを構成し、ワークフロー及び処理自動化を遂行し、モバイルウェブクライアントをサポートするように処理し、ビジネスルールを実施する、1つ又は複数の特定の機能又はジョブ等を実現するために設計され構成される。1つの実施例において、サーバ255は、（ウィンドウズNTオペレーティングシステム下の）NTサーバ又はUNIX（登録商標）オペレーティングシステム下のデーモン（例えば、バックグラウンドシェルプロセス）であり得る。1つの実施例において、サーバ255は、マルチプロセス及びマルチスレッドのコンポーネントの両方をサポートし、バッチ、サービス、及びインタラクティブモードのコンポーネントを動作させ得る。
【００３４】
1つの実施例において、サーバマネージャ260は、サーバ255及び企業サーバ250に対して異なるプログラムにわたる共通制御、管理、モニタリングを許可するユーティリティーとして構成される。1つの実施例において、サーバマネージャ260は、以下のタスク：スタート、ストップ、ポーズを実現するのに用いられ、サーバ255のコンポーネント及びタスクを再開し、ステータスをモニターし、多数のタスク、コンポーネント及び企業サーバ内のサーバに対する統計表を収集し、企業サーバ、個々のサーバ、個々のコンポーネント及びタスク等を構成する。
【００３５】
1つの実施例において、ゲートウェイサーバは、サーバにアクセスするための単一エントリポイントとして供する論理的エンティティとして構成され得る。それは、1つの実施例において、企業サーバにわたり強化された拡張性、ロードバランシング及び高稼働率を提供するのに用いられる。1つの実施例において、ゲートウェイサーバは、ネームサーバ及び接続ブローカコンポーネントを含んでいる。1つの実施例において、ネームサーバは、サーバと協働するパラメータのトラックを保持するように構成される。例えば、サーバと協働する稼働率及び接続性情報は、ネームサーバに記憶され得る。システムの様々なコンポーネントは、サーバの稼働率及び接続性を考慮している様々な情報をネームサーバに問い合わせることができる。ウィンドウズNT環境では、ネームサーバは、NTサービスとして実行され得る。UNIX環境では、ネームサーバは、デーモンプロセスとして実行され得る。1つの実施例において、接続ブローカコンポーネントは、クライアント接続リクエストを適当なサーバ（例えば、最も使用度の低いサーバ）に誘導するようにロードバランシング機能を実現するのに用いられる。
【００３６】
1つの実施例において、図２に例証するように、システムによってサポートされ得る様々なタイプのクライアントは、次のクライアント：専用ウェブクライアント、モバイルウェブクライアント、ウェブクライアント、ワイヤレスクライアント、及びハンドヘルドクライアント等を含んでいる。
【００３７】
1つの実施例において、専用ウェブクライアント（また、接続クライアントとも呼ばれる）は、LAN又はWAN接続を介したデータアクセスのためにデータベースサーバに直接的に接続される。1つの実施例において、これらの接続又は専用ウェブクライアントは、ローカルにデータを記憶しない。また、これらのウェブクライアントは、直接的にファイルシステムにアクセスできる。1つの実施例において、マルチレイヤー構成のユーザインターフェース、オブジェクトマネージャ、及びデータマネージャ層は、専用ウェブクライアントに存在する。
【００３８】
1つの実施例において、モバイルウェブクライアントは、ローカルデータアクセスに対して設計され、構成されており、それら自体のローカルデータベース及び/又はローカルファイルシステムを有する。1つの実施例において、モバイルウェブクライアントは、ゲートウェイサーバを介してシステム内の他のコンポーネントに相互に作用し得る。同期化を通して、ローカルデータベース及びサーバデータベースからの変更が、交換され得る。モバイルウェブクライアントについて、以下により詳細に描写する。
【００３９】
1つの実施例において、ウェブクライアントは、クライアントのマシンから標準ブラウザフォーマットで実行する。1つの実施例において、ウェブクライアントは、ウェブサーバを介してシステムサーバ255に接続し得る。1つの実施例において、システムサーバ255は、データベース290及びファイルシステム295からのビジネスロジック及びアクセスデータを実行するように設計及び構成されている。1つの実施例において、この中で描写されるウェブクライアントは、本発明の教示に従って設計及び構成されており、インタラクティブモードで動作する。1つの実施例において、この中で描写されるように、相互に作用するウェブクライアント構成は、ブラウザ側のJavaスクリプトで実現される、動的に作られるオブジェクトを利用しており、サーバ側のオブジェクトに対応している。1つの実施例において、ブラウザ側のこれらの動的に作られるオブジェクトは、最新の表示及びその対応するアプレットである、最新のビジネスオブジェクト及びその対応するビジネスコンポーネントなどを含んでいる。ウェブクライアントについて、以下により詳細に描写する。
【００４０】
1つの実施例において、ワイヤレスクライアントは、本質的には、ワイヤレス装置において可能であるシン・クライアントである。ワイヤレスクライアントは、ユーザインターフェースに基づいて、システムサーバで情報/データを通信及び交換するワイヤレスアプリケーションプロトコル（WAP）を利用できる。
【００４１】
図2に例証するシステム構成について、説明例のような様々な構造、データベース、テーブル、ファイルシステム等を参照して、以下に、より詳細に例証する。
【００４２】
図３は、アプリケーションが本発明の教示に従って確立され得る、マルチレイヤー構成の別の論理表現を例証するブロック図を示す。再度、図３に例証されるようなマルチレイヤー構成は、様々なアプリケーションをサポートするように設計及び構成される様々な共通サービスをプラットフォームに提供する。1つの実施例において、これらの様々なサービスは、アプレットマネージャ及びユーザインターフェース層310に対応するプレゼンテーションサービス論理層315、オブジェクトマネージャ（OM）層320及びデータマネージャ（DM）層330に対応するアプリケーションサービス論理層325、及びデータベース層340に対応するデータサービス論理層345を含んでいる。
【００４３】
1つの実施例において、プレゼンテーションサービス315は、様々なタイプのクライアントをサポートするように設計及び構成されており、それらにユーザインターフェースアプレット、表示、チャート、及びレポート等を提供する。上述したように、ワイヤレスクライアント、ハンドヘルドクライアント、ウェブクライアント、モバイルウェブクライアント、及び専用（接続された）クライアント等を含めて、非常に多様なクライアントがサポートされる。
【００４４】
1つの実施例において、アプリケーションサービス325は、ビジネスロジックサービス及びデータベースインタラクションサービスを含んでいる。1つの実施例において、ビジネスロジックサービスは、ビジネスオブジェクト及びビジネスコンポーネントのクラス及びビヘイビアを提供する。1つの実施例において、データベースインタラクションサービスは、ビジネスコンポーネントからのデータに対するユーザインターフェース（UI）リクエストを受け取り、リクエストを満足させるのに必要なデータベースコマンド（例えば、SQL照会等）を発生させる。例えば、データインタラクションサービスは、DBMSの特定SQLステートメントに対するリクエストデータを翻訳するのに用いられる。
【００４５】
1つの実施例において、データ記憶サービス345は、様々なアプリケーションの基礎として提供する下位データモデルにデータ記憶を提供するように設計及び構成されている。例えば、データモデルは、eファイナンス、e保険、eコミュニケーション、及びeヘルスケア等のような様々な垂直産業生成及びアプリケーションと同様である、コールセンター、販売、サービス、及びマーケティング等を含む様々なソフトウェア生成及びアプリケーションをサポートするように設計及び構成されている。
【００４６】
図４は、本発明の教示が実現されるアプリケーション構成の1つの実施例のブロック図を説明する。図４に示されるように、アプリケーション構成は、様々なタイプのサービス及び様々なタイプのツールの様々なロジックグルーピングを含んでおり、ビジネスニーズ及び環境に基づいた特定アプリケーションを設計及び構成するのに用いられ得る。
【００４７】
1つの実施例において、核となるサービスは、アプリケーションが実行する構成を提供するように設計及び構成されている。1つの実施例において、核となるサービスは、以下を含んでいる。
【００４８】
・中間層アプリケーションサーバである企業サーバ
・これらの部分の全てを共にリンクするネットワーク
・様々なアプリケーションと他の外部アプリケーションの間と同様に様々なアプリケーションの多数インストールの間でデータを共有することを許可するイベント管理及びデータ複製のような機能
・認証及びアクセス制御であるセキュリティ機能
【００４９】
1つの実施例において、アプリケーション統合サービスは、様々なアプリケーションがこの構成に従って確立され得るように設計及び構成され、外部の世界と通信する。1つの実施例において、この論理グルーピングの様々なタイプのサービスは、リアルタイム、ニアリアルタイム、外部アプリケーションを有するバッチ統合を提供するように設計及び構成されている。例えば、これらの統合サービスは、利用できる方法、技術、及びソフトウェア製品を用いて外部アプリケーションと内部アプリケーションの間での通信を可能にするために利用される。1つの実施例において、アプリケーション統合サービスにより、システム又はアプリケーションは、他の外部企業アプリケーションを有するデータを共有し複製することができる。従って、これらのサービスにより、特定のアプリケーション又はシステムは、情報をリクエストするクライアントとそれからリクエストされる情報を有するサーバの両方であり得る。
【００５０】
1つの実施例において、ビジネスプロセスサービスは、クライアントがアプリケーションを介してビジネスプロセスを自動化できるように設計及び構成されている。1つの実施例において、これらの様々なビジネスプロセスサービスは、以下を含んでいる。
【００５１】
・アサインマネージャを介したタスクの割当て
・ワークフローマネージャを介したビジネス実務の施行
・ビジネスサービスを介したカスタムビジネスロジックの再使用
・適正プロダクト構成の保証、及びプロダクトコンフィギュレータ及びプライシングコンフィギュレーターを介した評価
【００５２】
1つの実施例において、これらのビジネスプロセスの創造は、パーソナリゼーションデザイナー、ワークフローデザイナー、スマートスクリプトデザイナー、アサインメントアドミニストレーション表示、及びモデルビルダー等のような実行時間ツールを介して行われ得る。
【００５３】
1つの実施例において、統合サービスは、クライアントにユーザインターフェース及びシン・クライアントサポートを提供するように設計及び構成されている。1つの実施例において、これらは、ウェブベースのアプリケーションを確立し維持する可能性を含んでおり、高度なスマートスクリプト等と同様に、ユーザプロフィール管理、コラボレーションサービス、及びEメールとファックスサービスのようなウェブサポート機能を提供する。
【００５４】
1つの実施例において、設計時ツールは、カスタマイズして設計し、統合ポイントを提供し、アプリケーションを維持するサービスを提供するように設計及び構成されている。これらの様々なツールは、アプリケーションを定義するために1つの共通な場所を提供する。
【００５５】
1つの実施例において、管理サービスは、アプリケーション環境をモニターし、管理する1つの場所を提供するように設計及び構成されている。1つの実施例において、これらのサービスにより、ユーザは、グラフィックユーザインターフェース（GUI）又はコマンドライン等のいずれかを介してアプリケーションを管理することができる。
【００５６】
システム構成又はインフラストラクチャー
図５Ａは、本発明の1つの実施例に従う、インタラクティブウェブクライアント205及び図２のモバイルウェブクライアント210をサポートするための典型的なシステム構成又はインフラストラクチャー500を例証する。図５Ｂは、図５Ａに示した典型的なシステム構成又はインフラストラクチャー500の択一的な概観を例証する。
【００５７】
構成又はインフラストラクチャー500は、（図２に示した）インタラクティブウェブクライアント205及び（図２にも示した）モバイルウェブクライアント210をサポートしており、ウェブクライアント及びモバイルウェブクライアントの対話性及び性能を向上させて、共通する動作に対してページ再生数を低減させるような一定基準を満たし得る。
【００５８】
構成又はインフラストラクチャー500は、オブジェクトマネージャによって管理される、対応するオブジェクト504に良く似たブラウザ上に動的に作られるオブジェクト502を含み得る。1つの実施例において、オブジェクトマネージャ（OM）によって管理されるオブジェクト504は、オブジェクト指向パラダイムをサポートするC++のようなプログラミング言語を利用して確立され得る。
【００５９】
図５Ａ及び図５Ｂに示すように、OMによって管理される典型的なオブジェクト504は、CSSWEView506と表示しているオブジェクト506を含み得る。表示は、一般に、アプレットの特定の配置を構成するディスプレイパネルである。1つの実施例において、1つのアクティブな表示は、任意の所定時間に表示され得る。OMによって管理される別の典型的なオブジェクトは、CSSWEApplet508のアプレットを表すオブジェクト508であり得る。アプレットは、一般に、表示部分としてスクリーン上に現れるビジュアルアプリケーションユニットである。OMによって管理される他の典型的なオブジェクトは、ビジネスコンポーネント（CSSBusComp510）を表すオブジェクト510、ビジネスオブジェクト（CSSBusObj512）を表すオブジェクト512、フレーム（CSSWEFrame514）を表すオブジェクト514を含み得る。1つの実施例において、ビジネスオブジェクトは、アカウント、コンタクト、オポチュニティ、サービスリクエスト、ソリューション等のような様々なビジネスルール又はコンセプトの設定変更可能なソフトウェア表現として設計される。この実施例において、ビジネスコンポーネントは、典型的には、テーブルを重ねるレイヤーを提供し、それは下位テーブルよりもむしろアプレットリファレンスビジネスコンポーネントである。加えて、フレームは、一般に、表示のサブコンポーネントであり、1つ又は複数のアプレットから成る。
【００６０】
1つの実施例において、ブラウザ上のオブジェクト502は、Javaスクリプトを使って確立され得る。図５Ａ及び５Ｂに示すように、ブラウザ側の典型的なオブジェクト502は、ミラーCSSBusObj512、CSSBusComp510、CSSWEView506、及びCSSWEApplet508に対して、それぞれJSSBusObj516、JSSBusComp518、JSSView520、及びJSSApplet522を含んでおり、OMによって管理されるオブジェクト504である。
【００６１】
ブラウザ上のオブジェクト502及びOMによって管理されるオブジェクト504は、1つのコンピュータ計算装置又は多数のコンピュータ計算装置上に存在して動作するように構成され得る。図６Ａは、ブラウザ上のオブジェクト502及びOMによって管理されるオブジェクト504が、クライアント602及びサーバ604を含む多数のコンピュータ計算装置602、604上に存在して動作する典型的な構成600を例証する。図６Ｂは、ブラウザ上のオブジェクト502及びOMによって管理されるオブジェクト504が、1つのコンピュータ計算装置652上に存在して動作する典型的な構成650を例証する。
【００６２】
図５Ａ及び５Ｂに戻ると、ブラウザ上のオブジェクト502は、一般に、OMによって管理される、対応又は反映されているオブジェクト504と同期する。同期化は、遠隔手続き呼び出し（RPC）メカニズム528及び通知メカニズム530を介して成し遂げられ得る。RPCメカニズム528及び通知メカニズム530については、以下により詳細に描写する。
【００６３】
ブラウザのオブジェクト502について、JSSApplicationオブジェクト524は、典型的にはユーザセッションにわたり存在する。JSSApplicationオブジェクト524は、ユーザがアプリケーションをスタートする際に最初にロードされるべきである。アプリケーションは、一般に、ユーザがデスクトップのアイコンから又はスタートメニューからアプリケーションの一部を起動する際に開始される。JSSApplicationオブジェクト524は、一般に、CSSModelオブジェクト534と類似する役割を実現する。CSSModelオブジェクト534は、一般に、メモリ上の最新のビジネスオブジェクトインスタンス、最新ビジネスオブジェクトとそれに含まれるビジネスコンポーネントの間の関係、及びユーザのグローバルステート情報を利用するリポジトリオブジェクトに対するアクセスを提供するグローバルセッションオブジェクトである。CSSModelオブジェクト534は、一般に、リポジトリ532にアクセスし、必要とされる情報を得る。リポジトリ532は、一般に、１組のオブジェクト定義であり、1つのアプリケーション又はひと続きのアプリケーションを定義するのに用いられる。しかしながら、JSSApplicationオブジェクト524は、一般に、1つの表示、トラックされる表示に関連するアプレット、1つのビジネスオブジェクト、及び表示に利用するビジネスコンポーネントをトラックするために縮小される。
【００６４】
JSSApplicationオブジェクト524と異なり、JSSViewオブジェクト520、JSSAppletオブジェクト522、JSSBusObjオブジェクト516及びJSSBusCompオブジェクト518は、典型的には、一時的又は永続しないエンティティであって、一般には、ページ再生が起こる場合に置き換えられる。例えば、新しい表示をナビゲートするリクエストは、ブラウザ上で実行するために作られることになる新しい組のJSSView520、JSSApplet522、JSSBusObj516及びJSSBusComp518オブジェクトを生じさせる。
【００６５】
従って、ブラウザ上のオブジェクト502は、一般には、OMによって管理される反映される又は対応するオブジェクト504の軽量表現として描写され得る。ブラウザ上の各オブジェクト502は、典型的には、OMによって管理される対応するオブジェクト504に含まれる機能性の一部を含んでいる。例えば、JSSViewオブジェクト520は、CSSViewオブジェクト506に類似し、一般には、アプレットの収集を表す。JSSBusObjオブジェクト516は、CSSBusObjオブジェクト512に類似しており、一般には、アクティブなビジネスコンポーネント間の様々な一対多対応の関係を管理し、その結果、これらのアクティブなビジネスコンポーネントが照会を介して取り込まれる場合に正確な関係が使用される。JSSBusOBjオブジェクト516は、一般に、最新表示が終わるまでブラウザ上に存在し、対応するCSSBusObjオブジェクト512との同期を保持すべきである。
【００６６】
1つの実施例において、ブラウザは、ウェブエンジン526に対する新しい表示にナビゲートするためにリクエストを提出する場合、ウェブエンジン526は、データが全くない表示レイアウトを含むレスポンスを送信する。その後、ウェブエンジン526は、表示を取り込むためにデータの文字列を含むレスポンスを送信する。
【００６７】
JSSApplicationオブジェクト524は、一般には、ブラウザ上のオブジェクトへ及びから流れる通信を管理する。1つの実施例において、ブラウザのオブジェクトで起動される方法は、起動方法がOMによって管理されるオブジェクト504に再び向けられるべきである場合、典型的には、JSSApplicationオブジェクト524に誘導される。JSSApplicationオブジェクト524は、一般には、ウェブエンジン526からOMによって管理される適切なオブジェクト504に起動方法を経路指定するためにRPCメカニズム528を利用する。ウェブエンジン526は、典型的には、OMによって管理されるオブジェクト504からブラウザ上のオブジェクト502に戻り通知及びデータを送信するのに使用される。ウェブエンジン526は、一般には、JSSApplicationオブジェクト524からブラウザ上のオブジェクト502に通知及びデータを経路指定するために通知メカニズム530を利用する。
【００６８】
ブラウザオブジェクト502は、一般には、OMによって管理されるオブジェクト504における方法を起動するために遠隔手続き呼び出し528を利用する。これらの遠隔手続き呼び出し528は、一般には、HTTPリクエストとして実装される。OMによって管理されるオブジェクト504からのレスポンスは、通知及び関連ステータス情報とデータを含むHTTPレスポンスとして実装される。1つの実施例において、遠隔手続き呼び出しは、ブロッキング動作可能な状態でなされ、ブラウザ上のオブジェクト502とOMによって管理されるオブジェクト504の間の同期を保証する。ブロッキング動作可能である場合、典型的には、制御により、呼び出された遠隔手続きが実行終了するまで、呼び出しコードに対して逆向きに通過しない。
【００６９】
遠隔手続き呼び出し（RPC）
RPCモデルは、一般に、従来のプログラムと同様の手続き抽象化を利用するが、手続き呼び出しが、2つのコンピュータ間の境界に及ぶことを許可する。図７は、RPCパラダイムが、どのようにプログラム700を個別のコンピュータ計算装置702、704上で実行される部分に分割するのに用いられるかについての例を示す。この図は、一般には、多数の手続きを有する分散プログラムを示す。Main()706, proc_1()708, proc_2()710, proc_3()712, proc_5()714, proc_6()716, 及びproc_7()718は、第1のコンピュータ計算装置又はクライアント702に存在して動作し、proc_4()720, proc_8()722は、第2のコンピュータ計算装置又はサーバ704に存在し動作する。手続きnから手続きmへの実線は、nからmへの呼び出しを示す。破線726は、制御が、遠隔手続き呼び出し中に1つのコンピュータ計算装置から別のコンピュータ計算装置へどのように通過させるのかを示す。
【００７０】
図８は、遠隔手続き呼び出しで用いられる実行の典型的なモデル800を例証する。この図において、実線724は、一般には、コンピュータ計算装置内のフロー制御を示すのに用いられ、破線726は、一般には、制御が、遠隔手続き呼び出し中に1つのコンピュータ計算装置から別のコンピュータ計算装置にどのように通過させるかを示すのに用いられている。
【００７１】
上記のように、遠隔手続き呼び出しは、一般には、呼び出しコードから分離したアドレス空間に位置する手続きを実行する。RPCモデルは、一般には、ローカルな手続き呼び出しのプログラミングモデルから導出され、全ての手続きが手続き宣言を含むという事実を利用する。手続き宣言は、呼び出しコードと呼び出される手続きの間のインターフェースを定義する。手続き宣言は、呼び出しシンタックス及び手続きのパラメータを定義する。手続きに対する呼び出しは、典型的には、手続き宣言に従う。
【００７２】
遠隔手続き呼び出しを利用するアプリケーションは、ローカルアプリケーションに非常に類似した動作をする。しかしながら、RPCアプリケーションは、2つの部分：1つ又は複数の組の遠隔手続きを提供するサーバと、RPCサーバに対して遠隔手続き呼び出しをするクライアントに分割される。サーバ及びそのクライアントは、一般には、分離したシステムに存在し、ネットワークを介して通信する。RPCアプリケーションは、RPC実行時間ライブラリに依存し、それらに対するネットワーク通信を制御する。RPC実行時間ライブラリは、一般には、クライアントに対してサーバを見つけ、サーバを管理するような追加のタスクをサポートする。
【００７３】
分散アプリケーションは、一般には、中央処理装置（CPU）、データベース、装置、及びサービスのような分散コンピュータ計算リソースを利用する。以下のアプリケーションは、分散アプリケーションの例であって、
権限のあるユーザが他のユーザの個人のカレンダーにアクセスできる、カレンダー管理アプリケーションと、
CPUのデータを処理し、ワークステーションに結果を表示するグラフィックスアプリケーションと、
異なるコンピュータに位置する設計、在庫、スケジューリング、及び財務会計プログラムの間のアセンブリ構成要素についての情報を共有する製造アプリケーションと、を示す。
【００７４】
RPCソフトウェアは、一般には、
適切なサーバを認定するクライアントと、
異種の環境で動作させるためのデータ変換と、
ネットワーク通信と、を含んでいる分散アプリケーションの基本的な必要性を満たさなければならない。
【００７５】
分散アプリケーションは、通信を管理し、サーバを認定し、セキュリティを提供する等ようなタスクを含んでいる。独立型の分散アプリケーションは、全てのこれらのタスク自体を実現する必要がある。これらの分散コンピュータ計算タスクに対する適切なメカニズムなしに、分散アプリケーションを書き込むことは、難しく、高価であり、エラーを生じ易い。
【００７６】
RPCソフトウェアは、典型的には、呼び出されたRPCスタブ、及びアプリケーションに対する分散コンピュータ計算タスクを実現するタスクRPC実行時間ライブラリであるコードを提供する。RPCスタブ及びRPC実行時間ライブラリは、RPCアプリケーションを形成するクライアント及びサーバアプリケーションコードとリンクされるべきである。
【００７７】
表１は、一般には、分散アプリケーションのクライアント及びサーバに対する基本的なタスクを示す。手続きを呼び出すこと、及び遠隔手続きを実行することは、強調された文字で示され、（ローカルアプリケーションのような）アプリケーションコードによって実現されるが、それらは、ここでは、クライアント及びサーバアドレス空間に存在する。他のタスクはどうかといえば、幾つかは、スタブ及びRPC実行時間ライブラリによって自動的に実現され、一方で、他の幾つかは、アプリケーションコードのAPI呼び出しを介してRPC実行時間ライブラリによって実現される。
【００７８】
表１：RPCアプリケーションの基本的なタスク
2005505055.tif 000003
【００７９】
図９は、一般には、RPCの典型的なパーティション900について、アプリケーションコードセグメント904及び914、RPCインターフェース906及び916、クライアント及びサーバスタブ908及び918、及びRPCクライアント902及びRPCサーバ904におけるRPC実行時間ライブラリ910及び920を示す。
【００８０】
RPCクライアント902又はRPCサーバ912は、典型的には、RPCアプリケーションコードセグメント904及び914、RPCインターフェース906及び916、スタブ908及び918、及びRPC実行時間ライブラリ910及び920を含んでいる。RPCアプリケーションコードセグメント904、914は、一般には、アプリケーション開発者によって特定のRPCアプリケーションに対して書かれたコードである。RPCアプリケーションコードセグメント904、914は、一般には、遠隔手続きを実現し、呼び出し、また、RPC実行時間ライブラリにおいて必要とされるルーチン又は手続きを呼び出す。RPCスタブ908、918は、アーギュメントを通過させて受信するためにRPCインターフェース906、916を利用するインターフェース特定コードモジュールである。クライアント902及びサーバ912は、典型的には、各共有RPCインターフェース906、916に対して補足的なRPCスタブ906、916を含んでいる。RPC実行時間ライブラリ910、920は、一般には、RPCアプリケーションに対する通信を管理する。加えて、RPC実行時間ライブラリ910、920は、RPCアプリケーションが、RPCアプリケーションコードによって利用されるアプリケーションプログラミングインターフェース（API）をサポートし、それらの通信をセットアップし、サーバについて情報を操作し、遠隔にサーバを管理してセキュリティ情報にアクセスするようなオプションタスクを実現することができるようにする。
【００８１】
RPCアプリケーションコードセグメント904、914は、通常、クライアント及びサーバに対して異なる。サーバ912におけるRPCアプリケーションコード914は、典型的には、1つのRPCインターフェースを実現する遠隔手続きを含んでいる。対応するクライアント902におけるRPCアプリケーションコード904は、典型的には、それらの遠隔手続きに対する呼び出しを含んでいる。
【００８２】
RPCスタブ908、918は、一般には、遠隔手続き呼び出しに対する基本的なサポート機能を実現する。例えば、RPCスタブ908、918は、異なる形態のデータ表現を有するシステム間の送信のための入力及び出力アーギュメントを備えている。RPCスタブ908、918は、RPC実行時間ライブラリ910、920を利用して、クライアント902とサーバ904の間の送信を処理する。また、クライアント902におけるRPCスタブ908は、ローカルRPC実行時間ライブラリ910を利用して、クライアント902に対して適切なサーバを見つける。
【００８３】
図１０は、一般には、クライアントデータ構造とサーバデータ構造の間の典型的なマーシャリング及びアンマーシャリングを示す。クライアントRPCアプリケーションコードが遠隔手続きを呼び出す場合、クライアントスタブ908は、送信のために入力アーギュメント1002を準備すべきである。送信のためにアーギュメントを準備する処理は、“マーシャリング”として知られている。
【００８４】
マーシャリング1004は、一般には、入力又は呼び出しアーギュメント1002をバイトストリームフォーマットに変換し、送信のためにそれらを実装する。呼び出しアーギュメントを受信した場合、サーバRPCスタブ918は、それらをアンマーシャリングする（1014）。アンマーシャリング1014は、一般には、スタブが入力ネットワークデータを分解し、それをローカルシステムが認識するフォーマットを用いてアプリケーションデータに変換する。マーシャリング1004、1016及びアンマーシャリング1014、1006は、両方とも、各遠隔手続き呼び出しに対して2倍発生する。クライアントRPCスタブ908は、入力アーギュメント1002をマーシャリングし（1004）、出力アーギュメント1008をマーシャリングする（1006）。サーバRPCスタブ918は、入力アーギュメント1006をアンマーシャリングし（1014）、出力アーギュメント1008をマーシャリングする（1016）。マーシャリング及びアンマーシャリングは、クライアント及びサーバシステムが、同値のデータに対する異なるデータ表現を利用できるようにする。例えば、クライアントシステムは、ASCIIデータ1002、1008を利用でき、サーバシステムは、図１０に示すようなユニコードデータ1018を利用できる。
【００８５】
IDLコンパイラ（アプリケーション開発のためのツール）は、アプリケーション開発者によって記述されたRPCインターフェース定義をコンパイルすることによってスタブを発生させる。コンパイラは、プラットフォーム独立型IDLデータタイプに対するマーシャリング及びアンマーシャリングルーチンを発生させる。RPCアプリケーションに対するクライアントを確立するために、開発者は、クライアントアプリケーションコードをアプリケーションが利用する全てのRPCインターフェースのクライアントスタブとリンクさせる。サーバを確立するために、開発者は、サーバアプリケーションコードを対応するサーバスタブとリンクさせる。
【００８６】
1つ又は複数のRPCスタブに加えて、各RPCサーバ及びRPCクライアントは、RPC実行時間ライブラリのコピーとリンクされる。RPC実行時間ライブラリは、一般に、クライアントとサーバの間の通信を制御し、リクエストに関してクライアントに対してサーバを見つけるような実行時間オペレーションを提供する。クライアント及びサーバのRPCスタブは、典型的には、クライアント及びサーバに対してそれぞれローカルであるRPC実行時間ライブラリを介してアーギュメントを交換する。クライアントのRPC実行時間ライブラリは、典型的には、遠隔手続き呼び出しをサーバに送信する。サーバのRPC実行時間ライブラリは、一般には、遠隔手続き呼び出しをクライアントから受信し、各呼び出しをサーバの適切なRPCスタブにタスク指名する。RPC実行時間ライブラリは、その後、各呼び出しの結果をクライアントのRPC実行時間ライブラリに送信する。
【００８７】
また、サーバのRPCアプリケーションコードは、サーバがスタートアップ及びシャットダウンしている場合には、サーバにおけるRPC実行時間ライブラリのルーチンを呼び出すサーバ初期化コードを含んでいなければならない。また、クライアントのRPCアプリケーションコードは、初期化のために、RPC実行時間ライブラリルーチンを呼び出すことができる。また、さらに、サーバのRPCアプリケーションコード及びクライアントのRPCアプリケーションコードは、RPCスタブサポートルーチンに対する呼び出しを含み得る。RPCスタブサポートルーチンにより、一般には、アプリケーションはメモリの割当て及び開放をするようなプログラミングタスクを管理することができる。
【００８８】
図１１は、一般には、遠隔手続き呼び出し期間のRPCアプリケーションコードセグメント904及び914、RPCインターフェース906及び916、RPCスタブ908及び918、及びRPC実行時間ライブラリ910及び920の典型的な役割を示す。クライアントのアプリケーションコード又は呼び出しコード908は、遠隔手続き呼び出しを起動し、クライアントのRPCインターフェース906からクライアントスタブ908に入力アーギュメント1002を通過させる。クライアントスタブ908は、入力アーギュメント1002をマーシャリングし、呼び出しをクライアントのRPC実行時間ライブラリ910にタスク指名する。クライアントのRPC実行時間ライブラリ910は、入力アーギュメント1002をサーバのRPC実行時間ライブラリ920に送信し、呼び出された手続きのRPCインターフェース916のために、呼び出しをサーバスタブ918にタスク指名する。サーバのスタブ918は、入力アーギュメント1002をアンマーシャリングし、それらを呼び出された遠隔手続き914に通過させる。サーバのアプリケーションコード又は遠隔手続き914は、実行し、その後、任意の出力アーギュメント1008をサーバスタブ918に返す。サーバスタブ918は、出力アーギュメント1008をマーシャリングし、それらをサーバのRPC実行時間ライブラリ920に返す。サーバのRPC実行時間ライブラリ920は、出力アーギュメント1008をクライアントのRPC実行時間ライブラリ910に送信し、それらをクライアントスタブ901にタスク指名する。クライアントのスタブ908は、出力アーギュメント1008をアンマーシャリングし、それらを呼び出しコード904に返す。
【００８９】
1つの実施例において、遠隔手続き呼び出しは、ブロッキング動作可能な状態で、ブラウザのオブジェクト502と（図５Ａ及び５Ｂに示される）OMによって管理されるオブジェクト504の間の同期化を保証する。ブロッキング動作可能な状態で、制御は、典型的には、呼び出された遠隔手続きが実行を終えるまで、呼び出しコードに逆向きに通過しない。
【００９０】
図１２は、一般には、分散RPCアプリケーションを確立する典型的なプロセス1200の概略を記す。プロセスは、一般には、以下の基本タスク：
アプリケーションを設計し、どの手続きが必要とされるか、必要とされる手続きのどれが遠隔手続きであるかを決定し、遠隔手続きがRPCインターフェースにグループ化される方法を決定するタスク（ブロック1205）と、
ユニバーサルユニーク識別子（UUID）発生器を利用して、RPCインターフェースの各々に対するUUIDを発生させるタスク（ブロック1210）と、
インターフェース定義言語（IDL）を利用して、計画データタイプ及び遠隔手続きに対するRPCインターフェースを記述するタスク（ブロック1215）と、
IDLコンパイラを用いて前記IDL記述をコンパイルすることによってクライアント及びサーバスタブを発生させるタスク（ブロック1220）と、
RPCスタブに適合するプログラミング言語を利用してアプリケーションコードを書き込むか又は変更し、その結果、アプリケーションコードが前記スタブを処理するタスク（ブロック1225）と、
オブジェクトコードをアプリケーションコードから発生させるタスク（ブロック1230）と、
前記アプリケーションコードから発生させられたローカルRPC実行時間ライブラリ及びオブジェクトコードをリンクさせて、実行可能なコードを発生させるタスク（1235）と、を含んでいる。
【００９１】
図１３は、一般には、ローカルRPC実行時間ライブラリのリンク及びアプリケーションコードから発生するオブジェクトコードを例証する。クライアントに対しては、クライアントスタブ908、クライアントアプリケーションコード又は呼び出しコード904、及びクライアントのRPC実行時間ライブラリ910のオブジェクトコードが、リンカー1302を用いてリンクされ、クライアント実行可能コード1304を発生させる。サーバに対しては、サーバスタブ918、サーバの初期化コード1308、サーバのアプリケーションコード又は遠隔手続き914、及びサーバのRPC実行時間ライブラリ916に対するオブジェクトコードが、リンカー1302を用いてリンクされ、サーバ実行可能コード1306を発生させる。
【００９２】
従来、呼び出しコード及び呼び出される手続きは、同じアドレス空間を共有している。RPCアプリケーションにおいて、呼び出しコード及び呼び出される遠隔手続きは、リンクされず、むしろ、それらは、間接的に、RPCインターフェースを介して通信する。RPCインターフェースは、一般には、オペレーション、データタイプ、1組の遠隔手続きを短縮するのに供する定数のロジカルグルーピングである。RPCインターフェースは、典型的には、インターフェース定義言語（IDL）を用いてアプリケーション開発者によって書き込まれた正式なインターフェース定義からコンパイルされる。
【００９３】
分散アプリケーションを開発する際、インターフェース定義は、IDLで定義されるべきである。IDLコンパイラは、一般には、インターフェース定義を利用し、ヘッダファイル、クライアントスタブファイル、及びサーバスタブファイルを発生させる。IDLコンパイラは、標準プログラミング言語でヘッダファイルを生成し、ソースファイルとして又はオブジェクトファイルとしてスタブを発生し得る。幾つかのアプリケーションに対しては、インターフェース定義に付随する属性構成ファイル（ACF）が、定義される。ACFが存在する場合、IDLコンパイラは、それがインターフェース定義をコンパイルする時にACFを解釈する。ACFの情報は、コンパイラが発生するコードを変更するのに用いられる。
【００９４】
各RPCインターフェースのヘッダは、典型的には、ユニバーサルユニーク識別子（UUID）を含み、唯一の結果が出るようにエンティティを識別する16進数である。RPCインターフェースを識別するUUIDは、一般には、インターフェースUUIDとして知られている。インターフェースUUIDは、インターフェースが唯一の結果が出るように全ての可能性のあるネットワーク構成にわたって識別され得ることを保証する。インターフェースUUIDに加えて、各RPCインターフェースは、大小のバージョンナンバーを含んでいる。同時に、インターフェースUUID及びバージョンナンバーは、インターフェース識別子を形成し、時間の経過と共にシステムを横切るRPCインターフェースのインスタンスを識別する。
【００９５】
通知
図５Ａ及び５Ｂに振り返ると、ブラウザのオブジェクト502は、一般には、OMによって管理される、対応又は反映されているオブジェクト504と同期しており、変化が反映され得る。同期化は、遠隔手続き呼び出し（RPC）メカニズム528及び通知メカニズム530を介して実現され得る。
【００９６】
データ又はステータスがOMによって管理される対応するオブジェクト504（例えば、CSSBusComp 510）に変化する場合、通知メカニズム530は、一般には、ブラウザ上のオブジェクト502のデータ（例えば、JSSBusComp 518）が更新され得る手段を提供する。1つの実施例において、CSSSWEViewオブジェクト506は、1つ又は複数の通知を収集し、それらを表示サイクルの終端においてブラウザ上のオブジェクト502に送信する。
【００９７】
1つの実施例において、以下の典型的又は例示的通知が送信される。以下に列挙される通知の幾つかは、パラメータを必要とすることに注目すべきである。他の場合には、構成は、その最新状態を単純に認識することによってこれらの通知に対するコンテキストを理解し得る。
【００９８】
NotifyBeginNotifysは、1組の通知の開始を指示する。
【００９９】
NotifyEndNotifysは、1組の通知の終了を指示する。
【０１００】
NotifyStateChangedは、状態が変化していることを指示する。状態変化が生じる典型的なシナリオは、システムが照会状態に入る（ユーザが照会状態に入ることができる場合に照会を実行する）場合であり、その後、（ユーザがデータ値を更新できる場合に）引き渡し保留状態に入る。
【０１０１】
NotifyBeginQueryは、ビジネスコンポーネントが照会状態を受け入れる準備ができた状態にあることを指示する。
【０１０２】
NotifyExecuteは、ビジネスコンポーネントが実行される（すなわち、データベースの照会を実行し、それ自体を最新データと共に再度取り込む）ことを指示する。この通知は、照会明細を提供するオプションパラメータを含む。
【０１０３】
NotifyEndQueryは、照会が完了したことを指示する。
【０１０４】
NotifyDeleteRecordは、記録がデータベースから削除されたことを指示する。
【０１０５】
NotifyDeleteWorkSetは、記録がワーキングセットから取り除かれたことを指示する。通知は、取り除かれるのに必要とされるワーキングセット列のインデックスを提供するパラメータを含む。
【０１０６】
NotifyInsertWorkSetは、記録が最新のワーキングセットに追加されたことを指示する。この通知は、ワーキングセットの新しい記録のインデックスを提供するパラメータを含み得る。
【０１０７】
NotifyInsertWSFieldValsは、一定値がワーキングセットにおけるフィールドに追加されるのに必要であることを指示する。
【０１０８】
NotifyNewASctiveFieldは、新しいフィールドがアクティブであるか又は最新であることを指示する。
【０１０９】
NotifyNewActiveRowは、新しい列（すなわち記録）がアクティブであるか又は最新であることを指示する。
【０１１０】
NotifyNewDataは、データの変化があったことを指示する。
【０１１１】
NotifyNewDataWSは、ワーキングセットのデータの変化があったことを指示する。
【０１１２】
NotifyNewFieldDataは、特定のフィールドが新しいデータを有することを指示する。通知は、フィールド名を提供するパラメータを含む。
【０１１３】
NotifyNewFieldQuerySpecは、特定のフィールドが新しい照会又は探索明細を有することを指示する。
【０１１４】
NotifyNewPrimaryは、新しい記録が最初の記録になったことを指示する。
【０１１５】
NotifyNewRecordは、新しい記録が作成されたことを指示する。
【０１１６】
NotifyNewRecordDataは、新たに作成された記録が新しいデータを有することを指示する。
【０１１７】
NotifyNewRecordWSは、新たに作成された記録がワーキングセットに取り込まれる新しいデータを有することを指示する。
【０１１８】
NotifyNewSelectionは、記録の選定及び再選定を指示する。
【０１１９】
NotifyNewSellsは、多重記録の選定を指示する。
【０１２０】
NotifyPageRefreshは、UIが再生されるのに必要であることを指示する。この通知は、UIにおいて単純な更新データよりもむしろ一般に実質的な変化が必要とされる場合に、典型的には用いられる。この通知は、サーバトリップが新しいページを取り出し、それをブラウザに表示することを生じさせ得る。
【０１２１】
NotifyScrollDataは、記録が、スクロールアップ又はダウンされるのに必要であることを指示する。リストアプレットのような一定のユーザインターフェースオブジェクトは、この通知を利用して、異なる列を示すためにスクロールアップ及びダウンすることができる。
【０１２２】
NotifyChangeSelectionは、記録選定の変化があった（すなわち、最新列が選定又は再選定された）ことを指示する。
【０１２３】
NotifySelModeChangeは、選定モードの変化を指示する。1つの実施例において、（ｉ）ある時間における1つの記録の選定、及び（ii）同時に多重記録の選定（例えば、多重記録を1つのコマンドと共に削除すること）を含んでいる、選定の2つのモードが存在し得る。
【０１２４】
NotifyTotalsChangedは、合計値が変更される必要があることを指示する。多重記録が表示される幾つかの場合、幾つかのフィールドはまた、全ての記録における値の和を表示する。この通知は、合計値が変更されたことを指示する。
【０１２５】
NotifyLongOpProgressは、長い（すなわち時間消費）動作が進行していることを指示する。この通知は、ユーザインターフェースによって利用され、ユーザにフィードバックを提供し、タスクのほとんどがどのように容易に完了するかを示している進行又はステータスバーを示している。
【０１２６】
NotifyGeneric-これは、幾つかの特定状況のユーザインターフェースオブジェクトを通知するのに用いられる汎用通知であり、上記で列挙され描写された通知のセットによって保護されない。各タイプの汎用通知は、汎用通知に対する名称を提供するパラメータを含み、あるタイプの汎用通知は、別のタイプの汎用仕様と識別され得る。各タイプの汎用通知は、その特定パラメータを含み得る。
【０１２７】
一般の通信プロセス
上述したように、ブラウザ上のオブジェクト及びOMによって管理されるオブジェクトは、1つ又は多数のコンピュータ計算装置上に存在して動作するように構成され得る。上記で示したように、図６Ａは、典型的な構成600を例証しており、ブラウザ上のオブジェクト502及びOMによって管理されるオブジェクト504は、クライアント602及びサーバ604を含む多数のコンピュータ計算装置602及び604上に存在して動作する。図６Ｂは、典型的な構成650を例証しており、ブラウザ上のオブジェクト502及びOMによって管理されるオブジェクト504は、1つのコンピュータ計算装置652上に存在して動作する。
【０１２８】
図１４は、一般には、図６Ａに示す多数の装置構成600で動作している、ブラウザ側又はクライアント側のオブジェクト502とサーバ側オブジェクト504の間の通信の典型的プロセス1400を例証する。図１４の通信の典型的プロセス1400は、典型的には、ユーザ入力によって、ブラウザ側のアプレットJSSAppletで最初に処理される（ブロック1405）。ユーザがリンク又は他のユーザインターフェース機構においてクリックする場合、起動手段が発生する。JSSAppletは、典型的には、発生した起動手段を受信するための第1のオブジェクトである（ブロック1410）。JSSAppletは、その後、JSSApplicationを介して遠隔手続き呼び出しを発行し、サーバ側のアプレットCSSWEAppletに対する起動手段を再度ターゲットとする（ブロック1415）。ターゲットとなるサーバ側のアプレットCSSWEAppletは、一般には、ステータスフラグを設定することによって、ブラウザ側のアプレットJSSAppletからのRPC起動手段に応答し得る（ブロック1420）。1つの実施例において、ステータスフラグは、次の値の1つに設定され得る。
【０１２９】
Continue-この値は、一般には、サーバ側のアプレットCSSWEAppletが、起動手段の処理のその共有を実現したこと（又は実行する役割を有しないこと）、及びブラウザ上のJSSAppletが動作を完了するのに必要となることを指示する。通知は、応答において提供されるが、多くの場合は無意味である。
【０１３０】
Completed-この値は、一般には、サーバ側のアプレットが起動手段の処理を完了したこと、及びブラウザが応答で提供される通知に対する応答に対するもの以外にさらなる動作を実現する必要がないことを指示する。
【０１３１】
NewPage-この値は、一般には、起動リクエスト又は他のコマンドに対する応答が、ブラウザ側の全ての一時的なオブジェクトの再発生を含む、ブラウザのページ再生を必要とすることを指示する。URLは、ブラウザに送信され、新しいページが得られる。しかしながら、通知は存在しない。この値は、典型的には、異なる表示に対するドリルダウンが要求されるような場合に設定される。
【０１３２】
Error-この値は、一般には、起動手段リクエストが失敗したことを指示する。エラーステータスを受信する際には、JSSAppletは、典型的には、エラーページを表示する。
【０１３３】
ブラウザ側のアプレットであるJSSAppletがRPCを介してサーバを呼び出す場合、ブラウザ側のアプレットは、典型的には、応答のステータスフラグを見て、その後、それを処理する（ブロック1425）。戻りステータスがエラーである場合、ブラウザ側のアプレットは、エラーページを示している。戻りステータスが完了する場合、サーバは、一般には、それがもう既に起動手段を処理し、ブラウザに対して行うことが残されていないことを指示している。戻りステータスが存続している場合、サーバは、一般には、それが起動手段を処理していないことを指示している。ブラウザ側のアプレットは、一般には、手段を直接的にJSSBusCompオブジェクト上で起動することによって手段をJSSBusCompオブジェクトに再度誘導することにより、存続の戻りステータスに対して応答する。JSSBusCompオブジェクトは、起動手段リクエストを満足させることができ、JSSApplicationを介してその対応するサーバ側のビジネスコンポーネントにそのRPC呼び出しを送信しなければならない。
【０１３４】
図１５は、ブラウザ側のアプレットがJSSBusCompオブジェクトにおいて直接的に手段を起動する通信の典型的なプロセス1500を示す。図１５のプロセス1500は、プロセスが図６Ａに示した多数の装置構成において発生したかのように、以下に示されていることに注目すべきである。ブロック1505において、ブラウザ側のアプレットJSSAppletは、手段をJSSBusCompオブジェクトに再度誘導する。ブロック1510において、クライアント側のビジネスコンポーネントオブジェクトJSSBusCompが、JSSApplicationオブジェクトを介してサーバ側のビジネスコンポーネントCSSBusCompに遠隔手続き呼び出しを発行する。サーバ側のビジネスコンポーネントは、一般には、RPC手段呼び出しを処理し、ステータスを設定して返信し、また、適当な場合に1組の通知を戻す（ブロック1515）。1つの実施例において、ステータスフラグは、次の値を有する。
【０１３５】
Completed-この値は、一般には、サーバ側のビジネスコンポーネントCSSBusCompが、一般には、起動手段を首尾よく処理したことを指示する。通知は、典型的には生じる。
【０１３６】
Error-この値は、一般には、サーバ側のビジネスコンポーネントCSSBusCompが、首尾よく起動手段呼び出しを処理したことを指示する。エラーの戻りステータスを受信する際に、ブラウザは、典型的にはエラーページを表示する。
【０１３７】
ブロック1520において、クライアント側のビジネスコンポーネント（JSSBusComp）は、戻りステータスフラグを調査し、適切に応答する。起動手段呼び出しが、ブラウザとサーバのビジネスコンポーネントの間の同期を必要とする動作を実現する場合に、サーバは交信されることに注目すべきである。さらに、JSSBusCompオブジェクトが、サーバと交信することなしに、ローカルにリクエストを処理することができる状況があり得ることに注目すべきである。前記状況の例は、ユーザが次の記録動作を実現し、その後、任意データを変更することなしに事前の記録動作を実現する場合である。
【０１３８】
択一的なクライアント-サーバ実施例
以下の描写の幾つかの部分は、コンポーネントによって与えられ、システム又は装置のコンポーネント、コードのオブジェクト、コードの他の一部、プログラムの一部、又は全体のうちの他の部分であるように理解され、その部分の間の幾つかが独立した場合、集合的に機能することが期待される。
【０１３９】
図１６Ａは、ウェブアプリケーションの実施例を説明する。クライアント1610は、第1のマシン1605において動作する（実行される）。クライアント1610は、第1のマシン1605と第2のマシン1615の間のインターフェースを利用して、プラグイン1630に結合する。典型的には、第1のマシン1605と第2のマシン1615の間のインターフェースは、ワールドワイドウェブ、インターネット、又はマシンの接続に適当なネットワークの幾つかの他の形態である。ウェブサーバ1620は、第2のマシン1615において動作し、第1のマシンとのインターフェースからのリクエストを提供し、プラグイン1630は、クライアント1610からのリクエストを処理するのに適当であるウェブサーバ1620の一部である。プラグイン1630が、第1に又はもっぱらクライアント1610を有して利用するために設計され、ウェブサーバ1620を供給するように期待されたエンティティ以外のエンティティによって提供される特定のコンポーネントであることに注目すべきである。選択肢として、プラグイン1630は、クライアント1610からのリクエストを処理するのに適したウェブサーバ1620の一部であり得る。
【０１４０】
プラグイン1630は、クライアント1610からのリクエストを認識し、（例えば、別のワールドワイドウェブ又はインターネットインターフェースのような）第2のマシン1615と第3のマシン1645の間のインターフェースを介してそれらのリクエストをSWE1660に再度誘導する。前記再誘導は、問題のリクエストを形成しているメッセージを送るか、変換するか、又は別の方法で操作するデータを含み、又は、それは単純に、変更されていないSWE1660に対するリクエストを通すことを含んでいる。SWE1660は、データマネージャ1670と共にオブジェクトマネージャ1650の一部であり、その全ては、第3のマシン1645上で動作する。典型的には、クライアント1610からのリクエストは、SQLリポジトリ（データベース）1680におけるデータのアクセスを結果として生じ、第3のマシン1645によって受け入れ可能である。ウェブサーバ1620及びオブジェクトマネージャ1630は、同様の又は同一の論理関係を維持している一方で、2つの分離したマシンよりもむしろ、単一マシンで動作することに注目すべきである。
【０１４１】
図１６Ｂは、ウェブアプリケーションの択一的な実施例を説明する。第1のマシン1605は、第1のマシンは、独立型動作、又は第3のマシン1645に対する接続と関連した動作のどちらかに対して適しており、同様のマシンは、SQLリポジトリ1680に対するアクセスを許可する。クライアント1610は、オブジェクトマネージャ1650と共に第1のマシン1605上で動作する。プラグイン1630は、オブジェクトマネージャ1650のコンポーネント又は一部として統合され、介在ネットワーク接続を必要とすることなしに、図１６Ａで例証されるクライアント1610を有する同様のインターフェースを許可する。従って、図１６Ｂのプラグイン1630は、同様の又は実質的に同様のコード又は図１６Ａに例証した実施例に利用したような他の実装を利用する。
【０１４２】
プラグイン1630は、データマネージャ1670と相互に作用する、SWE1660に対するリクエストに関して通過させる。データマネージャ1670は、第3のマシン1645に対する接続が与えられるかどうかをよくある（潜在的に近く連続的な又は択一的に規則的な）基準で決定する。前記接続が与えられる場合、データマネージャ1670は、リクエストを処理する目的で第3のマシン1645におけるSQLデータベース1680にアクセスする。前記接続が与えられない場合、データマネージャ1670は、リクエストを処理する目的で第1のマシン1605におけるローカルSQLデータベース1675にアクセスする。
【０１４３】
1つの実施例において、ローカルSQLデータベース1675は、縮小するか又はデータベース1680のコピーを制限される。択一的な実施例において、ローカルデータベース1675は、データベース1680のコピーである。いずれかの実施例において、ローカルデータベース1675とデータベース1680の同期化は、様々な良く知られている手段を用いて処理される。例えば、データマネージャ1670は、1つの実施例において、データベース1675とデータベース1680の同期化を処理する。前記同期化は、リンクが第1のマシン1605と第3のマシン1645の間に与えられる場合にのみ必ず生じる。加えて、幾つかの実施例がデータベース1680とローカルデータベース1675の間に同一のスキーマを有する一方で、択一的な実施例は、データベース1680に対する第1のスキーマ及びデータベース1675に対する第2のスキーマを有する。
【０１４４】
図１７は、ウェブアプリケーションの別の択一的な実施例を説明する。クライアント1710及びローカルウェブサーバ1740の両方が、第1のマシンで動作する。ローカルウェブサーバ1740は、クライアント1710の表示ポイントから遠隔ウェブサーバをエミュレートするのに適したウェブエミュレーションコンポーネント1720を含んでいる。また、ローカルウェブサーバ1740は、クライアント1710からのリクエストを処理する際に利用されるデータにアクセスするのに適したサーバエミュレーションコンポーネント1730を含んでいる。前記データは、独立型の第1のマシンにおける（例えばキャッシュ又はディレクトリのような）ローカルデータ1750から利用できる。第1のマシンが第2のマシンに結合される場合、ネットワークデータ1775は、クライアント1710からのリクエストを処理するのに適したデータのアクセスのために利用できる。
【０１４５】
評価されるように、クライアント1710及びローカルサーバ1740は、同様の全コンポーネントの一部であるか、又は択一的な実施例における分離した又は互いに異なるコンポーネントである。さらに、サーバエミュレーションコンポーネント1730及びウェブエミュレーションコンポーネント1720は、幾つかの実施例においてローカルサーバコンポーネント1740を含むことを必要とすることなく、分離したコンポーネントとして実現される。望ましくは、クライアント1710は、特定のウェブアプリケーションにおける利用のために適した幾つかの専用化を有する、ユーザによる利用ためのウェブブラウザ又は類似するインターフェースである。しかしながら、クライアント1710は、ウェブベースのアプリケーションを提供するウェブブラウザのような様々なユーザインターフェースと共に利用するのに適したコンポーネントである。
【０１４６】
図１８は、データベースに対してウェブアプリケーションのリクエストを提供するプロセスの実施例を説明する。ブロック1810において、ウェブアプリケーションリクエストは、例えばクライアントから受信される。ブロック1820において、決定は、サービスエージェント又はコンポーネントとメインデータベースの間の最新の接続が与えられるかどうかに関してなされる。接続がされない場合、ブロック1830において、リクエストが、サービスエージェントによって受け入れ可能なローカルSQLデータベースにおいて与えられるデータに基づいて提供される（又はエラー出力する）。接続が与えられる場合、リクエストが、メインSQLデータベースにおいて与えられるデータに基づいてブロック1840において提供される（又はエラー出力する）。メインSQLデータベースは、信頼性を変化させる接続を有することはないネットワーク接続又は幾つかの他のインターフェースを介してサービスエージェントによって受け入れ可能であることに注目すべきである。さらに、サービスエージェントは、1つの実施例において、ウェブアプリケーションリクエストが生ずるクライアントと同様のマシン上で動作するローカルウェブサーバコンポーネント又はプロセスである。
【０１４７】
図１９は、ウェブアプリケーションにおけるサービスリクエストのプロセスの実施例を説明する。ブロック1910において、ウェブアプリケーションリクエストは、例えばクライアントから受信される。ブロック1920において、決定は、サービスエージェント又はコンポーネントとネットワークの間の最新の接続が与えられるかどうかに関してなされる。接続される場合、ブロック1940において、リクエストが、ネットワーク接続を介して受け入れ可能なデータに基づいて（可能な範囲で）提供される。接続されない場合、ブロック1930において、リクエストが、サービスエージェントによって受け入れ可能なデータのローカルキャッシュ又は他のソースで与えられるデータに基づいて（可能な範囲で）提供される。
【０１４８】
ネットワーク接続又は幾つかの他のインターフェースが信頼性を変化させる接続を有しないことに注目すべきである。さらに、接続の存在又は不存在の決定は、あらゆるリクエストに対してなされる必要はなく、その決定は、ネットワーク接続を介してリクエストを試みることに基づいてなされることに注目すべきであり、その後、結果、その欠乏、又は例えばタイムアウトのある形態を調査する。ウェブアプリケーションのサービスリクエストは、データの回復を含むか、既にローカルに与えらデータのローカル処理を含むか、又は遠隔データのローカル又は遠隔処理を含む。
【０１４９】
図２０は、データベースに対してウェブアプリケーションを動作させるプロセスの実施例を説明する。ブロック2010において、ウェブアプリケーションは、ローカルモードで動作し、ローカルデータベースを利用しているローカルウェブサーバを介してリクエストを提供する。ブロック2020において、メイン又は第1のデータベースに対するネットワーク接続が認識される。ブロック2030において、ローカルデータベースとメインデータベースの間の同期化が生じる。ブロック2040において、ウェブアプリケーションは、ネットワークモードにおいてメインデータベースのデータからのサービスリクエストを動作させる。ブロック2050において、ネットワーク接続の欠乏又はネットワーク接続における故障についての認識が生じる。ブロック2060において、ウェブアプリケーションは、ローカルモードのオペレーションに復帰する。
【０１５０】
ネットワークとの切断は、幾つかの例において適切な方法で処理され、同期化は切断より前に生じることに注目すべきである。さらに、同期は一切生じる必要はないことに注目すべきである。択一的に、メインデータベースとローカルデータベースの間の同期化は、ネットワークモードにおいて動作する一方で、裏プロセスとして実現される。同様に、ネットワークモードで動作中のメインデータベースにおけるデータの任意変化は、本質的には、ローカルデータベースにおいて同時になされるか、又はメインデータベースに対する前記変化をコミットすることが成功した指示が戻る際になされる。
【０１５１】
図２１は、データベースに対してウェブアプリケーションを動作させるプロセスの択一的な実施例を説明する。ブロック2110において、システムは起動し、システム自体を初期化し、その構成を決定するか又はパラメータを動作させる。ブロック2020において、ネットワーク接続が認識され、ネットワークとの通信が可能であることを指示する。ブロック2030において、ローカルデータベースとメインデータベースの間の同期化は、ネットワーク接続を介して生じる。ブロック2040において、ウェブアプリケーションは、ネットワークモードにおいて動作し、メインデータベースにおけるデータからのリクエストを提供する。ブロック2150において、システム動作は停止する。
【０１５２】
図２２は、データベースに対するウェブアプリケーションを動作させるプロセスの別の択一的な実施例を説明する。ブロック2210において、システムは起動し、システム自体を初期化し、その構成を決定するか又はパラメータを動作させる。ブロック2050において、ネットワーク接続の欠乏又はネットワーク接続における故障の認識がなされる。ブロック2060において、ウェブアプリケーションは、ローカルモードにおいて動作し、ローカルデータベースを利用しているローカルウェブサーバを介してリクエストを提供する。ブロック2270において、システム動作は停止する。
【０１５３】
図２３は、データベースに対してウェブアプリケーションにおけるリクエストを提供するプロセスの択一的な実施例を説明する。ブロック2300において、手段は、ステータスの初期化及び認識で始まる。ブロック2310において、決定は、ネットワーク接続の最新ステータスに関してなされる。ネットワーク接続されない場合、動作はブロック2320におけるネットワークなしに進行する。ブロック2320において、ウェブアプリケーションリクエストが受信される。ブロック2330において、ブロック2320において受信されたリクエストが、ローカルデータベースの利用するか又はローカルデータを用いて提供される。ブロック2340において、決定は、動作が終了するかどうかに関してなされる。終了しない場合、プロセスは、ブロック2320に戻り、次のリクエストを待つ。動作が終了すべき場合、ブロック2390において、動作が停止する。
【０１５４】
ネットワーク接続される場合、プロセスは、ブロック2310からブロック2350に進行する。ブロック2350において、ウェブアプリケーションリクエストが受信される。ブロック2360において、リクエストが、メインデータベースからのデータを用いるか又はネットワーク接続を介して利用できる他のデータを介して提供される。ブロック2370において、決定は、動作が終了するかどうかに関してなされる。終了しない場合、プロセスは、ブロック2350に戻り、別のリクエストを待つ。動作が終了する場合、プロセスは、ブロック2390に進行し、停止する。
【０１５５】
図２４は、ウェブアプリケーションにおいてリクエストを提供するプロセスの択一的な実施例を説明する。ブロック2410において、手段は、ステータスの初期化及び認識で始まる。ブロック2415において、決定は、ネットワーク接続の最新ステータスに関してなされる。接続される（又は動作可能な）場合、ブロック2020において、メイン又は第1のデータベースに対するネットワーク接続が認識される。ブロック2030において、ローカルデータベースとメインデータベースの間の同期化が生じる。ブロック2040において、ウェブアプリケーションは、ネットワークモードにおいて動作し、ネットワーク接続を介してメインデータベースにおけるデータからのリクエストを提供する。動作が完了する場合、ブロック2490において、プロセスが停止する。
【０１５６】
ネットワーク接続がされていないか又は動作可能でない場合、プロセスはブロック2050に進行する。ブロック2050において、ネットワーク接続の欠乏又はネットワーク接続における故障の認識がなされる。ブロック2060において、ウェブアプリケーションはローカルモードで動作し、ローカルデータベースを利用しているローカルウェブサーバを介してリクエストを提供する。最後に、動作が完了する場合、ブロック2490において、プロセスが停止する。
【０１５７】
上記詳細説明の幾つかの部分は、コンピュータメモリ内のデータビット動作のアルゴリズム及び抽象的表現に関して与えられている。これらのアルゴリズム説明及び表現は、データ処理技術における当業者によって利用されている手段であり、最も効果的にその動作の実体を他の当業者に伝えるものである。アルゴリズムは、ここでは、一般に、自己矛盾のない連続ステップであると理解され、所望の結果を導く。ステップは、それらの必要とされる物理量の物理的操作である。通常、必ずしも必要ではないが、これらの量は、記憶、転送、結合、比較、及び別の方法で操作することが可能な電気的又は磁気的信号の形態をとる。主として共通の使用という理由により、これらの信号をビット、値、構成要素、記号、特性、用語、数、又はその類似のものとして言及することは、時には便利であることを立証した。
【０１５８】
しかしながら、これらの全て及び類似する用語が、適切な物理量に関連することとなり、これらの量を適用した単に便利なラベルであることは、精神として伝えられるべきである。以下の議論から明らかなように別な方法で特別に述べられない限り、説明にわたり、“処理”又は“コンピュータ計算”又は“計算”又は“決定”又は“表示”又はその類似のもののような用語を利用する議論は、コンピュータシステムの動作及びプロセス、又は類似する電子コンピュータ計算装置について言及しており、コンピュータシステムのレジスタ及びメモリ内の物理（電子）量として表現されるデータを、コンピュータシステムのメモリ又はレジスタ又は他の類似する情報記憶、伝送、又は表示装置内の物理量として同様に表現される他のデータに操作及び変換させる。
【０１５９】
また、本発明は、この中で動作を実行するための装置に関する。この装置は、特に、必要な目的に対して構成されるか、又は、それはコンピュータ上で記憶されるコンピュータプログラムによって選択的に動作し、又は再構成される、一般の目的のコンピュータを備えている。前記コンピュータプログラムは、コンピュータ読み取り可能な記憶媒体に記憶されているが、例えば、フロッピー（登録商標）ディスク、光ディスク、CD-ROM、磁気光ディスク、リード-オンリーメモリ（ROM）、ランダムアクセスメモリ（RAM）、EPROM、EEPROM、磁気又は光カードを含む任意タイプのディスク、又は電子式命令を記憶するのに適した任意タイプの媒体に限定されておらず、各々はコンピュータシステムバスに接続されている。
【０１６０】
この中に与えられるアルゴリズム及び表示は、本質的に任意の特定のコンピュータ又は他の装置に関連するものではない。様々な一般目的のシステムは、この中の教示に従うプログラムと共に利用され、それは、必要な手段ステップを実現するより詳細な装置を構成するのに便利であることがわかる。様々なこれらのシステムに対して必要な構造は、描写から現れる。加えて、本発明は、任意の特定のプログラミング言語に関係して述べてはいない。様々なプログラミング言語がこの中で描写した発明の教示を実現するのに用いられる。
【０１６１】
図に示される、及び図に付随する文で説明される機能要素は、ソフトウェアコードセグメントを用いて実現され得る。前記機能要素がソフトウェアコードセグメントを利用して実現される場合、それは、さらに、これらのコードセグメントが、フロッピーディスク、ハードドライブ、CD-ROM、DVD、テープ、メモリ、又はコンピュータ計算マシンによってアクセス可能な任意の記憶装置のようなマシン読み取り可能な媒体に記憶され得ることが強調されるべきである。
【０１６２】
モバイルウェブクライアントに対する方法、システム、及び装置が提供される。1つの実施例において、発明は、ウェブアプリケーションを動作させる方法である。方法は、クライアントからのリクエストを受信することを含む。さらに、方法は、利用できるデータからのリクエストを提供することを含む。
【０１６３】
幾つかの実施例において、さらに、方法は、ウェブエミュレータとしてのウェブサーバに対するプラグインを用いることを含み、プラグインは、ウェブエンジンにリクエストを通し、ウェブエンジンは、データマネージャに関連してリクエストを提供する。幾つかの実施例において、さらに、方法は、ネットワークを介して利用できるデータに対するアクセスを試行するデータマネージャを含む。加えて、方法は、成功したアクセスにおいてネットワークから利用できるデータを利用し、リクエストを提供するのに失敗したアクセスにおいてローカルデータからの利用できるデータを利用するデータマネージャを含む。さらに、方法は、クライアントからネットワークにデータを送信するリクエストを含み、リクエストはネットワークからデータを受信する。
【０１６４】
択一的な実施例において、本発明は、データベースと共に利用するためのウェブアプリケーションを動作させる方法である。方法は、クライアントからのリクエストを受信すること、ウェブエミュレータを有するリクエストを処理すること、及びデータベースにおいて利用できるデータからのリクエストを提供することを含む。
【０１６５】
択一的な実施例において、利用できるデータは、メインデータベースにおいてネットワークを介して利用できるか、又はネットワークにアクセスすることなしにローカルデータベースにおいてローカルに利用できる。同様に、択一的な実施例において、さらに、方法は、ネットワークを介してメインデータベースにおいて利用できるデータに対するアクセスを試行することを含む。また、さらに、方法は、ネットワークを介して成功したアクセスにおいて、リクエストを提供することが、ネットワークを介してメインデータベースから利用できるデータを利用することを含む。また同様に、方法は、さらに、ネットワークを介して失敗したアクセスにおいて、リクエストを提供することが、ローカルデータベースにおいてローカルデータから利用できるデータを利用することを含む。
【０１６６】
前述の詳細説明において、本発明の方法及び装置は、特定の典型的な実施例を参照して描写されている。しかしながら、様々な変更及び変化が、本発明の広範な精神及び範囲から出発することなしにそれに対してなされることが明らかである。特に、様々なブロック図の分離したブロックは、方法又は装置の機能ブロックを表し、必ずしも物理的又は論理的分離、又は本発明の精神及び範囲に内在する動作命令を指示するものではない。例えば、図１７の様々なブロックコンポーネントに統合されるか、又はコンポーネントに再分割される。同様に、図１８のブロックは、（例えば）幾つかの実施例において、再命令されるか、又は、線形又は段階的様式におけるよりもむしろ並列に作り上げられる方法の一部を表す。従って、存在する明細書及び図面は、限定的というよりもむしろ例示的であるとみなされることになる。
【図面の簡単な説明】
【０１６７】
【図１】本発明の教示が実現されるマルチレイヤーシステム構成を示す。
【図２】本発明の教示が実現される1つの具体的なシステム配置のブロック図を示す。
【図３】アプリケーションが本発明の教示に従って確立され得る、別の論理表現のマルチレイヤー構成を例証するブロック図を示す。
【図４】本発明の教示が実現される１つの具体的なアプリケーション構想のブロック図を例証する。
【図５Ａ】図２の相互作用するウェブクライアント及びモバイルウェブクライアントをサポートする典型的構想又はインフラストラクチャー500を例証する。
【図５Ｂ】図５Ａに示した典型的構想又はインフラストラクチャーの択一的表示を例証する。
【図６Ａ】ブラウザのオブジェクト及びオブジェクトマネージャ（OM）によって管理されるオブジェクトが、クライアント及びサーバを含む多数の計算機上に存在し機能する典型的な配置を例証する。
【図６Ｂ】ブラウザのオブジェクト及びOMによって管理されるオブジェクトが、１つの計算機上に存在し機能する典型的な配置を例証する。
【図７】遠隔手続き呼び出し（RPC）の典型が、分離した計算機上で実行され得るプログラムの一部分を分割するのにどのように用いられるかについての例を説明する。
【図８】遠隔手続き呼び出しを利用した実行モデルのうちの典型的なモデルを例証する。
【図９】RPCクライアント及びRPCサーバにおけるRPCアプリケーションコードセグメント、RPCインターフェース、クライアント及びサーバ・スタブ、及びRPC実行時間ライブラリの典型的な分割を概して示す。
【図１０】クライアントデータ構造とサーバデータ構造の間の典型的なマーシャリング及びアンマーシャリングを概して示す。
【図１１】遠隔手続き呼び出し中のRPCアプリケーションコードセグメント、RPCインターフェース、RPCスタブ、及びRPC実行時間ライブラリの典型的な役割を概して示す。
【図１２】分散RPCアプリケーションを確立する典型的な処理1200を概説する。
【図１３】ローカルRPC実行時間ライブラリとアプリケーションコードから発生したオブジェクトコードのリンクを概して例証する。
【図１４】図６Ａに示した多数装置の配置で実行する、ブラウザ側又はクライアント側オブジェクトとサーバ側オブジェクトの間の典型的な通信処理を概して例証する。
【図１５】ブラウザ側アプレットが、JSSBusCompオブジェクトで方法を直接起動する典型的な通信処理を示す。
【図１６Ａ】ウェブアプリケーションの具体例を説明する。
【図１６Ｂ】ウェブアプリケーションの択一的に具体例を説明する。
【図１７】ウェブアプリケーションの別の択一的な具体例を説明する。
【図１８】データベースに対するウェブアプリケーションのサービスリクエスト処理の具体例を説明する。
【図１９】ウェブアプリケーションのサービスリクエスト処理の具体例を説明する。
【図２０】データベースに対するウェブアプリケーション動作処理の具体例を説明する。
【図２１】データベースに対するウェブアプリケーション動作処理の択一的な具体例を説明する。
【図２２】データベースに対するウェブアプリケーション動作処理の別の択一的な具体例を説明する。
【図２３】データベースに対するウェブアプリケーションのサービスリクエスト処理の択一的な具体例を説明する。
【図２４】ウェブアプリケーションのサービスリクエスト処理の択一的な具体例を説明する。
【図１】
2005505055.tif 000004
【図２】
2005505055.tif 000005
【図３】
2005505055.tif 000006
【図４】
2005505055.tif 000007
【図５Ａ】
2005505055.tif 000008
【図５Ｂ】
2005505055.tif 000009
【図６Ａ】
2005505055.tif 000010
【図６Ｂ】
2005505055.tif 000011
【図７】
2005505055.tif 000012
【図８】
2005505055.tif 000013
【図９】
2005505055.tif 000014
【図１０】
2005505055.tif 000015
【図１１】
2005505055.tif 000016
【図１２】
2005505055.tif 000017
【図１３】
2005505055.tif 000018
【図１４】
2005505055.tif 000019
【図１５】
2005505055.tif 000020
【図１６Ａ】
2005505055.tif 000021
【図１６Ｂ】
2005505055.tif 000022
【図１７】
2005505055.tif 000023
【図１８】
2005505055.tif 000024
【図１９】
2005505055.tif 000025
【図２０】
2005505055.tif 000026
【図２１】
2005505055.tif 000027
【図２２】
2005505055.tif 000028
【図２３】
2005505055.tif 000029
【図２４】
2005505055.tif 000030
【国際公開パンフレット】
2005505055.tif 000031
2005505055.tif 000032
2005505055.tif 000033
2005505055.tif 000034
2005505055.tif 000035
2005505055.tif 000036
2005505055.tif 000037
2005505055.tif 000038
2005505055.tif 000039
2005505055.tif 000040
2005505055.tif 000041
2005505055.tif 000042
2005505055.tif 000043
2005505055.tif 000044
2005505055.tif 000045
2005505055.tif 000046
2005505055.tif 000047
2005505055.tif 000048
2005505055.tif 000049
2005505055.tif 000050
2005505055.tif 000051
2005505055.tif 000052
2005505055.tif 000053
2005505055.tif 000054
2005505055.tif 000055
2005505055.tif 000056
2005505055.tif 000057
2005505055.tif 000058
2005505055.tif 000059
2005505055.tif 000060
2005505055.tif 000061
2005505055.tif 000062
2005505055.tif 000063
2005505055.tif 000064
2005505055.tif 000065
2005505055.tif 000066
2005505055.tif 000067
2005505055.tif 000068
2005505055.tif 000069
2005505055.tif 000070
2005505055.tif 000071
2005505055.tif 000072
2005505055.tif 000073
2005505055.tif 000074
2005505055.tif 000075
2005505055.tif 000076
2005505055.tif 000077
2005505055.tif 000078
2005505055.tif 000079
2005505055.tif 000080
2005505055.tif 000081
2005505055.tif 000082
2005505055.tif 000083
2005505055.tif 000084
2005505055.tif 000085
2005505055.tif 000086
2005505055.tif 000087
2005505055.tif 000088
2005505055.tif 000089
2005505055.tif 000090
2005505055.tif 000091
2005505055.tif 000092
2005505055.tif 000093
2005505055.tif 000094
2005505055.tif 000095
2005505055.tif 000096
2005505055.tif 000097
2005505055.tif 000098
2005505055.tif 000099
2005505055.tif 000100
2005505055.tif 000101
2005505055.tif 000102
【国際調査報告】
2005505055.tif 000103