JP2011129150A - ビジネスプロセスの自動化 - Google Patents

Abstract

【課題】組織および/または個人の中および間のビジネスプロセスが自動化されるシステムおよび方法の提供。
【解決手段】XMLおよびウェブ・サービス標準に基づいた標準型サービス指向ビジネスプロセス自動化アーキテクチャを使用して、組織および/または個人の中および間のビジネスプロセスが自動化されるシステムおよび方法が説明される。ビジネスプロセスの実行フレームワークも説明される。更なる局面は、ビジネスプロセス仕様をビジネス・フロー、ビジネス規則、およびビジネス状態へ解体する分解方法論を含む。ビジネス・フロー、規則、および状態は宣言型言語で定義され、フロー、規則、および状態エンジンの間のインタラクション、協力、および調整、ならびにフレームワーク内のビジネスプロセス実行モデルを含む。
【選択図】図９

Description

1 関連出願情報
本出願は、2003年6月12日に出願されたSubhra Bose, Steve Scimone, Nallan Sriraman, Arthur Bernstein, Philip C. Lewis, Radu Grosu, Ziyang Duanへの「ビジネスプロセスの自動化（Business Process Automation）」と題する米国仮出願第60/477,757号への優先権を主張する。この出願の内容は、参照してその全体を本明細書に組み入れられる。

2 発明の分野
本発明の局面は、ソフトウェアおよびビジネス・アプリケーションに関する。更に具体的には、本発明の局面は自動化ビジネス・アプリケーションに関する。

3 発明の背景
ビジネスプロセスは、幾つかのビジネス目的を達成するため、具体的ビジネス規則に従ったビジネス活動を共同して実行することである。ファイナンシャルサービスおよび他のビジネスは、ビジネスプロセスのリエンジニアリングに多大の努力を投入し、コストを低減して効率を改善してきた。最近のコンピュータおよび情報技術の急速な進歩に助けられて、伝統的に手作業で実行されていたファイナンシャルサービスおよび他の産業の複雑なビジネスプロセスを、現在では自動化できる。これは多くの新しいチャレンジをもたらす。即ち、1）ビジネスプロセスは容易に作成され、展開され、更新される必要があること、2）ビジネスプロセスは相互運用可能に構築されて、異なった組織および部門はビジネスプロセスを一緒に統合できること、3）ビジネスプロセスの正しさおよびセキュリティは保証される必要があること、4）ビジネスプロセスの管理および再使用性を容易にするツールが必要であることである。

XMLは、ワールド・ワイド・ウェブのデータ表現および交換の新しい標準として出現した。様々な異種システムの間で相互運用性を容易にするため、ますます多くのアプリケーションがXMLに基づいて作られてきた。XMLスキーマは、半構造化データ・タイプをXMLで指定する標準になってきた。半構造化データ・タイプ、およびそれらの関係データとの関係を理解する上で、多くの作業が行われた。ウェブ・サービス・プロトコル、例えばSOAP、WSDL、およびUDDIは、サービスのユビキタスな相互運用性を提供し、ビジネスプロセスにおける高度分散サービスの調整を可能にする。クエリーおよび更新能力を有するXMLデータ記憶装置を提供するため、ネイティブXMLデータベースが市場に出現している。

ワークフローは当技術分野において公知であり、システム・コンポーネントから制御論理を分離して制御論理を高レベルで指定する方法を提供する。ワークフロー管理連合によれば、ワークフローはビジネスプロセスの計算モデルである。ワークフロー・システムは、元来、オフィスの自動化のために開発された。それらのシステムは、単純な仕事、例えば文書処理およびファイル共有を標的としている。こうして、人々はビジネスプロセスをモデル化する更に複雑な業務ワークフローを考察するようになってきた。原子性および隔絶性が緩和された業務モデルに基礎を有する様々な拡張業務モデルは、データベース業務から継承された素晴らしい理論的フレームワークを有する。しかし、商用システムの中に実装される業務モデルはほとんどない。ワークフロー・モデルは、それらを一般化し、はるかに広い機能を提供し、複雑なビジネスプロセスに対処する更に適切なフレームワークである。過去数年の間、多くの商用システムが開発された。例えば、TibcoのBPM、MicrosoftのBizTalk、IBMのExotica/FlowMarkなどである。多くの研究試作品が作り出された。例えば、ConTractおよびMentorなどである。多くの公式的方法が、ワークフローのモデリングおよび実行のために提案された。即ち、事象代数学、状態図、ペトリ・ネット、時相論理、業務論理などである。ワークフローをウェブ・サービスのインタラクションとして定義およびモデル化するXML型標準が提案された。例えばBPML、WSCL、WSCI、BPEL4WSなどである。

規則エンジンも、数年の間開発されてきた。現在、IBM、Microsoft、iLog、Blazesoftその他によって提供される幾つかの標準および商用システムが存在する。規則エンジンは規則定義を消費し、異なったタイプの規則、例えば確認規則、ビジネス方針規則、およびビジネス決定を実行することができる。異なったタイプの規則エンジンも存在する。例えば推論エンジンおよびデシジョン・トリー・エンジンである。ビジネスプロセスは、多くの場合、多数のビジネス規則を含む。大部分のプログラミング環境は、データまたは手順のために設計されているから、規則の集合として書かれたビジネス仕様に直面する場合、開発者はややこしい問題に直面する。規則はデータで表現することはできず、規則を手順的にコーディングすることは「スパゲティコード」へ導く。更に、宣言型形態を取り、理解するのに容易な規則の当初の論理構造はコード内で失われ、デバッグが困難となり、必要となる場合の更新がほとんど不可能である。規則を記述するため、幾つかの標準が出現している。1つのそのような標準、即ちRuleMLは、XMLマークアップ、形式的意味論、および効率的実現方法を使用する規則の標準的ウェブ言語である。RuleMLは、誘導規則から変換規則および反応規則まで、全体の規則スペクトルをカバーする。したがって、RuleMLは、ウェブ存在論の中のクエリーおよび推論、ウェブ存在論の間のマッピング、およびワークフロー、サービス、およびエージェントのダイナミックなウェブ動作を指定することができる。

状態機械は、反応システムをモデル化するために広く使用されてきた。当初の有限状態機械は、Statechartのように、階層および並行性を表現するように拡張された。意味論を定義し、状態機械に基づくモデリング・ツールを作るため、多くの作業が行われた。ソフトウェア設計言語およびツール、例えばUML、ROOM、およびSTATE-MATEが、状態機械の変形を使用した。これらの技術が存在しても、ビジネスプロセスの自動化および管理には、依然として問題が残っている。

4 要約
本発明の局面は、ビジネスプロセスの自動化および管理における上記の問題の少なくとも1つを解決するフレームワークおよび方法を提供する。このフレームワークにおいて、ビジネスプロセスは、フロー、規則、および状態機械の統合としてモデル化されてよい。相互運用性を提供する基礎として、XMLおよびウェブ・サービス標準が使用されてよい。ビジネスプロセスおよびそのコンポーネントを高レベルで指定するため、標準ベースの宣言型言語が使用されてよい。指定は形式的論理モデルに基づいて行われてよく、正しさを保証するため自動検証およびモデル・チェック方法を展開することができる。意味論は形式的に定義されてよく、意味論ベースの検証およびワークフロー合成方法が提供される。

本発明の局面は、フロー、規則、および状態エンジンの向上した使用を提案する。ビジネスプロセスは、ビジネスプロセス内の制御、外部化されたビジネス規則、およびビジネス・エンティティの状態を表す宣言型言語、例えばXMLで指定される。指定の関連部分は、フロー、規則、および状態エンジンで実行される。これらのエンジンの各々は、本発明の少なくとも1つの局面で説明される実行環境へ具体的計算局面を提供する。

ビジネスプロセスの主要な成分を宣言型構文論で記述する能力は、ビジネス要件と技術実装と間のインピーダンス不整合を低減する。本明細書で説明される方法論は、ビジネス系および技術系の人々の思考プロセスへ、設計の要件分析から実装までの均一構造をもたらす。この方法論によるビジネスプロセス・アプリケーションの作成は、開発者を強制してインフラストラクチャ・コードよりもビジネス・アプリケーション論理に集中させる。フレームワークは、設計パターンおよび例外処理の集合を固く守ることによって、ビジネスプロセス実行中の信頼性を提供する。フレームワークは、更に、再使用可能なビジネス活動の在庫を作り出す能力を提供する。この在庫は進化するにつれて、アプリケーション開発時間を著しく低減する。

ビジネスプロセスの自動化に関連する前述の問題の観点から、本発明の少なくとも1つの局面は、XMLおよびSOAP、WSDL、WSIL、UDDI、およびBPEL4WSを非限定的に含むウェブ・サービス標準に基づく標準型サービス指向ビジネスプロセス自動化アーキテクチャを使用して、組織および/または個人の中および間のビジネスプロセスが自動化されることのできるシステムおよび方法を提供する。本発明の少なくとも1つの局面は、ビジネスプロセスの実行フレームワークをさらに含む。ビジネスプロセスは、単純および複雑な機械および人間のワークフロー、ビジネス規則の評価、ビジネス・エンティティのライフサイクル管理、および既存アプリケーションとの統合に関連するファイナンシャル・ビジネスプロセス・アプリケーションを含むが、それに限定されるわけではない。

更に、本発明の少なくとも1つの局面は、ビジネスプロセス仕様のためにビジネス・フロー、ビジネス規則、およびビジネス状態への分解方法論を提供する。ビジネス・フロー、規則、および状態は、標準または特注XML型言語を非限定的に含む宣言型言語で定義される。本発明の少なくとも1つの局面は、宣言型構文論で記述されたビジネス・フロー、規則、および状態を、商用および/または特別作成のフロー、規則、および状態エンジンで実行時に実行するシステムおよび方法を含む。本発明の少なくとも1つの局面は、フロー、規則、および状態エンジンの間のインタラクション、協力、および調整、ならびにフレームワーク内のビジネスプロセス実行モデルを含む。

本発明の更に他の局面において、ビジネスプロセス記述は、所定の分類法の集合に従って分類される。これは、分類法カテゴリー内の所与の名前について、更にビジネスプロセスが与えられると、それが指すカテゴリーおよび名前について、ビジネスプロセス定義をサーチするメカニズムを含む。本発明の少なくとも1つの局面は、レジストリ、ディスカバリ、モニタ、サービス水準合意（SLA）管理、およびSLAの自立的履行を含むフレームワーク内で実行しているビジネスプロセスの管理をさらに含む。

他の局面において、本発明はビジネスプロセスおよびそれらのコンポーネントの意味論を定義する形式的メカニズムを提供する。これは、厳密な数学モデルによってサポートされて事前条件および事後条件を非限定的に含むアサーションの構文論でビジネスプロセス指定を注釈することによって行われてよく、したがって設計時および実行時に意味論の正しさを自動的に検証することができる。本発明の少なくとも1つの局面は、設計時および実行時にビジネスプロセスの意味論的正しさを自動的に検証および保証するメカニズムを含む。システムは、ビジネスプロセスの宣言型指定の意味論的チェックおよびモデル・チェックによって正しさを達成する。

更に、本発明の少なくとも1つの局面は、意味論的に定義可能なビジネス活動またはタスクのライブラリを構築する方法を提供することである。これは、意味論的に定義可能なたコンポーネントのライブラリおよび新しいワークフローのビジネス目的に基づき、ビジネスプロセスの中で、または横断して、例外フローを非限定的に含む新しいワークフローを自動的に構築することを可能にする。本発明の少なくとも1つの局面は、そのような自動的ワークフローを生成するアルゴリズムを含む。

