Red Hat Training
A Red Hat training course is available for JBoss Enterprise SOA Platform
ESB サービスガイド
本ガイドは開発者向けです。
概要
はじめに
1. ドキュメント規則
1.1. 表記規則
等幅ボールド
現在の作業ディレクトリーのファイルmy_next_bestselling_novel
の内容を表示するには、シェルプロンプトで cat my_next_bestselling_novel コマンドを入力し、Enter を押してコマンドを実行します。
Enter を押してコマンドを実行します。Ctrl+Alt+F2 を押して、仮想ターミナルに切り替えます。
等幅ボールド
で示されます。以下に例を示します。
ファイル関連のクラスには、ファイルシステムのfilesystem
、ファイルのfile
、ディレクトリーのdir
が含まれます。各クラスには、独自の関連付けられたパーミッションセットがあります。
メインメニューバーから System → Preferences → Mouse を選択し、Mouse Preferences を起動します。Buttons タブで、Left-handed mouse チェックボックスを選択し、Close をクリックしてメインのマウスボタンを左から右に切り替えます (マウスを左手で使い易くします)。特殊文字を gedit ファイルに挿入するには、メインメニューバーから Applications → Accessories → Character Map を選択します。次に、Character Map メニューバーから Search → Find… を選択し、Search フィールドに文字の名前を入力して Next をクリックします。目的の文字が Character Table で強調表示されます。この強調表示した文字をダブルクリックして Text to copy フィールドに配置し、Copy ボタンをクリックします。ここでドキュメントに戻り、gedit メニューバーから Edit → Paste を選択します。
ssh を使用してリモートマシンに接続するには、シェルプロンプトで ssh username@domain.name を入力します。リモートマシンがexample.com
で、そのマシン上でのユーザー名が john の場合は、ssh john@example.com と入力します。mount -o remount file-system コマンドにより、指定したファイルシステムが再マウントされます。たとえば、/home
ファイルシステムを再マウントする場合、コマンドは mount -o remount /home となります。現在インストールされているパッケージのバージョンを表示するには、rpm -q package コマンドを使用します。これにより、package-version-release のような結果が返されます。
Publican は DocBook 公開システムです。
1.2. 引用規則
mono-spaced roman
に設定され、以下のように表示されます。
books Desktop documentation drafts mss photos stuff svn books_tests Desktop1 downloads images notes scripts svgs
mono-spaced roman
に設定されますが、以下のように構文の強調表示が追加されます。
static int kvm_vm_ioctl_deassign_device(struct kvm *kvm, struct kvm_assigned_pci_dev *assigned_dev) { int r = 0; struct kvm_assigned_dev_kernel *match; mutex_lock(&kvm->lock); match = kvm_find_assigned_dev(&kvm->arch.assigned_dev_head, assigned_dev->assigned_dev_id); if (!match) { printk(KERN_INFO "%s: device hasn't been assigned before, " "so cannot be deassigned\n", __func__); r = -EINVAL; goto out; } kvm_deassign_device(kvm, match); kvm_free_assigned_device(kvm, match); out: mutex_unlock(&kvm->lock); return r; }
1.3. 注記および警告
2. ヘルプの利用とフィードバック提供
2.1. ヘルプが必要ですか ?
- Red Hat 製品に関する技術サポート記事の知識ベースの検索または閲覧。
- Red Hat グローバルサポートサービス (GSS) へのサポートケースの送信。
- その他の製品ドキュメントへのアクセス。
2.2. ご意見をお寄せください
第1章 はじめに
1.1. ビジネス統合
1.2. サービス指向アーキテクチャーとは
はじめに
SOA (Service Oriented Architecture) は単一のプログラムまたはテクノロジーではありません。ソフトウェア設計パラダイムと見なします。
1.3. サービス指向アーキテクチャーの重要なポイント
- 交換される メッセージ
- サービスリクエスターおよびプロバイダーとして動作する エージェント
- メッセージを送受信できるようにする 共有トランスポートメカニズム。
1.4. JBoss Enterprise SOA Platform とは
1.5. Service-Oriented Architecture Paradigm
- サービスプロバイダー
- サービスプロバイダーはサービスへのアクセスを許可し、サービスの説明を作成し、サービスブローカーに公開します。
- サービスリクエスター
- サービスリクエスターは、サービスブローカーが提供するサービスの説明を検索して、サービスを検出します。リクエスターはサービスプロバイダーが提供するサービスにバインドするロールも果たします。
- サービスブローカー
- サービスブローカーは、サービスの説明のレジストリーをホストします。リクエスターをサービスプロバイダーにリンクします。
1.6. コアおよびコンポーネント
1.7. JBoss Enterprise SOA Platform のコンポーネント
- 完全な Java EE 準拠のアプリケーションサーバー (JBoss Enterprise Application Platform)
- Enterprise Service Bus (JBoss ESB)
- ビジネスプロセス管理システム (jBPM)
- ビジネスルールエンジン (JBoss ルール)
- オプションの JBoss Enterprise Data Services (EDS) 製品のサポート。
1.8. JBoss Enterprise SOA Platform の機能
- JBoss Enterprise Service Bus (ESB)
- ドメインはサービス間でメッセージを送信し、それらを変換して、異なるタイプのシステムで処理できるようにします。
- Business Process Execution Language (BPEL)
- Web サービスを使用して、この言語を使用してビジネスルールをオーケストレーションできます。これは、ビジネスプロセス命令を簡単に実行するために SOA に含まれています。
- Java Universal Description、Discovery and Integration (jUDDI)
- これは SOA のデフォルトサービスレジストリーです。ここで説明する内容は、インストラクター上のサービスに関する情報をすべて保管する場所です。
- Smooks
- この変換エンジンは SOA と組み合わせて使用してメッセージを処理できます。また、メッセージを分割して正しい宛先に送信するためにも使用できます。
- JBoss ルール
- これは、SOA にパッケージ化されたルールエンジンです。受信するメッセージからデータを推測して、実行する必要があるアクションを判別できます。
1.9. JBoss Enterprise SOA Platform の JBossESB コンポーネントの機能
- 複数のトランスポートおよびプロトコル
- リスナーアクションモデル (これにより、サービスを相互に選択可能)
- コンテンツベースのルーティング (JBoss Rules エンジン、XPath、Regex、および Smooks 経由)
- サービスオーケストレーション機能を提供するために JBoss Business Process Manager (jBPM) との統合
- ビジネスルールの開発機能を提供するために、JBoss ルールとの統合
- BPEL エンジンとの統合。
- さまざまなトランスポートメカニズム (電子メールや JMS など) と連携するよう設定されます。
- 汎用オブジェクトリポジトリーとして使用します。
- プラグ可能なデータ変換メカニズムを実装できるようにします。
- 対話のロギングをサポートします。
org.jboss.internal.soa.esb
と org.jboss.soa.esb
の 2 つのツリーがあります。org.jboss.internal.soa.esb
パッケージの内容をそのまま使用します。これは、通知なしに変更される可能性があるためです。これとは対照的に、org.jboss.soa.esb
パッケージ内のすべての内容は、Red Hat の非推奨ポリシーでカバーされます。
1.10. タスク管理
1.11. 統合のユースケース
1.12. ビジネス環境での JBoss Enterprise SOA Platform の使用
パート I. はじめに
第2章 はじめに
2.1. 対象読者
2.2. 本書のねらい
Aim
Enterprise Service Bus Services ガイドは、開発者が JBoss Enterprise SOA Platform にデプロイするサービスの作成方法を学習することを目的としています。リーダーは、Web アプリケーションの使用、ルールサービスの設定、およびコンテンツベースのルーティング機能の設定方法、メッセージの変換およびサービスのデプロイ方法を説明します。
2.3. データのバックアップ
第3章 basics
3.1. 初期状態のアクション
3.2. JBoss Enterprise SOA Platform の非ボックスアクション
- トランスフォーマーとコンバーター
- トランスフォーマーとコンバーターアクションを使用して、メッセージデータをある形式から別の形式に変更します。
- ビジネスプロセス管理
- ソフトウェアを jBPM と統合する場合は、ビジネスプロセス管理アクションを使用します。
- スクリプト
- スクリプトアクションを使用して、サポートされているスクリプト言語で書かれたタスクを自動化します。
- サービス
- コードを Enterprise Java Beans と統合する際に、サービスアクションを使用します。
- Routing
- メッセージデータを宛先サービスに移動する際にルーティングアクションを使用します。
- Notifier
- データを、認識しない宛先に送信する場合は、通知アクションを使用します。
- Web Services/SOAP
- Web サービスをサポートする必要がある場合は、Web サービスアクションを使用します。
3.3. Quickstart
SOA_ROOT/jboss-as/samples/quickstarts/
ディレクトリーには、数十のクイックスタートが含まれています。Apache Ant を使用して、すべてのクイックスタートをビルドしてデプロイします。
3.4. クイックスタートに関する重要事項
- 各クイックスタートは、Apache Ant を使用してビルドおよびデプロイする必要があります。
- 各クイックスタートは、
samples/quickstarts/conf/quickstarts.properties
ファイルを使用して、サーバーがインストールされたディレクトリーなどの環境固有の設定オプションを保存します。サーバーのインストールに一致するquickstarts.properties
ファイルを作成する必要があります。プロパティーファイルの例 (quickstarts.properties-example
) が含まれています。 - クイックスタートごとに要件が異なります。これらは、個別の
readme.txt
ファイルに記載されています。 - すべてのクイックスタートをすべてのサーバープロファイルで実行できるわけではありません。
- jBPM クイックスタートには、有効な jBPM コンソールのユーザー名とパスワードが必要です。これらを
SOA_ROOT/jboss-as/samples/quickstarts/conf/quickstarts.properties
ファイルにプロパティーとして追加して提供します。# jBPM console security credentials jbpm.console.username=admin jbpm.console.password=adminpassword
この要件の影響を受けるクイックスタートは、bpm_orchestration1
、bpm_orchestration2
、bpm_orchestration3
、およびbpm_orchestration4
です。 - サーバーが ヘッドレス モードで実行されていない場合は、一部のクイックスタート (groovy_gateway など) のみを実行できます。(JBoss Enterprise SOA Platform はデフォルトでヘッドレスモードで起動するように設定されています。)重要Red Hat は、実稼働サーバーをヘッドレスモードでのみ実行することをお勧めします。
3.5. クイックスタートの詳細
手順3.1 タスク
- クイックスタートの
readme.txt
ファイルを調べてください。 - クイックスタートのディレクトリーで ant help コマンドを実行します。
3.6. "Hello World" クイックスタートの仕組みの概要
図3.1 イメージ
- JBoss Enterprise SOA Platform サーバーが
Window1
で起動され、helloworld クイックスタートがデプロイされるとFirstServiceESB:SimpleListener
サービスが Service Registry サービスに追加されます。 - JMS クライアントは、ESB 非対応の "Hello World" メッセージ (プレーンな
String
オブジェクト) を JMS キュー (queue/quickstart_helloworld_Request_gw
) に送信します。 - JMS ゲートウェイリスナーは、ESB 非認識メッセージを受信し、そこから ESB 認識エンドポイントで使用する ESB 認識メッセージを作成します。
JMS ゲートウェイリスナー
は、service registry
を使用して、FirstServiceESB:SimpleListener
サービスの end-point reference (EPR) を見つけます。この場合、EPR はqueue/quickstart_helloworld_Request_esb
JMS キューです。JMS ゲートウェイリスナー
は、新しい ESB 対応メッセージを受け取り、それをqueue/quickstart_helloworld_Request_esb
JMS キューに送信します。FirstServiceESB:SimpleListener
サービスがメッセージを受信します。FirstServiceESB:SimpleListener
サービスはメッセージからペイロードを抽出し、コンソールに出力します。
パート II. サービス登録とホスト
第4章 Service Registry の概要
4.1. このセクションについて
はじめに
このセクションでは、サービスレジストリーの概要と、そのレジストリーがどのように対話するかについて説明します。レジストリーの開発方法については、 jUDDI Registry Guide を参照してください。
4.2. Service Registry
4.3. juddi レジストリー
4.4. juddi および JBoss Enterprise SOA Platform
juddi および JBoss Enterprise SOA Platform
JBoss Enterprise SOA Platform 製品には、jUDDI レジストリーの事前設定されたインストールが含まれています。特定の API を使用して、カスタムクライアントを介してこのレジストリーにアクセスできます。ただし、ビルドするカスタムクライアントは SOA Platform のサポート契約では対応されません。jUDDI の例、ドキュメント、および API の完全なセットには、次の場所からアクセスできます。http://juddi.apache.org/
4.5. サポートされるその他のサービスレジストリー
- SOA ソフトウェア SMS
- HP Systinet
4.6. サービスプロバイダー
4.7. サービスブローカー
4.8. サービスリクエスター
4.9. Web サービス
4.10. Web サービスのエンドポイント
4.11. Web Services Description Language (WSDL)
- サービスの場所
- サービスがサポートする操作
- サービスがサポートするプロトコルバインディング (SOAP、HTTP など)
- アクセス手順
4.12. Universal Description、Discovery and Integration (UDDI) レジストリー
4.13. UDDI アプリケーションプログラミングインターフェイス
- UDDI_Security_PortType
- これは、セキュリティートークンを取得するための API を定義します。有効なセキュリティートークンでは、パブリッシャーはレジストリーに公開できます。セキュリティートークンは、セッション全体に使用できます。
- UDDI_Publication_PortType
- これにより、ビジネスおよびサービス情報を UDDI レジストリーに公開する API が定義されます。
- UDDI_Inquiry_PortType
- これは、UDDI レジストリーをクエリーする API を定義します。この API は通常、セキュリティートークンを必要としません。
- UDDI_CustodyTransfer_PortType
- この API は、ある UDDI ノードから別の UDDI ノードにビジネスのカストディを転送するために使用することができます。
- UDDI_Subscription_PortType
- これは、特定のサービスビジネスで更新を登録する API を定義します。
- UDDI_SubscriptionListener_PortType
- これは、UDDI ノードからサブスクリプション通知を受け取るためにクライアントが実装する必要のある API を定義します。
- UDDI_Replication_PortType
- これは、UDDI ノード間でレジストリーデータを複製する API を定義します。
- UDDI_ValueSetValidation_PortType
- これは、外部プロバイダーが検証を設定するのを許可するためにノードによって使用されます。keyedReferences または keyedReferenceGroups が有効かどうかを評価する Web サービス。
- UDDI_ValueSetCaching_PortType
- UDDI ノードは、このような Web サービスから取得したキャッシュされた値を使用して、パブリッシャー参照自体を検証することができます。
4.14. UDDI ページタイプ
- 緑色のページ
- 緑のページでは、クライアントを提供されているサービスにバインドできる情報を提供します。
- 黄色のページ
- 黄色のページは、所属する業界に基づいて企業を分類するために使用されます。
- ホワイトページ
- ホワイトページには、サービスを提供する会社の名前、住所、その他の連絡先情報などの一般情報が含まれます。
4.15. Service Registry および JBoss Enterprise SOA Platform
4.16. jUDDI および ESB
4.17. レジストリーの仕組み
- JBoss Enterprise Service Bus は、レジストリーインターフェイスを介したレジストリーとのすべての対話をフェデレーションします。
- その後、このインターフェイスの JAXR 実装を呼び出します。
- JAXR API は JAXR 実装を使用する必要があります。(デフォルトでは Apache Scout です。)
- Apache Scout は、次に レジストリー を呼び出します。
第5章 出版契約
5.1. サービスリストアプリケーション
5.2. エンドポイントコントラクト
5.3. JBoss Enterprise SOA Platform がエンドポイントコントラクトを検出する方法
Unavailable on Contract
5.4. 契約書を発行する
手順5.1 タスク
- コントラクト情報を公開するには、次の
org.jboss.internal.soa.esb.publish.Publish
アノテーションをアクションに与える必要があります。(この例では説明目的で SOAPProcessor を使用しています):@Publish(JBossWSWebserviceContractPublisher.class) public class SOAPProcessor extends AbstractActionPipelineProcessor { //TODO: implement }
org.jboss.soa.esb.actions.soap.ContractPublisher
インターフェイスを実装します(実装する必要があるのは 1 つのメソッドだけです)。public ContractInfo getContractInfo(EPR epr);
パート III. サービスオーケストレーションおよびビジネスプロセス管理
第6章 jBPM Web アプリケーション
6.1. jBPM
6.2. jBPM インテグレーションと機能の統合
- サービスオーケストレーション:プロセス定義を作成して、Business Process Manager を使用してサービスをオーケストレーションできます。
- ヒューマンタスク管理:Business Process Manager を使用すると、マシンベースのサービスをユーザーが行うタスクの管理と統合できます。
6.3. ビジネス手順で手順のグラフィカル表現の作成
手順6.1 タスク
- jBPM の Process Designer 機能を使用します。注記このツールを使用する副次的な利点は、ビジネスアナリストと技術開発者間の優れた作業関係を追いつくことができることです。
6.4. jBPM Web コンソール
6.5. jBPM Web アプリケーションの JBoss Enterprise SOA Platform へのデプロイ
- デプロイメントオプションは多数あります。GPD デプロイメント (グラフィカル設計プロセス)タブ、JSF コンソールのアップロードフォーム、Ant DeployProcessTask の使用から選択します。警告jBPM ライブラリーはデプロイ済みのアプリケーションに追加しないでください。
jbpm.esb
モジュールは、jBPM アプリケーションの実行に必要なライブラリーおよび設定ファイルをすでに提供しています。提供されたバージョンとデフォルト設定を常に使用します。これは、クラ出力ディングの競合や設定の不一致などの問題を防ぐために、Red Hat の高品質エンジニアリングテストによって改良されているためです。注記プロセス定義は Web アプリケーションとは別にデプロイする必要があります。Red Hat は、Web アプリケーションの前にプロセスをデプロイすることを推奨します。これにより、後者はプロセスが常に利用可能であると仮定して動作させることができます。 - jBPM グラフィカル設計プロセスエディターには、Diagram、Deployment、Design、および Source の 4 つのモードが含まれます。これは、エディター下部のスイッチ可能なタブとして利用できます。プロジェクトのデプロイメント設定を調整するには、Deployment モードを開くタブを選択する必要があります。簡単に変更することも、設定がニーズに合わない場合はそれらをデフォルトにリセットできます。
- マルチテナンシーのユースケースでは、単一のサーバーが多数のアプリケーションをホストするので、それぞれ異なる設定が必要になります。プラットフォームで提供されるデフォルトの設定ファイルを上書きしないように、各設定ファイルに一意の名前(jbpm.cfg.xml 以外)を指定することを推奨します。
第7章 jBPM 3 の統合
7.1. JBoss Business Process Manager
7.2. JBPM 統合設定
- JBPM データベースを作成するには、
DatabaseInitializer
MBean を起動します。(この MBean の設定設定はSOA_ROOT/jboss-as/server/PROFILE/deploy/jbpm.esb/jbpm-service.xml
ファイルの最初の設定要素にあります。)警告JbpmDS データソースはSOA_ROOT/jboss-as/server/PROFILE/deploy/jbpm.esb
にある jbpm-ds.xml ファイルで定義されます。デフォルトでは、Hypersonic データベースを使用します。これをライブ環境で常に実稼働品質のデータベースに変更します。警告JBoss Enterprise SOA Platform には、インメモリー参照データベースである Hypersonic が同梱されています。これはテスト環境でのみ使用してください。 - 以下の例に従ってください。
<classpath codebase="deploy" archives="jbpm.esb"/> <classpath codebase="deploy/jbossesb.sar/lib" archives="jbossesb-rosetta.jar"/> <mbean code="org.jboss.internal.soa.esb.dependencies.DatabaseInitializer" name="jboss.esb:service=JBPMDatabaseInitializer"> <attribute name="Datasource">java:/JbpmDS</attribute> <attribute name="ExistsSql">select count(*) from JBPM_ID_USER</attribute> <attribute name="SqlFiles"> jbpm-sql/jbpm.jpdl.hsqldb.sql </attribute> <depends>jboss.jca:service=DataSourceBinding,name=JbpmDS</depends> <attribute name="UseEOL">true</attribute> </mbean> <mbean code="org.jboss.soa.esb.services.jbpm.configuration.JbpmService" name="jboss.esb:service=JbpmService"> </mbean>
7.3. jBPM 5 から JBoss Warehouse の統合
<service category="EsbJbpm5Example" name="JBpm5CallbackService" description="Service which makes Callbacks into jBPM"> <listeners> <jms-listener name="JMS-DCQListener" busidref="jBPMCallbackBus" maxThreads="1" /> </listeners> <actions mep="OneWay"> <action name="action" class="org.jboss.soa.esb.services.jbpm5.actions.Bpm5Callback"> <property name="process-definition-name" value="sample.bpmn"/> </action> </actions> </service> </services>
<property name="process-definition-name" value="sample.bpmn"/>
7.4. DatabaseInitializer MBean のデフォルト値
表7.1 DatabaseInitializer MBean のデフォルト値
プロパティー | 説明 | デフォルト |
---|---|---|
データソース | JBPM データベースのデータソース。 | java:/JbpmDS |
ExistsSql | この SQL コマンドを使用して、データベースが存在することを確認します。 | select count (*) from JBPM_ID_USER |
SqlFiles | これらのファイルには、JBPM データベースが見つからない場合に作成する SQL コマンドが含まれています。 | jbpm-sql/jbpm.jpdl.hsqldb.sql, jbpm-sql/import.sql |
DatabaseInitializer
MBean は JbpmDS
がデプロイされるまで待機してから、それ自体をデプロイするように設定されています。
7.5. JbpmService MBean
JbpmService
Bean は、 JBoss Business Process Manager のジョブエグゼキューター のライフサイクルを jbpm.esb
のものに関連付けます。これは、起動時に ジョブエグゼキューター
インスタンスを起動し、シャットダウン時にこれを閉じることで行います。
7.6. JBPM の設定
SOA_ROOT/jboss-as/server/PROFILE/deploy/jbpm.esb/
ディレクトリー内の 3 つのファイルに保存されます。
jbpm.cfg.xml
hibernate.cfg.xml
jbpm.mail.templates.xml
jbpm.cfg.xml
ファイルは、JTA トランザクションマネージャーを使用するように JBPM に指示します。<service name="persistence"> <factory> <bean class="org.jbpm.persistence.jta.JtaDbPersistenceServiceFactory"> <property name="isTransactionEnabled"><false/></property> <property name="isCurrentSessionEnabled"><true/></property> <!--property name="sessionFactoryJndiName"> <string value="java:/myHibSessFactJndiName" /> </property--> </bean> </factory> </service>
hibernate.cfg.xml
ファイルも、JTA トランザクションマネージャー
を使用して JBPM に通知します。<!-- JTA transaction properties (begin) --> <property name="jta.UserTransaction">UserTransaction</property> <property name="hibernate.current_session_context_class">jta</property> <property name="hibernate.transaction.factory_class">org.hibernate.transaction.JTATransactionFactory</property> <property name="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.JBossTransactionManagerLookup</property> <!-- JTA transaction properties (end) -->
注記Hibernate を使用してデータベーススキーマを作成しないでください。代わりにDatabaseInitializer
MBean を使用してください。jbpm.mail.templates.xml
ファイルには以下の内容が含まれます。jboss-as ]$ cat server/default/deploy/jbpm.esb/jbpm.mail.templates.xml <?xml version="1.0" encoding="UTF-8"?> <mail-templates> <variable name="taskListBaseURL" value="http://localhost:8080/jbpm-console/app/task.jsf?id=" /> <mail-template name='task-assign'> <actors>${taskInstance.actorId}</actors> <subject>Task notification: ${taskInstance.name}</subject> <text><![CDATA[Hi ${taskInstance.actorId}, Task '${taskInstance.name}' has been assigned to you. Go for it: ${taskListBaseURL}${taskInstance.id} Sent by jBPM]]></text> </mail-template> <mail-template name='task-reminder'> <actors>${taskInstance.actorId}</actors> <subject>Task reminder: ${taskInstance.name}</subject> <text><![CDATA[Hey ${taskInstance.actorId}, Do not forget about task '${taskInstance.name}'. Get going: ${taskListBaseURL}${taskInstance.id} Sent by jBPM]]></text> </mail-template> </mail-templates>
注記各設定ファイルの詳細は、 JBPM Reference Guide を参照してください。
7.7. プロセス定義の作成
- Create ウィザードを使用して空のプロセス定義を作成します。File → New → Other を選択します。ウィザードが Select Wizard ページで開きます。
- JBoss jBPM カテゴリーを選択し、jBPM Process Definition 項目を選択します。Next ボタンをクリックすると、Create Process Definition ページに移動します。
- プロセスアーカイブファイルの名前を入力します。Finish ボタンをクリックしてウィザードを終了し、プロセス定義エディターを開きます。
- Package Explorer を表示すると、プロセス定義の作成には、プロセス定義情報が含まれる
[process name].jpdl.xml
という名前の XML ファイルが作成されていることを確認できます。[process name].jpg
と呼ばれる JPG ファイルも、変更がプロセスに保存されると自動的に生成されます。
7.8. プロセス定義のデプロイ
- サーバーが実行中であることを確認します。
- JBPM グラフィカルエディター のDeployment タブに移動して、プロセスアーカイブ をアクティブにします。注記
processdefinition.xml
ファイルのみをデプロイする必要がある場合がありますが、ほとんどの場合は、タスクフォームなどの他のタイプのアーティファクト
もデプロイします。 - 以下の方法のいずれかを使用して定義をデプロイします。
- JBoss Developer Studio を使用して、デプロイヤーが使用するアップロードサーブレットを設定します。次に、Deploy Process Archive ボタンをクリックします。これは Deployment ビューに表示されます。
- DeployProcessToServer JBPM
ant
タスクの使用 - Deployment ビューのローカルの
.par
ファイルにデプロイメントを保存します。次に、JBPM コンソールを使用してアーカイブをアクティブにします。(これには管理者権限が必要です。)
7.9. JBPM コマンド
表7.2 JBPM コマンド
コマンド | Description |
---|---|
NewProcessInstanceCommand | このコマンドは、JBPM にすでにデプロイされているプロセス定義に関連付けられている新しい ProcessInstance を起動します。NewProcessInstanceCommand は、プロセスインスタンスを 開始 状態のままにします。これは、 開始ノード に関連付けられているタスクの場合に必要です( アクター の task-list にタスクリストがある場合など)。 |
StartProcessInstanceCommand |
これは NewProcessInstanceCommand と同じですが、新規プロセスインスタンスは
開始 位置から最初のノードに自動的に移動します。
|
GetProcessInstanceVariablesCommand |
プロセスインスタンス識別子を使用して、プロセスインスタンスのルートノード変数を表示します。
|
CancelProcessInstanceCommand | ProcessInstance 全体をキャンセルします。( ProcessInstance 識別子を含む、メッセージには JBPM コンテキスト変数を設定する必要があります。)
|
7.10. JBPM での新規プロセスインスタンスの設定
- jboss-exb.xml でのこの動作の設定は以下のようになります。
<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>
- 次の 2 つの属性を入力する必要があります。
- name
アクションパイプライン
で一意であれば、 name 属性に任意の値を使用します。 - classこの属性は必ず
org.jboss.soa.esb.services.jbpm.actions.BpmProcessor
に設定します。
7.11. JBPM 設定プロパティー
表7.3 JBPM 設定プロパティー
プロパティー | Description | 必須 ? |
---|---|---|
command |
これは、
NewProcessInstanceCommand 、StartProcessInstanceCommand 、GetProcessInstanceVariablesCommand または CancelProcessInstanceCommand のいずれかでなければなりません。
|
はい
|
process-definition-name |
NewProcessInstanceCommand および StartProcessInstanceCommand で process-definition-id プロパティーが使用されていない場合に必要です。このプロパティーの値は、新規インスタンスを必要とするすでにデプロイ済みのプロセス定義を参照する必要があります。(このプロパティーは CancelProcessInstanceCommand には適用されません。)
| 時々 |
process-definition-id |
NewProcessInstanceCommand および StartProcessInstanceCommand で process-definition-name プロパティーが使用されていない場合に必要です。このプロパティーの値は、新規インスタンスが作成される既存のデプロイ済みプロセス定義を参照する必要があります。(このプロパティーは CancelProcessInstanceCommand には適用されません。)
|
時々
|
actor | JBPM アクター 識別子を指定します。( NewProcessInstanceCommand および StartProcessInstanceCommandにのみ適用)
| いいえ |
key |
JBPM キーの値を指定します。キーは、プロセスインスタンスの文字列ベースのビジネスキープロパティーです。ビジネスキーが指定されている場合は、ビジネスキーとプロセス定義の組み合わせは一意でなければなりません。キー値は MVEL 式を保持し、EsbMessage から必要な値を抽出できます。たとえば、メッセージのボディーに
businessKey という名前付きパラメーターがある場合は、 body.businessKey が使用されます。(このプロパティーは NewProcessInstanceCommand および StartProcessInstanceCommand にのみ適用されます。)
| いいえ |
transition-name |
これは StartProcessInstanceCommand にのみ適用されます。現在のノードから移行が複数ある場合にのみ使用してください。このプロパティーが指定されていない場合、ノードからデフォルトの移行が行われます。デフォルトの移行は、JBPM
processdefinition.xml のそのノードに定義された移行リストの最初の移行です。
| いいえ |
esbToBpmVars |
これは、New- および StartProcessInstanceCommand の任意のプロパティーです。これは、MAn Message から抽出して、その特定のプロセスインスタンスの JBPM コンテキストに設定する必要がある変数の一覧を定義します。この一覧はマッピング要素で設定され、各要素には以下の属性を設定できます。
|
いいえ
|
7.12. JBPM の EsbMessage Body 設定
表7.4 JBPM の EsbMessage Body 設定
プロパティー | 説明 |
---|---|
jbpmProcessInstId |
これは、GetProcessInstanceVariablesCommand コマンドおよび CancelProcessInstanceCommand コマンドに適用される必須の Body メッセージボディーパラメーターです。これを EsbMessage 本文の名前付きパラメーターとして手動で設定します。
|
7.13. adobe-to-JBPM 例外処理
JbpmException
が出力された場合、アクションパイプライン
に渡されます。パイプラインはエラーをログに記録し、メッセージを DeadLetterService
に転送し、(設定されている場合) faultTo
エンドポイント参照にエラーを送信します。
7.14. JBPM-JBossESB-to-ESB Integration
EsbActionHandler
と EsbNotifier
です。EsbActionHandler
は、サービスにメッセージを送信し、応答を待ちます。一方、EsbNotifier
は応答を待ちません。
lib
ディレクトリーにデプロイします。
7.15. JBPM での通知アクション
- 以下のように
EsbNotifier
を JBPMprocessdefinition.xml
ファイルの 送信移行 にアタッチします。<node name="ShipIt"> <transition name="ProcessingComplete" to="end"> <action name="ShipItAction" class="org.jboss.soa.esb.services.jbpm.actionhandlers.EsbNotifier"> <esbCategoryName>BPM_Orchestration4</esbCategoryName> <esbServiceName>ShippingService</esbServiceName> <bpmToEsbVars> <mapping bpm="entireCustomerAsObject" esb="customer" /> <mapping bpm="entireOrderAsObject" esb="orderHeader" /> <mapping bpm="entireOrderAsXML" esb="entireOrderAsXML" /> </bpmToEsbVars> </action> </transition> </node>
- 以下の属性を指定できます。
- nameこれは必須です。アクションのユーザー指定の名前です。
- classこれは必須です。
org.jboss.soa.esb.services.jbpm.actionhandlers.EsbNotifier
に設定する必要があります。
7.16. アーキテクトアクションハンドラーの設定
EsbActionHandler
をノードに割り当て、ノードの入力時にアクションを呼び出します。EsbActionHandler
が実行されると、ノードは移行シグナルを待つ(通常JBossESB コールバック
サービスによって送信されます)。- 以下のように を設定します。
<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>
7.17. EsbActionHandler 拡張設定
EsbActionHandler
は、EsbNotifier
の設定に依存します。拡張機能は、以下のサブ要素で設定されます。
表7.5 EsbActionHandler 拡張設定
プロパティー | Description | 必須 ? |
---|---|---|
esbToBpmVars | BpmProcessor 設定の esbToBpmVars プロパティーと同じです。このサブ要素は、Mutuals メッセージから抽出して、その特定のプロセスインスタンスの Business Process Manager コンテキストで設定する必要がある変数の一覧を定義します。指定しない場合、変数が設定されている場合、globalProcessScope 値はデフォルトで true になります。
この一覧はマッピング要素で設定され、各要素には以下の属性を設定できます。
| いいえ |
exceptionTransition | サービスの処理中に例外が発生した場合に使用する移行の名前。現在のノードには、複数の送信移行が必要です。その 1 つは 例外処理を処理 できます。 | いいえ |
7.18. startProcess 上の jBPM5 プロセスにパラメーターを渡す
// create the ESB message Message esbMessage = MessageFactory.getInstance().getMessage(); // add a parameter esbMessage.getProperties().setProperty("name", "Laurel");
7.19. signalEvent で jBPM5 プロセスへパラメーターを渡す
// create the ESB message Message esbMessage = MessageFactory.getInstance().getMessage(); // set the process event type as defined in the process definition esbMessage.getProperties().setProperty("processEventType", "NewMessage"); // add a parameter esbMessage.getProperties().setProperty("name", "Hardy"); // setup data required to identify the intended target process instance ContextImpl ctxi = (ContextImpl) esbMessage.getContext(); // set the session id ctxi.setContext("jbpm5-session-id", sessionId); // set the instance id. ctxi.setContext("jbpm5-processinstance-id", processInstanceId);
<definition ...> <itemDefinition id="_nameItem" structureRef="String" /> <process name="Hello" tns:packageName="defaultPackage" ...> <property id="name" itemSubjectRef="_nameItem"/> <!-- ... --> </process> <!-- ... --> </definition>
<definition ...> <itemDefinition id="_objectMapItem" structureRef="java.util.Map" /> <process name="Hello" tns:packageName="defaultPackage" ...> <property id="objectMap" itemSubjectRef="_objectMapItem"/> <!-- ... --> </process> <!-- ... --> </definition>
String name2 = objectMap.get("name"); // will retrieve the Hardy string
7.20. シグナルイベントの例
<intermediateCatchEvent id="_4" name="Signal" > <dataOutput id="_4_Output" name="event" /> <dataOutputAssociation> <sourceRef>_4_Output</sourceRef> <targetRef>objectMap</targetRef> </dataOutputAssociation> <outputSet> <dataOutputRefs>_4_Output</dataOutputRefs> </outputSet> <signalEventDefinition signalRef="NewMessage"/> </intermediateCatchEvent>
7.21. 2009 Notifier Sub-Elements の一覧
表7.6 2009 Notifier Sub-Elements の一覧
サブ要素 | Description |
---|---|
esbCategoryName
|
これはグローバルなサービスのカテゴリー名で、 reply-to-originator 機能を使用していない場合に必要です。
|
esbServiceName
|
これは、Kamelet サービスの名前であり、 reply-to-originator 機能を使用していない場合に必要です。
|
replyToOriginator |
これを使用して、作成時にプロセスインスタンスに以前保存した reply またはfault オリジンアドレスを指定します。
|
globalProcessScope
|
この要素はオプションのブール値パラメーターです。
bpmToEsbVars 変数が見つかるデフォルトのスコープを設定します。globalProcessScope が true に設定されている場合、トークン階層 ( プロセスインスタンス スコープ)内の変数を検索します。false に設定すると、トークンのスコープにある変数が取得されます。トークン自体が指定の名前の変数を持たない場合、トークン階層はその変数の検索に使用されます。要素が完全に省略された場合、globalProcessScope はデフォルトで false になります。
|
bpmToEsbVars
|
この要素は任意です。サブ要素の一覧を取得し、それらを使用して JBPM コンテキスト変数を anifies message location にマッピングします。これらのマッピングサブ要素にはそれぞれ、以下の属性を指定できます。
|
bpm |
これは必の須属性です。JBPM コンテキストの変数の名前です。名前は MVEL タイプの式を指定できるため、より大きなオブジェクトから特定のフィールドを抽出できます。MVEL のルートは JBPMContextInstance に設定されているため、たとえば以下のようなマッピングを使用できます。
<mapping bpm="token.name" esb="TokenName" /> <mapping bpm="node.name" esb="NodeName" /> <mapping bpm="node.id" esb="esbNodeId" /> <mapping bpm="node.leavingTransitions[0].name" esb="transName" /> <mapping bpm="processInstance.id" esb="piId" /> <mapping bpm="processInstance.version" esb="piVersion" />
JBPM コンテキスト変数名は直接参照することもできます。
|
esb
|
オプション:これは、Enterprise Service Bus Message の変数の名前です。MVEL タイプの式にすることができます。(上記の例の属性値 TokenName は
body.TokenName と同じです。BODY_CONTENT "addresses" the body directly と呼ばれる特殊な値。) デフォルトでは、変数はこのメッセージの本文で名前付きパラメーターとして設定されます。esb 属性を省略するには、bpm 属性の値に置き換えます。
|
process-scope
|
この属性は任意です。これは、このマッピングの
globalProcessScope の設定をオーバーライドするために使用されるブール値を含むパラメーターです。
|
デバッグ
-level ロギングを有効にします。
7.22. 10^ServiceWorkItemHandler Sub-Elements の一覧
表7.7 10^ServiceWorkItemHandler Sub-Elements の一覧
名前 | Description |
---|---|
ServiceCategory | これは、jBPM 5 がメッセージを配信するサービスの カテゴリー 名です。 |
ServiceName | これは、jBPM 5 がメッセージを配信するサービスのサービス名です。 |
7.23. サブドメインアクションWorkItemHandler サブセットの一覧
表7.8 サブドメインアクションWorkItemHandler サブセットの一覧
名前 | Description |
---|---|
ServiceCategory | これは、jBPM 5 がメッセージを配信するサービスの カテゴリー 名です。 |
ServiceName | これは、jBPM 5 がメッセージを配信するサービスのサービス名です。 |
CallbackServiceCategory | コールバックサービスのサービスカテゴリー。コールバックサービスは jboss-esb.xml に提供する必要があります。 |
CallbackServiceName | コールバックサービスのサービス名。コールバックサービスは jboss-esb.xml に提供する必要があります。 |
replyToOriginator | これを使用して、作成時にプロセスインスタンスに以前保存した reply またはfault オリジンアドレスを指定します。 |
jbpm5-session-id | このプロセスを開始したセッションの jbpm 5 セッション ID。これは、コールバックサービスが現在のワークアイテムを完了できるようにするために必要です。 |
7.24. JBPM でのタイムアウト値の追加
- JBPM ネイティブ タイマー を適切なノードに追加します。この例では、タイマーが設定され、シグナルが 10 秒で受信されない場合に
time-out
と呼ばれる遷移がトリガーされます。<timer name='timeout' duedate='10 seconds' transition='time-out'/>
7.25. JBPM-to-ESB 例外処理
表7.9 JBPM-to-ESB 例外処理
Error | 解決方法 |
---|---|
配信エラー | 例外ハンドラー ( TB-JBPM-USER )を JBPM ノードに追加し、ユーザーがサービス名を誤ってスペルした MessageDeliveryException を処理します。(詳細 http://docs.jboss.com/jbpm/v3/userguide/processmodelling.html は を参照してください。) |
エラーの処理 | サービスは要求を受け取りますが、処理中にエラーが発生します。EsbActionHandler から呼び出しが行われると、例外は JBoss Business Process Manager に報告されました。 |
7.26. 例外処理の例
Time-out:
EsbActionHandler
アクションを使用し、ノードがコールバックを待機している場合は、待機期間を制限できます。これを行うには、ノードにタイマーを追加します。(これは、以下のプロセス定義スニペットで Service1
を設定する方法です。) タイマーは一定期間(この場合は 10 秒)に設定できます。
<node name="Service1"> <action class= "org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler"> <esbCategoryName>MockCategory</esbCategoryName> <esbServiceName>MockService</esbServiceName> </action> <timer name='timeout' duedate='10 seconds' transition='time-out-transition'/> <transition name="ok" to="Service2"></transition> <transition name="time-out-transition" to="ExceptionHandling"/> </node>
Service1
には、2 つの送信移行があります。最初のものは ok
です。2 番目のものは time-out-transition
です。
ただし、サービスの処理に 10 秒かかると、タイマーが代わりに実行されます。タイマーの transition 属性は time-out-transition
に設定されます。つまり、この移行はタイムアウト時に取られます。
ExceptionHandling
ノードで終了します。ここから、補正作業を実行できます。
例外移行: exceptionTransition
を定義して、処理中のサービス midst で発生した例外を処理できます。これにより、メッセージに faultTo
エンドポイント参照が設定されます。つまり、Enterprise Service Bus はこのノードにコールバックします。これは exceptionTransition
を通知します。
Service2
には 2 つの送信移行があります。通常、問題の発生時に ok
移行が行われます。名前が示すように、処理中に 例外
を出力するため、サービスがあるときに例外が発生します。
<node name="Service2"> <action class= "org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler"> <esbCategoryName>MockCategory</esbCategoryName> <esbServiceName>MockService</esbServiceName> <exceptionTransition>exception</exceptionTransition> </action> <transition name="ok" to="Service3"></transition> <transition name="exception" to="ExceptionHandling"/> </node>
Service2
の前述の定義では、アクションの exceptionTransition は exception
に設定されています。このシナリオでは、プロセス自体は ExceptionHandling
ノードでも終了します。
例外の決定:
Service3
の設定と、それに続く exceptionDecision
ノードを確認します。Service3
プロセスは通常の結論に処理され、そのノードから移行は予想通りに行われます。
errorCode
が設定され、exceptionDecision
ノードは、ここで同じ名前の変数が呼び出されたかどうかを確認します。
<node name="Service3"> <action class= "org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler"> <esbCategoryName>MockCategory</esbCategoryName> <esbServiceName>MockService</esbServiceName> <esbToBpmVars> <mapping esb="SomeExceptionCode" bpm="errorCode"/> </esbToBpmVars> </action> <transition name="ok" to="exceptionDecision"></transition> </node> <decision name="exceptionDecision"> <transition name="ok" to="end"></transition> <transition name="exceptionCondition" to="ExceptionHandling"> <condition>#{ errorCode!=void }</condition> </transition> </decision>
esbToBpmVars
マッピング要素は、メッセージのボディーから SomeExceptionCode
を呼び出し、JBPM コンテキスト で設定します。
(これは SomeExceptionCode
が設定されていることを前提としています。)
exceptionDecision
という名前の次のノードでは、処理が正常であれば ok
移行が実行されますが、JBPM コンテキストで errorCode
という変数が見つかると、代わりに exceptionCondition
遷移が取得されます。
<condition>#{ errorCode!=void }</condition>
7.27. JBPM コンソールの起動
- サーバーが停止したら、アドレス から JBPM コンソール にアクセスし http://localhost:8080/jbpm-console/app/processes.jsf ます。
- JBPM コンソールを使用して、プロセスおよびタスクをデプロイおよび監視できるようになりました。
bpm_orchestration4
クイックスタートはこの機能を示しています。警告JbpmDS
データソースはjbpm-ds.xml
ファイルで定義されます。デフォルトでは、 Hypersonic データベースを使用します。これをライブ環境で常に実稼働品質のデータベースに変更します。注記すべてのjbpm.esb
デプロイメントが同じデータベースインスタンスを共有することを確認してください。(これは、さまざまな Enterprise Service Bus ノードが同じプロセス定義にアクセスできるようにするためです。)
7.28. JBPM Deployment
表7.10 JBPM Deployment
プロパティー | Description |
---|---|
jbpm.esb/META-INF
|
このディレクトリーには、
deployment.xml および jboss-esb.xml ファイルが含まれます。
|
deployment.xml
| jbossesb.esb と JbpmDS のデータソースファイルの 2 つのリソースファイルを指定します。これらのファイルの情報は、デプロイメントの順序を決定するために使用されます。
<jbossesb-deployment> <depends>jboss.esb:deployment=jbossesb.esb</depends> <depends>jboss.jca:service=DataSourceBinding,name=JbpmDS</depends> </jbossesb-deployment> |
jboss-esb.xml
|
このファイルは、
JBpmCallbackService という内部サービスをデプロイします。
<services> <service category="JBossESB-Internal" name="JBpmCallbackService" description="Service which makes Callbacks into jBPM"> <listeners> <jms-listener name="JMS-DCQListener" busidref="jBPMCallbackBus" maxThreads="1" /> </listeners> <actions mep="OneWay"> <action name="action" class="org.jboss.soa.esb.services.jbpm.actions.JBpmCallback"/> </actions> </service> </services>
この内部サービスは
jBPMCallbackBus をリッスンします。デフォルトでは、JBossMQ ( jbmq-queue-service.xml ファイル経由)または JBossMessaging ( jbm-queue-service.xml ファイル経由)のいずれかに設定されます。 後者は、Java Message Service Queue のメッセージングプロバイダーです。これらのファイルのいずれかが jbpm.esb アーカイブにデプロイされていることを確認します。
|
第8章 jBPM 5 の統合
8.1. 統合設定
8.2. jBPM 5 の設定
<?xml version="1.0" encoding="UTF-8"?><jbossesb-deployment> <depends>jboss.esb:deployment=jbossesb.esb</depends> <depends>jboss.jca:name=jboss/datasources/jbpm5DS,service=DataSourceBinding</depends> </jbossesb-deployment>
8.3. JBossESB から jBPM 5
表8.1 jBPM 5 コマンド
コマンド | Description |
---|---|
startProcess |
jBPM にすでにデプロイされているプロセス定義を指定して、新しい ProcessInstance を起動します。
|
signalEvent |
イベントが発生したプロセスへシグナルします。
|
abortProcessInstance |
ProcessInstance をキャンセルします。つまり、イベントが発生すると、ProcessInstance 全体がキャンセルされます。このアクションでは、特に ProcessInstance Id で一部の jBPM コンテキスト変数をメッセージに設定する必要があります。
|
- name必須属性。name 属性の値は、アクションパイプラインで一意であれば自由に使用できます。
- class必須属性。この属性は "org.jboss.soa.esb.services.jbpm5.actions.Bpm5Processor" に設定する必要があります
8.4. jBPM コンテキスト設定プロパティー
Message esbMessage = MessageFactory.getInstance().getMessage(); ContextImpl ctxi = (ContextImpl) esbMessage.getContext(); ctxi.setContext("jbpm5-session-id", 10); ctxi.setContext("jbpm5-processinstance-id", 10L);
表8.2 jBPM 設定プロパティー
プロパティー | Description | 必須 ? |
---|---|---|
process-action |
startProcess、signalEvent、または abortProcessInstance のいずれかである必要があります。
|
はい
|
process-definition-name |
必須プロパティー。このプロパティーの値は、すでに jBPM にデプロイされており、新しいインスタンスを作成するプロセス定義を参照する必要があります。
|
はい
|
process-id |
このプロパティーの値は、新しいインスタンスを作成する jBPM のプロセス定義 ID を参照する必要があります。
|
はい
|
esbToBpmVars |
任意のプロパティー。このプロパティーは、EsbMessage から抽出し、特定のプロセスインスタンスの jBPM コンテキストに設定する必要がある変数のリストを定義します。この一覧はマッピング要素で設定されます。各 mapping 要素には以下の属性を指定できます。
|
いいえ
|
handlerClass |
WS Human Task ハンドラークラス(デフォルト:org.jbpm.task.service.hornetq.CommandBasedHornetQWSHumanTaskHandler)
|
はい
|
handlerHost |
WS Human タスクサーバーのホスト名(デフォルト:127.0.0.1)
|
はい
|
handlerPort |
WS Human Task サーバーのホスト名(デフォルト:5446)
|
はい
|
- org.jbpm.process.workitem.wsht.CommandBasedWSHumanTaskHandler
- handlerHost - WS Human タスクサーバーのホスト名(デフォルト:127.0.0.1)
- handlerPort - WS Human タスクサーバーのホスト名(デフォルト:9123)
8.5. ボディー設定プロパティー
表8.3 ボディー設定プロパティー
プロパティー | Description | 必須 ? |
---|---|---|
jbpm5-processinstance-id |
signalEvent および abortProcessInstance コマンドに適用されるための context プロパティー。
|
はい
|
jbpm5-session-id |
読み込むセッションをアクションに指示するための context プロパティー。
|
はい
|
第9章 サービスオーケストレーションとアーキテクト
9.1. サービスオーケストレーション
9.2. オーケストレーションダイアグラムの作成
- File → New → Other を選択します。
Selection
ウィザードから JBoss jBPM Process Definition を選択します。- プロセス定義を保存します。混乱を避けるために、プロセス定義ごとに個別のディレクトリーを使用します。
- jBPM 統合開発環境 のメニューパレットから Process Design ビューへの "drag-and-drop" 項目を開始します。設計モードとソースモードを切り替えて、追加時に XML 要素を確認できます。
- インテグレーションに必要な XML フラグメントを追加します。
- オーダープロセスダイアグラムをビルドする前に、3 つのサービスを作成およびテストします。これらは通常のグローバルなサービスであり、
jboss-esb.xml
ファイルで定義されます。サービス名とカテゴリーを使用した設定例を以下に示します。<services> <service category="BPM_orchestration4_Starter_Service" name="Starter_Service" description="BPM Orchestration Sample 4: Use this service to start a process instance"> <!-- .... --> </service> <service category="BPM_Orchestration4" name="IntakeService" description="IntakeService: transforms, massages, calculates priority"> <!-- .... --> </service> <service category="BPM_Orchestration4" name="DiscountService" description="DiscountService"> </service> <service category="BPM_Orchestration4" name="ShippingService" description="ShippingService"> <!-- .... --> </service> </services>
EsbActionHandler
またはEsbNotifier
アクションハンドラーのいずれかを使用してこれらのサービスを参照します。( JBoss Business Process Manager が応答を期待する場合はEsbActionHandler
を選択し、何も必要ない場合はEsbNotifier
を選択します。)- ためのサービスが認識されているので、
Start
state ノードをデザインビューにドラッグします。新しいプロセスインスタンスはこのノードで開始されます。 - ノードにドラッグし、
Intake Order
に名前を付けます。 - メニューから Transition を選択し、各ノードをクリックして、
Start
ノードおよびIntake Order
ノードを接続します。それらに接続する矢印が表示されます。最初のIntake Order
を参照します。 - Intake Node に Service および Category 名を追加します。Source ビューを選択します。
Intake Order
ノードのソースコードを確認できます。以下のようになります。<node name="Intake Order"> <transition name="" to="Review Order"></transition> </node>
EsbActionHandler
クラス参照を追加し、続いてサービスカテゴリーと名前、BPM_Orchestration4
、およびIntakeService
のサブ要素設定を追加します。以下のようになります。<node name="Intake Order"> <action name="esbAction" class= "org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler"> <esbCategoryName>BPM_Orchestration4</esbCategoryName> <esbServiceName>IntakeService</esbServiceName> <!-- async call of IntakeService --> </action> <transition name="" to="Review Order"></transition> </node>
- 以下のコードを使用して、サービス呼び出しとともに JBoss Business Process Manager コンテキスト変数を送信します。(以下の例では、 entireOrderAsXML という名前の変数がメッセージ本文のデフォルト位置に設定される)があります。
<bpmToEsbVars> <mapping bpm="entireOrderAsXML" esb="BODY_CONTENT" /> </bpmToEsbVars>
これにより、 entireOrderAsXML 変数の XML ベースの内容がメッセージの本文で終了します。これで、IntakeService
は、パイプラインの各アクションを通過させることにより、メッセージにアクセスし、処理できるようになりました。最後のアクションに達すると、 replyTo プロパティーが確認され、メッセージはJBpmCallBack
サービスに送信されます。これにより、JBoss Business Process Manager にコールバックし、Intake Order
ノードから次のノードへの移行(この場合は 順の確認 の確認
)に通知します。 - 次に、メッセージからノードにいくつかの変数を送信します。両方のコンテキストがオブジェクトのクラスをロードできる限り、オブジェクト全体を送信できます。JBoss Business Process Manager にマップバックする機能を維持するには、 esbToEsbVars 要素を追加します。
<node name="Intake Order"> <action name="esbAction" class= "org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler"> <esbCategoryName>BPM_Orchestration4</esbCategoryName> <esbServiceName>IntakeService</esbServiceName> <bpmToEsbVars> <mapping bpm="entireOrderAsXML" esb="BODY_CONTENT" /> </bpmToEsbVars> <esbToBpmVars> <mapping esb="body.entireOrderAsXML" bpm="entireOrderAsXML"/> <mapping esb="body.orderHeader" bpm="entireOrderAsObject" /> <mapping esb="body.customer" bpm="entireCustomerAsObject" /> <mapping esb="body.order_orderId" bpm="order_orderid" /> <mapping esb="body.order_totalAmount" bpm="order_totalamount" /> <mapping esb="body.order_orderPriority" bpm="order_priority" /> <mapping esb="body.customer_firstName" bpm="customer_firstName" /> <mapping esb="body.customer_lastName" bpm="customer_lastName" /> <mapping esb="body.customer_status" bpm="customer_status" /> </esbToBpmVars> </action> <transition name="" to="Review Order"></transition> </node>
このサービスが返されると、以下の変数が JBoss Business Process Manager のコンテキストに保存されます。entireOrderAsXML
entireOrderAsObject
entireCustomerAsObject
また、デモの目的では、フラット化された変数もあります。order_orderid
order_totalAmount
order_priority
customer_firstName
customer_lastName
customer_status
- オーダープロセスを手動で確認する必要があります。
Order Review
というタスクでタスクノード
を追加します。これらのジョブは、列車を持つ誰かが実行する必要があります。 actor_iduser
XML フラグメントは以下のようになります。<task-node name="Review Order"> <task name="Order Review"> <assignment actor-id="user"></assignment> <controller> <variable name="customer_firstName" access="read,write,required"></variable> <variable name="customer_lastName" access="read,write,required"> <variable name="customer_status" access="read"></variable> <variable name="order_totalamount" access="read"></variable> <variable name="order_priority" access="read"></variable> <variable name="order_orderid" access="read"></variable> <variable name="order_discount" access="read"></variable> <variable name="entireOrderAsXML" access="read"></variable> </controller> </task> <transition name="" to="Calculate Discount"></transition> </task-node>
- XHTML データ形式を作成して、これらの変数を jbpm-console の形式で表示します。注記詳細は、 bpm_orchestration4 クイックスタートの
Review_Order.xhtml
ファイルを参照してください。 - これらの設定を form
.xml ファイルに追加して、このデータ形式を task node にリンクします。
<forms> <form task="Order Review" form="Review_Order.xhtml"/> <form task="Discount Review" form="Review_Order.xhtml"/> </forms>
- この場合、2 つのタスクノードに同じ形式が適用されます。以下のサンプルコードに示されるように、Review Order フォームの変数への参照があります。(次に、JBoss Business Process Manager のコンテキストで設定される変数を参照します。)
<jbpm:datacell> <f:facet name="header"> <h:outputText value="customer_firstName"/> </f:facet> <h:inputText value="#{var['customer_firstName']}" /> </jbpm:datacell>
- プロセスが
Review Node
に到達すると、jBPM コンソールにログインし、Task をクリックしてアイテムのリストを表示できます。 - タスクをクリックして詳細を確認します。フォームが表示されます。その後、一部の値を更新できます。
- Save and Close をクリックして結論します。この時点で、プロセスは次のノードに移動します。
- これは
Calculate Discount
ノードです。繰り返しになりますが、このノードは、以下のような設定ファイルです。<node name="Calculate Discount"> <action name="esbAction" class=" org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler"> <esbCategoryName>BPM_Orchestration4</esbCategoryName> <esbServiceName>DiscountService</esbServiceName> <bpmToEsbVars> <mapping bpm="entireCustomerAsObject" esb="customer" /> <mapping bpm="entireOrderAsObject" esb="orderHeader" /> <mapping bpm="entireOrderAsXML" esb="BODY_CONTENT" /> </bpmToEsbVars> <esbToBpmVars> <mapping esb="order" bpm="entireOrderAsObject" /> <mapping esb="body.order_orderDiscount" bpm="order_discount" /> </esbToBpmVars> </action> <transition name="" to="Review Discount"></transition> </node>
サービスは、顧客
、orderHeader
、およびentireOrderAsXML
データを受け取ります。次に割引を計算します。応答は、body.order_orderDiscount
の値を order_-discount という JBoss Business Process Manager コンテキスト変数にマッピングします。プロセスが通知され、Review Discount
ノードに移行するように指示します。 - 値が 8.5 に設定されている割引を確認します。Save and Close をクリックします。プロセスは
Ship It
ノードに移動します。このノードも、Mastive サービスです。Ship It
サービスの完了前に注文プロセスを回避するには、以下のようにEsbNotifier
アクションハンドラーを送信移行にアタッチしてこれを使用します。<node name="ShipIt"> <transition name="ProcessingComplete" to="end"> <action name="ShipItAction" class= "org.jboss.soa.esb.services.jbpm.actionhandlers.EsbNotifier"> <esbCategoryName>BPM_Orchestration4</esbCategoryName> <esbServiceName>ShippingService</esbServiceName> <bpmToEsbVars> <mapping bpm="entireCustomerAsObject" esb="customer" /> <mapping bpm="entireOrderAsObject" esb="orderHeader" /> <mapping bpm="entireOrderAsXML" esb="entireOrderAsXML" /> </bpmToEsbVars> </action> </transition> </node>
ShippingService
に通知した後、オーダープロセスは終了状態に移行し、終了します。(
ShippingService
自体は終了している可能性があります。)bpm_orchestration4
のクイックスタートでは、 JBoss Rules エンジンを使用して、この順番が normal メソッドまたは express メソッドから同梱されるかどうかを決定します。
9.3. プロセス定義のデプロイ
processdefinition.xml
ファイルを作成したら、以下のいずれかを使用して JBoss Business Process Manager にデプロイできます。
- 統合開発環境
- ant
- jBPM コンソール
Review_Order.xhtml
forms.xml
gpd.xml
processdefinition.xml
processimage.jpg
PAR
はそれを jBPM のデータベースにアーカイブしてデプロイします。
.PAR
アーカイブに Java コードをデプロイしないことを推奨します。代わりに、.JAR
または .ESB
アーカイブのいずれかを使用してクラスをデプロイします。
9.4. デプロイメントのインスタンス化
- プロセス定義をデプロイしたら、新しいプロセスインスタンスを作成します。( StartProcessInstanceCommand を使用できることに注意してください)。このコマンドを使用すると、事前に設定された初期値でプロセスインスタンスを作成できます。
<service category="BPM_orchestration4_Starter_Service" name="Starter_Service" description="BPM Orchestration Sample 4: Use this service to start a process instance"> <listeners> </listeners> <actions> <action name="setup_key" class= "org.jboss.soa.esb.actions.scripting.GroovyActionProcessor"> <property name="script" value="/scripts/setup_key.groovy" /> </action> <action name="start_a_new_order_process" class= "org.jboss.soa.esb.services.jbpm.actions.BpmProcessor"> <property name="command" value="StartProcessInstanceCommand" /> <property name="process-definition-name" value="bpm4_ESBOrderProcess" /> <property name="key" value="body.businessKey" /> <property name="esbToBpmVars"> <mapping esb="BODY_CONTENT" bpm="entireOrderAsXML" /> </property> </action> </actions> </service>
- これで、新しいプロセスインスタンスが呼び出され、スクリプトを使用して起動します。jBPM キーは、受信順序の XML ファイルにより、 OrderId の値に設定されます。この XML は、その後
esbToBpmVars
マッピングを使用して jBPM コンテキストに入れられます。bpm_orchestration4
クイックスタートでは、XML はSeam DVD Store
から来、SampleOrder.xml
は以下のようになります。<Order orderId="2" orderDate="Wed Nov 15 13:45:28 EST 2006" statusCode="0" netAmount="59.97" totalAmount="64.92" tax="4.95"> <Customer userName="user1" firstName="Rex" lastName="Myers" state="SD"/> <OrderLines> <OrderLine position="1" quantity="1"> <Product productId="364" title="Gandhi" price="29.98"/> </OrderLine> <OrderLine position="2" quantity="1"> <Product productId="299" title="Lost Horizon" price="29.99"/> </OrderLine> </OrderLines> </Order>
注記Enterprise Service Bus および JBoss Business Process Manager デプロイメントは、hot として知られています。jBPM には特別な機能があり、プロセスデプロイメントがバージョン付けされます。新規作成されたプロセスインスタンスは最新バージョンを使用しますが、既存のプロセスインスタンスは、起動したプロセスデプロイメントを使用して終了で実行されます。
第10章 BPEL エンジンとの Service Registry の統合
10.1. BPEL エンジン
10.2. Business Process Execution Language (BPEL)
10.3. BPEL と Service Registry
10.4. BPEL-Service レジストリー統合の有効化
手順10.1 タスク
- インテグレーションはデフォルトで有効になっています。これを確認するには、
vi SOA_ROOT/jboss-as/server/PROFILE/deploy/riftsaw.sar/bpel.properties.xml
を開き、がbpel.uddi.registration=true
に設定されていることを確認します。
10.5. パートナーリンク
10.6. パートナーリンクチャンネル
10.7. esb.juddi.client.xml
SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb.sar/esb.juddi.client.xml
ファイルは、jUDDI Service Registry のクライアント設定ファイルです。
10.8. BPEL.properties 設定設定
表10.1 bpel.properties ファイルの UDDI 関連のプロパティー
attribute | タイプ(デフォルト) | description |
---|---|---|
bpel.uddi.registration | boolean (true) | 'false' に設定すると、UDDI 統合はオフになります。RiftSaw インストールプロセスでは、jbossesb-registry.sar に jUDDI v3 レジストリーが含まれることが検出されると、この値を true に設定します。他のすべての場合は、自動的に false に設定されます。 |
bpel.webservice.secure | boolean (false) | UDDI 登録プロセスでは、登録している BPEL サービスの BindingTemplate に WSDL AccessPoint を登録します。BPEL サーバーは WS スタック上のサービス WSDL エンドポイントを公開します(現在、Red Hat は JBossWS および CXF をサポートします)。web サービススタックがセキュアなプロトコル(https など)を使用するように設定されている場合は、この設定を true に切り替える必要があります。(この設定は登録プロセス中にのみ使用されることに注意してください。) |
bpel.uddi.client.impl | String (org.jboss.soa.bpel.uddi.UDDIRegistrationImpl) | これは、org.jboss.soa.bpel.runtime.engine.ode.UDDIRegistration インターフェイスを実装するクラスの名前です。 |
bpel.uddi.clerk.config | 文字列(デフォルトでは使用されません) | これは、bpel.uddi.client.xml 設定ファイルへのパスを定義します。riftsaw.sar/META-INF/riftsaw.uddi.xml を使用する場合は、コメントアウトしたままにすることができます。この場合、bpel.uddi.clerk.manager を定義する必要があります。 |
bpel.uddi.clerk.manager | string (riftsaw-manager) | これは、riftsaw.uddi.xml がコメントアウトされている場合に使用される ClerkManager の名前を定義します。この値は、esb.juddi.client.xml のマネージャーの名前に対応している必要があります。bpel.uddi.clerk.config が定義されている場合、bpel.uddi.clerk.manager の設定は無視されます。 |
bpel.uddi.clerk | string (BPEL_clerk) | 使用する clerk の名前を定義します。この値は、riftsaw.uddi.xml の clerk の名前に対応している必要があります。(デフォルトでは BPEL_clerk に設定されています。) |
bpel.uddi.lookup | boolean (true) | これを true に設定すると、パートナーチャネルの作成プロセスは UDDI の serviceName によるルックアップを実行し、WSDL エンドポイントが取得されます。このプロセスにより、BPEL プロセスデプロイメントでパートナーリンク WSDL ファイルを更新することなく、サーバーファーム内のプロセスデプロイメントを簡単に移動できます。複数のエンドポイント(BindingTemplate)が見つかった場合、ServiceLocator が使用するデフォルトのポリシーは PolicyLocalFirst になります。各 partnerLink に初期パートナーリンク WSDL ファイルをデプロイする必要があることに注意してください。 |
bpel.properties
ファイルに指定されます。
10.9. clerk
org.apache.juddi.v3.client.config.UDDIClerk
)は、Service Registry にサービスのエンドポイントを登録します。
10.10. サービス登録時に Clerk が使用するプロパティーを設定します。
手順10.2 タスク
- テキストエディターで
esb.juddi.client.xml
ファイルを開きます。vi SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb.sar/esb.juddi.client.xml - 設定を構成します。以下に例を示します。
</nodes> <clerks registerOnStartup="false"> <clerk name="SOAExample" node="default" publisher="root" password="root"/> </clerks> </manager> </uddi>
- ファイルを保存して終了します。
- ファイルの別のコピーをここに配置します(ファイルは常に対応する必要があります: SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/juddi_custom_install_data/)。
- ファイルを保存して終了します。
10.11. Service Registry Clerk のデフォルト設定
表10.2 デフォルトの設定
プロパティー | 値 |
---|---|
keyDomain | esb.jboss.org |
businessKey | redhat-jboss |
serviceDescription | BPEL Service deployed by Riftsaw |
bindingDescription | BPEL Endpoint deployed by Riftsaw |
SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/esb.juddi.xml
ファイルには、 juddi.seed.always というプロパティーが含まれており、これは false に設定されます。つまり、サーバーの起動時に常に root シードデータを読み込もうとします。
10.12. UDDI 登録
10.13. UDDI End-Point Look-Up
パート IV. メッセージのルーティング
第11章 ルールを使用したコンテンツベースのルーティングの実行
11.1. Content-Based Router
11.2. トレーニングによるコンテンツベースのルーティングの概要
11.3. XPath を使用したコンテンツベースのルーティングのインラインルールの定義
手順11.1 タスク
jboss-esb.xml
を開き、 cbrAlias プロパティーをXPath
に設定します。- 以下に示すように、(コンテナー宛先プロパティーにある)route-to 設定でルーティングルールを定義します。
<action class="org.jboss.soa.esb.actions.ContentBasedRouter" name="ContentBasedRouter"> <property name="cbrAlias" value="XPath"/> <property name="destinations"> <route-to service-category="BlueTeam" service-name="GoBlue" expression="/Order[@statusCode='0']" /> <route-to service-category="RedTeam" service-name="GoRed" expression="/Order[@statusCode='1']" /> <route-to service-category="GreenTeam" service-name="GoGreen" expression="/Order[@statusCode='2']" /> </property> </action>
11.4. XPath を使用したコンテンツベースのルーティングの外部ルールの定義
手順11.2 タスク
jboss-esb.xml
ファイルを開き、 cbrAlias プロパティーをXPath
に設定します。- .properties ファイルでルーティング式を定義します。プロパティーキーが宛先名と相関し、プロパティーの値がこの宛先にルーティングするための XPath 式であることを確認します。
- コンテナー宛先プロパティーを使用して、 route-to 設定でルーティングルールを定義します。destination-name 属性は、以下に示すように外部 .properties ファイルで定義されている XPath ルールキーを参照します。
<action class="org.jboss.soa.esb.actions.ContentBasedRouter" name="ContentBasedRouter"> <property name="cbrAlias" value="XPath"/> <property name="ruleSet" value="/rules/xpath-rules.properties"/> <property name="ruleReload" value="true"/> <property name="destinations"> <route-to destination-name="blue" service-category="BlueTeam" service-name="GoBlue" /> <route-to destination-name="red" service-category="RedTeam" service-name="GoRed" /> <route-to destination-name="green" service-category="GreenTeam" service-name="GoGreen" /> </property> </action>
11.5. コンテンツベースのルーティングの XPath ルール
blue=/Order[@statusCode='0'] red=/Order[@statusCode='1'] green=/Order[@statusCode='2']
11.6. Namespace
11.7. XML 名前空間接頭辞から URI へのマッピングの定義
- 以下のように、XML 名前空間の接頭辞から URI へのマッピングを定義します。(これは、外部ルール定義とインラインルール定義の両方に適用されます。)
<action class="org.jboss.soa.esb.actions.ContentBasedRouter" name="ContentBasedRouter"> <property name="cbrAlias" value="XPath"/> <property name="namespaces"> <route-to prefix="ord" uri="http://www.acne.com/order" /> </property> <property name="destinations"> <route-to service-category="BlueTeam" service-name="GoBlue" expression="/ord:Order[@statusCode='0']" /> <route-to service-category="RedTeam" service-name="GoRed" expression="/ord:Order[@statusCode='1']" /> <route-to service-category="GreenTeam" service-name="GoGreen" expression="/ord:Order[@statusCode='2']" /> </property> </action>
11.8. Regex を使用したコンテンツベースのルーティングのインラインルールの定義
jboss-esb.xml
ファイルを開き、cbrAlias プロパティーをRegex
に設定します。route-to
設定でルーティングルールを定義します。(これらはコンテナーの宛先プロパティーにあります。)<action class="org.jboss.soa.esb.actions.ContentBasedRouter" name="ContentBasedRouter"> <property name="cbrAlias" value="Regex"/> <property name="destinations"> <route-to service-category="BlueTeam" service-name="GoBlue" expression="#*111#*" /> <route-to service-category="RedTeam" service-name="GoRed" expression="#*222#*" /> <route-to service-category="GreenTeam" service-name="GoGreen" expression="#*333#*" /> </property> </action>
11.9. Regex を使用したコンテンツベースのルーティングの外部ルールの定義
jboss-esb.xml
ファイルを開き、cbrAlias プロパティーを Regex に設定します。- .properties ファイルでルーティング式を定義します。プロパティーキーは宛先名であり、プロパティーの値は宛先にルーティングするための Regex 式です。
- .properties ファイルで定義されているように destination-name 属性を Regex ルールキーに設定して、
route-to
設定(コンテナー宛先プロパティーにある)でルーティングルールを定義します。<action class="org.jboss.soa.esb.actions.ContentBasedRouter" name="ContentBasedRouter"> <property name="cbrAlias" value="XPath"/> <property name="ruleSet" value="/rules/regex-rules.properties"/> <property name="ruleReload" value="true"/> <property name="destinations"> <route-to destination-name="blue" service-category="BlueTeam" service-name="GoBlue" /> <route-to destination-name="red" service-category="RedTeam" service-name="GoRed" /> <route-to destination-name="green" service-category="GreenTeam" service-name="GoGreen" /> </property> </action>
XPath ルールは .properties ファイルにあり、以下の形式で表現されます。blue=#*111#* red=#*222#* green=#*333#*
11.10. JBoss Rules Engine を使用したコンテンツベースのルーティング
action classes
を通じてこのエンジンと統合されます。
JBoss Rules
エンジンの DRL 言語で記述されたルーティングルールセット (あるいは、必要に応じて DSL 言語を使用することもできます)。- メッセージの内容。これは、JBoss Rules エンジンに送られるデータです (XML 形式またはメッセージに埋め込まれたオブジェクトとして送られます)。
- 宛先 (エンジンから出力される結果情報から導出されます)。
コンテンツベースのルーター
に送信されると、ルールセットがそのコンテンツを評価し、一連のサービス宛先を返します。
- org.jboss.soa.esb.actions.ContentBasedRouter: このアクションクラスは コンテンツベースのルーティング パターンを実装します。メッセージの内容と、その内容を評価するルールセットに基づいて、メッセージを 1 つ以上の宛先サービスにルーティングします。特定のルールセットまたはメッセージの組み合わせに一致する宛先がない場合には、コンテンツベースルーターは例外を出力します。このアクションはそれ以降のパイプライン処理を終了させるため、常にパイプラインの最後に配置してください。
- org.jboss.soa.esb.actions.ContentBasedWiretap: これは WireTap パターンを実装します。
WireTap
は、メッセージのコピーを制御チャネルに送信するエンタープライズ統合パターンです。WireTap
の機能は標準のコンテンツベースのルーターと同じですが、パイプラインは終了されません。これは後者の特徴であり、wire-tap として使用するのに適した特徴であるため、その名前になります。詳細は、 を参照してください。 - org.jboss.soa.esb.actions.MessageFilter: メッセージフィルター パターンを実装します。メッセージフィルターパターンは、特定のコンテンツ要件を満たしていない場合に、メッセージを削除できる場合に使用されます。つまり、ルールセットが宛先と一致しない場合は例外を出力しないことを除いて、コンテンツベースのルーターと同じように機能します。詳細は、を参照してください http://www.eaipatterns.com/Filter.html。
11.11. XPath ドメイン固有の言語
- まず、
XPathLanguage.dsl
ファイルで式を定義し、以下のコードを使用してルールセットでそれを参照します。expander XPathLanguage.dsl
- XPath 言語は、メッセージが
JBOSS_XML
にあり、以下の項目が定義されていることを確認します。- xpathMatch<element> : この名前は、この名前による要素が一致した場合に
true
を生成します。 - xpathEquals<element& gt; , <value > : 要素が検出され、その値が等しい場合は
true
になります。 - xpathGreaterThan<element& gt; , < value > : 要素が検出され、その値が値よりも大きい場合は、
true
になります。 - xpathLessThan<element& gt; , < value > : これは、要素が検出され、その値が小さい場合に
true
を生成します。
注記fun_cbr
クイックスタートは XPath の使用を示しています。注記完全に異なるドメイン固有の言語を定義できます。
11.12. XPath と名前空間
prefix=uri,prefix=uri
の形式でコンマ区切りリストで指定します。
XPath 名前空間対応ステートメント:
- xpathMatch expr "<expression>" use namespaces "<namespaces>"
- xpathEquals expr "<expression>", "<value>" use namespaces "<namespaces>"
- xpathGreaterThan expr "<expression>", "<value>" use namespaces "<namespaces>"
- xpathLowerThan expr "<expression>", "<value>" use namespaces "<namespaces>"
expr
を付けて、XPath 以外の対応するステートメントと競合しないようにしてください。
11.13. コンテンツベースルーティングの設定
- XPath ステートメントは、 jboss-esb.xml ファイルに保存されている設定を介して接続されます。以下の
サービス設定
は、サービス設定のフラグメントの例です。(この例では、サービスは Java Message Service キューをリッスンしています。)<service> category="MessageRouting" name="YourServiceName" description="CBR Service"> <listeners> <jms-listener name="CBR-Listener" busidref="QueueA" maxThreads="1"> </jms-listener> </listeners> <actions> <action class="org.jboss.soa.esb.actions.ContentBasedRouter" name="YourActionName"> <property name="ruleSet" value="JBossESBRules.drl"/> <property name="ruleReload" value="true"/> <property name="destinations"> <route-to destination-name="xml-destination" service-category="category01" service-name="jbossesbtest1" /> <route-to destination-name="serialized-destination" service-category="category02" service-name="jbossesbtest2" /> </property> <property name="object-paths"> <object-path esb="body.test1" /> <object-path esb="body.test2" /> </property> </action> </actions> </service>
各メッセージはContentBasedRouter
アクションクラスに渡され、特定のルールセットで読み込まれます。その後、メッセージを JBoss Rules エンジンのワーキングメモリーに送信し、ルールを実行し、宛先リストを取得してサービスにメッセージのコピーを送信します。この場合、2 つの destination-xml-destination
とserialized-destination
に一致するJBossESBRules.drl
ルールセットを使用します。これらの名前は、route-to
セクションの実際のサービスのものにマッピングされます。
11.14. コンテンツベースルーティングアクションタグの属性
表11.1 コンテンツベースルーティングアクションタグの属性
属性 | Description |
---|---|
Class | アクションクラス。これは org.jboss.soa.esb.actions.ContentBasedRouter 、org.jboss.soa.esb.actions.ContentBasedWiretap または org.jboss.soa.esb.actions.MessageFilter のいずれかです。 |
名前 | カスタムアクション名。 |
11.15. コンテンツベースのルーティングアクション設定プロパティー
表11.2 コンテンツベースのルーティングアクション設定プロパティー
プロパティー | Description |
---|---|
ruleSet | これは、 JBoss Rules エンジンのruleSet が含まれるファイルの名前で、メッセージコンテンツの評価に使用されるルールセットです。(コンテンツベースのルーティングインスタンスごとに 1 つの ruleSet のみを指定できます。) |
ruleLanguage | これは、ルールセットの評価に使用されるドメイン固有言語の定義を含むファイルへのオプションの参照です。 |
ruleReload | これは任意のプロパティーで、ルールセットのホット再デプロイを有効にするために true に設定できます。この機能は、ルール処理にオーバーヘッドが発生することに注意してください。また、ルールが存在する .esb アーカイブが再デプロイされると、ルールが再読み込みされることに注意してください。 |
stateful | これは、呼び出し間でファクトが記憶されるステートフルセッションを使用するように RuleService に指示する任意のプロパティーです。このトピックに関する詳細は、ステートフルルールのセクションを参照してください。 |
宛先 | これは route-to プロパティーのセットであり、それぞれには、レジストリーで参照される Service カテゴリーおよび名前と共に宛先の論理名が含まれます。論理名は、ルールセットで使用する必要がある名前です。 |
object-paths | これは、メッセージ オブジェクトを ワーキングメモリー に渡す任意のプロパティーです。 |
ruleAuditType | これは、JBoss Rules エンジンが監査ロギングを実行できるようにする任意のプロパティーです。ログは JBoss Developer Studio プラグインに読み取り、検査できます。有効な値は CONSOLE、FILE、および THREADED_FILE です。デフォルトでは、監査ロギングは実行されません。 |
ruleAuditFile | これは、監査ロギングのファイルパスを定義できるようにする任意のプロパティーです。FILE または THREADED_FILE ruleAuditType にのみ適用されることに注意してください。デフォルトは event です。JBoss Rules Engine は、.log を追加することに注意してください。このファイルのデフォルトの場所は. - 現在の作業ディレクトリーです(JBoss は bin/ ディレクトリーにあります)。 |
ruleAuditInterval | これは任意のプロパティーで、監査イベントを監査ログにフラッシュする頻度を定義できます。これは THREADED_FILE ruleAuditType にのみ適用されることに注意してください。デフォルトは 1000 (ミリ秒)です。 |
11.16. 事前コンパイル済みルールパッケージの使用
KnowledgeAgent
は、JBoss Rules 5.0 API に組み込まれたコンポーネントです。ナレッジストアを使用するために追加のコンポーネントは必要ありません。JBoss Enterprise BRMS Platform を使用している場合は、アプリケーションにクラスパスに drools-core 依存関係のみを含める必要があります(drools および mvel JAR のみ)。その他のルール固有の依存関係はありません。
KnowledgeAgent
を使用します。これらのパッケージは、ローカルファイルシステムまたはリモートの場所(URL 経由でアクセス)に置くことができます。BRMS Platform (または ant タスク)のパッケージにルールを作成したら、ターゲットアプリケーションでエージェントを使用する準備が整います。
KnowledgeAgent kagent = KnowledgeAgentFactory.newKnowledgeAgent( "MyAgent" ); kagent.applyChangeSet( ResourceFactory.newUrlResource( url ) ); KnowledgeBase kbase = kagent.getKnowledgeBase();
KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase(); KnowledgeAgentConfiguration kaconf = KnowledgeAgentFactory.newKnowledgeAgentConfiguration(); kaconf.setProperty( "drools.agent.scanDirectories", "false" ); // we don't scan directories, only files KnowledgeAgent kagent = KnowledgeAgentFactory.newKnowledgeAgent( "test agent", kaconf ); // resource to the change-set xml for the resources to add kagent.applyChangeSet( ResourceFactory.newUrlResource( url ) );
change-set.xml
の例です。
<change-set xmlns='http://drools.org/drools-5.0/change-set'"; xmlns:xs='http://www.w3.org/2001/XMLSchema-instance' xs:schemaLocation='http://drools.org/drools-5.0/change-set drools-change-set-5.0.xsd' > <add> <resource source='http://localhost:9000/TEST.pkg' type='PKG' /> </add> </change-set>
ResourceFactory.getResourceChangeNotifierService().start(); ResourceFactory.getResourceChangeScannerService().start();
BRMS UI
のデプロイメント画面には、パッケージへの URL とダウンロードが含まれます。このパッケージを指定するには、change-set.xml
ファイルに含めるパッケージ URI の URL が必要です。正確なバージョンを指定します。この場合はスナップショットになります。各スナップショットには独自の URL があります。最新バージョンが必要な場合は、NewSnapshot
を LATEST
に置き換えます。
(PKG)
をダウンロードすることもできます。このファイルをディレクトリーに置き、KnowledgeAgent
の file
または dir
機能を使用します。これにより、更新については JBoss Enterprise BRMS Platform
サーバーへ自動的に問い合わせますが、一部のシナリオでは望ましくない場合があります。
11.17. ビジネスルールの実行
11.18. 独自のメッセージングプロバイダーの使用
jboss-esb.xml
ファイルの対応するセクションを変更して参照します。以下に例を示します。
<providers> <jms-provider name="CallbackQueue-JMS-Provider" connection-factory="ConnectionFactory"> <jms-bus busid="jBPMCallbackBus"> <jms-message-filter dest-type="QUEUE" dest-name="queue/CallbackQueue" /> </jms-bus> </jms-provider> </providers>
パート V. Message Transformation
第12章 Smook を使用した変換
12.1. Smooks
12.2. Smook の使用
SmooksAction
コンポーネントを使用して、Meoks アクションパイプラインにプラグインします。注記samples/quick starts
ディレクトリーで変換を示すクイックスタートが多数あります。(これらのクイックスタートの各変換の名前には、transform_
という単語が接頭辞として付けられます。)
12.3. XSLT を使用したメッセージ変換の概要
12.4. ActionProcessor データを使用したメッセージ変換の概要
org.jboss.soa.esb.actions.ActionPipelineProcessor
)を使用してカスタムソリューションを実装します。
12.5. プロセス変換設定
<actions mep="OneWay"> <action class="org.jboss.soa.esb.actions.SystemPrintln" name="print-before"> <property name="message" value="[transform_XML2XML_simple] Message before transformation"> </property> <action class="org.jboss.soa.esb.smooks.SmooksAction" name="simple-transform"> <property name="smooksConfig" value="/smooks-res.xml"> <property name="reportPath" value="/tmp/smooks_report.html"> </property> <action class="org.jboss.soa.esb.actions.SystemPrintln" name="print-after"> <property name="message" value="[transform_XML2XML_simple] Message after transformation"> </property>
- 1 行目
- MEP は、メッセージ交換パターン を表します。この例では、リクエスターはメッセージを送信してサービスを呼び出します。
- 2 - 4 行目
- この設定により、変換前後にメッセージをサーバーログに書き込むことができます。
- 5 行目
- これは、SmooksAction が指定されている場所です。
- 6 行目
- これは XLST が指定されている場所です。
- 7 行目
- 変換の rep[ort)を生成します。
パート VI. メッセージの永続性
第13章 メッセージの永続性
13.1. メッセージストア
13.2. メッセージストアインターフェイス
public interface MessageStore { public MessageURIGenerator getMessageURIGenerator(); public URI addMessage (Message message, String classification) throws MessageStoreException; public Message getMessage (URI uid) throws MessageStoreException; public void setUndelivered(URI uid) throws MessageStoreException; public void setDelivered(URI uid) throws MessageStoreException; public Map$lt;URI, Message> getUndeliveredMessages(String classification) throws MessageStoreException; public Map$lt;URI, Message> getAllMessages(String classification) throws MessageStoreException; public Message getMessage (URI uid, String classification) throws MessageStoreException; public int removeMessage (URI uid, String classification) throws MessageStoreException; }
13.3. カスタムメッセージストアの実装時に注意すべき要因
- 実装では、
addMessage
を使用してメッセージ分類スキームを取得できます。分類が定義されていない場合は、MessageStore
の個別の実装によってメッセージの保存方法を決定します。さらに、分類はガイドのみで、必要に応じて実装はこのフィールドを無視できます。 MessageStore
が個別のメッセージに何らかの 同時実行制御 を課すかどうかは実装次第です。したがって、常にremoveMessage
操作を使用してください。- setUndelivered コマンドおよび setDelivered コマンドまたはその他の関連操作は使用しないでください。これは、
MessageStore
インターフェイスが監査証跡および再配信機能の両方をサポートするためです。 org.jboss.internal.soa.esb.persistence.format.db.DBMessageStoreImpl
クラスは、メッセージストアのデフォルト実装を提供します。この実装のメソッドは、DBConnectionManager
と呼ばれる プールされたデータベースマネージャー を介して必要なデータベース接続を設定します。MessageActionGuide
およびMessagePersister
アクションは、メッセージストアの実装を上書きします。- その MessageStore インターフェイスは現在トランザクションをサポートしていません。グローバルトランザクションのスコープ内でメッセージストアを使用することは、認識されないことになります。これは、各
MessageStore
の更新または読み取りが個別に実施されることを意味します。
13.4. メッセージストアの設定
手順13.1 タスク
- グローバル設定ファイルをテキストエディターで開きます: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployers/jbossesb-properties.xml
- セクションまでスクロールダウンし、設定に合わせて編集します。
<properties name="dbstore"> <!-- connection manager type --> <property name="org.jboss.soa.esb.persistence.db.conn.manager" value= "org.jboss.internal.soa.esb.persistence.manager.StandaloneConnectionManager"/> <!-- this property is only used for the j2ee connection manager --> <property name="org.jboss.soa.esb.persistence.db.datasource.name" value="java:/JBossesbDS"/> <!-- standalone connection pooling settings --> <!-- mysql <property name="org.jboss.soa.esb.persistence.db.connection.url" value="jdbc:mysql://localhost/jbossesb"/> <property name="org.jboss.soa.esb.persistence.db.jdbc.driver" value="com.mysql.jdbc.Driver"/> <property name="org.jboss.soa.esb.persistence.db.user" value="kstam"/> --> <!-- postgres <property name="org.jboss.soa.esb.persistence.db.connection.url" value="jdbc:postgresql://localhost/jbossesb"/> <property name="org.jboss.soa.esb.persistence.db.jdbc.driver" value="org.postgresql.Driver"/> <property name="org.jboss.soa.esb.persistence.db.user" value="postgres"/> <property name="org.jboss.soa.esb.persistence.db.pwd" value="postgres"/> --> <!-- hsqldb --> <property name="org.jboss.soa.esb.persistence.db.connection.url" value="jdbc:hsqldb:hsql://localhost:9001/jbossesb"/> <property name="org.jboss.soa.esb.persistence.db.jdbc.driver" value="org.hsqldb.jdbcDriver"/> <property name="org.jboss.soa.esb.persistence.db.user" value="sa"/> <property name="org.jboss.soa.esb.persistence.db.pwd" value=""/> <property name="org.jboss.soa.esb.persistence.db.pool.initial.size" value="2"/> <property name="org.jboss.soa.esb.persistence.db.pool.min.size" value="2"/> <property name="org.jboss.soa.esb.persistence.db.pool.max.size" value="5"/> <!--table managed by pool to test for valid connections created by pool automatically --> <property name="org.jboss.soa.esb.persistence.db.pool.test.table" value="pooltest"/> <property name="org.jboss.soa.esb.persistence.db.pool.timeout.millis" value="5000"/> </properties>
注記required database スキーマのスクリプトはSOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb.esb/message-store-sql/DB_TYPE/create_database.sql
ファイルにあります。 - グローバル設定ファイルで、データベース接続マネージャーを設定します。
<!-- connection manager type --> <property name="org.jboss.soa.esb.persistence.db.conn.manager" value="org.jboss.internal.soa.esb.persistence.format.db.Standalone ConnectionManager"/> <!-- property name="org.jboss.soa.esb.persistence.db.conn.manager" value="org.jboss.soa.esb.persistence.manager.J2eeConnectionManager"/ --> <!-- this property is only used for the j2ee connection manager --> <property name="org.jboss.soa.esb.persistence.db.datasource.name" value="java:/JBossesbDS"/>
注記スタンドアロンマネージャーは C3PO を使用して J2eeConnectionManager の最悪の接続プールロジックを管理します。JBoss Application Server などのコンテナーに Enterprise Service Bus エンドポイントをデプロイする場合は、後者を使用します。 - ファイルを保存して終了します。
- または、
org.jboss.internal.soa.esb.persistence.manager.ConnectionManager
インターフェイスを実装し、新しいクラスの名前を指定してProperties
ファイルを更新して、カスタム接続マネージャーをプラグインすることもできます。
13.5. create_database.sql
SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb.esb/message-store-sql/DB_TYPE/create_database.sql
ファイルにはデータベーススキーマのスクリプトが含まれます。
13.6. create_database.sql Settings
create_database.sql
ファイルの構造を示しています。
CREATE TABLE message ( uuid varchar(128) NOT NULL, type varchar(128) NOT NULL, message text(4000) NOT NULL, delivered varchar(10) NOT NULL, classification varchar(10), PRIMARY KEY (`uuid`) );
- UUID 列は、メッセージの一意のキーを保存するために使用されます。このキーは、標準の統一されたリソース識別子の形式を取ります。
- メッセージキーは以下のようになります。
urn:jboss:esb:message:UID: + UUID.randomUUID()_
注記この構文では、UUID の乱数ジェネレーターを使用します。 - type は保存されたメッセージのものと同じになります。JBoss Enterprise SOA Platform には、それぞれ JBOSS_XML と JAVA_SERIALIZED の 2 つの異なるバージョンの type が同梱されています。
- message 列には、実際のメッセージ自体の内容が含まれます。
- 提供されたデータベースメッセージストア実装は、事前設定されたデータベースへの接続を呼び出すことで機能します。(スタンドアロン接続マネージャーと JNDI データソースの使用にともに、製品の一部としても提供されます。)
- データベースプールの事前提供済み接続マネージャーは、
org.jboss.soa.esb.persistence.manager.StandaloneConnectionManager
とorg.jboss.soa.esb.persistence.manager.J2eeConnectionManager
の 2 つです。
13.7. C3PO
SOA_ROOT/jboss-as/lib
ディレクトリーにあります。
13.8. J2eeConnectionManager
13.9. JmsConnectionPool
パート VII. 管理の変更
第14章 ホットデプロイメント
14.1. ホットデプロイメント
14.2. ホットデプロイメントと jbossesb.sar
- タイムスタンプが変更されます (アーカイブが圧縮されている場合)。
META-INF/jboss-service.xml
ファイルのタイムスタンプが変更されます (アーカイブがデプロイメント形式の場合)。
14.3. ホットデプロイメントと ESB アーカイブ
*.esb
アーカイブは、次の場合に自動的に再デプロイメントされます。
- アーカイブのタイムスタンプが変更されます (アーカイブが圧縮されている場合)。
META-INF/jboss-esb.xml
ファイルのタイムスタンプが変更されます (アーカイブがデプロイメント形式の場合)。
第15章 バージョン管理
15.1. ルールファイルの再デプロイ
手順15.1 タスク
- .DRL または .DSL ファイルを再デプロイするには、jbrules.esb ディレクトリーを
SOA_ROOT/jboss-as/server/PROFILE/deploy
にコピーして再デプロイします。 - または、Action Configuration の ruleReload 機能を有効にすることもできます。この機能を有効にした後、ルールファイルが変更されると、自動的に再ロードされます。
15.2. 変換ファイルの再デプロイ
手順15.2 タスク
- .ESB アーカイブを
SOA_ROOT/jboss-as/server/PROFILE/deploy
ディレクトリーにコピーして再デプロイします。 - または、Web ブラウザーを起動して、http://localhost:8080/admin-console Monitoring and Management Console にログインします。
- Java Message Service を介して通知メッセージを送信します。Smooks はこのイベントを処理し、自動的にリロードします。
15.3. ビジネスプロセス定義の再デプロイ
前提条件
- JBoss Developer Studio
手順15.3 タスク
- jBPM Eclipse プラグインを使用して、新しいバージョンのビジネスプロセス定義を jBPM データベースにデプロイします。注記新しいプロセスインスタンスのみがこの新しいバージョンを使用することに注意してください。既存のプロセスライフサイクルでは、以前の定義が引き続き使用されます。注記この手順はスタンドアロンモードでも機能することに注意してください。
15.4. スタンドアロンモードでの実行中にルールをリロードする
手順15.4 タスク
- ruleReload を実行します。
パート VIII. ルールサービス
第16章 ルールサービス
16.1. ルールサービス
16.2. ステートレスサービス
16.3. ステートフルルールセッション
true
に設定します。現在のセッションを継続するタイミングと、そのセッションを破棄するタイミングについて、ステートフルルールサービスに指示することができます。
16.4. ステートフルセッションセッションプロパティー
- 既存のステートフルセッションを続行するには、以下の 2 つのメッセージプロパティーを設定します。
message.getProperties().setProperty(“dispose”, false); message.getProperties().setProperty(“continue”, true);
- 最後にルールを実行する場合は、dispose を
true
に設定して、JBoss ルールのエンジンのワーキングメモリーをクリアします。message.getProperties().setProperty(“dispose”, true); message.getProperties().setProperty(“continue”, true);
注記ステートフルなルールセッションの使用に関する詳細は、business_ruleservice_stateful
クイックスタートを参照してください。
16.5. JBoss ルールでのルールサービスの使用
- ルールをアプリケーション環境に統合するのに必要なクライアントコードの量が大幅に削減されます。
- ルールは、アクションチェーンまたはオーケストレーションされたビジネスプロセス内からアクセスできます。
BusinessRulesProcessor
および DroolsRuleService
アクションクラスによって提供されます。後者は RuleService
インターフェイスも実装します。
BusinessRulesProcessor
クラスを使用すると、クラスパスからルールを読み込むことができます。これらのルールは、.drl
ファイルおよび .dsl
ファイル、および デシジョンテーブル ( .xls
形式)で定義されます。これらのファイルベースのルールは、主にプロトタイプをテストするために存在します。単一の BusinessRulesProcessor
アクションに複数のルールファイルを指定する方法はありません。より複雑なルールサービスには、 JBoss Rules KnowledgeAgent
を使用する必要があります。
RuleService
は KnowledgeAgent
を使用して、 Business Rules Management System またはローカルファイルシステムから ルールパッケージ にアクセスします。ルールパッケージには、以下を含むさまざまなソースからの数千のルールを含めることができます。
- JBoss Business Rules Management System
- インポートした
DRL
ファイル - ドメイン固有言語 (DSL)ファイル
- デシジョンテーブル
KnowledgeAgent
アプローチを使用することを推奨します。
ruleAgentProperties
ファイルの poll プロパティーを使用して実行されなくなりました。これで、esb.deployer/jbossesb-properties.xml
にある org.jboss.soa.esb.services.rules.resource.scanner.interval プロパティーを介してグローバルに設定できるようになりました。(デフォルト値は 60 です。) つまり、システムは 6 秒ごとにすべての KnowledgeAgents でリソースの変更をチェックします。
username=admin password=admin enableBasicAuthentication=true
16.6. action Chain
16.7. オーケストレーションされたビジネスプロセス
16.8. JBoss ルールおよび SOA Platform の統合
BusinessRulesProcessor
- アクションクラス。
- ルール
- JBoss Rules、DRL、DSL、デシジョンテーブル、または Business Rule Editor で書かれたルール。
- Enterprise Service Bus メッセージ
- これは、JBoss Rules Engine のワーキングメモリーに挿入されます。
- Enterprise Service Bus メッセージの内容
- これは、メッセージのファクトオブジェクトで設定され、JBoss Rules Engine に送信されます。
16.9. ルールセットの要件
- JBoss Enterprise SOA Platform でルールセットを作成する場合は 3 つの要件があります。以下のように、name および action クラス:
<action class="org.jboss.soa.esb.actions.BusinessRulesProcessor" name="OrderDiscountRuleService">
以下のいずれかも必要です。DRL
ファイル:<property name="ruleSet" value="drl/OrderDiscount.drl" />
DSL
またはDSLR
(ドメイン固有言語 )ファイル:<property name="ruleSet" value="dsl/approval.dslr" /> <property name="ruleLanguage" value="dsl/acme.dsl" />
- クラスパスの
decisionTable
<property name="decisionTable" value="PolicyPricing.xls" />
- クラスパス上のプロパティーファイル。これは、
ルールエージェントにルール
パッケージの検索方法を説明します。これを有効にするには、URL またはローカルファイルへのパスを指定します。<property name="ruleAgentProperties" value="brmsdeployedrules.properties" />
16.10. ルールセットの作成
- rule-set がためのメッセージをインポートしていることを確認します。テストするには、以下のコードを使用します。
import org.jboss.soa.esb.message.Message
- 次に、ルールセットが、宛先の一覧を作成する以下のグローバル変数を定義することを確認します。
global java.util.List destinations;
これで、メッセージは JBoss Rules エンジンのワーキングメモリーに送信されます。これで、通常のルールセットをコンテンツベースのルーティングに使用できるものに変換できます。これを行うには、MA メッセージのマッチングルールを評価し、サービス宛先名 の一覧を出力します。
16.11. ルールセットの例
<action class="org.jboss.soa.esb.actions.BusinessRulesProcessor" name="OrderDiscountRuleService"> <property name="ruleSet" value="drl/OrderDiscount.drl" /> <property name="ruleReload" value="true" /> <property name="object-paths"> <object-path esb="body.Order" /> </property> </action>
- ルールは DRL ファイルにあり、ステートフルモデルに従って実行されます。このシナリオでは、クライアントは複数のメッセージをルールサービスに送信できます。たとえば、最初のメッセージには customer オブジェクトが含まれ、後続のメッセージにはお客様の注文が含まれる可能性があります。メッセージを受信するたびに、ルールが実行されます。(クライアントは、ワーキングメモリーの内容を破棄するようにルールサービスに指示する最終メッセージにプロパティーを追加できます。)
- 単一の同期セッションインスタンスは、ステートフルセッションデプロイメントのすべての同時実行で共有されます。これにより、ステートフルモデルのユースケースの数が大幅に制限されます。複数のクライアント指向セッションサービスデプロイメントが必要な場合は、代わりに jBPM ソリューションまたは BPEL ソリューションの使用を検討してください。
- ステートフルセッションは 永続 的ではありません。
- ステートフルセッションは クラスター化 されていません。
<action class="org.jboss.soa.esb.actions.BusinessRulesProcessor" name="OrderDiscountMultipleRuleServiceStateful"> <property name="ruleSet" value="drl/OrderDiscountOnMultipleOrders.drl" /> <property name="ruleReload" value="false" /> <property name="stateful" value="true" > <property name="object-paths"> <object-path esb="body.Customer" /> <object-path esb="body.Order" /> </property> </action>
<action class="org.jboss.soa.esb.actions.BusinessRulesProcessor" name="OrderEventsRuleServiceStateful"> <property name="ruleSet" value="drl/OrderEvents.drl" /> <property name="ruleReload" value="false" /> <property name="stateful" value="true" > <property name="ruleFireMethod" value="FIRE_UNTIL_HALT" /> <property name="ruleAuditType" value="THREADED_FILE" /> <property name="ruleAuditFile" value="myaudit" /> <property name="ruleAuditInterval" value="1000" /> <property name="ruleClockType" value="REALTIME" /> <property name="ruleEventProcessingType" value="STREAM" /> <property name="ruleMultithreadEvaluation" value="false" /> <property name="ruleMaxThreads" value="1" /> <property name="object-paths"> <object-path esb="body.OrderStatus" entry-point="OrderStatusStream" /> <object-path esb="body.OrderInfo" entry-point="OrderInfoStream" /> </property> <property name="channels"> <!-- chan1 and chan2 are equivalent (but timeout only applies if async is false) --> <send-to channel-name="chan1" service-category="cat1" service-name="svc1" /> <send-to channel-name="chan2" service-category="cat1" service-name="svc1" channel-class="org.jboss.soa.esb.services.rules.ServiceChannel" async="true" timeout="30000" set-payload-location="org.jboss.soa.esb.message.defaultEntry" /> <!-- chan3 is a custom channel --> <send-to channel-name="chan3" channel-class="com.example.MyChannel" /> </property> </action>
<action class="org.jboss.soa.esb.actions.BusinessRulesProcessor" name="PolicyApprovalRuleService"> <property name="ruleSet" value="dsl/approval.dslr" /> <property name="ruleLanguage" value="dsl/acme.dsl" /> <property name="ruleReload" value="true" /> <property name="object-paths"> <object-path esb="body.Driver" /> <object-path esb="body.Policy" /> </property> </action>
<action class="org.jboss.soa.esb.actions.BusinessRulesProcessor" name="PolicyPricingRuleService"> <property name="decisionTable" value="decisionTable/PolicyPricing.xls" /> <property name="ruleReload" value="true" /> <property name="object-paths"> <object-path esb="body.Driver" /> <object-path esb="body.Policy" /> </property> </action>
<action class="org.jboss.soa.esb.actions.BusinessRulesProcessor" name="RuleAgentPolicyService"> <property name="ruleAgentProperties" value="ruleAgent/brmsdeployedrules.properties" /> <property name="object-paths"> <object-path esb="body.Driver" /> <object-path esb="body.Policy" /> </property> </action>
16.12. BusinessRulesProcessor アクション設定属性
表16.1 属性
属性 | Description |
---|---|
Class | アクションクラス |
名前 | カスタムアクション名 |
16.13. BusinessRulesProcessor アクション設定プロパティー
表16.2 BusinessRulesProcessor アクション設定プロパティー
プロパティー | Description |
---|---|
ruleSet |
コンテンツの評価に使用される
ruleSet を含むファイルへのオプションの参照。ルール サービス インスタンスごとに指定できる ruleSet は 1 つだけです。
|
ruleLanguage |
ドメイン固有言語の定義を含むファイルへのオプションの参照です。この定義は、ルールセットの評価に使用できます。
ruleSet の ファイルが dslr であることを確認します。
|
ruleReload | このオプションプロパティーを true に設定して、 ルールセットの ホット再デプロイメント を有効にします 。(この機能を有効にすると、ルール処理のオーバーヘッドが増加します。) .esb アーカイブが再デプロイされると、ルールは再読み込みされます。 |
decisionTable |
ルール固有のスプレッドシートの定義が含まれるファイルへの参照(任意)。
|
stateful |
このオプションプロパティーを
true に設定して、 ルールサービス が時間の経過とともに複数のメッセージを受信することを指定します。ルールは毎回再実行されます。
|
object-paths |
メッセージオブジェクトを JBoss ルールのワーキングメモリーに渡す任意のプロパティー。
|
ruleFireMethod |
ステートフルルール実行メソッドを定義する任意のプロパティー。有効な値は FIRE_ALL_RULES (デフォルト)および FIRE_UNTIL_HALT です(独自のスレッドを起動します)。複雑なイベント処理の "CEP" に便利です。)
|
ruleAuditType |
Drools が監査ロギングを実行できるようにする任意のプロパティー。ログは Drools Eclipse プラグインに読み取り、検査できます。有効な値は CONSOLE、FILE、および THREADED_FILE です。デフォルトでは、監査ロギングは実行されません。
|
ruleAuditFile |
監査ロギングのファイルパスを定義する任意のプロパティー。FILE または THREADED_FILE ruleAuditType にのみ適用されます。デフォルトは event です。JBoss Drools は、.log を追加することに注意してください。このファイルのデフォルトの場所は、現在の作業ディレクトリーにある.です(JBoss は bin/ ディレクトリーにあります)。
|
ruleAuditInterval |
監査イベントを監査ログにフラッシュする頻度を定義する任意のプロパティー。THREADED_FILE ruleAuditType にのみ適用されます。デフォルトは 1000 (ミリ秒)です。
|
ruleClockType |
JBoss Drools が使用するクロックを定義する任意のプロパティー。有効な値は REALTIME および PSEUDO です。デフォルトは REALTIME です。
|
ruleEventProcessingType |
Drools が使用するイベント処理オプションを定義する任意のプロパティー。有効な値は CLOUD または STREAM (CEP に役立ちます)です。デフォルトは CLOUD です。
|
ruleMultithreadEvaluation |
ナレッジベースのパーティション設定を有効にするかどうかを定義する任意のプロパティー。デフォルトは null で、Drools のデフォルト(false)に委譲します。
|
ruleMaxThreads |
ナレッジベースのパーティション設定に使用するスレッドの数を定義する任意のプロパティー。これは、ruleMultithreadEvaluation が true の場合にのみ使用されます。デフォルトは null で、JBoss ルールのデフォルトに委譲します。
|
channels |
ルールがオブジェクトを送信できるチャンネルを定義する任意のプロパティー。ExitPoint として知られているチャネルの概念。
|
16.14. オブジェクトパス
16.15. MVFLEX Expression Language (MVEL)
16.16. オブジェクトパスの使用
- object-paths プロパティーを設定して、これらのオブジェクトを 1 つの
Message Object Path
で抽出します。注記object-paths プロパティーを使用して、さらにオブジェクトツリーにドリルダウンできます。これを行うには、このプロパティーを設定して、これらのオブジェクトを MRG Message Object Path で抽出します。 - JBoss Rules エンジンは MVFLEX Expression Language (MVEL)を使用してオブジェクトを抽出します。パスは、以下の構文で禁止する必要があります。
location.objectname.[beanname].[beanname]...
重要java import ステートメントをルールセットにインポートするオブジェクトに追加するのを忘れないようにしてください。注記オブジェクトマッパーは コレクション全体をフラットにすることはできません。これを行う必要がある場合は、最初にメッセージで変換プロセスを実行します。これは、コレクションを登録解除するためです。
16.17. オブジェクトパスのプロパティー
表16.3 オブジェクトパスのプロパティー
プロパティー | 説明 |
---|---|
location | これは {body、header、properties、attachment} のいずれかである必要があります。 |
objectname | オブジェクトの名前。(添付ファイルには名前を付けて番号を付けることができるため、添付ファイルも数値にすることができます。) |
beannames | これは任意です。このタグを使用して Bean グラフをトラバースします。 |
16.18. MVEL 式
表16.4 MVEL 式
式 | 結果 |
---|---|
properties.Order |
これを使用して
をクリックします。 Order という名前のプロパティーオブジェクトを取得します。
|
attachment.1 |
最初の添付ファイルオブジェクトを取得します。
|
attachment.AttachmentOne | AttachmentOne という名前の添付ファイルを取得します。
|
attachment.1.Order |
割り当てられたオブジェクトで
getOrder() リターンオブジェクト を取得します。
|
body.Order1.lineitem |
メッセージの本文から
Order1 という名前のオブジェクトを取得します。次に、このオブジェクトで getLineitem() を呼び出します。Bean グラフをトラバースするために、クエリーにさらに要素を追加できます。
|
16.19. チャンネルを使用した JBoss ルールへのオブジェクト送信
- オブジェクトを JBoss Rules エンジンチャネルに送信するには、この DRL 構文を使用します。( ルール定義 の右側にある。)
channels["mychannel"].send(myobject);
- 上記のコードを機能させるには、
mychannel
をチャネルとして登録します。これには、 channels プロパティーセクションをjboss-esb.xml
設定ファイルに追加します。必要な数のチャネルを定義します。特定のチャネル名ごとに、チャネルは設定ファイルに表示される順序で実行されます。 - 以下のチャネルがサポートされます。
ServiceChannel
(デフォルト)。 channel-name、 service-category、および service-name を send-to 要素の属性として指定します。また、 async、 timeout、および set-payload-location などの任意の属性もあります(そのチャネルに送信されたオブジェクトは、新しいxhtmlメッセージに配置されます)。このコードは、属性の設定方法を示しています。<property name="channels"> <send-to channel-name="mychannel" service-category="cat1" service-name="svc1" /> </property>
重要ターゲットサービスでinvmScope="GLOBAL"
が定義されていることを確認します。- 独自の
org.drools.runtime.Channel
実装クラスを使用してカスタムチャンネルを指定します。この send-to 属性は channel-class です。実装には、パブリックの no-arg コンストラクター が必要です。実装を設定可能にする場合は、setConfiguration(ConfigTree()
メソッドが呼び出されるようにorg.jboss.soa.esb.Configurable
インターフェイスを実装します。これにより、属性とサブプロパティー要素をカスタムチャネルに渡すことができます。このコードサンプルは、カスタムチャネルを設定する方法を示しています。<property name="channels"> <send-to channel-name="mychannel" channel-class="com.example.MyChannel" /> </property>
16.20. ルールのパッケージ化およびデプロイメント
- ルールを
.esb
パッケージに配置して、ルールコードを機能ユニットにパッケージ化します。(ルールセットを使用するルールサービスとともに、ルーティングルール
をパッケージ化することを目的としてい
ます。) jbrules.esb
アーカイブのデプロイを作成したら、deployment.xml
ファイルでこれを参照します。このコードを使用して以下を行います。<jbossesb-deployment> <depends>jboss.esb:deployment=jbrules.esb</depends> </jbossesb-deployment>
パート IX. プロトコルの翻訳
第17章 アダプター
17.1. リソースアダプター
17.2. プロバイダーアダプター
17.3. Java コネクターアーキテクチャー (JCA) トランスポート
17.4. JCA Bridge
17.5. JCA アダプター
パート X. セキュリティー
第18章 セキュリティー
18.1. JBoss のルールとセキュリティー
18.2. サーバーでシリアル化を有効にする
手順18.1 タスク
- SOA_ROOT ディレクトリーに移動します: cd SOA_ROOT。
- keytool コマンドを実行し、画面のプロンプトに従います。
keytool -genkey -alias droolsKey -keyalg RSA -keystore MyDroolsPrivateKeyStore.keystore Enter keystore password: Re-enter new password: What is your first and last name? [Unknown]: Test User What is the name of your organizational unit? [Unknown]: HR What is the name of your organization? [Unknown]: Test Org What is the name of your City or Locality? [Unknown]: Brisbane What is the name of your State or Province? [Unknown]: QLD What is the two-letter country code for this unit? [Unknown]: AU Is CN=Test User, OU=HR, O=Test Org, L=Brisbane, ST=QLD, C=AU correct? [no]: yes Enter key password for droolsKey (RETURN if same as keystore password): Re-enter new password:
すべての質問に回答すると、パスワードで保護されたMyDroolsPrivateKeyStore.keystore
という名前のファイルが作成されます。このキーストアファイルには、パスワード drools とともに droolsKey という秘密鍵があります。このファイルを環境内の安全な場所に保存します。これ以降、これをkeystoredir
と呼びます。重要上記のパスワードは単なる例であり、実稼動環境では使用しないでください。 - 設定ファイルを開きます: vi jboss-as/server/default/deploy/properties-service.xml
- 次のスニペットを
properties-service.xml
に追加して、JBoss Rules シリアライゼーション機能を使用するように JBoss Enterprise SOA Platform を設定します。<mbean code="org.jboss.varia.property.SystemPropertiesService" name="jboss:type=Service,name=SystemProperties"> <attribute name="Properties"> # Drools Security Serialization specific properties drools.serialization.sign=true drools.serialization.private.keyStoreURL=file://$keystoredir/MyDroolsPrivateKeyStore.keystore drools.serialization.private.keyStorePwd=drools drools.serialization.private.keyAlias=droolsKey drools.serialization.private.keyPwd=drools </attribute> </mbean>
- drools.serialization.sign プロパティーを true に設定します
drools.serialization.sign=true
- drools.serialization.private.keyStoreURL=<RL> は、秘密鍵ストアの場所の URL です。
- 上記の例で、
keystoredir
とMyDroolsKeyStore.keystore
を、キーストアディレクトリーと、keytool で作成したキーストアの名前に置き換えます。 - drools.serialization.private.keyStorePwd=<password> は、プライベートキーストアにアクセスするためのパスワードです。
- drools.serialization.private.keyAlias=<key> は秘密鍵のキーエイリアス (識別子) です。
- drools.serialization.private.keyPwd=<password> は秘密鍵のパスワードです。
- ファイルを保存して終了します。
- サーバーインスタンスを再起動します。警告システムプロパティーが正しく設定されていない場合、ルールパッケージをビルドしようとすると、次のエラーが表示されます。
An error occurred building the package. Error signing object store: Key store with private key not configured. Please configure it properly before using signed serialization
18.3. クライアントでシリアル化を有効にする
前提条件
- サーバーのシリアル化がすでに有効になっている必要があります。
手順18.2 タスク
- 秘密鍵ストアから公開鍵証明書を作成します。(keytool -genkey -alias droolsKey -keyalg RSA -keystore を実行して、キーツールにアクセスできます。):
keytool -export -alias droolsKey -file droolsKey.crt -keystore
MyDroolsPrivateKeyStore.keystore Enter keystore password: Certificate stored in file <droolsKey.crtU>
- 公開鍵証明書を公開鍵ストアにインポートします。(これは、クライアントアプリケーションによって使用される場所です):
keytool -import -alias droolsKey -file droolsKey.crt -keystore
MyPublicDroolsKeyStore.keystore Enter keystore password: Re-enter new password: Owner: CN=Test User, OU=Dev, O=XYZ Corporation, L=Brisbane, ST=QLD, C=AU Issuer: CN=Test User, OU=Dev, O=XYZ Corporation, L=Brisbane, ST=QLD, C=AU Serial number: 4ca0021b Valid from: Sun Sep 26 22:31:55 EDT 2010 until: Sat Dec 25 21:31:55 EST 2010 Certificate fingerprints: MD5: 31:1D:1B:98:59:CC:0E:3C:3F:57:01:C2:FE:F2:6D:C9 SHA1: 4C:26:52:CA:0A:92:CC:7A:86:04:50:53:80:94:2A:4F:82:6F:53:AD Signature algorithm name: SHA1withRSA Version: 3 Trust this certificate? [no]: yes Certificate was added to keystore
- サーバー設定ファイルを開きます: vi grep drools jboss-as/server/default/deploy/properties-service.xml
- keystoredir と MyPublicDroolsKeyStore.keystore をキーストアディレクトリー、以前に作成した公開キーストアの名前と置き換えます。
# Drools Client Properties for Security Serialization drools.serialization.public.keyStoreURL=file://$keystoredir/MyPublicDroolsKeyStore.keystore drools.serialization.public.keyStorePwd=drools
- ファイルを保存して終了します。
- JBoss Enterprise SOA Platform サーバーを再起動します。
- Java クライアントアプリケーションの場合は、コードでシステムプロパティーを次のように設定します。
// Set the client properties to deserialize the signed packages URL clientKeyStoreURL = getClass().getResource( "MyPublicDroolsKeyStore.keystore" ); System.setProperty( KeyStoreHelper.PROP_SIGN, "true" ); System.setProperty( KeyStoreHelper.PROP_PUB_KS_URL, clientKeyStoreURL.toExternalForm() ); System.setProperty( KeyStoreHelper.PROP_PUB_KS_PWD, "drools" ); ...
または、run.sh
シェルスクリプト (vi SOA_ROOT/jboss-as/bin/run.sh) スクリプトを開き、 JAVA_OPTS セクション:# Serialization Security Settings JAVA_OPTS="-Ddrools.serialization.sign=true $JAVA_OPTS" JAVA_OPTS="-Ddrools.serialization.private.keyStoreURL=file://$keystoredir/MyDroolsKeyStore.keystore $JAVA_OPTS" JAVA_OPTS="-Ddrools.serialization.private.keyStorePwd=drools $JAVA_OPTS" JAVA_OPTS="-Ddrools.serialization.private.keyAlias=droolsKey $JAVA_OPTS" JAVA_OPTS="-Ddrools.serialization.private.keyPwd=drools $JAVA_OPTS" JAVA_OPTS="-Ddrools.serialization.public.keyStoreURL=file://$keystoredir/MyPublicDroolsKeyStore.keystore $JAVA_OPTS" JAVA_OPTS="-Ddrools.serialization.public.keyStorePwd=drools $JAVA_OPTS"
上記の値を環境に固有の値に置き換えてから、サーバーインスタンスを再起動します。
18.4. シリアル化署名を無効にする
- 設定ファイルを開きます: vi SOA_ROOT/jboss-as/server/PROFILE/deploy/properties-service.xml。
- drools.serialization.sign プロパティーの値を削除します。
- ファイルを保存して終了します。このタスクを実行する別の方法は、
run.sh
シェルスクリプト (vi SOA_ROOT/jboss-as/bin/run.sh) を開いて、次のように編集することです。JAVA_OPTS="-Ddrools.serialization.sign=false $JAVA_OPTS"
- サーバーインスタンスを再起動します。
- Java クライアントアプリケーションのサインオフをオフにするには、 drools.serialization.signプロパティーを変更するか、次のスニペットを各アプリケーションのコードに追加します。
System.setProperty( KeyStoreHelper.PROP_SIGN, "false" );
18.5. サービスごとにセキュリティーを設定する
- グローバル設定ファイルをテキストエディターで開きます: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jboss-esb.xml。
- 設定するサービスまで下にスクロールします。
- セキュリティー要素を追加します。この設定は、その方法を示しています。
<service category="Security" name="SimpleListenerSecured"> <security moduleName="messaging" runAs="adminRole" rolesAllowed="adminRole, normalUsers" callbackHandler="org.jboss.internal.soa.esb.services.security.UserPassCallbackHandler"> <property name="property1" value="value1"/> <property name="property2" value="value2"/> </security> ... </service>
- ファイルを保存して終了します。
18.6. サービスごとのセキュリティープロパティー
表18.1 セキュリティープロパティー
プロパティー | Description | 必須 ? |
---|---|---|
moduleName |
これは
SOA_ROOT/jboss-as/server/PROFILE/conf/login-config.xml ファイルに存在するモジュールです。
| いいえ |
runAs |
これが runAs ロールです。
| いいえ |
rolesAllowed |
これは、サービスを実行する権限が付与されたロールのコンマ区切りリストです。これは、発信者が実際に指定されたロールの 1 つに属していることを確認するために、発信者が認証された後に実行されるチェックとして使用されます。ロールは、基礎となるセキュリティーメカニズムによる認証が成功した後に割り当てられます。
| いいえ |
callbackHandler |
これは
jbossesb-properties.xml ファイルで定義されたものをオーバーライドする CallbackHandler です。
| いいえ |
property |
これらはオプションのプロパティーで、一度定義すると
CallbackHandler 実装で使用できるようになります。
| いいえ |
18.7. グローバルセキュリティー設定を上書きする
手順18.3 タスク
- グローバル設定ファイルをテキストエディターで開きます: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml
- 問題の設定を設定します。以下に例を示します。
<security moduleName="messaging" runAs="adminRole" rolesAllowed="adminRole"> <property name="org.jboss.soa.esb.services.security.contextTimeout" value="50000"/> <property name= "org.jboss.soa.esb.services.security.contextPropagatorImplementationClass" value="org.xyz.CustomSecurityContextPropagator" /> </security>
- ファイルを保存して終了します。
18.8. セキュリティープロパティーのオーバーライド
表18.2 セキュリティープロパティーのオーバーライド:
プロパティー | Description | 必須 ? |
---|---|---|
org.jboss.soa.esb.services.security.contextTimeout |
このプロパティーにより、サービスは
jbossesb-properties.xml ファイルで指定されたグローバルセキュリティーコンテキストタイムアウト (ミリ秒) をオーバーライドできます。
| いいえ |
org.jboss.soa.esb.services.security.contextPropagatorImplementationClass |
このプロパティーにより、サービスは
jbossesb-properties.xml ファイルで指定されたグローバルセキュリティーコンテキストプロパゲータークラスの実装をオーバーライドできます。
| いいえ |
18.9. セキュリティーコンテキスト
18.10. 認証リクエスト
18.11. SecurityConfig
SecurityConfig
クラスは、jboss-esb.xml
ファイルで指定されたセキュリティー設定へのアクセスを許可します。このクラスは、コールバックハンドラーで使用できるようになります。
18.12. 認証クラスをメッセージオブジェクトに追加する
手順18.4 タスク
- 次のコードを実行します。
byte[] encrypted = PublicCryptoUtil.INSTANCE.encrypt((Serializable) authRequest); message.getContext.setContext(SecurityService.AUTH_REQUEST, encrypted);
結果
認証コンテキストは暗号化され、メッセージコンテキスト内に設定されます。(リクエストを認証できるように、後で Enterprise Service Bus によって復号化されます。)
18.13. security_basic クイックスタート
SOA_ROOT/jboss-as/samples/quickstarts/security_basic
クイックスタートは、SecurityInvoker を使用する前にメッセージのセキュリティーを準備する方法を示しています。クイックスタートは、jbossesb-properties.xml
グローバル設定ファイルをクライアントサービスで使用するように設定する方法も示します。
18.14. セキュリティーコンテキストの時間制限をグローバルに設定する
手順18.5 タスク
- グローバル設定ファイルをテキストエディターで開きます: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml
- security.contextTimeout を含むセクションまで下にスクロールします。タイムアウト値を設定します (ミリ秒単位)。
- ファイルを保存して終了します。
18.15. サービスごとにセキュリティーコンテキストの時間制限を設定する
手順18.6 タスク
- サービスの設定ファイル vi jboss-esb.xml をテキストエディターで開きます。
- Security Context を含むセクションまで下にスクロールします。タイムアウト値を設定します (ミリ秒単位)。
- ファイルを保存して終了します。
18.16. セキュリティーサービス
SecurityService
インターフェイスは、Enterprise Service Bus の中央のセキュリティーコンポーネントです。
18.17. セキュリティーの伝播
18.18. SecurityContextPropagator
18.19. SecurityContextPropagator の実装
表18.3 SecurityContextPropagator の実装
Class | Description |
---|---|
パッケージ: org.jboss.internal.soa.esb.services.security
Class: JBossASContextPropagator
|
このプロパゲーターは、セキュリティー認証情報を ESB に送信します。独自の実装を記述する必要がある場合は、
org.jboss.internal.soa.esb.services.security.SecurityContextPropagator を実装するクラスを記述し、jbossesb-properties.xml または jboss-esb.xml でその実装を指定するだけです。
|
18.20. カスタムログインモジュールの追加
手順18.7 タスク
- テキストエディターでログイン設定ファイルを開きます: vi SOA_ROOT/jboss-as/server/PROFILE/conf/login-config.xml
- カスタムログインモジュールの詳細を追加します。
- ファイルを保存して終了します。
- ログインモジュールが異なれば必要な情報も異なるため、使用する CallbackHandler 属性を指定する必要があります。そのサービスの特定のセキュリティー設定を開きます。
- CallbackHandler が
Esb
インターフェイスを実装するクラスの 完全修飾 クラス名を指定するようにしてください。このコードは、その方法を示しています。CallbackHandler
public interface EsbCallbackHandler extends CallbackHandler { void setAuthenticationRequest(final AuthenticationRequest authRequest); void setSecurityConfig(final SecurityConfig config); }
- 発信者を認証するために必要な原則と認証情報の両方を
AuthenticationRequest
クラスに追加します。
結果
JaasSecurityService は、カスタムセキュリティー実装に置き換えられます。
18.21. 証明書ログインモジュール
18.22. 証明書ログインモジュールのプロパティー
<security moduleName="CertLogin" rolesAllowed="worker" callbackHandler="org.jboss.soa.esb.services.security.auth.loginUserPass CallbackHandler"> <property name="alias" value="certtest"/> </security>
表18.4 プロパティー
プロパティー | Description |
---|---|
moduleName
|
これは、使用する JAAS ログインモジュールを識別します。このモジュールは JBossAS login-config.xml で指定されます。
|
rolesAllow
|
これは、このサービスの実行が許可されているロールのコンマ区切りリストです。
|
alias
|
これは、ローカルキーストアを検索するために使用されるエイリアスであり、呼び出し元の証明書を検証するために使用されます。
|
18.23. 証明書ログインモジュールの設定ファイルのプロパティー
<application-policy name="CertLogin"> <authentication> <login-module code="org.jboss.soa.esb.services.security.auth.login.CertificateLoginModule" flag = "required" > <module-option name="keyStoreURL"> file://pathToKeyStore </module-option> <module-option name="keyStorePassword">storepassword</module-option> <module-option name="rolesPropertiesFile"> file://pathToRolesFile </module-option> </login-module> </authentication> </application-policy>
表18.5 証明書ログインモジュールの設定ファイルのプロパティー
プロパティー | Description |
---|---|
keyStoreURL
|
これは、証明書の検証に使用されるキーストアへのパスです。これは、ローカルファイルシステムまたはクラスパス上のファイルにすることができます。
|
keyStorePassword
|
これは、上記のキーストアのパスワードです。
|
rolesPropertiesFile
|
これは任意です。これは、ロールのマッピングを含むファイルへのパスです。詳細については、Getting Started Guide の Role Mapping セクションを参照してください。
|
18.24. コールバックハンドラー
18.25. ロールマッピング
18.26. ロールマッピングを有効にする
手順18.8 タスク
- テキストエディターでログイン設定ファイルを開きます: vi SOA_ROOT/jboss-as/server/PROFILE/conf/login-config.xml
- をセットする rolesPropertiesFile財産。(このプロパティーは、ローカルファイルシステムまたはクラスパスのいずれかにあるファイルを指すことができます)。
- ユーザーをロールにマップします。このコード例は、その方法を示しています。
# user=role1,role2,... guest=guest esbuser=esbrole # The current implementation will use the Common Name(CN) specified # for the certificate as the user name. # The unicode escape is needed only if your CN contains a space Andy\u0020Anderson=esbrole,worker
- ファイルを保存して終了します。
18.27. security_cert クイックスタート
18.28. セキュリティーサービスインターフェイスのカスタマイズ
手順18.9 タスク
SecurityService
インターフェイスを実装します。public interface SecurityService { void configure() throws ConfigurationException; void authenticate( final SecurityConfig securityConfig, final SecurityContext securityContext, final AuthenticationRequest authRequest) throws SecurityServiceException; boolean checkRolesAllowed( final List<String> rolesAllowed, final SecurityContext securityContext); boolean isCallerInRole( final Subject subject, final Principle role); void logout(final SecurityConfig securityConfig); void refreshSecurityConfig(); }
- グローバル設定ファイルをテキストエディターで開きます: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml
- カスタマイズされた
SecurityService
を使用するように ファイルを設定します。 - ファイルを保存して終了します。
18.29. リモート呼び出しクラス
18.30. ポート 8083 での非リモートメソッド呼び出しクラスの保護
ポート 8083
経由で Enterprise Java Bean クラスをダウンロードできます。ただし、システムのリモートメソッド呼び出し設定を設定して、クライアントアプリケーションが必要なデプロイ済みリソースをダウンロードできるようにすることもできます。
手順18.10 タスク
jboss-service.xml ファイルの設定の編集
テキストエディターでファイルを開きます: vi SOA_ROOT/server/PROFILE/conf/jboss-service.xmlファイルで設定を設定する
以下に例を示します。<attribute name="DownloadServerClasses">false</attribute>
クライアントアプリケーションがエンタープライズ Java Bean クラスのみをダウンロードできるようにするには、この値を false に設定します。重要デフォルトでは、この値は SOA プラットフォームの運用プロファイルで false に設定されています。SOA スタンドアロンバージョンのデフォルトプロファイルを含め、他のすべての場合、値は true に設定されます。これは安全な設定ではないため、開発環境でのみ使用する必要があることに注意してください。
第19章 サービスレジストリーの保護
19.1. サービスレジストリー認証
はじめに
ここでは、認証プロセスがどのように機能するかについての理論的な理解を示します。
Authenticator
インターフェイスのメソッドによって表されます。
GetAuthToken
リクエストが行われます。このフェーズの目標は、 user id と認証情報を有効な publisher id にかえることです。パブリッシャー ID (UDDI 用語では 許可された名前 と呼ばれます) は、UDDI 内で所有権を割り当てる値です。新しいエンティティーが作成されるたびに、発行者の承認された名前による所有権でタグ付けする必要があります。
GetAuthToken
要求が完了すると、認証トークン
が呼び出し元に発行されます。
GetAuthToken
要求に対する応答として発行されたトークンを提供する必要があります。これは、識別フェーズにつながります。
UddiEntityPublisher
オブジェクトに変換します。このオブジェクトには、UDDI エンティティーの所有権を処理するために必要なすべてのプロパティーが含まれています。したがって、トークン (または publisher id) は、発行元を識別するために使用されます。
UddiEntityPublisher
のサブクラスである Publisher
エンティティーを提供します。このサブクラスは、パブリッシャーのプロパティーを jUDDI レジストリー内で永続化します。
19.2. authToken
19.3. authToken とサービスレジストリー
authToken
が必要です。
19.4. authToken を取得する
手順19.1 タスク
GetAuthToken()
リクエストを行います。GetAuthToken
オブジェクトが返されます。 userid と credential (パスワード) をこのオブジェクトで設定します。org.uddi.api_v3.GetAuthToken ga = new org.uddi.api_v3.GetAuthToken(); ga.setUserID(pubId); ga.setCred(""); org.uddi.api_v3.AuthToken token = securityService.getAuthToken(ga);
SOA_ROOT/jboss-as/server/PROFILE/deploy/juddi-service.sar/juddi.war/WEB-INF
でjuddi.properties
設定ファイルを見つけます。テキストエディターで開きます。- を設定します juddi.authenticatorプロパティーを使用して、
GetAuthToken
リクエストによって渡された認証情報をサービスレジストリーがチェックする方法を指定します。(デフォルトでは、jUDDIAuthenticator
実装を使用します。) - ファイルを保存して終了します。
19.5. Service Registry で利用可能なセキュリティー認証の実装
- jUDDI 認証
- 警告この認証方法を本番環境で使用しないでください。提供されたすべての認証情報を受け入れ、クライアントがレジストリーにアクセスするときに認証する必要性を効果的に取り除きます。Service Registry によって提供されるデフォルトの認証メカニズムは
jUDDIAuthenticator
です。jUDDIAuthenticator
の認証フェーズは、user ID がPublisher
テーブルのレコードに対して一致を送信したかどうかを確認します。資格証明のチェックは行われません。認証プロセス中に Publisher レコードが存在しないことが判明した場合は、オンザフライで追加されます。識別フェーズでは、publisher ID Publisher レコードを取得して返すために使用されます。パブリッシャーは、必要なすべてのプロパティーをUddiEntityPublisher
から継承します。juddi.authenticator = org.apache.juddi.auth.JUDDIAuthentication
- XMLDocAuthentication
- 認証フェーズでは、ユーザー ID とパスワードが XML ファイル内の値と一致することを確認します。識別フェーズでは、user IDを使用して新しい
UddiEntityPublisher
を設定します。 - CryptedXMLDocAuthentication
CryptedXMLDocAuthentication
の実装はXMLDocAuthentication
の実装に似ていますが、パスワードは暗号化されています。juddi.authenticator = org.apache.juddi.auth.CryptedXMLDocAuthentication juddi.usersfile = juddi-users-encrypted.xml juddi.cryptor = org.apache.juddi.cryptor.DefaultCryptor
ここでは、ユーザー認証情報ファイルはjuddi-users-encrypted.xml
であり、ファイルの内容は次のようになります。<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <juddi-users> <user userid="anou_mana" password="+j/kXkZJftwTFTBH6Cf6IQ=="/> <user userid="bozo" password="Na2Ait+2aW0="/> <user userid="sviens" password="+j/kXkZJftwTFTBH6Cf6IQ=="/> </juddi-users>
DefaultCryptor
の実装では、BEWithMD5AndDES
とBase64
を使用してパスワードを暗号化します。注記AuthenticatorTest
のコードを使用して、この Authenticator 実装の使用方法について詳しく知ることができます。org.apache.juddi.cryptor.Cryptor
インターフェイスを実装し、juddi.cryptor プロパティーで実装クラスを参照することで、独自の暗号化アルゴリズムをプラグインできます。認証フェーズでは、XML ファイル内の user ID とパスワード一致値をチェックします。識別フェーズでは、user ID を使用して新しいUddiEntityPublisher
を設定します。- LDAP 認証
LdapSimpleAuthenticator
を使用して、LDAP の簡易認証機能を介してユーザーを認証します。このクラスを使用すると、principle と jUDDI publisher ID が同じ場合に、LDAP 原則 に基づいてユーザーを認証します。- JBoss 認証
- 最後の代替手段は、サードパーティーの認証情報ストアと連携することです。JBoss Application Server の認証コンポーネントにリンクできます。
docs/examples/auth
ディレクトリーにJBossAuthenticator
クラスが提供されています。このクラスは、JBoss 上の jUDDI デプロイメントがサーバーセキュリティードメインを使用してユーザーを認証できるようにします。
19.6. XMLDocAuthentication の設定
手順19.2 タスク
juddi-users.xml
というテキストファイルを作成し、jbossesb-registry.sar
に保存します。<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <juddi-users> <user userid="sscholl" password="password" /> <user userid="dsheppard" password="password" /> <user userid="vbrittain" password="password" /> </juddi-users>
- ファイルを保存して終了します。
- ファイルをクラスパスに追加します。
- テキストエディターで
juddi.properties
ファイルを開きます (SOA_ROOT/jboss-as/server/PROFILE/deploy/juddi-service.sar/juddi.war/WEB-INF
)。 - ファイルを次のように変更します。
juddi.authenticator = org.apache.juddi.auth.XMLDocAuthentication juddi.usersfile = juddi-users.xml
- ファイルを保存して終了します。
19.7. Lightweight Directory Access Protocol (LDAP)
19.8. LDAP 認証の設定
手順19.3 タスク
SOA_ROOT/jboss-as/server/PROFILE/deploy/juddi-service.sar/juddi.war/WEB-INF
でjuddi.properties
ファイルを見つけます。テキストエディターで開きます。- 次の構成設定を追加してください。
juddi.authenticator=org.apache.juddi.auth.LdapSimpleAuthenticator juddi.authenticator.url=ldap://localhost:389
juddi.authenticator.url プロパティーは、LDAP サーバーが存在する場所をLdapSimpleAuthenticator
クラスに通知します。 - ファイルを保存して終了します。
19.9. JBoss 認証の設定
手順19.4 タスク
SOA_ROOT/jboss-as/server/PROFILE/deploy/juddi-service.sar/juddi.war/WEB-INF
でjuddi.properties
ファイルを見つけます。テキストエディターで開きます。- ファイルに以下の行を追加します。
uddi.auth=org.apache.juddi.auth.JBossAuthenticator juddi.securityDomain=java:/jaas/other
juddi.authenticator プロパティーは、JbossAuthenticator
クラスを jUDDI レジストリーの Authenticator フレームワークに接続します。juddi.security.domain
は、JBossAuthenticator
に Application Server のセキュリティードメインを見つけることができる場所を伝えます。このドメインを使用して認証を実行します。JBoss はSOA_ROOT/jboss-as/server/PROFILE/conf/login-config.xml
ファイル内のアプリケーションポリシー要素ごとに 1 つのセキュリティードメインを作成することに注意してください。これらのドメインは、次の名前でサーバー JNDI ツリーにバインドされます。java:/jaas/<application-policy-name>
(ルックアップが存在しないアプリケーションポリシーを参照する場合、other
という名前のポリシーがデフォルトで使用されます。) - ファイルを保存して終了します。
付録A 更新履歴
改訂履歴 | |||
---|---|---|---|
改訂 5.3.1-78.400 | 2013-10-31 | Rüdiger Landmann | |
| |||
改訂 5.3.1-78 | Mon Feb 18 2013 | CS Builder Robot | |
|