この記事は、IBMによるSOA（Service-Oriented Architecture）アーキテクチャーのプログラミング・モデルに関するシリーズの第3回目です。これまでの記事では、SOAプログラミング・モデルの概念とSDO（Service Data Object）に関して紹介しました。

ビジネス・プロセス

ビジネス・プロセス・コレオグラフィーによるサービス協調の概念は、1970年代にFORTRANプログラムの経験がある人には、お馴染みのものでしょう。単純にメインライン・コードがファンクションやサブルーチンを呼び、それらが大きなプログラムの個々の断片を実行する、というのが、その概念なのです。今や21世紀なので、サブルーチンはWebサービスであり、メインライン・プログラムの実装言語はBPEL4WS（BPEL for Web Services: BPELに関して詳しくは 参考文献 を見てください）です。そして実行環境は、IBM WebSphere ® Business Integration Server Foundationのビジネス・プロセス・コレオグラフィー・コンテナーです。プログラムはビジネス・ファンクションを実現するために、複数企業にも広がり得る長期間実行タスクをつなぎ合わせるのです。

図1 は、社内用に出張承認と予約を行う、単純なBPELプロセスを示しています。このプロセスでは、プログラムがリクエスト・データのチェックを行い、また上司による承認という、人によるタスクがあり、そして実際の予約の行うための、パートナーとのB2B対話動作が行われます。

BPELに関しては数多くの参考資料やチュートリアル（ 参考文献 ）があるので、それを繰り返すのは避けることにします。下記のリストは、IBMがWebSphere Business Integrationで実装しているBPELの機能や拡張の幾つかを要約したものです。

• 複数のパートナーと対話動作し、長期間実行できるビジネス・プロセス。 全ての対話動作は、標準の、ステートレスWebサービス・コールによって実行されます。アプリケーション・レベル・データを使った特定なインスタンス（ある従業員からの、従業員番号を基にした出張承認リクエストなど）に対応するためには相関が使われます。必要な場合にはプロセスの効果を（部分的に）取り消すために（例えば、飛行機を予約した後に出張リクエストがキャンセルされた場合など）、補償機能が提供されています。
• プロセスの中に人を取り入れる機能。 ビジネス・プロセスの一部のステップを人が実行するのは一般的なことです（例えば承認や例外処理のワークフローの場合など）。こうしたステップの中に含まれるものとしては、作業を人に割り当てるための、複雑、かつコンテキスト次第で変化する状況があります（例えば、『4つの目による原則』、つまり第2段階の承認は第1段階での承認者以外で行う、という状況など）。こうした要求は、人によるタスクをプロセス・ステップとして使用することで実現することができます。ビジネス・プロセス・コレオグラフィー・エンジンとIBM WebSphere Studio Application Developer Integration Editionツールは、人によるタスクをサポートしています。
• プロセスをJ2EE（Java ™ 2 Platform, Enterprise Edition）に埋め込む機能 、そして、XPath（BPELでの標準）に加えて、プロセス内部からのファーストクラス言語としてJavaを使用する機能。BPELのスコープではJavaの機能はどれも対象外ですが、IBMとBEA Systems, Inc.は、BPELJという形でBPEL用のJavaエクステンションを提案しています。このエクステンションを利用すれば、プロセス中のアクティビティーをJava断片で実装でき、BPELで式が使用できる場合にはJavaを式のための言語として使用でき、また、プロセス内の作業データをJavaで操作できるようになります。
• QoSエクステンション(Quality of service extensions)。 これは実稼働システムで必要となります。例えばトランザクション境界を微調整する機能、エラー状況を正常に修復する機能、監査ログを生成する機能などです。
• WebSphereとの統合機能。 プロセス・コレオグラフィー・エンジンは、WebSphereのトランザクション・エンジンとアクティビティー・サービスに統合されています。人とのやり取りを伴うプロセスでは、WebSphereのユーザー・ディレクトリーとセキュリティーを利用します。BPELプロセスは、WebSphereアプリケーションのデプロイメントの一部としてデプロイされます。ビジネス・プロセスの管理は、WebSphere管理コンソールの中に統合されています。

BPELプロセスは、IBM Rational ® and WebSphereツール・スイートの中にある、ビジュアル・ビジネス・プロセス・エディターを使って作ることができます。サービス・インターフェースをアセット・ビューにインポートすれば、BPELプロセスから外部サービスを呼び出すことができます。このツール・スイートにはビジュアル・デバッガーもあり、長期間実行プロセスの並行分岐のデバッグや、適当なインターフェースを通して、人とやり取りを行うアクティビティーと対話動作を行うことができます。また、このツール・スイートでは、BPELプロセスのテストや、BPELプロセスをサービスとしてデプロイすることもできます。

