JP2004258823A - ビジネスプロセス処理方法およびシステム並びにその処理プログラム - Google Patents
ビジネスプロセス処理方法およびシステム並びにその処理プログラム Download PDFInfo
- Publication number
- JP2004258823A JP2004258823A JP2003046684A JP2003046684A JP2004258823A JP 2004258823 A JP2004258823 A JP 2004258823A JP 2003046684 A JP2003046684 A JP 2003046684A JP 2003046684 A JP2003046684 A JP 2003046684A JP 2004258823 A JP2004258823 A JP 2004258823A
- Authority
- JP
- Japan
- Prior art keywords
- business process
- message
- next step
- definition
- line
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
- G06Q10/103—Workflow collaboration or project management
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Strategic Management (AREA)
- Human Resources & Organizations (AREA)
- Entrepreneurship & Innovation (AREA)
- Operations Research (AREA)
- Economics (AREA)
- Marketing (AREA)
- Data Mining & Analysis (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
【課題】本発明は、ネットワーク環境におけるビジネスプロセスの管理方法に関わるもので、従来は特別の制御用計算機ノードを用意して管理したが、集中型となるため管理負荷が高く、ビジネスも対等の関係で実現できない、ビジネスプロセス全体の内容を理解せずに処理せざるを得ない、という問題があった。
【解決手段】上記課題を解決するため、ビジネスプロセスの定義を標準のＸＭＬ言語を用いて記述し、これをビジネスプロセスの各ステップを実行する計算機ノードにそのステップで必要となる情報と併せて渡すことで、ビジネスプロセスを実行する計算機が対等な関係で、なおかつビジネスプロセスの全体像を把握した上で、ビジネスプロセスを実行出来るようにする。ビジネスプロセスの実行状況については監視ノードを設け、各ステップ終了報告を送信することでモニタリングも実現する。
【選択図】 図１
【解決手段】上記課題を解決するため、ビジネスプロセスの定義を標準のＸＭＬ言語を用いて記述し、これをビジネスプロセスの各ステップを実行する計算機ノードにそのステップで必要となる情報と併せて渡すことで、ビジネスプロセスを実行する計算機が対等な関係で、なおかつビジネスプロセスの全体像を把握した上で、ビジネスプロセスを実行出来るようにする。ビジネスプロセスの実行状況については監視ノードを設け、各ステップ終了報告を送信することでモニタリングも実現する。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明はワークフローやビジネスプロセスの処理技術に関する
【０００２】
【従来の技術】
従来ワークフローの標準化やこれを実現した各種プロダクトにみられるように、ビジネスプロセスの制御はワークフロー技術の応用として実現されてきた。この方法では、まず利用者がビジネスプロセスを定義し、ワークフローエンジンと呼ばれるソフトウェアコンポーネントがこの定義に基づき個々のステップの遂行責任を持つソフトウェアや人に対し遠隔手続き呼び出し（ＲＰＣ）やメッセージ送信などの通信手段を用い、ビジネスプロセス定義に従い順次起動ないし作業依頼することでビジネスプロセスの実行と進行状況監視を行っていた。
【０００３】
また、ビジネスプロセス定義の分野ではＸＭＬ言語を用いた記述方法の標準化が議論されていることが知られている。これらは記述のための文法規則であり、記述された定義文書の使い方について規定するものではない。
【０００４】
更に、特開平９−２６５４０８号公報で開示されているような技術では、ワークフローの分散実行という意味で類似の領域を狙ったものであり、▲１▼ビジネスプロセスの自動化というより文書ベースのワークフローの自動化であること、及び▲２▼送信されるワークフロー定義にはフロー情報のほかにプログラムが含まれ各ノードで実行されることを前提にしていること、が特徴であり、本特許の請求項としている、ＸＭＬ「文書」引渡しによる人間の操作を前提としない「ビジネスプロセス」実行の実現、ステップ実行主体の動的発見、文書情報やメッセージ情報の参照による転送、ビジネスプロセス進捗状況モニタリングのための監視ノードの設定、など各種の点において異なるもの（対象領域、技術要素）である。
【０００５】
【特許文献１】
特開平９−２６５４０８号
【０００６】
【発明が解決しようとする課題】
ワークフローエンジンという制御コンポーネントにより集中制御や管理を行うため、その集中制御・管理専用の信頼性の高いソフトウェアやハードウェアが必要であった。
【０００７】
更に、企業の境界をまたがるようなビジネスプロセスではマスタ・スレーブという関係はなじまなず、各企業システムが対等な関係で連携しビジネスプロセスを実現出来るようにすることが求められていた。
【０００８】
また、ステップを実行する主体はその実行に必要最低限の情報だけを与えて処理を行う仕組みとなっていたため、その実行主体にとって当該処理を行うことがビジネス面から妥当か否かといった判断を行う情報が十分に与えられていなかった。
【０００９】
本発明の目的は、分散処理環境におけるビジネスプロセスの実行を分散型で実現することにある。
【００１０】
【課題を解決するための手段】
上記課題を改善するために、文書記述言語を用いて記述したビジネスプロセス定義とビジネスプロセス実行に必要な情報をメッセージ送信という機能を用いステップ間で順次渡して行くという手段を用意する。これにより、制御ノードを必要とせず、参加計算機ノードが対等な立場で、更にビジネスプロセスとしてのコンテキストを理解した上で各ステップ処理を遂行出来るようになる。
【００１１】
一方、ビジネスプロセス処理の進行状況のモニタリング用に監視ノードを用意し、ステップ処理終了時点の結果通知を受けられるようにする。これを用意することで、進行状況のモニタリングだけでなく、ステップでの処理が不成功となった場合に適切な動作を取らせることが可能となる。
【００１２】
【発明の実施の形態】
以下、本発明の実施例を図面に基づいて説明する。図１は本発明における一実施例の構成を示すものである。本実施例では、ネットワーク８で接続された七つの計算機ノードを示しており、ビジネスプロセス起動ノード１がビジネスプロセスを起動する。このビジネスプロセスで最初に行うステップは布地購入ステップで、ビジネスプロセス起動ノード１は布地購入ステップ実行ノード４に図２から図６に例を示したビジネスプロセス定義文書と、図７に示すメッセージを送信する。布地購入ステップの実行終了後、図７のビジネスプロセス定義文書にある条件に従って、衣料品の製造ステップ実行ノード５または衣料品以外の製造ステップ実行ノード６のいずれかに、図２から図６に例を示したビジネスプロセス定義文書と図７のような必要な情報を含むメッセージを送信する。なおメッセージ形式は各ステップ実行ノードが公開している形式に従うものとする。これらのステップでの処理が終了すると、衣料品の製造ステップ実行ノード５または衣料品以外の製造ステップ実行ノード６のいずれかから、パッケージステップ実行ノード７に、図２から図６に例を示したビジネスプロセス定義文書と図７のような必要な情報を含むメッセージを送信する。パッケージステップ実行ノードでの処理が正常に終了すると、ビジネスプロセスが完了し、ビジネスプロセス終了報告ノードに報告を送信する。
【００１３】
ビジネスプロセスの進行状況のモニターを可能にするため、各ステップでの処理が正常に終了した時点でビジネスプロセス監視ノード２に通知メッセージを送信するものとする。ステップでの処理に問題があった場合は、ビジネスプロセス監視ノード２が、それまで正常終了の報告をあげてきた各ステップ実行ノードに対して補償動作指示などの適切な動作を実施する。
【００１４】
ここで、ビジネスプロセス起動ノード１、ビジネスプロセス監視ノード２、ビジネスプロセス終了報告ノード３の三つのノードは、同じ計算機であっても構わないし、別々の計算機としても構わない。
【００１５】
なお、ビジネスプロセス定義文書を直接メッセージの一部として送信するのではなく、ネットワーク上のアクセス可能な場所に置き、ＵＲＬのようなアクセス方法と位置情報を参照という形でメッセージに含めて送信しても良い。
【００１６】
図２〜図６は本ビジネスプロセスをＸＭＬ文書として定義した例である。本発明はＸＭＬ言語での記述例を示しているが、ＸＭＬに限定されるものではない。構造的に記載可能なデータ構造であれば適用可能である。プログラム間で通信するメッセージを文書という表現をしているが、メッセージや要求（リクエスト）でも実現可能である。図２は文書構造であり、ビジネスプロセスは説明、属性、責任システム、ビジネスプロセス・インバリアント、ビジネスプロセス事前条件、報告先、ステップ定義、ビジネスプロセス事後条件から構成されることを示す。また、その内部に複数のステップを定義することが出来る。またステップは、インバリアント、事前条件、シグニチャ、事後条件、次のステップという要素から構成されることを示している。図３以降がビジネスプロセスの定義実体の例である。
【００１７】
図７はビジネスプロセス定義文書と共に各ステップに送られるメッセージの例である。宛先によりステップを遂行する計算機とアプリケーションが指定され、ビジネスプロセスＩＤ、ステップＩＤにより、どのビジネスプロセスのどのステップの処理を行うのかを指示している。それ以降のデータはステップ実行に必要となるパラメタである。
安全性の観点からメッセージ自体をＰＫＩ等を用い暗号化することもある。
【００１８】
図８はビジネスプロセスの実行に参加する各計算機ノードにおける処理の流れの例を示したものである。９でメッセージを受信し、そのメッセージ中にビジネス定義文書が含まれていればそれを１０で取り出し、含まれていない場合には１１のようにＵＲＬ情報をもとにネットワーク経由で取り出し、１２でメッセージに含まれるパラメタ情報と併せて解析を行う。この結果に基づき、１３でビジネスプロセス定義のなかで遂行を求められているステップを発見し、処理に必要な入力情報であるシグニチャを１４で作り上げ、１５で処理の実行を行う。その結果は１６で監視ノードへ報告し、ステップ定義に含まれる条件により、１７で次に行われるべきステップを確定する。最後に１８で次のステップに渡すべきメッセージを組立て、１７で確定したステップ実行計算機ノードに宛てこれを送信する。
【００１９】
図９はこれらビジネスプロセス処理方法を実現する装置の構造例を示したものである。１９はビジネスプロセス利用者システム例であり、ディスプレイ２０、入力装置２１、ＣＰＵ２２を備えている。この装置でビジネスプロセス定義編集プログラムとＷｅｂサービスクライアントプログラム２３を動作させることで、１９の利用者はビジネスプロセス定義文書を作成するとともに、３１で示すビジネスプロセスステップ実行装置にその処理実行の依頼を行う。２４はビジネスプロセス監視装置の構成例であり、ディスプレイ２５、入力装置２６、ＣＰＵ２７を備えている。この装置でビジネスプロセス進捗管理Ｗｅｂサービスプログラム２８を動作させることで、３１で示すビジネスプロセスステップ実行装置から実行結果を随時受信し、１９のビジネスプロセス利用者システムなどから進捗状況の把握が可能となる。また、実行できなかったという結果を受け取った場合、ビジネスプロセス利用者から得た取るべき動作のテーブルなどをＤＢ２９に保管し、対応するエントリを読み出すことで動作指示を出すことができる。３１はビジネスプロセスステップ実行装置の構成例であり、ディスプレイ３２、入力装置３３、ＣＰＵ３４を備えている。この装置でビジネスプロセスステップ処理Ｗｅｂサービスプログラム３５を動作させることで、ビジネスプロセス定義に現れる各ステップの処理を実行することができる。１９、２４、３１の各装置はネットワーク３０で接続されており、オープンな通信が出来るものとしている。
【００２０】
図１０は本ビジネスプロセス処理方法とビジネスプロセス処理装置を使い、ビジネスプロセスの進捗状況監視と必要に応じ補償動作を起動するなどの対応を代行するというビジネスの方法例を示したものである。３６のビジネスプロセス利用者は、ビジネスプロセスの定義を行い、その実行を３７のビジネスプロセス処理サービス提供者に依頼する。ビジネスプロセス処理サービス提供者は依頼者に替わり、ビジネスプロセスの始めのステップを実行するステップ実行装置３８に対し、ビジネスプロセス定義文書とステップ処理に必要なパラメタ情報をメッセージとして送信する。３８はステップ処理後、図１に対する説明で述べたような方法で、３９や４０のステップ実行装置にメッセージを送信する。このとき、各ステップ処理終了後に処理終了や処理不可といった結果情報を３７に送信するが、処理不可の場合には、３７から補償行為に相当する別のビジネスプロセスが流されることもある。３７は利用者に対してビジネスプロセスの管理というサービスを提供することで対価を得る。
【００２１】
以下、例を用い本発明を実現した場合のプログラムの動作を説明する。
【００２２】
１ ビジネスプロセス開始プログラムの動作
１．１ 前提
１）ビジネスプロセス定義（ＸＭＬ文書）はビジネスプロセス開始プログラム実行前に以下のいずれかの形態で作成されているものとする。
【００２３】
すべての値が入った定義文書（例：サービス実行者名や渡すパラメタ値全て）−これはビジネスプロセスの実行者、パラメタ等を全て固定にし、途中で変更を許さないもの。この場合には、変更が行われなかったことを証明するための機構（例えば暗号化やデジタル署名）を併用することを想定する。
【００２４】
部分的にパラメタ化された定義文書（例：サービス実行者に渡す各種情報をパラメタ化したもの）―これはステップ実行結果をビジネスプロセス定義の一部として次のステップに渡す場合などを想定。
【００２５】
すべての変数要素をパラメタ化し、テンプレートとしての利用を目的とした定義文書（例：典型的な購買プロセス）−これはビジネスプロセス定義のテンプレートのライブラリやリポジトリがあり、そこからベースとなるテンプレートを検索し、カスタマイズし利用する。
【００２６】
２）上記ビジネスプロセス定義は、▲１▼ビジネスプロセス開始プログラムへの入力データ、または、▲２▼ビジネスプロセス定義リポジトリ（ＤＢ）から読み出して自らの用途用にパラメタ設定、という形態で利用する
１．２ 例に基づく処理ロジックの説明
１）ビジネスプロセスＸＭＬ定義文書の読み込みを行う
２）同文書の構文解析を行う
３）＜説明＞を画面に出力する（図３の２行目に対応し「本ビジネスプロセスは布地を購入し衣料品等を製造販売するもの」というメッセージをディスプレイに表示）
４）＜属性＞がビジネストランザクションであることをチェックする（図３の３行目「ビジネストランザクション」に対応）
５）＜責任システム＞が本ビジネスプロセス実行を開始するシステム名と一致することをチェックする（図３の４行目「ＡＢＣ製作所．ｃｏｍ／ＢＰ」に対応）
６）＜ビジネスプロセスインバリアント＞として＜ビジネスプロセスＩＤ＞が含まれていることをチェックする（図３の５から７行目「ＸＹＺ１２３４７７」に対応）
７）＜ビジネスプロセスＩＤ＞が設定されている場合はこれを本ビジネスプロセスのＩＤとして保存する（設定されていない場合には、ビジネスプロセス開始プログラムが一意な値を生成し設定）
８）＜ビジネスプロセス事前条件＞の＜布地ストック＞の値（１００）と現実のストック数（開始プログラムが情報ベースより読み出す）を比較し、現実のストック数が１００以下であることをチェックする（図３の８から１０行目「１００」に対応）
９）＜報告先＞が設定されている場合にはこれを本ビジネスプロセスでの報告先として保存する（設定されていない場合には、ここに責任システムのアドレスを設定）（図３の１１行目「ｘｘｘ．ｙｙｙ．ｃｏｍ／ＲｅｐｏｒｔＨａｎｄｌｅｒ」に対応）
１０）＜ステップ定義＞が存在することをチェックする（図３の１２行目に対応）
１１）最初に現れる＜ステップ＞の属性である識別子（サービス名）を保存する（図３の１３行目及び図７の１８行目「布地購入」に対応）
１２）保存した識別子に基づきステップ実行者を選定する
・ネームサービスによる選定（識別子が具体的なシステム名の場合）
・ＵＤＤＩによる選定（識別子がサービス名の場合、ＵＤＤＩでサービスを検索し、判断基準にあうサービス提供者を選定）
１３）ステップ実行者に渡すパラメタの準備を行う
＜インバリアント＞が＜日数＞の場合、ビジネスプロセス定義と共に送付するメッセージに＜日数＞の具体的な値を＜Ｄａｙｓ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図３の１４−１６行目に対応した図７の１９行目「７」）
＜オーダＩＤ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダＩＤ＞の具体的な値を＜ＯｒｄｅｒＩＤ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図３の２２行目に対応した図７の２０行目「ＡＢＣ０００８９１」）
＜オーダタイプ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダタイプ＞の具体的な値を＜ＯｒｄｅｒＴｙｐｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図３の２３行目に対応した図７の２１行目「木綿布地」）
＜数量＞についても、ビジネスプロセス定義と共に送付するメッセージに＜数量＞の具体的な値を＜Ｑｕａｎｔｉｔｙ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図３の２４行目に対応した図７の２２行目「５００００」）
＜単価＞についても、ビジネスプロセス定義と共に送付するメッセージに＜単価＞の具体的な値を＜Ｐｒｉｃｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図３の２５行目に対応した図７の２３行目「３０００」）
＜発注日付＞についても、ビジネスプロセス定義と共に送付するメッセージに＜発注日付＞の具体的な値を＜Ｄａｔｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図３の２６行目に対応「２００２０７０１」）
１４）選定したサービス提供者に送る以下のメッセージを組立て（図７に主な項目を例示）
・ ヘッダ部分
・ 発信システム名：責任システム名
・ ビジネスプロセスＩＤ：ビジネスプロセスＩＤ
・ 宛先システム名：選定されたサービス提供者名
・ ステップ名：ステップ識別子
・ 監視システム名：報告者名
・ コンテンツ部分
＜Ｄａｙｓ＞、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の（名前、値）リストからなるＸＭＬ文書（これらの元となる＜日数＞、＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞が責任システムにより設定されていない場合）
上記ビジネスプロセス定義ＸＭＬ文書（またはそのＵＲＬ）
１５）選定したサービス提供者へこのメッセージを送信する
１６）監視システムにビジネスプロセス文書を送付し当該ビジネスプロセスがスタートしたことを連絡する
２ 衣料材購入ステップでのプログラムの動作
２．１ 前提
１）メッセージを受信する
２）メッセージを解析し、ヘッダ部分の各情報、コンテンツ部分の各情報を保存する（図７に例示した内容）
３）ヘッダ部分に含まれるステップ名を用い、コンテンツ部分のビジネスプロセス定義から対応するステップを確定する（例では布地購入ステップ）（図３の１３行目の情報を使用）
４）ステップ実行を受け入れることが出来ない場合には、監視ノードにその旨の連絡をする
２．２ 例に基づく処理ロジックの説明
１）＜インバリアント＞の＜日数＞の値（”Ｄａｙｓ”）は、メッセージに＜Ｄａｙｓ＞があるためその値で置き換え保存する（図３の１５行目に対応し、図７の１９行目の値で置き換えることに相当）
２）＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞についても同様に、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の値で置き換え保存する（図３の２２から２６行目及び図７の２０から２４行目に対応）
３）＜事前条件＞の＜コントラクト＞の値（契約済み）が、ステップ実行者と責任システムとの間の契約関係情報（情報ベースから読み出す）と合致していることをチェックする（図３の２１行目「ｘｘｘ．ｙｙｙ．ｃｏｍ／ｃｏｎｔｒａｃｔ．ｄｏｃ」の記述内容に対応）
４）アプリケーション起動の準備を行う
アプリケーション起動時のパラメタとなる＜ＩＮシグニチャ＞情報を設定する（図３の２０から２７行目に対応）
・コントラクト本文：ドキュメントまたはＵＲＬ等を設定する
・オーダＩＤ：＜ＯｒｄｅｒＩＤ＞にあった値を設定する
・オーダタイプ：＜ＯｒｄｅｒＴｙｐｅ＞にあった値を設定する
・数量：＜Ｑｕａｎｔｉｔｙ＞にあった値を設定する
・単価：＜Ｐｒｉｃｅ＞にあった値を設定する
・発注日付：＜Ｄａｔｅ＞にあった値を設定する
５）アプリケーションを起動し、リターン（結果）を得、＜ＯＵＴシグニチャ＞情報を設定する（図３の２８から３２行目に対応）
・成否：アプリケーション処理が正常に処理を終えたか否かを示す（図３の２９行目に対応）
・プロダクトタイプ：アプリケーション処理の結果生まれる製品のタイプ（図３の３０行目に対応）
・荷札ＩＤ：製品を以降のステップに引き渡す時の識別子（図３の３１行目に対応）
６）＜成否＞の値が成功であることを確認：失敗の場合には以降の処理は行わず、失敗報告メッセージを報告者に送信する
７）＜事後条件＞の＜発送済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜発送済＞ステータス（情報ベースより読み出す）と合致していることをチェックする（図３の３４行目に対応）
８）＜事後条件＞の＜支払済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜支払済＞ステータス（情報ベースより読み出す）と合致していることをチェックする（図３の３５行目に対応）
９）次のステップの確定
・アプリケーション起動のリターンにある＜プロダクトタイプ＞の値と＜次のステップの＞の＜条件＞にある＜プロダクトタイプ＞が一致する場合。次の行にある＜ステップＩＤ＞の値が、次のステップＩＤとなる。（図３の３９行目と４３行目が条件で、各々の遷移先が４０行目と４４行目）
・本例では、プロダクトタイプが衣料品用布地であれば衣料品製造というステップへ、プロダクトタイプが非衣料品用布地であれば非衣料品製造というステップへ、各々遷移する、という例である。
【００２７】
１０）上記判定により決まったステップの属性である識別子（サービス名）をビジネスプロセス定義ＸＭＬ文書より読み出す
１１）その識別子に基づきステップ実行者を選定する
・ネームサービスによる選定（識別子が具体的なシステム名の場合）
・ＵＤＤＩによる選定（識別子がサービス名の場合、ＵＤＤＩでサービスを検索し、判断基準にあうサービス提供者を選定）
１２）ステップ実行者に渡すパラメタの準備を行う
＜インバリアント＞が＜日数＞の場合、ビジネスプロセス定義と共に送付するメッセージに＜日数＞の具体的な値を＜Ｄａｙｓ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図４の３行目または図５の３行目に対応した図７の１９行目）
＜オーダＩＤ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダＩＤ＞の具体的な値を＜ＯｒｄｅｒＩＤ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図４の１０行目または図５の１０行目に対応した図７の２０行目）
＜オーダタイプ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダタイプ＞の具体的な値を＜ＯｒｄｅｒＴｙｐｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図４の１１行目または図５の１１行目に対応した図７の２１行目）
＜数量＞についても、ビジネスプロセス定義と共に送付するメッセージに＜数量＞の具体的な値を＜Ｑｕａｎｔｉｔｙ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図４の１２行目または図５の１２行目に対応した図７の２２行目）
＜単価＞についても、ビジネスプロセス定義と共に送付するメッセージに＜単価＞の具体的な値を＜Ｐｒｉｃｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図４の１３行目または図５の１３行目に対応した図７の２３行目）
＜発注日付＞についても、ビジネスプロセス定義と共に送付するメッセージに＜発注日付＞の具体的な値を＜Ｄａｔｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図４の１４行目または図５の１４行目に対応した図７の２４行目）
１３）選定したサービス提供者に送る以下のメッセージを組立て（図７に主な項目を例示）
・ヘッダ部分
・発信システム名：責任システム名
・ビジネスプロセスＩＤ：ビジネスプロセスＩＤ
・宛先システム名：選定されたサービス提供者名
・ステップ名：ステップ識別子
・監視システム名：報告者名
・コンテンツ部分
＜Ｄａｙｓ＞、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の（名前、値）リストからなるＸＭＬ文書（これらの元となる＜日数＞、＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞が責任システムにより設定されていない場合）
・上記ビジネスプロセス定義ＸＭＬ文書（またはそのＵＲＬ）
１４）監視システムに本ビジネスプロセスの衣料材購入ステップが終了したことを連絡した後、選定したサービス提供者へこのメッセージを送信する
３ 衣料品製造ステップ
３．１ 前提
１）メッセージを受信する
２）メッセージを解析し、ヘッダ部分の各情報、コンテンツ部分の各情報を保存する
３）ヘッダ部分に含まれるステップ名を用い、コンテンツ部分のビジネスプロセス定義から対応するステップを確定する（例では衣料品製造ステップ）（図４の１行目「衣料品製造」に対応）
４）必要に応じ、直前のステップが正常に終了していることを、監視ノードに問合せ確認する
５）ステップ実行を受け入れることが出来ない場合には、監視ノードにその旨の連絡をする
３．２ 例に基づく処理ロジックの説明
１）＜インバリアント＞の＜日数＞の値（”Ｄａｙｓ”）は、メッセージに＜Ｄａｙｓ＞があるためその値で置き換え保存する（図４の２−４行目に対応）
２）＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞についても同様に、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の値で置き換え保存する（図４の１０から１４行目に対応）
３）＜事前条件＞の＜コントラクト＞の値（契約済み）が、ステップ実行者と責任システムとの間の契約関係情報（情報ベースから読み出す）と合致していることをチェックする（図４の９行目「ｘｘｘ．ｙｙｙ．ｃｏｍ／ｃｏｎｔｒａｃｔ．ｄｏｃ」の記述内容に対応）
４）アプリケーション起動の準備を行う
・アプリケーション起動時のパラメタとなる＜ＩＮシグニチャ＞情報を設定する（図４の８から１５行目に対応）
・コントラクト本文：ドキュメントまたはＵＲＬ等を設定する
・オーダＩＤ：＜ＯｒｄｅｒＩＤ＞にあった値を設定する
・オーダタイプ：＜ＯｒｄｅｒＴｙｐｅ＞にあった値を設定する
・数量：＜Ｑｕａｎｔｉｔｙ＞にあった値を設定する
・単価：＜Ｐｒｉｃｅ＞にあった値を設定する
・発注日付：＜Ｄａｔｅ＞にあった値を設定する
５）アプリケーションを起動し、リターン（結果）を得、＜ＯＵＴシグニチャ＞情報を設定する（図４の１６から２０行目に対応）
・成否：アプリケーション処理が正常に処理を終えたか否かを示す（図４の１７行目に対応）
・プロダクトタイプ：アプリケーション処理の結果生まれる製品のタイプ（図４の１８行目に対応）
・荷札ＩＤ：製品を以降のステップに引き渡す時の識別子（図４の１９行目に対応）
６）＜成否＞の値が成功であることを確認：失敗の場合には以降の処理は行わず、失敗報告メッセージを報告者に送信する
７）＜事後条件＞の＜発送済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜発送済＞ステータス（情報ベースより読み出す）と合致していることをチェックする（図４の２２行目に対応）
８）＜事後条件＞の＜支払済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜支払済＞ステータス（情報ベースより読み出す）と合致していることをチェックする（図４の２３行目に対応）
９）次のステップの確定
・アプリケーション起動のリターンにある＜プロダクトタイプ＞の値と＜次のステップの＞の＜条件＞にある＜プロダクトタイプ＞が一致する場合。次の行にある＜ステップＩＤ＞の値が、次のステップＩＤとなる。（図４の２７行目が条件で２８行目が遷移先）
・本例では、プロダクトタイプが衣料品であればパッケージというステップへ、遷移する、という例である。
１０）上記判定により決まったステップの属性である識別子（サービス名）をビジネスプロセス定義ＸＭＬ文書より読み出す
１１）その識別子に基づきステップ実行者を選定する
・ネームサービスによる選定（識別子が具体的なシステム名の場合）
・ＵＤＤＩによる選定（識別子がサービス名の場合、ＵＤＤＩでサービスを検索し、判断基準にあうサービス提供者を選定）
１２）ステップ実行者に渡すパラメタの準備を行う
・＜インバリアント＞が＜日数＞の場合、ビジネスプロセス定義と共に送付するメッセージに＜日数＞の具体的な値を＜Ｄａｙｓ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の３行目に対応した図７の１９行目）
・＜オーダＩＤ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダＩＤ＞の具体的な値を＜ＯｒｄｅｒＩＤ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１０行目に対応した図７の２０行目）
・＜オーダタイプ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダタイプ＞の具体的な値を＜ＯｒｄｅｒＴｙｐｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１１行目に対応した図７の２１行目）
・＜数量＞についても、ビジネスプロセス定義と共に送付するメッセージに＜数量＞の具体的な値を＜Ｑｕａｎｔｉｔｙ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１２行目に対応した図７の２２行目）
・＜単価＞についても、ビジネスプロセス定義と共に送付するメッセージに＜単価＞の具体的な値を＜Ｐｒｉｃｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１３行目に対応した図７の２３行目）
＜発注日付＞についても、ビジネスプロセス定義と共に送付するメッセージに＜発注日付＞の具体的な値を＜Ｄａｔｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１４行目に対応した図７の２４行目）
１３）選定したサービス提供者に送る以下のメッセージを組立て（図７に主な項目を例示）
・ヘッダ部分
・発信システム名：責任システム名
・ビジネスプロセスＩＤ：ビジネスプロセスＩＤ
・宛先システム名：選定されたサービス提供者名
・ステップ名：ステップ識別子
・監視システム名：報告者名
・コンテンツ部分
・＜Ｄａｙｓ＞、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の（名前、値）リストからなるＸＭＬ文書（これらの元となる＜日数＞、＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞が責任システムにより設定されていない場合）
・上記ビジネスプロセス定義ＸＭＬ文書（またはそのＵＲＬ）
１４）監視システムに本ビジネスプロセスの衣料材製造ステップが終了したことを連絡した後、選定したサービス提供者へこのメッセージを送信する
４ 非衣料品製造ステップ
４．１ 前提
１）メッセージを受信する
２）メッセージを解析し、ヘッダ部分の各情報、コンテンツ部分の各情報を保存する
３）ヘッダ部分に含まれるステップ名を用い、コンテンツ部分のビジネスプロセス定義から対応するステップを確定する（例では非衣料品製造ステップ）（図５の１行目「非衣料品製造」に対応）
４）必要に応じ、直前のステップが正常に終了していることを、監視ノードに問合せ確認する
５）ステップ実行を受け入れることが出来ない場合には、監視ノードにその旨の連絡をする
４．２ 例に基づく処理ロジックの説明
１）＜インバリアント＞の＜日数＞の値（”Ｄａｙｓ”）は、メッセージに＜Ｄａｙｓ＞があるためその値で置き換え保存する（図５の２から４行目に対応）
２）＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞についても同様に、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の値で置き換え保存する（図５の１０から１４行目に対応）
３）＜事前条件＞の＜コントラクト＞の値（契約済み）が、ステップ実行者と責任システムとの間の契約関係情報（情報ベースから読み出す）と合致していることをチェックする（図５の９行目「ｑｑｑ．ｐｐｐ．ｃｏｍ／ｃｏｎｔｒａｃｔ．ｄｏｃ」の記述内容に対応）
４）アプリケーション起動の準備を行う
・アプリケーション起動時のパラメタとなる＜ＩＮシグニチャ＞情報を設定する（図５の８から１５行目に対応）
・コントラクト本文：ドキュメントまたはＵＲＬ等を設定する
・オーダＩＤ：＜ＯｒｄｅｒＩＤ＞にあった値を設定する
・オーダタイプ：＜ＯｒｄｅｒＴｙｐｅ＞にあった値を設定する
・数量：＜Ｑｕａｎｔｉｔｙ＞にあった値を設定する
・単価：＜Ｐｒｉｃｅ＞にあった値を設定する
・発注日付：＜Ｄａｔｅ＞にあった値を設定する
５）アプリケーションを起動し、リターン（結果）を得、＜ＯＵＴシグニチャ＞情報を設定する（図５の１６から２０行目に対応）
・成否：アプリケーション処理が正常に処理を終えたか否かを示す（図５の１７行目に対応）
・プロダクトタイプ：アプリケーション処理の結果生まれる製品のタイプ（図５の１８行目に対応）
・荷札ＩＤ：製品を以降のステップに引き渡す時の識別子（図５の１９行目に対応）
６）＜成否＞の値が成功であることを確認：失敗の場合には以降の処理は行わず、失敗報告メッセージを報告者に送信する
７）＜事後条件＞の＜発送済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜発送済＞ステータス（情報ベースより読み出す）と合致していることをチェック（図５の２２行目に対応）
８）＜事後条件＞の＜支払済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜支払済＞ステータス（情報ベースより読み出す）と合致していることをチェック（図５の２３行目に対応）
９）次のステップの確定
・アプリケーション起動のリターンにある＜プロダクトタイプ＞の値と＜次のステップの＞の＜条件＞にある＜プロダクトタイプ＞が一致する場合。次の行にある＜ステップＩＤ＞の値が、次のステップＩＤとなる。（図５の２７行目が条件で２８行目が遷移先）
・本例では、プロダクトタイプが非衣料品であればパッケージというステップへ遷移する、という例である。
１０）上記判定により決まったステップの属性である識別子（サービス名）をビジネスプロセス定義ＸＭＬ文書より読み出す
１１）その識別子に基づきステップ実行者を選定する
・ネームサービスによる選定（識別子が具体的なシステム名の場合）
・ＵＤＤＩによる選定（識別子がサービス名の場合、ＵＤＤＩでサービスを検索し、判断基準にあうサービス提供者を選定）
１２）ステップ実行者に渡すパラメタの準備を行う
・＜インバリアント＞が＜日数＞の場合、ビジネスプロセス定義と共に送付するメッセージに＜日数＞の具体的な値を＜Ｄａｙｓ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の３行目に対応した図７の１９行目）
・＜オーダＩＤ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダＩＤ＞の具体的な値を＜ＯｒｄｅｒＩＤ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１０行目に対応した図７の２０行目）
＊ ＜オーダタイプ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダタイプ＞の具体的な値を＜ＯｒｄｅｒＴｙｐｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１１行目に対応した図７の２１行目）
・＜数量＞についても、ビジネスプロセス定義と共に送付するメッセージに＜数量＞の具体的な値を＜Ｑｕａｎｔｉｔｙ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１２行目に対応した図７の２２行目）
・＜単価＞についても、ビジネスプロセス定義と共に送付するメッセージに＜単価＞の具体的な値を＜Ｐｒｉｃｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１３行目に対応した図７の２３行目）
・＜発注日付＞についても、ビジネスプロセス定義と共に送付するメッセージに＜発注日付＞の具体的な値を＜Ｄａｔｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１４行目に対応した図７の２４行目）
１３）選定したサービス提供者に送る以下のメッセージを組立て（図７に主な項目を例示）
・ヘッダ部分
・発信システム名：責任システム名
・ビジネスプロセスＩＤ：ビジネスプロセスＩＤ
・宛先システム名：選定されたサービス提供者名
・ステップ名：ステップ識別子
・監視システム名：報告者名
・コンテンツ部分
・＜Ｄａｙｓ＞、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の（名前、値）リストからなるＸＭＬ文書（これらの元となる＜日数＞、＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞が責任システムにより設定されていない場合）
・上記ビジネスプロセス定義ＸＭＬ文書（またはそのＵＲＬ）
１４）監視システムに本ビジネスプロセスの非衣料材製造ステップが終了したことを連絡した後、選定したサービス提供者へこのメッセージを送信する
５ パッケージステップ
５．１ 前提
１）メッセージを受信する
２）メッセージを解析し、ヘッダ部分の各情報、コンテンツ部分の各情報を保存する
３）ヘッダ部分に含まれるステップ名を用い、コンテンツ部分のビジネスプロセス定義から対応するステップを確定する（例ではパッケージステップ）（図６の１行目「パッケージ」に対応）
４）必要に応じ、直前のステップが正常に終了していることを、監視ノードに問合せ確認する
５）ステップ実行を受け入れることが出来ない場合には、監視ノードにその旨の連絡をする
５．２ 例に基づく処理ロジックの説明
１）＜インバリアント＞の＜日数＞の値（”Ｄａｙｓ”）は、メッセージに＜Ｄａｙｓ＞があるためその値で置き換え保存する（図６の３から５行目に対応）
２）＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞についても同様に、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の値で置き換え保存する（図６の１０から１４行目に対応）
３）＜事前条件＞の＜コントラクト＞の値（契約済み）が、ステップ実行者と責任システムとの間の契約関係情報（情報ベースから読み出す）と合致していることをチェックする（図６の９行目に対応）
４）アプリケーション起動の準備を行う
・アプリケーション起動時のパラメタとなる＜ＩＮシグニチャ＞情報を設定する（図６の８から１５行目に対応）
・コントラクト本文：ドキュメントまたはＵＲＬ等を設定する
・オーダＩＤ：＜ＯｒｄｅｒＩＤ＞にあった値を設定する
・オーダタイプ：＜ＯｒｄｅｒＴｙｐｅ＞にあった値を設定する
・数量：＜Ｑｕａｎｔｉｔｙ＞にあった値を設定する
・単価：＜Ｐｒｉｃｅ＞にあった値を設定する
・発注日付：＜Ｄａｔｅ＞にあった値を設定する
５）アプリケーションを起動し、リターン（結果）を得、＜ＯＵＴシグニチャ＞情報を設定する（図６の１６から２０行目に対応）
・成否：アプリケーション処理が正常に処理を終えたか否かを示す（図６の１７行目に対応）
・プロダクトタイプ：アプリケーション処理の結果生まれる製品のタイプ（図６の１８行目に対応）
・荷札ＩＤ：製品を以降のステップに引き渡す時の識別子（図６の１９行目に対応）
６）＜事後条件＞の＜発送済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜発送済＞ステータス（情報ベースより読み出す）と合致していることをチェック（図６の２２行目に対応）
７）＜事後条件＞の＜支払済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜支払済＞ステータス（情報ベースより読み出す）と合致していることをチェック（図６の２３行目に対応）
８）次のステップの確定
・アプリケーション起動のリターンにある＜プロダクトタイプ＞の値と＜次のステップの＞の＜条件＞にある＜プロダクトタイプ＞が一致する場合。次の行にある＜ステップＩＤ＞の値が、次のステップＩＤとなる。（図６の２６行目に対応）
・本例では、次のステップに関する情報が無いため、ビジネスプロセスは終了となり、ビジネスプロセス終了報告先へ遷移する、という例である。（図６の３１行目に対応）
９）選定したサービス提供者に送る以下のメッセージを組立て（図７に主な項目を例示）
・ヘッダ部分
・発信システム名：責任システム名
・ビジネスプロセスＩＤ：ビジネスプロセスＩＤ
・宛先システム名：ビジネスプロセス終了プログラム
・ステップ名：無し
・監視システム名：報告者名
・コンテンツ部分
・＜Ｄａｙｓ＞、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の（名前、値）リストからなるＸＭＬ文書（これらの元となる＜日数＞、＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞が責任システムにより設定されていない場合）
・上記ビジネスプロセス定義ＸＭＬ文書（またはそのＵＲＬ）
１０）監視システムに本ビジネスプロセスが終了したことを連絡した後、ビジネスプロセス終了プログラムへこのメッセージを送信する
６ ビジネスプロセス終了報告先の動作
１）メッセージを受信する
２）メッセージを解析し、ヘッダ部分の各情報、コンテンツ部分の各情報を保存する
３）オペレータにビジネスプロセス終了メッセージをあげる
７ ビジネスプロセス監視プログラムの動作
１）成功報告メッセージを受信した場合
・ビジネスプロセスにおける各ステップの進行状況をビジネスプロセス実行履歴情報として保存する
２）進行状況の問い合わせを受信した場合
・保存した各ステップの進行状況を回答する
３）失敗報告メッセージを受信した場合
・責任システムに連絡すると共に、定められた補償動作等を実行するために新たなビジネスプロセスを開始する
４）ステップ実行不可メッセージを受信した場合
・ビジネスプロセス定義文書にステップ実行者が特定されている場合は失敗報告メッセージを受信した場合の処理を行う。特定されていない場合には、ＵＤＤＩのような動的発見機構を用い代替のステップ実行ノードを発見し、そのノードにビジネスプロセスの続行を依頼する。
【００２８】
以上によれば、ネットワーク環境におけるビジネスプロセスの実行を、対等かつ分散型で実現できる。また、ビジネスプロセス定義を共有することで、ビジネス内容を理解した上でビジネスプロセスの遂行に参加するか否かを判断できる。
【００２９】
また、監視ノードを用意することで、分散して実行が進んで行くビジネスプロセスの進行状況をモニターすることが出来る。更に、ビジネスプロセスの実行途上で何らかのエラーが発生した場合の収拾処理も、この監視ノードを用いることで用意することが出来る。
【００３０】
また、ビジネスプロセスの各ステップを実行する計算機ノード間でデータの受け渡しが必要になった場合、単にメッセージに含めて送信するだけでなく、ＵＲＬなどの記法を使いデータの所在場所とアクセス方法だけをメッセージに含めて送信することが出来る。
【００３１】
また、ビジネスプロセスのフローにおける各ステップ実行計算機ノードの特定方法に関し、ビジネスプロセス定義文書中はサービス名やサービス内容だけを記述しておき、実行時にＵＤＤＩなどを使ったＷｅｂサービスの動的発見メカニズムを利用し物理的なサービス実行計算機ノードを特定する、ことが出来る。
【００３２】
また、オープンなネットワーク環境に展開されるビジネスプロセスの管理を代行するという行為がビジネスとして成立することを示している。
【００３３】
【発明の効果】
分散処理環境におけるビジネスプロセスの実行を分散型で実現することが可能となる。
【図面の簡単な説明】
【図１】本発明における一実施例で、布地加工パッケージビジネスプロセスシステムを本発明の方法で実現する場合のシステム構成を示すものである。
【図２】図１で参照される、ＸＭＬ言語による布地加工パッケージビジネスプロセス定義例を示すものである。
【図３】図１における衣料購入で受け付けるメッセージ例を示すものである。
【図４】図１における衣料品製造で受け付けるメッセージ例を示すものである。
【図５】図１における非衣料品製造で受け付けるメッセージ例を示すものである。
【図６】図１におけるパッケージで受け付けるメッセージ例を示すものである。
【図７】ビジネスプロセス定義文書と共に各ステップに送られるメッセージの例である。
【図８】図１で参照される、各ステップ実行計算機ノードでの処理手順例である。
【図９】図１で参照される、各ステップ実行計算機ノードの構成要素例である。
【図１０】図１で参照されるビジネスプロセス例において、起動、監視、終了、といった管理機能を代行するビジネスの構成例である。
【符号の説明】
１ ビジネスプロセス起動計算機ノード
２ ビジネスプロセス監視計算機ノード
３ ビジネスプロセス終了報告計算機ノード
４ 布地購入ステップ実行計算機ノード
５ 衣料品製造ステップ実行計算機ノード
６ 非衣料品製造ステップ実行計算機ノード
７ パッケージステップ実行計算機ノード
８ ネットワーク
９ メッセージ受信処理
１０ メッセージよりビジネスプロセス文書を抽出する処理
１１ ネットワークよりビジネスプロセス文書を抽出する処理
１２ パラメタと定義文書の解析処理
１３ 実行ステップ発見処理
１４ シグニチャの作成処理
１５ 当該ステップ実行処理
１６ 当該ステップ実行結果の監視ノードへの報告処理
１７ 次のステップ確定処理
１８ 次のステップへ送るメッセージ組立て送信処理
１９ ビジネスプロセス利用者システム（装置）
２０ ディスプレイ装置
２１ 入力装置
２２ 中央処理装置（ＣＰＵ）
２３ ビジネスプロセス定義編集プログラム及びＷｅｂサービスクライアントプログラム
２４ ビジネスプロセス監視システム（装置）
２５ ディスプレイ装置
２６ 入力装置
２７ 中央処理装置（ＣＰＵ）
２８ ビジネスプロセス進捗管理Ｗｅｂサービスプログラム
２９ 動作データベース装置
３０ ネットワーク
３１ ビジネスプロセスステップ実行装置
３２ ディスプレイ装置
３３ 入力装置
３４ 中央処理装置（ＣＰＵ）
３５ ビジネスプロセスステップ処理Ｗｅｂサービスプログラム
３６ ビジネスプロセス利用者
３７ ビジネスプロセス処理サービス
３８ ビジネスプロセスステップ実行装置
３９ ビジネスプロセスステップ実行装置
４０ ビジネスプロセスステップ実行装置
【発明の属する技術分野】
本発明はワークフローやビジネスプロセスの処理技術に関する
【０００２】
【従来の技術】
従来ワークフローの標準化やこれを実現した各種プロダクトにみられるように、ビジネスプロセスの制御はワークフロー技術の応用として実現されてきた。この方法では、まず利用者がビジネスプロセスを定義し、ワークフローエンジンと呼ばれるソフトウェアコンポーネントがこの定義に基づき個々のステップの遂行責任を持つソフトウェアや人に対し遠隔手続き呼び出し（ＲＰＣ）やメッセージ送信などの通信手段を用い、ビジネスプロセス定義に従い順次起動ないし作業依頼することでビジネスプロセスの実行と進行状況監視を行っていた。
【０００３】
また、ビジネスプロセス定義の分野ではＸＭＬ言語を用いた記述方法の標準化が議論されていることが知られている。これらは記述のための文法規則であり、記述された定義文書の使い方について規定するものではない。
【０００４】
更に、特開平９−２６５４０８号公報で開示されているような技術では、ワークフローの分散実行という意味で類似の領域を狙ったものであり、▲１▼ビジネスプロセスの自動化というより文書ベースのワークフローの自動化であること、及び▲２▼送信されるワークフロー定義にはフロー情報のほかにプログラムが含まれ各ノードで実行されることを前提にしていること、が特徴であり、本特許の請求項としている、ＸＭＬ「文書」引渡しによる人間の操作を前提としない「ビジネスプロセス」実行の実現、ステップ実行主体の動的発見、文書情報やメッセージ情報の参照による転送、ビジネスプロセス進捗状況モニタリングのための監視ノードの設定、など各種の点において異なるもの（対象領域、技術要素）である。
【０００５】
【特許文献１】
特開平９−２６５４０８号
【０００６】
【発明が解決しようとする課題】
ワークフローエンジンという制御コンポーネントにより集中制御や管理を行うため、その集中制御・管理専用の信頼性の高いソフトウェアやハードウェアが必要であった。
【０００７】
更に、企業の境界をまたがるようなビジネスプロセスではマスタ・スレーブという関係はなじまなず、各企業システムが対等な関係で連携しビジネスプロセスを実現出来るようにすることが求められていた。
【０００８】
また、ステップを実行する主体はその実行に必要最低限の情報だけを与えて処理を行う仕組みとなっていたため、その実行主体にとって当該処理を行うことがビジネス面から妥当か否かといった判断を行う情報が十分に与えられていなかった。
【０００９】
本発明の目的は、分散処理環境におけるビジネスプロセスの実行を分散型で実現することにある。
【００１０】
【課題を解決するための手段】
上記課題を改善するために、文書記述言語を用いて記述したビジネスプロセス定義とビジネスプロセス実行に必要な情報をメッセージ送信という機能を用いステップ間で順次渡して行くという手段を用意する。これにより、制御ノードを必要とせず、参加計算機ノードが対等な立場で、更にビジネスプロセスとしてのコンテキストを理解した上で各ステップ処理を遂行出来るようになる。
【００１１】
一方、ビジネスプロセス処理の進行状況のモニタリング用に監視ノードを用意し、ステップ処理終了時点の結果通知を受けられるようにする。これを用意することで、進行状況のモニタリングだけでなく、ステップでの処理が不成功となった場合に適切な動作を取らせることが可能となる。
【００１２】
【発明の実施の形態】
以下、本発明の実施例を図面に基づいて説明する。図１は本発明における一実施例の構成を示すものである。本実施例では、ネットワーク８で接続された七つの計算機ノードを示しており、ビジネスプロセス起動ノード１がビジネスプロセスを起動する。このビジネスプロセスで最初に行うステップは布地購入ステップで、ビジネスプロセス起動ノード１は布地購入ステップ実行ノード４に図２から図６に例を示したビジネスプロセス定義文書と、図７に示すメッセージを送信する。布地購入ステップの実行終了後、図７のビジネスプロセス定義文書にある条件に従って、衣料品の製造ステップ実行ノード５または衣料品以外の製造ステップ実行ノード６のいずれかに、図２から図６に例を示したビジネスプロセス定義文書と図７のような必要な情報を含むメッセージを送信する。なおメッセージ形式は各ステップ実行ノードが公開している形式に従うものとする。これらのステップでの処理が終了すると、衣料品の製造ステップ実行ノード５または衣料品以外の製造ステップ実行ノード６のいずれかから、パッケージステップ実行ノード７に、図２から図６に例を示したビジネスプロセス定義文書と図７のような必要な情報を含むメッセージを送信する。パッケージステップ実行ノードでの処理が正常に終了すると、ビジネスプロセスが完了し、ビジネスプロセス終了報告ノードに報告を送信する。
【００１３】
ビジネスプロセスの進行状況のモニターを可能にするため、各ステップでの処理が正常に終了した時点でビジネスプロセス監視ノード２に通知メッセージを送信するものとする。ステップでの処理に問題があった場合は、ビジネスプロセス監視ノード２が、それまで正常終了の報告をあげてきた各ステップ実行ノードに対して補償動作指示などの適切な動作を実施する。
【００１４】
ここで、ビジネスプロセス起動ノード１、ビジネスプロセス監視ノード２、ビジネスプロセス終了報告ノード３の三つのノードは、同じ計算機であっても構わないし、別々の計算機としても構わない。
【００１５】
なお、ビジネスプロセス定義文書を直接メッセージの一部として送信するのではなく、ネットワーク上のアクセス可能な場所に置き、ＵＲＬのようなアクセス方法と位置情報を参照という形でメッセージに含めて送信しても良い。
【００１６】
図２〜図６は本ビジネスプロセスをＸＭＬ文書として定義した例である。本発明はＸＭＬ言語での記述例を示しているが、ＸＭＬに限定されるものではない。構造的に記載可能なデータ構造であれば適用可能である。プログラム間で通信するメッセージを文書という表現をしているが、メッセージや要求（リクエスト）でも実現可能である。図２は文書構造であり、ビジネスプロセスは説明、属性、責任システム、ビジネスプロセス・インバリアント、ビジネスプロセス事前条件、報告先、ステップ定義、ビジネスプロセス事後条件から構成されることを示す。また、その内部に複数のステップを定義することが出来る。またステップは、インバリアント、事前条件、シグニチャ、事後条件、次のステップという要素から構成されることを示している。図３以降がビジネスプロセスの定義実体の例である。
【００１７】
図７はビジネスプロセス定義文書と共に各ステップに送られるメッセージの例である。宛先によりステップを遂行する計算機とアプリケーションが指定され、ビジネスプロセスＩＤ、ステップＩＤにより、どのビジネスプロセスのどのステップの処理を行うのかを指示している。それ以降のデータはステップ実行に必要となるパラメタである。
安全性の観点からメッセージ自体をＰＫＩ等を用い暗号化することもある。
【００１８】
図８はビジネスプロセスの実行に参加する各計算機ノードにおける処理の流れの例を示したものである。９でメッセージを受信し、そのメッセージ中にビジネス定義文書が含まれていればそれを１０で取り出し、含まれていない場合には１１のようにＵＲＬ情報をもとにネットワーク経由で取り出し、１２でメッセージに含まれるパラメタ情報と併せて解析を行う。この結果に基づき、１３でビジネスプロセス定義のなかで遂行を求められているステップを発見し、処理に必要な入力情報であるシグニチャを１４で作り上げ、１５で処理の実行を行う。その結果は１６で監視ノードへ報告し、ステップ定義に含まれる条件により、１７で次に行われるべきステップを確定する。最後に１８で次のステップに渡すべきメッセージを組立て、１７で確定したステップ実行計算機ノードに宛てこれを送信する。
【００１９】
図９はこれらビジネスプロセス処理方法を実現する装置の構造例を示したものである。１９はビジネスプロセス利用者システム例であり、ディスプレイ２０、入力装置２１、ＣＰＵ２２を備えている。この装置でビジネスプロセス定義編集プログラムとＷｅｂサービスクライアントプログラム２３を動作させることで、１９の利用者はビジネスプロセス定義文書を作成するとともに、３１で示すビジネスプロセスステップ実行装置にその処理実行の依頼を行う。２４はビジネスプロセス監視装置の構成例であり、ディスプレイ２５、入力装置２６、ＣＰＵ２７を備えている。この装置でビジネスプロセス進捗管理Ｗｅｂサービスプログラム２８を動作させることで、３１で示すビジネスプロセスステップ実行装置から実行結果を随時受信し、１９のビジネスプロセス利用者システムなどから進捗状況の把握が可能となる。また、実行できなかったという結果を受け取った場合、ビジネスプロセス利用者から得た取るべき動作のテーブルなどをＤＢ２９に保管し、対応するエントリを読み出すことで動作指示を出すことができる。３１はビジネスプロセスステップ実行装置の構成例であり、ディスプレイ３２、入力装置３３、ＣＰＵ３４を備えている。この装置でビジネスプロセスステップ処理Ｗｅｂサービスプログラム３５を動作させることで、ビジネスプロセス定義に現れる各ステップの処理を実行することができる。１９、２４、３１の各装置はネットワーク３０で接続されており、オープンな通信が出来るものとしている。
【００２０】
図１０は本ビジネスプロセス処理方法とビジネスプロセス処理装置を使い、ビジネスプロセスの進捗状況監視と必要に応じ補償動作を起動するなどの対応を代行するというビジネスの方法例を示したものである。３６のビジネスプロセス利用者は、ビジネスプロセスの定義を行い、その実行を３７のビジネスプロセス処理サービス提供者に依頼する。ビジネスプロセス処理サービス提供者は依頼者に替わり、ビジネスプロセスの始めのステップを実行するステップ実行装置３８に対し、ビジネスプロセス定義文書とステップ処理に必要なパラメタ情報をメッセージとして送信する。３８はステップ処理後、図１に対する説明で述べたような方法で、３９や４０のステップ実行装置にメッセージを送信する。このとき、各ステップ処理終了後に処理終了や処理不可といった結果情報を３７に送信するが、処理不可の場合には、３７から補償行為に相当する別のビジネスプロセスが流されることもある。３７は利用者に対してビジネスプロセスの管理というサービスを提供することで対価を得る。
【００２１】
以下、例を用い本発明を実現した場合のプログラムの動作を説明する。
【００２２】
１ ビジネスプロセス開始プログラムの動作
１．１ 前提
１）ビジネスプロセス定義（ＸＭＬ文書）はビジネスプロセス開始プログラム実行前に以下のいずれかの形態で作成されているものとする。
【００２３】
すべての値が入った定義文書（例：サービス実行者名や渡すパラメタ値全て）−これはビジネスプロセスの実行者、パラメタ等を全て固定にし、途中で変更を許さないもの。この場合には、変更が行われなかったことを証明するための機構（例えば暗号化やデジタル署名）を併用することを想定する。
【００２４】
部分的にパラメタ化された定義文書（例：サービス実行者に渡す各種情報をパラメタ化したもの）―これはステップ実行結果をビジネスプロセス定義の一部として次のステップに渡す場合などを想定。
【００２５】
すべての変数要素をパラメタ化し、テンプレートとしての利用を目的とした定義文書（例：典型的な購買プロセス）−これはビジネスプロセス定義のテンプレートのライブラリやリポジトリがあり、そこからベースとなるテンプレートを検索し、カスタマイズし利用する。
【００２６】
２）上記ビジネスプロセス定義は、▲１▼ビジネスプロセス開始プログラムへの入力データ、または、▲２▼ビジネスプロセス定義リポジトリ（ＤＢ）から読み出して自らの用途用にパラメタ設定、という形態で利用する
１．２ 例に基づく処理ロジックの説明
１）ビジネスプロセスＸＭＬ定義文書の読み込みを行う
２）同文書の構文解析を行う
３）＜説明＞を画面に出力する（図３の２行目に対応し「本ビジネスプロセスは布地を購入し衣料品等を製造販売するもの」というメッセージをディスプレイに表示）
４）＜属性＞がビジネストランザクションであることをチェックする（図３の３行目「ビジネストランザクション」に対応）
５）＜責任システム＞が本ビジネスプロセス実行を開始するシステム名と一致することをチェックする（図３の４行目「ＡＢＣ製作所．ｃｏｍ／ＢＰ」に対応）
６）＜ビジネスプロセスインバリアント＞として＜ビジネスプロセスＩＤ＞が含まれていることをチェックする（図３の５から７行目「ＸＹＺ１２３４７７」に対応）
７）＜ビジネスプロセスＩＤ＞が設定されている場合はこれを本ビジネスプロセスのＩＤとして保存する（設定されていない場合には、ビジネスプロセス開始プログラムが一意な値を生成し設定）
８）＜ビジネスプロセス事前条件＞の＜布地ストック＞の値（１００）と現実のストック数（開始プログラムが情報ベースより読み出す）を比較し、現実のストック数が１００以下であることをチェックする（図３の８から１０行目「１００」に対応）
９）＜報告先＞が設定されている場合にはこれを本ビジネスプロセスでの報告先として保存する（設定されていない場合には、ここに責任システムのアドレスを設定）（図３の１１行目「ｘｘｘ．ｙｙｙ．ｃｏｍ／ＲｅｐｏｒｔＨａｎｄｌｅｒ」に対応）
１０）＜ステップ定義＞が存在することをチェックする（図３の１２行目に対応）
１１）最初に現れる＜ステップ＞の属性である識別子（サービス名）を保存する（図３の１３行目及び図７の１８行目「布地購入」に対応）
１２）保存した識別子に基づきステップ実行者を選定する
・ネームサービスによる選定（識別子が具体的なシステム名の場合）
・ＵＤＤＩによる選定（識別子がサービス名の場合、ＵＤＤＩでサービスを検索し、判断基準にあうサービス提供者を選定）
１３）ステップ実行者に渡すパラメタの準備を行う
＜インバリアント＞が＜日数＞の場合、ビジネスプロセス定義と共に送付するメッセージに＜日数＞の具体的な値を＜Ｄａｙｓ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図３の１４−１６行目に対応した図７の１９行目「７」）
＜オーダＩＤ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダＩＤ＞の具体的な値を＜ＯｒｄｅｒＩＤ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図３の２２行目に対応した図７の２０行目「ＡＢＣ０００８９１」）
＜オーダタイプ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダタイプ＞の具体的な値を＜ＯｒｄｅｒＴｙｐｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図３の２３行目に対応した図７の２１行目「木綿布地」）
＜数量＞についても、ビジネスプロセス定義と共に送付するメッセージに＜数量＞の具体的な値を＜Ｑｕａｎｔｉｔｙ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図３の２４行目に対応した図７の２２行目「５００００」）
＜単価＞についても、ビジネスプロセス定義と共に送付するメッセージに＜単価＞の具体的な値を＜Ｐｒｉｃｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図３の２５行目に対応した図７の２３行目「３０００」）
＜発注日付＞についても、ビジネスプロセス定義と共に送付するメッセージに＜発注日付＞の具体的な値を＜Ｄａｔｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図３の２６行目に対応「２００２０７０１」）
１４）選定したサービス提供者に送る以下のメッセージを組立て（図７に主な項目を例示）
・ ヘッダ部分
・ 発信システム名：責任システム名
・ ビジネスプロセスＩＤ：ビジネスプロセスＩＤ
・ 宛先システム名：選定されたサービス提供者名
・ ステップ名：ステップ識別子
・ 監視システム名：報告者名
・ コンテンツ部分
＜Ｄａｙｓ＞、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の（名前、値）リストからなるＸＭＬ文書（これらの元となる＜日数＞、＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞が責任システムにより設定されていない場合）
上記ビジネスプロセス定義ＸＭＬ文書（またはそのＵＲＬ）
１５）選定したサービス提供者へこのメッセージを送信する
１６）監視システムにビジネスプロセス文書を送付し当該ビジネスプロセスがスタートしたことを連絡する
２ 衣料材購入ステップでのプログラムの動作
２．１ 前提
１）メッセージを受信する
２）メッセージを解析し、ヘッダ部分の各情報、コンテンツ部分の各情報を保存する（図７に例示した内容）
３）ヘッダ部分に含まれるステップ名を用い、コンテンツ部分のビジネスプロセス定義から対応するステップを確定する（例では布地購入ステップ）（図３の１３行目の情報を使用）
４）ステップ実行を受け入れることが出来ない場合には、監視ノードにその旨の連絡をする
２．２ 例に基づく処理ロジックの説明
１）＜インバリアント＞の＜日数＞の値（”Ｄａｙｓ”）は、メッセージに＜Ｄａｙｓ＞があるためその値で置き換え保存する（図３の１５行目に対応し、図７の１９行目の値で置き換えることに相当）
２）＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞についても同様に、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の値で置き換え保存する（図３の２２から２６行目及び図７の２０から２４行目に対応）
３）＜事前条件＞の＜コントラクト＞の値（契約済み）が、ステップ実行者と責任システムとの間の契約関係情報（情報ベースから読み出す）と合致していることをチェックする（図３の２１行目「ｘｘｘ．ｙｙｙ．ｃｏｍ／ｃｏｎｔｒａｃｔ．ｄｏｃ」の記述内容に対応）
４）アプリケーション起動の準備を行う
アプリケーション起動時のパラメタとなる＜ＩＮシグニチャ＞情報を設定する（図３の２０から２７行目に対応）
・コントラクト本文：ドキュメントまたはＵＲＬ等を設定する
・オーダＩＤ：＜ＯｒｄｅｒＩＤ＞にあった値を設定する
・オーダタイプ：＜ＯｒｄｅｒＴｙｐｅ＞にあった値を設定する
・数量：＜Ｑｕａｎｔｉｔｙ＞にあった値を設定する
・単価：＜Ｐｒｉｃｅ＞にあった値を設定する
・発注日付：＜Ｄａｔｅ＞にあった値を設定する
５）アプリケーションを起動し、リターン（結果）を得、＜ＯＵＴシグニチャ＞情報を設定する（図３の２８から３２行目に対応）
・成否：アプリケーション処理が正常に処理を終えたか否かを示す（図３の２９行目に対応）
・プロダクトタイプ：アプリケーション処理の結果生まれる製品のタイプ（図３の３０行目に対応）
・荷札ＩＤ：製品を以降のステップに引き渡す時の識別子（図３の３１行目に対応）
６）＜成否＞の値が成功であることを確認：失敗の場合には以降の処理は行わず、失敗報告メッセージを報告者に送信する
７）＜事後条件＞の＜発送済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜発送済＞ステータス（情報ベースより読み出す）と合致していることをチェックする（図３の３４行目に対応）
８）＜事後条件＞の＜支払済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜支払済＞ステータス（情報ベースより読み出す）と合致していることをチェックする（図３の３５行目に対応）
９）次のステップの確定
・アプリケーション起動のリターンにある＜プロダクトタイプ＞の値と＜次のステップの＞の＜条件＞にある＜プロダクトタイプ＞が一致する場合。次の行にある＜ステップＩＤ＞の値が、次のステップＩＤとなる。（図３の３９行目と４３行目が条件で、各々の遷移先が４０行目と４４行目）
・本例では、プロダクトタイプが衣料品用布地であれば衣料品製造というステップへ、プロダクトタイプが非衣料品用布地であれば非衣料品製造というステップへ、各々遷移する、という例である。
【００２７】
１０）上記判定により決まったステップの属性である識別子（サービス名）をビジネスプロセス定義ＸＭＬ文書より読み出す
１１）その識別子に基づきステップ実行者を選定する
・ネームサービスによる選定（識別子が具体的なシステム名の場合）
・ＵＤＤＩによる選定（識別子がサービス名の場合、ＵＤＤＩでサービスを検索し、判断基準にあうサービス提供者を選定）
１２）ステップ実行者に渡すパラメタの準備を行う
＜インバリアント＞が＜日数＞の場合、ビジネスプロセス定義と共に送付するメッセージに＜日数＞の具体的な値を＜Ｄａｙｓ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図４の３行目または図５の３行目に対応した図７の１９行目）
＜オーダＩＤ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダＩＤ＞の具体的な値を＜ＯｒｄｅｒＩＤ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図４の１０行目または図５の１０行目に対応した図７の２０行目）
＜オーダタイプ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダタイプ＞の具体的な値を＜ＯｒｄｅｒＴｙｐｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図４の１１行目または図５の１１行目に対応した図７の２１行目）
＜数量＞についても、ビジネスプロセス定義と共に送付するメッセージに＜数量＞の具体的な値を＜Ｑｕａｎｔｉｔｙ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図４の１２行目または図５の１２行目に対応した図７の２２行目）
＜単価＞についても、ビジネスプロセス定義と共に送付するメッセージに＜単価＞の具体的な値を＜Ｐｒｉｃｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図４の１３行目または図５の１３行目に対応した図７の２３行目）
＜発注日付＞についても、ビジネスプロセス定義と共に送付するメッセージに＜発注日付＞の具体的な値を＜Ｄａｔｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図４の１４行目または図５の１４行目に対応した図７の２４行目）
１３）選定したサービス提供者に送る以下のメッセージを組立て（図７に主な項目を例示）
・ヘッダ部分
・発信システム名：責任システム名
・ビジネスプロセスＩＤ：ビジネスプロセスＩＤ
・宛先システム名：選定されたサービス提供者名
・ステップ名：ステップ識別子
・監視システム名：報告者名
・コンテンツ部分
＜Ｄａｙｓ＞、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の（名前、値）リストからなるＸＭＬ文書（これらの元となる＜日数＞、＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞が責任システムにより設定されていない場合）
・上記ビジネスプロセス定義ＸＭＬ文書（またはそのＵＲＬ）
１４）監視システムに本ビジネスプロセスの衣料材購入ステップが終了したことを連絡した後、選定したサービス提供者へこのメッセージを送信する
３ 衣料品製造ステップ
３．１ 前提
１）メッセージを受信する
２）メッセージを解析し、ヘッダ部分の各情報、コンテンツ部分の各情報を保存する
３）ヘッダ部分に含まれるステップ名を用い、コンテンツ部分のビジネスプロセス定義から対応するステップを確定する（例では衣料品製造ステップ）（図４の１行目「衣料品製造」に対応）
４）必要に応じ、直前のステップが正常に終了していることを、監視ノードに問合せ確認する
５）ステップ実行を受け入れることが出来ない場合には、監視ノードにその旨の連絡をする
３．２ 例に基づく処理ロジックの説明
１）＜インバリアント＞の＜日数＞の値（”Ｄａｙｓ”）は、メッセージに＜Ｄａｙｓ＞があるためその値で置き換え保存する（図４の２−４行目に対応）
２）＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞についても同様に、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の値で置き換え保存する（図４の１０から１４行目に対応）
３）＜事前条件＞の＜コントラクト＞の値（契約済み）が、ステップ実行者と責任システムとの間の契約関係情報（情報ベースから読み出す）と合致していることをチェックする（図４の９行目「ｘｘｘ．ｙｙｙ．ｃｏｍ／ｃｏｎｔｒａｃｔ．ｄｏｃ」の記述内容に対応）
４）アプリケーション起動の準備を行う
・アプリケーション起動時のパラメタとなる＜ＩＮシグニチャ＞情報を設定する（図４の８から１５行目に対応）
・コントラクト本文：ドキュメントまたはＵＲＬ等を設定する
・オーダＩＤ：＜ＯｒｄｅｒＩＤ＞にあった値を設定する
・オーダタイプ：＜ＯｒｄｅｒＴｙｐｅ＞にあった値を設定する
・数量：＜Ｑｕａｎｔｉｔｙ＞にあった値を設定する
・単価：＜Ｐｒｉｃｅ＞にあった値を設定する
・発注日付：＜Ｄａｔｅ＞にあった値を設定する
５）アプリケーションを起動し、リターン（結果）を得、＜ＯＵＴシグニチャ＞情報を設定する（図４の１６から２０行目に対応）
・成否：アプリケーション処理が正常に処理を終えたか否かを示す（図４の１７行目に対応）
・プロダクトタイプ：アプリケーション処理の結果生まれる製品のタイプ（図４の１８行目に対応）
・荷札ＩＤ：製品を以降のステップに引き渡す時の識別子（図４の１９行目に対応）
６）＜成否＞の値が成功であることを確認：失敗の場合には以降の処理は行わず、失敗報告メッセージを報告者に送信する
７）＜事後条件＞の＜発送済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜発送済＞ステータス（情報ベースより読み出す）と合致していることをチェックする（図４の２２行目に対応）
８）＜事後条件＞の＜支払済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜支払済＞ステータス（情報ベースより読み出す）と合致していることをチェックする（図４の２３行目に対応）
９）次のステップの確定
・アプリケーション起動のリターンにある＜プロダクトタイプ＞の値と＜次のステップの＞の＜条件＞にある＜プロダクトタイプ＞が一致する場合。次の行にある＜ステップＩＤ＞の値が、次のステップＩＤとなる。（図４の２７行目が条件で２８行目が遷移先）
・本例では、プロダクトタイプが衣料品であればパッケージというステップへ、遷移する、という例である。
１０）上記判定により決まったステップの属性である識別子（サービス名）をビジネスプロセス定義ＸＭＬ文書より読み出す
１１）その識別子に基づきステップ実行者を選定する
・ネームサービスによる選定（識別子が具体的なシステム名の場合）
・ＵＤＤＩによる選定（識別子がサービス名の場合、ＵＤＤＩでサービスを検索し、判断基準にあうサービス提供者を選定）
１２）ステップ実行者に渡すパラメタの準備を行う
・＜インバリアント＞が＜日数＞の場合、ビジネスプロセス定義と共に送付するメッセージに＜日数＞の具体的な値を＜Ｄａｙｓ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の３行目に対応した図７の１９行目）
・＜オーダＩＤ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダＩＤ＞の具体的な値を＜ＯｒｄｅｒＩＤ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１０行目に対応した図７の２０行目）
・＜オーダタイプ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダタイプ＞の具体的な値を＜ＯｒｄｅｒＴｙｐｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１１行目に対応した図７の２１行目）
・＜数量＞についても、ビジネスプロセス定義と共に送付するメッセージに＜数量＞の具体的な値を＜Ｑｕａｎｔｉｔｙ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１２行目に対応した図７の２２行目）
・＜単価＞についても、ビジネスプロセス定義と共に送付するメッセージに＜単価＞の具体的な値を＜Ｐｒｉｃｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１３行目に対応した図７の２３行目）
＜発注日付＞についても、ビジネスプロセス定義と共に送付するメッセージに＜発注日付＞の具体的な値を＜Ｄａｔｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１４行目に対応した図７の２４行目）
１３）選定したサービス提供者に送る以下のメッセージを組立て（図７に主な項目を例示）
・ヘッダ部分
・発信システム名：責任システム名
・ビジネスプロセスＩＤ：ビジネスプロセスＩＤ
・宛先システム名：選定されたサービス提供者名
・ステップ名：ステップ識別子
・監視システム名：報告者名
・コンテンツ部分
・＜Ｄａｙｓ＞、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の（名前、値）リストからなるＸＭＬ文書（これらの元となる＜日数＞、＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞が責任システムにより設定されていない場合）
・上記ビジネスプロセス定義ＸＭＬ文書（またはそのＵＲＬ）
１４）監視システムに本ビジネスプロセスの衣料材製造ステップが終了したことを連絡した後、選定したサービス提供者へこのメッセージを送信する
４ 非衣料品製造ステップ
４．１ 前提
１）メッセージを受信する
２）メッセージを解析し、ヘッダ部分の各情報、コンテンツ部分の各情報を保存する
３）ヘッダ部分に含まれるステップ名を用い、コンテンツ部分のビジネスプロセス定義から対応するステップを確定する（例では非衣料品製造ステップ）（図５の１行目「非衣料品製造」に対応）
４）必要に応じ、直前のステップが正常に終了していることを、監視ノードに問合せ確認する
５）ステップ実行を受け入れることが出来ない場合には、監視ノードにその旨の連絡をする
４．２ 例に基づく処理ロジックの説明
１）＜インバリアント＞の＜日数＞の値（”Ｄａｙｓ”）は、メッセージに＜Ｄａｙｓ＞があるためその値で置き換え保存する（図５の２から４行目に対応）
２）＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞についても同様に、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の値で置き換え保存する（図５の１０から１４行目に対応）
３）＜事前条件＞の＜コントラクト＞の値（契約済み）が、ステップ実行者と責任システムとの間の契約関係情報（情報ベースから読み出す）と合致していることをチェックする（図５の９行目「ｑｑｑ．ｐｐｐ．ｃｏｍ／ｃｏｎｔｒａｃｔ．ｄｏｃ」の記述内容に対応）
４）アプリケーション起動の準備を行う
・アプリケーション起動時のパラメタとなる＜ＩＮシグニチャ＞情報を設定する（図５の８から１５行目に対応）
・コントラクト本文：ドキュメントまたはＵＲＬ等を設定する
・オーダＩＤ：＜ＯｒｄｅｒＩＤ＞にあった値を設定する
・オーダタイプ：＜ＯｒｄｅｒＴｙｐｅ＞にあった値を設定する
・数量：＜Ｑｕａｎｔｉｔｙ＞にあった値を設定する
・単価：＜Ｐｒｉｃｅ＞にあった値を設定する
・発注日付：＜Ｄａｔｅ＞にあった値を設定する
５）アプリケーションを起動し、リターン（結果）を得、＜ＯＵＴシグニチャ＞情報を設定する（図５の１６から２０行目に対応）
・成否：アプリケーション処理が正常に処理を終えたか否かを示す（図５の１７行目に対応）
・プロダクトタイプ：アプリケーション処理の結果生まれる製品のタイプ（図５の１８行目に対応）
・荷札ＩＤ：製品を以降のステップに引き渡す時の識別子（図５の１９行目に対応）
６）＜成否＞の値が成功であることを確認：失敗の場合には以降の処理は行わず、失敗報告メッセージを報告者に送信する
７）＜事後条件＞の＜発送済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜発送済＞ステータス（情報ベースより読み出す）と合致していることをチェック（図５の２２行目に対応）
８）＜事後条件＞の＜支払済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜支払済＞ステータス（情報ベースより読み出す）と合致していることをチェック（図５の２３行目に対応）
９）次のステップの確定
・アプリケーション起動のリターンにある＜プロダクトタイプ＞の値と＜次のステップの＞の＜条件＞にある＜プロダクトタイプ＞が一致する場合。次の行にある＜ステップＩＤ＞の値が、次のステップＩＤとなる。（図５の２７行目が条件で２８行目が遷移先）
・本例では、プロダクトタイプが非衣料品であればパッケージというステップへ遷移する、という例である。
１０）上記判定により決まったステップの属性である識別子（サービス名）をビジネスプロセス定義ＸＭＬ文書より読み出す
１１）その識別子に基づきステップ実行者を選定する
・ネームサービスによる選定（識別子が具体的なシステム名の場合）
・ＵＤＤＩによる選定（識別子がサービス名の場合、ＵＤＤＩでサービスを検索し、判断基準にあうサービス提供者を選定）
１２）ステップ実行者に渡すパラメタの準備を行う
・＜インバリアント＞が＜日数＞の場合、ビジネスプロセス定義と共に送付するメッセージに＜日数＞の具体的な値を＜Ｄａｙｓ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の３行目に対応した図７の１９行目）
・＜オーダＩＤ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダＩＤ＞の具体的な値を＜ＯｒｄｅｒＩＤ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１０行目に対応した図７の２０行目）
＊ ＜オーダタイプ＞についても、ビジネスプロセス定義と共に送付するメッセージに＜オーダタイプ＞の具体的な値を＜ＯｒｄｅｒＴｙｐｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１１行目に対応した図７の２１行目）
・＜数量＞についても、ビジネスプロセス定義と共に送付するメッセージに＜数量＞の具体的な値を＜Ｑｕａｎｔｉｔｙ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１２行目に対応した図７の２２行目）
・＜単価＞についても、ビジネスプロセス定義と共に送付するメッセージに＜単価＞の具体的な値を＜Ｐｒｉｃｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１３行目に対応した図７の２３行目）
・＜発注日付＞についても、ビジネスプロセス定義と共に送付するメッセージに＜発注日付＞の具体的な値を＜Ｄａｔｅ＞として設定、但し責任システムが最初から数値を設定している場合は何もしない（図６の１４行目に対応した図７の２４行目）
１３）選定したサービス提供者に送る以下のメッセージを組立て（図７に主な項目を例示）
・ヘッダ部分
・発信システム名：責任システム名
・ビジネスプロセスＩＤ：ビジネスプロセスＩＤ
・宛先システム名：選定されたサービス提供者名
・ステップ名：ステップ識別子
・監視システム名：報告者名
・コンテンツ部分
・＜Ｄａｙｓ＞、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の（名前、値）リストからなるＸＭＬ文書（これらの元となる＜日数＞、＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞が責任システムにより設定されていない場合）
・上記ビジネスプロセス定義ＸＭＬ文書（またはそのＵＲＬ）
１４）監視システムに本ビジネスプロセスの非衣料材製造ステップが終了したことを連絡した後、選定したサービス提供者へこのメッセージを送信する
５ パッケージステップ
５．１ 前提
１）メッセージを受信する
２）メッセージを解析し、ヘッダ部分の各情報、コンテンツ部分の各情報を保存する
３）ヘッダ部分に含まれるステップ名を用い、コンテンツ部分のビジネスプロセス定義から対応するステップを確定する（例ではパッケージステップ）（図６の１行目「パッケージ」に対応）
４）必要に応じ、直前のステップが正常に終了していることを、監視ノードに問合せ確認する
５）ステップ実行を受け入れることが出来ない場合には、監視ノードにその旨の連絡をする
５．２ 例に基づく処理ロジックの説明
１）＜インバリアント＞の＜日数＞の値（”Ｄａｙｓ”）は、メッセージに＜Ｄａｙｓ＞があるためその値で置き換え保存する（図６の３から５行目に対応）
２）＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞についても同様に、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の値で置き換え保存する（図６の１０から１４行目に対応）
３）＜事前条件＞の＜コントラクト＞の値（契約済み）が、ステップ実行者と責任システムとの間の契約関係情報（情報ベースから読み出す）と合致していることをチェックする（図６の９行目に対応）
４）アプリケーション起動の準備を行う
・アプリケーション起動時のパラメタとなる＜ＩＮシグニチャ＞情報を設定する（図６の８から１５行目に対応）
・コントラクト本文：ドキュメントまたはＵＲＬ等を設定する
・オーダＩＤ：＜ＯｒｄｅｒＩＤ＞にあった値を設定する
・オーダタイプ：＜ＯｒｄｅｒＴｙｐｅ＞にあった値を設定する
・数量：＜Ｑｕａｎｔｉｔｙ＞にあった値を設定する
・単価：＜Ｐｒｉｃｅ＞にあった値を設定する
・発注日付：＜Ｄａｔｅ＞にあった値を設定する
５）アプリケーションを起動し、リターン（結果）を得、＜ＯＵＴシグニチャ＞情報を設定する（図６の１６から２０行目に対応）
・成否：アプリケーション処理が正常に処理を終えたか否かを示す（図６の１７行目に対応）
・プロダクトタイプ：アプリケーション処理の結果生まれる製品のタイプ（図６の１８行目に対応）
・荷札ＩＤ：製品を以降のステップに引き渡す時の識別子（図６の１９行目に対応）
６）＜事後条件＞の＜発送済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜発送済＞ステータス（情報ベースより読み出す）と合致していることをチェック（図６の２２行目に対応）
７）＜事後条件＞の＜支払済＞の値（ｙｅｓ）が、ステップ実行者の本ビジネスプロセス（ＩＤにより識別）における＜支払済＞ステータス（情報ベースより読み出す）と合致していることをチェック（図６の２３行目に対応）
８）次のステップの確定
・アプリケーション起動のリターンにある＜プロダクトタイプ＞の値と＜次のステップの＞の＜条件＞にある＜プロダクトタイプ＞が一致する場合。次の行にある＜ステップＩＤ＞の値が、次のステップＩＤとなる。（図６の２６行目に対応）
・本例では、次のステップに関する情報が無いため、ビジネスプロセスは終了となり、ビジネスプロセス終了報告先へ遷移する、という例である。（図６の３１行目に対応）
９）選定したサービス提供者に送る以下のメッセージを組立て（図７に主な項目を例示）
・ヘッダ部分
・発信システム名：責任システム名
・ビジネスプロセスＩＤ：ビジネスプロセスＩＤ
・宛先システム名：ビジネスプロセス終了プログラム
・ステップ名：無し
・監視システム名：報告者名
・コンテンツ部分
・＜Ｄａｙｓ＞、＜ＯｒｄｅｒＩＤ＞、＜ＯｒｄｅｒＴｙｐｅ＞、＜Ｑｕａｎｔｉｔｙ＞、＜Ｐｒｉｃｅ＞、＜Ｄａｔｅ＞の（名前、値）リストからなるＸＭＬ文書（これらの元となる＜日数＞、＜オーダＩＤ＞、＜オーダタイプ＞、＜数量＞、＜単価＞、＜発注日付＞が責任システムにより設定されていない場合）
・上記ビジネスプロセス定義ＸＭＬ文書（またはそのＵＲＬ）
１０）監視システムに本ビジネスプロセスが終了したことを連絡した後、ビジネスプロセス終了プログラムへこのメッセージを送信する
６ ビジネスプロセス終了報告先の動作
１）メッセージを受信する
２）メッセージを解析し、ヘッダ部分の各情報、コンテンツ部分の各情報を保存する
３）オペレータにビジネスプロセス終了メッセージをあげる
７ ビジネスプロセス監視プログラムの動作
１）成功報告メッセージを受信した場合
・ビジネスプロセスにおける各ステップの進行状況をビジネスプロセス実行履歴情報として保存する
２）進行状況の問い合わせを受信した場合
・保存した各ステップの進行状況を回答する
３）失敗報告メッセージを受信した場合
・責任システムに連絡すると共に、定められた補償動作等を実行するために新たなビジネスプロセスを開始する
４）ステップ実行不可メッセージを受信した場合
・ビジネスプロセス定義文書にステップ実行者が特定されている場合は失敗報告メッセージを受信した場合の処理を行う。特定されていない場合には、ＵＤＤＩのような動的発見機構を用い代替のステップ実行ノードを発見し、そのノードにビジネスプロセスの続行を依頼する。
【００２８】
以上によれば、ネットワーク環境におけるビジネスプロセスの実行を、対等かつ分散型で実現できる。また、ビジネスプロセス定義を共有することで、ビジネス内容を理解した上でビジネスプロセスの遂行に参加するか否かを判断できる。
【００２９】
また、監視ノードを用意することで、分散して実行が進んで行くビジネスプロセスの進行状況をモニターすることが出来る。更に、ビジネスプロセスの実行途上で何らかのエラーが発生した場合の収拾処理も、この監視ノードを用いることで用意することが出来る。
【００３０】
また、ビジネスプロセスの各ステップを実行する計算機ノード間でデータの受け渡しが必要になった場合、単にメッセージに含めて送信するだけでなく、ＵＲＬなどの記法を使いデータの所在場所とアクセス方法だけをメッセージに含めて送信することが出来る。
【００３１】
また、ビジネスプロセスのフローにおける各ステップ実行計算機ノードの特定方法に関し、ビジネスプロセス定義文書中はサービス名やサービス内容だけを記述しておき、実行時にＵＤＤＩなどを使ったＷｅｂサービスの動的発見メカニズムを利用し物理的なサービス実行計算機ノードを特定する、ことが出来る。
【００３２】
また、オープンなネットワーク環境に展開されるビジネスプロセスの管理を代行するという行為がビジネスとして成立することを示している。
【００３３】
【発明の効果】
分散処理環境におけるビジネスプロセスの実行を分散型で実現することが可能となる。
【図面の簡単な説明】
【図１】本発明における一実施例で、布地加工パッケージビジネスプロセスシステムを本発明の方法で実現する場合のシステム構成を示すものである。
【図２】図１で参照される、ＸＭＬ言語による布地加工パッケージビジネスプロセス定義例を示すものである。
【図３】図１における衣料購入で受け付けるメッセージ例を示すものである。
【図４】図１における衣料品製造で受け付けるメッセージ例を示すものである。
【図５】図１における非衣料品製造で受け付けるメッセージ例を示すものである。
【図６】図１におけるパッケージで受け付けるメッセージ例を示すものである。
【図７】ビジネスプロセス定義文書と共に各ステップに送られるメッセージの例である。
【図８】図１で参照される、各ステップ実行計算機ノードでの処理手順例である。
【図９】図１で参照される、各ステップ実行計算機ノードの構成要素例である。
【図１０】図１で参照されるビジネスプロセス例において、起動、監視、終了、といった管理機能を代行するビジネスの構成例である。
【符号の説明】
１ ビジネスプロセス起動計算機ノード
２ ビジネスプロセス監視計算機ノード
３ ビジネスプロセス終了報告計算機ノード
４ 布地購入ステップ実行計算機ノード
５ 衣料品製造ステップ実行計算機ノード
６ 非衣料品製造ステップ実行計算機ノード
７ パッケージステップ実行計算機ノード
８ ネットワーク
９ メッセージ受信処理
１０ メッセージよりビジネスプロセス文書を抽出する処理
１１ ネットワークよりビジネスプロセス文書を抽出する処理
１２ パラメタと定義文書の解析処理
１３ 実行ステップ発見処理
１４ シグニチャの作成処理
１５ 当該ステップ実行処理
１６ 当該ステップ実行結果の監視ノードへの報告処理
１７ 次のステップ確定処理
１８ 次のステップへ送るメッセージ組立て送信処理
１９ ビジネスプロセス利用者システム（装置）
２０ ディスプレイ装置
２１ 入力装置
２２ 中央処理装置（ＣＰＵ）
２３ ビジネスプロセス定義編集プログラム及びＷｅｂサービスクライアントプログラム
２４ ビジネスプロセス監視システム（装置）
２５ ディスプレイ装置
２６ 入力装置
２７ 中央処理装置（ＣＰＵ）
２８ ビジネスプロセス進捗管理Ｗｅｂサービスプログラム
２９ 動作データベース装置
３０ ネットワーク
３１ ビジネスプロセスステップ実行装置
３２ ディスプレイ装置
３３ 入力装置
３４ 中央処理装置（ＣＰＵ）
３５ ビジネスプロセスステップ処理Ｗｅｂサービスプログラム
３６ ビジネスプロセス利用者
３７ ビジネスプロセス処理サービス
３８ ビジネスプロセスステップ実行装置
３９ ビジネスプロセスステップ実行装置
４０ ビジネスプロセスステップ実行装置
Claims (8)
- 相互通信が可能な複数の計算機が連携して行うビジネスプロセス処理方法において、
ビジネスプロセス定義を含むメッセージを参照し、次のステップへの入力パラメタを論理メッセージとして生成し、前記次のステップを実行する計算機へ送信することにより、当該計算機がそのステップを実行するとともに前記ビジネスプロセス定義に含まれる情報を解析して実行すべき次のステップを決定し、前記ビジネスプロセス定義メッセージの処理にて生成した前記次のステップへの入力パラメタを論理メッセージとして生成して次のステップを実行する計算機ノードに送信することを特徴としたビジネスプロセス処理方法。 - 前記ステップでの実行結果を事前に設定する監視ノードに通知することで、当該ビジネスプロセスの進捗状況を随時把握出来るようにし、障害等により以降のノードへ前記ビジネスプロセスを進められない場合には前記監視ノードから定義に基づき前記ビジネスプロセスを中断し補償動作を実現するビジネスプロセスを起動させることを特徴とする請求項１記載のビジネスプロセス処理方法。
- ステップ間でデータの引渡しが必要な場合に、データを当該ステップ間のメッセージの一部として引き渡す、またはデータの所在、名前およびアクセス手順を前記ビジネスプロセスメッセージの一部として引き渡すことを特徴とする請求項１記載のビジネスプロセス管方法。
- 前記ビジネスプロセス定義におけるステップ実行主体の指定時に、名称解決によりネットワークアドレスを直接得られるようなシステム名の指定またはサービス名やサービス記述といった型情報を指定することで、次のステップ実行主体を発見もしくは確定することを特徴とする請求項１記載のビジネスプロセス管方法。
- 請求項１から４のビジネスプロセス処理方法を用い、非集中型のビジネスプロセス実行を行うシステム及び装置。
- 請求項１から５のビジネスプロセス処理方法と装置を用い、他者からの依頼を受け、ビジネスプロセスの進捗状況を監視し、必要に応じ補償動作を起動するなどの対応を行い、ビジネスプロセス開始者の負担を代行するというビジネスの方法。
- 相互通信が可能な複数の計算機が連携して行うビジネスプロセス処理システムにおいて、
ビジネスプロセス定義を含むメッセージを参照し、次のステップへの入力パラメタを論理メッセージとして生成し、前記次のステップを実行する計算機へ送信する手段と、当該計算機がそのステップを実行するとともに前記ビジネスプロセス定義に含まれる情報を解析して実行すべき次のステップを決定し、前記ビジネスプロセス定義メッセージの処理にて生成した前記次のステップへの入力パラメタを論理メッセージとして生成して次のステップを実行する計算機ノードに送信する手段とを備えたことを特徴としたビジネスプロセス処理システム。 - 相互通信が可能な複数の計算機が連携して行うビジネスプロセス処理システムにおけるビジネスプロセス処理プログラムにおいて、
ビジネスプロセス定義を含むメッセージを参照し、次のステップへの入力パラメタを論理メッセージとして生成し、前記次のステップを実行する計算機へ送信する機能と、当該計算機がそのステップを実行するとともに前記ビジネスプロセス定義に含まれる情報を解析して実行すべき次のステップを決定し、前記ビジネスプロセス定義メッセージの処理にて生成した前記次のステップへの入力パラメタを論理メッセージとして生成して次のステップを実行する計算機ノードに送信する機能とを有することを特徴としたビジネスプロセス処理プログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003046684A JP4352722B2 (ja) | 2003-02-25 | 2003-02-25 | ビジネスプロセス処理方法およびシステム並びにその処理プログラム |
| US10/650,688 US20040167795A1 (en) | 2003-02-25 | 2003-08-29 | Method and system for processing business process, and processing program therefor |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003046684A JP4352722B2 (ja) | 2003-02-25 | 2003-02-25 | ビジネスプロセス処理方法およびシステム並びにその処理プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004258823A true JP2004258823A (ja) | 2004-09-16 |
| JP4352722B2 JP4352722B2 (ja) | 2009-10-28 |
Family
ID=32866549
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003046684A Expired - Fee Related JP4352722B2 (ja) | 2003-02-25 | 2003-02-25 | ビジネスプロセス処理方法およびシステム並びにその処理プログラム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20040167795A1 (ja) |
| JP (1) | JP4352722B2 (ja) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007249598A (ja) * | 2006-03-16 | 2007-09-27 | Mitsubishi Electric Corp | 処理フロー制御装置及びアプリケーション実行装置及び処理フロー制御システム及び処理フロー制御方法及び処理フロー制御プログラム |
| JP2010002963A (ja) * | 2008-06-18 | 2010-01-07 | Hitachi Ltd | サービス連携方法、サービス連携プログラム、ｂｐノード、および、サービス連携システム |
| WO2010018637A1 (ja) * | 2008-08-15 | 2010-02-18 | 富士通株式会社 | 業務フロー分散処理システム及び方法 |
| WO2011042969A1 (ja) * | 2009-10-07 | 2011-04-14 | Nakashima Hirofumi | P2p型のワークフローシステム |
| CN102810070A (zh) * | 2012-07-16 | 2012-12-05 | 福建富士通信息软件有限公司 | 高性能业务能力封装流程引擎及其流程控制方法 |
| JP2013012014A (ja) * | 2011-06-29 | 2013-01-17 | Yahoo Japan Corp | アプリケーションプラットフォーム装置、アプリケーションプラットフォームシステム及びアプリケーションプラットフォーム装置の動作方法 |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4625337B2 (ja) * | 2004-02-23 | 2011-02-02 | 株式会社リコー | プロセス管理装置、プロセス管理方法及びプロセス管理プログラム |
| US8650152B2 (en) * | 2004-05-28 | 2014-02-11 | International Business Machines Corporation | Method and system for managing execution of data driven workflows |
| US20100161362A1 (en) | 2006-08-13 | 2010-06-24 | Controls Force Ltd. | Systems and methods for message-based control and monitoring of a business process |
| US9020944B2 (en) | 2009-10-29 | 2015-04-28 | International Business Machines Corporation | Systems and methods for organizing documented processes |
| US8561080B2 (en) * | 2011-04-26 | 2013-10-15 | Sap Ag | High-load business process scalability |
| CN113409153A (zh) * | 2020-03-16 | 2021-09-17 | 京东安联财产保险有限公司 | 业务流程管理系统与业务流程处理方法、设备及存储介质 |
| CN112433794A (zh) * | 2020-11-20 | 2021-03-02 | 金蝶云科技有限公司 | 一种erp系统业务进度的控制方法及相关设备 |
| CN113762910B (zh) * | 2020-11-27 | 2024-04-16 | 北京京东振世信息技术有限公司 | 一种单据监控方法和装置 |
| CN113435842A (zh) * | 2021-06-28 | 2021-09-24 | 京东科技控股股份有限公司 | 业务流程的处理方法和计算机设备 |
| CN113778572B (zh) * | 2021-09-28 | 2023-09-15 | 广州四三九九信息科技有限公司 | 一种多个cli程序自动衔接为任务流程的方法 |
| CN114785874B (zh) * | 2022-06-16 | 2022-09-06 | 成都中科合迅科技有限公司 | 基于多网络协议提供高可用传输通道的方法 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5754857A (en) * | 1995-12-08 | 1998-05-19 | Sun Microsystems, Inc. | Distributed asynchronous workflow on the net |
| US6463420B1 (en) * | 1999-12-30 | 2002-10-08 | General Electric Company | Online tracking of delivery status information over a computer network |
| JP2002074090A (ja) * | 2000-08-29 | 2002-03-12 | Mori Seiki Co Ltd | ネットワークシステム |
| US20020143660A1 (en) * | 2001-03-29 | 2002-10-03 | International Business Machines Corporation | Method and system for online shopping |
| GB2381710B (en) * | 2001-10-31 | 2004-01-21 | Sun Microsystems Inc | Method and apparatus for routing signed messages |
-
2003
- 2003-02-25 JP JP2003046684A patent/JP4352722B2/ja not_active Expired - Fee Related
- 2003-08-29 US US10/650,688 patent/US20040167795A1/en not_active Abandoned
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007249598A (ja) * | 2006-03-16 | 2007-09-27 | Mitsubishi Electric Corp | 処理フロー制御装置及びアプリケーション実行装置及び処理フロー制御システム及び処理フロー制御方法及び処理フロー制御プログラム |
| JP2010002963A (ja) * | 2008-06-18 | 2010-01-07 | Hitachi Ltd | サービス連携方法、サービス連携プログラム、ｂｐノード、および、サービス連携システム |
| WO2010018637A1 (ja) * | 2008-08-15 | 2010-02-18 | 富士通株式会社 | 業務フロー分散処理システム及び方法 |
| JP5024453B2 (ja) * | 2008-08-15 | 2012-09-12 | 富士通株式会社 | 業務フロー分散処理システム及び方法 |
| US8583754B2 (en) | 2008-08-15 | 2013-11-12 | Fujitsu Limited | Business flow distributed processing system and method |
| WO2011042969A1 (ja) * | 2009-10-07 | 2011-04-14 | Nakashima Hirofumi | P2p型のワークフローシステム |
| GB2486151A (en) * | 2009-10-07 | 2012-06-06 | Hirofumi Nakashima | P2p-type work flow system |
| CN102576429A (zh) * | 2009-10-07 | 2012-07-11 | 中岛裕文 | P2p型工作流系统、信息处理装置及工作流支持系统 |
| JP5117619B2 (ja) * | 2009-10-07 | 2013-01-16 | 裕文 中島 | Ｐ２ｐ型のワークフローシステム |
| JP2013012014A (ja) * | 2011-06-29 | 2013-01-17 | Yahoo Japan Corp | アプリケーションプラットフォーム装置、アプリケーションプラットフォームシステム及びアプリケーションプラットフォーム装置の動作方法 |
| CN102810070A (zh) * | 2012-07-16 | 2012-12-05 | 福建富士通信息软件有限公司 | 高性能业务能力封装流程引擎及其流程控制方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4352722B2 (ja) | 2009-10-28 |
| US20040167795A1 (en) | 2004-08-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004258823A (ja) | ビジネスプロセス処理方法およびシステム並びにその処理プログラム | |
| US6658483B1 (en) | Electronic transaction system and method and storage medium storing therein control program for executing format conversion in electronic transaction | |
| Tan et al. | A petri net-based method for compatibility analysis and composition of web services in business process execution language | |
| US7707587B2 (en) | Scheduler supporting web service invocation | |
| US7949999B1 (en) | Providing support for multiple interface access to software services | |
| US7120703B2 (en) | Transforming data automatically between communications parties in a computing network | |
| US6961735B2 (en) | Method and a bridge for coupling a server and a client of different object types | |
| Falazi et al. | Smart contract invocation protocol (SCIP): A protocol for the uniform integration of heterogeneous blockchain smart contracts | |
| US7343554B2 (en) | Mechanisms for supporting back button function of web browser as web service server in interaction with business process engine | |
| US20040205376A1 (en) | Service processing system, processing result management device and processing result checking method of service processing system | |
| JP2008003709A (ja) | 管理装置及びタスク管理方法及びプログラム | |
| JP4852906B2 (ja) | 連携処理システム及び装置 | |
| JP2006277644A (ja) | データ移行支援システム及びデータ移行支援プログラム | |
| KR100574158B1 (ko) | 프로세스 제어 시스템, 방법 및 컴퓨터 판독 가능 기록 매체 | |
| JP5294885B2 (ja) | サービス中継装置、サービス中継方法、この方法を実行するためのプログラム | |
| JP5737249B2 (ja) | 負荷シミュレーション装置、シミュレーション装置、負荷シミュレーション方法、シミュレーション方法及びプログラム | |
| JP2004185166A (ja) | サービス部品選択支援方法 | |
| Mateo et al. | A coloured Petri net approach to model and analyse stateful workflows based on WS-BPEL and WSRF | |
| JP2003122912A (ja) | 業務支援システム | |
| JP2004310742A (ja) | サービス処理方法及び装置 | |
| KR102659154B1 (ko) | 애플리케이션 서비스 제공 장치, 애플리케이션 서비스 제공 방법 및 애플리케이션 서비스를 제공하는 컴퓨터로 실행가능한 프로그램을 저장하는 저장매체 | |
| JP2000207474A (ja) | ワ―クフロ―支援実行システム | |
| JP2002288360A (ja) | ソフトウェア購入方法及びシステム | |
| Akram et al. | Grid Business Process: Case Study | |
| Cicirelli et al. | Integration and interoperability between Jini services and web services |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060216 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060420 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080728 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080819 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081020 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081118 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090119 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090421 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090622 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090707 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090720 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120807 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120807 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130807 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |