JP2015072653A - 中継装置、中継方法、及び中継プログラム - Google Patents

Abstract

【課題】クラウドプラットフォームの制限を回避するための適切な非同期通信を実現する。
【解決手段】通信ネットワークを介して接続されたクラウドプラットフォームからのリクエストに対応させて前記クラウドプラットフォームと外部システムとのデータ通信を中継する中継装置において、前記クラウドプラットフォームからのリクエストを受け付け、受け付けた前記リクエストを登録し、該登録した結果を前記クラウドプラットフォームに送信する要求受付手段と、前記クラウドプラットフォームとの通信とは非同期に前記外部システムと通信を行い、前記要求受付手段により登録された前記リクエストに対するレスポンスを前記外部システムから取得し、取得した前記レスポンスを前記クラウドプラットフォームに送信する処理を実行する非同期処理実行手段とを有する。
【選択図】図３

Description

本発明は、クラウドプラットフォームの制限を回避するための非同期通信技術に関連するものである。

近年、１以上の情報処理装置を有するクラウドコンピューティングシステムを用いてデータ管理や各種処理を行う形態が普及し始めている。ユーザは、例えばクライアントコンピュータのＷｅｂブラウザ等からインターネット等を介してクラウドサーバコンピュータのＷｅｂページにアクセスし、そのＷｅｂページ上で閲覧したいデータを表示する。また、その画面からメールの受信指示を行うと、メールサーバに要求が送信され、メールサーバから取得したメールがＷｅｂ画面上で表示される。

なお、従来では、Ｗｅｂ画面からメールサーバに要求する際に、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＰＯＰ（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ）／ＩＭＡＰ（Ｉｎｔｅｒｎｅｔ Ｍｅｓｓａｇｅ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）等のプロトコル変換を行ってメールの送受信を行う手法が存在する（例えば、特許文献１及び２参照）。

特開２００８−０７８７７４号公報 特開２００３−０３０１１６号公報

ところで、上述したようなクラウドコンピューティングシステムを用いたクラウドプラットフォームの中には、外部システムとの通信の際に、通信プロトコルの制限や通信時間、通信データサイズ等が制限されるものがある。また、プロトコルが異なるシステム間で通信を行う場合には、その変換を行うＥＡＩ（Ｅｎｔｅｒｐｒｉｓｅ Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｔｅｇｒａｔｉｏｎ）システムの導入が一般的である。

しかしながら、ＥＡＩシステムは、リクエスト・レスポンス方式で通信を行うため、リクエストを送信してからレスポンスを取得するまでの通信時間がかかり、上述した通信時間の制限を回避することができずに、通信が途中で途切れたり、必要な情報を取得できないといった問題が生じる。

また、例えばメールサーバ上に受信対象となる未読メールが大量にたまっている場合には、受信データサイズの制限により受信メールが取得できなかったり、サーバ負荷やネットワーク輻輳等の原因で応答遅延が発生することで、通信時間の制限により通信が途切れる場合がある。このような状況は、事前に予測ができないため、リクエスト側（クラウドプラットフォーム側）で自律的に回避する制御もできない。

本発明は上記の点に鑑みてなされたものであり、クラウドプラットフォームの制限を回避した適切な非同期通信を実現する技術を提供することを目的とする。

上記の課題を解決するために、本発明の一態様における中継装置は、通信ネットワークを介して接続されたクラウドプラットフォームからのリクエストに対応させて前記クラウドプラットフォームと外部システムとのデータ通信を中継する中継装置において、前記クラウドプラットフォームからのリクエストを受け付け、受け付けた前記リクエストを登録し、該登録した結果を前記クラウドプラットフォームに送信する要求受付手段と、前記クラウドプラットフォームとの通信とは非同期に前記外部システムと通信を行い、前記要求受付手段により登録された前記リクエストに対するレスポンスを前記外部システムから取得し、取得した前記レスポンスを前記クラウドプラットフォームに送信する処理を実行する非同期処理実行手段とを有する。

また、前記中継装置は、前記クラウドプラットフォーム又は前記外部システムと通信する場合に、プロトコル変換を行うプロトコル変換手段を有していてもよい。

また、前記非同期処理実行手段は、前記外部システムから得られたレスポンスに対し、所定のレスポンス数に応じたデータセットを作成し、作成した前記データセット毎に前記クラウドプラットフォームにデータを送信してもよい。

また、前記非同期処理実行手段は、前記要求受付手段により前記リクエストを受け付けた後、又は、予め設定された時間間隔で、前記要求受付手段により登録された未処理のリクエストに対するレスポンスを前記外部システムから取得してもよい。

また、本発明の一態様は、前記中継装置が実行する中継方法、及び、コンピュータを、前記中継装置における各手段として機能させるための中継プログラムとして構成することもできる。

本発明によれば、クラウドプラットフォームの制限を回避するための適切な非同期通信を実現することができる。

非同期通信システムのシステム構成例を示す図である。 中継システムの概略構成例を示す図である。 中継システムの機能構成例を示す図である。 本実施形態における中継処理が実現可能なハードウェア構成の一例を示す図である。 中継システムが管理するデータ項目例を示す図である。 第１実施例における中継処理の一例を示すシーケンス図である。 第１実施例における中継システム処理の一例を示すフローチャートである。 第２実施例における中継処理の一例を示すシーケンス図である。 第２実施例における中継システム処理の一例を示すフローチャート（その１）である。 第２実施例における中継システム処理の一例を示すフローチャート（その２）である。 ユーザ端末で表示される画面例を示す図である。

以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

＜非同期通信システム：システム構成例＞
図１は、非同期通信システムのシステム構成例を示す図である。図１に示す非同期通信システム１０は、１又は複数のユーザ端末１１−１〜１１−ｎ（以下、必要に応じて「ユーザ端末１１」と総称する。）と、クラウドプラットフォーム１２と、中継装置の一例としての中継システム１３と、外部システムの一例としてのメールサーバ１４とを有する。ユーザ端末１１、クラウドプラットフォーム１２、中継システム１３、及びメールサーバ１４は、それぞれインターネット等に代表される通信ネットワークによりデータの送受信が可能な状態で接続されている。

本実施形態における非同期通信システム１０は、図１に示すようにクラウドプラットフォーム１２と、通信対象となるメールサーバ１４との間で、データ通信を中継するためのシステム（中継システム１３）を有する。

ユーザ端末１１は、クラウドプラットフォーム１２を利用するユーザの端末である。ユーザ端末１１は、例えばＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）やサーバ等であるが、これに限定されるものではなく、例えばスマートフォンやタブレット端末、携帯電話、ゲーム機器等であってもよい。

クラウドプラットフォーム１２は、１以上の情報処理装置を有するクラウドコンピューティング等を利用したサービス上で、データ管理や各種処理等を行う。情報処理装置は、例えばＰＣやサーバ、データベース等であるが、これに限定されるものではない。

