Red Hat Training

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

ESB サービスガイド

JBoss Enterprise SOA Platform 5

本ガイドは開発者向けです。

概要

本ガイドでは、開発者向けに JBoss Enterprise SOA Platform のサービスの開発方法について説明します。

はじめに

1. ドキュメント規則

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

1.1. 表記規則

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

1.2. 引用規則

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

         mutex_lock(&kvm->lock);

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

         kvm_deassign_device(kvm, match);

         kvm_free_assigned_device(kvm, match);

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

1.3. 注記および警告

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

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

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

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

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

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

第1章 はじめに

1.1. ビジネス統合

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

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

はじめに

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

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

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

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

1.4. JBoss Enterprise SOA Platform とは

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

1.5. Service-Oriented Architecture Paradigm

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

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

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

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

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

1.8. JBoss Enterprise SOA Platform の機能

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

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

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

1.10. タスク管理

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

1.11. 統合のユースケース

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

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

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

パート I. はじめに

第2章 はじめに

2.1. 対象読者

本書は、JBoss Enterprise SOA Platform 向けのサービスの開発の基本を学習したい開発者が理解できるように設計されています。

2.2. 本書のねらい

Aim

Enterprise Service Bus Services ガイドは、開発者が JBoss Enterprise SOA Platform にデプロイするサービスの作成方法を学習することを目的としています。リーダーは、Web アプリケーションの使用、ルールサービスの設定、およびコンテンツベースのルーティング機能の設定方法、メッセージの変換およびサービスのデプロイ方法を説明します。

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

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

第3章 basics

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

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

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

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. クイックスタートに関する重要事項

クイックスタートを実行する場合は、次の点に注意してください。
  1. 各クイックスタートは、Apache Ant を使用してビルドおよびデプロイする必要があります。
  2. 各クイックスタートは、samples/quickstarts/conf/quickstarts.properties ファイルを使用して、サーバーがインストールされたディレクトリーなどの環境固有の設定オプションを保存します。サーバーのインストールに一致する quickstarts.properties ファイルを作成する必要があります。プロパティーファイルの例 (quickstarts.properties-example) が含まれています。
  3. クイックスタートごとに要件が異なります。これらは、個別の readme.txt ファイルに記載されています。
  4. すべてのクイックスタートをすべてのサーバープロファイルで実行できるわけではありません。
  5. jBPM クイックスタートには、有効な jBPM コンソールのユーザー名とパスワードが必要です。これらを SOA_ROOT/jboss-as/samples/quickstarts/conf/quickstarts.properties ファイルにプロパティーとして追加して提供します。
    # jBPM console security credentials
    jbpm.console.username=admin 
    jbpm.console.password=adminpassword
    
    この要件の影響を受けるクイックスタートは、bpm_orchestration1bpm_orchestration2bpm_orchestration3、および bpm_orchestration4 です。
  6. サーバーが ヘッドレス モードで実行されていない場合は、一部のクイックスタート (groovy_gateway など) のみを実行できます。(JBoss Enterprise SOA Platform はデフォルトでヘッドレスモードで起動するように設定されています。)
    重要
    Red Hat は、実稼働サーバーをヘッドレスモードでのみ実行することをお勧めします。

3.5. クイックスタートの詳細

特定のクイックスタートについて詳しく知るには:

手順3.1 タスク

  1. クイックスタートの readme.txt ファイルを調べてください。
  2. クイックスタートのディレクトリーで ant help コマンドを実行します。

3.6. "Hello World" クイックスタートの仕組みの概要

図3.1 イメージ

イメージ
  1. JBoss Enterprise SOA Platform サーバーが Window1 で起動され、helloworld クイックスタートがデプロイされると FirstServiceESB:SimpleListener サービスが Service Registry サービスに追加されます。
  2. JMS クライアントは、ESB 非対応の "Hello World" メッセージ (プレーンな String オブジェクト) を JMS キュー (queue/quickstart_helloworld_Request_gw) に送信します。
  3. JMS ゲートウェイリスナーは、ESB 非認識メッセージを受信し、そこから ESB 認識エンドポイントで使用する ESB 認識メッセージを作成します。
  4. JMS ゲートウェイリスナー は、service registry を使用して、FirstServiceESB:SimpleListener サービスの end-point reference (EPR) を見つけます。この場合、EPR は queue/quickstart_helloworld_Request_esb JMS キューです。
  5. JMS ゲートウェイリスナー は、新しい ESB 対応メッセージを受け取り、それを queue/quickstart_helloworld_Request_esb JMS キューに送信します。
  6. FirstServiceESB:SimpleListener サービスがメッセージを受信します。
  7. FirstServiceESB:SimpleListener サービスはメッセージからペイロードを抽出し、コンソールに出力します。

パート II. サービス登録とホスト

第4章 Service Registry の概要

4.1. このセクションについて

はじめに

このセクションでは、サービスレジストリーの概要と、そのレジストリーがどのように対話するかについて説明します。レジストリーの開発方法については、 jUDDI Registry Guide を参照してください。

4.2. Service Registry

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

4.3. juddi レジストリー

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

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. サポートされるその他のサービスレジストリー

JBoss Enterprise SOA Platform は、以下の他の UDDI レジストリーもサポートします。
  • SOA ソフトウェア SMS
  • HP Systinet

4.6. サービスプロバイダー

サービスプロバイダーはサービスへのアクセスを許可し、その説明を作成し、サービスブローカーにパブリッシュします。

4.7. サービスブローカー

サービスブローカーは、サービスの説明のレジストリーをホストします。サービスリクエスターをサービスプロバイダーにリンクします。

4.8. サービスリクエスター

サービスリクエスターは、サービスの検出を行います。これは、サービスブローカーによって提供されたサービスの説明を検索して行います。リクエスターは、サービスプロバイダーから取得したサービスをバインドします。

4.9. Web サービス

Web サービスは、2 つのアプリケーションが Web 経由で通信できるようにする方法です。Web サービスは、この目的を達成するためのツールセットで設定されます。Web サービスには、REST 準拠のサービス (Web リソースの XML 表現を操作する目的) と任意の Web サービス (サービスが任意の操作を公開できる) の 2 つのタイプがあります。

4.10. Web サービスのエンドポイント

Web サービスのエンドポイントとは、Web サービスを実装するソフトウェアです。これらは、サービス指向のアーキテクチャー環境で Web サービス間のメッセージベースの通信を実装するために使用されます。
これらのレジストリーエントリーポイントの外部アプリケーションには、.NET プログラム、その他の外部 Java ベースのアプリケーションサーバー、および LAMP ソフトウェアバンドルを含めることができます。

4.11. Web Services Description Language (WSDL)

Web Services Description Language (WSDL)は、Web サービスインターフェイスの定義に使用される XML ベースの言語です。Web サービスを使用するアプリケーションは、サービスの WSDL ドキュメントを解析し、以下を検出します。
  • サービスの場所
  • サービスがサポートする操作
  • サービスがサポートするプロトコルバインディング (SOAP、HTTP など)
  • アクセス手順
各操作について、WSDL はクライアントが準拠する必要のあるインターフェイス形式を記述します。

4.12. Universal Description、Discovery and Integration (UDDI) レジストリー

Universal Description、Discovery and Integration Registry (UDDI) は Web サービスのディレクトリーです。これを使用して、設計時または実行時にクエリーを実行してサービスを見つけます。UDDI レジストリー内では、情報はページで分類されます。UDDI は、企業やアプリケーションがインターネット上で Web サービスを動的に見つけて使用できるように、標準的な相互運用可能なプラットフォームを作成します。また、UDDI を使用すると、さまざまなコンテキストで運用レジストリーを目的別に維持することもできます。
UDDI により、プロバイダーはサービスの説明を公開することもできます。通常の UDDI レジストリーには、Web サービスの WSDL ドキュメントとサービスプロバイダーの連絡先情報の両方を参照する統一されたリソースロケーター (URL) が含まれます。
ビジネスはサービスを UDDI レジストリーに公開します。クライアントはレジストリーでサービスを検索し、サービスバインディング情報を受信します。その後、クライアントはバインディング情報を使用してサービスを呼び出します。UDDI API は、相互運用性のために SOAP ベースです。

4.13. UDDI アプリケーションプログラミングインターフェイス

UDDI v3 仕様は、9 つの API を定義します。
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

Service Registry は、JBoss Enterprise SOA Platform の主要な部分です。SOA Platform にサービスをデプロイする場合、それらのエンドポイントの参照はそれに保存されます。

4.16. jUDDI および ESB

JBoss Enterprise Service Bus は、レジストリーインターフェイス (Apache Scout を使用する のデフォルトバージョンの) を介してレジストリーとのすべての対話を指示します。

4.17. レジストリーの仕組み

  1. JBoss Enterprise Service Bus は、レジストリーインターフェイスを介したレジストリーとのすべての対話をフェデレーションします。
  2. その後、このインターフェイスの JAXR 実装を呼び出します。
  3. JAXR API は JAXR 実装を使用する必要があります。(デフォルトでは Apache Scout です。)
  4. Apache Scout は、次に レジストリー を呼び出します。

第5章 出版契約

5.1. サービスリストアプリケーション

