Red Hat Training
A Red Hat training course is available for JBoss Enterprise SOA Platform
5.18.3. InVM を使用した開発
JBoss Enterprise SOA Platform ではサービスを複数の異なるトランスポートで同時に呼び出すことができるため、高いパフォーマンスと信頼性を実現できるようにサービスを簡単に設計できます。これを行うには、メッセージの種類ごとに適切なトランスポートを選択します。
製品の以前のバージョンはこのトランスポートをサポートしておらず、すべてのサービスを少なくとも 1 つのメッセージ対応リスナーで設定する必要がありました。これは要件から除外されました。<listeners> 設定なしでサービスを設定できるようになり、独自の仮想マシン内から引き続き呼び出すことができます。
<service category="ServiceCat" name="ServiceName" description="Test Service">
<actions mep="RequestResponse">
<action name="action" class="org.jboss.soa.esb.listeners.SetPayloadAction">
<property name="payload" value="Tom Fennelly" />
</action>
</actions>
</service>
これにより、サービスの設定がもう少し簡単になります。
<service> 要素の invmScope 属性を使用して、InVM サービスの呼び出し範囲を制御します。次の 2 つのスコープがサポートされています。
- GLOBAL: (デフォルト) サービスは、同じ Classloader スコープ内から InVM トランスポートを介して呼び出すことができます。
- NONE: InVM トランスポート経由でサービスを呼び出すことはできません。
InVM リスナーは、トランザクションをサポートする他のトランスポートと同じ方法で、トランザクションスコープまたは非トランザクションスコープ内で実行できます。この動作は、明示的または暗黙的な設定によって制御できます。
トランザクションスコープの明示的な設定は、<service> 要素の invmTransacted 属性の定義によって制御され、暗黙的な設定よりも常に優先されます。
注記
別のトランザクション処理がされたトランスポートが、サービスに設定されている場合には、ImVM リスナーは暗黙的にトランザクション処理されます。現在、これらの追加のトランスポートは、jms、スケジュール、または sql にすることができます。
警告
JBoss Enterprise SOA Platform の InVM トランスポートはトランザクションベースで、メッセージキューは揮発メモリーでのみ保持されます。つまり、システム障害が発生した場合やシャットダウンをした場合に、このトランスポートのメッセージキューが失われます。
注記
特にデータベースなどの他のトランザクションリソースと組み合わせて使用する場合に、ACID セマンティクスのすべてを実現できない場合があります。これは、InVM キューの揮発性の特性が原因ですが、ほとんどの場合、InVM のパフォーマンス上の利点がこの欠点を上回るはずです。完全な ACID セマンティクスが必要な状況では、Red Hat は、Java Message Service やデータベースなど、他のトランザクショントランスポートのいずれかを使用することをお勧めします。
トランザクション内で InVM を使用する場合には、トランザクションがコミットされるまでメッセージは受信者のキューに表示されませんが、送信者には、メッセージが受けいれられ、後でキューに追加されるという確認応答がすぐに表示されます。受信者がトランザクションの範囲内でキューからメッセージをプルしようとした場合に、そのトランザクションが後でロールバックすると、メッセージは自動的にキューに戻されます。メッセージの送信者または受信者がトランザクションの結果を知る必要がある場合は、トランザクションの結果を直接監視するか、トランザクションに同期を登録する必要があります。
トランザクションマネージャーによってメッセージがキューに戻されると、同じ場所に戻らない場合があります。これは、パフォーマンスを最大化するための意図的な仕様です。アプリケーションでメッセージの特定の順序付けが必要な場合は、別のトランスポートを検討するか、関連するメッセージを 1 つのラッパーメッセージにグループ化する必要があります。
