JP2002517831A - マルチエンタープライズコラボレーションのためのシステムおよびプロセス - Google Patents

Abstract

(57)【要約】 マルチエンタープライスコラボレーションのためのコンピュータ実行プロセスは、少なくとも１つのヘテロキャスト分割と、少なくとも１つのヘテロキャスト接合とを含むワークフローの設計を有する。ヘテロキャスト分割とヘテロキャスト接合とは、少なくとも１つのアクティビティがパラメータ化されることを可能にし、少なくとも１つのアクティビティはノードグループ内にノードを含んでいる。それぞれがノードグループ中の特別のノードに調整される複数のアクティビティとして、少なくとも１つのアクティビティが具体化されるように、ワークフローは具体化される。ワークフローは展開され、展開にはアクティビティをノードグループ中のノード全体に分配することが含まれる。さらに、ワークフローを実行して、マルチエンタープライズコラボレーションを提供する。他の実施形態においては、ワークフロー内において実行されるアクティビティに関連するオブジェクトを有する、オブジェクト志向のワークフローが、具体化される。オブジェクトは、エンタープライズ境界を超えて、関連するアクティビティが実行されるべきノードまで展開され、マルチエンタープライズコラボレーションを提供するように実行される。アクティビティは、データおよび行動の両方を伝送するオブジェクトを用いてデータを通信する。

Description

【発明の詳細な説明】

【０００１】 発明の技術分野 本発明は一般に、サプライチェーン、エンタープライズ、およびサイト・プラ
ンニングに関するものであり、特に、マルチエンタープライズコラボレーション
のためのシステムとプロセスに関するものである。

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

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

【０００４】 エンタープライズの成功または失敗は、エンタープライズ内での意思決定の品
質に大いに左右される可能性がある。したがって、エンタープライズの成功には
、エンタープライズ内での最適な意思決定を支援するアイ・ツー・テクノロジー
ズ社の製品ＲＨＹＴＨＭファミリなどの意思決定支援ソフトウェアが特に重要で
ある。一般に、最適な意思決定は、意思決定に達すると考えられる「世界」の広
がりである意思決定支援のドメインに関係している。 例えば、行われようとしている意思決定は、工場が所定の期間中に生産しなく
てはならない所定の品物の数量であってもよい。「最適な」回答は、意思決定の
ドメインに依存している。ドメインは、例えば、工場それ自体のみ、工場を含む
サプライチェーン、エンタープライズ全体、またはマルチエンタープライズ・サ
プライチェーンであってもよい（後の２つは、大きいドメインまたはマルチドメ
インと考えられる）。一般に、意思決定支援のドメインが大きいほど、意思決定
はより最適なものとなる。したがって、意思決定支援ソフトウェアが、意思決定
過程で、より大きなドメインを範囲に含むことが望ましい。しかしながら、対象
範囲をこのように拡大することによって重大な問題が生じることがある。

【０００５】 発明の開示 本発明によれば、従来のサプライチェーン、エンタープライズ、およびサイト
・プランニング環境に利益を与える、エンタープライズのコラボレーションのた
めのオブジェクト志向のワークフローが開示されている。

【０００６】 本発明の一態様によれば、エンタープライズのコラボレーションのためのコン
ピュータ実行プロセスはオブジェクト志向のワークフローを具体化することを伴
い、オブジェクト志向のワークフローは、ワークフロー内で実施されるべきアク
ティビティに関連するオブジェクトを有する。オブジェクト志向のワークフロー
のオブジェクトは、次に、エンタープライズ境界を超えて、関連するアクティビ
ティが実施されるべきノードまで展開される。展開後、展開されたオブジェクト
は、アクティビティがデータおよび行動の両方を伝送するオブジェクトを用いて
データを通信しながら、マルチエンタープライズのコラボレーションを提供する
ように実行される。

【０００７】 本発明の他の態様によれば、オブジェクト志向のワークフローのデータアクセ
スおよび変換に対してコンピュータ実行プロセスが提供される。このプロセスは
、基本データフォーマットとしてオブジェクトの通信をサポートすることと、基
礎をなすネィティブデータフォーマットから形成された導出フォーマットオブジ
ェクトをサポートすることとを含む。さらに、変換は、ネイティブフォーマット
と、導出フォーマットオブジェクトと、オブジェクトとの間でサポートされる。
このプロセスはさらに、オブジェクトを用いる実行ワークフローと、導出フォー
マットオブジェクトのアクティビティとの間の情報を通信し、ネィティブデータ
フォーマットと導出フォーマットオブジェクトとオブジェクトとの間の変換を使
用することとを伴う。

