JP2006244472A - Ｍａｐｉ準拠のメールアプリケーションを用いたウェブサービス処理 - Google Patents

Abstract

【課題】非同期通信を拡張し、オフラインもしくは非接続期間をサポートし、またウェブサービス環境中でメッセージを交換するために既存のインフラストラクチャを利用するウェブベースのサービスインフラストラクチャを提供する。
【解決手段】本発明は、メールトランスポートを介してウェブサービスを提供する。具体的には、本発明は、オフライン通信および延長されたサービス要求処理時間をサポートするため、ＭＡＰＩメールアプリケーションを使用することによって、このようなメッセージ交換のために追加インフラストラクチャを形成することなく、ウェブサービスメッセージを送信する。カスタムレイヤトランスポートは、ウェブサービスメッセージがメールトランスポートを介して送信されるべきであることを識別し、ＭＡＰＩアプリケーションを用いてメールメッセージを生成し、メールメッセージ内にウェブサービスメッセージおよび他の識別子を含むように構成される。
【選択図】図１Ａ

Description

本発明は、一般に、ウェブサービスおよび他の分散システム中で使用されるバインディング機構に関する。より詳細には、本発明は、オフライン通信をサポートし、かつサービス要求の処理時間を延長するために、ＭＡＰＩ（Ｍｅｓｓａｇｉｎｇ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）準拠メールアプリケーションを用いることによって、このようなメッセージ交換のための追加のインフラストラクチャを形成することなしに、メールメッセージトランスポートを介するウェブサービスを提供する。

コンピュータシステムおよびそれに関連する技術は、社会の多くの側面に影響を与えている。実際に、コンピュータシステムの情報処理能力は、人々が生活し働く様式を変化させている。現在、コンピュータシステムは、コンピュータシステムの出現前までは通常手作業で行われていた多くのタスク（例えば、ワードプロセッシング、スケジューリング、データベース管理など）を実行している。さらに最近では、コンピュータシステムを互いに結合してコンピュータネットワークを形成するようにして、電子的にデータを共用するためにそのネットワークを介して通信することができる。ウェブサービスは、コンピュータ間のこのような通信を向上させる原動力であり、ソフトウェアを構築し使用する方法を一変させている。

ウェブサービスは、アプリケーションにデータの共用を可能にし、そのアプリケーションがいかにして構築されたか、どのオペレーティングシステムまたはプラットフォーム上で動作するか、またそれにアクセスするためにどの装置を使用するかに関係なく他のアプリケーションから機能をより強力に呼び出せるようにする。ウェブサービスは、ＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｐｅｎ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）、ＵＤＤＩ（Ｕｎｉｖｅｒｓａｌ Ｄｅｓｃｒｉｐｔｉｏｎ Ｄｉｓｃｏｖｅｒｙ Ｉｎｔｅｇｒａｔｉｏｎ）、ＷＳＤＬ（Ｗｅｂ Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）などを含む業界標準プロトコルによりインターネットを介して呼び出される。ウェブサービスは、互いに独立したままであるが、特定のタスクを実行する共同作業グループに対して緩く（ｌｏｏｓｅｌｙ）リンクすることができる。

ウェブサービスネットワーク上の電子通信は、サーバコンピュータシステム（以下、「サーバ」、「サービス」または「ウェブサービス」と呼ぶ）におけるネットワークサービス（例えば、ウェブサービス）へのアクセスを要求するクライアントコンピュータシステム（以下、「クライアント」と呼ぶ）を含むことが多い。したがって、クライアントは、そのシステムリソースへの特定のアクセスを求める要求をそのサービスに送信し、そのクライアントが許可され確認された場合、そのサービスは、所望の情報を提供する応答メッセージで応答する。クライアントとサービスの間の他のメッセージングパターンも利用可能であり、簡単な単一メッセージ、ならびにより高級なマルチメッセージ交換、例えば、通知、送信請求応答、パブリッシュ／サブスクライブパターン、ポーリング、キックプッシュ（ｋｉｃｋ−ｐｕｓｈ）、キューイングなどを含むことは当然である。さらに、この種の通信は、分散システム（例えば、ウェブサービス）のためのコントラクト（ｃｏｎｔｒａｃｔ）中の、クライアントとサービスの双方によって決定される様々の要件および機能によって支配される。

コントラクトは、サービス（またはクライアント）の挙動の可視的な側面の表現である。コントラクトは、マシン可読言語および人間の言語を混合したものによって表される。マシン可読言語は、明らかに精度を高めることが可能であること以外に、部分的なサービス実装の構築、サービス配信の自動化、交換されるメッセージの監査／妥当性検査、サービスの管理、および多くの他のネットワークに関係する機能を実施できるようにする。しかし、マシン可読言語の表現力の限界のため、人間の言語が、主として、メッセージおよびメッセージ交換パターンの意味論を記述するために、コントラクトの重要な構成要素として使用されている。

ネットワークプロトコル記述言語（例えば、ＷＳＤＬ）は、共通または標準の言語でコントラクト（例えば、ウェブサービスコントラクト）を記述するための全体のラッパ（ｗｒａｐｐｅｒ）または仕様を提供する。このような仕様を用いると、開発者および開発者ツールはコントラクトを作成しかつ解釈することが容易になる。そのネットワークプロトコル記述言語（以下、「ＮＰＤＬ」と呼ぶ）は、豊富なツーリングスイート（ｓｕｉｔｅｓ）を有しており、それがよく使用される主な理由である。最近まで、それらのＮＰＤＬは、メッセージをどのようにカプセル化またはフォーマットするか（例えば、ＳＯＡＰエンベロープ）、またサービスとメッセージ交換するためにどのトランスポートを使用するか（例えば、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ））を記述する単一のトランスポートまたはバインディング機構とコントラクトを結んでいた。

現在、ウェブサービスの実装においては、一部にはそのユビキタスな性質のため、主要なトランスポートとしてＨＴＴＰが使用される。ＨＴＴＰがウェブサービスのためのトランスポートとしての人気が高まっているが、ＨＴＴＰはまた、よく知られているいくつかの制限を有する。例えば、ＨＴＴＰは要求／応答型のトランスポートであり、同期型トランザクションをサポートする。しかし、この種のメッセージ交換パターンは、非同期通信に対する課題を提示する。例えば、ウェブサービスクライアントは、ウェブサービスから何らかの応答を取得するために接続をキープアライブ（ｋｅｅｐ−ａｌｉｖｅ）する必要がある。それは、更新のため、クライアントがコンスタントにサーバにポーリングする機構を作成することなしには、ＨＴＴＰを用いた長時間トランザクション（例えば、処理をするのに数日かかる抵当取引）の実施を困難にする。このようなポーリングは、貴重なリソースを不必要に使用することになる。

ＨＴＴＰに関する他の問題は、それが接続ベースのプロトコルであることである。したがって、メッセージ交換パターンにおける各端末（すなわち、クライアントとサービス）は、ＨＴＴＰ要求／応答を完了するために常時接続され、アクティブでなくてはならない。それができそうもない状況（例えば、何らかの遠隔位置にあるウェブサービスに接続しようとするクライアント）の場合、メッセージは送達不可能と見なされ、ＨＴＴＰプロトコルはメッセージのキャッシュおよび記憶をサポートしないので、システムは障害を起こすことになる。

さらに、ウェブサービス環境中においてＨＴＴＰを用いることに関する他の問題は、ＨＴＴＰを使用するには追加のインフラストラクチャを必要とすることである。例えば、ウェブサイトをホストするには、ＨＴＴＰを使用するウェブサービスはインフラストラクチャおよびセットアップを必要とする。ホストされたウェブサービスをサポートするために、各コンピューティング装置は、コンピュータごとにウェブサーバまたは同等の機能のインストールを求める着信ＨＴＴＰ要求を受けることができる必要がある。それは、新しい管理およびセキュリティ上の問題を生ずることになる。その結果、例えば一時的なコンピュータユーザ、あるいはウェブサーバを構成することに習熟していないユーザなど、いくつかの環境において問題となり得る。

上記の制限があることにより、ウェブサービスをサポートできる代替のトランスポートの実装およびアイデアがすでに生まれている。したがって、さまざまなウェブサービスエンジンを用いて、開発者はいくつかのカプセル化およびトランスポートプロトコルを含めるためのバインディングまたはバインディング機構を記述または拡張することができる。例えば、開発者は、１つまたは複数の以下のものを含むようにトランスポートをカスタム化することができる。すなわち、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍｅｓｓａｇｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）などである。これらのバインディング拡張により、他のトランスポートの有利な機能を利用することができるが、それは、ＨＴＴＰの上記欠点に対処するものではない。

