Show Table of Contents
第9章 サービス設定の定義
9.1. 概要
JBossESB 4.8 の設定は jbossesb-1.2.0 XSD (http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.2.0.xsd) をベースとしています。この XSD は常に ESB 設定の最終的な参照となります。
このモデルは次の 2 つの主要セクションから構成されます。
図9.1 JBoss Enterprise Service Bus 設定モデル
- <providers>: モデルのこの部分は主としてモデルの <services> セクション内で定義されるメッセージの <listener> により使用されるすべてのメッセージ <bus> プロバイダーを定義します。
- <services>:モデルのこの部分は主に JBoss ESB の単一インスタンスの制御下にある全サービスを定義します。各 <service> インスタンスには "Gateway" または "Message Aware" のいずれかのリスナー定義が含まれます。
このモデルに基づいて構成を行う最も簡単な方法は、Eclipse 統合開発環境内の XSD 対応の XML エディターを使用することです。このエディターは構成の編集中に自動補完の機能を提供します。ファイル上で右クリックして Open With -> XML Editor の順で選択します。
9.2. Providers
図9.2 プロバイダー構成モデル
設定の
<providers> 部分では、ESB の単一インスタンスに対するすべてのメッセージ <provider> インスタンスを定義します。現在サポートされている 2 つの種類のプロバイダーを以下に示します。
- これらは、「プッシュ」されたメッセージであるリスナーなどに対する「イベント駆動」プロバイダーのプロバイダー詳細を指定します。このプロバイダーの種類の例は
<jms-provider>です。 - Schedule Provider: メッセージを「プル」するリスナーなどのスケジュール駆動リスナーのプロバイダー設定
バスプロバイダー (
<jms-provider>など) には複数の <bus> 定義を含めることができます。<provider> は、その <property> で定義される全 <bus> で共通となるプロバイダー固有プロパティに関連する <property> インスタンスで修飾することもできます (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>
上記の例は「基本の」
<provider> と <bus> タイプを使用しています。これに問題はありませんが、実際の設定を作成するにはこれらのタイプの特殊化された拡張を使用することをお薦めします。JMS なら <jms-provider> と <jms-bus> です。 上記の設定でもっとも重要となる部分は <bus> インスタンスで定義される busid 属性です。 これは <bus> エレメント／タイプで必要とされる属性です (<jms-bus> などそのすべての特殊化を含む)。この属性は <listener> 構成内で使用され、リスナーがそのメッセージを受け取る <bus> インスタンスを参照します。これについては後ほど詳しく説明します。
9.3. サービス
図9.3 サービス構成モデル
構成の
<services> の部分は ESB のこのインスタンスの管理下にある各サービスを定義します。<service> 一連の構成として定義します。<service> は次の属性で修飾することもできます。
表9.1 サービス属性
| 名前 | 説明 | タイプ | 必須 |
|---|---|---|---|
| name | サービスレジストリ内で登録されるサービスのサービス名 | xsd:string | true |
| カテゴリ | サービスレジストリ内で登録されるサービスのサービスカテゴリ | xsd:string | true |
| 詳細 | 読みやすい形式のサービス詳細、 リジストリ内に格納される | xsd:string | true |
<service> は <listeners> のセットと <actions> のセットを定義することができます。構成モデルは「基本の」 <listener>タイプの他、 サポートされるメインのトランスポートそれぞれの特殊化も定義します。<jms-listener>、<sql-listener> など。
「基本の」
<listener> は次の属性を定義します。これらの属性定義はすべての <listener> 拡張によって継承されます。このように、InVM トランスポートなど JBossESB でサポートするリスナーやゲートウェイすべてに対し設定することができます。
表9.2 リスナーの属性
| 名前 | 説明 | タイプ | 必須 |
|---|---|---|---|
| name | リスナーの名前、 この属性は主にログの目的で必要となる | xsd:string | true |
| busrefid | リスナーインスタンスが受け取るメッセージの元となる <bus> の busid への参照 | xsd:string | true |
| maxThreads | リスナーがアクティブとして持てる同時メッセージ処理スレッドの最大数 | xsd:int | True |
| is-gateway | リスナーインスタンスが「ゲートウェイ」であるかないかは関係ありません。[a] | xsd:boolean | true |
[a]
メッセージバスは特定のメッセージチャンネル／トランスポートの詳細を定義します。
| |||
リスナーはゼロまたは複数の
<property> エレメントのセットを定義できます (ちょうど <provider> と <bus> のエレメント／タイプのようなもの)。これらはリスナー固有のプロパティの定義に使用されます。
注記
サービス内で定義される各ゲートウェイリスナーに対しては、ESB 対応のリスナー (または「ネイティブ」) も定義されなければなりません。ゲートウェイリスナーは双方向のエンドポイントを定義するのではなく ESB への「スタートポイント」を定義するためです。 ESB 内からメッセージをゲートウェイに送ることはできません。また、ゲートウェイはエンドポイントではないため、リジストリ内に維持されるエンドポイント参照 (EPR) はありません。
<bus> に対する <listener> 参照の例を次の図で示します (「基本」タイプのみ使用)。
<?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"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.1.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>
1 つまたは複数の
<actions> の一覧がないと、サービスはほとんど何もしません。<actions> には一般的にサービスによって受け取られるメッセージのペイロードを処理するロジックが含まれています (そのリスナーを通じて)。 代わりに、外部のサービス／エンティティによって消費されるメッセージに対して変換またはルーティングのロジックを含めることもできます。
<action> エレメント／タイプは次の属性を定義します。
表9.3 アクションの属性
| 名前 | 説明 | タイプ | 必須 |
|---|---|---|---|
| name | アクションの名前、 この属性は主にログの目的で必要となる | xsd:string | true |
| クラス | org.jboss.soa.esb.actions.ActionProcessor 実装クラス名 | xsd:string | true |
| プロセス | メッセージ処理に反射的に呼び出される「process」メソッドの名前 (デフォルトは ActionProcessor クラスで定義されるように「process」メソッドとなる) | xsd:int | false |
<actions> セット内の <action> インスタンスの一覧では、アクションは <action> インスタンスが <actions> セットに表れる順序で呼び出されます (その「process」メソッドが呼び出される)。各 <action> から返されるメッセージは一覧内の次の <action> への入力メッセージとして使用されます。
このモデル内のいくつかの他のエレメント／タイプのように、
<action> タイプもゼロまたは複数の <property> エレメントインスタンスを含むことができます。<property> エレメント／タイプは標準の名前と値の組み合わせを定義するか、自由形式のコンテンツを含むことができます (xsd:any)。XSD によれば、この自由形式のコンテンツは構成内の場所 (<provider>、<bus>、<listener> のいずれかまたはその派生物のいずれか) に関係なく<property> エレメント/タイプの有効な子コンテンツになります。ただし、 この自由形式の子コンテンツが使用される<action>定義の<property> インスタンス上でのみになります。
上記の
<action> 定義に記載されているように、アクションは org.jboss.soa.esb.actions.ActionProcessor class クラスを実装することで実装されます。このインターフェースの実装はすべて次の形式のパブリックコンストラクターを含まなければなりません。
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>
9.4. 固有タイプの実装
JBoss ESB 構成モデルは「基本」タイプの
<provider>、<bus>、<listener> のトランスポート固有特殊化を定義します (JMS, SQL など)。これにより構成を厳密に検証できるようになり、XSD 対応の XML エディター (Eclipse XML Editor など) を使用するユーザーにとって構成が容易になります。これら特殊化は特に何の設定を行わなくても JBoss ESB でサポートされる各トランスポートの構成要件を明示的に定義します。JBoss ESB の構成を行っている場合は「基本」タイプの代わりにこの特殊化されたタイプを使用することを推奨します。あるいは、公式の JBoss ESB リリース以外で新しいトランスポートがサポートされる場合のみです。
「基本」タイプから構成を行っている場合に適用される同じ基本の原則がトランスポート固有の代替から構成を行う場合にも適用されます。
<jms-provider>などのプロバイダー設定を定義します。- 新しいプロバイダーにバスの構成を追加し (
<jms-bus>)、 固有の busid 属性値を割り当てます。 - 通常通りに
<services>を定義して、作成したばかりの新しいバス構成を参照する (busrefid を使用) トランスポート固有のリスナー構成 (<jms-listener>など) を追加します (例：<jms-bus>を参照する<jms-listener>)。
これらトランスポート固有のタイプを使用する場合に適用されるルールは、1 つのタイプのリスナーから別のタイプのバスへのクロス参照はできないということだけです。つまり、
<jms-bus> から <jms-listener> しか参照できないということです。相互参照されるとランタイムエラーが発生します。
このため、本リリースに配備されるトランスポート固有の実装は、JMS、SQL、FTP、Hibernate、ファイルシステム、スケジュール、JMS/JCA 統合となります。
- 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> は実際のメッセージのキュー／トピックとセレクターの詳細を指定します。- 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> はメッセージ／行の選択と処理プロパティを指定します。- 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> はメッセージ／ファイルの選択と処理プロパティを指定します。- ハイバネート
<hibernate-provider>、<hibernate-bus>、<hibernate-listener><hibernate-message-filter> は <hibernate-bus> または <hibernate-listener> エレメントのいずれかに追加できます。<hibernate-provider> はハイバネート設定プロパティの場所などファイルシステムアクセスのプロパティを指定し、<hibernate-message-filter> はリッスンするクラス名とイベントを指定します。- ファイルシステム
<fs-provider>、<fs-bus>、<fs-listener>、<fs-message-filter><fs-message-filter> は <fs-bus> または <fs-listener> エレメントのいずれかに追加できます。<fs-provider> と <fs-bus> はファイルシステムアクセスプロパティを指定し、<fs-message-filter> はメッセージ／ファイルの選択と処理プロパティを指定します。- スケジュール
<schedule-provider>これは特殊タイプのプロバイダーで、上記のバスベースのプロバイダーとは異なります。詳細はスケジューリングをご覧ください。- JMS/JCA 統合
<jms-jca-provider>このプロバイダーは JCA インフローを使って着信メッセージの配信を有効にするため <jms-provider> の代わりに使用できます。これによりトランザクション処理されたフローをアクションパイプラインに導入し、アクションを JTA トランザクション内に包み込みます。
お気づきの通り、現在実装されているトランスポート固有のタイプはすべて「基本」タイプにない追加タイプ、<*-message-filter> を含んでいます。このエレメント/タイプは <*-bus> または <*-listener> いずれかの内側に追加できます。 このタイプを両方の場所で指定すると、バス (このバスを使用するすべてのリスナー) にグローバルに、またはリスナーベースで 1 リスナーでローカルにメッセージのフィルタリングを指定することができます。
注記
それぞれのトランスポート固有タイプの属性一覧と詳細を表示するには、各属性に関する全詳細が記載されている jbossesb-1.2.0 XSD (http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd) を使用することができます。Eclipse XML Editor など XSD 対応の XML エディターを使用するとこうしたタイプでの作業が非常に容易になります。
表9.4 JMS メッセージフィルタ設定
| プロパティ名 | 説明 | 必須 |
|---|---|---|
| dest-type | 宛先のタイプ (QUEUE または TOPIC) | Yes |
| dest-name | Queue または Topic の名前 | Yes |
| selector | 複数のリスナーを同じキュー/トピックで登録できるようにします。ただし、リスナーはこのメッセージセレクターに基づいてフィルタリングされます。 | No |
| persistent | JMS の配信モードを永続的にするかどうかを指定します。値は真または偽です。デフォルト値は真です。 | No |
| acknowledge-mode | JMS セッション確認モード。AUTO_ACKNOWLEDGE、CLIENT_ACKNOWLEDGE、DUPS_OK_ACKNOWLEDGE のいずれかの値になります。デフォルト値は AUTO_ACKNOWLEDGE です。 | No |
| jms-security-principal | JMS 宛先ユーザー名。宛先への接続を作成するときに使用されます。 | No |
| jms-security-credential | JMS 宛先パスワード。宛先への接続を作成するときに使用されます。 | No |
構成例:
<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>表9.5 JMS リスナーの構成
| プロパティ名 | 説明 | 必須 |
|---|---|---|
| name | リスナーの名前 | Yes |
| busrefid | リッスンする JMS の ID | No |
| is-gateway | この JMS リスナーインスタンスはゲートウェイですか？それともメッセージ対応のリスナーですか？ | No。デフォルトは false です。 |
| maxThreads | JMS バス上でメッセージをリッスンする際に使用するスレッドの最大数。is-gateway が false の場合のみ該当 | No。デフォルトは 1 です。 |
| clientId | JMS 接続と関連付けられたクライアント ID。接続とオブジェクトを、プロバイダーによりクライアントの代わりに保たれたステータスを関連付ける際に使用。例：永続的なサブスクリプション | No。clientId が必須にも拘らず (例：durableSubscriptionName が指定されている場合)、指定されていない場合、デフォルトのリスナー名を使用します。 |
| durableSubscriptionName | 永続的なサブスクリプション名 | No。JMS Topics の場合のみ該当 |
9.5. ファイルシステムプロバイダー設定
以下のファイルシステムプロバイダーの設定オプションは、ファイルシステムメッセージフィルターにあります (fs-message-filter)。これ自体は fs-bus に含まれています。これに関する適切な例は、helloworld_file_action クイックスタートを参照してください。
以下のディレクトリオプションについては、指定された各ディレクトリがなければならず、ファイルの移動や名前の変更を行うにはアプリケーションサーバーのユーザーにはディレクトリ上の書き込み／読み取り権限がなければなりません。
表9.6 ファイルシステムメッセージフィルター設定
| プロパティ | 説明 | 必須 |
|---|---|---|
| directory | 受信ファイルに関してモニタリングが行われる FTP ディレクトリ | Yes |
| input-suffix | 受信ファイルのフィルタリングに使用するサフィックス。".esbIn" のように 1 文字以上かつ "." が含まれている必要があります。 | Yes |
| work-suffix | ファイルが ESB に処理される場合に使用するサフィックス。デフォルトは ".esbInProcess"。 | No |
| post-suffix | ファイルが ESB により正常に処理された場合に使用するサフィックス。デフォルトは ".esbDone"。 | No |
| post-delete | true の場合、 ファイルは処理後に削除される。 この場合、 post-directory および post-suffix は無効になる。デフォルト値は真。 | No |
| post-directory | ESB による処理後にファイルの移動先となる FTP ディレクトリ。デフォルト値は上記のディレクトリです。 | Yes |
| post-rename | true の場合、ファイルは処理後に名前が変更されます。post-directory および post-suffix は相互排他的である点に注意してください。 | No |
| error-delete | True の場合、処理中にエラーが発生するとこのファイルは削除されます。この場合、error-directory および error-suffix からの影響はありません。デフォルト値は true。 | No |
| error-directory | 処理中にエラーが発生した場合にファイルの移動先となる FTP ディレクトリ。デフォルト値は上記のディレクトリ。 | Yes |
| error-suffix | 処理中にエラーが発生した場合にファイル名に追加されるサフィックス。デフォルト値は .esbError。 | No |
9.6. FTP プロバイダー構成
表9.7 FTP プロバイダー構成
| プロパティ | 説明 | 必須 |
|---|---|---|
| hostname | 単純にポート 21 を使用する <host> の <host:port> の組み合わせで問題ありません。 | Yes |
| username | FTP 接続に使用されるユーザー名 | Yes |
| password | 上記ユーザーのパスワード | Yes |
| directory | 新しい受信ファイルについてモニタリングされる FTP ディレクトリ | Yes |
| input-suffix | ESB による消費を目的とするファイルのフィルタに使用されるファイルサフィックス (注: 「.esbIn」のようにドットを付ける)。 すべてのファイルが検索されるよう空白文字列にすることも可能。 | Yes |
| work-suffix | 別のスレッドやプロセスがファイルを取得しないようファイル処理中に使用されるファイルサフィックス。デフォルト値は .esbInProcess です。 | No |
| post-delete | true の場合、 ファイルは処理後に削除される。 この場合、 post-directory および post-suffix は無効になる。デフォルト値は真。 | No |
| post-directory | ESB による処理後にファイルの移動先となる FTP ディレクトリ。デフォルト値は上記のディレクトリです。 | No |
| post-suffix | 処理後にファイル名に追加されるファイルサフィックス。デフォルト値は .esbDone。 | No |
| error-delete | True の場合、処理中にエラーが発生するとこのファイルは削除されます。この場合、error-directory および error-suffix からの影響はありません。デフォルト値は true。 | No |
| error-directory | 処理中にエラーが発生した場合にファイルの移動先となる FTP ディレクトリ。デフォルト値は上記のディレクトリ。 | No |
| error-suffix | 処理中にエラーが発生した場合にファイル名に追加されるサフィックス。デフォルト値は .esbError。 | No |
| protocol | 次のいずれかのプロトコル
| No |
| passive | FTP接続がパッシブ状態であることを示します。この値を新に設定すると、FTP クライアントが FTP サーバーに対して 2 つの接続を確立します。デフォルト値は false で、クライアントは FTP サーバーが接続するポートを FTP サーバーに指示します。次に FTP サーバーはクライアントに対する接続を確立します。 | No |
| read-only | true の場合、 FTP サーバーはファイルに対する書き込み操作を許可しません。この場合、 次のプロパティは無効となるので注意: work-suffix、post-delete、post-directory、post-suffix、error-delete、error-directory、および error-suffix。デフォルトは false。詳細については、「読み取り専用 FTP リスナー」のセクションを参照してください。 | No |
| certificate-url | FTPS サーバー検証のためのパブリックサーバー証明書の URL または SFTP クライアント検証のためのプライベート証明書の URL。SFTP 証明書は、デプロイメント成果物内に組み込まれたリソースとして存在します。 | No |
| certificate-name | FTPS サーバー検証のための証明書の一般名 | No |
| certificate-passphrase | SFTP クライアント検証用プライベートキーのパスフレーズ | No |
9.7. FTP リスナーの構成
設定されたスケジュール (scheduleidref) を基にリモートのファイルに対してポーリングを行うリスナーをスケジュールします。「サービススケジューリング」を参照してください。
9.7.1. 読み取り専用 FTP リスナー
FTP プロバイダーのプロパティ「read-only」を true に設定するとリモートファイルシステムは書き込み動作を許可しないことをシステムに指示します。パーミッションが特定ファイルに与えられるようなメインフレームコンピュータで FTP サーバーが稼働している場合によく見られるケースです。
読み取り専用実装は JBoss TreeCache を使用して読み取られているファイル名の一覧を保持し、前に読み取られたことがなかったものだけをフェッチします。キャッシュは cacheloader を使用して設定し、安定したストレージに対してそのキャッシュを永続化する必要があります。
注記
ゲートウェイの呼び出しに使用するファイルがどのように作成され、コンテンツが書き込みされるかによっては、コンテンツが完全に書き込まれる前に、リスナーがファイルにアクセスできます。このタイミングの問題を回避するには、一時ファイルをまず作成して、目的のコンテンツで完全に作成されるようにします。一時ファイル内のコンテンツが完了すると、FTP ゲートウェイリスナー向けに設定されたディレクトリ／ファイル名へ移動する必要があります。
キャッシュからファイル名を削除する手段が存在しなければならないので注意してください。定期的に別の場所にファイルを移動するメインフレーム上のアーカイブ機能プロセスなどが該当します。キャッシュからのファイル名削除は、 2、 3 日置きにキャッシュからファイル名を削除するデータベース手順を設けることなどで行うことができます。キャッシュからファイル名を立ち退かせる場合に cacheloader からもそのファイル名を削除する TreeCacheListener を指定するのも別の手段となります。立ち退き期間は設定可能となります。これは FTP リスナー構成でプロパティ (removeFilesystemStrategy-cacheListener) を設定することにより行うことができます。
表9.8 読み取り専用 FTP リスナーの構成
| 名前 | 説明 |
|---|---|
| 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 | JBoss TreeCacheListener 実装が TreeCache で使用されることを指定する。デフォルト値は 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 キャッシュ構成例の一部:
<region name="/ftp/cache"> <attribute name="maxNodes">5000</attribute> <attribute name="timeToLiveSeconds">1000</attribute> <attribute name="maxAgeSeconds">86400</attribute> </region>
表9.9 構成
| プロパティ | 説明 | コメント |
|---|---|---|
| maxNodes | キャッシュに格納されるファイルの最大数。 | 0 は制限無しを意味します。 |
| timeToLiveSeconds | ノードが一掃されるまでのアイドル時間 (秒単位)。 | 0 は制限無しを意味します。 |
| maxAgeSeconds | ノードが一掃されるまでにアイドル時間に関係なくオブジェクトが TreeCache 内に存在する時間 (秒単位)。 | 0 は制限無しを意味します。 |
helloworld_ftp_action クィックスタートは read-only 構成を示します。クィックスタート実行方法に関する説明を参照するには helloworld_ftp_action クィックスタートディレクトリで「ant help」を実行します(http://labs.jboss.com/jbosscache/docs/index.html)。
9.8. UDP ゲートウェイ
UDP Gateway は、UDP プロトコル経由で送信される ESB 未対応のメッセージを受信するための実装です。ペイロードは、デフォルトの ESB メッセージオブジェクトの場所にあるアクションチェーンへ渡されます。アクションは esbMessage.getBody().get() を呼び出し、バイト配列ペイロードをリトリーブします。
表9.10 UDP ゲートウェイ設定
| プロパティ | 説明 | コメント |
|---|---|---|
| ホスト | リッスンするホスト名/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/>
9.9. JBoss リモーティング (JBR) 設定
JBoss Remoting Gateway は JBoss Remoting (http://www.jboss.org/jbossremoting/) をトランスポートオプションとして JBoss ESB にリンクします。JBR 経由 HTTP (S) および Socket (+SSL) に対するサポートを活用します。
JBR プロバイダーの基本設定は以下の通りです。
<jbr-provider name="socket_provider" protocol="socket" host="localhost">
<jbr-bus busid="socket_bus" port="64111"/>
</jbr-provider>
そのため、基本的な <jbr-provider> や <jbr-bus> 設定は、非常にシンプルです。<jbr-listener> 経由で <service> 設定から、<jbr-bus> を参照可能です。
<listeners>
<jbr-listener name="soc" busidref="socket_bus" is-gateway="true"/>
</listeners>
<jbr-listener> はゲートウェイとしてのみサポートされます。is-gateway を false に設定すると Service デプロイメントエラーが発生します。
JBR Gateway は、<jbr-provider>、<jbr-bus> または <jbr-listener> 要素 (<property> 要素として) のいずれかに設定可能な設定プロパティを多数サポートします。以下にまとめています。
表9.11 構成
| 名前 | 説明 | デフォルト値 |
|---|---|---|
| synchronous | 対象サービスを同期的に呼び出します。 | 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 |
JBR Gateway は JBR 固有の設定プロパティをサポートする点に注意してください。これは、プロパティ名に jbr- のプレフィックスを追加することで実行できます。設定済みのプロトコルに関する JBR 固有の設定については、JBoss Remoting の文書を参照してください。以下の設定例では、HTTPS のキーストアとクライアント認証モードを構成するための JBR 固有設定を指定しています。
<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>
JBR Gateway では、レスポンスヘッダーはすべて、
org.jboss.soa.esb.message.ResponseHeader クラスのインスタンスとして、Message.Properties 内にある必要があります。そのため、JBR Gateway をレスポンスヘッダーに設定する必要がある場合、Gateway レスポンスへ提供された Enterprise Service Bus Message (例：対象サービスの同期呼び出しの後) には、Message.Properties 上に設定された ResponseHeader クラスのインスタンスを含める必要があります。
9.10. HTTP ゲートウェイ
HTTP ゲートウェイでは、Enterprise Service Bus 上でメッセージ未対応の HyperText Transfer Protocol エンドポイントを公開できます。
Gateway は JBoss Enterprise Service Bus Application Server HTTP Container を使用して、HTTP エンドポイントを公開するため、設定の多くはコンテナーレベルで管理されます。バインド／ポートアドレス、SSL などです。
9.10.1. 基本設定
以下のやり方でサービス上に <http-gateway> を設定するのが簡単です (プロバイダー設定は必要なし)。
<service category="Vehicles" name="Cars" description="" invmScope="GLOBAL">
<listeners>
<http-gateway name="Http" />
</listeners>
<actions mep="RequestResponse">
<!-- Service Actions.... -->
</actions>
</service>
上記の設定は、
default HTTP バスプロバイダーを使用します。これは、busrefid 属性を定義しないためです。サービス名を使用して、HTTP エンドポイントアドレスを以下の方法で構築します。
http://<host>:<port>/<.esbname>/http/Vehicles/Cars
".esb" 拡張子のない、.esb デプロイメントの名前の <.esbname> トークン。アドレスの "http" トークンも注意してください。これは、<http-gateway> エンドポイント全てに使用されるハードコードされた名前空間のプレフィックスです。
9.10.2. URL パターン
<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/*
9.10.3. ポート制限
プロパティ 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/*
9.10.4. 処理リクエスト
<http-gateway> は通常、リクエスト MIME タイプをベースに HTTP Request ペイロードをデコーディングすることができます。これは、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> もペイロード属性をサポートし、上記のデフォルトの MIME タイプをベースとする動作をオーバーライドして使用することができます。この属性を使い、ゲートウェイにペイロードを "bytes" または "string" として処理するよう明示的に指示することができます。
9.10.5. リクエスト情報
HyperText Transfer Protocol Request には、サービスが必要とする情報が多数含まれています (つまり、
POST の場合、リクエストペイロードのみ)
HttpRequest requestInfo = HttpRequest.getRequest(message);
HttpRequest は以下のプロパティを公開します (getter メソッドを使用)
表9.12 プロパティ
| プロパティ | 説明 |
|---|---|
| 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 仕様を参照)。 |
| pathInfo | このリクエストが出された時にクライアントが送信する URL に関連付けられた追加のパス情報。この追加のパス情報は、"/" 文字から始まり、エンドポイントパスの後、かつクエリ文字列の前に来ます。追加のパス情報がなかった場合、このメソッドは null を返します。CGI 変数の PATH_INFO の値と同じです (Servlet 仕様を参照)。 |
| pathInfoToken | pathInfo のトークンを含む List<String> |
| queryString | クエリ文字列 |
| requestURI | プロトコル名からクエリ文字列までのこのリクエスト URL の一部。Web コンテナーはこの文字列をデコーディングしません。 |
| requestPath | エンドポイントを呼び出すリクエスト URL の一部。追加のパス情報やクエリ文字列は含みません。CGI 変数の SCRIPT_NAME の値と同じ。urlPattern が "/*" 出会った場合、このメソッドは "http" を返します。 |
| localAddr | リクエストを受け取ったインターフェースの IP アドレス |
| localName | リクエストを受け取った IP インターフェースのホスト名 |
| method | HTTP メソッド |
| protocol | HTTP プロトコルの名前とバージョン |
| remoteAddr | クライアントまたはリクエストを最後に送信したプロキシの IP アドレス。CGI 変数の REMOTE_ADDR の値と同じ |
| remoteHost | クライアントまたはリクエストを最後に送信したプロキシの完全修飾名。エンジンが (パフォーマンスの改善のため) ホスト名を解決できない、あるいは解決しようとしない場合、ドット表記の IP アドレスとなります。 |
| remoteUser | ユーザー認証がされている場合、このリクエストを出すユーザーのログイン。または、ユーザー認証がされていない場合は null。ユーザー名が後続のリクエストに送信されるかは、クライアントや認証タイプにより変わります。CGI 変数の REMOTE_USER の値と同じ。 |
| contentLength | リクエストボディの長さ (バイト) および入力ストリームで利用可能な長さ (バイト)、長さが不明な場合は -1。HTTP サーブレットの場合、CGI 変数の CONTENT_LENGTH の値と同じ。 |
| requestSessionId | クライアント指定のセッション ID、または指定がない場合は null |
| scheme | 使用するスキーマ。"http" または "https" いずれか |
| serverName | リクエストの送信先サーバーのホスト名。"Host" ヘッダーの値にある ":" の前の値です。解決済みの名前またはサーバーの IP アドレス。 |
9.10.6. レスポンス処理
9.10.6.1. 非同期レスポンス処理
このゲートウェイは常に、同期 HTTP クライアントに同期レスポンスを返すため非同期にはなりません。デフォルトでは、このゲートウェイは同期的にサービスパイプラインを呼び出し、HTTP レスポンスをゲートウェイから同期サービスレスポンスとして返します。
このゲートウェイからすると、非同期レスポンスの動作は、ゲートウェイがアクションパイプラインの非同期呼び出し (同期サービス呼び出しではない) の後に、同期 HTTP レスポンスを返しているだけのことです。サービスを非同期的に呼び出すため、同期 HTTP レスポンスの一部としてサービスレスポンスを返すことができません。そのため、ゲートウェイを設定して、非同期レスポンスを出す方法を指示する必要があります。
非同期動作は、<asyncHttpResponse> 要素を <http-gateway> に以下のように追加することで設定します。
<listeners>
<http-gateway name="Http" urlPattern="esb-cars/*">
<asyncResponse />
</http-gateway>
</listeners>
上記のように設定した場合、ゲートウェイは、HTTP ステータス 200 (OK) と、長さ 0 の HTTP レスポンスペイロードを返します。
<asyncHttpResponse> 要素に "statusCode" 属性を設定するだけで、非同期レスポンス HTTP ステータスコードを設定できます。
<listeners>
<http-gateway name="Http" urlPattern="esb-cars/*">
<asyncResponse statusCode="202" />
</http-gateway>
</listeners>
上記の長さゼロのペイロードが非同期レスポンスに返されます (デフォルト)。これは、<asyncHttpResponse> 要素に <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>
表9.13
| プロパティ | 説明 | 必須 |
|---|---|---|
| classpathResource |
レスポンスペイロードを含むクラスパスでファイルへのパスを指定します。
| 必須 |
| contentType |
classpathResource 属性が指定したペイロードデータのコンテンツ／MIME タイプを指定します。
| 必須 |
| characterEncoding |
classpathResource 属性が指定したデータの文字エンコーディング
| 任意 |
9.10.6.2. 同期レスポンス処理
デフォルトは、このゲートウェイが関連サービスを同期的に呼び出し、サービスレスポンスペイロードを HTTP レスポンスとして返します。
9.10.6.3. レスポンス情報
ゲートウェイが関連のサービスに対して 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 ゲートウェイレスポンスへマッピングされる以下のプロパティを含むことができます。
表9.14
| プロパティ | 説明 |
|---|---|
| responseCode |
ゲートウェイレスポンスに設定される HTTP レスポンス／ステータスコード (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html)
|
| contentType |
レスポンスペイロード MIME タイプ
|
| encoding |
レスポンスペイロードのコンテンツエンコーディング
|
| length |
レスポンスペイロードのコンテンツの長さ
|
| headers |
リクエストヘッダーを含む java.util.List<HttpHeader>
|
このクラスは、HttpRouter などの内部のアクションにより使用されるため、HttpResponse クラスを使用すると正常に機能し、このゲートウェイを使用してプロキシ操作が簡単に行うことができます。
9.10.6.4. ペイロードエンコーディング
レスポンスペイロードのコンテンツエンコーディングは HttpResponse インスタンス経由で設定可能です (上記参照)。
9.10.6.5. レスポンスのステータス
HTTP レスポンスステータスコードは (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html) HttpResponse インスタンス経由で設定されます (上記参照)。
9.10.6.6. レスポンスのタイムアウト
デフォルトでは、このゲートウェイは同期サービスの呼び出しが完了するまで 30,000 ミリ秒 (30 秒) 待機してから、ResponseTimeoutException を送出します。デフォルトのタイムアウトをオーバーライドするには、"synchronousTimeout" プロパティを設定する必要があります。
<listeners>
<http-gateway name="Http" urlPattern="esb-cars/*">
<property name="synchronousTimeout" value="120000"/>
</http-gateway>
</listeners>
9.10.6.7. 例外処理
サービス例外 (アクションパイプラインの例外) が ESB 設定経由で個別の 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>
9.10.7. セキュリティ処理
セキュリティ制約の設定には、ESB 設定の <http-provider> 設定セクションへ各種設定を追加します (つまり、<http-gateway> 設定で直接行うことはできません)。
<http-gateway> のセキュリティ確保のプロセスは以下のとおりです。
- 設定の <http-provider> セクションで <http-bus> を指定します。
- <http-bus> で制約を指定します。
- "busrefid" 属性を使用して <http-gateway> から <http-bus> を参照します。
注記
詳細にわたるサンプルについては、"http-gateway" Quickstart を参照してください。
9.10.8. 保護メソッドおよび許容ユーザーのロール
以下のようにログインは、<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>
上記の設定は、有効な "friend" ログインは、"secureSalesDeletes" バスで出された DELETE リクエストに必要であることが記述されています。以下のログインの表は、どの設定がいつ、ログインを強制するかを例をからめて説明しています。
表9.15
| 指定のメソッド | 指定のロール | ログイン必須 |
|---|---|---|
| No |
No
| No |
| No |
Yes
| 全メソッド向け |
| Yes |
Yes
| 指定済みのメソッドのみ |
| Yes |
No
| No。指定のメソッドはすべてブロック |
9.10.9. 認証メソッドとセキュリティドメイン
<globals> 要素内の <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>
メソッド属性は、"BASIC" (default)、"CLIENT-CERT"、"DIGEST" のいずれかになります。
注記
アプリケーションのセキュリティドメインの設定に関する詳細については、JBoss Application Server 文書を参照してください。
9.10.10. トランスポート保証
HTTP Transport Guarantee は、"transportGuarantee" 属性を使用してバス上に指定するだけで http-bus ごとに設定できます。
<http-bus busid="secureFriends" transportGuarantee="CONFIDENTIAL"> <!-- etc etc --> </http-bus>
transportGuarantee の許容値は、"CONFIDENTIAL"、"INTEGRAL"、"NONE" です。
9.11. Camel ゲートウェイ
警告
Camel Gateway はテクノロジプレビューのみを目的で提供しています。テクノロジプレビュー機能は完全対応されておらず、機能も完全ではありません。そのため、実稼働環境での利用を目的に設計されているわけではありません。これらの機能は、お客様が今後の製品イノベーションに早い段階でアクセスでき、開発プロセスで機能のテストやフィードバックの提供を行うことができるように提供されています。
Red Hat の JBoss サポートは、これらの機能のご利用時にお客様が直面され報告いただいた問題に対し、商習慣に基づく妥当な努力を払い、解決に努めます。
名前のとおり、Camel Gateway を使うと、メッセージ未対応の Camel エンドポイントを公開することができます。Apache Camel の入力機能を使い、Camel メッセージを ESB メッセージに変換して、関連の ESB サービスを呼び出します。
JBoss Enterprise Service Bus で提供される他のゲートウェイと Camel Gateway との最も大きな違いは、Camel Gateway はトランスポートの 1 つのタイプに縛られないということです。Camel が対応する様々なトランスポートをすべて活用するよう設計されているため、しっかり統合されるようにします。Camel が処理する各種トランスポートを参照するには、Camel Component 一覧 (http://camel.apache.org/components.html) を参照してください。
注記
Camel コンポーネントごとに、ライブラリ依存も変わってきます。JBoss Enterprise Service Bus には、
camel-core.jar のみが含まれており、他に必要な依存性は手動で追加する必要があります (その他の camel-* JAR やサードパーティの JAR を含む)。
jboss-esb.xml ファイルで、更新スキーマ (jbossesb-1.3.0.xsd) を使用するように宣言した場合、JBoss ESB の <providers> セクション内で、新しい <camel-provider> セクションが利用できます。
<camel-provider name="..."> <camel-bus busid="..."> <from uri="..."/> <from uri="..."/> </camel-bus> </camel-provider>
最も興味深い点は、<camel-bus> 要素内に含まれている部分です。<from uri=""/> 要素のバインドされていない数字をここに追加できます。Camel XML 設定をご存じの方は、ネーティブの Camel XML 設定での作業と全く同じであるため、この要素も使いやすいはずです。また、新しい <camel-gateway> 要素もあり、busidref 属性経由で前述したバスを参照することができます。
<camel-gateway name="..." busidref="..."/>
<camel-provider> を全く使わずに、<camel-gateway> 要素内で <from uri=""/> 要素を定義することができます。
<camel-gateway name="..."> <from uri=""/> <from uri=""/> </camel-gateway>
また、簡略表記の仕組みもあり、ゲートウェイレベルやバスレベルのいずれかで XML 属性として Camel "from" URI を 1 つ指定できます。
<camel-gateway name="..." from-uri="..."/>
<camel-bus name="..." busid="..." from-uri="..."/>
注記
<camel-bus> と <camel-gateway> レベルで定義されている Camel "from" URI は、要素の形式または簡略形式のいずれを使用しても、すべて累積される点が重要です。
この時点では、<to uri=””/> 要素はどこにあるのかと感じられるかもしれません。Camel では、あて先を 1 つ以上定義する必要があるためです。JBoss Enterprise Service Bus では、Camel "from" URI はすべて、1 つのルート (ゲートウェイとバスの他のルートに追加) と暗示的な Camel "to" URI (<camel-gateway> を割り当てる関連サービスを呼び出す) に変換されます。 ゲートウェイとバスにあるルートはすべて、最終的にこのサービスを呼び出し、同じ CamelContext 内で実行されます。このライフサイクルは CamelGateway のライフサイクルにリンクされています。
注記
このゲートウェイは、単一の "from" URI に定義可能な Camel のルートにのみ対応している点に留意してください。このゲートウェイが対応している基本的な構文は、from(endpointUri).to(esbService) です。ゲートウェイは、他の Camel コンポーネントへの仲介ルーティングを必要とするルートには対応していません。
Camel コンポーネントによっては、スケジュールされたルーティングタスクを実行します。例：HTTP コンポーネントを使用して定期的に HTTP アドレスやファイルにポールしたり、ファイルコンポーネントがファイルシステムディレクトリにポーリングしたりできます。これらのコンポーネントすべてが、ポールの頻度を設定する 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 が同期呼び出しを中断するまでに待機する時間をミリ秒で定義します。
注記
詳細情報は、http://community.jboss.org/wiki/CamelGateway の wiki ページを参照してください。
ディストリビューションの .../samples/quickstarts/camel_helloworld/ にクイックスタートもあります。
Apache Camel の詳細は、http://camel.apache.org/ の Web ページを参照してください。
9.12. 旧構成モデルからの移行
本セクションは XSD ベースではない 旧 JBoss ESB 構成モデルについて熟知している開発者を対象としています。
旧構成モデルは ESB コンポーネント付きの自由形式の XML 構成を使用し、その設定を
org.jboss.soa.esb.helpers.ConfigTree のインスタンス経由で受け取っていました。新しい構成モデルは XSD ベースとなりますが、基礎となるコンポーネント構成パターンはいまだ org.jboss.soa.esb.helpers.ConfigTree のインスタンス経由になります。つまり現在、XSD ベースの構成は ConfigTree スタイルの設定にマッピング/変換されるということになります。
旧モデルの使用に慣れている開発者の方々は次の点に注意して頂く必要があります。
- 新しい構成モデルに関する全ドキュメントをお読みください。 旧モデルの知識に基づいて新しい構成を推測で理解することはできません。
- 新しい構成で自由形式のマークアップがサポートされる場所は <property> エレメント/タイプのみになります。 このタイプは <provider>、<bus>、<listener> のタイプ (およびサプタイプ) で許可されます。 ただし、<property> ベースの自由形式マークアップが ConfigTree 設定にマッピングされる場所は <property> が <action> で存在する場所のみになります。 この場合、<property> のコンテンツはターゲットの ConfigTree <action> にマッピングされます。 しかし、<action> で自由形式の子コンテンツを持つ <property> エレメントが複数ある場合、 このコンテンツはすべてターゲット ConfigTree <action> 上で連結されます。
- 新しいリスナー/アクションのコンポーネントを開発する際はこれらのコンポーネントが依存する ConfigTree ベースの構成が新しい XSD ベースの設定からマッピング可能であることを必ず確認してください。この例としては、 ConfigTree 構成モデル内でどのようにその設定をリスナーノード上で属性を使いリスナーコンポーネントに提供することが決定できるか、またはリスナー構成内の子ノードに基づいて提供することが決定できるかを示す例です。<listener> コンポーネント上にある自由形式構成のこのタイプは XSD から ConfigTree へのマッピングではサポートされません。 つまり、上記の例の子コンテンツは XSD 設定から ConfigTree スタイルの設定にはマッピングされないということです。実際、XSD 設定は <property> に存在しない限り任意のコンテンツを受け取りません。また、<property> に存在する場合でも (<listener> 上)、 マッピングコードによって無視されます。
9.13. 構成
コア内のコンポーネントはすべてその設定パラメータを 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;
}
この JBossESB バージョン内にあるのは
org.jboss.soa.esb.parameters.ParamFileRepository の実装 1 つのみなります。1 ファイルからのパラメータのロードが可能であることを期待します。使用する実装は org.jboss.soa.esb.paramsRepository.class プロパティを使って上書きが可能です。
注記
ESB 設定ファイルは Eclipse または何らかの XML エディターを使って作成することをお勧めします。JBossESB 設定情報はアノテーション付き XSD でサポートされ、基本的なエディターを使うと作成が容易になるはずです。
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.