この記事はIBM® WebSphere® Process Server V6.2で加わった新規フィーチャーおよび機能について説明し、その動作の仕組みを例で説明します。WebSphere Process Server V6.2では柔軟性がさらに拡張され、プロセス・インスタンスのコントロール、シンプルで効率性のよいアプリケーション・デプロイメント方法の提供、そして最新テクノロジーと標準がサポートされるようになります。
IBM Business Process Management Journal (US)にて原文が紹介されています。

はじめに

2008年10月1日に、IBMはWebSphere Process Server V6.2を発表しました (訳注. 日本では2008年10月2日)。企業向けのビジネス・プロセス・マネージメント(BPM)アプリケーションを実現する、パワフルなソフトウェア・プラットフォームです。今回発表された新しいリリースでは柔軟性がさらに拡張され、プロセス・インスタンスのコントロール、シンプルで効率性のよいアプリケーション・デプロイメント方法の提供、そしてSOAP 1.2 などの最新テクノロジーと標準をサポートし、WebSphere Application Server Web サービス・フィーチャー・パックをサポートします。WebSphere BPM向けWeb2.0フロントエンドとして提供される、ビジネス・スペース powered by WebSphere には、新規ウィジェットの追加と機能拡張が行なわれました。いくつかのプラットフォームは最新バージョンに対応するようになりました。これはWebSphere Adapters V6.2 に対しても同様です。WebSphere ESBとの統合についてもアップデートされ、WebSphere Services Registry and Repositoryとの統合を含んだポリシー・メカニズムをサポートするようになりました。

なお、この記事はWebSphere Process Server V6.2 ベータ・リリースを元に記述されています。

WebSphere Business Modelerでデザインからデプロイまで行なう

これまでのWebSphere BPM製品で行なっていたプロセス作成のライフサイクルは、WebSphere Business Modelerでビジネス・モデリングを行ないエクスポートされ、WebSphere Process Server にデプロイするまえに、WebSphere Integration Developerにてサービスをアセンブリーしていました。WebSphere Process Server V6.2では新しく、ダイレクト・デプロイ機能が利用可能になりました。これはWebSphere Business ModelerのユーザーがモジュールをWebSphere Process Serverランタイムに直接デプロイすることができる機能です。

この新しく加わった実行能力はWebSphere Business Modelerを利用するビジネス・ユーザーが自ら設計したビジネス・プロセスをテスト検証することができるため、ビジネス要件が提出されてからビジネス・プロセスを実行可能なものにするまでの時間を短縮できるようになります。一方でIT部門は、トレーサビリティとガバナンスを維持しつつ、複雑な問題判別が起きたときにのみ対応すればよいようになります。

Web インターフェースの拡張

WebSphere Process Server V6.2 のWebインターフェースは、柔軟に選択することができます。V6.2になり、そのインターフェースにも様々な拡張が行なわれました。

ビジネス・スペースの拡張

ビジネス・スペース powered by WebSphereはWeb 2.0アプリケーションです。WebSphere BPM suite製品各々が専用のウィジェット・アプリケーションを同梱しています。ユーザーはこのウィジェットと呼ぶアプリケーションを使って、自分用のスペースを作成できます。WebSphere Process Server V6.2 には、機能が拡張されたワーク・リストとタスク管理向けウィジェットが同梱されており、ワークフロー・ダイヤグラム内にビジネス・プロセスやタスクの実行履歴が表示されるようになりました。またウィジェット機能を拡張して、アドホックなサブ・タスクを利用するダイナミックなプロセス・シナリオに対応できるようになり、その状況の表示、作成、編集、キャンセル、確認ができるようになりました。

またビジネス・カレンダー・マネージャーと呼ばれる、新たなウィジェットがビジネス・スペースに追加されました。このウィジェットを使うとユーザーは、ビジネス運用に使用されるカレンダー・イベント情報をメンテナンスすることができます。図 1にあるように、カレンダー情報の追加、削除、更新の権限をユーザーに与えることができます。

図 1. ビジネス・カレンダー・マネージャー
ビジネス・カレンダー・マネージャー

セキュリティ管理ウィジェットが新たに追加されました。これによりビジネス・カレンダー・マネージャー・ウィジェット用にセキュリティ・ロールを構成できます。BPMAdmin というIDは、BPMRoleManagerロールによってメンバー追加、削除する権限を持ちます。これはリソース・ロールの代わりに利用されます。

