JP5548433B2

JP5548433B2 - Ｗｅｂサービス基盤システム

Info

Publication number: JP5548433B2
Application number: JP2009271598A
Authority: JP
Inventors: 淳一瀧澤; 崇高山; 修宍戸; 恒三朗新田
Original assignee: Nomura Research Institute Ltd
Current assignee: Nomura Research Institute Ltd
Priority date: 2009-11-30
Filing date: 2009-11-30
Publication date: 2014-07-16
Anticipated expiration: 2029-11-30
Also published as: JP2011113463A

Description

本発明は、クライアントにＷｅｂサービスを提供するためのＷｅｂサービス基盤技術に関する。

近年、様々な種類のＷｅｂサービスが開発され、クライアントに提供されている。また、Ｗｅｂサービスを実現するにあたりＷＳＤＬを使用する場合がある。ＷＳＤＬは、Ｗ３Ｃ（World Wide Web Consortium）によって指定された標準のＸＭＬドキュメントである。ＷＳＤＬは、Ｗｅｂサービスを提供するサービス・プロバイダとＷｅｂサービスを利用するサービス・リクエスタ（クライアント）の間でインターフェイス情報をやり取りするために使用される。特許文献１には、コントローラ装置のプログラムと対話することができるＷｅｂサービスによりＷＳＤＬを使用する通信システムが記載されている。

特開２００２−２１５４８６号公報

ところで、既存の業務システムをＷｅｂサービスとしてクライアントに提供する場合、例えばＳＯＡＰ（Simple Object Access Protocol）などの通信プロトコルに従って交換されるメッセージの記述形式に従ったプログラムの開発が必要となる。メッセージがＸＭＬ（eXtensible Markup language）で記述されている場合、ＸＭＬによるメッセージのデータ形式とＷｅｂサービス・プロバイダ側におけるプログラム言語にて処理可能なデータ形式とは異なるため、各Ｗｅｂサービス・プロバイダ側においてデータ形式の相違を吸収する仕組みが必要となる。

そのため、既存の業務システムをＷｅｂサービスとしてクライアントに提供する場合、システムの開発規模、開発コスト、作業負荷が大きく、既存の業務システムを容易にＷｅｂサービス化できないという問題がある。

本発明は上記事情に鑑みてなされたものであり、本発明の目的は、既存の業務システムを変更することなく、より容易に既存の業務システムをＷｅｂサービスとしてクライアントに提供することにある。

上記課題を解決するために、本発明は、業務システムが行う処理をＷｅｂサービスとしてクライアントに提供するＷｅｂサービス基盤システムであって、所定の通信プロトコルに従って、クライアントとの間でメッセージの送受信を行う通信処理手段と、Ｗｅｂサービス毎に設けられた、複数のサービスエンドポイントと、全てのＷｅｂサービスに共通のＷｅｂサービス提供手段と、を有し、前記通信処理手段は、前記クライアントからのサービス要求を、当該サービス要求で指定されたＷｅｂサービス用のサービスエンドポイントを介して、前記Ｗｅｂサービス提供手段に送出し、前記Ｗｅｂサービス提供手段は、前記サービス要求を前記業務システムが処理可能なデータ形式に変換して、当該サービス要求で指定されたＷｅｂサービスに対応する業務システムに送信するとともに、前記業務システムの処理結果を前記通信処理手段が処理可能なデータ形式に変換して、前記Ｗｅｂサービス用のサービスエンドポイントを介して前記通信処理手段に送出する。

本発明では、既存の業務システムを変更することなく、より容易に既存の業務システムをＷｅｂサービスとしてクライアントに提供することができる。

本発明の実施形態が適用されたＷｅｂサービス基盤システムの構成図である。各装置のハードウェア構成例を示す図である。リクエスト電文の一例を示す図である。サービス呼出定義ファイルの一例を示す図である。トランザクション呼出定義ファイル、データ変換定義ファイル、電文定義ファイルの一例を示す図である。レスポンス電文の一例を示したものである。ＷＳＤＬの生成処理における入出力ファイルを示す図である。ＷＳＤＬの構造を模式的に示す図である。ＷＳＤＬの生成処理を示すフローチャートである。ＷＳＤＬと、トランザクション呼出定義ファイル、データ変換定義ファイルおよび電文定義ファイルとの関係を模式的に示す図である。ＷＳＤＬネーミングルールの一例を示す図である。ＷＳＤＬネーミングルールの一例を示す図である。ＷＳＤＬネーミングルールの一例を示す図である。ＷＳＤＬネーミングルールの一例を示す図である。ＷＳＤＬネーミングルールの一例を示す図である。ＪａｖａＢｅａｎｓの一例を示す図である。サービスエンドポイントの一例を示す図である。

以下、本発明の実施の形態について説明する。

図１は、本発明の実施形態が適用されたＷｅｂシステムの全体構成図である。本実施形態では、既存の業務システムを、スピーディに、かつ容易にＷｅｂサービス化するものである。

図示するＷｅｂシステムは、ユーザが使用するクライアント１と、Ｗｅｂサービス基盤システム２と、既存の複数の業務システム７、８とを有する。第１の業務システム７は、Ｊａｖａ（登録商標）で記述されたアプリケーションプログラム（トランザクション）を実行することにより各種のサービス（業務処理）を実行する。第２の業務システム８は、Ｊａｖａ（登録商標）以外のＣＯＢＯＬ、Ｃ言語などで記述されたアプリケーションプログラム（トランザクション）を実行することにより各種のサービス（業務処理）を実行する。

クライアント１とＷｅｂサービス基盤システム２とはインターネットなどのネットワークにより接続され、Ｗｅｂサービス基盤システム２と業務システム７、８とはＬＡＮなどのネットワークにより接続される。

本実施形態のＷｅｂサービス基盤システム２は、クライアント１から送信される要求を対応する業務システム７、８のトランザクションに接続し、当該トランザクションによる処理結果を要求元のクライアント１に送信する。

図示するＷｅｂサービス基盤システム２は、実行環境として、Ｗｅｂアプリケーション部２１と、ＳＯＡＰエンジン２２（通信処理手段）と、複数のサービスエンドポイント２３と、汎用のサービスクラス２４および接続部２８（Ｗｅｂサービス提供手段）と、サービス呼出定義ファイル３１と、データ変換定義ファイル３４と、電文定義ファイル３５とを有する。

また、Ｗｅｂサービス基盤システム２は、開発環境として、クライアント１にインストールされるＷＳＤＬ１１と、Ｗｅｂサービス基盤システム２の実行環境で使用するサービスエンドポイント２３、サービス呼出定義ファイル３１、ＪａｖａＢｅａｎｓ３２を生成する生成部２９を有する。