ユーザ端末１１は、通信ネットワークを介してクラウドプラットフォーム１２にアクセスし、そのＷｅｂ画面（Ｗｅｂページ）上でメールの受信処理を指示する。クラウドプラットフォーム１２では、その画面からメール受信指示を行うと、中継システム１３に転送される。その後、クラウドプラットフォーム１２は、中継システム１３からのメール取得結果を受けて、その内容をユーザ端末１１に閲覧可能に表示する。

ここで、クラウドプラットフォーム１２を用いたサービスの代表例として、例えばＳａｌｅｓｆｏｒｃｅ．ｃｏｍ社のＳａｌｅｓｆｏｒｃｅ．ｃｏｍ（登録商標）があるが、これに限定されるものではない。

ここで、クラウドプラットフォーム１２側では、例えばアウトバウンド通信（例えば、クラウドプラットフォーム１２から外部装置に対する通信）に対する制限や、インバウンド通信（外部装置からクラウドプラットフォーム１２に対する通信）に対する制限が設けられている。

アウトバウンド通信では、例えば通信プロトコルの制限（ＨＴＴＰ／ＨＴＴＰＳ（ＨＴＴＰ ｏｖｅｒ ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）／ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）通信のみ等）、受信データサイズの制限（例えば、１回の通信で受信可能なデータは２ＭＢまで等）、通信時間の制限（例えば、１回の通信が完了するまでの時間は１２０秒以内等）があるが、これに限定されるものではない。また、インバウンド通信では、例えば通信回数の制限（例えば、クラウドプラットフォーム１２への通信は２４時間で１０００［回／利用者］等）の制限があるが、これに限定されるものではない。クラウドプラットフォーム１２は、上述した各種の制限に抵触すると通信エラーとなる。

したがって、本実施形態において、クラウドプラットフォーム１２から指示を受けた中継システム１３は、ユーザ端末１１とクラウドプラットフォーム１２との通信とは異なる非同期でメールサーバ１４と通信を行い、リクエストに対応するメールをメールサーバ１４等の外部システムから取得する。

中継システム１３は、上述したアウトバウンド通信における制限の回避・軽減や、インバウンド通信における制限の回避・軽減等を行う。また、中継システム１３は、クラウドプラットフォーム１２から得られるリクエストをＨＴＴＰやＨＴＴＰＳで受信した場合に、メールサーバ１４との通信条件等に対応させて所定のプロトコル（例えば、ＰＯＰ／ＩＭＡＰ等にプロトコル変換を行う。また、中継システム１３は、メールサーバ１４から取得したメールをクラウドプラットフォーム１２に送信する場合にも通信条件等に対応させてプロトコル変換を行う。

例えば、中継システム１３は、クラウドプラットフォーム１２からのリクエストに対し、すぐにリクエスト受領を知らせるレスポンスをクラウドプラットフォーム側に返す。その後、中継システム１３は、そのリクエストとは非同期で、メールサーバ１４に対して対応プロトコルを使ってデータ取得をリクエストする。中継システム１３は、データ取得が完了すると、クラウドプラットフォーム１２に対して制限を回避するための制御を行いつつデータを登録する。

メールサーバ１４は、他の装置等から通信ネットワーク等を介して送受信されるメールを管理する。メールサーバ１４は、中継システム１３からの受信問い合わせに対して、対応するユーザのメールを抽出し、抽出したメールを中継システム１３へ送信する。

なお、本実施形態における外部システムは、メールサーバ１４に限定されるものではなく、例えばデータを取得するためのデータベースサーバや、予約を行う予約サーバ、顧客を管理する顧客管理サーバ、その他の各種業務サーバ等を用いてもよい。また、外部システムは、１又は複数のサーバ等の装置で構成されていてもよい。中継システム１３は、例えばユーザ端末１１からの要求（リクエスト）に応じて対応する装置にアクセスし、要求に応じたレスポンスに関する情報を取得する。

＜中継システム１３の概略構成例＞
次に、上述した中継システム１３の概略構成例について、図を用いて説明する。図２は、中継システムの概略構成例を示す図である。図２の例では、中継システム１３の概略構成の他にクラウドプラットフォーム１２及び外部システムの一例であるメールサーバ１４も示している。

図２に示す中継システム１３は、ルータ２１と、ファイアウォール２２と、ロードバランサ２３と、１又は複数のＷｅｂサーバ２４−１〜２４−ｎ（以下、必要に応じて「Ｗｅｂサーバ２４」という）と、１又は複数のデータベースサーバ（以下、「ＤＢサーバ」という）２５−１〜２５−ｎ（以下、必要に応じて「ＤＢサーバ２５」という）とを有するよう構成されている。

ルータ２１は、中継システム１３が、クラウドプラットフォーム１２やメールサーバ１４等の外部装置と通信ネットワークを介してデータを中継する通信手段である。ルータ２１は、例えばデータをどのルートを通して転送すべきかを判断するルート選択機能を有する。

ファイアウォール２２は、中継システム１３内部の装置と外部装置との通信を制御し、内部の装置や通信ネットワーク上の安全を維持することを目的としたソフトウェアやそのソフトウェアを搭載したハードウェアである。

ロードバランサ２３は、例えばクラウドプラットフォーム１２等の外部装置からの要求を一元的に管理し、同等の機能を持つ複数のサーバ（例えば、Ｗｅｂサーバ２４やＤＢサーバ２５）に要求を転送する装置である。ロードバランサ２３は、各サーバに要求を分散して送信する負荷分散機能を有し、各サーバが快適な応答速度を保つように制御を行う。

Ｗｅｂサーバ２４は、本実施形態における各種の非同期通信等を実行する。例えば、Ｗｅｂサーバ２４は、ＨＴＴＰ等にしたがってクラウドプラットフォーム１２上のソフトウェア（例えば、ウェブブラウザ等）に対して、ＨＴＭＬや所定のオブジェクト（例えば、メールや画像）の表示を提供するサービスプログラムを動作させる。

また、Ｗｅｂサーバ２４は、クラウドプラットフォーム１２からの要求（例えば、ユーザ端末１１からのメール問い合わせ等）を受け付けると共に、クラウドプラットフォーム１２との回線を切断し、非同期に外部システム（例えば、メールサーバ１４等）にアクセスして、要求に対応する回答（例えば、メール）を取得する。

また、Ｗｅｂサーバ２４は、取得した回答（例えば、受信メール）をＤＢサーバ２５に記憶すると共に、所定の時間毎、メール問い合わせ結果の取得時、又は、所定のデータ量以上になった場合等の所定のタイミングで、クラウドプラットフォーム１２に結果を出力する。

なお、クラウドプラットフォーム１２には、中継システム１３との通信、登録されたメールの閲覧等を行うための中継システム専用のアプリケーションを有する。ユーザは、ユーザ端末１１上のブラウザからこのアプリケーションにアクセスしてサービスを利用する。

