JP5031772B2 - サービス作成方法、該方法を実装するコンピュータプログラム製品およびコンピュータシステム - Google Patents

Description

本発明は、サービス作成方法、ならびにその方法を実装するコンピュータプログラム製品およびコンピュータシステムに関する。

この記述では、次の用語は、特に指定のない限り次に示す意味で使用される。
−「ＵＤＤＩレジストリ」は、「Ｕｎｉｖｅｒｓａｌ Ｄｅｓｃｒｉｐｔｉｏｎ Ｄｉｓｃｏｖｅｒｙ ａｎｄ Ｉｎｔｅｇｒａｔｉｏｎ」の略であり、ＸＭＬベースのレジストリ、より詳細には特にＳＯＡアーキテクチャ（「Ｓｅｒｖｉｃｅ−Ｏｒｉｅｎｔｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅｓ、サービス指向アーキテクチャ」の略）内のウェブサービス専用のレジストリのことを指す。一定のサービスプロバイダの特定のレジストリと同様に、プライベートレジストリおよびパブリックレジストリの両方が存在する。ＵＤＤＩレジストリにより、ネットワーク上で検索されるＷｅｂサービスの位置を突きとめることが可能になる。詳細には、ＵＤＤＩレジストリは、Ｗｅｂサービスにアクセスするための情報と、サービスおよびその機能の簡単な記述などの文脈情報とを含む。ＵＤＤＩレジストリは、詳細には、
−ビジネス関連情報を含むホワイトページと、
−ＷＳＤＬ標準を使用してこれらビジネスのＷｅｂサービスを列挙するイエローページと、
−提供されるサービスの特定の技術情報を提供するグリーンページと、を含む。この技術情報は、特に関連するサービス、リンク、またはビジネスプロセスの記述に関する。
−「コンピュータアプリケーション」は、ユーザにサービスを提供することが目的である任意のプログラムまたは合わせて動作するように意図された任意のプログラムのセットのことを指す。
−「ＢＰＥＬ」は、「Ｂｕｓｉｎｅｓｓ Ｐｒｏｃｅｓｓ Ｅｘｅｃｕｔｉｏｎ Ｌａｎｇｕａｇｅ」の略であり、対話ロジックおよび対話プロトコルロジックの正式の表記に使用されるＸＭＬ言語であり、これはＷｅｂサービスの対話モデルの意味論を拡大する。Ｗｅｂサービス間の対話に加えて、ＢＰＥＬはアプリケーションロジックおよび対話の順序を記述する。
−「組立て（ｃｏｍｐｏｓｉｔｉｏｎ）」は、Ｗｅｂサービスという状況で、新しい別個のＷｅｂサービスとして動作することができるサービスの集まりを指す。組み立てられたサービスにより実行されるプロセスの順序付けに重点を置く「編成（ｏｒｃｈｅｓｔｒａｔｉｏｎ）」による組立てと、サービスの順序付けが、交換されるメッセージおよび組み立てられたサービスによるイベントの検討に基づく「振付け（ｃｈｏｒｅｏｇｒａｐｈｙ）」による組立てとの間で区別が行われる。
−「入力パラメータ」は、Ｗｅｂサービスの処理動作に入力として提供されるデータのことを指し、この動作の入力データは、この動作によって変換されて出力結果を提供する。
−「出力結果」は、入力データ（すなわち「パラメータ」）上でＷｅｂサービスの動作により実行された処理の結果生じる情報のことを指す。この出力結果が、Ｗｅｂサービスのユーザにより要求される製品であり、該ユーザは、場合によってはコンピュータアプリケーションまたは別のＷｅｂサービスである。
−「ＲＳＳ」（「Ｒｅａｌｌｙ Ｓｉｍｐｌｅ Ｓｙｎｄｉｃａｔｉｏｎ」の略）は、Ｗｅｂページの内容を記述するために使用される、ＸＭＬに基づいたフォーマットであり、これによりウェブサイトのコンテンツに自動的に索引を付けて、利用可能にすることができる。
−「Ｗｅｂサービス」は、標準インターフェースを介してインターネット上でアクセス可能なアプリケーションのことを指し、これはＸＭＬに基づく通信プロトコルなどの通信プロトコルを用いることによってアプリケーションまたは他のＷｅｂサービスと動的に情報を交換することができ、どのオペレーティングシステムおよびプログラミング言語が使用されるかにかかわらず、そうすることができる。実際のインターフェースに対してＷｅｂサービスは、入力データまたは「入力パラメータ」に基づく結果を与える処理動作を含む。Ｗｅｂサービスを利用するには、Ｗｅｂサービスに期待される入力データを与えることによって動作の１つが呼び出され、出力結果が取り出される。
−「ＳＧＭＬ」は、デジタル文書の内容とその構造の関係を記述するために使用される標準化された言語である。
−「ＷＳＤＬ」は、Ｗ３Ｃによって標準化された言語（２００１年３月１５日付けバージョン１．１、ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｗｓｄｌ参照）であり、詳細にはＸＭＬを参照する言語である。ＷＳＤＬは、次の要素、すなわちサービス名、動作、操作されるデータの型、およびこれらの型とこれらの動作のリンクを使用して、ウェブサービスへパブリックアクセスするためのインターフェースを記述する。このように、ＷＳＤＬは、サービスを利用するための通信方法、通信プロトコル、およびこのサービスとの通信に要求されるメッセージフォーマットを示す。
−「ＸＭＬ」（「ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ」の略）は、ＳＧＭＬ言語上の改良であり、詳細にはＨＴＭＬ文書の設計者によって使用されて、データの構造に名前を付ける（ｐｅｒｓｏｎａｌｉｚｉｎｇ）目的で、独自のタグを定義するものである。