本発明のなお更なる局面は、ビジネスプロセス・アプリケーションのビジネス論理とプレゼンテーション論理との間を疎結合する方法を提供することである。

本発明の局面に従ったフロー、規則、および状態、ならびにそれらの間のインタラクションの論理的表現を提供する。 本発明の局面に従った取引ワークフローの例を提供する。 本発明の局面に従ったポートフォリオ検索の例を提供する。 本発明の局面に従ったビジネスプロセス定義言語のグラフ表現を提供する。 本発明の局面に従ったコーポレート動作ワークフローの一部分を形成するタスク・ライブラリの例を提供する。 本発明の局面に従ったシーケンスの構成体のグラフ表現を提供する。 本発明の局面に従ったスイッチの構成体のグラフ表現を提供する。 本発明の局面に従ったループの構成体のグラフ表現を提供する。 本発明の局面に従ったユビキタス計算環境におけるビジネスプロセス管理のグラフ表現を提供する。 本発明の局面に従ったビジネスプロセス実行フレームワークにおけるモデル・チェックの例を提供する。

6 詳細な説明
本発明の局面は、組織および/または個人の中および間のビジネスプロセスが、XMLおよび非限定的にSOAP、WSDL、WSIL、UDDI、およびBPEL4WSを含むウェブ・サービス標準に基づいた標準型サービス指向ビジネスプロセス自動化アーキテクチャを使用して自動化されるシステムおよび方法に関連する。本発明の少なくとも1つの局面は、ビジネスプロセスの実行フレームワークをさらに含む。ビジネスプロセスは、単純および複雑な機械および人間のワークフロー、ビジネス規則の評価、ビジネス・エンティティのライフサイクル管理、および既存のアプリケーションとの統合に関連するファイナンシャル・ビジネスプロセス・アプリケーションを含むが、それに限定されるわけではない。本発明の局面は、ビジネスプロセス仕様をビジネス・フロー、ビジネス規則、およびビジネス状態へ解体する分解方法論にさらに関連する。ビジネス・フロー、規則、および状態は、宣言型言語で定義され、フロー、規則、および状態エンジンと、フレームワーク内のビジネスプロセス実行モデルとの間のインタラクション、協力、および調整を含む。

本明細書で説明される様々なビジネス・フロー、規則、および状態は、コンピュータ読み取り可能メディアに存在してよい。このメディアは、取り外し可能メディア、固定メディア、光学および磁気記憶装置などを含むが、これらに限定されるわけではない。例えば、本発明の局面は、ホスト・コンピュータまたはコンピューティング・ネットワークまたはクライアント側コンピュータに常駐してよい。

以下の説明は、読者を助けるため次のように分割される。
6.1 フロー、規則、および状態（FRS）へのビジネスプロセスの分解
6.2 BPDおよび成分フロー、規則、および状態の分類法
6.3 BPIの宣言型仕様
6.3.1 フロー仕様
6.3.2 動作の意味論
6.3.3 ワークフロー内の異なった点におけるアサーション
6.4 BPI実行フレームワーク
6.4.1 フロー、規則、および状態エンジン
6.4.2 BPIフロー、規則、および状態の間の調整
6.4.3 BPIの管理
6.5 ビジネスプロセス・ワークフローの正しさ
6.5.1 ワークフローを自動的に注釈する
6.5.2 ワークフローの正しさを自動的に検証する
6.6 ビジネスプロセスのモデル・チェック
6.6.1 モデル・チェックのアプローチ
6.6.2 設計時のモデル・チェック
6.6.3 実行時のモニタリング
6.7 ビジネス・ワークフローの自動的合成
6.8 BPIフレームワーク型アプリケーション（可能な例であるが、これらに限定されるわけではない）
6.8.1 コーポレート動作管理
6.8.2 市場データ、ポートフォリオ、および遵守アプリケーションとの発注管理システムの統合
6.8.3 データ管理システム

次のセクションは、本発明の局面に従って使用されてよい例示的スキーマおよび例示的インスタンスに関連する。
7 スキーマおよび例示的インスタンス
7.1 スキーマ1：BPDLスキーマ
7.2 交渉プロセスの具体的データ・モデルのXMLスキーマ仕様
7.3 交渉データ・モデルのインスタンス
7.4 高レベル・データ・モデルの例

6.1 フロー、規則、および状態（FRS）へのビジネスプロセスの分解
ビジネスプロセス管理（BPM）は、ビジネスの世界で益々重要になっている。会社は、コストを低減し効率を改善するためビジネスプロセスを自動化しようと試みている。更に、会社は、高速で変化する市場の挑戦に立ち向かうため、新しいプロセスを迅速に統合して既存のプロセスに適合化する能力を必要としている。

ビジネスプロセスは、簡単に言えば、或るビジネス目的を達成するため、具体的ビジネス規則に従った活動の共同実行である。活動とは、コンピュータ・システムによって自動的に実行されるか、人間によって手作業で実行される作業の単位である。コンピュータまたはコンピュータ・人間のインタラクションによって実行される活動が、本明細書で考察される。次の2つの例は、或る典型的なビジネスプロセスを示す。

例1（図2）：この例は2人の取引業者AおよびBの間の交渉プロセスを示す。このプロセスのビジネス目的は、取引上の合意に達し、次に確認プロセスを介して取引を決済することである。プロセスは、取引業者AがBとコンタクトして提案を行う（例えば、1000株の株式Aを或る価格で売る）場合に開始する。もしBが提案を受け入れ、反対提案を行うならば、AおよびBは、1人の当事者が取引を中止するか相互の合意に達するまで、交渉を開始する。もし合意に達すれば、取引は確認および決済される。もし2人の取引業者が同じ金融支店に属していれば、決済を直ちに行うことができる。そうでなければ、各々の当事者は取引を別々に決済しなければならない。

例2（図3）：この例において、ファイナンシャル・アドバイザは、顧客名で顧客のポートフォリオ情報を検索したい。ファイナンシャル・アドバイザは、まず顧客データベースをサーチするため顧客名をタイプする。サーチ規準とマッチする名前を有する各々の顧客の要約情報が、グリッド・ビューにリストされる。もしただ1人の顧客がリストされるならば、そのポートフォリオ情報が検索されて自動的に提示される。そうでなければ、アドバイザは1人の顧客をリストから選択し、その顧客のポートフォリオ情報の提示を要求する。

ビジネスプロセス管理システムは、自動化ビジネスプロセスを設計、展開、および管理する能力を提供する。それは、所与の活動をビルディング・ブロックとして使用し、所与のビジネス規則に従ってビジネスプロセスを設計するツールを提供する。それは、組織の中でビジネスプロセスを展開および管理するファシリティを提供する。更に、それは、ビジネスプロセスの実行を制御し、実行中に活動を調整するフレームワークを提供する。

ビジネスプロセスは益々複雑になっており、より分散した異種の環境で、自動化およびスチームライン化したビジネスプロセスの必要性が大きくなっている。ビジネスプロセスに含まれる活動は、一般的に、組織内の異なったグループからの活動または異なった組織にわたる活動を含む。それらの活動は、おそらく、異なったコンピュータ言語で実現され、異なったプラットフォーム上で実行され、異なったプロトコルを使用してインタラクションを行う。これらの活動の間の調整、およびビジネスプロセスにおけるそれら活動の追跡は困難な問題である。

最近、ウェブ・サービスの広範な採用は、全世界相互運用コンポーネント・モデルの約束を達成し始めた。具体的には、それは、ビジネスプロセス管理における再使用可能性および言語/プラットフォーム独立性を可能にする。異なった言語および異なったプラットフォームで実現されるコンポーネントは、相互運用性を達成するためウェブ・サービスとしてパッケージされることができる。XML型ウェブ・サービス言語（例えば、SOAP、WSDL、UDDI）は、実現方法をインタフェースから切り離す。その結果、組織は、理論的に、最良品種のウェブ・サービスをビルディング・ブロックとして使用し、全体のソリューションを作り出すことができる。ウェブ・サービス標準は、「生産準備完了」の程度まで成熟し、受け入れが増加するにつれて発展し続けている。企業アプリケーション統合（EAI）およびビジネス対ビジネスおよびビジネス対消費者のインタラクション（B2B/B2C）を達成するため、企業の中で使用されるウェブ・サービスは、ますます多くなってきている。

しかし、ウェブ・サービスの技術的成熟とは対照的に、ウェブ・サービスの編成によってビジネスプロセス管理を可能にするツールは、比較的に原始状態のままである。現実世界のビジネスプロセスを、どのようにしてウェブ・サービスおよびメッセージ・フローの集合体として表現するか。大部分の場合、熟練した統合者が「マスタ・アプリケーション」を作り出す。マスタ・アプリケーションはコンポーネント・ウェブ・サービスを適切な順序で呼び出し、それらウェブ・サービスによって使用されたキー値を追跡し、結果を集積し、その他のことを行う。この「ビジネス論理をコーディングする」アプローチは、当座のビジネス要件を成功裏に満たすことができる意味で働くが、コンポーネント・モデルの利益をテコ入れすることはできない。即ち、「製品化されたソリューション」ではなく、そのような「ポイント・ソリューション」が作り出される場合、ビジネス意味論における繰り返しパターンは、繰り返し機能のようには容易に再使用され得ない。それらの繰り返しパターンは、多くの場合、次のソリューションが現れるように新しくコーディングされる必要がある。更に悪いことに、再使用性を取得する努力の中で、ビジネス意味論的考慮がウェブ・サービス自身の中へプッシュされる傾向があり、コンポーネント・モデルを崩壊させ、ウェブ・サービスの再使用可能性を低減させる。より高いレベルのビジネス抽象概念をモデル化する十分な手段がないと、ビジネスプロセスのフロー、データ、および規則に関連づけられたIPRは失われる。

本発明の少なくとも1つの局面は、既存のウェブ・サービス標準に基づいたビジネスプロセス管理フレームワークである。ビジネスプロセス・インスタンス（BPI）の用語は、任意レベルの細分性を有し、ビジネス・フロー、規則、および状態を含む自動化ビジネスプロセスとして定義される。より大きなビジネスプロセスの自動化を表すため、複数のBPIを階層へ組織化することができる。ビジネスプロセス・インスタンスの定義はBPDと呼ばれる。本発明の少なくとも1つの局面は、非伝統的方式でビジネスプロセス定義（BPD）を作り出す方法論を含み、ビジネスプロセス・インスタンス（BPI）を実行するフレームワークを含む。本発明の少なくとも1つの局面は、XML型言語のビジネスプロセス定義言語（BPDL）を含み、ビジネスプロセスを宣言型で指定する。BPI仕様は、ビジネスプロセスがどのように実行されるかを定義するだけでなく、プロセス実行の正確な「意味」、即ちプロセスが何を行うように想定されているかを定義する。言い換えれば、ビジネスプロセスの意味論は、その実行時の動作に加えて、形式的に定義される。BPIフレームワークと呼ばれるビジネスプロセス管理フレームワークは、ビジネスプロセスを定義、展開、管理、および実行するツール、コンポーネント、および環境を提供する。