上記説明した、クライアント１、Ｗｅｂサービス基盤システム２、および業務システム７、８は、いずれも、例えば図２に示すようなＣＰＵ９０１と、メモリ９０２と、ＨＤＤ等の外部記憶装置９０３と、キーボードやマウスなどの入力装置９０４と、ディスプレイやプリンタなどの出力装置９０５と、ネットワークと接続するための通信制御装置９０６と、を備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵ９０１がメモリ９０２上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。

例えば、Ｗｅｂサービス基盤システム２および業務システム７、８の各機能は、Ｗｅｂサービス基盤システム２用のプログラムの場合はＷｅｂサービス基盤システム２のＣＰＵ９０１が、そして、業務システム７、８用のプログラムの場合は業務システム７、８のＣＰＵ９０１が、それぞれ実行することにより実現される。

なお、入力装置９０４および出力装置９０５については、各装置が必要に応じて備えるものとする。また、Ｗｅｂサービス基盤システム２は、複数のサーバで構成されるものであってもよい。例えば、実行環境用のサーバと、開発環境用のサーバとで構成することとしてもよい。

［実行環境］
以下にＷｅｂサービス基盤システム２の実行環境について説明する。

Ｗｅｂアプリケーション部２１は、クライアント１から送信されたリクエスト電文（サービス要求）を受け付け、ＳＯＡＰエンジン２２に送出する。

ＳＯＡＰエンジン２２は、クライアント１との間でリクエスト電文およびレスポンス電文などのメッセージ交換を行う。ＳＯＡＰ（Simple Object Access Protocol）は、ＸＭＬ、ＨＴＴＰなどをベースとした、他のコンピュータにあるデータやサービスを呼び出すためのプロトコルである。ＳＯＡＰによる通信では、ＸＭＬ文書にエンベロープと呼ばれる付帯情報が付いた電文・メッセージを、ＨＴＴＰなどのプロトコルで交換する。Ｗｅｂサービス（以下、「サービス」という）を利用するクライアントと、サービスを提供する側のシステムの双方がＳＯＡＰの生成・解釈エンジンを持つことで、異なる環境間でのオブジェクト呼び出しを可能にしている。

サービスエンドポイント２３は、サービスを利用するクライアント１に公開するサービスの受け口（インターフェース、ポート）である。本実施形態では、サービス毎にサービスエンドポイント２３を備える。

サービスクラス２４は、サービスエンドポイント２３から呼び出されるＷｅｂ処理を行うミドルウェアである。本実施形態のサービスクラス２４は、全てのサービスで共通に使用される汎用的なものである。サービスクラスについては、後述する。

次に、本実施形態の実行環境における処理について説明する。

なお、本実施形態では、後述する開発環境の生成部２９によりあらかじめ生成された、クライアント１のＷＳＤＬ１１と、Ｗｅｂサービス基盤システム２のサービスエンドポイント２３、サービス呼出定義ファイル３１、ＪａｖａＢｅａｎｓ３２を用いる。

まず、クライアント１は、ユーザの指示などを受け付けて、ＳＯＡＰによるリクエスト電文をＷｅｂサービス基盤システム２に送信する。すなわち、クライアント１のアプリケーション１３は、ＷＳＤＬ１１から生成されるスタブ１２を用いて、リクエスト電文を生成し、Ｗｅｂサービス基盤システム２に送信する。リクエスト電文には、ミドルヘッダと、アプリケーションデータと、当該リクエスト電文の送信先であるＵＲＬ（Uniform Resource Locator）とが含まれる。ミドルヘッダは、クライアントと、Ｗｅｂサービス基盤システム２との間でやり取りする制御情報を保持するための領域である。なお、ＷＳＤＬ１１については、後述する。

図３は、クライアント１から送信されるリクエスト電文の一例を示すものである。図示すリクエスト電文は、ＨＴＴＰヘッダとＳＯＡＰ電文とを有する。ＨＴＴＰヘッダには、所望のサービスを識別するためのＵＲＬ３０１が含まれ、当該ＵＲＬ３０１の最後にはサービス名（図示する例では「ＰＴ０１」）が設定されている。ＳＯＡＰ電文には、ミドルヘッダ３０２と、アプリケーションデータ３０３が設定されている。

Ｗｅｂサービス基盤システム２のＳＯＡＰエンジン２２は、Ｗｅｂアプリケーション部２１を介してリクエスト電文を受け付け、当該リクエスト電文のＵＲＬ３０１に設定されたサービス名に対応するサービス呼出定義ファイル３１を読み出す。サービス呼出定義ファイル３１は、サービス毎に生成されるものとする。また、サービス呼出定義ファイル３１は、あらかじめ開発環境の生成部２９により生成され、Ｗｅｂサービス基盤システム２の図示しない記憶部に記憶されている。

図４は、サービス呼出定義ファイル３１の一例を示すものである。図示するサービス呼出定義ファイル３１には、サービス名として「ＰＴ０１」４０１が記述され、呼出メソッド名としてサービスクラス２４（Ｗｅｂサービスプロバイダ部２５）を意味する「ＴＲＤＯｐｅｒａｔｉｏｎ」４０２が記述されている。本実施形態では、全てのサービス呼出定義ファイル３１において、同一の呼出メソッド名（「ＴＲＤＯｐｅｒａｔｉｏｎ」）が設定される。これにより、各サービスエンドポイント２３は、全てのサービスエンドポイントに共通の汎用サービスクラス２４を呼び出す。

また、サービス呼出定義ファイル３１には、業務システムへ送信される上り電文で使用するＪａｖａＢｅａｎｓ（データ保持部品）の識別情報４０３（ミドルヘッダ用：「ａｉｆａｂｅａｎ」、アプリケーションデータ用：「ｌａｙ０２９ｂｅａｎ」）と、クライアントへ送信される下り電文で使用するＪａｖａＢｅａｎｓの識別情報４０４（アプリケーションデータ用：「ｐｔ０１ｒｅｔａｕｒｎｂｅａｎ」）とが記述され、さらに、電文の型定義４０５が記述されている。

ＳＯＡＰエンジン２２は、対応するサービス呼出定義ファイル３１に基づいてリクエスト電文のＳＯＡＰ電文をデシリアライズし、リクエスト電文で指定されたサービス名に対応するサービスエンドポイント２３にＪａｖａＢｅａｎｓを受け渡す。すなわち、ＳＯＡＰエンジン２２は、ＸＭＬで記述されたＳＯＡＰ電文のデータをＪａｖａ（登録商標）言語に変換し、サービス呼出定義ファイル３１で指定された上り電文用のＪａｖａＢｅａｎｓに格納して、サービスエンドポイント２３に送出する。