Ｗｅｂサーバ２４は、例えばＣｅｎｔＯＳ（Ｃｏｍｍｕｎｉｔｙ ＥＮＴｅｒｐｒｉｓｅ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）やＷｉｎｄｏｗｓ（登録商標）等のＯＳを用いることができ、更にＡｐａｃｈｅ（登録商標）等のオープンソースのＷｅｂサーバソフトウェアやＰＨＰ（Ｈｙｐｅｒｔｅｘｔ Ｐｒｅｐｒｏｃｅｓｓｏｒ）等を用いることができるが、これらに限定されるものではない。

ＤＢサーバ２５は、クラウドプラットフォーム１２からの各ユーザ端末１１からの要求や処理状況（ステータス）等を記憶して管理したり、メールサーバ１４からのメールを記憶して管理する記憶手段である。また、ＤＢサーバ２５は、あるＤＢサーバと同一内容の複製（レプリカ）を別のＤＢサーバ上に作成し、常に内容を同期させるレプリケーション機能を有していてもよい。ＤＢサーバ２５は、例えばＣｅｎｔＯＳやＷｉｎｄｏｗｓ（登録商標）等のＯＳを用いることができ、更にＭｙＳＱＬ（登録商標）等のデータベース管理システム等を用いることができるが、これらに限定されるものではない。

なお、上述したＷｅｂサーバ２４やＤＢサーバ２５は、１台で構成されていてもよく、その場合には、図２に示す中継システム１３は、ロードバランサ２３を有しない構成となる。

＜中継システム１３の機能構成例＞
次に、中継装置の一例である中継システム１３の機能構成例について、図を用いて説明する。図３は、中継システムの機能構成例を示す図である。図３の例において、中継システム１３は、入力手段３１と、出力手段３２と、記憶手段３３と、要求受付手段３４と、プロトコル変換手段３５と、非同期処理実行手段３６と、負荷分散手段３７と、通信手段３８と、制御手段３９とを有するよう構成されている。

入力手段３１は、例えば中継システム１３を使用する管理者等からの本実施形態に係る中継処理に関する各種指示の開始／終了等の入力を受け付ける。なお、入力手段３１は、例えばＰＣ等の汎用のコンピュータであればキーボードやマウス等のポインティングデバイスからなる。

出力手段３２は、入力手段３１により入力された内容や、入力内容に基づいて実行された処理結果等の出力を行う。なお、出力手段３２は、例えばディスプレイやスピーカ等からなる。また、出力手段３２は、例えば処理結果をＷｅｂ上に公開したり、画面出力する機能を有する。また、出力手段３２は、プリンタ等の印刷機能を有し、紙媒体等で処理結果を印刷してもよい。

記憶手段３３は、本実施形態において必要となる各種情報を記憶する。具体的には、本実施形態における中継処理を実行するための各種プログラムや各要求（例えば、メール問い合わせ等）、処理結果等の情報を記憶する。

なお、記憶手段３３は、上述した各種情報を必要に応じて所定のタイミングで書き込んだり、読み出したりすることができる。記憶手段３３は、上述したような多種の情報の集合物であり、それらの情報を、例えばキーワード等を用いて検索し、抽出することができるように体系的に構成されているデータベースとしての機能も有していてもよい。更に、記憶手段３３に記憶される情報は、例えば通信ネットワークを介して外部装置から取得してもよい。記憶手段３３は、例えば上述したＤＢサーバ２５に対応する。

要求受付手段３４は、クラウドプラットフォーム１２からの処理要求を受け付ける。また、要求受付手段３４は、受け付けた要求を記憶手段３３に登録する。

プロトコル変換手段３５は、クラウドプラットフォーム１２から得られる要求内容に応じてアクセス先の外部システムで処理可能なプロトコル形式に変換する。例えば、プロトコル変換手段３５は、クラウドプラットフォーム１２とＨＴＴＰ／ＨＴＴＰＳプロトコルで通信を行っており、更にその通信で得られたリクエストをメールサーバ１４に送信する場合には、ＨＴＴＰ／ＨＴＴＰＳプロトコルから、例えばＰＯＰ／ＩＭＡＰプロトコルへの変換を行う。また、メールサーバ１４と通信して得られた結果を、クラウドプラットフォーム１２に送信する場合には、ＰＯＰ／ＩＭＡＰプロトコルからＨＴＴＰ／ＨＴＴＰＳプロトコルへの変換を行う。

なお、どのプロトコルに変換するかについては、予め通信を行う外部システムに応じてプロトコル変換情報が設定され、記憶手段３３に記憶されているため、その情報を参照することで、通信条件に応じた適切なプロトコル変換を行うことができる。プロトコルの種類については、上述した内容に限定されるものではない。

非同期処理実行手段３６は、クラウドプラットフォーム１２との通信とは非同期でメールサーバ１４等の外部システムと通信等を行い、クラウドプラットフォーム１２から要求された処理を記憶手段３３から読み出し、呼び出した処理を実行する。

また、非同期処理実行手段３６は、例えばメールサーバ１４等の外部システムとの通信により要求に対応する回答（レスポンス）を取得した後、メールサーバ１４との通信とは非同期にクラウドプラットフォーム１２と通信を行い、回答を送信する。なお、非同期処理実行手段３６は、例えば取得した回答数（レスポンス数）に応じて、クラウドプラットフォーム１２で予め設定された１回の通信で受信可能なデータ件数等の制限に基づいて、所定の件数毎に分割したデータセットを作成し、作成したデータセット毎にクラウドプラットフォーム１２へ送信を行う。非同期処理実行手段３６は、上述した処理の実行結果や経過（状況）等を記憶手段３３に記憶して管理する。

上述した要求受付手段３４、プロトコル変換手段３５、及び非同期処理実行手段３６は、例えば上述したＷｅｂサーバ２４に対応する。

負荷分散手段３７は、例えば上述したロードバランサ２３に対応する。上述した要求受付手段３４やプロトコル変換手段３５、非同期処理実行手段３６における処理を複数の装置やプロセッサ（ＣＰＵ）等で処理している場合に、これらの負荷を計測し、その計測結果に基づいて、負荷が均等になるように処理を分散させる。

例えば、負荷分散手段３７は、クラウドプラットフォーム１２からのリクエスト数又はメールサーバ１４からのレスポンス数に応じて記憶手段３３や要求受付手段３４、プロトコル変換手段３５、非同期処理実行手段３６等における負荷を分散する。なお、中継システム１３が１つの装置やプロセッサで構成されている場合には、中継システム１３内に負荷分散手段３７の機能を設けていなくてもよい。

通信手段３８は、例えば通信ネットワーク等を用いて接続可能な外部装置（クラウドプラットフォーム１２やメールサーバ１４等）から本実施形態における各処理に必要な情報や取得した情報等を送受信したり、本実施形態における中継処理を実現するための実行プログラム等を送受信することが可能なインタフェースである。