重要
Red Hat は、現時点ではサービスリスト機能を テクニカルプレビュー としてのみ提供しています。今後のリリースでは、別のテクノロジーに置き換えられる予定です。
Service List Application は、ユーザーがエンドポイントに関する情報を表示できるようにするツールです。(SOAPProcessor アクションによって公開された Web サービスエンドポイントを利用している場合、この情報が必要になることがよくあります)。ツールは http://localhost:8080/contract/ です。このツールは、関連付けられているサービスの下にエンドポイントをグループ化します。

5.2. エンドポイントコントラクト

エンドポイントコントラクトは、エンドポイントが他のサービスと通信する内容を指定します。

5.3. JBoss Enterprise SOA Platform がエンドポイントコントラクトを検出する方法

JBoss Enterprise SOA Platform は、コントラクト情報を公開できる最初のアクションのアクションパイプラインを調べることで、エンドポイントコントラクトを検出します。
どのアクションも実行できない場合、Service List Application は次のメッセージを表示します。
Unavailable on Contract

5.4. 契約書を発行する

手順5.1 タスク

  1. コントラクト情報を公開するには、次の org.jboss.internal.soa.esb.publish.Publish アノテーションをアクションに与える必要があります。(この例では説明目的で SOAPProcessor を使用しています):
    @Publish(JBossWSWebserviceContractPublisher.class)
    public class SOAPProcessor extends AbstractActionPipelineProcessor {
    //TODO: implement
    }
    
  2. org.jboss.soa.esb.actions.soap.ContractPublisher インターフェイスを実装します(実装する必要があるのは 1 つのメソッドだけです)。
    public ContractInfo getContractInfo(EPR epr);
    

パート III. サービスオーケストレーションおよびビジネスプロセス管理

第6章 jBPM Web アプリケーション

6.1. jBPM

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

6.2. jBPM インテグレーションと機能の統合

JBoss Warehouse は、以下の 2 つの理由で jBPM コンポーネントと統合されます。
  • サービスオーケストレーション:プロセス定義を作成して、Business Process Manager を使用してサービスをオーケストレーションできます。
  • ヒューマンタスク管理:Business Process Manager を使用すると、マシンベースのサービスをユーザーが行うタスクの管理と統合できます。

6.3. ビジネス手順で手順のグラフィカル表現の作成

手順6.1 タスク

  • jBPM の Process Designer 機能を使用します。
    注記
    このツールを使用する副次的な利点は、ビジネスアナリストと技術開発者間の優れた作業関係を追いつくことができることです。

6.4. jBPM Web コンソール

jBPM コンソールは、JBoss Business Process Manager を管理するための Web ベースのインターフェイスです。http://localhost:8080/jbpm-console/ で入手できます。

6.5. jBPM Web アプリケーションの JBoss Enterprise SOA Platform へのデプロイ

  1. デプロイメントオプションは多数あります。GPD デプロイメント (グラフィカル設計プロセス)タブ、JSF コンソールのアップロードフォームAnt DeployProcessTask の使用から選択します。
    警告
    jBPM ライブラリーはデプロイ済みのアプリケーションに追加しないでください。 jbpm.esb モジュールは、jBPM アプリケーションの実行に必要なライブラリーおよび設定ファイルをすでに提供しています。提供されたバージョンとデフォルト設定を常に使用します。これは、クラ出力ディングの競合や設定の不一致などの問題を防ぐために、Red Hat の高品質エンジニアリングテストによって改良されているためです。
    注記
    プロセス定義は Web アプリケーションとは別にデプロイする必要があります。Red Hat は、Web アプリケーションの前にプロセスをデプロイすることを推奨します。これにより、後者はプロセスが常に利用可能であると仮定して動作させることができます。
  2. jBPM グラフィカル設計プロセスエディターには、Diagram、Deployment、Design、および Source の 4 つのモードが含まれます。これは、エディター下部のスイッチ可能なタブとして利用できます。プロジェクトのデプロイメント設定を調整するには、Deployment モードを開くタブを選択する必要があります。簡単に変更することも、設定がニーズに合わない場合はそれらをデフォルトにリセットできます。
  3. マルチテナンシーのユースケースでは、単一のサーバーが多数のアプリケーションをホストするので、それぞれ異なる設定が必要になります。プラットフォームで提供されるデフォルトの設定ファイルを上書きしないように、各設定ファイルに一意の名前(jbpm.cfg.xml 以外)を指定することを推奨します。

第7章 jBPM 3 の統合

7.1. JBoss Business Process Manager

JBoss Business Process Manager (jBPM)は、ワークフローおよびビジネスプロセス管理エンジンです。これにより、ビジネスプロセスを設計する際に、ユーザー、アプリケーション、およびサービスを共存させることができます。

