宣言型言語を使用してビジネス論理を実行する自動ワークフローシステムであって、フロー、規則、および状態をさらに含むプロセス記述を含み、フローがビジネス機能間の制御フローを表し、状態がビジネスエンティティについて法的状態遷移を表し、かつ規則が、外部形式でビジネスエンティティへ強制されるビジネス規則および方針を表す自動ワークフローシステム。各々のタスクが事前条件および事後条件を有し、所望の事前条件および事後条件が実行前に自動的に設計されるタスクライブラリをさらに含む、請求項1記載の宣言型言語を使用してビジネス論理を実行する自動ワークフローシステム。フロー、規則、および状態を調整するコーディネータをさらに含む、請求項1記載の宣言型言語を使用してビジネス論理を実行する自動ワークフローシステム。複数の当事者によって使用され、当事者の1人が、他の関係者のために信頼された第三者として動作して、かつプロトコルの正しさを保証すること、設計時および実行時の双方で全てのインタラクションの記録を維持すること、および他の関係者のために幾つかの活動をワークフローの一部分として実行することを含むサービスを実行する、請求項1記載の宣言型言語を使用してビジネス論理を実行する自動ワークフローシステム。宣言型言語がXMLである、請求項1記載の宣言型言語を使用してビジネス論理を実行する自動ワークフローシステム。宣言型言語がWSDLである、請求項1記載の宣言型言語を使用してビジネス論理を実行する自動ワークフローシステム。ワークフローがアサーションを更に含み、アサーションがワークフロー内のその点でシステムの事前条件および事後条件を記述する、請求項1記載の宣言型言語を使用してビジネス論理を実行する自動ワークフローシステム。実行が正しいことを確実にするため、システムが実行する実行時にアサーションがチェックされる、請求項7記載の宣言型言語を使用してビジネス論理を実行する自動ワークフローシステム。アサーションが指定される設計の前に設計の正しさを証明するため事前条件のアサーションが使用される、請求項7記載の宣言型言語を使用してビジネス論理を実行する自動ワークフローシステム。ワークフローの終わりで設計の正しさを証明するため事後条件のアサーションが使用される、請求項7記載の宣言型言語を使用してビジネス論理を実行する自動ワークフローシステム。ウェブベーストランスポートプロトコルを使用してビジネス論理を実行する自動ワークフローシステムであって、プロセス記述を含み、プロセス記述が、フロー、規則、および状態を更に含み、フローがビジネス機能間の制御フローを表し、状態がビジネスエンティティの法的状態遷移を表し、かつ規則が制御フローに影響を与えて1つの状態から他の状態への状態遷移を起こさせる自動ワークフローシステム。タスクのライブラリをさらに含み、各々のタスクが事前条件および事後条件を有し、所望の事前条件および事後条件が実行前に自動的に設計される、請求項11記載のウェブベーストランスポートプロトコルを使用してビジネス論理を実行する自動ワークフローシステム。フロー、規則、および状態を調整するコーディネータをさらに含む、請求項11記載のウェブベーストランスポートプロトコルを使用してビジネス論理を実行する自動ワークフローシステム。複数の当事者によって使用され、当事者の1人が他の関係者のために信頼された第三者として動作して、かつプロトコルの正しさを保証すること、設計時および実行時の双方で全てのインタラクションの記録を維持すること、および他の関係者のために幾つかの活動をワークフローの一部分として実行することを含むサービスを実行する、請求項11記載のウェブベーストランスポートプロトコルを使用してビジネス論理を実行する自動ワークフローシステム。ウェブベーストランスポートプロトコルがhttpである、請求項11記載のウェブベーストランスポートプロトコルを使用してビジネス論理を実行する自動ワークフローシステム。ウェブベーストランスポートプロトコルがhttpsである、請求項11記載のウェブベーストランスポートプロトコルを使用してビジネス論理を実行する自動ワークフローシステム。ワークフローが、アサーションを更に含み、アサーションがワークフロー内のその点でシステムの事前条件および事後条件を記述する、請求項11記載のウェブベーストランスポートプロトコルを使用してビジネス論理を実行する自動ワークフローシステム。実行が正しいことを確実にするため、システムが実行する実行時にアサーションがチェックされる、請求項17記載のウェブベーストランスポートプロトコルを使用してビジネス論理を実行する自動ワークフローシステム。アサーションが指定された設計の前に設計の正しさを証明するため事前条件アサーションが使用される、請求項17記載のウェブベーストランスポートプロトコルを使用してビジネス論理を実行する自動ワークフローシステム。ワークフローの終わりで設計の正しさを証明するため事後条件のアサーションが使用される、請求項17記載のウェブベーストランスポートプロトコルを使用してビジネス論理を実行する自動ワークフローシステム。宣言型言語を使用してビジネス論理を実行するシステムであって、フロー、規則、および状態を記憶するメディアを含むプロセス記述を記憶する手段であって、フローがビジネス機能間の制御フローを表し、状態がビジネスエンティティの法的状態遷移を表し、かつ規則が外部形式でビジネスエンティティに強制されるビジネス規則および方針を表す手段と、前記プロセスを実行する手段とを含むシステム。宣言型言語を使用してビジネス論理を実行するプロセスであって、フロー、規則、および状態を記憶するメディアを含むプロセス記述を記憶し、フローがビジネス機能間の制御フローを表し、状態がビジネスエンティティの法的状態遷移を表し、かつ規則が外部形式でビジネスエンティティへ強制されるビジネス規則および方針を表す段階;および前記プロセスを実行する段階を含むプロセス。ウェブベーストランスポートプロトコルを使用してビジネス論理を実行する自動ワークフローシステムであって、フロー、規則、および状態を記憶するメディアを含むプロセス記述を記憶する手段であって、フローがビジネス機能間の制御フローを表し、状態がビジネスエンティティの法的状態遷移を表し、かつ規則が外部形式でビジネスエンティティへ強制されるビジネス規則および方針を表す手段と、前記プロセスを実行する手段とを含むシステム。ウェブベーストランスポートプロトコルを使用してビジネス論理を実行するプロセスであって、フロー、規則、および状態を記憶するメディアを含むプロセス記述を記憶し、フローがビジネス機能間の制御フローを表し、状態がビジネスエンティティの法的状態遷移を表し、かつ規則が外部形式でビジネスエンティティへ強制されるビジネス規則および方針を表す段階;および前記プロセスを実行する段階を含むプロセス。ウェブベーストランスポートプロトコルを使用してビジネス論理を実行するプログラムを記憶するコンピュータ読み取り可能メディアであって、前記プログラムが、フロー、規則、および状態を記憶するメディアを含むプロセス記述を記憶し、フローがビジネス機能間の制御フローを表し、状態がビジネスエンティティの法的状態遷移を表し、かつ規則が外部形式でビジネスエンティティへ強制されるビジネス規則および方針を表す段階;および前記プロセスを実行する段階を有するメディア。6詳細な説明本発明の局面は、組織およびまたは個人の中および間のビジネスプロセスが、XMLおよび非限定的にSOAP、WSDL、WSIL、UDDI、およびBPEL4WSを含むウェブサービス標準に基づいた標準型サービス指向ビジネスプロセス自動化アーキテクチャを使用して自動化されるシステムおよび方法に関連する。本発明の少なくとも1つの局面は、ビジネスプロセスの実行フレームワークをさらに含む。ビジネスプロセスは、単純および複雑な機械および人間のワークフロー、ビジネス規則の評価、ビジネスエンティティのライフサイクル管理、および既存のアプリケーションとの統合に関連するファイナンシャルビジネスプロセスアプリケーションを含むが、それに限定されるわけではない。本発明の局面は、ビジネスプロセス仕様をビジネスフロー、ビジネス規則、およびビジネス状態へ解体する分解方法論にさらに関連する。ビジネスフロー、規則、および状態は、宣言型言語で定義され、フロー、規則、および状態エンジンと、フレームワーク内のビジネスプロセス実行モデルとの間のインタラクション、協力、および調整を含む。本明細書で説明される様々なビジネスフロー、規則、および状態は、コンピュータ読み取り可能メディアに存在してよい。このメディアは、取り外し可能メディア、固定メディア、光学および磁気記憶装置などを含むが、これらに限定されるわけではない。例えば、本発明の局面は、ホストコンピュータまたはコンピューティングネットワークまたはクライアント側コンピュータに常駐してよい。以下の説明は、読者を助けるため次のように分割される。61フロー、規則、および状態FRSへのビジネスプロセスの分解62BPDおよび成分フロー、規則、および状態の分類法63BPIの宣言型仕様631フロー仕様632動作の意味論633ワークフロー内の異なった点におけるアサーション64BPI実行フレームワーク641フロー、規則、および状態エンジン642BPIフロー、規則、および状態の間の調整643BPIの管理65ビジネスプロセスワークフローの正しさ651ワークフローを自動的に注釈する652ワークフローの正しさを自動的に検証する66ビジネスプロセスのモデルチェック661モデルチェックのアプローチ662設計時のモデルチェック663実行時のモニタリング67ビジネスワークフローの自動的合成68BPIフレームワーク型アプリケーション可能な例であるが、これらに限定されるわけではない681コーポレート動作管理682市場データ、ポートフォリオ、および遵守アプリケーションとの発注管理システムの統合683データ管理システム次のセクションは、本発明の局面に従って使用されてよい例示的スキーマおよび例示的インスタンスに関連する。7スキーマおよび例示的インスタンス71スキーマ1:BPDLスキーマ72交渉プロセスの具体的データモデルのXMLスキーマ仕様73交渉データモデルのインスタンス74高レベルデータモデルの例61フロー、規則、および状態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およびビジネス対ビジネスおよびビジネス対消費者のインタラクションB2BB2Cを達成するため、企業の中で使用されるウェブサービスは、ますます多くなってきている。しかし、ウェブサービスの技術的成熟とは対照的に、ウェブサービスの編成によってビジネスプロセス管理を可能にするツールは、比較的に原始状態のままである。現実世界のビジネスプロセスを、どのようにしてウェブサービスおよびメッセージフローの集合体として表現するか。大部分の場合、熟練した統合者がマスタアプリケーションを作り出す。マスタアプリケーションはコンポーネントウェブサービスを適切な順序で呼び出し、それらウェブサービスによって使用されたキー値を追跡し、結果を集積し、その他のことを行う。このビジネス論理をコーディングするアプローチは、当座のビジネス要件を成功裏に満たすことができる意味で働くが、コンポーネントモデルの利益をテコ入れすることはできない。即ち、製品化されたソリューションではなく、そのようなポイントソリューションが作り出される場合、ビジネス意味論における繰り返しパターンは、繰り返し機能のようには容易に再使用され得ない。それらの繰り返しパターンは、多くの場合、次のソリューションが現れるように新しくコーディングされる必要がある。更に悪いことに、再使用性を取得する努力の中で、ビジネス意味論的考慮がウェブサービス自身の中へプッシュされる傾向があり、コンポーネントモデルを崩壊させ、ウェブサービスの再使用可能性を低減させる。より高いレベルのビジネス抽象概念をモデル化する十分な手段がないと、ビジネスプロセスのフロー、データ、および規則に関連づけられたIPRは失われる。本発明の少なくとも1つの局面は、既存のウェブサービス標準に基づいたビジネスプロセス管理フレームワークである。ビジネスプロセスインスタンスBPIの用語は、任意レベルの細分性を有し、ビジネスフロー、規則、および状態を含む自動化ビジネスプロセスとして定義される。より大きなビジネスプロセスの自動化を表すため、複数のBPIを階層へ組織化することができる。ビジネスプロセスインスタンスの定義はBPDと呼ばれる。本発明の少なくとも1つの局面は、非伝統的方式でビジネスプロセス定義BPDを作り出す方法論を含み、ビジネスプロセスインスタンスBPIを実行するフレームワークを含む。本発明の少なくとも1つの局面は、XML型言語のビジネスプロセス定義言語BPDLを含み、ビジネスプロセスを宣言型で指定する。BPI仕様は、ビジネスプロセスがどのように実行されるかを定義するだけでなく、プロセス実行の正確な意味、即ちプロセスが何を行うように想定されているかを定義する。言い換えれば、ビジネスプロセスの意味論は、その実行時の動作に加えて、形式的に定義される。BPIフレームワークと呼ばれるビジネスプロセス管理フレームワークは、ビジネスプロセスを定義、展開、管理、および実行するツール、コンポーネント、および環境を提供する。BPIは、活動およびデータエンティティを、そのビルディングブロックとして使用する。全ての活動はウェブサービスインタフェースをWSDLで公開し、したがってウェブサービスとして取り扱われることが仮定される。データエンティティは、XMLスキーマによってモデル化されるXML文書としてアクセスされ得る。BPDLは、ビジネスプロセスを3つのコンポーネント、即ちフロー、規則、および状態へ分解することによってビジネスプロセスを記述する。フローは、活動の間の制御論理およびデータフローを定義する。規則は決定方針を定義し、状態は状態遷移モデルとの関係でビジネスデータエンティティの正規の動作を定義する。BPIを作り出す場合、ビジネスプロセスの平明な英語記述が、その成分ビジネスフロー、規則、および状態へ分解される。第1レベルの分解は、UnifiedModelingLanguageUMLまたは類似の表記法で構造化英語および図式を組み合わせることである。UMLシーケンス図式および活動図式は、ビジネスプロセスの活動の間の実行順序および論理依存情報を捕捉し、したがってBPDフロー仕様の基礎を形成する。UML状態図式は、ビジネスエンティティの状態遷移を捕捉し、BPD状態モデルの基礎を形成する。規則は、一般的に、フロー内の決定点または状態図式内の状態遷移に関連づけられる。規則は、フローまたは状態から分離される。なぜなら、第1に、規則は変わるかもしれないが、フローまたは状態モデルの一般的構造は同一に保たれるからである。第2に、同じ規則が異なった状況で使用されるかもしれない。第3に、ビジネス規則を外在化し、ビジネス規則を変える権能をビジネスユーザに与えることが可能になる。したがって、フロー、規則、および状態は、BPDLの宣言型形式で別々に指定される。BPDフロー仕様言語はBPEL4WSに基づく。BPEL4WSはウェブサービス編成プロトコルまたはワークフローを定義するXML型標準である。WSDLおよびBPEL4WS言語は拡張され、ウェブサービス操作およびBPEL4WSワークフロー上で形式的意味論を注釈することができる。XML型ビジネス規則言語BRLは、様々なタイプのビジネス規則の言語中立記述として使用される。XML型状態機械言語のStateMLは、異なったビジネスエンティティの状態遷移モデルを指定するために使用される。BPD仕様は、フロー、規則、および状態の仕様を直接には含まない。その代わりに、BPD仕様は或るレベルの回り道を追加することによって、それらの定義を参照する。次の記載は、取引交渉プロセスにおけるBPD仕様の簡単な例である。62BPDおよび成分フロー、規則、および状態の分類法BPIは、コンポーネント指向ソフトウェア開発におけるコンポーネントと類似している。コンポーネント指向ソフトウェア開発の欠点の1つは、膨大な数のコンポーネントが相互に重複し、それを避ける中央コンポーネントリポジトリまたはコンポーネント関連情報が存在しないことである。ウェブサービスパラダイムにおいて、この問題はUDDIの概念によって解決される。UDDIは、ウェブサービスに関するメタ情報のリポジトリとして使用され得る。BPIはウェブサービスとして開示されるから、BPIの場合にも同じ手法が有効である。BPDLによるBPI定義は、BPIおよびその成分フロー、規則、および状態の分類情報を含む。BPIの分類法は、図4で示されるように、BPDL文書のノードとして捕捉される。63BPIの宣言型仕様ビジネス要件が本発明者らの3つの主要なコンポーネントカテゴリへ適切に分解されると、XML型ビジネスプロセス定義言語であるBPDLを介して、要件をBPD文書の合成集合として表現することができる。BPDLのW3Cスタイルのスキーマがスキーマ1で示され、図4でグラフとして表される。BPDLはルート要素の下に主要な要素、即ち、、、、、およびを含む。本発明者らは、BPD内のフロー、規則、および状態モデルの場所を既に説明した。ビューは、他の要素が再使用可能バックエンド能力を提供する同じやり方で再使用可能GUI能力を提供する。エンティティは、ビジネスプロセスに関連したXMLスキーマに基づいて、名前の付いたビジネスエンティティを指す。サブBPIは、個々のコンポーネントが再使用される同じ方法で、既存のBPIが再使用されることを可能にする。これら主要な要素の各々は一つまたは複数の部分要素を含む。部分要素は、部分要素の共通集合の使用を介して親集合物の単一インスタンスを示す。スキーマ1で捕捉されるスキーマを有するこの集合は、主要な要素の実行時および設計時調整に必要な情報を提供する。これらの共通要素は、更にBPD要素自身へ適用され、したがって他のBPDは階層様式でそれを参照してよい。BPD要素は、更に、サーチを容易にする分類法情報を保持する要素を含む。BPDの適切な分類法的分類は、ビジネスプロセス再使用の値を取得するため絶対に必要である。分類法的要素は、確立された用語辞書に関してBPIの機能および目的を識別するデータを含む。BPDが分類法的タグと一緒にBPDリポジトリに記憶される場合、BPI設計ツールは、この情報を解析して、或るタイプのビジネスプロセスを探索している開発者の利用に供することができる。共通の部分要素の集合の中で、1つはBPI設計ツールによって排他的に使用され、他の2つは主としてBPI実行時エンジンによって使用される。前者のカテゴリとしてがある。これは要素および注釈特徴の目的を普通の書き方で要約したものである。この要約は、BPIコンポーネントリポジトリ内のコンポーネントをブラウズする場合、開発者へ表示される。他の2つの要素は、コンポーネントの解決および呼び出し手段を提供する。<URI>は、具体的コンポーネントの一意のリソース識別子を指定して、BPIエンジンがそれを特定して呼び出すことができるようにする。これは、BPDLがコンポーネント自身について詳細を提供せず、それらを一緒に結合する方法だけを提供するという全体的見解に沿ったものである。もし<URI>が結合される部分を指定すれば、要素が結合を行う糸である。はBPI名をコンポーネントへ与え、それによって他のBPI準備完了コンポーネントは、それを参照することができる。これらの名前は、BPDの中、および階層BPD集合の大きいコンテキストの中で、一意に解決可能でなければならない。BPIフレームワークは、2つの基本的概念の使用によってフロー、規則、および状態の調整統合を可能にする。第1の概念は、相互抽象呼び出しである。これは、フロー、規則、および状態エンジンが、BPIフレームワークへ渡された指名参照を介して相互を呼び出す能力を意味する。確かに、フロー、規則、およびまたは状態がBPI技術を利用しないで一緒に結合されることは可能である。例えば、フローは規則を呼び出して、どのフローパスを取るかを決定することができる。規則は、偽と評価すれば状態遷移を要求することができる。状態遷移はフローの実行をトリガして、遷移の複雑なログを提供することができる。しかし、この直接参照ストラテジの欠点は、調整が静的で、具体的参照がフロー、規則、および状態機械の中へ組み込まれることである。BPIはこの関係を抽象化し、BPI準備完了フロー、規則、および状態機械は、アドレスではなくBPI名によって相互を参照する。もし本発明者らが、所与のBPIを記述するBPDL文書を見るとすれば、本発明者らは次のようなエントリを見ると考えられる。直接呼び出しの例として、もしフローが上記の規則集合を呼び出す必要があれば、フローはhttpfauxurireuterscomcrmclientcategorizeasmxを呼び出す命令を含む必要があると考えられる。後で規則集合の他のより複雑なバージョンがhttpfauxurireuterscomcrmclientnewcategorizeasmxで利用可能になった場合、それを利用するためフロー自身が変更されなければならない。しかし、BPIフレームワークでは、規則集合を直接呼び出さず、その代わりに規則集合主要クライアント規則の呼び出しをBPIエンジンに要求することによって、それが避けられる。新しい規則集合を利用するためには、フローへの変更は必要でなく、BPDL文書の変更が必要なだけである。第2の概念は、フロー、規則、および状態機械の間の相互データアクセス可能性である。全ては、実行している間、ビジネスデータの同じコピーを参照、評価、および修正できなければならない。この重要性は明白であると考えられる。即ち、もしビジネスプロセスの過程で、例えばフローエンジンが特定のデータ部分を修正するならば、例えば規則エンジンへの後の呼び出しは、規則を正しく評価するため、その変更に気づく必要がある。データの管理を助けるため、BPIはエンティティという構成体を使用し、ビジネスプロセスからデータを分離する。原始的フローが行うように特定のロケーションからデータを要求するのではなく、BPI準備完了フローはBPDL記述エンティティからデータを要求する。BPIフレームワークは、データのライフサイクルを管理する状態機械の能力をテコ入れする。こうして、エンティティは、その具体化、状態進行、および破壊を提供するため状態機械へ関連づけられる。相互抽象呼び出しおよび相互データアクセスが、フロー、規則、および状態のBPDL記述集合の間に、使用可能であるが柔軟な接続を提供することによって、BPDLは、ビジネス要件の論理集合を具体化する明記目的を十分に充足することができる。更に、BPDLは階層であることができ、指名フローが指名規則を呼び出す同じ方式で、BPDL内で指名により相互を参照することができる。したがって、個々のBPIは一緒に積層および配列され、より高次のBPIを形成し、より大きなビジネスプロセスを自動化する。指名された参照は、プロセスおよびエンティティの実行時解決を可能にするだけでなく、設計時依存分析を可能にする。コンポーネントがBPDへ追加されるにつれて、BPI設計者は、そのコンポーネントが、どのような他の指名フロー、規則、状態機械、およびエンティティを参照するかを示し、未解決の参照が残らなくなるまで、他のコンポーネントをBPIに関連づけることを命ずることができる。指名コンポーネントへの全ての内部参照がBPDL文書内のBPI指名に対して検証されると、設計者は実行時の首尾一貫性を保証する。BPIフレームワークの真の美点は、これらの特徴を使用して、ビジネス要件が意図された方法でビジネス要件の本質を捕捉し、単一実装技術の制約の中へビジネス要件を埋没させないことである。フローとして最良に表現されたプロセスは、おそらく規則として最良に具体化された他のプロセスと同じように、各々が一緒に働く能力を犠牲にするがない。それによって、それらの要件を充足するために使用されるコンポーネントの選択を、後で最小のコストで変更することが可能になる。ビジネス要件と技術実装との間のインピーダンスを増加し、それらの要件の後続展開コストを減少することによって、BPIフレームワークは、ビジネスソリューションを構築する場合の新しい成熟度を可能にする。631フロー仕様ビジネスプロセスは、或るビジネス目的を達成するため共同して活動を実行する幾つかのアクタ、即ち人間またはコンピュータサービスを含む。活動間の制御論理およびデータフローは、一般的に、コントローラによって調整される。ビジネスプロセスの制御およびデータフロー論理は、例1図2および例2図3のようにグラフで示すことができる。ビジネスプロセスの制御フローおよびデータフローは、ワークフロー仕様言語で定義され得る。もし本発明者らが、WSDLによって記述されることのできるウェブサービスとして各々のタスクをモデル化すれば、ウェブサービス編成言語、例えばBPEL4WSが、ビジネスプロセスのワークフローを定義するために使用される。本発明者らは、BPEL4WSからの次の構成体が、ワークフローを構築するために使用されると仮定する。注意すべきは、BPDフロー仕様のベースとしてBPEL4WSが使用されるが、他のワークフローまたはウェブサービスをベースとする仕様も、類似の意味論の構成体をベースとするのであれば使用できることである。呼び出し操作は、値をパラメータへ割り当てることによって、ウェブサービスまたは他のワークフローを呼び出す。タスクの呼び出しは、BPEL4WSにおけるようなウェブサービスの呼び出しとは異なる。WSDL内のウェブサービスエンドポイントは、メッセージ渡しに基づいており、定義された意味論を有さない。タスクは意味論およびパラメータ集合を有する。割り当て値をロケーションへ割り当てる。障害のシグナリング名前終了実行を終了する。待機或る時間量だけ待機する。何もしない空の操作は何もしない。構造化された活動単純な活動は、複雑な活動を作るため組み立てられてよい。複雑な活動を構築するため、次のコンストラクタconstructorを使用することができる。ワークフロー状態が幾つかの正しさの規準を満足させることを保証するため、各々の活動または活動ブロックの前または後にアサーションを追加してよい。シーケンシャルコンストラクタシーケンシャルコンストラクタは、幾つかの活動ブロックを順次に実行する。同時コンストラクタ同時コンストラクタは、幾つかの活動ブロックを同時に実行する。全ての同時の活動が終了した場合、コンストラクタは終了する。同時コンストラクタを指定するため、フロー要素が使用される。リンクは、活動ブロック間の依存を定義する。activityblocks分岐コンストラクタ分岐コンストラクタは幾つかの活動ブロックの1つを実行する。そのブロックが終了した場合、コンストラクタは終了する。条件は、各々のブロックについてアサーションとして指定される。条件が真へ評価された場合のみ、ブロックを開始することができる。もし複数の条件が真へ評価されるならば、複数のブロックを選択して開始することができる。この場合、ブロックは、真の条件を有するブロックの中から非決定論的に選択される。whileコンストラクタwhileコンストラクタは、保護条件が真である間、ループ内の活動ブロックを実行する。それは、条件が偽へ評価されるまで、活動ブロックの実行を反復する。レースコンストラクタレースコンストラクタは幾つのタスクを同時に開始するが、最初に終了したタスクのみが効果を有する。他の活動ブロックは打ち切られる。activityblocks例外処理コンストラクタ例外条件はグローバル条件として指定され、サブフローとしてのハンドラが条件を処理する。条件が真になった場合、同時に実行していたサブフローは停止され、ハンドラが実行される。次にハンドラは、新しい例外を外側ブロックへ投げることができる。未処理の例外は外側ブロックへ自動的に投げられる。これは、上記の例で示されるように、サブフロー内の任意のタスクから生成される障害または例外事象を処理する構造化方法を提供する。ワークフロー仕様で例外状況を指定するため、本発明者らは次の表記法を使用する。事象事象は、タイマが時間切れになったか、外部メッセージがワークフローコントローラによって受け取られたために生成される。ピックどの事象が最初に起こったかに依存して、実行する1つのパスを選択する。632動作の意味論次のセクションは、ビジネスプロセスフレームワーク内の動作の意味論を説明する。6321SemanticLの紹介ワークフローの意味論を形式的に指定するため、数学モデルが展開される。モデルに基づいた宣言型言語であるSemanticLが、BPIフローの意味論を形式的に指定するために設計される。ビジネスプロセスのBPD仕様において、フローはXML型のワークフロー言語を使用して宣言型で指定される。多くのワークフロー仕様言語が既に提案された。例えば、BPEL4WS、WSCLなどである。BPD内のフロー記述言語としてBPEL4WSが選択される。それらの言語は、ビジネスプロセスの制御フロー論理を記述するのに十分である。しかし、意味論または正確な意味を記述する方法を提供するものはなかった。したがって、正しさはシステムによって自動的に保証されず、手作業のテストに依存する。SemanticLは、他のワークフロー仕様言語であることを意味するものではなく、ワークフロー仕様を注釈して、ワークフローおよびそれらのコンポーネントの意味論を形式的に定義するために使用される言語であることを意味する。SemanticLは厳格な数学モデルに基づいており、設計時および実行時に意味論的正しさを自動的に検証することができる。更に、新しいワークフローの、意味論的によく定義されたコンポーネントおよびビジネス目的のライブラリに基づいて、新しいワークフローを自動的に構築することができる。6322ワークフロー意味論を記述する形式的モデル形式的ワークフローモデルが説明される。ワークフローの意味論は、モデルに基づいて正確に定義されることができる。このモデルにおいて、ワークフロー仕様は、論理表現および推論を容易にするため高レベルで抽象化される。抽象化されたワークフロー仕様は、ABPDと呼ばれる。ABPDは4タプル、即ちとして定義される。各々の用語の定義およびBPDフローへの関係は、後で説明される。定義領域、変数、および定数:領域は同じタイプのオブジェクトの有限集合である。例えば、D12100は1から100までの整数の領域を表す。Aはその値を特定の領域から取る。例えば、x∈Dは領域Dの変数xを定義する。定数は、領域上の面白い値である。例えば、10はDの中の定数であり、真、偽はブールという領域の定数である。述語:述語はオブジェクトの或る特性またはオブジェクトの関係を主張する。述語はPの形式である。パラメータの数および各々のパラメータのタイプは、各々の述語について事前に定義されている。どのパラメータを取らない述語は、真または偽へ評価されるシンボルとして表現され得る。もしPが述語であれば、P∈TFである。述語は、ワークフローの現在の状態を特性化するために使用される。例えば、コンタクト済みは、交渉ワークフローの中の述語である。それは、もし取引業者AがBと成功裏にコンタクトしたのであれば真へ評価され、そうでなければ偽へ評価される。リテラル:リテラルは述語であるか、述語の否定である。リテラル述語|¬述語ワークフローデータベース:ワークフローを作り上げている述語の集合は、ワークフローデータベースを形成する。ワークフローデータベースはBPDL内の抽象的データモデルへ直接関係づけられる。抽象的データモデル内の葉要素は、ワークフローデータベース内の述語に対応する。述語は全てのタスクからグローバルに見ることができる。例えば、次に掲げるものは交渉の例におけるワークフローデータベースである。コンタクト済み受け入れ済み新指値A新指値B中断A中断B合意済みA合意済みB確認済みA確認済みB決済済みA決済済みB取引なし同一支店式:式は、所与のワークフローデータベースに基づく整合一次論理式である。具体的には、1述語は式である。2もしPQが式であれば、P∨Q、P∧Qは式である。3もしPが式であれば、¬Pは式である。4もしPが式であり、xが変数であれば、∀Pおよび∃Pは式である。タスク:タスクはワークフローのビルディングブロックである。単純タスクは、ACID特性を満足させる原子的動作を実行するタスクである。複雑タスクは、サブワークフローのような他のタスクを含み、したがって原子的でない。2つの複雑タスクが同時に実行している場合、それらの活動は任意の仕方で交錯する。本発明者らは最初に干渉がないことを仮定し、後でこの問題へ戻ることにする。単純タスクTはPTQによって記述される。PはTの事前条件である。Tは、それが開始した場合、Pが真である場合、かつ、その場合に限り、正しく実行する。簡単にするため、リテラルの合接形式でのみPを考える。P∧Tを幾つかの異なった状態で開始できる場合、P1∨P2TQTをタスクの集合と見ることができる。P1T1QP2T2QQはTの事後条件である。タスクTは幾つかの可能な終了状態を有することができ、それが終了した場合、1つが非決定論的に選択される。Qは∨∨の形式である。ここでQiはリテラルの合接であり、S1S2Snはワークフローコントローラによって観察可能なステータス変数である。Tが終了する場合、S1S2Snの1つのみが真であり、タスクによって非決定論的に選択される。簡単にするため、本発明者らは∨∨をQ1Q2Qnで表す。例えば、交渉Aというタスクは、次のように記述される。新指値B∨中断A交渉A合意済みA取引なしタスクの定義はフレーム意味論に従う。フレーム意味論とは、タスクの実行が、事後条件の中で言及された述語だけに影響を及ぼすことを意味する。形式的には、フレーム意味論は結果関数によって定義され得る。PはTが開始する場合のワークフロー状態であり、P⇒Pは真であり、Tが終了する場合、結果は真である。ここで、結果∧Qiであり、は、Qiで指名された全ての述語が削除されたPである。結果結果結果は、Tが終了する場合の全ての可能なワークフロー状態を定義する。または、Tが終了する状態から逆方向に推論することができる。Tが終了する場合、Qが真であると仮定する。ここで、Q⇒Q、剰余∧、ここでQQiはQおよびQiにおけるリテラル集合の集合差である。P∧剰余∧剰余∧剰余は、Tが開始する場合満足されなければならない。タスクのBPDL仕様は、抽象的データモデルとワークフローデータベースの間の関係に従ってABPD仕様へ容易に変換され得る。ワークフロー仕様:ワークフローは次の形式で指定される。P1P2P3PnWFQ1Q2Q3Qnここで、P1P2Pnはリテラルの合接であって相互に排他的である。Q1Q2Qnは次の形式である。∨∨∨∨∨∨これは、WFが開始する場合、WFの事前条件の1つが真でなければならず、もしP1が真であれば、Q1が事後条件であることを意味する。以下同様である。タスクは、ただ1つの事前条件および事後条件のペアを有する点で、ワークフロー仕様の特別のケースである。ワークフローは、ワークフローコンストラクタを使用してタスクから構築される。もし完全な構築が与えられると、ワークフローのフレーム意味論を引き出すことができ、ワークフローをタスクとして処理することができる。ワークフローコンストラクタの意味論ワークフロー仕様の中で、次のコンストラクタが許される。タスクもしワークフローが状態PにあってタスクT1が実行されるならば、次の推論規則が存在する。逆方向から推論する場合、シーケンシャルシーケンシャルコンストラクタは、2つのタスクが順次に実行することを指定する。SEQT1T2は、T1が実行され、次にT2が実行されることを意味する。シーケンシャルコンストラクタについて、次の推論規則が存在する。ANDコンストラクタのANDT1T2は、2つのタスクが同時に実行することを指定する。もし干渉が存在しなければ、ANDコンストラクタについて次の推論規則が存在する。ORコンストラクタのORT1T2Cは、もしCが真であれば、T1が実行され、そうでなければ、T2が実行されることを指定する。次の推論規則が存在する。レースレースコンストラクタのレースT1T2は、2つのタスクが同時に実行することを指定する。しかし、終了した最初のタスクがコミットし、他のタスクは打ち切られる。ループループコンストラクタのループT1Cは、Cが真になるまで、T1が反復して実行されることを指定する。ここで、Cは整合式である。ここで問題にするループは、ループ本体T1が少なくとも1回実行される意味で、反復ループである。反復ループおよびORコンストラクタを使用して、whileループを容易に構築することができる。ループ条件CおよびタスクT1の双方が論理式として指定されることに起因して、ループコンストラクタは、一般的なプログラミング言語のループよりも強力でない。その理由は、ループ本体が何回実行されようとも、ループコンストラクタの開始点に達した場合、ワークフロー状態は常に同じだからである。ループ不変式は単純にP1∧Cである。ループコンストラクタの意味論は、T1が幾つかの非決定論的出力を有するものと仮定して、T1が所望の出力を与えるまでT1を再試行することである。整合ループの必要条件は、ループの事後条件が矛盾を有さないことである。¬C∧Q1≠偽これは、たまたまループ終了の必要条件である。もしT1の出力が公平性の特性を満足させると仮定すれば、条件は更に十分条件である。事象およびピック事象は特殊なタスクである。事象は外部からワークフローコントローラへ送られるメッセージである。ワークフローコントローラは、いつ事象が起こるかについて制御を有さない。しかし、ワークフローコントローラは、それに登録された事象を認識し、それに応答する。例えば、新しいワークフローインスタンスを開始するか、事象の生起を待機している待機ワークフローを継続する。事象は事前条件を真として有するタスクとして指定され得る。真EQワークフロー仕様の中で事象を使用することはできない。その代わりに、ワークフローが或る事象の生起を待機していることを指定するため、ピックと呼ばれるコンストラクタが使用される。ピックは、一つまたは複数の受け取り節を有することができる。どの事象が最初に起こるかに依存して、1つのブロックがピックアップされて実行される。待機事象の1つが最終的に起こると仮定すれば、ピックコンストラクタの意味論は、レースの意味論に類似している。6323動作の意味論データモデルデータモデルは、ビジネスアプリケーションまたは関連ビジネスアプリケーションの集合の基礎をなすデータスキーマを定義する。更に、タスクおよびワークフローの意味論が定義される抽象的データモデルを記述する。データモデルは、XMLスキーマに基づく半構造化データタイプとして定義される。XMLスキーマに基づく多くの企業標準、例えばFpMLおよびNewsMLが存在する。それらは多くのアプリケーションの基礎を形成する。BPDLは、具体的データモデルおよび抽象的データモデル両方の表記法を提供する。具体的データモデルは、ワークフローコントローラが実行時に使用する実際のデータモデルであり、抽象的データモデルは、意味論的な仕様、検証、およびシミュレーション目的に必要な或る高レベル情報のみを指定する。具体的データモデル具体的データモデルは、ワークフローの実行に必要なデータスキーマを定義する。例えば、交渉プロセスのデータモデルは、72で示されるようにXMLスキーマ形式で定義され得る。これはFPML標準の拡張バージョンと考えることができる。交渉データモデルのインスタンスは73に例示される。抽象的データモデル抽象的データモデルは、具体的データモデルの上にある抽象的層である。それは、タスクおよびワークフローの事前および事後条件を指定するために使用される特性を定義する。例えば、確認済みと呼ばれる述語は、取引業者のために定義される。もし取引業者の取引が既に確認されていれば、確認済みは真であり、そうでなければ偽である。特性は、ブールまたは整数値へ評価される具体的データモデル上のXPATH表現として定義される。例えば、確認済みは、少なくとも1人の取引業者が確認済み状態へ達したものとして定義される。例は74で示される。タスクおよびタスクライブラリタスクはワークフロープロセスのビルディングブロックである。タスクは、一般的に、WSDLとのウェブサービスインタフェースとして指定される。タスクの意味論は、事前および事後条件の形式で指定される。タスクは事前条件の集合を有する。事前条件は、タスクが実行を開始する場合満足されなければならない。事前および事後条件は、抽象的データモデル上のブール表現である。タスクの実行本体は、ワークフローエンジンの外側にあるアプリケーションであるか単純タスク、サブワークフローである複雑タスク。要求要求は、タスクの事前条件を指定する。それは1つまたは幾つかの要求要素を有することができる。各々の要求要素は、式要素の集合を有する。式要素は、抽象的データモデル上のブールXPath表現である。要求要素は、全ての含まれた式要素が真である場合、かつ、その場合に限り満足される。少なくとも1つの要求要素が、タスクの実行を開始する前に満足されなければならない。negotiationSingleConfirm保証保証要素は、タスクの事後条件を指定する。要求要素と同じく、各々の保証も式要素の集合を有する。タスクが成功裏に終了する場合、保証要素の1つだけが出力として選択され、ワークフローデータはそれに従って更新されたことが保証され、XPath式は真へ評価される。更に、保証の中で明白に指定されたフィールドのみがタスクによって影響を受け、抽象的データモデル内の他のフィールドは変更されない。negotiationDoubleConfirmtrue例外例外は、タスクの例外的事後条件をXPath表現として指定する。それは保証仕様と類似している。唯一の差異は、タスクが失敗するか異常として出る場合の可能な出力を定義することである。negotiationtimeout6324ワークフローの意味論要求および保証タスク仕様と類似した仕方で、ワークフロー仕様は要求、保証、および例外を有することができる。これらはタスク仕様の場合と同じである。コンストラクタコンストラクタは、一般的に、BPEL4WS内の構文論に従い、本発明者らはコンストラクタをアサーションで注釈する方法を提供する。抽象的データモデル上のXPath表現633ワークフロー内の異なった点におけるアサーション64BPI実行フレームワーク以下のセクションはBPI実行フレームワークを説明する。641フロー、規則、および状態エンジンBPI実行フレームワークは3つのコアコンポーネント、即ち、フローエンジン、規則エンジン、および状態エンジンを有する。3つのエンジンは相互にインタラクションを行い、ビジネスプロセスの実行中に既存の領域サービスを呼び出す。領域サービスは、領域特定機能をウェブサービスとして提供する。例えば、顧客関係管理サービスは、顧客関係の管理に関連する機能、例えば顧客情報の検索、顧客ディレクトリのサーチなどを提供する。領域サービスは、新しいアプリケーションへ統合できるビルディングブロックを提供する。フローエンジンは、所与のワークフロー仕様に従ってBPEL4WSプログラムの形式でウェブサービスを編成する。ワークフローがフローエンジンで展開される場合、そのフローの一意のエントリポイントがウェブサービスとして作り出される。メッセージが対応するエントリポイントで受け取られる場合、フロー実行の新しいインスタンスが作り出されて開始される。実行中、フローは領域特定機能を実行するため領域サービスを呼び出し、規則を評価するため規則エンジンを呼び出し、状態のクエリーまたは遷移を要求するため状態エンジンを呼び出してよい。フローはウェブサービスとして展開されるから、それらのフローは他のフローによって呼び出され得る。状態エンジンは、状態機械モデルに基づいてビジネスオブジェクトライフサイクルを管理する。状態エンジンは、実行時に、ビジネスオブジェクトインスタンスの状態データおよびユーザ定義データを制御する。それらのデータは、状態エンジンの外部では更新され得ない。状態機械モデルは、正規の状態、状態間の遷移、およびビジネスオブジェクトの遷移に関連づけられた操作を定義する。実行時において、状態機械の新しいインスタンスは、作成要求が受け取られた場合モデルに従って作り出される。状態機械インスタンス上の遷移の要求が受け取られた場合、状態エンジンは、最初に、要求された遷移が動作可能であるかを検証する。もし動作可能であれば、状態データは、それに従って更新され、関連の操作、例えばユーザデータの更新またはウェブサービスの呼び出しが実行される。状態エンジンは、全ての状態機械モデルについて単一のウェブサービスインタフェースを有する。規則エンジンは複雑なビジネス規則を評価し、可能性として、どのような規則が真へ評価されるかに依存して幾つかの動作を実行することができる。ビジネス規則は宣言型言語、例えばRuleMLで指定される。実行時において、規則エンジンは要求時にデータ集合上の規則集合を評価する。状態エンジンと同じく、規則エンジンは全ての規則評価要求について単一のウェブサービスインタフェースをエキスポートする。642BPIフロー、規則、および状態の間の調整ビジネスプロセスの実行は、フロー、規則、および状態が相互に調整およびインタラクションを行うことを要求する。しかし、フロー、規則、および状態のエンジンは、独立に実行することができる。それらはウェブサービスインタフェースを介して疎結合される。図1は、それらのインタフェース間の論理関係を示す。グラフ内の矢印付き実線は、異なったインタフェース間の呼び出し関係を示し、破線はデータフロー関係を示す。各々のフローは、それ自身の一意のウェブサービスインタフェースを有する。例えば、F1は、インタフェースIフロー1を有し、F2はインタフェースIフロー2を有し、かつF3はインタフェースIフロー3を有する。規則エンジンは単一のインタフェースを有する。R1、R2、およびR3を評価する要求は、全て同じインタフェースを通過する。状態エンジンも単一のインタフェースを有する。全ての状態インスタンス上のクエリーまたは更新は、そのインタフェースを介して要求される。フローの実行中に、規則の評価を行うため規則エンジンを呼び出し、状態の遷移およびデータの更新を行うため状態エンジンを呼び出すことができる。規則エンジンは、幾つかの規則評価の結果によってトリガされるままに、フローを開始するか、状態エンジンを呼び出すことができる。状態エンジンは、規則エンジンを呼び出すか、もし遷移が成功裏に実行されたのであればフローを開始することができる。三者の相互呼び出し可能性は、図1の矢印L1、L2、L3によって示される。ビジネスオブジェクトデータは状態機械によって保護され、状態機械を介してのみ書き込みまたは更新が可能である。この保証は、データが正当な状態に維持され、正当な遷移によってのみ変更され得ることを保証する。フローおよび規則は、保護されていないデータ上で動作することができ、保護されたデータ上では読み出し専用動作を実行することができる。任意に、パフォーマンスを改善するため、保護されたデータを読み出し専用データ記憶装置へ複製することができる。643BPIの管理BPIがユビキタス計算環境で展開されるにつれて、BPIの管理が不可欠となる。BPI管理はレジストリ、ディスカバリ、モニタ、サービス水準合意SLA管理、および違反が生じた場合のSLA自立履行管理BPIおよびエンドポイント解決から構成される。以下のセクションは、これら局面の各々を詳細に説明する。図9は、BPI管理の図式表現を提供する。ここで注意すべき点は、BPIの管理がビジネスプロセスであり、管理BPIと呼ばれるBPIを使用することによって自動化されることである。6431BPIレジストリ:BPIレジストリは3つの部分から構成される。第1はBPIのエンドポイント論理的または物理的であり、第2はSLA合意であり、第3は分類法である。この情報を記憶するため、中央または連合レジストリが必要である。BPIの意味論は次のとおりである。即ち、BPIの各々およびその成分フロー、規則、および状態は抽象的インタフェースへマップされる。抽象的インタフェースの各々は、実行時エンドポイントの一つまたは複数のインスタンスを有する。実行時インスタンスの各々は、様々なSLA、構成、および分類法が定義されるインスタンスデータを有する。任意の永続的記憶装置をBPIレジストリとして使用することができる。以下のパラグラフは、UDDIをBPIレジストリとしてどのように使用できるかを説明する。6432UDDIを使用するBPIレジストリ:BPIの各々およびその成分は、UDDItモデルへマップされる。BPIおよびその成分の記述は、UDDI概説文書へマップされる。SLA合意、構成、および分類法は、UDDIインスタンスデータへマップされる。BPI分類法は、UDDI分類法へマップされる。6433BPIディスカバリBPIが、レジストリ前述したに記憶された構成に基づいて展開された後、展開とレジストリが同期しないリスクが常に存在する。なぜなら、それらは切り離される性質を有するからである。この問題はは、BPIエンドポイントへのトラフィックをモニタし、レジストリを同期するか、環境で実行しているルージュBPIを識別する能力をBPIアドミニストレータへフィードバックすることによって解決される。6434BPIモニタBPIエンドポイントはSOAPエンドポイントであるから、メッセージはSLAの様々な特性についてリアルタイムまたは近リアルタイムでモニタされるパフォーマンスを理由として。違反が起こった場合、モニタリングエージェントは、適切な動作を取るように管理BPIに通知する。6435管理BPI管理BPIは、SLA違反前述したを受け取ってSLA履行の決定を行う特殊BPIである。最も単純な例を挙げると、特定のフローサービスが能力の80に達した場合、BPIモニタは管理BPIに通知し、管理BPIはBPIレジストリの中の構成を調整して、最初のフローサービスがSLAを維持できるまで、フローサービスへの後続の呼び出しが、エンドポイント解決サービスを使用して異なったエンドポイントへ回送されるようにする。管理BPIは、更に、SLA許容および維持管理を提供して、動揺に基づくフィードバックを回避する。6436エンドポイント解決サービスBPI実行時に、全てのBPI成分は、エンドポイントを必要とする場合、インタフェース、SLA、および分類に基づいてBPIレジストリに質問し、呼び出される必要があるエンドポイントを取得する。これは、エンドポイントのダイナミックディスカバリを提供し、SLAを履行するため管理BPIによって実行される構成調整に基づいてBPI呼び出しを再回送する能力を提供する。65ビジネスプロセスワークフローの正しさワークフローが開始した場合ワークフローの事前条件が真であると仮定して、もしワークフロー要件の事後条件がワークフロー仕様によって真であると主張されるならば、ワークフローは所与の要件に従って正しい。タスクの意味論およびワークフローコンストラクタの推論規則に基づいて、コンパイル時にワークフローの正しさを検証することができる。651ワークフローを自動的に注釈するもしワークフローの事前条件が与えられると、各々のタスクの事前および事後条件が与えられたと仮定して、全ての実行ポイントで、そのポイントで何が真であるべきかについて、ワークフローを自動的に注釈することができる。自動注釈のアルゴリズムは2つのパラメータを取る。即ち、ワークフローWおよびワークフローの事前条件P、およびWの注釈バージョンである出力Wである。アルゴリズム:自動注釈W1もしWがタスクP1T1Q1であれば、タスク規則を適用する。2もしWがコンストラクタWCONで構成されていれば、対応するコンストラクタ規則を適用し、繰り返してT1、T2、を注釈する。652ワークフローの正しさを自動的に検証する最初に、ワークフローを注釈する。次に、もしアサーションが次ぎのタスクの事前条件を暗黙に意味していなければ、そのポイントでエラーが存在する。次のタスクの事前条件が満足されないので、ワークフローは誤っており、したがってそのポイントで開始され得ない。もし最後のアサーションがワークフローの事後条件を暗黙に意味しなければ、ワークフローは事前に定義された事後条件を満足させないから、ワークフローは誤っている。66ビジネスプロセスのモデルチェックモデルチェックは、システム実装が、その要件仕様を満足させるかどうかを形式的に検証する。企業および大学は、様々なソフトウェアおよびハードウェアシステムのモデルチェック方法論および自動検証ツールを開発してきた。しかし、ビジネスプロセスおよびアプリケーションに適用されるものは非常に少ない。なぜなら、それらが複雑で形式的仕様を欠如しているためである。BPIはビジネスプロセスを抽象化し、それをフロー、規則、および状態として形式的に記述する方法を提供する。フローおよび状態仕様の正しさは、モデルチェック手法を使用して検証され得る。これに基づいて、BPIフレームワークは、ビジネスプロセスの正しさをモデルチェックするアプローチを提案する。BPIモデルチェックツールは、フローおよび状態仕様をシステム実装として取り、それらを、オリジナルのビジネス要件から自動的に引き出されたシステム要件仕様の集合に対してチェックする。それは、設計時および実行時の双方で、正しさを補強するために使用され得る。モデルチェックは、次の局面で意味論に基づく検証とは異なる。第1に、モデルチェックは観察的トレース意味論、即ち可能なプロセス実行における観察可能状態シーケンスに基づく。しかし、意味論に基づく検証は、活動およびフローの形式的意味論に基づく。第2に、前者は、時間的特性、例えば、AはBの前に起こらなければならない、Aは最終的に起こるだろう、デッドロックは存在しない、などを検証するために使用され得る。しかし、後者は、そのような特性を検証するためには使用され得ない。第3に、前者はシステム実行の全体の状態空間を探求する必要があるが、後者はシステム仕様上の形式演繹法に基づく。BPIモデルチェックツールは、次の目的を達成する助けとなる。即ち、設計時の正しさのチェック、実行時の正しさの補強、およびセキュリティ確保である。セキュリティは分散環境で特に重要である。モデルチェックの観点からは、セキュリティ問題は、言語ベース手法によって処理され得る信頼性問題のサブセットである。本発明者らのモデルチェックツールは、情報フローのセキュリティ方針を保護し、したがって機密性を保証する。661モデルチェックのアプローチ本発明者らのモデルチェックアプローチは、抽象的状態機械モデルに基づいている。仕様は、最初に抽象的状態機械モデルへ変換され、次にモデルチェックされる。方法論は図10に要約される。662設計時のモデルチェック第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を発見する。dEi1Fi合併Eiとし、ii1として、次の反復へ進む。最弱事前条件誘導抽象化は、次のように要約される。1具体的モデルへ要件述語を適用する。2ステップ1の述語に基づいて各々の状態の最弱事前条件を逆方向に計算する。3全ての述語が計算された具体的モデルを抽象化する。4抽象的モデルをモデルチェックし、もし答えがイエスであれば、終了する。5もし答えがノーであれば、抽象化を修正し、モデルチェックを再実行する。663実行時のモニタリング実行時のモニタリングは、実行しているプロセスの正しさを保証する。プロセスは設計時に検証されが、実行時モニタリングが依然として必要である。その理由は、a幾つかの特性が、抽象化のために設計時に検証可能でないかもしれず、b幾つかの活動が、望ましくない実行時特性であってインタフェースで指定されない特性を有するかもしれず、c多くのパフォーマンスおよびセキュリティ方針が実行時に保証されなければならないからである。実行時モニタは、時間的述語として形式的に定義された安全特性要件に基づいて自動的に組み立てられる。モニタは、実行時に、モニタされるシステムと並列に実行し、安全特性の任意の違反を検出する。一度、違反が検出されると、モニタは現在のプロセス実行を中断し、誤り処理手順を開始する。セキュリティは、言語ベースの手法によって確保される。仕様の中の各々のデータ項目は、セキュリティレベルを示すセキュアタイプのタグ、例えば高または低に関連づけられる。各々のプログラムブロックはセキュリティコンテキストに関連づけらる。モデルチェッカはタイプ推論分析を実行して、情報フローがブロックおよびデータ項目のタグ値と整合するかを確かめる。例えば、低とタグされたデータ項目への全ての割り当ては、低値から引き出されるか、低コンテキストの中で起こる。67ビジネスワークフローの自動的合成ワークフロー要件は、ワークフローの事前条件および期待事後条件を指定する。正しいワークフロー仕様は、もし存在すれば、所与のタスクライブラリの意味論に基づいて見出される望みがある。問題は、もしタスクライブラリおよびワークフロー要件が与えられると、正しいワークフロー仕様が自動的に生成されることである。問題を例示するため、図5で説明されたタスクライブラリが存在すると仮定する。タスクは、コーポレート動作ワークフローを構築するために使用されるコンポーネントである。タスクを任意的に接続できないことは容易に分かる。なぜなら、1つのタスクの事後条件は、他のタスクの事前条件を満足させないかもしれないからである。ワークフロー構成体を使用し、どのようにしてタスクを正しく接続するかの基本的規則の集合が存在する。シーケンス:タスクまたはワークフローAの事後条件が、タスクまたはワークフローBの事前条件を暗黙に意味すると仮定すると、AおよびBはシーケンス構造として構成され得る。例は図6で示される。分岐:もしタスクAの出力がタスクBの事前条件を部分的にのみ暗黙に意味するならば、Aからの幾つかの出力ケースは、AおよびBのシーケンスを単純に形成することによっては処理されない。処理されないAからの出力は、懸垂エッジと呼ばれる。もし懸垂エッジの条件が他のタスクの事前条件を暗黙に意味するならば、異なったタスクによって異なったケースを処理するように分岐を形成する必要がある。もしAからの全ての可能なケースをカバーするようなタスクの集合を見出すことができれば、正しい分岐構成体を形成することができる。例は図7で示される。ループ:時には、パス上の幾つかのタスクへ懸垂エッジをフィードバックし、ループを形成することによって、懸垂エッジを固定することができる。これは、条件が満足されるまでループ内でサブワークフローを再試行することを意味する。例は図8で示される。例外:例外は特殊出力エッジである。したがってそれらは分岐と同じ方法で処理され得る。唯一の差異は、多くの場合、ワークフローが或るエラー状態にあり、エラーハンドラによって別個に処理されなければならないことを、例外が暗黙に意味することである。更に、同じ例外が異なったタスクによって生成されるかもしれず、それら例外のグループに対して単一のハンドラを使用することができる。ブロック内の例外を処理するため、分岐を作り出す代わりにキャッチステートメントが作り出される。サブフロー:より大きなワークフローを形成するため、合成されたワークフローをコンポーネントとして使用することができる。構築規則に基づいて、全ての可能なワークフローをタスクライブラリから構築することができる。しかし、数は天文学的になり、それらの全てがビジネス目的を満足させるわけではない。所与のビジネス目的を満足させる正しいワークフローを見つけるため、アルゴリズムが必要である。ビジネス目的は、ワークフローの事前条件および事後条件に関して指定される。ワークフローが開始した場合事前条件が真であると仮定すれば、ワークフローが終了した場合事後条件が真になるように、ワークフローを生成する必要がある。問題を扱いやすくするため、問題の特殊ケースのアルゴリズムが最初に構築され、特殊ケースに基づいて、より一般的なアルゴリズムが作り上げられる。ケース1:タスクは事前条件で肯定的述語のみを有し、事後条件で単一の出力を有する。タスクライブラリは、次の仮定を満足させる。1タスク事前条件は、肯定的述語の合接である。2変数割り当てまたは変数上の条件は許されない。3タスクライブラリは、順位づけの仮定に従う下記を参照4最初、全ての述語の値は真か偽である。ワークフロージェネレータによって実際の値を仮定することはできない。生成されたワークフローは、全ての可能なケースで正しく働かなければならない。ワークフローの事前条件は与えられない。順位づけ:述語の集合PSの上で部分的順序関係0であるか、双方の組み合わせである。a事後条件の中の述語は、genの形式であってよい。もしタスクの事後条件がgenを有するならば、genは一次出力でなければならず、そのタスクの唯一の一次出力でなければならない。b変数xは、ワークフローが開始する場合割り当てられない。即ち、最初はgen偽である。cgenおよびx上の条件は同じ順位を有する。パス:パスはタスクのシーケンスである。可能性として、タスクの幾つかの前に変数上の条件が存在する。もし最初のタスクの事前条件が満足されると、タスクが開始した場合タスクに先行する条件が真であると仮定して、パスの中のタスクは逐次の順序で正しく実行される。Pathは、最後のタスクの一次出力したがって、パスの一次出力としてのpを有するパスである。もしパス上に条件が存在しないならば、パスは完全パスである。そうでなければ、パスは不完全パスである。パスに沿った全ての条件の合接は、パスの条件である。仮定を満足させるタスクライブラリが与えられるならば、各々の述語pについて、少なくとも1つのパスPathが存在する。Pathは不完全であることができる。genを生成するタスクは、パスの中でせいぜい1回現れるだけでよい。タスクライブラリの中の全ての変数Xx1x2xnについて、変数順位の部分的順序を保つ全順序へgengenをソートすることができる。もしパスに沿った条件CC\1dotsCを有するpを実現する不完全パスが存在すれば、各々の変数をせいぜい1回生成するpを実現する不完全パスが存在し、パスにおける条件の同じ集合が所与の全順序で注釈される。各々の変数xiについて、それを生成する1つだけのタスクが必要である。属性閉包アルゴリズム:各々の対等な集合のために、変数の順序に従って不完全パスを見つけるだけでよい。これは、閉包アルゴリズムへ次の規則を追加することによって達成される。アルゴリズム:属性閉包を作り上げることによって、全ての不完全パスを構築する。アルゴリズム:閉包からワークフローを構築する。ケース3:事後条件における複数の一次出力追加の仮定:タスクは複数の出力を有することができ、その各々は前のセクションで指定されたように述語の合接である。もしタスクTが複数の出力を有すれば、各々の出力は1つだけの一次述語を有する。更に、もしpipjがTの出力の一次述語であれば、RankはRankよりも高くなく、または低くない。ケース4:複数の出力および否定を許可する順位の定義を拡張する:a述語は、前のセクションと同じように部分的順序で配列することができ、順位の概念は述語の否定へ拡張される。bRankRankcRankRankpノットq→pノットq述語およびその否定は同じ順位を有し、それは2つのリテラルが同じ順位を有する唯一の場合である。モデルは、事前条件における或る制限否定形式および複数出力を許可するように拡張される。68BPIフレームワーク型アプリケーション可能な例であるが、これらに限定されるわけではないBPIフレームワークは、広範囲のビジネスプロセスの自動化で使用可能である。ビジネスプロセスの自動化は次のファイナンシャルサービスワークフローを含むが、それに限定されるわけではない。681コーポレート動作管理保管財産管理組織におけるコーポレート動作ビジネスプロセスの管理は、ビジネスフロー、規則、および状態管理の複雑な組み合わせを必要とする。コーポレート動作ワークフローは、独立モジュールとしての7つのステージ、例えばデータの捕捉、事象の証明、権利の付与、通知、意思決定、請求書の転記、および決済を含む。それはBPIフレームワーク上で展開され、データモデルおよび外部システムとのインタフェースについて企業標準、例えばMDDL、SWIFTMT5645を使用する。682市場データ、ポートフォリオ、および遵守アプリケーションと発注管理システムとの統合伝統的発注管理システムは、他のファイナンシャルシステム、例えば市場データ、ポートフォリオ、および遵守アプリケーションへ良好に統合されない、BPIフレームワークは、統合ワークフローを自動化する適切な方法を提供する。683データ管理システムファイナンシャルデータの正確なリポジトリ多くの場合、ゴールドコピーとして知られるを作り出すことは、複雑な自動化および人間のワークフローを必要とする。伝統的に、これらのビジネスワークフローおよび規則は、特注プログラムとして実現される。その場合、市場の要求に基づいてビジネス論理を変更する能力は、費用のかかる遅いプロセスである。BPIフレームワークは、これらのビジネスプロセスを自動化する方法を提供する。この場合、システムの残りへ大きなインパクトを与えることなく、要求に従ってビジネス規則を変更することができる。7スキーマおよび例示的インスタンス71スキーマ1:BPDLスキーマ72交渉プロセスの具体的データモデルのXMLスキーマ仕様73交渉データモデルのインスタンス74高レベルデータモデルの例本発明の局面が本発明の例示的態様に関して説明された。当業者は、この開示のレビューから、添付された特許請求の範囲および精神内の多数の他の態様、修正、および変形を思いつくと考えられる。TOCビジネスプロセスの自動化11発明の分野12発明の背景13要約34図面の簡単な説明55詳細な説明651フロー、規則、および状態FRSへのビジネスプロセスの分解852BPDおよび成分フロー、規則、および状態の分類法1353BPIの宣言型仕様13532動作の意味論21533ワークフロー内の異なった点におけるアサーション3254BPI実行フレームワーク32541フロー、規則、および状態エンジン32542BPIフロー、規則、および状態の間の調整33543BPIの管理3455ビジネスプロセスワークフローの正しさ36551ワークフローを自動的に注釈する36552ワークフローの正しさを自動的に検証する3756ビジネスプロセスのモデルチェック37561モデルチェックのアプローチ38562設計時のモデルチェック38563実行時のモニタリング4057ビジネスワークフローの自動的合成4058BPIフレームワーク型アプリケーション可能な例であるが、これらに限定されるわけではない45581コーポレート動作管理45582市場データ、ポートフォリオ、および遵守アプリケーションとの発注管理システムの統合45583データ管理システム456スキーマおよび例示的インスタンス4761スキーマ1:BPDLスキーマ4762交渉プロセスの具体的データモデルのXMLスキーマ仕様4963交渉データモデルのインスタンス5064高レベルデータモデルの例517特許請求の範囲529発明の背景ビジネス機能を自動化するプロセスおよびシステムが説明される。