JP2013512488A - サービスを管理するためのアプリケーションサーバ及び方法 - Google Patents

Abstract

ユーザへ提供されるサービス（例えば、通信サービス）を管理するためのアプリケーションサーバ（１０２）が様々な他の装置及び方法とともに本明細書に記載される。本明細書に記載されるように、アスペクト指向プログラミングを利用してアプリケーションサーバは元のサービスの対象アプリケーションコードを直接に修正せずに、元のサービスに機能を自動的に追加できる。特に、所定のアプリケーションに機能を自動的に追加する場合に、アプリケーションサーバは所定のアプリケーション内にどのフィーチャがまだ欠けているか、及びどれがすでにサポートされているかを自動的に検出できる。

Description

本発明はユーザへ提供されるサービス（例えば、通信サービス）を管理するためのアプリケーションサーバ、リポジトリ装置、コンピュータプログラム及び方法に関する。

通信ネットワークでは、ユーザへ提供されるサービスをアプリケーションサーバが管理することが一般的である。サービス自体はしばしば、ユーザに所定の機能を提供するソフトウェアの部品の組み合わせである。機能は通常、サービスの開発者（例えば、ネットワークオペレータ）によって事前に規定されており、サービスの実装が変更されない限り、静的なままである。しかしながら、開発者がサービスを事前に規定した後にサービスの実装を変更したいことも一般的である。サービスを変更する１つの方法は、元のサービスの対象アプリケーションコードを直接に修正することなく、元のサービスに機能を追加することによってサービスの実装を変更することを可能にする技術であるアスペクト指向プログラミング（ＡＯＰ）を用いることである。ＡＯＰは当業者に周知な技術であるが、サービスに機能を追加することをより容易にするだろう特徴の改良方法を説明する前に、ＡＯＰの基礎について簡単な説明が以下に提供される。

ＡＯＰは複数の機能をアプリケーションに実装することを支援するソフトウェア設計技術である。しばしば、これらの機能のコードは、１つの機能に特化したコード部品が他の機能のコード内の複数の場所に配置される必要があるという意味で、非常に入り組んでいる。これらの特性は関心事の横断と呼ばれる。しかしながら、これらの複数の機能を専用のカプセル化された単位に分割することによってこれらのクリーン且つモジュール化した実装はしばしば不可能であるか、極端に困難である。

ＡＯＰはアプリケーションのコードを横断的機能のコードから分離したままにすることを可能にする。この分離した実装はアスペクトと呼ばれる。アスペクトによって実装される機能を追加するためにアプリケーションにアスペクトを適用することはウィービングと呼ばれる。アスペクトのウィービングはオフラインで行うことが可能であり、よってアプリケーションの実行前に行うことが可能である。これは通常、ポイントカットによって参照されるコード位置にアスペクトコードを差し込むことによって、ウィービングが対象アプリケーションから新たなアプリケーションを生成することを意味する。さらに、アスペクトのウィービングはオンラインで行うことも可能であり、これはアプリケーションの実行が監視され、ポイントカットによって特定される状況に達すると、アプリケーションの実行を継続する前にアスペクトが実行されることを意味する。

ウィービングはポイントカットによって誘導される。ポイントカットは、アスペクトコードが追加されるべき場所であるアプリケーション内のジョインポイントとして知られる位置の包括的定義である。例えば、ポイントカットは所定のメソッドのすべてのコールにおいてアスペクトを実行することを特定してもよい。ポイントカットは対象アプリケーションのソースコード内のポイントをキャプチャする状況に基づくか、アプリケーション実行を伴うイベントを参照する。原則として、この技術はアプリケーションを分析しなかったとしても所定の機能の自動適用を自動的に可能にしうる。例えば、新たなアプリケーションがサービス実行環境内に展開されるならば、この環境内に存在するアスペクトはこの新たな対象アプリケーションに自動的に適用されうるだろう。これは特に、サードパーティのサービスプロバイダからのサービスを使用する際に、通信分野で関心がある。

これらのサードパーティのサービスはネットワークオペレータによって要求される機能のすべてをサポートしないかもしれない。例えば、アクティビティ・ロギングや課金がサードパーティのサービスで実装されないかもしれない。よって、ＡＯＰを利用して、これらの特徴が対象アプリケーションに自動的に追加されうる。これを達成しうる装置及び方法が本発明の目的である。

本出願の独立請求項にアプリケーションサーバ、リポジトリ装置、システム、コンピュータプログラム及び方法が記載される。従属請求項にアプリケーションサーバ、リポジトリ装置、システム、コンピュータプログラム及び方法の有利な実施形態が記載される。

１つの側面では、本発明はサービスを管理するために少なくとも１つのリポジトリと相互作用するアプリケーションサーバを提供する。前記アプリケーションサーバは、（ａ）前記サービスによってランタイム・データに実装されるアプリケーション関心事のリストを識別するサービス記述をロードするために前記少なくとも１つのリポジトリと相互作用するように構成された合成エンティティと、（ｂ）アスペクト関心事のリストを識別するアスペクト記述にアクセスするために前記少なくとも１つのリポジトリと相互作用するように構成されたウィービング・エンティティであって、アスペクト関心事の前記リストは一意なアスペクト識別情報を有し、アスペクト関心事のそれぞれは一意識別子（例えば、タグ又はキーワード）によって識別される、ウィービング・エンティティとを備え、（ｃ）前記ウィービング・エンティティは、前記サービスの実行中に前記ランタイム・データ内の前記アプリケーション関心事の前記サービス記述を動的に更新するように構成され、ジョインポイントにおけるアスペクト・ウィービング中に、前記ランタイム・データ内の前記アプリケーション関心事の前記ランタイム・サービス記述の更新は、前記ランタイム・データ内の前記アプリケーション関心事にウィービングされる前記アスペクト関心事のために定義された前記一意識別子を追加するか、削除するか、又は削除されたものとしてマークすることによって実行される。この利点は、アスペクトが必要とされるサービスにのみアスペクトがウィービングされることをアプリケーションサーバが確かめることである。