7.2. JBPM 統合設定

  1. JBPM データベースを作成するには、DatabaseInitializerMBean を起動します。(この 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 が同梱されています。これはテスト環境でのみ使用してください。
  2. 以下の例に従ってください。
    <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 の統合

jBPM 5 から JBossESB の通信により、サービスオーケストレーションに JBPM を使用できます。これらのサービスの統合に使用される 2 つの JBPM ワークアイテムハンドラークラスは、EsbActionWorkItemHandler と xhtmlServiceWorkItemHandler です。EsbActionWorkItemHandler は、サービスにメッセージを送信し、応答を待ちます。一方、EsbServiceWorkItemHandler は応答を待ちません。
BPM5Callback アクションが含まれる jboss-esb.xml 内にコールバックサービスを指定する必要があります。コールバックサービスのカテゴリーと名前は、コールバックサービスと通信できるように、JECTActionWorkItemHandler に提供されます。以下は、設定例です。
<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 の設定

JBoss Business Process Manager の設定設定は、SOA_ROOT/jboss-as/server/PROFILE/deploy/jbpm.esb/ ディレクトリー内の 3 つのファイルに保存されます。
  • jbpm.cfg.xml
  • hibernate.cfg.xml
  • jbpm.mail.templates.xml
  1. 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>
    
  2. 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 を使用してください。
  3. 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. プロセス定義の作成

  1. Create ウィザードを使用して空のプロセス定義を作成します。FileNewOther を選択します。ウィザードが Select Wizard ページで開きます。
  2. JBoss jBPM カテゴリーを選択し、jBPM Process Definition 項目を選択します。Next ボタンをクリックすると、Create Process Definition ページに移動します。
  3. プロセスアーカイブファイルの名前を入力します。Finish ボタンをクリックしてウィザードを終了し、プロセス定義エディターを開きます。
  4. Package Explorer を表示すると、プロセス定義の作成には、プロセス定義情報が含まれる [process name].jpdl.xml という名前の XML ファイルが作成されていることを確認できます。[process name].jpg と呼ばれる JPG ファイルも、変更がプロセスに保存されると自動的に生成されます。

7.8. プロセス定義のデプロイ

  1. サーバーが実行中であることを確認します。
  2. JBPM グラフィカルエディターDeployment タブに移動して、プロセスアーカイブ をアクティブにします。
    注記
    processdefinition.xml ファイルのみをデプロイする必要がある場合がありますが、ほとんどの場合は、タスクフォームなどの他のタイプの アーティファクト もデプロイします
  3. 以下の方法のいずれかを使用して定義をデプロイします。
    1. JBoss Developer Studio を使用して、デプロイヤーが使用するアップロードサーブレットを設定します。次に、Deploy Process Archive ボタンをクリックします。これは Deployment ビューに表示されます。
    2. DeployProcessToServer JBPM ant タスクの使用
    3. Deployment ビューのローカルの .par ファイルにデプロイメントを保存します。次に、JBPM コンソールを使用してアーカイブをアクティブにします。(これには管理者権限が必要です。)

7.9. JBPM コマンド

JBoss Warehouse は、 BpmProcessor アクションを使用して JBoss Business Process Manager を呼び出すことができます。このアクションは、 JBPM コマンド API を使用します。以下は、使用できる JBPM コマンドです。

表7.2 JBPM コマンド

コマンド Description
NewProcessInstanceCommand このコマンドは、JBPM にすでにデプロイされているプロセス定義に関連付けられている新しい ProcessInstance を起動します。NewProcessInstanceCommand は、プロセスインスタンスを 開始 状態のままにします。これは、 開始ノード に関連付けられているタスクの場合に必要です( アクター の task-list にタスクリストがある場合など)。
StartProcessInstanceCommand
これは NewProcessInstanceCommand と同じですが、新規プロセスインスタンスは 開始 位置から最初のノードに自動的に移動します。
GetProcessInstanceVariablesCommand
プロセスインスタンス識別子を使用して、プロセスインスタンスのルートノード変数を表示します。
CancelProcessInstanceCommand
ProcessInstance 全体をキャンセルします。( ProcessInstance 識別子を含む、メッセージには JBPM コンテキスト変数を設定する必要があります。)

7.10. JBPM での新規プロセスインスタンスの設定

  1. 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. 次の 2 つの属性を入力する必要があります。
    1. name
      アクションパイプライン で一意であれば、 name 属性に任意の値を使用します。
    2. class
      この属性は必ず org.jboss.soa.esb.services.jbpm.actions.BpmProcessor に設定します。

7.11. JBPM 設定プロパティー

表7.3 JBPM 設定プロパティー

プロパティー Description 必須 ?
command
これは、NewProcessInstanceCommandStartProcessInstanceCommandGetProcessInstanceVariablesCommand または 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 コンテキストに設定する必要がある変数の一覧を定義します。この一覧はマッピング要素で設定され、各要素には以下の属性を設定できます。
  • adobe
    これは必の須属性です。MVEL 式をそこに配置し、それを使用して、MVEL メッセージの任意の場所から値を抽出します。
  • bpm
    これは、JBPM 側で使用する名前が含まれる任意の属性です。(省略した場合は、代わりに Enterprise Service Bus 名が使用されます。)
  • default
    これは、MVEL 式の MVEL 式が、Melpers の MVEL メッセージで設定された値を見つけられない場合にデフォルト値を保持できる任意の属性です。
  • bpmToEsbVars
    これは、上記の esbToBpmVars プロパティーと構造的に同じです。これは GetProcessInstanceVariablesCommand と併用し、JBPM プロセスインスタンス変数(ルートトークン 変数 )をためのメッセージにマッピングします。
  • reply-to-originator
    これは、New - および StartProcessInstanceCommand の任意のプロパティーです。プロセスインスタンスを保存するには、true の値を指定して、プロセスインスタンス内の呼び出しメッセージのエンドポイント参照の ReplyTo / FaultTo 値を指定します。これらの値は、後続の EsbNotifier / EsbActionHandler 呼び出し内で使用して、メッセージを ReplyTo / FaultTo アドレスに配信できます。
いいえ

7.12. JBPM の EsbMessage Body 設定

表7.4 JBPM の EsbMessage Body 設定

プロパティー 説明
jbpmProcessInstId
これは、GetProcessInstanceVariablesCommand コマンドおよび CancelProcessInstanceCommand コマンドに適用される必須の Body メッセージボディーパラメーターです。これを EsbMessage 本文の名前付きパラメーターとして手動で設定します。

7.13. adobe-to-JBPM 例外処理

2009 呼び出し中に JBPM Command API から JbpmException が出力された場合、アクションパイプライン に渡されます。パイプラインはエラーをログに記録し、メッセージを DeadLetterService に転送し、(設定されている場合) faultTo エンドポイント参照にエラーを送信します。

7.14. JBPM-JBossESB-to-ESB Integration

JBPM-JBossESB 間の通信では、サービスオーケストレーションに JBPM を使用できます。
これらのサービスのインターグレートに使用される 2 つの JBPM アクションハンドラークラスは、EsbActionHandlerEsbNotifier です。EsbActionHandler は、サービスにメッセージを送信し、応答を待ちます。一方、EsbNotifier は応答を待ちません。
注記
Enterprise Service Bus とのインタラクションは 非同期 であるため、サービスの実行中にプロセスインスタンスはブロックされません。
警告
JBPM サービスと JBoss Warehouse サービス間で渡される変数を表すクラスは、JBPM プロセス、ターゲットの詳細サービス、およびアーキテクト JBPM コールバックサービスに表示されることが重要です。これらのクラスを常にサーバーの lib ディレクトリーにデプロイします。

7.15. JBPM での通知アクション

  1. 以下のように 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>
    
  2. 以下の属性を指定できます。
    • name
      これは必須です。アクションのユーザー指定の名前です。
    • class
      これは必須です。 org.jboss.soa.esb.services.jbpm.actionhandlers.EsbNotifierに設定する必要があります。

7.16. アーキテクトアクションハンドラーの設定

  1. EsbActionHandler をノードに割り当て、ノードの入力時にアクションを呼び出します。EsbActionHandler が実行されると、ノードは移行シグナルを待つ(通常 JBossESB コールバック サービスによって送信されます)。
  2. 以下のように を設定します。
    <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 になります。
この一覧はマッピング要素で設定され、各要素には以下の属性を設定できます。
  • esb
    これは、MVEL 式を含むことができる必須属性です。これを使用して値を抽出し、どこから任意の場所からその値を読み込んだりします。
  • bpm
    これは、JBPM で使用される名前を含む任意の属性です。指定がない場合は、代わりに esb の名前が使用されます。
  • default
    esb MVEL 式が Enterprise Service Bus メッセージに設定されている値を見つけられない場合は、このオプションを使用してデフォルト値を保持します。
  • process-scope
    これは、ブール値で設定されるオプションのパラメーターです。これを使用して、このマッピングの e globalProcessScope の設定を上書きします。
いいえ
exceptionTransition サービスの処理中に例外が発生した場合に使用する移行の名前。現在のノードには、複数の送信移行が必要です。その 1 つは 例外処理を処理 できます。 いいえ

7.18. startProcess 上の jBPM5 プロセスにパラメーターを渡す

これは、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);
name のメッセージプロパティーが設定されている場合、プロセスの開始時に以下の name プロパティーが割り当てられます。
<definition ...>
 
    <itemDefinition id="_nameItem" structureRef="String" />
 
    <process name="Hello" tns:packageName="defaultPackage" ...>
        <property id="name" itemSubjectRef="_nameItem"/>
        <!-- ... -->
    </process>
    <!-- ... -->
</definition>
java.util.Map タイプのプロセスプロパティーを定義するには、以下を実行します。
<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. シグナルイベントの例