【０００８】 本発明の技術上の利点は、オブジェクトを用いるアクティビティ間の情報を通
信する、オブジェクト志向のワークフローの実行である。これにより、オブジェ
クトがデータと行動との両方を伝達するときに、能力が高められる。 本発明の他の技術上の利点は、実行中のアクティビティによってアクセス可能
なメモリ内オブジェクトモデルの局所的実行である。このアクセスは、オブジェ
クトの作成と、変更と、破壊とを含む。

【０００９】 本発明の更なる技術上の利点は、データアクセス、および、マルチエンタープ
ライズコラボレーションのアクティビティとワークフローとの間でデータを伝達
するために、かなりの柔軟性を提供する、操作フレームワークである。

【００１０】 その他の技術上の利点は、以下の図、説明、および請求項から当業者に容易に
明らかになるであろう。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００４４】

【表１】

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

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

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

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

【００４９】

【表２】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００７６】 図１４Ａは、局所的メモリ内オブジェクトモデルを含むエンタープライズコラ
ボレーションのためのオブジェクト志向のワークフローの一実施形態の図である
。図示するように、ワークフローは、１７０で示されるように論理的に、または
、１７２で示されるように物理的に表すことが可能である。論理的ワークフロー
１７０は、物理的ワークフロー１７２中の特別な企業によって実行される多数の
アクティビティを有することができる。例えば、論理的ワークフロー１７０は、
第２の企業（Ｅ２）で実行するアクティビティ１７６（Ａ２）が後に続く、第１
の企業（Ｅ１）で実行するアクティビティ１７４（Ａ１）を備えることができる
。論理的ワークフロー１７０は、第１の企業（Ｅ１）の背後で実行する、追加の
アクティビティ１７８（Ａ３）および１８０（Ａ４）をさらに有することができ
る。従って、物理的ワークフロー１７２は、第１の企業１８２（Ｅ１）において
実行されるアクティビティ（Ａ１、Ａ３、Ａ４）と、第２の企業１８４（Ｅ２）
において実行されるアクティビティ（Ａ２）とを備えることができる。さらに、
図示するように、企業１８２は、企業１８２で実行しているアクティビティ（Ａ
１、Ａ３、Ａ４）によってアクセス可能なメモリ内オブジェクトモデル１８６を
有することができる。同様に、企業１８４は、企業１８４で実行しているアクテ
ィビティ（Ａ２）によってアクセス可能なメモリ内オブジェクトモデル１８８を
有することができる。メモリ内オブジェクトモデル１８６および１８８へのそれ
ぞれのアクセスにより、アクティビティ（Ａ１、Ａ２，Ａ３、Ａ４）は、オブジ
ェクトを作成し、変更し、および破壊することができると共に、オブジェクトか
ら情報を得ることができる。

【００７７】 本発明によると、ワークフロー１７０のようなワークフローの実行は、従来の
ワークフローの実行における書類よりもむしろ、オブジェクトを介して情報を伝
達する。ワークフロー１７０のオブジェクト志向の性質は、一般に、オブジェク
トが、オブジェクトをデータおよび行動と共に伝送するときに、拡張された機能
性を提供する。さらに、ワークフロー１７０内におけるアクティビティ（Ａ１、
Ａ３、Ａ４）が、共用のメモリ内オブジェクトモデル１８６および１８８を作成
し、変更し、および、アクセスすることが可能になることにより、さらなる利点
が得られる。これらの利点には、状態を維持することおよび、メモリ内オブジェ
クトモデル中にワークをオフロードすることにより、ワークフローの複雑さを低
減させることも含まれる。従って、企業１８２および１８４で、メモリ内オブジ
ェクトをワークフローエンジン中にはめ込むことにより、各エンジンは、必要な
情報全体に局所的にアクセスし、かつ、それを制御することができる。例えば、
メモリ内オブジェクトモデル１８２および１８４は、サプライチェーンにおける
調達行動をモデリングする調達モデルであり得、サプライチェーンにおいてワー
クフロー１７０は調達プロセスに関係付けられる。さらに、メモリ内オブジェク
トモデル１８６および１８８は、同一の事例および同一のワークフロー、同一の
ワークフローの複合事例、または企業１８２および１８４で実行している複合ワ
ークフローの事例の一部であるアクティビティによって、アクセス可能である。