図 2 にあるようにヘルス・モニタリング・ウィジェットが新たに追加され、システム・アプリケーション、トポロジー、ユーザー・アプリケーション、メッセージング、キューの深さに対してヘルス情報の統計を行ないます。アプリケーションをいくつもチェックしなくても、管理者は一画面で一度に全てのヘルス情報を確認することができます。

図 2. ヘルス・モニター・ウィジェット
ヘルス・モニター・ウィジェット

タスク情報ウィジェットが拡張され、アドホック・シナリオ用にサブ・タスクを利用できるようになりました。サブ・タスクを作成して他ユーザーに割り当てる、サブ・タスクを見る、その状況を見る、といったことができます。MyTasksウィジェットは、保留中のサブ・タスク状況を見ることができます。またサブ・タスクをキャンセルすることができるほか、完了したサブ・タスク結果を見ることができます。図 3 にあるように、タスク情報ウィジェット内でタスクをひとつ選んでからアクション・メニューからNewを選択することで、サブ・タスクが作成できます。

図 3. サブ・タスクを作成する
サブ・タスクを作成する

サブ・タスクが作成されると、タスク情報ウィジェットでRelated Tasksをクリックすれば、それらを見ることができます。図 4にあるように、サブ・タスクの関連情報が画面に表示されます。右側にあるアイコンは、タスクをオープン、もしくはキャンセルするためのものです。

図 4. タスク関連情報の表示(Related tasks)
タスク関連情報の表示(Related tasks)

セキュリティ・マネージャーと呼ぶ新しいウィジェットが追加されました。図 5にあるように、ビジネス・カレンダーを利用するロール定義を構成できます。デフォルトでBPMAdminが、BPMrolemanagerロールを持ち、ユーザー追加、削除をする権限を持つIDとして用意されています。これはリソース・ロールの代わりに使われます。

図 5. セキュリティ管理ウィジェット
セキュリティ管理ウィジェット

BPC エクスプローラーの拡張

WebSphere Process Serverには、ビジネス・プロセスを扱うためのBPCエクスプローラーとBPC オブザーバーという2つの管理用Webアプリケーションを用意しています。図 6にあるように、画面左上にあるビュー・タブ(Views)を選ぶと、これまでと同じBPCエクスプローラー情報が表示されます。またレポート・タブ(Reports)を選ぶと、これまでBPCオブザーバー上で表示していた情報が表示されます。このレポート・タブは、プロセス・インスタンスなどを表示する画面に追加されました。

図 6. BPC エクスプローラー
BPC エクスプローラー

BPCオブザーバーによるレポート機能は、BPCエクスプローラーに移動しました。ヒューマンタスクとビジネス・プロセスの管理業務を行いながら、このレポート能力を活用することができるようになります。また、カスタム・ビューの定義ができるようになりました。これらのビューの使用に対しては、時間制約を設定することができます。

サービス・インテグレーション・バス(SIBus)ブラウザー

サービス・インテグレーション・バス(SIBus)を確認するために利用する、エクスプローラー形式のアプリケーションが新たに提供されます。このインターフェースを利用すると、セル・レベルで定義されたバスを見ることができ、バス上にあるキュー・ポイント、パブリケーション・ポイント、メディエーション・ポイントをドリルダウンして見ることができます。

SIバス・ブラウザーにアクセスする方法は次のとおりです:

  1. 管理コンソールにログオンします
  2. サービス統合(Service integration)をクリックして表示を広げ、Service Integration Bus Browserをクリックします
  3. BPC.widCell.Busの左横にある “+” をクリックし、widNode.server1 => widNode.server1-BPC.widCell.Bus => キュー・ポイント(Queue Points) の順番にクリックします
  4. 図 7 のとおり、キュー・ポイント(Queue Pointes)が表示されます。
図 7. SIバス・ブラウザー
SIバス・ブラウザー

クリックして大きなイメージを見る

図 7. SIバス・ブラウザー

SIバス・ブラウザー

インストレーション機能、標準サポート、サポート・プラットフォームの拡張

新規フィーチャーやオプションが加わり、インストレーション機能が拡張されました。WebSphere Process Server V6.2 にはWebSphere Application Server Network DeploymentとそのFeature Pack for Web Servicesの完全なパッケージを同梱しています。WebSphere Process Server 用プロファイル作成時のプロファイル選択オプションが増え、Web Services Feature Pack が選択できるようになりました。このフィーチャーパックはWebSphere Application V6.1 が当初リリースされたときには含まれていなかったWebサービス標準のサポートが含まれています。これにはWeb Services Reliable Messaging, Web Services Addressing, SOAP Message Transmission Optimization Mechanismなど、多くの標準が含まれています。

