Red Hat Training

A Red Hat training course is available for JBoss Enterprise SOA Platform

ESB プログラマーガイド

JBoss Enterprise SOA Platform 5

このガイドは、ソフトウェアエンジニア向けです。

概要

このリファレンスドキュメントには、JBoss Enterprise SOA Platform 製品を使用したプログラミングに関する情報が含まれています。

はじめに

1. ドキュメント規則

本ガイドでは、いくつかの規則を使用して特定の単語やフレーズを強調表示し、特定の情報への注意を促しています。

1.1. 表記規則

特定の単語や句への注意を促すために 4 つの表記慣習を使用しています。これらの規則や、これらが適用される状況は以下のとおりです。
等幅ボールド
シェルコマンド、ファイル名、パスなど、システム入力を強調表示するために使用されます。キーとキーの組み合わせを強調表示するためにも使用されます。以下に例を示します。
現在の作業ディレクトリーのファイル my_next_bestselling_novel の内容を表示するには、シェルプロンプトで cat my_next_bestselling_novel コマンドを入力し、Enter を押してコマンドを実行します。
上記には、ファイル名、シェルコマンドおよびキーが含まれます。これはすべて等幅ボールドで表示され、コンテキストにより区別可能なものになります。
キーの組み合わせは、各部分をつなぐプラス記号によって、個別のキーと区別できます。以下に例を示します。
Enter を押してコマンドを実行します。
Ctrl+Alt+F2 を押して、仮想ターミナルに切り替えます。
最初の例では、押す特定のキーを強調表示しています。2 つ目の例は、同時に押す 3 つのキーのセットというキーの組み合わせを強調表示しています。
ソースコードの場合、段落内で記述されるクラス名、メソッド、関数、変数名、および戻り値は、上記のように 等幅ボールド で示されます。以下に例を示します。
ファイル関連のクラスには、ファイルシステムの filesystem、ファイルの file、ディレクトリーの dir が含まれます。各クラスには、独自の関連付けられたパーミッションセットがあります。
プロポーショナルボールド
これは、アプリケーション名、ダイアログボックステキスト、ラベルが付いたボタン、チェックボックスおよびラジオボタン、メニュータイトルおよびサブメニュータイトルなど、システムで発生した単語またはフレーズを示します。以下に例を示します。
メインメニューバーから SystemPreferencesMouse を選択し、Mouse Preferences を起動します。Buttons タブで、Left-handed mouse チェックボックスを選択し、Close をクリックしてメインのマウスボタンを左から右に切り替えます (マウスを左手で使い易くします)。
特殊文字を gedit ファイルに挿入するには、メインメニューバーから ApplicationsAccessoriesCharacter Map を選択します。次に、Character Map メニューバーから SearchFind… を選択し、Search フィールドに文字の名前を入力して Next をクリックします。目的の文字が Character Table で強調表示されます。この強調表示した文字をダブルクリックして Text to copy フィールドに配置し、Copy ボタンをクリックします。ここでドキュメントに戻り、gedit メニューバーから EditPaste を選択します。
上記のテキストにはアプリケーション名、システム全体のメニュー名および項目、アプリケーション固有のメニュー名、GUI インターフェイス内のボタンおよびテキストなどがあります。すべては proportional bold で示され、コンテキストと区別できます。
等幅ボールドイタリック または プロポーショナルボールドイタリック
等幅ボールドまたはプロポーショナルボールドのいずれでも、イタリックが追加されると、置換または変数テキストを意味します。イタリックは、状況に応じて変化するテキストや、文字を入力しないテキストを表します。以下に例を示します。
ssh を使用してリモートマシンに接続するには、シェルプロンプトで ssh username@domain.name を入力します。リモートマシンが example.com で、そのマシン上でのユーザー名が john の場合は、ssh john@example.com と入力します。
mount -o remount file-system コマンドにより、指定したファイルシステムが再マウントされます。たとえば、/home ファイルシステムを再マウントする場合、コマンドは mount -o remount /home となります。
現在インストールされているパッケージのバージョンを表示するには、rpm -q package コマンドを使用します。これにより、package-version-release のような結果が返されます。
上記の太字のイタリック体の用語、username、domain.name、file-system、package、version、および release に注意してください。各単語はプレースホルダーで、コマンドの発行時に入力するテキストまたはシステムによって表示されるテキストのどちらかになります。
作業のタイトルを示す標準的な使用法のほかに、イタリックは新用語と重要な用語の最初の使用を示します。以下に例を示します。
Publican は DocBook 公開システムです。

1.2. 引用規則

端末の出力およびソースコードの一覧は、周りのテキストから視覚的に表示されます。
ターミナルに送信される出力は mono-spaced roman に設定され、以下のように表示されます。
books        Desktop   documentation  drafts  mss    photos   stuff  svn
books_tests  Desktop1  downloads      images  notes  scripts  svgs
ソースコードの一覧も mono-spaced roman に設定されますが、以下のように構文の強調表示が追加されます。
static int kvm_vm_ioctl_deassign_device(struct kvm *kvm,
                 struct kvm_assigned_pci_dev *assigned_dev)
{
         int r = 0;
         struct kvm_assigned_dev_kernel *match;

         mutex_lock(&kvm->lock);

         match = kvm_find_assigned_dev(&kvm->arch.assigned_dev_head,
                                       assigned_dev->assigned_dev_id);
         if (!match) {
                 printk(KERN_INFO "%s: device hasn't been assigned before, "
                   "so cannot be deassigned\n", __func__);
                 r = -EINVAL;
                 goto out;
         }

         kvm_deassign_device(kvm, match);

         kvm_free_assigned_device(kvm, match);

out:
         mutex_unlock(&kvm->lock);
         return r;
}

1.3. 注記および警告

最後に、3 つの視覚的スタイルを使用して、見落とす可能性のある情報に注意を促します。
注記
注記とは、タスクへのヒント、ショートカット、または代替アプローチです。注意を無視しても悪い結果を招くことはありませんが、便利なヒントを見逃してしまう可能性があります。
重要
見落としやすい詳細のある重要なボックス: 現行セッションにのみ適用される設定変更や、更新を適用する前に再起動が必要なサービスなどです。Important というラベルが付いたボックスを無視しても、データが失われることはありませんが、スムーズな操作が行えないことがあります。
警告
警告は無視すべきではありません。警告を無視すると、データが失われる可能性があります。

2. ヘルプの利用とフィードバック提供

2.1. ヘルプが必要ですか ?

本ガイドで説明されている手順で問題が発生した場合は、Red Hat カスタマーポータル http://access.redhat.com にアクセスしてください。カスタマーポータルでは、以下を行うことができます。
  • Red Hat 製品に関する技術サポート記事の知識ベースの検索または閲覧。
  • Red Hat グローバルサポートサービス (GSS) へのサポートケースの送信。
  • その他の製品ドキュメントへのアクセス。
Red Hat は、Red Hat のソフトウェアおよびテクノロジーについて、多くの電子メーリングリストも提供しています。一般に公開されているメーリングリストの一覧は、https://www.redhat.com/mailman/listinfoを参照してください。メーリングリストの名前をクリックして、その一覧をサブスクライブするか、またはメーリングリストのアーカイブにアクセスします。

2.2. ご意見をお寄せください

本ガイドで誤字脱字を発見されたり、このマニュアルを改善するための提案をお持ちの場合は、弊社までご連絡ください。JBoss Enterprise SOA Platform の製品に対して、Bugzilla: http://bugzilla.redhat.com/ レポートを送信してください。
バグレポートを送信する際は、必ずマニュアルの識別子 (『ESB_Programmers_Guide』) を記載してください。
本ガイドを改善するためのご意見やご提案をお寄せいただく場合は、できるだけ具体的にご説明ください。エラーが見つかった場合は、簡単に確認できるように、セクション番号と前後のテキストを含めてください。

第1章 はじめに

1.1. ビジネス統合

動的かつアジャイルなビジネスインフラストラクチャーを提供するためには、異なるアプリケーションとデータソースが最小限のオーバーヘッドで相互に通信できるように、サービス指向のアーキテクチャーを用意することが重要です。
JBoss Enterprise SOA Platform は、ビジネスプロセスの変更に対応するために、継続的に再利用することなく、ビジネスサービスをオーケストレーションできるフレームワークです。JBoss Enterprise SOA Platform では、ビジネスルールとメッセージの変換およびルーティング機能を使用することで、複数のソースからビジネスデータを操作できます。

1.2. サービス指向アーキテクチャーとは

はじめに

SOA (Service Oriented Architecture) は単一のプログラムまたはテクノロジーではありません。ソフトウェア設計パラダイムと見なします。

すでに分かっているように、ハードウェアバス は、複数のシステムとサブシステムを結び付ける物理コネクターです。これを使用する場合は、システムのペア間で多数のポイントツーポイントコネクターを使用する代わりに、各システムを中央バスに接続するだけです。エンタープライズサービスバス (ESB)は、ソフトウェアとまったく同じことを行います。
アーキテクトは、メッセージングシステムの上記のアーキテクチャー層にあります。このメッセージングシステムは、このメッセージングシステムを使用することでサービス間の 非同期通信 を容易にします。実際、アーキテクトを使用している場合、すべてを概念的に、サービス (このコンテキストではアプリケーションソフトウェア)またはサービス間で送信される メッセージ のいずれかです。サービスは接続アドレスとして一覧表示されます (エンドポイント参照 と呼ばれています)。
このコンテキストでは、サービスは必ずしも Web サービスであるとは限らないことに注意することが重要です。File Transfer Protocol や Java Message Service などのトランスポートを使用する他のタイプのアプリケーションもサービスになる可能性があります。
注記
この時点で、エンタープライズサービスバスがサービス指向のアーキテクチャーと同じ場合は、妨げられる場合があります。回答は Not exactly です。 アーキテクトは、サービス指向のアーキテクチャーを形成しません。代わりに、ツールを多数使用して構築できます。特に、SOA が必要とする loose-coupling および 非同期メッセージを渡すこと が容易になります。SOA は常にソフトウェア以外のものと考えてください。これは一連の原則、パターン、およびベストプラクティスです。

1.3. サービス指向アーキテクチャーの重要なポイント

以下は、サービス指向のアーキテクチャーの主要なコンポーネントです。
  1. 交換される メッセージ
  2. サービスリクエスターおよびプロバイダーとして動作する エージェント
  3. メッセージを送受信できるようにする 共有トランスポートメカニズム

1.4. JBoss Enterprise SOA Platform とは

JBoss Enterprise SOA Platform は、エンタープライズアプリケーションインテグレーション (EAI) およびサービス指向アーキテクチャー (SOA) ソリューションを開発するためのフレームワークです。これは、エンタープライズサービスバス (JBoss Warehouse) およびビジネスプロセス自動化インフラストラクチャーで設定されます。これにより、ビジネスサービスの構築、デプロイ、統合、オーケストレーションを行うことができます。

1.5. Service-Oriented Architecture Paradigm

SOA (Service-ient Architecture)は、リクエスター、プロバイダー、およびブローカーの 3 つのロールで設定されます。
サービスプロバイダー
サービスプロバイダーはサービスへのアクセスを許可し、サービスの説明を作成し、サービスブローカーに公開します。
サービスリクエスター
サービスリクエスターは、サービスブローカーが提供するサービスの説明を検索して、サービスを検出します。リクエスターはサービスプロバイダーが提供するサービスにバインドするロールも果たします。
サービスブローカー
サービスブローカーは、サービスの説明のレジストリーをホストします。リクエスターをサービスプロバイダーにリンクします。

1.6. コアおよびコンポーネント

JBoss Enterprise SOA Platform は、データ統合のニーズに対応する包括的なサーバーを提供します。基本的なレベルでは、Enterprise Service Bus を介してビジネスルールを更新し、メッセージをルーティングすることができます。
JBoss Enterprise SOA Platform の中心となるのは、Enterprise Service Bus です。JBoss (ESB) はメッセージの送受信を行う環境を作成します。メッセージにアクションを適用して変換し、サービス間でルーティングすることができます。
JBoss Enterprise SOA Platform を設定するコンポーネントは複数あります。ESB とともに、レジストリ (jUDDI)、変換エンジン (Smooks)、メッセージキュー (HornetQ)、BPEL エンジン (Riftsaw) が用意されています。

1.7. JBoss Enterprise SOA Platform のコンポーネント

  • 完全な Java EE 準拠のアプリケーションサーバー (JBoss Enterprise Application Platform)
  • Enterprise Service Bus (JBoss ESB)
  • ビジネスプロセス管理システム (jBPM)
  • ビジネスルールエンジン (JBoss ルール)
  • オプションの JBoss Enterprise Data Services (EDS) 製品のサポート。

1.8. JBoss Enterprise SOA Platform の機能

JBoss Enterprise Service Bus (ESB)
ドメインはサービス間でメッセージを送信し、それらを変換して、異なるタイプのシステムで処理できるようにします。
Business Process Execution Language (BPEL)
Web サービスを使用して、この言語を使用してビジネスルールをオーケストレーションできます。これは、ビジネスプロセス命令を簡単に実行するために SOA に含まれています。
Java Universal Description、Discovery and Integration (jUDDI)
これは SOA のデフォルトサービスレジストリーです。ここで説明する内容は、インストラクター上のサービスに関する情報をすべて保管する場所です。
Smooks
この変換エンジンは SOA と組み合わせて使用してメッセージを処理できます。また、メッセージを分割して正しい宛先に送信するためにも使用できます。
JBoss ルール
これは、SOA にパッケージ化されたルールエンジンです。受信するメッセージからデータを推測して、実行する必要があるアクションを判別できます。

1.9. JBoss Enterprise SOA Platform の JBossESB コンポーネントの機能

JBoss Enterprise SOA Platform の JBossESB コンポーネントは以下をサポートします。
  • 複数のトランスポートおよびプロトコル
  • リスナーアクションモデル (これにより、サービスを相互に選択可能)
  • コンテンツベースのルーティング (JBoss Rules エンジン、XPath、Regex、および Smooks 経由)
  • サービスオーケストレーション機能を提供するために JBoss Business Process Manager (jBPM) との統合
  • ビジネスルールの開発機能を提供するために、JBoss ルールとの統合
  • BPEL エンジンとの統合。
さらに、新しいデプロイメントにレガシーシステムを統合し、同期または非同期で通信できるようにします。
さらに、エンタープライズサービスバスは、以下を可能にするインフラストラクチャーおよびツールセットを提供します。
  • さまざまなトランスポートメカニズム (電子メールや JMS など) と連携するよう設定されます。
  • 汎用オブジェクトリポジトリーとして使用します。
  • プラグ可能なデータ変換メカニズムを実装できるようにします。
  • 対話のロギングをサポートします。
重要
ソースコードには、org.jboss.internal.soa.esborg.jboss.soa.esb の 2 つのツリーがあります。org.jboss.internal.soa.esb パッケージの内容をそのまま使用します。これは、通知なしに変更される可能性があるためです。これとは対照的に、org.jboss.soa.esb パッケージ内のすべての内容は、Red Hat の非推奨ポリシーでカバーされます。

1.10. タスク管理

JBoss SOA は、影響を受けるすべてのシステムで汎用的に実行するタスクを指定することにより、タスクを簡素化します。つまり、ユーザーは各ターミナルで個別に実行するようにタスクを設定する必要はありません。ユーザーは、Web サービスを使用してシステムを簡単に接続できます。
JBoss SOA を使用して各マシンに複数回ではなく、ネットワーク全体でトランザクションを 1 回委譲することで、時間を節約できます。これにより、エラーが発生する可能性も低くなります。

1.11. 統合のユースケース

ACME Equity は、大規模な経理サービスです。会社には多くのデータベースやシステムがあります。旧式の COBOL ベースのレガシーシステムや、近年で小規模な企業で取得されるデータベースもあります。ビジネスルールが頻繁に変化するため、これらのデータベースを統合することは困難でコストがかかります。会社は、クライアント向け e-commerce の Web サイトを新たに開発することを希望していますが、現在使用している既存のシステムとは同期しない場合があります。
会社は、安価なソリューションを希望していますが、企業セクターの厳密な規制およびセキュリティー要件に準拠するソリューションを検討しています。会社が望ましくないことは、レガシーデータベースおよびシステムを接続するために glob コードを作成および維持する必要があることです。
JBoss Enterprise SOA Platform は、これらのレガシーシステムを新しいお客様の Web サイトに統合するためにミドルウェアレイヤーとして選択されました。フロントエンドシステムとバックエンドシステムの間のブリッジを提供します。JBoss Enterprise SOA Platform で実装されたビジネスルールは、すぐに簡単に更新できます。
その結果、SOA の統合方法により、古いシステムは新しいシステムと同期できるようになりました。1 カ月あたり数万のトランザクションであっても、ボトルネックはありません。XML、JMS、FTP などのさまざまな統合タイプは、システム間でデータを移動するために使用されます。数多くのエンタープライズ標準のメッセージングシステムの 1 つを JBoss Enterprise SOA Platform にプラグインすることで、柔軟性を高めることができます。
さらに利点は、既存のインフラストラクチャーにより多くのサーバーやデータベースが追加されると、システムを簡単にスケールアップできることです。

1.12. ビジネス環境での JBoss Enterprise SOA Platform の使用

エラーメッセージが発生する可能性が低いサービスの実装により、コストを削減できます。生産性とソーシングオプションの強化により、継続的なコストを削減できます。
情報およびビジネスプロセスは、接続が増加するため、迅速に共有できます。これは Web サービスによって強化され、クライアントを簡単に接続するために使用できます。
レガシーシステムは Web サービスと組み合わせて使用して、異なるシステムが同じ言語にピークにすることができます。これにより、システムの同期に必要なアップグレードおよびカスタムコードの量が減ります。

パート I. はじめに

第2章 前提条件

2.1. 本ガイドの対象者

このガイドは、JBoss Enterprise SOA Platform でソリューションを構築する際に利用可能なすべてのオプションの包括的なガイドを必要とする開発者を対象としています。

2.2. 本ガイドの目的

このドキュメントは、サービスを開発し、エンドポイントを JBoss Enterprise SOA Platform と統合する方法を説明しています。また、理論と実際の例を紹介し、その際に重要な用語を定義しています。システムを統合するために、事前にパッケージ化されたアクションとカスタマイズされたアクションの両方を備えたサービスの開発と、デコーダー、ゲートウェイ、およびコネクターの使用について詳しく説明します。

2.3. データのバックアップ

警告
Red Hat は、本ガイドに記載されている設定タスクを行う前に、システム設定とデータのバックアップを行うことを推奨します。

2.4. Red Hat ドキュメントサイト

Red Hat の公式ドキュメントサイトは、https://access.redhat.com/knowledge/docs/ です。上記のサイトには、本書を含め、最新版の全ドキュメントが含まれています。

2.5. 変数名:SOA_ROOT ディレクトリー

SOA Root (SOA_ROOT として記述される) は、アプリケーションサーバーファイルが含まれるディレクトリーに指定された用語です。JBoss Enterprise SOA Platform パッケージの標準バージョンでは、SOA root は jboss-soa-p-5 ディレクトリーです。ただし、スタンドアロン編集では、jboss-soa-p-standalone-5 ディレクトリーになります。
ドキュメント全体で、このディレクトリーは頻繁に SOA_ROOT と呼ばれます。この名前がある場合は、必要に応じて jboss-soa-p-5 または jboss-soa-p-standalone-5 のいずれかを置き換えます。

2.6. 変数名: PROFILE

PROFILE は、JBoss Enterprise SOA Platform 製品に同梱されるサーバープロファイルの 1 つ (default、production、all、minimal、standard、または web) のいずれかになります。本書でファイルパスに PROFILE が表示されるたびに、使用しているこれらのいずれかを置き換えます。

第3章 JBoss エンタープライズ SOA プラットフォームの紹介

3.1. Enterprise Service Bus

Enterprise Service Bus は、抽象的な SOA 設計構想の具体的な実装です。Enterprise Service Bus (ESB) には、メッセージルーティング機能を提供するロールと、サービスを登録できるようにするロールの 2 つがあります。JBoss Enterprise SOA Platform の中心にあるEnterprise Service Bus は、JBoss ESB と呼ばれます。
Enterprise Service Bus は、ビジネスロジックではなくインフラストラクチャーロジックを扱います (ビジネスロジックはより高いレベルに任せられます)。データは、Enterprise Service Bus を介して 2 つ以上のシステム間を移動します。メッセージキューが含まれる場合と含まれない場合があります。ESB は、データを宛先に渡す前に変換エンジンに渡すこともできます。

3.2. Enterprise Service Bus のコアコンポーネント

Enterprise Service Bus は、4 つの主要なアーキテクチャーコンポーネントの上に構築されています。以下のとおりです。
メッセージリスニングとメッセージフィルタリングのコード
メッセージリスナーは、インバウンドメッセージ (JMS キューまたはトピック、ファイルシステムなど) をリッスンするルーターとして機能します。次に、メッセージを処理パイプラインに提示します。処理パイプラインは、メッセージをフィルタリングして (アウトバウンドルーター経由で) 別のメッセージエンドポイントにルーティングします。
データ変換コンポーネント
これらは Smooks と XSLT に基づいています。
コンテンツベースルーター
このルーターでは、本文の情報からメッセージの宛先を推測します。
メッセージリポジトリー
これは、ESB 経由で交換されたメッセージやイベントを保存するために使用されます。
これらのコンポーネントは、一連のビジネスクラス、アダプター、およびプロセッサーで設定されています。
クライアントサービスの対話は、JMS、フラットファイルシステム、電子メールなど、さまざまなアプローチによって促進されます。

3.3. EDS と JBoss Enterprise SOA Platform の統合

JBoss Enterprise Data Services は、JBoss Enterprise SOA Platform のスーパーセットです。EDS は JBoss Enterprise SOA Platform を強化および拡張し、以下を使用してデータアクセス、統合、および抽象化に対応します。
  • サービス指向アーキテクチャーのパターンとベストプラクティス
  • レポートと分析の有効化
  • マスターデータサービス
  • データのガバナンスとコンプライアンス
  • 異種データストアへのリアルタイムの読み取りおよび書き込みアクセス
  • 分散データへのアクセスを簡素化することによる迅速なアプリケーション開発
  • アクセス制御と監査の一元化

3.4. Enterprise Data Services の概要

完全なEnterprise Data Services (EDS) ソリューションは、次のもので設定されます。
EDS サービス
EDS サービスは、ビジネスアプリケーションと 1 つ以上のデータソースの間に配置されます。これらのデータソースの統合を調整して、実行時にビジネスアプリケーションからアクセスできるようにします。
設計ツール
特定のデータ統合ソリューションに向けた EDS サービス設定時のユーザー支援に、さまざまな設計ツールが利用可能です。
管理ツール
管理者は、デプロイメントされた EDS サービスを設定および監視するために、さまざまな管理ツールを使用できます。

図3.1 Enterprise Data Services の概要

Enterprise Data Services の概要

3.5. Enterprise Data Services を使用した開発

JBoss Enterprise Data Services 製品は、JDBC ドライバーまたは Web サービスを介して公開されます。ESB サービスは、どちらの方法でも消費できます。
EDS 仮想データベース (VDB) の JDBS 接続文字列は、通常の JDBC 接続文字列とは異なることに注意してください。これは、EDS 仮想データベース JBDC 接続文字列の正しい形式 (jdbc:teiid:vdb_name@mm://localhost:31000) です。

パート II. 仮説

第4章 サービスとメッセージ

4.1. サービス

4.1.1. サービス

サービスは、ESB メッセージを順次処理するアクションクラスのリストです。各サービス要素は、1 つ以上のリスナーと 1 つ以上のアクションで構成されます。これらは jboss-esb.xml 設定ファイル内で設定されます。

4.1.2. アクションパイプライン

アクションパイプラインは、メッセージが処理されるアクションクラスのリストで構成されます。メッセージ処理時に実行するアクションを指定するために使用します。アクションは、メッセージを変換し、ビジネスロジックを適用できます。各アクションはメッセージをパイプラインの次のメッセージに渡すか、プロセスの最後に ReplyTo アドレスで指定されたエンドポイントリスナーに送信します。
アクションパイプラインは、通常の処理とそれに続く結果処理の 2 段階で機能します。最初のステージでは、パイプラインは、パイプラインの最後に到達するかエラーが発生するまで、各アクション (デフォルトではプロセスと呼ばれます) でプロセスメソッドを順番に呼び出します。この時点で、パイプラインは反転し (第 2 段階)、前の各アクションで結果メソッドを呼び出します (デフォルトでは、processException または processSuccess)。現在のアクション (成功した場合の最後のアクションまたは例外を発生させたアクション) から開始し、パイプラインの先頭に到達するまで逆方向に移動します。

4.1.3. ESB 対応

アプリケーションクライアントとサービスが ESB 対応である場合には、SOA プラットフォームのEnterprise Service Bus で使用されるメッセージ形式とトランスポートプロトコルを理解できます。

4.1.4. メッセージリスナー

メッセージリスナーは、SB 対応メッセージの受信に必要な通信エンドポイントをカプセル化します。リスナーはサービスによって定義され、そのロールはキューを監視します。これらのキューに到着すると、メッセージを受信します。リスナーがメッセージを受信すると、ESB サーバーはアクション定義で指定された適切なアクションクラスを呼び出します。このクラスのメソッドはメッセージを処理します。つまり、リスナーは受信ルーターとして機能し、メッセージをアクションパイプラインに送信します。パイプラインのアクションによってメッセージが変更されると、リスナーは結果を replyTo エンドポイントに送信します。
リスナーのさまざまなパラメーターを設定できます。たとえば、アクティブなワーカースレッドの数を設定できます。
リスナーには、ESB 対応リスナーとゲートウェイリスナーの 2 種類があります。ゲートウェイリスナーは、さまざまな形式のデータ (ファイル内のオブジェクト、SQL テーブル、JMS メッセージなど) を受け入れるという点で、ESB 対応のリスナーとは異なります。次に、これらの形式から ESB メッセージング形式に変換します。対照的に、ESB 対応のリスナーは、org.jboss.soa.esb.message.Message 形式のメッセージのみを受け入れることができます。各ゲートウェイリスナーには、対応する ESB リスナーが定義されている必要があります。
ESB 対応のリスナーでは、RuntimeExceptions がロールバックをトリガーできます。対照的に、ゲートウェイリスナーでは、トランザクションは単純にメッセージを JBoss ESB に送信します。その後、メッセージは非同期的に処理されます。このようにして、メッセージの失敗はメッセージの受信から分離されます。

4.1.5. ServiceInvoker

ServiceInvoker (org.jboss.soa.esb.client.ServiceInvoker) は、指定されたサービスへのメッセージの配信を管理します。また、エンドポイント参照の読み込みと courier の選択も管理するため、メッセージ配信用に一元的なインターフェイスを提供します。
ServiceInvoker は、下位レベルの詳細の多くを非表示にして、ステートレスサービスのフェイルオーバーメカニズムと背後で連携できるので、開発作業を簡素化するために導入されました。そのため、ServiceInvoker は JBoss Enterprise SOA Platform 内でのサービスの使用に推奨されるクライアント側インターフェイスです。
クライアントが対話するサービスごとに ServiceInvoker のインスタンスを作成できます。インスタンスが作成されると、レジストリーを調べてプライマリーエンドポイント参照を特定し、フェイルオーバーの場合は代替エンドポイント参照を特定します。

4.1.6. InVM トランスポート

InVM (仮想マシン内) トランスポートは、同じ JVM で実行されているサービス間の通信を提供します。

4.1.7. 最初のサービスの作成

以下は、非常に単純な JBoss ESB 設定で、メッセージの内容をコンソールに出力する単一のサービスを定義します。
<?xml version = "1.0" encoding = "UTF-8"?>
<jbossesb
xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd">

<services>
    <service category="Retail" name="ShoeStore" description="Acme Shoe Store
Service" invmScope="GLOBAL">
        <actions>
            <action name="println"
class="org.jboss.soa.esb.actions.SystemPrintln" />
        </actions>
     </service>
</services>

</jbossesb>
サービスにはカテゴリー属性と名前属性があります。JBoss ESB がサービスをデプロイすると、これらの属性を使用してリスナーを Service Registry に登録します。クライアントは、次のサンプルに従って ServiceInvoker を使用してサービスを呼び出すことができます。
ServiceInvoker invoker = new ServiceInvoker(“Retail”, “ShoeStore”);
Message message = MessageFactory.getInstance().getMessage();

message.getBody().add(“Hi there!”);
invoker.deliverAsync(message);
ServiceInvoker は、Services Registry を使用して、Retail:ShoeStoreサービスの利用可能なエンドポイントアドレスを検索します。レジストリーは、クライアントから使用可能なエンドポイントの 1 つにメッセージを送信するプロセスを自動的に処理します。メッセージを転送するプロセスは、クライアントに対して完全に透過的です。
ServiceInvoker で使用できるエンドポイントアドレスは、JMS、FTP、HTTP などのサービスで設定されたリスナーのリストによって異なります。上記の例では、サービスにリスナーは設定されていませんが、その InVM リスナーは invmScope="GLOBAL"1 を使用して有効化されています。サービスにエンドポイントを追加するには、それらを明示的に追加する必要があります。

4.1.8. メッセージリスナーの種類

メッセージリスナーには次の 2 種類があります。
ゲートウェイリスナー
このタイプのリスナーは、ESB に対応していないメッセージを ESB バスにプッシュするために使用されるゲートウェイエンドポイントを設定します。アクションパイプラインに送信する前に、メッセージを ESB メッセージ内にラップすることで、メッセージを ESB が理解できる形式に変更します。
ESB 対応リスナー
このタイプのリスナーは、ESB 対応エンドポイントを作成し、ESB 対応コンポーネント間で ESB メッセージを交換するために使用されます。

4.1.9. ゲートウェイリスナー

ゲートウェイリスナーは、ESB 認識の世界と ESB 非認識の世界を橋渡しするために使用されます。これは、外部 (ESB 非対応) エンドポイント経由で到着した ESB に対応していないメッセージのキューをリッスンするように設計された特殊なリスナープロセスです。メッセージがキューに到着すると、ゲートウェイリスナーがメッセージを受信します。ゲートウェイリスナーが受信データの到着を認識すると、そのデータ (ESB に対応していないメッセージ) を org.jboss.soa.esb.message.Message 形式に変換します。この変換は、ゲートウェイの種類に応じてさまざまな方法で行われます。変換が行われると、ゲートウェイリスナーはデータを正しい宛先にルーティングします。

4.1.10. サービスへのゲートウェイリスナーの追加

このコードは、JMS ゲートウェイリスナーをサービスに追加する方法を示しています。
<?xml version = "1.0" encoding = "UTF-8"?>
<jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/
                                       trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd">
<providers>
    <jms-provider name="JBossMQ" connection-factory="ConnectionFactory">
        <jms-bus busid="shoeStoreJMSGateway">
            <jms-message-filter dest-type="QUEUE" dest-name="queue/shoeStoreJMSGateway"/>
        </jms-bus>
    </jms-provider>
</providers>

<services>
    <service category="Retail" name="ShoeStore" description="Acme Shoe Store Service"             
                                                                   invmScope="GLOBAL">
<listeners>
    <jms-listener name="shoeStoreJMSGateway" busidref="shoeStoreJMSGateway" 
                  is-gateway="true"/>
</listeners>
        <actions>
            <action name="println" class="org.jboss.soa.esb.actions.SystemPrintln" />
        </actions>
     </service>
</services>

</jbossesb>
バスの <providers> セクションが設定に追加されていることを確認します。ここで、エンドポイントのトランスポートレベルの詳細を設定できます。この場合、<jms-provider> セクションが追加されています。その目的は、Shoe Store JMS キュー用に単一の <jms-bus> を定義することです。次にこのバスは、Shoe Store Service で定義された <jms-listener> で参照されます。Shoe Store は、InVM および JMS Gateway エンドポイントを介して「呼び出し可能」になりました。(ServiceInvoker は、サービスのローカル InVM エンドポイントが利用可能な場合、常にそちらが優先的に使用されます。)

4.2. メッセージ

4.2.1. ESB メッセージ

このメッセージは、 org.jboss.soa.esb.message インターフェイスによって定義された形式を取得するメッセージです。この標準化された形式は、ヘッダー、本文 (ペイロード)、および添付ファイルで設定されます。すべての ESB 対応のクライアントとサービスは、メッセージを使用して相互に通信します。

4.2.2. ESB メッセージのコンポーネント

ESB メッセージは、次のコンポーネントで設定されています。
Header
ヘッダーには、宛先エンドポイント参照、送信者エンドポイント参照、および応答先などの情報が含まれています。これはすべて、一般的なメッセージレベルの機能情報です。
コンテキスト
これは、メッセージをさらに説明する追加情報です。たとえば、トランザクションまたはセキュリティーデータ、最終的な受信者の ID、HTTP クッキー情報などです。
本文
メッセージの実際の内容。
異常
メッセージに関連付けられたエラー情報。
添付ファイル
メッセージに関連付けられた添付ファイル (追加ファイル)。
プロパティー
メッセージ固有のプロパティー (たとえば、 jbossesb.message.idプロパティーは、メッセージごとに一意の値を指定します)。
コード表現は次のとおりです。
    <xs:complexType name="Envelope">
	<xs:attribute ref="Header" use="required"/>
	<xs:attribute ref="Context" use="required"/>
	<xs:attribute ref="Body" use="required"/>
	<xs:attribute ref="Attachment" use="optional"/>
	<xs:attribute ref="Properties" use="optional"/>
	<xs:attribute ref="Fault" use="optional"/>
</xs:complexType>

4.2.3. メッセージオブジェクトをキューに送信する方法

概要

JBoss Enterprise SOA Platform 製品は、ローカルサーバー上の JNDI の存在を識別するためにパラメーターが設定されたプロパティーオブジェクトを使用します。次に、これは、新しいネーミングコンテキストを作成するための呼び出しのパラメーターとして使用されます。このネーミングコンテキストを使用して、ConnectionFactory を取得します。次に、ConnectionFactory が QueueConnection を作成し、これが QueueSession を作成します。この QueueSession は、Queue の Sender オブジェクトを作成します。Sender オブジェクトは、送信者の ObjectMessage を作成し、キューの送信に使用されます。

4.2.4. Message インターフェイス

各メッセージは org.jboss.soa.esb.message.Message インターフェイスの実装です。
        public interface Message
{
	public Header getHeader ();
	public Context getContext ();
	public Body getBody ();
	public Fault getFault ();
	public Attachment getAttachment ();
	public URI getType ();
	public Properties getProperties ();

	public Message copy () throws Exception;
}

4.2.5. メッセージヘッダー

メッセージのヘッダーには、メッセージの送信先アドレスが含まれています。また、ルーティング情報も含まれています。アドレス形式は、W3C の WS-Addressing 標準に基づいています。

4.2.6. メッセージヘッダーの形式

これは、メッセージヘッダーの形式です。
    public interface Header
{
	public Call getCall ();
	public void setCall (Call call);
}
メッセージヘッダーの内容は、org.jboss.soa.esb.addressing.Call クラスのインスタンスに含まれています。
    public class Call
{
	public Call ();
	public Call (EPR epr);
	public Call (Call copy);
	public void setTo (EPR epr);
	public EPR getTo () throws URISyntaxException;

	public void setFrom (EPR from);
	public EPR getFrom () throws URISyntaxException;

	public void setReplyTo (EPR replyTo);
	public EPR getReplyTo () throws URISyntaxException;

	public void setFaultTo (EPR uri);
	public EPR getFaultTo () throws URISyntaxException;

	public void setRelatesTo (URI uri);
	public URI getRelatesTo () throws URISyntaxException;
	public void copy();
	public void setAction (URI uri);
	public URI getAction () throws URISyntaxException;
	public final boolean empty();
	public void setMessageID (URI uri);
	public URI getMessageID () throws URISyntaxException;
	public String toString();
	public String stringForum();
	public boolean valid();
	public void copy (Call from);
}
org.jboss.soa.esb.addressing.Call クラスは、一方向および要求と応答の両方の相互作用パターンをサポートします。

表4.1 org.jboss.soa.esb.addressing.Call プロパティー

プロパティー タイプ 必須 Description
終了 EPR はい メッセージ受信者のアドレス。
From EPR いいえ メッセージの発信元のエンドポイント。
ReplyTo EPR いいえ このメッセージへの返信が送られる受信者を識別するエンドポイント参照。返信が必要な場合は、メッセージに ReplyTo が含まれている必要があります。送信者は、ReplyTo の内容を使用して返信メッセージを作成する必要があります。ReplyTo が存在しない場合には、From の内容を使用してソースへのメッセージを作成できます。メッセージに意味のある返信がない場合には、このプロパティーは存在しない可能性があります。このプロパティーが存在する場合、MessageID プロパティーは必須です。
FaultTo EPR いいえ このメッセージに関する問題が送られる受信者を識別するエンドポイント参照。障害メッセージを作成する場合には、送信者は、応答するメッセージの FaultTo の内容を使用して、障害メッセージを作成する必要があります。FaultTo が存在しない場合、送信者は ReplyTo の内容を使用して障害メッセージを作成できます。FaultTo と ReplyTo の両方が存在しない場合には、送信者は From の内容を使用して障害メッセージを作成できます。送信者が障害メッセージを受信できない場合 (たとえば、一方向のアプリケーションメッセージである場合)、このプロパティーは存在しない可能性があります。このプロパティーが存在する場合、MessageID プロパティーは必須です。
アクション URI はい このメッセージが意味するセマンティクスを一意に (そして不透明に) 区別する識別子。
MessageID URI 状況により異なる このメッセージを時間と空間で一意に識別する URI。アプリケーションのインテントが異なる 2 つのメッセージでは、[MessageID] プロパティーを共有できません。メッセージは、通信障害など、あらゆる目的で再送信される可能性があり、同じ MessageID プロパティーを使用する可能性があります。このプロパティーの値は、同等以上の解釈が定義されていない不透明な URI です。返信が必要な場合は、このプロパティーが存在する必要があります。
サービスを開発および使用するときは、ヘッダーのロールを常に考慮してください。たとえば、リクエストとレスポンスに基づく同期対話パターンが必要な場合は、必ずReplyTo フィールドまたはデフォルトのエンドポイント参照を使用するようにしてください。リクエスト/レスポンスであっても、レスポンスを元の送信者に戻す必要はありません。同様に、一方向 (応答なし) のメッセージを送信する場合は、ReplyTo フィールドは無視されるので、設定しないでください。
警告
EPR の内部形式は API の実装に固有のものであるため、EPR の内部形式に直接依存しないようにしてください。この形式を同じ状態で確保できる保証はありません。
注記
メッセージヘッダーは、メッセージと共に形成されます。エンドポイント間で転送されると、不変になります。インターフェイスは受信者が個々の値を変更できるようにしますが、JBoss Enterprise SOA Platform はそのような変更を無視します。(今後のリリースでは、アプリケーションプログラミングインターフェイスでも、明確性を向上するため、このような変更が禁止される可能性があります。) これらの規則は、WS-Addressing 標準に記載されています。

4.2.7. To フィールド

メッセージを送信するときに、メッセージヘッダーの To フィールドの値を指定できます。このフィールドには、メッセージ受信者のアドレスが含まれている必要があります。
ServiceInvoker を使用する場合には、構築時にすでにレジストリーに接続しているため、To フィールドは不要です。実際、ServiceInvoker を介してメッセージを送信する場合には、To フィールドは同期配信モードと非同期配信モードの両方で無視されます。

4.2.8. メッセージコンテキスト

メッセージコンテキストには、セッション関連の情報が含まれています。これには、トランザクションおよびセキュリティーデータが含まれる場合があります。独自のユーザー拡張コンテキストを作成することもできます。

4.2.9. メッセージボディー

メッセージの本文には、メッセージのペイロードが含まれています。
警告
シリアル化されたオブジェクトをメッセージボディーとの間で送受信する場合は、細心の注意を払ってください。シリアル化できるからといって、受信側で有用であるとは限りません。これは、データベース接続で発生します。

4.2.10. メッセージペイロード

メッセージペイロードは、メッセージの本文、添付ファイル、およびプロパティーの組み合わせです。ペイロードは、任意のオブジェクトのリストで設定されている場合があります。メッセージの送信時にこれらのオブジェクトがどのようにシリアライズされるかは、オブジェクトのタイプによって決まります。

4.2.11. シリアライズ

オブジェクトをシリアル化することは、オブジェクトをデータオブジェクトに変換することです。

4.2.12. メッセージボディーの形式

メッセージボディーは次のようになります。
  public interface Body
{
  public static final String DEFAULT_LOCATION = 
  "org.jboss.soa.esb.message.defaultEntry";

	public void add (String name, Object value);
	public Object get (String name);
	public byte[] getContents();
	public void add (Object value);
	public Object get ();
	public Object remove (String name);
	public void replace (Body b);
	public void merge (Body b);
  public String[] getNames ();
}
重要
メッセージボディーのバイト配列コンポーネントは非推奨です。本体に格納されている他のデータと組み合わせてバイト配列を引き続き使用するには、addオプションを付けて、一意の名前を付けます。クライアントとサービスがバイト配列の場所を必要とする場合には、JBoss ESB 自体が使用するもの (ByteBody.BYTES_LOCATION) を使用できます。
警告
複数のサービスとアクションがお互いのデータを上書きしないように、デフォルトの名前がつけられたオブジェクト (DEFAULT_LOCATION) は注意して使用してください。

4.2.13. メッセージ障害

メッセージ障害では、メッセージボディーの情報で問題があります。

4.2.14. 障害メッセージの形式

これは、障害を示すメッセージの形式です。
  public interface Fault
{
	public URI getCode ();
	public void setCode (URI code);
	
	public String getReason ();
	public void setReason (String reason);
	
	public Throwable getCause ();
	public void setCause (Throwable ex);
}

4.2.15. メッセージのプロパティー

これらのメッセージプロパティーを使用して、メッセージに追加のメタデータを追加します。
  public interface Properties
{
	public Object getProperty(String name);
	public Object getProperty(String name, Object defaultVal);
	
	public Object setProperty(String name, Object value);
	public Object remove(String name);
	
	public int size();
	public String[] getNames();
}
注記
java.util.Properties を使用する properties は、JBoss Enterprise Service Bus 内に実装されていません。これは、使用できるクライアントとサービスの種類が制限されるためです。Web サービススタックは、同じ理由でそれらを実装しません。この制限に対処するには、現在の抽象化内に java.util.Properties を組み込む必要があります。

4.2.16. メッセージ添付

添付ファイルは、メッセージにバンドルされているファイルです。メッセージボディーには表示されません。バイナリー形式および圧縮ファイルのイメージとドキュメントを含めることができます。
添付ファイルを使用する理由はいくつかあります。これらは通常、メッセージにより論理的な構造を提供するために使用されます。また、エンドポイント間でストリーミングできるため、大きなメッセージを処理する際のパフォーマンスを向上させる方法も提供します。

4.2.17. メッセージ添付インターフェイス

このインターフェイスを使用して、メッセージに添付ファイルを追加します。
  public interface Attachment
{
	Object get(String name);
	Object put(String name, Object value);
	
	Object remove(String name);
	
	String[] getNames();
	
	Object itemAt (int index) throws IndexOutOfBoundsException;
	Object removeItemAt (int index) throws IndexOutOfBoundsException
	Object replaceItemAt(int index, Object value)
	throws IndexOutOfBoundsException;
	
    void addItem		(Object value);
	void addItemAt	(int index, Object value)
									throws IndexOutOfBoundsException;
	public int getUnnamedCount();
	public int getNamedCount();
}
注記
現在、JBossESB ではメッセージまたは添付ファイルのストリーミングに別のエンコーディングメカニズムを指定できません。したがって、現在、添付ファイルはボディー内の名前付きオブジェクトと同じ方法で処理されます。

4.2.18. 適切な方法の選択

ペイロードを配置する場所を決定する時に、添付ファイル、プロパティー、および名前付きオブジェクトのいずれかを選択する必要がある場合に、圧倒されてしまうかもしれませんが、簡単に判断を下すことができます。
  • 開発者は、クライアントがサービスと対話するために使用するコントラクトを定義します。その契約の一部として、航空券予約サービス (機能的) や本質的なトランザクション (非機能的) など、サービスの機能面と非機能面の両方を指定します。
    開発者は、サービスが理解できる操作 (メッセージ) も定義します。形式 (Java Serialized Message または XML など) は、メッセージ定義の一部として定義されます。(この例の場合、それらはトランザクションコンテキスト、座席番号、顧客名などになります。) コンテンツを定義するときに、サービスがペイロードを見つけることができるメッセージの中の場所を指定できます。(これは、添付ファイルまたは特定の名前付きオブジェクトの形式にすることも、必要に応じてデフォルトの名前付きオブジェクトにすることもできます。) 決定するのは完全にサービス開発者次第です。唯一の制限は、オブジェクトと添付ファイルにはグローバルに一意の名前を付ける必要があることです。そうしないと、1 つのサービスまたはアクションが別のサービスまたはアクションのペイロードの一部を誤って取得する可能性があります (同じメッセージボディーが複数のホップで転送されている場合)。
  • ユーザーは、メッセージ内のどこにペイロードを配置する必要があるかを定義するサービスのコントラクト定義を (UDDI レジストリーまたは帯域外通信のいずれかを介して) 取得できます。他の場所に置かれた情報はほぼ確実に無視され、サービスが正しく動作しなくなります。

4.2.19. メッセージボディーへのデータの追加に関するアドバイス

デフォルトでは、すべてのコンポーネント (アクション、リスナー、ゲートウェイ、ルーター、通知機能を含む) が MessagePayloadProxy を介してメッセージにデータを設定します。このクラスはデフォルト設定を処理しますが、デフォルトをオーバーライドすることもできます。
または、次のプロパティーを設定して、get および set 設定をオーバーライドすることもできます。
  • get-payload-location: メッセージペイロードを取得する場所です。
  • set-payload-location: メッセージペイロードの場所です。
add メソッドを使用して、より複雑なコンテンツをペイロードに添付し、名前付きオブジェクトをサポートできます。<name、Object> ペアを使用すると、データアクセスの粒度を細かくすることができます。任意のオブジェクトをペイロードに追加できます。Java シリアライズ可能である必要はありません。ただし、シリアル化できないオブジェクトを追加する場合は、JBoss Enterprise SOA Platform にメッセージがネットワーク上を流れるときにマーシャリングおよびアンマーシャリング機能を提供する必要があります。
注記
設定または取得に名前が指定されていない場合は、DEFAULT_LOCATION 設定が利用されます。
注記
サービスの実装を制約するため、シリアライズされた Java オブジェクトをメッセージで使用する場合は注意してください。
名前付きオブジェクトアプローチを使用してメッセージボディーを操作するのが最も簡単です。メッセージボディー全体をデコードすることなく、個々のデータ項目を追加、削除、および検査できます。さらに、名前付きオブジェクトをペイロード内のバイト配列と組み合わせることができます。
注記
JBoss Enterprise SOA Platform の現在のリリースでは、Java シリアライズオブジェクトのみをアタッチできます。この制限は、後続のリリースで削除される可能性があります。

4.2.20. レガシーメッセージペイロード Exchange の設定

JBoss Enterprise SOA Platform のバージョン 4.2 には、デフォルトのメッセージペイロードのエクスチェンジパターンがありませんでした。この方法を使用して、従来のサポートを提供します。

手順4.1 タスク

  1. jbossesb-properties.xml ファイルをテキストエディターで開きます (vi SOA_ROOT/jboss-soa-p-5/jboss-as/server/PROFILE/deploy/jbossesb.sar/jbossesb-properties.xml)。
  2. コアというタイトルのセクションまでスクロールします。
  3. use.legacy.message.payload.exchange.patterns プロパティーを true に設定します。
  4. ファイルを保存して終了します。

4.2.21. メッセージボディーの拡張

拡張機能の種類

org.jboss.soa.esb.message.body.content.TextBody
Body のコンテンツは任意の文字列であり、getText および setText メソッドを介して操作できます。
org.jboss.soa.esb.message.body.content.ObjectBody
ボディーのコンテンツはシリアル化されたオブジェクトで、getObject および setObject メソッドを介して操作できます。
org.jboss.soa.esb.message.body.content.MapBody
ボディーのコンテンツはマップ (String、Serialized) で、setMap およびその他のメソッドを介して操作できます。
org.jboss.soa.esb.message.body.content.BytesBody
本体の内容は、任意の Java データ型を含むバイトストリームです。データ型のさまざまなセッターおよびゲッターメソッドを使用して操作できます。BytesMessage を作成したら、必要な操作方法に応じて、読み取り専用モードまたは書き込み専用モードに設定する必要があります。これらのモードを (readMode と writeMode を使用して) 切り替えることは可能ですが、モードが変更されるたびにバッファーポインターがリセットされます。すべての更新がボディーにプッシュされたことを確認するには、終了時にフラッシュを呼び出す必要があります。
XMLMessageFactory または SerializedMessageFactory クラスを介して、これらの特定のインターフェイスのいずれかに基づいてボディーを実装したメッセージを作成できます。
各種ボディータイプごとに関連付けられた create メソッドがあります。たとえば、createTextBody などです。これを使用して、その特定のタイプのメッセージを作成および初期化します。作成したら、生のボディーを編集するか、インターフェイスのメソッドを使用して、メッセージを直接操作します。ボディーの構造は送信後も維持されるため、メッセージ受信者はそれを作成したインターフェイスのメソッドを使用して操作できます。
XMLMessageFactory と SerializedMessageFactory は、MessageFactory と関連するクラスよりもメッセージを操作するのに便利な方法です。
注記
ベースボディインターフェイスへのこれらの拡張は、元のボディーを補完する形で指定します。そのため、既存のクライアントやサービスと組み合わせて使用できます。メッセージ内の基礎となるデータ構造は変更されないため、メッセージコンシューマーは、必要に応じてこれらの新しい型を認識しないままにすることができます。これらの拡張機能は、デフォルトの場所にデータを保存しないことに注意してください。データは、拡張インスタンスの対応するゲッターを使用して取得する必要があります。

4.2.22. エンドポイント参照

エンドポイント参照 (EPR) には、サービスのアドレス情報と技術仕様が含まれています。実際には、すべてのサービスに対応するサービスは、エンドポイント参照を使用して識別されます。これらの参照を通じて、サービスが問い合わせられます。これらはレジストリーに保存されます。サービスは、起動時にレジストリーにエンドポイント参照を追加し、終了時に自動的にそれらを削除する必要があります。サービスには、複数のエンドポイント参照が含まれる場合があります。エンドポイントの参照は、バインディングテンプレートとも呼ばれます。
エンドポイントの参照には、特定のサービスのインターフェイス仕様を指定する tModels へのリンクを含めることができます。

4.2.23. 論理 EPR

論理 EPR は、サービスの名前とカテゴリーを指定するエンドポイント参照です。物理アドレス情報は含まれません。

4.2.24. 論理 EPR の使用

エンドポイント参照ユーザー (常にではありませんが、通常は Enterprise Service Bus 自体) に関する想定をしていないので、論理 EPR を使用することを最もお勧めします。 LogicalEPR のクライアントは、提供されたサービス名とカテゴリーの詳細を使用して、そのサービスの物理エンドポイントを検索できます。クライアントは、サービスの使用が目的である場合に検索します。クライアントは、状況に合わせて物理エンドポイントタイプを選択することもできます。

4.2.25. FaultTo フィールド

FaultTo フィールドには、エラーのあるメッセージの送信先アドレスが含まれています。設定しない場合は ReplyTo フィールドが使用されます。この ReplyTo フィールドが使用されない場合には From フィールドが使用されます。これらのフィールドをすべてチェックした結果、有効な EPR が取得されない場合は、コンソールにエラーが出力されます。エラーの通知を希望しない場合 (一方向のメッセージを送信している場合など)、FaultTo フィールドを DeadLetter Queue エンドポイント参照を指すように設定します。

4.2.26. Dead Letter Queue

Dead Letter Queue は、失敗したメッセージを送信できるエンドポイント参照です。ここで送信されたメッセージは、後で再処理するために保存されます。

4.2.27. ReplyTo フィールド

ReplyTo フィールドは、メッセージヘッダーのオプションフィールドです。メッセージの返信アドレス (またはエンドポイント参照) が含まれています。アプリケーションは、必要に応じてこのフィールドに入力するように設計する必要があります。(JBoss Enterprise SOA Platform の推奨される対話パターンは一方向のメッセージエクスちゃんじに基づいているため、メッセージは自動的に応答を受信しない場合があります。送信者が応答を期待するかどうかはアプリケーションにより決まります。)
応答が必要で ReplyTo フィールドが設定されていない場合、JBoss Enterprise SOA Platform はトランスポートの各タイプのデフォルト値に基づいて自動的に入力できます。(これらの ReplyTo デフォルトの一部を使用するには、システム管理者が JBoss Enterprise Service Bus の 動作を具体的に設定する必要があることに注意してください。)

4.2.28. ReplyTo フィールド設定の表

表4.2 トランスポートによるデフォルトの ReplyTo

トランスポート ReplyTo
JMS 元のリクエストの配信に使用された名前に基づいた名前のキュー: <request queue name>_reply。
JDBC 元のリクエストの配信に使用された名前に基づいた名前を持つ、同じデータベース内のテーブル: <request table name>_reply_table.新しいテーブルには、要求テーブルと同じ列が必要です。
files ローカルファイルでもリモートファイルでも、管理上の変更は必要ありません。応答は要求と同じディレクトリーに保存されますが、元の送信者だけが応答を取得できるように一意の接尾辞が付けられます。

4.2.29. メッセージのシリアル化に関するアドバイス

各エンタープライズサービスバスコンポーネントはすべてのメッセージを Java オブジェクトのコレクションとして扱いますが、多くの場合、これらのメッセージをシリアライズする必要があります。次の場合に行います。
  • データが保存される
  • メッセージが異なる ESB プロセス間で送信される
  • デバッグしている
JBoss Enterprise SOA Platform は、要件が各デプロイメントの固有の特性に影響されるので、メッセージのシリアライゼーションに特定の形式を 1 つ使用する必要はありません。org.jboss.soa.esb.message.format.MessageFactory クラスから org.jboss.soa.esb.message.Message インターフェイスのさまざまな実装を取得できます。
  public abstract class MessageFactory
{
	public abstract Message getMessage ();
	public abstract Message getMessage (URI type);
	public abstract void reset();
	public static MessageFactory getInstance ();
}
ユニフォームリソースインジケーターは、メッセージのシリアライゼーションの実装を一意に識別します。新しいインスタンスを作成するときに実装を指定するか、事前設定されたデフォルトを使用します。
シリアル化されたメッセージ形式には、JBOSS_XML と JBOSS_SERIALIZED の 2 つがあります。
MessageType.JBOSS_XML
この実装は、メッセージの XML 表現を使用します。メッセージのスキーマは、schemas/message.xsd ファイルで定義されます。任意のオブジェクトをメッセージに追加できます。つまり、シリアライズ可能である必要はありません。したがって、メッセージをシリアライズする必要がある場合に、そのようなオブジェクトを XML との間でマーシャリングおよびアンマーシャリングするメカニズムを提供する必要がある場合があります。org.jboss.soa.esb.message.format.xml.marshal.MarshalUnmarshalPlugin を介してこれを行います。
          public interface MarshalUnmarshalPlugin
{
	public static final String MARSHAL_UNMARSHAL_PLUGIN =
				 "org.jboss.soa.esb.message.format.xml.plugin";
	public boolean canPack(final Object value);
	public boolean marshal (Element doc, Object param)
											throws MarshalException;

	public Object unmarshal (Element doc) throws UnmarshalException;

	public URI type ();
}
MessageType.JAVA_SERIALIZED
これがデフォルトです。この実装では、メッセージのすべてのコンポーネントがシリアライズ可能である必要があります。また、メッセージの受信者が (Java クラスを介して) デシリアライズできる十分な情報を持っている必要があります。その URI は urn:jboss/esb/message/type/JAVA_SERIALIZED です。
メッセージの XML 表現を使用します。メッセージのスキーマは、schemas/message.xsd ファイルで定義されます。その URI は urn:jboss/esb/message/type/JBOSS_XML です。
また、すべてのコンテンツが Java シリアライズ可能である必要があります。シリアル化できないオブジェクトをメッセージに追加しようとすると、 IllegalParameterException エラーが発生します。
その URI は urn:jboss/esb/message/type/JAVA_SERIALIZED です。
重要
特定のサービス実装とお使いのアプリケーションを関連付けることができるので、メッセージ形式の JBOSS_SERIALIZED バージョンを使用する場合は注意してください。
org.jboss.soa.esb.message.format.MessagePlugin を介して実行時に他のメッセージ実装を提供できます。
    public interface MessagePlugin
{
	public static final String MESSAGE_PLUGIN =	
						 "org.jboss.soa.esb.message.format.plugin";
	public Object createBodyType(Message msg, String type);
	public Message getMessage ();
	public URI getType ();
}
各プラグインは、getType メソッドを使用して、(getMessage を介して) 提供するメッセージ実装のタイプを一意に識別する必要があります。プラグインの実装は、jbossesb-properties.xml ファイルを介してシステムに識別される必要があります。(org.jboss.soa.esb.message.format.plugin 拡張子を持つプロパティー名を使用します。)

4.2.30. デフォルトのメッセージタイプの変更

手順4.2 タスク

  1. org.jboss.soa.esb.message.default.uri プロパティーを任意の URI 名に設定します。(デフォルトは JBOSS_XML です。)
  2. ファイルを保存して終了します。

4.2.31. マーシャリングプラグインの登録

手順4.3 タスク

  1. jbossesb-properties.xml ファイルをテキストエディターで開きます (vi SOA_ROOT/jboss-soa-p-5/jboss-as/server/PROFILE/deploy/jbossesb.sar/jbossesb-properties.xml)。
  2. プラグインの名前を追加します。(MARSHAL_UNMARSHAL_PLUGIN という接頭辞で始まる必要があります。)
  3. ファイルを保存して終了します。

パート III. 開発

第5章 サービスの構築と使用

5.1. メッセージリスナーの設定プロパティー

リスナー 設定は、次の情報を提供する必要があります。
  • レジストリー (service-categoryservice-nameservice-description、および EPR-description タグ名を参照してください。) オプションの remove-old-service タグ名を true に設定すると、Enterprise Service Bus は registry から既存のサービスエントリーを削除して、この新規インスタンスを追加します。すべてのエンドポイント参照を含むサービス全体が削除されるため、この機能は常に注意して使用してください。
  • listener クラスのインスタンス化 (listenerClass タグ名を参照)。
  • リスナー が提供するエンドポイント参照。これはトランスポート固有です。次の例は、Java Message Service エンドポイント参照に対応しています (connection-factorydestination-typedestination-namejndi-typejndi-URL、および message-selector タグ名を参照してください)。
  • action pipeline。これには 1 つ以上の <action> 要素が必要で、それぞれに class タグ名が含まれている必要があります。これらにより、どの action クラスが chain の対象リンクに対してインスタンス化されるかが決まります。
  <?xml version = "1.0" encoding = "UTF-8"?>
<jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd" parameterReloadSecs="5">

<providers>
  <jms-provider name="JBossMQ" 
    connection-factory="ConnectionFactory"
    jndi-URL="jnp://127.0.0.1:1099" 
    jndi-context-factory="org.jnp.interfaces.NamingContextFactory"
    jndi-pkg-prefix="org.jboss.naming:org.jnp.interfaces">
    <jms-bus busid="quickstartGwChannel">
      <jms-message-filter dest-type="QUEUE" 
        dest-name="queue/quickstart_helloworld_Request_gw"/>
    </jms-bus>
    <jms-bus busid="quickstartEsbChannel">
      <jms-message-filter dest-type="QUEUE"
        dest-name="queue/quickstart_helloworld_Request_esb"/>
    </jms-bus>
  </jms-provider>
</providers>
      
<services>
  <service category="FirstServiceESB" 
    name="SimpleListener" description="Hello World">
    <listeners>
      <jms-listener name="JMS-Gateway" 
        busidref="quickstartGwChannel" maxThreads="1"
        is-gateway="true"/>
      <jms-listener name="helloWorld"
        busidref="quickstartEsbChannel" maxThreads="1"/>
    </listeners>

    <actions>
      <action name="action1" class="org.jboss.soa.esb.samples.
quickstart.helloworld.MyJMSListenerAction"
        process="displayMessage" />
      <action name="notificationAction" 
        class="org.jboss.soa.esb.actions.Notifier">
        <property name="okMethod" value="notifyOK" />
        <property name="notification-details"> 
          <NotificationList type="ok">
            <target class="NotifyConsole"/>
          </NotificationList>
          <NotificationList type="err">
            <target class="NotifyConsole"/>
          </NotificationList>
        </property>

     </action>    
   </actions>  
  </service>  
 </services>
</jbossesb>
この設定例では、listener オブジェクトをインスタンス化します (jms-listenerこれは、インターフェイス内でシリアル化された受信 ESB メッセージを待機します。次に、各受信メッセージを 2 つのステップ (<action> 要素) で構成される action pipeline に配信します。
  1. アクション1: MyJMSListenerAction (例を次に示します)。
  2. notificationAction: org.jboss.soa.esb.actions.SystemPrintln クラス。
リスナーが 2 つあるのは、ゲートウェイリスナーが ESB に対応しておらず、その役割はエンタープライズサービスバス全体で使用される ESB メッセージで JMS メッセージをカプセル化するためのものであるからです。

5.2. ファイルシステムゲートウェイリスナーの特性

ファイルシステムゲートウェイリスナー は、ファイルが変更されたときに、その変更を全体的に処理するために呼び出すことができます。行われた編集の通知を作成します。
AbstractFileGateway クラスは、これらのゲートウェイのベースです。AbstractScheduledManagedLifecycle クラスと連携して、イベントから情報を取得します。単一のスレッドを使用してファイル操作を実行し、ESB メッセージをバスに送信します。
挿入する max-millis-for-response プロパティーにより、ESB メッセージが同期的に送信されます。例外がある場合、ゲートウェイはファイルをエラーディレクトリーに移動します。(非同期処理の場合、このプロパティーを撤回します。例外が発生した場合、通知はなく、代わりに、別のスレッドで処理されます。)

5.3. パイプラインインターセプター

org.jboss.soa.esb.listeners.message.PipelineInterceptor は、サービス設定に渡されるインターセプターと、パイプラインの最後、サービスのインスタンス化時、または例外が原因でパイプラインが失敗する時点の設定に使用できるインターフェイスです。

5.4. パイプラインインターセプターの操作

パイプラインインターセプターには 1 つのメソッドがあります。
  1. public void processMessage (Message msg, ConfigTree config)。これは、jbossesb-properties.xml 設定ファイルで定義されたインターセプトポイントで呼び出されます。
次のプロパティーを使用して、jbossesb-properties.xml ファイル (jbossesb.sar アーカイブにある) のインターセプターセクションでパイプラインインターセプターを定義します。
  • org.jboss.soa.esb.pipeline.failure.interceptors
  • org.jboss.soa.esb.pipeline.instantiate.interceptors
  • org.jboss.soa.esb.pipeline.start.interceptors
  • org.jboss.soa.esb.pipeline.end.interceptors
注記
環境にデプロイされている各 ESB インスタンスの jbossesb-properties.xml ファイルに変更を加える必要があります。これにより、すべてのインスタンスが同じメタデータを処理できるようになります。
JBoss Enterprise SOA Platform には、メッセージを出力し、一般的な概念を示す org.jboss.soa.esb.listeners.message.GenericPipelineInterceptor のみが含まれています。任意で、具体的な実装を指定して使用するか決定できます。

5.5. ルーター

ルーターは、メッセージ自体またはそのペイロードをエンドポイントリスナーに送信するコンポーネントです。ルーターには、コンテンツベースのルーターと静的ベースのルーターの 2 種類があります。
設定に追加のアクションがある場合でも、ルーターアクションの後にアクションパイプラインのそれ以上の処理は行われません。(この種の分割が必要な場合は、StaticWiretap アクションを使用する必要があります。)

5.6. ルーター設定

一部のルーターは unwrap プロパティーをサポートしています。このプロパティーが true の場合には、ESB メッセージペイロードが抽出され、ペイロードのみが ESB に対応していないエンドポイントに送信されます。unwrap を false に設定すると、メッセージがそのまま渡され、受信エンドポイントはメッセージを処理できるように ESB に対応している必要があります。

5.7. Content-Based Router

コンテンツベースのルーターは、宛先アドレスを持たないメッセージを正しいエンドポイントに送信します。コンテンツベースのルーティングは、一連のルール (XPath または Drools 表記で定義可能) をメッセージの本文に適用することによって機能します。これらのルールは、どの当事者がメッセージに関心を持っているかを確認します。これは、送信アプリケーションが宛先アドレスを提供する必要がないことを意味します。
一般的な使用例は、優先度の高いキューで優先度の高いメッセージを処理することです。ここでの利点は、そのように設定されている場合、サービスの実行中にルーティングルールをオンザフライで変更できることです。(ただし、これには重大なパフォーマンス上の欠点があります。)
コンテンツベースのルーターが役立つ可能性があるその他の状況には、元の宛先が存在しなくなった場合、サービスが移動した場合、またはアプリケーションが時刻などの要素のコンテンツに基づいてメッセージの送信先をより詳細に制御したい場合などがあります。

5.8. 静的ベースのルーター

静的ベースのルーターは、ネットワーク全体で情報を調整するのに役立ちます。サーバー間で情報を転送し、メッセージの送信先を伝えます。デフォルトが非効率的であると感じた場合は、特定のルートを取るようにプログラムできます。他のサービスへのルーティングにのみ使用できます。

5.9. Notifier

Notifier は、成功メッセージやエラーメッセージなどの情報を ESB に対応していないエンドポイントに送信します。ESB 対応のエンドポイントでは使用しないでください。Notifier は単純なデータチャンクのみを転送できます。つまり、byte または String (ペイロードで toString() を呼び出して取得) のいずれかです。

5.10. ServiceInvoker

ServiceInvoker (org.jboss.soa.esb.client.ServiceInvoker) は、指定されたサービスへのメッセージの配信を管理します。また、エンドポイント参照の読み込みと courier の選択も管理するため、メッセージ配信用に一元的なインターフェイスを提供します。
ServiceInvoker は、下位レベルの詳細の多くを非表示にして、ステートレスサービスのフェイルオーバーメカニズムと背後で連携できるので、開発作業を簡素化するために導入されました。そのため、ServiceInvoker は JBoss Enterprise SOA Platform 内でのサービスの使用に推奨されるクライアント側インターフェイスです。
クライアントが対話するサービスごとに ServiceInvoker のインスタンスを作成できます。インスタンスが作成されると、レジストリーを調べてプライマリーエンドポイント参照を特定し、フェイルオーバーの場合は代替エンドポイント参照を特定します。

5.11. ServiceInvoker を使用した開発

これは ServiceInvoker のコードです。
  public class ServiceInvoker
    {
        public ServiceInvoker(Service service) throws MessageDeliverException;
        public ServiceInvoker(String serviceCategory, String serviceName) throws MessageDeliverException;
			 public ServiceInvoker(Service service, List<PortReference.Extension> extensions);
        public Message deliverSync(Message message, long timeoutMillis) throws MessageDeliverException, RegistryException, FaultMessageException;
        public void deliverAsync(Message message) throws MessageDeliverException;
			public Service getService();
			public String getServiceCategory();
    }
インスタンスを作成すると、クライアントはサービスにメッセージを送信する方法 (同期 (deliverSync 経由) または非同期 (deliverAsync 経由)) を決定します。同期の場合には、クライアントが応答を待機する時間を表すタイムアウトを指定する必要があります。この期間内に応答が受信されない場合、MessageDeliverException が出力されます。ResponseTimeoutException は MessageDeliverException から派生します。
クライアントサービス環境では、クライアントとサービスという用語はロールを表すために使用され、1 つのエンティティーが同時にクライアントにも、サービスにもなることができます。そのため、サービス内、特にアクション内で使用できるので、ServiceInvoker を純粋なクライアントのドメインと見なすべきではありません。たとえば、埋め込みのコンテンツベースのルーティングを使用する代わりに、アクションで、特定のビジネスロジックの評価をもとに、別のサービスに受信メッセージを再ルーティングするか、特定のタイプの障害メッセージを Dead Letter Queue にルーティングさせて、後で管理できるようにします。
この方法で ServiceInvoker を使用する利点は、詳細設定の章で説明されている不透明なフェイルオーバーメカニズムをサービスが利用できることです。つまり、開発者に複雑さを課すことなく、他のサービス、障害などへの一方向の要求をより堅牢な方法でルーティングできるます。
ServiceInvoker の機能の 1 つとして、ターゲットサービスで使用できる複数のエンドポイントがある状況での呼び出しを負荷分散する機能が挙げられます。ServiceInvoker は、この機能の一部として、多数の負荷分散戦略をサポートしています。
ServiceInvoker の使用時に、InVM トランスポートが利用可能な場合は、サービスを呼び出すことが常に優先されます。他の負荷分散ストラテジーは、ターゲットサービスの InVM エンドポイントがない場合にのみ適用されます。

5.12. RegistryException

クライアントがレジストリーに接続できない場合、またはサービスが見つからない場合は、RegistryException が出力されます。サービスに障害が発生したか、負荷が高すぎて時間内に応答できない可能性があります。その場合、タイムアウト値が返されます。一時的な問題かどうかをもう一度確認してください。

5.13. FaultMessageException

RegistryException が原因ではないサービスとの通信に失敗するたびに、FaultMessageException が出力されます。

5.14. MessageDeliverException

deliveryAsync メソッドの使用時に問題が発生すると、MessageDeliverException が出力されます。実際の例外がこのキャッチオールに埋め込まれていることがわかります。

5.15. Java Message Service

Java Message Service (JMS) は、2 つのクライアント間でメッセージを送信するための Java API です。これにより、分散アプリケーションのさまざまなコンポーネントが相互に通信できるようになり、疎結合と非同期が可能になります。さまざまな Java Message Service プロバイダーが利用可能です。Red Hat は、HornetQ の使用を推奨しています。

5.16. JMS トランザクションセッション

JMS トランザクションセッションでは、メッセージはキューに配置されますが、含まれているトランザクションがコミットされるまで配信されません。次に、別のトランザクションの範囲で受信者によって収集されます。残念ながら、同期的な要求/応答の相互作用では、送信者が配信トランザクションを終了する前に応答を待機することをブロックするため、応答を待機するタイムアウトが発生する可能性があります。

5.17. IncompatibleTransactionScopeException

IncompatibleTransactionScopeException は、JMS トランザクションセッションの問題から発生したブロックをキャッチし、エラーレポートを返します。

5.18. InVM

5.18.1. InVM トランスポート

InVM (仮想マシン内) トランスポートは、同じ JVM で実行されているサービス間の通信を提供します。

5.18.2. InVM の制限事項

InVM は、サービス間通信を促進するために使用される内部データ構造を最適化することにより、パフォーマンス上の利点を実現します。たとえば、メッセージを格納するために使用されるキューは永続的ではありません。つまり、障害が発生した場合にメッセージが失われる可能性があります。
さらに、キューが空になる前にサービスがシャットダウンされた場合には、それらのメッセージは配信されません。JBossESB ではサービスを複数の異なるトランスポートで同時に呼び出すことができるため、特定のメッセージタイプに適したトランスポートを選択することで高いパフォーマンスと信頼性を実現できるようにサービスを設計できます。
デフォルトでは、InVM トランスポートは参照によってメッセージを渡します。場合によっては、これが原因でデータの整合性の問題が発生する可能性があります。メッセージが ClassLoader 境界で交換される、クラスキャストの問題も言うまでもありません。
問題のサービスの inVMPassByValue プロパティーを true に設定することで、値によるメッセージの受け渡し (上記のような問題を回避する) をオンにすることができます。
<service category="ServiceCat" name="Service2" description="Test Service">
    <property name="inVMPassByValue" value="true" />

    <actions mep="RequestResponse">
        <action name="action" class="org.jboss.soa.esb.mock.MockAction" />
    </actions>
</service>

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 つのスコープがサポートされています。
  1. GLOBAL: (デフォルト) サービスは、同じ Classloader スコープ内から InVM トランスポートを介して呼び出すことができます。
  2. NONE: InVM トランスポート経由でサービスを呼び出すことはできません。
InVM リスナーは、トランザクションをサポートする他のトランスポートと同じ方法で、トランザクションスコープまたは非トランザクションスコープ内で実行できます。この動作は、明示的または暗黙的な設定によって制御できます。
トランザクションスコープの明示的な設定は、<service> 要素の invmTransacted 属性の定義によって制御され、暗黙的な設定よりも常に優先されます。
注記
別のトランザクション処理がされたトランスポートが、サービスに設定されている場合には、ImVM リスナーは暗黙的にトランザクション処理されます。現在、これらの追加のトランスポートは、jms、スケジュール、または sql にすることができます。
警告
JBoss Enterprise SOA Platform の InVM トランスポートはトランザクションベースで、メッセージキューは揮発メモリーでのみ保持されます。つまり、システム障害が発生した場合やシャットダウンをした場合に、このトランスポートのメッセージキューが失われます。
注記
特にデータベースなどの他のトランザクションリソースと組み合わせて使用する場合に、ACID セマンティクスのすべてを実現できない場合があります。これは、InVM キューの揮発性の特性が原因ですが、ほとんどの場合、InVM のパフォーマンス上の利点がこの欠点を上回るはずです。完全な ACID セマンティクスが必要な状況では、Red Hat は、Java Message Service やデータベースなど、他のトランザクショントランスポートのいずれかを使用することをお勧めします。
トランザクション内で InVM を使用する場合には、トランザクションがコミットされるまでメッセージは受信者のキューに表示されませんが、送信者には、メッセージが受けいれられ、後でキューに追加されるという確認応答がすぐに表示されます。受信者がトランザクションの範囲内でキューからメッセージをプルしようとした場合に、そのトランザクションが後でロールバックすると、メッセージは自動的にキューに戻されます。メッセージの送信者または受信者がトランザクションの結果を知る必要がある場合は、トランザクションの結果を直接監視するか、トランザクションに同期を登録する必要があります。
トランザクションマネージャーによってメッセージがキューに戻されると、同じ場所に戻らない場合があります。これは、パフォーマンスを最大化するための意図的な仕様です。アプリケーションでメッセージの特定の順序付けが必要な場合は、別のトランスポートを検討するか、関連するメッセージを 1 つのラッパーメッセージにグループ化する必要があります。

5.18.4. 個々のサービスの InVM スコープの設定

手順5.1 タスク

  1. テキストエディターでファイルを開きます。
  2. サービス要素の invmScope 属性を設定します。
          <service category="ServiceCat" name="ServiceName" invmScope="GLOBAL"
      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>
    
  3. ファイルを保存して終了します。

5.18.5. デプロイメントのデフォルトの InVM スコープ設定

手順5.2 タスク

  1. テキストエディターで jbossesb-properties.xml を開きます (vi jbossesb-properties.xml)。
  2. core:jboss.esb.invm.scope.default 設定プロパティーを設定します。(定義されたままの場合、デフォルトのスコープは GLOBAL です。)
  3. ファイルを保存して終了します。

5.18.6. InVM トランスポートに関連付けられたリスナースレッドの数の変更

手順5.3 タスク

  1. テキストエディターでファイルを開きます。
  2. 次のようにファイルを編集します。
          <service category="HelloWorld" name="Service2" 
        description="Service 2" invmScope="GLOBAL"> 
           		 <property name="maxThreads" value="100" /> 
             		<listeners>... 
             		<actions>...
    
  3. ファイルを保存して終了します。

5.18.7. Lock-Step 配信

Lock Step 配信とは、メッセージをサービスに配信する時間よりも、サービスが取得する時間が短くなるようにします。これは、受信サービスがメッセージを取得するか、タイムアウトの期限が切れるまで、メッセージの配信をブロックすることで実現します。
これは同期配信方法ではありません。つまり、応答や、サービスによるメッセージ処理の完了を待ちません。ブロックするのは、メッセージがサービスによってキューから削除されるまでの間だけです。
Lock Step 配信はデフォルトで無効になっています。

5.18.8. Lock Step 配信設定

<service> の <property> 設定を利用して、Lock Step 配信を設定します。
inVMLockStep
これはブール値です。Lock Step 配信を有効にするかどうかを制御します。
inVMLockStepTimeout
これにより、メッセージの取得を待機している間はメッセージ配信がブロックされる最大期間 (ミリ秒単位)。
<service category="ServiceCat" name="Service2" 
  description="Test Service">
  <property name="inVMLockStep" value="true" />
  <property name="inVMLockStepTimeout" value="4000" />

  <actions mep="RequestResponse">
    <action name="action" class="org.jboss.soa.esb.mock.MockAction" />
  </actions>
</service>
注記
トランザクションの範囲内で InVM を使用している場合には、Lock Step 配信は無効になります。キューにメッセージが挿入されるかどうかは、囲まれたトランザクションのコミットにより決まります。このコミットは、想定される Lock Step の待機時間の後、または前の任意のタイミングで発生する可能性があります。

5.19. ロードバランシング

5.19.1. ロードバランシング

ロードバランシングは、複数のコンピューターまたはコンピュータークラスター、ネットワークリンク、中央処理装置、ディスクドライブ、またはその他のリソースにワークロードを分散して、最適なリソース使用率を達成し、スループットを最大化し、応答時間を最小化し、過負荷を回避するためのコンピューターネットワーキング手法です。単一のコンポーネントではなく、複数のコンポーネントを負荷分散とともに使用すると、冗長性によって信頼性も向上します。

5.19.2. 負荷分散ポリシーの設定

手順5.4 タスク

  1. グローバル設定ファイルをテキストエディターで開きます: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployers/jbossesb-properties.xml
  2. org.jboss.soa.esb.loadbalancer.policy プロパティーまでスクロールダウンします。使用するポリシーで設定します。
  3. ファイルを保存して終了します。

5.19.3. 負荷分散ポリシー

表5.1 利用可能な負荷分散ポリシー

ポリシー名 Description
最初に入手可能 正常なサービスバインディングが見つかった場合は、それが終了するまで使用されます。リスト内の次のエンドポイント参照が使用されます。このポリシーでは、2 つのサービスインスタンス間の負荷分散は行われません。
ラウンドロビン 各エンドポイント参照がリスト順に使用される標準の負荷分散ポリシー。
ランダムロビン これはラウンドロビンに似ていますが、選択はランダム化されます。
注記
ポリシーで使用されるエンドポイント参照リストは、デッド EPR が削除されるにつれて、時間の経過とともに小さくなる可能性があります。リストが使い果たされたとき、またはリストキャッシュの time-to-live が上限を超えると、ServiceInvoker はレジストリーから EPR の新しいリストを取得します。

5.20. サービスコントラクトの定義

5.20.1. サービスコントラクト

サービスコントラクトは、着信要求、発信応答、およびエラーメッセージの詳細を定義する一連の XML スキーマです。要求メッセージと応答メッセージを表すスキーマは、メッセージの本文セクションの形式を定義するために使用され、そのコンテンツのデータを強制的に検証することもできます。

5.20.2. サービスコントラクトスキーマの宣言

スキーマは、サービスに関連付けられた <actions> 要素で次の属性を指定することによって宣言されます

表5.2 サービスコントラクトの属性

名前 説明 タイプ
inXsd 単一の要素を表す、要求メッセージのスキーマを含むリソース。 xsd:string
outXsd 単一の要素を表す、応答メッセージのスキーマを含むリソース。 xsd:string
faultXsd それぞれが 1 つ以上の障害要素を表すスキーマのコンマ区切りリスト。 xsd:string
requestLocation デフォルトの場所ではない場合、本文内のリクエストコンテンツの場所。 xsd:string
responseLocation デフォルトの場所ではない場合、本文内の応答コンテンツの場所。 xsd:string

5.20.3. メッセージの検証

関連するスキーマが <actions> 要素で宣言されていれば、要求メッセージと応答メッセージの内容を自動的に検証できます。デフォルトでは、検証は無効になっています。<actions> 要素の 'validate' 属性を 'true' に設定して検証を有効にします。

5.21. Web サービスエンドポイントを介した ESB サービスの公開

5.21.1. Web サービスエンドポイントを介した ESB サービスの公開

サービスコントラクトスキーマを宣言すると、ESB サービスは Web サービスエンドポイントを通じて自動的に公開されます。(この Web サービスエンドポイントのコントラクトは、コントラクト Web アプリケーションから見つけることができます。) この機能を変更するには、webservice 属性の値を次のいずれかに変更します。

表5.3 Web サービス属性

名前 Description
false Web サービスエンドポイントは公開されません。
true Web サービスエンドポイントが公開されます (デフォルト)。
デフォルトでは、Web サービスエンドポイントは WS-Addressing をサポートしていませんが、'addressing' 属性を使用して有効にすることができます。

表5.4 WS-Addressing 値

Description
false WS-Addressing はサポートされていません (デフォルト)。
true WS-Addressing サポートが必要です。
アドレス指定のサポートが有効になっている場合、WS-Addressing Message Id、Relates To URI、および関係タイプが受信メッセージのプロパティーとして追加されます。

表5.5 WS-Addressing プロパティー

プロパティー Description
org.jboss.soa.esb.gateway.ebws.messageID WS-Addressing メッセージ ID。
org.jboss.soa.esb.gateway.ebws.relatesTo WS-Addressing RelatesTo URI を含む文字列配列。
org.jboss.soa.esb.gateway.ebws.relationshipType RelatesTo URI に対応する WS-Addressing リレーションシップタイプを含む文字列配列。
次の例は、要求/応答メッセージを検証するが、Web サービスエンドポイントを介してサービスを公開しないサービスの宣言を示しています。
<service category="ServiceCat" name="ServiceName" description="Test Service">
    <actions mep="RequestResponse" inXsd="/request.xsd" outXsd="/response.xsd"
            webservice="false" validate="true">
        <!-- .... >
    </actions>			
</service>
次の例は、要求/応答メッセージを検証し、Web サービスエンドポイントを介してサービスを公開するサービスの宣言を示しています。さらに、サービス側は、指定された本文の場所 'REQUEST' で要求が提供されることを想定し、指定された本文の場所 'RESPONSE' でその応答を返します。
  
  <service category="ServiceCat" name="ServiceName" description="Test Service">
    <actions mep="RequestResponse" inXsd="/request.xsd" outXsd="/response.xsd"
            validate="true" requestLocation="REQUEST" responseLocation="RESPONSE">
        <!-- .... -->
    </actions>			
</service>

第6章 その他のコンポーネント

6.1. メッセージストア

メッセージストアは、監査追跡を可能にするように設計されたデータベース永続化メカニズムです。メッセージストアは、要求に応じてメッセージの読み取りと書き込みを行います。各メッセージには一意の識別番号が必要です。他の ESB サービスと同様に、メッセージストアはプラグイン可能です。つまり、必要に応じて独自の永続化メカニズムをプラグインできますが、デフォルトのデータベース永続化メカニズムが提供されています。
システム障害が発生した場合、メッセージストアは再配信が必要なメッセージの保持場所としても使用されます。
注記
ファイルの永続化メカニズムなど、データベース以外の何かが必要な場合は、独自のサービスを作成してから、設定を変更してデフォルトの動作をオーバーライドできます。

6.2. Smooks

Smooks は、フラグメントベースのデータ変換および分析ツールです。これは、メッセージの断片を解釈できる汎用処理ツールです。ビジターロジックを使用してこれを実現します。XSLT または Java で変換ロジックを実装でき、メッセージセットの変換ロジックを一言管理できる管理フレームワークを提供します。

6.3. Smooks の訪問者ロジック

Smooks は ビジターロジック を使用します。ビジターは、メッセージの特定のフラグメントに対して特定のアクションを実行する Java コードです。これにより、Smooks はメッセージフラグメントに対してアクションを実行できます。

6.4. データ変換

はじめに

クライアントとサービスは通常、同じ語彙を使用して通信します。ただし、これが当てはまらない場合があり、ある形式から別の形式に変換するためにオンザフライ変換メカニズムが必要になります。特に、大規模または長期にわたるデプロイメントなど、1 つのデータ形式がすべてのビジネスオブジェクトに適していると仮定するのは非現実的です。したがって、データ変換メカニズムが提供されています。

6.5. Content-Based Router

コンテンツベースのルーターは、宛先アドレスを持たないメッセージを正しいエンドポイントに送信します。コンテンツベースのルーティングは、一連のルール (XPath または Drools 表記で定義可能) をメッセージの本文に適用することによって機能します。これらのルールは、どの当事者がメッセージに関心を持っているかを確認します。これは、送信アプリケーションが宛先アドレスを提供する必要がないことを意味します。
一般的な使用例は、優先度の高いキューで優先度の高いメッセージを処理することです。ここでの利点は、そのように設定されている場合、サービスの実行中にルーティングルールをオンザフライで変更できることです。(ただし、これには重大なパフォーマンス上の欠点があります。)
コンテンツベースのルーターが役立つ可能性があるその他の状況には、元の宛先が存在しなくなった場合、サービスが移動した場合、またはアプリケーションが時刻などの要素のコンテンツに基づいてメッセージの送信先をより詳細に制御したい場合などがあります。

6.6. JBoss Rules Engine を使用したコンテンツベースのルーティング

JBoss Rules は、コンテンツベースルーターのルールプロバイダーエンジンです。Enterprise Service Bus は、次の 3 つの異なるルーティング action classes を通じてこのエンジンと統合されます。
  • JBoss Rules エンジンの DRL 言語で記述されたルーティングルールセット (あるいは、必要に応じて DSL 言語を使用することもできます)。
  • メッセージの内容。これは、JBoss Rules エンジンに送られるデータです (XML 形式またはメッセージに埋め込まれたオブジェクトとして送られます)。
  • 宛先 (エンジンから出力される結果情報から導出されます)。
注記
メッセージが コンテンツベースのルーター に送信されると、ルールセットがそのコンテンツを評価し、一連のサービス宛先を返します。
  • org.jboss.soa.esb.actions.ContentBasedRouter: このアクションクラスは コンテンツベースのルーティング パターンを実装します。メッセージの内容と、その内容を評価するルールセットに基づいて、メッセージを 1 つ以上の宛先サービスにルーティングします。特定のルールセットまたはメッセージの組み合わせに一致する宛先がない場合には、コンテンツベースルーターは例外を出力します。このアクションはそれ以降のパイプライン処理を終了させるため、常にパイプラインの最後に配置してください。
  • org.jboss.soa.esb.actions.ContentBasedWiretap: これは WireTap パターンを実装します。WireTap は、メッセージのコピーを制御チャネルに送信するエンタープライズ統合パターンです。WireTap の機能は標準のコンテンツベースのルーターと同じですが、パイプラインは終了されません。これは後者の特徴であり、wire-tap として使用するのに適した特徴であるため、その名前になります。詳細は、 を参照してください。
  • org.jboss.soa.esb.actions.MessageFilter: メッセージフィルター パターンを実装します。メッセージフィルターパターンは、特定のコンテンツ要件を満たしていない場合に、メッセージを削除できる場合に使用されます。つまり、ルールセットが宛先と一致しない場合は例外を出力しないことを除いて、コンテンツベースのルーターと同じように機能します。詳細は、を参照してください http://www.eaipatterns.com/Filter.html

6.7. Service Registry

サービスレジストリーは、サービスに関する情報 (特にエンドポイントの参照) を格納する中央データベースです。JBoss Enterprise SOA Platform のデフォルトのサービスレジストリーは、jUDDI (Java Universal Description、Discovery、および Integration) です。ほとんどのサービスレジストリーは、Universal Description、Discovery and Integration (UDDI) 仕様に準拠するように設計されています。
ビジネスアナリストの観点からは、レジストリーはインターネット検索エンジンと似ていますが、Web ページではなく Web サービスを検索するように設計されています。開発者の観点からは、レジストリーはさまざまな条件に一致するサービスを検出し、公開するために使用されます。
多くの方法では、レジストリーサービスは JBoss Enterprise SOA Platform の最後とみなすことができます。サービスは、レジストリーがアクティブになったときにレジストリーへのエンドポイント参照をセルフパブリッシュし、サービスが不足したときにそれらを削除できます。コンシューマーはレジストリーを参照して、現在のサービスタスクにどのエンドポイントの参照が必要かを判断できます。

6.8. juddi レジストリー

JUDDI (Java Universal Description、Discovery and Integration) レジストリーは、JBoss Enterprise SOA Platform のコアコンポーネントです。製品のデフォルトサービスレジストリーであり、製品の一部として含まれています。これには、Enterprise Service Bus に接続されるすべてのサービスのアドレス (エンドポイント参照) が保存されます。JAXR に実装され、UDDI 仕様に準拠していました。

6.9. juddi および JBoss Enterprise SOA Platform

juddi および JBoss Enterprise SOA Platform

JBoss Enterprise SOA Platform 製品には、jUDDI レジストリーの事前設定されたインストールが含まれています。特定の API を使用して、カスタムクライアントを介してこのレジストリーにアクセスできます。ただし、ビルドするカスタムクライアントは SOA Platform のサポート契約では対応されません。jUDDI の例、ドキュメント、および API の完全なセットには、次の場所からアクセスできます。http://juddi.apache.org/

第7章 メッセージ開発についてのチュートリアル

7.1. 概要

はじめに

概念的には、メッセージは SOA 開発アプローチの重要な要素です。メッセージには、クライアントとサービス間で送信されるアプリケーション固有のデータが含まれます。メッセージのデータは、サービスとそのクライアント間のコントラクトの重要な要素を表します。このセクションでは、このコンポーネントに使用するベストプラクティスを説明します。

まず、以下のフライト予約サービスの例を検討してください。このサービスは、以下の操作をサポートします。
reserveSeat
これはフライト番号とシート番号を取り、成功または失敗を示します。
querySeat
これはフライト番号とシート番号を取り、シートが現在予約されているかどうかを示します。
upgradeSeat
フライト番号と、2 つのシート番号(現在予約されているシートと、パッセンジャーが移動するもの)を取ります。
サービスを開発する場合、主に Enterprise Java Beans (EJB3)や Hibernate などの技術を使用してビジネスロジックを実装します。この例では、このロジックの実装方法をリーダーに説明しません。代わりに、サービス自体に重点を置いています。
サービスのロールは、バスにロジックをプラグインすることです。これを設定するには、サービスがバスに公開される方法を決定します(つまり、クライアントに定義されたコントラクトのタイプ)。現行バージョンの JBoss Enterprise Service Bus では、このコントラクトはクライアントとサービスが交換するさまざまなメッセージの形式を取ります。
注記
現在、この契約に対する正式な仕様は、この契約にはありません。これは、エンタープライズサービスバスに関係なく、開発者がクライアントを定義し、通信するものです。これは後続のリリースで修正されます。

7.2. メッセージ構造

サービスの観点から見ると、メッセージの最も重要なコンポーネントはボディーです。これは、ビジネスロジックに固有の情報を伝えるために使用されるためです。クライアントとサーバーの両方が、対話するために相互に理解する必要があります。この理解には、トランスポートのモード(Java Message Service や HTTP など)と使用されるダイアレクト(データがメッセージに表示される形式)に関する合意が関係します。
メッセージをサンプルフライト予約サービスに直接送信するクライアントを簡単にするには、サービスがメッセージに関与する操作をどのように判断するかを決定する必要があります。この場合、開発者は org.example.flight.opcode という場所にある opcode (操作コード)が文字列(reserve, queryupgrade)として表示されると判断します。その他の文字列値(または値がない場合)は、メッセージが不正であると見なされます。
重要
メッセージ内のすべての値に一意の名前が指定されていることを確認します。これにより、他のクライアントおよびサービスとの競合が回避されます。
メッセージボディーは、クライアントとサービスの間でデータを交換する主要な方法です。任意のデータタイプを含めるのに十分な柔軟性があります。(各操作に関連するビジネスロジックを実行するために必要な他のパラメーターは適切にエンコードする必要があります。)
  • シート番号の org.example.flight.seatnumber (整数)
  • フライト番号の org.example.flight.flightnumber。文字列になります。
  • アップグレードしたシート番号の org.example.flight.upgradenumber (整数)

表7.1 操作パラメーター

操作 opcode seatnumber flightnumber upgradenumber
reserveSeat string: reserve integer String 該当なし
querySeat string: query integer String 該当なし
upgradeSeat string: upgrade integer String integer
これらの操作はすべて、メッセージ内で情報をカプセル化してクライアントに返します。応答メッセージは、独自の形式を決定するために同じプロセスを通過します。簡単にするために、応答メッセージはこの例からなくなります。
1 つ以上のアクションを使用してサービスを構築します。これらのメッセージは、受信メッセージを事前に処理し、コンテンツをメインのビジネスロジックを担当するアクションに渡す前に変換します。これらの各アクションは分離して記述することができます(同一組織内の異なるグループや、全く異なる組織によっても記述される場合もあります)。各アクションに、それが動作するメッセージデータの一意のビューがあることを常に確認してください。そうでない場合は、チェーンされたアクションが上書きされたり、相互に干渉する可能性があります。

7.3. サービスの開発

この時点で、サービスを構築するのに十分なことを学習しました。簡単にするために、ビジネスロジックが以下の pseudo-object 内にカプセル化されていることを前提とします。
		  class AirlineReservationSystem
{
	public void reserveSeat (...);
	public void querySeat (...);
	public void upgradeSeat (...);
}
注記
Plain Old Java Objects、Enterprise Java Beans、または Spring を使用してビジネスロジックを開発します。JBoss Enterprise SOA Platform は、さまざまなアプローチに対して追加設定なしのサポートを提供します。
サービスアクションの処理は以下のようになります。
		  @Process
public Message process (Message message) throws Exception
{
	String opcode = message.getBody().get(“org.example.flight.opcode”);
	
	if (opcode.equals(“reserve”))
		reserveSeat(message);
	
	else if (opcode.equals(“query”))
		querySeat(message);
	
	else if (opcode.equals(“upgrade”))
		upgradeSeat(message);
		
	else
		throw new InvalidOpcode();
	
	return null;
}
注記
WS-Addressing では、メッセージボディーの opcode を埋め込むのではなく、メッセージヘッダーのaction フィールドを使用してください。欠点は、複数のアクションがチェーンされていて、これらごとに異なる opcode が必要な場合は機能しないことです。

7.4. ペイロードのデコード

手順7.1 タスク

  1. process メソッドは開始のみになります。ここで、受信メッセージのペイロード(Body)をデコードするメソッドを提供する必要があります。
    		  public void reserveSeat (Message message) throws Exception
    {
    	String seatNumber = message.getBody().get(“org.example.flight.seatnumber”);
    	String flight = 
            message.getBody().get(“org.example.flight.flightnumber”);
    	
    	boolean success = 
            airlineReservationSystem.reserveSeat(seatNumber, flight);
    	
    	// now create a response Message
    	Message responseMessage = ...
    	
    	responseMessage.getHeader().getCall().setTo(
            message.getHeader().getCall().getReplyTo()
        );
        
    	responseMessage.getHeader().getCall().setRelatesTo(
            message.getHeader().getCall().getMessageID()
        );
    	
    	// now deliver the response Message
    }
    このコードは、ボディー内の情報を抽出し、一部のビジネスロジックでメソッドを呼び出すのに使用します。reserveSeat の場合、応答はクライアントによって予想されます。この応答メッセージは、ビジネスロジックによって返される情報と、元の受信したメッセージから取得した配信情報を使用して構築されます。この例では、受信メッセージの ReplyTo フィールドから取得した応答の To アドレスが必要です。また、元のリクエストと応答を関連付ける必要があります。応答の RelatesTo フィールドとリクエストの MessageID を使用してこれを実現します。
  2. 同様のサービスがサポートするすべての操作をコーディングします。

7.5. クライアントの構築

手順7.2 タスク

  • サービスでサポートされるメッセージ定義があるとすぐに、クライアントコードを作成できます。サービスのサポートに使用されるビジネスロジックはサービスによって直接公開されることはありません(これは SOA: カプセル化の重要な原則の 1 つを壊す可能性があります)。これは基本的にサービスコードの逆になります。
    		  ServiceInvoker flightService = new ServiceInvoker(...);
    Message request = // create new Message of desired type
    
    request.getBody().add(“org.example.flight.seatnumber”, ”1”);
    request.getBody().add(“ org.example.flight.flightnumber”, “BA1234”);
    
    request.getHeader().getCall().setMessageID(1234);
    request.getHeader().getCall().setReplyTo(myEPR);
    
    Message response = null;
    
    do
    {
    	response = flightService.deliverSync(request, 1000);
    	
    	if (response.getHeader().getCall().getRelatesTo() == 1234)
    	{
    	// it's out response!
    	
    	break;
    	}
    	else
    	response = null;  // and keep looping
    	
    } while !maximumRetriesExceeded();
    
    注記
    上記のほとんどは、従来のクライアント/サーバー スタブジェネレーター で作業したリーダーに認識できます。これらのシステムでは、低レベルの詳細( opcodes やパラメーターなど)は高レベルのスタブ抽象化の背後で非表示になります。SOA Platform には RESTEasy との統合があり、ユーザーはアノテーションベースの REST スタイルの Web サービスを開発できます。これにより、opcodes や parameters などの低レベルの詳細が非表示になります。

7.6. リモートサービス呼び出し元の設定

直接のアクションから ServiceInvoker を使用するように設定する必要はありません。ボックスからは機能します。 ただし、スタンドアロン Java アプリケーション、サーブレット、EJB など、リモート JVM から使用するには、以下の JAR ファイルを利用できるようにする必要があります。
commons-codec-1.3.jar
commons-collections.jar
commons-configuration-1.5.jar
commons-lang-2.4.jar
commons-logging.jar
concurrent.jar
hornetq-core-client.jar
hornetq-jms.jar
javassist.jar
jboss-aop-client.jar
jboss-common-core.jar
jboss-javaee.jar
jboss-logging-spi.jar
jboss-mdr.jar
jboss-remoting.jar
jbossall-client.jar
jbossesb-config-model-1.0.1.jar
jbossesb-config-model-1.1.0.jar
jbossesb-config-model-1.2.0.jar
jbossesb-config-model-1.3.0.jar
jbossesb-config-model-1.3.1.jar
jbossesb-registry.jar
jbossesb-rosetta.jar
jbossjmx-ant.jar
jbossts-common.jar
juddi-client-3.1.3.jar
log4j.jar
netty.jar
scout-1.2.6.jar
serializer.jar
Trove.jar
uddi-ws-3.1.3.jar
注記
これらのファイルは $ SOA_HOME/jboss-as/client/$ SOA_HOME/jboss-as/common/lib/ および $ SOA_HOME/jboss-as/server/$ SOA_CONF/deployers/esb.deployer/lib/ ディレクトリーにあります。
クラスパス上では、以下の設定ファイルも利用できるようにする必要があります。
  • jbossesb-properties.xml
  • META-INF/uddi.xml

7.7. JBoss Enterprise SOA Platform の起動

前提条件

次のソフトウェアをインストールする必要があります。

  • JBoss Enterprise SOA Platform

手順7.3 JBoss Enterprise SOA Platform の起動

  • サーバーウィンドウ で SOA サーバーを起動する

    • Red Hat Enterprise Linux

      1. ターミナルを開き、コマンド cd SOA_ROOT/jboss-as/bin を入力して bin ディレクトリーに移動します。
      2. ./run.sh と入力して SOA サーバーを起動します。(サーバープロファイルを指定していないため、デフォルトが使用されます。)
    • Microsoft Windows

      1. ターミナルを開き、コマンド chdir SOA_ROOT\jboss-as\bin を入力して bin ディレクトリーに移動します。
      2. run.bat と入力して SOA サーバーを起動します。(サーバープロファイルを指定していないため、デフォルトが使用されます。)

結果

サーバーが起動します。ハードウェアの速度にもよりますが、これには約 2 分かかります。

注記
エラーがないことを確認するには、サーバーログをチェックします (less SOA_ROOT/jboss-as/server/PROFILE/log/server.log)。別のチェックとして、Web ブラウザーを開いて、http://localhost:8080 に移動します。設定したユーザー名とパスワードで管理コンソールにログインできることを確認してください。

7.8. テストサーバーへの "Hello World" クイックスタートのデプロイ

前提条件

  • SOA_ROOT/jboss-as/samples/quickstarts/conf/quickstarts.properties-example の設定がサーバー設定 (テスト環境の default) と一致することを確認します。

手順7.4 "Hello World" クイックスタートのデプロイ

  1. サーバーが完全に起動したことを確認します。
  2. 2 番目のターミナルウィンドウを開き、クイックスタートを含むディレクトリーに移動します。cd SOA_ROOT/jboss-as/samples/quickstarts/helloworld (chdir SOA_ROOT\jboss-as\samples\quickstarts\helloworld)
  3. ant deploy を実行して、クイックスタートをデプロイします。次のようなメッセージを探して、デプロイが成功したかどうかを確認します。
    deploy-esb:
         [copy] Copying 1 file to
    /jboss/local/53_DEV2/jboss-soa-p-5/jboss-as/server/default/deploy
    
    deploy-exploded-esb:
    
    quickstart-specific-deploys:
         [echo] No Quickstart specific deployments being made.
    
    display-instructions:
         [echo] 
         [echo] ******************
         [echo] Quickstart deployed to target JBoss ESB/App Server at
    '/jboss/local/53_DEV2/jboss-soa-p-5/jboss-as/server/default/deploy'.
         [echo] 1.  Check your ESB Server console to make sure the deployment was
    executed without errors.
         [echo] 2.  Run 'ant runtest' to run the Quickstart.
         [echo] 3.  Check your ESB Server console again.  The Quickstart should
    have produced some output.
         [echo] ******************
    
    deploy:
    
    BUILD SUCCESSFUL
    
    また、SOA_ROOT/jboss-as/server/default/log/server.log でこれを確認してください。
    10:58:52,998 INFO  [NamingHelper] JNDI InitialContext properties:{}
    11:00:58,154 INFO  [QueueService]
    Queue[/queue/quickstart_helloworld_Request_esb] started, fullSize=200000,
    pageSize=2000, downCacheSize=2000
    11:00:58,186 INFO  [QueueService]
    Queue[/queue/quickstart_helloworld_Request_gw] started, fullSize=200000,
    pageSize=2000, downCacheSize=2000
    11:00:58,427 INFO  [EsbDeployment] Starting ESB Deployment
    'Quickstart_helloworld.esb'
    
  4. コマンド ant runtest を発行して、クイックスタートを実行します。クイックスタートが実行されると、次のようなメッセージが SOA_ROOT/jboss-as/server/default/log/server.log に書き込まれます。
    11:03:02,190 INFO  [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
    11:03:02,191 INFO  [STDOUT] Body: Hello World
    11:03:02,191 INFO  [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
    11:03:02,192 INFO  [STDOUT] Message structure: 
    11:03:02,192 INFO  [STDOUT] [Hello World].
    

結果

サーバーターミナルに "Hello World" という言葉が表示されます。このメッセージは SOA_ROOT/jboss-as/server/default/log/server.log ファイルにも追加されます。

7.9. リモートクライアントの設定のテスト

前提条件

  • サーバーが起動し、Hello World クイックスタートがデプロイされている必要があります。

手順7.5 タスク

  • このテストコードを実行します。
        
    package org.jboss.esb.client;
    import
    import
    import
    import
    org.jboss.soa.esb.client.ServiceInvoker;
    org.jboss.soa.esb.listeners.message.MessageDeliverException;
    org.jboss.soa.esb.message.Message;
    org.jboss.soa.esb.message.format.MessageFactory;
    public class EsbClient
    {
    public static void main(String[] args)
    {
    System.setProperty("javax.xml.registry.ConnectionFactoryClass",
    "org.apache.ws.scout.registry.ConnectionFactoryImpl");
    try
    {
    Message message = MessageFactory.getInstance().getMessage();
    message.getBody().add("Sample payload");
    ServiceInvoker invoker = new ServiceInvoker("FirstServiceESB",
    "SimpleListener");
    invoker.deliverAsync(message);
    }
    catch (final MessageDeliverException e)
    {
    e.printStackTrace();
    }
    }
    }
    

7.10. リモートクライアントの設定が正しいことの確認

前提条件

  • JBoss Enterprise SOA Platform が実行されており、HelloWorld クイックスタートがデプロイされている必要があります。

手順7.6 タスク

  • このコードを実行します。
    package org.jboss.esb.client;
    
    import org.jboss.soa.esb.client.ServiceInvoker;
    import org.jboss.soa.esb.listeners.message.MessageDeliverException;
    import org.jboss.soa.esb.message.Message;
    import org.jboss.soa.esb.message.format.MessageFactory;
    
    public class EsbClient
    {
        public static void main(String[] args)
        {
            System.setProperty("javax.xml.registry.ConnectionFactoryClass",
                    "org.apache.ws.scout.registry.ConnectionFactoryImpl");
            try
            {
                Message message = MessageFactory.getInstance().getMessage();
                message.getBody().add("Sample payload");
                ServiceInvoker invoker = new ServiceInvoker("FirstServiceESB", "SimpleListener");
                invoker.deliverAsync(message);
            }
            catch (final MessageDeliverException e)
            {
                e.printStackTrace();
            }

7.11. クライアントおよびサービスの構築時のさらなるアドバイス

これらのヒントは、クライアントおよびサービスを構築する際に役立つ場合があります。
  • アクションを開発するときは、アクションに固有のペイロード情報が一意のメッセージボディーの場所に保持されていることを確認してください。
  • クライアントに影響を与えずに実装を変更することが困難になるため、メッセージ内にバックエンドサービスの実装の詳細を公開しないでください。実装に依存しないメッセージ定義(コンテンツ、形式など)を使用します。これは、結合が遅れるのに役立つためです。
  • ステートレスサービスの場合は、フェイルオーバーのopaquelyを処理するため、ServiceInvoker を使用します。
  • 要求/応答アプリケーションをビルドする場合は、メッセージヘッダー内で相関情報(MessageID および RelatesTo)を使用します。
  • メインのサービス opcodeHeader Action フィールドを使用することを検討してください。
  • 応答に配信アドレスがない非同期対話を使用する場合は、後で監視できるように、MessageStore にエラーを送信することを検討してください。
  • JBoss Enterprise SOA Platform がサービス契約の定義と公開の自動サポートを提供するまでは、これらの定義の個別のリポジトリーを維持し、開発者とユーザーの両方に利用できるようにすることを検討してください。

第8章 高度なトピック

8.1. ノード

JBoss Enterprise SOA Platform を使用する場合、サービスがビルドユニットになることを意味します。これにより、多数のノード間で同じサービスを複製できます。各ノードは、エンタープライズサービスバスのインスタンスを実行している仮想マシンまたは物理マシンです。

8.2. バス

ノードのグループの集まり名は Bus です。バス内のサービスは、異なる配信チャネルを使用してメッセージを交換します。

8.3. 配信チャンネル

配信チャンネルは、エンタープライズサービスバス外のシステムによって提供されるプロトコルです。チャネルは JMS、HTTP、または FTP のいずれかになります。サービスは、複数のプロトコルをリッスンするように設定できます。サービスがリッスンするように設定されているプロトコルごとに、レジストリーにエンドポイント参照を作成します。

8.4. クラスター内の複数のノードで同じサービスを実行する

手順8.1 タスク

  • クラスター内の複数のノードで同じサービスを実行するには、レジストリーのキャッシュが再検証されるまで待ちます。

8.5. 失敗したエンドポイント参照をレジストリーから削除する

手順8.2 タスク

  1. jbossesb-properties.xml をテキストエディターで開きます: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployers/jbossesb-properties.xml
  2. org.jboss.soa.esb.failure.detect.removeDeadEPR を含むセクションまで下にスクロールします。このプロパティーを true に設定します。
  3. ファイルを保存して終了します。
    警告
    この機能は細心の注意を払って使用する必要があるため、デフォルト設定は false であることに注意してください。これを使用すると、単純に過負荷になっているため応答が遅いサービスのエンドポイント参照が、誤って削除される可能性があります。これらの孤立したサービスとのやり取りはなくなり、再起動が必要になる場合があります。

8.6. サービスの仕組み

はじめに

このセクションでは、サービス、エンドポイントの参照、リスナー、およびアクションが実際にどのように機能するかについて詳しく説明します。

以下のコードフラグメントは、JBossESBHelloworld の例の設定に大まかに基づいています。
  ...
<service category="FirstServiceESB" name="SimpleListener" description="Hello World">
    <listeners>
        <jms-listener name="helloWorld" busidref="quickstartEsbChannel" maxThreads="1"/>
    </listeners>
    <actions>
        <action name="action1" class="org.jboss.soa.esb.actions.SystemPrintln"/>
    </actions>
</service>
...
サービスが初期化すると、カテゴリー、名前、および説明が UDDI レジストリーに登録されます。また、各 listener 要素について、ServiceBinding を UDDI に登録し、エンドポイント参照を格納します。(この場合は jms-listener であるため、このサービスの JMSEPR を登録します。)
キュー名などの JMS の詳細は表示されませんが、'provider' セクションを見つけることができる jboss-esb.xml ファイルの上部に表示されます。
jms-listener では、busidref 属性のquickstartEsbChannel を簡単に参照できます。
カテゴリーとサービス名が指定されていると、別のサービスがレジストリーでサービスを検索できます。その後、サービスにメッセージを送信するために使用できる JMSEPR を受け取ります。(この作業はすべて ServiceInvoker クラスによって行われます。)
HelloWorld サービスが quickstartEsbChannel を介してメッセージを受信すると、このメッセージを ActionPipeline の最初のアクションのプロセスメソッドに渡します。この場合は SystemPrintln アクションになります。
注記
ServiceInvoker は、ユーザーからのフェイルオーバーの複雑さの多くを隠すため、必要はあります。これはネイティブのメッセージでのみ機能します。さらに、すべてのゲートウェイが ServiceInvoker を使用するように変更されているわけではないため、このようなゲートウェイに近づくと、サービスのフェイルオーバーを活用できるとは限りません。

8.7. Application Service

アプリケーションサービスは、複数の個別サービスが侵害された論理サービスです。

8.8. サービスレプリケーションの仕組み

helloworld.esb などのサービスを取得し、それを Node2 および Node1 にデプロイするとどうなりますか ?レジストリーに jUDDI を使用し、1 つの中央 jUDDI データベースにアクセスできるようにすべてのノードを設定していることを前提とします。Node2 は、FirstServiceESB - SimpleListener サービスがすでに登録されていることを見つけます。したがって、このサービスに 2 番目の ServiceBinding を追加するため、このサービスには 2 つの ServiceBinding があります。したがって、Node1 がダウンすると、Node2 は機能し続けます。
両方のサービスインスタンスは同じキューをリッスンするため、負荷分散がある点に注意してください。
このタイプのレプリケーションは、サービスの可用性を高めたり、負荷分散を提供するために使用したりできます。4 つの個別のサービスで設定されるアプリケーションサービスについて考えてみましょう。それぞれのサービスは同じ機能を提供し、同じサービスコントラクトに準拠します。これらは、同じトランスポートプロトコルを共有する必要がない場合にのみ異なります。ただし、アプリケーションサービスのユーザーには、サービス名とカテゴリーで識別される単一のサービスのみが表示されていました。ServiceInvoker は、アプリケーションサービスが実際にはクライアントから 4 つの他のサービスで設定されるという事実を非表示にします。個別のサービスの失敗をマスクし、複製されたサービスグループの少なくとも 1 つのインスタンスが利用できる限り、クライアントが前進進捗できるようにします。
注記
このタイプのレプリケーションは、ステートレスサービスにのみ使用する必要があります。
サービスのレプリケーションは、サービスコンシューマーの制御外にあるサービスプロバイダーによって定義できます。そのため、メッセージの送信者がレジストリー内で記述されている場合に、別のサービスの使用にサイレントにフェイルオーバーしたくない場合があります。org.jboss.soa.esb.exceptionOnDeliverFailure メッセージプロパティーを true に設定すると、ServiceInvoker によって再試行が行われず、MessageDeliverException が出力されます。すべてのメッセージにこのアプローチを指定する場合は、JBossESB プロパティーファイルの Core セクションで同じプロパティーを定義します。

8.9. JBossMessaging

JBossMessaging はクラスターリング機能を提供するオープンソースソフトウェアです。これは、JMS サービスをクラスター化できるため、JBoss Enterprise SOA Platform 製品のクラスターリングのデフォルトプロバイダーです。

8.10. Cluster

クラスターとは、疎に接続されたコンピューターのグループであり、単一のシステムとして表示できるように連携します。クラスターのコンポーネント (またはノード) は通常、高速なローカルエリアネットワークを介して相互に接続され、各ノードは独自のオペレーティングシステムを実行します。クラスターリングミドルウェアは、ノード間のコラボレーションを調整し、ユーザーとアプリケーションがクラスターを単一のプロセッサーとして扱うことを可能にします。クラスターは、必要に応じてノードを追加することでパフォーマンスが向上するため、スケーラブルなエンタープライズアプリケーションに効果的です。さらに、1 つのノードに障害が発生した場合はいつでも、他のノードがその負荷を引き継ぐことができます。

8.11. ステートレスサービスフェイルオーバー

JBoss Enterprise SOA Platform は、ステートレスサービスにフェイルオーバー機能を提供します。1 つのノードに障害が発生した場合、サービスは別のノードで再開されます。ServiceInvoker は、フェイルオーバーの複雑さの多くをユーザーから隠しますが、ネイティブの Enterprise Service Bus メッセージでのみ機能し、さらに、すべてのゲートウェイがそれを利用するようにプログラムされているわけではありません。したがって、これらのゲートウェイ実装に送信された非 ESB 認識メッセージは、サービスフェイルオーバーを使用できない場合があります。

8.12. JMS クラスターリングの有効化

手順8.3 タスク

8.13. プロトコルクラスターリング

はじめに

JMS をクラスター化すると、アーキテクチャーから単一障害点が削除されます。

JBossESB レプリケーションと JMS クラスターリングの両方を一緒に使用できます。たとえば、サービス A は単一の JMS エンドポイント参照によってレジストリーで識別されます。ただし、クライアントに対しては、JMS エンドポイント参照はクラスター化された JMS キューを指しており、3 つのサービスをサポートするように個別に設定されています。これは、可用性および負荷分散のフェデレーションされた方法です。
注記
実際、サービスのレプリケーションをユーザーからマスクします(JBoss クラスターリングの場合のクライアント)。これらの実装の詳細をサービスエンドポイントの背後で非表示にし、コントラクトレベルで公開しないように SOA プリンシパルを使用します。
注記
このように JMS クラスターリングを使用する場合は、設定が正しく設定されていることを確認する必要があります。たとえば、JMS クラスターにすべてのサービスを配置すると、Madoop レプリケーションは恩恵を受けません。
プロバイダーがクラスターリングを提供できない場合は、複数のリスナーをサービスに追加し、複数の(JMS)プロバイダーを使用できます。ただし、これにはプロバイダー間でフェイルオーバーと負荷分散が必要であるため、次のセクションで説明します。

8.14. クラスター内の異なるノード間での同じサービスの実行

はじめに

クラスター内の複数のノードで同じサービスを実行する場合は、サービスレジストリーキャッシュが再検証されるのを待つ必要があります。その後、サービスはクラスター環境全体で実行されます。

8.15. レジストリーキャッシュのタイムアウト値の設定

手順8.4 タスク

  1. テキストエディターで deploy/jbossesb.sar/jbossesb-properties.xml ファイルを開きます: vi deploy/jbossesb.sar/jbossesb-properties.xml
  2. キャッシュのタイムアウト値を設定します。
    <properties name="core">
    <property name="org.jboss.soa.esb.registry.cache.life" value="60000"/>
    </properties>
    60 000 ミリ秒(sixty 秒)がデフォルト値であることに注意してください。
  3. ファイルを保存して終了します。

8.16. Channel Fail-Over

HelloWorld サービスは複数のプロトコルをリッスンできます。ここでは、JMS チャネルを追加しました。
...
<service category="FirstServiceESB" name="SimpleListener" description="Hello World">
    <listeners>
        <jms-listener name="helloWorld"  busidref="quickstartEsbChannel" maxThreads="1"/>
        <jms-listener name="helloWorld2" busidref="quickstartFtpChannel2" maxThreads="1"/>
    </listeners>
...
このサービスは、異なる物理ボックスにある JMS プロバイダーが提供できる 2 つの JMS キューを同時にリッスンします。これにより、2 つのサービス間の JMS 接続が冗長になります。この設定でプロトコルを組み合わせることもできます。たとえば、このコードは FTP リスナーの追加方法を示しています。
...
<service category="FirstServiceESB" name="SimpleListener"
 description="Hello World">
 <listeners>
  <jms-listener name="helloWorld" busidref="quickstartEsbChannel"
 maxThreads="1"/>
  <jms-listener name="helloWorld2" busidref="quickstartJmsChannel2"
 maxThreads="1"/>
  <ftp-listener name="helloWorld3" busidref="quickstartFtpChannel3"
 maxThreads="1"/>
  <ftp-listener name="helloWorld4" busidref="quickstartFtpChannel3"
 maxThreads="1"/>
 </listeners>
...
注記
ServiceInvoker がサービスにメッセージを配信しようとすると、8 つのエンドポイント参照(Node1 の 4 つの EPR と Node2 の 4 つの EPRs)を選択できます。使用するものを定義するには、負荷分散ポリシーを設定します。

8.17. 自動フェイルオーバーの無効化

手順8.5 タスク

  1. テキストエディターで JBossESB プロパティーファイルを開きます。
  2. org.jboss.soa.esb.exceptionOnDeliverFailure プロパティーを true に設定します。
  3. ファイルを保存して終了します。
    注記
    または、問題の特定のメッセージに同じプロパティーを true に設定すると、メッセージごとに設定できます。いずれの場合も、デフォルトは false です。

8.18. ロードバランシング

ロードバランシングは、複数のコンピューターまたはコンピュータークラスター、ネットワークリンク、中央処理装置、ディスクドライブ、またはその他のリソースにワークロードを分散して、最適なリソース使用率を達成し、スループットを最大化し、応答時間を最小化し、過負荷を回避するためのコンピューターネットワーキング手法です。単一のコンポーネントではなく、複数のコンポーネントを負荷分散とともに使用すると、冗長性によって信頼性も向上します。

8.19. 負荷分散ポリシーの設定

手順8.6 タスク

  1. グローバル設定ファイルをテキストエディターで開きます: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployers/jbossesb-properties.xml
  2. org.jboss.soa.esb.loadbalancer.policy プロパティーまでスクロールダウンします。使用するポリシーで設定します。
  3. ファイルを保存して終了します。

8.20. 負荷分散ポリシー

表8.1 利用可能な負荷分散ポリシー

ポリシー名 Description
最初に入手可能 正常なサービスバインディングが見つかった場合は、それが終了するまで使用されます。リスト内の次のエンドポイント参照が使用されます。このポリシーでは、2 つのサービスインスタンス間の負荷分散は行われません。
ラウンドロビン 各エンドポイント参照がリスト順に使用される標準の負荷分散ポリシー。
ランダムロビン これはラウンドロビンに似ていますが、選択はランダム化されます。
注記
ポリシーで使用されるエンドポイント参照リストは、デッド EPR が削除されるにつれて、時間の経過とともに小さくなる可能性があります。リストが使い果たされたとき、またはリストキャッシュの time-to-live が上限を超えると、ServiceInvoker はレジストリーから EPR の新しいリストを取得します。

8.21. トランザクションとアクションパイプライン

アクションパイプラインは、トランザクションまたはそれ自体のいずれかで実行できます。前者を実行するには、transact プロパティーを true に設定して、サービスに JCA リスナーを割り当てる必要があります。また、アプリケーションサーバーで実行しているときに TransactionManager を取得する方法も指定する必要があります。これは、JNDI ルックアップを実行して実行できます。
アクションパイプラインで作業する場合、アクションのすべての onSuccess メソッドが呼び出された後に発生するコミットフェーズ中にトランザクションをロールバックできます。パイプライン全体が依然として失敗し、コミットフェーズ中にロールバックされる可能性があります。これにより、メッセージがパイプを再試行します。

8.22. ロールバック

ロールバックは、変更前にサービスアクションを元の状態に戻します。サービスアクションをロールバックするには、ユーザーは setRollbackOnly プロパティーが現在のトランザクションに存在することを確認する必要があります。

8.23. ロールバックと JMS JCA リスナー

JMS JCA リスナーを使用してトランザクションのオーケストレーションを行う場合、再試行はメッセージキューから行われます。再試行間の再試行の最大回数と間隔をキューに設定できます。HornetQ を使用している場合は、サービスが実行されている特定のキューに対する rety ポリシーに対応する hornetq-configuration.xml を含めることができます。
<configuration xmlns="urn:hornetq"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:schemaLocation="urn:hornetq /schema/hornetq-configuration.xsd">
   <address-settings>
     <address-setting match="jms.queue.MyServiceQueue">
        <max-delivery-attempts>5</max-delivery-attempts>
        <redelivery-delay>1000</redelivery-delay>
        <max-size-bytes>10240</max-size-bytes> 
     </address-setting>
   </address-settings>                
</configuration>

8.24. メッセージの再配信

エンドポイント参照のリストに何も含まれないものの、期限切れの EPRs が含まれる場合、ServiceInvoker は以下のいずれかのことを実行できます。
  • メッセージを同期的に配信しようとすると、デフォルトで DLQ MessageStore に保存され、呼び出し元にフェイルバックする DeadLetterService にメッセージを送信します。処理は停止します。JMS キューに移動する場合や、通知を受け取る場合は、jbossesb.esb で DeadLetterService を設定することができます。
  • メッセージを非同期(推奨)に配信しようとすると、そのメッセージを DeadLetterService に送信しますが、メッセージは RDLVR MessageStore に保存されます。再配信サービス(jbossesb.esb)は、再配信の最大試行回数を超えるとメッセージの送信を再試行します。この場合、メッセージは DLQ MessageStore に保存され、処理が停止します。
注記
DeadLetterService はデフォルトでオンになっていますが、jbossesb-properties.xml では org.jboss.soa.esb.dls.redeliver を false に設定して使用をオフにすることができます。メッセージごとにこれを制御する場合は、それに応じて特定の Message プロパティーに org.jboss.soa.esb.dls.redeliver プロパティーを設定します。Message プロパティーは、グローバル設定よりも優先して使用されます。デフォルトでは、設定ファイルに設定された値が使用されます。

8.25. スケジューリング

8.25.1. Quartz Scheduler

Quartz Scheduler は、JBoss Enterprise SOA Platform のサービススケジューリング機能を構築する基盤を提供するオープンソースプロジェクトです。

8.25.2. Quartz スケジューラーの設定

以下は、JBoss Enterprise SOA Platform の Quartz スケジューラーのデフォルト設定です。
org.quartz.scheduler.instanceName = DefaultQuartzScheduler
org.quartz.scheduler.rmi.export = false
org.quartz.scheduler.rmi.proxy = false
org.quartz.scheduler.wrapJobExecutionInUserTransaction = false

org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount = 2
org.quartz.threadPool.threadPriority = 5
org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread = true

org.quartz.jobStore.misfireThreshold = 60000

org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore
これらのプロパティーを <schedule-provider> 設定に直接 <property> 要素として指定すると、新しいプロパティーを追加したり、新しいプロパティーを追加したりすることができます。たとえば、スレッドプールのサイズを 5 に増やす方法を説明します。
<schedule-provider name="schedule">
    <property name=”org.quartz.threadPool.threadCount” value=”5” />
    <cron-schedule scheduleid="cron-trigger" cronExpression="0/1 * * * * ?" />
</schedule-provider>

8.25.3. サービスのスケジューリング

JBoss Enterprise SOA Platform は、2 種類のスケジューリング機能プロバイダーをサポートします。
バスプロバイダー
これらは、JMS や HTTP などのメッセージングプロトコルを介して処理パイプラインにメッセージを提供します。このプロバイダータイプは、基盤となるメッセージングプロバイダーによってトリガーされます。
プロバイダーのスケジュール
これらは、基礎となるメッセージ配信メカニズム(ファイルシステムなど)が処理できるメッセージが利用可能な場合など、スケジュール駆動型モデルに基づいてアクション処理パイプラインにメッセージを提供します。これらは、メッセージの処理が利用可能な場合にエンタープライズサービスバスをトリガーするサポートがない場合、スケジューラーは定期的にリスナーをトリガーして新しいメッセージをチェックします。
JBoss Enterprise SOA Platform は、<schedule-listener> タイプと <simple-schedule> と <cron-schedule> の 2 つの <schedule-provider> タイプを提供します。<schedule-listener> は、org.jboss.soa.esb.listeners.ScheduledEventMessageComposer インターフェイスの実装であるcomposer クラスで設定されます。
重要
スケジューリング機能は JBoss Enterprise SOA Platform に新たに組み込まれ、すべてのリスナーがこのモデルに移行されているわけではありません。

8.25.4. 単純なスケジュール

このタイプのスケジューラーは、以下の属性から派生した機能を提供します。
scheduleid
スケジュールの一意の識別子文字列。リスナーからスケジュールを参照するために使用されます。
frequency
すべてのスケジュールリスナーがトリガーされる頻度(秒単位)。
execCount
スケジュールを実行する回数。
startDate
スケジュールの開始日時。この属性値の形式は、XML スキーマ型 "dateTime" の形式です。を参照してください http://books.xmlschemata.org/relaxng/ch19-77049.html
endDate
スケジュールの終了日および時間。この属性値の形式は、XML スキーマ型 "dateTime" の形式です。を参照してください http://books.xmlschemata.org/relaxng/ch19-77049.html
コードの例を以下に示します。
<providers>
        <schedule-provider name="schedule">
		<simple-schedule scheduleid="1-sec-trigger" frequency="1" execCount="5" />
        </schedule-provider>
</providers>

8.25.5. Cron スケジュール

このタイプの schedular は CRON 式に基づいて機能を提供します。その属性は以下のとおりです。
scheduleid
スケジュールの一意の識別子文字列。リスナーからスケジュールを参照するために使用されます。
cronExpression
CRON 式
startDate
スケジュールの開始日時。この属性値の形式は、XML スキーマ型 "dateTime" の形式です。を参照してください http://books.xmlschemata.org/relaxng/ch19-77049.html
endDate
スケジュールの終了日および時間。この属性値の形式は、XML スキーマ型 "dateTime" の形式です。を参照してください http://books.xmlschemata.org/relaxng/ch19-77049.html
コードの例を以下に示します。
<providers>
	<schedule-provider name="schedule">
		<cron-schedule scheduleid="cron-trigger" cronExpression="0/1 * * * * ?" />
        </schedule-provider>
</providers>

8.25.6. スケジュールされたリスナー

<scheduled-listener> を使用すると、<simple-schedule> または <cron-schedule> 設定に基づいてスケジュールされたタスクを実行することができます。
これは、org.jboss.soa.esb.schedule.ScheduledEventListener または org.jboss.soa.esb.listeners.ScheduledEventMessageComposer のいずれかの実装である event-processor クラスで設定されます。
ScheduledEventListener
このインターフェイスを実装するイベントプロセッサーは、onSchedule メソッドを使用して単純にトリガーされます。アクション処理のパイプラインは実行されません。
ScheduledEventMessageComposer
このインターフェイスを実装するイベントプロセッサーは、リスナーに関連付けられたアクション処理パイプラインのメッセージを破棄できます。
このリスナーの属性は次のとおりです。
  1. name: リスナーインスタンスの名前
  2. event-processor: すべてのスケジュールトリガーで呼び出されるイベントプロセッサークラス。実装の詳細については、上記 を参照してください。
  3. 以下のいずれかになります。
    1. name: リスナーインスタンスの名前。
    2. scheduleidref: このリスナーのトリガーに使用するスケジュールのスケジュール ID。
    3. schedule-frequency: スケジュール頻度(秒単位)。リスナーで直接簡単なスケジュールを指定する便利な方法。

8.25.7. スケジュールされたリスナーと Cron スケジューラーの組み合わせの設定例

以下のコードは、<scheduled-listener> と <cron-schedule> に関する設定の例を示しています。
<?xml version = "1.0" encoding = "UTF-8"?>
<jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd">

    <providers>
        <schedule-provider name="schedule">
            <cron-schedule scheduleid="cron-trigger" cronExpression="0/1 * * * * ?" />
        </schedule-provider>
    </providers>

    <services>
        <service category="ServiceCat" name="ServiceName" description="Test Service">

            <listeners>
                <scheduled-listener name="cron-schedule-listener" scheduleidref="cron-trigger" 
                     event-processor="org.jboss.soa.esb.schedule.MockScheduledEventMessageComposer" />
            </listeners>

            <actions>
                <action name="action" class="org.jboss.soa.esb.mock.MockAction" />
            </actions>			
        </service>
    </services>

</jbossesb>

第9章 フォールトトレランスおよび信頼性

9.1. システムの信頼性

はじめに

JBoss Enterprise SOA Platform には、多くのコンポーネントとサービスがあります。一部の障害は、障害が発生するタイミングに応じて、一部またはすべてのアプリケーションに気付かない場合があります。たとえば、コンシューマーが機能する必要があるサービスのすべての EPR 情報を正常に取得した後にレジストリーサービスがクラッシュした場合、クラッシュはアプリケーションに悪影響を及ぼしません。ただし、このポイントの前に失敗した場合、アプリケーションは進捗できません。したがって、信頼性の保証を決定するには、障害が発生するタイミングと、発生する可能性のある障害のタイプを考慮する必要があります。

信頼性およびフォールトトレランスの合計を保証することはできません。ハードウェア障害とヒューマンエラーを軽減できません。ただし、システムが一般的に障害を許容し、データの整合性を維持し、進捗を行えるようにすることができます。トランザクションやレプリケーションなどのフォールトトレランス技術は、常にパフォーマンスにコストがかかります。パフォーマンスとフォールトトレランス間のこのトレードオフは、アプリケーションに関する知識で実現するのが最適です。すべてのアプリケーションに特定のアプローチを均一に課すと、必要のない状況でパフォーマンスが低下します。そのため、JBoss Enterprise SOA Platform がサポートするフォールトトレランス技術の多くがデフォルトで無効になっていることがわかります。必要な場合にのみ有効にする必要があります。

9.2. Fault Tolerance

耐障害性のあるシステムは、コンポーネントの障害であっても、指定した目的を達成するために設計されたシステムです。通常、フォールトトレランスを提供する手法には、一貫した状態回復メカニズムと障害のあるコンポーネントによるエラー検出のためのメカニズムが必要です。レプリケーションやトランザクションなど、さまざまなフォールトトレランス技術が存在します。

9.3. 依存性

依存性は、提供するサービス(ユーザーが認識する動作)に限らないように、コンポーネントの信頼性として定義されます。 コンポーネントの信頼性は、継続的に正しいサービス配信の測定です。システムが提供するサービスが仕様に準拠しなくなった場合に、障害が発生します。エラーは、障害の原因となる信頼できるシステム状態の一部であり、障害はエラーの原因として定義されます。

9.4. メッセージの損失

多くの分散システムは、ポイントツーポイント(1 つのコンシューマーとプロバイダー)またはグループベース(多数のコンシューマーと 1 つのプロバイダー)のいずれかの信頼できるメッセージ配信をサポートします。障害が存在する場合でも、信頼性に制限されるセマンティクスは、通常メッセージが配信されるか、送信者が受信側に到達できなかったことを通知します。多くの場合、信頼できるメッセージング実装を使用するシステムは、受信者に配信されるメッセージと、受信者によって処理されるメッセージを区別します。たとえば、メッセージをサービスに送信するだけでは、同じサービスの後続のクラッシュが発生した場合は、メッセージの内容で作業する時間がかかっていました。
JBoss Enterprise SOA Platform 内では、JMS はメッセージ配信と処理の失敗セマンティクスを提供する唯一のトランスポートです。トランザクションセッション( JMSEprの任意部分)を使用する場合、障害発生時にメッセージが受信および処理されることを保証することができます。サービスによる処理中に障害が発生した場合、メッセージは後で再処理するために JMS キューに戻されます。ただし、トランザクションセッションは非トランザクションセッションよりもはるかに遅くなる可能性があるため、注意して使用する必要があります。
製品がサポートする他のトランスポートにはトランザクションまたは信頼できる配信の保証が含まれるため、メッセージが失われる可能性があります。ただし、ほとんどの場合、これが発生する可能性は小さくなります。送信側と受信側の同時障害(許容可能だがプローブできない)がない限り、送信者はメッセージ配信の失敗について JBoss Enterprise SOA Platform によって通知されます。処理中に受信側が失敗し、応答が想定される場合、受信側は最終的にタイムアウトし、再試行できます。
注記
非同期メッセージ配信を使用すると、障害の検出/発行が困難になる可能性があります(実際には、理論的には実現できなくなります)。アプリケーションの開発時には、この要素を考慮する必要があります。
このような理由から、メッセージのフェイルオーバーおよび再配信プロトコルを使用することが適切なアプローチです。サービスの障害が疑われる場合は、別の EPR (利用可能な場合を想定)を選択し、これを使用します。ただし、この障害の疑わしい場合は、複数のサービスが同じメッセージで同時に操作する可能性があります。したがって、フェイルオーバーのより堅牢なアプローチを提供しますが、注意して使用する必要があります。サービスがステートレスでべき等である場合に最適に機能します。(つまり、同じメッセージを複数回実行することは、1 回実行するのと同じです。)
多くのサービスやアプリケーションの場合、このタイプの再配信メカニズムは問題ありません。単一の EPR で提供する堅牢な利点は、大きな利点になります。機能しない障害モード(クライアントおよびサービスが失敗する場合や誤って失敗した場合など)は比較的一般的ではありません。サービスをべき等にできない場合は、JMS を使用するか、またはサービスをコードして、再送信を検出し、同じ作業を同時に実行する複数のサービスに対応できるようにする必要があります。

9.5. 終了点の失敗

障害が発生したマシンが回復するまで、クラッシュしたマシンと、単に非常に遅いマシン間の差異を判別することはできません。さらに、ネットワークはパーティション化できるため、さまざまなコンシューマーが利用可能なサービスに異なるビューを持つ可能性があります。

9.6. サポート対象のクラッシュリカバリーモード

トランザクションまたは JMS などの信頼できるメッセージ配信プロトコルを使用している場合、JBoss Enterprise SOA Platform は、システム障害の合計は発生しないクラッシュ障害のみを許容し、関係するエンドポイントがまだ alive であるかどうかについて多義性なしにアプリケーションを推論できるようにします。メッセージを受信する前にサービスが正常にクラッシュまたはシャットダウンした場合は、JMS 以外のトランスポートを安全に使用できます。

9.7. Message Failure, Component by Component

ゲートウェイ
ゲートウェイによってメッセージが受け入れられると、信頼できないトランスポートを使用してレートされない限り、メッセージは失われません。JMS、FTP、および SQL は、メッセージを確実に配信するか、システムから削除しないように JBossESB トランスポートを設定できます。ただし、この方法で HTTP を設定することはできません。
ServiceInvoker
ServiceInvoker は、再配信が非同期的に送信された場合は、再配信キューに配信できないメッセージを配置します。失敗した同期メッセージ配信は、送信側に即座に示されます。ServiceInvoker が正常に機能するには、トランスポートが送信者への配信に失敗したことを示す必要があります。送信側と受信側が同時に障害が発生すると、メッセージが失われる可能性があります。
JMS Broker
JMS ブローカーに配信できないメッセージは、再配信キュー内に配置されます。エンタープライズデプロイメントでは、クラスター化された JMS ブローカーが推奨されます。
アクションパネル
サービスが存在するコンテナーによって受信され、最終的な宛先によって処理されているメッセージを区別することが重要です。Action パイプライン内で処理中にエラーやクラッシュが発生して、その損失が発生するのは、メッセージが正常に配信される可能性があります。前述のように、一部の JBossESB トランスポートを設定して、受信したメッセージを処理中に削除しないようにすることができます。そのため、エラーやクラッシュが発生した場合は失われません。

9.8. 障害のリスクを最小限に抑える方法

以下は、障害によるデータ損失のリスクを最小限に抑えるためのいくつかの方法です。
  • ステートレスおよびべき等サービスを開発しようとします。これができない場合は、MessageID を使用してメッセージを特定し、アプリケーションが再送信の試行を検出できるようにします。メッセージ送信を再試行する場合は、同じ MessageID を使用します。べき等ではなく、再送信されたメッセージを受信すると、同じ作業のやり直すことの影響を受けるサービスは、トランザクションを使用して MessageID に対する状態遷移を記録することが推奨されます。ステートレスサービスに基づくアプリケーションも、より優れたスケーリングを行う傾向があります。
  • ステートフルサービスを開発する場合は、トランザクションと(クラスター化された)JMS 実装を使用します。
  • レジストリーをクラスター化し、クラスター化された/フォールトトレラントバックエンドデータベースを使用して、単一障害点を削除します。
  • オブジェクトストアが高可用性のデータベースでサポートされることを確認します。
  • サービスおよびサービスのどの操作に信頼性とフォールトトレランス機能を必要とするかを明確に特定します。これにより、これらのサービスで JMS 以外のトランスポートをターゲットにし、アプリケーションの全体的なパフォーマンスを向上させることができます。JBossESB は異なる EPR を介して同時にサービスを使用できるため、アプリケーション固有の要件に基づいて、これらの異なるサービス品質(QoS)を異なるコンシューマーに提供することもできます。
  • ネットワークパーティションを使用すると、サービスが失敗したかのように表示される可能性があるため、クラッシュしたと誤って識別できないサービスに対して、このタイプの障害が発生する可能性が高くなっています。
  • 一部の状況(HTTP など)は、メッセージが処理されてからサーバーがクラッシュすると、応答する前に別のサーバーが同じ作業を行う可能性があります。これは、サービスがメッセージを受信して処理した後に失敗したマシンと、メッセージを受信して処理しないマシンを区別できないためです。
  • 非同期(一方向)配信パターンを使用すると、サービス障害の検出が困難になります。リクエストへの応答が任意のタイミングで発生する可能性がある場合は、通常、失われたメッセージまたは遅延メッセージの概念はありません。応答がまったくない場合は、障害検出がより問題になり、メッセージに到達しないかどうかを判断するためにアプリケーションセマンティクスに依存する必要がある場合があります(たとえば、銀行アカウントの費用量が期待に一致しません)。ServiceInvoker または Couriers を使用して非同期メッセージを提供する場合、各操作(例:deliverAsync)から返されると、メッセージがサービスによって動作されたわけではありません。
  • メッセージストアは再配信プロトコルによって使用されます。ただし、これは堅牢性を改善するためにベストエフォートプロトコルであり、トランザクションや信頼できるメッセージ配信を使用しません。つまり、特定の障害により、メッセージが完全に失われるか(クラッシュ前にストアに書き込まれません)、複数回配信(再配信メカニズムはストアからメッセージをプルし、正常に配信しますが、メッセージをストアから削除できないクラッシュが発生することを意味します)。 リカバリー時に、メッセージが再び配信されます。
  • FTP などの一部のトランスポートは、処理されたメッセージを保持するように設定できますが、処理されていないメッセージと区別するために一意にマークされます。デフォルトのアプローチは、処理後にメッセージを削除することがよくありますが、このデフォルトを変更して、障害からの復旧時にアプリケーションが処理したメッセージを判断することもできます。

第10章 サービス設定の定義

10.1. 製品の設定の概要

はじめに

JBoss Enterprise SOA Platform の設定設定は jbossesb-1.3.0 XSD スキーマ()に基づいていhttp://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.3.0.xsdます。この XSD は、製品を設定するための具体的な参照です。ここでは紹介テキストが表示されます。

このモデルには、以下の 2 つの主要なセクションがあります。
  1. <globals>
  2. <providers>: モデルの <services> セクション内で定義される、メッセージ <listener> が使用するすべてのメッセージ <bus> プロバイダーを定義します。
  3. <services>: JBoss Warehouse の単一インスタンスの制御下にあるすべてのサービスを定義します。各 <service> インスタンスには、ゲートウェイまたはメッセージ Aware リスナー定義のいずれかが含まれます。
注記
このモデルに基づいて設定を作成する最も簡単な方法は、JBoss Developer Studiohttp://www.jboss.com/products/devstudio/()を使用することです。これにより、設定の編集時に、作成者に自動補完機能が提供されます。ファイル -> Open With -> XML Editor を右クリックします。

10.2. プロバイダー

設定ファイルの <providers> 部分は、Madobe の単一インスタンスのメッセージ <provider> インスタンスをすべて定義します。

10.3. プロバイダーのタイプ

現在、2 種類のプロバイダーがサポートされています。
  • バスプロバイダー:イベント駆動型プロバイダーのプロバイダーの詳細を指定します。つまり、プッシュされたメッセージであるリスナー用です。このプロバイダータイプの例は <jms-provider> です。
  • プロバイダーのスケジュール設定:スケジュール駆動型リスナー(つまり、メッセージをプルするリスナー)のプロバイダー設定。
<jms-provider> などのバスプロバイダーには、複数の <bus> 定義を含めることができます。<provider> には、その <property> インスタンスに共通するプロバイダー固有のプロパティーに関連する <bus> インスタンスを持つこともできます。<provider>たとえば、JMS には connection-factory、jndi-context-factory などがあります。同様に、<bus> の各インスタンスには、その <bus> インスタンスに固有の <property> インスタンスを付けることができます。たとえば、JMS には destination-type、destination-name などがあります。)
たとえば、JMS のプロバイダー設定は以下のようになります。
    <providers>
          <jms-provider name="JBossMQ" connection-factory="ConnectionFactory">
              <jms-bus busid="Reconciliation">
                  <jms-message-filter
                      dest-type="QUEUE"
                      dest-name="queue/B"
                   />
              </jms-bus>
          </jms-provider>
      </providers>>
重要
Red Hat は、これらのタイプの特殊な拡張を使用して設定を作成することを推奨します(例:JMS の場合は <jms-provider> および <jms-bus>)。上記の設定で最も重要な部分は、<jms-bus> インスタンスで定義される busid 属性です。これは、<bus> 要素/タイプの必須属性です(<jms-bus> など、すべての特殊化を含む)。この属性は <listener> 設定内で使用され、リスナーがメッセージを受信する <bus> インスタンスを参照します。

10.4. サービス

設定の <services> 部分は、Enterprise Service Bus のこのインスタンスの管理下にある各サービスを定義します。これは、一連の <service> 設定として定義します。

10.5. サービスの属性

<service> は以下の属性を持つことができます。

表10.1 service 属性

名前 説明 必須
name Service Registry にサービスを登録する名前。 xsd:string true
category サービスがレジストリーに登録されているサービスカテゴリー。 xsd:string true
description レジストリーに保存されているサービスの人間が判読できる説明。 xsd:string true
<service> は <listeners> のセットと <actions> のセットを定義できます。設定モデルは、ベース <listener> タイプと、サポートされている各トランスポートの特殊化を定義します(<jms-listener>、<sql-listener> など)。

10.6. リスナーの属性

base <listener> には以下の属性があります。これらの属性定義は、すべての <listener> エクステンションによって継承されます。そのため、InVM などの JBoss Enterprise SOA Platform がサポートするすべてのリスナーおよびゲートウェイに設定できます。

表10.2 listener 属性

名前 説明 必須
name リスナーの名前。この属性は主にロギングの目的で必要になります。 xsd:string true
busrefid リスナーインスタンスがメッセージを受信する <bus> の busid への参照。 xsd:string true
maxThreads リスナーがアクティブにできる同時メッセージ処理スレッドの最大数。 xsd:int True
is-gateway リスナーインスタンスがゲートウェイまたはメッセージアウェアリスナーであるかどうか。
メッセージバスは、特定のメッセージチャネルまたはトランスポートの詳細を定義します。
xsd:boolean true
リスナーは、ゼロまたはそれ以上の <property> 要素のセットを定義できます(<provider> 要素および <bus> 要素/タイプと同様)。これらは、リスナー固有のプロパティーを定義するために使用されます。
注記
サービスで定義された各ゲートウェイリスナーについて、Mutual-aware (または native)リスナーも定義する必要があります。これは、ゲートウェイリスナーが双方向エンドポイントを定義しないため、代わりに、起動ポイントが pidgin に定義されるためです。2009 内からゲートウェイにメッセージを送信することはできません。また、ゲートウェイはエンドポイントではないため、レジストリーに Endpoint Reference (EPR)が永続化されないことに注意してください。
以下は、<bus> を参照する <listener> の例です。
<?xml version = "1.0" encoding = "UTF-8"?>
<jbossesb xmlns="http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.3.0.xsd"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.3.0.xsd http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.3.0.xsd"
    parameterReloadSecs="5">
    <providers>
          <jms-provider name="JBossMQ" connection-factory="ConnectionFactory">
               <jms-bus busid="Reconciliation">
                  <jms-message-filter
                      dest-type="QUEUE"
                      dest-name="queue/B"
                   />
               </jms-bus>
<!-- busid --> <jms-bus busid="ReconciliationEsb">
                  <jms-message-filter
                      dest-type="QUEUE"
                      dest-name="queue/C"
               </jms-bus>
          </jms-provider>
      </providers>
      <services>
          <service category="Bank" name="Reconciliation"
                   description="Bank Reconciliation Service">
              <listeners>
<!-- busidref --> <jms-listener name="Bank-Listener"
                      busidref="Reconciliation"
                      is-gateway="true"/>
                  <jms-listener name="Bank-Esb"
                      busidref="ReconciliationEsb"/>
              </listeners>
              <actions>
                   ....
              </actions>
          </service>
      </services>
</jbossesb>

10.7. アクション

アクションには通常、(リスナーを介して)サービスによって受信されるメッセージのペイロードを処理するためのロジックが含まれます。アクションには、外部サービスまたはエンティティーによって使用されるメッセージの変換ロジックまたはルーティングロジックが含まれる場合があります。サービスには、常に 1 つ以上のアクションの一覧が必要です。アクションは通常テンプレートとして機能するため、外部設定オプションを設定して機能させる必要があります。

10.8. アクションの属性

<action> 要素には以下の属性があります。

表10.3 action 属性

名前 説明 必須
name アクションの名前。この属性は主にロギングの目的で必要になります。 xsd:string true
class アクションクラスは、org.jboss.soa.esb.actions.AbstractActionLifecycle、org.jboss.soa.esb.actions.ActionPipelineProcessor のいずれかを拡張する必要があります。 xsd:string true
process メッセージ処理のために反映的に呼び出されるプロセスメソッドの名前(デフォルトはプロセスメソッドです)。 xsd:int false
<actions> セット内の <action> インスタンスのリストでは、<action> インスタンスが <actions> セットに表示される順序で呼び出されます(つまり、プロセスメソッドが呼び出されます)。各 <action> から返されるメッセージは、リスト内の次の <action> への入力メッセージとして使用されます。
このモデルの他の多くの要素/タイプと同様に、<action> タイプにはゼロ以上の <property> 要素インスタンスを含めることもできます。<property> 要素/タイプは、標準の name-value-pair を定義するか、フリーフォームコンテンツ(xsd:any)を含めることができます。XSD によると、このフリー形式のコンテンツは、設定(<provider>、<bus>、<listener>、および任意の派生製品)に関係なく、<property> 要素/タイプの子コンテンツとして有効です。ただし、このフリーフォームの子コンテンツが使用される <action> で定義された <property> インスタンスにのみあります。
アクションは、org.jboss.soa.esb.actions.ActionProcessor クラスを介して実装されます。このインターフェイスのすべての実装には、以下の形式のパブリックコンストラクターが含まれている必要があります。
public ActionZ(org.jboss.soa.esb.helpers.ConfigTree configuration);
このコンストラクターが提供する ConfigTree インスタンスを通じて、アクション <property> インスタンスのフリーフォームコンテンツを含むすべてのアクション属性が利用可能になります。フリーフォームコンテンツは、ConfigTree インスタンスの子コンテンツとして提供されます。
以下は、<actions> 設定の例です。
<actions>
    <action name="MyAction-1" class="com.acme.MyAction1"/>
    <action name="MyAction-2" class="com.acme.MyAction2">
        <property name="propA" value="propAVal" />
    </action>
    <action name="MyAction-3" class="com.acme.MyAction3">
        <property name="propB" value="propBVal" />
        <property name="propC">
            <!-- Free form child content... -->
            <some-free-form-element>zzz<some-free-form-element>
        </property>
    </action>
</actions>

10.9. トランスポート固有の設定の実装

JBoss Enterprise SOA Platform 設定モデルには、<provider><bus>、および <listener> (JMS、SQL など)のトランスポート固有のバリアントがあります。 これらの特別なバリアントのいずれかを使用すると、設定の検証が強化されます。これらの特殊化は、製品によってサポートされる各トランスポートの設定要件を明示的に定義します。
注記
特定の実装のいずれかを使用すると、XSD 対応の XML エディター(JBoss Developer Studio など)を使用している場合は設定が容易になります。
重要
Red Hat は、JBoss MRG 設定の作成時に、ベースタイプの代わりにこれらの特殊なタイプを使用することを推奨します。唯一のバリエーションは、新しいトランスポートが公式の製品リリース外でサポートされている場合です。
トランスポート固有の代替手段から設定を作成する際にも、ベースタイプから設定を作成するときに適用される同じ基本プリンシパルが適用されます。
  1. プロバイダー設定を定義します(例:<jms-provider>)。
  2. バス設定を新しいプロバイダー(<jms-bus> など)に追加し、一意の busid 属性値を割り当てます。
  3. <services> を通常として定義します。これは、単に作成した新しいバス設定を参照(busidref を使用)するトランスポート固有のリスナー設定(<jms-listener> など)を追加します。(例:<jms-bus> を参照する <jms-listener>)。
これらのトランスポート固有のタイプを使用する場合に適用される唯一のルールは、あるタイプのリスナーから別のタイプのバスに相互参照できないことです。つまり、<jms-listener> から <jms-bus> のみを参照できます。ランタイムエラーで、相互参照が作成されます。
そのため、この製品にあるトランスポート固有の実装は以下のとおりです。
  1. jms: <jms-provider>、<jms-bus>、<jms-listener> および <jms-message-filter>: <jms-message-filter> は、<jms-bus> または <jms-listener> 要素のいずれかに追加できます。ここで、<jms-provider> および <jms-bus> は JMS 接続プロパティーを指定します。ここで、<jms-message-filter> は実際のメッセージ QUEUE/TOPIC とセレクターの詳細を指定します。
  2. SQL: <sql-provider>、<sql-bus>、<sql-listener> および <sql-message-filter>: <sql-message-filter> は、<sql-bus> または <sql-listener> 要素のいずれかに追加できます。<sql-provider> および <sql-bus> は JDBC 接続プロパティーを指定し、<sql-message-filter> はメッセージ/行の選択と処理プロパティーを指定します。
  3. ftp: <ftp-provider>、<ftp-bus>、<ftp-listener> および <ftp-message-filter>: <ftp-message-filter> は、<ftp-bus> または <ftp-listener> 要素のいずれかに追加できます。<ftp-provider> および <ftp-bus> は FTP アクセスプロパティーを指定します。<ftp-message-filter> はメッセージ/ファイルの選択と処理プロパティーを指定します。
  4. hibernate: <hibernate-provider>、<hibernate-bus>、<hibernate-listener> : <hibernate-message-filter> は <hibernate-bus> または <hibernate-listener> 要素のいずれかに追加できます。ここで、<hibernate-provider> は hibernate 設定プロパティーの場所などのファイルシステムのアクセスプロパティーを指定し、<hibernate-message-filter> はリッスンするクラス名およびイベントを指定します。
  5. ファイルシステム:<fs-provider>、<fs-bus>、<fs-listener>、および <fs-message-filter> は、<fs-bus> または <fs-listener> 要素のいずれかに追加できます。ここで、<fs-provider> および <fs-bus> は File System アクセスプロパティーを指定し、<fs-message-filter> はメッセージ/ファイルの選択と処理プロパティーを指定します。
  6. schedule: <schedule-provider>.これは特別なタイプのプロバイダーで、上記のバスベースのプロバイダーとは異なります。詳細は、Scheduling を参照してください。
  7. JMS/JCA 統合:<jms-jca-provider>: このプロバイダーは <jms-provider> の代わりに使用して、JCA インフローを使用した受信メッセージの配信を有効にすることができます。これにより、アクションパイプラインにトランザクションフローが導入され、JTA トランザクション内のアクションが含まれます。
各トランスポート固有のタイプには、base に存在しない追加の要素が含まれます。これは <*-message-filter> です。この要素は、<*-bus> または <*-listener> 内に追加できます。両方の場所でこの要素を使用する場合は、バスに対してグローバルにメッセージフィルターリングを指定できます(つまり、バスを使用するすべてのリスナーに対して)。またはローカル(リスナーバイリスナーベース)を指定できます。

表10.4 JMS メッセージフィルターの設定

Property Name Description 必須
dest-type 宛先のタイプ(QUEUE または TOPIC のいずれか)。 はい
dest-name キューまたはトピックの名前 はい
selector このメッセージセレクターでフィルターリングする同じキュー/トピックで複数のリスナーを登録できるようにします。 いいえ
永続 JMS の配信モードを永続化する必要があるかどうかを示します。true または false に設定します。(デフォルトは true です。) いいえ
acknowledge-mode JMS セッション確認モード。AUTO_ACKNOWLEDGE、CLIENT_ACKNOWLEDGE、DUPS_OK_ACKNOWLEDGE のいずれかです。デフォルトは AUTO_ACKNOWLEDGE です。 いいえ
jms-security-principal JMS 宛先ユーザー名。これは、宛先への接続の作成時に使用されます。 いいえ
jms-security-credential JMS 宛先パスワード。これは、宛先への接続の作成時に使用されます。 いいえ
以下は、設定例です。
 <jms-bus busid="quickstartGwChannel">
     <jms-message-filter
         dest-type="QUEUE"
         dest-name="queue/quickstart_jms_secured_Request_gw"
         jms-security-principal="esbuser"
         jms-security-credential="esbpassword"/>
</jms-bus>

表10.5 JMS リスナーの設定

Property Name Description 必須
name リスナー名。 はい
busrefid リッスンする JMS バスの ID。 いいえ
is-gateway この JMS リスナーインスタンスはゲートウェイであるか、またはメッセージ対応のリスナーです。 いいえ。デフォルトは false です。
maxThreads JMS バスでメッセージをリッスンしているときに使用するスレッドの最大数。is-gateway が false の場合のみ関連します。 いいえ。デフォルトは 1 です。
clientId JMS 接続に関連付けるクライアント ID。接続とそのオブジェクトを、プロバイダーによってクライアントの代わりに維持される状態に関連付けるために使用されます。(例:永続サブスクリプション)。 いいえ。clientId が必要な場合(例:durableSubscriptionName が指定されている場合)、が指定されていない場合、デフォルトはリスナー名になります。
durableSubscriptionName 永続的なサブスクリプション名。 いいえ。JMS トピックにのみ関連します。

10.10. ファイルシステムプロバイダーの設定

以下のファイルシステムプロバイダーの設定オプションは、fs-bus に含まれるファイルシステムメッセージフィルター(fs-message-filter)内で利用できます。適切な例については、helloworld_file_action クイックスタートを参照してください。
注記
以下のディレクトリーオプションについては、指定した各ディレクトリーが存在し、アプリケーションサーバーのユーザーにディレクトリーへの読み取りおよび書き込みパーミッションの両方が必要です。これにより、ファイルを移動し、名前を変更する必要があります。

表10.6 ファイルシステムメッセージフィルターの設定

プロパティー Description 必須
directory 受信ファイルを監視するディレクトリー。 はい
input-suffix 受信ファイルのフィルターに使用される接尾辞。. (.esbIn など)で 1 文字以上である必要があります。 はい
work-suffix ファイルの処理時にファイルが使用される場合に使用される接尾辞。デフォルトは.esbInProcess です。 いいえ
post-suffix ファイルが正常に処理されたときに使用される接尾辞。デフォルトは.esbDone です。 いいえ
post-delete true の場合、ファイルは処理された後に削除されます。この場合、ディレクトリー後および post-suffix は効果がありません。デフォルトは true です。 いいえ
post-directory ファイルの処理後にファイルが移動されるディレクトリー。デフォルトは上記のディレクトリーの値に設定されます。 はい
post-rename true の場合、ファイルの名前は処理後に変更されます。post-rename および post-delete オプションは相互に排他的であることに注意してください。 いいえ
error-delete true の場合、処理中にエラーが発生した場合にファイルが削除されます。この場合、error-directory および error-suffix は効果がありません。デフォルトは true です。 いいえ
error-directory 処理中にエラーが発生した場合にファイルを移動する FTP ディレクトリー。デフォルトは上記のディレクトリーの値に設定されます。 はい
error-suffix 処理中にエラーが発生するとファイル名に追加される接尾辞。デフォルトは .esbError です。 いいえ

10.11. FTP プロバイダーの設定

表10.7 FTP プロバイダーの設定

プロパティー Description 必須
hostname ポート 21 を使用する <host> だけの <host:port> の組み合わせを指定できます。 はい
username FTP 接続に使用されるユーザー名。 はい
password 上記のユーザーのパスワード はい
directory 新しいファイル用に監視される FTP ディレクトリー はい
input-suffix インストラクターが使用するファイルのフィルターに使用されるファイルの接尾辞(ドットの追加など、.esbIn など)。これは、空の文字列として指定することで、すべてのファイルを取得するように指定することもできます。 はい
work-suffix ファイルの処理中に使用されるファイル接尾辞。これにより、別のスレッドまたはプロセスも選択されなくなります。デフォルトは .esbInProcess です。 いいえ
post-delete true の場合、ファイルは処理された後に削除されます。この場合、ディレクトリー後および post-suffix は効果がないことに注意してください。デフォルトは true です。 いいえ
post-directory ファイルの処理後にファイルが移動される FTP ディレクトリー。デフォルトは上記のディレクトリーの値に設定されます。 いいえ
post-suffix 処理後にファイル名に追加されるファイルの接尾辞。デフォルトは .esbDone です。 いいえ
error-delete true の場合、処理中にエラーが発生した場合にファイルが削除されます。この場合、error-directory および error-suffix は効果がないことに注意してください。デフォルトは true です。 いいえ
error-directory 処理中にエラーが発生した場合にファイルを移動する FTP ディレクトリー。デフォルトは上記のディレクトリーの値に設定されます。 いいえ
error-suffix 処理中にエラーが発生するとファイル名に追加される接尾辞。デフォルトは .esbError です。 いいえ
protocol プロトコルは以下のいずれかになります。
  • SFTP (SSH ファイル転送プロトコル)
  • FTPS (SSL 経由の FTP)
  • FTP (デフォルト)。
いいえ
passive FTP 接続がパッシブモードであることを示します。これを true に設定すると、FTP クライアントは ftpserver への 2 つの接続を確立します。デフォルトは false で、クライアントは FTP サーバーに接続先となるポートを指示します。その後、FTP サーバーはクライアントへの接続を確立します。 いいえ
read-only true の場合、FTP サーバーはファイルの書き込み操作を許可しません。この場合、work-suffix、post-delete、post-directory、post-suffix、post-delete、error-directory、および error-suffix プロパティーは影響を受けないことに注意してください。デフォルトは false です。詳細は、読み取り専用 FTP リスナー を参照してください。 いいえ
certificate-url FTPS サーバー検証のパブリックサーバー証明書への URL、または SFTP クライアント検証のプライベート証明書への URL。SFTP 証明書は、デプロイメントアーティファクト内に埋め込まれたリソースとして配置できます。 いいえ
certificate-name FTPS サーバー検証の証明書の共通名 いいえ
certificate-passphrase SFTP クライアント検証用の秘密鍵のパスフレーズ。 いいえ
設定されたスケジュール(scheduleidref)に基づいてリモートファイルをポーリングする schedule リスナーを設定できます。
ftp-provider プロパティー read-only を true に設定すると、リモートファイルシステムが書き込み操作を許可しないことをシステムに指示します。これは、特定のファイルにパーミッションが付与されるイントラネットコンピューターで FTP サーバーが実行されている場合によくあります。
読み取り専用実装は JBoss TreeCache を使用して取得されたファイル名の一覧を保持し、以前に取得されていないファイル名のみを取得します。キャッシュを、キャッシュローダーを使用して安定したストレージに永続化するように設定する必要があります。
注記
キャッシュからファイル名を削除するストラテジーが存在する必要があります。企業には、定期的にファイルを別の場所に移動するアーカイブプロセスが存在する可能性があります。キャッシュからファイル名を削除するには、数日ごとにすべてのファイル名をキャッシュから削除するデータベースの手順を使用できます。別のストラテジーでは、キャッシュからファイル名をエビクトすると、cacheloader からファイル名も削除される TreeCacheListener を指定します。その後、エビクション期間は設定可能になります。これは、ftp-listener 設定でプロパティー(removeFilesystemStrategy-cacheListener)を設定することで設定できます。

表10.8 読み取り専用 FTP リスナー設定

名前 Description
scheduleidref FTP リスナーによって使用されるスケジュール。サービススケジューリング を参照してください。
remoteFileSystemStrategy-class リモートファイルシステムストラテジーを、実装するクラスで上書きします( org.jboss.soa.esb.listeners.gateway.remotestrategies.RemoteFileSystemStrategy )。デフォルトは org.jboss.soa.esb.listeners.gateway.remotestrategies.ReadOnlyRemoteFileSystemStrategyです。
remoteFilesystemStrategy-configFile ローカルファイルシステムまたはクラスパスに存在する JBoss TreeCache 設定ファイルを指定します。デフォルトでは、クラスパスのルートにある /ftpfile-cache-config.xml という名前のファイルを検索します。
removeFilesystemStrategy-cacheListener TreeCache で使用される JBoss TreeCacheListener 実装を指定します。デフォルトは TreeCacheListener ではありません。
maxNodes キャッシュに保存されるファイルの最大数。0 は制限なしを示します
timeToLiveSeconds ノードがスイプされるまでのアイドル時間(秒単位)。0 は制限なしを示します
maxAgeSeconds ノードがスイプアウトされるまでのアイドル時間に関係なく、オブジェクトは TreeCache (秒単位)に存在する必要がある時間。0 は制限なしを示します
以下は、設定例です。
<ftp-listener name="FtpGateway"
    busidref="helloFTPChannel"
    maxThreads="1"
    is-gateway="true"
    schedule-frequency="5">
    <property name="remoteFileSystemStrategy-configFile" value="./ftpfile-cache-config.xml"/>
     <property name="remoteFileSystemStrategy-cacheListener" value=
         "org.jboss.soa.esb.listeners.gateway.remotestrategies.cache.DeleteOnEvictTreeCacheListener"/>

</ftp-listener>
以下は、JBoss Cache コンポーネントの設定方法を示すサンプルコードです。
<region name="/ftp/cache">
	<attribute name="maxNodes">5000</attribute>
	<attribute name="timeToLiveSeconds">1000</attribute>
	<attribute name="maxAgeSeconds">86400</attribute>
</region>

表10.9 設定

プロパティー Description コメント
maxNodes キャッシュに保存されるファイルの最大数。 0 は制限なしを示します
timeToLiveSeconds ノードがスイプされるまでのアイドル時間(秒単位)。 0 は制限なしを示します
maxAgeSeconds ノードがスイプアウトされるまでのアイドル時間に関係なく、オブジェクトは TreeCache (秒単位)に存在する必要がある時間 0 は制限なしを示します
注記
helloworld_ftp_action クイックスタートは読み取り専用設定を示しています。クイックスタートの実行手順については、helloworld_ftp_action クイックスタートディレクトリーでant help を実行します。

10.12. UDP ゲートウェイ

UDP ゲートウェイを使用すると、ユーザーデータグラムプロトコルを使用して送信される機能と認識されないメッセージを受信できます。このゲートウェイを介して到達したメッセージのペイロードは、デフォルトのAppender Message オブジェクトの場所にあるアクションパイプラインに渡されます。

10.13. UDP ゲートウェイの設定

アクション内から esbMessage.getBody ().get ()メソッドを呼び出し、UDP ゲートウェイ経由で送信されるメッセージからバイトアレイペイロードを取得します。
ゲートウェイを設定するオプションを以下に示します。

表10.10 UDP ゲートウェイの設定

プロパティー Description コメント
ホスト リッスンするホスト名/IP。 必須。
ポート リッスンするポート。 必須。
handlerClass org.jboss.soa.esb.listeners.gateway.mina.MessageHandler の具体的な単純化。 オプション:デフォルトは org.jboss.soa.esb.listeners.gateway.mina.DefaultMessageHandler です。
is-gateway UDPGatewayListener はゲートウェイとしてのみ機能します。 必須。
以下は、設定例です。
<udp-listener 
   name="udp-listener" 
   host="localhost" 
   port="9999"
   handlerClass="org.jboss.soa.esb.listeners.gateway.mina.DefaultMessageHandler"
   is-gateway="true"
<udp-listener/>

10.14. JBoss Remoting Gateway

JBoss Remoting Gateway はオープンソースの JBoss Remoting コンポーネントを JBoss Enterprise SOA Platform にフックし、別のトランスポートオプションを提供します。ゲートウェイは、JBoss Remoting コンポーネントを介した HTTP (S)およびソケット(+SSL)のサポートを利用します。

10.15. JBoss Remoting Gateway の設定

JBoss Remoting プロバイダーの基本設定は次のとおりです。
<jbr-provider name="socket_provider" protocol="socket" host="localhost">
    <jbr-bus busid="socket_bus" port="64111"/>
</jbr-provider>
<jbr-bus> は、<jbr-listener> で <service> 設定から参照できます。
<listeners>
    <jbr-listener name="soc" busidref="socket_bus" is-gateway="true"/>
</listeners>
重要
<jbr-listener> はゲートウェイとしてのみサポートされます。is-gateway を false に設定すると、エラーが発生します。
<jbr-provider>、<jbr-bus>、または <jbr-listener> 要素のいずれかで JBoss Remoting Gateway に次の設定オプションを設定できます(これらは <property> 要素として設定します)。

表10.11 設定

名前 説明 デフォルト
同期 は、同期的に呼び出されるターゲットサービスです。 True
serviceInvokerTimeout 非同期呼び出しのタイムアウト。 20000
asyncResponse 非同期応答。 "<ack/>
securityNS これは、使用する必要のある Web Service Security バージョンの名前空間です。この名前空間は、SOAP メッセージのセキュリティーヘッダーを照合するために使用されます。これにより、Enterprise Service Bus がこれらのヘッダーからセキュリティー情報を抽出できるようになります。 http://docs.oasis-open.org/wss/2004/01/oasis-200401http-wss-wssecurity-secext-1.0.xsd
JBoss Remoting 固有の設定プロパティーを設定することもできます。これには、プロパティー名の前に jbr- を付けます。詳細は、JBoss Remoting のドキュメント()http://www.jboss.org/jbossremoting/を参照してください。
以下は、JBoss Remoting 固有の設定を使用して、HTTPS のキーストアとクライアント認証モードを設定する設定例です。
<jbr-provider name="https_provider" protocol="https" host="localhost">
    <!-- Https/SSL settings -->
    <property name="jbr-KeyStoreURL" value="/keys/myKeystore" />
    <property name="jbr-KeyStorePassword" value="keys_ssl_pass" />
    <property name="jbr-TrustStoreURL" value="/keys/myKeystore" />
    <property name="jbr-TrustStorePassword" value="keys_ssl_pass" />
    <property name="jbr-ClientAuthMode" value="need" />
    <property name="serviceInvokerTimeout" value="20000" />

    <jbr-bus busid="https_bus" port="9433"/>
</jbr-provider>
注記
JBoss Remoting Gateway は、すべての応答ヘッダーが org.jboss.soa.esb.message.ResponseHeader クラスのインスタンスとして Message.Properties に配置されていることを想定します。ゲートウェイが特定の応答ヘッダーを設定する必要がある場合、ゲートウェイ応答に提供されたエンタープライズサービスバスメッセージ(ターゲットサービスの同期呼び出し後など)には、Message.Properties に設定された ResponseHeader クラスのインスタンスが含まれている必要があります。

10.16. HTTP ゲートウェイ

HTTP ゲートウェイを使用すると、HTTP エンドポイントで認識されない HTTP エンドポイントを公開することができます。

10.17. HTTP ゲートウェイの設定

HTTP ゲートウェイは JBoss Enterprise SOA Platform の Application Server の HTTP コンテナーを使用して HTTP エンドポイントを公開するため、多くの設定はコンテナーレベルで管理されます。これらはバインド/ポートアドレス、SSL などです。
以下のコードは、サービスに <http-gateway> を設定する最も簡単な方法を示しています(プロバイダー設定は必要ありません)。
<service category="Vehicles" name="Cars" description="" invmScope="GLOBAL">
    <listeners>
        <http-gateway name="Http" />
    </listeners>
    <actions mep="RequestResponse">
        <!-- Service Actions.... -->
    </actions>
</service>
上記の設定では、デフォルト の HTTP バスプロバイダーを使用します。これは、busrefid 属性を定義しないためです。サービスカテゴリーと名前を使用して、次の形式の HTTP エンドポイントアドレスを構築します。
        http://<host>:<port>/<.esbname>/http/Vehicles/Cars
<.esbname> トークンは、.esb 拡張のない .esb デプロイメントの名前です。アドレスの http トークンにも注意してください。これは、すべての <http-gateway> エンドポイントに使用されるハードコーディングされた名前空間の接頭辞です。
<http-gateway> は urlPattern もサポートしています。
<service category="Vehicles" name="Cars" description="" invmScope="GLOBAL">
    <listeners>
        <http-gateway name="Http" urlPattern="esb-cars/*" />
    </listeners>
    <actions mep="RequestResponse">
        <!-- Service Aactions.... -->
    </actions>
</service>
これにより、サービスの HTTP エンドポイントが公開され、以下のアドレスにあるすべての HTTP 要求が取得されます。
        http://<host>:<port>/<.esbname>/http/esb-cars/*
allowedPorts プロパティーを使用して、特定のサービスを 1 つ以上の HTTP ポートに制限できます。これを行うには、以下のように問題のポートのコンマ区切りリストを作成します。
<http-gateway name="Http" urlPattern="esb-cars/*">
    <property name="allowedPorts" value="8080,8081">
</http-gateway>
これにより、サービスの HTTP エンドポイントが公開され、以下のポート下のすべての HTTP 要求のみがキャプチャーされます(他のすべてのポートは HTTP ステータスコード 404 - Not Found を受け取ります)。
  • http://<host>:8080/*
  • http://<host>:8081/*
<http-gateway> は通常、要求 MIME タイプに基づいて HTTP 要求のペイロードをデコードできます。jbossesb-properties.xml ファイルの core:org.jboss.soa.esb.mime.text.types 設定プロパティーを使用して、ペイロードを文字列としてデコードするか、またはアクションでデコードするサービスを使用するかどうかを決定します。
"core:org.jboss.soa.esb.mime.text.types" 設定プロパティーは、"text" (文字)MIME タイプのセミコロンで区切られたリストであり、デフォルトセットは次のように設定されます(ワイルドカードのサポートに注意)。
  • text/*
  • application/xml
  • application/*-xml
<http-gateway> は、テキストペイロードをデコードする際に要求の文字エンコーディングを使用します。
<http-gateway> は payloadAs 属性もサポートします。これは、上記のデフォルトの MIME タイプベースの動作の上書きとして使用できます。この属性を使用すると、ペイロードを BYTES または string として処理するようにゲートウェイを明示的に指示できます。
HTTP 要求には、サービスが必要とする可能性のあるデータペイロードに加えて、他の多くの情報が含まれています。  この情報は、ゲートウェイによりメッセージの HttpRequest オブジェクトインスタンスに保存されます。  アクション内でこのコードを使用して、その情報にアクセスします。
HttpRequest requestInfo = HttpRequest.getRequest(message);
HttpRequest は、(ゲッターメソッドを介して)以下のプロパティーセットを公開します。

表10.12 プロパティー

プロパティー Description
queryParams クエリーパラメーターが含まれる java.util.Map<String, String[]>。  値は String[] であるため、多値パラメーターをサポートすることに注意してください。
ヘッダー リクエストヘッダーが含まれる java.util.List<HttpHeader>。
authType エンドポイントを保護するために使用される認証スキームの名前。認証されていない場合は null です。CGI 変数 AUTH_TYPE の値と同じです。
characterEncoding この要求の本文で使用される文字エンコーディングの名前。要求が文字エンコーディングを指定しない場合は null。
contentType 要求の本文のコンテンツタイプ(MIME タイプ)、またはタイプが不明な場合は null。  CGI 変数 CONTENT_TYPE の値と同じです。
contextPath 要求のコンテキストを示す要求 URI の部分。  コンテキストパスは常にリクエスト URI で最初に行われます。  パスは / 文字で始まりますが、/ 文字で終わりません。  デフォルトの(root)コンテキストのエンドポイントの場合、これは "" を返します。  コンテナーはこの文字列をデコードしません。  (Servlet Spec を参照してください。)
pathInfo この要求時にクライアントが送信する URL に関連付けられた追加のパス情報。追加のパス情報はエンドポイントパスに従いますが、クエリー文字列の前には / 文字で始まります。追加パス情報がない場合は、このメソッドは null を返します。CGI 変数 PATH_INFO の値と同じです。(Servlet Spec を参照してください。)
pathInfoToken pathInfo のトークンが含まれる List<String>。
queryString クエリー文字列(サーブレット仕様を参照)
requestURI プロトコル名からクエリー文字列までのこの要求 URL の一部。Web コンテナーはこの文字列をデコードしません。(サーブレット仕様 を参照してください)
requestPath エンドポイントを呼び出すこのリクエスト URL の一部。追加のパス情報やクエリー文字列は含まれません。CGI 変数 SCRIPT_NAME の値と同じです。urlPattern が/*であった場合、このメソッドは http のみを返します。(サーブレット仕様 を参照してください)
localAddr 要求が受信したインターフェイスの IP アドレス。
localName 要求が受信した IP インターフェイスのホスト名。
メソッド HTTP メソッド
protocol HTTP プロトコルの名前とバージョン
remoteAddr 要求を送信したクライアントまたは最後のプロキシーの IP アドレス。CGI 変数 REMOTE_ADDR の値と同じです。
remoteHost 要求を送信したクライアントまたは最後のプロキシーの完全修飾名。エンジンが(パフォーマンスを向上させるために)ホスト名を解決できないか、または選択しない場合、これは IP アドレスのドット付き文字列の形式になります。CGI 変数 REMOTE_HOST の値と同じです。
remoteuser この要求を行うユーザーのログイン(ユーザーが認証されている場合)、またはユーザーが認証されていない場合は null。ユーザー名が後続の各要求と共に送信されるかどうかは、クライアントと認証のタイプによって異なります。CGI 変数 REMOTE_USER の値と同じです。
contentLength リクエストボディーと入力ストリームで利用可能になった長さ(バイト単位)。長さが不明な場合は -1。HTTP サーブレットの場合、CGI 変数 CONTENT_LENGTH の値と同じです。
requestSessionId クライアントによって指定されたセッション ID。指定されていない場合は null。
scheme 使用されているスキーム(http または https のいずれか)。
serverName 要求が送信されたサーバーのホスト名。Host ヘッダー値の ":" より前の部分(存在する場合)、または解決されたサーバー名、またはサーバー IP アドレスになります。
デフォルトでは、このゲートウェイは関連するサービスを同期的に呼び出し、サービス応答ペイロードを HTTP 応答として返します。
HTTP ゲートウェイは常に同期 HTTP クライアントに同期応答を返すため、単語の絶対意味では非同期ではありません。  デフォルトでは、ゲートウェイはアクションパイプラインを同期的に呼び出し、同期サービスの応答をゲートウェイからの HTTP 応答として返します。
このゲートウェイの観点からの非同期応答動作は、アクションパイプラインの非同期呼び出し後にゲートウェイが同期 HTTP 応答を返すことを意味します(つまり、同期サービス呼び出しではありません)。  サービスを非同期的に呼び出すため、同期 HTTP 応答の一部としてサービス応答を返すことはできません。  したがって、非同期応答を行う方法を示すゲートウェイを設定する必要があります。
非同期動作を設定するには、<asyncHttpResponse> 要素を <http-gateway> に追加します。
<listeners>
    <http-gateway name="Http" urlPattern="esb-cars/*">
        <asyncResponse />
    </http-gateway>
</listeners>
上記のように設定されている場合、ゲートウェイは HTTP ステータス 200 (OK)でゼロ長 HTTP 応答ペイロードを返します。
非同期応答 HTTP ステータスコードは、<asyncResponse> 要素に statusCode 属性を設定することで、(デフォルトの 200 から)設定できます。
<listeners>
    <http-gateway name="Http" urlPattern="esb-cars/*">
        <asyncResponse statusCode="202" />
    </http-gateway>
</listeners>
上記のように、非同期応答のゼロ長ペイロードは(デフォルトでは)を返します。  これは、<asyncResponse> 要素に <payload> 要素を指定して上書きできます。
<listeners>
    <http-gateway name="Http" urlPattern="esb-cars/*">
        <asyncResponse statusCode="202">
            <payload classpathResource="/202-static-response.xml"
                     content-type="text/xml"
                     characterEncoding="UTF-8" />
        <asyncResponse>
    </http-gateway>
</listeners>

表10.13

プロパティー Description 必須
classpathResource
応答ペイロードが含まれるクラスパス上のファイルへのパスを指定します。
必須
contentType
classpathResource 属性で指定されたペイロードデータのコンテンツ/mime タイプを指定します。
必須
characterEncoding
classpathResource 属性で指定されたデータの文字エンコーディング。
オプション
ゲートウェイが関連サービスの HttpRequest オブジェクトインスタンスを作成する方法と一貫性があり、関連するサービスは、同期 HTTP ゲートウェイ呼び出しでゲートウェイの HttpResponse オブジェクトを作成できます。
サービスのアクションでこのコードを使用して、応答メッセージに HttpResponse インスタンスを作成および設定します。
HttpResponse responseInfo = new HttpResponse(HttpServletResponse.SC_OK);
 
responseInfo.setContentType("text/xml");
// Set other response info ...
 
// Set the HttpResponse instance on the ESB response Message instance
responseInfo.setResponse(responseMessage);
HttpResponse オブジェクトには、発信 HTTP ゲートウェイの応答にマップされる以下のプロパティーを含めることができます。

表10.14

プロパティー Description
responseCode
ゲートウェイ応答に設定する HTTP 応答/ステータスコード()。http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
contentType
レスポンスペイロード MIME タイプ。
encoding
応答ペイロードのコンテンツエンコーディング。
長さ
応答ペイロードのコンテンツの長さ。
ヘッダー
リクエストヘッダーが含まれる java.util.List<HttpHeader>。
注記
このクラスは HttpRouter などの内部アクションでも使用されるため、HttpResponse クラスの使用は効率的であるため、このゲートウェイを使用してプロキシー操作を簡単に実行できます。
注記
応答ペイロードコンテンツエンコーディングは、HttpResponse インスタンスを介して HTTP 応答ステータスコード(ulink url="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html" />)として設定することもできます。
デフォルトでは、このゲートウェイは同期サービス呼び出しが完了するまで 30,000 ミリ秒(30 秒)待機してから ResponseTimeoutException を発生させます。  デフォルトのタイムアウトを上書きするには、synchronousTimeout プロパティーを設定します。
<listeners>
    <http-gateway name="Http" urlPattern="esb-cars/*">
        <property name="synchronousTimeout" value="120000"/>
    </http-gateway>
</listeners>
動作パイプラインの例外を、Madoop 設定を介して特定の HTTP 応答コードにマップできます。マッピングはトップレベル <http-provider> で指定でき、<http-gateway> で直接指定することもできます。これにより、<http-provider> でグローバルに定義された例外マッピングのリスナーごとのオーバーライドが可能になります。  以下は、<http-gateway> 設定に直接行われた例外マッピングの例です。
<http-gateway name="http-gateway">
    <exception>
        <mapping class="com.acme.AcmeException" status="503" />
    </exception>
</http-gateway>
<http-provider> レベルでの例外マッピングの設定はまったく同じです。
また、"{exception-class}={http-status-code}" マッピングを含む単純な .properties 形式のファイルであるマッピングファイルを設定することもできます。  ファイルはクラスパスで検索され、.ESB デプロイメント内にバンドルされる必要があります。  これは以下のように設定されます(<http-provider>)が設定されます。
<http-provider name="http">

    <!-- Global exception mappings file... -->
    <exception mappingsFile="/http-exception-mappings.properties" />
</http-provider>

10.18. HTTP ゲートウェイのセキュリティー保護

セキュリティー制約を設定するには、必要な設定の <http-provider> 設定セクションに必須の値を追加します。(つまり、これは <http-gateway> 設定で直接実行することはできません。)

10.19. HTTP ゲートウェイのセキュア化

手順10.1 タスク

  1. テキストエディターで jbossesb-properties.xml ファイルを開きます( vi jbossesb-properties.xml)。
  2. ファイルの <http-provider> セクションに <http-bus> を指定します。
  3. "busrefid" 属性を使用して、<http-gateway> から <http-bus> を参照します。
    注記
    完全な設定の例は、http-gateway クイックスタートを参照してください。
  4. ファイルを保存して終了します。

10.20. HTTP ゲートウェイセキュリティーの追加

エンドポイントによるログインの使用を強制するには、<http-bus> 設定ファイルの <protected-methods> セクションおよび <allowed-roles> セクションを使用します。
<http-bus busid="secureSalesDeletes">
    <allowed-roles>
        <role name="friend" />
    </allowed-roles>
    <protected-methods>
        <method name="DELETE" />
    </protected-methods>
</http-bus>
上記の設定では、secureSalesDeletes バスで行われた削除要求に有効な friend ログインが必要であることが示されています。
  以下のログインマトリックスは、ログインを有効にする設定、およびいつ実施するかを説明しようとします。

表10.15

指定したメソッド ロールの指定 Log-in Required
いいえ
いいえ
いいえ
いいえ
はい
すべてのメソッドについて
はい
はい
指定したメソッドのみ
はい
いいえ
いいえ。指定されたメソッドは all をブロックします。
<war-security> 設定の 要素内から認証方法とセキュリティードメインを設定し {> ます。
<http-provider name="http">
    <http-bus busid="secureFriends">
        <allowed-roles>
            <role name="friend" />
        </allowed-roles>
        <protected-methods>
            <method name="DELETE" />
        </protected-methods>
    </http-bus>

    <auth method="BASIC" domain="java:/jaas/JBossWS" />
</http-provider>
method 属性は、BASIC (デフォルト)、CLIENT-CERT、DIGEST のいずれかです。
HTTP Transport Guarantee は、"transportGuarantee" 属性を使用してバスに指定することで、http-bus ごとに HTTP トランスポート保証を設定できます。
<http-bus busid="secureFriends" transportGuarantee="CONFIDENTIAL">
    <!-- etc etc -->
</http-bus>
transportGuarantee の有効な値は、CONFIDENTIAL、INTEGRAL、および "NONE" です。

10.21. Apache Camel

Camel は、Apache プロジェクトによって開発されたオープンソースのルールベースのルーターです。

10.22. Camel Gateway

Camel Gateway を使用すると、Kadoop-unaware Camel エンドポイントを公開できます。このゲートウェイは Apache Camel の入力機能を活用し、Camel メッセージを JBoss Enterprise SOA Platform メッセージに変換し、関連するサービスを呼び出します。
Camel Gateway と JBoss Enterprise SOA Platform 内で提供される他のゲートウェイの最も明らかな違いは、Camel Gateway が 1 種類のトランスポートに関連付けられていないことです。

10.23. Camel ゲートウェイの設定

Camel が処理できるさまざまなトランスポートをすべて表示するには、以下の Camel Component リストを参照してください。 http://camel.apache.org/components.html
注記
Camel コンポーネントによってライブラリーの依存関係が異なります。JBoss Enterprise SOA Platform には camel-core.jar のみが含まれます。必要な他の依存関係(他の camel-* jars またはサードパーティーの jar を含む)を、お使いのアプリケーションではなく server//deployers/esb.deployer/lib に追加する必要があります。コア以外の Camel コンポーネントの使用に関する詳細は、を参照してください http://community.jboss.org/wiki/CamelGatewayUsingNon-coreComponents/
更新された(jbossesb-1.3.0.xsd)スキーマの使用を宣言すると、jboss-esb.xml ファイルで新しい <camel-provider> セクションが Providers の下に表示されます。
<camel-provider name="...">
<camel-bus busid="...">
	<from uri="..."/>
<from uri="..."/>
</camel-bus>
</camel-provider>
最も興味深い部分は、<camel-bus> 要素に含まれることです。ここで、無制限の <from uri=""/> 要素を追加できます。Camel XML 設定に慣れているものは、ネイティブ Camel XML 設定の内容を正確に実行するため、その要素について十分に理解しておく必要があります。また、busidref 属性を介してバスを参照できる新しい <camel-gateway> 要素もあります。
<camel-gateway name="..." busidref="..."/>
<camel-provider> をまったく使用せずに、<camel-gateway> 要素の下に <from uri=""/> 要素を定義できます。
<camel-gateway name="...">
<from uri=""/>
<from uri=""/>
</camel-gateway>
また、ゲートウェイレベルまたはバスレベルで XML 属性として Camel から URI を 1 つ指定できる簡単なメカニズムもあります。ゲートウェイレベルは次のとおりです。
<camel-gateway name="..." from-uri="..."/>
バスレベルは次のとおりです。
<camel-bus name="..." busid="..." from-uri="..."/>
注記
<camel-bus> と <camel-gateway> レベルの両方で定義されたすべての Camel "from" URI は累積的です(要素形式や短い形式を使用するかどうか)。
この時点で、Camel では少なくとも 1 つの宛先を定義する必要があるため、<to uri=""/> 要素がどこにあるかについて考えられます。JBoss Enterprise Service Bus では、すべての Camel "from" URI は 1 つのルート(その gateway+bus の他のすべてのルートに追加)に変換され、<camel-gateway> を割り当てる関連するサービスを呼び出す暗黙的な Camel "to" URI を使用します。可能性下では、その gateway+bus のすべてのルートはそのサービスを呼び出し、すべて同じ CamelContext 内で実行され、その CamelGateway のライフサイクルと関連付けられます。
注記
このゲートウェイは、1 つの "from" URI で定義できる Camel ルートのみをサポートすることに注意してください。ゲートウェイでサポートされる基本的なスタンザは from (endpointUri).to (esbService)です。ゲートウェイは、他の Camel コンポーネントへの中間ルーティングを必要とするルートをサポートしません。
注記
このゲートウェイは、1 つの "from" URI で定義できる Camel ルートのみをサポートすることに注意してください。ゲートウェイでサポートされる基本的なスタンザは from (endpointUri).to (esbService)です。ゲートウェイは、他の Camel コンポーネントへの中間ルーティングを必要とするルートをサポートしません。
一部の Camel コンポーネントはスケジュールされたルーティングタスクを実行することがあります。たとえば、HTTP コンポーネントを使用して HTTP アドレスを定期的にポーリングしたり、File コンポーネントを使用してファイルシステムディレクトリーをポーリングしたりできます。これらのすべてのコンポーネントがポーリング頻度を設定するための URI オプションをサポートしているわけではありません。HTTP コンポーネントはこのような例です。このような場合は、コンポーネントの URI Scheme に "esbschedule:<frequency-in-millis>" (例:. <from uri="esbschedule:5000:http://www.jboss.org" /> は 5 秒ごとに jboss.org をポーリングするだけです)。
最後に、<camel-gateway> または <camel-bus> レベルのいずれかに配置できる他の 2 つのオプション属性があります(この場合はバスを上書きするゲートウェイ): async および timeout:
<camel-gateway name="..." from-uri="..." async="false" timeout="30000"/>
  • async 属性(デフォルトは false)は、基礎となる ServiceInvoker が関連するサービスを同期的または非同期に呼び出すかどうかを示します。
  • timeout 属性(デフォルトは 30000)で、ServiceInvoker が同期呼び出しで待機する必要のあるミリ秒数を定義します。
注記
詳細は、以下の wiki ページを参照してください。 http://community.jboss.org/wiki/CamelGateway
camel_helloworld クイックスタートを調査することもできます。

10.24. 古い設定モデルから新しい設定モデルへの移行

本項は、旧式の JBoss の非 XSD ベースの設定モデルを熟知している開発者を対象としています。
古いモデルはフリーフォーム XML を使用していましたが、このコンポーネントは org.jboss.soa.esb.helpers.ConfigTree のインスタンスを介して設定を受信します。新しい設定モデルは XSD ベースです。ただし、基盤のコンポーネント設定パターンは、引き続き org.jboss.soa.esb.helpers.ConfigTree のインスタンスを介して実行されます。これは、現時点では XSD ベースの設定が ConfigTree スタイルの設定にマッピング/変換されることを意味します。
以前のモデルにカスタマイズした開発者は、以下の点を念頭に置いてください。
  1. 新しい設定モデルですべてのドキュメントを読み取ります。古い知識に基づいて新しい設定を推測できるとは限りません。
  2. 新しい設定でフリーフォームマークアップがサポートされる唯一の場所は <property> 要素/タイプにあります。このタイプは、<provider>、<bus>、および <listener> タイプ(およびサブタイプ)で許可されます。ただし、<property> ベースの空きフォームマークアップが ConfigTree 設定にマッピングされる唯一の場所は、<property> が <action> に存在する場所です。この場合、<property> コンテンツはターゲットの ConfigTree <action> にマッピングされます。ただし、<action> に空き形式の子コンテンツを持つ 1+ <property> 要素がある場合、このすべてのコンテンツはターゲットの ConfigTree <action> に連結されます。
  3. 新しい Listener/Action コンポーネントを開発する場合は、これらのコンポーネントに依存する ConfigTree ベースの設定が新しい XSD ベースの設定からマッピングできるようにする必要があります。たとえば、ConfigTree 設定モデルでは、リスナーノードの属性を使用してリスナーコンポーネントに設定を提供するか、リスナー設定内の子ノードに基づいて設定を提供するか(その日に気づいたかに応じて)決定することができます。<listener> コンポーネントのこのタイプのフリーフォーム設定は、XSD から ConfigTree へのマッピングではサポートされていません。つまり、上記の例の子コンテンツは、XSD 設定から ConfigTree スタイルの設定にマッピングされません。実際、XSD 設定は <property> にあり、その場合はマッピングコードによって無視される場合を除き、任意のコンテンツを受け入れません。

10.25. Enterprise Service Bus の設定

製品のコア内のすべてのコンポーネントは、XML として設定パラメーターを受け取ります。これらのパラメーターがシステムにどのように提供されるかは、org.jboss.soa.esb.parameters.ParamRepositoryFactory によって非表示になります。
public abstract class ParamRepositoryFactory
{
	public static ParamRepository getInstance();
}
この命令は、さまざまな実装を可能にする org.jboss.soa.esb.parameters.ParamRepository インターフェイスの実装を返します。
public interface ParamRepository
{
	public void add(String name, String value) throws
	ParamRepositoryException;
	public String get(String name) throws ParamRepositoryException;
	public void remove(String name) throws ParamRepositoryException;
}
JBoss Enterprise SOA Platform 内には、1 つの実装( org.jboss.soa.esb.parameters.ParamFileRepository)のみがあり、ファイルからパラメーターを読み込むことができることが予想されます。これを使用する実装は、org.jboss.soa.esb.paramsRepository.class プロパティーを使用して上書きすることができます。
注記
Red Hat は、JBoss Developer Studio または選択した XML エディターを使用して、アーキテクト設定ファイルを構築することを推奨します。JBossESB 設定情報はアノテーションが付いた XSD によってサポートされます。これは、より基本的なエディターを使用している場合に役立つはずです。

第11章 データのデコーディング:Mime Decoder

11.1. Message Composer

Message Composer は、MessageComposer インターフェイスを実装するクラスで、Madoop メッセージインスタンスを構築し、関連するサービスに送信します。メッセージコーダーは、ゲートウェイのたびにサポートされます。

11.2. MIME デコーダー

Mime Decoder は MimeDecoder インターフェイスを実装するクラスです。MessageComposer 実装により、バイナリーアレイをデコードし、特定タイプの Java Object に変換できます。(オブジェクトのタイプは、バイナリーでエンコードされたデータの mime タイプによって決定されます。)
MimeDecoder メカニズムを使用するゲートウェイの例は、File および FTP ゲートウェイリスナーです。これらのゲートウェイは、mimeType または mimeDecoder プロパティーで設定できます。これにより、指定された mime タイプの適切な MimeDecoder 実装の自動インストールがトリガーされます。

11.3. Mime Decoder の実装

手順11.1 タスク

  1. org.jboss.soa.esb.listeners.message.mime.MimeDecoder インターフェイスをアクティブにするクラスを作成します。
  2. @MimeType アノテーションをクラスに追加し、mime タイプをアノテーション値として指定します。
  3. META-INF/org/jboss/soa/esb/listeners/message/mime/decoders.lst ファイルで新たに作成されたクラスを定義します。
    @MimeType("text/plain")
    public class TextPlainMimeDecoder implements MimeDecoder, Configurable {
    
        private Charset encodingCharset;
        
        public void setConfiguration(ConfigTree configTree) throws ConfigurationException {
            AssertArgument.isNotNull(configTree, "configTree");
            
            String encoding = configTree.getAttribute("encoding", "UTF-8");
            encodingCharset = Charset.forName(encoding);
        }
    
        public Object decode(byte[] bytes) throws MimeDecodeException {
            try {
                return new String(bytes, encodingCharset.name());
            } catch (UnsupportedEncodingException e) {
                throw new MimeDecodeException("Unexpected character encoding error.", e);
            }
        }
    }
    注記
    このファイルは、実行時にクラスパスに存在する必要があります。モジュールにこのファイルがない場合は、モジュールソース/リソースに追加し、ランタイム時に存在します。
  4. MmeDecoder 実装がリスナー設定へのアクセスを必要とする場合(追加の設定情報の場合)、クラスは org.jboss.soa.esb.Configurable インターフェイスを実装する必要があります。

11.4. ConfigTree

ConfigTree はリスナーインスタンスの設定です。この情報は jboss-esb.xml ファイルに保存されます。

11.5. MIME デコーダー実装:すぐに使用できるボックスの実装

JBoss Enterprise SOA Platform には、以下の MimeDecoder 実装が含まれています。
text/plain
TextPlainMimeDecoder は text/plain データを処理し、byte[] を String (デフォルト)または char[] にデコードします。

表11.1 プロパティー

プロパティー Description コメント
encoding
byte[] でエンコードされた text/plain データの文字エンコーディング。
デフォルトは UTF-8 です。
decodeTo
text/plain データをデコードする方法:
  • "STRING" (デフォルト): text/plain データを java.lang.String にデコードします。
  • "CHARS": text/plain データを char[] にデコードします。
デフォルト "STRING"

11.6. ゲートウェイ実装での Mime Decoder の使用

MessageComposer がインストールされた mime デコーダーを使用する最も簡単な方法は、ConfigTree および MimeDecoder.Factory クラスファクトリーメソッドを使用することです。
this.mimeDecoder = MimeDecoder.Factory.getInstanceByConfigTree(config);
これは、(File および FTP リスナーでサポートされるように) mimeType または mimeDecoder 設定プロパティーのいずれかを指定するリスナー設定に依存します。
<fs-listener name="FileGateway1" busidref="fileChannel1" is-gateway="true" 
                                poll-frequency-seconds="10">
    <property name="mimeType" value="text/plain" />
    <property name="encoding" value="UTF-8" />
</fs-listener>
<fs-listener name="FileGateway2" busidref="fileChannel2" is-gateway="true" 
                                poll-frequency-seconds="10">
    <property name="mimeDecoder" value="com.acme.mime.ImageJPEGMimeDecoder” />
</fs-listener>
トランスポートペイロードの実際のデコードを実行するには、MessageComposer インスタンスはその mimeDecoder インスタンスで decode メソッドを使用します。
Object decodedPayload = mimeDecoder.decode(payloadBytes);
次に、設定しているメッセージインスタンスに "decodedPayload" オブジェクトインスタンスを設定します。

第12章 Web サービスのサポート

12.1. JBoss Web Services

JBoss Web Services は、JBoss Enterprise Application Platform の JAX-WS Web サービススタックを提供します。
JAX-WS は、XML Web Services の Java API です。Java アノテーションを使用して、Web サービスクライアントおよびエンドポイントの開発を簡素化します。

12.2. JBoss Web Services のサポート

JBoss Enterprise SOA Platform には、Web サービスのエンドポイントを公開して呼び出すために使用するコンポーネントが複数含まれています。
  1. SOAPProcessor: SOAPProcessor アクションを使用すると、JIO (SOAP to the bus)で実行されるエンドポイント(リスナー)を介して JBossWS 2.x 以降の Web サービスのエンドポイントを公開できます。これにより、JBossESB を使用して、Web サービスインターフェイスを公開しないサービスの Web サービスのエンドポイント(Web サービスごとの)を公開することができます。
  2. SOAPClient: SOAPClient アクションを使用すると、Web サービスエンドポイント(バスから SOAP)で呼び出しを行うことができます。

第13章 初期状態のアクション

13.1. 初期状態のアクション

追加設定なしのアクションは、JBoss Enterprise SOA Platform 製品に事前にパッケージ化されたアクションの汎用要素です。これらをサービスですぐに使用することも、ニーズに合わせてカスタマイズすることもできます。

13.2. JBoss Enterprise SOA Platform の非ボックスアクション

SOA Platform に実装されている追加設定なしのアクションは、以下の機能グループに分類されます。
トランスフォーマーとコンバーター
トランスフォーマーとコンバーターアクションを使用して、メッセージデータをある形式から別の形式に変更します。
ビジネスプロセス管理
ソフトウェアを jBPM と統合する場合は、ビジネスプロセス管理アクションを使用します。
スクリプト
スクリプトアクションを使用して、サポートされているスクリプト言語で書かれたタスクを自動化します。
サービス
コードを Enterprise Java Beans と統合する際に、サービスアクションを使用します。
Routing
メッセージデータを宛先サービスに移動する際にルーティングアクションを使用します。
Notifier
データを、認識しない宛先に送信する場合は、通知アクションを使用します。
Web Services/SOAP
Web サービスをサポートする必要がある場合は、Web サービスアクションを使用します。

13.3. トランスフォーマーアクション

13.3.1. transformers

トランスフォーマーは、メッセージペイロードを別の型に変換できるアクションプロセッサーの一種です。

13.3.2. ByteArrayToString

入力タイプ byte[ ]
Class org.jboss.soa.esb.actions.converters.ByteArrayToString
byte[] ベースのメッセージペイロードを取得し、java.lang.String オブジェクトインスタンスに変換します。

表13.1 ByteArrayToString プロパティー

プロパティー Description 必須
encoding
メッセージバイトアレイのバイナリーデータエンコーディング。デフォルトは UTF-8 です。
いいえ

例13.1 設定サンプル

<action name="transform" class="org.jboss.soa.esb.actions.converters.ByteArrayToString">
    <property name="encoding" value="UTF-8" />
</action>

13.3.3. LongToDateConverter

入力タイプ
java.lang.Long/long
出力タイプ
java.util.Date
Class
org.jboss.soa.esb.actions.converters.LongToDateConverter
長いメッセージペイロードを取り、java.util.Date オブジェクトインスタンスに変換します。

例13.2 設定サンプル

<action name="transform" class="org.jboss.soa.esb.actions.converters.LongToDateConverter">

13.3.4. ObjectInvoke

入力タイプ User Object
出力タイプ User Object
Class org.jboss.soa.esb.actions.converters.ObjectInvoke
メッセージペイロードとしてバインドされたオブジェクトを取得し、それを処理するために設定済みのプロセッサーに提供します。処理結果は、新しいペイロードとしてメッセージにバインドされます。

表13.2 ObjectInvoke プロパティー

プロパティー Description 必須
class-processor
メッセージペイロードの処理に使用されるプロセッサークラスのランタイムクラス名。
はい
class-method
メソッドの処理に使用されるプロセッサークラスのメソッドの名前。
いいえ

例13.3 設定サンプル

<action name="invoke" class="org.jboss.soa.esb.actions.converters.ObjectInvoke">
    <property name="class-processor" value="org.jboss.MyXXXProcessor"/>
    <property name="class-method" value="processXXX" />
</action>

13.3.5. ObjectToCSVString

入力タイプ User Object
出力タイプ java.lang.String
Class org.jboss.soa.esb.actions.converters.ObjectToCSVString
メッセージペイロードとしてバインドされたオブジェクトを取得し、(提供されたメッセージオブジェクトに基づく)コンマ区切り値(CSV)文字列、コンマ区切りの bean-properties リストに変換します。

表13.3 ObjectToCSVString プロパティー

プロパティー Description 必須
bean-properties
出力 CSV 文字列の CSV 値を取得するために使用されるオブジェクト Bean プロパティー名のリスト。オブジェクトは、一覧表示される各プロパティーの getter メソッドをサポートする必要があります。
はい
fail-on-missing-property
Object にプロパティーがない場合にアクションが失敗するかどうかを示すフラグ(Object がプロパティーの getter メソッドをサポートしない場合)。デフォルト値は false です。
いいえ

例13.4 設定サンプル

<action name="transform"
    class="org.jboss.soa.esb.actions.converters.ObjectToCSVString">
    <property name="bean-properties"
        value="name,address,phoneNumber"/>
    <property name="fail-on-missing-property" 
        value="true" />
</action>

13.3.6. ObjectToXStream

入力タイプ User Object
出力タイプ java.lang.String
Class org.jboss.soa.esb.actions.converters.ObjectToXStream
Message ペイロードとしてバインドされたオブジェクトを取得し、XStream プロセッサーを使用して XML に変換します。

表13.4 ObjectToXStream プロパティー

プロパティー Description 必須
class-alias
シリアル化前に XStream.alias(String, Class) への呼び出しに使用されるクラスエイリアス。デフォルトは、入力オブジェクトのクラス名です。
いいえ
exclude-package
生成された XML からパッケージ名を除外します。デフォルトは true です。class-alias が指定されている場合は該当しません。
いいえ
aliases
XStream が XML 要素をオブジェクトに変換するのに役立つ追加のエイリアスを指定します。
いいえ
namespaces
XStream によって生成された XML に追加する必要がある namespace を指定します。各 namespace-uri は local-part に関連付けられます。これは、この namespace が表示される要素です。
いいえ
xstream-mode
使用する XStream モードを指定します。使用できる値は、XPATH_RELATIVE_REFERENCES (デフォルト)、XPATH_ABSOLUTE_REFERENCESID_REFERENCES または NO_REFERENCES です。
いいえ
fieldAliases
Xstream に追加するフィールドエイリアス。
いいえ
implicit-collections
Xstream に登録される
いいえ
converters
Xstream に登録されるコンバーターのリスト
いいえ

例13.5 設定サンプル

<action name="transform" class="org.jboss.soa.esb.actions.converters.ObjectToXStream">
    <property name="class-alias" value="MyAlias" />
    <property name="exclude-package" value="true" />
    <property name="aliases">
        <alias name="alias1" class="com.acme.MyXXXClass1" />
        <alias name="alias2" class="com.acme.MyXXXClass2" />
        <alias name="xyz" class="com.acme.XyzValueObject"/>
        <alias name="x" class="com.acme.XValueObject"/>
        ...
    </property>
    <property name="namespaces">
        <namespace namespace-uri="http://www.xyz.com" local-part="xyz"/>
        <namespace namespace-uri="http://www.xyz.com/x" local-part="x"/>
        ...
    </property>
    <property name="fieldAliases">
        <field-alias alias="aliasName" definedIn="className" fieldName="fieldName"/>
        <field-alias alias="aliasName" definedIn="className" fieldName="fieldName"/>
        ...
    </property>
    <property name="implicit-collections">
        <implicit-collection class="className" fieldName="fieldName" 
            fieldType="fieldType" itemType="itemType"/>
        ...
    </property>
    <property name="converters">
        <converter class="className" fieldName="fieldName" fieldType="fieldType"/>
        ...
    </property>
</action>

13.3.7. XStreamToObject

入力タイプ java.lang.String
出力タイプ User Object (incoming-type プロパティーで指定)
Class org.jboss.soa.esb.actions.converters.XStreamToObject
メッセージペイロードとしてバインドされた XML を取得し、XStream プロセッサーを使用してオブジェクトに変換します。

表13.5 XStreamToObject Properties

プロパティー Description 必須
class-alias
シリアル化中に使用されるクラスエイリアス。デフォルトは、入力オブジェクトのクラス名です。
いいえ
exclude-package
XML にパッケージ名が含まれているかどうかを示すフラグ。
はい。
incoming-type
クラスタイプ。
はい
root-node
XML 内の実際のルートノードとは異なるルートノードを指定します。XPath 式を取ります。
いいえ
aliases
XStream が XML 要素をオブジェクトに変換するのに役立つ追加のエイリアスを指定します。
いいえ
attribute-aliases
XML 属性をオブジェクトに変換するために XStream に役立つ追加の属性エイリアスを指定します。
いいえ
fieldAliases
Xstream に追加するフィールドエイリアス。
いいえ
implicit-collections
Xstream に登録される
いいえ
converters
XML 要素および属性をオブジェクトに変換するために Xstream に役立つコンバーターを指定します。
いいえ

例13.6 設定サンプル

<action name="transform" class="org.jboss.soa.esb.actions.converters.XStreamToObject">
    <property name="class-alias" value="MyAlias" />
    <property name="exclude-package" value="true" />
    <property name="incoming-type" value="com.acme.MyXXXClass" />
    <property name="root-node" value="/rootNode/MyAlias" />
    <property name="aliases">
        <alias name="alias1" class="com.acme.MyXXXClass1/>
        <alias name="alias2" class="com.acme.MyXXXClass2/>
        ...
    </property>
    <property name="attribute-aliases">
        <attribute-alias name="alias1" class="com.acme.MyXXXClass1"/>
        <attribute-alias name="alias2" class="com.acme.MyXXXClass2"/>
        ...
    </property>
    <property name="fieldAliases">
        <field-alias alias="aliasName" definedIn="className" fieldName="fieldName"/>
        <field-alias alias="aliasName" definedIn="className" fieldName="fieldName"/>
        ...
    </property>
    <property name="implicit-collections">
        <implicit-colletion class="className" fieldName="fieldName" fieldType="fieldType" 
            itemType="itemType"/>
        ...
    </property>
    <property name="converters">
        <converter class="className" fieldName="fieldName" fieldType="fieldType"/>
        ...
    </property>
</action>

13.3.8. XsltAction

これにより、ドキュメント全体で変換が実行されます。

表13.6 XsltAction Properties

プロパティー Description 必須
get-payload-location
メッセージペイロードを含むメッセージボディーの場所。
指定しない場合、デフォルトのペイロードロケーションが使用されます。
いいえ
set-payload-location
結果ペイロードが配置されるメッセージボディーの場所。
指定しない場合、デフォルトのペイロードロケーションが使用されます。
いいえ
templateFile
XSL テンプレートファイルへのパス。デプロイされたアーカイブ内のファイルパスで定義するか、URL として定義できます。
はい
resultType
結果メッセージペイロードとして設定する結果のタイプ。
このプロパティーは、変換の出力結果を制御します。現在、以下の値を使用できます。
  • 文字 列 : 文字列 を生成します。
  • BYTES: バイトの配列( byte[] )を生成します。
  • DOM: DOMResult を生成します。
  • SAX: SAXResult を生成します。
  • 上記がニーズに適さない場合、SOURCERESULT を使用してカスタマイズされた結果を生成できます。
    メッセージペイロードに SourceResult オブジェクト(org.jboss.soa.esb.actions.xslt.SourceResult)が含まれると、ペイロードの SourceResult オブジェクトの result 属性と同じタイプの結果が生成されます。
メッセージペイロードが SourceResult オブジェクトで、resultTypeSOURCERESULT に設定されていない場合、結果は resultType で指定されたタイプとして返されます。開発者はタイプが互換性があることを確認する必要があります。
いいえ
failOnWarning
true の場合、変換警告が発生して例外が発生します。false の場合は、失敗がログに記録されます。
デフォルトは True です。
いいえ
uriResolver
URIResolver を実装するクラスの完全修飾クラス名。これは、Tranformation ファクトリーに設定されます。
いいえ
factory.feature.*
トランフォーマットファクトリーに設定されるファクトリー機能。完全修飾 URI の機能名は、factory.feature. 接頭辞の後に指定する必要があります。つまり、factory.feature.http://javax.xml.XMLConstants/feature/secure-processing
No
Factory.attribute.*
トランフォーマットファクトリーに設定されるファクトリー属性。属性名は、factory.attribute. 接頭辞の後に指定する必要があります。つまり、factory.attribute.someVendorAttributename
いいえ
validation
true の場合、無効なソースドキュメントによって例外が発生します。誤った検証が行われない場合は、適切に形成されたドキュメントが強制されます。
デフォルト値は falseです。
をクリックします。
いいえ
schemaFile
クラスパスにある、使用する入力スキーマファイル(XSD)。
いいえ
schemaLanguage
使用する入力スキーマ言語。
いいえ

13.3.9. XsltActions の検証

XsltAction 検証を設定する方法は複数あります。以下は例で一覧表示されています。
  1. 無効(デフォルト)
    これは、検証を無効にするために false に設定するか、省略するように設定できます。
    <property name="validation" value="false"/>
  2. DTD
    <property name="validation" value="true"/>
    <property name="schemaLanguage" value="http://www.w3.org/TR/REC-xml"/>
    Alernatively:
    <property name="validation" value="true"/>
    <property name="schemaLanguage" value=""/>
  3. W3C XML Schema または RELAX NG
    <property name="validation" value="true"/>
    または、次のようになります。
    <property name="validation" value="true"/>
    <property name="schemaLanguage" value="http://www.w3.org/2001/XMLSchema"/>
    または
    <property name="validation" value="true"/>
    <property name="schemaLanguage" value="http://relaxng.org/ns/structure/1.0"/>
  4. schemaFile が含まれる W3C XML スキーマまたは RELAX NG
    <property name="validation" value="true"/>
    <property name="schemaFile" value="/example.xsd"/>
    または
    <property name="validation" value="true"/>
    <property name="schemaLanguage" value="http://www.w3.org/2001/XMLSchema"/>
    <property name="schemaFile" value="/example.xsd"/>
    Aleternatively:
    <property name="validation" value="true"/>
    <property name="schemaLanguage" value="http://relaxng.org/ns/structure/1.0"/>
    <property name="schemaFile" value="/example.rng"/>
検証が有効になっているかどうかに応じて、XsltAction にはいくつかの異なる結果があります。
  1. XML の形式が適切で有効な場合は、以下を行います。
    • 変換が実行されます。
    • パイプラインは継続します。
  2. XML が不正な場合は、以下を行います。
    • エラーがログに記録されます。
    • SAXParseException -> ActionProcessingException
    • パイプラインの停止
  3. XML の形式が適切だが無効な場合は、以下を行います。
    • 検証が有効になっていない場合は、以下を行います。
      • 変換が失敗する場合があります。
      • パイプラインは継続します。
    • 検証が有効な場合は、以下を行います。
      • エラーがログに記録されます。
      • SAXParseException -> ActionProcessingException
      • パイプラインの停止

13.3.10. Smooks

Smooks は、フラグメントベースのデータ変換および分析ツールです。これは、メッセージの断片を解釈できる汎用処理ツールです。ビジターロジックを使用してこれを実現します。XSLT または Java で変換ロジックを実装でき、メッセージセットの変換ロジックを一言管理できる管理フレームワークを提供します。

13.3.11. Smook の使用

  • SmooksAction コンポーネントを使用して、Meoks アクションパイプラインにプラグインします。
    注記
    samples/quick starts ディレクトリーで変換を示すクイックスタートが多数あります。(これらのクイックスタートの各変換の名前には、transform_ という単語が接頭辞として付けられます。)

13.3.12. SmooksTransformer

重要
SmooksTransformer アクションは今後のリリースで非推奨になる予定です。より一般的な目的およびより柔軟な Smooks アクションクラスについては、SmooksAction を参照してください。
Class org.jboss.soa.esb.actions.converters.SmooksTransformer
SmooksTransformer コンポーネントは、JBoss Enterprise SOA Platform にメッセージ変換機能を提供します。これは、Smooks Data Transformation/Processing Framework をアクションパイプラインにプラグインできるようにするアクションコンポーネントです。
SmooksTransformer コンポーネントでは、幅広いソースおよびターゲットデータ形式がサポートされます。

表13.7 SmooksTransformer リソース設定

プロパティー Description 必須
resource-config
Smooks リソース設定ファイル。
はい

表13.8 SmooksTransformer Message Profile Properties (オプション)

プロパティー Description 必須
from
メッセージ交換の参加者名。Message Producer。
いいえ
from-type
from メッセージ交換参加者によって生成されたメッセージタイプ/形式。
いいえ
to
メッセージ交換の参加者名。Message Consumer
いいえ
to
 メッセージ交換の参加者名。 Message Consumer
いいえ
to-type
 メッセージ交換参加者によって消費されるメッセージタイプ/フォーマット。
いいえ
上記のプロパティーはすべて、( Message.Properties クラスを介して)メッセージにプロパティーとして指定して上書きできます。

例13.7 設定例:デフォルトの入出力

<action name="transform" class="org.jboss.soa.esb.actions.converters.SmooksTransformer">
    <property name="resource-config" value="/smooks/config-01.xml" />
</action>

例13.8 設定例:名前付き入出力

<action name="transform" class="org.jboss.soa.esb.actions.converters.SmooksTransformer">
    <property name="resource-config" value="/smooks/config-01.xml" /> 
    <property name="get-payload-location" value="get-order-params" />
    <property name="set-payload-location" value="get-order-response" />
</action>

例13.9 設定例:Message Proiles の使用

<action name="transform" class="org.jboss.soa.esb.actions.converters.SmooksTransformer">
    <property name="resource-config" value="/smooks/config-01.xml" />
    <property name="from" value="DVDStore:OrderDispatchService" />
    <property name="from-type" value="text/xml:fullFillOrder" />
    <property name="to" value="DVDWarehouse_1:OrderHandlingService" />
    <property name="to-type" value="text/xml:shipOrder" />
</action>
Java オブジェクトは beanIdMessage.Body にバインドされます。

13.3.13. SmooksAction

org.jboss.soa.esb.smooks.SmooksAction クラスは、Smooks プロセスを実行するための第 2 世代アクションクラスです。(単にメッセージを変換できないことに注意してください)。
SmooksAction クラスは、Smooks PayloadProcessor を使用して幅広いメッセージペイロードを処理できます。これには、文字列、バイトアレイ、InputStreams、リーダー、POJO などが含まれます。そのため、Java から Java への変換など、幅広い変換を実行できます。また、コンテンツベースのペイロードの分割やルーティングなど、ソースメッセージストリームで他のタイプの操作も実行できます(これは Warehouse メッセージルーティングと同じではないことに注意してください)。SmooksAction は、JBoss Enterprise SOA Platform 内から幅広い Smooks 機能を有効にします。
重要
Smooks は、ベース <resource-config> を介して行われたリソース設定の特定のタイプの設定エラーを検出(および報告)しないことに注意してください。たとえば、リソース(<resource>)が Smooks Visitor 実装で、Visitor クラスの名前が間違っている場合、Smooks はスペルがクラスであることが分からないため、エラーとしてこれを送出しません。Smooks は Java Visitor 実装だけでなく、さまざまな種類のリソースをサポートすることに注意してください。
この問題を回避する最も簡単な方法は、追加設定なしのすべての機能に拡張された Smooks 設定 namespace を使用することです。たとえば、org.milyn.javabean.BeanPopulator <resource-config> 設定を定義して Java バインディング設定を定義する代わりに、設定 namespace (つまり <jb:bean> 設定など)を使用 http://www.milyn.org/xsd/smooks/javabean-1.2.xsd します。
Smooks Visitor 機能を実装している場合、この問題を回避する最も簡単な方法は、この新しいリソースタイプの拡張設定名前空間領域を定義することです。また、JBoss Developer Studio に組み込まれているスキーマサポートを活用できるため、新しいリソースの設定を容易にするという利点があります。
以下は、基本的な SmooksAction 設定を示しています。

例13.10 SmooksAction

<action name="transform" class="org.jboss.soa.esb.smooks.SmooksAction">
    <property name="smooksConfig" value="/smooks/order-to-java.xml" />
</action>
オプションの設定プロパティーを以下に示します。

表13.9 SmooksAction オプション設定プロパティー

プロパティー 説明 デフォルト
get-payload-location
メッセージペイロードを含むメッセージボディーの場所。
デフォルトのペイロードの場所
set-payload-location
結果ペイロードが配置されるメッセージボディーの場所。
デフォルトのペイロードの場所
mappedContextObjects
ESB メッセージボディーの EXECUTION_CONTEXT_ATTR_MAP_KEY にマップされる Smooks ExecutionContext オブジェクトのコンマ区切りリスト。デフォルトは空のリストです。オブジェクトは Serializable である必要があります。
resultType
結果メッセージペイロードとして設定する結果のタイプ。
STRING
javaResultBeanId
場合にのみ関連します。 resultType=JAVA
resultType が JAVA の場合に結果としてマッピングされる Smooks Bean コンテキスト beanId。指定されていない場合、Bean コンテキスト Bean Map 全体が JAVA の結果としてマッピングされます。
reportPath
Smooks Execution Report を生成するためのパスおよびファイル名。これは開発の支援であり、実稼働環境では使用しないでください。
SmooksAction は MessagePayloadProxy クラスを使用して、ペイロードを取得およびメッセージに設定します。そのため、get-payload-location および set-payload-location アクションプロパティーで特に設定されていない限り、SmooksAction は Message.getBody ().get ()および Message.getBody ().set (Object)メソッドを使用してデフォルトのメッセージの場所で Message ペイロードを取得し、設定します。
提供されたメッセージペイロードが String、InputStream、Reader、または byte[] のいずれかではない場合、SmooksAction はペイロードを JavaSource として処理し、Java-to-XML および Java から Java への変換を実行できます。

13.3.14. SmooksAction を使用して XML、EDI、CSV、および Other Type メッセージペイロードを処理します。

手順13.1 タスク

  1. ソースメッセージを指定します。次のいずれかである必要があります。
    • 文字列
    • InputStream,
    • reader、または
    • バイト配列
  2. (Enterprise Service Bus 設定ファイルではなく、Smooks 設定ファイルを介して) Smooks を設定して、問題のメッセージタイプを処理します。たとえば、XML ソース(EDI、CSV など)を処理していない場合はパーサーを設定します。

13.3.15. SmooksAction 結果タイプの指定

Smooks アクションはさまざまなタイプの結果を生成する可能性があるため、必要な結果を指定する必要があります。次に、選択した結果がメッセージペイロードに戻ります。
デフォルトの ResultType は string です。resultType 設定プロパティーを設定することで、BYTES、JAVA、または NORESULT に変更できます。
JAVA の resultType を指定すると、Smooks ExecutionContext (具体的には Bean コンテキスト)から Java オブジェクトを 1 つ以上選択できます。javaResultBeanId 設定プロパティーは、Bean コンテキストからメッセージペイロードの場所にバインドする特定の Bean を指定できるようにすることで、resultType プロパティーを補完します。
以下は、order Bean を Smooks Bean コンテキストからペイロードとしてメッセージにバインドするサンプルコードです。
<action name="transform" class="org.jboss.soa.esb.smooks.SmooksAction">
    <property name="smooksConfig" value="/smooks/order-to-java.xml" />
    <property name="resultType" value="JAVA" />
    <property name="javaResultBeanId" value="order" />
</action>

13.3.16. PersistAction

入力タイプ メッセージ
出力タイプ 入力メッセージ
Class org.jboss.soa.esb.actions.MessagePersister
これは、必要に応じて MessageStore との対話に使用されます。

表13.10 PersistAction プロパティー

プロパティー Description 必須
classification
これは、メッセージの保存場所を分類するために使用されます。メッセージプロパティー org.jboss.soa.esb.messagestore.classification がメッセージに定義されている場合は、代わりに使用されます。それ以外の場合は、インスタンス化時にデフォルトを指定できます。
はい
message-store-class
MessageStore の実装。
はい
terminal
アクションを使用してパイプラインを終了する場合、これは true (デフォルト)である必要があります。そうでない場合は、これを false に設定し、入力メッセージが処理から返されます。
いいえ
<action name="PersistAction" class="org.jboss.soa.esb.actions.MessagePersister">
    <property name="classification" value="test"/>
    <property name="message-store-class" 
        value="org.jboss.internal.soa.esb.persistence.format.db.DBMessageStoreImpl"/>
</action>

13.4. ビジネスプロセス管理アクション

13.4.1. jBPM

JBoss Business Process Manager (jBPM) は、ユーザーがビジネスプロセスと言語を制御できるようにするワークフロー管理ツールです。jBPM 3 がデフォルトとして使用されます。

13.4.2. JBPM の統合

JBoss Business Process Manager は、ワークフローおよび ビジネスプロセス管理 エンジンです。

13.4.3. jBPM BpmProcessor

入力タイプ org.jboss.soa.esb.message.Message generated by AbstractCommandVehicle.toCommandMessage()
出力タイプ message - 入力メッセージと同じ
Class org.jboss.soa.esb.services.jbpm.actions.BpmProcessor
JBoss Enterprise SOA Platform は、BpmProcessor アクションを使用して jBPM を呼び出すことができます。BpmProcessor アクションは jBPM コマンド API を使用して jBPM に呼び出しを行います。
以下の jBPM コマンドが実装されています。
  • NewProcessInstanceCommand
  • StartProcessCommand
  • CancelProcessInstanceCommand
  • GetProcessInstanceVariablesCommand

表13.11 BpmProcessor プロパティー

プロパティー Description 必須
command
呼び出される jBPM コマンド。必須 許容値:
  • NewProcessInstanceCommand
  • StartProcessInstanceCommand
  • SignalCommand
  • CancelProcessInstanceCommand
はい
processdefinition
process-definition-id プロパティーが使用されていない場合、New- および Start-ProcessInstanceCommands に必要なプロパティー。このプロパティーの値は、すでに jBPM にデプロイされており、新しいインスタンスを作成するプロセス定義を参照する必要があります。このプロパティーは Signal- および CancelProcessInstance-Commands には適用されません。
状況により異なる
process-definition-id
processdefinition プロパティーが使用されていない場合、New- および Start-ProcessInstanceCommands に必要なプロパティー。このプロパティーの値は、新しいインスタンスを作成する jBPM の processdefintion id を参照する必要があります。このプロパティーは Signal- および CancelProcessInstance コマンドには適用されません。
状況により異なる
actor
jBPM アクター ID を指定する任意のプロパティー。これは New- および StartProcessInstanceCommands のみに適用されます。
いいえ
key
jBPM キーの値を指定する任意のプロパティー。たとえば、このキーの値として一意の請求書 ID を渡すことができます。jBPM 側で、このキーは business key id フィールドになります。キーは、プロセスインスタンスの文字列ベースのビジネスキープロパティーです。ビジネスキーが指定されている場合は、ビジネスキーとプロセス定義の組み合わせは一意でなければなりません。キー値は MVEL 式を保持し、EsbMessage から必要な値を抽出できます。たとえば、メッセージのボディーに businessKey という名前付きパラメーターがある場合は、body.businessKey を使用します。このプロパティーは New- および StartProcessInstanceCommands のみに使用されることに注意してください。
いいえ
transition-name
任意のプロパティー。このプロパティーは、StartProcessInstance- および Signal コマンドにのみ適用され、現在のノードから移行が 1 つ以上ある場合にのみ使用されます。このプロパティーが指定されていない場合、ノードからデフォルトの移行が行われます。デフォルトの移行は、jBPM processdefinition.xml のそのノードに定義された移行リストの最初の移行です。
いいえ
esbToBpmVars
New- および StartProcessInstanceCommands および SignalCommand の任意のプロパティー。このプロパティーは、EsbMessage から抽出し、特定のプロセスインスタンスの jBPM コンテキストに設定する必要がある変数のリストを定義します。この一覧はマッピング要素で設定されます。各 mapping 要素には以下の属性を指定できます。
adobe
メッセージから任意の場所に値を抽出するために MVEL 式を含むことができる必須属性。
bpm
jBPM 側で使用される名前を含む任意の属性です。省略した場合は、esb 名が使用されます。
default
esb MVEL 式が EsbMessage に設定された値を見つけられない場合にデフォルト値を保持できる任意の属性。
いいえ

13.5. スクリプトアクション

13.5.1. スクリプトアクション

スクリプトアクションは、サービスのパイプラインに追加できるアクションです。スクリプト言語を追加したら、スクリプト言語を使用してアクション処理ロジックを定義できます。

13.5.2. Groovy

Groovy は Java 仮想マシンのアジャイルで動的言語で、Java の強みに基づいて構築されますが、Python、Ruby、Smalltalk などの言語が受ける追加の電源機能を備えています。
詳細は、を参照し http://groovy.codehaus.org/ てください。

13.5.3. GroovyActionProcessor

Class org.jboss.soa.esb.actions.scripting.GroovyActionProcessor
このアクションは Groovy アクション処理スクリプトを実行し、message、payloadProxy、action configuration、および logger を変数入力として受け取ります。

表13.12 GroovyActionProcessor プロパティー

プロパティー Description 必須
script
Groovy スクリプトへのパス(クラスパス上)。
supportMessageBasedScripting
メッセージ内のスクリプトを許可します。
cacheScript
スクリプトをキャッシュする必要があります。デフォルトは true です。
いいえ

表13.13 GroovyAction プロセッサーバインディング変数

変数 Description
message
メッセージ
payloadProxy
メッセージペイロード(MessagePayloadProxy)のユーティリティー。
config
アクション設定(ConfigTree)。
logger
GroovyActionProcessor の静的 Log4J ロガー(ロガー)。ロギングカテゴリーは jbossesb.<esb_archive_name>.<category>.<service> です。
<action name="process" class="org.jboss.soa.esb.scripting.GroovyActionProcessor">
    <property name="script" value="/scripts/myscript.groovy"/>
</action>

13.5.4. Bean Scripting Framework (BSF)

Bean スクリプトフレームワークは、Apache Foundation によって開発されたオープンソースのスキャフォールディングです。これにより、スクリプトを Java コードに挿入することができます。

13.5.5. ScriptingAction

Class org.jboss.soa.esb.actions.scripting.ScriptingAction
Bean スクリプトフレームワークを使用してスクリプトを実行し、message、payloadProxy、action configuration、および logger を変数入力として受け取ります。
  1. Bean スクリプトフレームワークは、スクリプトを事前コンパイル、キャッシュ、再利用するための API を提供しません。このため、ScriptingAction の各実行は、再度コンパイルステップを実行します。パフォーマンス要件を評価する際には、これを念頭に置いてください。
  2. アプリケーションに BeanShell スクリプトを含める場合は、.bsh の代わりに .beanshell エクステンションを使用することが推奨されます。そうでないと、JBoss BSHDeployer がそれを取得する可能性があります。

表13.14 ScriptingAction プロパティー

プロパティー Description 必須
script
スクリプトへのパス(クラスパス上)。
supportMessageBasedScripting
メッセージ内のスクリプトを許可します。
language
オプションのスクリプト言語(拡張のデダクションをオーバーライドします)。
いいえ

表13.15 ScriptingAction プロセッサーのバインディング変数

変数 Description
message
メッセージ
payloadProxy
メッセージペイロードのユーティリティー(MessagePayloadProxy)
config
アクション設定(ConfigTree)
logger
ScriptingAction の静的 Log4J ロガー(ロガー)
<action name="process" class="org.jboss.soa.esb.scripting.ScriptingAction">
    <property name="script" value="/scripts/myscript.beanshell"/>
</action>

13.6. サービスアクション

13.6.1. サービスアクション

サービスアクションは、JBoss Enterprise SOA Platform の Enterprise Service Bus 内で定義されるアクションです。

13.6.2. EJBProcessor

入力タイプ EJB メソッド名とパラメーター
出力タイプ EJB 固有のオブジェクト
Class org.jboss.soa.esb.actions.EJBProcessor
入力メッセージを取得し、コンテンツを使用してステートレスセッション Bean を呼び出します。このアクションは EJB2.x および EJB3.x をサポートします。

表13.16 EJBProcessor プロパティー

プロパティー Description 必須
ejb3
EJB3.x セッション Bean を呼び出す場合。
ejb-name
EJB のアイデンティティー。ejb3 が true の場合は任意です。
jndi-name
関連する JNDI ルックアップ。
initial-context-factory
JNDI ルックアップメカニズム。
provider-url
関連するプロバイダー。
method
呼び出す EJB メソッド名。
lazy-ejb-init
EJB がデプロイ時にではなく、ランタイム時に初期化されるべきかどうか。デフォルトは false です。
いいえ
ejb-params
メソッドを呼び出す際に使用するパラメーターの一覧と、入力メッセージ内のどこにあるか。
esb-out-var
出力の場所。デフォルト値は DEFAULT_EJB_OUT です。
いいえ

例13.11 EJB 2.x の設定例

<action name="EJBTest" class="org.jboss.soa.esb.actions.EJBProcessor">
    <property name="ejb-name" value="MyBean" />
    <property name="jndi-name" value="ejb/MyBean" />
    <property name="initial-context-factory" value="org.jnp.interfaces.NamingContextFactory" />
    <property name="provider-url" value="localhost:1099" />
    <property name="method" value="login" />
    <!-- Optional output location, defaults to "DEFAULT_EJB_OUT"
    <property name="esb-out-var" value="MY_OUT_LOCATION"/> -->
    <property name="ejb-params">
    <!-- arguments of the operation and where to find them in the message -->
        <arg0 type="java.lang.String">username</arg0>
        <arg1 type="java.lang.String">password</arg1>
    </property>
</action>

例13.12 EJB 3.x の設定例

<action name="EJBTest" class="org.jboss.soa.esb.actions.EJBProcessor">
    <property name="ejb3" value="true" />
    <property name="jndi-name" value="ejb/MyBean" />
    <property name="initial-context-factory" value="org.jnp.interfaces.NamingContextFactory" />
    <property name="provider-url" value="localhost:1099" />
    <property name="method" value="login" />
    <!-- Optional output location, defaults to "DEFAULT_EJB_OUT"
    <property name="esb-out-var" value="MY_OUT_LOCATION"/> -->
    <property name="ejb-params">
        <!-- arguments of the operation and where to find them in the message -->
        <arg0 type="java.lang.String">username</arg0>
        <arg1 type="java.lang.String">password</arg1>
    </property>
</action>

13.7. ルーティングアクション

13.7.1. ルーティングアクション

ルーティングアクションは、サービスのパイプラインに追加できるアクションです。2 つ以上のメッセージ交換参加者間のメッセージの条件付きルーティングを実行します。

13.7.2. アグリゲーター

Class org.jboss.soa.esb.actions.Aggregator
これはメッセージ集約アクションです。 これは、Aggregator エンタープライズ統合パターンの実装です(を参照 http://www.enterpriseintegrationpatterns.com/Aggregator.html )。
このアクションは、正しい相関データを持つすべてのメッセージに依存します。このデータは、メッセージ上で aggregatorTag (Message.Properties)と呼ばれるプロパティーとして設定されます。ContentBasedRouter および StaticRouter アクションを参照してください。
データの形式は以下のとおりです。
[UUID] ":" [message-number] ":" [message-count]
すべてのメッセージがアグリゲーターによって受信された場合、Message.Attachment リスト(名前のない)の一部としてすべてのメッセージを含む新しい Message を返します。それ以外の場合は、アクションは null を返します。

表13.17 Aggregator プロパティー

プロパティー Description 必須
timeoutInMillis
集約プロセスがタイムアウトするまでのタイムアウト時間(ミリ秒単位)。
いいえ
<action class="org.jboss.soa.esb.actions.Aggregator" name="Aggregator">
    <property name="timeoutInMillies" value="60000"/>
</action>

13.7.3. ストリーミングアグリゲーター

Class org.jboss.soa.esb.actions.StreamingAggregator
このアクションにより、ルーティングアクションパイプラインから外部(ESB-unaware) HTTP エンドポイントを呼び出すことができます。このアクションは Apache Commons HttpClient を使用します。Aggregator エンタープライズ統合パターンの実装は、以下を参照してください。 http://www.enterpriseintegrationpatterns.com/Aggregator.html
Streaming Aggregator は、メッセージ集約アクションの改善バージョンです。以前のアグリゲーターとは異なり、ストリーミングアグリゲーターはすべてのメッセージの完全な集約詳細を必要としません。メッセージにはメッセージの順序番号と一意の集約 ID が必要ですが、すべてのメッセージは各メッセージで集約されるメッセージ数を指定する必要はありません。集約されたメッセージの数は後続のメッセージで送信できます。これは、行のカウントまたは解析が必要な非常に大きなファイルを処理する場合のパフォーマンスが向上することです。または、分割する必要がある Smooks フラグメントです。
データは、org.jboss.soa.esb.actions.aggregator.AggregateDetails オブジェクトを含める必要がある "Aggregate.AggregateDetails" と呼ばれるプロパティーとしてメッセージに設定されます。
データの形式は以下のとおりです。
[SeriesUUID] ":" [message-sequence] ":" [sequence-count]
Streaming Aggregator によってすべてのメッセージが受信した場合は、Message.Attachment リストの一部としてすべてのメッセージを含む新しいメッセージを返します(名前なし)。それ以外の場合は、アクションは null を返します。

表13.18 Aggregator プロパティー

プロパティー Description 必須
timeoutInMillis
集約プロセスがタイムアウトするまでのタイムアウト時間(ミリ秒単位)。
いいえ
<action class="org.jboss.soa.esb.actions.StreamingAggregator" name="Aggregator">
    <property name="timeoutInMillies" value="60000"/>
</action>

13.7.4. EchoRouter

このアクションは、受信メッセージペイロードを情報ログストリームにエコーし、プロセスメソッドから入力メッセージを返します。

13.7.5. HttpRouter

Class org.jboss.soa.esb.actions.routing.http.HttpRouter
このアクションにより、アクションパイプラインから外部 HTTP エンドポイントを呼び出すことができます。このアクションは Apache Commons HttpClient を使用します。

表13.19 Apache Commons HttpRouter

プロパティー Description 必須
unwrap
これを true (デフォルト)に設定すると、送信前に Message オブジェクトからメッセージペイロードを抽出します。false は、MessageType に基づいて、シリアル化されたメッセージを XML または Base64 でエンコードされた JavaSerialized オブジェクトとして送信します。
いいえ
endpointUrl
メッセージが転送されるエンドポイント。
はい
http-client-property
HttpRouter は HttpClientFactory を使用して HttpClient インスタンスを作成および設定します。ローカルファイルシステム、クラスパス、または URI ベースのプロパティーファイルを参照する file プロパティーを使用して、ファクトリーの設定を指定できます。これがどのように実行されるかを確認するには、以下の例を参照してください。
いいえ
method
現在、GET および POST のみをサポートしています。
はい
responseType
応答の送信フォームを指定します。STRING または BYTES のいずれか。デフォルト値は STRING です。
いいえ
headers
リクエストに追加されます。複数の <header name="test" value="testvalue" /> 要素をサポートします。
いいえ
MappedHeaderList
ターゲットエンドポイントに伝播される必要があるヘッダー名のコンマ区切りリスト。ヘッダーの値は、http-gateway または現在のメッセージのプロパティー内でエンタープライズサービスバスに入るリクエストに存在する値から取得されます。
いいえ
<action name="httprouter"  class="org.jboss.soa.esb.actions.routing.http.HttpRouter">
    <property name="endpointUrl"value="http://host:80/blah">
        <http-client-property name="file" value="/ht.props"/>
    </property>
    <property name="method" value="GET"/>
    <property name="responseType" value="STRING"/>
    <property name="headers">
        <header name="blah" value="blahval" ></header>
    </property>
</action>

13.7.6. Java Message Service

Java Message Service (JMS) は、2 つのクライアント間でメッセージを送信するための Java API です。これにより、分散アプリケーションのさまざまなコンポーネントが相互に通信できるようになり、疎結合と非同期が可能になります。さまざまな Java Message Service プロバイダーが利用可能です。Red Hat は、HornetQ の使用を推奨しています。

13.7.7. JMSRouter

Class org.jboss.soa.esb.actions.routing.JMSRouter
受信メッセージを Java Message Service にルーティングします。

表13.20 JMSRouter

プロパティー Description 必須
unwrap
これを true に設定すると、送信前に Message オブジェクトからメッセージペイロードを抽出します。false (デフォルト)はシリアライズされた Message オブジェクトを送信します。
いいえ
jndi-context-factory
使用する JNDI コンテキストファクトリー。デフォルトは org.jnp.interfaces.NamingContextFactory です。
いいえ
jndi-URL
使用する JNDI URL。デフォルトは 127.0.0.1:1099 です。
いいえ
jndi-pkg-prefix
使用する JNDI 命名パッケージ接頭辞。デフォルトは org.jboss.naming:org.jnp.interfacesです。
いいえ
connection-factory
使用する ConnectionFactory の名前。デフォルトは ConnectionFactory です。
いいえ
persistent
JMS DeliveryMody、true (デフォルト)、または false
いいえ
priority
使用する JMS 優先度。デフォルトは javax.jms.Message.DEFAULT_PRIORITY です。
いいえ
time-to-live
使用する JMS Time-To-Live。デフォルトは javax.jms.Message.DEFAULT_TIME_TO_LIVE です。
いいえ
security-principal
JMS 接続の作成時に使用するセキュリティープリンシパル。
はい
security-credentials
JMS 接続の作成時に使用するセキュリティー認証情報。
はい
property-strategy
デフォルトをオーバーライドする場合、JMSPropertiesSetter インターフェイスの実装。
いいえ
message-prop
メッセージに設定するプロパティーの前に message-prop が付けられます。
いいえ
jndi-prefixes
接頭辞のコンマ区切りの文字列。これらの接頭辞を持つプロパティーは JNDI 環境に追加されます。
いいえ

13.7.8. EmailRouter

Class org.jboss.soa.esb.actions.routing.email.EmailRouter
受信メッセージを設定済みのメールアカウントにルーティングします。

表13.21 EmailRouter プロパティー

プロパティー Description 必須
unwrap
true は、送信前に Message オブジェクトからメッセージペイロードを抽出します。false (デフォルト)はシリアル化された Message オブジェクトを送信します。
 
host
SMTP サーバーのホスト名。指定しない場合、jbossesb-properties.xml のプロパティー 'org.jboss.soa.esb.mail.smtp.host' にデフォルト設定されます。
 
port
SMTP サーバーのポート。指定しない場合、jbossesb-properties.xml のプロパティー 'org.jboss.soa.esb.mail.smtp.port' にデフォルト設定されます。
 
username
SMTP サーバーのユーザー名。指定しない場合、jbossesb-properties.xml のプロパティー 'org.jboss.soa.esb.mail.smtp.user' にデフォルト設定されます。
 
password
SMTP サーバーの上記のユーザー名のパスワード。指定しない場合、jbossesb-properties.xml のプロパティー 'org.jboss.soa.esb.mail.smtp.password' にデフォルト設定されます。
 
auth
true の場合、AUTH コマンドを使用してユーザーの認証を試みます。指定しない場合、jbossesb-properties.xml のプロパティー 'org.jboss.soa.esb.mail.smtp.auth' にデフォルト設定されます。
 
from
差出人の電子メールアドレス。
 
sendTo
宛先メールアカウント。
 
subject
メールの件名。
 
messageAttachmentName
メッセージペイロードを含む添付のファイル名(オプション)。指定しない場合には、メッセージペイロードはメッセージボディーに含まれます。
 
message
メールメッセージを設定する VNID メッセージの内容の前に付けられる文字列(オプション)
 
ccTo
メールアドレスのコンマ区切りリスト(オプション)
 
attachment
送信メールに添付ファイルとして追加されるファイルを含む子要素。
 
<action name="send-email"  class="org.jboss.soa.esb.actions.routing.email.EmailRouter">
    <property name="unwrap" value="true" /> 
    <property name="host" value="smtpHost" /> 
    <property name="port" value="25" /> 
    <property name="username" value="smtpUser" /> 
    <property name="password" value="smtpPassword" /> 
    <property name="from" value="jbossesb@xyz.com" /> 
    <property name="sendTo" value="system2@xyz.com" /> 
    <property name="subject" value="Message Subject" />  
</action>

13.7.9. Content-Based Router

コンテンツベースのルーターは、宛先アドレスを持たないメッセージを正しいエンドポイントに送信します。コンテンツベースのルーティングは、一連のルール (XPath または Drools 表記で定義可能) をメッセージの本文に適用することによって機能します。これらのルールは、どの当事者がメッセージに関心を持っているかを確認します。これは、送信アプリケーションが宛先アドレスを提供する必要がないことを意味します。
一般的な使用例は、優先度の高いキューで優先度の高いメッセージを処理することです。ここでの利点は、そのように設定されている場合、サービスの実行中にルーティングルールをオンザフライで変更できることです。(ただし、これには重大なパフォーマンス上の欠点があります。)
コンテンツベースのルーターが役立つ可能性があるその他の状況には、元の宛先が存在しなくなった場合、サービスが移動した場合、またはアプリケーションが時刻などの要素のコンテンツに基づいてメッセージの送信先をより詳細に制御したい場合などがあります。

13.7.10. RegexProvider

RegexProvider は正規表現を使用します。これにより、フィルターされるメッセージで選択したデータフィールドの形式に固有の低レベルのルールを定義できます。たとえば、特定のフィールドに適用して構文を検証し、適切な電子メールアドレスが使用されていることを確認できます。

13.7.11. XPath ドメイン固有の言語

注記
XML ベースのメッセージの XPath ベースの評価を実行すると便利な場合があります。Red Hat は、ドメイン固有の言語実装を提供することで、これをサポートします。この実装を使用して、XPath 式をルールファイルに追加します。
  1. まず、XPathLanguage.dsl ファイルで式を定義し、以下のコードを使用してルールセットでそれを参照します。
    expander XPathLanguage.dsl
    
  2. XPath 言語は、メッセージが JBOSS_XML にあり、以下の項目が定義されていることを確認します。
    1. xpathMatch&lt;element> : この名前は、この名前による要素が一致した場合に true を生成します。
    2. xpathEquals&lt;element& gt; , <value > : 要素が検出され、その値が等しい場合は true になります。
    3. xpathGreaterThan&lt;element& gt; , < value > : 要素が検出され、その値が値よりも大きい場合は、true になります。
    4. xpathLessThan&lt;element& gt; , < value > : これは、要素が検出され、その値が小さい場合に true を生成します。
    注記
    fun_cbr クイックスタートは XPath の使用を示しています。
    注記
    完全に異なるドメイン固有の言語を定義できます。

13.7.12. ContentBasedRouter

Class org.jboss.soa.esb.actions.ContentBasedRouter
コンテンツベースのメッセージルーティングアクション。
このアクションは、以下のルーティングルールプロバイダータイプをサポートします。
  • XPath: アクション上でインラインで定義される単純な XPath ルール、または .properties 形式のファイルで外部で定義される単純な XPath ルール。
  • Drools: Drools ルールファイル(DSL)XPath ベースの DSL の追加設定なしサポート。

表13.22 ContentBasedRouter プロパティー

プロパティー Description 必須
cbrAlias
コンテンツベースのルーティングプロバイダーエイリアス。サポートされる値は Drools (デフォルト)、Xpath、および regex です。
ruleSet
外部で定義されたルールファイル。Drools ルールプロバイダーが使用されている場合は Drools DSL ファイル、XPath プロバイダーまたは Regex プロバイダーが使用されている場合は .properties ルールファイルになります。
ruleLanguage
CBR 評価のドメイン固有言語(DSL)ファイルDrools ルールプロバイダーにのみ関連します。
ruleReload
毎回ルールファイルをリロードする必要があるかどうかを示すフラグ。デフォルトは false です。
ruleAuditType
Drools が監査ロギングを実行できるようにする任意のプロパティー。ログは Drools Eclipse プラグインに読み取り、検査できます。有効な値は CONSOLE、FILE、および THREADED_FILE です。デフォルトでは、監査ロギングは実行されません。
 
ruleAuditFile
監査ロギングのファイルパスを定義する任意のプロパティー。FILE または THREADED_FILE ruleAuditType にのみ適用されます。デフォルトは event です。JBoss Drools は、.log を追加することに注意してください。このファイルのデフォルトの場所は. - 現在の作業ディレクトリーです(JBoss は bin/ ディレクトリーにあります)。
 
ruleAuditInterval
監査イベントを監査ログにフラッシュする頻度を定義する任意のプロパティー。THREADED_FILE ruleAuditType にのみ適用されます。デフォルトは 1000 (ミリ秒)です。
 
destinations
<route-to> 設定のコンテナープロパティー。ルールが外部に定義されている場合は、この設定の形式は以下のようになります。
<route-to destination-name="express" 
    service-category="ExpressShipping" service-name="ExpressShippingService"/>
設定でルールをインラインで定義すると、この設定のフォーマットは以下のとおりです(Drools プロバイダーではサポートされません)。
<route-to service-category="ExpressShipping" 
    service-name="ExpressShippingService" expression="/order[@statusCode='2']" />
namespaces
必要な場合の <namespace> 設定のコンテナープロパティー(XPath ruleprovider など)。<namespace> 設定の形式は以下のとおりです。
<namespace prefix="ord" uri="http://acme.com/order" />

表13.23 ContentBasedRouter "process" メソッド

プロパティー Description 必須
process
メッセージに集計データを追加しないでください。
split
メッセージに集約データを追加します。

例13.13 設定 XPATH の例(インライン)

<action process="split" name="ContentBasedRouter" 
    class="org.jboss.soa.esb.actions.ContentBasedRouter">
    <property name="cbrAlias" value="XPath"/>
    <property name="destinations">
        <route-to service-category="ExpressShipping"                 
            service-name="ExpressShippingService" expression="/order['status='1']" />
        <route-to service-category="NormalShipping"  
            service-name="NormalShippingService" expression="/order['status='2']" />
    </property>  
</action>

例13.14 設定 XPATH の例(外部)

<action process="split" name="ContentBasedRouter" 
    class="org.jboss.soa.esb.actions.ContentBasedRouter">
    <property name="cbrAlias" value="XPath"/>
    <property name="ruleSet" value="xpath-rules.properties"/>
    <property name="ruleReload" value="true"/>
    <property name="destinations">
        <route-to destination-name="express" service-category="ExpressShipping"                 
            service-name="ExpressShippingService"/>
        <route-to destination-name="normal" service-category="NormalShipping"  
            service-name="NormalShippingService"/>
    </property>
</action>
regex は XPath とまったく同じように設定されます。唯一の違いは、式が(XPath 式ではなく) Regex 式です。

13.7.13. StaticRouter

Class org.jboss.soa.esb.actions.StaticRouter
静的メッセージルーティングアクション。これは基本的に、コンテンツベースのルーティングルールをサポートしない場合を除き、コンテンツベースルーターのシンプルなバージョンです。

表13.24 StaticRouter プロパティー

プロパティー 説明
destinations
<route-to> 設定のコンテナープロパティー。
<route-to destination-name="express" service-category="ExpressShipping" 
    service-name="ExpressShippingService"/>>

表13.25 StaticRouter プロセスメソッド

メソッド Description
process
メッセージに集計データを追加しないでください。
split
メッセージに集約データを追加します。
<action name="routeAction" class="org.jboss.soa.esb.actions.StaticRouter">
    <property name="destinations">
        <route-to service-category="ExpressShipping" service-name="ExpressShippingService"/>
        <route-to service-category="NormalShipping" service-name="NormalShippingService"/>
    </property>  
</action>

13.7.14. SyncServiceInvoker

Class org.jboss.soa.esb.actions.SyncServiceInvoker
同期メッセージルーティングアクション。このアクションは、設定されたサービスで同期呼び出しを行い、後続のアクション(ある場合)による処理のために呼び出し応答をアクションパイプラインに渡し(ある場合)、またはサービスが RequestResponse サービスである場合は への応答として渡します。

表13.26 SyncServiceInvoker Properties

プロパティー Description 必須
service-category
サービスカテゴリー。
はい
service-name
Service Name。
はい
failOnException
アクションがターゲットサービス呼び出しの例外で失敗する場合。false に設定すると、アクションによって入力メッセージがパイプラインに返され、サービスが処理を継続できるようになります。障害状態を把握する必要がある場合は、このパラメーターを true に設定したままにし、パイプラインの失敗を許可することで通常のfaultTo メカニズムを使用します(デフォルトは true)。
いいえ
suspendTransaction
アクティブなトランザクションが存在すると、このアクションは失敗します。このプロパティーが true に設定されている場合、トランザクションを一時停止できます。デフォルトは false です。
いいえ
ServiceInvokerTimeout
インボーカーのタイムアウト(ミリ秒単位)。タイムアウトが発生すると例外が発生し、アクションが failOnException 設定に従って動作します。デフォルトは 30000 です。
いいえ
<action name="route” class="org.jboss.soa.esb.actions.SyncServiceInvoker">
    <property name="service-category" value="Services" />
    <property name="service-name" value="OM" />
</action>

13.7.15. StaticWireTap

Class org.jboss.soa.esb.actions.StaticWireTap
StaticWiretap アクションは StaticRouter とは異なります。StaticWiretap はアクションチェーンでリッスンし、その下のアクションを実行できるようにします。一方、StaticRouter アクションは、使用される時点でアクションチェーンを終了します。したがって、StaticRouter はチェーンの最後のアクションである必要があります。

表13.27 StaticWireTap プロパティー

プロパティー Description 必須
destinations
<route-to> 設定のコンテナープロパティー。
<route-to destination-name="express" service-category="ExpressShipping" 
    service-name="ExpressShippingService"/>

表13.28 StaticWireTap プロセスメソッド

メソッド Description
process
メッセージに集計データを追加しないでください。
<action name="routeAction" class="org.jboss.soa.esb.actions.StaticWiretap">
    <property name="destinations">
        <route-to service-category="ExpressShipping" service-name="ExpressShippingService"/>
        <route-to service-category="NormalShipping" service-name="NormalShippingService"/>
    </property>  
</action>

13.7.16. E.-Mail WireTap

Class org.jboss.soa.esb.actions.routing.email.EmailWiretap

表13.29 E.-Mail WireTap プロパティー

プロパティー 説明
host
SMTP サーバーのホスト名。指定しない場合、jbossesb-properties.xml のプロパティー 'org.jboss.soa.esb.mail.smtp.host' にデフォルト設定されます。
port
SMTP サーバーのポート。指定しない場合、jbossesb-properties.xml のプロパティー 'org.jboss.soa.esb.mail.smtp.port' にデフォルト設定されます。
username
SMTP サーバーのユーザー名。指定しない場合、jbossesb-properties.xml のプロパティー 'org.jboss.soa.esb.mail.smtp.user' にデフォルト設定されます。
password
SMTP サーバーの上記のユーザー名のパスワード。指定しない場合、jbossesb-properties.xml のプロパティー 'org.jboss.soa.esb.mail.smtp.password' にデフォルト設定されます。
auth
true の場合、AUTH コマンドを使用してユーザーの認証を試みます。指定しない場合、jbossesb-properties.xml のプロパティー 'org.jboss.soa.esb.mail.smtp.auth' にデフォルト設定されます。
from
from のメールアドレス。
sendTo
宛先メールアカウント。
subject
メールの件名。
messageAttachmentName
メッセージペイロードを含む添付のファイル名(オプション)。指定しない場合には、メッセージペイロードはメッセージボディーに含まれます。
message
メールメッセージを設定します(オプション)。これは、Madobe メッセージの内容の前に付けられる文字列です。
ccTo
メールアドレスのコンマ区切りリスト(オプション)。
attachment
送信メールに添付ファイルとして追加されるファイルが含まれる子要素。
<action name="send-email" class="org.jboss.soa.esb.actions.routing.email.EmailWiretap"> 
    <property name="host" value="smtpHost" /> 
    <property name="port" value="25" /> 
    <property name="username" value="smtpUser" /> 
    <property name="password" value="smtpPassword" /> 
    <property name="from" value="jbossesb@xyz.com" /> 
    <property name="sendTo" value="systemX@xyz.com" /> 
    <property name="subject" value="Important message" /> 
</action>

13.8. 通知アクション

13.8.1. 通知アクション

Notifier アクションは、アクションパイプライン処理の結果に基づいて、設定で指定された通知ターゲットリストに通知を送信します。
Notifier は、アクションパイプラインの処理の最初の段階でメッセージを処理しないアクションです。代わりに、2 番目の段階で指定された通知を送信します。

13.8.2. Notifier

Class org.jboss.soa.esb.actions.Notifier
Notifier クラス設定は NotificationList 要素を定義するために使用されます。これは NotificationTargets のリストを指定するために使用できます。"ok" タイプの NotificationList は、アクションパイプライン処理が正常に実行されると通知を受信するターゲットを指定します。err タイプの NotificationList は、前述のアクションパイプライン処理セマンティクスに従って、例外アクションパイプライン処理時に通知を受信するターゲットを指定します。"err" と "ok" はいずれも大文字と小文字を区別しません。
NotificationTarget に送信される通知はターゲット固有ですが、基本的にはアクションパイプライン処理が行われるメッセージのコピーで設定されます。通知ターゲットタイプとそのパラメーターがこのセクションの最後に表示されます。
アクション処理パイプラインの各ステップで成功または失敗を通知するには、Notifier クラスを使用する <action> を含めるのではなく、各 <action> 要素に "okMethod" 属性および "exceptionMethod" 属性を使用します。
<action name="notify" class="org.jboss.soa.esb.actions.Notifier"  okMethod="notifyOK">
    <property name="destinations">
        <NotificationList type="OK">
            <target class="NotifyConsole" />
            <target class="NotifyFiles" >
                <file name="@results.dir@/goodresult.log" />
            </target>
        </NotificationList> 
        <NotificationList type="err">
            <target class="NotifyConsole" />
            <target class="NotifyFiles" >
                <file name="@results.dir@/badresult.log" />
            </target>    
        </NotificationList> 
    </property>
</action>

13.8.3. NotifyConsole

Class NotifyConsole
コンソールでメッセージの内容を出力することにより、通知を実行します。

例13.15 NotifyConsole

<target class="NotifyConsole" />

13.8.4. NotifyFiles

Class NotifyFiles
目的 指定ファイルセットにメッセージの内容を書き込むことにより、通知を実行します。
属性 none
child file
child 属性
  • append: 値が true の場合、通知を既存のファイルに追加します。
  • uri - ファイルを指定する有効な URI
<target class="NotifyFiles" >
<file append="true" URI="anyValidURI"/>
<file URI="anotherValidURI"/>
</target>

13.8.5. NotifySqlTable

Class NotifySqlTable
目的 既存のデータベーステーブルにレコードを挿入して、通知を実行します。データベースレコードにはグローバルなメッセージの内容が含まれ、任意でネストされた <column> 要素を使用して指定された他の値が含まれます。
属性
  • driver-class
  • connection-url
  • user-name
  • password
  • table: 通知レコードが保存されるテーブル。
  • dataColumn - メッセージの内容が保存されるテーブル列の名前。
child
child 属性
  • name: 追加の値を保存するテーブル列の名前
  • value - 保存される値
<target class="NotifySqlTable" driver-class="com.mysql.jdbc.Driver"
connection-url="jdbc:mysql://localhost/db"
user-name="user"
password="password"
table="table"
dataColumn="messageData">
<column name="aColumnlName" value="aColumnValue"/>
</target>

13.8.6. NotifyQueues

Class NotifyQueues
目的 メッセージを JMS メッセージ(割り当てられたプロパティーを含む)を JMS メッセージに変換し、JMS メッセージをキューのリストに送信して通知を実行します。追加のプロパティーは、<messageProp> 要素を使用して割り当てることができます。
属性 none
child queue
child 属性
  • jndiName - キューの JNDI 名。必須
  • jndi-URL - JNDI プロバイダー URL ( 任意 )。
  • jndi-context-factory - JNDI 初期コンテキストファクトリーの 任意
  • jndi-pkg-prefix - JNDI パッケージ接頭辞 Optional
  • connection-factory - JMS 接続ファクトリーの JNDI 名。オプション の。デフォルトは ConnectionFactory です。
child messageProp
child 属性
  • name - 追加する新しいプロパティーの名前
  • value - 新しいプロパティーの値
<target class="NotifyQueues" >
<messageProp name="aNewProperty" value="theValue"/>
<queue jndiName="queue/quickstarts_notifications_queue" />
</target>

13.8.7. NotifyTopics

Class NotifyTopics
目的 モデルメッセージ(割り当てられたプロパティーを含む)を JMS メッセージに変換し、JMS メッセージをトピックのリストに公開することで通知を実行します。追加のプロパティーは、<messageProp> 要素を使用して割り当てることができます。
属性 none
child topic
child 属性
  • jndiName - キューの JNDI 名。必須
  • jndi-URL - JNDI プロバイダーの URL。オプション
  • jndi-context-factory - JNDI 初期コンテキストファクトリー。オプション
  • jndi-pkg-prefix - JNDI パッケージ接頭辞。オプション
  • connection-factory - JMS 接続ファクトリーの JNDI 名。オプション の。デフォルトは ConnectionFactoryです。
child messageProp
child 属性
  • name - 追加する新しいプロパティーの名前
  • value - 新しいプロパティーの値
<target class="NotifyTopics" >
<messageProp name="aNewProperty" value="theValue"/>
<queue jndiName="queue/quickstarts_notifications_topic" />
</target>

13.8.8. NotifyEmail

Class NotifyEmail
目的 2025 メッセージコンテンツを含む通知メールを送信し、オプションでファイルの添付ファイルを送信します。
属性 なし。
child トピック。
child 属性
  • from – email address (javax.email.InternetAddress).必須
  • sendto: メールアドレスのコンマ区切りリスト必須
  • ccTo: メールアドレスのコンマ区切りリスト。オプション
  • Subject: email subject。必須
  • message: メール メッセージ を設定するためのメッセージの内容の前に付けられる文字列。オプション
child attachment.オプション
子テキスト 割り当てるファイルの名前。
<target class="NotifyEmail" from="person@somewhere.com"
sendTo="person@elsewhere.com"
subject="theSubject">
<attachment>attachThisFile.txt</attachment>
</target>

13.8.9. NotifyFTP

Class NotifyFTP
目的 2025 メッセージコンテンツを含むファイルを作成し、FTP 経由でリモートファイルシステムに転送して、通知を実行します。
属性 なし。
child FTP
child 属性
  • URL - 有効な FTP URL
  • filename - リモートシステムのメッセージコンテンツが含まれるファイルの名前
<target class="NotifyFTP" >
    <ftp URL="ftp://username:pwd@server.com/remote/dir" filename="someFile.txt" />
</target>

13.8.10. NotifyFTPList

Class NotifyFTPList
目的
NotifyFTPList は NotifyFTP を拡張し、単一のファイル名またはルート Message オブジェクトにあるファイル名の一覧を取る機能を追加します。
Message ペイロードの ファイルには、ファイルの一覧(完全パス)が含まれている必要があります。"listFiles" プロパティーが false の場合、この一覧内のすべてのファイルが設定済みの宛先 FTP サーバーディレクトリーに送信されます。"listFiles" が true の場合、ファイルは行ごとに読み取られ、各行には転送するファイルの名前が含まれます。
そのため、以下を指定できます。
  1. 転送される単一ファイル(listFiles = false を持つ単一の文字列ペイロード)
  2. 転送するファイルの一覧。(listFiles = false を含むリスト<String>ペイロード)
  3. 転送するファイルの単一リストファイル(listFiles = true を持つ単一の文字列ペイロード)
  4. 転送するファイルの一覧ファイルのリスト。(listFiles = true を含むリスト<String>ペイロード)
属性 なし。
child FTP。
child 属性
  • URL - 有効な FTP URL
  • filename - リモートシステムのメッセージコンテンツが含まれるファイルの名前
  • listFiles - メッセージペイロードで名前が付けられたファイルがリストファイルの場合、それ以外の場合は false になります。デフォルトは false です。
  • deleteListFile: リストファイルを削除する場合は true、それ以外の場合は false。デフォルトは false です。
<target class="NotifyFTPList">
    <ftp URL="ftp://username:password@localhost/outputdir"
        filename="{org.jboss.soa.esb.gateway.file}">
        listFiles="true"
        deletelistFile="true"
</target>

13.8.11. NotifyTCP

Class NotifyTCP
目的
TCP 経由でメッセージを送信します。各接続は通知期間中のみ維持されます。
文字列データペイロードの明示的な送信のみをサポートします(文字列として、またはバイト配列(byte[])としてエンコードされます)。
属性 なし。
child 宛先(複数の宛先をサポートします)。
child 属性
  • uri: データを書き込む TCP アドレス。デフォルトのポートは 9090 です。
<target class="NotifyTcp" >
  <destination URI="tcp://myhost1.net:8899" />
  <destination URI="tcp://myhost2.net:9988" />
</target>

13.9. SOAP クライアントアクション

13.9.1. Simple Object Access Protocol (SOAP)

Simple Object Access Protocol (SOAP)は、ユーザーがメッセージの内容を定義し、受信者がそのメッセージを処理する方法をヒントを提供できるようにする軽量プロトコルです。SOAP は XML ベースの通信プロトコルです。

13.9.2. SOAPProcessor

SOAPProcessor は、JBossESB がホストする任意のリスナーを介して JBossWS がホストする Web サービスエンドポイントを呼び出すことを可能にするアクションです。このアクションを介して、エンタープライズサービスバスは、まだ公開されていないサービスの Web サービスエンドポイントを公開できます。その後、HTTP、FTP、JMS など、エンタープライズサービスバスでサポートされている任意のトランスポートチャネルを介してサービスを呼び出すことができます。
SOAPProcessor は JBossWS-Native と JBossWS-CXF スタックの両方をサポートします。

13.9.3. SOAPProcessor アクション設定

SOAPProcessor アクションアクションに必要な必須のプロパティー値は jbossws-endpoint プロパティーの 1 つだけです。このプロパティーは、SOAPProcessor が公開する JBossWS エンドポイントに名前を付けます(非推奨)。
<action name="JBossWSAdapter" class="org.jboss.soa.esb.actions.soap.SOAPProcessor">
    <property name="jbossws-endpoint" value="ABI_OrderManager" />
    <property name="jbossws-context" value="ABIV1OrderManager_war" />
    <property name="rewrite-endpoint-url" value="true" />
</action>
jbossws-endpoint
これは、SOAPProcessor が公開している JBossWS エンドポイントです。必須。
jbossws-context
このオプションプロパティーは Web サービスのデプロイメントのコンテキスト名であり、JBossWS エンドポイントを一意に識別するために使用できます。
rewrite-endpoint-url
オプションの "rewrite-endpoint-url" プロパティーは、HTTP エンドポイントでの負荷分散をサポートするために存在します。この場合、Webservice エンドポイントコンテナーは WSDL の HTTP (S)エンドポイントアドレスをロードバランサーのロードバランサーに設定するように設定されます。この場合、rewrite-endpoint-url プロパティーを使用して、HTTP エンドポイントアドレスの書き換えをオフにできます。HTTP 以外のプロトコルには影響しません。デフォルトは true です。
重要
JBossWS Webservice エンドポイントは、このアクションを使用して Na リスナーで公開できます。ただし、これは JBoss Enterprise SOA Platform Server でサポートされないため、.esb デプロイメントが JBoss Application Server にインストールされている場合にのみ使用できることを意味します。

13.9.4. SOAPProcessor アクションの使用

前提条件

  • soap.esb サービス。これは、製品の lib ディレクトリーにあります。

手順13.2 タスク

  • Web サービスのエンドポイントを持たないターゲットサービスへの呼び出しをラップするシンサービスラッパー Web サービス(JSR 181 実装など)を記述します。
    エンタープライズサービスバスで実行しているエンドポイントを使用してターゲットサービスを公開します。

13.9.5. SOAPClient

SOAPClient アクションは、Wise Client Service を使用して JAXWS クライアントクラスを生成し、ターゲットサービスを呼び出します。
<action name="soap-wise-client-action" class="org.jboss.soa.esb.actions.soap.wise.SOAPClient">
    <property name="wsdl" value="http://host:8080/OrderManagement?wsdl"/>
    <property name="SOAPAction" value="http://host/OrderMgmt/SalesOrder"/>
    <property name="wise-config">
        <wise-property name="wise.tmpDir" value="/tmp" />
        <wise-property name="wise.jaxb.bindings" value="some.xjb,additional.xml" />
    </property>
</action>

表13.30 SOAPClient オプションプロパティー

プロパティー 説明
wsdl
使用する WSDL。
operationName
webservice WSDL で指定される操作の名前。
SOAPAction
エンドポイント操作は operationName に置き換えられました。
EndPointName
呼び出されたエンドポイント。Webservices には複数のエンドポイントを含めることができます。指定のない場合は、wsdl の最初の名前が使用されます。
SmooksRequestMapper
Smooks 設定ファイルを指定して、リクエストに定義された Java から Java マッピングを定義します。
SmooksResponseMapper
Smooks 設定ファイルを指定して、応答に定義された Java から Java マッピングを定義します。
serviceName
オブジェクト生成のキャッシュや、すでに生成されたオブジェクトをキャッシュするために Wise が使用するシンボリックサービス名。指定しないと、Wise は wsdl のサーブレット名を使用します。
username
web サービスが BASIC 認証 HTTP によって保護されている場合に使用されるユーザー名。
password
web サービスが BASIC 認証 HTTP によって保護されている場合に使用されるパスワード。
smooks-handler-config
多くの場合、SOAP リクエストまたは応答を変換する必要があります(特に ヘッダー)。これは、単に標準の SOAP ハンドラーを追加するだけです。wise は JAXWS SOAP ハンドラー(カスタムハンドラーまたは Smook に基づく事前定義されたハンドラーの両方)をサポートします。
SOAP リクエストの変換(送信前)は、Smooks 変換設定プロパティーで SOAPClient アクションを設定することでサポートされます。
custom-handlers
カスタム標準の JAXWS SOAP ハンドラーのセットを提供することもできます。パラメーターは、SonapHandler インターフェイスを実装するクラスの一覧を受け入れます。クラスは完全修飾名を指定し、セミコロンで区切る必要があります。
LoggingMessages
送信された SOAP メッセージと受信した応答を表示する場合は、デバッグを行う場合に便利です。理想的には、System.out で交換されたすべてのメッセージを出力する JAX-WS ハンドラーを使用して、このゴールを達成します。ブール値。
wise-config
Wise クライアントの設定に使用できる wise-property 要素の一覧。wise-property 要素は、name 属性および value 属性で設定されます。特殊な wise.jaxb.bindings プロパティーを使用して JAXB カスタマイズを指定できます。コンマ -eparated list of resource name included in the 2009 archive を受け入れます。
重要
呼び出される Web サービスに SOAP 障害と HTTP 500 エラーがある場合、JBoss Enterprise SOA Platform の SOAP ユーザーインターフェイスクライアントは以下を行います。
  1. HTTP SOAP (POST) request to...で Warning [SOAPClient] Received status code '500' を出力します。
  2. 障害を無視して、次のアクションに進みます。
このアクションの使用方法を示すクイックスタートは、JBoss Enterprise SOA Platform の samples/quickstarts ディレクトリーにあります。
soapUI Client Service を使用して、ターゲットサービスのメッセージを構築し、設定します。その後、このアクションはそのメッセージをそのサービスにルーティングします。を参照してください http://www.soapui.org/
SOAP 操作パラメーターは、以下の 2 つの方法のいずれかで提供されます。
  1. デフォルトのボディーの場所に設定されるマップインスタンスとして (Message.getBody().add(Map))
  2. 名前付きボディーの場所 (Message.getBody().add(String, Map)) に設定されたマップインスタンスとして、その本文の場所の名前は get-payload-location アクションプロパティーの値として指定します。
パラメーターマップ自体は、次の 2 つの方法のいずれかで入力することもできます。
  1. OGNL フレームワークを使用して(SOAP メッセージパラメーター用)にアクセスするオブジェクトのセット。
  2. String ベースのキーと値のペア(<String, Object>)のセットでは、キーはキーの値で設定される SOAP パラメーターを識別する OGNL 式です。

13.9.6. Object Graph Navigation Library (OGNL)

Object Graph Navigation Library は、Apache Foundation が開発したオープンソース言語です。Java オブジェクトプロパティーを取得するための式言語です。JBoss Enterprise SOA Platform は、指定のパラメーターマップから SOAP メッセージに注入される SOAP パラメーターの値を選択するために使用されるメカニズムとして使用します。SOAP メッセージ内の特定のパラメーターの OGNL 式は、SOAP ボディー内のパラメーターの位置によって異なります。

13.9.7. Object Graph Navigation ライブラリーの使用

以下のメッセージでは、customerOrder.header.customerNumber パラメーターを表す OGNL 式は customerOrder.header.customerNumber です。
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:cus="http://schemas.acme.com">
    <soapenv:Header/>
    <soapenv:Body>
    
        <cus:customerOrder>
            <cus:header>
                <cus:customerNumber>123456</cus:customerNumber>
            </cus:header>
        </cus:customerOrder>
        
    </soapenv:Body>
</soapenv:Envelope>
OGNL 式がパラメーターに対して計算されると、このクラスは、提供されたパラメーターマップで、完全な OGNL 式(上記のオプション 1)から指定されたオブジェクトキーをチェックします。そのようなパラメーターオブジェクトがマップに存在しない場合は、このクラスはマップおよび OGNL 式インスタンスを OGNL ツールキットに指定して、パラメーターの読み込みを試みます。これによって値が得られない場合、SOAP メッセージ内のこのパラメーターの場所は空白になります。
上記のサンプルメッセージを取り、customerNumber を入力するには、オブジェクトインスタンス(たとえば、Order オブジェクトインスタンス)をキー customerOrder キー下のパラメーターマップに設定する必要があります。"customerOrder" オブジェクトインスタンスにはヘッダープロパティー(たとえば、Header オブジェクトインスタンス)を含める必要があります。header プロパティーの背後にあるオブジェクトインスタンス(たとえば、Header オブジェクトインスタンス)には customerNumber プロパティーが必要です。
コレクションに関連付けられた OGNL 式は、若干異なる方法で構築されます。
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:cus="http://schemas.active-endpoints.com/sample/customerorder/2006/04/CustomerOrder.xsd"
    xmlns:stan="http://schemas.active-endpoints.com/sample/standardtypes/2006/04/StandardTypes.xsd">

    <soapenv:Header/>
    <soapenv:Body>
        <cus:customerOrder>
            <cus:items>
                <cus:item>
                    <cus:partNumber>FLT16100</cus:partNumber>
                    <cus:description>Flat 16 feet 100 count</cus:description>
                    <cus:quantity>50</cus:quantity>
                    <cus:price>490.00</cus:price>
                    <cus:extensionAmount>24500.00</cus:extensionAmount>
                </cus:item>
                <cus:item>
                    <cus:partNumber>RND08065</cus:partNumber>
                    <cus:description>Round 8 feet 65 count</cus:description>
                    <cus:quantity>9</cus:quantity>
                    <cus:price>178.00</cus:price>
                    <cus:extensionAmount>7852.00</cus:extensionAmount>
                </cus:item>
            </cus:items>
        </cus:customerOrder>
    </soapenv:Body>
    
</soapenv:Envelope>
上記の注文メッセージには、注文の項目のコレクションが含まれています。コレクションの各エントリーは、item 要素で表されます。注文アイテム "partNumber" の OGNL 式は、customerOrder.items[0].partnumber および "customerOrder.items[1].partnumber" として構築されます。これから分かるように、コレクションエントリー要素(item 要素)は OGNL 式で明示的な表示を行いません。これは、インデックス表記によって暗黙的に表されます。オブジェクトグラフの観点では、これは、リストエントリーが "OrderItem" インスタンスである "items" リストまたは配列を含む注文オブジェクトインスタンス(マップ上でキーが customerOrder として指定)で表現できます。これには、partNumber およびその他のプロパティーが含まれます。
構築および設定される SOAP メッセージテンプレートを表示するには、dumpSOAP パラメーターをパラメーターマップに追加します。
警告
これは非常に便利な開発者である可能性がありますが、開発の外に置かないでください。

13.9.8. SOAP 操作パラメーター

SOAP 操作パラメーターは、以下の 2 つの方法のいずれかで提供されます。
  • デフォルトのボディーの場所に設定されるマップインスタンスとして (Message.getBody().add(Map))
  • 名前付きボディーの場所 (Message.getBody().add(String, Map)) に設定されたマップインスタンスとして、その本文の場所の名前は "paramsLocation" アクションプロパティーの値として指定します。
パラメーターマップ自体は、次の 2 つの方法のいずれかで入力することもできます。
  1. 任意のタイプのオブジェクトセットを使用します。この場合、Smooks 設定をアクション属性 SmooksRequestMapper で指定し、Smooks を使用して Java から Java への変換を行う必要があります。
  2. 文字列ベースのキーと値のペア(<String, Object>)のセットでは、キーは、キーの値で設定される wsdl (または生成されたクラス)で指定される SOAP パラメーターの名前です。SOAP 応答メッセージ消費
SOAP 応答オブジェクトインスタンスは、以下のいずれかの方法でメッセージに割り当てることができます。
  • デフォルトの本文の場所(Message.getBody ().add (Map))
  • on は、名前付きボディーの場所(Message.getBody ().add (String, Map))で、ボディーの場所の名前は responseLocation アクションプロパティーの値として指定します。
応答オブジェクトインスタンスは、以下のいずれかの方法で(SOAP 応答から)入力することもできます。
  1. 任意のタイプのオブジェクトセットに置き換えます。この場合、Smooks 設定はアクション属性 SmooksResponseMapper で指定し、Smooks を使用して Java から Java への変換を行う必要があります。
  2. String ベースのキーと値のペア(<String, Object>)のセットでは、キーは、キーの値で設定される wsdl (または生成されたクラス)で指定される SOAP 応答の名前です。SOAP リクエスト/応答の JAX-WS ハンドラー
SOAPClient の使用例は、以下のクイックスタートを参照してください。
  • webservice_consumer_wise は、基本的な使用方法を表示します。
  • webservice_consumer_wise2 は、'SmooksRequestMapper' および 'SmooksResponseMapper' を使用する方法を示しています。
  • webservice_consumer_wise3 は、'smooks-handler-config' の使用方法を示しています。
  • webservice_consomer_wise4 は、'custom-handlers' の使用を示しています。

13.9.9. SOAPClient アクションのエンドポイント操作の指定

手順13.3 タスク

  • SOAPClient アクションで wsdl プロパティーおよび "operation" プロパティーを指定します。
    <action name="soapui-client-action" class="org.jboss.soa.esb.actions.soap.SOAPClient">
        <property name="wsdl" value="http://localhost:18080/acme/services/RetailerCallback?wsdl"/>
        <property name="operation" value="SendSalesOrderNotification"/>
    </action>

13.9.10. SOAP 応答メッセージの処理

SOAP 応答オブジェクトインスタンスは、以下のいずれかの方法で Message インスタンスに割り当てることができます。
  1. デフォルトの本文の場所(Message.getBody ().add (Map))
  2. 名前付きボディーの場所(Message.getBody ().add (String, Map))では、その本文の場所の名前が set-payload-location アクションプロパティーの値として指定します。
応答オブジェクトインスタンスは、以下の 3 つの方法のいずれかで(SOAP 応答から)入力できます。
  1. XStream ツールキットが作成して入力する Object Graph として。また、JAXB および JAXB アノテーションのIntroductionsを使用して応答をアンマーシャリングするためのサポートを追加する予定です。
  2. String ベースのキーと値のペア(<String, String>)のセットとして、キーは SOAP 応答要素を識別する OGNL 式で、value は SOAP メッセージからの値を表す String です。
  3. Options 1 または 2 がアクション設定で指定されていない場合、raw SOAP 応答メッセージ(文字列)がメッセージに割り当てられます。

13.9.11. XStream を使用したオブジェクトグラフの設定

手順13.4 タスク

  1. アクションに XStream を設定します。
    <action name="soapui-client-action"  class="org.jboss.soa.esb.actions.soap.SOAPClient">
        <property name="wsdl"  value="http://localhost:18080/acme/services/RetailerService?wsdl"/>
        <property name="operation" value="GetOrder"/>
        <property name="get-payload-location" value="get-order-params" />
        <property name="set-payload-location" value="get-order-response" />
        <property name="responseXStreamConfig">
            <alias name="customerOrder" class="com.acme.order.Order"         
                namespace="http://schemas.acme.com/services/CustomerOrder.xsd" />
            <alias name="orderheader" class="com.acme.order.Header" 
                namespace="http://schemas.acme.com/services/CustomerOrder.xsd" />
            <alias name="item" class="com.acme.order.OrderItem" 
                namespace="http://schemas.acme.com/services/CustomerOrder.xsd" />
        </property>
    </action>
    上記の例では、要求パラメーター Map および応答オブジェクトインスタンスにデフォルト以外の名前付きの場所を指定する方法の例もあります。
  2. フィールド名マッピングと XStream アノテーションが付けられたクラスを指定します。
    <property name="responseXStreamConfig">
        <fieldAlias name="header" class="com.acme.order.Order" fieldName="headerFieldName" />
        <annotation class="com.acme.order.Order" />
    </property>
    フィールドマッピングは、要素のローカル名が Java クラスのフィールド名に対応していない場合に、XML 要素を occasions の Java フィールドにマップするために使用できます。

13.9.12. SOAP 応答データを OGNL キー化されたマップに抽出します。

手順13.5 タスク

  • responseXStreamConfig プロパティーを responseAsOgnlMap プロパティーに置き換えます。
    <action name="soapui-client-action" class="org.jboss.soa.esb.actions.soap.SOAPClient">
        <property name="wsdl" value="http://localhost:18080/acme/services/RetailerService?wsdl"/>
        <property name="operation" value="GetOrder"/>
        <property name="get-payload-location" value="get-order-params" />
        <property name="set-payload-location" value="get-order-response" />
        <property name="responseAsOgnlMap" value="true" />
    </action>
    注記
    raw SOAP メッセージを文字列として返すには、responseXStreamConfig および responseAsOgnlMap プロパティーの両方を省略します。

13.9.13. HttpClient

HttpClient は、Apache Foundation によって作成されたオープンソースライブラリーです。最新の標準および推奨事項に準拠する HTTP クライアントを実装することを目的としています。JBoss Enterprise SOA Platform の SOAPClient は HttpClient を使用して SOAP 要求を実行します。SOAPClient は HttpClientFactory を使用して HttpClient インスタンスを作成および設定します。

13.9.14. HttpClient の設定

プロパティーのセットを指定して HttpClient を設定します。設定ファイルの例を以下に示します。
  • EasySSLProtocolSocketFactory を使用して、ターゲットサーバーが自己署名証明書で認証できるようにする SSL 接続を作成できます。
  • StrictSSLProtocolSocketFactory を使用して、中間者タイプの攻撃を防ぐのに役立つ、ホスト名の検証をオプションで実行できる SSL 接続を作成できます。
  • AuthSSLProtocolSocketFactory を使用すると、任意で相互クライアント/サーバー認証を適用できます。これは、プロトコルソケットファクトリーの最も柔軟な実装です。これにより、SSL 認証のほとんど(すべてでない場合)をカスタマイズできます。
HttpClientFactory が必要とする唯一のプロパティーは configurators で、configurator 実装のコンマ区切りリストを指定します。各 configurator 実装は HttpClient インスタンスのさまざまな側面を設定し、org.jboss.soa.esb.http.Configurator クラスを拡張し、configure(HttpClient, Properties) メソッドを提供します。

表13.31 追加設定なしの実装

Configurator Description 必須
HttpProtocol
ソケットファクトリーや SSL キーストア情報など、HttpClient ホスト、ポート、およびプロトコル情報を設定します。
はい
AuthBasic
HttpClient の HTTP Basic 認証を設定します。
いいえ
AuthNTLM
HttpClient の NTLM 認証を設定します。
いいえ
追加の configurator は、configurators プロパティーで指定されたリストにクラス名を追加して設定できます。
HTTP トランスポートプロパティーの設定:

表13.32 プロパティー

プロパティー Description 必須
HttpProtocol
ソケットファクトリーや SSL キーストア情報など、HttpClient ホスト、ポート、およびプロトコル情報を設定します。
はい
target-host-url
http/https エンドポイントのターゲット URL
はい
https.proxyHost
https 接続のプロキシーホスト
いいえ
https.proxyPort
https 接続のプロキシーポート。デフォルトはポート 443 です。
いいえ
http.proxyHost
http 接続のプロキシーホスト
いいえ
http.proxyPort
http 接続のプロキシーポート。デフォルトはポート 80 です。
いいえ
protocol-socket-factory
ProtocolSocketFactory または ProtocolSocketFactoryBuilder インターフェイスを実装するソケットファクトリーを上書きします。
http のデフォルト値は httpclient DefaultProtocolSocketFactory で、https のデフォルト値は提供した StrictSSLProtocolSocketFactory です。
AuthSSLProtocolSocketFactory ファクトリーと自己署名 SSLContext をそれぞれ設定するために、Answ コードベース AuthSSL ProtocolSocketFactoryBuilder および SelfSignedSSLProtocolSocketFactoryBuilder には、ProtocolSocketFactoryBuilder の実装が 2 つあります。
いいえ
keystore
キーストアの場所
いいえ
keystore-passw
キーストアパスワードまたは暗号化されたファイル
いいえ
keystore-type
キーストアタイプ。デフォルトは jks です。
いいえ
truststore
トラストストアの場所
いいえ
truststore-passw
トラストストアパスワードまたは暗号化されたファイル
いいえ
truststore-type
トラストストアタイプ。デフォルトは jks です。
いいえ
HTTP Basic 認証プロパティーの設定:

表13.33 プロパティー

プロパティー Description 必須
auth-username
認証ユーザー名
はい
auth-password
認証パスワード
はい
authscope-host
認証スコープホスト
はい
authscope-port
認証スコープポート
はい
authscope-domain
認証スコープドメイン
はい
HTTP Basic 認証 NTLM プロパティーの設定:

表13.34 プロパティー

プロパティー Description 必須
ntauth-username
認証ユーザー名
はい
ntauth-password
認証パスワード
はい
ntauthscope-host
認証スコープホスト
はい
ntauthscope-port
認証スコープポート
はい
ntauthscope-domain
認証スコープドメイン
はい
ntauthscope-realm
認証スコープのレルム
いいえ

13.9.15. SOAPClient での HttpClientFactory 設定の指定

手順13.6 タスク

  • wsdl プロパティーにその他のプロパティーを追加します。
    <property name="wsdl" value="https://localhost:18443/active-bpel/services/RetailerCallback?wsdl">
        <http-client-property name="file" value="/localhost-https-18443.properties" >
        
        </http-client-property>
    </property>
    注記
    file プロパティーの値は、ファイルシステム、クラスパス、または URI ベースのリソース(その順序で)として評価されます。このリソースには、標準の Java プロパティー形式の HttpClient 設定が含まれます。

13.9.16. アクション設定での HttpClient の直接設定

手順13.7 タスク

  • プロパティーをアクション設定に直接設定します。
    <property name="http-client-properties"> 
        <http-client-property name="http.proxyHost" value="localhost"/>
        <http-client-property name="http.proxyPort" value="8080"/> 
    </property>

13.9.17. SOAPProxy

SOAPProxy は、外部 Web サービスエンドポイントを消費するアクションです。また、Enterprise Service Bus を介して Web サービスエンドポイントを再公開することもできます。外部サービスと ESB の間に位置するこの仲介者の目的は、次の機能を提供する抽象化レイヤーを提供することです。
  • これにより、クライアントとサービスの間の疎結合が促進されます (両者はお互いをまったく認識していないため)。
  • これは、クライアントがリモートサービスのホスト名/IP アドレスに直接接続できなくなったことを意味します。
  • クライアントは、インバウンド/アウトバウンドパラメーターを変更する変更された WSDL を確認します。少なくとも、現在プロキシーされている元のエンドポイントではなく、ESB の公開されたエンドポイントをクライアントが指すように WSDL を微調整する必要があります。
  • インバウンド要求とアウトバウンド応答の両方について、アクションパイプラインを介して SOAP エンベロープ/ボディの変換を導入できます。
  • クライアントはエンタープライズサービスバス上の 2 つ以上のプロキシーエンドポイントに接続でき、それぞれに独自の WSDL や変換、ルーティング要件があり、ESB が適切なメッセージを適切なエンドポイントに送信し、究極の対応。
  • ContentBasedRouter を介した複雑なコンテキストベースのルーティングが可能になります。

13.9.18. SOAPProxy アクションの使用

SOAPProxy アクションは以下のとおりです。
  • プロデューサーと Web サービスのコンシューマーの両方。
  • 必要なのは、外部 wsdl を指すプロパティーのみです。
  • WSDL を自動的に変換できるようにする方法(オプションの wsdlTransform プロパティーを使用)。
  • SOAP が HTTP に関連付けられないようにする方法。WSDL は読み取られ、HTTP トランスポートが定義されている場合は使用されます。
  • HTTP を使用している場合は、任意で HttpRouter プロパティーをオーバーライドとして適用する方法。
WSDL が HTTP トランスポートを指定する場合、HttpRouter プロパティーのいずれかを適用できます。

表13.35

プロパティー Description 必須
wsdlTransform
柔軟な wsdl 変換を可能にする <smooks-resource-list> xml 設定ファイル。
いいえ
wsdlCharset
元の wsdl (およびインポートされたリソース)の文字セットは UTF-8 でエンコードされます。基礎となるプラットフォームでサポートされているエンコーディングの場合、UTF-8 に変換されます。
いいえ
endpointUrl
HttpRouter プロパティーの例。SSL 証明書でドメイン名の照合が重要な場合に役立ちます。
いいえ
file
Apache Commons HTTPClient プロパティーファイル。SSL 経由で Web サービスにプロキシーする場合に便利です。
いいえ
clientCredentialsRequired
Basic 認証クレデンシャルがエンドクライアントから送信されるか、またはファイル内に指定された認証情報が代わりに使用できるかどうか。(デフォルトは True)
いいえ
wsdl
WS エンドポイントが再作成され、新しい wsdl として公開される元の wsdl url。<definitions><service><port><soap:address の場所属性のプロトコル(http など)に応じて、プロトコル固有の SOAPProxyTransport 実装が使用されます。
値は、5 つの異なるスキームに基づいて場所を参照できます。
  • http://
    外部 Web サーバーから wsdl をプルする場合。
    例:http://host/foo/HelloWorldWS?wsdl
  • https://
    SSL 経由で外部 Web サーバーから wsdl をプルする場合。
    例:https://host/foo/HelloWorldWS?wsdl
  • file://
    wsdl がディスクに置かれ、JECT JVM からアクセスできる場合。
    例:file:///tmp/HelloWorldWS.wsdl
    注記:上記の例では 3 つのスラッシュを指定します。これは、絶対パスと相対パスを指定できるようにするためです。
  • classpath://
    wsdl アーカイブ内で wsdl をパッケージ化する場合。
    Example: classpath:///META-INF/HelloWorldWS.wsdl
    上記の例の 3 つのスラッシュに注意してください。これは、絶対的なクラ出力ダーリソースパスと相対クラ出力ダーのリソースパスを指定することができるようにします。
  • internal://
    wsdl が、このレベルでのデプロイメントと同じ JVM 内の JBossWS Web サービスによって提供される場合。
    Example: internal://jboss.ws:context=foo,endpoint=HelloWorldWS
    注記
    このスキームは、上記の用途では http または https の代わりに使用する必要があります。これは、サーバーの再起動時に、Tomcat がまだ受信 http/s 要求を受け入れていない可能性があるため、wsdl に対応できないためです。
はい

例13.16 サンプル設定:基本的なシナリオ

<action name="proxy" class="org.jboss.soa.esb.actions.soap.proxy.SOAPProxy">
    <property name="wsdl" value="http://host/foo/HelloWorldWS?wsdl"/>
</action>

例13.17 設定例:Basic 認証および SSL

<action name="proxy" class="org.jboss.soa.esb.actions.soap.proxy.SOAPProxy">
    <property name="wsdl" value="https://host/foo/HelloWorldWS?wsdl"/>
    <property name="endpointUrl" value="https://host/foo/HelloWorldWS"/>
    <property name="file" value="/META-INF/httpclient-8443.properties"/>
    <property name="clientCredentialsRequired" value="true"/>
</action>

13.10. その他のアクション

13.10.1. SystemPrintln

SystemPrintln は、メッセージの内容を出力するための簡単なアクションです(例: System.out.printlnメッセージの内容を XML としてフォーマットします。

13.10.2. SystemPrintln の使用

入力タイプ java.lang.String
Class org.jboss.soa.esb.actions.SystemPrintln
プロパティー
  • message : メッセージの接頭辞。必須
  • printfull : true の場合、メッセージ全体が出力されます。それ以外の場合はバイトアレイおよび添付ファイルのみが出力されます。
  • outputstream - true の場合、System.out が使用されます。それ以外の場合は System.err が使用されます。
<action name="action2" class="org.jboss.soa.esb.actions.ServiceLoggerAction">
   <property name="text" value="Message arrived"/>
   <property name="log-payload-location" value="true"/>
</action>

13.10.3. SchemaValidationAction

SchemaValidationAction は、XML メッセージのスキーマベースの検証を実行するための簡単なアクションです。

13.10.4. SchemaValidationAction の使用

入力タイプ java.lang.String
Class org.jboss.soa.esb.actions.validation.SchemaValidationAction
プロパティー
  • schema : 検証スキーマファイルのクラスパスパス(例:.xsd)。
  • schemaLanguage : (任意) スキーマのタイプ/言語。Default: "http://www.w3.org/2001/XMLSchema" i.e. XSD.
<action name="val"  class="org.jboss.soa.esb.actions.validation.SchemaValidationAction">
    <property name="schema" value="/com/acme/validation/order.xsd"/>
</action>

13.10.5. ServiceLoggerAction

ServiceLoggerAction は、"<service-category>.<service-name<" アペンダーを使用してカスタムテキストとメッセージをロガーに記録する簡単なアクションです。このアクションは、アクションごとにではなく、サービスごとに LogLevelAction を設定でき、カスタムテキストをログに記録できる点で LogAction とは異なります。

13.10.6. ServiceLoggerAction の使用

  • Debug level 設定を使用すると、メッセージが出力されます。
  • トレースレベル設定を使用すると、メッセージペイロードの出力になります。
入力タイプ java.lang.String
Class org.jboss.soa.esb.actions.ServiceLoggerAction
プロパティー
  • text : メッセージの接頭辞。必須
  • get-payload-location - true または False の値。ペイロードの場所をトレースに記録すべきかどうかを指定します。
<action name="servicelogger"  class="org.jboss.soa.esb.actions.ServiceLoggerAction">
    <property name="text" value="Reached here"/><br/>
    <property name="get-payload-location" value="true"/>
</action>
注記
<property> テキストは必要ありません。省略すると、<category>.<service> が代わりに出力されます。

第14章 独自のアクションの開発

14.1. カスタムアクションの開発

独自のアクションは以下のいずれかの方法で開発できます。各アクションには独自の長所と短所があります。
  • org.jboss.soa.esb.actions.ActionLifecycle または org.jboss.soa.esb.actions.ActionPipelineProcessorを実装するライフサイクルアクション
  • org.jboss.soa.esb.actions.BeanConfiguredActionを実装する Java Bean アクション
  • アノテーション付きアクション
  • レガシーアクション
各実装の違いを理解するには、以下を理解する必要があります。
  • アクションの設定方法
  • アクションがインスタンス化され、スレッドの安全性に影響を与える可能性があります。
  • ライフサイクルイベントの可視性があるかどうか
  • アクションメソッドが直接的またはリフレクションを介して呼び出されるかどうか。

14.2. プロパティーを設定してアクションを設定する

アクションは通常テンプレートとして機能し、タスクを実行するために外部設定が必要になります。たとえば、PrintMessage アクションは、message という名前のプロパティーを使用して出力する内容を示し、repeatCount という別のプロパティーを使用して出力する回数を示します。その場合、jboss-esb.xml ファイルのアクション設定は以下のようになります。
<action name="PrintAMessage" class="test.PrintMessage">
 <property name="information" value="Hello World!" />
 <property name="repeatCount" value="5" />
</action>
この設定がどのようにアクションインスタンスにマッピングされるかは、アクションのタイプによって異なります。

14.3. 反映

Java を使用する場合は、リフレクション 方法を使用してランタイム内のオブジェクトを検査および変更できます。これは、スクリプト内の用語の検索、スクリプトの一部の追加および変更、およびアプリケーションの呼び出しを支援するためにコードに追加できます。ランタイム時にサービスおよびアプリケーションを呼び出すために使用できます。これは、何かを効率的に変更できない、または変更する必要がないフィールドの名前を見つける必要がある場合に役立ちます。
注記
リフレクション方法を使用するとロード時間が遅くなりますが、これらのタスクを手動で実行する方が良いことがあります。

14.4. 管理ライフサイクル

この用語は、最初から最後まで、プロセスのすべての側面を制御できることです。この種の制御には、さまざまな方法があります。管理 Bean とサービスの両方が、プロセスのライフサイクルを管理するために使用できます。これにより、オブジェクトのライフサイクルの各段階で変更を加えることができます。

14.5. ライフサイクルアクション

ライフサイクルアクションは、ライフサイクルインターフェイス org.jboss.soa.esb.actions.ActionLifecycle および org.jboss.soa.esb.actions.ActionPipelineProcessor から派生するアクションです。

14.6. ActionLifecycle

ActionLifecycle は、initialise および destroy アクションパイプラインのライフサイクルメソッドを実装するインターフェイスです。

14.7. ActionPipelineProcessor

ActionPipelineProcessor は ActionLifecycle インターフェイスを拡張するインターフェイスであり、processprocessSuccess、および processException メッセージ処理メソッドを利用できます。
このインターフェイスは、管理対象のライフサイクルステートレスアクションの実装をサポートします。

14.8. ActionLifecycle および ActionPipelineProcessor の実装

ActionLifecycle または ActionPipelineProcessor インターフェイスのいずれかを実装するクラスの単一インスタンスは、パイプラインごとにインスタンス化され(アクションごとの設定)、スレッドセーフである必要があります。initialise および destroy メソッドを上書きし、アクションがパイプラインの存続期間中リソース管理を実行できるようにすることができます。(例: initialise メソッドで必要なキャッシュリソースで、destroy メソッドでクリーンアップします。)
これらのアクションは、単一の ConfigTree インスタンスをパラメーターとして取るコンストラクターを定義する必要があります。これは、パイプライン内の特定のアクションの設定を表します。
このパイプラインは、アクションが適切なインターフェイスを実装し、メソッド名が設定で上書きされないようにすることで、各メソッドを直接呼び出します。インターフェイスを介して実装されないメソッド呼び出し、またはアクション設定で上書きされたメソッド呼び出しは、リフレクションを使用して呼び出されます。
開発を簡素化するために、コードベースには 2 つの抽象ベースクラスが提供され、それぞれ適切なインターフェイスを実装し、process メソッド以外のすべてのスタブメソッドを提供します。これらは org.jboss.soa.esb.actions.AbstractActionPipelineProcessor および org.jboss.soa.esb.actions.AbstractActionLifecycle です。以下のように使用します。
public class ActionXXXProcessor extends AbstractActionPipelineProcessor {
  public ActionXXXProcessor(final ConfigTree config) {
    // extract configuration
  }
  
  public void initialise() throws ActionLifecycleException {
    // Initialize resources...
  }
  
  public Message process(final Message message) throws ActionProcessingException {
    // Process messages in a stateless fashion...
  }

  public void destroy() throws ActionLifecycleException {
    // Cleanup resources...
  }
}

14.9. Java Bean アクション

Java Bean Action は、セッターを使用してプロパティーが設定されるアクションです。これらのセッターはプロパティー名に対応します。フレームワークは自動的に設定します。

14.10. Java Bean アクションの設定

アクション Bean を自動的に入力するには、Java Bean Action クラスは org.jboss.soa.esb.actions.BeanConfiguredAction マーカーインターフェイスを実装する必要があります。コードの例を以下に示します。
import org.jboss.soa.esb.message.Message;
import org.jboss.soa.esb.actions.BeanConfiguredAction;

public class PrintMessage implements BeanConfiguredAction {
  private String information;
  private Integer repeatCount;
  public void setInformation(String information) {
    this.information = information;
  }
  public void setRepeatCount(Integer repeatCount) {
    this.repeatCount = repeatCount;
  }
  public Message process(Message message) {
    for (int i=0; i < repeatCount; i++) {
      System.out.println(information);
    }
    return message;
  }
}
注記
setRepeatCount() メソッドの Integer パラメーターは、XML で指定された String 表現から自動的に変換されます。
プロパティーをロードする BeanConfiguredAction メソッドは、簡単な引数を取るアクションに適していますが、ConfigTree メソッドは XML 表現を直接処理する必要がある場合に適しています。
重要
これらのアクション は、ライフサイクルメソッドをサポートしません。代わりに、アクションパイプラインを通過する すべての メッセージに対してインスタンス化され、常にリフレクションを使用して process メソッドが呼び出されます。

14.11. アノテーション付きアクション

アノテーションが付けられたアクションクラスは、クリーンな実装の作成を容易にするアノテーションを持つアクションクラスです。インターフェイスの実装、抽象クラス、および ConfigTree の処理に関連する複雑性が非表示になります。アノテーションが付けられたアクションの単一インスタンスは、パイプラインごとにインスタンス化され(つまり、アクションごとの設定)、スレッドセーフである必要があります。パイプラインは、常にリフレクションを使用して action メソッドを呼び出します。

14.12. アノテーションの使用

以下は、アクションクラスに追加できるアノテーションです。
@Process
最も単純な実装では、@Process アノテーションが付けられた 1 つのメソッドを持つ基本的な プレーンな古い Java オブジェクト (POJO)でアクションを作成します。
public class MyLogAction {

                @Process
 		    public void log(Message message) {
		        // log the message...
		    }
		}
@Process アノテーションは、クラスを有効な アクション として識別します。  クラスに複数のメソッドがある場合は、メッセージインスタンス(またはメッセージの一部)の処理に使用される メソッドも特定します。@BodyParam、@PropertyParam、および @AttachmentParam アノテーションの説明については、より詳細な説明があります。)
この アクション のインスタンスを パイプライン に設定するには、低/ベースレベルの アクション の実装と同じプロセスを使用します( AbstractActionPipelineProcessor を拡張するか、ActionLifecycle、または他のサブタイプまたは抽象実装のいずれかを実装するもの)。
<service .....>
		    <actions>
		        <action name="logger" class="com.acme.actions.MyLogAction" />
		    </actions>
		</service>
@Process アノテーションが付けられた複数のメソッドが アクション 実装に関連付けられている場合は、process 属性を使用して、メッセージインスタンスの処理に使用するメソッドを指定します。
<service .....>
		    <actions>
		        <action name="logger" class="com.acme.actions.MyLogAction" 
                                           process="log" />
		    </actions>
		</service>
@process メソッドを実装して以下を返すことができます。
  • void。これは、上記のロガーアクションの実装と同様に戻り値がないことを意味します。
  • Message: これはメッセージインスタンスです。  これは、アクションパイプラインのアクティブ/現在のインスタンスになります。
  • 別のタイプ。  メソッドがメッセージインスタンスを返さない場合、返されるオブジェクトインスタンスはアクションパイプラインの現在のメッセージインスタンスに設定されます。  メッセージに設定する場所は、set-payload-location<action> 設定プロパティーによって異なります。これは、通常の MessagePayloadProxy ルールに従ってデフォルトです。
@Process メソッドを使用して、さまざまな方法でパラメーターを指定します。これにより、以下が可能になります。
  1. メッセージインスタンスをメソッドパラメーターとして指定します。
  2. 任意のパラメータータイプを 1 つ以上指定します。  Enterprise Service Bus フレームワークは、アクティブ/現在のパイプラインメッセージインスタンスでそのタイプのデータを検索します。最初に、メッセージボディー、プロパティー、添付ファイルの順に検索し、このデータをそれらのパラメーターの値として渡します (または見つからない場合は null)。
最初のオプションの例は、ロガーアクションの上述されています。  2 番目のオプションの例を以下に示します。
public class OrderPersister {

		    @Process
		    public OrderAck storeOrder(OrderHeader orderHeader,
								OrderItems orderItems) {
		        // process the order parameters and return an ack...
		    }
		}
この例では、@Process メソッドは パイプライン の以前のアクションに依存して OrderHeader および OrderItem オブジェクトインスタンスを作成し、それらを現在のメッセージに割り当てます。  (おそらく、より現実的な実装では、XML または EDI ペイロードを注文インスタンスにデコードする一般的なアクション実装があり、その後に返されます。 OrderPersister は注文インスタンスを唯一のパラメーターとして取ります。 以下に例を示します。
public class OrderDecoder {

		    @Process
		    public Order decodeOrder(String orderXML) {
		        // decode the order XML to an ORder instance... 
		    }
		}

		public class OrderPersister {

		    @Process
		    public OrderAck storeOrder(Order order) {
		        // persist the order and return an ack...
		    }
		}
サービス設定で 2 つのアクションをチェーンします。
<actions>
    <action name="decode" class="com.acme.orders.OrderDecoder" />
    <action name="persist" class="com.acme.orders.OrderPersister" />
</actions>
このコードは、アノテーションが少ないため、オプション #2 で読み取るのが簡単になりますが、適切なパラメーター値のメッセージを介してランタイムのhunting のプロセスが完全に確定されないため、リスクが発生し ます。  このため、Red Hat は @BodyParam、@PropertyParam、および @AttachmentParam アノテーションをサポートします。
これらの @Process メソッドパラメーターアノテーションを使用して、メッセージのどこから @Process メソッドの個別のパラメーター値を取得するかを明示的に定義します。その名前が示すように、これらの各アノテーションを使用すると、特定のパラメーターの名前付きの場所 (メッセージボディー、プロパティー、または添付ファイル内) を指定できます。
public class OrderPersister {

  		    @Process
		    public OrderAck storeOrder(
		                   @BodyParam("order-header") OrderHeader orderHeader,
		                   @BodyParam("order-items") OrderItems orderItems) {
			
		        // process the order parameters and return an ack...
		    }
		}
指定したメッセージの場所に値が含まれていない場合は、このパラメーターに null を渡します(@Process メソッドインスタンスはこれの処理方法を決定できます)。一方、指定した場所に誤ったタイプの値が含まれる場合、 MessageDeliverException が出力されます。
@ConfigProperty
ほとんどのアクションには、ある程度のカスタム設定が必要です。  Na アクション設定では、プロパティーは <action> 要素の <property> サブ要素として提供されます。
<action name="logger" class="com.acme.actions.MyLogAction">
    <property name="logFile" value="logs/my-log.log" />
    <property name="logLevel" value="DEBUG" />
</action>
これらのプロパティーを使用するには、低/ベースレベルのアクション実装を使用します( AbstractActionPipelineProcessor を拡張するか、ActionLifecycleを実装してください)。これには、ConfigTree クラス(コンストラクターを介してアクションに提供される)の使用が関係します。アクションを実装するには、以下の手順に従います。
  1. ConfigTree インスタンスを提供するアクションクラスでコンストラクターを定義します。
  2. ConfigTree インスタンスから関連するアクション設定プロパティーをすべて取得します。
  3. 必須のアクションプロパティーの有無を確認し、<action> 設定で指定されていない場所で例外を発生させます。
  4. すべてのプロパティー値を文字列( ConfigTreeで指定)からアクション実装で使用される適切なタイプにデコードします。たとえば、java.lang.String から java.io.Filejava.lang.String をブール値に、java.lang.String を long などに決定します。
  5. 設定した値をターゲットプロパティータイプにデコードできない場所で例外を発生させます。
  6. 複数の異なる設定の可能性に ユニットテスト を実装し、上記のタスクが適切に完了していることを確認します。
上記のタスクは一般的に簡単ですが、面倒でエラーが発生しやすく、設定ミスの処理方法に関してアクション間で不整合が発生する可能性があります。  多くのコードを追加して、混乱が発生する場合もあります。
アノテーションが付けられたアクションは、@ConfigProperty を介してこれらの問題に対処します。MyLogActions 実装を展開します。これには、logFilelogLevel の 2 つの必須の設定プロパティーがあります。
public class MyLogAction {

		    @ConfigProperty
		    private File logFile;

		    @ConfigProperty
		    private LogLevel logLevel;
 
		    public static enum LogLevel {
		        DEBUG, 
		        INFO, 
		        WARN
		    }

		    @Process
		    public void log(Message message) {
		        // log the message at the configured log level...
		    }
		}
注記
@ConfigProperty アノテーションを "setter" メソッドで定義することもできます(フィールドの ではなく)。
これはすべて完了する必要があります。Enterprise Service Bus がアクションをデプロイすると、実装とデコードされた値内のマップの両方を検証します(上記の LogLevel enum の場合のように列挙のサポートを含む)。@ConfigProperty アノテーションを持つアクションフィールドを見つけます。開発者は、ConfigTree クラスをまったく処理したり、追加のコードを開発したりする必要はありません。
デフォルトでは、@ConfigProperty アノテーションを持つすべてのクラスフィールドは必須です。  必須ではないフィールドは、以下の 2 つの方法のいずれかで処理されます。
  1. フィールドの @ConfigProperty アノテーションに use = Use.OPTIONAL を指定します。
  2. フィールドの @ConfigProperty アノテーションに defaultVal を指定します。(これはオプションです。)
ログアクションのプロパティーのみをオプションにするには、以下のようなアクションを実装します。
public class MyLogAction {
		
		    @ConfigProperty(defaultVal = "logs/my-log.log")
		    private File logFile;

		    @ConfigProperty(use = Use.OPTIONAL)
		    private LogLevel logLevel;

		    public static enum LogLevel {
		        DEBUG, 
		        INFO, 
		        WARN
		    }

		    @Process
		    public void log(Message message) {
		        // log the message...
		    }
		}
@ConfigProperty アノテーションは、2 つの追加フィールドをサポートします。
  1. name: アクションインスタンスでその名前のフィールドを入力するために使用されるアクション設定プロパティーの名前を明示的に指定します。
  2. choice: このフィールドを使用して、それ自体に許可される設定値を制限します。  これは、( LogLevelのように)列挙型を使用して実行することもできます。
name フィールドは、古いアクション(低/ベースレベル実装タイプを使用する)を新しいアノテーションベースの実装に移行する場合など、さまざまな状況で使用される場合があります。これは、プロパティーの古い設定名(後方互換性のために変更できない)が有効な Java フィールド名にマップされないことのみとなります。ログアクションを例として取り込むと、これがログアクションの古い設定であったとします。
<action ...>
		    <property name="log-file" value="logs/my-log.log" />
		    <property name="log-level" value="DEBUG" />
		</action>
ここでのプロパティー名は有効な Java フィールド名にマッピングされないため、@ConfigProperty アノテーションの名前を指定します。
public class MyLogAction {
		
		    @ConfigProperty(name = "log-file")
		    private File logFile;

		    @ConfigProperty(name = "log-level")
		    private LogLevel logLevel;

		    public static enum LogLevel {
		        DEBUG, 
		        INFO, 
		        WARN
		    }

		    @Process
		    public void log(Message message) {
		        // log the message...
		    }
		}
Bean 設定のプロパティー値は文字列の値からデコードされます。適切な POJO Bean プロパティータイプと照合するには、以下の単純なルールが使用されます。
  1. プロパティータイプに単一引数の文字列コンストラクターがある場合は、それを使用します。
  2. Pimitive の場合は、オブジェクトタイプの単一引数の文字列コンストラクターを使用します。たとえば、int の場合は、Integer オブジェクトを使用します。
  3. 列挙の場合は、Enum.valueOf を使用して設定文字列を列挙値に変換します。
@initialize および @Destroy
アクションの実装は、デプロイ時に初期化タスクを実行する必要がある場合があります。また、アンデプロイ中にクリーンアップのウォールを実行する必要もあります。  このような理由により、@Initialize および @Destroy メソッドアノテーションがあります。
以下に例をいくつか示します。デプロイメント時に、ロギングアクションは一部のチェック(例:ファイルとディレクトリーが存在する)を実行しなければならない場合があります。また、いくつかの初期化タスクを実行することもできます(書き込みのためにログファイルを開くなど)。アンデプロイ時には、(ファイルを閉じるなど)クリーンアップタスクを実行する必要がある場合があります。これらのタスクを実行するコードを以下に示します。
public class MyLogAction {

		    @ConfigProperty
		    private File logFile;

		    @ConfigProperty
		    private LogLevel logLevel;

		    public static enum LogLevel {
		        DEBUG, 
		        INFO, 
		        WARN
		    }

		    @Initialize
		    public void initializeLogger() {
			// Check if file already exists… check if parent folder 
			// exists etc...
			// Open the file for writing...
		    }
 
		    @Destroy
		    public void cleanupLogger() {
		        // Close the file...
		    }

		    @Process
		    public void log(Message message) {
		        // log the message...
		    }
		}
注記
@ConfigProperty アノテーションはすべて、@Initialize デプロイヤーが @Initialize メソッドを呼び出す際に処理されます。そのため、@Initialize メソッドは、カスタム初期化を実行する前にこれらのフィールドの準備が整っている可能性があります。
注記
メソッドの指定には、これらの両方のアノテーションを常に使用する必要はありません。  必要な場合にのみ指定します。つまり、メソッドが初期化のみを必要とする場合は、@Initialize アノテーションのみを使用します(@Destroy アノテーションが付けられた一致メソッドを指定する必要はありません)。
注記
単一のメソッドを指定し、@Initialize と @Destroy の両方にアノテーションを付けることができます。
注記
オプションで、@Initialize メソッドで ConfigTree パラメーターを指定できます。これは、ConfigTree インスタンスに依存するアクションにアクセスできるようにします。
@onSuccess および @OnException
これらのアノテーションを使用して、アクションが設定されている パイプライン の正常な実行または失敗した実行で実行するメソッドを指定します。
public class OrderPersister {

		    @Process
		    public OrderAck storeOrder(Order order) {
		        // persist the order and return an ack...
		    }

		    @OnSuccess
		    public void logOrderPersisted(Message message) {
		        // log it...
		    }

		    @OnException
		    public void manualRollback(Message message, 
                                           Throwable theError) {
		        // manually rollback...
		    }
		}
これらの両方のアノテーションの場合、メソッドに渡されるパラメーターは任意です。上記のパラメーターには、none、一部、またはすべてを指定できます。  Enterprise Service Bus のフレームワークは、それぞれの場合に関連するパラメーターを解決します。

14.13. レガシーアクション

ライフサイクルアクション、Java Bean アクション、またはアノテーション付きアクションではないアクションはレガシーアクションと見なされます。レガシーアクションは、Enterprise Service Bus コードベースに存在する動作を継承します。

14.14. レガシーアクションの動作および属性

レガシーアクションには、以下の特徴があります。
  • アクションの設定は、単一の ConfigTree パラメーターを持つコンストラクターのプロビジョニングを通じて行われます。
  • アクションは、パイプラインを通過する すべてのメッセージ に対してインスタンス化されます。
  • アクションには、ライフサイクルメソッドに関する知識はありません。
  • process メソッドの呼び出しは常にリフレクションを介して行われます。

第15章 ゲートウェイとコネクター

15.1. ゲートウェイとコネクターの概要

はじめに

JBoss Enterprise SOA Platform と対話するすべてのクライアントが、そのネイティブプロトコルとメッセージ形式を理解することができるわけではありません。そのため、アーキテクト対応のエンドポイント(JBossESB を理解するエンドポイント)と、JBossESB を認識しないエンドポイント(JBossESB を理解しないもの)の間にブリッジできる必要があります。このようなブリッジングテクノロジーは、さまざまな分散システムに存在し、ゲートウェイやコネクターと呼ばれます。

SOA インフラストラクチャーで、ワールウェア対応クライアントは、新しい対応サービスを使用できる、従来の相互運用性シナリオ、または企業対応クライアントが、認識しないサービスを使用できることが重要になります。JBoss Enterprise SOA Platform の機能の 1 つは、JBossESB を使用して記述されていないクライアントやサービスなど、さまざまなクライアントとサービスが対話できるようにすることです。JBossESB には相互運用性バスの抽象概念があります。したがって、各自が認識していないエンドポイントをバスにプラグインできます。

15.2. ゲートウェイ

15.2.1. ゲートウェイリスナー

ゲートウェイリスナーは、ESB 認識の世界と ESB 非認識の世界を橋渡しするために使用されます。これは、外部 (ESB 非対応) エンドポイント経由で到着した ESB に対応していないメッセージのキューをリッスンするように設計された特殊なリスナープロセスです。メッセージがキューに到着すると、ゲートウェイリスナーがメッセージを受信します。ゲートウェイリスナーが受信データの到着を認識すると、そのデータ (ESB に対応していないメッセージ) を org.jboss.soa.esb.message.Message 形式に変換します。この変換は、ゲートウェイの種類に応じてさまざまな方法で行われます。変換が行われると、ゲートウェイリスナーはデータを正しい宛先にルーティングします。

15.2.2. ゲートウェイリスナーと通常のリスナーの相違点

ゲートウェイは、デスクトップ対応リスナーと同様に動作します。ただし、重要な相違点がいくつかあります。
  • ゲートウェイクラスは、ファイル、JMS メッセージ、SQL テーブルなどに含まれる任意のオブジェクトを取得できます(各ゲートウェイクラスは特定のトランスポートに特化されています)、JBossESB リスナーは、このドキュメントのメッセージ セクションで説明されているように JBossESB の正規化されたメッセージのみを処理できます。ただし、これらのメッセージには任意のデータを含めることができます。
  • message 設定アクションを実行するアクションクラスが 1 つだけ呼び出されます。allInOne リスナーは、アクション処理パイプラインを実行できます。
  • 'picked up'(ピックアップされたオブジェクトは、Maker メッセージオブジェクトを返す単一の 'composer class')を呼び出すために使用されます。最終的には、このサービスに対応する必要があるターゲットサービスに配信されます。設定時に定義されるターゲットサービスは、実行時にレジストリーによって EPR (または EPR の一覧)に変換されます。レジストリーによって返される EPR は、Madobe Messages のヘッダーに含まれる 'toEPR' と似ています。ただし、着信オブジェクトは toEPR を決定する動的な方法を持たない 'ESB-unaware' であるため、この値は設定時にゲートウェイに提供され、すべての送信メッセージに含まれます。
    同梱のコンポーザークラスがいくつかあります。デフォルトのファイルコンポーザクラスは、ファイルの内容をメッセージボディーにパッケージ化するだけです。JMS メッセージでも同じプロセスが発生します。SQL テーブル行にクラスを作成するデフォルトのメッセージは、設定で指定されたすべての列のコンテンツを java.util.Map にパッケージ化することです。
    これらのデフォルトの composer クラスはほとんどの用途に適していますが、独自のクラスを指定することもできます。唯一の要件は、単一の ConfigTree 引数を取るコンストラクターが必要で、Message コンポジションメソッドを提供する必要があります(デフォルト名は process ですが、コンストラクター時に提供された ConfigTree 内の <action> 要素の process 属性で異なる設定を行うことができます)。処理メソッドは、型オブジェクトの単一の引数を取り、メッセージ値を返す必要があります。
    FileGateway は file-filter-class 設定属性を受け入れます。これにより、問題のゲートウェイが使用するファイルを選択するのに使用できる FileFilter 実装を定義できます。ユーザー定義の FileFilter インスタンスの初期化はゲートウェイによって実行されます。インスタンスが org.jboss.soa.esb.listeners.gateway.FileGatewayListener.FileFilterInit タイプでもあると、init メソッドが呼び出され、ゲートウェイ ConfigTree インスタンスに渡されます。
    デフォルトでは、FileFilter 実装は FileGateway によって定義され、使用されます。入力接尾辞が設定ファイルに定義されている場合、その接尾辞に一致するファイルが返されます。または、入力接尾辞がない場合は、作業接尾辞、エラー接尾辞、および post 接尾辞に一致しない限り、すべてのファイルが許可されます。

15.2.3. ゲートウェイデータマッピング

ゲートウェイリスナーによって非ESBメッセージを受信すると、これは ラボメッセージ に変換されます。これがどのように実行されるかは、関連するゲートウェイリスナーのタイプによって異なります。それぞれのゲートウェイのデフォルトアプローチを以下に示します。
JMS ゲートウェイ
入力メッセージが JMS TextMessage の場合、関連付けられた String はデフォルトの Body の場所に配置されます。ObjectMessage または BytesMessage の場合、コンテンツは body location という名前の BytesBody.BYTES_LOCATION 内に配置されます。
ローカルファイルゲートウェイ
これにより、"Body location" という名前の BytesBody.BYTES_LOCATION 内に内容が置かれます。
Hibernate Gateway
コンテンツは、Body location という名前の ListenerTagNames.HIBERNATE_OBJECT_DATA_TAG に配置されます。
リモートファイルゲートウェイ
コンテンツは、Body location という名前の BytesBody.BYTES_LOCATION に配置されます。
注記
InVM トランスポートの導入により、ゲートウェイと同じアドレス空間(VM)内にサービスをデプロイできるようになり、ゲートウェイ間の対話の効率が向上します。

15.2.4. ゲートウェイデータマッピングの変更

マッピングは、ゲートウェイタイプごとに異なる方法で変更されます。
ファイルゲートウェイ
org.jboss.soa.esb.listeners.message.MessageComposer インターフェイスのインスタンスは、変換を実行します。デフォルトの動作を変更するには、独自の Compose および decompose メソッドを定義する適切な実装を指定します。composer-class 属性名を使用して、設定ファイルに MessageComposer 実装を必ず指定してください。
JMS および Hibernate ゲートウェイ
これらの実装では、設定クラスの定義にリフレクションアプローチを使用します。独自のメッセージ composer クラスを提供し、設定ファイルで composer-class 属性名を使用して、使用するインスタンスをゲートウェイに通知します。composer-process 属性を使用して、メッセージが必要なときに呼び出すクラスの動作をゲートウェイに通知することができます。このメソッドは オブジェクトを取り、メッセージを返す必要があります。指定しない場合は、プロセスのデフォルト名が使用されます。
注記
メッセージ設定を再定義するために使用するメソッドに関係なく、メッセージボディーだけでなく、メッセージの内容を完全に制御できることに注意してください。たとえば、元のコンテンツ、送信者などに基づいて新しく作成されたメッセージの ReplyTo または FaultTo エンドポイント参照を定義する場合は、ヘッダーの変更も検討する必要があります。

15.3. コネクター

15.3.1. Java Connector Architecture (JCA)

Java EE Connector Architecture (JCA) は外部にある異種のエンタープライズ情報システム (EIS) に対して Java EE システムの標準アーキテクチャーを定義します。EIS の例として、エンタープライズリソースプランニング(IaaS)システム、企業トランザクション処理(TP)、データベース、メッセージングシステムなどがあります。
JCA 1.6 は以下の管理機能を提供します。
  • connections
  • transactions
  • security
  • life-cycle
  • work instances
  • transaction inflow
  • message inflow
JCA 1.6 は http://jcp.org/en/jsr/detail?id=313 Java Community Process で JSR-322 として開発されました。

15.3.2. JCA 経由での接続

JCA Message Inflow は、JCA のメッセージインフローとして使用することができます。サービスのゲートウェイを有効にするには、最初に org.jboss.soa.esb.listeners.jca.InflowGateway クラスを実装するエンドポイントクラスを実装する必要があります。
public interface InflowGateway
{
  public void setServiceInvoker(ServiceInvoker invoker);
}
エンドポイントクラスには、デフォルトのコンストラクターまたは ConfigTree パラメーターを取るコンストラクターのいずれかが必要です。この Java クラスは、バインディング先の JCA アダプターのメッセージングタイプも実装する必要があります。以下は、JMS アダプターをフックする単純なエンドポイントクラスの例です。
public class JmsEndpoint implements InflowGateway, MessageListener
{
  private ServiceInvoker service;
  private PackageJmsMessageContents transformer = new PackageJmsMessageContents();

  public void setServiceInvoker(ServiceInvoker invoker)
  {
    this.service = invoker;
  }

  public void onMessage(Message message)
  {
    try
    {
      org.jboss.soa.esb.message.Message esbMessage = transformer.process(message);
      service.deliverAsync(esbMessage);
    }
    catch (Exception e)
    {
      throw new RuntimeException(e);
    }
  }
}
このクラスに定義されたゲートウェイごとに、JmsEndpoint クラスのインスタンスが 1 つ作成されます。これは、プールされるメッセージ駆動 Bean とは異なります。クラスの 1 つのインスタンスのみが受信メッセージとすべての受信メッセージに対応するため、スレッドセーフコードを作成する必要があります。
設定時に、Madobe は ServiceInvoker を作成し、エンドポイントクラスで setServiceInvoker メソッドを呼び出します。次に、JCA のエンドポイントがアクティブになり、エンドポイントクラスインスタンスはメッセージを受信する準備が整います。JmsEndpoint の例では、インスタンスは JMS メッセージを受け取り、Tunece メッセージに変換します。その後、ServiceInvoker インスタンスを使用してターゲットサービスで呼び出します。
注記
JMS エンドポイントクラスは、org.jboss.soa.esb.listeners.jca.JmsEndpoint で提供されます。このクラスは、JMS JCA インフローアダプターを使用して再度使用できます。

15.3.3. JCA インフローゲートウェイの設定

jboss-esb.xml ファイルの設定を変更して JCA インフローゲートウェイを設定します。
<service category="HelloWorld_ActionESB"
  name="SimpleListener"
  description="Hello World">
  <listeners>
    <jca-gateway name="JMS-JCA-Gateway"
     adapter="jms-ra.rar"
     endpointClass="org.jboss.soa.esb.listeners.jca.JmsEndpoint">
    <activation-config>
     <property name="destinationType" value="javax.jms.Queue"/>
     <property name="destination" value="queue/esb_gateway_channel"/>
    </activation-config>
  </jca-gateway>
...
 </service>
<service category="HelloWorld_ActionESB"
  name="SimpleListener"
  description="Hello World">
  <listeners>
    <jca-gateway name="JMS-JCA-Gateway"
     adapter="jms-ra.rar"
     endpointClass="org.jboss.soa.esb.listeners.jca.JmsEndpoint">
    <activation-config>
     <property name="destinationType" value="javax.jms.Queue"/>
     <property name="destination" value="queue/esb_gateway_channel"/>
    </activation-config>
  </jca-gateway>
...
 </service>
JCA ゲートウェイは <jca-gateway> 要素で定義されます。これらは、この XML 要素の設定可能な属性です。

表15.1 JCA-gateway 設定属性

属性 必須 Description
name はい ゲートウェイの名前
adapter はい 使用しているアダプターの名前。JBoss では、デプロイした RAR のファイル名です(例: jms-ra.rar)。
endpointClass はい エンドポイントクラスの名前。
messagingType いいえ アダプターのメッセージインターフェイス。指定しないと、エンドポイントクラスに基づいて推測されます。
transacted いいえ デフォルトは true です。JTA トランザクション内でメッセージを呼び出すかどうか。
<jca-gateway> 内で <activation-config> 要素を定義する必要があります。この要素は、アクションプロパティーと同じ構文を持つ 1 つ以上の <property> 要素を取ります。<activation-config> の下のプロパティーは、エンドポイントクラスにメッセージを送信するために使用される JCA アダプターのアクティベーションを作成するために使用されます。これは MDB で JCA を使用するのとは大きく変わりません。
<jca-gateway> 内に必要な数の <property> 要素を含めることもできます。このオプションは、エンドポイントクラスに追加設定を指定できるように提供されます。これらは、コンストラクターに渡される ConfigTree から読み取ることができます。

15.3.4. 標準のアクティベーションプロパティーのマッピング

ActivationMapper を使用して、多くの administrators プロパティーがアクティベーション設定に自動的にマッピングされます。プロパティー、その場所、およびそれらの目的を以下の表に示します。

表15.2 標準のアクティベーションプロパティーのマッピング

属性 場所 Description
maxThreads jms-listener 同時に処理できるメッセージの最大数。
dest-name jms-message-filter JMS 宛先名。
dest-type jms-message-filter JMS 宛先タイプ、QUEUE または TOPIC。
selector jms-message-filter JMS メッセージセレクター。
providerAdapterJNDI jms-jca-provider JCA インフローがリモート JMS プロバイダーにアクセスするために使用できるプロバイダーアダプターの JNDI の場所。これは、デフォルトの JCA インフローアダプターによってサポートされる JBoss 固有のインターフェイスであり、必要に応じて他のインフローアダプターで使用できます。
ActivationMapper. インターフェイスを実装するクラスを指定すると、この動作を過剰に最適化できます。このクラスは、グローバルまたは個別のデプロイメント設定内で宣言できます。
指定された JCA アダプターに使用されるデフォルトのマッパーを定義するため、jbossesb-properties.xml ファイルでグローバルに指定すると、設定されるプロパティーの名前は org.jboss.soa.esb.jca.activation.mapper.<adapter name> で、値は ActivationMapper のクラス名です。
以下の例は、JBoss JCA アダプター jms-ra.rar のアクティベーション仕様でプロパティーをマップするために使用されるデフォルトの ActivationMapper の設定を示しています。
<properties name="jca"> 
       <property name="org.jboss.soa.esb.jca.activation.mapper.jms-ra.rar"
            value="org.jboss.soa.esb.listeners.jca.JBossActivationMapper"/> 
   </properties>
デプロイメント内で ActivationMapper を指定すると、グローバル設定が上書きされます。マッパーはリスナー、バス、または優先順位が同じ順序で指定できます。
以下は、リスナー設定内でマッパー設定を指定する例を示しています。
<jms-listener name="listener" busidref="bus" maxThreads="100">
        <property name="jcaActivationMapper" value="TestActivationMapper"/>
    </jms-listener>
以下は、バス設定内でマッパー設定を指定する方法です。
<jms-bus busid="bus">
        <property name="jcaActivationMapper" value="TestActivationMapper"/>
        <jms-message-filter dest-type="TOPIC" dest-name="DestName"/>
    </jms-bus>
以下は、プロバイダー設定内でマッパー設定を指定する方法です。
<jms-jca-provider name="provider" connection-factory="ConnectionFactory">
        <property name="jcaActivationMapper" value="TestActivationMapper"/>
        <jms-bus busid="bus">
            <jms-message-filter dest-type="TOPIC" dest-name="DestName"/>
        </jms-bus>
    </jms-jca-provider>

第16章 JAXB アノテーションの概要

16.1. JAXB アノテーションの概要

JAXB アノテーションのIntroductions は、JBoss Enterprise SOA Platform の機能であり、JAXB アノテーションの導入を可能にする XML 設定を定義できます。ネイティブの JBossWS SOAP スタックは SOAP との間でバインド/からバインドするためにこの機能が追加されました。つまり、アノテーションなしの型セットを使用して JBossWS エンドポイントを構築することができます。

16.2. JAXB アノテーションのはじめに

XML 設定は、エンドポイントデプロイメントの META-INF/jaxb-intros.xml ファイルに保存する必要があります。

16.3. JAXB アノテーションの概要設定の作成

設定の XSD は、でオンラインで http://anonsvn.jboss.org/repos/jbossws/projects/jaxbintros/tags/1.0.0.GA/src/main/resources/jaxb-intros.xsd 利用できます。(IDE で、この XSD を namespace に対して登録し http://www.jboss.org/xsd/jaxb/intros ます。)
@XmlType
@XmlElement
https://jaxb.dev.java.net/nonav/2.1.3/docs/api/javax/xml/bind/annotation/XmlElement.html: これは、Field 要素およびMethod 要素になります。
@XmlAttribute
https://jaxb.dev.java.net/nonav/2.1.3/docs/api/javax/xml/bind/annotation/XmlAttribute.html: これは、Field 要素およびMethod 要素になります。
設定ファイルの基本構造は、Java クラス(つまり、Fields および Methods を含むクラス)に従います。 <Class>、<Field>、および <Method> 要素はすべて name 属性を必要とします。この属性は、クラス、フィールド、またはメソッドの名前を指定します。この name 属性の値は正規表現をサポートできます。これにより、単一のアノテーション導入設定を複数のクラス、フィールド、またはメンバーでターゲットに設定できます。たとえば、クラス内のフィールドに name-space を設定したり、パッケージのすべてのクラスに対して名前スペースを設定したりできます。
アノテーションのIntroduction 設定はアノテーション定義自体と完全に一致します。各アノテーションの element-value pair はアノテーション導入設定の属性によって表されます。XSD と IDE を使用して設定を編集します。
以下に例を示します。
<?xml version = "1.0" encoding = "UTF-8"?>
<jaxb-intros xmlns="http://www.jboss.org/xsd/jaxb/intros">

  <!--
  The type namespaces on the customerOrder are 
  different from the rest of the message...
  -->
    
  <Class name="com.activebpel.ordermanagement.CustomerOrder">
    <XmlType propOrder="orderDate,name,address,items" />
      <Field name="orderDate">
        <XmlAttribute name="date" required="true" />
      </Field>
      <Method name="getXYZ">
        <XmlElement 
         namespace="http://org.jboss.esb/quickstarts/bpel/ABI_OrderManager"
         nillable="true" />
      </Method>
  </Class>
    
  <!-- More general namespace config for the rest of the message... -->
  <Class name="com.activebpel.ordermanagement.*">
    <Method name="get.*">
      <XmlElement namespace="http://ordermanagement.activebpel.com/jaws" />
    </Method>
  </Class>

</jaxb-intros>

付録A 更新履歴

改訂履歴
改訂 5.3.1-78.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
改訂 5.3.1-78Thu Feb 07 2013 CS Builder Robot
コンテンツ仕様:10767、Revision: 372112 からビルド