JP2007011470A - サービス処理方法、装置及びプログラム - Google Patents

Abstract

【課題】 ＷＳＤＬでインターフェース定義が記述される場合、複数の型や種別に対応して冗長な記述が提供される可能性がある。しかし、利用者側は必要な型や種別以外のインターフェース定義は取得不要であり、ネットワーク帯域の無駄な利用や、メモリリソースの無駄な使用などが発生する。
【解決手段】 インターフェース定義要求を受けた（Ｓ５０１）インターフェース定義提供装置は、要求されたデータ型やプロトコル種別などから必要なインターフェース定義を生成し（Ｓ５０２〜５０７）、生成したインターフェース定義を送信する（Ｓ５０８）。
【選択図】 図５

Description

本発明は、ネットワークを介して、サービスを利用する際のサービス処理方法、装置及びプログラムに関する。

近年、インターネットの普及により、コンピュータやデジタル機器から、ネットワーク上のＷｅｂサービスを利用することが多くなってきている。Ｗｅｂサービスとは、ネットワーク上でオープンな仕様で公開されるソフトウェア部品のことである。Ｗｅｂサイト検索サービス、辞書サービス、地図参照サービス、ホテル予約サービスなどが一例である。

一般に、コンピュータ、デジタル機器とＷｅｂサービス間でメッセージを送受信する際のインターフェースは、ＷＳＤＬ（Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）で記述され公開されることが多い。ＷＳＤＬは、インターネット技術の標準化団体であるＷ３Ｃ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ）で仕様が策定されているサービス記述言語である。

Ｗｅｂサービスの利用者は、この公開されているＷＳＤＬで記述されたインターフェース定義を参照する。そして、Ｗｅｂサービスを利用するアプリケーションプログラムのスタブ、スケルトンコードを作成したり、送受信に使用するメッセージを動的に生成したりすることができる。

なお、ＷＳＤＬで記述されたインターフェース定義は、抽象的な定義部分とプロトコルバインディング定義部分などから構成される。抽象的な定義部分は、色々な通信プロトコルで共通に使うことができる。プロトコルバインディング定義部分は、通信プロトコルごとに具体的なメッセージ構成やメッセージ送受信のためのアドレスを定義する。

Ｗｅｂサービスを提供する装置上で公開するインターフェース定義は、ネットワークで接続された他装置上で動作するアプリケーション等がＷｅｂサービス利用の前にダウンロードすることが多い。ある装置からのインターフェース定義のダウンロード要求があった場合、メモリなど記憶装置に保存してあるＷＳＤＬ定義をそのままダウンロードする方法がある。その他、インターフェース定義をＷｅｂサービス提供側の装置の状態によって要求ごとに動的に生成、カスタマイズした後ダウンロードする方法が提案されている（例えば［特許文献１］参照）。
特開２００２−２１５４８６号公報

しかしながら、インターフェース定義は、Ｗｅｂサービス提供側の静的、動的な状況をもとに公開されることになるため、特定のＷｅｂサービス利用側が利用できる形式で、記述を最適化することができなかった。

たとえば、ＷＳＤＬの抽象定義部分の一部であるｔｙｐｅｓ要素は、Ｗｅｂサービス利用時に送受信するメッセージフォーマット内の各パラメータのデータ型を定義するのに使用される。そのデータ型を定義するのに使用されるスキーマ定義言語についてはＷＳＤＬの仕様では限定されていない。現在、Ｗ３Ｃで仕様が策定されているＸＭＬＳｃｈｅｍａ言語が使用されることが多いが、今後、特にリソースが不足しがちなコンシューマ向け電子機器などでは、より軽量なＩＳＯのＲｅｌａｘＮＧ仕様が使われる可能性もあり得る。これにより、サービス要求側の装置では、異なるスキーマ言語を利用する実装が混在する可能性がでてくる。Ｗｅｂサービス提供側は、異なるスキーマ言語で記述されたｔｙｐｅｓ要素をもつインターフェース定義を公開しなければ異なるサービス要求側の実装に対応することができない。