最新の電気通信技術、特にインターネットにより、ユーザは様々なサービスにすばやくアクセスすることができる。問題が繰り返し起こる度に、ユーザの繰り返される要求に対処するために、適切なサービスを作成するのが一般的である。例えば、インターネットの検索エンジンには、機械翻訳などの拡張機能を提供するものがある。しかしながら、ユーザに起こる可能性のある問題によっては、既存のサービスでは解決されない。詳細には、（特定の技術の知識がない）ユーザが、一時的な問題を解決するサービスに、そのようなサービスがないのに、アクセスすることを希望する場合がある。例えば、ＩＰ端末（携帯電話、携帯情報端末、ポケットＰＣなど）のユーザが、所与のＲＳＳサービスのユーザの母国語への翻訳を入手することを希望する場合がある。

したがって、（ユーザの）要求に基づいたサービスを作成する方法、ならびにこの方法を実装するコンピュータプログラム製品およびコンピュータシステムの必要性がある。

これを受けて本発明は、要求に基づいたサービスを作成する方法を開示し、自然言語の要求を意味的に解析するステップと、行われた自然言語の意味的解析に基づいてＷｅｂサービスの要件を識別するステップと、識別されたサービスの要件に基づいてＷｅｂサービスを決定し、順序付けするステップとを含む。

好ましい実施形態では、サービスを作成する本発明の方法は、次の特徴のうちの１つまたは複数を含む。
−このプロセスはさらに、順序付けされたＷｅｂサービスを編成するステップを含む。
−Ｗｅｂサービスを決定するステップは、ＵＤＤＩレジストリにアクセスすることを含む。
−要求を意味的に解析するステップは、字句および意味の解析を含む。
−決定して順序付けするステップは、Ｗｅｂサービスを決定するステップと、次に決定したＷｅｂサービスを順序付けするステップとに分けられる。
−Ｗｅｂサービスを決定するステップは、Ｗｅｂサービスの記述に基づいてＷｅｂサービスの特性を識別することと、これらの特性の少なくともいくつかを識別した要件と比較することと、比較の結果によりＷｅｂサービスを決定することとを含む。
−Ｗｅｂサービスを順序付けするステップはさらに、識別した要件により順序付けするステップを含む。
−ウェブサービスの特性を識別する段階は、サービスのそれぞれについて、ウェブサービスの記述の取得と、このサービスの記述からこのサービスの特性を識別することとを含む。
−Ｗｅｂサービスの記述は、ＷＳＤＬ言語である。
−特性を識別するステップは、Ｗｅｂサービスの記述の意味解析を含む。
−順序付けするステップは、決定されたサービスのそれぞれについて少なくとも１つの識別された特性を含む互換性テストを含む。
−識別された特性は、サービスのそれぞれについて、それぞれが少なくとも３つのフィールドを有する少なくとも２組を含み、この組の１つの第１のフィールドはサービスの入力に関連し、この組の別の１つの第１のフィールドはサービスの出力に関連し、この組のそれぞれの第２のフィールドは第１のフィールドに関係するデータの型に関連し、この組のそれぞれの第３のフィールドは第１のフィールドに関係する意味タグに関連し、組立てのステップは、この組のそれぞれの３つのフィールドを含む互換性テストのステップを含む。
−本発明の方法はさらに、決定されて順序付けされたＷｅｂサービスに基づいて新しいＷｅｂサービスを作成するステップを含む。
−本発明の方法はさらに、決定されて順序付けされたＷｅｂサービスの承認を受信するステップと、新しいＷｅｂサービスを提供するステップとを含む。

