JP2014211898A - ウィジェットフレームワーク、リアルタイムサービス統合およびリアルタイムリソース集約 - Google Patents

Abstract

【課題】アプリケーションサーバ上で実行するアプリケーションのコンポーネントによる、サービスに対する呼び出しを最適化する。【解決手段】第一の呼び出しは、アプリケーション１０４に含まれる複数のコンポーネントのうちの第一のコンポーネントによってサービスに対してなされ、第二の呼び出しは、複数のコンポーネントのうちの第二のコンポーネントによってサービスに対してなされる、ステップと、複数の最適化のうちの一つを選択するステップであって、複数の最適化は、第一の呼び出しおよび第二の呼び出しを、サービスに対する第三の呼び出しへと統合するステップを含む、ステップと、複数の最適化のうちの一つとして、第一の呼び出しおよび第二の呼び出しを第三の呼び出しへと統合するステップを選択するステップに応じて、第一の呼び出しおよび第二の呼び出しを第三の呼び出しへと統合するステップと、を含む。【選択図】図１Ｂ

Description

［関連する出願］
本ＰＣＴ出願は、２０１０年４月５日に申請された米国特許出願番号第１２／７５４，５６４号“WIDGET FRAMEWORK, REAL-TIME SERVICE ORCHESTRATION, AND REAL-TIME RESOURCE AGGREGATION”に対する、３５ Ｕ．Ｓ．Ｃ．§１２０もしくは§３６５（ｃ）のもとで主張される優先権を享受する利益を主張し、その出願は、２０１０年２月５日に申請された米国仮特許出願番号第６１／３０２，０８２号“WIDGET FRAMEWORK, REAL-TIME SERVICE ORCHESTRATION, AND REAL-TIME RESOURCE AGGREGATION”に対する優先権を享受する利益を主張し、これらの出願は本明細書にその全体を参照することによって組み込まれる。

本出願は、概して、サーバ性能を最適化する技術分野に関し、具体的な一実施例においては、アプリケーションサーバ上で実行するアプリケーションのコンポーネントによるサービスに対しての呼び出しの効率の最適化に関する。

世界的な市場において競争力を有するために、ユーザの広範かつ世界的なコミュニティを提供するネットワークベースの市場は、以下の目的を満たすことが有益であると見出す可能性がある。その目的とは、（１）急速に変化するユーザのニーズを満たすように、数多くのサーバ側アプリケーションを、迅速に開発し、改変し、テストし、または展開すること、ならびに（２）アプリケーションの展開がリソースおよび性能の制約に相反しないように、サーバ側アプリケーションを最適化すること、である。あるアプローチにおいては、ネットワークベースの市場は、各サーバ側アプリケーションを手動でコーディングするために、大人数の開発者グループを雇うことによってその目的を達成しうる。しかしながら、このようなアプローチは、種々の欠点を有しうる。その欠点とは、一貫性を欠く外観および操作感を有し、開発に長い時間のかかる、または、例えば、コードの再利用の観点から、他のアプローチを利用して生成されたアプリケーションよりも効率的ではないアプリケーションの生成を含む。別のアプローチにおいては、ネットワークベースの市場は、テンプレートに対して厳格に従うアプリケーションをコーディングするため、少人数の開発者グループを雇うことによってその目的を達成しうる。しかしながら、このようなアプローチもまた、種々の欠点を有しうる。その欠点とは、カスタマイズが困難であり、より多くのリソースを消費し、または、他のアプローチを利用して生成されたアプリケーションと比較してより低速な性能を有するアプリケーションの生成を含む。

したがって、ウィジェットを利用する多数のサーバ側アプリケーションを迅速に開発し、改変し、テストし、または展開することをサポートするフレームワークを利用する、各サーバ側アプリケーションを開発する必要性が存在しうる。ウィジェットとは、一つ以上のユーザインターフェイス（UI）を有し、ビジネスロジック（もしくはサービス）によって裏付けされるソフトウェアコンポーネントでありうる。すなわち、ウィジェットは、種々のデータソースもしくはサービスを組み込むように接続されるか、または構成されうる、一つ以上のビューおよび論理層を提示するように接続されるか、または構成されうる、提示層を有する可能性がある。ウィジェットは、提示層を論理層へと接続する接続モジュールもまた有しうる。

幾つかの実施形態は例示の目的のために図示されており、以下に添付される図面内の図に限定されるわけではない。
アプリケーションのコンポーネントとデータソースおよびリソースとの間の例示的な関係を示すブロック図である。 呼び出しオプティマイザとリソースアグリゲータが図１Ａのアプリケーションに組み込まれた後の、アプリケーションのコンポーネントとデータソースおよびリソースとの間の例示的な関係を示すブロック図である。 図１Ｂの呼び出しオプティマイザの、例示的な一実施形態のモジュールを示すブロック図である。 図１Ｂの呼び出しオプティマイザの、例示的な一実施形態のさらなるモジュールを示すブロック図である。 図１Ｂのリソースアグリゲータの、例示的な一実施形態のモジュールを示すブロック図である。 図１Ａおよび図１Ｂのウィジェット１の例示的なモジュールを示すブロック図である。 メタモデルフレームワークの例示的なアーキテクチャのブロック図である。 モデル定義のライフサイクルを管理する方法の例示的な一実施形態のフローチャートである。 アプリケーションのコンポーネント（例えば、ヘルプページ）を構成するためにAPIを生成する例示的な方法のフローチャートである。 図４Ｂのコンポーネントの構成の例示的なスキーマの図を示す。 図４のスキーマ図に対応する例示的なスキーマを示す。 図５の例示的なスキーマに対応する例示的な型（例えばクラス）を示す。 図６の例示的なスキーマもしくは図７の型に基づくコンポーネントを構成するための例示的なAPIを示す。 リソースフレームワークのアーキテクチャの例示的な一実施形態のブロック図である。 例示的なウィジェットフレームワークの構成要素と相互作用する二つのウィジェットのブロック図である。 アプリケーションの様々な各クライアントに関連しうる、アプリケーションの種々のバージョンを開発する開発者ツールの一実施例の間でのインタラクションのブロック図である。 シミュレーティングモジュールに関連する例示的なHTMLページ（例えば、demo.html）のソースコードリストである。 例示的なJavaテストクライアント（例えば、TestClient.java）のソースコードリストである。 ウェブブラウザにおける例示的なHTMLページおよびJavaテストクライアントの実行に関連するJavaコンソールログである。 アプリケーションサーバ上の例示的なHTMLページの展開をシミュレーションするシミュレーティングモジュールの例示的なユーザインターフェイスである。 アプリケーションのコンポーネントからサービスへの呼び出しを最適化する例示的な方法のフローチャートである。 アプリケーションのコンポーネントによって使用されるリソースを集約するための例示的な方法のフローチャートである。 アプリケーションの多数のバージョンを設計、編集、構成、テスト、もしくは展開するための例示的な方法である。 種々の例示的な実施形態が展開されうるクライアントサーバシステムを示すネットワーク図である。 例示的な一実施形態において、ネットワークシステムの一部として提供される、多数のアプリケーションを示すブロック図である。 例示的な一実施形態が実行されうるマシンのブロック図である。

以下の記述においては、例示の目的のために、本発明の主題の種々の実施形態の理解を提供するために、数多くの具体的な詳細が説明される。しかしながら、これらの具体的な詳細なくして、その実施形態を実践してもよいことは当業者にとって明らかである。さらには、既知の命令のインスタンス、プロトコル、構造および技術は詳細には記述されていない。本明細書で使用されるように、“or”という語は、包含的な意味で解釈されてもよいし、排他的な意味で解釈されてもよい。

“Bizmo”という語は、ユーザインターフェイス（UI）プレゼンテーション、入力もしくは構成を含むデータ／サービスアクセスを含みうるビジネスモジュールを含む。“アクション入力”という語は、アクションを起こすためのビジネスモジュールに対する入力パラメータを含む。“BizOp”もしくは“BizOperation”という語は、ビジネスモジュールが、外部のエンティティに対してデリゲートする可能性があるビジネスオペレーション（例えば、サービス呼び出し）を含む。BizOpは、ビジネスモジュールに対する方策として接続されてもよい。“BizMo View”という語は、ビジネスモジュールのUIを含む。“View Builder”という語は、ビジネスモジュールに対する方策として接続することができるUIビルダを含む。“BizMo Manager”という語は、ビジネスモジュールのライフサイクルを駆動するコントローラを含む。“BizOpEngine”という語は、ビジネスオペレーションを最適化し、実行するエンジンを含む。“BizMo”、“ウィジェット”、“ビジネスモジュール”という語は、交換して使用されてもよい。“ユーザ”という語は、人もしくはマシンを含む。アプリケーションのコンポーネントはウィジェットを含んでもよい。ウィジェットは、リアルタイムのリソース集約およびリアルタイムのサービス統合を含む、最適化をサポートしてもよい。リアルタイムのサービス統合は、多数のウィジェットによる同一のサービスに対する呼び出しを検出し、結合することを含む、ランタイム最適化をウィジェットがサポートすることを可能にしうる。リアルタイムのリソース集約は、ウィジェットが、実行時において、ウェブページ用の全リソースをウェブページ用の単一のリソースへと集約する（例えば、JavaScriptの全バージョンもしくはインスタンス、またはカスケーディングスタイルシート（CSS）を、ウェブページ用の単一のリソースへと集約する）ことを可能にしうる。フレームワークは、設計時もしくはリアルタイムのページの生成、改変もしくは削除を（例えば、コンポーネントのドラッグアンドドロップをサポートする開発者ツールを介して）サポートしうる。

例示的な一実施形態においては、アプリケーションサーバ上で実行するアプリケーションのコンポーネントによる、サービスに対する呼び出しを最適化するためのシステムが提供される。本システムはアプリケーションにおける呼び出しオプティマイザを含む。呼び出しオプティマイザは、第一の呼び出しおよび第二の呼び出しを遮断するための遮断モジュールと、第一の呼び出しおよび第二の呼び出しを第三の呼び出しへと統合するための統合モジュールと、を含む。第一の呼び出しは、サービスに対して、コンポーネントのうちの第一のコンポーネントによってなされ、第二の呼び出しは、サービスに対して、コンポーネントのうちの第二のコンポーネントによってなされる。

別の例示的な一実施形態においては、アプリケーションサーバ上で実行するアプリケーションのコンポーネントによる、サービスに対する呼び出しを最適化するためのシステムが提供される。本システムはアプリケーションに関連する呼び出しオプティマイザを含む。呼び出しオプティマイザは、第一の呼び出しおよび第二の呼び出しを遮断する遮断モジュールと、多数の最適化のうちの一つを選択する最適化選択モジュールであって、多数の最適化は、第一の呼び出しおよび第二の呼び出しを第三の呼び出しへの統合を含む、最適化選択モジュールと、多数の最適化のうちの一つとして、第一の呼び出しおよび第二の呼び出しを第三の呼び出しへと統合することを選択するのに応じて、第一の呼び出しおよび第二の呼び出しを第三の呼び出しへと統合する統合モジュールと、を含む。

別の例示的な一実施形態においては、アプリケーションサーバ上で実行するアプリケーションのコンポーネントによるサービスに対する呼び出しを最適化するための方法が提供される。本方法は、第一の呼び出しおよび第二の呼び出しを受信するステップであって、第一の呼び出しは、サービスに対してコンポーネントのうちの第一のコンポーネントによってなされ、第二の呼び出しは、サービスに対してコンポーネントのうちの第二のコンポーネントによってなされるステップと、多数の最適化のうちの一つを選択するステップであって、多数の最適化は、第一の呼び出しおよび第二の呼び出しを、サービスに対する第三の呼び出しへと統合するステップを含む、ステップと、多数の最適化のうちの一つとして、第一の呼び出しおよび第二の呼び出しを第三の呼び出しへと統合するステップを選択するステップに応じて、第一の呼び出しおよび第二の呼び出しを第三の呼び出しへと統合するステップと、を含む。

別の例示的な一実施形態においては、マシンの一つ以上のプロセッサによって実行されるとき、アプリケーションサーバ上で実行するアプリケーションのコンポーネントによるサービスに対する呼び出しを最適化するための方法をそのマシンに実施させる命令を含む、マシンで読み出し可能な記憶媒体が提供される。本方法は、第一の呼び出しおよび第二の呼び出しを受信するステップと、多数の最適化のうちの一つを選択するステップであって、多数の最適化は、第一の呼び出しおよび第二の呼び出しをサービスに対する第三の呼び出しへと統合するステップを含む、ステップと、多数の最適化のうちの一つとして、第一の呼び出しおよび第二の呼び出しを第三の呼び出しへと統合するステップを選択するステップに応じて、第一の呼び出しおよび第二の呼び出しを第三の呼び出しへと統合するステップと、を含む。