これはシグナルイベントの例です。これは、MAn メッセージからプロセスの変数にマップをマッピングするデータの関連付けを定義します。
<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 変数が見つかるデフォルトのスコープを設定します。globalProcessScopetrue に設定されている場合、トークン階層 ( プロセスインスタンス スコープ)内の変数を検索します。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 タイプの式にすることができます。(上記の例の属性値 TokenNamebody.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 です。
通常、call-back はデフォルトの遷移(最初の移行として定義されているため)に問題はありません。ただし、サービスの処理に 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 の前述の定義では、アクションの exceptionTransitionexception に設定されています。このシナリオでは、プロセス自体は 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 遷移が取得されます。
このようにシステムを設定するには、JBPM の デシジョンノード 機能を使用する必要があります。条件内で複数の移行をネスト化できます。
<condition>#{ errorCode!=void }</condition>
注記
条件移行の詳細は、 JBPM Reference Guide を参照してください。

7.27. JBPM コンソールの起動

  1. サーバーが停止したら、アドレス から JBPM コンソール にアクセスし http://localhost:8080/jbpm-console/app/processes.jsf ます。
  2. 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.esbJbpmDS のデータソースファイルの 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. 統合設定

JBoss Warehouse に同梱される jbpm5.esb デプロイメントには、jBPM 5 ランタイム、データソース、hibernate 設定、JPA 永続設定が含まれます。データソースは、デフォルトで H2 をバックエンドデータベースとして使用するよう設定され、セッションおよびプロセス情報の永続化に使用されます。
実稼働環境では、H2 から実稼働強度のデータベースに変更が必要です。すべての jbpm5.esb デプロイメントが同じデータベースインスタンスを共有する必要があります。これにより、さまざまな JBoss administrators ノードが同じプロセス定義およびインスタンスにアクセスできるようにする必要があります。
jBPM コンソール は Web アプリケーションです。同梱されていませんが、オプションでカスタマーポータルからダウンロードしたり、jBPM インストーラーからインストールしたりできます。jbpm-5.2.0.Final インストーラーを使用します。これは、JBoss Warehouse に対してテストされたバージョンであるためです。WEB-INF/jboss-web.xml の context-root を 'jbpm-console' から 'jbpm5-console' に変更して、デフォルトで出荷されている jbpm 3 バージョンコンソールと競合しないように、JBPM NORMAL コンソールの設定にマイナーな変更を加える必要がある場合があります。
jBPM ドキュメント を確認して、このアプリケーションのセキュリティー設定を変更します。これには、conf/login-config.xml の設定を変更する必要があります。コンソールは jBPM プロセスのデプロイと監視に使用できますが、ヒューマンタスク管理にも使用できます。異なるユーザーの場合は、カスタマイズされたタスクリストが表示され、これらのタスクを管理できます。
jbpm5.esb/META-INF ディレクトリーには、deployment.xml と jboss-esb.xml が含まれます。deployment.xml は、この esb アーカイブが依存するリソースを指定します。

8.2. jBPM 5 の設定

デフォルトでは、persistence.xml は、セクションで定義されているように JTA トランザクションマネージャーを使用するように設定されています。
<?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>
その他の設定はデフォルトの jBPM 設定に残り、Hibernate はデータベーススキーマの作成に使用されます。
さらに、に移動して jBPM コンソールのアクティビティーをいつでも表示できます。 http://localhost:8080/business-central

8.3. JBossESB から jBPM 5

JBossESB は、Bpm5Processor アクションを使用して jBPM 5 を呼び出すことができます。このアクションは、jBPM 5 コマンド API を使用して jBPM に呼び出しを行います。以下の jBPM コマンドが実装されています。

表8.1 jBPM 5 コマンド

コマンド Description
startProcess
jBPM にすでにデプロイされているプロセス定義を指定して、新しい ProcessInstance を起動します。
signalEvent
イベントが発生したプロセスへシグナルします。
abortProcessInstance
ProcessInstance をキャンセルします。つまり、イベントが発生すると、ProcessInstance 全体がキャンセルされます。このアクションでは、特に ProcessInstance Id で一部の jBPM コンテキスト変数をメッセージに設定する必要があります。
必要なアクション属性は 2 つあります。
  1. name
    必須属性。name 属性の値は、アクションパイプラインで一意であれば自由に使用できます。
  2. class
    必須属性。この属性は "org.jboss.soa.esb.services.jbpm5.actions.Bpm5Processor" に設定する必要があります
警告
signalEvent の使用は、プロセスインスタンスまたはワークアイテムがどの状態にあるかを示すものがないため、本質的にリスクがあります。signalEvent ではなく、JECTActionWorkItemHandler のリクエスト/リプライ機能を使用します。

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 要素には以下の属性を指定できます。
  • adobe
    EsbMessage から任意の場所に値を抽出するための MVEL 式を含む必須属性。
  • bpm
    jBPM 側で使用される名前を含む任意の属性です。省略した場合は、esb 名が使用されます。
  • value
    ハードコードされた値を保持できる任意の属性です。
いいえ
handlerClass
WS Human Task ハンドラークラス(デフォルト:org.jbpm.task.service.hornetq.CommandBasedHornetQWSHumanTaskHandler)
はい
handlerHost
WS Human タスクサーバーのホスト名(デフォルト:127.0.0.1)
はい
handlerPort
WS Human Task サーバーのホスト名(デフォルト:5446)
はい
注記
jBPM はデフォルトで HornetQ を使用します。もう 1 つのオプションは、以下の設定を必要とする Mina を使用することです。
  • org.jbpm.process.workitem.wsht.CommandBasedWSHumanTaskHandler
  • handlerHost - WS Human タスクサーバーのホスト名(デフォルト:127.0.0.1)
  • handlerPort - WS Human タスクサーバーのホスト名(デフォルト:9123)

8.5. ボディー設定プロパティー

以下は、EsbMessage のコンテキストで設定できる変数の一覧です。

表8.3 ボディー設定プロパティー

プロパティー Description 必須 ?
jbpm5-processinstance-id
signalEvent および abortProcessInstance コマンドに適用されるための context プロパティー。
はい
jbpm5-session-id
読み込むセッションをアクションに指示するための context プロパティー。
はい

第9章 サービスオーケストレーションとアーキテクト

9.1. サービスオーケストレーション

サービスオーケストレーションという用語は、ビジネスプロセスの配置を指します。従来は、Business Process Execution Language (BPEL)を使用して SOAP ベースの Web サービスを実行していました。Red Hat は、プロセスのオーケストレーションに常に JBPM を使用することを推奨します。

9.2. オーケストレーションダイアグラムの作成

  1. FileNewOther を選択します。
  2. Selection ウィザードから JBoss jBPM Process Definition を選択します。
  3. プロセス定義を保存します。混乱を避けるために、プロセス定義ごとに個別のディレクトリーを使用します。
  4. jBPM 統合開発環境 のメニューパレットから Process Design ビューへの "drag-and-drop" 項目を開始します。設計モードとソースモードを切り替えて、追加時に XML 要素を確認できます。
  5. インテグレーションに必要な XML フラグメントを追加します。
  6. オーダープロセスダイアグラムをビルドする前に、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>
    
  7. EsbActionHandler または EsbNotifier アクションハンドラーのいずれかを使用してこれらのサービスを参照します。( JBoss Business Process Manager が応答を期待する場合は EsbActionHandler を選択し、何も必要ない場合は EsbNotifier を選択します。)
  8. ためのサービスが認識されているので、Start state ノードをデザインビューにドラッグします。新しいプロセスインスタンスはこのノードで開始されます。
  9. ノードにドラッグし、Intake Order に名前を付けます。
  10. メニューから Transition を選択し、各ノードをクリックして、Start ノードおよび Intake Order ノードを接続します。それらに接続する矢印が表示されます。最初の Intake Order を参照します。
  11. Intake Node に Service および Category 名を追加します。Source ビューを選択します。Intake Order ノードのソースコードを確認できます。以下のようになります。
    <node name="Intake Order">
    	<transition name="" to="Review Order"></transition>
    </node>
    
  12. 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>
    
  13. 以下のコードを使用して、サービス呼び出しとともに JBoss Business Process Manager コンテキスト変数を送信します。(以下の例では、 entireOrderAsXML という名前の変数がメッセージ本文のデフォルト位置に設定される)があります。
    			
    <bpmToEsbVars>
    	<mapping bpm="entireOrderAsXML" esb="BODY_CONTENT" />
    </bpmToEsbVars>
    
    これにより、 entireOrderAsXML 変数の XML ベースの内容がメッセージの本文で終了します。これで、IntakeService は、パイプラインの各アクションを通過させることにより、メッセージにアクセスし、処理できるようになりました。最後のアクションに達すると、 replyTo プロパティーが確認され、メッセージは JBpmCallBack サービスに送信されます。
    これにより、JBoss Business Process Manager にコールバックし、Intake Order ノードから次のノードへの移行(この場合は 順の確認 の 確認)に通知します。
  14. 次に、メッセージからノードにいくつかの変数を送信します。両方のコンテキストがオブジェクトのクラスをロードできる限り、オブジェクト全体を送信できます。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
  15. オーダープロセスを手動で確認する必要があります。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>
    
  16. XHTML データ形式を作成して、これらの変数を jbpm-console の形式で表示します。
    注記
    詳細は、 bpm_orchestration4 クイックスタートの Review_Order.xhtml ファイルを参照してください。
  17. これらの設定を form .xml ファイルに追加して、このデータ形式を task node にリンクします。
    <forms>
    <form task="Order Review" form="Review_Order.xhtml"/>
    <form task="Discount Review" form="Review_Order.xhtml"/>
    </forms>
    
  18. この場合、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>
    
  19. プロセスが Review Node に到達すると、jBPM コンソールにログインし、Task をクリックしてアイテムのリストを表示できます。
  20. タスクをクリックして詳細を確認します。フォームが表示されます。その後、一部の値を更新できます。
  21. Save and Close をクリックして結論します。この時点で、プロセスは次のノードに移動します。
  22. これは 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 ノードに移行するように指示します。
  23. 値が 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 コンソール
以下のファイルがデプロイされます。
  1. Review_Order.xhtml
  2. forms.xml
  3. gpd.xml
  4. processdefinition.xml
  5. processimage.jpg
統合開発環境により、が作成されます。PAR はそれを jBPM のデータベースにアーカイブしてデプロイします。
警告
Red Hat は、クラ出力ディングの問題が発生する可能性があるため、.PAR アーカイブに Java コードをデプロイしないことを推奨します。代わりに、.JAR または .ESB アーカイブのいずれかを使用してクラスをデプロイします。

9.4. デプロイメントのインスタンス化

  1. プロセス定義をデプロイしたら、新しいプロセスインスタンスを作成します。( 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>
    
  2. これで、新しいプロセスインスタンスが呼び出され、スクリプトを使用して起動します。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 エンジン

BPEL エンジンは BPEL ビジネスプロセス命令を実行します。JBoss Enterprise SOA Platform 製品の一部として含まれる BPEL エンジンは、Apache ODE に基づいています。
注記
ブラウザーで BPEL コンソールウィンドウを 1 つだけ開くことを推奨します。そうしないと、ログイン時に空白のウィンドウが表示されたり、2 つ目のウィンドウからログインできなくなったりする可能性があります。詳細は、RIFTSAW-400 を参照してください。

10.2. Business Process Execution Language (BPEL)

ビジネスプロセス実行言語 (BPEL) は、ビジネスルールオーケストレーション用の OASIS 標準言語です。詳細は、http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html を参照してください。

10.3. BPEL と Service Registry

BPEL は Service Registry と統合されているため、サービスはデプロイ時に自動的に登録できます。
この登録プロセスは、jUDDI クライアントライブラリーを使用します。サービスがデプロイされると、その BindingTemplate とその BindingTemplate (エンドポイント参照)の両方が登録され、partnerLinkChannel ごとに partnerLinkChannel が作成されます。同時に、WSDL エンドポイントは UDDI から取得されます。
デプロイを解除すると、BindingTemplate は UDDI レジストリー から削除されます

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. パートナーリンク

パートナーリンクは、BPEL プロセスとクライアント間の関係を確立するリンクです。

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 ファイルをデプロイする必要があることに注意してください。
注記
ClerkManager Clerk の両方の名前は bpel.properties ファイルに指定されます。

10.9. clerk

clerk (org.apache.juddi.v3.client.config.UDDIClerk)は、Service Registry にサービスのエンドポイントを登録します。

10.10. サービス登録時に Clerk が使用するプロパティーを設定します。

手順10.2 タスク

  1. テキストエディターで esb.juddi.client.xml ファイルを開きます。vi SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb.sar/esb.juddi.client.xml
  2. 設定を構成します。以下に例を示します。
    </nodes>
       <clerks registerOnStartup="false">
          <clerk name="SOAExample" node="default" publisher="root" password="root"/>
       </clerks>
       </manager>
    </uddi>
    
  3. ファイルを保存して終了します。
  4. ファイルの別のコピーをここに配置します(ファイルは常に対応する必要があります: SOA_ROOT/jboss-as/server/PROFILE/deploy/jbossesb-registry.sar/juddi_custom_install_data/)。
  5. ファイルを保存して終了します。

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 登録

BPEL プロセスをデプロイすると、BPEL4WS OASIS technotehttp://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-bpel-20040725.htm()に従ってプロセス情報が UDDI レジストリーに登録されます。

10.13. UDDI End-Point Look-Up

BPEL サービスが別の BPEL サービス(または一般的な Web サービスのエンドポイント)を呼び出す場合、BPEL Engine は serviceQName および portName によるルックアップを実行します(WSDL から取得)。結果はクライアント側のサービスキャッシュに保存されるため、パフォーマンスが向上します。クライアント側のキャッシュが Stale 情報を返しないようにするために、レジストリーは変更が発生するたびに、Subscription API を使用して UDDI レジストリーによりキャッシュを自動的に無効にします。

パート IV. メッセージのルーティング

第11章 ルールを使用したコンテンツベースのルーティングの実行

11.1. Content-Based Router

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

11.2. トレーニングによるコンテンツベースのルーティングの概要

通常、Enterprise Service Bus のデータはパッケージ化され、メッセージの形式で転送および保存されます。メッセージはエンドポイント参照(サービスまたはクライアントのいずれかを指す)に対応します。 エンドポイント参照のロールは、最終的にメッセージの内容を処理するマシンまたはプロセスまたはオブジェクトを識別することです。ただし、指定したアドレスが有効でなくなった場合はどうなりますか ?このシナリオにつながる可能性のある状況には、サービスが失敗したり、削除されたりする状況が含まれます。
また、サービスがその特定のタイプのメッセージを処理しなくなる可能性もあります。この場合、他のサービスが元の関数に対応すると想定されますが、その質問はHow should the message be handled?のままです。 メッセージの内容に目的の受信者が関心があること以外に、他のサービスはどうすればよいでしょうか ?宛先が指定されていない場合はどうすればよいですか ?
これは、コンテンツベースのルーティングが実行される場所です。コンテンツベースのルーティングが機能する仕組みでは、メッセージが開かれ、そのコンテンツに一連のルールが適用されることでルーティングされます。これらのルールは、対象の当事者を確認し、送信先を決定するために使用します。これにより、メッセージの送信アプリケーションは、メッセージがどこにあるべきかを知る必要があります。
コンテンツベースのルーティングシステムは、ルーター(存在する場合は 1 つしかない)およびサービス(通常は複数のコンポーネントがある)の 2 つのコンポーネントに構築されます。サービスは、最終的にメッセージを消費するコンポーネントです。各サービスがルーターへの特定タイプのメッセージに関心があることを示す方法は実装に依存しますが、ルーターが適切にダイレクトされるように、メッセージタイプ(またはメッセージコンテンツの他の要素)とサービスの間にマッピングが存在する必要があります。
名前が示すように、ルーターはルートメッセージを提案します。これらはメッセージを受信する際にメッセージの内容を検査し、そのコンテンツにルールを適用し、ルールが指示されたらメッセージを転送します。
ルーターとサービスに加えて、一部のシステムには harvesters も含まれます。これらのツールのロールは興味深い情報を見つけ、フォーマットされたメッセージの難読者にパッケージ化し、ルーターに送信します。Harvesters "mine" は、メール転送エージェントのメッセージストア、新しいサーバー、データベース、その他のレガシーシステムなど、多くの情報ソースを最小限に抑えます。

11.3. XPath を使用したコンテンツベースのルーティングのインラインルールの定義

手順11.1 タスク

  1. jboss-esb.xml を開き、 cbrAlias プロパティーを XPath に設定します。
  2. 以下に示すように、(コンテナー宛先プロパティーにある)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 タスク

  1. jboss-esb.xml ファイルを開き、 cbrAlias プロパティーを XPath に設定します。
  2. .properties ファイルでルーティング式を定義します。プロパティーキーが宛先名と相関し、プロパティーの値がこの宛先にルーティングするための XPath 式であることを確認します。
  3. コンテナー宛先プロパティーを使用して、 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 ルール

XPath ルールは .properties ファイルにあります。これらは、以下の構文で表されます。
blue=/Order[@statusCode='0']
red=/Order[@statusCode='1']
green=/Order[@statusCode='2']

11.6. Namespace

名前空間は、さまざまな識別子を保持するコンテナーです。これらは、サーバーに要求を提供するのに役立つ XML 名前空間の接頭辞から URI (ユニバーサルリソース識別子)マッピングを定義します。

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 を使用したコンテンツベースのルーティングのインラインルールの定義

  1. jboss-esb.xml ファイルを開き、cbrAlias プロパティーを Regex に設定します。
  2. 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 を使用したコンテンツベースのルーティングの外部ルールの定義

  1. jboss-esb.xml ファイルを開き、cbrAlias プロパティーを Regex に設定します。
  2. .properties ファイルでルーティング式を定義します。プロパティーキーは宛先名であり、プロパティーの値は宛先にルーティングするための Regex 式です。
  3. .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 を使用したコンテンツベースのルーティング

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

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

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

11.12. XPath と名前空間

XPath 式は、メッセージを検索してデータを抽出する機能です。
Xpath で名前空間を使用するには、XPath 式で使用する名前空間接頭辞を指定します。これらの接頭辞は、prefix=uri,prefix=uri の形式でコンマ区切りリストで指定します。
XPath 名前空間対応ステートメント:
  1. xpathMatch expr "<expression>" use namespaces "<namespaces>"
  2. xpathEquals expr "<expression>", "<value>" use namespaces "<namespaces>"
  3. xpathGreaterThan expr "<expression>", "<value>" use namespaces "<namespaces>"
  4. 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.ContentBasedRouterorg.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 タスク)のパッケージにルールを作成したら、ターゲットアプリケーションでエージェントを使用する準備が整います。
以下の例では、path 文字列で指定されたファイルから新しいナレッジベースを構築するエージェントを構築します。これらのファイルは、デフォルトである 60 秒ごとにポーリングして、更新されているかどうかを確認します。新しいファイルが見つかると、新しいナレッジベースが作成されます。変更セットがディレクトリーであるリソースを指定する場合、変更に対してもコンテンツがスキャンされます。
KnowledgeAgent kagent = KnowledgeAgentFactory.newKnowledgeAgent( "MyAgent" );
kagent.applyChangeSet( ResourceFactory.newUrlResource( url ) );
KnowledgeBase kbase = kagent.getKnowledgeBase();
KnowledgeAgent は、一部のデフォルトを変更できる設定を受け入れることができます。プロパティーの例は "drools.agent.scanDirectories" で、デフォルトでは指定されたディレクトリーは新しい追加のためにスキャンされ、これを無効にすることができます。
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 を介して実行できます。
ResourceFactory.getResourceChangeNotifierService().start();
ResourceFactory.getResourceChangeScannerService().start();
BRMS UI のデプロイメント画面には、パッケージへの URL とダウンロードが含まれます。このパッケージを指定するには、change-set.xml ファイルに含めるパッケージ URI の URL が必要です。正確なバージョンを指定します。この場合はスナップショットになります。各スナップショットには独自の URL があります。最新バージョンが必要な場合は、NewSnapshotLATEST に置き換えます。
デプロイメント画面の URL の一覧からパッケージファイル (PKG) をダウンロードすることもできます。このファイルをディレクトリーに置き、KnowledgeAgentfile または dir 機能を使用します。これにより、更新については JBoss Enterprise BRMS Platform サーバーへ自動的に問い合わせますが、一部のシナリオでは望ましくない場合があります。

11.17. ビジネスルールの実行

ビジネスプロセスに応じてメッセージの内容を変更するルールを実行することは、ルーティングのルールの実行と非常に似ています。business_rule_service というクイックスタートの例では、これを示しています。(このクイックスタートでは、org.jboss.soa.esb.actions.BusinessRulesProcessor アクションクラスを利用します。)
このプロセスは、Business Rule Processor というコンポーネントを使用します。これはルーターとほぼ同じですが、詳細な処理のために変更されたメッセージをアクションパイプラインに返す点が唯一の違いがあります。必要に応じて、単一のルールセットでビジネスルールとルーティングルールを混在させることもできます。(ただし、これは前述の 3 つのルーティングアクションクラスのいずれかが使用されている場合にのみ機能します。)

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

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

12.2. Smook の使用

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

12.3. XSLT を使用したメッセージ変換の概要

このサービスは Smooks と同様に機能し、代替として使用できます。

12.4. ActionProcessor データを使用したメッセージ変換の概要

Smooks が特定のタイプの変換を処理できない場合は、このインターフェイス( 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. メッセージストア

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

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 タスク

  1. グローバル設定ファイルをテキストエディターで開きます: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployers/jbossesb-properties.xml
  2. セクションまでスクロールダウンし、設定に合わせて編集します。
    <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 ファイルにあります。
  3. グローバル設定ファイルで、データベース接続マネージャーを設定します。
    <!--  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 エンドポイントをデプロイする場合は、後者を使用します。
  4. ファイルを保存して終了します。
  5. または、 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

以下の SQL コードは、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.StandaloneConnectionManagerorg.jboss.soa.esb.persistence.manager.J2eeConnectionManager の 2 つです。

13.7. C3PO

C3P0 は、Hibernate とともに配布されるオープンソースの JDBC 接続プールです。これは SOA_ROOT/jboss-as/lib ディレクトリーにあります。

13.8. J2eeConnectionManager

J2eeConnectionManager は、JBoss AS アプリケーションサーバーなどの J2EE コンテナーへのデプロイ時に使用する J2EE データソースベースの接続プール実装です。

13.9. JmsConnectionPool

JmsConnectionPool は Java Message Service セッションをプールします。これは、リスナー、courier、およびルーターを含むすべての JMS ベースのコンポーネントによって使用されます。

パート VII. 管理の変更

第14章 ホットデプロイメント

14.1. ホットデプロイメント

ホットデプロイメントとは、デプロイされた ESB アーカイブがサーバープロファイルのデプロイディレクトリーに入るとすぐにそれを検出する SOA Platform サーバーの機能を指します。SOA Platform サーバーソフトウェアは、そのディレクトリーを常に監視し、ディレクトリーへの変更を自動的に検出します。また、既存のアーカイブの状態の変化を検出して、それらを自動的に再デプロイメントすることもできます。
これらのアクションには、ライフサイクルサポート があります。これは、ホット再デプロイ時に、アクティブなリクエストを終了することによって正常に終了することを意味します。それらは、再起動されるまで、それ以上着信メッセージを受け入れません。(これはすべて自動的に行われます。)
注記
JBoss Enterprise SOA Platform がスタンドアロンモードで実行されている場合、アーカイブをデプロイできません。
ノードはこのファイルのタイムスタンプを監視し、変更が発生した場合はその内容を再度読み取ります。

14.2. ホットデプロイメントと jbossesb.sar

jbossesb.sar アーカイブはライブでデプロイできます。次の場合にデプロイされます。
  • タイムスタンプが変更されます (アーカイブが圧縮されている場合)。
  • META-INF/jboss-service.xml ファイルのタイムスタンプが変更されます (アーカイブがデプロイメント形式の場合)。

14.3. ホットデプロイメントと ESB アーカイブ

*.esb アーカイブは、次の場合に自動的に再デプロイメントされます。
  • アーカイブのタイムスタンプが変更されます (アーカイブが圧縮されている場合)。
  • META-INF/jboss-esb.xml ファイルのタイムスタンプが変更されます (アーカイブがデプロイメント形式の場合)。

第15章 バージョン管理

15.1. ルールファイルの再デプロイ

手順15.1 タスク

  1. .DRL または .DSL ファイルを再デプロイするには、jbrules.esb ディレクトリーを SOA_ROOT/jboss-as/server/PROFILE/deploy にコピーして再デプロイします。
  2. または、Action Configuration の ruleReload 機能を有効にすることもできます。この機能を有効にした後、ルールファイルが変更されると、自動的に再ロードされます。

15.2. 変換ファイルの再デプロイ

手順15.2 タスク

  1. .ESB アーカイブを SOA_ROOT/jboss-as/server/PROFILE/deploy ディレクトリーにコピーして再デプロイします。
  2. または、Web ブラウザーを起動して、http://localhost:8080/admin-console Monitoring and Management Console にログインします。
  3. 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. ステートフルセッションセッションプロパティー

  1. 既存のステートフルセッションを続行するには、以下の 2 つのメッセージプロパティーを設定します。
    message.getProperties().setProperty(“dispose”, false);
    message.getProperties().setProperty(“continue”, true);
    
  2. 最後にルールを実行する場合は、dispose を true に設定して、JBoss ルールのエンジンのワーキングメモリーをクリアします。
    message.getProperties().setProperty(“dispose”, true);
    message.getProperties().setProperty(“continue”, true);
    
    注記
    ステートフルなルールセッションの使用に関する詳細は、business_ruleservice_stateful クイックスタートを参照してください。

16.5. JBoss ルールでのルールサービスの使用

JBoss Enterprise SOA Platform のルールサービスを使用すると、JBoss Rules でアーキテクトのビジネスアナリストが作成したビジネスルールを、JBoss Rules のサービスとしてデプロイできます。これには、以下の 2 つの大きな利点があります。
  • ルールをアプリケーション環境に統合するのに必要なクライアントコードの量が大幅に削減されます。
  • ルールは、アクションチェーンまたはオーケストレーションされたビジネスプロセス内からアクセスできます。
注記
JBoss Business Rules Management System はサポートされるオプションですが、必要に応じてルールエンジンを使用することもできます。
ルールサービスの機能は、BusinessRulesProcessor および DroolsRuleService アクションクラスによって提供されます。後者は RuleService インターフェイスも実装します。
BusinessRulesProcessor クラスを使用すると、クラスパスからルールを読み込むことができます。これらのルールは、.drl ファイルおよび .dsl ファイル、および デシジョンテーブル ( .xls 形式)で定義されます。これらのファイルベースのルールは、主にプロトタイプをテストするために存在します。単一の BusinessRulesProcessor アクションに複数のルールファイルを指定する方法はありません。より複雑なルールサービスには、 JBoss Rules KnowledgeAgent を使用する必要があります。
RuleService KnowledgeAgent を使用して、 Business Rules Management System またはローカルファイルシステムから ルールパッケージ にアクセスします。ルールパッケージには、以下を含むさまざまなソースからの数千のルールを含めることができます。
  1. JBoss Business Rules Management System
  2. インポートした DRL ファイル
  3. ドメイン固有言語 (DSL)ファイル
  4. デシジョンテーブル
重要
Red Hat は、実稼働システムでは KnowledgeAgent アプローチを使用することを推奨します。
その BusinessRulesProcessor アクションは、JBoss Rules の実行モデル、ステートレス モデルと ステートフル モデルの両方をサポートします。
ほとんどのルールサービスはステートレスモデルに準拠します。このモデルでは、ルールエンジンによって処理されるすべてのファクトが含まれるメッセージがルールサービスに送信されます。その後、ルールはメッセージやファクトを実行し、更新します。
一方、ステートフル実行は長期間行われ、複数のメッセージがルールサービスに送信されます。メッセージが送信されるたびに、ルールが再度実行され、メッセージやファクトが更新されます。プロセスの完了時に、最終メッセージはルールサービスに、ステートフルセッションの ワーキングメモリー を破棄するように指示し、次にルールエンジンからパージされます。
重要
RuleAgent は SOA Platform で使用されなくなりました。これは、異なる設定を行う KnowledgeAgent に置き換えられました。DRL の変更のポーリング設定は、ruleAgentProperties ファイルの poll プロパティーを使用して実行されなくなりました。これで、esb.deployer/jbossesb-properties.xml にある org.jboss.soa.esb.services.rules.resource.scanner.interval プロパティーを介してグローバルに設定できるようになりました。(デフォルト値は 60 です。) つまり、システムは 6 秒ごとにすべての KnowledgeAgents でリソースの変更をチェックします。
Basic 認証でセキュア化された URL にアクセスするには、以下のプロパティーを提供する必要があります。

username=admin password=admin enableBasicAuthentication=true

注記
ステートフルモデルのメッセージフローには、単一のルールサービスのみを使用できます。

16.6. action Chain

action チェーンはアクションコンポーネントをグループ化し、処理中に実行します。

16.7. オーケストレーションされたビジネスプロセス

このようなサービスサービスは、デプロイメントのためにアプリケーションを大まかに結合して、簡単に変更できるようにします。これは、アプリケーション、サービス、およびコンポーネントと対話します。

16.8. JBoss ルールおよび SOA Platform の統合

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. ルールセットの作成

  1. rule-set がためのメッセージをインポートしていることを確認します。テストするには、以下のコードを使用します。
    import org.jboss.soa.esb.message.Message
    
  2. 次に、ルールセットが、宛先の一覧を作成する以下のグローバル変数を定義することを確認します。
    global java.util.List destinations;
    
    これで、メッセージは JBoss Rules エンジンのワーキングメモリーに送信されます。
    これで、通常のルールセットをコンテンツベースのルーティングに使用できるものに変換できます。これを行うには、MA メッセージのマッチングルールを評価し、サービス宛先名 の一覧を出力します。

16.11. ルールセットの例

ルールは DRL ファイルにあり、ステートレスモデルに従って実行します。
      <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 ファイルにあり、ステートレスモデルに従って実行します。
  • ルールは DRL ファイルにあり、ステートフルモデルに従って実行されます。このシナリオでは、クライアントは複数のメッセージをルールサービスに送信できます。たとえば、最初のメッセージには customer オブジェクトが含まれ、後続のメッセージにはお客様の注文が含まれる可能性があります。メッセージを受信するたびに、ルールが実行されます。(クライアントは、ワーキングメモリーの内容を破棄するようにルールサービスに指示する最終メッセージにプロパティーを追加できます。)
    1. 単一の同期セッションインスタンスは、ステートフルセッションデプロイメントのすべての同時実行で共有されます。これにより、ステートフルモデルのユースケースの数が大幅に制限されます。複数のクライアント指向セッションサービスデプロイメントが必要な場合は、代わりに jBPM ソリューションまたは BPEL ソリューションの使用を検討してください。
    2. ステートフルセッションは 永続 的ではありません。
    3. ステートフルセッションは クラスター化 されていません。
         <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>
    
ルールは DRL ファイルにあり、ステートフルモデルが使用され、監査ロギングが有効になり、JBoss ルールが使用されます。 clockType , eventProcessingType および チャネルは、複雑なイベント処理を容易にするために設定されます。
ruleMultithreadEvaluation が false に設定されているため、ナレッジベースのパーティション設定は有効になっていません( ruleMaxThreads は 1 に設定されていることも注意してください)。
注記
複雑なイベント処理シナリオでは、ステートフルモデルを使用し、ステートフルセッションデプロイメントのすべての同時実行で共有されます。
     <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>
ルールは BRMS 形式であり、ステートレス実行モデルが使用されます。
      <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)

MVEL は MVFLEX 式言語です。これは、Java 環境で使用されるプログラミング言語です。

16.16. オブジェクトパスの使用

  1. object-paths プロパティーを設定して、これらのオブジェクトを 1 つの Message Object Path で抽出します。
    注記
    object-paths プロパティーを使用して、さらにオブジェクトツリーにドリルダウンできます。これを行うには、このプロパティーを設定して、これらのオブジェクトを MRG Message Object Path で抽出します。
  2. 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 ルールへのオブジェクト送信

  1. オブジェクトを JBoss Rules エンジンチャネルに送信するには、この DRL 構文を使用します。( ルール定義 の右側にある。)
    channels["mychannel"].send(myobject);
    
  2. 上記のコードを機能させるには、mychannel をチャネルとして登録します。これには、 channels プロパティーセクションを jboss-esb.xml 設定ファイルに追加します。
    必要な数のチャネルを定義します。特定のチャネル名ごとに、チャネルは設定ファイルに表示される順序で実行されます。
  3. 以下のチャネルがサポートされます。
    • 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. ルールのパッケージ化およびデプロイメント

  1. ルールを .esb パッケージに配置して、ルールコードを機能ユニットにパッケージ化します。(ルールセットを使用するルール サービスとともに、ルーティングルール をパッケージ化することを目的として ます。)
  2. 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) トランスポート

