(57)【要約】【課題】クライアントの処理能力やメモリに対する負担の軽いＳＯＡＰメッセージ送受信のための技術を提供し、かかる能力に制限のある端末装置をクライアントとするのに適したウェブサービスのシステムを実現する。【解決手段】クライアント２００において、メッセージの暗号化や署名といった加工を当該メッセージの断片ごとに順次行ってボディ部分を生成し、この加工において得られた情報を用いてヘッダ部分を生成し、これらのボディ部分およびヘッダ部分を結合してＤＯＭを用いることなくＳＯＡＰメッセージを作成する。また、受信したＳＯＡＰメッセージをパースしながらヘッダ情報を取得し、このヘッダ情報に基づいてボディ部分の復号や署名の検証を順次行っていくことにより、ＤＯＭを用いることなくＳＯＡＰメッセージを解読する。【選択図】        図４
2004274355.tif 000002
【特許請求の範囲】
【請求項１】
所定の記憶手段からメッセージ本体を所定の断片ごとに読み出す第１のステップと、
読み出した前記断片に順次加工処理を行ってメッセージのボディ部分を生成し、所定の記憶手段の作業領域に保持すると共に当該加工処理に関する情報を取得する第２のステップと、
取得した前記加工処理に関する情報を含むメッセージのヘッダ部分を生成し、所定の記憶手段の作業領域に保持する第３のステップと、
前記記憶手段の作業領域から前記ボディ部分およびヘッダ部分を読み出して結合しＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）メッセージを構築する第４のステップと
を含むことを特徴とするＳＯＡＰメッセージ作成方法。
【請求項２】
前記第２のステップでは、前記メッセージの断片を順次暗号化し、前記ボディ部分における暗号化を行った箇所を参照するための参照ＩＤと暗号化方法に関する情報とを取得することを特徴とする請求項１に記載のＳＯＡＰメッセージ作成方法。
【請求項３】
前記第２のステップでは、処理対象である前記メッセージの断片に対して署名を行い、前記ボディ部分における署名を行った箇所を参照するための参照ＩＤと署名方法に関する情報を取得することを特徴とする請求項１に記載のＳＯＡＰメッセージ作成方法。
【請求項４】
前記第２のステップでは、前記メッセージの断片に対して複数回の加工を行い、各加工処理に関する情報を取得することを特徴とする請求項１に記載のＳＯＡＰメッセージ作成方法。
【請求項５】
ＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）メッセージをパースしながら、当該ＳＯＡＰメッセージのヘッダ部分からボディ部分の加工処理に関する情報を抽出して所定の記憶手段の作業領域に格納する第１のステップと、
前記ＳＯＡＰメッセージをパースしながら、前記記憶手段の作業領域に格納された情報に基づいて、前記ボディ部分の所定の箇所を順次加工する第２のステップと
を含むことを特徴とするＳＯＡＰメッセージ処理方法。
【請求項６】
前記第１のステップでは、前記ボディ部分の暗号化された箇所および復号化方法を含む復号化情報を抽出し、
前記第２のステップでは、抽出された前記復号化情報にて特定される前記ボディ部分の箇所に対して、当該復号化情報に基づいて復号化処理を行うことを特徴とする請求項５に記載のＳＯＡＰメッセージ処理方法。
【請求項７】
前記第１のステップでは、前記ボディ部分の署名された箇所および署名方法を含む検証情報を抽出し、
前記第２のステップでは、抽出された前記検証情報にて特定される前記ボディ部分の箇所に対して、前記署名の検証を行うことを特徴とする請求項５に記載のＳＯＡＰメッセージ処理方法。
【請求項８】
前記ボディ部分における前記第２のステップにより加工された前記所定の箇所に対して、独立したパーサを用いてパースし、前記第１、第２のステップを再帰的に実行することを特徴とする請求項５に記載のＳＯＡＰメッセージ処理方法。
【請求項９】
前記第２のステップは、
前記ボディ部分における前記所定の箇所の加工を開始する際に前記独立したパーサを作成するステップと、
前記所定の箇所を加工するステップと、
前記独立したパーサを用いて加工後の前記所定の箇所をパースするステップとを含むことを特徴とする請求項８に記載のＳＯＡＰメッセージ処理方法。
【請求項１０】
ヘッダ部分とボディ部分とを備え、当該ボディ部分に所定の処理の処理対象が設定され、当該ヘッダ部分に当該処理に関する情報および当該処理対象を指示する情報が記述される記述仕様のデータファイルを処理するデータ処理方法であって、
前記データファイルの元データを格納した所定の記憶手段から当該元データを所定の断片ごとに読み出す第１のステップと、
読み出した前記断片にストリーミング処理による加工処理を行って前記データファイルのボディ部分を生成し、所定の記憶手段の作業領域に保持すると共に当該加工処理に関する情報を取得する第２のステップと、
取得した前記加工処理に関する情報を含む前記データファイルのヘッダ部分を生成し、所定の記憶手段の作業領域に保持する第３のステップと、
前記記憶手段の作業領域から前記ボディ部分およびヘッダ部分を読み出して結合し前記データファイルを構築する第４のステップと
を含むことを特徴とする情報処理方法。
【請求項１１】
ヘッダ部分とボディ部分とを備え、当該ボディ部分に所定の処理の処理対象が設定され、当該ヘッダ部分に当該処理に関する情報および当該処理対象を指示する情報が記述される記述仕様のデータファイルを処理するデータ処理方法であって、
前記データファイルを第１のパーサにてパースしながら、当該データファイルのヘッダ部分からボディ部分の加工処理に関する情報を抽出して所定の記憶手段の作業領域に格納する第１のステップと、
前記データファイルを前記第１のパーサにてパースしながら、前記記憶手段の作業領域に格納された情報に基づいて、前記ボディ部分の所定の箇所をストリーミング処理にて加工する第２のステップとを含み、
前記第２のステップは、
前記ボディ部分における前記所定の箇所の加工を開始する際に前記第１のパーサとは独立の第２のパーサを作成するステップと、
前記所定の箇所を加工するステップと、
前記第２のパーサを用いて加工後の前記所定の箇所をパースするステップとを含むことを特徴とする情報処理方法。
【請求項１２】
ＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）メッセージのボディ部分に対して所定の加工を行うと共に当該加工に関する情報を取得する加工処理部と、
前記ＳＯＡＰメッセージを所定の断片ごとに読み込み、予め定められた前記メッセージの加工に関する設定に基づき、前記メッセージの所定の断片を前記加工処理部に渡すメッセージ構築制御部と、
前記加工処理部により取得された前記加工に関する情報を含む前記ＳＯＡＰメッセージのヘッダ部分を生成するヘッダ生成部と、
前記加工処理部により加工されたボディ部分と前記ヘッダ生成部により生成されたヘッダ部分とを結合してＳＯＡＰメッセージを構築するメッセージ組立部とを備えることを特徴とする情報処理装置。
【請求項１３】
前記加工処理部は、前記メッセージの断片を順次暗号化し、前記ボディ部分における暗号化を行った箇所を参照するための参照ＩＤと暗号化方法に関する情報とを取得することを特徴とする請求項１２に記載の情報処理装置。
【請求項１４】
前記加工処理部は、処理対象である前記メッセージの断片に対して署名を行い、前記ボディ部分における署名を行った箇所を参照するための参照ＩＤと署名方法に関する情報を取得することを特徴とする請求項１２に記載の情報処理装置。
【請求項１５】
ＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）メッセージをパースしてヘッダ部分とボディ部分とを検出し、当該ボディ部分における加工対象をさらに検出する解読制御部と、
前記解読制御部にて検出された前記ヘッダ部分から前記ボディ部分の加工処理に関する情報を抽出するヘッダ処理部と、
前記ヘッダ処理部にて抽出された情報に基づいて、前記ボディ部分における前記加工対象に対して加工処理を行う加工処理部とを備え、
前記解読制御部は、前記ＳＯＡＰメッセージを先頭から順にパースし、検出した前記ヘッダ部分を前記ヘッダ処理部へ渡し、さらに検出した前記ボディ部分における前記加工対象を前記加工処理部に渡し、
前記ヘッダ処理部および前記加工処理部は、前記解読制御部から受け取った前記ＳＯＡＰメッセージの部分を順次処理することを特徴とする情報処理装置。
【請求項１６】
前記加工処理部は、前記ボディ部分の前記加工対象に対する加工を開始する際に前記解読制御部とは独立のパーサを作成し、加工後の当該加工対象を当該独立のパーサを用いてさらにパースすることを特徴とする請求項１５に記載の情報処理装置。
【請求項１７】
前記ヘッダ処理部は、前記ボディ部分の暗号化された箇所および復号化方法を含む復号化情報を抽出し、
前記加工処理部は、前記ヘッダ処理部により抽出された前記復号化情報にて特定される前記ボディ部分の箇所に対して、当該復号化情報に基づいて復号化処理を行うことを特徴とする請求項１６に記載の情報処理装置。
【請求項１８】
前記ヘッダ処理部は、前記ボディ部分の署名された箇所、署名方法および署名値を含む検証情報を抽出すると共に、当該署名値を用いた署名の検証を行い、
前記加工処理部は、抽出された前記検証情報にて特定される前記ボディ部分の箇所に対して、前記検証情報に基づいて計算されるダイジェスト値を用いた署名の検証を行うことを特徴とする請求項１５に記載の情報処理装置。
【請求項１９】
コンピュータを制御してデータ処理を行うプログラムであって、
ヘッダ部分とボディ部分とを備え、当該ボディ部分に所定の処理の処理対象が設定され、当該ヘッダ部分に当該処理に関する情報および当該処理対象を指示する情報が記述される記述仕様のデータファイルの元データを格納した所定の記憶手段から当該元データを所定の断片ごとに読み出す第１の処理と、
読み出した前記断片をストリーミング処理にて加工して前記データファイルのボディ部分を生成し、所定の記憶手段の作業領域に保持すると共に当該加工処理に関する情報を取得する第２の処理と、
取得した前記加工処理に関する情報を含む前記データファイルのヘッダ部分を生成し、所定の記憶手段の作業領域に保持する第３の処理と、
前記記憶手段の作業領域から前記ボディ部分およびヘッダ部分を読み出して結合し前記データファイルを構築する第４の処理と
を前記コンピュータに実行させることを特徴とするプログラム。
【請求項２０】
処理対象である前記データファイルがＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）メッセージであることを特徴とする請求項１９に記載のプログラム。
【請求項２１】
コンピュータを制御してデータ処理を行うプログラムであって、
ヘッダ部分とボディ部分とを備え、当該ボディ部分に所定の処理の処理対象が設定され、当該ヘッダ部分に当該処理に関する情報および当該処理対象を指示する情報が記述される記述仕様のデータファイルを第１のパーサにてパースしながら、当該データファイルのヘッダ部分からボディ部分の加工処理に関する情報を抽出して所定の記憶手段の作業領域に格納する第１の処理と、
前記第１のパーサとは独立の第２のパーサを作成する第２の処理と、
前記データファイルを前記第１のパーサにてパースしながら、前記記憶手段の作業領域に格納された情報に基づいて、前記ボディ部分の所定の箇所をストリーミング処理にて加工する第２の処理と、
前記第２のパーサを用いて加工後の前記所定の箇所をパースするステップと
を前記コンピュータに実行させることを特徴とするプログラム。
【請求項２２】
請求項１９から請求項２１のいずれかに記載のプログラムを、コンピュータが読み取り可能に記録した記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、データファイルの加工方法に関し、特にウェブサービスにおいて用いられるＳＯＡＰメッセージ等のＸＭＬ文書の加工方法に関する。
【０００２】
【従来の技術】
今日、インターネットに代表されるコンピュータネットワークの普及により、ネットワークを介して様々なサービスが提供されている。コンピュータ間の通信に関する新しいフレームワークとして、近年ウェブサービスが普及しつつある。ウェブサービスとは、ＷＷＷ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）の基盤となるＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）などの各種プロトコルを介して、人間が介入せずに、サービスが動的にデータをやり取りする仕組みである。各サービス間の情報の授受は、ＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）メッセージを用いて行なわれる。ウェブサービスの普及により、クライアントは複数の異なる情報を、自動的に得ることができるようになった。
【０００３】
ウェブサービスの運用上、メッセージの改ざんや偽名などを防ぐために、セキュリティを確保することは重要なことである。そこで近年、ＳＯＡＰメッセージ上に暗号化や署名などのセキュリティ技術を記述する、ウェブサービスセキュリティの仕様が提案されている（例えば、非特許文献１参照）。
【０００４】
一方、ネットワークに接続する端末装置の種類も、パーソナルコンピュータやワークステーションのような高い処理能力を有するコンピュータ装置から、携帯電話、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔｓ）といった携帯性や小型化を重視してメモリの記憶容量や処理能力が制限されるものまで様々である。
現在の携帯電話端末では、ＨＴＴＰをベースにした通信でウェブページを閲覧する環境や、Ｊａｖａ（米国サン・マイクロシステムズ社の商標）やＣのプログラムを起動してゲームなどのアプリケーションを動かす環境が搭載されており、これらの環境を活用すれば携帯電話端末をクライアントとしたウェブサービスが実現できる。これらの実現のためには、アプリケーションから関数や引数を渡してウェブサービスセキュリティ付きのＳＯＡＰメッセージを構築・送信する機能と、ウェブサービスセキュリティ付きのＳＯＡＰメッセージを受信・解読してその返り値をアプリケーションに渡す機能とを携帯電話端末に実装することが望ましい。携帯電話端末のように処理速度や実行時メモリ使用量が制限される場合には、できるだけ軽い処理でこれらの機能を実装する必要がある。
【０００５】
【非特許文献１】
Ｂｏｂ  Ａｔｋｉｎｓｏｎ  他、“Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｓｅｃｕｒｉｔｙ  （ＷＳ−Ｓｅｃｕｒｉｔｙ）”、［ｏｎｌｉｎｅ］、２００２年５月２３日、［２００３年２月２７日検索］、インターネット＜ｈｔｔｐ：／／ｗｗｗ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｊａｐａｎ／ｍｓｄｎ／ｗｅｂｓｅｒｖｉｃｅｓ／ｓｐｅｃ／ｗｓ−ｓｅｃｕｒｉｔｙ．ａｓｐ＞
【０００６】
【発明が解決しようとする課題】
ウェブサービスにおける主要な技術は、ＳＯＡＰメッセージの送信前の構築および受信後の解読の各処理である。
これらのＳＯＡＰメッセージ処理では、メモリ上にＤＯＭ（Ｄｏｃｕｍｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ）を作成して行う方法が一般的である。これは、メッセージ内の記述順番に関係なく木構造をたどって処理を行うことができるので、処理方法として汎用的に実行することができる。しかし、ＤＯＭを作成、操作するのに、
１）大きなメモリ使用量を要する。
２）処理に時間がかかる。
といった問題がある。
【０００７】
携帯電話端末をクライアントとしてウェブサービスを行う場合を考えると、携帯電話端末は処理速度や実行時メモリ使用量が制限されるために、上述したＤＯＭを用いる方法における問題は深刻である。
これらの問題を解決する手段として、ＳＯＡＰメッセージの構築、解読の処理をストリーミング処理で実行することが考えられる。これを実現するには、ヘッダ部分とボディ部分とを備え、ヘッダ部分に処理手順や処理情報が定義され、このヘッダ部分から処理対象がＩＤ参照されるような仕様の文書ファイルに対し、ヘッダ部分の記述に基づいて行われるボディ部分のメッセージの処理を、ストリーミング処理で実行する技術が必要である。
【０００８】
そこで本発明は、クライアントの処理能力やメモリに対する負担の軽いＳＯＡＰメッセージ送受信のための技術を提供し、かかる能力に制限のある端末装置をクライアントとするのに適したウェブサービスのシステムを実現することを目的とする。
また本発明は、ヘッダ部分とボディ部分とを備えた文書ファイルに対し、ヘッダ部分に記述された定義に基づいて行われるボディ部分の処理を、ストリーミング処理で実行する手法を提供することを他の目的とする。
【０００９】
【課題を解決するための手段】
上記の目的を達成する本発明は、次のようなＳＯＡＰメッセージの作成方法として実現される。すなわち、このＳＯＡＰメッセージ作成方法は、所定の記憶手段からメッセージ本体を所定の断片ごとに読み出す第１のステップと、読み出した断片に順次加工処理を行ってメッセージのボディ部分を生成し、所定の記憶手段の作業領域に保持すると共に、この加工処理に関する情報を取得する第２のステップと、取得した加工処理に関する情報を含むメッセージのヘッダ部分を生成し、所定の記憶手段の作業領域に保持する第３のステップと、この記憶手段の作業領域からボディ部分およびヘッダ部分を読み出して結合しＳＯＡＰメッセージを構築する第４のステップとを含むことを特徴とする。
この加工処理としては、具体的には、暗号化処理や署名処理を行うことができる。
【００１０】
また本発明は、次のようなＳＯＡＰメッセージ処理方法としても実現することができる。すなわち、このＳＯＡＰメッセージ処理方法は、ＳＯＡＰメッセージをパースしながら、このＳＯＡＰメッセージのヘッダ部分からボディ部分の加工処理に関する情報を抽出して所定の記憶手段の作業領域に格納する第１のステップと、このＳＯＡＰメッセージをパースしながら、記憶手段の作業領域に格納された情報に基づいて、ボディ部分の所定の箇所を順次加工する第２のステップとを含むことを特徴とする。
この加工処理としては、具体的には、暗号化されたメッセージの復号化処理や署名されたメッセージの検証処理を行うことができる。
また、メッセージのパースを再帰的に繰り返す必要がある場合、処理の進行に応じて独立のパーサを動的に作成し、適用することで行うことができる。
【００１１】
また、上記の目的を達成する他の本発明は、次のように構成されたことを特徴とする情報処理装置としても実現される。この情報処理装置は、ＳＯＡＰメッセージのボディ部分に対して所定の加工を行うと共に加工に関する情報を取得する加工処理部と、ＳＯＡＰメッセージを所定の断片ごとに読み込み、予め定められたメッセージの加工に関する設定に基づき、このメッセージにおける所定の断片を加工処理部に渡すメッセージ構築制御部と、加工処理部により取得された加工に関する情報を含むＳＯＡＰメッセージのヘッダ部分を生成するヘッダ生成部と、加工処理部により加工されたボディ部分とヘッダ生成部により生成されたヘッダ部分とを結合してＳＯＡＰメッセージを構築するメッセージ組立部とを備えることを特徴とする。
【００１２】
さらに本発明による他の情報処理装置は、ＳＯＡＰメッセージをパースしてヘッダ部分とボディ部分とを検出し、このボディ部分における加工対象をさらに検出する解読制御部と、この解読制御部にて検出されたヘッダ部分からボディ部分の加工処理に関する情報を抽出するヘッダ処理部と、このヘッダ処理部にて抽出された情報に基づいて、ボディ部分における加工対象に対して加工処理を行う加工処理部とを備え、解読制御部は、ＳＯＡＰメッセージを先頭から順にパースし、検出したヘッダ部分をヘッダ処理部へ渡し、さらに検出したボディ部分における加工対象を加工処理部に渡し、ヘッダ処理部および加工処理部は、解読制御部から受け取ったＳＯＡＰメッセージの部分を順次処理することを特徴とする。
【００１３】
さらにまた、本発明は、コンピュータを制御して上述したＳＯＡＰメッセージ作成方法や処理方法における各ステップに相当する処理を実行させるプログラムや、コンピュータに上記の情報処理装置の機能を実現させるプログラムとして実現することができる。このプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録媒体に格納して配布したり、ネットワークを介して配信したりすることにより、提供することができる。
また、本発明は、処理対象をＳＯＡＰメッセージ以外の、ヘッダ部分とボディ部分とを備え、当該ボディ部分に所定の処理の処理対象が設定され、当該ヘッダ部分に当該処理に関する情報および当該処理対象を指示する情報が記述される記述仕様のデータファイルに対しても適用することができる。
【００１４】
【発明の実施の形態】
以下、添付図面に示す実施の形態に基づいて、この発明を詳細に説明する。
図１は、ウェブサービスを実現するネットワークシステムの構成を示す図である。
図１に示すように、ウェブサービスを実現するネットワークシステムは、サービスを提供するサーバ１００と、当該サービスを利用するクライアント２００とを、インターネット等のネットワーク３００を介して接続して実現される。サーバ１００とクライアント２００との間の通信は、ＸＭＬベースのＳＯＡＰにて行われる。サーバ１００は、パーソナルコンピュータやワークステーション、その他のコンピュータ装置にて実現される。また、クライアント２００は、パーソナルコンピュータやワークステーション等のコンピュータ装置、携帯電話やネットワーク機能を備えたＰＤＡ等の情報端末にて実現される。本実施の形態では、クライアント２００として携帯電話端末を用いた場合を例として説明する。
【００１５】
図２は、本実施の形態におけるクライアント２００として用いられる携帯電話端末のハードウェア構成を模式的に示す図である。
図２に示すように、携帯電話端末は、無線による情報通信を行うための送受信部２０１と、無線で送受信されるデジタルデータの信号処理を行うベースバンドＬＳＩ２０２と、情報の表示や音声出力、キー操作や音声による入力を行うための入出力部２０３と、各種の情報処理及び各機能の制御を行うＣＰＵ２０４及びメモリ２０５とを備える。
なお、図２に示す構成は例示に過ぎず、一般的な情報処理装置における種々の構成を取り得ることは言うまでもない。また、本実施の形態を実現する上で、クライアント２００として携帯電話端末以外の各種の情報処理装置（コンピュータ装置、ＰＤＡ等）を用いることも可能である。
【００１６】
ウェブサービスにおけるデータ通信はＳＯＡＰメッセージとしてやり取りされるので、クライアント２００における主要な処理は、送信前に置けるＳＯＡＰメッセージの構築処理と、ＳＯＡＰメッセージの受信後の解読処理である。本実施の形態では、ＳＯＡＰメッセージの構築の際にウェブサービスセキュリティを実現するためのメッセージの暗号化および署名を行う。これに応じて、受信後のメッセージの解読においても、当該メッセージの復号化および署名の検証を行う。本実施の形態におけるクライアント２００は、これらの処理をストリーミング処理で実行する。
【００１７】
図３は、本実施の形態のクライアント２００におけるＳＯＡＰメッセージの構築処理を実行するための機能構成を示す図である。
図３を参照すると、本実施の形態によるＳＯＡＰメッセージ構築手段は、構築されたＳＯＡＰメッセージを格納するメッセージ格納部２１１と、ＳＯＡＰメッセージ構築のための前提となる各種の情報を構築するメッセージ構築制御部２１２と、メッセージに対する暗号化処理を行う暗号化処理部２１３と、メッセージに対する署名を行う署名処理部２１４と、ＳＯＡＰメッセージのヘッダを生成するヘッダ生成部２１５と、必要に応じて暗号化処理部２１３および署名処理部２１４にて処理されたメッセージ本体とヘッダ生成部２１５にて生成されたヘッダとを結合してＳＯＡＰメッセージを組み立てるメッセージ組立部２１６とを備える。
上記の構成において、メッセージ格納部２１１は、例えば図２に示したメモリ２０５にて実現される。また、メッセージ構築制御部２１２、暗号化処理部２１３、署名処理部２１４、ヘッダ生成部２１５、メッセージ組立部２１６は、例えば図２に示したＣＰＵ２０４にて実現される。
【００１８】
クライアント２００からサーバ１００への送信処理では、サービスを利用するためのクライアントアプリケーションから指定された関数名および引数名、引数値を用いて、リクエストＳＯＡＰメッセージが作成される。本実施の形態では、署名対象および暗号化対象の範囲、署名や暗号化の処理順、鍵や証明書に関する情報、使用するアルゴリズムに関する情報など（以下、これらの情報をまとめて加工情報と呼ぶ）は、ＳＯＡＰメッセージを作成する側（すなわちクライアント２００）が決定できる。ここではクライアントアプリケーションから指定されるものとする。
【００１９】
メッセージ構築制御部２１２は、まず、署名および暗号化処理を行う前段階のメッセージの構造を構築する。この処理では、ＳＯＡＰメッセージの雛形となるタグ群が、予め（プログラムの起動時などに）メモリ２０５の作業領域に格納される。また、クライアントアプリケーションから与えられる関数名や引数名を表すタグ群が、少なくともサーバ１００との通信前に、メモリ２０５の作業領域に格納される。これらのタグ群は、ＳＯＡＰメッセージに記述される順番で並べられる。
また、メッセージ構築制御部２１２は、セキュリティトークン（証明書など）に関する情報、署名に関する情報（署名方法など）、暗号化に関する情報（鍵、暗号化方法など）等の加工情報を記録したデータを構築する。そして、このデータをメモリ２０５の作業領域に格納する。この際、署名に関する情報と暗号化に関する情報をクライアントアプリケーションから指定された順に並べておく。
【００２０】
さらにメッセージ構築制御部２１２は、メモリ２０５に格納したタグ群を、所定の順番にしたがってＵＴＦ−８（ＵＣＳ  Ｔｒａｎｓｆｅｒ  Ｆｏｒｍａｔ−８）のバイト列に変換し、ＳＯＡＰメッセージを生成する。生成されたＳＯＡＰメッセージは、メッセージ格納部２１１に格納される。このＳＯＡＰメッセージの所定の箇所が暗号化処理の対象または署名対象に相当する場合、該当個所のバイト列は、上述した加工情報にて指定された処理順にしたがって、暗号化処理部２１３または署名処理部２１４に渡され、加工された後にメッセージ格納部２１１に格納される。暗号化や署名といったバイト列の加工は、ＳＯＡＰメッセージの任意の箇所に任意の数だけ個別に施行することができる。メッセージ構築制御部２１２から暗号化処理部２１３または署名処理部２１４へのバイト列の受け渡しは、行単位やバイト単位の断片ごとに行われる。そして、この断片ごとに順次ストリーミング処理にて下記の暗号化処理や署名処理が実行される。
【００２１】
暗号化処理部２１３は、メッセージ構築制御部２１２から処理対象であるバイト列を受け取ると、まずメッセージにおける処理対象の該当個所を参照するための参照ＩＤと暗号化方法とを記述したメッセージ断片（バイト列）を作成し出力する。そして受け取ったバイト列を暗号化して出力する。
ここで、暗号化方法としてストリーミング処理できる暗号化アルゴリズムを採用しているときには、メッセージ構築制御部２１２から受け取ったバイト列に対して順次、暗号化を行い、その結果を出力する。これに対し、ストリーミング処理できる暗号化アルゴリズムを採用していない場合は、メッセージ構築制御部２１２から受け取ったバイト列を蓄積していき、暗号化対象である部分の末尾に到達したところでまとめて暗号化を行い、その結果を出力する。なお、暗号化処理部２１３は、バイト列に対して施す暗号化処理の種類等に応じて複数設けることも可能である。
【００２２】
署名処理部２１４は、メッセージ構築制御部２１２から処理対象であるバイト列を受け取ると、まずメッセージにおける処理対象の該当個所を参照するための参照ＩＤを記述したメッセージ断片（バイト列）を作成し出力する。そして、メッセージ構築制御部２１２から受け取ったバイト列を蓄積していき、署名対象の末尾に到達したところで、蓄積されたバイト列のダイジェスト値（元のバイト列から特定の方法で計算される値）を算出し、メモリ２０５の作業領域に記録しておく。蓄積されたバイト列自体はそのまま出力される。なお、署名処理部２１４は、バイト列に対して施す署名処理の種類等に応じて複数設けることも可能である。
【００２３】
暗号化処理部２１３または署名処理部２１４で処理された出力バイト列は、リクエストＳＯＡＰメッセージの一部として、メッセージ構築制御部２１２にて生成されたＳＯＡＰメッセージの他の断片と共に、メッセージ格納部２１１に格納される。
なお、バイト列が複数の処理の対象である場合（暗号化され、さらに署名される場合や、複数種類の暗号化あるいは署名が施される場合など）には、前の処理の出力バイト列を後の処理の入力バイト列とする（例えば、暗号化処理部２１３で暗号化した後、その出力バイト列を署名処理部２１４の入力バイト列として署名処理を実行するなど）。そして、各処理が終了した後、メッセージ格納部２１１に格納される。
【００２４】
図４は、メッセージの断片ごとにストリーミング処理にて実行される上記の加工処理のイメージを示す図である。
図４に示すように、メッセージ構築制御部２１２にて生成されたＳＯＡＰメッセージは、メッセージ構築制御部２１２にて構築された加工情報のデータにしたがって、断片ごとに暗号化処理部２１３または署名処理部２１４に送られ、ストリーミング処理にて順次加工されて、リクエストＳＯＡＰメッセージを構成するバイト列としてメッセージ格納部２１１に蓄積される。ＳＯＡＰメッセージのどの断片に対してどの処理を施すかは、メッセージ構築制御部２１２において初期設定に基づいて構築されたデータにしたがって行われる。図４の例では、処理ｍに対して暗号化処理が行われ、その次の処理ｎに対して署名処理が行われる。
【００２５】
ヘッダ生成部２１５は、メッセージ構築制御部２１２にて生成されたＳＯＡＰメッセージにおける全ての署名対象および暗号化対象に対して、暗号化処理部２１３および署名処理部２１４による処理が完了した後、このＳＯＡＰメッセージのヘッダに記述する情報をバイト列として生成する。具体的には次のようにしてヘッダを生成する。
図５は、ヘッダ生成部２１５による処理を説明する図である。
図５に示すように、ヘッダ生成部２１５は、まずメッセージ構築制御部２１２にて構築されメモリ２０５の作業領域に保持されていたセキュリティトークンの情報を読み出し、バイト列として出力する。続いて、暗号化処理部２１３により得られた暗号化処理に関する情報（参照ＩＤ、暗号鍵等）と署名処理部２１４により得られた署名処理に関する情報（ダイジェスト値、署名方法、参照ＩＤ等）とを入力し、加工情報に示された処理順に従ってバイト列として出力する。署名処理に関しては、予め記録されているダイジェスト値を出力するだけでなく、ダイジェスト値を含む情報から署名値を算出し、これも併せて出力する。これらの出力バイト列は、ＳＯＡＰメッセージのヘッダ情報としてメッセージ格納部２１１に格納される。
【００２６】
以上のように、メッセージ構築制御部２１２にて生成されたＳＯＡＰメッセージに対して暗号化処理部２１３および署名処理部２１４によって必要な箇所に処理が施され、ヘッダ生成部２１５にてヘッダ情報が生成された後、メッセージ組立部２１６は、メッセージ格納部２１１からこれらのデータを読み出し、結合してリクエストＳＯＡＰメッセージを組み立てる。組み立てられたリクエストＳＯＡＰメッセージは、図２に示したベースバンドＬＳＩ２０２、送受信部２０１を介してサーバ１００へ送信される。
【００２７】
上述したように、本実施の形態では、ＳＯＡＰメッセージを構築する際に行われる暗号化や署名といったデータの加工処理を、ストリーミング処理にて実行する。そして、加工処理が終了した後に、この処理の過程で得られた情報を用いてヘッダ情報を生成する。このような手順でＳＯＡＰメッセージの構築を行うことにより、加工処理を行う段階では、各処理によって取得される情報と処理中のメッセージの断片のみがメモリに保持されている必要があり、ヘッダ情報を生成する段階では、蓄積された取得情報のみがメモリに保持されている必要がある。すなわち、従来のようにＳＯＡＰメッセージ全体やＤＯＭなどの中間表現をメモリの作業領域に読み込んでおいて処理を行う必要はなく、実行時のメモリ使用量を大幅に削減することができる。また、ＤＯＭ等の中間表現を作成しないため、ＳＯＡＰメッセージを構築するのに要する時間を短縮することができる。
【００２８】
図６は、本実施の形態のクライアント２００におけるＳＯＡＰメッセージの解読処理を実行するための機能構成を示す図である。
図６を参照すると、本実施の形態によるＳＯＡＰメッセージ解読手段は、受信したＳＯＡＰメッセージをストリーミング処理にて解読するための制御を行う解読制御部２２１と、ＳＯＡＰメッセージのヘッダ部分から必要な情報を取り出すヘッダ処理部２２２と、暗号化された部分（バイト列）の復号化処理を行う復号化処理部２２３と、署名の検証処理を行う検証処理部２２４と、解読されたＳＯＡＰメッセージ返り値を抽出する返り値抽出部２２５とを備える。
上記の各機能は、例えば図２に示したＣＰＵ２０４にて実現される。
【００２９】
サーバ１００からクライアント２００へ送られたレスポンスＳＯＡＰメッセージの受信処理では、サーバ１００で署名および暗号化されたＳＯＡＰメッセージから、署名の検証および暗号化されたメッセージの復号化の各処理を実行して返り値を取得する。そして、得られた返り値をクライアントアプリケーションに渡す。ウェブサービスセキュリティの下では、所定の対象（バイト列）に対して署名を行い、別の対象（バイト列）に暗号化を行うというように、複数回のセキュリティ処理を行っている場合もある。本実施の形態では、ストリーミング処理により、ＳＯＡＰメッセージのヘッダ部分を上から順にパースして解読する。
【００３０】
解読制御部２２１は、ＸＭＬパーサを用いて、受信したレスポンスＳＯＡＰメッセージをパースする。そして、ヘッダ部分、復号化対象の部分（暗号化された部分）、検証対象の部分（署名された部分）を検出すると、その部分のバイト列を行単位やバイト単位の断片ごとに、それぞれヘッダ処理部２２２、復号化処理部２２３または検証処理部２２４に渡して処理を実行させる。
【００３１】
ヘッダ処理部２２２は、解読制御部２２１からレスポンスＳＯＡＰメッセージのヘッダ部分を先頭から順次受け取ってストリーミング処理にて処理し、後の解読処理に必要な情報を取得する。
図７は、ヘッダ処理部２２２の動作を説明するフローチャートである。
図７を参照すると、ヘッダ処理部２２２は、取得したレスポンスＳＯＡＰメッセージのヘッダ部分を読み（ステップ７０１）、セキュリティトークンに関する記述が始まったならば、その中に記述された証明書の情報やＩＤを抽出してメモリ２０５の作業領域に記録しておく（ステップ７０２）。次に、復号化処理に関する情報の記述が始まったならば、復号化情報（復号鍵、復号化対象ＩＤ等）を抽出してメモリ２０５の作業領域に記録しておく（ステップ７０３、７０４）。復号鍵自体が暗号化されている場合は、これを復号化してから記録する。また、署名の検証に関する情報の記述が始まったならば、検証情報（ダイジェスト値、検証対象ＩＤ、ダイジェスト方法、署名値等）を抽出してメモリ２０５の作業領域に記録しておく（ステップ７０５、７０６）。ここでさらに、署名情報のＵＴＦ−８のバイト列から算出される署名値と、ステップ７０５で抽出された署名値とを比較して、署名内容を検証する（ステップ７０７）。そして、検証結果が「偽」である場合は、処理を中断して「偽」であることを解読制御部２２１に通知する（ステップ７０８、７０９）。この通知を受けた解読制御部２２１は、レスポンスＳＯＡＰメッセージの解読処理を終了し、クライアントユーザに通知する等の所定のエラー処理を行う。
レスポンスＳＯＡＰメッセージのヘッダ部分全体に対して以上の処理を行った後、ヘッダ処理部２２２は、ヘッダ部分における復号化および検証の記述順番で、復号化情報および検証情報を並べてメモリ２０５に格納する（ステップ７１０、７１１）。後述する復号化処理および検証処理は、この順番に従って行われる。
【００３２】
解読制御部２２１は、メモリ２０５に格納された復号化情報および検証情報を参照しながら、さらにレスポンスＳＯＡＰメッセージを読み進め、ヘッダ処理部２２２によって得られたヘッダ情報において指定された復号化対象および検証対象を検出すると、この対象を復号化処理部２２３または検証処理部２２４に渡してメッセージの加工処理を実行させる。上述したように、ＳＯＡＰメッセージの複数箇所に対して複数回のセキュリティ処理を行っている場合がある。したがって、解読制御部２２１によるこれらの処理の制御は次のように行われる。
図８は、解読制御部２２１による制御手順を説明するフローチャートである。
まず、ＳＯＡＰメッセージから復号化対象または検証対象（以下、処理対象）の開始を検出したならば、その対象がヘッダ処理部２２２で取得された復号化情報および検証情報（以下、処理情報）のいずれに対応するかを決定する（ステップ８０１）。これは、図７のステップ７１１で得られた順番に従って最初の処理情報から順次評価し、選択していく。ただし、その過程で復号化情報が選択された場合は、それ以降の処理情報は評価しない。この結果、処理情報が複数選択されることもある。次に、選択された処理情報に従って、復号化処理部２２３または検証処理部２２４により、処理対象のバイト列を順次処理していく（ステップ８０２）。復号化処理部２２３または検証処理部２２４による処理の詳細は後述する。最後に、復号化処理部２２３または検証処理部２２４からの通知等により処理対象に対する処理の終了を検出したならば、選択された当該処理情報を解放し、ＳＯＡＰメッセージのパースを続行する。ＳＯＡＰメッセージの最後までパースし、必要な加工処理が完了したならば、当該ＳＯＡＰメッセージの解読は終了する（ステップ８０３）。
【００３３】
次に、図８のステップ８０２に示した処理の詳細を説明する。
復号化処理部２２３は、解読制御部２２１にて検出された復号化対象のバイト列に対し、選択された復号化情報に基づいて、次の手順でストリーミング処理による復号化処理を行う。
図９は、復号化処理部２２３による復号化処理の手順を説明するフローチャートである。
図９に示すように、復号化処理部２２３は、まず解読制御部２２１から受け取ったバイト列に復号化方法が記述されている場合は、これをメモリ２０５の作業領域に保持する。また、解読制御部２２１から受け取ったバイト列に復号鍵の情報が記述されている場合は、この復号鍵を取得し、これをメモリ２０５の作業領域に保持する（ステップ９０１）。
解読制御部２２１から受け取ったバイト列が復号対象の暗号文である場合は、これをメモリ２０５の作業領域に蓄積していく（ステップ９０２）。そして、バイト列が復号対象である暗号文の末尾に到達したところで、図７のステップ７０４で得られた復号化情報を用いて当該暗号文全体を復号化する（ステップ９０３、９０４）。
次に、復号化の結果である平文を解読制御部２２１に渡し、当該平文全体をエンティティとしてパースし、図８に示した処理手順を再帰的に適用する（ステップ９０５）。再帰的なパース処理および復号化処理を繰り返し、復号化対象が検出されなくなったならば、この復号化対象に対する処理を終了する。そして、処理結果の平文をレスポンスＳＯＡＰメッセージの一部としてメモリ２０５に蓄積する（すなわち元のレスポンスＳＯＡＰメッセージの該当個所と置き換える）と共に、解読制御部２２１に処理の完了を通知して解読制御部２２１による最初の動作に戻り（ステップ９０６）、ＳＯＡＰメッセージのパースを続行する（図８のステップ８０３）。
【００３４】
さて、図９に示した処理では、復号化対象である暗号文を蓄積していき、最後のバイト列に達した後に全体を復号化した。しかしながら、復号化方法がストリーミング処理で実行できる方法（例えば、ｔｒｉｐｌｅ  ＤＥＳやＡＥＳ）である場合は、図９に代えて次のような手順で復号化処理を行うことができる。
図１０は、復号化処理部２２３による他の復号化処理の手順を説明するフローチャートである。
図１０に示すように、復号化処理部２２３は、まず解読制御部２２１から受け取ったバイト列に復号化方法が記述されている場合は、これをメモリ２０５の作業領域に保持する。また、解読制御部２２１から受け取ったバイト列に復号鍵情報が記述されている場合は、この復号鍵を取得し、これをメモリ２０５の作業領域に保持する（ステップ１００１）。
次に、復号化処理部２２３は、解読制御部２２１から復号対象の暗号文の先頭であるバイト列を受け取った時点で、解読制御部２２１による現在のパーサと同様の内部状態を保持する独立のパーサ（以下、子パーサ。この子パーサに対して現在のパーサを親パーサと呼ぶ）を作成する（ステップ１００２）。そして、以降の暗号文のバイト列（以下、部分暗号文）を順次復号化し、ステップ１００２で作成した子パーサに渡す（ステップ１００３）。
【００３５】
子パーサは、取得した平文（部分暗号文に対する平文）をエンティティの一部として順次パースし、図８に示した処理と同様の処理手順を再帰的に適用する（ステップ１００４）。
この再帰処理を経て処理対象のバイト列が暗号文の末尾に到達したならば、当該バイト列中にさらに復号化処理を行うべき部分は存在しないので、ステップ１００２で作成した子パーサを廃棄する（ステップ１００５）。そして、処理結果の平文をリクエストＳＯＡＰメッセージの一部としてメモリ２０５に蓄積する（すなわち元のレスポンスＳＯＡＰメッセージの該当個所と置き換える）と共に、解読制御部２２１に処理の完了を通知して解読制御部２２１による最初の動作に戻り（ステップ１００６）、ＳＯＡＰメッセージのパースを続行する（図８のステップ８０３）。
ステップ１００４における再帰処理は、ステップ１００３において復号化された平文中に対する子パーサによるパースの結果、さらに復号化すべき部分が検出されなくなるまで繰り返される。すなわち、復号化対象が検出される限り、子パーサの子パーサが入れ子状に動的に作成され、各段階で処理が実行されることとなる。そして、ある時点で復号化対象が検出されなかった場合に、親パーサによる処理に段階的に戻っていく。
【００３６】
図１０に示した手順では、復号化処理の結果であるバイト列に対して独立のパーサ（子パーサ）を用意して、ストリーミング処理により順次、パースおよび復号化を行っていくため、図９に示した処理の場合のように処理の過程で暗号文全体がメモリ２０５に保持されることがない。そのため、オーバーヘッドが削減され、処理のパフォーマンスが向上することが期待される。ただし、子パーサを作成するオーバーヘッドが別に発生するため、この手順による処理を実行するのは、暗号文保留によるオーバーヘッドよりも有利な場合とするのが好ましい。子パーサを作成するためのオーバーヘッドを削減するには、可能な場合には１度作成した子パーサを再利用する等の方法が考えられる。子パーサの作成に関する処理の詳細は後述する。
【００３７】
検証処理部２２４は、解読制御部２２１にて検出された検証対象のバイト列に対し、選択された検証情報に基づいて、次の手順でストリーミング処理による署名の検証処理を行う。
図１１は、検証処理部２２４による検証処理の手順を説明するフローチャートである。
図１１に示すように、検証処理部２２４は、解読制御部２２１から受け取ったバイト列を蓄積していき（ステップ１１０１）、検証対象の末尾に到達したならば、蓄積したバイト列のダイジェスト値を計算する（ステップ１１０２、１１０３）。そして、算出されたダイジェスト値を、図７のステップ７０６で得られた検証情報に含まれるダイジェスト値と比較して署名内容を検証し（ステップ１１０４）、検証結果を解読制御部２２１に通知する（ステップ１１０５）。
この検証結果が「真」である場合は、解読制御部２２１において、さらにＳＯＡＰメッセージのパースが続行される（図８のステップ８０３）。一方、検証結果が「偽」である場合、解読制御部２２１は、レスポンスＳＯＡＰメッセージの解読処理を終了し、クライアントユーザに通知する等の所定のエラー処理を行う。
【００３８】
図１２は、レスポンスＳＯＡＰメッセージに対して行われる復号化処理あるいは署名の検証処理のイメージを示す図である。
図１２に示すように、解読制御部２２１にて検出されたメッセージ中の復号化対象は復号化処理部２２３に送られて処理され、検証対象は検証処理部２２４へ送られて処理される。図１２の例では、ＳＯＡＰメッセージ中の処理ｍに対して復号化処理が行われ、その次の処理ｎに対して検証処理が行われる。メッセージ中の所定の箇所に対して複数回のセキュリティ処理が行われている場合、当該箇所をそれぞれの処理対象として処理する必要がある。例えば、所定のバイト列が暗号化され、さらに署名されているような場合は、当該箇所を復号化した後さらに検証する必要がある。このような場合は、前の処理の出力バイト列を後の処理の入力バイト列とする。これらの処理を経たバイト列は、元のレスポンスＳＯＡＰメッセージの該当個所に戻され、後述の返り値の抽出処理に供される。
【００３９】
返り値抽出部２２５は、上記のように解読制御部２２１の制御によりレスポンスＳＯＡＰメッセージを読んでいる途中で、返り値のタグを見つけ次第、この返り値を、メモリ２０５の作業領域に保存しておく。そして、検証処理部２２４による検証処理が全て終了した時点で、全ての検証結果が「真」であったならば、保存した返り値をクライアントアプリケーションに渡す。クライアントアプリケーションは、この返り値を用いて目的の処理を実行する。
【００４０】
次に、図１０に示したＸＭＬパーサの動的作成について詳細に説明する。
ウェブサービスセキュリティの基盤であるＸＭＬ  Ｅｎｃｒｙｐｔｉｏｎでは、復号化処理部２２３の機能について上述した際に説明したように、ＸＭＬ文書の復号化において、まずＸＭＬ文書（ＳＯＡＰメッセージ）をパースしてその一部を復号化し、その復号結果（以下、ＸＭＬ断片）をさらにパースする必要がある。図９に示した処理手順では、この多重にパースを行う処理を実現するため、ＸＭＬ断片をパーサに戻し、エンティティとしてパースするという方法が採られている。
【００４１】
図１３は、図９の処理手順に対応するＸＭＬ文書のパース方法を説明する図である。
図１３には、ＸＭＬ文書のパース結果の一部であるＸＭＬ断片をパーサへ戻して再帰的にパースを行う様子が示されている。このように、解読制御部２２１にて提供されるパーサを再帰的に用いることにより、ＸＭＬ文書に対して多重にパース処理を行うことができるため、ＸＭＬ断片を直接的かつ適切にパースすることができる。
しかし、この方法では、ＸＭＬ断片をパースするためにパーサが使用されてしまうため、ＸＭＬ断片のパース結果を元のＸＭＬ文書に戻すまで当該ＸＭＬ文書自体の処理を待機する必要がある（ＸＭＬ断片の一部に対してさらにパースを行う場合も、同様に、その一部に対するパース結果が戻されるまで当該ＸＭＬ断片の処理を待機する）。そのため、
▲１▼処理を待機する間、元のＸＭＬ文書やＸＭＬ断片を保持するためにメモリを要する。
▲２▼元のＸＭＬ文書に対するパースが完了するまで、クライアントアプリケーションも待機する必要があり、時間を要する。
という問題があった。
【００４２】
図１４は、図１０の処理手順に対応するＸＭＬ文書のパース方法を説明する図である。図１４において、パーサ１にとってパーサ２は子パーサ、パーサ２にとってパーサ１は親パーサである。同様に、パーサ２にとってパーサ３は子パーサ、パーサ３にとってパーサ２は親パーサである。
図１４に示すように、図１０の処理手順では、現在のパーサ（親パーサ）と同様の内部状態を保持するパーサ（子パーサ）を動的に作成し、ＸＭＬ断片をエンティティとして、元のＸＭＬ文書に対するパースとは独立にパースする。ＸＭＬ断片の一部をさらに復号化し、その結果をパースする場合は、子パーサを作成して独立にパースする処理を繰り返して実行する。ＸＭＬ文書（ＸＭＬ断片を含む）を復号化する度に、この復号化した部分に対して独立にパースを行っていくため、元のＸＭＬ文書に対する処理を、その一部に対するパースが終了するまで待機する必要はない。すなわち、復号化対象に関しては、その部分へのパース結果が得られてから、必要に応じて当該パース結果で置き換えれば良い。なお、復号化対象は復号化された時点で平文に変換されているので、パース結果に置き換える必要のある場合とは、当該復号化対象の一部に対してさらに復号化処理を行った場合である。
【００４３】
この方法によれば、子パーサがパースを行っている間、親パーサの処理対象である元のＸＭＬ文書やＸＭＬ断片を保持しておく必要がないため、メモリの使用量を削減できる。また、ＸＭＬ文書の解読処理全体がストリーミング処理にて行われ、復号化対象は順次復号化されてＸＭＬ文書に追加されていくため、クライアントアプリケーションは元のＸＭＬ文書に対するパースが完了するまで待機することなく順次実行することができる。
【００４４】
さて、子パーサは、親パーサと同様の内部状態を継承する必要があるが、ここで継承すべき内部状態には、少なくとも、シンボルテーブル、名前空間スタック、エンティティテーブル、エンティティリゾルバ、ドキュメント（またはコンテンツ）ハンドラ、エラーハンドラが挙げられる。シンボルテーブルとは、文字列を管理するテーブルであり、同一の文字列は同一の参照をもつことを保証するものである。名前空間スタックとは、階層ごとの名前空間を管理するスタックである。エンティティテーブルとは、エンティティの名前と実体の対応を管理するテーブルである。エンティティリゾルバとは、エンティティの名前から実体を特定するコンポーネントである。ドキュメント（またはコンテンツ）ハンドラとは、パース結果を通知するコンポーネントである。エラーハンドラとは、エラーを通知するコンポーネントである。
これらの内部状態うち、名前空間スタック以外は親パーサと共有してもよい。名前空間スタックはコピーすることによって子パーサへ継承されるが、スタック全体をコピーする必要はなく、復号化を始める時点で有効な名前空間をコピーするだけでよい。
【００４５】
子パーサを動的に作成した場合、ＸＭＬ断片の受け渡しについてはどのように実装しても良いが、例えば、次のような実装が考えられる。
図１５は、スレッドとスレッドセーフなバッファによるＸＭＬ断片の受け渡しの実装例を示す図である。
図１５に示す実装例では、解読制御部２２１による親パーサ１５１０と、復号化処理部２２３にて作成された子パーサ１５２０と、メモリ２０５にて実現されるバッファ１５３０とが用意される。そして、まず親パーサ１５１０がＸＭＬ文書を読み込み（１）、当該ＸＭＬ文書をパースして、パース結果を利用するアプリケーション（上述したウェブサービスのクライアント２００ではクライアントアプリケーション）に送る（２）。また、パースしたＸＭＬ文書の一部（ＸＭＬ断片）をバッファ１５３０に書き込む（３）。このとき、上述したクライアント２００では、ＸＭＬ断片が復号化処理部２２３にて復号化された後にバッファ１５３０に書き込まれることとなる。
【００４６】
次に、子パーサ１５２０は、バッファ１５３０からＸＭＬ断片を読み込み（４）、当該ＸＭＬ断片をパースして、パース結果をアプリケーションに送る（５）。そして引き続き、親パーサ１５１０がＸＭＬ文書の残りの部分をパースして、パース結果をアプリケーションに送る（６）。
【００４７】
図１６は、コルーチンによるＸＭＬ断片の受け渡しの実装例を示す図である。
図１６に示す実装例では、解読制御部２２１による親パーサ１６１０と、復号化処理部２２３にて作成された子パーサ１６２０とが用意される。そして、まず親パーサ１６１０がＸＭＬ文書を読み込み（１）、当該ＸＭＬ文書をパースして、パース結果を利用するアプリケーションに送る（２）。次に、ＸＭＬ文書の一部（ＸＭＬ断片）をパイプに書き込む（３）。このとき、上述したクライアント２００では、ＸＭＬ断片が復号化処理部２２３にて復号化された後にパイプに書き込まれることとなる。
子パーサ１６２０は、このパイプに書き込まれたＸＭＬ断片を読み込み、当該ＸＭＬ断片をパースして、パース結果をパイプに書き込む（４）。親パーサ１６１０は、このパイプに書き込まれたパース結果を読み込み、アプリケーションに送る（５）。そして、引き続きＸＭＬ文書の残りの部分をパースして、パース結果をアプリケーションに送る（６）。
【００４８】
図１７は、ＳＡＸやＸＮＩ等のプッシュＡＰＩによるＸＭＬ断片の受け渡しの実装例を示す図である。
図１７に示す実装例では、解読制御部２２１による親パーサ１７１０と、復号化処理部２２３にて作成された子パーサ１７２０とが用意される。そして、まず親パーサ１７１０がＸＭＬ文書を読み込み（１）、当該ＸＭＬ文書をパースして、パース結果を利用するアプリケーションに送る（２）。また、ＸＭＬ文書の一部（ＸＭＬ断片）を子パーサ１７２０に通知する（３）。このとき、上述したクライアント２００では、ＸＭＬ断片が復号化処理部２２３にて復号化された後に子パーサ１７２０に通知されることとなる。
子パーサ１７２０は、親パーサ１７１０から受け取ったＸＭＬ断片をパースして、パース結果をアプリケーションに送る（４）。そして引き続き、親パーサ１７１０がＸＭＬ文書の残りの部分をパースして、パース結果をアプリケーションに送る（５）。
【００４９】
図１８は、プルＡＰＩによるＸＭＬ断片の受け渡しの実装例を示す図である。
図１８に示す実装例では、解読制御部２２１による親パーサ１８１０と、復号化処理部２２３にて作成された子パーサ１８２０とが用意される。そして、まず親パーサ１８１０がＸＭＬ文書を読み込む（１）。ＸＭＬ文書のパース結果を利用するアプリケーションから親パーサ１８１０に対してパース結果が要求されると（２）、親パーサ１８１０は、当該ＸＭＬ文書をパースして、パース結果を利用するアプリケーションに送る（３）。
【００５０】
次に、アプリケーションから子パーサ１８２０に対してパース結果が要求されると（４）、子パーサ１８２０は、親パーサ１８１０に対して対応するＸＭＬ文書の部分（ＸＭＬ断片）を要求する（５）。これに応じて、親パーサ１８１０は、該当するＸＭＬ断片を子パーサ１８２０に通知する（６）。このとき、上述したクライアント２００では、ＸＭＬ断片が復号化処理部２２３にて復号化された後に子パーサ１８２０に通知されることとなる。
【００５１】
次に、子パーサ１８２０は、親パーサ１８１０から受け取ったＸＭＬ断片をパースして、パース結果をアプリケーションに送る（７）。そして引き続き、アプリケーションからの要求に応じて、親パーサ１８１０がＸＭＬ文書の残りの部分をパースして（８）、パース結果をアプリケーションに送る（９）。
なお、親パーサ１８１０および子パーサ１８２０は、ラッパーモジュールにて統括的に管理されており、アプリケーションは直接的にはこのラッパーモジュールに対してパース結果を要求することにより、適切なパーサ（親パーサ１８１０または子パーサ１８２０）にアクセス要求が渡されることとなる。
【００５２】
以上のように、本実施の形態によるＳＯＡＰメッセージの加工処理は、ストリーミング処理によってメッセージの加工（暗号化、署名、復号化、検証）を実行できるため、処理の実行時にＤＯＭ、その他のＸＭＬ文書の中間表現をメモリ上に保持しておく必要がないため、メモリの使用量を減少させると共に、ＣＰＵの負担を軽減させることができる。
【００５３】
なお、上述した、ＸＭＬ文書のパースに関して、子パーサを動的に作成しながら再帰的にパースを実行する手法は、上述した暗号化されたＸＭＬ文書の復号化処理以外にも、例えば、ＸＭＬ文書の一部が圧縮されている場合の解凍処理や、符号化されているＸＭＬ文書の復号にも適用することが可能である。
【００５４】
また、本実施の形態は、ウェブサービスセキュリティにおけるＳＯＡＰメッセージ構築時または解読時における加工処理（暗号化、署名、復号化、検証）を例として説明したが、本実施の形態のストリーミング処理によるデータファイルの処理方法は、ＳＯＡＰメッセージ以外のＸＭＬ文書、さらに一般的に、ヘッダ部分とボディ部分とを備え、当該ボディ部分に所定の処理の処理対象が設定され、当該ヘッダ部分に当該処理に関する情報および当該処理対象を指示する情報が記述される記述仕様を持ったデータファイルを対象として、暗号化や署名、上記の圧縮や符号化といった加工処理を行う場合にも広く適用することが可能である。
【００５５】
【発明の効果】
以上説明したように、本発明によれば、クライアントの処理能力やメモリに対する負担の軽いＳＯＡＰメッセージ送受信のための技術を提供し、かかる能力に制限のある端末装置をクライアントとするのに適したウェブサービスのシステムを実現することができる。
また、本発明によれば、ヘッダ部分とボディ部分とを備えた文書ファイルに対し、ヘッダ部分に記述された定義に基づいて行われるボディ部分の処理を、ストリーミング処理で実行する手法を提供することができる。
【図面の簡単な説明】
【図１】ウェブサービスを実現するネットワークシステムの構成を示す図である。
【図２】本実施の形態におけるクライアントとして用いられる携帯電話端末のハードウェア構成を模式的に示す図である。
【図３】本実施の形態のクライアントにおけるＳＯＡＰメッセージの構築処理を実行するための機能構成を示す図である。
【図４】メッセージの断片ごとにストリーミング処理にて実行される本実施の形態による加工処理のイメージを示す図である。
【図５】本実施の形態のヘッダ生成部による処理を説明する図である。
【図６】本実施の形態のクライアントにおけるＳＯＡＰメッセージの解読処理を実行するための機能構成を示す図である。
【図７】本実施の形態におけるヘッダ処理部の動作を説明するフローチャートである。
【図８】本実施の形態の解読制御部による制御手順を説明するフローチャートである。
【図９】本実施の形態の復号化処理部による復号化処理の手順を説明するフローチャートである。
【図１０】本実施の形態の復号化処理部による他の復号化処理の手順を説明するフローチャートである。
【図１１】本実施の形態の検証処理部による検証処理の手順を説明するフローチャートである。
【図１２】レスポンスＳＯＡＰメッセージに対して行われる本実施の形態による復号化処理あるいは署名の検証処理のイメージを示す図である。
【図１３】図９の処理手順に対応するＸＭＬ文書のパース方法を説明する図である。
【図１４】図１０の処理手順に対応するＸＭＬ文書のパース方法を説明する図である。
【図１５】本実施の形態におけるスレッドとスレッドセーフなバッファによるＸＭＬ断片の受け渡しの実装例を示す図である。
【図１６】本実施の形態におけるコルーチンによるＸＭＬ断片の受け渡しの実装例を示す図である。
【図１７】本実施の形態におけるプッシュＡＰＩによるＸＭＬ断片の受け渡しの実装例を示す図である。
【図１８】本実施の形態におけるプルＡＰＩによるＸＭＬ断片の受け渡しの実装例を示す図である。
【符号の説明】
１００…サーバ、２００…クライアント、２０１…送受信部、２０２…ベースバンドＬＳＩ、２０３…入出力部、２０４…ＣＰＵ、２０５…メモリ、２１１…メッセージ格納部、２１２…メッセージ構築制御部、２１３…暗号化処理部、２１４…署名処理部、２１５…ヘッダ生成部、２１６…メッセージ組立部、２２１…解読制御部、２２２…ヘッダ処理部、２２３…復号化処理部、２２４…検証処理部、２２５…返り値抽出部
【図１】
2004274355.tif 000003
【図２】
2004274355.tif 000004
【図３】
2004274355.tif 000005
【図４】
2004274355.tif 000006
【図５】
2004274355.tif 000007
【図６】
2004274355.tif 000008
【図７】
2004274355.tif 000009
【図８】
2004274355.tif 000010
【図９】
2004274355.tif 000011
【図１０】
2004274355.tif 000012
【図１１】
2004274355.tif 000013
【図１２】
2004274355.tif 000014
【図１３】
2004274355.tif 000015
【図１４】
2004274355.tif 000016
【図１５】
2004274355.tif 000017
【図１６】
2004274355.tif 000018
【図１７】
2004274355.tif 000019
【図１８】
2004274355.tif 000020