例えば、ＳＭＴＰバインディングが使用される場合、ウェブサービスメッセージをメッセージの本文が含んでいる標準のメールメッセージが生成され、次いで、それは有線を介して他のエンドポイントに転送される。ＳＭＴＰトランスポートを使用することは、ＨＴＴＰに対して有利な機能を有することができるが、このようにＳＭＴＰを使用することは、なお、エンドポイントがそれぞれ、ＳＭＴＰトランスポートを介して接続されることが必要となる。さらに、メールメッセージ内におけるウェブサービスメッセージの生成およびカプセル化が追加のインフラストラクチャを必要とし、やはり上記のように、管理問題およびセキュリティ上の問題を生ずることになる。したがって、非同期通信を拡張し、オフラインもしくは非接続期間をサポートし、またウェブサービス環境中でメッセージを交換するために、既存のインフラストラクチャを利用するウェブベースのサービスインフラストラクチャが求められている。

現在のウェブサービスバインディング機構の上記の欠陥および欠点は、本発明の例示的な諸実施形態によって克服される。例えば、本発明は、オフライン通信をサポートし、かつサービス要求の処理時間を延長するために、ＭＡＰＩ（Ｍｅｓｓａｇｉｎｇ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）準拠のメールアプリケーションを利用することによって、このようなメッセージ交換のために追加のインフラストラクチャを形成することなしに、メールトランスポートを介したウェブサービスを提供する。さらに、本発明はオフライン通信をサポートし、かつＮＰＤＬデータ構造を生成するために、ＭＡＰＩ準拠メールアプリケーションを利用することによって、ウェブサービスアプリケーションにアクセスすることなしに、メールトランスポートを介したウェブサービスアプリケーションのためのＮＰＤＬ（Ｎｅｔｗｏｒｋ Ｐｒｏｔｏｃｏｌ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）データ構造の配布を提供する。

例えば、諸実施形態は、メールメッセージトランスポートを介して通信するクライアントとウェブサービスの間でのメッセージ交換パターンの一部であるウェブサービスメッセージを送信するために、ＭＡＰＩ準拠のメールアプリケーションを使用していることを識別するアドレッシング方式（ｓｃｈｅｍｅ）を含むウェブサービスメッセージを受信することを含む。アドレッシング方式に含まれるエンドポイントメーリングアドレスは、次いで、対応するエンドポイントにウェブサービスメッセージを送信するために識別される。その後、ＭＡＰＩ準拠のメールアプリケーションを使用するメールメッセージが生成される。メールメッセージは、エンドポイントメーリングアドレスと、ウェブサービスメッセージと、ウェブサービスおよびそのウェブサービスメッセージに対するメッセージ交換タイプ（例えば、要求、応答など）を識別するための識別子とを含む。その後引き続き、メールメッセージトランスポートを介してエンドポイントに後で送達するために、メールメッセージは、ＭＡＰＩ準拠メールアプリケーションの発信メールボックスに送られる。

他の例示的な実施形態では、メールメッセージは、メールメッセージトランスポートを介して受信される。メッセージは、エンドポイントのウェブサービスアプリケーションに対応するＭＡＰＩ準拠メールアプリケーションの着信メールボックスにおいて受信される。その後、メールメッセージは、ＭＡＰＩ準拠メールアプリケーションに対応するエンドポイントメールアドレスと、クライアントとウェブサービスの間でのメッセージ交換パターンの一部であるウェブサービスメッセージと、ウェブサービスおよびそのウェブサービスメッセージに対するメッセージ交換タイプを識別するための識別子とを含んでいるものとして識別される。ウェブサービスおよびそのウェブサービスメッセージに対するメッセージ交換タイプに基づいて、ウェブサービスメッセージは、処理のためエンドポイントウェブサービスアプリケーションに送信される。

他の例示的な実施形態は、メールトランスポートを介してＮＰＤＬ（例えば、ＷＳＤＬデータ構造）を配布することを含む。その例示的な実施形態は、ウェブサービスアプリケーションに関連するＭＡＰＩ準拠メールアプリケーションの着信メールボックスにおいて、エンドポイントからのメールメッセージを受信することを含む。次いで、メールメッセージは、エンドポイントアプリケーションが、ウェブサービスアプリケーションとメッセージを交換するときに準拠する１つまたは複数のコントラクトを記述するための仕様であるＮＰＤＬデータ構造を要求しているものとして識別される。その後、ＮＰＤＬデータ構造は、ウェブサービスアプリケーションにアクセスすることなく、自動的に生成される。次いで、ＮＰＤＬデータ構造はエンドポイントに送信される。

本発明のさらなる機能および利点は、以下の説明の中で述べられているが、一部はその説明から自明のものであり、また本発明の実施によって理解することもできる。本発明の機能および利点は、添付された特許請求の範囲で特に示された手段および組合せにより実現され取得することができる。本発明のそれらのおよび他の機能は、以下の説明および添付の特許請求の範囲から十分明白になろうが、あるいは後に述べる本発明の実施によって理解することができる。

本発明の上記のおよび他の利点および機能を獲得できる方法を記述するために、上記に簡単に述べた本発明のより詳細な説明を、添付図面で示される本発明の特定の諸実施形態を参照しながら示すものとする。それらの図面は、本発明の典型的な諸実施形態を示しているに過ぎない。したがって、その範囲を限定するものと見なすべきではないことを理解した上で、添付図面を用いてさらなる特有な部分および詳細と共に本発明を記述し説明する。

本発明は、ＭＡＰＩ準拠メールアプリケーションを使用しメールトランスポートを介して、クライアントとウェブサービスの間でウェブサービスメッセージを交換するための方法、システム、およびコンピュータプログラム製品に及ぶ。さらに、本発明は、ＭＡＰＩ準拠メールアプリケーションを介して要求側エンドポイントにＮＰＤＬデータ構造を送ることを含む。本発明の諸実施形態は、様々なコンピュータハードウェアを含む専用または汎用コンピュータを含むことができ、それを以下でより詳細に説明する。

本発明は、メールトランスポートを介してウェブサービスのためにメッセージを交換することを目的として、ＭＡＰＩ（Ｍｅｓｓａｇｉｎｇ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）準拠メールアプリケーションを利用することを含む。ＭＡＰＩ準拠メールアプリケーションの諸実施例は、Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ（登録商標）、Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ Ｅｘｃｈａｎｇｅ（登録商標）、Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ（登録商標）、Ｑｕａｌｃｏｍｍ（登録商標）のＥｕｄｏｒａ（登録商標）、およびメール交換サーバまたはメールストアと通信できる他の同様な電子メールアプリケーションを含む。他の例示的な実施形態はまた、例えば、ＷＳＤＬ（Ｗｅｂ Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）文書などのＮＰＤＬ（Ｎｅｔｗｏｒｋ Ｐｒｏｔｏｃｏｌ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）データ構造を要求するためにこれらのＭＡＰＩ準拠メールアプリケーションを用いることを含み、それによって、クライアントおよびサービス開発者は、対応するウェブサービスアプリケーションにアクセスする必要なく、設計時にそれらの文書にアクセスできるようになる。

上記のＭＡＰＩ準拠メールアプリケーションは、途方もなく広く行きわたった技術であり、世界中の数多くの人々が、日々メッセージを交換するためにこれらのアプリケーションを使用している。アプリケーション間で交換されるウェブサービスメッセージのためのトランスポートとしてこのようなＭＡＰＩ準拠メールアプリケーションを使用する機能は、信じられないほど強力になる。例えば、前にＨＴＴＰについて概略を示した課題を考えると、ＭＡＰＩ準拠メールアプリケーションを使用することがなぜ従来技術に対してはるかに利点を有しているのか理解することができよう。具体的には、このようなＭＡＰＩ準拠メールアプリケーションは、ＨＴＴＰおよび他の同様のトランスポートに対してはるかに非同期のモデルを提供する。ＭＡＰＩ準拠メールアプリケーションのユーザは、メッセージを送信し、次いで、数分後、数時間後、あるいは数日後にもなる返事を待つことができる。したがって、それがウェブサービスに適用された場合、ＭＡＰＩメールアプリケーションは、ウェブサービス要求を送信し、次いで、数分後、数時間後、または数日後の応答を受信するのに使用することができる。この非同期形式の対話は、ＨＴＴＰまたは他のトランスポートを使用して達成することは困難であり、いくつかの場合は不可能である。

さらに、ＭＡＰＩメールアプリケーションは、オフライン環境におけるメールメッセージの構築をサポートする。例えば、ユーザが、メール交換サーバへのアクセスもまたは接続性もない離れた場所にいた場合、ユーザは、なお、ＭＡＰＩ準拠メールアプリケーションを用いて、メッセージを作成することが可能であり、このようなメッセージは、このようなアプリケーションの発信メールボックスに保存される。次いで、それらのメッセージは、ユーザが次にそのメール交換サーバに接続した時に送信することができる。ＨＴＴＰおよび他の同様のトランスポートプロトコルのこのような欠点を克服するために、ＭＡＰＩ準拠メールアプリケーションと共にウェブサービスを使用できるモデルに対して、同様のプロセスが適用される。具体的には、本発明により、ウェブサービスメッセージ（例えば、要求または応答）を構成できるアプリケーションは、ＭＡＰＩメールアプリケーションの発信メールボックス内に普通のメールメッセージとしてウェブサービスメッセージを記憶できるようになる。したがって、本発明は、ウェブサービスメッセージのオフライン処理をサポートし、ユーザがそのネットワークに次に接続したとき、所望のエンドポイントにメッセージを送信することができる。