図１Ａは、アプリケーションのコンポーネントとデータソースおよびリソースとの間の例示的な関係１００を示すブロック図である。アプリケーションのコンポーネントは、ウィジェット１、１１２およびウィジェット２、１１４を含みうる。データソースは、データソース１、１３２、データソース２、１３６もしくはデータソース３、１４０を含みうる。リソースは、リソース１、１３４およびリソース２、１３８を含みうる。図１Ａは、データソース１、１３２、リソース１、１３４およびデータソース２、１３６との関係を有するものとして、ウィジェット１、１１２を示す。図１Ａは、データソース２、１３６、リソース２、１３８およびデータソース３、１４０との関係を有するものとして、ウィジェット２、１１４を示す。

ウィジェット１、１１２とデータソース１−１３２との間の関係は、ウィジェット１、１１２がデータソース１、１３２のサービスを呼び出すというものであってもよい。同様に、ウィジェット２、１１４とデータソース２、１３６との間の関係は、ウィジェット２、１１４がデータソース２、１３６のサービスを呼び出すというものであってもよい。ウィジェット１、１１２とリソース１、１３４との間の関係は、ウィジェット１、１１２が含まれうるアプリケーション１０２のうちの（図示されていない）別のコンポーネントが、リソース１、１３４を利用するというものであってもよい。例えば、ウィジェット１、１１２は、マークアップ言語（例えば、HTML，XHTML，XML，SVGもしくはXUL）で記述された文書内に含まれてもよいし、同様に、その文書はアプリケーション１０２に含まれてもよい。

リソース１、１３４は、スタイルシート言語（例えば、リソースはワールドワイドウェブコンソーシアム（W3C）によって定義されるCSSもしくは、JavaScriptスタイルシート（JSSS）であってもよい。）の文書の提示（例えば、外観およびフォーマット）を記述するリソースであってもよい。この場合においては、ウィジェット１、１１２はリソース１、１３４を使用して、文書の提示を決定する。リソース１、１３４は、JavaScriptリソース、HTMLリソース、ESFリソース、コンテンツリソース（例えば、テキスト、イメージなど）、プロトタイプリソース、ルールリソース、メタデータリソース、メタモデルリソース、もしくは別のタイプのリソースであってもよい。同様に、ウィジェット２、１１４とリソース２、１３８との間の関係は、ウィジェット２，１１４が含まれうるアプリケーション１０２の（図示されていない）別のコンポーネントが、リソース２、１３８を利用するというものであってもよい。

データリソースの各々は、ウェブサービスであってもよい。さらには、各データソースもしくはリソースは、ローカル（例えば、同一のサーバ、同一のシステム、もしくは同一のネットワーク上に）に配置されてもよいし、またはアプリケーション１０２に関して遠隔（リモート）（例えば、異なるサーバ、異なるシステムもしくは異なるネットワーク上に）に配置されてもよい。

図１Ｂは、呼び出しオプティマイザ１１６とリソースアグリゲータ１１８がアプリケーション１０４に関連付けられた後の、アプリケーション１０４のコンポーネントとデータソースおよびリソースとの間の例示的な関係１５０を示すブロック図である。本実施例においては、呼び出しオプティマイザ１１６のアプリケーション１０４に対する組み込みは、データソース２、１３６との関係を維持する上でのウィジェット２、１１４の必要性を排除する。さらには、リソースアグリゲータ１１８の組み込みは、リソース１、１３４との関係を維持する上でのウィジェット１、１１２の必要性、ならびに、リソース２、１３８との関係を維持する上でのウィジェット２、１１４の必要性を排除する。

さらには、リソースアグリゲータ１１８の組み込みは、結果として、リソース３、１４２の追加、ウィジェット１、１１２とリソース３、１４２との間の関係の構築、ウィジェット２とリソース３、１４２との間の関係の構築を引き起こす。リソース３、１４２は、アプリケーション１０４が使用するリソース１、１３４とリソース２、１３８の構成要素の集約を含む可能性がある。リソース３、１４２は、お互いに対して重複したリソース１、１３４もしくはリソース２、１３８の構成要素は含まなくてもよい。したがって、呼び出しオプティマイザ１１６のアプリケーション１０４への組み込みは、アプリケーション１０４が依存するサービス呼び出し回数を減少させ、リソースアグリゲータ１１８のアプリケーション１０４への組み込みは、アプリケーション１０４が依存するリソースの数を減少させる可能性がある。このサービス呼び出しの最適化およびリソースの集約は、アプリケーション１０４の効率もしくは性能を改善する可能性がある。

図２Ａは、図１Ｂの呼び出しオプティマイザ１１６の例示的な一実施形態のモジュールを示すブロック図である。呼び出しオプティマイザ１１６は、アプリケーション（例えば、アプリケーション１０２）のコンポーネント（例えば、ウィジェット１、１１２もしくはウィジェット２、１１４）からの呼び出し（例えば、第一の呼び出しおよび第二の呼び出し）を遮断するかまたは受信するための遮断モジュール２０２、または、呼び出しの統合を適用するための統合モジュール２０６を含みうる。

呼び出しの統合の適用は、第一の呼び出しの複数の要求パラメータを、第三の呼び出しの複数の要求パラメータへと統合するステップ、第二の呼び出しの複数の要求パラメータを、第三の呼び出しの複数の要求パラメータへと統合するステップ、第三の呼び出しを生成するステップ、第三の呼び出しの結果を受信するステップ、第一の呼び出しに対応する、結果のうちの第一部分を識別するステップ、第二の呼び出しに対応する、結果のうちの第二部分を識別するステップ、第一の呼び出しに対する応答として、複数のコンポーネントのうちの第一のコンポーネントへと結果の第一部分を提供するステップ、もしくは第二の呼び出しに対する応答として、複数のコンポーネントのうちの第二のコンポーネントへと結果の第二部分を提供するステップを含みうる。呼び出しを最適化する多数の技術のうちの他の技術は、図２Ｂに関連して以下に記述される。

図２Ｂは、図１Ｂの呼び出しオプティマイザ１１６の例示的な一実施形態のさらなるモジュールを示すブロック図である。呼び出しオプティマイザ１１６は、最適化選択モジュール２０４、バッチ処理モジュール２４２、キャッシングモジュール２４４もしくは実行モジュール２４６を含みうる。最適化選択モジュール２０４は、呼び出しを最適化する多数の技術から呼び出しを最適化する一技術を選択しうる。呼び出しを最適化する多数の技術は、キャッシュから第一の呼び出しもしくは第二の呼び出しに対する応答を提供するステップ、第一の呼び出しおよび第二の呼び出しを第三の呼び出しへと統合するステップ、バッチ呼び出しを生成するステップ、第一の呼び出しおよび第二の呼び出しをパラレルに実行するステップなどを含みうる。呼び出しを最適化する一技術の選択は、種々の基準に基づくものである。種々の基準は、多数の技術のうちの他の技術が呼び出しを処理するのにかかる時間に対する、ある技術が呼び出しを処理するためかかりうる時間、ある技術の可用性の同定もしくは、多数の技術のうちの他の技術の可用性の欠如、または、多数の技術のうちの他の技術に対する、ある技術の適合性の別の定量を含む。この場合においては、統合モジュール２０６は、一技術として、統合の選択に応じて、統合を適用してもよい。

バッチ処理モジュール２４２は、呼び出し最適化の一技術として、バッチ呼び出しの生成を選択するのに応じて、第一の呼び出しもしくは第二の呼び出しの代わりにバッチ呼び出しを生成しうる。バッチ呼び出しは、第一の呼び出しおよび第二の呼び出しが向けられたデータソースのサービスとして提供されてもよい。したがって、バッチ呼び出しの生成の選択は、データソースにおけるバッチ処理サービスの可用性に基づくものでありうる。さらには、バッチ呼び出しの生成の選択は、第一の呼び出しの応答として、バッチ呼び出しの結果の第一部分が使用可能であり、かつ、第二の呼び出しの応答として、バッチ呼び出しの結果の第二部分が使用可能であることの判断に基づくものでありうる。

キャッシングモジュール２４４は、呼び出し最適化のうちの一技術として、キャッシュから第一の呼び出しもしくは第二の呼び出しに対する応答の提供を選択するのに応じて、各々、第一の呼び出しもしくは第二の呼び出しの生成から受信される応答を提供する代わりに、メモリのキャッシュ内に含まれるデータを利用して、第一の呼び出しもしくは第二の呼び出しへの応答を提供しうる。メモリのキャッシュ内に含まれるデータは、サービスに対して第三の呼び出しを生成することから受信された応答であってもよい。さらには、一技術としての、第一の呼び出しもしくは第二の呼び出しへの応答をキャッシュから提供することの選択が、第三の呼び出しは、第一の呼び出しもしくは第二の呼び出しと実質的に同一であることの同定、また、そうでない場合には、第一の呼び出しもしくは第二の呼び出しの生成が、第三の呼び出しの生成と重複していることの同定に基づくものであってもよい。

実行モジュール２４６は、概して、呼び出しの実行を処理しうる。実行モジュール２４６は、一技術として第一の呼び出しおよび第二の呼び出しをパラレルに実行することを選択するのに応じて、第一の呼び出しおよび第二の呼び出しをパラレルに実行しうる。第一の呼び出しおよび第二の呼び出しのパラレルな実行の選択は、第一の呼び出しが第二の呼び出しに依存しないことの同定、または第二の呼び出しが第一の呼び出しに依存しないことの同定に基づくものでありうる。実行モジュール２４６は、アプリケーションの適切なコンポーネント（例えば、図１Ｂのウィジェット１、１１２）に対する呼び出しへの応答の転送を処理してもよい。実行モジュール２４６は、最適化の結果から呼び出しに対する応答のアセンブリを処理してもよい（例えば、バッチ呼び出しの生成、キャッシュからの第一の呼び出しもしくは第二の呼び出しの結果の提供、または、第一の呼び出しおよび第二の呼び出しの統合）。

簡略化のために、上述の議論は、第一の呼び出しおよび第二の呼び出しに関する単一の最適化技術の適用について言及している。しかしながら、呼び出しオプティマイザ１１６は、一つ以上のアプリケーションコンポーネントによって生成された一つ以上の呼び出しを遮断してもよいし、一つ以上の呼び出しに関する一つ以上の呼び出し最適化を選択してもよいし、一つ以上の呼び出しに対して一つ以上の呼び出し最適化を適用してもよい。例えば、呼び出しオプティマイザ１１６は、あらゆる数の呼び出しを処理してもよいし、あらゆる数の呼び出しに対して、あらゆる数の最適化技術を適用してもよい。さらには、呼び出しオプティマイザ１１６は、パラレルに動作を実施してもよいし、シリアルに動作を実施してもよい。さらに、呼び出しオプティマイザ１１６は、実行時に自動的に動作を実施してもよい。にもかかわらず、動作の性能の効果は、設計期間にアプリケーションの開発者によって、手動もしくはハンドコーディングで最適化されるように、アプリケーション（例えば、アプリケーション１０２）のコンポーネント（例えば、ウェブページ）を実施させることであってもよい。さらには、呼び出しオプティマイザ１１６は、一つ以上のアプリケーションコンポーネントのうちの一つからの一つ以上の呼び出しに対して、一つ以上の最適化を適用してもよい。言い換えると、呼び出しオプティマイザ１１６は、一つ以上のコンポーネントからの一つ以上の呼び出しに対して一つ以上の最適化を適用することに限定されることはない。

図２Ｃは、図１Ｂのリソースアグリゲータ１１８の例示的な一実施形態のモジュールを示すブロック図である。リソースアグリゲータ１１８は、識別モジュール２２２、集約モジュール２２４、もしくはアップデートモジュール２２６を含みうる。識別モジュール２２２は、アプリケーション（例えば、アプリケーション１０２）に関連する多数のリソースのうちの第一のリソースの少なくとも一部が多数のリソースのうちの第二のリソースの少なくとも一部と重複していることを識別しうる。例えば、識別モジュール２２２は、第一のリソースが第二のリソースのアップデートされたバージョンであることを識別してもよいし、アプリケーションが、第二のリソースの代わりに第一のリソースのうちの少なくとも一部を使用できることを識別してもよい。

集約モジュール２２４は、第一のリソースのうちの少なくとも一部が、第二のリソースのうちの少なくとも一部と重複していることを識別するのに応じて、第一のリソースおよび第二のリソースを第三のリソースへと集約しうる。第三のリソースは、アプリケーションの使用する第一のリソースの一部および第二のリソースの一部を含んでもよい。

アップデートモジュール２２６は、第三のリソースを使用するためにアプリケーションをアップデートしうる。アプリケーションのアップデートは、第一のリソースの重複部分もしくは第二のリソースの重複部分に対する、アプリケーションの依存を除去する可能性がある。例えば、アップデートモジュール２２６は、第二のリソースの重複部分の代わりに、第一のリソースの一部を第三のリソースが含むようにアプリケーションをアップデートしてもよい。したがって、アップデートモジュール２２６は、アプリケーションが依存するリソースの全体のサイズを減少させる可能性がある。さらには、アップデートモジュール２２６は、第三のリソースを表出化して、クライアントが、第一のリソースもしくは第二のリソースの代わりに第三のリソースをキャッシュしてもよい。例えば、クライアントは、第一の時刻におけるアプリケーションに対するアクセスに応じて、第三のリソースをダウンロードしてキャッシュしてもよい。その後、第二の時刻におけるアプリケーションに対するアクセスに応じて、クライアントが第三のリソースを再度ダウンロードする必要はない。リソースアグリゲータ１１８は、実行時に自動的にリソース集約を実施してもよい。にもかかわらず、リソース集約の効果は、設計時にアプリケーション開発者によって手動もしくはハンドコーディングで最適化されるように、アプリケーション（例えば、アプリケーション１０２）のコンポーネント（例えば、ウェブページ）を出力させることであってもよい。

