Red Hat Training

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

JBoss SOA BPEL ガイド

JBoss Enterprise SOA Platform 5

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

概要

このガイドでは、ビジネスプロセス実行言語 (BPEL) エンジンの使用方法を開発者に説明します。

はじめに

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 レポートを送信してください。
バグレポートを送信する際には、マニュアル識別子 『JBoss_SOA_BPEL_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 サービスと組み合わせて使用して、異なるシステムが同じ言語にピークにすることができます。これにより、システムの同期に必要なアップグレードおよびカスタムコードの量が減ります。

第2章 はじめに

2.1. 対象読者

本書は、JBoss Enterprise SOA Platform の BPEL エンジンを操作したい開発者向けに書かれています。

2.2. 本書のねらい

JBoss Enterprise SOA Platform の Business Process Execution Language (BPEL) エンジンを使用する方法を学ぶために、本書をお読みください。インストールおよび設定ガイド の指示に従って、システムがすでにインストールされ、正しく設定されていることを前提としています。

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

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

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

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

2.5. 変数名: PROFILE

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

2.6. サーバープロファイル

表2.1 サーバープロファイル

プロファイル Description
default このプロファイルは、開発とテストに使用します。このプロファイルは、プロダクションプロファイルよりもメモリーの使用量が少なくなりますが、このモードではクラスターリングは有効になりません。さらに、このプロファイルは、"all" および "production" プロファイルよりも詳細なログを提供します。この詳細ログは追加情報を提供しますが、サーバーのパフォーマンスに悪影響を及ぼします。別のプロファイルを明示的に指定しない限り、サーバーの始動時にこのプロファイルが使用されます。
実稼働 このプロファイルは実動サーバーで使用してください。このプロファイルは、クラスターリングを提供し、より多くのメモリーを使用し、all または default プロファイルよりも詳細なログと画面コンソール出力を提供しないことで、パフォーマンスを最大化します。このモードでは、出力 (Hello World クイックスタートからのメッセージなど) がコンソール画面に表示されないことに注意してください。ログのみに書き込まれます。
最小 機能するシステムに必要な最小限の機能を有効にします。アーカイブはデプロイされません。ESB または SOA 機能は有効化されていません。BPEL エンジンは使用できません。
standard これにより、テスト用の標準機能が提供されます。Web、ESB、または SOA 機能は有効になっていません。BPEL エンジンは使用できません。
web このプロファイルが実行されると、jbossweb.sar アーカイブがデプロイされます。ESB または SOA 機能は有効化されていません。BPEL エンジンは使用できません。
all このプロファイルを実行すると、事前にパッケージ化された ESB アーカイブがすべてデプロイされます。このプロファイルは、運用プロファイルよりもパフォーマンスとスケーラビリティが低くなりますが、実行に必要なメモリーは少なくなります。

2.7. Java 仮想マシン

Java 仮想マシン (JVM) は、Java バイトコードを実行できるソフトウェアです。JVM は、中間バイトコードが実行される標準環境を作成します。基盤となるハードウェアとオペレーティングシステムの組み合わせに関係なく標準的な環境を作成することにより、プログラマーは一度 Java コードを記述すれば、どのシステムでも実行できるという安心感を持つことができます。Red Hat は、OpenJDK を使用することを推奨します。OpenJDK は、Red Hat Enterprise Linux システムで適切に動作する、サポートされているオープンソースの Java 仮想マシンです。Windows ユーザーは、Oracle JDK 1.6 をインストールする必要があります。

第3章 BPEL エンジン

3.1. BPEL エンジン

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

3.2. Business Process Execution Language (BPEL)

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

3.3. ビジネスルールのオーケストレーション

ビジネスルールオーケストレーションとは、Web サービスを介してビジネスプロセス内のアクションを指定する行為を指します。

3.4. Enterprise Service Bus

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

3.5. Apache ODE

Apache ODE (Orchestration Director Engine) は、BPEL ビジネスプロセスを実行するように設計されたソフトウェアコンポーネントです。Web サービスとの間でメッセージを送受信し、データを操作し、プロセス定義で規定された方法でエラー処理を実行します。Apache ODE の詳細については、プロジェクト Web サイト http://ode.apache.org/ にアクセスしてください。

3.6. プロセス定義

BPEL プロセス定義は、プロセスのテンプレートとして機能する XML ファイルです。公開されると、プロセス定義はそれ自体が Web サービスであるプロセスを作成します。

3.7. プロセスインスタンス

プロセスインスタンスは、プロセス定義の 1 つの実行です。

第4章 入門チュートリアル

4.1. JBoss Enterprise SOA Platform での BPEL プロセスの実行

はじめに

BPEL ESB Hello World クイックスタートは、ESB サービスが BPEL プロセスを直接呼び出す方法を示しています。

  1. BPEL エンジンと ESB は同じ JVM にあります。
  2. 呼び出された BPEL プロセスは、同じ ESB で実行されている BPEL エンジンインスタンスにデプロイされます。

4.2. BPEL ESB Hello World クイックスタートのデプロイ