Java コネクターアーキテクチャー (JCA) トランスポートは、サービスインテグレータとして機能する Java ベースのアーキテクチャーです。アプリケーションサーバーと企業情報システムをつなぐコネクターです。

17.4. JCA Bridge

JCA ブリッジは、接続を開いたり閉じたりできるディスパッチャーです。ユーザーが設定した接続を識別し、コネクターとゲートウェイを検出できます。

17.5. JCA アダプター

JCA アダプターは、アプリケーションサーバーとエンタープライズ情報システムをリンクする仲介者として機能します。

パート X. セキュリティー

第18章 セキュリティー

18.1. JBoss のルールとセキュリティー

デフォルトでは、JBoss Rules コンポーネントはルールパッケージまたは署名されていないルールベースをデシリアライズしません。
重要
設定が Red Hat によってサポートされるようにするには、このシリアライゼーションセキュリティー機能を有効にする必要があります。パッケージとそのルールベースをシリアライズするアプリケーション (以下、サーバーと呼びます) と、パッケージとそのルールベースをデシリアライズするアプリケーション (以下、クライアントと呼びます) の両方のシステムプロパティーを設定する必要があります。

18.2. サーバーでシリアル化を有効にする

手順18.1 タスク

  1. SOA_ROOT ディレクトリーに移動します: cd SOA_ROOT
  2. 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 と呼びます。
    重要
    上記のパスワードは単なる例であり、実稼動環境では使用しないでください。
  3. 設定ファイルを開きます: vi jboss-as/server/default/deploy/properties-service.xml
  4. 次のスニペットを 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>
    
  5. drools.serialization.sign プロパティーを true に設定します
    drools.serialization.sign=true
    
    • drools.serialization.private.keyStoreURL=<RL> は、秘密鍵ストアの場所の URL です。
    • 上記の例で、keystoredirMyDroolsKeyStore.keystore を、キーストアディレクトリーと、keytool で作成したキーストアの名前に置き換えます。
    • drools.serialization.private.keyStorePwd=<password> は、プライベートキーストアにアクセスするためのパスワードです。
    • drools.serialization.private.keyAlias=<key> は秘密鍵のキーエイリアス (識別子) です。
    • drools.serialization.private.keyPwd=<password> は秘密鍵のパスワードです。
  6. ファイルを保存して終了します。
  7. サーバーインスタンスを再起動します。
    警告
    システムプロパティーが正しく設定されていない場合、ルールパッケージをビルドしようとすると、次のエラーが表示されます。
    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 タスク

  1. 秘密鍵ストアから公開鍵証明書を作成します。(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>
    
  2. 公開鍵証明書を公開鍵ストアにインポートします。(これは、クライアントアプリケーションによって使用される場所です):
    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
    
  3. サーバー設定ファイルを開きます: vi grep drools jboss-as/server/default/deploy/properties-service.xml
  4. keystoredir MyPublicDroolsKeyStore.keystore をキーストアディレクトリー、以前に作成した公開キーストアの名前と置き換えます。
    # Drools Client Properties for Security Serialization
    drools.serialization.public.keyStoreURL=file://$keystoredir/MyPublicDroolsKeyStore.keystore
    drools.serialization.public.keyStorePwd=drools
    
  5. ファイルを保存して終了します。
  6. JBoss Enterprise SOA Platform サーバーを再起動します。
  7. 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. シリアル化署名を無効にする

  1. 設定ファイルを開きます: vi SOA_ROOT/jboss-as/server/PROFILE/deploy/properties-service.xml
  2. drools.serialization.sign プロパティーの値を削除します。
  3. ファイルを保存して終了します。
    このタスクを実行する別の方法は、run.sh シェルスクリプト (vi SOA_ROOT/jboss-as/bin/run.sh) を開いて、次のように編集することです。
    JAVA_OPTS="-Ddrools.serialization.sign=false $JAVA_OPTS"
    
  4. サーバーインスタンスを再起動します。
  5. Java クライアントアプリケーションのサインオフをオフにするには、 drools.serialization.signプロパティーを変更するか、次のスニペットを各アプリケーションのコードに追加します。
    System.setProperty( KeyStoreHelper.PROP_SIGN, "false" );
    

18.5. サービスごとにセキュリティーを設定する

  1. グローバル設定ファイルをテキストエディターで開きます: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jboss-esb.xml
  2. 設定するサービスまで下にスクロールします。
  3. セキュリティー要素を追加します。この設定は、その方法を示しています。
    <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>
    
  4. ファイルを保存して終了します。

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 タスク

  1. グローバル設定ファイルをテキストエディターで開きます: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml
  2. 問題の設定を設定します。以下に例を示します。
    <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>
    
  3. ファイルを保存して終了します。

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. セキュリティーコンテキスト

SecurityContext は、セキュリティー証明書が確認された後に作成されるオブジェクトです。作成後、証明書に関連するアクションを実行するたびに証明書を再認証する必要がないように設定されます。ESB は、メッセージに SecurityContext があることを検出すると、それがまだ有効であることを確認し、有効である場合は再認証を試みません。(SecurityContext は単一の Enterprise Service Bus ノードに対してのみ有効であることに注意してください。メッセージが別の ESB ノードにルーティングされる場合は、再認証する必要があります。)

18.10. 認証リクエスト

AuthenticationRequest は、ゲートウェイとサービス間、または 2 つのサービス間の認証に必要なセキュリティー情報を運びます。認証サービスを呼び出す前に、メッセージオブジェクトにこのクラスのインスタンスを設定する必要があります。クラスには、呼び出し元を認証するために必要な原則と認証情報が含まれている必要があります。このクラスは、コールバックハンドラーで使用できるようになります。

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 タスク

  1. グローバル設定ファイルをテキストエディターで開きます: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml
  2. security.contextTimeout を含むセクションまで下にスクロールします。タイムアウト値を設定します (ミリ秒単位)。
  3. ファイルを保存して終了します。

18.15. サービスごとにセキュリティーコンテキストの時間制限を設定する

手順18.6 タスク

  1. サービスの設定ファイル vi jboss-esb.xml をテキストエディターで開きます。
  2. Security Context を含むセクションまで下にスクロールします。タイムアウト値を設定します (ミリ秒単位)。
  3. ファイルを保存して終了します。

18.16. セキュリティーサービス

SecurityService インターフェイスは、Enterprise Service Bus の中央のセキュリティーコンポーネントです。

18.17. セキュリティーの伝播

セキュリティー伝播という用語は、セキュリティー情報を外部システムに渡すプロセスを指します。たとえば、Enterprise Service Bus と Enterprise Java Beans メソッドの両方を呼び出すために、同じ認証情報を使用したい場合があります。

18.18. SecurityContextPropagator

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 タスク

  1. テキストエディターでログイン設定ファイルを開きます: vi SOA_ROOT/jboss-as/server/PROFILE/conf/login-config.xml
  2. カスタムログインモジュールの詳細を追加します。
  3. ファイルを保存して終了します。
  4. ログインモジュールが異なれば必要な情報も異なるため、使用する CallbackHandler 属性を指定する必要があります。そのサービスの特定のセキュリティー設定を開きます。
  5. CallbackHandler が Esb CallbackHandler インターフェイスを実装するクラスの 完全修飾 クラス名を指定するようにしてください。このコードは、その方法を示しています。
    public interface EsbCallbackHandler extends CallbackHandler
    {
      void setAuthenticationRequest(final AuthenticationRequest authRequest);
      void setSecurityConfig(final SecurityConfig config);
    }
    
  6. 発信者を認証するために必要な原則と認証情報の両方を AuthenticationRequest クラスに追加します。

結果

JaasSecurityService は、カスタムセキュリティー実装に置き換えられます。

18.21. 証明書ログインモジュール

証明書ログインモジュールは、Enterprise Service Bus への呼び出しで渡された証明書を、ローカルキーストアに保持されている証明書と照合して認証を実行します。証明書の共通名は原則を作成します。

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 タスク

  1. テキストエディターでログイン設定ファイルを開きます: vi SOA_ROOT/jboss-as/server/PROFILE/conf/login-config.xml
  2. をセットする rolesPropertiesFile財産。(このプロパティーは、ローカルファイルシステムまたはクラスパスのいずれかにあるファイルを指すことができます)。
  3. ユーザーをロールにマップします。このコード例は、その方法を示しています。
    # 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
    
  4. ファイルを保存して終了します。

18.27. security_cert クイックスタート

security_cert クイックスタートは、JBoss Enterprise SOA Platform のロールマッピング機能を示します。

18.28. セキュリティーサービスインターフェイスのカスタマイズ

手順18.9 タスク

  1. 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();
    }
    
  2. グローバル設定ファイルをテキストエディターで開きます: vi SOA_ROOT/jboss-as/server/PROFILE/deployers/esb.deployer/jbossesb-properties.xml
  3. カスタマイズされた SecurityServiceを使用するように ファイルを設定します。
  4. ファイルを保存して終了します。

