ビジネス・プロセス: BPEL4WSについて 第1回

ビジネス・プロセスにおけるいくつかの概念

最近リリースされたBusiness Process Execution Language for Web Services (BPEL4WS) 仕様は、複合Webサービスのための標準として位置付けられています。BPEL4WSを使用すると、例えば、Webサービス呼び出しの実行、データの操作、障害(fault)の通知、またはプロセスの終了などのさまざまなアクティビティーを作成し、それらを結び合わせることによって、複雑なプロセスを作成することができます。これらのアクティビティーは、その実行方法 (例えば、順番に実行するのか、並列して実行するのか、あるいは特定の条件に基づいて実行するのか) を定義する、構造化されたアクティビティーの中でネストさせることができます。このシリーズは、この言語のさまざまなコンポーネントを読者に理解していただき、さらに、読者自身で独自の完全なプロセスを作成できるようになっていただくことを目的としています。第1回では、最初の単純なプロセスの作成について説明します。第2回以降では、そのサンプル・プロセスをさまざまに拡張して、BPEL4WSのデータ操作、相関付け、障害処理、補償(compensation)、およびさまざまに構造化されたアクティビティーなど、この言語の主要なパーツについて説明する予定です。

Sanjiva Weerawarana, Research Staff Member, IBM TJ Watson Research Center

Sanjiva Weerawaranaは、IBM T.J. ワトソン研究センターにおけるコンポーネント・システム・グループの研究スタッフの一員です。彼はBPEL4WS、WSDL、およびWSFL仕様の作成者の1人であり、また、BPWS4J、Apache SOAP、WSTK、WSDL Toolkit、WSIF、およびWSGWの開発者の1人です。Sanjivaは、Purdue大学よりコンピューター・サイエンスの分野で博士号を授与されています。



Francisco Curbera (curbera@us.ibm.com), Manager Component Systems Group, IBM TJ Watson Research Center

Francisco Curberaは、IBM T.J. ワトソン研究センターにおけるコンポーネント・システム・グループの研究スタッフの一員であり、またマネージャーです。彼はBPEL4WS、WSDL、およびWSFL仕様の作成者の1人であり、また、BPWS4J、Apache SOAP、およびWSTKの開発者の1人です。Franciscoは、コロンビア大学より応用数学の分野で博士号を授与されています。彼の連絡先はcurbera@us.ibm.com です。



2002年 8月 01日

はじめに

今日のWebサービスは、業界で広く通用している仕様を使用して相互にコミュニケーションし、自らを宣伝し、発見され、呼び出してもらうようになっています。しかし、先週まで、これらのサービスを相互にリンクしてビジネス・プロセスや複合Webサービスに仕上げるには、IBMのWSFLやMicrosoftのXLANGのような、多数の矛盾し合う仕様の中からいずれかを選択する必要がありました。Business Process Execution Language for Web Services (BPEL4WS) は、WSFLとXLANGを組み合わせたもので、うまくいくと、複合Webサービスの標準のための基礎になりそうです。BPEL4WSは、(グラフ指向プロセスをサポートする) WSFLと (プロセスを構造的に構成する) XLANGの長所を組み合わせて、まとまりのあるパッケージにしたものであり、これを使用することにより、あらゆる種類のビジネス・プロセスをきわめて自然に実装できるようになります。BPEL4WSは実装言語としてだけでなく、抽象プロセスの概念を使用して、ビジネス・プロセスのインターフェースを記述するためにも使用することができます。これについては、今後の記事で詳しく述べる予定です。

BPWS4J という名前のBPEL4WS初期実装も、IBMのalphaWorksからリソースされました (参考文献を参照)。この実装は、ユーザーがBPEL4WSを学習し、体験するための試験台として使用することができます。

今回の記事では、BPEL4WSの基本概念について説明します。


BPEL4WSの概念

BPEL4WSは、次の2つの異なるシナリオをサポートします。

  • 実行可能なビジネス・プロセスを実装する。
  • 抽象プロセス(そのままでは実行できない)を記述する。

この記事では、最初のシナリオのみに焦点を当てることにします。BPEL4WSの抽象プロセスの概念については、このシリーズの今後の記事で考察します。

