JP2002517825A - ワークフロー通信 - Google Patents

Abstract

(57)【要約】 コンピュータで実行されるワークフロー通信法が提供されている。方法には次のステップが含まれる。まず第一に、一つあるいはそれ以上のワークフローが実行される。それから、ワークフローで所定のイベントが発生すると、イベント・マネージャが始動する。最後に、イベントに基づいてメッセージが作成され、所定のグループに送られる。

Description

【発明の詳細な説明】

【０００１】 発明の技術分野 本発明は一般に、サプライチェーン、エンタープライズ、およびサイト・プラ
ンニングの分野に関するものであり、特に、ワークフロー通信方法に関するもの
である。

【０００２】 発明の背景 サプライチェーン、エンタープライズ、およびサイト・プランニングのアプリ
ケーションおよび環境は、意思決定支援と管理業務の補助のために製造エンティ
ティによって広範に使用されている。サプライチェーン、エンタープライズ、お
よびサイト・プランニングのための意思決定支援環境は、一体式シングルドメイ
ン環境から、一体式マルチドメイン環境に進化してきた。従来のプランニング・
ソフトウェア・アプリケーションは、種々の会社から提供される広範囲な製品に
利用できる。これらの意思決定支援ツールにより、エンティティは複雑な製造業
務をより効率的に管理することができる。しかしながら、サプライチェーンは、
一般に、複数の分散型異種プランニング環境を特徴としている。従って、サプラ
イチェーン・プランニングの問題に適用する場合には、一体式のアプリケーショ
ン・アーキテクチャに起因して従来環境の効果に制限がある。また、これらの問
題は、サプライチェーン全体の「所有者」が存在しない場合に悪化する。

【０００３】 プランニング環境の次の発展段階に望まれるのは、複数のドメインならびに複
数のエンジンおよび製品にまたがって、製品をサポートするマルチドメイン異種
アーキテクチャを確立することである。種々のプランニング環境をシームレス・
ソリューションに統合することにより、ドメイン間およびエンタープライズ間の
サプライチェーン・プランニングを実現できる。また、いくつかのプランニング
・アプリケーションによって提供される重要機能は、単なる追跡処理ではなく、
対象環境の最適化である。特に、アイ・ツー・テクノロジーズ社（Ｉ２ ＴＥＣ
ＨＮＯＬＯＧＩＥＳ）から市販されている製品ＲＨＹＴＨＭファミリが最適化機
能を提供している。しかしながら、エンタープライズまたはサプライチェーン・
レベルのプランニングに関しては、ＳＡＰから入手できるものなど多くの従来ア
プリケーションはエンタープライズ資源プランニング（ＥＲＰ）エンジンを使用
し、最適化を提供するものではない。

【０００４】 エンタープライズの成功または失敗は、エンタープライズ内での意思決定の品
質に大いに左右される可能性がある。したがって、エンタープライズの成功には
、エンタープライズ内での最適な意思決定を支援するアイ・ツー・テクノロジー
ズ社の製品ＲＨＹＴＨＭファミリなどの意思決定支援ソフトウェアが特に重要で
ある。一般に、最適な意思決定は、意思決定に達すると考えられる「世界」の広
がりである意思決定支援のドメインに関係している。例えば、行われようとして
いる意思決定は、工場が所定の期間中に生産しなくてはならない所定の品物の数
量であってもよい。「最適な」回答は、意思決定のドメインに依存している。ド
メインは、例えば、工場それ自体のみ、工場を含むサプライチェーン、エンター
プライズ全体、またはマルチエンタープライズ・サプライチェーンであってもよ
い（後の２つは、大きいドメインまたはマルチドメインと考えられる）。一般に
、意思決定支援のドメインが大きいほど、意思決定はより最適なものとなる。し
たがって、意思決定支援ソフトウェアが、意思決定過程で、より大きなドメイン
を範囲に含むことが望ましい。一つの解決策はワークフローを設計することであ
り、ワークフローは、何らかのタスクを実行するデータフローにより結合された
一組のアクティビティでもよい。ワークフローは、一つあるいはそれ以上のエン
タープライズにわたって一つあるいはそれ以上のワークフローエンジン上で実行
することができる。ワークフローは異なるエンジン及び異なるエンタープライズ
にわたって実行されるので、ワークフロー間あるいはワークフローとアプリケー
ションもしくはユーザ間でメッセージを送ることができる。必要なのは、従来の
サプライチェーン、エンタープライズ及びサイトプランニング環境にわたって有
利な通信法である。

【０００５】 コンピュータにより実行されるワークフロー通信法がここに提供されている。
この方法には次のステップが含まれている。まず第一に、一つあるいはそれ以上
のワークフローが実行される。それから、ワークフロー上の所定のイベントの発
生に関するイベント・マネージャが始動する。最後に、イベントに基づいてメッ
セージが作成され、所定のグループに送られる。

【０００６】 本発明の技術的利点は、区間パラダイムあるいは加入／発行パラダイムのいず
れかを使用してエンタープライズ内及びエンタープライズ間でメッセージを送る
機能にある。その他の技術上の利点は、以下の図、説明、および請求項から当業
者に容易に明らかになるであろう。

【０００７】 本発明ならびにその利点は、同様の参照符号によって同様の特徴を示す添付図
面とともに以下の説明を参照することによって更に完全に理解されるであろう。

【０００８】 発明の詳細な説明 意思決定支援プロセスの改良には、最適意思決定のためにエンタープライズ・
レベルおよびマルチエンタープライズ・レベルの意思決定支援を提供するための
拡張が含まれる。技術的および概念的には、エンタープライズ・レベルおよびマ
ルチエンタープライズ・レベルの意思決定支援を行うことは、ファクトリ・レベ
ルおよびサプライチェーン・レベルの意思決定支援を行うこととは異なっている
。その理由は、（エンタープライズまたはマルチエンタープライズ内の複数の事
業部門などの）マルチドメイン状況では、異なるドメインが異なる意思決定支援
ソフトウェアをしばしば使用しているからである。また、マルチドメイン状況で
は、あるドメインが別のドメインに特定の意思決定を強制することができない。
すなわち、この環境における最適意思決定支援は、強制とは反対の協定環境でし
ばしば実行される必要がある。

【０００９】 マルチドメイン状況における意思決定支援は、強制的な方法ではなく、意思決
定支援への協調的な方法を追求することによって達成できる。そのような環境を
実現するために、大規模な協調的意思決定を実現可能にする手助けとなるインタ
ーネット、Ｗｅｂ、ＪＡＶＡ、ＸＭＬ、ＣＯＲＢＡ等を含む種々の通信および分
散処理技術を利用できる。ＲＨＹＴＨＭ−ＧＬＯＢＡＬ ＣＯＬＬＡＢＯＲＡＴ
ＩＯＮ ＭＡＮＡＧＥＲ （ＧＣＭ）やＲＨＹＴＨＭ−ＧＬＯＢＡＬ ＣＯＬＬ
ＡＢＯＲＡＴＩＯＮ ＤＥＳＩＧＮＥＲ （ＧＣＤ）など、協調的な意思決定支
援方法を可能にする製品は、アイ・ツー・テクノロジーズ社からすぐに入手でき
る。

【００１０】 コラボレーション・システムとプロセス・コンポーネント 図１は、エンタープライズ・コラボレーションをサポートできるコンピュータ
実行アーキテクチャの一実施形態の図である。図示されているように、グローバ
ル意思決定支援アーキテクチャは、基礎をなすリンク・コンポーネント、ビジョ
ン・コンポーネント、グローバル・メッセージング・コンポーネント、およびデ
ータ・ウェアハウス・コンポーネントの上に構築できる。また、意志決定支援ア
ーキテクチャによってサポートされるグローバル・コラボレーション・デザイナ
（ＧＣＤ）およびグローバル・コラボレーション・マネージャ（ＧＣＭ）をコラ
ボレーションに含むことができる。グローバル・コラボレーション・デザイナは
、コラボレーションの設計と具体化に利用でき、グローバル・コラボレーション
・マネージャは、コラボレーションの実行に利用できる。この手法では、コラボ
レーションをモジュールと呼んで、別のバージョンを作ることができる。

【００１１】 図２は、グローバル・コラボレーション・フレームワークの構成要素の一実施
形態の図である。図示されているように、フレームワークにより、ハブ・エンタ
ープライズ２はスポーク・エンタープライズ４およびウェブ・エンタープライズ
６と協同作業することができる。ハブ・エンタープライズ２とスポーク・エンタ
ープライズ４はいずれもグローバル・コラボレーション・マネージャ８を含んで
いる。グローバル・コラボレーション・マネージャ８は、それぞれの内部グロー
バル・コラボレーション・ワークスペース１０に連結されて交信している。また
、外部グローバル・コラボレーション・ワークスペース１２が、ハブ・エンター
プライズ２、スポーク・エンタープライズ４、およびウェブ・エンタープライズ
６の間でデータを共有する手段となっている。ハブ・エンタープライズ２は、電
子データ交換（ＥＤＩ）プロセッサ１４を介して付加価値通信網（ＶＡＮ）と協
同作業をすることもできる。また、ハブ・エンタープライズ２は、グローバル・
メッセージ・バス１５を使って他のハブ・エンタープライズと通信したり協同作
業をすることができる。

