JP2002517828A

JP2002517828A - 意思決定支援環境でオブジェクト・ワークスペース・エージェントを実行するためのシステムおよび方法

Info

Publication number: JP2002517828A
Application number: JP2000552610A
Authority: JP
Inventors: ランジット・エヌ・ノタニ; アバイ・ブイ・パラスニス; マーク・ビー・ホイップル
Original assignee: アイ２・テクノロジーズ・インコーポレイテッド
Priority date: 1998-06-05
Filing date: 1999-06-03
Publication date: 2002-06-18
Also published as: US6334146B1; AU4415299A; TW425517B; KR20010052573A; EP1084475A1; WO1999063466A1; CA2333748A1

Abstract

(57)【要約】マルチエンタープライズのコラボレーションにおいてデータに遠隔からアクセスするためのコンピュータシステムは、複数の記憶オブジェクトを有する第１のエンタープライズと関連付けられたワークスペースを備えている。コンピュータシステムは、第２のエンタープライズと関連付けられ、ネットワークを通じてワークスペースと通信状態にあるネットワーク・ノードを更に備えている。コンピュータ・システムは、ネットワーク・ノードで生成されるエージェントを更に備えている。該エージェントは、ネットワーク経由でワークスペースにアクセスするように動作可能であり、また、ワークスペース内の複数の記憶オブジェクトのうちの少なくとも１つを操作してコラボレーション・アクティビティを実施させるように動作可能である。

Description

【発明の詳細な説明】

【０００１】発明の技術分野本発明は一般に、サプライチェーン、エンタープライズ、およびサイト・プラ
ンニングに関するものであり、特に、意思決定支援環境でオブジェクト・ワーク
スペース・エージェントを実施するためのシステムと方法に関するものである。

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

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

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

【０００５】そのような問題の１つとして、ドメイン環境またはマルチドメイン環境の離れ
たエンティティが局所オブジェクト・ワークスペースにアクセスできないという
、現在の意思決定支援ソフトウェアの限界がある。そのようなソフトウェアでは
、前述の遠隔エンティティが局所ワークスペースで、管理業務、最適化ルーティ
ン、または他の形態のデータおよびオブジェクト管理を容易に実行することは不
可能である。

【０００６】発明の開示本発明によれば、従来のサプライチェーン、エンタープライズ、およびサイト
・プランニング環境に利益を与える、意思決定支援環境でオブジェクト・ワーク
スペース・エージェントを実施するためのシステムと方法が開示されている。

【０００７】本発明の一態様によれば、マルチエンタープライズのコラボレーションで、デ
ータに遠隔アクセスするためのコンピュータシステムは、複数の記憶オブジェク
トを有する第１のエンタープライズと関連付けられたワークスペースを備えてい
る。コンピュータシステムは、第２のエンタープライズと関連付けられ、ネット
ワークを通じてワークスペースと通信状態にあるネットワークノードを更に備え
ている。コンピュータシステムは、ネットワーク・ノードで生成されるエージェ
ントを更に備えており、このエージェントは、ネットワーク経由でワークスペー
スにアクセスするように動作可能で、ワークスペース内の複数の記憶オブジェク
トのうちの少なくとも１つを操作してコラボレーション・アクティビティを実施
するように動作可能である。

【０００８】本発明の技術上の利点は、エージェントを備えた遠隔ワークスペースにアクセ
スし、遠隔ワークスペースにおいてエージェントの予めプログラムされた目的を
満たす機能である。本発明の更なる技術上の利点は、エージェントが既に接触を
喪失している第２のエンタープライズ、ノード、またはプラットフォームで開始
されたにもかかわらず、第１のエンタープライズ、ノード、またはプラットフォ
ームでタスクを実行するエージェントの機能である。本発明の更なる利点は、宛
先ノードで実施された実行タスクの結果を、開始ノードに伝達できることである
。更に別の利点は、エージェントが、ワークスペース内に存在する別のエージェ
ント上で動作または作用するように動作可能なことである。その他の技術上の利
点は、以下の図、説明、および請求項から当業者に容易に明らかになるであろう
。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００４２】

【表１】

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

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

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

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

【００４７】