本モデルの他の利点は、追加のインフラストラクチャを必要としないことである。前に述べたように、着信ＨＴＴＰ要求をサポートすることは、通常、管理およびセキュリティ問題の原因となるウェブサーバのインストールを必要とする。本明細書に例示の諸実施形態によるＭＡＰＩメールアプリケーションを使用すると、必要なものはエンドポイントのためのメールボックスだけである。着信するメールウェブサービスメッセージを、何らかの追加のソフトウェアまたはインストールの経費も必要とせずに、そのメールボックスに送信することができる。

本発明はまた、ウェブサービス環境中においてエンドポイント間でメッセージを交換するためにＳＭＴＰトランスポートを使用する他の現行モデルに対して、いくつかの有利な機能を有する。例えば、このようなアプリケーションは、プロトコルまたはトランスポートではなく、ＭＡＰＩ準拠メールアプリケーションに特有の発信メールボックスの使用をサポートするので、例示的な諸実施形態によるＭＡＰＩメールアプリケーションを使用することは、オフラインで動作する能力を提供する。さらに、ＭＡＰＩ準拠メールアプリケーションの使用は、コンフィギュレーションの複製を含まない。例えば、ネイティブのもしくは現在のＳＭＴＰチャネルを使用する場合、ウェブサービスクライアントおよびサービスは、尚、電子メールアカウントのいくつかの詳細を知る必要がある。それは、例えば、ＳＭＴＰサーバの位置、ＰＯＰ３サーバのロケーション、ユーザ名、およびパスワードを含む。本発明によるＭＡＰＩメールアプリケーションを用いると、その情報のすべてがアプリケーション内にすでに構成されており、したがって、複製をする必要はない。

さらに、本発明の他の有利な機能は、分散環境中においてメッセージを交換するのに使用されるトランスポートを拡張することを含む。例えば、多くのＭＡＰＩメールアプリケーションは、メッセージを、ＳＭＴＰのほかに他のトランスポート上で送信することができる。例えば、これらのＭＡＰＩメールアプリケーションは、Ｈｏｔｍａｉｌ、Ｘ．２５、ＤＥＣ ＡＬＬ−ＩＮ−１などを用いてメッセージ送信するように拡張することができる。上記で識別された利点のいくつかを前提として、これらの所望の結果を得るため、どのようにＭＡＰＩメールアプリケーションを使用するかに関するより詳細な説明を、以下に示す。

図１Ａは、例示的な実施形態によるクライアントとサービスの間でメッセージを交換するためにＭＡＰＩメールアプリケーションを利用する分散システムを示す。図１Ａならびに本明細書に記載の他の図に関する以下の説明では、クライアント、サーバ、またはそれに関連付けられたアプリケーションに対するメールアドレスについて参照が時々行われる。理解されるように、このようなメーリングアドレスは、普通、何らかの特定のマシンまたはアプリケーションではなく、個人または会社にバインドされている。本明細書に記載の「メールアドレス」は、通常、クライアントまたはサービスの個人ユーザにバインドされるが、適用可能である場合、アプリケーションまたはマシンに拡張することも可能である。したがって、本明細書で使用されるどの特定のメーリングアドレスも、個人、会社、アプリケーション、またはマシンにバインドされるものと広く解釈されるべきである。

図１Ａで示すように、クライアント１０５とサーバ１５０は共に、ＭＡＰＩメールアプリケーション１１０、１５５のインスタンスがそれぞれインストールされ、あるいは、それぞれを含んでいる。図を簡略化するために、ＭＡＰＩメールアプリケーション１１０、１５５のインスタンスを共に、同じメール交換サーバ１４５を使用して図示されていることに留意されたい。しかし、分散システム１００全体で使用される他のメール交換サーバ１４５とすることも可能である。本発明を用いる唯一の必要条件は、クライアント１０５上のＭＡＰＩメールアプリケーション１１０のインスタンスが、サーバ１５０上のＭＡＰＩメールアプリケーション１５５のインスタンスとメールメッセージを交換（送信および受信）できる能力を有することである。

図１の実施例では、クライアント１０５は、ウェブサービス１６５と通話するように構成されたカスタムアプリケーションであるウェブサービスアプリケーション１３０を動作させる。同様に、サーバ１５０は、ウェブサービス１６５をホストし、動作させる。しかし、このアプリケーションの場合、用語「ウェブサービスアプリケーション」は、その他の形で明示的に特定されない限り、クライアントのウェブサービスアプリケーション１３０と、サーバ側ウェブサービス１６５を共に含むように広く解釈されるべきであることに留意されたい。さらに、クライアントのウェブサービスアプリケーション１３０と、ウェブサービス１６５は共に、クライアント側のカスタムレイヤ化トランスポート１１５およびサーバ側のカスタムレイヤ化トランスポート１６０を用いて、それぞれ、ＭＡＰＩアプリケーション１１０、１５５にバインドされる。以下により詳細に述べるように、これらのレイヤ化トランスポート１１５、１６０は共に、ウェブサービスアプリケーション１３０、１６５と、それに対応するＭＡＰＩメールアプリケーション１１０、１５５との間でメッセージを通信するために使用されるいくつかのレイヤ化されたインターフェースを有することができる。

以下で、クライアント１０５とサーバ１５０の間における要求／応答メッセージ交換パターンの簡単な概観を示す。しかし、他のメッセージ交換パターンも本発明に利用可能であることに留意されたい。したがって、図１Ａおよび他の図の例示的な諸実施形態の説明における要求／応答メッセージ交換パターンの使用は、説明のために過ぎないが、明示的に特許請求されない限り、本発明の範囲を制限し、あるいはその他の方法で狭くすることを意図するものではない。

この実施例では、クライアントのウェブサービスアプリケーション１３０は、サーバ１５０のＭＡＰＩメールアプリケーション１５５によって使用されるメールアドレスのロケーションを指定する（以下でより詳細に説明するように）カスタムアドレッシング方式を含むウェブサービス要求１２０を作成する。クライアント側レイヤトランスポート１１５を用いて、ウェブサービス要求メッセージ１２０を、１つまたは複数の直接ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅｓ）を介してＭＡＰＩメールアプリケーション１１０に転送することができ、それを以下で述べる。ＭＡＰＩメールアプリケーション１１０は、その要求１２０に対して発信メールメッセージ１３５を作成し、その発信メールメッセージ１３５を、ＭＡＰＩメールアプリケーション１１０の発信メールボックス（図示せず）に入れる。発信メールメッセージ１３５は、送信されるかあるいは発信ボックスに保存されるが、発信ボックス中にメールメッセージ１３５を入れる他のプロセスもまた、本発明に利用可能であることに留意されたい。例えば、メールメッセージ１３５を発信メールボックス内で直接作成することもできる。したがって、メールメッセージ１３５（ならびにここに記載の他のメールメッセージ）を送信しまたは保存することは、発信メールボックス内にメールメッセージを置き、または作成する任意の周知の方法を含むように広く解釈すべきである。

いずれにしても、発信メールメッセージは、ウェブサービス１６５のＭＡＰＩメールアプリケーション１５５にバインドされるメールアドレスと、ウェブサービス要求１２０メッセージと、ウェブサービス１６５およびそのウェブサービスメッセージ（すなわち、この実施例では要求１２０）に対するメール交換タイプを識別するための識別子とを含むことができる。ＭＡＰＩメールアプリケーション１１０が適切なメール交換サーバ１４５に接続されると、発信メールメッセージ１３５は、着信メールメッセージ１３５としてサーバ１５０のＭＡＰＩメールアプリケーション１５５に送信される。通常、この着信メールメッセージ１３５は、プレーンテキストのＳＯＡＰエンベロープである。しかし、本発明は、交換されたメールメッセージに対して何らかの特定のカプセル化および／またはフォーマット化に限定するものではないことに留意されたい。したがって、メールメッセージ１３５、１４０を転送するためにＳＯＡＰエンベロープおよびプレーンテキストを使用することは、説明のために過ぎないが、明示的に特許請求されない限り、本発明の範囲を制限しあるいはその他の形で狭くすることを意図するものではない。