【００１２】 稼働中、コラボレーションの主コントローラは、ハブ・エンタープライズ２の
ＧＣＭエンジン８であってもよい。ハブ／ハブの関係は、グローバル・メッセー
ジ・バス１５によって簡単化でき、また、ハブ／スポーク及びハブ／ウェブの関
係は、外部グローバル・コラボレーション・ワークスペース（ＧＣＷ）１２によ
って簡単化できる。図示されているように、ハブ・エンタープライズ２は、一般
に、内部ＧＣＷ１０と外部ＧＣＷ１２とを持つことができる。内部ＧＣＷ１０は
、内部ユーザ・インタフェースおよびＥＤＩプロセッサ１４とのデータの共有お
よび交換に利用できる。外部ＧＣＷ１２は、スポーク・エンタープライズ４よび
ウェブ・エンタープライズとのデータの共有および交換に利用できる。

【００１３】 安全性のために、外部ＧＣＷ１２は、ＤＭＺの中またはハブ・エンタープライ
ズ２の一連のファイアウォールの外側に設置できる。このように、ハブ・エンタ
ープライズ２の保護された一連のネットワークに外側から直接接続する必要が無
い。外部ＧＣＷは、例えば、ＩＩＯＰ、ＨＴＴＰ、およびＨＴＴＰＳの接続を受
け付けることができる。特に、後の２つの接続は、既存のファイアウォール構成
を相互接続するのに有用である。このように、クライアント側（スポーク・ノー
ドまたはウェブ・ノード）にもサーバ側（ハブ・ノード）にもファイアウォール
構成が不要であり、それにより、より速やかに展開できるソリューションを作る
ことができる。

【００１４】 図３は、特定のモジュールを構成するあるソフトウェア要素を強調表示させた
、図２のグローバル・コラボレーション・フレームワークの図である。図示され
ているように、グローバル・コラボレーション・マネージャ・モジュールのソフ
トウェアは、ハブ・エンジン８内、スポーク・エンジン８内、ハブ−ユーザ・ユ
ーザ・インタフェース（ＵＩ）内、スポーク−ユーザＵＩ内、およびウェブ−ノ
ードＵＩ内といった場所に存在しうる。また、モジュールは、ハブ・エンタープ
ライズ２およびスポーク・エンタープライズ４上のネイティブ・アプリケーショ
ン１７と通信できる。ネイティブ・アプリケーション１７との通信は、同期式（
点線）であっても、非同期式（実線）であってもよい。ネイティブ・アプリケー
ション１７との非同期通信は、図示されているように、内部ＧＣＷ１０によって
簡単化できる。また、ハブ・エンタープライズ２側にグローバル・シリーズ・デ
ータベース（ＧＳＤＢ）が存在していてもよい。

【００１５】 図４は、最適な意志決定を行うためにエンタープライズ内またはエンタープラ
イズ間の協同作業を可能にする、全体が１６で示されたシステムの一実施形態の
ブロック図である。図示されているように、システム１６は、コンピュータ・シ
ステム上で動作するハブ・エンジン内のプロセスとなりうるハブ・ノード１８を
含んでいる。ハブ・ノード１８は、やはりコンピュータ・システム上で動作する
ハブ・エンジン内のプロセスとなりうるスポーク・ノード２０と結合され、これ
と通信を行う。図示されているように、スポーク・ノード２０は、ハブ・ノード
１８のエンタープライズ境界２２の外側にあってもよい。ハブ・ノード１８は、
１つ以上のコンピュータ・システム上で動作するスポーク・エンジン内のプロセ
スとなりうる複数のスポーク・ノード２４と結合され、これと通信を行う。ハブ
・ノード１８は、コンピュータ・システム上で動作するウェブ・ブラウザ内のプ
ロセスとなりうる複数のウェブ・ノード２６と結合され、これと通信を行える。
また、ハブ・ノード１８は、ＥＤＩシステムとのゲートウェイとなりうるＥＤＩ
（電子データ交換）プロキシ２８に連結され、これと通信を行う。

【００１６】 ハブ・エンジンおよびスポーク・エンジンは、グローバル・コラボレーション
・ワークスペースと共に、グローバル・コラボレーション・マネージャの基本エ
ンティティとなりうる。この環境では、ハブ・エンジンがコラボレーションの主
コントローラである。ハブ・エンジンは、グローバル・コラボレーションならび
にローカル・コラボレーションの両方と連係動作できる。グローバル・コラボレ
ーションは、ハブ・ノード１８、スポーク・ノード２０と２４、およびウェブ・
ノード２６にまたがるものである。ローカル・コラボレーションは、任意の単一
機能ハブまたはスポーク／スポーク−グループ上で局部的に動作できる。これら
のコラボレーションは分散させることも可能であるが、ここでは単一エンタープ
ライズの範囲内にとどまっている。ハブ・エンジンは、ハブ−ユーザ・インタフ
ェース（ＵＩ）ならびにＥＤＩプロキシ２８のＶＡＮ−ＥＤＩプロセッサとも連
係動作できる。一実施形態において、ハブ・エンジンは、複数のコラボレーショ
ンならびに同一コラボレーションの複数のバージョンと同時に連係動作できるマ
ルチスレッド型のエンジンである。また、ハブ・エンジンは、コラボレーション
を動的にロードおよび実行できる。

【００１７】 スポーク・エンジンは、コラボレーションを開始させるように作用することも
可能である。この環境では、ハブ・エンジンとは異なり、スポーク・エンジンは
独立したエンティティではない。したがって、スポーク・エンジンは、ハブ・エ
ンジンと一緒でなければ、コラボレーションと連係動作できない。また、スポー
ク・エンジンは、別のスポーク・エンジンや別のウェブ・ノードと連係動作する
ことができない。ハブ・エンジンと同様に、スポーク・エンジンもマルチスレッ
ド化が可能で、複数のコラボレーションならびに同一コラボレーションの複数の
バージョンと同時に連係動作できる。スポーク・エンジンも、コラボレーション
を動的にロードおよび実行できる。

【００１８】 図５は、グローバル・コラボレーション・ワークスペース３０の使用法の一実
施形態のブロック図である。図５で、グローバル・コラボレーション・ワークス
ペース３０は、コラボレーション内の種々のエンティティ間でデータ／オブジェ
クトを共有するために使用される主エンティティである。図示されているように
、ワークスペース３０は、グローバル・コラボレーション・マネージャ（ＧＣＭ
）３２、ローカル・システム３４、ウェブ・サーバ３６、ウェブ・インタフェー
ス３７、およびネイティブ・アプリケーション３８と接続して機能できる。一般
に、オブジェクトは、一方のエンティティによってグローバル・コラボレーショ
ン・ワークスペース３０に配置され、他方のエンティティによって検索されるこ
とが可能である。検索は、照会または登録によって達成できる。このように、グ
ローバル・コラボレーション・ワークスペース３０は、データベースならびにメ
ッセージ・バスの属性を組み合わせている。

【００１９】 グローバル・コラボレーション・ワークスペースは、メモリ内スロットまたは
永久スロットの階層として編成できる。スロットは、待機式のものであっても通
常のものであってもよく、各スロットに細かい許可段階を付けることもできる。
許可段階は、ユーザ別、動作別に割り当てることができる。主な動作は、読出、
書込、取込、および登録である。

【００２０】 メモリ内スロットは、データを揮発性メモリに保持する。メモリ内スロットか
らの書込および検索は極めて高速であるが、グローバル・コラボレーション・ワ
ークスペース３０が停止した場合にデータが失われる。メモリ内スロットと共に
使用されるとき、グローバル・コラボレーション・ワークスペース３０は、セキ
ュリティとメッセージング機能とを備えた高速で確実なメモリ内オブジェクト・
データベースと考えることができる。一方、永久スロットは、そのデータを安定
記憶機構に保持する。永久スロットからの書込および検索はメモリ内スロットか
らの場合よりも遅いが、グローバル・コラボレーション・ワークスペース３０が
停止した場合でもデータは失われない。

【００２１】 メモリ内スロットを使用するか、永久スロットを使用するかは、アプリケーシ
ョンに応じて決定できる。グローバル・コラボレーション・ワークスペース３０
は、オブジェクトの形でデータを記憶するもので、Ｊａｖａオブジェクト、ＣＯ
ＲＢＡオブジェクト、または任意のバイト・アレイを記憶することができる。グ
ローバル・コラボレーション・ワークスペース３０は、メモリ内の各機能と結合
されて、アイ・ツー・テクノロジーズ社のサプライチェーン・プランナとファク
トリ・プランナなど他のオブジェクト指向メモリ内エンジン間の高速データ共用
機構に適したグローバル・コラボレーション・ワークスペース３０を形成する。