本発明はまた、本発明の方法のステップを実装することができるコンピュータプログラム製品に関する。

本発明はまた、本発明の方法のステップを実装することができるコード手段を含むコンピュータシステムに関する。

本発明の他の特徴および利点は、単に一例としておよび例を参照して提示する、次に示す本発明の実施形態の詳細な説明、ならびに本発明の一実施形態による方法のステップおよび構成要素を示す添付の図面（唯一の図）を読んで明らかになるであろう。

このように、本発明は、要求に基づいてサービスを作成する方法を開示する。この方法は、携帯電話または携帯情報端末から送信された要求など自然言語の要求を意味的に解析するステップを含む。したがって、要求は、いかなる技術的知識を有する必要もなく、自然言語で構築されることが可能である。行われる意味解析により、Ｗｅｂサービスの要件（または仕様）を識別することが可能になる。次に、識別されたサービスの要件に基づいて、Ｗｅｂサービスの決定および順序付けが行われる。新しいサービスはその後、例えば対応する自然言語の要求を行ったユーザに対して利用可能になる。本発明の方法は、（例えば）携帯電話からの自然言語で表された要求に基づいて、インターネット上で見つけられる既存のコンポーネントのＷｅｂサービスを集めることによって新しいサービスを作成し、次に（適切な場合）提案されるコンポーネントサービスの順序付けを承認した後にこの新しいサービスをユーザに利用可能にすることを可能にする。

この方法は、複数の結合されたソフトウェアモジュールを含み、このモジュールのそれぞれが所与のタスクに割り当てられているアシスタントまたはアプリケーションなど「組み込まれた」コンピューティングツールの中に実装されるのが好ましい。

唯一の図は、本発明の一実施形態による方法のステップおよび構成要素を表す。

この図を参照すると、本発明のサービス作成方法１００は、自然言語の要求を意味的に解析するステップ３０を含む。

この要求は、例えば携帯情報端末１５０からユーザ１２０によって構築された（ステップ１０）可能性がある。この要求は次に、電気通信網を介して送信され（ステップ２０）、サーバに受信された（図示せず）。このテキストは、例えば、「Ｉ ｗａｎｔ ｔｏ ｇｅｔ ｔｈｅ ｔｅｘｔ ｏｆ Ｒｅｕｔｅｒｓ ｂｕｌｌｅｔｉｎｓ ｔｒａｎｓｌａｔｅｄ ｉｎｔｏ Ｇｅｒｍａｎ．（ロイターニュースのテキストをドイツ語に翻訳したい）」のようなものとすることができる。

上述のコンピューティングツールをサーバ側か、または上記クライアントの携帯電話もしくは携帯情報端末の中などクライアント側に実装することが可能であるということに注目されたい。

要求を解析するステップ３０は、例えば構文解析器（言い換えれば「パーサ」、すなわち構文ユニットの認識に基づいて記述を解析することができるツール）、または意味解析器に結合された構文解析ルーチンを用いて実行されることが可能である。構文解析器と意味解析器のこの結合を、（第１の）「意味モジュール」と呼ぶことにする。このモジュールは、定義により、上述のコンピューティングツールに組み込まれることが可能であり、その目的は、要求の意味解析を行うことである。

この解析により、要求をコンピュータ可読フォーマットで論理的に構築することが可能になる。自然言語のテキストの様々な意味解析技術が知られている。一般に、名前、名前のそれぞれの定義、およびこれら名前間の働きが、要求から引き出されるまたは推定される。そのために、従来の技術で知られているように、辞書または文法的解析が使用される。

詳細には、意味解析のステップ３０は、第１に、字句解析を含むことができる。先の例では、字句解析の第１の結果は、関係する単語、または必要に応じてその標準形のリストである（関係のない単語は無視される）。このリストを、表１に示す。

第２に、表２に示すように、文脈固有の意味情報の一部が、意味解析モジュールによって追加されることが可能である。

要求を字句的におよび意味的に解析するステップは、次にコンポーネントのＷｅｂサービスの要件（すなわち「仕様」）を識別する（ステップ３５）ことを可能にする。先の例では、最初の要求の追加の意味情報および文法形態を考慮に入れ、意味モジュールが、コンポーネントサービスの次の要件を作り出すことができる：
−ｇｅｔ／ｓｈｏｗ ｔｈｅ ｔｅｘｔ
−ｔｒａｎｓｌａｔｉｏｎ ｏｆ／ｖｅｒｓｉｏｎ ｏｆ／ｔｒａｎｓｌａｔｅ ｔｈｅ ｔｅｘｔ
−ｌａｎｇｕａｇｅ＝Ｇｅｒｍａｎ
−ｎｅｗｓ／ｂｕｌｌｅｔｉｎｓ／ｅｖｅｎｔｓ／ｆｅｅｄｓ
−ｃｏｍｐａｎｙ ｎａｍｅ＝Ｒｅｕｔｅｒｓ