図２Ｄは、図１Ａおよび図１Ｂのウィジェット１、１１２の例示的なモジュールを示すブロック図である。ウィジェット１、１１２は、アプリケーションのより複雑なコンポーネント（例えば、ウェブページ）のうちの基本的なコンポーネント（例えば、ヘッダユニット、検索ユニット、カテゴリナビゲーションユニット、認可もしくは認証ユニット、またはメンバーバッジユニット）である可能性がある。ウィジェット１、１１２は、提示モジュール２６２、論理実装モジュール２６４、接続モジュール２６６、もしくは構成モジュール２６８を含みうる。提示モジュール２６２は、ウィジェット１、１１２に関連する一つ以上のUIを提示しうる。例えば、ウィジェット１、１１２にアクセスするクライアントが、モバイルデバイスベースのウェブブラウザ（例えば、Apple Safariブラウザ）である場合には、提示モジュール２６２は、モバイルデバイスベースのウェブブラウザに対して適応されたUI（例えば、パーソナルコンピュータベースのウェブブラウザ用のUIよりも少ないテキストもしくは少ない画像を含むUI）を提示してもよい。ウィジェット１、１１２にアクセスするクライアントがパーソナルコンピュータベースのウェブブラウザ（例えば、Microsoft Windows Internet Explorer ブラウザ）である場合には、提示モジュール２６２は、パーソナルコンピュータベースのウェブブラウザに適応されたUI（例えば、モバイルデバイスベースのウェブブラウザ用のUIよりも多いテキストもしくは多い画像を含むUI）を提示してもよい。提示モジュール２６２は、ウィジェット１、１１２の論理の実装から、ウィジェット１、１１２のユーザインターフェイスの提示を分離してもよい。

論理実装モジュール２６４は、ウィジェット１、１１２の論理を実装しうる。論理の実装は、一つ以上のデータソース（例えば、データソース１、１３２もしくはデータソース２、１３６、ただし、両者は図１Ｂのものである）へのアクセスを含んでもよい。さらには、一つ以上のデータソースへのアクセスは、一つ以上のデータソースに関連する一つ以上のアプリケーションプログラミングインターフェイス（API）の呼び出しを含んでもよい。論理実装モジュール２６４は、ウィジェット１、１１２の論理の実装を、ウィジェット１、１１２のユーザインターフェイスの提示から分離してもよい。

接続モジュール２６６は、論理実装モジュール２６４へと提示モジュール２６２を接続し、提示モジュール２６２が、論理実装モジュール２６４から受信されたデータ（論理実装モジュール２６４が、一つ以上のデータソースへのアクセスを通して受信するデータを含む）の提示を一つ以上のUIへと統合することができるようにする。

構成モジュール２６８は、構成APIを通して、ウィジェット１、１１２の設定可能な属性を公開しうる。構成APIは、ウィジェット１、１１２に関連する構成データ（例えば、データスキーマ）に対するプログラムによるアクセスを与える可能性がある。構成APIは、ウィジェット１、１１２を手動で（例えば、XMLファイルに関連するXSDスキーマのハンドコーディングを通して）構成することを要求する代わりに、単純なユーザインターフェイス（例えば、ウィジェット１、１１２に構成APIを介してアクセスするツールのユーザインターフェイス）を介してウィジェット１、１１２を構成することを可能しうる。構成APIは、ウィジェット１、１１２に対して、テーマ（例えば、クリスマスもしくはハロウィンテーマ）を定義するかまたは適用する機能を含んでもよい。テーマの適用は、単一の動作でウィジェット１、１１２の構成可能な属性のうちの多数を改変することを含んでもよい。ウィジェット１、１１２が検索ウィジェットである場合には、構成APIは、ウィジェット１、１１２の構成可能な属性として、デフォルト検索文字列を公開してもよい。構成APIは、その後、呼び出されて、デフォルト検索文字列（例えば、“防水ブーツ”、“MP3プレイヤー”もしくは他の文字列）を設定されてもよい。構成APIは、ウィジェット１、１１２の地域化を定義するかまたは適用するための機能を含んでもよい。地域化の適用は、ウィジェット１、１１２にアクセスするユーザの地域性（言語、地域など）に基づいて、ウィジェット１、１１２に関連するテキストもしくは画像を結果として変更する可能性がある。例えば、ウィジェット１、１１２にドイツの（例えば、de-DE）地域化を適用することによって、ウィジェット１、１１２に関連するテキストをドイツ語にさせ、ウィジェット１、１１２にアメリカ合衆国で使用される英語（例えば、en-US）の地域化を適用することによって、ウィジェット１、１１２に関連するテキストを英語にさせる可能性がある。

構成モジュール２６８は、メタモデルのウィジェット１、１１２の関連付けを管理してもよい。例えば、構成モジュール２６８は、メタデータ定義フレームワーク（メタモデルフレームワーク、メタデータフレームワーク、もしくはメタモデル定義フレームワークとも呼ばれる）を使用してもよい。メタモデルフレームワークは、ウィジェット１、１１２の設定可能な属性を記述するために使用されうる型のような、モデル（もしくは型）の記述を管理するためのAPI（例えば、IDataDef API）を含んでもよい。メタモデル定義フレームワークは、（例えば、XMLスキーマに等価な）型の構造的もしくは機能的定義をサポートしてもよいし、単一型の継承もしくは多相性サポートを伴うオブジェクト指向であってもよいし、または、（例えば、JavaScriptと同様に）データ継承もしくは階層化を伴うプロトタイプ指向であってもよい。各々の基本的な型は、スーパータイプ（単一継承型）、制約（型不変節（例えば、列挙型））、アクション（あらゆる戻り値の型を有する方法をデリゲートする）、変換（他の型へと変換することができる方法（例えば、多相性をサポートする方法）をデリゲートする）、または、（例えば、データ継承もしくは階層化サポートを伴う）初期データもしくはデフォルトデータを含むメンバーを有する可能性がある。各々の複雑な型は、基本的な型のメンバーまたは、関連付け（役割、型もしくは多様性）もしくは属性（単純名もしくは値の組）を含む、さらに別のメンバーを含む可能性がある。役割とは、関連付けのインスタンスの名称でありうる。多様性は、単一の多様性（０，０．．１，１）リスト多様性（０．．ｎ，１．．ｎ）もしくは（キーとして文字列もしくは列挙型を有する）マップ多様性であってもよい。

メタデータフレームワークは、ドメイン固有言語（DSL）を使用する型の定義をサポートしてもよい。DSLは、モデル（もしくはデータ）定義（例えば、IDataDefインターフェイス）がモデル（もしくはデータ）インスタンス（例えば、IManagedData インターフェイス）と相関する、プロトタイプベースのアプローチを使用してもよい。IDataDefインターフェイスは、DSL定義階層の頂点に存在しうる。IDataDefインターフェイスは、構造的定義もしくはデータ階層を含む、定義のライフサイクルを管理してもよい。IDataDefインターフェイスは、型の階層、制約、動作、変換の定義を保持してもよい。DSL定義階層は、ある型から別の型へのオブジェクトの変換（例えば、Javaオブジェクトの文字列への変換もしくは文字列からJavaオブジェクトへの変換）を管理する、単一値ユニット定義インターフェイス（例えば、ISimpleValueUnitDef インターフェイス）を含んでもよい。DSL定義階層は、属性もしくは関連付けの定義を保持する、複雑データ定義インターフェイス（例えば、IComplexDataDefインターフェイス）を含んでもよい。複雑データ定義インターフェイスは、関連付けに対応する多数の語義を管理するための実装を含んでもよい。例えば、複雑データ定義インターフェイスは、コード生成プロセスもしくはインターフェイス様選択を通してクラスになる豆様構造（例えば、StructDataDefオブジェクト）、または、コード生成プロセスを介して、インターフェイスもしくは列挙型となる代替物（例えば、ChoiceDataDefオブジェクト）を含んでもよい。

図３は、メタモデルフレームワークの例示的なアーキテクチャ３００のブロック図である。メタモデルフレームワークは、ユーザ３０２を含みうる。ユーザ３０２は、モデルメタデータに対するフレームワークのメタデータモデリング３１０コンポーネントと相互作用（例えば、型定義を生成する、APIを生成するなど）してもよい。メタデータモデリング３１０コンポーネントは、モデルメタデータへとユーザインターフェイスを提供するメタデータツールもしくはアプリケーション３０６を含みうる。ツールは、メタデータもしくはドメインモデル３０８を生成してもよい。モデル化されたメタデータは、入力になってもよいし、メタデータシステム３２０に関連づけられてもよい。メタデータシステム３２０は、代理もしくは仲介層３１４を含んでもよい。代理もしくは仲介層３１４は、インタプリタ３１２、ジェネレータ３１６もしくはマッパ３１８を含みうる。インタプリタ３１２は、メタデータ定義にアクセスしてもよいし、または、型、ドメイン、もしくは範囲を検証してもよい。ジェネレータ３１６は、メタデータ定義に関連する具象クラスをマッピングしてもよいし、具象オブジェクトを構築するか、配線してもよい。マッパ３１８は、メタデータクラスを具象クラスへとマッピングしてもよい。メタデータモデリング３１０コンポーネントは、持続性層３２２と相互作用して、メタデータもしくはモデルを格納するか、またはメタデータもしくはモデルにアクセスする。持続性層３２２は、同様に、メタデータ定義レポジトリ３２４と相互作用して、メタデータ定義（例えば、型定義）、モデル、もしくは他のメタデータを格納する。メタデータシステム３２０は、持続性層３２２とも相互作用してもよい。持続性層３２２は、同様に、メタデータインスタンスレポジトリ３２６とも相互作用して、メタデータのインスタンス（例えば、型定義のインスタンス）を格納する。

メタモデルフレームワークは、クラスベースの継承パラダイムではなく、プロトタイプベースのパラダイムをサポートしてもよい。例えば、ヘッダ、コンテンツ、もしくはフッタを有する第一のウェブページは、より詳細なヘッダを有する第二のウェブページ用のプロトタイプでありうる。第二のウェブページは、同様に、さらに詳細なヘッダおよび左側のナビゲーションペインを有する第三のウェブページ用のプロトタイプでありうる。サブクラスのプロトタイプは、不変プロトタイプ（例えば、入力規則）、もしくは値制限（例えば、列挙された文字列、もしくは最小値もしくは最大値）などの制約を加える可能性がある。サブクラスのプロトタイプは、何も除去しない（が、多重性を０に変更する）可能性がある。サブクラスのプロトタイプは、新規の属性もしくは構造的な要素に加えるか、混合する可能性がある（例えば、混入は、名称の競合を回避するために名称空間サポートを加えてもよい）。サブクラスのプロトタイプは、動作の形式（例えば、モデルを読み出す、もしくは書き込むための任意のコード）、または変換（例えば、変換するためのコード、または、ある型から別の型への多形データ）の形式で行動に織り込んでもよい。

メタモデルフレームワークは、モデル（もしくはメタデータ）定義ライフサイクルをサポートしてもよい。すなわち、メタモデルは、（例えば、プロトタイプベースアプローチを使用して）構造定義およびデータ設定動作を結合するモデル定義をサポートしてもよい。データ設定は、構造定義に基づく型のオブジェクトのインスタンスに関連する値の設定を含んでもよい。このようなオブジェクトは、管理されたデータと呼ばれる可能性がある。図４Ａは、モデル定義のライフサイクルを管理する方法４００の例示的な一実施形態のフローチャートである。方法４００は、型を宣言する（例えば、型に対する言及を含む型定義を生成する）ステップ４０２、その型に基づくオブジェクトもしくは構造をインスタンス化する（例えば、型をインスタンス化する）ステップ４０４、もしくは構造内のデータを設定する（例えば、インスタンス化型に関連する値を設定する）ステップ４０６を含みうる。

図４Ｂは、アプリケーションのコンポーネント（例えば、ヘルプページ）を構成するためのAPIを生成する例示的な方法４５０のフローチャートである。方法４５０は、コンポーネントの設定可能な属性（例えば、設定可能な属性を表す、または、（例えば、統一モデリング言語（UML）もしくは（例えば、DSLを介した）スキーマを介した）スキーマ図を利用して設定可能な属性が如何にお互いに関連するか）を同定するステップ４５２、スキーマから型定義を作成もしくは生成するステップ４５４、スキーマもしくは型定義からコンポーネントを構成するためのAPIを作成もしくは生成するステップ４５６、（例えば、実行時に）コンポーネントがAPIを利用して構成できるように、コンポーネントとAPIを関連付けるステップ４５８、スキーマ図、スキーマ、型定義、APIもしくは（例えば、リソースフレームワークを利用する）他のメタデータを格納するステップ４６０を含みうる。コンポーネントの構成は、APIをユーザインターフェイスを介して公開する、か、または、ユーザがAPIにアクセスするのを可能にする（または、フロントエンドを提供する）開発ツールなどのクライアントを利用するステップを含みうる。