制御手段３９は、中継システム１３の各構成全体の制御を行う。例えば、制御手段３９は、要求受付手段３４による各種要求の受け付けや、プロトコル変換手段３５による通信プロトコルの変換、非同期処理実行手段３６による非同期通信による処理の実行、負荷分散手段３７による負荷分散等の各処理のうち、少なくとも１つを制御する。なお、制御手段３９における処理内容は、これに限定されるものではなく、例えばエラー発生時の制御等も行う。

＜中継システム１３のハードウェア構成例＞
例えば、上述した中継システム１３の各機能をコンピュータに実行させる実行プログラム（中継プログラム）を生成し、例えば汎用のＰＣ、サーバ等のコンピュータにインストールすることにより、本実施形態における中継処理等を実現することができる。図４は、本実施形態における中継処理が実現可能なハードウェア構成の一例を示す図である。

図４におけるコンピュータ本体は、入力装置４１と、出力装置４２と、ドライブ装置４３と、補助記憶装置４４と、主記憶装置４５と、各種制御を行うＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）４６と、ネットワーク接続装置４７とを有するよう構成され、これらはシステムバスＢで相互に接続されている。

入力装置４１は、例えば中継システム１３の管理者等が操作するキーボードやマウス等のポインティングデバイスを有しており、例えば管理者等からのプログラムの実行等、各種操作信号を入力する。出力装置４２は、本発明における処理を行うコンピュータ本体を操作するのに必要な各種ウィンドウやデータ等を表示するディスプレイを有し、ＣＰＵ４６が実行する制御プログラムの実行経過や結果等を表示する。

ここで、本発明においてコンピュータ本体にインストールされる実行プログラムは、例えばＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリやＣＤ−ＲＯＭ等の可搬型の記録媒体４８等により提供される。記録媒体４８は、ドライブ装置４３にセット可能であり、記録媒体４８に含まれる実行プログラムが、記録媒体４８からドライブ装置４３を介して補助記憶装置４４にインストールされる。

補助記憶装置４４は、ハードディスク等のストレージ手段であり、本発明における実行プログラムやコンピュータに設けられた制御プログラム等を蓄積し、必要に応じて入出力を行う。

主記憶装置４５は、ＣＰＵ４６により補助記憶装置４４から読み出された実行プログラム等を格納する。なお、主記憶装置４５は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等である。

ＣＰＵ４６は、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）等の制御プログラム、及び主記憶装置４５に格納されている実行プログラムに基づいて、各種演算や各ハードウェア構成部とのデータの入出力等、コンピュータ全体の処理を制御することで、情報提供における各処理を実現する。なお、プログラム実行中に必要な各種情報等は、補助記憶装置４４から取得し、実行結果等を格納してもよい。

ネットワーク接続装置４７は、通信ネットワーク１５等と接続することにより、実行プログラムを通信ネットワーク１５に接続されている他の端末等から取得したり、プログラムを実行することで得られた実行結果又は本発明における実行プログラム自体を他の端末等に提供したりする。

本実施形態では、上述したコンピュータ本体のハードウェア構成に実行プログラム（例えば、中継プログラム等）をインストールすることで、ハードウェア資源とソフトウェアとが協働して本実施形態における中継処理等を実現することができる。

＜中継システム１３が管理するデータ項目例＞
次に、中継システム１３が管理するデータ項目例について、図を用いて説明する。図５は、中継システムが管理するデータ項目例を示す図である。図５（Ａ）はユーザ情報の一例を示し、図５（Ｂ）は本実施形態における非同期通信を管理する管理テーブルの一例を示し、図５（Ｃ）は、受信メール情報の一例を示し、図５（Ｄ）は、プロトコル変換情報を示している。なお、図５（Ａ）〜図５（Ｃ）は、それぞれユーザＩＤで関連付けられている。また、図５（Ａ）〜図５（Ｄ）の各情報は、記憶手段３３（ＤＢサーバ２５）に記憶して管理される。

図５（Ａ）に示すユーザ情報の項目としては、例えば「ユーザＩＤ」、「ユーザアカウントＩＤ」、「クラウドプラットフォームアカウントＩＤ」、「メール接続アカウント名」、「メール接続パスワード」、「ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）認証用アカウント名」、「ＳＭＴＰ認証用パスワード」、「差出人アドレス」、「差出人名」、「有効／無効フラグ」、「最終メール同期時刻」、「認証有効フラグ」、「作成日時」、「更新日時」等があるが、これに限定されるものではない。

図５（Ａ）に示すユーザ情報では、中継システム１３の利用する個々のユーザ情報を保持する。したがって、個々のユーザにおけるクラウドプラットフォーム１２側のＩＤ情報や、メールサーバ１４に接続するためのアカウント情報等を保持する。また、メールサーバ１４以外の外部装置にアクセスする場合には、その装置にアクセスするためデータが登録される。

例えば、図５（Ａ）に示す「クラウドプラットフォームアカウントＩＤ」は、個々のユーザにおけるクラウドプラットフォーム１２側のＩＤであり、中継システム１３からクラウドプラットフォーム１２にメールを登録するときは、このＩＤをメールの所有者として登録する。

また、図５（Ｂ）に示す管理テーブルの項目としては、例えば「トリガーＩＤ」、「ユーザＩＤ」、「メールトリガー」、「トリガー設定日時」、「作成日時」、「更新日時」等があるが、これに限定されるものではない。

図５（Ｂ）に示す管理テーブルは、例えばユーザ端末１１からのメール取得リクエストを、クラウドプラットフォーム１２を介してメール取得フラグ登録リクエストとして受信したときに参照される。管理テーブルは、ユーザＩＤ毎にメールを非同期で取得する際のステータス情報等を管理しており、例えば「メールトリガー」等にそのステータスを識別する情報としてメール取得フラグ等を格納する。

メール取得フラグの具体例としては、例えばメール取得リクエストを受領可能な状態を「０」とし、メール取得リクエストを受け付け済みでメール取得処理が未処理の状態を「１」とし、メール取得処理中の状態を「２」とすることができるが、識別する種類や値については、これに限定されるものではない。管理テーブルを作成したり、更新したり、メールトリガーを設定した場合には、その作成日時や更新日時、トリガー設定日時も管理テーブルに記憶される。

また、図５（Ｃ）に示す受信メール情報の項目としては、例えば「受信メールＩＤ」、「ユーザＩＤ」、「メールフォルダＩＤ」、「ＵＩＤ」、「メッセージＩＤ」、「ＴＥＸＴ／ＨＴＭＬ」、「既読フラグ」、「メッセージ送信者名」、「メッセージ送信者アドレス」、「メッセージ受信者名」、「メッセージ受信者アドレス」、「受信日時」、「メッセージ件名」、「メッセージ本文」、「添付ファイルＩＤ」、「添付ファイル名」、「返信／転送した対象のメッセージＩＤ」、「クラウドプラットフォームメールＩＤ」、「同期日時」、「作成日時」、「更新日時」等があるが、これに限定されるものではない。