さらに、次のステップ、すなわちＷｅｂサービスを決定するステップ４０および順序付けするステップ５０を容易にするために、これらの要件を、ＷＳＤＬフォーマット（上記定義を参照）と互換性のあるフォーマットで構成することが可能である。詳細については、後に説明する。

この対のステップ４０、５０は、Ｗｅｂサービスを決定するステップ４０と、決定したＷｅｂサービスを順序付けするステップ５０に分割されることが好ましい。このように、サービスが決定された後に、順序付けがユーザに提示されて承認を求める（ステップ５２）ことができる。ユーザは次に、これを承認する（ステップ５５）か、または独自の順序付けを組み立てて、機械に順序付けさせ、好適なモジュールによって処理されることが可能である。

あるいは、Ｗｅｂサービスが次々に決定され、その後提示されて一部を逐次順序付けされることも可能である。このような場合、決定するステップ４０および順序付けするステップ５０は、ネストされる。しかしながら、順序付けが完了した後、この順序付けがさらに承認を求めてユーザに提示されることが可能である。この場合もやはり、所定の基準に基づいて算出された順序で、複数の順序付けが提案されることが可能であることに注意されたい。

一実施形態では、Ｗｅｂサービスを決定するステップ４０は、該Ｗｅｂサービスの記述に基づいてＷｅｂサービスの特性を識別することを含む。このステップ中、利用可能なＷｅｂサービスは、例えば体系的に検討されることが可能である。Ｗｅｂサービスのそれぞれについて、特性が識別され、これらの特性の少なくともいくつかと以前に設定された要件との間で比較が行われる。これにより、比較の結果に基づいて、Ｗｅｂサービスを決定することが可能になる。

またより詳細には、Ｗｅｂサービスの特性の識別に関して、これらのサービスの標準化された記述が用いられる。好ましくは、Ｗｅｂサービスの個々の記述が使用される。このように、所与のＷｅｂサービスに対して上述のコンピューティングツールが、サービスの記述にアクセスし、その後この記述に基づいて特定の特性を識別する。これらの特性は、サービスの記述の中などに明確に存在するわけではないことに注意されたい。これらの特性は、本発明の方法によって推定される。

上述のように特にＵＤＤＩレジストリなどの記述カタログが利用可能である場合は、Ｗｅｂサービスの個々の記述を使用することが好ましい。

好ましくは、サービスの各記述は、例えばＵＤＤＩレジストリと同様に、ＷＳＤＬ言語である。このように、標準化された記述は、各Ｗｅｂサービスに利用可能である。さらに、公開されたＷｅｂサービスの外部のインターフェースからレジストリサーバによって自動的に作られるので、このような記述はレジストリサーバで常に利用可能である。これにより、この方法とのより大きな互換性がもたらされる。

さらに、このような記述を、構文解析器（すなわち上記「パーサ」）を使用するなどにより、自動的に解析することが可能である。（第２の）意味モジュールについては、下記で言及する。したがってこの第２のモジュールの機能は、ＷＳＤＬ記述を意味的に解析することである。

さらに詳細には、構文解析器は、例えば従来技術で知られているような字句解析を含むことができる。抽出された字句成分の意味を決定するために、次にＷｅｂサービスの記述の意味解析が行われる。

サービスの記述を解析することにより、サービスのそれぞれの特性を識別することが可能になる。例えば、これにより、サービスの動作のそれぞれの特性の組を識別することが可能になる。これらの特性は後に、識別されたサービスの接続性を判断するために使用される。

前もって設定された要件および識別された特性は、好ましくは同様に構成されているので、これらを比較することは（共有される特性の数に基づかれることによってなど）より容易にかつより速くなる。この比較が完了すると、所与の要件の組について、１つのＷｅｂサービス（または複数）が決定される。適切な場合には、ランキングを決定して、次に（比較の意味において）「最良の」サービスのみを保持することが有益であることもある。

コンポーネントのＷｅｂサービスを決定するステップ３５が完了すると、所与の数の知られているサービスが利用可能である。次に、要求に示されたロジックに基づいてこれらのサービスを組み立てることが望ましい。