図５、図６、図７および図８は、アプリケーションのコンポーネントを構成するためにAPIを生成するための方法４５０（図４Ｂ）に関連するソースコードの例示的なスナップショットを提供する。図５は、コンポーネントの構成の例示的なスキーマ図５００を示す。図６は、図５のスキーマ図に対応する例示的なスキーマ６００を示す。図７は、図６の例示的なスキーマ６００に対応する例示的な型（例えば、クラス）７００を示す。図８は、例示的なスキーマ６００もしくは例示的な型７００に基づくコンポーネントを構成するための例示的なAPI８００を示す。

メタモデルフレームワークは、モデル定義ファクトリを含みうる。モデル定義ファクトリは、定義もしくはプロトタイプのインスタンスを得るために利用されてもよい。モデル定義ファクトリは、単一のファクトリをサポートしてもよいし、新規の型および適応した（例えば、レガシ）型に対する参照モデルをサポートしてもよい。モデル定義ファクトリは、（例えば、型定義を生成する４５４ため、もしくはAPIを生成する４５６ために）コードジェネレータによって利用されてもよい。モデル定義ファクトリは、ツール（例えば、エディタもしくはメタモデル駆動ツール）によって利用されてもよい。モデル定義ファクトリは、メタデータ定義ライフサイクルを管理してもよい。モデル定義ファクトリは、帰納的型もしくはデータ階層をサポートしてもよい。モデル定義ファクトリは、フレームワーク提供、コンテナ提供もしくはアプリケーション固有のメタデータ定義インジェクタをサポートしてもよい。フレームワーク提供、コンテナ提供、もしくはアプリケーション固有のメタデータ定義インジェクタは、コールバックメカニズムを介して実装されてもよい。

したがって、メタモデルフレームワークの例示的なアーキテクチャ３００は、Javaベースモデル定義を提供しうる。Javaベースモデル定義は、キー値コーディング（KVC）サポートを伴うタイプセーフプレーンオールドJavaオブジェクト（POJO）モデル生成と、XMLマーシャラもしくはアンマーシャラの生成、ツール用定義検索のためのランタイムJavaAPIの提供、文書化もしくはツール化目的のためのXSDもしくはXMI（UML）生成を可能にする。メタモデルフレームワークの利点は、定義およびデータ消費の双方に対する一貫したインターフェイス、異なるパーティもしくはレガシシステム間での定義の再利用、ツール化サポート（発見可能性、もしくは定義、もしくはツール化ヘルパ）、継承プロセスを介した混合型定義もしくは値設定を可能にするプロトタイプベース定義、多数の定義もしくはAOP定義インジェクタの混入を介した関係の分離、行動の織り込み（例えば、参照用トランスフォーマもしくはタイプセーフアクセサ）を介した関係の分離、または、（各リソースに格納されるべき）“互換性キー”の記述をサポートするための定義バージョン化、互換性のないバージョンを移行するためのバージョンコンバータの提供を含みうる。

図２Ｄの構成モジュール２６８は、ウィジェット１、１１２に関連するリソースの格納および検索を管理してもよい。例えば、構成モジュール２６８は、リソースフレームワークを利用して、リソースを格納および検索する。図９は、リソースフレームワークのアーキテクチャ９００の例示的な一実施形態のブロック図である。リソースフレームワークは、アプリケーション層９０２、型固有アクセス層９２２、レポジトリ層９４２、格納持続性インターフェイス９６２、または格納レポジトリもしくはシステムの種々の実装９８２を含みうる。アプリケーション層９０２は、アプリケーション（例えば、ePages９０４、サービスフレームワークランタイム９０６コンポーネント、サービスフレームワークランタイム９０８コンポーネントもしくはコンテンツレポジトリランタイム９１２コンポーネント）を、（例えば、アプリケーションレベルAPIを介して）実行時におけるリソースに対するアクセスとともに提供しうる。

型固有アクセス層９２２は、アプリケーション層９０２APIとレポジトリ層９４２APIとの間の翻訳に役立つ可能性がある。例えば、型固有アクセス層９２２は、種々のリソース型に関連するヘルパ（例えば、HTMLリソースアクセスヘルパ９２４、JavaScriptリソースアクセスヘルパ９２６、CSSリソースアクセスヘルパ９２８、プロトタイプリソースアクセスヘルパ９３０、コンテンツリソースアクセスヘルパ９３２など）を含みうる。

レポジトリ層９４２は、レポジトリレベルAPI（例えば、Iresourceレポジトリ９４４）を含み、メモリ（例えば、揮発性メモリ）におけるリソースの格納を管理する。レポジトリレベルAPIは、レガシリソース、シリアライザもしくはコンバータに対するアダプタの登録をサポートするリソースレポジトリ実装９４６に関連する可能性がある。この方法においては、レポジトリレベルAPIは多数のオーナーもしくはレガシシステム間で、同一の参照モデルを利用してサポートしてもよい。レポジトリレベルAPIは、レポジトリ構造の定義（例えば、リソースの論理キー）をサポートしてもよい。レポジトリレベルAPIは、種々のフォーマット間（例えば、揮発性メモリフォーマットと不揮発性メモリフォーマットの間、レガシシステムフォーマットと現行システムフォーマットとの間もしくは他のフォーマット間）でリソースの変換もしくはシリアル化をサポートしてもよい。レポジトリレベルAPIは、下層のリソースレポジトリのJavaベースタイプセーフラッパであってもよい。レポジトリレベルAPIは、リゾルバを含み、論理キーおよび物理キーの間のマッピングをサポートする。リゾルバは、リソースパターンを認識してもよい。例えば、リゾルバは、順列（例えば、サイトもしくはロケール）、バージョン化（例えば、“列”番号を解放する）、ライフサイクル状態（例えば、レビュー状態もしくは生産状態）、もしくは互換性管理をサポートしてもよい。レポジトリレベルAPIは、インフォセットベースの持続性をサポートして、迅速もしくは小型のバイナリXMLシリアル化；グラニュラーターゲット、オーバーライド、バインディングもしくは階層化属性のためのサポート；または、接続可能なシリアライザもしくはデシリアライザを活用する。接続可能なシリアライザもしくはデシリアライザは、メタモデルフレームワークには結合されえない。レポジトリレベルAPIは、リソース利用をトレースするトレーサをサポートしてもよい。レポジトリレベルAPIは、データ型（例えば、管理されたデータ）のインスタンスの管理をサポートしてもよい。レポジトリレベルAPI９４４は、一般的オブジェクトと同様にタイプセーフKVCオブジェクトに対してリソースを適用してもよい。レポジトリレベルAPIは、（例えば、ツールを介して）編集されるべきオブジェクトの定義（例えば、型宣言）を公開してもよい。

レポジトリ層９４２は、格納持続性インターフェイス９６２と関連付けられてもよい。格納持続性インターフェイス９６２は、持続性マネージャAPI（例えば、IResource持続性マネージャ９６４）を含み、下層にある持続性格納（例えば、不揮発性）実装９８２に対して共通のAPIを提供し、持続性格納実装９８２は、サービスとしてのストレージ（StaaS）ベース実装９８４、プロキシサービス実装９８６、ファイルシステムベース実装９８８、もしくはサービス指向アーキテクチャ（SOA）クライアントベース実装９９０を含みうる。Staasベース実装９８４は、ホットデプロイおよび迅速なロールアウトもしくはロールバック（例えば、データセンター複製）もしくはランタイムソースオブトゥルース（例えば、UGC）およびオーバーライドサポートをサポートしてもよい。プロキシサーバは、フェッチャもしくはローカルディスクキャッシュを（例えば、高性能にするために）含んでもよい。SOAクライアントベース実装９９０は、同様に、（図示されていない）一つ以上のSOAサービスもしくは（図示されていない）さらなるStaaSベース実装に基づくものであってもよい。リソースの格納および検索の管理は、実行時に実施されてもよい。

したがって、リソースフレームワークのアーキテクチャ９００の例示的な一実施形態は、リソースレポジトリを含み、リソースレポジトリは、リソースにアクセスするための均一なAPIを提供するが、型固有API、接続可能な持続性メカニズムを提供するリソース持続性サービス、もしくは、設計時間から実行時間へのアウトオブザボックスソリューションとしてのプロトタイプリソースレポジトリの付加を許可する。この方法においては、アーキテクチャ９００の例示的な実施形態は、最良の実践および特性をほとんどのリソースタイプへと拡張する可能性があり、また、維持、トラブルシューティング、もしくは、ほとんどの構成表出化の必要性に対して、イージーゴートゥーソリューションを提供するために容易、もしくは安価である可能性がある。

図１０は、例示的なウィジェットフレームワーク１０００の構成要素と相互作用する二つのウィジェットのブロック図である。二つのウィジェットのうちの第一のウィジェット、ウィジェット１、１０１２は、ステップＡ１、１００２、ステップＡ２、１００４もしくはステップＡ３、１００６を含みうる。ステップＡ１、１００２は、動作１（ＯＰ１）１００８、動作２（ＯＰ２）１０１０もしくはコールバック１０１２を含みうる。ステップＡ２、１００４は、動作３（ＯＰ３）１０１４およびコールバック（ＣＢ）１０１８を含みうる。ステップＡ３、１００６は、動作４（ＯＰ４）１０１６およびコールバック１０２０を含みうる。ＯＰ２、１０１０は第二のサービスに対する呼び出しを含みうる。ＯＰ１、１００８、ＯＰ２、１０１０、ＯＰ３、１０１４およびＯＰ４、１０１６は、各々、第一のサービス、第二のサービス、第三のサービスおよび第四のサービスに対する呼び出しを含みうる。コールバック１０１１は、ウィジェットマネージャ１０４０が第一の呼び出しもしくは第二の呼び出しの実行に応じて呼び出す機能でありうる。コールバック１０１８は、ウィジェットマネージャ１０４０が第三の呼び出しの実行に応じて呼び出すコールバック機能でありうる。コールバック１０２０は、ウィジェットマネージャ１０４０が、第四の呼び出しの実行に応じて呼び出す機能でありうる。二つのウィジェットのうちの第二のウィジェット、ウィジェット２−１０２４は、ステップＢ１、１０２２を含みうる。ステップＢ１は、動作５（ＯＰ５）１０２６、動作６（ＯＰ６）１０２８およびコールバック１０３０を含みうる。ＯＰ５、１０２６およびＯＰ６、１０２８は、各々、第五のサービスおよび第六のサービスに対する呼び出しを含みうる。

ウィジェットマネージャ１０４０は、ウィジェット１、１０１２およびウィジェット２、１０２４を管理し、ウィジェット１、１０１２およびウィジェット２、１０２４は、それらのライフサイクルもしくはランタイム動作を含む。ウィジェットマネージャ１０４０は、ウィジェット１、１０１２に対する参照１０４２もしくはウィジェット２、１０２４に対する参照１０４４を含みうる。さらには、ウィジェットマネージャ１０４０は、各ウィジェット内のステップに対する参照を含みうる。例えば、ウィジェットマネージャ１０４０は、ステップＡ１―１００２に対する参照１０４６もしくはステップＢ１、１０２２に対する参照１０５２を含みうる。ウィジェットマネージャ１０４０は、ウィジェットからサービスへの呼び出しを遮断し、かつ、ウィジェットエンジン１０６０への呼び出しを転送してもよい。

ウィジェットエンジン１０６０は、ウィジェットによる一つ以上の呼び出しの処理を取り扱ってもよい。例えば、ウィジェットエンジン１０６０は、（例えば、ウィジェット１、１０１２によるＯＰ１、１００８に対する呼び出し、もしくはウィジェット２、１０２４によるＯＰ５、１０２６に対する呼び出しのウィジェットマネージャ１０４０による遮断に応じて）ウィジェットマネージャ１０４０からのＯＰ１、１００８に対する参照１０６２もしくはＯＰ５、１０２６に対する参照１０６４を受信してもよい。ウィジェットエンジン１０６０は、オプティマイザ１０６６、エグゼキュータ１０６８もしくはキャッシュ１０７０を含みうる。オプティマイザ１０６６は、図２Ａおよび図２Ｂに関連して上述されたように、呼び出しを最適化しうる。エグゼキュータ１０６８は、図２Ｂに関連して上述されたように、一つ以上の呼び出しをシリアルにもしくはパラレルに実行しうる。キャッシュ１０７０は、図２Ｂに関連して上述されたように、ウィジェットエンジン１０６０が呼び出しの結果をキャッシュするメモリ（例えば、他のシステムメモリよりも高速の揮発性メモリ）であってもよい。ウィジェットエンジン１０６０は、（図示されていない）モジュールを含み、処理すべき呼び出しに関する情報を受信し、処理された呼び出しに関する情報（例えば、応答もしくは返答データ）を送信する。ウィジェットエンジン１０６０は、図２Ａおよび図２Ｂに関連して上述されたように、最適化された呼び出しの結果の処理に基づいて、一つ以上の呼び出しに対する応答を提供してもよい。