着信メールメッセージ１３５がＭＡＰＩメールアプリケーション１５５に到着すると、それを、ＭＡＰＩメールアプリケーション１５５の着信メールボックスに送信することができる。着信メールメッセージ１３５内の識別子により、サーバ側レイヤ化トランスポート１６０は、着信メールメッセージ１３５が要求１２０を含んでいると識別し、それを処理のため関連するウェブサービス１６５に渡す。識別子は、着信メールメッセージ１３５が要求１２０を含んでいることを識別するために使用されるが、例示的な諸実施形態はまた、メッセージが要求１２０を含んでいることを識別するための他の方法も備えることに留意されたい。例えば、メッセージは、フィルタリングプロセスを介して識別することができるが、その場合、ＭＡＰＩメールアプリケーション１５５は、着信メールメッセージ１３５中の件名（ｓｕｂｊｅｃｔ ｍａｔｔｅｒ）を要求として識別することができる。このような場合、サーバ開発者によって設定された様々なルールを使用して、それを特定のフォルダへとフィルタリングすることができる。したがって、サーバ側レイヤトランスポート１６０は、フィルタリングされたフォルダ内のメッセージを見ると、自動的に、着信メールメッセージ１３５が要求１２０を含んでいるものと推定し、その要求１２０を処理のためにウェブサービス１６５に送信することができる。したがって、以下でより詳細に説明するように、着信メールメッセージ１３５内の要求１２０（または他のタイプのウェブサービスッセージ）を識別するための用語「識別子」の使用は、メッセージが特定のコンテンツを含んでいることを識別する他の周知の方法を含むように広く解釈されるべきである。

いずれにしても、要求メッセージ１２０のウェブサービス１６５へのハンドオフが成功すると、サーバ１５０のＭＡＰＩメールアプリケーション１５５の着信ボックスから（例えば、削除済みアイテムフォルダに移して）着信メールメッセージ１３５を削除することができる。それが一方向のメッセージ交換パターンであれば、処理はここで終了することになる。しかし、この実施例では、ウェブサービス１６５は、上記に説明した内容と同様、応答１２５を送信することができる。

具体的には、ウェブサービス１６５は、応答１２５を構成し、サーバ側レイヤ化トランスポート１６０を使用してその応答をＭＡＰＩメールアプリケーション１５５に渡す。次いで、ＭＡＰＩメールアプリケーション１５５は、クライアント１０５のメーリングアドレス（またはその他の形でクライアントに対応するアドレス）と、ウェブサービス応答１２５と、ウェブサービス１６５およびメール交換タイプ、すなわち応答１２５を識別するための識別子とを含む発信メールメッセージ１４０を構成する。発信メールメッセージ１４０は、次いで、サーバ１５０上の発信メールボックス（図示せず）に保存され、それにサーバ１５０が接続されたときメール交換サーバ１４５に送信される。クライアントがそのメール交換サーバ１４５に接続されると、発信メールメッセージ１４０は着信メールメッセージ１４０として、クライアント１０５側のＭＡＰＩメールアプリケーション１１０のインスタンスに送信される。次いで、クライアント側レイヤ化トランスポート１１５は、（サーバ１５０に関して前に説明したプロセスと同様に）着信メールメッセージ１４０が応答１２５を含んでいることを認識し、処理のためそれをクライアントウェブサービスアプリケーション１３０に渡す。

図２は、ウェブサービス１６５またはウェブサービスアプリケーション１３０をその対応するＭＡＰＩメールアプリケーション１５５、１１０にバインドするためのレイヤ化トランスポート１１５、１６０のより詳細な実施例を示す。図に示すように、ウェブサービスエンジン２２５（例えば、ＷＳＥ（Ｗｅｂ Ｓｅｒｖｉｃｅ Ｅｎｈａｎｃｅｍｅｎｔ））は、カスタムレイヤ化トランスポート２３０内の様々なカスタムＡＰＩ２１０、２１５、２２０を利用する。これらのＡＰＩ２１０、２１５、２２０は、別々のインターフェースとして図示されているが、その機能を組み合わせて単一のアプリケーションプログラミングインターフェースを形成できることに留意されたい。したがって、この別々のインターフェースおよびその機能の使用は、説明のために過ぎないが、明示的に特許請求されない限り、本発明の範囲を制限しまたは他の形で狭くすることを意図するものではない。

そうではあるが、図２のように、カスタムレイヤトランスポート２３０は、３つのエレメントからなり、カスタムトランスポートインターフェース２２０、マネージドＭＡＰＩ機能２１５、および拡張ＭＡＰＩ機能２１０を含む。カスタムトランスポートレイヤ２３０は、ウェブサービスエンジン２２５トランスポートに必要な様々のインターフェースおよびプロセスを実施する。そのレイヤ２２０は、（以下でより詳細に説明する）アドレッシング方式、およびトランスポートのためのイベントを処理する（例えば、新しいメッセージが到着した場合のどのようにすべきかなど）プロセスと共に、使用されるチャネルの概要を示す。このカスタムトランスポートインターフェース２２０はまた、開発者が、メールメッセージをウェブサービスに送信し、サービスと共に働くことになるクライアントを設計し構築するためのＮＰＤＬ文書を要求できるように、ＮＰＤＬ文書（例えば、ＷＳＤＬ文書）の生成をサポートする。そのプロセスおよびこのようなＮＰＤＬ文書を要求するためのアドレッシング方式は、図１Ｂに関して以下でより詳細に説明する。

マネージドＭＡＰＩ機能２１５レイヤは、ウェブサービス要求を、（通常、ＳＯＡＰエンベロープとして知られる）ウェブサービスエンジン２２５形式からメールメッセージに変換するのに使用される。そのレイヤ２１５の機能の一部は、紛らわしいメールアドレスを正しく処理するように、アドレッシングを正しく処理することである。そのレイヤ２１５は、マネージド（．Ｎｅｔ）コードで開発することができ、したがってこの名前がついている。

例えば、様々なＭＡＰＩメールアプリケーション２０５内のセキュリティモデルに起因して、マネージドレイヤ２１５が実施できないいくつかの機能があり得る。それらの機能には、存在するメールメッセージに対するメールアドレスおよび本文テキストを取得することが含まれる可能性がある。したがって、それを克服するために、例示的な諸実施形態は、ＭＡＰＩメールアプリケーション１０５と対話するいくつかの機能を実施するように構成された拡張ＭＡＰＩ機能２１０レイヤを備える。この拡張ＭＡＰＩ機能２１０レイヤは、ＭＡＰＩメールアプリケーション２０５の一部として装備されていても良い。

前に述べたように、本発明は、ウェブサービスメッセージ（例えば、要求、応答）を送信するためにＭＡＰＩ準拠メールアプリケーションの使用していることを識別するため、カスタムアドレッシング方式を使用する。アドレッシング方式の以下の説明では、エンドポイントメーリングアドレスを識別し、かつウェブサービスメッセージがＭＡＰＩ準拠メールアプリケーションを用いて交換されることを識別するために特定の形式を使用しているが、これらの機能を識別する他の周知の方法を本発明に適用可能であることにも留意されたい。したがって、以下のアドレッシング方式および本明細書に記載の他の識別子は、説明のために過ぎないが、明示的に特許請求されない限り、本発明の範囲を制限しあるいはその他の形で狭くすることを意図するものではない。

例示的な諸実施形態による例示のアドレッシング方式は、典型的なＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）のモデリングに類似したものである。例えば、１つのＵＲＬは、トランスポート（例えば、「ｈｔｔｐ：／／」）、ホスト名（例えば、「ｗｗｗ．ｃｏｍｐａｎｙｎａｍｅ．ｃｏｍ」）、および要求されたページ（例えば、「／ｂｉｚｔａｌｋ／ｄｅｆａｕｌｔ．ａｓｐｘ」）を含むいくつかの異なる部分から構成される。ＨＴＴＰトランスポートを介して動作するウェブサービスも、同様の規定に従う。例えば、アドレスが、http://myserver/services/service1.asmxであるとすると、トランスポートはやはり「ｈｔｔｐ：／／」であり、「ｍｙｓｅｒｖｅｒ」はホスト名であり、また「／ｓｅｒｖｉｃｅｓ／ｓｅｒｖｉｃｅ１．ａｓｍｘ」は要求されているウェブサービスを識別する。

本発明の例示的な諸実施形態は、ＭＡＰＩメールアプリケーション識別子のために同様のアドレッシング方式を使用する。例えば、アドレッシング方式が、soap.mapimailapplicationname://to/sguest@company.comである場合、以下のように分離される。すなわち、「ｓｏａｐ．ｍａｐｉｍａｉｌａｐｐｌｉｃａｔｉｏｎｎａｍｅ：／／」は使用するトランスポートを定義し、「ｔｏ」はホスト名（ＵＲＩネーミング規定に従うために使用されるが、通常、設計で無視される）であり、「／ｓｇｕｅｓｔ＠ｃｏｍｐａｎｙ．ｃｏｍ」は（それが要求、応答か、それとも他のタイプのメッセージ交換かどうかに応じて）ウェブサービスまたはクライアントの電子メールアドレスである。

また、上記フォーマットを使用することにより、電子メールが複数の受信者にアドレス指定可能であるのと同じように、トランスポートを複数のサービスにアドレス指定することが可能になる。それは、ＵＲＬに対してアドレスを付加し、例えば、soap.mapimailapplication://to/squest@company.com；account@company.comとすることにより実施することができる。それは、ｓｑｕｅｓｔ＠ｃｏｍｐａｎｙ．ｃｏｍおよびａｃｃｏｕｎｔｓ＠ｃｏｍｐａｎｙ．ｃｏｍの両方で動作するサービスに対する要求にアドレス指定する。