なお、図４に示すサービス呼出定義ファイル３１の場合、ＳＯＡＰエンジン２２は、ＳＯＡＰ電文のミドルヘッダについては「ａｉｆａｂｅａｎ」のＪａｖａＢｅａｎｓに、ＳＯＡＰ電文のアプリケーションデータについては「ｌａｙ０２９ｂｅａｎ」のＪａｖａＢｅａｎｓに、データを格納する。

また、各サービスで使用するミドルヘッダ、上り電文および下り電文のＪａｖａＢｅａｎｓ（データが入っていない空の状態のデータ保持部品）は、あらかじめ開発環境の生成部２９により生成され、Ｗｅｂサービス基盤システム２に設けられている。

ＪａｖａＢｅａｎｓを受け付けたサービスエンドポイント２３は、自サービスエンドポイントのサービスに対応するサービス呼出定義ファイル３１を参照し、当該サービス呼出定義ファイル３１に設定された情報に基づいて、汎用のサービスクラス２４を呼び出す。具体的には、呼び出しメソッド名４０２（図４参照）に設定されたサービスクラス２４を呼び出す。その際に、サービスエンドポイント２３は、受け付けたＪａｖａＢｅａｎｓおよびサービス呼出定義ファイルに設定された各種情報（サービス名、ＪａｖａＢｅａｎｓのＩＤなど）を引数として、サービスクラス２４に受け渡す。

サービスクラス２４のデータ変換部２６は、Ｗｅｂサービスプロバイダ部２５を介して、ＪａｖａＢｅａｎｓ３２などの引数を受け取る。そして、データ変換部２６は、受け取ったＪａｖａＢｅａｎｓ３２に保持されたデータのデータチェックを行い、当該データをデータ記憶部３６に格納する。本実施形態のデータ記憶部３６は、データストアビーン（ＤＳＢ）と、リクエストデータホルダー（ＲＤＨ）と、セッションデータホルダー（ＳＤＨ）とを有する。

データ変換部２６は、上り電文（アプリケーションデータ）のＪａｖａＢｅａｎｓに保持されたデータについてはＤＳＢに格納し、ミドルヘッダのＪａｖａＢｅａｎｓに保持されたデータについてはＲＤＨおよびＳＤＨに格納する。なお、データ記憶部３６は、業務システム７、８の全てのサービスからアクセスが可能なデータ領域である。

そして、データ変換部２６は、ＪａｖａＢｅａｎｓ３２から生成され、データ記憶部３６に格納されたＤＳＢ、ＲＤＨ、ＳＤＨのデータ、およびサービス名を引数として、トランザクション呼出部２７を呼び出す。トランザクション呼出部２７は、トランザクション呼出定義ファイル３３を参照し、引数として設定されたサービス名に対応する業務システム７、８のトランザクションＩＤおよび呼出先を特定する。トランザクション呼出定義ファイル３３は、業務システム７、８への呼び出しを定義するファイルであって、図示しない記憶部にあらかじめ記憶されている。

図５（ａ）は、トランザクション呼出定義ファイル３３の一例を示すものである。図示するトランザクション呼出定義ファイル３３には、サービス名５０１と、当該サービス名５０１に対応する業務システムのトランザクションＩＤ５０２および呼出先５０３とが対応付けて記憶されている。呼出先５０３には、呼び出す業務システムを識別するための識別情報（システムＩＤ等）が設定される。なお、図示するトランザクション呼出定義ファイル３３には、一組のサービス名とトランザクションＩＤ・呼出先しか記述されていないが、実際には複数の組のサービス名とトランザクションＩＤ・呼出先とが対応付けて記述されている。

起動するトランザクションが第１の業務システム７のＪａｖａ（登録商標）ロジックの場合、呼出先５０３として第１の業務システム７のシステムＩＤが設定される。一方、起動するトランザクションが第２の業務システム８のＣＯＢＯＬ、Ｃ言語などで記述されたアプリケーションプログラムの場合、呼出先５０３として接続部２８が設定される。

トランザクション呼出部２７は、特定したトランザクションＩＤおよびＤＳＢ、ＲＤＨ、ＳＤＨのデータを引数として、特定した呼出先を呼び出す。

第１の業務システム７が呼び出された場合、第１の業務システム７は引数として指定されたトランザクションを起動し、引数として受け渡されたデータを用いて所定の業務処理を行い、処理結果をトランザクション呼出部２７を介してデータ変換部２６に送信する。なお、データ変換部２６に送信される処理結果は、Ｊａｖａ（登録商標）のデータ形式のデータである。

一方、接続部２８が呼び出された場合、接続部２８は、引数として指定されたトランザクションＩＤに対応するデータ変換ファイル３４を参照し、当該データ変換ファイル３４で指定された電文定義ファイルＩＤを特定する。そして、接続部２８は、特定した電文定義ファイルＩＤの電文定義ファイルを読み出す。データ変換ファイル３４は、業務システムの入出力を定義するファイルであり、電文定義ファイル３５は、各入出力毎のデータレイアウトを定義するファイルであって、これらのファイル３４、３５は図示しない記憶部にあらかじめ記憶されている。

図５（ｂ）は、データ変換ファイル３４の一例を示すものである。図示するデータ変換ファイル３４には、第２の業務システム８のトランザクションＩＤ５１１と、当該トランザクションＩＤ５１１に対応する上り電文用の電文定義ファイルＩＤ５１２および下り電文用の電文定義ファイルＩＤ５１３とが対応付けて記憶されている。

図５（ｃ）は、電文定義ファイル３５の一例を示すものである。図示する電文定義ファイル３５には、電文定義ファイルＩＤ５２１と、当該電文定義ファイルＩＤ５２１に対応する電文のデータレイアウト定義５２２（データ名、データタイプ、桁数、データの並び順、等）とが対応付けて記憶されている。

接続部２８は、データ変換ファイル３４を参照して特定した上り電文用の電文定義ファイルＩＤ５１２の電文定義ファイル３５を読み出し、当該電文定義ファイル３５のデータレイアウト定義５２２を用いて、引数として受け渡されたＤＳＢのデータを、第２の業務システム８のトランザクション（アプリケーションプログラム）で使用可能なデータ形式に変換する。そして、接続部２８は、変換したデータおよびトランザクション呼出定義ファイル３３から特定したトランザクションＩＤを引数として第２の業務システム８を呼び出す。

第２の業務システム８は、引数として指定されたトランザクションを起動し、引数として受け渡されたデータを用いて所定の業務処理を行い、処理結果を接続部２８に送信する。

接続部２８は、データ変換ファイル３４で指定された下り電文用の電文定義ファイルＩＤ５１３に対応する電文定義ファイル３５を読み出し、当該電文定義ファイル３５のデータレイアウト定義を用いて、第２の業務システム８から送信された処理結果のデータをＤＳＢのデータ形式（Ｊａｖａ（登録商標）データ）に変換する。そして、接続部２８は、変換したＤＳＢのデータ形式のデータを、トランザクション呼出部２７を介してデータ変換部２６に送信する。