【表２】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００８６】オブジェクト・ワークスペース図１９は、コンピュータ・システム２０５のコンピュータ・ワークスペース２
００の一実施形態のブロック図である。コンピュータ・ワークスペース２００は
、許可フレームワーク・マネージャ２２０およびイベント・マネージャ２３０と
通信状態にある複数のメモリ・スロット２１０を含む。許可フレームワーク・マ
ネージャとイベント・マネージャ２３０は、コンピュータ・ワークスペース２０
０に常駐していても、していなくてもよい。コンピュータ・ワークスペース２０
０は、ネットワーク・ノード２４０によってネットワーク２５０を通じてアクセ
スされる。一般に、許可フレームワーク・マネージャ２２０は、ネットワーク・
ノード２４０によるコンピュータ・ワークスペース２００内のメモリ・スロット
２１０へのアクセスを制御する。イベント・マネージャ２３０は、メモリ・スロ
ット２１０に記憶されているデータまたはオブジェクトに関連するイベントまた
は状況を受けて、ネットワーク・クライアント２４０に対してメッセージを発生
する。

【００８７】ネットワーク２５０は、ハブ、ルータ、ブリッジ、ゲートウェイ、スイッチ、
またはネットワーク・ノード２４０間でデータを送信する適切な通信装置または
関連ソフトウェアの他の関連品を任意に組合せたもの、または多数のそれらを含
む。一実施形態において、ネットワーク２５０は、個別に実現されたネットワー
ク、または、広域ネットワーク（ＷＡＮ）、またはＥｔｈｅｒｎｅｔネットワー
ク、トークン・リング・ネットワーク、またはファイバーデータ分配インターフ
ェイス（ＦＤＤＩ）ネットワークなどのローカル・エリア・ネットワーク（ＬＡ
Ｎ）と組み合わせたネットワークを含む。ネットワーク２５０は、インターネッ
ト・プロトコル（ＩＰ）などの高レベル非接続プロトコル、フレーム・リレーな
どの高レベル接続指向プロトコル、またはいずれか他の適切なネットワーク用プ
ロトコルをサポートしている。ネットワーク２５０は、１つ以上のエンタープラ
イズ間で実行されるアクティビティを含むワークフローを実行するためにマルチ
エンタープライズ・コラボレーションで使用することもできる。マルチエンター
プライズ・コラボレーションのネットワーク２５０の各ネットワーク・ノード２
４０を別々のエンタープライズと対応付けることもでき、それによって、通信と
、アクティビティとエンタープライズ間のワークフローの調整性能が可能になる
。

【００８８】ネットワーク・ノード２４０は、ネットワーク２５０に接続された、任意の端
末、サーバ、クライアント、ハブ、スポーク、または他のデバイスでよい。各ネ
ットワーク・ノード２４０は、特定のエンタープライズと対応付けられている。
ネットワーク・ノード２４０は、特定のワークフローすなわちプロセスに関係し
ても、しなくてもよい。ネットワーク・ノード２４０は、ワークフローまたはコ
ラボレーションの一部として、または、ワークフローまたはコラボレーションに
対応付けられていない他のアクティビティまたはプロセスの一部として、ワーク
スペース２００にアクセスすることもできる。

【００８９】各メモリ・スロット２１０は、データとオブジェクトを記憶する。ここで使用
されているように、それぞれとは、識別アイテムの少なくともサブセットのそれ
ぞれを意味する。オブジェクトは、Ｊａｖａオブジェクト、Ｃ＋＋オブジェクト
、Ｃｏｒｂａオブジェクト、または情報および挙動の両方を記憶できる他の構造
であってもよい。メモリ・スロット２１０は、データまたはオブジェクトを保持
できる、問合わせまたはランダム・アクセスされる任意のメモリ構造であっても
よい。メモリ・スロット２１０は、例えば、任意のデータ構造、ハッシュ・テー
ブル、またはメモリ・アレイを含むこともできる。メモリ・スロット２１０は、
例えば、メモリ・スロット２１０内でキューに入れられる複数のオブジェクトを
収容することもできるし、単一オブジェクトだけを収容することもできる。メモ
リ・スロット２１０は、ディスクまたは他の記憶媒体に記憶されてもよいし、コ
ンピュータ・システム２０５によって行われる任意のプロセスまたはアクティビ
ティの間だけメモリに保持されてもよい。メモリ内に保持されるメモリ・スロッ
ト２１０は、例えば、ランダム・アクセス・メモリ上に記憶することもでき、そ
れにより、ディスクまたは周辺コンポーネントに記憶されたメモリ・スロット２
１０に対するアクセスが高速化する。ディスクまたは他の記憶媒体に記憶された
メモリ・スロット２１０は低速でアクセス可能であるが、メモリに記憶されたメ
モリ・スロット２１０は不揮発性で、永久データまたはオブジェクトを記憶でき
る。メモリ・スロット２１０は、プログラマ、ユーザ、または他の適切な機構に
よって定められた組織的階層に配列できる。そのような階層により、図２０を参
照しながら以下に説明するように、メモリ・スロット２１０の類別と参照が容易
にできる。