18.29. リモート呼び出しクラス

リモート呼び出しクラスは、その名前が示すように、リモートマシンから呼び出すことができるクラスです。これは開発者にとっては便利ですが、潜在的なセキュリティーリスクにつながる可能性もあります。

18.30. ポート 8083 での非リモートメソッド呼び出しクラスの保護

デフォルトでは、クライアントアプリケーションは Remote Method Invocation を利用して、ポート 8083 経由で Enterprise Java Bean クラスをダウンロードできます。ただし、システムのリモートメソッド呼び出し設定を設定して、クライアントアプリケーションが必要なデプロイ済みリソースをダウンロードできるようにすることもできます。

手順18.10 タスク

  1. jboss-service.xml ファイルの設定の編集

    テキストエディターでファイルを開きます: vi SOA_ROOT/server/PROFILE/conf/jboss-service.xml
  2. ファイルで設定を設定する

    以下に例を示します。
    <attribute name="DownloadServerClasses">false</attribute>
    
    クライアントアプリケーションがエンタープライズ Java Bean クラスのみをダウンロードできるようにするには、この値を false に設定します。
    重要
    デフォルトでは、この値は SOA プラットフォームの運用プロファイルで false に設定されています。SOA スタンドアロンバージョンのデフォルトプロファイルを含め、他のすべての場合、値は true に設定されます。これは安全な設定ではないため、開発環境でのみ使用する必要があることに注意してください。