また、ＷＳＤＬのバインディング定義部分の一部であるｂｉｎｄｉｎｇ要素では、メッセージ構成、メッセージ送信先アドレスを複数定義することができる。抽象定義部分で定義されたメッセージ定義を、Ｗ３Ｃのプロトコル仕様であるＳＯＡＰや、ＨＴＴＰなど具体的な通信プロトコルに適用したときなどである。実際に特定の装置上で動作するＷｅｂサービス利用者側のアプリケーションは、そのプロトコルの中で、自身が利用可能な特定のプロトコルを利用することが多いと考えられる。利用しないプロトコルに関するインターフェース定義の記述は不要である。

上記の例でわかるように、ＷＳＤＬで記述されたインターフェース定義は、個々のＷｅｂサービス利用者側装置にとっては冗長な記述とならざるを得ない。実際にＷｅｂサービス利用側の装置がインターフェース定義を利用する場合には、ダウンロードする際のネットワーク帯域の無駄な使用がある。また、不要な定義部分をインターフェース定義の解析プログラムに解釈させなければならなくなるというプロセッサ、メモリなどのリソースの無駄な使用が発生する。特に、後者については、リソースが不足しがちなコンシューマ向け電子機器などで今後Ｗｅｂサービス技術を適用していく際の弊害となり得る。

そこで、本発明は、Ｗｅｂサービス利用（要求）側装置が利用（要求）する最適なインターフェース定義を取得することを目的とする。

上記の課題を解決するため、本発明によるサービス処理方法は以下の構成を備える。すなわち、ネットワークを介して接続された装置間のインターフェースの定義をサービス記述言語で記述した文書を保持手段に保持させ、該文書を用いてサービス提供装置がサービスを提供処理する方法において、インターフェース定義の取得要求をサービス要求装置から受信する受信工程と、前記取得要求からデータ型の指定要件を抽出する抽出工程と、前記抽出されたデータ型に対応する前記文書の部分からインターフェース定義を生成するインターフェース定義生成工程と、前記生成されたインターフェース定義をサービス要求装置に送信する送信工程。

上記の課題を解決するため、本発明によるサービス処理方法は以下の構成を備える。すなわち、ネットワークを介して接続された装置間のインターフェースの定義をサービス要求装置が要求処理する方法において、取得要求するインターフェース定義のデータ型を指定する指定工程と、前記インターフェース定義の取得要求をサービス提供装置に送信する送信工程と、サービス提供装置で生成されたインターフェース定義を受信する受信工程。

上記の課題を解決するため、本発明によるサービス処理装置は以下の構成を備える。すなわち、ネットワークを介して接続された装置間のインターフェースの定義をサービス記述言語で記述した文書を保持手段に保持させ、該文書を用いてサービスを提供処理する装置において、インターフェース定義の取得要求をサービス要求装置から受信する受信手段と、前記取得要求に含まれるデータ型を抽出する抽出手段と、前記抽出されたデータ型に対応する前記文書の部分からインターフェース定義を生成するインターフェース定義生成手段と、前記生成されたインターフェース定義をサービス要求装置に送信する送信手段。

上記の課題を解決するため、本発明によるサービス処理装置は以下の構成を備える。すなわち、ネットワークを介して接続された装置間のインターフェースの定義を要求するサービス要求処理装置において、取得要求するインターフェース定義のデータ型を指定する指定手段と、前記インターフェース定義の取得要求をサービス提供装置に送信する送信手段と、サービス提供装置で生成されたインターフェース定義を受信する受信手段。

上記の課題を解決するため、本発明によるプログラムは以下の構成を備える。すなわち、ネットワークを介して接続された装置間のインターフェースの定義をサービス記述言語で記述した文書を保持手段に保持させ、該文書を用いてサービスを提供処理する装置で実行されるプログラムであって、インターフェース定義の取得要求をサービス要求装置から受信する受信ステップと、前記取得要求に含まれるデータ型を抽出する抽出ステップと、前記抽出されたデータ型に対応する前記文書の部分からインターフェース定義を生成するインターフェース定義生成ステップと、前記生成されたインターフェース定義をサービス要求装置に送信する送信ステップ。