【００９０】許可フレームワーク・マネージャ２２０は、メモリ・スロット２１０に対する
アクセスを維持および制御する。許可フレームワーク・マネージャ２２０は、メ
モリ・スロット２１０に対するアクセス権を維持し、維持されているアクセス権
に基づいてメモリ・スロット２１０に対するアクセスを制御できる、任意の組合
せのハードウェアおよびソフトウェアを含むこともできる。一実施形態において
、アクセス権は、各メモリ・スロット２１０の内容を読み出し、各メモリ・スロ
ット２１０の内容に書き込み、各メモリ・スロット２１０の内容の一部を除去し
、１つ以上の指定メモリスロット２１０のイベント通知を登録または登録解除す
るノードの権利を含む。

【００９１】イベント・マネージャ２３０は、メモリ・スロット２１０内の特定のイベント
を受けて、ノード２４０に対してメッセージを発生する。イベント・マネージャ
２３０は、メッセージを発生して、特定ネットワーク・ノード２４０またはコン
ピュータ・システム２０５の他の適切な要素に対する前述メッセージの経路指定
を開始できる、ハードウェアおよびソフトウェアを任意の組合せで含むこともで
きる。許可フレームワーク２２０によって決定された特定メモリ・スロット２１
０に関するイベント通知を登録するためのアクセス権を有し、そのような登録を
特定のメモリ・スロット２１０に実行するためのアクセス権を有するネットワー
ク・ノード２４０に対し、特定メモリ・スロット２１０に関連付けられた、通知
を必要とするイベントが起こるたびに、イベント・マネージャ２３０によって発
生されたメッセージが通知される。

【００９２】例えば、ネットワーク・ノード２４０のうちの１つは、許可フレームワーク・
マネージャ２２０によって確認された特定のメモリ・スロット２１０に関する通
知を登録するためのアクセス権を有することもできるし、ネットワーク・ノード
２４０のうちの１つによって特定のメモリ・スロット２１０に書き込みが行われ
るたび毎の特定メモリ・スロット２１０に関する通知を登録することもできる。
この１つのネットワーク・ノード２４０が、前述の特定スロットに関する通知の
登録解除を行うまでは、ネットワーク・ノード２４０のいずれかによって特定メ
モリ・スロット２１０に書き込みが行われるたびに、イベント・マネージャ２３
０はメッセージを発生し、該特定メモリ・スロット２１０に対して書き込みがあ
ったことを示す前述メッセージを、該１つのネットワーク・ノード２４０に対し
て経路指定する。

【００９３】一実施形態において、特定メモリ・スロット２１０に関するイベントの通知を
登録または登録解除するためのアクセス権は、イベントの分類に基づいて変える
こともできる。例えば、特定のネットワーク・ノード２４０は、特定メモリ・ス
ロット２１０でデータの削除があったときに必ず通知を受け、同じメモリ・スロ
ット２１０に書き込みがあったときには通知を受けないようにする登録権を有す
ることもできるし、ネットワーク・ノード２４０は、両方に登録権を有すること
もできるし、または、登録は、そのようなメモリ・スロット２４０でのデータの
削除または書込に応じた通知を包含することもできる。許可フレームワーク２２
０によって与えられるアクセス権と、イベント・マネージャ２３０からのメッセ
ージに対する登録は、いずれか適切な組み合わせて分類することもできる。例え
ば、イベントの通知は、個々のメモリ・スロット２１０毎に、全部のメモリ・ス
ロット２１０に対し、または指定の基準に基づいて選択されたメモリ・スロット
２１０のサブセットに対して登録することもできる。同様に、アクセス権は、許
可フレームワーク２２０によって全部のメモリ・スロット２１０またはその任意
のサブセットに与えることができる。

