通信装置、中継装置及び当該装置におけるメッセージ送受信方法
【課題】 アプリケーションの開発者は、スタブを生成するためにそれぞれの添付方式に対応したインターフェース定義を記述し、それぞれの添付方式に応じたスタブを生成するという非効率な作業を行なう必要があった。
【解決手段】 コンテンツデータを添付したメッセージの送信時、ＷＳＤＬのメッセージ形式で前記コンテンツデータの添付方式に対応するデータ型を指定し、そのデータ型に含まれる複数の添付方式の内、そのコンテンツデータの添付方式を指定するデータ型を、そのメッセージ内のコンテンツデータに対応するパラメータの属性としてメッセージに追加し（Ｓ５０２）、コンテンツデータを添付方式に従ってメッセージに添付する（Ｓ５０３）。そして、メッセージの本文と、添付された添付部分とを合成して送信する（Ｓ５０５）。
【解決手段】 コンテンツデータを添付したメッセージの送信時、ＷＳＤＬのメッセージ形式で前記コンテンツデータの添付方式に対応するデータ型を指定し、そのデータ型に含まれる複数の添付方式の内、そのコンテンツデータの添付方式を指定するデータ型を、そのメッセージ内のコンテンツデータに対応するパラメータの属性としてメッセージに追加し（Ｓ５０２）、コンテンツデータを添付方式に従ってメッセージに添付する（Ｓ５０３）。そして、メッセージの本文と、添付された添付部分とを合成して送信する（Ｓ５０５）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットなどのネットワークを介してテキスト形式の構造化されたメッセージを送受信する通信装置、中継装置及び当該装置におけるメッセージ送受信方法に関する。
【背景技術】
【０００２】
近年、インターネットの普及により、コンピュータやデジタル機器から、ネットワーク上のＷｅｂサービスを利用することが多くなってきている。Ｗｅｂサービスとは、ネットワーク上でオープンな仕様で公開されるソフトウェア部品のことである。一般に、コンピュータ、デジタル機器とＷｅｂサービス間で送受信されるメッセージは、インターネット技術の標準化団体であるＷ３Ｃ（World Wide Web Consortium）で仕様が策定されているＳＯＡＰ等のＸＭＬプロトコルが使用されることが多い。ここでＸＭＬプロトコルとは、Ｗ３Ｃで仕様が規定されているマークアップ言語であるＸＭＬを使って通信内容を記述する通信プロトコルのことである。
【０００３】
ＸＭＬは、構造化データをテキスト形式で記述する言語である。そのため、ＸＭＬプロトコルの仕様だけを使ってＸＭＬ形式のメッセージを送受信する場合に、ＸＭＬ形式のメッセージからリンク参照される画像ファイル等のバイナリ形式のコンテンツデータをバイナリ形式のまま送信することができない。これを解決するために、標準化団体であるＷ３Ｃでは、ＳＯＡＰ自体の仕様の他に、ＳＷＡ（SOAP Messages with Attachments），ＭＴＯＭ（SOAP Message Transmission Optimization Mechanism）など、ＳＯＡＰで送受信するメッセージに画像などのバイナリ形式のコンテンツデータを添付する際の仕様を複数規定している。また、マイクロソフト社やＩＢＭにおいても、かつて独自の添付方式であるＷＳＡ（WS-Attachments）を、標準化団体であるＩＥＴＦのドラフト仕様として提出していた。
【０００４】
このように、ＸＭＬプロトコルで送受信するメッセージにファイルを添付するための仕様が現時点では複数存在するため、アプリケーションがコンテンツデータをメッセージに添付する場合には、送信側、受信側のアプリケーションプログラムが予めどの添付方式を使用すればよいかを知っておく必要がある。
【０００５】
Ｗｅｂサービス間の相互接続性の向上を目的とする標準化団体であるＷＳ−Ｉは、Attachment Profile 1.0という仕様で、添付方式としてＷ３ＣのＳＷＡ（SOAP Messages with Attachments）を用いた例を記述している。ここでは、Ｗｅｂサービス間のインターフェース定義言語（ＷＳＤＬ：Web Service Definition Language）で記述されたインターフェース定義文書において、メッセージを構成するパラメータのどれがＳＷＡ方式で添付したコンテンツデータを参照しているのかを、ｓｗａＲｅｆというパラメータのデータ型で表現する方法を提案している。これにより、そのインターフェース定義文書を参照して、送信側と受信側のアプリケーションを開発し、そのアプリケーションを用いてＳＷＡ方式を用いたメッセージを正しく送受信することができる。尚、ＸＭＬプロトコルを使ってメッセージを交換する送信側及び受信側のアプリケーションは、一般に直接インターフェース記述を参照するのではなく、アプリケーション開発ツールによってインターフェース記述からスタブと呼ばれるメッセージ解釈のためのソフトウェア部品を生成し、それらをアプリケーションプログラムから利用することによってインターフェース定義に従ったメッセージを生成し、それを解釈することが多い。ＷＳＤＬを用いた先行技術として、以下の特許文献１が存在する。
【特許文献１】特開２００４−３４１７３４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上述のAttachment Profile 1.0仕様は、ＳＷＡという添付方式を採用した際のインターフェース定義の仕方を記述している。これによって、アプリケーション開発ツールは、ＳＷＡ方式に対応している送信側及び受信側のアプリケーション用のスタブを生成することができる。しかしながら、受信側がＳＷＡ以外の添付方式を使用していたり、受信側が複数の添付方式を受け付け可能であったりする場合には、上記のインターフェース定義の方法では統一的に記述することができなかった。従って、アプリケーションの開発者は、スタブを生成するためにそれぞれの添付方式に対応したインターフェース定義文書を参照し、それぞれの添付方式に応じたスタブを生成するという非効率な処理を行なう必要があった。そして、送信側装置および受信側装置のそれぞれのメモリに各種類の添付方式に対応したインターフェース記述文書を格納しなければならず、メモリ容量の点からも効率がよくなかった。
【０００７】
また上述のAttachment Profile 1.0仕様では、バイナリ形式のコンテンツデータを添付してメッセージを送受信することを、そのインターフェース定義内のメッセージ形式の定義で論理的に記述していない。上述のAttachment Profile 1.0仕様では、具体的にＳＷＡという添付方式に特化したメッセージ形式として記述する必要があった。そのため、Ｗｅｂサービスのバージョンアップ等、コンテンツデータの添付方式を新しい方式に対応させる必要があるときに、本来プロトコルによらない論理的なメッセージ形式の記述を、新しい添付方式に沿った記述に大幅に書き換える必要がある。
【０００８】
本発明は、上記従来技術の欠点を解決することにある。
【０００９】
また本願発明の特徴は、コンテンツデータの添付方式を、複数の添付方式の中から選択して指定できる通信装置、中継装置及び当該装置におけるメッセージ送受信方法を提供することにある。
【課題を解決するための手段】
【００１０】
上記特徴は、独立クレームに記載の特徴の組み合わせにより達成され、従属項は発明の単なる有利な具体例を規定するものである。
【００１１】
本発明の一態様に係る通信装置は以下のような構成を備える。即ち、
ネットワークを介して接続された通信装置との間で送受信するメッセージとして、バイナリ形式のコンテンツデータを添付したテキスト形式の構造化文書を生成する通信装置であって、
送信側と受信側の通信装置間のウェブサービスのインターフェース定義であって、前記構造化文書に添付可能なコンテンツデータの添付方式を示す複数種類のデータ型を示す抽象データ型の記述を有するインターフェース定義を記憶する記憶手段と、
前記インターフェース定義に記述されたデータ型に対応する添付方式のうち、前記通信装置が対応可能な添付方式でバイナリ形式のコンテンツデータを添付するとともに、バイナリ形式のコンテンツデータを添付した添付方式を示すデータ型を示すメッセージを生成するメッセージ生成手段と、
前記バイナリ形式のコンテンツデータが添付されたメッセージを送信する送信手段と、を有することを特徴とする。
【００１２】
本発明の一態様に係る通信装置は以下のような構成を備える。即ち、
ネットワークを介して接続された通信装置との間で送受信するメッセージとして、バイナリ形式のコンテンツデータを添付したテキスト形式の構造化文書を受信する通信装置であって、
送信側と受信側の通信装置間のウェブサービスのインターフェース定義であって、前記構造化文書に添付可能なコンテンツデータの添付方式を示す複数種類のデータ型を示す抽象データ型の記述を有するインターフェース定義を記憶する記憶手段と、
前記記憶手段に記憶されたインターフェース定義に記述されたデータ型が受信したメッセージに記述されているかどうかを判別する判別手段と、
前記判別手段によって前記記憶手段に記憶されたインターフェース定義に記述されたデータ型が前記受信したメッセージに記述されていると判別された場合、前記変別されたデータ型に対応する添付方式に従って、前記添付されているバイナリ形式のコンテンツデータを抽出する抽出手段と、
前記抽出手段により抽出した前記バイナリ形式のコンテンツデータのパス名を設定してメモリに記憶する記憶制御手段と、
を有することを特徴とする。
【００１３】
尚、この発明の概要は、必要な特徴を全て列挙しているものではない。また、これら特徴群のサブコンビネーションも発明になり得る。
【発明の効果】
【００１４】
本発明によれば、コンテンツデータの添付方式を、複数の添付方式の中から選択して指定できるという効果がある。
【発明を実施するための最良の形態】
【００１５】
以下、添付図面を参照して本発明の好適な実施の形態を詳しく説明する。尚、以下の実施の形態は特許請求の範囲に係る発明を限定するものでなく、また本実施の形態で説明されている特徴の組み合わせの全てが発明の解決手段に必須のものとは限らない。
【００１６】
［実施の形態１］
図１は、本発明の実施の形態１に係る通信システムの構成例を示す図である。
【００１７】
ネットワーク１４０には、メッセージ送信側装置（以下、送信装置）１００とメッセージ受信側装置１２０（以下、受信装置）が接続されている。送信装置１００と受信装置１２０はネットワーク１４０を経由して、ＸＭＬプロトコルの１つであるＳＯＡＰでメッセージを送受信する。ここで、一般的な送信装置１００、受信装置１２０として、パーソナルコンピュータ、サーバコンピュータ、デジタル機器等が考えられる。尚、この実施の形態では、送信装置、受信装置はそれぞれ１つずつしか説明されていないが、それぞれ複数存在しても構わない。
【００１８】
送信装置１００、受信装置１２０には、メッセージに添付するテキストデータ，画像データなどのバイナリ形式のコンテンツデータを保存するための外部記憶装置１１０，１３０がそれぞれ接続されている。本実施の形態では、コンテンツデータはファイルとして説明するが、メモリ上に展開されたデータであってもよいし、ネットワークを経由したＷｅｂサーバ、ストレージサーバ上にあってもよい。なお、外部記憶装置１１０，１３０の代わりとして、送信装置１００、受信装置１２０にメモリを内蔵してもよい。なお、本実施の形態で説明する「スタブ」とは、送受信するメッセージを解釈し、送受信装置アプリケーションにデータを引き渡すプログラムを指す。
【００１９】
次に通信装置である送信装置１００の機能構成を説明する。
【００２０】
送信装置１００は、ネットワーク１４０を経由し、ＸＭＬ形式のアプリケーションデータ及びそこからリンクして参照されているバイナリ形式のコンテンツデータを格納するファイルの送信要求を行なう送信側アプリケーション１０１を有する。さらに、送信装置１００は、送信側アプリケーション１０１からの要求により、アプリケーションデータから、マルチパートＭＩＭＥあるいはＤＩＭＥなどマルチパート形式の送信メッセージを生成する送信側スタブ１０２を有する。さらに、送信装置１００は、送信側スタブ１０２から呼び出され、アプリケーションデータ内の記述を検索し、添付が必要なファイルを読み込む添付ファイル読み込み部１０３を有する。さらに、送信装置１００は、送信側スタブ１０２で作成したメッセージをネットワーク１４０経由で受信装置１２０に送信するメッセージ送信部１０４を有している。
【００２１】
次に通信装置である受信装置１２０の機能構成を説明する。
【００２２】
受信装置１２０は、ネットワーク１４０を経由し、送信装置１００から受信したマルチパートＭＩＭＥ，ＤＩＭＥ等のマルチパート形式のメッセージを受信するメッセージ受信部１２４を有する。また、受信装置１２０は、メッセージ受信部１２４が受信したメッセージを解析して複数のパートに分解し、コンテンツデータのパートを添付ファイル書き出し部１２３により外部記憶装置１３０に保存する処理を行なう受信側スタブ１２２を有する。また、受信装置１２０は、この受信側スタブ１２２によってメッセージから取り出されたアプリケーションデータを渡す先である受信側アプリケーション１２１を有している。尚、図１及び以下に示す図面において、各機能を実行する部は、本実施の形態ではソフトウェアにより実現されているが、これら各部は専用のＬＳＩ等を採用したハードウェアにより構成されていても良い。
【００２３】
なお、説明の簡略化のため上記のとおり送信装置１００および受信装置１２０を分けて説明したが、実際は送信装置１００，受信装置１２０はそれぞれ受信装置１００，送信装置１２０を兼用することになる。
【００２４】
次に図２を使用して、本実施の形態に係るアプリケーション開発装置の構成例を説明する。このアプリケーション開発装置は、前述の送信装置１００や受信装置１２０で実行されるアプリケーションを開発するための装置である。なお、送信装置１００および受信装置１２０がこのアプリケーション開発装置の機能を兼用してもよい。この場合、インターフェース定義２２１は外部記憶装置１００，１３０に記憶される。
【００２５】
図２は、本実施の形態１に係るアプリケーション開発装置２１０の機能構成を説明する機能ブロック図である。尚、図２においても、各機能を実行する部は、本実施の形態ではソフトウェアにより実現されているが、これら各部は専用のＬＳＩ等を採用したハードウェアにより構成されていても良い。
【００２６】
このアプリケーション開発装置２１０は、送信装置１００と受信装置１２０間で送受信するメッセージの構成の定義を記述した文書であるインターフェース定義２２１を保存する外部記憶装置２２０と接続されている。尚、この実施の形態では、インターフェース定義２２１はファイルとして説明するが、メモリ上に展開されたデータであってもよい。また、インターフェース定義２２１は、ネットワークを経由したＷｅｂサーバ、ストレージサーバ上にあってもよい。
【００２７】
次にアプリケーション開発装置２１０の機能構成を説明する。インターフェース定義読み込み部２１２は、インターフェース定義を記述した文書からスタブと呼ばれるメッセージ解釈のためのソフトウェアを生成するスタブ生成部２１３からの要求により、外部記憶装置２２０に保存されているインターフェース定義２２１を読み込む。データ型定義解析部２１４は、インターフェース定義読み込み部２１２により読み込んだインターフェース定義２２１のデータ型定義部からバイナリ添付方式を表す抽象データ型の定義を抽出する。そして、データ型定義解析部２１４は、この抽象データ型がどのデータ型の結合として派生されているかを解析する。添付方式判断部２１１は、データ型定義解析部２１４で解析した結合されているデータ型名と、データ型・添付方式対応テーブル２１５の内容とから、送信側及び受信側スタブ１０２，１２２で使用するバイナリ形式のコンテンツデータの添付方式を決定する。
【００２８】
次に図３、図７及び図９を使用して、構造化文書生成装置としての本実施の形態に係るアプリケーション開発装置２１０における送信側スタブ１０２の生成処理を説明する。
【００２９】
図３は、本発明の実施の形態１に係るアプリケーション開発装置２１０で送信側スタブ１０２を生成する際の制御手順を説明するフローチャートである。
【００３０】
スタブ生成部２１３が、アプリケーション開発者などの要求により、送信側スタブ１０２を生成する指示を検出すると、まずステップＳ３０１で、インターフェース定義読み込み部２１２により外部記憶装置２２０からインターフェース定義２２１を読み込む。
【００３１】
図７は、ＷＳＤＬで記述されたウェブサービスのインターフェース定義の一例を示す図である。
【００３２】
次にステップＳ３０２で、インターフェース定義読み込み部２１２は、インターフェース定義２２１内のデータ型定義部７００（図７）を参照し、添付するコンテンツデータの仕様を表す抽象データ型（図７の７０２で示す「binaryRef」型）が定義されているかどうか判断する。定義されていた場合はステップＳ３０３に進み、添付方式判断部２１１は、データ型定義部７００の定義から、抽象データ型（binaryRef型）がどのようなデータ型を結合して派生しているのか抽出してデータ型名をリスト化する。尚、ステップＳ３０２で、添付先を示すデータ型が定義されていなかった場合、添付方式判断部２１１は、バイナリ形式のコンテンツデータを添付しないメッセージであると判断してステップＳ３０８にスキップする。
【００３３】
図７の例では、記述７０７で示すように、binaryRef型は、ＳＷＡ方式でコンテンツデータを参照するのに使用するデータ型（swaRef型）７０３、ＷＳＡ方式でコンテンツデータを参照するのに使用するデータ型（wsaRef型）７０４、ＭＴＯＭ方式でコンテンツデータを参照するのに使用するデータ型（mtomRef型）７０５を結合した抽象型として記述されている。
【００３４】
ステップＳ３０３で、添付方式判断部２１１は、添付方式に対応するデータ型のリストを作成する。図７の例では、ＳＷＡ方式でコンテンツデータを参照するデータ型（swaRef型）７０３、ＷＳＡ方式でコンテンツデータを参照するデータ型（wsaRef型）７０４、ＭＴＯＭ方式でコンテンツデータを参照するデータ型（mtomRef型）７０５がリストアップされる。次にステップＳ３０４で、データ型・添付方式対応テーブル２１５を参照して、ステップＳ３０３でリストアップされた各データ型に対応する添付方式を特定する。次にステップＳ３０５で、そのリストの最後のデータ型でないときはステップＳ３０６に進み、リストの前から順番にこの添付方式が送信装置１００で対応しているかどうか判断する。ここで対応している場合はステップＳ３０７に進むが、対応していない場合はステップＳ３０４に戻る。
【００３５】
図９は、本実施の形態に係るデータ型・添付方式対応テーブル２１５の一例を示す図である。
【００３６】
この図９では、データ型の名前空間ＵＲＩ（図７の７０３〜７０５）に対して、そのデータ型名、添付方式が登録されている。データ型・添付方式対応テーブル２１５を参照することにより、データ添付方式を表すswaRef型、wsaRef型、mtomRef型はSWA方式、WSA方式、MTOM方式に相当すると判断される。
【００３７】
尚、前述のステップＳ３０６で、送信装置１００がその添付方式に対応しているか否かの判断基準は、スタブ生成部２１３に記憶された動作環境定義ファイルに、予め送信装置１００が対応している添付方式に関する情報を記述しておく。送信装置１００が対応している添付方式に関する情報は、送信装置１００がバージョンアップによって新たな添付方式が対応可能となるたびに更新される。こうしてステップＳ３０６で、そのリストアップされた添付方式が送信装置１００で対応している場合は、ステップＳ３０７に進み、添付方式判断部２１１は、生成する送信側スタブ１０２で採用する添付方式をその添付方式に決定する。尚、送信装置１００が対応できる添付方式が複数存在する場合を考慮し、データ型定義部７００でデータ型を記述する順序を、開発者が生成させたい優先度順に記述しておき、対応できる添付方式の中から最も先に記述されているデータ型に対応する添付方式に決定する形態も考えられる。この場合、各送信装置１００におけるさらなる送信側スタブの統一化を図ることができる。
【００３８】
次にステップＳ３０８で、スタブ生成部２１３は、インターフェース定義２２１のメッセージ構成定義部（図７の７１０）から、メッセージを構成する次のパラメータを抽出する。図７の例では、「PutImage」の「ImgaeRef」としてパラメータ「type=types:binaryRef」が指定されており、これによりこのパラメータによる添付ファイルの定義が可能であることがわかる。そしてステップＳ３０９で、パラメータが抽出できるとステップＳ３１０に進む。ステップＳ３１０において、そのパラメータのデータ型が添付先参照を表すデータ型であるかどうかを調べ、そうであれば（図７では７０２，７０７で定義されている）ステップＳ３１１に進む。ステップＳ３１１において、ステップＳ３０７で決定した添付方式に従って、マルチパート化された送信メッセージの１つのパートとしてバイナリ形式のコンテンツデータを添付するコードを生成するなど、その添付方式に従った送信用スタブ１０２を生成してステップＳ３０８に戻る。またステップＳ３１０で、パラメータのデータ型が添付先参照を表すデータ型でない場合は、ステップＳ３１２に進み、インターフェース定義２２１の他の定義情報を使って送信側スタブ１０２を生成してステップＳ３０８に戻る。
【００３９】
またステップＳ３０５の処理で、送信装置１００が対応できる添付方式が全くないと判断した場合は、ステップＳ３１３に進み、送信スタブ１０２の生成を中止する。またステップＳ３０９で、これ以上パラメータがなくなると、この処理を終了する。
【００４０】
このようにして送信装置１００の送信側スタブ１０２を生成することができる。
【００４１】
次に図４及び図７を使用して、本実施の形態１に係るアプリケーション開発装置２１０における受信側スタブ１２２の生成処理の流れを説明する。
【００４２】
図４は、本実施の形態１に係るアプリケーション開発装置２１０における受信側スタブ１２２の生成を説明するフローチャートである。
【００４３】
スタブ生成部２１３が、アプリケーション開発者等の要求により、受信側スタブ１２２を生成する指示が検出されると、まずステップＳ４０１で、インターフェース定義読み込み部２１２を用いて外部記憶装置２２０からインターフェース定義２２１を読み込む。
【００４４】
次にステップＳ４０２で、インターフェース定義読み込み部２１２は、インターフェース定義２２１のデータ型定義部７００を参照し、添付先参照を表すデータ型（図７におけるbinaryRef型）が定義されているかどうか判断する。定義されていた場合はステップＳ４０３に進み、データ型定義部解析部２１４はデータ型定義部７００の定義から、添付先参照を表す抽象データ型（binaryRef型）が、どのようなデータ型を結合しているのかデータ型名を抽出してリスト化する。そして、添付方式判断部２１１は、このリストを参照してデータ型・添付方式対応テーブル２１５を参照してそのデータ型名がどの添付方式に対応するのか判断する。
【００４５】
図７の例では、binaryRef型７０２は、ＳＷＡ方式でバイナリ形式のコンテンツデータを参照するのに使用するデータ型（swaRef型）７０３、ＷＳＡ方式でバイナリ形式のコンテンツデータを参照するのに使用するデータ型（wsaRef型）７０４、ＭＴＯＭ方式でバイナリ形式のコンテンツデータを参照するのに使用するデータ型（mtomRef型）７０５を結合した型となっている。尚、ステップＳ４０２で、添付先参照を表すデータ型定義されていなかった場合は、バイナリ形式のコンテンツデータは添付しないメッセージであると判断してステップＳ４０３の処理を省略してステップＳ４０４に進む。
【００４６】
次にステップＳ４０４で、スタブ生成部２１３は、インターフェース定義２２１のメッセージ構成定義部７００からメッセージを構成するパラメータを抽出する。そしてステップＳ４０５で最後のパラメータでないときはステップＳ４０６に進み、そのパラメータのデータ型が添付先参照を表すデータであるかどうかを判定する。パラメータが添付先参照を表すデータ型である場合はステップＳ４０７に進む。ステップＳ４０７では、マルチパート化された受信メッセージの１つのパートに格納されたコンテンツデータを添付データとしてアプリケーションに渡すコードを生成するなど、その添付方式に従った受信側スタブ１２２を生成する処理を行ってステップＳ４０５に戻る。
【００４７】
一方ステップＳ４０６で、パラメータが添付先参照を表すデータ型でない場合は、ステップＳ４０８に進み、インターフェース定義の他の定義情報を使って受信側スタブ１２２を生成してステップＳ４０５に戻る。
【００４８】
尚、生成される受信側スタブ１２２は、インターフェース定義２２１で記述された全ての添付方式（ＳＷＡ方式，ＷＳＡ方式，ＭＴＯＭ方式）に従ったコードができるだけ含まれなければならない点が、前述の送信側スタブ１０２の生成の場合とは異なっている。すなわち、受信側スタブ１２２は、スタブ生成部２１３に記憶された動作環境定義ファイルに記述された受信装置１２０が対応する全ての添付方式に従ったコードが含まれることになる。
【００４９】
次に図５及び図８を使用して、本実施の形態に係る送信装置１００でどのようにメッセージが生成されて送信されるのかを示す処理の流れを説明する。
【００５０】
図５は、本実施の形態１に係る送信装置１００における処理を説明するフローチャートである。
【００５１】
送信装置１００の送信側アプリケーション１０１は、受信装置１２０にメッセージを送る際、まずステップＳ５０１で、送信側スタブ１０２に指定したメッセージを構成するパラメータ名とパラメータの値を通知する。特に、メッセージにバイナリファイルを添付する場合は、同時に送信側スタブ１０２に対して、添付するファイルのパス名と、その参照先を格納するパラメータ名を指定する（Ｓ５０２）。
【００５２】
この送信要求を受け取った送信側スタブ１０２は、添付ファイル読み込み部１０３を使って、指定されたパス名をもつファイルを読み込んで、送信メッセージの添付部分を生成する。この送信側スタブ１０２によるメッセージ添付部分の生成時に指定された添付方式に従って送信メッセージを作成する。この際、添付したデータの参照先を格納するパラメータの属性として、添付方式に応じたデータ型を記述する（ステップＳ５０３）。
【００５３】
図８は、こうして作成した送信メッセージの一例を示す図である。
【００５４】
図８の例では、添付したバイナリ形式のコンテンツデータ（image0001@example.com）の参照先を格納するパラメータ（ImageRef）としてＳＷＡ添付方式において参照先を格納するためのデータ型を指定（xsi:type="types:swaRef）している（８０１）。
【００５５】
このようにステップＳ５０３で、送信側スタブ１０２は、添付方式に従ってメッセージを生成した後ステップＳ５０４に進む。送信側スタブ１０２は、メッセージ送信部１０４に送信要求を行なう。この送信要求を受けたメッセージ送信部１０４は、ステップＳ５０５で、ネットワーク１４０を経由して受信装置１２０にメッセージを送信する。
【００５６】
次に本実施の形態１に係る受信装置１２０でどのようにメッセージが受信され、解析されるのかを示す処理の流れを図６及び図８を用いて説明する。
【００５７】
図６は、本実施の形態１に係る受信装置１２０における処理を説明するフローチャートである。
【００５８】
まずステップＳ６０１において、受信装置１２０のメッセージ受信部１２４は、送信装置１００から送信されたメッセージを受信すると、その受信したメッセージ内容を受信側スタブ１２２に通知する。次にステップＳ６０２で、受信側スタブ１２２は、その受け取ったメッセージの非添付部分からパラメータ（xsi:type="types:swaRef）を抽出する。次にステップＳ６０３で、抽出するパラメータが存在する場合は、ステップＳ６０４に進み、受信側スタブ１２２は、その抽出したパラメータに添付データの参照先を表すデータ型が属性として付加されているかを判定する。ここで属性として付加されているときはステップＳ６０５に進み、インターフェース定義２２１に記述されている添付方式か否かをみる。インターフェース定義２２１に記述されている添付方式であればステップＳ６０８に進む。ステップＳ６０８において、その指定されたデータ型に対応する添付方式（図８の例ではＳＷＡ方式）に従ってパラメータの値が指すメッセージの添付部分から、バイナリ形式のコンテンツデータとしての添付ファイル（図８の例では「image0001@example.com」）を抽出する。そしてステップＳ６０９で、添付ファイル書き出し部１２３を使って外部記憶装置１３０に保存する。この後ステップＳ６１０で、受信側スタブ１２２は、保存した後、パラメータの値として保存先パス名を設定してステップＳ６０２に戻る。
【００５９】
図８は、この受信装置１２０が受信したメッセージの一例を示す図である。
【００６０】
図８の例では、添付されたデータの参照先を格納するパラメータ（ImageRef）にＳＷＡ添付方式で参照先を格納するためのデータ型が属性として指定（xsi:type="types:swaRef）されている。これにより図９に示すデータ型・添付方式対応テーブル２１５から、テンプレート方式が「ＳＷＡ方式」であることが分かる。
【００６１】
一方ステップＳ６０４で、パラメータに添付するバイナリ形式のコンテンツデータの参照先を表すデータ型が属性として指定されていなかった場合は、ステップＳ６１１に進む。ステップＳ６１１において、受信側スタブ１２２は、パラメータの値をメッセージの非添付部分から抽出してステップＳ６０２に戻る。
【００６２】
こうしてステップＳ６０３で、全てのパラメータとパラメータの値の抽出を行なうとステップＳ６０６に進み、受信側スタブ１２２は受信側アプリケーション１２１にそれらを渡す。
【００６３】
またステップＳ６０５で、受信したメッセージにインターフェース定義２２１に記述されていた以外の添付データ参照用のデータ型が指定されていた場合はステップＳ６０７に進む。ステップＳ６０７において、受信側スタブ１２２は、不正なメッセージとしてエラーをアプリケーション１２１に通知する。例えば、図８の例のようにインターフェース定義で、swaRef、wsaRef、mtomRefのいずれかが定義されていた場合は正しいメッセージであるとして処理を行い、これら以外のデータ型が指定指定されているとエラーとなる。
【００６４】
以上説明したように本実施の形態１によれば、１つのインターフェース定義を参照するだけで、Ｗｅｂサービスでやり取りするバイナリ形式のコンテンツデータの添付方式を指定することができる。
【００６５】
また、このメッセージを受信した受信装置では、「xsi:type」で指定されたデータ型を参照して、どのコンテンツデータの添付方式を採用したメッセージであるかを識別して処理できる。
【００６６】
［実施の形態２］
次に本発明の実施の形態２の構成を説明する。
【００６７】
図１０は、本発明の実施の形態２に係る通信システムの構成を示すブロック図である。尚、この実施の形態２に係るメッセージ送信側装置（以下、送信装置）１０００とメッセージ受信側装置（以下、受信装置）１０１０の構成は、前述の実施の形態１の送信装置１００，受信装置１２０と同様であるため、その説明を省略する。この実施の形態２では、ネットワーク１１００に送信装置１０００と受信装置１０１０が接続されており、これら装置の他に、メッセージ中継装置１０２０がネットワーク１０１０に接続されている。そして送信装置１０００から送信されたメッセージが、メッセージ中継装置１０２０を経由して受信装置１０１０に送信される点が前述の実施の形態１と異なっている。
【００６８】
このメッセージ中継装置１０２０は、データ添付方式が異なるメッセージを変換するためのメッセージ変換部１０２３が実装されている。これにより、メッセージ送信側装置１０００、メッセージ受信側装置１０１０のそれぞれで対応しているデータ添付方式が異なっていた場合にも、このメッセージ中継装置１０２０を経由してメッセージを送信することにより、適切なデータ添付方式の変換を行なうことが可能となる。尚、この実施の形態２における、これ以後の説明では、送信装置１０００、受信装置１０１０が１つずつネットワークに接続される場合を説明するが、それぞれ複数存在しても構わない。
【００６９】
メッセージ中継装置１０２０のメッセージ受信部１０２１は、ネットワーク１１００経由で送信装置１０００から、例えば図８に示すようなバイナリ形式のコンテンツデータが添付されたメッセージを受信する。このメッセージ受信部１０２１は、受信したメッセージをメッセージ変換部１０２３に渡す。これによりメッセージ変換部１０２３は、その受け取ったメッセージに、そのメッセージの添付方法を表すデータ型（例えば図８における「xsi:type=types:swaRef」）が指定されているかを判別する。そして、メッセージ変換部１０２３は、指定されているとデータ型・添付方式対応テーブル１０２７を参照して、どの添付方式でメッセージが送られてきたかを判断する。
【００７０】
本実施の形態２に係るデータ型・添付方式対応テーブル１０２７のデータ構成は、前述の図９に示すデータ構成と同じである。
【００７１】
その後、メッセージ変換部１０２３は、データ型定義部解析部１０２４に対して、受信装置１０１０のインターフェース定義１０２８に記述されたデータ添付方式を表す抽象データ型が、どのような型を結合して派生されているのか問い合わせる。データ型定義部解析部１０２４は、受信装置１０１０に記憶された動作環境定義ファイルの記述から、データ添付方式を表す抽象データ型がどのようなデータ型から派生されているのかを検索する。そして、データ型定義部解析部１０２４は、問い合わせ結果としてメッセージ変換部１０２３に検索結果のデータ型一覧を返却する。
【００７２】
この実施の形態２に係る受信装置１０１０のインターフェース定義１０２８は、前述の実施の形態１に係る図７と同じであるものとする。
【００７３】
図７において、データ添付方式を表す抽象データ型は、binaryRef型である。binaryRef型は、swaRef型、wsaRef型、mtomRef型の結合による派生で定義されていることが記述されている。従って、データ型定義部解釈部１０２４は、メッセージ変換部１０２３にこれら３つのデータ型名を返却する。これら処理により、メッセージ変換部１０２３は、返却されたデータ型名と、データ型添付方式対応テーブル１０２７から、受信装置１０１０が対応している添付方式の一覧を得ることができる。
【００７４】
そして図９に示すデータ型・添付方式対応テーブル１０２７を参照すると、データ型が「swaRef型」、「wsaRef型」、「mtomRef型」は、それぞれデータ添付方式「SwA方式」、「WSA方式」、「MTOM方式」に相当すると判断できる。
【００７５】
従って、メッセージ変換部１０２３は、送信装置１０００がどのデータ添付方式でメッセージを送ってきたか、及び、受信装置１０１０がどのデータ添付方式のメッセージに対応しているのかを判断できる。このためメッセージ変換部１０２３は、データ添付方式変換テーブル１０２６から、どの変換メソッドを使えば、受信したメッセージを受信装置１０１０が対応している添付形式に適切に変換できるかを判別できる。
【００７６】
図１１は、本実施の形態２に係るデータ添付方式変換テーブル１０２６のデータ例を示す図である。
【００７７】
この例では、受信データ添付方式がＳＷＡ方式で、送信データ添付方式がＭＴＯＭ方式の場合、メッセージ変換に使用するメソッド名は「SwAtoMTOM（）」であることが分かる。
【００７８】
以上の処理により、メッセージ変換部１０２３は、適切なメソッドを選択して、送信装置１０００から受け取った添付方式の異なるメッセージを、受信装置１０１０が対応している適切な添付方式のメッセージに変換して転送することができる。
【００７９】
尚、添付方式の組み合わせによっては、受信装置１０１０が対応する添付方式に変換するためのメソッドが存在しない場合がある。その場合は、メッセージ中継装置１０２０が送信装置１０００にメッセージ変換の失敗メッセージを返却するなど適切なエラー処理を行なう。
【００８０】
以上説明したように本実施の形態によれば、ネットワークで接続された複数の送受信装置において、１つのインターフェース定義を参照するだけで複数の添付方式を使用するウェブサービスを利用することができる。これにより、それぞれの添付方式に合わせた個別のインターフェース定義を参照することなく送信及び受信側スタブを生成することが可能となり、アプリケーションの開発効率が向上する。
【００８１】
また、アプリケーションが新しい添付方式に対応した場合などに発生するインターフェース定義自身の更新作業も効率良く行なうことができる。
【００８２】
なお本発明は、前述した実施の形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが、その供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。その場合、プログラムの機能を有していれば、その形態はプログラムである必要はない。従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明には、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【００８３】
プログラムを供給するための記憶媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。その他のプログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記憶媒体にダウンロードすることによっても供給できる。また本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。
【００８４】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件を満足するユーザに対してインターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【００８５】
またコンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
【００８６】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。
【００８７】
図１２は、上述した送信装置１００，１０００、受信装置１２０，１０１０、中継装置１０２０，アプリケーション開発装置２１０のハードウェア構成の一例を示すブロック図である。
【００８８】
図１２において、ＣＰＵ１２０１は、装置各部を統括制御するために、ＲＯＭ１２０３から所定のプログラムを読み出して実行し、各種処理を実現する。ＲＡＭ１２０２は、プログラムによる処理に必要な作業領域を提供する。ＲＯＭ１２０３は、本実施の形態を実行するプログラムおよび参照対象となるウェブサービスのインターフェース定義の情報を格納するためのものである。入力部２０４は、キーボード，マウスなどによって構成される。２次記憶部１２０５は、装置に内蔵されるハードディスク，或は不揮発性の着脱可能なメモリカードとデータの読出しあるいは書き込みを行う記憶制御部などによって構成される。２次記憶部１２０５には、各種情報だけでなく、ウェブサービスのインターフェース定義を参照することによって生成されるスタブが記憶される。また、表示部１２０６は、各種データを表示する。Ｉ／Ｆ（インターフェース）１２０７は、インターネットなどを介して外部装置とメッセージを送受信する。
【図面の簡単な説明】
【００８９】
【図１】本発明の実施の形態１に係る通信システムの構成例を示す図である。
【図２】本実施の形態１に係るアプリケーション開発装置の機能構成を説明する機能ブロック図である。
【図３】本発明の実施の形態１に係るアプリケーション開発装置で送信側スタブを生成する際の制御手順を説明するフローチャートである。
【図４】本実施の形態１に係るアプリケーション開発装置における受信側スタブの生成を説明するフローチャートである。
【図５】本実施の形態１に係る送信装置における処理を説明するフローチャートである。
【図６】本実施の形態１に係る受信装置における処理を説明するフローチャートである。
【図７】ＷＳＤＬで記述されたインターフェース定義の一例を説明する図である。
【図８】本発明の実施の形態１，２において送信装置から受信装置に送信されるメッセージ形式の一例を示す図である。
【図９】本実施の形態１，２に係るデータ型・添付方式対応テーブルの一例を示す図である。
【図１０】本発明の実施の形態２に係る通信システムの構成を示すブロック図である。
【図１１】本実施の形態２に係るデータ添付方式変換テーブルのデータ例を示す図である。
【図１２】本実施の形態に係る各装置のハードウェア構成の一例を示すブロック図である。
【技術分野】
【０００１】
本発明は、インターネットなどのネットワークを介してテキスト形式の構造化されたメッセージを送受信する通信装置、中継装置及び当該装置におけるメッセージ送受信方法に関する。
【背景技術】
【０００２】
近年、インターネットの普及により、コンピュータやデジタル機器から、ネットワーク上のＷｅｂサービスを利用することが多くなってきている。Ｗｅｂサービスとは、ネットワーク上でオープンな仕様で公開されるソフトウェア部品のことである。一般に、コンピュータ、デジタル機器とＷｅｂサービス間で送受信されるメッセージは、インターネット技術の標準化団体であるＷ３Ｃ（World Wide Web Consortium）で仕様が策定されているＳＯＡＰ等のＸＭＬプロトコルが使用されることが多い。ここでＸＭＬプロトコルとは、Ｗ３Ｃで仕様が規定されているマークアップ言語であるＸＭＬを使って通信内容を記述する通信プロトコルのことである。
【０００３】
ＸＭＬは、構造化データをテキスト形式で記述する言語である。そのため、ＸＭＬプロトコルの仕様だけを使ってＸＭＬ形式のメッセージを送受信する場合に、ＸＭＬ形式のメッセージからリンク参照される画像ファイル等のバイナリ形式のコンテンツデータをバイナリ形式のまま送信することができない。これを解決するために、標準化団体であるＷ３Ｃでは、ＳＯＡＰ自体の仕様の他に、ＳＷＡ（SOAP Messages with Attachments），ＭＴＯＭ（SOAP Message Transmission Optimization Mechanism）など、ＳＯＡＰで送受信するメッセージに画像などのバイナリ形式のコンテンツデータを添付する際の仕様を複数規定している。また、マイクロソフト社やＩＢＭにおいても、かつて独自の添付方式であるＷＳＡ（WS-Attachments）を、標準化団体であるＩＥＴＦのドラフト仕様として提出していた。
【０００４】
このように、ＸＭＬプロトコルで送受信するメッセージにファイルを添付するための仕様が現時点では複数存在するため、アプリケーションがコンテンツデータをメッセージに添付する場合には、送信側、受信側のアプリケーションプログラムが予めどの添付方式を使用すればよいかを知っておく必要がある。
【０００５】
Ｗｅｂサービス間の相互接続性の向上を目的とする標準化団体であるＷＳ−Ｉは、Attachment Profile 1.0という仕様で、添付方式としてＷ３ＣのＳＷＡ（SOAP Messages with Attachments）を用いた例を記述している。ここでは、Ｗｅｂサービス間のインターフェース定義言語（ＷＳＤＬ：Web Service Definition Language）で記述されたインターフェース定義文書において、メッセージを構成するパラメータのどれがＳＷＡ方式で添付したコンテンツデータを参照しているのかを、ｓｗａＲｅｆというパラメータのデータ型で表現する方法を提案している。これにより、そのインターフェース定義文書を参照して、送信側と受信側のアプリケーションを開発し、そのアプリケーションを用いてＳＷＡ方式を用いたメッセージを正しく送受信することができる。尚、ＸＭＬプロトコルを使ってメッセージを交換する送信側及び受信側のアプリケーションは、一般に直接インターフェース記述を参照するのではなく、アプリケーション開発ツールによってインターフェース記述からスタブと呼ばれるメッセージ解釈のためのソフトウェア部品を生成し、それらをアプリケーションプログラムから利用することによってインターフェース定義に従ったメッセージを生成し、それを解釈することが多い。ＷＳＤＬを用いた先行技術として、以下の特許文献１が存在する。
【特許文献１】特開２００４−３４１７３４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上述のAttachment Profile 1.0仕様は、ＳＷＡという添付方式を採用した際のインターフェース定義の仕方を記述している。これによって、アプリケーション開発ツールは、ＳＷＡ方式に対応している送信側及び受信側のアプリケーション用のスタブを生成することができる。しかしながら、受信側がＳＷＡ以外の添付方式を使用していたり、受信側が複数の添付方式を受け付け可能であったりする場合には、上記のインターフェース定義の方法では統一的に記述することができなかった。従って、アプリケーションの開発者は、スタブを生成するためにそれぞれの添付方式に対応したインターフェース定義文書を参照し、それぞれの添付方式に応じたスタブを生成するという非効率な処理を行なう必要があった。そして、送信側装置および受信側装置のそれぞれのメモリに各種類の添付方式に対応したインターフェース記述文書を格納しなければならず、メモリ容量の点からも効率がよくなかった。
【０００７】
また上述のAttachment Profile 1.0仕様では、バイナリ形式のコンテンツデータを添付してメッセージを送受信することを、そのインターフェース定義内のメッセージ形式の定義で論理的に記述していない。上述のAttachment Profile 1.0仕様では、具体的にＳＷＡという添付方式に特化したメッセージ形式として記述する必要があった。そのため、Ｗｅｂサービスのバージョンアップ等、コンテンツデータの添付方式を新しい方式に対応させる必要があるときに、本来プロトコルによらない論理的なメッセージ形式の記述を、新しい添付方式に沿った記述に大幅に書き換える必要がある。
【０００８】
本発明は、上記従来技術の欠点を解決することにある。
【０００９】
また本願発明の特徴は、コンテンツデータの添付方式を、複数の添付方式の中から選択して指定できる通信装置、中継装置及び当該装置におけるメッセージ送受信方法を提供することにある。
【課題を解決するための手段】
【００１０】
上記特徴は、独立クレームに記載の特徴の組み合わせにより達成され、従属項は発明の単なる有利な具体例を規定するものである。
【００１１】
本発明の一態様に係る通信装置は以下のような構成を備える。即ち、
ネットワークを介して接続された通信装置との間で送受信するメッセージとして、バイナリ形式のコンテンツデータを添付したテキスト形式の構造化文書を生成する通信装置であって、
送信側と受信側の通信装置間のウェブサービスのインターフェース定義であって、前記構造化文書に添付可能なコンテンツデータの添付方式を示す複数種類のデータ型を示す抽象データ型の記述を有するインターフェース定義を記憶する記憶手段と、
前記インターフェース定義に記述されたデータ型に対応する添付方式のうち、前記通信装置が対応可能な添付方式でバイナリ形式のコンテンツデータを添付するとともに、バイナリ形式のコンテンツデータを添付した添付方式を示すデータ型を示すメッセージを生成するメッセージ生成手段と、
前記バイナリ形式のコンテンツデータが添付されたメッセージを送信する送信手段と、を有することを特徴とする。
【００１２】
本発明の一態様に係る通信装置は以下のような構成を備える。即ち、
ネットワークを介して接続された通信装置との間で送受信するメッセージとして、バイナリ形式のコンテンツデータを添付したテキスト形式の構造化文書を受信する通信装置であって、
送信側と受信側の通信装置間のウェブサービスのインターフェース定義であって、前記構造化文書に添付可能なコンテンツデータの添付方式を示す複数種類のデータ型を示す抽象データ型の記述を有するインターフェース定義を記憶する記憶手段と、
前記記憶手段に記憶されたインターフェース定義に記述されたデータ型が受信したメッセージに記述されているかどうかを判別する判別手段と、
前記判別手段によって前記記憶手段に記憶されたインターフェース定義に記述されたデータ型が前記受信したメッセージに記述されていると判別された場合、前記変別されたデータ型に対応する添付方式に従って、前記添付されているバイナリ形式のコンテンツデータを抽出する抽出手段と、
前記抽出手段により抽出した前記バイナリ形式のコンテンツデータのパス名を設定してメモリに記憶する記憶制御手段と、
を有することを特徴とする。
【００１３】
尚、この発明の概要は、必要な特徴を全て列挙しているものではない。また、これら特徴群のサブコンビネーションも発明になり得る。
【発明の効果】
【００１４】
本発明によれば、コンテンツデータの添付方式を、複数の添付方式の中から選択して指定できるという効果がある。
【発明を実施するための最良の形態】
【００１５】
以下、添付図面を参照して本発明の好適な実施の形態を詳しく説明する。尚、以下の実施の形態は特許請求の範囲に係る発明を限定するものでなく、また本実施の形態で説明されている特徴の組み合わせの全てが発明の解決手段に必須のものとは限らない。
【００１６】
［実施の形態１］
図１は、本発明の実施の形態１に係る通信システムの構成例を示す図である。
【００１７】
ネットワーク１４０には、メッセージ送信側装置（以下、送信装置）１００とメッセージ受信側装置１２０（以下、受信装置）が接続されている。送信装置１００と受信装置１２０はネットワーク１４０を経由して、ＸＭＬプロトコルの１つであるＳＯＡＰでメッセージを送受信する。ここで、一般的な送信装置１００、受信装置１２０として、パーソナルコンピュータ、サーバコンピュータ、デジタル機器等が考えられる。尚、この実施の形態では、送信装置、受信装置はそれぞれ１つずつしか説明されていないが、それぞれ複数存在しても構わない。
【００１８】
送信装置１００、受信装置１２０には、メッセージに添付するテキストデータ，画像データなどのバイナリ形式のコンテンツデータを保存するための外部記憶装置１１０，１３０がそれぞれ接続されている。本実施の形態では、コンテンツデータはファイルとして説明するが、メモリ上に展開されたデータであってもよいし、ネットワークを経由したＷｅｂサーバ、ストレージサーバ上にあってもよい。なお、外部記憶装置１１０，１３０の代わりとして、送信装置１００、受信装置１２０にメモリを内蔵してもよい。なお、本実施の形態で説明する「スタブ」とは、送受信するメッセージを解釈し、送受信装置アプリケーションにデータを引き渡すプログラムを指す。
【００１９】
次に通信装置である送信装置１００の機能構成を説明する。
【００２０】
送信装置１００は、ネットワーク１４０を経由し、ＸＭＬ形式のアプリケーションデータ及びそこからリンクして参照されているバイナリ形式のコンテンツデータを格納するファイルの送信要求を行なう送信側アプリケーション１０１を有する。さらに、送信装置１００は、送信側アプリケーション１０１からの要求により、アプリケーションデータから、マルチパートＭＩＭＥあるいはＤＩＭＥなどマルチパート形式の送信メッセージを生成する送信側スタブ１０２を有する。さらに、送信装置１００は、送信側スタブ１０２から呼び出され、アプリケーションデータ内の記述を検索し、添付が必要なファイルを読み込む添付ファイル読み込み部１０３を有する。さらに、送信装置１００は、送信側スタブ１０２で作成したメッセージをネットワーク１４０経由で受信装置１２０に送信するメッセージ送信部１０４を有している。
【００２１】
次に通信装置である受信装置１２０の機能構成を説明する。
【００２２】
受信装置１２０は、ネットワーク１４０を経由し、送信装置１００から受信したマルチパートＭＩＭＥ，ＤＩＭＥ等のマルチパート形式のメッセージを受信するメッセージ受信部１２４を有する。また、受信装置１２０は、メッセージ受信部１２４が受信したメッセージを解析して複数のパートに分解し、コンテンツデータのパートを添付ファイル書き出し部１２３により外部記憶装置１３０に保存する処理を行なう受信側スタブ１２２を有する。また、受信装置１２０は、この受信側スタブ１２２によってメッセージから取り出されたアプリケーションデータを渡す先である受信側アプリケーション１２１を有している。尚、図１及び以下に示す図面において、各機能を実行する部は、本実施の形態ではソフトウェアにより実現されているが、これら各部は専用のＬＳＩ等を採用したハードウェアにより構成されていても良い。
【００２３】
なお、説明の簡略化のため上記のとおり送信装置１００および受信装置１２０を分けて説明したが、実際は送信装置１００，受信装置１２０はそれぞれ受信装置１００，送信装置１２０を兼用することになる。
【００２４】
次に図２を使用して、本実施の形態に係るアプリケーション開発装置の構成例を説明する。このアプリケーション開発装置は、前述の送信装置１００や受信装置１２０で実行されるアプリケーションを開発するための装置である。なお、送信装置１００および受信装置１２０がこのアプリケーション開発装置の機能を兼用してもよい。この場合、インターフェース定義２２１は外部記憶装置１００，１３０に記憶される。
【００２５】
図２は、本実施の形態１に係るアプリケーション開発装置２１０の機能構成を説明する機能ブロック図である。尚、図２においても、各機能を実行する部は、本実施の形態ではソフトウェアにより実現されているが、これら各部は専用のＬＳＩ等を採用したハードウェアにより構成されていても良い。
【００２６】
このアプリケーション開発装置２１０は、送信装置１００と受信装置１２０間で送受信するメッセージの構成の定義を記述した文書であるインターフェース定義２２１を保存する外部記憶装置２２０と接続されている。尚、この実施の形態では、インターフェース定義２２１はファイルとして説明するが、メモリ上に展開されたデータであってもよい。また、インターフェース定義２２１は、ネットワークを経由したＷｅｂサーバ、ストレージサーバ上にあってもよい。
【００２７】
次にアプリケーション開発装置２１０の機能構成を説明する。インターフェース定義読み込み部２１２は、インターフェース定義を記述した文書からスタブと呼ばれるメッセージ解釈のためのソフトウェアを生成するスタブ生成部２１３からの要求により、外部記憶装置２２０に保存されているインターフェース定義２２１を読み込む。データ型定義解析部２１４は、インターフェース定義読み込み部２１２により読み込んだインターフェース定義２２１のデータ型定義部からバイナリ添付方式を表す抽象データ型の定義を抽出する。そして、データ型定義解析部２１４は、この抽象データ型がどのデータ型の結合として派生されているかを解析する。添付方式判断部２１１は、データ型定義解析部２１４で解析した結合されているデータ型名と、データ型・添付方式対応テーブル２１５の内容とから、送信側及び受信側スタブ１０２，１２２で使用するバイナリ形式のコンテンツデータの添付方式を決定する。
【００２８】
次に図３、図７及び図９を使用して、構造化文書生成装置としての本実施の形態に係るアプリケーション開発装置２１０における送信側スタブ１０２の生成処理を説明する。
【００２９】
図３は、本発明の実施の形態１に係るアプリケーション開発装置２１０で送信側スタブ１０２を生成する際の制御手順を説明するフローチャートである。
【００３０】
スタブ生成部２１３が、アプリケーション開発者などの要求により、送信側スタブ１０２を生成する指示を検出すると、まずステップＳ３０１で、インターフェース定義読み込み部２１２により外部記憶装置２２０からインターフェース定義２２１を読み込む。
【００３１】
図７は、ＷＳＤＬで記述されたウェブサービスのインターフェース定義の一例を示す図である。
【００３２】
次にステップＳ３０２で、インターフェース定義読み込み部２１２は、インターフェース定義２２１内のデータ型定義部７００（図７）を参照し、添付するコンテンツデータの仕様を表す抽象データ型（図７の７０２で示す「binaryRef」型）が定義されているかどうか判断する。定義されていた場合はステップＳ３０３に進み、添付方式判断部２１１は、データ型定義部７００の定義から、抽象データ型（binaryRef型）がどのようなデータ型を結合して派生しているのか抽出してデータ型名をリスト化する。尚、ステップＳ３０２で、添付先を示すデータ型が定義されていなかった場合、添付方式判断部２１１は、バイナリ形式のコンテンツデータを添付しないメッセージであると判断してステップＳ３０８にスキップする。
【００３３】
図７の例では、記述７０７で示すように、binaryRef型は、ＳＷＡ方式でコンテンツデータを参照するのに使用するデータ型（swaRef型）７０３、ＷＳＡ方式でコンテンツデータを参照するのに使用するデータ型（wsaRef型）７０４、ＭＴＯＭ方式でコンテンツデータを参照するのに使用するデータ型（mtomRef型）７０５を結合した抽象型として記述されている。
【００３４】
ステップＳ３０３で、添付方式判断部２１１は、添付方式に対応するデータ型のリストを作成する。図７の例では、ＳＷＡ方式でコンテンツデータを参照するデータ型（swaRef型）７０３、ＷＳＡ方式でコンテンツデータを参照するデータ型（wsaRef型）７０４、ＭＴＯＭ方式でコンテンツデータを参照するデータ型（mtomRef型）７０５がリストアップされる。次にステップＳ３０４で、データ型・添付方式対応テーブル２１５を参照して、ステップＳ３０３でリストアップされた各データ型に対応する添付方式を特定する。次にステップＳ３０５で、そのリストの最後のデータ型でないときはステップＳ３０６に進み、リストの前から順番にこの添付方式が送信装置１００で対応しているかどうか判断する。ここで対応している場合はステップＳ３０７に進むが、対応していない場合はステップＳ３０４に戻る。
【００３５】
図９は、本実施の形態に係るデータ型・添付方式対応テーブル２１５の一例を示す図である。
【００３６】
この図９では、データ型の名前空間ＵＲＩ（図７の７０３〜７０５）に対して、そのデータ型名、添付方式が登録されている。データ型・添付方式対応テーブル２１５を参照することにより、データ添付方式を表すswaRef型、wsaRef型、mtomRef型はSWA方式、WSA方式、MTOM方式に相当すると判断される。
【００３７】
尚、前述のステップＳ３０６で、送信装置１００がその添付方式に対応しているか否かの判断基準は、スタブ生成部２１３に記憶された動作環境定義ファイルに、予め送信装置１００が対応している添付方式に関する情報を記述しておく。送信装置１００が対応している添付方式に関する情報は、送信装置１００がバージョンアップによって新たな添付方式が対応可能となるたびに更新される。こうしてステップＳ３０６で、そのリストアップされた添付方式が送信装置１００で対応している場合は、ステップＳ３０７に進み、添付方式判断部２１１は、生成する送信側スタブ１０２で採用する添付方式をその添付方式に決定する。尚、送信装置１００が対応できる添付方式が複数存在する場合を考慮し、データ型定義部７００でデータ型を記述する順序を、開発者が生成させたい優先度順に記述しておき、対応できる添付方式の中から最も先に記述されているデータ型に対応する添付方式に決定する形態も考えられる。この場合、各送信装置１００におけるさらなる送信側スタブの統一化を図ることができる。
【００３８】
次にステップＳ３０８で、スタブ生成部２１３は、インターフェース定義２２１のメッセージ構成定義部（図７の７１０）から、メッセージを構成する次のパラメータを抽出する。図７の例では、「PutImage」の「ImgaeRef」としてパラメータ「type=types:binaryRef」が指定されており、これによりこのパラメータによる添付ファイルの定義が可能であることがわかる。そしてステップＳ３０９で、パラメータが抽出できるとステップＳ３１０に進む。ステップＳ３１０において、そのパラメータのデータ型が添付先参照を表すデータ型であるかどうかを調べ、そうであれば（図７では７０２，７０７で定義されている）ステップＳ３１１に進む。ステップＳ３１１において、ステップＳ３０７で決定した添付方式に従って、マルチパート化された送信メッセージの１つのパートとしてバイナリ形式のコンテンツデータを添付するコードを生成するなど、その添付方式に従った送信用スタブ１０２を生成してステップＳ３０８に戻る。またステップＳ３１０で、パラメータのデータ型が添付先参照を表すデータ型でない場合は、ステップＳ３１２に進み、インターフェース定義２２１の他の定義情報を使って送信側スタブ１０２を生成してステップＳ３０８に戻る。
【００３９】
またステップＳ３０５の処理で、送信装置１００が対応できる添付方式が全くないと判断した場合は、ステップＳ３１３に進み、送信スタブ１０２の生成を中止する。またステップＳ３０９で、これ以上パラメータがなくなると、この処理を終了する。
【００４０】
このようにして送信装置１００の送信側スタブ１０２を生成することができる。
【００４１】
次に図４及び図７を使用して、本実施の形態１に係るアプリケーション開発装置２１０における受信側スタブ１２２の生成処理の流れを説明する。
【００４２】
図４は、本実施の形態１に係るアプリケーション開発装置２１０における受信側スタブ１２２の生成を説明するフローチャートである。
【００４３】
スタブ生成部２１３が、アプリケーション開発者等の要求により、受信側スタブ１２２を生成する指示が検出されると、まずステップＳ４０１で、インターフェース定義読み込み部２１２を用いて外部記憶装置２２０からインターフェース定義２２１を読み込む。
【００４４】
次にステップＳ４０２で、インターフェース定義読み込み部２１２は、インターフェース定義２２１のデータ型定義部７００を参照し、添付先参照を表すデータ型（図７におけるbinaryRef型）が定義されているかどうか判断する。定義されていた場合はステップＳ４０３に進み、データ型定義部解析部２１４はデータ型定義部７００の定義から、添付先参照を表す抽象データ型（binaryRef型）が、どのようなデータ型を結合しているのかデータ型名を抽出してリスト化する。そして、添付方式判断部２１１は、このリストを参照してデータ型・添付方式対応テーブル２１５を参照してそのデータ型名がどの添付方式に対応するのか判断する。
【００４５】
図７の例では、binaryRef型７０２は、ＳＷＡ方式でバイナリ形式のコンテンツデータを参照するのに使用するデータ型（swaRef型）７０３、ＷＳＡ方式でバイナリ形式のコンテンツデータを参照するのに使用するデータ型（wsaRef型）７０４、ＭＴＯＭ方式でバイナリ形式のコンテンツデータを参照するのに使用するデータ型（mtomRef型）７０５を結合した型となっている。尚、ステップＳ４０２で、添付先参照を表すデータ型定義されていなかった場合は、バイナリ形式のコンテンツデータは添付しないメッセージであると判断してステップＳ４０３の処理を省略してステップＳ４０４に進む。
【００４６】
次にステップＳ４０４で、スタブ生成部２１３は、インターフェース定義２２１のメッセージ構成定義部７００からメッセージを構成するパラメータを抽出する。そしてステップＳ４０５で最後のパラメータでないときはステップＳ４０６に進み、そのパラメータのデータ型が添付先参照を表すデータであるかどうかを判定する。パラメータが添付先参照を表すデータ型である場合はステップＳ４０７に進む。ステップＳ４０７では、マルチパート化された受信メッセージの１つのパートに格納されたコンテンツデータを添付データとしてアプリケーションに渡すコードを生成するなど、その添付方式に従った受信側スタブ１２２を生成する処理を行ってステップＳ４０５に戻る。
【００４７】
一方ステップＳ４０６で、パラメータが添付先参照を表すデータ型でない場合は、ステップＳ４０８に進み、インターフェース定義の他の定義情報を使って受信側スタブ１２２を生成してステップＳ４０５に戻る。
【００４８】
尚、生成される受信側スタブ１２２は、インターフェース定義２２１で記述された全ての添付方式（ＳＷＡ方式，ＷＳＡ方式，ＭＴＯＭ方式）に従ったコードができるだけ含まれなければならない点が、前述の送信側スタブ１０２の生成の場合とは異なっている。すなわち、受信側スタブ１２２は、スタブ生成部２１３に記憶された動作環境定義ファイルに記述された受信装置１２０が対応する全ての添付方式に従ったコードが含まれることになる。
【００４９】
次に図５及び図８を使用して、本実施の形態に係る送信装置１００でどのようにメッセージが生成されて送信されるのかを示す処理の流れを説明する。
【００５０】
図５は、本実施の形態１に係る送信装置１００における処理を説明するフローチャートである。
【００５１】
送信装置１００の送信側アプリケーション１０１は、受信装置１２０にメッセージを送る際、まずステップＳ５０１で、送信側スタブ１０２に指定したメッセージを構成するパラメータ名とパラメータの値を通知する。特に、メッセージにバイナリファイルを添付する場合は、同時に送信側スタブ１０２に対して、添付するファイルのパス名と、その参照先を格納するパラメータ名を指定する（Ｓ５０２）。
【００５２】
この送信要求を受け取った送信側スタブ１０２は、添付ファイル読み込み部１０３を使って、指定されたパス名をもつファイルを読み込んで、送信メッセージの添付部分を生成する。この送信側スタブ１０２によるメッセージ添付部分の生成時に指定された添付方式に従って送信メッセージを作成する。この際、添付したデータの参照先を格納するパラメータの属性として、添付方式に応じたデータ型を記述する（ステップＳ５０３）。
【００５３】
図８は、こうして作成した送信メッセージの一例を示す図である。
【００５４】
図８の例では、添付したバイナリ形式のコンテンツデータ（image0001@example.com）の参照先を格納するパラメータ（ImageRef）としてＳＷＡ添付方式において参照先を格納するためのデータ型を指定（xsi:type="types:swaRef）している（８０１）。
【００５５】
このようにステップＳ５０３で、送信側スタブ１０２は、添付方式に従ってメッセージを生成した後ステップＳ５０４に進む。送信側スタブ１０２は、メッセージ送信部１０４に送信要求を行なう。この送信要求を受けたメッセージ送信部１０４は、ステップＳ５０５で、ネットワーク１４０を経由して受信装置１２０にメッセージを送信する。
【００５６】
次に本実施の形態１に係る受信装置１２０でどのようにメッセージが受信され、解析されるのかを示す処理の流れを図６及び図８を用いて説明する。
【００５７】
図６は、本実施の形態１に係る受信装置１２０における処理を説明するフローチャートである。
【００５８】
まずステップＳ６０１において、受信装置１２０のメッセージ受信部１２４は、送信装置１００から送信されたメッセージを受信すると、その受信したメッセージ内容を受信側スタブ１２２に通知する。次にステップＳ６０２で、受信側スタブ１２２は、その受け取ったメッセージの非添付部分からパラメータ（xsi:type="types:swaRef）を抽出する。次にステップＳ６０３で、抽出するパラメータが存在する場合は、ステップＳ６０４に進み、受信側スタブ１２２は、その抽出したパラメータに添付データの参照先を表すデータ型が属性として付加されているかを判定する。ここで属性として付加されているときはステップＳ６０５に進み、インターフェース定義２２１に記述されている添付方式か否かをみる。インターフェース定義２２１に記述されている添付方式であればステップＳ６０８に進む。ステップＳ６０８において、その指定されたデータ型に対応する添付方式（図８の例ではＳＷＡ方式）に従ってパラメータの値が指すメッセージの添付部分から、バイナリ形式のコンテンツデータとしての添付ファイル（図８の例では「image0001@example.com」）を抽出する。そしてステップＳ６０９で、添付ファイル書き出し部１２３を使って外部記憶装置１３０に保存する。この後ステップＳ６１０で、受信側スタブ１２２は、保存した後、パラメータの値として保存先パス名を設定してステップＳ６０２に戻る。
【００５９】
図８は、この受信装置１２０が受信したメッセージの一例を示す図である。
【００６０】
図８の例では、添付されたデータの参照先を格納するパラメータ（ImageRef）にＳＷＡ添付方式で参照先を格納するためのデータ型が属性として指定（xsi:type="types:swaRef）されている。これにより図９に示すデータ型・添付方式対応テーブル２１５から、テンプレート方式が「ＳＷＡ方式」であることが分かる。
【００６１】
一方ステップＳ６０４で、パラメータに添付するバイナリ形式のコンテンツデータの参照先を表すデータ型が属性として指定されていなかった場合は、ステップＳ６１１に進む。ステップＳ６１１において、受信側スタブ１２２は、パラメータの値をメッセージの非添付部分から抽出してステップＳ６０２に戻る。
【００６２】
こうしてステップＳ６０３で、全てのパラメータとパラメータの値の抽出を行なうとステップＳ６０６に進み、受信側スタブ１２２は受信側アプリケーション１２１にそれらを渡す。
【００６３】
またステップＳ６０５で、受信したメッセージにインターフェース定義２２１に記述されていた以外の添付データ参照用のデータ型が指定されていた場合はステップＳ６０７に進む。ステップＳ６０７において、受信側スタブ１２２は、不正なメッセージとしてエラーをアプリケーション１２１に通知する。例えば、図８の例のようにインターフェース定義で、swaRef、wsaRef、mtomRefのいずれかが定義されていた場合は正しいメッセージであるとして処理を行い、これら以外のデータ型が指定指定されているとエラーとなる。
【００６４】
以上説明したように本実施の形態１によれば、１つのインターフェース定義を参照するだけで、Ｗｅｂサービスでやり取りするバイナリ形式のコンテンツデータの添付方式を指定することができる。
【００６５】
また、このメッセージを受信した受信装置では、「xsi:type」で指定されたデータ型を参照して、どのコンテンツデータの添付方式を採用したメッセージであるかを識別して処理できる。
【００６６】
［実施の形態２］
次に本発明の実施の形態２の構成を説明する。
【００６７】
図１０は、本発明の実施の形態２に係る通信システムの構成を示すブロック図である。尚、この実施の形態２に係るメッセージ送信側装置（以下、送信装置）１０００とメッセージ受信側装置（以下、受信装置）１０１０の構成は、前述の実施の形態１の送信装置１００，受信装置１２０と同様であるため、その説明を省略する。この実施の形態２では、ネットワーク１１００に送信装置１０００と受信装置１０１０が接続されており、これら装置の他に、メッセージ中継装置１０２０がネットワーク１０１０に接続されている。そして送信装置１０００から送信されたメッセージが、メッセージ中継装置１０２０を経由して受信装置１０１０に送信される点が前述の実施の形態１と異なっている。
【００６８】
このメッセージ中継装置１０２０は、データ添付方式が異なるメッセージを変換するためのメッセージ変換部１０２３が実装されている。これにより、メッセージ送信側装置１０００、メッセージ受信側装置１０１０のそれぞれで対応しているデータ添付方式が異なっていた場合にも、このメッセージ中継装置１０２０を経由してメッセージを送信することにより、適切なデータ添付方式の変換を行なうことが可能となる。尚、この実施の形態２における、これ以後の説明では、送信装置１０００、受信装置１０１０が１つずつネットワークに接続される場合を説明するが、それぞれ複数存在しても構わない。
【００６９】
メッセージ中継装置１０２０のメッセージ受信部１０２１は、ネットワーク１１００経由で送信装置１０００から、例えば図８に示すようなバイナリ形式のコンテンツデータが添付されたメッセージを受信する。このメッセージ受信部１０２１は、受信したメッセージをメッセージ変換部１０２３に渡す。これによりメッセージ変換部１０２３は、その受け取ったメッセージに、そのメッセージの添付方法を表すデータ型（例えば図８における「xsi:type=types:swaRef」）が指定されているかを判別する。そして、メッセージ変換部１０２３は、指定されているとデータ型・添付方式対応テーブル１０２７を参照して、どの添付方式でメッセージが送られてきたかを判断する。
【００７０】
本実施の形態２に係るデータ型・添付方式対応テーブル１０２７のデータ構成は、前述の図９に示すデータ構成と同じである。
【００７１】
その後、メッセージ変換部１０２３は、データ型定義部解析部１０２４に対して、受信装置１０１０のインターフェース定義１０２８に記述されたデータ添付方式を表す抽象データ型が、どのような型を結合して派生されているのか問い合わせる。データ型定義部解析部１０２４は、受信装置１０１０に記憶された動作環境定義ファイルの記述から、データ添付方式を表す抽象データ型がどのようなデータ型から派生されているのかを検索する。そして、データ型定義部解析部１０２４は、問い合わせ結果としてメッセージ変換部１０２３に検索結果のデータ型一覧を返却する。
【００７２】
この実施の形態２に係る受信装置１０１０のインターフェース定義１０２８は、前述の実施の形態１に係る図７と同じであるものとする。
【００７３】
図７において、データ添付方式を表す抽象データ型は、binaryRef型である。binaryRef型は、swaRef型、wsaRef型、mtomRef型の結合による派生で定義されていることが記述されている。従って、データ型定義部解釈部１０２４は、メッセージ変換部１０２３にこれら３つのデータ型名を返却する。これら処理により、メッセージ変換部１０２３は、返却されたデータ型名と、データ型添付方式対応テーブル１０２７から、受信装置１０１０が対応している添付方式の一覧を得ることができる。
【００７４】
そして図９に示すデータ型・添付方式対応テーブル１０２７を参照すると、データ型が「swaRef型」、「wsaRef型」、「mtomRef型」は、それぞれデータ添付方式「SwA方式」、「WSA方式」、「MTOM方式」に相当すると判断できる。
【００７５】
従って、メッセージ変換部１０２３は、送信装置１０００がどのデータ添付方式でメッセージを送ってきたか、及び、受信装置１０１０がどのデータ添付方式のメッセージに対応しているのかを判断できる。このためメッセージ変換部１０２３は、データ添付方式変換テーブル１０２６から、どの変換メソッドを使えば、受信したメッセージを受信装置１０１０が対応している添付形式に適切に変換できるかを判別できる。
【００７６】
図１１は、本実施の形態２に係るデータ添付方式変換テーブル１０２６のデータ例を示す図である。
【００７７】
この例では、受信データ添付方式がＳＷＡ方式で、送信データ添付方式がＭＴＯＭ方式の場合、メッセージ変換に使用するメソッド名は「SwAtoMTOM（）」であることが分かる。
【００７８】
以上の処理により、メッセージ変換部１０２３は、適切なメソッドを選択して、送信装置１０００から受け取った添付方式の異なるメッセージを、受信装置１０１０が対応している適切な添付方式のメッセージに変換して転送することができる。
【００７９】
尚、添付方式の組み合わせによっては、受信装置１０１０が対応する添付方式に変換するためのメソッドが存在しない場合がある。その場合は、メッセージ中継装置１０２０が送信装置１０００にメッセージ変換の失敗メッセージを返却するなど適切なエラー処理を行なう。
【００８０】
以上説明したように本実施の形態によれば、ネットワークで接続された複数の送受信装置において、１つのインターフェース定義を参照するだけで複数の添付方式を使用するウェブサービスを利用することができる。これにより、それぞれの添付方式に合わせた個別のインターフェース定義を参照することなく送信及び受信側スタブを生成することが可能となり、アプリケーションの開発効率が向上する。
【００８１】
また、アプリケーションが新しい添付方式に対応した場合などに発生するインターフェース定義自身の更新作業も効率良く行なうことができる。
【００８２】
なお本発明は、前述した実施の形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが、その供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。その場合、プログラムの機能を有していれば、その形態はプログラムである必要はない。従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明には、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【００８３】
プログラムを供給するための記憶媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。その他のプログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記憶媒体にダウンロードすることによっても供給できる。また本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。
【００８４】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件を満足するユーザに対してインターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【００８５】
またコンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
【００８６】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。
【００８７】
図１２は、上述した送信装置１００，１０００、受信装置１２０，１０１０、中継装置１０２０，アプリケーション開発装置２１０のハードウェア構成の一例を示すブロック図である。
【００８８】
図１２において、ＣＰＵ１２０１は、装置各部を統括制御するために、ＲＯＭ１２０３から所定のプログラムを読み出して実行し、各種処理を実現する。ＲＡＭ１２０２は、プログラムによる処理に必要な作業領域を提供する。ＲＯＭ１２０３は、本実施の形態を実行するプログラムおよび参照対象となるウェブサービスのインターフェース定義の情報を格納するためのものである。入力部２０４は、キーボード，マウスなどによって構成される。２次記憶部１２０５は、装置に内蔵されるハードディスク，或は不揮発性の着脱可能なメモリカードとデータの読出しあるいは書き込みを行う記憶制御部などによって構成される。２次記憶部１２０５には、各種情報だけでなく、ウェブサービスのインターフェース定義を参照することによって生成されるスタブが記憶される。また、表示部１２０６は、各種データを表示する。Ｉ／Ｆ（インターフェース）１２０７は、インターネットなどを介して外部装置とメッセージを送受信する。
【図面の簡単な説明】
【００８９】
【図１】本発明の実施の形態１に係る通信システムの構成例を示す図である。
【図２】本実施の形態１に係るアプリケーション開発装置の機能構成を説明する機能ブロック図である。
【図３】本発明の実施の形態１に係るアプリケーション開発装置で送信側スタブを生成する際の制御手順を説明するフローチャートである。
【図４】本実施の形態１に係るアプリケーション開発装置における受信側スタブの生成を説明するフローチャートである。
【図５】本実施の形態１に係る送信装置における処理を説明するフローチャートである。
【図６】本実施の形態１に係る受信装置における処理を説明するフローチャートである。
【図７】ＷＳＤＬで記述されたインターフェース定義の一例を説明する図である。
【図８】本発明の実施の形態１，２において送信装置から受信装置に送信されるメッセージ形式の一例を示す図である。
【図９】本実施の形態１，２に係るデータ型・添付方式対応テーブルの一例を示す図である。
【図１０】本発明の実施の形態２に係る通信システムの構成を示すブロック図である。
【図１１】本実施の形態２に係るデータ添付方式変換テーブルのデータ例を示す図である。
【図１２】本実施の形態に係る各装置のハードウェア構成の一例を示すブロック図である。
【特許請求の範囲】
【請求項１】
ネットワークを介して接続された通信装置との間で送受信するメッセージとして、バイナリ形式のコンテンツデータを添付したテキスト形式の構造化文書を生成する通信装置であって、
送信側と受信側の通信装置間のウェブサービスのインターフェース定義であって、前記構造化文書に添付可能なコンテンツデータの添付方式を示す複数種類のデータ型を示す抽象データ型の記述を有するインターフェース定義を記憶する記憶手段と、
前記インターフェース定義に記述されたデータ型に対応する添付方式のうち、前記通信装置が対応可能な添付方式でバイナリ形式のコンテンツデータを添付するとともに、バイナリ形式のコンテンツデータを添付した添付方式を示すデータ型を示すメッセージを生成するメッセージ生成手段と、
前記バイナリ形式のコンテンツデータが添付されたメッセージを送信する送信手段と、を有することを特徴とする通信装置。
【請求項２】
ネットワークを介して接続された通信装置との間で送受信するメッセージとして、バイナリ形式のコンテンツデータを添付したテキスト形式の構造化文書を受信する通信装置であって、
送信側と受信側の通信装置間のウェブサービスのインターフェース定義であって、前記構造化文書に添付可能なコンテンツデータの添付方式を示す複数種類のデータ型を示す抽象データ型の記述を有するインターフェース定義を記憶する記憶手段と、
前記記憶手段に記憶されたインターフェース定義に記述されたデータ型が受信したメッセージに記述されているかどうかを判別する判別手段と、
前記判別手段によって前記記憶手段に記憶されたインターフェース定義に記述されたデータ型が前記受信したメッセージに記述されていると判別された場合、前記変別されたデータ型に対応する添付方式に従って、前記添付されているバイナリ形式のコンテンツデータを抽出する抽出手段と、
前記抽出手段により抽出した前記バイナリ形式のコンテンツデータのパス名を設定してメモリに記憶する記憶制御手段と、
を有することを特徴とする通信装置。
【請求項３】
前記メッセージ生成手段は、前記通信装置が前記インターフェースに記述されている添付方式のうち複数の添付方式に対応可能な場合、前記対応可能な添付方式のうち、前記インターフェース内で最も先に記述されているデータ型に対応する添付方式で、前記バイナリ形式のコンテンツデータを添付することを特徴とする請求項１に記載の通信装置。
【請求項４】
前記添付方式は、少なくともＳＷＡ方式、ＷＳＡ方式、ＭＴＯＭ方式のいずれかを含むことを特徴とする請求項１乃至３のいずれか１項に記載の通信装置。
【請求項５】
送信側通信装置と受信側通信装置との間に介在し、ネットワークを介して接続された通信装置との間で送受信するメッセージとして、コンテンツデータを添付したテキスト形式の構造化文書の送受信を中継する中継装置であって、
前記送信側通信装置が対応可能な添付方式でバイナリ形式のコンテンツデータを添付するとともに、前記バイナリ形式のコンテンツデータを添付した添付方式を示すデータ型を示すメッセージを受信する受信手段と、
前記受信側通信装置が対応可能な添付形式を問い合わせる問い合わせ手段と、
前記受信手段によって受信されたデータ型に対応する添付方式と、前記問い合わせ手段によって問い合わせ結果から得られた受信側通信装置が対応可能な添付形式とに基づいて、前記バイナリ形式のコンテンツデータの添付形式を変換するためのメソッドを選択する選択手段と、
前記選択手段によって選択されたメソッドを用いて前記バイナリ形式のコンテンツデータの添付形式が変換されたメッセージを送信する送信手段とを有することを特徴とする中継装置。
【請求項６】
前記添付方式は、少なくともＳＷＡ方式、ＷＳＡ方式、ＭＴＯＭ方式のいずれかを含むことを特徴とする請求項５に記載の中継装置。
【請求項７】
ネットワークを介して接続された通信装置との間で送受信するメッセージとして、バイナリ形式のコンテンツデータを添付したテキスト形式の構造化文書を生成する通信装置のメッセージ送信方法であって、
送信側と受信側の通信装置間のウェブサービスのインターフェース定義であって、前記構造化文書に添付可能なコンテンツデータの添付方式を示す複数種類のデータ型を示す抽象データ型の記述を有するインターフェース定義を参照する参照ステップと、
前記インターフェース定義に記述されたデータ型に対応する添付方式のうち、前記通信装置が対応可能な添付方式でバイナリ形式のコンテンツデータを添付するとともに、バイナリ形式のコンテンツデータを添付した添付方式を示すデータ型を示すメッセージを生成するメッセージ生成ステップと、
前記バイナリ形式のコンテンツデータが添付されたメッセージを送信する送信ステップと、
を有することを特徴とする通信装置のメッセージ送信方法。
【請求項８】
ネットワークを介して接続された通信装置との間で送受信するメッセージとして、バイナリ形式のコンテンツデータを添付したテキスト形式の構造化文書を受信する通信装置のメッセージ受信方法であって、
送信側と受信側の通信装置間のウェブサービスのインターフェース定義であって、前記構造化文書に添付可能なコンテンツデータの添付方式を示す複数種類のデータ型を示す抽象データ型の記述を有するインターフェース定義を参照する参照ステップと、
前記インターフェース定義に記述されたデータ型が受信したメッセージに記述されているかどうかを判別する判別ステップと、
前記判別ステップにおいて前記インターフェース定義に記述されたデータ型が前記受信したメッセージに記述されていると判別された場合、前記変別されたデータ型に対応する添付方式に従って、前記添付されているバイナリ形式のコンテンツデータを抽出する抽出ステップと、
前記抽出ステップにおいて抽出した前記バイナリ形式のコンテンツデータのパス名を設定してメモリに記憶する記憶制御ステップと、
を有することを特徴とする通信装置のメッセージ受信方法。
【請求項９】
前記メッセージ生成ステップにおいて、前記通信装置が前記インターフェースに記述されている添付方式のうち複数の添付方式に対応可能な場合、前記対応可能な添付方式のうち、前記インターフェース内で最も先に記述されているデータ型に対応する添付方式で、前記バイナリ形式のコンテンツデータが添付されることを特徴とする請求項７に記載の通信装置のメッセージ送信方法。
【請求項１０】
前記添付方式は、少なくともＳＷＡ方式、ＷＳＡ方式、ＭＴＯＭ方式のいずれかを含むことを特徴とする請求項７又は９に記載の通信装置のメッセージ送信方法。
【請求項１１】
前記添付方式は、少なくともＳＷＡ方式、ＷＳＡ方式、ＭＴＯＭ方式のいずれかを含むことを特徴とする請求項８に記載の通信装置のメッセージ受信方法。
【請求項１２】
送信側通信装置と受信側通信装置との間に介在し、ネットワークを介して接続された通信装置との間で送受信するメッセージとして、コンテンツデータを添付したテキスト形式の構造化文書の送受信を中継する中継装置の中継方法であって、
前記送信側通信装置が対応可能な添付方式でバイナリ形式のコンテンツデータを添付するとともに、前記バイナリ形式のコンテンツデータを添付した添付方式を示すデータ型を示すメッセージを受信する受信ステップと、
前記受信側通信装置が対応可能な添付形式を問い合わせる問い合わせステップと、
前記受信ステップにおいて受信されたデータ型に対応する添付方式と、前記問い合わせステップにおいて問い合わせ結果から得られた受信側通信装置が対応可能な添付形式とに基づいて、前記バイナリ形式のコンテンツデータの添付形式を変換するためのメソッドを選択する選択ステップと、
前記選択ステップにおいて選択されたメソッドを用いて前記バイナリ形式のコンテンツデータの添付形式が変換されたメッセージを前記受信側装置に送信する送信ステップとを有することを特徴とする中継装置の中継方法。
【請求項１３】
前記添付方式は、少なくともＳＷＡ方式、ＷＳＡ方式、ＭＴＯＭ方式のいずれかを含むことを特徴とする請求項１２に記載の中継装置の中継方法。
【請求項１】
ネットワークを介して接続された通信装置との間で送受信するメッセージとして、バイナリ形式のコンテンツデータを添付したテキスト形式の構造化文書を生成する通信装置であって、
送信側と受信側の通信装置間のウェブサービスのインターフェース定義であって、前記構造化文書に添付可能なコンテンツデータの添付方式を示す複数種類のデータ型を示す抽象データ型の記述を有するインターフェース定義を記憶する記憶手段と、
前記インターフェース定義に記述されたデータ型に対応する添付方式のうち、前記通信装置が対応可能な添付方式でバイナリ形式のコンテンツデータを添付するとともに、バイナリ形式のコンテンツデータを添付した添付方式を示すデータ型を示すメッセージを生成するメッセージ生成手段と、
前記バイナリ形式のコンテンツデータが添付されたメッセージを送信する送信手段と、を有することを特徴とする通信装置。
【請求項２】
ネットワークを介して接続された通信装置との間で送受信するメッセージとして、バイナリ形式のコンテンツデータを添付したテキスト形式の構造化文書を受信する通信装置であって、
送信側と受信側の通信装置間のウェブサービスのインターフェース定義であって、前記構造化文書に添付可能なコンテンツデータの添付方式を示す複数種類のデータ型を示す抽象データ型の記述を有するインターフェース定義を記憶する記憶手段と、
前記記憶手段に記憶されたインターフェース定義に記述されたデータ型が受信したメッセージに記述されているかどうかを判別する判別手段と、
前記判別手段によって前記記憶手段に記憶されたインターフェース定義に記述されたデータ型が前記受信したメッセージに記述されていると判別された場合、前記変別されたデータ型に対応する添付方式に従って、前記添付されているバイナリ形式のコンテンツデータを抽出する抽出手段と、
前記抽出手段により抽出した前記バイナリ形式のコンテンツデータのパス名を設定してメモリに記憶する記憶制御手段と、
を有することを特徴とする通信装置。
【請求項３】
前記メッセージ生成手段は、前記通信装置が前記インターフェースに記述されている添付方式のうち複数の添付方式に対応可能な場合、前記対応可能な添付方式のうち、前記インターフェース内で最も先に記述されているデータ型に対応する添付方式で、前記バイナリ形式のコンテンツデータを添付することを特徴とする請求項１に記載の通信装置。
【請求項４】
前記添付方式は、少なくともＳＷＡ方式、ＷＳＡ方式、ＭＴＯＭ方式のいずれかを含むことを特徴とする請求項１乃至３のいずれか１項に記載の通信装置。
【請求項５】
送信側通信装置と受信側通信装置との間に介在し、ネットワークを介して接続された通信装置との間で送受信するメッセージとして、コンテンツデータを添付したテキスト形式の構造化文書の送受信を中継する中継装置であって、
前記送信側通信装置が対応可能な添付方式でバイナリ形式のコンテンツデータを添付するとともに、前記バイナリ形式のコンテンツデータを添付した添付方式を示すデータ型を示すメッセージを受信する受信手段と、
前記受信側通信装置が対応可能な添付形式を問い合わせる問い合わせ手段と、
前記受信手段によって受信されたデータ型に対応する添付方式と、前記問い合わせ手段によって問い合わせ結果から得られた受信側通信装置が対応可能な添付形式とに基づいて、前記バイナリ形式のコンテンツデータの添付形式を変換するためのメソッドを選択する選択手段と、
前記選択手段によって選択されたメソッドを用いて前記バイナリ形式のコンテンツデータの添付形式が変換されたメッセージを送信する送信手段とを有することを特徴とする中継装置。
【請求項６】
前記添付方式は、少なくともＳＷＡ方式、ＷＳＡ方式、ＭＴＯＭ方式のいずれかを含むことを特徴とする請求項５に記載の中継装置。
【請求項７】
ネットワークを介して接続された通信装置との間で送受信するメッセージとして、バイナリ形式のコンテンツデータを添付したテキスト形式の構造化文書を生成する通信装置のメッセージ送信方法であって、
送信側と受信側の通信装置間のウェブサービスのインターフェース定義であって、前記構造化文書に添付可能なコンテンツデータの添付方式を示す複数種類のデータ型を示す抽象データ型の記述を有するインターフェース定義を参照する参照ステップと、
前記インターフェース定義に記述されたデータ型に対応する添付方式のうち、前記通信装置が対応可能な添付方式でバイナリ形式のコンテンツデータを添付するとともに、バイナリ形式のコンテンツデータを添付した添付方式を示すデータ型を示すメッセージを生成するメッセージ生成ステップと、
前記バイナリ形式のコンテンツデータが添付されたメッセージを送信する送信ステップと、
を有することを特徴とする通信装置のメッセージ送信方法。
【請求項８】
ネットワークを介して接続された通信装置との間で送受信するメッセージとして、バイナリ形式のコンテンツデータを添付したテキスト形式の構造化文書を受信する通信装置のメッセージ受信方法であって、
送信側と受信側の通信装置間のウェブサービスのインターフェース定義であって、前記構造化文書に添付可能なコンテンツデータの添付方式を示す複数種類のデータ型を示す抽象データ型の記述を有するインターフェース定義を参照する参照ステップと、
前記インターフェース定義に記述されたデータ型が受信したメッセージに記述されているかどうかを判別する判別ステップと、
前記判別ステップにおいて前記インターフェース定義に記述されたデータ型が前記受信したメッセージに記述されていると判別された場合、前記変別されたデータ型に対応する添付方式に従って、前記添付されているバイナリ形式のコンテンツデータを抽出する抽出ステップと、
前記抽出ステップにおいて抽出した前記バイナリ形式のコンテンツデータのパス名を設定してメモリに記憶する記憶制御ステップと、
を有することを特徴とする通信装置のメッセージ受信方法。
【請求項９】
前記メッセージ生成ステップにおいて、前記通信装置が前記インターフェースに記述されている添付方式のうち複数の添付方式に対応可能な場合、前記対応可能な添付方式のうち、前記インターフェース内で最も先に記述されているデータ型に対応する添付方式で、前記バイナリ形式のコンテンツデータが添付されることを特徴とする請求項７に記載の通信装置のメッセージ送信方法。
【請求項１０】
前記添付方式は、少なくともＳＷＡ方式、ＷＳＡ方式、ＭＴＯＭ方式のいずれかを含むことを特徴とする請求項７又は９に記載の通信装置のメッセージ送信方法。
【請求項１１】
前記添付方式は、少なくともＳＷＡ方式、ＷＳＡ方式、ＭＴＯＭ方式のいずれかを含むことを特徴とする請求項８に記載の通信装置のメッセージ受信方法。
【請求項１２】
送信側通信装置と受信側通信装置との間に介在し、ネットワークを介して接続された通信装置との間で送受信するメッセージとして、コンテンツデータを添付したテキスト形式の構造化文書の送受信を中継する中継装置の中継方法であって、
前記送信側通信装置が対応可能な添付方式でバイナリ形式のコンテンツデータを添付するとともに、前記バイナリ形式のコンテンツデータを添付した添付方式を示すデータ型を示すメッセージを受信する受信ステップと、
前記受信側通信装置が対応可能な添付形式を問い合わせる問い合わせステップと、
前記受信ステップにおいて受信されたデータ型に対応する添付方式と、前記問い合わせステップにおいて問い合わせ結果から得られた受信側通信装置が対応可能な添付形式とに基づいて、前記バイナリ形式のコンテンツデータの添付形式を変換するためのメソッドを選択する選択ステップと、
前記選択ステップにおいて選択されたメソッドを用いて前記バイナリ形式のコンテンツデータの添付形式が変換されたメッセージを前記受信側装置に送信する送信ステップとを有することを特徴とする中継装置の中継方法。
【請求項１３】
前記添付方式は、少なくともＳＷＡ方式、ＷＳＡ方式、ＭＴＯＭ方式のいずれかを含むことを特徴とする請求項１２に記載の中継装置の中継方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２００７−４８２１５（Ｐ２００７−４８２１５Ａ）
【公開日】平成１９年２月２２日（２００７．２．２２）
【国際特許分類】
【出願番号】特願２００５−２３４６９７（Ｐ２００５−２３４６９７）
【出願日】平成１７年８月１２日（２００５．８．１２）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成１９年２月２２日（２００７．２．２２）
【国際特許分類】
【出願日】平成１７年８月１２日（２００５．８．１２）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]