さらに別の側面では、本発明はサービスを管理するために少なくとも１つのリポジトリと相互作用するアプリケーションサーバによって実施される方法を提供する。前記方法は、（ａ）前記サービスによってランタイム・データに実装されるアプリケーション関心事のリストを識別するサービス記述をロードするために前記少なくとも１つのリポジトリと相互作用する工程と、（ｂ）アスペクト関心事のリストを識別するアスペクト記述にアクセスするために前記少なくとも１つのリポジトリと相互作用する工程であって、アスペクト関心事の前記リストは一意なアスペクト識別情報を有し、アスペクト関心事のそれぞれは一意識別子（例えば、タグ又はキーワード）によって識別される、工程と、（ｃ）前記サービスの実行中に前記ランタイム・データ内の前記アプリケーション関心事の前記サービス記述を動的に更新する工程とを有し、ジョインポイントにおけるアスペクト・ウィービング中に、前記ランタイム・データ内の前記アプリケーション関心事の前記ランタイム・サービス記述の更新は、前記ランタイム・データ内の前記アプリケーション関心事にウィービングされる前記アスペクト関心事のために定義された前記一意識別子を追加するか、削除するか、又は削除されたものとしてマークすることによって実行される。この利点は、アスペクトが必要とされるサービスにのみアスペクトがウィービングされることをアプリケーションサーバが確かめることである。

なおも別の側面では、本発明はサービスを管理するためのシステムを提供する。前記システムは、少なくとも１つのリポジトリと、アプリケーションサーバとを備え、（ａ）前記少なくとも１つのリポジトリは、前記サービスによって実装されるアプリケーション関心事のリストを識別するサービス記述を格納し、（ｂ）前記少なくとも１つのリポジトリは、アスペクトによって実装されるアスペクト関心事のリストを識別するアスペクト記述も格納し、アスペクト関心事の前記リストは一意なアスペクト識別情報を有し、アスペクト関心事のそれぞれは一意識別子（例えば、タグ又はキーワード）によって識別され、（ｃ）前記アプリケーションサーバは、（ｉ）前記サービスによってランタイム・データに実装されるアプリケーション関心事の前記リストを識別する前記サービス記述をロードように構成された合成エンティティと、（ｉｉ）アスペクト関心事のリストを識別するアスペクト記述にアクセスするために前記少なくとも１つのリポジトリと相互作用するように構成されたウィービング・エンティティであって、アスペクト関心事の前記リストは一意なアスペクト識別情報を有し、アスペクト関心事のそれぞれは一意識別子によって識別される、ウィービング・エンティティとを備え、（ｉｉｉ）前記ウィービング・エンティティは、前記サービスの実行中に前記ランタイム・データ内の前記アプリケーション関心事の前記サービス記述を動的に更新するように構成され、ジョインポイントにおけるアスペクト・ウィービング中に、前記ランタイム・データ内の前記アプリケーション関心事の前記ランタイム・サービス記述の更新は、前記ランタイム・データ内の前記アプリケーション関心事にウィービングされる前記アスペクト関心事のために定義された前記一意識別子を追加するか、削除するか、又は削除されたものとしてマークすることによって実行される。この利点は、アスペクトが必要とされるサービスにのみアスペクトがウィービングされることをアプリケーションサーバが確かめることである。

さらに別の側面では、本発明はサービスを提供するアプリケーションサーバと相互作用するリポジトリを提供する。前記リポジトリは、前記サービスによって実装されるアプリケーション関心事のリストを識別するサービス記述を格納するための記憶装置を備え、アプリケーション関心事のそれぞれは一意識別子（例えば、タグ又はキーワード）によって識別される。

さらに別の側面では、本発明はサービスを提供するアプリケーションサーバと相互作用するリポジトリによって実施される方法を提供する。前記方法は、前記サービスによって実装されるアプリケーション関心事のリストを識別するサービス記述を格納する工程を有し、アプリケーション関心事のそれぞれは一意識別子によって識別される。

さらに別の側面では、本発明は、コンピュータで実行された場合に前記コンピュータに、サービスによって実装されるアプリケーション関心事のリストを識別するサービス記述を格納する工程を実行させるコンピュータ読み取り可能コードを有するコンピュータプログラムを提供し、アプリケーション関心事のそれぞれは一意識別子（例えば、タグ又はキーワード）によって識別される。

なおも別の側面では、本発明は、コンピュータで実行された場合に前記コンピュータに、（ａ）前記サービスによってランタイム・データに実装されるアプリケーション関心事のリストを識別するサービス記述をロードするために前記少なくとも１つのリポジトリと相互作用する工程と、（ｂ）アスペクト関心事のリストを識別するアスペクト記述にアクセスするために前記少なくとも１つのリポジトリと相互作用する工程であって、アスペクト関心事の前記リストは一意なアスペクト識別情報を有し、アスペクト関心事のそれぞれは一意識別子（例えば、タグ又はキーワード）によって識別される、工程と、（ｃ）前記サービスの実行中に前記ランタイム・データ内の前記アプリケーション関心事の前記サービス記述を動的に更新する工程とを実行させるコンピュータ読み取り可能コードを有するコンピュータプログラムを提供し、ジョインポイントにおけるアスペクト・ウィービング中に、前記ランタイム・データ内の前記アプリケーション関心事の前記ランタイム・サービス記述の更新は、前記ランタイム・データ内の前記アプリケーション関心事にウィービングされる前記アスペクト関心事のために定義された前記一意識別子を追加するか、削除するか、又は削除されたものとしてマークすることによって実行される。

本発明の更なる側面が以下の詳細な説明、図面及び任意の請求項において部分的に説明され、詳細な説明から部分的に導出され、又は本発明の実施によって習得されうる。前述の総括的な説明及び以下の詳細な説明は例示のため、および説明のためであり、開示される本発明の限定するものではないことが理解されるだろう。

本発明のより完全な理解は添付の図面と合わせて以下の詳細な説明を参照することによって得られうる。

本発明の実施形態に従って一緒にサービスを管理するアプリケーションサーバ、サービス・リポジトリ及びアスペクト・リポジトリを含む例示のシステムを説明するブロック図である。 、 本発明の実施形態に従って実行される例示のウィービング・シナリオを説明するのに役立つ２つの図である。

ＡＯＰを利用して元のサービスの対象アプリケーションコードを直接に修正せずに元のサービスに機能を自動的に追加できるアプリケーションサーバが以下に記載される。アプリケーションサーバは特に、所定のアプリケーションに機能を自動的に追加する場合に、所定のアプリケーションコード内にどのフィーチャがまだ欠けているかと、どれが既にサポートされているかとを自動的に検出する。例えば、対象アプリケーションが既に課金をサポートしているならば、課金サポートを追加するアスペクトは重複又は矛盾する課金を避けるために適用されないだろう。これを実現するために、アプリケーションサーバは、アプリケーションコード及び現在適用されているアスペクトによってどの機能が既にカバーされているかを制御するためにアプリケーションのフィーチャ及び能力を動的に記述するように構成される。アプリケーションは、アプリケーションが既に対処しているフィーチャ及び関心事に対応する一意識別子、例えばタグやキーワードの集合で記述される。また、アスペクトが対処するだろう関心事も記述される。アスペクトが対象アプリケーションコードにウィービングされるならば、アスペクトによって適用される変更を反映するように、現在対処されている関心事のリストが更新される。アスペクトが自動的に追加されるべきかを決定する場合に、アスペクトが提供する機能がアプリケーションによって既にカバーされているかどうか、そしてそれ故、アスペクトが不要であるかどうかを確認するためにこのリストが参照されうる。