【００９４】図２０に、図１９に示されるワークスペースの一実施形態を示す。ワークスペ
ース３００は、階層フレームワークに配列されたメモリ・スロット３１０にデー
タおよびオブジェクトを記憶するためのワークスペースである。階層の正確な性
質およびフレームワーク内の特定のメモリ・スロットの場所は、ワークスペース
管理者、他のユーザ、または他の適切な機構によって定義されうる。

【００９５】一般に、ワークスペース３００は複数のセクション３０５で構成され、各セク
ション３０５は、更に個別のメモリ・スロット３１０とグループ３２０とに分か
れている。グループ３２０は、更にメモリ・スロット３１０を含み、および／ま
たは更なるサブグループに分かれている。図２０で、メモリ・スロット３１０は
セクション番号、該当するならばグループ番号、そして該当するセクション３０
５またはグループ３２０内の識別番号によって指定される。例えば、”ｓｅｃｔ
ｉｏｎ２．ｇｒｏｕｐ１．ｓ２”という名称で識別されるメモリ・スロット３１
０は、ワークスペースのセクション２のグループ１の中の”ｓ２”と名付けられ
たスロットを指す。他の階層または組織化手法を、ここに記載の階層の代わりに
用いることもできる。記載されているもののような階層により、メモリ・スロッ
ト３１０の類別と分類を容易化できる。そのような類別は、アクセス権を維持す
る目的でメモリ・スロット３１０を簡単に分類するために使用できる。例えば、
図２０のネットワーク・ノード２４０は、メモリ・スロット３１０の特定列に対
する特定のアクセス権が与えられるに過ぎない。そのような列は、例えば、グル
ープ・レベルの全部のメモリ・スロット３１０であってもよいし、図２０のｓｅ
ｃｔｉｏｎ１.ｓ１とｓｅｃｔｉｏｎ２.ｓ１で指定されるメモリ・スロット３１
０であってもよい。特定のセクション３０５、グループ３２０、サブグループ、
またはそれらの組合せに対してアクセス権を与えることもできる。

【００９６】図２１は、ネットワーク４５０を通じてオブジェクト・ワークスペース４００
にアクセスするために複数のネットワーク・ノード４４０のうちの１つで開始さ
れた少なくとも１つのエージェント４６０を使用するコンピュータ・システム４
０５のブロック図である。ネットワーク・ノード４４０は、ネットワーク４５０
を介してワークスペース４００に接続される。コンピュータ・システム４０５の
中では、一般に、エージェント４６０がネットワーク・ノード４４０のいずれか
１つで開始されてネットワーク４５０を通じて移動し、ワークスペース４００に
アクセスし、プログラムされているコマンドに基づいてワークスペース４００内
で作業またはタスクを実行する。

【００９７】ワークスペース４００は、メモリ・スロット４１０を含み、図１９と２０を参
照しながら説明されたワークスペース２００と３００の特徴の一部または全部を
取り入れて具現されている。ネットワーク・ノード４４０は、特定のエンタープ
ライズと関係付けられ、図１９のネットワーク・ノード２４０を参照しながら説
明された通りに具現されている。ネットワーク４５０は、特定のコラボレーショ
ンに関わるネットワーク・ノードをつなぐネットワークであり、図１９のネット
ワーク２５０を参照しながら説明された通りに具現されている。

