(57)【要約】【課題】クライアントアプリケーションとネットワークサービスとの間におけるコンテントネゴシエーションにおいて、データ構造に係る連携機能を備えることによって、操作性に優れたネットワーク環境を提供する。【解決手段】クライアントアプリケーション１が指定した複数のスキーマとネットワークサービス２が使用するスキーマとを取得し、内容を解析して、クライアントアプリケーション１が指定した複数のスキーマの中からネットワークサービス２が使用するスキーマとの親和性が高い１つのスキーマを選択するスキーマネゴシエーション機能部１４と、サービス呼び出しによりネットワークサービス２から受信したレスポンスについてスキーマネゴシエーション機能部１４が選択したスキーマをもとにサービス変換を行うサービス変換機能部１２とを具備する。【選択図】    図１
2011130374.tif 000002
【特許請求の範囲】
【請求項１】
クライアントアプリケーションとネットワークサービスとの間のネゴシエーションを仲介するサービスネゴシエーション装置であって、
前記クライアントアプリケーションとネゴシエーションを行うクライアントネゴシエーション機能部と、
前記クライアントネゴシエーション機能部が前記クライアントアプリケーションから受信したリクエストに対して前記ネットワークサービスにサービス呼び出しを行うサービス呼び出し機能部と、
前記クライアントアプリケーションが指定した複数のスキーマと前記ネットワークサービスが使用するスキーマとを取得し、内容を解析して、前記クライアントアプリケーションが指定した複数のスキーマの中から前記ネットワークサービスが使用するスキーマとの親和性が高い１つのスキーマを選択するスキーマネゴシエーション機能部と、
前記サービス呼び出しにより前記ネットワークサービスから受信したレスポンスについて前記スキーマネゴシエーション機能部が選択したスキーマをもとにサービス変換を行うサービス変換機能部と
を具備したことを特徴とするサービスネゴシエーション装置。
【請求項２】
前記クライアントネゴシエーション機能部は、前記レスポンスについて前記サービス変換を必要とするか否かを判定する判定手段と、前記取得したスキーマについてデータ構造の定義内容を解析する解析手段とを具備し、前記判定手段が前記サービス変換を必要とする判定をとしたとき、前記解析手段を用いて前記各スキーマについて前記解析を行うことを特徴とする請求項１に記載のサービスネゴシエーション装置。
【請求項３】
前記クライアントネゴシエーション機能部は、前記取得したスキーマについて、前記解析手段を用いて、字句の解析と意味クラスの解析を行い、この解析結果の内容をもとに対応付け定義ファイルを生成し、前記対応付け定義ファイルを参照して前記取得した複数のスキーマの中から、前記レスポンスのスキーマに対して適合率の最も高いスキーマを判定し、１つのスキーマを選択するスキーマ選択処理手段を具備することを特徴とする請求項２に記載のサービスネゴシエーション装置。
【請求項４】
クライアントアプリケーションとネットワークサービスとの間を連携するサービスネゴシエーション装置としてコンピュータを機能させるためのサービスネゴシエーションプログラムであって、
前記クライアントアプリケーションとの間でネゴシエーションを行うクライアントネゴシエーション機能と、
前記クライアントネゴシエーション機能が前記クライアントアプリケーションから受信したリクエストに対して前記ネットワークサービスにサービス呼び出しを行うサービス呼び出し機能と、
前記クライアントアプリケーションが指定した複数のスキーマと前記ネットワークサービスが使用するスキーマとを取得し、内容を解析して、前記クライアントアプリケーションが指定した複数のスキーマの中から前記ネットワークサービスが使用するスキーマとの親和性が高い１つのスキーマを選択するスキーマネゴシエーション機能と、
前記サービス呼び出しにより前記ネットワークサービスから受信したレスポンスについて前記スキーマネゴシエーション機能部が選択したスキーマをもとにサービス変換を行うサービス変換機能と
をコンピュータに実現させるためのサービスネゴシエーションプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク環境において、クライアントアプリケーションとネットワークサービスとの間を連携するサービスネゴシエーション装置およびサービスネゴシエーションプログラムに関する。
【背景技術】
【０００２】
クライアントアプリケーションとネットワークサービスとの間におけるコンテントネゴシエーションは、クライアントアプリケーションがネットワークサービスに対して利用するメディアタイプや言語などを指定したリクエストをネットワークを介し送信し、ネットワークサービスが受信したリクエストに応じて、適切なメディアタイプ（例えばｔｅｘｔ／ｈｔｍｌ、ｔｅｘｔ／ｘｍｌ）や言語のデータをクライアントに提供している。
【０００３】
このようにコンテントネゴシエーションは、クライアントアプリケーションからのリクエストに応じて最適なドキュメントを判断し、レスポンスを返す仕組みを実現するが、データの構造についてのネゴシエーションができないという問題があった。クライアントアプリケーションとネットワークサービスの連携において、互いに使用するデータ構造が異なるケースは多く、従来では、その都度、人手による変換やマッピングなどの作業が介在していた。
【０００４】
この種のコンテントネゴシエーション技術として、電子商取引環境におけるデジタルアイテムアダプテーション記述ネゴシエーション機能をもつマルチメディア配信ネットワークが存在した（特許文献１）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００４−２６６６１５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上述したように従来のコンテントネゴシエーションは、クライアントアプリケーションからのリクエストに応じ最適なドキュメントを判断してレスポンスを返す仕組みを実現するが、データの構造についてのネゴシエーションができないことから操作性に問題があった。
【０００７】
また、特許文献１に記載の技術については、MPEG-21仕様の中に決められたDIA記述メッセージ（DIADM）を利用して、ユーザ特有の設定についてネゴシエーションを行うという発明である。つまり、データ構造がすでにMPEG-21によって決められて、それを利用してネゴシエーションを行なうという発明である。それに対して、本発明は、特にデータ構造を決めずに、データ構造自身についてネゴシエーションを行い、ダイナミック（動的）にサーバとクライアントをつなぐものであり、特許文献１に記載の技術とは異なったものになっている。
【０００８】
本発明は上記実情に鑑みなされたもので、クライアントアプリケーションとネットワークサービスとの間におけるコンテントネゴシエーションにおいて、データ構造に係る連携機能を有するシステムの構築を可能にし、これによって操作性に優れたネットワーク環境を実現可能にしたサービスネゴシエーション装置およびサービスネゴシエーションプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明は、クライアントアプリケーションとネットワークサービスとの間のネゴシエーションを仲介するサービスネゴシエーション装置であって、前記クライアントアプリケーションとネゴシエーションを行うクライアントネゴシエーション機能部と、前記クライアントネゴシエーション機能部が前記クライアントアプリケーションから受信したリクエストに対して前記ネットワークサービスにサービス呼び出しを行うサービス呼び出し機能部と、前記クライアントアプリケーションが指定した複数のスキーマと前記ネットワークサービスが使用するスキーマとを取得し、内容を解析して、前記クライアントアプリケーションが指定した複数のスキーマの中から前記ネットワークサービスが使用するスキーマとの親和性が高い１つのスキーマを選択するスキーマネゴシエーション機能部と、前記サービス呼び出しにより前記ネットワークサービスから受信したレスポンスについて前記スキーマネゴシエーション機能部が選択したスキーマをもとにサービス変換を行うサービス変換機能部とを具備したことを特徴とする。
【００１０】
また、本発明は、クライアントアプリケーションとネットワークサービスとの間を連携するサービスネゴシエーション装置としてコンピュータを機能させるためのサービスネゴシエーションプログラムであって、前記クライアントアプリケーションとの間でネゴシエーションを行うクライアントネゴシエーション機能と、前記クライアントネゴシエーション機能が前記クライアントアプリケーションから受信したリクエストに対して前記ネットワークサービスにサービス呼び出しを行うサービス呼び出し機能と、前記クライアントアプリケーションが指定した複数のスキーマと前記ネットワークサービスが使用するスキーマとを取得し、内容を解析して、前記クライアントアプリケーションが指定した複数のスキーマの中から前記ネットワークサービスが使用するスキーマとの親和性が高い１つのスキーマを選択するスキーマネゴシエーション機能と、前記サービス呼び出しにより前記ネットワークサービスから受信したレスポンスについて前記スキーマネゴシエーション機能部が選択したスキーマをもとにサービス変換を行うサービス変換機能とをコンピュータに実現させることを特徴とする。
【発明の効果】
【００１１】
本発明によれば、クライアントアプリケーションとネットワークサービスとの間におけるコンテントネゴシエーションにおいて、データ構造に係る連携機能を備えたことにより、操作性に優れたネットワーク環境を提供できる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施形態に係るサービスネゴシエーション装置の構成を示すブロック図。
【図２】上記実施形態に係るサービスネゴシエーション装置のデータ構造に係る連携処理の概要を示す図。
【図３】上記実施形態に係るサービスネゴシエーション装置のデータ構造に係る連携動作を説明するための機能構成図。
【図４】上記実施形態に係るサービスネゴシエーション装置のデータ構造に係る連携動作を説明するためのフローチャート。
【図５】上記実施形態に係るサービスネゴシエーション装置のデータ構造に係る連携動作を説明するための図。
【図６】上記実施形態に係るサービスネゴシエーション装置のデータ構造に係る連携動作を説明するための図。
【図７】上記実施形態に係るサービスネゴシエーション装置のデータ構造に係る連携動作を説明するための図。
【図８】上記実施形態に係るサービスネゴシエーション装置のデータ構造に係る連携動作を説明するための図。
【図９】上記実施形態に係るサービスネゴシエーション装置のデータ構造に係る連携動作を説明するための図。
【図１０】上記実施形態に係るサービスネゴシエーション装置のデータ構造に係る連携動作を説明するための図。
【図１１】上記実施形態に係るサービスネゴシエーション装置のデータ構造に係る連携動作を説明するための図。
【発明を実施するための形態】
【００１３】
本発明の実施形態を説明するに際し、本発明の概要を図１および図２を参照して説明する。
【００１４】
本発明の実施形態に係るサービスネゴシエーション装置は、図１に示すように、クライアントアプリケーション（Client）１とネゴシエーションを行うクライアントネゴシエーション機能部１１と、クライアントネゴシエーション機能部１１がクライアントアプリケーション１から受信したリクエストに対してネットワークサービス（Service）２にサービス呼び出しを行うサービス呼び出し機能部１３と、クライアントアプリケーション１が指定した複数のスキーマとネットワークサービス２が使用するスキーマとを取得し、内容を解析して、クライアントアプリケーション１が指定した複数のスキーマの中からネットワークサービス２が使用するスキーマとの親和性が高い１つのスキーマを選択するスキーマネゴシエーション機能部１４と、サービス呼び出しによりネットワークサービス２から受信したレスポンスについてスキーマネゴシエーション機能部１４が選択したスキーマをもとにサービス変換を行う（サービスの結果をクライアントアプリケーション側に適合するデータ構造に変換する）サービス変換機能部１２とを具備して構成される。
【００１５】
上記したサービスネゴシエーション装置１０をクライアントアプリケーション１とネットワークサービス２との間に設けることにより、クライアントアプリケーション１と、クライアントアプリケーション１が利用するネットワークサービス２との間で、互いに使用するデータ構造について自動的に連携する機構を提供することができる。例えば、図２に示すように、クライアントアプリケーション１が指定したデータ構造（Ｓｃｈｅｍａ  Ａ）について、ネットワークサービス２側が対応していなくても、サービスネゴシエーション装置１０において自動的に対応付けを行い、クライアントが指定したデータ構造に変換した形でクライアントアプリケーション１にデータを提供することができる。
【００１６】
これにより、クライアントアプリケーション１とネットワークサービス２の連携において、互いに使用するデータ構造が異なる場合であっても、人手による変換やマッピングなどの作業を必要とせず、操作性に優れたコンテントネゴシエーションによるネットワーク環境を提供することができる。
【００１７】
以下に、図面を参照して本発明の実施形態をより詳細に説明する。  
図１および図３に示すように、本発明の実施形態に係るサービスネゴシエーション装置１０は、クライアントネゴシエーション機能部１１と、サービス変換機能部１２と、サービス呼び出し機能部１３と、スキーマネゴシエーション機能部１４と、字句解析、意味クラス解析ツール１５を具備して構成される。
【００１８】
クライアントネゴシエーション機能部１１は、クライアントアプリケーション１とネゴシエーションを行う処理機能を具備するもので、この実施形態では、クライアントアプリケーション１の指定により、他の機能部を呼び出し、処理を委譲するフロントコントローラの役割を果たす。
【００１９】
サービス変換機能部１２は、サービス呼び出しにより得られたサービスの結果（レスポンス）を、スキーマネゴシエーション機能部１４の出力（選択したスキーマ）に従い、クライアントアプリケーション側に適合するデータ構造に変換する処理機能を有する。
【００２０】
サービス呼び出し機能部１３は、クライアントネゴシエーション機能部１１が受信したクライアントアプリケーション１からの要求（リクエスト）に従い、ネットワークサービス２にサービスの呼び出しを行う処理機能を有する。
【００２１】
スキーマネゴシエーション機能部１４は、クライアントアプリケーション１とネットワークサービス２がそれぞれ使用するデータ構造について、ネゴシエーションを行う処理機能を具備するもので、具体的にはデータ構造（スキーマ）の設計情報（テキスト情報）を利用して、意味クラス解析を行い、意味の近いもの同士について対応付けを行う処理機能を有する。
【００２２】
このスキーマネゴシエーション機能部１４は、スキーマ読み込み機能部１４１と、スキーマ対応付け機能部１４２と、スキーマ対応付け出力機能部１４３とを具備して構成される。
【００２３】
スキーマ読み込み機能部１４１は、クライアントアプリケーション１とネットワークサービス２が使用するデータ構造の定義（スキーマ）を図示しないネットワークを経由して取得する処理機能を有する。
【００２４】
スキーマ対応付け機能部１４２は、字句解析、意味クラス解析ツール１５を利用して、クライアントアプリケーション１が指定した複数のスキーマとネットワークサービス２が使用するスキーマの設計情報を解析し、クライアントアプリケーション１とネットワークサービスのデータ構造の対応付けを行う処理機能を有する。
【００２５】
スキーマ対応付け出力機能部１４３は、スキーマ対応付け機能部１４２で行ったスキーマの対応付けを、対応付け定義ファイルという形として出力する処理機能を有する。この定義ファイルに従って、サービス変換機能部１２がサービスの結果（レスポンス）についてデータ構造の変換を行う。
【００２６】
字句解析、意味クラス解析ツール１５は、スキーマ対応付け機能部１４２によるデータ構造の解析処理に供されるもので、字句解析、意味クラス解析処理部１５１と、字句解析、意味クラス解析用辞書１５２とを具備して構成される。この字句解析、意味クラス解析ツール１５は、スキーマの内容について字句および意味クラスの解析を行う（一例を後述する）もので、既存の技術を利用して実現される。
【００２７】
ここで図３および図４を参照して本発明の実施形態における処理動作を説明する。また、図５乃至図１１を参照してデータ構造に係る連携動作の具体例を説明する。
【００２８】
図３において、クライアントアプリケーション（Ｃｌｉｅｎｔ  Ａ）１とクライアントアプリケーション（Ｃｌｉｅｎｔ  Ｂ）１、およびネットワークサービス２がそれぞれ内部で異なるデータ構造（スキーマ）を使用しているものとする。この図３および図４に示すフローチャートを参照して処理の流れを説明する。
【００２９】
図４に示すステップＳ１において、クライアントアプリケーション１は、サービスネゴシエーション装置１０に、ネゴシエーション要求（サービス要求）を送信する。
【００３０】
ステップＳ２において、サービスネゴシエーション装置１０（クライアントネゴシエーション機能部１１）は、受け取ったリクエスト（ネゴシエーション要求）を、サービス呼び出し機能（サービス呼び出し機能部１３の処理機能）を利用して、ネットワークサービス２へ送信する。
【００３１】
ステップＳ３において、ネットワークサービス２は、サービスネゴシエーション装置１０から受信したネゴシエーション要求（リクエスト）に対して、ネゴシエーション回答（レスポンス）を返信する。
【００３２】
サービスネゴシエーション装置１０は、ネットワークサービス２から受信した回答について、スキーマネゴシエーションの必要性（サービス変換を必要とするか否か）を判断する。
【００３３】
ここで、スキーマネゴシエーションの必要ありと判断した場合は、ステップＳ４以降の処理（処理Ａ）を実行し、スキーマネゴシエーションの必要なしと判断した場合は、ステップＳ１４以降の処理（処理Ｂ）を実行する。
【００３４】
処理Ａ
ステップＳ４，Ｓ５において、サービスネゴシエーション装置１０は、スキーマ読み込み機能（スキーマ読み込み機能部１４１の処理機能）を利用して、ネットワークサービス２のスキーマを取得する。
【００３５】
ステップＳ６，Ｓ７において、サービスネゴシエーション装置１０は、スキーマ読み込み機能（スキーマ読み込み機能部１４１の処理機能）を利用して、クライアントアプリケーション１が指定した複数のスキーマを取得する。
【００３６】
ステップＳ８において、サービスネゴシエーション装置１０は、スキーマ対応付け機能（スキーマ対応付け機能部１４２の処理機能）を用いて、クライアントアプリケーション１から取得したスキーマとネットワークサービス２から取得したサービススキーマの対応付けを行う。この対応付けでは、スキーマ対応付け機能部１４２が字句解析、意味クラス解析ツール１５を用いて、スキーマの設計情報（テキスト情報）を、字句解析、意味クラス解析し、意味の同じまたは近いものについての対応付けを行う。この対応付けの具体例については後述する。
【００３７】
ステップＳ９において、サービスネゴシエーション装置１０は、以上の対応付けの結果を、対応付け定義ファイルとして出力する。
【００３８】
ステップＳ１０，Ｓ１１において、サービスネゴシエーション装置１０は、サービス呼び出し機能（サービス呼出機能部１３の処理機能）を利用して、ネットワークサービス２からサービス結果を受け取る。
【００３９】
ステップＳ１２において、サービスネゴシエーション装置１０は、サービス変換機能（サービス変換機能部１２の処理機能）を用いて、上記対応付け定義ファイルに従い、サービス結果を変換する。
【００４０】
ステップＳ１３において、サービスネゴシエーション装置１０は、変換したサービス結果をクライアントアプリケーションに返信する。
【００４１】
処理Ｂ
ステップＳ１４，Ｓ１５において、サービスネゴシエーション装置１０は、サービス呼び出し機能（サービス呼出機能部１３の処理機能）を利用して、ネットワークサービス２からサービス結果を受け取る。
【００４２】
ステップＳ１６において、サービス結果（レスポンス）をクライアントアプリケーション１に返信する。
【００４３】
以上がサービスネゴシエーション装置１０による処理の手順である。
【００４４】
以下に、図５乃至図１１を参照してデータ構造に係る連携動作の具体例を説明する。
【００４５】
・サービスネゴシエーションについて
サービスネゴシエーションは、通常のＨＴＴＰコンテントネゴシエーションの仕組みを拡張して実現することが可能である。
【００４６】
図５に、ネゴシエーション要求の一例を示す。この例では、クライアントアプリケーションが、自分が処理できるデータ構造（スキーマ）として、「Ａｃｃｅｐｔ−Ｓｃｈｅｍａｓ」ＨＴＴＰ拡張ヘッダーを利用して、ａ．ｘｓｄとｂ．ｘｓｄの二つを指定している。
【００４７】
図６に、ネゴシエーション回答の例を示す。この例では、クライアントが指定したデータ構造に対応できないため、ステータスコード「４０６  Ｎｏｔ  Ａｃｃｅｐｔａｂｌｅ」を返すと同時に、「Ａｌｔｅｒｎａｔｅ−Ｓｃｈｅｍａｓ」拡張ヘッダーを利用して、代わりにｓ．ｘｓｄをクライアントに提案している。
【００４８】
サービスネゴシエーション装置１０は、以上の回答を見て、クライアントアプリケーション１が指定する「ａ．ｘｓｄ」、［ｂ．ｘｓｄ］とネットワークサービス２側が提案する「ｓ．ｘｓｄ」の対応付けを行うことになる。
【００４９】
また、クライアントアプリケーション１は、指定した複数のスキーマに対して図７に示すように優先順位をすることもできる。図７に示す例では、ｂ．ｘｓｄよりａ．ｘｓｄが優先されることになる。
【００５０】
・スキーマの対応付けについて
サービスネゴシエーションでは、スキーマ定義の設計情報に対して字句解析、意味クラス解析を行い、スキーマの要素間の対応付けを行う。図８および図９に、Ｗ３Ｃ  ＸＭＬ  Ｓｃｈｅｍａにより、設計情報を記述する例を示す。
【００５１】
図８および図９に示す二つのスキーマでは、同じ行の日程を表すのに、それぞれ「Ｓｃｈｅｄｕｌｅ」と「Ｎｉｔｔｅｉ」という二つの異なる要素を用いる。通常の場合は、その二つの要素は異なるものと見做され、対応付けすることができない。そこで、要素の設計情報（ｘｓｄ：ａｎｎｏｔａｔｉｏｎ）に書かれたテキスト情報に対して字句解析と意味クラス解析を用いて、「スケジュール」と「日程」の二つの単語の意味が同じであることが分かり、「Ｓｃｈｅｄｕｌｅ」と「Ｎｉｔｔｅｉ」が同じ意味を持つ要素であることを判断できるようになる。以下に用いる意味クラスの例を示す。図１０に示す例では、「旅程」、「日程」、「スケジュール」は、すべて同じ「Ｓｃｈｅｄｕｌｅ」クラスに属するため、同じ意味を持つものだと判断可能になる。なお、字句解析、意味クラス解析には、既存の技術を利用している。
【００５２】
・スキーマ対応付けの出力について
上述したようにスキーマの対応付けの結果として、対応付け定義ファイルが出力される。対応付け定義ファイルには、例えばＸＳＬＴ変換スタイルシートを用いることが可能である。図１１に、Ｎｉｔｔｅｉ要素をＳｃｈｅｄｕｌｅ要素に変換するスタイルシートの例を示す。
【００５３】
・スキーマ適合率の計算
クライアントアプリケーションが複数スキーマを指定することが可能なため、サービスネゴシエーション装置１０では、それぞれのネットワークサービススキーマとの適合率を計算し、適合率の高いほうのスキーマにデータを変換して、クライアントアプリケーションに提供する。
【００５４】
スキーマ適合率の計算方法として、例えば、スキーマのすべての要素に対して対応付けを行う際、対応付けできる要素と対応付けできない要素が必ず存在する。その割合を、適合率として利用することが可能である。
【００５５】
クライアントアプリケーション１がスキーマに対して優先順位を指定した場合、適合率よりも優先順位で処理を行う。なお、優先順位が低く、適合率が高いものに対しては、サービスネゴシエーション装置とクライアントアプリケーション間で、再びネゴシエーションを行って決めることも可能であり、実装依存になる。
【００５６】
また、例えば適合率が３０％に満たない場合、「４０６  Ｎｏｔ  Ａｃｃｅｐｔａｂｌｅ」を返すようにするか、それとも満たない場合でもネットワークサービスデータを変換して提供するかは、ＳＬＡ（Ｓｅｒｖｉｃｅ  Ｌｅｖｅｌ  Ａｇｒｅｅｍｅｎｔ）に依存すると考えられる。
【００５７】
上記したように、本発明の実施形態に係るサービスネゴシエーション装置１０によれば、サービスネゴシエーションにより、クライアントアプリケーションが自動認識可能なデータ構造を持つデータを、ネットワークサービスから取得することできるため、ネットワークサービスと自動連携することが可能になる。また、ネットワークサービスとクライアントアプリケーションが互いに影響を及ぼさずに独立することができる。さらに、ネットワークサービスが複数の異なるクライアントアプリケーションのために、複数のデータ構造を持つデータを予め用意する必要がなく、クライアントアプリケーションも同様に、利用するサービスが増えたとしても、それぞれに追従する必要がなくなる（ただしサービスネゴシエーションの仕組み、例えば利用するＨＴＴＰ拡張ヘッダーなどには対応する必要がある）。
【００５８】
なお、本発明は、上記実施の形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できるものである。例えば、上記した実施形態では、ネゴシエーション要求（リクエスト）の都度、クライアントアプリケーション１とネットワークサービス２のそれぞれからスキーマ（Ｓｃｈｅｍａ）を取得したが、これに限らず、構築するネットワークシステム、サービス内容等によって、ネットワークサービス２が扱う情報のスキーマ、クライアントアプリケーション１が扱う情報のスキーマについて、任意のスキーマを予めスキーマネゴシエーション機能部１４に登録しておくことも可能である。また上記実施形態に記載した処理機能は、コンピュータに実行させることのできるプログラムとして、磁気ディスク、光ディスク、光磁気ディスク、半導体メモリなどの記憶媒体に格納して頒布する、またはダウンロードして頒布することも可能である。
【符号の説明】
【００５９】
１…クライアントアプリケーション、２…ネットワークサービス、１０…サービスネゴシエーション装置、１１…クライアントネゴシエーション機能部、１２…サービス変換機能部、１３…サービス呼び出し機能部、１４…スキーマネゴシエーション機能部、１５…字句解析、意味クラス解析ツール、１４１…スキーマ読み込み機能部、１４２…スキーマ対応付け機能部、１４３…スキーマ対応付け出力機能部、１５１…字句解析、意味クラス解析処理部、１５２…字句解析、意味クラス解析用辞書。
【図１】
2011130374.tif 000003
【図２】
2011130374.tif 000004
【図３】
2011130374.tif 000005
【図４】
2011130374.tif 000006
【図５】
2011130374.tif 000007
【図６】
2011130374.tif 000008
【図７】
2011130374.tif 000009
【図８】
2011130374.tif 000010
【図９】
2011130374.tif 000011
【図１０】
2011130374.tif 000012
【図１１】
2011130374.tif 000013