手順4.1 BPEL ESB Hello World クイックスタートのデプロイ

  1. JBoss Enterprise SOA Platform サーバーが実行中であることを確認します。
  2. クイックスタートを含むディレクトリー cd SOA_ROOT/samples/quickstarts/bpel_helloworld (Microsoft Windows では chdir SOA_ROOT\samples\quickstarts\bpel_helloworld) に移動します。
  3. ant deploy を実行して、クイックスタートをデプロイします。
  4. ant runtest を実行して、クイックスタートをデプロイします。

結果

このコマンドは、Hello World via ESB to BPEL というテキストを ESB サービスに送信し、BPEL プロセスを呼び出します。これにより、テキストに Hello World が追加され、クライアントアプリケーションによって受信されるまでエコーバックされます。

4.3. Quickstart

クイックスタートはサンプルプロジェクトです。それぞれが、サービスの構築を支援するために特定の機能を使用する方法を示しています。SOA_ROOT/jboss-as/samples/quickstarts/ ディレクトリーには、数十のクイックスタートが含まれています。Apache Ant を使用して、すべてのクイックスタートをビルドしてデプロイします。

4.4. ant deploy

ant deploybuild ディレクトリーにあるクイックスタートのソースコードをコンパイルし、サーバープロファイルの deploy ディレクトリーに .ESB ファイル (Quickstart_helloworld.esb など) を生成します。(BPEL クイックスタート用の .JAR ファイルが生成されることに注意してください。) サーバーは新しい .esb アーカイブの存在を検出し、デプロイします。.ESB アーカイブには、ant deploy がキューを設定するために使用する deployment.xml ファイルがあります。
また、ant deploy は、XSL テンプレートを使用して、汎用 JMS キュー名をターゲットサーバーのメッセージングプロバイダーが必要とする特定の JMS キューに変換します。Ant は、メッセージングプロバイダーのデプロイメントのサーバーを調べて、正しいメッセージングプロバイダーを選択します。ビルドスクリプトによって検出されるのは、JBoss Messaging、JBoss MQ、および HornetQ のみです。他のメッセージングプロバイダーは、クイックスタートではサポートされていません。次に、Ant は deployment.xml ファイルを build/META-INF ディレクトリーに配置してから、他のクイックスタートと同じ .ESB アーカイブに含めます。

4.5. ant runtest

ant runtest は、ESB 非対応の "Hello World" メッセージ (プレーンな String オブジェクト) を JMS キュー (queue/quickstart_helloworld_Request_gw) に送信します。このコマンドは、Java に送信側クラスを実行するように指示します ("Hello World" クイックスタートの場合、これは org.jboss.soa.esb.samples.quickstart.helloworld.test.sendJMSMessage と呼ばれます)。そうすることで、デプロイされたプロセスにメッセージを直接送信します。

第5章 プロセスの管理

5.1. プロセスのデプロイ

BPEL プロセスをデプロイするには、2 つの方法があります。
  1. JBoss Developer Studio 経由
  2. 直接 (サンプルのクイックスタートでは、この方法を使用します)。

5.2. JBoss Developer Studio を使用したプロセスのデプロイ

前提条件

  • JBoss Developer Studio

手順5.1 タスク

  1. JBoss Developer Studio を起動します。
  2. JBDS BPEL プロジェクトを作成またはインポートします。
    (この例では、SOA_ROOT/jboss-as/samples/quickstart/bpel_esb_helloworld ディレクトリーから既存のプロジェクトをインポートします)。
    Import メニュー項目 (JBDS の左側のナビゲーションパネル -> General -> Existing Projects into Workspace -> Next) を選択します。
  3. Browse ボタンをクリックします。
  4. bpel_esb_helloworld クイックスタートディレクトリーに移動します。
    注記
    プロジェクトがインポートされると、BPEL プロセスや WSDL の記述など、その内容を検査できます。
  5. JBoss Enterprise SOA Platform のサーバー設定を作成します。(Server タブは、JBDS ウィンドウの下部領域に表示されます。存在しない場合は、Window->Show Views->Servers をクリックします。)
  6. Servers ビューで右クリックし、New->Server を選択します。
  7. JBoss Enterprise SOA Platform の適切なバージョンを選択します。
  8. Finish をクリックします。
  9. Servers タブでサーバーを右クリックし、Start を選択して、新しいサーバーを起動します。
    サーバーからの出力は Console タブに表示されます。
  10. サーバーが起動したら、サーバーエントリーを再度右クリックし、Add and Remove->bpel_esb_helloworld を選択します。
  11. Add->Finish をクリックします。
    プロジェクトがサーバーにデプロイされます。(Servers タブのサーバーの下にエントリーとして表示されます。)
  12. クイックスタートサンプルで提供されている Ant スクリプトを使用して、デプロイされた BPEL プロセスをテストします。プロジェクトのルートフォルダーの build.xml ファイルを右クリックし、Run As->Ant Build を選択します。
    注記
    ... が付いたメニュー項目を選択することが重要です。これにより、使用する Ant ターゲットを選択できるダイアログボックスが起動するためです。
  13. deploy ターゲットの選択を解除します。
  14. runtest ターゲットを選択します。
  15. Run ボタンをクリックします。
    テスト用の hello メッセージがサーバーに送信され、応答が Console タブに表示されます。
  16. BPEL プロセスを更新するには、assignHelloMesg->Properties->Details->Expression to Variable を選択します。
    テキストに UPDATED を追加するなどのタスクを実行するために、concat 関数の 2 番目のパラメーターを更新できます。
  17. 更新を保存します。
  18. Server ビューに移動します。
  19. bpel_esb_helloworld>Full Publish をクリックします。
    プロジェクトが再デプロイされます。
  20. 新しいリクエストを送信して新しいレスポンスを表示するには、build.xml ファイル内で runtest ターゲットを再実行します。
    これで、BPEL プロセスで行った変更がレスポンスに反映されます。
  21. Server ビューに移動し、デプロイされたプロジェクトノードを展開します。
    デプロイされたバージョンの両方が表示されます。(そのバージョンのプロセスを使用する BPEL プロセスインスタンスがまだ存在する可能性があるため、古いバージョンが保持されます。)
  22. Server ビューのプロジェクトメニューを使用し、Add and Remove をクリックしてプロジェクトをアンデプロイします。
    警告
    各子ノードを右クリックすると、特定のバージョンをアンデプロイすることもできます。ただし、バージョンを手動でアンデプロイすると、そのバージョンの残りのアクティブなプロセスインスタンスはすべて終了します。
  23. Server メニュー項目に移動し、サーバーを停止します。