第19章 サービスレジストリーの保護

19.1. サービスレジストリー認証

はじめに

ここでは、認証プロセスがどのように機能するかについての理論的な理解を示します。

認証は 2 フェーズのプロセスです。これらは、認証フェーズ および 識別フェーズ として知られています。これらのフェーズはいずれも、 Authenticator インターフェイスのメソッドによって表されます。
認証フェーズは、 GetAuthToken リクエストが行われます。このフェーズの目標は、 user id と認証情報を有効な publisher id にかえることです。パブリッシャー ID (UDDI 用語では 許可された名前 と呼ばれます) は、UDDI 内で所有権を割り当てる値です。新しいエンティティーが作成されるたびに、発行者の承認された名前による所有権でタグ付けする必要があります。
publisher idの値は、jUDDI レジストリーには関係ありません。唯一の要件は、新しいエンティティーに割り当てるために存在するため、null でない必要があることです。 GetAuthToken 要求が完了すると、認証トークン が呼び出し元に発行されます。
認証を必要とする UDDI API への後続の呼び出しを行うときは、 GetAuthToken 要求に対する応答として発行されたトークンを提供する必要があります。これは、識別フェーズにつながります。
識別フェーズは、認証トークン (または publisher idそのトークンに関連付けられている) を有効な UddiEntityPublisher オブジェクトに変換します。このオブジェクトには、UDDI エンティティーの所有権を処理するために必要なすべてのプロパティーが含まれています。したがって、トークン (または publisher id) は、発行元を識別するために使用されます。
この 2 つのフェーズは、UDDI 認証構造に準拠し、独自の認証メカニズムを提供する場合に柔軟性を提供します。
クレデンシャルとパブリッシャープロパティーの処理は、jUDDI レジストリーの外部で完全に実行できます。ただし、デフォルトでは、レジストリーは UddiEntityPublisher のサブクラスである Publisher エンティティーを提供します。このサブクラスは、パブリッシャーのプロパティーを jUDDI レジストリー内で永続化します。