上記の課題を解決するため、本発明によるプログラムは以下の構成を備える。すなわち、ネットワークを介して接続された装置間のインターフェースの定義を要求するサービス要求処理装置で実行されるプログラムであって、取得要求するインターフェース定義のデータ型を指定する指定ステップと、前記インターフェース定義の取得要求をサービス提供装置に送信する送信ステップと、サービス提供装置で生成されたインターフェース定義を受信する受信ステップ。

本発明によれば、Ｗｅｂサービスなどの公開されたソフトウェア部品の利用または要求において、利用または要求側の要件を満たしたインターフェース定義を取得することができる。

以下、本発明の実施の形態について図面を参照して説明する。

＜実施形態１＞
図１、図６、図７、図８を使用して、本発明が適用されるシステムの構成例を説明する。ネットワーク１４０には、インターフェース定義要求側装置１１０とインターフェース定義提供側装置１２０が接続されている。インターフェース定義要求側装置１１０とインターフェース定義提供側装置１２０との間では、ネットワーク１４０を経由し、Ｗｅｂサービスのインターフェース定義の要求命令およびインターフェース定義が送受信される。通信プロトコルには、例えばＴＣＰ、ＨＴＴＰ、ＳＯＡＰなどがある。

ここで、一般的インターフェース定義要求側装置１１０、インターフェース定義提供側装置１２０として、例えば、パーソナルコンピュータ、サーバコンピュータ、デジタル機器などが考えられる。なお、この実施例では、インターフェース定義要求側装置１１０、インターフェース定義提供側装置１２０は１つずつしか説明されていないが、それぞれ複数存在しても構わない。

また、本実施形態では、インターフェース定義要求側装置とインターフェース定義提供側装置が直接ネットワークを介してデータの送受信を行っているが、中継や仲介する装置が加わった構成になっても良い。また、ＵＤＤＩ（（Ｕｎｉｖｅｒｓａｌ Ｄｅｓｃｒｉｐｔｉｏｎ，Ｄｉｓｃｏｖｅｒｙ ａｎｄ Ｉｎｔｅｇｒａｔｉｏｎ）レジストリにインターフェース定義提供側装置がＷｅｂサービスを登録し、そのＷｅｂサービスを要求側装置が参照するような構成でも良い。

インターフェース定義提供側装置１２０には、サービス提供アプリケーション１２８が提供するＷｅｂサービスのインターフェース定義を保存するための記憶装置１３１が接続されている。

記憶装置１３１内の構成を示す。抽象定義部分１３２は、送受信メッセージ組み合わせ方法、メッセージを構成するパラメータのデータ型などを定義している。バインディング定義部分１３３は、抽象定義部分１３２で定義した内容が、通信プロトコルごとにどのように適用されるかを定義している。メイン部１３１は、それら二つを参照して１つのインターフェース定義としてまとめている。図６にメイン部１３１、図７に抽象定義部分１３２、図８にバインディング定義部分１３３をＷＳＤＬで記述した例をそれぞれあげる。図７、８はそれぞれ、ＸＭＬＳｃｈｅｍａ、ＳＯＡＰで記述されている。なお、サービス提供アプリケーション１２８は、インターフェース定義提供側装置以外のネットワークに接続された装置上にある場合もある。

インターフェース定義要求側装置１１０の構成を示す。インターフェース定義取得部１１４は、インターフェース定義利用アプリケーション１１１からのインターフェース定義の取得要求を、インターフェース定義提供側装置１２０に対し、ネットワーク１４０を経由し送信する。その結果としてインターフェース定義を取得する。抽象定義部分要件指定部１１２は、取得要求命令を送信する際にインターフェース定義利用アプリケーション１１１がインターフェース定義の抽象定義部分の要件を指定する。バインディング定義部分要件指定部１１３は、取得要求命令を送信する際にインターフェース定義利用アプリケーション１１１がインターフェース定義のバインディング定義部分の要件を指定する。