また、インストレーション・ファクトリーを作成することができます。これはインストール・パッケージに含まれるスクリプトを使って本番環境を構成するものです。この新しいインストレーション検証ツールは、サービスが正しく構成されたことを検証するのに利用できます。インストレーション作業中のエラーに対しては、エラー検知機能が改善されました。

IBM z/OSプラットフォームではインストレーション機能が改善され、証明aliasの数を減らしました。zPMT構成ツールを利用し、新たな応答ファイルを作成できます。データ定義言語の生成が改善され、利用しやすくなりました。

最新プラットフォームへの対応

WebSphere Process Server V6.2は、最新プラットフォームに対応するための更新が行なわれました。現在、WebSphere Application Server V6.1がサポートされています。

IBM z/OS と z/OSe V1.9以上の製品サポートに加えて、ランタイム・プラットフォームとしてWindows® Vistaがサポートされます。またzFSがサポートされるため、ネイティブなz/OSファシリティーを活用できます。IBM IMS V10も同様にサポートされるようになりました

標準サポート

WS-I Reliable Secure プロファイル、SOAP 1.2、WS-Reliable Messaging に対するサポートが追加され、インターオペーラビリティーが向上しました。Webサービス・バインディングについては、JAXWS 2.0, JAXB 2.0, SAAJ 1.3, そして StAX 1.0のサポートが追加されました。サービス・ディスカバリーについては、JAX-WS と JAXB2 ベースの Java™ サービスが追加されました。配列(arrays)が本当の意味で、サポートされるようになりました。

Webサービスを呼び出すプロセスに、Webサービス・ポリシーセットがサポートされるようになりました。これにより管理がシンプルになります。各々のサービス・コール毎にQoS クオリファー(qualifiers)を定義しなくても、ポリシーセットをひとつ明記すれば済むからです。利用可能なポリシーセットは、WS- Reliable Messaging, WS-Security, WS-Transaction, WS-Addressing, HTTP Transport そして SSL Transportです。

WebSphere Process Server V6.2は、米国連邦政府のデスクトップ基準(FDCC= Federal Desktop Core Configuration)により定められたセキュリティ設定に準拠しています。また米国連邦標準規格である暗号モジュールに関するセキュリティ要件の仕様、FIPS 140-2に則った機能もWebSphere Application Server Network Deployment 環境により、サポートされています。

WebSphere Process Server V6.2 では、WS-BPEL 2.0 サポートがさらに拡張され、新たにRepeatUntil ループがサポートされるようになりました。Whileループではコンディションがtrueに限り実行されますが、RepeatUntilループは最低一回実行されることになり、そしてコンディションがtrueの限り継続されます。図 8 はRepeatUntilループを示しています。

図 8. Repeat until ループ
Repeat until ループ

これまでのWebSphere Process Server バージョンでは、XPath値の参照にはWS-BPEL 1.1スタイルが使われていてGetVariableData()メソッドが必要でした。V6.2ではこの機能が改善されWS-BPEL 2.0スタイルによる値の参照が可能になり、$variable 記述が使えるようになりました。bpws:getVariableData(‘customer’,’/name’)という記述方法だったものから、$customer/nameと表現できるようになります。

ヒューマンタスク

WebSphere Process Server V6.2では、ヒューマンタスクにいくつかの改善を行ないました。これまでのバージョンでは、プロセス内のステップはインライン・ヒューマンタスクまたは外部参加型タスク(訳注.予定タスク/To-Do Task)になりました。外部参加型のタスクではプロセス・コンテキストにアクセスできない、というデメリットがありました。そのため、ヒューマンタスクとしては限定された利用方法しかできませんでした。WebSphere Process Server V6.2 ではプロセス・コンテキストから呼び出しタスクを作ることができるため、ビジネス・プロセスはタスクのライフサイクルを管理できるようになります。同様に、タスクは代理機能を使用することができるようになります。図 9 に示すとおり、タスクのプロパティ内オプションにて ”ライフサイクルを呼び出し側ビジネス・プロセスにバインドする(Bind the lifecycle to the invoking business process)” を指定することができるようになりました。このタスクはこのシナリオにおいて「子タスク」と呼ばれます。ヒューマンタスクがそのプロセスのライフサイクルにバインドされている場合、プロセスを停止させるとこのヒューマンタスクも停止することになります。

図 9. ヒューマンタスクのライフサイクルを呼び出しプロセスにバインドさせる
ヒューマンタスクのライフサイクルを呼び出しプロセスにバインドさせる