データ変換部２６は、業務システム７、８からＤＳＢのデータ形式で受け付けた処理結果（下り電文を）を、データ記憶部３６のＤＳＢに記憶するととともに、サービス呼出定義ファイル３１（図４参照）で記述された下り電文用のＪａｖａＢｅａｎｓに格納する。なお、サービスエンドポイント２３は、サービスクラス２４を呼び出す際に、引数として下り電文用のＪａｖａＢｅａｎｓのＩＤをサービスクラス２４（データ変換部２６）に通知しておく。

そして、データ変換部２６は、Ｗｅｂサービスプロバイダ部２５および対応するサービスエンドポイント２３を介して、下り電文用のＪａｖａＢｅａｎｓをＳＯＡＰエンジン２２に送出する。また、データ変換部２６は、下り電文用のＪａｖａＢｅａｎｓとともに、リターンコードを設定したミドルヘッダ用のＪａｖａＢｅａｎｓを、ＳＯＡＰエンジン２２に送出することとしてもよい。

ＳＯＡＰエンジン２２は、受け付けたＪａｖａＢｅａｎｓに格納されたデータを、サービス呼出定義ファイル３１に基づいてシリアライズしてレスポンス電文を生成し、クライアント１に送信する。すなわち、ＳＯＡＰエンジン２２は、ＪａｖａＢｅａｎｓに格納されたＪａｖａ（登録商標）データを、ＸＭＬで記述されたＳＯＡＰ電文に変換する。

図６は、レスポンス電文の一例を示すものである。図示すレスポンス電文は、ＨＴＴＰヘッダとＳＯＡＰ電文とを有し、ＳＯＡＰ電文には、リターンコードが設定されたミドルヘッダ４０１と、アプリケーションデータ（処理結果）４０２が記述されている。

［開発環境の処理］
次に、本実施形態における開発環境について説明する。

Ｗｅｂサービス基盤システム２の生成部２９は、クライアント１で使用するＷＳＤＬ１１と、Ｗｅｂサービス基盤システム２の実行環境で使用するサービスエンドポイント２３、ＪａｖａＢｅａｎｓ３２、およびサービス呼出定義ファイル３１とを生成する（図１参照）。

＜ＷＳＤＬの生成＞
まず、ＷＳＤＬの生成処理について説明する。

ＷＳＤＬ（Web Service Description Language：ウェブサービス記述言語）は、Ｗｅｂサービスを記述するための、ＸＭＬをベースとした言語仕様である。ＷＳＤＬには、それぞれのＷｅｂサービスがどのような機能を持つのか、それを利用するためにはどのような要求をすればいいのか、などの定義が記述され、Ｗｅｂサービスを提供するサービスプロバイダとＷｅｂサービスを利用するサービスリクエスタ（クライアント）の間でインターフェイス情報をやり取りするために使用される。ＷＳＤＬには、クライアントがＷｅｂサービスのメソッドを呼び出すのに必要な情報が含まれる。

図７に示すように、本実施形態の生成部２９は、実行環境で使用するトランザクション呼出定義ファイル３３、データ変換定義ファイル３４および電文定義ファイル３５に基づいて、クライアント１で使用するＷＳＤＬ１１を生成する。なお、ＷＳＤＬ１１の生成の際に、生成部２９は、後述するＷＳＤＬネーミングルール７０１を用いる。

図８は、ＷＳＤＬ１１の構造を模式的に示す図である。

ＷＳＤＬ１１は、タイプ要素７１、メッセージ要素７２、ポートタイプ要素７３、バインディング要素７５及びサービス要素７６とを有する。ポートタイプ要素７３は、少なくとも１つのオペレーション要素７４を有し、サービス要素７６は、少なくとも１つのポート要素７７を有する。また、ＷＳＤＬ１１は、最上位の要素としてＤｅｆｉｎｉｔｉｏｎｓ要素７０を、有する。

タイプ要素７１では、ミドルヘッダ、上り電文、下り電文、下り電文構造体などの下位のデータ型を定義する。ネストした型も定義することができる。メッセージ要素３では、送信データフォーマットを定義する。要求として受信するメッセージは、どのような名前の要素で、それにはどのタイプ要素７１で定義されたデータ型が含まれるのかなどを定義する。

ポートタイプ要素４では、メッセージ要素３で定義された送信データフォーマットをいくつか組み合わせて、１つの操作単位を論理的に定義する。具体的には、リクエスト電文（メッセージ）とそれに対応するレスポンス電文（メッセージ）とを定義する。

バインディング要素７５では、前記タイプ定義７１、メッセージ定義７２、ポートタイプ定義７３などで定義されたインターフェイスの論理的なモデル（こういうデータ型を組み合わせて、こういうメッセージで、こういうやりとりをするという定義）と、物理的なモデル（例えば、SOAP-RPCを、HTTP上で行うという定義）とを結びつける定義をする。SOAP-RPCは、RPC（Remote Procedure Call）すなわち遠隔手続き呼び出しをSOAPすなわちXMLを使用した通信規約を使用して行うための仕様である。

サービス要素７６では、具体的なアクセスポイントを定義する。ポート要素７７では、どのバインディング要素７５のインターフェイスを、どのＵＲＬで提供するかを定義する。

本実施形態では、実行環境で使用するトランザクション呼出定義ファイル３３、データ変換定義ファイル３４および電文定義ファイル３５に基づいてタイプ定義７１を作成し、タイプ定義７１に基づいてメッセージ定義７２を作成し、メッセージ定義７２に基づいてポートタイプ定義７３を作成し、ポートタイプ定義７３に基づいてバインディング定義７５を作成し、バインディング定義７５に基づいてサービス定義７６を作成する。

図９は、ＷＳＤＬ１１を生成する処理の流れを示すフローチャートである。図１０は、トランザクション呼出定義ファイル３３、データ変換定義ファイル３４および電文定義ファイル３５と、ＷＳＤＬ１１との関連を模式的に示す関連図である。

まず、生成部２９は、トランザクション呼出定義ファイル３３、データ変換定義ファイル３４および電文定義ファイル３５を入力し、図示しない記憶部に記憶する（Ｓ１１）。

図１０に示すトランザクション呼出定義ファイル３３の例では、「ＰＴ０１」のサービス名に対して、「ＢＥ８０１」というトランザクションＩＤが関連付けられている。なお、図示するトランザクション呼出定義ファイル３３には、一組のサービス名とトランザクションＩＤしか記述されていないが、実際には複数の組のサービス名とトランザクションＩＤとが対応付けて記述されているものとする。

