| Oracle® Fusion Middleware Oracle WebCenter Contentでの開発 11gリリース1(11.1.1) B72427-01 |
|
 前 |
 次 |
ホーム > Oracle WebCenter Contentによる開発 > RIDCの使用によるコンテンツ・サーバーへのアクセス
| Oracle® Fusion Middleware Oracle WebCenter Contentでの開発 11gリリース1(11.1.1) B72427-01 |
|
前 |
次 |
ホーム > Oracle WebCenter Contentによる開発 > RIDCの使用によるコンテンツ・サーバーへのアクセス
この章では、Oracle WebCenter Content Serverとの通信のためのシン通信APIを提供するRemote Intradoc Client (RIDC)の初期化および使用方法について説明します。詳細は、Oracle Fusion Middleware Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンスを参照してください。
Remote Intradoc Client (RIDC)は、Oracle Technology Network (OTN) (http://www.oracle.com/technetwork/index.html)からダウンロードできます。
|
注意: Remote Intradoc Client (RIDC) 11gR1 (11.1.1.6.0以降)では、Java Runtime Environment (JRE) 1.6以上が必要です。最新のJava JRE/JDKは、Oracle Technology Network (OTN) ( |
この章では、次の項目について説明します。
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) 11gR1 (11.1.1.7.0)は、idc、idcs、http、httpsおよびjax-wsの各プロトコルをサポートしています。
Intradoc: Intradocプロトコルは、Intradocソケット・ポート(通常は4444)経由でコンテンツ・サーバーと通信します。このプロトコルは、クライアントとコンテンツ・サーバー間の信頼できる接続を必要とし、パスワード検証は行いません。このプロトコルを使用するクライアントには、RIDCコールを行う前に、必要な認証を自身で実行することが求められます。Intradoc通信は、SSL経由で実行するように構成することもできます。
HTTP: RIDCは、サポートされている次の3つのHTTPクライアント・パッケージのいずれかを使用して、コンテンツ・サーバーへのHTTP接続を作成できます。
Oracle HTTPClient
Apache HttpClientバージョン3(デフォルト)
Apache HttpClientバージョン4
Intradocとは異なり、このプロトコルでは、リクエストごとに有効なユーザー名とパスワード認証資格証明が必要です。詳細は、第29.1.1項「HttpClientライブラリ」を参照してください。その他の詳細は、次の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 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 | 説明 |
|---|---|
|
|
Intradocポートを使用します。ホスト名とポート番号のみが必要です。 |
|
|
Intradocポート経由でSSLを使用します。SSL証明書をロードするための追加の構成が必要です。 |
|
|
コンテンツ・サーバーCGIパスへのURLを指定します。 |
|
|
SSL over HTTPを使用します。SSL証明書をロードするための追加の構成が必要です。 |
|
|
JAX-WSプロトコルを使用してコンテンツ・サーバーに接続します。 |
必要な環境
次の表は、RIDCが各接続タイプをサポートするために必要な環境についてまとめたものです。
| URL | 説明 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
RIDCでは、HTTP接続を使用してコンテンツ・サーバー・インスタンスに添付されているWebサービスと通信するために、HTTPクライアント・ライブラリをサポートする必要があります。現在は、次の3つのライブラリがサポートされています。
Oracle HTTPClient
Apache (Jakarta Commons) HttpClientバージョン3
Apache (HttpComponents) HttpClientバージョン4
デフォルトは、Apache HttpClientバージョン3です。
Oracle HttpClientをJavaコードでリクエストするには:
IdcClient idcClient = manager.createClient("http://localhost/cs/idcplg");
idcClient.getConfig ().setProperty ("http.library", "oracle");
Apache HttpClientバージョン4をJavaコードでリクエストするには:
IdcClient idcClient = manager.createClient("http://localhost/cs/idcplg");
idcClient.getConfig ().setProperty ("http.library", "apache4");
JDeveloper拡張機能を使用して新規のRIDCアプリケーションを作成している場合は、「構成パラメータ」セクションで、適切な値( apache4など)を指定したパラメータhttp.libraryを接続に追加することができます。その他の詳細は、次のApache HttpClient WebサイトのHttpClientホームページで、Jakarta Commons HttpClientドキュメントを参照してください。
http://hc.apache.org/
JDeveloperでSite Studio for External Applications (SSXA)アプリケーションを使用している場合、ユーザー・インタフェースがないため、まず接続を作成し、その接続をテストせずに保存する必要があります。その後で、「接続」→ディスクリプタ→ADF META-INFノードのconnections.xmlファイルを開きます。connections.xmlファイルに次のStringRefAddrセクションを追加し(例29-1に示します)、ファイルを保存します。
例29-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です。
多数のアプリケーションがRIDCを使用して実行するアクションのパターンがいくつかあります。コンビニエンス・パッケージで、それらのパターンの一部が再利用のために提供されています。コンビニエンス・パッケージ領域内のクラスは、RIDCコードのコンシューマであり、そのため、新しい機能を追加することはありません。それらは、RIDCの上の新たなレイヤーと考えることができます。
コンビニエンス・クラスの使用の詳細は、第29.9項「ユーザー・セキュリティの設定」を参照してください。
この項では、Intradoc接続とHTTP接続を初期化するサンプル・コード、およびJAX-WSクライアントを初期化するコードを示します。
例29-2のコードは、Intradoc接続を初期化します。
例29-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");
例29-3のコードは、HTTP接続を初期化します。Intradoc接続との唯一の違いはURLです。
例29-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/cs/idcplg");
例29-4のコードは、JAX-WSクライアントを初期化します。URLにはidcnativews Webコンテキスト・ルートが含まれています。このWebコンテキスト・ルートは(デフォルトでは)、コンテンツ・サーバーにより公開される2つのWebサービス、loginサービスおよびrequestサービスにより使用されます。
クライアントの構成は、クライアントの作成後に実行できます。構成パラメータには、ソケット・タイムアウトの設定、接続プール・サイズなどがあります。構成はプロトコルに固有です。IdcClientオブジェクトを特定のタイプにキャストすると、そのタイプのプロトコル構成オブジェクトを取得できます。
例29-5のコードは、Intradoc接続のためのソケット・タイムアウトおよび待機時間を設定します。
例29-5 Intradoc接続のためのクライアント構成
// build a client as cast to specific type
IntradocClient idcClient =
(IntradocClient)manager.createClient("http://localhost/cs/idcplg");
// get the config object and set properties
idcClient.getConfig().setSocketTimeout(30000); // 30 seconds
idcClient.getConfig().setConnectionSize(20); // 20 connections
Remote Intradoc Client (RIDC)では、Intradoc通信プロトコルを使用してコンテンツ・サーバーとSecure Socket Layer (SSL)通信を行うことが可能です。使用される通常のポートは4444です。SSLの構成とポートの有効化の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』を参照してください。
SSL通信の場合、アクセス先のコンテンツ・サーバー・インスタンスにSecurityProvidersコンポーネントをインストールして有効化する必要があります。新しい受信プロバイダとのSSL通信のためにコンテンツ・サーバーを構成し、トラストストアまたはキーストアに関する情報を指定する必要があります。クライアントとコンテンツ・サーバーの両方で、署名付きの信頼できる証明書のある有効なキーストアまたはトラスト・マネージャが必要です。
Oracleでは、署名付き証明書を提供していません。ほとんどの実装では、広く認められている認証局による署名付きの証明書を求めることになります。
コンテンツ・サーバーとのSSL通信を構成するには、次のタスクを実行する必要があります。
SecurityProvidersコンポーネントをインストールして、有効にします。SecurityProvidersコンポーネントは、SSL通信でアクセスするコンテンツ・サーバー・インスタンスにインストールし、有効にする必要があります。
このコンポーネントは、Oracle WebCenter Content Server 11gR1ではデフォルトでインストールされ、有効化されます。
SSL通信のための受信プロバイダを構成します。
SSLの構成の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』を参照してください。
自己署名付きのキー・ペアおよび証明書を作成します。
例29-6のコードは、セキュア・ソケット(SSL)経由のIDCプロトコルを使用します。
例29-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接続を設定するには、RIDCクライアントとOracle WebCenter Content Serverがそれぞれ、互換性のあるクライアントおよびサービスのWebサービス・ポリシーによって構成されている必要があります。
RIDCクライアントの場合、jaxwsConfig.setClientSecurityPolicy(...)を使用して明示的なクライアント・ポリシー(LPAモード)を設定するか、または、RIDCを使用するアプリケーションが、ws-clientのPGAポリシーが正しく構成され、ターゲットになっている状態でOracle WebLogic Serverドメインにデプロイされている場合に、GPAクライアント・ポリシーを継承することができます。
サービス・ポリシーは、Oracle WebCenter ContentのWebサービス(IdcWebLoginPort)エンドポイント(LPAモード)に直接添付するか、GPA ws-serviceポリシーをドメイン用に構成して、サービスにより継承することができます。
サービスのLPAモードは、Oracle Enterprise Manager Fusion Middleware Controlを使用して設定できます。
Fusion Middleware Controlを使用してサービスのLPAモードを設定するには:
Oracle Enterprise Manager 11g Fusion Middleware Controlにログインします。
左側のナビゲーション・ツリーで「アプリケーション・デプロイメント」を開き、「Oracle UCM Native Web Services」をクリックします。
「Oracle UCM Native Web Service」ページの「アプリケーション・デプロイメント」ドロップダウン・メニューから、「Webサービス」を選択します。
「Webサービス(Oracle Infrastructure Web Services)」ページの「Webサービスの詳細」で、「Webサービス・エンドポイント」タブをクリックします。
「エンドポイント名」列の「IdcWebLoginPort」をクリックします。
IdcWebLoginPort (「Webサービス・エンドポイント」)ページで、「OWSMポリシー」タブをクリックします。
「直接アタッチされたポリシー」の下で「アタッチ/デタッチ」をクリックし、適切なポリシー(例: oracle/wss_saml_or_username_token_service_policy)を選択します。
WebLogic Scripting Tool (WLST)のコマンドを使用して、GPAポリシーの継承を構成できます。
WLSTを使用してドメインのGPA ws-serviceポリシーを設定するには:
WebLogic Server Administration Scripting Shellを使用して、WebLogic Scripting Tool (WLST)を初期化します。
(/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
次のbase_domainというドメインに対する一連のコマンドと類似したコマンドを起動します。
$MW_HOME/Oracle_ECM1/common/bin/wlst.sh
connect(username='weblogic',password='welcome1',url='t3://localhost:7001')
beginRepositorySession()
createPolicySet('base_domain-ws-service','ws-service','Domain("base_domain")')
attachPolicySetPolicy('oracle/wss_saml_or_username_token_service_policy')
validatePolicySet()
commitRepositorySession()
listPolicySets()
exit()
GPAサービス・ポリシーが設定されていることを検証します。
GPAサービス・ポリシーがIdcWebLoginPortによってピックアップされるまでしばらく待ちます。
WSDLを検査してwsp:PolicyReferenceを探し、変更が適用されたかどうかを確認します。
http://server:16200/idcnativews/IdcWebLoginPort?WSDL
LPAが明示的に設定されていない場合にJAX-WS経由でRIDCによって活用されるWSクライアントに対するGPAポリシーを特定するには、WebLogic Scripting Tool (WLST)を初期化し、WebLogic Server Administration Scripting Shellを使用します。
例29-7のコードは、その一例を示しています。
例29-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
例29-8のコードは、WSクライアントのGPAポリシーを設定します。
例29-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()
クライアントの作成後に実行可能な、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);
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 Fusion Middleware Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンスを参照してください。
例29-9のコードは、サービス・リクエストを実行し、結果のデータ・バインダを戻します。
例29-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に解析し、結果を問い合せることができます。
例29-10のコードは、ServiceResponseを取得し、検索結果を取得して、タイトルと作成者の値を出力します。
例29-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"));
}
ストリームを使用する場合、ストリームのクローズはコードで行います。例29-11のコードは、ストリームを閉じます。
例29-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 ();
}
}
接続プーリングとストリームを介して閉じる方法の詳細は、第29.6項「接続プーリングの処理」を参照してください。
IdcClientConfig#getConnectionPoolプロパティは、RIDCが接続のプーリングをどのように処理するかを決定します。simpleとpoolの2つのオプションがあります。
simpleオプションがデフォルトです。simpleオプションでは、接続の最大数の制限は適用されず、すべての接続がブロックされることなく処理されます。ほとんどの場合、このオプションを使用する必要があります。
poolオプションでは、一度にアクティブにする接続数を構成可能な内部プールを使用することが指定されます(IdcClientConfig#getConnectionSizeプロパティを通じて構成可能で、デフォルトのアクティブ・サイズは20に設定されます)。
通常、RIDCライブラリが、それ自体がアプリケーション・コンテナ内に存在するアプリケーション(Webアプリケーションなど)からの通信に使用される場合、インバウンド・リクエストはすでに調整されています。そのため、simpleオプションを使用することが適切です。poolオプションを使用する唯一のシナリオは、スタンドアロン・サーバーを作成しており、かつコンテンツ・サーバーの過負荷を生じさせる可能性がある大量の同時コールをコンテンツ・サーバーに対して行う場合です。
IdcClientManager#getConnectionPoolManager()#registerPool()メソッドによって別のプール実装を登録できます。このメソッドは、名前をConnectionPoolインタフェースの実装にマップします。マップされた名前は、IdcClientConfigオブジェクトで使用されて、特定のクライアントに対してそのプールが選択されます。
ストリームは、TransferFileクラスを通じてコンテンツ・サーバーに送信されます。このクラスは、実際のストリームを、ストリームに関するメタデータ(長さや名前など)とともにラップします。ファイルとストリームのチェックインを可能にするメソッドの詳細は、Oracle Fusion Middleware Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンスを参照してください。
例29-12のコードは、コンテンツ・サーバーへのチェックインを実行します。
例29-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 Fusion Middleware Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンスを参照してください。
特に要求されないかぎり、レスポンスは、DataBinderに変換されません。単に未加工のHDAデータが必要な場合は、それを直接取得し、レスポンスをStringまたはDataBinderに変換できます。
例29-13のコードは、サービスを実行し、レスポンスを文字列として取得して、それをデータ・バインダに解析します。
例29-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 ();
コンテンツ・サーバーのほとんどのサービス・リクエストは、クライアント上でDataBinderを使用してモデル化される構造化HDAペイロードを返します。HDAペイロードは基本的にマップのような構造であり、オプションとして、表に似たResultSetが含まれています。
ダウンロード・スタイルのサービス・リクエスト(GET_FILEなど)は通常、リクエストされたドキュメントのコンテンツをRAWバイト・ストリームとして返すと予想されています。ただし、GET_FILEリクエストに指定されたパラメータが無効な場合、またはエンド・ユーザーの権限が十分でない場合などには、コンテンツ・サーバーは、エラー情報を含めたHDAペイロードで応答することがあります。したがって、GET_FILEのようなリクエストを実行するときには、例29-14に示すように、ServiceResponseに質問して、返されるレスポンス・タイプを決定する必要があります。
例29-14 返されるレスポンス・タイプ
DataBinder binder = idcClient.createBinder ();
binder.putLocal ("IdcService", "GET_FILE");
binder.putLocal ("dID", "12345");
ServiceResponse response = idcClient.sendRequest (user, binder);
if (response.getResponseType().equals(ServiceResponse.ResponseType.BINDER))
{
DataBinder responseBinder = response.getResponseAsBinder(false); // do not check for errors
int statusCode = m_binder.getLocalData ("StatusCode").getInteger("StatusCode");
String statusMessage = m_binder.getLocal ("StatusMessage");
throw new IllegalStateException("Download response was not a stream - Error: " + statusCode + " - " + statusMessage);
}
バインダは、複数のリクエスト間で再利用できます。あるリクエストからのバインダを別のリクエストに送信できます。あるコールからのバインダを次のコールで再利用する場合、次のコールに影響する可能性のあるものがバインダに残っていないように、細心の注意を払う必要があります。RIDCは、各コールの後にバインダをクリーンアップしません。
例29-15のコードは、コンテンツ・サーバーへの複数のコールで同じバインダを再利用することで、検索結果をページングする例を示しています。
例29-15 バインダの再利用
// 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();
コンテンツ・サーバーには、コンテンツ・サーバー上の設定によって制御されるいくつかのセキュリティ・モデルがあります。特定のユーザーがあるドキュメントへのアクセス権を持っているかどうかを判断するには、ユーザーの権限コントロール、ドキュメントの権限コントロール、コンテンツ・サーバーのセキュリティ環境設定という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 Fusion Middleware Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンスを参照してください。
例29-16のコードは、ユーザー・セキュリティの設定の例を示しています。
例29-16 ユーザー・セキュリティの設定
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 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 Fusion Middleware Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンスを参照してください。
Remote Intradoc Client (RIDC) 11gR1 (11.1.1.4.0以上)では、DataBinderが処理されてコンテンツ・サーバーに送信される前に、アプリケーション・コードでフィルタを追加することが可能です。IdcFilterAdapterクラスのいずれかを拡張してフィルタを作成し、そのフィルタを登録してIdcFilterManagerクラスで実行できます。フィルタは、登録時に指定された順番で実行されます。すでに登録済のフィルタを取得したり、削除したりすることもできます。
例29-17のコードは、アダプタを拡張し、アクションを実行するメソッドをオーバーライドします。
例29-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) 11gR1 (11.1.1.5.0以降)では、JAX-WS処理領域にさらに2つのフィルタの場所が提供されます。それらのフィルタを使用するには、BeforeJaxwsServiceFilterクラスを拡張します。
例29-18のコードは、BeforeJaxwsServiceFilterクラスを拡張します。
例29-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
}
例29-19のコードは、フィルタ・クラス(複数可)を登録します。
例29-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));
}
