特許 6265473 Ｗｅｂサービスシステム、Ｗｅｂサービスメッセージ仲介方法およびプロキシサーバ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6265473

(24)【登録日】2018年1月5日

(45)【発行日】2018年1月24日

(54)【発明の名称】Ｗｅｂサービスシステム、Ｗｅｂサービスメッセージ仲介方法およびプロキシサーバ

(51)【国際特許分類】

   G06F 13/00 20060101AFI20180115BHJP

   G06F 9/54 20060101ALI20180115BHJP

   G06F 9/50 20060101ALI20180115BHJP

【ＦＩ】

   G06F13/00 351A

   G06F13/00 540A

   G06F9/46 480F

   G06F9/46 465A

   G06F9/46 465C

【請求項の数】6

【全頁数】14

(21)【出願番号】特願2013-247874(P2013-247874)

(22)【出願日】2013年11月29日

(65)【公開番号】特開2015-106272(P2015-106272A)

(43)【公開日】2015年6月8日

【審査請求日】2016年7月29日

【国等の委託研究の成果に係る記載事項】（出願人による申告）平成２５年度、独立行政法人情報通信研究機構、「新世代ネットワークを支えるネットワーク仮想化基盤技術の研究開発」副題イ「サービス合成可能なネットワークプラットフォームの研究開発」委託研究、産業技術力強化法第１９条の適用を受ける特許出願

(73)【特許権者】

【識別番号】000208891

【氏名又は名称】ＫＤＤＩ株式会社

(74)【代理人】

【識別番号】100092772

【弁理士】

【氏名又は名称】阪本 清孝

(74)【代理人】

【識別番号】100119688

【弁理士】

【氏名又は名称】田邉 壽二

(72)【発明者】

【氏名】林 通秋

【審査官】 小林 義晴

(56)【参考文献】

【文献】 特開２００４−１８５１３８（ＪＰ，Ａ）

【文献】 丸田康正，他２名，ＩＢＭプロフェッショナル論文３ ＥＳＢ環境での高可用性，ＰＲＯＶＩＳＩＯＮ，日本，日本アイ・ビー・エム株式会社，２００６年１０月３０日，第13巻，第4号，p.81-87

【文献】 福留康之，他２名，Ｗｅｂサービスのリファクタリング検出と自動適応，レクチャーノート／ソフトウェア学３６ ソフトウェア工学の基礎ＸＶＩＩ，日本，株式会社近代科学社，２０１０年１１月３０日，p.119-124

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １３／００

Ｇ０６Ｆ ９／５０

Ｇ０６Ｆ ９／５４

(57)【特許請求の範囲】

【請求項1】

各種機能を実行する複数のアプリケーションサーバと、
前記複数のアプリケーションサーバ間で授受されるＷｅｂサービスメッセージを仲介するプロキシサーバを備え、
前記複数のアプリケーションサーバの各々は、各自の機能を実行するためのプログラムとＡＰＩを備え、
前記プロキシサーバは、アプリケーションサーバからＷｅｂサービスメッセージを受信したとき、それが要求コマンドであれば、その内容を変更することなく要求コマンド受信先アプリケーションサーバに転送し、それに対して正常応答メッセージを受信した場合、その内容を変更することなく要求コマンド送信元アプリケーションサーバに転送し、要求コマンドに対してエラーメッセージを受信した場合には、該要求コマンドに対するＷＳＤＬ定義の変更に応じて予め設定されたポリシーに従って、仕様を一部変更した要求コマンドを要求コマンド受信先アプリケーションサーバに転送するか、受信した要求コマンドを、それに対して応答する可能性のあるアプリケーションサーバに転送するか、を選択的に実行する機能を有することを特徴とするＷｅｂサービスシステム。

【請求項2】

複数のアプリケーションサーバで構成されるＷｅｂサービスシステムにおけるＷｅｂサービスメッセージ仲介方法であって、
Ｗｅｂサービスメッセージを受信する第１のステップと、
前記第１のステップにより受信されたＷｅｂサービスメッセージにおけるＷＳＤＬ定義を生成する第２のステップと、
処理判定を行う第３のステップと、
前記第３のステップでの判定結果に従ってＷｅｂサービスメッセージを送信する第４のステップを有し、
前記第３のステップは、アプリケーションサーバからＷｅｂサービスメッセージを受信したとき、それが要求コマンドであれば、その内容を変更することなく要求コマンド受信先アプリケーションサーバに転送し、それに対して正常応答メッセージを受信した場合、その内容を変更することなく要求コマンド送信元アプリケーションサーバに転送し、要求コマンドに対してエラーメッセージを受信した場合には、該要求コマンドに対するＷＳＤＬ定義の変更に応じて予め設定されたポリシーに従って、仕様を一部変更した要求コマンドを要求コマンド受信先アプリケーションサーバに転送するか、受信した要求コマンドを、それに対して応答する可能性のあるアプリケーションサーバに転送するかを、選択的に実行することを特徴とするＷｅｂサービスメッセージ仲介方法。