上に戻る

ビジネス状態マシン

ワークフロー・プロセスは、アクションや動詞と似ています。例えば、CreatePurchaseOrder（注文書を作成）あるいはBookTravel（旅行を予約）であれば、数多くのWebサービスやJavaクラス、あるいはEJB（Enterprise JavaBeans）を呼び出しながら、複数のステップやパスを通って実行されるかも知れません。

もしワークフロー・プロセスが動詞とするならば、ビジネス状態マシンは、『もの』を表す名詞と言えるでしょう（例えば注文書や出張のチケット、保険商品の申し込みなど）。ここで、CreatePurchaseOrderやBookTravelのような動詞は、ある『もの』に対する『オペレーション』です。ビジネス状態マシンでオペレーションを行うと、任意のサービス（例えばBPELプロセスや、状態マシンによってインライン化されて規定されているJavaコードなど）を呼び出すことができます。

どちらによる方法も、つまりプロセスによる方法も、状態マシンによる方法も、どちらが優れているということはありません。どちらもサービスの抽象化であり、機能的には等価です。ですから自分の対象とする課題を、より適切に抽象化できる方を選択するようにします。

ビジネス状態マシンは、状態遷移図によってグラフィカルに規定されます。この遷移図では、状態や、起こり得る状態遷移とその遷移を引き起こしたイベント、その結果行われるオペレーションなどが表示されます。 図2 は、PurchaseOrder（注文書）に関する単純な状態マシンに対応するフロー・チャートです。

ノード（四角）はPurchaseOrderが取りうる状態です。そうした状態としては、Created（作成された）、Ready（準備完了）、InApproval（承認中）、Purchased（購入された）、Canceled（キャンセルされた）、Shipped（発送した）、Delivered（送達された）、Archived（アーカイブされた）などがあります。アーク（arc、矢印）は、起こり得る『イベント』を表します。イベントによって、PurchaseOrderは、ある状態から別の状態に遷移します。

ビジネス状態マシンは、BPELプロセスによって実装することができます。その場合、イベントは、単にWSDL（Web Services Description Language）が記述するプロセスのportTypeに対するオペレーションです。現在の状態（変数の中に保存されています）によって、どのイベント（オペレーション）がアクティブであるかが決まります。もし呼び出し側が不正なオペレーションを呼び出そうとすると、ランタイムは例外を投げます。また、あるオペレーションが有効かどうかを判定するために、状態マシンの現在の状態をクエリーすることもできます。

あるイベントが発生すると（例えば、あるオペレーションが呼ばれた、あるいはタイマーで設定した時間が経過した、など）、状態マシンは新しい状態に遷移し、その遷移に関連付けられたアクションを実行します（例えば、オペレーションやメソッドを呼び出す、など）。 図2 での遷移は、イベントに対する注釈やオプション条件、実行すべきアクションなどを持ったアークに反映されています。状態遷移は、その状態遷移に関連付けられた条件が真となった場合にのみ実行されます。ある状態への入り口と出口で、追加のアクションが行われる場合もあります。 図2 では、Readyという状態での状態マシンに起こり得るイベント（イネーブルになっているオペレーション）としては、purchaseとCancelという2つがあります。purchaseオペレーションに関しては、「承認が必要」と「承認不要」という、2つの状態に可能性があります。

呼び出し側がpurchaseというオペレーションを呼び出すと、ビジネス状態マシン・フレームワークは下記のことを行います。

1. そのオペレーションが現在の状態に対して有効かどうかを判断する。
2. もしその状態に終了アクションがある場合には、その終了アクションを実行する。
3. そのイベントに関連付けられた、全ての状態遷移のための条件を評価する。もし、この注文に対して承認が必要であるとすると、InApproval状態への遷移が選択され、Purchasedへの遷移は無視されます。
4. その状態遷移（この場合はdoApprovalAction() ）に関連付けられたアクションを実行する。例えば、このオペレーションは、セールス・マネージャーにeメールを送る、あるいは別のSOAコンポーネント（BPELフローなど）に対するオペレーションを単純に呼び出す、などを実行するかも知れません。
5. 新しいInApproval状態に入る。
6. もし新しい状態への入力アクションがある場合には、その入力アクションを実行する。

ビジネス状態マシンは、Rational/WebSphereツール・スイートのビジュアル・ビジネス状態マシン・エディターを使って作成することができます。このツールは、ビジネス状態マシンとビジネス・プロセスとを同じように扱います。どちらも外部サービスに対する関係は同じであり、また両者のテスト環境やデプロイメント環境も同じです。

上に戻る

まとめ