図１１は、アプリケーションの種々の各クライアント（例えば、モバイルウェブブラウザ１１５２、ウェブブラウザ１１５４、電子メールクライアント１１５６もしくは他のクライアント１１５８）に関連しうる、アプリケーション（例えば、図１Ｂのアプリケーション１０４）の種々のバージョン（例えば、バージョン１、１１６２、バージョン２、１１６４、バージョン３、１１６６もしくはバージョン４、１１６８）を開発するための例示的な開発者ツール１１２２の間のインタラクション１１００のブロック図である。開発者ツール１１２２は、アプリケーションサーバ１１１２に連通された開発者マシン１１０２上で実行しうる。アプリケーションの種々のバージョンは、アプリケーションサーバ１１１２上で実行しうる。モバイルウェブブラウザ１１５２は、モバイルデバイス１１０４上で実行し、ウェブブラウザ１１５４は、パーソナルコンピュータ１１０６上で実行し、電子メールクライアント１１５６は、ユーザマシン１１０８上で実行し、他のクライアント１１５８は、他のデバイス１１１０上で実行しうる。種々のクライアントは、アプリケーションサーバ１１１２に対して連通してもよい。

開発者ツール１１２２は、編集モジュール１１３２、シミュレーティングモジュール１１３６、もしくは展開モジュール１１３８を含みうる。編集モジュール１１３２は、編集用にコンポーネントの設定可能な属性（例えば、図２Ｄのウィジェット１、１１２）を公開することができる可能性がある。すなわち、編集モジュール１１３２は、（上述された）図２Ｄの構成モジュール２６８のインターフェイスとなることが可能であり、編集用に、設定可能な属性もしくは設定可能な属性に関連するメタデータ（例えば、メタデータ定義）を発見する。編集モジュール１１３２は、（例えば、展開モジュール１１３８を利用する迅速な展開を介して）実行時にコンポーネントを構成することが可能でありうる。

開発者ツール１１２２は、シミュレーティングモジュール１１３６を含み、シミュレーティングモジュール１１３６は、アプリケーションの展開を要求することなく、アプリケーション（もしくは、アプリケーションの特定のコンポーネント、もしくは、アプリケーションの特定のバージョン）のシミュレーションを可能にする。例えば、シミュレーティングモジュール１１３６は、アプリケーションがウェブブラウザで実行することを可能にするウェブブラウザ（例えば、Firefox）拡張であってもよい。JVMは、ウェブブラウザ拡張と同一のマシン上で実行する必要がない（例えば、対照的に、アプレットは、アプレットが実行しているマシン上でJVMを必要とする）ために、拡張は、Java仮想マシン（JVM）から分離されてもよい。アプリケーションは、ウェブページおよび制御ブラウザメニューと相互作用してもよい。シミュレーティングモジュール１１３６は、アプレットは利用しなくてもよい。シミュレーティングモジュール１１３６は、ブラウザメニューおよびウェブページタブに対する可視性を有しうる。シミュレーティングモジュール１１３６のセキュリティモデルは、アプレット（ファイル入力もしくは出力、クロスドメインなど）ほど拘束性がない。シミュレーティングモジュール１１３６は、よりインタラクテイブなウェブページアプリケーション用に設計されてもよい。シミュレーティングモジュール１１３６は、Javaベースの文書オブジェクトモデル（DOM）を有するウェブページの操作、JavaにおけるDOMイベントの処理（例えば、DOMイベントはJavaに到達する前に正規化されてもよい。したがって、イベント（もしくはイベントデータ）のブラウザ固有の動作は減少する可能性がある）、ブラウザ開始、終了、ページロードもしくはアンロードもしくはタブイベントの処理、ツールおよび右クリックメニューの変更、メニューからのイベント受信、ブラウザおよびシミュレーティングモジュール１１３６レベルにおけるデータの持続もしくはアクセス、任意のJavaScriptのウェブページへの送信、任意のJavaScriptの送信に関連する戻り値の受信、アプリケーションマネージャを有するアプリケーション（例えば、アプリケーションは、標準HTTP URLを介して配布されてもよい）の発見、インストールもしくは管理、または、簡便なUI特性のビルトインライブラリへのアクセスをサポートしてもよい。アプリケーションマネージャは、OSGiフレームワークを利用してもよいし、OSGi提供manifest.fmオプションに関連してもよい。したがって、アプリケーションは、.jabファイル（例えば、OSGi manifest.fmファイルを伴う.jarファイル、およびカスタムinstall.rdfファイル）であってもよい。Javaとシミュレーティングモジュール１１３６との間の通信は、プラットフォーム非依存メッセージング規格（例えば、DLC）でなされてもよい。開発者ツール１１２２が、アプリケーションサーバ１１１２の代わりに開発者マシン１１０２上で展開されたコンポーネント（例えば、アプリケーションサーバの構成要素）と通信しうるように、アプリケーションサーバ１１１２のコンポーネントは、開発者マシン１１０２上で展開されてもよいし、アプリケーションサーバ１１１２よりも、開発者マシン１１０２に対してより近傍に連通されたマシン上で展開されてもよい。したがって、シミュレーティングモジュール１１３６は、開発者ツール１１２２とアプリケーションサーバ１１１２との間のより低速な通信チャネルを介して通信することなく、アプリケーションの展開を近傍でシミュレートしうる。

図１２Ａは、シミュレーティングモジュール１１３６に関連する例示的なHTMLページ（例えば、demo.html）のソースコードリスト１２００である。図１２Ｂは、例示的なJavaテストクライアント（例えば、TestClient.java）のソースコードリスト１２２０である。図１２Ｃは、ウェブブラウザにおける例示的なHTMLページおよびJavaテストクライアントの実行に関連するJavaコンソールログ１２４０である。図１２Ｄは、アプリケーションサーバ上の例示的なHTMLページの展開をシミュレーションするシミュレーティングモジュール１１３６の例示的なユーザインターフェイス１２６０である。

図１３Ａは、アプリケーションのコンポーネントからサービスへの呼び出しを最適化する例示的な方法１３００のフローチャートである。方法１３００は、サービスへの第一の呼び出しおよびサービスへの第二の呼び出しを遮断するステップ１３０２、第一の呼び出しおよび第二の呼び出しを最適化する技術を選択するステップ１３０４、もしくは、第一の呼び出しおよび第二の呼び出しを最適化する選択された技術を適用するステップを含みうる。技術は、キャッシュから第一の呼び出しおよび第二の呼び出しへと応答を提供するステップ１３１０、第一の呼び出しおよび第二の呼び出しを第三の呼び出しへと統合するステップ１３１２、バッチ呼び出しを生成するステップ１３１４、第一の呼び出しおよび第二の呼び出しをパラレルに実行するステップ１３１６、もしくは別の技術を適用するステップ（例えば、議論された技術の組み合わせを適用するステップ）１３１８を含みうる。

図１３Ｂは、アプリケーションのコンポーネントによって利用されるリソースを集約するための例示的な方法１３５０のフローチャートである。本方法１３５０は、第一のウィジェットによる第一のリソースの利用が、第二のウィジェットによる第二のリソースの利用と重複していることを検出するステップ１３５２、第一のリソースおよび第二のリソースを集約する第三のリソースを生成するステップ１３５４、第三のリソースを利用するために第一のウィジェットおよび第二のウィジェットを構成するステップ１３５６、もしくは、クライアントが第三のリソースをキャッシュできるように、第三のリソースを表出化するステップ１３５８を含みうる。

図１４は、アプリケーションの多数のバージョンを設計、編集、構成、テストするか、または展開するための例示的な方法１４００である。方法１４００は、アプリケーションを受信するステップ１４０２、アプリケーションを生成するステップ１４０４、アプリケーションにウィジェットを発見するステップ１４０６、ウィジェットをアプリケーションに添加するステップ１４０８、ウィジェットを構成するステップ１４１０、アプリケーションの展開をシミュレーションするステップ１４１２、もしくは、アプリケーションの多数のバージョンを展開するステップ１４１４を含みうる。
[アーキテクチャ]

図１５は、種々の例示的な実施形態が展開される可能性がある、クライアントサーバシステム１５００を示すネットワーク図である。ネットワークシステム１５０２は、ネットワークベースの市場もしくは他の出版システムの例示的な形式において、一つ以上のクライアントに対して、ネットワーク１５０４（例えば、インターネットもしくはワイドエリアネットワーク（WAN））を介してサーバ側の機能を提供する。図１５は、例えば、ウェブクライアント１５０６（例えば、Microsoft Corporation of Redmondによって開発されたInternet Explorerブラウザなどのブラウザ）および其々のクライアントマシン１５１０および１５１２上で実行するプログラマティッククライアント１５０８を示す。

アプリケーションプログラムインターフェイス（API）サーバ１５１４およびウェブサーバ１５１６は、一つ以上のアプリケーションサーバ１５１８に結合され、一つ以上のアプリケーションサーバ１５１８に対して、其々、プログラマティックなウェブインターフェイスを提供する。アプリケーションサーバ１５１８は、一つ以上の市場アプリケーション１５２０および支払アプリケーション１５２２を提供する。アプリケーションサーバ１５１８は、同様に、一つ以上のデータベース１５２６に対するアクセスを容易にする一つ以上のデータベースサーバ１５２４に対して結合されるように示される。

市場アプリケーション１５２０は、ネットワークシステム１５０２にアクセスするユーザに対して、多数の市場機能およびサービスを提供しうる。支払アプリケーション１５２２は、同様に、ユーザに対して、多数の支払サービスおよび機能を提供しうる。支払アプリケーション１５２２は、ユーザが口座に値（例えば、米国ドルなどの市場通貨もしくは“ポイント”のような専用通貨）を蓄積することを可能にし、その後、市場アプリケーション１５２０を介して入手可能な製品（例えば、商品もしくはサービス）と、累積値を変換してもよい。市場アプリケーション１５２０および支払アプリケーション１５２２は、図１５においては、両者がネットワークシステム１５０２の一部を形成するように示されているが、別の実施形態においては、支払アプリケーション１５２２は、ネットワークシステム１５０２から分離された別個の支払サービスの一部を形成してもよいことを理解されたい。

さらには、図１５に示されるシステム１５００は、クライアントサーバアーキテクチャを使用しているが、本開示は、無論、このようなアーキテクチャに限定されることはなく、例えば、分散型、もしくはピアツーピアアーキテクチャシステムにも同様にアプリケーションを見出すことができる。種々の市場アプリケーション１５２０および支払アプリケーション１５２２は、スタンドアローンソフトウェアプログラムとしても実装することができ、スタンドアローンソフトウェアプログラムは、必ずしもネットワーク特性を有しない。

ウェブクライアント１５０６は、ウェブサーバ１５１６によってサポートされるウェブインターフェイスを介して、種々の市場アプリケーション１５２０および支払アプリケーション１５２２にアクセスする。同様に、プログラマティッククライアント１５０８は、APIサーバ１５１４によって提供されるプログラマティックインターフェイスを介して、市場アプリケーション１５２０および支払アプリケーション１５２２によって提供される種々のサービスおよび機能にアクセスする。プログラマティッククライアント１５０８は、例えば、販売者がオフラインでネットワークシステム１５０２上のリストを作成し管理することを可能にする、かつ、プログラマティッククライアント１５０８とネットワークシステム１５０２との間のバッチモード通信を実施するための、販売者アプリケーション（例えば、San Jose, CaliforniaのeBay Inc.によって開発されたTurboListerアプリケーション）であってもよい。

図１５は、APIサーバ１５１４によって提供されるプログラマティックインターフェイスを介して、ネットワークシステム１５０２に対するプログラマティックアクセスを有する、第三者サーバマシン１５３０上で実行する、第三者アプリケーション１５２８をも示す。例えば、第三者アプリケーション１５２８は、ネットワークシステム１５０２から検索された情報を利用して、第三者によって提供されるウェブサイト上の一つ以上の特性もしくは機能をサポートしてもよい。第三者ウェブサイトは、例えば、ネットワークシステム１５０２の関連するアプリケーションによってサポートされる一つ以上の、販売促進、市場もしくは支払い機能を提供してもよい。

図１６は、例示的な一実施形態において、ネットワークシステム１５０２の一部として提供される、多数のアプリケーション１５２０および１５２２を示すブロック図である。アプリケーション１５２０および１５２２は、サーバマシン間での通信を可能にするように連通した（図示されていない）専用の、もしくは共有されたサーバマシン上で提供されてもよい。アプリケーション１５２０および１５２２は、それ自体が（例えば、適切なインターフェイスを介して）お互いに、かつ種々のデータソースに対して連通し、アプリケーション１５２０および１５２２の間で情報を伝達することを可能にするか、または、アプリケーション１５２０および１５２２が共通のデータを共有して、アクセスするのを可能にする。アプリケーション１５２０および１５２２は、図１５のデータベースサーバ１５２４を介して、一つ以上のデータベース１５２６にさらにアクセスしてもよい。