【請求項3】

複数のアプリケーションサーバで構成されるＷｅｂサービスシステム用のプロキシサーバであって、
アプリケーションサーバからＷｅｂサービスメッセージを受信したとき、それが要求コマンドであれば、その内容を変更することなく要求コマンド受信先アプリケーションサーバに転送し、それに対して正常応答メッセージを受信した場合、その内容を変更することなく要求コマンド送信元アプリケーションサーバに転送し、要求コマンドに対してエラーメッセージを受信した場合には、該要求コマンドに対するＷＳＤＬ定義の変更に応じて予め設定されたポリシーに従って、仕様を一部変更した要求コマンドを要求コマンド受信先アプリケーションサーバに転送するか、受信した要求コマンドを、それに対して応答する可能性のあるアプリケーションサーバに転送するか、を選択的に実行する機能を有することを特徴とするプロキシサーバ。

【請求項4】

Ｗｅｂサービスメッセージを受信する受信部と、
前記受信部により受信されたＷｅｂサービスメッセージのうち、要求コマンドに対するＷＳＤＬ定義を生成するＷＳＤＬ生成部と、
処理判定部と、
前記処理判定部による判定結果に従ってＷｅｂサービスメッセージを送信する送信部と、
前記ＷＳＤＬ生成部により生成されたＷＳＤＬ定義により、要求コマンド送信元アプリケーションサーバごとに事前に格納されているＷＳＤＬ定義を更新して格納するＷＳＤＬデータベースと、
前記処理判定部での判定結果をトランザクションの状態遷移と共に蓄積する状態管理データベースと、
前記受信部により受信されたＷｅｂサービスメッセージとその受信に対して行う動作のポリシーを格納するポリシーデータベースを備え、
前記処理判定部は、前記ＷＳＤＬデータベースに要求コマンド送信元アプリケーションサーバごとに事前に格納されている更新前のＷＳＤＬ定義と前記ＷＳＤＬ生成部により生成されたＷＳＤＬ定義との差分を要求コマンド送信元アプリケーションサーバ対応に求め、該差分を追加のＷＳＤＬ定義として要求コマンド送信元アプリケーションサーバごとに前記ＷＳＤＬデータベースに格納させることによりＷＳＤＬ定義を更新させ、また、処理結果をトランザクションの状態遷移と共に前記状態管理データベースに蓄積させ、さらに、Ｗｅｂサービスメッセージを受信したとき、それが要求コマンドであれば、その内容を変更することなく要求コマンド受信先アプリケーションサーバに転送させ、それに対して正常応答メッセージを受信した場合、その内容を変更することなく要求コマンド送信元アプリケーションサーバに転送させ、要求コマンドに対してエラーメッセージを受信した場合には、該要求コマンドに対するＷＳＤＬ定義の変更に応じて予め設定されたポリシーに従って、仕様を一部変更した要求コマンドの要求コマンド受信先アプリケーションサーバに転送させるか、受信した要求コマンドを、それに対して応答する可能性のあるアプリケーションサーバに転送させるかを、選択的に実行することを特徴とする請求項３に記載のプロキシサーバ。

【請求項5】

前記ポリシーは、要求コマンドのパラメータについては、その差分が１つの場合、当該パラメータを削除した要求コマンドを要求コマンド受信先アプリケーションサーバに転送させ、その差分が２つの場合、差分が２つ以下のアプリケーションサーバに要求コマンドを転送させるように設定され、要求コマンド自体については、要求コマンド自体が未サポートの場合、該要求コマンドを、それをサポート可能なアプリケーションサーバに転送させるように設定されていることを特徴とする請求項４に記載のプロキシサーバ。

【請求項6】

前記ポリシーは、さらに、要求コマンドの引数の数の差に応じた、要求コマンドあるいは仕様を一部変更した要求コマンドの転送について設定していることを特徴とする請求項５に記載のプロキシサーバ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、Webサービスシステム、Webサービスメッセージ仲介方法およびプロキシサーバに関し、特に、API仕様の拡張性に優れたWebサービスシステム、Webサービスメッセージ仲介方法およびプロキシサーバおよびに関する。

【背景技術】

【0002】

Webサービスシステムは、各種機能を実行する複数のアプリケーションサーバを備え、それらのアプリケーションサーバ間でRESTやSOAPなどといったプロトコルを用いてメッセージを授受して連携を図る。

【0003】