なお、インターフェース定義利用アプリケーション１１１の例をあげる。Ｗｅｂサービスを利用するアプリケーションのソースコードを生成するアプリケーション開発ツールや、通信プロトコルに適したメッセージを動的に生成するＷＳＤＬインタプリタなどである。ＷＳＤＬインタプリタはＷｅｂサービスフレームワークで提供される。

インターフェース定義提供側装置１２０の構成を示す。インターフェース定義要求受付部１２１は、インターフェース定義要求側装置１１０からネットワーク１４０経由でインターフェース定義取得要求命令を受信する。インターフェース定義生成部１２２は、インターフェース定義取得要求命令を解析・抽出し、命令に記述された要件を元に、インターフェース定義を生成する。インターフェース定義取得要求命令には、抽象定義部分の要件、バインディング定義部分の要件が記述されている。抽象定義部分選択部１２３は、抽象定義部分の要件と、記憶装置１３０に保存された複数の抽象定義部分１３２の一覧情報を保存した抽象定義部分一覧表１２５から、要件に合った抽象定義部分１３２を選択する。バインディング定義部分選択部１２４は、記憶装置１３０に保存された複数のバインディング定義部分１３３の一覧情報を保存したバインディング定義部分一覧表１２６から、要件に合ったバインディング定義部分１３３を選択する。インターフェース定義送信部１２７は、インターフェース定義生成部により生成されたインターフェース定義をインターフェース定義要求側装置１１０に送信する。

次に、図４を使用して、本実施例における、インターフェース定義要求側装置上での処理の流れを説明する。図４において、インターフェース定義要求側装置１１０上でインターフェース定義利用アプリケーション１１１が、抽象定義部分要件指定部１１２に対し、抽象定義部分に対する要件を指定する。ここでは、インターフェース定義言語中のデータ型を定義するのに使用するスキーマ定義言語としてＷ３Ｃ ＸＭＬ Ｓｃｈｅｍａを指定するとする（ステップＳ４０１）。

次に、インターフェース定義利用アプリケーション１１１は、バインディング定義部分指定部１１３に対し、バインディング定義部分に対する要件を指定する。ここでは、インターフェース定義中で記述が必要なプロトコルとしてＳＯＡＰプロトコルを指定するとする（ステップＳ４０２）。

その後、インターフェース定義量アプリケーション１１１は、インターフェース定義取得部１１４に対し、インターフェース定義提供側装置１２０上のインターフェース定義の取得要求を行う（ステップＳ４０３）。

インターフェース定義言語取得部１１４は、ステップＳ４０１、ステップＳ４０２で指定されたインターフェース定義に対する要件を元に、インターフェース定義取得命令を作成する（ステップＳ４０４）。そして、インターフェース提供側装置１２０に送信（ステップＳ４０５）する。以下に、ＨＴＴＰのＧＥＴメソッドで取得命令を作成した場合の一例（ＵＲＩ）を記述する。
ｈｔｔｐ：／／ｐｒｏｖｉｄｅｒ／ｗｓｄｌ？ＡｂｓｔｒｕｃｔＲｅｑ＝ＸＭＬ＿Ｓｃｈｅｍａ＆ＢｉｎｄｉｎｇＲｅｑ＝ＳＯＡＰ
インターフェース定義提供側装置１２０でインターフェース定義が生成され、送信されたインターフェース定義は、インターフェース定義取得部１１４によって受信される（ステップＳ４０７）。

インターフェース定義を受信したインターフェース定義取得部１１４は、インターフェース定義利用アプリケーション１１１にインターフェース定義を返却する（ステップＳ４０８）。

次に、図５を使用して、本実施例における、インターフェース定義要求側装置１２０上での処理の流れを説明する。ネットワーク１４０経由で、インターフェース定義利用側装置からインターフェース定義の取得要求をインターフェース定義提供要求受付部１２１が受信する。そして、取得命令を解析して抽象定義に対する要件（ＡｂｓｔｒｕｃｔＲｅｑ＝ＸＭＬ＿Ｓｃｈｅｍａ）と、バインディング定義に対する要件（ＢｉｎｄｉｎｇＲｅｑ＝ＳＯＡＰ”）とを抽出し取得する。その後、インターフェース定義生成部１２２に対しこの要件を満たすインターフェース定義の生成要求を行う（ステップＳ５０１，ステップＳ５０２）。