図５（Ｃ）に示す受信メール情報は、例えばメールサーバ１４から取得したメールを保存し、メールのステータスも管理する。図５（Ｃ）に示す受信メール情報において「ユーザＩＤ」は、中継システム１３において各種データを管理するためのユーザ情報であり、「ＵＩＤ」とは、メールサーバ１４においてメールを識別するための情報である。

また、図５（Ｃ）に示す「クラウドプラットフォームメールＩＤ」は、この項目が空かどうかによって、メールがクラウドプラットフォーム１２側に登録済みか否かのステータスを管理する。中継システム１３でメールサーバ１４からメールを取得して、クラウドプラットフォーム１２に登録する場合には、まずメールサーバ１４から取得したメールを図５（Ｃ）に示す受信メールに保存する。このとき「クラウドプラットフォームメールＩＤ」は、空の状態とする。つまり、「登録待ち」の状態となる。

次に、「クラウドプラットフォームメールＩＤ」が空のメールを対象にクラウドプラットフォーム１２に登録処理を行う。登録処理が完了すると、個々のメール毎にユニークなＩＤがクラウドプラットフォーム１２から返される。そのため、非同期処理実行手段３６は、そのＩＤを「クラウドプラットフォームメールＩＤ」に登録する。これにより、「登録済み」の状態となる。なお、上述した登録処理でエラーが発生した場合には、非同期処理実行手段３６は、その旨を示す情報を「クラウドプラットフォームメールＩＤ」に登録する。これにより、「登録エラー」の状態となる。

また、図５（Ｃ）に示す「同期日時」には、上述した「クラウドプラットフォームメールＩＤ」が「登録済み」又は「登録エラー」になった日時を登録する。これにより、非同期通信におけるステータス管理を適切に行うことができる。

また、図５（Ｄ）に示すプロトコル変換情報の項目としては、例えば「非同期通信先」、「通信可能プロトコル」等があるが、これに限定されるものではない。本実施形態では、中継システム１３から外部システムと通信する場合に、図５（Ｄ）に示すプロトコル変換情報を参照して、その通信先に対して通信なプロトコル情報を取得し、取得したプロトコル情報と、現在のプロトコル情報とが異なる場合に、プロトコル変換手段３５により変換が行われる。

例えば、図５（Ｄ）に示すプロトコル変換情報を参照し、メールサーバ１４にアクセスする場合には、ＰＯＰ／ＩＭＡＰ等への変換が必要である場合、プロトコル変換手段３５は、現在のプロトコル（例えば、ＨＴＴＰ）からＰＯＰ／ＩＭＡＰ等へのプロトコル変換を行う。なお、図５（Ｄ）に示すプロトコル変換情報は、処理実行前に予め登録されている。

＜本実施形態における中継処理例＞
次に、本実施形態の非同期通信における中継処理の各実施例について、図を用いて説明する。

＜第１実施例＞
図６は、第１実施例における中継処理の一例を示すシーケンス図である。第１実施例では、クラウドプラットフォーム１２から随時リクエストを受領し、中継システム１３ですぐに処理を行う。図６の例では、ユーザ端末１１と、クラウドプラットフォーム１２と、中継システム１３と、メールサーバ１４とを有する。

図６の例に示す第１実施例において、ユーザ端末１１は、Ｗｅｂブラウザ等を用いてクラウドプラットフォーム１２にアクセスし、メール取得リクエストを送信する（Ｓ０１）。クラウドプラットフォーム１２は、ユーザ端末１１から取得したメール取得リクエストをメール取得フラグ登録リクエストとして中継システム１３に送信する（Ｓ０２）。

中継システム１３は、要求受付手段３４により要求を受け付けて登録した後、対象ユーザのメール取得フラグ（例えば、上述した図５（Ｂ）に示す管理テーブルの「メールトリガー」）を「１」に更新する（Ｓ０３）。また、中継システム１３は、Ｓ０３の処理後、メール取得フラグ登録結果レスポンスをクラウドプラットフォーム１２に送信する（Ｓ０４）。クラウドプラットフォーム１２は、メール取得リクエスト完了レスポンスをユーザ端末１１に送信する（Ｓ０５）。ここで、ユーザ端末１１とクラウドプラットフォーム１２との間の通信を切断してもよい。

次に、中継システム１３は、メールサーバ１４に対して対象ユーザのメール取得をリクエストする（Ｓ０６）。メールサーバ１４は、メールを受け付けると、対象ユーザのメールを取得し、そのメールをレスポンスとして中継システム１３に送信する（Ｓ０７）。

中継システム１３は、メールサーバ１４から取得したメールを記憶手段３３（ＤＢサーバ２５）に登録する（Ｓ０８）。このとき、記憶手段３３に登録された対象ユーザのメールのステータスを「登録待ち」とする。例えば、中継システム１３は、メールサーバ１４からメールを取得し、そのメールに関する情報を、例えば上述した図５（Ｃ）に示す受信メール情報に登録する際、「クラウドプラットフォームメールＩＤ」の値を空にしておくことで、メールのステータスを、クラウドプラットフォーム１２に対する「登録待ち」として判断させることができるが、これに限定されるものではない。

次に、中継システム１３は、取得した複数のメールを、クラウドプラットフォーム１２において１回のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）通信で受信可能なデータ件数毎に分割したデータセットを作成する（Ｓ０９）。これは、１回の通信で送信するデータ件数（データ量）がクラウドプラットフォーム１２側の制限を超えないようにするためである。受信可能なデータ件数等の制限は、クラウドプラットフォーム１２上で予め設定されているため、その情報を事前に取得しておくことで、データ件数を超えない範囲でデータセットを作成することができる。

次に、中継システム１３は、例えば上述したＳ０９において、分割してできたデータセット毎にクラウドプラットフォーム１２にメールの登録を行い（Ｓ１０）、クラウドプラットフォーム１２からの登録結果のレスポンスを受信する（Ｓ１１）。また、中継システム１３は、受信したレスポンスを確認し、正常登録されたメールのステータスを「登録済み」に更新する（Ｓ１２）。なお、Ｓ１２の処理では、例えば上述した図５（Ｃ）に示す受信メール情報の「クラウドプラットフォームメールＩＤ」に、クラウドプラットフォーム１２からレスポンスとして得られるメールＩＤを登録することで「登録済み」に更新したと判断することができる。

上述したＳ１０〜Ｓ１２の処理は、データセット毎に繰り返し実行される。次に、中継システム１３は、対象ユーザのメール取得フラグを「０」に更新する（Ｓ１３）。なお、クラウドプラットフォーム１２では、１回のデータセットに対するメールの登録毎に通信は完結し、そのデータに対する登録処理を終了する。

