| Oracle® Fusion Middleware Oracle Service Busでのサービスの開発 12c (12.1.3) E53004-06 |
|
 前 |
 次 |
この章では、JMSトランスポートの概要と、Service Busサービスでの使用および構成方法について説明します。また、Service BusとWebLogic JMS間、およびService BusとWebSphere MQ間の相互運用性に関連する機能および概念についても説明します。
この章の内容は次のとおりです。
JMSトランスポートでは、JMSサービスのJMSキューとトピックからメッセージを送受信できます。JMSトランスポートを使用するようにビジネス・サービスを構成する場合はメッセージをエンキューして、JMSトランスポートを使用するようにプロキシ・サービスを構成する場合はメッセージを読み取ります(またはポーリングします)。JMSキューまたはトピックは、ローカルWebLogic Serverまたはリモート・サーバーに存在できます。
JMSは、エンタープライズ・メッセージング・システムにアクセスするための標準APIです。WebLogic JMSの概要と機能については、『Oracle WebLogic Server JMSリソースの管理』のJMSとWebLogic Serverの概要に関する項を参照してください。
Service Busでは、異種のエンドポイント間での相互運用性を確保するため、使用されるコンテンツ・タイプ、JMSタイプおよびエンコーディングをメッセージ・フローの構成時にそれぞれ制御できます。JMSタイプはバイトまたはテキスト(非Javaタイプ・メッセージの場合)のいずれかです。詳細は、「コンテンツ・タイプ、JMSタイプ、およびエンコーディング」を参照してください。
メッセージングは、一方向、同期型のリクエスト/レスポンスまたは非同期のリクエスト/レスポンスのいずれかです。ただし、JMSでのメッセージングは、一方向または非同期のリクエスト/レスポンスのみです。JMSを使用した非同期のリクエスト/レスポンス・メッセージングは、HTTPまたはHTTPSを使用したメッセージングにかわるものです。
非同期のリクエスト/レスポンス・メッセージングを使用する利点は次のとおりです。
レスポンスを待機する間、リクエスト・スレッドがブロックされることはありません。これにより、多数のブロッキング・リクエスト/レスポンス呼出しが行われた場合に生じる可能性のある、スレッドの管理上の問題が解消されます。ただし、HTTPとHTTP(S)は、操作の非ブロッキング・モードをサポートしています。
メッセージングは次が可能であるため、HTTPよりも信頼できます:
ディスク上に保持される
サービスを利用できないときに、キューに格納される
メッセージの処理時にサーバーにエラーや障害が発生した場合、メッセージを再配信できます。
トランザクション
IBM WebSphere MQの場合、特定のメインフレームとの対話には非同期のリクエスト/レスポンス・メッセージを使用することをお薦めします。非同期サービスは、使用するJMSリクエスト/レスポンス・パターンに応じて相関IDまたはメッセージIDを返す必要があります。Service Busで使用するどちらのID形式も、IBM WebSphere MQとの互換性およびMQネイティブ・インタフェースを使用するターゲット・サービスとの互換性があります。詳細は、「JMSリクエスト/レスポンスのメッセージIDと相関IDのパターン」を参照してください。
非同期のリクエスト/レスポンス・メッセージは、アウトバウンド・トランスポートとインバウンド・トランスポートによって処理されます。つまり、トランスポート方式固有のデータである$outboundと$inboundを除き、JMSリクエスト/レスポンスとHTTPリクエスト/レスポンスのメッセージ・フローに違いはありません。
Service Busは、同期と非同期のリクエスト/レスポンスのブリッジングをサポートしています。たとえば、HTTPを使用してプロキシ・サービスを呼び出すことができ、呼び出されたプロキシ・サービスは、JMSリクエスト/レスポンス・ビジネス・サービスにルーティングされます。これを同期から非同期へのサービスの切替えと呼びます。
JMSトランスポートを使用してJavaオブジェクトを直接送信できます。リクエストまたはレスポンスでJavaオブジェクトのサポートを有効にするには、「メッセージ・サービス」タイプのプロキシ・サービスまたはビジネス・サービスを作成し、Service Busを通じてJavaオブジェクトを送信するか受信するかに応じて、リクエストまたはレスポンスの「メッセージング」ページで「Java」を選択します。
JMS宛先からのJavaオブジェクトのデキューには、Javaオブジェクトのデシリアライズが伴います。この処理を有効にするには、JARファイルにデキューされる予定のJavaオブジェクトのJavaクラスをパッケージ化して、JARをService Busプロジェクトにインポートする必要があります。次に、サービスに対するJMSトランスポート固有の構成ページで、「クライアントJar」フィールドでJARを選択します。「クライアントJar」フィールドは、リクエストのメッセージ・タイプとしてJavaを選択しているときはJMSプロキシ・サービスで、また、レスポンスのメッセージ・タイプとしてJavaを選択しているときはビジネス・サービスで使用できます。
Service BusのJavaオブジェクトは、パイプライン・オブジェクト・リポジトリに格納され、<java-content ref="jcid" />要素および属性によってSOAP本体で参照されます(jcidはオブジェクト・リポジトリのオブジェクトに対するキーです)。JavaオブジェクトがNULLの場合、オブジェクトはパイプラインでref="jcid:null"として表現されます。
各メッセージで使用可能なJavaオブジェクトは1つだけです。Javaタイプのメッセージ・タイプについて、Service Busはラージ・メッセージ(コンテンツ・ストリーミング)や、テスト・コンソールでのJavaタイプ・サービスのテストはサポートしていません。
Oracle Fusion Middleware構成ウィザードでJMSファイル・ストアを構成するとともに、JMSを使用するプロキシ・サービスおよびビジネス・サービスに、次のリソースを構成する必要があります。
JMS接続ファクトリ。JMSを使用して実装されたすべてのビジネス・サービスとプロキシ・サービスに、XAまたは非XAのJMS接続ファクトリを構成する必要があります。
JMSキューまたはトピック。Service Busでは、JMSを使用して実装されたプロキシ・サービスに自動的にJMSキューが構成されます。JMSを使用するすべてのビジネス・サービスおよび非JMSを使用して実装されたプロキシ・サービスには、JMSキューまたはトピックを構成する必要があります。
すべてのService Bus JMSリソースを単一のJMSモジュールにまとめる場合、Oracle WebLogic Server管理コンソールを使用して、プロキシ・サービスのエンドポイントとして使用する宛先を含む新しいJMSモジュールを作成します。JMSリソースの構成の詳細は、『Oracle WebLogic Server JMSリソースの管理』のJMSリソースの構成方法に関する項を参照してください。
次の項では、異なるJMSプラットフォームを使用する場合の相互運用性に関する情報とリンクを示します。
WebLogic Server JMSの詳細は、次のトピックを参照してください。
『Oracle WebLogic Server JMSアプリケーションの開発』のアプリケーションの管理に関する項を参照してください。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバーの構成に関する項
注意:
Service Busでは、リモート・トランザクション・サポートの構成に不可欠なMQ Extended Transactional Clientがサポートされています。
Service Busは、WebSphere MQ JMSインタフェースを介してWebSphere MQに接続するため、Service BusはWebSphere MQ JMSクライアントです。WebSphere MQは、次の方法でService Busと対話できます。
Service BusがWebSphere MQのフロントエンドとして機能し、他のアプリケーションからのサービス・リクエストを受け入れ、それらをWebSphere MQリクエストに変換します。
WebSphere MQがService Busを介して他のアプリケーションにメッセージを送信します。
詳細は、「WebSphere MQ JMSインタフェースの使用」を参照してください。
SOAPはトランスポート方式に依存しないため、SOAPトランスポートでHTTPのかわりにJMSを使用できます。Service Busでは、JMSリクエスト/レスポンスによるSOAPメッセージと、SOAPベースのWebLogic Serverクライアントおよびサービスとの相互運用性をサポートしています。JMSは、信頼性の高いメッセージング方法でもあります。
WebLogic ServerでJMSリソースを構成するときは、次のSOAP-JMS URI形式をWebLogic Serverで使用します。
jms://host:port/contextURI/serviceName?URI=destJndiName
Service Busでサービスを構成する場合、URIは次の形式で指定する必要があります。
jms://host:port/connection_factory/jndi_destination
どちらの形式でも同じjndi_destinationを使用します。jndi_destinationは、ターゲットのWebLogic Serverの既存のQueueConnectionFactoryのJNDI名である必要があります。詳細は、『Oracle WebLogic Serverの理解』のWebLogic Serverのメッセージングに関する項を参照してください。このドキュメントでは、JMSの概要と詳細へのリンクを示します。
注意:
WebLogic Serverでは、JNDI名でmyqueues/myqueueのようにフォワード・スラッシュを使用できますが、フォワード・スラッシュのあるJNDI名は、Service Busに必要とされるURI形式と一致しないため、このような名前は使用できません。この問題を回避するには、JMS外部サーバーを定義してURIでその外部サーバーを参照します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成に関する項を参照してください。
Service BusからWebLogic Serverサービスを呼び出す場合は、リクエストをビジネス・サービスに送信する前に、パイプライン内でアウトバウンド変数($outbound)に値/contextURI/serviceNameを指定したURIをJMSプロパティとして設定する必要があります。このプロパティを設定するには、トランスポート・ヘッダー・アクションを使用します。$outboundの設定の詳細は、「inbound変数とoutbound変数」を参照してください。
WebLogic Server Webサービス・クライアントがService Busプロキシ・サービスを呼び出す場合、URIプロパティは無視されます。ただし、トランスポート・ヘッダー・アクションのパススルー・オプションを使用すると、呼び出されるサービスにパススルーできます。詳細は、「コンソールでのトランスポート・ヘッダー・アクションの追加」を参照してください。
Service Busで呼び出すことができるのは、バージョン9.2以降で実行されているOracle WebLogicリクエスト/レスポンス・サービスのみです。ただし、一方向のJMSサービスも呼び出すことができます。
ドメイン間JMS呼出しのレスポンス・キューを構成する場合は、リクエスト側の管理対象サーバーごとに個別のレスポンス・キューを設定します。
たとえば、2つのService Busクラスタ・ドメイン(ドメインAとドメインB)が、2つの管理対象サーバーを含むWebLogic Serverドメインと通信しているとします。ドメインAには3つの管理対象サーバーがあり、ドメインBには4つの管理対象サーバーがあります。ドメインAとドメインBにレスポンスを返すには、レスポンス・キューとして機能する7つ(3 + 4 = 7)の異なるキューをWebLogic Serverドメインに構成する必要があります。この7つのキューは、(WebLogic Serverドメインの両方の管理対象サーバーにメンバーを持つ)分散キューである場合もあります。
注意:
異なるリモート・ドメインによってホストされている複数のプロキシ・サービスからJMSリクエストを受信するには、リクエスト側の各ドメインに対応する個別のレスポンス・キューのセットを使用して、JMSビジネス・サービスをホストするバックエンドのドメインを構成する必要があります。
複数のドメインを使用する作業では、構成が次の要件に準拠していることを確認します。
WebLogic Serverインスタンス名およびドメイン名がユニークであること。
WebLogic JMSサーバー名はドメイン間に渡って一意とします。
永続メッセージ用にJMSファイル・ストアを使用している場合、そのJMSファイル・ストア名がドメイン間に渡って一意でなければなりません。
JMSサーバー名に関しては次のルールを確認します。
同じドメインに重複したJMSサーバー名を持つことはできません。重複したJMSサーバー名があると、メッセージが特定のJMSサーバーの宛先に送信されたときに、Service Busはメッセージの送信先のサーバーを判別できません。
ストア・アンド・フォワード(SAF)を使用する場合は、異なるドメインに重複したJMSサーバー名があってもかまいません。
ドメイン間通信の場合、ReplyTo機能を使用するときに、重複したJMSサーバー名が問題になることがあります。特定のドメインから送信されたReplyToメッセージは、元のメッセージを送信したドメインではなく、そのメッセージを受信した同じドメイン上のJMSサーバーに返されます。
WebLogic JMSの構成と管理方法については、次を参照してください。
『Oracle WebLogic Server JMSアプリケーションの開発』のアプリケーションの管理に関する項を参照してください。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバーの構成に関する項
プロキシ・サービスにおけるJMSクライアントIDは、jms-client-id記述子の値であり、サブスクライバ名およびトピックのサブスクライバのクライアントID値を生成するために使用されます。トピック宛先を使用してJMSプロキシ・サービスを構成する場合は、サブスクライバ名およびサブスクライバのクライアントIDの生成時にJMSクライアントIDが使用されるように指定できます。これによって、実行時にサービスおよびトピックを監視および管理する際に、サブスクライバおよび対応するプロキシ・サービスを簡単に識別できるようになります。これは、恒久サブスクリプションにおいてのみ有効です。
トピック宛先のサブスクリプションは、クライアントIDおよびサブスクライバ名によって識別できます。これらの値は、次の記述子を使用して、様々なTopicMessagesDistribution構成に対して生成されます。
jms-client-id: トピック宛先をターゲットとするJMSプロキシ・サービスでJMS Client IDプロパティに対して構成される値。
ejb-name: プロキシ・サービスに対してService Busによって生成されるMDBの名前。これは、一意のID値です。
DomainName: Service Busドメインの名前。
ServerName: ランタイムService Busサーバーの名前。
UniqueKey: generate-unique-client-id記述子がtrueに設定されている場合に、WebLogic Serverによって生成される一意のキー。generate-unique-client-id記述子は、JMSプロキシ・サービスによってデプロイされたMDBに対して、常にtrueに設定されます。
次の表に、様々な配信モードでサブスクライバのクライアントIDおよび名前が生成される方法を示します。
| トピック・メッセージ配信 | サブスクライバのクライアントID | サブスクライバ名 |
|---|---|---|
アプリケーションごとに1つのコピー |
jms-client-id |
ejb-name |
サーバーごとに1つのコピー |
{jms-client-id}_{DomainName}_{ServerName} |
ejb-name |
互換性 |
{jms-client-id}_{ドメイン名}_{サーバー名}_{一意キー} |
クライアントIDと同じ |
その他にも、サブスクライバのクライアントIDに影響を与える記述子があります。distributed-destination-connection記述子は常にlocalに、generate-unique-client-id記述子は常にtrueに設定されます。詳細は、Oracle WebLogic ServerメッセージドリブンBeanのプログラミングの「トピックのサブスクリプション識別子」を参照してください。
アプリケーション・エラーおよび通信エラーを処理するJMSトランスポート・ビジネス・サービスは、次のように構成します。
アプリケーション・エラーが発生したときにビジネス・サービスのエンドポイントURIを再試行するかどうかを指定できます。詳細は、『Oracle Service Busの管理』のビジネス・サービス用のエンドポイントURIの管理とモニターに関する項を参照してください。
リクエスト/レスポンスを使用するように構成されたJMSビジネス・サービスでは、レスポンス・メッセージのSystem.getProperty("com.bea.wli.sb.transports.jms.ErrorPropertyName", "SERVER_ERROR")プロパティがtrueである場合にアプリケーション・エラーが発生します。このシナリオでは、JMSトランスポート・プロバイダは、TRANSPORT_ERROR_APPLICATIONエラー・コードを使用してエラー・メソッドを呼び出します。
通信エラーが発生したときにビジネス・サービスのURIをオフラインにするように構成できます。ビジネス・サービスの操作設定を構成するときに、指定した再試行間隔の後、ビジネス・サービスのエンドポイントURIがオフラインになるように設定できます。詳細は、『Oracle Service Busの管理』のビジネス・サービス用のエンドポイントURIの管理とモニターに関する項を参照してください。
次のアクティビティのいずれかでJMS例外またはネーミング例外が発生すると、通信エラーが発生します。
JMS接続ファクトリのルックアップ
JMS接続ファクトリからのJMS接続の作成
接続オブジェクトを使用したJMSセッションの作成
JMS宛先のルックアップ
セッション・オブジェクトからの送信者の作成
送信者および宛先オブジェクトを使用したJMSメッセージの送信
Javaオブジェクト・メッセージのビジネス・サービスまたはJavaコールアウトへのルーティング中などに、JMSプロキシ・サービスで例外が発生したら、プロキシ・サービスが例外インスタンスにアクセスして、それを呼出し元のクライアントに返すことができるように、メッセージ・ペイロードを正しく書式設定してください。必ず、ペイロードは次の形式に従ってください。
<soap:Body xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<ctx:java-content ref="key1"
xmlns:ctx="http://www.bea.com/wli/sb/context" />
</soap:Body>
ここで、key1はオブジェクト・リポジトリ内のJavaオブジェクトに対するキーです。ペイロードがこの形式ではない場合、パイプラインはnullのペイロードをインバウンドJMSトランスポートに渡します。
エラー・ハンドラの使用
Javaオブジェクトに関連するパイプライン・エラーは、エラー・ハンドラを使用して捕捉できます。エラー・ハンドラの$fault変数には、例外インスタンスへの参照が含まれます(java-exception要素)。
$fault変数に例外インスタンスへの参照が含まれない場合、変数$faultの情報を使用するエラー・ハンドラ内でJavaコールアウトを使用して、前述の$bodyペイロードの形式で例外インスタンスを生成できます。$bodyをインバウンドJMSトランスポートに対するペイロードとして使用できるように、失敗時の返信アクションを使用する必要があります。
明示的にエラーを定義するWSDLファイルを使用している場合、XMLエラーのタイプに対し、WebLogic clientgenツールによってjava.lang.Exceptionというサブクラスが生成されます。WebLogic Server JAX-RPCスタックがSOAP応答メッセージを検査し、応答メッセージにSOAPフォルトが含まれると判断すると、そのエラーをclientgen生成の例外Javaクラスにマップしようとします。
たとえば、次のリストに示す定義がWSDLファイルに含まれる場合、clientgenツールはjava.lang.Exceptionを拡張したcom.bea.test.TheFaultType Javaクラスを生成します。このサービス・スタブの関連メソッドが呼び出されると、JAX-RPCクライアントがcom.bea.test.TheFaultTypeを受け取る可能性があります。
例 - WSDL定義のサンプル
<definitions ... xmlns:s0="http://www.oracle.com/test/">
...
<types>
<xsd:schema targetNamespace="http://www.oracle.com/test/">
...
<xsd:complexType name="theFaultType">
<xsd:sequence>
<xsd:element name="ID" type="xsd:int" />
<xsd:element name="message" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
<xsd:element name="theFault" type="theFaultType" />
</xsd:schema>
</types>
...
<message name="theFaultMessage">
<part element="s0:theFaultPart" name="theFault" />
</message>
...
<binding ...>
<operation ...>
<soap:operation soapAction="..." style="document" />
<input ...>
...
</input>
<output ...>
...
</output>
<fault ...>
<soap:fault name="theFaultPart" use="literal" />
</fault>
</operation>
</binding>
...
</definitions>
SOAPメッセージには正しい形式のエラーが含まれ、JAX-RPCスタックが正しい例外をスローできるようになっている必要があります。詳細は、「フォルトがService Busパイプライン内から作成される場合にSOAPメッセージにフォルトを追加」を参照してください。
SOAPメッセージには正しい形式のエラーが含まれ、JAX-RPCスタックが正しい例外をスローできるようになっている必要があります。
フォルトがService Busパイプライン内から作成される場合、次のことを行う必要があります。
返信アクションの構成の詳細は、「コンソールでの返信アクションの追加」を参照してください。
clientgenツールを使用して、Webサービスを呼び出すために必要なクライアント側のアーティファクト(JAX-RPCスタブなど)を生成します。『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のAntタスク・リファレンスの項を参照してください。
この項では、Service BusでサポートされるJMSリクエスト/レスポンスのメッセージIDと相関IDのパターン、およびService Busでこれらのパターンを使用してJava API for Remote Procedure Call (JAX-RPC) Webサービスと相互運用する方法について説明します。例も示します。
メッセージングでは、プログラム間で配信が保証された高速非同期通信を行います。多くの場合、メッセージングはメッセージ指向ミドルウェア(MOM)と呼ばれるソフトウェアのレイヤーとして実装されます。エンタープライズ・コンピューティングにおいて、プロセスやプロセス間の通信の信頼性がそれほど高くない場合でも、メッセージングによりプロセス間の通信の信頼性が高まります。プロセスで通信が必要になる理由は次のとおりです。
あるプロセスのデータを別のプロセスに送信する必要があります。
あるプロセスが別のプロセスのプロシージャをリモートから呼び出す必要があります。
IBM WebSphere MQを使用している場合、特定のメインフレームとの対話には非同期リクエスト/レスポンス・メッセージングを使用することをお薦めします。
クラスタ・ドメインおよびリクエスト/レスポンスのシナリオでは、JMSトランスポートによってMDBがクラスタの個々の管理対象サーバーにデプロイされます。しかし、動的クラスタ・ドメインでは、動的サーバーを個々のアプリケーションにターゲット指定することができないため、JMSトランスポートはリクエスト/レスポンスのシナリオに対してのみ構成済管理対象サーバーにMDBをデプロイできます。この動的クラスタに関する制限の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの管理』ガイドの動的クラスタを使用する際の制限事項と考慮事項に関する項を参照してください。
メッセージングのパターンには、MOMで構築されたシステムの各部分間をフローするメッセージのフォーマットが記述されます。メッセージには、次のような様々なタイプがあります。
メッセージング・システムでプロシージャ・コールのセマンティクスを実行できるようにするコマンド・メッセージ。
メッセージング・システムが情報(コマンド・メッセージの結果として送信側に返す情報など)をトランスポートできるようにするドキュメント・メッセージ。
メッセージングを使用してイベントの通知を実行するイベント・メッセージ。
リモート・プロシージャ・コールの結果のセマンティクスを処理する応答メッセージ。応答メッセージでは、成功した結果と失敗した結果の両方を処理できる必要があります。
リクエストを作成するプログラムが応答送信時のチャネルを識別できるようにする応答指定子。
リクエスト元のプログラムが特定のレスポンスをリクエストに関連付けることを可能にする相関ID。渡されたデータが複数のメッセージにわたる場合は、シーケンス識別子により、受信側は元のデータを正確に再構築できます。
送信側がメッセージを配信または無視することによって期限を設定できるようにするメッセージ有効期限。
受信側がメッセージの受信率を制御できるようにするメッセージ抑制。
Service Busの場合、各返信メッセージに、リクエスト・メッセージと返信を関連付ける相関IDと呼ばれる一意の識別子を含める必要があります。
呼出し側は、リクエスト・メッセージの作成時に、現在未完了の他のすべてのリクエスト(応答をまだ受信していないリクエストなど)の識別子とは異なる一意の識別子をリクエストに割り当てます。受信側は、リクエストを処理するときにこの識別子を保存し、リクエストの識別子を応答に追加します。呼出し側は、応答を処理するときにリクエストの識別子を使用してリクエストを応答に関連付けます。この識別子は、呼出し側が各応答とリクエストの関連付けに使用するため、相関IDと呼ばれます。
通常、相関IDはメッセージのヘッダーに配置されます。このIDは、呼出し側が受信側に伝達するコマンドまたはデータに含まれるわけではありません。受信側は、リクエストのIDを保存し、呼出し側のために応答に追加します。メッセージ本文は2つのシステム間で送信されるコンテンツであり、IDはコンテンツの一部ではないため、IDはヘッダーに追加されます。リクエスト・メッセージには、IDを相関IDプロパティとして格納することも、単にメッセージIDプロパティとして格納することもできます。IDが相関IDとして使用されている場合、どのメッセージがリクエストでどのメッセージが応答か混乱を招くおそれがあります。リクエストにメッセージIDが含まれ、相関IDは含まれていない場合、応答にはそのリクエストのメッセージIDと同じ相関IDが含まれます。Service Busで内部的に使用される相関IDの形式はWebSphere MQの形式と互換性があり、MQネイティブのインタフェースが使用されているターゲット・サービスで動作します。
アウトバウンド・トランスポートでは、非同期のリクエスト/レスポンス・メッセージを処理します。つまり、トランスポート方式固有のデータである$outboundを除き、JMSリクエスト/レスポンスとHTTPリクエスト/レスポンスのパイプラインに違いはありません。
JMSリクエスト/レスポンス・ビジネス・サービスまたはプロキシ・サービスを定義するときには、まず設計パターンを選択する必要があります。これを行うには、JMSプロキシ・サービスでは「レスポンスが必要」オプション、JMSビジネス・サービスでは「レスポンス・キュー」オプションを選択し、JMSの「トランスポート構成」ページで次のいずれかの相関パターンを選択します。
JMS相関ID (デフォルトのパターン)
JMSメッセージID
注意:
プロキシ・サービスに対する相関IDのマッピングがメモリーに格納されているため、JMSリクエスト/レスポンス・メッセージングに信頼性のあるレスポンスが返されません。リクエストの送信後にレスポンスが受信されるまでの間に障害またはシステムの再起動が発生すると、そのレスポンスは破棄されます。
この状況を回避するには、JMSリクエスト/レスポンスを使用せずに、2つの一方向JMSプロキシ・サービス(メッセージ配信用とレスポンス配信用の2つ)を使用します。
次の項では、これらのパターンについて説明します。2つのパターンを比較するには、「メッセージIDと相関IDのパターンの比較」を参照してください。
JMSメッセージIDのパターンを使用してビジネス・サービスを作成する場合は、レスポンスが1つのURIに送信されるように構成できます。あるいは、フェイルオーバーをサポートするために、Service Busクラスタの各管理対象サーバー上の各リクエストURIに対してレスポンス・キューを構成できます。これらのキューは、サービスのリクエスト・キューと同じ場所に存在する必要があります。プロキシ・サービスは、ビジネス・サービスを呼び出すときにこの情報を使用してJMSReplyToプロパティを設定し、このリクエストを出した管理対象サーバーによってレスポンスが処理されるようにします。
JMSメッセージIDのパターンを使用してプロキシ・サービスを定義すると、プロキシ・サービスはJMSReplyToプロパティで指定されたキューに返信するため、レスポンスURIを定義する必要はありません。ただし、レスポンス・メッセージに対してJMS接続ファクトリのJNDI名を指定できます。JMSReplyToプロパティには、「JMSReplyToプロパティへのアクセス」の説明に従い、トランスポート・メタデータを介してアクセスできます。
注意:
デフォルトでは、リクエスト・メッセージの接続ファクトリが使用されます。これが役立つのは、JMSレスポンスに対して非XA接続ファクトリを使用するが、リクエストに対してXA接続ファクトリがある場合です。
デプロイメント記述子をXA対応リソースに適切に設定するには、プロキシ・サービスを作成する前に、参照接続ファクトリのXA属性を設定する必要があります。
呼び出されたサービスは、リクエストのメッセージID (JMSヘッダー・フィールドJMSMessageIDの値)をレスポンスの相関IDにコピー(JMSヘッダー・フィールドJMSCorrelationIDを設定)する必要があります。また、呼び出されたサービスは、JMSReplyToヘッダー・フィールドに指定されたキューに返信する必要があります。JMSメッセージIDのパターンを選択すると、レスポンスは適切な管理対象ノードに送信されます。
注意:
JMSメッセージID相関パターンは、プロキシ・サービスが別のプロキシ・サービスを呼び出す場合はサポートされません。
JMSプロキシ・サービスの場合、着信メッセージ内のJMSReplyToプロパティは、同じくJMSReplyToという名前を持つ、JMSトランスポート・メタデータ要素内のJavaオブジェクトとして格納されます。アウトバウンド・リクエストに含まれるこのメタデータ要素の値をビジネス・サービスに渡すと、動的な返信先をサポートできます。パイプラインでは、この値をJavaコールアウト・アクションに渡して変換できます。JMSプロキシ・サービスが、パイプラインを使用せずにJMSビジネス・サービスを直接呼び出す場合、JMSトランスポート・メタデータは自動的にビジネス・サービスに渡されます。プロキシ・サービスでパイプラインを呼び出す場合、ヘッダーをインバンド・メッセージからコピーしてアウトバウンド・リクエスト・ヘッダーで設定するようにパイプラインを構成する必要があります。
JMSビジネス・サービスがパイプラインを使用せずに直接呼び出される初めてのケースの場合、このキューをリスンするコンシューマは、JMSReplyToヘッダーを読み取り、さらにメッセージをヘッダーの宛先に送信します。つまり、2つのメッセージがキューに書き込まれます。これを避けるには、サービス間でパイプラインを使用します。
リクエスト/レスポンス・プロキシ・サービスの場合、JMSReplyToメタデータ要素は、相関パターンがメッセージIDの場合のみ設定されます。パターンが相関IDの場合、プロキシ・サービスはJMSReplyToの値をトランスポート構成から特定するため、この値はメタデータ要素には設定されません。
注意:
JMSReplyToメタデータ要素にはJavaオブジェクトのjava-content表現が含まれるため、この要素はテスト・コンソールに表示されません。
ビジネス・サービスをJavaで設計するときは、レスポンスのJMS相関IDの値をリクエストのJMS相関IDの値に設定してから、JMSレスポンスをキューに送信するようにします。メッセージの受信時にJMS相関IDを取得するには、次の方法を使用します。
String getJMSCorrelationID()
上記のメソッドは、特定のメッセージIDまたはアプリケーション固有の値を表す相関IDの値を文字列として返します。
メッセージの送信時にJMS相関IDを設定するには:
void setJMSCorrelationID(String correlationID)
JMSリクエスト/レスポンス・パターンは次の点で異なります。
レスポンスをリクエストと関連させる方法
レスポンス・キューの選択
この2つのパターンの相違について、表31-1にまとめます。
表31-1 メッセージIDと相関IDのパターンの相違点
| JMSパターン名 | レスポンス・キュー | CorrelationID |
|---|---|---|
相関IDのパターン |
すべてのレスポンスは固定された同じキューに入れられます。 |
サーバーはリクエストの相関IDをレスポンスの相関IDにコピーします。 |
メッセージIDのパターン |
レスポンスは、 |
サーバーはリクエストのメッセージIDをレスポンスの相関IDにコピーします。 |
相関IDのパターンが使用される場合、呼び出されたサービスは、リクエストURIに対応するキューに応答します。レスポンスは常に同じキューに置かれ、クライアントはレスポンスが置かれるキューを制御できません。たとえば、10のクライアントがリクエストURI「A」にメッセージを送信した場合、これらのクライアントはすべてリクエストURI「A」に対応するキューからレスポンスを取得します。このため、クライアントはレスポンス・キューのメッセージをフィルタして、各自に関連するレスポンスを選択する必要があります。フィルタ条件をリクエスト・メッセージの相関IDプロパティに構成し、これをレスポンスの相関IDプロパティに返すようにサーバーを構成します。
メッセージIDのパターンの場合、クライアントのJMSReplyToプロパティによってサーバーにレスポンスの送信先を指示します。このキューはクライアントのサーバーに固有であるため、別のクライアントへのレスポンスは別のキューに置かれます。サーバーは、レスポンスのJMS相関IDをリクエストのJMSメッセージIDに設定します。
メッセージIDによる相関は、JMSアプリケーションだけではなく多くのIBM MQアプリケーションでも一般に使用されており、リクエストとレスポンスを関連付ける標準的な方法です。
メッセージIDのパターンによるJMSリクエスト/レスポンスを使用して、複数のOracle WebLogicクライアント・ドメインからターゲットのOracle WebLogicドメインを呼び出す場合は、リクエスト・キューとレスポンス・キューの両方をSAFキューとして設定できます。ただし、所定のリクエストURIに対するすべてのレスポンスに単一のキューを使用する相関IDのパターンでは、このように設定することはできません。
相関IDのパターンには主に2つの利点があります。
レスポンス・キューの構成が簡単であり、クラスタに管理対象サーバーが新しく追加されるたびに変更する必要はありません。
ドメインのプロキシ・サービスが同じドメインの別のプロキシ・サービスを呼び出す必要がある場合、相関IDも使用できます。
Service Bus開発環境では、HTTP/HTTPSに加え、JMSトランスポートを使用するJAX-RPC Webサービスを作成できます。このようなJMS転送のJAX-RPC Webサービスでは、操作に関連付けられた値を取得したり返したりするためのメカニズムとしてJMSキューを使用します。JMSメッセージIDのパターンを使用して、JMS転送のJAX-RPC Webサービスを呼び出すことができます。
また、Oracle WebLogic clientgenのAntタスクによって生成されたJAX-RPC静的スタブから、JMSリクエスト/レスポンス・プロキシ・サービスを呼び出すこともできます。
JMSメッセージIDのパターンを使用してJMS転送のJAX-RPC Webサービスを呼び出すには、以下の手順を実行します。
JMSメッセージIDのパターンを使用してJMSトランスポートのJAX-RPC Webサービスを呼び出す、JMSリクエスト/レスポンス・ビジネス・サービスを作成します。詳細は、Service Busで提供されるオンライン・ヘルプを参照してください。
このビジネス・サービスは、JMSトランスポートを使用します。エンドポイントURIのJMSキューJNDI名の部分は、JMSトランスポートのJAX-RPC Webサービスの@WLJmsTransport注釈に指定したキュー属性と同じであることが必要です。次に例を示します。
jms://localhost:7001/AJMSConnectionFactoryJNDIName/JmsTransportServiceRequestQueue
「宛先」フィールドに割り当てるJMSキューのJNDI名は、「ターゲット」フィールドに表示されるWebLogic Server名を対象としたJMSサーバーに関連付けられている必要があります。
注意:
WebLogic Serverでは、JNDI名でmyqueues/myqueueのようにフォワード・スラッシュを使用できますが、フォワード・スラッシュのあるJNDI名は、Service Busに必要とされるURI形式と一致しないため、このような名前は使用できません。この問題を回避するには、JMS外部サーバーを定義してURIでその外部サーバーを参照します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成に関する項を参照してください。
手順1で作成したJMSリクエスト/レスポンス・ビジネス・サービスへのルーティング(またはサービス・コールアウト)アクションを含むプロキシ・サービスを作成します。
ルーティング・アクションの「リクエスト・アクション」領域には、アウトバウンド・リクエストのトランスポート・ヘッダーの設定アクションを含める必要があります。トランスポート・ヘッダー・アクションを構成するときは、アウトバウンド・リクエスト・アクションの2つのJMSヘッダーを追加する必要があります。トランスポート・ヘッダー・アクションの構成方法の詳細は、「コンソールでのトランスポート・ヘッダー・アクションの追加」を参照してください。
次に、手順を簡単に説明します。
トランスポート・ヘッダー・アクションを構成するには、「ヘッダーの追加」フィールドの「その他」を選択し、表示されたフィールドにURIを入力します。
「ヘッダーを<Expression>に設定」を選択し、(JMSトランスポートのJAX-RPC Webサービスの@WLJmsTransport注釈で)contextPath属性とserviceUri属性に指定した値を続けて入力(各属性の値の前にはスラッシュを入力)して式を作成します。たとえば、@WLJmsTransportアノテーションが次のように指定されているとします。
@WLJmsTransport( contextPath="transports", serviceUri="JmsTransportService", portName="JmsTransportPort", queue="JmsTransportServiceRequestQueue" )
トランスポート・ヘッダーを構成する場合、「XQueryテキスト」入力領域に次の式を入力します。
/transports/JmsTransportService
2つ目のJMSヘッダーを指定するには、「ヘッダーの追加」フィールドの「その他」をもう一度選択し、関連するフィールドに_wls_mimehdrContent_Typeと入力します。
「ヘッダーを<Expression>に設定」を選択し、「XQueryテキスト」入力領域にtext/xml; charset=UTF-8と入力します。
JAX-RPC WebLogic Serverクライアントからプロキシ・サービスを呼び出すシナリオでは、プロキシ・サービスのインバウンド・レスポンスに_wls_mimehdrContent_Type JMSヘッダーを設定し、着信JMSメッセージIDパターン・リクエストへのレスポンスを発行するときに、そのヘッダーを指定します。
たとえば、JAX-RPCクライアントからプロキシ・サービスを呼び出し、続いてWebLogic Server Webサービスを呼び出すシナリオでは、ルート・ノードの構成は次のようになります。
リクエスト・パイプラインの場合
Webサービス・コンテキストURIのトランスポート・ヘッダーを設定します(例: interop/AllocJmsDocLit)。
_wls_mimehdrContent_Typeのトランスポート・ヘッダーを、text/xml; charset=UTF-8に設定します。
「トランスポート・ヘッダーを設定」メニュー項目から「アウトバウンド・リクエスト」を選択します。
「パイプラインを介してすべてのヘッダーを渡す」を有効にします。
レスポンス・パイプラインの場合
空のトランスポート・ヘッダーを追加し、「トランスポート・ヘッダーを設定」メニューから「インバウンド・レスポンス」を選択します。
「パイプラインを介してすべてのヘッダーを渡す」を有効にします。
注意:
トランスポート・ヘッダー・アクションを構成する手順については、「コンソールでのトランスポート・ヘッダー・アクションの追加」を参照してください。
次の例で、JMSメッセージIDのパターンを使用する様々な方法について説明します。
図31-1では、リクエスト/レスポンス通信においてMQサービスをホストするサーバーがリクエスト・メッセージIDをレスポンス相関IDに返し、レスポンスをreplyToキューに送信します。レスポンスが戻り、JMSメッセージIDを使用して関連付けられます。Service BusのreplyTo宛先は、ビジネス・サービスの構成時に、クラスタのService Busノードごとに1つ設定されています。また、JMSまたはMQネイティブ・クライアントが、JMSメッセージIDのパターンを使用してJMSリクエスト/レスポンス・プロキシ・サービスを呼び出すことができます。クライアントは、レスポンスを受け取るキューにreplyToプロパティを設定する必要があります。
この使い方で重要なのは、JMSメッセージIDがリクエスト/レスポンス・メッセージの相関を行うことです。また、クラスタ・サーバーと同じ数のMQ Seriesアウトバウンド・レスポンス・キューを作成する必要があります。
図31-2は、Service Busプロキシ・サービスにメッセージを送信するJAX-RPCクライアントを表します(JAX-RPCインバウンドの場合)。JAX-RPCスタックは、レスポンスを受信するために一時的なキューを使用します。JMSトランスポートでは、実行時にこの一時的なキューを使用します。
図31-3は、JAX-RPCアウトバウンド、つまりWebLogic Server JAX-RPCリクエスト/レスポンス・サービスとService Busプロキシ・サービスとの相互運用性を表します。
図31-3 WebLogic Server JAX-RPCサービスのクライアントとしてのService Bus
注意:
1つ目のWebLogic Serverドメインのプロキシ・サービスが2つ目のドメインのプロキシ・サービスにメッセージを送信する必要がある場合、まずドメイン1のパススルー・ビジネス・サービスにメッセージをルーティングする必要があります。ドメイン1とドメイン2の間のJMSストア・アンド・フォワードでは、ドメイン2のプロキシ・サービスにインバウンド・リクエスト・メッセージを転送します。JMSリクエスト/レスポンスを使用する場合、JMSストア・アンド・フォワードを使用して、ドメイン2からドメイン1にインバウンド・レスポンス・メッセージを転送することもできます。この場合、ドメイン2のプロキシ・サービスに対して、エクスポートされるインバウンド・リクエスト・キューとインポートされるインバウンド・レスポンス・キューをドメイン2で構成する必要があります。JMSストア・アンド・フォワードの構成に特に注意する必要があります。
どのサービス・タイプのプロキシおよびビジネス・サービスに対しても、JMSをトランスポート・プロトコルとして選択できます。この項では、ビジネスおよびプロキシ・サービスのJMSトランスポート用に構成できるプロパティについて説明します。ビジネス・サービスのエラー処理の詳細は、「JMSトランスポートのエラー処理」を参照してください。
プロキシ・サービスを構成するときに、トランスポート・ヘッダー・アクションを使用してメッセージのヘッダー値を設定できます。詳細は、「JMSトランスポート・ヘッダー」を参照してください。
次の形式で、JMSトランスポートのエンドポイントURIを入力します。
jms://host:port[,host:port]*/connection_factory/jndi_destination
説明:
hostは、サービスをホストするシステムの名前です。
portは、接続を行うポート番号です。
[,host:port]*は、対応するポートで複数のホストを構成できることを示します。
connection_factoryは、JNDI接続ファクトリの名前です。接続ファクトリ・キューを定義する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールのリソースの構成に関する項を参照してください。
jndi_destinationは、JNDI宛先の名前です。
JMS宛先として複数のサーバーを指定するには、次のURI形式を使用します。
jms://host1:port,host2:port/connection_factory/jndi_destination
ここで、connection_factoryは、接続ファクトリ・キューの名前です。接続ファクトリ・キューを定義する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールのリソースの構成に関する項を参照してください。
注意:
WebLogic Serverでは、JNDI名でmyqueues/myqueueのようにフォワード・スラッシュを使用できますが、フォワード・スラッシュのあるJNDI名は、Service Busに必要とされるURI形式と一致しないため、このような名前は使用できません。この問題を回避するには、JMS外部サーバーを定義してURIでその外部サーバーを参照します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成に関する項を参照してください。
次の表に、JMSベースのプロキシ・サービスの構成に使用するプロパティを示します。詳細は、「プロキシ・サービスの作成と構成」を参照してください。
表31-2 プロキシ・サービス用のJMSトランスポート・プロパティ
| プロパティ | 説明 |
|---|---|
宛先タイプ |
次のいずれかを選択します。
|
レスポンスが必要 |
アウトバウンド・メッセージの送信後にレスポンスを受け取ることを指定する場合は、このオプションを選択します。 このオプションは、「宛先タイプ」が「キュー」の場合のみ使用できます。 |
レスポンス・パターン |
次のいずれかを選択して、レスポンスの設計パターンを指定します。
このオプションは、「レスポンスが必要」チェック・ボックスが選択されている場合のみ使用できます。 |
レスポンス・メッセージ・タイプ |
レスポンス・メッセージのタイプとして、次のいずれかを選択します。
レスポンスにJavaのメッセージ・タイプを選択した場合、このオプションは無効です。「レスポンスが必要」チェック・ボックスが選択されている場合のみ使用できます。 |
クライアントJar |
Javaオブジェクトを含むメッセージのデキューに使用する、クライアントJARを選択します。クライアントJARの選択によって、それがクラスパス上にあることが確認されます。このオプションは、サービスが、Javaリクエスト・タイプのメッセージング・サービスのときに使用できます。 詳細は、「メッセージでのJavaオブジェクトの送信および受信」を参照してください。 |
ディスパッチ・ポリシー |
このエンドポイントのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。 ワーク・マネージャの詳細は、次の説明を参照してください。
|
リクエストのエンコーディング |
リクエストのエンコード用の文字セットを入力します。デフォルト値は |
レスポンスのエンコーディング |
レスポンスのエンコード用の文字セットを入力します。デフォルト値は このオプションは、「レスポンスが必要」チェック・ボックスが選択されている場合のみ使用できます。 |
クライアント・レスポンス・タイムアウト |
接続を切断するまでのサーバー・レスポンスの待機時間を秒単位で入力します。このフィールドの値は、クライアントが同一ドメインの別のプロキシ・サービスである場合にのみ適用されます。 このオプションは、「レスポンスが必要」チェック・ボックスが選択されている場合のみ使用できます。 |
レスポンスURI |
次に示すいずれかの形式で、レスポンスURIを入力します。このオプションは、「レスポンス・パターン」で「JMSCorrelationID」が選択されている場合にのみ使用できます。 jms://host:port/connection_factory/jndi_destination 複数のサーバーをターゲットとする場合は、次の形式を使用します。 jms://host1:port,host2:port/connection_factory/jndi_destination レスポンスURIのホストとポートを省略することもできます。次に例を示します。 jms:///connection_factory/jndi_destination ホストとポートを省略すると、ローカル・サーバーで接続ファクトリや宛先ルックアップが発生します。これは、リクエストURIが外部接続ファクトリや宛先を指し、レスポンスをローカル・サーバーに送信する場合などに便利です。 注意: WebLogic Serverでは、JNDI名でmyqueues/myqueueのようにフォワード・スラッシュを使用できますが、フォワード・スラッシュのあるJNDI名は、Service Busに必要とされるURI形式と一致しないため、このような名前は使用できません。この問題を回避するには、JMS外部サーバーを定義してURIでその外部サーバーを参照します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成に関する項を参照してください。 |
レスポンス接続ファクトリ |
レスポンス接続ファクトリURIを入力します。このオプションは、「レスポンス・パターン」で「JMSMessageID」が選択されている場合にのみ使用できます。 接続ファクトリが指定されていない場合、リクエストの接続ファクトリがレスポンスに使用されます。 |
JMSサービス・アカウント |
JMSサーバーによって管理されているJMSリソースに使用するサービス・アカウントを選択します。サービス・アカウントは、リクエストとレスポンスの両方に使用される、ユーザーIDとパスワードの別名リソースです。同じサービス・アカウントが、JMSとJNDIの両方に使用されます。 詳細は、「サービス・アカウントの操作」を参照してください。 |
SSLを使用 |
リクエストがTLS/SSL接続を通して行われる場合にのみ、このチェック・ボックスを選択します。 TLS/SSL (Secure Sockets Layer)では、ネットワークで接続される2つのアプリケーションが互いのIDを認証し、アプリケーション間で交換されるデータを暗号化できるようにすることによって、安全な接続が可能になります。認証を使用すると、サーバー(および必要に応じてクライアント)はネットワーク接続の相手側アプリケーションのIDを検証できます。また、宛先のJNDIエントリに対してアクセス制御が設定されていることにより、管理者から個々のJMS宛先(キューまたはトピック)へのアクセスが制限されている場合、JNDIツリー内でのルックアップ時に、サービスで認証を行う必要があります。 注意: JMSトランスポートでは、双方向SSLはサポートされません。 |
メッセージ・セレクタ |
メッセージ・セレクタ式を入力します。式に一致するプロパティを持つメッセージのみが処理されます。 |
クライアントID |
サブスクライバに使用するクライアントIDをトピックに対してのみ入力します。値を入力しないと、クライアントIDが自動的に生成されます。カスタムIDを割り当てると、サービスの監視時にこのコンポーネントを識別するのに役立ちます。これは、恒久サブスクライバにおいてのみ有効です。 JMSクライアントIDは、トピックのサブスクライバに対してサブスクライバ名およびクライアントID値を生成するために使用される複数のMDB記述子の1つです。JMSクライアントIDを定義すると、サブスクライバ名またはクライアントIDによって、特定のトピックのサブスクライバを簡単に識別して表示できます。 詳細は、「プロキシ・サービスにおけるJMSクライアントID」を参照してください。 |
恒久サブスクリプション |
サブスクリプションが恒久である場合はこのチェック・ボックスを選択し、サブスクリプションが恒久でない場合は、このチェック・ボックスを空のままにします。恒久サブスクリプションは、メッセージがパブリッシュされたときにサブスクリプションが非アクティブになっている場合でも、トピックに関してパブリッシュされたすべてのメッセージを受信します。 このオプションは、「宛先タイプ」で「トピック」が選択されている場合にのみ使用できます。 |
非XA接続の再試行 |
後述の再試行回数と間隔を使用して非XA接続を再試行する場合、このチェック・ボックスを選択します。このチェック・ボックスを選択しなかった場合、Service BusはXA接続のみを再試行し、再試行回数および間隔はXA接続のみに適用されます。 このチェック・ボックスは、サービスURI内に非XA接続ファクトリを含むJMSプロキシ・サービスのみに適用されます。 |
再試行回数 |
メッセージがエラー宛先に移されるまでに許可される配信の再試行回数を入力します。このフィールドは、WebLogic Server JMS宛先にのみ適用されます。 |
再試行間隔 |
ロールバックまたは復元されたメッセージが再配信されるまでの時間をミリ秒単位で入力します。このフィールドは、WebLogic Server JMS宛先にのみ適用されます。 |
エラー宛先 |
再配信制限に達したメッセージの宛先の名前を入力します。このフィールドは、WebLogic Server JMS宛先にのみ適用されます。 |
有効期限ポリシー |
宛先で検出された有効期限切れメッセージの処理方法を定義するポリシーを選択します。メッセージを破棄またはリダイレクトすることを指定できます。リダイレクトされたメッセージは、前述のエラー宛先に移動されます。 このフィールドは、WebLogic Server JMS宛先にのみ適用されます。 |
XAが必要 |
接続ファクトリがXAである場合は、このチェック・ボックスを選択します。 このオプションは、リモート接続ファクトリが使用できない場合に考慮されます。接続ファクトリが使用可能であり、このオプションが有効になっている場合は、接続ファクトリがトランザクションとして定義されていることを確認してください。 |
トランザクション・タイムアウト |
トランザクションが処理されるまでJMSプロキシ・サービスが待機する時間を秒単位で入力します。このオプションは、XA接続ファクトリを使用しているサービスにのみ適用されます。デフォルトは600秒です。 |
レスポンス・キューにMDBなし |
インバウンド・レスポンス・キューでデフォルトのメッセージドリブンBean (MDB)を生成しない場合、このオプションを選択します。このオプションは、パフォーマンスを向上させるために使用します。このオプションを選択した場合、プロキシからプロキシへのルーティング形式はサポートされません。 |
JNDIタイムアウト |
JNDIツリーでの宛先または接続ファクトリの検索時に使用されるJNDI接続タイムアウト(秒)。 |
トピック・メッセージ配信 |
メッセージドリブンBeanによって着信JMSメッセージ、高可用性およびフェイルオーバーを処理する方法を決定するために、次のいずれかのプロパティを選択します。
このオプションは、「宛先タイプ」に「トピック」を選択した場合に使用できます。 注意: クラスタ内で互換性モードを使用する場合、重複メッセージが表示されることがあります。これを回避するには、他のいずれかのオプションを使用します。 「1コピー」オプションは、JMS接続ファクトリで構成された「サブスクリプション共有ポリシー」および「クライアントIDポリシー」をオーバーライドします。 |
ターゲット |
受信したJMSメッセージを処理するターゲット・サーバーを選択します。「トピック・メッセージ配信」で「1コピー」オプションのいずれかを選択した場合、このフィールドにはクラスタの名前が表示されます。このオプションは、「トピック・メッセージ配信」オプションに「互換性」を選択した場合に、Service Busクラスタでのみ使用できます。 対象を設定しない場合は、クラスタ内の管理対象サーバーごとにトピックからメッセージを読み取るJMSプロキシ・サービス・インスタンスによってメッセージのコピーが取得されます。 |
JMSトランスポートに関連する各種のヘッダーを表31-3に示します。順序単位ヘッダーを除き、すべてのヘッダーはアウトバウンド・リクエストとインバウンド・レスポンスの両方で共通になっています。
表31-3 JMSトランスポート・ヘッダー
| ヘッダー | 説明 |
|---|---|
JMSCorrelation ID |
メッセージを別のメッセージにリンクするために使用される識別子。たとえば、リクエスト・メッセージをレスポンス・メッセージにリンクできます。 |
JMSDeliveryMode |
メッセージの送信時に指定された配信モード。 |
JMSExpiration |
メッセージの有効期限。メッセージの有効期限が切れる特定の日時を示す絶対値です。XQuery式を使用して、各メッセージの正確な有効期限日時を計算できます。 |
JMSMessageID |
プロバイダから送信されるメッセージを一意に識別する値。 |
JMSPriority |
メッセージの処理優先順位。メッセージを送信すると、このフィールドは無視されます。送信操作が完了すると、メッセージを送信したメソッドによって指定された値が保持されます。 |
JMSType |
メッセージの送信時にクライアントによって指定されるメッセージ・タイプの識別子。 |
JMSXAppID |
JMSで定義されるプロパティの1つで、メッセージを送信するアプリケーションのIDを指定します。このプロパティは、JMSプロバイダによって設定されます。 |
JMSXGroupID |
JMSで定義されるプロパティの1つで、メッセージが属するメッセージ・グループのグループIDを指定します。このプロパティは、クライアントによって設定されます。 |
JMSXGroupSeq |
JMSで定義されるプロパティの1つで、メッセージ・グループ内でのメッセージの順序を指定します。 |
JMS_IBM_Format |
アプリケーション・データの性質。詳細は、IBM WebSphereのドキュメントを参照してください。 |
JMS_IBM_Report_Exception |
例外レポートをリクエストします。また、メッセージからレポート・メッセージに保持する必要があるアプリケーション・データの量も指定します。詳細は、IBM WebSphereのドキュメントを参照してください。 |
JMS_IBM_Report_Expiration |
期限切れレポートをリクエストします。また、メッセージからレポート・メッセージに保持する必要があるアプリケーション・データの量も指定します。詳細は、IBM WebSphereのドキュメントを参照してください。 |
JMS_IBM_Report_COA |
着信確認レポートをリクエストします。また、メッセージからレポート・メッセージに保持する必要があるアプリケーション・データの量も指定します。詳細は、IBM WebSphereのドキュメントを参照してください。 |
JMS_IBM_Report_COD |
配信確認レポートをリクエストします。また、メッセージからレポート・メッセージに保持する必要があるアプリケーション・データの量も指定します。詳細は、IBM WebSphereのドキュメントを参照してください。 |
JMS_IBM_Report_PAN |
肯定アクション通知レポートをリクエストします。詳細は、IBM WebSphereのドキュメントを参照してください。 |
JMS_IBM_Report_NAN |
肯定アクション通知レポートをリクエストします。詳細は、IBM WebSphereのドキュメントを参照してください。 |
JMS_IBM_Report_Pass_Msg_ID |
レポートまたは返信メッセージのメッセージ識別子が元のメッセージの識別子と同じになるようにリクエストします。詳細は、IBM WebSphereのドキュメントを参照してください。 |
JMS_IBM_Report_Pass_Correl_ID |
レポートまたは返信メッセージの相関識別子が元のメッセージの識別子と同じになるようにリクエストします。詳細は、IBM WebSphereのドキュメントを参照してください。 |
JMS_IBM_Report_Discard_Msg |
指定の宛先に配信できなかった場合にメッセージを廃棄するようにリクエストします。詳細は、IBM WebSphereのドキュメントを参照してください。 |
JMS_IBM_MsgType |
メッセージのタイプ。詳細は、IBM WebSphereのドキュメントを参照してください。 |
JMS_IBM_Feedback |
レポート・メッセージの性質を示すインジケータ。詳細は、IBM WebSphereのドキュメントを参照してください。 |
JMS_IBM_Last_Msg_In_Group |
メッセージがメッセージ・グループの最後のメッセージかどうかを示すインジケータ。詳細は、IBM WebSphereのドキュメントを参照してください。 |
JMS_BEA_UnitOfOrder |
このヘッダーはリクエストおよびレスポンスに有効です。 |
パイプラインでは、インバウンド・リクエストおよびアウトバウンド・リクエストの両方についてトランスポート・ヘッダーを構成できます。メッセージのヘッダーの値を設定するには、トランスポート・ヘッダー・アクションを使用します。トランスポート・ヘッダー・アクションの追加の詳細は、「コンソールでのトランスポート・ヘッダー・アクションの追加」を参照してください。JMSトランスポートに関連するトランスポート・ヘッダーの詳細は、「JMSトランスポート・ヘッダー」を参照してください。
注意:
JMSトランスポート・ヘッダーの制限の詳細は、「ランタイムがテスト・コンソールでトランスポート設定を使用する方法」を参照してください。表12-8も参照してください。
JMSビジネス・サービスを登録する場合、WSDLファイルのURIをサービス定義に追加するときに、手動で編集する必要があります。URIの形式は次のとおりです。
jms://host:port/connection_factory/jndi_destination
注意:
ビジネス・サービスでJMS IDによるレスポンス相関を使用するようにJMSリクエスト/レスポンス・アプリケーションを構成するには、次の作業を行う必要があります。
選択した1つのJMSサーバーをターゲットとする共通分散キューおよびローカル・キューを作成します。
クラスタにUDQをデプロイし、すべてのJMSに対してメンバー・キューを作成するUDQのデフォルトのターゲット指定を無効にします。
次の表に、JMSベースのビジネス・サービスの構成に使用するプロパティを示します。詳細は、「ビジネス・サービスの作成と構成」を参照してください。
表31-4 ビジネス・サービス用のJMSトランスポート・プロパティ
| プロパティ | 説明 |
|---|---|
宛先タイプ |
JMS宛先タイプとして、次のいずれかを選択します。
|
メッセージ・タイプ |
メッセージ・タイプとして、次のいずれかを選択します。
レスポンスにJavaのメッセージ・タイプを選択した場合、このオプションは無効です。 |
レスポンス・キュー |
レスポンスの処理方法を指定するためのオプションとして、次のいずれかを選択します。
このオプションは、「宛先タイプ」が「キュー」の場合のみ使用できます。 |
レスポンス・パターン |
次のいずれかを選択して、レスポンスの設計パターンを指定します。
このオプションを使用できるのは、「レスポンス・キュー」フィールドでレスポンス・オプションを選択した場合のみです。詳細は、「JMSリクエスト/レスポンスのメッセージIDと相関IDのパターン」を参照してください。 |
ディスパッチ・ポリシー |
このエンドポイントのディスパッチ・ポリシーに使用するWebLogic Serverワーク・マネージャのインスタンスを選択します。デフォルトのワーク・マネージャは、他にワーク・マネージャがない場合に使用されます。 たとえば、ビジネス・サービスがJMS転送プロトコルに対応している場合、ビジネス・サービスのエンドポイントは、そのディスパッチ・ポリシーに関連付けることのできるMDB (メッセージドリブンBean)のJARファイルになります。 ワーク・マネージャの詳細は、次の説明を参照してください。
|
リクエストのエンコーディング |
リクエストのエンコード用の文字セットを入力します。デフォルトは、UTF-8です。 |
レスポンスのエンコーディング |
レスポンスのエンコード用の文字セットを入力します。デフォルトは、UTF-8です。 このオプションを使用できるのは、「レスポンス・キュー」フィールドでレスポンス・オプションの1つを選択した場合のみです。 |
レスポンス・タイムアウト |
レスポンスを待機する時間を秒単位で入力します。この時間が経過すると接続が切断されます。デフォルト値は0で、レスポンスのタイムアウトがありません。 このオプションを使用できるのは、「レスポンス・キュー」フィールドでレスポンス・オプションの1つを選択した場合のみです。 |
クライアントJar |
Javaオブジェクトを含むメッセージのデキューに使用する、クライアントJARを選択します。クライアントJARの選択によって、それがクラスパス上にあることが確認されます。このオプションは、サービスが、Javaレスポンス・タイプのメッセージング・サービスのときに使用できます。 詳細は、「メッセージでのJavaオブジェクトの送信および受信」を参照してください。 |
レスポンスURI |
次に示すいずれかの形式で、レスポンスURIを入力します。このオプションを使用できるのは、「すべてのリクエストURIに対して1つ」レスポンス・オプションと「JMSCorrelationID」レスポンス・パターンを選択した場合のみです。 jms://host:port/connection_factory/jndi_destination 複数のサーバーをターゲットとする場合は、次の形式を使用します。 jms://host1:port,host2:port/connection_factory/jndi_destination レスポンスURIのホストとポートを省略することもできます。次に例を示します。 jms:///connection_factory/jndi_destination ホストとポートを省略すると、ローカル・サーバーで接続ファクトリや宛先ルックアップが発生します。これは、リクエストURIが外部接続ファクトリや宛先を指し、レスポンスをローカル・サーバーに送信する場合などに便利です。 注意: WebLogic Serverでは、JNDI名でmyqueues/myqueueのようにフォワード・スラッシュを使用できますが、フォワード・スラッシュのあるJNDI名は、Service Busに必要とされるURI形式と一致しないため、このような名前は使用できません。この問題を回避するには、JMS外部サーバーを定義してURIでその外部サーバーを参照します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成に関する項を参照してください。 |
レスポンスのリクエスト |
汎用の「トランスポート」ページで入力したリクエストURIごとに、「レスポンスURI」を入力します。前述の「レスポンスURI」フィールドの説明に記載されている形式とガイドラインに従います。 URIごとに、オプションで、リクエスト・キューとレスポンス・キューの両方にサービスで使用するJMS/JNDI資格証明用のサービス・アカウントを選択できます。 このオプションを使用できるのは、「JMSCorrelationID」パターンに対して「リクエストURIごとに1つ」レスポンス・オプションを選択して、レスポンス・フェイルオーバーを提供する場合です。 |
ターゲット - レスポンス |
レスポンスを受信する「対象」サーバーの名前と「レスポンスURI」を、「レスポンスURI」フィールドの説明に従って入力します。 このオプションを使用できるのは、「JMSMessageID」パターンに対して「すべてのリクエストURIに対して1つ」レスポンス・オプションを選択した場合のみです。 |
接続のリクエスト |
リクエストURIごとに、JMS接続ファクトリ名を入力します。この名前は、「順序番号」フィールド。名前を入力しないと、JMSトランスポートではリクエストURIの接続ファクトリが使用されます。 サービスがリクエスト・キューとレスポンス・キューの両方で使用するJMS/JNDI資格証明のためにオプションとしてサービス・アカウントを選択できます。 このオプションを使用できるのは、「JMSMessageID」パターンに対して「リクエストURIごとに1つ」レスポンス・オプションを選択して、レスポンス・フェイルオーバーを提供する場合です。 |
ターゲット - 宛先 |
各ターゲット上のリクエストURIごとにレスポンスを受信する、各ターゲット・サーバー上の宛先キューを入力します。リスト内のターゲット・サーバー(クラスタ内の管理対象サーバーなど、現行ドメインのサーバーによって判別される)ごとに、リクエストURIが「順序番号」(「接続のリクエスト」フィールドの番号に対応)順に表示されます。 このオプションを使用できるのは、「JMSMessageID」パターンに対して「リクエストURIごとに1つ」レスポンス・オプションを選択して、レスポンス・フェイルオーバーを提供する場合です。このフィールドは「接続のリクエスト」フィールドと組み合せて使用します。 注意: Service Bus開発環境では1サーバー環境しかサポートされないため、「対象」は1つしか表示されません。複数サーバー環境でこのフィールドを構成するには、このサービスをランタイム環境にデプロイし、Oracle Service Busコンソールでサービス構成を完了してください。 |
JMSサービス・アカウント |
JMSサーバーによって管理されているJMSリソースに使用するサービス・アカウントを入力します。サービス・アカウントは、リクエストとレスポンスの両方に使用される、ユーザーIDとパスワードの別名リソースです。同じサービス・アカウントが、JMSとJNDIの両方に使用されます。 このオプションを使用できるのは、「レスポンス・キュー」フィールドで「なし」または「すべてのリクエストURIに対して1つ」オプションを使用する場合です。このフィールドは「呼出し元のサブジェクトを渡す」オプションと互いに排他的です。JMS/JNDI認証のためにいずれか1つを使用してください。 詳細は、「サービス・アカウントの操作」を参照してください。 |
SSLを使用 |
リクエストがTLS/SSL接続を通して行われる場合にのみ、このチェック・ボックスを選択します。 TLS/SSL (Secure Sockets Layer)では、ネットワークで接続される2つのアプリケーションが互いのIDを認証し、アプリケーション間で交換されるデータを暗号化できるようにすることによって、安全な接続が可能になります。認証を使用すると、サーバー(および必要に応じてクライアント)はネットワーク接続の相手側アプリケーションのIDを検証できます。また、宛先のJNDIエントリに対してアクセス制御が設定されていることにより、管理者から個々のJMS宛先(キューまたはトピック)へのアクセスが制限されている場合、JNDIツリー内でのルックアップ時に、サービスで認証を行う必要があります。「サービス・アカウント」または「呼出し元のサブジェクトを渡す」オプションを使用して認証します。 注意: JMSトランスポートでは双方向SSLはサポートされません。 |
有効期限 |
メッセージが期限切れになるまでの時間間隔(ミリ秒単位)です。デフォルト値の0を指定すると、メッセージは無期限になります。 |
メッセージ永続性を有効にする |
メッセージ配信を保証するためにはこのチェック・ボックスを選択します。少数のメッセージの紛失が許容される場合は、このチェック・ボックスを選択解除するとスループットが向上します。このJMSメッセージ配信モードを使用すると、信頼性とスループットのバランスを取ることができます。 |
順序単位 |
メッセージ・プロデューサが処理順序に関して複数のメッセージを1つの単位にグループ化できるようになる、メッセージ順序単位を入力します。この順序単位のすべてのメッセージは、メッセージが作成された順序に従って処理する必要があります。 順序単位の使用の詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージ順序単位の使用に関する項を参照してください。 |
呼出し元のサブジェクトを渡す |
Service Busがメッセージを送信するときに、認証されたサブジェクトを渡すには、このチェック・ボックスを選択します。 このフィールドを有効にしたときに、ビジネス・サービスの対象が別のドメインのJMSリソースである場合は、両方のドメインのグローバル信頼を有効にします。『Oracle WebLogic Serverセキュリティの管理』のWebLogicドメインのセキュリティの構成に関する項を参照してください。 このフィールドは「サービス・アカウント」オプションと互いに排他的です。JMS/JNDI認証のためにいずれか1つを使用してください。 |
JNDIタイムアウト |
JNDIツリーで宛先ファクトリまたは接続ファクトリを検索する際に、JNDI接続がタイムアウトするまでの時間(秒単位)を入力します。 デフォルト値0では接続のタイムアウトは行われません。 |