BPIは、活動およびデータ・エンティティを、そのビルディング・ブロックとして使用する。全ての活動はウェブ・サービス・インタフェースをWSDLで公開し、したがってウェブ・サービスとして取り扱われることが仮定される。データ・エンティティは、XMLスキーマによってモデル化されるXML文書としてアクセスされ得る。BPDLは、ビジネスプロセスを3つのコンポーネント、即ちフロー、規則、および状態へ分解することによってビジネスプロセスを記述する。フローは、活動の間の制御論理およびデータ・フローを定義する。規則は決定方針を定義し、状態は状態遷移モデルとの関係でビジネス・データ・エンティティの正規の動作を定義する。

BPIを作り出す場合、ビジネスプロセスの平明な英語記述が、その成分ビジネス・フロー、規則、および状態へ分解される。第1レベルの分解は、Unified Modeling Language（UML）または類似の表記法で構造化英語および図式を組み合わせることである。UMLシーケンス図式および活動図式は、ビジネスプロセスの活動の間の実行順序および論理依存情報を捕捉し、したがってBPDフロー仕様の基礎を形成する。UML状態図式は、ビジネス・エンティティの状態遷移を捕捉し、BPD状態モデルの基礎を形成する。規則は、一般的に、フロー内の決定点または状態図式内の状態遷移に関連づけられる。規則は、フローまたは状態から分離される。なぜなら、第1に、規則は変わるかもしれないが、フローまたは状態モデルの一般的構造は同一に保たれるからである。第2に、同じ規則が異なった状況で使用されるかもしれない。第3に、ビジネス規則を外在化し、ビジネス規則を変える権能をビジネス・ユーザに与えることが可能になる。したがって、フロー、規則、および状態は、BPDLの宣言型形式で別々に指定される。

BPDフロー仕様言語はBPEL4WSに基づく。BPEL4WSはウェブ・サービス編成プロトコルまたはワークフローを定義するXML型標準である。WSDLおよびBPEL4WS言語は拡張され、ウェブ・サービス操作およびBPEL4WSワークフロー上で形式的意味論を注釈することができる。

XML型ビジネス規則言語（BRL）は、様々なタイプのビジネス規則の言語中立記述として使用される。

XML型状態機械言語のStateMLは、異なったビジネス・エンティティの状態遷移モデルを指定するために使用される。

BPD仕様は、フロー、規則、および状態の仕様を直接には含まない。その代わりに、BPD仕様は或るレベルの回り道を追加することによって、それらの定義を参照する。次の記載は、取引交渉プロセスにおけるBPD仕様の簡単な例である。

6.2 BPDおよび成分フロー、規則、および状態の分類法
BPIは、コンポーネント指向ソフトウェア開発におけるコンポーネントと類似している。コンポーネント指向ソフトウェア開発の欠点の1つは、膨大な数のコンポーネントが相互に重複し、それを避ける中央コンポーネント・リポジトリまたはコンポーネント関連情報が存在しないことである。ウェブ・サービス・パラダイムにおいて、この問題はUDDIの概念によって解決される。UDDIは、ウェブ・サービスに関するメタ情報のリポジトリとして使用され得る。BPIはウェブ・サービスとして開示されるから、BPIの場合にも同じ手法が有効である。BPDLによるBPI定義は、BPIおよびその成分フロー、規則、および状態の分類情報を含む。BPIの分類法は、図4で示されるように、BPDL文書のノードとして捕捉される。

6.3 BPIの宣言型仕様
ビジネス要件が本発明者らの3つの主要なコンポーネント・カテゴリへ適切に分解されると、XML型ビジネスプロセス定義言語であるBPDLを介して、要件をBPD文書の合成集合として表現することができる。BPDLのW3Cスタイルのスキーマがスキーマ1で示され、図4でグラフとして表される。

BPDLはルート要素<BPD>の下に主要な要素、即ち<Flows>、<RuleSets>、<StateModels>、<Entities>、<SubBPDs>、および<Views>を含む。本発明者らは、BPD内のフロー、規則、および状態モデルの場所を既に説明した。ビューは、他の要素が再使用可能バックエンド能力を提供する同じやり方で再使用可能GUI能力を提供する。エンティティは、ビジネスプロセスに関連したXMLスキーマに基づいて、名前の付いたビジネス・エンティティを指す。サブBPIは、個々のコンポーネントが再使用される同じ方法で、既存のBPIが再使用されることを可能にする。これら主要な要素の各々は一つまたは複数の部分要素を含む。部分要素は、部分要素の共通集合の使用を介して親集合物の単一インスタンスを示す。スキーマ1で捕捉されるスキーマを有するこの集合は、主要な要素の実行時および設計時調整に必要な情報を提供する。これらの共通要素は、更にBPD要素自身へ適用され、したがって他のBPDは階層様式でそれを参照してよい。

BPD要素は、更に、サーチを容易にする分類法情報を保持する要素を含む。BPDの適切な分類法的分類は、ビジネスプロセス再使用の値を取得するため絶対に必要である。分類法的要素は、確立された用語辞書に関してBPIの機能および目的を識別するデータを含む。BPDが分類法的タグと一緒にBPDリポジトリに記憶される場合、BPI設計ツールは、この情報を解析して、或るタイプのビジネスプロセスを探索している開発者の利用に供することができる。

共通の部分要素の集合の中で、1つはBPI設計ツールによって排他的に使用され、他の2つは主としてBPI実行時エンジンによって使用される。前者のカテゴリとして<Description>がある。これは要素および注釈特徴の目的を普通の書き方で要約したものである。この要約は、BPIコンポーネント・リポジトリ内のコンポーネントをブラウズする場合、開発者へ表示される。他の2つの要素は、コンポーネントの解決および呼び出し手段を提供する。＜URI＞は、具体的コンポーネントの一意のリソース識別子を指定して、BPIエンジンがそれを特定して呼び出すことができるようにする。これは、BPDLがコンポーネント自身について詳細を提供せず、それらを一緒に結合する方法だけを提供するという全体的見解に沿ったものである。もし＜URI＞が結合される部分を指定すれば、<Name>要素が結合を行う糸である。<Name>はBPI名をコンポーネントへ与え、それによって他のBPI準備完了コンポーネントは、それを参照することができる。これらの名前は、BPDの中、および階層BPD集合の大きいコンテキストの中で、一意に解決可能でなければならない。

BPIフレームワークは、2つの基本的概念の使用によってフロー、規則、および状態の調整統合を可能にする。第1の概念は、相互抽象呼び出しである。これは、フロー、規則、および状態エンジンが、BPIフレームワークへ渡された指名参照を介して相互を呼び出す能力を意味する。確かに、フロー、規則、および/または状態がBPI技術を利用しないで一緒に結合されることは可能である。例えば、フローは規則を呼び出して、どのフロー・パスを取るかを決定することができる。規則は、偽と評価すれば状態遷移を要求することができる。状態遷移はフローの実行をトリガして、遷移の複雑なログを提供することができる。しかし、この直接参照ストラテジの欠点は、調整が静的で、具体的参照がフロー、規則、および状態機械の中へ組み込まれることである。BPIはこの関係を抽象化し、BPI準備完了フロー、規則、および状態機械は、アドレスではなくBPI名によって相互を参照する。もし本発明者らが、所与のBPIを記述するBPDL文書を見るとすれば、本発明者らは次のようなエントリを見ると考えられる。

直接呼び出しの例として、もしフローが上記の規則集合を呼び出す必要があれば、フローは「http://fauxuri.reuters.com/crm/client/categorize.asmx」を呼び出す命令を含む必要があると考えられる。後で規則集合の他のより複雑なバージョンが「http://fauxuri.reuters.com/crm/client/new-categorize.asmx」で利用可能になった場合、それを利用するためフロー自身が変更されなければならない。しかし、BPIフレームワークでは、規則集合を直接呼び出さず、その代わりに規則集合「主要クライアント規則」の呼び出しをBPIエンジンに要求することによって、それが避けられる。新しい規則集合を利用するためには、フローへの変更は必要でなく、BPDL文書の変更が必要なだけである。

第2の概念は、フロー、規則、および状態機械の間の相互データ・アクセス可能性である。全ては、実行している間、ビジネス・データの同じコピーを参照、評価、および修正できなければならない。この重要性は明白であると考えられる。即ち、もしビジネスプロセスの過程で、例えばフロー・エンジンが特定のデータ部分を修正するならば、例えば規則エンジンへの後の呼び出しは、規則を正しく評価するため、その変更に気づく必要がある。データの管理を助けるため、BPIは「エンティティ」という構成体を使用し、ビジネスプロセスからデータを分離する。原始的フローが行うように特定のロケーションからデータを要求するのではなく、BPI準備完了フローはBPDL記述エンティティからデータを要求する。BPIフレームワークは、データのライフサイクルを管理する状態機械の能力をテコ入れする。こうして、エンティティは、その具体化、状態進行、および破壊を提供するため状態機械へ関連づけられる。

相互抽象呼び出しおよび相互データ・アクセスが、フロー、規則、および状態のBPDL記述集合の間に、使用可能であるが柔軟な接続を提供することによって、BPDLは、ビジネス要件の論理集合を具体化する明記目的を十分に充足することができる。更に、BPDLは階層であることができ、指名フローが指名規則を呼び出す同じ方式で、BPDL内で指名により相互を参照することができる。したがって、個々のBPIは一緒に積層および配列され、より高次のBPIを形成し、より大きなビジネスプロセスを自動化する。

指名された参照は、プロセスおよびエンティティの実行時解決を可能にするだけでなく、設計時依存分析を可能にする。コンポーネントがBPDへ追加されるにつれて、BPI設計者は、そのコンポーネントが、どのような他の指名フロー、規則、状態機械、およびエンティティを参照するかを示し、未解決の参照が残らなくなるまで、他のコンポーネントをBPIに関連づけることを命ずることができる。指名コンポーネントへの全ての内部参照がBPDL文書内のBPI指名に対して検証されると、設計者は実行時の首尾一貫性を保証する。

BPIフレームワークの真の美点は、これらの特徴を使用して、ビジネス要件が意図された方法でビジネス要件の本質を捕捉し、単一実装技術の制約の中へビジネス要件を埋没させないことである。フローとして最良に表現されたプロセスは、おそらく規則として最良に具体化された他のプロセスと同じように、各々が一緒に働く能力を犠牲にするがない。それによって、それらの要件を充足するために使用されるコンポーネントの選択を、後で最小のコストで変更することが可能になる。ビジネス要件と技術実装との間のインピーダンスを増加し、それらの要件の後続展開コストを減少することによって、BPIフレームワークは、ビジネス・ソリューションを構築する場合の新しい成熟度を可能にする。

6.3.1 フロー仕様
ビジネスプロセスは、或るビジネス目的を達成するため共同して活動を実行する幾つかのアクタ、即ち人間またはコンピュータ・サービスを含む。活動間の制御論理およびデータ・フローは、一般的に、コントローラによって調整される。ビジネスプロセスの制御およびデータ・フロー論理は、例1（図2）および例2（図3）のようにグラフで示すことができる。

ビジネスプロセスの制御フローおよびデータ・フローは、ワークフロー仕様言語で定義され得る。もし本発明者らが、WSDLによって記述されることのできるウェブ・サービスとして各々のタスクをモデル化すれば、ウェブ・サービス編成言語、例えばBPEL4WSが、ビジネスプロセスのワークフローを定義するために使用される。

本発明者らは、BPEL4WSからの次の構成体が、ワークフローを構築するために使用されると仮定する。注意すべきは、BPDフロー仕様のベースとしてBPEL4WSが使用されるが、他のワークフローまたはウェブ・サービスをベースとする仕様も、類似の意味論の構成体をベースとするのであれば使用できることである。