ユーザ端末１１は、Ｓ０５の処理によりメール取得リクエスト完了から所定時間経過後に再度クラウドプラットフォーム１２にアクセスして画面リロードを行うことで（Ｓ１４）、新着メール等がＷｅｂ画面（ブラウザ画面）に表示される（Ｓ１５）。

＜第１実施例における中継システム１３の処理例＞
次に、第１実施例における中継システム１３の処理の一例について、フローチャートを用いて説明する。図７は、第１実施例における中継システム処理の一例を示すフローチャートである。図７の例において、中継システム１３の要求受付手段３４は、メール取得フラグ登録リクエストを受信すると（Ｓ２１）、記憶手段３３に記憶された管理テーブル等を参照し、対象ユーザのメール取得フラグが「０」であるか否かを判断する（Ｓ２２）。

要求受付手段３４は、対象ユーザのメール取得フラグが「０」である場合（Ｓ２２において、ＹＥＳ）、該当するメール取得フラグを「１」に更新する（Ｓ２３）。次に、要求受付手段３４は、クラウドプラットフォーム１２に対してリクエストを正常受領したことをレスポンスする（Ｓ２４）。

次に、非同期処理実行手段３６は、例えば別スレッド（プロセス）でメール取得処理を起動し（Ｓ２５）、メールサーバ１４に接続して対象ユーザのメールを取得する（Ｓ２６）。なお、Ｓ２６の処理において、通信時のプロトコルの変換が必要である場合には、プロトコル変換手段３５により、メールサーバ１４との通信を行うための適切なプロトコルへと変換する。

ここで、非同期処理実行手段３６は、メールの取得が成功したか否かを判断し（Ｓ２７）、メールの取得が成功した場合（Ｓ２７において、ＹＥＳ）、取得したメールをステータス「登録待ち」として登録する（Ｓ２８）。次に、非同期処理実行手段３６は、取得したメールを、クラウドプラットフォーム１２において１回の通信で受け入れ可能なデータ件数毎のデータセットに分割する（Ｓ２９）。

次に、非同期処理実行手段３６は、データセット毎にデータセットがなくなるまで以下に示すＳ３１〜Ｓ３６の処理を繰り返し行う（Ｓ３０）。非同期処理実行手段３６は、データセットをクラウドプラットフォーム１２に登録し、そのレスポンスを受信する（Ｓ３１）。なお、Ｓ３１の処理において、クラウドプラットフォーム１２との通信において、プロトコル変換が必要な場合、プロトコル変換手段３５は、クラウドプラットフォーム１２と通信が可能なプロトコルに変換を行ってもよい。

ここで、非同期処理実行手段３６は、レスポンスの内容を確認し、レスポンス内の全データを確認するまで以下に示すＳ３３〜Ｓ３６の処理を繰り返し行う（Ｓ３２）。非同期処理実行手段３６は、レスポンスから個々のメールの登録結果を取り出して確認し（Ｓ３３）、メールの登録が成功したか否かを判断する（Ｓ３４）。非同期処理実行手段３６は、メールの登録が成功した場合（Ｓ３４において、ＹＥＳ）、対象メールのステータスを「登録済み」に更新する（Ｓ３５）。また、非同期処理実行手段３６は、メールの登録が成功しなかった場合（Ｓ３４において、ＮＯ）、対象メールのステータスを「登録エラー」に更新する（Ｓ３６）。登録エラーとなる場合としては、例えば通信ネットワーク上の障害でクラウドプラットフォーム１２に疎通できなかった場合や、クラウドプラットフォーム１２への認証が失敗した場合、クラウドプラットフォーム１２側で登録可能なデータ量の上限に達した場合等があるが、これに限定されるものではない。

非同期処理実行手段３６は、Ｓ３２の処理におけるレスポンス内容確認ループ及びＳ３０の処理におけるデータセットループが終了後、対象ユーザのメール取得フラグを「１」から「０」に更新し（Ｓ３７）、処理を終了する。

なお、上述したＳ２２の処理において、対象ユーザのメール取得フラグが「０」でない場合（Ｓ３２において、ＮＯ）、要求受付手段３４は、すでにリクエスト受領済みであることをクラウドプラットフォーム１２にレスポンスする（Ｓ３８）。

また、上述したＳ２７の処理において、メールサーバ１４からメールの取得が成功しなかった場合（Ｓ２７において、ＮＯ）、非同期処理実行手段３６は、対象ユーザでエラーが発生したことをクラウドプラットフォーム１２に登録する（Ｓ３９）。メールサーバ１４からの取得に成功しない（失敗する）場合としては、例えば通信ネットワーク上の障害でメールサーバ１４と疎通できなかった場合やメールサーバ１４の障害、対象アカウントのパスワード変更やアカウントの削除等による認証の失敗等があるが、これに限定されるものではない。

上述した第１実施例によれば、ユーザ（クラウドプラットフォーム１２）側からリクエストを受けてから、クラウドプラットフォーム１２に対するデータ登録が完了するまでのタイムラグが小さくなる。

＜第２実施例＞
次に、第２実施例について説明する。上述した第１実施例では、例えばクラウドプラットフォーム１２からの１回リクエストに対し中継システム１３側から１以上のデータの登録を行うため、クラウドプラットフォーム１２に対する通信が多くなり、外部からの通信回数の制限を回避できない可能性がある。

そこで、第２実施例では、クラウドプラットフォームからは随時リクエストを受領し、中継システム１３上では１又は複数のリクエストをまとめて定期的に処理を行う。図８は、第２実施例における中継処理の一例を示すシーケンス図である。図８の例では、ユーザ端末１１と、クラウドプラットフォーム１２と、中継システム１３と、メールサーバ１４とを有する。

図８の例に示す第２実施例において、Ｓ４１〜Ｓ４５の処理は、上述した第１実施例におけるＳ０１〜Ｓ０５の処理と同様であるため、ここでの具体的な説明は省略する。なお、中継システム１３は、例えばユーザ端末１１からのメール取得リクエストがある度に、対象ユーザのメール取得フラグを「１」に更新する。

次に、中継システム１３は、例えば定期的なタイミングで、メールサーバ１４に対してメール取得をリクエストするため、メール取得フラグが「１」（メール取得処理が未処理）のユーザを対象にメール取得処理（バッチ処理）を開始する（Ｓ４６）。定期的なタイミングとは、例えば５分〜１０分等の予め設定された時間間隔である。なお、第２実施例では、これに限定されるものではなく、例えば時間帯（例えば、日中／夜間）や曜日（平日／休日）等に応じて時間間隔を変更してもよい。更に、第２実施例では、上述した時間的なタイミングではなく、メールのリクエスト件数がある一定値以上となったことを基準としてＳ４６以降の処理を行ってもよい。