そうするには、前もって設定された要件を反映している識別された特性が、基準として使用されることが可能である。これらの特性により、次にサービスの接続性、すなわち接続するサービスの性質を決定することが可能になる。次に、これらのサービスを、その接続性に基づいて自動的に組み立てることが可能になる。

Ｗｅｂサービスの特性の中で、例えば所与のＷｅｂサービスの動作のそれぞれの少なくとも１つの入力および／または出力を識別することを求めることができる。

より一般的には、例えば各サービスの各動作の入力−出力を、「入力パラメータ」または「出力結果」として（上記のこれらの用語の定義を参照）検索することができる。このようにして、次にＷｅｂサービスの動作の入力特性／出力特性を比較することによって、Ｗｅｂサービスの接続性をテストすることが可能である。例えば、サービスＢの動作の入力と互換性のある出力を提供する動作を有するサービスＡは、サービスＢに接続することができる。

サービスの接続性を判断するために、またこれらのサービスの将来の組立てを視野に入れて、一実施形態では、所与のＷｅｂサービスの動作の各入力および各出力について特性の組を形成することが可能である。

Ｗｅｂサービスの１つの動作が複数の入力または複数の出力を有する場合、Ｗｅｂサービスの記述が解析されると、対応する数の組が形成されることが可能である。

パラメータ自体の名前に加えて、これらの組は、例えばそれぞれ３つの（または、計画されているテストモデルによってはさらに多い）フィールドを有することができる。しかしながら、ＷＳＤＬ記述がどのように解釈されるかに応じて２つのフィールドを使用すれば十分であるとわかる可能性があることを理解すべきである。

したがって各組は、好ましくは３つのフィールドを有し、Ｗｅｂサービスの動作の入力パラメータまたは出力結果に関連する。第１のフィールドは、問題のパラメータまたは結果の入力または出力情報に関連する。各組の第２のフィールドは、パラメータまたは結果のデータの型を指定する。データの型は、サービスのＷＳＤＬ記述で見つけられる要素の１つである。第３のフィールドは、意味タグ（すなわち、下の例では「ＳｅｍＴａｇ」）に関連し、これはパラメータまたは結果と関連付けられる。意味タグは、ここではデータと関連付けられてデータを意味的にさらに特徴付ける働きをする名前、一連の文字、またはより一般的にはコードとみなされることが可能である。型が、ＷＳＤＬ記述から直接引き出されることが可能である場合、このＷＳＤＬ記述が解析された後にタグが配置されるということに注意されたい。

次に、特性の互換性テストは、各組の各フィールドを含むことができる。

上述した第２の意味モジュールは、典型的に上記コンピューティングツールの一体部分を形成し、入力および出力の両方において、データの各型に意味タグを設置するために使用されることが可能である。このタグは、入力／出力データの性質を指定し、したがってデータがどのように処理されるかを指定する。このように、入力／出力データの各部分は、三要素によって次のように記述される：
｛ｉｎｐｕｔ ｏｒ ｏｕｔｐｕｔ、ｔｙｐｅ ｏｆ ｄａｔａ、ｓｅｍａｎｔｉｃ ｔａｇ｝

後に述べるＷｅｂ翻訳サービスの入力の、３つのフィールドを使用した意味記述に対応するＸＭＬファイルの抜粋を、以下に示す（このＸＭＬファイルの抜粋は、対応するＷＳＤＬファイルで実行された意味処理の結果である）：

このように、各パラメータは、入力情報に加えて、パラメータ名、パラメータ型、およびパラメータの意味タグ（「ｓｅｍｔａｇ」）に対応する３つのフィールドを持つことがわかる。次にサービス間の互換性のテスト中に用いられる情報の三要素は、入力もしくは出力情報、情報の型、および意味タグである。

ここで、意味解析に関してさらに詳細な説明を行う。

ＷＳＤＬファイルが解析されるときは必ず、型、メッセージ、動作、およびサービスの名前に対応する４つの主要部分が識別され得る。さらに、「ＰｏｒｔＴｙｐｅ」および「Ｂｉｎｄｉｎｇ」に対応する他の情報が識別され（これら２つの用語は、ＷＳＤＬ記述の従来の用語である）、動作の入力／出力とメッセージとの関係を作り出す働きをする。

ＷＳＤＬ記述の第１の、また単に構文の解析レベルにより、サービスの「有用な」構文構造、すなわち必要かつ十分な情報を取得することができる。この情報は、主として上述の４つの部分から取得される。検索に役立たない要素は、削除される。残りの情報は整理し直され、「Ｂｉｎｄｉｎｇ」および「ＰｏｒｔＴｙｐｅ」情報を用いて相互に連結される。これは、構文解析器を用いて容易に成し遂げられる。このレベルでは、意味データはまだ付加されない。