呼び出し
操作は、値をパラメータへ割り当てることによって、ウェブ・サービスまたは他のワークフローを呼び出す。

タスクの呼び出しは、BPEL4WSにおけるようなウェブ・サービスの呼び出しとは異なる。WSDL内のウェブ・サービス・エンドポイントは、メッセージ渡しに基づいており、定義された意味論を有さない。タスクは意味論およびパラメータ集合を有する。

割り当て
値をロケーションへ割り当てる。
<assign>
<from>...</from>
<to>...</to>
</assign>
障害のシグナリング
<throw>名前</throw>

終了
実行を終了する。
<terminate/>

待機
或る時間量だけ待機する。
<wait time=""/>

何もしない
空の操作は何もしない。
<empty/>

構造化された活動
単純な活動は、複雑な活動を作るため組み立てられてよい。複雑な活動を構築するため、次のコンストラクタ（constructor）を使用することができる。ワークフロー状態が幾つかの正しさの規準を満足させることを保証するため、各々の活動または活動ブロックの前または後にアサーションを追加してよい。

シーケンシャル・コンストラクタ
シーケンシャル・コンストラクタは、幾つかの活動ブロックを順次に実行する。
<sequential>
<!-activity block 1-->
<!-activity block 2-->
... ...
</sequential>

同時コンストラクタ
同時コンストラクタは、幾つかの活動ブロックを同時に実行する。全ての同時の活動が終了した場合、コンストラクタは終了する。同時コンストラクタを指定するため、フロー要素が使用される。リンクは、活動ブロック間の依存を定義する。
<flow>
activity blocks
<links>?
<link name="ncname">+
</links>
</flow>

分岐コンストラクタ
分岐コンストラクタは幾つかの活動ブロックの1つを実行する。そのブロックが終了した場合、コンストラクタは終了する。条件は、各々のブロックについてアサーションとして指定される。条件が真へ評価された場合のみ、ブロックを開始することができる。もし複数の条件が真へ評価されるならば、複数のブロックを選択して開始することができる。この場合、ブロックは、真の条件を有するブロックの中から非決定論的に選択される。

whileコンストラクタ
whileコンストラクタは、保護条件が真である間、ループ内の活動ブロックを実行する。それは、条件が偽へ評価されるまで、活動ブロックの実行を反復する。
<while>
<condition>
<formula>...</formula>
</condition>
<activity>...</activity>
</while>

レース・コンストラクタ
レース・コンストラクタは幾つのタスクを同時に開始するが、最初に終了したタスクのみが効果を有する。他の活動ブロックは打ち切られる。
<race>
activity blocks
</race>

例外処理コンストラクタ
例外条件はグローバル条件として指定され、サブフローとしてのハンドラが条件を処理する。条件が真になった場合、同時に実行していたサブフローは停止され、ハンドラが実行される。次にハンドラは、新しい例外を外側ブロックへ投げることができる。未処理の例外は外側ブロックへ自動的に投げられる。これは、上記の例で示されるように、サブフロー内の任意のタスクから生成される障害または例外事象を処理する構造化方法を提供する。ワークフロー仕様で例外状況を指定するため、本発明者らは次の表記法を使用する。
<catch>
<condition>
...
</condition>
<activity>
...
</activity>
</catch>

事象
事象は、タイマが時間切れになったか、外部メッセージがワークフロー・コントローラによって受け取られたために生成される。
<event>
<name>
...
</name>
<type>
...
</type>
</event>

ピック
どの事象が最初に起こったかに依存して、実行する1つのパスを選択する。
<pick>
<OnEvent>
<name>...</name>
<activity>
...
</activity>
</OnEvent>
</pick>

6.3.2 動作の意味論
次のセクションは、ビジネスプロセス・フレームワーク内の動作の意味論を説明する。

6.3.2.1 SemanticLの紹介
ワークフローの意味論を形式的に指定するため、数学モデルが展開される。モデルに基づいた宣言型言語であるSemanticLが、BPIフローの意味論を形式的に指定するために設計される。

ビジネスプロセスのBPD仕様において、フローはXML型のワークフロー言語を使用して宣言型で指定される。多くのワークフロー仕様言語が既に提案された。例えば、BPEL4WS、WSCLなどである。BPD内のフロー記述言語としてBPEL4WSが選択される。それらの言語は、ビジネスプロセスの制御フロー論理を記述するのに十分である。しかし、意味論または正確な「意味」を記述する方法を提供するものはなかった。したがって、正しさはシステムによって自動的に保証されず、手作業のテストに依存する。

SemanticLは、他のワークフロー仕様言語であることを意味するものではなく、ワークフロー仕様を注釈して、ワークフローおよびそれらのコンポーネントの意味論を形式的に定義するために使用される言語であることを意味する。SemanticLは厳格な数学モデルに基づいており、設計時および実行時に意味論的正しさを自動的に検証することができる。更に、新しいワークフローの、意味論的によく定義されたコンポーネントおよびビジネス目的のライブラリに基づいて、新しいワークフローを自動的に構築することができる。

6.3.2.2 ワークフロー意味論を記述する形式的モデル
形式的ワークフロー・モデルが説明される。ワークフローの意味論は、モデルに基づいて正確に定義されることができる。このモデルにおいて、ワークフロー仕様は、論理表現および推論を容易にするため高レベルで抽象化される。抽象化されたワークフロー仕様は、A-BPDと呼ばれる。A-BPDは4タプル、即ち<ワークフロー・データベース、タスク・ライブラリ、ワークフロー>として定義される。各々の用語の定義およびBPDフローへの関係は、後で説明される。

定義
領域、変数、および定数：
領域は同じタイプのオブジェクトの有限集合である。例えば、D={1,2,...,100}は1から100までの整数の領域を表す。Aはその値を特定の領域から取る。例えば、x∈Dは領域Dの変数xを定義する。定数は、領域上の面白い値である。例えば、10はDの中の定数であり、真、偽はブールという領域の定数である。

述語：
述語はオブジェクトの或る特性またはオブジェクトの関係を主張する。述語はP(x₁,x₂,...,x_k)の形式である。パラメータの数および各々のパラメータのタイプは、各々の述語について事前に定義されている。どのパラメータを取らない述語は、真または偽へ評価されるシンボルとして表現され得る。もしPが述語であれば、
P∈{T,F}
である。

述語は、ワークフローの現在の状態を特性化するために使用される。例えば、コンタクト済みは、交渉ワークフローの中の述語である。それは、もし取引業者AがBと成功裏にコンタクトしたのであれば真へ評価され、そうでなければ偽へ評価される。
リテラル：リテラルは述語であるか、述語の否定である。
リテラル:={述語｜¬述語}

ワークフロー・データベース：
ワークフローを作り上げている述語の集合は、ワークフロー・データベースを形成する。ワークフロー・データベースはBPDL内の抽象的データ・モデルへ直接関係づけられる。抽象的データ・モデル内の葉要素は、ワークフロー・データベース内の述語に対応する。述語は全てのタスクからグローバルに見ることができる。例えば、次に掲げるものは交渉の例におけるワークフロー・データベースである。
{コンタクト済み, 受け入れ済み, 新指値_A, 新指値_B, 中断_A, 中断_B, 合意済み_A, 合意済み_B, 確認済み_A, 確認済み_B, 決済済み_A, 決済済み_B, 取引なし, 同一支店}

式：
式は、所与のワークフロー・データベースに基づく整合一次論理式である。具体的には、
1.述語は式である。
2.もしP,Qが式であれば、P∨Q、P∧Q は式である。
3.もしPが式であれば、¬Pは式である。
4.もしPが式であり、xが変数であれば、∀(x)Pおよび∃(x)Pは式である。

タスク：
タスクはワークフローのビルディング・ブロックである。単純タスクは、ACID特性を満足させる原子的動作を実行するタスクである。複雑タスクは、サブワークフローのような他のタスクを含み、したがって原子的でない。2つの複雑タスクが同時に実行している場合、それらの活動は任意の仕方で交錯する。本発明者らは最初に干渉がないことを仮定し、後でこの問題へ戻ることにする。

単純タスクTは{P}T{Q}によって記述される。PはTの事前条件である。Tは、それが開始した場合、Pが真である場合、かつ、その場合に限り、正しく実行する。簡単にするため、リテラルの合接形式でのみPを考える。
P:=∧(リテラル)

Tを幾つかの異なった状態で開始できる場合、
{P₁∨P₂}T{Q}

Tをタスクの集合と見ることができる。
{P₁}T₁{Q},{P₂}T₂{Q}

QはTの事後条件である。タスクTは幾つかの可能な終了状態を有することができ、それが終了した場合、1つが非決定論的に選択される。Qは(S₁∧Q₁)∨(S₂∧Q₂),...,∨(S_n∧Q_n) の形式である。ここでQ_iはリテラルの合接であり、S₁,S₂,...,S_nはワークフロー・コントローラによって観察可能なステータス変数である。Tが終了する場合、S₁,S₂,...,S_nの1つのみが真であり、タスクによって非決定論的に選択される。簡単にするため、本発明者らは(S₁∧Q₁)∨(S₂∧Q₂),...,∨(S_n∧Q_n)をQ₁,Q₂,...,Q_nで表す。

例えば、交渉_Aというタスクは、次のように記述される。
{新指値_B∨中断_A}交渉_A{(新指値_A∧¬新指値_B),合意済み_A,取引なし}

タスクの定義はフレーム意味論に従う。フレーム意味論とは、タスクの実行が、事後条件の中で言及された述語だけに影響を及ぼすことを意味する。形式的には、フレーム意味論は結果関数によって定義され得る。

