(57)【要約】【課題】テキストベースの構造言語をベースとしたメッセージ交換用のプロトコルにおいて、添付ファイル方式を採用しながらも、テキストベースの構造言語に対応した標準的なＡＰＩを利用可能にする。【解決手段】添付ファイル付きメッセージから、メッセージと添付ファイルを分離し、分離された添付ファイルをメモリに記憶する。又、分離されたメッセージに含まれる要素を用いて、構造言語用のアプリケーションプログラミングインターフェイスに適応した構造を有するデータを構築する。そして、分離されたメッセージに含まれている各要素に基づいて、上記構築されたデータの各要素に型情報を付与する。ここで、添付ファイルの参照を示す型情報が付与された要素には、当該要素にリンクされている添付ファイルの上記メモリにおける格納場所を示す情報が付加される。【選択図】  図７
2007304994.tif 000002
【特許請求の範囲】
【請求項１】
テキストベースの構造言語をベースとしたメッセージ交換のためのプロトコルで通信される添付ファイル付きメッセージを処理する情報処理方法であって、
前記添付ファイル付きメッセージから、前記メッセージと前記添付ファイルを分離する分離工程と、
前記添付ファイルをメモリに記憶する記憶工程と、
前記メッセージに含まれる要素を用いて、前記構造言語用のアプリケーションプログラミングインターフェイスに適応した構造を有するデータを構築する構築工程と、
前記メッセージに含まれる各要素に基づいて、前記構築工程で構築されたデータの各要素に型情報を付与する付与工程と、
前記付与工程で添付ファイルの参照を示す型情報が付与された要素に、当該要素にリンクされている添付ファイルの前記メモリにおける格納場所を示す情報を付加する付加工程とを備えることを特徴とする情報処理方法。
【請求項２】
前記プロトコルはＳＯＡＰであることを特徴とする請求項１に記載の情報処理方法。
【請求項３】
前記添付ファイル付きメッセージはMIME multi-part形式であることを特徴とする請求項１に記載の情報処理方法。
【請求項４】
前記構築工程は、前記メッセージに含まれる要素に基づいて木構造のデータを構築することを特徴とする請求項１に記載の情報処理方法。
【請求項５】
テキストベースの構造言語用のアプリケーションインターフェイスに適応したデータ構造を有するデータから添付ファイル付きメッセージを生成する情報処理方法であって、
前記データ構造に基づいて、前記データの各要素からテキストベースの構造言語をベースとしたメッセージを生成する生成工程と、
前記データがコンテンツデータを参照する要素を有する場合、前記生成工程で生成されたメッセージを添付ファイル付きメッセージの一部に組み込む第１組み込み工程と、
前記データがコンテンツデータを参照する要素を有する場合、前記要素が参照するコンテンツデータの実体を取得し、これを添付ファイルとして前記添付ファイル付きメッセージの一部に組み込み、前記要素に対応する前記メッセージ内の要素に前記添付ファイルを参照するための情報を記録する第２組み込み工程とを備えることを特徴とする情報処理方法。
【請求項６】
前記データ構造は要素をノードとする木構造であることを特徴とする請求項５に記載の情報処理方法。
【請求項７】
テキストベースの構造言語をベースとしたメッセージ交換のためのプロトコルで通信される添付ファイル付きメッセージを処理する情報処理装置であって、
前記添付ファイル付きメッセージから、前記メッセージと前記添付ファイルを分離する分離手段と、
前記添付ファイルを記憶する記憶手段と、
前記メッセージに含まれる要素を用いて、前記構造言語用のアプリケーションプログラミングインターフェイスに適応した構造を有するデータを構築する構築手段と、
前記メッセージに含まれる各要素に基づいて、前記構築手段で構築されたデータの各要素に型情報を付与する付与手段と、
前記付与手段で添付ファイルの参照を示す型情報が付与された要素に、当該要素にリンクされている添付ファイルの前記記憶手段における格納場所を示す情報を付加する付加手段とを備えることを特徴とする情報処理装置。
【請求項８】
テキストベースの構造言語用のアプリケーションインターフェイスに適応したデータ構造を有するデータから添付ファイル付きメッセージを生成する情報処理装置であって、
前記データ構造に基づいて、前記データの各要素からテキストベースの構造言語をベースとしたメッセージを生成する生成手段と、
前記データがコンテンツデータを参照する要素を有する場合、前記生成手段で生成されたメッセージを添付ファイル付きメッセージの一部に組み込む第１組み込み手段と、
前記データがコンテンツデータを参照する要素を有する場合、前記要素が参照するコンテンツデータの実体を取得し、これを添付ファイルとして前記添付ファイル付きメッセージの一部に組み込み、前記要素に対応する前記メッセージ内の要素に前記添付ファイルを参照するための情報を記録する第２組み込み手段とを備えることを特徴とする情報処理装置。
【請求項９】
請求項１乃至６のいずれかに記載の情報処理方法をコンピュータに実行させるための制御プログラム。
【請求項１０】
請求項９に記載の制御プログラムを格納したことを特徴とする記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータファイルの処理方法に関し、特にＷｅｂサービスにおいて用いられる添付ファイル付きのＳＯＡＰ（Simple Object Access Protocol）メッセージ等の処理に好適なものである。
【背景技術】
【０００２】
今日ではコンピュータネットワークが普及したことにより、様々なサービスがコンピュータネットワークを介して提供されている。現在、とりわけ世界的に注目され、利用されている技術として、Ｗｅｂサービス関連技術があげられる。ＷｅｂサービスとはＨＴＴＰに代表される様々な通信プロトコルを利用して、人間の手を介さすにコンピュータ同士がデータを動的に交換するしくみである。Ｗｅｂサービスでは、通信プロトコル上をＳＯＡＰメッセージが流れることにより、様々なコンピュータ機器や組み込み機器等が同時に異なる情報を受け取ることができるようになっている。
【０００３】
ＳＯＡＰメッセージはＸＭＬ（Extensible Markup Language）で構成されているため、画像などのバイナリデータを送ろうとした場合には工夫が必要である。一般的には、base64等に基づいてバイナリデータを文字列に変換してＸＭＬに組み込む方法（以下、文字列変換方式という）、もしくは、MIME multi-partなどの添付ファイルを利用する方法（以下、添付ファイル方式という）の２種類が利用されている。
【０００４】
文字列変換方式では、バイナリデータを文字列に変換する際、又、文字列をバイナリに復元する際に、バイナリデータの大きさに応じて処理時間がかかってしまうという課題がある。よって大容量のバイナリデータをＳＯＡＰメッセージと共に送受信したい場合には、後者の添付ファイル方式を利用するのがより一般的である。
【０００５】
添付ファイル方式では、ＨＴＴＰ等の通信プロトコル上のメッセージにおいて、仕様で決められた区切り文字列によってＳＯＡＰメッセージと添付ファイルの区画に分け、これらを通信プロトコル上の一つのメッセージとして送信する。添付ファイル方式は、添付ファイルを付加する際には、バイナリデータはバイナリのままメッセージ中に添付することが可能である。このため、添付ファイル方式は、バイナリデータを文字列に変換したり、文字列からバイナリデータを復元したりするというような処理が不要であり、文字列変換方式と比較して処理効率がいいという長所を有する。
【０００６】
一方、添付ファイル方式では通信プロトコル上を流れるメッセージはＳＯＡＰメッセージをMIME multi-partなどの添付ファイル用のメッセージフォーマットとして非ＸＭＬフォーマットで包むことになる。そのため、ＸＭＬだけを扱えるように設計されたアプリケーションやライブラリでは添付ファイル方式のメッセージを処理することができないという課題を有する。また、WS-BPELやXPathなどのＸＭＬだけを扱うような仕様においても、添付ファイル方式で生成されたメッセージは全体がＸＭＬとしての構造を有していないので不都合が生じてしまう。
【０００７】
通常、ＸＭＬを扱うプログラムやライブラリ等は、Ｗ３Ｃで定義されたＤＯＭ（Document Object Model）インターフェイスを利用してプログラミングされる。ＤＯＭはＸＭＬデータへのプログラムからのアクセスを標準化したインターフェイスである。ＤＯＭインターフェイスをサポートしているプログラムやライブラリであれば、データを直接受け渡したり、直接受け渡せないまでも容易に変換して利用することが可能となる。
【０００８】
ＤＯＭインターフェイスはＸＭＬの木構造をたどって処理を行うことができるので、汎用的にＸＭＬで利用することが可能である。ところが、前述したような添付ファイルつきのメッセージは、ＳＯＡＰメッセージがＸＭＬとして中身の一部に入ってはいるが、全体としてはMIME multi-partのような添付ファイルを表現するメッセージ形態となっている。そのため、ＤＯＭインターフェイスでメッセージの全てを操作することは通常不可能である。このような場合、一般には、添付ファイルとＳＯＡＰメッセージを分離して、ＳＯＡＰメッセージ部分のみをＸＭＬとしてＤＯＭインターフェイスとして取り扱う（非特許文献１参照）。
【非特許文献１】http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211
【発明の開示】
【発明が解決しようとする課題】
【０００９】
上述したように、画像などの大容量のバイナリデータをＷｅｂサービスで取り扱う際には、添付ファイル方式を使ってなるべく処理のオーバーヘッドをかけずに通信を行うのが一般的である。しかしながら、このような方法だと、例えば、MIME multi-part形式のメッセージから分離されたSOAPメッセージのみにしかＤＯＭインターフェイスを利用できない。即ち、一般的なＸＭＬの処理方式であるＤＯＭインターフェイスをメッセージの一部にしか利用することができなくなってしまう。ＤＯＭが利用できないということは、汎用的につくられたライブラリを利用できないということであり、プログラムの再利用性を著しく低下させてしまう。また、ＸＭＬを取り扱うことを前提としている、WS-BPELやXPathなどの仕様においても不都合が生じる。よって、ＳＯＡＰを利用したメッセージングにおけるバイナリデータの取り扱いには、著しい開発負荷の増加が生じることが容易に予想される。
【００１０】
本発明は上記の課題に鑑みてなされたものである。即ち、本発明は、テキストベースの構造言語（ＸＭＬ等）をベースとしたメッセージ交換のためのプロトコル（ＳＯＡＰ等）において、添付ファイル方式を採用しながらもＤＯＭのような標準的なＡＰＩ（Application Programming Interface）をメッセージ全体に利用可能にすることを目的とする。
【課題を解決するための手段】
【００１１】
上記の目的を達成するための本発明の一態様による情報処理方法は、
テキストベースの構造言語をベースとしたメッセージ交換のためのプロトコルで通信される添付ファイル付きメッセージを処理する情報処理方法であって、
前記添付ファイル付きメッセージから、前記メッセージと前記添付ファイルを分離する分離工程と、
前記添付ファイルをメモリに記憶する記憶工程と、
前記メッセージに含まれる要素を用いて、前記構造言語用のアプリケーションプログラミングインターフェイスに適応した構造を有するデータを構築する構築工程と、
前記メッセージに含まれる各要素に基づいて、前記構築工程で構築されたデータの各要素に型情報を付与する付与工程と、
前記付与工程で添付ファイルの参照を示す型情報が付与された要素に、当該要素にリンクされている添付ファイルの前記メモリにおける格納場所を示す情報を付加する付加工程とを備える。
【００１２】
また、上記の目的を達成するための本発明の他の態様による情報処理方法は、
テキストベースの構造言語用のアプリケーションインターフェイスに適応したデータ構造を有するデータから添付ファイル付きメッセージを生成する情報処理方法であって、
前記データ構造に基づいて、前記データの各要素からテキストベースの構造言語をベースとしたメッセージを生成する生成工程と、
前記データがコンテンツデータを参照する要素を有する場合、前記生成工程で生成されたメッセージを添付ファイル付きメッセージの一部に組み込む第１組み込み工程と、
前記データがコンテンツデータを参照する要素を有する場合、前記要素が参照するコンテンツデータの実体を取得し、これを添付ファイルとして前記添付ファイル付きメッセージの一部に組み込み、前記要素に対応する前記メッセージ内の要素に前記添付ファイルを参照するための情報を記録する第２組み込み工程とを備える。
【発明の効果】
【００１３】
本発明によれば、テキストベースの構造言語をベースとするメッセージ交換用のプロトコルにおいて、添付ファイル方式を採用しながらもテキストベースの構造言語に対応した標準的なＡＰＩをメッセージ全体に利用することができる。
【発明を実施するための最良の形態】
【００１４】
以下、添付の図面を参照して本発明の好適な実施形態を説明する。
【００１５】
図１Ａは本実施形態によるネットワークシステムの構成例を示す図である。ネットワークシステムはＷｅｂサービスを提供する機能を有するサーバ１００と、Ｗｅｂサービスを利用する機能を有するクライアント２００とを含む。サーバ１００とクライアント２００はインターネットやＬＡＮ等のネットワーク３００を介して接続されている。サーバ１００とクライアント２００との間の通信（メッセージの交換）は、ネットワーク３００を介して、例えばＳＯＡＰメッセージを用いて行われる。尚、サーバ１００とクライアント２００は一般的なコンピュータ装置や、ネットワーク機能を有するプリンタやカメラ等の周辺機器装置、または携帯電話やネットワーク機能を有するＰＤＡ等の情報端末装置で実現することができる。
【００１６】
図１Ｂは、本実施形態によるサーバ及びクライアントの構成例を説明する図である。本実施形態では、サーバ１００、クライアント２００として一般的な情報処理装置（コンピュータ装置）を用いた場合を説明する。
【００１７】
図１Ｂにおいて、１はアプリケーションプログラムによって処理中のデータの情報、各種メッセージメニューなどを表示するＣＲＴを示している。２はＣＲＴ１の画面に表示されるイメージを展開するビデオＲＡＭ（以下、ＶＲＡＭ）を示している。３及び４は、画面上の所定欄に文字などを入力したり、アイコンやＧＵＩにおけるボタンなどを指し示すためなどに用いられるキーボード及びポインティングデバイスをそれぞれ示す。５は本装置全体の制御を司るＣＰＵである。
【００１８】
６はＣＰＵ５の動作処理手順（プログラム）を記憶しているＲＯＭである。なおこのＲＯＭ６にはデータ処理に係るアプリケーションプログラムやエラー処理プログラムをはじめ、後述するフローチャートに係るプログラムも記憶されている。７は上述した各種プログラムをＣＰＵ５が実行する時のワークエリア、エラー処理時の一時退避エリアとして用いられるＲＡＭを示している。
【００１９】
９はハードディスクドライプ（以下、ＨＤＤ）、１０はフロッピー（登録商標）ディスクドライプ（以下、ＦＤＤ）をそれぞれ示し、それぞれのディスクはアプリケーションプログラムやデータ、ライプラリなどの保存及び読み込み用に用いられる。また、ＦＤＤの替わりに、あるいは追加してＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等の光（磁気）ディスクドライブや、テープストリーマ、ＤＤＳなどの磁気テープドライブ等を設けてもよい。
【００２０】
１０は装置をネットワークに接続するためのネットワークインターフェイスである。１１は上述した各ユニット間を接続する１／０バス（アドレスバス、データバスおよび制御バスからなる）である。以下で説明する処理は、ＣＰＵ５がＲＯＭ６に記憶されているプログラムを実行することで実現される。或は、ハードディスクドライブ９やフロッピー（登録商標）ディスクドライブ１０からＲＡＭ７にロードされたプログラムをＣＰＵ５が実行することにより実現されるようにしてもよい。
【００２１】
図２は本実施形態のサーバ１００とクライアント２００の間におけるＳＯＡＰメッセージの通信を模式的に表した図である。クライアント２００はＷｅｂサービスを利用する立場であり、利用するサービスに必要なＳＯＡＰメッセージ３００をサーバ１００に送信する。このとき、ＳＯＡＰメッセージ３００がバイナリファイルを有する場合は、添付ファイル方式に従って、バイナリファイル３０１もサーバ１００へ送信される。
【００２２】
又、サーバ１００は、クライアント２００からのＳＯＡＰメッセージ３００に従ってＷｅｂサービスを実行し、その結果であるＳＯＡＰメッセージ３０２をクライアント２００に返す。その際、ＳＯＡＰメッセージ３０２にはバイナリファイル３０３の添付が必要な場合がある。ＳＯＡＰメッセージ３００，３０２はＸＭＬドキュメントの一つである。ＸＭＬは構造化されたデータをテキストで表現したものなので、本来、バイナリデータをＸＭＬ中に入れることは出来ない。従って、上述したように、文字列変換方式、添付ファイル方式のいずれかによりバイナリデータを付加する。添付ファイル方式では、MIME multi-part等の形式を用いてバイナリデータをバイナリファイルとして添付するので、バイナリデータを文字列に変換する処理が不要となり、文字列変換方式に比べて効率的である。一方、上述したように、MIME multi-part等の添付ファイルの形式を用いると、ＸＭＬのデータ構造とは別のデータ構造になってしまうため、ＸＭＬに対応したＤＯＭのようなＡＰＩを利用できなくなる。本実施形態では、添付ファイル方式のこのような欠点を補うＳＯＡＰメッセージの処理方法を示す。尚、以下では、添付ファイル方式のＳＯＡＰメッセージを添付ファイル付きＳＯＡＰメッセージという。
【００２３】
図３は本実施形態のサーバ１００（情報処理装置）内部における、ＳＯＡＰメッセージ処理（情報処理）にかかるソフトウェアの構成例を模式的に示したブロック図である。
【００２４】
通信プロトコル処理部４００は、ＨＴＴＰなどのＳＯＡＰメッセージを乗せる通信プロトコルの送受信を行う。又、通信プロトコル４００は、受信した添付ファイル付きＳＯＡＰメッセージをメッセージ本体とメッセージヘッダ等へ分離する等の処理を行ない、ＳＯＡＰメッセージ処理部５００にＳＯＡＰメッセージを渡す。ＳＯＡＰメッセージ処理部５００は、ＳＯＡＰメッセージを後述するデータモデル構造に展開したり、データモデル構造を有するデータをＳＯＡＰメッセージに変換したりする。ＳＯＡＰメッセージ処理部５００によりデータモデル構造に展開されたＳＯＡＰメッセージは、アプリケーション処理部６００に渡される。アプリケーション処理部６００は、サーバ１００がＷｅｂサービスとして提供する処理をＳＯＡＰメッセージ処理部５００より渡されたＳＯＡＰメッセージに施し、その結果をＳＯＡＰメッセージ処理部５００に渡す。ＳＯＡＰメッセージ処理部５００は、アプリケーション処理部６００から渡された、データモデル構造のデータをＳＯＡＰメッセージ（添付ファイル付きＳＯＡＰメッセージ）に変換する。ＳＯＡＰメッセージに変換されたメッセージは、通信プロトコル処理部４００に戻され、クライアントへＨＴＴＰなどの通信プロトコルを利用して送信（返信）返答される。
【００２５】
図４は添付ファイル付きＳＯＡＰメッセージを模式的に表した図である。添付ファイル付きＳＯＡＰメッセージ７００におけるＳＯＡＰメッセージ７０２や添付ファイル７０７，７０９の各コンテンツには、それぞれ、Content-ID７０１、７０６、７０８が付与されている。ＳＯＡＰメッセージ７０２中のＳＯＡＰボディ７０３に含まれる要素７０４、７０５は、各添付ファイルのContent-Id７０６、７０８の値をＵＲＩで参照することにより、ＳＯＡＰメッセージと添付ファイル７０７，７０９は関連付けされている。
【００２６】
図５は図３で示したＳＯＡＰメッセージ処理部５００の詳細構成を表したブロック図である。
【００２７】
ＳＯＡＰメッセージ受信部５０１で通信プロトコル処理部４００よりＳＯＡＰメッセージを受け取り、それをデータモデル構築部５０３に渡す。データモデル構築部５０３は、ＳＯＡＰメッセージ受信部５０１より受け取ったテキスト形式のＳＯＡＰメッセージを、後述するデータ構造を有するデータモデルとしてメモリ（例えば、ＲＡＭ７）上に展開する。その際にデータ型管理部５０７に予め登録されている型情報に基づいて、ＳＯＡＰメッセージの各要素に型情報が付加される。又、データモデル構築部５０３は、ＳＯＡＰメッセージ受信部５０１から送られてきたＳＯＡＰメッセージが添付ファイル付きＳＯＡＰメッセージであった場合は、当該メッセージから添付ファイルを分離する。そして、データモデル構築部５０３は、分離した添付ファイルを一時保存領域５０５に保存すると共に、添付ファイルの保存場所と添付ファイルのContent-IDとの関連を添付ファイル管理部５０６に登録する。尚、一時保存領域５０５及び添付ファイル管理部５０６はＲＡＭ７に構成されるものとする。
【００２８】
データモデル構築部５０３で構築されたデータはアプリケーション処理部６００に渡され、サーバ１００で提供されるサービス処理が行われる。そして、その処理結果が添付ファイル付きＳＯＡＰメッセージ構築部５０４に送られる。添付ファイル付きＳＯＡＰメッセージ構築部５０４は、データモデルに記述されている添付ファイルの情報またはContent-IDから、添付ファイル管理部５０６を利用して添付ファイルの場所を特定し、一時保存領域５０５より添付ファイルを取得する。そして、添付ファイル管理部５０６は、添付ファイルのデータ形式にＳＯＡＰメッセージを整形してＳＯＡＰメッセージ送信部５０２に整形されたＳＯＡＰメッセージを送信する。ＳＯＡＰメッセージ送信部５０２は、添付ファイル付きＳＯＡＰメッセージ構築部５０４から受け取ったメッセージを、図３で示した通信プロトコル処理部４００に渡す。通信プロトコル処理部４００は、このＳＯＡＰメッセージをクライアントに対して送信することにより、クライアントから送信されたＳＯＡＰメッセージに対して返答を行う。
【００２９】
図６Ａは、データモデル構築部５０３で構築されるデータモデルのデータ構造を説明する図である。Elementインターフェイス８００はＷ３Ｃで定義され、標準化されているＤＯＭのインターフェイス（ＸＭＬデータへのプログラムからのアクセスを標準化したインターフェイス）である。型情報付きElementクラス８０１はElementインターフェイスを実装している。型情報付きElementクラス８０１は型情報８０２を集約しており、これにより要素毎に値の型を認識することが可能となる。又、添付ファイル型Element８０３はファイルのパスを抽象表現したFileクラス８０４を集約している。添付ファイル型Element８０３は型情報付きElement８０３の子クラスになっており、型情報８０２を保持できると共に、File８０４への参照も保持することが可能である。
【００３０】
図７は、図５のデータモデル構築部５０３の制御手順を示したフローチャートである。データモデル構築部５０３はＳＯＡＰメッセージを通信プロトコル処理部４００より受信すると（ステップＳ７０１）、そのＳＯＡＰメッセージが通常のＳＯＡＰメッセージの形式か添付ファイル形式（例えば、MIME multi-part）かを判断する（ステップＳ７０２）。添付ファイル形式、即ち、添付ファイル付きＳＯＡＰメッセージであると判断された場合は、当該メッセージをＳＯＡＰメッセージ部と添付ファイルへ分離する（ステップＳ７０３）。例えば添付ファイル付きＳＯＡＰメッセージ７００は、ＳＯＡＰメッセージ７０２と添付ファイル７０７，７０９に分離される。そして、データモデル構築部５０３は、添付ファイルを一時保存領域５０５に保存し（ステップＳ７０４）、その添付ファイルの一時保存領域５０５における保存場所とContent-Idをファイル管理部５０６に登録する（ステップＳ７０５）。例えば、添付ファイル７０７は一時保存領域５０５に保存され、その保存場所とContent-IDであるexample1との対応が添付ファイル管理部５０６に登録される。同様に、添付ファイル７０９も一時保存領域５０５に保存され、その保存場所とContent-IDであるexample2との対応が添付ファイル管理部５０６に登録される。尚、ステップＳ７０２で通常のＳＯＡＰメッセージであると判断された場合は、処理はステップＳ７０６へ直接進む。
【００３１】
ステップＳ７０６では、分離されたＳＯＡＰメッセージ７０２のＳＯＡＰボディ７０３に含まれている各要素の型をデータ型管理部５０７に予め登録してある情報を参照して判断する。そして、前述したデータモデルのデータ構造に沿って型情報を保有しているＤＯＭインターフェイス準拠のデータ（この型情報を保有しているＤＯＭインターフェイスに適応した構造を有するデータ）を構築する（ステップＳ７０７）。以上のようにして構築されたデータモデルは、各要素に型情報が付与されたものとなる。
【００３２】
この様子を図６Ｂに示す。図６Ｂは図４に示したＳＯＡＰボディ７０３の要素を図６Ａに示したデータモデル構造に従って展開した例を示す図である。〈operation〉、〈int_value〉等の要素が木構造（本実施形態では、ＤＯＭツリー）に展開されており、各要素７５２〜７５５の各々には型情報が付与されている。データ型管理部５０７にはＳＯＡＰ（ＸＭＬ）における要素名（及び／又は属性）とデータモデルにおける型情報との対応が登録されている。データモデル構築部５０３はデータ型管理部５０７を参照することによりＳＯＡＰボディ７０３の各要素に対応する型情報を取得し、各要素に型情報を付与することができる。即ち、ＸＭＬの要素名及び／又は属性に基づいて型情報が付与される。
【００３３】
次に、構築したデータモデルを調べ、添付ファイル型の要素があるかどうかを判断する（ステップＳ７０８）。添付ファイル型の要素があった場合には、その要素のContent-IDを有するコンテンツ（添付ファイル）の保存場所を添付ファイル管理部５０６を参照して調べる。そして、その保存場所をFileクラス８０４のインスタンスとして添付ファイル型の要素に関連付ける（ステップＳ７０９）。例えば、図６Ｂに示されるように、要素７５４、７５５には添付ファイル形を示す型情報が付与されている。従って、データモデル構築部５０３は、それぞれの要素のContent-ID（example1,example2）により、添付ファイル管理部５０６から各コンテンツ（添付ファイル）の一時保存領域５０５における格納場所を取得し、インスタンス７５８，７５９として関連付ける。尚、インスタンス７５８，７５９として、Content-ID（example1,example2）を記述してもよい。一方、データモデルに添付ファイル型の要素が無い場合は、ステップＳ７０９をスキップしてステップＳ７１０に進む。
【００３４】
以上のようにして、データモデル構築部５０３はデータモデルを生成し、データモデルをアプリケーション処理部６００に渡す。こうして、ＤＯＭインターフェイスに準拠し、また拡張部分により添付ファイルの情報を付加したデータモデルで、アプリケーションは通常のＤＯＭを利用したＸＭＬと同様の手順で当該ＳＯＡＰメッセージを処理することが可能となる。
【００３５】
なお、添付ファイル型はＸＭＬスキーマの新しい型を定義してもよいが、WS-I Attachment Profileで定義されているswaRef型で代用することが可能である。すなわち、ＳＯＡＰメッセージ中にswaRef型の添付ファイル参照を用いることが可能である。swaRef型を利用するとWS-I Attachment Profileに準拠した添付ファイルのメッセージングが可能となる。
【００３６】
次に、添付ファイル付きＳＯＡＰメッセージ構築部５０４の処理を説明する。図８は、図５で示した添付ファイル付きＳＯＡＰメッセージ構築部５０４の制御手順を示したフローチャートである。
【００３７】
添付ファイル付きＳＯＡＰメッセージ構築部５０４は、アプリケーション処理部６００よりデータモデルを受信すると、ＤＯＭインターフェイスよりＸＭＬの情報を取得してＸＭＬの文字列にデータモデルを変換する（ステップＳ８０１）。次に、ＸＭＬの文字列に変換したデータをＳＯＡＰメッセージのエンベロープの中に追加し、通常のＳＯＡＰメッセージを構築する（ステップＳ８０２）。例えば、添付ファイル付きＳＯＡＰメッセージ構築部５０４は、図６Ｂのようなデータモデル構造のデータを受信すると、これをＸＭＬに変換してＳＯＡＰボディ７０３を生成する。そして、生成されたＳＯＡＰボディ７０３をＳＯＡＰメッセージのエンベロープの中に入れて、ＳＯＡＰメッセージ７０２を生成する。この時点で、ファイル参照を行う要素（７０４，７０５）には、図６Ｂのインスタンス７５８，７５９に従って、Content-idが記述される。尚、インスタンス７５８，７５９にContent-idが記述されていれば、これをそのまま利用する。又、インスタンス７５８，７５９にデータ（添付ファイル）の格納場所が記述されている場合は、添付ファイル管理部５０６から格納場所に対応した添付ファイルのContent-idが取得され、要素７０４，７０５に記述される。
【００３８】
次に、受信したデータモデルの各要素のデータ型を判別し、添付ファイル型の要素があるかどうかを判別する（ステップＳ８０３）。添付ファイル型があると判断された場合は、添付ファイル形式（例えばMIME multi-part形式）データとして、ステップＳ８０２で構築したＳＯＡＰメッセージを追加する（ステップＳ８０４）。次に、その添付ファイル形式の要素が指定するContent-idのコンテンツ（ファイル）の保存場所を添付ファイル管理部５０６から取得する。そして、取得した保存場所に従って一時保存領域５０５から対応するコンテンツを取得し、取得したコンテンツを添付ファイルとして上記添付ファイル形式データに追加する。こうして、添付ファイル形式のＳＯＡＰメッセージが構築される。そして、ＳＯＡＰメッセージ送信部５０２は、添付ファイル着きＳＯＡＰメッセージ構築部５０４で構築されたＳＯＡＰメッセージを通信プロトコル処理部４００に渡す（ステップＳ８０６）。
【００３９】
例えば、図６Ｂに示されるように、添付ファイル付きＳＯＡＰメッセージ構築部５０４は、添付ファイル型の要素７５４，７５５が存在する場合は、添付ファイル付きＳＯＡＰメッセージ７００にＳＯＡＰメッセージ７０２を組み込む。ここで、インスタンス７５８，７５９にコンテンツのＩＤ（Content-id）が登録されていれば、Content-idに対応するコンテンツ（添付ファイル）の格納場所は添付ファイル管理部５０６を参照して取得することができる。添付ファイル付きＳＯＡＰメッセージ構築部５０４は、その格納場所からコンテンツの実体を取得し、これを添付ファイル（７０７，７０９）として、そのContent-id（７０６，７０８）とともに添付ファイル付きＳＯＡＰメッセージ７００に組み込む。又、インスタンス７５８，７５９に格納場所が記述されている場合は、当該格納場所からコンテンツを取得し、添付ファイル７０７，７０９として添付ファイル付きＳＯＡＰメッセージ７００に組み込むことができる。この場合、その格納場所に対応するContent-idが添付ファイル管理部５０６から取得され、メッセージ７００のContent-ID（７０６，７０８）として記述される。
【００４０】
一方、データモデルに添付ファイル型のエレメントが無い場合には、ＳＯＡＰメッセージを添付ファイル形式に加工することは行わない。即ち、添付ファイル付きＳＯＡＰメッセージ構築部５０４は、ステップＳ８０２で生成したＳＯＡＰメッセージをそのままＳＯＡＰメッセージ送信部５０２に渡す。ＳＯＡＰメッセージ送信部５０２は、このＳＯＡＰメッセージを通信プロトコル処理部４００に渡す（ステップＳ８０６）。
【００４１】
通信プロトコル処理部４００は、以上のようにして構築されたＳＯＡＰメッセージ（或は、添付ファイル付きＳＯＡＰメッセージ）をクライアントに送信する。こうして、クライアントに添付ファイル付きもしくは通常のＳＯＡＰメッセージを返答することが可能となる。
【００４２】
以上の図７、図８のフローチャートで示した制御手順を実行することにより、バイナリデータの文字列化を行うことなく、添付ファイル付きＳＯＡＰメッセージを、例えばＤＯＭインターフェイスを利用して操作することができる。
又、本実施形態によるデータ処理方法によれば、バイナリデータをＤＯＭインターフェイスを有するデータモデルの内部にリンクさせることが可能になる。そのため、バイナリデータを文字列に変換するようなオーバーヘッドをかけることなく、かつ、通常のＸＭＬの処理方法であるＤＯＭを処理するインターフェイスを利用して、添付ファイル付きＳＯＡＰ目セージにＷｅｂサービスを施すことが可能となる。また、本実施形態はＤＯＭインターフェイスをもつ外部ライブラリに関しても、データモデルを変更することなく利用することが可能となる。
【００４３】
以上のように、上記実施形態によれば、添付ファイル付きＳＯＡＰメッセージによりバイナリファイルを取り扱うのに適したＷｅｂサービスシステムを実現できる。又、上記実施形態によれば、サーバがバイナリファイル付きのＳＯＡＰメッセージを用いてＷｅｂサービス機能を提供する場合に、汎用的なＸＭＬの処理方法を用いることができる。
【００４４】
尚、上記実施形態ではテキストベースの構造言語としてＸＭＬ、テキストベースの構造言語をベースとするメッセージ交換用のプロトコルをＳＯＡＰ、テキストベースの構造言語に対するＡＰＩとしてＤＯＭを用いて説明したがこれらに限られるものではない。
【００４５】
本発明の目的は前述した実施例の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵまたはＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００４６】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。
【００４７】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施例の機能が実現される形態には限らない。すなわち、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているOperating System（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【００４８】
更に、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【図面の簡単な説明】
【００４９】
【図１Ａ】実施形態による、Ｗｅｂサービスを実現するネットワークシステムの構成例を示す図である。
【図１Ｂ】実施形態によるクライアント及びサーバ装置のハードウェア構成例を示すブロック図である。
【図２】実施形態によるサーバ１００とクライアント２００間の通信を模式的に表した図である。
【図３】実施形態のサーバ１００におけるソフトウェアの構成を模式的に示したブロック図である。
【図４】添付ファイル付きＳＯＡＰメッセージのデータ構成例を模式的に表した図である。
【図５】ＳＯＡＰメッセージ処理部５００の詳細構成を表したブロック図である。
【図６Ａ】本実施形態で利用するデータモデルのデータ構造を表現したモデルの模式図である。
【図６Ｂ】図４に示したＳＯＡＰボディの要素をデータモデル構造に展開した例を示す図である。
【図７】実施形態によるデータモデル構築部の制御手順を示したフローチャートである。
【図８】実施形態による添付ファイル付きＳＯＡＰメッセージ構築部の制御手順を示したフローチャートである。
【図１Ａ】
2007304994.tif 000003
【図１Ｂ】
2007304994.tif 000004
【図２】
2007304994.tif 000005
【図３】
2007304994.tif 000006
【図４】
2007304994.tif 000007
【図５】
2007304994.tif 000008
【図６Ａ】
2007304994.tif 000009
【図６Ｂ】
2007304994.tif 000010
【図７】
2007304994.tif 000011
【図８】
2007304994.tif 000012