【００７８】 現在のグローバルコラボレーションマネジャーは、単純な書類を渡すのに対抗
してイベントおよびメッセージとしてのオブジェクトを渡すオブジェクト志向の
ワークフローを実行することができる。このようなオブジェクトは、データと行
動との両方を含み、グローバルコラボレーションマネージャを実行するエンター
プライズプラットフォーム上において実行可能である。例えばこれらのオブジェ
クトを使用すると、イベントは、ワークフローを始動または開始するために使用
され得、ワークフローが終了する信号まで送られ得る。メッセージはワークフロ
ー内の後続のアクティビティ間において、情報を運搬することが可能である。こ
のように、グローバルコラボレーションマネージャは、ドキュメント中心ワーク
フローに対抗して、オブジェクト中心ワークフローを実行する。さらに、アクセ
ス／変換オブジェクトモデルは露出され、図１４Ａに示されるようにデベロッパ
ーが、ワークフローによって贈呈されるメモリ内オブジェクトモデルを形成する
ことを可能にする。

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

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

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

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

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

【００８４】 図１７Ａおよび１７Ｂは、ワークフロー実行の間にデータが様々なフォーマッ
トに処理される得る、データアクセスおよび変換の一実施形態を示す図である。
図示されるように、図１７Ａは、グローバル・コラボレーションマネージャ内に
おいて実行される詳細なアクセスモデルを表し、様々なフォーマットにおけるデ
ータのアクセスおよび操作を提供する。上述したように、オブジェクト１９０は
一般に、実行するワークフロー中のアクティビティ間において、情報を伝達する
ために使用される。結果として主要なデーフォーマットタはオブジェクトベース
である。図示されるように、オブジェクト１９０は、ファイル、ストリーム、Ｃ
ＯＲＢＡ、ＤＣＯＭ、およびＯＯＤＢを含む様々なタイプのエレメントオブジェ
クト１９２であり得る。これらのタイプの外部オブジェクトは、ソースおよび宛
先の両方に直接アクセス可能である。しかしながら、導出された他のオブジェク
トフォーマットは、ＥＤＩデータ１９４、ＸＭＬデータ１９６および関連データ
１９８のような様々な固有フォーマットにおいて、柔軟性のあるデータ操作を提
供するようにサポートされる。それぞれのサポートされた導出フォーマットに対
して、対応するフォーマットから形成されたオブジェクトを有する導出フォーマ
ットオブジェクト（ＤＦＯ）が存在し得る。サポートされた導出フォーマット（
ＤＦＯ）はＥＤＩ ＤＦＯ ２００、ＸＭＬ ＤＦＯ ２０２、および関連ＤＦ
Ｏ ２０４を有し得る。エレメントフォーマット１９４、１９６および１９８は
、必要であれば、それぞれの導出フォーマットオブジェクト（ＤＦＯ）およびオ
ブジェクト１９０に抽出可能である。

【００８５】 図１７Ｂは、上述したオブジェクトおよび導出フォーマットオブジェクトを使
用する詳細な変換モデルの図である。図示されるように、オブジェクト２０６は
２つのアクティビティ間を直接通過可能である。さらに、データは、導出フォー
マットオブジェクト２０７としてアクティビティ間を通過可能である。さらに、
データはエレメントデータフォーマット２０８中を通過可能である。一般に、こ
の機構はサポートされた変換の２つの基本カテゴリーを伴うことができる。１つ
めは、フォーマットオブジェクトが直接変換されて、効果的でカストマイズされ
た変換を提供する直接変換である。２つめの変換は、フォーマットオブジェクト
が、共通データモデル（ＣＤＭ）として関連する中間表示を介して変換される共
通データモデル変換である。変換は、図１３から１６を参照してもまた説明され
る。このデータアクセスおよび操作フレームワークは、マルチエンタープライズ
コラボレーションのためのアクティビティとワークフローとの間でデータを通信
するために、かなりの柔軟性を提供する。

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

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

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

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

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

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

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

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

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図１４Ａ】 局所的メモリ内オブジェクトモデルを含むオブジェクト志向
のワークフローの一実施形態の図である。

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

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

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