上述のようなサービスを管理するように構成されたアプリケーションサーバは典型的に、１つ以上のリポジトリ装置と相互作用し、アプリケーションサーバとリポジトリ装置（群）との両方が（詳細に後述される）以下の特徴のうちの１つ以上を有するだろう。

１．サービスが実装する関心事の記述は、特定のドメインからの使用のためにサービスを公開する（例えば）サービス・リポジトリ内に格納されたサービス記述に規定される（図１参照）。例えば、サービス記述はサービスのバインド情報を含んでもよく、通常はサービスの機能及び能力を記述する。ウェブサービス記述言語（ＷＳＤＬ）はこのようなサービス記述に用いられうる１つの方式である。

１．１ 関心事のサービス記述は、対処される関心事ごとに１つの一意識別子（例えば、キーワード／タグ）を有する。

２．アスペクトが実装する関心事はアスペクトの記述内に規定される。この記述はアスペクト・リポジトリ内に格納される（図１参照）。アスペクト記述は、適用されるならばどの機能をアスペクトがアプリケーションへ追加する（又はアプリケーションから削除する）かを示す。

２．１ 関心事のアスペクト記述は、対処される関心事ごとに１つの一意識別子（例えば、キーワード／タグ）を有する。

２．２ 関心事のアスペクト記述は、アスペクトがこの関心事の処理を追加又は削除するかを付加的に表現できる。

２．３ 一緒になって関心事を実装する複数のアスペクトは共通ＩＤ（アスペクト・グループＩＤ）と一緒にアスペクト・リポジトリ内に登録される。

３．アプリケーションのインスタンスが対処する関心事のリストはアプリケーションサーバ内でランタイムに動的に維持され更新される（図１参照）。例えば、アスペクトの使用はアプリケーション全体によって対処される関心事における変更を生じさせうる。

３．１ デフォルトのサービス関心事記述はサービス・リポジトリからアプリケーションサーバにコピーされ、サービス開始時のサービス・インスタンスでランタイム・データに格納される。

３．２ ランタイム・データ内のサービス関心事記述はサービスの実行を通じて更新され、例えばアスペクト・ウィービングによってこの実行中のインスタンスへ機能が動的に追加又は削除される。

３．３ ランタイム関心事記述の更新は、アプリケーションコードにウィービングされるアスペクトについて定義される関心事タグを追加又は削除することによって実行される。

３．４ アスペクトが機能を削除するならば、それぞれのキーワード／タグの削除によって、ランタイム・サービス関心事記述においてこれが反映される。

３．５ アスペクトが機能を削除するならば、削除されたものとして関心事をマークする情報を付加することによってランタイム・サービス関心事記述においてこれが反映される。

３．６ 同じ関心事についてどのアスペクトが適用されるかを判定するポリシーが変わるならば、この関心事と一緒に登録されているアスペクトＩＤは変更／更新されてもよい。

３．７ 複数のアスペクトが単一の関心事に対処するものにウィービングされるならば、ランタイム関心事記述において複数のアスペクトＩＤがこの関心事と一緒に格納される。

３．８ 関心事が複数のアスペクト（アスペクトのグループ）によって実装されるならば、これらの関心事は共通グループＩＤと一緒に登録される。このアスペクト・グループＩＤは、グループ内の任意のアスペクトをウィービングした後にランタイム・サービス関心事記述内の関心事で格納される。

４ ランタイム・サービス関心事記述は、アスペクトがアプリケーションにウィービングされるべきかどうかの決定が必要な場合に評価される。アスペクト・ウィービングは、アプリケーションがアスペクトと同じ関心事に既に対処しているならば、拒絶されうる。

４．１ アスペクトの関心事記述が、ランタイム・サービス関心事記述にも含まれる関心事を含むならば、アスペクト・ウィービングは拒絶されうる。

４．２ ウィービングにおいて、ランタイム・サービス関心事記述が、アスペクト関心事記述にも含まれる関心事を既に含むならば、対立する関心事がアスペクトの以前のウィービングによって追加された場合に、ウィービングは許可されうる。

４．３ ジョインポイントにおいて同じ関心事について複数のアスペクトが適用可能であるならば、どのアスペクトを適用するかに関する決定をサポートするためにポリシーが用いられうる。この観点で、複数のアスペクトは同じ関心事を実装するものの、ポリシーは複数のアスペクトがウィービングされることを可能にする。

４．４ 結合ポイントにおいて同じ関心事について複数のアスペクトが適用可能であるならば、アスペクトの適用の順序に関して決定するためにポリシーが用いられうる。

５ 合成サービスの関心事のデフォルトのリストは合成に用いられている構成サービスのリストから導出されてもよい。このようにアスペクト・ウィービングと合成との両方が、対処される関心事のリストを動的に変更してもよい。

図１を参照して、本発明の実施形態に従うサービス１０８を一緒に管理するアプリケーションサーバ１０２、サービス・リポジトリ１０４及びアスペクト・リポジトリ１０６を含む例示のシステム１００を説明するブロック図が示される。アプリケーションサーバ１０２は当該分野において周知の多くのコンポーネントを含むが、これらは明確化のために図１には示されず、本発明に関連する合成エンティティ１１０、分析機能１１２、ランタイム・データ１１４及びウィービング・エンティティ１１６のようなコンポーネントが示される。これらのコンポーネント１０２、１０４、１０６、１０８、１１０、１１２、１１４、１１６のそれぞれの機能に関する詳細な説明は以下のトピックに関して以下に記載される。（１）アプリケーション及びアスペクトの関心事（特徴１．ｘ、特徴２．ｘ）。（２）ランタイムでの関心事処理（特徴３．ｘ）。（３）ウェービング決定に影響する関心事（特徴４．ｘ）。（４）その他の実施形態（特徴５）。（５）例示のシナリオ（図２、図３）。