ネットワークシステム１５０２（図１５）は、多数の発行、リスト化、および価格設定メカニズムを提供し、それによって、販売者は、販売用に商品もしくはサービスをリスト化（または、商品もしくはサービスに関する情報を発行）し、購入者は、そのような商品もしくはサービスを購入するために関心を示すか、または欲求を示すことが可能となり、価格は、商品もしくはサービスに関係する取引用に設定することができる。これを終了するために、図１６においては、市場アプリケーション１５２０および支払アプリケーション１５２２は、少なくとも一つの発行アプリケーション１６００および一つ以上のオークションアプリケーション１６０２を含むように示される。オークションアプリケーション１６０２は、オークション形式のリスト化および価格設定メカニズム（例えば、英語、オランダ語、Vickrey、中国語、ダブル、リバースオークション）をサポートする。種々のオークションアプリケーション１６０２は、このようなオークション形式のリスト化のサポートにおいて、それによって販売者がリストに関連する最低競売価格を明示する、最低競売価格特性、ならびに、それによって入札者が自動的な代理入札を実施する代理入札特性などの多数の特性を提供する可能性がある。

多数の定価アプリケーション１６０４は、定価リスト化形式（例えば、伝統的に分類された広告型リストもしくはカタログリスト）および買占め型リスト化をサポートする。具体的には、買占め型リスト化（例えば、San Jose, CaliforniaのeBay Inc.によって開発されたBuy-It-Now（BIN）技術を含む）は、オークション形式リスト化と合わせて提供され、オークションを介して売りに出されている商品もしくはサービスを、オークションの開始価格よりも典型的には高い定価で購入者が購入することを可能にしうる。

店舗アプリケーション１６０６は、販売者が“仮想”店舗内でのリストをグループ化することを可能にする。“仮想”店舗は、商標で示されてもよいし、さもなければ販売者によって販売者のために個人用にされてもよい。このような仮想店舗は、関連する販売者に対して特有かつ個人化された販売促進、奨励策および特性を提供してもよい。

評価アプリケーション１６０８は、ネットワークシステム１５０２を利用して取引するユーザが評価を創設し、構築し、維持することを可能にする。評価は、可能性のある取引相手に対して使用可能であり、その取引相手に対して発行される可能性がある。例えば、ネットワークシステム１５０２が個人対個人の取引をサポートしている場合を考えると、ユーザは、履歴を有しないか、または、それによって可能性のある取引相手の信頼性および信用が評価されうる他の参照情報を有してもよい。評価アプリケーション１６０８は、（例えば、他の取引相手によって提供されたフィードバックを介して）ユーザがネットワークシステム１５０２内の評価を時間外に創設することを可能にする。他の可能性のある取引相手は、その後、信用および信頼性を評価する目的でこのような評価を参照する可能性がある。

個人化アプリケーション１６１０は、ネットワークシステム１５０２のユーザが、ネットワークシステム１５０２を介する、彼らのインタラクションの種々の態様を個人化することを可能にする。例えば、ユーザは、適切な個人化アプリケーション１６１０を利用して、個人化された参照ページを生成し、その参照ページにおいて、ユーザが当事者である（もしくは当事者であった）取引に関する情報を閲覧してもよい。さらには、個人化アプリケーション１６１０は、ユーザがネットワークシステム１５０２および他の当事者を伴うインタラクションのリストおよび他の態様を個人化することを可能にしうる。

ネットワークシステム１５０２は、例えば、具体的な地理的地域に対してカスタマイズされた多数の市場をサポートしてもよい。ネットワークシステム１５０２のあるバージョンは、英国用にカスタマイズされ、別のバージョンのネットワークシステム１５０２は、米国用にカスタマイズされてもよい。これらのバージョンの各々は、独立した市場として動作してもよいし、または、共通する基礎を有する市場のカスタマイズされた（もしくは国際化された）提示であってもよい。ネットワークシステム１５０２は、したがって、既定の基準（例えば、地理的、人口統計学的もしくは市場基準）に従って、ネットワークシステム１５０２によって情報（および／もしくは情報の提示）をカスタマイズする、多数の国際化アプリケーション１６１２を含みうる。例えば、国際化アプリケーション１６１２は、ネットワークシステム１５０２によって操作され、かつ、其々のウェブサーバ１５１６（図１５）を介してアクセス可能な、多数の地域的ウェブサイト用の情報のカスタマイズをサポートするために利用されてもよい。

ネットワークシステム１５０２のナビゲーションは、一つ以上のナビゲーションアプリケーション１６１４によって容易にされてもよい。できるだけ視覚的な情報を与え、魅力的になるように、ネットワークシステム１５０２を介して使用可能なリストを作成するために、市場アプリケーション１５２０および支払アプリケーション１５２２は、ユーザがリスト内に含める画像をアップロードするために利用しうる、一つ以上のイメージングアプリケーション１６１６を含みうる。イメージングアプリケーション１６１６は、可能性のある購入者に対して提示される画像ギャラリーなどの、一つ以上の販売促進特性をサポートしてもよい。例えば、販売者は、販売促進された品目用に、画像ギャラリー内に含まれる画像を有するために、追加料金を支払う可能性がある。

リスト生成アプリケーション１６１８は、販売者が、ネットワークシステム１５０２を介して取引を望んでいる商品もしくはサービスに関連するリストを簡便に作成することを可能にし、リスト管理アプリケーション１６２０は、販売者がこのようなリストを管理するのを可能にする。特に、特定の販売者が多数のリストを作成する、ならびに／または、発行する場合には、このようなリストの管理は課題を有する。リスト管理アプリケーション１６２０は、多数の特性（例えば、自動再リスト化、在庫レベルモニタなど）を提供し、このようなリストを管理する上で販売者を援助する。一つ以上のリスト化後管理アプリケーション１６２２は、リスト化後に典型的に生じる多数のアクティビティで販売者を援助する。例えば、一つ以上のオークションアプリケーション１６０２によって容易にされたオークションの完了によって、販売者は、特定の購入者に関するフィードバックを残すことを望む可能性がある。これを終了させるために、リスト化後管理アプリケーション１６２２は、一つ以上の評価アプリケーション１６０８に対するインターフェイスを提供し、販売者が、評価アプリケーション１６０８に対して多数の購入者に関するフィードバックを簡便に提供することを可能にする。

紛争解決アプリケーション１６２４は、取引の当事者間に生じる紛争が解決されうるメカニズムを提供する。例えば、紛争解決アプリケーション１６２４は、誘導手順を提供して、それによって当事者は、紛争を解決するために多数の動作を経るように誘導される。紛争が誘導された手順を介しても解決できなかった場合には、その紛争は、第三者調停者もしくは仲裁人へと段階的に引き上げられてもよい。

多数の詐欺防止アプリケーション１６２６は、ネットワークシステム１５０２内で詐欺の発生を減少させるために、詐欺検出および防止メカニズムを実施する。

メッセージングアプリケーション１６２８は、ネットワークシステム１５０２のユーザに対して、メッセージの生成および伝達を担当する。これらのメッセージは、例えば、ネットワークシステム１５０２において、リストの状態に関してユーザに忠告しうる（例えば、オークション過程の間、入札者に対して“アウトビッド”通告を提供する、または、ユーザに対して販売促進および広告宣伝情報を提供する）。其々のメッセージングアプリケーション１６２８は、ユーザに対してメッセージを伝達するため、多数のメッセージ伝達ネットワークおよびプラットフォームのうちのいかなるものでも利用してよい。例えば、メッセージングアプリケーション１６２８は、電子メール（ｅメール）、インスタントメッセージ（IM）、ショートメッセージサービス（SMS）、テキスト、ファクシミリ、もしくは回線（例えばインターネット）を介した音声（例えば、Voice over IP（VoIP））メッセージ、従来型電話サービス（POTS）、もしくはワイヤレス（例えば、モバイル、携帯電話、WiFi、WiMAX）ネットワークを伝達してもよい。

広告宣伝アプリケーション１６３０は、販売者がネットワークシステム１５０２を介した販売を増加させることを可能にするため、販売者が使用可能である種々の広告宣伝機能をサポートする。広告宣伝アプリケーション１６３０は、販売者によって呼び出され、販売者によって使用された広告宣伝戦術の成功を監視かつ追跡しうる種々の広告宣伝特性をも動作させる。

ネットワークシステム１５０２それ自体、もしくはネットワークシステム１５０２を介して取引する一つ以上の当事者は、一つ以上のロイヤルティ／販売促進アプリケーション１６３２によってサポートされる、ロイヤルティプログラムを動作させてもよい。例えば、購入者は、特定の販売者と確立した、ならびに／または完結した各取引のために、ロイヤルティもしくは販売促進ポイントを受け取り、累積したロイヤルティポイントが交換できることによって報酬を提供されてもよい。
［モジュール、コンポーネントおよび論理］

論理もしくは多数のコンポーネント、モジュールもしくはメカニズムを含むものとして、ここではある実施形態が記述される。モジュールは、ソフトウェアモジュール（例えば、マシンで読み出し可能な記憶媒体上で、もしくは伝達信号において具現化されるコード）もしくはハードウェアモジュールのいずれかを構成しうる。 ハードウェアモジュールは、ある動作を実施することが可能な具体的ユニットであって、ある方法で構成されるか、または配置されてもよい。例示的な実施形態においては、一つ以上のコンピュータシステム（例えば、スタンドアローン、クライアントもしくはサーバコンピュータシステム）もしくは、コンピュータシステム（例えば、プロセッサもしくはプロセッサの集合）の一つ以上のハードウェアモジュールは、本明細書で記述されるようなある動作を実施するために動作するハードウェアモジュールとして、ソフトウェアモジュールによって構成されてもよい。

種々の実施形態においては、ハードウェアモジュールは、機械的もしくは電子的に実装されてもよい。例えば、ハードウェアモジュールは、ある動作を実施するために（例えば、フィールドプログラマブルゲートアレイ（FPGA）もしくは特定用途向け集積回路（ASIC）などの専用プロセッサとして）恒久的に構成される専用回路もしくは論理を含みうる。ハードウェアモジュールは、ある動作を実施するためにソフトウェアによって一時的に構成される、プログラマブル論理もしくは回路（例えば、汎用プロセッサもしくは他のプログラマブルプロセッサ内に包含されたものとして）を含んでもよい。恒久的に構成される専用回路、もしくは一時的に構成される（例えば、ソフトウェアによって構成される）回路として、ハードウェアモジュールを機械的に実装するための判断は、コストおよび時間を考慮してなされてもよいことを理解されたい。

したがって、“ハードウェアモジュール“という語は、具体的なエンティティを包含し、本明細書で記述されたある方法で動作する、および／もしくはある動作を実施するために、物理的に構成されるか、恒久的に構成される（例えば、ハードワイヤードされる）か、一時的に構成される（例えば、プログラムされる）エンティティであると理解されるべきである。ハードウェアモジュールが一時的に構成される（例えば、プログラムされる）実施形態を考えると、ハードウェアモジュールの各々は、時間内のあらゆるインスタンスにおいて、構成されるか、またはインスタンス形成される必要がない。例えば、ハードウェアモジュールがソフトウェアを利用して構成された汎用プロセッサを含む場合、汎用プロセッサは、異なる時間において、其々異なるハードウェアモジュールとして構成されてもよい。ソフトウェアは、したがって、プロセッサを構成し、期間のうちのあるインスタンスにおいては、特定のハードウェアモジュールを構成し、期間のうちの異なるインスタンスにおいては、異なるハードウェアモジュールを構成する。

ハードウェアモジュールは、他のハードウェアモジュールへと情報を提供でき、かつ、他のハードウェアモジュールから情報を受信できる。したがって、記述されるハードウェアモジュールは、連通しているものとみなされてもよい。このような多数のハードウェアモジュールが同期間に存在する場合、通信は、ハードウェアモジュールを接続する信号伝達を介して（例えば、適切な回路およびバスを介して）達成されうる。多数のハードウェアモジュールが異なる時間に構成されるかまたは、インスタンス形成される実施形態においては、このようなハードウェアモジュール間の通信は、例えば、多数のハードウェアモジュールがアクセスを有するメモリ構造における情報の格納および検索を介して達成されてもよい。例えば、あるハードウェアモジュールは、ある動作を実施して、連通されたメモリデバイスにその動作の出力を格納しうる。さらに別のハードウェアモジュールは、その後、もっと遅い時刻に、格納された出力を検索して処理するためにメモリデバイスにアクセスしてもよい。ハードウェアモジュールは、入力もしくは出力デバイスとの通信を開始してもよいし、リソース（例えば、情報の集合）上で動作できる。