SOAに関するIBMのプログラミング・モデルでは、新しいサービス指向アプリケーションを構築し、また既存アプリケーションをサービス・フレームワークとしてつなぎ合わせるための、幾つかの方法が用意されています。この記事では、BPELを使ったビジネス・コレオグラフィーによる方法に焦点を当てました。この方法は、古典的なプロシージャー型プログラミングでサブルーチンを呼ぶ方法と似ており、その上に長期間実行や並行性に関するサポートが追加されています。ビジネス状態マシンによる方法は、BPELを使って表現する、もう一つのプログラミング・モデル成果物です。どちらの方法も、どちらが優れているということはありません。自分が対象とする問題に最適な方を選べばよいのです。今後の記事では、その他のコンポーネント・タイプを紹介し、SOA開発者のレパートリーを広げるために役立てたいと思います。

参考文献

• このシリーズの、過去2回の記事も読んでください。「第1回: IBMのSOAプログラミング・モデル入門」（developerWorks, 2005年6月）と「第2回: SDOを使ってデータ・アクセスを単純化する」（developerWorks, 2005年6月）です。
  
  
• BPELと、WebサービスでのBPELの動作に関して学ぶために、「Business Process Execution Language for Web Services (BPEL4WS) v1.1」（developerWorks, 2003年5月）を読んでください。
  
  
• ビジネス・プロセス・コレオゴラフィーに関して詳しくは、「WebSphere Application Server Enterprise Process Choreographer: Concepts and Architecture」（developerWorks, 2002年10月）と「Business process choreography in WebSphere: Combining the power of BPEL and J2EE」（IBM Systems Journal）を読んでください。
  
  
• BPELJに関して学ぶために、「BPELJ: BPEL for Java technology」（developerWorks, 2004年3月）を読んでください。
  
  
• developerWorks の SOA and web servicesゾーンをご覧ください。SOAやWebサービス技術に関する充実したハウ・ツー情報やツール、プロジェクトの更新情報など、豊富な情報が用意されています。
  
  
• developerWorks ブログに参加して、developerWorksのコミュニティーに加わってください。
  
  
• developerWorks には、SOAやWebサービスに関する記事や、無料のチュートリアル が豊富に用意されていますので、ぜひご利用ください。
  
  

著者について

Matthias Kloppmannは、ドイツのBoeblingenにあるIBM Software Groupの研究所のSenior Technical Staff Memberです。彼はビジネス・プロセス・コレオゴラフィーの中心アーキテクトです。1986年にIBMに入社以来、様々なプロジェクトを経験してきており、ワークフロー・システムやWebサービスのアーキテクチャーに集中してきました。University of Stuttgartにてコンピューター・サイエンスと電子工学の学位を取得しています。

Donald F. Ferguson博士は、20万人にものぼる技術専門家から成るIBMのエンジニアリング・コミュニティーの中で技術的に最高の地位である、IBM Fellowsを持つ55人の一人であり、IBM Software Group製品ファミリー（Lotus, Rational, WebSphere, DB2, and Tivoliなどが含まれています）のChief Architect and Technical Leadです。SWG Architecture Boardの議長として、SWGに関する指導的な製品アーキテクトを取りまとめています。最近焦点を当ててきた業務には、Webサービスやビジネス・プロセス管理、クライアント・プラットフォーム、アウトソーシング/ホスティング・プラットフォーム、グリッド・サービス、WebSphere用のアプリケーション開発などがあります。WebSphere製品ファミリーが開始された時から2003年に彼がSWGのChief Architectとなるまで、Chief Architectを務めていました。

Marcia L. Stocktonは、ノースキャロライナ州Research Triangle ParkにあるIBM Software GroupのSenior Technical Staff Memberであり、Master Inventorでもあり、またIEEEのシニア・メンバーでもあります。Software Group Architecture BoardのProgramming Model Workgroupのリーダーとして水平統合の活動を推進しており、LotusやRational、WebSphere、DB2、Tivoliなどの製品群全体に渡るプログラミング・モデルの単純化を図ろうとしています。彼女が合衆国に申請したの73件の特許は、ネットワーキングやWeb、セキュリティー、プライバシー、マルチメディア、ワイヤレス、パーベイシブ・デバイス、無線周波数IDなど、広範に渡っています。最近は、ID管理やエッジ・サーバー分散プログラミング用アーキテクチャーを定義するための活動の中心として活躍してきました。彼女はネットワーキング・ソフトウェアの開発に5年間の経験を経た後、1988年にIBMに加わりました。1975年に、Swarthmore Collegeにて学位を取得しています。

この記事を評価する

コメント

上に戻る

目次

• ビジネス・プロセス
• ビジネス状態マシン
• まとめ
• 参考文献
• 著者について
• コメント