P'はTが開始する場合のワークフロー状態であり、P'⇒Pは真であり、Tが終了する場合、結果(P',Q_i) は真である。ここで、
結果(P',Q_i)=(P'/Q_i)∧Q_iであり、(P'/Q_i)は、Q_iで指名された全ての述語が削除されたPである。

結果(P',Q₁),結果(P',Q₂),...,結果(P',Q_n)は、Tが終了する場合の全ての可能なワークフロー状態を定義する。

または、Tが終了する状態から逆方向に推論することができる。Tが終了する場合、Q'が真であると仮定する。ここで、Q⇒Q'、
剰余(Q',Qi)=∧(Q'-Qi)、ここでQ'-QiはQ'およびQiにおけるリテラル集合の集合差である。

P∧剰余(Q',Q₁)∧剰余(Q',Q₁),...,∧剰余(Q',Q₁)は、Tが開始する場合満足されなければならない。

タスクのBPDL仕様は、抽象的データ・モデルとワークフロー・データベースの間の関係に従ってA-BPD仕様へ容易に変換され得る。

ワークフロー仕様：
ワークフローは次の形式で指定される。
{P₁,P₂,P₃,...P_n}WF{Q₁,Q₂,Q₃,...Q_n}
ここで、P₁,P₂,...P_nはリテラルの合接であって相互に排他的である。Q₁,Q₂,...,Q_nは次の形式である。
[(S₁₁∧Q₁₁)∨(S₁₂∧Q₁₂)∨...)],[(S₂₁∧Q₂₁)∨(S₂₂∧Q₂₂)∨...],...[(S_n1∧Q_n1)∨(S_n2∧Q_n2)∨...]
これは、WFが開始する場合、WFの事前条件の1つが真でなければならず、もしP₁が真であれば、Q₁が事後条件であることを意味する。以下同様である。

タスクは、ただ1つの事前条件および事後条件のペアを有する点で、ワークフロー仕様の特別のケースである。

ワークフローは、ワークフロー・コンストラクタを使用してタスクから構築される。もし完全な構築が与えられると、ワークフローのフレーム意味論を引き出すことができ、ワークフローをタスクとして処理することができる。

ワークフロー・コンストラクタの意味論
ワークフロー仕様の中で、次のコンストラクタが許される。

タスク
もしワークフローが状態PにあってタスクT₁が実行されるならば、次の推論規則が存在する。

逆方向から推論する場合、

シーケンシャル
シーケンシャル・コンストラクタは、2つのタスクが順次に実行することを指定する。SEQ[T₁,T₂]は、T₁が実行され、次にT₂が実行されることを意味する。シーケンシャル・コンストラクタについて、次の推論規則が存在する。

AND
コンストラクタのAND[T₁,T₂]は、2つのタスクが同時に実行することを指定する。もし干渉が存在しなければ、ANDコンストラクタについて次の推論規則が存在する。

OR
コンストラクタのOR[T₁,T₂,C]は、もしCが真であれば、T₁が実行され、そうでなければ、T₂が実行されることを指定する。次の推論規則が存在する。

レース
レース・コンストラクタのレース[T₁,T₂]は、2つのタスクが同時に実行することを指定する。しかし、終了した最初のタスクがコミットし、他のタスクは打ち切られる。

ループ
ループ・コンストラクタのループ[T₁,C]は、Cが真になるまで、T₁が反復して実行されることを指定する。ここで、Cは整合式である。ここで問題にするループは、ループ本体T₁が少なくとも1回実行される意味で、反復ループである。反復ループおよびORコンストラクタを使用して、whileループを容易に構築することができる。

ループ条件CおよびタスクT₁の双方が論理式として指定されることに起因して、ループ・コンストラクタは、一般的なプログラミング言語のループよりも強力でない。その理由は、ループ本体が何回実行されようとも、ループ・コンストラクタの開始点に達した場合、ワークフロー状態は常に同じだからである。ループ不変式は単純にP₁∧Cである。ループ・コンストラクタの意味論は、T₁が幾つかの非決定論的出力を有するものと仮定して、T₁が所望の出力を与えるまでT₁を再試行することである。

整合ループの必要条件は、ループの事後条件が矛盾を有さないことである。
¬C∧Q₁≠偽

これは、たまたまループ終了の必要条件である。もしT₁の出力が公平性の特性を満足させると仮定すれば、条件は更に十分条件である。

事象およびピック
事象は特殊なタスクである。事象は外部からワークフロー・コントローラへ送られるメッセージである。ワークフロー・コントローラは、いつ事象が起こるかについて制御を有さない。しかし、ワークフロー・コントローラは、それに登録された事象を認識し、それに応答する。例えば、新しいワークフロー・インスタンスを開始するか、事象の生起を待機している待機ワークフローを継続する。事象は事前条件を真として有するタスクとして指定され得る。
{真}E{Q}

ワークフロー仕様の中で事象を使用することはできない。その代わりに、ワークフローが或る事象の生起を待機していることを指定するため、ピックと呼ばれるコンストラクタが使用される。ピックは、一つまたは複数の受け取り節を有することができる。どの事象が最初に起こるかに依存して、1つのブロックがピックアップされて実行される。

待機事象の1つが最終的に起こると仮定すれば、ピック・コンストラクタの意味論は、レースの意味論に類似している。

6.3.2.3 動作の意味論
データ・モデル
データ・モデルは、ビジネス・アプリケーションまたは関連ビジネス・アプリケーションの集合の基礎をなすデータ・スキーマを定義する。更に、タスクおよびワークフローの意味論が定義される抽象的データ・モデルを記述する。

データ・モデルは、XMLスキーマに基づく半構造化データ・タイプとして定義される。XMLスキーマに基づく多くの企業標準、例えばFpMLおよびNewsMLが存在する。それらは多くのアプリケーションの基礎を形成する。

BPDLは、具体的データ・モデルおよび抽象的データ・モデル両方の表記法を提供する。具体的データ・モデルは、ワークフロー・コントローラが実行時に使用する実際のデータ・モデルであり、抽象的データ・モデルは、意味論的な仕様、検証、およびシミュレーション目的に必要な或る高レベル情報のみを指定する。

具体的データ・モデル
具体的データ・モデルは、ワークフローの実行に必要なデータ・スキーマを定義する。

例えば、交渉プロセスのデータ・モデルは、7.2で示されるようにXMLスキーマ形式で定義され得る。これはFPML標準の拡張バージョンと考えることができる。交渉データ・モデルのインスタンスは7.3に例示される。

抽象的データ・モデル
抽象的データ・モデルは、具体的データ・モデルの上にある抽象的層である。それは、タスクおよびワークフローの事前および事後条件を指定するために使用される特性を定義する。例えば、確認済みと呼ばれる述語は、取引業者のために定義される。もし取引業者の取引が既に確認されていれば、確認済みは真であり、そうでなければ偽である。
<property name="confirmed"
expression="(negotiation/CurrentBid/bitter/confirmed=yes)or
(negotiation/CurrentBid/listener/confirmed=yes)"/>

特性は、ブールまたは整数値へ評価される具体的データ・モデル上のXPATH表現として定義される。例えば、確認済みは、少なくとも1人の取引業者が確認済み状態へ達したものとして定義される。例は7.4で示される。

タスクおよびタスク・ライブラリ
タスクはワークフロー・プロセスのビルディング・ブロックである。タスクは、一般的に、WSDLとのウェブ・サービス・インタフェースとして指定される。タスクの意味論は、事前および事後条件の形式で指定される。

タスクは事前条件の集合を有する。事前条件は、タスクが実行を開始する場合満足されなければならない。事前および事後条件は、抽象的データ・モデル上のブール表現である。タスクの実行本体は、ワークフロー・エンジンの外側にあるアプリケーションであるか（単純タスク）、サブワークフローである（複雑タスク）。

要求
要求は、タスクの事前条件を指定する。それは1つまたは幾つかの要求要素を有することができる。各々の要求要素は、式要素の集合を有する。式要素は、抽象的データ・モデル上のブールXPath表現である。要求要素は、全ての含まれた式要素が真である場合、かつ、その場合に限り満足される。少なくとも1つの要求要素が、タスクの実行を開始する前に満足されなければならない。
<requires>
<require>
<formula>negotiation/SingleConfirm
</formula>
</require>
</requires>

保証
保証要素は、タスクの事後条件を指定する。要求要素と同じく、各々の保証も式要素の集合を有する。タスクが成功裏に終了する場合、保証要素の1つだけが出力として選択され、ワークフロー・データはそれに従って更新されたことが保証され、XPath式は真へ評価される。更に、保証の中で明白に指定されたフィールドのみがタスクによって影響を受け、抽象的データ・モデル内の他のフィールドは変更されない。
<guarantees>
<guarantee>
<formula>negotiation/DoubleConfirm=true
</formula>
</guarantee>
<guarantees>

例外
例外は、タスクの例外的事後条件をXPath表現として指定する。それは保証仕様と類似している。唯一の差異は、タスクが失敗するか異常として出る場合の可能な出力を定義することである。
<exceptions>
<exception>
<formula>negotiation/timeout</formula>
</exception>
<exceptions>

6.3.2.4 ワークフローの意味論
要求および保証
タスク仕様と類似した仕方で、ワークフロー仕様は要求、保証、および例外を有することができる。これらはタスク仕様の場合と同じである。

コンストラクタ
コンストラクタは、一般的に、BPEL4WS内の構文論に従い、本発明者らはコンストラクタをアサーションで注釈する方法を提供する。
<assert>
<formula>抽象的データ・モデル上のXPath表現</formula>
</assert>
6.3.3 ワークフロー内の異なった点におけるアサーション

6.4 BPI実行フレームワーク
以下のセクションはBPI実行フレームワークを説明する。

6.4.1 フロー、規則、および状態エンジン
BPI実行フレームワークは3つのコア・コンポーネント、即ち、フロー・エンジン、規則エンジン、および状態エンジンを有する。3つのエンジンは相互にインタラクションを行い、ビジネスプロセスの実行中に既存の領域サービスを呼び出す。

領域サービスは、領域特定機能をウェブ・サービスとして提供する。例えば、顧客関係管理サービスは、顧客関係の管理に関連する機能、例えば顧客情報の検索、顧客ディレクトリのサーチなどを提供する。領域サービスは、新しいアプリケーションへ統合できるビルディング・ブロックを提供する。

フロー・エンジンは、所与のワークフロー仕様に従ってBPEL4WSプログラムの形式でウェブ・サービスを編成する。ワークフローがフロー・エンジンで展開される場合、そのフローの一意のエントリ・ポイントがウェブ・サービスとして作り出される。メッセージが対応するエントリ・ポイントで受け取られる場合、フロー実行の新しいインスタンスが作り出されて開始される。実行中、フローは領域特定機能を実行するため領域サービスを呼び出し、規則を評価するため規則エンジンを呼び出し、状態のクエリーまたは遷移を要求するため状態エンジンを呼び出してよい。フローはウェブ・サービスとして展開されるから、それらのフローは他のフローによって呼び出され得る。

状態エンジンは、状態機械モデルに基づいてビジネス・オブジェクト・ライフサイクルを管理する。状態エンジンは、実行時に、ビジネス・オブジェクト・インスタンスの状態データおよびユーザ定義データを制御する。それらのデータは、状態エンジンの外部では更新され得ない。状態機械モデルは、正規の状態、状態間の遷移、およびビジネス・オブジェクトの遷移に関連づけられた操作を定義する。実行時において、状態機械の新しいインスタンスは、作成要求が受け取られた場合モデルに従って作り出される。状態機械インスタンス上の遷移の要求が受け取られた場合、状態エンジンは、最初に、要求された遷移が動作可能であるかを検証する。もし動作可能であれば、状態データは、それに従って更新され、関連の操作、例えばユーザ・データの更新またはウェブ・サービスの呼び出しが実行される。状態エンジンは、全ての状態機械モデルについて単一のウェブ・サービス・インタフェースを有する。

規則エンジンは複雑なビジネス規則を評価し、可能性として、どのような規則が真へ評価されるかに依存して幾つかの動作を実行することができる。ビジネス規則は宣言型言語、例えばRuleMLで指定される。実行時において、規則エンジンは要求時にデータ集合上の規則集合を評価する。状態エンジンと同じく、規則エンジンは全ての規則評価要求について単一のウェブ・サービス・インタフェースをエキスポートする。

6.4.2 BPIフロー、規則、および状態の間の調整
ビジネスプロセスの実行は、フロー、規則、および状態が相互に調整およびインタラクションを行うことを要求する。しかし、フロー、規則、および状態のエンジンは、独立に実行することができる。それらはウェブ・サービス・インタフェースを介して疎結合される。図1は、それらのインタフェース間の論理関係を示す。グラフ内の矢印付き実線は、異なったインタフェース間の呼び出し関係を示し、破線はデータ・フロー関係を示す。

各々のフローは、それ自身の一意のウェブ・サービス・インタフェースを有する。例えば、F1は、インタフェースIフロー1を有し、F2はインタフェースIフロー2を有し、かつF3はインタフェースIフロー3を有する。規則エンジンは単一のインタフェースを有する。R1、R2、およびR3を評価する要求は、全て同じインタフェースを通過する。状態エンジンも単一のインタフェースを有する。全ての状態インスタンス上のクエリーまたは更新は、そのインタフェースを介して要求される。

フローの実行中に、規則の評価を行うため規則エンジンを呼び出し、状態の遷移およびデータの更新を行うため状態エンジンを呼び出すことができる。規則エンジンは、幾つかの規則評価の結果によってトリガされるままに、フローを開始するか、状態エンジンを呼び出すことができる。状態エンジンは、規則エンジンを呼び出すか、もし遷移が成功裏に実行されたのであればフローを開始することができる。三者の相互呼び出し可能性は、図1の矢印L1、L2、L3によって示される。

ビジネス・オブジェクト・データは状態機械によって保護され、状態機械を介してのみ書き込みまたは更新が可能である。この保証は、データが正当な状態に維持され、正当な遷移によってのみ変更され得ることを保証する。フローおよび規則は、保護されていないデータ上で動作することができ、保護されたデータ上では読み出し専用動作を実行することができる。任意に、パフォーマンスを改善するため、保護されたデータを読み出し専用データ記憶装置へ複製することができる。

6.4.3 BPIの管理
BPIがユビキタス計算環境で展開されるにつれて、BPIの管理が不可欠となる。BPI管理はレジストリ、ディスカバリ、モニタ、サービス水準合意（SLA）管理、および違反が生じた場合のSLA自立履行（管理BPIおよびエンドポイント解決）から構成される。以下のセクションは、これら局面の各々を詳細に説明する。図9は、BPI管理の図式表現を提供する。ここで注意すべき点は、BPIの管理がビジネスプロセスであり、管理BPIと呼ばれるBPIを使用することによって自動化されることである。

6.4.3.1 BPIレジストリ：
BPIレジストリは3つの部分から構成される。第1はBPIのエンドポイント（論理的または物理的）であり、第2はSLA合意であり、第3は分類法である。この情報を記憶するため、中央または連合レジストリが必要である。BPIの意味論は次のとおりである。即ち、BPIの各々およびその成分（フロー、規則、および状態）は抽象的インタフェースへマップされる。抽象的インタフェースの各々は、実行時エンドポイントの一つまたは複数のインスタンスを有する。実行時インスタンスの各々は、様々なSLA、構成、および分類法が定義されるインスタンス・データを有する。任意の永続的記憶装置をBPIレジストリとして使用することができる。以下のパラグラフは、UDDIをBPIレジストリとしてどのように使用できるかを説明する。

6.4.3.2 UDDIを使用するBPIレジストリ：
・BPIの各々およびその成分は、UDDI tモデルへマップされる。
・BPIおよびその成分の記述は、UDDI概説文書へマップされる。
・SLA合意、構成、および分類法は、UDDIインスタンス・データへマップされる。
・BPI分類法は、UDDI分類法へマップされる。

6.4.3.3 BPIディスカバリ
BPIが、レジストリ（前述した）に記憶された構成に基づいて展開された後、展開とレジストリが同期しないリスクが常に存在する。なぜなら、それらは切り離される性質を有するからである。この問題はは、BPIエンドポイントへのトラフィックをモニタし、レジストリを同期するか、環境で実行しているルージュBPIを識別する能力をBPIアドミニストレータへフィードバックすることによって解決される。

6.4.3.4 BPIモニタ
BPIエンドポイントはSOAPエンドポイントであるから、メッセージはSLAの様々な特性についてリアルタイムまたは近リアルタイムでモニタされる（パフォーマンスを理由として）。違反が起こった場合、モニタリング・エージェントは、適切な動作を取るように「管理BPI」に通知する。

6.4.3.5 管理BPI
管理BPIは、SLA違反（前述した）を受け取ってSLA履行の決定を行う特殊BPIである。最も単純な例を挙げると、特定のフロー・サービスが能力の80％に達した場合、BPIモニタは管理BPIに通知し、管理BPIはBPIレジストリの中の構成を調整して、最初のフロー・サービスがSLAを維持できるまで、フロー・サービスへの後続の呼び出しが、エンドポイント解決サービスを使用して異なったエンドポイントへ回送されるようにする。管理BPIは、更に、「SLA許容および維持管理」を提供して、動揺に基づくフィードバックを回避する。

6.4.3.6 エンドポイント解決サービス
BPI実行時に、全てのBPI成分は、エンドポイントを必要とする場合、インタフェース、SLA、および分類に基づいてBPIレジストリに質問し、呼び出される必要があるエンドポイントを取得する。これは、エンドポイントのダイナミック・ディスカバリを提供し、SLAを履行するため管理BPIによって実行される構成調整に基づいてBPI呼び出しを再回送する能力を提供する。

6.5 ビジネスプロセス・ワークフローの正しさ
ワークフローが開始した場合ワークフローの事前条件が真であると仮定して、もしワークフロー要件の事後条件がワークフロー仕様によって真であると主張されるならば、ワークフローは所与の要件に従って正しい。

タスクの意味論およびワークフロー・コンストラクタの推論規則に基づいて、コンパイル時にワークフローの正しさを検証することができる。

6.5.1 ワークフローを自動的に注釈する
もしワークフローの事前条件が与えられると、各々のタスクの事前および事後条件が与えられたと仮定して、全ての実行ポイントで、そのポイントで何が真であるべきかについて、ワークフローを自動的に注釈することができる。

自動注釈のアルゴリズムは2つのパラメータを取る。即ち、ワークフローWおよびワークフローの事前条件P、およびWの注釈バージョンである出力W'である。
アルゴリズム：自動注釈(W,P):W'
1.もしWがタスク{P₁}T₁{Q₁}であれば、タスク規則を適用する。

2.もしWがコンストラクタW=CON(T₁,T₂,...)で構成されていれば、対応するコンストラクタ規則を適用し、繰り返してT₁、T₂、...を注釈する。
6.5.2 ワークフローの正しさを自動的に検証する

最初に、ワークフローを注釈する。次に、もしアサーションが次ぎのタスクの事前条件を暗黙に意味していなければ、そのポイントでエラーが存在する。次のタスクの事前条件が満足されないので、ワークフローは誤っており、したがってそのポイントで開始され得ない。

もし最後のアサーションがワークフローの事後条件を暗黙に意味しなければ、ワークフローは事前に定義された事後条件を満足させないから、ワークフローは誤っている。

6.6 ビジネスプロセスのモデル・チェック
モデル・チェックは、システム実装が、その要件仕様を満足させるかどうかを形式的に検証する。企業および大学は、様々なソフトウェアおよびハードウェア・システムのモデル・チェック方法論および自動検証ツールを開発してきた。しかし、ビジネスプロセスおよびアプリケーションに適用されるものは非常に少ない。なぜなら、それらが複雑で形式的仕様を欠如しているためである。

BPIはビジネスプロセスを抽象化し、それをフロー、規則、および状態として形式的に記述する方法を提供する。フローおよび状態仕様の正しさは、モデル・チェック手法を使用して検証され得る。これに基づいて、BPIフレームワークは、ビジネスプロセスの正しさをモデル・チェックするアプローチを提案する。BPIモデル・チェック・ツールは、フローおよび状態仕様をシステム実装として取り、それらを、オリジナルのビジネス要件から自動的に引き出されたシステム要件仕様の集合に対してチェックする。それは、設計時および実行時の双方で、正しさを補強するために使用され得る。

モデル・チェックは、次の局面で意味論に基づく検証とは異なる。第1に、モデル・チェックは観察的トレース意味論、即ち可能なプロセス実行における観察可能状態シーケンスに基づく。しかし、意味論に基づく検証は、活動およびフローの形式的意味論に基づく。第2に、前者は、時間的特性、例えば、AはBの前に起こらなければならない、Aは最終的に起こるだろう、デッドロックは存在しない、などを検証するために使用され得る。しかし、後者は、そのような特性を検証するためには使用され得ない。第3に、前者はシステム実行の全体の状態空間を探求する必要があるが、後者はシステム仕様上の形式演繹法に基づく。

BPIモデル・チェック・ツールは、次の目的を達成する助けとなる。即ち、設計時の正しさのチェック、実行時の正しさの補強、およびセキュリティ確保である。セキュリティは分散環境で特に重要である。モデル・チェックの観点からは、セキュリティ問題は、言語ベース手法によって処理され得る信頼性問題のサブセットである。本発明者らのモデル・チェック・ツールは、情報フローのセキュリティ方針を保護し、したがって機密性を保証する。

6.6.1 モデル・チェックのアプローチ
本発明者らのモデル・チェック・アプローチは、抽象的状態機械モデルに基づいている。仕様は、最初に抽象的状態機械モデルへ変換され、次にモデル・チェックされる。方法論は図10に要約される。

6.6.2 設計時のモデル・チェック
第1のステップは、システム実装および要件仕様を形式的に定義することである。これらの双方はビジネス要件から引き出される。ビジネスプロセスの要件から、BPIによってBPEL4WSでフローを指定し、StateMLに関して状態モデルを指定することができる。StateMLは階層的状態機械モデルに基礎を有する。それらの手順は、図10の破線矢印で示される。更に、ビジネス要件は、時相論理の形式で時間的述語として抽象化および形式化される。時間的述語の集合は、システムが観察しなければならない時間的制約を指定する。この手順は図10の矢印gで示される。

第2のステップは、本発明者らの階層的状態機械モデルの中でフローおよび状態を定義することである。なぜなら、モデル・チェック手法は、階層的状態機械モデルに基づいているからである。BPEL4WS仕様は、StateMLへ変換される。StateMLはBPI状態およびモデル・チェック両方の状態仕様言語として役立つ。変換を自動的に行うアルゴリズムが展開される。この手順は図10の矢印aによって示される。

第3のステップは、階層的状態機械および時間的述語の双方を抽象的状態機械へマップすることによってシステムおよび要件仕様を抽象化することである。このステップが必要な理由は、オリジナルの仕様が、あまりに多くの状態、更には無限の状態空間を有するかもしれないからである。そのような状態機械でのモデル・チェックは、状態の急増問題に出会うと考えられる。抽象化はオリジナル仕様の状態空間を単純化する。この手順は、図10の矢印cおよびdで示される。

第4のステップは、抽象的状態機械をモデル・チェックすることである。結果は、状態機械モデルを更に洗練するために使用される。ステップ3および4は、抽象的状態機械が成功裏にモデル・チェックされるまで反復して実行される。この手順は、図10の矢印b、eおよびfで示される。

抽象化とモデル・チェックには2つの接近方法が存在する。即ち、反例誘導法と最弱事前条件誘導法である。

簡単にいえば、反例誘導抽象化は次の手順に従う。
1.最初に、要件に述語を含むようにE0をセットする。
2.次のステップを反復して実行する。
a. 具体的モデルをEiで抽象化する。
b. 抽象的モデルをモデル・チェックする。もし答えがイエスであれば、終了する。
c. もし答えがノーであれば、具体的モデルをシミュレートし、問題を起こした新しい述語Fiを発見する。
d. Ei+1:=Fi合併Eiとし、i:=i+1として、次の反復へ進む。

最弱事前条件誘導抽象化は、次のように要約される。
1.具体的モデルへ要件述語を適用する。
2.ステップ1の述語に基づいて各々の状態の最弱事前条件を逆方向に計算する。
3.全ての述語が計算された具体的モデルを抽象化する。
4.抽象的モデルをモデル・チェックし、もし答えがイエスであれば、終了する。
5.もし答えがノーであれば、抽象化を修正し、モデル・チェックを再実行する。

6.6.3 実行時のモニタリング
実行時のモニタリングは、実行しているプロセスの正しさを保証する。プロセスは設計時に検証されが、実行時モニタリングが依然として必要である。その理由は、a)幾つかの特性が、抽象化のために設計時に検証可能でないかもしれず、b)幾つかの活動が、望ましくない実行時特性であってインタフェースで指定されない特性を有するかもしれず、c)多くのパフォーマンスおよびセキュリティ方針が実行時に保証されなければならないからである。