また、図１０に示すデータ変換定義ファイル３４の例では、「ＢＥ８０１」というトランザクションＩＤの上り電文に対して、「Ｌａｙ０２９」（電文レイアウトＩＤ）の電文定義ファイルが関連付けられ、当該トランザクションＩＤの下り電文に対して、「Ｌａｙｏｕｔ２」（電文レイアウトＩＤ）の電文定義ファイルが関連付けられている。また、図１０に示す「Ｌａｙ０２９」の電文定義ファイル３５の例では、「ｍｅｍｎｏ」の項目名（カラム）のデータ型は文字列型であり、「ｐａｓｓｗｄ」のデータ項目名（カラム）のデータ型は文字列型であることが記述されている。

そして、生成部２９は、ＷＳＤＬ生成情報の入力を受け付ける（Ｓ１２）。ＷＳＤＬ生成情報には、サービス名、ＷＳＤＬファイル出力先ディレクトリ名、エンドポイントＵＲＬなどが含まれる。生成部２９は、ＷＳＤＬ生成情報として入力されたサービス名に対応するＷＳＤＬ１１を、以降の処理により生成する。

そして、生成部２９は、Ｓ１１で入力され、記憶部に記憶されたトランザクション呼出定義ファイル３３を読み出し、Ｓ１２で入力されたサービス名に対応するトランザクションＩＤを取得する（Ｓ１３）。図９に示す例では、「ＰＴ０１」のサービス名が入力された場合、「ＢＥ８０１」のトランザクションＩＤが取得される。

そして、生成部２９は、記憶部に記憶されたデータ変換定義ファイル３４を読み出し、Ｓ１３で取得したトランザクションＩＤに対応する電文レイアウトＩＤを取得し、取得した電文レイアウトＩＤの電文定義ファイルを記憶部から読み出す（Ｓ１４）。図９に示す例では、「ＢＥ８０１」のトランザクションＩＤが取得された場合、上り電文については「Ｌａｙ０２９」の電文レイアウトＩＤを、下り電文については「Ｌａｙｏｕｔ２」の電文レイアウトＩＤを取得する。

そして、生成部２９は、Ｓ１２で入力されたサービス名およびＷＳＤＬネーミングルール７０１に基づいて、ＷＳＤＬのＤｅｆｉｎｉｔｉｏｎｓ定義を生成する（Ｓ１５）。

ＷＳＤＬネーミングルール７０１は、図示しない記憶部にあらかじめ記憶され、サービスＩＤ名、出力ＷＳＤＬファイル名、ＸＭＬ名前空間設定、ＸＭＬ宣言、タイプ定義、メッセージ定義、ポートタイプ定義、バインディング定義、サービス定義の各々に関するネーミングルールを有する。

図１１から図１５は、記憶部に記憶されたＷＳＤＬネーミングルール７０１の一例を示すものである。図１１は、サービス名、出力ＷＳＤＬファイル名、ＸＭＬ名前空間設定、ＸＭＬ宣言に関するネーミングルールの一例を示す。

サービス名は、Ｗｅｂサービスのサービス名であり、Ｗｅｂサービス（アプリケーション）ごとに異なる。このサービス名は、ＷＳＤＬ生成情報としてＳ１２で入力される。出力ＷＳＤＬファイル名は、生成されたＷＳＤＬの出力ファイル名であり、サービス名と拡張子”.wsdl”から構成される。

ＸＭＬ名前空間設定のネーミングルールは、impl、wsdl、wsdlsoap、xsd、tns1、tns2及びsoapencから構成される。implは、サービスが属する名前空間であり、「サービス名」が設定されされる。wsdlは、WSDLフレームワークのためのWSDL名前空間を示す固定値（例えばhttp://schemas.xmlsoap.org/WSDL/）が設定される。Wsdlsoapは、WSDL SOAPバインディングのためのWSDL名前空間を示す固定値（例えばhttp://schemas.xmlsoap.org/WSDL/soap/）が設定される。xsdは、XSDで定義のスキーマ名前空間を示す固定値（例えばhttp://www.w3.org/2001/XMLScheme/が設定される。tns1は、ミドルヘッダの電文が属する名前空間を示す固定値（例えばhttp://PPPI.header.WSDL.info.nri.co.jp）が設定される。tns2は、上り電文及び下り電文が属する名前空間であり、例えばhttp://[サービス名].apl.wsd.info.nri.co.jpが設定される。soapencは、SOAP1.1で定義されているエンコーディング名前空間を示す固定値（例えばhttp://schemas.xmlsoap.org/soap/encoding/）が設定される。

xml宣言のネーミングルールは、xml versionとencodingとを有する。xml versionは、ＸＭＬのバージョンを示す固定値であって、例えば1.0となる。encodingは、エンコーディングを示す固定値であって、例えばUTF-8となる。

Ｓ１２で入力されたサービス名が「ＰＴ０１」であって、図１１に示すＷＳＤＬネーミングルールを用いた場合に、生成部２９が生成するＷＳＤＬのdifinitions要素の一例を以下に示す。

<?xml version="1.0" encoding="UTF-8"?>
<WSDL:definitions targetNamespace="PT01" xmlns:impl=" PT01"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns1="http://PPPI.header.wsd.info.nri.co.jp"
xmlns:tns2="http:// PT01.apl.wsd.info.nri.co.jp"
xmlns:WSDL="http://schemas.xmlsoap.org/WSDL/"
xmlns:WSDLsoap="http://schemas.xmlsoap.org/WSDL/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
そして、生成部２９は、Ｓ１４で読み出した電文定義ファイル３５及びＷＳＤＬネーミングルールに基づいてタイプ定義を作成する（Ｓ１６）。

図１２および図１３は、記憶部に記憶されたタイプ定義に関するＷＳＤＬネーミングルールの一例を示すものである。図示するように、タイプ定義は、ミドルヘッダ、上り電文、下り電文、下り電文構造体（ミドルヘッダ＋下り電文）に関する定義から構成される。

図１１に示すように、ミドルヘッダ（O3Wヘッダ）は、タイプ定義名(complexType name)、targetNamespace、名前空間接頭辞、type項目名(element name)、type属性(type)から構成される。タイプ定義名は、ミドルヘッダのデータ名を示す固定値（例えば、O3WheadBean）が設定される。名前空間接頭辞は、ミドルヘッダの電文が属する名前空間の接頭辞を示す固定値（例えば、tns1）が設定される。targetNamespaceは、ミドルヘッダの電文が属する名前空間であり、tns1で指定した名前が設定される。type項目名は、ミドルヘッダとして設定する項目であり、電文定義ファイル３５で設定された項目名が設定される。type属性は、ミドルヘッダのデータ型を示す固定値（例えば、xsd:string）が設定される。

以下に、生成部２９が生成するミドルヘッダのタイプ定義に対応するＷＳＤＬの一例を示す。