クリックして大きなイメージを見る

図 9. ヒューマンタスクのライフサイクルを呼び出しプロセスにバインドさせる

ヒューマンタスクのライフサイクルを呼び出しプロセスにバインドさせる

ヒューマンタスクに履歴ログという新規フィーチャーが追加されました。管理コンソールで、ヒューマンタスク・ヒストリー機能を利用可能にすることができます。図 10に示すように、サーバー>アプリケーション・サーバー>server1>ビジネス・インテグレーション>Business Process Choreographer>Human Taskと順番に選んで、Human Task Manager構成パネルを開きます。この画面上にある”タスク履歴を使用可能にする(Enable Task History)”にチェックを入れます(デフォルトでチェックされています)。この機能を利用可能にすると、誰がいつ実施したかなど様々なタスク状況の履歴を見ることができます。ビジネス・ユーザーはタスク・ヒストリーを見ることができます。ヒューマンタスク・ヒストリーは共通イベント・インフラストラクチャー(CEI)のような監査メカニズムをもつものではありません。そのライフサイクルは、そのヒューマンタスクに依存します。そのタスクが削除されると、そのタスクの履歴も同様に削除されます。

図 10. ヒューマンタスクの履歴表示
ヒューマンタスクの履歴表示

このオプションを確認する方法:

  1. 管理コンソールにログオンします
  2. Serversをクリックしてリストを広げます。それからアプリケーション・サーバー(Application Servers)を選択します
  3. server1をクリックして選択します
  4. Business Process Choreographerを広げて、Human Task Managerを選択します
  5. オプションにチェックをしてOKをクリックし、その後構成の更新を保管します

WebSphere Process Server V6.0.2 では、ページ・フローに新規機能を追加しました。それは、シングル・ユーザーがひとつのプロセスで連続した複数タスクを実行するもので、API completeAndClaimSuccessor を使って行ないます。ワークを行なうユーザーが多くのページ・フロー・プロセスを起こすシナリオをサポートするために、新たにAPI initiateAndClaimFirst を追加しました。これはプロセス・インスタンスを起こして最初のワーク・アイテムを呼び出すまでを、ひとつのAPIコールで行なうものです。

ボリュームの多い環境では、ユーザーはワーク・アイテムを探し出すのに、何百も何千もあるタスクをソートする必要があります。そのような場合には、タスクのプロパティに、状況、ディスクリプション、プロセス・データなどを指定して、クエリーすることができます。また複雑なクエリーも可能です。ユーザー・インターフェースに早くレスポンスすることは重要なため、クエリー・テーブルを作成することができるようになりました。サポートパックに含まれるEclipseプラグインでXMLファイルを作ります。こうしてできたファイルはmanageQueryTables.pyと呼ばれるwsadminスクリプトでインポートできます。このスクリプトは最適化したSQLを生成し、追加のビューやテーブルをデータベース内に作成することなく、クエリー検索に使えます。このフィーチャーにより、規模の大きいクエリーでも大した時間が掛からずに処理を行なうことができます。

ケース・ハンドリング

ビジネス・プロセスはとても構造的です。全てのプロセス・インスタンスはプロセスを通じて決められたパスを通ります。伝来のWS-BPELプロセスはこうしたプロセス・クラスを扱います。ところがビジネス・プロセスにはビジネス上の必要性から、こうした厳格なプロセスによる制限が受け入れられないクラスがあります。次に何を行うのか、ガイダンスを提供するプロセスが必要ですが、ユーザーは前のステップをスキップ、再実行(redo)することもあり、もしくはオンザフライで新たなステップを追加することもありえます。

このようなダイナミックなプロセス・シナリオ用に、コラボレーション・スコープと呼ぶ新しい構造をビジネス・プロセス内に用意しました。このプロセス要素はコンテナーです。BPELスコープ・アクティビティと同様です。コラボレーション・スコープはビジネス・ユーザーがスキップや再実行(redone)できるステップを含んでいる点で異なります。図 11 に示すとおり、ビジネス・スペースのヒューマンタスク向けメニューには、ひとつのヒューマンタスクにおいてスキップもしくは再実行(redo)をアクションとして選べるようになっています。

図 11. コラボレーション・スコープでのステップ再実行(Redo)
コラボレーション・スコープでのステップ再実行(Redo)

図 12 に示すとおり、フォールト・リンク(Fault link)によるフォールト(Faults)の扱いが、可能になりました。タスクが通常終了するときは、通常リンク(regular link)に従って処理されます。フォールトが発生するケースでは、フォールト・リンクにしたがって処理されます。フォールト・リンクは通常リンクとは異なり、別の色でかつ二重線で示されます。