要求をされたインターフェース定義生成部１２２は、抽象定義部分選択部１２３に対し、要件（ＡｂｓｔｒｕｃｔＲｅｑ＝ＸＭＬ＿Ｓｃｈｅｍａ）を満たす抽象定義部分１３２のパス名を要求する（ステップＳ５０３）。

要求を受けた抽象定義部分選択部１２３は、指定された要件と、抽象定義部分一覧表１２５を比較して、要件に合った抽象定義部分１３２のパス名を取得し、インターフェース定義生成部１２２に渡す（ステップＳ５０４）。図２は、抽象定義一覧表の例である。この例ではパラメータ名２０１がＡｂｓｔｒｕｃｔＲｅｑ、パラメータ値ＸＭＬ＿Ｓｃｈｅｍａが一致する行の抽象定義格納ファイルのパス名が、／ｗｓｄｌ／ａｂｓｔｒｕｃｔｘｓｄ／ａ．ｗｓｄｌに格納されていることがわかる。

同様に、インターフェース定義生成部１２２は、バインディング定義部分選択部１２４に対し、バインディング定義部分に対する要件（ＢｉｎｄｉｎｇＲｅｑ＝ＳＯＡＰ）を満たすバインディング定義部分１３３のパス名を要求する（ステップＳ５０５）。

要求を受けたバインディング定義部分選択部１２４は、指定された要件と、バインディング定義部分一覧表１２６を比較して、要件に合ったバインディング定義部分１３３のパス名を取得する。そして、インターフェース定義生成部１２２に渡す（ステップＳ５０６）。図３はバインディング定義一覧表１２６の例である。

インターフェース定義生成部１２２は、インターフェース定義送信部１２７にインターフェース定義要求側装置１１０への送信要求を行い（ステップＳ５０７）、インターフェース定義送信部１２７が送信する。（ステップＳ５０８）。そのとき、インターフェース定義のメイン部１３１と、取得した抽象定義部分１３２、バインディング定義部分１３３のパス名を指定している。図６、図７、図８はそれぞれインターフェース定義のメイン部、抽象定義部分、バインディング定義部分の例である。なお、この例では、メイン部を記述するファイルで、ＷＳＤＬの外部参照（ｉｍｐｏｒｔ）を使って抽象定義部分、バインディング定義部分を記述するファイル名を参照している。このように、３つのファイルをそのまま送信している他、外部参照を使用せず、インターフェース定義生成部１２２が１つのファイルに合成してから送信要求を行なってもよい。

本発明の目的は前述した実施例の機能を実現するソフトウエアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵまたはＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施例の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施例の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

ネットワーク上でインターフェース定義を要求、取得するためのシステム構成を表すブロック図。 記憶装置上に保存されたインターフェース定義の抽象定義部分を一覧として保持する抽象定義一覧表の例。 記憶装置上に保存されたインターフェース定義のバインディング定義部分を一覧として保持するバインディング定義一覧表の例。 インターフェース定義要求側装置におけるインターフェース定義取得手順を説明するフローチャート。 インターフェース定義提供側装置におけるインターフェース定義提供手順を説明するフローチャート。 インターフェース定義の論理定義部分、バインディング定義部分部を参照して１つのインターフェース定義としてまとめるためのメイン部の記述例。 インターフェース定義の論理定義部分の記述例。 インターフェース定義のバインディング定義部分の記述例。

Claims (13)

1. ネットワークを介して接続された装置間のインターフェースの定義をサービス記述言語で記述した文書を保持手段に保持させ、該文書を用いてサービス提供装置がサービスを提供処理する方法において、
   インターフェース定義の取得要求をサービス要求装置から受信する受信工程と、
   前記取得要求からデータ型の指定要件を抽出する抽出工程と、
   前記抽出されたデータ型に対応する前記文書の部分からインターフェース定義を生成するインターフェース定義生成工程と、
   前記生成されたインターフェース定義をサービス要求装置に送信する送信工程と、
   を備えることを特徴とするサービス処理方法。
