(57)【要約】【課題】  システム間の通信処理に、ストレージネットワークを利用することで、データ伝送の効率化と通信の信頼性とを確保する。【解決手段】  サービスを提供するサーバアプリケーションを有するサービスプロバイダシステムと、サービスを利用するコンシューマアプリケーションを有するコンシューマシステムとが、ストレージネットワークに接続され、前記コンシューマシステムに設けられたプロトコル変換部が、アプリケーション通信をストレージネットワークで用いるストレージ通信にプロトコル変換を行ない、前記ストレージネットワークが前記変換されたストレージ通信を前記サービスプロバイダシステムに伝送し、前記サービスプロバイダシステムに設けられたプロトコル変換部が、伝送されたストレージ通信をアプリケーション通信にプロトコル変換する。【選択図】        図１
2005196531.tif 000002
【特許請求の範囲】
【請求項１】
サービスを提供するサーバアプリケーションを有するサービスプロバイダシステムと、サービスを利用するコンシューマアプリケーションを有するコンシューマシステムとが、ストレージネットワークに接続され、前記サービスプロバイダシステムと前記コンシューマシステムとの間のサービスを行なうための通信処理方法であって、
前記コンシューマシステムに設けられたプロトコル変換部が、前記コンシューマアプリケーションで用いるアプリケーション通信をストレージネットワークで用いるストレージ通信にプロトコル変換を行ない、
前記ストレージネットワークが前記変換されたストレージ通信を前記サービスプロバイダシステムに伝送し、
前記サービスプロバイダシステムに設けられたプロトコル変換部が、伝送されたストレージ通信を前記サーバアプリケーションへのアプリケーション通信にプロトコル変換し、前記サーバアプリケーションが当該アプリケーション通信に対応してサービス処理をすることを特徴とするシステム間通信処理方法。
【請求項２】
前記サービスプロバイダシステムと前記コンシューマシステムとがアプリケーションネットワークに接続されており、アプリケーション通信メッセージが、複数のデータ種別の、複数の部分のデータから構成されており、前記コンシューマシステムに設けられた伝送データ分割・合成部が、伝送データ種別によってアプリケーション通信メッセージを構成する部分データに分割し、アプリケーション通信メッセージの各部分データに対応する伝送データについて、当該伝送データの種別に応じ、当該伝送データを伝送するネットワークに前記ストレージネットワークを選定して伝送を行ない、前記サービスプロバイダシステムに設けられた伝送データ分割・合成部が、当該伝送された伝送データを合成して、前記サーバアプリケーションへのアプリケーション通信メッセージを作成することを特徴とする請求項１に記載のシステム間通信処理方法。
【請求項３】
コンシューマシステム又はサービスプロバイダシステムに設けられた通信制御状態制御部が、前記アプリケーションネットワークの利用の停止を決定した際に、当該利用を停止したアプリケーションネットワーク上でアプリケーション通信のために伝送する内容を、前記ストレージネットワークにより伝送することを特徴とする請求項１または請求項２に記載のシステム間通信処理方法。
【請求項４】
コンシューマシステムに設けられたコンシューマ通信プロキシ部が、アプリケーション通信のリクエストメッセージのデータを編集し、アプリケーションネットワークで伝送するデータと、ストレージネットワークで伝送するデータを作成し、どちらかにデータの改ざん等の変更があった場合に、検知できるデータを保持し、一方の伝送データはアプリケーションネットワークを経由して伝送し、他方の伝送データはストレージネットワークを経由して伝送し、サービスプロバイダシステムに設けられたサーバ通信プロキシ部が、それぞれの伝送データを受信して編集し、前記変更があった場合に、検知できるデータのチェックをすることを特徴とする請求項１又は請求項２に記載のシステム間通信処理方法。
【請求項５】
サービスを提供するサーバアプリケーションを有するサービスプロバイダシステムと、サービスを利用するコンシューマアプリケーションを有するコンシューマシステムとが、ストレージネットワークに接続され、前記サービスプロバイダシステムと前記コンシューマシステムとの間のサービスを行なうための通信処理方法であって、
前記コンシューマシステムに設けられたプロトコル変換部が、前記コンシューマアプリケーションで用いるアプリケーション通信をストレージネットワークで用いるストレージ通信にプロトコル変換を行ない、前記ストレージネットワークに接続され、データを格納するために前記コンシューマシステムに設けられたコンシューマシステムストレージが当該変換されたストレージ通信メッセージのデータを格納し、
前記ストレージネットワークが、前記格納されたストレージ通信メッセージのデータを、前記ストレージネットワークに接続され、データを格納するために前記サービスプロバイダシステムに設けられたサービスプロバイダシステムストレージに伝送して格納し、
前記サービスプロバイダシステムに設けられたプロトコル変換部が、格納されたストレージ通信を前記サーバアプリケーションへのアプリケーション通信にプロトコル変換し、前記サーバアプリケーションが当該アプリケーション通信に対応してサービス処理をすることを特徴とするシステム間通信処理方法。
【請求項６】
前記ストレージネットワークの利用を停止する場合に、前記コンシューマシステムストレージから前記サービスプロバイダシステムストレージへの前記データの伝送がされていない場合に、前記ストレージネットワークの利用を再開した後に、前記コンシューマシステムストレージに格納された前記データを、前記サービスプロバイダシステムストレージへ伝送することを特徴とする請求項５に記載のシステム間通信処理方法。
【請求項７】
サービスを提供するサーバアプリケーションを有するサービスプロバイダシステムと、サービスを利用するコンシューマアプリケーションを有するコンシューマシステムとが、ストレージネットワークに接続され、前記サービスプロバイダシステムと前記コンシューマシステムとの間のサービスを行なうための通信処理システムであって、
前記コンシューマシステムは、前記コンシューマアプリケーションで用いるアプリケーション通信をストレージ通信にプロトコル変換するプロトコル変換部を具備し、プロトコル変換部によってプロトコル変換したストレージ通信を、前記ストレージネットワークを介して前記サービスプロバイダシステムに伝送し、
前記サービスプロバイダシステムは、サービスプロバイダシステムから伝送されたストレージ通信を前記サーバアプリケーションへのアプリケーション通信に変換するプロトコル変換部と、当該アプリケーション通信に対応してサービス処理をするサーバアプリケーションとを具備することを特徴とするシステム間通信処理システム。
【請求項８】
サービスを提供するサーバアプリケーションを有するサービスプロバイダシステムと、サービスを利用するコンシューマアプリケーションを有するコンシューマシステムとが、ストレージネットワークに接続され、前記サービスプロバイダシステムと前記コンシューマシステムとの間のサービスを行なうための通信処理システムであって、
前記コンシューマシステムは、前記コンシューマアプリケーションで用いるアプリケーション通信をストレージ通信にプロトコル変換するプロトコル変換部と、前記ストレージネットワークに接続され、データを格納するために前記コンシューマシステムに設けられ、当該変換されたストレージ通信メッセージのデータを格納するコンシューマシステムストレージとを具備し、
前記ストレージネットワークが、前記格納されたストレージ通信メッセージのデータを、前記ストレージネットワークに接続され、データを格納するために前記サービスプロバイダシステムに具備するサービスプロバイダシステムストレージに伝送して格納し、
前記サービスプロバイダシステムは、前記サービスプロバイダシステムストレージに格納されたストレージ通信を前記サーバアプリケーションへのアプリケーション通信に変換するプロトコル変換部と、当該アプリケーション通信に対応してサービス処理をするサーバアプリケーションとを具備することを特徴とするシステム間通信処理システム。
【請求項９】
サービスを提供するサーバアプリケーションを有するサービスプロバイダシステムと、サービスを利用するコンシューマアプリケーションを有するコンシューマシステムとが、ストレージネットワークに接続され、前記サービスプロバイダシステムと前記コンシューマシステムとの間のサービスを行なうシステムとしてコンピュータを機能させるための通信処理プログラムであって、
前記コンシューマシステムは、前記コンシューマアプリケーションで用いるアプリケーション通信をストレージ通信にプロトコル変換するプロトコル変換部を具備し、プロトコル変換部によってプロトコル変換したストレージ通信を、前記ストレージネットワークを介して前記サービスプロバイダシステムに伝送し、
前記サービスプロバイダシステムは、サービスプロバイダシステムから伝送されたストレージ通信を前記サーバアプリケーションへのアプリケーション通信に変換するプロトコル変換部と、当該アプリケーション通信に対応してサービス処理をするサーバアプリケーションとを具備するシステムとしてコンピュータを機能させることを特徴とするシステム間通信処理プログラム。
【請求項１０】
サービスを提供するサーバアプリケーションを有するサービスプロバイダシステムと、サービスを利用するコンシューマアプリケーションを有するコンシューマシステムとが、ストレージネットワークに接続され、前記サービスプロバイダシステムと前記コンシューマシステムとの間のサービスを行なうシステムとしてコンピュータを機能させるための通信処理プログラムであって、
前記コンシューマシステムは、前記コンシューマアプリケーションで用いるアプリケーション通信をストレージ通信にプロトコル変換するプロトコル変換部と、前記ストレージネットワークに接続され、データを格納するために前記コンシューマシステムに設けられ、当該変換されたストレージ通信メッセージのデータを格納するコンシューマシステムストレージとを具備し、
前記ストレージネットワークが、前記格納されたストレージ通信メッセージのデータを、前記ストレージネットワークに接続され、データを格納するために前記サービスプロバイダシステムに具備するサービスプロバイダシステムストレージに伝送して格納し、
前記サービスプロバイダシステムは、前記サービスプロバイダシステムストレージに格納されたストレージ通信を前記サーバアプリケーションへのアプリケーション通信に変換するプロトコル変換部と、当該アプリケーション通信に対応してサービス処理をするサーバアプリケーションとを具備するシステムとしてコンピュータを機能させることを特徴とするシステム間通信処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストレージネットワークで接続されたシステム間において通信処理を行なうための技術に関する。
【背景技術】
【０００２】
情報化の進展に伴い、企業間などコンピュータシステム間で通信を行ない、いわゆるオンラインでサービス処理を行なうケースが多くなっている。システム間通信においては、高信頼性を確保することの重要性が高まっている。例えば、システム間接続回線の１つに障害が発生した場合でも、予備の回線などを用いることで通信を行ない、企業間のサービス処理を継続することが要求される。また、予備回線を含めた通信の効率化が要求される。
【０００３】
なお、システム間接続における基本的な要件には、オープンで安価であることが挙げられる。すなわち、仕様が公開され（すなわち、独自に開発した仕様ではなく）相互接続性が高いこと、市販製品により（すなわち、特定の環境でのみの利用のための独自に開発するプロプラエタリなソフトウェアやハードウェアではなく）低コストで構築でき運用し易いこと、が要求される。
【０００４】
システム間のサービス処理に用いられるアプリケーション間通信プロトコルには、例えば、ＳＯＡＰ（Simple Object Access Protocol）がある。ＳＯＡＰの仕様は、Ｗ３Ｃ（World Wide Web Consortium）が策定している。ＳＯＡＰの下位プロトコルは、限定はされていないが、主にＨＴＴＰ（HyperText Transfer Protocol）が用いられ、ＩＰ（Internet Protocol）ネットワークが用いられる。ＳＯＡＰメッセージに添付データを追加する機能の標準化が進められている。例えば、SOAP Messages with Attachmentsと言う仕様がＷ３Ｃに提出されている。また、ＤＩＭＥ（Direct Internet Message Encapsulation）を使ってＳＯＡＰメッセージと添付データを扱う仕様WS-AttachmentsがＩＥＴＦ（Internet Engineering Task Force）で策定されている。
【０００５】
一方、システム間でデータを授受する場合や、複数サーバ間でデータを共有する場合に、例えば、ＳＡＮ（Storage Area Network）と呼ばれる技術が用いられる。ＳＡＮにより、例えば、ディザスタリカバリ（災害対策）などのため重要なデータのバックアップを取得するために、ストレージネットワークを経由し、遠隔地のストレージシステムとの間でデータを受け渡すことが行われている。ストレージネットワーク関連の業界団体ＳＮＩＡ(Storage Networking Industry Association)は、ストレージネットワーキング技術の啓蒙や標準化を中心に活動し、ＳＡＮ関連製品の相互接続性の検証も行なっている。
【０００６】
ＳＡＮに用いられる伝送のためのインタフェイス規格に、Fibre Channel（以下ＦＣと略す）がある。ＦＣのインタフェイス規格はＡＮＳＩ（American National Standards Institute）で標準化が行われている。また、ＦＣ関連の製品ベンダなどによる業界団体ＦＣＩＡ（Fibre Channel Industry Association）が、同規格を支持し、各ベンダにより製品開発されている。ＦＣでは、一般的にはＩＰネットワークとは独立したストレージ専用のネットワークを構築する。ＦＣのプロトコルについては、シリアルＳＣＳＩ（Small Computer System Interface）を採用したＦＣＰ（Fibre Channel Protocol）の標準化が、ＡＮＳＩにより進められている。
【０００７】
また、ＩＰネットワーク上でＳＣＳＩコマンドを用いてストレージ間のデータ伝送を行なうプロトコル規格にｉＳＣＳＩがある。同規格はＩＥＴＦで標準化が進められている。
従来のシステム間の通信システムでは、ＬＡＮと公衆網と効率的に切り替えて使用することでネットワーク障害に対処するとともに通信費の低減を図った通信装置および方法がある（例えば、後述する特許文献１参照）。
【０００８】
また、二重系ネットワークにおける障害検知および回復をするために、複数のネットワークドライバと、上位のアプリケーションとのインタフェイスとなる冗長なネットワークドライバを配置しているものがある（例えば、後述する特許文献２参照）。
【０００９】
以下、特許文献に記載された従来の高信頼性確保および通信効率化のためのシステム間通信処理方法について説明する。
【００１０】
下記特許文献１には、ＬＡＮの障害の有無を検知する検知手段と、公衆網経由でデータ送信中に、送信データを所定のタイミングで、ＬＡＮ経由での送信に切り替える切替手段とを備え、公衆網経由でデータ送信中に、前記検出手段によりＬＡＮ（Local Area Network）の障害が復旧したことを検知したら、前記切替手段によりＬＡＮ経由で未送信データを送信する、ＬＡＮ及び公衆網に接続された通信装置が開示されている。
【００１１】
下記特許文献２には、プライマリと代替の、複数のＩＰネットワークを用いる。通常は各コンピュータが適宜好適な方のネットワークをデフォルトネットワークとする。定期的にネットワークをチェックし、障害を検知したらルーティングテーブルを書き換えて、デフォルトでない方のネットワークを利用するようにする。冗長ネットワークドライバ（Redundant Network Driver）において、ネットワーク障害検知と回復のアルゴリズム（Network Fault Detection and Recovery (NFDR) algorithm）が、障害を検知し、上記の処理制御を行なう。
【００１２】
下記特許文献３には、ストレージシステムについて、ホスト−ストレージシステム間のインタフェイスをＬＡＮ及びＳＡＮで二重化し切り替える技術が記載されている。
【００１３】
下記特許文献４には、インターネットとストレージネットワークとを併用し、データによって両ネットワークを使い分けるデータ参照方法が記載されている。
【００１４】
【特許文献１】特開２００１−１１９４２２号公報
【特許文献２】United Sates Patent 6,581,166（Abstract, FIG.2, FIG.3）
【特許文献３】特開２００２−２２９７４０号公報
【特許文献４】特開２００２−１８３０００号公報
【発明の開示】
【発明が解決しようとする課題】
【００１５】
前述のWS-Attachmentsのように、システム間のアプリケーション間通信では、サイズの大きい添付データをメッセージと一緒に送信することが想定される。ＩＰネットワークでシステム間通信を行なう際に、メッセージを多数送受信する中で、長大な添付データを伝送することは、ネットワーク伝送効率の劣化につながると考えられる。
【００１６】
また、もとより長大データのデータ伝送に用いられるＦＣのストレージネットワークと比べると、ＩＰネットワークは、パケットサイズが小さいことによるプロセッサ割り込みとパケット処理のオーバヘッド、上位のプロトコルの処理のオーバヘッド、データレートの低さなどにより、データ伝送のスループットは一般に低くなる。
【００１７】
前記の従来技術（特許文献１）では、公衆網経由でデータ送信中に、ＬＡＮが復旧したら、ＬＡＮ経由で未送信データを送信する。これにより、公衆網の使用率を低減し通信費の削減を図る。しかし、各ネットワークのデータ伝送効率と、伝送するデータの種別から、各データ伝送に最適なネットワークを選定してシステム間全体でのデータ伝送の効率化を図ることは考慮されていない。特に、伝送効率化および信頼性向上のためにストレージネットワークを使用することも考慮されていない。
【００１８】
前記の従来技術（特許文献２）では、複数のネットワークインタフェイスカード（以下、ＮＩＣと略す）を用いるネットワークドライバが記載されている。しかし、いずれのネットワークも同等のＩＰネットワークを対象としている。すなわち、複数のネットワークがそれぞれのデータ伝送の特性を活かした上で伝送効率の向上を図ることは考慮されていない。特に、伝送効率化および信頼性向上のためにストレージネットワークを使用することも考慮されていない。
【００１９】
前記の従来技術（特許文献３）では、ＳＡＮの障害時にＬＡＮで代用する技術が記載されている。しかし、この技術は、ホスト−ストレージ間の通信のための技術であり、ホスト間のＳＡＮによる通信或いはプロトコル変換の構成要素については記載されておらず、ストレージネットワークによるシステム間のアプリケーション通信を実現することはできない。
【００２０】
前記の従来技術（特許文献４）では、ＳＡＮの障害時にＬＡＮで代用する技術が記載されている。しかし、この技術は、ストレージに格納されたデータをストレージからサーバへ伝送するための技術であり、サーバ間のＳＡＮによる通信については記載されておらず、ストレージネットワークによるシステム間のアプリケーション通信を実現することはできない。
【００２１】
すなわち、システム間通信において、従来技術では、以下の問題がある。あるアプリケーション間通信用のネットワーク回線に障害が発生しても別の回線で通信が継続できるように通信の信頼性を確保するためには、同様の冗長なネットワーク回線が必要となり、冗長な回線を利用するためのコスト（通信利用、回線契約、維持のコスト）がかかる。
【００２２】
ストレージネットワークで接続されたシステム間においても、ストレージネットワークをアプリケーション間通信用のネットワークの代替手段とすることができない。ＩＰネットワーク通信で負荷のかかる長大なアプリケーション間通信データのデータ伝送を、ストレージネットワークを使用し、アプリケーションに対して通常のアプリケーション間通信と同等となるように処理することができない。ストレージネットワークのデータ伝送を活用し、システム間のアプリケーション間通信のデータ伝送について効率化を図ることはできない。
【００２３】
本発明が解決しようとする課題は、システム間のアプリケーション間通信処理において、データ伝送の効率化と、通信の信頼性を確保することにある。本出願人が知る公知の文献には、上記の問題を解決する方法が開示されていない。
【課題を解決するための手段】
【００２４】
本発明によれば、上記の課題を解決し、サービスを提供するサーバアプリケーションを有するサービスプロバイダシステムと、サービスを利用するコンシューマアプリケーションを有するコンシューマシステムとが、ストレージネットワークに接続され、前記サービスプロバイダシステムと前記コンシューマシステムとの間のサービスを行なうために、前記コンシューマシステムに設けられたプロトコル変換部が、前記コンシューマアプリケーションで用いるアプリケーション通信をストレージネットワークで用いるストレージ通信にプロトコル変換を行ない、前記ストレージネットワークが前記変換されたストレージ通信を前記サービスプロバイダシステムに伝送し、前記サービスプロバイダシステムに設けられたプロトコル変換部が、伝送されたストレージ通信を前記サーバアプリケーションへのアプリケーション通信にプロトコル変換し、前記サーバアプリケーションが当該アプリケーション通信に対応してサービス処理をする。このため、本発明によれば、システム間のアプリケーション通信において、ストレージネットワークを使用してデータ伝送することができる。
【発明の効果】
【００２５】
本発明によれば、ストレージネットワークを経路に用いて、システム間のアプリケーション間通信のデータ伝送を行なう。これにより、ＩＰネットワークの負荷を軽減するとともに、ストレージネットワークのデータ伝送を有効活用することにより、システム間のアプリケーション間通信のデータ伝送の効率化を図ることができる、という効果がある。
また、システム間接続のＩＰネットワークを多重化せずとも、ストレージネットワークを代替経路とすることで、システム間のサービス処理の通信を継続することができる。これにより、低コストで、かつ、通信の高信頼を確保することができる、という効果がある。
【発明を実施するための最良の形態】
【００２６】
以下、本発明を実施するために本出願人が最良と思う実施の形態を、図面を用いて詳細に説明する。なお、以下に示す内容は、本発明を理解し易くするための例であり、本発明は、以下の具体例に限定されるものではない。抽象化や拡張が考えられることを、後述する。
【００２７】
図１に、本発明の１つの実施の形態であるシステムの構成概要を示す。本システムは、システム間でサービス処理をするシステムである。サービスプロバイダシステム１１６がサービスを提供し、コンシューマシステム１０１がそのサービスを利用する。コンシューマシステム１０１のコンシューマアプリケーション部１０３が、サービスプロバイダシステム１１６のサーバアプリケーション部１１８が提供するサービスを利用する。
【００２８】
本システムは、システム間通信で高信頼を要求されるシステムを想定している。例えば、コンシューマシステム１０１は地方銀行のシステムとし、顧客からの金融サービスの取引要求を受け付けた受付情報の管理を行ない、サービスプロバイダシステム１１６は、複数銀行間の共同センタや大手金融機関などのシステムで、当該金融サービスの実際の取引処理を行なうシステムとしてもよい。すなわち、地方銀行などのシステムから、共同センタなどのシステムが提供するサービスを利用する。
【００２９】
コンシューマシステム１０１とサービスプロバイダシステム１１６の間は、アプリケーションネットワークであるＩＰネットワーク１１４と、ＦＣによるストレージネットワーク１１５で接続されている。コンシューマアプリケーション部１０３とサーバアプリケーション部１１８のアプリケーション通信は、通常時は主にＩＰネットワーク１１４で伝送するものとする。一方、コンシューマシステム１０１とサービスプロバイダシステム１１６との間で、大量のデータの授受を行なう場合は、それぞれ、コンシューマシステムストレージ１１３、サービスプロバイダシステムストレージ１２８を用いて、ストレージネットワーク１１５で伝送する。
【００３０】
本システムは、計算機およびネットワーク通信手段により構成されるシステムである。本システムでのデータ処理は、計算機装置上でプログラムを実行することによって実現する。以下の説明では、本システムを構成する要素がデータ処理を行なうことを示すが、それらのデータ処理は、それぞれの要素に対応した計算機上でプログラムを実行することによって実現する。また、それぞれの要素は、以下に説明するデータの授受を行なう。それらのデータ授受は、通信手段を介して行なう。これらのプログラムは、ハードディスク装置、ＣＤ−ＲＯＭなどの計算機で読み書きができる記憶媒体に格納し、通信手段を通してプログラムにアクセスする。すなわち、本システムは、計算機および通信手段によって実現される。
【００３１】
本システムを構成する主な要素を、以下簡単に説明する。
コンシューマシステム１０１は、以下の構成要素を含む。
コンシューマアプリケーション部１０３は、ＳＯＡＰクライアントとなり、ＳＯＡＰサービスを要求し、利用するアプリケーション処理を行なう。コンシューマ通信プロキシ部１０５は、コンシューマアプリケーション部１０３とのアプリケーション通信を中継する。すなわち、ＳＯＡＰサービス通信のＨＴＴＰリクエストおよびレスポンスを中継する。コンシューマシステム１０１のホストバスアダプタ（以下、ＨＢＡと略す）制御部１１０は、ストレージネットワーク１１５への接続とデータ送受信の制御を行なう。
【００３２】
サービスプロバイダシステム１１６は、以下の構成要素を含む。
サーバアプリケーション部１１８は、ＳＯＡＰサーバとなり、ＳＯＡＰサービスの要求に対するサービス処理を行なう。サーバ通信プロキシ部１２０は、サーバアプリケーション部１１８とのアプリケーション通信を中継する。すなわち、ＳＯＡＰサービス通信のＨＴＴＰリクエストおよびレスポンスを中継する。サービスプロバイダシステム１１６のＨＢＡ制御部１２５は、ストレージネットワーク１１５への接続とデータ送受信の制御を行なう。
【００３３】
以下、本システムでのシステム間サービスの通信処理の流れについて概略を説明する。ＦＣによるストレージネットワーク経路を利用したＳＯＡＰサービス通信処理について説明する。まず、基本となる処理方式として、ＳＯＡＰサービス通信をストレージネットワーク経路で伝送する処理について説明する。のちに、添付データ部とＳＯＡＰメッセージ部を分けて、それぞれの伝送にストレージネットワークとＩＰネットワークを用いる処理、ストレージに伝送データを一旦格納することで配送保証する処理、ＩＰネットワークの障害時にストレージネットワークを用いるよう選定する処理などを示す。
【００３４】
図２に、本システムにおけるサービス処理における通信処理フローの概要を示す。コンシューマアプリケーション部１０３は、コンシューマ通信プロキシ部１０５に対して、サービス処理要求を伝える（２０１）。より詳細には、コンシューマアプリケーション部１０３がＳＯＡＰクライアント部１０４を利用し、ＳＯＡＰリクエスト呼び出しを行なう。ＳＯＡＰクライアント部１０４は、当該ＳＯＡＰリクエストをＨＴＴＰリクエストとしてコンシューマ通信プロキシ部１０５に伝える。ＳＯＡＰクライアント部１０４の設定により、ＨＴＴＰ通信接続のプロキシサーバとしてコンシューマ通信プロキシ部１０５が指定されているものとする。
【００３５】
このサービス処理要求２０１において、要求の内容（ＨＴＴＰリクエストの内容）２０２には、要求先システム識別子、サービス識別子、サービス処理要求内容が含まれる。例えば、要求元システム識別子は、サービスプロバイダシステム１１６を識別するものであり、例えば、abcdefg.comのような識別子で指定されるものである。サービス識別子は、例えば、ＳＯＡＰサービスを識別するＵＲＩ（Uniform Resource Identifier）で示される。サービス処理要求内容は、例えば、金融サービスにおける融資要求の場合の、申込者や融資金額、返済条件などを示すデータである。また、例えば、契約書や融資審査に用いられる各種書類のイメージデータを添付データとして扱う。
【００３６】
コンシューマ通信プロキシ部１０５は、当該要求を、要求先システム識別子で示されるサービスプロバイダシステム１１６に通信するための、通信手段を選定する（２０３）。
ここでは、添付データが多いこと、ＩＰネットワーク１１４の負荷が高いことから、通信手段としてストレージネットワーク１１５の経路を選定したものとする。このような選定は、後述する通信手段選定部１０７により、添付データのデータ種別（画像などのマルチメディアデータなど）や、通信制御状態検知部１０８によるＩＰネットワーク１１４の負荷状況の情報をもとに、選定する。
【００３７】
コンシューマ通信プロキシ部１０５は、ストレージネットワーク１１５における要求先システムへの転送先デバイス対象を特定する（２０４）。すなわち、要求先システムでのリクエスト受信用デバイス識別子を取得する。デバイス識別子は、ストレージネットワーク１１５に接続されているデバイスを識別するものであり、例えば、ＳＣＳＩのＩＤとＬＵＮ（Logical Unit Number）である。当該転送先デバイス識別子を取得するには、例えば、当該ＳＯＡＰサービスの定義をＵＤＤＩ（Universal Description Discovery and Integration）で検索して得られる、ＷＳＤＬ(Web Service Description Language)で記述された定義情報に、要求先リクエスト受信用デバイス識別子を指定しておき、その値を取得するようにしてもよい。
【００３８】
コンシューマ通信プロキシ部１０５は、コンシューマシステム１０１におけるストレージ通信の送信用のデバイス識別子と、受信用のデバイス識別子を取得する。例えば、図７で後述する、ストレージ通信デバイス定義を参照することで取得する。これらのストレージ通信用デバイス識別子は、Ｒａｗデバイスを識別するものとする。さらにそれらのＲａｗデバイスは、ストレージ通信用のＨＢＡ制御部１１０における、それぞれ、リクエスト送信用ＳＣＳＩイニシエータ１１１、レスポンス受信用ＳＣＳＩターゲット１１２に、対応しているものとする。このようにするのは、コンシューマ通信プロキシ部１０５が、ＯＳ（Operating System）のカーネルの一般的な機能を用いて、デバイスにアクセスし利用できるようにするためである。
【００３９】
コンシューマアプリケーション通信−ストレージ通信プロトコル変換部１０６は、ＳＯＡＰリクエストのアプリケーション通信を、ストレージ通信に変換する（２０５）。すなわち、当該要求のＨＴＴＰリクエストを、リクエスト送信用デバイスに対するＲａｗデバイスへのＩＯ要求に変換する。通信メッセージ内容のデータ構造は、図６を用いて後述する。なお、この変換の際、レスポンス受信用デバイス識別子を、ＳＯＡＰヘッダに含めておく。そのデバイス識別子を利用したレスポンス送信処理は、後述する。
【００４０】
コンシューマ通信プロキシ部１０５は、上記変換したデバイスへの要求をもとに、コンシューマシステム１０１のＨＢＡ制御部１１０に対してストレージ通信要求をする（２０６）。なお、コンシューマ通信プロキシ部１０５は、当該要求処理のスレッドを割り当てる。このスレッドにより、後述のように伝送完了をうけて、レスポンス受信の制御を行なう。また、複数のストレージ通信送受信を並行して行なう場合に、それぞれスレッドを割り当てて行なえるようにする。
【００４１】
ＨＢＡ制御部１１０への通信要求では、上記のとおり取得した、要求元としてリクエスト送信用デバイス識別子を、要求先として要求先リクエスト受信用デバイス識別子を、指定する。ＨＢＡ制御部１１０は、指定された送信元、送信先のデバイス識別子で示される各デバイスを対象として、当該要求内容の伝送データ２２６を、ストレージネットワーク１１５で伝送する（２０７）。すなわち、リクエスト送信用ＳＣＳＩイニシエータ１１１と、リクエスト受信用ＳＣＳＩターゲット１２６をコネクトし、ＳＣＳＩ  Ｗｒｉｔｅコマンドを実行する。サービスプロバイダシステム１１６では、リクエスト受信用ＳＣＳＩターゲット１２６で当該伝送を受信し（２０８）、リクエスト送信用ＳＣＳＩイニシエータ１１１へ伝送完了を通知する（２０９）。
【００４２】
当該伝送が成功すると、リクエスト送信用ＳＣＳＩイニシエータ１１１は、サービスプロバイダシステム１１６側から、伝送完了通知を受け取る（２１０）。なお、サービスプロバイダシステム１１６側の処理は、このあとつづいて説明する。
【００４３】
コンシューマ通信プロキシ１０５の送信処理スレッドは、伝送完了通知を受けて、レスポンス受信処理用の処理スレッドを割り当てる（２１１）。コンシューマ通信プロキシ１０５は、上記で取得したレスポンス受信用デバイス識別子により、レスポンス受信用ＳＣＳＩターゲット１１２のＲａｗデバイスを特定する（２１２）。レスポンス受信処理スレッドは、当該Ｒａｗデバイスに対する伝送受信待ち（レスポンス受信待ち）になる（２１３）。
【００４４】
一方、サービスプロバイダシステム１１６側では、コンシューマシステム１０１からの伝送要求２０７に対して、リクエスト受信用ＳＣＳＩターゲット１２６が、伝送を受信する２０８。ＨＢＡ制御部１２５は、当該伝送内容を、サーバ通信プロキシ部１２０に伝える（２１４）。サーバ通信プロキシ部１２０は、サーバアプリケーション通信−ストレージ通信プロトコル変換部１２１により、伝送内容を、アプリケーション通信プロトコルであるＨＴＴＰリクエストに変換する（２１５）。
【００４５】
サーバ通信プロキシ部１２０は、ＳＯＡＰサーバ部１１９に当該ＨＴＴＰリクエストを転送し、サービス処理要求する（２１６）。ＳＯＡＰサーバ部１１９は、当該ＨＴＴＰリクエスト、すなわち、ＳＯＡＰリクエストを、当該リクエスト処理に対応する、ＳＯＡＰサーバであるサーバアプリケーション部１１８に伝える。このＳＯＡＰサーバアプリケーションの呼び出しは、一般的なＳＯＡＰサーバ機能によるものでよい。
【００４６】
サーバアプリケーション部１１８は、当該ＳＯＡＰリクエストに応じたサービス処理を行ない、応答メッセージ（ＳＯＡＰレスポンス）を返信する（２１７）。当該返信は、ＳＯＡＰサーバ部１１９により、ＨＴＴＰレスポンスとして、サーバ通信プロキシ部１２０に返送される。
【００４７】
サーバ通信プロキシ部１２０は、当該処理要求のＳＯＡＰヘッダ情報から、コンシューマシステム１０１側で先に設定された、レスポンス受信用のデバイス識別子を取得する。これにより、レスポンス受信用ＳＣＳＩターゲット１１２を特定する（２１８）。サーバ通信プロキシ部１２０は、サーバアプリケーション通信−ストレージ通信プロトコル変換部１２１により、当該ＨＴＴＰレスポンスを、ストレージ通信プロトコルのＳＣＳＩ伝送に変換する（２１９）。
【００４８】
サーバ通信プロキシ部１２０は、上記で取得したレスポンス送信元、送信先のデバイス識別子を指定して、ＨＢＡ制御部１２５に、当該レスポンスを、レスポンス送信用ＳＣＳＩイニシエータ１２７から、レスポンス受信用ＳＣＳＩターゲット１１２に、伝送するよう要求する（２２０）。コンシューマシステム１０１では、レスポンス受信用ＳＣＳＩターゲット１１２で当該伝送を受信する（２２２）。
【００４９】
これを受けて、ＨＢＡ制御部１１０は、レスポンス受信待ちとなっているコンシューマ通信プロキシ部１０５の受信処理スレッドに、当該伝送データを転送する（２２３）。コンシューマ通信プロキシ部１０５は、コンシューマアプリケーション通信−ストレージ通信プロトコル変換部１０６により、当該レスポンス伝送内容を、ＨＴＴＰレスポンスに変換する（２２４）。コンシューマ通信プロキシ部１０５は、当該ＨＴＴＰレスポンスを、ＳＯＡＰクライアント部１０４に返送し、コンシューマアプリケーション部１０３は、ＳＯＡＰレスポンスとして受け取る（２２５）。
【００５０】
以上により、ストレージネットワークを伝送路としたＳＯＡＰサービス通信が実現される。以上のように、本発明によるシステム間サービス通信処理を行なうことにより、以下の効果がある。
本発明では、アプリケーション通信とストレージ通信プロトコル変換により、ＳＯＡＰクライアントからのＨＴＴＰプロトコルメッセージを、ＳＣＳＩプロトコルに変換する。ＨＴＴＰメッセージデータを、ＳＣＳＩの伝送データとして、ＦＣによるストレージネットワークで伝送する。また、サービスプロバイダシステム側で、ＳＣＳＩ伝送データをＨＴＴＰメッセージに変換し、ＳＯＡＰサーバに伝える。この処理において、ＩＰネットワークは利用しない。
【００５１】
これにより、ＳＯＡＰリクエストをストレージネットワークで伝送することができる。
すなわち、システム間のアプリケーション通信を、ストレージネットワーク経由で通信することができる。長大データの伝送効率の良いストレージネットワークを利用することで、ＩＰネットワークの負荷を低減し、アプリケーション間通信の伝送効率の向上を図ることができる。ＩＰネットワークがなくてもアプリケーション通信が可能となる。システム間で回線を多重化せずとも、ＩＰネットワークが障害の場合でも、ストレージネットワークによりアプリケーション間通信の継続が可能となる。
【００５２】
なお、本例では、簡単のため、コンシューマシステム１０１とサービスプロバイダシステム１１６とをそれぞれ例示しているが、コンシューマシステムとサービスプロバイダシステムは互いに排他的であるわけではなく、同一システム内にコンシューマアプリケーション部１０３とサーバアプリケーション部１１８が共存し、コンシューマシステムでありかつサービスプロバイダシステムとなってもよい。
【００５３】
この場合、コンシューマ通信プロキシ部１０５、サーバ通信プロキシ部１２０は、共通の機能を有する１つの実装部としてもよい。同様に、コンシューマアプリケーション通信−ストレージ通信プロトコル変換部１０６とサーバアプリケーション通信−ストレージ通信プロトコル変換部１２１は、共通の機能を有する１つの実装部としてもよい。上記の例では、ＳＣＳＩターゲット、ＳＣＳＩイニシエータを別々に記載しているが、ターゲット、イニシエータ両方のモードに対応するデバイスがあれば、そのようなデバイスを用いてもよい。
【００５４】
上記の例では、リクエストとレスポンスで、ＳＣＳＩイニシエータとＳＣＳＩターゲットの組み合わせを、それぞれ用いたが、１組のイニシエータ−ターゲットで、ＳＣＳＩ  Ｗｒｉｔｅコマンドの応答で、レスポンスを受信するようにしてもよい。なお、Ｗｒｉｔｅコマンド送信後に一旦コネクションを切断し、レスポンス受信の際にリコネクトしてもよい。これにより、受信用スレッドを起動して待ち状態にしておくのではなく、リコネクトを契機に、レスポンス受信処理用のスレッドを起動し、コンシューマ通信プロキシ部１０５に転送するようにしてもよい。
【００５５】
上記の例では、ＦＣのストレージネットワークの例を示したが、本発明はＦＣに限定するものではない。ストレージ専用のネットワークと、通常のアプリケーション間通信のネットワークとの両方を利用するシステム間通信に、本発明を適用することができる。
【００５６】
次に、通信プロトコル階層（プロトコルスタック）を用いて、本発明の通信処理の体系について説明する。
【００５７】
図３に、本発明の通信処理における通信プロトコル階層の概要図を示す。一般的なＳＯＡＰ通信でのプロトコル階層を３０１に示す。下位にＨＴＴＰプロトコルを用い、さらにＴＣＰ／ＩＰプロトコルを用い、物理層はＮＩＣを用いる。一方、本発明のストレージネットワークによる通信のプロトコル階層を３０２に示す。アプリケーション層では、ＨＴＴＰプロトコルをインタフェイスとして、下位にアクセスする。コンシューマ通信プロキシ部１０５、サーバ通信プロキシ部１２０が、ＨＴＴＰプロキシとなる。
【００５８】
コンシューマ通信プロキシ部１０５、サーバ通信プロキシ部１２０は、ＲａｗデバイスＩＯのインタフェイスを利用して、下位にアクセスする。Ｒａｗデバイスからは、ＯＳの機能により、ＳＣＳＩデバイスドライバにＲｅａｄ／Ｗｒｉｔｅを行なう。ＳＣＳＩデバイスドライバは、バス／ネットワーク層以下となるＦＣ接続のＨＢＡにＳＣＳＩ  Ｒｅａｄ／Ｗｒｉｔｅを行ない、当該コマンドはＦＣＰにより伝送される。
【００５９】
なお、この概要図は、本発明の通信処理の体系を理解し易くするために示したものであり、厳密な階層を示したものではない。一般的なＳＯＡＰ通信でのプロトコル階層と、本発明のストレージ入出力プロトコル階層のそれぞれ階層は、必ずしも対応するものではない。
【００６０】
本発明では、コンシューマ通信プロキシ部１０５、サーバ通信プロキシ部１２０が、ＨＴＴＰプロキシとなることにより、ＳＯＡＰに限らず、一般的にＨＴＴＰ通信をストレージネットワーク経由で行なうことができる。例えば、ＷｅｂブラウザからＨＴＴＰプロキシを通して、サービスプロバイダシステム側の静的ＨＴＭＬコンテンツを取得してもよい。ＩＰネットワークを用いなくても、ストレージネットワークのみで、ＨＴＴＰ通信を行なうことができる。
【００６１】
また、ＨＴＴＰプロキシでなくてもよい。ＨＴＴＰプロトコルとしなくても、ＳＯＡＰプロトコルから、ストレージ通信プロトコルに直接的にマッピングするような機能レイヤで実装してもよく、それによりＳＯＡＰプロトコルとストレージ通信プロトコルへのマッピングの効率化を図っても良い。また、ＨＴＴＰプロキシは、のちに図４、図５に示すように、３０１と３０２のプロトコルを併用するようにしても良い。
【００６２】
本発明で利用するアプリケーション通信プロトコルはＳＯＡＰに限定されるものではない。上記の例でＳＯＡＰプロトコルを用いているところを、他のアプリケーション間通信プロトコルに置き換えることにより、アプリケーション間通信一般に、本発明の方法は適用できる。例えば、ＲＰＣ（Remote Procedure Call）、ＣＯＲＢＡ（Common Object Request Broker Architecture）、ＲＭＩ（Remote Method Invocation）などでもよい。特に、ＳＯＡＰヘッダを含むような制御メッセージの部分と、添付データの部分を伝送するアプリケーション間通信に、本発明は有効である。
【００６３】
コンシューマアプリケーション部１０３が要求する際のアプリケーション通信プロトコルと、サーバアプリケーション部１１８のアプリケーション通信プロトコルは、互いに異なっていても良い。コンシューマ通信プロキシ部１０５、サーバ通信プロキシ部１２０が、それぞれのプロトコル変換を行なえればよい。これにより、ＯＳやＯＬＴＰなどの実行基盤、開発言語に依存せず、アプリケーション間通信を行なうことができる。
【００６４】
上記の例では、ストレージ制御コマンドにＳＣＳＩを用いているが、本発明はこれに限定するものではない。上記の例の説明のＳＣＳＩの箇所を、他のストレージ制御コマンドに置き換えて、実現してもよい。
【００６５】
ストレージシステムの管理用のアプリケーションのために、本発明のストレージネットワーク経路での通信メッセージを用いてもよい。例えば、ストレージデバイス構成定義管理アプリケーションの通信を、ＦＣ経路で伝送してもよい。これにより、ＩＰネットワークを利用せずに、ＦＣ接続のみでストレージシステム管理アプリケーションの通信が可能になる。
【００６６】
次に、添付データとＳＯＡＰメッセージ部を分けて、それぞれの伝送にストレージネットワークとＩＰネットワークを用いる処理について、図４、図５を用いて説明する。
【００６７】
基本的な構成は図１と同じである。違いは、図４に示すように、コンシューマ通信プロキシ部１０５、サーバ通信プロキシ部１２０にそれぞれ、伝送データ分解・合成部４０１、４０２を具備する。これにより、ＳＯＡＰリクエストおよびレスポンスにおける、ＳＯＡＰメッセージ部と添付データ部の分解および合成を行なう。
【００６８】
図５に、処理の流れを示す。基本的な処理の流れは、図２で説明したとおりである。ここでは追加となるデータや処理を説明する。
要求の内容５０１には、要求先システム識別子、サービス識別子、サービス処理要求内容、添付データがある。コンシューマアプリケーション部１０３からのサービス処理要求を受け、コンシューマ通信プロキシ部１０５の伝送データ分解・合成部４０１は、ＳＯＡＰリクエストをＳＯＡＰメッセージ部と添付データに分解する（５０２）。
【００６９】
つづいて、ＳＯＡＰメッセージ部をＩＰネットワーク１１４で伝送する（５０３）。コンシューマ通信プロキシ部１０５が、ネットワークアダプタ制御部１０９を用いて伝送要求する。ＩＰネットワークでの伝送自体は、一般的な技術でよい。添付データの部分については、図２に示した処理と同様に伝送する（２０３〜２０６）。
【００７０】
サービスプロバイダシステム１１６側では、５０３により伝送されたＳＯＡＰメッセージ部と、図２の処理と同様に伝送された添付データ部の伝送を受けて、伝送データ分解・合成部４０２により、ＳＯＡＰメッセージ部と添付データを合成する（５０４）。なお、このとき、図６で後述するように、伝送データに含まれるメッセージ識別子をキーとして、同一のＳＯＡＰリクエストを構成するＳＯＡＰメッセージと添付データを合成する。
【００７１】
サーバアプリケーション部１１８によるＳＯＡＰサービス処理後のレスポンスでは、サーバ通信プロキシ部１２０は、ＳＯＡＰレスポンスを、伝送データ分解・合成部４０２により、ＳＯＡＰメッセージ部と添付データに分解する（５０５）。
【００７２】
つづいて、サーバ通信プロキシ部１２０は、ＳＯＡＰメッセージ部をＩＰネットワークで伝送する（５０６）。サーバ通信プロキシ部１２０が、ネットワークアダプタ制御部１２４を用いて伝送要求する。ＩＰネットワークでの伝送自体は、一般的な技術でよい。レスポンスの添付データの部分は、図２の処理と同様に、ストレージネットワークで伝送する（２１８〜２２４）。
【００７３】
コンシューマ通信プロキシ部１０５では、５０６により伝送されたＳＯＡＰメッセージ部と、図２の処理と同様に伝送された添付データ部の伝送を受けて、伝送データ分解・合成部４０１により、ＳＯＡＰメッセージ部と添付データを合成する（５０７）。合成したＳＯＡＰレスポンスメッセージをコンシューマアプリケーション部１０３に返送する（２２５）。
【００７４】
以上により、長大データに対する伝送効率の良いストレージネットワークを活用することにより、システム間のアプリケーション間通信におけるデータ伝送の効率化を図ることができる。
【００７５】
図６に、プロトコル変換により作成されるメッセージのデータ構成の概要を示す。
コンシューマアプリケーション部１０３からの要求メッセージとなるＨＴＴＰメッセージデータ２０２を、ＳＯＡＰメッセージ部や添付データのデータ伝送単位ごとに、ＳＣＳＩ伝送データ２２６とする。なお、ＳＣＳＩ伝送データ２２６の先頭部分には、上位の通信プロトコルの種別を示すコード６０１を保持する。この上位通信プロトコル種別コード６０１を用いて、前述２１４のように、サービスプロバイダシステム１１６側のＨＢＡ制御部１２５は、当該伝送データが上位のアプリケーション通信のデータであることを判別し、サーバ通信プロキシ部１２０にデータを転送する。これにより、より汎用的に、複数の通信種別に対応可能にすることができる。
【００７６】
または、上位通信プロトコル種別コード６０１を用いず、ＨＴＴＰメッセージデータ２０２のみを扱い、ＨＢＡ制御部１２５のリクエスト受信用ＳＣＳＩターゲット１２６が、判別することなく、サーバ通信プロキシ部１２０にデータを転送するようにしてもよい。
【００７７】
また、各ＳＣＳＩ伝送データには、メッセージ識別子６０２を含む。伝送データ分解・合成部４０１、４０２により、メッセージ分解時にメッセージ識別子６０２が設定され、メッセージ合成時にメッセージ識別子６０２をキーとして同一のＳＯＡＰリクエストまたはレスポンスを構成する伝送データを特定し、合成する。
【００７８】
また、伝送データの内容であるＳＯＡＰメッセージのＳＯＡＰヘッダの部分に、レスポンス送信先であるレスポンス受信用デバイス識別子６０３を含む。これにより、前述２１８のとおり、サービス処理のレスポンスの送信先であるデバイスを特定する。よって、レスポンス送信時に、定義などを参照することなく、送信先を特定することができる。
【００７９】
また、コンシューマシステム１０１側で、リクエスト送信時に、レスポンス受信用デバイスの障害などにより代替のデバイスに変更する場合には、当該指定をすることにより、サービスプロバイダ１１６側からのレスポンス送信先指定を、柔軟に対応することができる。
【００８０】
なお、ＳＯＡＰヘッダに含まれる項目の扱いは、ＳＯＡＰの仕様に従うものとする。すなわち、当該ＳＯＡＰメッセージを中継するコンシューマ通信プロキシ部１０５とサーバ通信プロキシ部１２０と間の取り決めにより、ＳＯＡＰヘッダの項目が扱われるものとする。
【００８１】
ＳＣＳＩ伝送データ２２６の物理層での伝送では、一般的なブロック転送により、複数のブロックに分割して伝送されてもよい。受信側のＨＢＡ制御部で分割された伝送データを組み立ててもよい。
【００８２】
サービスプロバイダ１１６側からのレスポンス送信時に、ＩＰネットワーク１１４が利用可能であれば、サーバ通信プロキシ部１２０で判定し、サーバアプリケーション通信−ストレージ通信プロトコル変換部１２１で変換することなく、ネットワークアダプタ制御部１２４を通してＩＰネットワーク１１４でレスポンスを返送するようにしてもよい。なお、添付データがない場合などは、ＳＯＡＰメッセージ部のみをＳＣＳＩ伝送データとするようにしてもよい。
【００８３】
図７に、ストレージ通信デバイス定義のデータ構造を示す。コンシューマシステム１０１のコンシューマシステムサーバ１０２における、ストレージ通信デバイス定義７０１は、リクエスト送信用デバイスの項７０２と、レスポンス受信用デバイスの項７０３からなる。
【００８４】
リクエスト送信用デバイスの項は、リクエスト送信時に用いるデバイスを識別する識別子を保持し、例えば、デバイスファイル識別子−ＳＣＳＩ ＩＤ０,  ＬＵＮ０のような値を持つ。レスポンス受信用デバイスの項は、レスポンス受信時に用いるデバイスを識別する識別子を保持し、デバイスファイル識別子−ＳＣＳＩ ＩＤ０,  ＬＵＮ１のような値を持つ。
【００８５】
サービスプロバイダシステム１１６のサービスプロバイダシステムサーバ１１７における、ストレージ通信デバイス定義７０４は、リクエスト受信用デバイスの項７０５と、レスポンス送信用デバイスの項７０６からなる。
【００８６】
リクエスト受信用デバイスの項は、リクエスト受信時に用いるデバイスを識別する識別子を保持し、例えば、デバイスファイル識別子−ＳＣＳＩ ＩＤ１,  ＬＵＮ０のような値を持つ。レスポンス送信用デバイスの項は、レスポンス送信時に用いるデバイスを識別する識別子を保持し、デバイスファイル識別子−ＳＣＳＩ ＩＤ１,  ＬＵＮ１のような値を持つ。
【００８７】
このようなデータ構造により、前述２０６、２１２、２２０のとおり、ストレージ通信で送受信するときに用いるデバイスを特定するために必要となる情報を保持管理することができる。
【００８８】
なお、本発明では、定義データの項目は、この例に限定されるものではなく、データ項目を適当に変更することで、構成管理に柔軟に対応させることができる。例えば、デバイスの指定を、サーバアプリケーション部１１８が提供するサービスの種類ごとに分けて指定できるようにしてもよい。
【００８９】
または、定義管理を利用せず、リクエスト送信用デバイス、レスポンス受信用デバイスは、ＩＰネットワークの代替通信経路用として、固定的に設定されていてもよい。
また、１つのデバイスが、イニシエータ、ターゲットの両方のモードに対応できるものであれば、送信用、受信用の区別なく指定できるようにしてもよい。
【００９０】
なお、サービスプロバイダシステム１１６側のリクエスト受信用デバイスに関しては、ＳＯＡＰサービスの定義であるＷＳＤＬ定義に指定し、ＵＤＤＩ検索を用いることとしてもよい。これにより、本方法のために個別に定義を設定することなく、環境設定および管理負担を軽減することができる。
【００９１】
また、ＳＯＡＰサービス定義でのリクエスト受信用デバイスの指定の有無により、当該ＳＯＡＰサービスのストレージネットワーク経由の通信の対応可否を示すこともできる。これにより、通信処理の未然にチェックアウトできれば、無駄な変換や通信を防ぐことができる。
【００９２】
また、送信元や送信先のデバイスの指定は論理的な指定とし、ＨＢＡ制御部１１０、１２５により、複数の物理的なデバイスを並列に利用するようにしてもよい。これにより、コンシューマ通信プロキシ部１０５およびサーバ通信プロキシ部１２０より上位では伝送の経路を論理的に１つだけ意識するだけでよく、ＨＢＡ制御部１１０、１２５により、データ伝送の効率が良くなるよう複数のデバイスを利用しても良い。
【００９３】
以下、上記で説明した具体例に限らず、拡張して考えられる構成および処理を示す。
次に、ストレージシステムを介したデータの授受により、通信を行なう処理を示す。
図８に示すように、図１と同様の構成において、コンシューマシステムストレージ１１３に、リクエスト送信エリア８１０とレスポンス受信エリア８１１を設ける。サービスプロバイダシステムストレージ１２８に、リクエスト受信エリア８１２とレスポンス送信エリア８１３を設ける。
【００９４】
リクエスト送信では、伝送データをリクエスト送信エリア８１０に書き込む（８０１）。この書き込まれた伝送データを、ストレージシステムのレプリケーション機能などにより、リクエスト受信エリア８１２に、ストレージネットワーク１１５を経由して伝送する（８０２）。さらに、サービスプロバイダシステムストレージ１２８は、リクエスト受信用ＳＣＳＩターゲット１２６に、当該データを伝送する（８０３）。
【００９５】
リクエスト受信用ＳＣＳＩターゲット１２６では、当該データ伝送を受けて、図２で示した処理と同様に、サーバアプリケーション部１１８の処理を呼び出す処理を行ない、レスポンス送信用ＳＣＳＩイニシエータ１２７に、レスポンスの伝送データが渡される。レスポンス送信用ＳＣＳＩイニシエータ１２７は、レスポンス送信エリア８１３にレスポンス伝送データを書き込む（８０４）。
【００９６】
レスポンス伝送データは、レプリケーション機能などにより、レスポンス送信エリア８１３から、ストレージネットワーク１１５を経由して、レスポンス受信エリア８１１に伝送される（８０５）。コンシューマストレージシステム１１３は、レスポンス受信エリア８１１に書き込まれた伝送データを、レスポンス受信用ＳＣＳＩターゲット１１２に渡す（８０６）。レスポンス受信用ＳＣＳＩターゲット１１２がレスポンス伝送データを受けたあとは、図２で示した処理と同様に、コンシューマアプリケーション部１０３に、レスポンスデータが渡される。
【００９７】
以上のように、ストレージシステムにデータを書き込み、伝送データを保持することにより、通信障害時の回復処理において、再送などの保証を行なうことが考えられる。すなわち、ＦＣのストレージネットワークやサーバに一時的な障害が発生しても、再起動時に、ストレージエリアに格納されたデータのレプリケーション状況を確認し、レプリケーションを確実に行なうことで、当該データ伝送を行ない、再送することができる。
【００９８】
再送による配送保証に限らず、同様に、通信処理における一般的な機能要件である、レスポンス受信待ちのタイマ監視、流量制御、順序制御、キューイング管理などを、コンシューマ通信プロキシ部１０５、サーバ通信プロキシ部１２０、ＨＢＡ制御部１１０、ＨＢＡ制御部１２５に、具備し、当該ストレージエリアに格納するデータを用いて、実現することが好ましい。
【００９９】
次に、ＩＰネットワーク通信とストレージネットワーク通信の両方を同時に並行して利用することにより、通信の安全性を確保する方法を示す。
図１に示したコンシューマアプリケーション部１０３からのアプリケーション通信要求が、安全性を必要することを指定された要求であった場合、コンシューマ通信プロキシ部１０５は、通信手段選定部１０７に問合せ、安全性確保通信のためにＩＰネットワーク１１４とストレージネットワーク１１５の両方が利用可能であるかを確認する。
【０１００】
コンシューマ通信プロキシ部１０５は、アプリケーション通信のリクエストメッセージのデータを編集し、ＩＰネットワーク１１４で伝送するデータと、ストレージネットワーク１１５で伝送するデータを作成する。なお、これらの伝送データは、どちらかにデータの改ざんがあった場合に、処理コストの小さいロジックにより検知できるようなデータを保持する。例えば、それぞれに互いの伝送データのダイジェストを持つようにする。
【０１０１】
コンシューマ通信プロキシ部１０５は、ＩＰネットワーク１１４とストレージネットワーク１１５を経由して、それぞれの伝送データを伝送する。サーバ通信プロキシ部１２０は、それぞれの伝送データを受信して編集し、それぞれのダイジェストを算出して、伝送データ中のダイジェストと比較しチェックをする。そして、サーバアプリケーション部１１８へのリクエストメッセージを作成し、サービス処理要求する。
【０１０２】
以上のように処理することにより、ＩＰネットワークに対する暗号化などの一般的な改ざん防止策だけでなく、システム間専用のストレージネットワークを経由した伝送データとを組み合わせたチェックを行なうことにより、通信の安全性をさらに高めることができる。
【０１０３】
次に、ＩＰネットワーク通信をストレージ通信に切り替えて代替する処理を説明する。
図１において以下の構成要素を持つ。通信制御状態検知部１０８は、ネットワークアダプタ制御部１０９と、ＨＢＡ制御部１１０とを利用して、ＩＰネットワーク１１４と、ストレージネットワーク１１５が、それぞれ利用可能な状態であるかを監視し、障害などの状態を検知する。通信手段選定部１０７は、通信制御状態検知部１０８で得られたそれぞれのネットワークの状態から、どの通信手段を利用するかを選定する。
【０１０４】
定期的に通信制御状態検知部１０８によりネットワーク状態情報を収集し、通信手段選定部１０７は、メモリ上の管理テーブルにそれらの情報を保持する。コンシューマ通信プロキシ部１０５からの問い合わせに対し、当該管理テーブルを用いて、通信手段選定部１０７は、選定ロジックにより、適当な通信手段を選定し、回答する。
【０１０５】
これにより、図２の通信手段選定２０３において、ＩＰネットワークの障害時にストレージネットワークを利用するよう選定することができ、ＩＰネットワークの代替としてストレージネットワークを利用することができる。同様に、通信制御状態検知部１２３、通信手段選定部１２２により、サービスプロバイダシステム１１６からのレスポンス送信で、ＩＰネットワークの代替としてストレージネットワークを選定する。
【０１０６】
また、本発明によれば、システム間において、次のようなサービスを行なうことができる。例えば、ストレージシステム間で渡した大量の管理会計データをもとに、サービスプロバイダシステム１１６側が当該データを解析し、サーバアプリケーション部１１８によりＳＯＡＰサービスとして、解析結果データを提供するサービスを行なう。この場合、本発明のストレージネットワーク１１５によるアプリケーション間通信を利用すれば、ＩＰネットワーク１１４を用いなくても、ストレージネットワーク１１５を接続するだけで、このようなサービス提供を実現することができる。
【０１０７】
また、本発明によれば、ビジネスモデル上、以下のような効果がある。
サービスプロバイダは、ＩＰネットワーク通信の予備経路を必要とせず、ストレージネットワークの経路を補完的に活用することにより、データ伝送の効率化を図るとともに、ＩＰネットワーク障害時もサービス処理を継続でき、低コストで信頼性を確保することができる。サービスコンシューマは、通信にかかるコストの低減が期待できる。また、プロバイダでのコスト低減から、コスト還元（サービス提供料金を低く設定）が期待できる。
エンドユーザは、コンシューマシステムのシステムランニングコストが低減されることから、コスト還元が期待できる。よって、これら三者のビジネスにとってそれぞれメリットのある好適な関係を維持できるビジネスモデルとなる。
【図面の簡単な説明】
【０１０８】
【図１】本発明の一実施の形態であるシステムの構成を示す概念図である。
【図２】ストレージネットワークによるアプリケーション間通信の処理フロー図である。
【図３】本発明の通信処理における通信プロトコル階層の概要図である。
【図４】添付データを通信する場合のシステムの構成を示す概念図である。
【図５】添付データを通信する場合の通信処理フロー図である。
【図６】通信メッセージ内容のデータ構成図である。
【図７】ストレージ通信デバイス定義のデータ構成図である。
【図８】ストレージシステムを介したデータの授受を行なうシステムの構成を示す概念図及びその通信処理フロー図である。
【符号の説明】
【０１０９】
１０１…コンシューマシステム、１０３…コンシューマアプリケーション部、１０５…コンシューマ通信プロキシ部、１０６…コンシューマアプリケーション通信−ストレージ通信プロトコル変換部、１０７…通信手段選定部、１０８…通信制御状態検知部、１１０…ＨＢＡ制御部、１１３…コンシューマシステムストレージ、１１４…ＩＰネットワーク、１１５…ストレージネットワーク、１１６…サービスプロバイダシステム、１１８…サーバアプリケーション部、１２０…サーバ通信プロキシ部、１２１…サーバアプリケーション通信−ストレージ通信プロトコル変換部、１２２…通信手段選定部、１２３…通信制御状態検知部、１２５…ＨＢＡ制御部、１２８…サービスプロバイダシステムストレージ。
【図１】
2005196531.tif 000003
【図２】
2005196531.tif 000004
【図３】
2005196531.tif 000005
【図４】
2005196531.tif 000006
【図５】
2005196531.tif 000007
【図６】
2005196531.tif 000008
【図７】
2005196531.tif 000009
【図８】
2005196531.tif 000010