| Oracle® WebCenter Content Content Server開発者ガイド 11gリリース1(11.1.1) B66702-01 |
|
 前へ |
 次 |
ホーム > Content Server開発者ガイド > RIDCを使用したコンテンツ・サーバーへのアクセス
| Oracle® WebCenter Content Content Server開発者ガイド 11gリリース1(11.1.1) B66702-01 |
|
前へ |
次 |
ホーム > Content Server開発者ガイド > RIDCを使用したコンテンツ・サーバーへのアクセス
この章では、Oracle WebCenter Content Serverとの通信のためのシン通信APIを提供するRemote Intradoc Client (RIDC)の初期化および使用方法について説明します。詳細は、Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンスを参照してください。
Remote Intradoc Client (RIDC)は、Oracle Technology Network (OTN) (http://otn.oracle.com)からダウンロードできます。
|
注意: Remote Intradoc Client (RIDC)バージョン11.1.1.6 (11gR1 PS5)では、Java Runtime Environment (JRE) 1.6以上が必要です。最新のJava JRE/JDKは、Oracle Technology Network (OTN) (http://otn.oracle.com)からダウンロードできます。 |
この章では、次の項目について説明します。
Remote Intradoc Client (RIDC)は、コンテンツ・サーバーとの通信を行うためのシン通信APIです。その主な機能は、コンテンツ・サーバー・サービスをリモートで実行できるようにすることです。さらに、RIDCは、接続プーリング、セキュリティ、プロトコルの固有情報などを処理します。
主な機能
Remote Intradoc Client (RIDC)には次のような機能があります。
Intradocソケットベース通信、およびHTTPプロトコルとJAX-WSプロトコルをサポートします。
コンテンツ・サーバーとのSecure Socket Layer (SSL)通信をサポートします。
ソケットのタイムアウトや接続プールのサイズなどの設定を含むクライアント構成を提供します。
RIDCオブジェクトは、標準のJava Collectionパラダイムに従います。
サポートされているプロトコル
Remote Intradoc Client (RIDC)バージョン11.1.1.6.0は、idc、idcs、http、httpsおよびjax-wsプロトコルをサポートしています。
Intradoc: Intradocプロトコルは、Intradocソケット・ポート(通常は4444)経由でコンテンツ・サーバーと通信します。このプロトコルは、クライアントとコンテンツ・サーバー間の信頼できる接続を必要とし、パスワード検証は行いません。このプロトコルを使用するクライアントには、RIDCコールを行う前に、必要な認証を自身で実行することが求められます。Intradoc通信は、SSL経由で実行するように構成することもできます。
HTTP: RIDCは、Apache HttpClientパッケージを使用して、コンテンツ・サーバーに接続されたWebサーバーと通信します。Intradocとは異なり、このプロトコルでは、各リクエストについて認証資格証明が必要です。HttpClientバージョン3がデフォルトです。ただし、httpClientライブラリのバージョン4も使用できます。詳細は、第23.1.1項「HttpClientライブラリ・バージョン4の使用」を参照してください。また、追加情報については、Apache HttpClient WebサイトのHttpClientホームページで、Jakarta Commons HttpClientのドキュメントを参照してください。
http://hc.apache.org/
JAX-WS: JAX-WSプロトコルは、適切に構成されたコンテンツ・サーバー・インスタンスとRIDCクライアントがインストールされているOracle WebCenter Content 11gでのみサポートされます。JAX-WSは、この環境の外部ではサポートされません。
JAX-WSの詳細は、Oracle Technology Network (OTN)で、『Oracle Fusion Middleware Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド』および『Oracle Fusion Middleware Oracle WebLogic Server JAX-WS Webサービスの高度な機能のプログラミング』を参照してください。また、次のJava Community Process Webサイトで、Java API for XML Web Services (JAX-WS)のドキュメントも参照してください。
http://www.jcp.org/
サポートされているURLフォーマット
次の表に、サポートされているURLフォーマットを示します。
| URL | 説明 |
|---|---|
idc://localhost:4444 |
Intradocポートを使用します。ホスト名とポート番号のみが必要です。 |
idcs://localhost:4443 |
Intradocポート経由でSSLを使用します。SSL証明書をロードするための追加の構成が必要です。 |
http://localhost:16200/cs/idcplg |
コンテンツ・サーバーCGIパスへのURLを指定します。 |
https://localhost:16200/cs/idcplg |
SSL over HTTPを使用します。SSL証明書をロードするための追加の構成が必要です。 |
http://wlsserver:16200/idcnativews |
JAX-WSプロトコルを使用してコンテンツ・サーバーに接続します。 |
必要な環境
次の表は、RIDCが各接続タイプをサポートするために必要な環境についてまとめたものです。
| URL | 説明 |
|---|---|
| idc:// |
|
idcs:/ |
|
http:/ |
|
https:/ |
|
| jax-ws |
|
RIDCは、Apache HttpClientパッケージを使用して、コンテンツ・サーバーに接続されたWebサーバーと通信します。Intradocとは異なり、このプロトコルでは、各リクエストについて認証資格証明が必要です。Remote Intradoc Client (RIDC)バージョン11.1.1.6.0は、HttpClientバージョン3をデフォルトとして使用します。ただし、HttpClientライブラリのバージョン4も使用できます。
また、追加情報については、Apache HttpClient WebサイトのHttpClientホームページで、Jakarta Commons HttpClientのドキュメントを参照してください。
http://hc.apache.org/
JavaコードでHttpClientバージョン4を要求するには、次のコマンドを使用します。
IdcClient idcClient = manager.createClient("http://localhost/idc/idcplg");
idcClient.getConfig ().setProperty ("http.library", "apache4");
JDeveloper拡張機能を使用して新しいRIDCアプリケーションを作成する場合、Configuration Parametersセクションで、接続にapache4という値のhttp.libraryパラメータを追加することができます。RIDC JDeveloper拡張機能の詳細は、第23.11項「RIDC JDeveloper拡張機能の使用」を参照してください。
JDeveloperでSite Studio for External Applications (SSXA)アプリケーションを使用している場合、UIがないため、まず接続を作成し、その接続をテストせずに保存する必要があります。そして、「接続」→ディスクリプタ→ADF META-INFノードのconnections.xmlファイルを開きます。connections.xmlファイルに次のStringRefAddrセクションを追加し(例23-1に示されています)、ファイルを保存します。
例23-1 connections.xmlにおける接続の例
<Reference name="sample"
className="oracle.stellent.ridc.convenience.adf.mbeans.IdcConnection" xmlns="">
<Factory className=
"oracle.stellent.ridc.convenience.adf.mbeans.IdcConnectionFactory"/>
<RefAddresses>
<StringRefAddr addrType="oracle.stellent.idc.connectionUrl">
<Contents>idc://localhost:4444</Contents>
</StringRefAddr>
<StringRefAddr addrType="oracle.stellent.idc.idcServerURL">
<Contents>http://localhost/cs/idcplg</Contents>
</StringRefAddr>
<StringRefAddr addrType="oracle.stellent.idc.http.library">
<Contents>apache4</Contents>
</StringRefAddr>
</RefAddresses>
</Reference>
SSXAとRIDCの接続タイプは類似していることに注意してください。
JDeveloperでSSXA接続を使用する場合、connections.xmlファイルのaddrType値はoracle.stellent.idc.http.libraryです。
JDeveloperでRIDC接続を使用する場合、connections.xmlファイルのaddrType値はoracle.stellent.ridc.http.libraryです。
この項では、Intradoc接続とHTTP接続を初期化するサンプル・コード、およびJAX-WSクライアントを初期化するコードを示します。
例23-2のコードは、Intradoc接続を初期化します。
例23-2 Intradoc接続の初期化
// create the manager
IdcClientManager manager = new IdcClientManager();
// build a client that will communicate using the intradoc protocol
IdcClient idcClient = manager.createClient("idc://localhost:4444");
例23-3のコードは、HTTP接続を初期化します。Intradoc接続との唯一の違いはURLです。
例23-3 HTTP接続の初期化
// create the manager
IdcClientManager manager = new IdcClientManager();
// build a client that will communicate using the HTTP protocol
IdcClient idcClient = manager.createClient("http://localhost:16200/idc/idcplg");
例23-4のコードは、JAX-WSクライアントを初期化します。URLにはidcnativews Webコンテキスト・ルートが含まれることに注意してください。このWebコンテキスト・ルートは(デフォルトで)、コンテンツ・サーバーによって公開される2つのWebサービス(loginサービスとrequestサービス)で使用されます。
クライアントの構成は、クライアントの作成後に実行できます。構成パラメータには、ソケットのタイムアウトや接続プールのサイズなどの設定が含まれます。構成はプロトコル固有のものです。つまり、IdcClientオブジェクトを特定のタイプにキャストする場合、そのタイプのプロトコル構成オブジェクトを取得できます。
Intradoc接続のためのクライアント構成
例23-5のコードは、Intradoc接続のためのソケット・タイムアウトおよび待機時間を設定します。
例23-5 Intradoc接続のためのクライアント構成
// build a client as cast to specific type
IntradocClient idcClient =
(IntradocClient)manager.createClient("http://localhost/idc/idcplg");
// get the config object and set properties
idcClient.getConfig().setSocketTimeout(30000); // 30 seconds
idcClient.getConfig().setConnectionSize(20); // 20 connections
SSLの構成
Remote Intradoc Client (RIDC)では、Intradoc通信プロトコルを使用してコンテンツ・サーバーとSecure Socket Layer (SSL)通信を行うことが可能です。使用される通常のポートは4444です。SSLの構成およびポートの有効化に関する詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』を参照してください。
SSL通信の場合、アクセス先のコンテンツ・サーバー・インスタンスにSecurityProvidersコンポーネントをインストールして有効化する必要があります。新しい受信プロバイダとのSSL通信のためにコンテンツ・サーバーを構成し、トラストストアまたはキーストアに関する情報を指定する必要があります。クライアントとコンテンツ・サーバーの両方で、署名付きの信頼できる証明書のある有効なキーストアまたはトラスト・マネージャが必要です。
Oracleでは、署名付き証明書を提供していません。ほとんどの実装では、広く認められている認証局による署名付きの証明書を求めることになります。
コンテンツ・サーバーとのSSL通信を構成するには、次のタスクを実行する必要があります。
SecurityProvidersコンポーネントをインストールして、有効にします。SecurityProvidersコンポーネントは、SSL通信でアクセスするコンテンツ・サーバー・インスタンスにインストールし、有効にする必要があります。
このコンポーネントは、Oracle WebCenter Content Server 11gR1ではデフォルトでインストールされ、有効化されます。
SSL通信のための受信プロバイダを構成します。
SSLの構成に関する詳細は、『Oracle WebCenter Content Content Serverシステム管理者ガイド』を参照してください。
自己署名付きのキー・ペアおよび証明書を作成します。
例23-6のコードは、セキュア・ソケット(SSL)経由のIDCプロトコルを使用します。
例23-6 SSL経由のIDCプロトコル
// build a secure IDC client as cast to specific type
IntradocClient idcClient = (IntradocClient)
manager.createClient("idcs://localhost:4443");
// set the SSL socket options
config.setKeystoreFile("ketstore/client_keystore"); //location of keystore file
config.setKeystorePassword ("password"); // keystore password
config.setKeystoreAlias("SecureClient"); //keystore alias
config.setKeystoreAliasPassword("password"); //password for keystore alias
JAX-WSの構成
クライアントの作成後に実行可能な、JAX-WS固有の構成がいくつかあります。ただし、ほとんどの場合、デフォルト設定を使用する必要があります。
このコードは、クライアントをJAX-WSタイプのキャストとしてビルドします。
JaxWSClient jaxwsClient = (JaxWSClient) manager.createClient
("http://wlsserver:7044/idcnativews");
JaxWSClientConfig jaxwsConfig = jaxwsClient.getConfig();
接続先のコンテンツ・サーバーのインスタンス名を設定できます。これは、デフォルトで/cs/(UCMインストールのWebコンテキスト)に設定されます。サーバーのWebコンテキストがデフォルトと異なる場合は、次のように設定できます。
// set the property
jaxwsConfig.setServerInstanceName("/mywebcontext/");
JPS構成ファイルの場所を設定します。JPS構成ファイルは、SAMLやメッセージ・トークンなど、ほとんどのポリシーで必要です。
jaxwsConfig.setJpsConfigFile("/my/path/to/the/jps-config.xml");
次のように、セキュリティ・ポリシーを設定します。
jaxwsConfig.setClientSecurityPolicy("policy:oracle/wss11_username_token_with_message_protection_client_policy");
ログイン・ポートのWSDL URLの変更
RIDCは、インストール済のWebサービスに対してデフォルト値を使用します。何らかの理由で、Webサービスが変更されており、デフォルトのURI/URLと一致しない場合は、デフォルト値を変更する必要がある可能性があります。
次のように、ログイン・ポートのWSDL URLを変更します。
jaxwsConfig.setLoginServiceWSDLUrl
(new URL("http://server:7044/webservices/loginPort?WSDL"));
次のように、リクエスト・サービスURLを変更します。
jaxwsConfig.setRequestServiceWSDLUrl
(new URL("http://server:7044/anotherservice/myrequestport?WSDL"));
デフォルトのストリーム・チャンク・サイズは8192です。次の例では、チャンク・サイズを変更します。
jaxwsConfig.setStreamingChunkSize(8190);
JAX-WSポリシーの構成
UCMに対して設定されているサービス側のポリシーを特定するには、管理コンソールから、「デプロイメント」→Oracle UCM Native Web Services→IdcWebLoginService→「構成」→WS-Policy→IdcWebLoginPort→OWSMを選択します。
LPAが明示的に設定されていない場合にJAX-WS経由でRIDCによって活用されるWSクライアントに対するGPAポリシーを特定するには、WebLogic Scripting Tool (WLST)を初期化し、WebLogic Server Administration Scripting Shellを使用します。
例23-7のコードは、その一例を示しています。
例23-7 WebLogic Scripting Toolを使用したGPAポリシーの特定
(/u01/app/oracle/product/Middleware/oracle_common/common/bin)% ./wlst.sh
...
Initializing WebLogic Scripting Tool (WLST) ...
Welcome to WebLogic Server Administration Scripting Shell
Type help() for help on available commands
wls:/offline> connect('weblogic','welcome1','t3://localhost:7001')
Connecting to t3://localhost:7001 with userid weblogic ...
Successfully connected to Admin Server 'AdminServer' that belongs to domain 'base_domain'.
wls:/base_domain/serverConfig> help('wsmManage')
Operations that provide support to manage the global policy attachments and
Oracle MDS repository.
help('abortRepositorySession')
Abort the current repository session,
discarding the changes made to repository.
help('attachPolicySet')
Attach a policy set to the specified resource scope.
help('attachPolicySetPolicy')
Attach a policy to a policy set using the policy's URI.
help('beginRepositorySession')
Begin a session to modify the repository.
help('clonePolicySet')
Clone a new policy set from an existing policy set.
help('commitRepositorySession')
Write the contents of the current session to the repository.
help('createPolicySet')
Create a new, empty policy set.
help('deletePolicySet')
Delete a specified policy set.
help('describeRepositorySession')
Describe the contents of the current repository session.
help('detachPolicySetPolicy')
Detach a policy from a policy set using the policy's URI.
help('displayPolicySet')
Display the configuration of a specified policy set.
help('enablePolicySet')
Enable or disable a policy set.
help('enablePolicySetPolicy')
Enable or disable a policy attachment
for a policy set using the policy's URI.
help('exportRepository')
Export a set of documents from the repository into a supported ZIP archive.
help('importRepository')
Import a set of documents from a supported ZIP archive into the repository.
help('listPolicySets')
Lists the policy sets in the repository.
help('migrateAttachments')
Migrates direct policy attachments to global policy attachments
if they are identical.
help('modifyPolicySet')
Specify an existing policy set for modification in the current session.
help('resetWSMPolicyRepository')
Clean the Oracle MDS repository and re-seed with the current set
of WSM policies.
help('setPolicySetDescription')
Specify a description for the policy set selected within a session.
help('upgradeWSMPolicyRepository')
Add newly introduced WSM policies to the Oracle MDS repository.
help('validatePolicySet')
Validate an existing policy set in the repository or in a session.
wls:/base_domain/serverConfig> listPolicySets()
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root.
For more help, use help(domainRuntime)
Global Policy Sets in Repository:
base-domain-ws-client
wls:/base_domain/serverConfig> displayPolicySet('base-domain-ws-client')
Policy Set Details:
-------------------
Name: base-domain-ws-client
Type of Resources: Web Service Client
Scope of Resources: Domain("base_domain")
Description: Global policy attachments for Web Service Client resources.
Enabled: true
Policy Reference: security : oracle/wss10_saml_token_client_policy, enabled=true
GPAポリシーの設定
例23-8のコードは、WSクライアントのGPAポリシーを設定します。
例23-8 Webサービス・クライアントに対するGPAの追加
# add GPA for the web service client assuming domain name is base_domain
beginRepositorySession()
createPolicySet('base_domain-ws-client','ws-client','Domain("base_domain")')
# assuming service policy is hardcoded to
# oracle/wss11_saml_token_with_message_protection_service_policy
# and that we want the RIDC client to leverage client policy:
# oracle/wss11_saml_token_with_message_protection_client_policy
attachPolicySetPolicy
('oracle/wss11_saml_token_with_message_protection_client_policy')
validatePolicySet()
commitRepositorySession()
# confirm policy set created
listPolicySets()
# add GPA for the web service client assuming domain name is base_domain
beginRepositorySession()
createPolicySet('base_domain-ws-client','ws-client','Domain("base_domain")')
# assuming service policy is hardcoded to
# oracle/wss11_saml_token_with_message_protection_service_policy
# and that we want the RIDC client to leverage client policy:
# oracle/wss11_saml_token_with_message_protection_client_policy
attachPolicySetPolicy
('oracle/wss11_saml_token_with_message_protection_client_policy')
validatePolicySet()
commitRepositorySession()
# confirm policy set created
listPolicySets()
Remote Intradoc Client (RIDC)へのすべてのコールで、認証のための何らかのユーザーIDが必要です。オプションで、このID資格証明に、プロトコルで必要なパスワードなど、他のパラメータを添付することができます。ユーザーIDは、IdcContextオブジェクトに保持されます。いったん作成されると、以降のすべてのコールでそれを再利用できます。コンテキストを作成するには、ユーザー名と、オプションで何らかの資格証明を渡します。
次のように、(idc:// urlsに対して)パスワードなしの単純なコンテキストを作成します。
IdcContext userContext = new IdcContext("weblogic");
次のように、パスワード付きのコンテキストを作成します。
IdcContext userPasswordContext = new IdcContext("weblogic", "welcome1");
Intradoc URLの場合、リクエストがコンテンツ・サーバーとクライアントの間で信頼されているため、資格証明でパスワードは必要ありません。
JAX-WS URLの場合、資格証明の要件は、サーバーによってWebサービスが使用するように構成されているサービス・ポリシーによって異なります。
サービスを起動するには、IdcClientクラス・メソッドを使用します。
public ServiceResponse sendRequest (IdcContext userContext, DataBinder dataBinder) throws IdcClientException
詳細は、Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンスを参照してください。
例23-9のコードは、サービス・リクエストを実行し、結果のデータ・バインダを戻します。
例23-9 サービス・リクエストの実行
// get the binder
DataBinder binder = idcClient.createBinder();
// populate the binder with the parameters
binder.putLocal ("IdcService", "GET_SEARCH_RESULTS");
binder.putLocal ("QueryText", "");
binder.putLocal ("ResultCount", "20");
// execute the request
ServiceResponse response = idcClient.sendRequest (userContext, binder);
ServiceResponseには、コンテンツ・サーバーからのレスポンスが含まれます。このレスポンスから、コンテンツ・サーバーのストリームに直接アクセスできます。または、それをDataBinderに解析し、結果を問い合せることができます。
例23-10のコードは、ServiceResponseを取得し、検索結果を取得して、タイトルと作成者の値を出力します。
例23-10 バインダの取得と結果のループ・オーバー
// get the binder
DataBinder binder = response.getResponseAsBinder ();
DataResultSet resultSet = binder.getResultSet ("SearchResults");
// loop over the results
for (DataObject dataObject : resultSet.getRows ()) {
System.out.println ("Title is: " + dataObject.get ("dDocTitle"));
System.out.println ("Author is: " + dataObject.get ("dDocAuthor"));
}
ストリームを使用する場合、ストリームのクローズはコードで行います。例23-11のコードは、ストリームのクローズの例を示しています。
例23-11 ストリームのクローズ
IdcContext user = new IdcContext ("weblogic", "welcome1");
IdcClientManager manager = new IdcClientManager ();
IdcClient idcClient = manager.getClient ("some url");
DataBinder binder = idcClient.createBinder ();
binder.putLocal ("IdcService", "GET_FILE");
binder.putLocal ("dID", "12345");
ServiceResponse response = idcClient.sendRequest (user, binder);
InputStream stream = null;
try {
stream = response.getResponseStream ();
int read = 0;
int total = 0;
byte[] buf = new byte[256];
while ((read = stream.read (buf)) != -1) {
total += read;
}
} finally {
if (stream != null) {
stream.close ();
}
}
ストリームを通じた接続プーリングとクローズについては、第23.6項「接続プーリングについて」を参照してください。
IdcClientConfig#getConnectionPoolプロパティは、RIDCが接続のプーリングをどのように処理するかを決定します。simpleとpoolの2つのオプションがあります。
simpleオプションがデフォルトです。simpleオプションでは、接続の最大数の制限は適用されず、すべての接続がブロックされることなく処理されます。ほとんどの場合、このオプションを使用する必要があります。
poolオプションでは、一度にアクティブにする接続数を構成可能な内部プールを使用することが指定されます(IdcClientConfig#getConnectionSizeプロパティを通じて構成可能で、デフォルトのアクティブ・サイズは20に設定されます)。
通常、RIDCライブラリが、それ自体がアプリケーション・コンテナ内に存在するアプリケーション(Webアプリケーションなど)からの通信に使用される場合、インバウンド・リクエストはすでに調整されています。そのため、simpleオプションを使用することが適切です。poolオプションを使用する唯一のシナリオは、スタンドアロン・サーバーを作成しており、かつコンテンツ・サーバーの過負荷を生じさせる可能性がある大量の同時コールをコンテンツ・サーバーに対して行う場合です。
IdcClientManager#getConnectionPoolManager()#registerPool()メソッドによって別のプール実装を登録できます。このメソッドは、名前をConnectionPoolインタフェースの実装にマップします。マップされた名前は、IdcClientConfigオブジェクトで使用されて、特定のクライアントに対してそのプールが選択されます。
ストリームは、TransferFileクラスを通じてコンテンツ・サーバーに送信されます。このクラスは、実際のストリームを、ストリームに関するメタデータ(長さや名前など)とともにラップします。ファイルおよびストリームのチェックインを可能にするメソッドについては、Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンスを参照してください。
例23-12のコードは、コンテンツ・サーバーへのチェックインを実行します。
例23-12 コンテンツ・サーバーへのチェックイン
// create request
DataBinder binder = idcClient.createBinder();
binder.putLocal ("IdcService", "CHECKIN_UNIVERSAL");
// get the binder
binder.putLocal ("dDocTitle", "Test File");
binder.putLocal ("dDocName", "test-checkin-6");
binder.putLocal ("dDocType", "ADACCT");
binder.putLocal ("dSecurityGroup", "Public");
// add a file
binder.addFile ("primaryFile", new TransferFile ("test.doc"));
// check in the file
idcClient.sendRequest (userContext, binder);
コンテンツ・サーバーからのレスポンス
コンテンツ・サーバーからのストリームは、ServiceResponseオブジェクトを通じて受信されます。使用可能なメソッドの概要については、Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンスを参照してください。
特に要求されないかぎり、レスポンスは、DataBinderに変換されません。単に未加工のHDAデータが必要な場合は、それを直接取得し、レスポンスをStringまたはDataBinderに変換できます。
例23-13のコードは、サービスを実行し、レスポンスを文字列として取得して、それをデータ・バインダに解析します。
例23-13 DataBinderへのStringの解析
// create request DataBinder binder = idcClient.createBinder (); // execute the service ServiceResponse response = idcClient.sendRequest (userContext, binder); // get the response stream InputStream stream = response.getResponseStream (); // get the response as a string String responseString = response.getResponseAsString (); // parse into data binder DataBinder dataBinder = response.getResponseAsBinder ();
バインダは、複数のリクエスト間で再利用できます。あるリクエストからのバインダを別のリクエストに送信できます。あるコールからのバインダを次のコールで再利用する場合、次のコールに影響する可能性のあるものがバインダに残っていないように、細心の注意を払う必要があります。RIDCは、各コールの後にバインダをクリーンアップしません。
例23-14のコードは、コンテンツ・サーバーへの複数のコールで同じバインダを再利用することで、検索結果をページングする例を示しています。
例23-14 バインダの再利用
// create the user context
IdcContext idcContext = new IdcContext ("sysadmin", "idc");
// build the search request binder
DataBinder binder = idcClient.createBinder();
binder.putLocal("IdcService", "GET_SEARCH_RESULTS");
binder.putLocal("QueryText", "");
binder.putLocal("ResultCount", "20");
// send the initial request
ServiceResponse response = idcClient.sendRequest (binder, idcContext);
DataBinder responseBinder = response.getResponseAsBinder();
// get the next page
binder.putLocal("StartRow", "21");
response = idcConnection.executeRequest(idcContext, binder);
responseBinder = response.getResponseAsBinder();
// get the next page
binder.putLocal("StartRow", "41");
response = idcConnection.executeRequest(binder, idcContext);
responseBinder = response.getResponseAsBinder();
多数のアプリケーションがRIDCを使用して実行するアクションのパターンがいくつかあります。コンビニエンス・パッケージで、それらのパターンの一部が再利用のために提供されています。コンビニエンス・パッケージ領域内のクラスは、RIDCコードのコンシューマであり、そのため、新しい機能を追加することはありません。それらは、RIDCの上の新たなレイヤーと考えることができます。
コンテンツ・サーバーには、コンテンツ・サーバー上の設定によって制御されるいくつかのセキュリティ・モデルがあります。特定のユーザーがあるドキュメントへのアクセス権を持っているかどうかを判断するには、ユーザーの権限コントロール、ドキュメントの権限コントロール、コンテンツ・サーバーのセキュリティ環境設定という3つのものが必要です。
UserSecurityモジュールをコールするアプリケーション・プログラムは、スーパーユーザーとして(ドキュメントのバインダ、通常は検索結果で)ドキュメントおよびDOC_INFOメタデータをフェッチし、その情報をキャッシュすると想定されます。アプリケーションで、特定のユーザーがドキュメントへのアクセス権を持っているかどうかを把握する必要がある場合、そのユーザーの権限をフェッチするために、そのユーザーとしてコンテンツ・サーバーへのコールが行なわれます。いったんユーザーの権限コントロールが把握されると、それらをドキュメントのメタデータ内の情報と照合してそのユーザーのアクセス・レベルを判断することができます。(アクセス・レベルは、READ、READ/WRITEまたはREAD/WRITE/DELETEです)。したがって、必要なのは、(キャッシュによって)コンテンツ・サーバーへのコール数を減らし、ユーザーの権限情報とドキュメントの権限情報を照合するデフォルトの実装を用意することです。さらに複雑化させる1つの要因は、コンテンツ・サーバーが一部のサーバー環境プロパティ(UseAccounts=trueおよびUseCollaboration=trueまたはUseEntitySecurity=1)でどのセキュリティのタイプが使用されるかを制御することです。さらに、メソッドによって、そのドキュメントのセキュリティ・タイプに管理者権限が割り当てられているかどうかをテストすることができます。
ユーザー・セキュリティ・コンビニエンスには、IUserSecurityCacheインタフェースを通じてアクセスできます。それらのクラスは、オプションのコンテンツ・サーバー・セキュリティを実装します。
UserSGAcctAclCacheクラスは、常にコールする必要があります。このクラスは、セキュリティ構成についてコンテンツ・サーバーをチェックし、それに合せて自身を内部的に調整します。
UserSecurityGroupsCacheクラスは、ユーザー権限のキャッシュを保持し、セキュリティ・グループ情報のみを考慮してドキュメントを照合します。このクラスを直接コールしないでください。UserSGAcctAclCacheクラスは、セキュリティ構成についてコンテンツ・サーバーをチェックし、それに合せて自身を内部的に調整します。
コンテンツ・サーバーにUseAccounts=true設定がある場合、UserSGAccountsCacheクラスは、アカウント情報も考慮するためのリゾルバを追加します。このクラスを直接コールしないでください。UserSGAcctAclCacheクラスは、セキュリティ構成についてコンテンツ・サーバーをチェックし、それに合せて自身を内部的に調整します。
詳細は、Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンスを参照してください。
例23-15のコードは、ユーザー・セキュリティの設定の例を示しています。
例23-15 ユーザー・セキュリティの設定
IdcClientManager m_clientManager = new IdcClientManager ();
IdcClient m_client = m_clientManager.createClient
("http://localhost/scs/idcplg");
//RIDC superuser context
IdcContext m_superuser = new IdcContext("sysadmin", "idc");
//This class will self-adjust (downwards) to match the security model
// on the content server
IUserSecurityCache m_userSecurityCache = new UserSGAcctAclCache
(m_client, 20, 1000, 20000, m_superuser);
ITrace trace = null;
//Example test
testDocPermission () {
//If you don't want to do any logging, you can leave trace as null
if (m_log.isLogEnabled(ILog.Level.TRACE)) {
trace = new Trace ();
}
DataBinder m_doc1 = getDataBinder ("TEST");
//Get the document information (typically in the first row of DOC_INFO)
DataObject docInfo = m_doc1.getResultSet ("DOC_INFO").getRows ().get (0);
//Get the cache id for this user
//This makes a live call to content server to get the user ID for "Acme1"
//CacheId acme1 = m_userSecurityCache.getCacheIdForUser
// (new IdcContext("Acme1", "idc"), trace);
IdcContext context = new IdcContext("Acme1", "idc");
CacheId acme1 = new CacheId (context.getUser (), context);
//Get the access level for this document by this user
int access = m_userSecurityCache.getAccessLevelForDocument
(acme1, docInfo, trace);
//Check if user has ACL admin permissions
boolean aclAdmin = m_userSecurityCache.isAdmin
(acme1, docInfo, IUserSecurityCache.AdminType.ACL, trace);
if (m_log.isLogEnabled(ILog.Level.TRACE)) {
m_log.log (trace.formatTrace (), ILog.Level.TRACE);
}
}
//Example code to get a Document's DOC_INFO databinder
DataBinder getDataBinder (String dDocName) throws IdcClientException {
DataBinder dataBinder = m_client.createBinder ();
dataBinder.putLocal ("IdcService", "DOC_INFO_BY_NAME");
dataBinder.putLocal ("dDocName", dDocName);
ServiceResponse response = m_client.sendRequest (m_superuser, dataBinder);
return response.getResponseAsBinder ();
}
//Example code to create a DataObject
DataObject dataObject = m_client.getDataFactory ().createDataObject ();
dataObject.put ("dSecurityGroup", "public");
dataObject.put ("dDocAccount", "Eng/Acme");
内部的に、ドキュメントからのこれらのフィールドは、getAccessLevelForDocument()の間に調査されます。
AccessResolverSecurityGroupsクラスの場合: dSecurityGroup
AccessResolverAccountsクラスの場合: dDocAccount
AccessResolverSecurityGroupsクラスの場合: xClbraUserList、xClbraAliasListおよびxClbraRoleList
IAccessResolverクラスは、コンテンツ・サーバーからキャッシュされた情報に基づいて参加するかどうかを決定します。参加する場合、複数のアクセス・レベルは論理積(AND)になります。hasAdmin()メソッドを使用して、管理アクセス権があるかどうかを判断できます。詳細は、Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンスを参照してください。
Remote Intradoc Client (RIDC)バージョン11.1.1.6.0には、AdfConnectionFacadeコンビニエンス・クラスが含まれています。このクラスは、接続の詳細を格納し、idcClientオブジェクトを取得し、ユーザー資格証明オブジェクトを作成するための簡単な方法を提供します。また、JDeveloper拡張機能において接続UIも提供します。
|
注意: この機能は、RIDCアプリケーションが適切なADFライブラリでプロビジョニングされたshiphomeにデプロイされている場合のみ使用可能です。 |
例23-16のコードは、example1という名前の接続に対するファサードをフェッチし、接続できるかどうかを確認するテストを実行します。
例23-16 ファサードのフェッチとテストの実行
AdfConnectionFacade facade = new AdfConnectionFacade ("example1");
boolean ok = facade.testConnection ("user").isSuccess()
//or
AdfConnectionFacade.ResultTestConnection testResult =
facade.testConnection ("user");
if (!testResult.isSuccess ()) {
throw new IdcClientException (testResult.getMessage ());
}
パラメータ名に対して<Credentials Label>.<Credentials Type>.<Field Name>というネーミング・パターンに従うことで、Jdeveloper UIにユーザー資格証明を追加できます。
次に例を示します。
admin1.basic.name admin1.basic.password
facade.getUserCredentials("admin1")を使用すると、移入されたBasicCredentialsクラスが返されます。
public.nameonly.name
facade.getUserCredentials("public")を使用すると、移入されたUserNameOnlyCredentialsクラスが返されます。<default>の値を使用して、内部のデフォルト・ユーザー名を取得します。
myuser.adf.name
facade.getUserCredentials("myuser")を使用すると、AdfUserCredentialsクラスが返されます。
RIDCコールが行なわれると、ログイン・ユーザーが次のコードでフェッチされます。
ADFContext.getCurrent ().getSecurityContext().getUserName()
次の追加パラメータは、RIDCによって自動的に把握されます。
connectionSize
connectionWaitTime
connectionPool
socketTimeout
useSystemProxy
http.proxyHost
http.proxyPort
http.nonProxyHosts
http.proxyUserName
http.proxyPassword
http.library
sslKeystoreFile
sslKeystorePassword
sslAlgorithm
sslKeystoreAlias
sslKeystoreAliasPassword
sslTrustManagerFile
sslTrustManagerPassword
clientSecurityPolicy
jaxWsStack
streamingChunkSiz
Remote Intradoc Client (RIDC)バージョン11.1.1.4.0以上では、DataBinderが処理され、コンテンツ・サーバーに送信される前に、アプリケーション・コードでフィルタを追加することが可能です。IdcFilterAdapterクラスのいずれかを拡張してフィルタを作成し、そのフィルタを登録してIdcFilterManagerクラスで実行できます。フィルタは、登録時に指定された順番で実行されます。すでに登録済のフィルタを取得したり、削除したりすることもできます。
例23-17のコードは、アダプタを拡張し、アクションを実行するメソッドをオーバーライドします。
例23-17 サービス・リクエストの前のRIDCフィルタのコール
public class IdcFilterAddComment extends BeforeServiceRequestFilter {
@Override
public void beforeServiceRequest
(IdcClient client, IdcContext context, DataBinder binder)
throws IdcClientException {
String existingComments = binder.getLocal("xComments");
if (existingComments != null) {
binder.putLocal("xComments", String.format
("%s %s", existingComments, "--DGT WAS HERE--"));
} else {
binder.putLocal("xComments", "--DGT WAS HERE--");
}
}
}
Remote Intradoc Client (RIDC)バージョン11.1.1.5.0以降では、JAX-WS処理領域にさらに2つのフィルタの場所が提供されます。それらのフィルタを使用するには、BeforeJaxwsServiceFilterクラスを拡張します。
例23-18のコードは、BeforeJaxwsServiceFilterクラスを拡張します。
例23-18 JAX-WSコールの前のRIDCフィルタのコール
/**
* RIDC filter called just before jaxws call is made to
* loginPort.contentServerLogin () in authenticateUser ()
**/
public void beforeJaxwsAuthenticateUser (IdcContext context, DataBinder binder,
Map<String, Object> requestContext) throws IdcClientException {
requestContext.put(oracle.wsm.security.util.SecurityConstants.
ClientConstants.WSM_SUBJECT_PRECEDENCE, “false”);
}
/**
* RIDC filter called just before jaxws call is made to
* loginPort.contentServerRequest () in performServiceRequest ()
**/
public void beforeJaxwsServiceRequest (IdcContext context, DataBinder binder,
Map<String, Object> requestContext) throws IdcClientException {
//Override this class and implement your filter here
}
例23-19のコードは、フィルタ・クラス(複数可)を登録します。
例23-19 フィルタ・クラスの登録
// If you are at the start of a pure RIDC application, you typically
// will create a ClientManager, for example:
IdcClientManager m_clientManager = new IdcClientManager();
// New method added to IdcClient to get the ClientManager
// if you do not have the ClientManager instance:
IdcClient client = myClient;
client.getClientManager();
// From the ClientManager, you can get the FilterManager:
IdcFilterManager fmanager = m_clientManager.getFilterManager();
// Then register your filter:
IIdcFilter addCommentFilter = new IdcFilterAddComment();
int slot = fmanager.registerFilter(100, addCommentFilter);
// Optionally, you can deregister. However, it might not be in the slot you
// assigned because there might have already been a filter in that slot.
// When registering, the next available higher slot will be used. You also need
// to pass in the instance currently in the slot you want to remove:
fmanager.deRegisterFilter(slot, addCommentFilter);
// Here is an example to remove all the filters,
// including the ones you did not register
for (Integer slot:fmanager.getUsedSlots()) {
fmanager.deRegisterFilter(slot, fmanager.getFilter (slot));
}
Remote Intradoc Client (RIDC)通信APIは、Oracle JDeveloperのデプロイ可能な拡張機能として提供されています。RIDC JDeveloper拡張機能は、JDeveloper環境にRIDCライブラリのコピーを配置します。
必要なバージョンと拡張機能
次のJDeveloperバージョンとRIDC拡張機能が必要です。
Oracle Remote Intradoc Client (RIDC)拡張機能11.1.1.6 (11gR1 PS5)
Oracle JDeveloperバージョン11.1.1.6 (11gR1 PS5)
Oracle Remote Intradoc Client (RIDC)拡張機能(oracle.ucm.ridc.jdev-11.1.1.6.zip)は、Remote Intradoc Client (RIDC)スイート・ディストリビューション(ridc-suite-11.1.1.6.zip)の/modules/jdevディレクトリにあります。RIDCスイート・ディストリビューションは、Oracle Technology Network (OTN) (http://otn.oracle.com)からダウンロードできます。
Oracle JDeveloperにRIDC拡張機能をデプロイするには、次の手順を実行します。
Oracle Technology Network (OTN)からRemote Intradoc Client (RIDC)スイート・ディストリビューションをダウンロードします。
RIDCスイート・ディストリビューション(ridc-suite-11.1.1.6.zip)を、Oracle JDeveloperインスタンスをホストしているシステムの場所にアンバンドルします。
JDeveloperのメイン・メニューから、「ヘルプ」→「更新の確認」を選択します。
「ローカル・ファイルからインストール」オプションを有効にします。
「参照」をクリックして、アンバンドルされたRIDCスイート・ディストリビューション(ridc-suite-11.1.1.6.zip)にナビゲートします。
/modules/jdevディレクトリにあるRIDC拡張機能(oracle.ucm.ridc.jdev-11.1.1.6.zip)を選択し、「開く」をクリックします。
「次へ」をクリックして、拡張機能をデプロイします。
「終了」をクリックします。
JDeveloperにより拡張機能がインストールされたら、「ツール」→「プリファレンス」→「拡張機能」を選択して、RIDCライブラリからJDeveloperにアクセスできることを確認し、RIDCエントリにスクロールします。RIDCライブラリがディスク上に存在することを確認するには、<JDeveloper Home>/jdeveloper/ucm/Distribution/RIDCディレクトリをチェックし、次のファイルが存在することを確認します。
+-- lib ¦ +-- commons-codec-1.2.jar ¦ +-- commons-httpclient-3.1.jar ¦ +-- commons-logging-1.0.4.jar ¦ +-- httpclient-4.1.1.jar ¦ +-- httpcore-4.1.jar ¦ +-- httpmime-4.1.1.jar +-- oracle.ucm.ridc-11.1.1.jar +-- oracle.ucm.ridc.app-lib-11.1.1.ear
この項では、新しいアプリケーションとプロジェクトを作成し、RIDCテクノロジを追加して、共有ライブラリ参照を検証する手順について説明します。RIDCテクノロジを既存のプロジェクトに追加するのではなく、新しいRIDC対応プロジェクトを作成することをお薦めします。
RIDCテクノロジが備わった新しいアプリケーションとプロジェクトを作成する手順は次のとおりです。
メイン・メニューから、「ファイル」→「新規」を選択します。
「新規ギャラリ」ダイアログが開きます。
「カテゴリ」で、「一般」→「アプリケーション」を選択します。
「アイテム」で、「汎用アプリケーション」を選択します。
「OK」をクリックします。
汎用アプリケーションの作成ウィザードが表示されます。
アプリケーション名を指定します。
デフォルト・ディレクトリを受け入れるか、別のディレクトリを指定します。
「次へ」をクリックします。
これがRIDC対応プロジェクトであることがわかるようなプロジェクト名を指定します。
|
注意: プロジェクト名には、アポストロフィ( ' )やアスタリスク( * )などの特殊文字を使用しないでください。 |
「プロジェクト・テクノロジ」タブで、リストからRIDC、「HTML」および「JSPとサーブレット」を選択し、シャトル・ボタンをクリックして、選択したものをそれぞれ「選択済」リストに転送します。
「次へ」をクリックします。
設定を確認して「終了」をクリックします。
共有ライブラリ参照を検証する手順は次のとおりです。
メイン・メニューから、「表示」→「アプリケーション・ナビゲータ」を選択します。
アプリケーション・ナビゲータで、「アプリケーション・リソース」パネルを選択します。
「ディスクリプタ」→META-INFを開きます。
weblogic-application.xmlを右クリックしし、「開く」を選択します。
エディタで、「概要」タブを選択します。
「ライブラリ」を選択し、「共有ライブラリ参照」を開きます。
ライブラリ名oracle.ucm.ridc.app-libがリストされていることを確認します。
この項では、接続を処理するための様々な手順について説明します。接続の処理の詳細は、JDeveloperオンライン・ヘルプのRIDCに関する項を参照してください。
JDeveloper 11gでは、接続を作成して管理するための2つの方法があります。アプリケーションのコンテキストで使用される接続(アプリケーション・リソース接続と呼ばれます)を定義することも、IDE全体としての接続(IDE接続と呼ばれます)を定義することもできます。同じダイアログを使用してこれらの接続の両方を定義できますが、JDeveloper内でのそれらの有効範囲は異なります。
アプリケーション・リソース: これらの接続の有効範囲はローカルで、そのアプリケーション内でのみ使用可能です。接続情報は、アプリケーション自体に格納され、アプリケーションとともにデプロイできます。これらのタイプの接続は、アプリケーション・ナビゲータの「アプリケーション・リソース」パネルの「接続」ノードの下にリストされます。
IDE接続: これらの接続は、グローバルに定義され、再利用可能です。これらのタイプの接続は、リソース・パレットの「IDE接続」パネルにリストされます。アプリケーション・ナビゲータにIDE接続をコピーして、アプリケーション内でそれらを使用することができます。
新しいコンテンツ・サーバー接続を作成する手順は次のとおりです。
メイン・メニューから、「表示」→「アプリケーション・ナビゲータ」を選択します。
アプリケーション・ナビゲータで、「アプリケーション・リソース」パネルを選択します。
「接続」を右クリックし、「接続の作成」→RIDCを選択します。
「コンテンツ・サーバー接続の作成」ダイアログを使用して、新しい接続を作成します。このダイアログのオプションとフィールドの説明については、「ヘルプ」をクリックします。
「接続のテスト」をクリックします。
接続に失敗した場合は、コンテンツ・サーバーの正しい接続情報を把握していること、および有効なログイン資格証明を指定したことを確認してください。
「OK」をクリックします。
アプリケーション・リソース接続を編集または更新します。
メイン・メニューから、「表示」→「アプリケーション・ナビゲータ」を選択します。
アプリケーション・ナビゲータで、「アプリケーション・リソース」パネルを選択します。
「接続」→RIDCを開きます。
接続を右クリックし、「プロパティ」を選択します。
「コンテンツ・サーバー接続の編集」ダイアログを使用して、接続の詳細を編集または更新します。このダイアログのオプションとフィールドの説明については、「ヘルプ」をクリックします。
「接続のテスト」をクリックします。
接続に失敗した場合は、コンテンツ・サーバーの正しい接続情報を把握していること、および有効なログイン資格証明を指定したことを確認してください。
「OK」をクリックします。
IDE接続を編集または更新します。
メイン・メニューから、「表示」→「リソース・パレット」を選択します。
「リソース・パレット」で、「IDE接続」パネルを選択します。
RIDCノードを開きます。
接続を右クリックし、「プロパティ」を選択します。
「コンテンツ・サーバー接続の編集」ダイアログを使用して、接続の詳細を編集または更新します。このダイアログのオプションとフィールドの説明については、「ヘルプ」をクリックします。
「接続のテスト」をクリックします。
接続に失敗した場合は、コンテンツ・サーバーの正しい接続情報を把握していること、および有効なログイン資格証明を指定したことを確認してください。
「OK」をクリックします。
RIDCテクノロジが備わったアプリケーションにIDE接続を追加する手順は次のとおりです。
メイン・メニューから、「表示」→「アプリケーション・ナビゲータ」を選択します。
ドロップダウン・リストから、RIDCテクノロジが備わったアプリケーションを選択します。
メイン・メニューから、「表示」→「リソース・パレット」を選択します。
「リソース・パレット」で、「IDE接続」パネルを選択します。
RIDCノードを開きます。
接続を右クリックし、「アプリケーションに追加」を選択します。
注意: 接続は、JDeveloperで現在開かれているアプリケーションに追加されます。接続は、アプリケーション・ナビゲータの「アプリケーション・リソース」パネルの「接続」ノードの下にリストされます。
この項では、JSPページ上のサービス・コールのサンプル・コードを示します。これらの手順は、RIDC対応のプロジェクトに対してJSPページが作成済であることを前提としています。詳細は、JDeveloperオンライン・ヘルプのRIDCに関する項を参照してください。
JSPページへの次のJSPディレクティブを使用して、必要なJavaパッケージおよびクラスをインポートします。
<%@ page import="oracle.stellent.ridc.*"%>
<%@ page import="oracle.stellent.ridc.model.*"%>
<%@ page import="oracle.stellent.ridc.model.impl.*"%>
<%@ page import="oracle.stellent.ridc.convenience.adf.connection.*"%>
例23-20のコードは、JSPページのボディに追加されるサービス・コールの例を示しています。
例23-20 サービス・コールのサンプル・コード
<h1>Example of service call</h1>
<%
AdfConnectionFacade facade = new AdfConnectionFacade("demo");
AdfConnectionFacade.ResultTestConnection rtest; rtest =
facade.testConnection("user");
if (!rtest.isSuccess()) {
%>
<h3>Content server not available because</h3>
<p><%=rtest.getmessaage()%></p>
<%
} else {
IdcClient client = facead.getIdcClient();
IdcContext ctx = new IdcContext(facade.gtUserCredentials("user"));
DataBinder binder = client.createBinder();
binder.putLocal("IdcService", "GET_USER_PERMISSIONS");
DataBinder r = client.sendRequest(ctx, binder).getResponseAsBinder();
%>
<pre><%=(DataBinderImpl)r%></pre>
<% } %>
