JP3782880B2 - モジュール型アプリケーション共同装置およびアプリケーション間の共通運用性を与える方法 - Google Patents
モジュール型アプリケーション共同装置およびアプリケーション間の共通運用性を与える方法 Download PDFInfo
- Publication number
- JP3782880B2 JP3782880B2 JP32137197A JP32137197A JP3782880B2 JP 3782880 B2 JP3782880 B2 JP 3782880B2 JP 32137197 A JP32137197 A JP 32137197A JP 32137197 A JP32137197 A JP 32137197A JP 3782880 B2 JP3782880 B2 JP 3782880B2
- Authority
- JP
- Japan
- Prior art keywords
- application
- connector
- service
- transaction
- module
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Human Resources & Organizations (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Software Systems (AREA)
- Entrepreneurship & Innovation (AREA)
- Marketing (AREA)
- Data Mining & Analysis (AREA)
- Economics (AREA)
- General Engineering & Computer Science (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- General Business, Economics & Management (AREA)
- Stored Programmes (AREA)
- Computer And Data Communications (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、大略、コンピューティングシステム即ち計算機システムに関するものであって、更に詳細には、情報システムにおいて動作するアプリケーション間のコラボレーション（ｃｏｌｌａｂｏｒａｔｉｏｎ）即ち共同を与えるための方法及び装置に関するものである。
【０００２】
【従来の技術】
例えば、会計、給与、製造及び流通等の特定のビジネスドメイン機能性条件に対処するカスタム、スタンドアローン情報システムを実現するために会社は毎年何十億ドルも使っている。これらの別々のスタンドアローンシステムを構築することによって、ビジネスプロセス即ち事業処理の各個別的なセクションは他のものから分離されたものとなっている。
【０００３】
そのうち、コーポレイトインフォメーションテクノリジー（ＣＩＴ）即ち法人情報技術部門がこれらのカスタムシステムの内部での開発から離れ始め且つ外部でのエンタプライズ（企業）アプリケーションを購入することによりコストを最小とするようになった。エンタプライズアプリケーションはより一般的なものであり、予めパッケージされた製品で一般的なビジネス機能性を提供している。典型的に、エンタプライズアプリケーションは、アプリケーションシステム、ハードウエアプラットフォーム、オペレーティングシステム、第三世代及び第四世代言語、データベース、ネットワークプロトコル、管理ツールからなる異種の結合を包含している。これらのアプリケーションは、エンタプライズ即ち企業のレベルにおいて、それらを実現する会社に対して巨大な利益をもたらすものであるが、それは容易に統合即ち一体化可能なものではないので、それらは、単にプロセスアイランド「（ｐｒｏｃｅｓｓ ｉｓｌａｎｄｓ）」の増殖を悪化させるに過ぎない。
【０００４】
スタンドアローンエンタプライズアプリケーションは多くのビジネスプロセスを取扱うための強力なツールを提供している。然しながら、ある機能性は、しばしば、別個のアプリケーションにおいて重複しており、エンタプライズアプリケーションをバンドル即ち束ねる場合にコストを押し上げることとなる。エンタプライズアプリケーション間のカスタム機能性の統合即ち一体化は望ましいものではあるが、通常、コストが高過ぎ、且つ最初にエンタプライズアプリケーションを購入することが作るか買うかの決定の恩恵を打破る。ツール及びミドルウエアのベンダーはデータの統合に対する解決法を提供しているが、機能の統合（一体化）ではなく、且つこれらの解決法も実現するためには顧客がかなりコーディングを行なうことを必要とする。
【０００５】
【発明が解決しようとする課題】
本発明は、以上の点に鑑みなされたものであって、上述した如き従来技術の欠点を解消し、アプリケーション間の共通運用性を提供するモジュール型アプリケーション共同装置及び方法を提供することを目的とする。
【０００６】
【課題を解決するための手段】
一般的に、１つの側面において、本発明は、複数個のアプリケーションと通信を行なうための複数個のコレクタとインターチェンジ（交換）サーバーとを含むアプリケーション間においてインターオペラビリティ（ｉｎｔｅｒ−ｏｐｅｒａｂｉｌｉｔｙ）即ち共通運用性を与えるためのモジュール型アプリケーションコラボレータ（ｃｏｌｌａｂｏｒａｔｏｒ）即ち共同装置を提供している。交換サーバーは、アプリケーション共同モジュールとサービスモジュールとを包含している。サービスモジュールは、コネクタとアプリケーション共同モジュールとの間でメッセージを転送する。アプリケーション共同モジュールは２つ又はそれ以上のアプリケーション間での共通運用性を画定し且つトリガと該トリガに応答するトランズアクション（ｔｒａｎｓａｃｔｉｏｎ）とを包含している。該トリガは１つ又はそれ以上のコネクタからデータを受取ると活性化され、関連するアプリケーションへ転送するために１つ又はそれ以上のコネクタへデータを送給するトランズアクション即ち処理となる。
【０００７】
本発明の他の側面としては以下のような特徴を包含している。交換サーバーサービスモジュールはトランズアクションサービスとエラーサービスとを包含している。アプリケーション共同モジュールにおけるトランズアクションは、１つ又はそれ以上のアクションを包含しており、且つトランズアクションサービスは、各アクション（動作）及び関連するアクションをアンドゥ（ｕｎｄｏ）即ち取消すための補償用アクションを記録する。エラーサービスは交換サーバーにおけるエラーをモニタし、且つ、エラーを検知すると、トランズアクションの実行を停止し、且つ中断したトランズアクションをアンドゥ即ち取消すために所要の補償用アクションの実行をトリガする。
【０００８】
各コネクタは、アプリケーションインターフェースと、ビジネスモジュールと、交換サーバーインターフェースとを包含している。アプリケーションインターフェースは、コネクタとそれと関連するアプリケーションとの間でデータ及び方法を受取り且つ転送するためのＡＰＩマニュピュレータを包含している。ビジネスモジュールは、関連するアプリケーションとアプリケーション共同モジュールとの間で転送するためのデータを取扱うためのビジネス方法及びトランスフォームを包含している。交換サーバーインターフェースは、コネクタとアプリケーション共同モジュールとの間でデータ及び方法を転送するためのものである。
【０００９】
トランズアクションは有限状態マシンを包含している。コネクタとアプリケーション共同モジュールとの間のデータ転送は、交換サーバー内のサービスモジュールによって転送されるオブジェクトによるものである。サービスモジュールは、サブスクリプション（予約）サービスとパブリケーション（発表）サービスとを持ったイベントサービスを包含しているアプリケーション共同モジュールは、トリガに基づいて１つまたはそれ以上のコネクタに対して予約を行なう。該コネクタは、それと関連するアプリケーションからトリガデータを受取ると、イベントサービスに対してデータを発表し、該発表サービスが該データをアプリケーション共同モジュールへ送給することとなる。交換サーバーは、更に、交換サーバーコンポーネントに対してメッセージの送給を確保するために、ＲＡＳサービス及びメッセージサービスを包含している。
【００１０】
別の側面においては、本発明は、交換サーバーと第一及び第二アプリケーションコネクタとを包含する別個の機能を実現するアプリケーションを共同するためのモジュール型アプリケーション共同器を提供している。各コネクタは、交換サーバーと関連するアプリケーションとの間でデータを転送するためのものである。交換サーバーは、アプリケーション共同モジュールとサービスモジュールとを包含している。サービスモジュールは、第一及び第二コネクタとアプリケーション共同モジュールとの間でオブジェクトを転送するためのものである。アプリケーション共同モジュールは、第一及び第二アプリケーションの間での共通運用性を画定し且つトリガと該トリガに応答するトランズアクションとを包含している。該トリガは、第一及び第二コネクタのうちの第一のものからデータを受取ると活性化され、且つ該トランズアクションは、第一及び第二コネクタのうちの第二のものへデータを送給し、関連するアプリケーションへ転送する。
【００１１】
別の側面においては、本発明は、第一及び第二アプリケーション間で共通運用性機能を画定することを包含する異なるプロセス上で動作するアプリケーション間での共通運用性を与える方法を提供している。該共通運用性機能は、一般的なサブピース（ｓｕｂ−ｐｉｅｃｅｓ）即ち部分と、ベンダーに特定的な部分とに分割される。共通運用性機能の一般的な部分を格納し且つ実行するためのアプリケーション共同モジュールが形成される。第一及び第二アプリケーションと関連する共通運用性機能のベンダーに特定的な部分を格納し且つ実行するための２つのアプリケーション特定コネクタが形成される。最後に、アプリケーション共同モジュール及び２つのアプリケーション特定コネクタがリンクされて共通運用性機能を達成する。
【００１２】
本発明の利点の１つは、関連する機能性を統合即ち一体化させることによって、ビジネスが効率及び生産性を著しく改善することを可能とさせることである。その他の利点としては、プラットフォーム、オペレーティングシステム、ネットワークとは独立的に、いずれかのアプリケーションを他のいずれかのアプリケーションと統合即ち一体化させるために単一のパッケージしたプロダクト即ち製品を提供し、異なる機能エリアにおける複数個のエンタプライザアプリケーションが機能及びプログラム論理を共用する一体化した一式として動作することを可能とし、共同的ビジネスモデルの実現をサポートするレベルにおいてのプロセスアイランドを一体化させ、エンタプライズアプリケーションを容易にインストール及び除去することを可能とし、且つ参加するアプリケーションの複数個のバージョンにわたっての動作を行ない、それによりアプリケーションを一体化させるための柔軟で長期的な解決法を提供し且つアプリケーションのバージョンのアップグレイド及びカスタム一体化の高維持コストを取除くことである。
【００１３】
【発明の実施の形態】
図１を参照すると、モジュール型アプリケーション共同装置１０に対するアーキテクチュアは、１つ又はそれ以上のコネクタ３０及び１つ又はそれ以上のアプリケーション共同モジュール４０を具備する交換サーバー２０と、管理ツール５０と、開発ツール６０とを包含している。アプリケーション７０が各コネクタ３０へ結合している。
【００１４】
交換サーバー２０は分散型アプリケーションサーバーであって、それは全てのコンポーネントに対してオブジェクト指向型ランタイムプラットフォームを提供する。それは、更に、コンポーネントを管理し、形態を特定させ且つ制御するためのメカニズムを提供し、且つ典型的なサーバー環境において見いだされる信頼性、使用可能性、及びサービス性特徴、ＲＡＳ特徴、の全てを提供する。オブジェクトコンポーネントは、同一の管理ドメイン内のいずれかの交換サーバー内に常駐することが可能である。管理ドメインは、相互接続されているコネクタ、アプリケーション共同モジュール及び交換サーバーからなる一式である。マルチ協力交換サーバーは異なるプラットフォーム上で走ることが可能である。この場合におけるプラットフォームは、オペレーティングシステム、データベース（必要な場合）、及び／又はミドルウエアを包含する任意の基本ソフトウエア環境のことを意味している。コネクタ３０は、アプリケーションが交換サーバー２０と通信することを可能とする。コネクタ３０は、アプリケーション７０とインターフェースすることの詳細の全てを取扱い、且つ交換サーバーのオブジェクト及びデータモデルにおけるアプリケーションを表わすためにオブジェクト指向型インターフェースを提供する。コネクタ３０はアプリケーション７０と通信を行ない且つ交換サーバーのオブジェクト指向型モデルにおけるその他のアプリケーションとインターフェースするためのスキーマを与える。コネクタは２つの端部を有するものと考えることが可能である。「交換端部」はアプリケーションのデータ及び方法に対するオブジェクト指向型代理スキーマである。「アプリケーション端部」はアプリケーションのＡＰＩに対するドライバである。換言すると、コネクタの交換端部は、そのアプリケーション内に常駐するデータ及び方法（挙動）に対する交換サーバーへの「仮想」オブジェクトインターフェースを提供する。アプリケーション共同モジュールがコネクタを横断して再使用することを可能とするために、コネクタの交換端部によって提供される仮想オブジェクトインターフェースは、同一のアプリケーションクラスを有しているが異なるベンダーによって製造されているコネクタに対して同様である。コネクタ３０のアプリケーション端部は、アプリケーション７０から仮想オブジェクトへ情報を転送すること及び仮想オブジェクトに対してなされた変更（変更の要求）をアプリケーション７０へ戻すべく伝搬させることに関係している。コネクタ３０のアプリケーション端部は、更に、ベンダーＡＰＩを取扱うために必要とされるベンダーに特定的な論理を包含している。コネクタはアプリケーション及びベンダーに特定的なものである。
【００１５】
アプリケーション共同モジュール４０は、２つ又はそれ以上のアプリケーション７０を統合即ち一体化させるために必要な特定的な一体化ビジネス論理及び処理の流れを与える。アプリケーション共同モジュール４０は、一体化ビジネス論理の再使用可能な部分を含んでおり、一方、参加するビジネス論理のアプリケーション特定部分はコネクタ３０内に格納される。アプリケーション共同モジュール４０は、共同に参加する各アプリケーション７０に対して適宜のコネクタ及び交換サーバー２０を必要とする。アプリケーション共同モジュール４０はコネクタオブジェクト間で通信及び処理の流れを共同させる特別化したオブジェクトである。交換サーバー２０において実行するアプリケーション共同モジュール４０は任意のコネクタ３０の交換端部のみを見るに過ぎない。アプリケーション共同オブジェクトは交換サーバーのサービス（それらはオブジェクトである）、参加するアプリケーションのコネクタオブジェクト、及びその他のアプリケーション共同オブジェクトの間におけるメッセージの交換の形態でビジネスインタラクションを実現させる。
【００１６】
管理ツール５０は、エンドユーザの顧客が交換サーバー２０及びコネクタ３０をインストールし、形態を特定し、制御し、且つモニタすることを可能とする１組のツール及びインターフェースを提供する。
【００１７】
開発ツール６０は、顧客が自分自身のアプリケーション共同モジュール及びコネクタを開発することを可能とする１組のツール及びライブラリを提供する。ツールは交換サーバーのオブジェクト内のメタデータから駆動される。メタデータは、データを特性づける情報を記述するために使用される用語であり、時々、データ定義として呼称される。
【００１８】
アプリケーション７０は、会計、請求、顧客サービス、給与及びその他のビジネスプロセスをサポートする種々のビジネスアプリケーションを包含している。アプリケーションクライエントは、アプリケーションのユーザインターフェースを使用して関連するアプリケーション７０と対話即ち相互作用を行なう。一方、アプリケーション７０は非ビジネスアプリケーションとすることが可能である。アプリケーション７０の間の共通運用性はアプリケーション共同モジュール４０内において定義されている。
【００１９】
第一アプリケーション共同モジュール内に設けられた簡単化したビジネス共通運用性機能は、第一アプリケーションからデータを受取り且つその一部を新しいフォーマットで第二アプリケーションへ書込むことを必要とする場合がある。簡単化したビジネス共通運用性機能に対する流れ図を図２に示してある。図１及び２を参照すると、初期化されると、第一アプリケーション共同モジュール４０、及びそれと関連する（第一及び第二）コネクタ３０が交換サーバー２０内へインストールされる（１００）。第一アプリケーション共同モジュール４０がビジネス共通運用性機能を提供し、それは、少なくともトリガ（例えば、１つ又はそれ以上のアプリケーションからの情報の受取り）及びそのトリガに応答するトランズアクション（例えば、１つ又はそれ以上のアプリケーションへの新たなデータの書込み）を包含している。第一アプリケーション共同モジュール４０は、特定のビジネス共通運用性機能に対するトリガに基づいてイベントに対して予約を行なう（１０２）。この例においては、そのイベントは、第一アプリケーションと関連する第一コネクタにおいての情報の受領によってトリガされる（１０３）。第一アプリケーションから受取った情報に基づいて、関連するコネクタのアプリケーション端部が第一コネクタの交換端部へデータをパスさせる（１０４）。第一コネクタの交換端部が、その情報を、交換フォーマットオブジェクトへ変換し且つそのイベントを発表する（その情報の受領即ちトリガ）（１０５）。そのイベントは第一コネクタによって発生されたオブジェクトの形態で、そのイベントに対して予約されている第一アプリケーション共同モジュールへ（又は、そのイベントに対して予約をしたか又はそのデータを要求した任意のアプリケーション共同モジュールへ）送給される（１０６）。
【００２０】
その後に、第一アプリケーション共同モジュールはそれと関連するビジネス共通運用性機能を実行し且つ第二コネクタに対して送信するためのオブジェクトを発生する（１０８）。そのオブジェクト自身は第二コネクタへ送給され（１０９）、それは該オブジェクト（データ及び方法）を適宜のフォーマットへ変換し（関連するコネクタの交換端部によって）且つそのコネクタの関連するアプリケーションにおいて（コネクタのアプリケーション端部によって）所望の機能を開始させる（１１０）。この共同プロセスに関連する詳細は、個々のコンポーネントに対する詳細な説明に関連して以下に更に詳細に説明する。
【００２１】
交換サーバー
次に、図３を参照すると、単一の管理ドメイン内の交換サーバーは、種々のシステム部品がプラグ即ち接続されているバスとして見ることが可能である。交換サーバー２０は、アプリケーション共同モジュールインターフェース２００、コネクタインターフェース２０２、外部インターフェース２０３、コンフィギュレーション（形態特定）ツール２０５へ接続されているコンフィギュレーションツールインターフェース２０４、セットアップツール２０７へ接続しているセットアップツールインターフェース２０６、システム管理インターフェース２０９及び複数個のサービスモジュール２０８を包含している。
【００２２】
コンフィギュレーションツール２０５は、アプリケーション共同モジュール及びコネクタ特性をユーザがイネーブル即ち動作可能状態とさせ及び／又は変更することを可能とさせる。セットアップツール２０７は、交換サーバーにおいてアプリケーションコネクタをインストールし取除き且つコンフィギュア即ち形態を特定させる。システム管理インターフェース２０９は、業界標準（ＳＭＳ／ＳＮＭＰ）管理インターフェースをサポートし且つ交換サーバーの部品に対し管理インターフェースを与える。外部インターフェース２０３はツール及びその他の外部エージェントが交換サーバー２０内のオブジェクトへアクセスし且つ制御することを可能とする。
【００２３】
交換サーバー２０はアプリケーションコネクタ３０（図１）及びアプリケーション共同モジュール４０（図１）の実行の必要性をサポートするための部品指向型オブジェクト実行環境である。それは、大きなグレインの容器オブジェクトとして機能するオブジェクト及び部品からなる基本オブジェクトモデルを定義する。アプリケーションコネクタ及び共同は、この基本モデルで実行され且つ該交換環境内の大きなグレインの容器である。このことは、コネクタ及びアプリケーション共同モジュールが基本モデルから派生される強力なインターフェースを有することを可能とすると共に、同時的に、交換サーバーの個々の部品内にそれらの実行の詳細を内部に閉じ込める。
【００２４】
部品は、その他のオブジェクトを収容し且つランタイムでＤＬＬ（ダイナミックリンキングアンドローディング）を介してロードすることの可能な大きなグレインのオブジェクトである。オブジェクト及び部品はそれらの実行から厳格に分離されているそれらのインターフェースで定義される。部品は名前サービス２３０を介して命名され且つレジストリ２３２内に見いだされる。
【００２５】
コネクタはアプリケーションに対する代理として作用する部品である。コネクタは典型的にアプリケーション内のエントリに対する代理であるコネクタオブジェクト（仮想オブジェクトと呼ばれる）を管理する。アプリケーション共同モジュールは、交換サーバー内に存在しており且つ動的に登録したり又は登録を解除したりすることの可能なオブジェクトである。アプリケーション共同モジュールは必要に応じてオブジェクトを作成するか又は管理する。アプリケーション共同モジュールは、交換サーバーと同一の基本オブジェクトモデルを使用する交換サーバー２０内の副部品として見ることが可能である。交換サーバー内の全ては基本オブジェクトモデルで表現される。基本オブジェクトモデルはそれらを記述するためのオブジェクト及びメカニズムを定義する。基本オブジェクトモデルは、オブジェクト配向、分布、位置独立性、及びサポートされているプラットフォーム上でのオブジェクトを実行する能力を提供する。
【００２６】
オブジェクトはイベント及びメッセージを介して相互作用を行なう。イベント予約（ｓｕｂｓｃｒｉｐｔｉｏｎ）サービス２３５、イベント発表（ｐｕｂｌｉｃａｔｉｏｎ）サービス２３６及びメッセージサービス２４２は、アプリケーション共同オブジェクトがコネクタオブジェクトと相互作用を行なう場合の基本的なメカニズムである。交換サーバー２０はオブジェクトに「サービス」を与える。
【００２７】
交換サーバー２０におけるサービスモジュール２０８によって与えられるサービスは、それらの一体化タスクを実行するためのコネクタ及びアプリケーション共同モジュールによって必要とされるものである。本発明の１実施例においては、サービスはバス上のモジュールとして描写され且つ名前サービス２３０、レジストリサービス２３２、予約サービス２３５と発表サービス２３６とを包含するイベントサービス２３４、貯蔵所２３８、ダイナミックローディングサービス２４０、メッセージサービス２４２、規則エンジンサービス２４４、データ転送サービス２４６、トランズアクションサービス２４８、エラー及び例外サービス２６０を包含している。交換サーバーサービスは、動的にコネクタ及び共同を付加及び除去すること、新しいコンフィギュレーション即ち形態をテストすること、リソースを効率的に管理すること、滑らかなアップグレードを可能とすること、及びハードウエア及びソフトウエアの障害から優雅に立ち直ることの能力を包含している。交換サーバーサービスはこれらの基本オブジェクトモデルから構築されており且つ交換サーバーの部品が必要とする一般的に有用な特徴を全て包含している。
【００２８】
交換サーバー２０は、交換サーバーのスタートアップ処理を調整し且つオブジェクトが名前によってその他のオブジェクトを見つけだすことを可能とするためのレジストリサービス２３２を包含している。これは、新たなオブジェクトが使用可能になる場合のその動的な登録を包含している。動的な登録は、新たなアプリケーション共同モジュールがそれ自身を登録することを可能とする。動的登録は、又、他のクライエントが新たな共同がオンラインとなる場合にそれを見つけ出すことを可能とする。レジストリサービス２３２は、交換サーバー内のその他のツールによってアクセスすることの可能な貯蔵所２３８内の任意の部品と関連するメタデータ（ｍｅｔａ−ｄａｔａ）を格納する。
【００２９】
動的ローディングサービス２４０は、部品のランタイム部分をロードし且つ交換サーバー２０を再コンパイル又は再リンクする必要性なしにそれらを実行する。
【００３０】
イベントサービス２３４は発表（ｐｕｂｌｉｓｈ）及び予約（ｓｕｂｓｃｒｉｂｅ）通知メカニズムを提供する。イベントサービス２３４は情報プロバイダーを情報消費者から離脱させる。ここでの概念は、アプリケーション共同オブジェクトはどのコネクタがどのオブジェクトを発表するかについての親密な詳細を知ることなしに、あるコネクタによって発表されるあるビジネスオブジェクト／イベントに対して予約することを希望することが可能であるということである。イベント配達及び予約サービスは、予約受領（イベントに対し）、予約の格納、イベントの受領、イベント通知及びそのイベントに対して予約した各オブジェクト（アプリケーション共同モジュール、コネクタ、又は交換サーバー）に対するイベントに関連するオブジェクト転送（結果）を包含している。該イベントサービスは、予約リストを含む予約サービス２３５及び発表サービス２３６を包含している。
【００３１】
図３及び４を参照すると、イベントに対する発表及び予約のプロセスにおいて、予約はオブジェクト（コネクタ、共同又は交換サーバー）から受取られる（４００）。予約サービス２３５は予約リスト内に予約を格納する（４０２）。イベント通知を受取ると（４０４）、発表サービスが予約リストをチェックして、受取ったイベントにおいて興味があることを登録しているオブジェクトが存在するか否かを判別する（４０６）。オブジェクトがそのイベントに対して予約している場合には、発表サービスがそのイベント通知に関連するオブジェクトを特定のイベントの通知を要求する予約リスト内の各オブジェクトに対して配達する（４０８）。
【００３２】
再度図３を参照すると、メッセージサービス２４２は、地理的に分布した部品に対する非同期的な実行セマンティクス（ｓｅｍａｎｔｉｃｓ）を与える。メッセージサービス２４２は、交換サーバー２０が非同期的なトランズアクションモデルをサポートすることを可能とするための信頼性のあるキューイング（行列）及びメッセージファシリティ（機構）を包含している。更に、信頼性のある配達メカニズムが、参加する部品が使用可能でない場合には、メッセージ要求が参加する部品に対して永続的にキューイングすることを可能とする。該部品が再度スタートアップすると、それは下側に存在する永続的なキューから未処理のメッセージを取ることにより、それを処理する。１実施例においては、発表及び予約サービスがメッセージサービスの上に構築されており、参加する部品の全ての処理、システム及び地理的な境界を超越するイベントサービスを提供する。
【００３３】
規則エンジンサービス２４４は２つの側面を有しており、即ち定義側面及び実行側面を有している。該定義側面は、規則の定義と結びついており且つ実行側面は実行期間中におけるこのような規則の評価から構成されている。アプリケーション共同モジュールは、アプリケーション共同モジュール内において実施されるされるビジネス規則を定義し且つ評価するためにこのサービスを使用する。コネクタも、該コネクタ内においてビジネス条件を評価し又は新たなビジネス論理を定義する場合にはこのサービスを使用する。最後に、イベントサービス２３４は、メッセージのルート付け及び発表のためにメッセージのセマンチック即ち意味論的な内容を評価するために規則エンジンサービス２４４を使用することが可能である。
【００３４】
データ転送サービス２４６はデータのシンタクチック（ｓｙｎｔａｃｔｉｃ）及びセマンチック（ｓｅｍａｎｔｉｃ）変換の両方を実施するために設けられている。このような変換の例は、簡単な整数からキャラクへの変換から共同期間中におけるセマンチックな内容及び意味の変換までの範囲にわたる。例えば、このようなセマンチック変換を与える条件は、第１アプリケーションにおける「従業員（ｅｍｐｌｏｙｅｅ）」がそれと関連する２つのフィールド（従業員ＩＤ番号（８ビット）及び名前）を有しており、一方第２アプリケーションにおける「従業員（ｅｍｐｌｏｙｅｅ）」がそれと関連する３つのフィールド（従業員ＩＤ番号（１０ビット）、名前、社会保障番号）を有している場合に発生する。従業員データを第１アプリケーションから第２アプリケーションへ転送する場合に、２つのシステムを同期させるために２つの変換が使用される場合がある。１つの変換は、従業員番号（８桁乃至１０桁）をマッピングすることが必要とされ、且つ第２変換は第１アプリケーションのデータベースから従業員の社会保障番号を抽出し且つその情報を第２アプリケーションのシステムへ付加することが必要とされる。典型的に、これらの変換に対するターゲットは、アプリケーション共同モジュール及びコネクタにおいて実行される変換によって定義される。コネクタも、必要な場合には、それらの実行内容内において変換を定義することが可能である。
【００３５】
トランズアクションサービス２４８は交換サーバーを介してリンクされているアプリケーションにわたっての一貫性を与える。交換サーバー２０は別個の非同期的なトランズアクションをサポートするトランズアクションモデルに補償用トランズアクションを供給する。補償用トランズアクションは、前のトランズアクソンの効果をセマンチック的に即ち意味論的にアンドゥ即ち取消すことを可能とするトランズアクション（処理）である。トランズアクションサービス２４８は１つ又はそれ以上のキュー（行列）２４９（不図示）を包含しており、且つ非同期的なトランズアクションを実行するためのメッセージプロセサ２５０（不図示）を包含している。トランズアクションサービス２４８はアプリケーションにわたって２つの態様で一貫性を与える。格納及び転送キューは、オンラインではないアプリケーションに対して取り決められているトランズアクションを管理する。第２に、トランズアクション記録キューはトランズアクション動作を記録するために使用される。トランズアクション記録キューはインタラプトされたトランズアクションと関連する第１動作の実行前にシステムの状態を再度確立するために、インタラプトされたトランズアクションから回復するために使用される。
【００３６】
１実施例においては、一貫性を維持し且つトランズアクション実行中において受取った障害又はその他のシャットダウンから回復するためにサガ（ｓａｇａ）を使用する。「サガ（ｓａｇａ）」は、１組のステップ（即ちサブトランズアクション）及び補償用サブトランズアクション（ｓｕｂ−ｔｒａｎｓａｃｔｉｏｎ）からなる接続されている別個のトランズアクションの二重にリンクされたリストである。一貫性を補償するために、本発明は、サガ内の全てのサブトランズアクションが完了されるか、又はいずれかの部分的な実行が補償用サブトランズアクションでアンドゥ即ち取消されるかのいずれかを確保する。サガ内の各サブトランズアクションは同一の一貫性のある状態を取るものではない。従って、サブトランズアクションが完了すると、他のサブトランズアクションを待つことなしに同一のサガをコミットすることが可能であり、従って、その結果を同時的なトランズアクションの残部へ解放することが可能である。インタラプト即ち中断の場合には、アプリケーション共同モジュールは、インタラプトしたトランズアクションの前方又は後方の両方の回復を試みることが可能である。補償用トランズアクションは、エラー及び例外サービス２６０に関連して詳細に説明する。
【００３７】
次に、図３及び５を参照すると、交換サーバーにおいて一貫性を維持する方法において、トランズアクションサービスは例えばイベント通知に応答するアプリケーション共同モジュールのようなオブジェクトによってトランズアクションが開始されるべきである通知を受取る（５００）。アプリケーション共同モジュールがイベントの通知を受取ると、それはサガ開始トランズアクション要求を開始させる（又は、交換サーバー内のいずれかのオブジェクトがトランズアクションを開始する場合）。トランズアクションサービス２４８は、アプリケーション共同モジュールによって開始されたトランズアクションと関連するアクション即ち動作を格納するために記録用キュー（行列）を割当てることによって、該サガ開始要求に応答する（５０２）。トランズアクションサービス２４８は、該記録用キューと関連するサガ識別子をトランズアクション要求を開始させるオブジェクトへリターンさせる（５０４）。
【００３８】
その後に、アプリケーション共同モジュールはそのビジネス共通運用性機能に従ってステップ／アクション（動作）を実行する。各アクション（トランズアクションステップとも呼ばれる）が開始されると、アプリケーション共同モジュールは適宜のサガキュー内にそのステップを付加する要求を発生する。トランズアクションサービスは、ループ内に入り且つ要求するオブジェクトからの次の要求を待つ（５０６）。受取ることの可能な要求のタイプは、付加（５０８）、削除（５１０）、修正（５１２）、獲得（５１４）、取消し（５１６）、終了トランズアクション（５２６）である。
【００３９】
次の要求が「付加（ａｄｄ）」要求である場合には、「付加」要求と関連するアクションが、補償用トランズアクション情報と共に記録用キュー内に格納される（５１８）。次の要求が「削除（ｄｅｌｅｔｅ）」要求である場合には、該キューからの要求されたエントリ（アクション（ａｃｔｉｏｎ））が削除される（５２０）。次の要求が「修正（ｍｏｄｉｆｙ）」要求である場合には、該キュー内のエントリがその要求に従って修正される（５２２）。次の要求が「獲得（ｇｅｔ）」要求である場合には、該キュー（サガ）の指定された部分が要求するオブジェクトへリターンされる（５２３）。最後に、次の要求が取消し要求である場合には、該キュー内に格納されるアクションと関連する補償用トランズアクションシーケンスがサガから検索され且つ開始される（５２４）。トランズアクションの完了時に（終了トランズアクション要求を受取ると）、該サガは除去される（５２６−５３０）。
【００４０】
１実施例においては、トランズアクションがインタラプトされる場合には、該トランズアクションサービス内の補償用エンジンが補償用アクションを実行して部分的に完了したトランズアクションと関連する記録用キュー内に格納されている該サガを取消す。トランズアクションをアボート即ち打ち切ることは、サガキュー内の各アクション（サブトランズアクション）に対する対応する補償用トランズアクションを実行することによって達成される。該補償用トランズアクションは、論理的即ちセマンチックな「ロールバック（ｒｏｌｌｂａｃｋ）」を与える（何故ならば、そのトランズアクションは既にコミットしているからである）。例えば、「従業員を付加（ａｄｄ ｅｍｐｌｏｙｅｅ）」に対する補償用トランズアクションは「従業者を除去（ｒｅｍｏｖｅ ｅｍｐｌｙｅｅ）」である場合がある。しかしながら、この補償用トランズアクションはそんなに簡単なものではない場合がある。例えば、人的リソースのユーザは、新たな従業者（ｅｍｐｌｏｙｅｅ）がシステムから単純に消え去った場合には不可解に思う場合がある。何故ならば、別の位置における別の部門内に位置されている可能性のある何等かのプロジェクトトラッキングシステムがそれを拒否するからである。従って、その他のより複雑な補償用トランズアクションが定義される。
【００４１】
１実施例においては２ＰＣ（２フェーズコミット（Ｐｈａｓｅ Ｃｏｍｍｉｔ））調節器が、アプリケーション共同に参加する複数個のキューに対するメッセージのキューイング即ち行列化を調整するために使用される。単一の共同（ｃｏｌｌａｂｒａｔｉｏｎ）が５つのアプリケーションに対してメッセージを送給するために下側に存在するメッセージサービスを与える場合には、２フェーズコミット調節器は、５つのメッセージの全てが送信されるか又は該メッセージのいずれもが送信されないかのいずれかを保証する。
【００４２】
コネクタにおいて非同期的なトランズアクションセマンチックを与えることは、トランズアクションのオブジェクト、そのトランズアクション方法を識別し、且つこれらの方法を補償するために必要な機能（補償用トランズアクション）を与えることを包含している。補償用トランズアクション機能の内容は、共同に特定的であって、その処理論理が各方法に対して異なるものであることが可能であることを暗示している。殆どの場合においては、補償用トランズアクションを手でコーディングすることが必要となる。１実施例においては、交換サーバーは、任意のコネクタにおいて補償用トランズアクション機能の実行を動的にイネーブル及びディスエーブルさせることが可能である。
【００４３】
エラー及び例外サービス２６０はエラーを取扱うための通知及びフック（ｈｏｏｋ）を与える。エラー及び例外サービス２６０は、そのエラーが発生した部品、そのような部品の位置、エラー番号及びストリングの形態でのそのエラーの性質を識別する任意のエラーの通知を与える。トランズアクションがインタラプトされる場合には、そのエラーサービスはそのトランズアクションサービスに対してアンドゥ（取消し）要求を発生し、サガ内に格納されている「アンドゥ（ｕｎｄｏ）」アクションを開始させる。一方、エラー及び例外サービスは、適宜のアプリケーション共同モジュールへそのエラーを通知することが可能である。該アプリケーション共同モジュールは、従って、インタラプトしたトランズアクションの前方又は後方の両方の回復を試みようとすることが可能である。後方回復においては、該アプリケーション共同モジュールは、該トランズアクションサービスに対してアンドゥ（取消し）要求を発生し、インタラプトされたトランズアクションにおいて完了した全てのトランズアクションステップをアンドゥ即ち取消す。一方、前方回復は、特定のエラーを評価し且つそれが臨界的なものであるか否かを決定することによってインタラプトしたトランズアクションを継続しようとする。そうでない場合には、代替手段が使用される。
【００４４】
例外サービスは、そのサービスのユーザが処理中における例外の場合には容易に登録を取消すことの可能なリソースへ登録することを可能とする。
【００４５】
その他のサービスは交換サーバー２０によって与えることが可能であり、それは、コネクタ及びアプリケーション共同モジュールがある演算を実行するために予め定めたスケジュールを有するようにさせるタイマーサービス、交換サーバーにおける多くの演算を並列的に実行することを可能とさせるスレッド及び同期サービス、ライセンシングサービス、アプリケーション外部のオブジェクト又はオブジェクト状態を持続的に格納することを可能とする持続サービス、部品インターフェースの変更されたバージョンを検知するためのインターフェースバージョンサービス、例えばアップグレイドされるか又はダウングレイドされるコネクタのような変更された部品を検知する部品バージョンサービス、アップグレイディング、バグの報告及び診断、性能モニタリング及びチューニングを包含するその他のＲＡＳ特徴サービスを包含している。
【００４６】
１実施例においては、交換サーバー２０（及びアプリケーション共同モジュール）は、ジャバ（Ｊａｖａ）で構成されている。何故ならば、それは実行のクロスプラットフォーム能力を有しているからである。１実施例においては、交換サーバーのバックボーンはアメリカ合衆国カリフォルニア州フォスターシティのビスジェニック（Ｖｉｓｉｇｉｎｉｃ）社によって作成されジャバで書かれたＣＯＲＢＡオブジェクトリクエストブローカー（ＯＲＢ）である。このＯＲＢはジャバランタイム環境で動作する。必要なＣＯＲＢＡサービスはジャバから利用される（クライエントに対するジャバスタブ（ｓｔｕｂ）及びサーバーに対するジャバスケルトン（ｓｋｅｌｅｔｏｎ）からなるジャバ世代に対してＩＤＬを使用）。交換サーバーの中でこの構成における通信トランスポートはＩＩＯＰ（Ｉｎｔｅｒｎｅｔ ｉｎｔｅｒ ｏｒｂ ｐｏｒｔｏｃｏｌ）又はメッセージング（ｍｅｓｓａｇｉｎｇ）即ちメッセージサービスである。該コネクタの２つの半分の間又は交換サーバーとコネクタとの間の通信構成はＩＩＯＰ又はメッセージングとすることが可能である。
【００４７】
交換サーバー２０に対する処理の流れを図６に示してある。次に、図３及び６を参照すると、スタートアップ即ち開始時において、交換サーバーが初期化される（６００）。この初期化は、アプリケーション共同モジュール及びコネクタ情報及び交換サービス情報を包含するレジストリサービス２３２と関連する貯蔵所からコンフィギュレーション（形態）情報を検索することを包含している。その後に、該コンフィギュレーションにおいてエラーを発生しなか否かを判別するためのチェックが行なわれる（６０２）。カウンタ又はアプリケーション共同モジュール仕様内にコンフィギュレーションエラーがある場合、又は何等のサービスが無効であり且つサポートされていないオプションが特定される場合に発生する場合がある。例えばメッセージングサービスが使用可能でないというような臨界的なエラーが発生すると（６０４）、その初期化は停止する（６０６）。
【００４８】
エラーが検知されないか又はエラーが臨界的なものではない場合（例えば、コネクタが何等かの特性を特定するものではないがデフォルトを有している）、交換サーバー内のサービスの全てが使用可能であるか否かを判別するためのチェックが行なわれる（６０８）。いずれかの臨界的なサービスが使用可能でない場合には（６１０）、初期化は終了する。そうでなければ、交換サーバーは各インストールされ且つコンフィギュア即ち所定の形態とされたコネクタ（６１２）及びアプリケーション共同モジュール（６１４）を例示する。その後に、交換サーバーは定常状態ループに入り、サービス要求を待つ。サービス要求を受取ると（６１６）、交換サーバーは、その要求がシャットダウンリクエストであるか否かを判別するためのチェックを行なう（６１８）。
【００４９】
そうである場合には、交換サーバーはシャットダウン手順を実行する（６２０）。そうでない場合には、交換サーバーはその要求をサービスし（６２２）、次いでサービスに対する次の要求を受取るまでアイドル状態となる。
【００５０】
要求のサービスを図７により詳細に示してある。要求のタイプが決定される（７００）。その要求が交換サービス要求である場合には、分岐Ａが喚起される。その要求がトランズアクション要求である場合には、分岐Ｂが喚起される。その要求が管理要求である場合には、分岐Ｃが喚起される。最後に、その要求がコンフィギュレーション要求である場合には、分岐Ｄが喚起される。
【００５１】
分岐Ａにおいて、交換サービス要求は、交換サーバー（７０２）における適宜の交換サーバーサービスモジュールによって処理され、結果がリターンされる（７０４）。例えば、その要求はイベント通知の形態である場合がある。イベント通知はイベントサービスによって受取れ、その後に、オブジェクトが、受取った特定のイベント通知に対して予約されている各オブジェクト（アプリケーション共同モジュール、コネクタ又はそれの他の交換サーバー）へ配布される。
【００５２】
分岐Ｂにおいて、トランズアクション要求のタイプが決定される（７０６）。１実施例においては、トランズアクションのタイプは、トランズアクションサガの作成（トランズアクションサガキューを作成するため）、及びサガ演算（付加、削除、リターン、又はアンドゥ（取消し）サガ）を包含している。要求がトランズアクションサガ作成である場合には（７０７）、トランズアクションサービスが新たなトランズアクションに対して記録用のキューを割当て且つそのサガに対する識別子をリータンさせる（７０８）。一方、受取ったトランズアクションがサガ演算である場合には（７０９）、トランズアクションサービスは既存のサガ上で動作し且つその操作のアクノレッジメント（肯定応答）をリターンするか又はアンドゥ（取消し）要求に応答して補償用トランズアクションを実行する（７１０）。
【００５３】
分岐Ｃにおいては、管理要求がタイプされ（７１２）、その後に、適宜のサービスによって操作される（例えば、エラー及び例外サービスによって）（７１４）。１実施例においては、該管理要求はエラーのロギング（ｌｏｇｇｉｎｇ）即ち記録付け、交換サーバードメインにおいてのオブジェクトの開始、停止及びパス、性能データ回収、及びイベントロギング及び診断を包含している。管理要求は、交換サーバー内のオブジェクトによって又はシステム管理インターフェース２０９を介してシステム管理ツールから発生させることが可能である（図３）。分岐Ｄにおいては、コンフィギュレーション要求がコンフィギュレーションサービスによって操作される。コンフィギュレーション要求は、コネクタ、共同、交換サーバーオブジェクトによるか、又はコンフィギュレーションツールによって発生させることが可能である。コンフィギュレーション要求は、アプリケーション共同モジュール及びコネクタのインストール（据付け）又は除去、コネクタ又はアプリケーション共同モジュールの活性化又は脱活性化、及びバージョン追跡及びアップグレイド機能を包含している。コンフィギュレーションサービスは、コンフィギュレーション要求を実行し（７１６）且つ要求するオブジェクト（又は（ユーザ）に対してアクノレッジメント（又は結果）をリターンする（７１８）。その後に該プロセスはステップ６２２において継続し（図６）、サービスするための次の要求を待つ。
【００５４】
次に図３及び８を参照すると、シャットダウンプロセス（図６におけるステップ６２０）は、各アプリケーション共同モジュールへのシャットダウン要求を発生することを包含している（８００）。ステップ８００において発生されたシャットダウン要求に対するアクノレッジメント（肯定応答）信号が受取られたか否かの判別を行なうためのチェックが行なわれる（８０２）。各共同はそれ自身のシャットダウン手順を実行することによってシャットダウン要求に応答する。この実行の一部として、アクノレッジメント（肯定応答）信号が交換サーバー２０へリターンされる。アクノレッジメント信号が受取られなかった場合には、タイムアウトが経過したか否かを判別するためにチェックが行なわれる（８０４）。１実施例においては、そのタイムアウトは、各部品の順序だったシャットダウンを可能とすべく決定される。長いタイムアウトは、タスクを完了することを可能とする。選択されているタイムアウトが短か過ぎる場合には、ある部品において実行中のあるトランズアクションがトランズアクション全体を完了する前に終了される場合があり、補償用トランズアクションを実行することを必要とする。一方、そのタイムアウトは、システムのすぐさまのシャットダウンを強制するために短い時間期間に設定することが可能である。
【００５５】
タイムアウトが未だに経過していない場合には、交換サーバーは、最も短いタイムアウトの経過か又は最後のアクノレッジメントを受取るのを待つ。
【００５６】
そのタイムアウトが経過すると、交換サーバーは（アプリケーション共同モジュールを介して）トランズアクションサービス２４８によるサービスに対するアンドゥ（取消し）トランズアクションを開始する（８０６）。その後にトランズアクションサービスは交換サーバー内において一貫性を維持するために必要な補償用トランズアクションを実行する（８０７）。
【００５７】
最後のアクノレッジメントを受取るか又は最後の補償用トランズアクションの完了の後に、交換サーバー２０は各例示した即ち具体化したコネクタに対するコネクタシャットダウンを発生する（８０８）。各コネクタは、それ自身のシャットダウン手順を実行することによってシャットダウン要求に応答する。この実行の一部として、アクノレッジメント信号が交換サーバー２０へリターンされる。アクノレッジメント信号の全てが受取られたか否かの判別を行なうためのチェックが行なわれる（８１０）。アクノレッジメント信号が受取られていない場合には、タイムアウトが経過したか否かを判別するためのチェックが行なわれる（８１２）。１実施例においてはこのタイムアウトは、各コネクタの秩序だったシャットダウンを可能とすべく設定されている。そのタイムアウトが未だに経過していない場合には、交換サーバーは、最後のアクノレッジメントの受領か又は最も短いタイムアウトの経過を待つ。
【００５８】
そのタイムアウトが経過するか又は最後のアクノレッジメント信号を受取ると、交換サーバーは、それ自身のサービス及び部品の秩序だったシャットダウンを開始する（８１４）。
【００５９】
アプリケーション共同モジュール
典型的に、アプリケーションの一体化は、１つのアプリケーションのオブジェクトと別のアプリケーションのオブジェクトとの「協力（ｃｏｏｐｅｒａｔｉｏｎ）」によって達成される。交換サーバーにおいては、アプリケーションオブジェクトはそれらの夫々のコネクタによって仮想オブジェクトとして表わされている。これらのビジネス仮想オブジェクトは他のビジネス仮想オブジェクト（別のアプリケーションから）と協力し且つアプリケーション統合機能を実行するために「サービス」オブジェクトのファシリティ（機構）を利用する。この種々のアプリケーションオブジェクト間での協力即ち相互作用は、アプリケーション統合セマンチックス（ｓｅｍａｎｔｉｃ）を定義すると共に捕獲し且つ交換サーバーにおけるアプリケーション共同モジュールの形態でカプセル化され且つ格納される。全てのマルチオブジェクトアプリケーション共同モジュールは交換サーバー内のファーストクラスエンティティとして格納され且つ処理され且つアプリケーション共同オブジェクトとして呼称される。このアプリケーション共同オブジェクトは、アプリケーションの統合を実行するために必要なビジネス論理及びブジネス処理の流れをカプセル化する。
【００６０】
次に図１，３，９を参照すると、アプリケーション共同モジュール４０は、オブジェクト表示モジュール９００、ビジネスシナリオモジュール９０２、メッセージング通信モジュール９０４を包含している。
【００６１】
アプリケーション共同モジュール４０は、アプリケーション共同オブジェクトとして交換サーバー２０内に常駐している。アプリケーション共同オブジェクトは、全ての参加する交換（コネクタ及び「サービス」）オブジェクト及びこれらのオブジェクトの間の「ビジネスシナリオ（ｂｕｓｉｎｅｓｓ ｓｃｅｎａｒｉｏ）」を識別する。
【００６２】
オブジェクト表示モジュール９００は、消費方法、受信方法、オブジェクト発生方法を包含するアプリケーション共同オブジェクトと関連する方法を包含している。このモジュールは、又、与えられた共同に参加するために必要な抽象化された再使用可能なクラス及び方法を定義する。メッセージング中心モジュール９０４はイベント通知（ｅｖｅｎｔ ｎｏｔｉｆｉｃａｔｉｏｎ）及び予約（ｓｕｂｓｃｒｉｐｔｉｏｎ）を処理する。イベント予約は、イベント予約サービス２３５へ送信するために発生される。イベント通知はイベント発表サービス（ｅｖｅｎｔ ｐｕｂｌｉｃａｔｉｏｎ ｓｅｒｖｉｃｅ）２３６から受取られる。
【００６３】
ビジネスシナリオモジュール９０２は、協力するアプリケーション間でのメッセージ交換の時間的順番を定義するビジネスシナリオを包含している。それは、更に、このようなメッセージに対するこれらのアプリケーションオブジェクトの反応を定義する。ビジネスシナリオを定義することは、共同するアプリケーションオブジェクトに対する参加用の属性及び方法を識別することを包含している。オブジェクト反応挙動は、無条件的に又は該オブジェクトの状態に基づいてイネーブルさせることの可能な１組の制限的拘束条件及び原因となる規則によって記述される。
【００６４】
アプリケーション間の全ての通信は、アプリケーション共同オブジェクトによって管理され且つ施行される。アプリケーション共同オブジェクトは、交換ユーザがコネクタオブジェクト間での相互作用を定義することを可能とする。アプリケーション共同モジュールの一例は、自動的にインボイス（請求書）を発生し且つ顧客サポートアプリケーションが新たなサポートコールをログ（ｌｏｇ）する場合に、金融システムにおける売掛金エントリへその額を付加することである。アプリケーション共同オブジェクトは、ビジネスシナリオモジュール９０２に格納されている１組のビジネスシナリオによって定義されている。アプリケーション共同モジュールは、単一のビジネス処理指向型機能を有している。幾つかの適用可能な共同が任意の２つのアプリケーションの間で存在する場合があり、且つ共同は２つを超えるアプリケーションが関与する場合がある。単一のビジネス処理機能は、シナリオとも呼ばれる複数個のトランズアクションが関与する場合がある。例えば、２つ以上のアプリケーションを横断して従業員を模倣するアプリケーション共同モジュールは、雇用、解雇、及びステータス変化を取扱うことを必要とし、それらは全て同一アプリケーション共同モジュールに対して異なるシナリオを構成する。
【００６５】
アプリケーション共同モジュールはプロパティシートを介して制御される。プロパティシートは、アプリケーション共同モジュール又はその参加するアプリケーションオブジェクトのいずれかのコンフィギュレーション即ち形態を制御するためのカスタマー（顧客）インターフェースである。アプリケーション共同モジュールプロパティの例は診断レベル、ユーザ名前／パスワード、及び統合シナリオ特定特性である。参加するアプリケーションオブジェクトのプロパティは、これらのアプリケーションオブジェクトの属性のいずれかに対する最大値、最小値、デフォルト値、及び統合特定特性の値の設定を包含している。
【００６６】
アプリケーション共同オブジェクトはファーストクラスエンティティであるので、それらは例えば継承、ポリモリフィズム（ｐｏｌｙｍｏｒｐｈｉｓｍ）即ち多形性、等の典型的なオブジェクトプロパティ（特性）を表示する。アプリケーション共同オブジェクトは、別の共同においてアプリケーションオブジェクトとしてそれが参加することを可能とさせるために、良好に定義されたインターフェースを露呈させる。
【００６７】
次に図１０を参照すると、ビル・バイ・コール（ｂｉｌｌ−ｂｙ−ｃａｌｌ）ビジネスシナリオ用のオブジェクト間のメッセージの流れが示されており、その場合に、１つのオブジェクトから別のオブジェクトへの矢印がこれらのオブジェクト間での順番の付けられたメッセージの流れとしてのオブジェクト相互作用を画定する。ビジネスシナリオは、メッセージの流れ、参加するアプリケーションオブジェクト、それらの属性及び方法、及びそれと関連するビジネス規則を識別することを包含する。アプリケーション共同モジュールにおいていずれかのビジネスシナリオを実行することは、典型的に、交換サービスオブジェクト、コネクタオブジェクト又は別のアプリケーション共同オブジェクトによって発生されるイベント又はメッセージによってトリガすることが可能である。
【００６８】
再度、図９を参照すると、各シナリオ又は１組のオブジェクト相互作用は、有限状態マシン（ＦＳＭ）９０６へ還元させ且つカプセル化される。イベントによってトリガされる場合には、ＦＳＭは処理の流れを表わす。更なる制御を与えるために、イベント、条件及びアクションを直接的にＦＳＭ内において操作し、相互作用の挙動を修正することが可能である。各シナリオと関連しているＦＳＭは、そのアプリケーション共同オブジェクトに対する属性として格納されており、且つそのアプリケーション共同オブジェクトへ送給されるイベント又はメッセージによってトリガされる。
【００６９】
ＦＳＭ実現例は、ＦＳＭ内の「アクション（ａｃｔｉｏｎ）」が、実行時間におけるアプリケーション共同モジュール及び参加するアプリケーションオブジェクトに対する位置、トランズアクション及び性能条件に基づいて、以下のメカニズムのうちの１つへ変換するように分解することが可能である。これらのメカニズムは、同期的である関数（機能）ディスパッチング（簡単なローカル又はリモートな関数（機能）呼出し）、関数（機能）の非同期的な実行を行なう点を除いてリモート機能をディスパッチングに類似しているメッセージング（これはメッセージングシステムの信頼性のあるデリバリ（配達）能力を使用して何等かの機能（関数）を実行する要求を有するリモート（遠隔）オブジェクトへメッセージを送給することによって達成される）、及び同一及び別のＦＳＭ内のイベント発生又は状態変化、を包含することが可能である。ファンクションコール即ち関数（機能）呼出しは、メッセージング又はイベントサービスを介して受取ったオブジェクト又はデータの属性に関して操作を行なうためのビジネス規則を実現することが可能である。
【００７０】
１実施例においては、アプリケーション共同モジュールはジャバ言語で発生され且つ基本共同ジャバクラス及びインターフェース（オブジェクトシステムにおけるサブクラス処理（ｓｕｂ−ｃｌａｓｓｉｎｇ）としても知られている）を拡張する。
【００７１】
次に、図１を参照すると、アプリケーション共同モジュールを構築する方法において、アプリケーション共同モジュール構築器がクロスアプリケーション統合を達成するために必要な相互に関連したアプリケーションオブジェクトのコンフィギュレーション即ち形態を定義する（１１００）。このようなコンフィギュレーションは、簡単なものからより複雑な統合、例えばＥＲＰ（エンタプライズ・リソース・プラニング）アプリケーションを具備する供給チェーン最適化アプリケーションにおける製造スケジュールプランの統合等にわたる単一のビジネスプロセスを表わすものとすべきである。このコンフィギュレーション即ち形態を定義することは、参加するアプリケーションオブジェクト（１１０２）、それらの属性及び所要のアプリケーション統合（１１０４）を実施するのに必要な方法及びアプリケーションオブジェクト間の「関係」（１１０６）を識別することを包含している。
【００７２】
その後に、アプリケーション共同モジュール内のアプリケーションオブジェクト間のメッセージ相互作用を駆動する１組のビジネスシナリオが識別される（１１０８）。各シナリオはビジネスプロセス、システム管理シナリオ、又はユーザの観点からの１組の「ビジネス」トランズアクション（取引）を表わす場合がある。単一のビジネスプロセスにおいて論理的に参加する機能（関数）が実行する１組の全てのシナリオは１つのアプリケーション共同モジュール内にグループ化される。
【００７３】
該シナリオを定義した後に、アプリケーションオブジェクトの構造及び挙動を合体させ且つ抽象化する総括的な組のクラス及びそれらの関係が識別される（１１１０）。
【００７４】
最後に、その挙動がモデル化される（１１１２）。該モデルは、必要である場合に、より細かいグレイン即ち粒状の形態を作成するための繰返しステップへ分割することによって分解することが可能である（１１１４）。このことは、ソリューション即ち解答が最も高いビジネスモデルから開始し、且つ必要に応じて微細なグレイン即ち粒状のサービスオブジェクトへ繰返し下がるような反復的開発を可能とする。
【００７５】
アプリケーション共同オブジェクトは同一のアプリケーションクラスに対する異なるベンダーから派生されるアプリケーションオブジェクトにわたって再使用可能である。このことは、アプリケーション共同オブジェクトをして所要のビジネス挙動（方法）に対する参加するアプリケーションオブジェクトを要求させることにより且つアプリケーション共同オブジェクト自身の一部としてこのような挙動を組込むか又は開発することがないことによって達成される。全てのこのようなベンダー特定機能性はコネクタ内にカプセル化されており、アプリケーション共同モジュールオブジェクトが同一のアプリケーションクラスに対して異なるベンダーのアプリケーションを横断的に再使用することが可能であることを許容している。
【００７６】
アプリケーション共同オブジェクトは、セットアップツール及びコンフィギュレーションツールを使用して交換サーバー内にインストールされている。コンフィギュレーションツールは、例えば参加するアプリケーションのいずれかからもその値を得ることが可能なものでない場合には、ビル・バイ・コール（ｂｉｌｌ−ｂｙ−ｃａｌｌ）共同における請求率を設定すること等のアプリケーション共同モジュールと関連するプロパティシートを設定することを可能とする。
【００７７】
更に、アプリケーション共同モジュールは、例えば、具体化（例示化）特性（スタートアップ又はイベント）、トランズアクションセマンチック（参加するアプリケーションを具備する同期的２ＰＣ又は補償用トランズアクションを具備する非同期的メッセージング）、実行タイミング（スケジュールされており且つ計時される）、及び任意の参加するビジネスシナリオの可能化（イネーブル／ディスエーブル）等のランタイム及び処理基準を制御する種々のプロパティ即ち特性のコンフィギュレーションを行なうことを可能とする。
【００７８】
アプリケーション共同モジュール４０（図１）と関連する処理の流れを図１２に示してある。次に図３及び１２を参照すると、アプリケーション共同モジュールは、インスタンシエーション（ｉｎｓｔａｎｔｉａｔｉｏｎ）即ち具体化（例示化）プロセスの一部として交換サーバー２０から初期化要求を受取る（１２００）。アプリケーション共同モジュールは、ビジネスシナリオモジュール内に格納されているビジネスシナリオと関連するイベント予約を発生し（１２０２）、次いで初期化要求に応答して交換サーバー２０へアクノレッジメント（肯定応答）信号をリターンする（１２０４）。その後に、アプリケーション共同モジュールは、予約されているイベントのデリバリ（配達）を待機し、共同（ｃｏｌｌａｂｏｒａｔｉｏｎ）の開始又は交換サーバーからの管理要求（例えばシャットダウン）をトリガする。
【００７９】
イベント通知（関連するオブジェクトを受取るか、又は交換サーバー２０又はアプリケーションコネクタ３０から受取ったオブジェクトに応答して、ビジネスシナリオモジュール９０２（図９）は該オブジェクトにおいて要求されている方法を実行する。該オブジェクトがイベント通知（１２０７）である場合には、ビジネスシナリオモジュールはトランズアクションサービスから新たなサガを要求する（１２０８）。新たなサガ要求アクノレッジメントをトランズアクションサービスから受取ると、ビジネスシナリオモジュール９０２（図９）はビジネスシナリオモジュール内に格納されているシナリオと関連する有限状態マシンを開始させ（１２１０）及び実行する（１２１１）。該シナリオ内の各サブトランズアクション（ｓｕｂ−ｔｒａｎｓａｔｉｏｎ）において、ビジネスシナリオモジュールがトランズアクションサービスが下側に存在するサブトランズアクションをサガ内に記録することを要求する（１２１２）。その後に、該ビジネスシナリオモジュールは、イベント通知（又はオブジェクトデリバリ）において受取ったデータに関して操作を行ない（１２１４）且つ１つ又はそれ以上のアプリケーションコネクタへ送信するためのオブジェクト（図９のオブジェクト表示モジュール９００により）を発生する（１２１６）。このプロセスは、そのシナリオの終了に到達（ＦＳＭ実行が終了）（１２１８）か又は強制シャットダウン要求が受取られる（１２２０）まで、サブトランズアクション要求及びオブジェクトの発生を継続して行なう。
【００８０】
有限状態マシンが終了まで実行を行なうと、最終的なトランズアクション要求が発生され且つトランズアクションサービスへ送信されてその中に格納されているサガを削除する（１２２２）。その後に、シャットダウンフラグ（「優雅（ｇｒａｃｅｆｕｌ）」又は「強制（ｆｏｒｃｅｄ）」シャットダウンフラグのいずれか）がセットされるか否か（ステップ１２３０及び１２３３において）を判別するためのチェックが行なわれる（１２２３）。そうである場合には、該アプリケーション共同モジュールのシャットダウンが開始される（１２２４）。そうでない場合には、該プロセスはステップ１２０６において継続する。
【００８１】
強制シャットダウンフラグがステップ１２２０においてセットされる場合には、サガアンドゥ要求がトランズアクションサービスへ発行される（１２２６）。その後に、該アプリケーション共同モジュールはそのシャットダウンを開始する（１２２４）。一方、該アプリケーション共同モジュールは、強制シャットダウンを受取った後に全てのトランズアクションを完了すべく試みることが可能であり、その後に進行中のトランズアクションプロセスが完了した時にそれ自身のシャットダウン手順を喚起することが可能である。
【００８２】
ステップ１２０７において受取られるオブジェクトがイベント通知ではない場合には、その受取られたオブジェクトが強制シャットダウン要求であるか否かの判別を行なうためのチェックが行なわれる（１２２８）。そうである場合には、有限状態マシンがアプリケーション共同モジュール内において実行中であるか否かを判別するためのチェックが行なわれる（１２２９）。そうでない場合には、アプリケーション共同モジュールはそのシャットダウン手順を開始させる（１２２４）。有限状態マシンが実行中である場合には、「強制（ｆｏｒｃｅｄ）」シャットダウンフラグがセットされ（１２３０）且つ該プロセスはステップ１２０６において継続する。
【００８３】
その受取られたオブジェクトが強制シャットダウン要求ではない場合には（ステップ１２２８）、その受取れたオブジェクトが「優雅（ｇｒａｃｅｆｕｌ）」シャットダウン要求であるか否かを判別するためのチェックが行なわれる（１２３１）。そうである場合には、「優雅（ｇｒａｃｅｆｕｌ）」シャットダウンフラグがセットされ（１２３３）且つそのプロセスはステップ１２０６において継続する。そうでない場合には、該オブジェクトは、既存の有限状態マシンの実行に起因して該アプリケーション共同モジュールによって発生される要求に応答する。従って、有限状態マシンの実行を再開することが可能である（１２３２）。動作期間中に、エラー及び例外サービス２６０（図３）は、サービス及び交換サーバー部品の状態をモニタする。エラーが発生すると、該エラー及び例外サ−ビスは、アプリケーション共同モジュールへ送信するためのエラー信号を発生する。そのエラーが致命的なものである場合（例えば、メッセージングサービスが故障した場合）、アプリケーション共同モジュールは後方リカバリ（回復）を開始し、次いでシャットダウンを実行する。そのエラーが致命的なものでない場合には、該共同が終了されることを必要とするか否かの判別がなされる。その共同がそれ自身エラーの発生源である場合には、その共同はシャットダウンされることが要求され、従って後方リカバリ（回復）が開始され、それに続いてアプリケーション共同モジュールのシャットダウンが行なわれる。一方、前方リカバリ（回復）は、そのエラーがアプリケーション共同モジュール自身のものであることを暗示するものでない場合に試みることが可能である。
【００８４】
共同定義ツール
共同構築器は共同を構築するための手順プログラムを書込むことは必要とされない。共同定義ツールは、インストールされたコネクタ及び共同開発器に対して使用可能な一般的なクラス階層によってサポートされるビジネスオブジェクトを得るためにレポジトリィ（ｒｅｐｏｓｉｔｒｙ）即ち貯蔵所を読取る。この情報は視覚的な階層形態で共同開発器へ提供される。
【００８５】
共同開発器（ｃｏｌｌａｂｏｒａｔｉｏｎ ｄｅｖｅｌｏｐｅｒ）は、これらのアプリケーションクラスを使用し且つサポートされているオブジェクトモデリング方法の視覚的記号を使用してそれらをオブジェクトとしてモデル化させることが可能である。アプリケーション統合シナリオは、使用可能なアプリケーションオブジェクト間でのメッセージ交換を意味する線及び矢印を描くことにより且つサポートされている方法（アプリケーションオブジェクトに対応）のリストから、適宜の引数と共に受取ったメッセージに対する反応として喚起する方法をピックする即ち採用することによってモデル化することが可能である。ビジネス規則及び拘束条件は、統合した規則定義テーブルを使用することによって定義され且つ良好に画定されたアンカー点においてビジネスシナリオダイヤグラム内に組込まれる。必要とされる場合には、何等かのデータ変換が、アプリケーション統合シナリオ内にこのような変換をアンカーさせるためのフックと共にデータ変換ツールを使用して同様に定義される。従って、共同開発器は、視覚的ツールを使用してコラボレーション（ｃｏｌｌａｂｏｒａｔｉｏｎ）即ち共同全体を構築することが可能である。１例を図１０に示してある。これは単にサンプルの視覚化であって、実際のビジュアルはモデル用ツールによってサポートされているオブジェクトモデル化方法に依存する。
【００８６】
コラボレーション即ち共同が視覚的にモデル化され且つその全てのパーツが画定された後に、共同定義ツールがビジネスシナリオを有限状態マシンへ還元させ且つコンフィギュレーション情報及びジャバクラスファイルを発生する。参加するオブジェクト／クラス、それらの属性及び参加する方法、オブジェクト間の関係、有限状態マシン、例えば位置、実行及びトランズアクションセマンチック等の形態が特定されたプロパティ（特性）を包含する全ての共同コンフィギュレーションは、共同インストール期間中に、レポジトリ即ち貯蔵所内に格納される。該共同を描写し且つコラボレーション定義ツールによって発生されたサポート用のジャバクラスファイルは良好に定義された位置内に格納され且つこれに対する経路はレポジトリ即ち貯蔵所内に格納される。
【００８７】
アプリケーション共同モジュールは、一度インストールされると、必要に応じて他の交換ツールによってコンフィギュア即ち所定の形態とされ且つ管理することが可能である。新たなビジネスオブジェクトを必要とする共同の場合には、このようなオブジェクトを作成し、且つそのオブジェクトが共同器に対してローカルなものである場合には、ジャバコードを書くことによるか又はコネクタ開発ツールキットを使用する（新たなオブジェクトがコネクタから来る場合）によるかのいずれかによって構築するためにプログラム用のツールを使用することが可能である。
【００８８】
コネクタ
コネクタは、交換サーバーとビジネスアプリケーションとの間のインターフェースを行なう。各コネクタはアプリケーションエリア及びベンダー特定的である。該コネクタは、アプリケーションのＡＰＩを利用し、且つ該アプリケーション内のデータ及び演算を交換サーバーのオブジェクト及びイベントモデルへ及びそれから変換する。例えば、人的リソース（ＨＲ）アプリケーションはエンプロイ（ｅｍｐｌｏｙｅｅ）即ち従業員の概念を有することが可能であり、且つ従業員を付加し且つ彼らの月給を変更するためのメカニズムを有することが可能である。対応するアプリケーションコネクタは、交換サーバーのオブジェクトモデルにおける従業員の表示を与える。該アプリケーションにおける変更を検知し且つ追従し、且つ必要である場合には、イベントを発生することがコネクタの責任である。
【００８９】
コネクタはアプリケーションのＡＰＩを処理して、該アプリケーションから情報を抽出し且つ該アプリケーションへ情報を付託する。この文脈における情報はデータと機能（関数）の両方を意味している。
【００９０】
コネクタはアプリケーションオブジェクトとして交換サーバーにおけるアプリケーションからのデータ及び関数（機能）を表わす。アプリケーションオブジェクトモデルは、交換サーバーによって定義された基本オブジェクトモデルに追従する。
【００９１】
コネクタは、又、アプリケーションのデータと挙動及びその交換サーバーにおける表示との間のセマンチック（ｓｅｍａｎｔｉｃ）及びシンタクチック（ｓｙｎｔａｃｔｉｃ）のギャップを橋渡しする。このことは、適宜のデータ変換を実行し且つアプリケーションデータ及び挙動を画定されたオブジェクトモデルへ提供するのに必要な挙動セマンチックを具体化させることを包含している。
【００９２】
コネクタは、又、アプリケーション共同モジュールによって予定される正しい挙動的セマンチックを与えるのに必要なベンダー／アプリケーション特定ビジネス規則及び論理（拘束条件）を組込む。例えば、アプリケーション共同モジュールは、「北米」領域からのみのカスタマー（顧客）を予測するが、該アプリケーションは領域の間で区別を行なわない場合がある。このような場合に、コネクタは、「北米」領域内に入るカスタマーのみをピックアップするためのビジネス論理を包含している。
【００９３】
更に、コネクタは、それをコネクタ内に組込むことによって、アプリケーションによって提供されることのないアプリケーション共同モジュールによって必要とされるアプリケーション及び／又はベンダー特定機能性を提供する。ここでの１例は、ビリング（ｂｉｌｌｉｎｇ）即ち請求機能を提供することのない会計システムである。ビル・バイ・コール（ｂｉｌｌ−ｂｙ−ｃａｌｌ）アプリケーション共同モジュールの場合には、このような請求機能は金融アプリケーション用のコネクタ内に組込まれている。
【００９４】
最後に、コネクタは、アプリケーションにおいて変化が発生する場合にアプリケーション共同モジュール及び交換サーバーへイベント通知を供給する。
【００９５】
コネクタによって提供されるその他の機能は、エラー処理及び通信「ミドルウエア（ｍｉｄｄｌｅｗａｒｅ）」（処理内、処理外及びローカル及び広域ネットワークトポロジィを介して交換サーバーと通信するため）である。コネクタは、又、管理ツールが、該コネクタを何等かのその他の部品として管理し、コネクタをインストールし、セットアップし且つコンフィギュア（ｃｏｎｆｉｇｕｒｅ）即ち所定の形態とさせ、且つセキュリティを与える（コネクタと交換サーバーとの間の安全なトランズアクションのため）を可能とするための管理インターフェースをサポートしている。
【００９６】
次に図１３を参照すると、コネクタ３０はＡＰＩマニュピュレータ１３００、データ変換器１３０２、ビジネス規則及び拘束モジュール１３０４、ビジネスカプセル化モジュール１３０６、メッセージ変換器１３０８、通信モジュール１３１０、オブジェクト表示モジュール１３１２、コンフィギュレーションツールセット及び管理インターフェース１３１４、エラー処理器１３１６を包含している。
【００９７】
典型的に、アプリケーションコネクタは、データベース管理システム内に存在する場合のあるアプリケーションのデータと直接的に相互作用することはない。この代わりに、交換器がアプリケーション特定ＡＰＩマニュピュレータ１３００を使用してベンダーが供給したＡＰＩに対して操作する。このことは、全てのコネクタ動作がアプリケーション自身の処理論理に対して稼動することを可能とし、その際にアプリケーションベンダーの内部論理及びスキーマ変化に依存することを減少している。例えば、カスタマー（顧客）サポートアプリケーションにおいて、カスタマーテーブル内に新たなカスタマーを付加することは、カスタマー契約情報（請求率、サポートレベル、２４×７サポート情報、等）が契約テーブル内においてアップデートされることを必要とする。ＡＰＩ処理は、全てのコネクタにおいて最もベンダー（及びアプリケーション）特定的部分であり、コネクタの論理的スタックの底部にレイヤー化されている。
【００９８】
コネクタはアプリケーションのデータ及び機能（関数）から交換サーバーのオブジェクトモデルへ行く場合及びその逆の場合に双方向シンタクチック及びセマンチック変換を提供する。これらの機能は、データ変換器１３０２、ビジネス規則及び拘束モジュール１３０４及びビジネスカプセル化モジュール１３０６によって与えられる。
【００９９】
データ変換器１３０２は、アプリケーションデータ及び機能（関数）をコネクタに適したデータフォーマットへ変換する。データ変換器は、コネクタ開発ツールと共にバンドルされる変換用のデータフォーマットを視覚的に定義するための対話的ツール１３０２、及び実際の変換を実行し且つコネクタ実行可能コード内に埋め込まれているランタイム部品１３２２を包含している。対話的ツール１３２０は、入力及び出力フォーマット及び適宜の変換を記述する。これらの変換は、暗示的シンタクチック変換からセマンチック内容をベースとした変換までにわたるものである。該ツールは、数学的（＋，−，＊，？，．）ストリング（切り捨て、アペンド、等）論理的（＞，＜、≧，≦、等）及びブール（ＡＮＤ，ＯＲ，ＮＯＴ等）オペレータを供給し、それらは入力及び出力フィールドの内容に関して作業を行なう。それは、又は、必要に応じて、外国語機能を組込むためのフックを提供する。外国語機能の例は、例えば情報を有効化するためのフラットファイル等の異なるデータ源からの外部テーブルを読取ることの可能な機能である。典型的に、データがアプリケーションから読取られるや否や、又はデータがアプリケーションへ書込まれる直前に、実行され、又は、アプリケーション共同論理に依存して、与えられたコネクタに対する異なる時点において実行することが可能である。
【０１００】
ビジネス規則及び拘束モジュール１３０４は、ベンダー特定ビジネス規則及び規則エンジンを実施するのに必要な情報１３３２を有する１組の規則１３３０を定義するツールを包含している。規則エンジン１３３２は該規則を評価する。例えばビジネスアプリケーションは、全世界からのカスタマー（顧客）に対するビジネス記録を与えることが可能である。共同は特定の地理的領域に関連した記録を必要とするに過ぎない場合がある。ビジネスカプセル化モジュールは、このような記録をフィルタするためのスクリーンを与え、且つこのような記録をフィルタするビジネス規則（１組の規則１３３０内に格納されている）を有することによってアプリケーション共同モジュールに対してのオブジェクトとしてこれらの適宜の記録を提供する。
【０１０１】
ビジネスカプセル化モジュール１３０６は、該アプリケーションによって提供されるものではないが、アプリケーション共同モジュールによって必要とされるビジネス機能性を付加する。例えば、カスタマーサポートアプリケーションは１つの場合に対してログされている全てのサポートコールに対して蓄積した時間を追従するものではない場合には、ビジネスカプセル化モジュール１３０６を使用して、所望のビジネス機能性を提供するのに必要なデータベース内の各サポートコールに対する時間を合計することにより１つの場合に対してログ（ｌｏｇ）される時間を持続的に蓄積し且つ格納する。
【０１０２】
イベント通知は、アプリケーション共同モジュールにおいて処理を開始する。イベントは、又、種々の部品間での変化を通信するために使用される。イベントは、コネクタから発生され、アプリケーションがアプリケーションデータ内の修正を交換サーバーと通信することを可能とする。コネクタは、アプリケーション内において発生する変化を追従し且つそれらをイベントを介して交換サーバーへ通信する。
【０１０３】
コネクタは、部品内の故障の場合にこのようなイベントが失われることを防止するために、コネクタを信頼性のあるメッセージングシステム内にキュー即ち行列させることによって、アプリケーションからの持続的なイベント通知に依存する。コネクタの障害の場合には、該コネクタはコネクタが倒れた後に発生した全ての変化を該コネクタが決定し且つ交換サーバーへ通信する。メッセージ変換器１３０８及び通信モジュール１３１０は、コネクタ内の及びコネクタと交換サーバーとの間のメッセージの搬送のためにメッセージ指向型ミドルウエア（ＭＯＭ）を与える。同様のメカニズムは交換サーバーにおいて使用されている。メッセージングミドルウエアは信頼性のあるデリバリ（配達）で逐次的なキュー（行列）を与えることにより地理的に分布したアプリケーション間での共通運用性をサポートするための実行環境によって必要とされる非同期セマンチックスを提供する。これは、アプリケーションが低速の広域ネットワーク上でのアクノレッジメントを待つことがなく、継続して作業を行なうことが可能であることの確保を与えている。下側に存在する仮定は、リモートシステムにキューしたメッセージは絶対にデリバー即ち配達されるということである。ＭＯＭは、又、それらのメッセージを持続的な格納部に対してキュー即ち行列させることによりそのアプリケーションが使用可能でない場合のインスタンス（例）を取扱うためのセマンチックスを提供している。該アプリケーションが再度スタートアップ即ち開始すると、それは格納部から正しい順番でそのメッセージを検索し且つそれらを処理する。このＭＯＭ実現例は、更に、メッセージを消滅させ共同においてトランズアクションのアボート及び回復を必要とするエラーを発生させるためにメッセージに関するタイムアウトを提供する。
【０１０４】
オブジェクト表示モジュール１３１２は、アプリケーションのデータ及び挙動の周りにオブジェクトラッパー（ｏｂｊｅｃｔ ｗｒａｐｐｅｒ）を構築し且つ交換サーバーの基本オブジェクトモデルを使用してそれを提供する。該ラッパーは、このようなデータ及び機能（関数）がアプリケーション又はコネクタ自身内に存在するか否かに拘らず、アプリケーション共同モジュールによって必要とされるアプリケーションのデータ及び機能（関数）スキーマを正確に表わすためのフレームワーク即ち枠組を与える。ラッパーは、又、一般的なフレームワークを解釈し且つ交換サーバーの基本オブジェクトモデルにおいてそのフレームワークの内容を表わす。これは双方向メカニズムであって、それは、又、交換サーバーのオブジェクトモデルからコネクタにおける実行のためのフレームワークへの変換を与える。最後に、該ラッパーは、特定のラッパー又はフレームワークにおけるセマンチックな内容を与え、それは、例えばその属性及びその機能（関数）は何か又はそれらは何をするのか等の与えられたアプリケーションオブジェクトの意味を記述する。
【０１０５】
１実施例においては、任意の言語を使用してコネクタが構築され且つジャバラッパー（Ｊａｖａ ｗｒａｐｐｅｒ）、ＣＯＲＢＡ ＩＢＬ又はマイクロソフトのＯＬＥ／Ａｃｔｉｖｉｘ技術を使用して交換サーバーへ露呈される。交換サーバーは、上述した形態のいずれかにおける部品を喚起（結合）するためのフックを提供する。基本コネクタクラス／インターフェースが定義され、それは３つのタイプ（ジャバ、ＩＤＬ、ＯＬＥ／Ａｃｔｉｖｅｘ）に対する基本クラスを提供するために拡張される。
【０１０６】
アプリケーションオブジェクトは、アプリケーション共同モジュール作成時にそれらのクラス定義によって表わされる。アプリケーションオブジェクトが仮想オブジェクトとしてコネクタによって具体化されるのはランタイムにおいてのみである。アプリケーション共同オブジェクトは、参加するアプリケーションの実行のプラットフォームとは独立的である。最小で、それらは、交換サーバーが実行する同一のプラットフォーム上で実行する。
【０１０７】
エラーハンドラー１３１６は、他の部品における管理インターフェース、ログ用機構及びエラー取扱いサービスと同期する。コンフィギュレーションツール１３１４は種々の管理インターフェースをサポートする。これらのインターフェースは、プラットフォーム特定管理インターフェーススタンダードに執着し、従って既存管理ツールはコネクタプロセスを管理することが可能である。コンフィギュレーションツールも、アプリケーションコネクタのインストールを可能とさせる。
【０１０８】
アプリケーションコネクタは、「オブジェクトファクトリ（ｏｂｊｅｃｔ ｆａｃｔｏｒｙ）」のような動作をする部品である。これは、それが「オブジェクトの作成（ｃｒｅａｔｅ ｏｂｊｅｃｔ）」、「オブジェクト獲得（ｇｅｔ ｏｂｊｅｃｔ）」、「オブジェクトの破壊（ｄｅｓｔｒｏｙ ｏｂｊｅｃｔ）」のようなことを行なうことが可能なインターフェースをサポートするという意味である。これらのオブジェクトは、コネクタ、アプリケーション及び仮想オブジェクトを包含している。それらは、アプリケーション、共同又はサーバーによって提供されるオブジェクト、データ及びサービスを表わす。多くの場合において、これらのオブジェクトは「プロキシィ（ｐｒｏｘｙ）」即ち代理のオブジェクトである。それらは、リモートオブジェクトを表わしているが、実際には、どのようなオブジェクト状態を含むものでない。
【０１０９】
交換サーバーがコネクタオブジェクトへアクセスすることを必要とする場合には、それはそのオブジェクトに対する「ハンドル（ｈａｎｄｌｅ）」を獲得する。交換サーバーの観点からは、コネクタによって提供される任意のオブジェクトは、そのオブジェクトが正確にどこに存在するかということ（データ及び機能（関数））は交換サーバーは全く気にしないという点において、同様のものである。それは、コネクタオブジェクトに対する状態情報を追従するものでもない。オブジェクトに対する状態情報は、必要な場合には、コネクタによって維持される。共同がコネクタオブジェクトの何等かの状態を必要とする場合には、それはローカルオブジェクトを作成し、それはコネクタオブジェクトのスナップショットコピーであってローカル処理のためにそれを使用する。共同は、トランズアクション上の一貫性のために明示的に必要とされない限り、任意のオブジェクト状態情報を維持するためにコネクタに依存することはできない。１実施例においては、コネクタオブジェクトは共同プロセスの性能を拘束化されるためにキャッシュされる。
【０１１０】
各アプリケーションコネクタは、それがどのように処理するかを知っている１組の予め定義されたオブジェクト「タイプ」をサポートしている。例えば、ＨＲアプリケーションは従業員タイプをサポートしている。カスタマーサービスアプリケーションはカスタマーのタイプをサポートしている。全てのアプリケーションコネクタは、例えば、イベントサービスタイプ、イベントタイプ、トランズアクションサービスタイプ、トランズアクションタイプ、受取り方法、消費方法等の所要なサービスを与える目的のために最小組のファシリティ（機構）オブジェクトタイプをサポートすることが必要とされる。１実施例においては、該オブジェクト表現モジュールは、サービス観点からだけのイベントを見る代わりに、イベントに基づいた発表及び予約メカニズムを使用し、従ってイベントは、単に、発表され且つ予約される別の形態のビジネスオブジェクトであるに過ぎない。
【０１１１】
イベント予約に起因するか又は消費方法を喚起することに応答して１つのオブジェクトが受取られると、コネクタがアプリケーションと通信を行ない、要求されたオブジェクトを構築するのに必要なデータを検索し（例えば、データベースに対してクエリを発生する）、必要なデータ変換、規則及びビジネス論理を適用し、そのオブジェクトを構築し、且つ要求者のデリバリ（配達）受領又は消費方法を喚起することによって、そのオブジェクトに対するハンドルを要求者／予約者へリターンさせる。
【０１１２】
該コネクタは、直接的にアプリケーションＡＰＩをコールするか、又はアプリケーションＡＰＩをコールするゲートウエイプロセスと通信することによるかのいずれかによってアプリケーションと通信を行なう。このような通信は、イベントを基礎とした発表・予約メカニズムを使用してより効率的に達成することが可能である。
【０１１３】
交換サーバーにおけるイベントは外部的なもの又は内部的なものとすることが可能である。内部的なイベントは、例えば、アプリケーション共同モジュール、タイマー、同期プリミティブ（ｐｒｉｍｉｔｉｖｅ）、又はその他のサービス等の交換サーバー内のサービスによって発生されるものである。外部的イベントは、例えばコネクタ又はその他の交換サーバー等の外部の部品によって発生されるものである。
【０１１４】
次に、図１３及び１４を参照すると、コネクタ３０に対する処理の流れが示されている。初期化において、コネクタ３０はそれが各共同（１４００）において責任を有するイベントのリストを発表する。次いで、該コネクタは、メッセージ変換器１３０８を介して交換サーバー（１４０１）へイベント予約を与えることによって、それと関連するビジネスシナリオに従ってイベントに対する予約を行なう。その後に該コネクタはアプリケーションか又は交換サーバーのいずれかからの受信情報を待つ。アプリケーションからの情報は、イベントトリガ用情報又はアプリケーション共同モジュールからの情報に対する要求に応答して該アプリケーションからリターンされた情報の形態を取ることが可能である。交換サーバーの情報は、アプリケーション共同モジュールからのビジネスオブジェクト要求又はコネクタによる予約に基づいて共同からの要求されたビジネスオブジェクトのリターンの形態を取ることが可能である。アプリケーション情報がコネクタによって受取られると（１４０２）、データ変換器１３０２はその情報をビジネス規則及び拘束モジュール１３０４に対する適宜のフォーマットへ変換する（１４０６）。ビジネス規則及び拘束モジュール１３０４は、関連する規則のランタイム評価を実行し、アプリケーション共同モジュールによって予定されている特定のベンダー／アプリケーションセマンチックスを組込む（１４０８）。ビジネスカプセル化モジュールは、該アプリケーションによって提供されたものではないがアプリケーション共同モジュールによって要求されるビジネス機能性を付加する（１４０９）。
【０１１５】
その後に、イベント通知がメッセージ変換器１３０８によって発生され（１４１０）且つ適宜のオブジェクトがオブジェクト表現モジュール１３１２によって交換オブジェクトベースモデルに従って作成される（１４１２）。オブジェクト及びイベントはビジネスオブジェクトとして交換サーバーを介して通信モジュール１３１０によってアプリケーション共同モジュールへ転送される（１４１４）。
【０１１６】
交換サーバー情報又は要求が受取られると、このような要求（又は要求に対する応答）はメッセージ変換器１３０８によって処理され（１４１６）且つそのオブジェクトはオブジェクト表現モジュール１３１２によって該コネクタに対する適宜のフォーマットへ変換される（１４１８）。カプセル化モジュールは、コネクタレベルにおいて要求される任意の機能性を付加させる（１４２０）。その後に、ビジネス規則及び拘束モジュール１３０４は、関連する規則のランタイム評価を実行し、アプリケーションによって予測されている特定のベンダー／アプリケーションセマンチックスを組込む（１４２２）。データ変換器１３０２は、その情報をＡＰＩマニュピュレータ１３００用の適宜のフォーマットへ変換し（１４２４）、該マニュピュレータはその情報を該アプリケーションへ転送する（１４２６）。該アプリケーションへリターンされた情報は、該アプリケーションによって取扱うべきデータか又は該共同において使用されるべきデータに対する要求の形態とすることが可能である。
【０１１７】
この処理は、シャットダウン要求が受取られるまで継続する。シャットダウン要求は、補償用トランズアクションを包含することが可能であり、又は該コネクタのシャットダウンのみを要求するに過ぎない場合がある。受領すると、コネクタ３０は例外サービスから受取った補償用トランズアクションを実行し、又はアプリケーション共同モジュールはそれ自身のシャットダウン手順を開始させる。
管理ツール及びインターフェース
次に図５を参照すると、管理ツール５０（図３）はインストールツール１５０２、セットアップツール１５０４、コンフィギュレーションツール１５０６、管理インターフェース１５０８を包含している。
【０１１８】
インストールツール１５０２は、インストールし、所要のパラメータを回収し、且つ交換サーバー内の部品を取除くために使用される。該インストールツールはメタデータ（ｍｅｔａ−ｄａｔａ）駆動型であり、従って該ツールを案内する情報は該ツールによって内在的に知られているものではなく、該部品それ自身の中に格納される。
【０１１９】
セットアップツール１５０４は、その管理ドメイン内における任意の交換サーバー内に部品をインストールさせる。
【０１２０】
コンフィギュレーションツール１５０６もメタデータ駆動型ツールであって、インストールした交換サーバー、アプリケーション共同モジュール及びコネクタのコンフィギュレーション即ち形態を観察し且つ変更するためのツールである。コンフィギュレーションに加えて、それは、又、カスタマー（顧客）が実行用の部品をイネーブル又はディスエーブルさせることを可能とする。コンフィギュレーションメタデータは、交換オブジェクト内にプロパティ（特性）として格納される（交換オブジェクトはコンフィギュラブル即ち形態特定可能なプロパティ挙動を与える基本クラスから受け継いだコンフィギュラブル特性を有するオブジェクトである）。プロパティは、名前、データタイプ、デフォルト値、及び許容可能な値に対する規則を提供する。コンフィギュレーションツール１５０６は、参加するアプリケーションのバージョンを改定する場合（又は本来的に形態特定する場合）自動的バージョン管理を実行する。参加するアプリケーションの異なるバージョンへアップグレイドする場合には、該コンフィギュレーションツールは、その他の部品が必要とされるか否か又は別のアクションが実行されねばならないか否かを判別する。
【０１２１】
管理インターフェース１５０８もメタデータ駆動型である。該メタデータは例えばＳＭＳ又はＳＮＭＰ等のスタンダードインターフェースをポピュレート（ｐｏｐｕｌａｔｅ）させる。スタンダードシステム管理ツールはこれらのインターフェースへアクセスするために使用される。２つの種類の管理インターフェースが存在しており、即ち、リソース管理（どのサーバーがアップであるか、私にスレッドを示せ、私にメモリ利用を示せ、いつログがｘ％満杯であるかを告げろ等）、及びインテグレーション即ち統合（一体化）操作管理である。前者は、標準管理フレームアークフックのサポートを介して与えられる。
【０１２２】
開発ツール
次に、図１６を参照すると、開発ツール６０（図３）はカスタマー及びベンダーが彼ら自身のコネクタを構築することを可能とするコネクタ開発キット１６００を包含している。これは個人的に形成したアプリケーションをインターチェンジ（交換）と統合させることを希望するカスタマー（顧客）にとっては特に有用である。このコネクタ開発キットは、交換プロトコル及びＡＰＩ１６０２、コネクタフレームアーク１６０４（それはソースコードの形態での１組のクラスを提供する）、該コネクタを部品としてパッケージングするパッケージャ（ｐａｃｋａｇｅｒ）１６０６、及び規則及びデータ変換ツール１６０８を包含している。
ビル・バイ・コール共同
コラボレーション（ｃｏｌｌａｂｏｒａｔｉｏｎ）即ち共同の実際的な例は、「ビル・バイ・コール（ｂｉｌｌ−ｂｙ−ｃａｌｌ）」アプリケーション共同モジュールであって、その場合に、コールトラッキング（カスタマーサポート）アプリケーションは、コール即ち通話が完了すると、ビリング（ｂｉｌｌｉｎｇ）即ち伝票発行アプリケーションへ要求を送り、インボイス（伝票）を発生しそれをカスタマー（顧客）へ送る。コール（通話）トラッキングアプリケーションとビリングアプリケーションとの間のビジネス処理相互作用は双方向メッセージ交換を介して行なわれる。コールトラッキングアプリケーションの場合には、必要とされるデータは、カスタマーＩＤ、名前、アドレス及び請求率である。所望のビジネス機能性は、コールトラッキングアプリケーションからのＣａｌｃＣａｌｌＤｕｒａｔｉｏｎ（通話期間を計算するため）及びｔｅｌｌＮａｍｅＡｄｄｒｅｓｓｉｄ（発呼者の名前、アドレス及びカスタマーＩＤを得るため）から構成されている。
【０１２３】
ビリングアプリケーションに対して必要とされるデータはカスタマーＩＤ、伝票発行用のアドレス等である。所望とされるビジネス機能性は、ＶｅｒｉｆｙＣｕｓｔＤｅｔａｉｌｓ（これら有効なカスタマーであるか否かを判別するため）及びＧｅｎｉｎｖｏｉｃｅ（インボイス即ち伝票を発生し且つカスタマーへ送るため）である。このタイプのコラボレーション即ち共同と関連するメッセージの流れを図１０に示してある。
【０１２４】
１つのレベルにおいては簡単であるが、上のアプリケーション共同モジュールは、例えば、（ａ）２つのアプリケーションにおけるカスタマーＩＤが同じでない場合、又は（ｂ）請求率がコールトラッキングアプリケーション、ビリングアプリケーション、又はアプリケーション共同モジュール自身のいずれかによって供給することが可能である場合等のような多様な条件下においては、実際には、きわめて複雑なものとなる場合がある。
【０１２５】
コンフィギュレーションツールを使用して、ユーザは、より特定的なオプションを設定することが可能であり、例えば、どのようにして通話期間をラウンド（ｒｏｕｎｄ）即ち丸めるか、又はそれが通話あたり固定した料金であるか又は分当たりの料金であるかをどのようにして特定するか、通話は個別的に請求されるか又は合計されるか、発呼者がある額のサポートをただで得るか否かをどのようにして判別するか且つどれが請求率を与えるかをどのようにして識別するか（アプリケーションのうちの１つ、即ちアプリケーション共同モジュールか又はそれがどこか他から派生されるものか）等のオプションである。
【０１２６】
インストレーション及びコンフィギュレーションプロセスは、交換サーバーのオブジェクトに関するプロパティ即ち特性を設定し且つこれらのエントリをレポジトリ即ち貯蔵所へ付加させる。該貯蔵所は、又、２つのコネクタ及びアプリケーション共同モジュールの存在及び位置に関する情報を維持する。交換サーバーがブートすると、それは貯蔵所とコンタクトし且つどの部品がスタートアップするものであるかを見つけ出す。この場合には、該２つのコネクタと該１つの共同である。該ブートプロセスはこれらの部品をスタートアップさせ次いで抜け出る。１つの部品がスタートアップすると、それはそのプロパティを検討してそのスタートアップパラメータを決定する。コネクタの場合には、そのパラメータは、接続すべきアプリケーションのネットワーク位置、及びどのようにしてこれらのアプリケーションがカスタマイズされたかに関する情報を包含する。コラボレーション即ち共同の場合には、スタートアッププロパティは、どのコネクタを使用するか、アプリケーション共同オブジェクトをいつ例示化即ち具象化するか（スタートアップ又は要求により）等のようなことを包含している。注意すべきことであるが、コネクタの識別は、位置透明性を保存するためにレジストリ内の名前として特定される。同様に、アプリケーション共同オブジェクトは、その他の交換サーバーのそのオブジェクトへの直接的なアクセスをさせるために該レジスタ内に名前を有している。
【０１２７】
コールトラッキングアプリケーションコネクタは該交換に対してオブジェクト及びイベント指向型インターフェースを提供している。この例のために、オブジェクトがプロダクト（ｐｒｏｄｕｃｔ）、カスタマー（ｃｕｓｔｏｍｅｒ）、ケース（ｃａｓｅ）、コール（ｃａｌｌ）であると想像する。イベントはＮｅｗＣａｓｅ、ＣａｌｌＣｏｍｌｅｔｅｄ、ＣａｓｅＣｌｏｓｅｄである場合がある。コールトラッキングコネクタによってサポートされる方法のうちの１つの例は、ＲｅｔｕｒｎＣａｓｅＨｉｓｔｏｒｙの場合があり、それは全てのコール即ち通話で且つ任意の与えられた場合に対する各々の期間に関して情報をリターンする。
【０１２８】
同様に、ビリングコネクタは、ａｃｃｏｕｎｔｓＲｅｃｅｉｖａｂｌｅｓ方法及びｂｉｌｌＡｃｃｏｕｎｔ方法を露呈させるビリングオブジェクトを供給する。注意すべきことであるが、柔軟性を最大のものとするためにａｃｃｏｕｎｔｓＲｅｃｅｉｖａｂｌｅｓ方法を分離させた。この方法は売掛金システムにおいてインボイス情報をアップデートする。殆どの場合に、カスタマーはどの請求が自動的に売掛金に入れられるかを制御することを希望する。ａｃｃｏｕｎｔｓＲｅｃｅｉｖａｂｌｅを別の方法として設けることは、請求を売掛金へ自動的に挿入することをユーザが制御可能なものとする必要性を簡単化させる。請求が入れられる場合には、該方法が喚起される。そのような挿入がなされるべきでない場合には、該方法は使用されない。
【０１２９】
交換サーバーがブートアップすると、それは、最初に、全てのコネクタを例示化即ち具象化し、次いで全てのアプリケーション共同オブジェクトを例示化する。例示化において、ビリングアプリケーションのコネクタがコールトラッキングコネクタのＣａｓｅＣｌｏｓｅｄイベントに対して予約を行なう（該システムはそのケースが閉じられるまで請求を発生するものではないものと仮定する）。コールトラッキングコネクタは、サポートアナリストがそのケースのステータスをＣＬＯＳＥＤ即ち閉じた状態に設定することによってそのケースを閉じる場合にＣａｓｅＣｌｏｓｅｄイベントを発生する。ＣａｓｅＣｌｏｓｅｄイベントを受取ると、共同オブジェクトは、問題のケース番号に関してのＲｅｔｕｒｎＣａｓｅＨｉｓｔｏｒｙ方法を喚起することによって、そのケースに対しての全てのコール（通話）及びそれらの期間に対してコールトラッキングコネクタに質問を発する。リターンされたコール期間はアプリケーション共同オブジェクトのプロパティによって特定されているビジネス規則に従ってドルの額へ変換される。それは、又、コールトラッキングコネクタに、カスタマーＩＤをカスタマーの名前へ変換するための質問をせねばならない場合があり、又はコールトラッキングアプリケーションにおけるカスタマーＩＤをビリングアプリケーションにおけるカスタマーＩＤへマッピングせねばならない場合がある。
【０１３０】
次いで、共同オブジェクトはビリングコネクタにおけるビリングオブジェクトに対するｂｉｌｌＡｃｃｏｕｎｔ機能を喚起し、それに対して、カスタマーの名前、ドルの金額、コール及びケースを記述するテキストストリングをパスする。請求書をちゃんと発生することは、多分、複数回のデータ変換を必要とする。カスタマーの名前を金融システムのカスタマーＩＤへ変換することが必要な場合があり、且つドルの金額を表示することに関して対処すべき通貨の局地性の問題が存在する場合がある。これらの変換は売掛金アプリケーション内にビリング（請求）情報を実際に提出する前に対処される必要があるので、共同オブジェクトは、所定の組の動的に決定したビジネス規則に基づいて、条件付きのデータ変換を取扱うことが可能である必要性がある。
【０１３１】
全てのデータ変換ステップが処理されると、本コラボレーション（共同）は、ビリングコネクタにおけるａｃｃｏｕｎｔＲｅｃｉｖａｂｌｅｓ機能を喚起し、売掛金に対する「請求したばかり（ｊｕｓｔ ｂｉｌｌｅｄ）」の金額をアップデートすることが可能である。
【０１３２】
以上、本発明の具体的実施の態様について詳細に説明したが、本発明は、これら具体例にのみ限定されるべきものではなく、本発明の技術的範囲を逸脱することなしに種々の変形が可能であることは勿論である。
【図面の簡単な説明】
【図１】 本発明の１実施例に基づくモジュール型アプリケーションコラボレータ（共同器）の概略ブロック図。
【図２】 本発明の１実施例に基づく簡単化したコラボレーション（共同）に対する流れ線図。
【図３】 本発明の１実施例に基づく交換サーバー（ｉｎｔｅｒｃｈｅｎｇｅ ｓｅｒｖｅｒ）の概略ブロック図。
【図４】 本発明の１実施例に基づくイベント発表及び予約サービスに対する流れ線図。
【図５】 本発明の１実施例に基づくトランズアクション（取引）サービスに対する流れ線図。
【図６】 本発明の１実施例に基づく交換サーバーに対する流れ線図。
【図７】 本発明の１実施例に基づく交換サーバーによって実行されるサービス要求に対する流れ線図。
【図８】 本発明の１実施例に基づく交換サーバーに対するシャットダウン手順に対する流れ線図。
【図９】 本発明の１実施例に基づくアプリケーション共同モジュールの概略ブロック図。
【図１０】 本発明の１実施例に基づく簡単なアプリケーション共同に対する順番が付けられたメッセージの流れを示す概略図。
【図１１】 本発明の１実施例に基づくアプリケーション共同を作成するための流れ線図。
【図１２】 本発明の１実施例に基づくアプリケーション共同に対する流れ線図。
【図１３】 本発明の１実施例に基づくコネクタの概略ブロック図。
【図１４】 本発明の１実施例に基づくコネクタに対する流れ線図。
【図１５】 本発明の１実施例に基づく管理ツールの概略ブロック図。
【図１６】 本発明の１実施例に基づくコネクタ開発キットに対するブロック図。
【符号の説明】
１０ モジュール型アプリケーションコラボレータ（共同器）
２０ インターチェンジ（交換）サーバー
３０ コネクタ
４０ アプリケーション共同モジュール
５０ 管理ツール
６０ 開発ツール
７０ アプリケーション
【発明の属する技術分野】
本発明は、大略、コンピューティングシステム即ち計算機システムに関するものであって、更に詳細には、情報システムにおいて動作するアプリケーション間のコラボレーション（ｃｏｌｌａｂｏｒａｔｉｏｎ）即ち共同を与えるための方法及び装置に関するものである。
【０００２】
【従来の技術】
例えば、会計、給与、製造及び流通等の特定のビジネスドメイン機能性条件に対処するカスタム、スタンドアローン情報システムを実現するために会社は毎年何十億ドルも使っている。これらの別々のスタンドアローンシステムを構築することによって、ビジネスプロセス即ち事業処理の各個別的なセクションは他のものから分離されたものとなっている。
【０００３】
そのうち、コーポレイトインフォメーションテクノリジー（ＣＩＴ）即ち法人情報技術部門がこれらのカスタムシステムの内部での開発から離れ始め且つ外部でのエンタプライズ（企業）アプリケーションを購入することによりコストを最小とするようになった。エンタプライズアプリケーションはより一般的なものであり、予めパッケージされた製品で一般的なビジネス機能性を提供している。典型的に、エンタプライズアプリケーションは、アプリケーションシステム、ハードウエアプラットフォーム、オペレーティングシステム、第三世代及び第四世代言語、データベース、ネットワークプロトコル、管理ツールからなる異種の結合を包含している。これらのアプリケーションは、エンタプライズ即ち企業のレベルにおいて、それらを実現する会社に対して巨大な利益をもたらすものであるが、それは容易に統合即ち一体化可能なものではないので、それらは、単にプロセスアイランド「（ｐｒｏｃｅｓｓ ｉｓｌａｎｄｓ）」の増殖を悪化させるに過ぎない。
【０００４】
スタンドアローンエンタプライズアプリケーションは多くのビジネスプロセスを取扱うための強力なツールを提供している。然しながら、ある機能性は、しばしば、別個のアプリケーションにおいて重複しており、エンタプライズアプリケーションをバンドル即ち束ねる場合にコストを押し上げることとなる。エンタプライズアプリケーション間のカスタム機能性の統合即ち一体化は望ましいものではあるが、通常、コストが高過ぎ、且つ最初にエンタプライズアプリケーションを購入することが作るか買うかの決定の恩恵を打破る。ツール及びミドルウエアのベンダーはデータの統合に対する解決法を提供しているが、機能の統合（一体化）ではなく、且つこれらの解決法も実現するためには顧客がかなりコーディングを行なうことを必要とする。
【０００５】
【発明が解決しようとする課題】
本発明は、以上の点に鑑みなされたものであって、上述した如き従来技術の欠点を解消し、アプリケーション間の共通運用性を提供するモジュール型アプリケーション共同装置及び方法を提供することを目的とする。
【０００６】
【課題を解決するための手段】
一般的に、１つの側面において、本発明は、複数個のアプリケーションと通信を行なうための複数個のコレクタとインターチェンジ（交換）サーバーとを含むアプリケーション間においてインターオペラビリティ（ｉｎｔｅｒ−ｏｐｅｒａｂｉｌｉｔｙ）即ち共通運用性を与えるためのモジュール型アプリケーションコラボレータ（ｃｏｌｌａｂｏｒａｔｏｒ）即ち共同装置を提供している。交換サーバーは、アプリケーション共同モジュールとサービスモジュールとを包含している。サービスモジュールは、コネクタとアプリケーション共同モジュールとの間でメッセージを転送する。アプリケーション共同モジュールは２つ又はそれ以上のアプリケーション間での共通運用性を画定し且つトリガと該トリガに応答するトランズアクション（ｔｒａｎｓａｃｔｉｏｎ）とを包含している。該トリガは１つ又はそれ以上のコネクタからデータを受取ると活性化され、関連するアプリケーションへ転送するために１つ又はそれ以上のコネクタへデータを送給するトランズアクション即ち処理となる。
【０００７】
本発明の他の側面としては以下のような特徴を包含している。交換サーバーサービスモジュールはトランズアクションサービスとエラーサービスとを包含している。アプリケーション共同モジュールにおけるトランズアクションは、１つ又はそれ以上のアクションを包含しており、且つトランズアクションサービスは、各アクション（動作）及び関連するアクションをアンドゥ（ｕｎｄｏ）即ち取消すための補償用アクションを記録する。エラーサービスは交換サーバーにおけるエラーをモニタし、且つ、エラーを検知すると、トランズアクションの実行を停止し、且つ中断したトランズアクションをアンドゥ即ち取消すために所要の補償用アクションの実行をトリガする。
【０００８】
各コネクタは、アプリケーションインターフェースと、ビジネスモジュールと、交換サーバーインターフェースとを包含している。アプリケーションインターフェースは、コネクタとそれと関連するアプリケーションとの間でデータ及び方法を受取り且つ転送するためのＡＰＩマニュピュレータを包含している。ビジネスモジュールは、関連するアプリケーションとアプリケーション共同モジュールとの間で転送するためのデータを取扱うためのビジネス方法及びトランスフォームを包含している。交換サーバーインターフェースは、コネクタとアプリケーション共同モジュールとの間でデータ及び方法を転送するためのものである。
【０００９】
トランズアクションは有限状態マシンを包含している。コネクタとアプリケーション共同モジュールとの間のデータ転送は、交換サーバー内のサービスモジュールによって転送されるオブジェクトによるものである。サービスモジュールは、サブスクリプション（予約）サービスとパブリケーション（発表）サービスとを持ったイベントサービスを包含しているアプリケーション共同モジュールは、トリガに基づいて１つまたはそれ以上のコネクタに対して予約を行なう。該コネクタは、それと関連するアプリケーションからトリガデータを受取ると、イベントサービスに対してデータを発表し、該発表サービスが該データをアプリケーション共同モジュールへ送給することとなる。交換サーバーは、更に、交換サーバーコンポーネントに対してメッセージの送給を確保するために、ＲＡＳサービス及びメッセージサービスを包含している。
【００１０】
別の側面においては、本発明は、交換サーバーと第一及び第二アプリケーションコネクタとを包含する別個の機能を実現するアプリケーションを共同するためのモジュール型アプリケーション共同器を提供している。各コネクタは、交換サーバーと関連するアプリケーションとの間でデータを転送するためのものである。交換サーバーは、アプリケーション共同モジュールとサービスモジュールとを包含している。サービスモジュールは、第一及び第二コネクタとアプリケーション共同モジュールとの間でオブジェクトを転送するためのものである。アプリケーション共同モジュールは、第一及び第二アプリケーションの間での共通運用性を画定し且つトリガと該トリガに応答するトランズアクションとを包含している。該トリガは、第一及び第二コネクタのうちの第一のものからデータを受取ると活性化され、且つ該トランズアクションは、第一及び第二コネクタのうちの第二のものへデータを送給し、関連するアプリケーションへ転送する。
【００１１】
別の側面においては、本発明は、第一及び第二アプリケーション間で共通運用性機能を画定することを包含する異なるプロセス上で動作するアプリケーション間での共通運用性を与える方法を提供している。該共通運用性機能は、一般的なサブピース（ｓｕｂ−ｐｉｅｃｅｓ）即ち部分と、ベンダーに特定的な部分とに分割される。共通運用性機能の一般的な部分を格納し且つ実行するためのアプリケーション共同モジュールが形成される。第一及び第二アプリケーションと関連する共通運用性機能のベンダーに特定的な部分を格納し且つ実行するための２つのアプリケーション特定コネクタが形成される。最後に、アプリケーション共同モジュール及び２つのアプリケーション特定コネクタがリンクされて共通運用性機能を達成する。
【００１２】
本発明の利点の１つは、関連する機能性を統合即ち一体化させることによって、ビジネスが効率及び生産性を著しく改善することを可能とさせることである。その他の利点としては、プラットフォーム、オペレーティングシステム、ネットワークとは独立的に、いずれかのアプリケーションを他のいずれかのアプリケーションと統合即ち一体化させるために単一のパッケージしたプロダクト即ち製品を提供し、異なる機能エリアにおける複数個のエンタプライザアプリケーションが機能及びプログラム論理を共用する一体化した一式として動作することを可能とし、共同的ビジネスモデルの実現をサポートするレベルにおいてのプロセスアイランドを一体化させ、エンタプライズアプリケーションを容易にインストール及び除去することを可能とし、且つ参加するアプリケーションの複数個のバージョンにわたっての動作を行ない、それによりアプリケーションを一体化させるための柔軟で長期的な解決法を提供し且つアプリケーションのバージョンのアップグレイド及びカスタム一体化の高維持コストを取除くことである。
【００１３】
【発明の実施の形態】
図１を参照すると、モジュール型アプリケーション共同装置１０に対するアーキテクチュアは、１つ又はそれ以上のコネクタ３０及び１つ又はそれ以上のアプリケーション共同モジュール４０を具備する交換サーバー２０と、管理ツール５０と、開発ツール６０とを包含している。アプリケーション７０が各コネクタ３０へ結合している。
【００１４】
交換サーバー２０は分散型アプリケーションサーバーであって、それは全てのコンポーネントに対してオブジェクト指向型ランタイムプラットフォームを提供する。それは、更に、コンポーネントを管理し、形態を特定させ且つ制御するためのメカニズムを提供し、且つ典型的なサーバー環境において見いだされる信頼性、使用可能性、及びサービス性特徴、ＲＡＳ特徴、の全てを提供する。オブジェクトコンポーネントは、同一の管理ドメイン内のいずれかの交換サーバー内に常駐することが可能である。管理ドメインは、相互接続されているコネクタ、アプリケーション共同モジュール及び交換サーバーからなる一式である。マルチ協力交換サーバーは異なるプラットフォーム上で走ることが可能である。この場合におけるプラットフォームは、オペレーティングシステム、データベース（必要な場合）、及び／又はミドルウエアを包含する任意の基本ソフトウエア環境のことを意味している。コネクタ３０は、アプリケーションが交換サーバー２０と通信することを可能とする。コネクタ３０は、アプリケーション７０とインターフェースすることの詳細の全てを取扱い、且つ交換サーバーのオブジェクト及びデータモデルにおけるアプリケーションを表わすためにオブジェクト指向型インターフェースを提供する。コネクタ３０はアプリケーション７０と通信を行ない且つ交換サーバーのオブジェクト指向型モデルにおけるその他のアプリケーションとインターフェースするためのスキーマを与える。コネクタは２つの端部を有するものと考えることが可能である。「交換端部」はアプリケーションのデータ及び方法に対するオブジェクト指向型代理スキーマである。「アプリケーション端部」はアプリケーションのＡＰＩに対するドライバである。換言すると、コネクタの交換端部は、そのアプリケーション内に常駐するデータ及び方法（挙動）に対する交換サーバーへの「仮想」オブジェクトインターフェースを提供する。アプリケーション共同モジュールがコネクタを横断して再使用することを可能とするために、コネクタの交換端部によって提供される仮想オブジェクトインターフェースは、同一のアプリケーションクラスを有しているが異なるベンダーによって製造されているコネクタに対して同様である。コネクタ３０のアプリケーション端部は、アプリケーション７０から仮想オブジェクトへ情報を転送すること及び仮想オブジェクトに対してなされた変更（変更の要求）をアプリケーション７０へ戻すべく伝搬させることに関係している。コネクタ３０のアプリケーション端部は、更に、ベンダーＡＰＩを取扱うために必要とされるベンダーに特定的な論理を包含している。コネクタはアプリケーション及びベンダーに特定的なものである。
【００１５】
アプリケーション共同モジュール４０は、２つ又はそれ以上のアプリケーション７０を統合即ち一体化させるために必要な特定的な一体化ビジネス論理及び処理の流れを与える。アプリケーション共同モジュール４０は、一体化ビジネス論理の再使用可能な部分を含んでおり、一方、参加するビジネス論理のアプリケーション特定部分はコネクタ３０内に格納される。アプリケーション共同モジュール４０は、共同に参加する各アプリケーション７０に対して適宜のコネクタ及び交換サーバー２０を必要とする。アプリケーション共同モジュール４０はコネクタオブジェクト間で通信及び処理の流れを共同させる特別化したオブジェクトである。交換サーバー２０において実行するアプリケーション共同モジュール４０は任意のコネクタ３０の交換端部のみを見るに過ぎない。アプリケーション共同オブジェクトは交換サーバーのサービス（それらはオブジェクトである）、参加するアプリケーションのコネクタオブジェクト、及びその他のアプリケーション共同オブジェクトの間におけるメッセージの交換の形態でビジネスインタラクションを実現させる。
【００１６】
管理ツール５０は、エンドユーザの顧客が交換サーバー２０及びコネクタ３０をインストールし、形態を特定し、制御し、且つモニタすることを可能とする１組のツール及びインターフェースを提供する。
【００１７】
開発ツール６０は、顧客が自分自身のアプリケーション共同モジュール及びコネクタを開発することを可能とする１組のツール及びライブラリを提供する。ツールは交換サーバーのオブジェクト内のメタデータから駆動される。メタデータは、データを特性づける情報を記述するために使用される用語であり、時々、データ定義として呼称される。
【００１８】
アプリケーション７０は、会計、請求、顧客サービス、給与及びその他のビジネスプロセスをサポートする種々のビジネスアプリケーションを包含している。アプリケーションクライエントは、アプリケーションのユーザインターフェースを使用して関連するアプリケーション７０と対話即ち相互作用を行なう。一方、アプリケーション７０は非ビジネスアプリケーションとすることが可能である。アプリケーション７０の間の共通運用性はアプリケーション共同モジュール４０内において定義されている。
【００１９】
第一アプリケーション共同モジュール内に設けられた簡単化したビジネス共通運用性機能は、第一アプリケーションからデータを受取り且つその一部を新しいフォーマットで第二アプリケーションへ書込むことを必要とする場合がある。簡単化したビジネス共通運用性機能に対する流れ図を図２に示してある。図１及び２を参照すると、初期化されると、第一アプリケーション共同モジュール４０、及びそれと関連する（第一及び第二）コネクタ３０が交換サーバー２０内へインストールされる（１００）。第一アプリケーション共同モジュール４０がビジネス共通運用性機能を提供し、それは、少なくともトリガ（例えば、１つ又はそれ以上のアプリケーションからの情報の受取り）及びそのトリガに応答するトランズアクション（例えば、１つ又はそれ以上のアプリケーションへの新たなデータの書込み）を包含している。第一アプリケーション共同モジュール４０は、特定のビジネス共通運用性機能に対するトリガに基づいてイベントに対して予約を行なう（１０２）。この例においては、そのイベントは、第一アプリケーションと関連する第一コネクタにおいての情報の受領によってトリガされる（１０３）。第一アプリケーションから受取った情報に基づいて、関連するコネクタのアプリケーション端部が第一コネクタの交換端部へデータをパスさせる（１０４）。第一コネクタの交換端部が、その情報を、交換フォーマットオブジェクトへ変換し且つそのイベントを発表する（その情報の受領即ちトリガ）（１０５）。そのイベントは第一コネクタによって発生されたオブジェクトの形態で、そのイベントに対して予約されている第一アプリケーション共同モジュールへ（又は、そのイベントに対して予約をしたか又はそのデータを要求した任意のアプリケーション共同モジュールへ）送給される（１０６）。
【００２０】
その後に、第一アプリケーション共同モジュールはそれと関連するビジネス共通運用性機能を実行し且つ第二コネクタに対して送信するためのオブジェクトを発生する（１０８）。そのオブジェクト自身は第二コネクタへ送給され（１０９）、それは該オブジェクト（データ及び方法）を適宜のフォーマットへ変換し（関連するコネクタの交換端部によって）且つそのコネクタの関連するアプリケーションにおいて（コネクタのアプリケーション端部によって）所望の機能を開始させる（１１０）。この共同プロセスに関連する詳細は、個々のコンポーネントに対する詳細な説明に関連して以下に更に詳細に説明する。
【００２１】
交換サーバー
次に、図３を参照すると、単一の管理ドメイン内の交換サーバーは、種々のシステム部品がプラグ即ち接続されているバスとして見ることが可能である。交換サーバー２０は、アプリケーション共同モジュールインターフェース２００、コネクタインターフェース２０２、外部インターフェース２０３、コンフィギュレーション（形態特定）ツール２０５へ接続されているコンフィギュレーションツールインターフェース２０４、セットアップツール２０７へ接続しているセットアップツールインターフェース２０６、システム管理インターフェース２０９及び複数個のサービスモジュール２０８を包含している。
【００２２】
コンフィギュレーションツール２０５は、アプリケーション共同モジュール及びコネクタ特性をユーザがイネーブル即ち動作可能状態とさせ及び／又は変更することを可能とさせる。セットアップツール２０７は、交換サーバーにおいてアプリケーションコネクタをインストールし取除き且つコンフィギュア即ち形態を特定させる。システム管理インターフェース２０９は、業界標準（ＳＭＳ／ＳＮＭＰ）管理インターフェースをサポートし且つ交換サーバーの部品に対し管理インターフェースを与える。外部インターフェース２０３はツール及びその他の外部エージェントが交換サーバー２０内のオブジェクトへアクセスし且つ制御することを可能とする。
【００２３】
交換サーバー２０はアプリケーションコネクタ３０（図１）及びアプリケーション共同モジュール４０（図１）の実行の必要性をサポートするための部品指向型オブジェクト実行環境である。それは、大きなグレインの容器オブジェクトとして機能するオブジェクト及び部品からなる基本オブジェクトモデルを定義する。アプリケーションコネクタ及び共同は、この基本モデルで実行され且つ該交換環境内の大きなグレインの容器である。このことは、コネクタ及びアプリケーション共同モジュールが基本モデルから派生される強力なインターフェースを有することを可能とすると共に、同時的に、交換サーバーの個々の部品内にそれらの実行の詳細を内部に閉じ込める。
【００２４】
部品は、その他のオブジェクトを収容し且つランタイムでＤＬＬ（ダイナミックリンキングアンドローディング）を介してロードすることの可能な大きなグレインのオブジェクトである。オブジェクト及び部品はそれらの実行から厳格に分離されているそれらのインターフェースで定義される。部品は名前サービス２３０を介して命名され且つレジストリ２３２内に見いだされる。
【００２５】
コネクタはアプリケーションに対する代理として作用する部品である。コネクタは典型的にアプリケーション内のエントリに対する代理であるコネクタオブジェクト（仮想オブジェクトと呼ばれる）を管理する。アプリケーション共同モジュールは、交換サーバー内に存在しており且つ動的に登録したり又は登録を解除したりすることの可能なオブジェクトである。アプリケーション共同モジュールは必要に応じてオブジェクトを作成するか又は管理する。アプリケーション共同モジュールは、交換サーバーと同一の基本オブジェクトモデルを使用する交換サーバー２０内の副部品として見ることが可能である。交換サーバー内の全ては基本オブジェクトモデルで表現される。基本オブジェクトモデルはそれらを記述するためのオブジェクト及びメカニズムを定義する。基本オブジェクトモデルは、オブジェクト配向、分布、位置独立性、及びサポートされているプラットフォーム上でのオブジェクトを実行する能力を提供する。
【００２６】
オブジェクトはイベント及びメッセージを介して相互作用を行なう。イベント予約（ｓｕｂｓｃｒｉｐｔｉｏｎ）サービス２３５、イベント発表（ｐｕｂｌｉｃａｔｉｏｎ）サービス２３６及びメッセージサービス２４２は、アプリケーション共同オブジェクトがコネクタオブジェクトと相互作用を行なう場合の基本的なメカニズムである。交換サーバー２０はオブジェクトに「サービス」を与える。
【００２７】
交換サーバー２０におけるサービスモジュール２０８によって与えられるサービスは、それらの一体化タスクを実行するためのコネクタ及びアプリケーション共同モジュールによって必要とされるものである。本発明の１実施例においては、サービスはバス上のモジュールとして描写され且つ名前サービス２３０、レジストリサービス２３２、予約サービス２３５と発表サービス２３６とを包含するイベントサービス２３４、貯蔵所２３８、ダイナミックローディングサービス２４０、メッセージサービス２４２、規則エンジンサービス２４４、データ転送サービス２４６、トランズアクションサービス２４８、エラー及び例外サービス２６０を包含している。交換サーバーサービスは、動的にコネクタ及び共同を付加及び除去すること、新しいコンフィギュレーション即ち形態をテストすること、リソースを効率的に管理すること、滑らかなアップグレードを可能とすること、及びハードウエア及びソフトウエアの障害から優雅に立ち直ることの能力を包含している。交換サーバーサービスはこれらの基本オブジェクトモデルから構築されており且つ交換サーバーの部品が必要とする一般的に有用な特徴を全て包含している。
【００２８】
交換サーバー２０は、交換サーバーのスタートアップ処理を調整し且つオブジェクトが名前によってその他のオブジェクトを見つけだすことを可能とするためのレジストリサービス２３２を包含している。これは、新たなオブジェクトが使用可能になる場合のその動的な登録を包含している。動的な登録は、新たなアプリケーション共同モジュールがそれ自身を登録することを可能とする。動的登録は、又、他のクライエントが新たな共同がオンラインとなる場合にそれを見つけ出すことを可能とする。レジストリサービス２３２は、交換サーバー内のその他のツールによってアクセスすることの可能な貯蔵所２３８内の任意の部品と関連するメタデータ（ｍｅｔａ−ｄａｔａ）を格納する。
【００２９】
動的ローディングサービス２４０は、部品のランタイム部分をロードし且つ交換サーバー２０を再コンパイル又は再リンクする必要性なしにそれらを実行する。
【００３０】
イベントサービス２３４は発表（ｐｕｂｌｉｓｈ）及び予約（ｓｕｂｓｃｒｉｂｅ）通知メカニズムを提供する。イベントサービス２３４は情報プロバイダーを情報消費者から離脱させる。ここでの概念は、アプリケーション共同オブジェクトはどのコネクタがどのオブジェクトを発表するかについての親密な詳細を知ることなしに、あるコネクタによって発表されるあるビジネスオブジェクト／イベントに対して予約することを希望することが可能であるということである。イベント配達及び予約サービスは、予約受領（イベントに対し）、予約の格納、イベントの受領、イベント通知及びそのイベントに対して予約した各オブジェクト（アプリケーション共同モジュール、コネクタ、又は交換サーバー）に対するイベントに関連するオブジェクト転送（結果）を包含している。該イベントサービスは、予約リストを含む予約サービス２３５及び発表サービス２３６を包含している。
【００３１】
図３及び４を参照すると、イベントに対する発表及び予約のプロセスにおいて、予約はオブジェクト（コネクタ、共同又は交換サーバー）から受取られる（４００）。予約サービス２３５は予約リスト内に予約を格納する（４０２）。イベント通知を受取ると（４０４）、発表サービスが予約リストをチェックして、受取ったイベントにおいて興味があることを登録しているオブジェクトが存在するか否かを判別する（４０６）。オブジェクトがそのイベントに対して予約している場合には、発表サービスがそのイベント通知に関連するオブジェクトを特定のイベントの通知を要求する予約リスト内の各オブジェクトに対して配達する（４０８）。
【００３２】
再度図３を参照すると、メッセージサービス２４２は、地理的に分布した部品に対する非同期的な実行セマンティクス（ｓｅｍａｎｔｉｃｓ）を与える。メッセージサービス２４２は、交換サーバー２０が非同期的なトランズアクションモデルをサポートすることを可能とするための信頼性のあるキューイング（行列）及びメッセージファシリティ（機構）を包含している。更に、信頼性のある配達メカニズムが、参加する部品が使用可能でない場合には、メッセージ要求が参加する部品に対して永続的にキューイングすることを可能とする。該部品が再度スタートアップすると、それは下側に存在する永続的なキューから未処理のメッセージを取ることにより、それを処理する。１実施例においては、発表及び予約サービスがメッセージサービスの上に構築されており、参加する部品の全ての処理、システム及び地理的な境界を超越するイベントサービスを提供する。
【００３３】
規則エンジンサービス２４４は２つの側面を有しており、即ち定義側面及び実行側面を有している。該定義側面は、規則の定義と結びついており且つ実行側面は実行期間中におけるこのような規則の評価から構成されている。アプリケーション共同モジュールは、アプリケーション共同モジュール内において実施されるされるビジネス規則を定義し且つ評価するためにこのサービスを使用する。コネクタも、該コネクタ内においてビジネス条件を評価し又は新たなビジネス論理を定義する場合にはこのサービスを使用する。最後に、イベントサービス２３４は、メッセージのルート付け及び発表のためにメッセージのセマンチック即ち意味論的な内容を評価するために規則エンジンサービス２４４を使用することが可能である。
【００３４】
データ転送サービス２４６はデータのシンタクチック（ｓｙｎｔａｃｔｉｃ）及びセマンチック（ｓｅｍａｎｔｉｃ）変換の両方を実施するために設けられている。このような変換の例は、簡単な整数からキャラクへの変換から共同期間中におけるセマンチックな内容及び意味の変換までの範囲にわたる。例えば、このようなセマンチック変換を与える条件は、第１アプリケーションにおける「従業員（ｅｍｐｌｏｙｅｅ）」がそれと関連する２つのフィールド（従業員ＩＤ番号（８ビット）及び名前）を有しており、一方第２アプリケーションにおける「従業員（ｅｍｐｌｏｙｅｅ）」がそれと関連する３つのフィールド（従業員ＩＤ番号（１０ビット）、名前、社会保障番号）を有している場合に発生する。従業員データを第１アプリケーションから第２アプリケーションへ転送する場合に、２つのシステムを同期させるために２つの変換が使用される場合がある。１つの変換は、従業員番号（８桁乃至１０桁）をマッピングすることが必要とされ、且つ第２変換は第１アプリケーションのデータベースから従業員の社会保障番号を抽出し且つその情報を第２アプリケーションのシステムへ付加することが必要とされる。典型的に、これらの変換に対するターゲットは、アプリケーション共同モジュール及びコネクタにおいて実行される変換によって定義される。コネクタも、必要な場合には、それらの実行内容内において変換を定義することが可能である。
【００３５】
トランズアクションサービス２４８は交換サーバーを介してリンクされているアプリケーションにわたっての一貫性を与える。交換サーバー２０は別個の非同期的なトランズアクションをサポートするトランズアクションモデルに補償用トランズアクションを供給する。補償用トランズアクションは、前のトランズアクソンの効果をセマンチック的に即ち意味論的にアンドゥ即ち取消すことを可能とするトランズアクション（処理）である。トランズアクションサービス２４８は１つ又はそれ以上のキュー（行列）２４９（不図示）を包含しており、且つ非同期的なトランズアクションを実行するためのメッセージプロセサ２５０（不図示）を包含している。トランズアクションサービス２４８はアプリケーションにわたって２つの態様で一貫性を与える。格納及び転送キューは、オンラインではないアプリケーションに対して取り決められているトランズアクションを管理する。第２に、トランズアクション記録キューはトランズアクション動作を記録するために使用される。トランズアクション記録キューはインタラプトされたトランズアクションと関連する第１動作の実行前にシステムの状態を再度確立するために、インタラプトされたトランズアクションから回復するために使用される。
【００３６】
１実施例においては、一貫性を維持し且つトランズアクション実行中において受取った障害又はその他のシャットダウンから回復するためにサガ（ｓａｇａ）を使用する。「サガ（ｓａｇａ）」は、１組のステップ（即ちサブトランズアクション）及び補償用サブトランズアクション（ｓｕｂ−ｔｒａｎｓａｃｔｉｏｎ）からなる接続されている別個のトランズアクションの二重にリンクされたリストである。一貫性を補償するために、本発明は、サガ内の全てのサブトランズアクションが完了されるか、又はいずれかの部分的な実行が補償用サブトランズアクションでアンドゥ即ち取消されるかのいずれかを確保する。サガ内の各サブトランズアクションは同一の一貫性のある状態を取るものではない。従って、サブトランズアクションが完了すると、他のサブトランズアクションを待つことなしに同一のサガをコミットすることが可能であり、従って、その結果を同時的なトランズアクションの残部へ解放することが可能である。インタラプト即ち中断の場合には、アプリケーション共同モジュールは、インタラプトしたトランズアクションの前方又は後方の両方の回復を試みることが可能である。補償用トランズアクションは、エラー及び例外サービス２６０に関連して詳細に説明する。
【００３７】
次に、図３及び５を参照すると、交換サーバーにおいて一貫性を維持する方法において、トランズアクションサービスは例えばイベント通知に応答するアプリケーション共同モジュールのようなオブジェクトによってトランズアクションが開始されるべきである通知を受取る（５００）。アプリケーション共同モジュールがイベントの通知を受取ると、それはサガ開始トランズアクション要求を開始させる（又は、交換サーバー内のいずれかのオブジェクトがトランズアクションを開始する場合）。トランズアクションサービス２４８は、アプリケーション共同モジュールによって開始されたトランズアクションと関連するアクション即ち動作を格納するために記録用キュー（行列）を割当てることによって、該サガ開始要求に応答する（５０２）。トランズアクションサービス２４８は、該記録用キューと関連するサガ識別子をトランズアクション要求を開始させるオブジェクトへリターンさせる（５０４）。
【００３８】
その後に、アプリケーション共同モジュールはそのビジネス共通運用性機能に従ってステップ／アクション（動作）を実行する。各アクション（トランズアクションステップとも呼ばれる）が開始されると、アプリケーション共同モジュールは適宜のサガキュー内にそのステップを付加する要求を発生する。トランズアクションサービスは、ループ内に入り且つ要求するオブジェクトからの次の要求を待つ（５０６）。受取ることの可能な要求のタイプは、付加（５０８）、削除（５１０）、修正（５１２）、獲得（５１４）、取消し（５１６）、終了トランズアクション（５２６）である。
【００３９】
次の要求が「付加（ａｄｄ）」要求である場合には、「付加」要求と関連するアクションが、補償用トランズアクション情報と共に記録用キュー内に格納される（５１８）。次の要求が「削除（ｄｅｌｅｔｅ）」要求である場合には、該キューからの要求されたエントリ（アクション（ａｃｔｉｏｎ））が削除される（５２０）。次の要求が「修正（ｍｏｄｉｆｙ）」要求である場合には、該キュー内のエントリがその要求に従って修正される（５２２）。次の要求が「獲得（ｇｅｔ）」要求である場合には、該キュー（サガ）の指定された部分が要求するオブジェクトへリターンされる（５２３）。最後に、次の要求が取消し要求である場合には、該キュー内に格納されるアクションと関連する補償用トランズアクションシーケンスがサガから検索され且つ開始される（５２４）。トランズアクションの完了時に（終了トランズアクション要求を受取ると）、該サガは除去される（５２６−５３０）。
【００４０】
１実施例においては、トランズアクションがインタラプトされる場合には、該トランズアクションサービス内の補償用エンジンが補償用アクションを実行して部分的に完了したトランズアクションと関連する記録用キュー内に格納されている該サガを取消す。トランズアクションをアボート即ち打ち切ることは、サガキュー内の各アクション（サブトランズアクション）に対する対応する補償用トランズアクションを実行することによって達成される。該補償用トランズアクションは、論理的即ちセマンチックな「ロールバック（ｒｏｌｌｂａｃｋ）」を与える（何故ならば、そのトランズアクションは既にコミットしているからである）。例えば、「従業員を付加（ａｄｄ ｅｍｐｌｏｙｅｅ）」に対する補償用トランズアクションは「従業者を除去（ｒｅｍｏｖｅ ｅｍｐｌｙｅｅ）」である場合がある。しかしながら、この補償用トランズアクションはそんなに簡単なものではない場合がある。例えば、人的リソースのユーザは、新たな従業者（ｅｍｐｌｏｙｅｅ）がシステムから単純に消え去った場合には不可解に思う場合がある。何故ならば、別の位置における別の部門内に位置されている可能性のある何等かのプロジェクトトラッキングシステムがそれを拒否するからである。従って、その他のより複雑な補償用トランズアクションが定義される。
【００４１】
１実施例においては２ＰＣ（２フェーズコミット（Ｐｈａｓｅ Ｃｏｍｍｉｔ））調節器が、アプリケーション共同に参加する複数個のキューに対するメッセージのキューイング即ち行列化を調整するために使用される。単一の共同（ｃｏｌｌａｂｒａｔｉｏｎ）が５つのアプリケーションに対してメッセージを送給するために下側に存在するメッセージサービスを与える場合には、２フェーズコミット調節器は、５つのメッセージの全てが送信されるか又は該メッセージのいずれもが送信されないかのいずれかを保証する。
【００４２】
コネクタにおいて非同期的なトランズアクションセマンチックを与えることは、トランズアクションのオブジェクト、そのトランズアクション方法を識別し、且つこれらの方法を補償するために必要な機能（補償用トランズアクション）を与えることを包含している。補償用トランズアクション機能の内容は、共同に特定的であって、その処理論理が各方法に対して異なるものであることが可能であることを暗示している。殆どの場合においては、補償用トランズアクションを手でコーディングすることが必要となる。１実施例においては、交換サーバーは、任意のコネクタにおいて補償用トランズアクション機能の実行を動的にイネーブル及びディスエーブルさせることが可能である。
【００４３】
エラー及び例外サービス２６０はエラーを取扱うための通知及びフック（ｈｏｏｋ）を与える。エラー及び例外サービス２６０は、そのエラーが発生した部品、そのような部品の位置、エラー番号及びストリングの形態でのそのエラーの性質を識別する任意のエラーの通知を与える。トランズアクションがインタラプトされる場合には、そのエラーサービスはそのトランズアクションサービスに対してアンドゥ（取消し）要求を発生し、サガ内に格納されている「アンドゥ（ｕｎｄｏ）」アクションを開始させる。一方、エラー及び例外サービスは、適宜のアプリケーション共同モジュールへそのエラーを通知することが可能である。該アプリケーション共同モジュールは、従って、インタラプトしたトランズアクションの前方又は後方の両方の回復を試みようとすることが可能である。後方回復においては、該アプリケーション共同モジュールは、該トランズアクションサービスに対してアンドゥ（取消し）要求を発生し、インタラプトされたトランズアクションにおいて完了した全てのトランズアクションステップをアンドゥ即ち取消す。一方、前方回復は、特定のエラーを評価し且つそれが臨界的なものであるか否かを決定することによってインタラプトしたトランズアクションを継続しようとする。そうでない場合には、代替手段が使用される。
【００４４】
例外サービスは、そのサービスのユーザが処理中における例外の場合には容易に登録を取消すことの可能なリソースへ登録することを可能とする。
【００４５】
その他のサービスは交換サーバー２０によって与えることが可能であり、それは、コネクタ及びアプリケーション共同モジュールがある演算を実行するために予め定めたスケジュールを有するようにさせるタイマーサービス、交換サーバーにおける多くの演算を並列的に実行することを可能とさせるスレッド及び同期サービス、ライセンシングサービス、アプリケーション外部のオブジェクト又はオブジェクト状態を持続的に格納することを可能とする持続サービス、部品インターフェースの変更されたバージョンを検知するためのインターフェースバージョンサービス、例えばアップグレイドされるか又はダウングレイドされるコネクタのような変更された部品を検知する部品バージョンサービス、アップグレイディング、バグの報告及び診断、性能モニタリング及びチューニングを包含するその他のＲＡＳ特徴サービスを包含している。
【００４６】
１実施例においては、交換サーバー２０（及びアプリケーション共同モジュール）は、ジャバ（Ｊａｖａ）で構成されている。何故ならば、それは実行のクロスプラットフォーム能力を有しているからである。１実施例においては、交換サーバーのバックボーンはアメリカ合衆国カリフォルニア州フォスターシティのビスジェニック（Ｖｉｓｉｇｉｎｉｃ）社によって作成されジャバで書かれたＣＯＲＢＡオブジェクトリクエストブローカー（ＯＲＢ）である。このＯＲＢはジャバランタイム環境で動作する。必要なＣＯＲＢＡサービスはジャバから利用される（クライエントに対するジャバスタブ（ｓｔｕｂ）及びサーバーに対するジャバスケルトン（ｓｋｅｌｅｔｏｎ）からなるジャバ世代に対してＩＤＬを使用）。交換サーバーの中でこの構成における通信トランスポートはＩＩＯＰ（Ｉｎｔｅｒｎｅｔ ｉｎｔｅｒ ｏｒｂ ｐｏｒｔｏｃｏｌ）又はメッセージング（ｍｅｓｓａｇｉｎｇ）即ちメッセージサービスである。該コネクタの２つの半分の間又は交換サーバーとコネクタとの間の通信構成はＩＩＯＰ又はメッセージングとすることが可能である。
【００４７】
交換サーバー２０に対する処理の流れを図６に示してある。次に、図３及び６を参照すると、スタートアップ即ち開始時において、交換サーバーが初期化される（６００）。この初期化は、アプリケーション共同モジュール及びコネクタ情報及び交換サービス情報を包含するレジストリサービス２３２と関連する貯蔵所からコンフィギュレーション（形態）情報を検索することを包含している。その後に、該コンフィギュレーションにおいてエラーを発生しなか否かを判別するためのチェックが行なわれる（６０２）。カウンタ又はアプリケーション共同モジュール仕様内にコンフィギュレーションエラーがある場合、又は何等のサービスが無効であり且つサポートされていないオプションが特定される場合に発生する場合がある。例えばメッセージングサービスが使用可能でないというような臨界的なエラーが発生すると（６０４）、その初期化は停止する（６０６）。
【００４８】
エラーが検知されないか又はエラーが臨界的なものではない場合（例えば、コネクタが何等かの特性を特定するものではないがデフォルトを有している）、交換サーバー内のサービスの全てが使用可能であるか否かを判別するためのチェックが行なわれる（６０８）。いずれかの臨界的なサービスが使用可能でない場合には（６１０）、初期化は終了する。そうでなければ、交換サーバーは各インストールされ且つコンフィギュア即ち所定の形態とされたコネクタ（６１２）及びアプリケーション共同モジュール（６１４）を例示する。その後に、交換サーバーは定常状態ループに入り、サービス要求を待つ。サービス要求を受取ると（６１６）、交換サーバーは、その要求がシャットダウンリクエストであるか否かを判別するためのチェックを行なう（６１８）。
【００４９】
そうである場合には、交換サーバーはシャットダウン手順を実行する（６２０）。そうでない場合には、交換サーバーはその要求をサービスし（６２２）、次いでサービスに対する次の要求を受取るまでアイドル状態となる。
【００５０】
要求のサービスを図７により詳細に示してある。要求のタイプが決定される（７００）。その要求が交換サービス要求である場合には、分岐Ａが喚起される。その要求がトランズアクション要求である場合には、分岐Ｂが喚起される。その要求が管理要求である場合には、分岐Ｃが喚起される。最後に、その要求がコンフィギュレーション要求である場合には、分岐Ｄが喚起される。
【００５１】
分岐Ａにおいて、交換サービス要求は、交換サーバー（７０２）における適宜の交換サーバーサービスモジュールによって処理され、結果がリターンされる（７０４）。例えば、その要求はイベント通知の形態である場合がある。イベント通知はイベントサービスによって受取れ、その後に、オブジェクトが、受取った特定のイベント通知に対して予約されている各オブジェクト（アプリケーション共同モジュール、コネクタ又はそれの他の交換サーバー）へ配布される。
【００５２】
分岐Ｂにおいて、トランズアクション要求のタイプが決定される（７０６）。１実施例においては、トランズアクションのタイプは、トランズアクションサガの作成（トランズアクションサガキューを作成するため）、及びサガ演算（付加、削除、リターン、又はアンドゥ（取消し）サガ）を包含している。要求がトランズアクションサガ作成である場合には（７０７）、トランズアクションサービスが新たなトランズアクションに対して記録用のキューを割当て且つそのサガに対する識別子をリータンさせる（７０８）。一方、受取ったトランズアクションがサガ演算である場合には（７０９）、トランズアクションサービスは既存のサガ上で動作し且つその操作のアクノレッジメント（肯定応答）をリターンするか又はアンドゥ（取消し）要求に応答して補償用トランズアクションを実行する（７１０）。
【００５３】
分岐Ｃにおいては、管理要求がタイプされ（７１２）、その後に、適宜のサービスによって操作される（例えば、エラー及び例外サービスによって）（７１４）。１実施例においては、該管理要求はエラーのロギング（ｌｏｇｇｉｎｇ）即ち記録付け、交換サーバードメインにおいてのオブジェクトの開始、停止及びパス、性能データ回収、及びイベントロギング及び診断を包含している。管理要求は、交換サーバー内のオブジェクトによって又はシステム管理インターフェース２０９を介してシステム管理ツールから発生させることが可能である（図３）。分岐Ｄにおいては、コンフィギュレーション要求がコンフィギュレーションサービスによって操作される。コンフィギュレーション要求は、コネクタ、共同、交換サーバーオブジェクトによるか、又はコンフィギュレーションツールによって発生させることが可能である。コンフィギュレーション要求は、アプリケーション共同モジュール及びコネクタのインストール（据付け）又は除去、コネクタ又はアプリケーション共同モジュールの活性化又は脱活性化、及びバージョン追跡及びアップグレイド機能を包含している。コンフィギュレーションサービスは、コンフィギュレーション要求を実行し（７１６）且つ要求するオブジェクト（又は（ユーザ）に対してアクノレッジメント（又は結果）をリターンする（７１８）。その後に該プロセスはステップ６２２において継続し（図６）、サービスするための次の要求を待つ。
【００５４】
次に図３及び８を参照すると、シャットダウンプロセス（図６におけるステップ６２０）は、各アプリケーション共同モジュールへのシャットダウン要求を発生することを包含している（８００）。ステップ８００において発生されたシャットダウン要求に対するアクノレッジメント（肯定応答）信号が受取られたか否かの判別を行なうためのチェックが行なわれる（８０２）。各共同はそれ自身のシャットダウン手順を実行することによってシャットダウン要求に応答する。この実行の一部として、アクノレッジメント（肯定応答）信号が交換サーバー２０へリターンされる。アクノレッジメント信号が受取られなかった場合には、タイムアウトが経過したか否かを判別するためにチェックが行なわれる（８０４）。１実施例においては、そのタイムアウトは、各部品の順序だったシャットダウンを可能とすべく決定される。長いタイムアウトは、タスクを完了することを可能とする。選択されているタイムアウトが短か過ぎる場合には、ある部品において実行中のあるトランズアクションがトランズアクション全体を完了する前に終了される場合があり、補償用トランズアクションを実行することを必要とする。一方、そのタイムアウトは、システムのすぐさまのシャットダウンを強制するために短い時間期間に設定することが可能である。
【００５５】
タイムアウトが未だに経過していない場合には、交換サーバーは、最も短いタイムアウトの経過か又は最後のアクノレッジメントを受取るのを待つ。
【００５６】
そのタイムアウトが経過すると、交換サーバーは（アプリケーション共同モジュールを介して）トランズアクションサービス２４８によるサービスに対するアンドゥ（取消し）トランズアクションを開始する（８０６）。その後にトランズアクションサービスは交換サーバー内において一貫性を維持するために必要な補償用トランズアクションを実行する（８０７）。
【００５７】
最後のアクノレッジメントを受取るか又は最後の補償用トランズアクションの完了の後に、交換サーバー２０は各例示した即ち具体化したコネクタに対するコネクタシャットダウンを発生する（８０８）。各コネクタは、それ自身のシャットダウン手順を実行することによってシャットダウン要求に応答する。この実行の一部として、アクノレッジメント信号が交換サーバー２０へリターンされる。アクノレッジメント信号の全てが受取られたか否かの判別を行なうためのチェックが行なわれる（８１０）。アクノレッジメント信号が受取られていない場合には、タイムアウトが経過したか否かを判別するためのチェックが行なわれる（８１２）。１実施例においてはこのタイムアウトは、各コネクタの秩序だったシャットダウンを可能とすべく設定されている。そのタイムアウトが未だに経過していない場合には、交換サーバーは、最後のアクノレッジメントの受領か又は最も短いタイムアウトの経過を待つ。
【００５８】
そのタイムアウトが経過するか又は最後のアクノレッジメント信号を受取ると、交換サーバーは、それ自身のサービス及び部品の秩序だったシャットダウンを開始する（８１４）。
【００５９】
アプリケーション共同モジュール
典型的に、アプリケーションの一体化は、１つのアプリケーションのオブジェクトと別のアプリケーションのオブジェクトとの「協力（ｃｏｏｐｅｒａｔｉｏｎ）」によって達成される。交換サーバーにおいては、アプリケーションオブジェクトはそれらの夫々のコネクタによって仮想オブジェクトとして表わされている。これらのビジネス仮想オブジェクトは他のビジネス仮想オブジェクト（別のアプリケーションから）と協力し且つアプリケーション統合機能を実行するために「サービス」オブジェクトのファシリティ（機構）を利用する。この種々のアプリケーションオブジェクト間での協力即ち相互作用は、アプリケーション統合セマンチックス（ｓｅｍａｎｔｉｃ）を定義すると共に捕獲し且つ交換サーバーにおけるアプリケーション共同モジュールの形態でカプセル化され且つ格納される。全てのマルチオブジェクトアプリケーション共同モジュールは交換サーバー内のファーストクラスエンティティとして格納され且つ処理され且つアプリケーション共同オブジェクトとして呼称される。このアプリケーション共同オブジェクトは、アプリケーションの統合を実行するために必要なビジネス論理及びブジネス処理の流れをカプセル化する。
【００６０】
次に図１，３，９を参照すると、アプリケーション共同モジュール４０は、オブジェクト表示モジュール９００、ビジネスシナリオモジュール９０２、メッセージング通信モジュール９０４を包含している。
【００６１】
アプリケーション共同モジュール４０は、アプリケーション共同オブジェクトとして交換サーバー２０内に常駐している。アプリケーション共同オブジェクトは、全ての参加する交換（コネクタ及び「サービス」）オブジェクト及びこれらのオブジェクトの間の「ビジネスシナリオ（ｂｕｓｉｎｅｓｓ ｓｃｅｎａｒｉｏ）」を識別する。
【００６２】
オブジェクト表示モジュール９００は、消費方法、受信方法、オブジェクト発生方法を包含するアプリケーション共同オブジェクトと関連する方法を包含している。このモジュールは、又、与えられた共同に参加するために必要な抽象化された再使用可能なクラス及び方法を定義する。メッセージング中心モジュール９０４はイベント通知（ｅｖｅｎｔ ｎｏｔｉｆｉｃａｔｉｏｎ）及び予約（ｓｕｂｓｃｒｉｐｔｉｏｎ）を処理する。イベント予約は、イベント予約サービス２３５へ送信するために発生される。イベント通知はイベント発表サービス（ｅｖｅｎｔ ｐｕｂｌｉｃａｔｉｏｎ ｓｅｒｖｉｃｅ）２３６から受取られる。
【００６３】
ビジネスシナリオモジュール９０２は、協力するアプリケーション間でのメッセージ交換の時間的順番を定義するビジネスシナリオを包含している。それは、更に、このようなメッセージに対するこれらのアプリケーションオブジェクトの反応を定義する。ビジネスシナリオを定義することは、共同するアプリケーションオブジェクトに対する参加用の属性及び方法を識別することを包含している。オブジェクト反応挙動は、無条件的に又は該オブジェクトの状態に基づいてイネーブルさせることの可能な１組の制限的拘束条件及び原因となる規則によって記述される。
【００６４】
アプリケーション間の全ての通信は、アプリケーション共同オブジェクトによって管理され且つ施行される。アプリケーション共同オブジェクトは、交換ユーザがコネクタオブジェクト間での相互作用を定義することを可能とする。アプリケーション共同モジュールの一例は、自動的にインボイス（請求書）を発生し且つ顧客サポートアプリケーションが新たなサポートコールをログ（ｌｏｇ）する場合に、金融システムにおける売掛金エントリへその額を付加することである。アプリケーション共同オブジェクトは、ビジネスシナリオモジュール９０２に格納されている１組のビジネスシナリオによって定義されている。アプリケーション共同モジュールは、単一のビジネス処理指向型機能を有している。幾つかの適用可能な共同が任意の２つのアプリケーションの間で存在する場合があり、且つ共同は２つを超えるアプリケーションが関与する場合がある。単一のビジネス処理機能は、シナリオとも呼ばれる複数個のトランズアクションが関与する場合がある。例えば、２つ以上のアプリケーションを横断して従業員を模倣するアプリケーション共同モジュールは、雇用、解雇、及びステータス変化を取扱うことを必要とし、それらは全て同一アプリケーション共同モジュールに対して異なるシナリオを構成する。
【００６５】
アプリケーション共同モジュールはプロパティシートを介して制御される。プロパティシートは、アプリケーション共同モジュール又はその参加するアプリケーションオブジェクトのいずれかのコンフィギュレーション即ち形態を制御するためのカスタマー（顧客）インターフェースである。アプリケーション共同モジュールプロパティの例は診断レベル、ユーザ名前／パスワード、及び統合シナリオ特定特性である。参加するアプリケーションオブジェクトのプロパティは、これらのアプリケーションオブジェクトの属性のいずれかに対する最大値、最小値、デフォルト値、及び統合特定特性の値の設定を包含している。
【００６６】
アプリケーション共同オブジェクトはファーストクラスエンティティであるので、それらは例えば継承、ポリモリフィズム（ｐｏｌｙｍｏｒｐｈｉｓｍ）即ち多形性、等の典型的なオブジェクトプロパティ（特性）を表示する。アプリケーション共同オブジェクトは、別の共同においてアプリケーションオブジェクトとしてそれが参加することを可能とさせるために、良好に定義されたインターフェースを露呈させる。
【００６７】
次に図１０を参照すると、ビル・バイ・コール（ｂｉｌｌ−ｂｙ−ｃａｌｌ）ビジネスシナリオ用のオブジェクト間のメッセージの流れが示されており、その場合に、１つのオブジェクトから別のオブジェクトへの矢印がこれらのオブジェクト間での順番の付けられたメッセージの流れとしてのオブジェクト相互作用を画定する。ビジネスシナリオは、メッセージの流れ、参加するアプリケーションオブジェクト、それらの属性及び方法、及びそれと関連するビジネス規則を識別することを包含する。アプリケーション共同モジュールにおいていずれかのビジネスシナリオを実行することは、典型的に、交換サービスオブジェクト、コネクタオブジェクト又は別のアプリケーション共同オブジェクトによって発生されるイベント又はメッセージによってトリガすることが可能である。
【００６８】
再度、図９を参照すると、各シナリオ又は１組のオブジェクト相互作用は、有限状態マシン（ＦＳＭ）９０６へ還元させ且つカプセル化される。イベントによってトリガされる場合には、ＦＳＭは処理の流れを表わす。更なる制御を与えるために、イベント、条件及びアクションを直接的にＦＳＭ内において操作し、相互作用の挙動を修正することが可能である。各シナリオと関連しているＦＳＭは、そのアプリケーション共同オブジェクトに対する属性として格納されており、且つそのアプリケーション共同オブジェクトへ送給されるイベント又はメッセージによってトリガされる。
【００６９】
ＦＳＭ実現例は、ＦＳＭ内の「アクション（ａｃｔｉｏｎ）」が、実行時間におけるアプリケーション共同モジュール及び参加するアプリケーションオブジェクトに対する位置、トランズアクション及び性能条件に基づいて、以下のメカニズムのうちの１つへ変換するように分解することが可能である。これらのメカニズムは、同期的である関数（機能）ディスパッチング（簡単なローカル又はリモートな関数（機能）呼出し）、関数（機能）の非同期的な実行を行なう点を除いてリモート機能をディスパッチングに類似しているメッセージング（これはメッセージングシステムの信頼性のあるデリバリ（配達）能力を使用して何等かの機能（関数）を実行する要求を有するリモート（遠隔）オブジェクトへメッセージを送給することによって達成される）、及び同一及び別のＦＳＭ内のイベント発生又は状態変化、を包含することが可能である。ファンクションコール即ち関数（機能）呼出しは、メッセージング又はイベントサービスを介して受取ったオブジェクト又はデータの属性に関して操作を行なうためのビジネス規則を実現することが可能である。
【００７０】
１実施例においては、アプリケーション共同モジュールはジャバ言語で発生され且つ基本共同ジャバクラス及びインターフェース（オブジェクトシステムにおけるサブクラス処理（ｓｕｂ−ｃｌａｓｓｉｎｇ）としても知られている）を拡張する。
【００７１】
次に、図１を参照すると、アプリケーション共同モジュールを構築する方法において、アプリケーション共同モジュール構築器がクロスアプリケーション統合を達成するために必要な相互に関連したアプリケーションオブジェクトのコンフィギュレーション即ち形態を定義する（１１００）。このようなコンフィギュレーションは、簡単なものからより複雑な統合、例えばＥＲＰ（エンタプライズ・リソース・プラニング）アプリケーションを具備する供給チェーン最適化アプリケーションにおける製造スケジュールプランの統合等にわたる単一のビジネスプロセスを表わすものとすべきである。このコンフィギュレーション即ち形態を定義することは、参加するアプリケーションオブジェクト（１１０２）、それらの属性及び所要のアプリケーション統合（１１０４）を実施するのに必要な方法及びアプリケーションオブジェクト間の「関係」（１１０６）を識別することを包含している。
【００７２】
その後に、アプリケーション共同モジュール内のアプリケーションオブジェクト間のメッセージ相互作用を駆動する１組のビジネスシナリオが識別される（１１０８）。各シナリオはビジネスプロセス、システム管理シナリオ、又はユーザの観点からの１組の「ビジネス」トランズアクション（取引）を表わす場合がある。単一のビジネスプロセスにおいて論理的に参加する機能（関数）が実行する１組の全てのシナリオは１つのアプリケーション共同モジュール内にグループ化される。
【００７３】
該シナリオを定義した後に、アプリケーションオブジェクトの構造及び挙動を合体させ且つ抽象化する総括的な組のクラス及びそれらの関係が識別される（１１１０）。
【００７４】
最後に、その挙動がモデル化される（１１１２）。該モデルは、必要である場合に、より細かいグレイン即ち粒状の形態を作成するための繰返しステップへ分割することによって分解することが可能である（１１１４）。このことは、ソリューション即ち解答が最も高いビジネスモデルから開始し、且つ必要に応じて微細なグレイン即ち粒状のサービスオブジェクトへ繰返し下がるような反復的開発を可能とする。
【００７５】
アプリケーション共同オブジェクトは同一のアプリケーションクラスに対する異なるベンダーから派生されるアプリケーションオブジェクトにわたって再使用可能である。このことは、アプリケーション共同オブジェクトをして所要のビジネス挙動（方法）に対する参加するアプリケーションオブジェクトを要求させることにより且つアプリケーション共同オブジェクト自身の一部としてこのような挙動を組込むか又は開発することがないことによって達成される。全てのこのようなベンダー特定機能性はコネクタ内にカプセル化されており、アプリケーション共同モジュールオブジェクトが同一のアプリケーションクラスに対して異なるベンダーのアプリケーションを横断的に再使用することが可能であることを許容している。
【００７６】
アプリケーション共同オブジェクトは、セットアップツール及びコンフィギュレーションツールを使用して交換サーバー内にインストールされている。コンフィギュレーションツールは、例えば参加するアプリケーションのいずれかからもその値を得ることが可能なものでない場合には、ビル・バイ・コール（ｂｉｌｌ−ｂｙ−ｃａｌｌ）共同における請求率を設定すること等のアプリケーション共同モジュールと関連するプロパティシートを設定することを可能とする。
【００７７】
更に、アプリケーション共同モジュールは、例えば、具体化（例示化）特性（スタートアップ又はイベント）、トランズアクションセマンチック（参加するアプリケーションを具備する同期的２ＰＣ又は補償用トランズアクションを具備する非同期的メッセージング）、実行タイミング（スケジュールされており且つ計時される）、及び任意の参加するビジネスシナリオの可能化（イネーブル／ディスエーブル）等のランタイム及び処理基準を制御する種々のプロパティ即ち特性のコンフィギュレーションを行なうことを可能とする。
【００７８】
アプリケーション共同モジュール４０（図１）と関連する処理の流れを図１２に示してある。次に図３及び１２を参照すると、アプリケーション共同モジュールは、インスタンシエーション（ｉｎｓｔａｎｔｉａｔｉｏｎ）即ち具体化（例示化）プロセスの一部として交換サーバー２０から初期化要求を受取る（１２００）。アプリケーション共同モジュールは、ビジネスシナリオモジュール内に格納されているビジネスシナリオと関連するイベント予約を発生し（１２０２）、次いで初期化要求に応答して交換サーバー２０へアクノレッジメント（肯定応答）信号をリターンする（１２０４）。その後に、アプリケーション共同モジュールは、予約されているイベントのデリバリ（配達）を待機し、共同（ｃｏｌｌａｂｏｒａｔｉｏｎ）の開始又は交換サーバーからの管理要求（例えばシャットダウン）をトリガする。
【００７９】
イベント通知（関連するオブジェクトを受取るか、又は交換サーバー２０又はアプリケーションコネクタ３０から受取ったオブジェクトに応答して、ビジネスシナリオモジュール９０２（図９）は該オブジェクトにおいて要求されている方法を実行する。該オブジェクトがイベント通知（１２０７）である場合には、ビジネスシナリオモジュールはトランズアクションサービスから新たなサガを要求する（１２０８）。新たなサガ要求アクノレッジメントをトランズアクションサービスから受取ると、ビジネスシナリオモジュール９０２（図９）はビジネスシナリオモジュール内に格納されているシナリオと関連する有限状態マシンを開始させ（１２１０）及び実行する（１２１１）。該シナリオ内の各サブトランズアクション（ｓｕｂ−ｔｒａｎｓａｔｉｏｎ）において、ビジネスシナリオモジュールがトランズアクションサービスが下側に存在するサブトランズアクションをサガ内に記録することを要求する（１２１２）。その後に、該ビジネスシナリオモジュールは、イベント通知（又はオブジェクトデリバリ）において受取ったデータに関して操作を行ない（１２１４）且つ１つ又はそれ以上のアプリケーションコネクタへ送信するためのオブジェクト（図９のオブジェクト表示モジュール９００により）を発生する（１２１６）。このプロセスは、そのシナリオの終了に到達（ＦＳＭ実行が終了）（１２１８）か又は強制シャットダウン要求が受取られる（１２２０）まで、サブトランズアクション要求及びオブジェクトの発生を継続して行なう。
【００８０】
有限状態マシンが終了まで実行を行なうと、最終的なトランズアクション要求が発生され且つトランズアクションサービスへ送信されてその中に格納されているサガを削除する（１２２２）。その後に、シャットダウンフラグ（「優雅（ｇｒａｃｅｆｕｌ）」又は「強制（ｆｏｒｃｅｄ）」シャットダウンフラグのいずれか）がセットされるか否か（ステップ１２３０及び１２３３において）を判別するためのチェックが行なわれる（１２２３）。そうである場合には、該アプリケーション共同モジュールのシャットダウンが開始される（１２２４）。そうでない場合には、該プロセスはステップ１２０６において継続する。
【００８１】
強制シャットダウンフラグがステップ１２２０においてセットされる場合には、サガアンドゥ要求がトランズアクションサービスへ発行される（１２２６）。その後に、該アプリケーション共同モジュールはそのシャットダウンを開始する（１２２４）。一方、該アプリケーション共同モジュールは、強制シャットダウンを受取った後に全てのトランズアクションを完了すべく試みることが可能であり、その後に進行中のトランズアクションプロセスが完了した時にそれ自身のシャットダウン手順を喚起することが可能である。
【００８２】
ステップ１２０７において受取られるオブジェクトがイベント通知ではない場合には、その受取られたオブジェクトが強制シャットダウン要求であるか否かの判別を行なうためのチェックが行なわれる（１２２８）。そうである場合には、有限状態マシンがアプリケーション共同モジュール内において実行中であるか否かを判別するためのチェックが行なわれる（１２２９）。そうでない場合には、アプリケーション共同モジュールはそのシャットダウン手順を開始させる（１２２４）。有限状態マシンが実行中である場合には、「強制（ｆｏｒｃｅｄ）」シャットダウンフラグがセットされ（１２３０）且つ該プロセスはステップ１２０６において継続する。
【００８３】
その受取られたオブジェクトが強制シャットダウン要求ではない場合には（ステップ１２２８）、その受取れたオブジェクトが「優雅（ｇｒａｃｅｆｕｌ）」シャットダウン要求であるか否かを判別するためのチェックが行なわれる（１２３１）。そうである場合には、「優雅（ｇｒａｃｅｆｕｌ）」シャットダウンフラグがセットされ（１２３３）且つそのプロセスはステップ１２０６において継続する。そうでない場合には、該オブジェクトは、既存の有限状態マシンの実行に起因して該アプリケーション共同モジュールによって発生される要求に応答する。従って、有限状態マシンの実行を再開することが可能である（１２３２）。動作期間中に、エラー及び例外サービス２６０（図３）は、サービス及び交換サーバー部品の状態をモニタする。エラーが発生すると、該エラー及び例外サ−ビスは、アプリケーション共同モジュールへ送信するためのエラー信号を発生する。そのエラーが致命的なものである場合（例えば、メッセージングサービスが故障した場合）、アプリケーション共同モジュールは後方リカバリ（回復）を開始し、次いでシャットダウンを実行する。そのエラーが致命的なものでない場合には、該共同が終了されることを必要とするか否かの判別がなされる。その共同がそれ自身エラーの発生源である場合には、その共同はシャットダウンされることが要求され、従って後方リカバリ（回復）が開始され、それに続いてアプリケーション共同モジュールのシャットダウンが行なわれる。一方、前方リカバリ（回復）は、そのエラーがアプリケーション共同モジュール自身のものであることを暗示するものでない場合に試みることが可能である。
【００８４】
共同定義ツール
共同構築器は共同を構築するための手順プログラムを書込むことは必要とされない。共同定義ツールは、インストールされたコネクタ及び共同開発器に対して使用可能な一般的なクラス階層によってサポートされるビジネスオブジェクトを得るためにレポジトリィ（ｒｅｐｏｓｉｔｒｙ）即ち貯蔵所を読取る。この情報は視覚的な階層形態で共同開発器へ提供される。
【００８５】
共同開発器（ｃｏｌｌａｂｏｒａｔｉｏｎ ｄｅｖｅｌｏｐｅｒ）は、これらのアプリケーションクラスを使用し且つサポートされているオブジェクトモデリング方法の視覚的記号を使用してそれらをオブジェクトとしてモデル化させることが可能である。アプリケーション統合シナリオは、使用可能なアプリケーションオブジェクト間でのメッセージ交換を意味する線及び矢印を描くことにより且つサポートされている方法（アプリケーションオブジェクトに対応）のリストから、適宜の引数と共に受取ったメッセージに対する反応として喚起する方法をピックする即ち採用することによってモデル化することが可能である。ビジネス規則及び拘束条件は、統合した規則定義テーブルを使用することによって定義され且つ良好に画定されたアンカー点においてビジネスシナリオダイヤグラム内に組込まれる。必要とされる場合には、何等かのデータ変換が、アプリケーション統合シナリオ内にこのような変換をアンカーさせるためのフックと共にデータ変換ツールを使用して同様に定義される。従って、共同開発器は、視覚的ツールを使用してコラボレーション（ｃｏｌｌａｂｏｒａｔｉｏｎ）即ち共同全体を構築することが可能である。１例を図１０に示してある。これは単にサンプルの視覚化であって、実際のビジュアルはモデル用ツールによってサポートされているオブジェクトモデル化方法に依存する。
【００８６】
コラボレーション即ち共同が視覚的にモデル化され且つその全てのパーツが画定された後に、共同定義ツールがビジネスシナリオを有限状態マシンへ還元させ且つコンフィギュレーション情報及びジャバクラスファイルを発生する。参加するオブジェクト／クラス、それらの属性及び参加する方法、オブジェクト間の関係、有限状態マシン、例えば位置、実行及びトランズアクションセマンチック等の形態が特定されたプロパティ（特性）を包含する全ての共同コンフィギュレーションは、共同インストール期間中に、レポジトリ即ち貯蔵所内に格納される。該共同を描写し且つコラボレーション定義ツールによって発生されたサポート用のジャバクラスファイルは良好に定義された位置内に格納され且つこれに対する経路はレポジトリ即ち貯蔵所内に格納される。
【００８７】
アプリケーション共同モジュールは、一度インストールされると、必要に応じて他の交換ツールによってコンフィギュア即ち所定の形態とされ且つ管理することが可能である。新たなビジネスオブジェクトを必要とする共同の場合には、このようなオブジェクトを作成し、且つそのオブジェクトが共同器に対してローカルなものである場合には、ジャバコードを書くことによるか又はコネクタ開発ツールキットを使用する（新たなオブジェクトがコネクタから来る場合）によるかのいずれかによって構築するためにプログラム用のツールを使用することが可能である。
【００８８】
コネクタ
コネクタは、交換サーバーとビジネスアプリケーションとの間のインターフェースを行なう。各コネクタはアプリケーションエリア及びベンダー特定的である。該コネクタは、アプリケーションのＡＰＩを利用し、且つ該アプリケーション内のデータ及び演算を交換サーバーのオブジェクト及びイベントモデルへ及びそれから変換する。例えば、人的リソース（ＨＲ）アプリケーションはエンプロイ（ｅｍｐｌｏｙｅｅ）即ち従業員の概念を有することが可能であり、且つ従業員を付加し且つ彼らの月給を変更するためのメカニズムを有することが可能である。対応するアプリケーションコネクタは、交換サーバーのオブジェクトモデルにおける従業員の表示を与える。該アプリケーションにおける変更を検知し且つ追従し、且つ必要である場合には、イベントを発生することがコネクタの責任である。
【００８９】
コネクタはアプリケーションのＡＰＩを処理して、該アプリケーションから情報を抽出し且つ該アプリケーションへ情報を付託する。この文脈における情報はデータと機能（関数）の両方を意味している。
【００９０】
コネクタはアプリケーションオブジェクトとして交換サーバーにおけるアプリケーションからのデータ及び関数（機能）を表わす。アプリケーションオブジェクトモデルは、交換サーバーによって定義された基本オブジェクトモデルに追従する。
【００９１】
コネクタは、又、アプリケーションのデータと挙動及びその交換サーバーにおける表示との間のセマンチック（ｓｅｍａｎｔｉｃ）及びシンタクチック（ｓｙｎｔａｃｔｉｃ）のギャップを橋渡しする。このことは、適宜のデータ変換を実行し且つアプリケーションデータ及び挙動を画定されたオブジェクトモデルへ提供するのに必要な挙動セマンチックを具体化させることを包含している。
【００９２】
コネクタは、又、アプリケーション共同モジュールによって予定される正しい挙動的セマンチックを与えるのに必要なベンダー／アプリケーション特定ビジネス規則及び論理（拘束条件）を組込む。例えば、アプリケーション共同モジュールは、「北米」領域からのみのカスタマー（顧客）を予測するが、該アプリケーションは領域の間で区別を行なわない場合がある。このような場合に、コネクタは、「北米」領域内に入るカスタマーのみをピックアップするためのビジネス論理を包含している。
【００９３】
更に、コネクタは、それをコネクタ内に組込むことによって、アプリケーションによって提供されることのないアプリケーション共同モジュールによって必要とされるアプリケーション及び／又はベンダー特定機能性を提供する。ここでの１例は、ビリング（ｂｉｌｌｉｎｇ）即ち請求機能を提供することのない会計システムである。ビル・バイ・コール（ｂｉｌｌ−ｂｙ−ｃａｌｌ）アプリケーション共同モジュールの場合には、このような請求機能は金融アプリケーション用のコネクタ内に組込まれている。
【００９４】
最後に、コネクタは、アプリケーションにおいて変化が発生する場合にアプリケーション共同モジュール及び交換サーバーへイベント通知を供給する。
【００９５】
コネクタによって提供されるその他の機能は、エラー処理及び通信「ミドルウエア（ｍｉｄｄｌｅｗａｒｅ）」（処理内、処理外及びローカル及び広域ネットワークトポロジィを介して交換サーバーと通信するため）である。コネクタは、又、管理ツールが、該コネクタを何等かのその他の部品として管理し、コネクタをインストールし、セットアップし且つコンフィギュア（ｃｏｎｆｉｇｕｒｅ）即ち所定の形態とさせ、且つセキュリティを与える（コネクタと交換サーバーとの間の安全なトランズアクションのため）を可能とするための管理インターフェースをサポートしている。
【００９６】
次に図１３を参照すると、コネクタ３０はＡＰＩマニュピュレータ１３００、データ変換器１３０２、ビジネス規則及び拘束モジュール１３０４、ビジネスカプセル化モジュール１３０６、メッセージ変換器１３０８、通信モジュール１３１０、オブジェクト表示モジュール１３１２、コンフィギュレーションツールセット及び管理インターフェース１３１４、エラー処理器１３１６を包含している。
【００９７】
典型的に、アプリケーションコネクタは、データベース管理システム内に存在する場合のあるアプリケーションのデータと直接的に相互作用することはない。この代わりに、交換器がアプリケーション特定ＡＰＩマニュピュレータ１３００を使用してベンダーが供給したＡＰＩに対して操作する。このことは、全てのコネクタ動作がアプリケーション自身の処理論理に対して稼動することを可能とし、その際にアプリケーションベンダーの内部論理及びスキーマ変化に依存することを減少している。例えば、カスタマー（顧客）サポートアプリケーションにおいて、カスタマーテーブル内に新たなカスタマーを付加することは、カスタマー契約情報（請求率、サポートレベル、２４×７サポート情報、等）が契約テーブル内においてアップデートされることを必要とする。ＡＰＩ処理は、全てのコネクタにおいて最もベンダー（及びアプリケーション）特定的部分であり、コネクタの論理的スタックの底部にレイヤー化されている。
【００９８】
コネクタはアプリケーションのデータ及び機能（関数）から交換サーバーのオブジェクトモデルへ行く場合及びその逆の場合に双方向シンタクチック及びセマンチック変換を提供する。これらの機能は、データ変換器１３０２、ビジネス規則及び拘束モジュール１３０４及びビジネスカプセル化モジュール１３０６によって与えられる。
【００９９】
データ変換器１３０２は、アプリケーションデータ及び機能（関数）をコネクタに適したデータフォーマットへ変換する。データ変換器は、コネクタ開発ツールと共にバンドルされる変換用のデータフォーマットを視覚的に定義するための対話的ツール１３０２、及び実際の変換を実行し且つコネクタ実行可能コード内に埋め込まれているランタイム部品１３２２を包含している。対話的ツール１３２０は、入力及び出力フォーマット及び適宜の変換を記述する。これらの変換は、暗示的シンタクチック変換からセマンチック内容をベースとした変換までにわたるものである。該ツールは、数学的（＋，−，＊，？，．）ストリング（切り捨て、アペンド、等）論理的（＞，＜、≧，≦、等）及びブール（ＡＮＤ，ＯＲ，ＮＯＴ等）オペレータを供給し、それらは入力及び出力フィールドの内容に関して作業を行なう。それは、又は、必要に応じて、外国語機能を組込むためのフックを提供する。外国語機能の例は、例えば情報を有効化するためのフラットファイル等の異なるデータ源からの外部テーブルを読取ることの可能な機能である。典型的に、データがアプリケーションから読取られるや否や、又はデータがアプリケーションへ書込まれる直前に、実行され、又は、アプリケーション共同論理に依存して、与えられたコネクタに対する異なる時点において実行することが可能である。
【０１００】
ビジネス規則及び拘束モジュール１３０４は、ベンダー特定ビジネス規則及び規則エンジンを実施するのに必要な情報１３３２を有する１組の規則１３３０を定義するツールを包含している。規則エンジン１３３２は該規則を評価する。例えばビジネスアプリケーションは、全世界からのカスタマー（顧客）に対するビジネス記録を与えることが可能である。共同は特定の地理的領域に関連した記録を必要とするに過ぎない場合がある。ビジネスカプセル化モジュールは、このような記録をフィルタするためのスクリーンを与え、且つこのような記録をフィルタするビジネス規則（１組の規則１３３０内に格納されている）を有することによってアプリケーション共同モジュールに対してのオブジェクトとしてこれらの適宜の記録を提供する。
【０１０１】
ビジネスカプセル化モジュール１３０６は、該アプリケーションによって提供されるものではないが、アプリケーション共同モジュールによって必要とされるビジネス機能性を付加する。例えば、カスタマーサポートアプリケーションは１つの場合に対してログされている全てのサポートコールに対して蓄積した時間を追従するものではない場合には、ビジネスカプセル化モジュール１３０６を使用して、所望のビジネス機能性を提供するのに必要なデータベース内の各サポートコールに対する時間を合計することにより１つの場合に対してログ（ｌｏｇ）される時間を持続的に蓄積し且つ格納する。
【０１０２】
イベント通知は、アプリケーション共同モジュールにおいて処理を開始する。イベントは、又、種々の部品間での変化を通信するために使用される。イベントは、コネクタから発生され、アプリケーションがアプリケーションデータ内の修正を交換サーバーと通信することを可能とする。コネクタは、アプリケーション内において発生する変化を追従し且つそれらをイベントを介して交換サーバーへ通信する。
【０１０３】
コネクタは、部品内の故障の場合にこのようなイベントが失われることを防止するために、コネクタを信頼性のあるメッセージングシステム内にキュー即ち行列させることによって、アプリケーションからの持続的なイベント通知に依存する。コネクタの障害の場合には、該コネクタはコネクタが倒れた後に発生した全ての変化を該コネクタが決定し且つ交換サーバーへ通信する。メッセージ変換器１３０８及び通信モジュール１３１０は、コネクタ内の及びコネクタと交換サーバーとの間のメッセージの搬送のためにメッセージ指向型ミドルウエア（ＭＯＭ）を与える。同様のメカニズムは交換サーバーにおいて使用されている。メッセージングミドルウエアは信頼性のあるデリバリ（配達）で逐次的なキュー（行列）を与えることにより地理的に分布したアプリケーション間での共通運用性をサポートするための実行環境によって必要とされる非同期セマンチックスを提供する。これは、アプリケーションが低速の広域ネットワーク上でのアクノレッジメントを待つことがなく、継続して作業を行なうことが可能であることの確保を与えている。下側に存在する仮定は、リモートシステムにキューしたメッセージは絶対にデリバー即ち配達されるということである。ＭＯＭは、又、それらのメッセージを持続的な格納部に対してキュー即ち行列させることによりそのアプリケーションが使用可能でない場合のインスタンス（例）を取扱うためのセマンチックスを提供している。該アプリケーションが再度スタートアップ即ち開始すると、それは格納部から正しい順番でそのメッセージを検索し且つそれらを処理する。このＭＯＭ実現例は、更に、メッセージを消滅させ共同においてトランズアクションのアボート及び回復を必要とするエラーを発生させるためにメッセージに関するタイムアウトを提供する。
【０１０４】
オブジェクト表示モジュール１３１２は、アプリケーションのデータ及び挙動の周りにオブジェクトラッパー（ｏｂｊｅｃｔ ｗｒａｐｐｅｒ）を構築し且つ交換サーバーの基本オブジェクトモデルを使用してそれを提供する。該ラッパーは、このようなデータ及び機能（関数）がアプリケーション又はコネクタ自身内に存在するか否かに拘らず、アプリケーション共同モジュールによって必要とされるアプリケーションのデータ及び機能（関数）スキーマを正確に表わすためのフレームワーク即ち枠組を与える。ラッパーは、又、一般的なフレームワークを解釈し且つ交換サーバーの基本オブジェクトモデルにおいてそのフレームワークの内容を表わす。これは双方向メカニズムであって、それは、又、交換サーバーのオブジェクトモデルからコネクタにおける実行のためのフレームワークへの変換を与える。最後に、該ラッパーは、特定のラッパー又はフレームワークにおけるセマンチックな内容を与え、それは、例えばその属性及びその機能（関数）は何か又はそれらは何をするのか等の与えられたアプリケーションオブジェクトの意味を記述する。
【０１０５】
１実施例においては、任意の言語を使用してコネクタが構築され且つジャバラッパー（Ｊａｖａ ｗｒａｐｐｅｒ）、ＣＯＲＢＡ ＩＢＬ又はマイクロソフトのＯＬＥ／Ａｃｔｉｖｉｘ技術を使用して交換サーバーへ露呈される。交換サーバーは、上述した形態のいずれかにおける部品を喚起（結合）するためのフックを提供する。基本コネクタクラス／インターフェースが定義され、それは３つのタイプ（ジャバ、ＩＤＬ、ＯＬＥ／Ａｃｔｉｖｅｘ）に対する基本クラスを提供するために拡張される。
【０１０６】
アプリケーションオブジェクトは、アプリケーション共同モジュール作成時にそれらのクラス定義によって表わされる。アプリケーションオブジェクトが仮想オブジェクトとしてコネクタによって具体化されるのはランタイムにおいてのみである。アプリケーション共同オブジェクトは、参加するアプリケーションの実行のプラットフォームとは独立的である。最小で、それらは、交換サーバーが実行する同一のプラットフォーム上で実行する。
【０１０７】
エラーハンドラー１３１６は、他の部品における管理インターフェース、ログ用機構及びエラー取扱いサービスと同期する。コンフィギュレーションツール１３１４は種々の管理インターフェースをサポートする。これらのインターフェースは、プラットフォーム特定管理インターフェーススタンダードに執着し、従って既存管理ツールはコネクタプロセスを管理することが可能である。コンフィギュレーションツールも、アプリケーションコネクタのインストールを可能とさせる。
【０１０８】
アプリケーションコネクタは、「オブジェクトファクトリ（ｏｂｊｅｃｔ ｆａｃｔｏｒｙ）」のような動作をする部品である。これは、それが「オブジェクトの作成（ｃｒｅａｔｅ ｏｂｊｅｃｔ）」、「オブジェクト獲得（ｇｅｔ ｏｂｊｅｃｔ）」、「オブジェクトの破壊（ｄｅｓｔｒｏｙ ｏｂｊｅｃｔ）」のようなことを行なうことが可能なインターフェースをサポートするという意味である。これらのオブジェクトは、コネクタ、アプリケーション及び仮想オブジェクトを包含している。それらは、アプリケーション、共同又はサーバーによって提供されるオブジェクト、データ及びサービスを表わす。多くの場合において、これらのオブジェクトは「プロキシィ（ｐｒｏｘｙ）」即ち代理のオブジェクトである。それらは、リモートオブジェクトを表わしているが、実際には、どのようなオブジェクト状態を含むものでない。
【０１０９】
交換サーバーがコネクタオブジェクトへアクセスすることを必要とする場合には、それはそのオブジェクトに対する「ハンドル（ｈａｎｄｌｅ）」を獲得する。交換サーバーの観点からは、コネクタによって提供される任意のオブジェクトは、そのオブジェクトが正確にどこに存在するかということ（データ及び機能（関数））は交換サーバーは全く気にしないという点において、同様のものである。それは、コネクタオブジェクトに対する状態情報を追従するものでもない。オブジェクトに対する状態情報は、必要な場合には、コネクタによって維持される。共同がコネクタオブジェクトの何等かの状態を必要とする場合には、それはローカルオブジェクトを作成し、それはコネクタオブジェクトのスナップショットコピーであってローカル処理のためにそれを使用する。共同は、トランズアクション上の一貫性のために明示的に必要とされない限り、任意のオブジェクト状態情報を維持するためにコネクタに依存することはできない。１実施例においては、コネクタオブジェクトは共同プロセスの性能を拘束化されるためにキャッシュされる。
【０１１０】
各アプリケーションコネクタは、それがどのように処理するかを知っている１組の予め定義されたオブジェクト「タイプ」をサポートしている。例えば、ＨＲアプリケーションは従業員タイプをサポートしている。カスタマーサービスアプリケーションはカスタマーのタイプをサポートしている。全てのアプリケーションコネクタは、例えば、イベントサービスタイプ、イベントタイプ、トランズアクションサービスタイプ、トランズアクションタイプ、受取り方法、消費方法等の所要なサービスを与える目的のために最小組のファシリティ（機構）オブジェクトタイプをサポートすることが必要とされる。１実施例においては、該オブジェクト表現モジュールは、サービス観点からだけのイベントを見る代わりに、イベントに基づいた発表及び予約メカニズムを使用し、従ってイベントは、単に、発表され且つ予約される別の形態のビジネスオブジェクトであるに過ぎない。
【０１１１】
イベント予約に起因するか又は消費方法を喚起することに応答して１つのオブジェクトが受取られると、コネクタがアプリケーションと通信を行ない、要求されたオブジェクトを構築するのに必要なデータを検索し（例えば、データベースに対してクエリを発生する）、必要なデータ変換、規則及びビジネス論理を適用し、そのオブジェクトを構築し、且つ要求者のデリバリ（配達）受領又は消費方法を喚起することによって、そのオブジェクトに対するハンドルを要求者／予約者へリターンさせる。
【０１１２】
該コネクタは、直接的にアプリケーションＡＰＩをコールするか、又はアプリケーションＡＰＩをコールするゲートウエイプロセスと通信することによるかのいずれかによってアプリケーションと通信を行なう。このような通信は、イベントを基礎とした発表・予約メカニズムを使用してより効率的に達成することが可能である。
【０１１３】
交換サーバーにおけるイベントは外部的なもの又は内部的なものとすることが可能である。内部的なイベントは、例えば、アプリケーション共同モジュール、タイマー、同期プリミティブ（ｐｒｉｍｉｔｉｖｅ）、又はその他のサービス等の交換サーバー内のサービスによって発生されるものである。外部的イベントは、例えばコネクタ又はその他の交換サーバー等の外部の部品によって発生されるものである。
【０１１４】
次に、図１３及び１４を参照すると、コネクタ３０に対する処理の流れが示されている。初期化において、コネクタ３０はそれが各共同（１４００）において責任を有するイベントのリストを発表する。次いで、該コネクタは、メッセージ変換器１３０８を介して交換サーバー（１４０１）へイベント予約を与えることによって、それと関連するビジネスシナリオに従ってイベントに対する予約を行なう。その後に該コネクタはアプリケーションか又は交換サーバーのいずれかからの受信情報を待つ。アプリケーションからの情報は、イベントトリガ用情報又はアプリケーション共同モジュールからの情報に対する要求に応答して該アプリケーションからリターンされた情報の形態を取ることが可能である。交換サーバーの情報は、アプリケーション共同モジュールからのビジネスオブジェクト要求又はコネクタによる予約に基づいて共同からの要求されたビジネスオブジェクトのリターンの形態を取ることが可能である。アプリケーション情報がコネクタによって受取られると（１４０２）、データ変換器１３０２はその情報をビジネス規則及び拘束モジュール１３０４に対する適宜のフォーマットへ変換する（１４０６）。ビジネス規則及び拘束モジュール１３０４は、関連する規則のランタイム評価を実行し、アプリケーション共同モジュールによって予定されている特定のベンダー／アプリケーションセマンチックスを組込む（１４０８）。ビジネスカプセル化モジュールは、該アプリケーションによって提供されたものではないがアプリケーション共同モジュールによって要求されるビジネス機能性を付加する（１４０９）。
【０１１５】
その後に、イベント通知がメッセージ変換器１３０８によって発生され（１４１０）且つ適宜のオブジェクトがオブジェクト表現モジュール１３１２によって交換オブジェクトベースモデルに従って作成される（１４１２）。オブジェクト及びイベントはビジネスオブジェクトとして交換サーバーを介して通信モジュール１３１０によってアプリケーション共同モジュールへ転送される（１４１４）。
【０１１６】
交換サーバー情報又は要求が受取られると、このような要求（又は要求に対する応答）はメッセージ変換器１３０８によって処理され（１４１６）且つそのオブジェクトはオブジェクト表現モジュール１３１２によって該コネクタに対する適宜のフォーマットへ変換される（１４１８）。カプセル化モジュールは、コネクタレベルにおいて要求される任意の機能性を付加させる（１４２０）。その後に、ビジネス規則及び拘束モジュール１３０４は、関連する規則のランタイム評価を実行し、アプリケーションによって予測されている特定のベンダー／アプリケーションセマンチックスを組込む（１４２２）。データ変換器１３０２は、その情報をＡＰＩマニュピュレータ１３００用の適宜のフォーマットへ変換し（１４２４）、該マニュピュレータはその情報を該アプリケーションへ転送する（１４２６）。該アプリケーションへリターンされた情報は、該アプリケーションによって取扱うべきデータか又は該共同において使用されるべきデータに対する要求の形態とすることが可能である。
【０１１７】
この処理は、シャットダウン要求が受取られるまで継続する。シャットダウン要求は、補償用トランズアクションを包含することが可能であり、又は該コネクタのシャットダウンのみを要求するに過ぎない場合がある。受領すると、コネクタ３０は例外サービスから受取った補償用トランズアクションを実行し、又はアプリケーション共同モジュールはそれ自身のシャットダウン手順を開始させる。
管理ツール及びインターフェース
次に図５を参照すると、管理ツール５０（図３）はインストールツール１５０２、セットアップツール１５０４、コンフィギュレーションツール１５０６、管理インターフェース１５０８を包含している。
【０１１８】
インストールツール１５０２は、インストールし、所要のパラメータを回収し、且つ交換サーバー内の部品を取除くために使用される。該インストールツールはメタデータ（ｍｅｔａ−ｄａｔａ）駆動型であり、従って該ツールを案内する情報は該ツールによって内在的に知られているものではなく、該部品それ自身の中に格納される。
【０１１９】
セットアップツール１５０４は、その管理ドメイン内における任意の交換サーバー内に部品をインストールさせる。
【０１２０】
コンフィギュレーションツール１５０６もメタデータ駆動型ツールであって、インストールした交換サーバー、アプリケーション共同モジュール及びコネクタのコンフィギュレーション即ち形態を観察し且つ変更するためのツールである。コンフィギュレーションに加えて、それは、又、カスタマー（顧客）が実行用の部品をイネーブル又はディスエーブルさせることを可能とする。コンフィギュレーションメタデータは、交換オブジェクト内にプロパティ（特性）として格納される（交換オブジェクトはコンフィギュラブル即ち形態特定可能なプロパティ挙動を与える基本クラスから受け継いだコンフィギュラブル特性を有するオブジェクトである）。プロパティは、名前、データタイプ、デフォルト値、及び許容可能な値に対する規則を提供する。コンフィギュレーションツール１５０６は、参加するアプリケーションのバージョンを改定する場合（又は本来的に形態特定する場合）自動的バージョン管理を実行する。参加するアプリケーションの異なるバージョンへアップグレイドする場合には、該コンフィギュレーションツールは、その他の部品が必要とされるか否か又は別のアクションが実行されねばならないか否かを判別する。
【０１２１】
管理インターフェース１５０８もメタデータ駆動型である。該メタデータは例えばＳＭＳ又はＳＮＭＰ等のスタンダードインターフェースをポピュレート（ｐｏｐｕｌａｔｅ）させる。スタンダードシステム管理ツールはこれらのインターフェースへアクセスするために使用される。２つの種類の管理インターフェースが存在しており、即ち、リソース管理（どのサーバーがアップであるか、私にスレッドを示せ、私にメモリ利用を示せ、いつログがｘ％満杯であるかを告げろ等）、及びインテグレーション即ち統合（一体化）操作管理である。前者は、標準管理フレームアークフックのサポートを介して与えられる。
【０１２２】
開発ツール
次に、図１６を参照すると、開発ツール６０（図３）はカスタマー及びベンダーが彼ら自身のコネクタを構築することを可能とするコネクタ開発キット１６００を包含している。これは個人的に形成したアプリケーションをインターチェンジ（交換）と統合させることを希望するカスタマー（顧客）にとっては特に有用である。このコネクタ開発キットは、交換プロトコル及びＡＰＩ１６０２、コネクタフレームアーク１６０４（それはソースコードの形態での１組のクラスを提供する）、該コネクタを部品としてパッケージングするパッケージャ（ｐａｃｋａｇｅｒ）１６０６、及び規則及びデータ変換ツール１６０８を包含している。
ビル・バイ・コール共同
コラボレーション（ｃｏｌｌａｂｏｒａｔｉｏｎ）即ち共同の実際的な例は、「ビル・バイ・コール（ｂｉｌｌ−ｂｙ−ｃａｌｌ）」アプリケーション共同モジュールであって、その場合に、コールトラッキング（カスタマーサポート）アプリケーションは、コール即ち通話が完了すると、ビリング（ｂｉｌｌｉｎｇ）即ち伝票発行アプリケーションへ要求を送り、インボイス（伝票）を発生しそれをカスタマー（顧客）へ送る。コール（通話）トラッキングアプリケーションとビリングアプリケーションとの間のビジネス処理相互作用は双方向メッセージ交換を介して行なわれる。コールトラッキングアプリケーションの場合には、必要とされるデータは、カスタマーＩＤ、名前、アドレス及び請求率である。所望のビジネス機能性は、コールトラッキングアプリケーションからのＣａｌｃＣａｌｌＤｕｒａｔｉｏｎ（通話期間を計算するため）及びｔｅｌｌＮａｍｅＡｄｄｒｅｓｓｉｄ（発呼者の名前、アドレス及びカスタマーＩＤを得るため）から構成されている。
【０１２３】
ビリングアプリケーションに対して必要とされるデータはカスタマーＩＤ、伝票発行用のアドレス等である。所望とされるビジネス機能性は、ＶｅｒｉｆｙＣｕｓｔＤｅｔａｉｌｓ（これら有効なカスタマーであるか否かを判別するため）及びＧｅｎｉｎｖｏｉｃｅ（インボイス即ち伝票を発生し且つカスタマーへ送るため）である。このタイプのコラボレーション即ち共同と関連するメッセージの流れを図１０に示してある。
【０１２４】
１つのレベルにおいては簡単であるが、上のアプリケーション共同モジュールは、例えば、（ａ）２つのアプリケーションにおけるカスタマーＩＤが同じでない場合、又は（ｂ）請求率がコールトラッキングアプリケーション、ビリングアプリケーション、又はアプリケーション共同モジュール自身のいずれかによって供給することが可能である場合等のような多様な条件下においては、実際には、きわめて複雑なものとなる場合がある。
【０１２５】
コンフィギュレーションツールを使用して、ユーザは、より特定的なオプションを設定することが可能であり、例えば、どのようにして通話期間をラウンド（ｒｏｕｎｄ）即ち丸めるか、又はそれが通話あたり固定した料金であるか又は分当たりの料金であるかをどのようにして特定するか、通話は個別的に請求されるか又は合計されるか、発呼者がある額のサポートをただで得るか否かをどのようにして判別するか且つどれが請求率を与えるかをどのようにして識別するか（アプリケーションのうちの１つ、即ちアプリケーション共同モジュールか又はそれがどこか他から派生されるものか）等のオプションである。
【０１２６】
インストレーション及びコンフィギュレーションプロセスは、交換サーバーのオブジェクトに関するプロパティ即ち特性を設定し且つこれらのエントリをレポジトリ即ち貯蔵所へ付加させる。該貯蔵所は、又、２つのコネクタ及びアプリケーション共同モジュールの存在及び位置に関する情報を維持する。交換サーバーがブートすると、それは貯蔵所とコンタクトし且つどの部品がスタートアップするものであるかを見つけ出す。この場合には、該２つのコネクタと該１つの共同である。該ブートプロセスはこれらの部品をスタートアップさせ次いで抜け出る。１つの部品がスタートアップすると、それはそのプロパティを検討してそのスタートアップパラメータを決定する。コネクタの場合には、そのパラメータは、接続すべきアプリケーションのネットワーク位置、及びどのようにしてこれらのアプリケーションがカスタマイズされたかに関する情報を包含する。コラボレーション即ち共同の場合には、スタートアッププロパティは、どのコネクタを使用するか、アプリケーション共同オブジェクトをいつ例示化即ち具象化するか（スタートアップ又は要求により）等のようなことを包含している。注意すべきことであるが、コネクタの識別は、位置透明性を保存するためにレジストリ内の名前として特定される。同様に、アプリケーション共同オブジェクトは、その他の交換サーバーのそのオブジェクトへの直接的なアクセスをさせるために該レジスタ内に名前を有している。
【０１２７】
コールトラッキングアプリケーションコネクタは該交換に対してオブジェクト及びイベント指向型インターフェースを提供している。この例のために、オブジェクトがプロダクト（ｐｒｏｄｕｃｔ）、カスタマー（ｃｕｓｔｏｍｅｒ）、ケース（ｃａｓｅ）、コール（ｃａｌｌ）であると想像する。イベントはＮｅｗＣａｓｅ、ＣａｌｌＣｏｍｌｅｔｅｄ、ＣａｓｅＣｌｏｓｅｄである場合がある。コールトラッキングコネクタによってサポートされる方法のうちの１つの例は、ＲｅｔｕｒｎＣａｓｅＨｉｓｔｏｒｙの場合があり、それは全てのコール即ち通話で且つ任意の与えられた場合に対する各々の期間に関して情報をリターンする。
【０１２８】
同様に、ビリングコネクタは、ａｃｃｏｕｎｔｓＲｅｃｅｉｖａｂｌｅｓ方法及びｂｉｌｌＡｃｃｏｕｎｔ方法を露呈させるビリングオブジェクトを供給する。注意すべきことであるが、柔軟性を最大のものとするためにａｃｃｏｕｎｔｓＲｅｃｅｉｖａｂｌｅｓ方法を分離させた。この方法は売掛金システムにおいてインボイス情報をアップデートする。殆どの場合に、カスタマーはどの請求が自動的に売掛金に入れられるかを制御することを希望する。ａｃｃｏｕｎｔｓＲｅｃｅｉｖａｂｌｅを別の方法として設けることは、請求を売掛金へ自動的に挿入することをユーザが制御可能なものとする必要性を簡単化させる。請求が入れられる場合には、該方法が喚起される。そのような挿入がなされるべきでない場合には、該方法は使用されない。
【０１２９】
交換サーバーがブートアップすると、それは、最初に、全てのコネクタを例示化即ち具象化し、次いで全てのアプリケーション共同オブジェクトを例示化する。例示化において、ビリングアプリケーションのコネクタがコールトラッキングコネクタのＣａｓｅＣｌｏｓｅｄイベントに対して予約を行なう（該システムはそのケースが閉じられるまで請求を発生するものではないものと仮定する）。コールトラッキングコネクタは、サポートアナリストがそのケースのステータスをＣＬＯＳＥＤ即ち閉じた状態に設定することによってそのケースを閉じる場合にＣａｓｅＣｌｏｓｅｄイベントを発生する。ＣａｓｅＣｌｏｓｅｄイベントを受取ると、共同オブジェクトは、問題のケース番号に関してのＲｅｔｕｒｎＣａｓｅＨｉｓｔｏｒｙ方法を喚起することによって、そのケースに対しての全てのコール（通話）及びそれらの期間に対してコールトラッキングコネクタに質問を発する。リターンされたコール期間はアプリケーション共同オブジェクトのプロパティによって特定されているビジネス規則に従ってドルの額へ変換される。それは、又、コールトラッキングコネクタに、カスタマーＩＤをカスタマーの名前へ変換するための質問をせねばならない場合があり、又はコールトラッキングアプリケーションにおけるカスタマーＩＤをビリングアプリケーションにおけるカスタマーＩＤへマッピングせねばならない場合がある。
【０１３０】
次いで、共同オブジェクトはビリングコネクタにおけるビリングオブジェクトに対するｂｉｌｌＡｃｃｏｕｎｔ機能を喚起し、それに対して、カスタマーの名前、ドルの金額、コール及びケースを記述するテキストストリングをパスする。請求書をちゃんと発生することは、多分、複数回のデータ変換を必要とする。カスタマーの名前を金融システムのカスタマーＩＤへ変換することが必要な場合があり、且つドルの金額を表示することに関して対処すべき通貨の局地性の問題が存在する場合がある。これらの変換は売掛金アプリケーション内にビリング（請求）情報を実際に提出する前に対処される必要があるので、共同オブジェクトは、所定の組の動的に決定したビジネス規則に基づいて、条件付きのデータ変換を取扱うことが可能である必要性がある。
【０１３１】
全てのデータ変換ステップが処理されると、本コラボレーション（共同）は、ビリングコネクタにおけるａｃｃｏｕｎｔＲｅｃｉｖａｂｌｅｓ機能を喚起し、売掛金に対する「請求したばかり（ｊｕｓｔ ｂｉｌｌｅｄ）」の金額をアップデートすることが可能である。
【０１３２】
以上、本発明の具体的実施の態様について詳細に説明したが、本発明は、これら具体例にのみ限定されるべきものではなく、本発明の技術的範囲を逸脱することなしに種々の変形が可能であることは勿論である。
【図面の簡単な説明】
【図１】 本発明の１実施例に基づくモジュール型アプリケーションコラボレータ（共同器）の概略ブロック図。
【図２】 本発明の１実施例に基づく簡単化したコラボレーション（共同）に対する流れ線図。
【図３】 本発明の１実施例に基づく交換サーバー（ｉｎｔｅｒｃｈｅｎｇｅ ｓｅｒｖｅｒ）の概略ブロック図。
【図４】 本発明の１実施例に基づくイベント発表及び予約サービスに対する流れ線図。
【図５】 本発明の１実施例に基づくトランズアクション（取引）サービスに対する流れ線図。
【図６】 本発明の１実施例に基づく交換サーバーに対する流れ線図。
【図７】 本発明の１実施例に基づく交換サーバーによって実行されるサービス要求に対する流れ線図。
【図８】 本発明の１実施例に基づく交換サーバーに対するシャットダウン手順に対する流れ線図。
【図９】 本発明の１実施例に基づくアプリケーション共同モジュールの概略ブロック図。
【図１０】 本発明の１実施例に基づく簡単なアプリケーション共同に対する順番が付けられたメッセージの流れを示す概略図。
【図１１】 本発明の１実施例に基づくアプリケーション共同を作成するための流れ線図。
【図１２】 本発明の１実施例に基づくアプリケーション共同に対する流れ線図。
【図１３】 本発明の１実施例に基づくコネクタの概略ブロック図。
【図１４】 本発明の１実施例に基づくコネクタに対する流れ線図。
【図１５】 本発明の１実施例に基づく管理ツールの概略ブロック図。
【図１６】 本発明の１実施例に基づくコネクタ開発キットに対するブロック図。
【符号の説明】
１０ モジュール型アプリケーションコラボレータ（共同器）
２０ インターチェンジ（交換）サーバー
３０ コネクタ
４０ アプリケーション共同モジュール
５０ 管理ツール
６０ 開発ツール
７０ アプリケーション
Claims (8)
- アプリケーション間で共通運用性を与えるモジュール型アプリケーション共同装置において、
アプリケーションと通信し、アプリケーション端部と交換端部とを含み、前記アプリケーションから受取った情報に基づいて前記コネクタの前記交換端部へとその情報をパスし、前記交換端部において交換フォーマットオブジェクトへと変換した後アプリケーション共同モジュールに対するトリガとなる前記交換フォーマットオブジェクトを発行するコネクタと、
前記交換フォーマットオブジェクトを受取り、関連するビジネス共通運用性機能を実行し、かつ第２のコネクタに送供され、前記第２のコネクタの交換端部でフォーマット変換されることでオブジェクトを生成するアプリケーション共同モジュールと、サービスモジュールと
を含む交換サーバーを有し、
前記サービスモジュールは、前記複数のコネクタとアプリケーション共同モジュールとの間でメッセージを転送し、前記アプリケーション共同モジュールは２つの以上のアプリケーション間での共通運用性を画定し、前記アプリケーション共同モジュールは前記トリガと前記トリガに応答するトランズアクションとを実行させ、前記トリガは１つ以上のコネクタから前記アプリケーション共同モジュールが前記交換フォーマットオブジェクトを受取ると活性化され、且つ前記トランズアクションは関連するアプリケーションへ転送するために１つ又はそれ以上のコネクタへ前記オブジェクトを伝送する、ことを特徴とするモジュール型アプリケーション共同装置。 - 請求項１において、前記サービスモジュールがトランズアクションサービスとエラーサービスとを包含しており、前記アプリケーション共同モジュールにおけるトランズアクションが１つ又はそれ以上のアクションを包含しており、前記トランズアクションサービスは各アクション及び補償用アクションを記録するためのものであり、前記補償用アクションは関連するアクションを取消すためのものであり、前記エラーサービスは前記交換サーバーにおけるエラーをモニタし且つエラーを検知するとトランズアクションの実行を停止し且つ中断したトランズアクションを取消すために所要の補償用アクションの実行をトリガすることを特徴とする装置。
- 請求項１において、各コネクタがアプリケーションインターフェースと、ビジネスモジュールと、交換サーバーインターフェースとを包含しており、前記アプリケーションインターフェースがコネクタとそれと関連するアプリケーションとの間でデータ及び方法を受取り且つ転送するためのＡＰＩマニュピュレータを包含しており、前記ビジネスモジュールが関連するアプリケーションとアプリケーション共同モジュールとの間で転送するために交換フォーマットオブジェクトを取扱うための方法及び変換を実行し、且つ前記交換サーバーインターフェースがコネクタとアプリケーション共同モジュールとの間で前記交換フォーマットオブジェクト及び方法を転送することを特徴とする装置。
- 請求項１において、アプリケーション共同モジュールは、有限状態マシンを有しており、前記有限状態マシンが、トランザクションを処理するためのメカニズムの１つへ変換することを特徴とする装置。
- 請求項１において、コネクタとアプリケーション共同モジュールとの間のデータ転送が、前記交換サーバーにおける前記サービスモジュールによって転送される前記交換フォーマットオブジェクトを使用する変換により行われるものであることを特徴とする装置。
- 請求項１において、前記交換サーバーは、更に、ＲＡＳサービスを包含しており且つ交換サーバーコンポーネントへのメッセージの送給を確保するためのメッセージサービスを包含していることを特徴とする装置。
- アプリケーション間で共通運用性を与える交換サーバーにおけるモジュール型アプリケーション共同器において、アプリケーション間の共通運用性を与える方法であって、前記サーバーは、アプリケーション共同モジュールと、サービスモジュールとを 含み、前記方法は、交換サーバーに対し、
第１のコネクタに対し、アプリケーションと通信し、アプリケーション端部と交換端部とを含み、前記アプリケーションから受取った情報に基づいて前記交換端部へとその情報をパスし、前記交換端部において交換フォーマットオブジェクトへと変換した後アプリケーション共同モジュールに対するトリガとなる前記交換フォーマットオブジェクトを発行させるステップと、
アプリケーション共同モジュールに対し、前記交換フォーマットオブジェクトを受取り、関連するビジネス共通運用性機能を実行し、かつ第２のコネクタに送供され、前記第２のコネクタの交換端部でフォーマット変換されることでオブジェクトを生成するステップと、を実行させ、
前記サービスモジュールは、前記複数のコネクタとアプリケーション共同モジュールとの間でメッセージを転送し、前記アプリケーション共同モジュールは２つの以上のアプリケーション間での共通運用性を画定し、前記アプリケーション共同モジュールは前記トリガと前記トリガに応答するトランズアクションとを実行させ、前記トリガは１つ以上のコネクタから前記アプリケーション共同モジュールが前記交換フォーマットオブジェクトを受取ると活性化され、且つ前記トランズアクションは関連するアプリケーションへ転送するために１つ又はそれ以上のコネクタへ前記オブジェクトを伝送する、ことを特徴とする方法。 - 前記サービスモジュールがトランズアクションサービスとエラーサービスとを包含しており、前記アプリケーション共同モジュールにおけるトランズアクションが１つ又はそれ以上のアクションを包含しており、前記トランズアクションサービスは各アクション及び補償用アクションを記録するためのものであり、前記補償用アクションは関連するアクションを取消すためのものであり、前記エラーサービスは前記交換サーバーにおけるエラーをモニタし且つエラーを検知するとトランズアクションの実行を停止し且つ中断したトランズアクションを取消すために所要の補償用アクションの実行をトリガするステップを含む、請求項７に記載の方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/780593 | 1997-01-08 | ||
| US08/780,593 US5913061A (en) | 1997-01-08 | 1997-01-08 | Modular application collaboration |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10260825A JPH10260825A (ja) | 1998-09-29 |
| JP3782880B2 true JP3782880B2 (ja) | 2006-06-07 |
Family
ID=25120037
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP32137197A Expired - Lifetime JP3782880B2 (ja) | 1997-01-08 | 1997-11-21 | モジュール型アプリケーション共同装置およびアプリケーション間の共通運用性を与える方法 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US5913061A (ja) |
| EP (1) | EP0853277A3 (ja) |
| JP (1) | JP3782880B2 (ja) |
Families Citing this family (147)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6212556B1 (en) * | 1995-11-13 | 2001-04-03 | Webxchange, Inc. | Configurable value-added network (VAN) switching |
| US8271339B2 (en) | 1995-11-13 | 2012-09-18 | Lakshmi Arunachalam | Method and apparatus for enabling real-time bi-directional transactions on a network |
| US7930340B2 (en) * | 1995-11-13 | 2011-04-19 | Lakshmi Arunachalam | Network transaction portal to control multi-service provider transactions |
| US8037158B2 (en) | 1995-11-13 | 2011-10-11 | Lakshmi Arunachalam | Multimedia transactional services |
| US6745388B1 (en) * | 1997-01-08 | 2004-06-01 | International Business Machines Corporation | Expanded object model including roles |
| US6119173A (en) * | 1997-01-27 | 2000-09-12 | Alcatel Usa Sourcing, L.P. | System and method for communications and process management in a distributed telecommunications switch |
| US6286050B1 (en) | 1997-01-27 | 2001-09-04 | Alcatel Usa Sourcing, L.P. | System and method for monitoring and management of telecommunications equipment using enhanced internet access |
| US6324682B1 (en) * | 1997-02-14 | 2001-11-27 | Velocity.Com | Organicware applications for computer systems |
| US7490169B1 (en) | 1997-03-31 | 2009-02-10 | West Corporation | Providing a presentation on a network having a plurality of synchronized media types |
| JP3652834B2 (ja) * | 1997-04-30 | 2005-05-25 | 富士通株式会社 | クライアント主導のネットワーク・コンピューティングシステムおよび方法 |
| WO1999005597A1 (en) * | 1997-07-25 | 1999-02-04 | British Telecommunications Public Limited Company | Visualisation in a modular software system |
| US5890161A (en) | 1997-10-28 | 1999-03-30 | Microsoft Corporation | Automatic transaction processing of component-based server applications |
| US6134594A (en) | 1997-10-28 | 2000-10-17 | Microsoft Corporation | Multi-user, multiple tier distributed application architecture with single-user access control of middle tier objects |
| US7203288B1 (en) | 1997-11-21 | 2007-04-10 | Dictaphone Corporation | Intelligent routing of voice files in voice data management system |
| US6115690A (en) * | 1997-12-22 | 2000-09-05 | Wong; Charles | Integrated business-to-business Web commerce and business automation system |
| US6310888B1 (en) * | 1997-12-30 | 2001-10-30 | Iwork Software, Llc | System and method for communicating data |
| US6012067A (en) * | 1998-03-02 | 2000-01-04 | Sarkar; Shyam Sundar | Method and apparatus for storing and manipulating objects in a plurality of relational data managers on the web |
| US6233585B1 (en) * | 1998-03-12 | 2001-05-15 | Crossworlds Software, Inc. | Isolation levels and compensating transactions in an information system |
| US6195685B1 (en) * | 1998-05-22 | 2001-02-27 | International Business Machines Corporation | Flexible event sharing, batching, and state consistency mechanisms for interactive applications |
| US6119149A (en) | 1998-06-05 | 2000-09-12 | I2 Technologies, Inc. | System and process allowing collaboration within and between enterprises for optimal decision making |
| US6526416B1 (en) | 1998-06-30 | 2003-02-25 | Microsoft Corporation | Compensating resource managers |
| US6425017B1 (en) * | 1998-08-17 | 2002-07-23 | Microsoft Corporation | Queued method invocations on distributed component applications |
| US6473748B1 (en) * | 1998-08-31 | 2002-10-29 | Worldcom, Inc. | System for implementing rules |
| US6275787B1 (en) * | 1998-10-14 | 2001-08-14 | Unisys Corp. | Method for merging repository updates with incomplete work in progress |
| US6405266B1 (en) * | 1998-11-30 | 2002-06-11 | Hewlett-Packard Company | Unified publish and subscribe paradigm for local and remote publishing destinations |
| US7523471B1 (en) * | 1998-12-18 | 2009-04-21 | Siemens Aktiengesellschaft | Interpretive network daemon implemented by generic main object |
| US6779184B1 (en) * | 1999-01-21 | 2004-08-17 | Oracle International Corporation | Method for loosely coupling object oriented and non-object oriented applications in a messaging-based communication infrastructure |
| US6829770B1 (en) * | 1999-02-23 | 2004-12-07 | Microsoft Corporation | Object connectivity through loosely coupled publish and subscribe events |
| US6748455B1 (en) | 1999-02-23 | 2004-06-08 | Microsoft Corporation | Object connectivity through loosely coupled publish and subscribe events with filtering |
| US7197741B1 (en) * | 1999-04-14 | 2007-03-27 | Adc Telecommunications, Inc. | Interface for an enterprise resource planning program |
| US6526412B1 (en) * | 1999-04-22 | 2003-02-25 | International Business Machines Corporation | Use of adapter key to increase performance when updating a value referenced by a data access object |
| US6529955B1 (en) | 1999-05-06 | 2003-03-04 | Cisco Technology, Inc. | Proxy session count limitation |
| US6430619B1 (en) | 1999-05-06 | 2002-08-06 | Cisco Technology, Inc. | Virtual private data network session count limitation |
| US6728879B1 (en) | 1999-06-02 | 2004-04-27 | Microsoft Corporation | Transactional log with multi-sector log block validation |
| JP2001060155A (ja) * | 1999-08-20 | 2001-03-06 | Fujitsu Ltd | メッセージ処理装置 |
| WO2001024002A2 (en) * | 1999-09-29 | 2001-04-05 | Anna Petrovskaya | System to coordinate the execution of a plurality of separate computer systems to effectuate a process |
| US7017161B1 (en) | 1999-10-11 | 2006-03-21 | Dictaphone Corporation | System and method for interfacing a radiology information system to a central dictation system |
| GB9928226D0 (en) | 1999-11-30 | 2000-01-26 | Ibm | Data processing with message processing nodes wrapped into a business activity |
| US7152220B2 (en) * | 1999-12-09 | 2006-12-19 | Sensemaking Technologies Corp. | Collaboration engine: adding collaboration functionality to computer software |
| AU780753B2 (en) * | 1999-12-14 | 2005-04-14 | International Business Machines Corporation | Client-server computing software architecture |
| US6920636B1 (en) * | 1999-12-15 | 2005-07-19 | Microsoft Corporation | Queued component interface passing for results outflow from queued method invocations |
| WO2001050395A2 (en) | 2000-01-04 | 2001-07-12 | Employeematters, Inc. | Method and system for remotely managing business and employee administration functions |
| AU2001238340A1 (en) * | 2000-02-16 | 2001-08-27 | Bea Systems Inc. | Message routing system for enterprise wide electronic collaboration |
| US6567822B1 (en) * | 2000-03-21 | 2003-05-20 | Accenture Llp | Generating a data request graphical user interface for use in an electronic supply chain value assessment |
| JP2001306535A (ja) * | 2000-04-19 | 2001-11-02 | Hitachi Ltd | アプリケーション・サービス・提供方法及びその実施装置並びにその処理プログラムを記録した記録媒体 |
| CA2306968C (en) * | 2000-04-28 | 2004-11-30 | Ibm Canada Limited-Ibm Canada Limitee | Efficient index-data fetch via callback for a table data |
| US7031976B1 (en) * | 2000-05-26 | 2006-04-18 | Sprint Communications Company L.P. | Computer framework and method for isolating a business component from specific implementations of a datastore |
| US20020066074A1 (en) * | 2000-06-05 | 2002-05-30 | Jabri Mohamed I. | Method and system for developing and executing software applications at an abstract design level |
| US6898783B1 (en) * | 2000-08-03 | 2005-05-24 | International Business Machines Corporation | Object oriented based methodology for modeling business functionality for enabling implementation in a web based environment |
| US7171455B1 (en) | 2000-08-22 | 2007-01-30 | International Business Machines Corporation | Object oriented based, business class methodology for generating quasi-static web pages at periodic intervals |
| US6684388B1 (en) | 2000-08-22 | 2004-01-27 | International Business Machines Corporation | Method for generating platform independent, language specific computer code |
| AU2001286786A1 (en) * | 2000-08-25 | 2002-03-13 | Stuart E. Massey | Transaction-based enterprise application integration (eai) and development system |
| US6853994B1 (en) | 2000-08-30 | 2005-02-08 | International Business Machines Corporation | Object oriented based, business class methodology for performing data metric analysis |
| WO2002023333A2 (en) * | 2000-09-15 | 2002-03-21 | Learnframe, Inc. | Construction of virtual objects based on run-time type information |
| JP2004521530A (ja) * | 2000-10-25 | 2004-07-15 | トムソン・フィナンシャル・インコーポレイテッド | 電子商取引システム |
| US6636875B1 (en) | 2000-10-25 | 2003-10-21 | International Business Machines Corporation | System and method for synchronizing related data elements in disparate storage systems |
| US7305360B1 (en) | 2000-10-25 | 2007-12-04 | Thomson Financial Inc. | Electronic sales system |
| US7330830B1 (en) | 2000-10-25 | 2008-02-12 | Thomson Financial Inc. | Distributed commerce system |
| EP2317432A1 (en) * | 2000-10-26 | 2011-05-04 | Microsoft Development Center Copenhagen ApS | A system and method supporting configurable object definitions |
| US7383355B1 (en) * | 2000-11-01 | 2008-06-03 | Sun Microsystems, Inc. | Systems and methods for providing centralized management of heterogeneous distributed enterprise application integration objects |
| GB2369738B (en) * | 2000-11-29 | 2004-12-15 | Agency Com Interactive Tv As | Method and apparatus for building a platform specific data service |
| US7191453B2 (en) * | 2000-11-30 | 2007-03-13 | Intel Corporation | Discovery and integration of Jini services in non-Java clients |
| US7213231B1 (en) * | 2001-01-11 | 2007-05-01 | Cisco Technology, Inc. | Cross-spectrum application model for dynamic computing environments in software lifecycle |
| US7483979B1 (en) | 2001-01-16 | 2009-01-27 | International Business Machines Corporation | Method and system for virtualizing metadata between disparate systems |
| US20020161859A1 (en) * | 2001-02-20 | 2002-10-31 | Willcox William J. | Workflow engine and system |
| TW586069B (en) * | 2001-03-01 | 2004-05-01 | Ibm | A method and a bridge for coupling a server and a client of different object types |
| US20030204835A1 (en) * | 2001-03-30 | 2003-10-30 | Versioning Method For Business Process Models | Versioning method for business process models |
| US20030140126A1 (en) * | 2001-03-30 | 2003-07-24 | Vitria Technology, Inc. | Method of deployment for concurrent execution of multiple versions of an integration model |
| US7499948B2 (en) * | 2001-04-16 | 2009-03-03 | Bea Systems, Inc. | System and method for web-based personalization and ecommerce management |
| US7231460B2 (en) * | 2001-06-04 | 2007-06-12 | Gateway Inc. | System and method for leveraging networked computers to view windows based files on Linux platforms |
| US20020188774A1 (en) * | 2001-06-08 | 2002-12-12 | Lessard Michael R. | Virtualizing external data as native data |
| US20020188727A1 (en) * | 2001-06-08 | 2002-12-12 | Lessard Michael R. | Method for processing external data for access and manipulation through a host operating environment |
| US7536697B2 (en) | 2001-06-19 | 2009-05-19 | Accenture Global Services Gmbh | Integrating enterprise support systems |
| US6877107B2 (en) * | 2001-07-05 | 2005-04-05 | Softwired Ag | Method for ensuring operation during node failures and network partitions in a clustered message passing server |
| EP1442368A4 (en) * | 2001-09-19 | 2006-05-10 | Steven G Belovich | METHOD AND SYSTEM FOR PROVIDING A VIRUS IMMUNE BASED ON RULES |
| US20090106353A1 (en) * | 2001-09-19 | 2009-04-23 | Belovich Steven G | Method and system for providing an event auditing client server software arrangement |
| US7177856B1 (en) | 2001-10-03 | 2007-02-13 | International Business Machines Corporation | Method for correlating data from external databases |
| US7552203B2 (en) * | 2001-10-17 | 2009-06-23 | The Boeing Company | Manufacturing method and software product for optimizing information flow |
| US20030120539A1 (en) * | 2001-12-24 | 2003-06-26 | Nicolas Kourim | System for monitoring and analyzing the performance of information systems and their impact on business processes |
| US20030126159A1 (en) * | 2001-12-28 | 2003-07-03 | Nwafor John I. | Method and system for rollback of software system upgrade |
| US6934706B1 (en) | 2002-03-22 | 2005-08-23 | International Business Machines Corporation | Centralized mapping of security credentials for database access operations |
| US20030187763A1 (en) * | 2002-03-26 | 2003-10-02 | The Regents Of The University Of California | Intelligent inter-organizational system for procurement and manufacturing |
| US7454760B2 (en) | 2002-04-22 | 2008-11-18 | Rosebud Lms, Inc. | Method and software for enabling n-way collaborative work over a network of computers |
| US7899888B2 (en) * | 2002-06-28 | 2011-03-01 | Oracle America, Inc. | Runtime versioning of information processing systems |
| US9521209B2 (en) * | 2002-11-06 | 2016-12-13 | Code Valley Corp Pty Ltd | Code generation |
| US8832178B2 (en) | 2002-11-06 | 2014-09-09 | Noel William Lovisa | Service implementation |
| US8589861B2 (en) * | 2002-11-06 | 2013-11-19 | Code Valley Corp Pty Ltd | Code generation |
| EP1424643A1 (en) * | 2002-11-26 | 2004-06-02 | Sap Ag | Processing business schemas with predefined sequences and predefined documents on personal computer |
| US7349949B1 (en) | 2002-12-26 | 2008-03-25 | International Business Machines Corporation | System and method for facilitating development of a customizable portlet |
| US7359982B1 (en) | 2002-12-26 | 2008-04-15 | International Business Machines Corporation | System and method for facilitating access to content information |
| US20040139141A1 (en) * | 2002-12-31 | 2004-07-15 | Lessard Michael R. | Integration of virtual data within a host operating environment |
| US7254733B2 (en) * | 2003-02-18 | 2007-08-07 | International Business Machines Corporation | Method of shutting down virtual machines in an orderly manner |
| US20040204947A1 (en) * | 2003-03-28 | 2004-10-14 | Ruicheng Li | System and method for generic business scenario management |
| US20050033588A1 (en) * | 2003-08-04 | 2005-02-10 | Mario Ruiz | Information system comprised of synchronized software application moduless with individual databases for implementing and changing business requirements to be automated |
| US20050108275A1 (en) * | 2003-11-17 | 2005-05-19 | Capotosto Thomas P. | Disaggregation of services into building blocks |
| US20050144099A1 (en) * | 2003-12-24 | 2005-06-30 | Indrojit Deb | Threshold billing |
| US7849085B2 (en) * | 2004-05-18 | 2010-12-07 | Oracle International Corporation | System and method for implementing MBSTRING in weblogic tuxedo connector |
| US20060085206A1 (en) * | 2004-10-08 | 2006-04-20 | Timo Seufert | System and method for a controller to define, determine, and execute cross-application processes |
| US7437080B2 (en) * | 2005-02-03 | 2008-10-14 | Stratalight Communications, Inc. | Optical transmission system having optimized filter wavelength offsets |
| US8005791B1 (en) * | 2005-03-14 | 2011-08-23 | Oracle America, Inc. | Methods and systems for publishing aggregated data to a business logic tier |
| US7747985B2 (en) * | 2005-03-18 | 2010-06-29 | Microsoft Corporation | Conformance testing of multi-threaded and distributed software systems |
| US7500149B2 (en) * | 2005-03-31 | 2009-03-03 | Microsoft Corporation | Generating finite state machines for software systems with asynchronous callbacks |
| US7949551B2 (en) | 2005-04-06 | 2011-05-24 | International Business Machines Corporation | Processing of compensation scopes in workflow management systems |
| EP1748384B1 (en) * | 2005-04-06 | 2009-07-22 | International Business Machines Corporation | Processing of compensation scopes in workflow management systems |
| US20060229866A1 (en) * | 2005-04-07 | 2006-10-12 | Business Objects, S.A. | Apparatus and method for deterministically constructing a text question for application to a data source |
| US20060230028A1 (en) * | 2005-04-07 | 2006-10-12 | Business Objects, S.A. | Apparatus and method for constructing complex database query statements based on business analysis comparators |
| US20060229853A1 (en) * | 2005-04-07 | 2006-10-12 | Business Objects, S.A. | Apparatus and method for data modeling business logic |
| US20060230027A1 (en) * | 2005-04-07 | 2006-10-12 | Kellet Nicholas G | Apparatus and method for utilizing sentence component metadata to create database queries |
| US7665072B2 (en) | 2005-04-21 | 2010-02-16 | Microsoft Corporation | Generating test cases for software with complex preconditions |
| US7739218B2 (en) * | 2005-08-16 | 2010-06-15 | International Business Machines Corporation | Systems and methods for building and implementing ontology-based information resources |
| US8255818B2 (en) * | 2005-11-17 | 2012-08-28 | Oracle International Corporation | System and method for providing drag and drop functionality in a communities framework |
| US20070112798A1 (en) * | 2005-11-17 | 2007-05-17 | Bea Systems, Inc. | System and method for providing unique key stores for a communities framework |
| US20070112856A1 (en) * | 2005-11-17 | 2007-05-17 | Aaron Schram | System and method for providing analytics for a communities framework |
| US8185643B2 (en) * | 2005-11-17 | 2012-05-22 | Oracle International Corporation | System and method for providing security in a communities framework |
| US8046696B2 (en) * | 2005-11-17 | 2011-10-25 | Oracle International Corporation | System and method for providing active menus in a communities framework |
| US20070112913A1 (en) * | 2005-11-17 | 2007-05-17 | Bales Christopher E | System and method for displaying HTML content from portlet as a page element in a communites framework |
| US7590687B2 (en) * | 2005-11-17 | 2009-09-15 | Bea Systems, Inc. | System and method for providing notifications in a communities framework |
| US8078597B2 (en) * | 2005-11-17 | 2011-12-13 | Oracle International Corporation | System and method for providing extensible controls in a communities framework |
| US7805459B2 (en) * | 2005-11-17 | 2010-09-28 | Bea Systems, Inc. | Extensible controls for a content data repository |
| US7493329B2 (en) * | 2005-11-17 | 2009-02-17 | Bea Systems, Inc. | System and method for providing generic controls in a communities framework |
| US7680927B2 (en) * | 2005-11-17 | 2010-03-16 | Bea Systems, Inc. | System and method for providing testing for a communities framework |
| US20070112781A1 (en) * | 2005-11-17 | 2007-05-17 | Mcmullen Cindy | System and method for providing search controls in a communities framework |
| US20070112799A1 (en) * | 2005-11-17 | 2007-05-17 | Bales Christopher E | System and method for providing resource interlinking for a communities framework |
| JP5292670B2 (ja) * | 2006-02-22 | 2013-09-18 | 富士通株式会社 | 開発支援プログラム、開発支援方法、及び開発支援装置 |
| US20070261065A1 (en) * | 2006-04-20 | 2007-11-08 | Astl Kenneth L | Framework for generating pre-packaged business integration component group pattern-based applications |
| US7996855B2 (en) * | 2006-09-15 | 2011-08-09 | Oracle International Corporation | Personal messaging application programming interface for integrating an application with groupware systems |
| US8463852B2 (en) * | 2006-10-06 | 2013-06-11 | Oracle International Corporation | Groupware portlets for integrating a portal with groupware systems |
| US7996488B1 (en) | 2006-11-27 | 2011-08-09 | Disney Enterprises, Inc. | Systems and methods for interconnecting media applications and services with automated workflow orchestration |
| US8086758B1 (en) | 2006-11-27 | 2011-12-27 | Disney Enterprises, Inc. | Systems and methods for interconnecting media applications and services with centralized services |
| US7720918B1 (en) * | 2006-11-27 | 2010-05-18 | Disney Enterprises, Inc. | Systems and methods for interconnecting media services to an interface for transport of media assets |
| US8341646B2 (en) * | 2007-01-26 | 2012-12-25 | Sap Ag | Information system with event-enabled data objects |
| US20100023798A1 (en) * | 2008-07-25 | 2010-01-28 | Microsoft Corporation | Error recovery and diagnosis for pushdown automata |
| WO2010014544A2 (en) | 2008-07-28 | 2010-02-04 | Sony Corporation | Client device, information processing system and associated methodology of accessing networked sevices |
| CN101833479B (zh) * | 2010-04-16 | 2014-05-21 | 中国人民解放军国防科学技术大学 | 多网络环境下基于强化学习的mpi消息调度方法 |
| US8620724B2 (en) | 2010-04-20 | 2013-12-31 | Accenture Global Services Limited | Integration framework for enterprise content management systems |
| CN102622216A (zh) * | 2011-01-30 | 2012-08-01 | 国际商业机器公司 | 一种用于应用的协同工作的方法和系统 |
| US9959278B1 (en) * | 2011-09-29 | 2018-05-01 | EMC IP Holding Company LLC | Method and system for supporting block-level incremental backups of file system volumes using volume pseudo devices |
| US9128973B1 (en) | 2011-09-29 | 2015-09-08 | Emc Corporation | Method and system for tracking re-sizing and re-creation of volumes using modification time |
| US9262238B2 (en) * | 2012-01-31 | 2016-02-16 | Red Hat, Inc. | Connection management for an application in a computing platform |
| US9665356B2 (en) | 2012-01-31 | 2017-05-30 | Red Hat, Inc. | Configuration of an application in a computing platform |
| US9170797B2 (en) | 2012-01-31 | 2015-10-27 | Red Hat, Inc. | Automated deployment of an application in a computing platform |
| CA2791771C (en) | 2012-10-05 | 2019-09-10 | Ibm Canada Limited - Ibm Canada Limitee | Dynamic and selective management of integration points using performance metrics |
| US10579366B2 (en) * | 2013-09-16 | 2020-03-03 | Nicira, Inc. | Data upgrade framework for distributed systems |
| US10229042B2 (en) * | 2017-01-19 | 2019-03-12 | International Business Machines Corporation | Detection of meaningful changes in content |
| US11405300B2 (en) * | 2017-06-20 | 2022-08-02 | Vmware, Inc. | Methods and systems to adjust resources and monitoring configuration of objects in a distributed computing system |
| US10514895B2 (en) | 2017-09-08 | 2019-12-24 | Bank Of America Corporation | Tool for generating event case management applications |
| GB201717766D0 (en) * | 2017-10-30 | 2017-12-13 | Suites Digital Pte Ltd | Offline sales execution system |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5187787B1 (en) | 1989-07-27 | 1996-05-07 | Teknekron Software Systems Inc | Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes |
| EP0573711A1 (en) * | 1992-06-12 | 1993-12-15 | International Business Machines Corporation | Data processing system |
| WO1995010805A1 (en) * | 1993-10-08 | 1995-04-20 | International Business Machines Corporation | Message transmission across a network |
| US5787300A (en) * | 1993-11-10 | 1998-07-28 | Oracle Corporation | Method and apparatus for interprocess communications in a database environment |
| CA2149445A1 (en) * | 1994-07-27 | 1996-01-28 | Aziza Bushra Faruqi | Separation and transmission control method and apparatus for a microkernal data processing system |
| US5732270A (en) | 1994-09-15 | 1998-03-24 | Visual Edge Software Limited | System and method for providing interoperability among heterogeneous object systems |
-
1997
- 1997-01-08 US US08/780,593 patent/US5913061A/en not_active Expired - Lifetime
- 1997-11-04 EP EP97308844A patent/EP0853277A3/en not_active Withdrawn
- 1997-11-21 JP JP32137197A patent/JP3782880B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| EP0853277A2 (en) | 1998-07-15 |
| JPH10260825A (ja) | 1998-09-29 |
| US5913061A (en) | 1999-06-15 |
| EP0853277A3 (en) | 2000-05-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3782880B2 (ja) | モジュール型アプリケーション共同装置およびアプリケーション間の共通運用性を与える方法 | |
| US6094688A (en) | Modular application collaboration including filtering at the source and proxy execution of compensating transactions to conserve server resources | |
| US7020880B2 (en) | Modular application collaborator for providing inter-operability between applications and monitoring errors to trigger execution of required compensating actions to undo interrupted transaction | |
| US8185665B2 (en) | Distributed computing system architecture | |
| US7788319B2 (en) | Business process management for a message-based exchange infrastructure | |
| Cichocki et al. | Workflow and process automation: concepts and technology | |
| US7213049B2 (en) | System and method for transaction processing with transaction property feature | |
| US20090125366A1 (en) | Method and system for dynamic adaptation of workflows | |
| Shrivastava et al. | Architectural support for dynamic reconfiguration of large scale distributed applications | |
| US6038589A (en) | Apparatus, method and computer program product for client/server computing with a transaction representation located on each transactionally involved server | |
| Belhajjame et al. | A flexible workflow model for process-oriented applications | |
| JP3409308B2 (ja) | クライアント／サーバ・コンピューティング・システム及びサーバ処理方法 | |
| US20050114240A1 (en) | Bidirectional interfaces for configuring OSS components | |
| US6766323B2 (en) | System, method and computer program for application support in a data processing system | |
| Papaioannou et al. | Mobile agent technology in support of sales order processing in the virtual enterprise | |
| Alonso et al. | Enterprise application integration | |
| Jin et al. | An execution and transaction model for active, rule-based component integration middleware | |
| Biörnstad | A workflow approach to stream processing | |
| Ranno et al. | A review of distributed workflow management systems | |
| Alonso et al. | Service composition | |
| McGovern et al. | Orchestration | |
| Mejia | ACTA DEPENDENCIES AS A UNIFIED MECHANISM FOR COMPENSATION, ACTIVITIES SYNCHRONIZATION AND FUNCTIONAL REPLICATION IN BPEL4WS | |
| Liebig et al. | Advanced transactions | |
| Hong et al. | An abstract architecture for dependable and flexible distributed applications | |
| Satapathy et al. | Application of agent building tools in factory scheduling and control systems |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051115 |
|
| RD12 | Notification of acceptance of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7432 Effective date: 20051209 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20051209 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060210 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060307 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20060307 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060313 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100317 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110317 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110317 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120317 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130317 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140317 Year of fee payment: 8 |
|
| EXPY | Cancellation because of completion of term |