(57)【要約】【課題】クライアント１とサーバ２間での送受信メッセージから、インタフェース定義記述を生成する。【解決手段】  生成装置３は、クライアント１およびサーバ２間で送受信されるメッセージ情報３２１と、インタフェース定義記述のテンプレート情報３２３を記憶した定義記述記憶部３２と、インタフェース定義記述を生成する定義記述生成部３４と、定義記述生成部３４にメッセージを入力する入力部３３とを有し、定義記述生成部３４は、入力されたメッセージからテンプレートの設定項目に設定する設定情報を抽出し、抽出した設定情報を前記テンプレートの設定項目にそれぞれ設定し、インタフェース定義記述を生成する。【選択図】図１
2005107884.tif 000002
【特許請求の範囲】
【請求項１】
情報処理装置が、ＷＳＤＬにより記述された、メッセージ送受信のインタフェース定義であるインタフェース定義記述を生成するインタフェース定義記述生成方法であって、
情報処理装置の演算処理部は、
記憶装置に記憶された前記送受信されるメッセージを入力する第１の入力ステップと、
前記第１の入力ステップで入力したメッセージから、あらかじめ記憶装置に記憶されたインタフェース定義記述のテンプレートの設定項目にそれぞれ設定するための設定情報を抽出する抽出ステップと、
前記記憶されたテンプレートを読み出す読み出しステップと、
前記抽出ステップにおいて抽出した設定情報を、前記読み出しステップで読み出したテンプレートの設定項目にそれぞれ設定し、インタフェース定義記述を生成する生成ステップと、を有すること
を特徴とするインタフェース定義記述生成方法。
【請求項２】
請求項１記載のインタフェース定義記述生成方法であって、
前記情報処理装置は、
前記テンプレートの設定項目に設定するための設定情報を、ユーザから受け付ける受付ステップをさらに有し、
前記生成ステップは、前記受付ステップで受け付けた設定情報、および、前記抽出ステップで抽出した設定情報を、前記テンプレートの設定項目にそれぞれ設定し、インタフェース定義記述を生成すること
を特徴とするインタフェース定義記述生成方法。
【請求項３】
請求項１記載のインタフェース定義記述生成方法であって、
前記情報処理装置は、
あらかじめ記憶されたインタフェース定義記述を入力する第２の入力ステップと、
前記生成ステップで生成したインタフェース定義記述と、前記第２の入力ステップで入力したインタフェース定義記述とをマージして１つのインタフェース定義記述を生成するマージステップと、をさらに有すること
を特徴とするインタフェース定義記述生成方法。
【請求項４】
請求項１記載のインタフェース定義記述生成方法であって、
前記生成ステップにおいて、前記第１の入力ステップで入力したメッセージの引数が子要素を有するか否かを判定し、子要素を有する場合、当該子要素各々に対して型定義を生成し、当該生成した子要素各々の型定義を用いてインタフェース定義記述を生成すること
を特徴とするインタフェース定義記述生成方法。
【請求項５】
ＷＳＤＬにより記述された、メッセージ送受信のインタフェース定義であるインタフェース定義記述を生成するインタフェース定義記述生成装置であって、
前記インタフェース定義記述のテンプレートと、前記送受信されるメッセージとを記憶した記憶手段と、
前記インタフェース定義記述を生成する生成手段と、
前記生成手段に、前記記憶されたメッセージを入力する入力手段と、を有し、
前記生成手段は、前記入力手段が入力したメッセージから前記テンプレートの設定項目に設定する設定情報を抽出し、前記記憶手段に記憶されたテンプレートを読み出し、前記抽出した設定情報を前記テンプレートの設定項目にそれぞれ設定し、インタフェース定義記述を生成すること
を特徴とするインタフェース定義記述生成装置。
【請求項６】
ＷＳＤＬにより記述されたメッセージ送受信のインタフェース定義であるインタフェース定義記述を生成するプログラムであって、
前記プログラムは、情報処理装置の演算処理部に、
記憶装置に記憶された前記送受信されるメッセージを入力する入力ステップ、
前記入力ステップで入力したメッセージから、あらかじめ記憶装置に記憶されたインタフェース定義記述のテンプレートの設定項目に設定するための設定情報を抽出する抽出ステップ、
前記記憶されたテンプレートを読み出す読み出しステップ、および、
前記抽出ステップにおいて抽出した設定情報を、前記読み出しステップで読み出したテンプレートの設定項目にそれぞれ設定し、インタフェース定義記述を生成する生成ステップを、実行させること
を特徴とするインタフェース定義記述生成プログラム。
【請求項７】
情報処理装置が、クライアントがサーバと通信するための通信用プログラムであるスタブコードを生成するスタブコード生成方法であって、
情報処理装置の演算処理部は、
記憶装置に記憶された、前記クライアントと前記サーバ間で送受信されるメッセージを入力する入力ステップと、
前記入力ステップで入力したメッセージから、あらかじめ記憶装置に記憶されたスタブコードのテンプレートの設定項目に設定するための設定情報を抽出する抽出ステップと、
前記記憶されたテンプレートを読み出す読み出しステップと、
前記抽出ステップにおいて抽出した設定情報を、前記読み出しステップで読み出したテンプレートの設定項目に設定し、スタブコードを生成する生成ステップと、を有すること
を特徴とするスタブコード生成方法。
【請求項８】
情報処理装置が、サーバがクライアントと通信するための通信用プログラムであるスケルトンコードを生成するスケルトンコード生成方法であって、
情報処理装置の演算処理部は、
記憶装置に記憶された、前記クライアントと前記サーバ間で送受信されるメッセージを入力する入力ステップと、
前記入力ステップで入力したメッセージから、あらかじめ記憶装置に記憶されたスケルトンコードのテンプレートの設定項目に設定するための設定情報を抽出する抽出ステップと、
前記記憶されたテンプレートを読み出す読み出しステップと、
前記抽出ステップにおいて抽出した設定情報を、前記読み出しステップで読み出したテンプレートの設定項目に設定し、スケルトンコードを生成する生成ステップと、を有すること
を特徴とするスケルトンコード生成方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＷＳＤＬにより記述されたインタフェース定義記述を生成する技術に関する。
【背景技術】
【０００２】
ネットワークにより接続された複数の情報処理装置に存在するオブジェクトを利用する技術（分散オブジェクト環境の技術）として、ＯＭＧ（Object Management Group）が策定したＣＯＲＢＡ（The Common Object  Request Broker）、Ｗｅｂサービスなどがある（例えば、非特許文献１）。
【０００３】
Ｗｅｂサービスとは、ＳＯＡＰ（Simple Object Access Protocol）プロトコルを用いてＸＭＬ形式のメッセージ交換により、ネットワーク上に存在するオブジェクトを呼び出す技術である（例えば、非特許文献２）。Ｗｅｂサービスの技術を用いたオブジェクト、または、Ｗｅｂサービスの技術を用いたオブジェクトを複数まとめたアプリケーションも、Ｗｅｂサービスという。そして、Ｗｅｂサービスのインタフェース定義を記述するためのインタフェース定義言語としてＷＳＤＬ（Web Service Description Language）がある（例えば、非特許文献３）。なお、ＷＳＤＬにより記述されたインタフェース定義を、インタフェース定義記述という。
【０００４】
また、Ｗｅｂサービスの実装技術としては、Java（登録商標）言語のライブラリとして動作するApache Axisや、Microsoft社による.NET Frameworkが存在する（例えば、非特許文献４および非特許文献５）。これらの実装技術では、Ｗｅｂサービスを提供するサーバのＷｅｂサービスのアプリケーションプログラムソースから、インタフェース定義記述を自動生成するツールを提供する。また、これらの実装技術では、インタフェース定義記述からスタブコードおよびスケルトンコードを自動生成するツールも提供している。スタブコードとは、クライアント側で使用するＷｅｂサービスを呼び出すための通信用プログラムであり、スケルトンコードとは、サーバ側で使用するＷｅｂサービスをクライアントに提供するための通信用プログラムである。
【０００５】
【非特許文献１】Architecture and Specification Revision 2.0, July 1995,OMG
【非特許文献２】Simple Object Access Protocol (SOAP) 1.1 May 2000, W3C
【非特許文献３】Web Service Description Language 1.1 January 2001, W3C
【非特許文献４】http://xml.apache.org/soap/index.html
【非特許文献５】http://www.microsoft.com/net/default.asp
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ところで、一旦構築したＷｅｂサービスのシステムを、当該システムが稼動した後に、Ｗｅｂサービスを要求するクライアントの台数を増加し、あるいは当該Ｗｅｂサービスを提供するサーバの台数を増加するなどして、拡張する場合がある。この場合、新たに増加するクライアントまたはサーバにおいて、スタブコードまたはスケルトンコードが必要となる。
【０００７】
このようなシステムの拡張の際に、Ｗｅｂサービスを提供するサーバのアプリケーションプログラムソースが失われていた場合、従来はインタフェース定義記述を自動生成することができなかった。また、インタフェース定義記述は複雑な記載となる場合が多い。このため、システム開発者がコーディングしてインタフェース定義記述を作成する場合、その作業負荷は大きいものとなる。
【０００８】
本発明は上記事情を鑑みてなされたものであり、本発明の目的は、プログラムソースが失われた場合であっても、インタフェース定義記述を生成することである。また、インタフェース定義記述を生成する際の作業負荷を軽減することである。
【課題を解決するための手段】
【０００９】
上記課題を解決するために、本発明では、クライアントとサーバ間で送受信されるメッセージと、インタフェース定義記述のテンプレートを用いて、インタフェース定義記述を生成する。
【００１０】
例えば、情報処理装置は、前記送受信されるメッセージを入力する第１の入力ステップと、前記第１の入力ステップで入力したメッセージから、あらかじめ記憶されたインタフェース定義記述のテンプレートの設定項目にそれぞれ設定するための設定情報を抽出する抽出ステップと、前記記憶されたテンプレートを読み出す読み出しステップと、前記抽出ステップにおいて抽出した設定情報を、前記読み出しステップで読み出したテンプレートの設定項目にそれぞれ設定し、インタフェース定義記述を生成する生成ステップと、を有する。
【発明の効果】
【００１１】
本発明では、プログラムソースが失われた場合であっても、クライアントとサーバ間で送受信されるメッセージを用いて、インタフェース定義記述を生成することができる。また、インタフェース定義記述を生成する際の作業負荷を軽減することができる。
【発明を実施するための最良の形態】
【００１２】
以下、本発明の実施の形態を説明する。
【００１３】
図１は、本発明の一実施形態が適用されたインタフェース定義記述生成システムの全体構成図である。図示するように、本実施形態のインタフェース定義記述生成システムは、複数のクライアント１と、Ｗｅｂサービスサーバ２と、インタフェース定義記述を生成する生成装置３とを備える。クライアント１は、インターネットなどのネットワーク８により、Ｗｅｂサービスサーバ２とそれぞれ接続されている。また、Ｗｅｂサービス２と生成装置３は、生成装置３がＷｅｂサービスサーバ２のログ情報を取得するため、イントラネットなどのネットワーク９により接続されている。  
クライアント１は、Ｗｅｂサービス利用者の端末装置である。クライアント１は、ネットワーク８を介してＷｅｂサービスサーバ２に、Ｗｅｂサービスを要求するリクエストメッセージを送信し、また、Ｗｅｂサービスサーバ２から提供されるＷｅｂサービスのレスポンスメッセージを受信する。なお、これらのリクエストメッセージおよびレスポンスメッセージの送受信には、ＳＯＡＰプロトコルが用いられる。ＳＯＡＰプロトコルとは、ＸＭＬ（eXtensible Markup Language）、ＨＴＴＰ（HyperText Transfer Protocol）などの技術をベースとした、Ｗｅｂサービスを呼び出すための通信手順である。
【００１４】
また、クライアント１は、所定の業務処理を行うアプリケーション部１１と、Ｗｅｂサービスサーバ２にＷｅｂサービスの呼び出しを行うため通信用のオブジェクトであるスタブ１２とを有する。スタブ１２は、アプリケーション部１１から独立してＷｅｂサービスのインタフェースを提供するものである。このため、アプリケーション部１１は、Ｗｅｂサービスのインタフェースを意識することなくＷｅｂサービスを利用することができる。なお、スタブ１２は、図示しないスタブコードから、所定のコンパイラにより生成される。
【００１５】
Ｗｅｂサービスサーバ２は、Ｗｅｂサービスの技術を用いたアプリケーションであるＷｅｂサービスを提供する装置である。Ｗｅｂサービスサーバ２は、クライアント１からのリクエストメッセージを受け付け、当該リクエストに応じたレスポンスメッセージをクライアント１に送信することにより、Ｗｅｂサービスを提供する。
【００１６】
また、Ｗｅｂサービスサーバ２は、クライアント１にＷｅｂサービスを提供するＷｅｂサービス提供部２１と、クライアント１との通信を行うための通信用のオブジェクトであるスケルトン２２と、Ｗｅｂサービスサーバ２のメッセージログ情報を記憶するログ情報記憶部２３と、を有する。スケルトン２２は、図示しないスケルトンコードから、所定のコンパイラにより生成される。
【００１７】
ログ情報記憶部２３には、図示しないＯＳ（Operating System）等の機能により、各クライアント１から受け付けたリクエストメッセージ、および各クライアントへ送信するレスポンスメッセージが、ログ情報として記憶されている。リクエストメッセージは、クライアント１がＷｅｂサービスを要求するための入力メッセージである。また、レスポンスメッセージは、Ｗｅｂサービスサーバ２が要求元のクライアント１にＷｅｂサービスを提供するための出力メッセージである。なお、リクエストメッセージについては、図３で後述する。
【００１８】
生成装置３は、Ｗｅｂサービスサーバ２のログ情報記憶部２３からリクエストメッセージおよびレスポンスメッセージを取得し、取得したこれらのメッセージからインタフェース定義記述を生成する装置である。生成装置３は、ログ情報取得部３１と、定義記述記憶部３２と、入力部３３と、定義記述生成部３４と、出力部３５と、を有する。
【００１９】
ログ情報取得部３１は、Ｗｅｂサービスサーバ２のログ情報記憶部２３に記憶されているリクエストメッセージおよびレスポンスメッセージを、ネットワーク９を介して取得し、定義記述記憶部３２に記憶する。なお、ログ情報取得部３１は、ネットワーク９を介してではなく、フレキシブルディスク、ＣＤ、磁気テープなどの記憶媒体から、リクエストメッセージおよびレスポンスメッセージを取得することとしてもよい。  
定義記述記憶部３２には、メッセージ情報３２１と、定義記述情報３２２と、テンプレート情報３２３と、テーブル情報３２４と、が記憶されている。メッセージ情報３２１には、ログ情報取得部３１が取得したリクエストメッセージおよびレスポンスメッセージが記憶されている。また、定義記述情報３２２には、後述する出力部３５が出力した既存のインタフェース定義記述が記憶されている。また、テンプレート情報３２３には、ＷＳＤＬで記述したインタフェース定義記述のテンプレート（雛形）が記憶されている。このテンプレートについては、図４において後述する。また、テーブル情報３２４には、型定義の生成処理で使用する単純型判定テーブル７００と単純型マージテーブル９００とが記憶されている。これらのテーブル７００、９００については、図７および図９で後述する。
【００２０】
入力部３３は、定義記述記憶部３２に記憶されているメッセージ情報３２１および定義記述情報３２２を、定義記述生成部３４に入力する。また、入力部３３は、図示しない入力装置からユーザが入力したインタフェース定義記述の生成に必要な情報を受け付け、定義記述生成部３４に入力する。
【００２１】
定義記述生成部３４は、生成処理部３４１とマージ処理部３４２とを有する。生成処理部３４１は、入力部が入力したメッセージ情報３２１またはユーザが入力した情報と、テンプレート情報３２３に記憶されたテンプレートとを用いて中間インタフェース定義記述を生成する。そして、マージ処理部３４２は、生成処理部３４１が生成した中間インタフェース定義記述と、入力部３３が入力した定義記述情報３２２の既存のインタフェース定義記述とをマージし、新インタフェース定義記述を生成する。なお、定義記述情報３２２に既存のインタフェース定義記述が存在しない場合（例えば、最初にインタフェース定義記述を生成する場合等）、マージ処理部３４２はマージ処理を行わず、生成処理部３４１が生成した中間インタフェース定義記述を新インタフェース定義記述とする。
【００２２】
出力部３５は、定義記述生成部３４が生成した新インタフェース定義記述を、定義記述記憶部３２の定義記述情報３２２に出力（記憶）する。なお、本実施形態においては、出力部３５は、定義記述生成部３４が生成した新インタフェース定義記述を、定義記述情報３２２に記憶されている既存のインタフェース定義記述に上書きして更新するものとする。この場合、定義記述情報３２２には、常に最新のインタフェース定義記述のみが記憶される。しかしながら、出力部３５は、既存のインタフェース定義記述を履歴としてそのまま残し、定義記述生成部３４が生成した新インタフェース定義記述を、逐次、定義記述情報３２２に追加して記憶することとしてもよい。
【００２３】
以上説明した、クライアント１、Ｗｅｂサービスサーバ２および生成装置３には、いずれも、例えば図２に示すようなＣＰＵ９０１と、メモリ９０２と、ＨＤＤ等の外部記憶装置９０３と、キーボードやマウスなどの入力装置９０４と、モニタやプリンタなどの出力装置９０５と、ネットワーク接続するための通信制御装置９０６と、これらの各装置を接続するバス９０７と、を備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵ９０１がメモリ９０２上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。例えば、クライアント１、Ｗｅｂサービスサーバ２および生成装置３の各機能は、クライアント１用のプログラムの場合は、クライアント１のＣＰＵ９０１が、Ｗｅｂサービスサーバ２用のプログラムの場合は、Ｗｅｂサービスサーバ２のＣＰＵ９０１が、そして、生成装置３用のプログラムの場合は、生成装置３のＣＰＵ９０１が、それぞれ実行することにより、実現される。この場合、Ｗｅｂサービスサーバ２のログ情報記憶部２３には、Ｗｅｂサービスサーバ２のメモリ９０２または外部記憶装置９０３が用いられる。また、生成装置３の定義記述記憶部３２には、生成装置３のメモリ９０２または外部記憶装置９０３が用いられる。
【００２４】
次に、クライアント１がＷｅｂサービスの要求を行うためにＷｅｂサービスサーバ２へ送信するリクエストメッセージについて説明する。図３は、リクエストメッセージの一例である。図示するように、リクエストメッセージは、ＨＴＴＰのプロトコルヘッダ部分３１０と、ＳＯＡＰメッセージ部分３２０とを有する。そして、プロトコルヘッダ部分３１０は、通常のＨＴＴＰヘッダに加えて、「SOAPAction」というヘッダ３１１を有し、リクエストメッセージの送信先のＵＲＩ（Uniform Resource Identifier）をＨＴＴＰヘッダに含んでいる。ＵＲＩは、インターネット上に存在する情報資源の場所を指し示すものである。
【００２５】
また、ＳＯＡＰメッセージ部分３２０は、名前空間名３２５と、purchaseOrder要素３２１が含まれているＳＯＡＰボディとを有する。このpurchaseOrder要素３２１は、メッセージの引数について記載したものであり、orderDate属性３２２と、少なくとも１つの子要素であるitem要素とを有する。図３に示す例では、２つのitem要素３２３、３２４を有している。
【００２６】
なお、Ｗｅｂサービスサーバ２がクライアントへ送信するレスポンスメッセージは、図示しないが、リクエストメッセージと同様の構成である。
【００２７】
次に、テンプレート情報３２３に記憶されている、インタフェース定義記述のテンプレート（雛形）について説明する。図４は、テンプレートの一例を示したものである。図示するように、テンプレートは、ＷＳＤＬの記載形式により記載されたインタフェース定義記述であって、図中の四角で囲まれた複数の設定項目４０１〜４０８を有する。そして、これらの設定項目４０１〜４０８に、図５で後述するインタフェース定義記述の生成処理で特定した情報を、それぞれ設定（埋め込む）ことで、インタフェース定義記述が生成される。
【００２８】
なお、インタフェース定義記述には、一般的に、インタフェース定義記述全体で使用する名前空間名４０１を定義するdefinitions要素４１０と、後述するメッセージ要素を定義する際に使用する型を定義するtypes要素４２０と、リクエストメッセージまたはレスポンスメッセージのフォーマットを定義するmessage要素４３０と、関連した操作をまとめたポートを定義するportType要素４４０と、portType要素で定義したポートに通信プロトコルをバインドしたbinding要素４５０と、binding要素で通信プロトコルをバインドしたポートのＵＲＩを定義するservice要素４６０と、が記述される。
【００２９】
次に、インタフェース定義記述の生成処理手順を、図５に示すフローチャートを用いて説明する。
【００３０】
はじめに、入力部３３が、定義記述記憶部３２のメッセージ情報３２１に記憶されているリクエストメッセージまたはレスポンスメッセージを生成処理部３４１に入力する（Ｓ５０１）。そして生成処理部３４１は、入力部３３が入力したメッセージから、名前空間名およびSOAPActionを特定する（Ｓ５０２）。例えば、図３に示すリクエストメッセージが入力された場合、名前空間名としてＳＯＡＰメッセージ部分３２０の「soap:Envelope」の後に記載されている部分３２５を特定する。また、「SOAPAction」として、プロトコルヘッダ部分３１０の「http://tempuri.org/Order」３１１を特定する。
【００３１】
次に、生成処理部３４１は、入力部３３が入力したメッセージから、オペレーション名および引数を特定する（Ｓ５０３）。生成処理部３４１は、メッセージにSOAPActionが指定されている場合、そのSOAPActionで指定されたＵＲＩをオペレーション名として特定する。そして、生成処理部３４１は、SOAPActionが指定されていない場合であって、かつ、入力したメッセージが１つの要素で構成されている場合は、その要素の名前をオペレーション名として特定する。そして、SOAPActionが指定されていない場合であって、かつ、入力メッセージが複数の要素で構成されている場合は、ユーザが入力装置から入力したオペレーション名を、入力部３３が受け付ける。そして、入力部３３は、入力されたオペレーション名を生成処理部３４１に入力し、生成処理部３４１は当該入力されたオペレーション名を特定する。あるいは、あらかじめ定められたデフォルトのオペレーション名を用いることとしてもよい。図３に示すリクエストメッセージが入力された場合、SOAPActionが指定されているので、「http://tempuri.org/Order」３１１をオペレーション名として特定する。
【００３２】
また、生成処理部３４１は、リクエストメッセージまたはレスポンスメッセージのpurchaseOrder要素を、入力引数または出力引数として特定する。図３に示すリクエストメッセージが入力された場合、生成処理部３４１は、purchaseOrder要素３２１を入力引数として特定する。
【００３３】
次に、生成処理部３４１は、Ｓ５０３で特定した引数を構成する各要素に対して型定義を生成する（Ｓ５０４）。この引数の型定義の生成については、図６から図１０で後述する。
【００３４】
次に、生成処理部３４１は、サービス名とＷｅｂサービスのアドレス（例えば、ＵＲＩまたはＵＲＬ）など、その他のインタフェース定義記述を生成する際に必要となる情報を特定する（Ｓ５０５）。サービス名およびＷｅｂサービスのアドレスは、リクエストメッセージおよびレスポンスメッセージの中に含まれていない。そのため、生成処理部３４１は、入力装置から入力部３３が受け付けたユーザ指定の情報を、Ｗｅｂサービス名およびＷｅｂサービスアドレスとして特定する。あるいは、生成処理部３４１は、あらかじめ定められたデフォルトの情報を、Ｗｅｂサービス名およびＷｅｂサービスアドレスとして特定してもよい。
【００３５】
次に、生成処理部３４１は、定義記述記憶部３２のテンプレート情報３２３に記憶されているインタフェース定義記述のテンプレートを読み出す（Ｓ５０６）。そして、生成処理部３４１は、このテンプレートの空欄になっている設定項目部分に、Ｓ５０２からＳ５０５で特定した情報をそれぞれ設定して、中間インタフェース定義記述を生成する（Ｓ５０７）。
【００３６】
具体的には、Ｓ５０２で特定した名前空間名はdefinitions要素４１０の空欄４０１に設定され、Ｓ５０２で特定した「SOAPAction」はbinding要素４５０のsoap：operationの空欄４０７に設定される。また、Ｓ５０３で生成した型定義は、types要素４２０の空欄４０２に設定される。また、Ｓ５０４で特定したオペレーション名は、message要素４３０、portType要素４４０およびbinding要素４５０の各空欄４０３に設定され、Ｓ５０３で特定した入力引数または出力引数は、message要素４３０の空欄４０４、４０５に設定される。また、Ｓ５０５で特定したサービス名は、portType要素４４０、binding要素４５０およびservice要素４６０の各空欄４０６に設定され、Ｓ５０５で特定したＷｅｂサービスのアドレスは、service要素４６０のsoap address locationの空欄４０８に設定される。なお、テンプレートの空欄の設定項目部分に設定すべき部分が、入力されたメッセージに存在しない部分、生成処理部３４１は当該設定項目部分を出力しない。例えば、入力されたメッセージがリクエストメッセージの場合、出力引数に対する定義４０５のmessage要素４３０は出力しない。
【００３７】
次に、マージ処理部３４２は、定義記述記憶部３２の定義記述情報３２２に、インタフェース定義記述が記憶されているか否かを判定する（Ｓ５０８）。そして、マージ処理部３４２は、インタフェース定義記述が記憶されている場合（Ｓ５０８：ＹＥＳ）、後述するマージ処理を行い（Ｓ５０９）、新インタフェース定義記述を生成する（Ｓ５１０）。また、インタフェース定義記述が記憶されていない場合（Ｓ５０８：ＮＯ）、マージ処理部３４２は、生成処理部３４１が作成した中間インタフェース定義記述を、そのまま新インタフェース定義記述とする（Ｓ５１０）。
【００３８】
そして、出力部３５は、生成処理部３４１およびマージ処理部３４２が生成した新インタフェース定義記述を、定義記述記憶部３２の定義記述情報３２２に出力（記憶）する（Ｓ５１１）。なお、既存のインタフェース定義記述が定義記述情報３２２に記憶されている場合、出力部３５は、新インタフェース定義記述を既存のインタフェース定義記述に上書きする。
【００３９】
以上により、一件のメッセージのインタフェース定義記述の生成処理を終了する。そして、定義記述記憶部３２の定義記述情報３２２に未処理のメッセージがなくなるまで、入力部３３は順次メッセージを生成処理部３４１に入力し、生成処理部３４１およびマージ処理部３４２は、図５に示す生成処理を行う。
【００４０】
次に、引数の型定義の生成（Ｓ５０４）について、図６に示すフローチャートを用いて説明する。
【００４１】
まず、生成処理部３４１は、対象となるメッセージの要素が属性を有するか否かを判定する（Ｓ６０１）。要素が属性を有しない場合（Ｓ６０１：ＮＯ）、生成処理部３４１は要素が子要素を有するか否かを判定する（Ｓ６０２）。そして、子要素を有しない場合（Ｓ６０２：ＮＯ）、生成処理部３４１は、対象となる要素のタグで指定されている値について、後述する単純型判定により型を決定する（Ｓ６０４）。一方、子要素を有する場合（Ｓ６０２：ＹＥＳ）、生成処理部３４１は当該子要素に対して再帰処理を行う（Ｓ６０５）。すなわち、生成処理部３４１は、当該子要素の各々に対して再びＳ６０１に戻り、属性を有するか否かを判定し、以降の処理を行う。そして、全ての子要素に対して再帰処理（Ｓ６０５）を行った後、生成処理部３４１は後述する複合型生成を行う（Ｓ６０６）。
【００４２】
また、要素が属性を有する場合（Ｓ６０１：ＹＥＳ）、生成処理部３４１は要素が子要素を有するか否かを判定する（Ｓ６０３）。そして、子要素を有する場合（Ｓ６０３：ＹＥＳ）、生成処理部３４１は当該子要素に対して前述の再帰処理を行う（Ｓ６０７）。そして、生成処理部３４１は、Ｓ６０６と同様に後述する複合型生成を行う（Ｓ６０８）。そして、生成処理部３４１は、要素の属性に対して、単純型判定を行う（Ｓ６０９）。一方、子要素を有しない場合（Ｓ６０３：ＮＯ）、生成処理部３４１は単純型判定を行い（Ｓ６１０）、要素の属性に対して、単純型判定を行う（Ｓ６１１）。そして、生成処理部３４１は、以上述べたように、属性の有無（Ｓ６０１）および子要素の有無（Ｓ６０２、Ｓ６０３）により、４つのタイプに分類して、それぞれの子要素の型定義を生成し、さらに要素の型定義を生成する（Ｓ６１２）。
【００４３】
次に、単純型判定（Ｓ６０４、Ｓ６０９、Ｓ６１０、Ｓ６１１）について説明する。
【００４４】
図７は、単純型判定テーブル７００を例示したものである。この単純型判定テーブル７００は、定義記述記憶部３２のテーブル情報３２４に記憶されている。図示するように、単純型判定テーブル７００には、判定対象となる要素の値の形式７０１（例えば、YYYY-MM-DD、整数、小数等）と、これに対応する型名７０２（例えば、date、integer、decimal等）とが組になったデータが、優先順位の高い順に上から登録されている。図７に示す例では、最も優先順位の高いデータは、形式７０１がYYYY-MM-DD形式（日付の形式）で、型名７０２がdateのデータ７０３である。また、最も優先順位の低いデータは、形式７０１がその他で、型名７０２がstringのデータ７０４である。このテーブル７００では、自由度の小さい形式・型名のデータは優先順位が高く、自由度が大きい形式・型名のデータは優先順位が低い。例えば、stringは他の全ての型を包含可能な型であるため、優先順位が最も低い。
【００４５】
単純型判定（Ｓ６０４、Ｓ６１０等）において、生成処理部３４１は、単純型判定テーブル７００を読み出す。そして、生成処理部３４１は、判定対象の要素または子要素の値がこのテーブルに登録された形式７０１に適合するか否かを上から順に判定していく。そして生成処理部３４１は、適合すると判定した最初の形式の型名を、要素または子要素の型と判定する。
【００４６】
次に、複合型生成（Ｓ６０６、Ｓ６０８）について説明する。
【００４７】
生成処理部３４１は、単純型判定で判定した各子要素（子要素の子要素（孫要素）を含む）の型を、入力されたメッセージに出現した子要素の順番で出力し、ＷＳＤＬの記載形式に従って型定義を生成する。この場合、生成処理部３４１は、同じ名前の子要素が連続している場合は、同じ名前の子要素をマージ処理して、同じ名前の子要素の型定義を１つだけ生成する。
【００４８】
図８は、複合型生成におけるマージ処理のフローチャートである。まず、生成処理部３４１は、同じ名前の子要素が連続して出現した場合、これらの子要素の中に複合型子要素を含むか否かを判別する（Ｓ８０１）。複合型子要素とは、子要素がさらに子要素（孫要素）を有する子要素のことをいう。複合型子要素か否かを判別する方法としては、例えば、タグで指定された子要素の中に別のタグで指定された子要素が出現するか否かによって判別することが考えられる。そして、生成処理部３４１は、これらの子要素の中に複合型子要素を含まない場合、すなわち全てが複合型子要素でない場合（Ｓ８０１；ＮＯ）、単純型マージ処理を行う（Ｓ８０５）。単純型マージ処理（Ｓ８０５）では、生成処理部３４１は、同じ名前の子要素の最大出現回数（maxOccurs：最大繰り返し回数）を、連続して出現した回数に設定する。なお、最大出現回数（maxOccurs）のデフォルト値および最小出現回数（minOccurs）のデフォルト値は、ともに１回である。そして、生成処理部３４１は、単純型マージテーブル９００を用いて、単純型マージ処理後の型を決定する。
【００４９】
図９は、単純型マージテーブル９００を例示したものである。単純型マージテーブル９００は、定義記述記憶部３２のテーブル情報３２４にあらかじめ登録されている。この単純型マージテーブル９００は、型名が登録された列９０１と、型名が登録された行９０２とを有する。そして、列９０１および行９０２以外の各セルには、単純型マージ処理後の型名が登録されている。生成処理部３４１は、単純型マージテーブル９００を参照し、マージ処理の対象となる子要素（孫要素も含む）の型名を列９０１と行９０２に登録された型名の中からそれぞれ特定し、これらの特定した列９０１の型名と行９０２の型名とが交差するセルの型名をマージ後の型として決定する。
【００５０】
例えば、マージ処理の対象となる子要素が、「string」９０３と「date」９０４の場合、生成処理部３４１は、列９０１の「string」９０３と行９０２の「date」９０４が交差するセルの「string」９０５を、単純型マージ処理後の型名と決定する。なお、連続して出現した同じ名前の子要素が３つ以上ある場合、１番目の子要素と２番目の子要素のマージ処理後の型と、３番目の子要素の型でマージ処理を行い、その後順次マージ処理後の型と次の子要素でマージ処理を行うものとする。
【００５１】
一方、生成処理部３４１は、連続する同じ名前の子要素の中に複合型子要素を含む場合（Ｓ８０１；ＹＥＳ）、連続する同じ名前の子要素の全てが複合型子要素か否かを判別する（Ｓ８０２）。そして、全ての子要素が複合型子要素の場合、これらの複合型子要素が包含関係にあるか否かを判定する（Ｓ８０３）。ここで、包含関係にあるとは、１つの複合型子要素に含まれる子要素（孫要素）が、他の複合型子要素に含まれる子要素（孫要素）を全て含んでおり、かつ子要素（孫要素）各々の出現順番（並び順）も同じ場合をいう。包含関係にあるか否かを判別する方法としては、例えば、タグで指定された子要素が、同じ並び順で出現しているか否かによって判別することが考えられる。包含関係が成立する場合（Ｓ８０３；ＹＥＳ）、生成処理３４１は複合型マージ処理を行う（Ｓ８０４）。
【００５２】
複合型マージ処理（Ｓ８０４）では、生成処理部３４１は、同じ名前の複合型子要素の最大出現回数を、連続して出現した回数に設定する。なお、最大出現回数および最小出現回数のデフォルト値は１回である。そして、生成処理部３４１は、複合型マージ処理後の型定義として包含する側の複合型子要素の型定義を採用する。そして、生成処理３４１は、採用した包含する側の複合型子要素の子要素（孫要素）の最小出現回数を必要に応じて変更する。すなわち、生成処理３４１は、包含される側の複合型子要素には現れない子要素（孫要素）の最小出現回数を０に変更する。
【００５３】
また、連続する同じ名前の子要素の全てが複合型子要素でない場合（Ｓ８０２；ＮＯ）、あるいは、複合型子要素が包含関係にない場合（Ｓ８０３；ＮＯ）は、生成処理３４１は複合型マージ処理を行わず、連続する同じ名前の子要素のいずれかを選択可能な型定義を生成する（Ｓ８０６）。
【００５４】
次に、これまで説明した型定義の生成処理（図６から図９参照）に従って、図３に示すリクエストメッセージのpurchaseOrder要素３２１を例として、型定義の生成処理を具体例に説明する。図１０は、図３のpurchaseOrder要素３２１の型定義を、例示したものである。図１０（ａ）はitem要素３２３の型定義で、図１０（ｂ）はitem要素３２４の型定義で、図１０（ｃ）はitem要素３２３の型定義とitem要素３２４の型定義を複合型生成によりマージ処理した型定義である。
【００５５】
まず、生成処理部３４１は、入力されたリクエストメッセージのpurchaseOrder要素３２１を参照し、属性の有無を判断し、orderDate属性３２２を有するため（Ｓ６０１；ＹＥＳ）、Ｓ６０３に進む。次に、生成処理部３４１は、子要素の有無を判断し、子要素であるitem要素３２３、３２４を２つ有するため（Ｓ６０３；ＹＥＳ）、Ｓ６０７に進む。次に、生成処理部３４１は、子要素である各item要素３２３、３２４のそれぞれに対して、再帰的に処理を行う（Ｓ６０７）。すなわち、生成処理部３４１は、Ｓ６０１に戻ってitem要素３２３が属性を有するか否かを判定する（Ｓ６０１）。そして、属性を有しないため（Ｓ６０１；ＮＯ）、生成処理部３４１はitem要素３２３がさらに子要素（孫要素）を有するか否かを判定する（Ｓ６０２）。
【００５６】
そして、item要素３２３が子要素（孫要素）を有するため、当該子要素（孫要素）に対して、再帰的に処理を行う（Ｓ６０５）。すなわち、生成処理部３４１は、再びＳ６０１に戻って、item要素３２３の最初の子要素（孫要素）のproductNo要素について、属性の有無（Ｓ６０１）、および子要素の有無（Ｓ６０２）を判定する。そして、productNo要素は、orderDate属性３２２および子要素を有しないため（Ｓ６０１；ＮＯ、Ｓ６０２；ＮＯ）、生成処理部３４１は、Ｓ６０４の単純型判定を行う。この単純型判定において、生成処理部３４１は、単純型判定テーブル７００（図７参照）を読み出し、productNo要素の値（「８７２-ＡＡ」）を「その他」の「string型」と判定する（Ｓ６０４）。そして、生成処理部３４１は、ＷＳＤＬの記載形式に従ってproductNo要素の型定義（図１０（ａ）；１００１）を生成する（Ｓ６１２）。
【００５７】
次に生成処理部３４１は、他のitem要素３２３の子要素（孫要素）についても、それぞれproductNo要素と同様の処理を行う（Ｓ６０１、Ｓ６０２、Ｓ６０４、Ｓ６１２）。そして、生成処理部３４１は、quality要素（値が「１」）を「integer型」と判定し、quality要素の型定義（図１０（ａ）；１００２）を生成する（Ｓ６１２）。また、生成処理部３４１は、size要素（値が「２５．０」）を「decimal型」と判定し、size要素の型定義（図１０（ａ）；１００３）を生成する（Ｓ６１２）。
【００５８】
このようにitem要素３２３の子要素（孫要素）各々の再帰処理が終わると（Ｓ６０５）、生成処理は、item要素３２３全体の複合型生成を行う（Ｓ６０６）。すなわち、生成処理部３４１は、Ｓ６１２で生成した各子要素（孫要素）の型定義を、item要素３２３に出現した順番でＷＳＤＬの記載形式に従って、item要素３２３全体の型定義（図１０（ａ）：１００４）を生成する。
【００５９】
次に、生成処理部３４１は、２つ目のitem要素３２４に対しても、１つ目のitem要素３２４と同様の処理を行い、item要素３２４全体の型定義（図１０（ｂ）；１００５）を生成する。なお、item要素３２４は、子要素（孫要素）としてproductNo要素、quality要素およびsize要素と、さらにcolor要素を有する。このcolor要素は、値が「ｂｌａｃｋ」のため「string型」である（図１０（ｂ）；１００６）。
【００６０】
これら２つのitem要素３２３、３２４の型定義の複合型生成（Ｓ６０６）が終了することにより、生成処理部３４１は、item要素３２３、３２４の再帰処理（Ｓ６０７）を終了し、次にpurchaseOrder要素３２１の型定義の複合型生成を行う（Ｓ６０８）。ここで、itemという同じ名前の要素が連続して出現するため、生成処理部３４１は、マージ処理を行う（図８参照）。
【００６１】
生成処理部３４１は、これら２つのitem要素３２３、３２４が全て子要素（孫要素）を有する複合型子要素であるため（Ｓ８０１；ＹＥＳ、かつ、Ｓ８０２；ＹＥＳ）、これらのitem要素３２３、３２４が包含関係にあるか否かを判定する（Ｓ８０３）。ここで、item要素３２３およびitem要素３２４は共にproductNo要素、quality要素およびsize要素を有する。そして、item要素３２４は、さらにcolor要素を有する。したがって、生成処理部３４１は、包含関係にあると判断し（Ｓ８０３；ＹＥＳ）、そして、生成処理部３４１は、複合型マージ処理を行う（Ｓ８０４）。すなわち、生成処理部３４１は、item要素３２４全体の型定義（図１０（ｂ）；１００５）を採用し、item要素の最大出現回数を２回に設定する（図１０（ｃ）；１００７）。そして、item要素の子要素（孫要素）であるcolor要素は、item要素３２４にしか存在しないため、最小出現回数を０回に設定する（図１０（ｃ）；１００８）。
【００６２】
そして、生成処理部３４１は、orderDate属性３２２の単純型判定を行う（Ｓ６０９）。orderDate属性３２２の値は「2003-1-1」であるため、生成処理部３４１は、「date型」と判定する（図１０（ｃ）；１００９）。以上により、生成処理部３４１は、ＷＳＤＬの記載形式に従って、purchaseOrder要素３２１の型定義を生成する（図１０（ｃ）；１０１０）。
【００６３】
次に、生成処理部３４１が生成した中間インタフェース定義記述と、定義記述記憶部３２の定義記述情報３２２に記憶された既存のインタフェース定義記述とのマージ処理（図５；Ｓ５０９）について説明する。
【００６４】
型定義を記載するtypes要素４２０については、マージ処理部３４２は図６に示す型定義生成を行う。また、message要素４３０については、マージ処理部３４２は、中間インタフェース定義記述のmessage要素４３０の名前と、既存のインタフェース定義記述のmessage要素４３０の名前が、同じか否かを判定する。message要素４３０の名前が同じ場合、マージ処理部３４２は、これらのmessage要素４３０をマージして１つにまとめる。また、message要素４３０の名前が異なる場合、マージ処理部３４２は、既存のインタフェース定義記述と中間インタフェース定義記述の両方のmessage要素４３０を併記して、両方のmessage要素４３０が選択可能なインタフェース定義記述を生成する。service要素４６０についても、message要素４３０と同様である。
【００６５】
portType要素４４０については、マージ処理部３４２は、portType要素４４０の名前および引数の形式（例えばoperation  name等）が、中間インタフェース定義記述と既存のインタフェース定義記述とで同じか否かを判定する。これらが同じ場合、マージ処理部３４２は、これらのportType要素４４０をマージして１つにまとめる。また、これらが異なる場合、マージ処理部３４２は、既存のインタフェース定義記述と中間インタフェース定義記述の両方のportType要素４４０を併記して、両方のportType要素４４０が選択可能なインタフェース定義記述を生成する。binding要素４５０についても、portType要素４４０と同様である。
【００６６】
具体的な例として、既存のインタフェース定義記述がリクエストメッセージのみを入力して生成されたインタフェース定義記述であって、出力引数に対する定義のmessage要素４３０がないものとする。そして、中間インタフェース定義記述がレスポンスメッセージから生成されているものとする。この場合、マージ処理部３４２は、既存インタフェース定義記述に、中間インタフェース定義記述の出力引数に対する定義のmessage要素４３０を追加して、新インタフェース定義記述を生成する。
【００６７】
以上、本発明の一実施形態について説明した。
【００６８】
本実施形態において、プログラムソースが失われた場合であっても、クライアント１とＷｅｂサービスサーバ２間で送受信されるリクエストメッセージまたはレスポンスメッセージから、インタフェース定義記述を生成することができる。また、インタフェース定義記述を生成する際の作業負荷を軽減することができる。
【００６９】
なお、本発明は上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。
【００７０】
例えば、上記実施形態では、リクエストメッセージまたはレスポンスメッセージから、インタフェース定義記述を生成する方法について記述した。しかしながら、リクエストメッセージまたはレスポンスメッセージから、直接スタブコードまたはスケルトンコードを作成することとしてもよい。すなわち、インタフェース定義記述の生成処理においてスタブコード用のテンプレートを使用した場合（図５；Ｓ５０６）、スタブコードを生成することができる。同様に、スケルトンコード用のテンプレートを使用した場合、スケルトンコードを生成することができる。
【００７１】
図１１は、Apache Axisを用いたJava（登録商標）言語で記述されたスタブコードのテンプレートを例示したものである。スタブコードは、図５に示す生成処理において、図１１に示すJava言語で記載されたスタブコード用テンプレートを使用して生成する。この場合、スタブコード用テンプレートはあらかじめ定義記述記憶部３２のテンプレート情報３２３に記憶されているものとする。なお、引数の型定義の生成（図５：Ｓ５０４）で生成される型定義の記述言語は、ＷＳＤＬがベースとしているXML  schemaからJava言語に変更され、データを定義するJavaクラスを記述したファイルが作成される。また、テンプレートの引数を記載した部分（図１１；１１０１）は、Ｓ５０３において特定した引数の数だけ、それぞれの引数に対応した形式で生成される。例えば、リクエストメッセージの場合、「javax.xml.rpc.ParameterMode.IN」（図１１；１１０３）と生成され、レスポンスメッセージの場合、「javax.xml.rpc.ParameterMode.OUT」と生成される。また、テンプレートの１２０２部分は、型定義の生成処理（図６）において、複合型子要素（例えば、item要素）の型定義の個数分だけ、それぞれの複合型に応じた形式で生成される。
【００７２】
なお、スケルトンコードについても、図示しないスケルトンコード用テンプレートを使用することにより、スタブコードと同様の処理によりスケルトンコードを生成することができる。
【００７３】
これにより、従来のインタフェース定義記述をコンパイルしてスタブコードまたはスケルトンコードを生成する方法とは異なり、インタフェース定義記述定義が存在しない場合であっても、リクエストメッセージまたはレスポンスメッセージから直接スタブコードまたはスケルトンコードを生成することができる。
【図面の簡単な説明】
【００７４】
【図１】図１は、本発明の一実施形態が適用されたインタフェース定義記述生成システムの全体構成図である。
【図２】図２は、各装置のハードウエア構成例を示す図である。
【図３】図３は、リクエストメッセージの一例を示す図である。
【図４】図４は、インタフェース定義記述のテンプレートの一例を示す図である。
【図５】図５は、インタフェース定義の生成処理フローを示す図である。
【図６】図６は、型定義の生成処理フローを示す図である。
【図７】図７は、単純型判定テーブルの一例を示す図である。
【図８】図８は、複合型生成のマージ処理フローを示す図である。
【図９】図９は、単純型マージテーブルの一例を示す図である。
【図１０】図１０は、生成された型定義の一例を示す図である。
【図１１】図１１は、スタブコードのテンプレートの一例を示す図である。
【符号の説明】
【００７５】
１：クライアント、１１：ＡＰ部、１２：スタブ、２：Ｗｅｂサービスサーバ、２１：Ｗｅｂサービス提供部、２２：スケルトン、２３：ログ情報記憶部、３：生成装置、３１：ログ情報取得部、３２：定義記述記憶部、３２１：メッセージ情報、３２２：定義記述情報、３２３：テンプレート情報、３２４：テーブル情報、３３：入力部、３４：定義記述生成部、３４１：生成処理部、３４２：マージ処理部、３５：出力部、８：ネットワーク、９：ネットワーク
【図１】
2005107884.tif 000003
【図２】
2005107884.tif 000004
【図３】
2005107884.tif 000005
【図４】
2005107884.tif 000006
【図５】
2005107884.tif 000007
【図６】
2005107884.tif 000008
【図７】
2005107884.tif 000009
【図８】
2005107884.tif 000010
【図９】
2005107884.tif 000011
【図１０】
2005107884.tif 000012
【図１１】
2005107884.tif 000013