<WSDL:types>
<schema targetNamespace="http://PPPI.header.wsd.info.nri.co.jp" xmlns="http://www.w3.org/2001/XMLSchema">
<complexType name="O3WheadBean">
<sequence>
<element name="APL_KYOSEI" type="xsd:string"/>
<element name="APLSYOGAI" type="xsd:string"/>
</sequence>
</complexType>
<element name="O3WheadBean" type="tns1:O3WheadBean"/>
</schema>
次に、タイプ定義の上り電文について説明する。図１２に示すように、上り電文のネーミングルールは、type定義名(complexType name)、targetNamespace、名前空間接頭辞、type項目名(element name)、type属性(type)とを有する。type定義名は、上り電文のデータ名であり、[電文レイアウトID]+Beanが設定される。名前空間接頭辞には、上り電文が属する名前空間の接頭辞を示す固定値（例えばtns2）が設定される。targetNamespaceは、上り電文が属する名前空間であり、tns2で指定した名前空間が設定される。type項目名およびtype属性は、電文定義ファイル３５で設定された項目名およびデータ型が設定される。

以下に、生成部２９が生成する上り電文のタイプ定義に対応するＷＳＤＬの一例を示す。

<schema targetNamespace="http://PT01.apl.wsd.info.nri.co.jp" xmlns="http://www.w3.org/2001/XMLSchema">
<complexType name="Lay029Bean">
<sequence>
<element name="memmo" type="xsd:string"/>
<element name="passwd" type="xsd: string"/>
</sequence>
</complexType>
<element name=" Lay029Bean" type="tns2: Lay029Bean"/>
次に、タイプ定義の下り電文について説明する。図１３に示すように、下り電文のネーミングルールは type定義名(complexType name)、targetNamespace、名前空間接頭辞、type項目名(element name)、type属性(type)から構成される。type定義名は、下り電文のデータ名であり、[電文レイアウトID]+Beanが設定され、名前空間接頭辞は、下り電文が属する名前空間の接頭辞を示す固定値（例えばtns2）が設定され、targetNamespaceは、下り電文が属する名前空間であり、tns2で指定した名前空間であって、上り電文と共有となる。

type項目名およびtype属性は、電文定義ファイルで設定された項目名およびデータ型が設定される。
以下に、生成部２９が生成する下り電文のタイプ定義に対応するＷＳＤＬの一例を示す。

<complexType name="Layout2Bean">
<sequence>
<element name="swkl000ap00" type="xsd:string"/>
<element name="swkl1100d00" type=" xsd:string"/>
</sequence>
</complexType>
</schema>
</WSDL:types>
次に、タイプ定義の下り電文構造体について説明する。下り電文構造体は、ミドルヘッダと下り電文とから構成されるものである。図１３に示すように、下り電文のネーミングルールは、type定義名(complexType name)、targetNameplace、名前空間接頭辞、type項目名(element name)、type属性(type)から構成される。type定義名は、下り電文構造体のデータ名であり、[サービス名]+ReturnBeanが設定される。名前空間接頭辞は、下り電文構造体が属する名前空間の接頭辞を示す固定値（例えばtns2）が設定される。

targetNamespaceは、下り電文構造体が属する名前空間であり、tns2で指定した名前空間であって、上り電文と共有する。type項目名は、下り電文構造体として設定する項目であり、ミドルヘッダと下り電文のtype定義名を小文字にしたも（例えばo3wheadbeanなど）が設定される。type属性は、下り電文構造体のデータ型であり、例えば、ミドルヘッダに関してはtns1:O3WheadBean、下り単純電文に関してはtns2:[下り電文のtype定義名]が設定される。

以下に、生成部２９が生成する下り電文構造体のタイプ定義に対応するＷＳＤＬの一例を示す。

<complexType name="PT01ReturnBean">
<sequence>
<element name="o3wheadbean" type="tns1:O3WheadBean"/>
<element name="layout2bean" type="tns2: Layout2Bean"/>
</sequence>
</complexType>
<element name=" PT01ReturnBean" type="tns2: PT01ReturnBean"/>
そして、生成部２９は、Ｓ１６で生成したタイプ定義およびＷＳＤＬネーミングルールに基づいて、ＷＳＤＬのメッセージ定義を生成する（Ｓ１７）。

図１４は、記憶部に記憶されたメッセージ定義およびポートタイプ定義に関するＷＳＤＬネーミングルールの一例を示すものである。図１４に示すように、メッセージ定義は、リクエスト（Request）定義とレスポンス（Response）定義とから構成される。リクエスト定義およびレスポンス定義は、メッセージ名(message name)、パート名(part name)、パートタイプ(type)から構成される。

リクエスト定義については、メッセージ名は、上り電文のメッセージ名であり、[サービス名]+Requestを設定する。パート名およびパートタイプは、ミドルヘッダと上り電文でそれぞれ生成される。ミドルヘッダについては、パート名には、ミドルヘッダのtype定義名を小文字にしたものが設定され、パートタイプには、ミドルヘッダの[type定義で設定したtargetNamespaceの名前空間接頭辞]+":"+[type定義名]が設定される。上り電文については、パート名には、上り電文のtype定義名を小文字にしたものが設定され、パートタイプには、上り電文の[type定義で設定したtargetNamespaceの名前空間接頭辞]+":"+[type定義名]が設定される。

レスポンス定義については、メッセージ名は、下り電文構造体のメッセージ名であり、[サービス名]+Responseが設定される。パート名は、下り電文構造体のパート名であり、[下り電文構造体のtype定義名を小文字にしたもの]が設定される。パートタイプは、下り電文構造体のパートタイプであり、[下り電文構造体のtype定義で設定したtargetNamespaceの名前空間接頭辞]+":"+[type定義名]が設定される。

以下に、生成部２９が生成するＷＳＤＬのメッセージ定義の一例を示す。

<WSDL:message name="PT01Request">
<WSDL:part name="o3wheadbean" type="tns1:O3WheadBean"/>
<WSDL:part name="lay029bean" type="tns2:Lay029Bean"/>
</WSDL:message>
<WSDL:message name="PT01Response">
<WSDL:part name=" pt01returnbean" type="tns2: PT01ReturnBean"/>
</WSDL:message>
そして、生成部２９は、Ｓ１７で生成したメッセージ定義およびＷＳＤＬネーミングルールに基づいて、ＷＳＤＬのポートタイプ定義を生成する（Ｓ１８）。

図１４に示すように、ポートタイプ定義は、ポートタイプ名(portType name)、parameterOrder、オペレーション名(operation name)、inputのメッセージ名(message)、データ名(name)、outputのメッセージ名(message)、データ名(name)から構成される。

