米国特許情報 | 欧州特許情報 | 国際公開(PCT)情報 | Google の米国特許検索
 
     特許分類
A 農業
B 衣類
C 家具
D 医学
E スポ−ツ;娯楽
F 加工処理操作
G 机上付属具
H 装飾
I 車両
J 包装;運搬
L 化学;冶金
M 繊維;紙;印刷
N 固定構造物
O 機械工学
P 武器
Q 照明
R 測定; 光学
S 写真;映画
T 計算機;電気通信
U 核技術
V 電気素子
W 発電
X 楽器;音響


  ホーム -> 計算機;電気通信 -> キヤノン株式会社

発明の名称 サービス処理方法、装置及びプログラム
発行国 日本国特許庁(JP)
公報種別 公開特許公報(A)
公開番号 特開2007−11470(P2007−11470A)
公開日 平成19年1月18日(2007.1.18)
出願番号 特願2005−188298(P2005−188298)
出願日 平成17年6月28日(2005.6.28)
代理人 【識別番号】100090538
【弁理士】
【氏名又は名称】西山 恵三
発明者 田宮 圭介
要約 課題
WSDLでインターフェース定義が記述される場合、複数の型や種別に対応して冗長な記述が提供される可能性がある。しかし、利用者側は必要な型や種別以外のインターフェース定義は取得不要であり、ネットワーク帯域の無駄な利用や、メモリリソースの無駄な使用などが発生する。