【００２２】 グローバル・コラボレーション・デザイナ（ＧＣＤ）は、コラボレーション設
計者が、グローバル・コラボレーション・マネージャを使用して実行されるコラ
ボレーションを対話式に設計、具体化、および配備できるようにするツールであ
る。グローバル・コラボレーション・デザイナの出力は、グローバル・コラボレ
ーション・マネージャが自動的にロードおよび実行できるコードである。グロー
バル・コラボレーション・デザイナにより、設計者は新しいコラボレーションを
作成し、既存のコラボレーションを検索し、別のバージョンのコラボレーション
を作ることができる。グローバル・コラボレーション・デザイナにより、設計者
は、コラボレーション用のハブ・アンド・スポーク式ネットワークを設計し、コ
ラボレーションの事象およびメッセージを設計することもできる。グローバル・
コラボレーション・デザイナは、標準的なオブジェクト・ライブラリと標準的な
コンポーネント・ライブラリとを統合させて、グローバル・コラボレーション・
デザイナの中でより使いやすくすることができる。グローバル・コラボレーショ
ン・デザイナは、同期、非同期、サブワークフロー、ＡＮＤ分割、ＯＲ分割、同
期結合、ヘテロキャスト（heterocast）分割、ヘテロキャスト結合等を備えた高
度なマルチエンタープライズ・ワークフローを作成するために利用できる。グロ
ーバル・ワークフローおよび局所ワークフローのいずれも作成可能である。グロ
ーバル・コラボレーション・デザイナは、コラボレーションの自動検証と、グロ
ーバル・コラボレーション・マネージャによって実行されるコードの自動コード
生成とを実行できる。生成されたコードは、所望であれば手作業で編集できる。
また、グローバル・コラボレーション・デザイナは、セキュリティ・マネージャ
構成およびグローバル・コラボレーション・ワークスペース構成の生成を含むコ
ラボレーションの具体例を生成できる。

【００２３】 図６は、コラボレーションのライフサイクルの一実施形態の図である。図示さ
れているように、ステップ４０で、グローバル・コラボレーション・デザイナを
使用してコラボレーションを設計できる。ステップ４２で、グローバル・コラボ
レーション・デザイナを使用してコラボレーションを具体化できる。次に、ステ
ップ４４で、グローバル・コラボレーション・デザイナとグローバル・コラボレ
ーション・マネージャを使って、具体化されたコラボレーションを配備できる。
配備後、ステップ４６でグローバル・コラボレーション・マネージャを使ってコ
ラボレーションを実行できる。その後、新しい具体例を生成できるし、コラボレ
ーションの新しいバージョンを作成することもできる。新しい具体例を生成する
には、ステップ４２に戻る。新バージョンの場合は、ステップ４８でグローバル
・コラボレーション・デザイナを使用してコラボレーションを修正できる。

【００２４】 シングルドメイン意思決定支援からマルチドメイン意思決定支援への拡張は複
雑になりうる。特に、マルチドメイン意思決定支援によって引き起こされる多数
の問題と、エンタープライズ内およびエンタープライズ間のコラボレーションが
最適意思決定を行うことを可能にする本発明のシステムおよびプロセスが、その
ような問題にどのように取り組んだかを以下の考察部分で述べる。

【００２５】 表現の異質性 コラボレーションの１つの問題は、複数のエンタープライズにわたる異質な表
現間に橋をかけることである。コラボレーションが正常に行われる以前に、エン
タープライズ間の異質な表現に橋をかける必要がある。エンタープライズは、し
ばしば同じデータを別な形で表現する。これらの違いは、意味論的な違いから、
技術的な違い、命名の違い等にまで及ぶ。これらの違いに橋をかける１つの明ら
かな解決策は、標準化である。しかしながら、これにより、どの規格に合わせる
かという問題がすぐに生じる。本発明のシステムおよびプロセスでは、そのよう
な要件を回避できる。

【００２６】 取り組む必要がある３つの関連基準カテゴリが存在しうることに注意されたい
。これら３つのカテゴリは、形式基準、転送基準、および意味基準である。形式
基準は、データ／オブジェクトを符号化する技術上の形式のことを言う。例とし
て、ＸＭＬ、Ｊａｖａ Ｓｅｒｉａｌ Ｓｔｒｅａｍｓ、ＩＩＯＰ Ｓｅｒｉａ
ｌ Ｓｔｒｅａｍｓ、およびＥＤＩ形式などがある。転送基準は、データを次々
に伝達するために使用される。これらは、ＨＴＴＰ、ＩＩＯＰ、ＲＭＩ、ＤＣＯ
Ｍ、ＦＴＰ， 付加価値通信網、 ＭＱＳｅｒｉｅｓのような非同期メッセージ
・バス等を含むことができる。第３の意味基準は、データの意味内容を記述する
方法である。例として、ＥＤＩ、Ｉ２ ＣＯＭＭＯＮ ＤＡＴＡ ＭＯＤＥＬ（
ＣＤＭ）などがある。

【００２７】 この見解で基準について考えると、前述の問題は自ずと理解できる。既存の基
準の多くが前述の二つ以上のカテゴリを扱っているが、種々の基準の考察は、ど
のカテゴリが論じられるかの類別を行わないことから、今日、多くの混乱を招い
ている。例えば、ＥＤＩは本質的には意味基準であるが、一般に形式基準（ＥＤ
Ｉファイル形式）および転送基準（付加価値通信網）も含んでいる。これが理解
されれば、ＥＤＩ意味基準を他の２つから切り離せることが明らかになる。した
がって、意味ＥＤＩオブジェクトは、Ｊａｖａ Ｓｅｒｉａｌ Ｓｔｒｅａｍｓ
などの別の形式に符号化でき、ＨＴＴＰなどの他の転送基準で転送できる。同様
に、ＸＭＬは本質的には、種々の意味基準を符号化するために利用できる形式基
準である。ＥＤＩをＸＭＬに符号化するための作業が進められている。

【００２８】 いくつかの形式基準は、ＸＭＬ、ＥＤＩ形式、Ｊａｖａ Ｓｅｒｉａｌ Ｓｔ
ｒｅａｍｓ（Ｊａｖａ言語やＪａｖａプラットフォームとの混乱を避けるために
、Ｊａｖａ形式と呼ぶ） およびＩＩＯＰ Ｓｅｒｉａｌ Ｓｔｒｅａｍｓなど
、現在のグローバル・コラボレーション・マネージャでサポートできる。一実施
形態では、これらのうちのＪａｖａ形式が基本形式であり、その他が派生形式で
ある。基本形式としてＪａｖａ形式が選択されたのは、Ｊａｖａ形式が他の形式
を生成する挙動を含むことができるからである。ＸＭＬ、ＥＤＩ、およびＩＩＯ
Ｐ形式は、Ｊａｖａ形式から派生させることができる。

【００２９】 図７は、アイ・ツー・テクノロジーズ社からの共通ソフトがリレーションシッ
プの両側に存在している状況と、していない状況の図である。例えば、図示され
ているように、両側にＲＨＹＴＨＭ ＧＬＯＢＡＬ ＣＯＬＬＡＢＯＲＡＴＩＯ
Ｎ ＭＡＮＡＧＥＲがある場合、中間形式に変換しても何も得られない。これは
不要な非能率を招き、データ（オブジェクトではない）だけが交換可能であり、
アプリケーションの範囲を限定するものである。したがって、両側に同じソフト
ウェアが存在する場合、２進Ｊａｖａオブジェクトを直接に交換できる。他方、
例えば、ＲＨＹＴＨＭ ＧＬＯＢＡＬ ＣＯＬＬＡＢＯＲＡＴＩＯＮ ＭＡＮＡ
ＧＥＲが片側にしか存在しない場合、ＸＭＬまたはＥＤＩ形式の「オブジェクト
」を生成（アウトバウンド）および解釈（インバウンド）できる。

【００３０】 転送基準に関して述べると、当該グローバル・コラボレーション・マネージャ
は、ＨＴＴＰ、ＩＩＯＰ、および非同期メッセージ・バスを含む種々の転送基準
をサポートできる。以下に多関係タイプの処理について詳述する。

【００３１】 意味基準について述べると、当該グローバル・コラボレーション・マネージャ
は主として２つの意味基準、ＥＤＩとＲＨＹＴＨＭ−ＣＤＭ、をサポートできる
。ＥＤＩがサポート可能であるのは、ＥＤＩが一般に最も普及している意味基準
だからである。しかしながら、これには、プランニング・ドメインの深い部分を
範囲に含まないという欠点（数ある中で）がある。他方、ＲＨＹＴＨＭ−ＣＤＭ
は、プランニング・ドメインの深い部分を範囲に含み、マルチエンタープライズ
意思決定支援を実行するのに適切な構造を提供する。また、この形式は、アイ・
ツー・テクノロジーズ社のプランニング・エンジンのすべてによってサポートさ
れている。