ポートタイプ名には、[サービス名]+"Server"が設定される。parameterOrderは、パラメータの順序を示す属性であり、"o3wheadbean"+[上り電文のtype定義名を小文字にしたもの]が設定される。オペレーション名は、サービスの呼び出しメソッド（サービスクラス２４）を示す固定値（例えばTRDOperation）が設定される。

inputのメッセージ名は、上り電文のメッセージ名であり、"impl:"+[message定義で設定したRequestメッセージ名]が設定される。inputのデータ名は、上り電文のデータ名であり、[サービス名]+"Request"が設定され、outputのメッセージ名は、下り電文構造体のメッセージ名であり、"impl:"+[message定義で設定したResponseメッセージ名]が設定される。outputのデータ名は、下り電文構造体のデータ名であり、[サービス名]+"Response"が設定される。

以下に、生成部２９が生成するＷＳＤＬのポートタイプ定義の一例を示す。

<WSDL:portType name="PT01Server">
<WSDL:operation name="TRDOperation" parameterOrder="o3wheadbean trl_a1bean">
<WSDL:input message="impl:PT01Request" name="PT01Request"/>
<WSDL:output message="impl:PT01Response" name="PT01Response"/>
</WSDL:operation>
</WSDL:portType>
そして、生成部２９は、Ｓ１８で生成したポートタイプ定義およびＷＳＤＬネーミングルールに基づいて、ＷＳＤＬのバインディング定義を生成する（Ｓ１９）。

図１５は、記憶部に記憶されたバインディイング定義およびサービス定義に関するＷＳＤＬネーミングルールの一例を示すものである。図１５に示すように、バインディング定義は、バインディング名(binding name)、バインディングタイプ(binding type)、transport、soapAction、バインディングスタイル(binding style)、オペレーション名(operation name)、inputのデータ名(input name)、inputのエンコード指定(use)、inputのエンコード形式(encodingStyle)、inputのネームスペース(namespace)、outputのデータ名(output name)、outputのエンコード指定(use)、outputのエンコード形式(encodingStyle)、outputのネームスペース(namespace)から構成される。

バインディング名には、[サービス名]+"SoapBinding"が設定され、バインディングタイプは、"impl:"+[portType定義で設定したポートタイプ名]が設定される。transportは、使用するプロトコルを示す固定値（例えばhttp://schemas.xmlsoap.org/soap/http）が設定される。soapActionは、SOAPActionヘッダの値を示す固定値が設定され、バインディングスタイルは、固定値（例えばrpc）が設定される。オペレーション名は、[portType定義で設定したオペレーション名]が設定される。

inputのデータ名は、上り電文のデータ名を示し、[portType定義で設定したRequestメッセージ名]が設定される。inputのエンコード指定は、上り電文のエンコード指定を示す固定値（例えばuse="encoded"）が設定される。inputのエンコード形式は、上り電文のエンコード形式を示す固定値（例えばhttp://schemas.xmlsoap.org/soap/encoding/）が設定される。inputのネームスペースは、上り電文のネームスペースであって、[サービス名]が設定される。

outputのデータ名は、下り電文構造体のデータ名を示し、[portType定義で設定したResponseメッセージ名]が設定される。outputのエンコード指定は、下り電文構造体のエンコード指定を示す固定値（例えばuse="encoded"）が設定される。outputのエンコード形式は、下り電文構造体のエンコード形式を示す固定値（例えばhttp://schemas.xmlsoap.org/soap/encoding/）が設定される。outputのネームスペースは、下り電文構造体のネームスペースであって、[サービス名]が設定される。

<WSDL:binding name="PLTr_A1SoapBinding" type="impl:PT01Server">
<WSDLsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<WSDL:operation name="TRDOperation">
<WSDLsoap:operation soapAction=""/>
<WSDL:input name="PT01Request">
<WSDLsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="PLTr_A1" use="encoded"/>
</WSDL:input>
<WSDL:output name="PT01Response">
<WSDLsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="PLTr_A1" use="encoded"/>
</WSDL:output>
</WSDL:operation>
</WSDL:binding>
そして、生成部２９は、Ｓ１９で生成したバインディング定義およびＷＳＤＬネーミングルールに基づいて、ＷＳＤＬのサービス定義を生成する（Ｓ２０）。

図１５に示すように、サービス定義は、サービス名(service name)、バインディング名(port binding)、ポート名(port name)、エンドポイントURL(address location)から構成される。

サービス名には、 [サービス名]＋ServerServiceが設定され、バインディング名には、”impl:”+[binding定義で設定したバインディング名]が設定される。ポート名には、[サービス名]が設定され、エンドポイントURLは、アクセスする際の相手先を示し、http://サーバアドレス/コンテキストルート/[サービス名]とする。

<WSDL:service name="PT01ServerService">
<WSDL:port binding="impl:PT01SoapBinding" name="PT01">
<WSDLsoap:address location="http://localhost:8090/axis/services/PT01"/>
</WSDL:port>
</WSDL:service>
生成部２９は、上記Ｓ１５〜Ｓ２０でそれぞれ生成したdifinitions定義、タイプ定義、メッセージ定義、ポートタイプ定義、バインディング定義及びサービス定義から構成されるＷＳＤＬファイルを、ＷＳＤＬ生成情報としてＳ１２で入力されたＷＳＤＬファイル出力先ディレクトリに出力する（Ｓ２１）。

＜サービス呼出定義ファイルの生成＞
次に、サービス呼出定義ファイル３１の生成について説明する。

生成部２９は、生成したＷＳＤＬに基づいてサービス呼出定義ファイル３１（図４参照）を生成する。すなわち、生成部２９は、ＷＳＤＬを入力し、ＳＯＡＰエンジンにより提供されている生成ツール（例えば、ＷＳＤＬ２Ｊａｖａ等）を用いて、当該ＷＳＤＬに対応するサービス呼出定義ファイル３１を生成する。生成ツールは、ＷＳＤＬからＪａｖａ（登録商標）加工物を生成するためのツールである。生成部２９は、生成ツールを用いて、入力されたＷＳＤＬを所定の条件に従って加工・編集することによりサービス呼出定義ファイル３１を生成する。なお、本実施形態では、サービス呼出定義ファイル３１の呼出メソッド名をサービス名ではなく、固定値（TRDOperation）となるように生成する。これにより、本実施形態では、複数のサービスを汎用のサービスクラスで実行することができる。

＜ＪａｖａＢｅａｎｓの生成＞
次に、ＪａｖａＢｅａｎｓ３２の生成について説明する。