一例として、翻訳サービスに取得される有用な構文構造は、（用語をＸＭＬ言語から取った）次のようなものである：

有用な構文構造に基づいて、第２の意味モジュールを用いてより精密な解析が行われる。このモジュールは、例えば次の動作を課せられることが可能である。このモジュールは、使用されている用語（上記の用語の「Ｔｒａｎｓｌａｔｅ」、「ｌａｎｇ」、「ｔｅｘｔ」、「ＴｒａｎｓｌａｔｅＲｅｓｕｌｔ」など）を選んで、これらの用語を「連結解除する」ために、これらの用語を分解する（これらの用語は一般にプログラミング言語に使用される用語と同様の方法で書かれているか、または” ”などの文字で区切られている）。モジュールは次に、（辞書での検索によるなど）必要であれば、省略された用語を拡張する。先の例では、これは、「ｔｒａｎｓｌａｔｅ」、「ｔｅｘｔ」、および「ｔｒａｎｓｌａｔｅ ｒｅｓｕｌｔ」となる。このようにされた後、適切な辞書を用いて、モジュールは、名詞を直面する各動詞、ならびに各名詞の定義と関連付けようとする。適切な場合は、モジュールは、他のものではなく１つを保有するためにこれらの定義を調べる。補間技術が知られており、これにより、適切な場合、これらの処理タスクを簡略化し、容易に使用できる結果を得ることが可能になる。

上述の、第５のステップの主な目的は、サービスの上記の有用な構文構造の各入力／出力の名前のそれぞれに意味タグを追加することである。このように、タグの「ｔｅｘｔ」が、対応する入力の「ｔｅｘｔ」に配置される。このようにして、サービスの再加工された記述が取得される。翻訳サービスの例では、上述のＸＭＬファイルの抜粋と同様の記述が取得される。

「スーパータグ（ｓｕｐｅｒｔａｇ）」と考えることができる意味タグを配置することにより、Ｗｅｂサービスの接続性を効率的に決定することが可能になる。しかしながら、他の意味解析技術がこの配置に用いられることも可能である。

この時点では、すべてのコンポーネントが、１つのＷｅｂサービスを他のＷｅｂサービスと接続可能にする。

次には、一例を用いてＷｅｂサービスの接続性を決定するステップについて説明する。

この例では、ユーザは、翻訳サービスおよびＲＳＳサービスからＲＳＳフィード（新聞のウェブサイトから抜き出したものなど）の翻訳の結果が表示されるようにしたいことを要求の中で表す。ＲＳＳフィードは、詳細にはニュースサイトからヘッドラインまたは全テキストを自動的に再生する。このフォーマットは、特に定期的にコンテンツが更新されるページを利用するために用いられる。

この場合、この時点で、要求が伝えられて解析され、そこからＷｅｂサービスの要件が引き出され、最終的に、ＵＤＤＩレジストリを調べることによって、これらのＷｅｂサービスが発見されたと仮定する。したがって、必要なＷｅｂサービスが利用可能である。ここで、発生する１つの問題は、ＲＳＳコンテンツの一部分の機械翻訳を入手するために、いかにしてこれらのサービスを自動的に組み立てるかということである。

第１に、翻訳のＷｅｂサービスが利用可能であり、これは入力（第１の言語、すなわち「ｌａｎｇｕａｇｅ １」で書かれたテキスト）および出力（第２の言語、すなわち「ｌａｎｇｕａｇｅ ２」で書かれた別のテキスト）を所有する。対応するＷＳＤＬ記述の解析の結果、次の三要素の組によって記述された入力および出力データが識別される。

用語「ｓｔｒｉｎｇ」は、文字の列のことを指す。

ＲＳＳフィードを提供するＷｅｂサービスもまた、利用可能である。このＷｅｂサービスは、例えば上述のツールによって行われた解析の後に、次のように指定された出力を提供する。

さらに、表示サービスが利用可能であり、解析の後に識別されたその特性は、次のように示すことができる。

次に、組み立てられるサービスのそれぞれの接続性が、好ましくは１度に２つ決定される。そのために、Ｗｅｂサービスの１つの入力と、別のサービスの出力との間の意味的一致、すなわち２つの意味的三要素間の互換性が、検索されることが可能である。

この互換性は、詳細には３つの条件を満たすことができる。
ａ）第１の三要素が出力に関し、他方の三要素が入力に関する。
ｂ）両方の型が同一であるか、または互換性がある。
ｃ）両方の意味タグが同一であるか、または互換性がある。