【００３２】 一般に、ＥＤＩなどの公認基準の問題の１つは、エンタープライズが交換した
い種類のデータ／オブジェクトに十分に対応していない場合があることである。
また、特定のオブジェクト上で標準化するために基準本体を待つことがオプショ
ンでないことがあり、公認基準を使用することによってサプライチェーンが特に
競争に有利な利点を有しない。前述および他の理由により、当該グローバル・コ
ラボレーション・マネージャは、独自のコミュニティ基準をサポートすることに
よって別の標準化法をサポートしている。エンタープライズのコミュニティは、
例えばＲＨＹＴＨＭ−ＧＣＤを利用して、当該コミュニティだけに関連がある基
準セットを考案することができる。ＲＨＹＴＨＭ−ＧＣＤは、これらの独自のコ
ミュニティ基準をサポートし、実施する。ＲＨＹＴＨＭ−ＧＣＤは、独自のコミ
ュニティ基準を構成しうるビルディング・ブロック・オブジェクトから成るライ
ブラリもサポートする。独自のコミュニティ基準は、当該エンタープライズが交
換したい種類のデータ／オブジェクトを正確に対象として含むように設計できる
；特定の基準に同意する必要があるのは関係当事者だけなので、プロセスが基準
本体を待つよりもはるかに速い；パートナーの種々のカテゴリに合わせて種々の
基準を（極端な場合はパートナー毎に別々の基準を）開発できる；競争相手を越
える競争利益をサプライチェーンに与える基準を開発できる等、数多くの利点が
ある。

【００３３】 多関係タイプ コラボレーションを可能にするための別の問題は、多関係タイプの扱いである
。エンタープライズは、そのパートナーとの間に種々のタイプの関係を持ってい
る。関係が異なるケースとして、一方は大きな取引相手間、他方は小さな取引相
手間の場合；サプライチェーンに与える影響がほぼ同等であるエンタープライズ
間と、サプライチェーンに与える影響が等しくないエンタープライズ間の場合；
一方は高度な技術程度を備えたエンタープライズ間、他方は等しくない技術程度
を備えたエンタープライズ間、がある。理解される通り、これらの異なる関係タ
イプは別々に処理されるべきである。

【００３４】 当該グローバル・コラボレーション・マネージャは、エンタープライズ間の関
係を、上に説明され図４に記載されているハブ・アンド・スポーク式のネットワ
ークとして構成できる。当該実施形態の４タイプの関係は、ハブ／ウェブ、ハブ
／ＶＡＮ−ＥＤＩ、ハブ／スポーク、およびハブ／ハブである。各関係タイプに
、その適切用途がある。

【００３５】 ハブ／ウェブについて述べると、人々が今日の電子商取引について話すとき、
ウェブ・ブラウザといくつかの集中サーバとが通信するアーキテクチャを含意す
ることが多い。このアーキテクチャは、このアーキテクチャをサポートするイン
フラストラクチャが一般に既に所定の位置にある、サーバ側に管理を集中させる
ことができるなど、いくつかの利点を有している。しかしながら、このアーキテ
クチャは、ウェブ・ブラウザ側に人間が存在している必要がある、という大きな
欠点も備えている。そのため、システム間の自動化が不可能である。前述および
他の賛否に基づき、この関係タイプは、エンタープライズが、重要度の低いパー
トナーまたは技術程度の低いパートナーとデータ交換する必要がある場合に適切
でありうる。

【００３６】 ハブ／ＶＡＮ−ＥＤＩについて述べると、今日、エンタープライズ間の電子取
引の大部分は、付加価値ネットワーク全体にＥＤＩを送ることによって行われて
いる。この方法の利点は、システム間の統合が可能であり、今日、一般にサポー
トされていることである。この方法の欠点は、独自のＶＡＮにデータを送信する
ための多大なコスト、真の標準化が存在しないことによる高い管理費、真の「基
準」をエンタープライズに適した形に変換するためだけのサード・パーティ・ツ
ールが必要であること、システムと人とを統合するためのサポートが存在しない
こと、独自基準または企業基準のサポートが存在しないことである。前述および
他の賛否両論に基づき、この関係タイプは、レガシーＶＡＮ−ＥＤＩ環境をサポ
ートするときに適切でありうる。

【００３７】 ハブ／スポークについて述べると、この関係タイプも、ＶＡＮ−ＥＤＩのよう
にシステム間の統合を可能にする。構造的には、ハブ／スポークは、ハブ・エン
ジンとスポーク・エンジンとの間のコラボレーションである。ハブ／スポーク関
係は、ＶＡＮ−ＥＤＩと比較し、公衆網の利用によりネットワーク費用を削減で
きる、ハブ／スポーク関係インフラストラクチャの大部分を一元的に配備して管
理できるので管理費がＶＡＮ−ＥＤＩよりはるかに安い、（ただのデータに加え
）真のオブジェクトを交換により、更に高度なコラボレーションが可能となる、
ＥＤＩ、Ｉ２−ＣＤＭ、独自コミュニティ基準を含む複数の意味基準をサポート
できる、という利点を有することができる。前述の特徴に基づき、ハブ／スポー
クの関係は、高度なシステム間コラボレーションを実行することを望むエンター
プライズ間に適切でありうる。また、エンタープライズのいずれかにもアイ・ツ
ー・テクノロジーズ社のソフトウェアが存在していない場合にも適切でありうる
。これは、ハブ・エンタープライズによってハブ／スポークの関係が一元的に配
備されるからである。

【００３８】 ハブ／ハブについて述べると、この関係は、ハブとスポーク・エンジン間では
なく２つのハブ・エンジン間で実行されることを除き、ハブ／スポークと同様で
ある。この特徴に基づき、ハブ／ハブの関係は、高度なシステム間コラボレーシ
ョンを実行することを望むエンタープライズ間に適切でありうる。また、ハブ／
ハブの関係は、２つのエンタープライズがそれぞれ別々にＲＨＹＴＨＭ−ＧＣＭ
を購入して、ハブ・エンジンをセットアップした場合にも適切でありうる。

【００３９】 ハブ・エンジンとスポーク・エンジンの間には、いくつかの違いがある。一般
に、ハブ・エンジンの機能は、スポーク・エンジンの機能のスーパーセットであ
る。次の表に、いくつかの違いの例を示す。

【００４０】

【表１】

【００４１】 セキュリティ コラボレーションの別の問題は、広範囲なセキュリティを提供するという課題
である。エンタープライズが効率的に協同作業できる以前に、セキュリティの問
題に取り組む必要がある。協同作業環境では、セキュリティに対して数多くの異
なる側面が存在する。マルチエンタープライズ協同作業フレームワークは、これ
ら異なる側面のすべてに取り組むべきである。協同的なセキュリティフレームワ
ークに対する要件として、二者間で交換されるデータは二者のみが見るべきであ
る、二者間で交換されるデータは、不正操作がきかないようになっていなくては
ならない、エンタープライズは、パートナーが、エンタープライズの要求した本
人であることを確認できなくてはらない、フレームワークは相手ネットワークに
新しいセキュリティ・ホールを持ち込んではならない、フレームワークはセット
アップおよび管理が比較的簡単でなくてはならない、といったことを含むことが
できる。

【００４２】 安全確実な協同作業フレームワークは、前述の要件に取り組む総合的なセキュ
リティ戦略を実施することによって実現できる。一実施形態において、この戦略
は、技術的セキュリティ、許可フレームワーク、およびデータ分割という３種類
の側面を有する。

【００４３】 技術セキュリティは、セキュリティを保証するために使用される技術的手段の
ことである。このセキュリティは、プライバシー、認証、およびデータ保全性を
提供するために利用できる。プライバシーは、無許可の人間がデータを見ること
ができないようにするものである。認証は、コラボレーションの当事者が、本当
にコラボレーション当事者となることを要求した本人であるかどうかの認証を含
む。データ保全性は、無許可の人間が送信データをいずれかの方法で変更できな
いようにすることを含む。

【００４４】 厳密なセキュリティ方法は、先に述べた関係タイプに基づいて変わることがで
きる。例えば１つの手法を次の表に詳述する。

【００４５】

【表２】

【００４６】 表から分かるように、ハブ／ＶＡＮ ＥＤＩを除くすべての関係タイプは、Ｓ
ＳＬ ３．０を通じてセキュリティを支援できる。

【００４７】 ＳＳＬ ３．０は、ソケットをベースにしている接続に対する公開鍵暗号をサ
ポートするために使用される業界基準プロトコルであり、プライバシー、サーバ
と同様のクライアント認証、データ保全性、および認可管理を提供する。ＳＳＬ
３．０は、ＲＳＡ法およびディッフィ−ヘルマン法を含むいくつかの公開鍵暗
号化アルゴリズムを組み込むことができる高レベルのプロトコルである。

【００４８】 ＳＳＬ接続が完了すると、次の段階はユーザ名−パスワードの認証である。こ
れは、ＳＳＬ ３．０自体が提供する認証を越える認証である。パスワードは、
ＰＫＣＳ５パスワードを使用した暗号化（ＲＳＡ標準）を使用して記憶できる。
ユーザまたはスポークの認証がなされると、アクセス・トークンに戻される。こ
のアクセス・トークンは、管理者が指定可能な存続時間を有する。ユーザは、ア
クセス・トークンの有効期限の時間内でシステムにアクセスできる。これは、ア
クセス毎の認証が必要でないという有益な効果がある。アクセスされる各アプリ
ケーションは、セキュリティ・マネージャの署名（セキュリティ・マネージャの
専用鍵を使って暗号化されたダイジェスト）を確認することによって、アクセス
・トークンを認証する。