図６は、Webサービスシステムの基本構成を示す。このWebサービスシステムは、システムA〜Dとして図示されている4つのアプリケーションサーバを備える。システムA〜Dは、互いに異なる機能を実行する。ここで、システムAは、システムB〜Dと各種メッセージを授受し、Webサービスシステム全体の連携を図る基幹システムとして機能する。システムB〜Dは、互いに異なる機能を実行する。また、システムB〜Dは、必要に応じてシステムAと、あるいはシステムAを介して他システムとメッセージを授受することにより他システムが処理した各種情報を取得できる。

【0004】

各システムA〜Dはそれぞれ、プログラムおよびAPI(application programming interface)を備える。各システムA〜DのAPI仕様は標準化され、それによりシステムA〜Dは、メッセージを相互に理解できるようになっている。Webサービスシステムの機能拡張のために各システムA〜DのAPI仕様が拡張される場合があるが、その拡張は、Webサービスシステムを構成する全てのシステムA〜DのAPI仕様が拡張され、システムA〜Dがメッセージを相互に理解できるようになった場合に効果的なものとなる。

【0005】

特許文献１には、ネットワーク管理装置に関し、SNMP管理情報とCMIP管理情報との情報体系の違いを整合し、移植性と拡張性の高い管理アプリケーションを作成可能とするため、SNMP管理情報とCMIP管理情報との情報体系の違いを整合するための情報を格納した整合情報データベースを備え、この整合情報データベースに格納された情報を参照してNMP管理情報とCMIP管理情報との情報体系を変換することが記載されている。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】特開平７−２５００６５号公報

【発明の概要】

【発明が解決しようとする課題】

【0007】

上述したように、従来では、Webサービスシステムの機能拡張のためのAPI仕様の拡張は、特定のシステムのAPI仕様だけでなく、Webサービスシステムを構成する全てのシステムのAPI仕様が拡張された場合に効果的なものとなる。

【0008】

例えば、図６に示すように、Webサービスメッセージのコマンド、パラメータ、引数の数が増やされるなどして、システムDの API仕様だけが拡張された場合、システムDがそのAPI仕様によるメッセージを送出してもシステムAがそれを理解できず、システムAがそのメッセージを理解できたとしてもシステムB〜Cがそれを理解できないという不整合が生じる。この不整合をなくすためには、システムA〜Dの全てのAPI仕様が拡張される必要がある。

【0009】

このようなケースでのAPI仕様の拡張の工数の増大は、Webサービスシステムの機能拡張の阻害要因となる。このため、Webサービスシステムを構成する特定のシステムのAPI仕様が拡張されても、Webサービスシステム全体に及ぶ影響が少なく、しかも、API仕様の拡張が極力有効になることが望まれる。

【0010】

引用文献１には、整合情報データベースを用いてインタフェースの相違を整合させる手法が開示されている。しかし、このような手法では、1対1のシステム間でのインタフェースの相違を整合させることは容易であるが、多対多のシステム間でのインタフェースの相違を整合させることは困難である。Webサービスシステムでは、多対多のシステム間でAPI仕様が多様に拡張されることが多々あるので、引用文献１での手法は、Webサービスシステムにおける多様なインタフェースへの対応という観点では拡張性に優れているとは言えない。

【0011】

なお、Webサービスシステムを構成するシステムのうち、API仕様が拡張されたシステムだけでの連携に留め、未拡張のシステムでは拡張を無視するという手法も考えられる。この手法によれば、特定のシステムのAPI仕様が拡張された場合の影響を少なくできるが、API仕様の拡張によるサービスは、API仕様が拡張済みのシステム間に限られ、他のシステムはそのサービスを全く受けることができない。結局、システムのAPI仕様の拡張がそのままWebサービスシステムに影響することになる。

【0012】

また、Webサービスシステムを構成するシステムを、中間言語となるAPIを介して連携させる手法も考えられる。この手法によれば、特定のシステムのAPI仕様が拡張された場合、API仕様が拡張されたシステムのメッセージと中間言語との変換を変更するだけで対処できる。しかし、API仕様の拡張を予め想定して中間言語を作っておく必要があり、実現が困難である。

【0013】

本発明の目的は、上記課題を解決し、API仕様の拡張性に優れたWebサービスシステム、Webサービスメッセージ仲介方法およびプロキシサーバを提供することにある。

【課題を解決するための手段】

【0014】