図 12. フォールト・リンクを使用したコラボレーション・スコープ
フォールト・リンクを使用したコラボレーション・スコープ

コラボレーション・スコープは、コラボレーション・フォルダーと呼ばれる特別な値を持っています。これはビジネス・プロセスにリンクしたドキュメントを添付するために使われます。このフィーチャーにより、ビジネス・ユーザーはプロセス・フローに対してよりコントロールできるようになり、ビジネスにとって受け入れやすいプロセスが構築できます。

そのほかの拡張

WebSphere Process Serverのステップに、exitコンディションが持てるようになりました。これはプロセス・ステップの入り口(entry)や出口(exit)において評価することができます。タスクの入り口でコンディション評価をすると、その評価結果がtrueの場合、アクティビティがスキップされ、プロセスは次のアクティビティへとナビゲートします。これにより、実行不要なステップをスキップさせるためのコンディション評価ロジックをプロセス内に記述する手間を省きます。タスクの出口でコンディション評価をすると、その評価結果がtrueの場合、そのタスクは成功裏に完了したとみなされます。この結果がfalseの場合、そのアクティビティは問題を抱えているとみなし、停止するようにセットされます。これにより、そのステップが正常終了していることを確認するための追加ステップを作成する手間を省きます。このように、この機能によりチェックする追加アクティビティが不要になるため、よりクリーンなモデリングが実現できます。

ステップを自動スキップするケースを定義するのに、こうしたコンディションが使用されます。コンディションはステップに入るとき、出るとき、もしくはその両方で確認できます。

新規フィーチャーが追加され、ダイナミック呼び出し(dynamic invocation)がSCAで利用できるようになりました。これは、WS-BPELプロセス、メディエーション・コンポーネント、Javaコンポーネントで利用できます。これにより、アプリケーションはより高度な柔軟性とダイナミックさが持てるようになります。そのエンドポイント参照は実行時点(runtime)で判断され、事前のSCAインポート定義は必要ありません。ワイヤリングされたインポートによる限定的な呼び出し方法ではなく、エンドポイントのアドレスを上書きして事前にワイヤーでつないだものとは違うインポートを使用する、もしくはインポート手段を最初からまったく使わずに最初からダイナミックな呼び出しを実行する、といったことができます。

フォールト・ハンドリングはバージョン6.2になって、さらに機能向上しました。呼び出しをWSDL内で適切な操作(operation)にマップするファンクション・セレクター(function selector)としても利用できますが、新たなフォールト・セレクター(fault selector)は、操作レベル(operation)だけでなくバインディング・レベル(binding)でもフォールトのネイティブ名称をリターンさせたいときに利用できます。全てのインポート・バインディングに渡るフォールト・ハンドリングは、呼び出したサービスがフォールト・リターンを返したかを決めることができます。また、新しくフォールト・データをマッピングできるようになりました。またフォールトをビジネスなのかテクニカルなのか分類分けすることができます。こうした新しい機能は、全てのサービス呼び出しにおいて、フォールト・ハンドリングの設計を首尾一貫したものにします。

これまでのWebSphere Process Serverバージョンでは、デプロイされたアプリケーションをアンインストールするのに、プロセス・テンプレートやタスク・テンプレートを停止させる必要がありました。そのテンプレートでプロセス・インスタンスが起動していない場合には、テンプレートを停止させることなくアプリケーションをアンインストールすることができるようになりました。

WebSphere Process ServerのREST APIが拡張され、新たな機能とリソースをサポートするようになりました。サブ・タスクを作業する、ヒューマンタスクの履歴をみる、といったことが、プロセス・テンプレート、プロセス・インスタンス、アクティビティに対する重要な機能として、追加で利用できるようになりました。

プロセスを開始すると、オーナーシップを他のユーザーに転送することができるようになりました。管理者は変遷状況(transition condition)の値を、これから処理されていくアクティビティに対して提供できるようになりました。これによりプロセスの枝分かれをどのように進めるのかを、強制的に指定することができます。これからナビゲートされるアクティビティも含めて、その変数値を確認・変更することができるようになりました。図 13 はBPCエクスプローラーのアクティビティ変数画面です。アクティビティ・ページ上のVariablesをクリックすることで表示することができます。

図 13. アクティビティ値 (Activity variables)
アクティビティ値 (Activity variables)

マイグレーション機能の拡張