【００４９】 技術的セキュリティ・フレームワークは、セキュリティ機構の一部である。他
の部分は、コラボレーション自体の設計と一緒に行わなくてはならない。フレー
ムワークにより、エンタープライズは、他のエンタープライズが実行可能な種々
のアクティビティに対して簡単に許可を付与することができる。グローバル・コ
ラボレーション・ワークスペースは、階層内の種々のデータ要素に対して別個の
許可を付ける階層許可モデルをサポートできる。特に、ユーザ固有およびスポー
ク固有の読出、書込、取込、および登録許可をサポートできる。従って、エンタ
ープライズは、誰がどのデータを読み出すことができ、誰がどのデータを書き込
むことができ、誰がどのデータを取り込むことができ、誰がどのデータの書込通
知を登録できるか、を細かく調整することができる。

【００５０】 コラボレーション・フレームワーク・セキュリティ戦略の第３の要素は、種々
のコラボレーション・ワークスペースにデータを分割する機能である。特に、協
同作業ワークスペースは、内部協同作業ワークスペースと外部協同作業ワークス
ペースに分割され、関係者が真に共有する必要があるデータだけが外部協同作業
ワークスペースにある。その他は、内部協同作業ワークスペースにある。外部協
同作業ワークスペースは、一連のファイアウォールの外側、あるいはエクストラ
ネットまたはＤＭＺの中に存在するように設計されている。コラボレーション・
フレームワークの設計に際し、（そうすることもできるが）一連のファイアウォ
ールを通じて外部協同作業ワークスペースをイントラネットに接続する必要がな
い。

【００５１】 一実施形態において、グローバル・コラボレーションは、外部および内部協同
作業ワークスペースの両方を使用できる。局所コラボレーションは内部協同作業
ワークスペースしか使用しないので、相手エンタープライズからは全く見えない
。グローバル・コラボレーションの場合でさえ、関連部分が使用するのは外部コ
ラボレーション・ワークスペースである。また、前述の許可フレームワークのた
めに、それぞれの相手エンタープライズは、それ自身のデータしか見ること（書
込、読出、取込、登録）ができない。

【００５２】 図８は、ハブ／スポークおよびハブ／ウェブの場合のセキュリティ構成の一実
施形態のブロック図である。図示されているように、ハブ・エンタープライズ５
０は、内部グローバル・コラボレーション・ワークスペース５２と外部グローバ
ル・コラボレーション・ワークスペース５４に連結され、これらと通信する。ス
ポーク・エンタープライズ５６とウェブ・エンタープライズ５８は、ウェブサー
バ６０を通じて、外部グローバル・コラボレーション・ワークスペース５４に接
続されている。ハブ・エンタープライズ５０と同様に、スポーク・エンタープラ
イズ５６は、内部グローバル・コラボレーション・ワークスペース６２を有する
。エンタープライズ５０、５６、および５８は、関連するファイアウォールによ
って保護でき、また、ウェブ・サーバ６０と外部グローバル・コラボレーション
・ワークスペース５４とによって形成されているエクストラネットは、フィルタ
リング・ルータとＨＴＴＰに適用されるＳＳＬ ３．０を介した通信とによって
保護できる。

【００５３】 図９は、ハブ／ハブの場合のセキュリティ構成の一実施形態のブロック図であ
る。図示されているように、ハブ・エンタープライズ６４とハブ・エンタープラ
イズ６６は、ＳＳＬ ３．０保護ＴＣＰ／ＩＰの接続により通信できる。この通
信は、別々のグローバル・メッセージ・ブローカ６８と６９の間で可能である。
両方のハブ・エンタープライズ６４と６６は、図示されているように、ファイア
ウォールで保護されている。

【００５４】 エンタープライズ間のワークフロー マルチエンタープライズ意思決定支援の問題の１つは、閉ループのコラボレー
ションが無いことである。その代わり、データは、あるエンタープライズから次
のエンタープライズに、整合のとれたワークフローなしで送られる。閉ループ・
コラボレーションを実現するために、マルチエンタープライズのワークフローの
作成を支援する必要がある。当該グローバル・コラボレーション・マネージャお
よびグローバル・コラボレーション・デザイナにより、高度なマルチエンタープ
ライズ・ワークフローを構築、配備、監視、および変更することが可能になる。

【００５５】 一般に、「ワークフロー」は、いくつかのタスクを一緒に実行するデータフロ
ーによってつなぎ合わされた「アクティビティ」セットでありうる。ワークフロ
ーは、一般に、ワークフロー・エンジン上で実行される。「分散型ワークフロー
」とは、複数のワークフロー・エンジン上で実行されるワークフローのことを言
う。言い換えると、ワークフローのいろいろな部分が、別々のエンジン上で実行
される、ということである。「ノード」は、分散型ワークフローの種々のワーク
フロー・エンジンが実行される抽象的なエンティティのことを言い、「ノード・
グループ」は、何らかの特徴毎に分類されたノード・セットでありうる。「マル
チエンタープライズ分散型ワークフロー」は、ノードがエンタープライズである
分散型ワークフローでありうる。

【００５６】 ワークフローのパラメータ化は、エンタープライズ・コラボレーションにとっ
て重要でありうる。「パラメトリック・ワークフロー」は、何らかの変数につい
てパラメータ化されたワークフローであり、正規のもの、または分配されるもの
でありうる。種々の値のパラメータ変数を利用してパラメータ・ワークフローを
具体化することにより、ワークフローの種々の具体例ができる。「ノード・グル
ープ内のノードについてパラメータ化された分散型ワークフロー」とは、ワーク
フローのパラメータが、ノード・グループ内のノードである分散型ワークフロー
のことを言う。従って、ワークフローが具体化されるとき、ワークフローは、ノ
ード・グループ内の特定ノードに合わせて調整される。

【００５７】 当該グローバル・コラボレーションによってサポートできる、ワークフローに
とって重要ないくつかの特性がある。これらのワークフローは強分類される（st
rongly typed）。強分類を行うことは、堅固で誤りのないワークフローを生成す
る上で不可欠でありうる。本質的に、強分類を行うことによってメッセージタイ
プは設計時に保証される。例えば、資材明細書を送信するようにワークフローを
設計する場合、強分類を行うことにより、資材明細書以外のオブジェクトの送信
が物理的に不可能になる。グローバル・コラボレーション・デザイナを利用して
設計され、グローバル・コラボレーション・マネージャによって実行されるワー
クフローの場合、正しくないタイプのオブジェクトを送ることを不可能にするこ
とさえも可能である。この機能は、堅固で誤りのないワークフローを作る上で重
要である。

【００５８】 強分類にもかかわらず、例えば、不適切なオブジェクト・タイプがワークフロ
ーを通過できると考えられる２つの径路がある。ワークフローの設計者側の誤り
によるものと、ワークフローを傷つけようとする誰かの悪意のある試みによるも
のである。その両方の径路に対し、対処可能である。第１のものは、設計時の誤
りが、そのような径路を通過できないようにすることによって対処できる。第２
のものは、前述の公開鍵暗号化または他の暗号化方式（保全特性）を使用するこ
とにより、データフローに対する不正操作を防止することによって対処できる。

【００５９】 別の重要特性は、グループについてパラメータ化されたワークフローのサポー
トである。マルチエンタープライズ・ワークフローの中には、多数のエンタープ
ライズを含んでいるものがある。そのような場合、パートナー毎に個別化したワ
ークフローを作成することは無理になる。そうではなく、パートナーのグループ
についてパラメータ化されるワークフローを作成することが有利である。例えば
、調達部門において、２つのグループが第１供給元と第２供給元であってもよい
。第１供給元グループは、あるタイプのワークフローを有し、第２供給元グルー
プは別のタイプのワークフローを有することができる。グループベースのワーク
フローは、実行時に、グループ・メンバー向けに実際のワークフローを作成でき
るという意味で、パラメトリックでありうる。

【００６０】 マルチエンタープライズ環境では、エンタープライズは、例えば、潜在的に数
百または数千の他のエンタープライズと協同作業することもできる。それぞれの
コラボレーションまたはマルチエンタープライズ・ワークフローは、潜在的に（
そして、一般に）独自のものである。しかしながら、エンタープライズのパート
ナーとの数千の専用ワークフローを設計することは望ましくないし、実現可能で
もない。他方、これらのワークフローの多くは、基礎となるパラメータ化された
ワークフロー上ではパラメータ的変形例であるに過ぎない。例えば、企業Ａは、
小売業者、代理店、直売所等と（販売に関して）協同作業しているかもしれない
。従って、種々のパートナーをグループ化することは意味がある。グループ化の
例として、ウォールマート社（ＷａｌＭａｒｔ）；シアーズ社（Ｓｅａｒｓ）；
ウォールマート社とシアーズ社を除く他の小売業者（グループ）；第１代理店（
グループ）と第２代理店（グループ）にすることもできる。ここで、例えば、第
１代理店グループの全メンバーとのワークフローは、当該グループの特定代理店
についてパラメータ化された基礎パラメトリック分散型ワークフローを変化させ
たものである。