【００９８】エージェント４６０は、任意のオブジェクト指向エージェント、または自主性
（ａｕｔｏｎｏｍｙ）の特徴を有する他のアイテムであってもよい。ここで定義
される自主性とは、１つ以上の目標の下にプログラムされ、ネットワークおよび
他のプラットフォームに移動されて発信プログラムとのコンタクトが失われたと
きでさえ、発信プログラムまたはアプリケーションとは無関係に、これらの目標
を満足しようとする機能のことである。エージェント４６０は、コラボレーショ
ン・アクティビティを実行するという目標の下にプログラムされている。コラボ
レーション・アクティビティは、ワークフローの性能に関わるアクティビティで
あってもよいし、コラボレーション内のエンタープライズまたはファシリティを
開始して、ワークスペース４００内にあるデータまたはオブジェクトに関連する
管理、最適化、または実行タスクを実施しワークフローの外側で実行されるアク
ティビティであってもよい。コラボレーション・アクティビティは、データ回収
またはデータ操作のための問合わせであってもよいし、ワークスペース４００内
のオブジェクトであってもよい。管理エージェント４６０は、例えば、図２０を
参照しながら説明されたメモリ・スロット階層の特徴を修正するために開始する
こともできる。管理エージェント４６０は、開始側ネットワーク・ノード４４０
の登録概要を変更するために開始することもでき、それによって、当該ネットワ
ーク・ノード４４０が受信するイベント通知タイプが変更される。特定エージェ
ント４６０は、許可フレームワークを変更し、それによって、特定メモリ・スロ
ット４１０に対する１つ以上のネットワーク・ノード４４０のアクセス権を変更
できる権限を有する特定のネットワーク・ノード４４０から発生することも可能
である。最適化エージェント４６０は、ワークスペース４００に記憶されている
オブジェクトの特徴または挙動を修正し、ワークフロー決定または実行中に当該
オブジェクトの性能を改善させるために開始することもできる。実行エージェン
ト４６０は、ワークスペース４００内のオブジェクトを利用して一連のタスクま
たは計算を実行し、そのようなタスクまたは計算の結果をその開始側ネットワー
ク・ノード４４０に戻すこともできる。問合わせエージェント４６０は、ワーク
スペース４００に対して複雑な問合わせを行って、その問合わせの結果をその開
始側ネットワーク・ノード４４０に戻すこともできる。エージェント４６０は、
ワークスペース４００の内部で動作して、結果を別のエージェント４６０または
ネットワーク・ノード４４０に戻すことも可能である。

【００９９】ワークスペース４００は、ワークスペース２００および３００と同様に、エー
ジェント４６０と相互作用及び応答可能な許可フレームワークおよび／またはイ
ベント・マネージャを有する。例えば、エージェント４６０は、エージェント４
６０の開始側ネットワーク・ノード４４０が、エージェントが対話を希望するオ
ブジェクトまたはデータを収容している特定のメモリ・スロット４１０に対して
アクセス権を持っていることを確認するために、図１９に記載されているように
、許可フレームワークと対話することが必要な場合もある。同様に、イベント・
マネージャは、図１９を参照しながら説明したように、イベント通知メッセージ
を登録ネットワーク・ノード４４０に送信することにより特定メモリ・スロット
４６０内のエージェント４６０によって実行される動作に応答することもできる
。

【０１００】図２２は、図２１のエージェントを利用してワークスペースにアクセスする方
法の一実施形態を示すフローチャートである。ステップ５１０で、ネットワーク
のノードは、遠隔ワークスペースの少なくとも１つのタスクを実行するようにプ
ログラムされたエージェントを開始する。ステップ５２０で、エージェントは、
ネットワークを通じて、該ネットワークの第２のノードに接続されたワークスペ
ースに送られる。ワークスペースは、それぞれ少なくとも１つのオブジェクトを
記憶するように動作可能な複数のメモリ・スロット、許可フレームワーク、およ
びイベント・マネージャを有する。ステップ５３０で、エージェントは、許可フ
レームワークに対し、エージェントがアクセスしたい特定のメモリ・スロットを
示す。ステップ５４０で、許可フレームワークは、エージェントが開始したネッ
トワークのノードが、指定メモリ・スロットに対してアクセス権を有しているこ
とを確認する。ステップ５５０で、エージェントは、図２１を参照して説明され
た１つ以上の作業を実行する。ステップ５６０で、エージェントは、作業結果が
あれば、それを開始ノードに戻す。

【０１０１】ステップ５７０で、イベント・マネージャは、エージェントが実行した作業お
よびエージェントがアクセスしたメモリ・スロットに対応したイベント通知を登
録しているネットワークのノードにイベントを送信する。

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

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図１９】本発明の教示内容に基づいて構成されたワークスペースを利用
したコンピュータシステムの一実施形態のブロック図である。

【図２０】本発明の教示内容に基づいて構成された図１９のワークスペー
スの一実施形態の図である。

【図２１】本発明の教示内容によりオブジェクト・ワークスペースにアク
セスするエージェントを利用したコンピュータシステムのブロック図である。