実行時モニタは、時間的述語として形式的に定義された安全特性要件に基づいて自動的に組み立てられる。モニタは、実行時に、モニタされるシステムと並列に実行し、安全特性の任意の違反を検出する。一度、違反が検出されると、モニタは現在のプロセス実行を中断し、誤り処理手順を開始する。

セキュリティは、言語ベースの手法によって確保される。仕様の中の各々のデータ項目は、セキュリティ・レベルを示すセキュア・タイプのタグ、例えば高または低に関連づけられる。各々のプログラム・ブロックはセキュリティ・コンテキストに関連づけらる。モデル・チェッカはタイプ推論分析を実行して、情報フローがブロックおよびデータ項目のタグ値と整合するかを確かめる。例えば、低とタグされたデータ項目への全ての割り当ては、低値から引き出されるか、低コンテキストの中で起こる。

6.7 ビジネス・ワークフローの自動的合成
ワークフロー要件は、ワークフローの事前条件および期待事後条件を指定する。正しいワークフロー仕様は、もし存在すれば、所与のタスク・ライブラリの意味論に基づいて見出される望みがある。

問題は、もしタスク・ライブラリおよびワークフロー要件が与えられると、正しいワークフロー仕様が自動的に生成されることである。

問題を例示するため、図5で説明されたタスク・ライブラリが存在すると仮定する。タスクは、コーポレート動作ワークフローを構築するために使用されるコンポーネントである。