【００６１】 グループについてパラメータ化されたワークフローは、ＨＥＴＥＲＯＣＡＳＴ
ＩＮＧワークフロー定義法によってサポートできる。ＨＥＴＥＲＯＣＡＳＴＩＮ
Ｇワークフロー定義法は一般に、パラメータの差に基づいて異種のワークフロー
を具体化するためにパラメータ化されたワークフロー定義を使用するものである
。このように、ＨＥＴＥＲＯＣＡＳＴＩＮＧ定義法により、非パラメータ的分散
型ワークフローを（ビジュアル・デザイン・ツールを通じて）ノード・グループ
内のノードに対して容易にパラメータ化することができる。この定義を実施する
ために、ＨＥＴＥＲＯＣＡＳＴ分割アクティビティとＨＥＴＥＲＯＣＡＳＴ結合
アクティビティという２つのワークフロー・アクティビティを使用できる。ＨＥ
ＴＥＲＯＣＡＳＴ分割とＨＥＴＥＲＯＣＡＳＴ結合の間のすべてのアクティビテ
ィは、これらのアクティビティに該当するノード・グループのノードについてパ
ラメータ化される。

【００６２】 図１０は、複数のグループについてのパラメータ化を含むエンタープライズ間
ワークフロー設計の一実施形態の図である。図示されているように、ワークフロ
ーは、何らかの事象を待つ受信アクティビティ７０から開始できる。アクティビ
ティ７０は、並列アクティビティ７１に連結され、並列アクティビティ７１はサ
ブ・ワークフロー７２とヘテロキャスト分割７３と連結している。サブ・ワーク
フロー自体は、ワークフロー定義を含むことができる。ＨＥＴＥＲＯＣＡＳＴＩ
ＮＧについて述べると、ヘテロキャスト分割７３後のワークフローは、パラメー
タ化される。従って、図１０の例では、アクティビティ７４は、パラメ−タ化ア
クティビティである。アクティビティ７４の後、ヘテロキャスト結合７５は、ア
クティビティ７４からのフローを受け入れる。サブ・ワークフロー７２とヘテロ
キャスト結合７５は、同期または非同期結合７６に連結されており、同期または
非同期結合７６は、さらに統合イベント７７（例えば、マルチキャスティング）
に連結されている。図１０のようなワークフローは、当該グローバル・コラボレ
ーション・デザイナを使用して設計でき、各ワークフローがエンタープライズ間
意思決定支援できるようにする。ワークフローは、当該グローバル・コラボレー
ション・マネージャを通じて具体化および実行できる。

【００６３】 図１１は、ワークフローの設計を修正する変更管理の一実施形態の図である。
図示されているように、最初のワークフローの設計は、並列アクティビティ分割
７１に連結されたイベント７０を有することができる。アクティビティ分割７１
とアクティビティ結合７６の間には、例えば、２つのアクティビティ７８があっ
てもよい。このワークフローは、設計後、グローバル・コラボレーション・マネ
ージャによって具体化および実行できる。ワークフローに対して変更を行う必要
がある場合、グローバル・コラボレーション・デザイナは、変更時のトラブルを
著しく軽減する。例えば、新規アクティビティ７９を分割７１と結合７６の間に
追加できる。その後、ワークフローを一元的に再具体化して実行することができ
る。

【００６４】 特に、ＨＥＴＥＲＯＣＡＳＴ法により、ノード・グループのノードについてパ
ラメータ化した分散型ワークフローを構築できる。これにより、個々のグループ
・メンバーの個々のワークフローの設計に莫大な生産利得を与えることができる
。また、この手法により、数百または数千の可能なパートナーと共に、高度なエ
ンタープライズ間ワークフローの設計および試作が高速化される。この手法は、
全く同じメッセージを種々のノード（パートナー）に送出する従来の「マルチキ
ャスト」と区別されるべきである。本質的には、マルチキャストでは、複数のノ
ードに対して全く同じように実行される単一ワークフローが設計される。これは
、ワークフロー実行対象のノードに基づいてワークフローが違ったように実行さ
れるＨＥＴＥＲＯＣＡＳＴＩＮＧ法とは異なっている。

【００６５】 第３の重要な特徴は、役割ベースのワークフローのサポートである。役割ベー
スのワークフローにより、一般的な役割を利用してワークフローを指定できる。
この機能により、種々の筋書で具体化できる一般的な、すなわちテンプレート付
きのワークフローを作ることができる。例えば、役割タイプを、パートナー役、
スポーク役、スポーク・グループ役、ウェブ役、ウェブ・グループ役、ユーザ役
にしてもよい。役割の例として、パートナー役とは、パートナーが果たす種々の
役割のことを言う。したがって、調達の場合のパートナーの役割の１つは、第１
供給元と第２供給元である。

【００６６】 役割ベースのワークフローは、ワークフローの設計および実行に３段階の概念
をもたらすことができる。設計段階は、役割ベースのワークフローを規定する段
階である。具体化段階は、役割を具体例に割り当てる段階である。例えば、第１
供給元を第１の会社に割り当て、ＰＯ承認者をジョン・ドゥに割り当てることも
できる。第３の実行時段階は、具体化されたワークフローを実行する段階である
。

【００６７】 更に別の重要な特徴は、自動化ワークフローとユーザ指向ワークフローとの統
合である。ワークフローは、自動化されたシステム間ワークフローとユーザ・イ
ンタフェース・ワークフローという２つの種類があると説明されることが多い。
完全に自動化されたワークフローも存在しているし、完全にユーザ駆動のワーク
フローも存在しているが、大部分のワークフローは、自動化要素とユーザ・イン
タフェース要素とを持っている。当該グローバル・コラボレーション・マネージ
ャおよびグローバル・コラボレーション・デザイナは、ワークフローのタイプに
このような人工的な区別をする必要がない。そのため、ワークフローは部分的に
自動化し、他の部分をユーザと相互作用させることができる。自動化部分とユー
ザ部分の両方とも、複数のエンタープライズをつなぐことができる。

【００６８】 さらに重要な特徴はワークフロー通信である。通信は、ワークフローで発生す
るイベントにより始動したエンタープライズを介して行われる。通信は二つの形
態、すなわち区間通信と加入／発行通信、の一つで行われる。区間通信体系では
、個々のメッセージは所定の受取人の各々に送信される。例えば、１０人に連絡
を取る必要がある場合、１０のメッセージがこれらの人々に送信される。発行／
加入体系では、個人はイベントにより発生するメッセージを受け取るために加入
する。イベントが発生すると、メッセージは加入した全てのユーザに送信される
。

【００６９】 図１２はワークフロー通信を組み込んだシステムの一実施形態のブロック図を
示している。システム１６は、ハブエンジン１９を有するハブ１７を持っている
。ハブエンジン１９はイベント・マネージャ２００を持つ。ハブ１７にはスポー
クノード２４が接続されており、これにはスポークエンジン上で実行されるワー
クフローのようなプロセスが含まれる。別のスポークノード２０をハブ１７に接
続することもできる。

【００７０】 作動中、ハブ１７から区間通信を受け取るようにスポークノード２４を操作で
きるようにしてもよい。ハブエンジン１９上で実行されるワークフローがあるイ
ベントに到達すると、区間体系で個々のメッセージをスポークノード２４に送信
するためにイベント・マネージャ２００を始動するようにしてもよい。また、エ
ンジン１９上で実行されるワークフローが到達したイベントに基づいて所定の時
間にメッセージを受け取るため、スポークノード２０はイベント・マネージャ２
００に予約することもできる。イベントに到達すると、メッセージ・ハンドラ（
図示せず）とともにイベント・マネージャ２００は全ての予約者にメッセージを
送信する。例えば、イベントは送り状の到着であってもよい。送り状が到着する
と、全ての予約者は注意書きを受け取る。

【００７１】 図１３はイベント・マネージャ２００の一実施形態のブロック図である。イベ
ント・マネージャ２００はワークフロー・マネージャ２０２に接続されている。
ワークフロー・マネージャ２０２は一つあるいはそれ以上のモジュール２０４と
関係づけられている。モジュール２０４は、エンジンが使用するためにデータ及
び対象物を格納することができる内部ワークスペース２０３に接続されている。
ワークフロー・マネージャ２０２は、モジュールからメッセージを受け取り外部
ワークスペースにメッセージを伝達するように作動するメッセージ・ハンドラ２
０６にも接続されている。メッセージ・ハンドラ２０６は、コラボレーションに
おける異なるエンティティ間でデータ及び対象物を交換できる外部ワークスペー
ス２０８に接続されている。（Ｃ＋＋及びＪａｖａのような）様々な異なるプロ
グラミング言語が種々の要素にアクセスするために、ＣＯＲＢＡインターフェー
ス２０１が設けられている。

【００７２】 作動中、エンジン上で実行されるワークフローに発生するイベントがイベント
マネージャ２００を始動させ、アクセス・ワークフロー・マネージャ２０２によ
りワークフローがスタートする。さらに、ワークフローで発生するどのようなイ
ベントもワークフロー・マネージャ２０２を始動してイベント・マネージャ２０
０にアクセスさせる。イベント・マネージャ２００はそれから、イベントが発生
したことを全ての加入者に連絡する。発生したイベントに固有のパラメータ化さ
れたデータが連絡には含まれている。

【００７３】 図１４は発行／加入通信モデルの一実施形態のブロック図を示している。図示
されたイベント・マネージャ２００は複数のＧＵＩ／アプリケーション２１２，
２１４，２１６と接続され通信可能である。イベント・マネージャ２００は、ワ
ークフロー２１０を実行するために作動するモジュール２０４にも接続されてい
る。