１．アプリケーション及びアスペクトの関心事（特徴１．ｘ、特徴２．ｘ）
サービス１０８の機能全体は、アプリケーション全体の相異なる部分を提供する複数のサブ機能で構成される。これは特に、各構成サービス１２１ａ、１２１ｂ（service1、service1）がアプリケーションの一部を提供する合成サービス１１８である場合である。合成サービス１１８によって実装される機能は関心事１２０ａ、１２０ｂと呼ばれる。この観点でＡＯＰは合成サービス１１８によってどの関心事１２０ａ、１２０ｂが対処されるかを修正する方法である。

ＡＯＰ技術の使用前の合成サービス１１８は複数の関心事１２０ａ、１２０ｂに対処する。例えば、合成サービス１１８はサービスの課金を扱うかもしれないが、合成サービス１１８はロギングのサポートを含まないかもしれない。本発明の特徴は、アプリケーションの実装によって既にカバーされている関心事１２０ａ、１２０ｂのリスト１１９を、サービス・リポジトリ１０４内のサービス記述１１２の一部として追加することである（特徴１）。１つの実施形態では、合成サービス１１８が対処する各関心事１２０ａ、１２０ｂはキーワード／タグ（例えば、concern1、concern2）に対応しうる。その後、関心事１２０ａ、１２０ｂの集合全体はこれらのキーワード／タグのリスト１１９によって表される（特徴１．１）。

また、アスペクト１２４は関心事１２６ａ、１２６ｂの実装を提供する。これは、アスペクト・リポジトリ１０６内のアスペクト記述１２８によって反映される。アスペクト記述１２８は一意ＩＤ１３０と、アスペクト１２４に関連する関心事１２６ａ、１２６ｂのリスト１３２とを含む（特徴２）。さらに、アスペクト記述１２８は、これが適用されるならば、関心事１２６ａ、１２６ｂがアプリケーションへどの機能を追加するか、又はアプリケーションからどの機能を削除するかを示す。１つの実施形態では、アスペクト１２４が対処する各関心事１２６ａ、１２６ｂはキーワード／タグ（例えば、concern3、concern4）と一緒にリスト１３２に格納されてもよい（特徴２．１）。

アスペクト１２４がアプリケーションに実装を追加できる関心事（例えば、関心事１２６ａ）は、アスペクト１２４がアプリケーションから削除できる関心事（例えば、関心事１２６ｂ）から区別されるべきである。１つの実施形態では、これを実現するために、関心事１２６ａ、１２６ｂについて別個のリスト１３２ａ、１３２ｂを用いる（特徴２．２）。１つのリスト１３２ａはアスペクト１２４がアプリケーションに追加する関心事１２６ａを識別し、別のリスト１３２ｂはアスペクト１２４がアプリケーションから削除する関心事１２６ｂを識別する。アプリケーションへの関心事の削除及び追加の例は、元の合成サービス１１８がユーザに課金する機能を含むかもしれない場合である。しかしながら、オペレータは、課金の特定のメソッドを有することを望まないかも知れず、それ故、この種の課金を削除するためにアスペクト１２４（関心事１２６ｂ）を使用する。さらに、オペレータは別のアスペクト１２４（関心事１２６ａ）を通じて自身の好みの課金方法を合成サービス１１８に追加してもよい。関心事１２６ａ、１２６ｂは両方の場合について「charging」と呼ばれないだろうが、例えば、「charging_methodA」、「charging_methodB」と呼ばれるだろう。

各関心事１２６ａ、１２６ｂは、それぞれが関心事の機能全体の一部を実装する複数のアスペクトによって実装されてもよい。これらのアスペクトはアスペクト・グループである。これらは共通アスペクト・グループＩＤと一緒にアスペクト・リポジトリ１０６に登録される（特徴２．３）。このアスペクト・グループＩＤを実装する方法は複数存在する。例えば、特定のグループに属するすべてのアスペクト１２４にグループＩＤを付加することによる。または、特定のグループに属するすべてのアスペクト１２４のリストとして別々にグループＩＤを特定することによる。これらのアプローチのそれぞれは独自の利点及び不都合を有する。

２．ランタイムでの関心事の処理（特徴３．ｘ、４．ｘ）
前節で導入されたサービス記述１２２及びアスペクト記述１２８はサービス１０８の実行のための環境を設定する。サービス記述１２２、１２８はサービス１０８のランタイムで用いられる（特徴３）。

実行開始において、アプリケーションサーバ１０２、特に合成エンジン１１０はサービス記述１２２をサービス・インスタンスのランタイム・データ１１４にロードする。１つの実施形態では、これを行うために、サービス記述１２２をサービス・リポジトリ１０４からランタイム・データ１１４へコピーする（特徴３．１）。別の実施形態では、分析機能１１２はサービス１０８の分析の結果としてサービス記述１２２を判定しうる。

ランタイム・サービス関心事記述１２２’はアスペクト１２４がアプリケーションにウィービングされるごとに更新される（特徴３．２）。１つの実施形態では、アプリケーションサーバ１０２、特にウィービング・エンティティ１１６はこれを行うために、アスペクト関心事記述１２８に特定される関心事をランタイム・サービス関心事記述１２２’に追加する（特徴３．３）。

アスペクト１２４が機能を削除するならば、それぞれの関心事記述は追加されるのではなく、ランタイム・サービス関心事記述１２２’から削除される必要がある（特徴３．４）。１つの実施形態では、関心事の削除は、当該関心事が削除されたものとしてマークするのではなく、ランタイム・サービス関心事記述１２２’において実際に離すことによって実行される（特徴３．５）。

ランタイム中に変更されるランタイム・サービス関心事記述１２２’内のすべての関心事は、変更の起源としてマークされる。例えば、ウィービングされたアスペクトが変更を引き起こすならば、この特定の関心事はそれぞれのアスペクトＩＤによってマークされる（特徴３．６）。

所与のジョインポイントについて、関心事を実装する複数のアスペクトが適用可能であってもよい。例えば、課金のためのアスペクトの適用を導くジョインポイントにおける２つの有効なウィービング命令が存在してもよい。二重課金を避けるために、これらのうちの１つだけが実際に用いられるべきである。１つの実施形態では、ウェービング・エンティティ１１６はウィービングについて１つのアスペクトだけ（例えば、処理された最初のアスペクト）を選択し、同じ関心事のための他のアスペクトはスキップされる。別の実施形態では、どのアスペクトが用いられるかを制御するためにポリシーが定義されうる（特徴４．３、４．４）。単一の関心事について複数のアスペクトが用いられるならば、複数のアスペクトＩＤを関心事に割り当てることによって、ランタイム関心事記述１２２’にこれが反映されうる（特徴３．７）。