アドレッシング方式は、ウェブサービスの名前を含まなくてもよいことに留意されたい。その代わり、例示的な実施形態は、ウェブサービスの名前（または、サービスや、そのような割り当てられたコードを識別するための他の手段）およびメッセージ交換タイプを識別子中に挿入する。識別子は、例えば、メールメッセージの件名などの特有のフィールド中に挿入することができる。その識別子のフォーマットは以下のようにすることができる。すなわち、サービスを求める要求を識別する＜ｓｅｒｖｉｃｅｎａｍｅ＞ｒｅｑｕｅｓｔ、前の要求に対する応答を識別する＜ｓｅｒｖｉｃｅｎａｍｅ＞ｒｅｑｕｅｓｔｒｅｓｐｏｎｓｅである。要求および／または応答を識別するために、特有のフォーマットが使用されているが、メッセージ交換パターンを識別する他の方法も本発明に利用可能であることことに留意されたい。例えば、要求（ｒｅｑｕｅｓｔ）に対して、略語「ｒｅｑ」を使用することができ、一方、応答（ｒｅｓｐｏｎｓｅ）に対して、「ｒｅｓｐ」を使用することができる。したがって、その識別子内に現れるメッセージ交換パターンおよびフォーマットを識別するための上記実施例は、説明のために過ぎないが、明示的に特許請求されない限り、本発明の範囲を制限しあるいはその他の形で狭くすることを意図するものではない。

前に説明したように、例示的な実施形態はまた、ウェブサービス１６５と互換性を持って通信可能な要求１２０を作成するために、ＮＰＤＬ文書（例えば、ＷＳＤＬ文書）を要求することおよび受信することを含む。理解されるように、このようなＮＰＤＬデータ構造は、ウェブサービスアプリケーション１６５とメッセージを交換するとき、クライアントウェブサービスアプリケーション１３０が準拠する１つまたは複数のコントラクトを記述するための仕様を与える。

図１Ｂは、例示的な実施形態に従って、開発者（図示せず）またはアプリケーションが、ＮＰＤＬデータ構造１８５を要求し受信できる分散システム１００を示す。図に示すように、開発者またはアプリケーションは、クライアント１０５上で動作しているＭＡＰＩメールアプリケーション１１０を使用して、ウェブサービス１６５に対してＮＰＤＬ１７５を求める要求であるメールメッセージ１９０を作成することができる。要求１９０は、メール交換サーバ１４５を介してサーバ１５０のＭＡＰＩメールアプリケーション１５５着信メールボックスに送信される。要求１９０は、ウェブサービス１６５、およびＮＰＤＬ文書を求める要求である要求のタイプを識別するための識別子を含むべきである。このような識別子は、要求１９０の件名または何らかの他のフィールド中に含めることができる。例えば、メッセージ１９０がそのウェブサービス１６５に対応するＮＰＤＬ文書を求める要求であることを識別する、識別子「＜ｓｅｒｖｉｃｅｎａｍｅ＞？ＷＳＤＬ」を、要求メッセージ１９０の件名中に含めることができる。しかし、サービスおよび／またはＮＰＤＬを求める要求を識別する他の方法も本発明に適用可能であることを再度留意されたい。したがって、メッセージ１９０に含まれる識別子の上記識別位置および識別子の特有の形式は、説明のために過ぎないが、明示的に特許請求されない限り、本発明の範囲を制限しあるいはその他の形で狭くすることを意図するものではない。

ウェブサービスエンジン１７０は、識別子により要求メールメッセージ１９０を識別し、それを使用してＮＰＤＬデータ構造１７５を生成することができ、次いで、それを、例えば、メールメッセージ応答１８５中でクライアントに送信することができる。図１ＢのＮＰＤＬデータ構造１７５はストア１８０から取り出されるが、他の例示的な実施形態は、ウェブサービスエンジン１７０に動的に直ちに（ｏｎ−ｔｈｅ−ｆｌｙ）それを生成できるようにすることを含むことも留意されたい。さらに、その実施例では、ＮＰＤＬデータ構造が応答メールメッセージ１８５中で送信されるが、ＮＰＤＬデータ構造は、他のトランスポートを用いて送信できることも留意されたい。例えば、要求１９０は、ＮＰＤＬデータ構造を使用するために異なるトランスポートを指定し、かつ／またはＮＰＤＬデータ構造を送信するために異なるアドレスを指定することができる。したがって、ＮＰＤＬデータ構造の作成方法、およびＮＰＤＬデータ構造１８５を返すためのメールメッセージの使用は、説明のために過ぎないが、明示的に特許請求されない限り、本発明の範囲を制限しあるいはその他の形で狭くすることを意図するものではない。

ウェブサービスエンジン１７０は、ウェブサービス１６５にアクセスまたは要求せずに、ストア１８０から、または他の手段によってＮＰＤＬ１７５を動的に生成しまたは取得することができるので、本実施形態がいくつかの有利な特徴を持っていることに留意されたい。例えば、ウェブサービス１６５は、このプロセス中にアクセスされないので、ウェブサービス１６５のリソースを他の要求を処理するために利用することができる。ＮＰＤＬデータ構造を取得するためのこの例示的な実施形態はまた、ＭＡＰＩメールアプリケーション１１０が要求１９０のために使用されるため、オフライン環境中でこのような要求が可能になるという利点をさらに持っている。具体的には、要求１９０を、まず、オフライン環境中のＭＡＰＩアプリケーション１１０の発信メールボックスに送信し、次いで、メール交換サーバ１４５への接続が利用可能になったとき、要求１９０をサーバ１４５、１５０に送信することができる。

本発明はまた、機能的なステップおよび／または非機能的な行為（ａｃｔｓ）を含む方法によって記述することができる。以下に示すのは、本発明の実施において実行できる諸ステップおよび／または行為の記述である。通常、機能的な諸ステップは、達成された結果の点から本発明を記述し、一方、非機能的な行為は、特定の結果を達成するためのより特定のアクションを記述する。機能的な諸ステップおよび／または非機能的な行為は、特定の順序で記述されまたは特許請求され得るが、本発明は、諸ステップおよび／または行為の特定の順序付けまたは組合せに必ずしも限定しない。さらに、特許請求の範囲の列挙において、また、図３〜図５に対するフロー図の以下の説明において、諸ステップおよび／または行為の使用は、このような用語の望ましい特定の使用を示すように使用するものとする。

図３〜図５は、本発明の様々な例示の実施形態に対するフロー図を示す。図３〜図５の以下の説明は、図１Ａ、図１Ｂ、および図２の対応する要素を時々参照する。これらの図から特定の要素を参照することができるが、このような要素は、説明のために過ぎず、明示的に特許請求されない限り、本発明の範囲を制限しあるいはその他の形で狭くすることを意図するものではない。

図３は、オフライン通信をサポートし、かつサービス要求の処理時間を延長するために、ＭＡＰＩ準拠メールアプリケーションを利用することによって、このようなメッセージ交換のために追加のインフラストラクチャを形成することなしに、メールトランスポートを介してウェブサービスを提供する方法３００のためのフロー図を示す。方法３００は、ウェブサービスメッセージを受信する行為３０５を含む。例えば、クライアント側１１５またはサーバ側１６０レイヤ化トランスポートが、ウェブサービスメッセージが要求１２０か、それとも応答１２５かに応じて、ウェブサービスメッセージ１２０、１２５を受信することができる。ウェブサービスメッセージ１２０、１２５は、メールメッセージトランスポートを介して通信するクライアント１０５とウェブサービス１６５の間でのメッセージ交換パターンの一部として、ウェブサービスメッセージ１２０、１２５を送信するためにＭＡＰＩ準拠メールアプリケーション１１０、１５５の使用していることを識別するアドレッシング方式を含むべきである。ＭＡＰＩ準拠メールアプリケーションは、Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ（登録商標）、Ｏｕｔｌｏｏｋ Ｅｘｐｒｅｓｓ（登録商標）、Ｅｕｄｏｒａ（登録商標）などのうちの１つでよい。さらに、メールメッセージトランスポートは、ＳＭＴＰ、Ｈｏｔｍａｉｌ（商標）、Ｘ．２５、ＤＥＣ Ａｌｌ−Ｉｎ−１などのうちの１つとすることができる。

いずれにしても、方法３００はさらに、エンドポイントのメーリングアドレスを識別する行為３１０を含む。例えば、カスタムレイヤ化トランスポート２３０内の様々なレイヤ２１０、２１５、２２０を使用して、ウェブサービスメッセージ１２０、１２５を対応するエンドポイント１０５、１５０に送信するために、アドレッシング方式に含まれる（クライアント１０５またはサーバ１５０に対する）エンドポイントメーリングアドレスを識別することができる。方法３００はまた、ＭＡＰＩ準拠メールアプリケーションを用いてメールメッセージを生成する行為３１５を含む。例えば、ＭＡＰＩメールアプリケーション１１０、１５５は、発信メールメッセージ１３５、１４０を生成するのに使用することができる。そのメールメッセージは、エンドポイントメーリングアドレスと、ウェブサービスメッセージ１２０、１２５と、ウェブサービス１６５およびそのウェブサービスメッセージ１２０、１２５に対する（例えば、要求、応答などの）メッセージ交換タイプを識別するための識別子とを含むべきである。