実行可能なプロセスの実装言語としてのBPEL4WSの役割は、既存のサービスのセットを組み合わせて新規Webサービスを定義することです。したがって、BPEL4WSは、基本的には、このような複合Webサービスを実装するための言語です。複合サービスのインターフェースは、他のあらゆるWebサービスと同じように、WSDL portTypeのコレクションとして記述されます。複合Webサービス (プロセス と呼ばれます) は、サービス・インターフェースがその複合Webサービスの全体的な実行にどのように組み込まれるのかを示します。図1 は、こうしたBPEL4WSプロセスの外面的な仕組みを示しています。

図1. BPEL4WSプロセスとして実装されたWebサービスの概念図
図1. BPEL4WSプロセスとして実装されたWebサービスの概念図

BPEL4WSに含まれているコンポジション・プリミティブは、基本的には、長年にわたるワークフローとビジネス・プロセスの統合の経験から得られたものであり、また、BPEL4WSがビジネス・プロセス構成言語として位置付けられているのも、そうした経緯によるものです。

サービスの実装

上の図の雲の形は何を表しているのでしょうか?従来から行われているWSDLサービスのプログラム言語実装の場合とは異なり、BPEL4WSでは、各portTypeのそれぞれの操作は、個別の論理にマップされることがありません。BPEL4WSでは、サービス全体のタイプ (つまり、サービスのportTypeのセット) が1つのBPEL4WSプロセスによって実装されるようになっています。したがって、インターフェースの操作を呼び出す外部ユーザーに対応する、特定の「エントリー・ポイント」は、BPEL4WS記述の中で指定されます。これらのエントリー・ポイントは、入力専用または入出力操作によって得られたWSDL操作の着信メッセージを受け入れます。入出力操作の着信メッセージを使用する場合には、出力メッセージがどこで生成されるのかも、このプロセスで指示しなければなりません。BPEL4WSはWSDLの入力専用操作および入出力 (要求/応答) 操作だけを使用し、サポートします。出力専用 (通知) および出入力 (請求/応答) 操作は不要であり、サポートされることもありません。

BPEL4WSプロセス自体は、基本的には、アルゴリズムをフローチャートに似た形で表現したものです。プロセスにおける各ステップは、アクティビティーと呼ばれます。プリミティブなアクティビティーがいくつかあって、なんらかのWebサービスの操作を呼び出したり (<invoke>)、サービスのインターフェースを操作するメッセージが外部のユーザーから呼び出されるのを待ったり (<receive>)、入出力操作の応答を生成したり (<reply>)、しばらくの間待機したり (<wait>)、ある場所から別の場所にデータをコピーしたり (<assign>)、なんらかの障害の発生を通知したり (<throw>)、サービス・インスタンス全体を終了したり (<terminate>)、あるいは何も行わなかったり (<empty>) する働きを担っています。

BPEL4WS言語で提供される構造アクティビティーを使用して、こうしたプリミティブなアクティビティーを結合することにより、より複雑なアルゴリズムを作ることができます。これらの機能により、一定の順序のステップ (<sequence>) を定義したり、現在一般的になっている「caseステートメント」手法による分岐を行ったり (<switch>)、ループを定義したり (<while>)、いくつかの代替パスのうちのいずれかを実行したり (<pick>)、ステップの集合を並列に実行すべきことを指示したり (<flow>) することができます。並列的に実行されるアクティビティーの中で、links を使用して実行順序の制約を示すことができます。

BPEL4WSでは、構造化されたアクティビティーを再帰的に結合して、サービスの実装を表す任意の複合アルゴリズムを表現することができます。

他のサービスとの相互作用: パートナー

いくつかのサービスをまとめて新規サービスを作り上げるための言語としてのBPEL4WSのプロセスは、主として、他のサービスへの呼び出しを行うこと、またはクライアント (図1 に示したサービスのユーザー) からの呼び出しを受けること、あるいはその両方からなります。前者は<invoke> アクティビティーを使用して行われ、後者は<receive> および<reply> アクティビティーを使用して行われます。BPEL4WSは、プロセスと相互作用する、こうした他のサービスをパートナー と呼びます。したがって、パートナーは、そのアルゴリズムの実装の一部としてプロセスが呼び出すサービス (被呼び出しパートナー)、またはプロセスを呼び出すサービス (クライアント・パートナー) のいずれかです。