ランタイム・サービス関心事記述１２２’において、アスペクトのＩＤはアスペクトが追加した関心事と一緒に格納される。相異なるジョインポイントで同じ関心事のための同じアスペクトがブロックされないことを保証するためにこれが行われる。そうでなければ、アスペクトは自身をブロックしうる。これは、ランタイム・サービス関心事記述１２２’が最初のジョインポイントで更新されるので発生しうる。その後、更新されたランタイム・サービス関心事記述１２２’内にこの関心事が既にあるので、他のジョインポイントにおいて、アスペクトの他の部分のウィービングがブロックされる。関心事の実装が複数のアスペクトに亘って意図的に広がるならば、このようなブロックも発生しうる。単一の関心事について複数のアスペクトが用いられるならば、複数のアスペクトＩＤを関心事に割り当てることによって、ランタイム・サービス関心事記述１２２’にこれが反映されうる（特徴３．７）。これにより、関心事に割り当てられたすべてのアスペクトが、同じ関心事に対処する他のジョインポイントで用いられることが可能になる。

特定のアスペクトのウィービングを導くポリシーは変わりうる。これが発生したならば、ランタイム・サービス関心事記述１２２’は新たなポリシーを反映するために更新される必要があるだろう。この更新はランタイム・サービス関心事記述１２２’において関心事に割り当てられたアスペクトＩＤの削除を暗に示すだろう。これはまた、新たなポリシーに従って選択されていただろうアスペクトの新たなＩＤで元のアスペクトＩＤを置き換えることにつながるだろう（特徴３．６）。しかしながら、このメカニズムは、最初に用いられたものとは非互換である残りの実行のためのアスペクトが用いられないことを保証するように、慎重に用いられるべきである。さらに、置換アルゴリズムは互換性問題を検討し考慮に入れるべきである。実際、すべての実行中の合成セッションについてポリシーを有効に維持し、新たなセッションについてのみ新たなポリシーを使用する方がよいかもしれない。いずれの場合でも、例えば合成の再開や古いポリシーの更なる使用が受け入れられない長時間実行中の合成セッションについて、記載されたポリシーの置換が必要になりうる。

時には、一般に様々なジョインポイントでアプリケーションにウェーブされる複数のアスペクトに関心事の実装が分配される必要がある。このようなアスペクトのグループは単一のグループアスペクトＩＤと一緒にアスペクト・リポジトリ１０６に記述される。その後、グループのアスペクトＩＤは、グループのアスペクトが適用されるとランタイム・サービス関心事記述１２２’内の関心事にも割り当てられる。同じグループからの異なるアスペクトが別のジョインポイントでウィービングされようとしているならば、これは許可される。なぜなら、このアスペクトは、既に関心事に割り当てられた同じアスペクト・グループＩＤと一緒にアスペクトが記述されるからである（特徴３．８）。

３．ウェービング決定に影響する関心事（特徴４．ｘ）
ランタイムにおいて、アスペクト１２４はアプリケーションにウィービングされ、各ジョインポイントにおいて、ウィービング・エンティティ１１６はアスペクト１２４がウィービングされうるかどうかに関する決定を行う必要がある。ウィービング・エンティティ１１６は、アスペクト１２４が実装する関心事１２６ａ、１２６ｂが対象アプリケーションに既に存在するならば、アスペクト１２４のウィービングをスキップする。この目的のために、アスペクト・リポジトリ１０６に格納されたアスペクト関心事記述１２８はランタイム・サービス関心事記述１２２’に対して比較される。アスペクト関心事１２６ａ、１２６ｂが既にランタイム・データ１１４内にあるならば、ウィービングはスキップされてもよい。

アスペクト１２４はアプリケーションに亘る複数のジョインポイントでウィービングされてもよい。これは、単に最初のウィービングにおいてランタイム・サービス関心事記述１２２’が更新されたからといって、更なるウィービングを常に拒絶してはならないことを意味する。更なるウィービングが同じアスペクト１２４に関連しうるならば、これは許可されるべきである。これを達成するために、アスペクト関心事記述タグをランタイム・サービス能力リストに格納するだけでなく、アスペクトＩＤ１３０が特定の関心事１２０ａ、１２０ｂと一緒に格納される。同じアスペクト１２４の更なるウィービングにおいて、ウィービング・エンティティ１１６はランタイム・データ１２４にマッチング関心事記述及びアスペクト記述１２８を発見するが、対立する関心事が同じアスペクトＩＤ１３０を有するアスペクト１２４によって追加されたならばウィービングは許可される。

ジョインポイントにウィービングされるべきアスペクト１２４に関する決定を行う際に、同じ関心事１２０ａ、１２０ｂについての複数のアスペクト１２４が適用可能であってもよい。１つの実施形態では、ポリシーは、どのアスペクト１２４を選択するかに関する規則を提供する。例えば、ポリシーは検討される最初のアスペクト１２４を特定してもよい。別の関心事１２０ａ、１２０ｂについて、ジョインポイントについて適用可能な最後のアスペクトが選択されてもよい。ポリシーはまた、複数のアスペクト１２４が関心事１２０ａ、１２０ｂについてウィービングされることを許可し、アスペクト・ウィービング／実行の順序を判定してもよい。

４．その他の実施形態（特徴５）
図１に示されるように、合成に利用可能な構成サービス１２１ａ、１２１ｂと、ウィービングに利用可能なアスペクト１２４とは別個のリポジトリ１０４、１０６内に登録される。必要ならば、ただ１つのリポジトリが、（構成サービス１２１ａ、１２１ｂを含む）合成サービス１１８とアスペクト１２４との両方のために存在しうる。サービス及びアスペクト関心事記述１２２、１２８のための具体的なオントロジーの定義はドメイン固有でありうる。

１つの実施形態では、デフォルトの関心事１２０ａ、１２０ｂのリスト１１９は構成サービス１１８について事前に定義され、サービス・リポジトリ１０４内に格納される。別の実施形態では、合成サービス１１８が既に対処している関心事１２０ａ、１２０ｂのリスト１１９は、この合成サービス１１８をインスタンス化するために必要な構成サービス１２１ａ、１２１ｂに関して合成サービス１１８を分析する分析機能１１２によって自動的に生成されてもよい（特徴５）。

