JBoss Enterprise SOA Platform 4.3 プログラマーガイド

JBoss Enterprise SOA Platform
4.3
プログラマーガイド
JBoss Enterprise SOA Platform 4.3 CP02 を使用する開発者向けガイド
エディッション 1.2
Red Hat Documentation Group
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
JBoss Enterprise SOA Platform 4.3 CP02 を使用する開発者向けガイド
エディッション 1.2
Red Hat Do cumentatio n Gro up
法律上の通知
Copyright © 2008 Red Hat, Inc..
T his document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported
License. If you distribute this document, or a modified version of it, you must provide attribution to Red
Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be
removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section
4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo,
and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux ® is the registered trademark of Linus T orvalds in the United States and other countries.
Java ® is a registered trademark of Oracle and/or its affiliates.
XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States
and/or other countries.
MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other
countries.
Node.js ® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or
endorsed by the official Joyent Node.js open source or commercial project.
T he OpenStack ® Word Mark and OpenStack Logo are either registered trademarks/service marks or
trademarks/service marks of the OpenStack Foundation, in the United States and other countries and
are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or
sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
概要
このガイドには JBoss Enterprise SOA Platform 4.3 CP02 を使用して開発を行うプログラマー向けの情報
が記載されています。
目次
目次
.前書き
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6. . . . . . . . . .
1. 本書の表記規則
6
1.1. 書体の表記規則
6
1.2. 引用文の表記規則
7
1.3. 注記および警告
8
2. フィードバック
8
. . .1章
第
. . . .ESB
. . . . .(Enterprise
. . . . . . . . . . . .Service
. . . . . . . .Bus)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
............
1.1. ESB とは?
10
1.2. 実際に ESB を使用できる場面とは?
10
. . .2章
第
. . . .JBoss
. . . . . . ESB
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
............
2.1. Rosetta
14
2.2. JBossESB コアの要約
15
. . .3章
第
. . . サービスとメッセージ
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
............
3.1. サービス
17
3.2. メッセージ
19
3.2.1. ヘッダー
22
3.2.2. コンテキスト
25
3.2.3. 不良 (Fault)
25
3.2.4. ボディ
26
3.2.5. ボディに対する拡張
27
3.2.6. 添付
28
3.2.7. プロパティ
29
3.2.8. MessageFactory
30
3.2.8.1. MessageT ype.JAVA_SERIALIZ ED
31
3.2.8.2. MessageT ype.JBOSS_XML
31
. . .4.章
第
. . .サービスの構築と使用
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
...........
4.1. Listener、Notifier/Router、および Action
33
4.1.1. Listener
33
4.1.2. Router
33
4.1.3. Notifier
33
4.1.4. Action とメッセージ
37
4.1.5. 応答を処理する
38
4.1.6. Action 処理中のエラーの扱い方
38
4.2. メタデータとフィルタ
39
4.3. サービスとは
40
4.3.1. ServiceInvoker
41
4.3.2. サービスと ServiceInvoker
42
4.3.3. InVM トランスポート
42
4.3.3.1. inVM Scope
43
4.3.3.2. 処理された InVM
44
4.3.3.3. トランザクションセマンティック
44
4.3.3.4. ロックステップ配信
44
4.3.3.5. 負荷分散
45
4.3.3.6. 「値で渡す」と「参照で渡す」
45
4.4. サービス契約定義
46
. . .5章
第
. . . .その他のコンポーネント
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. .8. . . . . . . . . .
5.1. メッセージストア
48
5.2. データ変換
48
1
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
5.3. コンテンツベースルーティング
5.4. レジストリ
49
49
. . .6章
第
. . . .サンプル
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
............
6.1. メッセージの使用方法
50
6.1.1. メッセージの構造
50
6.1.2. サービス
51
6.1.3. ペイロードの展開
52
6.1.4. クライアント
53
6.1.5. コツとヒント
53
. . .7章
第
. . . .高度なトピック
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
............
7.1. フェールオーバーと負荷分散のサポート
55
7.1.1. サービス、 EPR、 リスナー、 アクション
55
7.1.2. 複製されたサービス
56
7.1.3. プロトコルのクラスタリング
58
7.1.4. クラスタリング
60
7.1.5. チャンネルのフェールオーバーと負荷分散機能
61
7.1.6. メッセージ再配信
63
7.2. サービスのスケジュール
64
7.2.1. Simple Schedule
64
7.2.2. Cron Schedule
65
7.2.3. Scheduled Listener
65
7.2.4. 設定例
66
7.2.5. Quartz Scheduler のプロパティ設定
67
. . .8章
第
. . . .耐障害性と信頼性
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
............
8.1. 障害の分類
69
8.1.1. JBossESB と不良モデル
70
8.1.2. 障害検出機能と障害推測機能
71
8.2. 信頼性の保証
72
8.2.1. メッセージの損失
72
8.2.2. エンドポイントの障害を疑う
73
8.2.3. サポート対象となるクラッシュ障害モード
73
8.2.4. コンポーネント固有
73
8.2.5. ゲートウェイ
74
8.2.6. ServiceInvoker
74
8.2.7. JMS ブローカー
74
8.2.8. アクションパイプライン
74
8.3. 推奨
74
. . .9章
第
. . . .サービス設定の定義
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
............
9.1. 概要
76
9.2. Providers
76
9.3. サービス
77
9.4. トランスポート固有タイプの実装
79
9.5. FT P プロバイダ構成
82
9.6. FT P リスナーの構成
84
9.6.1. 読み取り専用 FT P リスナー
84
9.7. 旧構成モデルからの移行
85
9.8. 構成
86
. . .10章
第
. . . . .Web
. . . . .サービスサポート
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
............
10.1. JBossWS
87
. . .11章
第
. . . . .事前定義されたアクション
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
............
11.1. トランスフォーマとコンバータ
88
2
目次
11.1.1. ByteArrayT oString
11.1.2. ObjectInvoke
11.1.3. ObjectT oCSVString
11.1.4. ObjectT oXStream
11.1.5. XStreamT oObject
11.1.6. SmooksT ransformer
11.1.7. SmooksAction
11.1.8. PersistAction
11.2. ビジネスプロセス管理
11.2.1. jBPM - BpmProcessor
11.3. スクリプト
11.3.1. GroovyActionProcessor
11.3.2. ScriptingAction
11.4. サービス
11.4.1. EJBProcessor
11.5. ルーティング
11.5.1. Aggregator
11.5.2. EchoRouter
11.5.3. HttpRouter
11.5.3.1. JBoss Remoting HttpRouter
11.5.3.2. Apache Commons HttpRouter
11.5.4. JMSRouter
11.5.5. ContentBasedRouter
11.5.6. StaticRouter
11.5.7. StaticWireT ap
11.6. Notifier
11.7. Webservices/SOAP
11.7.1. JBoss Web サービス SOAPProcessor
88
88
89
89
90
91
93
95
95
96
98
98
99
100
100
102
102
102
102
102
103
104
104
105
106
107
111
111
. . . . . . Message
"ESB
. . . . . . . . . . Aware"
. . . . . . . . Webservice
. . . . . . . . . . . . .Endpoints
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
.............
. . . . . サービスエンドポイントデプロイメント
Web
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
.............
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
WSDL
.............
. . . . . . Annotation
JAXB
. . . . . . . . . . . . Introductions
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
.............
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
アクション設定
.............
.クイックスタート
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
.............
11.7.2. SOAPCLIENT - WISE
112
11.7.3. SOAPClient - SOAPUI
114
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
エンドポイント操作の仕様
.............
. . . . . . .要求メッセージの構築
SOAP
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
.............
. . . . . . .応答メッセージ消費
SOAP
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
.............
.HttpClient
. . . . . . . . . . .設定
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
.............
11.8. Miscellaneous
118
. . .12章
第
. . . . .カスタムアクションの開発
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
.............
12.1. プロパティを使用したアクションの設定
120
. . .13章
第
. . . . .コネクタおよびアダプタ
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
.............
13.1. はじめに
122
13.2. ゲートウェイ
122
3
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
13.2.1. ゲートウェイデータマッピング
13.2.2. ゲートウェイデータマッピングの変更方法
13.3. JCA を介した接続
13.3.1. 構成
13.3.2. 標準アクティベーションプロパティのマッピング
123
123
124
125
126
. . . . . . Annotation
JAXB
. . . . . . . . . . . . Introduction
. . . . . . . . . . . . . .の設定を作成する
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
.............
.サービス指向アーキテクチャの概要
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
.............
B.1. SOA とは
132
B.2. SOA の基本
133
B.3. SOA の利点
134
B.3.1. 相互運用性
134
B.3.2. 効率性
134
B.3.3. 標準化
135
B.3.4. ステートフルおよびステートレスサービス
135
B.4. JBossESB と SOA との関係
136
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
リビジョン履歴
.............
4
目次
5
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
前書き
1. 本 書 の 表 記 規 則
本ガイドでは、一部の単語や語句を強調して、特定の情報に対する読者の注意を促すために、以下のよう
な表記規則を採用しています。
本ガイドの PDF および紙書籍版では、Liberation フォントセットの書体を使用しています。また、
Liberation フォントセットがご使用のシステムにインストールされている場合には、HT ML 版もこの書体
で表示されます。インストールされていない場合には、別の対応する書体で表示されます。なお、Red
Hat Enterprise Linux 5 以降のバージョンでは、Liberation フォントセットがデフォルトでインストールさ
れる点に注意してください。
1.1. 書体の表記規則
本ガイドでは、特定の単語や語句に対する注意を促すために、4 つの書体表記規則を採用しています。こ
れらの表記規則および適用される状況は、以下のとおりです。
太字の等幅フォント
シェルコマンド、ファイル名、パスなど、システムへの入力を強調するために使用します。また、キー名
やキーの組み合わせを強調するのにも使用します。以下が例となります。
作業ディレクトリ内の m y_next_bestselling_novel というファイルの内容を表示する
には、シェルプロンプトで cat m y_next_bestselling_novel というコマンドを入力し
て Enter キーを押し、そのコマンドを実行します。
上記の例には、ファイル名、シェルコマンド、キー名が含まれており、すべて太字の等幅フォントで表示
されていますが、文脈で区別することができます。
キーの組み合わせは、プラス記号 (+) で各キーがつながれているので、個別のキーと区別することができ
ます。以下が例となります。
Enter を押してコマンドを実行します。
Ctrl+Alt+F2 を押して仮想ターミナルに切り替えます。
第 1 の例では、押すべき特定のキー名が強調されています。第 2 の例では、3 つのキーを同時に押す、
キーの組み合わせが強調されています。
ソースコードを記載する場合、その段落で言及されるクラス名、メソッド、関数、変数名、戻り値は上記
のように 太字の等幅フォント で表示されます。以下が例となります。
ファイル関連のクラスには、filesystem (ファイルシステム)、file (ファイル)、dir
(ディレクトリ) などがあります。各クラスにそれぞれ独自のパーミッションセットが関連付
けられています。
太字の可変幅フォント
この書体は、アプリケーション名、ダイアログボックスのテキスト、ラベル付きボタン、チェックボック
ス/ラジオボタンのラベル、メニュータイトル、サブメニュータイトルなど、システムで表示される単語や
語句であることを示します。以下が例となります。
メインメニューバーから システム → 設定 → マウス の順で選択し、マウスの設定 を起動
します。全般 タブで 左利き のラジオボタンを選択して 閉じる をクリックし、マウスの主
6
前書き
ボタンを左から右へ切り替えます (左利きのユーザーが使用するのに適切な設定に変更しま
す)。
gedit ファイルに特殊文字を入力するには、メインのメニューバーから アプリケーション
→ アクセサリ → 文字マップ の順に選択します。次に 文字マップ のメニューバーから 検
索 → 検索 … の順に選択して 検索 フィールドに文字名を入力し、次を検索 をクリックしま
す。検索対象の文字が 文字テーブル に強調表示されます。その文字をダブルクリックして
コピーする文字列 のフィールドに表示されたら、コピー ボタンをクリックします。この後
に編集中のドキュメントに戻り、gedit のメニューバーから 編集 → 貼り付け の順で選択し
ます。
上記のテキストには、アプリケーション名、システム全体のメニュー名と項目、アプリケーション固有の
メニュー名、GUI インターフェースで使用されているボタンおよびテキストが含まれており、これらはす
べて、太字の可変幅フォントで表示されていますが、文脈で区別することができます。
太字斜体の等幅フォント または 太字斜体の可変幅フォント
太字の等幅フォントおよび太字の可変幅フォントに斜体を使用した場合には、いずれも置き換え可能な可
変テキストであることを意味します。斜体は、記載されている通りには入力しないテキスト、あるいは状
況によって変化するテキストを示します。以下が例となります。
ssh を使用してリモートマシンに接続するには、シェルプロンプトで ssh
username@ domain.name と入力します。リモートマシンが exam ple.com で、そのマシン
上のユーザー名が john である場合には、ssh john@ exam ple.com と入力してください。
m ount -o rem ount file-system のコマンドは、指定したファイルシステムを再マウン
トします。たとえば、/hom e ファイルシステムを再マウントするコマンドは m ount -o
rem ount /hom e となります。
現在インストール済みのパッケージのバージョンを確認するには、rpm -q package のコマ
ンドを使用します。その結果、次のような出力が返されます: package-version-release
ユーザー名、ドメイン名、ファイルシステム、パッケージ、バージョン、およびリリースが太字のイタ
リック体で表示されている点に注意してください。これらの語句はプレースホルダーで、コマンドを発行
する際に入力するテキストまたはシステムによって表示されるテキストのいずれかです。
斜体は、著作物のタイトルを表すという標準的な用途の他に、重要な用語の初出時にも使用されます。以
下が例となります。
Publican は DocBook の出版システムです。
1.2. 引用文の表記規則
端末の出力とソースコードは、周囲のテキストとは視覚的に区切られて表示されます。
端末に送信される出力は、ローマン体の等幅フォント を使用して以下のように表示されます。
books
books_tests
Desktop
Desktop1
documentation
downloads
drafts
images
mss
notes
photos
scripts
stuff
svgs
svn
ソースコードの表示にも ローマン体の等幅フォント が使用されますが、以下のような構文強調表示が追
加されます。
7
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
package org.jboss.book.jca.ex1;
import javax.naming.InitialContext;
public class ExClient
{
public static void main(String args[])
throws Exception
{
InitialContext iniCtx = new InitialContext();
Object
ref
= iniCtx.lookup("EchoBean");
EchoHome
home
= (EchoHome) ref;
Echo
echo
= home.create();
System.out.println("Created Echo");
System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
}
}
1.3. 注記および警告
本ガイドでは、見落としがちな情報に注意を促すために、次にあげる 3 つの視覚的スタイルを使用してい
ます。
注記
注記には、対象のタスクに関するヒント、ショートカット、その他のアプローチなどを記載してい
ます。注記を無視しても、悪影響はありませんが、作業を効率的に行うためのコツを見逃してしま
う可能性があります。
重要
重要の欄には、現行セッションのみに適用される設定の変更や、更新を適用するのに再起動が必要
なサービスなど、見落としがちな情報を記載しています。「重要」と記載された事項を無視して
も、データ損失などには至りませんが、作業が思ったようにスムーズに進まなくなる可能性があり
ます。
警告
警告は、無視しないでください。警告を無視すると、データ損失が発生する可能性が非常に高くな
ります。
2. フ ィ ー ド バ ッ ク
本ガイドに誤植を見つけられた場合や本ガイドの改善案をお持ちの場合はぜひお知らせください。
Bugzilla http://bugzilla.redhat.com/bugzilla/ にて、 Product には JBoss Enterprise SOA Platform. を選
びレポートの提出をお願いいたします。
バグレポートを提出される場合は、 そのガイドの識別子となる SOA_ESB_Programmers_Guide を必ず
8
前書き
明記して頂くようお願いします。
ドキュメントに関する改善のご意見についてはできるだけ具体的にお願いいたします。 エラーを発見され
た場合は、 セクション番号および該当部分の前後の文章も含めてご報告頂くと照合が容易になります。
9
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
第 1章 ESB (Enterprise Service Bus)
1.1. ESB と は ?
ESB (Enterprise Service Bus、エンタープライズサービスバス) は、次世代の EAI (Enterprise Application
Integration、エンタープライズアプリケーション統合) と考えられています。ESB は、既存の EAI ソ
リューションに似た機能を提供しますが、1 つのベンダーに縛られることがありません。
従来の EAI スタックは以下で構成されています。
ビジネスプロセスモニタリング
統合開発環境
ヒューマンワークフローユーザーインターフェイス
ビジネスプロセス管理
コネクタ
トランザクションマネージャ
セキュリティ
アプリケーションコンテナ
メッセージングサービス
メタデータレポジトリ
ネーミングとディレクトリサービス
分散コンピューティングアーキテクチャ
As with EAI systems, ESB is not about business logic – that is left to higher levels. It is about
infrastructure logic. Although there are many different definitions of what constitutes an ESB, what
everyone agrees on now is that an ESB is part of an SOA infrastructure. However, SOA is not simply a
technology or a product: it's a style of design, with many aspects (such as architecture, methodology and
organisation) unrelated to the actual technology. But obviously at some point it becomes necessary to
map the abstract SOA to a concrete implementation and that's where the ESB comes in to play.
SOA の原理や ESB のアーキテクチャについては 付録B サービス指向アーキテクチャの概要 を参照してく
ださい。
1.2. 実 際 に ESB を 使 用 で き る 場 面 と は ?
JBossESB を役立たせることができる実例をいくつか以下に図で示します。 これらは相互運用性のない
JMS 実装を使用しているもの同士の通信に固有の例となりますが、 その原理は汎用であり FT P や HT T P
などの他のトランスポートにも適用が可能です。
1 番目の図ではメッセージングの待ち行列が関与しない 2 システム間のシンプルなファイル移動を示して
います。
10
第1章 ESB (Enterprise Service Bus)
図 1.1 メッセージキューイングを用いない 2 つのシステム間の簡単なファイル移動
次の図では同じシナリオに JBossESB を使用することによってどのように変換を投入できるかを示してい
ます。
図 1.2 メッセージキューイングを用いずに変換を使用する 2 つのシステム間の簡単なファイル移動
次の一連の例では、待ち行列システムを使用します (つまり JMS 実装)。
図 1.3 メッセージキューイングを使用
以下の図では同じ状態で変換とキューイングを示します。
11
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
図 1.4 変換とメッセージキューイングを使用
JBossESB は複数パーティのシナリオ以外でも使用できます。たとえば、 以下の図ではファイルシステム
を使った ESB 経由の基本的なデータ変換を示しています。
図 1.5 ファイルシステムを使用した ESB による基本的なデータ変換
最後のシナリオも変換と待ち行列システムを使った単一パーティの例になります。
12
第1章 ESB (Enterprise Service Bus)
図 1.6 変換と待ち行列システムを使った単一パーティの例
次の章では JBossESB 内の中核となるコンセプトについて、 また SOA ベースのアプリケーション開発を
行う場合にそのコンセプトをどのように使用できるかについて見ていきます。
13
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
第 2章 JBoss ESB
2.1. Rosetta
JBoss Enterprise SOA Platform の中心は、ミッションクリティカルなサイトで 3 年以上商業的にデプロ
イされている ESB である Rosetta です。これらのデプロイメントには、高度に異機種混合な環境が含ま
れます。このような例として z/OS、DB2、および Oracle データベースが実行されている IBM メインフ
レーム、Windows および Linux サーバー、広範なサードパーティアプリケーション、企業の IT インフラ
ストラクチャの外部にあるサードパーティサービスなどがあります。
図 2.1 Rosetta アーキテクチャ
図ではプロセッサクラス群は引き起こされるイベントで処理を行う役割を担うコア内のアクションクラス
群を参照します。
異なるアプリケーション、サービス、コンポーネントを相互運用する理由はたくさんあります。最も一般
的な理由は、新しいデプロイメントでレガシーシステムを活用することです。こうした構成要素同士の対
話は同期的また非同期的にも発生する場合があります。
Rosetta はこうしたデプロイメントを容易にするだけでなく、以下の目的を足すためにインフラストラク
チャと一連のツールを提供するために開発されました。
さまざまなトランスポートのメカニズムで動作させる設定が簡単に行えます (email や JMS など)。
汎用目的のオブジェクトリポジトリを提供します。
交換可能なデータ変換のメカニズムを実現します。
フレームワークを介した対話、ビジネスおよび処理イベントのログ記録をサポートします。
トランスポートおよびトリガメカニズムからビジネスロジックを簡単に分離できます。
ビジネスロジックとデータ変換に関する柔軟なプラグインを可能にする
将来のユーザーがフレームワークに含まれる標準ベースクラスを簡単に置き換えたり、拡張したりで
きる
トランスポートおよびトリガメカニズムを認識できないカスタム「アクションクラス」のトリガを有
効にする
14
第2章 JBoss ESB
重要
JBossESB ソース内には org.jboss.internal.soa.esb と org.jboss.soa.esb の 2 つの
ツリーがあります。 コンテンツは予告なしに変更されるた
め、org.jboss.internal.soa.esb パッケージ内にあるものはすべてその使用を制限してく
ださい。 org.jboss.soa.esb は廃止予定ポリシーの範囲となります。
2.2. JBossESB コ ア の 要 約
Rosetta は 4 つのアーキテクチャコンポーネント上に構築されます。
メッセージリスナおよびメッセージフィルタリングコード
Sm ooksAction アクションプロセッサを使用したデータ変換
コンテンツベースルーティングサービス
ESB 内で交換されるメッセージやイベントを保存するためのメッセージリポジトリ。
これらの機能は本ガイドの後半に記載されているビジネスクラス、 アダプタ、 プロセッサのセットを通
じて提供されます。 クライアントとサービス間の交信は JMS やフラットなファイルシステム、 email な
どさまざまな手段で対応されます。
JBoss SOA Platform デプロイメントの例を以下に示します。この図は次のセクションで説明します。
図 2.2 JBoss SOA Platform デプロイメントの例
15
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
重要
LDAP サーバーなどの 図2.2「JBoss SOA Platform デプロイメントの例」 の一部のコンポーネント
はオプションのコンポーネントであり、初期状態では提供されないかもしれません。 また、 上図
のプロセッサおよびアクションの違いは単に着信イベント (メッセージ) が基盤となる ESB を起動
して高度なレベルのサービスを呼び出す場合のコンセプトをわかりやすく説明するためのもので
す。
次の章では、JBoss SOA Platform 内のさまざまなコンポーネントを紹介し、コンポーネント同士の対話
方法やそのコンポーネントを使ってどのようにサービス指向アプリケーションを開発するかについて説明
します。
16
第3章 サービスとメッセージ
第 3章 サービスとメッセージ
SOA の原理に基づき、JBoss ESB 内ではすべてがサービスまたはメッセージと見なされます。
サービスはビジネス論理や統合ポイントをレガシーシステムでカプセル化します。
メッセージとは、クライアントとサービスが互いに通信する方法のことです。
次のセクションより、サービスとメッセージがどのようにサポートされるかを説明します。
3.1. サ ー ビ ス
JBoss ESB の Service はメッセージを順番に処理する Action クラスの一覧として定義されます。 この
Action クラスの一覧は アクションパイプライン と呼ばれます。 またサービスは Listeners の一覧も定義
することができます。 リスナはサービスの着信ルーターのように動作し、 アクションパイプラインに
メッセージをルーティングします。
下記は、メッセージの内容をコンソールに出力する単一サービスを定義する、大変簡単な設定になりま
す。
例 3.1 メッセージの内容をコンソールに出力する簡単なサービスの例
<?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" invmScope="GLOBAL">
<services>
<service category="Retail" name="ShoeStore"
description="Acme Shoe Store Service">
<actions>
<action name="println"
class="org.jboss.soa.esb.actions.SystemPrintln" />
</actions>
</service>
</services>
</jbossesb>
A Service has category and name attributes. When the JBoss ESB deploys the Service it uses these
attributes to register the Service's listeners as endpoints in the Service Registry. Clients can invoke the
Service using the class ServiceInvoker.
例 3.2 クライアントからサービスを呼び出す
ServiceInvoker invoker = new ServiceInvoker(“Retail”, “ShoeStore”);
Message message = MessageFactory.getInstance().getMessage();
message.getBody().add(“Hi there!”);
invoker.deliverAsync(message);
T he ServiceInvoker uses the Service Registry to lookup the available Endpoint addresses for the
service "Retail:ShoeStore". It takes care of all the details of getting the message from the Client to one of
the available Service Endpoints. T he message transport process is completely transparent to the client.
17
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
T he Endpoint addresses made available to the ServiceInvoker will depend on the list of listeners
configured on the Service, such as JMS, FT P or HT T P. No listeners are configured on the Service in the
above example, but its InVM listener has been enabled using invm Scope="GLOBAL". T he InVM
transport is a new ESB feature in the SOA Platform 4.3 release that provides communication between
services running on the same JVM. 「 InVM トランスポート」 contains more information about this
feature.
追加のエンドポイントを有効にするには、明示的にリスナの設定をサービスに追加する必要があります。
JBoss ESB は以下 2 つのリスナ設定をサポートします。
ゲートウェイリスナ
T hese listener configurations provide a Gateway Endpoint. T hese Endpoint types provide a point of
entry for messages from outside of your JBoss ESB deployment. T hey also have the responsibility
for normalizing the message payload by wrapping it into an ESB Messagebefore shipping it to the
Service's Action Pipeline.
ESB 対応リスナ
ESB 認識リスナの設定は、ESB 認識エンドポイントを提供します。エンドポイントタイプは、ESB 認
識コンポーネント間で ESB メッセージを交換するため使用されます。
注記
ESB メッセージは org.jboss.soa.esb.m essage.Message の実装で、「メッセージ」 に詳
細な説明があります。ESB 対応コンポーネントは ESB メッセージに対応します。
T he Endpoints are configured for the service are configured in the same configuration file as the
services other details. T he transport level details are defined by adding a <providers> section. A
reference to the provider is then added as a <listener>.
In the following example we have added a <jms-provider> section that defines a single <jms-bus> for
the Shoe Store JMS Queue. T his is then referenced in the <jms-listener> defined on the Shoe Store
Service.
18
第3章 サービスとメッセージ
例 3.3 上記の ShoeStore Service 例に追加される 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" invmScope="GLOBAL">
<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" invmScope="GLOBAL"
description="Acme Shoe Store Service">
<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>
T he Shoe Store service can now be accessed using either of two Endpoints, the InVM Endpoint and the
new JMS Gateway Endpoint. For performance reasons the ServiceInvoker will always try to use a
Service's local InVM Endpoint in preference to other Endpoint types if one is available.
3.2. メ ッ セ ー ジ
JBossESB 内のクライアントとサービス間の対話はすべてメッセージの交換によって発生します。疎結合
を促進するため、メッセージ交換パターンを使用した開発が推奨されます。要求と応答は、必要な場合に
インフラストラクチャやアプリケーションによって相互に関連付けられる、独立したメッセージでなけれ
ばなりません。このようにして構築されたアプリケーションは耐障害性が高く、デプロイメントやメッ
セージ配信の要件に対して開発者はより柔軟に対応できるようになります。
サービスの疎結合やロバストな SOA アプリケーションを確保するため、次のガイドラインが推奨されま
す。
1. 要求応答アーキテクチャでなく一方向メッセージを使用します。
2. 交換されたメッセージ内で規定の定義を維持します。後で実装の変更が大変難しくなるため、バッ
クエンド実装の選択を公開するサービスインターフェイスを定義しないようにしてください。
3. メッセージペイロードに拡張可能なメッセージ構造を使用します。これにより、変更をバージョン
19
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
化して後方互換性を維持することができます。
4. 極端に粒度が細かいサービスは開発しないようにしてください。これは、簡単に環境の変化に対応
できないような非常に複雑なアプリケーションが必要になることが多いためです。SOA のパラダイ
ムは分散オブジェクトではなく、1 つのサービスです。
要求と応答を持つ一方向メッセージ配信パターンは、応答がメッセージ内でエンコードされる応答の送信
先に関する情報を必要とします。この情報は、メッセージボディ (ペイロード) に存在しアプリケーション
によって処理される場合と、最初の要求メッセージの一部として存在し ESB インフラストラクチャに
よって処理される場合があります。
SOAP の構造と似ているメッセージの概念が ESB の中心となります。
例 3.4 ESB メッセージスキーマのサンプル
<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>
以下に示すように図を用いてその基本的なメッセージの構造を表すことができます。 本セクションの後半
では、 これら各コンポーネントについて詳しく見ていくことにします。
図 3.1 メッセージの基本構造
UML では、メッセージの構造を次のように表記できます。
20
第3章 サービスとメッセージ
図 3.2 UML で表記されるメッセージ構造
各メッセージは org.jboss.soa.esb.m essage.Message インターフェイスの実装です。このパッ
ケージには、メッセージ内の各種フィールドのインターフェイスが同梱されます。
例 3.5 org.jboss.soa.esb.m essage.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 ();
}
アプリケーションとサービスの観点では、メッセージペイロードはボディ、添付、プロパティの組み合わ
せになります。
警告
現時点では、Properties や Attachments の使用は推奨されません。
具体化する一般的な概念については現在再評価中で、将来のリリースで大幅に変更される可能性が
あります。
Properties と Attachments のデータがメッセージBody の一部として含まれることが推奨されま
す。
ペイロードの UML 表記を以下に示します。
21
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
図 3.3 メッセージペイロードの UML 表記
3.2.1. ヘッダー
ヘッダーにはメッセージのルーティングとアドレス指定の情報が、EPR (Endpoint Reference、エンドポ
イント参照) およびメッセージを一意に識別する情報として格納されます。JBossESB は、W3C の WSAddressing を基にしたアドレス指定スキームを使用します。
ヘッダーと各種 EPR の関係を UML で表記すると次のようになります。
図 3.4 UML で表記されたヘッダーと ERP の関係
サービスを開発し使用する際、ヘッダーの役割について考慮しなければなりません。たとえば、要求と応
答に基づいた同期の対話パターンが必要な場合、ReplyT o フィールドの設定が求められます。設定がな
22
第3章 サービスとメッセージ
い場合はデフォルトの EPR が使用されます。要求／応答の場合でも、指定があれば応答は元の送信側に
戻る必要はありません。一方向メッセージ (応答なし) を送信する場合、ReplyT o フィールドを設定して
も無視されるため、設定しないようにしてください。
ReplyT o や FaultT o EPR は、物理 EPR (JMS-EPR など) ではなく、常に論理 EPR を使用するようにして
ください。論理 EPR とは、ESB サービス／エンドポイントの名前とカテゴリを指定する EPR のことで
す。論理 EPR には物理アドレス指定の情報は含まれません。
論理 EPR は EPR ユーザー（通常 ESB ですが、そうとは限りません）の能力を想定しないため、論理
EPR の選択が奨励されます。論理 EPR のクライアントは EPR で提供されるサービス名やカテゴリの詳細
を使用して、呼び出しが行われる時に（適切なアドレス指定情報を取得する場合など）サービスやエンド
ポイントに対する物理エンドポイントの詳細をルックアップできます。クライアントは適切な物理エンド
ポイントタイプを選択することもできます。
注記
メッセージヘッダーはエンドポイント間の送信では不変です。
インターフェイスを使用してヘッダーを変更することはできますが、JBossESB はそのような変更
を無視します。今後のリリースでは、混同しないよう API によってこのような変更ができなくなる
可能性があります。このようなルールは WS-Adressing の基準に基づいています。
例 3.6 org.jboss.soa.esb.m essage.Header インターフェイス
public interface Header
{
public Call getCall ();
public void setCall (Call call);
}
メッセージヘッダーの内容は org.jboss.soa.esb.addressing.Call クラスのインスタンスに格納
されます。
23
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
例 3.7 org.jboss.soa.esb.addressing.Call
public class Call
{
public Call ();
public Call (EPR epr);
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 setAction (URI uri);
public URI getAction () throws URISyntaxException;
public void setMessageID (URI uri);
public URI getMessageID () throws URISyntaxException;
public void copy (Call from);
}
org.jboss.soa.esb.addressing.Call は一方向パターンと要求返答対話パターンの両方をサポー
トします。
表 3.1 org.jboss.soa.esb.addressing.Call プロパティ
プロパ
ティ
タイプ
必須
説明
To
EPR
Yes
このメッセージの受信対象となる受信側のアドレスです。
From
EPR
No
メッセージ発信元のエンドポイント参照です。
ReplyT o
EPR
No
このメッセージへの返答を受信する所定の受信側を識別する
EPR です。
FaultT o
EPR
No
このメッセージに関する不良を受信する所定の受信側を識別す
るエンドポイント参照です。
Action
URI
Yes
このメッセージによって暗示されるセマンティックを一意的で
不透明に識別する識別子です。
MessageI
D
URI
場合による
このメッセージを一意的に識別する URI です。
ReplyT o
ReplyT o プロパティは、このメッセージへの返答を受信する所定の受信側を識別する EPR です。返答が
予期される場合は、メッセージヘッダーに ReplyT o が含まれるようにしなければなりません。
24
第3章 サービスとメッセージ
JBossESB は、各トランスポートタイプに対してデフォルトの ReplyT o 値をサポートしています。応答
の必要があるにも関わらず ReplyT o プロパティが設定されていない場合、デフォルトの値が使用されま
す。デフォルト値の一部は、システム管理者による JBossESB の設定が必要となります。
表 3.2 トランスポートによるデフォルトの ReplyT o
トランス
ポート
ReplyT o
JMS
元の要求の配信に使用した名前の末尾に _reply を追加した名前を持つキューです。
JDBC
元の要求の配信に使用した名前の末尾に _reply_table を追加した名前を持つデータベー
スにあるテーブルです。応答テーブルには、要求テーブルと同じ列定義が必要となりま
す。
ファイル
ローカルファイルとリモートファイル共に管理的な変更は必要ありません。元の送信側
のみが応答を受け取るようにするため、応答は固有のサフィックスで要求と同じディレ
クトリに書き込まれます。
FaultT o
FaultT o は、このメッセージに関連する障害を受信する所定の受信側を識別する EPR です。障害について
は、「不良 (Fault)」 の説明を参照してください。
JBossESB はすべての不良を受信メッセージの FaultT o プロパティ内の EPR にルーティングしま
す。FaultT o が設定されていない場合、JBossESB は ReplyT o プロパティと From プロパティを順に
チェックします。すべてのフィールドをチェックしても有効な EPR が取得できなかった場合は、エラー
がコンソールに出力されます。
送信側が不良メッセージを受信できない場合やすべての応答を必要としない場合、FaultT o プロパティを
設定する必要はありませんが、DeadLetter Queue Service EPR を FaultT o として使用することが推奨さ
れます。使用しない場合、発生する不良はすべて保存され、後に処理されます。
MessageID
MessageID プロパティは各メッセージを一意に識別するため使用される URI です。
異なるメッセージが同じ MessageID を持つことはできませんが、再送信されるメッセージは元のメッ
セージと同じ MessageID を使用することができます。
返答が予期される場合や、ReplyT o プロパティと FaultT o プロパティのいずれかが設定されている場合
は、MessageID の設定が必要となります。
3.2.2. コンテキスト
コンテキストには、トランザクションコンテキストやセキュリティコンテキストなどのセッション関係の
情報が格納されます。今回の JBossESB リリースは、ユーザー拡張のコンテキストをサポートしていませ
ん。5.0 リリースでサポート対象となる予定です。
3.2.3. 不良 (Fault)
不良はエラー情報を伝達するために使用されます。情報はボディー内に表示されます。
25
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
例 3.8 T he org.jboss.soa.esb.m essage.Fault インターフェイス
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);
}
3.2.4. ボディ
ボディは一般的にメッセージのペイロードを格納します。ボディを使用して任意数の異なるデータタイプ
を送信することができます。ボディ内における単一データ項目の送信や受信に制限はありません。このよ
うなオブジェクトがメッセージボディへシリアライズされる方法やメッセージボディからシリアライズさ
れる方法は、オブジェクトタイプによって異なります。
例 3.9 org.jboss.soa.esb.m essage.Body インターフェイス
public interface Body
{
public static final String DEFAULT_LOCATION
= "org.jboss.soa.esb.message.defaultEntry";
public
public
public
public
public
public
public
public
void add (Object value);
void add (String name, Object value);
Object get ();
Object get (String name);
String[] getNames()
void merge (Body b);
Object remove (String name);
void replace (Body b);
}
重要
ボディのバイト配列コンポーネントは JBossESB 4.2.1 で廃止されました。継続してバイト配列と
ボディ内に格納される他のデータを使用したい場合は、固有の名前に add を使用してください。ク
ライアントとサービスに対して同じバイト配列の場所が必要な場合、JBossESB が使用する
ByteBody.BYT ES_LOCAT ION を使用できます。
メッセージボディに名前付きオブジェクトを使用するのが最も簡単でしょう。ボディ全体をデコードしな
くてもメッセージペイロード内で各データ項目を追加、削除、検査することができます。また、ペイロー
ド内の名前付きオブジェクトとバイト配列を組み合わせることも可能です。
ボディにはあらゆるタイプのオブジェクトを追加することができます。 Java がシリアライズできないオ
ブジェクトを追加する場合はメッセージのマーシャルとアンマーシャルの機能を JBossESB に与える必要
26
第3章 サービスとメッセージ
があります。 詳細は、 「MessageFactory」 を参照してください。
シリアライズされたオブジェクトすべてが受信側で有用となるわけではないため、ボディへシリアライズ
するオブジェクトには注意する必要があります。たとえば、データベースサーバーにアクセスできないク
ライアントがデータベース接続オブジェクトを受信しても意味がありません。メッセージでシリアライズ
された Java オブジェクトを使用すると、サービスの実装を制限する依存関係が発生する場合もありま
す。
T he default named Object (DEFAULT _LOCAT ION) should be used with care so that multiple services or
Actions do not overwrite eachother's data.
T he default behavior of all ESB components (Actions, Listeners, Gateways, Routers, Notifiers etc) is to
get and set data on the message using the message's Default Payload Location.
All ESB components use the MessagePayloadProxy to manage getting and setting of the payload on
the message. It handles the default case, as outlined above, but also allows this to be overridden in a
uniform manner across all components. It allows the "get" and "set" location for the message payload to
be overridden in a uniform way using the following component properties:
get-payload-location: メッセージペイロードを読み出す場所。
set-payload-location: メッセージペイロードを set する場所。
注記
JBossESB 4.2.1GA 以前は、デフォルトのメッセージペイロード交換パターンはありませんでし
た。JBossESB 4.2.1GA 以降のリリースに後方互換性を持たせるには、jbossesb.sar 内にある
jbossesb-properties.xm l ファイルの core セクション
で、use.legacy.message.payload.exchange.patterns プロパティを true に設定します。
3.2.5. ボディに対する拡張
バイトや名前と値のペアに関して、メッセージボディーの内容を直接操作することもできますが、事前に
定義されたメッセージ構造やメソッドを提供すれば、複数のインターフェイスにてこの操作を簡略化する
ことができます。
これらのインターフェイスは基本のボディーインターフェイスの拡張で、既存のクライアントやサービス
と共に使用できます。メッセージの基礎となるデータ構造は変更されないため、メッセージのコンシュー
マは新しいタイプを認識する必要はありません。
XMLMessageFactory クラスや SerializedMessageFactory クラスを使用すると、これらのイン
ターフェイスを基にしたボディの実装を持つメッセージを作成することができます。メッセージに対して
作業を行う場合、MessageFactory クラスや MessageFactory に関連したクラスを使用するよ
り、XMLMessageFactory クラスや SerializedMessageFactory クラスを使用した方が便利です。
createT extBody など、ボディの各タイプに関連する create メソッドが存在します。このメソッドに
よって、特定タイプのメッセージを作成し初期化することができます。メッセージの作成後、生のボディ
またはインターフェイスメソッドを使用して直接メッセージを操作することができます。ボディの構造は
送信後も維持されるため、メッセージを作成したインターフェイスのメソッドを使用すればメッセージの
受信側が操作することもできます。
org.jboss.soa.esb.m essage.body.content.T extBody
ボディの内容は任意のストリングであり、getT ext メソッドや setT ext メソッドを使用して操作する
ことができます。
27
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
org.jboss.soa.esb.m essage.body.content.ObjectBody
ボディの内容はシリアライズされたオブジェクトであり、getObject メソッドや setObject メソッド
を使用して操作することができます。
org.jboss.soa.esb.m essage.body.content.MapBody
ボディの内容はマップ (ストリング、シリアライズされている) であり、setMap メソッドやその他のメ
ソッドを使用して操作することができます。
org.jboss.soa.esb.m essage.body.content.T extBody
ボディの内容は任意のストリングであり、getT ext メソッドや setT ext メソッドを使用して操作する
ことができます。
org.jboss.soa.esb.m essage.body.content.ObjectBody
ボディの内容はシリアライズされたオブジェクトであり、getObject メソッドや setObject メソッド
を使用して操作することができます。
org.jboss.soa.esb.m essage.body.content.MapBody
ボディの内容はマップ (ストリング、シリアライズされている) であり、setMap メソッドやその他のメ
ソッドを使用して操作することができます。
org.jboss.soa.esb.m essage.body.content.BytesBody
ボディの内容は任意の Java データタイプを含むバイトストリームです。データタイプのメソッドを使用
して操作することができます。BytesMessage が作成されると、操作の必要に応じて読み取り専用モード
または書き込み専用モード内に置かれます。readMode() メソッドや writeMode() メソッドを使用し
てモードを変更することができますが、モードが変更される度にバッファポイントがリセットされま
す。flush() メソッドを呼び出して、すべての更新がボディに適応されたことを確認する必要がありま
す。
3.2.6. 添付
メッセージには、メインのペイロードボディには表示されない添付 (イメージ、図、バイナリドキュメン
ト形式、zip ファイルなど) が含まれることがあります。Attachm ent インターフェイスは、名前の付い
た添付と名前のない添付の両方をサポートします。JBossESB の現在のリリースでは、Java でシリアラ
イズされたオブジェクトのみが添付として扱われます。今後のリリースではこの制限が解除される予定で
す
添付を使用する理由はさまざまですが、メッセージに論理的な構成を提供するために使用するのが一般的
です。エンドポイント間で添付のストリーミングができるようにすると、大きなメッセージのパフォーマ
ンスを向上することができます。
JBossESB はメッセージや添付のストリーミングに他のエンコーディングメカニズムを指定することをサ
ポートしていません。この機能は今後のリリースに追加され、添付を持つ SOAP の配信メカニズムと結合
される予定です。現在、添付はボディ内の名前付きオブジェクトと同じ方法で処理されます。
28
第3章 サービスとメッセージ
警告
現時点では、Properties や Attachments の使用は推奨されません。
具体化する一般的な概念については現在再評価中で、将来のリリースで大幅に変更される可能性が
あります。
Properties と Attachments のデータがメッセージBody の一部として含まれることが推奨されま
す。
例 3.10 org.jboss.soa.esb.m essage.Attachm ent インターフェイス
public interface Attachment
{
Object get(String name);
Object put(String name, Object value);
Object remove(String name);
String[] getNames();
Object
Object
Object
throws
itemAt (int index) throws IndexOutOfBoundsException;
removeItemAt (int index) throws IndexOutOfBoundsException
replaceItemAt(int index, Object value)
IndexOutOfBoundsException;
void addItem (Object value);
void addItemAt (int index, Object value)
throws IndexOutOfBoundsException;
public int getNamedCount();
}
3.2.7. プロパティ
メッセージプロパティはメッセージの追加メタデータを定義します。 使用できるクライアントやサービス
のタイプに関する制限を施行するので、 JBossESB は java.util.Properties を使用した Properties は実
装しません。 Web サービススタックも同様です。 java.util.Properties を送信する必要がある場
合は現在の抽象化内に組み込むことができます。
警告
現時点では、Properties や Attachments の使用は推奨されません。
具体化する一般的な概念については現在再評価中で、将来のリリースで大幅に変更される可能性が
あります。
Properties と Attachments のデータがメッセージBody の一部として含まれることが推奨されま
す。
29
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
例 3.11 org.jboss.soa.esb.m essage.Properties インターフェイス
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();
}
3.2.8. MessageFactory
各 ESB コンポーネントは ESB メッセージを Java オブジェクトの集合として処理しますが、多くの場合
で ESB メッセージをシリアライズする必要があります。データストアへの保存や異なる JBossESB プロ
セス間でのメッセージ送信、デバッグなどの場合に ESB メッセージをシリアライズする必要がありま
す。
正規化形式の要件は、各 ESB デプロイメント独自の特性に左右されるため、JBossESB はメッセージに
対して単一の正規化形式を指定することはありません。org.jboss.soa.esb.m essage.Message イ
ンターフェイスの実装はすべて org.jboss.soa.esb.m essage.form at.MessageFactory クラス
から取得されます。
例 3.12 org.jboss.soa.esb.m essage.form at.MessageFactory
public abstract class MessageFactory
{
public abstract Message getMessage ();
public abstract Message getMessage (URI type);
public static MessageFactory getInstance ();
}
メッセージシリアライゼーションの実装は URI によって一意に識別されます。新しいインスタンスを作成
する時に実装を指定するか、設定されているデフォルトを使用します。
現在、JBossESB は JBOSS_XML と JBOSS_SERIALIZED の 2 つの実装を提供します。これらの実装
は、org.jboss.soa.esb.m essage.form at.MessageT ype クラスに定義されています。
追加のメッセージ実装は、ランタイム時に
org.jboss.soa.esb.m essage.form at.MessagePlugin より提供できます。
30
第3章 サービスとメッセージ
例 3.13 org.jboss.soa.esb.m essage.form at.MessagePlugin
public interface MessagePlugin
{
public static final String MESSAGE_PLUGIN =
"org.jboss.soa.esb.message.format.plugin";
public Message getMessage ();
public URI getType ();
}
各プラグインは getT ype() メソッドを使用して、提供するメッセージ実装のタイプを一意に識別しなけ
ればなりません。プラグインの実装は、org.jboss.soa.esb.m essage.form at.plugin 拡張の付
いたプロパティ名を使って jbossesb-properties.xm l ファイル内でシステムに対し識別されなけれ
ばなりません。
3.2.8.1. MessageT ype.JAVA_SERIALIZED
この実装では、メッセージの全コンポーネントがシリアライズ可能でなければなりません。このタイプの
メッセージの受信側は、メッセージをデシリアライズできなければなりません。よって、メッセージ内に
格納された Java クラスをインスタンス化できなければならないことになります。
この実装では、すべての内容が Java でシリアライズできなければなりません。メッセージにシリアライ
ズ可能でないオブジェクトを追加しようとすると、IllegalParam eterException がスローされま
す。
URI は urn:jboss/esb/m essage/type/JAVA_SERIALIZED です。
重要
アプリケーションが簡単に特定のサービス実装に結合されてしまうため、メッセージ形式の
JAVA_SERIALIZ ED バージョンの使用には細心の注意を払ってください。
3.2.8.2. MessageT ype.JBOSS_XML
メッセージの XML 表現を使用します。メッセージのスキーマは、schemas ディレクトリ内の
m essage.xsd に定義されます。
URI は urn:jboss/esb/m essage/type/JBOSS_XML です。
メッセージに Java でシリアライズできないオブジェクトを追加する場合は、XML にてこれらのオブジェ
クトをマーシャリングするメカニズムを提供しなければなりません。それに
は、org.jboss.soa.esb.m essage.form at.xm l.m arshal.MarshalUnm arshalPlugin イン
ターフェイスを使用してプラグインを作成します。
31
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
public interface MarshalUnmarshalPlugin
{
public static final String MARSHAL_UNMARSHAL_PLUGIN =
"org.jboss.soa.esb.message.format.xml.plugin";
public boolean marshal (Element doc, Object param)
throws MarshalException;
public Object unmarshal (Element doc) throws UnmarshalException;
public URI type ();
}
プラグインのマーシャリングは、jbossesb-properties.xm l 設定ファイルよりシステムに登録しな
ければなりません。プラグインは MARSHAL_UNMARSHAL_PLUGIN で始まる属性名を持たなければなりま
せん。
XML でオブジェクトをパッキングする時、JBossESB はそのオブジェクトタイプを処理できるプラグイン
が見つかるまで、登録されたプラグインのリスト内を検索します。適切なプラグインが見つからない場合
は、「不良 (Fault)」 で説明されたように障害メッセージを返します。メッセージの受信側でのアンパッ
キングを容易にするため、オブジェクトをパッキングしたプラグインの名前も添付されます。
32
第4章 サービスの構築と使用
第 4章 サービスの構築と使用
4.1. Listener、 Notifier/Router、 お よ び Action
4.1.1. Listener
Listener は ESB 認識のメッセージ受信用エンドポイントをカプセル化します。 メッセージの受信で、
Listener は「replyT o」エンドポイントにその結果をルーティングする前にメッセージを処理するメッセー
ジプロセッサの「パイプライン」にメッセージをフィードします。 パイプライン内で行われる Action 処
理はいくつかのステップで構成されることがあります。 ここでは、 特定のプロセッサにメッセージが変
換され、 何らかのビジネスロジックが次のプロセッサで適用されてから、 その結果がパイプライン内の
次のステップまたは別のエンドポイントにルーティングされます。
リスナーには、 アクティブワーカースレッドの数などのさまざまなパラメータを設定できます。 これら
のオプションの完全な説明については、 「概要」 を参照してください。
4.1.2. Router
Router は Action パイプラインからそのペイロードまたは ESB メッセージを他のエンドポイントに送信す
るために使用される Action です。 SOA Platform には複数の Router が含まれ、 ほとんどの使用状況に対
応します。 StaticWireT ap の例外では、 含まれる Router Action はすべて構成に残っている追加の
Action があっても Action パイプラインの処理を終了します。
各ルーターの詳細については、 「ルーティング」 を参照してください。
unwrap プロパティを実装する Router があります。 これにより Router はメッセージのペイロードのみを
送るだけで ESB を認識しないエンドポイントにメッセージを送信することができるようになります。 こ
のプロパティを true にセットすると ESB メッセージのペイロードが抽出されてから送信されます。
unwrap を false に設定すると完全な ESB メッセージを送信します。
また、 メッセージのコンテンツに基づいて動的なルーティングに使用できる ContentBasedRouter と呼ば
れるルータも存在します。 コンテンツベースのルーティングの詳細については、 『JBoss SOA Platform
サービスガイド (JBoss SOA Platform Services Guide)』 [1] を参照してください。
4.1.3. Notifier
成功またはエラーの情報を ESB 認識しないエンドポイントに伝播させることができる方法が Notifier にな
ります。 ESB 認識のエンドポイントとの通信には Notifier を使用しないでください。 ESB 認識のエンド
ポイントと ESB 認識しないエンドポイントに同じチャンネルでのリッスンを行わせることはできませ
ん。 ESB 認識のエンドポイントと通信する場合は Action 内で Couriers か ServiceInvoker を使用するこ
とを考慮してください。
ESB 認識のトランスポートがすべて Notifier に対してサポートされているわけではありません (また、 そ
の逆も同様)。 Notifier は何をトランスポートできるかに関して意図的にシンプルになっています。byte[]
または String のどちらかです (ペイロードで toString() を呼び出すことにより取得)。
33
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
注記
JMSNotifier は ESB メッセージのタイプ (XML または Serializable) に応じて JMS メッセージのタ
イプ (T extMessage または ObjectMessage) を送信していました。 ESB メッセージのタイプは
Notifier が応答を送信する方法に作用すべきではないため、 これは間違っていました。 JBossESB
4.2.1CP02 以後は、 Notifier で使用されるメッセージタイプは ESB メッセージでプロパティとし
て設定可能になります
(org.jboss.soa.esb.m essage.transport.jm s.nativeMessageT ype)。 可能性のある値
としては NotifyJMS.NativeMessage.text か NotifyJMS.NativeMessage.object にな
ります。以前のリリースとの後方互換のため、 デフォルト値はその ESB メッセージタイプに依存
します。 Serializable にはオブジェクト、XML にはテキストになります。 ただしできればデフォ
ルトに依存しないことを推奨します。
As outlined above, the responsibility of a listener is to act as a message delivery endpoint and to deliver
messages to an "Action Processing Pipeline". Each listener configuration needs to supply information
for:
Registry (service-category、service-nam e、service-description、および EPRdescription タグ名)。オプションの remove-old-service tag 名を true に設定すると、ESB はこの
新しいインスタンスを追加する前に Registry から既存のすべてのサービスエントリを削除します。た
だし、すべての EPR を含むサービス全体が削除されるため注意してください。
listener クラスのインスタンス化 (listenerClass タグ名を参照)
listener が処理する EPR。これはトランスポート固有となります。 次の例は JMS EPR に該当します
(connection-factory、destination-type、destination-name、jndi-type、jndi-URL、message-selector
のタグ名を参照)。
the "action processing pipeline". One or more <action> elements that each must contain at least the
'class' tag name that will determine which action class will be instantiated for that step in the
processing chain.
34
第4章 サービスの構築と使用
例 4 .1 HelloWorld クイックスタートサービス設定
<?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>
</jbossesb>
</actions>
</service>
</services>
T his example configuration will instantiate a listener object (jms-listener attribute) that will wait for
incoming ESB Messages, serialized within a javax.jms.ObjectMessage, and will deliver each incoming
message to an ActionProcessingPipeline consisting of two steps (<action> elements):
35
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
1. action1、MyJMSListenerAction (普通のサンプルが続く)
2. notificationAction、org.jboss.soa.esb.actions.SystemPrintln
次の普通の Action クラスは XML Action 設定をデバッグする際に便利であることがわかります。
public class MyJMSListenerAction
{
ConfigTree _config;
public MyJMSListenerAction(ConfigTree config) { _config = config; }
public Message process (Message message) throws Exception
{
System.out.println(message.getBody().getContents());
return message;
}
}
ESB ユーザーがユーザー独自のニーズにあわせてフレームワークを調整することができる主要な手段が
Action クラスになります。 ActionProcessingPipeline クラスは少なくとも次を提供するためにあらゆる
Action クラスを期待します。
ConfigT ree タイプの単一引数をとるパブリックコンストラクタ
Message 引数をとる 1 つまたは複数のパブリックメソッド (Message の結果を返します)
Message 引数をとるオプションのパブリックコールバックメソッドはパイプライン処理の特定ステップ
の結果を通知するために使用されます (以下のアイテム 5 と 6 を参照)。
T he org.jboss.soa.esb.listeners.m essage.ActionProcessingPipeline class will
perform the following steps for all steps configured using <action> elements
1. Instantiate an object of the class specified in the 'class' attribute with a constructor that takes a
single argument of type ConfigT ree
2. Analyze contents of the 'process' attribute.
コンテンツはインスタンス作成されるクラスのパブリックメソッド名をコンマで区切った一覧にな
り (ステップ 1)、 それぞれ Message タイプの単一引数をとらなければならず、 パイプライン内で
次のステップに渡される Message オブジェクトを返します。
If the 'process' attribute is not present, the pipeline will assume a single processing method called
process
Using a list of method names in a single <action> element has some advantages compared to
using successive <action> elements, as the action class is instantiated once, and methods will be
invoked on the same instance of the class. T his reduces overhead and allows for state
information to be kept in the instance objects.
T his approach is useful for user supplied (new) action classes, but the other alternative (list of
<action> elements) continues to be a way of reusing other existing action classes.
3. 前のステップで返されるメッセージを使って一覧内の各メソッドを連続して呼び出します。
4. いずれかのステップで返される値が null の場合、 パイプラインは処理を直ちに停止します。
5. Callback method for success in each <action> element: If the list of methods in the 'process'
attribute was executed successfully, the pipeline will analyze contents of the okMethod attribute.
If none is specified, processing will continue with the next <action> element. If a method name is
provided in the okMethod attribute, it will be invoked using the Message returned by the last
method in step 3. If the pipeline succeeds then the okMethod notification will be called on all
handlers from the last one back to the initial one.
36
第4章 サービスの構築と使用
6. Callback method for failure in each <action> element: If an Exception occurs then the
exceptionMethod notification will be called on all handlers from the current (failing) handler
back to the initial handler. At present time, if no exceptionMethod was specified, the only output
will be the logged error. If an ActionProcessingFaultException is thrown from any process
method then an error message will be returned as per the rules defined in the next section. T he
contents of the error message will either be whatever is returned from the getFaultMessage of
the exception, or a default Fault containing the information within the original exception.
Action classes supplied by users to tailor behavior of the ESB to their specific needs, might need extra
run time configuration (for example the Notifier class in the XML above needs the <NotificationList> child
element). Each <action> element will utilize the attributes mentioned above and will ignore any other
attributes and optional child elements. T hese will be however passed through to the action class
constructor in the require ConfigT ree argument. Each action class will be instantiated with it's
corresponding <action> element and thus does not see (in fact must not see) sibling action elements.
注記
In JBoss ESB 4.3 GA the name of the property used to enclose NotificationList elements in the
<action> target is not validated.
4.1.4. Action とメッセージ
Action は Message が到着することで起動されます。 特定の Action 実装は Message 内のどこにデータが
存在しているか認識していることが期待されます。 サービスは Action の任意の番号を使って実装される
場合があるためであり、 単一入力の Message が複数の Action の代表として情報を含んでいる可能性があ
ります。 このような場合、 Message Body 内にそのデータ用の固有の場所を 1 つまたは複数選択して
サービスを使用する側に対してこれを伝えるのは Action 開発者の義務となります。
さらに、Action 同士はチェーン化される場合があるため、チェーンの始めの方の Action にオリジナル入力
の Message を修正させるまたは完全に置き換えさせることが可能です。
注記
セキュリティ上、 サービスチェーン内で未知の Action を使用する場合は注意が必要です。 情報の
暗号化を推奨します。
Action が入力 Message 内でデータを共有しそれぞれがチェーン全体に循環するためその情報を修正する
場合、 Action がチェーンの先に進んでもオリジナルの情報にアクセスできるようにするため、 デフォル
トでオリジナルの情報を維持することを推奨します。 当然、 これが不可能な場合や状況に適していない
こともあります。 JBossESB 内で入力データを修正する Action は、 このオリジナルの情報を
org.jboss.soa.esb.actions.post 指定の Body の場所に配置することができます。 つまり、
チェーン内に N 個の Action がある場合、Action N は通常検索する場所でオリジナルのデータを見つける
ことができます。 もし Action N-1 がそのデータを修正している場合は N はそのデータを他の指定場所で
見つけることになります。 さらに Action のチェーン機能を利用すると、 Action N は Action N-2 がその
データを修正したかどうかを org.jboss.soa.esb.actions.pre 指定の Body の場所を検索することにより確
認することもできます。
37
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
注記
前述した通り、 チェーン化された Action が競合する形でそれを使用する場合には、 Action を
チェーン化する際、 デフォルトの指定ボディの場所の使用には十分注意をしてください。
4.1.5. 応答を処理する
Action パイプライン、 暗示的な処理 ( Action の応答に基づく)、 明示的な処理での応答対応をサポートし
ている処理メカニズムは 2 種類あります。
処理が暗示的な場合、 応答は次のように処理されます。
パイプライン内の Action が null メッセージを返す場合、 応答は送信されません。
パイプライン内の最後の Action がエラー以外の応答を返した場合、 要求メッセージの ReplyT o EPR
に返信が送信されます。 これが設定されていない場合は、 要求メッセージの From EPR に送信されま
す。 応答をルーティングできない事態が発生すると、 エラーメッセージがシステムによりログ記録さ
れます。
処理が明示的な場合、 応答は次のように処理されます。
If the action pipeline is specified as 'OneWay' then the pipeline will never send a response
If the pipeline is specific as 'RequestResponse' then a reply will be sent to the ReplyT o EPR of the
request message or, if not set, to the From EPR of the request message. In the event that there is no
EPR is specified then no error message will be logged by the system.
We recommend that all action pipelines should use the explicit processing mechanism. T his can be
enabled by simply adding the 'mep' attribute to the 'actions' element in the jboss-esb.xm l file. T he
value of this attribute should be either OneWay or RequestResponse.
4.1.6. Action 処理中のエラーの扱い方
Action チェーンを処理しているあいだにエラーが発生する可能性があります。 このようなエラーは Action
パイプラインから例外として送出され、 これによりパイプラインの処理を終了させるはずです。 前述の
ように、 Fault Message が ActionProcessingFaultException 内で返される場合があります。 送信者 (また
は仲介者) に返されるエラー情報が重要である場合、 FaultT o EPR を設定してください。 これを設定しな
いと JBossESB は ReplyT o EPR に基づいてエラーメッセージの配信を試行し、ReplyT o EPR も設定さ
れていない場合は From EPR に配信を試行します。 いずれの EPR も設定されていない場合、 エラー情報
はローカルにログ記録されます。
さまざまなエラーメッセージを Action 実装から返すことができます。 ただし、 JBossESB は以下の「シ
ステム」エラーメッセージをサポートしています。 例外が送出され表示させるアプリケーション固有の
Fault Message がない場合、 これらはすべて Fault メッセージ内に記載される URI で識別することができ
ます。
urn:action/error/actionprocessingerror
これは、 チェーン内の Action が ActionProcessingFaultException を送出したが返す失
敗メッセージを含んでいなかったという意味になります。 例外の詳細は Fault の reason
String 内に含まれます。
urn:action/error/unexpectederror
処理中に予期しない例外が出現しました。 例外に関する詳細は Fault の reason String 内にあ
ります。
38
第4章 サービスの構築と使用
urn:action/error/disabled
Action 処理が無効になります。
Action チェーン内で例外が送出される場合、 FaultMessageException\t 内のクライアントに伝播し
て戻されます。 これは Courier か ServiceInvoker のクラスから再度送出されます。 Fault メッ
セージが受信されるときにも必ず送出されるこの例外は、 Fault のコードおよび理由の他に伝播された
例外を含みます。
4.2. メ タ デ ー タ と フ ィ ル タ
ESB を通ってメッセージが循環されるため、 ESB に入る時と出る時などにメタデータを添付すると便利
な場合があります。 また、 トランザクションやセキュリティ情報を追加するなど、 動的にメッセージを
補強する必要があるかもしれません。 これらの機能はいずれもゲートウェイと ESB ノード群両方に対し
てフィルタのメカニズムを使って JBossESB でサポートされます。
注記
フィルタのプロパティ名、InputOutputFilter のパッケージ、その署名などはすべて JBossESB 4.2
MR3 より古い主要なリリースからは変更されています。
org.jboss.soa.esb.filter.InputOutputFilter クラスは 2 種類のメソッドを持ちます。
public Message onOutput (Message msg, Map<String, Object> params) throws
CourierException which is called as a message flows to the transport. An implementation may
modify the message and return a new version. Additional information may be provided by the caller in
the form of extra parameters.
public Message onInput (Message msg, Map<String, Object> params) throws
CourierException which is called as a message flows from the transport. An implementation may
modify the message and return a new version. Additional information may be provided by the caller in
the form of extra parameters.
Filters are defined in the filters section of the jbossesb-properties.xm l file (typically located in the
jbossesb.sar archive) using the property org.jboss.soa.esb.filter.<number>, where <number> can be any
value and is used to indicate the order in which multiple filters are to be called (lowest to highest).
JBossESB ships with org.jboss.internal.soa.esb.m essage.filter.MetaDataFilter and
org.jboss.internal.soa.m essage.filter.GatewayFilter which add the following meta-data
to the Message as Properties with the indicated property names and the returned String values. See
the chapter 12, 'Connectors and Adapters' for more information about Gateways.
ゲートウェイ関連のメッセージプロパティ
org.jboss.soa.esb.m essage.transport.type
File、 FT P、 JMS、 SQL、Hibernate
org.jboss.soa.esb.m essage.source
メッセージが読み込まれた元ファイルの名前
39
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
org.jboss.soa.esb.m essage.tim e.dob
メッセージが ESB に入った時間、 つまり送信された時間またはゲートウェイに到着した時間
org.jboss.soa.esb.m esage.tim e.dod
メッセージが ESB から出た時間、 つまり受信された時間
org.jboss.soa.esb.gateway.original.file.nam e
メッセージがファイル関連のゲートウェイノード経由で受信された場合、 このエレメントはメッ
セージ供給元となるオリジナルファイルの名前を含む
org.jboss.soa.esb.gatway.original.queue.nam e
メッセージが JMS ゲートウェイノード経由で受信された場合、 このエレメントは受信された元
のキューの名前を含む
org.jboss.soa.esb.gateway.original.url
メッセージが SQL ゲートウェイノード経由で受信された場合、 このエレメントはオリジナルの
データベース URL を含む
注記
すべての ESB ノードで GatewayFilter のデプロイは安全ですが、 ゲートウェイノードにデプ
ロイされる場合は Message への情報追加しか行いません。
適切なフィルタを作成して登録することで、 メッセージにより多くのメタデータを追加することができま
す。 フィルタは追加パラメータ内の次のような名前が付くエントリの存在があるかないかでゲートウェイ
ノード内で稼働しているかどうかを判断することができます。
ゲートウェイ生成のメッセージパラメータ
org.jboss.soa.esb.gateway.file
メッセージ提供元のファイル。 このゲートウェイがファイルベースである場合にのみ表される。
org.jboss.soa.esb.gateway.config
ゲートウェイインスタンスの初期化に使用された ConfigT ree。
注記
JBoss ESB 4.3 GA では、GatewayFilter のサポートがあるのはファイルベースの JMS および
SQL ゲートウェイのみになります。
4.3. サ ー ビ ス と は
40
第4章 サービスの構築と使用
JBossESB はサービスの構成要素に関して制限を課しません。 本ガイドの前半で説明したように、 理想
的な SOA インフラストラクチャとは、 メッセージが非常に重要となり実装固有の詳細が抽象インター
フェースの背後に隠れるようなクライアントとサービス間に積極的なルーズカップリングの対話式を採用
しているインフラストラクチャです。 これにより、 実装はクライアントやユーザー側での変更を必要と
しない変更が可能になります。 メッセージの定義に対する変更で必然的に伴うのはクライアントへの更新
のみになります。
いままで見てきたように、 JBossESB はサービスの定義と構成にメッセージ主導のパターンを使用しま
す。 クライアントは Message をサービスに送り、 基本的なサービスインターフェースは本質的に受け
取った Message で動作する単一プロセスのメソッドになります。 内部的にサービスは 1 つまたは複数の
Action から構成され、 着信 Message を処理するためチェーン化することができます。 Action が行うこ
とは実装依存になります。 つまり、 データベーステーブルのエントリを更新したり EJB を呼び出すなど
です。
サービスを開発する場合、 最初にユーザーやコンシューマー側に公開する概念的なインターフェースや規
定を決定する必要があります。 この規定は Message の観点から定義されなければなりません。 つまり、
ペイロードをどのようにするか、 どのタイプの応答 Message が生成されるかなどです。
注記
定義が完了したら、 規定情報をレジストリ内で公開しなければなりません。 現在、 JBossESB に
は自動的にこれを行う手段はありません。
これでクライアントは公開された規定に従ってサービスを使用することができるようになります。 サービ
スが Message をどのように処理し必要な作業を行うかについては実装での選択になります。 単一の
Action 内でも複数の Action 内でも可能です。 管理性と再利用性のどちらをとるかなど、 多少の代償はつ
きものです。
注記
今後のリリースでは、 サービスの開発を容易にするツールサポートを向上させる予定です。
4.3.1. ServiceInvoker
クライアントの観点から、Courier インターフェースとその各種実装はサービスとの対話に使用できま
す。 ただし、 これはいまだかなり低レベルの方法となり、 レジストリにコンタクトして障害の処理を行
うようなプログラムが開発者により作成される必要があります。 また、 JBossESB にはステートレス
サービスに対するフェールオーバー機能があるため、 これもアプリケーションで管理する必要があるで
しょう。 フェールオーバーの詳細については「Advanced」の章を参照してください。
JBossESB 4.2 では、 開発にかける作業の簡略化を支援するため ServiceInvoker が採用されました。
ServiceInvoker は多くの低レベル詳細を表示させずステートレスサービスのフェールオーバーメカニズム
と不透明に動作します。 このように、 ServiceInvoker は JBossESB 内のサービスを使用する上で推奨さ
れるクライアント側インターフェースとなります。
41
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
public class ServiceInvoker
{
public ServiceInvoker(Service service) throws MessageDeliverException;
public ServiceInvoker(String serviceCategory, String serviceName) throws
MessageDeliverException;
public Message deliverSync(Message message, long timeoutMillis) throws
MessageDeliverException, RegistryException, FaultMessageException;
public void deliverAsync(Message message) throws MessageDeliverException;
}
ServiceInvoker のインスタンスはクライアントが対話を必要とするそれぞれのサービスに対して作成
することができます。 作成すると、 そのインスタンスはプライマリの EPR またフェールオーバーの際に
は代替となる EPR を確定するため必要に応じてレジストリにコンタクトします。
作成すると、 クライアントはサービスに対して同期的 (deliverSync) にまたは非同期的 (deliverAsync) に
Message を送信する方法を確定できるようになります。 同期的な方法の場合、 タイムアウトを指定する
必要があり、 これはクライアントが応答を待機する時間になります。 この期間内に応答が受信されない
と MessageDeliverException が送出されます。
本ガイドの前半で説明したように、Message を送信する際に T o、ReplyT o、FaultT oなどの値
をMessage ヘッダー内に指定することが可能です。 ServiceInvoker を使用する場合、 構成される際
にレジストリに既にコンタクトを行っているため T o フィールドは不要になります。 実際、
ServiceInvoker を通じて Message を送信する場合、T o フィールドは同期的配信モードでも非同期的配信
モードでも無視されます。 JBossESB の今後のリリースでは、 レジストリにより返される EPR がアク
ティブなサービスに対する解決に失敗した場合に代替の配信先として与えられるあらゆる T o フィールド
を使用できるようになる可能性があります。
4.3.2. サービスと ServiceInvoker
クライアントとサービスの環境では、 クライアントとサービスという用語を使って役割を表し、 単一の
エンティティが同時にクライアントでありサービスであり得ます。 このように、ServiceInvoker とは純粋
にクライアントの領域になるとはみなさないようにしてください。 サービス内、 特に Action 内での使用
が可能です。 たとえば、 ビルトインのコンテンツベースのルーティングを使用せずに、 特定のビジネス
ロジックの評価に基づき異なるサービスに着信メッセージを再ルーティングさせるため Action を使用した
い場合、 あるいは Action によって後日の管理目的で Dead Letter Queue に障害メッセージの特定タイプ
をルーティングするよう決定させることもできます。
ServiceInvoker をこのように使用する利点は、 「高度なトピック (Advanced )」の章で説明された不
透明なフェールオーバーメカニズムの恩恵をサービスが受けることができることです。 つまり、 他の
サービスや障害などへの一方向要求はより堅牢にルーティングされ、 開発は複雑になりません。
4.3.3. InVM トランスポート
InVM トランスポートは JBossESB 4.3 の新しい機能であり、同じ JVM で実行されているサービス間の通
信を提供します。つまり、ServiceInvoker のインスタンスは、ネットワークやメッセージシリアライ
ズ化のオーバーヘッドなしに同じ JVM 内からサービスを起動できます。
Earlier versions of the ESB did not support this transport and required every service to be configured
with at least one Message Aware listener. T his is not longer a requirement. Services can now be
configured without any <listener> configuration and still be invokable from within their VM. T his makes
Service configuration much simpler.
42
第4章 サービスの構築と使用
<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>
重要
InVM はサービス間の通信の促進に使用される内部データの構造を最適化することによりパフォー
マンス性を実現することを認識しておくことが重要となります。 このトランスポートの利用を決定
する際に考慮に入れておくべき制約がいくつかあります。
主要な制限は、 メッセージを格納するために使用するキューが永続的ではないことです。 サービ
スがシャットダウンしたり、 キューが空になる前に失敗したりした場合に、 これらのメッセージ
が失われます。 それ以外の制限はこのセクションで説明します。
注記
JBoss ESB を使用すると、 サービスを複数の異なるトランスポートから同時に起動できます。
サービスを設定する場合は、 パフォーマンスと信頼性を最大化するために異なるメッセージに適切
なトランスポートを選択することが重要です。
4 .3.3.1. inVM Scope
ESB デプロイメント用のデフォルトの InVM Scope は jbossesb-properties.xm l ファイルで
core:jboss.esb.invm.scope.default プロパティの値を使用して指定されます。JBoss SOA Platform で設定
されたデフォルト値は NONE ですが、このプロパティが未定義の場合、デフォルトのスコープは実際には
GLOBAL になります。
JBossESB は現在 2 つのスコープをサポートします。
NONE
Service は InVM トランスポートでは起動できません。
GLOBAL
Service は同じ Classloader スコープ内から InVM トランスポートに対して起動可能です。
注記
今後のリリースには LOCAL スコープが予定され、 これによりデプロイされた同じ .esb アーカイ
ブ内での起動を制限します。
You can specify the InVM scope of a service using the invmScope attribute of the <service> element of
the service's configuration.
43
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
例 4 .2 サービスに対して GLOBAL inVM スコープを有効化
<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>
4 .3.3.2. 処理された InVM
InVM リスナはトランザクション処理されたスコープ内、 トランザクション非処理のスコープ内いずれで
も、 トランザクションをサポートする他のトランスポートと同様に実行できます。
この動作は、 明示的または暗黙的な設定により制御でき、 次の基本的な 2 つのルールに従います。
1. サービスに設定されている別の処理済みトランスポートがある場合は ImVM リスナは暗示的に処理
されます。 現在、 こうした追加トランスポートは JMS、 scheduled または SQL です。
2. 与えると、 サービスエレメントにある invmT ransacted 属性が優先されます。
4 .3.3.3. トランザクションセマンティック
JBossESB 内の InVM トランスポートはトランザクション対応ですが、 メッセージキューは揮発性メモリ
にのみ保持されます。 InVM が非常に高速となるのはこのためですが、 システム障害またはシャットダウ
ンが発生した場合にはこのトランスポートのメッセージキューは失われます。
InVM キューの揮発性のため、 すべての ACID セマンティクスを達成できない場合があります (特にデータ
ベースなどの他のトランザクションリソースと使用する場合)。 ただし、 多くの場合InVM のパフォーマン
スの利点はその欠点を上回ります。 完全な ACID セマンティクスが必要な場合は、 JMS やデータベース
などの他のトランザクショントランスポートを使用することが推奨されます。
When using InVM within a transaction, the message will not appear on the receiver's queue until the
transaction commits, although the sender will get an immediate acknowledgment that the message has
been accepted to be later queued. If a receiver attempts to pull a message from the queue within the
scope of a transaction, then the message will be automatically placed back on the queue if that
transaction subsequently rolls back. If either a sender or receiver of a message needs to know the
transaction outcome then they should either monitor the outcome of the transaction directly, or register a
Synchronization with the transaction.
For performance reasons when a message is placed back on the queue by the transaction manager, it
may not go back into the same location. If your application relies on specific ordering of messages then
you should consider a different transport or group related messages into a single "wrapper" message.
4 .3.3.4 . ロックステップ配信
InVM トランスポートは低いオーバーヘッドでメモリ内メッセージキューにメッセージを配信します。 非
常に高速なためメッセージを消費しているサービスに対して配信が行われるのが速すぎるとメッセージ
キューが溢れてしまうことがあります。 これらの状況を緩和するために InVM トランスポートは「ロック
ステップ」配信メカニズムを提供しています。
「ロックステップ」配信方法では、 サービスがメッセージを読み出す能力を越える早さでメッセージが
44
第4章 サービスの構築と使用
サービスに配信されないようにします。 受信側サービスがメッセージを拾うかタイムアウト時間に到達す
るまでメッセージ配信をブロックすることによって行われます。
これは同期配信方法ではありません。応答を待ったり、サービスがメッセージを処理するのを待ったりせ
ず、メッセージがサービスによってキューから削除されるまでブロックします。
ロックステップ配信はデフォルトでは無効になっていますが、 property 設定を使用すると 1 サービスに
対し有効にすることができます。
例 4 .3 Enabling "Lock-Step" delivery
<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>
inVMLockStep
LockStep 配信を有効にするかどうかを制御するブール値
inVMLockStepT im eout
メッセージを取得するのを待ってるときにメッセージ配信をブロックする最大時間 (ミリ秒単位)
ロックステップ配信はトランザクションのスコープ内で無効にされます。 メッセージのキューへの挿入は
囲まれたトランザクションのコミット時に不測となり、 予期されるロックステップ待機期間の前後いつで
も発生する可能性があるためです。
4 .3.3.5. 負荷分散
ServiceInvoker は InVM トランスポート (利用可能な場合) よりもサービスを起動することを常に優先
します。 ServiceInvoker の他の負荷分散方針は目的のサービスに対して InVM エンドポイントが存在
しない場合のみ適用されます。
ServiceInvoker gives preference to invoking a service over its InVM transport if one is available.
ServiceInvoker's other load balancing strategies are only applied in the absence of an InVM
endpoint for the target Service.
4 .3.3.6. 「値で渡す」と「参照で渡す」
By default, the InVM transport passes Messages "by reference". T his is done for performance reasons
but can result in data integrity issues and class cast issues where messages are being exchanged
across ClassLoader boundaries.
Message passing "by value" can be enabled on individual services if you encounter these issues. T his
is done by by setting the inVMPassByValue property on the service to true
45
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
例 4 .4 inVMPassByValue プロパティに設定する
<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>
4.4. サ ー ビ ス 契 約 定 義
契約定義は、受信要求、送信応答、および対応するサービスによってサポートされる障害詳細メッセージ
を表す XML スキーマ定義を含めることによってサービスに対して指定できます。要求および応答メッ
セージを表すスキーマはメッセージのメインボディセクションのコンテンツの形式を定義するために使用
され、そのコンテンツの検証を強制的に実行できます。
T he schemas are declared by specifying the following attributes on the <actions> element associated
with the service.
表 4 .1 サービス契約属性
名前
説明
タイプ
inXsd
要求メッセージのスキーマを含むリソース (単一エ
レメントを表す)
xsd:string
outXsd
応答メッセージのスキーマを含むリソース (単一エ
レメントを表す)
xsd:string
faultXsd
スキーマのカンマで区切られた一覧 (それぞれが 1
つまたは複数のエラーエレメントを表す)
xsd:string
requestLocation
ボディ内の要求コンテンツの場所 (デフォルトの場
所でない場合)
xsd:string
responseLocation
ボディ内の応答コンテンツの場所 (デフォルトの場
所でない場合)
xsd:string
メッセージ検証
T he contents of the request and response messages can be automatically validated providing that the
associated schema has been declared on the <actions> element. T he validation can be enabled by
specifying the 'validate' attribute on the <actions> element with a value of 'true'.
検証はデフォルトで無効にされます。
ESB サービスを Web サービスとして公開
契約スキーマを宣言すると、Web サービスエンドポイントを介して ESB サービスが自動的に公開されま
す (その契約は契約 Web アプリケーションを介して探すことができます)。この機能は webservice 属性を
指定することによって変更できます。この値は以下のとおりです。
webservice 属性
false
46
第4章 サービスの構築と使用
Web サービスエンドポイントは公開される
true
Web サービスエンドポイントは公開される (デフォルト)
以下の例は、要求および応答のメッセージは検証するが Web サービスエンドポイント経由でサービスを
公開しないサービスの宣言を示しています。
<service category="ServiceCat" name="ServiceName"
description="Test Service">
<actions mep="RequestResponse" inXsd="/request.xsd"
outXsd="/response.xsd" webservice="false" validate="true">
</actions>
</service>
[1] 『JBo s s Enterp ris e SO A Platfo rm サービスガイド (JBo s s Enterp ris e SO A Platfo rm Servic es G uid e)』はファイル
S ervi ces_G ui d e.p d f として提供されるか、 http ://www.red hat.c o m/d o c s /en-US/JBo s s _SO A_Platfo rm/ でオンラインで参照できます。
47
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
第 5章 その他のコンポーネント
本章では、JBossESB 内の他のインフラストラクチャコンポーネントやサービスについて説明します。こ
れらのサービスのいくつかはそのサービス独自のドキュメントがありますので、 この場合はそちらも参照
してください。 本章の目的は開発者が利用できるその他のものに関する概要を示すことです。
5.1. メ ッ セ ー ジ ス ト ア
JBossESB のメッセージストアのメカニズムは監査追跡の目的を念頭に置いて設計されています。 他の
ESB サービスと同様にプラグイン可能なサービスであり、 特殊なニーズがある場合など開発者が独自の
永続メカニズムにプラグインすることができます。 JBossESB で提供される実装はデータベース永続メカ
ニズムになります。 ファイル永続メカニズムなどが必要な場合は、単にこれを行う独自のサービスを記述
し設定変更でデフォルトの動作を上書します。
メッセージストアについて注意して頂きたい点が 1 点あります。 これはベース実装になるということで
す。 メッセージストアの機能性が高度な監査と管理要求に応えられるようにするためコミュニティおよび
パートナーの方々と共同で作業を進めていく予定です。 したがってこれは出発点となります。
5.2. デ ー タ 変 換
クライアントとサービスは同じボキャブラリーを使用して交信することがよくありますが、 そうではない
場合にはあるデータ形式から別の形式に即時対応による変換が必要になります。 単一のデータ形式がすべ
てのビジネスオブジェクト、 特に大規模な開発や長期に渡る開発において適しているとみなすのは非現実
的です。 したがって、 あるデータ形式から別の形式への変換メカニズムを提供することが必要になって
くるわけです。
JBossESB では、 これは T ransformation Service の役割になります。 ESB のこのバージョンは Milyn
Smooks をベースとしたすぐに使用できる T ransformation Service が同梱されます。 Smooks は変換実装
および管理フレームワークになります。 これにより、 XSLT 、 Java などによる変換論理を実装してメッ
セージセットの変換論理の中央管理ができる管理フレームワークを実現します。
変換の実装のさまざまな例を提供する複数のクイックスタートが含まれます。
1. jboss-as/sam ples/quickstarts/transform _CSV2XML/
このクイックスタートは、カンマ区切り値 (CSV) ファイルを XML に変換する方法を示します。変
換は、Smooks を設定し、2 つの変換 (1 つは CSV から中間 xml 形式、もう 1 つは中間 xml 形式か
らターゲット xml への変換) を行うことによって実行します。
2. jboss-as/sam ples/quickstarts/transform _XML2POJO/
このクイックスタートは Smooks を使用して XML ファイルから Java POJO への単純な変換を実行
する方法を示します。
3. jboss-as/sam ples/quickstarts/transform _XML2POJO2/
このクイックスタートは 2 つの異なる XML ファイルから POJO の共通セットへの変換を示しま
す。
4. jboss-as/sam ples/quickstarts/transform _XML2XML_sim ple/
これは、JBossESB 内でメッセージ変換を手動で定義および適用する方法の非常に基本的な例であ
り、非常に単純な XSLT を Sam pleOrder.xm l メッセージに適用し、処理前と処理後の XML を
コンソールに出力します。
5. jboss-as/sam ples/quickstarts/transform _XML2XML_date_m anipulation/
このクイックスタートは transform ation_XML2XML_sim ple クイックスタートから継続し、
XSLT を Java と組み合わせることによって変換をどのように単純化できるかを示します。Java は
SampleOrder データフィールド (OrderDate.java) に対して文字列操作を実行するために使用さ
48
第5章 その他のコンポーネント
れ、XSLT は出力のテンプレートを提供するために提供されます。変換された元の
Sam pleOrder.xm l メッセージが Java コンソールに出力されます。
6. jboss-as/sam ples/quickstarts/transform _XML2XML_stream /
これは ESB サービスに対して変換の断片をストリーム化する方法の非常に基本的な例です。この背
後にあるトリックは visitBefore と visitAfter で渡されたエレメントを送信する Smooks DOMVisitor
を使用することです。
7. jboss-as/sam ples/quickstarts/transform _EDI2XML_Groovy_XSLT /
T his is the most advanced of the transform Quickstarts. Be sure to go through the other
transformation Quickstarts before going through this. T here's an accompanying Flash demo at
http://labs.jboss.com/portal/jbossesb/resources/tutorials/xformation-demos/console-demo-03.html
which walks you through this Quickstart.
完全な Smooks ドキュメンテーションは、Smooks プロジェクトの Web サイト
(http://milyn.codehaus.org/docs/v1.0/SmooksUserGuide_v1.0.html) に存在します。
5.3. コ ン テ ン ツ ベ ー ス ル ー テ ィ ン グ
ESB はメッセージをそのソースに動的にルーティングする必要がある場合があります。 たとえば、 オリ
ジナルの送り先が使用できなくなった可能性がある、 サービスが移動されてしまった可能性がある、 コ
ンテンツや時刻に基づいてメッセージが送信される場所をもっとアプリケーションに制御させたいなどで
す。 JBossESB 内のコンテンツベースルーティングのメカニズムを使用して適宜に複雑なルールに応じて
メッセージをルーティングすることができ、 これは JBoss Rules の表記法または XPath 内で定義が可能
です。
5.4. レ ジ ス ト リ
SOA のコンテキスト内で、 レジストリはそのサービスに関する情報を格納するためのセントラルポイン
トをアプリケーションやビジネスに提供します。 そのクライアントに対して標準市場と同ベルの情報や同
じ範囲におけるサービスの提供が求められます。 理想的にはレジストリは自動ディスカバリや ecommerce トランザクションの実行を容易にし、 ビジネストランザクションの動的環境を実現する必要も
あります。 したがって、 リジストリは単に「e-business ディレクトリ」というだけではなく、 SOA イ
ンフラストラクチャの固有となるコンポーネントになります。
いろいろな意味で、 リジストリサービスは JBossESB の心臓部となります。 エンドポイント参照 (EPR)
が起動されるとサービス自体によってリジストリにそれらを公開させる、 またサービスからエンドポイン
ト参照が取り除かれるとサービス自体によってリジストリからそれらを削除させることができます。 コン
シューマー側はレジストリを調べて現在のタスクに適したサービスの EPR を確定することができます。
49
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
第 6章 サンプル
6.1. メ ッ セ ー ジ の 使 用 方 法
メッセージは SOA 開発の手段において非常に重要なコンポーネントで、クライアントとサービスの間で
送信されるアプリケーション固有のデータを含んでいます。メッセージの内容は、サービスとそのクライ
アント群間の規定に関する重要な側面を表しています。本セクションでは、メッセージに関するベストプ
ラクティスや使用法について説明します。
Let's consider the following example which uses a Flight Reservation service. T his service supports the
following operations:
reserveSeat
これはフライト番号と座席番号をとり、 成功または失敗の表示を返します。
querySeat
これはフライト番号と座席番号をとり、 その座席が現在予約されているかどうかの表示を返しま
す。
upgradeSeat
これはフライト番号と 2 つの座席番号をとります (現在予約されている座席と移動先の座席)。
このサービスを開発する場合、 ビジネスロジックを実装するために EJB3 や Hibernate などの技術を使用
する可能性が高くなります。 このサンプルでは、 どのようにビジネスロジックが実装されるのかについ
ては触れずサービスの方に集中することとします。
このサービスの役割は、ロジックをそのバスに接続することです。これを行うためには、クライアントに
対して定義する規定など、サービスがバスに対してどのように公開されるかを判断する必要があります。
現在の JBossESB バージョンでは、この規定はクライアントとサービスが交換できるメッセージの形式を
とっています。ESB 内ではこの規定に関する公式な仕様はありません。現在、仕様は開発者が定義し、
ESB から帯域外でクライアントと通信しなければなりません。これについては今後のリリースで修正され
る予定です。
6.1.1. メッセージの構造
サービスの観点では、メッセージ内のすべてのコンポーネント中でボディが最も重要となります。これ
は、ビジネスロジック固有の情報を伝達するためにボディが使用されるからです。対話するには、クライ
アントとサービスの両方がお互いを理解しなければなりません。これには、トランスポートに同意する形
式 (JMS や HT T Pなど) やダイアレクトに同意する形式 (メッセージデータの表示や対応する形式) をとり
ます。
クライアントがメッセージをフライト予約サービスに直接送信するといったシンプルなケースの場合、
メッセージに関するオペレーションをサービスが判断する方法を確定する必要があります。この場合、
org.example.flight.opcode にて opcode (オペレーションコード) が文字列 (reserve、query、upgrade) と
してボディ内に表示されることを開発者が決定します。その他の文字列値 (または値の指定がない場合) は
不正なメッセージとしてみなされます。
50
第6章 サンプル
注記
メッセージ内のすべての値に固有の名前を与えて他のクライアントまたはサービスとのクラッシュ
を避けるのが重要となります。
メッセージボディはクライアントとサービス間でデータが交換される主要な手段となります。すべての任
意データタイプの数を格納することができる十分な柔軟性を持ち合わせています。各オペレーションに関
連するビジネスロジックを実行するために必要となる他のパラメータも適切にエンコードされます。
org.exam ple.flight.seatnum ber は座席番号用で整数になります。
org.exam ple.flight.flightnum ber はフライト番号で文字列になります。
org.exam ple.flight.upgradenum ber はアップグレードされる座席番号で整数になります。
表 6.1 オペレーションのパラメータ
オペレーション
opcode
seatnumber
flightnumber
upgradenumber
reserveSeat
String: reserve
整数
文字列
N/A
querySeat
String: query
整数
文字列
N/A
upgradeSeat
String: upgrade
整数
文字列
整数
前述の通り、これらのオペレーションはすべてクライアントに情報を返します。こうした情報は同様に
メッセージ内でカプセル化されます。ここで説明するプロセスと同じやり方で、こうした応答メッセージ
の形式が判断されます。説明が難しくなるため、ここでは応答メッセージについては考慮しません。
JBossESB のアクションの観点では、サービスは 1 つ以上のアクションを使用して構築することができま
す。たとえば、メインのビジネスロジックに関与するアクションに受信メッセージを渡す前に、アクショ
ンは受信メッセージを事前処理し、その内容を何らかの方法で変換することができます。各アクションは
分離して記述されている可能性があります (同じ構成内の別のグループまたは完全に異なる構成など)。各
アクションは対応する Message データの独自のビューを持つことが重要となります。そうでない場合、
チェーンされた Action によって上書きされたり、アクション同士が干渉し合う可能性があります。
6.1.2. サービス
この時点でサービスを構成するのに十分な情報があります。 わかりやすくするため、 ビジネスロジック
は次の疑似オブジェクト内でカプセル化されていると仮定します。
class AirlineReservationSystem
{
public void reserveSeat (...);
public void querySeat (...);
public void upgradeSeat (...);
}
注記
ビジネスロジックは POJO、 EJB、 Spring などで開発が可能です。 JBossESB ではこれら多くの
手段について特に設定をすることなくそのままの状態によるサポートを提供します。 関連のドキュ
メントとサンプルをお読みください。
T he process method of the service Action (we'll assume no chaining of Actions) then becomes (ignoring
51
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
error checking):
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 ではなく、メッセージヘッダのア
クションフィールドを使用することができます。この欠点は、複数の JBossESB アクションが
チェーン化され、各アクションに異なる opcode が必要な場合は機能しないことです。
6.1.3. ペイロードの展開
ご覧の通り、process メソッドはスタート地点にすぎません。次に、受信のメッセージペイロード (ボ
ディ) を復号化するメソッドを提供しなければなりません。
public void reserveSeat (Message message) throws Exception
{
int 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
}
このメソッドは、ボディ内の情報がどのように抽出され、ビジネスロジックでメソッドを呼び出すのに使
52
第6章 サンプル
用されるかを表しています。reserveSeat のケースでは、クライアントにより応答が予期されます。この
応答メッセージは、ビジネスロジックにより返される情報や、元の受信したメッセージより取得した配信
情報を使って構成されます。この例の場合、受信メッセージの ReplyT o フィールドより取得する T o アド
レスが応答に必要となります。また、応答を元の要求に関連させる必要がありますが、これは応答の
RelatesT o フィールドと要求の MessageID を使用して関連させます。
サービスでサポートされるこの他すべてのオペレーションは同様にコード化されます。
6.1.4. クライアント
サービスによりサポートされるメッセージ定義があれば、クライアントコードを作成できます。サービス
をサポートするために使用するビジネスロジックは、サービスによって直接公開されることはありません
(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 maximumRetriesNotExceeded;
注記
上記の多くは、従来のクライアント／サーバースタブジェネレータと同様であるように見えるかも
しれません。これらのシステムでは、オペレーションコードやパラメータなどの低レベルの詳細は
高レベルのスタブ抽象化の背後に隠されることになります。JBossESB の今後のリリースでは、開
発アプローチを緩和するためこうした抽象化をサポートしていく予定です。ボディやヘッダなど生
のメッセージコンポーネントの作業は、ほとんどの開発者から見えないようになります。
6.1.5. コツとヒント
クライアントとサービスの開発に便利なコツやヒントを記しておきます。
アクションを開発する際、アクション固有のペイロード情報は必ずメッセージボディ内の独自の場所
で維持するようにしてください。
53
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
Message 内でバックエンドサービス実装の詳細を公開しないようにしてください。公開してしまう
と、クライアントに影響を与えずに実装を変更することが難しくなります。実装にとらわれないメッ
セージ定義 (内容や形式など) は、疎結合を維持できるようにします。
ステートレスサービスの場合は、フェールオーバーを不透明に処理するため ServiceInvoker を使用し
ます。
要求／応答のアプリケーションを構築する場合は、メッセージヘッダ内で相互関係の情報 (MessageID
と RelatesT o) を使用します。
メインのサービスオペレーションコードにヘッダアクションフィールドを使用するよう考慮してくだ
さい。
応答用の配信アドレスがない場合に非同期の対話を使用する場合、 後で監視できるようすべてのエ
ラーを MessageStore に送信することを考慮してみてください。
JBossESB がサービス規定の定義や公開に対してより自動的なサポートを提供できるようになるま
で、開発者とユーザーが使用できる定義のレポジトリを個別に維持するようにしてください。
54
第7章 高度なトピック
第 7章 高度なトピック
本章では JBossESB 内の高度なコンセプトについてさらに見ていくことにします。
7.1. フ ェ ー ル オ ー バ ー と 負 荷 分 散 の サ ポ ー ト
In mission critical systems it is important to design with redundancy in mind. T he JBoss ESB includes
built-in fail-over, load balancing and delayed message redelivery to help you build a robust architecture.
When you use SOA it is implied that the Service has become the building unit. JBossESB allows you to
replicate identical services across many nodes. Where each node can be a virtual or physical machine
running an instance of JBossESB. T he collective of all these JBossESB instances is called "T he Bus".
Services within the bus use different delivery channels to exchange messages. In ESB terminology one
such channel maybe JMS, FT P, HT T P, etc. T hese different "protocols" are provided by systems external
to the ESB; the JMS-provider, the FT P server, etc. Services can be configured to listen to one or more
protocols. For each protocol that it is configured to listen on, it creates an End Point Reference (EPR) in
the Registry.
7.1.1. サービス、 EPR、 リスナー、 アクション
As we have discussed previously, within the jboss-esb.xm l each service element consists of one or
more listeners and one or more actions. Let's take a look at the JBossESBHelloworld example. T he
configuration fragment below is loosely based on the configuration of the JBossESBHelloworld
example. When the service initializes it registers the category, name and description to the UDDI
registry. Also for each listener element it will register a ServiceBinding to UDDI, in which it stores an EPR.
In this case it will register a JMSEPR for this service, as it is a jms-listener. T he jms specific like queue
name etc are not shown, but appeared at the top of the jboss-esb.xm l where you can find the
'provider' section. In the jms-listener we can simply reference the "quickstartEsbChannel" in the busidref
attribute.
図 7.1 helloworld クイックスタートサンプル (1 つのノードに 1 つのサービス )。
55
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
例 7.1 helloworld クイックスタートサンプル (設定の一部 )
...
<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>
...
カテゴリとサービス名を見てみると、 レジストリ内のサービスを検索することで別のサービスが Hello
World サービスにメッセージを送信できます。 JMSEPR を受け取り、 それを使ってメッセージを送信で
きます。 こうした重い作業はすべて ServiceInvoker クラスで行われます。 HelloWorld サービスが
quickstartEsbChannel 経由でメッセージを受け取ると、 このメッセージを ActionPipeline 内の 1 番目の
アクションのプロセスメソッドに渡します。 SystemPrintln アクションです。
注記
ServiceInvoker によってファイルオーバーの複雑さの大部分がユーザーから隠されるため、ネ
イティブの ESB メッセージとのみ動作する必要があります。またすべてのゲートウェイが
ServiceInvoker を使用するよう変更されているわけではないため、これらのゲートウェイ実装への
受信 ESB 非対応メッセージはサービスファイルオーバーを常に利用できるとは限りません。
7.1.2. 複製されたサービス
In our example we have this service running on let's say Node1. What happens if we simply take the
helloworld.esb and deploy it to Node2 as well (see figure 7-2)? Let's say we're using jUDDI for our
Registry and we have configured all our nodes to access one central jUDDI database (it is
recommended to use a clustered database for that). Node2 will find that the FirstServiceESB SimpleListener Service is already registered! It will simply add a second ServiceBinding to this service.
So now we have 2 ServiceBindings for this Service. We now have our first replicated Service! If Node1
goes down, Node2 will keep on working.
56
第7章 高度なトピック
図 7.2 異なるノードにある 2 つのサービスインスタンス
両方のサービスインスタンスが同じキューをリッスンするため負荷分散機能を得ることになります。 ただ
し、 まだこのセットアップでは単一障害点があることになります。 このため、次のセクションで説明す
るプロトコルクラスタリングがひとつの選択肢となります。
このタイプのレプリケーションを使用してサービスの利用度を向上したり負荷分散機能を提供することが
できます。 詳しく説明するため、 論理サービス (アプリケーションサービス) を持つ以下の図を見てくだ
さい。 実際には 4 つの個別なサービスから構成され、 それぞれ同じ機能を提供し同じサービス規定に準
じています。 異なるのは同じトランスポートプロトコルを共有する必要がないということだけです。 し
かし、 アプリケーションサービスのユーザーに関する限り、 ユーザーにはサービス名とカテゴリで識別
される単一のサービスしか見えません。 ServiceInvoker はアプリケーションサービスが実際には 4 つの
サービスから構成されているという事実をクライアントには見えないようにしています。 これにより個別
サービスの障害が隠され、 複製されるサービスグループの少なくとも 1 インスタンスが利用できる状態に
ある限りクライアントは先に進むことができます。
注記
このタイプのレプリケーションはステートレスのサービスにのみ使用してください。
57
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
サービスプロバイダーはサービスコンシューマー側のサービスを自主的に複製する場合があります。 しか
し、 サービスが自動的にリジストリ内で定義された代替サービスにフェールオーバーされるのを好まない
場合があります。自動的なフェイルオーバーを防ぐにはメッセージプロパティ
org.jboss.soa.esb.exceptionOnDeliverFailure を true に設定します。このプロパティを設定すると、
メッセージを再送信する代わりに ServiceInvoker によって MessageDeliverException がスローされ
ます。すべてのメッセージにこれを指定するには、 JBossESB プロパティファイルの Core セクションで
このプロパティを設定します。
7.1.3. プロトコルのクラスタリング
JMS プロバイダの中にはクラスタ化が可能なものがあります。 JBossMessaging もこうしたプロバイダ
のひとつで、 JBossESB 内のデフォルト JMS プロバイダとしてこれを使用するのもその理由です。 JMS
をクラスタ化することでアーキテクチャから単一障害性を排除します。図 7-3 を参照してください。
58
第7章 高度なトピック
図 7.3 JMS を使用したプロトコルクラスタリングの例
JMS クラスタリングを有効にしたい場合は JBossMessaging のクラスタリングに関するドキュメントを
お読みください。 JBossESB レプリケーションと JMS クラスタリングは以下の図に示すように一緒に使
用することができます。 この例では、 サービス A が単一の JMSEpr によりレジストリ内で指定されてい
ます。 しかし、 クライアントには不透明にその JMSEpr はクラスタ化された JMS キューを参照し、 これ
は 3 つのサービスをサポートするため別々に設定されています。 利用度や負荷分散機能に対する連合的な
手段となります。 実際、サービスのレプリケーションをユーザー (JBossESB レプリケーションの方法の
場合はクライアントであり、 JMS クラスタリングの場合は JBossESB) に見えないようにするのは SOA
の原則と一致しています。 これら実装の詳細をサービスエンドポイントの背後に隠し規定レベルでは公開
しません。
59
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
注記
JMS クラスタリングをこの方法で使用している場合、 明らかに設定が正しく行われているかを確
認する必要があります。 たとえば、 ESB サービスをすべて JMS クラスタ内に配置する場合は
ESP レプリケーションの利点を生かすことはできません。
プロトコルクラスタリングの別の例としてはファイルシステムプロトコルの NAS がありますが、 ご使用
のプロバイダが単純にクラスタリングをまったく提供できない場合はどうでしょう。 このような場合に
は、 サービスに複数のリスナーを追加し、 複数の (JMS) プロバイダを使用することができます。 ただ
し、 これにはフェールオーバーと負荷分散機能がプロバイダ全体に必要となります。 それでは、 これに
ついて次のセクションで見ていくことにします。
7.1.4. クラスタリング
クラスタ内の複数のノードで同じサービスを実行したい場合、 サービスが完全にクラスタ化された環境で
動作する前にサービスレジストリキャッシュの再検証を待たなければなりません。 このキャッシュ再検証
のタイムアウトは deploy/jbossesb.sar/jbossesb-properties.xm l でセットアップできます。
60
第7章 高度なトピック
<properties name="core">
<property name="org.jboss.soa.esb.registry.cache.life" value="60000"/>
</properties>
デフォルトのタイムアウトは 60 秒です。
7.1.5. チャンネルのフェールオーバーと負荷分散機能
本セクションの HelloWorld サービスは 1 プロトコル以上のリッスンが可能です。 以下では FT P チャ
ンネルを追加しています。
...
<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>
...
これでサービスは 2 つの JMS キューを同時にリッスンしていることになります。 これらのキューは物理
的に異なるマシンで JMS プロバイダにより提供することができます。 つまり、 2 つのサービス間の冗長
な JMS 接続を確立したということになります。 この設定ではプロトコルを混合することも可能なため、
FT P リスナーを追加することもできます。
61
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
図 7.4 2 つの FT P サーバーをその混合に追加する
...
<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>
...
When the ServiceInvoker tries to deliver a message to our Service it will get a choice of 8 EPRs now
62
第7章 高度なトピック
(4 EPRs from Node1 and 4 EPRs from Node2). How will it decide which one to use? For that you can
configure a Policy. In the jbossesb-properties.xml you can set the 'org.jboss.soa.esb.loadbalancer.policy'.
Right now three Policies are provided, or you can create your own.
1 番目に利用可能。 健全な ServiceBinding が見つかるとそれが終了しない限り使用され、 一覧内の次
の EPR に移動します。 このポリシーは 2 つのサービスインスタンス間での負荷分散は提供しませ
ん。
ラウンドロビン。 一般的な負荷分散ポリシーで、 各 EPR は一覧の順でヒットされます。
ランダムロビン。 他のロビンと似ていますがランダムになります。
T he EPR list the Policy works with may get smaller over time as dead EPRs will be removed from the
(cached) list. When the list is emptied or the time-to-live of the list cache is exceeded, the ServiceInvoker
will obtain a fresh list of EPRs from the Registry. T he 'org.jboss.soa.esb.registry.cache.life' can be set in
the jbossesb-properties file, and is defaulted to 60,000 milliseconds. What if none of the EPRs work at
the moment? T his is where we may use Message Redelivery Service.
7.1.6. メッセージ再配信
EPR の一覧に終了した EPR 以外何も含まれていない場合、 ServiceInvoker は以下の 2 つのうちいずれか
を行うことができます。
メッセージを同期的に配信しようとしている場合、 メッセージを DeadLetterService に送信します。
デフォルトでは DLQ MessageStore に格納し、 呼び出し側にエラーを返送します。 処理は停止しま
す。 たとえば、 JMS キューに送りたい、 あるいは通知を受け取りたい場合などは、 jbossesb.esb 内
の DeadLetterService を設定することができます。
メッセージを非同期的に送信しようとしている場合 (推奨)、 この場合もメッセージを
DeadLetterService に送信しますがそのメッセージは RDLVR MessageStore に格納されます。 再配信
サービス (jbossesb.esb) は再配信試行の最大数に達するまでメッセージ送信の再試行を行います。 最
大数に達すると、 メッセージは DLQ MessageStore に格納され処理は停止します。
図 7.5 メッセージ再配信
63
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
注記
デフォルトでは DeadLetterService はオンになりますが、 jbossesb-properties.xm l で
org.jboss.soa.esb.dls.redeliver を false に設定すると使用をオフにすることができま
す。
7.2. サ ー ビ ス の ス ケ ジ ュ ー ル
JBoss ESB 4.3 GA は 2 種類のプロバイダをサポートしています。
1. バスプロバイダ、 JMS や HT T P などメッセージングプロトコルを介してアクション処理パイプラ
インにメッセージを供給します。 このプロバイダタイプは基礎となるメッセージングプロバイダに
より起動されます。
2. スケジュールプロバイダ、 スケジュール駆動のモジュールに基づいてアクション処理パイプライン
にメッセージを供給します。 つまり、 基礎となるメッセージ配信のメカニズム (ファイルシステム
など) はメッセージが処理可能になる場合に ESB 起動に対するサポートを提供せず、 スケジューラ
が定期的にリスナーを起動して新しいメッセージをチェックします。
スケジュールの機能は JBoss ESB の新機能になるため、 このモデルへの全リスナーの移植はまだ完了し
ていません。
JBoss ESB 4.3 GA offers a <schedule-listener> as well as 2 <schedule-provider> types: <simpleschedule> and <cron-schedule>. T he <schedule-listener> is configured with a “composer” class, which
is an implementation of the
org.jboss.soa.esb.listeners.ScheduledEventMessageCom poser interface.
7.2.1. Simple Schedule
このスケジュールタイプは次の属性に基づく簡単なスケジュール機能を提供します。
scheduleid
スケジュール用の固有の識別子文字列になります。 リスナーからスケジュールを参照するために
使用されます。
frequency
すべてのスケジュールリスナーが起動されるべき頻度 (秒単位) になります。
execCount
スケジュールが実行されるべき回数になります。
startDate
スケジュールの開始日と時間です。 この属性値の形式は XML スキーマタイプの「dateT ime」に
なります。dateT ime を参照してください。
endDate
スケジュールの終了日と時間です。 この属性値の形式は XML スキーマタイプの「dateT ime」に
なります。dateT ime を参照してください。
64
第7章 高度なトピック
例:
<providers>
<schedule-provider name="schedule">
<simple-schedule scheduleid="1-sec-trigger" frequency="1" execCount="5" />
</schedule-provider>
</providers>
7.2.2. Cron Schedule
このスケジュールタイプは CRON 式に基づいたスケジュール機能を提供します。 このスケジュールタイ
プの属性は以下の通りです。
scheduleid
スケジュールの固有な識別子文字列です。 リスナーからのスケジュールを参照するために使用さ
れます。
cronExpression
CRON 式
startDate
スケジュールの開始日と時間です。 この属性値の形式は XML スキーマタイプの「dateT ime」に
なります。dateT ime を参照してください。
endDate
スケジュールの終了日と時間です。 この属性値の形式は XML スキーマタイプの「dateT ime」に
なります。dateT ime を参照してください。
例:
<providers>
<schedule-provider name="schedule">
<cron-schedule scheduleid="cron-trigger" cronExpression="0/1 * * * * ?" />
</schedule-provider>
</providers>
7.2.3. Scheduled Listener
T he <scheduled-listener> can be used to perform scheduled tasks based on a <simple-schedule> or
<cron-schedule> configuration.
It's configured with an event-processor class, which can be an implementation of one of
org.jboss.soa.esb.schedule.ScheduledEventListener or
org.jboss.soa.esb.listeners.ScheduledEventMessageCom poser.
ScheduledEventListener
このインターフェースを実装するイベントプロセッサは単純に「onSchedule」メソッドで起動さ
65
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
れます。 アクション処理パイプラインは実行されません。
ScheduledEventMessageComposer
このインターフェースを実装するイベントプロセッサはリスナーに関連付けられるアクション処
理パイプラインのメッセージを「composing」する機能があります。
このリスナーの属性は次の通りです。
1.
name
リスナーインスタンスの名前です。
2.
event-processor
T he event processor class that's called on every schedule trigger. Se above for
implementation details.
3. いずれかひとつ
scheduleidref
このリスナーの起動に使用するスケジュールの scheduleid です。
schedule-frequency
スケジュールの頻度 (秒単位) です。 直接リスナーで簡単にスケジュールを指定する便利な
方法になります。
7.2.4. 設定例
T he following is an example configuration involving the <scheduled-listener> and the <cron-schedule>.
66
第7章 高度なトピック
<?xml version = "1.0" encoding = "UTF-8"?>
<jbossesb
xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jb
ossesb-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"
eventprocessor="org.jboss.soa.esb.schedule.MockScheduledEventMessageComposer" />
</listeners>
<actions>
<action name="action" class="org.jboss.soa.esb.mock.MockAction" />
</actions>
</service>
</services>
</jbossesb>
7.2.5. Quartz Scheduler のプロパティ設定
JBossESB のスケジュール機能は Quartz Scheduler の上に構築されます。 JBossESB で使用されるデ
フォルトの Quartz Scheduler インスタンス設定は以下の通りです。
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
Any of these Scheduler configurations can be overridden, or/and new ones can be added. You can do
this by simply specifying the configuration directly on the <schedule-provider> configuration as a
<property> element. For example, if you wish to increase the thread pool size to 5:
67
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
<schedule-provider name="schedule">
<property name=”org.quartz.threadPool.threadCount” value=”5” />
<cron-schedule scheduleid="cron-trigger" cronExpression="0/1 * * * * ?" />
</schedule-provider>
68
第8章 耐障害性と信頼性
第 8章 耐障害性と信頼性
本章では JBossESB の信頼性に関する特性について説明します。本リリースで耐性がある障害モードにつ
いて検証し、アプリケーションの耐障害性を向上する方法について説明します。本章に目を通す前に、重
要な用語を理解する必要があります。以下のセクションの内容を既に理解している場合は、「信頼性の保
証」 から読み始めても構いません。
ディペンダビリティ とは、配信するサービス (ユーザーによって認識される動作) に正当な信頼が置ける
など、コンポーネントの信用性を意味します。コンポーネントの信頼性は、継続した適切なサービス配信
を示す基準となります。システムが提供するサービスが仕様に適合しなくなると障害が発生します。エ
ラーは障害の原因となるシステム状態の一部で、不良はエラーの原因となります。
耐障害性 システムとは、コンポーネントの障害が発生しても特定の目的を達成するよう設計されたシステ
ムです。通常、耐障害性を提供するための技術は、整合状態回復のメカニズムや故障したコンポーネント
により生成されるエラーを検出するメカニズムを必要とします。レプリケーションやトランザクションな
ど、複数の耐障害性の技術が存在します。
8.1. 障 害 の 分 類
システム上で稼働しているアプリケーションが適切であるか検証する前に、システムの動作を正式に記述
する必要があります。これにより、アプリケーションの動作制限を確立し、この制限を緩和または強化す
る意味を明確にします。
耐障害性に関して正式な記述を行うメソッドとして、発生すると考えられる障害の種類によってシステム
コンポーネントを分類するメソッドを推奨します。
各コンポーネントには特定の入力セットに対するそのコンポーネントの正しい動作を記す関連詳細があり
ます。 障害のない コンポーネントはこの詳細に一致する出力を生成します。 障害のあるコンポーネント
からの応答は詳細通りではない必要があります。 何でも構いません。 特定の入力に対する特定のコン
ポーネントからの応答は、 出力値が正しいだけでなくその出力の生成が時間通りである場合に正しいとみ
なされます。 つまり出力が指定制限時間内に生成されるということです。
起こりうる障害を 4 つに分類すると、脱落、値、タイミング、任意になります。
脱落の不良／障害
コンポーネントが別のコンポーネントからの入力に応答せず、予期される出力を生成しない場
合、脱落の不良とそれに関連する脱落の障害が発生していることになります。メッセージを紛失
することのある通信リンクなどが、脱落の不良が発生しているコンポーネントの例になります。
値の不良／障害
正しい時間間隔内にコンポーネントが応答しても、値が正しくないような不良を値の不良と呼び
ます (これに関連する障害は 値の障害 と呼ばれます)。破損したメッセージを時間通りに配信す
る通信リンクには値の不良が発生しています。
タイミングの不良／障害
タイミングの不良は、コンポーネントが正しい値で応答しても指定された間隔で応答しない (早
すぎるか遅すぎる) 原因となります。この不良に関連する障害はタイミングの障害です。正しい
値を生成するのに応答に過度の遅延があるオーバーロードしたプロセッサにはタイミングの障害
が発生しています。タイミングの障害は、計算を時間的に制約するシステム内でのみ発生しま
す。
任意の不良／障害
69
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
前述の障害クラスは、その値または時間ドメインでコンポーネントがどのように失敗するかを指
定するものでした。前述の障害クラスが適応されない方法でコンポーネントが両方のドメインで
失敗する可能性もあります。このような出力を生成する障害コンポーネントは任意の障害 (ビザ
ンチン障害) が発生していると言えます。
任意の不良はコンポーネントの指定動作に対するあらゆる違反の原因となります。 他の不良タイプはすべ
て特定タイプの不良動作については除外します。 脱落の不良タイプはもっとも限定的となります。 した
がって、 不良分類の分布帯で言えば脱落と任意の不良はこの分布帯の両端となり、 他の不良タイプがそ
の中間に位置することになります。 このため、 後ろの方の障害分類はそれより前に位置する障害分類の
特徴を包含することになります。 つまり、 脱落不良 (障害) は値またはタイミングの不良 (障害)の特殊な
ケースとして扱うことができます。 こうした順序は以下のように階層で表すことができます。
図 8.1 不良分類の階層
8.1.1. JBossESB と不良モデル
JBossESB 内では、すべてが任意の障害によって影響を受けます。ご想像の通り、任意の障害を検出する
のは本質的に大変困難です。任意の障害に対する耐性をシステムに持たせるプロトコルは存在しますが、
何段階もの調整やデジタル署名が必要になる場合がほとんどです。JBossESB の今後のリリースでは、こ
うした方法の一部がサポートされる見込みです。
値、タイミング、脱落の障害にはアプリケーションに関するセマンティック情報が必要となることが多い
ため、JBossESB が直接このような障害タイプに対応できることは限られています。しかし、メッセージ
ヘッダー内で RelatesT o や MessageID などの JBossESB の機能を正しく使用すると、アプリケーション
によって、受信したメッセージが受信待ちのメッセージであるか遅延のメッセージであるかを判断するこ
とができます。一方向要求に対する非同期の一方向応答など、サービスによる提供が早すぎたメッセージ
は、基礎のトランスポート実装が原因で損失する可能性があります。たとえば、HT T P などのプロトコル
を使用する場合、応答がアプリケーションに渡されるまで応答を保持できる有限のバッファがあります
(オペレーティングシステムレベルで設定される)。このバッファの容量を越えると、新しいメッセージを
保持するためバッファ内の情報が失われることがあります。この制限によって FT P や SQL などのトラン
スポートが必ずしも影響を受けるとは限りませんが、同様の動作を生じるような他のリソース制限を受け
る可能性があります。
遅延のメッセージに対して耐性を持たせる方が早着のメッセージに対して耐性を持たせるより簡単な場合
があります。しかし、アプリケーションの観点では、早着のメッセージが失われると (バッファのオー
バーフローなどにより)、無限に遅れるメッセージとの区別がつかなくなります。そのため、メッセージ損
失の際に再試行のメカニズムを使用するようアプリケーション (コンシューマとサービス) を構築する場
70
第8章 耐障害性と信頼性
合、コンシューマが順序を無視して早い応答を受け取って不適切に処理するという例外 (これにより値の
障害が発生します) にてタイミングと脱落の障害に対応できるようにします。メッセージヘッダー内で
RelatesT o と MessageID を使用すると、ペイロード全体を処理しなくても不適切なメッセージシーケン
スを見つけることができます (別のオプションを使用することもできます)。
同期された要求と応答の対話パターン内では、応答が一定の時間内に受信されないと RPC で構築された
システムの多くは自動的に要求を再送信します。しかし、現在の JBossESB は自動的に再送信を行わない
ため、Couriers または ServiceInvoker 内でタイムアウトのメカニズムを使用し、いつメッセージを再送信
するか（または再送信する必要があるか）を判断しなければなりません。高度なトピックの章にある通
り、メッセージの配信に影響するようなサービスの障害発生が疑われる場合、そのメッセージを再送信し
ます。
注記
メッセージをサービスに再送信する場合は注意してください。現在、JBossESB には保持される結
果やサービス内の再送の検出といった概念はないため、重複するメッセージもサービスへ自動的に
配信されます。そのため、サービスが同じメッセージを複数回受け取る可能性があります (損失し
たのが最初の要求ではなく最初のサービス応答だった場合など)。このように、サービスは同じ作
業を実行しようとすることがあります。再送信を使用する場合 (明示的または ServiceInvoker の
フェールオーバーメカニズムを使用)、必ず冪等になるようサービス内で複数の要求を処理する必
要があります。
トランザクションの使用 (JBossT S で提供されるものなど) やレプリケーションプロトコル (JGroups の
ようなシステムで提供される) はこうした障害モデルの多くに対して耐障害性を持たせるのに役立ちま
す。 さらに、 障害が原因で先に進めない状態の場合、 トランザクションを使用するとアプリケーション
のロールバックが可能になり、 基礎となるトランザクションシステムはまるでその作業がまったく試行さ
れなかったかのように表示してデータの整合性を保証します。 現在の JBossESB は JBoss Application
Server 内にデプロイされると JBossT S を通じてトランザクション的なサポートを提供します。
8.1.2. 障害検出機能と障害推測機能
理想的な障害検出機能とは、分散システム内でエンティティ (プロセスやマシンなど) の活発さをはっきり
と判定できる機能のことです。しかし、障害が発生したシステムと応答が遅いシステムを区別することは
不可能なため、一定時間内に障害の検出を保証するのは不可能です。
現在の障害検出機能は、エンティティが使用できるかを判断するためにタイムアウト値を使用します。た
とえば、マシンが指定時間内に「are-you-alive?」というメッセージに応答しない場合、障害が発生した
と想定します。こうしたタイムアウトに割り当てられる値が正しくない場合 (ネットワークの混雑などが
原因で)、正しくない障害が想定され、一部のマシンが別のマシンの障害を「検出」するのに他のマシンは
検出しないなど矛盾を招く可能性があります。したがって、ネットワークの混雑やマシンの負荷が最悪な
場合など、使用される分散環境内で想定できる最悪の事態に対して、通常こうしたタイムアウトが割り当
てられます。しかし、分散システムやアプリケーションが実行の度に予期した通りに動作することはまず
ありません。したがって、想定する最悪の事態が変化することも考えられる上、障害検出に対して間違っ
た判断をする可能性は常にあります。
障害の検出を保証することは不可能ですが、既知のアクティブなエンティティは相互に通信することがで
きるため、通信できないエンティティは障害が発生していると合意することができます。これが障害推測
機能の動作になります。あるエンティティが別のエンティティに障害が発生していると予測した場合、残
りのエンティティー間でプロトコルが実行され、障害発生の合意を問います。エンティティの障害発生に
合意した場合、障害が発生していると見られるエンティティはシステムから除外され、その後このエン
ティティによる動作は許可されません。1 つのエンティティが障害の発生を予測しても、すべてのエン
ティティが同じような判断をするとは限りません。障害が発生していないエンティティがシステムから除
外された場合は、別のプロトコルを実行して活動状態であることを認識させなければなりません。
71
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
障害推測機能の長所は、分散環境内で正しく機能しているすべてのエンティティが、障害の発生が疑われ
る別のエンティティの状態について合意することです。短所は、障害推測のプロトコルは重く、一般的に
複数回の合意が必要となることです。また、タイムアウト値に基づいて障害が推測されるため、障害のな
いエンティティが除外されることもあり、(重大となる可能性のある) リソースの利用や可用性が低下しま
す。
障害検出のメカニズムが時折、 誤った答えを返す可能性があるという事実に耐性を持つことができるアプ
リケーションもあります。 ただし、 これ以外他のアプリケーションの場合、 エンティティが活発である
という誤った判定はデータ破損などの問題を招くおそれがあり、 ミッションクリティカルなアプリケー
ション (航空機制御システムや原子炉監視など) の場合などは人命に関わる結果となる可能性があります。
現在の JBossESB は障害検出または障害推測をサポートしていません。 この短所については将来的なリ
リースで対応していきたいと考えています。 現在のところ、 前述のような特定のサービスに障害が発生
しているのかどうかを判定試行する技術 (MessageID およびタイムアウト／再試行) を使用するコン
シューマー側とサービスは利用側で開発して頂く必要があります。 アプリケーションに障害の検出から疑
わしい障害の処理まで行わせた方がより効率的な場合もあります。
8.2. 信 頼 性 の 保 証
見てきたように、 分散システム内で障害が発生する恐れのある状況は多くあります。 このセクションで
は障害がどのように JBossESB およびそれにデプロイされたアプリケーションに影響を及ぼすのかについ
て具体的な例を説明していきます。 推奨のセクションでは、 こうした障害によりよい耐性を持たせるた
めの JBossESB 設定方法やアプリケーション開発を前提とした設定方法について見ていきます。
JBossESB 内には多くのコンポーネントやサービスがあります。 障害発生時に依存するアプリケーション
の一部またはすべてに対して認識できない可能性がある障害がいくつかあります。 たとえば、 コン
シューマー側がサービスが機能するために必要な EPR 情報をすべて完全に取得してしまった後にレジス
トリサービスがクラッシュすると、 アプリケーションに不都合な影響はありません。 しかし、 これより
前に障害が発生すると、 アプリケーションは先に進めなくなります。 したがって、 いずれの信頼性保証
の判定においても、 障害が発生した時期また障害の種類を考慮する必要があります。
信頼性や耐障害性を 100 % 保証することは不可能です。ハードウェアの障害や人的エラーをなくすこと
はできません。しかし、システムが障害に耐えられる可能性を高くしたり、データの整合性を維持して向
上することは可能です。トランザクションやレプリケーションなどの耐障害性技術はパフォーマンスに影
響します。アプリケーションの知識に基づいてパフォーマンスと耐障害性の妥協点を見つけるのが最良の
方法です。特定の方法をすべてのアプリケーションに対して一様に使用すると、その方法が必要でない状
況下ではパフォーマンスの劣化につながります。そのため、JBossESB によってサポートされる耐障害性
技術の多くはデフォルトで無効になっています。耐障害性技術は必要に応じて有効にするようにしてくだ
さい。
8.2.1. メッセージの損失
メッセージの紛失や遅延がどのようにアプリケーションに対して悪影響を与える可能性があるのかについ
ては既に見てきました。 また、 JBossESB 内でどのようにメッセージがなくなってしまうのかについて
も例をいくつか見てきました。 このセクションではメッセージ紛失についてもう少し詳しく見ていくこと
にします。
多くの分散システムがポイントツーポイント (1 コンシューマー側と 1 プロバイダ) またはグループベース
(複数のコンシューマー側と 1 プロバイダ) で信頼できるメッセージ配信をサポートしています。 一般的に
信頼性に課されるセマンティックとは、 たとえ障害が存在していてもメッセージが配信されるまたはメッ
セージが受信者に届かなかったことを確実に送信者が知ることができるということになります。 信頼でき
るメッセージング実装を採用しているシステムは受信者にメッセージが配信されるのとそのメッセージが
受信者によって処理されるのとは区別する場合が多く、 たとえば、 単にサービスにメッセージが届くと
いうのと、 サービスがメッセージの内容を処理する時間を確保する前にクラッシュが続けて発生した状況
72
第8章 耐障害性と信頼性
とは区別されます。
メッセージの配信や処理で前述の障害セマンティックを提供するトランスポートで、JBossESB 内で使用
できるのは JMS のみです。トランザクション処理されるセッションでは (JMSEpr のオプション部分)、
障害が存在していてもメッセージの受信や処理を保証することが可能です。サービスによる処理中に障害
が発生した場合、メッセージが後で再処理されるよう JMS キューに戻されます。しかし、トランザク
ション処理されるセッションはトランザクション処理されないセッションより大幅に遅くなることがある
ため、使用には注意が必要です。
JBossESB によってサポートされる他のトランスポートは、トランザクションや確実な配信についての保
証がないため、メッセージが損失する可能性はあります。しかし、ほとんどの場合でメッセージ損失の可
能性は低くなります。送信側と受信側の両方で同時に障害が発生しない限り (このような障害が発生する
ことはまずありませんが、起こり得ます)、送信側は JBossESB によってメッセージ配信の障害に関する
通知を受けます。処理中に受信側に障害が発生し、応答が予期されていた場合、受信側は最終的にタイム
アウトするため再試行できます。
注記
非同期メッセージの配信を使用すると障害の検出／推測が難しくなる可能性があります (理論的に
は不可)。 アプリケーションを開発する際はこの点を考慮にいれてください。
こうした理由から、高度なトピックの章に説明がある再配信プロトコルとメッセージフェールオーバーが
最良のアプローチであると言えます。サービスの障害を予測すると、代替の EPR (1 つが利用可能と仮定)
を選択して使用します。しかし、予測した障害が発生していなかった場合は、複数のサービスが同じメッ
セージで同時に動作する可能性があります。そのため、フェールオーバーにはロバストなアプローチです
が、使用する場合は注意が必要です。このアプローチは、同じメッセージを複数回実行することと 1 回実
行することが同じ場合など、サービスがステートレスで冪等である場合に最適なアプローチです。
多くのサービスおよびアプリケーションに対してこのタイプの再配信メカニズムは適切に動作します。 単
一の ERP 全体にわたり提供される堅固さは大きな利点となるでしょう。 クライアントとサービスが失敗
するまたはサービスに誤って障害が発生したとみなされるなど、 動作しない状況の障害モードはかなり珍
しいことになります。 サービスをべき等にできない場合は、 JBossESB がメッセージのトランザクショ
ン的配信か維持される結果のなんらかの形式をサポートするまで、 JMS を使用するかサービスが再送信
を検出して同じ作業を同時に実行している複数のサービスに対処できるコードを使用してください。
8.2.2. エンドポイントの障害を疑う
We saw earlier how failure detection/suspicion is difficult to achieve. In fact until a failed machine
recovers, it is not possible to determine the difference between a crashed machine or one that is simply
running extremely slowly. Networks can also become partitioned - a situation where the network
becomes divided, and effectively acts as two or more separate networks. When this happens consumers
on different parts of the network can only see the services available in their part of the network. T his is
sometimes called "split-brain syndrome".
8.2.3. サポート対象となるクラッシュ障害モード
トランザクションや、JMS などの確実なメッセージ配信プロトコルを使用する場合、JBossESB はシステ
ム全体がシャットダウンするような破滅的な障害から回復することができます。
トランザクションや確実なメッセージ配信プロトコルを使用しない場合、関係するエンドポイントの可用
性が保証される場合のみ JBossESB は障害に対応できます。
8.2.4. コンポーネント固有
73
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
本セクションでは JBossESB 内の特定のコンポーネントおよびサービスについて説明します。
8.2.5. ゲートウェイ
ゲートウェイでメッセージが受け取られると、 信頼できないトランスポートを使って ESB 内に送信しな
い限りメッセージが失われることはありません。 JMS、 FT P、 SQL などの JBossESB トランスポートは
すべてメッセージを確実に配信するまたはシステムから絶対に削除されないようにするよう設定すること
ができます。 残念ながら HT T P はこのようには設定できません。
8.2.6. ServiceInvoker
ServiceInvoker は非同期で送信された不達のメッセージを再配信キューに配置します。メッセージの同期
配信に失敗すると、送信側へ直ちに通知されます。ServiceInvoker が正しく機能するためには、トランス
ポートによって配信の失敗を送信側に明確に知らせなければなりません。送信側と受信側で同時に障害が
発生すると、メッセージが損失することがあります。
8.2.7. JMS ブローカー
JMS ブローカーに配信できないメッセージは再配信キューに置かれます。エンタープライズデプロイメン
トにはクラスタ化された JMS ブローカーが推奨されます。
8.2.8. アクションパイプライン
多くの分散システムと同様、サービスが存在する場所内にあるコンテナが受信するメッセージと、最終的
な送り先で処理されるメッセージを区別します。メッセージが正しく配信されても、アクションパイプラ
イン内での処理中にエラーやクラッシュが発生するとメッセージを損失することがあります。前述の通
り、受信したメッセージが処理中に削除されないように JBossESB トランスポートの一部を設定し、エ
ラーやクラッシュが発生してもメッセージを損失しないようにすることができます。
8.3. 推 奨
上記で説明してきたような障害モデルの概要とそれら障害に対する JBossESB 内の耐性機能を考慮し、
次のようなことが推奨されます。
ステートレスで羃等なサービスを開発するようにしてください。不可能な場合は、アプリケーション
が再送信の試行を検出できるように、MessageID を使用してメッセージを特定するようにしてくださ
い。メッセージ送信の再試行を行う場合は、同じ MessageID を使用してください。冪等でなく、再送
信された メッセージを受信すると同じ処理を再度行うようなサービスは、なるべくトランザクション
を使用して MessageID に対してステート移行を記録するようにします。ステートレスサービスを基に
するアプリケーションの方がスケーラビリティが高い傾向にあります。
ステートフルなサービスを開発する場合はトランザクションと JMS 実装を使用してください (できれ
ばクラスタ化する)。
レジストリのクラスタ化を行い、 クラスタ化された耐障害性のあるバックエンドデータベースを使用
して単一障害点がないようにします。
メッセージストアが必ず高可用性のデータベースで支えられているようにします。
他のサービスやオペレーションと比較して、 より高い信頼性や耐障害性の機能を必要とするサービス
およびサービス上のオペレーションを明確に識別しておきます。 これによりこれらのサービスで JMS
以外のトランスポートを対象とすることができるようになり、 アプリケーション全体のパフォーマン
スを向上させることができる場合があります。 JBossESB により別々の EPR を通じて同時にサービ
スが使用されるようにすることが可能なため、 こうした異なるサービスの特性 (QoS) をアプリケー
ション固有の必要条件に応じて異なるコンシューマー側に提供することも可能になります。
ネットワークのパーティションはサービスが失敗しているかのように表示する可能性があるため、 ク
ラッシュしたように誤って識別されることに対処できないサービスに対してはこの種の障害が起きる
傾向にあるトランスポートの使用は避けてください。
74
第8章 耐障害性と信頼性
In some situations (e.g., HT T P) the crash of a server after it has dealt with a message but before it
has responded could result in another server doing the same work because it is not possible to
differentiate between a machine that fails after the service receives the message and process it, and
one where it receives the message and doesn't process it.
非同期 (一方向) の配信パターンを使用するとサービスの障害検出が困難になります。これは、要求へ
の応答が任意の時間に到達できる場合、一般的に損失メッセージや遅延メッセージの概念がないから
です。応答が全くない場合は障害の検出がより難しくなるため、アプリケーションセマンティックに
依存してメッセージの不達を判断しなければならない場合もあります (例：銀行口座の残高が予期した
金額と異なる)。ServiceInvoker または Couriers を使用して非同期のメッセージを配信する場合、各操
作 (deliverAsync など) から返答があってもメッセージがサービスによって動作したとは限りません。
メッセージストアは再配信プロトコルによって使用されますが、前述の通り、このプロトコルはロバ
スト性の向上に最善のプロトコルであり、トランザクションや確実なメッセージ配信を使用しませ
ん。そのため、障害によってはメッセージが全て損失したり (クラッシュの前にメッセージがストアに
書き込まれない)、メッセージが複数回配信される原因となることがあります (再配信のメカニズムが
ストアからメッセージを取り出して無事配信するが、クラッシュによってメッセージがストアから削
除されず、クラッシュから回復した後にメッセージが再度配信される)。
FT P など一部のトランスポートは、処理済みのメッセージを保持するよう設定することができます
が、未処理のメッセージと区別するため独自にマークされます。通常、デフォルトでは処理された
メッセージは削除されますが、障害から回復した際に、アプリケーションが処理されたメッセージを
判別できるよう、デフォルトを変更することもできます。
本章では障害について説明してきましたが障害は頻繁に発生するわけではありません。 年月をかけてハー
ドウェアの信頼性は飛躍的に向上され、 公式の検証ツールの使用を含め活発なソフトウェア開発が行われ
ることによりソフトウェア関連の問題も少なくなってきました。 サービスやアプリケーションを開発、
デプロイしていく上で適切な方法を判断するのに役立つよう本章では障害についての説明をしています。
パフォーマンスを低減させるような高いレベルでの信頼性や耐障害性が必ずしもすべてに必要なわけでは
ありませんが、 間違いなく必要とするものもあるからです。
75
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
第 9章 サービス設定の定義
9.1. 概 要
JBoss ESB サービス設定は、 XSD
(http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd)
に基づいています。 この XSD は常に ESB 設定の最終的な参照となります。
このモデルは次の 2 つの主要セクションから構成されます。
<providers>
T his part of the model centrally defines all the message <bus> providers used by the message
<listener>s, defined within the <services> section of the model.
<services>
T his part of the model centrally defines all of the services under the control of a single instance
of JBoss ESB. Each <service> instance contains either a “Gateway” or “Message Aware”
listener definition.
このモデルに基づいて構成を行う最も簡単な方法は、 JBoss Developer Studio の XML Editor など XSD
対応の XML エディタを使用することです。このエディタは構成の編集中に自動補完の機能を提供しま
す。
9.2. Providers
T he <providers> part of the configuration defines all of the message <provider> instances for a single
instance of the ESB. T wo types of providers are currently supported:
バスプロバイダ
T hese specify provider details for "Event Driven" providers i.e. for listeners that are "pushed"
messages. Examples of this provider type would be the <jms-provider>.
スケジュールプロバイダ
Provider configurations for schedule driven listeners i.e. listeners that "pull" messages.
A Bus Provider (e.g. <jms-provider>) can contain multiple <bus> definitions. T he <provider> can also be
decorated with <property> instances relating to provider specific properties that are common across all
<bus> instances defined on that <provider> (e.g. for JMS - "connection-factory", "jndi-context-factory"
etc). Likewise, each <bus> instance can be decorated with <property> instances specific to that <bus>
instance (e.g. for JMS - "destination-type", "destination-name" etc).
例として JMS のプロバイダ構成を以下に示します。
76
第9章 サービス設定の定義
<providers>
<provider name="JBossMQ">
<property name="connection-factory" value="ConnectionFactory" />
<property name="jndi-URL" value="jnp://localhost:1099" />
<property name="protocol" value="jms" />
<property name="jndi-pkg-prefix" value="com.xyz"/>
<bus busid="local-jms">
<property name="destination-type" value="topic" />
<property name="destination-name" value="queue/B" />
<property name="message-selector" value="service='Reconciliation'"
<property name=”persistent” value=”true”/>
</bus>
</provider>
</providers>
T he above example uses the “base” <provider> and <bus> types. T his is perfectly legal, but we
recommend use of the specialized extensions of these types for creating real configurations, namely
<jms-provider> and <jms-bus> for JMS. T he most important part of the above configuration is the busid
attribute defined on the <bus> instance. T his is a required attribute on the <bus> element/type
(including all of its specializations - <jms-bus> etc). T his attribute is used within the <listener>
configurations to refer to the <bus> instance on which the listener receives its messages. More on this
later.
9.3. サ ー ビ ス
T he <services> part of the configuration defines each of the Services under the management of this
instance of the ESB. It defines them as a series of <service> configurations. A <service> can also be
decorated with the following attributes.
表 9.1 サービス属性
名前
説明
タイプ
必須
name
サービスレジストリ内で登録されるサービスのサービス名
xsd:string
true
カテゴリ
サービスレジストリ内で登録されるサービスのサービスカ
テゴリ
xsd:string
true
詳細
読みやすい形式のサービス詳細、 リジストリ内に格納され
る
xsd:string
true
A <service> may define a set of <listeners> and a set of <actions>. T he configuration model defines a
“base” <listener> type, as well as specializations for each of the main supported transports i.e. <jmslistener>, <sql-listener> etc.
T he base <listener> defines the following attributes. T hese attribute definitions are inherited by all
<listener> extensions. T hey can be set for all of the listeners and fateways supported by JBoss ESB
including the InVM transport.
77
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
表 9.2 リスナーの属性
名前
説明
タイプ
必須
name
リスナーの名前、 この属性は主にログの目的で必要となる
xsd:string
true
busrefid
Reference to the busid of the <bus> through which the
listener instance receives messages.
xsd:string
true
maxT hread
s
リスナーがアクティブとして持てる同時メッセージ処理ス
レッドの最大数
xsd:int
T rue
is-gateway
リスナーインスタンスが「ゲートウェイ」であるかないか
xsd:boolean
true
は関係ありません。
[a]
[a] メッセージバスは特定のメッセージチャンネル／トランスポートの詳細を定義します。
Listeners can define a set of zero or more <property> elements (just like the <provider> and <bus>
elements/types). T hese are used to define listener specific properties.
注記
サービス内で定義される各ゲートウェイリスナーに対しては、 ESB 対応のリスナー (または「ネイ
ティブ」) も定義されなければなりません。 ゲートウェイリスナーは双方向のエンドポイントを定
義するのではなく ESB への「スタートポイント」を定義するためです。 ESB 内からメッセージを
ゲートウェイに送ることはできません。 また、 ゲートウェイはエンドポイントではないため、 リ
ジストリ内に維持されるエンドポイント参照 (EPR) はありません。
An example of a <listener> reference to a <bus> can be seen in the following illustration (using “base”
types only).
A Service will do little without a list of one or more <actions>. <action>s typically contain the logic for
processing the payload of the messages received by the service (through it's listeners). Alternatively, it
may contain the transformation or routing logic for messages to be consumed by an external
Service/entity.
T he <action> element/type defines the following attributes.
78
第9章 サービス設定の定義
表 9.3 アクションの属性
名前
説明
タイプ
必須
name
アクションの名前、 この属性は主にログの目的で必要とな
る
xsd:string
true
クラス
org.jboss.soa.esb.actions.ActionProcessor
実装クラス名
xsd:string
true
プロセス
メッセージ処理に反射的に呼び出される「process」メ
ソッドの名前 (デフォルトは ActionProcessor クラス
で定義されるように「process」メソッドとなる)
xsd:int
false
In a list of <action> instances within an <actions> set, the actions are called (their “process” method is
called) in the order in which the <action> instances appear in the <actions> set. T he message returned
from each <action> is used as the input message to the next <action> in the list.
Like a number of other elements/types in this model, the <action> type can also contain zero or more
<property> element instances. T he <property> element/type can define a standard name-value-pair, or
contain free form content (xsd:any). According to the XSD, this free form content is valid child content for
the <property> element/type no matter where it is in the configuration (on any of <provider>, <bus>,
<listener> and any of their derivatives). However, it is only on <action> defined <property> instances
that this free form child content is used.
As stated in the <action> definition above, actions are implemented through implementing the
org.jboss.soa.esb.actions.ActionProcessor class. All implementations of this interface must contain a
public constructor of the following form:
public ActionZ(org.jboss.soa.esb.helpers.ConfigTree configuration);
このコンストラクタはアクションの属性を付けて ConfigT ree のインスタンスを与えます。 アクションプ
ロパティのインスタンスからの自由形式コンテンツもこれに含まれます。
So an example of an <actions> configuration might be as follows:
<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. ト ラ ン ス ポ ー ト 固 有 タ イ プ の 実 装
T he JBoss ESB configuration model defines transport specific specializations of the “base” types
<provider>, <bus> and <listener> (JMS, SQL etc). T his allows us to have stronger validation on the
configuration, as well as making configuration easier for those that use an XSD aware XML Editor (e.g.
the Eclipse XML Editor). T hese specializations explicitly define the configuration requirements for each
79
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
of the transports supported by JBoss ESB out of the box. It is recommended to use these specialized
types instead of the “base” types when creating JBoss ESB configurations, the only alternative being
where a new transport is being supported outside an official JBoss ESB release.
「基底」タイプから構成を行っている場合に適用される同じ基本の原則がトランスポート固有の代替から
構成を行う場合にも適用されます。
1. Define the provider configuration e.g. <jms-provider>.
2. Add the bus configurations to the new provider (e.g. <jms-bus>), assigning a unique busid
attribute value.
3. Define your <services> as normal, adding transport specific listener configurations (e.g. <jmslistener> that reference (using busidref) the new bus configurations you just made e.g. <jmslistener> referencing a <jms-bus>.
T he only rule that applies when using these transport specific types is that you cannot cross reference
from a listener of one type, to a bus of another type i.e. you can only reference a <jms-bus> from a <jmslistener>. A runtime error will result where cross references are made.
このため、 本リリースに配備されるトランスポート固有の実装は次のようになります。
JMS
<jm s-provider>, <jm s-bus>, <jm s-listener> and <jm s-m essage-filter>: T he <jm sm essage-filter> can be added to either the <jm s-bus> or <jm s-listener> elements. Where the
<jm s-provider> and <jm s-bus> specify the JMS connection properties, the <jm s-m essagefilter> specifies the actual message QUEUE/T OPIC and selector details.
SQL
<sql-provider>, <sql-bus>, <sql-listener> and <sql-m essage-filter>: T he <sqlm essage-filter> can be added to either the <sql-bus> or <sql-listener> elements. Where the
<sql-provider> and <ftp-bus> specify the JDBC connection properties, the <sql-m essagefilter> specifies the message/row selection and processing properties.
FT P
<ftp-provider>, <ftp-bus>, <ftp-listener> and <ftp-m essage-filter>: T he <ftpm essage-filter> can be added to either the <ftp-bus> or <ftp-listener> elements. Where the
<ftp-provider> and <ftp-bus> specify the FT P access properties, the <ftp-m essage-filter>
specifies the message/file selection and processing properties
ハイバネート
<hibernate-provider>, <hibernate-bus>, <hibernate-listener> : T he <hibernatem essage-filter> can be added to either the <hibernate-bus> or <hibernate-listener>
elements. Where the <hibernate-provider> specifies file system access properties like the
location of the hibernate configuration property, the <hibernate-m essage-filter> specifies what
classnames and events should be listened to.
ファイルシステム
<fs-provider>, <fs-bus>, <fs-listener> and <fs-m essage-filter> T he <fs-m essagefilter> can be added to either the <fs-bus> or <fs-listener> elements. Where the <fsprovider> and <sql-bus> specify the File System access properties, the <fs-m essage-filter>
specifies the message/file selection and processing properties.
80
第9章 サービス設定の定義
スケジュール
<schedule-provider>. T his is a special type of provider and differs from the bus based providers
listed above. See Scheduling for more.
JMS/JCA 統合
<jm s-jca-provider>: T his provider can be used in place of the <jm s-provider> to enable
delivery of incoming messages using JCA inflow. T his introduces a transacted flow to the action pipeline,
encompassing actions within a JT A transaction.
As you'll notice, all of the currently implemented transport specific types include an additional type not
present in the “base” types, that being <*-message-filter>. T his element/type can be added inside either
the <*-bus> or <*-listener>. Allowing this type to be specified in both places means you can specify
message filtering globally for the bus (for all listeners using that bus), or locally on a listener by listener
basis.
注記
それぞれのトランスポート固有タイプの属性一覧と詳細を表示するには、 各属性に関する全詳細が
記載されている jbossesb-1.0.1 XSD を使用することができます。Eclipse XML Editor など XSD
対応の XML エディタを使用するとこうしたタイプでの作業が非常に容易になります。
表 9.4 JMS メッセージフィルタ設定
プロパティ名
説明
必須
dest-type
宛先のタイプ (QUEUE または T OPIC)
Yes
dest-name
Queue または T opic の名前
Yes
selector
複数のリスナーを同じキュー/トピックで登録できるようにします。
ただし、リスナーはこのメッセージセレクタに基づいてフィルタリ
ングされます。
No
persistent
JMS の配信モードを永続的にするかどうかを指定します。値は真ま
たは偽です。デフォルト値は真です。
No
acknowledgemode
JMS セッション確認モード。AUT O_ACKNOWLEDGE、
CLIENT _ACKNOWLEDGE、DUPS_OK_ACKNOWLEDGE のいずれ
かの値になります。デフォルト値は AUT O_ACKNOWLEDGE で
す。
No
jms-securityprincipal
JMS 宛先ユーザー名。宛先への接続を作成するときに使用されま
す。
No
jms-securitycredential
JMS 宛先パスワード。宛先への接続を作成するときに使用されま
す。
No
構成例:
81
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
<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. FTP プ ロ バ イ ダ 構 成
82
第9章 サービス設定の定義
表 9.5 FT P プロバイダ構成
プロパティ
説明
必須
hostname
Can be a combination of <host:port> of just <host> which will
use port 21.
Yes
username
FT P 接続に使用されるユーザー名
Yes
password
上記ユーザーのパスワード
Yes
directory
着信する新しいファイルについてモニタリングされる FT P ディレク
トリ
Yes
input-suffix
T he file suffix used to filter files targeted for consumption by the
ESB (note: add the dot, so something like '.esbIn'). T his can also be
specified as an empty string to specify that all files should be
retrieved.
Yes
work-suffix
T he file suffix used while the file is being process, so that another
thread or process won't pick it up too. Defaults to .esbInProcess.
No
post-delete
true の場合、 ファイルは処理後に削除される。 この場合、 postdirectory および post-suffix は無効になる。デフォルト値は真。
No
post-directory
ESB による処理後にファイルの移動先となる FT P ディレクトリ。デ
フォルト値は上記のディレクトリです。
No
post-suffix
処理後にファイル名に追加されるファイルサフィックス。デフォル
ト値は .esbDone。
No
error-delete
真の場合、 処理中にエラーが発生するとこのファイルは削除され
る。 この場合、 error-directory および error-suffix は無効となるの
で注意。デフォルト値は真。
No
error-directory
処理中にエラーが発生した場合にファイルの移動先となる FT P ディ
レクトリ。デフォルト値は上記のディレクトリ。
No
error-suffix
処理中にエラーが発生した場合にファイル名に追加されるファイル
サフィックス。デフォルト値は .esbError。
No
protocol
次のいずれかのプロトコル
No
sftp (SSH ファイル転送プロトコル)
ftps (FT P over SSL)
ftp (デフォルト)
passive
FT P接続がパッシブ状態であることを示します。この値を新に設定
すると、FT P クライアントが FT P サーバーに対して 2 つの接続を
確立します。デフォルト値は偽であり、クライアントは FT P サー
バーが接続するポートを FT P サーバーに指示する。次に FT P サー
バーはクライアントに対する接続を確立します。
No
read-only
真の場合、 FT P サーバーはファイルに対する書き込み操作を許可し
ない。 この場合、 次のプロパティは無効となるので注意: worksuffix、post-delete、post-directory、post-suffix、error-delete、
error-directory、および error-suffix。デフォルトは偽。詳細について
は、「読み取り専用 FT P リスナー」のセクションを参照。
No
certificate-url
FT PS サーバー検証のためのパブリックサーバー証明書の URL また
は SFT P クライアント検証のためのプライベート証明書の URL。
SFT P 証明書は、デプロイメント成果物内に組み込まれたリソース
として存在します。
No
certificate-name
FT PS サーバー検証のための証明書の一般名
No
83
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
certificatepassphrase
SFT P クライアント検証用プライベート鍵のパスフレーズ
No
9.6. FTP リ ス ナ ー の 構 成
設定されたスケジュール (scheduleidref) を基にリモートのファイルに対してポーリングを行うリスナーを
スケジュールします。「サービススケジューリング」を参照してください。
9.6.1. 読み取り専用 FTP リスナー
FT P プロバイダのプロパティ「read-only」を true に設定するとリモートファイルシステムは書き込み動
作を許可しないことをシステムに指示します。 パーミッションが特定ファイルに与えられるようなメイン
フレームコンピュータで FT P サーバーが稼働している場合によく見られるケースです。
読み取り専用実装は JBoss T reeCache を使用して読み取られているファイル名の一覧を保持し、 前に読
み取られたことがなかったものだけをフェッチします。 キャッシュは cacheloader を使用して設定し、
安定したストレージに対してそのキャッシュを永続化する必要があります。
キャッシュからファイル名を削除する手段が存在しなければならないので注意してください。 定期的に別
の場所にファイルを移動するメインフレーム上のアーカイブ機能プロセスなどが該当します。 キャッシュ
からのファイル名削除は、 2、 3 日置きにキャッシュからファイル名を削除するデータベース手順を設け
ることなどで行うことができます。 キャッシュからファイル名を立ち退かせる場合に cacheloader からも
そのファイル名を削除する T reeCacheListener を指定するのも別の手段となります。 立ち退き期間は設
定可能となります。これは FT P リスナー構成でプロパティ (removeFilesystemStrategy-cacheListener)
を設定することにより行うことができます。
表 9.6 読み取り専用 FT P リスナーの構成
名前
説明
scheduleidref
FT P リスナーによって使用されるスケジュール。「サービススケジューリング」
を参照。
remoteFilesystem
Strategy-class
実装するクラスでリモートファイルシステムの方法を上書きする:
org.jboss.soa.esb.listeners.gateway.rem otestrategies.Rem ote
FileSystem Strategy。デフォルト値は
org.jboss.soa.esb.listeners.gateway.rem otestrategies.ReadOn
lyRem oteFileSystem Strategy。
remoteFilesystem
Strategy-configFile
ローカルファイルシステムまたはクラスパスに存在する JBoss T reeCache 設定
ファイルを指定します。デフォルトではクラスパスのルートに存在する
/ftpfile-cache-config.xm l という名前のファイルを検索します。
removeFilesystem
StrategycacheListener
JBoss T reeCacheListener 実装が T reeCache で使用されることを指定す
る。デフォルト値は T reeCacheListener。
maxNodes
キャッシュに格納されるファイルの最大数。0 は制限無しを意味する。
timeT oLiveSecond
s
ノードが一掃されるまでのアイドル時間 (秒単位)。0 は制限無しを意味する。
maxAgeSeconds
ノードが一掃されるまでにアイドル時間に関係なくオブジェクトが T reeCache 内
に存在する時間 (秒単位)。0 は制限無しを意味する。
構成例:
84
第9章 サービス設定の定義
<ftp-listener name="FtpGateway"
busidref="helloFTPChannel"
maxThreads="1"
is-gateway="true"
schedule-frequency="5">
<property name="remoteFileSystemStrategy-configFile" value="./ftpfile-cacheconfig.xml"/>
<property name="remoteFileSystemStrategy-cacheListener"
value="org.jboss.soa.esb.listeners.gateway.remotestrategies.cache.DeleteOnEvictTreeC
acheListener"/>
</ftp-listener>
JBoss キャッシュ構成例の一部:
<region name="/ftp/cache">
<attribute name="maxNodes">5000</attribute>
<attribute name="timeToLiveSeconds">1000</attribute>
<attribute name="maxAgeSeconds">86400</attribute>
</region>
T he helloworld_ftp_action quickstart demonstrates the read-only configuration. Run 'ant help' in the
helloworld_ftp_action quickstart directory for instructions on running the quickstart. Please refer to the
JBoss Cache documentation for more information about the configuration options available
(http://labs.jboss.com/jbosscache/docs/index.html).
9.7. 旧 構 成 モ デ ル か ら の 移 行
本セクションは XSD ベースではない 旧 JBoss ESB 構成モデルで使い慣れている開発者を対象としてい
ます。
旧構成モデルは ESB コンポーネント付きの自由形式の XML 構成を使用し、 その設定を
org.jboss.soa.esb.helpers.ConfigT ree のインスタンス経由で受け取っていました。新しい構
成モデルは XSD ベースとなりますが、 基礎となるコンポーネント構成パターンはいまだ
org.jboss.soa.esb.helpers.ConfigT ree のインスタンス経由になります。 つまり、 現在、 XSD ベースの
構成は ConfigT ree スタイルの設定にマッピング/変換されるということになります。
旧モデルの使用に慣れている開発者の方々は次の点に注意して頂く必要があります。
1. Read all of the docs on the new configuration model. Don't assume you can infer the new
configurations based on your knowledge of the old.
2. T he only location where free-form markup is supported in the new configuration is on the
<property> element/type. T his type is allowed on <provider>, <bus> and <listener> types (and
sub-types). However, the only location in which <property> based free form markup is mapped
into the ConfigT ree configurations is where the <property> exists on an <action>. In this case, the
<property> content is mapped into the target ConfigT ree <action>. Note however, if you have 1+
<property> elements with free form child content on an <action>, all this content will be
concatenated together on the target ConfigT ree <action>.
3. When developing new Listener/Action components, you must ensure that the ConfigT ree based
configuration these components depend on can be mapped from the new XSD based
configurations. An example of this is how in the ConfigT ree configuration model, you could decide
to supply the configuration to a listener component via attributes on the listener node, or you could
decide to do it based on child nodes within the listener configuration. T his type of free form
configuration on <listener> components is not supported on the XSD to ConfigT ree mapping i.e.
85
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
the child content in the above example would not be mapped from the XSD configuration to the
ConfigT ree style configuration. In fact, the XSD configuration simply would not accept the arbitrary
content, unless it was in a <property> and even in that case (on a <listener>), it would simply be
ignored by the mapping code.
9.8. 構 成
コア内のコンポーネントはすべてその設定パラメータを XML として受け取ります。 これらのパラメータ
がどのようにシステムに提供されるのかは
org.jboss.soa.esb.param eters.Param RepositoryFactory によって隠されます。
public abstract class ParamRepositoryFactory
{
public static ParamRepository getInstance();
}
これは異なる実装を許可する org.jboss.soa.esb.param eters.Param Repository インター
フェースの実装を返します。
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.param eters.Param FileRepository の実装 1 つのみなります。 1 ファイ
ルからのパラメータのロードが可能であることを期待します。 使用する実装は
org.jboss.soa.esb.paramsRepository.class プロパティを使って上書きが可能です。
注記
ESB 設定ファイルは Eclipse または何らかの XML エディタを使って作成することをお勧めしま
す。 JBossESB 設定情報はアノテーション付き XSD でサポートされ、 基本的なエディタを使うと
作成が容易になるはずです。
86
第10章 Web サービスサポート
第 10章 Web サービスサポート
10.1. JBossWS
JBossESB は、Web サービスのエンドポイントを公開し呼び出すための Web サービスベースのコンポー
ネントを複数持っています。
SOAPProcessor
SOAPProcessor アクションにより、JBossWS 2.x とそれ以降の Web サービスエンドポイン
トを、ESB 上で稼働しているエンドポイント (リスナ) より公開することができます。これは、
独自の Web サービスを提供しないサービスでも公開が可能です。この JBossESB アクションを
使用して公開される JBossWS の Web サービスエンドポイントは ESB Message を認識し、
ESB によってサポートされるすべてのトランスポートチャネル 上で Web サービスエンドポイン
トを呼び出すことができます。
また、バス上の SOAP とも呼ばれます。
SOAPClient
SOAPClient アクションにより、Web サービスエンドポイント上で呼び出しができます。
また、バス外の SOAP とも呼ばれます。
設定やコンポーネントの使用についての詳細は、「 Webservices/SOAP」 を参照してください。
87
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
第 11章 事前定義されたアクション
このセクションでは、JBoss ESB にデフォルトで含まれるすべてのアクションのカタログを提供します。
11.1. ト ラ ン ス フ ォ ー マ と コ ン バ ー タ
コンバータ/トランスフォーマは、 あるメッセージ交換参加側によって生成された形式を別のメッセージ
交換参加側によって消費できる形式にメッセージを変換する役割を担うアクションプロセッサの分類で
す。
特別に指定されていない限り、 これらのアクションはすべてメッセージペイロードのアクセスには
MessagePayloadProxy を使用します。
11.1.1. ByteArrayToString
入力タイプ
byte[ ]
クラス
org.jboss.soa.esb.actions.converters.ByteArrayT oString
byte[] ベースのメッセージペイロードを取得して java.lang.String オブジェクトインスタンスに
変換します。
表 11.1 ByteArrayT oString のプロパティ
プロパティ
説明
必須
encoding
メッセージバイト配列でのバイナリデータエンコーディングで
す。 指定されていない場合はデフォルトで UT F-8 に設定され
ます。
No
例 11.1 ByteArrayT oString
<action name="transform"
class="org.jboss.soa.esb.actions.converters.ByteArrayToString">
<property name="encoding" value="UTF-8" />
</action>
11.1.2. ObjectInvoke
入力タイプ
ユーザーオブジェクト
出力タイプ
ユーザーオブジェクト
クラス
org.jboss.soa.esb.actions.converters.ObjectInvoke
メッセージペイロードとしてバインドされたオブジェクトを取得して、 処理するために設定された
processor にそれを与えます。 処理結果は新しいペイロードとしてメッセージに再びバインドされます。
表 11.2 ObjectInvoke のプロパティ
プロパティ
説明
必須
class-processor
メッセージペイロードの処理に使用されるプロセッサクラスの
ランタイムクラス名です。
Yes
class-method
メソッドの処理に使用されるプロセッサクラスのメソッド名で
す。 デフォルト値はそのアクション名になります。
No
88
第11章 事前定義されたアクション
例 11.2 ObjectInvoke
<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>
11.1.3. ObjectToCSVString
入力タイプ
ユーザーオブジェクト
出力タイプ
java.lang.String
クラス
org.jboss.soa.esb.actions.converters.ObjectT oCSVString
メッセージペイロードとしてバインドされたオブジェクトを取得して、 与えられたメッセージオブジェク
トおよびコンマで区切られた bean-properties リストプロパティに応じてコンマで区切られた値 (CSV) の
文字列に変換します。
表 11.3 ObjectT oCSVString プロパティ
プロパティ
説明
必須
bean-properties
出力 CSV 文字列に対する CSV 値の取得に使用するオブジェク
ト Bean プロパティ名の一覧です。 オブジェクトは一覧の各プ
ロパティに対して getter メソッドをサポートする必要がありま
す。
Yes
fail-on-missingproperty
オブジェクトがプロパティの getter メソッドをサポートしない
場合にアクションが失敗するかどうかを示すフラグです。 デ
フォルト値は false です。
No
例 11.3 ObjectT oCSVString
<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>
11.1.4. ObjectToXStream
入力タイプ
ユーザーオブジェクト
出力タイプ
java.lang.String
クラス
org.jboss.soa.esb.actions.converters.ObjectT oXStream
メッセージペイロードとしてバインドされる XML を取得して、 XStream プロセッサを使ってオブジェク
トに変換します。
89
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
表 11.4 ObjectT oXStream のプロパティ
プロパティ
説明
必須
class-alias
Class alias used in call to XStream .alias(String,
Class) prior to serialization. T he default is the input Object's
class name.
No
exclude-package
生成される XML からパッケージ名を除くかどうかを示す
Boolean フラグです。 デフォルトは true です。 このプロパ
ティは class-alias が指定されると適用されません。
No
aliases
XStream による XML エレメントのオブジェクトへの変換を可
能にする追加のエイリアスを指定します。
No
namespaces
XStream によって生成された XML に追加する必要がある名前
空間を指定します。 各 namespace-uri はこのネームスペース
が出現するエレメントとなるローカルの部分に関連付けられま
す。
No
xstream-mode
Specifies the XStream mode to use.Possible values are
XPAT H_RELAT IVE_REFERENCES,
XPAT H_ABSOLUT E_REFERENCES>, ID_REFERENCES,
NO_REFERENCES.
No
例 11.4 ObjectT oXStream
<action name="transform"
class="org.jboss.soa.esb.actions.converters.ObjectToXStream">
<property name="class-alias" value="MyAlias" />
<property name="exclude-package" value="true" />
</action>
例 11.5 aliases と namespaces を使った ObjectT oXStream
<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” value=”com.acme.MyXXXClass1/>
<alias name=”alias2” value=”com.acme.MyXXXClass2/>
<alias name=”xyz” value=”com.acme.XyzValueObject”/>
<alias name=”x” value=”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>
</action>
11.1.5. XStreamToObject
90
第11章 事前定義されたアクション
入力タイプ
java.lang.String
出力タイプ
ユーザーオブジェクト
クラス
org.jboss.soa.esb.actions.converters.XStream T oObject
メッセージペイロードとしてバインドされる XML を取得して、 XStream プロセッサを使ってオブジェク
トに変換します。
表 11.5 XStreamT oObject のプロパティ
プロパティ
説明
必須
class-alias
Class alias used during serialization. Defaults to the input
object's class name.
No
exclude-package
XML にパッケージ名を含めるかどうかを示す Boolean フラグで
す。
必須
incoming-type
XML が表すオブジェクトのタイプおよび返されるオブジェクト
のタイプ
Yes
root-node
XML 内の実際のルートノードとは異なるルートノードを指定す
る XPath 式です。
No
aliases
XStream による XML エレメントのオブジェクトへの変換を可
能にする追加のエイリアスです。
No
attribute-aliases
Xstream による XML 属性のオブジェクトへの変換を可能にす
る追加の属性エイリアスです。
No
converters
Xstream による XML エレメントと属性のオブジェクトへの変
換を可能にするコンバータの指定に使用されます。 コンバータ
の詳細について
は、http://xstream.codehaus.org/converters.html を参照してく
ださい。
No
<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" value="com.acme.MyXXXClass1" />
<alias name="alias2" value="com.acme.MyXXXClass2" />
...
</property>
<property name="attribute-aliases">
<attribute-alias name="alias1" value="com.acme.MyXXXClass1" />
<attribute-alias name="alias2" value="com.acme.MyXXXClass2" />
...
</property>
<property name="converters">
<converter class="com.acme.MyXXXConverter1" />
<converter class="com.acme.MyXXXConverter2" />
...
</property>
</action>
11.1.6. SmooksTransformer
91
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
クラス
org.jboss.soa.esb.actions.converters.Sm ooksT ransform er
JBoss ESB でのメッセージ変換は Sm ooksT ransform er コンポーネントによってサポートされていま
す。 ESB アクションコンポーネントであり、 Smooks データ変換/処理フレームワークを ESB アクショ
ン処理パイプラインにプラグインできるようにします。
SmooksT ransformer コンポーネントでは広範なデータ形式 (XML、 Java、 CSV、 EDI など) が入出力い
ずれに対してもサポートされています。 また、 たった 1 つのフレームワーク内で広範囲に渡る変換技術
がサポートされています。
重要
Sm ooksT ransform er は今後のリリースで廃止される予定です。 用途の広い柔軟な Smooks ア
クションクラスの詳細については Sm ooksAction を参照してください。
表 11.6 SmooksT ransformer のプロパティ
プロパティ
説明
必須
resource-config
Smooks のリソース設定ファイル
Yes
from
メッセージ交換参加者名、 メッセージ生成者
No
from-type
from メッセージ交換参加者によって作成されたメッセージタイ
プ/形式
No
to
メッセージ交換参加者名、 メッセージ消費者
No
to-type
to メッセージ交換参加者によって消費されるメッセージタイプ/
形式
No
上記のプロパティはすべてメッセージにプロパティとして与えることにより上書きが可能です
(Message.Properties)。
例 11.6 デフォルトの入力 /出力
<action name="transform"
class="org.jboss.soa.esb.actions.converters.SmooksTransformer">
<property name="resource-config" value="/smooks/config-01.xml" />
</action>
例 11.7 指定の入力 /出力
<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>
92
第11章 事前定義されたアクション
例 11.8 メッセージプロファイルを使用
<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 オブジェクトはその beanId の下の Message.Body にバインドされます
(http://milyn.codehaus.org/javadoc/v1.0/smookscartridges/javabean/org/milyn/javabean/BeanPopulator.html)。 詳細については、『JBoss SOA サービス
ガイド』 [2] または http://wiki.jboss.org/wiki/Wiki.jsp?page=MessageT ransformation を参照してくださ
い。
11.1.7. SmooksAction
SmooksAction クラスの org.jboss.soa.esb.sm ooks.Sm ooksAction は Smooks のプロセスを実行
する第 2 世代 ESB アクションクラスです 。 単純なメッセージ変換以上のことを行うことができます。
SmooksT ransformer アクションは 今後の ESB のリリースでは廃止される予定です (最後は削除)。
T he SmooksAction class can process (using Smooks PayloadProcessor) a wider range of ESB
Message payloads e.g. Strings, byte arrays, InputStreams, Readers, POJOs and more. As such, it can
perform a wide range of transformations including Java to Java transforms. It can also perform other
types of operations on a Source messages stream, including content based payload Splitting and
Routing (not ESB Message routing). T he SmooksAction enables the full range of Smooks capabilities
from within JBoss ESB.
以下は基本的な SmooksAction 設定を示しています。
<action name="transform" class="org.jboss.soa.esb.smooks.SmooksAction">
<property name="smooksConfig" value="/smooks/order-to-java.xml" />
</action>
93
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
表 11.7 SmooksAction オプションとなる設定プロパティ
プロパティ
説明
デフォルト値
get-payload-location
メッセージペイロードに含まれるメッセージボ
ディの位置
デフォルトのペイロー
ド位置
set-payload-location
結果となるペイロードが配置されるメッセージボ
ディの位置。
デフォルトのペイロー
ド位置
excludeNonSerializable
s
Exclude non Serializable Objects when mapping
the contents of the Smooks ExecutionContext
back onto the ESB Message.
true
resultT ype
結果となるメッセージペイロードとして設定され
る結果のタイプ。
ST RING
javaResultBeanId
注記: resultT ype=JAVA の場合のみ重要
T he Smooks bean context beanId to be mapped
as the result when the resultT ype is "JAVA". If
not specified, the whole bean context bean Map is
mapped as the JAVA result.
reportPath
T he path and file name for generating a Smooks
Execution Report. T his is a development aid i.e.
not to be used in production.
メッセージ入力ペイロード
T he SmooksAction uses the ESB MessagePayloadProxy class for getting and setting the message
payload on the ESB Message. T herefore, unless otherwise configured via the “get-payload-location”
and “set-payload-location” action properties, the SmooksAction gets and sets the Message payload on
the default message location (i.e. using Message.getBody().get() and Message.getBody().set(Object)).
As stated above, the SmooksAction automatically supports a wide range of Message payload types.
T his means that the SmooksAction itself can handle most payload types without requiring “fixup”
actions before it in the action chain.
XML、 EDI、 CSV などの入力ペイロード
SmooksAction を使ったこれらのメッセージタイプの処理にはソースメッセージを文字列、 InputStream、
Reader、 またはバイト配列で与えるだけです。
Apart from that, you just need to perform the standard Smooks configurations (in the Smooks config, not
the ESB config) for processing the message type in question e.g. configure a parser if it's not an XML
Source (e.g. EDI, CSV etc).
Java 入力ペイロード
提供されたメッセージペイロードがタイプ String、InputStream、Reader、または byte[] のいずれかでな
い場合、SmooksAction は JavaSource としてペイロードを処理し、Java から XML、Java 対 Java などの
変換を実行できるようになります。
結果タイプの指定
Because the Smooks Action can produce a number of different Result types, you need to be able to
specify which type of Result you want. T his effects the result that's bound back into the ESB Message
94
第11章 事前定義されたアクション
payload location.
デフォルトでは ResultT ype は ST RING ですが、resultT ype 設定プロパティをセットすることにより
BYT ES、 JAVA、 NORESULT にすることもできます。
Specifying a resultT ype of JAVA allows you to select one or more Java Objects from the Smooks
ExecutionContext (specifically, the bean context). T he javaResultBeanId configuration property
complements the resultT ype property by allowing you to specify a specific bean to be bound from the
bean context to the ESB Message payload location. T he following is an example that binds the “order”
bean from the Smooks bean context onto the ESB Message as the Message payload.
<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>
11.1.8. PersistAction
入力タイプ
メッセージ
出力タイプ
入力メッセージ
クラス
org.jboss.soa.esb.actions.MessagePersister
MessageStore との対話に使用されます。
表 11.8 PersistAction のプロパティ
プロパティ
説明
必須
classification
メッセージが格納される場所を分類するために使用されます。
メッセージプロパティ
org.jboss.soa.esb.m essagestore.classification
が Message で定義されるとそれが代わりに使用されます。 こ
れ以外はインスタンス作成時にデフォルトを与えることができ
ます。
Yes
message-store-class
MessageStore の実装です。
Yes
terminal
true にセットすると、 このアクションは処理パイプラインを
終了するため入力メッセージが処理から返されます。 デフォル
ト値は false です。
No
例 11.9 PersistAction
<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>
11.2. ビ ジ ネ ス プ ロ セ ス 管 理
95
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
11.2.1. jBPM - BpmProcessor
入力タイプ
AbstractCom m andVehicle.toCom m andMessage() で生成される
org.jboss.soa.esb.m essage.Message
出力タイプ
Message – 入力メッセージと同じ
クラス
org.jboss.soa.esb.services.jbpm .actions.Bpm Processor
JBoss ESB Services は Bpm Processor Action を使って jBPM コマンドを呼び出すことができます。
Bpm Processor Action は jBPM へのアクセスにjBPM コマンド API を使用します。
jBPM からの ESB サービスのアクセス方法を含む jBPM 統合の詳細については、『JBoss Enterprise SOA
Platform サービスガイド』 [3] を参照してください。
次の jBPM コマンドが実装されています。
NewProcessInstanceCom m and
StartProcessCom m and
SignalCom m and
CancelProcessInstanceCom m and
setProcessInstanceVariables
96
第11章 事前定義されたアクション
表 11.9 BpmProcessor のプロパティ
プロパティ
説明
必須
command
呼び出されている jBPM コマンドです。 許容値が 必要です。
Yes
NewProcessInstanceCom m and
StartProcessInstanceCom m and
SignalCom m and
CancelProcessInstanceCom m and
processdefinition
process-definition-id プロパティが与えられない場合はこれが
NewProcessInstanceCom m and と
StartProcessInstanceCom m and のコマンドに必要となる
プロパティです。 このプロパティの値は作成したい新規の
jBPM インスタンスにすでにデプロイされているプロセス定義
を参照しなければなりません。 このプロパティは
SignalCom m and と CancelProcessInstanceCom m and
には適用されません。
場合による
process-definition-id
processdefinition プロパティが与えられない場合に
NewProcessInstanceCom m and と
StartProcessInstanceCom m and のコマンドにのみ必要と
なります。 このプロパティの値は作成したい jBPM の新規イン
スタンスのプロセス定義 ID を参照しなければなりません。 こ
のプロパティは SignalCom m and と
CancelProcessInstanceCom m and には適用されません。
場合による
actor
jBPM actor id を指定します。
NewProcessInstanceCom m and と
StartProcessInstanceCom m and のコマンドにのみ適用さ
れます。
No
key
Specify the value of the jBPM key. On the jBPM side this key is
as the "business" key id field. T he key is a string based
business key property on the process instance. T he
combination of business key and process definition must be
unique if a business key is supplied. For example, a unique
invoice id could be used as the value for this key.
No
キーの値は EsbMessage から目的の値を抽出する MVEL 表現
を保持できます。 たとえば、 メッセージのボディに
businessKey という名前のパラメータがある場合は
body.businessKey を使用します。 このプロパティ
はNewProcessInstanceCom m and と
StartProcessInstanceCom m and のコマンドにのみ使用さ
れます。
transition-name
このプロパティは StartProcessInstanceCom m and と
SignalCom m and のコマンドにのみ適用され、 transition が
複数定義されている場合にノードから使用する transition を指
定します。 このプロパティが指定されていない場合はノードか
らのデフォルトの transition が取得されます。 デフォルトの
transition は jBPM processdefinition.xm l の該当ノード
に定義された transition 一覧の最初の transition になります。
No
esbT oBpmVars
このプロパティは、 EsbMessage から抽出し、 特定のプロセ
No
97
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
スインスタンスの jBPM コンテキストに設定する必要がある変
数のリストを定義します。 このリストはマッピングエレメント
から構成されます。 各マッピングエレメントは以下の属性を持
つことができます。
esb: EsbMessage のどこからでも値を抽出するために
MVEL 式を含めることができる必須属性。
bpm : jBPM 側で使用できる名前を含むオプション属性。 省
略された場合は、 esb 名が使用されます。
default: esb MVEL 式が EsbMessage で設定された値を
見つけることができない場合にデフォルト値を保持できる
オプション属性。
reply-to-originator:
NewProcessInstanceCom m and と
StartProcessInstanceCom m ands のオプションプロパ
ティ。 true の値を使用してこのプロパティが指定された
場合は、 プロセスインスタンスの作成により起動メッセー
ジの ReplyT o および FaultT o EPR がプロセスインスタ
ンス内に格納されます。 これらの値は、 後続
のEsbNotifier とEsbActionHandler の呼び出しで
メッセージを ReplyT o および FaultT o アドレスに配信
するために使用できます。
これは、 NewProcessInstanceCom m and、
StartProcessInstanceCom m and、 および
SignalCom m and によってのみ使用されます。
例 11.10 jBPM - BpmProcessor
<action name="create_new_process_instance"
class="org.jboss.soa.esb.services.jbpm.actions.BpmProcessor">
<property name="command" value="StartProcessInstanceCommand" />
<property name="process-definition-name" value="processDefinition2"/>
<property name="actor" value="FrankSinatra"/>
<property name="esbToBpmVars">
<!-- esb-name maps to getBody().get("eVar1") -->
<mapping esb="eVar1" bpm="counter" default="45" />
<mapping esb="BODY_CONTENT" bpm="theBody" />
</property>
</action>
11.3. ス ク リ プ ト
スクリプトアクションプロセッサはスクリプト言語を使用してアクション処理ロジックの定義をサポート
します。
11.3.1. GroovyActionProcessor
クラス
org.jboss.soa.esb.actions.scripting.GroovyActionProcessor
このアクションは Groovy アクション処理スクリプトを実行し入力としてメッセージとアクション構成を
受け取ります。 Groovy の詳細については http://groovy.codehaus.org/ をご覧ください。
98
第11章 事前定義されたアクション
表 11.10 GroovyActionProcessor のプロパティ
プロパティ
説明
script
クラスパス内のスクリプトのパスです。
supportMessageBasedScripting
メッセージ内でスクリプトの使用を許可し
ます。
cacheScript
スクリプトをキャッシュします。 デフォル
トの設定は true です。
必須
No
表 11.11 GroovyAction Processor Script Binding の変数
変数
説明
message
メッセージ
payloadProxy
メッセージペイロードのユーティリティ (MessagePayloadProxy)
config
アクション設定 (ConfigT ree)
logger
T he GroovyActionProcessor's static Log4J logger (Logger)
例 11.11 GroovyActionProcessor
<action name="process"
class="org.jboss.soa.esb.scripting.GroovyActionProcessor">
<property name="script" value="/scripts/myscript.groovy"/>
</action>
11.3.2. ScriptingAction
クラス
org.jboss.soa.esb.actions.scripting.ScriptingAction
Bean Scripting Framework (BSF) を使用してスクリプトを実行し、 メッセージ、 payloadProxy、 アク
ション設定、 ロガーを可変の入力として受け取ります。 詳細については http://jakarta.apache.org/bsf/ を
参照してください。
JBoss ESB 4.4 には BSF 2.3.0 が含まれます。 これは Groovy または Rhino に対応しません。 今後の
バージョンには BSF 2.4.0 を含ませてこうした言語に対応する予定です。
BSF はスクリプトのプレコンパイル、 キャッシュ、 および再使用を行う API を提供していません。
ScriptingAction を実行するたびにコンパイルを再度行うことになります。 パアプリケーションのフォーマ
ンス要件を評価する際には、 この点を考慮に入れる必要があります。
JBoss BSHDeployer が .bsh を検出してデプロイの試行を行わないよう、 BeanShell スクリプトには
.bsh ではなく .beanshell のファイル名拡張子を使用してください。
99
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
表 11.12 ScriptingAction のプロパティ
プロパティ
説明
script
クラスパス内のスクリプトのパスです。
supportMessageBasedScripting
メッセージ内でスクリプトの使用を許可し
ます。
language
この値はスクリプトを記述する言語を指定
します。 この値を与えないとファイル名の
拡張子に応じて推定されます。
必須
No
表 11.13 ScriptingAction Processor Script Binding の変数
変数
説明
message
メッセージ
payloadProxy
メッセージペイロードのユーティリティ (MessagePayloadProxy)
config
アクション設定 (ConfigT ree)
logger
T he ScriptingAction's static Log4J logger (Logger)
例 11.12 ScriptingAction
<action name="process"
class="org.jboss.soa.esb.scripting.ScriptingAction">
<property name="script" value="/scripts/myscript.beanshell"/>
</action>
11.4. サ ー ビ ス
ESB サービス内で定義されたアクション。
11.4.1. EJBProcessor
入力タイプ
EJB のメソッド名とパラメータ
出力タイプ
EJB 固有のオブジェクト
クラス
org.jboss.soa.esb.actions.EJBProcessor
入力メッセージを取得してステートレスセッション Bean の呼び出しにその内容を使用します。 このアク
ションは EJB2.x と EJB3.x に対応します。
100
第11章 事前定義されたアクション
表 11.14 EJBProcessor のプロパティ
プロパティ
説明
ejb3
EJB3.x セッション Bean に対する呼び出しがどうかを示す
Boolean フラグです。
ejb-name
EJB の アイデンティティです。 ejb3 が true の場合にオプ
ションとなります。
jndi-name
関連する JNDI ルックアップです。
initial-context-factory
JNDI ルックアップのメカニズムです。
provider-url
関連するプロバイダです。
method
呼び出す EJB メソッド名です。
ejb-params
メソッドを呼び出すときにメソッドが存在する入力メッセージ
の位置で使用するパラメータの一覧です。
esb-out-var
出力の位置です。 デフォルト値は DEFAULT _EJB_OUT です。
必須
No
例 11.13 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>
101
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
11.5. ル ー テ ィ ン グ
ルーティングアクションは 2 つ以上のメッセージ交換参加者間でのメッセージの条件ルーティングをサ
ポートします。
11.5.1. Aggregator
クラス
org.jboss.soa.esb.actions.Aggregator
メッセージ集約アクション。 Aggregator Enterprise Integration Pattern の実装です。 この開発パターン
に関する詳細は http://www.enterpriseintegrationpatterns.com/Aggregator.html でご覧ください。
このアクションは正しい相関データを持つすべてのメッセージに依存します。 このデータは
aggregatorT ag (Message.Properties) という名前のプロパティとしてメッセージに設定されます。
また、 「ContentBasedRouter」 と 「StaticRouter」 も参照してください。
T he data has the following format:
[UUID] ":" [message-number] ":" [message-count]
すべてのメッセージがアグリゲータによって受け取られた場合は、 Message.Attachment 一覧 (名前なし)
の一部としてすべてのメッセージを含む新しいメッセージを返します。 これ以外、 アクションは null を
返します。
表 11.15 アグリゲータのプロパティ
プロパティ
説明
必須
timeoutInMillis
集約プロセスがタイムアウトするまでのミリ秒単位の時間で
す。
No
例 11.15 Aggregator
<action class="org.jboss.soa.esb.actions.Aggregator" name="Aggregator">
<property name="timeoutInMillis" value="60000"/>
</action>
11.5.2. EchoRouter
EchoRouter は着信メッセージのペイロードを情報ログストリームにエコーしてプロセスメソッドから入
力メッセージを返します。
11.5.3. HttpRouter
現在、 コードベースには 2 種類の HttpRouter アクションがあります。 JBoss Remoting を使用して
HT T P 呼び出しを行うものと Apache Commons HttpClient を使用するものです。 本セクションでは両方
共説明していきます。
11.5.3.1. JBoss Remoting HttpRouter
クラス
102
org.jboss.soa.esb.actions.routing.HttpRouter
第11章 事前定義されたアクション
重要
JBoss Remoting HttpRouter は混同を避けるため廃止されます。
このアクションはさらに処理を行うために着信メッセージを URL に転送します。
表 11.16 JBoss Remoting HttpRouter のプロパティ
プロパティ
説明
必須
routeUrl
メッセージの転送先となるエンドポイントです。 デフォルト値
は localhost:54 00 です。
No
11.5.3.2. Apache Commons HttpRouter
クラス
org.jboss.soa.esb.actions.routing.http.HttpRouter
このアクションにより ESB アクションパイプラインから外部の ESB 認識しない Http エンドポイントの呼
び出しを許可します。 このアクションは Apache Commons HttpClient を使って実装します。
表 11.17 Apache Commons HttpRouter
プロパティ
説明
必須
endpointUrl
メッセージの転送先となるエンドポイントです。
Yes
http-client-property
HttpRouter は HttpClientFactory を使って HttpClient インスタンスの
作成と構成を行います。 ローカルのファイルシステム、 クラスパス
または URI ベースのプロパティファイルをポイントするファイルプ
ロパティを使ってファクトリの構成を指定することができます。 ど
のようにして行うかを下の例に示します。 ファクトリのプロパティ
についての詳細は http://www.jboss.org/community/docs/DOC-9969
を参照してください。
No
method
現在 GET と POST のみのサポートです。
Yes
responseT ype
応答が返される形式を指定します。 ST RING か BYT ES になり、 デ
フォルト値は ST RING です。
No
headers
Http headers T o be added to the request. Supports multiple
<header name=”blah” value=”blahvalue”/> elements.
No
例 11.16 httprouter
<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>
103
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
11.5.4. JMSRouter
クラス
org.jboss.soa.esb.actions.routing.JMSRouter
受信メッセージを JMS にルーティングします。
表 11.18 JMSRouter
プロパティ
説明
必須
unwrap
true にセットするとメッセージオブジェクトからのメッセー
ジのペイロードが抽出されて送信されます。 これ以外はメッ
セージオブジェクト全体が送信されます。 デフォルトは
false です。
No
jndi-context-factory
使用する JNDI コンテキストファクトリです。 デフォルトは
org.jnp.interfaces.Nam ingContextFactory です。
No
jndi-URL
使用する JNDI URL です。 デフォルトは 127.0.0.1:1099 で
す。
No
jndi-pkg-prefix
使用する JNDI 命名パッケージのプレフィックスです。 デフォ
ルトは org.jboss.nam ing:org.jnp.interfaces です。
No
connection-factory
使用する ConnectionFactory の名前です。 デフォルトは
ConnectionFactory です。
No
persistent
JMS の DeliveryMody です。 デフォルト値は true です。
No
priority
使用される JMS の優先度です。 デフォルトは
javax.jm s.Message.DEFAULT _PRIORIT Y です。
No
time-to-live
使用される JMS の T ime-T o-Live です。 デフォルトは
javax.jm s.Message.DEFAULT _T IME_T O_LIVE です。
No
security-principal
JMS 接続の作成時に使用するセキュリティプリンシパルです。
Yes
security-credentials
JMS 接続の作成時に使用するセキュリティクレデンシャルで
す。
Yes
property-strategy
デフォルトを上書きする場合の JMSPropertiesSetter イン
ターフェイスの実装です。
No
message-prop
メッセージで設定されるプロパティには m essage-prop とい
うプレフィックスが付けられます。
11.5.5. ContentBasedRouter
クラス
org.jboss.soa.esb.actions.ContentBasedRouter
コンテンツ (およびルール) ベースのメッセージルーティングアクション。
ContentBasedRouter has two process methods. process doesn't append aggregation data to
message. split does append aggregation data to message. See 「Aggregator」 for more details.
詳細については、『JBoss Enterprise SOA Platform サービスガイド (JBoss Enterprise SOA Platform
Services Guide)』 [4] の章「コンテンツベースルーティング (Content Based Routing)」を参照してくださ
い。
104
第11章 事前定義されたアクション
表 11.19 ContentBasedRouter
プロパティ
説明
ruleSet
JBoss Rules のルールセットです。
ruleLanguage
CCR 評価のドメイン固有言語 (DSL) ファイルですのファイル
です。
ruleReload
ルールファイルを毎回再ロードするかどうかを示すフラグで
す。 デフォルトは “false” です。
destinations
Container property for the <route-to> configurations.
必須
例 11.17 ContentBasedRouter
<action process="split" name="ContentBasedRouter"
class="org.jboss.soa.esb.actions.ContentBasedRouter">
<property name="ruleSet" value="MyESBRules-XPath.drl"/>
<property name="ruleLanguage" value="XPathLanguage.dsl"/>
<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>
11.5.6. StaticRouter
Static message routing action. T his is basically a simplified version of the Content Based Router that
doesn't support content based routing rules.
クラス
org.jboss.soa.esb.actions.StaticRouter
表 11.20 StaticRouter のプロパティ
プロパティ
説明
必須
destinations
Container property for the <route-to> configurations.
Yes
<route-to destination-name="express"
service-category="ExpressShipping"
service-name="ExpressShippingService"/>
表 11.21 StaticRouter プロセスのメソッド
method
説明
process
Don't append aggregation data to message.
split
メッセージに集約データを追加します。
「Aggregator」 を参照してください。
105
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
例 11.18 StaticRouter
<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>
11.5.7. StaticWireTap
StaticWiretap はパイプライン処理を終わりまで引き起こさない点で StaticRouter と異なります。
クラス
org.jboss.soa.esb.actions.StaticWireT ap
表 11.22 StaticWireT ap のプロパティ
プロパティ
説明
必須
destinations
Container property for the <route-to> configurations.
Yes
<route-to destination-name="express"
service-category="ExpressShipping"
service-name="ExpressShippingService"/>
表 11.23 StaticWireT ap プロセスのメソッド
method
説明
process
Don't append aggregation data to message.
split
メッセージに集約データを追加します。
「Aggregator」 を参照してください。
例 11.19 StaticWireT ap
<action name="routeAction"
class="org.jboss.soa.esb.actions.StaticWiretap">
<property namjbosse="destinations">
<route-to service-category="ExpressShipping"
service-name="ExpressShippingService"/>
<route-to service-category="NormalShipping"
service-name="NormalShippingService"/>
</property>
</action>
106
第11章 事前定義されたアクション
11.6. Notifier
アクションパイプライン処理の結果に基づいて、設定で指定された一連の通知ターゲットに通知を送信し
ます。
アクションパイプラインは、2 つの段階 (通常の処理の後に結果の処理) で機能します。最初の段階では、
パイプラインが、パイプラインの最後に達するまで、またはエラーが発生するまで順番に各アクション
(デフォルトではプロセスと呼ばれます) のプロセスメソッドを呼び出します。この時点でパイプラインは
逆方向に処理され (第 2 段階)、それぞれの前のアクションで結果メソッドを呼び出します (デフォルトは
processException or processSuccess).。これは現在のアクション (成功した最後のアクションまたは例
外が発生したアクション) で開始され、パイプラインの先頭に達するまで逆方向に移動します。Notifier は
第 1 段階でメッセージの処理を行わず (no-op)、第 2 段階で指定された通知を送信するアクションです。
Notifier クラスの設定は NotificationT argets の一覧を指定するために使用できる NotificationList エレメン
トを定義するために使用されます。タイプ “ok” の NotificationList では、アクションのパイプライン処理
が成功したときに通知を受け取るターゲットが指定されます。タイプ “err” の NotificationList では、これ
までに説明したアクションパイプライン処理セマンティクスに応じてアクションパイプライン処理で例外
が発生したときに通知を受け取るターゲットが指定されます。“err” と “ok” は大文字と小文字を区別しま
す。
T he notification sent to the NotificationT arget is target-specific, but essentially consists of a copy of the
ESB message undergoing action pipeline processing. A list of notification target types and their
parameters appears at the end of this section.
If you wish the ability to notify of success or failure at each step of the action processing pipeline, use
the “okMethod” and “exceptionMethod” attributes in each <action> element instead of having an
<action> that uses the Notifier class.
クラス
org.jboss.soa.esb.actions.Notifier
プロパティ
NotificationList subtree indicating targets
設定例
<action 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>
107
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
</property>
</action>
通知はさまざまなタイプのターゲットに送信できます。以下の表は NotificationT arget タイプとそのパラ
メータを示しています。
クラス
NotifyConsole
目的
コンソールに ESB メッセージのコンテンツを出力することにより通知を実行しま
す。
属性
なし
子
なし
子属性
なし
設定例
<target class="NotifyConsole" />
クラス
NotifyFiles
目的
ESB メッセージのコンテンツを指定された一連のファイルに書き込むことによって通
知を実行します。
属性
なし
子
ファイル
子属性
設定例
1. append – 値が true の場合は既存のファイルに通知をアペンドします。
2. URI – ファイルを指定する任意の有効な URI
<target class="NotifyFiles" >
<file append=”true” URI=”anyValidURI”/>
<file URI=”anotherValidURI”/>
</target>
クラス
NotifySQLT able
目的
レコードを既存のデータベーステーブルに挿入することによって通知を実行します。
database table. T he database record contains the ESB message contents and,
optionally, other values specified using nested <column> elements.
属性
子
子属性
設定例
108
1.
2.
3.
4.
5.
6.
driver-class
connection-url
user-name
password
table – 通知レコードが保存されるテーブル
dataColumn – ESB メッセージコンテンツが保存されるテーブル列の名前
列
1. name – 追加の値を保存するテーブル列の名前
2. value – 保存する値
<target class="NotifySQLT able"
第11章 事前定義されたアクション
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>
クラス
NotifyFT P
目的
ESB メッセージコンテンツを含むファイルを作成し、FT P を使用してリモートファ
イルシステムに転送することにより通知を実行します。
属性
なし
子
ftp
子属性
設定例
1. URL – 有効な FT P URL
2. filename – リモートシステムの ESB メッセージコンテンツを含むファイルの名
前
<target class="NotifyFT P" >
<ftp URL=”ftp://username:[email protected]/remote/dir”
filename=”someFile.txt” />
</target>
クラス
NotifyQueues
目的
Performs a notification by translating the ESB message (including its attached
properties) into a JMS message and sending the JMS message to a list of Queues.
Additional properties may be attached using the <messageProp> element.
属性
なし
子
queue
子属性
子
子属性
設定例
1.
2.
3.
4.
5.
jndiName – キューの JNDI 名
jndi-URL – JNDI プロバイダ URL (オプション)
jndi-context-factory – JNDI 初期コンテキストファクトリ (オプション)
jndi-pkg-prefix – JNDI パッケージ接頭辞 (オプション)
connection-factory – JMS 接続ファクトリの JNDI 名 (デフォルトでは
“ConnectionFactory”)
messageProp
1. name – 追加される新しいプロパティの名前
2. value – 新しいプロパティの値
<target class="NotifyQueues" >
109
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
<messageProp name=”aNewProperty” value=”theValue”/>
<queue jndiName=”queue/quickstarts_notifications_queue” />
</target>
クラス
NotifyT opics
目的
Performs a notification by translating the ESB message (including its attached
properties) into a JMS message and publishing the JMS message to a list of T opics.
Additional properties may be attached using the <messageProp> element.
属性
なし
子
topic
子属性
子
子属性
設定例
1.
2.
3.
4.
5.
jndiName – キューの JNDI 名
jndi-URL – JNDI プロバイダ URL (オプション)
jndi-context-factory – JNDI 初期コンテキストファクトリ (オプション)
jndi-pkg-prefix – JNDI パッケージ接頭辞 (オプション)
connection-factory – JMS 接続ファクトリの JNDI 名 (デフォルトでは
“ConnectionFactory”)
messageProp
1. name – 追加される新しいプロパティの名前
2. value – 新しいプロパティの値
<target class="NotifyT opics" >
<messageProp name=”aNewProperty” value=”theValue”/>
<queue jndiName=”topic/quickstarts_notifications_topic” />
</target>
クラス
NotifyEmail
目的
ESB メッセージコンテンツ (オプションで任意の添付ファイルも) を含む電子メール
を送信することにより通知を実行します。
属性
1.
2.
3.
4.
5.
from – email address (javax.email.InternetAddress)
sendT o – カンマ区切り一覧形式の電子メールアドレス
ccT o – カンマ区切り一覧形式の電子メールアドレス (オプション)
subject – 電子メールの件名
message – 電子メールメッセージを構成する ESB メッセージコンテンツに追
加する文字列 (オプション)
6. msgAttachmentName - メッセージペイロードを含む添付のファイル名 (オプ
ション)。指定されない場合は、メッセージペイロードがメッセージボディに含
まれます。
子
添付ファイル (オプション)
子テキスト
添付されるファイルの名前
設定例
<target class="NotifyEmail"
from=”[email protected]”
sendT o=”[email protected]”
110
" ESB Message Aware" Webservice Endpoints
subject=”theSubject”>
<attachment>attachT hisFile.txt</attachment>
</target>
11.7. Webservices/SOAP
11.7.1. JBoss Web サービス SOAPProcessor
T his action supports invocation of a JBossWS hosted webservice endpoint through any JBossESB
hosted listener. T his means the ESB can be used to expose Webservice endpoints for Services that
don't already expose a Webservice endpoint. You can do this by writing a thin Service Wrapper
Webservice (e.g. a JSR 181 implementation) that wraps calls to the target Service (that doesn't have a
Webservice endpoint), exposing that Service via endpoints (listeners) running on the ESB. T his also
means that these Services are invokable over any transport channel supported by the ESB (http, ftp, jms
etc.).
依存関係
1. JBoss Application Server 4.2.0GA またはそれ以降
2. JBossWS 2.0.x またはそれ以降
3. soap.esb サービス。 これはデフォルトで production サーバー構成の一部としてデプロイされ
ます。
JBossWS コンソールは http://localhost:8080/jbossws に存在します。 デプロイされたすべての
JBossWS エンドポイントのリストにアクセスできます。 JBossWS の詳細については、
http://jbossws.jboss.org/mediawiki/index.php?title=JBossWS を参照してください。
"ESB Message Aware" Webservice Endpoints
Note that Webservice endpoints exposed via this action have direct access to the current JBossESB
Message instance used to invoke this action's process(Message) method. It can access the current
Message instance via the SOAPProcessor.getMessage() method and can change the Message
instance via the SOAPProcessor.setMessage(Message) method. T his means that Webservice
endpoints exposed via this action are "ESB Message Aware".
Web サ ー ビ ス エ ン ド ポ イ ン ト デ プ ロ イ メ ン ト
このアクションを使用すると ESB リスナ経由であらゆる JBossWS Webservice エンドポイントを公開す
ることができます。 これには .esb デプロイメントの内部 (つまり、 Webservice .war は .esb 内部にバ
ンドルされます) と外部 (たとえば、 スタンドアローンの Webservice .war のデプロイメント、 .ear 内
部にバンドルされる Webservice .war のデプロイメント) からデプロイされるエンドポイントが含まれま
す。 ただし、 このアクションは .esb デプロイメントが JBoss Application Server にインストールされ
ている場合にのみ使用可能となるという意味になります。 つまり、 JBossESB Server ではサポートされ
ません。
WSDL
WSDLs for Webservices exposed via JBossESB are available through the "Contracts" application
(deployed with the ESB components). T his application can be accessed through your JBoss SOA
Platform Server at http://localhost:8080/contract. T his application lists URLs that can be used by your
Webservice Client (e.g. soapUI) for accessing a Service's WSDL, enabling WSDL based invocation of the
111
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
Service through an ESB Endpoint.
エンドポイントパブリッシングの詳細については、『管理ガイド』 [5] の項「契約パブリッシング
(Contract Publishing)」を参照してください。
JAXB Annotation Introductions
T he native JBossWS SOAP stack uses JAXB to bind to and from SOAP. T his means that an unannotated typeset cannot be used to build a JBossWS endpoint. T o overcome this we provide a
JBossESB and JBossWS feature called "JAXB Annotation Introductions" which basically means you can
define an XML configuration to "Introduce" the JAXB Annotations.
この XML 設定はエンドポイントデプロイメントの MET A-INF ディレクトリ内の jaxb-intros.xm l と
いう名前のファイルにパッケージ化する必要があります。
JBossWS 2.0.0 でこの機能を有効にする方法の詳細については、 付録A JAXB Annotation Introduction の
設定を作成する を参照してください。
アクション設定
T he <action> configuration for this action is very straightforward. T he action requires only one
mandatory property value, which is the jbossws-endpoint property. T his property names the JBossWS
endpoint that the SOAPProcessor is exposing (invoking).
<action name="ShippingProcessor"
class="org.jboss.soa.esb.actions.soap.SOAPProcessor">
<property name="jbossws-endpoint" value="ABI_Shipping"/>
<property name="rewrite-endpoint-url" value="true/false"/>
</action>
ここにあるオプションの rewrite-endpoint-url プロパティは HT T P エンドポイントでの負荷分散をサポー
トします。 この場合、 Webservice エンドポイントのコンテナは WSDL の HT T P(S) エンドポイントアド
レスをロードバランサのものに設定するよう構成されることになります。 rewrite-endpoint-url プロパティ
を使用すると、 このような状況に HT T P エンドポイントアドレスの書き換え機能を無効にすることがで
きるようになります。 HT T P 以外のプロトコルには効果はありません。
クイックスタート
このアクションの使用方法を示すクイックスタートがいくつか用意されています。
webservice_producer クイックスタートを参照してください。
11.7.2. SOAPCLIENT - WISE
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"/>
</action>
オプションプロパティ
112
JAXB Annotation Introductions
プロパティ名
説明
wsdl
使用される WSDL。
SOAPAction
エンドポイント操作。
EndPointName
T he EndPoint invoked. Webservices can have multiple endpoint. If
it's not specified the first specified in wsdl will be used.
SmooksRequestMapper
Specifies a smooks config file to define the java-to-java mapping
defined for the request.
SmooksResponseMapper
Specifies a smooks config file to define the java-to-java mapping
defined for the response
ServiceName
A symbolic service name used by wise to cache object generation
and/or use already generated object. If it isn't provided wise uses
the servlet name of wsdl.
UserName
webservice が BASIC 認証 HT T P により保護されている場合に使用
されるユーザー名。
Password
webservice が BASIC 認証 HT T P により保護されている場合に使用
されるパスワード。
smooksT ransform
It's often necessary to be able to transform the SOAP request or
response, especially in header. T his may be to simply add some
standard SOAP handlers. Wise support JAXWS Soap Handler, both
custom or a predefined one based on smooks.
SOAP 要求の変換 (送信前) は SOAPClient アクションを Smooks 変
換設定プロパティで設定することによってサポートされます。
custom-handlers
It's also possible to provide a set of custom standard JAXWS Soap
Handler. T he parameter accept a list of classes implementing
SoapHandler interface. Classes have to provide full qualified name
and be separated by semi-columns.
LoggingMessages
It's useful for debug purpose to view soap Message sent and
response received. Wise achieve this goal using a JAX-WS handler
printing all messages exchanged on System.out. Boolean value.
SOAP 操作パラメータは以下の 2 つの方法で提供されます。
1. デフォルトのボディ位置に設定された Map インスタンスとして (Message.getBody().add(Map))
2. As a Map instance set on in a named body location (Message.getBody().add(String, Map)), where
the name of that body location is specified as the value of the "paramsLocation" action property.
パラメータ Map 自体にも以下の 2 つのいずれかの方法でデータを入力できます。
1. 任意のタイプのオブジェクトセット。 この場合、 Smooks 設定をアクション属性
SmooksRequestMapper で指定する必要があります。 Smooks は java 同士の変換を行うために使
用されます。
2. With a set of String based key-value pairs(<String, Object>), where the key is the name of the
SOAP parameter as specified in wsdls (or in generated class) to be populated with the key's
value. SOAP Response Message Consumption
SOAP 応答オブジェクトインスタンスは、以下のいずれかの方法で ESB メッセージインスタンスに追加
できます。
1. デフォルトのボディ位置で (Message.getBody().add(Map))
2. On in a named body location (Message.getBody().add(String, Map)), where the name of that body
location is specified as the value of the "responseLocation" action property.
113
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
応答オブジェクトインスタンスには以下の 2 つのいずれかの方法で値を入力できます (SOAP 応答から)。
1. 任意のタイプのオブジェクトセット。 この場合、 Smooks 設定をアクション属性
SmooksResponseMapper で指定する必要があります。 Smooks は java 同士の変換を行うために
使用されます。
2. With a set of String based key-value pairs(<String, Object>), where the key is the name of the
SOAP answer as specified in wsdls (or in generated class) to be populated with the key's value.
JAX-WS Handler for the SOAP Request/Response
SOAPClient の使用例については、 次のクイックスタートを参照してください。
1. webservice_consum er_wise。 基本的な使用方法を説明します。
2. webservice_consum er_wise2, shows how to use'SmooksRequestMapper' and
'SmooksResponseMapper'.
3. webservice_consum er_wise3, shows how to use 'smooks-handler-config'.
4. webservice_consom er_wise4 , shows usage of 'custom-handlers'.
Wise の詳細については、 Web サイト http://www.javalinuxlabs.org/wise を参照してください。
11.7.3. SOAPClient - SOAPUI
ターゲットサービスに対してサービスを構築し、値を入力するために soapUI クライアントサービスを使
用します。 この結果、アクションはサービスにメッセージをルーティングします。 soapUI の詳細につい
ては、 http://www.soapui.org を参照してください。
エンドポイント操作の仕様
Specifying the endpoint operation is a straightforward task. Simply specify the "wsdl" and "operation"
properties on the SOAPClient action as follows:
<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>
SOAP 要 求 メ ッ セ ー ジ の 構 築
SOAP 操作パラメータは以下の 2 つの方法で提供されます。
1. デフォルトのボディ位置 にセットされた Map インスタンスとして
(Message.getBody().add(Map))
2. 指定のボディ位置にセットされた Map インスタンスとして
(Message.getBody().add(String, Map))、 ボディ位置の名前は get-payloadlocation アクションプロパティの値として指定されます。
パラメータ Map 自体も以下の 2 つのいずれかの方法で移植できます。
1. OGNL フレームワークを使用してアクセスされるオブジェクトのセット (SOAP メッセージパラ
メータ用)。 OGNL の使用法については下記に説明します。
2. With a set of String based key-value pairs(<String, Object>), where the key is an OGNL
expression identifying the SOAP parameter to be populated with the key's value. More on the use
of OGNL below.
114
エンドポイント操作の仕様
上述したように、 OGNL は与えられたパラメータ Map から SOAP メッセージにインジェクトする SOAP
パラメータの値の選択に使用するメカニズムとなります。 SOAP メッセージ内の特定のパラメータの
OGNL 式は SOAP ボディ内のそのパラメータの位置に依存します。 OGNL の詳細については、
http://www.opensymphony.com/ognl/ を参照してください。
以下のメッセージで:
<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>
custom erNum ber のパラメータを表す OGNL 式は custom erOrder.header.custom erNum ber で
す。
Once the OGNL expression has been calculated for a parameter, this class will check the supplied
parameter map for an Object keyed off the full OGNL expression (Option 1 above). If no such parameter
Object is present on the map, this class will then attempt to load the parameter by supplying the map
and OGNL expression instances to the OGNL toolkit (Option 2 above). If this doesn't yield a value, this
parameter location within the SOAP message will remain blank.
T aking the sample message above and using the "Option 1" approach to populating the
custom erNum ber requires an object instance (e.g. an Order object instance) to be set on the
parameters map under the key custom erOrder. T he custom erOrder object instance needs to
contain a header property (e.g. a Header object instance). T he object instance behind the header
property (e.g. a Header object instance) should have a custom erNum ber property.
コレクションに関連付けられた OGNL 式は少し異なる方法で構築されます。これは例を使用して説明する
のが最もわかりやすいケースです。
115
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
<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 s の集合が含まれます。 この集合内の各エントリは item エ
レメントで表されます。 注文アイテムの partNum ber に対する OGNL 式は
custom erOrder.item s[0].partnum ber および custom erOrder.item s[1].partnum ber のよ
うに構成されます。 このことからわかるように、 集合のエントリエレメント (item エレメント) は
OGNL 式に明示的に現われず、 インデックス表記で暗示的に表されます。 オブジェクトグラフという意
味では (上記のオプション 1)、 item s 一覧 (一覧または配列) を含むオーダーオブジェクトインスタンス
(マップでは custom erOrder に適合) に OrderItem インスタンスとなる一覧のエントリを付けて表す
ことができ、 次に partNum ber などのプロパティを含みます。
Option 2 (above) provides a quick-and-dirty way to populate a SOAP message without having to create
an Object model like Option 1. T he OGNL expressions that correspond with the SOAP operation
parameters are exactly the same as for Option 1, except that there's not Object Graph Navigation
involved. T he OGNL expression is simply used as the key into the Map, with the corresponding keyvalue being the parameter.
SOAP 応 答 メ ッ セ ー ジ 消 費
SOAP 応答オブジェクトインスタンスは、以下のいずれかの方法で ESB メッセージインスタンスに追加
できます。
1. デフォルトのボディ位置 で (Message.getBody().add(Map))
2. 指定のボディ位置 で (Message.getBody().add(String, Map))、 ボディ位置の名前を
こset-payload-location アクションプロパティの値として指定します
応答オブジェクトインスタンスには以下の 3 つのいずれかの方法で値を入力できます (SOAP 応答から)。
1. XStream ツールキットで作成し、 値が入力されたオブジェクトグラフとして
As a set of String based key-value pairs(<String, String>), where the key is an OGNL expression
identifying the SOAP response element and the value is a String representing the value from the
116
HttpClient 設定
SOAP message.
オプション 1 または 2 がアクション設定で指定されていない場合、 生の SOAP 応答メッセージ (文
字列) がメッセージに添付されます。
XML と Java オブジェクトモデルが互いに一致している限り、 オブジェクトグラフ (上記のオプション 1)
への値の入力のメカニズムとして XStream を使用するのが簡単であり、 効果的です。 XStream の詳細に
ついては、 http://xstream.codehaus.org を参照してください。
XStream を使用する方法 (オプション 1) は以下のようにアクションで設定されます。
<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 と応答オブジェクトインスタンスのデフォルトでない名前付き位置
を指定する方法の例も含まれています。
SOAP 応答データを OGNL キーマップ (上記のオプション 2) に抽出して ESB Message に添付するに
は、 以下のように responseXStream Config プロパティを true の値を持たせた
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>
生の SOAP メッセージを文字列 (オプション 3) として返すには、 responseXStream Config と
responseAsOgnlMap の両方のプロパティを省略します。
HttpClient 設 定
SOAPClient は Apache Commons HttpClient を使用して SOAP 要求を実行します。 SOAPClient は
HttpClientFactory を使用して HttpClient インスタンスを作成および設定します。 SOAPClient で
HttpClientFactory 設定を指定するのは非常に簡単です。 次のように WSDL プロパティにプロパティを追
加するだけです。
117
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
<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 ベースのリソースとして順番に評価
されます。
このプロパティセットの例は次のとおりです。
# Configurators
configurators=HttpProtocol,AuthBASIC
# HttpProtocol config...
protocol-socket-factory=org.apache.commons.httpclient.contrib.ssl.EasySSLPr
otocolSocketFactory
keystore=/packages/jakarta-tomcat-5.0.28/conf/chap8.keystore
keystore-passw=xxxxxx
https.proxyHost=localhost
https.proxyPort=443
# AuthBASIC config...
auth-username=tomcat
auth-password=tomcat
authscope-host=localhost
authscope-port=18443
authscope-realm=ActiveBPEL security realm
また、 プロパティはアクション設定で直接設定することもできます。
<property name="http-client-properties">
<http-client-property name="http.proxyHost" value="localhost"/>
<http-client-property name="http.proxyPort" value="8080"/>
</property>
利用可能な設定オプションの詳細については、 https://www.jboss.org/community/wiki/SOAPClient を参照
してください。
11.8. Miscellaneous
その他のアクションプロセッサ
SystemPrintln
メッセージのコンテンツを出力する単純なアクション ( System.out.println)。
メッセージコンテンツを XML としてフォーマットしようとします。
入力タイプ
java.lang.String
クラス
org.jboss.soa.esb.actions.SystemPrintln
プロパティ
1. “message”: メッセージ接頭辞。
1. “printfull”: true の場合は、メッセージ全体が出力されます。その他の場合は、
バイトアレイと添付ファイルのみが出力されます。
118
HttpClient 設定
2. “outputstream”: true の場合は System.out が使用されます。その他の場合は
System.err が使用されます。
設定例
<action name="print-before" class="org.jboss.soa.esb.actions.SystemPrintln">
<property name="message" value="Message before action XXX" />
</action>
[2] 『JBo s s Enterp ris e SO A Platfo rm サービスガイド (JBo s s Enterp ris e SO A Platfo rm Servic es G uid e)』はファイル
S ervi ces_G ui d e.p d f として提供され、 http ://www.red hat.c o m/d o c s /en-US/JBo s s _SO A_Platfo rm/ でオンラインで参照できます。
[3] 『JBo s s Enterp ris e SO A Platfo rm サービスガイド (JBo s s Enterp ris e SO A Platfo rm Servic es G uid e)』はファイル
S ervi ces_G ui d e.p d f として提供されるか、 http ://www.red hat.c o m/d o c s /en-US/JBo s s _SO A_Platfo rm/ でオンラインで参照できます。
[4] 『JBo s s Enterp ris e SO A Platfo rm サービスガイド (JBo s s Enterp ris e SO A Platfo rm Servic es G uid e)』はファイル
S ervi ces_G ui d e.p d f として提供されるか、 http ://www.red hat.c o m/d o c s /en-US/JBo s s _SO A_Platfo rm/ でオンラインで参照できます。
[5] 『JBo s s Enterp ris e SO A 管理ガイド (JBo s s Enterp ris e SO A Ad minis tratio n G uid e)』はファイル Ad m i n i strati o n _G ui d e.p d f
として提供されるか、 http ://www.red hat.c o m/d o c s /en-US/JBo s s _SO A_Platfo rm/ でオンラインで参照できます。
119
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
第 12章 カスタムアクションの開発
カスタムアクションプロセッサを実装するには 単に
org.jboss.soa.esb.actions.ActionPipelineProcessor インターフェースを実装します。
このインターフェースは管理されたライフサイクルを持つステートレスアクションの実装をサポートしま
す。1 つのパイプライスの基礎ごとに (つまり、1 つのアクション設定ごとに) このインターフェースを実
装するクラスの単一インスタンスがインスタンス化されます。つまり、initialise メソッドのアク
ションによって必要とされるリソースをキャッシュし、破棄メソッドでそれらのリソースをクリーンアッ
プできます。
実装するクラスはプロセスメソッド実装内からメッセージを処理する必要があります。
以下のように単に org.jboss.soa.esb.actions.AbstractActionPipelineProcessor を拡張
すると便利です。
public class ActionXXXProcessor extends AbstractActionPipelineProcessor {
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...
}
}
12.1. プ ロ パ テ ィ を 使 用 し た ア ク シ ョ ン の 設 定
Actions generally act as templates that require external configuration to perform their tasks. For example,
a PrintMessage action might take a property named 'message' to indicate what to print and a property
repeatCount to indicate the number of times to print it. T he action configuration in the jboss-esb.xm l
file might look like this:
<action name="PrintAMessage" class="test.PrintMessage">
<property name="information" value="Hello World!" />
<property name="repeatCount" value="5" />
</action>
アクション実装のロードプロパティ値に対するデフォルトのメソッドは ConfigT ree インスタンスを使
用します。ConfigT ree は DOM に類似したアクション XML のビューを提供します。デフォルトでは、ア
クションはパラメータとして ConfigT ree を受け取るパブリックコンストラクタを持つことが期待され
ます。例を以下に示します。
120
第12章 カスタムアクションの開発
public class PrintMessage extends AbstractActionPipelineProcessor {
private String information;
private Integer repeatCount;
public PrintMessage(ConfigTree config) {
information = config.getAttribute("information");
repeatCount = new Integer(config.getAttribute("repeatCount"));
}
public Message process(Message message) throws
ActionProcessingException {
for (int i=0; i < repeatCount; i++) {
System.out.println(information);
}
}
}
アクションプロパティを設定する他の方法はプロパティ名に対応するアクションにセッターを追加し、フ
レームワークがそれらにデータを自動的に入力するよう許可することです。アクション Bean にデータを
自動的に入力するために、アクションクラスは
org.jboss.soa.esb.actions.BeanConfiguredAction マーカーインターフェースを実装する必
要があります。たとえば、以下のクラスの動作は上記のものと同じです。
public class PrintMessage extends AbstractActionPipelineProcessor
implements BeanConfiguredAction {
private String information;
private Integer repeatCount;
public setInformation(String information) {
this.information = information;
}
public setRepeatCount(Integer repeatCount) {
this.repeatCount = repeatCount;
}
public Message process(Message message) {
for (int i=0; i < repeatCount; i++) {
System.out.println(information);
}
}
}
注記
setRepeatCount() の Integer パラメータは XML で指定された String 形式から自動的に変換さ
れます。
ロードプロパティの BeanConfiguredAction メソッドは単純な引数を取るアクションに適してお
り、ConfigT ree メソッドは XML 形式のデータを直接扱う必要がある場合に適しています。
121
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
第 13章 コネクタおよびアダプタ
13.1. は じ め に
JBossESB のすべてのクライアントとサービスがネイティブで使用するプロトコルとメッセージ形式を理
解できるわけではありません。したがって、ESB 対応エンドポイント (JBossESB を理解するもの) と
ESB 対応エンドポイント (JBossESB を理解しないもの) との間を橋渡しする必要があります。このよう
な橋渡しをする技術はさまざまな分散システムで長年使用され、コネクタ、ゲートウェイ、またはアダプ
タと呼ばれることがよくあります。
JBossESB の目的の 1 つは、広範なクライアントとサービスが対話できるようにすることです。
JBossESB では、このために JBossESB または任意の ESB を使用してこのようなクライアントとサービ
スをすべて作成する必要がありません。JBossESB 内には相互運用性のバスの抽象的な表記が存在するた
め、JBossESB 対応ではない場合があるエンドポイントでもバスに「プラグイン」できます。
注記
これ以降で「ESB 内」または「ESB 内部」という言葉は ESB 対応エンドポイントのことを意味し
ます。
すべての JBossESB 対応クライアントとサービスはメッセージを使用して相互に通信します。メッセージ
は情報交換の標準的な形式であり、ヘッダー、ボディ (ペイロード)、添付、および他のデータを含みま
す。また、すべての JBossESB 対応サービスはエンドポイント参照 (EPR) を使用して識別されます。
レガシー相互運用性シナリオの場合に JBossESB などの SOA インフラストラクチャで ESB 対応クライ
アントが ESB 対応サービスを使用したり、ESB 対応クライアントが ESB 非対応サービスを使用したりで
きることが重要です。この相互有用性を実現するために JBossESB が使用するコンセプトはゲートウェイ
を使用することです。ゲートウェイは ESB 対応の世界と ESB 非対応の世界を橋渡しし、メッセージを
EPR に変換したり、逆に EPR をメッセージに変換したりできるサービスです。
JBossESB は現在ゲートウェイとコネクタをサポートします。次のセクションでは、両方のコンセプトを
調べ、その使用方法を説明します。
13.2. ゲ ー ト ウ ェ イ
JBossESB のすべてのユーザーが ESB に対応しているわけではありません。ユーザーが ESB によって提
供されるサービスと対話できるように、JBossESB にはゲートウェイ (非 ESB クライアントとサービスか
らのメッセージを受け取り、必要な宛先にメッセージをルーティングできる特殊なサーバー) のコンセプ
トが存在します。
ゲートウェイは、ESB 対応リスナーと非常によく似た動作をする特殊なリスナープロセスです。ただし、
いくつかの重要な差異があります。
Gateway classes can pick up arbitrary objects contained in files, JMS messages, SQL tables etc
(each 'gateway class' is specialized for a specific transport), whereas JBossESB listeners can only
process JBossESB normalized Messages as described in “T he Message” section of this document.
However, those Messages can contain arbitrary data.
Only one action class is invoked to perform the 'message composing' action. ESB listeners are able
to execute an action processing pipeline.
Objects that are 'picked up' will be used to invoke a single 'composer class' (the action) that will
return an ESB Message object, which will be delivered to a target service that must be an ESB aware
122
第13章 コネクタおよびアダプタ
service. T he target service defined at configuration time, will be translated at runtime into an EPR (or
a list of EPRs) by the Registry. T he underlying concept is that the EPR returned by the Registry is
analogous to the 'toEPR' contained in the header of ESB Messages, but because incoming objects
are 'ESB unaware' and there is thus no dynamic way to determine the toEPR, this value is provided
to the gateway at configuration time and included in all outgoing messages.
T here are a few off the shelf composer classes: the default 'file' composer class will just package the file
contents into the Message body; same idea for JMS messages. Default message composing class for a
SQL table row is to package contents of all columns specified in configuration, into a java.util.Map.
Although these default composer classes will be enough for most use cases, it is relatively
straightforward for users to provide their own message composing classes. T he only requirements are
a) they must have a constructor that takes a single ConfigT ree argument, and b) they must provide a
'Message composing' method (default name is 'process' but this can be configured differently in the
'process' attribute of the <action> element within the ConfigT ree provided at constructor time. T he
processing method must take a single argument of type Object, and return a Message value.
13.2.1. ゲートウェイデータマッピング
非 JBossESB メッセージはゲートウェイが受け取ったときにメッセージに変換する必要があります。これ
をどのように行うか、受け取ったデータをメッセージのどこに置くかはゲートウェイの種類によって異な
ります。この変換をどのように行うかはゲートウェイの種類によって異なります。デフォルトの変換方法
は以下で説明されています。
JMS ゲートウェイ
入力メッセージが JMS T extMessage である場合は、関連付けられた String がデフォルトで指
定されたボディ部分に置かれます。ObjectMessage または BytesMessage である場合、コンテ
ンツは BytesBody.BYTES_LOCATION で指定されたボディ部分内に置かれます。
ローカルファイルゲートウェイ
コンテンツは BytesBody.BYTES_LOCATION で指定されたボディ部分内に置かれます。
ハイバネートゲートウェイ
コンテンツは ListenerTagNames.HIBERNATE_OBJECT_DATA_TAG で指定されたボディ部分内
に置かれます。
リモートファイルゲートウェイ
コンテンツは BytesBody.BYTES_LOCATION で指定されたボディ部分内に置かれます。
注記
InVM transport の導入により、同じアドレス空間 (VM) 内にサービスをゲートウェイとしてデプロ
イできるようになり、ゲートウェイとリスナー間の対話が効率的になりました。
13.2.2. ゲートウェイデータマッピングの変更方法
このマッピングがどのように行われるかを変更する場合、その方法はゲートウェイの種類によって異なり
ます。
123
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
ファイルゲートウェイ
org.jboss.soa.esb.listeners.m essage.MessageCom poser インターフェースのイン
スタンスは変換を行います。デフォルトの動作を変更するには、独自の compose メソッドと
decompose メソッドを定義する適切な実装を提供します。新しい MessageCom poser 実装は
composer-class 属性名を使用して設定ファイルで提供する必要があります。
JMS およびハイバーネイトゲートウェイ
これらの実装は作成クラスを定義するために反射的な方法を使用します。独自のメッセージ
composer クラスを提供し、どのインスタンスを使用するかをゲートウェイに通知するために設
定ファイルで composer-class 属性名を使用します。メッセージが必要な場合はクラスのどの操
作を呼び出すかをゲートウェイに通知するために composer-process 属性を使用できます。この
メソッドはオブジェクトを受け取り、メッセージを返す必要があります。指定されていない場合
は、プロセスのデフォルト名が使用されます。
注記
メッセージ作成を再定義するのにどのメソッドを使用するかに関係なく、ボディだけでなくメッ
セージのコンテンツを完全に制御できることに注意してください。たとえば、元のコンテンツの内
容や送信者などに基づいて新しく作成されたメッセージに対して ReplyT o または FaultT o EPR を
定義する場合は、ヘッダも変更することを考慮する必要があります。
13.3. JCA を 介 し た 接 続
You can use JCA Message Inflow as an ESB Gateway. T his integration does not use MDBs, but rather
ESB's lightweight inflow integration. T o enable a gateway for a service, you must first implement an
endpoint class. T his class is a Java class that must implement the
org.jboss.soa.esb.listeners.jca.InflowGateway class:
public interface InflowGateway
{
public void setServiceInvoker(ServiceInvoker invoker);
}
T he endpoint class must either have a default constructor, or a constructor that takes a ConfigT ree
parameter. T his Java class must also implement the messaging type of the JCA adapter you are binding
to. Here's a simple endpoint class example that hooks up to a JMS adapter:
124
第13章 コネクタおよびアダプタ
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.postMessage(esbMessage);
}
catch (Exception e)
{
throw new RuntimeException(e);
}
}
}
このクラスに対して定義されたゲートウェイ 1 つに対して JmsEndpoint クラスの 1 つのインスタンスが
作成されます。これはプールされる MDB とは異なります。このクラスの 1 つのインスタンスのみが各受
信メッセージにサービスを提供するため、スレッドセーフコードを記述する必要があります。
設定時に ESB は ServiceInvoker を作成し、エンドポイントクラスの setServiceInvoker メソッ
ドを呼び出します。次に ESB は JCA エンドポイントを有効にし、エンドポイントクラスインスタンスが
メッセージを受信できる状態になります。JmsEndpoint の例では、インスタンスが JMS メッセージを受
け取り ESB メッセージタイプに変換し、ターゲットサービスで呼び出す ServiceInvoker インスタンスを
使用します。
注記
JMS エンドポイントクラスは、ESB の配布が
org.jboss.soa.esb.listeners.jca.Jm sEndpoint 下に存在する状態で提供されます。こ
のクラスを任意の JMS JCA インフローアダプタとともに何度も使用することができます。
13.3.1. 構成
A JCA inflow gateway is configured in a jboss-esb.xm l file. Here's an example:
125
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
<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 gateways are defined in <jca-gateway> elements. T hese are the configurable attributes of this XML
element.
表 13.1 jca-gateway 設定属性
属性
必須
説明
name
yes
ゲートウェイの名前
アダプタ
yes
使用しているアダプタの名前。JBoss では、デプロイした
RAR のファイル名 (jm s-ra.rar など) になります。
endpointClass
yes
エンドポイントクラスの名前
messagingT ype
no
アダプタのメッセージインターフェース。指定しない場合は、
ESB がエンドポイントクラスに基づいた名前を付けます。
実行済み
no
デフォルトでは真に設定されます。JT A トランザクション内で
メッセージを呼び出すかどうかを設定します。
You must define an <activation-config> element within <jca-gateway>. T his element takes one or more
<property> elements which have the same syntax as action properties. T he properties under
<activation-config> are used to create an activation for the JCA adapter that will be used to send
messages to your endpoint class. T his is really no different than using JCA with MDBs.
You may also have as many <property> elements as you want within <jca-gateway>. T his option is
provided so that you can pass additional configuration to your endpoint class. You can read these
through the ConfigT ree passed to your constructor.
13.3.2. 標準アクティベーションプロパティのマッピング
複数の ESB プロパティは ActivationMapper を使用してアクティベーション設定に自動的にマッピン
グされます。 プロパティ、 その場所、 およびその目的については、 次の表で説明されます。
126
第13章 コネクタおよびアダプタ
表 13.2 アクティベーションプロパティ
属性
場所
説明
maxT hreads
jm s-listener
同時に処理できる最大メッセージ数
dest-name
jm s-m essage-filter
JMS 宛先名
dest-type
jm s-m essage-filter
JMS 宛先タイプ、 QUEUE または T OPIC
selector
jm s-m essage-filter
JMS メッセージセレクタ
providerAdapterJNDI
jm s-jca-provider
リモートの JMS プロバイダにアクセスするた
めに JCA インフローで使用できるプロバイダ
アダプタの JNDI 場所。 これは、 デフォルト
の JCA インフローアダプタによりサポートさ
れた JBoss 固有のインターフェースであり、
必要な場合は他のインフローアダプタにより
使用できます。
アクティベーション指定へのこれらのプロパティのマッピングは、 ActivationMapper インター
フェースを実装するクラスを指定することにより上書きでき、 グローバルまたは ESB デプロイメント設
定内で宣言できます。
Specifying the ActivationMapper globally is done using the jbossesb-properties.xm l file and
defines the default mapper used for the specified JCA adapter. T he name of the property to be
configured is org.jboss.soa.esb.jca.activation.mapper.<adapter_name> and the value is the class name
of the ActivationMapper.
次のコード例は、 JBoss JCA アダプタ (jm s-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>
次のコード例は、 プロバイダ設定内でマッパー設定を指定する例を示します。
127
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
<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>
128
JAXB Annotation Introduction の設定を作成する
JAXB Annotation Introduction の設定を作成する
JAXB Annotation Introduction configurations are very easy to write. If you're already familiar with the
JAXB Annotations, you'll have no problem writing a JAXB Annotation Introduction configuration.
設定の XSD
は、http://anonsvn.jboss.org/repos/jbossws/projects/jaxbintros/tags/1.0.0.GA/src/main/resources/jaxbintros.xsd にてオンラインで提供されています。IDE にて http://www.jboss.org/xsd/jaxb/intros 名前空間に
対してこの XSD を登録します。
現在サポートされているのは 3 つのアノテーションのみです。
@XmlT ype
Class 要素上
https://jaxb.dev.java.net/nonav/2.1.3/docs/api/javax/xml/bind/annotation/XmlT ype.html
@XmlElement
Field 要素および Method 要素上
https://jaxb.dev.java.net/nonav/2.1.3/docs/api/javax/xml/bind/annotation/XmlElement.html
@XmlAttribute
Field 要素および Method 要素上
https://jaxb.dev.java.net/nonav/2.1.3/docs/api/javax/xml/bind/annotation/XmlAttribute.html
T he basic structure of the configuration file follows the basic structure of a Java class i.e. a "Class"
containing "Fields" and "Methods". T he <Class>, <Field> and <Method> elements all require a “name”
attribute for the name of the Class, Field or Method. T he value of this name attribute supports regular
expressions. T his allows a single Annotation Introduction configuration to be targeted at more than one
Class, Field or Member e.g. setting the namespace for a fields in a Class, or for all Classes in a package
etc.
Annotation Introduction 設定は Annotation の定義と完全に一致し、各アノテーションの「要素と値のペ
ア」は、Annotation Introduction 設定上の属性によって表されます。XSD と IDE を使用して設定を編集し
てください。
例は次の通りです。
129
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
<?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>
130
サービス指向アーキテクチャの概要
サービス指向アーキテクチャの概要
JBossESB is a Service Oriented Architecture (SOA) infrastructure. SOA represents a popular
architectural paradigm for applications development. While the principles behind SOA have been around
for many years and it doesn't require the use of web services, it is the use of web services that have
popularized it.
Web サービスは業界標準のネットワークおよびアプリケーションのインターフェースとプロトコルを使用
して他のアプリケーション (または他の Web サービス) を利用できる機能を実装します。SOA はソフト
ウェアコンポーネントが他のソフトウェアコンポーネントによって活用できるサービスとして機能を提供
する手法に準拠します。コンポーネント (またはサービス) は再利用可能なソフトウェアの部品を表しま
す。
SOA では、既存のシステム、アプリケーション、ユーザーを変化するニーズに簡単に対応できる柔軟な
アーキテクチャに統合できます。堅牢な SOA を作成するのに必要な要素は、統合されたデザイン、既存
の IT 投資の再利用、上記のすべて、業界標準などです。
企業の意識がコスト削減にのみ集中する状態からようやくより安定的なコスト管理に移ってきたなかで、
多くの企業は今まで経験したことがない状況に直面しています。現在の経済不況以前は、ほとんどの企業
が IT 投資の選択肢を理解していました。多くの企業が主要なパッケージ実装 (Siebel、PeopleSoft など)
を導入する一方で、他の企業は長年使用してきたレガシーシステムを元にしてシステムを構築していまし
た。どちらの方法でもほとんどの企業が約束されたリターンを認識し、投資を行っていました。今現在は
このような大規模な投資への意欲は失われました。
ただし、企業は依然として前進し、競争に勝つ必要があります。SOA (およびこれらの原則の具体的な実
装としての Web サービス) はこれを可能にします。結果として、ユーザー、アプリケーション、およびテ
クノロジコンポーネント間のコラボレーションが大幅に改善され、どのようなビジネスにも大きな価値が
生み出され、競争力が強化されます。
SAP、PeopleSoft などさまざまなベンダーのソフトウェアを使用している企業を考えてみてください。他
社 (顧客、供給業者など) とビジネスを行うにはこれらのいくつかのソフトウェアパッケージが役に立つか
もしれません。したがって、企業はこれらの既存のシステムをサービスとして公開することにより他社が
利用できるようにします。このサービスはクライアント (他のソフトウェアコンポーネント) が呼び出すこ
とができる安定した公開インターフェースを持つソフトウェアコンポーネントです。したがって、サービ
スを要求および実行するには、ある企業が所有するソフトウェアコンポーネントが他の企業が所有するコ
ンポーネントと対話する必要があります (ビジネスツービジネス (B2B) トランザクション)。
このような組織間の交換に対して従来の分散システムインフラストラクチャ (ミドルウェア) は十分ではあ
りません。
ミドルウェアプラットフォームに関係する者の間で同意が必要になります。
これらの関係者間には暗黙的な (場合によっては明示的な) 信頼の欠如が存在します。
ビジネスデータは機密性が高く、想定された受信者のみによって参照されるべきです。
組織間の対話処理では従来のミドルウェアで前提としていたことの多くが無効です。たとえば、トラ
ンザクションは長時間 (数時間または数日) 継続するため、2 フェーズコミットなどの従来のトランザ
クションプロトコルは適用できません。
So, in B2B exchanges the lack of standardization across middleware platforms makes point-to-point
solutions costly to realize in practice. T he Internet alleviated some of these problems by providing
standard interaction protocols (HT T P) and data formats (XML) but by themselves these standards are
not enough to support application integration. T hey don't define interface definition languages, name and
directory services, transaction protocols, etc,. It is the gap between what the Web provides and what
application integration requires that Web services are trying to fill.
ただし、SOA の最終的な目標は企業間の対話処理であり、インターネットを使用してサービスにアクセス
131
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
する必要はありません。サービスはローカルネットワークに存在するクライアントが簡単に利用できま
す。1 つの企業内で稼働する複数のシステムを統合するために Web サービスがこのように使用されるこ
とは一般的です。
As demonstration of how web services can connect applications to each other both within and between
companies, consider a stand-alone inventory system. If you don't connect it to anything else, it's not as
valuable as it could be. T he system can track inventory, but not much more. Inventory information may
have to be entered separately in the accounting and customer relationship management systems. T he
inventory system may be unable to automatically place orders to suppliers. T he benefits of such an
inventory system are diminished by high overhead costs.
しかし、在庫システムを XML を使用して会計システムに接続すると、興味深い結果が得られます。この
場合、何かを購入または販売するびに在庫の結果とキャッシュフローを 1 つのステップで追跡できるよう
になります。さらに倉庫管理システム、供給業者の発注システム、運送業者を XML を使用して接続する
と、在庫管理システムは突然たくさんの価値を生み出すようになります。この場合、ビジネスのエンド
ツーエンド管理を行うことができ、影響を受ける各システムに対してではなく各トランザクションを 1 度
だけ処理するだけですみます。作業が大幅に削減され、エラーの発生も大幅に減少します。これらの接続
は Web サービスを使用して簡単に行えます。
企業は以下のものを含む SOA の利点を認識しています。
パートナと簡単に接続することにより、新しいビジネスチャンスが生まれます。
ソフトウェア開発の時間を削減し、他の企業によって作成されたサービスを使用することにより時間
とお金を削減します。
独自のサービスを簡単に利用できるようにすることにより収益ストリームが増加します。
B.1. SOA と は
問題は一般的に過去の IT 投資の eProcurement、eSourcing、サプライチェーン管理、顧客間警官理
(CRM)、インターネットコンピューティングの領域に分類できます。これらのすべての投資は 1 つのサイ
ロで行われました。短期の (戦術的な) 要件を満たすためにこれらシステムが増大し、これらの領域に対し
て下された決定によりアプリケーションとインフラストラクチャの長期的な価値が傷つけられました。
SOA 手法を実装する 3 つの主要な理由は以下のとおりです。
コスト削減
サービス同士が対話する方法によって達成されます。直接的なコスト効果は、向上した処理の生
産性、効果的なソースオプション、現在のコストを可変モデルにシフトする大幅に拡張された機
能をによってもたらされます。
IT ソリューションを素早くスマートに提供する
標準に基づいた手法をとることにより、組織は以前よりも非常に迅速かつ簡単に情報/ビジネスプ
ロセスを接続および共有できるようになります。標準的なフレームワークとインターフェースを
提供することにより開発者の役割が単純化され IT 導入の生産性が大幅に向上します。個別機能
の統合負荷を緩和し、環境内で高速な導入テクニックを適用することにより導入時間は大幅に短
縮されます。
投資リターンの最大化
Web サービスを使用すると、新しいビジネスモデルを実現でき新しいビジネスチャンスが生み出
されます。Web サービスは従来の機能と利益に基づく方法とは大きく異なり価値と離散的なリ
ターンを測定できる機能を提供します。通常の T CO (T otal Cost of Ownership) モデルでは過去
の投資から生まれた生涯の価値が考慮されません。コスト中心のこの観点により、これらの過去
132
サービス指向アーキテクチャの概要
の投資を活用する多くのチャンスが失われ、結果的にほとんどの企業が必要性からではなく予見
されたニーズのためにアーキテクチャで冗長性を構築することになってしまいます。これらの同
じ組織はインフラストラクチャのオーバーヘッドによって調整されたアプリケーションのポート
フォリオに IT 投資の価値を見出します。Web サービスに基づいた方法では、過去の IT 投資の生
涯貢献度が考慮され、計画的なシステムの置き換えではなくこれらの投資の発展が促進されま
す。
SOA/Web サービスはエンタープライズソフトウェアの開発およびデプロイ方法を根本的に変えます。
SOA は進化し、新しいアプリケーションはモノリシックな方法で開発されず、従来の方法により引き起こ
された現在の経済的および技術的なボトルネックを解消する仮想オンデマンド実行モデルになります。
作業を効率化し、所有コストを削減し、市場で競争力がある差異化を図りたい先進的な企業にとってサー
ビスとしてのソフトウェアは一般的なモデルです。Web サービスを使用すると、企業はソフトウェアの取
得から大きな利益を生み出し、急速に変化する市場に対応し、ビジネスパートナといつでも取引を行える
ようになります。疎結合の標準をベースにしたアーキテクチャはネットワークで利用可能なソフトウェア
リソースを活用できる分散コンピューティングの 1 つの方法です。ビジネスプロセス、プレゼンテーショ
ンルール、ビジネスルール、データアクセスを独立した疎結合レイヤに分離することは、より良いソフト
ウェアを構築するだけでなく将来の変更に対応するためにも役に立ちます。
SOA により、既存の機能と新しい開発成果を組み合わせて複合アプリケーションを作成できます。このよ
うに既存の機能を再利用することにより、プロジェクトのリスクの低下、導入時間の短縮、ソフトウェア
の全体の品質の向上が実現されます。
疎結合により、モノリシックな方法を使用したコストがかかる移行に関連するリスクを負わずに部品を独
自のペースで変更できるようになります。SOA により、ビジネスユーザーは技術的な制約を気にせずに現
在直面しているビジネス上の問題に集中できます。ソリューションを開発する個人にとって SOA は以下
の点で役に立ちます。
ビジネス分析者はビジネスドメインの知識を増やしつつ開発ライフサイクルの高位の仕事に集中でき
ます。
複数のチームが取り組むことができるコンポーネントベースのサービスに機能を分けることによって
並列開発が可能になります。
品質保証やユニットテストが効率的になります。エラーは開発ライフサイクルの初期に検出できま
す。
開発チームはリスクを増やさずに初期の要件から逸脱できます。
アーキテクチャ内のコンポーネントは再利用可能な資産でありその部品を再び作成する必要はありま
せん。
ビジネスプロセスに関係するサービスとその基礎となるコンポーネントを機能的に分解することによ
り、柔軟性と将来の保守性が保持され、統合の作業が緩和されます。
セキュリティルールはサービスレベルで実装され、企業内の多くのセキュリティ考慮事項を解決でき
ます。
B.2. SOA の 基 本
従来の分散コンピューティング環境は密接に結合され、変化する環境に十分に対応できません。たとえ
ば、アプリケーションが他のアプリケーションと対話する場合にいずれかのシステムのデータ型が変更さ
れると両方のアプリケーションがどのようにデータ型やデータエンコーディングを処理するかが問題とな
ります。互換性がないデータ型はどのように処理されるのでしょうか?
サービス指向アーキテクチャ (SOA) はリクエスタ、プロバイダ、ブローカの 3 つの役割から構成されま
す。
133
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
サービスプロバイダ
サービスプロバイダはサービスへのアクセスを許可し、サービスの説明を作成し、サービスブ
ローカに公開します。
サービスリクエスタ
サービスリクエスタはサービスブローカによって提供されたサービスの説明を検索することに
よってサービスを探します。また、リクエスタはサービスプロバイダによって提供されるサービ
スにバインドします。
サービスブローカ
サービスブローカはサービスの説明のレジストリをホストし、リクエスタをサービスプロバイダ
に関連付けます。
B.3. SOA の 利 点
SOA は分散エンタープライズシステムに複数の大きな利点を提供します。最も注目すべき利点には相互有
用性、効率性、標準化などが含まれます。これらについてはこのセクションで簡単に説明します。
B.3.1. 相互運用性
相互運用性は、データと機能を共有することによってさまざまなシステムのソフトウェア同士の通信を可
能にします。SOA と Web サービスは Web とインターネットスケールコンピューティングと同様に相互
運用性に大きく基づきます。ほとんどの企業はその存続期間において数多くのビジネスパートナと取引を
行います。SOAP などの Web サービステクノロジを使用すると、新しいパートナを得るたびに 1 つのイ
ンターフェースを作成するだけですみます。したがって、パートナは UDDI を使用してサービスを動的に
見つけ、SOAP を使用してバインドできます。また、自社のネットワーク内に Web サービスを導入する
ことによりシステムの相互運用性を拡張することもできます。システムに Web サービスを追加すると、
統合コストを削減し、コミュニケーションと顧客ベースを増大させることができます。
重要なのは業界が Web Services Interoperability Organization を創設したことです。
“Web Services Interoperability Organization はプラットフォーム、アプリケーション、およびプログラミ
ング言語間の Web サービスの相互運用性を促進するために設立されたオープンな組織です。この組織は
相互運用可能な Web サービスを開発するためのガイダンスや推奨される慣習を提供したり、リソースを
提供したりすることにより多様な Web サービスのリーダーたちが顧客のニーズに応えることができるよ
う支援します。” (www.ws-i.org)
WS-I は実際には Web サービスが業界標準と同様に WS-I 標準に準拠するかどうかを判断します。整合性
や信頼性を確立するために企業は WS-I 標準に準拠して Web サービスを構築しようとします。
B.3.2. 効率性
SOA を使用すると、既存のアプリケーションを再利用できます。完全に新しいアプリケーションを作成す
る代わりに、既存のアプリケーションによって公開されたさまざまな組み合わせのサービスを使用してア
プリケーションを作成できます。開発者は業界標準のテクノロジを学ぶことに集中できるため作業は効率
的になり、新しいテクノロジが現れるたびに時間をかけて学ぶ必要がありません。マネージャにとってこ
れは新しいソフトウェアを購入し、新しいスキルを持った開発者を雇用するコストが削減されることを意
味します。この手法により、開発者は変化するビジネス要件に対応し、プロジェクトの開発サイクル期間
を短縮できるようになります。一般的に SOA を使用するとアプリケーションの再利用、開発者の学習時
間の短縮、全体的な開発プロセスの短縮が可能になり効率が向上します。
134
サービス指向アーキテクチャの概要
B.3.3. 標準化
標準化を実際に図るには、その標準が業界の多数によって認められ使用される必要があります。1 つのベ
ンダやベンダの小規模なグループがテクノロジや仕様の進化を支配することがあってはなりません。業界
リーダーの全員とは言わないまでもそのほとんどが Web サービス仕様の開発に参加します。ほとんどの
企業は何らかの形でインターネットと World Wide Web を使用します。WWW の基礎となるプロトコルは
当然 HT T P です。Web サービスの基礎は HT T P と XML に基づいて構築されます。SOA では特定の実装
フレームワークを必要としませんが、相互運用性が重要であり、SOAP は優れたすべての SOA 実装がと
もに使用する複数のプロトコルの 1 つです。
B.3.4. ステートフルおよびステートレスサービス
Web サービスのほとんどの提唱者は、アーキテクチャが Web のようにスケーラブルかつ柔軟であること
が重要であると認識しています。結果として、Web サービスの現在の対話パターンは粒度が粗いサービス
やコンポーネントに基づきます。アーキテクチャは意図的にサービスエンドポイントの背後で起こること
について規定していません。Web サービスは究極的には関係者間の構造化データの転送とこのような転送
を (メッセージの暗号化やデジタル署名などによって) 保護するメタレベルの情報にのみ関係します。これ
により、実装の柔軟性が提供され、ユーザーに直接影響を与えずにシステムが要件やテクノロジの変更に
適応できるようになります。また、ほとんどの企業はさまざまな理由からバックエンド実装の決定や方針
をユーザーに公開したくありません。
CORBA、J2EE、DCOM などの分散システムでは、通常対話はコンテナ内に存在するステートフルオブ
ジェクト間で行われます。これらのアーキテクチャでは、オブジェクトは個別に参照されるエンティティ
として公開され、特定のコンテナ、したがって多くの場合は特定のマシンに関連付けられます。ほとんど
の Web サービスアプリケーションはオブジェクト指向言語を使用して作成されているため、そのアーキ
テクチャを Web サービスに拡張することを考えるのは自然です。したがって、サービスは、特定の状態
を表す Web サービスリソースを公開します。結果として、このようなアーキテクチャによりクライアン
トとサービスの結合は密接になり、World Wide Web と同等のスケーラビリティを実現することは難しく
なります。
現在、Web サービスの定義に参加する企業によって定義されるセッションコンセプトには、WSAddressing EndpointReferences (ReferenceProperties/ReferenceParameters とともに使用) と WSContext の明示的なコンテキスト構造の 2 つの主要なモデルが存在します。これら両方のモデルは
JBossESB 内でサポートされます。WS-Addressing セッションモデルは Web サービスエンドポイント情
報とセッションデータ間の結合を提供し、分散オブジェクトシステムのオブジェクト参照に類似します。
WS-Context は HT T P サーバー、トランザクション、MOM システムで存在するセッションモデルが進化
したセッションを提供します。その一方で、WS-Context を使用するとサービスクライアントがサービス
との関係を動的および一時的にバインドできるようになります。サービスに対するクライアントの通信
チャネルは特定のセッション関係によって影響されません。
これは、Web サービスを内部デプロイメントからインターネットで提供されている一般的なサービスにス
ケーリングするときに重要になります。Web サービスの現在の対話パターンは粒度が粗いサービスまたは
コンポーネントに基づいています。アーキテクチャは意図的にサービスエンドポイントの背後で起こるこ
とについて規定していません。Web サービスは究極的には関係者間の構造化データの転送とこのような転
送を (メッセージの暗号化やデジタル署名などによって) 保護するメタレベルの情報にのみ関係します。こ
れにより、実装の柔軟性が提供され、ユーザーに直接影響を与えずにシステムが要件やテクノロジの変更
に適応できるようになります。また、サービスがユーザーや (一時的にバインドされる) その対話を代表し
てステータスを保持するかどうかなどの問題は実装によって異なり、通常はユーザーに公開されません。
ステートフルサービスと対話するときに WS-Addressing に基づくセッション形式のモデルを使用する場
合は、ステータスとサービス間の密接な結合によりクライアントが影響を受けます。このモデルが使用さ
れている他の分散環境 (CORBA や J2EE など) と同様に、クライアントがサービスエンドポイントに対し
て持つリモート参照 (アドレス) は以降の起動のためにクライアントによって記憶されなければなりませ
ん。クライアントアプリケーションが同じ論理セッション内の複数のサービスと対話する場合、サービス
は他のサービスの関連付けられたステータスとともに使用する場合のみクライアントに影響します。つま
135
JBoss Enterprise SOA Platform 4.3 プログラマーガイド
り、クライアントは各サービス参照を記憶し、特定の対話と何らかの方法で関連付ける必要があります。
したがって、複数の対話の結果として、さまざまな参照セットを組み合わせて各セッションを表すことが
できるようになります。
たとえば、同じアプリケーションセッション内で N 個のサービスが使用され、各サービスが m 個の異な
るステータスを保持する場合、クライアントアプリケーションは N*m 個の参照エンドポイントを保持する
必要があります。初期サービスエンドポイント参照が UDDI など一部のブートストラッププロセスから取
得されることがよくあることに注意してください。ただし、このモデルではこれらの参照はステートレス
であり、アプリケーション対話を開始する以外は役に立ちません。これ以降に特定のステータスへのアク
セスが必要なこれらのサイトにアクセスする場合は、WS-Addressing モデルで異なる参照を使用する必要
があります。
これにより、当然 Web のサイズの環境にスケーリングされませんが、代わりに WS-Context を使用して
Web サービスの疎結合の性質を引き続き受け継ぐことができます。これまでに示したように、一連のサー
ビスとの各対話はセッションとしてモデル化でき、セッションは関連付けられたコンテキストを持つ WSContext アクティビティとしてモデル化できます。クライアントアプリケーションが同じセッション内の
一連のサービスと対話するときは、コンテキストがサービスに必ず伝播され、このコンテキストはクライ
アントとの対話で必要なステータスにマッピングされます。
このマッピングがどのように行われるかは実装によって異なり、クライアントに公開する必要はありませ
ん。また、特定のセッション内の各サービスは同じコンテキストを取得し、これらのサービスに後で再び
アクセスしたときに同じコンテキストが再び提供されるため、クライアントアプリケーションは必ず正し
いステータスセットに戻ることができます。したがって、前述した例の N 個のサービスと m 個のステー
タスの場合、クライアントは N 個のエンドポイント参照のみを必要とし、これまでに述べたように通常こ
れらのエンドポイント参照はブートストラッププロセスから取得されます。この結果、このモデルのス
ケーリングは大幅に向上します。
B.4. JBossESB と SOA と の 関 係
SOA は単なるテクノロジではありません。SOA は包装された箱で提供されず、JBossESB などの基礎と
なるインフラストラクチャを使用してユーザーが作業や対話をしたりする方法を変更することを必要とし
ます。JBossESB 4.3 GA で Red Hat は SOA アプリケーションを開発できる基礎となる SOA インフラス
トラクチャを提供しています。4.2.1 リリースには SOA 開発に必要なほとんどの機能が備わっており、
Red Hat はパートナと連携し高レベルのプラットフォームがこれらの機能を適切に活用できるよう取り組
んでいます。ただし、ベースラインプラットフォーム (JBossESB) は、すぐに使用できるツールの改良、
ランタイム管理、サービスライフサイクルなどによって進化し続けます。JBossESB 4.3 GA では、開発
者が低レベルの API とパターンを使用してこれらの機能を活用しなければならない場合があります。
136
リビジョン履歴
リビジョン履歴
改訂 1.2-5.4 00
2013-10-31
Landmann Rüdiger [FAMILY
Given]
2012-07-18
T owns Anthony [FAMILY
Given]
Rebuild with publican 4.0.0
改訂 1.2-5
Rebuild for Publican 3.0
改訂 1.2-0
Wed Jul 1 2009
Mison Darrin [FAMILY Given]
4.3.CP02 リリース用に更新
SOA-1358 - テキストセクションの間違いを修正 (セクション 11.7)
SOA-1341 - 除外されたクイックスタートへの参照を削除 (セクション 11.7.1)
SOA-1335 - 古い webservice 設定の詳細を削除 (セクション 4.4)
SOA-1001 - JAXB XSD url の参照を更新 (付録 A)
改訂 1.1-0
4.3.CP01 リリース用に更新
T ue Jan 27 2009
Mison Darrin [FAMILY Given]
改訂 1.0-0
Created
Fri Jan 23 2009
Mison Darrin [FAMILY Given]
137