最初のパートナー(被呼び出しパートナー)がどういう種類のものであるのかは、説明するまでもありません。プロセスが何かをするためには、他のサービスを呼び出さなければなりません。<invoke> アクティビティーは、呼び出すパートナーを示し、また、そのパートナーのportType のうちのどれに関して、どのような操作をそのパートナーに対して行うのかを指示します。ただし、被呼び出しパートナーは、クライアントとなることもありますので注意してください。プロセスが、なんらかのサービスを要求するために、パートナーに対する操作を呼び出すことがあります。その後パートナーが、必要なデータを提供するために、プロセスに対する操作を呼び出すことがあります。

プロセスのクライアントをパートナーとして扱う理由は、あまり分かりやすくありません。実際には、2つの理由があります。最初の理由は、プロセスがそのクライアント・パートナーの1つに対する操作を呼び出さなければならない場合があるからです。これは主に、非同期相互作用をどのようにサポートするのか、ということに関係します。クライアントは、なんらかのサービスを要求するためにプロセスに対する操作を呼び出します。その操作が完了すると、プロセスがクライアント・パートナーに対する操作を呼び出します。その時点では、クライアント・パートナーと被呼び出しパートナーの区別はなくなります。

2番目の理由は、プロセスによって提供されるサービスが (全面的に) 複数のクライアントによって使用される可能性があるからです。さらに、プロセスがこれらのさまざまなサービスのユーザーを区別する必要が生じることがあります。例えば、融資サービス・システムを表すプロセスは、単一のWebサービスを提供しますが、融資を申し込む顧客はそのサービスの一部にしかアクセスできず、その他の部分は顧客サービス担当者向けであり、最後に、融資の保証人はサービス全体にアクセスすることができます。操作が顧客によって呼び出されるのか保証人によって呼び出されるのかに応じて、戻される振る舞いがまったく異なる可能性があります。さらに、パートナーを使用してクライアントをモデル化するという手法を取ることにより、プロセスは、特定の操作が特定のクライアントによってのみ呼び出されることを指定できるようになります。

したがって、パートナーは次のいずれかになります。

  • プロセスが呼び出すのみのサービス。
  • プロセスを呼び出すのみのサービス。
  • プロセスが呼び出し、プロセスを呼び出すサービス (いずれかが先に行われます)。

最初の2つは、それぞれ、単純な被呼び出しパートナー とクライアント・パートナー です。3番目の場合のプロセスとサービスの関係で、プロセスがサービスを先に呼び出す場合について考えてみましょう。つまり、サービスがportType (PT1) を提供 (あるいは公開) し、プロセスがそのportTypeの操作を呼び出します。また、このプロセスは、サービスが操作を呼び出すために使用する、portType (PT2) も提供しなければなりません。したがって、プロセスの側から見ると、プロセスがサービスからportType PT1を要求し、サービスに対してportType PT2を提供することになります。同じ関係をサービスの側から見ると、逆のことが言えます。つまり、サービスがプロセスに対してportType PT1を提供し、プロセスからportType PT2を要求することになります。この状況は、プロセスがサービスを呼び出す場合も、その逆の場合も同じです。

サービス・リンク・タイプ
3番目の種類のパートナーをモデル化することにより、サービス・リンク・タイプ が生まれました。サービス・リンク・タイプは、サービスとプロセスの関係をそれらのいずれか一方の観点から定義するのではなく、2つ (あるいはそれ以上の場合もあり得ます) のサービスの間の関係を第三者の観点から宣言したものです。サービス・リンク・タイプは役割(role)の集合を定義し、それぞれの役割はportTypeのリストとして表されます。つまり、2つのサービスが相互作用する場合、サービス・リンク・タイプは、それらがどのように相互作用するのか (基本的には各当事者が何を提供するのか) を宣言するものとなります。

BPEL4WSは、サービス・リンク・タイプを使用してパートナーを定義します。基本的に、パートナーの定義は、パートナーに名前を割り当ててから、サービス・リンク・タイプの名前を指定し、そのサービス・リンク・タイプの中でプロセスが果たす役割と、パートナーが果たす役割を識別することによって行われます。純粋な被呼び出しパートナーと純粋なクライアント・パートナーの場合には、サービス・リンク・タイプは1つの役割だけを持っていますので、パートナーを定義するときには1つの役割だけしか割り当てられません。このパートナー名は<receive><reply>、および<invoke> アクティビティーで、必要なパートナーを指定するために使用されます。