上記課題を解決するため、本発明のWebサービスシステムは、各種機能を実行する複数のアプリケーションサーバと、前記複数のアプリケーションサーバ間で授受されるWebサービスメッセージを仲介するプロキシサーバを備え、前記複数のアプリケーションサーバの各々は、各自の機能を実行するためのプログラムとAPIを備え、前記プロキシサーバは、アプリケーションサーバからWebサービスメッセージを受信したとき、それが要求コマンドであれば、その内容を変更することなく要求コマンド受信先アプリケーションサーバに転送し、それに対して正常応答メッセージを受信した場合、その内容を変更することなく要求コマンド送信元アプリケーションサーバに転送し、要求コマンドに対してエラーメッセージを受信した場合には、該要求コマンドに対するＷＳＤＬ定義の変更に応じて予め設定されたポリシーに従って、仕様を一部変更した要求コマンドを要求コマンド受信先アプリケーションサーバに転送するか、受信した要求コマンドを、それに対して応答する可能性のあるアプリケーションサーバに転送するか、を選択的に実行する機能を有することを特徴としている。

【0015】

また、本発明のWebサービスメッセージ仲介方法は、複数のアプリケーションサーバで構成されるWebサービスシステムにおけるＷｅｂサービスメッセージ仲介方法であって、Webサービスメッセージを受信する第1のステップと、前記第1のステップにより受信されたWebサービスメッセージにおけるWSDL定義を生成する第2のステップと、処理判定を行う第3のステップと、前記第3のステップでの判定結果に従ってWebサービスメッセージを送信する第4のステップを有し、前記第3のステップは、アプリケーションサーバからWebサービスメッセージを受信したとき、それが要求コマンドであれば、その内容を変更することなく要求コマンド受信先アプリケーションサーバに転送し、それに対して正常応答メッセージを受信した場合、その内容を変更することなく要求コマンド送信元アプリケーションサーバに転送し、要求コマンドに対してエラーメッセージを受信した場合には、該要求コマンドに対するＷＳＤＬ定義の変更に応じて予め設定されたポリシーに従って、仕様を一部変更した要求コマンドを要求コマンド受信先アプリケーションサーバに転送するか、受信した要求コマンドを、それに対して応答する可能性のあるアプリケーションサーバに転送するかを、選択的に実行することを特徴としている。

【0016】

また、本発明のプロキシサーバは、複数のアプリケーションサーバで構成されるWebサービスシステム用のプロキシサーバであって、アプリケーションサーバからWebサービスメッセージを受信したとき、それが要求コマンドであれば、その内容を変更することなく要求コマンド受信先アプリケーションサーバに転送し、それに対して正常応答メッセージを受信した場合、その内容を変更することなく要求コマンド送信元アプリケーションサーバに転送し、要求コマンドに対してエラーメッセージを受信した場合には、該要求コマンドに対するＷＳＤＬ定義の変更に応じて予め設定されたポリシーに従って、仕様を一部変更した要求コマンドを要求コマンド受信先アプリケーションサーバに転送するか、受信した要求コマンドを、それに対して応答する可能性のあるアプリケーションサーバに転送するか、を選択的に実行する機能を有することを第１の特徴としている。

【0017】

また、本発明のプロキシサーバは、Webサービスメッセージを受信する受信部と、前記受信部により受信されたWebサービスメッセージのうち、要求コマンドに対するWSDL定義を生成するWSDL生成部と、処理判定部と、前記処理判定部による判定結果に従ってWebサービスメッセージを送信する送信部と、前記WSDL生成部により生成されたWSDL定義により、要求コマンド送信元アプリケーションサーバごとに事前に格納されているWSDL定義を更新して格納するWSDLデータベースと、前記処理判定部での判定結果をトランザクションの状態遷移と共に蓄積する状態管理データベースと、前記受信部により受信されたWebサービスメッセージとその受信に対して行う動作のポリシーを格納するポリシーデータベースを備え、前記処理判定部は、前記WSDLデータベースに要求コマンド送信元アプリケーションサーバごとに事前に格納されている更新前のWSDL定義と前記WSDL生成部により生成されたWSDL定義との差分を要求コマンド送信元アプリケーションサーバ対応に求め、該差分を追加のWSDL定義として要求コマンド送信元アプリケーションサーバごとに前記WSDLデータベースに格納させることによりWSDL定義を更新させ、また、処理結果をトランザクションの状態遷移と共に前記状態管理データベースに蓄積させ、さらに、Webサービスメッセージを受信したとき、それが要求コマンドであれば、その内容を変更することなく要求コマンド受信先アプリケーションサーバに転送させ、それに対して正常応答メッセージを受信した場合、その内容を変更することなく要求コマンド送信元アプリケーションサーバに転送させ、要求コマンドに対してエラーメッセージを受信した場合には、該要求コマンドに対するＷＳＤＬ定義の変更に応じて予め設定されたポリシーに従って、仕様を一部変更した要求コマンドの要求コマンド受信先アプリケーションサーバに転送させるか、受信した要求コマンドを、それに対して応答する可能性のあるアプリケーションサーバに転送させるかを、選択的に実行することを第２の特徴としている。

