この章では プロファイル サービス API を使用してカスタム プロファイル プロバイダを開発する方法について説明します。以下の節で構成されています。
OWLCS にはプロファイル サービス API である com.bea.wcp.profile.API
が含まれています。この API には複数のプロファイル サービス プロバイダの実装が含まれています。プロファイル プロバイダは、定義されたプロトコルを使用してデータ リポジトリから XML ドキュメントへのアクセスを実行します。デプロイ済み SIP Servlets やその他のアプリケーションが、基盤のプロトコルについて、またはドキュメントが保存されているデータ リポジトリについて認識している必要はありません。カスタム URL を使用してプロファイル データが参照されると、OWLCS はリクエストの処理を正しいプロファイル プロバイダに任せます。
プロバイダは、ドキュメントを操作するのに必要なプロトコル処理を実行します。すべてのプロバイダは XML DOM 形式でドキュメントを処理するため、クライアント コードは、さまざまなタイプのプロファイル データを共通の方法で処理することができます。
API を使用して実装された各プロファイル プロバイダには、プロファイル データに対して次の操作が可能になります。
新しいドキュメントの作成
既存のドキュメントのクエリと更新
ドキュメントの削除
プロファイル ドキュメントの変更の通知を受信するためのサブスクリプションの管理
プロファイル プロバイダを使用するクライアントは、サーブレット コンテキスト属性を通じてプロファイル サービス インスタンスを取得します。次に、適切な URL を確立し、利用できる 1 つのプロファイル サービス API でこの URL を使用してプロファイル データを処理します。プロファイル プロバイダのコンフィグレーションと組み合わされた URL のコンテンツは、OWLCS のプロバイダの実装を決定してクライアントのリクエストを処理します。
以下の節では、カスタム プロファイル プロバイダにプロファイル サービス API インタフェースを実装する方法について説明します。
カスタム プロファイル プロバイダは、エンジン層クラスタにデプロイされた共有の Java EE ライブラリ (一般的に単純な JAR ファイル) として実装されます。プロバイダ JAR ファイルには、少なくとも com.bea.wcp.profile.ProfileServiceSpi
を実装するクラスが含まれる必要があります。このインタフェースは、com.bea.wcp.profile.ProfileService
からメソッドを継承し、プロバイダの登録と未登録で呼び出される新しいメソッドを定義します。
プロバイダ実装に加え、プロバイダがプロファイル データの更新についてサブスクリプション ベースの通知をサポートする場合、com.bea.wcp.profile.ProfileSubscription
インタフェースを実装する必要があります。プロファイル ドキュメントが変更されると、ProfileSubscription
がクライアント サブスクライバに返されます。
『Oracle Fusion Middleware WebLogic Communication Services API Reference』では、プロファイル サービス API の各メソッドについて詳しく説明します。プロファイル サービス インタフェースを実装するときには、以下の注意点とベスト プラクティスに留意する必要があります。
putDocument
、getDocument
と deleteDocument
メソッドには、それぞれ 2 つの個別メソッドシグナチャがあります。メソッドの基本的なバージョンは、処理が行われるドキュメント セレクタだけを渡します。別のメソッド シグナチャは、リクエスタについて明示的な情報が必要となるプロトコルに対してリクエストの送信者のアドレスも渡します。
subscribe
メソッドには、送信者のアドレスを渡すために、そして、時間ベースのサブスクリプションをサポートするために、複数のメソッド シグネチャがあります。
com.bea.wcp.profile.ProfileServiceSpi
にメソッドを実装しない場合は、OperationNotSupportedException を送出する「no-op」メソッドをインクルードします。
com.bea.wcp.profile.ProfileServiceSpi
は、登録と未登録で呼び出されるプロバイダ メソッドを定義します。プロバイダはデータ ストアに接続を作成したり、register
メソッドにおいて必要な初期化を実行できます。register
メソッドは、ProviderBean
インスタンスも提供します。このインスタンスには、profile.xml
においてプロバイダのコンフィグレーション要素でコンフィグレーションされたコンテキスト パラメータが含まれています。
unregister
メソッドの場合、プロバイダはバッキング ストア接続をリリースし、保持している状態を消去する必要があります。
プロバイダは、デプロイされたすべての他のアプリケーションが実装にアクセスできる必要があるため、共有 Java EE ライブラリとしてデプロイされる必要があります。
「Creating Shared Java EE Libraries and Optional Packages」を参照してください。ほとんどのプロファイル プロバイダに対して実装クラスを JAR ファイルに簡単にパッケージ化することができます。「Deploying Shared Java EE Libraries and Dependent Applications」の手順に従って OWLCS にライブラリを登録します。
プロバイダをライブラリとしてインストールした後、profile.xml
ファイルにプロバイダとしてプロバイダ クラスも識別する必要があります。name
要素は、プロバイダ コンフィグレーションを一意的に識別し、class
要素は、プロファイル サービス API インタフェースを実装する Java クラスを識別します。プロバイダに対して 1つまたは複数のコンテキスト パラメータを定義することができます。register
メソッドの場合、これらのコンテキスト パラメータが実装クラスに配信されます。たとえば、コンテキスト パラメータは、プロファイル データを取得するために使用するバッキング ストアを識別する可能性があります。
例 13-1 は、XCAP を使用してデータにアクセスするプロバイダのコンフィグレーションのサンプルを示しています。
例 13-1 profile.xml でのプロバイダ マッピング
<profile-service xmlns="http://www.bea.com/ns/wlcp/wlss/profile/300" xmlns:sec="http://www.bea.com/ns/weblogic/90/security" xmlns:xsi="http://www.w3.org/2001/XMLSchema=instance" xmlns:wls="http;//www.bea.com/ns/weblogic/90/security/wls"> <mapping> <map-by>provider-name</map-by> </mapping> <provider> <name>xcap</name> <provider-class>com.mycompany.profile.XcapProfileProvider</provider-class> <param> <name>server</name> <value>example.com</name> </param> ... </provider> </profile-service>
アプリケーションがプロファイル サービス API を使用してリクエストを実行する場合、OWLCS は、そのリクエストを処理するために対応するプロバイダを見つける必要があります。デフォルトでは、OWLCS は、profile.xml
に定義されたプロバイダ name
要素に対して、リクエストされた URL のプレフィックスをマップします。たとえば、例 13-1 に示した基本的なコンフィグレーションでは、OWLCS は、xcap://
で始まるプロファイル サービス API リクエストをプロバイダ クラス com.mycompany.profile.XcapProfileProvider にマップします。
または、名前を付けた各プロバイダに対応するプレフィックスをまとめた profile.xml
にある mapping
エントリを定義することができます。例 13-2 は 2 つの代替プレフィックスを使ったマッピングを示します。
例 13-2 複数のプレフィックスへのプロバイダのマッピング
... <mapping> <map-by>prefix</map-by> <provider> <provider-name>xcap</provider-name> <doc-prefix>sip</doc-prefix> <doc-prefix>subscribe</doc-prefix> </provider> <by-prefix> <mapping> ...
profile.xml
の明示的なマッピング機能が不十分な場合は、com.bea.wcp.profile.ProfileRouter インタフェースを実装するカスタム マッピング クラスを作成し、そのクラスを map-by-router
要素で識別することができます。例 13-3 はコンフィグレーションの例を示します。
profile.xml
ファイルを作成または変更するには、Administration Console を使用することができます。この場合、ドメインに対して config.xml
ファイルのプロファイル プロバイダ コンソール拡張を有効化する必要があります。
例 13-4 config.xml でのプロファイル サービス リソースの有効化
... <custom-resource> <name>ProfileService</name> <target>AdminServer</target> <descriptor-file-name>custom/profile.xml</descriptor-file-name> <resource-class>com.bea.wcp.profile.descriptor.resource.ProfileServiceResource</resource-class> <descriptor-bean-class>com.bea.wcp.profile.descriptor.beans.ProfileServiceBean</descriptor-bean-class> </custom-resource> </domain>
プロファイル プロバイダ拡張は、コンソールの左ペインで Sipserver ノードの下に表示されます。このプロファイル プロバイダ拡張で新しいプロバイダ クラスとマッピング動作のコンフィグレーションを実行することができます。