【図１７Ａ】 ワークフローを実行する間に、データが様々な形態に処理さ
れることを可能にする、データアクセスおよび変換の一実施形態の図である。

【図１７Ｂ】 ワークフローを実行する間に、データが様々な形態に処理さ
れることを可能にする、データアクセスおよび変換の一実施形態の図である。

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

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＵＧ，ＺＷ)，Ｅ Ａ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ， ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，Ｇ Ｅ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ， ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，Ｍ Ｎ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ， ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，Ｚ Ｗ (72)発明者 マーク・ビー・ホイップル アメリカ合衆国75208テキサス州ダラス、 ノース・クリントン・アベニュー110番 【要約の続き】 で展開され、マルチエンタープライズコラボレーション を提供するように実行される。アクティビティは、デー タおよび行動の両方を伝送するオブジェクトを用いてデ ータを通信する。

Claims (6)

【特許請求の範囲】
1. 【請求項１】 少なくとも１つのヘテロキャスト分割と、少なくとも１つの
   ヘテロキャスト接合とを含むワークフローを設計することと、 少なくとも１つのアクティビティをパラメータ化することを可能にし、少なく
   とも１つの前記パラーメータがノードグループ内においてノードを有する、前記
   ヘテロキャスト分割および前記ヘテロキャスト接合と、 それぞれが前記ノードグループ中の特別のノードに調整される複数のアクティ
   ビティとして、前記少なくとも１つのアクティビティが具体化されるように、前
   記ワークフローを具体化することと、 前記アクティビティを前記ノードグループ中の前記ノード全体に分配すること
   を含む、前記ワークフローの展開と、 前記ワークフローを実行して、マルチエンタープライズコラボレーションを提
   供することとを有するエンタープライズコラボレーションのためのコンピュータ
   実行プロセス。
2. 【請求項２】 ワークフロー内で実施されるべきアクティビティに関連する
   オブジェクトを有する、オブジェクト志向のワークフローを具体化することと、 前記オブジェクト志向のワークフローの前記オブジェクトを、エンタープライ
   ズ境界を超えて、関連するアクティビティが実施されるべきノードまで展開する
   ことと、 展開されたオブジェクトを実行してマルチエンタープライズコラボレーション
   を提供し、前記アクティビティはデータおよび行動の両方を伝送するオブジェク
   トを用いてデータを通信する、こととを含むマルチエンタープライズコラボレー
   ションのためのコンピュータ実行プロセス。
3. 【請求項３】 １以上のノードで実行しているオブジェクトがメモリ内オブ
   ジェクトモデルをアクセス可能であるように、前記１以上のノードでメモリ内オ
   ブジェクトモデルを作成することをさらに有する、請求項２に記載のコンピュー
   タ実行プロセス。
4. 【請求項４】 基本データフォーマットとしてオブジェクトの通信をサポー
   トすることと、 基礎をなすネィティブデータフォーマットから形成された導出フォーマットオ
   ブジェクトをサポートすることと、 ネィティブデータフォーマットと、導出フォーマットオブジェクトと、オブジ
   ェクトとの間の変換をサポートすることと、 オブジェクトを用いる実行ワークフローおよび、導出フォーマットオブジェク
   トのアクティビティ間の情報を通信し、ネィティブデータフォーマットと導出フ
   ォーマットオブジェクトとオブジェクトとの間の変換を使用することとを有する
   オブジェクト志向のワークフローのデータアクセスおよび変換のためのコンピュ
   ータ実行プロセス。
5. 【請求項５】 サポートされたオブジェクトはファイルオブジェクトと、ス
   トリームオブジェクトと、ＣＯＲＢＡオブジェクトと、ＤＣＯＭオブジェクトと
   、ＯＯＤＢＰオブジェクトとを有する請求項４に記載のコンピュータ実行プロセ
   ス。
6. 【請求項６】 サポートされた導出フォーマットオブジェクトは、ＥＤＩデ
   ータとＸＭＬデータと関連データとを有する、ネィティブデータフォーマットか
   ら形成される請求項４に記載のコンピュータ実行プロセス。