生成部２９は、生成したＷＳＤＬに基づいて、実行環境で使用するデータ保持用部品であるＪａｖａＢｅａｎｓ３２を生成する。すなわち、生成部２９は、ＷＳＤＬを入力し、前記生成ツール（例えば、ＷＳＤＬ２Ｊａｖａ等）を用いて、当該ＷＳＤＬで使用するミドルヘッダ、上り電文、下り電文のＪａｖａＢｅａｎｓを生成する。図１６は、ミドルヘッダのＪａｖａＢｅａｎｓの一例を示すものである。

＜サービスエンドポイントの生成＞
次に、サービスエンドポイント２３の生成について説明する。

生成部２９は、引数としてサービス名の入力を受け付け、サービスエンドポイント用のネーミングルールを参照し、入力されたサービス名のサービスエンドポイントを生成する。図１７は、サービス名が、「BEsearch」のサービスエンドポイントの一例を示すものである。サービスエンドポイントは、図１に示すようにサービス毎に設ける必要があるため、生成部２９は、全てのサービスについて、それぞれのサービスエンドポイントを生成する。

以上説明した本実施形態によれば、既存の業務システムを変更することなく、より容易に既存の業務システムをＷｅｂサービスとしてクライアントに提供するができる。

すなわち、本実施形態のＷｅｂサービス基盤システムは、クライアントから送信されたリクエスト電文を、業務システムが処理可能なデータ形式に変換して業務システムに送信するとともに、業務システムの処理結果をクライアントが処理可能なデータ形式のレスポンス電文に変換して、要求元のクライアントに送信する。つまり、クライアントからのリクエスト電文によりＷｅｂサービス基盤システムが起動され、業務システムのトランザクションを呼び出すことにより、既存の業務システムを変更することなく、データ形式の相違を吸収し、既存の業務システムをより容易、よりスピーディにＷｅｂサービスとしてクライアントに提供するができる。

また、本実施形態では、実行環境で使用するトランザクション呼出定義ファイル、データ変換定義ファイルおよび電文定義ファイルに基づいて、クライアントで使用するＷＳＤＬを自動生成する。これにより、煩雑で誤りが発生しやすいＷＳＤＬのコーディングが不要となり、開発生産性を向上させることができる。また、本実施形態では、Ｗｅｂサービス基盤システムの実行環境で使用するサービスエンドポイント、ＪａｖａＢｅａｎｓ、およびサービス呼出定義ファイルについても自動生成するため、システム開発者の作業負荷を低減することができる。

また、本実施形態では、ＷＳＤＬを接続仕様としたドキュメント中心型のＷｅｂシステムにすることにより、既存の業務システムとの相互接続性をより向上させることができる。また、本実施形態では、Ｗｅｂサービスの標準仕様に対応することで、Ｗｅｂサービスとしての相互運用性、可搬性を高めることができる。

なお、本発明は上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。

１：クライアント、１１：ＷＳＤＬ、１２：スタブ、１３：アプリケーション、２：Ｗｅｂサービス基盤システム、２１：Ｗｅｂアプリケーション部、２２：ＳＯＡＰエンジン、２３：サービスエンドポイント、２４：サービスクラス、２５：Ｗｅｂサービスプロバイダ部、２６：データ変換部、２７：トランザクション呼出部、２８：接続部、２９：生成部、３１：サービス呼出定義ファイル、３２：ＪａｖａＢｅａｎｓ、３３：トランザクション呼出定義ファイル、３４：データ変換定義ファイル、３５：電文定義ファイル、３６：データ記憶部、７：第１の業務システム、８：第２の業務システム

Claims

業務システムが行う処理をＷｅｂサービスとしてクライアントに提供するＷｅｂサービス基盤システムであって、
所定の通信プロトコルに従って、クライアントとの間でメッセージの送受信を行う通信処理手段と、
Ｗｅｂサービス毎に設けられた、複数のサービスエンドポイントと、
全てのＷｅｂサービスに共通のＷｅｂサービス提供手段と、を有し、
前記通信処理手段は、前記クライアントからのサービス要求を、当該サービス要求で指定されたＷｅｂサービス用のサービスエンドポイントを介して、前記Ｗｅｂサービス提供手段に送出し、
前記Ｗｅｂサービス提供手段は、前記サービス要求を前記業務システムが処理可能なデータ形式に変換して、当該サービス要求で指定されたＷｅｂサービスに対応する業務システムに送信するとともに、前記業務システムの処理結果を前記通信処理手段が処理可能なデータ形式に変換して、前記Ｗｅｂサービス用のサービスエンドポイントを介して前記通信処理手段に送出し、
Ｗｅｂサービス毎に、前記通信処理手段と前記Ｗｅｂサービス提供手段との間でデータを送受信するためのデータ保持部品と、サービスエンドポイントの呼び出し先として前記Ｗｅｂサービス提供手段を示す呼出先情報とが設定されたサービス呼出定義ファイルと、
Ｗｅｂサービスと業務システムのトランザクションとを対応付けて記憶したトランザクション定義ファイルと、
トランザクション毎に、当該トランザクションで使用する電文のデータレイアウトのデータレイアウトＩＤが記憶されたデータ変換定義ファイルと、
データレイアウトＩＤ毎にデータレイアウトが記憶されたレイアウト定義ファイルと、をさらに有し、
前記通信処理手段は、前記サービス要求で指定されたＷｅｂサービスに対応するサービス呼出定義ファイルに設定されたデータ保持部品を特定し、当該データ保持部品に前記サービス要求のデータを格納して前記サービスエンドポイントに送出し、
前記サービスエンドポイントは、前記通信処理手段から受け付けた前記データ保持部品を、前記サービス呼出定義ファイルに設定された呼出先情報に基づいて前記Ｗｅｂサービス提供手段に送出し、
前記Ｗｅｂサービス提供手段は、
前記トランザクション定義ファイルを参照して、前記サービス要求で指定されたＷｅｂサービスに対応するトランザクションを特定し、
前記データ変換定義ファイルおよび前記レイアウト定義ファイルを参照して、特定したトランザクションに対応するデータレイアウトを読み出し、読み出したデータレイアウトに従って、前記サービスエンドポイントから受け付けたデータ保持部品のデータを変換し、業務システムの前記特定したトランザクションに送出すること
を特徴とするＷｅｂサービス基盤システム。
請求項１記載のＷｅｂサービス基盤システムであって、
前記トランザクション定義ファイル、データ変換定義ファイルおよびレイアウト定義ファイルを用いて、前記クライアントで使用する所定のＷｅｂサービスのＷＳＤＬを生成する生成手段を、さらに有すること
を特徴とするＷｅｂサービス基盤システム。
請求項２記載のＷｅｂサービス基盤システムであって、
前記生成手段は、前記生成した所定のＷｅｂサービスのＷＳＤＬを用いて、当該所定のＷｅｂサービス用のサービス呼出定義ファイルおよびデータ保持部品を生成すること
を特徴とするＷｅｂサービス基盤システム。