５．例示のシナリオ（図２、図３）
サービス合成環境内で、アスペクト１２４を合成サービス１１８に適用するためにオンライン・ウィービングが用いられうる。図２に示される例では、使用されるすべての構成サービス１２１ａ’１２１ｂ’、１２１ｃ’、１２１ｄ’、１２１ｅ’、１２１ｆ’のロギングを合成サービスアプリケーション１１８に追加するアスペクト１２４が使用される。これは、合成サービス１１８内の各サービス選択後にロギング・アスペクト１２４が呼び出されることを意味する。よって、各ジョインポイントにおいて、ウィービング・エンティティ１１６は、図３に関連するフローチャートに示されるウィービング決定ロジックに従って決定を行う。

図３を参照して、図２に示される例示のサービスを実装するためにウィービング・エンティティ１１６によって実行されるウィービング決定ロジック３００を説明するフローチャートを示す。ウィービング・エンティティ１１６は、ジョインポイントに到達した（ステップ３０２）後に、ウィービング命令に従ってアスペクト１２４を選択し（ステップ３０４）、アスペクト関心事記述１２８を取得する（ステップ３０６）ように機能する。その後、ウィービング・エンティティ１１６は、アスペクト関心事がランタイム・サービス制約のリストにあるかを判定し（ステップ３０８）、結果がＮＯであればアスペクト関心事がサービス関心事１２２’のランタイム・リストに追加され（ステップ３１０）、アスペクト１２４がアプリケーションにウィービングされ（ステップ３１２）、その後終了する（ステップ３１４）。アスペクトが実際にランタイム・サービス制約のリストにあることをウィービング・エンティティ１１６が判定した（ステップ３０８）ならば、ランタイム関心事が同じアスペクト１２４からのものであるかを判定し（ステップ３１６）、結果がＮＯであれば終了し（ステップ３１８）、結果がＹＥＳであればアスペクト１２４をアプリケーションにウィービングし（ステップ３２０）、その後終了する（ステップ３２２）。この例では、サービスはロギングをサポートしない。ロギングはランタイムでアスペクトによって追加される。最初に、ロギング・アスペクトが適用されるジョインポイントに到達した場合に、ウィービング・エンティティ１１６は、アプリケーションによって既に対処されている関心事のリストにロギング関心事がないことを判定すると仮定する（ステップ３０８）。アスペクトは適用され、このサービス・インスタンスについて対処される関心事のリストは更新される（ステップ３１０、３１２）。次のジョインポイントで、再びロギング・アスペクトを適用する場合に（ステップ３０８）、ウィービング・エンティティ１１６は、ロギング・アスペクトの関心事が既に対処される関心事のリスト内にあることを見つける。このロギング関心事は同じＩＤのアスペクトによって追加されたので、ウィービング・エンティティ１１６はこのアスペクトの使用を再び許可することを決定する（ステップ３２０）。やはりロギングを適用するだろう別のアスペクトが試されたなら、ウィービング・エンティティ１１６は２つの独立したアスペクトが同じ関心事に対処することを避けるためにウィービングを拒絶するだろう（ステップ３１８）。

上記により、当業者は、本発明は少なくとも先行技術に関する前述の欠点を軽減し、アスペクト指向サービス管理環境全体の中央構成要素を提供することが意図されることを理解するだろう。このような環境では、ウィービング言語により複数のアプリケーション及びサービスに広域に亘るウィービングを定義できる。本発明は、アスペクトが必要なアプリケーションにのみアスペクトがウィービングされることを保証することに役立つ。特に、新たなアプリケーションが環境に追加されるならば、本明細書に記載されたメカニズムはグローバルなウィービング命令を変更することなくアスペクトの自動適用を可能にしうる。なぜなら、アスペクトがこのアプリケーションにウィービングされるべきかどうか、及びどのアスペクトがウィービングされるべきかをアプリケーションサーバが自動且つ動的に決定できるからである。このようなサービス環境のオペレータは、アプリケーションの機能に関して自身の要件を表現するグローバルなウィービング命令を提供できる。本明細書に記載されるメカニズム及び特徴はサポートを含まないアプリケーションにアスペクト・ウィービングによってこの機能を追加するのにも役立つ。この要件に既に準拠しているアプリケーションはウィービングから自動的に除外される。

本発明の複数の実施形態が添付の図面に説明され、前述の詳細な説明に記載されてきたが、本発明は開示された実施形態に限られず、添付の特許請求の範囲で説明され規定される本発明から逸脱することなく、多数の再構成、変形及び代替が可能であることが理解されるべきである。

Claims (34)

1. サービス（１０８）を管理するために少なくとも１つのリポジトリ（１０４、１０６）と相互作用するアプリケーションサーバ（１０２）であって、
   前記サービスによってランタイム・データ（１１４）に実装されるアプリケーション関心事（１２０ａ、１２０ｂ）のリスト（１１９）を識別するサービス記述（１２２）をロードするために前記少なくとも１つのリポジトリと相互作用するように構成された合成エンティティ（１１０）と、
   アスペクト関心事（１２６ａ、１２６ｂ）のリスト（１３２）を識別するアスペクト記述（１２８）にアクセスするために前記少なくとも１つのリポジトリと相互作用するように構成されたウィービング・エンティティ（１１６）であって、アスペクト関心事の前記リストは一意なアスペクト識別情報（１３０）を有し、アスペクト関心事のそれぞれは一意識別子によって識別される、ウィービング・エンティティ（１１６）とを備え、
   前記ウィービング・エンティティは、前記サービスの実行中に前記ランタイム・データ内の前記アプリケーション関心事のランタイム・サービス記述（１２２’）を動的に更新するように構成され、ジョインポイントにおけるアスペクト・ウィービング中に、前記ランタイム・データ内の前記アプリケーション関心事の前記ランタイム・サービス記述の更新は、前記ランタイム・データ内の前記アプリケーション関心事にウィービングされる前記アスペクト関心事のために定義された前記一意識別子を追加するか、削除するか、又は削除されたものとしてマークすることによって実行されることを特徴とするアプリケーションサーバ。