WebSphere Process Server 製品が発表される前には、ビジネス・プロセス・マネージメント用の製品がいくつか存在していました。それぞれの製品が持っていた実行能力はWebSphere Process Server の設計に取り込まれました。そうした製品からWebSphere Process Server へとスムースにマイグレーションするための新しい機能拡張がバージョン6.2に対しておこなわれました。

WebSphere MQ Workflow

WebSphere MQ Workflow は、自動処理とヒューマンタスクを含むロングランニングなビジネス・プロセスをサポートする製品です。WebSphere Process Server V6.2 では、より最適なWS-BPELを生成するFDL2BPEL ツールの更新バージョンを用意しました。マージは、Javaスニペットをいくつか生成するよう最適化されました。WS-BPEL変数を共有する仕組みが改善され、いくつか生成されるようになりました。新たなWS-BPEL構成がサポートされるようになり、冗長シーケンスとフロー・アクティビティが除去されました。これにより、クリーンなプロセスが生成されます。

ヒューマンタスクのクエリー・パフォーマンスは、WebSphere MQ Workflowと同等に近づくレベルまで改善されました。新たになったクリーンナップ・サービスは、完了したインスタンスをデータベースから削除するタイミングをスケジュールできます。これはクリーンナップ・サーバーと同等機能を実現します。このサービスがいつ、どのくらいの期間実行するのか、ひとつのトランザクションでいくつのインスタンスを削除するのか、を定義できます。このオプションによりデータベース内部にどの程度完了済みインスタンスを一時保管するのか、またあとでシステムの空き時間にそれらを削除するのか、を指定できるようになり、パフォーマンスが向上します。作業をずらすことで、データベースのピークタイムの負荷を軽減します。図 14は、新たなクリーンナップ・サービスのジョブを追加するダイヤログを示しています。

図 14. クリーンナップ・サーバーのジョブをナビゲートする
クリーンナップ・サーバーのジョブをナビゲートする

完了したプロセス・インスタンスをクリーンナップするスケジュールを組む機能は、WebSphere MQ Workflow クリーンナップ・サーバーと同等機能を提供します。

WebSphere InterChange Server

WebSphere InterChange Server は、WebSphere Business Integration Adapters を利用してシステム統合したビジネス・プロセスの自動化を実現する製品です。エンドポイントが使用するアプリケーション定義BO(ASBOs)は、汎用BO(GBOs)にマッピングされてからコラボレーション・ロジックに使用されます。WebSphere Process Server V6.2 はそのマップをWebSphere Adapters、生成するネイティブSCAバインディング、WebSphere MQシリーズ、JMS、HTTP、EJBを使ってマイグレーションします。マイグレーションされたマップは、テキスト・ベースのデータ・ハンドラーをサポートします。実行環境(runtime)のパフォーマンスも改善しました。こうした機能拡張により、WebSphere InterChange Server からのマイグレーション手段が改善されました。

WebSphere ESB の拡張

WebSphere Process Server は、WebSphere ESBというエンタープライズ・サービス・バス製品と密接に統合しており、その製品を内部包含しています。このWebSphere ESB製品は、単体でも購入できます。WebSphere ESBはメッセージ・ルーティング、データ変換(transformation)、プロトコル変換(transport mediation)、そしてイベントをサポートします。バージョン6.2になりポリシー・ドリブンによるサービス・メディエーション構成が可能になったため、柔軟性がさらに増しました。ポリシー管理とガバナンス実現にはWebSphere Services Registry and Repository 製品が利用できます。

バージョン6.2では、これまでのメディエーション・プリミティブが改良されたほか、新たなメディエーション・プリミティブが追加されました。図 15 は利用可能なメディエーション・プリミティブを示しています。

図 15. メディエーション・プリミティブ
メディエーション・プリミティブ

タイプ・フィルター・プリミティブ(Type Filter primitive). タイプ・フィルター・プリミティブが新たに追加されました。メッセージ・フィルターが値でルーティングするのに対して、このタイプ・フィルターはメッセージ・タイプでルーティングします。あるメディエーション・フローでタイプの異なるメッセージを複数処理する場合に、それぞれが異なるターミナル先に誘導するのに、この新しいプリミティブを使ってXPath式を定義できます。このXPath式のどれにも当てはまらない場合には、デフォルトのターミナルが使用されます。この機能はサービス・ゲートウェイ・パターンで使用されます。

