JMSアーキテクチャでは、多数のメッセージ・サーバーに対して1つのクライアント・インタフェースが使用されます。JMSモデルには、Point-to-Pointおよびパブリッシュ・サブスクライブという2つのメッセージ・ドメインがあります。Point-to-Pointドメインでは、メッセージはキューを介して交換され、各メッセージは1人の受信者にのみ配信されます。パブリッシュ・サブスクライブ・モデルでは、メッセージはトピックに送信され、複数のサブスクライブ・クライアントによって読み取られます。
JCA 1.5リソース・アダプタとBPEL Process Managerを双方向で統合するために、JCAバインディング・コンポーネントが使用されています。JCAバインディング・コンポーネントは規格に準拠しており、基盤となるJCA相互作用をWebサービスとして公開するためのWeb Service Invocation Framework (WSIF)テクノロジが使用されています。
Oracle JMSアダプタのアーキテクチャ、アダプタとOracle BPEL Process Manager (Oracle BPEL PM)の統合およびアダプタのデプロイの詳細は、アダプタとOracle Application Serverコンポーネントの統合を参照してください。
Oracle Mediator (メディエータ)はOracle JCAアダプタをサポートしており、それぞれのインバウンドおよびアウトバウンドのアダプタ・サービスを定義できます。インバウンド・アダプタ・サービスでは、外部メッセージ・システムからデータが受信されてXMLメッセージに変換されます。アウトバウンド・アダプタ・サービスでは、XMLメッセージが特定のアダプタのネイティブ・フォーマットに変換され、データがターゲット・アプリケーションに送信されます。
Oracle JMSアダプタ・サービスの場合、メディエータを使用してJMSキューまたはトピックからのメッセージを送受信できます。
メディエータはOracle BPEL PMの後継であり、このガイドのほとんどの部分およびサンプルはOracle BPEL PMを使用することを想定しています。ただし、アダプタの動作はOracle BPEL PMでもメディエータでも同じです。この章でOracle BPEL PMに言及している箇所は、メディエータで置き換えてかまいません。
Oracle JMSアダプタには次の特徴があります。
JMSバージョン1.0.2bがベース
汎用Oracle JMSアダプタ
任意のJMSプロバイダで機能します。ただし、Oracle JMSアダプタの場合、AQ JMS (JMSプロバイダOJMS 8.1.7、9.0.1.4および9.2)、TIBCO JMS、IBM WebSphere MQSeries (IBM MQSeries JMS 6.0)、Weblogic JMS、ApacheおよびActive MQで動作確認されています。その他のプロバイダの動作保証についての追加情報は、Oracleサポートに問い合せてください。
JMSトピックおよびキューをサポートしています。
バイト、テキストおよびマップ・メッセージ・タイプをサポートしています。
これらのデータ・タイプは、このリリースでのみサポートされています。アダプタ構成ウィザードにより、実行時のネイティブ・データ・ペイロードの消費にネイティブ・フォーマット・ビルダー・ウィザードが提供されます。ネイティブ・フォーマット・ビルダー・ウィザードでは、基礎となるネイティブ・データのXSD定義が作成されます。
JMSヘッダーおよびプロパティをサポートしています。
WebLogic Serverの順序単位機能をサポートしています。
WebLogic Serverの順序単位機能では、JMSメッセージ・プロデューサや単体として動作するメッセージ・プロデューサのグループが、複数のメッセージを1つの単位にグループ化してメッセージを作成順に処理することが可能になります。単一のメッセージのメッセージ処理は、メッセージが確認応答、コミット、回復またはロールバックされたときに完了します。メッセージのメッセージ処理が完了するまでは、その順序単位の残りの未処理メッセージがブロックされます。
この拡張により、SOA JMSアダプタでWebLogic Serverの順序単位サポートが有効化されます。SOA JMSアダプタを介して生成されたメッセージによって、ユーザーは特定の順序単位を指定できるようになります。
jca.message.encodingプロパティをサポートしています。
Oracle JMSアダプタでは、インバウンド・ペイロードとアウトバウンド・ペイロードのjca.message.encoding
プロパティがサポートされます。jca.message.encoding
プロパティがadapter.jms.encoding
プロパティおよびnxsd:encoding
属性とともに使用される場合、jca.message.encoding
プロパティはadapter.jms.encoding
プロパティよりも優先され、nxsd:encoding
属性の優先度は最も低くなります。nxsd:encoding
値にはUTF-8が指定可能で、通常は相互運用性とUnicodeサポートのためにこれをお薦めします。ただし、Java Runtime Environmentでサポートされている任意の有効なエンコーディングを指定できます。サポートされているエンコーディングの完全なリストは、http://docs.oracle.com/javase/7/docs/technotes/guides/intl/encoding.doc.html
を参照してください。エンコーディングは、アダプタ・プロキシ・メタデータに関連付けられた(N)XSDで指定できます。たとえば、nxsd:encoding="iso-8859-1"
のように属性を指定できます。
jca.message.encoding
プロパティは、composite.xml
で定義されたエンドポイントとしてサポートされています。このプロパティは、アダプタ構成ウィザードの「プロパティ」タブを使用するか、composite.xml
ファイルを編集して定義できます。jca.message.encoding
プロパティは、インバウンド相互作用とアウトバウンド相互作用の両方で正規化されたメッセージ・プロパティとして渡すことができます。
次のコード・スニペットは、インバウンド・サービスに関するメッセージ・エンコーディングについてcomposite.xmlファイルに値を設定する一例です。
<service name="jms_inbound" ui:wsdlLocation="jms_inbound.wsdl"> <interface.wsdl interface="http://xmlns.oracle.com/pcbpel/adapter /jms/utf8/jcamessageencoding/ jms_inbound#wsdl.interface(Consume_Message_ptt)"/> <binding.jca config="jms_inbound_jms.jca"> <property name="jca.message.encoding" type="xs:string" many="false" override="may">GBK</property> </binding.jca> </service>
次のコード・スニペットは、アウトバウンド・サービスに関するメッセージ・エンコーディングについてcomposite.xmlファイルに値を設定する一例です。
<reference name="jms_outbound" ui:wsdlLocation= “jms_outbound.wsdl"> <interface.wsdl interface="http://xmlns.oracle.com/pcbpel/adapter/jms/utf8/jcamessageencoding/ jms_outbound#wsdl.interface(Produce_Message_ptt)"/> <binding.jca config="jms_outbound_jms.jca"> <property name="jca.message.encoding" type="xs:string" many="false" override="may">GBK</property> </binding.jca> </reference>
JMSメッセージ・セレクタのサポート
JMSトピックおよびキューへのサブスクライブ中のフィルタ処理の実行用にJMSメッセージ・セレクタをサポートしています。このパラメータは、JMSヘッダーおよびプロパティのセクションに存在するフィールドに基づくメッセージをフィルタ処理するためのSQL 92言語に基づいています。
DOM2準拠
Oracle JMSアダプタでは、DOM2仕様に準拠するドキュメント・オブジェクトを処理および生成できます。
正規化されたメッセージのサポート。
ヘッダーの操作と伝播は、重要なビジネス統合メッセージング要件です。Oracle BPEL PM、メディエータ、Oracle JCAおよびOracle B2Bでは、顧客の統合要件を解決する場合にヘッダー・サポートに広範に依存しています。たとえば、メッセージ・ヘッダーを介して伝播させることで、ファイル名をソース・ディレクトリからターゲット・ディレクトリに保存できます。また、アウトバウンドOracle JMSアダプタでは、correlationId
およびJMSReplyTo
のアドレスをJMSヘッダーとして伝播することで、非同期リクエスト/レスポンスが容易になります。Oracle BPEL Process ManagerとMediatorでは、様々なUIサポート・レベルでヘッダーにアクセスし、操作して設定できます。
詳細は、「アダプタ内での相関サポート」を参照してください。
正規化されたメッセージのヘッダーの伝播
正規化されたメッセージは、プロパティとペイロードという2つの部分のみを持つように簡素化されています。通常、プロパティはスカラー型の名前/値ペアです。既存の複雑なヘッダーがプロパティに収まるように、プロパティはスカラー型にフラット化されます。
設計時のヘッダーの操作
複雑なプロパティは事前に決定されているため、設計時にヘッダーを操作する際のユーザー操作は合理化されています。メディエータまたはOracle BPELデザイナでは、なんらかの予約済キーワードを使用してヘッダーを操作できます。たとえば、現在、メディエータ・デザイナでは、次の式を使用してインバウンドOracleファイル・アダプタのfileName
ヘッダーにアクセスできます。
$nmproperty.InboundFileHeaderType.fileName
ただし、この方法はユーザー入力に基づいて動的に生成されるプロパティに対処していません。たとえば、Oracle AQアダプタ・ウィザードでは、AQオブジェクトからの一部のフィールドをヘッダーとして伝播できます。この選択内容に基づいてヘッダー定義が生成されます。これらの定義はあらかじめ決まらないため、あらかじめ決められたプロパティ定義のリストでは対応できません。動的プロパティのヘッダー操作は、定義するまで設計できません。この制限に対応するには、必要なすべてのサービス(コンポジット・エントリ・ポイント)と参照を生成する必要があります。この制限は、動的プロパティを生成する必要のあるサービスにのみ適用されます。動的プロパティが生成された後、コンポジットごとに特定の場所で取得される必要があります。その後にのみ、Oracle MediatorまたはOracle BPELデザイナで動的プロパティを操作できます。
永続JMSサブスクライバの指定をサポートしています。
JMSパブリッシャの永続および非永続モードをサポートしています。
SolarisでのAQJMSに対するアウトバウンド再試行機能はサポート対象外
注意:
Oracle JMSアダプタを使用してAQ-JMSプロバイダに接続する際に、AQの宛先をホストするデータベースが10.1.0.4の場合、データベース・サーバーが停止すると、アウトバウンド方向のアダプタ再試行メカニズムはデータベース・サーバーへの再接続に失敗します。これは、クライアントJDBCとojdbc14.jar
との問題によるものです。これを解決するには、10.1.0.4のJDBCドライバをダウンロードし、$MIDTIER_ORACLE_HOME/jdbc
にあるライブラリ(特にojdbc14.jar)を置き換えて、中間層で使用する必要があります。この問題の解決方法の詳細は、MetaLink Note 317385.1を参照してください。
JMS APIでは、JMSパブリッシャによって送信される3つの確認情報を指定します。
DUPS_OK_ACKNOWLEDGE
: メッセージの重複に関連のないコンシューマ用
AUTO_ACKNOWLEDGE
: セッションがメッセージの受信を自動的に確認
CLIENT_ACKNOWLEDGE
: クライアントがメッセージの確認メソッドを呼び出してメッセージを確認
メッセージ・サイズの追跡のサポート
Oracle JMSアダプタはメッセージ・サイズ対応です。Oracle JMSアダプタではメッセージ・サイズが計算され、JCAバインディング・コンポーネントにレポートされます。JCAバインディング・コンポーネントにより公開されるサイズ関連APIは、レポート処理に使用できます。
JMSアダプタのMapMessageデータ型でのMapMessageサポートの構成
MapMessage
は、名前/値ペアを送信するために使用されます。名前は文字列で、値はJavaプリミティブ型です。このエントリには、名前を指定して順次的またはランダムにアクセスできます。エントリの順序は定義されません。これはメッセージから継承し、マップ・メッセージ本文を追加します。
Oracle JMSアダプタでは、MapMessage
の処理がサポートされます。現在では、JmsMapMessageConsumeActivationSpec
およびJmsMapMessageProduceInteractionSpec
という新しいActivationSpecおよびInteractionSpecプロパティがサポートされています。
次の使用例がサポートされています。
使用例1。
JMS MapMessageオブジェクト全体がペイロードとして処理されます。
PayloadEntryプロパティとAttachmentListプロパティが両方とも定義されていない場合は、JMS MapMessage全体がXMLに変換され、そのXMLファイルがペイロードとして転送されます。この使用例の場合、PayloadEntry
プロパティとAttachmentList
プロパティは両方ともオプションです。変換には、次のスキーマが使用されます。
<schema targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/jms/MapMessage" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/jms/MapMessage" elementFormDefault="qualified"> <element name="MapMessage"> <complexType> <choice maxOccurs="unbounded"> <element name="entry"> <complexType> <simpleContent> <extension base="string"> <attribute name="name" type="string"/> <attribute name="dt" type="string"/> </extension> </simpleContent> </complexType> </element> </choice> </complexType> </element> </schema>
属性name
は、JMS MapMessageエントリの名前/値ペアの名前部分です。
属性dt
には、次のいずれか1つの文字列値を指定できます。
Boolean
Byte
Short
Integer
Long
Float
Double
文字列
Char
ByteArray
使用例2。MapMessageエントリ(名前/値ペア)がペイロードとして処理されます。
PayloadEntry
プロパティでは、ペイロードとして使用されるJMS MapMessageエントリ名(処理される必要がある名前/値ペアを参照)を指定します。PayloadEntry
ではなくAttachmentList
プロパティが定義されている場合は、ペイロードを添付として送信することもできます。この使用例の場合、PayloadEntry
プロパティまたはAttachmentList
プロパティのいずれかを指定する必要がありますが、両方は指定しないでください。
他のすべてのMapMessageエントリは、jca.jms.Map.xxxx
により識別されるアダプタ・プロパティに変換されます。xxxx
は、JMS MapMessageエントリの名前です(名前/値ペア)。
JMS MapMessageサンプルは、「開発者および管理者のサンプル・コード」ページから「ミドルウェアおよびツール」の下にある最新のSOAサンプル・コードにアクセスして、次のサンプルを参照します: adapters-jms-104-wlsjms-mapmessage。
エンタープライズ情報システム(EIS)の資格証明のサポート
Oracle JMSアダプタでは、EISとのアウトバウンド接続の確立時の、エンタープライズ情報システム(EIS)の資格証明(ユーザー名やパスワードなど)の保護がサポートされています。Oracle JMSアダプタのユーザー名とパスワードは、Oracle WebLogic Serverのコンテナ管理のサインオンを使用して保護できます。
エンタープライズ情報システム(EIS)の資格証明の保護のサポートの詳細は、「エンタープライズ情報システムの資格証明の保護」を参照してください。
大きなペイロードのストリーミングのサポート
Oracle JMSアダプタには、ストリーム・ペイロードのサポートが用意されています。この機能を有効化すると、ペイロードはメモリーDOM内のSOAランタイムで操作されるかわりにデータベースにストリーミングされます。この機能は、大きなペイロードの処理中に使用できます。ストリーム・ペイロードのサポートを有効化するには、Oracle JDeveloperの「消費操作のパラメータ」ページで消費操作のパラメータを定義する際に必ず「ストリーミングの有効化」チェック・ボックスを選択します。「ストリーミングの有効化」チェック・ボックスを選択すると、次の例に示すように、対応するブール・プロパティEnableStreaming
がそれぞれの.jca
ファイルに定義されているActivationSpec
プロパティに追加されます。EnableStreaming
プロパティが存在しない場合は、デフォルト値のfalseとみなされます。
<activation-spec className="oracle.tip.adapter.jms.inbound. JmsConsumeActivationSpec"> <property name="DestinationName" value="jms/DemoInQueue"/> <property name="UseMessageListener" value="false"/> <property name="PayloadType" value="TextMessage"/> <property name="EnableStreaming" value="true"/> </activation-spec>
トランザクションのサポート
送信または受信されたメッセージを1つの単位として扱うことで、アプリケーションは、1つのトランザクションで発行および消費のメッセージのグループを調整できます。アプリケーションがトランザクションをコミットすると、そのトランザクション内で受信したすべてのメッセージが、JMSプロバイダにより削除されます。そのトランザクション内で送信したメッセージは、1つの単位としてすべてのJMSコンシューマに配信されます。アプリケーションがトランザクションをロールバックすると、そのトランザクション内で受信したメッセージはメッセージ・システムに戻され、送信したメッセージは破棄されます。Oracle JMSアダプタはJMSトランザクションをサポートします。JMSで処理されたセッションは、そのセッション内に配置されたトランザクションをサポートします。JMSで処理されたセッションのトランザクションは、そのセッション以外には影響しません。
エラー処理のサポート
エラー処理については、「エラー処理」を参照してください。
複数のコンシューマ・スレッドのサポート
Oracle JMSアダプタは、アクティブ化エンドポイント・プロパティadapter.jms.receive.threads
をサポートしています。アダプタとエンタープライズ情報システム(EIS)間のインバウンド・メッセージ・フロー用として複数のポーラー・スレッドを生成するには、composite.xmlでこのプロパティを設定することをお薦めします。これにより、複数のポーラー・スレッドがラウンド・ロビン形式でメッセージをデキューするため、パフォーマンスが向上します。これは、分散シナリオでもサポートされています。
注意:
レジリエンシが有効であり、Oracle Event Delivery Network (EDN)サブスクライバが静止モードである場合、EDNコンシューマ・スレッドはスリープ・モードになります。構成されたMaxStuckThreadTime
が経過すると、たとえばMaxStuckThreadTime = 600
(秒)といった構成に基づき、スリープ状態のEDNコンシューマ・スレッドがSTUCKとマークされます。サーバー・ログのこれらのSTUCKロギング文は一時的な警告であり、機能に影響しません。静止モードが終了し、レジリエンシが受信リクエスト処理を再開した後、これらのSTUCK警告はなくなり、通常の処理が再開されます。
SOA_Request_WMおよびSOA_EDN_WMも同じ最大制約を共有します。EDNサブスクライバのスレッド数が最大制約よりも大きい場合、SOA_Request_WMのパフォーマンスは影響を受けます。回避策は、EDNサブスクライバのスレッド数を削減するか、またはSOAIncomingRequests_maxThreadsで定義された最大制約を増加します
パフォーマンス・チューニングのサポート
Oracle JMSアダプタはパフォーマンス・チューニングをサポートしています。詳細は、「Oracle JCAアダプタ・チューニング・ガイド」および「Oracle JCAアダプタのプロパティ」を参照してください。
注意:
Oracle JMSアダプタをEJBまたはJMSクライアントのプログラムで使用することはできません。
メッセージ機能はプログラム間の通信を可能にするメカニズムです。メッセージは、あるアプリケーションが別のアプリケーションに送信する構造化データです。メッセージ指向ミドルウェア(MOM)は、スケーラブルなエンタープライズ・メッセージング機能をサポートするインフラストラクチャです。MOMにより、高速で信頼できる非同期の通信、保証付きメッセージ配信、受信通知およびトランザクション制御が実現されます。
JMSは、エンタープライズ・メッセージング・システムのメッセージの発行、送信および受信を目的として開発されたSun Javaインタフェースです。JMSはJMSベンダーが実装するAPIです。オラクル社では、WLS JMSとOracleアドバンスト・キューに基づいたOracle JMSの2つのJMS実装を提供しています。JMSプロデューサによりJMSメッセージが作成され、JMSコンシューマによってJMSメッセージが消費されます。
JMSでは、Point-to-Point(キュー)およびパブリッシュ・サブスクライブ(トピック)という2つのメッセージ・パラダイムをサポートしています。
Point-to-Pointメッセージでは、メッセージは消費されるまでキューに格納されます。1つ以上のプロデューサがキューに書き込み、1つ以上のコンシューマがキューからメッセージを抽出します。JMSコンシューマにより、メッセージの消費後に確認情報が送信されるため、キューからメッセージがパージされます。
パブリッシュ・サブスクライブ・メッセージでは、プロデューサがメッセージをトピックにパブリッシュし、コンシューマが特定のトピックにサブスクライブします。複数のパブリッシャが同じトピックを公開でき、複数のコンシューマが同じトピックにサブスクライブできます。プロデューサによってトピックに公開されたすべてのメッセージは、そのトピックにサブスクライブしたすべてのコンシューマによって受信されます。デフォルトでは、サブスクライバがメッセージを受信できるのはアクティブなときのみです。ただし、JMS APIでは、サブスクライバが稼働中ではなくても、パブリッシュされたメッセージをコンシューマが受信できる永続サブスクリプションをサポートしています。永続サブスクリプションでは、コンシューマがアクティブではないときに送信されたメッセージを受信するために、コンシューマを一意のIDで登録します。これらのメッセージはJMSプロバイダにより保存され、コンシューマが再度アクティブになった際に送信されるか、メッセージが失効した場合には記憶域からパージされます。JMSプロデューサは、永続モードまたは非永続モードに設定できます。非永続モードではメッセージは保存されず、非永続サブスクリプションにのみ使用できます。
Oracle WebLogic Serverで永続サブスクリプションの操作を必要とするシナリオでは、次の例に示すように、ClientID
プロパティを定義済のコネクタ・ファクトリが必要です。
<FactoryProperties>ClientID=uniquename</FactoryProperties>
複数の永続サブスクライバを定義する際には、それぞれ一意のClientID
プロパティを指定して複数のコネクタ・ファクトリを定義する必要があります。Oracle WebLogic Serverではclientid
のバインドが1回しか許可されないため、他のアダプタ相互作用(インバウンド・メッセージの処理に使用する場合のアウトバウンド相互作用など)には同じコネクタ・ファクトリを使用しないように注意してください。ClientId
を定義済のコネクタ・ファクトリをインバウンドで使用して着信メッセージを処理するシナリオの場合、アウトバウンド・アダプタ相互作用には異なるコネクタ・ファクトリを使用する必要があります。
注意:
BPELパートナ・リンクで使用されない永続サブスクライバは、手動で削除する必要があります。これらの永続サブスクリプションがOracle JMSアダプタにより自動的に削除されることはありません。
JMS APIでは、メッセージ消費のための同期および非同期通信の両方をサポートしています。同期の場合、コンシューマはトピックまたはキューのreceive()
メソッドを明示的に呼び出します。非同期の場合、JMSクライアントによりトピックまたはキューにメッセージ・リスナーが登録され、メッセージはそのリスナーのonMessage()
メソッドを呼び出すことで配信されます。
宛先プロパティには、JMSキューまたはトピックのアドレス情報が含まれます。接続は、JMSプロバイダへの物理接続を表します。コネクション・ファクトリは、JMS接続の作成に使用されます。セッションは、キューまたはトピックの宛先、JMSプロデューサ、およびJMSコンシューマのオブジェクトの作成に使用されます。
JMSメッセージには、必須の標準ヘッダー要素、オプションのプロパティ要素およびオプションの標準ペイロード要素があります。ペイロードはテキスト・メッセージ、バイト・メッセージ、マップ・メッセージ、ストリーム・メッセージまたはオブジェクト・メッセージのいずれかになります。プロパティ要素はJMSプロバイダ固有で、JMSプロバイダごとに異なります。
JMSアダプタは、TIBCO、IBM MQ Seriesおよびその他の動作保証されているサード・パーティ・サービス・プロバイダと通信できます。これらのサービス・プロバイダが停止した後に再起動した場合、JMSアダプタは、これらのサービス・プロバイダに正常に接続し、保留中のメッセージを処理できます。
適切に接続されるようにするには、次の手順を実行します。
SOAおよびWebLogicコンソールの起動スクリプトであるsetDomainEnv.sh
で、次を設定します。
-Dweblogic.transaction.blocking.commit=false
and
-Dweblogic.transaction.blocking.rollback=false
WebLogicコンソールで、-->「domain」--- >「JTA」----- >「詳細」---->「CompletionTimeoutSeconds」に進み、CompletionTimeoutSeconds
を0に設定します。
プロパティ
adapter.jms.DistributedDestinationConnectionEveryMemberは、JMSアダプタのサービスのバインディング・プロパティとして使用可能です。
このプロパティには、ブール値[true | false]を使用できます。デフォルト値はtrueです。
trueの場合、JMSアダプタでは、分散宛先の各メンバーのコンシューマ/サブスクライバが作成されます。falseに設定すると、JMSアダプタでは、分散宛先のローカル・メンバーのみのコンシューマ/サブスクライバが作成されます。JMSアダプタがリモート・クラスタまたはリモート・ドメインのサーバーの分散宛先に接続されている場合、プロパティ
adapter.jms.DistributedDestinationConnectionEveryMemberを常にtrueに設定する必要があります。JMSアダプタがローカル・クラスタの分散宛先に接続している場合、このプロパティはtrueまたはfalseに設定できます。trueに設定すると、JMSアダプタは以前と同じままとなります(つまり、分散宛先ごとにコンシューマが作成されます)。falseに設定すると、JMSアダプタでは、ローカル・メンバーのコンシューマ/サブスクライバのみが作成されます。
JDeveloperのユーザー・インタフェースでは、このプロパティがサービス側のバインディング・プロパティとして表示されません。このため、次に示すように、<service>/<binding.jca>
タグの下にこのプロパティを手動で追加する必要があります。
<property name="adapter.jms.DistributedDestinationConnectionEveryMember" type="xs:string" many="false" override="may">false</property>
この項では、次に示すOracle JMSアダプタの使用例について述べています。
次の使用例では、Oracle JMSアダプタの構成手順を説明し、結果のWSDLファイルおよび関連するweblogic-ra.xml
ファイルを検証します。
この項には次のトピックが含まれます:
最初に、SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。次の手順に従って新規アプリケーションとSOAプロジェクトを作成します。
アダプタ構成ウィザードにより次のコンポジット・ファイルが生成されます。
<composite name="AQQueue2Queue"revision="1.0" label="2007-09-04_11-58-50_914"mode="active"state="on" xmlns="http://xmlns.oracle.com/sca/1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:orawsp="http://schemas.oracle.com /ws/2006/01/policy"> <import namespace="http://xmlns.oracle.com/pcbpel/adapter /jms/Inbound/"location="Inbound.wsdl" importType="wsdl"/> <import namespace="http://xmlns.oracle.com/pcbpel/ adapter/jms/Outbound/"location="Outbound.wsdl" importType="wsdl"/> <service name="Inbound"> <interface.wsdl interface="http://xmlns.oracle.com/pcbpel/ adapter/jms/Inbound/#wsdl.interface (Consume_Message_ptt)"/> <binding.jca config="Inbound_jms.jca"/> </service> <component name="BPELProcess1"> <implementation.bpel src="BPELProcess1.bpel"/> </component> <reference name="Outbound"> <interface.wsdl interface= "http://xmlns.oracle.com/pcbpel/adapter /jms/Outbound/#wsdl.interface (Produce_Message_ptt)"/> <binding.jca config="Outbound_jms.jca"/> </reference> <wire> <source.uri>Inbound</source.uri> <target.uri>BPELProcess1/Inbound</target.uri> </wire> <wire> <source.uri>BPELProcess1/Outbound</source.uri> <target.uri>Outbound</target.uri> </wire> </composite>
次のコード・セグメントでは、アダプタの名前、様々な必要なスキーマの場所およびその他の定義ファイルが定義されています。
<import namespace="http://xmlns.oracle.com/pcbpel /adapter/jms/Inbound/"location="Inbound.wsdl" importType="wsdl"/> <import namespace="http://xmlns.oracle.com /pcbpel/adapter/jms/Outbound/"location= "Outbound.wsdl" importType="wsdl"/>
このコード・セグメントでは必要なネームスペースをインポートしています。
<definitions name="Inbound" targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/jms/Inbound/" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/jms/Inbound/" xmlns:plt="http://schemas.xmlsoap.org/ws/2003/05/partner-link/" xmlns:imp1="http://xmlns.oracle.com/pcbpel/samples/expense"> <types> <schema xmlns="http://www.w3.org/2001/XMLSchema"> <import namespace="http://xmlns.oracle.com/pcbpel/samples/expense" schemaLocation="xsd/expense.xsd"/> </schema> </types> <message name="ExpenseRecord_msg"> <part name="ExpenseRecord" element="imp1:ExpenseRecord"/> </message> <portType name="Consume_Message_ptt"> <operation name="Consume_Message"> <input message="tns:ExpenseRecord_msg"/> </operation> </portType>
このコード・セグメントでは、メッセージ・タイプ、メッセージ名およびパートナ・リンクのポート・タイプが定義されています。
<adapter-config name="dequeue" adapter="Jms Adapter xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata"> <connection-factory location="eis/wls/Queue" UIConnectionName="wls3" UIJmsProvider="WLSJMS" adapterRef=""/> <endpoint-activation portType="Consume_Message_ptt" operation="Consume_ Message"> <activation-spec className="oracle.tip.adapter.jms.inbound.JmsConsumeActivationSpec"> <property name="DestinationName" value="jms/DemoInQueue"/> <property name="UseMessageListener" value="false"/> <property name="PayloadType" value="TextMessage"/> </activation-spec> </endpoint-activation> </adapter-config>
weblogic-ra.xml
ファイルでは、JMSコネクション・ファクトリのエンドポイントが定義されます。コネクション・ファクトリには、各エンドポイントの構成プロパティが含まれます。後続の項で示すように、エンドポイントは、タイプの異なる接続に対応するために追加されます。次の例に、汎用weblogic-ra.xml
ファイルの内容を示します。
<connection-instance> <jndi-name>eis/wls/Queue</jndi-name> <connection-properties> <properties> <property> <name>ConnectionFactoryLocation</name> <value>weblogic.jms.XAConnectionFactory</value> </property> <property> <name>FactoryProperties</name> <value></value> </property> <property> <name>AcknowledgeMode</name> <value>AUTO_ACKNOWLEDGE</value> </property> <property> <name>IsTopic</name> <value>false</value> </property> <property> <name>IsTransacted</name> <value>false</value> </property> <property> <name>Username</name> <value></value> </property> <property> <name>Password</name> <value></value> </property> </properties> </connection-properties> </connection-instance>
新規接続は、Oracle WebLogic Server管理コンソールを使用して作成する方法もあります。次の手順に従って、Oracle WebLogic Server管理コンソールで新規接続を作成します。
weblogic-ra.xml
ファイルでFactoryPropertiesパラメータに値を指定することで、アダプタで非Web Logic Server JMSおよび非AQJMSの接続インスタンスにサード・パーティのJMSプロバイダを使用することを指定できます。具体的には、ThirdPartyJMSProvider
値をFactoryPropertiesパラメータに指定できます。このプロパティは、WebLogic Serverにアダプタをデプロイする場合にのみ必要です。
この値をtrueに設定した場合、JMSアダプタではJMSメッセージを処理するコンシューマの作成にDestinationAvailabilityListener
を使用しません。デフォルトはfalseです。次のスニペットのようなコードを使用する必要があります。
<property> <name>FactoryProperties</name> <value>ThirdPartyJMSProvider=true</value> </property>
注意:
WebLogic Serverに事前に移入されているすべての接続インスタンスは変更を反映するため、それらのインスタンスに対してそれ以上チューニングは不要です。新規の非WLS JMSまたは非AQJMSプロバイダ・アクセスが必要な場合にのみ、新規接続インスタンスを追加する必要があるため、ThirdPartyJMSProvider
プロパティが必要です。
メッセージ発行操作では、特に「アダプタ構成ウィザードを使用した構成」のステップ13において、定義の手順が異なります。消費操作パラメータを指定するかわりに、次の発行操作パラメータを指定します。これにより、JMS宛先へのアウトバウンド・メッセージをアダプタで発行(送信)できます。図8-13に、「発行操作のパラメータ」ページを示します。
宛先名:
メッセージの配信先にする必要のあるJMSキューまたはトピックのJNDI名。入力する名前は、使用するJMSプロバイダのタイプに基づきます。
接続先名の詳細は、次の項を参照してください。
メッセージ本文のタイプ:
サポートされている値は、TextMessage
、BytesMessage
およびMapMessage
です。このリリースでは、StreamMessage
メッセージ・タイプはサポートされていません。
配信モード:
値は「永続」
または「非永続」
です。永続配信モードでは、今後の使用に備えて、永続サブスクライバによりメッセージを保存するパブリッシャである永続JMSパブリッシャを指定します。永続サブスクライバは、「アダプタ構成ウィザードを使用した構成」のステップ15の対応するフィールドに永続サブスクライバIDのあるメッセージ消費です。非永続サブスクライバでは、アダプタがアクティブではないときに発行されたメッセージは失われます。永続サブスクライバでは、永続パブリッシャに保存されていたメッセージをダウンロードするため、すべてのメッセージを受信するために常にアクティブである必要はありません。
優先度:
優先度の値を選択します。9
は最も高い優先度を、0
は最も低い優先度を表します。デフォルトは4
です。
TimeToLive:
メッセージが失効して消費できなくなるまでの期間です。
順序単位
このパラメータは、選択されたJMSプロバイダがWebLogic Server JMSプロバイダの場合にのみ適用されます。これにより、メッセージ・プロデューサや単体として動作するメッセージ・プロデューサのグループが、複数のメッセージを1つの単位にグループ化してメッセージを作成順に処理することが可能になります。単一のメッセージのメッセージ処理は、メッセージが確認応答、コミット、回復またはロールバックされたときに完了します。メッセージのメッセージ処理が完了するまでは、その順序単位の残りの未処理メッセージがブロックされます。このUnit of order
プロパティにより、メッセージの作成時にMessageProducerの順序単位値を設定できます。『Oracle WebLogic Server JMSアプリケーションの開発』で、使用事例「JMSアダプタでのWLS JMS順序単位の使用」および「メッセージ順序単位の使用」を参照してください。
JNDI名
このフィールドでは、JMS接続のJNDI名を指定できます。JMSアダプタのデプロイ済インスタンスのデプロイメント・ディスクリプタは、JMSアダプタが実行時にJNDI宛先にアクセスするために必要な一連の構成プロパティとともにこのJNDI名に関連付けられている必要があります。
この項では、直接接続と非直接接続用にTibco JMSを使用するOracle JMSアダプタの構成方法について説明します。
注意:
各サブセクションにすべての情報が記載されているわけではないため、構成を変更する前にこの項全体をお読みください。TIBCO Enterprise Message Serviceに関連する情報は、TIBCO Enterprise Message Serviceユーザー・ガイド、ソフトウェア・リリース6.3(2012年2月)に基づいています。最新の更新は、TIBCOのドキュメントを参照してください。
また、次の説明のEMS_HOME
は、Tibco Enterprise Message Serviceのインストール・ディレクトリを表しています。
TIBCO Enterprise Message Service管理ツールを使用して、コネクション・ファクトリおよびキュー/トピックを作成します。
通常、事前構成済のコネクション・ファクトリが推奨されるメカニズムですが、Tibcoは、動的に作成されたコネクション・ファクトリのサポートも提供しています。これらを使用するには、次の手順を実行します。
SSL接続に事前構成済のTibcoコネクション・ファクトリを使用できます。これを行うには、SSLをサポートするようにTibcoサーバーを構成する必要があります。
この項では、非XAおよびXAデータソース用にIBM WebSphere MQ JMSを使用するOracle JMSアダプタの構成方法について説明します。
次の手順を実行します。
IBM WebSphere MQ JMSに接続し、マルチインスタンス・キュー・マネージャを使用するようにJMSアダプタを構成できます。
これを行うには、カスタム・プロパティconnectionNameList
を使用します。このプロパティを使用して、様々なインスタンスの名前とポートを指定できます。
QueueManager=QM1;TransportType=1; ConnectionNameList=slj01aml.us.domain.com(141 4),acb113114.us.domain.com(1414); Channel=SYSTEM.DEF.SVRCONN;ThirdPartyJMSProv ider=true;ClientReconnectOptions=0
この項では、Active MQ JMSを使用するOracle JMSアダプタの構成方法について説明します(非XAのみ)。
次の手順を実行します: 次のファイルを<SOAInstall_DIR>/user_projects/domains/<DOMAIN_NAME>/lib
フォルダにコピーします。
/<YOUR-ACTIVEMQ-INSTALL-LOCATION>//activemq-all-5.8.0.jar
次の例に示すように、AS11gR1SOA/soa/connectors/JmsAdapter.rar
にある weblogic-ra.xml
ファイルを変更してコネクタ・ファクトリを構成します。
<connection-instance> <jndi-name>eis/activemq/Queue</jndi-name> <connection-properties> <properties> <property> <name>ConnectionFactoryLocation</name> <value>org.apache.activemq. ActiveMQConnectionFactory</value> </property> <property> <name>FactoryProperties</name> <value>BrokerURL=tcp://<YOUR-HOST>: <YOUR-PORT>;ThirdPartyJMSProvider=true</value> </property> <property> <name>AcknowledgeMode</name> <value>AUTO_ACKNOWLEDGE</value> </property> <property> <name>IsTopic</name> <value>false</value> </property> <property> <name>IsTransacted</name> <value>true</value> </property> <property> <name>Username</name> <value></value> </property> <property> <name>Password</name> <value></value> </property> </properties> </connection-properties> </connection-instance>
または、Oracle WebLogic Server管理コンソールを使用して新規コネクション・ファクトリを構成するには、「アダプタ・コネクション・ファクトリの追加」で説明する手順に従います。
ActiveMQ Series v5.8の場合、XAサポートがあり、XA用に構成されるコネクション・ファクトリは、org.apache.activemq.ActiveMQXAConnectionFactory
です。これはJMSアダプタの現在のリリースで動作確認済です。
Oracle BPEL PMのこのWebLogic Server JMSテキスト・メッセージの使用例では、Oracle JMSアダプタでWebLogic Server JMSキューとの間のエンキューおよびデキューを実行する方法について説明します。
メディエータ・ビジネス・プロセスのWLS JMSテキスト・メッセージ・シナリオの場合、adapters-jms-101-wlsjms-textmessageusingqueues
サンプルに含まれているartifacts.zip
ファイルの次のファイルが必要です。
artifacts/schemas/expense.xsd
adapters-jms-101-wlsjms-textmessageusingqueues
サンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。
この項には次のトピックが含まれます:
Oracle BPEL PMのWebLogic Server JMSテキスト・メッセージの使用例では、前提条件として次のタスクを実行する必要があります。
次のコードを使用してQ2Qorders.xsdファイルを作成します。
<?xml version="1.0" ?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd" targetNamespace="http://xmlns.oracle.com/ pcbpel/nxsd/extensions/FileInbound" xmlns:tns="http://xmlns.oracle.com/ pcbpel/nxsd/extensions/FileInbound" elementFormDefault="qualified" attributeFormDefault="unqualified" nxsd:encoding="US-ASCII" nxsd:stream="chars" nxsd:version="NXSD"> <xsd:element name="Items"> <xsd:complexType> <xsd:sequence> <xsd:element name="item" minOccurs="1" maxOccurs="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="Name" type="xsd:string" nxsd:style="terminated" nxsd:terminatedBy="," nxsd:quotedBy="""> </xsd:element> <xsd:element name="Type" type="xsd:string" nxsd:style="terminated" nxsd:terminatedBy="," nxsd:quotedBy="""> </xsd:element> <xsd:element name="Quantity" type="xsd:string" nxsd:style="terminated" nxsd:terminatedBy="," nxsd:quotedBy="""> </xsd:element> <xsd:element name="Rate" type="xsd:string" nxsd:style="terminated" nxsd:terminatedBy="${eol}" nxsd:quotedBy="""> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> <!--NXSDWIZ:C:\errors\inputFiles\orders.txt:-->
設計時環境とデプロイ先サーバーの間の接続性を確立する必要があります。「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」で説明した手順を実行して、アプリケーション・サーバー接続を作成します。
SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。次の手順に従ってアプリケーションとSOAプロジェクトを作成します。
リクエスト・メッセージをエンキューし、対応するレスポンス・メッセージ(レポート)をキューからデキューするアダプタ・サービスを作成する手順は、次のとおりです。
Q2Qorders.xsd
スキーマ・ファイルが表示されます。composite.xml
ページが表示されます。作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)を接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。
Oracle JMSアダプタを使用してリモートWLS JMS宛先にアクセスできます。リモート宛先は、リモートOracle WebLogic Serverドメインの一部であるWLS JMSサーバー内で定義されているキューまたはトピックを指します。
このようなアクセスを実行するには、リモートWLS JMSサーバーと通信するように構成されたコネクタ・ファクトリを使用する必要があります。そのためには、次の例に示すように、weblogic-ra.xml
内で定義されているコネクタ・ファクトリの<FactoryProperties>プロパティをリモート・サーバー構成に設定します。
<property> <name>FactoryProperties</name> <value>java.naming.factory.initial =weblogic.jndi.WLInitialContextFactory; java.naming.provider.url= t3://<HOST>:<PORT>; java.naming.security.principal= <USERNAME>;java.naming.security.credentials =<PASSWORD> </value> </property>
Oracle JMSアダプタでリモートWLS JMSサーバーにあるリモート・キューから読み取れるようにするには、次のように構成する必要があります。
両方のサーバーに一意のドメイン名とJMSサーバー名が必要です。
2つのサーバー間でグローバルな信頼を有効化する必要があります。
サーバー間でグローバルな信頼を有効化する方法については、次のリンクを参照してください。
この構成は、WLS9.2サーバーにあるキューまたはトピックに接続する際にも適しています。
注意:
JMSアダプタを使用してWebLogic Serverのセキュアなキュー(ローカルまたはリモートのドメイン)にアクセスする場合は、FactoryPropertiesプロパティのjava.naming.security.principal
およびjava.naming.security.credentials
がWLSのセキュアなキューへのアクセス権を持つユーザーで適切に設定されていることを確認してください。
JMSアダプタを使用すると、SOAがインストールされているWebLogicServerドメインに対してリモートになっている、ドメイン内のWebLogic Server JMSの宛先の場所と対話できます。
JMSアダプタを使用してリモートの宛先にアクセスできるようにする2つのオプションがサポートされています。
アクセス・パラメータにリモート・ドメインを指定したweblogic-ra.xml
ファイルのFactoryProperties
の指定による直接アクセス。
リモート・ドメインにアクセスするように外部サーバーを構成。
インバウンドの使用例では、両方のオプションがサポートされます。アウトバウンドの使用例の場合のみ、直接アクセスはサポートされますが、外部サーバーの構成はサポートされません。
Oracle JMSアダプタでは、同期と非同期のリクエスト-リプライ相互作用パターンの両方がサポートされています。
アダプタ構成ウィザードを使用すると、Oracle JMSアダプタを同期リクエスト-リプライ相互作用パターンに使用できるプロセスをモデル化できます。この場合、Oracle JMSアダプタはリクエスト・キューにリクエストを送信し、リプライ・キューからのレスポンスを待ってから実行を継続します。
下位では、Oracle JMSアダプタにより新規の相互作用パターンJmsRequestReplyInteractionSpec
が使用されます。このインタラクション仕様では、リクエストとリプライの宛先名の構成が許可されています。
バリエーションでは、リプライ・キューの一部として一時返信先の使用が許可されます。基本的に、このパターンではOracle JMSアダプタはJMS宛先にメッセージを送信できます。その後、アダプタはJMSReplyTo
ヘッダーをリプライの宛先に設定します。
この値を使用してサード・パーティ・クライアントからリプライの宛先にメッセージが送信され、その後にメッセージがOracle JMSアダプタによりデキューされます。
Oracle JMSアダプタを同期パターンで使用する場合は、JMSまたはBPEL受信イベントにXA ConnectionFactoryを使用し、コネクタ・ファクトリのisTransacted
プロパティをweblogic-ra.xml
でtrue
に設定できます。ただし、Webサービスを使用する場合は、非XA ConnectionFactoryを使用し、コネクタ・ファクトリのisTransacted
プロパティをweblogic-ra.xml
でtrue
に設定してください。
Oracle WebLogic Server JMSとの同期パターンでOracle JMSアダプタを使用する場合、コネクション・ファクトリはweblogic.jms.ConnectionFactory
またはその他任意の非XAコネクション・ファクトリにする必要があります。また、Oracle WebLogic Server JMSをアダプタと同じローカルJVMで実行する場合は、コネクタ・ファクトリのisTransacted
プロパティがweblogic-ra.xml
でfalse
に設定されていることを確認する必要があります。次のサンプルを入手するには、Oracleサンプル・コード・サイトにアクセスします。
adapters-jms-106-wlsjms-syncrequestreply
adapters-jms-107-wlsjms-syncrequestreplywithtemporaryreplydestination
アダプタ構成ウィザードを使用すると、Oracle JMSアダプタを非同期リクエスト-リプライ相互作用パターンに使用できるプロセスをモデル化できます。
基本的に、このパターンではJMS Oracle JMSアダプタはJMS宛先にメッセージを送信できます。メッセージがリプライ・キューで受信されると、Oracle JMSアダプタはメッセージを正しいコンポジットまたはコンポーネント・インスタンスにルーティングできます。相関付けはリクエスト・メッセージのJMSMessageID
に基づいて実行され、このIDはリプライ・メッセージのJMSCorrelationID
および基礎となるコンポーネントの対話IDとなります。
詳細は、Oracleサンプル・コード・サイトにアクセスして次のサンプルを参照してください。
adapters-jms-105-wlsjms-nativecorrelation
この使用例では、Oracle JMSアダプタでAQ JMSキューとの間のエンキューおよびデキューを実行する方法について説明します。
adapters-jms-108-aqjms-textmessageusingqueues
サンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。
この項には次のトピックが含まれます:
この使用例を実行するには、前提条件として次のタスクを実行する必要があります。
Oracle WebLogic Server管理コンソールでAQ JMSを構成するには、次の手順を実行する必要があります。
Oracle WebLogic JMSモジュールの追加
Oracle WebLogic JMSモジュールの追加はオプションです。AQ JMS外部サーバーを既存のJMSモジュールに作成することもできます。
Oracle WebLogic Server JMS: http://
servername
:
portnumber
/console
にナビゲートします。
必要な資格証明を使用して、Oracle WebLogic Server管理コンソールのホーム・ページを開きます。
Oracle WebLogic Server管理コンソールのホーム・ページが表示されます。
「ドメイン構造」ペインで、「サービス」、「メッセージング」、「JMSモジュール」の順にナビゲートします。
Oracle WebLogic Server管理コンソールの「JMSモジュール」ページが表示されます。
「新規作成」をクリックして新規のWebLogic JMSモジュールを作成します。
Oracle WebLogic Server管理コンソールの「JMSシステム・モジュールの作成」ページが表示されます。
JMSモジュール名を入力して「次へ」をクリックします。
Oracle WebLogic Server管理コンソールの「JMSシステム・モジュールの作成」ページが表示されます。
SOAコンポーネントが実行中のターゲット・サーバーを選択し、「次へ」をクリックします。
Oracle WebLogic Server管理コンソールの「JMSシステム・モジュールの作成」ページが表示されます。
「終了」をクリックします。
JMSモジュールが作成されました。
JMSモジュールへのAQ JMS外部サーバーの追加
次のステップは、次の手順に従ってJMSモジュールにAQ JMS外部サーバーを追加することです。
作成したJMSモジュールをクリックします。
Oracle WebLogic Server管理コンソールの「AQJMSモジュールの設定」ページが表示されます。
「リソースの概要」表で、「新規作成」をクリックして新規のJMSシステム・モジュール・リソースを作成します。
Oracle WebLogic Server管理コンソールの「新しいJMSシステム・モジュール・リソースの作成」ページが表示されます。
「作成するリソースのタイプを選択してください。」で、「外部サーバー」を選択して「次へ」をクリックします。
Oracle WebLogic Server管理コンソールの「新しいJMSシステム・モジュール・リソースの作成」ページが表示されます。
「名前」フィールドに外部サーバー名を入力し、「終了」をクリックします。
Oracle WebLogic Server管理コンソールの「<JMSモジュール名>の設定」ページが表示されます。
AQ JMS外部サーバーの構成
次のステップは、作成したAQ JMS外部サーバーを構成することです。
「リソースの概要」表に表示されるAQ JMS外部サーバーをクリックします。
Oracle WebLogic Server管理コンソールの「TestAQJMS_ForeignServerの設定」ページが表示されます。
以下の値を入力します。
JNDI初期コンテキスト・ファクトリ: oracle.jms.AQjmsInitialContextFactory
AQ JMS外部サーバーがWebLogicサーバー側コンポーネントで使用される場合は、次の値を指定して、このAQ JMS外部サーバーを使用してデータソースを構成する必要があります。
「JNDIプロパティ」フィールドにdatasource=<datasource jndi location>と入力します。プレースホルダをデータソースのJNDIロケーションで置き換えます。
ただし、AQ JMS外部サーバーがWebLogicアプリケーション・クライアントで使用される場合は、作成したAQ JMS外部サーバーを指定してJDBC URLを構成する必要があります。
JNDI接続URL: WebLogicサーバーでJNDIプロバイダへの接続に使用するURLを指定します。
この値は、AQ JMS外部サーバーがWebLogicアプリケーション・クライアントで使用される場合にのみ必須です。
JNDIプロパティ資格証明: JNDIプロバイダ用に設定する必要のある資格証明を指定します。
この値は、AQ JMS外部サーバーがWebLogicアプリケーション・クライアントで使用される場合にのみ必須です。
注意:
Oracle RACデータベースをアダプタ・エンドポイントとして使用する場合は、前述の手順で説明したJNDIプロパティが指すデータソースでマルチ・データソースを指す必要があります。
このようなエンドポイントに使用される個別データソースとマルチ・データソースには、「Oracle JCAアダプタで使用するデータソースの推奨設定」に示す推奨設定を使用する必要があります。
AQ JMS外部サーバーへのコネクション・ファクトリの追加
AQJMS外部サーバーにコネクション・ファクトリを追加する手順は、次のとおりです。
「<外部サーバー名>の設定」ページの「接続ファクトリ」タブで、作成したAQJMS外部サーバーを選択します。
「新規」をクリックします。
Oracle WebLogic Server管理コンソールの「新しい外部JMS接続ファクトリの作成」ページが表示されます。
「名前」フィールドに、このコネクション・ファクトリの名前を入力します。これは、Oracle WebLogic Serverで参照される論理名です。
「ローカルJNDI名」フィールドに、このコネクション・ファクトリを参照するためにアプリケーションで使用するローカルJNDI名を入力します。
注意:
サンプルの使用例AQQueuetoQueue
で提供されるJNDI名がeis/aqjms/Queueのキューに接続する場合は、ローカルJNDI名にaqjms/XAQueueConnectionFactory
を指定してください。
また、JNDI名がeis/aqjms/Topic
のトピックに接続する場合は、aqjms/XATopicConnectionFactory
を指定します。
「リモートJNDI名」フィールドに、要件に応じて次のいずれかの値を入力します。このコネクション・ファクトリをグローバル変換に使用する場合はXAベースのコネクション・ファクトリを使用し、それ以外の場合は非XAベースのコネクション・ファクトリを使用します。
QueueConnectionFactory
TopicConnectionFactory
ConnectionFactory
XAQueueConnectionFactory
XATopicConnectionFactory
XAConnectionFactory
「OK」をクリックします。
AQ JMS外部サーバーへの宛先の追加
AQJMS外部サーバーに宛先を追加する手順は、次のとおりです。
Queues/<queue name>
、宛先がトピックの場合はTopics/<topic name>
と入力します。Oracle WebLogic ServerでAQJMSの構成を完了しました。
キューを作成する手順は、次のとおりです。
setup_user.sql
スクリプトを実行します。create_start_queues.sql
スクリプトを実行します。これらのスクリプトは、adapters-jms-108-aqjms-textmessageusingqueues
サンプルのartifacts/sql
ディレクトリにあります。adapters-jms-108-aqjms-textmessageusingqueues
サンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。
設計時環境とデプロイ先サーバーの間の接続性を確立する必要があります。「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」で説明した手順を実行して、アプリケーション・サーバー接続を作成します。
SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。次の手順に従って新規アプリケーションとSOAプロジェクトを作成します。
次の手順を実行し、メッセージをキューにデキューするアダプタ・サービスを作成します。
リクエスト・メッセージをエンキューし、対応するレスポンス・メッセージ(レポート)をキューからデキューするアダプタ・サービスを作成する手順は、次のとおりです。
作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)を接続する必要があります。
コンポーネントを接続する手順は、次のとおりです。
注意:
Oracle JMSアダプタを使用して永続サブスクリプションを使用するAQ JMSトピックからデキューする際に、デキュー操作が低パフォーマンスであることに気づいた場合は、アダプタ・サービスごとに複数のインバウンド・スレッドを使用することでパフォーマンス全体を高速化できます。
Oracle JMSアダプタでは、エンドポイント・プロパティadapter.jms.receive.threads
を指定すると複数のインバウンド・スレッドが許可されます。
ただし、非永続サブスクリプションを使用する場合、そのシナリオでこの解決策を使用するとメッセージが重複するため、この解決策は機能しません。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。
Fusion Middleware Controlコンソールを使用して、デプロイ済のコンポジットを監視できます。次の手順を実行します。
http://
servername
:portnumber
/em
にナビゲートします。デプロイしたコンポジットがアプリケーション・ナビゲータに表示されます。AQQueue2Queue
.java
を使用してメッセージをエンキューするときにトリガーされたインスタンスです。この項では、Oracle Application Server 11gまたは12.1.3で作成されたキューとトピックにOC4J 10.1.3.4からアクセスする手順について説明します。
このことを行うには、Oracle WebLogic Serverを使用してOracle BPEL PM JMSアダプタを構成する必要があります。
Oracle WebLogic Serverを使用してOracle BPEL PM JMSアダプタを構成する手順は、次のとおりです。
次の手順に従ってwlfullclient.jar
ファイルを作成します。
次の例に示すようにserver/lib
ディレクトリに移動します。
cd WL_HOME
/server/lib
次のコマンドを使用して、server/lib
ディレクトリにwlfullclient.jar
ファイルを作成します。
java -jar ../../../modules/com.bea.core.jarbuilder_X.X.X.X.jar
X.X.X.X
は、WL_HOME
/server/lib
ディレクトリにあるjarbuilderモジュールのバージョン番号です。例:
java -jar ../../../modules/com.bea.core.jarbuilder_1.0.1.0.jar
wlfullclient.jar
ファイルを、次の場所にある10.1.3.4サーバーにコピーします。
<ORACLEAS_HOME>/j2ee/<OC4J_INSTANCE>/connectors/ JmsAdapter/JmsAdapter
次の例に示すように、oc4j-ra.xml
ファイル内のコネクタ・ファクトリ設定を構成します。
<connector-factory location="eis/wlsjms/Queue" connector-name="Jms Adapter"> <config-property name="connectionFactoryLocation" value="weblogic.jms.ConnectionFactory"/> <config-property name="factoryProperties" value="java.naming.factory.initial=weblogic.jndi. WLInitialContextFactory;java.naming.provider.url=t3: //<WLS-SERVER-NAME>: <WLS-SERVER-PORT>; java.naming.security.principal=<USER>; java.naming.security.credentials= <PASSWORD>"/> <config-property name="acknowledgeMode" value="AUTO_ACKNOWLEDGE"/> <config-property name="isTopic" value="false"/> <config-property name="isTransacted" value="false"/> <config-property name="username" value=""/> <config-property name="password" value=""/> <connection-pooling use="none"> </connection-pooling> <security-config use="none"> </security-config> </connector-factory>
注意:
isTransacted
構成プロパティの値は、通常はFALSE
に設定する必要があります。現在、XAとWebLogic JMSの統合は、アダプタがOracle WebLogic Serverにデプロイされていないかぎりサポートされていません。また、<WLS-SERVER-NAME>
はキューをホストする実際のWeblogic Server名で置き換える必要があること、さらに<WLS-SERVER-PORT>
はキューをホストするWeblogic Serverの実際のポート値で置き換える必要があることに注意してください。
次の例に示すように、10.1.3.4サーバーのserver.xml
ファイルを変更し、environment-naming-url-factory-enabled="true"
プロパティを追加します。
<application-server ... ... environment-naming-url-factory-enabled="true" ... >
10.1.3.4サーバーを再起動して、変更されていることを確認します。
次の手順に従って、10.1.3.x OC4Jに存在するキューにアクセスするように11G以降のサーバーを構成できます。
次のjarファイルをWebLogic Serverのdomains/<DOMAIN_NAME>/lib
フォルダにコピーします。
$J2EE_HOME/lib/jms.jar
$J2EE_HOME/lib/jta.jar
$J2EE_HOME/oc4jclient.jar
$AS_HOME/opmn/lib/optic.jar
次の手順は、weblogic-ra.xml
ファイルへのコネクタ・ファクトリの追加です。
<connection-instance><jndi-name>eis/oc4jjms/Queue</jndi-name>
<connection-properties>
<properties>
<property>
<name>ConnectionFactoryLocation</name>
<value>jms/XAQueueConnectionFactory</value>
</property>
<property>
<name>FactoryProperties</name>
<value>java.naming.factory.initial=com. evermind.server.rmi.RMIInitialContextFactory; java.naming.provider.url= <PROVIDER_URL>; java.naming.security.principal=oc4jadmin;
java.naming.security.credentials=welcome1</value>
</property>
<property><name>AcknowledgeMode</name>
<value>AUTO_ACKNOWLEDGE</value>
</property> <property> <name>IsTopic</name> <value>false</value> </property> <property> <name>IsTransacted</name><value>false</value>
</property>
<property>
<name>Username</name> <value>oc4jadmin</value> </property> </property> <property><name>Password</name>
<value>welcome1</value> </property></properties>
</connection-properties> </connection-instance>
<PROVIDER_URL>=opmn://localhost:6003
またはormi://localhost:12401
は特定のノードに使用し、opmn:ormi://localhost:6003:oc4j_soa
はoc4j_soaインスタンスに使用します。
分散宛先は、単一の論理的な宛先としてクライアントからアクセスできる宛先のセット(キュー、物理的なJMSキュー・メンバーのセット、またはトピック、物理的なJMSトピック・メンバーのセット)です。
注意:
分散宛先の詳細およびこのコンテキストで使用されている用語の定義は、http://download.oracle.com/docs/cd/E13222_01/wls/docs103//jms/dds.htmlにある分散宛先の使用に関するページを参照してください
JMSアダプタは、使用可能通知の受信後に分散宛先メンバーにアドレス指定されたメッセージを処理できます。分散宛先メンバーに関連する使用可能通知、使用不能通知および障害通知を処理できます。分散トピックの使用時にJMSアダプタでこのようなメッセージを処理するには、追加のプロパティを指定する必要があります。
追加のプロパティを指定する場合は、複数のFactoryProperty値をセミコロンで区切ることができます。次の例を参照してください。
<property> <name>FactoryProperties</name> <value>ClientID=SOACLient2;TopicMessageDistributionAll=true</value> </property>
また、クラスタ内でJMSアダプタがWLSの複数の管理対象サーバーと対話するシナリオでは、すべてのサーバーをFactoryProperties
プロパティの一部として指定する必要があります。これらを使用して、次の例のように、JMSアーティファクトを参照するための適切なコンテキストを確立します。
<property> <name>FactoryProperties</name> <value> java.naming.factory.initial=weblogic.jndi. WLInitialContextFactory; java.naming.provider.url=t3://<server1>:<port1>, <server2>:<port2>; java.naming.security.principal= <username>;java.naming.security.credentials =<password> </value> </property>
山カッコ<>は自身の環境で使用可能な値に置き換えます。
3つのFactoryPropertyパラメータ値を使用して、分散トピックにアクセスするアダプタの指定、複数の接続で共有するクライアントIDの明示的な有効化、複数のサブスクライバ間での永続サブスクリプションの共有の有効化を行う他、アプリケーションごとまたはエンドポイントごとに1つのメッセージのコピーが必要かどうかを指定します。次のプロパティがあります。
ClientIDPolicy
複数の接続でクライアントIDを共有できるようにするには、FactoryPropertiesパラメータのClientIDPolicy
プロパティにUNRESTRICTED
という値を使用します。値が指定されていない場合、デフォルトはUNRESTRICTED
です。デフォルト以外の値はRESTRICTED
です。ほぼすべてのケースでデフォルトが使用されるため、通常はこのプロパティを設定する必要はありません。次の例を参照してください。
</property> <name>FactoryProperties</name> <value>ClientIDPolicy=UNRESTRICTED</value> </property>
SubscriptionSharingPolicy
複数のサブスクライバ間で永続サブスクリプションを共有できるようにするには、FactoryPropertiesパラメータにSHARABLE
という値を使用します。
SubscriptionSharingPolicyの値EXCLUSIVE
は、複数のサブスクライバ間で永続サブスクリプションを共有できないことを意味します。値を指定しない場合、デフォルトはSHARABLE
です。ほとんどの場合、値を変更する必要はありません。
<property> <name>FactoryProperties</name> <value>SubscriptionSharingPolicy= SHARABLE</value> </property>
TopicMessageDistributionAll
TopicMessageDistributionAll
FactoryPropertiesパラメータの詳細は、分散トピックに関する項を参照してください。次の例のように設定できます。
<property> <name>FactoryProperties</name> <value>TopicMessageDistributionAll=true</value> </property>
特定のインバウンドおよびアウトバウンド・キューおよびエラー処理の動作は、WebLogic Server JMSの分散キューおよび分散トピックを使用したJMSアダプタに適用されます。
インバウンド・キューの場合、JMSアダプタはインバウンド・ポーラー・スレッドを作成し、エンドポイント・アクティブ化時にWebLogic Server JMSに通知リスナーを登録します。エンドポイントの非アクティブ化時に通知リスナーを登録解除します。
注意:
内部では、コンシューマが分散キューのメンバーに固定されます。多数のスレッドを使用してアダプタをデプロイすることで、分散キューのすべてのメンバーを考慮できるようにする必要があります。
SOA 11.1.1.4.0以降のバージョンから、JMSアダプタでは分散キューと分散トピックの両方を完全にサポートしています。JMSアダプタの新しいバージョンでは、WebLogic Server JMSからの通知に依存して、分散宛先のメンバーに対するコンシューマの作成および削除を行います。
SOA 11.1.1.3.0以前のバージョンのJMSアダプタの動作(ここでは分散キューの2つ以上のメンバーにコンシューマがランダムに作成されます)とSOA 11.1.1.4.0以降の新しい動作を比較すると、アクティブ化の際に多数のポーラー・スレッドを使用してJMSアダプタを起動することに依存しなくてもすべてのメンバーを考慮できるようになったこと以外に変更はありません。
JMSアダプタは、非分散環境のエラーが処理されるのと同じ方法で分散環境のエラーを処理します。再試行可能例外ではメッセージが再試行されます。再試行不能例外ではメッセージが拒否されます。
アダプタが分散キューへのメッセージを生成するときに、他のアダプタの動作からJMSアダプタの動作への変更は行われません。
分散宛先に対するJMSメッセージは、分散宛先に対してMessageProducerを作成し、特定のメンバーに対しては作成しないことで生成されます。
アウトバウンド・エラーは、アウトバウンド参照に対して以前に定義されたフォルト・ポリシーに基づいて処理されます。
分散トピックを使用したインバウンド・アダプタの場合、JMSアダプタはエンドポイントのアクティブ化時に通知リスナーをWebLogic Server JMSに登録します。JMSアダプタは、分散トピック・メンバーに対してWebLogic Server JMSから受信した使用可能通知ごとにインバウンド・ポーラー・スレッドを作成します。
ポーラー・スレッドが作成されたメンバーに対する使用不能通知が受信された場合は、インバウンド・ポーラー・スレッドが作業を停止し、必要なクリーン・アップが実行されます。恒久サブスクリプションは、非分散トピック・シナリオの場合と同様に保持されます。
アダプタは、エンドポイントの非アクティブ化時に通知リスナーを登録解除します。分散トピックに到着したメッセージは、使用されている様々な設定と使用中の分散宛先のタイプ(アプリケーションごとにメッセージのコピーが1つ、またはアダプタ・エンドポイントごとにメッセージのコピーが1つ)に基づいて処理されます。
これらの各タイプの分散宛先の動作を次に示します。
JMSアダプタで使用される場合のWebLogic Serverパーティション分散トピックのデフォルトの動作では、アプリケーションごとにメッセージのコピーが1つ提供されます。各メッセージは必ず1回のみ処理する(つまり、重複する処理がない)必要があります。アプリケーションごとにメッセージのコピーが1つあるこのシナリオでは、クライアントIDとサブスクリプション名はすべての分散宛先に対して 同じ であり、 各 アダプタ・インスタンスが すべての メンバーにサブスクリプションを作成します。サーバーの再起動後も名前は一意であり不変です。パーティション分散トピックを使用する場合、無制限のクライアントIDと共有サブスクリプション・ポリシーを使用するようにJMSアダプタを構成する必要があります。この2つはJMSアダプタのデフォルト設定です。複製された分散トピックを使用している場合は、無制限のクライアントIDと共有サブスクリプションのポリシーを使用するようにJMSアダプタを構成する必要があります(これはデフォルト設定です)。また、アクティブ化の仕様を定義するときに、NOT JMS_WL_DDForwarded
のようにメッセージ・セレクタを指定する必要があります。
パフォーマンスを向上させるには、パーティション分散トピックを使用する必要があります。
ローカル・クラスタのweblogic-ra.xml
ファイルの接続インスタンスのスニペットから構成される例については、次を参照してください。
<property> <name>FactoryProperties</name> <value>ClientID=SOAClient1;</value> </property>
分散トピックで使用できる2番目の使用例では、アダプタ・エンドポイントごとに1つのメッセージのコピーを使用します。この場合、クライアントIDまたはサブスクリプション名は、アダプタ・インスタンスごとに一意です。メンバー名の一意の 部分 は、サーバーの再起動後も変わりません。
パーティション分散トピックを使用する場合は、無制限のクライアントIDと共有サブスクリプションのポリシーを使用するようにJMSアダプタを構成する必要があります(これはデフォルト設定です)。
同時に、サブスクリプション名を一意にするには、JMSアダプタではプロパティTopicMessageDistributionAll
(デフォルト値はfalse)がtrueに設定されている必要があります。このプロパティは、weblogic-ra.xml
ファイルで接続インスタンスのFactoryProperties
プロパティを設定することで定義できます。
使用例(ローカル・クラスタのweblogic-ra.xml
ファイルの接続インスタンスのスニペット)を次に示します。
<name>FactoryProperties</name> <value>ClientID=SOAClient2; TopicMessageDistributionAll=true</value> </property>
パフォーマンスを向上させるには、パーティション分散トピックを使用する必要があります。
複製された分散トピックを使用している場合は、無制限のクライアントIDと共有サブスクリプションのポリシーを使用するようにJMSアダプタを構成します(これはデフォルト設定です)。
同時に、サブスクリプション名を一意にするには、JMSアダプタではプロパティTopicMessageDistributionAll
(デフォルト値はfalse)がtrueに設定されている必要があります。このプロパティは、weblogic-ra.xml
で接続インスタンスのFactoryProperties
プロパティを設定することで定義できます。使用例(ローカル・クラスタのweblogic-ra.xml
の接続インスタンスのスニペット)を次に示します。
<name>FactoryProperties</name> <value> ClientID=SOAClient2; TopicMessageDistributionAll=true</value> </property>
また、アクティブ化の仕様を定義するときに、メッセージ・セレクタNOT JMS_WL_DDForwarded
を指定する必要があります。
アクティブ化の仕様を定義するときに、メッセージ・セレクタを指定します。メッセージ・セレクタは、アダプタ・エンドポイントごとにメッセージのコピーを1つ作成する場合に必要です。
セレクタを指定するには、重複する分散トピックから読み取ったコンポジット・アプリケーションをモデリングするときにJMSアダプタ・ウィザードを使用します。指定するメッセージ・セレクタのメタデータは、.jca
ファイルに取得されます。
アクティブ化の仕様で定義されているメッセージ・セレクタの例を次に示します。このメッセージ・セレクタは、メッセージを宛先サブスクライバに送信するときに、転送されたメッセージのコピーを除外します。
このメッセージ・セレクタは、複製された分散トピックを使用する場合のみ適用できます。
<activation-spec className="oracle.tip.adapter.jms.inbound.JmsConsumeActivationSpec"> <property name="DestinationName" value="jms/DemoInTopic"/> <property name="UseMessageListener" value="false"/> <property name="DurableSubscriber" value="dsub1"/> <property name="MessageSelector" value="NOT JMS_WL_DDForwarded"/> <property name="PayloadType" value="TextMessage"/> </activation-spec>
分散トピックでは、再試行可能例外によりメッセージが再試行され、再試行不能例外によりメッセージが拒否されます。
使用可能/使用不能/障害通知は、アウトバウンド・アダプタ参照の処理には影響しません。メッセージは特定メンバーではなく分散宛先を対象とするMessageProducerを作成することによって作成されます。
分散トピック環境では、他の環境と同様に、エラーはアウトバウンド参照に対して定義されているフォルト・ポリシーに基づいて処理されます。
この項では、IBM WebSphere 7.x JMSに対するOracle JMSアダプタの構成方法について説明します。
次のファイルを<WAS_INSTALL DIR>/fmwwas-nd/websphere/runtimes
ディレクトリの下からSOAInstall_DIR>/user_projects/domains/<DOMAIN_NAME>/
/libフォルダにコピーします。
com.ibm.jaxws.thinclient_7.0.0.jar
com.ibm.ws.admin.client_7.0.0.jar
com.ibm.ws.ejb.thinclient_7.0.0.jar
com.ibm.ws.jpa.thinclient_7.0.0.jar
com.ibm.ws.messagingClient.jar
com.ibm.ws.orb_7.0.0.jar
com.ibm.ws.sib.client.thin.jms_7.0.0.jar
com.ibm.ws.sib.client_ExpeditorDRE_7.0.0.jar
com.ibm.ws.webservices.thinclient_7.0.0.jar
ejb3exceptions.jar
sibc.jmsra.rar
sibc.nls.zip
次の例に示すように、soa/connectors/JmsAdapter.rar
にある weblogic-ra.xml
ファイルを変更してコネクタ・ファクトリを構成します
例 - コネクション・ファクトリの構成
<connection-instance> <jndi-name>eis/webspherejms/Queue</jndi-name> <connection-properties> <properties> <property> <name>ConnectionFactoryLocation</name> <value><QUEUE_CONECTION_FACTORY></value> </property> <property> <name>FactoryProperties</name> <value>java.naming.provider. url=iiop://<HOST_NAME>:<PORT>; java.naming.factory.initial=com.ibm. websphere.naming.WsnInitialContextFactory; java.naming.security.principal=<USERNAME>; java.naming.security.credentials=<PASSWORD>; ThirdPartyJMSProvider=true </value> </property> <property> <name>AcknowledgeMode</name> <value>AUTO_ACKNOWLEDGE</value> </property> <property> <name>IsTopic</name> <value>false</value> </property> <property> <name>IsTransacted</name> <value>true</value> </property> <property> <name>Username</name> <value><USERNAME></value> </property> <property> <name>Password</name> <value><PASSWORD></value> </property> </properties> </connection-properties> </connection-instance> <connection-instance> <jndi-name>eis/webspherejms/Topic</jndi-name> <connection-properties> <properties> <property> <name>ConnectionFactoryLocation</name> <value><TOPIC_CONECTION_FACTORY></value> </property> <property> <name>FactoryProperties</name> <value>java.naming.provider.url= iiop://<HOST_NAME>:<PORT>; java.naming.factory.initial=com.ibm.websphere. naming.WsnInitialContextFactory; java.naming.security.principal=<USERNAME>; java.naming.security.credentials=<PASSWORD>; ThirdPartyJMSProvider=true </value> </property> <property> <name>AcknowledgeMode</name> <value>AUTO_ACKNOWLEDGE</value> </property> <property> <name>IsTopic</name> <value>true</value> </property> <property> <name>IsTransacted</name> <value>true</value> </property> <property> <name>Username</name> <value><USERNAME></value> </property> <property> <name>Password</name> <value><PASSWORD></value> </property> </properties> </connection-properties> </connection-instance>
<QUEUE_CONECTION_FACTORY>
および<TOPIC_CONECTION_FACTORY>
は、デフォルトのJMSプロバイダのWebSphere 7.0でそれぞれ作成されているキューおよびトピック・コネクション・ファクトリのJNDI名を参照しています。
または、Oracle WebLogic Server管理コンソールを使用して新規コネクション・ファクトリを作成し、「アダプタ・コネクション・ファクトリの追加」で説明する手順を使用することもできます。
注意:
WebSphere 7.x JMSと対話する際は、XA以外のモードでのみJMSアダプタを使用できます。
リクエスト-リプライ構成機能では、次のことを実行できます。
単一の構成手順でのリクエストとリプライの結合。Oracle SOA Suiteの以前のリリースでは、2つの異なるアダプタを構成する必要がありました。
BPEL相関セットの手動構成を必要としない自動相関付け。これはメディエータMediatorおよびBPMNでもシームレスに機能します。
JMSアダプタのリクエスト-リプライ機能を構成するには、次の手順を実行します。
JDeveloperコンポジット・エディタで、JMSアダプタを「外部参照」スイムレーンにドラッグ・アンド・ドロップします。
JMSアダプタ構成ウィザードの最初のいくつかの画面でデフォルト値を入力し、操作名の入力を求める画面まで進みます。「操作タイプ」として「リクエスト/リプライ」を、「操作名」として「非同期」を選択します。
ウィザードの後続の画面で、リクエスト・キューおよびリプライ・キューを選択します。メッセージはリクエスト・キューでエンキューされ、リプライはリプライ・キューで返されます。
リクエスト・キューから読み取りレスポンス・キューにレスポンスを生成するバックエンド・システムは、実際には複数のレスポンスを生成します。そのため、このようなセレクタを使用することによって、不要なレスポンスをフィルタして除外する必要があります。
レスポンスのメッセージ・スキーマを選択します。
JMS Adapterパートナ・リンクに対応するBPELの<invoke>アクティビティを追加します。使用するサード・パーティ・アプリケーションで必要となるため、追加ヘッダーが設定されています。
図8-31 JMS Adapterリンクに対応するBPELのInvokeプロパティ・ダイアログ
<invoke>アクティビティの直後に<receive>アクティビティを追加し、「リプライ」操作を選択します。「インスタンスの作成」オプションが選択されていないことを確認します。
SOA JMSアダプタを使用して、メッセージの特定の順序単位を作成したメッセージを生成できます。アダプタのInteractionSpecでは、JMSアダプタ構成ウィザードの操作の生成ページを使用してアダプタ参照をモデル化する際に構成したUnitOfOrder
という名前のプロパティがサポートされます。「メッセージ発行手順」の当該ページの説明を参照してください。
このUnitOfOrder
プロパティを使用して、メッセージの生成時にMessageProducerの順序単位値を設定します。新しいフィールドは、JMSプロバイダがWebLogic Server JMSの場合にのみ表示できます。
JMSアダプタにより、WLS宛先へのメッセージの生成時に使用されるこの順序単位をオーバーライドできるようになります。
このオーバーライドを実行するには、JMSアダプタでjca.jms.WeblogicUnitOfOrder
という名前の正規化されたメッセージ・プロパティをサポートします。この値により、 JmsProduceInteractionSpec
のUnitOfOrder
プロパティを使用して指定された値がオーバーライドされます。
UnitOfOrder
指定プロパティの値はEMコンソールで変更できます。その時点以降のアウトバウンド相互作用ではすべて、指定する新しい値が使用されます。
当該プロパティのjca.jms.WeblogicUnitOfOrder
も、JmsProduceInteractionSpec
プロパティのUnitOfOrder
も定義されていない場合は、JMSアダプタで順序単位値は設定されません。デフォルトの順序単位がコネクション・ファクトリおよび宛先で管理者によって指定されている場合は、それが有効化されます。
JMSの順序単位機能は、WebLogic Serverとのみ動作します。WebLogic Server以外の宛先では、当該プロパティのjca.jms.WeblogicUnitOfOrder
(存在する場合)は無視されます。
Oracle JMSアダプタでは、同期消費(中間プロセス受信)相互作用パターンがサポートされています。
アダプタ構成ウィザードを使用すると、Oracle JMSアダプタをこのような同期消費相互作用パターンに使用できるプロセスをモデル化できます。この場合、Oracle JMSアダプタでは、プロセスの実行中に指定されたキューからのメッセージがデキューされます(このため、中間プロセス受信と呼ばれます)。
キューが空の場合は、実行が継続されます。下位では、Oracle JMSアダプタにより新規の相互作用パターンJmsReceiveNoWaitInteractionSpec
が使用されます。
JMSアダプタ構成ウィザードを使用してJMS同期消費をモデル化する場合は、デキューに使用するキュー名を指定する必要があります。この操作の場合、JMSアダプタでは、現在の消費操作が構成されたときに構成されたその他すべてのjcaプロパティがサポートされます。
この操作を使用するシナリオでは、JMSアダプタにデキューするキューに関するメッセージがない場合、BPELプロセスによって、引き続きプロセスの次の手順が実行されます。