2. 前記ウィービング・エンティティは、前記アスペクト・ウィービングが前記ランタイム・データ内の前記アプリケーション関心事の１つに変化をもたらした場合に、当該１つのアプリケーション関心事を前記一意なアスペクト識別情報と一緒にマークするように構成されることを特徴とする請求項１に記載のアプリケーションサーバ。
3. 前記ウィービング・エンティティは、２つ以上のアスペクトが前記ランタイム・データ内の１つのアプリケーション関心事に適用可能であるならばウィービングのために前記２つ以上のアスペクトのうちの１つの選択し、残りのアスペクトをスキップするポリシーを実施するように構成されることを特徴とする請求項１又は２に記載のアプリケーションサーバ。
4. 前記ウィービング・エンティティは、前記ポリシーが変わった場合に、新たなポリシーに従って前記ランタイム・データ内の前記アプリケーション関心事の前記サービス記述内の一意なアスペクト識別情報を更新することを特徴とする請求項３に記載のアプリケーションサーバ。
5. 前記ウィービング・エンティティは、前記ランタイム・データ内のアプリケーション関心事の１つに対処する複数のアスペクトがウィービングされるならば、当該１つのアプリケーション関心事と一緒に複数の一意なアスペクト識別情報を格納するように構成されることを特徴とする請求項３又は４に記載のアプリケーションサーバ。
6. 前記ウィービング・エンティティは、前記アスペクト関心事の１つが追加されるべきかを決定する場合に前記サービス記述を参照するように構成され、当該１つのアスペクト関心事の機能が前記サービスで既にカバーされているならば、当該１つのアスペクト関心事は前記ランタイム・データ内の前記アプリケーション関心事にウィービングされないことを特徴とする請求項１乃至５の何れか１項に記載のアプリケーションサーバ。
7. 前記アスペクト関心事のリストは、前記アスペクトが前記サービスに追加するアスペクト関心事の個別のリストと、前記アスペクトが前記サービスから除去するアスペクト関心事の別の個別のリストとを含むことを特徴とする請求項１乃至６の何れか１項に記載のアプリケーションサーバ。
8. 前記ウィービング・エンティティは、前記アスペクト・ウィービングが前記ランタイム・データ内の前記アプリケーション関心事の１つに変化をもたらす場合に前記一意な識別情報と一緒に当該１つのアプリケーション関心事をマークするように構成され、同じ一意なアスペクト識別情報を有する異なるアスペクト関心事が別のジョインポイントにおいてウィービングされようとしているならば、前記異なるアスペクト関心事が前記同じ一意なアスペクト情報と一緒に記述されているのでこれを許可することを特徴とする請求項１乃至７の何れか１項に記載のアプリケーションサーバ。
9. 前記一意識別子はタグ又はキーワードを含むことを特徴とする請求項１乃至８の何れか１項に記載のアプリケーションサーバ。
10. サービス（１０８）を管理するために少なくとも１つのリポジトリ（１０４、１０６）と相互作用するアプリケーションサーバ（１０２）によって実施される方法であって、
    前記サービスによってランタイム・データ（１１４）に実装されるアプリケーション関心事（１２０ａ、１２０ｂ）のリスト（１１９）を識別するサービス記述（１２２）をロードするために前記少なくとも１つのリポジトリと相互作用する工程と、
    アスペクト関心事（１２６ａ、１２６ｂ）のリスト（１３２）を識別するアスペクト記述（１２８）にアクセスするために前記少なくとも１つのリポジトリと相互作用する工程であって、アスペクト関心事の前記リストは一意なアスペクト識別情報（１３０）を有し、アスペクト関心事のそれぞれは一意識別子によって識別される、工程と、
    前記サービスの実行中に前記ランタイム・データ内の前記アプリケーション関心事のランタイム・サービス記述（１２２’）を動的に更新する工程とを有し、
    ジョインポイントにおけるアスペクト・ウィービング中に、前記ランタイム・データ内の前記アプリケーション関心事の前記ランタイム・サービス記述の更新は、前記ランタイム・データ内の前記アプリケーション関心事にウィービングされる前記アスペクト関心事のために定義された前記一意識別子を追加するか、削除するか、又は削除されたものとしてマークすることによって実行されることを特徴とする方法。
11. 前記アスペクト関心事のリストは、前記アスペクトが前記サービスに追加するアスペクト関心事の個別のリストと、前記アスペクトが前記サービスから除去するアスペクト関心事の別の個別のリストとを含むことを特徴とする請求項１０に記載の方法。
12. 前記動的に更新する工程は、前記アスペクト・ウィービングが前記ランタイム・データ内の前記アプリケーション関心事の１つに変化をもたらした場合に、当該１つのアプリケーション関心事を前記一意なアスペクト識別情報と一緒にマークする工程を含むことを特徴とする請求項１０又は１１に記載の方法。
13. 前記動的に更新する工程は、２つ以上のアスペクトが前記ランタイム・データ内の１つのアプリケーション関心事に適用可能であるならばウィービングのために前記２つ以上のアスペクトのうちの１つの選択し、残りのアスペクトをスキップするポリシーを実施する工程を含むことを特徴とする請求項１０乃至１２の何れか１項に記載の方法。
14. 前記ポリシーが変わった場合に、新たなポリシーに従って前記ランタイム・データ内の前記アプリケーション関心事の前記サービス記述内の一意なアスペクト識別情報を更新することを特徴とする請求項１３に記載の方法。
15. 前記動的に更新する工程は、前記ランタイム・データ内のアプリケーション関心事の１つに対処する複数のアスペクトがウィービングされるならば、当該１つのアプリケーション関心事と一緒に複数の一意なアスペクト識別情報を格納する工程を含むことを特徴とする請求項１３又は１４に記載の方法。
16. 前記動的に更新する工程は、前記アスペクト・ウィービングが前記ランタイム・データ内の前記アプリケーション関心事の１つに変化をもたらす場合に前記一意な識別情報と一緒に当該１つのアプリケーション関心事をマークする工程を含み、同じ一意なアスペクト識別情報を有する異なるアスペクト関心事が別のジョインポイントにおいてウィービングされようとしているならば、前記異なるアスペクト関心事が前記同じ一意なアスペクト情報と一緒に記述されているのでこれを許可することを特徴とする請求項１０乃至１５の何れか１項に記載の方法。
17. 前記動的に更新する工程は、前記アスペクト関心事の１つが追加されるべきかを決定する場合に前記サービス記述を参照する工程を含み、当該１つのアスペクト関心事の機能が前記サービスで既にカバーされているならば、当該１つのアスペクト関心事は前記ランタイム・データ内の前記アプリケーション関心事にウィービングされないことを特徴とする請求項１０乃至１６の何れか１項に記載の方法。
18. 前記一意識別子はタグ又はキーワードを含むことを特徴とする請求項１０乃至１７の何れか１項に記載の方法。
19. サービス（１０８）を管理するためのシステム（１００）であって、
    少なくとも１つのリポジトリ（１０４、１０６）と、アプリケーションサーバ（１０２）とを備え、
    前記少なくとも１つのリポジトリ（１０４、１０６）は、前記サービスによって実装されるアプリケーション関心事（１２０ａ、１２０ｂ）のリスト（１１９）を識別するサービス記述（１２２）を格納し、
    前記少なくとも１つのリポジトリ（１０４、１０６）は、アスペクトによって実装されるアスペクト関心事（１２６ａ、１２６ｂ）のリスト（１３２）を識別するアスペクト記述（１２８）も格納し、アスペクト関心事の前記リストは一意なアスペクト識別情報（１３０）を有し、アスペクト関心事のそれぞれは一意識別子によって識別され、
    前記アプリケーションサーバ（１０２）は、
    前記サービスによってランタイム・データ（１１４）に実装されるアプリケーション関心事（１２０ａ、１２０ｂ）の前記リスト（１１９）を識別する前記サービス記述（１２２）をロードように構成された合成エンティティ（１１０）と、
    アスペクト関心事（１２６ａ、１２６ｂ）のリスト（１３２）を識別するアスペクト記述（１２８）にアクセスするために前記少なくとも１つのリポジトリと相互作用するように構成されたウィービング・エンティティ（１１６）であって、アスペクト関心事の前記リストは一意なアスペクト識別情報（１３０）を有し、アスペクト関心事のそれぞれは一意識別子によって識別される、ウィービング・エンティティ（１１６）とを備え、
    前記ウィービング・エンティティは、前記サービスの実行中に前記ランタイム・データ内の前記アプリケーション関心事のランタイム・サービス記述（１２２’）を動的に更新するように構成され、ジョインポイントにおけるアスペクト・ウィービング中に、前記ランタイム・データ内の前記アプリケーション関心事の前記ランタイム・サービス記述の更新は、前記ランタイム・データ内の前記アプリケーション関心事にウィービングされる前記アスペクト関心事のために定義された前記一意識別子を追加するか、削除するか、又は削除されたものとしてマークすることによって実行されることを特徴とするシステム（１００）。
