|
|
開発作業を綿密に計画すると、カスタム転送プロバイダの開発に要する時間と労力を大幅に削減できます。以下の節では、最初に知っておくと役立つ、転送プロバイダの概念と機能について詳しく説明します。
転送プロバイダは、転送 SDK のインタフェースを実装し、AquaLogic Service Bus とメッセージを送受信するメカニズムとの橋渡しをします。このようなメカニズムには、HTTP などの特定の転送プロトコルだけでなく、ファイルや電子メール メッセージなど、他のエンティティが含まれる場合もあります。転送プロバイダは、転送エンドポイントのライフ サイクルおよび実行時の動作を管理します。エンドポイントは、メッセージの送信元または送信先となるリソースです。
図 2-1 は、AquaLogic Service Bus を介した基本的なメッセージの流れを示したものです。クライアントは、特定の転送プロトコルを使用して AquaLogic Service Bus にメッセージを送信します。転送プロバイダは、着信メッセージを処理します。サービス クライアント エンドポイントとの通信を処理し、AquaLogic Service Bus へのメッセージのエントリ ポイントとして機能します。
図 2-1 にはバインディング レイヤも示されています。これは、メッセージのパックおよびアンパック、メッセージのセキュリティ処理を行い、AquaLogic Service Bus パイプラインにメッセージを渡します。
| ヒント : | AquaLogic Service Bus のメッセージ ブローカリングおよび転送レイヤの役割の詳細については、AquaLogic Service Bus の概念とアーキテクチャを参照してください。AquaLogic Service Bus を介したメッセージ フローについてのより詳細なシーケンス ダイアグラムについては、「UML シーケンス ダイアグラム」を参照してください。 |
デフォルトでは、AquaLogic Service Bus には、HTTP、JMS、ファイル、FTP など、一般的に使用されている複数の転送プロトコルをサポートする転送プロバイダが用意されています。これらのネイティブなプロバイダを使用して、前述の一般的な転送プロトコルを必要とするプロキシ サービスおよびビジネス サービスをコンフィグレーションできます。表 2-1 に、これらの組み込みプロバイダを示します。
| ヒント : | これらのネイティブな転送プロバイダの使用およびコンフィグレーションの詳細については、AquaLogic Service Bus ユーザーズ ガイドを参照してください。 |
この節では、転送 SDK の用途および機能について簡単に説明します。この節の内容は以下のとおりです。
AquaLogic Service Bus では、メッセージがシステムに出入りする方法とは無関係にメッセージを処理します。転送 SDK は、AquaLogic Service Bus と、AquaLogic Service Bus に出入りするデータのフローを処理するコンポーネントとの間の抽象レイヤを提供します。この抽象レイヤにより、独自の転送プロトコルを処理するための新しい転送プロバイダを開発できます。AquaLogic Service Bus と共にインストールされる転送プロバイダのリストについては、「表 2-1 AquaLogic Service Bus と共にインストールされる転送プロバイダ」を参照してください。
SDK は、AquaLogic Service Bus の他の部分から以下を抽象化します。
転送 SDK を使用して開発された転送プロバイダは、以下のように着信メッセージおよび発信メッセージを処理します。
転送 SDK は、発信メッセージおよび着信メッセージを個別に処理します。着信メッセージを 1 つの転送プロトコルにバインドし、発信エンドポイントで異なる転送プロトコルにバインドすることもできます。
AquaLogic Service Bus のメッセージ フローの詳細については、AquaLogic Service Bus ユーザーズ ガイドを参照してください。
一部の転送では、アーティファクトを WLS サーバにデプロイする必要があります。たとえば、JMS プロキシは、メッセージ駆動型 Bean として実装されます。このアーティファクト、EAR ファイルは、新しい JMS プロキシを登録する際にデプロイする必要があります。同様に、EJB 転送プロバイダでは EAR ファイルを使用しますが、これは新しい EJB ビジネス サービスを登録する際にデプロイする必要があります。サービス登録の一環としてキューおよびトピックを作成することがある JMS 転送などのように、その他のタイプのアーティファクトのデプロイが必要になる場合があります。SDK により、これらのアーティファクトをサポートし、WLS のデプロイメント サイクルに参加できます。これらのアーティファクト ファイルのいずれかのデプロイメントが失敗した場合、AquaLogic Service Bus のセッションに通知され、デプロイメントはキャンセルされます。SDK のこの機能により、サービスを最小単位で作成できます。失敗が発生した場合、セッションは以前の状態に戻ります。
| 注意 : | WLS のデプロイメント サイクルに参加するには、転送プロバイダが TransportWLSArtifactDeployer インタフェースを実装している必要があります。この方法の第一の利点は、最小単位で WebLogic Server をデプロイできる点であり、必要に応じてロールバックすることもできます。このインタフェースの詳細については、「汎用インタフェースの概要」および「TransportWLSArtifactDeployer の実装が適している場合」を参照してください。 |
メッセージを処理する際、サーバで動作するスレッド数には限りがあるため、非同期的に行うことが重要です。この機能により、多数のメッセージを処理できるように AquaLogic Service Bus を拡張できます。要求が処理されると、スレッドは解放されます。ビジネス サービスが応答を受信すると (または、一方向の場合は要求を処理し終えると)、コールバックによって AquaLogic Service Bus に非同期的に通知します。
「同期トランザクションのサポート」および「スレッディング モデル」も参照してください。
転送 SDK を使用して、着信プロパティのモードおよび発信プロパティのモードを実装できます。これらの接続モードおよびエンドポイント モードは、転送プロバイダの XML スキーマ定義ファイルで指定します。このファイルの詳細については、「3. 転送固有のアーティファクトの XML スキーマ ファイルの作成」を参照してください。このスキーマは、AquaLogic Service Bus パイプラインでフィルタ処理およびルーティングを行う際に使用できます。
この節では、転送マネージャによって提供される関連機能について示します。転送マネージャは、さまざまな転送プロバイダの管理、エンドポイントの登録、制御、着信メッセージと発信メッセージの処理、およびその他の機能を一元化するための主要ポイントとなります。これらの機能は、転送プロバイダによる特定のサポートを必要としません。
転送 SDK は、発信メッセージのロード バランシングおよびフェイルオーバをサポートします。サポートされているロード バランシングのオプションは以下のとおりです。
この節では、カスタム転送プロバイダの記述が必要となる基本的な使用例について説明します。別の方法を選択した方が適切な場合もあります。この節の内容は以下のとおりです。
転送 SDK の主要な使用例の 1 つは、既に内部アプリケーション間の通信に使用している特別な転送をサポートすることです。このような転送では、セットアップされたハンドシェーク、ヘッダ フィールド、メタデータ、または転送レベルのセキュリティに独自の概念が用いられている場合があります。転送 SDK を使用して、個々のエンドポイントや、着信および発信のいずれか、または両方のコンフィグレーションを可能にする、AquaLogic Service Bus の転送の実装を作成できます。カスタム転送を実装することで、特別な転送のメタデータおよびヘッダ フィールドをプロキシ サービス パイプラインで使用できるコンテキスト変数にマッピングできます。
信頼性、セキュリティ、パフォーマンス、管理、ユーザ インタフェースおよび UDDI レジストリの使用のために、転送プロバイダを AquaLogic Service Bus のあらゆる側面にシームレスに統合する必要がある場合は、転送 SDK を使用してください。
転送 SDK を使用してカスタム転送を開発した方が良い場合の例を以下に示します。
また、転送 SDK を使用して、AquaLogic Service Bus で提供される既存の転送の 1 つで特別なプロトコルをサポートできます。この例には、以下のサポートが含まれます。
転送 SDK を使用して新しい AquaLogic Service Bus 転送プロバイダを作成する場合、多大な労力が必要となることがあります。転送 SDK は、カスタム転送が、AquaLogic Service Bus にネイティブに付属する転送の利便性と機能をすべて活用できるようにするために、多彩な機能をすべて備えた環境を提供します。ただし、このような多彩な機能を持ったカスタム転送は複雑になります。場合によっては、より簡単な別の方法を検討することをお勧めします。
既存のプロトコルを介して送受信される、異なるフォーマットのメッセージをサポートするためだけに拡張機能が必要な場合は、既存の転送および Java コールアウトを使用してメッセージを変換できる場合があります。たとえば、標準の JMS プロトコルを介して送信される (ASN.1 またはシリアライズされた Java オブジェクトなどの) 特別なバイナリ フォーマットを使用しているとします。この場合、サービスのタイプがバイナリの入出力メッセージを使用するメッセージング サービスである、標準の JMS 転送を使用したサービスを定義することも検討できます。次に、パイプラインでメッセージ コンテンツが必要な場合は、Java コールアウト アクションを使用してメッセージを XML に変換したり XML から変換したりできます。Java コールアウトの使用については、AquaLogic Service Bus ユーザーズ ガイドの「Java コールアウトおよび POJO を使用した拡張性」を参照してください。
転送 SDK を使用してカスタム転送を開発することが最適とは言えないその他の例を以下に示します。
この節では、転送プロバイダの実行時および設計時のコンポーネントについて説明した UML ダイアグラムを示します。この節の内容は以下のとおりです。
通常、カスタム転送プロバイダは設計時部分と実行時部分から構成されています。設計時部分では、転送プロバイダへのエンドポイントの登録を行います。このコンフィグレーション動作は、UI インタフェースの実装によって実行されます。実行時部分では、メッセージの送受信のメカニズムを実装します。
新しいカスタム転送プロバイダを開発する場合は、SDK によって提供される多数のインタフェースを実装する必要があります。この節では、SDK の設計時部分および実行時部分の構成をモデル化した UML ダイアグラムを示します。
| ヒント : | AquaLogic Service Bus では、TransportProvider インタフェースの実装は、転送プロトコル固有のコンフィグレーション プロパティおよび実行時プロパティの集中的な管理ポイントとなります。サポートされているプロトコルごとに、TransportProvider オブジェクトの単一のインスタンスが存在します。たとえば、HTTP 転送プロバイダ、JMS 転送プロバイダ、およびその他の転送プロバイダに、それぞれ単一のインスタンスが存在します。 |
詳細については、「転送プロバイダの開発」で、必要なインタフェースのリストを参照してください。転送 SDK によって提供されるインタフェースおよびクラスの概要については、「転送 SDK のインタフェースおよびクラス」を参照してください。詳細な説明については、AquaLogic Service Bus クラスの Javadoc を参照してください。
カスタム転送プロバイダの設計時部分はユーザ インタフェースのコンフィグレーションから構成されています。このコンフィグレーションは、新しいビジネス サービスまたはプロキシ サービスが登録される際に、AquaLogic Service Bus Console によって呼び出されます。図 2-2 に、転送プロバイダの設計時部分の構造を説明した UML ダイアグラムを示します。ダイアグラムでは以下のインタフェースについて説明しています。
| 注意 : | 各転送エンドポイントのコンフィグレーションは、任意の転送プロバイダのすべてのエンドポイントに対して汎用なプロパティ (URI など) と、そのプロバイダのエンドポイントだけに固有のプロパティとで構成されます。図 2-3 は、共有のエンドポイント コンフィグレーション プロパティと転送プロバイダ固有のコンフィグレーション プロパティの関係を示しています。詳細については「転送エンドポイントのプロパティの概要」を参照してください。 |
実行時フレームワークでは、転送プロバイダは、転送マネージャを呼び出して着信メッセージを受信したことを認識します。転送メッセージ コンテキストには着信メッセージのヘッダおよび本文が含まれています。発信メッセージの場合、TransportSendListener および TransportSender があります。転送プロバイダは、メッセージからヘッダおよび本文を取得します。
図 2-4 に、転送プロバイダの実行時部分の構造を説明した UML ダイアグラムを示します。
転送 SDK を使用して新しい転送プロバイダを開発する前に、メッセージ エンドポイントのトランザクション モデルを検討することが重要です。この節では、AquaLogic Service Bus で使用されるトランザクション モデル、およびそのモデルが転送 SDK にどのように関係するかを説明します。
転送エンドポイントは、JMS プロキシ サービスなどの AquaLogic Service Bus リソースであり、メッセージの送信元または送信先となります。AquaLogic Service Bus では、転送エンドポイントはプロトコル固有の転送プロバイダによって管理されます。転送プロバイダは、転送エンドポイントのライフ サイクルおよび実行時動作を管理するプラグイン オブジェクトです。
AquaLogic Service Bus のトランザクション モデルを理解するには、サービス転送エンドポイントのプロパティを確認しておくと役に立ちます。
エンドポイントはトランザクション対応の場合と非対応の場合があります。トランザクション対応のエンドポイントは、メッセージを処理する際に、グローバル トランザクションのコンテキスト内で開始または追加できます。以下の例では、トランザクションのプロパティがエンドポイントによってどのように異なるかを示します。
特定のプロキシ サービスの詳細については、AquaLogic Service Bus ユーザーズ ガイドを参照してください。
任意のエンドポイントで、以下のメッセージ パターンのいずれかを使用できます。
EJB 転送および Tuxedo 転送は、同期トランザクションをサポートします。以前は、AquaLogic Service Bus では、JMS 転送のみがトランザクションをサポートしており、トランザクションは、AquaLogic Service Bus ドメインから開始され、AquaLogic Service Bus ドメインによってバインドされていました。EJB 転送および Tuxedo 転送を使用することで、トランザクションを AquaLogic Service Bus の外部から開始したり、外部ドメインにパス スルーしたりすることができます。同期トランザクション対応の転送がサポートする使用例は以下のとおりです。
応答パイプラインの処理は、着信転送が同期トランザクションをサポートする場合に、受信トランザクションに含まれます。この例は、着信転送が他の発信転送とペアである場合にサポートされます。例外については、以下の注意を参照してください。
| 注意 : | 着信転送が同期トランザクションで発信転送が非同期トランザクションの場合、デッドロック状況が発生します。デッドロックが発生する原因は、トランザクションがコミットされるまで発信要求が使用できないにもかかわらず、トランザクションが外部で開始され、AquaLogic Service Bus が応答を受け取り制御が戻るまでコミットされないためです。転送マネージャはこの状況を認識し、実行時エラーを送出してデッドロックを回避します。 |
| 注意 : | たとえば、Tuxedo プロキシ サービスなどの同期トランザクションの着信エンドポイントを使用していて、JMS プロキシ サービスなどのように発信エンドポイントが非同期トランザクションである場合、応答を受信するまで発信要求はトランザクションをコミットしません。応答は、外部エンティティが要求を受け取り、処理するまで受信できません。 |
また、この場合、応答パイプラインで実行される AquaLogic Service Bus パブリッシュ アクションは、トランザクションの一部として行われます。これは要求パイプラインで実行されるパブリッシュ アクションがトランザクションの一部として行われるのと同様です。
| 注意 : | 複数のアクションが (要求パイプラインまたは応答パイプラインの) トランザクションに参加できます。これには、パブリッシュ アクション、サービス コールアウト アクション、およびレポート アクションが含まれます。 |
たとえば、着信 Tuxedo 転送が同期トランザクションの場合、要求パイプラインおよび応答パイプラインが完了した場合のみコミットできます。この場合、転送マネージャは、トランザクション コンテキストを着信スレッドから発信スレッドに転送します。応答スレッドが終了すると、トランザクション コントロールおよび結果が呼び出しクライアントに返されます。
AquaLogic Service Bus サービス コールアウトを使用すると、あるプロキシ サービスから別のサービスへのコールアウトを行うことができます。同期トランザクション対応の転送に対しサービス コールアウト アクションが実行された場合、「ベスト エフォート」のサービス品質に加えて、「必ず 1 回」のサービス品質がサポートされます。「必ず 1 回」では、発信メッセージの送信が開始されるまでは終了エラーが発生しないことを前提として、メッセージが着信から発信に 1 回だけ配信されます。「ベスト エフォート」では、それぞれの送信で独自のトランザクション コンテキストが定義されます (トランザクション対応の転送方式の場合)。「ベスト エフォート」が指定されている場合、メッセージングの機能に信頼性はなく、重複するメッセージは除去されませんが、パフォーマンスが最適化されます。「TransportOptions の操作」も参照してください。
同期トランザクション対応の転送へのコールアウトは必要に応じて既存のトランザクションの一部になります。たとえば、グローバル トランザクション中に要求パイプラインを実行しいても、サービス コールアウトはトランザクションへの参加を許可されます。たとえば、EJB サービスへのコールアウトがある場合、サービスは、必要に応じてそのトランザクションに参加できます。
サービス コールアウトの詳細については、『AquaLogic Service Bus Console の使い方』の「サービス コールアウト」を参照してください。メッセージの信頼性の詳細については、AquaLogic Service Bus ユーザーズ ガイドを参照してください。
以下の条件に当てはまる場合、転送プロバイダを呼び出して発信要求を送信する前に、転送フレームワークがトランザクションを中断します。
「送信」操作が完了すると、中断されていたトランザクションが再開されます。
任意の発信サービス エンドポイントに、関連付けられている URI が複数あり、トランザクション対応である場合、フェイルオーバが発生する場合は、トランザクションの間にのみ発生し、ロールバックのマークは付けられていません。たとえば、URI が呼び出され、サービスがエラーを返した場合、フェイルオーバは正常にトリガされます。この場合、転送フレームワークが、トランザクションにロールバックのマークが付けられていることを検出するため、フレームワークは、別の URI に対しフェイルオーバを実行しません。
転送 SDK により、ユーザおよびサードパーティは、AquaLogic Service Bus に新しい転送をプラグインできます。AquaLogic Service Bus のセキュリティ モデル内では、転送プロバイダは信頼できるコードと見なされます。セキュリティ ホールによる潜在的なセキュリティ上の脅威を避けるため、転送プロバイダの実装は慎重に設計することが重要です。このドキュメントには、安全な転送プロバイダを開発する方法についての具体的なガイドラインは含まれていませんが、この節では、以下の転送 SDK のセキュリティ目標について説明します。
転送プロバイダは、着信認証のメカニズムがその転送に適しているものはすべて自由に実装できます。たとえば、HTTP 転送は以下の認証方式をサポートします。
HTTPS 転送プロバイダは、上記の認証方法の他に、SSL クライアント認証をサポートします。HTTP 転送プロバイダおよび HTTPS 転送プロバイダのどちらも、匿名のクライアント要求をサポートします。
転送プロバイダは、適用可能な任意の転送レベル認証スキーマを実装します (存在する場合)。転送プロバイダがクライアントを認証する場合、weblogic.security.Security.runAs(subject) のスコープ内で TransportManager.receiveMessage() を呼び出し、AquaLogic Service Bus がクライアントの Subject オブジェクトを使用できるようにする必要があります。このメソッドについては、http://edocs.bea.com/wls/docs92/javadocs/weblogic/security/Security.html を参照してください。
| ヒント : | Java の Subject クラスについては、http://java.sun.com/j2se/1.5.0/docs/api/javax/security/auth/Subject.html を参照してください。 |
プロキシは、以下のように、この Subject を使用します。
転送プロバイダが認証をサポートしない、または匿名の要求をサポートする場合、要求をディスパッチする前に匿名サブジェクトがスレッド上にあることを確認する必要があります。通常、転送プロバイダは、匿名としてすでに実行しています。そうでない場合、プロバイダは以下を呼び出す必要があります。
Subject anonymous = SubjectUtils.getAnonymousUser()Security.runAs(anonymous, action)
SubjectUtils については、http://edocs.bea.com/wls/docs92/javadocs/weblogic/security/SubjectUtils.html を参照してください。
転送プロバイダは、着信クライアント認証のコンフィグレーションに必要な、任意の AquaLogic Service Bus Console コンフィグレーション ページの提供も行います。
転送プロバイダは、着信認証モデルを明確に記録しておく必要があります。
転送プロバイダは、発信認証のスキーマがその転送に適しているものはすべて自由に実装できます。転送 SDK には、ユーザ名およびパスワードによる発信認証、(双方向) SSL クライアント認証、および JAAS Subject 認証を容易に実現するための API が含まれています。
AquaLogic Service Bus のサービス アカウントを使用して、ユーザ名およびパスワードによる発信認証を実装できます。サービス アカウントは、最上位の AquaLogic Service Bus リソースです。サービス アカウントは、AquaLogic Service Bus Console で作成および管理されます。転送プロバイダでは、それぞれの転送固有のコンフィグレーションを自由に設計し、サービス アカウントへの参照を含めることができます。このようにして、転送プロバイダは、AquaLogic Service Bus のサービス アカウントによって提供される資格管理メカニズムを利用することができます。
転送プロバイダでは、サービス アカウントのコンフィグレーションの詳細について懸念する必要はありません。サービス アカウントのタイプは、以下の 3 つです。
発信エンドポイントは、サービス アカウントへの参照を持つことができます。サービス アカウントへの参照は、転送固有のエンドポイントのコンフィグレーションに格納する必要があります。プロキシ サービスが、メッセージをこの発信エンドポイントにルーティングする場合、転送プロバイダは、サービス アカウントへの参照を CredentialCallback.getUsernamePasswordCredential(ref) に渡します。AquaLogic Service Bus は、サービス アカウントのコンフィグレーションに応じて、ユーザ名およびパスワードを返します。この方法には、ID の伝播と資格マッピングのコンフィグレーションを転送固有の詳細な作業から分離することで、転送 SDK を簡素化できるという利点があります。また、このコンフィグレーションの共有も可能になります。複数のエンドポイントが同じサービス アカウントを参照できます。
| 注意 : | CredentialCallback オブジェクトは、TransportSender.getCredentialCallback() を呼び出すことにより転送プロバイダで使用できるようになります。 |
CredentialCallback.getUsernamePasswordCredential() は、weblogic.security.UsernameAndPassword インスタンスを返します。これは、ユーザ名およびパスワードを取得するためのメソッドを持つ簡単なクラスです。返されるユーザ名およびパスワードは、サービス アカウントのタイプによって異なります。サービス アカウントのタイプが静的である場合、固定されたユーザ名およびパスワードが返されます。サービス アカウントのタイプがマップされている場合、クライアント サブジェクトを使用してリモートのユーザ名およびパスワードがルックアップされます。サービス アカウントがパススルーである場合、クライアントのユーザ名およびパスワードが返されます。
| 注意 : | 以下の場合、マップされたサービス アカウントは、CredentialNotFoundException を送出します。 |
| 注意 : | AquaLogic Service Bus 2.5 では、パススルー サービス アカウントは、以下の 2 つのシナリオでのみ機能します。 |
| 注意 : | それ以外の場合は、パススルー サービス アカウントは CredentialNotFoundException を送出します。 |
AquaLogic Service Bus は、発信 SSL クライアント認証もサポートします。この場合、発信 SSL 要求を出すプロキシを、SSL 用の PKI キーペアを使用してコンフィグレーションする必要があります (これには、プロキシ サービス プロバイダへの参照が含まれますが、このドキュメントでは、詳細については取り上げていません。詳細については、AquaLogic Service Bus ユーザーズ ガイドを参照してください)。SSL クライアント認証用のキーペアを取得するには、転送プロバイダが CredentialCallback.getKeyPair() を呼び出す必要があります。この例として、HTTPS 転送プロバイダがあります。
一部の転送プロバイダは、認証トークンとして、シリアライズされた JAAS Subject を回線で送信します。着信サブジェクトを取得するには、転送プロバイダが CredentialCallback.getSubject() を呼び出す必要があります。
| 注意 : | 戻り値は、匿名サブジェクトである場合があります。 |
一部の転送では、サービスに接続するために資格が必要になります。たとえば、FTP サーバへの認証には、FTP エンドポイントが必要になる場合があります。転送プロバイダは、静的なサービス アカウントを利用して、接続を確立するためのユーザ名およびパスワードを取得できます。これらの接続は、特定のクライアント要求の代わりとしての確立されるものではないため、この場合、マップされたサービス アカウントまたはパススルー サービス アカウントは使用できません。転送プロバイダでこのアプローチを採用する場合は、サービス アカウントへの参照を使用してエンドポイントをコンフィグレーションする必要があります。実行時に、転送プロバイダは、TransportManagerHelper.getUsernamePasswordCredential() を呼び出して、静的なサービス アカウントへの参照を渡す必要があります。
AquaLogic Service Bus は、すべての着信要求についてプロキシ サービスへのアクセス制御を実施します。転送プロバイダでは、アクセス制御を実施するための、またはアクセス制御ポリシーを管理するためのインタフェースを提供する必要はありません。
| 注意 : | アクセス制御ポリシーはほとんどの使用例を対象としていますが、転送プロバイダに固有の理由で、(AquaLogic Service Bus によって行われるアクセス制御チェックの他に) 独自のアクセス制御メカニズムが必要な場合は、それらを実装できます。この場合は、BEA 販売代理店にお問い合わせください。通常は、転送プロバイダで、AquaLogic Service Bus を使用してアクセス制御を処理する方法をお勧めします。 |
アクセスが拒否されると、TransportManager.receiveMessage() は、TransportException 内にラップされている AccessNotAllowedException を送出します。転送プロバイダは、TransportException の根本原因を確認します。根本原因が AccessNotAllowedException である場合、転送プロバイダは、特別なエラー処理を行う場合があります。たとえば、この場合、HTTP/S 転送プロバイダは HTTP 403 (forbidden) エラー コードを返します。
| 注意 : | AquaLogic Service Bus は、アクセス制御の判断を行うために、認証プロバイダが要求ヘッダを使用できるようにします。 |
「発信要求の認証」で説明したように、AquaLogic Service Bus には、3 つのタイプのサービス アカウントが用意されています。転送プロバイダは、サービス アカウントを利用して、発信認証のためのユーザ名およびパスワードにアクセスできます。サービス アカウントは、AquaLogic Service Bus の転送プロバイダに対し、すべての ID の伝播および資格マッピングの詳細を非表示にしています。
この節では、AquaLogic Service Bus で使用されるスレッディング モデル、およびそのモデルが転送 SDK にどのように関係するかを説明します。この節の内容は以下のとおりです。
図 2-5 に、1 つの着信メッセージを処理する仮想の転送エンドポイントを表す、AquaLogic Service Bus のスレッディング モデルを示します。
Servlet などのフロント エンド アーティファクトが、着信メッセージを取得します。要求を、発信エンドポイントにルーティングし、非同期的に送信できます。この時点で、スレッドは解放されます。その後しばらくして、コールバックを使用して、応答が AquaLogic Service Bus に送り返されます。応答が受信され、パッケージ化されて、AquaLogic Service Bus パイプラインに渡されます。その後、パイプラインが、応答をクライアントに送信する準備ができていることを着信エンドポイントに通知します。スレッドが使用できないのは必要な間のみであるため、この処理はスケーラブルです。
| 注意 : | この時点で、最初の要求スレッドは解放され、別の要求が使用できるように WebLogic Server のスレッド プールに戻されます。 |
転送プロバイダが、非同期の (非ブロッキング) 発信呼び出しをネイティブに実装していない場合は、着信要求メッセージを受信したスレッドとは別のスレッドで、AquaLogic Service Bus ランタイムに応答を返す必要があります。これを行うために転送プロバイダは、要求スレッドでブロッキング呼び出しを実行し、転送 SDK のヘルパー メソッドを使用して、AquaLogic Service Bus ランタイムに応答を返します。
たとえば、EJB 転送プロバイダは、非同期 (非ブロッキング) の発信呼び出しを実装していません。基礎となる API はブロッキング API です。これに対処するには、プロバイダがブロッキング呼び出しを行い、その後で、TransportManagerHelper.schedule() を使用して処理に対する応答をスケジュールします。EJB 転送プロバイダの詳細については、AquaLogic Service Bus ユーザーズ ガイドの「EJB 転送」を参照してください。
転送サブシステムは、意図的に、AquaLogic Service Bus と非同期的に対話するようになっています。これは、非同期での動作が、同期での動作よりもスケーラブルであるため望ましいからです。非同期の対話用に 1 つ、および同期の対話用に 1 つと、2 つの別々の API を作成するのではなく、AquaLogic Service Bus ランタイムでは非同期の対話が必要です。この処理は、ブロッキング呼び出しやコールバックでの応答をポストするなどの方法により、転送開発者が行う必要があります。いずれにせよ、応答は、要求とは別のスレッドで実行する必要があります。非同期の発信呼び出しをサポートする AquaLogic Service Bus の転送プロバイダのリストについては、表 2-2 を参照してください。
図 2-5 に示すスレッド ダイアグラムは、ルーティングに焦点を当てたものです。転送サブシステムは、要求または応答パイプラインの処理中に実行される AquaLogic Service Bus のパブリッシュ アクションとサービス コールアウト アクションに対して同じように動作します。これらのアクションは、転送サブシステムの範囲外および AquaLogic Service Bus パイプラインの範囲内で実行されます。そのため、パブリッシュおよびサービス コールアウトのスレッディング動作と転送プロバイダのスレッディング動作には違いがいくつかあります。
| ヒント : | サービス コールアウト アクションにより、ユーザは、AquaLogic Service Bus にすでに登録されているプロキシまたはビジネス サービスに対し、同期 (ブロッキング) 呼び出しをコンフィグレーションすることができます。メッセージの対象サービスを特定し、そのサービスへメッセージをパッケージ化し、送信する方法をコンフィグレーションするには、パブリッシュ アクションを使用してください。サービス コールアウト アクションおよびパブリッシュ アクションの詳細については、AquaLogic Service Bus Console のオンライン ヘルプおよび AquaLogic Service Bus ユーザーズ ガイドを参照してください。 |
転送プロバイダには、メッセージ コンテンツの独自のネイティブ表現があります。たとえば、HTTP 転送は java.io.InputStream を使用し、JMS は、さまざまなタイプの Message オブジェクトがあります。また、Tuxedo にはバッファがあり、WLS Web サービスのスタックは SAAJ を使用します。ただし、プロキシ サービスの実行時は、コンテンツのネイティブ表現は、メッセージ コンテキストです。AquaLogic Service Bus は、InputStream からメッセージ コンテキストへの、またはその逆などの一部の一般的な変換シナリオをサポートしますが、転送での表現とメッセージ コンテキストの間の変換は、最終的には転送プロバイダが行います。
通常、転送 SDK が、転送の 2 つの異なるコンテンツ表現を直接変換することはありません。ただし、2 つの転送が互換性のある表現を使用していて、コンテンツを再エンコードする必要がない場合は、SDK によって、(たとえば、着信ファイル転送から発信 HTTP 転送に FileInputStream を渡すことにより) ソース コンテンツを直接パススルーできます。ただし、ソース コンテンツで何らかの処理が必要な場合は、最初にソース コンテンツをメッセージ コンテキストに復号化し、その後で標準のメカニズムを使用して送信転送用のコンテンツを生成した方が適切です。
コンテンツは、Source インタフェースのインスタンスとして表されます。TransportSender や TransportMessageContext などのメッセージ コンテンツを処理する転送 SDK インタフェースは、すべてメッセージ ペイロードを渡す際に、Source インタフェースを使用します。Source における要件はごくわずかです。Source は、基本となる Source インタフェースで定義されている 2 つのメソッドを使用した、バイト単位のストリームへのプルベースおよびプッシュベースの変換をサポートする必要があります。Source は、シリアライゼーション中に、TransformOptions パラメータで指定されている、文字セット エンコーディングなどのさまざまなトランスフォーメーションのオプションを考慮しない場合があります。
すべての Source オブジェクトは基本的なシリアライゼーション インタフェースを実装する必要がありますが、Source オブジェクトの基礎となる表現は実装固有のものです。そのため、InputStream、JMS Message オブジェクト、String、または特定の転送に最も適している表現に基づいた Source オブジェクトを使用できます。通常、Source を実装することで、基本的なシリアライゼーション メソッドだけでなく、基になるコンテンツに直接アクセスできるようになります。たとえば、内部で String オブジェクトを使用してそのコンテンツを格納する StringSource は、内部データにアクセスするための getString() メソッドを提供します。その後、Source の最終的なコンシューマは、これらのソース固有の API を呼び出して、基礎となるコンテンツを抽出し、シリアライゼーションのオーバーヘッドを回避することができます。
また、Transformer オブジェクトを使用して、Source を他のタイプの Source に変換することもできます。転送プロバイダなどの Source コンシューマが、認識できない Source インスタンスを受け取った場合は、多くの場合、認識できる Source インスタンスに変換できます。その後、ソース固有の API を使用して、認識できる Source から基になるコンテンツを抽出できます。ただし、転送プロバイダは多くの場合、単に基本的なシリアライゼーション メソッドを使用してコンテンツをシリアライズし送信します。「Source および Transformer クラスとインタフェース」も参照してください。
Source は、転送レイヤとバインディング レイヤの間の一般的なコンテンツ表現です。バインディング レイヤは、転送レイヤで使用される Source 表現と実行時にパイプラインで使用されるメッセージ コンテキストとの間でコンテンツを変換するエンティティです。変換がどのように行われるかは、サービスのタイプ (そのバインディングのタイプ) と添付の有無によって異なります。厳密には転送 SDK の役割ではありませんが、独自の Source オブジェクトを定義しているすべての転送プロバイダは、この変換プロセスを認識している必要があります。
添付が存在しない場合、受信した Source は単にコアとなるメッセージ コンテンツを示します。受信した Source を特定のタイプの Source に変換し、その後で基になるコンテンツを抽出することで MessageContext が初期化されます。たとえば、XML ベースのサービスの場合、受信した Source は XmlObjectSource に変換されます。その後、XmlObjectSource から XmlObject が抽出され、$body コンテキスト変数内でペイロードとして使用されます。同様に、SOAP サービスは XmlObjectSource に変換されます。ただし、<SOAP:Header> および <SOAP:Body> 要素を抽出して $header および $body コンテキスト変数を初期化できるようにするために、抽出された XmlObject が SOAP Envelope である必要がある点が異なります。
定義された一連のサービス タイプで使用される標準的な Source のタイプを以下に示します。
バイナリ サービスの場合、Source の変換は行われません。代わりに、Source は、SourceRepository に登録され、結果の <binary-content/> XML は、$body 内でペイロードとして使用されます。
添付が存在する場合、Source は最初に MessageContextSource に変換されます。MessageContextSource から、2 つのタイプの Source オブジェクトが取得されます。1 つが添付で、もう 1 つがコア メッセージです。コア メッセージの Source は、前述のとおり処理されます。添付を表す Source は、AttachmentsSource に変換されます。AttachmentsSource から、XML が取得され、$attachments コンテキスト変数、および任意のバイナリの添付コンテンツを表す登録済みの Source を含む SourceRepository の初期化に使用されます。図 2-6 に、このプロセス全体を示します。
転送レイヤに渡すために MessageContext 内のデータから Source を作成する場合にも、同様の変換が実行されます。コア メッセージは、サービスのタイプの標準的な Source に変換できる Source インスタンスで表現されています。ほとんどの場合、Source は、すでに標準的な Source のインスタンスになっていますが、必ずしもそうであるとは限りません。添付が存在する場合、転送レイヤに渡される Source は、MessageContextSource インスタンスに変換できる Source になります。転送プロバイダが、事前定義された転送ヘッダとして Content-Type をサポートする場合、一般的に、配信された Source は MessageContextSource のインスタンスになります。それ以外の場合、配信された Source は MimeSource のインスタンスであることが多いですが、これも MessageContextSource に変換できます。
この違いの理由は、転送ヘッダとして Content-Type をネイティブにサポートする転送では、ペイロードではなく、転送ヘッダにトップレベルの MIME ヘッダが含まれている必要があるためです。この例としては、HTTP および電子メールがあります。Content-Type をネイティブにサポートしない転送では、これらのトップレベルの MIME ヘッダがペイロードに含まれている必要があります。Content-Type ヘッダは、複数の MIME パッケージのデコードに不可欠であるためです。
以下の一覧は、組み込みのトランスフォーマによって提供される、サポートされているトランスフォーメーションのセットを示しています。左側にある Source 名の列は最初の Source のタイプを示し、上にある Source 名の行はターゲットの Source のタイプを示しています。行 R および列 C にある「X」は、最初の Source R からターゲットである Source C へ直接変換できることを示しています。たとえば、StringSource から XmlObjectSource への変換を処理する組み込みのトランスフォーマは存在しますが、StringSource から AttachmentsSource に変換できるトランスフォーマは存在しません。通常、これらのトランスフォーマは両方の Source のタイプで使用される内部データ表現の知識を利用します。
特に興味深いのは、一覧中の最初の「X」の行です。これは、サポートされている任意の Source から特定の Source へのトランスフォーメーションを示しています。たとえば、XmlObjectSource から ByteArraySource への変換を処理するトランスフォーマは特に存在しませんが、任意の Source のインスタンスから ByteArraySource への変換を処理するトランスフォーマは存在します。これらの一般的なトランスフォーメーションは、最初の Source のタイプの知識なしで実行されます。ただし、代わりに、すべての Source で実装されている、getInputStream() および writeTo() などの基本的なシリアライゼーション メソッドに基づいて実行されます。そのため、最終的には、XmlObjectSource から ByteArraySource へ変換することはできますが、これには、XmlObjectSource の内部情報の特定の知識は使用されません。
| 注意 : | 転送で実装されているカスタム Source の多くは、(基礎となるデータが構造化されていないバイトの収集である場合は特に) これらの一般的なトランスフォーメーションで処理できます。たとえば、ファイル転送は、ディスク上のファイルから直接コンテンツを取り出すカスタム Source を使用します。ただし、データは構造のない単なるバイトのセットであるため、XmlObjectSource などへのカスタム トランスフォーメーションを実行する必要はありません。Source から XmlObjectSource への一般的なトランスフォーメーションで、すべての Source が実装している基本的なシリアライゼーション メソッドのみを使用して、このカスタム FileSource を処理することができます。 |
詳細については、「Source および Transformer クラスとインタフェース」を参照してください。
  
|