【0018】

また、本発明のプロキシサーバは、前記ポリシーが、要求コマンドのパラメータについては、その差分が1つの場合、当該パラメータを削除した要求コマンドを要求コマンド受信先アプリケーションサーバに転送させ、その差分が2つの場合、差分が2つ以下のアプリケーションサーバに要求コマンドを転送させるように設定され、要求コマンド自体については、要求コマンド自体が未サポートの場合、該要求コマンドを、それをサポート可能なアプリケーションサーバに転送させるように設定されていることを第３の特徴としている。

【0019】

さらに、本発明のプロキシサーバは、前記ポリシーが、さらに、要求コマンドの引数の数の差に応じた、要求コマンドあるいは仕様を一部変更した要求コマンドの転送について設定していることを第４の特徴としている。

【発明の効果】

【0020】

本発明によれば、要求コマンド送信先アプリケーションサーバからエラーメッセージが返される場合でも、要求コマンドに対するＷＳＤＬ定義の変更に応じて予め設定されたポリシーに従って、仕様を一部変更した要求コマンドを要求コマンド受信先アプリケーションサーバに転送するか、受信した要求コマンドを、それに対して応答する可能性のあるアプリケーションサーバに転送するか、を選択的に実行するので、API仕様の拡張性に優れたWebサービスシステムを実現できる。

【0021】

また、特定のアプリケーションサーバにおけるAPI仕様の拡張に対して、ポリシーデータベースに格納するポリシーで対処できるので、API仕様の拡張に対処するための工数の増大を抑制できる。また、API仕様の拡張がWebサービスシステム全体に極力影響しないようにでき、さらに、API仕様の拡張を極力有効利用できる。

【図面の簡単な説明】

【0022】

【図1】本発明に係るWebサービスシステムの一実施形態を示すブロック図である。

【図2】RESTメッセージの具体例を示す図である。

【図3】WSDL定義の具体例を示す図である。

【図4】名前空間定義の具体例を示す図である。

【図5】図１のWSPにおける処理の一例を示すフローチャートである。

【図6】Webサービスシステムの基本構成を示すブロック図である。

【発明を実施するための形態】

【0023】

以下、図を参照して本発明を説明する。以下では、Webサービスシステムを構成するシステム間で授受されるメッセージ(Webサービスメッセージ)がREST(Representational State Transfer)メッセージであるとして説明する。

【0024】

図１は、本発明に係るWebサービスシステムの一実施形態を示すブロック図である。本実施形態のWebサービスシステムが図６と異なるのは、プロキシサーバ(WSP：Web Services Proxy)10を備える点である。

【0025】

ここで、システムAは、WSP10を介してシステムB〜Dと各種RESTメッセージを授受し、Webサービスシステム全体の連携を図る基幹システムとして機能する。システムB〜Dは、互いに異なる機能を実行する。また、システムB〜Dは、必要に応じてWSP10を介してシステムAと、あるいはWSP10およびシステムAを介して他システムと各種RESTメッセージを授受することにより他システムの機能により処理された各種情報を取得できる。

【0026】

WSP10は、各システムA〜D間で授受されるRESTメッセージを仲介し、特定のシステムのAPI仕様が拡張された場合でも、システムA〜Dを極力連携可能にするために備えられたものであり、REST API受信部11、WSDL(Web Services Description Language)生成部12、処理判定部13、REST API送信部14、WSDLデータベース(DB)15、状態管理データベース16およびポリシーデータベース17を備える。なお、WSDL生成部12や処理判定部13は、CPUとソフトウエアで構成できる。また、WSDLデータベース15や状態管理データベース16やポリシーデータベース17は、外部に設けてもよい。

【0027】

REST API受信部11は、各システムA〜Dから送出される各種RESTメッセージを受信する。

【0028】