方法３００はさらに、ＭＡＰＩ準拠メールアプリケーションの発信メールボックスにメールメッセージを送信する行為３２０を含む。例えば、カスタムレイヤ化トランスポート２３０は、メールメッセージトランスポートを介してエンドポイント１０５、１５０に後で送達するために、メールメッセージ１３５、１４０を、ＭＡＰＩメールアプリケーション１１０、１５５の発信メールボックスに送信することができる。前に述べたように、カスタムレイヤ化トランスポート２３０中の１つまたは複数のＡＰＩ２１０、２１５、２２０を使用してメールメッセージ１３５、１４０を生成し、ＭＡＰＩ準拠メールアプリケーション１１０、１５５の発信メールボックスにメールメッセージ１３５、１４０を送信することもできる。

他の例示的な実施形態は、ウェブサービスメッセージ１２０、１２５がクライアント１０５からの要求メッセージ１２０であり、エンドポイントがウェブサービス１６５であることを含む。この例示の実施形態では、メールメッセージ１３５がエンドポイント１６５メーリングアドレスに送信される。次いで、他のメールメッセージ１４０がＭＡＰＩ準拠メールアプリケーション１１０の着信メールボックスで受信される。そのメールメッセージ１４０は、クライアント１０５に対するメーリングアドレスと、要求１２０に対するウェブサービス応答１２５と、ウェブサービス１６５およびメールメッセージ１４０がウェブサービス応答１２５を含むことを示しているメッセージ交換タイプを識別するための識別子とを含む。その後、ウェブサービス応答１２５を、さらに処理するためにクライアントのウェブサービスアプリケーション１３０に送信することができる。

図４は、ＭＡＰＩ準拠メールアプリケーションを利用することにより、メールトランスポートを介してウェブサービスを提供する方法４００のフロー図を示す。この例示的な実施形態では、方法４００はメールメッセージトランスポートを介してメールメッセージを受信する行為４０５を含む。例えば、クライアント１０５またはサーバ１５０は、エンドポイント１０５、１５０ウェブサービスアプリケーション１３０、１６５に対応するＭＡＰＩ準拠メールアプリケーション１１０、１５５の着信メールボックスにおいて、メールメッセージトランスポートを介してメールメッセージ１３５、１４０を受信することができる。その後、方法４００は、メールメッセージがエンドポイントメールアドレスと、ウェブサービスメッセージと、識別子とを含むことを識別する行為４１０を含む。例えば、カスタムレイヤトランスポート１１５、１６０を使用することにより、メールメッセージ１３５、１４０は、ＭＡＰＩ準拠メールアプリケーション１１０、１５５に対応するエンドポイント１０５、１５０メーリングアドレスと、クライアント１０５／ウェブサービス１６５の間におけるメッセージ交換パターンの一部であるウェブサービスメッセージ１２０、１２５と、ウェブサービス１６５およびそのウェブサービスメッセージ１２０、１２５に対する（例えば、要求、応答などの）メール交換タイプを識別する識別子とを含むことを識別することができる。

ウェブサービスおよびそのウェブサービスメッセージに対するメール交換タイプに基づき、方法４００はまた、ウェブサービスメッセージをエンドポイントウェブサービスアプリケーションに送信する行為４１５を含む。例えば、カスタムレイヤトランスポート２１０、２１５、２２０内の様々なＡＰＩを用いて、メールメッセージにウェブサービスメッセージ１２０、１２５が含まれていることを識別した後、ウェブサービスメッセージ１２０、１２５は、処理のために適切なサービスアプリケーション１３０、１６５に送信することができる。

他の例示的な実施形態は、方法４００のウェブサービスメッセージ１２０、１２５がクライアント１０５からの要求１２０であり、エンドポイントがウェブサービス１６５であることを含む。その実施形態では、もう一方のウェブサービスメッセージを要求１２０への応答１２５として識別するアドレッシング方式を含む他のウェブサービスメッセージ１２５を受信することができる。次いで、応答メッセージ１２５をクライアント１０５のＭＡＰＩメールアプリケーション１１０に送信するために、アドレッシング方式に含まれるクライアント１０５のメールアドレスを識別することができる。次いで、ＭＡＰＩ準拠メールアプリケーション１５５を用いて、他のメールメッセージ１４０が生成され、そのメッセージは、クライアント１０５のメーリングアドレスと、応答メッセージ１２５と、ウェブサービス１６５およびそのウェブサービスメッセージタイプが応答１２５であることを識別するための識別子とを含む。次いで、メールメッセージトランスポートを介してクライアント１０５に後で送達をするために、メールメッセージ１４０は、ＭＡＰＩメールアプリケーション１５５の発信メールボックスに送信される。

図５は、オフライン通信をサポートし、かつＮＰＤＬデータ構造を生成するために、ＭＡＰＩメールアプリケーションを利用して、ウェブサービスアプリケーションにアクセスすることを必要とせずに、メールトランスポートを介してウェブサービスアプリケーションに対するＮＰＤＬを提供する方法５００のフロー図を示す。方法５００は、エンドポイントからメールメッセージを受信する行為５０５を含む。例えば、図１Ｂを参照すると、ＮＰＤＬ要求１９０を（クライアント１０５から）ウェブサービスアプリケーション１６５に関連付けられたＭＡＰＩメールアプリケーション１５５により受信することができる。さらに、方法５００は、メールメッセージがＮＰＤＬデータ構造を要求していることを識別する行為５１０を含む。例えば、ＮＰＤＬ要求１９０が、ウェブサービスアプリケーション１３０、１６５とエンドポイント１０５がメッセージを交換するときに準拠する１つまたは複数のコントラクトを記述するための仕様であるＮＰＤＬデータ構造を求める要求であることを識別するために、ウェブサービスエンジン１７０を使用することができる。

方法５００はさらに、ＮＰＤＬデータ構造を自動的に生成する行為５１５を含む。例えば、ウェブサービスエンジン１７０は、ウェブサービス１６５に対するＮＰＤＬ１７５をストア１８０から取り出すことができ、あるいはウェブサービスアプリケーション１６５にアクセスせずにＮＰＤＬデータ構造１７５を自動的に生成することができる。その後、方法５００は、ＮＰＤＬデータ構造をクライアントに送信する行為５２０を含む。例えば、ウェブサービスエンジン１７０は、メールメッセージトランスポートを介して、応答メッセージ１８５中でＮＰＤＬデータ構造を送信することができる。この実施形態では、ＭＡＰＩ準拠メールアプリケーション１５５を用いて、他のメールメッセージ１８５を生成することができる。メールメッセージ１８５は、ＮＰＤＬデータ構造と、クライアント１０５のＭＡＰＩ準拠メールアプリケーション１１０に対するメーリングアドレスと、メールメッセージ１８５がＮＰＤＬデータ構造を含んでいることを識別するための識別子とを含む。その後、クライアント１０５のＭＡＰＩ準拠メールアプリケーション１１０に後で送達するために、メールメッセージ１８５をサーバ１５０のＭＡＰＩ準拠メールアプリケーション１５５の発信メールボックスに送信することができる。

ＮＰＤＬはＷＳＤＬであり、ＮＰＤＬデータ構造をＸＭＬ文書とすることができる。さらに、メールメッセージ１９０は、メールメッセージの件名フィールド中に識別子を含むことにより、ＮＰＤＬデータ構造１７５を要求していることが識別可能である。さらに、識別子は、ウェブサービスアプリケーション１６５に対する名前を含むこともできる。

本発明の範囲に含まれる諸実施形態はまた、その上に記憶されたコンピュータ実行可能命令またはデータ構造を有する、または搬送するためのコンピュータ読取り可能媒体を含む。このようなコンピュータ読取り可能媒体は、汎用または専用コンピュータによってアクセスできる任意の利用可能な媒体とすることができる。例として、それだけに限らないが、このようなコンピュータ読取り可能媒体は、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ、ＣＤ−ＲＯＭもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気記憶装置、あるいはコンピュータ実行可能命令またはデータ構造の形式で所望のプログラムコード手段を搬送または記憶するのに使用可能な、また汎用もしくは専用コンピュータによってアクセス可能な他の任意の媒体を含むことができる。情報がネットワークまたは他の通信接続（有線、無線、または有線もしくは無線の組合せ）を介して、コンピュータに転送もしくは提供された場合、コンピュータは、当然、その接続をコンピュータ読取り可能媒体として見なす。したがって、このような接続もコンピュータ読取り可能媒体と呼ばれるのは当然である。上記の組合せもまた、コンピュータ読取り可能媒体の範囲に含まれるべきである。コンピュータ実行可能命令は、例えば、汎用コンピュータ、専用コンピュータ、または専用処理装置がある種の機能もしくは一群の機能を実施できるようにする命令およびデータを含む。