本明細書で記述される例示的な方法の種々の動作は、関連動作を実施するために、一時的に構成される（例えばソフトウェアによって）か、または恒久的に構成される一つ以上のプロセッサによって、少なくとも部分的に実施されてもよい。一時的に構成されようが、または恒久的に構成されようが、このようなプロセッサは、一つ以上の動作もしくは機能を実施するために動作する、プロセッサ実装されたモジュールを構成してもよい。本明細書で言及されるモジュールは、例示的な幾つかの実施形態においては、プロセッサ実装されたモジュールを含みうる。

同様に、本明細書で記述される方法は、少なくても部分的にプロセッサ実装されてもよい。例えば、方法の動作のうち少なくとも幾つかは、一つ以上のプロセッサもしくはプロセッサ実装されたモジュールによって実施されてもよい。ある動作の性能は、一つ以上のプロセッサ間で分散され、単一のマシン内に存在するだけではなく、多数のマシンに配置されてもよい。例示的な幾つかの実施形態においては、プロセッサもしくは複数のプロセッサは、単一の位置（例えば、家庭環境、オフィス環境もしくはサーバーファームとして）に配置されてもよいし、他の実施形態においては、プロセッサは、多数の位置に分散されてもよい。

一つ以上のプロセッサは、“クラウドコンピューティング”環境もしくは“サービスとしてのソフトウェア”（SaaS）として、関連する動作の性能をサポートするように動作してもよい。例えば、少なくとも幾つかの動作は、コンピュータのグループ（プロセッサを含むマシンの実施例として）によって実施されてもよく、これらの動作は、ネットワーク（例えば、インターネット）を介して、ならびに、一つ以上の適切なインターフェイス（例えば、API）を介してアクセスすることが可能である。
［電子装置およびシステム］

例示的な実施形態は、デジタル電子回路もしくはコンピュータハードウェア、ファームウェア、ソフトウェア、もしくはそれらの組み合わせとして実装されてもよい。例示的な実施形態は、データ処理装置（例えば、プログラマブルプロセッサ、コンピュータもしくは多数のコンピュータ）による実行のため、またはその動作の制御のために、例えば、マシンで読み出し可能な記憶媒体内のコンピュータプログラムプロダクト（例えば、情報キャリア内で具体的に具現化されたコンピュータプログラム）を利用して実装されてもよい。

コンピュータプログラムは、コンパイルされたか、もしくは翻訳された言語を含む、プログラミング言語のうちのあらゆる形式で記述することが可能であり、スタンドアローンプログラムもしくはモジュール、サブルーチン、もしくはコンピューティング環境における利用に適切な他のユニットを含むあらゆる形式で展開することができる。コンピュータプログラムは、一つのコンピュータもしくは多数のコンピュータ上で展開し、実行することができる。多数のコンピュータは、単一位置にあるか、または多数の位置に分散され、通信ネットワークで相互接続される。

例示的な実施形態においては、動作は、コンピュータプログラムを実行する一つ以上のプログラマブルプロセッサによって実施され、入力データを操作し、出力を生成することによって機能を実施する。方法の動作もまた、例えば、フィールドプログラマブルゲートアレイ（FPGA）もしくは特定用途向け集積回路（ASIC）などの専用論理回路によって実施することができ、例示的な実施形態の装置は、専用論理回路として実装されてもよい。

コンピューティングシステムは、クライアントおよびサーバを含みうる。クライアントおよびサーバは、概して、お互いから遠隔の位置にあり、典型的には通信ネットワークを介して相互作用する。クライアントおよびサーバの関係は、其々のコンピュータ上で実行し、かつ、クライアントサーバ関係をお互いに有するコンピュータプログラムによって生じる。プログラマブルコンピューティングシステムを展開する実施形態においては、ハードウェアおよびソフトウェアアーキテクチャの双方の考慮が必要であることを理解されたい。特に、ある機能を恒久的に構成されたハードウェア（例えば、ASIC）で実装するか、一時的に構成されたハードウェア（例えば、ソフトウェアおよびプログラマブルプロセッサの組み合わせ）で実装するか、または、恒久的に構成されたハードウェアと一時的に構成されたハードウェアの組み合わせ（例えば、ソフトウェアおよびプログラマブルプロセッサの組み合わせ）で実装するかは、設計上の選択であってもよいことを理解されたい。以下に記述されるのは、種々の例示的な実施形態において展開されうる、ハードウェア（例えば、マシン）およびソフトウェアアーキテクチャである。
［例示的なマシンアーキテクチャおよびマシンで読み出し可能な記憶媒体］

図１７は、本明細書で議論された方法論のうちの如何なる一つ以上をマシンに実施させるための命令が実行されうるコンピュータシステム１７００の例示的な形式におけるマシンのブロック図である。別の実施形態においては、マシンは、スタンドアローンデバイスとして動作するか、または他のマシンに対して接続され（ネットワークを介して接続され）てもよい。ネットワーク接続された配置においては、マシンは、サーバクライアントネットワーク環境におけるサーバもしくはクライアントマシンの容量で動作してもよいし、または、ピアツーピア（もしくは分散）ネットワーク環境におけるピアマシンとして動作してもよい。マシンは、パーソナルコンピュータ（PC）、タブレットPC、セットトップボックス（STB）、携帯情報端末（PDA）、携帯電話、ウェブ設備、ネットワークルータ、スイッチもしくはブリッジ、または、そのマシンによってなされる動作を指定する命令を（シーケンシャルか或いはその逆に）実行することが可能なあらゆるマシンでありうる。さらには、単一のマシンのみが図示されているが、“マシン”という語は、本明細書で議論された方法論のうちのあらゆる一つ以上を実施するための一組（もしくは複数組）の命令を個々に、または共同して実行する、あらゆるマシンの集合として解釈されるべきである。

例示的なコンピュータシステム１７００は、プロセッサ１７０２（例えば、中央処理装置（CPU）、グラフィック処理ユニット（GPU）もしくはその両方）、メインメモリ１７０４、スタティックメモリ１７０６を含み、それらはお互いにバス１７０８を介して通信する。コンピュータシステム１７００は、ビデオディスプレイユニット１７１０（例えば、液晶ディスプレイ（LCD）もしくはブラウン管（CRT））をさらに含んでもよい。コンピュータシステム１７００は、英数字入力デバイス１７１２（例えば、キーボード）、ユーザインターフェイス（UI）ナビゲーション（もしくはカーソル制御）デバイス１７１４（例えば、マウス）、ディスクドライブユニット１７１６、信号生成デバイス１７１８（例えば、スピーカ）およびネットワークインターフェイスデバイス１７２０をも含む。
［マシンで読み出し可能な記憶媒体］

ディスクドライブユニット１７１６は、本明細書で記述された方法論もしくは機能のうちの如何なる一つ以上を具現化するか、またはそれによって利用される、一つ以上の組の命令１７２４およびデータ構造（例えば、ソフトウェア）が格納された、マシンで読み出し可能な記憶媒体１７２２を含む。命令１７２４は、コンピュータシステム１７００によるそれらの実行中に、メインメモリ１７０４および／もしくはプロセッサ１７０２内に完全に、または少なくとも部分的に存在し、メインメモリ１７０４およびプロセッサ１７０２もまた、マシンで読み出し可能な記憶媒体を構成する。命令１７２４は、スタティックメモリ１７０６内にもまた、完全に、または少なくとも部分的に存在してもよい。

マシンで読み出し可能な記憶媒体１７２２は、例示的な一実施形態においては、単一の記憶媒体として示されているが、“マシンで読み出し可能な記憶媒体”という語は、一つ以上の命令１７２４もしくはデータ構造を格納する単一の記憶媒体もしくは複数の記憶媒体（例えば、集中型もしくは分散型データベース、ならびに／または、キャッシュおよびサーバ）を含んでもよい。“マシンで読み出し可能な記憶媒体”という語は、マシンによって実行するための、本実施形態の方法論のうちのあらゆる一つ以上をマシンに実施させる命令を格納し、エンコードし、伝達することが可能な具体的なあらゆる媒体、または、このような命令に関連するか、このような命令によって利用されるデータ構造を格納し、エンコードし、伝達することが可能な具体的なあらゆる媒体を含むものとして解釈されるべきである。“マシンで読み出し可能な記憶媒体”という語は、したがって、ソリッドステートメモリ、光学および磁気記憶媒体を含むものとして解釈されるべきであるが、そのいずれにも限定はされない。マシンで読み出し可能な記憶媒体の具体的な実施例は、不揮発性メモリを含む。例えば、不揮発性メモリは、例示の目的のため、消去可能プログラマブルリードオンリーメモリ（EPROM）、電子的に消去可能なプログラマブルリードオンリーメモリ（EEPROM）、およびフラッシュメモリデバイスなどの半導体メモリデバイス；内部ハードディスクおよびリムーバブルディスクなどの磁気ディスク；光磁気ディスク；ならびにコンパクトディスクリードオンリーメモリ（CD-ROM）、デジタル多目的ディスク（もしくはデジタルビデオディスク）リードオンリーメモリ（DVD-ROM）ディスクを含む。
［伝送媒体］

命令１７２４は、伝送媒体を利用する通信ネットワーク１７２６を介してさらに伝送されるか、または受信されてもよい。命令１７２４は、ネットワークインターフェイスデバイス１７２０および多数の既知の転送プロトコル（例えば、ハイパーテキスト転送プロトコルもしくはHTTP）のうちのいずれかを利用して伝送されてもよい。通信ネットワークの実施例は、ローカルエリアネットワーク（“LAN”）、ワイドエリアネットワーク（“WAN”）、インターネット、携帯電話ネットワーク、従来型電話サービス（POTS）ネットワーク、およびワイヤレスデータネットワーク（例えば、WiFi、WiMaxネットワーク）を含む。“伝送媒体”という語は、マシンによる実行のための命令を格納、エンコード、または伝達することが可能なあらゆる無形媒体を含むものとして解釈されるべきであり、このようなソフトウェアの通信を容易にするためのデジタルもしくはアナログ通信信号もしくは他の無形媒体を含む。

一実施形態は、具体的な例示的実施形態を参照して記述されてきたが、本開示の広範な趣旨および範囲を逸脱することなく、これらの実施形態に対して種々の改変および変更がなされてもよいことは明らかである。したがって、明細書および図面は、限定する意味ではなく、例示的な意味としてみなされるべきである。本明細書の一部を形成する付随の図面は、本発明の主題が実施される可能性のある具体的な実施形態を、限定する目的ではなく例示する目的で、示すものである。示された実施形態は、当業者が本明細書で開示された教示を実践することが可能なほど、十分詳細に記述される。示された実施形態から他の実施形態が利用され、派生する可能性があり、構造的および論理的置換ならびに変更が本開示の範囲から逸脱することなく加えられてもよい。したがって、この詳細な説明は、限定する意味で解釈されるべきではなく、種々の実施形態の範囲は、添付の請求項およびその請求項が権利を有する均等物の全範囲によってのみ定義される。

本発明の主題のこのような実施形態が、個々に、および／もしくは集合的に、簡便のため、単に“発明”という用語によって、本明細書で言及されているが、実際に一つ以上の発明が開示される場合には、如何なる単一の発明もしくは発明の概念へと、本出願の範囲を故意に限定することを意図するものではない。したがって、本明細書では具体的な実施形態が示され、かつ記述されてきたが、同一の目的を達すると推定されるあらゆる配置が、示された具体的実施形態に対して置換されてもよいことを理解されたい。本開示は、種々の実施形態のあらゆる、および全ての適応もしくは変形を包含することを意図される。上述された実施形態および他の実施形態の組み合わせは、本明細書では特に記述されていないが、上記の説明を検討することによって当業者にとって明らかであろう。

Claims (20)

1. アプリケーションサーバ上で実行されるアプリケーションに関連する呼び出しオプティマイザを含むシステムにおいて、
   前記アプリケーションは、複数のコンポーネントを含み、
   前記呼び出しオプティマイザは、
   第一のウェブサービス呼び出しおよび第二のウェブサービス呼び出しを遮断する遮断モジュールであって、前記第一のウェブサービス呼び出しは、前記複数のコンポーネントのうちの第一のコンポーネントによってウェブサービスに対してなされ、前記第二のウェブサービス呼び出しは、前記複数のコンポーネントのうちの第二のコンポーネントによって前記ウェブサービスに対してなされる、遮断モジュールと、
   前記第一のウェブサービス呼び出しおよび前記第二のウェブサービス呼び出しを第三のウェブサービス呼び出しへと統合する統合モジュールと、
   を含む、
   ことを特徴とするシステム。
2. 前記統合モジュールは、
   前記第一のウェブサービス呼び出しの複数の要求パラメータを、前記第三のウェブサービス呼び出しの複数の要求パラメータへと統合し、
   前記第ニのウェブサービス呼び出しの複数の要求パラメータを、前記第三のウェブサービス呼び出しの前記複数の要求パラメータへと統合し、
   前記第三のウェブサービス呼び出しを実行する、
   ように構成される、
   ことを特徴とする請求項１に記載のシステム。