解決手段
インターフェース定義要求を受けた(S501)インターフェース定義提供装置は、要求されたデータ型やプロトコル種別などから必要なインターフェース定義を生成し(S502〜507)、生成したインターフェース定義を送信する(S508)。
特許請求の範囲
【請求項1】
ネットワークを介して接続された装置間のインターフェースの定義をサービス記述言語で記述した文書を保持手段に保持させ、該文書を用いてサービス提供装置がサービスを提供処理する方法において、
インターフェース定義の取得要求をサービス要求装置から受信する受信工程と、
前記取得要求からデータ型の指定要件を抽出する抽出工程と、
前記抽出されたデータ型に対応する前記文書の部分からインターフェース定義を生成するインターフェース定義生成工程と、
前記生成されたインターフェース定義をサービス要求装置に送信する送信工程と、
を備えることを特徴とするサービス処理方法。
【請求項2】
ネットワークを介して接続された装置間のインターフェースの定義をサービス要求装置が要求処理する方法において、
取得要求するインターフェース定義のデータ型を指定する指定工程と、
前記インターフェース定義の取得要求をサービス提供装置に送信する送信工程と、
サービス提供装置で生成されたインターフェース定義を受信する受信工程と、
を備えることを特徴とするサービス処理方法。
【請求項3】
前記インターフェース定義がサービス記述言語であるWSDL(Web Services Description Language)で記述されていることを特徴とする請求項1または2記載のサービス処理方法。
【請求項4】
前記インターフェース定義に、抽象定義部分とバインディング定義部分を含むことを特徴とする請求項1乃至3記載のサービス処理方法。
【請求項5】
前記抽象定義部分でXMLSchemaまたはRelaxNGを含むスキーマ言語を用いることを特徴とする請求項4記載のサービス処理方法。
【請求項6】
前記バインディング定義部分でSOAPまたはHTTPまたはSMTPを含む通信プロトコル種別を用いることを特徴とする請求項4記載のサービス処理方法。
【請求項7】
前記インターフェース定義生成工程では、前記抽象定義部分と前記バインディング定義部分に基づいてインターフェース定義を生成することを特徴とする請求項4記載のサービス処理方法。
【請求項8】
前記インターフェース定義生成工程では、XMLSchemaまたはRelaxNGを含むスキーマ言語で記述された前記抽象定義部分のうち、前記抽出されたデータ型に対応する前記文書の部分からインターフェース定義を生成することを特徴とする請求項5に記載のサービス処理方法。
【請求項9】
前記インターフェース定義生成工程では、SOAPまたはHTTPまたはSMTPを含む通信プロトコル種別で記述されたバインディング定義部分のうち、前記抽出されたデータ型に対応する前記文書の部分からインターフェース定義を生成することを特徴とする請求項6に記載のサービス処理方法。
【請求項10】
ネットワークを介して接続された装置間のインターフェースの定義をサービス記述言語で記述した文書を保持手段に保持させ、該文書を用いてサービスを提供処理する装置において、
インターフェース定義の取得要求をサービス要求装置から受信する受信手段と、
前記取得要求に含まれるデータ型を抽出する抽出手段と、
前記抽出されたデータ型に対応する前記文書の部分からインターフェース定義を生成するインターフェース定義生成手段と、
前記生成されたインターフェース定義をサービス要求装置に送信する送信手段と、
を備えることを特徴とするサービス処理装置。
【請求項11】
ネットワークを介して接続された装置間のインターフェースの定義を要求するサービス要求処理装置において、
取得要求するインターフェース定義のデータ型を指定する指定手段と、
前記インターフェース定義の取得要求をサービス提供装置に送信する送信手段と、
サービス提供装置で生成されたインターフェース定義を受信する受信手段と、
を備えることを特徴とするサービス処理装置。
【請求項12】
ネットワークを介して接続された装置間のインターフェースの定義をサービス記述言語で記述した文書を保持手段に保持させ、該文書を用いてサービスを提供処理する装置で実行されるプログラムであって、
インターフェース定義の取得要求をサービス要求装置から受信する受信ステップと、
前記取得要求に含まれるデータ型を抽出する抽出ステップと、
前記抽出されたデータ型に対応する前記文書の部分からインターフェース定義を生成するインターフェース定義生成ステップと、
前記生成されたインターフェース定義をサービス要求装置に送信する送信ステップと、
を備えることを特徴とするプログラム。
【請求項13】
ネットワークを介して接続された装置間のインターフェースの定義を要求するサービス要求処理装置で実行されるプログラムであって、
取得要求するインターフェース定義のデータ型を指定する指定ステップと、
前記インターフェース定義の取得要求をサービス提供装置に送信する送信ステップと、
サービス提供装置で生成されたインターフェース定義を受信する受信ステップと、
を備えることを特徴とするプログラム。
発明の詳細な説明
【技術分野】
【0001】
本発明は、ネットワークを介して、サービスを利用する際のサービス処理方法、装置及びプログラムに関する。
【背景技術】
【0002】
近年、インターネットの普及により、コンピュータやデジタル機器から、ネットワーク上のWebサービスを利用することが多くなってきている。Webサービスとは、ネットワーク上でオープンな仕様で公開されるソフトウェア部品のことである。Webサイト検索サービス、辞書サービス、地図参照サービス、ホテル予約サービスなどが一例である。
【0003】
一般に、コンピュータ、デジタル機器とWebサービス間でメッセージを送受信する際のインターフェースは、WSDL(Web Services Description Language)で記述され公開されることが多い。WSDLは、インターネット技術の標準化団体であるW3C(World Wide Web Consortium)で仕様が策定されているサービス記述言語である。
【0004】
Webサービスの利用者は、この公開されているWSDLで記述されたインターフェース定義を参照する。そして、Webサービスを利用するアプリケーションプログラムのスタブ、スケルトンコードを作成したり、送受信に使用するメッセージを動的に生成したりすることができる。
【0005】
なお、WSDLで記述されたインターフェース定義は、抽象的な定義部分とプロトコルバインディング定義部分などから構成される。抽象的な定義部分は、色々な通信プロトコルで共通に使うことができる。プロトコルバインディング定義部分は、通信プロトコルごとに具体的なメッセージ構成やメッセージ送受信のためのアドレスを定義する。
【0006】
Webサービスを提供する装置上で公開するインターフェース定義は、ネットワークで接続された他装置上で動作するアプリケーション等がWebサービス利用の前にダウンロードすることが多い。ある装置からのインターフェース定義のダウンロード要求があった場合、メモリなど記憶装置に保存してあるWSDL定義をそのままダウンロードする方法がある。その他、インターフェース定義をWebサービス提供側の装置の状態によって要求ごとに動的に生成、カスタマイズした後ダウンロードする方法が提案されている(例えば[特許文献1]参照)。
【特許文献1】特開2002−215486号公報
【発明の開示】
【発明が解決しようとする課題】
【0007】
しかしながら、インターフェース定義は、Webサービス提供側の静的、動的な状況をもとに公開されることになるため、特定のWebサービス利用側が利用できる形式で、記述を最適化することができなかった。
【0008】
たとえば、WSDLの抽象定義部分の一部であるtypes要素は、Webサービス利用時に送受信するメッセージフォーマット内の各パラメータのデータ型を定義するのに使用される。そのデータ型を定義するのに使用されるスキーマ定義言語についてはWSDLの仕様では限定されていない。現在、W3Cで仕様が策定されているXMLSchema言語が使用されることが多いが、今後、特にリソースが不足しがちなコンシューマ向け電子機器などでは、より軽量なISOのRelaxNG仕様が使われる可能性もあり得る。これにより、サービス要求側の装置では、異なるスキーマ言語を利用する実装が混在する可能性がでてくる。Webサービス提供側は、異なるスキーマ言語で記述されたtypes要素をもつインターフェース定義を公開しなければ異なるサービス要求側の実装に対応することができない。
【0009】
また、WSDLのバインディング定義部分の一部であるbinding要素では、メッセージ構成、メッセージ送信先アドレスを複数定義することができる。抽象定義部分で定義されたメッセージ定義を、W3Cのプロトコル仕様であるSOAPや、HTTPなど具体的な通信プロトコルに適用したときなどである。実際に特定の装置上で動作するWebサービス利用者側のアプリケーションは、そのプロトコルの中で、自身が利用可能な特定のプロトコルを利用することが多いと考えられる。利用しないプロトコルに関するインターフェース定義の記述は不要である。
【0010】
上記の例でわかるように、WSDLで記述されたインターフェース定義は、個々のWebサービス利用者側装置にとっては冗長な記述とならざるを得ない。実際にWebサービス利用側の装置がインターフェース定義を利用する場合には、ダウンロードする際のネットワーク帯域の無駄な使用がある。また、不要な定義部分をインターフェース定義の解析プログラムに解釈させなければならなくなるというプロセッサ、メモリなどのリソースの無駄な使用が発生する。特に、後者については、リソースが不足しがちなコンシューマ向け電子機器などで今後Webサービス技術を適用していく際の弊害となり得る。
【0011】
そこで、本発明は、Webサービス利用(要求)側装置が利用(要求)する最適なインターフェース定義を取得することを目的とする。
【課題を解決するための手段】
【0012】
上記の課題を解決するため、本発明によるサービス処理方法は以下の構成を備える。すなわち、ネットワークを介して接続された装置間のインターフェースの定義をサービス記述言語で記述した文書を保持手段に保持させ、該文書を用いてサービス提供装置がサービスを提供処理する方法において、インターフェース定義の取得要求をサービス要求装置から受信する受信工程と、前記取得要求からデータ型の指定要件を抽出する抽出工程と、前記抽出されたデータ型に対応する前記文書の部分からインターフェース定義を生成するインターフェース定義生成工程と、前記生成されたインターフェース定義をサービス要求装置に送信する送信工程。
【0013】
上記の課題を解決するため、本発明によるサービス処理方法は以下の構成を備える。すなわち、ネットワークを介して接続された装置間のインターフェースの定義をサービス要求装置が要求処理する方法において、取得要求するインターフェース定義のデータ型を指定する指定工程と、前記インターフェース定義の取得要求をサービス提供装置に送信する送信工程と、サービス提供装置で生成されたインターフェース定義を受信する受信工程。
【0014】
上記の課題を解決するため、本発明によるサービス処理装置は以下の構成を備える。すなわち、ネットワークを介して接続された装置間のインターフェースの定義をサービス記述言語で記述した文書を保持手段に保持させ、該文書を用いてサービスを提供処理する装置において、インターフェース定義の取得要求をサービス要求装置から受信する受信手段と、前記取得要求に含まれるデータ型を抽出する抽出手段と、前記抽出されたデータ型に対応する前記文書の部分からインターフェース定義を生成するインターフェース定義生成手段と、前記生成されたインターフェース定義をサービス要求装置に送信する送信手段。
【0015】
上記の課題を解決するため、本発明によるサービス処理装置は以下の構成を備える。すなわち、ネットワークを介して接続された装置間のインターフェースの定義を要求するサービス要求処理装置において、取得要求するインターフェース定義のデータ型を指定する指定手段と、前記インターフェース定義の取得要求をサービス提供装置に送信する送信手段と、サービス提供装置で生成されたインターフェース定義を受信する受信手段。
【0016】
上記の課題を解決するため、本発明によるプログラムは以下の構成を備える。すなわち、ネットワークを介して接続された装置間のインターフェースの定義をサービス記述言語で記述した文書を保持手段に保持させ、該文書を用いてサービスを提供処理する装置で実行されるプログラムであって、インターフェース定義の取得要求をサービス要求装置から受信する受信ステップと、前記取得要求に含まれるデータ型を抽出する抽出ステップと、前記抽出されたデータ型に対応する前記文書の部分からインターフェース定義を生成するインターフェース定義生成ステップと、前記生成されたインターフェース定義をサービス要求装置に送信する送信ステップ。
【0017】
上記の課題を解決するため、本発明によるプログラムは以下の構成を備える。すなわち、ネットワークを介して接続された装置間のインターフェースの定義を要求するサービス要求処理装置で実行されるプログラムであって、取得要求するインターフェース定義のデータ型を指定する指定ステップと、前記インターフェース定義の取得要求をサービス提供装置に送信する送信ステップと、サービス提供装置で生成されたインターフェース定義を受信する受信ステップ。
【発明の効果】
【0018】
本発明によれば、Webサービスなどの公開されたソフトウェア部品の利用または要求において、利用または要求側の要件を満たしたインターフェース定義を取得することができる。
【発明を実施するための最良の形態】
【0019】
以下、本発明の実施の形態について図面を参照して説明する。
【0020】
<実施形態1>
図1、図6、図7、図8を使用して、本発明が適用されるシステムの構成例を説明する。ネットワーク140には、インターフェース定義要求側装置110とインターフェース定義提供側装置120が接続されている。インターフェース定義要求側装置110とインターフェース定義提供側装置120との間では、ネットワーク140を経由し、Webサービスのインターフェース定義の要求命令およびインターフェース定義が送受信される。通信プロトコルには、例えばTCP、HTTP、SOAPなどがある。
【0021】
ここで、一般的インターフェース定義要求側装置110、インターフェース定義提供側装置120として、例えば、パーソナルコンピュータ、サーバコンピュータ、デジタル機器などが考えられる。なお、この実施例では、インターフェース定義要求側装置110、インターフェース定義提供側装置120は1つずつしか説明されていないが、それぞれ複数存在しても構わない。
【0022】
また、本実施形態では、インターフェース定義要求側装置とインターフェース定義提供側装置が直接ネットワークを介してデータの送受信を行っているが、中継や仲介する装置が加わった構成になっても良い。また、UDDI((Universal Description,Discovery and Integration)レジストリにインターフェース定義提供側装置がWebサービスを登録し、そのWebサービスを要求側装置が参照するような構成でも良い。
【0023】
インターフェース定義提供側装置120には、サービス提供アプリケーション128が提供するWebサービスのインターフェース定義を保存するための記憶装置131が接続されている。
【0024】
記憶装置131内の構成を示す。抽象定義部分132は、送受信メッセージ組み合わせ方法、メッセージを構成するパラメータのデータ型などを定義している。バインディング定義部分133は、抽象定義部分132で定義した内容が、通信プロトコルごとにどのように適用されるかを定義している。メイン部131は、それら二つを参照して1つのインターフェース定義としてまとめている。図6にメイン部131、図7に抽象定義部分132、図8にバインディング定義部分133をWSDLで記述した例をそれぞれあげる。図7、8はそれぞれ、XMLSchema、SOAPで記述されている。なお、サービス提供アプリケーション128は、インターフェース定義提供側装置以外のネットワークに接続された装置上にある場合もある。
【0025】
インターフェース定義要求側装置110の構成を示す。インターフェース定義取得部114は、インターフェース定義利用アプリケーション111からのインターフェース定義の取得要求を、インターフェース定義提供側装置120に対し、ネットワーク140を経由し送信する。その結果としてインターフェース定義を取得する。抽象定義部分要件指定部112は、取得要求命令を送信する際にインターフェース定義利用アプリケーション111がインターフェース定義の抽象定義部分の要件を指定する。バインディング定義部分要件指定部113は、取得要求命令を送信する際にインターフェース定義利用アプリケーション111がインターフェース定義のバインディング定義部分の要件を指定する。
【0026】
なお、インターフェース定義利用アプリケーション111の例をあげる。Webサービスを利用するアプリケーションのソースコードを生成するアプリケーション開発ツールや、通信プロトコルに適したメッセージを動的に生成するWSDLインタプリタなどである。WSDLインタプリタはWebサービスフレームワークで提供される。
【0027】
インターフェース定義提供側装置120の構成を示す。インターフェース定義要求受付部121は、インターフェース定義要求側装置110からネットワーク140経由でインターフェース定義取得要求命令を受信する。インターフェース定義生成部122は、インターフェース定義取得要求命令を解析・抽出し、命令に記述された要件を元に、インターフェース定義を生成する。インターフェース定義取得要求命令には、抽象定義部分の要件、バインディング定義部分の要件が記述されている。抽象定義部分選択部123は、抽象定義部分の要件と、記憶装置130に保存された複数の抽象定義部分132の一覧情報を保存した抽象定義部分一覧表125から、要件に合った抽象定義部分132を選択する。バインディング定義部分選択部124は、記憶装置130に保存された複数のバインディング定義部分133の一覧情報を保存したバインディング定義部分一覧表126から、要件に合ったバインディング定義部分133を選択する。インターフェース定義送信部127は、インターフェース定義生成部により生成されたインターフェース定義をインターフェース定義要求側装置110に送信する。
【0028】
次に、図4を使用して、本実施例における、インターフェース定義要求側装置上での処理の流れを説明する。図4において、インターフェース定義要求側装置110上でインターフェース定義利用アプリケーション111が、抽象定義部分要件指定部112に対し、抽象定義部分に対する要件を指定する。ここでは、インターフェース定義言語中のデータ型を定義するのに使用するスキーマ定義言語としてW3C XML Schemaを指定するとする(ステップS401)。
【0029】
次に、インターフェース定義利用アプリケーション111は、バインディング定義部分指定部113に対し、バインディング定義部分に対する要件を指定する。ここでは、インターフェース定義中で記述が必要なプロトコルとしてSOAPプロトコルを指定するとする(ステップS402)。
【0030】
その後、インターフェース定義量アプリケーション111は、インターフェース定義取得部114に対し、インターフェース定義提供側装置120上のインターフェース定義の取得要求を行う(ステップS403)。
【0031】
インターフェース定義言語取得部114は、ステップS401、ステップS402で指定されたインターフェース定義に対する要件を元に、インターフェース定義取得命令を作成する(ステップS404)。そして、インターフェース提供側装置120に送信(ステップS405)する。以下に、HTTPのGETメソッドで取得命令を作成した場合の一例(URI)を記述する。
http://provider/wsdl?AbstructReq=XML_Schema&BindingReq=SOAP
インターフェース定義提供側装置120でインターフェース定義が生成され、送信されたインターフェース定義は、インターフェース定義取得部114によって受信される(ステップS407)。
【0032】
インターフェース定義を受信したインターフェース定義取得部114は、インターフェース定義利用アプリケーション111にインターフェース定義を返却する(ステップS408)。
【0033】
次に、図5を使用して、本実施例における、インターフェース定義要求側装置120上での処理の流れを説明する。ネットワーク140経由で、インターフェース定義利用側装置からインターフェース定義の取得要求をインターフェース定義提供要求受付部121が受信する。そして、取得命令を解析して抽象定義に対する要件(AbstructReq=XML_Schema)と、バインディング定義に対する要件(BindingReq=SOAP”)とを抽出し取得する。その後、インターフェース定義生成部122に対しこの要件を満たすインターフェース定義の生成要求を行う(ステップS501,ステップS502)。
【0034】
要求をされたインターフェース定義生成部122は、抽象定義部分選択部123に対し、要件(AbstructReq=XML_Schema)を満たす抽象定義部分132のパス名を要求する(ステップS503)。
【0035】
要求を受けた抽象定義部分選択部123は、指定された要件と、抽象定義部分一覧表125を比較して、要件に合った抽象定義部分132のパス名を取得し、インターフェース定義生成部122に渡す(ステップS504)。図2は、抽象定義一覧表の例である。この例ではパラメータ名201がAbstructReq、パラメータ値XML_Schemaが一致する行の抽象定義格納ファイルのパス名が、/wsdl/abstructxsd/a.wsdlに格納されていることがわかる。
【0036】
同様に、インターフェース定義生成部122は、バインディング定義部分選択部124に対し、バインディング定義部分に対する要件(BindingReq=SOAP)を満たすバインディング定義部分133のパス名を要求する(ステップS505)。
【0037】
要求を受けたバインディング定義部分選択部124は、指定された要件と、バインディング定義部分一覧表126を比較して、要件に合ったバインディング定義部分133のパス名を取得する。そして、インターフェース定義生成部122に渡す(ステップS506)。図3はバインディング定義一覧表126の例である。
【0038】
インターフェース定義生成部122は、インターフェース定義送信部127にインターフェース定義要求側装置110への送信要求を行い(ステップS507)、インターフェース定義送信部127が送信する。(ステップS508)。そのとき、インターフェース定義のメイン部131と、取得した抽象定義部分132、バインディング定義部分133のパス名を指定している。図6、図7、図8はそれぞれインターフェース定義のメイン部、抽象定義部分、バインディング定義部分の例である。なお、この例では、メイン部を記述するファイルで、WSDLの外部参照(import)を使って抽象定義部分、バインディング定義部分を記述するファイル名を参照している。このように、3つのファイルをそのまま送信している他、外部参照を使用せず、インターフェース定義生成部122が1つのファイルに合成してから送信要求を行なってもよい。
【0039】
本発明の目的は前述した実施例の機能を実現するソフトウエアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ(またはCPUまたはMPU)が記録媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【0040】
プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、CD−ROM、CD−R、磁気テープ、不揮発性のメモリカード、ROM、DVDなどを用いることができる。
【0041】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施例の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているOperating System(OS)などが実際の処理の一部または全部を行い、その処理によって前述した実施例の機能が実現される場合も含まれることは言うまでもない。
【0042】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【図面の簡単な説明】
【0043】
【図1】ネットワーク上でインターフェース定義を要求、取得するためのシステム構成を表すブロック図。
【図2】記憶装置上に保存されたインターフェース定義の抽象定義部分を一覧として保持する抽象定義一覧表の例。
【図3】記憶装置上に保存されたインターフェース定義のバインディング定義部分を一覧として保持するバインディング定義一覧表の例。
【図4】インターフェース定義要求側装置におけるインターフェース定義取得手順を説明するフローチャート。
【図5】インターフェース定義提供側装置におけるインターフェース定義提供手順を説明するフローチャート。
【図6】インターフェース定義の論理定義部分、バインディング定義部分部を参照して1つのインターフェース定義としてまとめるためのメイン部の記述例。
【図7】インターフェース定義の論理定義部分の記述例。
【図8】インターフェース定義のバインディング定義部分の記述例。




 

 


     NEWS
会社検索順位 特許の出願数の順位が発表

URL変更
平成6年
平成7年
平成8年
平成9年
平成10年
平成11年
平成12年
平成13年


 
   お問い合わせ info@patentjp.com patentjp.com   Copyright 2007-2013