データ・ハンドラー・プリミティブ(Data Handler primitive). 新しくなったデータ・ハンドラー・プリミティブは、物理フォーマットと論理データ構造間で変換を行ないます。以前のバージョンでは、モジュールのインポートとエクスポート内でデータ・ハンドラーを使用していました。今回はサービス・ゲートウェイ・シナリオが追加されましたが、これは入ってくるメッセージはanyTypeなので、メディエーション・フローのなかにデータ・ハンドラー・ロジックが入れられるようになりました。

プリミティブのセット(Set of primitives). WebSphere MQ、SOAP、HTTP、JMS向けのメッセージ・ハンドラーを設定するために、新しいプリミティブのセットが提供されました。これらメッセージ・ハンドラー・セッターは、ヘッダー・プロパティとその値をセットすることができます。また、既にあるヘッダー・プロパティを見つけて値をセットすることもできます。さらに、既存ヘッダー・プロパティを見つけて、その値をサービス・メッセージ・オブジェクト(SMO)内のほかの場所にコピーすることもできます。既存ヘッダー・プロパティを見つけて削除することもできます。

ポリシー解決プリミティブ(Policy Resolution primitive). WebSphere Services registry and Repositoryと動作するための、新たなポリシー解決プリミティブが追加されました。WSRRからポリシーを取得し、有効なポリシーからダイナミックなプロパティ値のセットへと変換します。

以前のWebSphere Process Serverバージョンでは、メディエーション・フロー・コンポーネント毎にモジュールが必要でした。バージョン6.2では、複数のメディエーション・コンポーネントはひとつのモジュールに収められます。仮に20個のメディエーション・フロー・コンポーネントがあった場合、20個ではなく、その全てが含められたひとつのモジュールをデプロイすればよくなりました。これはメディエーション・フロー・コンポーネントのシンプルな管理とデプロイを実現します。

さらに、メディエーション・フロー・コンポーネントはビジネス・インテグレーション・モジュールに追加されるようになりました。これでSCA経由ではなく、プロセスを直接メディエーション・フロー・コンポーネントにワイヤーでつなげることができるようになりました。これはメッセージを外部モジュールに送るのではなくこの呼び出しはローカルで行なわれるため、パフォーマンスが改善されます。

サービス・ゲートウェイ・パターン

エンタープライズ・サービス・バス向けの共通実装パターンを、サービス・ゲートウェイと呼びます。このパターンでは、着信メッセージをエンドポイントにルーティングするときに、メッセージが持つ属性を元に判断します。サービス・ゲートウェイのよくあるメディエーション・フローを図 16に示します。フィルター・ノードがフローを異なる分岐に向かわせています。そこではメッセージ変換(message transformation)が行なわれています。それから正しいエンドポイントが呼び出されています。以前のWebSphere ESBバージョンでは、このパターン実装は”静的(Static)”に行なわれました。エンドポイントに対して変更があるときは、メディエーション・モジュールの変更が必要だったためです。

図 16. 静的(Static)なサービス・ゲートウェイ・パターン
静的(Static)なサービス・ゲートウェイ・パターン

WebSphere ESB V6.2 は、最新のメディエーション・プリミティブを使ってダイナミック・サービス・ゲートウェイを実現し、このシナリオを拡張しました。フロー分岐とその条件ロジックをハードコーディングする代わりに、WebSphere Services Registry and Repositoryを利用してダイナミックなルックアップを実行します。図 17に示したフローでは、WebSphere Services Registry and Repositoryからエンドポイントを取得し、SOAPヘッダー情報をセットして、それからエンドポイントを呼び出します。こうすることで、仮にエンドポイントが変更されても、もしくは新たなエンドポイントが追加されても、WebSphere Services Registry and Repository内の変更で作業が完了します。メディエーション・フローは変更する必要がないので、この実装はダイナミックに変更できます。このエンドポイント・ルックアップはデータベース、メッセージの要素、カスタム・ロジックからも取得できるので、サードパーティ製品を利用することもできます。このゲートウェイはWebサービス(SOAP 1.1もしくは1.2)、HTTP、JMS、MQが転送プロトコルとして使用できます。

図 17. WebSphere Process Server V6.2 のダイナミックなサービス・ゲートウェイ・パターン
WebSphere Process Server V6.2 のダイナミックなサービス・ゲートウェイ・パターン

ダイナミック・プロパティ