図６および以下の議論は、本発明を実施できる適切なコンピューティング環境の簡単で一般的な説明を提供することを意図している。必ずしも必要なことではないが、本発明は、ネットワーク環境中のコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で記述される。一般に、プログラムモジュールは、特定のタスクまたは特定の抽象データ型を実行するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。コンピュータ実行可能命令、関連付けられたデータ構造、およびプログラムモジュールは、本明細書に開示の方法の諸ステップを実行するためのプログラムコード手段の諸実施例を表す。このような実行可能命令または関連付けられたデータ構造の特定のシーケンスは、このような諸ステップで記述される機能を実施するための対応する行為の実施例を表す。

当業者であれば、本発明は、パーソナルコンピュータ、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベースもしくはプログラム可能な家庭用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む多くのタイプのコンピュータシステムコンフィギュレーションを有するネットワークコンピューティング環境中で実施できることを理解されよう。本発明はまた、通信ネットワークを介して（有線リンク、無線リンク、または有線もしくは無線リンクの組合せによって）リンクされたローカルおよび遠隔の処理装置により、タスクが実施される分散コンピューティング環境中で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、ローカルと遠隔の両方のメモリ記憶装置中に位置することができる。

図６を参照すると、本発明を実施するための例示的なシステムは、処理装置６２１、システムメモリ６２２、およびシステムメモリ６２２を含む様々なシステムコンポーネントを処理装置６２１に結合するシステムバス６２３を含む従来のコンピュータ６２０の形式の汎用コンピューティング装置を含む。システムバス６２３は、メモリバスもしくはメモリ制御装置、周辺バス、および任意の様々なバスアーキテクチャを用いるローカルバスを含む任意のいくつかのタイプのバス構造とすることができる。システムメモリは、ＲＯＭ（読取り専用メモリ）６２４、およびＲＡＭ（ランダムアクセスメモリ）６２５を含む。起動中などに、コンピュータ６２０内の要素間で情報を転送できるようにする基本ルーチンを含むＢＩＯＳ（基本入出力システム）６２６を、ＲＯＭ６２４に記憶することができる。

コンピュータ６２０はまた、磁気ハードディスク６３９から読み取りまたは書き込む磁気ハードディスクドライブ６２７と、取外し可能磁気ディスク６２９から読み取りまたは書き込む磁気ディスクドライブ６２８と、ＣＤ−ＲＯＭもしくは他の光媒体などの取外し可能光ディスク６３１から読み取りまたは書き込む光ディスクドライブ６３０とを含むことができる。磁気ハードディスクドライブ６２７、磁気ディスクドライブ６２８、および光ディスクドライブ６３０は、ハードディスクドライブインターフェース６３２、磁気ディスクドライブインターフェース６３３、および光ドライブインターフェース６３４によって、それぞれ、システムバス６２３に接続されている。ドライブおよびそれに関連付けられたコンピュータ読取り可能媒体は、コンピュータ実行可能命令、データ構造、プログラムモジュール、およびコンピュータ６２０に対する他のデータの不揮発性ストレージを提供する。本明細書に記載の例示的な環境は、磁気ハードディスク６３９、取外し可能磁気ディスク６２９、および取外し可能光ディスク６３１を使用するが、磁気カセット、フラッシュメモリカード、ＤＶＤ、ベルヌーイカートリッジ、ＲＡＭ、ＲＯＭなどを含む、データを記憶する他のタイプのコンピュータ読取り可能媒体を使用することもできる。

オペレーティングシステム６３５、１つまたは複数のアプリケーションプログラム６３６、他のプログラムモジュール６３７、およびプログラムデータ６３８を含む１つまたは複数のプログラムモジュールを含むプログラムコード手段は、ハードディスク６３９、磁気ディスク６２９、光ディスク６３１、ＲＯＭ６２４もしくはＲＡＭ６２５上に記憶することができる。ユーザは、キーボード６４０、ポインティング装置６４２、またはマイクロフォン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどの他の入力装置（図示せず）を介してコンピュータ６２０にコマンドおよび情報を入力することができる。これらのおよび他の入力装置は、システムバス６２３に結合されたシリアルポートインターフェース６４６を介して処理装置６２１に接続されることが多い。あるいは、入力装置は、パラレルポート、ゲームポート、またはＵＳＢなどの他のインターフェースによって接続することもできる。モニタ６４７または他の表示装置はまた、ビデオアダプタ６４８などのインターフェースを介してシステムバス６２３に接続されている。モニタに加えて、パーソナルコンピュータは、通常、スピーカおよびプリンタなどの他の周辺出力装置（図示せず）を含む。

コンピュータ６２０は、遠隔コンピュータ６４９ａおよび６４９ｂなど１つまたは複数の遠隔コンピュータへの論理接続を用いてネットワーク化された環境中で動作することができる。遠隔コンピュータ６４９ａおよび６４９ｂは、それぞれ別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置もしくは他の共通のネットワークノードとすることができ、また図６では、メモリ記憶装置６５０ａ、６５０ｂおよびそれに関連付けられたアプリケーションプログラム６３６ａ、６３６ｂだけが示されているが、通常、コンピュータ６２０に関する上記の多くのまたはすべての要素を含むことができる。図６に示された論理接続は、限定するのではなく、例としてここに提示したＬＡＮ（ローカルエリアネットワーク）６５１、およびＷＡＮ（広域ネットワーク）６５２を含む。このようなネットワーク化された環境は、オフィス規模、または企業規模のコンピュータネットワーク、イントラネット、およびインターネットにおいて普通のものである。

ＬＡＮネットワーク化環境で使用した場合、コンピュータ６２０は、ネットワークインターフェースまたはアダプタ６５３を介してローカルネットワーク６５１に接続される。ＷＡＮネットワーク化環境で使用した場合、コンピュータ６２０は、モデム６５４、無線リンク、またはインターネットなどの広域ネットワーク６５２を介して通信を確立する他の手段を含むことができる。モデム６５４は、内蔵または外付けのものとすることができるが、シリアルポートインターフェース６４６を介してシステムバス６２３に接続されている。ネットワーク化された環境では、コンピュータ６２０に関して示したプログラムモジュール、またはその部分を、遠隔のメモリ記憶装置に記憶することができる。図示されたネットワーク接続は例示的なものであり、広域ネットワーク６５２を介して通信を確立する他の手段を使用できることも理解されたい。

本発明は、その趣旨または本質的な特性から逸脱することなく、他の特定の形態で実施することもできる。上記の諸実施形態は、すべての点において説明のためだけのものであり、限定するものではないと見なすべきである。したがって、本発明の範囲は上記の説明によるのではなく、添付の特許請求の範囲によって示される。特許請求の範囲の均等な意味および範囲に含まれる変更はすべて、その範囲に含まれるものとする。

本発明の例示的な諸実施形態によるクライアントとウェブサービスの間でメッセージを交換するためのＭＡＰＩメールアプリケーションを利用する分散システムを示す図である。 本発明の例示的な諸実施形態によるＭＡＰＩメールアプリケーションを使用したＮＰＤＬ文書を要求するための分散システムを示す図である。 本発明の例示的な諸実施形態によるウェブサービスエンジンとＭＡＰＩメールアプリケーションの間で通信するためのトランスポート内の例示的なインターフェースのレイヤ化を示す図である。 本発明の例示的な諸実施形態によるメールトランスポートを介してウェブサービスを提供する方法のフロー図である。 本発明の例示的な諸実施形態によるメールトランスポートを介してウェブサービスを提供する方法の他のフロー図である。 本発明の例示的な諸実施形態によるメールトランスポートのウェブサービスアプリケーションに対するＮＰＤＬデータ構造を提供する方法のフロー図である。 本発明のために適切な動作環境を提供する例示的システムを示す図である。

符号の説明

１０５ クライアント
１１０、１５５ ＭＡＰＩメールアプリケーション
１５０ サーバ
６２７ 磁気ハードディスクドライブ
６２８ 磁気ディスクドライブ
６３０ 光ディスクドライブ

Claims (20)

1. 分散環境中のコンピューティングシステムにおいて、オフライン通信および延長されたサービス要求処理時間をサポートするために、ＭＡＰＩ（Ｍｅｓｓａｇｉｎｇ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）準拠メールアプリケーションを利用することによって、このようなメッセージ交換のための追加のインフラストラクチャを形成することなく、メールトランスポートを介してウェブサービスを提供する方法であって、
   メールメッセージトランスポートを介して通信するクライアントとウェブサービスの間におけるメッセージ交換パターンの一部としてウェブサービスメッセージを送信するために、ＭＡＰＩ準拠メールアプリケーションを使用していることを識別するアドレッシング方式を含む前記ウェブサービスメッセージを受信する行為（ａｃｔ）と、
   前記ウェブサービスメッセージを対応するエンドポイントに送信するために、前記アドレッシング方式に含まれるエンドポイントメーリングアドレスを識別する行為と、
   前記ＭＡＰＩ準拠メールアプリケーションを用いてメールメッセージを生成する行為であって、前記メールメッセージは、前記エンドポイントメーリングアドレス、前記ウェブサービスメッセージ、並びに前記ウェブサービスおよび前記ウェブサービスメッセージに対するメッセージ交換タイプを識別するための識別子を含むことと、
   前記メールメッセージトランスポートを介して前記エンドポイントに引き続き後で送達するために、前記ＭＡＰＩ準拠メールアプリケーションの発信メールボックスに前記メールメッセージを送信する行為と、
   を備えることを特徴とする方法。
