ソフトウェア間通信の中継方法、装置、及びプログラム
【課題】Ｗｅｂブラウザ内で実行される複数のソフトウェア間の通信を、セキュリティを確保しつつ行えるようにする。
【解決手段】
中継サーバが中継するＷｅｂドキュメントに、中継サーバを介して他Ｗｅｂドキュメントと通信を行うためのコードが注入される。連携定義に基づきＷｅｂドキュメント同士が注入コードと中継サーバを介して通信を行う。
【解決手段】
中継サーバが中継するＷｅｂドキュメントに、中継サーバを介して他Ｗｅｂドキュメントと通信を行うためのコードが注入される。連携定義に基づきＷｅｂドキュメント同士が注入コードと中継サーバを介して通信を行う。
【発明の詳細な説明】
【技術分野】
【０００１】
開示する技術は、Ｗｅｂブラウザ内で実行される複数のソフトウェア間の通信の中継技術に関する。
【背景技術】
【０００２】
最近のＷｅｂブラウザには same origin policy というセキュリティ機構が備わっており、異なったオリジン（送信元）から読み込まれたＷｅｂアプリケーション（ソフトウェア）が自由に通信を行うことがないように制御され、セキュリティが確保される。
【０００３】
一方、最近では、同一ブラウザ内に複数のドキュメントを表示させ、異なったオリジンから読み込まれたＷｅｂアプリケーション同士が通信を行うような、マッシュアップと呼ばれる手法が使われるようになってきた。
【０００４】
しかし、このマッシュアップを実現するにあたっては、上述のsame origin policy機構によりアプリケーション間の連携が阻害されるため、same origin policy によるセキュリティ機構を回避する手法が求められている。
【０００５】
Ｗｅｂアプリケーション間の連携を実現する第１の従来技術として、「中継サーバによるドメイン越え」という技術が知られている。更に、この技術として、「パラメータによる中継」技術と「ドメインのエンコーディングによる中継」技術が知られている。
【０００６】
まず、「パラメータによる中継」技術は、読み込みたいＵＲＩを例えば「http://www.exapmle.net/dir/」とした場合に、「http://proxy.example.org/?uri=http://www.exapmle.net/dir/」などのように上記ＵＲＩが中継ドメイン「proxy.example.org」に対するリクエストのクエリパラメータとして埋め込まれる方法である。この手法は、ＣＧＩプロキシでよく使われている。この方法により中継サーバが経由されるときのオリジンは、中継サーバのオリジンとなる。このため、中継サーバ経由で異なるオリジンから読み込まれたドキュメントのオリジンは、互いに等しくなる。図１５は、「パラメータによる中継」技術の例を示す図である。ドメインＰのプロキシ経由で異なるサーバＡ及びＢから読み込まれた各ドキュメントが、クライアントコンピュータの同一ブラウザに含まれる各フレーム等に表示される。この場合、各ドキュメントのドメインは、同一のドメインＰとなる。従って、各ドキュメントは、same origin policyに阻まれずに、ブラウザ上で相互に通信が可能となる。
【０００７】
次に、上記第１の従来技術における「ドメインのエンコーディングによる中継」技術について説明する。
この技術は、読み込みたいＵＲＩを「http://www.example.net/dir/」とした場合に、「http://http-www-example-net.proxy.example.org/dir/」などのように、もともとのＵＲＩのスキーマ・ホスト・ポートをドメインの一部にエンコーディングし、パスとクエリを付加する手法である。図１６は、「ドメインのエンコーディングによる中継」技術の例を示す図である。この手法のプロキシ経由で異なるサーバＡ及びＢから読み込まれた各ドキュメントは、クライアントコンピュータの同一ブラウザに含まれる各フレーム等に表示される。この場合、各ドキュメントのドメインは、ドメインＰの一部に、例えばＡ．Ｐ又はＢ．Ｐというようにエンコーディングされる。この場合、各ドキュメントのドメインは、異なるドメインとなる。この手法は、same origin policyによるセキュリティを保ち、SSLの証明書と相性がよく、変換・逆変換の処理効率もよく、またそのＵＲＩを見たときに容易に解読することが可能（ヒューマンリーダブル）なエンコーディング方法である。
【０００８】
Ｗｅｂアプリケーション間の連携を実現する第２の従来技術として、「ブラウザ内のドキュメント間通信」技術が知られている。更に、この技術として、「iframe proxy communication」技術と「window.postMessage」技術が知られている。
【０００９】
「iframe proxy communication」技術は、ＨＴＭＬ（HyperText Markup Language）におけるiframe要素のsrc属性のフラグメントＩＤを用いてドキュメント間で通信を行う手法である。
【００１０】
一方、「window.postMessage」技術は、ＨＴＭＬ５で採用される新アプリケーションプログラミングインタフェース（ＡＰＩ）である。ＨＴＭＬ５は、Ｗ３Ｃ（World Wide Web Consortium）やＷＨＡＴＷＧ（Web Hypertext Application Technology Working Group）で策定中の次期ＨＴＭＬ仕様である。このＨＴＭＬ５には、「window.postMessage」というＡＰＩが定義されており、このＡＰＩを用いることで、異なったオリジンのドキュメント間で通信を行うことができるようになっている。
【００１１】
本出願が開示する技術に関連する従来技術として、下記先行技術文献が開示されている。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】特開２０００−０７６０７４号公報
【特許文献２】特開２００５−２６７６０５号公報
【発明の概要】
【発明が解決しようとする課題】
【００１３】
しかし、前述した各従来技術は、以下に示される問題点を有している。
まず、前述した第１の従来技術における「パラメータによる中継」技術では、もともとは異なるオリジンであったドキュメント同士が中継サーバを経由することで同一のオリジンとなるため、same origin policy によるセキュリティ機構が動作しない。このため、ドキュメント間では自由な通信ができるが、いかなる通信も許容してしまうため、情報の漏洩や改竄が起きる可能性があるという問題点を有している。
【００１４】
前述した第１の従来技術における「ドメインのエンコーディングによる中継」技術では、もともとのＵＲＩのオリジンが異なっていればエンコーディング後のＵＲＩでもオリジンが異なるので、異なるオリジンを中継サーバ経由で読み込んでもsame origin policyが働く。この結果、ドキュメント間では通信ができないため安全ではあるが、アプリケーションを連携させることができず、マッシュアップ等の実現が困難である。
【００１５】
前述した第２の従来技術における「iframe proxy communication」技術では、ＵＲＩのフラグメントＩＤという、長さの制限の厳しい文字列による通信であるため、通信効率が良いとはいえない。また、「iframe proxy communication」技術では、通信するドキュメント同士が通信相手としてお互いに認識し合っていないと安全な通信を実現することができないという問題点を有している。
【００１６】
前述した第２の従来技術における「window.postMessage」技術に関しては、ＨＴＭＬ５仕様が策定途中であり、この仕様に則ったＷｅｂブラウザの広い普及はまだ先のことであるため、未完成の技術である。また、「window.postMessage」技術では、ドキュメント間が安全に通信をするためにはドキュメント同士が通信相手としてお互いに認識し合っている必要がある。
【００１７】
開示する技術が解決しようとする課題は、Ｗｅｂブラウザ内で実行される複数のソフトウェア間の通信を、セキュリティを確保しつつ行えるようにすることにある。
【課題を解決するための手段】
【００１８】
上記課題を解決するために、態様の一例は、第１の対象サーバから中継サーバを経由して取得した第１のＷｅｂドキュメントに基づいて、クライアントのブラウザ内で実行される連携元ソフトウェアと、第２の対象サーバからその中継サーバを経由して取得した第２のＷｅｂドキュメントに基づいて、そのブラウザ内で実行される連携先ソフトウェアとの間の通信を、その中継サーバにおいて中継する中継方法として実現され、中継サーバが、以下のステップを実行する。
【００１９】
第１の注入ステップは、第１のＷｅｂドキュメントに、連携元ソフトウェアの識別子とその連携元ソフトウェア内で実行される第１の関数の識別子とその第１の関数に与えられる引数を含む第１のイベント通知を、連携元ソフトウェアが中継サーバに送信するための第１の命令を注入する。
【００２０】
第２の注入ステップは、第２のＷｅｂドキュメントに、第２の関数の識別子と引数を含む中継サーバからの第２のイベント通知に基づいて、連携先ソフトウェアがその第２の関数をその引数により実行するための第２の命令を注入する。
【００２１】
第１の送信ステップは、第１の命令が注入された第１のＷｅｂドキュメントおよび第２の命令が注入された第２のＷｅｂドキュメントをクライアントに送信する。
決定ステップは、連携元ソフトウェアから、第１のイベント通知を受信したときに、連携元ソフトウェアの識別子とその連携元ソフトウェアで実行された第１の関数の識別子の組み合わせに対応付けて、その連携元ソフトウェアとの通信が行われる連携先ソフトウェアの識別子とその連携先ソフトウェアで実行される第２の関数の識別子の組み合わせを保持した連携定義テーブルを参照し、その第１のイベント通知に含まれるその連携元ソフトウェアの識別子とその連携元ソフトウェアで実行された第１の関数の識別子の組み合わせに対応する、連携先ソフトウェアの識別子とその連携先ソフトウェアで実行される第２の関数の識別子の組み合わせを決定する。
【００２２】
第２の送信ステップは、決定された組み合わせに含まれる連携先ソフトウェアの識別子に基づいて特定される連携先ソフトウェアに対して、第２のイベント通知として、その決定された組み合わせに含まれる第２の関数の識別子と引数とを送信する。
【発明の効果】
【００２３】
開示する技術によれば、ソフトウェア間で、中継サーバを介してユーザまたはシステムの許諾に基づいた通信を行うことにより、該ソフトウェア間での安全な通信が可能となる。
【００２４】
開示する技術によれば、ソフトウェア間の通信の可否をユーザやシステムが定義するため、各ソフトウェアに通信相手のソフトウェアを意識させる必要をなくすことが可能となる。
【００２５】
開示する技術によれば、クライアント側はプラグイン等が不要で通常のブラウザのみで動作させることが可能となる。
【図面の簡単な説明】
【００２６】
【図１】Ｗｅｂドキュメント間通信システムの第１の実施形態の基本構成図である。
【図２】第１の実施形態の動作フローチャートである。
【図３】ウィジェットのメタデータのデータ構成図である。
【図４】発行関数に対するスクリプト注入の説明図である。
【図５】受信関数に対するHTMLコード注入の説明図である。
【図６】連携定義の動作説明図である。
【図７】Ｗｅｂドキュメント間通信システムの第２の実施形態の基本構成図である。
【図８】第２の実施形態における読込みシーケンスを示す動作シーケンス図である。
【図９】第２の実施形態における連携定義シーケンスを示す動作シーケンス図である。
【図１０】第２の実施形態における連携シーケンスを示す動作シーケンス図である。
【図１１】第２の実施形態における連携定義テーブルのデータベーススキーマを示す図である。
【図１２】第２の実施形態におけるリクエスト受付処理を示す動作フローチャートである。
【図１３】マッシュアップの例を示す図である。
【図１４】中継サーバ１０１を実現できるコンピュータのハードウェア構成の一例を示す図である。
【図１５】第１の従来技術の説明図である。
【図１６】第２の従来技術の説明図である。
【発明を実施するための形態】
【００２７】
以下、実施形態について詳細に説明する。
図１は、Ｗｅｂドキュメント間通信システムの第１の実施形態の基本構成図である。
前述したように、same origin policyによるセキュリティ機構の存在により、Ｗｅｂアプリケーション（ソフトウェア）間の通信は、通信はできるが全ての通信を許可してしまうため安全でない、若しくは、そもそも通信ができない、のいずれかであった。
【００２８】
これに対して、本実施形態では、異なるサーバ１０２（＃ｍ）及び１０２（＃ｎ）からの各ドキュメントは、オリジンが異なるようにして中継サーバ１０１経由でブラウザ１０３内の各フレームに読み込まれる。その際に、各ドキュメントと中継サーバ１０１が通信可能になるように、中継サーバ１０１が各ドキュメントにコードを注入する。ドキュメントから中継サーバ１０１にドキュメント間通信の要求が来たら、中継サーバ１０１がその通信を許可するか否かを判断し、許可ならば通信先のドメインの中継サーバ１０１がブラウザ１０３上のドキュメントに対して、通信内容を配信する。
【００２９】
各ドキュメントは、中継サーバ１０１を経由することによりオリジンが異なるため、same origin policyによってブラウザ１０３内では相互に通信はできない。本実施形態では、ブラウザ１０３内のドキュメント間で通信を行いたい場合には、中継サーバ１０１によって各ドキュメントに注入されたコードによって、中継サーバ１０１を経由して通信を実行する。この際、中継サーバ１０１はドキュメント相互間の通信を許可するか否かを判断できるため、Ｗｅｂアプリケーション間の安全な連携が可能となる。
【００３０】
図２は、上述の第１の実施形態の動作を示す動作フローチャートである。以下に、この動作フローチャートの各ステップの動作を説明する。
ステップＳ２０１：
まず、ブラウザ１０３を利用するユーザが、中継サーバ１０１に対してメタデータのＵＲＩ（Uniform Resource Identifier）を渡し、中継サーバ１０１がそのメタデータに基づいて、ウィジェット（ブラウザ内で、該ブラウザとは独立して実行されるソフトウェアをいう。）をブラウザ１０３に追加表示させる。この例では、ブラウザ１０３において、アドレス帳と地図のウィジェットが読み込まれる。
【００３１】
ステップＳ２０２：
各ウィジェットがサーバ１０２より中継サーバ１０１経由で読み込まれる際に、中継サーバ１０１が、各ウィジェットに対して、ＵＲＩの置換、発行関数へのコード（スクリプト）注入、受信関数へのコード注入を行う。
【００３２】
ステップＳ２０３：
ユーザは、中継サーバ１０１に対して、発行ウィジェット及び発行関数と受信ウィジェット及び受信関数の組を指定することにより、連携定義を指定する。この例では、「アドレス帳ウィジェットにおいて住所が選択されたら地図ウィジェットにて検索が実行される」という連携関係が、下記記述によって定義される。この記述は、ウィジェットｗ１において住所を選択する関数「AddressSelected」が実行されたら、ウィジェットｗ２において地図を検索する関数「SearchMapA」が実行されるという連携関係を表している。
w1:AddressSelected -> w2:SearchMapA
【００３３】
上述の連携定義は、例えばブラウザ１０３を利用するユーザが、中継サーバ１０１から提供される連携定義用のホームページを呼び出して実行する。例えば、ユーザが発行ウィジェット名と受信ウィジェット名を指定すると、中継サーバ１０１は、サーバ１０２にアクセスして、これらのウィジェットに対応するメタデータ（図３）を参照し、発行関数と受信関数のリストをユーザに提示する。ユーザは、提示された関数の中から、所望の発行関数と受信関数の組を指定する。
【００３４】
ステップＳ２０４：
中継サーバ１０１が、ステップＳ２０３にてユーザによって指定された連携定義を、内部の連携定義テーブルに登録する。或いは、この連携定義は、例えば中継サーバ１０１において、予めプリセットされてもよい。
【００３５】
ステップＳ２０５：
アドレス帳ウィジェットにおいて、住所が選択されると、ステップＳ２０２にて発行関数へ注入されたスクリプトにより、中継サーバ１０１にイベントが発行される。
【００３６】
ステップＳ２０６：
中継サーバ１０１は、ステップＳ２０４にて定義した連携定義テーブルを参照して、配信先を決定する。この例では、地図ウィジェットの地図検索が配信先となる。
【００３７】
ステップＳ２０７：
中継サーバ１０１は、ステップＳ２０２にて受信関数に注入されたiframeを用いて、イベントをクライアントに送信する。この結果、地図ウィジェットにおいて地図検索が実行されることになる。
【００３８】
以上のステップＳ２０１からＳ２０７までの一連の動作により、ブラウザ１０３上で表示されているウィジェット間で、中継サーバ１０１経由による連携が実現される。
【００３９】
前述のステップＳ２０１に基づいて図１のサーバ１０２から発行されるウィジェットには一般的に、図３の３０１又は３０２として例示されるようなメタデータが付けられている。メタデータ３０１又は３０２には、３０３又は３０４として示されるcontent要素のsrc属性としてＷｅｂアプリケーションのＵＲＩが書かれている。また、３０５として示されるpublisher要素と３０６として示されるsubscriber要素には発行関数と受信関数の関数名が書かれている。このメタデータに基づいて、後述するウィジェット読込み処理が実行される。
【００４０】
前述のステップＳ２０２の実行において、中継サーバ１０１（図１）を経由してリソースが読み込まれるとき、リソースがＨＴＭＬやＪａｖａＳｃｒｉｐｔなどのテキスト形式のリソースであった場合に、ＵＲＩの置換が行われる。この置換処理により、もともとのＵＲＩが中継サーバ１０１経由のＵＲＩに置き換えられることになる。
【００４１】
ＵＲＩの置換においては、ウィジェットごとに一意のインスタンスＩＤがドメイン名に埋め込まれる。例えば、元のＵＲＩが「http://address.example.net/Address.html 」でウィジェットインスタンスＩＤが「cn0306」なら、置換後のＵＲＩは「http://cn0306-http-address-exapmle-net.hub.example.org/Address.html」のようになる。
【００４２】
一意なウィジェットインスタンスＩＤをドメイン名に埋め込むことには、主に２つの理由がある。一つは、ウィジェットインスタンスＩＤに基づいて中継サーバ１０１がウィジェットを特定できるようにするためである。もう一つは、もともとのＷｅｂアプリケーションのオリジンが同じであったとしても、中継サーバ１０１を経由することで異なるオリジンになり、ウィジェット間の直接の通信を不可能にさせてセキュリティが高められることである。
【００４３】
メタデータに発行関数があることが記述されていた場合（例えば図３の３０１の場合）には、中継サーバ１０１は、前述のステップＳ２０２の実行において、サーバ１０２からの読み込んだウィジェット内の発行関数へスクリプト（コード）を注入する。今例えば、元のＨＴＭＬドキュメントが、図４の４０１のようになっており、発行関数が４０３で示されるようにグローバル関数として定義されているとする。このようなＨＴＭＬドキュメントのbody要素の末尾に、４０２として例示されるスクリプトが注入される。
【００４４】
このスクリプトでは、４０４として示されるように、もともとの発行関数がローカル変数に保存され、４０５として示されるように、新たな関数がグローバル変数に代入される。新たな関数では、４０６として示されるように、もともとの発行関数が呼び出される。また、４０７として示されるように、XMLHttpRequestを用いて中継サーバに対してイベントが起きたことを通知するためのコードが記述される。更に、４０８として示されるように、通知の際に中継サーバ１０１の連携用パスを指定するためのコードが記述さる。更に、４０９として示されるように、通知の際にイベント名や引数をＰＯＳＴリクエストのリクエストボディとして送信するためのコードが記述される。なお、４０８として示される連携用パスは、中継サーバ１０１が予め定めた特殊なパスとする。
【００４５】
中継サーバ１０１でこのようにスクリプトを注入してからブラウザに送信することで、もとのアプリケーションのロジックを壊すことなく、中継サーバ１０１に対してイベントの通知をする機能を追加できる。
【００４６】
メタデータに受信関数があることが記述されていた場合（例えば図３の３０２の場合）には、中継サーバ１０１は、前述のステップＳ２０２の実行において、サーバ１０２から読み込んだウィジェット内の受信関数へＨＴＭＬコードを注入してからブラウザに送信する。元のＨＴＭＬドキュメントが、例えば図５の５０１のようになっており、受信関数が５０４で示されるようにグローバル関数として定義されているとする。このようなＨＴＭＬドキュメントのbody要素の末尾に、５０２として例示されるiframeが注入される。そのiframeによって読み込まれるＨＴＭＬの中身であるスクリプト要素は、例えば５０３のようなコードである。
【００４７】
中継サーバ１０１は、アドレス帳ウィジェット内の発行関数に注入されたスクリプトからのイベント通知に基づいて、前述したステップＳ２０７にて、スクリプト要素５０３を、ブラウザ１０３に表示される地図ウィジェット内のiframeにイベントとして通知する。このイベントの配信時には、サーバプッシュ型通信手法Ｃｏｍｅｔの一種であるiframe streamingを用いてスクリプト要素５０３が書き込まれ、ネットワークストリームがフラッシュされることで、書き込まれたスクリプト要素がブラウザ側で即時実行される。ブラウザ１０３にて実行されるスクリプト要素５０３では、５０５で示されるwindow.parent参照の記述により、元のドキュメント５０１内で５０４として定義されているグローバル関数が呼び出される。この結果、アドレス帳ウィジェット内での住所選択に応答して、地図ウィジェット内で発行元のサーバ１０２（図１）に対して地図検索が実行され、その検索結果が地図ウィジェット内に表示される。
【００４８】
上述の例では、発行ウィジェットからのイベント通知に基づく中継サーバ１０１から受信ウィジェットへのイベント通知は、iframeコードの注入とiframe streamingによって実現されている。そのほか、ＸＨＲ（ＸＭＬＨｔｔｐＲｅｑｕｅｓｔ）を用いたポーリング又は一般的なＣｏｍｅｔ、或いは、タイマ等によるscript要素追加に基づくＪＳＯＮＰ（ＪＳＯＮ ｗｉｔｈ Ｐａｄｄｉｎｇ）を実行する手法等を採用することができる。
【００４９】
前述のステップＳ２０３においてユーザによる指定又はシステムプリセットにより連携定義が指定されると、中継サーバ１０１は、ステップＳ２０４にてその連携定義を連携定義テーブルに登録する。ステップＳ２０５において発行元のウィジェットから中継サーバ１０１にイベントが通知されると、中継サーバ１０１は、ステップＳ２０６において、連携定義テーブルを参照して、どの受信ウィジェットのどの受信関数にイベントを通知するかを判別し、その結果決定したイベント通知を実行する。即ち、中継サーバ１０１は、連携定義テーブルに連携定義が登録されている場合のみ、受信ウィジェットへのイベント通知を実行する。このように連携定義を用いることで、安全なウィジェット間連携を実現できる。
【００５０】
図６は、連携定義テーブルの例を示す図である。この例の１行目のエントリでは、発行ウィジェット名としてアドレス帳ウィジェットに対応するｗ１が指定され、発行関数名として住所項目が選択（クリック又はポイント）されると発行される関数AddressSelectedが指定されている。これに対応して、受信ウィジェット名として地図ウィジェットに対応するｗ２が指定され、受信関数名として地図Ａを検索する関数SearchMapAが指定されている。また、２行目のエントリでは、発行ウィジェット名としてアドレス帳ウィジェットに対応するｗ１が指定され、発行関数名としてメールアドレス項目が選択されると発行される関数MailSelectedが指定されている。これに対応して、受信ウィジェット名としてメーラウィジェットに対応するｗ３が指定され、受信関数名としてToアドレスへのアドレス設定を行う関数SetToが指定されている。
【００５１】
中継サーバ１０１は、上述の連携定義以外のウィジェット間連携は実行しないため、アドレス帳のメールアドレスが地図ウィジェットに漏れたり、アドレス帳の内容が他ウィジェットによって書き換えられたりといった、予測されない連携を阻止することができる。
【００５２】
図７は、Ｗｅｂドキュメント間通信システムの第２の実施形態の基本構成図である。第２の実施形態は、図１の第１の実施形態における中継サーバ１０１、サーバ（対象サーバ）１０２、及びブラウザ１０３からなるＷｅｂドキュメント間通信システムにおいて、中継サーバ１０１の構成を具体化したものである。
【００５３】
図７の構成を有する中継サーバ１０１を中心とした動作について、以下に説明する。
図８は、第２の実施形態における読込みシーケンスを示す動作フローチャートである。この動作フローチャートは、図２に示される前述した第１の実施形態の動作フローチャートのステップＳ２０１とＳ２０２の処理を詳細化したものである。
【００５４】
ユーザは、ブラウザ１０３の親フレームから、中継サーバ１０１内の追加削除部７０１に、追加したいウィジェットのメタデータのＵＲＩを渡す（図８のステップＳ８０１）。
追加削除部７０１は、ユーザテーブル７０２を参照し、要求ユーザが正規のユーザであるか否かをチェックする（図８のステップＳ８０２）。
【００５５】
追加削除部７０１は、ユーザ確認ができたら、対象サーバ１０２からユーザにより要求されたメタデータを取得する（図８のステップＳ８０３）。
そして、追加削除部７０１は、そのメタデータを解析し（図８のステップＳ８０４）、そのメタデータに一意なウィジェットインスタンスＩＤを割り当てて、そのメタデータの登録情報をインスタンスデータベース７０３に登録する（図８のステップＳ８０５）。
【００５６】
追加削除部７０１は、中継サーバ１０１経由でコンテンツを読み込むためのウィジェットインスタンスＩＤ（図中ではインスタンスＩＤ）と置換済みＵＲＩを、ブラウザ１０３の親フレームに返す（図８のステップＳ８０６）。ブラウザ１０３の親フレームは、この情報を中継サーバ１０１から受け取ると、子フレームを作成し、そのアドレスを上記置換済みＵＲＩに設定する。
【００５７】
ブラウザ１０３の親フレームが作成した子フレームは、中継サーバ１０１のプロキシ部７０４に対して、上記置換済みＵＲＩでリクエストを送る（図８のステップＳ８０７）。
プロキシ部７０４内のＵＲＩ置換部７０５は、置換済みＵＲＩから逆変換により、ウィジェットインスタンスＩＤと元のＵＲＩを取り出す（図８のステップＳ８０８）。
【００５８】
プロキシ部７０４は、元のＵＲＩが指している対象サーバ１０２のコンテンツにリクエストを送り、そのコンテンツを取得する（図８のステップＳ８０９）。
もしコンテンツがテキストベースのコンテンツであった場合、プロキシ部７０４内のＵＲＩ置換部７０５は、対象サーバ１０２から渡されたコンテンツの内容のうちＵＲＩの部分に対して置換を行う（図８のステップＳ８１０）。
【００５９】
更に、プロキシ部７０４内のコード注入部７０６は、インスタンスデータベース７０３に登録されているメタデータに基づいて、発行関数と受信関数に対してスクリプト（コード）を注入する（図８のステップＳ８１１）。この動作は、第１の実施形態で前述した動作と同様である。
【００６０】
プロキシ部７０４は、置換と注入の済んだテキストコンテンツ又はバイナリコンテンツを、ブラウザ１０３の子フレームに対してレスポンスとして返し（図８のステップＳ８１２）、ブラウザ１０３は、その内容をウィジェットとして表示する（図８のステップＳ８１３）。
【００６１】
図９は、第２の実施形態における連携定義シーケンスを示す動作フローチャートである。この動作フローチャートは、図２に示される前述した第１の実施形態の動作フローチャートのステップＳ２０３とＳ２０４の処理を詳細化したものである。
【００６２】
ユーザは、ブラウザ１０３の親フレームから中継サーバ１０１の連携定義部７０７に対して、発行ウィジェットのウィジェットインスタンスＩＤ、発行関数名、受信ウィジェットのウィジェットインスタンスＩＤ、受信関数名の組を送る（図９のステップＳ９０１）。
【００６３】
連携定義部７０７は、ユーザテーブル７０２を参照し、要求ユーザが正規のユーザであるか否かをチェックする（図９のステップＳ９０２）。また、連携定義部７０７は、ユーザ確認ができたら、インスタンスデータベース７０３を参照し、ユーザから指定された各ウィジェットインスタンスＩＤと各関数の存在と、各ウィジェットの所有者が当該ユーザであることを確認する（図９のステップＳ９０２）。
【００６４】
連携定義部７０７は、確認が済んだら、連携定義テーブル７０８に、発行ウィジェットインスタンスＩＤ（発行ウィジェット名）、発行関数名、受信ウィジェットインスタンスＩＤ（受信ウィジェット名）、受信関数名を登録する（図９のステップＳ９０３）。連携定義テーブル７０８の構成は、第１の実施形態の説明において前述した図６の構成と同様である。
【００６５】
図１０は、第２の実施形態における連携シーケンスを示す動作フローチャートである。この動作フローチャートは、図２に示される前述した第１の実施形態の動作フローチャートのステップＳ２０５とＳ２０６とＳ２０７の処理を詳細化したものである。
【００６６】
ブラウザ１０３の子フレームで、ユーザが住所選択などのマウス操作又はカーソル操作を行うと、住所選択のイベントが発生する（図１０のステップＳ１００１）。
この結果、住所選択に対応する発行関数が呼び出され（図１０のステップＳ１００２）、その発行関数に注入されたスクリプトによって、子フレームから中継サーバ１０１の発行受付部７０９にリクエストが送られる。発行受付部７０９は、配信割振部７１０に、発行ウィジェットインスタンスＩＤ、発行関数名、関数引数を渡す（図１０のステップＳ１００３）。
【００６７】
配信割振部７１０は、連携定義テーブル７０８を参照し、発行ウィジェットインスタンスＩＤと発行関数名の組に対応する受信ウィジェットインスタンスＩＤと受信関数の組を検索する（図１０のステップＳ１００４）。配信割振部７１０は、組が1つ以上見つかった場合は、配信部７１１に対し、見つかった組と関数引数を渡す（図１０のステップＳ１００５）。
【００６８】
ブラウザ１０３の子フレームから中継サーバ１０１には、iframe streamingのＣｏｍｅｔリクエストが事前に来ている（図１０のステップＳ１０００）。このため、配信部７１１は、受信ウィジェットインスタンスＩＤに対応する子フレームに対して、Ｃｏｍｅｔｎｏレスポンスとして受信関数名と関数引数を含むスクリプト要素を送信する（図１０のステップＳ１００６）。
【００６９】
ブラウザ１０３の子フレームは、受信したスクリプト要素内の受信関数名に対応する受信関数を、関数引数をつけて呼び出し実行する（図１０のステップＳ１００７）。
図１１は、中継サーバ１０１内のデータベースのスキーマを示す図である。
【００７０】
図１１において、ユーザテーブル７０２及び連携定義テーブル７０８は、それぞれ図７に示されるものと同じである。また、ウィジェットインスタンステーブル７０３−１、発行関数テーブル７０３−２、受信関数７０３−３は、図７のインスタンスデータベース（図中「インスタンス・関数」と表記）７０３に対応する。
【００７１】
ユーザテーブル７０２は、ユーザ名とパスワードのハッシュを持ち、ユーザが正しいパスワードでログインしたときに一意のセッションＩＤがランダムで作成され、このテーブルに格納される。ユーザがログイン中は、そのセッションＩＤが用いられてユーザの識別が行われる。ユーザがログアウトしたら、セッションＩＤがテーブルから削除されることで、ログアウト処理が行われる。
【００７２】
ウィジェットインスタンステーブル７０３−１では、ユーザがウィジェットの追加又は削除を行うたびに、データの追加と削除が発生する。ウィジェットが追加されたときには、追加されたウィジェットのメタデータに付与されている発行関数と受信関数が、発行関数テーブル７０３−２及び受信関数テーブル７０３−３に追加される。また、ウィジェットが削除されたときには、ウィジェットインスタンステーブル７０３−１から該当する行が削除される共に、発行関数テーブル７０３−２と受信関数テーブル７０３−３からも対応する関数の行が削除される。
【００７３】
連携定義テーブル７０８では、発行関数と受信関数の関連が定義される。これは図５で前述した通りである。このテーブルで定義されている発行関数と受信関数の組に対して、発行関数が呼び出されたら、対応する受信関数が呼び出される。
【００７４】
図１２は、中継サーバ１０１が実行するリクエスト受付処理を示す動作フローチャートである。
中継サーバ１０１は、リクエストを、以下の４種類処理に振り分けて処理する。
【００７５】
中継サーバ１０１自身へのリクエスト
中継サーバ１０１のコンテンツをレスポンスとして返したり、中継サーバ１０１上のサーバサイドプログラムを実行しその結果を返したりする。
【００７６】
中継サーバ１０１として動作させるためのリクエスト
中継サーバ１０１は、リクエストされたＵＲＩを逆変換して元のＵＲＩにし、その元のＵＲＩに対してリクエストを送り、そのレスポンスを中継サーバ１０１で変換し、レスポンスとして返す。
【００７７】
発行関数が呼び出されたことを中継サーバ１０１に伝えるためのリクエスト
中継サーバ１０１がスクリプトを注入した発行関数が呼び出されたときに、中継サーバ１０１に対してリクエストが発生するようになっている。
【００７８】
受信関数に対してイベントの配信をしてもらうための非同期リクエスト
受信関数を持つウィジェットに対して中継サーバ１０１がiframe streamingのためのiframeを埋め込んであるため、そのiframeからのリクエスト１０１が中継サーバに対して発生する。イベントの配信が起きたときに中継サーバ１０１がこのストリームを利用してイベントを配信する。
【００７９】
上記４つのリクエストの振分け処理を実行する動作フローチャートが、図１２に示される
中継サーバ１０１は、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）リクエストのＨｏｓｔヘッダに書かれているドメイン名をみて、それが中継用の変換済みドメインであるか否かを判断する（図１２のステップＳ１２０２）。
【００８０】
変換済みドメインでなければ、中継サーバ１０１は、自分自身へのリクエストであると判断し、中継サーバ１０１のコンテンツを返したりサーバサイドプログラムを実行したりする（図１２のステップＳ１２０１→Ｓ１２０８）。
【００８１】
ドメイン名が変換済みドメイン名であった場合、中継サーバ１０１は、次にＨＴＴＰリクエストのパスを調べる（図１２のステップＳ１２０１→Ｓ１２０２）。
パスがＣｏｍｅｔ用の特殊な予約済みパスでなかった場合には、中継サーバ１０１に対する中継のリクエストであると判断する。中継サーバ１０１は、リクエストされたＵＲＩを逆変換して元のＵＲＩにする（図１２のステップＳ１２０６）。そして、中継サーバ１０１は、その元のＵＲＩに対してリクエストを中継し、対象サーバ１０２からのレスポンスを変換して中継サーバ１０１のレスポンスとして返す（図１２のステップＳ１２０７）。この動作は、前述したように、プロキシ部７０４によって実行される。
【００８２】
パスがＣｏｍｅｔ用の特殊な予約済みパスであった場合には、中継サーバ１０１は、ＨＴＴＰリクエストのメソッドを判定する（図１２のステップＳ１２０３）。
メソッドがＰＯＳＴであった場合には、中継サーバ１０１は、発行関数からのイベント通知であると判断し、前述した図１０のステップＳ１００４からＳ１００６のイベント発行処理を実行する（図１２のステップＳ１２０３→Ｓ１２０４）。
【００８３】
メソッドがＧＥＴであった場合には、中継サーバ１０１は、受信関数を含むウィジェットに注入したiframeによるiframe streamingであると判断し、イベントを配信するための非同期通信のストリームを開いたままにする（図１２のステップＳ１２０３→Ｓ１２０５）。配信割振部７１０からイベント配信の要求が起きた場合には、配信部７１１がそのストリームに受信関数名と引数を書き込むことで、クライアント側で受信関数の呼び出しを行わせる。
【００８４】
図１３は、第１又は第２の実施形態を用いたマッシュアップの例を示す図である。
図１３では、社内のアドレス帳とメーラ、及び社外の地図のアプリケーションが連携する例が示されている。アドレス帳には氏名、メールアドレス、住所が載っている。この住所録とメーラと地図を連携させたいのであるが、社内のメーラにはメールアドレスがわたるようにし、社外の地図には住所のみがわたるようにして、それ以外のデータがわたらないようにしたい。
【００８５】
図５の連携定義テーブルにあるように連携が定義されることで、地図には住所のみが渡されそれ以外のデータがわたらないよう設定されることで、セキュリティを保ったままアプリケーションの連携をさせることが可能となる。
【００８６】
このほか、メーラ、人事異動帳、従業員アドレス帳、スケジュールの社内のアプリケーションおよび地図の社外のアプリケーションを連携することなども可能である。
図１４は、第１又は第２の実施形態の中継サーバ１０１を実現できるコンピュータのハードウェア構成の一例を示す図である。
【００８７】
図１４に示されるコンピュータは、ＣＰＵ１４０１、メモリ１４０２、入力装置１４０３、出力装置１４０４、外部記憶装置１４０５、可搬記録媒体１４０９が挿入される可搬記録媒体駆動装置１４０６、及びネットワーク接続装置１４０７を有し、これらがバス１４０８によって相互に接続された構成を有する。同図に示される構成は上記システムを実現できるコンピュータの一例であり、そのようなコンピュータはこの構成に限定されるものではない。
【００８８】
ＣＰＵ１４０１は、当該コンピュータ全体の制御を行う。メモリ１４０２は、プログラムの実行、データ更新等の際に、外部記憶装置１４０５（或いは可搬記録媒体１４０９）に記憶されているプログラム又はデータを一時的に格納するＲＡＭ等のメモリである。ＣＵＰ１４０１は、プログラムをメモリ１４０２に読み出して実行することにより、全体の制御を行う。
【００８９】
入力装置１４０３は、例えば、キーボード、マウス等及びそれらのインタフェース制御装置とからなる。入力装置１４０３は、ユーザによるキーボードやマウス等による入力操作を検出し、その検出結果をＣＰＵ１４０１に通知する。
【００９０】
出力装置１４０４は、表示装置、印刷装置等及びそれらのインタフェース制御装置とからなる。出力装置１４０４は、ＣＰＵ１４０１の制御によって送られてくるデータを表示装置や印刷装置に出力する。
【００９１】
外部記憶装置１４０５は、例えばハードディスク記憶装置である。主に各種データやプログラムの保存に用いられる。
可搬記録媒体駆動装置１４０６は、光ディスクやＳＤＲＡＭ、コンパクトフラッシュ（登録商標）、ＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）等の可搬記録媒体１４０９を収容するもので、外部記憶装置１４０５の補助の役割を有する。
【００９２】
ネットワーク接続装置１４０７は、例えばＬＡＮ（ローカルエリアネットワーク）又はＷＡＮ（ワイドエリアネットワーク）の通信回線を接続するための装置である。
第１又は第２の実施形態による中継サーバ１０１の機能は、それに必要な処理内容を記述したプログラムをＣＰＵ１４０１が実行することで実現される。そのプログラムは、例えば外部記憶装置１４０５や可搬記録媒体１４０９に記録して配布してもよく、或いはネットワーク接続装置１４０７によりネットワークを介して他のコンピュータから取得できるようにしてもよい。
【産業上の利用可能性】
【００９３】
開示する技術は、複数のＷｅｂアプリケーションを提供するポータルサイトなどに利用することができる。
【符号の説明】
【００９４】
１０１ 中継サーバ
１０２ サーバ、対象サーバ
１０３ ブラウザ
７０１ 追加削除部
７０２ ユーザテーブル
７０３ インスタンスデータベース
７０３−１ ウィジェットインスタンステーブル
７０３−２ 発行関数テーブル
７０３−３ 受信関数テーブル
７０４ プロキシ部
７０５ ＵＲＩ置換部
７０６ コード注入部
７０７ 連携定義部
７０８ 連携定義テーブル
７０９ 発行受付部
７１０ 配信割振部
７１１ 配信部
１４０１ ＣＰＵ
１４０２ メモリ
１４０３ 入力装置
１４０４ 出力装置
１４０５ 外部記憶装置
１４０６ 可搬記録媒体駆動装置
１４０７ ネットワーク接続装置
１４０８ バス
１４０９ 可搬記録媒体
【技術分野】
【０００１】
開示する技術は、Ｗｅｂブラウザ内で実行される複数のソフトウェア間の通信の中継技術に関する。
【背景技術】
【０００２】
最近のＷｅｂブラウザには same origin policy というセキュリティ機構が備わっており、異なったオリジン（送信元）から読み込まれたＷｅｂアプリケーション（ソフトウェア）が自由に通信を行うことがないように制御され、セキュリティが確保される。
【０００３】
一方、最近では、同一ブラウザ内に複数のドキュメントを表示させ、異なったオリジンから読み込まれたＷｅｂアプリケーション同士が通信を行うような、マッシュアップと呼ばれる手法が使われるようになってきた。
【０００４】
しかし、このマッシュアップを実現するにあたっては、上述のsame origin policy機構によりアプリケーション間の連携が阻害されるため、same origin policy によるセキュリティ機構を回避する手法が求められている。
【０００５】
Ｗｅｂアプリケーション間の連携を実現する第１の従来技術として、「中継サーバによるドメイン越え」という技術が知られている。更に、この技術として、「パラメータによる中継」技術と「ドメインのエンコーディングによる中継」技術が知られている。
【０００６】
まず、「パラメータによる中継」技術は、読み込みたいＵＲＩを例えば「http://www.exapmle.net/dir/」とした場合に、「http://proxy.example.org/?uri=http://www.exapmle.net/dir/」などのように上記ＵＲＩが中継ドメイン「proxy.example.org」に対するリクエストのクエリパラメータとして埋め込まれる方法である。この手法は、ＣＧＩプロキシでよく使われている。この方法により中継サーバが経由されるときのオリジンは、中継サーバのオリジンとなる。このため、中継サーバ経由で異なるオリジンから読み込まれたドキュメントのオリジンは、互いに等しくなる。図１５は、「パラメータによる中継」技術の例を示す図である。ドメインＰのプロキシ経由で異なるサーバＡ及びＢから読み込まれた各ドキュメントが、クライアントコンピュータの同一ブラウザに含まれる各フレーム等に表示される。この場合、各ドキュメントのドメインは、同一のドメインＰとなる。従って、各ドキュメントは、same origin policyに阻まれずに、ブラウザ上で相互に通信が可能となる。
【０００７】
次に、上記第１の従来技術における「ドメインのエンコーディングによる中継」技術について説明する。
この技術は、読み込みたいＵＲＩを「http://www.example.net/dir/」とした場合に、「http://http-www-example-net.proxy.example.org/dir/」などのように、もともとのＵＲＩのスキーマ・ホスト・ポートをドメインの一部にエンコーディングし、パスとクエリを付加する手法である。図１６は、「ドメインのエンコーディングによる中継」技術の例を示す図である。この手法のプロキシ経由で異なるサーバＡ及びＢから読み込まれた各ドキュメントは、クライアントコンピュータの同一ブラウザに含まれる各フレーム等に表示される。この場合、各ドキュメントのドメインは、ドメインＰの一部に、例えばＡ．Ｐ又はＢ．Ｐというようにエンコーディングされる。この場合、各ドキュメントのドメインは、異なるドメインとなる。この手法は、same origin policyによるセキュリティを保ち、SSLの証明書と相性がよく、変換・逆変換の処理効率もよく、またそのＵＲＩを見たときに容易に解読することが可能（ヒューマンリーダブル）なエンコーディング方法である。
【０００８】
Ｗｅｂアプリケーション間の連携を実現する第２の従来技術として、「ブラウザ内のドキュメント間通信」技術が知られている。更に、この技術として、「iframe proxy communication」技術と「window.postMessage」技術が知られている。
【０００９】
「iframe proxy communication」技術は、ＨＴＭＬ（HyperText Markup Language）におけるiframe要素のsrc属性のフラグメントＩＤを用いてドキュメント間で通信を行う手法である。
【００１０】
一方、「window.postMessage」技術は、ＨＴＭＬ５で採用される新アプリケーションプログラミングインタフェース（ＡＰＩ）である。ＨＴＭＬ５は、Ｗ３Ｃ（World Wide Web Consortium）やＷＨＡＴＷＧ（Web Hypertext Application Technology Working Group）で策定中の次期ＨＴＭＬ仕様である。このＨＴＭＬ５には、「window.postMessage」というＡＰＩが定義されており、このＡＰＩを用いることで、異なったオリジンのドキュメント間で通信を行うことができるようになっている。
【００１１】
本出願が開示する技術に関連する従来技術として、下記先行技術文献が開示されている。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】特開２０００−０７６０７４号公報
【特許文献２】特開２００５−２６７６０５号公報
【発明の概要】
【発明が解決しようとする課題】
【００１３】
しかし、前述した各従来技術は、以下に示される問題点を有している。
まず、前述した第１の従来技術における「パラメータによる中継」技術では、もともとは異なるオリジンであったドキュメント同士が中継サーバを経由することで同一のオリジンとなるため、same origin policy によるセキュリティ機構が動作しない。このため、ドキュメント間では自由な通信ができるが、いかなる通信も許容してしまうため、情報の漏洩や改竄が起きる可能性があるという問題点を有している。
【００１４】
前述した第１の従来技術における「ドメインのエンコーディングによる中継」技術では、もともとのＵＲＩのオリジンが異なっていればエンコーディング後のＵＲＩでもオリジンが異なるので、異なるオリジンを中継サーバ経由で読み込んでもsame origin policyが働く。この結果、ドキュメント間では通信ができないため安全ではあるが、アプリケーションを連携させることができず、マッシュアップ等の実現が困難である。
【００１５】
前述した第２の従来技術における「iframe proxy communication」技術では、ＵＲＩのフラグメントＩＤという、長さの制限の厳しい文字列による通信であるため、通信効率が良いとはいえない。また、「iframe proxy communication」技術では、通信するドキュメント同士が通信相手としてお互いに認識し合っていないと安全な通信を実現することができないという問題点を有している。
【００１６】
前述した第２の従来技術における「window.postMessage」技術に関しては、ＨＴＭＬ５仕様が策定途中であり、この仕様に則ったＷｅｂブラウザの広い普及はまだ先のことであるため、未完成の技術である。また、「window.postMessage」技術では、ドキュメント間が安全に通信をするためにはドキュメント同士が通信相手としてお互いに認識し合っている必要がある。
【００１７】
開示する技術が解決しようとする課題は、Ｗｅｂブラウザ内で実行される複数のソフトウェア間の通信を、セキュリティを確保しつつ行えるようにすることにある。
【課題を解決するための手段】
【００１８】
上記課題を解決するために、態様の一例は、第１の対象サーバから中継サーバを経由して取得した第１のＷｅｂドキュメントに基づいて、クライアントのブラウザ内で実行される連携元ソフトウェアと、第２の対象サーバからその中継サーバを経由して取得した第２のＷｅｂドキュメントに基づいて、そのブラウザ内で実行される連携先ソフトウェアとの間の通信を、その中継サーバにおいて中継する中継方法として実現され、中継サーバが、以下のステップを実行する。
【００１９】
第１の注入ステップは、第１のＷｅｂドキュメントに、連携元ソフトウェアの識別子とその連携元ソフトウェア内で実行される第１の関数の識別子とその第１の関数に与えられる引数を含む第１のイベント通知を、連携元ソフトウェアが中継サーバに送信するための第１の命令を注入する。
【００２０】
第２の注入ステップは、第２のＷｅｂドキュメントに、第２の関数の識別子と引数を含む中継サーバからの第２のイベント通知に基づいて、連携先ソフトウェアがその第２の関数をその引数により実行するための第２の命令を注入する。
【００２１】
第１の送信ステップは、第１の命令が注入された第１のＷｅｂドキュメントおよび第２の命令が注入された第２のＷｅｂドキュメントをクライアントに送信する。
決定ステップは、連携元ソフトウェアから、第１のイベント通知を受信したときに、連携元ソフトウェアの識別子とその連携元ソフトウェアで実行された第１の関数の識別子の組み合わせに対応付けて、その連携元ソフトウェアとの通信が行われる連携先ソフトウェアの識別子とその連携先ソフトウェアで実行される第２の関数の識別子の組み合わせを保持した連携定義テーブルを参照し、その第１のイベント通知に含まれるその連携元ソフトウェアの識別子とその連携元ソフトウェアで実行された第１の関数の識別子の組み合わせに対応する、連携先ソフトウェアの識別子とその連携先ソフトウェアで実行される第２の関数の識別子の組み合わせを決定する。
【００２２】
第２の送信ステップは、決定された組み合わせに含まれる連携先ソフトウェアの識別子に基づいて特定される連携先ソフトウェアに対して、第２のイベント通知として、その決定された組み合わせに含まれる第２の関数の識別子と引数とを送信する。
【発明の効果】
【００２３】
開示する技術によれば、ソフトウェア間で、中継サーバを介してユーザまたはシステムの許諾に基づいた通信を行うことにより、該ソフトウェア間での安全な通信が可能となる。
【００２４】
開示する技術によれば、ソフトウェア間の通信の可否をユーザやシステムが定義するため、各ソフトウェアに通信相手のソフトウェアを意識させる必要をなくすことが可能となる。
【００２５】
開示する技術によれば、クライアント側はプラグイン等が不要で通常のブラウザのみで動作させることが可能となる。
【図面の簡単な説明】
【００２６】
【図１】Ｗｅｂドキュメント間通信システムの第１の実施形態の基本構成図である。
【図２】第１の実施形態の動作フローチャートである。
【図３】ウィジェットのメタデータのデータ構成図である。
【図４】発行関数に対するスクリプト注入の説明図である。
【図５】受信関数に対するHTMLコード注入の説明図である。
【図６】連携定義の動作説明図である。
【図７】Ｗｅｂドキュメント間通信システムの第２の実施形態の基本構成図である。
【図８】第２の実施形態における読込みシーケンスを示す動作シーケンス図である。
【図９】第２の実施形態における連携定義シーケンスを示す動作シーケンス図である。
【図１０】第２の実施形態における連携シーケンスを示す動作シーケンス図である。
【図１１】第２の実施形態における連携定義テーブルのデータベーススキーマを示す図である。
【図１２】第２の実施形態におけるリクエスト受付処理を示す動作フローチャートである。
【図１３】マッシュアップの例を示す図である。
【図１４】中継サーバ１０１を実現できるコンピュータのハードウェア構成の一例を示す図である。
【図１５】第１の従来技術の説明図である。
【図１６】第２の従来技術の説明図である。
【発明を実施するための形態】
【００２７】
以下、実施形態について詳細に説明する。
図１は、Ｗｅｂドキュメント間通信システムの第１の実施形態の基本構成図である。
前述したように、same origin policyによるセキュリティ機構の存在により、Ｗｅｂアプリケーション（ソフトウェア）間の通信は、通信はできるが全ての通信を許可してしまうため安全でない、若しくは、そもそも通信ができない、のいずれかであった。
【００２８】
これに対して、本実施形態では、異なるサーバ１０２（＃ｍ）及び１０２（＃ｎ）からの各ドキュメントは、オリジンが異なるようにして中継サーバ１０１経由でブラウザ１０３内の各フレームに読み込まれる。その際に、各ドキュメントと中継サーバ１０１が通信可能になるように、中継サーバ１０１が各ドキュメントにコードを注入する。ドキュメントから中継サーバ１０１にドキュメント間通信の要求が来たら、中継サーバ１０１がその通信を許可するか否かを判断し、許可ならば通信先のドメインの中継サーバ１０１がブラウザ１０３上のドキュメントに対して、通信内容を配信する。
【００２９】
各ドキュメントは、中継サーバ１０１を経由することによりオリジンが異なるため、same origin policyによってブラウザ１０３内では相互に通信はできない。本実施形態では、ブラウザ１０３内のドキュメント間で通信を行いたい場合には、中継サーバ１０１によって各ドキュメントに注入されたコードによって、中継サーバ１０１を経由して通信を実行する。この際、中継サーバ１０１はドキュメント相互間の通信を許可するか否かを判断できるため、Ｗｅｂアプリケーション間の安全な連携が可能となる。
【００３０】
図２は、上述の第１の実施形態の動作を示す動作フローチャートである。以下に、この動作フローチャートの各ステップの動作を説明する。
ステップＳ２０１：
まず、ブラウザ１０３を利用するユーザが、中継サーバ１０１に対してメタデータのＵＲＩ（Uniform Resource Identifier）を渡し、中継サーバ１０１がそのメタデータに基づいて、ウィジェット（ブラウザ内で、該ブラウザとは独立して実行されるソフトウェアをいう。）をブラウザ１０３に追加表示させる。この例では、ブラウザ１０３において、アドレス帳と地図のウィジェットが読み込まれる。
【００３１】
ステップＳ２０２：
各ウィジェットがサーバ１０２より中継サーバ１０１経由で読み込まれる際に、中継サーバ１０１が、各ウィジェットに対して、ＵＲＩの置換、発行関数へのコード（スクリプト）注入、受信関数へのコード注入を行う。
【００３２】
ステップＳ２０３：
ユーザは、中継サーバ１０１に対して、発行ウィジェット及び発行関数と受信ウィジェット及び受信関数の組を指定することにより、連携定義を指定する。この例では、「アドレス帳ウィジェットにおいて住所が選択されたら地図ウィジェットにて検索が実行される」という連携関係が、下記記述によって定義される。この記述は、ウィジェットｗ１において住所を選択する関数「AddressSelected」が実行されたら、ウィジェットｗ２において地図を検索する関数「SearchMapA」が実行されるという連携関係を表している。
w1:AddressSelected -> w2:SearchMapA
【００３３】
上述の連携定義は、例えばブラウザ１０３を利用するユーザが、中継サーバ１０１から提供される連携定義用のホームページを呼び出して実行する。例えば、ユーザが発行ウィジェット名と受信ウィジェット名を指定すると、中継サーバ１０１は、サーバ１０２にアクセスして、これらのウィジェットに対応するメタデータ（図３）を参照し、発行関数と受信関数のリストをユーザに提示する。ユーザは、提示された関数の中から、所望の発行関数と受信関数の組を指定する。
【００３４】
ステップＳ２０４：
中継サーバ１０１が、ステップＳ２０３にてユーザによって指定された連携定義を、内部の連携定義テーブルに登録する。或いは、この連携定義は、例えば中継サーバ１０１において、予めプリセットされてもよい。
【００３５】
ステップＳ２０５：
アドレス帳ウィジェットにおいて、住所が選択されると、ステップＳ２０２にて発行関数へ注入されたスクリプトにより、中継サーバ１０１にイベントが発行される。
【００３６】
ステップＳ２０６：
中継サーバ１０１は、ステップＳ２０４にて定義した連携定義テーブルを参照して、配信先を決定する。この例では、地図ウィジェットの地図検索が配信先となる。
【００３７】
ステップＳ２０７：
中継サーバ１０１は、ステップＳ２０２にて受信関数に注入されたiframeを用いて、イベントをクライアントに送信する。この結果、地図ウィジェットにおいて地図検索が実行されることになる。
【００３８】
以上のステップＳ２０１からＳ２０７までの一連の動作により、ブラウザ１０３上で表示されているウィジェット間で、中継サーバ１０１経由による連携が実現される。
【００３９】
前述のステップＳ２０１に基づいて図１のサーバ１０２から発行されるウィジェットには一般的に、図３の３０１又は３０２として例示されるようなメタデータが付けられている。メタデータ３０１又は３０２には、３０３又は３０４として示されるcontent要素のsrc属性としてＷｅｂアプリケーションのＵＲＩが書かれている。また、３０５として示されるpublisher要素と３０６として示されるsubscriber要素には発行関数と受信関数の関数名が書かれている。このメタデータに基づいて、後述するウィジェット読込み処理が実行される。
【００４０】
前述のステップＳ２０２の実行において、中継サーバ１０１（図１）を経由してリソースが読み込まれるとき、リソースがＨＴＭＬやＪａｖａＳｃｒｉｐｔなどのテキスト形式のリソースであった場合に、ＵＲＩの置換が行われる。この置換処理により、もともとのＵＲＩが中継サーバ１０１経由のＵＲＩに置き換えられることになる。
【００４１】
ＵＲＩの置換においては、ウィジェットごとに一意のインスタンスＩＤがドメイン名に埋め込まれる。例えば、元のＵＲＩが「http://address.example.net/Address.html 」でウィジェットインスタンスＩＤが「cn0306」なら、置換後のＵＲＩは「http://cn0306-http-address-exapmle-net.hub.example.org/Address.html」のようになる。
【００４２】
一意なウィジェットインスタンスＩＤをドメイン名に埋め込むことには、主に２つの理由がある。一つは、ウィジェットインスタンスＩＤに基づいて中継サーバ１０１がウィジェットを特定できるようにするためである。もう一つは、もともとのＷｅｂアプリケーションのオリジンが同じであったとしても、中継サーバ１０１を経由することで異なるオリジンになり、ウィジェット間の直接の通信を不可能にさせてセキュリティが高められることである。
【００４３】
メタデータに発行関数があることが記述されていた場合（例えば図３の３０１の場合）には、中継サーバ１０１は、前述のステップＳ２０２の実行において、サーバ１０２からの読み込んだウィジェット内の発行関数へスクリプト（コード）を注入する。今例えば、元のＨＴＭＬドキュメントが、図４の４０１のようになっており、発行関数が４０３で示されるようにグローバル関数として定義されているとする。このようなＨＴＭＬドキュメントのbody要素の末尾に、４０２として例示されるスクリプトが注入される。
【００４４】
このスクリプトでは、４０４として示されるように、もともとの発行関数がローカル変数に保存され、４０５として示されるように、新たな関数がグローバル変数に代入される。新たな関数では、４０６として示されるように、もともとの発行関数が呼び出される。また、４０７として示されるように、XMLHttpRequestを用いて中継サーバに対してイベントが起きたことを通知するためのコードが記述される。更に、４０８として示されるように、通知の際に中継サーバ１０１の連携用パスを指定するためのコードが記述さる。更に、４０９として示されるように、通知の際にイベント名や引数をＰＯＳＴリクエストのリクエストボディとして送信するためのコードが記述される。なお、４０８として示される連携用パスは、中継サーバ１０１が予め定めた特殊なパスとする。
【００４５】
中継サーバ１０１でこのようにスクリプトを注入してからブラウザに送信することで、もとのアプリケーションのロジックを壊すことなく、中継サーバ１０１に対してイベントの通知をする機能を追加できる。
【００４６】
メタデータに受信関数があることが記述されていた場合（例えば図３の３０２の場合）には、中継サーバ１０１は、前述のステップＳ２０２の実行において、サーバ１０２から読み込んだウィジェット内の受信関数へＨＴＭＬコードを注入してからブラウザに送信する。元のＨＴＭＬドキュメントが、例えば図５の５０１のようになっており、受信関数が５０４で示されるようにグローバル関数として定義されているとする。このようなＨＴＭＬドキュメントのbody要素の末尾に、５０２として例示されるiframeが注入される。そのiframeによって読み込まれるＨＴＭＬの中身であるスクリプト要素は、例えば５０３のようなコードである。
【００４７】
中継サーバ１０１は、アドレス帳ウィジェット内の発行関数に注入されたスクリプトからのイベント通知に基づいて、前述したステップＳ２０７にて、スクリプト要素５０３を、ブラウザ１０３に表示される地図ウィジェット内のiframeにイベントとして通知する。このイベントの配信時には、サーバプッシュ型通信手法Ｃｏｍｅｔの一種であるiframe streamingを用いてスクリプト要素５０３が書き込まれ、ネットワークストリームがフラッシュされることで、書き込まれたスクリプト要素がブラウザ側で即時実行される。ブラウザ１０３にて実行されるスクリプト要素５０３では、５０５で示されるwindow.parent参照の記述により、元のドキュメント５０１内で５０４として定義されているグローバル関数が呼び出される。この結果、アドレス帳ウィジェット内での住所選択に応答して、地図ウィジェット内で発行元のサーバ１０２（図１）に対して地図検索が実行され、その検索結果が地図ウィジェット内に表示される。
【００４８】
上述の例では、発行ウィジェットからのイベント通知に基づく中継サーバ１０１から受信ウィジェットへのイベント通知は、iframeコードの注入とiframe streamingによって実現されている。そのほか、ＸＨＲ（ＸＭＬＨｔｔｐＲｅｑｕｅｓｔ）を用いたポーリング又は一般的なＣｏｍｅｔ、或いは、タイマ等によるscript要素追加に基づくＪＳＯＮＰ（ＪＳＯＮ ｗｉｔｈ Ｐａｄｄｉｎｇ）を実行する手法等を採用することができる。
【００４９】
前述のステップＳ２０３においてユーザによる指定又はシステムプリセットにより連携定義が指定されると、中継サーバ１０１は、ステップＳ２０４にてその連携定義を連携定義テーブルに登録する。ステップＳ２０５において発行元のウィジェットから中継サーバ１０１にイベントが通知されると、中継サーバ１０１は、ステップＳ２０６において、連携定義テーブルを参照して、どの受信ウィジェットのどの受信関数にイベントを通知するかを判別し、その結果決定したイベント通知を実行する。即ち、中継サーバ１０１は、連携定義テーブルに連携定義が登録されている場合のみ、受信ウィジェットへのイベント通知を実行する。このように連携定義を用いることで、安全なウィジェット間連携を実現できる。
【００５０】
図６は、連携定義テーブルの例を示す図である。この例の１行目のエントリでは、発行ウィジェット名としてアドレス帳ウィジェットに対応するｗ１が指定され、発行関数名として住所項目が選択（クリック又はポイント）されると発行される関数AddressSelectedが指定されている。これに対応して、受信ウィジェット名として地図ウィジェットに対応するｗ２が指定され、受信関数名として地図Ａを検索する関数SearchMapAが指定されている。また、２行目のエントリでは、発行ウィジェット名としてアドレス帳ウィジェットに対応するｗ１が指定され、発行関数名としてメールアドレス項目が選択されると発行される関数MailSelectedが指定されている。これに対応して、受信ウィジェット名としてメーラウィジェットに対応するｗ３が指定され、受信関数名としてToアドレスへのアドレス設定を行う関数SetToが指定されている。
【００５１】
中継サーバ１０１は、上述の連携定義以外のウィジェット間連携は実行しないため、アドレス帳のメールアドレスが地図ウィジェットに漏れたり、アドレス帳の内容が他ウィジェットによって書き換えられたりといった、予測されない連携を阻止することができる。
【００５２】
図７は、Ｗｅｂドキュメント間通信システムの第２の実施形態の基本構成図である。第２の実施形態は、図１の第１の実施形態における中継サーバ１０１、サーバ（対象サーバ）１０２、及びブラウザ１０３からなるＷｅｂドキュメント間通信システムにおいて、中継サーバ１０１の構成を具体化したものである。
【００５３】
図７の構成を有する中継サーバ１０１を中心とした動作について、以下に説明する。
図８は、第２の実施形態における読込みシーケンスを示す動作フローチャートである。この動作フローチャートは、図２に示される前述した第１の実施形態の動作フローチャートのステップＳ２０１とＳ２０２の処理を詳細化したものである。
【００５４】
ユーザは、ブラウザ１０３の親フレームから、中継サーバ１０１内の追加削除部７０１に、追加したいウィジェットのメタデータのＵＲＩを渡す（図８のステップＳ８０１）。
追加削除部７０１は、ユーザテーブル７０２を参照し、要求ユーザが正規のユーザであるか否かをチェックする（図８のステップＳ８０２）。
【００５５】
追加削除部７０１は、ユーザ確認ができたら、対象サーバ１０２からユーザにより要求されたメタデータを取得する（図８のステップＳ８０３）。
そして、追加削除部７０１は、そのメタデータを解析し（図８のステップＳ８０４）、そのメタデータに一意なウィジェットインスタンスＩＤを割り当てて、そのメタデータの登録情報をインスタンスデータベース７０３に登録する（図８のステップＳ８０５）。
【００５６】
追加削除部７０１は、中継サーバ１０１経由でコンテンツを読み込むためのウィジェットインスタンスＩＤ（図中ではインスタンスＩＤ）と置換済みＵＲＩを、ブラウザ１０３の親フレームに返す（図８のステップＳ８０６）。ブラウザ１０３の親フレームは、この情報を中継サーバ１０１から受け取ると、子フレームを作成し、そのアドレスを上記置換済みＵＲＩに設定する。
【００５７】
ブラウザ１０３の親フレームが作成した子フレームは、中継サーバ１０１のプロキシ部７０４に対して、上記置換済みＵＲＩでリクエストを送る（図８のステップＳ８０７）。
プロキシ部７０４内のＵＲＩ置換部７０５は、置換済みＵＲＩから逆変換により、ウィジェットインスタンスＩＤと元のＵＲＩを取り出す（図８のステップＳ８０８）。
【００５８】
プロキシ部７０４は、元のＵＲＩが指している対象サーバ１０２のコンテンツにリクエストを送り、そのコンテンツを取得する（図８のステップＳ８０９）。
もしコンテンツがテキストベースのコンテンツであった場合、プロキシ部７０４内のＵＲＩ置換部７０５は、対象サーバ１０２から渡されたコンテンツの内容のうちＵＲＩの部分に対して置換を行う（図８のステップＳ８１０）。
【００５９】
更に、プロキシ部７０４内のコード注入部７０６は、インスタンスデータベース７０３に登録されているメタデータに基づいて、発行関数と受信関数に対してスクリプト（コード）を注入する（図８のステップＳ８１１）。この動作は、第１の実施形態で前述した動作と同様である。
【００６０】
プロキシ部７０４は、置換と注入の済んだテキストコンテンツ又はバイナリコンテンツを、ブラウザ１０３の子フレームに対してレスポンスとして返し（図８のステップＳ８１２）、ブラウザ１０３は、その内容をウィジェットとして表示する（図８のステップＳ８１３）。
【００６１】
図９は、第２の実施形態における連携定義シーケンスを示す動作フローチャートである。この動作フローチャートは、図２に示される前述した第１の実施形態の動作フローチャートのステップＳ２０３とＳ２０４の処理を詳細化したものである。
【００６２】
ユーザは、ブラウザ１０３の親フレームから中継サーバ１０１の連携定義部７０７に対して、発行ウィジェットのウィジェットインスタンスＩＤ、発行関数名、受信ウィジェットのウィジェットインスタンスＩＤ、受信関数名の組を送る（図９のステップＳ９０１）。
【００６３】
連携定義部７０７は、ユーザテーブル７０２を参照し、要求ユーザが正規のユーザであるか否かをチェックする（図９のステップＳ９０２）。また、連携定義部７０７は、ユーザ確認ができたら、インスタンスデータベース７０３を参照し、ユーザから指定された各ウィジェットインスタンスＩＤと各関数の存在と、各ウィジェットの所有者が当該ユーザであることを確認する（図９のステップＳ９０２）。
【００６４】
連携定義部７０７は、確認が済んだら、連携定義テーブル７０８に、発行ウィジェットインスタンスＩＤ（発行ウィジェット名）、発行関数名、受信ウィジェットインスタンスＩＤ（受信ウィジェット名）、受信関数名を登録する（図９のステップＳ９０３）。連携定義テーブル７０８の構成は、第１の実施形態の説明において前述した図６の構成と同様である。
【００６５】
図１０は、第２の実施形態における連携シーケンスを示す動作フローチャートである。この動作フローチャートは、図２に示される前述した第１の実施形態の動作フローチャートのステップＳ２０５とＳ２０６とＳ２０７の処理を詳細化したものである。
【００６６】
ブラウザ１０３の子フレームで、ユーザが住所選択などのマウス操作又はカーソル操作を行うと、住所選択のイベントが発生する（図１０のステップＳ１００１）。
この結果、住所選択に対応する発行関数が呼び出され（図１０のステップＳ１００２）、その発行関数に注入されたスクリプトによって、子フレームから中継サーバ１０１の発行受付部７０９にリクエストが送られる。発行受付部７０９は、配信割振部７１０に、発行ウィジェットインスタンスＩＤ、発行関数名、関数引数を渡す（図１０のステップＳ１００３）。
【００６７】
配信割振部７１０は、連携定義テーブル７０８を参照し、発行ウィジェットインスタンスＩＤと発行関数名の組に対応する受信ウィジェットインスタンスＩＤと受信関数の組を検索する（図１０のステップＳ１００４）。配信割振部７１０は、組が1つ以上見つかった場合は、配信部７１１に対し、見つかった組と関数引数を渡す（図１０のステップＳ１００５）。
【００６８】
ブラウザ１０３の子フレームから中継サーバ１０１には、iframe streamingのＣｏｍｅｔリクエストが事前に来ている（図１０のステップＳ１０００）。このため、配信部７１１は、受信ウィジェットインスタンスＩＤに対応する子フレームに対して、Ｃｏｍｅｔｎｏレスポンスとして受信関数名と関数引数を含むスクリプト要素を送信する（図１０のステップＳ１００６）。
【００６９】
ブラウザ１０３の子フレームは、受信したスクリプト要素内の受信関数名に対応する受信関数を、関数引数をつけて呼び出し実行する（図１０のステップＳ１００７）。
図１１は、中継サーバ１０１内のデータベースのスキーマを示す図である。
【００７０】
図１１において、ユーザテーブル７０２及び連携定義テーブル７０８は、それぞれ図７に示されるものと同じである。また、ウィジェットインスタンステーブル７０３−１、発行関数テーブル７０３−２、受信関数７０３−３は、図７のインスタンスデータベース（図中「インスタンス・関数」と表記）７０３に対応する。
【００７１】
ユーザテーブル７０２は、ユーザ名とパスワードのハッシュを持ち、ユーザが正しいパスワードでログインしたときに一意のセッションＩＤがランダムで作成され、このテーブルに格納される。ユーザがログイン中は、そのセッションＩＤが用いられてユーザの識別が行われる。ユーザがログアウトしたら、セッションＩＤがテーブルから削除されることで、ログアウト処理が行われる。
【００７２】
ウィジェットインスタンステーブル７０３−１では、ユーザがウィジェットの追加又は削除を行うたびに、データの追加と削除が発生する。ウィジェットが追加されたときには、追加されたウィジェットのメタデータに付与されている発行関数と受信関数が、発行関数テーブル７０３−２及び受信関数テーブル７０３−３に追加される。また、ウィジェットが削除されたときには、ウィジェットインスタンステーブル７０３−１から該当する行が削除される共に、発行関数テーブル７０３−２と受信関数テーブル７０３−３からも対応する関数の行が削除される。
【００７３】
連携定義テーブル７０８では、発行関数と受信関数の関連が定義される。これは図５で前述した通りである。このテーブルで定義されている発行関数と受信関数の組に対して、発行関数が呼び出されたら、対応する受信関数が呼び出される。
【００７４】
図１２は、中継サーバ１０１が実行するリクエスト受付処理を示す動作フローチャートである。
中継サーバ１０１は、リクエストを、以下の４種類処理に振り分けて処理する。
【００７５】
中継サーバ１０１自身へのリクエスト
中継サーバ１０１のコンテンツをレスポンスとして返したり、中継サーバ１０１上のサーバサイドプログラムを実行しその結果を返したりする。
【００７６】
中継サーバ１０１として動作させるためのリクエスト
中継サーバ１０１は、リクエストされたＵＲＩを逆変換して元のＵＲＩにし、その元のＵＲＩに対してリクエストを送り、そのレスポンスを中継サーバ１０１で変換し、レスポンスとして返す。
【００７７】
発行関数が呼び出されたことを中継サーバ１０１に伝えるためのリクエスト
中継サーバ１０１がスクリプトを注入した発行関数が呼び出されたときに、中継サーバ１０１に対してリクエストが発生するようになっている。
【００７８】
受信関数に対してイベントの配信をしてもらうための非同期リクエスト
受信関数を持つウィジェットに対して中継サーバ１０１がiframe streamingのためのiframeを埋め込んであるため、そのiframeからのリクエスト１０１が中継サーバに対して発生する。イベントの配信が起きたときに中継サーバ１０１がこのストリームを利用してイベントを配信する。
【００７９】
上記４つのリクエストの振分け処理を実行する動作フローチャートが、図１２に示される
中継サーバ１０１は、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）リクエストのＨｏｓｔヘッダに書かれているドメイン名をみて、それが中継用の変換済みドメインであるか否かを判断する（図１２のステップＳ１２０２）。
【００８０】
変換済みドメインでなければ、中継サーバ１０１は、自分自身へのリクエストであると判断し、中継サーバ１０１のコンテンツを返したりサーバサイドプログラムを実行したりする（図１２のステップＳ１２０１→Ｓ１２０８）。
【００８１】
ドメイン名が変換済みドメイン名であった場合、中継サーバ１０１は、次にＨＴＴＰリクエストのパスを調べる（図１２のステップＳ１２０１→Ｓ１２０２）。
パスがＣｏｍｅｔ用の特殊な予約済みパスでなかった場合には、中継サーバ１０１に対する中継のリクエストであると判断する。中継サーバ１０１は、リクエストされたＵＲＩを逆変換して元のＵＲＩにする（図１２のステップＳ１２０６）。そして、中継サーバ１０１は、その元のＵＲＩに対してリクエストを中継し、対象サーバ１０２からのレスポンスを変換して中継サーバ１０１のレスポンスとして返す（図１２のステップＳ１２０７）。この動作は、前述したように、プロキシ部７０４によって実行される。
【００８２】
パスがＣｏｍｅｔ用の特殊な予約済みパスであった場合には、中継サーバ１０１は、ＨＴＴＰリクエストのメソッドを判定する（図１２のステップＳ１２０３）。
メソッドがＰＯＳＴであった場合には、中継サーバ１０１は、発行関数からのイベント通知であると判断し、前述した図１０のステップＳ１００４からＳ１００６のイベント発行処理を実行する（図１２のステップＳ１２０３→Ｓ１２０４）。
【００８３】
メソッドがＧＥＴであった場合には、中継サーバ１０１は、受信関数を含むウィジェットに注入したiframeによるiframe streamingであると判断し、イベントを配信するための非同期通信のストリームを開いたままにする（図１２のステップＳ１２０３→Ｓ１２０５）。配信割振部７１０からイベント配信の要求が起きた場合には、配信部７１１がそのストリームに受信関数名と引数を書き込むことで、クライアント側で受信関数の呼び出しを行わせる。
【００８４】
図１３は、第１又は第２の実施形態を用いたマッシュアップの例を示す図である。
図１３では、社内のアドレス帳とメーラ、及び社外の地図のアプリケーションが連携する例が示されている。アドレス帳には氏名、メールアドレス、住所が載っている。この住所録とメーラと地図を連携させたいのであるが、社内のメーラにはメールアドレスがわたるようにし、社外の地図には住所のみがわたるようにして、それ以外のデータがわたらないようにしたい。
【００８５】
図５の連携定義テーブルにあるように連携が定義されることで、地図には住所のみが渡されそれ以外のデータがわたらないよう設定されることで、セキュリティを保ったままアプリケーションの連携をさせることが可能となる。
【００８６】
このほか、メーラ、人事異動帳、従業員アドレス帳、スケジュールの社内のアプリケーションおよび地図の社外のアプリケーションを連携することなども可能である。
図１４は、第１又は第２の実施形態の中継サーバ１０１を実現できるコンピュータのハードウェア構成の一例を示す図である。
【００８７】
図１４に示されるコンピュータは、ＣＰＵ１４０１、メモリ１４０２、入力装置１４０３、出力装置１４０４、外部記憶装置１４０５、可搬記録媒体１４０９が挿入される可搬記録媒体駆動装置１４０６、及びネットワーク接続装置１４０７を有し、これらがバス１４０８によって相互に接続された構成を有する。同図に示される構成は上記システムを実現できるコンピュータの一例であり、そのようなコンピュータはこの構成に限定されるものではない。
【００８８】
ＣＰＵ１４０１は、当該コンピュータ全体の制御を行う。メモリ１４０２は、プログラムの実行、データ更新等の際に、外部記憶装置１４０５（或いは可搬記録媒体１４０９）に記憶されているプログラム又はデータを一時的に格納するＲＡＭ等のメモリである。ＣＵＰ１４０１は、プログラムをメモリ１４０２に読み出して実行することにより、全体の制御を行う。
【００８９】
入力装置１４０３は、例えば、キーボード、マウス等及びそれらのインタフェース制御装置とからなる。入力装置１４０３は、ユーザによるキーボードやマウス等による入力操作を検出し、その検出結果をＣＰＵ１４０１に通知する。
【００９０】
出力装置１４０４は、表示装置、印刷装置等及びそれらのインタフェース制御装置とからなる。出力装置１４０４は、ＣＰＵ１４０１の制御によって送られてくるデータを表示装置や印刷装置に出力する。
【００９１】
外部記憶装置１４０５は、例えばハードディスク記憶装置である。主に各種データやプログラムの保存に用いられる。
可搬記録媒体駆動装置１４０６は、光ディスクやＳＤＲＡＭ、コンパクトフラッシュ（登録商標）、ＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）等の可搬記録媒体１４０９を収容するもので、外部記憶装置１４０５の補助の役割を有する。
【００９２】
ネットワーク接続装置１４０７は、例えばＬＡＮ（ローカルエリアネットワーク）又はＷＡＮ（ワイドエリアネットワーク）の通信回線を接続するための装置である。
第１又は第２の実施形態による中継サーバ１０１の機能は、それに必要な処理内容を記述したプログラムをＣＰＵ１４０１が実行することで実現される。そのプログラムは、例えば外部記憶装置１４０５や可搬記録媒体１４０９に記録して配布してもよく、或いはネットワーク接続装置１４０７によりネットワークを介して他のコンピュータから取得できるようにしてもよい。
【産業上の利用可能性】
【００９３】
開示する技術は、複数のＷｅｂアプリケーションを提供するポータルサイトなどに利用することができる。
【符号の説明】
【００９４】
１０１ 中継サーバ
１０２ サーバ、対象サーバ
１０３ ブラウザ
７０１ 追加削除部
７０２ ユーザテーブル
７０３ インスタンスデータベース
７０３−１ ウィジェットインスタンステーブル
７０３−２ 発行関数テーブル
７０３−３ 受信関数テーブル
７０４ プロキシ部
７０５ ＵＲＩ置換部
７０６ コード注入部
７０７ 連携定義部
７０８ 連携定義テーブル
７０９ 発行受付部
７１０ 配信割振部
７１１ 配信部
１４０１ ＣＰＵ
１４０２ メモリ
１４０３ 入力装置
１４０４ 出力装置
１４０５ 外部記憶装置
１４０６ 可搬記録媒体駆動装置
１４０７ ネットワーク接続装置
１４０８ バス
１４０９ 可搬記録媒体
【特許請求の範囲】
【請求項１】
第１の対象サーバから中継サーバを経由して取得した第１のＷｅｂドキュメントに基づいて、クライアントのブラウザ内で実行される連携元ソフトウェアと、第２の対象サーバから該中継サーバを経由して取得した第２のＷｅｂドキュメントに基づいて、該ブラウザ内で実行される連携先ソフトウェアとの間の通信を、該中継サーバにおいて中継する中継方法において、
前記中継サーバが、
前記第１のＷｅｂドキュメントに、前記連携元ソフトウェアの識別子と該連携元ソフトウェア内で実行される第１の関数の識別子と該第１の関数に与えられる引数を含む第１のイベント通知を、前記連携元ソフトウェアが前記中継サーバに送信するための第１の命令を注入する第１の注入ステップと、
前記第２のＷｅｂドキュメントに、第２の関数の識別子と前記引数を含む前記中継サーバからの第２のイベント通知に基づいて、前記連携先ソフトウェアが該第２の関数を該引数により実行するための第２の命令を注入する第２の注入ステップと、
前記第１の命令が注入された第１のＷｅｂドキュメントおよび前記第２の命令が注入された第２のＷｅｂドキュメントを前記クライアントに送信する第１の送信ステップと、
前記連携元ソフトウェアから、前記第１のイベント通知を受信したときに、連携元ソフトウェアの識別子と該連携元ソフトウェアで実行された第１の関数の識別子の組み合わせに対応付けて、該連携元ソフトウェアとの通信が行われる連携先ソフトウェアの識別子と該連携先ソフトウェアで実行される第２の関数の識別子の組み合わせを保持した連携定義テーブルを参照し、該第１のイベント通知に含まれる該連携元ソフトウェアの識別子と該連携元ソフトウェアで実行された第１の関数の識別子の組み合わせに対応する、連携先ソフトウェアの識別子と該連携先ソフトウェアで実行される第２の関数の識別子の組み合わせを決定するステップと、
前記決定された組み合わせに含まれる前記連携先ソフトウェアの識別子に基づいて特定される連携先ソフトウェアに対して、前記第２のイベント通知として、該決定された組み合わせに含まれる前記第２の関数の識別子と前記引数とを送信する第２の送信ステップと、
を実行することを特徴とするソフトウェア間通信の中継方法。
【請求項２】
前記第１の命令は、前記連携元ソフトウェアで前記第１の関数が実行されたときに、該連携元ソフトウェアの識別子と該第１の関数の識別子と該第１の関数に与えられた引数を含む前記第１のイベント通知を、前記中継サーバに送信するための命令である、
ことを特徴とする請求項１記載のソフトウェア間通信の中継方法。
【請求項３】
前記第２の命令は、前記中継サーバから前記第２のイベント通知を受信したときに、該第２のイベント通知に含まれる前記第２の関数の識別子と前記引数に基づいて、該第２の関数を呼び出しかつ該第２の関数に該引数を与える命令である、
ことを特徴とする請求項１又は２記載のソフトウェア間通信の中継方法。
【請求項４】
前記第１の送信ステップは、前記第１のＷｅｂドキュメントの送信元アドレスと前記第２のＷｅｂドキュメントの送信元アドレスとが、前記クライアントにおいて互いに異なると判定されるように、各Ｗｅｂドキュメントに一意のアドレスを割り当てて該クライアントに送信することを特徴とする請求項１、２または３記載のソフトウェア間通信の中継方法。
【請求項５】
クライアントからのリクエストに基づいて第１の対象サーバから第１のＷｅｂドキュメントを取得して該クライアントに中継したときに該クライアント内のブラウザ内で実行される連携元ソフトウェアと、前記クライアントからのリクエストに基づいて第２の対象サーバから第２のＷｅｂドキュメントを取得して前記クライアントに中継したときに前記ブラウザ内で実行される連携先ソフトウェアとの間の通信を中継する中継装置において、
前記第１のＷｅｂドキュメントに、前記連携元ソフトウェアの識別子と該連携元ソフトウェア内で実行される第１の関数の識別子と該第１の関数に与えられる引数を含む第１のイベント通知を、前記連携元ソフトウェアから自中継装置に送信させるための第１の命令を注入する第１の注入部と、
前記第２のＷｅｂドキュメントに、第２の関数の識別子と前記引数を含む自中継装置からのからの第２のイベント通知に基づいて、前記連携先ソフトウェアが該第２の関数を該引数により実行するための第２の命令を注入する第２の注入部と、
前記第１の命令が注入された第１のＷｅｂドキュメントおよび前記第２の命令が注入された第２のＷｅｂドキュメントを前記クライアントに送信する第１の送信部と、
前記連携元ソフトウェアから、前記第１のイベント通知を受信したときに、連携元ソフトウェアの識別子と該連携元ソフトウェアで実行された第１の関数の識別子の組み合わせに対応付けて、該連携元ソフトウェアとの通信が行われる連携先ソフトウェアの識別子と該連携先ソフトウェアで実行される第２の関数の識別子の組み合わせを保持した連携定義テーブルを参照し、該第１のイベント通知に含まれる該連携元ソフトウェアの識別子と該連携元ソフトウェアで実行された第１の関数の識別子の組み合わせに対応する、連携先ソフトウェアの識別子と該連携先ソフトウェアで実行される第２の関数の識別子の組み合わせを決定する決定部と、
前記決定された組み合わせに含まれる前記連携先ソフトウェアの識別子に基づいて特定される連携先ソフトウェアに対して、前記第２のイベント通知として、該決定された組み合わせに含まれる前記第２の関数の識別子と前記引数とを送信する第２の送信部と、
を含むことを特徴とするソフトウェア間通信の中継装置。
【請求項６】
第１の対象サーバから中継サーバを経由して取得した第１のＷｅｂドキュメントに基づいて、クライアントのブラウザ内で実行される連携元ソフトウェアと、第２の対象サーバから該中継サーバを経由して取得した第２のＷｅｂドキュメントに基づいて、該ブラウザ内で実行される連携先ソフトウェアとの間の通信を該中継サーバにおいて中継するプログラムであって、
前記中継サーバに、
前記第１のＷｅｂドキュメントに、前記連携元ソフトウェアの識別子と該連携元ソフトウェア内で実行される第１の関数の識別子と該第１の関数に与えられる引数を含む第１のイベント通知を、前記連携元ソフトウェアが前記中継サーバに送信するための第１の命令を注入する第１の注入ステップと、
前記第２のＷｅｂドキュメントに、第２の関数の識別子と前記引数を含む前記中継サーバからの第２のイベント通知に基づいて、前記連携先ソフトウェアが該第２の関数を該引数により実行するための第２の命令を注入する第２の注入ステップと、
前記第１の命令が注入された第１のＷｅｂドキュメントおよび前記第２の命令が注入された第２のＷｅｂドキュメントを前記クライアントに送信する第１の送信ステップと、
前記連携元ソフトウェアから、前記第１のイベント通知を受信したときに、連携元ソフトウェアの識別子と該連携元ソフトウェアで実行された第１の関数の識別子の組み合わせに対応付けて、該連携元ソフトウェアとの通信が行われる連携先ソフトウェアの識別子と該連携先ソフトウェアで実行される第２の関数の識別子の組み合わせを保持した連携定義テーブルを参照し、該第１のイベント通知に含まれる該連携元ソフトウェアの識別子と該連携元ソフトウェアで実行された第１の関数の識別子の組み合わせに対応する、連携先ソフトウェアの識別子と該連携先ソフトウェアで実行される第２の関数の識別子の組み合わせを決定するステップと、
前記決定された組み合わせに含まれる前記連携先ソフトウェアの識別子に基づいて特定される連携先ソフトウェアに対して、前記第２のイベント通知として、該決定された組み合わせに含まれる前記第２の関数の識別子と前記引数とを送信する第２の送信ステップと、
を実行させるためのプログラム。
【請求項１】
第１の対象サーバから中継サーバを経由して取得した第１のＷｅｂドキュメントに基づいて、クライアントのブラウザ内で実行される連携元ソフトウェアと、第２の対象サーバから該中継サーバを経由して取得した第２のＷｅｂドキュメントに基づいて、該ブラウザ内で実行される連携先ソフトウェアとの間の通信を、該中継サーバにおいて中継する中継方法において、
前記中継サーバが、
前記第１のＷｅｂドキュメントに、前記連携元ソフトウェアの識別子と該連携元ソフトウェア内で実行される第１の関数の識別子と該第１の関数に与えられる引数を含む第１のイベント通知を、前記連携元ソフトウェアが前記中継サーバに送信するための第１の命令を注入する第１の注入ステップと、
前記第２のＷｅｂドキュメントに、第２の関数の識別子と前記引数を含む前記中継サーバからの第２のイベント通知に基づいて、前記連携先ソフトウェアが該第２の関数を該引数により実行するための第２の命令を注入する第２の注入ステップと、
前記第１の命令が注入された第１のＷｅｂドキュメントおよび前記第２の命令が注入された第２のＷｅｂドキュメントを前記クライアントに送信する第１の送信ステップと、
前記連携元ソフトウェアから、前記第１のイベント通知を受信したときに、連携元ソフトウェアの識別子と該連携元ソフトウェアで実行された第１の関数の識別子の組み合わせに対応付けて、該連携元ソフトウェアとの通信が行われる連携先ソフトウェアの識別子と該連携先ソフトウェアで実行される第２の関数の識別子の組み合わせを保持した連携定義テーブルを参照し、該第１のイベント通知に含まれる該連携元ソフトウェアの識別子と該連携元ソフトウェアで実行された第１の関数の識別子の組み合わせに対応する、連携先ソフトウェアの識別子と該連携先ソフトウェアで実行される第２の関数の識別子の組み合わせを決定するステップと、
前記決定された組み合わせに含まれる前記連携先ソフトウェアの識別子に基づいて特定される連携先ソフトウェアに対して、前記第２のイベント通知として、該決定された組み合わせに含まれる前記第２の関数の識別子と前記引数とを送信する第２の送信ステップと、
を実行することを特徴とするソフトウェア間通信の中継方法。
【請求項２】
前記第１の命令は、前記連携元ソフトウェアで前記第１の関数が実行されたときに、該連携元ソフトウェアの識別子と該第１の関数の識別子と該第１の関数に与えられた引数を含む前記第１のイベント通知を、前記中継サーバに送信するための命令である、
ことを特徴とする請求項１記載のソフトウェア間通信の中継方法。
【請求項３】
前記第２の命令は、前記中継サーバから前記第２のイベント通知を受信したときに、該第２のイベント通知に含まれる前記第２の関数の識別子と前記引数に基づいて、該第２の関数を呼び出しかつ該第２の関数に該引数を与える命令である、
ことを特徴とする請求項１又は２記載のソフトウェア間通信の中継方法。
【請求項４】
前記第１の送信ステップは、前記第１のＷｅｂドキュメントの送信元アドレスと前記第２のＷｅｂドキュメントの送信元アドレスとが、前記クライアントにおいて互いに異なると判定されるように、各Ｗｅｂドキュメントに一意のアドレスを割り当てて該クライアントに送信することを特徴とする請求項１、２または３記載のソフトウェア間通信の中継方法。
【請求項５】
クライアントからのリクエストに基づいて第１の対象サーバから第１のＷｅｂドキュメントを取得して該クライアントに中継したときに該クライアント内のブラウザ内で実行される連携元ソフトウェアと、前記クライアントからのリクエストに基づいて第２の対象サーバから第２のＷｅｂドキュメントを取得して前記クライアントに中継したときに前記ブラウザ内で実行される連携先ソフトウェアとの間の通信を中継する中継装置において、
前記第１のＷｅｂドキュメントに、前記連携元ソフトウェアの識別子と該連携元ソフトウェア内で実行される第１の関数の識別子と該第１の関数に与えられる引数を含む第１のイベント通知を、前記連携元ソフトウェアから自中継装置に送信させるための第１の命令を注入する第１の注入部と、
前記第２のＷｅｂドキュメントに、第２の関数の識別子と前記引数を含む自中継装置からのからの第２のイベント通知に基づいて、前記連携先ソフトウェアが該第２の関数を該引数により実行するための第２の命令を注入する第２の注入部と、
前記第１の命令が注入された第１のＷｅｂドキュメントおよび前記第２の命令が注入された第２のＷｅｂドキュメントを前記クライアントに送信する第１の送信部と、
前記連携元ソフトウェアから、前記第１のイベント通知を受信したときに、連携元ソフトウェアの識別子と該連携元ソフトウェアで実行された第１の関数の識別子の組み合わせに対応付けて、該連携元ソフトウェアとの通信が行われる連携先ソフトウェアの識別子と該連携先ソフトウェアで実行される第２の関数の識別子の組み合わせを保持した連携定義テーブルを参照し、該第１のイベント通知に含まれる該連携元ソフトウェアの識別子と該連携元ソフトウェアで実行された第１の関数の識別子の組み合わせに対応する、連携先ソフトウェアの識別子と該連携先ソフトウェアで実行される第２の関数の識別子の組み合わせを決定する決定部と、
前記決定された組み合わせに含まれる前記連携先ソフトウェアの識別子に基づいて特定される連携先ソフトウェアに対して、前記第２のイベント通知として、該決定された組み合わせに含まれる前記第２の関数の識別子と前記引数とを送信する第２の送信部と、
を含むことを特徴とするソフトウェア間通信の中継装置。
【請求項６】
第１の対象サーバから中継サーバを経由して取得した第１のＷｅｂドキュメントに基づいて、クライアントのブラウザ内で実行される連携元ソフトウェアと、第２の対象サーバから該中継サーバを経由して取得した第２のＷｅｂドキュメントに基づいて、該ブラウザ内で実行される連携先ソフトウェアとの間の通信を該中継サーバにおいて中継するプログラムであって、
前記中継サーバに、
前記第１のＷｅｂドキュメントに、前記連携元ソフトウェアの識別子と該連携元ソフトウェア内で実行される第１の関数の識別子と該第１の関数に与えられる引数を含む第１のイベント通知を、前記連携元ソフトウェアが前記中継サーバに送信するための第１の命令を注入する第１の注入ステップと、
前記第２のＷｅｂドキュメントに、第２の関数の識別子と前記引数を含む前記中継サーバからの第２のイベント通知に基づいて、前記連携先ソフトウェアが該第２の関数を該引数により実行するための第２の命令を注入する第２の注入ステップと、
前記第１の命令が注入された第１のＷｅｂドキュメントおよび前記第２の命令が注入された第２のＷｅｂドキュメントを前記クライアントに送信する第１の送信ステップと、
前記連携元ソフトウェアから、前記第１のイベント通知を受信したときに、連携元ソフトウェアの識別子と該連携元ソフトウェアで実行された第１の関数の識別子の組み合わせに対応付けて、該連携元ソフトウェアとの通信が行われる連携先ソフトウェアの識別子と該連携先ソフトウェアで実行される第２の関数の識別子の組み合わせを保持した連携定義テーブルを参照し、該第１のイベント通知に含まれる該連携元ソフトウェアの識別子と該連携元ソフトウェアで実行された第１の関数の識別子の組み合わせに対応する、連携先ソフトウェアの識別子と該連携先ソフトウェアで実行される第２の関数の識別子の組み合わせを決定するステップと、
前記決定された組み合わせに含まれる前記連携先ソフトウェアの識別子に基づいて特定される連携先ソフトウェアに対して、前記第２のイベント通知として、該決定された組み合わせに含まれる前記第２の関数の識別子と前記引数とを送信する第２の送信ステップと、
を実行させるためのプログラム。
【図３】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１４】
【図１】
【図２】
【図４】
【図５】
【図６】
【図７】
【図１３】
【図１５】
【図１６】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１４】
【図１】
【図２】
【図４】
【図５】
【図６】
【図７】
【図１３】
【図１５】
【図１６】
【公開番号】特開２０１０−２６２４５３（Ｐ２０１０−２６２４５３Ａ）
【公開日】平成２２年１１月１８日（２０１０．１１．１８）
【国際特許分類】
【出願番号】特願２００９−１１２３２１（Ｐ２００９−１１２３２１）
【出願日】平成２１年５月１日（２００９．５．１）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２２年１１月１８日（２０１０．１１．１８）
【国際特許分類】
【出願日】平成２１年５月１日（２００９．５．１）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]