5.3. JBoss Developer Studio を使用したプロセスのテスト

前提条件

  • JBoss Developer Studio

手順5.2 タスク

  1. JBoss Developer Studio を起動します。
  2. プロセスを右クリックし、WSDL を選択します。
  3. Web Services をクリックします。
  4. Test with Web Service Explorer をクリックします。
  5. JBoss Developer Studio を起動します。

5.4. 直接アプローチを使用したプロセスのデプロイ

手順5.3 タスク

  1. テキストエディターでプロセスの Apache Ant ビルドスクリプトを開きます。
  2. 適切に変更します。以下に例を示します。
    <!-- Import the base Ant build script... -->
    	<property file="../../../install/deployment.properties" />
    	
    	<property name="version" value="1" />
    	
    	<property name="server.dir" value="${org.jboss.as.home}/server/${org.jboss.as.config}"/>
    	<property name="conf.dir" value="${server.dir}/conf"/>
    	<property name="deploy.dir" value="${server.dir}/deploy"/>
    	<property name="server.lib.dir" value="${server.dir}/lib"/>
    
    	<property name="sample.jar.name" value="${ant.project.name}-${version}.jar" />
    	
    	<target name="deploy">
    		<echo>Deploy ${ant.project.name}</echo>
    		<jar basedir="bpel" destfile="${deploy.dir}/${sample.jar.name}" />
    	</target> 
     
    	<target name="undeploy">
    		<echo>Undeploy ${ant.project.name}</echo>
    		<delete file="${deploy.dir}/${sample.jar.name}" />
    </target>
    
  3. ファイルを保存して終了します。