タスクを任意的に接続できないことは容易に分かる。なぜなら、1つのタスクの事後条件は、他のタスクの事前条件を満足させないかもしれないからである。ワークフロー構成体を使用し、どのようにしてタスクを正しく接続するかの基本的規則の集合が存在する。

シーケンス：
タスクまたはワークフローAの事後条件が、タスクまたはワークフローBの事前条件を暗黙に意味すると仮定すると、AおよびBはシーケンス構造として構成され得る。例は図6で示される。

分岐：
もしタスクAの出力がタスクBの事前条件を部分的にのみ暗黙に意味するならば、Aからの幾つかの出力ケースは、AおよびBのシーケンスを単純に形成することによっては処理されない。処理されないAからの出力は、懸垂エッジと呼ばれる。もし懸垂エッジの条件が他のタスクの事前条件を暗黙に意味するならば、異なったタスクによって異なったケースを処理するように分岐を形成する必要がある。もしAからの全ての可能なケースをカバーするようなタスクの集合を見出すことができれば、正しい分岐構成体を形成することができる。例は図7で示される。

ループ：
時には、パス上の幾つかのタスクへ懸垂エッジをフィードバックし、ループを形成することによって、懸垂エッジを固定することができる。これは、条件が満足されるまでループ内でサブワークフローを再試行することを意味する。例は図8で示される。

例外：
例外は特殊出力エッジである。したがってそれらは分岐と同じ方法で処理され得る。唯一の差異は、多くの場合、ワークフローが或るエラー状態にあり、エラー・ハンドラによって別個に処理されなければならないことを、例外が暗黙に意味することである。更に、同じ例外が異なったタスクによって生成されるかもしれず、それら例外のグループに対して単一のハンドラを使用することができる。ブロック内の例外を処理するため、分岐を作り出す代わりにキャッチ・ステートメントが作り出される。

サブフロー：
より大きなワークフローを形成するため、合成されたワークフローをコンポーネントとして使用することができる。

構築規則に基づいて、全ての可能なワークフローをタスク・ライブラリから構築することができる。しかし、数は天文学的になり、それらの全てがビジネス目的を満足させるわけではない。所与のビジネス目的を満足させる正しいワークフローを見つけるため、アルゴリズムが必要である。

ビジネス目的は、ワークフローの事前条件および事後条件に関して指定される。ワークフローが開始した場合事前条件が真であると仮定すれば、ワークフローが終了した場合事後条件が真になるように、ワークフローを生成する必要がある。

問題を扱いやすくするため、問題の特殊ケースのアルゴリズムが最初に構築され、特殊ケースに基づいて、より一般的なアルゴリズムが作り上げられる。

ケース1：
タスクは事前条件で肯定的述語のみを有し、事後条件で単一の出力を有する。

タスク・ライブラリは、次の仮定を満足させる。
1.タスク事前条件は、肯定的述語の合接である。
2.変数割り当てまたは変数上の条件は許されない。
3.タスク・ライブラリは、順位づけの仮定に従う（下記を参照）
4.最初、全ての述語の値は真か偽である。ワークフロー・ジェネレータによって実際の値を仮定することはできない。生成されたワークフローは、全ての可能なケースで正しく働かなければならない。（ワークフローの事前条件は与えられない。）

順位づけ：
述語の集合PSの上で部分的順序関係<を定義することができ、タスク・ライブラリTSは次の意味で部分的順序<を尊重する。
a. $＼mathcal{T}$内の任意のタスク$T$について、Tの事後条件の中に肯定的述語q_0が存在する。q_0は一次出力と呼ばれる。Tの事前条件の中の任意の述語pおよびTの事後条件の中の非一次述語qについて、次の関係が存在する。
b. p<q_0, q<q_0
c. $T$の事前および事後条件の中の述語は、$q_0$よりも高い順位を有さない。タスクは複数の一次出力を有することができる。
d. 全ての述語は、少なくとも1つのタスクの一次出力である。

パス：
パスはタスクのシーケンスである。最初のタスクの事前条件が満足されたと仮定すると、パスの中の全てのタスクを逐次の順序で正しく実行することができる。

定理：
順位づけ仮定を満足させるタスク・ライブラリが与えられたと仮定すれば、次のことが得られる。

各々の述語pについて、Path(p)のパスが存在する。Path(p)はpを真にし、pはPath(p)の最後のタスクの一次出力である。
a. もしPath(p)をサブワークフローとして見るならば、pはサブワークフローの一次出力である。
b. $p$よりも高い順位を有する述語は、パスの中に現れない。
c. 属性閉包の表記法を使用して、述語を実現するパスを計算することができる。

アルゴリズム：
ライブラリTLを与えられるならば、ライブラリCL(TL)の属性閉包を構築することによって各々の具体的述語についてワークフローを見つけよ。

閉包は、真にすることのできる全ての述語である。各々の述語$p$は、Path(p)に属するパス属性に関連づけられる。

ケース2：許可条件
ケースは、上記のセクションと同じ仮定に従うが、条件を処理する仮定を追加する。

追加の仮定：
タスクの事前条件は、肯定的述語の合接であるか、単一変数上の条件、例えば$x>0$であるか、双方の組み合わせである。
a. 事後条件の中の述語は、gen(x)の形式であってよい。もしタスクの事後条件がgen(x)を有するならば、gen(x)は一次出力でなければならず、そのタスクの唯一の一次出力でなければならない。
b. 変数xは、ワークフローが開始する場合割り当てられない。即ち、最初はgen(x)=偽である。
c. gen(x)およびx(x>0)上の条件は同じ順位を有する。

パス：
パスはタスクのシーケンスである。可能性として、タスクの幾つかの前に変数上の条件が存在する。もし最初のタスクの事前条件が満足されると、タスクが開始した場合タスクに先行する条件が真であると仮定して、パスの中のタスクは逐次の順序で正しく実行される。

Path(p)は、最後のタスクの一次出力（したがって、パスの一次出力）としてのpを有するパスである。もしパス上に条件が存在しないならば、パスは完全パスである。そうでなければ、パスは不完全パスである。パスに沿った全ての条件の合接は、パスの条件である。

仮定を満足させるタスク・ライブラリが与えられるならば、

各々の述語pについて、少なくとも1つのパスPath(p)が存在する。Path(p)は不完全であることができる。

gen(x)を生成するタスクは、パスの中でせいぜい1回現れるだけでよい。

タスク・ライブラリの中の全ての変数X={x_1, x_2, ..., x_n}について、変数順位の部分的順序を保つ全順序へgen(x_1), ..., gen(x_n)をソートすることができる。もしパスに沿った条件C(x_1), C(x_2), ＼1dots, C(x_k)を有するpを実現する不完全パスが存在すれば、各々の変数をせいぜい1回生成するpを実現する不完全パスが存在し、パスにおける条件の同じ集合が所与の全順序で注釈される。

各々の変数x_iについて、それを生成する1つだけのタスクが必要である。

属性閉包アルゴリズム：
各々の対等な集合のために、変数の順序に従って不完全パスを見つけるだけでよい。これは、閉包アルゴリズムへ次の規則を追加することによって達成される。

アルゴリズム：
属性閉包を作り上げることによって、全ての不完全パスを構築する。

アルゴリズム：
閉包からワークフローを構築する。

ケース3：事後条件における複数の一次出力
追加の仮定：
タスクは複数の出力を有することができ、その各々は前のセクションで指定されたように述語の合接である。もしタスクTが複数の出力を有すれば、各々の出力は1つだけの一次述語を有する。更に、もしp_i,p_jがTの出力の一次述語であれば、Rank(p_i)はRank(p_j)よりも高くなく、または低くない。

ケース4：複数の出力および否定を許可する
順位の定義を拡張する：
a. 述語は、前のセクションと同じように部分的順序で配列することができ、順位の概念は述語の否定へ拡張される。
b. Rank(p)=Rank(ノットp)
c. Rank(p)=Rank(q), pノットq → p=ノットq

述語およびその否定は同じ順位を有し、それは2つのリテラルが同じ順位を有する唯一の場合である。

モデルは、事前条件における或る制限否定形式および複数出力を許可するように拡張される。

6.8 BPIフレームワーク型アプリケーション（可能な例であるが、これらに限定されるわけではない）
BPIフレームワークは、広範囲のビジネスプロセスの自動化で使用可能である。ビジネスプロセスの自動化は次のファイナンシャルサービス・ワークフローを含むが、それに限定されるわけではない。

6.8.1 コーポレート動作管理
保管財産管理組織におけるコーポレート動作ビジネスプロセスの管理は、ビジネス・フロー、規則、および状態管理の複雑な組み合わせを必要とする。コーポレート動作ワークフローは、独立モジュールとしての7つのステージ、例えばデータの捕捉、事象の証明、権利の付与、通知、意思決定、請求書の転記、および決済を含む。それはBPIフレームワーク上で展開され、データ・モデルおよび外部システムとのインタフェースについて企業標準、例えばMDDL、SWIFT MT564/5を使用する。

6.8.2 市場データ、ポートフォリオ、および遵守アプリケーションと発注管理システムとの統合
伝統的発注管理システムは、他のファイナンシャル・システム、例えば市場データ、ポートフォリオ、および遵守アプリケーションへ良好に統合されない、BPIフレームワークは、統合ワークフローを自動化する適切な方法を提供する。