20. 前記ウィービング・エンティティは、前記アスペクト・ウィービングが前記ランタイム・データ内の前記アプリケーション関心事の１つに変化をもたらした場合に、当該１つのアプリケーション関心事を前記一意なアスペクト識別情報と一緒にマークするように構成されることを特徴とする請求項１９に記載のシステム。
21. 前記ウィービング・エンティティは、２つ以上のアスペクトが前記ランタイム・データ内の１つのアプリケーション関心事に適用可能であるならばウィービングのために前記２つ以上のアスペクトのうちの１つの選択し、残りのアスペクトをスキップするポリシーを実施するように構成されることを特徴とする請求項１９又は２０に記載のシステム。
22. 前記ウィービング・エンティティは、前記ポリシーが変わった場合に、新たなポリシーに従って前記ランタイム・データ内の前記アプリケーション関心事の前記サービス記述内の一意なアスペクト識別情報を更新することを特徴とする請求項２１に記載のシステム。
23. 前記ウィービング・エンティティは、前記ランタイム・データ内のアプリケーション関心事の１つに対処する複数のアスペクトがウィービングされるならば、当該１つのアプリケーション関心事と一緒に複数の一意なアスペクト識別情報を格納するように構成されることを特徴とする請求項２１又は２２に記載のシステム。
24. 前記ウィービング・エンティティは、前記アスペクト関心事の１つが追加されるべきかを決定する場合に前記サービス記述を参照するように構成され、当該１つのアスペクト関心事の機能が前記サービスで既にカバーされているならば、当該１つのアスペクト関心事は前記ランタイム・データ内の前記アプリケーション関心事にウィービングされないことを特徴とする請求項１９乃至２４の何れか１項に記載のシステム。
25. 前記アスペクト関心事のリストは、前記アスペクトが前記サービスに追加するアスペクト関心事の個別のリストと、前記アスペクトが前記サービスから除去するアスペクト関心事の別の個別のリストとを含むことを特徴とする請求項１９乃至２４の何れか１項に記載のシステム。
26. 前記ウィービング・エンティティは、前記アスペクト・ウィービングが前記ランタイム・データ内の前記アプリケーション関心事の１つに変化をもたらす場合に前記一意な識別情報と一緒に当該１つのアプリケーション関心事をマークするように構成され、同じ一意なアスペクト識別情報を有する異なるアスペクト関心事が別のジョインポイントにおいてウィービングされようとしているならば、前記異なるアスペクト関心事が前記同じ一意なアスペクト情報と一緒に記述されているのでこれを許可することを特徴とする請求項１９乃至２５の何れか１項に記載のシステム。
27. 前記一意識別子はタグ又はキーワードを含むことを特徴とする請求項１９乃至２６の何れか１項に記載のシステム。
28. サービス（１０８）を提供するアプリケーションサーバ（１０２）と相互作用するリポジトリ（１０４）であって、
    前記サービスによって実装されるアプリケーション関心事（１２０ａ、１２０ｂ）のリスト（１１９）を識別するサービス記述（１２２）を格納するための記憶装置を備え、
    アプリケーション関心事のそれぞれは一意識別子によって識別されることを特徴とするリポジトリ（１０４）。
29. 前記記憶装置は、アスペクト（１２４）によって実装されるアスペクト関心事（１２６ａ、１２６ｂ）のリスト（１３２）を識別するアスペクト記述（１２８）を更に格納し、アスペクト関心事の前記リストは一意なアスペクト識別情報（１３０）を有し、アスペクト関心事のそれぞれは一意識別子によって識別されることを特徴とする請求項２８に記載のリポジトリ。
30. 前記一意識別子はタグ又はキーワードを含むことを特徴とする請求項２８又は２９に記載のリポジトリ。
31. サービス（１０８）を提供するアプリケーションサーバ（１０２）と相互作用するリポジトリ（１０４）によって実施される方法であって、
    前記サービスによって実装されるアプリケーション関心事（１２０ａ、１２０ｂ）のリスト（１１９）を識別するサービス記述（１２２）を格納する工程を有し、
    アプリケーション関心事のそれぞれは一意識別子によって識別されることを特徴とする方法。
32. アスペクト（１２４）によって実装されるアスペクト関心事（１２６ａ、１２６ｂ）のリスト（１３２）を識別するアスペクト記述（１２８）を格納する工程を更に有し、アスペクト関心事の前記リストは一意なアスペクト識別情報（１３０）を有し、アスペクト関心事のそれぞれは一意識別子によって識別されることを特徴とする請求項３１に記載の方法。
33. 前記一意識別子はタグ又はキーワードを含むことを特徴とする請求項３１又は３２に記載の方法。
34. コンピュータで実行された場合に前記コンピュータに請求項１０乃至１８、３１及び３３の何れか１項に記載の方法の各工程を実行させるコンピュータ読み取り可能コードを有するコンピュータプログラム。

Images