19.2. authToken

authToken は、パスワード認証情報を保持するセキュリティーコンテナーです。

19.3. authToken とサービスレジストリー

Service Registry への適切な書き込みアクセスを強制するには、サービスレジストリーに対する各リクエストに有効な authToken が必要です。
重要
読み取りアクセスはまったく制限されていないことに注意してください。

19.4. authToken を取得する

手順19.1 タスク

  1. GetAuthToken() リクエストを行います。
  2. 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);
    
  3. SOA_ROOT/jboss-as/server/PROFILE/deploy/juddi-service.sar/juddi.war/WEB-INFjuddi.properties 設定ファイルを見つけます。テキストエディターで開きます。
  4. を設定します juddi.authenticatorプロパティーを使用して、GetAuthToken リクエストによって渡された認証情報をサービスレジストリーがチェックする方法を指定します。(デフォルトでは、jUDDIAuthenticator 実装を使用します。)
  5. ファイルを保存して終了します。

19.5. Service Registry で利用可能なセキュリティー認証の実装

jUDDI 認証
警告
この認証方法を本番環境で使用しないでください。提供されたすべての認証情報を受け入れ、クライアントがレジストリーにアクセスするときに認証する必要性を効果的に取り除きます。
Service Registry によって提供されるデフォルトの認証メカニズムは jUDDIAuthenticator です。jUDDIAuthenticator の認証フェーズは、user IDPublisher テーブルのレコードに対して一致を送信したかどうかを確認します。資格証明のチェックは行われません。認証プロセス中に 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 の実装では、BEWithMD5AndDESBase64 を使用してパスワードを暗号化します。
注記
AuthenticatorTest のコードを使用して、この Authenticator 実装の使用方法について詳しく知ることができます。org.apache.juddi.cryptor.Cryptor インターフェイスを実装し、juddi.cryptor プロパティーで実装クラスを参照することで、独自の暗号化アルゴリズムをプラグインできます。
認証フェーズでは、XML ファイル内の user ID とパスワード一致値をチェックします。識別フェーズでは、user ID を使用して新しい UddiEntityPublisher を設定します。
LDAP 認証
LdapSimpleAuthenticator を使用して、LDAP の簡易認証機能を介してユーザーを認証します。このクラスを使用すると、principlejUDDI publisher ID が同じ場合に、LDAP 原則 に基づいてユーザーを認証します。
JBoss 認証
最後の代替手段は、サードパーティーの認証情報ストアと連携することです。JBoss Application Server の認証コンポーネントにリンクできます。
docs/examples/auth ディレクトリーに JBossAuthenticator クラスが提供されています。このクラスは、JBoss 上の jUDDI デプロイメントがサーバーセキュリティードメインを使用してユーザーを認証できるようにします。

19.6. XMLDocAuthentication の設定

手順19.2 タスク

  1. 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>
    
  2. ファイルを保存して終了します。
  3. ファイルをクラスパスに追加します。
  4. テキストエディターで juddi.properties ファイルを開きます (SOA_ROOT/jboss-as/server/PROFILE/deploy/juddi-service.sar/juddi.war/WEB-INF)。
  5. ファイルを次のように変更します。
    juddi.authenticator = org.apache.juddi.auth.XMLDocAuthentication
    juddi.usersfile = juddi-users.xml
    
  6. ファイルを保存して終了します。

19.7. Lightweight Directory Access Protocol (LDAP)

Lightweight Directory Access Protocol (LDAP) は、インターネット経由で分散ディレクトリー情報にアクセスするためのプロトコルです。

19.8. LDAP 認証の設定

手順19.3 タスク

  1. SOA_ROOT/jboss-as/server/PROFILE/deploy/juddi-service.sar/juddi.war/WEB-INFjuddi.properties ファイルを見つけます。テキストエディターで開きます。
  2. 次の構成設定を追加してください。
    juddi.authenticator=org.apache.juddi.auth.LdapSimpleAuthenticator
    juddi.authenticator.url=ldap://localhost:389
    
    juddi.authenticator.url プロパティーは、LDAP サーバーが存在する場所を LdapSimpleAuthenticator クラスに通知します。
  3. ファイルを保存して終了します。

19.9. JBoss 認証の設定

手順19.4 タスク

  1. SOA_ROOT/jboss-as/server/PROFILE/deploy/juddi-service.sar/juddi.war/WEB-INFjuddi.properties ファイルを見つけます。テキストエディターで開きます。
  2. ファイルに以下の行を追加します。
    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 という名前のポリシーがデフォルトで使用されます。)
  3. ファイルを保存して終了します。

付録A 更新履歴

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