2. 前記識別子は、前記メールメッセージの件名フィールド中に含まれていることを特徴とする請求項１に記載の方法。
3. 前記メールメッセージトランスポートは、ＳＭＴＰ、Ｈｏｔｍａｉｌ、Ｘ．２５、またはＤＥＣ Ａｌｌ−Ｉｎ−１から選択されることを特徴とする請求項１に記載の方法。
4. 前記ウェブサービスメッセージは、前記クライアントからの要求メッセージであり、または前記ウェブサービスからの応答メッセージであることを特徴とする請求項１に記載の方法。
5. 前記ウェブサービスメッセージは前記クライアントからの要求メッセージであり、また前記エンドポイントは前記ウェブサービスであり、前記方法は、
   前記メールメッセージを前記エンドポイントメーリングアドレスに送信する行為と、
   前記ＭＡＰＩ準拠メールアプリケーションの着信メールボックスにおいて、もう１つのメールメッセージを受信する行為であって、前記もう１つのメールメッセージは、前記クライアントに対するメーリングアドレス、前記要求メッセージに対するウェブサービス応答、並びに前記ウェブサービスの名前および前記他のメールメッセージが前記ウェブサービス応答を含むことを示しているメッセージ交換タイプを識別するための識別子を含むことと、
   さらに処理するために、前記ウェブサービス応答を前記クライアントのウェブサービスアプリケーションに送信する行為と、
   をさらに備えることを特徴とする請求項１に記載の方法。
6. １つまたは複数のＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅｓ）をまた、前記メールメッセージを生成し、前記メールメッセージを前記ＭＡＰＩ準拠メールアプリケーションの前記発信メールボックスに送信するのに使用することを特徴とする請求項１に記載の方法。
7. 前記ＭＡＰＩ準拠メールアプリケーションは、Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ、Ｏｕｔｌｏｏｋ Ｅｘｐｒｅｓｓ、またはＥｕｄｏｒａのうちの１つであることを特徴とする請求項１に記載の方法。
8. 分散環境中のコンピューティングシステムにおいて、オフライン通信および延長されたサービス要求処理時間をサポートするために、ＭＡＰＩ（Ｍｅｓｓａｇｉｎｇ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）準拠メールアプリケーションを利用することによって、このようなメッセージ交換のために追加のインフラストラクチャを形成することなく、メールトランスポートを介してウェブサービスを提供する方法であって、
   エンドポイントウェブサービスアプリケーションに対応するＭＡＰＩ準拠メールアプリケーションの着信メールボックスにおいて、メールメッセージトランスポートを介してメールメッセージを受信する行為と、
   前記メールメッセージが、前記ＭＡＰＩ準拠メールアプリケーションに対応するエンドポイントメーリングアドレス、クライアントとウェブサービスの間におけるメッセージ交換パターンの一部であるウェブサービスメッセージ、並びに前記ウェブサービスおよび前記ウェブサービスメッセージに対するメッセージ交換タイプを識別するための識別子を含んでいることを識別する行為と、
   前記ウェブサービスおよび前記ウェブサービスメッセージに対する前記メッセージ交換タイプに基づいて、処理のために、前記ウェブサービスメッセージを前記エンドポイントウェブサービスアプリケーションに送信する行為と、
   を備えることを特徴とする方法。
9. メモリリソースの節約のために、前記ウェブサービスメッセージが前記ウェブサービスアプリケーションに送信された後、前記メールメッセージを削除する行為をさらに備えることを特徴とする請求項８に記載の方法。
10. 前記識別子は、前記メールメッセージの件名フィールド中に含まれていることを特徴とする請求項８に記載の方法。
11. 前記メールメッセージトランスポートは、ＳＭＴＰ、Ｈｏｔｍａｉｌ、Ｘ．２５、またはＤＥＣ Ａｌｌ−Ｉｎ−１から選択されることを特徴とする請求項８に記載の方法。
12. 前記ウェブサービスメッセージは、前記クライアントからの要求メッセージであり、または前記ウェブサービスからの応答メッセージであることを特徴とする請求項８に記載の方法。
13. 前記ウェブサービスメッセージは前記クライアントからの要求メッセージであり、また前記エンドポイントは前記ウェブサービスであり、前記方法は、
    前記他のウェブサービスメッセージを前記要求メッセージへの応答メッセージであると識別する他のアドレッシング方式を含む前記他のウェブサービスメッセージを受信する行為と、
    前記応答メッセージを前記クライアントのＭＡＰＩ準拠メールアプリケーションに送信するために前記他のアドレッシング方式に含まれる前記クライアントのメーリングアドレスを識別する行為と、
    前記ＭＡＰＩ準拠メールアプリケーションを用いて他のメールメッセージを生成する行為であって、前記メールメッセージは、前記クライアントのメーリングアドレス、前記応答メッセージ、並びに前記ウェブサービスおよび前記応答ウェブサービスメッセージが前記応答メッセージであることを識別するための他の識別子を含むことと、
    前記メールメッセージトランスポートを介して前記クライアントに引き続き後で送達するために、前記ＭＡＰＩ準拠メールアプリケーションの発信メールボックスに前記他のメールメッセージを送信する行為と、
    をさらに備えることを特徴とする請求項８に記載の方法。
14. １つまたは複数のＡＰＩをまた、前記メールメッセージを生成し、前記メールメッセージを前記ＭＡＰＩ準拠メールアプリケーションの前記発信メールボックスに送信するのに使用することを特徴とする請求項１３に記載の方法。
15. 前記ＭＡＰＩ準拠メールアプリケーションは、Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ、Ｏｕｔｌｏｏｋ Ｅｘｐｒｅｓｓ、またはＥｕｄｏｒａのうちの１つであることを特徴とする請求項８に記載の方法。
16. 分散環境中のコンピューティングシステムにおいて、オフライン通信をサポートし、かつＮＰＤＬ（Ｎｅｔｗｏｒｋ Ｐｒｏｔｏｃｏｌ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）データ構造を生成するために、ＭＡＰＩ（Ｍｅｓｓａｇｉｎｇ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）準拠メールアプリケーションを利用することによって、ウェブサービスアプリケーションにアクセスすることを必要とすることなく、メールトランスポートを介して前記ウェブサービスアプリケーションのためのＮＰＤＬを配布する方法であって、
    ウェブサービスアプリケーションに関連付けられたＭＡＰＩ準拠メールアプリケーションの着信メールボックスにおいて、エンドポイントからメールメッセージを受信する行為と、
    エンドポイントアプリケーションが前記ウェブサービスアプリケーションとメッセージを交換するときに準拠する１つまたは複数のコントラクトを記述するための仕様であるＮＰＤＬデータ構造を要求しているものと、前記メールメッセージを識別する行為と、
    前記ウェブサービスアプリケーションにアクセスすることなしに、前記ＮＰＤＬデータ構造を自動的に生成する行為と、
    前記エンドポイントに前記ＮＰＤＬデータ構造を送信する行為と、
    を備えることを特徴とする方法。
17. 前記エンドポイントアプリケーションはクライアントであり、前記メールメッセージは前記ウェブサービスアプリケーションに関連付けられたサーバにおいて受信されるものであり、送信する前記行為は、
    前記ＭＡＰＩ準拠メールアプリケーションを用いてもう１つのメールメッセージを生成する行為であって、前記もう１つのメールメッセージは、前記ＮＰＤＬデータ構造、前記クライアントのＭＡＰＩ準拠メールアプリケーションに対するメーリングアドレス、および前記もう１つのメールメッセージが前記ＮＰＤＬデータ構造を含んでいることを識別するための識別子を含むことと、
    前記クライアントのＭＡＰＩ準拠メールアプリケーションに引き続き後で送達するために、前記ＭＡＰＩ準拠メールアプリケーションの発信メールボックスに前記他のメッセージを送信する行為と、
    を含むことを特徴とする請求項１６に記載の方法。
18. 前記ＮＰＤＬはＷＳＤＬであり、前記ＮＰＤＬデータ構造はＸＭＬ文書であることを特徴とする請求項１６に記載の方法。
19. 前記メールメッセージは、前記メールメッセージの件名フィールド中の識別子によって、ＮＰＤＬデータ構造を要求しているものとして識別されることを特徴とする請求項１６に記載の方法。
20. 前記件名フィールド中の前記識別子は、前記ウェブサービスアプリケーションに対する名前を含んでいることを特徴とする請求項１９に記載の方法。

Images