中継システム１３は、メール取得フラグが「１」のユーザ毎に対象ユーザのメール取得をメールサーバ１４にリクエストし（Ｓ４７）、対象ユーザのメールをレスポンスする（Ｓ４８）。また、中継システム１３は、取得したメールを記憶手段３３に登録する（Ｓ４９）。このとき、中継システム１３は、図５（Ｃ）に示す受信メール情報を作成し、例えば受信メール情報内の「クラウドプラットフォームメールＩＤ」を空とすることで、メールのステータスを「登録待ち」にする。

上述の処理をメール取得フラグが「１」のユーザ毎に行った後、中継システム１３は、クラウドプラットフォーム１２にメールを登録する処理を開始する（Ｓ５１）。中継システム１３は、全てのユーザのメールを対象に、メールのステータスが「登録待ち」のメールを取得し（Ｓ５２）、取得したメールをクラウドプラットフォーム１２において１回のＡＰＩ通信で受信なデータ件数毎のデータセットに分割する（Ｓ５２）。

なお、中継システム１３におけるＳ５３〜Ｓ５５の処理は、上述した第１実施例のＳ５３〜Ｓ５５の処理と同様であるため、ここでの説明は省略する。中継システム１３は、処理が終了したユーザのメール取得フラグを「０」に更新する（Ｓ５６）。

ユーザ端末１１は、Ｓ５５の処理によりメール取得リクエスト完了から所定時間経過後に再度クラウドプラットフォーム１２にアクセスして画面リロードを行うことで（Ｓ５７）、新着メールがブラウザ画面に表示される（Ｓ５８）。

＜第２実施例における中継システム１３の処理例＞
次に、第２実施例における中継システム１３の処理の一例について、フローチャートを用いて説明する。図９、図１０は、第２実施例における中継システム処理の一例を示すフローチャート（その１、その２）である。なお、図９の処理では、メール取得フラグ登録リクエスト受信処理の一例を示し、図１０の処理では、定期メール取得処理の一例を示している。

図９の例において、中継システム１３の要求受付手段３４は、クラウドプラットフォーム１２からメール取得フラグ登録リクエストを受信すると（Ｓ６１）、記憶手段３３に記憶された図５（Ｂ）等に示す管理テーブル等を参照し、対象ユーザのメール取得フラグが「０」であるか否かを判断する（Ｓ６２）。

要求受付手段３４は、対象ユーザのメール取得フラグが「０」である場合（Ｓ６２において、ＹＥＳ）、該当するメール取得フラグを「１」に更新する（Ｓ６３）。次に、要求受付手段３４は、クラウドプラットフォーム１２に対してリクエストを正常受領したことをレスポンスする（Ｓ６４）。

また、非同期処理実行手段３６は、対象ユーザのメール取得フラグが「０」でない場合（Ｓ６２において、ＮＯ）、すでにリクエスト受領済みであることをクラウドプラットフォーム１２にレスポンスする（Ｓ６５）。上述した図９に示すメール取得フラグ登録リクエスト受信処理は、クラウドプラットフォーム１２からの登録リクエストがある毎に行われる。

また、図１０の例に示すように定期メール取得処理を開始した場合には、非同期処理実行手段３６は、メール取得フラグが「１」のユーザを検索し、抽出されたデータを対象ユーザ毎に配列として格納し、その配列が空になるまで、以下に示すＳ７３〜Ｓ７７の処理を行う（Ｓ７２）。

非同期処理実行手段３６は、図５（Ｂ）に示す管理テーブルの対象ユーザのメール取得フラグ（メールトリガー）を「２」に更新し（Ｓ７３）、メールサーバ１４に接続して対象ユーザのメールを取得する（Ｓ７４）。なお、Ｓ７４の処理では、メールサーバ１４と接続する際にプロトコルの変換が必要な場合、プロトコル変換手段３５により所定のプロトコル変換を行う。

次に、非同期処理実行手段３６は、メールの取得が成功したか否かを判断し（Ｓ７５）、メールの取得が成功した場合（Ｓ７５において、ＹＥＳ）、取得したメールを、ステータス「登録待ち」として記憶手段３３に登録する（Ｓ７５）。また、非同期処理実行手段３６は、メールの取得が成功しなかった場合（Ｓ７５において、ＮＯ）、対象ユーザでエラーが発生したことをクラウドプラットフォーム１２に登録する（Ｓ７７）。上述の処理は、対象ユーザ配列が空になるまでループされる。

次に、非同期処理実行手段３６は、全ユーザのメールを対象に、ステータスが「登録待ち」のメールを検索し（Ｓ７８）、検索結果のメールを、クラウドプラットフォームにおいて１回の通信で受け入れ可能なデータ件数毎のデータセットに分割する（Ｓ７９）。

次に、非同期処理実行手段３６は、データセット毎にデータセットがなくなるまで以下に示すＳ８１〜Ｓ８６の処理を繰り返し行う（Ｓ８０）。なお、Ｓ８１〜Ｓ８６の処理は、上述した第１実施例のＳ３０〜Ｓ３６と同様であるため、ここでの具体的な説明は省略する。

次に、非同期処理実行手段３６は、Ｓ８２の処理におけるレスポンス内容確認ループ及びＳ８０の処理におけるデータセットループが終了後、対象ユーザのメール取得フラグを「２」から「０」に更新し（Ｓ３７）、処理を終了する。

上述した第２実施例によれば、クラウドプラットフォームからの複数リクエストを中継システム側でまとめて処理できるため、クラウドプラットフォームに対する通信が少なくなり、外部からの通信回数の制限を回避しやすくなる。

なお、第２実施例では、利用ユーザ（クラウドプラットフォーム）側からリクエストを受けてから、クラウドプラットフォーム１２に対するデータ登録が完了するまでのタイムラグが大きくなる可能性がある。したがって、本実施形態では、上述した第１実施例及び第２実施例をサービス形態やシステム負荷、時間帯、管理者等の設定に応じて適宜組み合わせて実施することができる。

＜画面例＞
次に、ユーザ端末１１のＷｅｂブラウザ等で表示される画面例について図を用いて説明する。図１１は、ユーザ端末で表示される画面例を示す図である。図１１（Ａ）、（Ｂ）に示す画面例は、例えばユーザ端末１１からクラウドプラットフォーム１２にアクセスすることで表示されるＷｅｂ画面例である。

ユーザ端末１１からクラウドプラットフォーム１２にアクセスすると、通常は、ユーザ端末１１のＷｅｂブラウザ上にメール一覧の画面が表示される。ユーザは、ユーザ端末１１に表示されているＷｅｂ画面等を用いて、例えば上述したメール取得リクエストを行った場合に図１１（Ａ）に示すように画面５０に処理中を意味するＧＩＦ（Ｇｒａｐｈｉｃｓ Ｉｎｔｅｒｃｈａｎｇｅ Ｆｏｒｍａｔ）アニメ等のアイコン５１が表示される。また、リクエストが完了すると、例えば図１１（Ｂ）に示すような画面が表示される。