このために、互換表が準備されて、上述のコンピューティングツールに利用できるようにされることが可能である。

上記の例では、互換性は自動的に次の方向でわかる：
ＲＳＳサービス−＞翻訳サービス−＞表示サービス

実際に、意味モジュールに利用可能に作られた表により、サービスのそれぞれを用いて、完全な１度に２つの一致を作り出すことができる。

一方、「ＲＳＳサービス−＞表示サービス−＞翻訳サービス」の順序は、表示サービスの出力と翻訳サービスの入力との間の意味的非互換性のため、考えられないであろう。

適切な場合は、第１のサービスからの同じ型の所与の数の出力を別のサービスからの入力に接続するために、対話プロセスすなわち「反復処理」が採用されることが可能であることに注意すべきである。これは、先の例では特に有効である。このように、各ＲＳＳサービスの出力（タイトル、記述など）が翻訳されて、表示される。

さらに詳細には、Ｗｅｂサービスの接続性の決定は、
ｉ）Ｗｅｂサービスのそれぞれの入力−出力を調べることから導かれた論理的順序に基づいた第１のステップと、
ｉｉ）（上記の互換性テストを行うことによって）入力−出力自体の接続による、Ｗｅｂサービスの意味タグおよび型の詳細な記述に基づいた次のステップと
の２つのステップで行われることが可能である。

このように、特定のモジュールは、サービスの編成の順序（サービスＸがサービスＹの前に来るなど）を包括的に決定し、次により詳細なレベルでは、サービスのどの出力が別のサービスのどの入力と接続するかを決定することを課せられている。

包括的な編成の順序は、適切な場合上述のように、ユーザに提案されて（ステップ５２）承認を求める（ステップ５５）。しかしながら、このユーザは、この順序を変更する、または別のサービスを導入する決定をすることができる。

編成の順序は、例えば、規則データベースの中に実装されて、推論エンジンの制御下に置かれることが可能である経験則に基づいて決定されることが可能である。例えば、サービスＡが、その入力−出力に、テキストに対応する意味タグを所有し、サービスＢが、その入力に異なるまたは互換性のないタグを有する場合、順序は好ましくは、ＢからＡとなる。

上記の例では、まず、その出力がテキストに対応する意味タグを有するＲＳＳサービスが呼び出される（入力タグは、例えばＷｅｂアドレスに対応することができ、「テキスト」とは異なる）。次に、入力および出力にテキストに対応するタグを有する翻訳サービスが呼び出される。さらに、ＲＳＳサービスの出力は、翻訳サービスの入力に接続されることが可能である。

意味および型のタグを比較することから理解可能である明白な非互換性を考慮して、提案する自動的な接続は、
−ＲＳＳサービスのヘッドラインに対応するテキストの出力が、翻訳サービスの（唯一の）テキストの入力に接続されることが可能であり、
−ＲＳＳサービスの記述に対応するテキストの出力が、翻訳サービスの（唯一の）テキストの入力に接続されることが可能である。
これらの提案は、そのまま次の組立てのステップに保持されるか、適切な場合は上述のようにユーザに承認されることが可能である。

次に、接続性が確立されると、接続性に応じて特定の組立てモジュールによって、Ｗｅｂサービスの実際の組立てが行われる。そのために、例えば接続の文字列は、ＢＰＥＬなどの正式のオーケストレーションまたはコレオグラフィ言語に翻訳されることが可能である（本文書の始めの定義を参照）。次にこの接続の文字列は、別個のＷｅｂサービスであるので、これを実行することを課せられるオーケストレーションエンジンにサブミットされることが可能である（ステップ６０）。詳細には、次の型の接続の文字列、すなわち
“Ｉｎｐｕｔ １” ｏｆ ｓｅｒｖｉｃｅ Ａ ＝＞ ｐｒｏｄｕｃｔ “ｏｕｔｐｕｔ １”
−＞ “Ｉｎｐｕｔ ２” ｏｆ ｓｅｒｖｉｃｅ Ｂ ＝＞ ｐｒｏｄｕｃｔ “ｏｕｔｐｕｔ ２”
−＞ “Ｉｎｐｕｔ ３” ｏｆ ｓｅｒｖｉｃｅ Ｃ ＝＞ ｐｒｏｄｕｃｔ “ｏｕｔｐｕｔ ３”
が、翻訳されてオーケストレーションエンジンへサブミットされ、このオーケストレーションエンジンがサービスＡ、Ｂ、およびＣから作成された別個のサービスＤとしてこれを実行し、入力１を与えられると、「最終結果３」を直接提供することができる。