2. ネットワークを介して接続された装置間のインターフェースの定義をサービス要求装置が要求処理する方法において、
   取得要求するインターフェース定義のデータ型を指定する指定工程と、
   前記インターフェース定義の取得要求をサービス提供装置に送信する送信工程と、
   サービス提供装置で生成されたインターフェース定義を受信する受信工程と、
   を備えることを特徴とするサービス処理方法。
3. 前記インターフェース定義がサービス記述言語であるＷＳＤＬ（Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）で記述されていることを特徴とする請求項１または２記載のサービス処理方法。
4. 前記インターフェース定義に、抽象定義部分とバインディング定義部分を含むことを特徴とする請求項１乃至３記載のサービス処理方法。
5. 前記抽象定義部分でＸＭＬＳｃｈｅｍａまたはＲｅｌａｘＮＧを含むスキーマ言語を用いることを特徴とする請求項４記載のサービス処理方法。
6. 前記バインディング定義部分でＳＯＡＰまたはＨＴＴＰまたはＳＭＴＰを含む通信プロトコル種別を用いることを特徴とする請求項４記載のサービス処理方法。
7. 前記インターフェース定義生成工程では、前記抽象定義部分と前記バインディング定義部分に基づいてインターフェース定義を生成することを特徴とする請求項４記載のサービス処理方法。
8. 前記インターフェース定義生成工程では、ＸＭＬＳｃｈｅｍａまたはＲｅｌａｘＮＧを含むスキーマ言語で記述された前記抽象定義部分のうち、前記抽出されたデータ型に対応する前記文書の部分からインターフェース定義を生成することを特徴とする請求項５に記載のサービス処理方法。
9. 前記インターフェース定義生成工程では、ＳＯＡＰまたはＨＴＴＰまたはＳＭＴＰを含む通信プロトコル種別で記述されたバインディング定義部分のうち、前記抽出されたデータ型に対応する前記文書の部分からインターフェース定義を生成することを特徴とする請求項６に記載のサービス処理方法。
10. ネットワークを介して接続された装置間のインターフェースの定義をサービス記述言語で記述した文書を保持手段に保持させ、該文書を用いてサービスを提供処理する装置において、
    インターフェース定義の取得要求をサービス要求装置から受信する受信手段と、
    前記取得要求に含まれるデータ型を抽出する抽出手段と、
    前記抽出されたデータ型に対応する前記文書の部分からインターフェース定義を生成するインターフェース定義生成手段と、
    前記生成されたインターフェース定義をサービス要求装置に送信する送信手段と、
    を備えることを特徴とするサービス処理装置。
11. ネットワークを介して接続された装置間のインターフェースの定義を要求するサービス要求処理装置において、
    取得要求するインターフェース定義のデータ型を指定する指定手段と、
    前記インターフェース定義の取得要求をサービス提供装置に送信する送信手段と、
    サービス提供装置で生成されたインターフェース定義を受信する受信手段と、
    を備えることを特徴とするサービス処理装置。
12. ネットワークを介して接続された装置間のインターフェースの定義をサービス記述言語で記述した文書を保持手段に保持させ、該文書を用いてサービスを提供処理する装置で実行されるプログラムであって、
    インターフェース定義の取得要求をサービス要求装置から受信する受信ステップと、
    前記取得要求に含まれるデータ型を抽出する抽出ステップと、
    前記抽出されたデータ型に対応する前記文書の部分からインターフェース定義を生成するインターフェース定義生成ステップと、
    前記生成されたインターフェース定義をサービス要求装置に送信する送信ステップと、
    を備えることを特徴とするプログラム。
13. ネットワークを介して接続された装置間のインターフェースの定義を要求するサービス要求処理装置で実行されるプログラムであって、
    取得要求するインターフェース定義のデータ型を指定する指定ステップと、
    前記インターフェース定義の取得要求をサービス提供装置に送信する送信ステップと、
    サービス提供装置で生成されたインターフェース定義を受信する受信ステップと、
    を備えることを特徴とするプログラム。

Images