レベル: 中級 Claudio Morgia, SOA アーキテクト, IBM
2008年 4月 23日 Apache Lucene とSpring フレームワークを使用してキーワード・プラグインを作成し、WebSphere® Service Registry and Repositoryに全文検索を追加する方法を学習します。
概要
IBM WebSphere Service Registry and Repository (以下 Service Registry ) は、サービス、サービスの関係、サービスのライフ・サイクルに関する技術文書を、ガバナンスされた方法で保管、構成および検索する機能を提供します。Service Registry は、オリジナルの XML フォームに近い形で XML ファイルを簡単に管理するために、従来のリレーショナル・データベース管理システム (RDBMS) に XML データベース・エンジンを積み重ねた階層化データベース技術を使用しています。そのためService RegistryはXML文書のセクション間の論理的な関係(例えば、WSDL ファイルのインターフェース定義とデータ構造記述)を記述し、パーツ間の内部関係を保持できます。また、さまざまな文書およびその論理的なエンティティー間の関係を設定することもできます。
Service Registry では、文書、論理オブジェクト、リレーションシップなどのライフ・サイクルはすべて、ステート・マシンによって定義された、明確かつカスタマイズ可能なプロセスで管理されます。前述の論理エンティティー間の構造的静的関係だけでなく、Service Registry はオントロジー (種別システム) を使用してこれらのエンティティー間の動的関係を作成します。これらの分類により、オブジェクト間のセマンティックな関係が構築されます。
その他の関連機能としては、Service Registryでは、構造的関係とセマンティック関係の両方を使用し、XPathのような言語でオブジェクトのネットワークをナビゲートして文書や論理エンティティーを検索することができます。ただし、Service Registry は全文検索機能を備えていないので、今のところ、キーワード検索やその他の拡張検索を行うことはできません。
この論文では、拡張性フレームワークと、Apache Lucene および Springフレームワークという 2つのオープン・ソース・プロジェクトを使用して、Service Registry に全文検索機能を導入する方法を紹介します。2つのソリューション・シナリオを使用して、実装しやすさと統合の広汎性の間のトレードオフを説明します。両ソリューションのプラグイン・コードは、Download セクションから入手できます。
技術的な実装を完全に理解するには Java™ の知識がある程度必要ですが、一般的な説明を読むには特に必要ありません。
Service Registry 拡張性フレームワーク
Service Registry は拡張性フレームワークを備えており、製品自体の内部動作を拡張するプラグインを開発できます。プラグイン・メソッドは文書処理 (作成、更新および削除。以下 CRUD 操作) の特定の段階で呼び出され、暗黙的にオブジェクトの変更を許可または拒否するためのものです。
Service Registryでは3種類のプラグインが使用できます。
-
検証プラグイン：CRUD 操作が実行される直前に呼び出され、オブジェクトはまだ永続化されていないので、ストレージ域に到達する前に変更できます。
-
変更プラグイン：CRUD 操作の実行直後に呼び出され、オブジェクトに関連する情報を変更できますが、オブジェクト自体を容易に変更することはできません。
-
通知プラグイン：CRUD 操作が完了した後に呼び出され、通知メカニズムを実装するために使用できますが、オブジェクト自体を変更することはできません。
図 1 論理プラグイン構造
新規オブジェクトのプロパティーを作成するために、検証プラグインのオブジェクト表現を変更する機能を活用します。このプロパティーには、処理中のテキスト形式の文書から導き出されたキーワード (静的に関連するトークン) が設定されます。
プロパティー内のサブストリングを検索する XPath の機能を使用し、全文検索へのキーワード・ベースのアプローチを使用して文書を検索できます。
オントロジーを使用したバイナリー文書に対する Xpath 照会の例を以下に示します。
/WSRR/GenericDocument[classifiedByAnyOf(.,'<classification URI>')]
|
一方、全文検索機能を使用すると以下のような照会が可能です。
/WSRR/GenericDocument[classifiedByAnyOf(.,'<classification URI>') and matches(@keywords,'.*<my keyword>.*') ]
おわかりのように、2番目の照会はオントロジー (classifiedByAnyOf) と全文検索ベースの述部の両方を使用して、2つの検索方法 (オントロジーと全文検索) を統合しています。重要なのは述部のmatchesです。これにより、1つの属性 (またはすべての属性) に対する正規表現のマッチングを行うことができます。
検証プラグインの役割は、サブミットされた文書からキーワードを抽出し、属性キーワードに格納し、マッチング演算子と XPath にその後の処理を実行させることです。
Luceneによる索引付け
次の課題は、文書を分析し、文書から関連するトークンを統計的に抽出し、Service Registry が使用できるようにする再利用可能なよい方法を見つけ出すことです。そのために Apache Lucene を使用します。具体的には、トークン抽出という索引付け機能に付随する主要な動作を使用します。
Lucene が索引付けのために文書を処理する場合、分析 (トークン化) を行います。この分析は複雑で言語に依存しますが、文書内のトークンとその頻度のマップを作成します。私たちはLucene 索引付けのこの段階で中断して、2つの異なる実装方法を使用してトークンを抽出しますが、結果は同じになります。
注意する必要があるのは、このソリューションでは PDF から Word や Excel の文書まで、多くのさまざまなビジネス文書の索引付けを有効にする必要があることです。Lucene ではプレーン・テキスト文書のみ索引付けができるので、上記のようなさまざまな文書形式からプレーン・テキストを抽出して Lucene に取り込む方法が必要です。(当然ながら、XML ファイルはプレーン・テキストなので変換する必要はありません。) この抽出を行うために、その他の 2 つのオープン・ソース・プロジェクトを利用します。
- Word や Excelなどの Microsoft™ 文書を取り扱うための Apache POI
- PDF 文書を取り扱うための PDFBox
図2 は、一般的な索引付けプロセスを示します。
図 2 索引付けプロセス
同じ論理スキームが、メモリー・ベースおよび Spring ベースの実装の両方に適用されます。2 番目のシナリオでは、文書変換と索引付けエンジン・コンポーネント、そのサブコンポーネントは、記述子を使用して外部で定義され、Spring を使用してインスタンス化されます。
非常に高速な Lucene のメモリー内索引付け
Lucene メモリー内アプローチは、RAM ベースのストレージと、非常に高速な文書アナライザーを組み合わせて、カスタマイズしやすさと引き換えに高度に最適化された実装を実現します。基本的に、RAM ベースのストレージは、インデックス・ファイルが RAM に保持されるため、異なるアプリケーション間で共有することはできません。これらの索引はプライベートであり、手の込んだアクセス制御方法は必要ありません。高度に最適化された実装により Lucene のカスタマイズの柔軟性は低下しますが、非常に高速な索引付けエンジンが提供されます。
さまざまなアプリケーション間で索引を共有する必要がない場合は、索引付けエンジンの構造を外部的に宣言する機能を考慮せず、Service Registry に全文検索を提供することにのみ関心を向けることができます。
索引を共有する必要があれば、以下をお読みください。
Springフレームワークによる秩序
前のソリューションの欠点の 1 つは、コーディング面でパフォーマンスとコードの複雑さに影響を与えることなく、柔軟性を提供する簡単な方法がないことです。基本的に変換フローはハードコーディングされるため、ある種の柔軟性フレームワークを提供しない限り、簡単に変更することはできません。
Springフレームワークの非常に興味ある機能は、制御反転の原則 (ハリウッドの原則とも呼ばれ、「Don't call me, I'll call you (後でこちらから連絡します、という体のよい断り方)」と同じ) の実装です。この原則は、明示的な参照を通じてコンポーネントをコードにワイヤリングするのではなく、インターフェースとタイプを通じて依存関係を宣言してコンポーネントを構造化し、その他のコンポーネントが依存関係を解決し、要求されたコンポーネントを要求元コンポーネントに注入するようにします。
コーディング面で、明示的な依存関係がある場合は以下のようなコードになります。
class A {
public void theMethod() {
B dependency = new B();
dependency.someOtherMethod();
}
}
|
上記コードは、以下のように変換できます。
class A {
public void theMethod(B dependency) {
dependency.someOtherMethod();
}
}
|
このように、メソッド・インターフェースによって最初のコード例の暗黙の依存関係を明示化し、実際にBオブジェクトを作成して注入する責任をその他のコンポーネントに移すことができます。これは、コード自体ではなく構成ファイルで駆動することもできます。構成ファイル(Springの場合は XML 記述子)を変更するだけのこのアプローチを使用して、異なる索引付け方法を使用するようにコンポーネントの実装を変更することができます。
ここではSpringフレームワークおよびそのプログラミング・モデルの詳細には触れずに、基本的な論理ワークフローの要約を示します。
- XML ファイルを作成し、使用する Bean またはコンポーネントおよびそれを使用する方法を記述します。
- コードで、
ApplicationContext または BeanFactory クラスのインスタンスを作成し、参照を XML 記述子に渡します。
- Bean の取得を開始します。
Springフレームワークが Lucene 統合に固有の統合モジュールとプログラミング・モデルを提供することも重要です。これらは、Spring Framework の宣言アプローチとともに使用できる Bean のセットを提供することにより、Lucene アプリケーションの開発を非常に容易にするものです。
私たちは、Spring を使用して索引付けエンジン、ストレージ・タイプ (RAM またはファイル・ベース)、文書変換 (および文書を適切なハンドラーにディスパッチできるようにするために、文書タイプを認識する方法)、および Spring の用語で Spring ユーザーから Lucene API の複雑さをシールドするテンプレート Bean を宣言します。
プラグインの作成
このセクションでは、統合プラグインをコーディングする方法について段階的に学習し、関連するさまざまなフレームワークの技術的な側面について学習します。
グルー・コード
同じ索引付け機能を2つの方法で実装するため、以下に示すように、これらの実装を1つの共通インターフェース (DocumentAnalyzer) を公開するファクトリー (DocumentAnalyzerFactory) で隠蔽します。
package com.ibm.luceneintegration;
public interface DocumentAnalyzer {
public static final int DEFAULT_MAX_TERMS = 50;
String[] getMostFrequentTermsAsArray(String name,byte[] content)
throws Exception ;
String[] getMostFrequentTermsAsArray(String name,byte[] content, int
maxTerms) throws Exception ;
String getMostFrequentTerms(String name,byte[] content) throws
Exception ;
String getMostFrequentTerms(String name,byte[] content, int
maxTerms) throws Exception ;
}
|
インターフェースは、同じメソッドの 4つのバリエーションを提供します。このメソッドは、バイナリー・コンテンツを頻度が最も高いトークンのリストに論理的に変換し、リストの長さを制限します。
パラメーターnameは、拡張子に基づいて文書タイプを推定します。異なる方法で文書タイプを推定することもできますが、簡単にするためにここではファイル名ベースの推定を使用します。
検証プラグイン
Service Registry 検証プラグインは、XPath 混合照会を行うために、DocumentAnalyzerFactory を使用して文書アナライザーを選択し、文書アナライザーを使用して文書の解析とトークン・リストの取得を行い、文書に関連するXML 記述メタデータの属性にトークン・リストを注入します。これを実装する 2つの方法を紹介しますが、プラグイン・インフラストラクチャーに適合するその他の実装も簡単にコーディングできます。
図3 は、簡略化されたバージョンのプラグイン・コードを示します。
図 3 プラグイン・コード
このプラグインでは、コードの説明のために CRUD メソッドの 1つの実装を示します。(3)
渡されたオブジェクトが、XML ベースの技術文書ではなくバイナリー・オブジェクトであることを意味するDocument型の場合は、それを処理する injectProperty メソッドに渡します。このメソッド (2) はコンテンツと文書の名前を取得し、(ファクトリーを通じて)文書アナライザー実装を使用して頻度が最も高いトークンのセットを計算し、最後に setPropertyValue メソッド (1) を呼び出して、keywords属性の値にキーワード・セットのストリング表現を設定します。
非常に高速な RAM ベースの Lucene 実装
この実装は Lucene コアおよび提供されたパッケージ、つまりメモリー内索引付け機能を提供する Lucene Memory に基づいています。図2に示すように、索引付けワークフローには以下が含まれます。
- 文書トークン化。これはバイナリー文書を文書のコンテンツの大部分を含むプレーン・テキストに変換する段階です。
- 索引付けエンジン。プレーン・テキスト (バイナリー文書から導き出される) を統計的に解析し、頻度でソートされたトークンのリストを計算します。
この実装では、最初のステップは Converter クラスを使用して実現されます (見やすくするためにここにはそのクラスを示しませんが、付属するソースに用意されています)。Converter クラスは文書名 (ファイル名から導き出される) から拡張子を抽出し、その拡張子を使用して文書を以下の適切なテキスト・エクストラクターにディスパッチします。
- Microsoft Excel および Word 文書用の Apache POI
- PDF 文書用の PDFBox
- RTF 文書用の Java Swing
AnalyzerUtil クラス (Lucene Memory パッケージから) は、プレーン・テキストから頻度が最も高い用語を抽出するために使用されます。このクラスは、処理中の一時的な索引を直接 RAM に作成します。このため非常に高速な索引付け操作を行うことができますが、それ以降の操作のために索引にアクセスすることはできません。
Spring ベースの実装
Spring 実装は、それぞれが特定の機能を提供する、いくつかのコンポーネントの使用法に基づいています。
- 制御反転パターンおよび宣言アプローチを活用するための Springフレームワーク
- Spring および Lucene 統合のための Springモジュール
- 索引付けエンジンのための Luceneコア
- PDF 文書を取り扱うための PDFBox
- Microsoft Word および Excel 文書を取り扱うための Apache POI
Springフレームワークは、図4の簡単な例に示すような XML 記述子文書を使用して構成されます。
図 4 サンプル Spring 構成ファイル conf.xml
構成ファイルは、論理的に 4つの主な部分に分けることができます。
- ストレージBean：索引のストレージ域を定義します。上の例では、RAM ベース (セッションのみ) およびファイルシステム・ベース (永続的) の 2 つがあります。
- 索引付けエンジン：テキスト解析 (アナライザー) の方法、および索引を記録する索引ストレージを定義します。
- 文書変換：文書タイプを推定する方法 (上の例では拡張子に基づいていますが、この方法は変更可能です) および特定の文書タイプをプレーン・テキストに変換する文書ハンドラーをマップします。
- テンプレート：Lucene API をより簡単なプログラミング・モデルにラップし、索引付けエンジンにリンクされるオブジェクト・ファサード。
これらの Bean は、依存関係注入メカニズムを使用して関連付けられます。
- 索引付けエンジン (
IndexFactory Bean) は Directory 型のプロパティーを持ち、Directory型である 2つのストレージ Bean のどちらかが設定されます。
- テンプレート・コンポーネントは、索引付けエンジンに由来する
IndexFactory 型のプロパティーを持ち、その値が設定されます。
Bean のプロパティー値として参照を使用するとき、実際にはコンポーネントを関連付けるためにグルー・コードを作成せずに、依存関係を注入しています。
おわかりのように、文書ハンドラー・マネージャー Bean はテンプレートにリンクする必要がありますが、どのBean にも直接リンクされていません。これは、Spring モジュール・コンポーネントのコードの不具合のためです。
Spring オブジェクト (ApplicationContext または BeanFactory) はこの構成ファイルを使用して Bean を作成し、依存関係を注入し、ここでは示していないその他の多くのことができます。
おわかりのように、Spring ベースの実装のためのコードは、基本的に ApplicationContext を使用して Spring コンポーネントを初期化し、使用する Bean を取得します。
ctx = new ClassPathXmlApplicationContext("conf.xml");
mgr = (DocumentHandlerManager)ctx.getBean("documentHandlerManager");
template = (LuceneIndexTemplate)ctx.getBean("template");
|
以下に示すように、各文書の処理にあたって文書ハンドラー・マネージャー Bean は自動的に文書タイプを推定し、適切な文書ハンドラーに送付してプレーン・テキストを抽出します。
Document doc = mgr.getDocumentHandler(name).getDocument(new HashMap(),
new ByteArrayInputStream(content));
Field contents = doc.getField("contents");
Field myContents = new Field("contents",contents.stringValue(),
Store.YES,Index.TOKENIZED,TermVector.YES);
doc.removeField("contents");
doc.add(myContents);
|
最初の行によって、外部化された文書ハンドラー・マネージャーの構成が使用できるようになります。Spring の利点は、プラグイン・コードが取り扱える文書タイプをまったく意識しないことであり、この設定は既存のプラグイン・コードに影響を与えずに、宣言によって簡単に変更できます。
その他の行は、文書ハンドラー・マネージャーのデフォルト動作を取り扱います。文書ハンドラー・マネージャーは、Document オブジェクトを索引付けできるものとしては作成せず、解析できるものとしてのみ作成します。このため、頻度が最も高い用語のリストを取得することはできません。したがって、コードはコンテンツ・フィールドを取得し、索引付けが可能な新しいフィールドを作成します。
次に、文書が Template オブジェクトに送られ、構成ファイルに指定された索引付けエンジンを使用して実際の索引付けが行われます。テンプレート・プログラミング・モデルでは、文書が挿入されると、コールバック・メソッドを使用して索引を読み込むことができます。私たちの実装では、このメソッドは索引にアクセスし、用語と頻度のvectorを取得してSrtedMapに渡します。それによって以下に示すように、頻度によるソートが保証され、頻度順の用語のサブセットを抽出することができます。
int docNumber = reader.termDocs().doc();
TermFreqVector[] freqs = reader.getTermFreqVectors(docNumber);
TermFreqVector vector = freqs[0];
int[] frequencies = vector.getTermFrequencies();
String[] terms = vector.getTerms();
SortedMap<Integer, String> map = new
TreeMap<Integer,String>(Collections.reverseOrder());
for (int i=0; i<vector.size(); i++) {
map.put(new Integer(frequencies[i]), terms[i]);
}
|
順序付けられたマップが得られたら、いくつかの用語を抽出して、1つのストリングとして書き出すことができます (これはグルー統合コードによって実行されます)。
プラグインのデプロイ
このセクションでは、Eclipse でプラグインをデプロイし、アプリケーション・サーバーを構成し、プラグインを Service Registry にロードし、ソリューションをテストする方法について学習します。
Eclipse へのプラグインのインポート
Service Registry ランタイム・クライアント以外のすべての依存関係をバンドルした wsrrplugin.zip に収められている、プラグイン・ソース・プロジェクトをダウンロードしたら、以下のステップを実行することにより Eclipse環境にインポートできます。
- 空のワークスペースを指定して Eclipse を開始します。
- Eclipse で File => Importを選択します。
- Import ダイアログで、図 5 に示すように General => Existing Projects into
Workspace を選択し、Nextを選択します。
図 5 インポート・タイプの選択
- 図 6に示す Import Projects ダイアログで、ダウンロードしたアーカイブ・ファイルを表示します。Eclipse により、そのファイルに含まれているプロジェクトだけが自動選択されます。
図 6 アーカイブ・ファイルの選択
- Finish をクリックしてプロジェクトをビルドします。最終的なワークスペースは図 7 のようになります。
図 7 初期ワークスペース
WSRRplug-inExport.jardesc を右クリックし、Open JAR Packager を選択してバイナリー・プラグイン JAR ファイルを生成します。- JAR File Specification ダイアログで、図 8 に示すように適切な JAR ファイル名を選択して、Finish をクリックします。
図 8 JAR ファイルの指定
アプリケーション・サーバーの構成
プラグインを実行するには、このセクションで説明するように特にクラスパスに関してアプリケーション・サーバーの構成をカスタマイズする必要があります。プラグインをテストするために記述されたソリューションを使用することはできますが、ある種類のクラスパス操作が必要なために、実稼働環境では使用しないでください。
ソリューションをテストするには、この論文からダウンロードできる以下のアーカイブ・ファイルが必要です。
- プラグイン・コードが収められている wsrrplugin.zip
- ランタイム依存関係が収められている WSRRFullTextDependencies.zip。このファイルを、Service Registry が実行されているマシン上のディレクトリーに unzip します。例えば、Linux プラットフォームでは、/usr/local/WSRRplug-inDependencies というディレクトリーを作成し、以下のコマンドを使用して依存関係アーカイブを unzip できます。
unzip <dependency archive> -d /usr/local/WSRRplug-inDependencies
- ワークスペース・ファイルが格納されている workspace.zip
アプリケーション・サーバーをカスタマイズするには、以下の手順に従います。
- Service Registry をホストするアプリケーション・サーバーがまだ稼働していない場合は始動します。例えば、Service Registry を標準的にインストールした Linux システムでは、以下のコマンドを入力します。
/opt/IBM/WebSphere/AppServer/bin/startServer.sh server1
|
- ブラウザーで http://localhost:9060/ibm/console を表示し、左側のナビゲーションから Servers
=> Application servers を選択し、右側のペインで
server1 を選択します。
- 右側のペインで、Server Infrastructure => Java and Process
Management => Process Definition => Java Virtual Machine.
を選択します。図 9 に示すように、Java Virtual Machine Configuration ダイアログが表示されます。
- ログアウトし、以下のコマンドを入力してサーバーを再始動します。
/opt/IBM/WebSphere/AppServer/bin/stopServer.sh server1
/opt/IBM/WebSphere/AppServer/bin/startServer.sh server1
|
これで、アプリケーション・サーバーは、Service Registry にデプロイできるプラグインをホストするように構成されました。
サービス・レジストリーへのプラグインのロード
ダウンロードするか、Eclipse ワークスペースから作成することにより、プラグイン JAR ファイルが得られます。
- ブラウザーで http://localhost:9080/ServiceRegistry と入力し、Service Registry Webユーザー・インターフェースを開きます。
- 図 10 に示すように Perspective => Configuration を選択します。
図 10 Configuration パースペクティブの選択
- 図 11 に示すように、左側のナビゲーション・ペインで Active Configuration Profile =>
Plug-ins => JARs を選択し、右側のペインで Load JAR Plug-In をクリックします。
図 11 JAR プラグインのロード
- 次のダイアログで、プラグイン・ファイルをブラウズし、WSRRLuceneplug-in のように名前を指定して OK をクリックします。
- Details ペインが表示されたら、左側のペインの Validation Properties を選択します。
- 右側のペインで、図 12 に示すように Validation properties plug-in (ValidationProperties) をクリックします。
図 12 検証プロパティーの選択
- 右側のペインで Content タブを選択し、以下のテキストを探します。
validators=com.ibm.sr.api.SRTemplateValidator,com.ibm.sr.api.SRBusinessModelValidator
|
コンマと以下の値 (新しい統合バリデーターのクラス名) を追加します。
com.ibm.luceneintegration.wsrr.FullTextValidator
|
- OK をクリックします。
バリデーターが有効になり、Service Registry にフックされます。処理する次の文書には新しい属性キーワードが含まれ、Xpath 照会でフルテキスト検索を行うことができます。
ソリューションのテスト
すべてが期待どおりに動作していることを確認するため、以下を行います。
- Service Registry の管理コンソールをAdministrator パースペクティブに切り替えます。
- 左側のナビゲーション・ペインで、Service Documents => Other
Documents を選択し、右側のペインで Load Documents をクリックします。
- 図 13 に示すように、検索する文書 (PDF、Excel または Word) をブラウズし、名前空間、記述、および文書のバージョンを入力して OK をクリックします。
図 13 文書のインポート
- 確認メッセージで Finish をクリックします。
- 文書がロードされると、文書へのリンクがある要約ページが表示されます。このリンクをクリックして、文書記述ページに進みます。
- 文書記述ページで、Properties リンクをクリックします。図 14に示すように Properties ダイアログが表示されます。
図 14 新しいキーワード・プロパティーを持つ文書プロパティー
文書内で見つかった、最も関連するトークンのリストが含まれる新しいキーワード・プロパティーが表示されます。
お楽しみはここから！検索を試してみましょう。
Service Registry Web UI は XPath 照会の作成方法を案内する照会ウィザードを備えていますが、今のところはワイルドカードに対応していないため、新しい検索機能のテストには使用できません。ただし、Service Registry の保存された検索機能を利用することによりこの制限を回避できます。
- 図 15に示すように、Service Registry Web UI の左側のペインでQueries => Query Wizardを 選択してから All Entities を選択し、右側のペインで Next をクリックします。
図 15 照会ウィザードを開く
- 次のダイアログでプロパティー名とプロパティー値に
Dummy を指定し、Next をクリックしてから、Finish をクリックします。
- 照会はおそらく結果を返しませんが、図 16 に示すように照会を保存するオプションが提供されています。Save this Search セクションで
mysearch のように検索の名前を指定し、Save をクリックします。
図 16 照会の保存
- 図17に示すように、左側のペインでMyService Registry => My Saved Searches
=> mysearch を選択します。
図 17 保存された検索の選択
- Details ダイアログで、Additional Properties の下の Properties を選択し、queryExpression をクリックします。
- フルテキスト検索機能を活用するために、マッチング述部を使用して XPath 照会を入力し、OK をクリックします。例えば、前のセクションでインポートした IBM Redbook『SOA Design Using WebSphere Message Broker and WebSphere ESB (US)』 を検索する場合は、
executeQuery プロパティーに以下の Xpath 照会を使用できます。
/WSDL/GenericDocument[matches(@keywords,".*soa.*")]
|
- 図 18 に示すように MyService Registry => My Saved
Searches => mysearch を選択し、Run Search をクリックすることにより照会を再実行します。
図 18 保存された照会の再実行
このプロセスを使用して、オントロジーとフルテキスト照会の両方を使用して統合プラグインをテストできます。以下に例を示します。
/WSRR/GenericDocument[classifiedByAnyOf(.,’<classification URI>’)
and matches(@keywords,’.*<my keyword>.*’) ]
|
要約
この論文では、検索機能を拡張するために Service Registry プラグインを作成する方法について学習しました。具体的には、Service Registry に索引付け機能を追加し、全文検索を行うことができるようにするためにオープン・ソース Apache Lucene プロジェクトを使用する方法を学びました。また、オープン・ソース Spring Framework プロジェクトを使用してプラグイン・コードの構造的な面を外部化し、柔軟性と、宣言により機能を追加および変更する方法についても学習しました。関連する Spring Modules プロジェクトを通じて、簡単な Spring に対応した方法で Lucene とやり取りするために簡略化されたプログラミング・モデルについて学習しました。
学習した手法を使用して、その他多くの機能を追加できます。英語以外の言語を取り扱って、その言語で文書プロパティーや文書を発見するための方法を決定したり、Lucene 照会言語とWikipediaやWordNet® との統合機能を用いてセマンティック検索を統合したりする機能があります。ファイル・ベースのストレージにより索引を永続化すれば、索引を使用して、Service Registry の外部でもその他の照会を行うことができます。
謝辞
著者は、この論文の内容の作成と検証に対する支援に対して、Tim Baldwin と WebSphere Service Registry and Repository 開発チームに謝意を表します。
ダウンロード | 内容 | ファイル名 | サイズ | ダウンロード形式 |
|---|
| プラグイン・アーカイブ・ファイル | wsrrplugin.zip | 9KB | HTTP |
|---|
| 依存関係アーカイブ・ファイル | WSRRFullTextDependencies.zip | 11.8MB | HTTP |
|---|
| ワークスペース・アーカイブ・ ファイル | workspace.zip | 17.5MB | HTTP |
|---|
参考文献 学ぶために
製品や技術を入手するために
著者について  | | | Claudio Morgia はイタリアの IBM Software Group に属する SOA アーキテクトです。複数の大規模なイタリアのクライアントを担当し、特に BPM、サービス管理およびガバナンスの分野で SOA 導入のためのアーキテクチャー上のガイドラインを提供しています。Claudio は以前、ローマにある IBM Tivoli® Lab にソフトウェア設計者として勤め、IBM WebSphere プラットフォームに対する J2EE ベースのソリューションに従事しました。 |
記事の評価
| 
