|
|
転送 SDK は、転送プロトコルと AquaLogic Service Bus ランタイム システムとの間に抽象のレイヤを提供します。この抽象のレイヤでは、新しい転送プロバイダを開発して AquaLogic Service Bus にプラグインできます。転送 SDK インタフェースは、HTTP などの転送プロトコルと AquaLogic Service Bus ランタイムの間を橋渡しします。
| ヒント : | この章を始める前に、必ず「設計上の考慮事項」を確認してください。 |
この章では、カスタム転送プロバイダの開発に必要な基本手順について説明します。この章の内容は以下のとおりです。
カスタム転送プロバイダを設計および構築するプロセスは複雑です。この節では、転送プロバイダを開発する際の推奨事項について説明します。カスタム転送プロバイダの開発は、以下の基本的な手順に分類されます。
「開発の基本手順」では、スキーマのコンフィグレーション、インタフェースの実装を含め、転送プロバイダを開発する際に必要な手順について説明します。
「開発の重要トピック」では、開発サイクルで参照する必要がある、いくつかのトピックについて詳細に説明します。ここでは、「メッセージの処理」、「メッセージの変換」、「エラーの処理」などのトピックについて詳細に説明します。
転送プロバイダのパッケージ化およびデプロイの詳細については、「転送プロバイダのデプロイ」を参照してください。
カスタム転送プロバイダを開発する前に、以下のような設計上の問題について、検討および確認する必要があります。
カスタム転送プロバイダを開発する際に従う基本手順は以下のとおりです。
3. 転送固有のアーティファクトの XML スキーマ ファイルの作成
5. XMLBean TransportProviderConfiguration の定義
図 3-1 は、カスタム転送プロバイダを作成する際に、実装およびコンフィグレーションする必要があるコンポーネントを示しています。転送マネージャは、転送プロバイダの登録を制御および管理し、AquaLogic Service Bus との通信を処理します。転送プロバイダは、転送エンドポイント (メッセージの送信元または送信先となるリソース) のライフサイクルおよび実行時の動作を管理します。カスタム転送プロバイダを開発するには、転送 SDK を使用します。転送 SDK を使用してカスタム転送プロバイダを開発することが、この章のテーマです。
実装およびコンフィグレーションする必要がある転送サブシステムには、以下のものがあります。
新しい転送プロバイダを開発する前に、プロジェクトの適切なディレクトリ構造をセットアップします。サンプル ソケット転送プロバイダに使用されているディレクトリ構造をコピーすることをお勧めします。この構造の詳細については、「サンプルの場所とディレクトリ構造」を参照してください。
XML スキーマ (xsd) ファイルを作成し、転送固有の定義を記述します。このファイルは、サンプル ソケット転送プロバイダ用に開発されたスキーマ ファイルを基に作成できます。
BEA_HOME/weblogic92/samples/servicebus/sample-transport/schemas/
SocketTransport.xsd
ここで、BEA_HOME は AquaLogic Service Bus をインストールしたディレクトリです。
| 注意 : | SocketTransport.xsd ファイルにより、TransportCommon.xsd ファイルがインポートされます。このファイルは、サービス エンドポイントのコンフィグレーション用の基本となるスキーマ定義ファイルです。BEA_HOME/weblogic92/servicebus/lib/sb-public.jar にあります。続行する前に、このファイルのコンテンツを確認しておきます。 |
前の節「3. 転送固有のアーティファクトの XML スキーマ ファイルの作成」で説明した XML スキーマ ファイルに、次の転送固有のアーティファクトの XML スキーマを定義します。
| 注意 : | 転送プロバイダ固有のメタデータおよびヘッダを定義する場合は、単純な XML タイプのみサポートされています。たとえば、ネストされた要素を持つ複雑なタイプはサポートされていません。さらに、特定の名前を持つヘッダは最大 1 つしか使用できないという制限もあります。 |
| ヒント : | これらの各スキーマ定義は、対応する Java ファイルに変換された後、コンパイルされます。サンプル ソケット転送プロバイダの変換済み Java ソース ファイルは、次のディレクトリにあります。sample-transport/build/classes/com/bea/alsb/transports/sock/impl |
EndPointConfiguration は、エンドポイント コンフィグレーションの基本型で、着信エンドポイントおよび発信エンドポイントのデプロイメントと操作に必要なパラメータの完全なセットを表します。このコンフィグレーションは、汎用的な部分とプロバイダ固有の部分で構成されます。EndPointConfiguration スキーマ定義の詳細については、TransportCommon.xsd ファイルのドキュメント要素を参照してください。
プロバイダ固有のエンドポイント コンフィグレーションをスキーマ ファイルに指定する必要があります。コード リスト 3-1 に、SocketTransport.xsd の抜粋を示します。
<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 のメッセージ メタデータを AquaLogic Service Bus ランタイムに配信する必要があります。「要求/応答のメタデータの処理」も参照してください。
RequestMetaDataXML は、同じ RequestMetaData POJO を XML で表現したものです。この XML 表現では、Apache XML Bean テクノロジを使用します。発信要求のメタデータ全体を特定の XML フラグメントに設定するなど、メッセージを処理するときにメタデータの XML 表現を必要とするパイプラインでの操作を伴う場合のみ、AquaLogic Service Bus ランタイムで必要になります。
要求メタデータのコンフィグレーションをスキーマ ファイルに指定する必要があります。コード リスト 3-2 に、SocketTransport.xsd の抜粋を示します。
<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 のコンフィグレーションをスキーマ ファイルに指定する必要があります。コード リスト 3-3 に、SocketTransport.xsd の抜粋を示します。
<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 のコンフィグレーションをスキーマ ファイルに指定する必要があります。コード リスト 3-4 に、SocketTransport.xsd の抜粋を示します。
<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 のコンフィグレーションをスキーマ ファイルに指定する必要があります。コード リスト 3-5 に、SocketTransport.xsd の抜粋を示します。
<xs:complexType name="SocketResponseHeadersXML">
<xs:annotation>
<xs:documentation/>
</xs:annotation>
<xs:complexContent>
<xs:extension base="ts:ResponseHeadersXML"/>
</xs:complexContent>
</xs:complexType>
TransportProviderConfiguration XML Bean をコンフィグレーションするには、転送プロバイダのコンフィグレーション ファイルを編集します。この XML ファイルは、転送プロバイダ ルート ディレクトリの config ディレクトリにあります。サンプル ソケット転送プロバイダを実装する場合、このファイル (SocketConfig.xml) の場所については、「サンプルの場所とディレクトリ構造」を参照してください。
inbound-direction-supported 要素を true に設定する。 outbound-direction-supported 要素を true に設定する。 self-described 要素の値を true に設定する。自己記述転送では、そのサービスがエンドポイント コンフィグレーションに基づいて形式 (スキーマまたは WSDL) を記述します。UDDI 要素を含める。詳細については、「UDDI レジストリへのプロキシ サービスのパブリッシュ」を参照してください。| ヒント : | TransportProviderConfiguration のスキーマは、BEA_HOME/weblogic92/servicebus/lib/sb-public.jar にある TransportCommon.xsd に定義されています。詳細については、スキーマ ファイルを参照してください。 |
AquaLogic Service Bus Console を使用してビジネス サービスまたはプロキシ サービスを追加する場合、サービスの作成ウィザードのメニューから、転送プロバイダを選択します。このメニューには、AquaLogic Service Bus で用意されている転送プロバイダ、および転送 SDK で開発されたカスタム転送プロバイダが表示されます。
この節では、カスタム転送プロバイダを AquaLogic Service Bus Console のユーザ インタフェースにバインドする、転送 SDK API コンポーネントについて説明します。プロバイダをユーザ インタフェースに接続するには、これらの API を実装する必要があります。
| ヒント : | この節では、サービスの作成ウィザードに慣れていることを前提としています。詳細な例については、「ソケット転送のコンフィグレーションのサンプル」を参照してください。 |
public boolean isServiceTypeSupported(BindingTypeInfo binding)
このメソッドにより、転送プロバイダが、選択したサービスの種類に適しているかどうかが判定されます。
public TransportUIError[] validateMainForm(TransportEditField[] fields)
public TransportEditField[] getEditPage(EndPointConfiguration config, BindingTypeInfo binding) throws TransportException
転送 SDK は、コンフィグレーション ページにフィールドを表示する、TransportUIObjects のセットを提供します。たとえば、テキスト ボックス、チェックボックス、およびその他のタイプの UI 要素を追加できます。これらを作成するには、TransportUIFactory を使用します。作成したら、同じファクトリを使用して追加のプロパティを指定して、サービスの作成ウィザードで表示可能な TransportEditField オブジェクトを取得します。
使用可能な TransportUIObjects の詳細なリストについては、Javadoc を参照してください。
| ヒント : | イベントを大部分の UI フィールドに関連付けることができます。イベントは、TransportUIBinding クラスのコールバック メカニズムのように動作するため、コンフィグレーション ページをリフレッシュ、検証、および更新することができます。イベントがトリガされると、ウィザードにより次のメソッドが呼び出されます。updateEditPage(TransportEditField[] fields, String name) throws TransportException |
TransportUIError[] validateProviderSpecificForm(TransportEditField[] fields)
public TransportViewField[] getViewPage(EndPointConfiguration config) throws TransportException
void validateEndPointConfiguration(TransportValidationContext context)
エラーが報告されない場合は、新しいエンドポイントが作成されます。次に、転送マネージャにより次のメソッドが呼び出されます。
TransportEndPoint createEndPoint(EndPointOperations.Create context) throws TransportException
このメソッドが正常に返されると、新しいサービスが AquaLogic Service Bus Console にリストされ、基になる転送コンフィグレーションが TransportProvider のエンドポイントに関連付けられます。
| 注意 : | エンドポイント コンフィグレーションは、AquaLogic Service Bus セッションに格納されます。サーバを再起動するときに、転送プロバイダで保持したり復元したりする必要はありません。 |
| ヒント : | サンプル ソケット転送プロバイダの場合、これらのインタフェースの実装は sample-transport/src ディレクトリにあります。 |
新しいカスタム転送プロバイダでは、以下のランタイム インタフェースを実装している必要があります。転送 SDK インタフェースの概要、および関連するクラスについては、「転送 SDK のインタフェースおよびクラス」を参照してください。インタフェースとクラスの詳細については、AquaLogic Service Bus の Javadoc の説明を参照してください。
| ヒント : | サンプル ソケット転送プロバイダの場合、これらのインタフェースの実装は sample-transport/src ディレクトリにあります。 |
| 注意 : | 転送プロバイダで、エンドポイントの作成時に WebLogic Server 変更リストに記載される、WebLogic Server 関連のアーティファクト (EAR/WAR/JAR ファイルなど) をデプロイする必要がある場合は、TransportWLSArtifactDeployer インタフェースのみを実装してください。詳細については、「TransportWLSArtifactDeployer の実装が適している場合」を参照してください。 |
| 注意 : | 転送プロバイダで、非標準の、つまり、ストリーム、DOM、SAX、XMLBean などではないペイロード バインディングを使用する必要がある場合は、転送インタフェースのみを実装してください。詳細については、「メッセージの変換」を参照してください。 |
デプロイメントの詳細については、「転送プロバイダのデプロイ」を参照してください。
この節では、カスタム転送プロバイダの開発時に経験することがある、いくつかのトピックについて説明します。次のようなトピックがあります。
この節では、転送プロバイダでのメッセージ処理について説明します。以下のトピックがあります。
転送 SDK は、メッセージ ペイロードを柔軟に表現できる点に特徴があります。ペイロードを処理するすべての転送 SDK API が、Source インタフェースを使用してメッセージ コンテンツを表示します。
転送 SDK に用意されている Source 派生のメッセージ タイプには、以下のものがあります。
| 注意 : | StreamSource は、1 度しか使用できないソースです。つまり、マーカ インタフェース SingleUseSource を実装しています。他の Source の場合は、ソースから入力ストリームを何度でも取得できます。Source オブジェクトでは、毎回、入力ストリームを最初から取得します。SingleUseSource の場合は、入力ストリームは 1 度しか取得できません。入力は、1 度使用すると削除されます (ネットワーク ソケットからのストリームなど)。ただし、AquaLogic Service Bus では、SingleUseSource からの入力をバッファに入れ、基本的には、そのデータのすべてのコピーを保持します。 |
| 注意 : | 転送プロバイダに Source クラスを実装する場合、入力ストリームを最初から再取得できるかどうかを判断する必要があります。入力ストリームが、その性質上 1 度しか使用できないものである場合は、Source クラスでマーカ インタフェース SingleUseStream を実装することをお勧めします。 |
転送 SDK には、Source オブジェクト間で変換するための、一連のトランスフォーマが用意されています。一連の標準表現との変換をサポートするものであれば、必要に応じて、新しいトランスフォーマを実装できます。詳細については、「メッセージの変換」を参照してください。また、「メッセージ コンテンツの設計」も参照してください。
着信エンドポイントを実装して、着信メッセージを AquaLogic Service Bus ランタイムに配信する場合、TransportManager.receiveMessage() を呼び出す必要があります。転送プロバイダは、ストリーム、DOM、SAX などの標準の Source 派生オブジェクトやカスタム オブジェクトのいずれかで、着信メッセージ ペイロードを自由にエクスポーズします。
AquaLogic Service Bus では、要求を送信したクライアントに対して応答メッセージを返信する必要がある場合、InboundTransportMessageContext でメソッド setResponseMetaData()、setResponsePayload()、および close() を呼び出して、応答の返信準備ができていることを示します。AquaLogic Service Bus ランタイムが着信転送メッセージ コンテキスト close() メソッドを呼び出す場合、これは、着信要求メッセージを受信したスレッドとは異なるスレッドから行われます。トランザクションのセマンティクスに影響する可能性があるため、転送プロバイダでは、このことを認識している必要があります。また、close() メソッドが呼び出されるまで、転送プロバイダは、応答ペイロードおよびメタデータへのアクセスを試行できません。
各転送プロバイダでは、メタデータおよびヘッダを POJO (Plain Old Java Object) に格納し、パイプラインに渡す必要があります。AquaLogic Service Bus で XMLBean が必要となる場合もあります。このような場合は、API を使用して、POJO から XMLBean への変換を実装する必要があります。
POJO から XML に変換するために、実装する必要があるメソッドを以下に示します。
逆方向 (XML から POJO) の場合は、以下のメソッドを実装する必要があります。
各転送プロバイダは、AquaLogic Service Bus に対して、着信メッセージ ペイロードの文字セット エンコーディングを指定します。送信メッセージ (発信要求と着信応答) の場合、AquaLogic Service Bus に対して、送信ペイロードに使用する文字セット エンコーディングを指定します。文字セット エンコーディングは、要求と応答のメタデータに指定されます。
ほとんどの場合、転送がメタデータに挿入する文字コード エンコーディングは、サービス コンフィグレーションで静的に指定されているエンコードです。数少ない例外の 1 つが HTTP 転送です。HTTP 転送では、「charset」パラメータがあるかどうか Content-Type を検査し、サービスにコンフィグレーションされているすべてのエンコーディングをオーバーライドします。この処理は、HTTP 仕様に準拠する上で必要です。他の転送プロトコルでも、同様な問題を処理する必要がある場合があります。
| ヒント : | 通常、サービスのエンコーディングは固定です。SHIFT_JIS に指定されているプロキシに対して、UTF-16 でコード化されたメッセージを送信すると、通常、エラーと見なされます。転送プロバイダは、単にエンコーディングを確認する目的で、メッセージを検査する必要はありません。 |
送信メッセージの場合、転送プロバイダが AquaLogic Service Bus に対して発信要求に必要なエンコーディングを指定し、AquaLogic Service Bus が必要に応じて変換を実行します。
発信メッセージの場合、転送は常にこのエンコーディングに基づいている必要があります。また、このエンコーディングは、サービス コンフィグレーションに指定されているエンコーディングと同じであるとは限りません。不一致がある場合、転送では不一致を許可できますが、転送以外の部分がエラーとみなして例外を送出する可能性があります。また、転送には、エンコーディング要素を空白のままにする、追加オプションがあります。これにより、パイプラインでは、自由にエンコーディングを指定できます (パススルーを使用する場合など)。
特定の転送プロバイダがプロキシ サービス エンドポイントをサポートしている場合、ルーティング手順でそのプロバイダのプロキシ サービスにルーティングするように、要求パイプラインをコンフィグレーションできます。さらに、パブリッシュ アクション、またはビジネス サービスではなくプロキシ サービスに対してメッセージを送信するサービス コールアウト アクションが発生する場合があります。この使用例は、同じ場所に配置された呼び出しと呼ばれます。
転送プロバイダは、同じ場所に配置された呼び出しを認識し、それに従って処理する必要があります。プロキシ サービス エンドポイントの実装の性質によって、転送プロバイダは、このような、転送通信スタック全体およびすべての着信認可/認証を経由しないように呼び出しを最適化して、直ちに TransportManager.receiveMessage() を効率的に呼び出す、直接呼び出しを選択できます。
| ヒント : | AquaLogic Service Bus は、この最適化を HTTP、ファイル、電子メール、および FTP 転送プロバイダで実装しています。JMS プロバイダでは、送信操作と受信操作のトランザクション セマンティクスを分離する必要があるため、この最適化は使用されません。 |
カスタム転送プロバイダでこの最適化を使用する場合は、CoLocatedTransportMessageContext クラスを拡張して、TransportProvider.sendMessageAsync() が呼び出されたときに send() メソッドを呼び出す必要があります。
AquaLogic Service Bus ランタイムが発信エンドポイントにメッセージを送信し、応答メッセージが返される場合、転送プロバイダは、この応答を非同期で返す必要があります。TransportSendListener.onReceiveResponse() メソッドまたは TransportSendListener.onError() メソッドは、TransportProvider.sendMessageAsync() が呼び出されたスレッドとは異なるスレッドから呼び出される必要があるということです。
転送プロバイダで、非同期応答オプションの使用時に、JMS 要求や HTTP 要求への応答など、応答を非同期で取得する組み込みのメカニズムがある場合、これは自然に行われます。ただし、転送プロバイダで、応答を非同期で取得する組み込みのメカニズムがない場合は、ブロック方式で発信要求を実行し、TransportManagerHelper.schedule() メソッドを使用して、新しいワーカ スレッドをスケジュールできます。この場合、応答は TransportSendListener にポストされます。
AquaLogic Service Bus で、要求ペイロードを発信メッセージに設定するか、または応答ペイロードを着信メッセージに設定する必要がある場合、Source インタフェースから派生したオブジェクトを介して設定を行うように転送プロバイダに依頼します。転送プロバイダでは、基になる転送レイヤで必要な表現を決定し、Transformer.transform() メソッドを使用して、Source オブジェクトを目的のソースに変換する必要があります。
| ヒント : | メッセージのトランスフォーメーションの詳細については、「メッセージ コンテンツの設計」を参照してください。組み込みのトランスフォーメーションのリストについては、「組み込みのトランスフォーメーション」および「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 つのオプションがあります。
multipart/related を持つ、転送プロバイダに事前定義されたヘッダである。添付ファイルのサポートでは、HTTP 転送と電子メール転送はいずれも、この 3 つ目のオプションに基づいています。
TransportOptions オブジェクトは、メッセージを送受信する際のオプションを指定するために使用されます。TransportOptions オブジェクトは、着信メッセージの場合、転送プロバイダから転送マネージャに渡されます。発信メッセージの場合は、TransportOptions オブジェクトは、AquaLogic Service Bus ランタイムから転送マネージャに渡され、最後に転送プロバイダに渡されます。
転送プロバイダは、TransportManager.receiveMessage() に以下のパラメータを提供します。
TransportManager.receiveMessage() の呼ばれた側に対して、例外が送出されます。例外送出のオプションには、着信メッセージに対して例外を返したり、エラーから応答メッセージを生成して、その応答メッセージで着信メッセージに通知するものがあります。通常、QOS が exactly-once (トランザクション対応のメッセージ) の場合は、THROW_ON_ERROR を true に設定します。
たとえば、JMS/XA ではこのフラグを true に設定し、同じ要求スレッドで例外を送出するため、例外をロールバックするようにマークできます。HTTP では再試行のメカニズムがないため、このフラグを false に設定します。エラーがステータス コードに変換され、応答メッセージが返されます。
発信処理の場合、AquaLogic Service Bus ランタイムは、転送マネージャに以下のパラメータを指定します。転送パラメータは、これらのパラメータのいくつかを内部的に使用し、TransportProvider.sendMessageAsync() に伝播します。
要求モードは、REQUEST_ONLY (「一方向」とも呼ばれる) および REQUEST_RESPONSE の 2 つの値を持つ列挙値として定義されます。これらのモードは、要求および応答について次のように解釈されます。
実行時例外がトランザクション対応モデルに与える影響については、以下の 3 つの異なるケースがあります。
図 3-2 に示すように、ビジネス サービスの発信呼び出しの前に、例外が要求パイプラインで発生します。たとえば、要求メッセージのコンテンツに対して特定の XQuery を実行すると、例外が生成されます。
要求パイプラインにユーザ コンフィグレーション エラー ハンドラをコンフィグレーションしている場合、ユーザ コンフィグレーションに従ってエラーが処理されます。それ以外の場合は、引数として receiveMessage() 呼び出しに渡される転送オプションに従って、プロキシ サービスが TransportManager.receiveMessage() の呼び出し時に例外を捕捉するか、応答メタデータを介してエラーの InboundTransportMessageContext.close() メソッドで通知されます。プロキシ サービスが、例外を送出する必要があることを示している場合は、try/catch 句で receiveMessage() を囲み、トランザクションをロールバックするようにマークします。
図 3-3 に示すように、ビジネス サービスの呼び出し中に、例外が発生します。発信転送プロバイダでは、次の処理のいずれかが行われます。
TransportProvider.sendMessageAsync() から例外を送出する。たとえば、外部サービスへのソケット接続を確立している最中にエラーが発生した場合、発信プロバイダは例外を送出します。このような状況は、誤った URL や接続障害などのために、ビジネス サービスを呼び出すことができない場合に発生します。この場合、転送プロバイダが例外を生成する必要があります。 TransportSendListener.onError() を介して、リスナに通知する。たとえば、ビジネス サービスを呼び出したときに、呼び出しがエラーになった場合 (SOAP 障害など)、転送プロバイダは、例外を生成する代わりに TransportSendListener.onError() を呼び出す必要があります。
最初の例では、ケース 1 で説明したものと同じ例外処理が行われます。2 つ目の例では、応答パイプラインにエラー ハンドラをコンフィグレーションしている場合、ユーザ コンフィグレーションに従ってエラーが処理されます。それ以外の場合は、InboundTransportMessageContext.close() の応答メタデータを介して、例外がプロキシ サービス エンドポイントに逆に伝播されます。
図 3-4 に示すように、ビジネス サービスを呼び出した後、応答パイプラインで例外が発生します。応答パイプラインにユーザ定義のエラー ハンドラがない場合、適切な応答メタデータを持つ InboundTransportMessageContext.close() メソッドを使用して、エラーがプロキシ サービス エンドポイントに通知されます。着信転送エンドポイントが同期トランザクション エンドポイントの場合、要求を受信したときにアクティブであったトランザクションがまだなおアクティブで、ロールバックできることが保証されます。着信エンドポイントがトランザクション対応でも同期型でもない場合、ロールバックする着信トランザクション コンテキストがないため、他のアクションを実行する必要があります。
UDDI (Universal Description, Discovery, and Integration) は、インターネット上の Web サービスを記述および検索するための標準メカニズムです。カスタム転送プロバイダに基づいて、プロキシ サービスを UDDI レジストリにパブリッシュできます。これにより、ビジネス サービスをホストするサービスとして、プロキシ サービスを異なるドメインの AquaLogic Service Bus サーバにインポートできます。
プロキシ サービスをパブリッシュするには、転送プロバイダは、TransportProviderConfiguration XML スキーマ定義の「UDDI」セクションで、転送のタイプを表す tModel を定義する必要があります (スキーマで生成されるインタフェースの詳細については、「スキーマで生成されるインタフェース」を参照してください)。
この tModel には、CategoryBag および keyedReference が含まれている必要があります。また、keyedReference では、tModelKey が UDDI タイプのカテゴリ システムに設定され、keyValue が「transport」になっている必要があります。この tModel では、UDDI V3 tModel キーのみ指定する必要があります。
UDDI がこの転送のタイプに tModel を定義している場合は、定義をコピーして、UDDI セクションに貼り付けることをお勧めします。
コード リスト 3-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 を定義していない場合、AquaLogic Service Bus は、コンフィグレーションされたレジストリに、ここで定義する tModel をパブリッシュできます。AquaLogic Service Bus に UDDI レジストリをコンフィグレーションしている場合、[tModel をレジストリにロード] オプションを指定できます。このオプションにより、カスタム転送プロバイダの tModel を含め、AquaLogic 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 を実装するのは、プロバイダが、AquaLogic Service Bus ドメインの WebLogic Server アーティファクトを変更する必要がある場合だけです。TransportWLSArtifactDeployer のメソッドは、管理サーバでのみ呼び出すことができます。この場合、渡された DomainMBean 引数を使用して変更が行われ、クラスタ全体に変更が伝播されます。
TransportProvider メソッドは、ドメインのすべてのサーバ (管理サーバおよび管理対象サーバ) で呼び出されます。管理対象サーバで AquaLogic Service Bus ドメインのアーティファクトは変更できないため、TransportProvider のメソッドを呼び出すのは、内部データ構造を更新する場合だけです。
特定の転送プロバイダが TransportWLSArtifactDeployer インタフェースを実装する場合、TransportProvider の対応するメソッドが呼び出される前に、TransportWLSArtifactDeployer のメソッドが呼び出されます。たとえば、TransportProvider.createEndPoint() が呼び出される前に、TransportWLSArtifactDeployer.onCreate() が呼び出されます。
TransportWLSArtifactDeployer の詳細については、「汎用インタフェースの概要」を参照してください。
  
|