5.5. プロセスの直接デプロイメントに関するポイント

  • BPEL プロセスがデプロイされる JBoss Enterprise SOA Platform Server の場所を提供する必要があります。(この例では、これは、インストールディレクトリーにある deployment.properties ファイルを参照することによって実現されます。
  • 同じ BPEL プロセスの複数のバージョンを一度にデプロイする バージョン管理アプローチ を取ることができます。BPEL プロセスと関連するアーティファクトを含む JAR アーカイブファイルの名前には、バージョン番号の接尾辞が付きます。異なるバージョンの BPEL プロセスをデプロイするたびに、この接尾辞番号を手動で増やす必要があります。
    警告
    現在、バージョンは単一の整数として指定する必要があります。major.minor.incremental (Maven スタイル) 形式で表示される数値などの非数値は、例外をトリガーします。
  • BPEL プロセスアーカイブの作成に使用するデプロイメントターゲットを定義する必要があります。bpel サブディレクトリーのコンテンツを使用してこれを行い、JBoss Enterprise SOA Platform の SOA_ROOT/jboss-as/server/PROFILE/deploy ディレクトリー内に保存します。
  • 最後に、アンデプロイメントターゲットを定義する必要があります。これは、JBoss Enterprise SOA PlatformSOA_ROOT/jboss-as/server/PROFILE/deploy ディレクトリーから BPEL プロセスアーカイブを削除するためにのみ使用されます。

5.6. プロセスの削除

警告
アクティブなプロセス定義を削除 (アンデプロイ) すると、そのプロセスインスタンスのすべてが終了します。これが発生しないようにする場合は、最初にプロセス定義を廃止する必要があります。

手順5.4 タスク

  1. プロセスにアクティブなプロセスインスタンスがあるかどうかを確認します。
  2. 存在する場合は、BPEL Web コンソールを使用して、まずそれらを廃止してください。
  3. アクティブなプロセスインスタンスがなくなった場合にのみ、プロセスを削除します。

5.7. エンドポイント参照の設定とデプロイ

手順5.5 タスク

  1. サンプルのエンドポイントファイル vi SOA_ROOT/jboss-as/samples/quickstart/hello_world/bpelContent/test.endpoint を作成します。
  2. 以下の内容を追加します。
    # 3 minutes
    mex.timeout=180000
    
  3. ファイルを保存して終了します。
    デプロイされると、helloworld の例は応答するまで最大 3 分間待機します。
  4. これをテストするには、hello_world.bpel ファイルを編集し、レスポンスの前に wait アクティビティーを挿入します。
    <wait>
    	<for>'PT150S'</for>
    </wait>
    
    これにより、応答するまで 2 分 30 秒待機するようになります。これは、デフォルトのタイムアウトよりも 30 秒長くなりますが、test.endpoint ファイル内で指定された新しいタイムアウト期間の制限内に収まります。
  5. ファイルを保存して終了します。
  6. 強制的にタイムアウトを発生させたい場合は、待機時間を 3 分 30 秒に増やし、ant runtest コマンドを使用してテストメッセージを再送信します。
    注記
    BPEL Web コンソールはまだグローバル設定ファイルをサポートしていないため、デプロイされた BPEL バンドルからのみ設定データを取得できます。(具体的には、BPEL デプロイメント記述子とともに BPEL デプロイメントユニット内のルートの場所を調べます。)

5.8. サポート対象のエンドポイント参照設定プロパティー

BPEL Web Console は、次のプロパティーをサポートしています。
  • mex.timeout

第6章 Web サービスの設定

6.1. Web サービス

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

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

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

6.3. Web Services Description Language (WSDL)

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

6.4. Web サービススタック

Web サービススタックは、ソフトウェアのレイヤーです。そのロールは、Web サービスを BPEL プロセスで使用できるようにすることです。

6.5. Java API for XML Web Services (JAX-WS)

Java API for XML Web Services (JAX-WS) は、Web サービスを作成できる Java API です。JAX-WS ハンドラーメカニズムは、メッセージ (または障害) が送信または受信されるたびに、ユーザー指定のクラスを呼び出すために Web サービスによって使用されます。したがって、ハンドラーはメッセージパイプラインにインストールされ、必要に応じてメッセージヘッダーまたは本文を操作するために使用されます。

6.6. JAX-WS ハンドラーと BPEL

BPEL は JAX-WS API を介して JBossWS と統合します。これにより、BPEL は JBossWS ネイティブと Apache CXF Web サービススタックの両方をサポートできます。通常、ハンドラーは、プログラム、または Web サービスを表す Java インターフェイスの HandlerChain アノテーションを使用して、インストールします。ただし、BPEL にデプロイされたプロセスの場合、JAX-WS サービスはデプロイ時に動的に作成されます。

6.7. BPEL の JAX-WS ハンドラーの設定

手順6.1 タスク

  1. BPEL プロセス定義とデプロイメント記述子を配置した場所に移動します。
  2. jws_handler.xml: vi jws_handler.xml というファイルを作成します。
  3. 設定をファイルに追加します。以下に、bpel_service_handler クイックスタートに関する例を示します。
    <handler-chains xmlns="http://java.sun.com/xml/ns/javaee" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xsi:schemaLocation="http://java.sun.com/xml/ns/javaee">
        <handler-chain>
      <handler>
       <handler-name>JAXWSHandler</handler-name>
       <handler-class>org.jboss.soa.bpel.examples.jaxws.JAXWSHandler</handler-class>
       <init-param>
           <param-name>TestParam</param-name>
           <param-value>TestValue</param-value>
       </init-param>
      </handler>
        </handler-chain>
    </handler-chains>
    
    このファイルは、標準の JAX-WS ハンドラーチェーン設定形式です。1 つ以上のハンドラー要素を指定でき、各ハンドラーは名前とクラスを定義します。(ハンドラー設定は、オプションでハンドラー実装の init メソッドに渡される初期化パラメータを提供できます。)
  4. ファイルを保存して終了します。
    注記
    このメカニズムは、プロバイダー Web サービスに JAX-WS ハンドラーのみをインストールします。現在、BPEL プロセスから外部 Web サービスを呼び出すために使用されるクライアントエンドポイントの JAX-WS ハンドラーを設定することはできません。
    注記
    詳細については、service_handler クイックスタートで提供されるこのメカニズムの例を調べてください。

6.8. jws_handler.xml

jws_handler.xml は JAX-WS API の XML ベースの設定ファイルです。

6.9. Apache CXF

Apache CXF は、サービス指向アーキテクチャー (SOA) を開発するためのオープンソースフレームワークです。CXF は、JAX-WS や JAX-RS などのフロントエンドプログラミング API を使用してサービスを構築および開発するのに役立ちます。これらのサービスは、SOAP、XML/HTTP、RESTful HTTP、CORBA などのさまざまなプロトコルを使用でき、HTTP、JMS、JBI などのさまざまなトランスポートで機能します。
CXF の詳細については、http://cxf.apache.org/docs/ を参照してください。

6.10. サーバーエンドポイントとして使用する Apache CXF の設定

前提条件

  • Apache CXF

手順6.2 タスク

  1. BPEL デプロイメント記述子を含むディレクトリーに移動します。
  2. jbossws-cxf.xml: vi jbossws-cxf.xml というファイルを作成します。
  3. 設定をファイルに追加します。以下に例を示します。
     
    <beans
      xmlns='http://www.springframework.org/schema/beans'
      xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
      xmlns:beans='http://www.springframework.org/schema/beans'
      xmlns:jaxws='http://cxf.apache.org/jaxws'
      xsi:schemaLocation='http://cxf.apache.org/core
        http://cxf.apache.org/schemas/core.xsd
        http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
        http://cxf.apache.org/jaxws
        http://cxf.apache.org/schemas/jaxws.xsd'>
      
      <bean id="UsernameTokenSign_Request"
         class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
        <constructor-arg>
          <map>
            <entry key="action" value="UsernameToken Timestamp Signature"/> 
            <entry key="passwordType" value="PasswordDigest"/>
         <entry key="user" value="serverx509v1"/>
            <entry key="passwordCallbackClass"
              value="org.jboss.test.ws.jaxws.samples.wsse.ServerUsernamePasswordCallback"/> 
            <entry key="signaturePropFile" value="etc/Server_SignVerf.properties"/>
            <entry key="signatureKeyIdentifier" value="DirectReference"/>
          </map>
        </constructor-arg>
      </bean>
      
      <bean id="UsernameTokenSign_Response"
         class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
        <constructor-arg>
          <map>
            <entry key="action" value="UsernameToken Timestamp Signature"/> 
            <entry key="passwordType" value="PasswordText"/>
         <entry key="user" value="serverx509v1"/>
            <entry key="passwordCallbackClass"
              value="org.jboss.test.ws.jaxws.samples.wsse.ServerUsernamePasswordCallback"/> 
            <entry key="signaturePropFile" value="etc/Server_Decrypt.properties"/>
            <entry key="signatureKeyIdentifier" value="DirectReference"/>
            <entry key="signatureParts"
              value="{Element}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp;{Element}{http://schemas.xmlsoap.org/soap/envelope/}Body"/>
          </map>
        </constructor-arg>
      </bean>
    
      <jaxws:endpoint
        id='SecureHelloWorldWS'
        address='http://@jboss.bind.address@:8080/Quickstart_bpel_secure_serviceWS'
        implementor='@provider@'>
        <jaxws:inInterceptors>
            <ref bean="UsernameTokenSign_Request"/>
            <bean class="org.apache.cxf.binding.soap.saaj.SAAJInInterceptor"/>
        </jaxws:inInterceptors>
        <jaxws:outInterceptors>
            <ref bean="UsernameTokenSign_Response"/>
            <bean class="org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor"/>
        </jaxws:outInterceptors>
      </jaxws:endpoint>
      
      
    </beans>
    
    このコード例では、ユーザー名 トークンデジタル署名認証 と組み合わせて使用するように Web サービスを設定します。
    注記
    jaxws:endpoint 要素には、 implementor という属性があります。この属性は、JAX-WS サービスを実装する Java クラスを定義します。BPEL コンソールは、このクラスを自動的に動的に作成します。したがって、属性を値 @provider@ に設定することが重要です。そうしないと、機能しません。
  4. ファイルを保存して終了します。

6.11. jbossws-cxf.xml

jbossws-cxf.xml はユーザー作成の XML ベースの設定ファイルです。デプロイメント記述子とともに、プロジェクトの /WEB-INF/ フォルダーに配置する必要があります。これを使用して、Apache CXF をサーバーエンドポイントとして設定します。また、JAX-WS アノテーションの使用に基づいて Web サービスをデプロイする際に jbossws-cxf によって使用されます。

6.12. デプロイメント記述子

デプロイメント記述子は、デプロイ可能なシステムアーティファクト用の XML ベースの設定ファイルです。アーティファクトをデプロイする方法と場所が記述されています。このファイルでは、さまざまなオプションとセキュリティー設定を指定できます。

6.13. jbossws-cxf-portname_local_part.xml

BPEL によって呼び出される Web サービスを表すクライアントエンドポイントのさまざまな設定設定は、現在、ポートごとに異なるファイルに分散されています。
これらのファイルは、jbossws-cxf-{portname_local_part}.xml という命名規則に従います。ここで、portname_local_part は、呼び出される Web サービスのポート名のローカル部分を表します。

6.14. Apache CXF クライアントエンドポイントの WSDL の例

<definitions name='SecureHelloWorldWSService'
  targetNamespace='http://secure_invoke/helloworld' .... >
    <portType name='SecureHelloWorld'>
        ...
    </portType>
    <service name='SecureHelloWorldWSService'>
       <port name='SecureHelloWorldPort' ... >
           ...
       </port>
    </service>
</definitions>

6.15. クライアントエンドポイントとして使用する Apache CXF の設定

前提条件

  • Apache CXF

手順6.3 タスク

  1. サンプルの jbossws-cxf-SecureHelloWorldPort.xml CXF 設定ファイルを編集するには、vi SOA_ROOT/jboss-as/samples/quickstarts/bpel_secure_invoke/bpelContent/jbossws-cxf-SecureHelloWorldPort.xml コマンドを実行します。
  2. このファイルに含まれる設定情報は、CXF バス用です。次のようにファイルを編集します。
    <beans xmlns="http://www.springframework.org/schema/beans"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xmlns:cxf="http://cxf.apache.org/core"
           xmlns:wsa="http://cxf.apache.org/ws/addressing"
           xmlns:http="http://cxf.apache.org/transports/http/configuration"
           xmlns:wsrm-policy="http://schemas.xmlsoap.org/ws/2005/02/rm/policy"
           xmlns:wsrm-mgr="http://cxf.apache.org/ws/rm/manager"
        xmlns:beans='http://www.springframework.org/schema/beans'
        xmlns:jaxws='http://cxf.apache.org/jaxws'
        xmlns:ns1='http://secure_invoke/helloworld'
           xsi:schemaLocation="
           http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
           http://cxf.apache.org/transports/http/configuration http://cxf.apache.org/schemas/configuration/http-conf.xsd
           http://schemas.xmlsoap.org/ws/2005/02/rm/policy http://schemas.xmlsoap.org/ws/2005/02/rm/wsrm-policy.xsd
           http://cxf.apache.org/ws/rm/manager http://cxf.apache.org/schemas/configuration/wsrm-manager.xsd
           http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
     http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd">
    
      <bean id="UsernameTokenSign_Request"
         class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor" >
        <constructor-arg>
          <map>
            <entry key="action" value="UsernameToken Timestamp Signature"/> 
            <entry key="passwordType" value="PasswordDigest"/>
      <entry key="user" value="clientx509v1"/>
            <entry key="passwordCallbackClass"
              value="org.jboss.test.ws.jaxws.samples.wsse.ClientUsernamePasswordCallback"/> 
            <entry key="signaturePropFile" value="etc/Client_Sign.properties"/>
            <entry key="signatureKeyIdentifier" value="DirectReference"/>
            <entry key="signatureParts"
              value="{Element}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp;{Element}{http://schemas.xmlsoap.org/soap/envelope/}Body"/>
          </map>
        </constructor-arg>
      </bean>
      
      <bean id="UsernameTokenSign_Response" 
         class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor" >
        <constructor-arg>
          <map>
            <entry key="action" value="UsernameToken Timestamp Signature"/> 
            <entry key="passwordType" value="PasswordText"/>
         <entry key="user" value="serverx509v1"/>
            <entry key="passwordCallbackClass" 
              value="org.jboss.test.ws.jaxws.samples.wsse.ClientUsernamePasswordCallback"/> 
            <entry key="signaturePropFile" value="etc/Client_Encrypt.properties"/>
            <entry key="signatureKeyIdentifier" value="DirectReference"/>
          </map>
        </constructor-arg>
      </bean>
      
      <cxf:bus>
        <cxf:outInterceptors>
            <ref bean="UsernameTokenSign_Request"/>
            <bean class="org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor"/>
        </cxf:outInterceptors>
        <cxf:inInterceptors>
            <ref bean="UsernameTokenSign_Response"/>
            <bean class="org.apache.cxf.binding.soap.saaj.SAAJInInterceptor"/>
        </cxf:inInterceptors>
      </cxf:bus>
    
    </beans>
    
    これらの設定により、Web サービスクライアントがユーザー名トークンとデジタル署名認証を使用するように設定されます。
  3. ファイルを保存して終了します。

6.16. BPEL プロセスと Web サービス

BPEL プロセスをデプロイすると、Web サービスが自動的に作成されます。この Web サービスはサービスエンドポイントを表し、デプロイされるプロセスにバンドルされている WSDL 記述に基づいています。

6.17. WSDL の表示

手順6.4 タスク

  1. ?wsdl 接尾辞が付いたサービスのエンドポイント URL を検索します。
  2. 表示されると、<soap:address> はデフォルトでサーバーのホストバインドアドレスに関連付けられます。
    注記
    このアドレスは ${jboss.bind.address} プロパティーに定義されています。

6.18. セキュアな外部 Web サービスを呼び出すように BPEL クライアントエンドポイントを設定する

手順6.5 タスク

  1. テストエディターを起動し、新しいファイルを作成します。
  2. key-store ファイルと trust-store ファイルの相対的な場所を追加します。
  3. ファイルを BPEL プロセスとともに最上位ディレクトリーに jboss-wsse-client.xml として保存し、終了します。
    注記
    詳細については、secure_invoke_native クイックスタートを参照してください。

6.19. セキュアな Web サービスを提供するように BPEL サーバーエンドポイントを設定する

手順6.6 タスク

  1. テストエディターを起動し、新しいファイルを作成します。
  2. key-store ファイルと trust-store ファイルの相対的な場所を追加します。
  3. ファイルを BPEL プロセスとともに最上位ディレクトリーに jboss-wsse-server.xml として保存し、終了します。
    注記
    詳細については、secure_service_native クイックスタートを参照してください。

第7章 高度な BPEL エンジンの統合

7.1. 双方向の疎結合

双方向の疎結合は、Web サービスを通じて提供されます。たとえば、ESB アクションは、Web サービスを介して BPEL プロセスを呼び出すことができます。この Web サービスは WSDL インターフェイスで表されます。同様に、BPEL プロセスは、それ自体を Web サービスとして提供できる ESB 管理サービスを呼び出すことができます。

7.2. Enterprise Service Bus

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

7.3. BPELInvoke ESB アクションの使用

前提条件

  • BPEL エンジンは、ESB と同じ Java 仮想マシンにインストールする必要があります。
  • 要求されたプロセスは、ローカル BPEL エンジンにデプロイされている必要があります。

手順7.1 タスク

  1. テキストエディターで jboss-esb.xml ファイルを開きます。
  2. を追加します。 BPELInvoke 動作。
    以下の例は、bpel_esb_helloworld クイックスタートとともに使用されているアクションを示しています。
          <action name="action2" class="org.jboss.soa.esb.actions.bpel.BPELInvoke">
        <property name="service" value="{http://www.jboss.org/bpel/examples/wsdl}HelloService"/>
        <property name="port" value="HelloPort" />
        <property name="operation" value="hello" />
        <property name="requestPartName" value="TestPart" />
        <property name="responsePartName" value="TestPart" />
    </action>
    
  3. ファイルを保存して終了します。

7.4. BPELInvoke ESB アクションクラス

BPELInvoke ESB アクションクラス (org.jboss.soa.esb.actions.bpel.BPELInvoke) を使用して、ESB サービス内から BPEL エンジンを呼び出すことができます。

7.5. BPELInvoke ESB アクションクラスのプロパティー

表7.1 プロパティー

プロパティー 説明
service
このプロパティーは必須です。デプロイされた BPEL プロセスに関連付けられている WSDL に登録されているサービス名を定義します。
port
このプロパティーはオプションです。WSDL に登録されているデプロイ済み BPEL プロセスに関連付けられたポートの名前を定義します。このパラメーターは、ポート固有のエンドポイント設定情報が BPEL プロセスデプロイメントの一部として登録されている場合にのみ必要です。
operation
このプロパティーは必須です。これは、呼び出される WSDL 操作を表します。
requestPartName
このオプションのプロパティーを使用して、インバウンド ESB メッセージコンテンツがマップされる WSDL メッセージ部分を定義します。このプロパティーは、ESB メッセージがまだマルチパートメッセージを表していない場合にのみ使用してください。
responsePartName
このオプションのプロパティーを使用して、レスポンスマルチパート WSDL メッセージのコンテンツを抽出し、パイプラインの次のアクションに渡される ESB メッセージに配置します。(このプロパティーが定義されていない場合、完全なマルチパートメッセージ値が ESB メッセージに配置されます。)
abortOnFault
このオプションのプロパティーを使用して、BPEL プロセスの呼び出し中に発生した障害をメッセージとして処理するか (このプロパティーの値が false の場合)、ESB サービスを中断する例外として処理するかを示します。デフォルト値は true で、サービスを中断します。
この ESB アクションは、インバウンドメッセージをサポートします。これらのメッセージの内容は、以下の項目のいずれかとして定義する必要があります。

表7.2 プロパティー

項目 説明
DOM
メッセージコンテンツが DOM ドキュメントまたは要素である場合、完全なマルチパートメッセージとして、またはメッセージ部分のコンテンツとして使用できます。 requestPartName プロパティーを使用して、定義します。
Java String
メッセージコンテンツが XML ドキュメントの文字列表現である場合、 requestPartName はオプションです。指定しない場合、ドキュメントはマルチパートメッセージを表す必要があります。
メッセージコンテンツが XML ドキュメントを表現しない文字列である場合は、 requestPartName を指定する必要があります。
メッセージコンテンツが マルチパートメッセージ のすべての部分を表す場合、最上位要素として定義する必要があります (任意の名前を付けることができます)。子要素は、メッセージの各部分を表すため、すぐ下に配置する必要があります。これらの子要素はそれぞれ、独自の 1 つの子要素を持つ必要があります。この要素は、名前付きの部分の値を表します。
これはマルチパートメッセージの構造です。
<message>
	<TestPart>
		Hello World
	</TestPart>
</message>
最上位の要素 (メッセージタグ) は重要ではありません。次のレベルの要素は部分名を表します。この場合は、1 つだけ、つまり、TestPart があります。この部分はテキストノードであり、この場合は、Hello World と呼ばれます。(ただし、より複雑な XML 値のルートノードを表す要素である可能性もあります。)

7.6. BPELInvoke とアクションパイプライン

WSDL 操作が実行されると、通常応答メッセージが から返されます。 BPELInvoke アクション。このメッセージは、次のアクションで処理できるようにアクションパイプラインに配置されます。(それ以上のアクションが定義されていない場合は、サービスクライアントに返されます。)

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

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

第8章 BPEL と REST

8.1. BPEL コンソール RESTful サービス

これは、BPEL コンソールで使用される Restful サービスのリストです。

表8.1 BPEL コンソール RESTful サービス

メソッド
パス
Description
消費されるアイテム
生成されるアイテム
サーバー情報 (一般的な REST サーバー情報)
GET
/gwt-console-server/rs/server/status
*/*
application/json
-
GET
/gwt-console-server/rs/server/resources/{project}
*/*
text/html
プロセス管理 (プロセス関連データ)
GET
/gwt-console-server/rs/process/definitions
*/*
application/json
-
GET
/gwt-console-server/rs/process/definition/{id}/instances
*/*
application/json
-
GET
/gwt-console-server/rs/process/instance/{id}/dataset
*/*
text/xml
-
POST
/gwt-console-server/rs/process/instance/{id}/end/{result}
*/*
application/json
-
GET
/gwt-console-server/rs/process/definition/{id}/image
*/*
image/*
-
GET
/gwt-console-server/rs/process/definition/{id}/image/{instance}
*/*
image/*
プロセスエンジン (プロセスランタイム状態)
GET
/gwt-console-server/rs/engine/deployments
*/*
application/json
プロセス履歴 (プロセス履歴サービス)
GET
/gwt-console-server/rs//history/definition/{id}/instances
*/*
applications/json
-
GET
/gwt-console-server/rs//history/definitions
*/*
application/json
-
GET
/gwt-console-server/rs//history/definition/{id}/instances
*/*
application/json
-
GET
/gwt-console-server/rs//history/instance/{id}/activities
*/*
application/json
-
GET
/gwt-console-server/rs//history/instance/{id}/events
*/*
application/json
-
GET
/gwt-console-server/rs//history/definition/{id}/instances/completed
*/*
application/json
-
GET
/gwt-console-server/rs//history/definition/{id}/instances/failed
*/*
application/json
-
GET
/gwt-console-server/rs//history/definition/{id}/instances/terminated
*/*
application/json
-
GET
/gwt-console-server/rs//history/definition/{id}/instances/chart/completed
*/*
application/json
-
GET
/gwt-console-server/rs//history/definition/{id}/instances/chart/failed
*/*
application/json

第9章 障害処理

9.1. BPELInvoke 障害処理

システムの設定方法に応じて、障害を ESB メッセージとして受信するか、アクションパイプラインを中止する例外を発生させることができます。使用する動作を決定する設定プロパティーは、 abortOnFault と呼ばれます。このプロパティーのデフォルト値は true です。

9.2. BPELInvoke 障害処理リファレンス

次のサンプルマテリアルでは、Loan Fault クイックスタートを使用しています。
        <action name="action2" class="org.jboss.soa.esb.actions.bpel.BPELInvoke">
 	<property name="service" value="{http://example.com/loan-approval/wsdl/}loanService"/>
	<property name="operation" value="request" />
	<property name="abortOnFault" value="true" />
</action>
WSDL 障害は、障害タイプと障害の詳細という 2 つの情報を報告します。これらはそれぞれ、メッセージの本文の別の部分で返されます。
  1. 障害コード: javax.xml.namespace.QName
    ESB メッセージ本文部分: org.jboss.soa.esb.message.fault.detail.code
    この本文部分は、BPEL プロセスによって返された特定の WSDL 障害を識別します。
    警告
    JBoss Enterprise SOA Platform サーバーが使用する QName のバージョンは lib/endorsed/stax-api.jar ファイルにあります。(このファイルが存在しない場合、クラスバージョンの例外が発生します。)
  2. 障害コード (QName のテキスト表現として)。
    ESB メッセージ本文部分: org.jboss.soa.bpel.message.fault.detail.code
    この本文部分は、障害コードの QName のテキスト表現を返します。この表現の形式は {namespace}localpart です。(QName に戻すには、 javax.xml.namespace.QName.valueOf(String) メソッドを使用します。)
  3. 障害の詳細
    ESB メッセージ本文部分: org.jboss.soa.esb.message.fault.detail.detail
    この本文部分には、障害に関連付けられたメッセージコンテンツのテキスト表現が含まれます。

第10章 SAML サポート

10.1. Security Assertion Markup Language (SAML)

Security Assertion Markup Language (SAML) は、ID プロバイダーとサービスまたはコンシューマーの間でセキュリティーデータを交換するための XML ベースの OASIS 標準メソッドです。

10.3. SAML トークン

SAML トークンは、アイデンティティープロバイダーと Web サービスの間でエンドユーザーに関する情報を渡すように設計されています。

10.4. BPEL での SAML サポート

ESB サービスが PicketLink を使用して SAML トークンを取得する場合、このアサーションは、 requestSAMLPartName によって、呼び出された BPEL プロセスに渡すことができます。
        <action name="action2" class="org.jboss.soa.esb.actions.bpel.BPELInvoke">
	<property name="service" value="{http://simple_invoke/helloworld}HelloHeaderWSService"/>
	<property name="operation" value="sayHi" />
	<property name="requestPartName" value="sayHello" />
	<property name="responsePartName" value="sayHelloResponse" />
	<property name="requestSAMLPartName" value="Security" />
</action>
requestSAMLPartName はメッセージ部分の名前を識別します。この部分を WS-Security 要素として定義する必要があります。
<part name="Security" element="wsse:Security"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" />

付録A 更新履歴

改訂履歴
改訂 5.3.1-93.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
改訂 5.3.1-93Tue Feb 05 2013 David Le Sage
dlesage によりコンテンツ仕様: 6892、リビジョン: 371689 からビルド