ホワイト ペーパー : 仮想コンテンツ リポジトリへのコンテンツの統合
|
 |
 |
|
ポータルは、エンタープライズ アプリケーションやエンタープライズ コンテンツの集約、配信、公開に役立つ、極めて効率的なメカニズムを提供します。しかし、効率的な集約メカニズムがなければ、エンタープライズ ポータルを複数の異種リポジトリに接続する際に、コストや複雑な手順に悩まされるおそれもあります。
これは大企業の多くに共通する問題です。Forrester の調査によると、78% の企業が複数のコンテンツ リポジトリを保有しており、うち 43% の企業が 6 つ以上保有しています。いずれの企業でも、このような多くのリポジトリが、エンタープライズ コンテンツ管理システム、ビジネス アプリケーション、または独自のソリューションで構成されています。
WebLogic Portal は、複数の種類の異なるコンテンツ リポジトリへのプラグインを実現する、仮想コンテンツ リポジトリ (VCR) を提供します。FileNet、Documentum、FatWire などの主な ECM ベンダは、この VCR にプラグインするための統合ツールまたはコンテンツ サービス プロバイダ実装ツールを構築しています。それによって、パーソナライズされたコンテンツを WebLogic Portal から配信できるようにしています。
Portal を使用すると、複数のリポジトリに存在するコンテンツのブラウズおよび管理も可能になります。さまざまなリポジトリの複雑性を理解する必要があった従来に比べ、ポータル開発者は 1 つの共通の API を習得するだけでよいため、コストも削減できます。ただし、独自のソリューションを使用している場合などは、独自のコンテンツ SPI 実装ツールの作成が必要となることもあります。このドキュメントでは、この作業を達成するために必要な背景情報を提供します。
BEA 仮想コンテンツ リポジトリ (VCR) は、既存のコンテンツ リポジトリを BEA WebLogic Portal にプラグインする作業を簡易化するように設計されています。既存のリポジトリを VCR に追加することで、Portal の対話管理、コンテンツの串刺し検索、コンテンツ管理ツールといったすべての機能を、既存のコンテンツに対して活用できるようになります。
このドキュメントの目的は、BEA コンテンツ管理 SPI を実装し、それを VCR にプラグインするための必要手順を伝達することです。この SPI は、特定の基幹アーキテクチャやデータ ソース、あるいはプロトコルに連結すべきものではありません。つまり、この SPI は、データベース中心のリポジトリ、ファイルシステムベースのリポジトリ、ネットワーク プロトコルベースのリポジトリを含む広範な実装環境に適用できるようになっています。
SPI の実装は WebLogic Portal Server エンタープライズ アプリケーション内で実行し、クラスタ化したり、さまざまなコンフィグレーション パラメータを使って何度もデプロイすることができます。SPI の実装担当者は、計画している実装方法が WebLogic Portal のスケーラビリティとパフォーマンスにどのように影響するかを理解しておく必要があります。このホワイト ペーパーでは、各種の実装方法において、全般的なスケーラビリティに悪影響を与える可能性のある考慮すべき局面について説明します。
SPI ドメインは、値オブジェクトの集合を囲むようにモデリングされます。これらの値クラスを作成、読み込み、更新、削除するには、一連のサービス インタフェースを使用します。サービス インタフェースは、SPI 実装へのゲートウェイである一連のリポジトリ接続インタフェースを通して利用できます。
このモデルは、限られた機能に対して可能な限りオープンであろうとし、SPI の実装に依存することによって、リポジトリで許可されていない操作が行われた場合に適切な例外を発行します。たとえば、SPI で「フォルダ」に「コンテンツ」を追加する操作が許可されていても、リポジトリで許可されていない場合は、そのことを示す RepositoryException が SPI で生成されます。
メソッドがまったく実装されていない場合は、UnsupportedRepositoryOperationException が生成されます。BEA コンテンツ SPI の実装には、com.bea.content.spi に一覧されているリポジトリ接続インタフェースとサービス インタフェースの実装が必要となります。
コンテンツの値オブジェクトはノードで構成されており、各ノードには、その形式を定義するプロパティと ObjectClass が含まれます。値オブジェクトは SPI のクライアントに対するインメモリ オブジェクトであるため、サービス インタフェースを介してのみ更新できます。com.bea.content では、値クラスのデフォルトの実装について説明しています。デフォルトの実装は必要に応じて拡張することができます (非推奨)。
ContentEntity は、ほとんどの値クラスのスーパークラスです。すべてのサブクラスがシリアライズされて、ユニークな ID を持つように指定します。
ID は、システム内の ContentEntity をユニークに識別します。ID は、管理レイヤで使用される repositoryName と、リポジトリ レイヤで使用される UID の両者で構成されます。管理レイヤにより、システム内に存在する ContentEntity が参照されたときに、ID が NULL でないことだけでなく、その UID も NULL でないことが保証されます。
これは他のノードおよびプロパティ用のコンテナです。ノードのタイプには、階層とコンテンツがあります。階層ノードには、階層ノードとコンテンツ ノードの両方を含めることができますが、コンテンツ ノードには他のコンテンツ ノードしか含めることはできません。
ノードには、createDate、createdBy、modifiedDate、ModifiedBy など、Node クラスに直接定義されたいくつかのシステム プロパティが含まれます。また、ユーザまたはアプリケーションによって定義された Property オブジェクトも含まれます。ノードに Property オブジェクトを含めるには、そのノードに関連付けられた ObjectClass (定義については後述の説明を参照) がノード内に存在している必要があります。
プロパティは、0 個以上の値オブジェクトが含まれる名前の値の組み合わせです。これに関連付けられた PropertyDefinition は、プロパティの形式を定義します。この関連付けは、名前に基づく暗黙的な関係を示します。
これは実値の一般的なラッパーで、BinaryValue、Boolean、Calendar、Float、Long、または String になります。
BinaryValue には、実際のバイナリであるバイト配列のほか、バイナリ名、MIME タイプ、およびサイズが含まれます。パフォーマンス上の理由により、BinaryValue には必ずしも実際のバイトが含まれるとは限りません。SPI のコンシューマが実際のバイトを取得するには、NodeOps サービス インタフェースを使用する必要があります。
ObjectClass はノードのスキーマを定義し、リポジトリ内でノードをユニークに識別する名前と PropertyDefinition の配列を保持します。ObjectClass はスタンドアロン型であり、継承構造または包含構造を持ちません。
したがって、SPI を実装するリポジトリに継承モデルまたは包含モデルが含まれる場合は、要求された ObjectClass を、すべてのスーパー ObjectClass のすべての PropertyDefinition を保持する単一の ObjectClass に変換する必要があります。複数のノードが 1 つの ObjectClass に関連付けられている場合は、慎重に更新を行わないと、望みどおりの結果にならない場合があります。
各 ObjectClass には、プライマリ PropertyDefinition を含めることができます。これにより、モデルがコンテンツなのかメタコンテンツなのかを区別できます。プライマリ PropertyDefinition は、真のコンテンツを表すノードのプロパティを示します。
PropertyDefinition は、名前、タイプ、単一値か多値か、読み込み専用か、必須か、などのプロパティの形式を定義します。さらに、一連の PropertyChoice とプロパティ値がそれらの選択肢に制限されるかどうかも定義する場合があります。PropertyDefinition の妥当性は、いくつかの例外を除いて、SPI の実装に委ねられます。管理レイヤには、以下のルールを設定する必要があります。これは、これらのルールがクラス構造に設定されていなくても必要です。これらのルールは PropertyDefinition の作成時に管理レイヤによって強制的に適用されます。SPI 実装から取得した PropertyDefinition (および対応するプロパティ) に関して各条件が真でなければ、値モデルは有効と見なされません。
プロパティの選択値と、その値がプロパティのデフォルトであるかどうかを定義します。PropertyChoice には、プロパティでサポートされている任意のタイプを使用できます。
サービス インタフェースは、値インタフェースに CRUD (ノードの作成やノードに対するプロパティの更新など) を実行する際に使用されます。 サービス インタフェースは一般に、Node ID などのエンティティの ID に対して動作します。この ID は、UID、データベース ID、または要素パス (リポジトリ内でユニークにパスを識別している場合のみ) になります。
サービス インタフェースはトランザクション対応 (必要な場合) であり、スレッド セーフでスケーラブルであることが望まれます。実装方法には、すべてのサービス インタフェースを一度に実装する方法と、インタフェースごとに個別に実装する方法があります。サービス メソッドはすべて、標準の com.bea.content.RepositoryException を送出します。SPI にも、RepositoryException から継承されたいくつかの標準の例外が含まれます。
NodeOps は、ノードとそのプロパティの操作に使用されるサービス インタフェースです。これには、作成、更新、削除、コピー、移動、名前変更などがあります。
ObjectClassOps は、ObjectClass とその PropertyDefinition および PropertyChoice の操作に使用されるサービス インタフェースです。これには、作成、更新、および取得などがあります。
SearchOps は、ノードの検索に使用されるサービス インタフェースです。検索は、com.bea.content.expression で定義されている Search オブジェクトと、com.bea.p13n.expression パッケージに記載される式構造に基づいています。
検索は、式に含まれるプロパティの定義と ObjectClass の定義、またはそのどちらかに一致するすべてのノードに対して実行されます。システム プロパティには検索で使用できるものもあり、これらは Search クラスで定義されます。http://edocs.beasys.co.jp/e-docs/wlp/docs70/dev/exppkg.htm#795355 を参照してください。
リポジトリ接続インタフェースには、Repository、Ticket および PasswordCredential があります。SPI のクライアントがサービスに接続するためには、リポジトリ接続インタフェースが実装されている必要があります。これらのインタフェースを使用することにより、SPI 実装を BEA コンテンツ管理フレームワークにプラグインすることができます。
リポジトリ接続インタフェースは、ユーザ名などの PasswordCredential オブジェクトを受理し、クライアントにさまざまなサービス インタフェースに対するアクセス権を付与します。
Repository は、コンテンツ リポジトリのコンフィグレーションを定義すると共に、Ticket を使ってコンテンツ リポジトリ サービスにアクセスできるようにします。これは、「new」が呼び出されるように J2SE クラスとして実装する必要があります。
Repository の setProperties メソッドは初期化時に呼び出されるため、Repository インスタンスには、チケットが要求される前に必ずコンフィグレーション プロパティが設定されます。Repository の実装は、さまざまなリポジトリに複数のインスタンスをデプロイできるようにコンフィグレーションすることも可能です。
Ticket は、認証済みの Credentials を使って Repository への接続を呼び出した後、クライアントに表示されるインタフェースです。これは、コンテンツ リポジトリ サービスへのゲートウェイです。
Credentials は、コンテンツ リポジトリへのアクセスを試みるユーザの資格を定義します。認証および認可は、どちらもこの Credentials に基づいて行われます。SPI の実装では、ユーザ名に基づいて認証および認可を行う必要があります。これは、PasswordCredential にパスワードが含まれないためです。ユーザ名が NULL の場合は、匿名ユーザに基づいて認証を行います。
ContentManager は必要に応じて SPI を呼び出すということに注意する必要があります。SPI の実装では、遅延ローディングによってもこの機能を利用できますが、SPI またはアプリケーションにとってこの機能が有用である場合は、完全なロードを行うこともできます。
たとえば、getNodes 呼び出しと getNode 呼び出しは、どちらも、プロパティを含まない「軽量」バージョンのノードを返すことも、プロパティを含む「完全」バージョンのノードを返すこともできます。プロパティを含まないノードが返された場合、ContentManager は、プロパティが必要な場合だけ SPI を呼び出してプロパティを取得します。ただし、Binary Property の InputStream は、getBytes() 呼び出しによってのみ返される必要があります。そうしないと、正常に閉じることができません。
以下に、Virtual ContentManager から呼び出されるリポジトリの実装例を示します。
public class RepositoryImpl implements Repository
{
Properties properties;
String name;
public Ticket connect(Credentials credentials)
{
return new TicketImpl(credentials, properties);
}
public Ticket connect(String userName, String password)
{
Subject subject = com.bea.p13n.security.Authentication.
getCurrentSubject();
Credentials credentials = new Credentials(subject);
return new TicketImpl(credentials, properties);
}
public Properties getProperties()
{
return properties;
}
public void setProperties(Properties properties)
{
this.properties = properties;
}
public String getName()
{
return name;
}
public void setName(String name)
{
this.name = name;
}
}
図 2 は、値モデルを示しています。
図 3 は、式モデルを示しています。
SPI を実装したら、コンテンツ管理ツールを使用して、リポジトリをコンフィグレーションする必要があります。一般に、既存のリポジトリには、VCR を接続するための特別なコンフィグレーション パラメータが必要です。これらのプロパティは、BEA Repository を利用できるようにする場合と同様に、キーと値の組み合わせとして管理ツールから追加できます。コンテンツ管理ツールから追加されたプロパティは、接続シーケンスの図に示すように、VCR を既存のリポジトリに接続した時点で、実装されている SPI に渡されます。リポジトリのコンフィグレーションが終了したら、BEA WebLogic Portal で使い始めることができます。SPI の詳細については、『Content SPI JavaDoc』を参照してください。
|
|
|