【００７４】 作動中、第一のＧＵＩ／アプリケーション２１２がイベント２１８をイベント
・マネージャ２００に送信する。イベント・マネージャ２００がイベント２１８
を受け取ると、モジュール２０４に送られ、そこでワークフロー２１０の実行を
開始する。ワークフロー２１０がある点に達すると、第二のイベント２２０を発
生する。これはそれからイベント・マネージャ２００に送られる。イベント・マ
ネージャ２００は、イベントが発生したことをＧＵＩ／アプリケーション２１２
，２１４，２１６に知らせるメッセージを通知する。それらが加入者である限り
、イベントに固有のパラメータ化された値が通知とともにイベント・マネージャ
２００に送られる。

【００７５】 外界との統合 図１５は、ワークフローと外界との統合の一実施形態の図である。既出部分に
記載されているように、高度なエンタープライズ間およびエンタープライズ内ワ
ークフローを作成できる。これらのワークフローは、種々の構成でつなぎ合わさ
れている複数のアクティビティから作ることができる。ワークフローの種々のア
クティビティが何を行うかについては何ら制限はないが、これらのアクティビテ
ィの主要タスクのうちの１つは、外界との統合である。図１５に、コンポーネン
トベースの統合法を利用して、どのようにワークフローと外界とを統合させるこ
とができるかを示す。コンポーネントは、アクセッサ８０、トランスフォーマ８
２、転送オブジェクト８４、アダプタおよびフロー８６を含むことができる。

【００７６】 グローバル・コラボレーション・マネージャは、コンポーネント・ベースの統
合モデルをサポートできる。コンポーネント・ベースの統合モデルを採用するこ
とにより、統合を行う際に柔軟性がもたらされる。コンポーネントには、単純コ
ンポーネント（ｐｒｉｍｉｔｉｖｅ ｃｏｍｐｏｎｅｎｔ）と複合コンポーネン
ト（ｃｏｍｐｏｕｎｄ ｃｏｍｐｏｎｅｎｔ）の２タイプがある。単純コンポー
ネントとして、アクセッサ８０、トランスフォーマ８２、および転送オブジェク
ト８４などがある。複合コンポーネントは、アダプタおよびフロー８６などであ
る。複合コンポーネントは、単純コンポーネントで構築されている。この手法で
は、アクセッサ８０は、ＳＣＰ（サプライチェーン・プランナ）、ＳＡＰ、リレ
ーショナル・データベース、ウェブ・サーバ、ｅメール、メッセージ・バスなど
の外部ソースにアクセスするために使用される。アクセッサ８０は、データソー
スおよびデータ宛先と読出、書込、または通信を行うために使用できる。トラン
スフォーマ８２は、データをある形態から別の形態に変換するために使用できる
。転送オブジェクト８４は、アクティビティ間またはエンタープライズ間で受け
渡し可能なオブジェクトである。転送オブジェクト８４は、必要に応じてＥＤＩ
、ＸＭＬ、ＣＯＲＢＡ構造等に変換できるものでもよい。アクセッサ８０とトラ
ンスフォーマ８２は、一緒に連なってフローを形成できる。図１６に示されてい
るように、フロー全体を１回のアクティビティで実行できる。

【００７７】 図１６は、１回のアクティビティ９２で実行されるデータフローの一実施形態
の図である。図示されているように、データソース９０は、アクセッサ・コンポ
ーネント９４からアクセス可能であり、また、アクセッサ・コンポーネント９４
にデータを供給できる。また、アクセッサ・コンポーネント９４は、第２のアク
セッサ・コンポーネント１００にデータを供給するトランスフォーマ・コンポー
ネント９６と９８を通じてデータを受け渡すことができる。その後、データはデ
ータ宛先１０２に記憶される。

【００７８】 図１７は、複数のアクティビティ１０４と１０６に関して分割されたデータフ
ローの一実施形態の図である。図示されているように、図１７のフローは、トラ
ンスフォーマ・コンポーネント９６と９８が、別々のアクティビティ１０４と１
０６の中にあり、転送オブジェクトによって連絡されている点が図１６のものと
異なっている。マルチエンタープライズのデータフローは、図１６でなく図１７
のモデルを基礎とすることができる。

【００７９】 変換について述べると、一実施形態において、Ｉ２ ＣＤＭを使用した変換と
直接変換との２種類の基本変換タイプがサポートされる。Ｉ２ ＣＤＭを使用し
た変換は、アイ・ツー・テクノロジー社のＣＯＭＭＯＮ ＤＡＴＡ ＭＯＤＥＬ
（ＣＤＭ）に基づくものである。ＣＤＭは、リレーショナル形にもオブジェクト
形にも利用可能な抽象スキーマである。

【００８０】 図１８は、Ｉ２−ＣＤＭをベースにした変換モデルの一実施形態のブロック図
である。図示されているように、トランスフォーマとアクセッサを結合して、ア
プリケーション・データをＣＤＭデータ・オブジェクト１１０に変換したり、そ
の逆を行ったりすることができる。例えば、ＳＣＰアクセッサによってＳＣＰデ
ータ１１４からＳＵＰＰＬＹ ＣＨＡＩＮ ＰＬＡＮＮＥＲ （ＳＣＰ）オブジ
ェクト１１２を作成できる。その後、ＳＣＰオブジェクト１１２は、ＳＣＰ−Ｃ
ＤＭトランスフォーマによってＣＤＭオブジェクト１１０に変換できる。同様に
、ＳＡＰアクセッサによってＳＡＰデータ１１８からＳＡＰオブジェクト１１６
を作成できる。その後、ＳＡＰオブジェクト１１６は、ＳＡＰ−ＣＤＭトランス
フォーマによってＣＤＭオブジェクト１１０に変換できる。他のアクセッサおよ
びトランスフォーマでそうであるように、ＳＡＰアクセッサおよびトランスフォ
ーマを組み合わせて、ＣＤＭベースの変換に利用できる標準的なＳＡＰ−ＣＤＭ
アダプタ１２０にすることができる。別の例として、ＢＡＡＮアクセッサによっ
て、ＢＡＡＮデータ１２４からＢＡＡＮオブジェクト１２２を作成できる。その
後、ＢＡＡＮオブジェクト１２２は、ＢＡＡＮ−ＣＤＭトランスフォーマによっ
てＣＤＭオブジェクト１１０に変換できる。これらの変換は別の方向にも働く。

【００８１】 図１９は、直接変換の一実施形態の図である。直接トランスフォーマの場合、
オブジェクトは、中間形式を通らずに一つの形態から別の形態に変換される。例
えば、図１９に示されているように、ＳＵＰＰＬＹ ＣＨＡＩＮ ＰＬＡＮＮＥ
Ｒ （ＳＣＰ）アクセッサがＳＣＰデータ１３０にアクセスしてＳＣＰオブジェ
クト１３２が作成される。ＳＣＰオブジェクト１３２は、ＦＡＣＴＯＲＹ ＰＬ
ＡＮＮＥＲ （ＦＰ）オブジェクト１３４に直接に変換される。ＦＰオブジェク
ト１３４は、その後、ＦＰアクセッサを通じてＦＰデータ１３６となりうる。こ
のデータフローは、別の方向にも作用しうる。

【００８２】 これらのプロセスには、アクセスおよび変換可能な、リレーショナル・レベル
（テーブル）、汎用オブジェクト・レベル（ツリー、グラフ、マトリックス等）
および特定オブジェクト・レベル（資材明細書、プラン等）などの細分化された
種々のレベルが存在している。アクセス権は１つのレベル（例えば、テーブル）
でしか得られないが、別のレベル（例えば、汎用オブジェクト）での変換が適し
ていることもある。例えば、階層集約（変換の形態）は、しばしばツリー・オブ
ジェクトに適している。しかしながら、表の形でしかデータにアクセスできない
こともある。この場合、例えば、データにテーブル・レベルでアクセスし、ツリ
ーに変換し、そしてそれに階層集約を適用しなくてはならない。

【００８３】 図２０は、異なるアクセスおよび変換レベルの一実施形態の図である。図示さ
れているように、アクセスおよび変換は３つのレベルを持つことができる。第１
のレベル１４０は、表のアクセスおよび変換を含むことができる。第２のレベル
１４２は、汎用オブジェクト（ツリー、グラフ等）のアクセスと変換を含むこと
ができ、第３のレベルは、特定オブジェクト（資材明細書、プラン等）のアクセ
スと変換を含むことができる。アプリケーション形式間の変換の他に、図示され
ているように３レベル間の変換があってもよい。

【００８４】 コラボレーションの配備 マルチエンタープライズ・コラボレーション・システムの重要要素の１つは、
コラボレーション配備の容易さである。前述のように、当該グローバル・コラボ
レーション・マネージャは、ハブ／ウェブ、ハブ／スポーク、ハブ／ハブ、およ
びハブ／ＶＡＮ−ＥＤＩという４種類のパートナー関係をサポートできる。これ
らの４種類のうち、ハブ／ウェブは、従来のウェブ・アプリケーションのあらゆ
る配備特性を有する。ハブ／ＶＡＮ−ＥＤＩは、既存のＶＡＮ−ＥＤＩインフラ
ストラクチャに影響を及ぼす範囲まで配備可能である。ハブ／ウェブ関係は高度
に配備可能であるが、関係のウェブ側に人間を要するという問題がある。すなわ
ち、これは、システム間コラボレーションには適合しない可能性がある。