【図２２】図２１のエージェントを利用してワークスペースにアクセスす
る方法の一実施形態を示すフローチャートである。

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

Claims

【特許請求の範囲】

【請求項１】マルチエンタープライズのコラボレーションにおいて、デー
タに遠隔アクセスするためのコンピュータ・システムであって、第１のエンタープライズと関連付けられ、ネットワークを介して、第２のエン
タープライズと関連付けられ複数の記憶オブジェクトを有するワークスペースと
通信状態にあるネットワーク・ノードと、前記ネットワーク・ノードで生成され、前記ネットワーク経由で前記ワークス
ペースにアクセスするように動作可能であり、さらに、該ワークスペース内の複
数の記憶オブジェクトのうちの少なくとも１つを操作してコラボレーション活動
を実施させるように動作可能であるエージェントと、を備えたコンピュータ・システム。
【請求項２】前記エージェントは管理エージェントである請求項１に記載
のコンピュータ・システム。
【請求項３】前記ワークスペースは階層に基づいて編制され、前記エージ
ェントは前記階層の特性を修正するように動作可能である管理エージェントであ
る請求項１に記載のコンピュータ・システム。
【請求項４】前記エージェントは実行エージェントである請求項１に記載
のコンピュータ・システム。
【請求項５】前記エージェントは最適化エージェントである請求項１に記
載のコンピュータ・システム。
【請求項６】前記エージェントは問合わせエージェントである請求項１に
記載のコンピュータ・システム。
【請求項７】前記ワークスペースは複数のメモリ・スロットを備え、各ス
ロットは少なくとも１つのオブジェクトを記憶するように動作可能である請求項
１に記載のコンピュータ・システム。
【請求項８】前記メモリ・スロットは、複数のネットワーク・ノードによ
りアクセス可能であり、該ネットワーク・ノードによる前記メモリ・スロットへ
のアクセスは、許容フレームワークによって制御される請求項７に記載のコンピ
ュータ・システム。
【請求項９】前記ワークスぺースはメモリ内ワークスペースである請求項
１に記載のコンピュータ・システム。前記エージェントは最適化エージェントである請求項１に記載のコンピュータ
・システム。
【請求項１０】前記ワークスペースは、永久ワークスペースである、請求
項１に記載のコンピュータ・システム。
【請求項１１】前記ワークスペースはイベント・マネージャを備え、該イ
ベント・マネージャは前記ワークスペースに対する変更を受けてネットワーク・
ノードに通知するように動作可能である請求項１に記載のコンピュータ・システ
ム。
【請求項１２】オブジェクト・ワークスペースにおいてデータに遠隔アク
セスする方法であって、ネットワークの第１のノードでエージェントを開始し、前記ネットワークを通じて前記ネットワークの第２のノードで前記エージェン
トをワークスペースに送り、該ワークスペースは複数のメモリ・スロットを有し
、各メモリ・スロットは少なくとも１つのオブジェクトを記憶するように動作可
能であり、前記ワークスペースは、前記メモリ・スロットへのアクセスを制御す
る許容フレームワークを更に有し、前記許容フレームワークを使用して、前記エージェントが特定のメモリ・スロ
ットへのアクセス権を有していることを確認し、前記エージェントと、前記特定メモリ・スロットに記憶されている少なくとも
１つのオブジェクトとを使用して作業を実行する、ようにした方法。
【請求項１３】前記作業の結果を前記第１のノードに送信するようにした
請求項１２に記載の方法。
【請求項１４】前記作業の実行を受けて、前記ネットワークの第３のノー
ドにメッセージを送信するようにした請求項１２に記載の方法。
【請求項１５】前記作業の実行を受けて、前記ワークスペースの組織的階
層を変更するようにした請求項１２に記載の方法。
【請求項１６】前記作業の実行を受けて、前記第１のノードがイベント通
知を登録するようにした請求項１２に記載の方法。
【請求項１７】前記作業の実行を受けて、前記許容フレームワークを変更
するようにした請求項１２に記載の方法。
【請求項１８】前記作業の実行により、前記ワークスペース内において管
理タスクを実行するようにした請求項１２に記載の方法。
【請求項１９】前記作業の実行により、前記オブジェクトの性能を最適化
するようにした請求項１２に記載の方法。