3. 前記統合モジュールは、
   前記第三のウェブサービス呼び出しの結果を受信し、
   前記第一のウェブサービス呼び出しに対応するものとして、前記結果の第一部分を識別し、
   前記第二のウェブサービス呼び出しに対応するものとして、前記結果の第二部分を識別し、
   前記第一のウェブサービス呼び出しに対する応答として、前記複数のコンポーネントのうちの前記第一のコンポーネントへと、前記結果の前記第一部分を提供し、
   前記第二のウェブサービス呼び出しに対する応答として、前記複数のコンポーネントのうちの前記第二のコンポーネントへと、前記結果の前記第二部分を提供する、
   ようにさらに構成される、
   ことを特徴とする請求項２に記載のシステム。
4. 前記アプリケーションに関連するリソースアグリゲータをさらに含み、前記リソースアグリゲータは、
   第一のリソースが第二のリソースと重複することを識別する識別モジュールであって、前記第一のリソースは、前記複数のコンポーネントのうちの前記第一のコンポーネントによって利用され、前記第二のリソースは、前記複数のコンポーネントのうちの前記第二のコンポーネントによって利用される、識別モジュールと、
   前記識別に応じて、前記第一のリソースおよび前記第二のリソースを第三のリソースへと集約する集約モジュールと、
   前記集約に応じて、前記第三のリソースを利用するために、前記アプリケーションをアップデートするアップデートモジュールと、
   を含む、
   ことを特徴とする請求項１に記載のシステム。
5. 前記第一のリソースは、カスケーディングスタイルシートの第一バージョンであり、前記第二のリソースは、前記カスケーディングスタイルシートの第二バージョンである、
   ことを特徴とする請求項４に記載のシステム。
6. 前記アプリケーションサーバの第一のクライアントをさらに含み、前記第一のクライアントは、前記アプリケーションサーバ上の前記アプリケーションの展開を前記第一のクライアント上でシミュレーションするシミュレーティングモジュールを含み、前記シミュレーティングモジュールは、前記アプリケーションサーバと通信する代わりに、前記クライアントにインストールされた構成要素と通信することが可能である、
   ことを特徴とする請求項１に記載のシステム。
7. 前記第一のクライアントは、前記アプリケーションサーバ上の前記アプリケーションの複数のバージョンを実行可能とする際に、前記複数のバージョンのうちの第一のバージョンは、第二のクライアントに対して適応され、前記複数のバージョンのうちの第二のバージョンは、第三のクライアントに対して適応され、前記第二のクライアントは、モバイルデバイス上で実行され、前記第三のクライアントは、パーソナルコンピュータ上で実行される、
   ことを特徴とする請求項６に記載のシステム。
8. アプリケーションサーバ上で実行されるアプリケーションに関連する呼び出しオプティマイザを含むシステムにおいて、
   前記アプリケーションは、複数のコンポーネントを含み、
   前記呼び出しオプティマイザは、
   第一のウェブサービス呼び出しおよび第二のウェブサービス呼び出しを遮断する遮断モジュールであって、前記第一のウェブサービス呼び出しは、前記複数のコンポーネントのうちの第一のコンポーネントによってウェブサービスに対してなされ、前記第二のウェブサービス呼び出しは、前記複数のコンポーネントのうちの第二のコンポーネントによって前記ウェブサービスに対してなされる、遮断モジュールと、
   複数の最適化のうちの一つを選択する最適化選択モジュールであって、前記複数の最適化は、前記第一のウェブサービス呼び出しおよび前記第二のウェブサービス呼び出しの前記ウェブサービスに対する、バッチ呼び出しとしての第三のウェブサービス呼び出しへの統合を含む、最適化選択モジュールと、
   前記複数の最適化のうちの前記一つとしての、前記第一のウェブサービス呼び出しおよび前記第二のウェブサービス呼び出しの前記第三のウェブサービス呼び出しへの前記統合の前記選択に応じて、前記第一のウェブサービス呼び出しおよび前記第二のウェブサービス呼び出しを前記第三のウェブサービス呼び出しへと、バッチ呼び出しとして統合する統合モジュールと、
   を含む、
   ことを特徴とするシステム。
9. 前記複数の最適化は、前記ウェブサービスに対する第四のウェブサービス呼び出しの実行を含み、前記第四のウェブサービス呼び出しは、バッチ呼び出しであり、前記バッチ呼び出しの結果の第一部分は、前記第一のウェブサービス呼び出しに対する応答として利用可能であり、前記バッチ呼び出しの前記結果の第二部分は、前記第二のウェブサービス呼び出しに対する応答として利用可能であり、
   前記システムは、前記複数の最適化のうちの前記一つとしての前記第四のウェブサービス呼び出しの前記実行の選択に応じて、
   前記第四のウェブサービス呼び出しを実行し、
   前記第一のウェブサービス呼び出しに対する前記応答として、前記複数のコンポーネントのうちの前記第一のコンポーネントへと、前記結果の前記第一部分を提供し、
   前記第二のウェブサービス呼び出しに対する前記応答として、前記複数のコンポーネントのうちの前記第二のコンポーネントへと、前記結果の前記第二部分を提供する
   バッチ処理モジュールをさらに含む、
   ことを特徴とする請求項８に記載のシステム。
10. 前記複数の最適化のうちの前記一つとしての前記第四のウェブサービス呼び出しの前記実行の前記選択は、前記ウェブサービスが前記第四のウェブサービス呼び出しに対応するインターフェイスを提供したという判断に基づく、
    ことを特徴とする請求項９に記載のシステム。
11. 前記複数の最適化のうちの前記一つとしての前記第四のウェブサービス呼び出しの前記実行の前記選択は、前記第四のウェブサービス呼び出しの前記実行が、前記第一のウェブサービス呼び出しおよび前記第二のウェブサービス呼び出しの前記第三のウェブサービス呼び出しへの前記統合よりも時間がかからないという判断に基づく、
    ことを特徴とする請求項９に記載のシステム。
12. 前記複数の最適化は、前記第一のウェブサービス呼び出しが実行される必要がないように、キャッシュからの前記第一のウェブサービス呼び出しに対する応答を提供することを含み、
    前記システムは、前記複数の最適化のうちの前記一つとして、前記キャッシュからの前記第一のウェブサービス呼び出しに対する前記応答を前記提供することの選択に応じて、前記キャッシュからの前記第一のウェブサービス呼び出しに対する前記応答を提供するキャッシングモジュールをさらに含む、
    ことを特徴とする請求項８に記載のシステム。
13. 前記複数の最適化のうちの前記一つとして、前記キャッシュからの前記第一のウェブサービス呼び出しに対する前記応答を前記提供することを前記選択することは、前記第一のウェブサービス呼び出しが第二のウェブサービス呼び出しと同一であるという判断に基づいており、前記第二のウェブサービス呼び出しの実行は、結果として前記応答の受信をもたらす、
    ことを特徴とする請求項１２に記載のシステム。
14. 前記複数の最適化は、前記第一のウェブサービス呼び出しおよび前記第二のウェブサービス呼び出しをパラレルに実行することを含み、
    前記システムは、前記複数の最適化のうちの前記一つとして、前記第一のウェブサービス呼び出しおよび前記第二のウェブサービス呼び出しをパラレルに前記実行することを選択するのに応じて、前記第一のウェブサービス呼び出しおよび前記第二のウェブサービス呼び出しをパラレルに実行する実行モジュールをさらに含む、
    ことを特徴とする請求項８に記載のシステム。
15. 前記複数の最適化のうちの前記一つとして、前記第一のウェブサービス呼び出しおよび前記第二のウェブサービス呼び出しをパラレルに前記実行することを前記選択することは、前記第一のウェブサービス呼び出しおよび前記第二のウェブサービス呼び出しを前記第三のウェブサービス呼び出しへと前記統合するよりも、前記第一のウェブサービス呼び出しおよび前記第二のウェブサービス呼び出しをパラレルに実行することは時間がかからないという判断に基づく、
    ことを特徴とする請求項１４に記載のシステム。
16. アプリケーションサーバ上で実行されるアプリケーションに関連する呼び出しオプティマイザが行なう方法であって、
    前記呼び出しオプティマイザが行なう方法は、
    第一のウェブサービス呼び出しおよび第二のウェブサービス呼び出しを受信するステップであって、前記第一のウェブサービス呼び出しは、アプリケーションサーバ上で実行されるアプリケーションに含まれる複数のコンポーネントのうちの第一のコンポーネントによってウェブサービスに対してなされ、前記第二のウェブサービス呼び出しは、前記複数のコンポーネントのうちの第二のコンポーネントによって前記ウェブサービスに対してなされる、ステップと、
    複数の最適化のうちの一つを選択するステップであって、前記複数の最適化は、前記第一のウェブサービス呼び出しおよび前記第二のウェブサービス呼び出しを、前記ウェブサービスに対する第三のウェブサービス呼び出しへと統合するステップを含む、ステップと、
    前記複数の最適化のうちの前記一つとして、前記第一のウェブサービス呼び出しおよび前記第二のウェブサービス呼び出しを前記第三のウェブサービス呼び出しへと前記統合するステップを前記選択するステップに応じて、前記第一のウェブサービス呼び出しおよび前記第二のウェブサービス呼び出しを前記第三のウェブサービス呼び出しへと統合するステップと、
    を含む、
    ことを特徴とする方法。
17. 前記第一のウェブサービス呼び出しおよび前記第二のウェブサービス呼び出しを前記第三のウェブサービス呼び出しへと前記統合するステップは、
    前記第一のウェブサービス呼び出しの複数の要求パラメータを、前記第三のウェブサービス呼び出しの複数の要求パラメータへと統合するステップと、
    前記第二のウェブサービス呼び出しの複数の要求パラメータを、前記第三のウェブサービス呼び出しの前記複数の要求パラメータへと統合するステップと、
    前記第三のウェブサービス呼び出しを実行するステップと、
    を含む、
    ことを特徴とする請求項１６に記載の方法。
18. 前記複数の最適化は、前記ウェブサービスに対して第四のウェブサービス呼び出しを実行するステップを含み、前記第四のウェブサービス呼び出しはバッチ呼び出しであり、前記バッチ呼び出しの結果の第一部分は、前記第一のウェブサービス呼び出しに対する応答として利用可能であり、前記バッチ呼び出しの前記結果の第二部分は、前記第二のウェブサービス呼び出しに対する応答として利用可能であり、
    前記方法は、前記複数の最適化のうちの前記一つとしての前記第四のウェブサービス呼び出しの前記実行を選択するステップに応じて、
    前記第四のウェブサービス呼び出しを実行するステップと、
    前記第一のウェブサービス呼び出しに対する前記応答として、前記複数のコンポーネントのうちの前記第一のコンポーネントへと、前記結果の前記第一部分を提供するステップと、
    前記第二のウェブサービス呼び出しに対する前記応答として、前記複数のコンポーネントのうちの前記第二のコンポーネントへと、前記結果の前記第二部分を提供するステップと、
    をさらに含む、
    ことを特徴とする請求項１６に記載の方法。
19. 第一のウェブサービス呼び出しおよび第二のウェブサービス呼び出しを受信するステップであって、前記第一のウェブサービス呼び出しは、アプリケーションサーバ上で実行されるアプリケーションに含まれる複数のコンポーネントのうちの第一のコンポーネントによってウェブサービスに対してなされ、前記第二のウェブサービス呼び出しは、前記複数のコンポーネントのうちの第二のコンポーネントによって前記ウェブサービスに対してなされる、ステップと、
    複数の最適化のうちの一つを選択するステップであって、前記複数の最適化は、前記第一のウェブサービス呼び出しおよび前記第二のウェブサービス呼び出しを前記ウェブサービスに対する第三のウェブサービス呼び出しへと統合するステップを含む、ステップと、
    前記複数の最適化のうちの前記一つとして、前記第一のウェブサービス呼び出しおよび前記第二のウェブサービス呼び出しを前記第三のウェブサービス呼び出しへと前記統合するステップを前記選択するステップに応じて、前記第一のウェブサービス呼び出しおよび前記第二のウェブサービス呼び出しを前記第三のウェブサービス呼び出しへと統合するステップと、
    を含む方法を、マシンの一つ以上のプロセッサによって実行されたとき、前記マシンに実施させる命令を含む、
    ことを特徴とするマシンで読み出し可能な記憶媒体。
20. 前記第一のウェブサービス呼び出しおよび前記第二のウェブサービス呼び出しを前記第三のウェブサービス呼び出しへと前記統合するステップは、
    前記第一のウェブサービス呼び出しの複数の要求パラメータを、前記第三のウェブサービス呼び出しの複数の要求パラメータへと統合するステップと、
    前記第二のウェブサービス呼び出しの複数の要求パラメータを、前記第三のウェブサービス呼び出しの前記複数の要求パラメータへと統合するステップと、
    前記第三のウェブサービス呼び出しを実行するステップと、
    を含む、
    ことを特徴とする請求項１９に記載のマシンで読み出し可能な記憶媒体。
    

Images