【００８５】 ハブ／スポーク・ソリューションは、システム間コラボレーション環境に最大
の配備可能性を与えることができる。ハブ／スポーク領域において、スポーク・
エンジンはウェブ・ブラウザと類似し、コラボレーションのスポーク部はウェブ
・ページまたはアプレットと類似している。ウェブ・ページまたはアプレットと
同様に、コラボレーションのスポーク部は、集中的に設計されて遠隔スポーク・
エンジンに配備される。ウェブ・ページまたはアプレットと異なり、遠隔から実
行する必要のある統合業務が依然として存在している。この遠隔統合は不可避で
あるが、コラボレーションのスポーク部によって制限し正確に規定できる。

【００８６】 配備可能性の別の側面は、バージョン管理処理である。設計および配備された
コラボレーションは、時間の経過に伴って（種々の方法で）変更が必要になるこ
とが多い。初期バージョンのように、コラボレーションの後続バージョンを簡単
に配備できることが重要である。当該グローバル・コラボレーション・マネージ
ャは、コラボレーションのバージョン管理と集中再配備とを完全にサポートでき
る。また、コラボレーションの種々のバージョンは、互いに影響を及ぼすことな
く同時に実行可能である。これにより、既存バージョンを段階的に体好く廃止し
ながら、別のバージョンを段階的に導入していくことができる。

【００８７】 当該グローバル・コラボレーション・マネージャの配備特性の別の要素は、既
存のインフラストラクチャの強化である。この要素は、例えば、既存のウェブ・
プロトコルに基づいたハブ／スポーク関係のサポートで明らかである。既存のウ
ェブ・プロトコルに基づいてハブ／スポークをサポートすることは、既存のウェ
ブ・インフラストラクチャの変更または再構成が必要ないため、高速配備にとっ
て重要である。これに関する大幅な時間の節約は、既に所定の場所にあるかも知
れない、注意深く設計されたファイアウォールおよびセキュリティ・インフラス
トラクチャを修正する必要が無くなることに起因する。

【００８８】 多コラボレーション対多コラボレーションのサポート 本発明のハブ／スポークアーキテクチャは、扱いやすさと配備しやすさを提供
するものである。しかしながら、実際には、エンタープライズは、更に別のエン
タープライズと協同作業を行う数多くのエンタープライズと協同作業する。従っ
て、エンタープライズはしばしば協同作業ウェブまたはグラフを形成する。これ
は、スポーク・エンジンの代わりにハブ・エンジンを随時使用する機能を介して
サポートできる。この代用機能により、多コラボレーション対多コラボレーショ
ン・ウェブは、一度にではなく有機的に成長することができる。

【００８９】 図２１は、コラボレーション内のスポーク・エンジンの代わりにハブ・エンジ
ンを使っている一実施形態の図である。図示されているように、エンタープライ
ズ（ＥＩ）は、それ自体にハブ・エンジン１５０を配備し、そのパートナー・サ
イトの全部にスポーク・エンジン１５２を配備することもできる。特に、スポー
ク・エンジン１５４は、パートナー側（Ｅ２）にあってもよい。パートナー側（
Ｅ２）が、自己のコラボレーションの設計および制御を希望する場合、スポーク
・エンジン１５４とハブ・エンジン１５６を交換できる。Ｅ１から見ると、Ｅ２
は、依然としてＥ１のコラボレーション内のスポークでありうる。しかしながら
、今やこのスポークは、スポーク・エンジン１５８によりそれ自体のコラボレー
ションを制御できるハブ・エンジン１５６上で動作している。また、スポーク・
エンジン１６０と１６２は、Ｅ３に代わってハブ・エンジン１５０およびハブ・
エンジン１５６の両方と対話する第３のエンティティ（Ｅ３）と対応付けること
もできる。

【００９０】 フレームワークの拡張 本願のフレームワークの重要側面は拡張性である。拡張性無くしては、フレー
ムワークは直面する新しい状況や課題を処理しえない。この拡張性に対して、い
くつかの異なる次元がある。例えば、拡張性の主領域の１つは、意味オブジェク
ト基準の領域にある。サポートしている基準が、特定の問題に対して不十分な場
合、フレームワークに新しい意味基準を増補できる。更に、フレームワークは独
自の意味基準を構築できる。また、フレームワークは、新しいアクセッサ、トラ
ンスフォーマ、アダプタ等によって拡張できる。基準コンポーネント・ライブラ
リは、習慣的に拡張することも、エンド・ユーザが拡張することも可能である。

【００９１】 以上、本発明を詳細に説明したが、添付の請求項に記載の本発明の精神および
範囲から逸脱せずに本発明に対して種々の変更、置換、および修正を行えること
を理解されたい。

【図面の簡単な説明】

【図１】 エンタープライズ・コラボレーションをサポートできるコンピュ
ータ実行アーキテクチャの一実施形態の図である。

【図２】 グローバル・コラボレーション・フレームワークの構成要素の一
実施形態の図である。

【図３】 特定のモジュールを構成するあるソフトウェア要素を強調表示さ
せた、図２のグローバル・コラボレーション・フレームワークの図である。

【図４】 最適な意思決定を行うためにエンタープライズ内またはエンター
プライズ間のコラボレーションを可能にするシステムの一実施形態のブロック図
である。

【図５】 グローバル・コラボレーション・ワークスペースの使用法の一実
施形態のブロック図である。

【図６】 コラボレーションのライフサイクルの一実施形態の図である。

【図７】 共通ソフトがリレーションシップの両側に存在している状況と、
存在していない状況の図である。

【図８】 ハブ／スポークおよびハブ／ウェブの場合のセキュリティ構成の
一実施形態のブロック図である。

【図９】 ハブ／ハブの場合のセキュリティ構成の一実施形態のブロック図
である。

【図１０】複数のグループに対するパラメータ化を含むエンタープライズ間
ワークフロー設計の一実施形態の図である。

【図１１】 ワークフローの設計を修正する変更管理の一実施形態の図であ
る。

【図１２】 ワークフロー通信を組み込んだシステムの一実施形態のブロッ
ク図である。

【図１３】 イベント・マネージャの一実施形態のブロック図である。

【図１４】 発行／加入通信モデルの一実施形態のブロック図である。

【図１５】 ワークフローと外界との統合の一実施形態の図である。

【図１６】 １回のアクティビティで実行されるデータフローの一実施形態
の図である。

【図１７】 複数のアクティビティに関して分割されたデータフローの一実
施形態の図である。

【図１８】 ＣＯＭＭＯＮ ＤＡＴＡ ＭＯＤＥＬをベースにした変換モデ
ルの一実施形態のブロック図である。

【図１９】 直接変換の一実施形態の図である。

【図２０】 異なるアクセスおよび変換レベルの一実施形態の図である。

【図２１】 コラボレーション内のスポーク・エンジンの代わりにハブ・エ
ンジンを使用した一実施形態の図である。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＵＧ，ＺＷ)，Ｅ Ａ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ， ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，Ｇ Ｅ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ， ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，Ｍ Ｎ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ， ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，Ｚ Ｗ (72)発明者 マーク・ビー・ホイップル アメリカ合衆国75208テキサス州ダラス、 ノース・クリントン・アベニュー110番

Claims (10)

【特許請求の範囲】
1. 【請求項１】 一つあるいはそれ以上のワークフローを実行し、ワークフロ
   ー上で所定のイベントが発生するとイベント・マネージャを始動し、イベントに
   基づいてメッセージを作成し、所定のグループに送信するようにしたワークフロ
   ー通信法。
2. 【請求項２】 メッセージを受け取るように予め予約したグループのすべて
   のメンバにメッセージが送られるようにした請求項１の方法。
3. 【請求項３】 メッセージがグループの全てのメンバに個々に送られるよう
   にした請求項１の方法。
4. 【請求項４】 メッセージがエンタープライズを介して送られるようにした
   請求項１の方法。
5. 【請求項５】 ワークフローにおけるイベントの発生を伝達するシステムで
   あって、 ワークフロー・エンジンと、該エンジンに接続され、ワークフローにおけるイ
   ベントの発生に基づいてメッセージを作成するために作動するイベント・マネー
   ジャを備えたシステム。
6. 【請求項６】 イベント・マネージャが、メッセージの伝達に際し、イベン
   ト・マネージャを手助けするために作動するメッセージ・ハンドラをさらに備え
   た請求項５のシステム。
7. 【請求項７】 イベント・マネージャに接続され、ワークフローにおけるイ
   ベントの発生に関する情報を送信及び受信するために作動するワークフロー・マ
   ネージャをさらに備えた請求項５のシステム。
8. 【請求項８】 イベント・マネージャが、イベントの発生に基づいてワーク
   フローを始動するためにさらに作動するようにした請求項５のシステム。
9. 【請求項９】 メッセージが、メッセージを受け取るように予約したグルー
   プに送られるようにした請求項５のシステム。
10. 【請求項１０】 メッセージがグループのメンバに個々に送られるようにし
    た請求項５のシステム。