次に組立てモジュールにより、Ｗｅｂサービスを自動的に接続することが可能になる。

このようにして、上記のコンピューティングツールによって自動的に組み立てられたサービス（ステップ６０）が取得される。

このようにして組み立てられたサービスは、ユーザに利用可能にされる（ステップ６５、７０）。

１つの代替方法では、適切な場合、サービスはさらにユーザに利用可能に（このような場合、作成されて）維持されて、所与の期間の間利用可能のままとすることが可能である。

このツールを一定のアプリケーションに組み込むことにより、リアルタイムでサービスの組立てを取得することが可能になる。上記の例では、必要な要素を指定して、所望の言語への翻訳を要求すると、所望の言語に翻訳されたＲＳＳフィードを取得することが可能である。

当然ながら、他の例および組立てが予測される可能性がある。

本発明の一実施形態による方法のステップおよび構成要素を表す図である。

Claims (16)

1. 要求からサービスを作成する方法（１００）であって、
   第１の意味手段により自然言語の要求を意味的に解析する（３０）ステップと、
   行われた意味解析（３０）に基づいて識別手段によりＷｅｂサービスの要件を識別する（３５）ステップと、
   識別されたサービスの要件に基づいて第２の意味手段によりＷｅｂサービスを決定する（４０）ステップと、
   順序付け手段により決定されたＷｅｂサービスを順序付けする（５０）ステップと
   を含む、方法。
2. 組み立て手段により順序付けされたウェブサービスを編成する（６０）ステップをさらに含む、請求項１に記載の方法（１００）。
3. Ｗｅｂサービスを決定するステップが、ＵＤＤＩレジストリ（２００）にアクセスする行為を含む、請求項１に記載の方法（１００）。
4. 要求を意味的に解析する（３０）ステップが、
   字句および意味解析（３０）
   を含む、請求項１に記載の方法（１００）。
5. Ｗｅｂサービスを決定する（４０）ステップが、
   Ｗｅｂサービスの記述に基づいてＷｅｂサービスの特性を識別することと、
   これらの特性の少なくともいくつかを識別された要件と比較することと、
   比較の結果に基づいてＷｅｂサービスを決定することと
   を含む、請求項１に記載の方法（１００）。
6. Ｗｅｂサービスを順序付けする（５０）ステップがさらに、
   識別された要件に基づいて順序付けするステップ
   を含む、請求項１に記載の方法（１００）。
7. Ｗｅｂサービスの特性を識別するステップが、サービスのそれぞれについて、
   Ｗｅｂサービスの記述にアクセスすることと、
   そのサービスの記述に基づいてそのサービスの特性を識別することと
   を含む、請求項５に記載の方法（１００）。
8. Ｗｅｂサービスの記述がＷＳＤＬ言語である、請求項７に記載の方法（１００）。
9. 特性を識別するステップが、Ｗｅｂサービスの記述の意味解析を含む、請求項５に記載の方法（１００）。
10. 識別された特性が、決定されたサービスのそれぞれの入力および／または出力を含む、請求項５に記載の方法（１００）。
11. 順序付けする（５０）ステップが、
    決定されたサービスのそれぞれに少なくとも１つの識別された特性を含む互換性テスト
    を含む、請求項５に記載の方法（１００）。
12. 識別された特性が、サービスのそれぞれについて、
    それぞれが少なくとも３つのフィールドを有する少なくとも２つの組であって、
    組の１つの第１のフィールドが、サービスの入力に関係し、
    別の組の第１のフィールドが、サービスの出力に関係し、
    組のそれぞれの第２のフィールドが、第１のフィールドと関連するデータの型に関係し、
    組のそれぞれの第３のフィールドが、第１のフィールドに関連する意味タグに関係する組を含み、組立てステップがさらに、
    組のそれぞれの３つのフィールドを含む互換性テストのステップを含む、
    請求項１０に記載の方法（１００）。
13. 決定されて順序付けされたＷｅｂサービスに基づいて新しいＷｅｂサービスを作成する（６０）ステップ
    をさらに含む、請求項１に記載の方法（１００）。
14. 決定されて順序付けされたＷｅｂサービスの承認を受信する（５５）ステップと
    新しいＷｅｂサービスを利用可能にする（６５）ステップと
    をさらに含む、請求項１３に記載の方法（１００）。
15. 請求項１から１４のいずれか一項の方法（１００）のステップを実装するコンピュータプログラム。
16. 請求項１から１４のいずれか一項の方法（１００）のステップを実装する手段を含むコンピュータシステム。

Images