| Oracle® Fusion Middleware Oracle Service Bus開発者ガイド 11g リリース1(11.1.1.4.0) B61435-02 |
|
 前 |
 次 |
トランスポートSDKは、転送プロトコルとOracle Service Busランタイム・システムとの間に抽象のレイヤーを提供します。この抽象のレイヤーでは、新しいトランスポート・プロバイダを開発してOracle Service Busにプラグインできます。トランスポートSDKインタフェースは、HTTPなどの転送プロトコルとOracle Service Busランタイムの間を橋渡しします。
この章では、カスタム・トランスポート・プロバイダの開発に必要な基本手順について説明します。この章の内容は以下のとおりです。
カスタム・トランスポート・プロバイダを設計および構築するプロセスは複雑です。この項では、トランスポート・プロバイダを開発する際の推奨事項について説明します。カスタム・トランスポート・プロバイダの開発は、以下の基本的な手順に分類されます。
カスタム・トランスポート・プロバイダを開発する前に、次の計画手順を確認します。
カスタム・トランスポート・プロバイダを開発する必要があるかどうかを判断します。38.3項「カスタム・トランスポート・プロバイダの開発の必要性」を参照してください。
ソケット・トランスポート・プロバイダのサンプルを実行して検討します。このプロバイダのソース・コードはOracle Service Busと共にインストールされます。また、内容を検討したり再利用したりできるように一般に公開されています。第42章「サンプル・ソケット・トランスポート・プロバイダ」を参照してください。
第38章「設計上の考慮事項」を確認します。ここでは、トランスポート・プロバイダのアーキテクチャ、およびトランスポート・プロバイダで使用されるセキュリティ・モデルやスレッディング・モデルなど、トランスポート・プロバイダの設計の様々な側面について説明しています。
39.2項「始める前に」を確認します。
39.3項「開発の基本手順」では、スキーマの構成、インタフェースの実装を含め、トランスポート・プロバイダを開発する際に必要な手順について説明します。
39.4項「開発の重要トピック」では、開発サイクルで参照する必要がある、いくつかのトピックについて詳細に説明します。また、39.5項「メッセージの処理」、39.6項「メッセージの変換」、39.8項「エラー処理」などのトピックについて詳細に説明します。
トランスポート・プロバイダのパッケージ化およびデプロイの詳細は、第43章「トランスポート・プロバイダのデプロイ」を参照してください。
カスタム・トランスポート・プロバイダを開発する前に、以下のような設計上の問題について、検討および確認する必要があります。
カスタム・トランスポート・プロバイダを開発する必要があるかどうかを判断します。38.3項「カスタム・トランスポート・プロバイダの開発の必要性」を参照してください。
メッセージ・エンドポイントをトランザクション対応にするか、またはトランザクション非対応にするかを判断します。38.5.1.1項「トランザクション対応のエンドポイントとトランザクション非対応のエンドポイント」を参照してください。
メッセージ・エンドポイントを一方向、同期、非同期のいずれにするかを判断します。38.5.1.2項「サポートされているメッセージ・パターン」および38.5.2項「同期トランザクションのサポート」を参照してください。
送信メッセージと着信メッセージのセキュリティ要件を決定します。38.6項「セキュリティ・モデル」を参照してください。
Oracle Service Busで使用されるスレッディング・モデルについて理解します。38.7項「スレッディング・モデル」を参照してください。
トランスポート・プロバイダで同期アウトバウンド呼出しと非同期アウトバウンド呼出しのどちらがサポートされるかについて理解します。38.7.4項「非同期のサポート」を参照してください。
トランスポートSDKに用意されているインタフェースとクラスについて確認し、トランスポート・プロバイダの設計時部分および実行時部分にどのように適合するのかを理解します。第41章「トランスポートSDKのインタフェースおよびクラス」を参照してください。
カスタム・トランスポート・プロバイダをパッケージ化およびデプロイする方法について理解します。43章「トランスポート・プロバイダのデプロイ」を参照してください。
トランスポート・フレームワークを介したメソッド呼出しのフローを確認します。付録A「トランスポートSDKのUMLシーケンス・ダイアグラム」を参照してください。
カスタム・トランスポート・プロバイダを開発する際に従う基本手順は以下のとおりです。
39.3.1項「1. トランスポート・フレームワーク・コンポーネントの確認」
39.3.2項「2. トランスポート・プロジェクトのディレクトリ構造の作成」
39.3.3項「3. トランスポート固有のアーティファクトのXMLスキーマ・ファイルの作成」
39.3.4項「4. トランスポート固有のアーティファクトの定義」
39.3.5項「5. XMLBean TransportProviderConfigurationの定義」
39.3.6項「6. トランスポート・プロバイダのユーザー・インタフェースの実装」
39.3.8項「8. トランスポート・プロバイダのデプロイ」
図39-1は、カスタム・トランスポート・プロバイダを作成する際に、実装および構成する必要があるコンポーネントを示しています。トランスポート・マネージャは、トランスポート・プロバイダの登録を制御および管理し、Oracle Service Busとの通信を処理します。トランスポート・プロバイダは、トランスポート・エンドポイント(メッセージの送信元または送信先となるリソース)のライフ・サイクルおよび実行時の動作を管理します。カスタム・トランスポート・プロバイダを開発するには、トランスポートSDKを使用します。トランスポートSDKを使用してカスタム・トランスポート・プロバイダを開発することが、この章のテーマです。
実装および構成する必要があるトランスポート・サブシステムには、以下のものがあります。
トランスポートUIバインディング - トランスポート・プロバイダのユーザー・インタフェース・コンポーネント。関連するインタフェースの概要は、41.6項「ユーザー・インタフェースの構成」を参照してください。
トランスポート・エンドポイント - メッセージの送受信を行います。関連するインタフェースの概要は、41.3項「汎用クラスおよびインタフェース」を参照してください。
エンドポイント構成 - エンドポイント構成を格納します。関連するインタフェースの概要は、41.2項「スキーマで生成されるインタフェース」を参照してください。
トランスポート・メッセージ・コンテキスト - メッセージ(インバウンドおよびアウトバウンド)のリクエスト・ヘッダー、レスポンス・ヘッダー、およびその他の部分のメタデータが含まれています。41.4項「SourceおよびTransformerクラスとインタフェース」および41.5項「リクエストおよびレスポンス・メッセージのメタデータおよびヘッダーの表現」も参照してください。
WLSアーティファクト・デプロイヤ - (オプション)メッセージを送受信するサーブレットなどの、アーティファクトをデプロイします。
トランスポートの送信者 - アウトバウンド・メッセージおよびペイロードのメタデータを取得します。関連するインタフェースの概要は、41.3.2項「汎用インタフェースの概要」を参照してください。
トランスポートのリスナー - アウトバウンド・エンドポイントがOracle Service Busの残りの部分にアウトバウンド・リクエストの結果をポストできるようにします。41.5項「リクエストおよびレスポンス・メッセージのメタデータおよびヘッダーの表現」も参照してください。
リクエスト/レスポンスのメタデータ - 関連するインタフェースの概要については、41.5項「リクエストおよびレスポンス・メッセージのメタデータおよびヘッダーの表現」を参照してください。
新しいトランスポート・プロバイダを開発する前に、プロジェクトの適切なディレクトリ構造をセットアップします。サンプル・ソケット・トランスポート・プロバイダに使用されているディレクトリ構造をコピーすることをお薦めします。この構造の詳細は、42.2項「サンプルの場所とディレクトリ構造」を参照してください。
XMLスキーマ(xsd)ファイルを作成し、トランスポート固有の定義を記述します。このファイルは、サンプル・ソケット・トランスポート・プロバイダ用に開発されたスキーマ・ファイル(OSB_ORACLE_HOME/samples/servicebus/sample-transport/schemas/SocketTransport.xsd)を基に作成できます。
|
注意: SocketTransport.xsdファイルにより、TransportCommon.xsdファイルがインポートされます。このファイルは、サービス・エンドポイントの構成用の基本となるスキーマ定義ファイルです。このファイルは、OSB_ORACLE_HOME/lib/sb-schemas.jarにあります。続行する前に、このファイルのコンテンツを確認しておきます。 |
前の39.3.3項「3. トランスポート固有のアーティファクトのXMLスキーマ・ファイルの作成」で説明したXMLスキーマ・ファイルに、次のトランスポート固有のアーティファクトのXMLスキーマを定義します。
EndpointConfiguration
RequestMetaDataXML
ResponseMetaDataXML
|
注意: トランスポート・プロバイダ固有のメタデータおよびヘッダーを定義する場合は、単純なXMLタイプのみサポートされています。たとえば、ネストされた要素を持つ複雑なタイプはサポートされていません。さらに、特定の名前を持つヘッダーは最大1つしか使用できないという制限もあります。 |
|
ヒント: これらの各スキーマ定義は、対応するJavaファイルに変換された後、コンパイルされます。サンプル・ソケット・トランスポート・プロバイダの変換済みJavaソース・ファイルは、次のディレクトリにあります。 sample-transport/build/classes/com/bea/alsb/transports/sock/impl |
EndPointConfigurationは、エンドポイント構成のベース・タイプで、インバウンド・エンドポイントおよびアウトバウンド・エンドポイントのデプロイメントと操作に必要なパラメータの完全なセットを表します。この構成は、汎用的な部分とプロバイダ固有の部分で成り立ちます。EndPointConfigurationスキーマ定義の詳細は、TransportCommon.xsdファイルのドキュメント要素を参照してください。
プロバイダ固有のエンドポイント構成をスキーマ・ファイルに指定する必要があります。例39-1に、SocketTransport.xsdの抜粋を示します。
例39-1 SocketEndPointConfiguration定義のサンプル
<xs:complexType name="SocketEndpointConfiguration">
<xs:annotation>
<xs:documentation>
SocketTransport - specific configuration
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:choice>
<xs:element name="outbound-properties"
type="SocketOutboundPropertiesType"/>
<xs:element name="inbound-properties"
type="SocketInboundPropertiesType"/>
</xs:choice>
<xs:element name="request-response" type="xs:boolean">
<xs:annotation>
<xs:documentation>
Whether the message pattern is synchronous
request-response or one-way.
</xs:documentation>
</xs:annotation>
</xs:element>
...
各トランスポート・プロバイダは、メタデータ(メッセージ・ヘッダー)をPOJO (Plain Old Java Object)に格納し、パイプラインに渡す必要があります。メタデータとして送信できる情報の例には、Content-Typeヘッダー、セキュリティ情報、ロケール情報などがあります。RequestMetaData POJOは、RequestMetaData抽象クラスを拡張する汎用オブジェクトで、インバウンド・リクエストやアウトバウンド・リクエストのメッセージ・メタデータを表します。トランスポート・プロバイダでは、RequestMetaData POJOのメッセージ・メタデータをOracle Service Busランタイムに配信する必要があります。39.5.3項「リクエスト/レスポンスのメタデータの処理」も参照してください。
RequestMetaDataXMLは、同じRequestMetaData POJOをXMLで表現したものです。このXML表現では、Apache XML Beanテクノロジを使用します。アウトバウンド・リクエストのメタデータ全体を特定のXMLフラグメントに設定するなど、メッセージを処理するときにメタデータのXML表現を必要とするパイプラインでの操作を伴う場合のみ、Oracle Service Busランタイムで必要になります。
リクエスト・メタデータの構成をスキーマ・ファイルに指定する必要があります。例39-2に、SocketTransport.xsdの抜粋を示します。
例39-2 SocketRequestMetaDataXML定義のサンプル
<xs:complexType name="SocketRequestMetaDataXML">
<xs:annotation>
<xs:documentation/>
</xs:annotation>
<xs:complexContent>
<xs:extension base="ts:RequestMetaDataXML">
<xs:sequence>
<xs:element name="client-host"
type="xs:string" minOccurs="0">
<xs:annotation>
<xs:documentation>
Client host name
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="client-port" type="xs:int" minOccurs="0">
<xs:annotation>
<xs:documentation>Client port</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
RequestHeadersXMLは、一連のインバウンド・リクエスト・ヘッダーまたはアウトバウンド・リクエスト・ヘッダーのベース・タイプです。RequestHeadersXMLの構成をスキーマ・ファイルに指定する必要があります。例39-2に、SocketTransport.xsdの抜粋を示します。
例39-3 SocketRequestHeadersXML定義のサンプル
<xs:complexType name="SocketRequestHeadersXML">
<xs:annotation>
<xs:documentation/>
</xs:annotation>
<xs:complexContent>
<xs:extension base="ts:RequestHeadersXML">
<xs:sequence>
<xs:element name="message-count" type="xs:long" minOccurs="0">
<xs:annotation>
<xs:documentation>
Number of messages passed till now.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
ResponseMetaDataXMLは、インバウンド・メッセージまたはアウトバウンド・メッセージに対するレスポンスのメタデータのベース・タイプです。ResponseMetaDataXMLの構成をスキーマ・ファイルに指定する必要があります。例39-2に、SocketTransport.xsdの抜粋を示します。
例39-4 SocketResponseMetaDataXML定義のサンプル
<xs:complexType name="SocketResponseMetaDataXML">
<xs:complexContent>
<xs:extension base="ts:ResponseMetaDataXML">
<xs:sequence>
<xs:element name="service-endpoint-host"
type="xs:string" minOccurs="0">
<xs:annotation>
<xs:documentation>
Host name of the service end point connection.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="service-endpoint-ip"
type="xs:string" minOccurs="0">
<xs:annotation>
<xs:documentation>
IP address of the service end point connection.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
ResponseHeadersXMLは、一連のレスポンス・ヘッダーのベース・タイプです。ResponseHeadersXMLの構成をスキーマ・ファイルに指定する必要があります。例39-2に、SocketTransport.xsdの抜粋を示します。
TransportProviderConfiguration XML Beanを構成するには、トランスポート・プロバイダの構成ファイルを編集します。このXMLファイルは、トランスポート・プロバイダ・ルート・ディレクトリのconfigディレクトリにあります。サンプル・ソケット・トランスポート・プロバイダを実装する場合、このファイル(SocketConfig.xml)の場所については、42.2項「サンプルの場所とディレクトリ構造」を参照してください。
プロキシ・サービスでトランスポートを使用できるようにする場合、inbound-direction-supported要素をtrueに設定します。
ビジネス・サービスでトランスポートを使用できるようにする場合、outbound-direction-supported要素をtrueに設定します。
トランスポートが自己記述型の場合、self-described要素の値をtrueに設定します。自己記述トランスポートでは、そのサービスがエンドポイント構成に基づいて形式(スキーマまたはWSDL)を記述します。
トランスポートのtModelをUDDIにパブリッシュする場合、UDDI要素を含めます。詳細は、39.10項「UDDIレジストリへのプロキシ・サービスのパブリッシュ」を参照してください。
|
ヒント: TransportProviderConfigurationのスキーマは、OSB_ORACLE_HOME/lib/sb-schemas.jarにあるTransportCommon.xsdに定義されています。詳細は、スキーマ・ファイルを参照してください。 |
Oracle Service Busコンソールを使用してビジネス・サービスまたはプロキシ・サービスを追加する場合、サービス作成ウィザードでトランスポート・プロバイダを選択します。ウィザードには、Oracle Service Busで用意されているトランスポート・プロバイダ、およびトランスポートSDKで開発されたカスタム・トランスポート・プロバイダが表示されます。
この項では、カスタム・トランスポート・プロバイダをOracle Service Busコンソールのユーザー・インタフェースにバインドする、トランスポートSDK APIコンポーネントについて説明します。プロバイダをユーザー・インタフェースに接続するには、これらのAPIを実装する必要があります。
カスタム・トランスポートのユーザー・インタフェースの作成
新しいサービスを作成し、サービス作成ウィザードで「サービス・タイプ」を選択したら、そのサービスの種類に対して適切なトランスポート・プロバイダを選択する必要があります。選択内容を検証するために、ウィザードによりTransportUIBindingインタフェースの次のメソッドが呼び出されます。
public boolean isServiceTypeSupported(BindingTypeInfo binding)
このメソッドにより、トランスポート・プロバイダが、選択したサービスの種類に適しているかどうかが判定されます。
有効なトランスポート・プロバイダを選択したら、エンドポイントURIを入力します。このURIを検証するために、ウィザードによりTransportUIBindingインタフェースの次のメソッドが呼び出されます。
public TransportUIError[] validateMainForm(TransportEditField[] fields)
次に、トランスポート固有の構成のページがウィザードに表示されます。このページを表示するために、ウィザードによりTransportUIBindingインタフェースの次のメソッドが呼び出されます。
public TransportEditField[] getEditPage(EndPointConfiguration config, BindingTypeInfo binding) throws TransportException
トランスポートSDKは、構成ページにフィールドを表示する、TransportUIObjectsのセットを提供します。たとえば、テキスト・ボックス、チェック・ボックス、およびその他のタイプのUI要素を追加できます。これらを作成するには、TransportUIFactoryを使用します。作成したら、同じファクトリを使用して追加のプロパティを指定して、サービス作成ウィザードで表示可能なTransportEditFieldオブジェクトを取得します。
|
ヒント: イベントを大部分のUIフィールドに関連付けることができます。イベントは、TransportUIBindingクラスのコールバック・メカニズムのように動作するため、構成ページをリフレッシュ、検証、および更新することができます。イベントがトリガーされると、ウィザードにより次のメソッドが呼び出されます。updateEditPage(TransportEditField[] fields, String name) throws TransportException |
トランスポートの構成が完了すると、ウィザードにより次の検証メソッドが呼び出されます。
TransportUIError[] validateProviderSpecificForm(TransportEditField[] fields)
サービスを保存すると、トランスポート・マネージャによりTransportProviderクラスの次のメソッドが呼び出されます。
void validateEndPointConfiguration(TransportValidationContext context)
エラーが報告されない場合は、新しいエンドポイントが作成されます。次に、トランスポート・マネージャにより次のメソッドが呼び出されます。
TransportEndPoint createEndPoint(EndPointOperations.Create context) throws TransportException
このメソッドが正常に返されると、新しいサービスがOracle Service Busコンソールにリストされ、基底のトランスポート構成がTransportProviderのエンドポイントに関連付けられます。
|
注意: エンドポイント構成は、Oracle Service Busセッションに格納されます。サーバーを再起動するときに、トランスポート・プロバイダで保持したり復元したりする必要はありません。 |
セッションがアクティブになったら、エンドポイントをデプロイして、リクエストの処理を開始する必要があります。エンドポイントのデプロイおよびリクエストの処理の詳細は、39.11項「TransportWLSArtifactDeployerの実装が適している場合」および43.4項「クラスタへのデプロイ」を参照してください。
|
ヒント: サンプル・ソケット・トランスポート・プロバイダの場合、これらのインタフェースの実装はsample-transport/srcディレクトリにあります。 |
新しいカスタム・トランスポート・プロバイダでは、次の実行時インタフェースを実装している必要があります。トランスポートSDKインタフェースの概要、および関連するクラスは、第41章「トランスポートSDKのインタフェースおよびクラス」を参照してください。インタフェースとクラスの詳細は、Oracle Fusion MiddlewareのOracle Service Bus Java APIリファレンスを参照してください。
|
ヒント: サンプル・ソケット・トランスポート・プロバイダの場合、これらのインタフェースの実装はsample-transport/srcディレクトリにあります。 |
次の実行時インタフェースを実装します。
TransportProvider
TransportWLSArtifactDeployer
|
注意: エンドポイント作成時にOracle WebLogic Serverの変更リストに組み込まれるOracle WebLogic Server関連のアーティファクト(EAR/WAR/JARファイルなど)をトランスポート・プロバイダがデプロイする必要がある場合のみ、TransportWLSArtifactDeployerインタフェースを実装してください。詳細は、39.11項「TransportWLSArtifactDeployerの実装が適している場合」を参照してください。 |
TransportEndPoint
InboundTransportMessageContext
OutboundTransportMessageContext
Transformer
|
注意: トランスポート・プロバイダで、非標準のペイロード・バインディング(ストリーム、DOM、SAXまたはXMLBean以外)を使用する必要がある場合のみ、Transformerインタフェースを実装してください。詳細は、39.6項「メッセージの変換」を参照してください。 |
デプロイメントの詳細は、第43章「トランスポート・プロバイダのデプロイ」を参照してください。
この項では、カスタム・トランスポート・プロバイダの開発時に経験することがある、いくつかのトピックについて説明します。次のようなトピックがあります。
この項では、トランスポート・プロバイダでのメッセージ処理について説明します。以下のトピックがあります。
トランスポートSDKは、メッセージ・ペイロードを柔軟に表現できる点に特徴があります。ペイロードを処理するすべてのトランスポートSDK APIが、Sourceインタフェースを使用してメッセージ・コンテンツを表示します。
トランスポートSDKに用意されているSource派生のメッセージ・タイプには、以下のものがあります。
StreamSource
ByteArraySource
StringSource
XmlObjectSource
DOMSource
MFLSource
SAAJSource
MimeSource
|
注意: StreamSourceは、1度しか使用できないソースです。つまり、マーカー・インタフェースSingleUseSourceを実装しています。他のSourceの場合は、ソースから入力ストリームを何度でも取得できます。Sourceオブジェクトでは、毎回、入力ストリームを最初から取得します。SingleUseSourceの場合は、入力ストリームは1度しか取得できません。入力は、1度使用すると削除されます(ネットワーク・ソケットからのストリームなど)。ただし、Oracle Service Busでは、SingleUseSourceからの入力をバッファに入れ、基本的には、そのデータのすべてのコピーを保持します。転送プロバイダにSourceクラスを実装する場合、入力ストリームを最初から再取得できるかどうかを判断する必要があります。入力ストリームが、その性質上1度しか使用できないものである場合は、Sourceクラスでマーカー・インタフェースSingleUseStreamを実装してください。 |
トランスポートSDKには、Sourceオブジェクト間で変換するための、一連のトランスフォーマが用意されています。一連の標準表現との変換をサポートするものであれば、必要に応じて、新しいトランスフォーマを実装できます。詳細は、39.6項「メッセージの変換」を参照してください。また、38.8項「メッセージ・コンテンツの設計」も参照してください。
インバウンド・エンドポイントを実装して、インバウンド・メッセージをOracle Service Busランタイムに配信する場合、TransportManager.receiveMessage()を呼び出す必要があります。トランスポート・プロバイダは、ストリーム、DOM、SAXなどの標準のSource派生オブジェクトやカスタム・オブジェクトのいずれかで、インバウンド・メッセージ・ペイロードを自由に公開します。
Oracle Service Busでは、リクエストを送信したクライアントに対してレスポンス・メッセージを返信する必要がある場合、InboundTransportMessageContextでメソッドsetResponseMetaData()、setResponsePayload()、およびclose()を呼び出して、レスポンスの返信準備ができていることを示します。Oracle Service Busランタイムがインバウンド・トランスポート・メッセージ・コンテキストclose()メソッドを呼び出す場合、これは、インバウンド・リクエスト・メッセージを受信したスレッドとは異なるスレッドから行われます。トランザクションのセマンティクスに影響する可能性があるため、トランスポート・プロバイダでは、このことを認識している必要があります。また、close()メソッドが呼び出されるまで、トランスポート・プロバイダは、レスポンス・ペイロードおよびメタデータへのアクセスを試行できません。
各トランスポート・プロバイダでは、メタデータおよびヘッダーをPOJO (Plain Old Java Object)に格納し、パイプラインに渡す必要があります。Oracle Service BusでXMLBeanが必要となる場合もあります。このような場合は、APIを使用して、POJOからXMLBeanへの変換を実装する必要があります。
POJOからXMLに変換するために、実装する必要があるメソッドを以下に示します。
RequestHeaders.toXML() RequestMetaData<T>.toXML() ResponseHeaders.toXML() ResponseMetaData<T>.toXML()
逆方向(XMLからPOJO)の場合は、以下のメソッドを実装する必要があります。
TransportEndPoint.createRequestMetaData(RequestMetaDataXML) InboundTransportMessageContext.createResponseMetaData(ResponseMetaDataXML)
各トランスポート・プロバイダは、Oracle Service Busに対して、インバウンド・メッセージ・ペイロードの文字セット・エンコーディングを指定します。送信メッセージ(アウトバウンド・リクエストとインバウンド・レスポンス)の場合、Oracle Service Busに対して、送信ペイロードに使用する文字セット・エンコーディングを指定します。文字セット・エンコーディングは、リクエストとレスポンスのメタデータに指定されます。
ほとんどの場合、トランスポートがメタデータに挿入する文字コード・エンコーディングは、サービス構成で静的に指定されているエンコードです。数少ない例外の1つがHTTPトランスポートです。HTTPトランスポートでは、charsetパラメータがあるかどうかContent-Typeを検査し、サービスに構成されているすべてのエンコーディングをオーバーライドします。この処理は、HTTP仕様に準拠する上で必要です。他の転送プロトコルでも、同様な問題を処理する必要がある場合があります。
|
ヒント: 通常、サービスのエンコーディングは固定です。SHIFT_JISに指定されているプロキシに対して、UTF-16でエンコードされたメッセージを送信すると、通常、エラーと見なされます。トランスポート・プロバイダは、単にエンコーディングを確認する目的で、メッセージを検査する必要はありません。 |
送信メッセージの場合、トランスポート・プロバイダがOracle Service Busに対してアウトバウンド・リクエストに必要なエンコーディングを指定し、Oracle Service Busが必要に応じて変換を実行します。
発信メッセージの場合、トランスポートは常にこのエンコーディングに基づいている必要があります。また、このエンコーディングは、サービス構成に指定されているエンコーディングと同じであるとは限りません。不一致がある場合、トランスポートでは不一致を許可できますが、トランスポート以外の部分がエラーとみなして例外を送出する可能性があります。また、トランスポートには、エンコーディング要素を空白のままにする、追加オプションがあります。これにより、パイプラインでは、自由にエンコーディングを指定できます(パススルーを使用する場合など)。
特定のトランスポート・プロバイダがプロキシ・サービス・エンドポイントをサポートしている場合、ルーティング手順でそのプロバイダのプロキシ・サービスにルーティングするように、リクエスト・パイプラインを構成できます。さらに、パブリッシュ・アクション、またはビジネス・サービスではなくプロキシ・サービスに対してメッセージを送信するサービス・コールアウト・アクションが発生する場合があります。この使用例は、同じ場所に配置された呼出しと呼ばれます。
トランスポート・プロバイダは、同じ場所に配置された呼出しを認識し、それに応じて呼出しを処理する必要があります。プロキシ・サービス・エンドポイントの実装の性質によって異なりますが、トランスポート・プロバイダは呼出しの最適化を選択できます。その場合、呼出しは、トランスポート通信スタック全体およびすべてのインバウンド認可/認証を経由せずに、直ちにTransportManager.receiveMessage()を実質的に呼び出す直接呼出しになります。
|
ヒント: Oracle Service Busは、この最適化をHTTP、ファイル、電子メール、およびFTPトランスポート・プロバイダで実装しています。JMSプロバイダでは、送信操作と受信操作のトランザクション・セマンティクスを分離する必要があるため、この最適化は使用されません。 |
カスタム・トランスポート・プロバイダでこの最適化を使用する場合は、CoLocatedTransportMessageContextクラスを拡張して、TransportProvider.sendMessageAsync()が呼び出されたときにsend()メソッドを呼び出す必要があります。
Oracle Service Busランタイムがアウトバウンド・エンドポイントにメッセージを送信し、レスポンス・メッセージが返される場合、トランスポート・プロバイダは、このレスポンスを非同期で返す必要があります。TransportSendListener.onReceiveResponse()メソッドまたはTransportSendListener.onError()メソッドは、TransportProvider.sendMessageAsync()が呼び出されたスレッドとは異なるスレッドから呼び出される必要があるということです。
トランスポート・プロバイダで、非同期レスポンス・オプションの使用時に、JMSリクエストやHTTPリクエストへのレスポンスなど、レスポンスを非同期で取得する組込みのメカニズムがある場合、これは自然に行われます。ただし、トランスポート・プロバイダで、レスポンスを非同期で取得する組込みのメカニズムがない場合は、ブロック方式でアウトバウンド・リクエストを実行し、TransportManagerHelper.schedule()メソッドを使用して、新しいワーカー・スレッドをスケジュールできます。この場合、レスポンスはTransportSendListenerにポストされます。
Oracle Service Busで、リクエスト・ペイロードをアウトバウンド・メッセージに設定するか、またはレスポンス・ペイロードをインバウンド・メッセージに設定する必要がある場合、Sourceインタフェースから派生したオブジェクトを介して設定を行うようにトランスポート・プロバイダに依頼します。トランスポート・プロバイダでは、基底のトランスポート・レイヤーで必要な表現を決定し、Transformer.transform()メソッドを使用して、Sourceオブジェクトを目的のソースに変換する必要があります。
|
ヒント: メッセージ変換の詳細は、38.8項「メッセージ・コンテンツの設計」を参照してください。組込み変換のリストは、38.8.4項「組込みのトランスフォーメーション」および41.4項「SourceおよびTransformerクラスとインタフェース」を参照してください。 |
カスタム・トランスポート・プロバイダでは、新しい種類のトランスフォーメーションをサポートできます。アウトバウンド・メッセージを送信するために、トランスポート・プロバイダがDOMオブジェクトを使用する必要があるとします。setRequestPayload(Source src)で呼び出された場合、トランスポート・プロバイダは、次のメソッドを呼び出す必要があります。
TransportManagerHelper.getTransportManager().getTransformer(). transform(src, DOMSource.class, transformOptions)
メソッドの戻り値はDOMSourceで、DOMノードを取得する際に使用されます。
|
注意: トランスポート・プロバイダでストリームが必要な場合は、簡単な方法を使用できます。各Sourceオブジェクトでは、ストリームへのトランスフォーメーションをネイティブにサポートしています。 |
新しいトランスフォーメーションをカスタム・トランスポート・プロバイダに追加できます。たとえば、XYZSourceと呼ばれる、新しい種類のSource派生クラスを追加するとします。パフォーマンス上の理由から、トランスポート・プロバイダではXYZSourceから2つの標準SourceオブジェクトXmlObjectSourceおよびStreamSourceのいずれかへの変換を提供することをお薦めします。このような変換を行わない場合は、XYZSourceのStreamSource表現に基づいた汎用トランスフォーマが使用されます。もちろん、XYZSourceが内部構造を持たない単純なバイト・ベースのSourceである場合は、通常は、汎用トランスフォーマで十分です。TransportManagerに登録されているカスタム・トランスフォーマは、スレッド・セーフかつステートレスであることが前提です。
添付ファイルをサポートする場合、トランスポート・プロバイダには次の3つのオプションがあります。
TransportMessageContextが返すSourceは、MessageContextSourceのインスタンスである必要があります。このオプションには、MessageContextSourceでは、コンテンツがすでにコア・メッセージSourceと添付ファイルSourceに区分されている必要があるという制約があります。
SourceはMimeSourceのインスタンスで、Headersオブジェクトにはマルチ・パートContent-Typeヘッダーが含まれています。
Content-Typeは、固有の値multipart/relatedを持つ、トランスポート・プロバイダに事前定義されたヘッダーです。HTTPトランスポートと電子メール・トランスポートはいずれも、この3つ目のオプションに基づいて添付ファイルをサポートします。
TransportOptionsオブジェクトは、メッセージを送受信する際のオプションを指定するために使用されます。TransportOptionsオブジェクトは、インバウンド・メッセージの場合、トランスポート・プロバイダからトランスポート・マネージャに渡されます。アウトバウンド・メッセージの場合は、TransportOptionsオブジェクトは、Oracle Service Busランタイムからトランスポート・マネージャに渡され、最後にトランスポート・プロバイダに渡されます。
この項では、次のトピックについて説明します。
トランスポート・プロバイダは、TransportManager.receiveMessage()に次のパラメータを提供します。
QOS - exactly-onceまたはbest-effortのサービス品質を指定します。exactly-onceのサービス品質は、インバウンド・メッセージがトランザクション対応の場合に指定されます。
THROW_ON_ERROR - このフラグを設定すると、Oracle Service Busのパイプラインの処理中にエラーが発生した場合に、メソッドTransportManager.receiveMessage()の呼ばれた側に対して、例外がスローされます。例外スローのオプションには、インバウンド・メッセージに対して例外を返したり、エラーからレスポンス・メッセージを生成して、そのレスポンス・メッセージでインバウンド・メッセージに通知するものがあります。通常、QOSがexactly-once(トランザクション対応のメッセージ)の場合は、THROW_ON_ERRORをtrueに設定します。
たとえば、JMS/XAではこのフラグをtrueに設定し、同じリクエスト・スレッドで例外を送出するため、例外をロールバックするようにマークできます。HTTPでは再試行のメカニズムがないため、このフラグをfalseに設定します。エラーがステータス・コードに変換され、レスポンス・メッセージが返されます。
トランスポート固有の不透明なデータ - 不透明なデータは、トランスポート・プロバイダによって設定された任意のデータで、パイプラインを介してアウトバウンド呼出しに渡されます。この方法を使用すると、インバウンドとアウトバウンドで同じトランスポートを使用する場合に、パフォーマンスを最適化できます。不透明なデータは、パイプラインを介して、インバウンド・トランスポートからアウトバウンド・トランスポートに直接渡されます。たとえば、HTTP/Sトランスポート・プロバイダでは、IDのパススルー伝播を効率的にサポートするために、ユーザー名とパスワードをインバウンドからアウトバウンドに直接渡すことができます。
アウトバウンド処理の場合、Oracle Service Busランタイムは、トランスポート・マネージャに次のパラメータを指定します。トランスポート・マネージャは、これらのパラメータのいくつかを内部的に使用し、TransportProvider.sendMessageAsync()に伝播します。パラメータには次のものが含まれます。
QOS - exactly-onceのサービス品質を実現可能かどうかを指定します。たとえば、HTTPでは、サービス品質をexactly-onceに設定している場合、HTTP呼出しはブロックされています。best-effortに設定している場合、HTTP呼出しはブロックされません。
モード - 一方向または双方向(リクエスト/レスポンス)を指定します。38.2.3項「トランスポート・プロバイダのモード」も参照してください。
URI、再試行間隔、回数 - トランスポート・プロバイダは、URIを使用してアウトバウンド・トランスポート接続を初期化します。たとえば、HTTPトランスポート・プロバイダは、新しいHttpURLConnectionをインストールする際にURIを使用します。トランスポート・プロバイダでは、再試行間隔および回数を使用する必要はありません。
OperationName - トランスポート・プロバイダは、使用されているアウトバウンドWebサービスを認識する必要がある場合にOperationNameを使用します。トランスポート・マネージャは、このパラメータを使用してモニター統計を追跡します。
トランスポート固有の不透明なデータ - トランスポート固有の不透明なデータの例としては、HTTP/SのAuthorizationヘッダーの値があります。
リクエスト・モードは、REQUEST_ONLY(「一方向」とも呼ばれる)およびREQUEST_RESPONSEの2つの値を持つ列挙値として定義されます。これらのモードは、リクエストおよびレスポンスについて次のように解釈されます。
アウトバウンド・リクエストでは、パイプラインがTransportOptionsを介してモードを示し、トランスポート・プロバイダはそのモードを使用する必要があります。
インバウンド・リクエストでは、パイプラインがモードを認識し、REQUEST_ONLYモードを算出した場合は、インバウンド・リクエストを閉じてレスポンスを送信しません。
パイプラインがレスポンスを送信する場合は、レスポンスが空のときでもレスポンスが発生します。
本質的に一方向のトランスポートでは、トランスポートでレスポンス・メタデータを指定する必要はありません。
実行時例外がトランザクション対応モデルに与える影響については、3つの異なるケースがあります。これらのケースには、以下のようなものがあります。
39.8.1項「ケース1」: ビジネス・サービスのアウトバウンド呼出しの前に、リクエスト・パイプラインで例外が発生します。
39.8.2項「ケース2」: ビジネス・サービスの呼出し中に、例外が発生します。
39.8.3項「ケース3」: ビジネス・サービスの呼出しの後に、レスポンス・パイプラインで例外が発生します。
図39-2に示すように、ビジネス・サービスのアウトバウンド呼出しの前に、例外がリクエスト・パイプラインで発生します。たとえば、リクエスト・メッセージのコンテンツに対して特定のXQueryを実行すると、例外が生成されます。
リクエスト・パイプラインにユーザー構成エラー・ハンドラを構成している場合、ユーザー構成に従ってエラーが処理されます。それ以外の場合は、引数としてreceiveMessage()呼出しに渡されるトランスポート・オプションに従って、プロキシ・サービスがTransportManager.receiveMessage()の呼出し時に例外を捕捉するか、レスポンス・メタデータを介してエラーのInboundTransportMessageContext.close()メソッドで通知されます。プロキシ・サービスが、例外をスローする必要があることを示している場合は、try/catch句でreceiveMessage()を囲み、トランザクションをロールバックするようにマークします。
図39-3に示すように、ビジネス・サービスの呼出し中に、例外が発生します。アウトバウンド・トランスポート・プロバイダでは、次の処理のいずれかが行われます。
TransportProvider.sendMessageAsync()から例外をスローします。たとえば、外部サービスへのソケット接続を確立している最中にエラーが発生した場合、アウトバウンド・プロバイダは例外をスローします。このような状況は、誤ったURLや接続障害などのために、ビジネス・サービスを呼び出すことができない場合に発生します。この場合、トランスポート・プロバイダが例外を生成する必要があります。
TransportSendListener.onError()を介して、リスナーに通知します。たとえば、ビジネス・サービスを呼び出したときに、呼出しがエラーになった場合(SOAPフォルトなど)、トランスポート・プロバイダは例外を生成するかわりにTransportSendListener.onError()を呼び出す必要があります。
最初の例では、39.8.1項「ケース1」で説明したものと同じ例外処理が行われます。2つ目の例では、レスポンス・パイプラインにエラー・ハンドラを構成している場合、ユーザー構成に従ってエラーが処理されます。それ以外の場合は、InboundTransportMessageContext.close()のレスポンス・メタデータを介して、例外がプロキシ・サービス・エンドポイントに逆に伝播されます。
図39-4に示すように、ビジネス・サービスを呼び出した後、レスポンス・パイプラインで例外が発生します。レスポンス・パイプラインにユーザー定義のエラー・ハンドラがない場合、適切なレスポンス・メタデータを持つInboundTransportMessageContext.close()メソッドを使用して、エラーがプロキシ・サービス・エンドポイントに通知されます。インバウンド・トランスポート・エンドポイントが同期トランザクション・エンドポイントの場合、リクエストを受信したときにアクティブであったトランザクションがまだなおアクティブで、ロールバックできることが保証されます。インバウンド・エンドポイントがトランザクション対応でも同期型でもない場合、ロールバックするインバウンド・トランザクション・コンテキストがないため、他のアクションを実行する必要があります。
ビジネス・サービスが外部サービスへのアクセスを試行した時に、外部サービス・アプリケーションにSOAPフォルトなどのエラーが発生する場合、アプリケーションが修正されるまで、サービスによる後続の再試行によってエラーが発生します。
Oracle Service Busによって、アプリケーション・エラーの識別が可能になり、トランスポートを使用するときにアプリケーション・エラーの再試行を回避するオプションが提供されます。
この項では、トランスポート内のアプリケーション・エラーを捕捉して、アプリケーション・エラーの再試行を回避できるようにトランスポートを構成する方法について説明します。
トランスポート・プロバイダのコードでは、アプリケーション・エラーが発生した条件を識別する必要があります。
たとえば、Oracle Service Bus HTTPトランスポートにおいて、アプリケーション・エラーとは、HTTPレスポンスに500ステータス・コードがあり、空でないペイロードがあり、サービス・タイプと一致するコンテンツ・タイプ(SOAP用XMLなど)を持つエラーです。
エラーが定義されたアプリケーション・エラー条件を満たしている場合、以下のメソッドの1つを用いて、「TRANSPORT_ERROR_APPLICATION」タイプを返します。
リクエストでエラーが発生する - TransportProvider.sendMessageAsync()においてTRANSPORT_ERROR_APPLICATIONエラー・コードでTransportExceptionをスローします。
レスポンスでエラーが発生する - TRANSPORT_ERROR_APPLICATIONエラー・コードを使用して TransportSendListener.onError() スケジュールします。
トランスポートSDKは、発生したアプリケーション・エラーを識別して、それに応じて処理することができます。
トランスポートSDKは、アプリケーション・エラーをパイプラインの$fault変数に送信することもできます。
<Transport>Config.xmlファイルでは、 /osb_10.3/lib/sb-schemas.jarのTransportCommon.xsdスキーマに準拠して<ProviderConfiguration>要素の子として次の要素を入力します。
<declare-application-errors>true</declare-application-errors>
ユーザーがトランスポートを選択する場合、このエントリはビジネス・サービスのメインの「トランスポート構成」ページの「アプリケーション・エラーの再試行」オプションを提供します。この要素を入力しないと、デフォルト値はfalseで、アプリケーション・エラーを捕捉できず、アプリケーション・エラーの再試行オプションが提供されません。
Oracle Service Busはトランスポートにある接続エラーを識別することができます。これにより、アクセスできないエンドポイントURIを自動オフラインにするように、トランスポートSDKをトリガーします。たとえば、管理対象サーバーで実行されるOracle Service Busのあるクラスタに、サービス・リクエストに対して接続エラーが発生される管理対象サーバーは、自動的にエンドポイントURIをオフラインとしてマークすることができます。
以下の方法でエンドポイントURIを再有効化することができます。
ビジネス・サービスを構成すると、接続エラー後に再試行の頻度と回数を決定するために「再試行回数」と「再試行の反復間隔」を設定することができます。再試行により自動的にエンドポイントURIが再有効化された後の、サービスへの正常な接続。
「再試行の反復間隔」をゼロ(0)にすると、エンドポイントURIは無期限でオフラインになるため、手動で再有効化する必要があります。
ビジネス・サービスのための「操作設定」ページで、Oracle Service BusコンソールのオフラインになっているエンドポイントURIを手動で再有効化することができます。
自動化接続エラーの機能は以下の状況に対して適用されません。
サービス・パイプラインはエンドポイントURIを動的に$outbound/ctx:transport/ctx:uriに設定すると、トランスポートSDKは、エンドポイントURIが サービス構成に設定されていないので、URIをオフラインにすることはできません。
トランスポートSDKは接続ステータスを保持しません。サーバーを再起動すると、すべてのエンドポイントURIはオンラインと見なされます。
詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のビジネス・サービスのエンドポイントURIの管理に関する項を参照してください。
この項では、トランスポートにおける接続エラーを識別する方法について説明します。エラーが送出された後、接続エラーは、自動で影響を受けるエンドポイントURIをオフラインにするようにトランスポートSDKを設定します。
トランスポート・プロバイダのコードでは、接続エラーが発生した条件を識別する必要があります。
たとえば、Oracle Service Bus HTTPトランスポートにおいて、接続エラーとは、エンドポイントURIで接続しようとするとき、HTTPレスポンスに404ステータス・コードがあり、またはIOExceptionが発生するかを識別します。
例外が定義された接続エラー条件を満たしている場合、以下のメソッドの1つを用いて、「TRANSPORT_ERROR_CONNECTION」タイプを返します。
リクエストでエラーが発生する - TransportProvider.sendMessageAsync()においてTRANSPORT_ERROR_CONNECTIONエラー・コードでTransportExceptionをスローします。
レスポンスでエラーが発生する - TRANSPORT_ERROR_CONNECTIONエラー・コードを使用して TransportSendListener.onError() をスケジュールします。
これにより、トランスポートSDKは、接続エラーが発生した時にそのエラーを識別し、それに応じて処理できるようになります。
また、トランスポートSDKは、接続エラーをパイプラインの$fault変数に送信し、それをレスポンスに追加します。
この項では、トランスポートの実装に使用するカスタム環境の値タイプを定義する方法について説明します。TransportProvider.getEnvValues()メソッドを使用してエンドポイントに対する環境値を返す際に、これらのカスタム・タイプの環境値を宣言できます。
トランスポートを使用した場合、構成をインポートした後、値をカスタマイズするか、検索して置き換えるか、保存するためにOracle Service Busで使用される標準な環境値と同じようにカスタム環境の値タイプを使用できます。たとえば、トランスポート構成にあるサービス・アカウントまたはJMSキューにリファレンスを定義して保持することができます。
環境値のタイプは環境、操作、およびセキュリティの3つのカテゴリに分けられます。
カスタム変数は<Transport>Config.xmlファイルに追加します。XML構造を決定するスキーマはTransportCommon.xsdで、/osb_10.3/lib/sb-schemas.jarにあります。
次に示すのは、JMSトランスポートのJmsConfig.xmlにあるカスタム・セキュリティ変数の例です。
<env-value-type>
<name>JMS Service Accounts</name>
<localized-display-name>
<localizer-class>com.bea.wli.sb.transports.messages.
TransportsTextLocalizer</localizer-class>
<message-id>JMS_SERVICE_ACCOUNTS</message-id>
</localized-display-name>
<localized-description>
<localizer-class>com.bea.wli.sb.transports.messages.
TransportsTextLocalizer</localizer-class>
<message-id>JMS_SERVICE_ACCOUNTS</message-id>
</localized-description>
<simple-value>true</simple-value>
<category>security</category>
</env-value-type>
カスタム環境の値タイプに関する主要な要素の説明は、次のとおりです。
name –トランスポートSDKで使用する変数名です。
display-name – Oracle Service Busユーザー・インタフェースに表示する変数名です。以下は、ローカライゼーションの代替手段です。
localized-display-name – display-nameの代替のローカライズされたバージョン。
localizer-class –ローカライズされたdisplay-nameを含むローカライゼーション・プロパティのテキスト・ファイル。.properties拡張子は必須ではありません。
message-id –表示名の値を提供するローカライゼーション・プロパティ・ファイルにあるプロパティ。
description –環境値タイプの説明。ローカライゼーションでは、display-nameで説明されているlocalizer-classとmessage-idの子要素のかわりにlocalized-description要素を使用します。
simple-value – 環境値タイプが「環境」カテゴリである場合、simple-valueはOracle Service Busの検索と置換の機能を使用してこのタイプを検索できるかを決定します(trueまたはfalseの値)。
category – 環境値のカテゴリ(「環境」、「セキュリティ」、または「操作」)。カテゴリが「セキュリティ」または「操作」である場合、構成をインポートするときに環境値のタイプを保持するかどうかを決定できます。カテゴリが「環境」である場合、環境値のタイプを検索および置換できます。
UDDI (Universal Description, Discovery, and Integration)は、インターネット上のWebサービスを記述および検索するための標準メカニズムです。カスタム・トランスポート・プロバイダに基づいて、プロキシ・サービスをUDDIレジストリにパブリッシュできます。これにより、ビジネス・サービスをホストするサービスとして、プロキシ・サービスを異なるドメインのOracle Service Busサーバーにインポートできます。
プロキシ・サービスをパブリッシュするには、トランスポート・プロバイダは、TransportProviderConfiguration XMLスキーマ定義の「UDDI」セクションで、トランスポートのタイプを表すtModelを定義する必要があります(スキーマで生成されるインタフェースの詳細は、41.2項「スキーマで生成されるインタフェース」を参照してください)。
このtModelには、CategoryBagおよびkeyedReferenceが含まれている必要があります。また、keyedReferenceでは、tModelKeyがUDDIタイプのカテゴリ・システムに設定され、keyValueが「transport」になっている必要があります。このtModelでは、UDDI V3 tModelキーのみ指定する必要があります。
UDDIがこのトランスポートのタイプにtModelを定義している場合は、定義をコピーして、UDDIセクションに貼り付けてください。
例39-6に、このようなtModelの例を示します。
例39-6 tModelの例
<?xml version="1.0" encoding="UTF-8"?>
<ProviderConfiguration xmlns="http://www.bea.com/wli/sb/transports">
. . .
. . .
<UDDI>
<TModelDefinition>
<tModel tModelKey="uddi:bea.uddi.org:transport:socket">
<name>uddi-org:socket</name>
<description>Socket transport based webservice</description>
<overviewDoc>
<overviewURL useType="text">
http://www.bea.com/wli/sb/UDDIMapping#socket
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference keyName="uddi-org:types:transport"
keyValue="transport"
tModelKey="uddi:uddi.org:categorization:types"/>
</categoryBag>
</tModel>
</TModelDefinition>
</UDDI>
</ProviderConfiguration>
UDDIがこのトランスポートのタイプにtModelを定義していない場合、Oracle Service Busは、構成されたレジストリに、ここで定義するtModelをパブリッシュできます。Oracle Service BusにUDDIレジストリを構成している場合、「tModelsをレジストリにロード」オプションを指定できます。このオプションにより、カスタム・トランスポート・プロバイダのtModelを含め、Oracle Service BusのすべてのtModelが、UDDIレジストリにパブリッシュされます。トランスポート・プロバイダをデプロイすると、UDDIレジストリの構成を更新して、tModelをパブリッシュできます。
UDDIのエクスポート中に、TransportProvider.getBusinessServicePropertiesForProxy(Ref)が呼び出され、生成されたマップがUDDIレジストリにパブリッシュされます。UDDIのインポート処理中に、情報が失われることなくビジネス・サービスの定義を正確に作成できるよう、プロバイダは、ビジネス・サービスの重要なプロパティすべてをマップ内に確実に保持します。
UDDIのインポート中に、TransportProvider.getProviderSpecificConfiguration(Map)が呼び出され、プロバイダ固有のエンドポイント構成スキーマに準拠するXmlObjectが生成されて、サービス定義に含められます。
|
ヒント: OASIS (Organization for the Advancement of Structured Information Standards)では、UDDI標準を作成しています。完全な技術仕様を含め、UDDIの詳細は、http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=uddi-specを参照してください。 |
個々のサービス登録を処理する、2セットのトランスポート・プロバイダ・インタフェースが用意されています。TransportProviderには、作成、更新、削除、サスペンド、再開などのメソッドがあります。また、TransportWLSArtifactDeployerにも同じメソッドがあります。この項では、これら2つの実装について説明します。また、TransportWLSArtifactDeployerを実装する必要がある場合についても説明します。
TransportWLSArtifactDeployerを実装するのは、プロバイダが、Oracle Service BusドメインのOracle WebLogic Serverアーティファクトを変更する必要がある場合だけです。TransportWLSArtifactDeployerのメソッドは、管理サーバーでのみ呼び出すことができます。この場合、渡されたDomainMBean引数を使用して変更が行われ、クラスタ全体に変更が伝播されます。
TransportProviderメソッドは、ドメインのすべてのサーバー(管理サーバーおよび管理対象サーバー)で呼び出されます。管理対象サーバーでOracle Service Busドメインのアーティファクトは変更できないため、TransportProviderのメソッドを呼び出すのは、内部データ構造を更新する場合だけです。
特定のトランスポート・プロバイダがTransportWLSArtifactDeployerインタフェースを実装する場合、TransportProviderの対応するメソッドが呼び出される前に、TransportWLSArtifactDeployerのメソッドが呼び出されます。たとえば、TransportProvider.createEndPoint()が呼び出される前に、TransportWLSArtifactDeployer.onCreate()が呼び出されます。
TransportWLSArtifactDeployerの詳細は、41.3.2項「汎用インタフェースの概要」を参照してください。
設計環境(Eclipse)および実行時環境(Oracle Service Busコンソール)でカスタム・トランスポートのオンライン・ヘルプを提供することができます。ヘルプの提供は省略可能です。しかし、ヘルプを提供することで、サービスの作成者にトランスポートの構成プロセスを説明する際に非常に役立つ場合があります。
図39-5は、開発環境および実行時環境での、カスタム・トランスポートに付属するヘルプを示しています。
ここででは次のトピックについて説明します。
ここでは、EclipseおよびOracle Service Busコンソールでカスタム・トランスポートのヘルプを提供するために使用できる様々なオプションについて説明します。
|
注意: EclipseとOracle Service Busコンソールでは、トランスポートの構成においてユーザー・インタフェースおよび機能の点で異なる可能性があるため、両方の環境で個別のヘルプ・トピックを作成することを検討してください。 |
Eclipseヘルプは、Eclipseヘルプ・フレームワークに基づいています。Eclipseでカスタム・トランスポートのヘルプを実装する場合、次の選択肢があります。
Eclipseで[F1]を押すと起動する状況依存ヘルプは、ヘルプ・システム全体を表示する個別のヘルプ・ウィンドウを表示するのではなく、Eclipse内でヘルプ・トピックを表示します。図39-6は、Eclipseで状況依存ヘルプがどのように表示されるかを示しています。
すべてのネイティブなOracle Service Busトランスポートは、それぞれのトランスポート構成エディタから、状況依存ヘルプを提供します。
状況依存ヘルプの利点は、ユーザーがEclipseを離れずに、対象のヘルプ・トピックに迅速にアクセスできることです。これは、カスタム・トランスポートのヘルプで特に役立ちます。
Eclipseの「Help」メニューからアクセスできる、Eclipseヘルプ・システムで、カスタム・トランスポートのヘルプ・コンテンツを提供できます。Eclipseヘルプを起動すると、個別のウィンドウがヘルプ・システム全体の目次を表示します。
図39-7は、Eclipseヘルプ・システムでのトランスポートのオンライン・ヘルプを示しています。
図39-7に示すように、カスタム・トランスポートのパッケージ化および構成方法に応じて、ヘルプ・トピックを、ヘルプ・システムの目次の別の場所に表示させることができます。たとえば、トランスポートのヘルプをOracle Service Busヘルプ・トピックのトランスポートのセクションとマージしたり、トランスポートのヘルプをヘルプ・システムの最上位で提供したりすることができます。
Oracle Service Busコンソールで、実行時にトランスポート構成のヘルプを提供することもできます。Oracle Service Busコンソールは、独自の統合されたヘルプ・システムを提供しますが、Oracle Service Busは、図39-8に示すように、カスタム・トランスポートのヘルプを専用の独立したブラウザ・ウィンドウで表示します。カスタム・トランスポートのヘルプは、「トランスポート構成」ページで「ヘルプ」をクリックすると表示されます。
図39-8 Oracle Service Busコンソールから表示したカスタム・トランスポートのヘルプ
以降の項では、EclipseおよびOracle Service Busコンソールの両方で、カスタム・トランスポートのオンライン・ヘルプを提供する方法を示します。
Eclipseで、カスタム・トランスポートをサービスの構成で使用できるようにする場合、Eclipseの状況依存ヘルプまたはEclipseヘルプ・システムのいずれか、あるいはその両方として表示されるヘルプ・コンテンツを提供することができます。ここでは、その方法を示します。
サンプル・ソケット・トランスポートおよびOracle Service Busのネイティブなトランスポートは、Eclipseヘルプのベスト・プラクティスの参照実装を提供します。ここでは、これらを例として使用します。
トランスポートのヘルプは、トランスポート用に作成するEclipseプラグインの一部です。プラグインの作成の詳細は、第40章「Eclipse用のOracle Service Busトランスポートの開発」を参照してください。
状況依存ヘルプでは、ユーザーがEclipseでトランスポートを構成しているときに、トランスポート構成に関する情報をEclipseで直接得られます。
Eclipseのサービス・エディタのトランスポート構成ページで状況依存ヘルプを指定できます。
状況依存ヘルプを提供するには、以下の手順を実行する必要があります。
plugin.xmlで、context.xmlファイルを指し示すorg.eclipse.help.contextsの拡張を追加します。例39-7のorg.eclipse.help.contextsの例を参照してください。
このエントリは、context.xmlファイルを見つける場所をプラグインに示します。context.xmlファイルへのパスは、プラグインのルートからの相対パスです。
トランスポート構成のユーザー・インタフェースのコンテキストIDをヘルプ・ファイルにマップするcontext.xmlを作成します。Oracle Service Busでは、カスタム・トランスポートのコンテキストIDを自動的に提供します。39.12.2.3.3項「context.xml」を参照してください。
ヘルプ・トピックを作成します。39.12.2.3.4項「ヘルプ・コンテンツとリソース」を参照してください。
すべてのヘルプ・ファイルをパッケージ化します。39.12.2.4項「トランスポート・プラグインのヘルプのパッケージ化」を参照してください。
メインのEclipseヘルプ・システムにトランスポートのヘルプを追加できます。図39-7に示すように、ヘルプ・トピックが目次に表示されます。
plugin.xmlで、toc.xmlファイルを指し示すorg.eclipse.help.tocの拡張を追加します。例39-7のorg.eclipse.help.contextsの例を参照してください。次のガイダンスに従って、primary属性を設定します。
プラグインをJARファイルとしてパッケージ化する場合、または、図39-7の「Sample Transport」エントリで示されているように、トランスポートのヘルプをヘルプの目次の最上位に表示させる場合は、primary="true"を設定します。
図39-7のように、トランスポート・ヘルプをOracle Service Busのヘルプ・トピックとマージして表示する場合は、primary="false"と設定します。
トランスポート・ヘルプをOracle Service Busのメイン・ヘルプとマージして表示する場合は、トランスポート・プラグインを展開ディレクトリとしてパッケージ化する必要があります。
プラグインのパッケージ化の詳細は、第40章「Eclipse用のOracle Service Busトランスポートの開発」を参照してください。
トランスポートのヘルプの目次構造を提供するtoc.xmlファイルを作成します。39.12.2.3.2項「toc.xml」の例を参照してください。
ヘルプ・トピックを作成します。39.12.2.3.4項「ヘルプ・コンテンツとリソース」を参照してください。
すべてのヘルプ・ファイルをパッケージ化します。39.12.2.4項「トランスポート・プラグインのヘルプのパッケージ化」を参照してください。
Eclipseヘルプ・フレームワークを基盤とするEclipseヘルプは、ここで説明するリソースを必要とします。
前に説明した手順と共にこのリファレンスを使用して、Eclipseでのトランスポートのヘルプの実装を行ってください。
|
注意: Oracle Service Busは、OSB_ORACLE_HOME/samples/servicebus/sample-transportにあるサンプル・ソケット・トランスポートで、サンプルのヘルプ実装を提供しています。サンプル・トランスポートは、独自のカスタム・トランスポートおよびヘルプを開発する上で良い参考となる実装です。サンプルのplugin.xmlは/eclipseサブディレクトリに、ヘルプ・リソースは/helpサブディレクトリにあります。 |
ここでは、次のEclipseヘルプ・リソースについて説明します。
39.12.2.3.1項「plugin.xml」 – Eclipse(ヘルプ・システム)に追加するコンポーネントを指定する重要なファイルです。
39.12.2.3.2項「toc.xml」 – 図39-7に示されているように、ヘルプ・システムの目次に表示されるヘルプ・トピックの階層です。
39.12.2.3.3項「context.xml」 – トランスポート構成のユーザー・インタフェースの状況依存ヘルプを有効にします。
39.12.2.3.4項「ヘルプ・コンテンツとリソース」 – HTMLファイル、CSSファイル、イメージ、および提供する必要がある他のヘルプ・リソースです。
plugin.xmlファイルは、トランスポートおよびトランスポートのヘルプ・ファイルをEclipse環境に追加するための鍵となるファイルです。plugin.xmlに、ヘルプの目次(toc.xml)および状況依存ヘルプ(context.xml)のエントリを追加する必要があります。
例39-7は、OSB_ORACLE_HOME/samples/servicebus/sample-transport/eclipseディレクトリにあるサンプル・ソケット・トランスポートのplugin.xmlファイルでのtoc.xmlおよびcontext.xml(contexts_socketTransport.xml)エントリを示しています。
例39-7 トランスポートのplugin.xmlのサンプル
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.2"?>
<plugin>
...
<extension
point="org.eclipse.help.toc">
<toc file="/help/en/toc.xml" primary="true"/>
</extension>
<extension
point="org.eclipse.help.contexts">
<contexts
file="/help/en/contexts_socketTransport.xml"
plugin="Socket_Transport"/>
</extension>
</plugin>
plugin.xmlの重要な部分
すべてのパスは、プラグインのルート・ディレクトリからの相対パスです。
org.eclipse.help.toc拡張ポイントは、Eclipseヘルプ・システムの左側のナビゲーション領域への接続を作成します。
<toc file...>エントリは、トランスポートのヘルプ用に作成したヘルプ・トピックの階層を含むtoc.xmlファイルを参照します。
primary="true"属性は重要です。trueに設定した場合、トランスポートの目次がEclipseヘルプ・システムの最上位に表示されます。カスタム・トランスポート・プラグインをJARファイルとしてパッケージ化する場合は、trueに設定してください。
falseに設定した場合、toc.xmlはEclipseによって既存のtoc.xml (Oracle Service Busのメイン・ヘルプ・システムなど)の階層にマージされます。詳細は、次のtoc.xmlの項を参照してください。
org.eclipse.help.contextsのエントリにより、トランスポートのEclipseベースの状況依存([F1])ヘルプを実装できます。状況依存のヘルプ・トピックのリンクは、Eclipseの「Help」ビューの「Related Topics」領域に表示されます。
プラグインのパッケージ化の詳細は、第40章「Eclipse用のOracle Service Busトランスポートの開発」を参照してください。
toc.xmlファイルによって、カスタム・トランスポートのヘルプがEclipseヘルプ・システムの左側のナビゲーション領域にどのように表示されるかが決まります。例39-8は、Eclipseヘルプ・システムの目次の最上位レベルにトランスポートのヘルプを表示する方法を示します。
例39-8 サンプル・ソケット・トランスポートのtoc.xml (Eclipseヘルプ・システムの最上位エントリ)
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<?NLS TYPE="org.eclipse.help.toc"?>
<toc label="Socket Transport Sample">
<topic label="Socket Transport Configuration Page (Business Services)"
href="help/en/tpSOCKETTransportBizService.html"/>
<topic label="Socket Transport Configuration Page (Proxy Services)"
href="help/en/tpSOCKETTransportProxyService.html"/>
<topic label="Configuring the Socket Transport Sample (Service Bus Console)"
href="help/en/example.html"/>
</toc>
トランスポートのヘルプをEclipseヘルプ・システムの目次の最上位エントリに組み込む場合は、必ずplugin.xmlのorg.eclipse.help.toc拡張ポイントでprimary="true"を設定してください。
例39-9で示されているcontext.xmlファイルは、トランスポート・エディタ・ページのコンテキストIDをヘルプ・トピックにマップします。ユーザーがトランスポート構成ページで[F1]を押すと、図39-6に示すように、Eclipseが「Help」ビューにヘルプ・リンクを表示します。
例39-9 サンプル・ソケット・トランスポートのcontext.xmlサンプル(contexts_socketTransport.xml)
<?xml version="1.0" encoding="UTF-8"?>
<?NLS TYPE="org.eclipse.help.contexts"?>
<contexts>
<!-- Default Socket Transport help -->
<context id="tpSOCKETTransportBizService"
title="Socket Transport Configuration page (Business Service)">
<description>The Sample socket transport illustrates Transport SDK
concepts.</description>
<topic href="help/en/tpSOCKETTransportBizService.html"
label="Socket Transport Configuration Page (Business Services)"/>
</context>
<context id="tpSOCKETTransportProxyService"
title="Socket Transport Configuration page (Proxy Service)">
<description>The Sample socket transport illustrates Transport SDK
concepts.</description>
<topic href="help/en/tpSOCKETTransportProxyService.html"
label="Socket Transport Configuration Page (Proxy Services)"/>
</context>
</contexts>
context.xmlの重要な部分
context id属性の値は、エディタのユーザー・インタフェースのコンテキストIDです。
topic href属性は、ユーザーが[F1]を押したときにリンクするヘルプ・トピックをEclipseに示します。
topic label属性は、Eclipseの「Help」ビューの「Related Topics」領域に表示されるリンク・テキストを決定します。
description要素は、ユーザーが[F1]を押したときに表示されるリンクの上にテキストを提供します。
トランスポートのユーザー・インタフェースのコンテキストIDは自動的に提供されます。表39-1に示されているcontext id属性のパターンを大文字と小文字を区別してそのまま使用してください。idの値が正しくない場合、トランスポートの状況依存ヘルプが機能しません。
表39-1 トランスポート構成ページのコンテキストID
| ユーザー・インタフェース・コンポーネント | ID属性の値 |
|---|---|
|
ビジネス・サービス・エディタのトランスポート構成ページ |
tp<TRANSPORT_ID>TransportBizService –例: tpSOCKETTransportBizService |
|
プロキシ・サービス・エディタのトランスポート構成ページ |
tp<TRANSPORT_ID>TransportProxyService –例: tpSOCKETTransportProxyService |
<TRANSPORT_ID>の値は、トランスポートの文字列IDを設定するTransportProviderクラスの実装によって得られます。トランスポートIDに小文字を使用して名前を付けた場合でも、<TRANSPORT_ID>はすべて大文字である必要がある点に注意してください。
plugin.xmlで正確なパスを指定しさえすれば、context.xmlにユニークな名前(.xml拡張子を持つ)を付け、プラグイン・ディレクトリ内の任意の場所に配置できます。
context.xml内のすべてのパスは、プラグインのルート・ディレクトリからの相対パスです。
グラフィックスを含まない1つの単純なテキスト・ページから、多数のグラフィックス、PDFファイル、埋め込みのビデオなどを含む複数のページまで、提供するヘルプ・コンテンツのタイプを非常に柔軟に決定できます。
たとえば、単一のHTMLファイルを作成し、そのファイルをtoc.xmlおよびcontext.xmlファイルから参照したり、ビジネス・サービスおよびプロキシ・サービスのトランスポート構成のフィールドについて説明するヘルプ・ファイルや、概要を示すヘルプ・ファイルも個別に作成して、toc.xmlおよびcontext.xmlから、異なる組合せで3つのヘルプ・ファイルを指し示すこともできます。
ヘルプ・トピックとリソースは、toc.xmlおよびcontext.xmlでそれらを正確に参照しさえすれば、トランスポート・プラグインの任意の場所に格納することができます。
EclipseとOracle Service Busコンソールでは、トランスポートの構成においてユーザー・インタフェースおよび機能の点で異なる可能性があるため、EclipseとOracle Service Busコンソールで個別のヘルプ・トピックを作成することを検討してください。
トランスポート・プラグインには、以下が含まれている必要があります。
plugin.xmlファイル
トランスポート・クラスおよびサポート・ファイルを含むトランスポートJAR
toc.xml、context.xml、およびヘルプ・ファイルを含むhelpディレクトリ
トランスポート・プラグインのパッケージ化をJARとして行うか、展開ディレクトリとして行うかにかかわらず、トランスポートのヘルプとその他のリソースの関係については、以下のパッケージ化構造が推奨されます。
/plugin_root
plugin.xml
transport.jar
/help
/en(ロケール)
toc.xml
context.xml
/html
<ヘルプ・ファイルとリソース>
/enディレクトリを使用して、ローカライゼーションをサポートするようにヘルプがパッケージ化される点に注意してください。ローカライゼーションを行うには、Eclipseドキュメントの説明に従って、各ロケールのプラグインを作成する必要があります。
|
注意: ヘルプ・ファイルをdoc.zipファイルにパッケージ化することもできます。詳細は、『Eclipseプラットフォーム・プラグイン開発者ガイド』(http://help.eclipse.org/galileo/topic/org.eclipse.platform.doc.isv/guide/ua_help_content_files.htm)を参照してください。 |
Eclipseヘルプ・フレームワークの詳細は、http://help.eclipse.org/galileo/topic/org.eclipse.platform.doc.isv/guide/ua_help.htmにあるEclipseヘルプ・システムを参照してください。
プラグインのパッケージ化の詳細は、第40章「Eclipse用のOracle Service Busトランスポートの開発」を参照してください。
ここでは、Oracle Service Busコンソールで実行時にカスタム・トランスポートのヘルプを提供する方法を示します。Oracle Service Busは、図39-8に示されているように、カスタム・トランスポートのヘルプを、ブラウザで独立したヘルプ・ページとして表示します。
図39-9は、カスタム・トランスポートのOracle Service Busコンソール・ヘルプ・フレームワークの概要を示しています。
特定のOracle Service Busインタフェースを実装し、getHelpPage()メソッドを使用すると、ユーザー・インタフェースにフォーカスがある場合に、Oracle Service Busコンソールでユーザーが「ヘルプ」をクリックすると、単一のHTMLページが起動します。HTMLファイルには、次の内容を含めることができます。
テキスト、インラインCSS定義、インラインJavaScript関数
グラフィックスおよびその他のリソースへの参照。これは、これらのリソースがWebアプリケーションまたは外部Webサイトでホストされている場合に限ります。
ほとんどの場合、カスタム・トランスポートのすべてのヘルプにテキストおよびインライン形式を含めることができます。
ただし、グラフィックスおよびその他の外部リソースを含むすべての機能を備えたWebベースのヘルプを提供する場合は、それらのリソースがWebアプリケーションまたは外部Webサイトでホストされている必要があります。それらの外部リソースをHTMLファイルで参照するか、または、HTMLファイルから外部の場所へのリンクを提供する必要があります。たとえば、サンプル・ソケット・トランスポートのヘルプでは、最初のHTMLファイルから、カスタムWebアプリケーションで実行されているグラフィックスを含むヘルプ・トピックへのリンクを提供しています。埋め込みのJavaScript呼出しを使用して、希望する拡張されたヘルプのURLに自動的にリダイレクトするようにHTMLファイルをセット・アップすることもできます。
Oracle Service Busコンソールでのカスタム・トランスポートのヘルプの作成には、以下のタスクが含まれます。
カスタム・トランスポートの構成ユーザー・インタフェースを開発するには、TransportUIBindingインタフェースをカスタム・クラスに実装します。Oracle Service Busコンソールでトランスポート構成のユーザー・インタフェースのヘルプを提供するには、CustomHelpProviderインタフェースも実装する必要があります。CustomHelpProviderには、Oracle Service Busコンソールでトランスポート構成ページのヘルプを起動するために必要なgetHelpPage()メソッドが含まれます。
サンプル・ソケット・トランスポートでは、OSB_ORACLE_HOME/samples/servicebus/sample-transport/src/com/bea/alsb/transports/sockにあるSocketTransportUIBinding.javaクラスでCustomHelpProviderを実装します。
例39-10には、CustomHelpProviderの実装を示す抜粋部分が含まれています。
例39-10 Oracle Service Busコンソールでトランスポートのヘルプを提供するためのCustomHelpProviderの実装
public class SocketTransportUIBinding
implements TransportUIBinding, CustomHelpProvider {
.
.
.
public Reader getHelpPage() {
String helpFile = "help/en/contexts_socketTransport.html";
ClassLoader clLoader = Thread.currentThread().getContextClassLoader();
InputStream is = clLoader.getResourceAsStream(helpFile);
InputStreamReader helpReader = null;
if(is!=null)
helpReader = new InputStreamReader(is);
else
SocketTransportUtil.logger
.warning(SocketTransportMessagesLogger.noHelpPageAvailableLoggable().
getMessage(uiContext.getLocale()));
return helpReader;
}
}
例39-10では、Reader getHelpPage()が、Oracle Service BusコンソールがブラウザにHTMLページを送信するために使用するReaderストリームを返します。helpFileのパスは、トランスポートJAR内のルートからの相対パスです。
複数の言語でヘルプを提供する場合は、TransportUIContext.getLocale()を使用して、ローカライズされたコンテンツへの適切なパスを提供します。この場合は、/help/<ロケール>/your.htmlのロケールの値を提供します。
例39-10のhelp/en/contexts_socketTransport.htmlで示されているように、getHelpPage()メソッドが起動するHTMLファイルを作成します。
ヘルプの実装を簡潔に維持する場合は、テキスト、インラインCSS定義、およびインラインJavaScript関数を使用するHTMLファイルを作成してください。こうすることで、グラフィックスまたはその他の外部リソースをホストする個別のWebアプリケーションを作成する必要がなくなります。
ただし、グラフィックスやその他のリソースを含むように拡張したヘルプを作成する場合は、それらの外部リソースを次のようにHTMLファイルで参照してください。
img src="/help_socket/help/en/wwimages/addProject.gif"
または
a href="http://www.yoursite.com"
例39-11で示されているように、埋込みのJavaScript呼出しを使用して、拡張されたヘルプに自動的にリダイレクトするようにHTMLファイルをセットアップすることもできます。この例では、サンプル・ソケット・トランスポートのHTMLページから、拡張されたhelp_socket Webアプリケーションのヘルプ・コンテンツにリダイレクトしています。
例39-11 リダイレクトを提供するJavaScript関数
<script language="JavaScript" type="text/javascript"> <!-- Begin window.location="/help_socket/help/en/example.html"; // End --> </script>
サンプル・ソケット・トランスポートのHTMLファイルが、拡張されたヘルプへのリンクを提供しています。HTMLファイルcontexts_socketTransport.htmlは、OSB_ORACLE_HOME/samples/servicebus/sample-transport/resources/help/en/にあります。
トランスポートのヘルプで基本的なテキストのHTMLファイル以上のものが必要な場合は、以下の様々な方法を使用して、グラフィックスやその他のリソースを含めた拡張ヘルプを提供することができます。
独立したHTMLファイルから既存のURLにリンクします(トランスポートに関するドキュメントを含む既存のWebサイトがある場合など)。必要な作業は、独立したHTMLファイルからURLへのリンクの提供のみです。外部サイトでホストされているグラフィックスやその他のリソースへの参照を挿入することもできます。
拡張されたヘルプ用のWebアプリケーションを作成して、トランスポートにバンドルし、リンクするか、HTMLファイルからグラフィックスやその他のリソースを参照します。このトピックでは、トランスポートEARにバンドルして、拡張されたトランスポートのヘルプを表示するWebアプリケーションの作成手順について説明します。
Webアプリケーションの以下のファイルを作成します。
application.xmlで、WebアプリケーションのルートURLに使用されるコンテキスト・ルートをWebアプリケーションに提供します。たとえば、例39-12は、サンプル・ソケット・トランスポートのWebアプリケーションのコンテキスト・ルートを示しています。
例39-12 サンプル・ソケット・トランスポートのWebアプリケーションのapplication.xml
<application>
<display-name>Socket Transport</display-name>
<description>Socket Transport</description>
<module>
<web>
<web-uri>webapp</web-uri>
<context-root>help_socket</context-root>
</web>
</module>
</application>
サンプル・ソケット・トランスポートのapplication.xmlファイルはOSB_ORACLE_HOME/samples/servicebus/sample-transport/META-INF/にあります。
このエントリは、ファイル・システムのディレクトリ/webappをエイリアスのWebアプリケーションのルートURLにマップします。
http://server:port/help_socket/
ヘルプ・ファイルが、/help/en/などのディレクトリにあるWebアプリケーション内にある場合、拡張されたヘルプの完全なURLは以下のようになります。
http://server:port/help_socket/help/en/index.html
ただし、ヘルプへの内部リンクの場合は、以下のみで済みます。
/help_socket/help/en/index.html
ここで、index.htmlは、リンク先のHTMLページです。
web.xmlで、Webアプリケーションの表示名および説明を入力します。これは、標準のデプロイメント記述子情報です。たとえば、例39-13は、サンプル・ソケット・トランスポートのWebアプリケーションの名前および説明を示しています。
例39-13 サンプル・ソケット・トランスポートのWebアプリケーションのweb.xml
<web-app>
<display-name>Sample Socket Transport Help WebApp</display-name>
<description>
This webapp implements the help webapp for the socket transport.
</description>
</web-app>
サンプル・ソケット・トランスポートのweb.xmlファイルはOSB_ORACLE_HOME/samples/servicebus/sample-transport/webapp/WEB-INF/にあります。
拡張されたヘルプ・ファイルを作成し、Webアプリケーション・ディレクトリ内にパッケージ化します。サンプル・ソケット・トランスポートでは、ヘルプ・ファイルはOSB_ORACLE_HOME/samples/servicebus/sample-transport/resources/help/enに格納されています。
|
注意: ソケット・トランスポートのヘルプ・ファイルが/webappディレクトリに格納されてないのは、helpディレクトリにEclipseプラグインとOracle Service Busコンソールの両方のヘルプ・ファイルとリソースが格納されているためです。サンプル・ソケットのANTビルドが、トランスポートJAR、トランスポートEAR、およびEclipseプラグインを作成する場合は、ヘルプは別の方法でパッケージ化されます。トランスポートEARのビルドの場合、ヘルプ・ファイルは/webappディレクトリの下に移動します。 |
EclipseとOracle Service Busコンソールでは、トランスポートの構成においてユーザー・インタフェースおよび機能の点で異なる可能性があるため、EclipseとOracle Service Busコンソールで個別のヘルプ・トピックを作成することを検討してください。
トランスポートEARには、以下が含まれている必要があります。
以下を含む、APP-INF/libに格納されたトランスポートJAR
トランスポート・クラスとサポート・ファイル
トランスポートのヘルプのHTMLファイル。ローカライゼーションをサポートするためにhelp/en/などのディレクトリにあることが理想的です。
(オプション)トランスポートの拡張されたヘルプを含むWebアプリケーション
