(57)【要約】【課題】インタフェース定義情報の変更に伴うエラーが発生した場合にそのエラーの発生を防止する為の修正及びテストを動的に行うことが可能な技術を提供する。【解決手段】インタフェース定義情報の変更に応じて変更されたメッセージをテストするプログラム管理方法であって、メッセージによるアクセス要求を送付した際に、そのアクセス要求先のインタフェースを示すインタフェース定義情報の変更によるエラーが発生したか否かを判定するステップと、インタフェース定義情報の変更によるエラーが発生した場合に、前記メッセージをその変更内容に合わせて変更するステップと、前記変更したメッセージによるアクセス要求をテスト送信するステップとを有するものである。【選択図】        図２
2004362051.tif 000002
【特許請求の範囲】
【請求項１】
インタフェース定義情報の変更に応じて変更されたメッセージをテストするプログラム管理方法であって、
メッセージによるアクセス要求を送付した際に、そのアクセス要求先のインタフェースを示すインタフェース定義情報の変更によるエラーが発生したか否かを判定するステップと、インタフェース定義情報の変更によるエラーが発生した場合に、前記メッセージをその変更内容に合わせて変更するステップと、前記変更したメッセージによるアクセス要求をテスト送信するステップとを有することを特徴とするプログラム管理方法。
【請求項２】
改訂前のインタフェース定義情報と改訂後のインタフェース定義情報とを比較することにより前記メッセージの変更箇所を検出することを特徴とする請求項１に記載されたプログラム管理方法。
【請求項３】
メッセージの送付テストであることを示す情報を前記変更後のメッセージのヘッダに付加して送付することにより前記アクセス要求のテスト送信を行うことを特徴とする請求項１または請求項２のいずれかに記載されたプログラム管理方法。
【請求項４】
インタフェース定義情報の変更に応じて変更されたプログラムをテストするプログラム管理方法であって、
メッセージによるアクセス要求を送付した際に、そのアクセス要求先のインタフェースを示すインタフェース定義情報の変更によるエラーが発生したか否かを判定するステップと、インタフェース定義情報の変更によるエラーが発生した場合に、前記アクセス要求を行うプログラムのインタフェースをその変更内容に合わせて変更するステップと、前記変更したプログラムによるアクセス要求をテスト送信するステップとを有することを特徴とするプログラム管理方法。
【請求項５】
メッセージの送付テストであることを示す情報を前記変更後のプログラムから出力されたメッセージのヘッダに付加して送付することにより前記アクセス要求のテスト送信を行うことを特徴とする請求項４に記載されたプログラム管理方法。
【請求項６】
前記アクセス要求のテスト送信でエラーが発生した場合にプログラムの変更を再度行うことを特徴とする請求項４または請求項５のいずれかに記載されたプログラム管理方法。
【請求項７】
インタフェース定義情報の変更に応じて変更されたメッセージをテストするプログラム管理装置であって、
メッセージによるアクセス要求を送付した際に、そのアクセス要求先のインタフェースを示すインタフェース定義情報の変更によるエラーが発生したか否かを判定するＦａｕｌｔ取得・解析処理部と、インタフェース定義情報の変更によるエラーが発生した場合に、前記メッセージをその変更内容に合わせて変更するメッセージ変更処理部と、前記変更したメッセージによるアクセス要求をテスト送信する通信処理部とを備えることを特徴とするプログラム管理装置。
【請求項８】
インタフェース定義情報の変更に応じて変更されたプログラムをテストするプログラム管理装置であって、
メッセージによるアクセス要求を送付した際に、そのアクセス要求先のインタフェースを示すインタフェース定義情報の変更によるエラーが発生したか否かを判定するＦａｕｌｔ取得・解析処理部と、インタフェース定義情報の変更によるエラーが発生した場合に、前記アクセス要求を行うプログラムのインタフェースをその変更内容に合わせて変更するコンポーネント変更処理部と、前記変更したプログラムによるアクセス要求をテスト送信する通信処理部とを備えることを特徴とするプログラム管理装置。
【請求項９】
インタフェース定義情報の変更に応じて変更されたメッセージをテストするプログラム管理装置としてコンピュータを機能させる為のプログラムであって、
メッセージによるアクセス要求を送付した際に、そのアクセス要求先のインタフェースを示すインタフェース定義情報の変更によるエラーが発生したか否かを判定するＦａｕｌｔ取得・解析処理部と、インタフェース定義情報の変更によるエラーが発生した場合に、前記メッセージをその変更内容に合わせて変更するメッセージ変更処理部と、前記変更したメッセージによるアクセス要求をテスト送信する通信処理部としてコンピュータを機能させることを特徴とするプログラム。
【請求項１０】
インタフェース定義情報の変更に応じて変更されたプログラムをテストするプログラム管理装置としてコンピュータを機能させる為のプログラムであって、
メッセージによるアクセス要求を送付した際に、そのアクセス要求先のインタフェースを示すインタフェース定義情報の変更によるエラーが発生したか否かを判定するＦａｕｌｔ取得・解析処理部と、インタフェース定義情報の変更によるエラーが発生した場合に、前記アクセス要求を行うプログラムのインタフェースをその変更内容に合わせて変更するコンポーネント変更処理部と、前記変更したプログラムによるアクセス要求をテスト送信する通信処理部としてコンピュータを機能させることを特徴とするプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はプログラム若しくはオブジェクトの変更管理及びテストを行うプログラム管理装置に関するものである。
【０００２】
【従来の技術】
近年、インターネットを用いた分散オブジェクト技術であるＷｅｂサービス（プログラムやオブジェクトの実行により実現される機能）が注目されている。Ｗｅｂサービスに関しては、その基礎技術として、ＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）、ＷＳＤＬ（Ｗｅｂ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ）、ＵＤＤＩ（Ｕｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｄｉｓｃｏｖｅｒｙ，  ａｎｄ  Ｉｎｔｅｇｒａｔｉｏｎ）がある（例えば非特許文献１参照）。
【０００３】
ＳＯＡＰは構造化文書交換に使う封筒構造の定義であり、この定義に従って記述した構造化文書をＳＯＡＰメッセージと呼び、Ｗｅｂサービスを用いたクライアント／サーバプログラムではこのＳＯＡＰメッセージを用いて通信を行う（例えば非特許文献１  ｐｐ．２５−５３参照）。
【０００４】
ＷＳＤＬは、Ｗｅｂサービスのインタフェースを定義する為の構造化文書フォーマットである。ＷｅｂサービスではＷＳＤＬファイルをインタフェースとし、ＳＯＡＰメッセージを用いて通信を行う（例えば非特許文献１ｐｐ．７２−９５参照）。
【０００５】
ＵＤＤＩは、Ｗｅｂサービスに対するグローバルレジストリと標準仕様を提供しており、インターネットで共通に利用できるレジストリとして公開されている。従って、Ｗｅｂサービスを用いたクライアント／サーバプログラムでは、サーバプログラムのＷｅｂサービスをこのＵＤＤＩレジストリに登録しておき、クライアントプログラムはこのＵＤＤＩレジストリに登録されているＷｅｂサービスを見つけることにより、サーバプログラムのＷｅｂサービスが利用できる様になる（例えば非特許文献１ｐｐ．９８−１３９参照）。
【０００６】
【非特許文献１】
Ｄａｖｉｄ  Ａ．  Ｃｂａｐｐｅｌｌ他著「Ｊａｖａ  Ｗｅｂ  Ｓｅｒｖｉｃｅｓ」、出版社：Ｏ’Ｒｅｉｌｌｙ  ＆  Ａｓｓｏｃｉａｔｅｓ，Ｉｎｃ．，  ２００２．３
【０００７】
【発明が解決しようとする課題】
分散技術におけるアクセス要求送付先のインタフェース定義情報が変更された場合を考えてみる。保守作業者は、クライアントプログラムがエラーメッセージを受け付けた原因がインタフェース定義情報の変更によるものであることを判っており、それを基にクライアントプログラムを修正するものとする。
【０００８】
上記の様なクライアントプログラムの保守作業に際しては、エラーを発生させた送付メッセージが、改訂前のインタフェース定義情報に従って生成されたメッセージかどうかを確認し、生成されたメッセージが改訂前のインタフェース定義情報に従って正しく生成されたものである場合には、改訂後のインタフェース定義情報を取得し、改訂後のインタフェース定義情報に従ったメッセージを送付する様にクライアントプログラムを修正する。
【０００９】
しかしながら、従来の方法によるクライアントプログラムの生成は、インタフェース定義情報と雛型からクライアントプログラムを生成するものに過ぎない。その為、実行中のクライアントプログラムに発生したエラーがインタフェース定義情報の変更によるエラーであると判っていても、保守作業者は、一旦クライアントプログラムを停止させ、改訂後のインタフェース定義情報を取得し、それに沿ったクライアントプログラムの雛型の作成を再度行い、インタフェース定義情報の変更箇所とプログラムの修正個所の対応関係を判断しながら作業する等の手間のかかる作業を行う必要がある。
【００１０】
更に、プログラムの変更・修正を行った後、実運用に入る前にテストを行う必要もあり、その結果によっては、更にクライアントプログラムの修正が必要になる。
【００１１】
本発明の目的は上記問題を解決し、インタフェース定義情報の変更に伴うエラーが発生した場合にそのエラーの発生を防止する為の修正及びテストを動的に行うことが可能な技術を提供することにある。
【００１２】
【課題を解決するための手段】
本発明は、インタフェース定義情報の変更に応じて変更されたメッセージをテストするプログラム管理装置であって、インタフェース定義情報の変更によるエラー発生時にその変更内容に合わせてメッセージまたはプログラムを変更してアクセス要求をテスト送信するものである。
【００１３】
本発明のプログラム管理装置（計算機や情報処理装置、またはその様な処理を実施するプログラムやオブジェクトでも良い）では、Ｗｅｂサービス（プログラムやオブジェクトの実行により実現される機能）を提供するＷｅｂサービスサーバに対して、ＳＯＡＰメッセージによるアクセス要求を送付してＷｅｂサービスの提供を受ける処理を行う。
【００１４】
前記ＳＯＡＰメッセージによるアクセス要求を送付した際に、そのアクセス要求先のＷｅｂサービスプログラムとの間でやりとりされるデータや操作等に関するインタフェースを示すインタフェース定義情報の変更によるエラー、すなわちＷＳＤＬファイルの変更によるエラーが発生したか否かを判定し、ＷＳＤＬファイルの変更によるエラーが発生した場合には、改訂前のＷＳＤＬファイルと改訂後のＷＳＤＬファイルとを比較して変更箇所を調べる。
【００１５】
そして、その変更箇所に合わせて前記ＳＯＡＰメッセージを変更し、前記変更したＳＯＡＰメッセージによるアクセス要求をＷｅｂサービスサーバに対してテスト送信する。そのテスト送信でエラーが発生しない場合には、以後、Ｗｅｂサービスサーバに対してアクセス要求を行う際には、前記と同様にしてＳＯＡＰメッセージを変更して送信するという運用を行う。
【００１６】
また、アクセス要求を行うクライアントプログラムを前記変更箇所に合わせて修正し、前記変更したクライアントプログラムによるアクセス要求をＷｅｂサービスサーバに対してテスト送信する様にしても良い。そのテスト送信でエラーが発生しない場合には、改訂前のクライアントプログラムを停止して、改訂後のクライアントプログラムを実行し、以後、改訂後のクライアントプログラムによる運用を行う。
【００１７】
ここで、複数のＷｅｂサービスサーバに対してアクセス要求を行う場合等、前記テスト送信でエラーが発生している場合には、各ＷｅｂサービスサーバへのＳＯＡＰメッセージの内、エラーの発生しているＷｅｂサービスサーバへのＳＯＡＰメッセージのみを変更する様に、ＳＯＡＰメッセージまたはクライアントプログラムの修正を行う様にしても良い。
【００１８】
以上の様に本発明のプログラム管理装置によれば、インタフェース定義情報の変更に伴うエラーが発生した場合にそのエラーの発生を防止する為の修正及びテストを動的に行うことが可能である。
【００１９】
【発明の実施の形態】
（実施形態１）
以下にインタフェース定義情報の変更に応じて変更されたメッセージをテストする実施形態１のプログラム管理装置について説明する。
【００２０】
図１は本実施形態のＷＳＤＬファイルの変更例を示す図である。図１の様にＷｅｂサービス（プログラムやオブジェクトの実行により実現される機能）のインタフェースを示すＷＳＤＬ１（１−１）の保存場所情報がＷＳＤＬ２（１−４）の保存場所情報に変更された場合、すなわち、改訂前のＷＳＤＬ１においては、ユーザ情報として名前と年齢のみの入力を受け付けていたが、改訂後のＷｅｂサービスでは、名前、年齢に加えて電話番号の入力を受け付ける場合、図１の様に、＜ＮＡＭＥ＞，＜ＡＧＥ＞タグ（１−２，１−３）のみのＷＳＤＬ１から＜ＮＡＭＥ＞，＜ＡＧＥ＞，＜ＴＥＬ＞タグ（１−５，１−６，１−７）のＷＳＤＬ２へと変更される。具体的には１−８の行が追加される。
【００２１】
図２は本実施形態のプログラム管理装置の処理概要を示す図である。本実施形態ではプログラムを対象として説明するが、オブジェクトに対しても適用可能である。
【００２２】
図２に示す様に通常の運用は、Ｗｅｂサービスサーバ２−１とＷｅｂサービスクライアント２−４上のＷｅｂアプリケーション運用処理２−６との間でのＳＯＡＰメッセージ通信２−２によって行われる。なお、図に示したクライアント及びサーバの各装置は、計算機や情報処理装置、またはその様な処理を実施するプログラムやオブジェクトでも良い。
【００２３】
ここで、Ｗｅｂサービスサーバ２−１において、ＷｅｂサービスのインタフェースであるＷＳＤＬが図１の様に変更になった場合、Ｗｅｂサービスクライアント２−４側から送られてきたＳＯＡＰメッセージのインタフェースが現在のインタフェースと異なる為、Ｗｅｂサービスサーバ２−１はＦａｕｌｔメッセージを返す。この場合のＦａｕｌｔｃｏｄｅはＳＯＡＰ−ＥＮＶ：Ｃｌｉｅｎｔとなる。
【００２４】
Ｗｅｂサービスクライアント２−４側のＷｅｂアプリケーション運用処理２−６がそのＦａｕｌｔメッセージを取得すると、変更検知処理２−７によってＷｅｂサービスサーバ２−１側のインタフェースであるＷＳＤＬの変更を検知し、変更箇所を特定する。
【００２５】
次に、Ｗｅｂアプリケーションテスト処理２−８により、ＳＯＡＰメッセージに修正を加え、修正したＳＯＡＰメッセージをテスト送信する（２−５）。このテスト結果、つまり送付したＳＯＡＰメッセージの応答を判断することにより、Ｗｅｂアプリケーションの運用２−６を再開するか、或いは運用を停止し、エラー内容を管理者に通知する処理を行う。
【００２６】
図３は本実施形態のクライアントプログラム側の処理の詳細を示す図である。以下、図３の処理フローを用いて本実施形態のクライアントプログラム側での処理の詳細を説明する。
【００２７】
ＷｅｂサービスクライアントがＷｅｂサービスサーバからの応答でＦａｕｌｔメッセージ３−１を取得すると（３−２）、まず、Ｆａｕｌｔメッセージの解析（３−３）を行う。Ｆａｕｌｔメッセージの解析（３−３）では、Ｆａｕｌｔｃｏｄｅタグの内容がＳＯＡＰ−ＥＮＶ：Ｃｌｉｅｎｔかそれ以外かを調べ、ＳＯＡＰ−ＥＮＶ：ＣｌｉｅｎｔであればＷＳＤＬの取得を行い（３−５）、ＳＯＡＰ−ＥＮＶ：Ｃｌｉｅｎｔ以外であれば、Ｗｅｂアプリケーションの運用を停止し、ユーザにエラー画面を表示し、管理者へエラー通知を行う（３−４）。
【００２８】
ＷＳＤＬの取得（３−５）では、予めクライアントＤＢ３−１５に保存してあるＷｅｂサービス検索条件を用いてＵＤＤＩレジストリ３−９でＷｅｂサービスの検索を行い（３−６）、改訂後ＷＳＤＬの保存場所情報を取得する（３−７）。ＷＳＤＬの取得（３−８）では、取得した保存場所情報のＵＲＬにアクセスし、改訂後ＷＳＤＬを取得する。
【００２９】
ＷＳＤＬ比較・差分取得３−１１では、前記取得した改訂後のＷＳＤＬ２（３−１０）とクライアントＤＢに保存してある改訂前ＷＳＤＬ１（３−１４）とを比較し、その差分を取得する。本実施形態の場合、例３−１２の様な差分を取得する。取得した差分から追加するタグ（ここではＴＥＬ）を判別し、その内容として空文字列（””）を設定し（３−２３）、エラーとなったＳＯＡＰメッセージのＢＯＤＹ要素に追加する（３−１３）。本実施形態では、エラー発生時にこの様なＳＯＡＰメッセージの修正を行う為に、ＷｅｂサービスクライアントからＷｅｂサービスサーバへ送信したＳＯＡＰメッセージをメモリ内に一時的に記録しているものとする。
次に、ＳＯＡＰメッセージをテストモードで送付する。これは、以下の様にして実施する。
【００３０】
ＳＯＡＰメッセージのＨｅａｄｅｒにＭｏｄｅタグを追加する（３−１６）。ここで、Ｍｏｄｅタグの属性をｍｕｓｔＵｎｄｅｒｓｔａｎｄ属性に設定し（３−２２）、ＷｅｂサービスサーバがＭｏｄｅタグを理解できない場合にはエラーを返す様にする。また、Ｍｏｄｅタグの内容は”ＴＥＳＴ”とする。本実施形態では、Ｗｅｂサービスサーバ側もこのＨｅａｄｅｒを解釈する機能を有しているものとし、Ｍｏｄｅタグの内容が”ＴＥＳＴ”の場合にはテストモードとして動作し、実際の予約や注文といった動作は行わずに、クライアント側から送られてきたＳＯＡＰメッセージが正常な入力かどうかをチェックしてそれに対する応答を返すものとする。
【００３１】
次に、変更したＳＯＡＰメッセージをＷｅｂサービスサーバに送付し（３−１７）、その応答を解析する（３−１８）。正常な応答が返ってきた場合には、即座に運用を再開する（３−２０）。また、Ｆａｕｌｔメッセージが返ってきた場合には、管理者へエラー内容を通知し、運用を停止する（３−１９）。
【００３２】
前記運用の再開では、Ｗｅｂサービスクライアントから出力されるＳＯＡＰメッセージに対して前記差分に相当するＢＯＤＹ要素の追加または削除等の修正を行った後、その修正したＳＯＡＰメッセージをＷｅｂサービスサーバへ送信する処理を行う。
【００３３】
図４は本実施形態のプログラム管理装置のシステム構成を示す図である。以下、図４及び図３を用いて、システム構成と各処理についての説明を行う。
【００３４】
Ｗｅｂサービスクライアント４−１１、Ｗｅｂサービスサーバ４−２０、ＵＤＤＩレジストリ４−２１、Ｗｅｂサーバ４−２２、ユーザＰＣ４−１４は、ネットワーク４−１２に接続されたコンピュータである。
【００３５】
本発明はサーバ−クライアント間の通信手段について特定するものではないが、本実施形態では、インターネット上でのＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）による通信を前提として説明する。すなわち、Ｗｅｂサービスクライアント４−１１はＨＴＴＰサーバとしての機能を備え、ユーザＰＣ４−１４からはＷｅｂブラウザ４−１３を介してＷｅｂサービスクライアント４−１１と通信を行うものとする。
【００３６】
また、Ｗｅｂサービスサーバ４−２０はＨＴＴＰサーバとしての機能を備え、Ｗｅｂサービスクライアント４−１１とＳＯＡＰメッセージを用いて通信を行うものとし、ＵＤＤＩレジストリ４−２１はＨＴＴＰサーバとしての機能を備え、Ｗｅｂサービスクライアント４−１１とＳＯＡＰメッセージを用いて通信を行うものとする。
【００３７】
Ｗｅｂサービスクライアント４−１１は、改訂前と改訂後のＷＳＤＬを有するデータベース４−６を保持する。また、メモリ上にＨＴＴＰ通信処理部４−２、ＳＯＡＰ通信処理部４−３、ＳＯＡＰメッセージ変更処理部４−４、ＳＯＡＰメッセージ作成処理部４−５、ＷＳＤＬ比較・差分取得処理部４−７、ＵＤＤＩ検索処理部４−８、ＷＳＤＬ取得処理部４−１０、Ｆａｕｌｔ取得・解析処理部４−１、表示処理部４−９を保持する。
【００３８】
Ｗｅｂサービスクライアント４−１１を、前記各処理部として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する記録媒体はＣＤ−ＲＯＭ以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体から情報処理装置にインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。
【００３９】
ＨＴＴＰ通信処理部４−２は、ＨＴＴＰに基づき通信を行う。ＳＯＡＰ通信処理部４−３は、テストモードを含むＳＯＡＰメッセージの送受信を行う（３−１７）。Ｆａｕｌｔ取得・解析処理部４−１は、Ｆａｕｌｔの取得（３−２）及びＦａｕｌｔメッセージの解析（３−３）を行う。ＳＯＡＰメッセージ変更処理部４−４は、ＳＯＡＰメッセージのＢｏｄｙ要素の追加（３−１３）、Ｈｅａｄｅｒ要素の追加（３−１６）を行う。ＳＯＡＰメッセージ作成処理部４−５は、ユーザＰＣ４−１４のブラウザから入力されたデータを表示処理部４−９を介して受け取り、ＳＯＡＰメッセージの作成を行う。ＷＳＤＬ比較・差分取得処理部４−７はＷＳＤＬの比較・差分取得（３−１１）を行う。
【００４０】
ＵＤＤＩ検索処理部４−８は、ＵＤＤＩレジストリの検索（３−６）を行う。ＷＳＤＬ取得処理部４−１０はＷＳＤＬの取得（３−５）を行う。表示処理部４−９はユーザＰＣ上のブラウザにＷｅｂページの表示を行い、またブラウザからの入力を受け取り、ＳＯＡＰメッセージ作成処理部４−５へと渡す。
【００４１】
次に、Ｗｅｂサービスサーバ４−２０は、メモリ上にＨＴＴＰ通信処理部４−１５、Ｗｅｂサービス処理部４−１６を保持する。ＨＴＴＰ通信処理部４−１５は、ＨＴＴＰに基づき通信を行う。Ｗｅｂサービス処理部４−１６はＷｅｂサービスクライアント４−１１からのＳＯＡＰメッセージを受け取り、Ｗｅｂサービスを提供する。ＵＤＤＩレジストリ４−２１はＤＢ４−１７にＷＳＤＬ保持場所等のＷｅｂサービスに関する情報を保持する。Ｗｅｂサーバ４−２２はＤＢ４−１９にＷＳＤＬの情報を保持する。
【００４２】
以上説明した様に本実施形態のプログラム管理装置によれば、インタフェース定義情報の変更によるエラー発生時にその変更内容に合わせてメッセージを変更してアクセス要求をテスト送信するので、インタフェース定義情報の変更に伴うエラーが発生した場合にそのエラーの発生を防止する為の修正及びテストを動的に行うことが可能である。
（実施形態２）
以下にインタフェース定義情報の変更に応じて変更されたプログラムをテストする実施形態２のプログラム管理装置について説明する。
【００４３】
図５は本実施形態のＷｅｂサービスクライアントによる複数Ｗｅｂサービスへの接続の概要を示す図である。図５の様にＷｅｂサービスクライアントが、ユーザに対して表示する一つのＷｅｂページに対して複数のＷｅｂサービスサーバへのアクセスを含む場合、例えば、ＷｅｂサービスＡの注文に対しては名前、年齢、電話番号が必要で、ＷｅｂサービスＢの注文に対しては名前、電話番号、住所が必要である場合、名前と電話番号のフォームはＷｅｂサービスＡとＷｅｂサービスＢ両方が利用する。
【００４４】
図６は本実施形態のＷｅｂサービスクライアントによる複数Ｗｅｂサービスへの接続時のＷＳＤＬファイルの変更例を示す図である。ここで、まず図６の様にＷｅｂサービスのインタフェースであるＷＳＤＬ１がＷＳＤＬ２に変更された場合に、そのＷＳＤＬの変更に伴ってクライアントプログラムを自動的に修正・変更する場合の問題点について説明する。
【００４５】
上記の様な自動変更を行う場合、まず実施形態１と同様にＦａｕｌｔメッセージからＷＳＤＬの変更を検知し、改訂前のＷＳＤＬ１と改訂後のＷＳＤＬ２の差分を取得すると、ここでは、ＴＥＬタグが削除されることが判る。
【００４６】
そこで、クライアントプログラムの一部のコンポーネントを修正することにより、図７の様に、ＴＥＬフォームを表示するＷｅｂＰａｇｅ上からＴＥＬの部分を削除する。
【００４７】
図７は本実施形態のＷＳＤＬファイルの変更に伴うＷｅｂページの変更例を示す図である。図７の変更例では、ＴＥＬフォームを表示するＷｅｂＰａｇｅ上からＴＥＬの部分が削除されている。
【００４８】
しかし、ＴＥＬフォームはＷｅｂサービスＢも利用している要素であり、ＷｅｂサービスＢの実行時に、エラーとなってしまう（図８）。
【００４９】
図８は本実施形態のＷｅｂページの変更によるエラーの発生例を示す図である。図８に示す様にＷｅｂサービスＢが実行されると、ＴＥＬ要素が無い為、実行時のエラーが発生する。そこで、再度ＷｅｂサービスＢのＷＳＤＬ３を見直してコンポーネントを修正する必要がある。
【００５０】
図９は本実施形態のプログラム管理装置の処理概要を示す図である。図９を用いて上記の問題点を解決する本実施形態の処理概要を説明する。本実施形態ではプログラムを対象として説明するが、オブジェクトに対しても適用可能である。
【００５１】
通常の運用は、Ｗｅｂサービスサーバ９−１とＷｅｂサービスクライアント９−２上のＷｅｂアプリケーション運用処理９−３との間でのＳＯＡＰメッセージ通信によって行われる（９−１０）。なお、図に示したクライアント及びサーバの各装置は、計算機や情報処理装置、またはその様な処理を実施するプログラムやオブジェクトでも良い。
【００５２】
ここで、Ｗｅｂサービスサーバ９−１において、ＷｅｂサービスのインタフェースであるＷＳＤＬが図６の様に変更になった場合、Ｗｅｂサービスクライアント９−２側から送られてきたＳＯＡＰメッセージのインタフェースが現在のインタフェースと異なる為、Ｗｅｂサービスサーバ９−１はＦａｕｌｔメッセージを返す。
【００５３】
Ｗｅｂサービスクライアント９−２側のＷｅｂアプリケーション運用処理９−３がそのＦａｕｌｔメッセージを取得すると、変更検知処理９−４によってＷｅｂサービスサーバ９−１側のインタフェースであるＷＳＤＬの変更を検知し、変更箇所を特定する。
【００５４】
次に、必要コンポーネント変更処理９−５によって、前記特定したＷＳＤＬの変更箇所情報から必要コンポーネントの修正箇所を特定し、修正・変更を行う。
【００５５】
次に、Ｗｅｂアプリケーション生成処理９−６により変更を加えたコンポーネントを含めたＷｅｂアプリケーションのクライアントプログラムを再構築する。
【００５６】
そして、Ｗｅｂアプリケーションテスト処理９−７により、前記生成したＷｅｂアプリケーションを用いてＷｅｂサービスサーバ９−１に対してＳＯＡＰメッセージをテストモードで送付する（９−９）。
【００５７】
ここでの実行時にエラーとなるか、或いはＳＯＡＰメッセージの応答がＦａｕｌｔメッセージだった場合には、再度コンポーネント変更処理部９−５の実行に戻る（９−１１）そして、再度Ｗｅｂアプリケーション生成処理９−６、Ｗｅｂアプリケーションテスト処理９−７を実行し、正常な応答が返ってくれば、Ｗｅｂアプリケーション運用処理９−３の実行に移り、運用を再開する。また、応答が正常でなく、不明なエラーである場合には、管理者へ通知し、運用を停止する。
【００５８】
図１０は本実施形態のクライアントプログラム側の処理の詳細を示す図である。以下、図１０の処理フローを用いて本実施形態のクライアントプログラム側での処理について解説する。
【００５９】
ＷｅｂサービスクライアントがＷｅｂサービスサーバからの応答でＦａｕｌｔメッセージ１０−１を取得すると（１０−２）、まず、Ｆａｕｌｔメッセージの解析（１０−３）を行う。Ｆａｕｌｔメッセージの解析（１０−３）では、Ｆａｕｌｔｃｏｄｅタグの内容がＳＯＡＰ−ＥＮＶ：Ｃｌｉｅｎｔかそれ以外かを調べ、ＳＯＡＰ−ＥＮＶ：ＣｌｉｅｎｔであればＷＳＤＬの取得（１０−５）を行い、ＳＯＡＰ−ＥＮＶ：Ｃｌｉｅｎｔ以外であれば、Ｗｅｂアプリケーションの運用を停止し、ユーザにエラー画面を表示し、管理者へエラー通知を行う（１０−４）。
【００６０】
ＷＳＤＬの取得（１０−５）では、予めクライアントＤＢ１０−１５に保存してあるＷｅｂサービス検索条件を用いてＵＤＤＩレジストリ１０−９でＷｅｂサービスの検索を行い（１０−６）、改訂後ＷＳＤＬの保存場所情報を取得する（１０−７）。ＷＳＤＬの取得（１０−８）では、取得した保存場所情報のＵＲＬにアクセスし、改訂後ＷＳＤＬを取得する。
【００６１】
ＷＳＤＬ比較・差分取得１０−１１では、前記取得した改訂後のＷＳＤＬ２（１０−１０）とクライアントＤＢに保存してある改訂前ＷＳＤＬ１（１０−１４）とを比較し、その差分を取得する。本実施形態の場合、例１０−１２の様な差分を取得する。取得した差分から削除するタグ（ここではＴＥＬ）を判別し、変更・修正を行うコンポーネントを決定し、必要コンポーネントの変更・修正を行う（１０−１３）。
【００６２】
この必要コンポーネントの変更・修正では、例えばＴＥＬフォームをＷｅｂＰａｇｅ上で表示する為のタグの生成を行うコンポーネントと、ＷｅｂサービスサーバへのＳＯＡＰメッセージの生成を行うコンポーネントに対して、図７の様にＴＥＬ部分を削除する様に変更・修正を行う。
【００６３】
統合システム作成１０−１６では、変更・修正したコンポーネントを含む全てのコンポーネントを再コンパイルし、Ｗｅｂアプリケーションを再構築する。
【００６４】
次に、ＳＯＡＰメッセージをテストモードで送付する。これは、以下の様にして実施する。
【００６５】
ＳＯＡＰメッセージのＨｅａｄｅｒにＭｏｄｅタグを追加する（１０−１６）。ここで、Ｍｏｄｅタグの属性をｍｕｓｔＵｎｄｅｒｓｔａｎｄ属性に設定し（１０−１７）、ＷｅｂサービスサーバがＭｏｄｅタグを理解できない場合にはエラーを返す様にする。また、Ｍｏｄｅタグの内容は”ＴＥＳＴ”とする。本実施形態では、Ｗｅｂサービスサーバ側もこのＨｅａｄｅｒを解釈する機能を有しているものとし、Ｍｏｄｅタグの内容が”ＴＥＳＴ”の場合にはテストモードとして動作し、実際の予約や注文といった動作は行わずに、クライアント側から送られてきたＳＯＡＰメッセージが正常な入力かどうかをチェックしてそれに対する応答を返すものとする。
【００６６】
次に、変更したＳＯＡＰメッセージをＷｅｂサービスサーバに送付する（１０−１８）。応答解析１０−１９では、その応答を解析するか、或いは、実行時エラーによりＳＯＡＰメッセージの送付に失敗した場合のエラー解析を行う。
【００６７】
正常な応答が返ってきた場合には、即座に運用を再開する（１０−２２）。実行時エラー、或いはＦａｕｌｔｃｏｄｅがＳＯＡＰ−ＥＮＶ：Ｃｌｉｅｎｔの場合には、再度必要コンポーネントの変更・修正に戻る（１０−２１）。それ以外のエラーの場合には、管理者へエラー内容を通知し、運用を停止する（１０−２０）。
【００６８】
再度必要コンポーネントの変更・修正を行う場合では、例えばＷｅｂＰａｇｅ上で表示する為のタグの生成を行うコンポーネントを修正して前記エラーの発生したＷｅｂサービスＢで必要なＴＥＬ部分が表示される様に変更し、ＷｅｂサービスサーバへのＳＯＡＰメッセージの生成を行うコンポーネントについては、ＷｅｂサービスＢへのＳＯＡＰメッセージのみにＴＥＬ部分が含まれる様に変更する。
【００６９】
図１１は本実施形態のプログラム管理装置のシステム構成を示す図である。以下、図１１及び図１０を用いて、システム構成と各処理についての説明を行う。
【００７０】
Ｗｅｂサービスクライアント１１−１２、Ｗｅｂサービスサーバ１１−２０、ＵＤＤＩレジストリ１１−２１、Ｗｅｂサーバ１１−２２、ユーザＰＣ１１−１４は、ネットワーク１１−２３に接続されたコンピュータである。
【００７１】
本発明はサーバクライアント間の通信手段について特定するものではないが、本実施形態では、インターネット上でのＨＴＴＰによる通信を前提として説明する。すなわち、Ｗｅｂサービスクライアント１１−１２はＨＴＴＰサーバとしての機能を備え、ユーザＰＣ１１−１４からはＷｅｂブラウザ１１−２４を介してＷｅｂサービスクライアント１１−１２と通信を行うものとする。
【００７２】
また、Ｗｅｂサービスサーバ１１−２０はＨＴＴＰサーバとしての機能を備え、Ｗｅｂサービスクライアント１１−１２とＳＯＡＰメッセージを用いて通信を行うものとし、ＵＤＤＩレジストリ１１−２１はＨＴＴＰサーバとしての機能を備え、Ｗｅｂサービスクライアント１１−１２とＳＯＡＰメッセージを用いて通信を行うものとする。
【００７３】
Ｗｅｂサービスクライアント１１−１２は、改訂前と改訂後のＷＳＤＬを有するデータベース１１−６を保持する。また、メモリ上にＨＴＴＰ通信処理部１１−２、ＳＯＡＰ通信処理部１１−３、ＳＯＡＰメッセージ変更処理部１１−４、ＳＯＡＰメッセージ作成処理部１１−５、統合システム作成処理部１１−７、必要コンポーネント変更処理部１１−８、ＷＳＤＬ比較・差分取得処理部１１−９、ＵＤＤＩ検索処理部１１−１０、ＷＳＤＬ取得処理部１１−１１、Ｆａｕｌｔ取得・解析処理部１１−１、表示処理部１１−１３を保持する。
【００７４】
Ｗｅｂサービスクライアント１１−１２を、前記各処理部として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する記録媒体はＣＤ−ＲＯＭ以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体から情報処理装置にインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。
【００７５】
ＨＴＴＰ通信処理部１１−２は、ＨＴＴＰに基づき通信を行う。ＳＯＡＰ通信処理部１１−３は、テストモードを含むＳＯＡＰメッセージの送受信を行う（１０−１７）。Ｆａｕｌｔ取得・解析処理部１１−１は、Ｆａｕｌｔの取得（１０−２）及びＦａｕｌｔの解析（１０−３）を行う。ＳＯＡＰメッセージ変更処理部１１−４は、Ｈｅａｄｅｒ要素の追加（１０−１７）を行う。ＳＯＡＰメッセージ作成処理部１１−５は、ユーザＰＣ１１−１４のブラウザから入力されたデータを、表示処理部１１−１３を介して受け取り、ＳＯＡＰメッセージの作成を行う。
【００７６】
統合システム作成処理部１１−１７は、全コンポーネントの再コンパイル、Ｗｅｂアプリケーションの再構築を行う（１０−１６）。必要コンポーネント変更処理部１１−８は、必要コンポーネントの変更・修正（１０−１３）を行う。ＷＳＤＬ比較・差分取得処理部１１−９は、ＷＳＤＬの比較・差分取得（１０−１１）を行う。
【００７７】
ＵＤＤＩ検索処理部１１−１０は、ＵＤＤＩレジストリの検索（１０−６）を行う。ＷＳＤＬの取得処理部１１−１１は、ＷＳＤＬの取得（１０−５）を行う。表示処理部１１−１３はユーザＰＣ上のブラウザにＷｅｂページの表示を行い、またブラウザからの入力を受け取り、ＳＯＡＰメッセージ作成処理部１１−５へと渡す。
【００７８】
次に、Ｗｅｂサービスサーバ１１−２０は、メモリ上にＨＴＴＰ通信処理部１１−１５、Ｗｅｂサービス処理部１１−１６を保持する。ＨＴＴＰ通信処理部１１−１５は、ＨＴＴＰに基づき通信を行う。Ｗｅｂサービス処理部１１−１６はＷｅｂサービスクライアント１１−１２からのＳＯＡＰメッセージを受け取り、Ｗｅｂサービスを提供する。ＵＤＤＩレジストリ１１−２１はクライアントＤＢ１１−１７にＷＳＤＬ保持場所等のＷｅｂサービスに関する情報を保持する。Ｗｅｂサーバ１１−２２はＤＢ１１−１９にＷＳＤＬの情報を保持する。
【００７９】
以上説明した様に本実施形態のプログラム管理装置によれば、インタフェース定義情報の変更によるエラー発生時にその変更内容に合わせてプログラムを変更してアクセス要求をテスト送信するので、インタフェース定義情報の変更に伴うエラーが発生した場合にそのエラーの発生を防止する為の修正及びテストを動的に行うことが可能である。
【００８０】
【発明の効果】
本発明によれば、インタフェース定義情報の変更に伴うエラーが発生した場合にそのエラーの発生を防止する為の修正及びテストを動的に行うことが可能である。
【図面の簡単な説明】
【図１】実施形態１のＷＳＤＬファイルの変更例を示す図である。
【図２】実施形態１のプログラム管理装置の処理概要を示す図である。
【図３】実施形態１のクライアントプログラム側の処理の詳細を示す図である。
【図４】実施形態１のプログラム管理装置のシステム構成を示す図である。
【図５】実施形態２のＷｅｂサービスクライアントによる複数Ｗｅｂサービスへの接続の概要を示す図である。
【図６】実施形態２のＷｅｂサービスクライアントによる複数Ｗｅｂサービスへの接続時のＷＳＤＬファイルの変更例を示す図である。
【図７】実施形態２のＷＳＤＬファイルの変更に伴うＷｅｂページの変更例を示す図である。
【図８】実施形態２のＷｅｂページの変更によるエラーの発生例を示す図である。
【図９】実施形態２のプログラム管理装置の処理概要を示す図である。
【図１０】実施形態２のクライアントプログラム側の処理の詳細を示す図である。
【図１１】実施形態２のプログラム管理装置のシステム構成を示す図である。
【符号の説明】
１−１…ＷＳＤＬファイル、１−２…ＮＡＭＥタグ、１−３…ＡＧＥタグ、１−４…ＷＳＤＬファイル、１−５…ＮＡＭＥタグ、１−６…ＡＧＥタグ、１−７…ＴＥＬタグ、１−８…追加行、２−１…Ｗｅｂサービスサーバ、２−２…通常運用時通信、２−３…テストモード通信、２−４…Ｗｅｂサービスクライアント、２−５…ネットワーク、２−６…Ｗｅｂアプリケーション運用処理、２−７…変更検知処理、２−８…Ｗｅｂアプリケーションテスト処理、３−９…ＵＤＤＩレジストリ、３−１０…改訂後ＷＳＤＬファイル、３−１２…差分例、３−１４…改訂前ＷＳＤＬファイル、３−１５…クライアントＤＢ、３−２１…ＳＯＡＰメッセージ、４−１…Ｆａｕｌｔ取得・解析処理部、４−２…ＨＴＴＰ通信処理部、４−３…ＳＯＡＰ通信処理部、４−４…ＳＯＡＰメッセージ変更処理部、４−５…ＳＯＡＰメッセージ作成処理部、４−６…ＷＳＤＬデータベース、４−７…ＷＳＤＬ比較・差分取得処理部、４−８…ＵＤＤＩ検索処理部、４−９…表示処理部、４−１０…ＷＳＤＬ取得処理部、４−１１…Ｗｅｂサービスクライアント、４−１２…ネットワーク、４−１３…ブラウザ、４−１４…ユーザＰＣ、４−１５…ＨＴＴＰ通信処理部、４−１６…Ｗｅｂサービス処理部、４−１７…ＤＢ、４−１８…ＷＳＤＬファイル、４−１９…ＤＢ、４−２０…Ｗｅｂサービスサーバ、４−２１…ＵＤＤＩレジストリ、４−２２…Ｗｅｂサーバ、９−１…Ｗｅｂサービスサーバ、９−２…Ｗｅｂサービスクライアント、９−３…Ｗｅｂアプリケーション運用処理、９−４…変更検知処理、９−５…必要コンポーネント変更処理、９−６…Ｗｅｂアプリケーション生成処理、９−７…Ｗｅｂアプリケーションテスト処理、１０−９…ＵＤＤＩレジストリ、１０−１０…改訂後ＷＳＤＬファイル、１０−１２…差分例、１０−１４…改訂前ＷＳＤＬファイル、１０−１５…クライアントＤＢ、１１−１…Ｆａｕｌｔ取得・解析処理部、１１−２…ＨＴＴＰ通信処理部、１１−３…ＳＯＡＰ通信処理部、１１−４…ＳＯＡＰメッセージ変更処理部、１１−５…ＳＯＡＰメッセージ作成処理部、１１−６…ＷＳＤＬデータベース、１１−７…統合システム作成処理部、１１−８…必要コンポーネント変更処理部、１１−９…ＷＳＤＬ比較・差分取得処理部、１１−１０…ＵＤＤＩ検索処理部、１１−１１…ＷＳＤＬ取得処理部、１１−１２…Ｗｅｂサービスクライアント、１１−１３…表示処理部、１１−１４…ユーザＰＣ、１１−１５…ＨＴＴＰ通信処理部、１１−１６…Ｗｅｂサービス処理部、１１−１７…ＤＢ、１１−１８…ＷＳＤＬファイル、１１−１９…ＤＢ、１１−２０…Ｗｅｂサービスサーバ、１１−２１…ＵＤＤＩレジストリ、１１−２２…Ｗｅｂサーバ、１１−２３…ネットワーク、１１−２４…ブラウザ。
【図１】
2004362051.tif 000003
【図２】
2004362051.tif 000004
【図３】
2004362051.tif 000005
【図４】
2004362051.tif 000006
【図５】
2004362051.tif 000007
【図６】
2004362051.tif 000008
【図７】
2004362051.tif 000009
【図８】
2004362051.tif 000010
【図９】
2004362051.tif 000011
【図１０】
2004362051.tif 000012
【図１１】
2004362051.tif 000013