WSDL生成部12は、REST API受信部11により受信されたRESTメッセージ、特に要求コマンドのRESTメッセージからWSDL定義を生成する。また、名前空間定義が必要な場合には、それも生成する。WSDL定義は、Webメッセージ仕様のWSDL、ここではRESTメッセージ仕様のWSDLであり、名前空間定義は、RESTメッセージ仕様をさらに詳細化したWSDLである。RESTメッセージにおけるWSDL定義は、WSDL2.0(以降)の枠組みを使えば生成可能である。WSDL定義および名前空間定義の生成については、例えば、(http://www.ibm.com/developerworks/webservices/library/ws-restwsdl/#describerestservice)が参照される。

【0029】

図２は、RESTメッセージの具体例を示している。この例は、'gone with the wind' というタイトルのコンテンツのリストを検索する要求コマンドと、それに対して返された応答メッセージの例を示している。また、図３は、WSDL定義の具体例を示し、図４は、名前空間定義の具体例を示している。

【0030】

処理判定部13は、WSDL2.0(以降)の枠組みを使って事前に構成され、WSDLデータベース15に予め格納されているWSDL定義(名前空間定義を含む)とWSDL生成部12により生成されたWSDL定義(RESTメッセージ仕様のWSDL)との差分をRESTメッセージ送信元システム対応に求め、該差分を、追加WSDL定義として、WSDLデータベース15にRESTメッセージ送信元システム対応に格納する。

【0031】

また、処理判定部13は、REST API受信部11により受信されたRESTメッセージの処理状態(ステート)を状態管理データベース16に格納し、さらに、RESTメッセージ受信先システムからの応答に応じて、状態管理データベース16やポリシーデータベース17を参照し、その後の処理を実行する。処理判定部13における処理については、後で詳細に説明する。

【0032】

REST API送信部14は、RESTメッセージやWSP10の内部での処理結果を送信する。

【0033】

WSDLデータベース15は、トランザクションで用いられるRESTメッセージをWSDL2.0(以降)の枠組みを使って事前に仕様化し、WSDL定義としてRESTメッセージ送信元システムごとに予め格納しており、また、処理判定部13により求められた差分を追加WSDL定義としてRESTメッセージ送信元システム対応に格納する。各RESTメッセージ送信元システムについてのWSDL定義の共通部分は、共通に格納しておいてもよい。RESTメッセージは、WebサービスのURL、オペレーションコマンド、RESTメッセージの構造を含む。

【0034】

状態管理データベース16は、トランザクションの状態遷移およびRESTメッセージやそのWSDL定義の情報を格納する。この情報は、WSP10が送信したオペレーションコマンドやそのWSDL定義(メッセージ内容)、WSP10が送信したオペレーションコマンドに対する受信先システムからの応答(正常応答，例外(エラー)の返信，無応答)、送信元と受信先の組と状態遷移履歴(正常終了，異常終了シーケンス)を含む。

【0035】

ポリシーデータベース17は、受信されたRESTメッセージに対して、WSP10がその後に行う処理についてのポリシーを格納している。

【0036】

図５は、WSP10における処理の一例を示すフローチャートである。以下、その処理を図１および図２を参照して説明する。

【0037】

まず、システムA〜Dの何れか１つを要求コマンド送信元システムとし、他の1つを要求コマンド受信先システムとして、要求コマンド送信元システムから要求コマンドのRESTメッセージ(以下では単に「要求コマンド」と称することがある)が送出される。

【0038】

WSP10は、S11で、要求コマンドを受信し、S12では、それをRESTメッセージ仕様のWSDL(WSDL定義)に変換し、要求コマンドと共に次の処理(S13:処理判定部13)に与える。なお、WSDLは、RESTメッセージの変換が可能なWSDL2.0(以降)とする。以上は、REST API受信部11およびWSDL生成部12が行う処理である。

【0039】

以下は、処理判定部13が行う処理である。処理判定部13では、まず、S13で、RESTメッセージが例外メッセージ、すなわちエラーメッセージであるか否かを判定する。この場合、RESTメッセージは要求コマンドであり、エラーメッセージでないので、S13では、例外メッセージでないと判定される。したがって、この場合、要求コマンドおよびそのWSDL定義が、S14に与えられる。

【0040】

S14では、WSDLデータベース15に事前に格納されているWSDL定義とWSDL生成部12により生成されたWSDL定義を比較する。この比較処理は、エラーメッセージが受信された場合の処理でないので、ここでは比較処理(正常系)と記している。

【0041】

WSDLデータベース15には、トランザクションで用いられるRESTメッセージのWSDL定義が事前に構成されて、RESTメッセージ送信元システムごとに格納されている。WSDL定義の比較や後述するWSDL定義の追加は、RESTメッセージ送信元システム対応に行う。

【0042】

S14での比較処理(正常系)の後、S15では、比較処理の結果の差分の有無を判定する。ここで差分がないと判定された場合には、S18に進む。S18では、ポリシーデータベース17に予め格納されているポリシーに従って最終処理判定を行う。

【0043】

ポリシーデータベース17には、受信されたRESTメッセージが要求コマンドである場合、内容を変更せずに要求コマンド受信先システムに転送するというポリシーが格納されている。したがって、この場合、要求コマンドを、S14,S15,S18,S19を通して、内容変更することなく要求コマンド受信先システムに転送する。この際、要求コマンドの送信元と受信先システムの対、要求コマンドおよびそのWSDL定義と共に、S18での最終処理判定の結果を遷移履歴として状態管理データベース16に蓄積する。

【0044】

要求コマンド送信元システムのAPI仕様が拡張された場合、S15で、差分があると判定される。この場合には、その差分を、WSDLデータベース15に格納されているWSDL定義に対する追加WSDL定義して格納する。WSDLデータベース15に格納されたWSDL定義により、RESTメッセージ送信元システムを受信側とした場合に対応できる仕様が分かる。

【0045】

次に、再度、S14で比較処理(正常系)する。この比較処理(正常系)の結果、S15では差分がないと判定されるので、要求コマンドを、S14,S15,S18,S19を通して、内容変更することなく要求コマンド受信先システムに転送する。この際、要求コマンドおよびそのWSDL定義と共に、S18での最終処理判定の結果を遷移履歴として状態管理データベース16に蓄積する。なお、以上のS18までは、処理判定部13が行う処理であるが、S19は、REST API送信部14が行う処理である。

【0046】

以上のように、WSP10は、要求コマンドにおけるWSDL定義がWSDLデータベース15に事前に格納されているWSDL定義と同じであれば、要求コマンドを、内容変更することなく要求コマンド受信先システムに転送する。また、要求コマンド送信元システムのAPI仕様が拡張されて、要求コマンドにおけるWSDL定義がWSDLデータベース15に事前に格納されているWSDL定義と異なっていれば、その差分をWSDLデータベース15のWSDL定義ファイルに追加してから、要求コマンドを、内容変更することなく要求コマンド受信先システムに転送する。この際、WSDLデータベース15は、要求コマンド送信元システムのAPI仕様のWSDL定義を更新しつつ格納する。また、状態管理データベース16は、要求コマンドの送信元と受信先システムの対、要求コマンドおよびそのWSDL定義と共に、最終処理判定の結果を遷移履歴として蓄積する。

【0047】

要求コマンド受信先システムは、要求コマンドを受信し、それを理解できれば正常応答のRESTメッセージを返し、それを理解できなければ例外(エラー)のRESTメッセージを返す。また、何らの応答も返さない場合もある。

【0048】

RESTメッセージ受信先システムは、受信したRESTメッセージを理解できれば、正常応答のRESTメッセージを返す。したがって、要求コマンド受信先システムが要求コマンドを理解できた場合、正常応答のRESTメッセージ(以下では単に「正常応答」と称することがある)が返される。

【0049】

この場合、WSP10は、正常応答を受信し、正常応答に対してはS12,S14,S15の処理を行わず、正常応答をそのまま最終処理判定(S18)に与える。すなわち、正常応答を、S14,S15,S18,S19を通して、内容変更することなく要求コマンド送信元システムに転送する。この処理を行うために、ポリシーデータベース17には、正常応答が受信された場合、その内容を変更せずに要求コマンド送信元システムに転送するというポリシーが格納されている。この際、状態管理データベース16には、要求コマンドとの対応が分かるようにして、要求コマンドの送信元と受信先システムの対、正常応答と共に、最終処理判定の結果を遷移履歴として蓄積する。

【0050】

以上のように、WSP10は、正常応答を、内容変更することなく要求コマンド送信元システムに転送する。この際、状態管理データベース16には、要求コマンドの送信元と受信先(応答送信元)システムの対、RESTメッセージの内容と共に、最終処理判定の結果を遷移履歴として蓄積する。

【0051】

RESTメッセージ受信先システムは、受信したRESTメッセージを理解できなければ、例外(エラー)のRESTメッセージを返す。したがって、要求コマンド受信先システムが要求コマンドを理解できなかった場合、要求コマンド受信先システムから例外(エラー)のRESTメッセージ(以下では単に「エラーメッセージ」と称することがある)が返される。

【0052】

この場合、S13では、受信されたRESTメッセージは例外と判定されるので、S16に進む。S16では、WSDLロールバック処理を行う。WSDLロールバック処理は、例外(エラー)の原因となった前手順のRESTメッセージに基づく追加WDSL定義を削除する処理を意味する。このWSDLロールバック処理により、例外(エラー)の原因となった前手順のRESTメッセージに基づく追加が行われる前のWSDL定義が生成される。なお、WSDLデータベース15に要求コマンド送信元システムに対して格納されているWSDL定義は、該要求コマンド送信元システムを受信側とした場合に対応できる仕様を管理するためのものであるので、更新する必要はない。

【0053】

その上で、S17で、前手順のRESTメッセージのWSDL定義をWSDLロールバック処理後のWSDL定義と比較する。すなわち、要求コマンドのWSDL定義とそれに対する事前のWSDL定義を比較する。この比較処理は、エラーメッセージが受信された場合の処理であるので、ここでは比較処理(異常系)と記している。

【0054】

次に、S18に進んで、最終処理判定を行う。ポリシーデータベース17には、受信メッセージが例外である場合のポリシーも格納されており、S18では、ポリシーデータベース17に格納されているポリシーに従って最終処理判定を行う。

【0055】

図５には、API仕様の拡張によりパラメータが追加・変更される場合やAPI仕様の拡張による要求コマンド自体が未サポートである場合を想定してのポリシーも図示している。

【0056】

具体的には、エラーメッセージが受信された場合にWSP10で実行する動作として、(1)差分がパラメータ1つの場合、当該パラメータを削除した要求コマンドを要求コマンド受信先システムに転送、(2)差分がパラメータ2つの場合、WSDLデータベース15と状態管理データベース16 を参照し、差分が2つ以下のシステムに要求コマンドを転送、(3)差分がパラメータ3つ以上の場合、要求コマンド送信元システムに例外(unsupported parameter)のRESTメッセージを返送、(4)要求コマンド自体が未サポートの場合、サポート可能なシステムに該要求コマンドを転送し、そのようなシステムがなければ例外(unsupported parameter)を要求コマンド送信元システムに返送、と定めている。なお、要求コマンドをサポート可能なシステムかどうかは、WSDLデータベース15を参照することにより分かる。

【0057】

(1)の場合には、S18では、前手順の要求コマンドのRESTメッセージから差分のパラメータ1つを削除し、S19を通して、要求コマンドを要求コマンド受信先システムに転送する。これにより、要求コマンド受信先システムから正常応答が返されることが期待できる。しかし、それでもなおエラーメッセージが返された場合には、要求コマンド送信元システムにエラーを返せばよい。

【0058】

(2)の場合には、S18およびS19を通して、差分が2つ以下のシステムに対して要求コマンドを転送する。これは、差分が2つ以下のシステムが正常応答する可能性が比較的大きいからである。それでもなおエラーメッセージが返された場合には、要求コマンド送信元システムにエラーを返せばよい。

【0059】

(3)の場合には、何れのシステムも正常応答の可能性が小さいとしてエラーメッセージを要求コマンド送信元システムに返す。

【0060】

(4)の場合には、要求コマンドをサポート可能なシステムから正常応答が返される可能性が大である。そこで、S18,S19を通して、そのシステムに対して要求コマンドを転送し、何れのシステムからも正常応答が返されなければ、エラーメッセージを要求コマンド送信元システムに返す。

【0061】

要求コマンドを送信しても、要求コマンド受信先システムが何らの応答も返さない場合には、ポリシーデータベース17に「応答無し」に対して格納されているポリシーに従って要求コマンド送信元システムに未サポート・エラーメッセージを返す。これは、割り込み処理で実現できる。例えば、状態管理データベース16において要求コマンド送信後の経過時間をタイマで計時し、100mse経過しても応答がなければ、S16に無応答通知を送出し、要求コマンド送信元システムに未サポート・エラーメッセージを返す。なお、以上の場合も、状態管理データベース16には、要求コマンドの送信元と受信先システムの対や応答、最終処理判定の結果を遷移履歴として蓄積する。

【0062】

以上実施形態について説明したが、本発明は、上記実施形態に限定されない。例えば、図５にはポリシーを具体的に図示したが、そのポリシーは、一例に過ぎず、(1),(2),(4)の少なくとも1つを含むようにポリシーを定めればよい。すなわち、要求コマンドに対してエラーメッセージを受信した場合、予め設定されたポリシーに従って、仕様を一部変更した要求コマンドを要求コマンド受信先アプリメーションサーバに転送する((1)の場合)、あるいは受信した要求コマンドを、それに対して応答する可能性のあるアプリメーションサーバに転送する((2)または(4)の場合)、という処理を含むポリシーであれば、API仕様の拡張性に対処できる。

【0063】

また、パラメータやコマンドだけでなく、引数の数の差などに応じてポリシーを定めてもよく、さらに、ポリシーを適宜可変設定できるようにしてもよい。

【0064】

また、上記実施形態は、本発明を、WSP10を備えたWebサービスシステムとして実現したものであるが、本発明は、WSP10での処理方法、すなわち、WebサービスシステムにおけるWebサービスメッセージ仲介方法やWSP10の構成としても実現できる。また、上記実施形態では、各システム間で授受されるWebサービスメッセージがRESTメッセージであるとしたが、本発明は、他のWebサービスメッセージ、例えばSOAPメッセージなどの場合にも適用できる。

【符号の説明】

【0065】

10・・・WSP、11・・・REST API受信部、12・・・WSDL生成部、13・・・処理判定部、14・・・REST API送信部、15・・・WSDLデータベース、16・・・状態管理データベース、17・・・ポリシーデータベース

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】