6.8.3 データ管理システム
ファイナンシャル・データの正確なリポジトリ（多くの場合、「ゴールド・コピー」として知られる）を作り出すことは、複雑な自動化および人間のワークフローを必要とする。伝統的に、これらのビジネス・ワークフローおよび規則は、特注プログラムとして実現される。その場合、市場の要求に基づいてビジネス論理を変更する能力は、費用のかかる遅いプロセスである。BPIフレームワークは、これらのビジネスプロセスを自動化する方法を提供する。この場合、システムの残りへ大きなインパクトを与えることなく、要求に従ってビジネス規則を変更することができる。

7 スキーマおよび例示的インスタンス
7.1 スキーマ1：BPDLスキーマ

7.2 交渉プロセスの具体的データ・モデルのXMLスキーマ仕様

7.3 交渉データ・モデルのインスタンス

7.4 高レベル・データ・モデルの例

本発明の局面が本発明の例示的態様に関して説明された。当業者は、この開示のレビューから、添付された特許請求の範囲および精神内の多数の他の態様、修正、および変形を思いつくと考えられる。

TOC
ビジネスプロセスの自動化・・・・・・・・・・・・・・・・・・・・・・・・・・・1
1 発明の分野・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 1
2 発明の背景・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 1
3 要約・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 3
4 図面の簡単な説明・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 5
5 詳細な説明・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 6
5.1 フロー、規則、および状態（FRS）へのビジネスプロセスの分解・・・・・・・8
5.2 BPDおよび成分フロー、規則、および状態の分類法・・・・・・・・・・・・・13
5.3 BPIの宣言型仕様・・・・・・・・・・・・・・・・・・・・・・・・・・・・13
5.3.2 動作の意味論・・・・・・・・・・・・・・・・・・・・・・・・・・・21
5.3.3 ワークフロー内の異なった点におけるアサーション・・・・・・・・・・32
5.4 BPI実行フレームワーク・・・・・・・・・・・・・・・・・・・・・・・・・32
5.4.1 フロー、規則、および状態エンジン・・・・・・・・・・・・・・・・・32
5.4.2 BPIフロー、規則、および状態の間の調整・・・・・・・・・・・・・・・33
5.4.3 BPIの管理・・・・・・・・・・・・・・・・・・・・・・・・・・・・・34
5.5 ビジネスプロセス・ワークフローの正しさ・・・・・・・・・・・・・・・・36
5.5.1 ワークフローを自動的に注釈する・・・・・・・・・・・・・・・・・・36
5.5.2 ワークフローの正しさを自動的に検証する・・・・・・・・・・・・・・37
5.6 ビジネスプロセスのモデル・チェック・・・・・・・・・・・・・・・・・・37
5.6.1 モデル・チェックのアプローチ・・・・・・・・・・・・・・・・・・・38
5.6.2 設計時のモデル・チェック・・・・・・・・・・・・・・・・・・・・・38
5.6.3 実行時のモニタリング・・・・・・・・・・・・・・・・・・・・・・・40
5.7 ビジネス・ワークフローの自動的合成・・・・・・・・・・・・・・・・・・40
5.8 BPIフレームワーク型アプリケーション（可能な例であるが、これらに限定されるわけではない）・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・45
5.8.1 コーポレート動作管理・・・・・・・・・・・・・・・・・・・・・・・45
5.8.2 市場データ、ポートフォリオ、および遵守アプリケーションとの発注管理システムの統合・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・45
5.8.3 データ管理システム・・・・・・・・・・・・・・・・・・・・・・・・45
6 スキーマおよび例示的インスタンス・・・・・・・・・・・・・・・・・・・・・47
6.1 スキーマ1：BPDLスキーマ・・・・・・・・・・・・・・・・・・・・・・・・47
6.2 交渉プロセスの具体的データ・モデルのXMLスキーマ仕様・・・・・・・・・・49
6.3 交渉データ・モデルのインスタンス・・・・・・・・・・・・・・・・・・・50
6.4 高レベル・データ・モデルの例・・・・・・・・・・・・・・・・・・・・・51
7 特許請求の範囲・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・52

9 発明の背景
ビジネス機能を自動化するプロセスおよびシステムが説明される。

Claims (25)

1. 宣言型言語を使用してビジネス論理を実行する自動ワークフロー・システムであって、
   フロー、規則、および状態をさらに含むプロセス記述を含み、
   フローがビジネス機能間の制御フローを表し、状態がビジネス・エンティティについて法的状態遷移を表し、かつ規則が、外部形式でビジネス・エンティティへ強制されるビジネス規則および方針を表す
   自動ワークフロー・システム。
2. 各々のタスクが事前条件および事後条件を有し、所望の事前条件および事後条件が実行前に自動的に設計されるタスク・ライブラリをさらに含む、
   請求項1記載の宣言型言語を使用してビジネス論理を実行する自動ワークフロー・システム。
3. フロー、規則、および状態を調整するコーディネータ
   をさらに含む、請求項1記載の宣言型言語を使用してビジネス論理を実行する自動ワークフロー・システム。
4. 複数の当事者によって使用され、当事者の1人が、他の関係者のために信頼された第三者として動作して、かつプロトコルの正しさを保証すること、設計時および実行時の双方で全てのインタラクションの記録を維持すること、および他の関係者のために幾つかの活動をワークフローの一部分として実行することを含むサービスを実行する、請求項1記載の宣言型言語を使用してビジネス論理を実行する自動ワークフロー・システム。
5. 宣言型言語がXMLである、請求項1記載の宣言型言語を使用してビジネス論理を実行する自動ワークフロー・システム。
6. 宣言型言語がWSDLである、請求項1記載の宣言型言語を使用してビジネス論理を実行する自動ワークフロー・システム。
7. ワークフローがアサーションを更に含み、アサーションがワークフロー内のその点でシステムの事前条件および事後条件を記述する、請求項1記載の宣言型言語を使用してビジネス論理を実行する自動ワークフロー・システム。
8. 実行が正しいことを確実にするため、システムが実行する実行時にアサーションがチェックされる、請求項7記載の宣言型言語を使用してビジネス論理を実行する自動ワークフロー・システム。
9. アサーションが指定される設計の前に設計の正しさを証明するため事前条件のアサーションが使用される、請求項7記載の宣言型言語を使用してビジネス論理を実行する自動ワークフロー・システム。
10. ワークフローの終わりで設計の正しさを証明するため事後条件のアサーションが使用される、請求項7記載の宣言型言語を使用してビジネス論理を実行する自動ワークフロー・システム。
11. ウェブ・ベース・トランスポート・プロトコルを使用してビジネス論理を実行する自動ワークフロー・システムであって、
    プロセス記述を含み、プロセス記述が、フロー、規則、および状態を更に含み、フローがビジネス機能間の制御フローを表し、状態がビジネス・エンティティの法的状態遷移を表し、かつ規則が制御フローに影響を与えて1つの状態から他の状態への状態遷移を起こさせる自動ワークフロー・システム。
12. タスクのライブラリをさらに含み、各々のタスクが事前条件および事後条件を有し、所望の事前条件および事後条件が実行前に自動的に設計される、
    請求項11記載のウェブ・ベース・トランスポート・プロトコルを使用してビジネス論理を実行する自動ワークフロー・システム。
13. フロー、規則、および状態を調整するコーディネータ
    をさらに含む、請求項11記載のウェブ・ベース・トランスポート・プロトコルを使用してビジネス論理を実行する自動ワークフロー・システム。
14. 複数の当事者によって使用され、当事者の1人が他の関係者のために信頼された第三者として動作して、かつプロトコルの正しさを保証すること、設計時および実行時の双方で全てのインタラクションの記録を維持すること、および他の関係者のために幾つかの活動をワークフローの一部分として実行することを含むサービスを実行する、請求項11記載のウェブ・ベース・トランスポート・プロトコルを使用してビジネス論理を実行する自動ワークフロー・システム。
15. ウェブ・ベース・トランスポート・プロトコルがhttpである、請求項11記載のウェブ・ベース・トランスポート・プロトコルを使用してビジネス論理を実行する自動ワークフロー・システム。
16. ウェブ・ベース・トランスポート・プロトコルがhttpsである、請求項11記載のウェブ・ベース・トランスポート・プロトコルを使用してビジネス論理を実行する自動ワークフロー・システム。
17. ワークフローが、アサーションを更に含み、アサーションがワークフロー内のその点でシステムの事前条件および事後条件を記述する、請求項11記載のウェブ・ベース・トランスポート・プロトコルを使用してビジネス論理を実行する自動ワークフロー・システム。
18. 実行が正しいことを確実にするため、システムが実行する実行時にアサーションがチェックされる、請求項17記載のウェブ・ベース・トランスポート・プロトコルを使用してビジネス論理を実行する自動ワークフロー・システム。
19. アサーションが指定された設計の前に設計の正しさを証明するため事前条件アサーションが使用される、
    請求項17記載のウェブ・ベース・トランスポート・プロトコルを使用してビジネス論理を実行する自動ワークフロー・システム。
20. ワークフローの終わりで設計の正しさを証明するため事後条件のアサーションが使用される、
    請求項17記載のウェブ・ベース・トランスポート・プロトコルを使用してビジネス論理を実行する自動ワークフロー・システム。
21. 宣言型言語を使用してビジネス論理を実行するシステムであって、
    フロー、規則、および状態を記憶するメディアを含むプロセス記述を記憶する手段であって、フローがビジネス機能間の制御フローを表し、状態がビジネス・エンティティの法的状態遷移を表し、かつ規則が外部形式でビジネス・エンティティに強制されるビジネス規則および方針を表す手段と、
    前記プロセスを実行する手段と
    を含むシステム。
22. 宣言型言語を使用してビジネス論理を実行するプロセスであって、
    フロー、規則、および状態を記憶するメディアを含むプロセス記述を記憶し、フローがビジネス機能間の制御フローを表し、状態がビジネス・エンティティの法的状態遷移を表し、かつ規則が外部形式でビジネス・エンティティへ強制されるビジネス規則および方針を表す段階；および
    前記プロセスを実行する段階を含むプロセス。
23. ウェブ・ベース・トランスポート・プロトコルを使用してビジネス論理を実行する自動ワークフロー・システムであって、
    フロー、規則、および状態を記憶するメディアを含むプロセス記述を記憶する手段であって、フローがビジネス機能間の制御フローを表し、状態がビジネス・エンティティの法的状態遷移を表し、かつ規則が外部形式でビジネス・エンティティへ強制されるビジネス規則および方針を表す手段と、
    前記プロセスを実行する手段と
    を含むシステム。
24. ウェブ・ベース・トランスポート・プロトコルを使用してビジネス論理を実行するプロセスであって、
    フロー、規則、および状態を記憶するメディアを含むプロセス記述を記憶し、フローがビジネス機能間の制御フローを表し、状態がビジネス・エンティティの法的状態遷移を表し、かつ規則が外部形式でビジネス・エンティティへ強制されるビジネス規則および方針を表す段階；および
    前記プロセスを実行する段階を含むプロセス。
25. ウェブ・ベース・トランスポート・プロトコルを使用してビジネス論理を実行するプログラムを記憶するコンピュータ読み取り可能メディアであって、前記プログラムが、
    フロー、規則、および状態を記憶するメディアを含むプロセス記述を記憶し、フローがビジネス機能間の制御フローを表し、状態がビジネス・エンティティの法的状態遷移を表し、かつ規則が外部形式でビジネス・エンティティへ強制されるビジネス規則および方針を表す段階；および
    前記プロセスを実行する段階を有するメディア。

Images