Marc Fasbinder (mfasbind@us.ibm.com), Consulting I/T Specialist, WebSphere Software Technical Sales, IBM
2007年6月27日, 原文はこちら(US)
IBM® WebSphere® Business Modeler（以降、Modelerと呼びます）は、ビジネス・アナリストが個々の独特なビジネス・プロセスを正確にモデリングするために使うことができる強力なツールです。さらに完成したモデルは、WS-BPELにエクスポートすることができます。I/Tで引き継ぐことができる成果物を生成することにより、ビジネス駆動型開発サイクルの時間を短縮し、それとともに最終的なプロセスがビジネスのニーズを確実に満たすようにします。
この記事では、Modelerのさまざまな構成体がどのようにWS-BPELに変換されるかについて説明します。ここに記載するWS-BPELプロセスの図は、IBM WebSphere Integration Developer（以降、Integration Developerと呼びます）で表示されるものを使用しています。
この記事は、皆さんがModelerおよびWS-BPELの基本的知識を持っていることを前提としています。
Modelerは以下をはじめ、さまざまなタスクを支援できる強力なツールです。
- 文書化および法令遵守を目的としたモデリング: プロセスが十分に文書化されていないことは珍しくありません。文書化だけを目的にプロセスを把握しようとする企業もあれば、法規制準拠のためにプロセスの把握が必要な企業もあります。
- 再設計を目的としたモデリング: 一部の企業は、現状（as-is）のプロセスを把握して改善する必要を感じています。Modeler にはこのようなケースを支援する強力なシミュレーション・エンジンがあります。また、将来あるべき姿（to-be）のプロセスを定義するために動的レポートおよび静的レポートを作成することができます。
- 実装を目的としたモデリング: 企業によっては、ビジネス・アナリストがモデリングを行い、それをITで引き継ぐことができる成果物に落とし込んでいくという、ビジネス駆動型開発サイクルを実践する必要があります。このようなモデルは、開発サイクルの時間短縮、ビジネス要件を満たすプロセスの実装を実現します。
実装を目的としてモデリングを行う場合、ビジネス・アナリストがはじめにモデルを作成すると、そのモデルは、IT担当者に引き継がれます。IT担当者とビジネス・アナリストがプロセスの内容について合意した時点で、プロセスはビジネス契約と呼ばれるようになります。つまり、ITでの実装に落とし込む際には、きちんと当初のプロセス・モデルの内容が反映されなければならないということです。IT側でプロセスの内容を変更しようとすれば、それはビジネス側との契約を破ることになります。
ビジネス契約が確立されると、IT担当者は、このビジネス・モデルに技術的要素を付加していくことに着手できます。この技術的な情報は、プロセスをWS-BPELにエクスポートする際に使用されます。ただしModelerの基本モードでプロセスを表示すれば、ビジネス・アナリストは、これらの技術的な詳細を意識せずに済みます。
IT担当者がプロセスを編集するときには、技術属性が表示されるWebSphere Process ServerモードでModelerを使用します。Modelerをこのモードにした場合は、技術属性を表示するタブの他、プロセスの技術仕様を表示するタブも提供されます。開発者はこれらのタブを使って、プロセス・モデルに詳細を追加していきます。
この記事では、ビジネス・モデルの情報を、標準準拠のビジネス・プロセス実行言語である、WS-BPELに変換する方法について説明します（WS-BPEL仕様を参照（US））。記事の内容は、WebSphere Business Modeler version 6.0.2に基づいています。
Modelerには、ビジネス・プロセス・モデルの作成に使用できる多彩なオブジェクトが用意されています。これらの構成体で、ビジネス・プロセスのステップ、制御フロー、データ、リソース、文書化などを表すことができます。
ビジネス・プロセスをエクスポートすると、該当する構成体は、WS-BPEL、WSDLおよびXSDに変換され、ITで引継ぐことができる成果物になります。ただし、Modelerに含まれる構成体の中には、相当するWS-BPELがないものもあります。このような構成体は無視されることもあれば、問題ビューにエラーまたは警告が表示されることもあります。各種オブジェクトは、次のセクションで紹介します。
ModelerプロジェクトをWS-BPELとしてエクスポートする手順は、以下のとおりです。
- プロジェクト・ツリー内のプロジェクトを右クリックします。
- Export…を選択します。
- WebSphere Process Serverを選択し、Nextをクリックします。
- Browse…を使ってターゲット・ディレクトリーを選択します。
- Module project nameのチェック・ボックスを選択し、作成するモジュールの名前を入力します。モジュールが現行のワークスペースに作成されます。
- オプションで、Library project nameのチェック・ボックスを選択して名前を入力します。エクスポートするライブラリーを選択すると、XSDなどの再使用可能な項目がライブラリー・プロジェクト内に配置されます。このライブラリーを、ここで作成するモジュールが参照することになります。
- Modelerがスタンドアロンでインストールされている場合は、Project Interchange nameのチェック・ボックスが有効になります。このチェック・ボックスを選択すると、現行のワークスペースにエクスポートする代わりにIntegration Developerのワークスペースにインポート可能なZIPファイルを作成することができます。
- プロセスに共通イベント・インフラストラクチャーのイベントを生成させたい場合は、Enable default eventsを選択します。
- この時点で、Exportウィンドウは図1のようになっているはずです。Finishをクリックします。
図1 Modelerプロジェクトのエクスポート
Modelerで最もよく使用されるオブジェクトの1つは、タスクです。タスクは、ビジネス・プロセス内の1ステップを表し、手動のタスクと自動のタスクの場合があります。1つのリソースが同時に複数の作業を行う場合には、そのすべての作業を1つのタスクとしてグループ化することができます。
モデリングを行う際に重要なのは、タスクの粒度を考慮することです。タスクの「粒度が小さすぎる」場合、プロセス・モデルが複雑になりすぎて扱いきれないものになってしまう可能性があります。逆に「粒度が大きすぎる」とプロセスが単純になりすぎる恐れがあるので、その中間の程よい粒度になるようにしてください。
Modelerのローカル・タスクとグローバル・タスクは、エクスポートされるとどちらも同じように機能します。このセクションでは、それぞれのタイプのタスクがどのようにBPELにエクスポートされるかを見ていきます。
自動アクティビティー用のタスク
スタッフ・リソース定義のない Modelerタスクは、WS-BPELのinvoke（起動）アクティビティーとなります。また、invokeアクティビティー用のタスクとの接続も作成されます（図2を参照）。
図2 invokeアクティビティーに変換される自動アクティビティー用のタスク
ヒューマン・アクティビティー用のタスク
タスクのリソース定義がStaffに設定されている場合、生成されるプロセスで人による処理の介在をどのように扱うかを制御することができます。Technical Attributes Viewで実装タイプがHuman Taskに設定されているタスクについては、WebSphere Process Serverのヒューマン・タスク・マネージャー用のタスクと併せてWS-BPELのinvokeアクティビティーが生成されます（図3を参照）。実装タイプがNoneに設定されているか、あるいはリソース・タイプが個人の場合、ヒューマン・タスクにIBM WS-BPEL拡張を使用したタスクが生成されます。これは、インライン・ヒューマン・タスクとも呼ばれます。
図3 invokeアクティビティーに変換される自動アクティビティー用のタスク
複数の入力基準を持つタスク
これまで見てきたタスクではすべて、1つのビジネス項目が入力され、1つのビジネス項目が出力されていましたが、プロセスの1つのタスクが複数の入力を持つモデルもあります。それぞれの入力ごとに固有の入力基準を設定すると、いずれかの入力を受け取った場合にタスクが開始されるようにできます。これは、Input Logicタブで制御します（図4を参照）。
図4 Input Logicタブ
タスクが複数の入力を持つ場合、複数の操作を持つWSDLが生成されます（図5を参照）。
図5 複数入力タスクに対応したWSDL
複数の操作を持つWSDLを生成する手順は、以下のとおりです。
- Modelerでタスクをクリックして選択します。
- Inputsタブで、Addをクリックして2番目の入力を作成します。新規入力に名前を指定し、ビジネス項目を関連付けます（図6を参照）。
図6 新規入力の追加
- Outputsタブで、Addをクリックして2番目の出力を作成します。新規出力に名前を指定し、ビジネス項目を関連付けます。
- Input Logicタブで、Addをクリックして 2 番目の入力基準を作成します。
- デフォルトでは、入力基準でAND演算が実行されるので、タスクは両方の入力を待機することになります。この例では一度に1つの入力しか使用しないため、ANDをORに変更します。新規入力基準と新規入力が関連付けられるようにチェック・ボックスを選択します。また、元の入力基準と新規入力との関連付けが解除されるように、該当するチェック・ボックスのチェック・マークを外します（図7を参照）。
図7 Input Logicの設定
- タスクの入力基準と出力基準は同じ数でなければなりません。Output Logicタブでステップ4と5を繰り返して新規出力基準を追加し、OR演算を実行するように変更します。
- Advanced Output Logicタブで、新規出力基準をクリックして選択します。新規入力基準のチェック・ボックスをクリックして出力基準に関連付けます（図8を参照）。
図8 Advanced Output Logicの設定
エクスポートすると、このタスクに対して生成されたWSDLに複数の操作が組み込まれます。
生成される参照パートナーとインターフェース・パートナー
WS-BPELプロセスの各invokeアクティビティーは、WSDLファイルを使って定義された参照パートナー・リンクと関連付けられます。ModelerはこのWSDLファイルを、バインディングをラップした文書リテラル・スタイルで生成します。さらにインターフェース・パートナー・リンクも作成して、プロセスの呼び出し方法を定義します。パートナー・リンクの名前は、invokeアクティビティーの名前の終わりに「Partner」を追加した形式となります（図9を参照）。Container（コンテナー） アクティビティー（ループなど）内での呼び出しの場合に生成される名前は、container activity name || invoke activity name || Partnerとなります。
図9 インターフェース・パートナー・リンク
大抵のIT組織には、WSDLファイルの命名規則などについて、従わなければならない標準があります。WSDLで生成される内容を制御するには、Technical Attributes Viewを使用します。このビューでは要求のWSDL操作名などを定義できます。これらの名前フィールドが入力されない場合、Modelerはデフォルト名を使用し、例えば生成されるポート・タイプの名前は Modelerでのタスクの名前に設定されます。
図10 ModelerのTechnical Attributes View
|