図１１（Ｂ）に示す画面５０には、メール一覧表示領域５２と、チャット領域５３と、ステータス表示領域５４とを有しているが、画面レイアウトや表示される内容については、これに限定されるものではない。メール一覧表示領域５２には、ユーザに対応してメールサーバ１４から取得した受信メールの一覧が表示される。メール一覧には、受信メール毎に送信者や件名、受信時刻等が表示される。また、メール一覧は、各メールが未読メールであるか既読メールであるかが区別できるように所定のマークやハイライト等を用いた表示が行われる。ここで、ユーザがメール一覧の中から何れかのメールを選択すると、メール本文が画面に表示され、ユーザはメールの内容を閲覧することができ、必要に応じて返信等を行うことができる。

また、図１１（Ｂ）に示すチャット領域５３は、例えばユーザが文字を入力してチャット等を行うための領域である。チャット領域５３により予め設定されたＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）で他人と会話したり情報を共有することができる。また、チャット領域５３は、メール一覧から閲覧した受信メールに対する返信メールを作成することもでき、送信メールの一覧をメール一覧表示領域５２に表示させることもできる。

また、図１１（Ｂ）に示すステータス表示領域５４は、例えば、メール取得リクエスト中に異常が発生した場合には、ステータス表示領域５４にエラーメッセージが表示される。なお、リクエストが正常に完了した場合には、ステータス表示領域５４に正常に完了したことを示すメッセージを表示してもよく、メッセージを何も表示しなくてもよい。

上述したように、本実施形態の技術を用いることにより、クラウドプラットフォームの制限を回避するための適切な非同期通信を実現することができる。なお、上述した実施形態では、クラウドプラットフォームへの通信と非同期に通信される外部システムの一例としてメールサーバを用いて説明したが、これに限定されるものではない。

例えば、本実施形態における中継手法は、オンラインストレージやオンプレミスのファイルサーバと連携し、外部のストレージからファイルサイズをフィルタリングして、指定したクラウドプラットフォームの領域へ格納する「外部ストレージ連携」にも適用することができる。また、本実施形態における中継手法は、例えばグループウェアでテキスト更新やファイルデータを保存した場合に、クラウドプラットフォームの特定の領域へ格納する「グループウェア連携」にも適用することができる。また、本実施形態における中継手法は、例えば他の業務システムにおいて保存されている画像データをクラウドプラットフォームへ取り込み、顧客データと対応付けて管理する「Ｗｅｂサービス連携」等にも適用することができる。

以上、実施例について詳述したが、特定の実施例に限定されるものではなく、特許請求の範囲に記載された範囲内において、種々の変形及び変更が可能である。また、上述した実施例の一部又は全部を組み合わせることも可能である。

１０ 非同期通信システム
１１ ユーザ端末
１２ クラウドプラットフォーム
１３ 中継システム（中継装置）
１４ メールサーバ（外部システム）
２１ ルータ
２２ ファイアウォール
２３ ロードバランサ
２４ Ｗｅｂサーバ
２５ ＤＢサーバ
３１ 入力手段
３２ 出力手段
３３ 記憶手段
３４ 要求受付手段
３５ プロトコル変換手段
３６ 非同期処理実行手段
３７ 負荷分散手段
３８ 通信手段
３９ 制御手段
４１ 入力装置
４２ 出力装置
４３ ドライブ装置
４４ 補助記憶装置
４５ 主記憶装置
４６ ＣＰＵ
４７ ネットワーク接続装置
４８ 記録媒体
５０ 画面
５１ アイコン
５２ メール一覧表示領域
５３ チャット領域
５４ ステータス表示領域

Claims (9)

1. 通信ネットワークを介して接続されたクラウドプラットフォームからのリクエストに対応させて前記クラウドプラットフォームと外部システムとのデータ通信を中継する中継装置において、
   前記クラウドプラットフォームからのリクエストを受け付け、受け付けた前記リクエストを登録し、該登録した結果を前記クラウドプラットフォームに送信する要求受付手段と、
   前記クラウドプラットフォームとの通信とは非同期に前記外部システムと通信を行い、前記要求受付手段により登録された前記リクエストに対するレスポンスを前記外部システムから取得し、取得した前記レスポンスを前記クラウドプラットフォームに送信する処理を実行する非同期処理実行手段とを有することを特徴とする中継装置。
2. 前記クラウドプラットフォーム又は前記外部システムと通信する場合に、プロトコル変換を行うプロトコル変換手段を有することを特徴とする請求項１に記載の中継装置。
3. 前記非同期処理実行手段は、
   前記外部システムから得られたレスポンスに対し、所定のレスポンス数に応じたデータセットを作成し、作成した前記データセット毎に前記クラウドプラットフォームにデータを送信することを特徴とする請求項１又は２に記載の中継装置。
4. 前記非同期処理実行手段は、
   前記要求受付手段により前記リクエストを受け付けた後、又は、予め設定された時間間隔で、前記要求受付手段により登録された未処理のリクエストに対するレスポンスを前記外部システムから取得することを特徴とする請求項１乃至３の何れか１項に記載の中継装置。
5. 通信ネットワークを介して接続されたクラウドプラットフォームからのリクエストに対応させて前記クラウドプラットフォームと外部システムとのデータ通信を中継する中継方法において、
   前記クラウドプラットフォームからのリクエストを受け付け、受け付けた前記リクエストを登録し、該登録した結果を前記クラウドプラットフォームに送信する要求受付ステップと、
   前記クラウドプラットフォームとの通信とは非同期に前記外部システムと通信を行い、前記要求受付ステップにより登録された前記リクエストに対するレスポンスを前記外部システムから取得し、取得した前記レスポンスを前記クラウドプラットフォームに送信する処理を実行する非同期処理実行ステップとを有することを特徴とする中継方法。
6. 前記クラウドプラットフォーム又は前記外部システムと通信する場合に、プロトコル変換を行うプロトコル変換ステップを有することを特徴とする請求項５に記載の中継方法。
7. 前記非同期処理実行ステップは、
   前記外部システムから得られたレスポンスに対し、所定のレスポンス数に応じたデータセットを作成し、作成した前記データセット毎に前記クラウドプラットフォームにデータを送信することを特徴とする請求項５又は６に記載の中継方法。
8. 前記非同期処理実行ステップは、
   前記要求受付ステップにより前記リクエストを受け付けた後、又は、予め設定された時間間隔で、前記要求受付ステップにより登録された未処理のリクエストに対するレスポンスを前記外部システムから取得することを特徴とする請求項５乃至７の何れか１項に記載の中継方法。
9. コンピュータを、請求項１乃至４の何れか１項に記載の中継装置における各手段として機能させるための中継プログラム。

Images