以前のWebSphere ESBバージョンでは、メディエーション・プリミティブのプロパティは、設計局面でWebSphere Integration Developerによって定義されていました。バージョン6.2になり、実行時(runtime)にそれを決めることのできる、プロモーテッド・プロパティ(promoted properties)が利用可能になりました。このプロモーテッド・プロパティ値を上書きするために、サービス・メディエーション・オブジェクト(SMO)にダイナミック・プロパティ・コンテキストが含まれるようになりました。2つ目のオプションは、WebSphere Services Registry and Repositoryで得るポリシーを使って値を指定する方法です。メディエーション・コンポーネント内でポリシー解決プリミティブを利用することで実現可能です。どの方法でも柔軟でダイナミックなメディエーション・フレームワークが実現できます。

そのほかの拡張

以前のWebSphere Process Serverバージョンでは、ビジネス・プロセスとヒューマンタスクにバージョンを付けることができ、同時に複数バージョンをインストールすることができました。図 18に示すとおり、WebSphere Process Server V6.2 では、SCAモジュールとライブラリーにもバージョン・サポートが追加されました。依存エディター(dependency editor)でライブラリーを選ぶと、必要なバージョンを指定することができます。そのモジュールが正しいバージョンのライブラリーを使用していることを確認できます。SCAインポートに対して、使用したいバージョンが指定できます。エンドポイント・ルックアップ・プリミティブもバージョンが指定できます。この新しい実行能力により、同じ名前を持つ複数バージョンのモジュールを同じサーバー上にデプロイすることができます。遅延バインディング(late-binding)インターフェースは常に最新バージョンを選択します。アーリー・バインディング(early-binding)インターフェースは使用するバージョンを指定します。

図 18. モジュール・バージョンの設定
モジュール・バージョンの設定

ビジネス・オブジェクト(BO)向けの新たなAPIが追加され、ビジネス・オブジェクトをネストして開発するのが便利になりました。以前のバージョンでは、プロパティをセットする前にネストされる対象ビジネス・オブジェクトを作成してから初期化する必要がありました。バージョン6.2では新しく追加されたAPI boFactory.createByType を使って、ハイレベルのビジネス・オブジェクトを最初に作成することができます。作成されたBOはすぐに利用することができます。これにより3階層にネストされたビジネス・オブジェクトに対しては、以前では7行のコーディングが必要だったのに対して、2行で済むようになります。

抽象ビジネス・オブジェクト(Abstract business objects)がサポートされます。これは抽象的なビジネス・オブジェクトを作るための新しいオプションです。抽象ビジネス・オブジェクトはSCAバインディングの境界外には渡されません。SCA内部で、新しいビジネス・オブジェクトを作成するのに利用されます。Javaプログラミングにおける”implements”コンセプトに似た役割を持ちます。抽象ビジネス・オブジェクトはXMLからSDOへと変換することはできません。

WebSphere Service Registry and Repository との連携

WebSphere Process Server と WebSphere Service Registry and Repositoryとの連携機能がV6.2で拡張されました。WSRRのインスタンスが定義されると、そのコネクションをテストする新しいボタンが利用可能になります。プロキシー定義の変更が行なわれても、サーバーの再起動は必要なくなりました。図 19に示すとおり、キャッシュに保存されたWSRR情報は管理コンソールからクリアできるようになりました。またコマンド・ラインからも可能です。

図 19. WebSphere Service Registry and Repository (WSRR) の定義
WebSphere Service Registry and Repository (WSRR) の定義

クリックして大きなイメージを見る

図 19. WebSphere Service Registry and Repository (WSRR) の定義

WebSphere Service Registry and Repository (WSRR) の定義

WSRR定義の作成方法:

  1. 管理コンソールにログオンします
  2. +”をクリックしてサービス統合(Service integration)を広げ、WSRR定義(WSRR definition)をクリックします
  3. 新規作成(New)をクリックして、構成を新たに追加します
  4. WSRR定義名を入力し、適用(Apply)をクリックします
  5. 接続プロパティー(Connection Properties)をクリックし、レジストリーURL、認証別名(authentication alias)、SSL構成に選択入力してから、OKをクリックします
  6. テスト接続(Test Connection)をクリックし、値が正しいことを確認します
  7. 保存(Save)をクリックしてローカル構成を更新すると、コネクションがリストに表示されます

まとめ

この記事では、WebSphere Process Server V6.2 の新機能について学びました。
学んだ内容は次のとおりです:

  • ビジネス・スペース by WebSphere に対する更新情報
  • 新規追加および改善された、プロセス・デプロイメントとプロセス・インスタンスのコントロール
  • 最新標準とプラットフォームに対する更新情報
  • WebSphere Application Server Web Services Feature Pack との連携
  • WebSphere Adapters V6.2 のサポート

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=384981
ArticleTitle=WebSphere Process Server V6.2新機能のご紹介
publish-date=12042008