(57)【要約】【課題】  通信によるXML Webサービスのパフォーマンスを向上させる。【解決手段】  ネットワークを介して利用可能なXML Webサービスに関する情報を通信する方法であって、XML Webサービスの呼び出し手順の情報を圧縮し、圧縮済みのXML情報のサイズが設定値以上か否かを判断して、設定値以上でないときは該XML情報を、設定値以上のときは該XML情報を分割して、それぞれ復元可能な送信先へ送信する。受信側では、受信した圧縮・分割済みのXML情報を結合後解凍することにより、XML Webサービス呼び出し手順の情報を復元する。【選択図】  図５
2006201843.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して利用可能なXML Webサービスに関する情報を通信する方法であって、
前記XML Webサービスの呼び出し手順の情報を圧縮する第１のステップと、
圧縮したXML情報のサイズが設定値以上か否かを判断する第２のステップと、
該XML情報のサイズが設定値以上のとき、該XML情報を分割する第３のステップと、
圧縮したXML情報のサイズが設定値以上でないときは該XML情報を、該XML情報のサイズが設定値以上のときは分割したXML情報を、それぞれ復元可能な送信先へ送信する第４のステップと、
を含むことを特徴とする通信方法。
【請求項２】
請求項１記載の通信方法において、
前記第１のステップで、前記XML Webサービス呼び出し手順の情報をXMLにエンコードして作成したSOAPエンベロープを圧縮し、前記第２のステップで、前記圧縮済みSOAPエンベロープのファイルサイズが設定値以上と判断したとき、前記第３のステップで、前記圧縮済みSOAPエンベロープのファイルを所定のサイズで分割し、前記第４のステップで、圧縮・分割済みのSOAPエンベロープファイルを同時送信する
ことを特徴とする通信方法。
【請求項３】
ネットワークを介して利用可能なXML Webサービスに関する情報を通信するための装置であって、
前記XML Webサービスを実行するために必要なファイル等の情報を圧縮、分割して前記ネットワーク上に送信する処理を行う送信処理手段と、
前記圧縮、分割された圧縮ファイル等の情報を受信して復元する処理を行う受信処理手段と
を備えたことを特徴とする通信装置。
【請求項４】
請求項３記載の通信装置において、前記送信処理手段は、前記XML Webサービス呼び出し手順の情報を圧縮し、圧縮したXML情報のサイズが設定値以上か否かを判断し、設定値以上でないときは該XML情報を、設定値以上のときは該XML情報を分割して、圧縮・分割済みのXML情報を、それぞれ復元可能な送信先へ送信する機能を有することを特徴とする通信装置。
【請求項５】
請求項４記載の通信装置において、前記受信処理手段は、受信した圧縮・分割済みのXML情報を結合後解凍することにより、前記XML Webサービス呼び出し手順の情報を復元する機能を有することを特徴とする通信装置。
【請求項６】
ネットワークを介して利用可能なXML Webサービスに関する情報を通信するための通信処理をコンピュータに実行させるプログラムであって、
前記XML Webサービスの呼び出し手順の情報をXMLにエンコードして作成したSOAPエンベロープを圧縮する機能と、
圧縮したSOAPエンベロープファイルのサイズが設定値以上か否かを判断する機能と、
前記圧縮済みSOAPエンベロープファイルのサイズが設定値以上のとき、該ファイルを所定のサイズで分割する機能と、
前記圧縮済みSOAPエンベロープファイルのサイズが設定値以上でないときは該圧縮済みSOAPエンベロープファイルを、設定値以上のときは分割したSOAPエンベロープファイルを、それぞれ送信する機能と
を含むことを特徴とするコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークにおいて通信要求を出した端末とXML Webサービス提供側との間で通信を効率よく行う方法及び装置と、そのような通信機能をコンピュータに実行させるためのプログラムに関する。
【背景技術】
【０００２】
企業等での業務用コンピュータシステムを構築するための手段として、嘗ては大型汎用機で全処理を行うホスト集中型システムが主流であったが、近年のパーソナルコンピュータ（ＰＣ）及びワークステーションの高性能・低価格化により、機能の一部をクライアントＰＣに持たせ、サーバと協調して稼働するクライアント・サーバ型システム（以下「C/Sシステム」という）が主流となってきた。
【０００３】
C/Sシステムは開放系技術を用いているため、各メーカ独自の仕様であったホスト集中型システムと比較して非常に少ない初期投資で構築できるという大きな利点を有し、ホスト集中型システムにとって代わると思われたが、クライアント側にもソフトウェアを導入しなければならない等の理由により、メンテナンス費用も含めた総費用（TCO）の点で、ホスト集中型とあまり変わらないことが判明してきた。
【０００４】
このC/SシステムのTCO増大という問題を解決するため、最近では、オペレーションシステム（ＯＳ）に標準で搭載されているインターネットブラウザを使用した３層モデルというものが提案された。これは、「ブラウザ」と称されるとおり閲覧する（ブラウズ）には適しているが、業務処理システムのように入力が主となるものには適しておらず、帳票印刷のような定型フォーマットに印刷する用途にも適していない。また、ネットワーク接続を前提としているため、インターネットに接続できない環境では使用できない等の理由により、企業情報システムとして、ホスト集中型システムやC/Sシステムを完全に置き換えるまでには至っていない。
【０００５】
今後は分散環境の発展に伴って、複数のサーバにまたがる分散処理に対し完全性を保証することが要求される。そのためには、通信エラーやサーバのダウン等により、いずれかの処理が実行できなかった場合に、代替処理ができるサーバを探して実行するか、或いは実行済みの処理（例えば、後述のXML Webサービス）に対してキャンセル処理を行うことで処理自体なかったことにするかという複雑な処理を行わなければならない。
【０００６】
ここで、XML Webサービスとは、コンピュータシステムで提供されるサービスであって、インターネット上で扱うデータを記述するための新しいデータフォーマット言語であるXML（eXtensible Markup Language）を用いて記述されるものである。XMLによれば、記述された情報に対して「タグ」という独自の意味づけを定義することができるため、プログラムからの操作が容易であり、XML WebサービスのLOGや動的画面を描画するための記述言語としてXMLが使用される。
【０００７】
従来の技術では、XML Webサービスは実用化されて間もないので、商用ベースでは殆ど実装されていないか、或いは実装されていたとしても実際にやり取りされるデータが少量であるため、XML Webサービス自体のパフォーマンス向上の必要性には迫られていない。しかしながら、XML Webサービスが本格的に実用化され、一般的に利用されるようになったときには、動画データや大量のファイルを提供するサービスも出現することが予想され、パフォーマンスの向上が要求される。
【０００８】
詳細には、上記のXML Webサービスでは、クライアント端末に表示する全画面構成情報をXML Webサービス提供側から取得するため、かなりの情報量になる。加えて、XML Webサービスに必要な情報は、XMLにて記述されたSOAP (Simple Object Access Protocol) エンベロープを、HTTP等のトランスポートプロトコルを用いて通信しており、その通信においてやり取りするXML文書は、生データをタグで囲んだ要素の集まりで構成されるので、生データと比較して、データ量が増大するという特徴がある。また、SOAPエンベロープをXMLパーサにて解析するために処理時間がかかる。これらの事情により、XML Webサービスでは、一般的な通信と比較して２〜１０倍の送信時間がかかるという問題もある。なお、SOAPエンベロープとは、Webサービスを提供するサーバ側と交換する情報を入れる封筒を意味し、封筒の中身はXMLを用いてテキストでエンコードされている。
【０００９】
また、複数のクライアント端末からの同時アクセスに対してXML Webサービスを提供するサーバ側では、スレッドの使い果たしによるサービス停止やサービスレベルの劣化等が生ずる恐れがある。すなわち、XML Webサービスを実行させる一般的なWebアプリケーションサーバでは、構造的な問題により、1つのリクエストは1つのスレッドによって実行されるので、XML Webサービスへのアクセスが集中し、その内容が大きい場合は、その処理だけでWebアプリケーションサーバの実行スレッドが全て占有されてしまう。より長大なデータの場合は、処理に時間がかかり、新しいリクエストを受け付けるための空きスレッドができなくなる。このため、巨大なデータの多重リクエストがあった場合には、無応答状態を引き起こす可能性がある。この問題は、処理の占有時間が長いことに起因している。
【００１０】
今後、XML Webサービスの発展に伴って扱うデータも増加していくと、同時接続数が多い場合、パフォーマンスの遅延及び通信帯域の圧迫が生ずるおそれがある。また、外部向けに公開するXML Webサービスに対するユーザからのアクセス数は、基本的に予測不可能であり、大容量ファイルを送るような場合のように、Webアプリケーションサーバ側で準備しているリクエスト数を超えてしまうと、サービスが提供できなくなるおそれがある。
【００１１】
これに対し、下記特許文献１では、次のようにデータを圧縮・展開する技術が開示されている。ある装置から他の装置へ情報を転送する際、転送元の装置において、転送される情報を所定のバイト毎のバイトデータ列に分割し、分割された情報をバイトデータ列毎に互いに並行に圧縮し、分割圧縮されたバイトデータ列毎に識別子を付加して混合し、１つの情報列として転送する。その後、転送先の装置において、転送されてきた情報列から、バイトデータ列毎の識別子に基づいて、バイトデータ列を分配し、転送されてきた情報をバイトデータ列毎に互いに並行に展開し、それにより、転送された情報を復元させる。すなわち、この技術は、分割→並行圧縮→一つにデータをまとめて送信、という順序で処理するものである。
【００１２】
【特許文献１】特開平１０−１５４０４４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
しかしながら、上記特許文献記載の技術では、転送される情報を分割してから並行圧縮するので、分割された情報のサイズに「ばらつき」が生じ、ネットワークで各サイズの情報を送信する際、送信に適したサイズを超える情報では送信効率が落ちることとなる。
【００１４】
上記のように、従来の技術では、XML Webサービスのデータ等の送受信を効率よく行うことができる手段は確立されていない。
【００１５】
本発明の目的は、通信によるXML Webサービスのパフォーマンスを向上させるという課題を解決することである。
【課題を解決するための手段】
【００１６】
本発明の通信方法は、ネットワークを介して利用可能なXML Webサービスに関する情報を通信する方法であって、XML Webサービスの呼び出し手順の情報を圧縮する第１のステップと、圧縮したXML情報のサイズが設定値以上か否かを判断する第２のステップと、該XML情報のサイズが設定値以上のとき、該XML情報を分割する第３のステップと、圧縮したXML情報のサイズが設定値以上でないときは該XML情報を、該XML情報のサイズが設定値以上のときは分割したXML情報を、それぞれ復元可能な送信先へ送信する第４のステップとを含むことを特徴とする。
【００１７】
この通信方法の実施態様では、第１のステップで、前記XML Webサービス呼び出し手順の情報をXMLにエンコードして作成したSOAPエンベロープを圧縮し、第２のステップで、前記圧縮済みSOAPエンベロープのファイルサイズが設定値以上と判断したとき、第３のステップで、前記圧縮済みSOAPエンベロープのファイルを所定のサイズで分割し、第４のステップで、圧縮・分割済みのSOAPエンベロープファイルを同時送信することを特徴とする。
【００１８】
本発明の通信装置は、ネットワークを介して利用可能なXML Webサービスに関する情報を通信するための装置であって、XML Webサービスを実行するために必要なファイル等の情報を圧縮、分割してネットワーク上に送信する処理を行う送信処理手段と、前記圧縮、分割された圧縮ファイル等の情報を受信して復元する処理を行う受信処理手段とを備えたことを特徴とする。
【００１９】
この通信装置の実施態様では、送信処理手段は、XML Webサービス呼び出し手順の情報を圧縮し、圧縮したXML情報のサイズが設定値以上か否かを判断し、設定値以上でないときは該XML情報を、設定値以上のときは該XML情報を分割して、圧縮・分割済みのXML情報を、それぞれ復元可能な送信先へ送信する機能を有することを特徴とする。また、受信処理手段は、受信した圧縮・分割済みのXML情報を結合後解凍することにより、XML Webサービス呼び出し手順の情報を復元する機能を有することを特徴とする。
【００２０】
更に、本発明は、ネットワークを介して利用可能なXML Webサービスに関する情報を通信するための通信処理をコンピュータに実行させるプログラムであって、XML Webサービスの呼び出し手順の情報をXMLにエンコードして作成したSOAPエンベロープを圧縮する機能と、圧縮したSOAPエンベロープファイルのサイズが設定値以上か否かを判断する機能と、圧縮済みSOAPエンベロープファイルのサイズが設定値以上のとき、該ファイルを所定のサイズで分割する機能と、圧縮済みSOAPエンベロープファイルのサイズが設定値以上でないときは該圧縮済みSOAPエンベロープファイルを、設定値以上のときは分割したSOAPエンベロープファイルをそれぞれ送信する機能とを含むことを特徴とするコンピュータ・プログラムを提供する。
【発明の効果】
【００２１】
本発明によれば、通信に用いられるSOAPエンベロープというXMLで記述されたXML Webサービスの呼出し手順を圧縮し、更に指定したサイズ以上であれば分割して送信することで、送信時間の短縮を図ることができる。また、XML Webサービスの提供において、送信ファイルを圧縮し、かつ所定のサイズ以下に分割することで、多数のリスエストを効率よく処理することが可能になり、XML Webサービスのレベルを向上させる。
【００２２】
より具体的には、SOAPエンベロープの情報自体は圧縮効果が大きい文字情報であることに着目して、ネットワークに送出する前に送信側でSOAPエンベロープを圧縮するものとし、指定したサイズで圧縮情報を分割して同時に送信する。一方、受信側では受信したデータを結合後、解凍することで、送信された情報を復元する。これにより、ネットワークにおいて通信要求を出した端末とXML Webサービス提供側との間で通信量が多くなっても送信を効率よく高速に行うことができ、通信によるXML Webサービスのパフォーマンスが大幅に向上する。
【発明を実施するための最良の形態】
【００２３】
図１は、本発明の技術を適用した複数XML Webサービスを提供するシステムの構成例を示す図である。
【００２４】
このシステムは、本サービスを利用するユーザ側のクライアント端末（ＰＣ）１からネットワーク（例えばインターネット）２を介して接続され、複数XML Webサービスを仲介するサーバ（以下「コーディネートサーバ」という）３と、サービス提供者側の複数のサーバ（以下「エージェントサーバ」という）４ａ，４ｂ，４ｃ・・・とで構成されている。
【００２５】
クライアント端末１はクライアントエンジン、各サーバはサーバエンジンをそれぞれ備える。この２種のエンジンは、コンピュータプログラムから成り、クライアント端末又は各サーバを構成するコンピュータに格納される。
【００２６】
プログラムは、種々の要素の組み合わせにより、ユーザに対してサービスを提供するものである。そこで、このような要素を用意して、各要素の基本的な機能を予め規定しておき、それらの要素を機能させる仕組み（エンジン）を配置することで、現状のプログラムと同等の動作を実現することが考えられる。
【００２７】
上記エンジン自体を製作するためのプログラミング言語は何でもよく、設定を定義するXMLデータをエンジンの言語に対応させるためにXSL (eXtensible Stylesheet Language) を使用し、プログラミング言語の使用の違いを吸収する。これにより、プログラミング言語ごとにエンジンとXSLのみを作成すれば、あらゆる環境でこの仕組みが実現できる。
【００２８】
サーバエンジンは、図２に示すように、クライアント端末１からの処理要求に応じて、サーバ上のWebサービス処理を実行し、結果を回答する。これにより、クライアント端末以外で行う処理をコンピュータ同士が自立的にやり取りして分散処理を実現するXML Webサービスを動的に生成し、複数のXML Webサービスに対して整合性を保った処理環境（トランザクション環境）を提供できる。
【００２９】
クライアントエンジンは、従来のWebアプリケーションでは不得意な、表現力に乏しいGUI環境を大きく改善するものである。詳細には、次のような機能を有する。
【００３０】
通常のクライアント画面はコンパイルしたもの、つまり静的な画面というのが一般的であるが、上記クライアントエンジンでは、画面構成情報からイベント処理等の全てをXMLと呼ばれるタグ言語にて記述し、サーバ側で実行されるXML WebサービスによりXMLで記述された画面構成情報をXML Webサービスから受け取り、その内容を解釈して画面上に動的に描画する。このため、非常に柔軟で表現力に富んだ画面になる一方で、そのやり取りされるXMLの情報量は相当のものになる。
【００３１】
また、クライアントエンジンでは、画面構成情報からイベント処理など全てをXMLと呼ばれるタグ言語にて記述し、その定義情報から、画面表示の各要素（部品）の表示位置（X,Y座標）や基礎的な表示状態などを動的に再現する。更に、その動作方法及び手順についても、XMLを用いた定義情報から取得して動作させる。これにより、プログラミング作業そのものが変革される。すなわち、プログラマは、プログラムコードを記述するのではなく、プログラムの見栄えや振る舞いに思考の中心を移すことができ、新しいプログラム制作が実現することとなる。
【００３２】
クライアントエンジンは、図３に示すように、コーディネートサーバ３から複数のクライアント端末１ａ，１ｂ，１ｃ・・・にそれぞれダウンロードされる。
【００３３】
従って、図４に示すように、コーディネートサーバ３と各種クライアント端末１ａ，１ｂ，１ｃ・・・との間では次の動作が行われる。
（１）コーディネートサーバ３からクライアントエンジン送信（配布）、
（２）クライアント端末１でクライアントアプリケーションの生成、
（３）クライアント端末１からＷｅｂサービス（予約など）要求、
（４）コーディネートサーバ３からエージェントサーバ４へＷｅｂサービス呼び出し及び実行、
（５）エージェントサーバ４からのＷｅｂサービス実行処理結果をクライアント側へ送信。
【００３４】
図１のシステムでは、ネットワークを介して通信するクライアント端末やXML Webサービスを提供するサーバの間の通信を高速化するための手段として、高速通信コンポーネント５が前記クライアント端末及び各サーバに設けられている。この高速通信コンポーネント５は、XML Webサービス実行のために必要なファイルやデータを圧縮、分割して送信する機能と、他から受信した分割ファイル等を結合、解凍してXML Webサービス処理を実行する機能とを備えたコンピュータ・プログラムで構成される。これを組み込んだクライアント端末又は各サーバは、本発明の通信方法を実施するための装置となる。
【００３５】
各サーバ又はクライアント端末は、高速通信コンポーネント５により、図５に示すように、(1) XML Webサービス呼び出し手順を圧縮し、(2) 分割し、(3) 分割した個々の情報を同時にネットワークを介して送信する。また、他のサーバからネットワークを介して、(4) 分割された情報を受信すると、(5) それらを結合し、(6) 解凍して、XML Webサービス処理を実行する。
【００３６】
この高速通信コンポーネント５によれば、多数のリスエストを効率よく処理することができ、XML Webサービスのレベル向上に大きく寄与する。
【００３７】
図６は、高速通信コンポーネント５を格納した各サーバ又はクライアント端末（以下、送信元となるサーバ等を「送信元コンピュータ」、送信先のサーバ等を「送信先コンピュータ」という）で実行される通信処理の手順を示すフローチャートである。
【００３８】
初めに、送信元コンピュータでは、Webサービス呼び出し手順を起動し（ＳＴ１）、その情報をXMLにエンコードしてSOAPエンベロープを作成する（ＳＴ２）。なお、Webサービス呼び出し手順とは、後述のようにXML Webサービス処理を実行するための処理手順を記述した情報である。
【００３９】
次に、SOAPエンベロープを圧縮する（ＳＴ３）。例えば、JAVA（登録商標）を使用する場合は、標準ライブラリに含まれているZIP圧縮を使用して圧縮する。そして、圧縮済みSOAPエンベロープのファイルサイズを取得し（ＳＴ４）、取得したファイルサイズが予め定めた設定値以上か否かを判定する（ＳＴ５）。その判定結果が“Ｎｏ”であれば、圧縮済みSOAPエンベロープのデータファイルを、HTTP等のトランスポートプロトコルを使用して、送信先コンピュータ宛に送信する（ＳＴ６）。
【００４０】
送信先コンピュータでは、HTTP等のトランスポートプロトコルにて送信元コンピュータから送信された圧縮済みSOAPエンベロープファイルを受信すると（ＳＴ７）、送信元コンピュータにて圧縮に用いたものと同一の圧縮ロジックを使用して解凍し（ＳＴ８）、解凍済みのSOAPエンベロープファイルをデコードする（ＳＴ９）。このファイル情報に基づき、XML Webサービスを実行する（ＳＴ１０）。
【００４１】
一方、送信元コンピュータでは、上記ＳＴ５の判定で“Ｙｅｓ”（ファイルサイズが設定値以上）であれば、圧縮済みSOAPエンベロープのファイルを分割する（ＳＴ１１）。分割の方式は、トランスポートプロトコルにHTTPを使用する場合は、Rangeヘッダ等を用いてWebサービスの呼び出し手順を複数の呼び出し手順に分割する。もしHTTPを使用するならばHTTPヘッダ部分を加味し、携帯電話のパケットサイズである128バイトで分割する。分割後の個々のファイル情報には、順番を付与する（ＳＴ１２）。そして、圧縮・分割済みのSOAPエンベロープファイルを、HTTP等のトランスポートプロトコルを使用して送信先コンピュータに同時送信する（ＳＴ１３）。なお、セキュリティについては、SSL（HTTPS）或いは既存の暗号化プロトコルを使用することで、確保できる。
【００４２】
送信先コンピュータでは、HTTP等のトランスポートプロトコル経由にて送信元コンピュータから送信された分割・圧縮済みSOAPエンベロープファイルを受信すると（ＳＴ１４）、これら分割済みSOAPエンベロープを各々付与された番号に応じて結合する（ＳＴ１５）。このとき、番号が付いていないものについては、未分割と判断して処理する。
【００４３】
この後は、ファイルサイズが予め定めた設定値以上でない場合（未分割）と同様に、送信元コンピュータにて圧縮に用いたものと同一の圧縮ロジックを使用して解凍し（ＳＴ８）、解凍済みのSOAPエンベロープファイルをデコードする（ＳＴ９）。このファイル情報に基づき、XML Webサービスを実行する（ＳＴ１０）。
【００４４】
次に、上記の高速通信コンポーネント５によるデータ圧縮、分割、送受信、結合及び解凍の各処理について詳細に説明する。
【００４５】
図７は、送信元コンピュータにてWebサービス呼び出し手順をXMLにエンコードして作成されるSOAPエンベロープの記述例を示す。図において、各行の文字列は、以下のような意味を有する。
【００４６】
１行目の <SOAP-ENV:Envelope は、SOAPエンベロープの始まりのタグ、
２行目のxmlns:SOAP-ENV=http://schemas.xmlsoap.prg/soap/envelope/" は、XML名前空間名の指定（XMLタグ要素を定義するときは必須）、３行目の SOAP-ENV:encodingStyle="http://schemas.xmlsoap.prg/soap/encoding/"> は、
値をどのように文字列で表示するか（シリアライズ）の方法の指定、最後の </SOAP-ENV:Envelope> はSOAPエンベロープの終わりのタグである。
【００４７】
SOAPエンベロープの中身（内容）は、SOAPヘッダとSOAPボディとで構成され、SOAPヘッダには認証情報やルーティング情報が記述され、SOAPボティには交換する情報が入っている。
【００４８】
以下、説明のため、SOAPエンベロープ（Ａ）はSOAPヘッダ(B)とSOAPボディ(C)とから成るものとする。
【００４９】
このSOAPエンベロープ（Ａ）を圧縮するために、次の方法が用いられる。
【００５０】
例えば、“AAAAAAAAAABBBBBBBBBBCCCCCCCCCC”という30個の文字列がある場合、これを“A10B10C10 ”のようにAが10個、Bが10個、Cが10個と記述して並べることにより、9個の文字列に変更することができる。このとき、データ量は約1/3になる。
【００５１】
図８に示すように、こうして圧縮されたSOAPヘッダ(B’)とSOAPボディ(C’)とで、圧縮されたSOAPエンベロープ（Ａ’）が構成される。
【００５２】
次に、圧縮済みSOAPエンベロープのファイルサイズは、例えばHTTPを使用する場合、図９に示すようにHTTPヘッダのContents-length = xxという値で得られる。この値が、予め設定したファイルサイズ（例えば、最大で４０９６バイト）以上であれば、前述のように圧縮済みSOAPエンベロープを適宜のサイズ（例えば、携帯電話のパケットサイズである128バイト）で分割する。具体的には、HTTPをトランスポートプロトコルに使用する場合、Rangeヘッダ等を用いて、Webサービスの呼び出し手順を複数の呼出し手順に分割する。
【００５３】
例えば、図１０に示すように、圧縮されたSOAPエンベロープ（Ａ’）は、取得したContents-lengthの範囲内で、リクエスト毎に、次のようなRange （バイトの範囲）のヘッダを付加した圧縮済みSOAPエンベロープに分割される。
【００５４】
0〜127バイトのRange：圧縮済みSOAPエンベロープ（Ａ’１）、
128〜255のRange：圧縮済みSOAPエンベロープ（Ａ’２）、 
・・・
xxx〜(Contents-length)のRange：圧縮済みSOAPエンベロープ（Ａ’x）。
【００５５】
一方、送信先コンピュータでは、HTTP等のトランスポートプロトコル経由で受け取った圧縮・分割済みSOAPエンベロープを各々に付与された番号に応じて結合するため、上記のように送信元コンピュータにて付加されたRangeヘッダのバイト数を参照して、複数のSOAPエンベロープファイルをバイト数が昇順になるように自動的に結合する。これにより、図１１に示すように、元の圧縮されたSOAPエンベロープ（Ａ’）が１つのファイルとして復元される。この結合済みSOAPエンベロープ（Ａ’）を、送信元コンピュータでの圧縮と同一の圧縮ロジックを使用して解凍する。すなわち、図８の圧縮と逆の処理を行い、元のデータを復元する。 復元したSOAPエンベロープ(Ａ)は、SOAPヘッダ(B)と SOAPボディ(C)とから成る。
【００５６】
最後に、解凍済みのSOAPエンベロープ(Ａ)をデコードする。すなわち、SOAPヘッダ(B)を外し、実際の要求内容であるSOAPボディ(C)を取り出す（図１２）。そして、この情報（Webサービス呼び出し手順）により、下記の例のようなXML Webサービスを実行する。
【００５７】
図１のシステムは、例えば、一般ユーザが旅行や出張に必要な手配をする場合、図１３に示すように、ユーザ自身が携帯電話やパソコンなどの端末１１からインターネット１２を介して、航空会社や鉄道などの交通機関、宿泊したいホテルや旅館及び観光地の施設などのWebサイト１３ａ，１３ｂ，１３ｃにアクセスして各々予約をするといった手間を解消するため、図１４に示すように、上記サーバエンジンを備えたコーディネートサーバ３が旅行代理店の役割を果たすシステムとして利用できる。この場合、各Webサイト１３ａ，１３ｂ，１３ｃを運営する事業者に、図１の各エージェントサーバ４ａ，４ｂ，４ｃが設置される。
【００５８】
旅行代理店としてのXML Webサービスは、複数の異なるXML Webサービスを仲介するものと考えられる。この場合、システムは、図１５に示すように、ユーザ端末１１からの予約リクエストに応じて予約サービスを仲介するコーディネートサーバ３と、ホテル予約、レンタカー予約、航空券予約、その他の予約サービスを提供するエージェントサーバ４ａ，４ｂ，４ｃ，４ｄと、ユーザ端末１１とコーディネートサーバ３の間及びコーディネートサーバ３と各エージェントサーバ４ａ，４ｂ，４ｃ，４ｄの間をそれぞれ接続するインターネット（図示省略）とで構成される。コーディネートサーバ３は、変更内容をXMLで書き込むためのメモリ３１を備えている。
【００５９】
このシステムでは、コーディネートサーバ３は、ユーザ端末１１から予約リクエストを受けると、それに応じた予約サービスを実行するエージェントサーバ４ａ，４ｂ，４ｃ又は４ｄへ予約リクエストを送り、そのエージェントサーバから予約ＯＫの返答を受けると、返答をユーザ端末１１へ送る。ユーザ端末１１からの予約リクエストに対し、その要求に係る全ての予約処理が完了するまで予約リクエストを受けないようにサーバをロックすることとなる。しかしながら、旅行代理店としてのXML Webサービスでは、従来のトランザクション（コンピュータでの処理）のように全ての処理が完了するまでサーバのコンピュータ資源をロックすることは困難である。
【００６０】
そこで、いずれかの予約処理の結果が“NG”の場合（例えば、ユーザの希望する交通機関が満席である場合）は、代替策を検索するとしても、以下のキャンセル処理を行うことで処理自体をなかったことにすれば、トランザクションの完全性を保証できる。すなわち、図１６に示すように、コーディネートサーバ３は、ユーザ端末１１からの予約リクエストにより旅行代理店XML Webサービスを起動し、予約リクエストをエージェントサーバ４ａ，４ｂ，４ｃ，４ｄに送ることで、予約に必要なXML Webサービスを呼び出す。その際、キャンセル処理のための戻しロジック（後述の「戻し」のSQL）を自動生成し、LOGとしてメモリ３１に保管しておく。そして、各エージェントサーバでの実行結果を集計、判定し、全ての予約処理がＯＫ（成功）ならば、トランザクションは終了し、ＯＫの返答をユーザ端末１１へ送る。他方、いずれかの処理がＮＧ（不成功）ならば、XML Webサービス・キャンセル処理を行い、成功したXML Webサービスに対して実行しなかったことにする。そして、予約不成功の返答をユーザ端末１１に送る。
【００６１】
図１７は、上記のコーディネートサーバとエージェントサーバによる複数XML Webサービスの処理手順を示すフローチャートである。
【００６２】
初めにコーディネートサーバは、予約リクエストの有無をチェックし（ＳＴ２１）、予約リクエストがあるとき、XML Webサービスを呼び出し、その予約リクエストに応じたサービスの種類（範囲）を確定する（ＳＴ２２）。同時に、「戻し」のSQLメッセージ又はパラメータを自動生成して、メモリ３１に保存する（ＳＴ２３）。
【００６３】
例えば、SQL (Structured Query Language) メッセージの場合は、insert文ならdelete文を、update文なら元のデータを戻すため、現在のデータをselectで取得し、「戻し」のためのupdate文を自動生成してLOGとして格納する。「戻し」のSQLについては、後で具体例を説明する。
【００６４】
他方、パラメータ受け渡しの場合は、実行したXML Webサービスからキャンセル処理のための「戻し」パラメータを取得してLOGとして格納する。
【００６５】
次に、上記で確定した範囲のXML Webサービスを呼び出す（ＳＴ２４）。すなわち、当該XML Webサービスを実行するエージェントサーバに予約リクエストを送信する。
【００６６】
各エージェントサーバでは、受信した予約リクエストに応じて、所定のXML Webサービス（予約）処理を実行し（ＳＴ３１）、その処理結果をコーディネートサーバに送信する（ＳＴ３２）。
【００６７】
コーディネートサーバでは、受信したサービス処理結果をメモリに格納し（ＳＴ２５）、処理結果が全てＯＫか否かを判定する（ＳＴ２６）。その結果“Ｙｅｓ”であれば、予約リクエストを送ったユーザ端末に「予約成功」の結果通知を送信して（ＳＴ２７）、サービス終了となる。
【００６８】
一方、ＳＴ２６の判定結果が“Ｎｏ”、すなわち複数XML WebサービスのどれかがＮＧの場合は、代替案の有無すなわち他のサービスの予約が可能かどうかをチェックし（ＳＴ２８）、“Ｙｅｓ”であれば、代替案のXML Webサービスを呼び出す（ＳＴ２９）。すなわち、そのXML Webサービスを実行するエージェントサーバに予約リクエストを送信する。
【００６９】
当該エージェントサーバでは、受信した予約リクエストに応じて、その代替案サービス（予約）処理を実行し（ＳＴ３３）、その処理結果をコーディネートサーバに送信する（ＳＴ３４）。
【００７０】
コーディネートサーバでは、受信した代替案サービス処理結果をメモリに格納し（ＳＴ２５）、以下の手順を繰り返す。上記ＳＴ２８の判定で“Ｎｏ”、すなわち代替案がない場合は、メモリ３１に格納した「戻し」のSQLメッセージ又はパラメータを使用して、成功したXML Webサービスに対して実行しなかったことにするキャンセル呼出し指令を各エージェントサーバに送る（ＳＴ３０）。
【００７１】
各エージェントサーバでは、キャンセル呼出し指令に応じて、XML Webサービス（キャンセル）処理を実行し（ＳＴ３５）、その処理結果をコーディネートサーバに送信する（ＳＴ３６）。
【００７２】
コーディネートサーバでは、予約リクエストを送ったユーザ端末に「予約不成功」の結果通知を送信して（ＳＴ２７）、サービス終了となる。
【００７３】
ここで、上記のようにサーバで自動生成されるSQLについて説明する。
【００７４】
(1) レコードを追加するSQL（INSERT）：
例えば、“INSERT 項目名Ａ（ユニークキー），項目名Ｂ，項目名Ｃ， 項目名Ｄ FROM TABLE名”ならば、戻しのSQLとして、
DELETE FROM TABLE名WHERE 項目名A ＝ '削除キー '
というSQLを自動生成する。キャンセル処理の際には、このSQLを実行する。
【００７５】
(2) レコードを変更するSQL（UPDATE）：
例えば、“UPDATE TABLE名 SET 項目名B=変更値 , 項目名C=変更値 , 項目名D=変更値 WHERE 項目名A=変更キー”のように、Ｂ，Ｃ，Ｄを変更するSQLを発行しようとする際には、
SELECT * FROM TABLE名WHERE 項目名 =変更キー
というSQLを発行して、事前に変更前の項目情報を取得する。そして、
“UPDATE TABLE名 SET 項目名B=変更値 , 項目名C=変更値 , 項目名D=変更値 WHERE 項目名A=変更キー”
というSQLを自動生成する。「戻し」が発生した場合は、このSQLを実行する。
【００７６】
一例として、新規にホテルを予約したい場合を考える。その場合のSQLは、
“INSERT 予約番号，名前，宿泊日，泊数，部屋タイプ， FROM 予約テーブル”となる。
【００７７】
この予約SQLの発行と同時に、予約自体を取り消す戻しSQLとして、
“DELETE FROM予約テーブルWHERE予約番号＝予約番号”
を自動生成してLOGに格納する。
【００７８】
その後、ホテルでの予約内容の変更が発生した場合は、
“SELECT * FROM予約テーブルWHERE予約番号＝予約番号”
というSQLを発行して、事前に変更前の項目情報を取得しておく。そして、
“UPDATE 予約テーブル SET 名前=名前(変更前) , 宿泊日=宿泊日(変更前) , 泊数=泊数(変更前) , 部屋タイプ=部屋タイプ(変更前) WHERE 予約番号=予約番号（ユニークキー）” 
というSQLを発行して、LOGに格納する。
【００７９】
「戻し」が発生した場合は、上記SQLを実行することで、更新前のデータに戻すことが可能になる。
【００８０】
上記のシステムによれば、旅行代理店にコーディネートサーバを設置し、予約を受け付けるホテル、鉄道会社、航空会社等に各エージェントサーバをそれぞれ設置することにより、旅行代理店からホテルや各交通機関の予約をとるサービスが提供される。
【００８１】
以上、本発明の実施の形態として、旅行代理店としてのサービスを行うシステムについて説明したが、本発明はこれに限らず、XML Webサービスを提供するシステムに適用できる。
【図面の簡単な説明】
【００８２】
【図１】本発明の適用例としてXML Webサービス提供システムを示す図。
【図２】図１のシステムにおいてクライアント端末からの処理要求に応じてWebサービス処理を実行し、結果を回答するサーバエンジンを示す図。
【図３】図１のシステムを構成するコーディネートサーバから各クライアント端末にクライアントエンジンがダウンロードされることを示す図。
【図４】ネットワークを介して通信する各クライアント端末とコーディネートサーバとを示す図。
【図５】高速通信コンポーネントによるデータ圧縮・分割・送受信・結合・解凍の処理を示す図。
【図６】高速通信コンポーネントを備えたサーバ等で実行される通信処理の手順を示すフローチャート。
【図７】Webサービス呼び出し手順をXMLにエンコードして作成されるSOAPエンベロープの記述例を示す図。
【図８】圧縮されたSOAPエンベロープ（Ａ’）の構成を示す図。
【図９】圧縮済みSOAPエンベロープ（Ａ’）のHTTPヘッダを示す図。
【図１０】圧縮済みSOAPエンベロープ（Ａ’）の分割を示す図。
【図１１】解凍により圧縮済みSOAPエンベロープ（Ａ’）から元のSOAPエンベロープ(Ａ)が復元されることを示す図。
【図１２】解凍済みのSOAPエンベロープ(Ａ)をデコードすることで、SOAPヘッダ(B)を外して取り出されるSOAPボディ(C)を示す図。
【図１３】ユーザ端末からインターネットを介して各Webサイトにアクセスし各々予約をする場合の説明図。
【図１４】サーバエンジンを備えたコーディネートサーバが旅行代理店の役割を果たすシステムの構成図。
【図１５】旅行代理店として複数の異なるXML Webサービスを仲介するシステムの構成図。
【図１６】予約処理の結果によりキャンセル処理を行うシステムの構成図。
【図１７】コーディネートサーバとエージェントサーバによるXML Webサービスの処理手順を示すフローチャート。
【符号の説明】
【００８３】
１…クライアント端末、２…ネットワーク、３…コーディネートサーバ、４ａ，４ｂ，４ｃ，４ｄ…エージェントサーバ、５…高速通信コンポーネント、１１…ユーザ端末、１２…インターネット、１３ａ，１３ｂ，１３ｃ…Webサイト。
【図１】
2006201843.tif 000003
【図２】
2006201843.tif 000004
【図３】
2006201843.tif 000005
【図４】
2006201843.tif 000006
【図５】
2006201843.tif 000007
【図６】
2006201843.tif 000008
【図７】
2006201843.tif 000009
【図８】
2006201843.tif 000010
【図９】
2006201843.tif 000011
【図１０】
2006201843.tif 000012
【図１１】
2006201843.tif 000013
【図１２】
2006201843.tif 000014
【図１３】
2006201843.tif 000015
【図１４】
2006201843.tif 000016
【図１５】
2006201843.tif 000017
【図１６】
2006201843.tif 000018
【図１７】
2006201843.tif 000019