サービスの参照
実行時には、パートナーはどのように機能するのでしょうか?パートナーは、実行時に実際のWebサービスに名前解決される必要があります。したがって、パートナーとは、結局は型を持つサービス参照 であり、その場合の型指定とは、サービス・リンク・タイプおよびその中で果たす役割によって指示されたものになります。BPEL4WSプロセス自体は、パートナーが特定のサービスにどのように結合されるのかを指示しません。この結合方法は、デプロイメント時に考慮されるか、あるいはBPEL4WS実装がサポートする必要のある実行時結合ステップで考慮されます。

問題への対処

開発者には、ビジネス・プロセスのエラーを処理し、そこから回復するための方法が必要です。BPEL4WSでは、<throw> および<catch> コンストラクトにより、例外 (障害) が言語に組み込まれています。BPEL4WSにおける障害の概念は、WSDLにおける障害の概念と直接関連していて、実際、その概念を基礎に構成されています。

また、BPEL4WSは補償(compensation) という観念をサポートします。これは、プロセス設計者が特定の不可逆アクションに対応する補償アクションを実装できるようにするための技法です。例えば、旅行予約プロセスについて考えてみましょう。予約が確認された後では、なんらかの明示的な操作を行わなければ、その予約を取り消すことはできなくなります。そのようなアクションを、オリジナル・アクションに対応する「補償アクション」と呼びます。

BPEL4WSでは、再帰的な障害の処理および補償は、有効範囲という概念を導入することによってサポートされます。この有効範囲は、基本的には障害の処理または補償、あるいはその両方の単位です。補償および障害処理の詳細は、単独のトピックとして扱うべきですので、今後の記事で説明することにします。

サービスのライフ・サイクル

これらのサービスのライフ・サイクルはどのようになっているのでしょうか?BPEL4WSプロセスとして実装されたWebサービスには、インスタンスに基づいたライフ・サイクル・モデルが組み込まれています。つまり、これらのサービスのクライアントは、常にそのサービスの特定のインスタンス (プロセス) と相互作用します。それでは、クライアントはどのようにしてサービスのインスタンスを作成するのでしょうか?

従来の分散オブジェクト・システムとは異なり、BPELWSにおけるシステムは画一的なパターンによって作成されることはありません。BPEL4WSでは、インスタンスは、サービスのためにメッセージが到着したときに暗黙的に作成されます。つまり、インスタンスは明示的な「インスタンスID」概念によって識別されるのではなく、データ・メッセージ内にあるいくつかのキー・フィールドによって識別されます。例えば、プロセスが注文処理システムを表している場合、送り状の番号が、相互作用に必要な特定インスタンスを識別するための「キー」フィールドとなることがあります。したがって、あるメッセージがプロセスにおける「開始可能」点に到着したときに、適合するインスタンスがない場合には、新規インスタンスが自動的に作成され、メッセージから検出されたキー・データに関連付けられます。適切なインスタンスが見付かった後では、メッセージは、非開始可能点のみで受け入れることができるようになります。つまり、そのような場合、実際にはメッセージは常に特定のインスタンスに送達されます。BPEL4WSでは、適切なインスタンスを検出したり、必要に応じて作成したりするプロセスは、メッセージ相関(message correlation)と呼ばれます。メッセージ相関についても、今後の記事で取り上げます。


結論

今回の記事では、BPEL4WSの主要な基礎概念について簡単に述べました。BPEL4WSとはどういうものであるのかという概要について考えた後で、パートナー、障害、補償、およびライフ・サイクルについて考えました。このシリーズの今後の記事では、BPEL4WSの特定の側面について詳しく論じる予定です。

[編集者による注: このコラムでは、BPEL4WSの背後にある概念に関するシリーズと、それらの概念を技術的に実装する方法に関するシリーズが、交替で掲載される予定です。次回は、技術的な実装について紹介します。]

参考文献

コメント

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=SOA and web services
ArticleID=241843
ArticleTitle=ビジネス・プロセス: BPEL4WSについて 第1回
publish-date=08012002