(57)【特許請求の範囲】
【請求項１】
通信ネットワークに接続した取引パートナー間での入力及び出力ドキュメントの交換を介した商取引トランザクションを実行するシステムであって、
前記取引パートナーにより定義される入力及び出力ドキュメントデータを前記通信ネットワーク上で送信及び受信するための１又はそれ以上のクライアントコンピュータ(11)と、
前記クライアントコンピュータに関連するトランザクションのために、入力及び出力ドキュメントデータを処理するトランザクションプロセッサ・フロントエンド(304)を有するサーバと、
前記クライアントコンピュータ間のインターフェースのための定義を記憶するリポジトリサーバであって、前記定義は、前記取引パートナー間のトランザクションで使用される前記入力ドキュメント(211)及び出力ドキュメント（212)に関する論理構造情報のマッピング（対応）データを含む当該リポジトリサーバとを備え、
前記サーバは、
（１）前記レポジトリサーバ内の入力及び出力ドキュメントに関する論理構造情報を参照し、ユーザ入力を基に生成された入力ドキュメントを受け入れるデータ入力手段と、
（２）前記入力ドキュメントを構文解析する構文解析手段(301)と、
（３）前記リポジトリサーバ内のマッピングデータを使って、前記構文解析された前記入力ドキュメントを、前記入力ドキュメントからデータを受信するように設計された内部データ構造に変換し、トランザクションデータを、前記出力ドキュメントのためにデータを提供するよう設計されたデータ構造に変換するトランスレータ手段(302)と、
（４）前記内部データ構造に変換された前記入力ドキュメントを受信するイベントリスナー手段(308)であって、前記イベントリスナー手段によって実行される各リスナーモジュールは、前記入力ドキュメントの異なる他の部分とは互いに独立して作動しトランザクションデータを生成させる当該イベントリスナー手段と、
（５）前記出力ドキュメントを前記クライアントコンピュータに送信する情報提供（パブリッシャー）手段と、
を含むシステム。
【請求項２】
前記リポジトリサーバは、前記クライアントコンピュータを介して、ユーザが前記リポジトリサーバに記憶された入力及び出力ドキュメントに関する論理構造情報にアクセス可能であることを特徴とする請求項１に記載の装置。
【請求項３】
前記リポジトリサーバは、論理構造情報を含む前記入力及び出力ドキュメントを詳細に定義するためのデータを記憶することを特徴とする請求項２に記載の装置。
【請求項４】
前記サーバは、補足的(complementary)なトランザクションに関する他のクライアントコンピュータからの入力及び出力ドキュメントの論理構造情報を得るため前記リポジトリサーバにアクセスすることを更に含み、
前記入力ドキュメントデータの論理構造情報として、前記補足的なトランザクションの出力ドキュメントの論理構造情報を含むことによって、前記取引パートナーの入力及び出力ドキュメント間のインターフェースのための定義を前記リポジトリサーバに記憶する請求項１に記載の装置。
【請求項５】
前記リポジトリサーバは、前記出力ドキュメントの論理構造情報として、前記補足的なトランザクションの入力ドキュメントの論理構造情報を記憶する請求項４に記載の装置。
【請求項６】
前記データ入力手段は、特定のトランザクション識別子を記憶するための論理構造を有する入力及び出力ドキュメントデータ間でインターフェースを定義するためのドキュメントを受け入れ、前記構文解析手段は、前記特定のトランザクションのための入力及び出力ドキュメントデータ間の定義及びその定義への参照のうち少なくとも一つを用いて構文解析することを含む請求項１に記載の装置。
【請求項７】
前記サーバは、前記取引パートナーの識別子を記憶し、並びに前記取引パートナーによってサポートされる１以上のトランザクションの組の仕様及び仕様への参照のうち少なくとも一つを記憶するドキュメントを、前記論理構造情報のマッピングデータに従って処理する請求項１に記載の装置。
【請求項８】
前記取引パートナーの入力及び出力ドキュメントデータ間のインターフェースのための定義に従った前記入力及び出力ドキュメントは、特定のトランザクションの仕様への参照を含み、そして、前記特定のトランザクションの仕様には、前記特定のトランザクションのための入力及び出力ドキュメントデータ間の定義及びその定義への参照のうち少なくとも一つを記録するための論理構造情報が含まれている請求項７に記載の装置。
【請求項９】
前記入力及び出力ドキュメントの論理構造情報は、可変トランザクション処理アーキテクチャに従った変数及びメソッドを含むプログラミング・オブジェクトを生成する請求項１に記載の装置。
【請求項１０】
前記可変トランザクション処理アーキテクチャは、インターフェース記述言語に従った処理を実行することを特徴とする請求項９に記載の装置。
【発明の詳細な説明】
【０００１】
（発明の属する技術分野）
本発明は、ネットワークに接続された多様なクライアントの間でのトランザクション（取引）をサポートするシステム及びプロトコルに関し、詳細には、いろいろなアーキテクチャを有するプラットフォームの間での商取引をサポートするシステム及びプロトコルに関する。
【０００２】
（従来の技術）
インターネットやその他の通信ネットワークは、参加者が商品やサービスを売買する商取引を含む幅広く多様なトランザクションに使用されつつあるコンピュータプラットフォームと人との間の通信のための手段を提供している。インターネット上での商取引を促進させるために多くの努力がなされつつある。しかしながら、多くの競合する標準があるので、トランザクションを実行するためには、そのトランザクションへの関係者は、前もって、用いられるプロトコルに同意しなければならないし、しばしば、かかるトランザクションをサポートするためプラットフォームアーキテクチャのカスタムインテグレーション（専用の統合）を必要とする。同意した標準にコンパチブルでない特定のノード内への商業的プロセスは、他のノードとのインテグレーションのために相当の手直しを必要とするかも知れない。更に、一つの会社（Ｃｏｍｐａｎｙ）が１つの標準又は他の標準にコミットすると、その会社は標準化グループのトランザクション関係者に固定され、それ以外を排除する。
【０００３】
インターネット商取引の開発に遭遇した挑戦の概要が、「Ｅｃｏ  Ｓｙｓｔｅｍ：Ａｎ  Ｉｎｔｅｒｎｅｔ  Ｃｏｍｍｅｒｃｅ  Ａｒｃｈｉｔｅｃｔｕｒｅ」  Ｔｅｎｅｎｂａｕｍ  外著：Ｃｏｍｐｕｔｅｒ，Ｍａｙ  １９９７；４８〜５５ページに記載されている。
【０００４】
インターネット上での商取引を開放するため、アーキテクチャフレームワークの標準化が望ましい。かかる商業フレームワークをサポートするために開発されたプラットフォームは、ＩＢＭのＣｏｍｍｅｒｃｅ  Ｐｏｉｎｔ；Ｍｉｃｒｏｓｏｆｔ  Ｉｎｔｅｒｎｅｔ  Ｃｏｍｍｅｒｃｅ  Ｆｒａｍｅｗｏｒｋｓ；ＮｅｔｓｃａｐｅのＯＮＥ（Ｏｐｅｎ  Ｎｅｔｗｏｒｋ  Ｅｎｖｉｒｏｎｍｅｎｔ）；ＯｒａｃｌｅのＮＣＡ（Ｎｅｔｗｏｒｋ  Ｃｏｍｐｕｔｉｎｇ  Ａｒｃｈｉｔｅｃｔｕｒｅ）；及びＳｕｎ／ＪＡＶＡのソフトＪＥＣＦ（ＪＡＶＡ  Ｅｌｅｃｔｒｏｎｉｃ  Ｃｏｍｍｅｒｃｅ  Ｆｒａｍｅｗｏｒｋ）を包含する。
【０００５】
これらの専有のフレームワークに加えて、ＣＯＲＢＡ  ＩＩＯＰ（Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ  Ｉｎｔｅｒｎｅｔ  ＯＲＢ  Ｐｒｏｔｏｃｏｌ）に基づく、共通に配布されたオブジェクトモデルのようなプログラム技術が遂行されつつある。その共通配布のオブジェクトモデルの使用は、企業のシステムを、電子商取引のためのビジネスアプリケーションレベルで共同利用できるシステムにマイグレーション（交換）するのを簡単にしようとするためのものである。しかしながら、１つのフレームワークを用いる消費者又はビジネスは、異なるネットワーク上でトランザクションを実行することはできない。これが電子商取引システムの成長を制限している。
【０００６】
１つのフレームワークを実施する会社は、アプリケーションプログラミングインタフェース（ＡＰＩ）をもつであろうし、このＡＰＩは他のフレームワークをサポートするＡＰＩとは異なるものであろう。従って、会社にとって、共通のビジネスシステムインタフェースの採用を必要とせずに、相互にビジネスサービスにアクセスするのは大変に困難である。かかるＡＰＩレベルでのビジネスシステムインタフェースの開発は、関係者間でのかなりの協力が必要であるが、それはしばしば実際にはできない。
【０００７】
従って、通信ネットワーク内の多様なプラットフォーム間での対話（インタラクション）を促進するフレームワークを提供することが望ましい。かかるシステムは、カスタムインテグレーションや産業上でのワイドな標準に事前同意を必要とせずに、取引のパートナー間での自発的な商売を促進するであろう。更に、かかるシステムは、ビジネスオートメーションへの前進を促進して、伝統的なシステムインテグレーションの時間やコストやリスクの多くを排除するであろう。
【０００８】
全般的に、専有の標準に基づいた、閉じた商業パートナーネットワークを、開放マーケットに置き換えられる電子商取引システムを提供するのが望ましい。
【０００９】
（発明の概要）
本発明は、ビジネスをカストマーや供給業者や商業パートナーにつなぐためのインフラストラクチャ（基盤＝インフラ）を提供する。本発明のインフラストラクチャの下では、複数の会社は相互に、自己定義のマシン読取り可能なドキュメント（例えば、パートナーの間で容易に理解できるＸＭＬ（拡張マークアップ言語）系のドキュメント）を用いて情報及びサービスを交換する。交換されるべきドキュメントを記述するドキュメント（本書ではビジネスインタフェース定義すなわちＢＩＤと呼ぶ）が、インターネット上で送られ、あるいは、ネットワークのメンバーに通信される。ビジネスインタフェース定義（ＢＴＤ）は、潜在的な商業パートナーに、会社が提供するサービスとそのサービスに通信する時に使用するためのドキュメントとを告げる。従って、代表的なビジネスインタフェース定義によって、カストマーは購買オーダ（その購買オーダを受取るパーティのＢＩＤで発行されたドキュメント定義に従う購買オーダ）を提出することによってオーダを行うことができる。供給業者は、ビジネスシステム管理在庫データのＢＩＤで発行されたドキュメント定義に従った在庫状況報告をダウンロードすることによってその有効性をチェックすることが可能になる。予め定義したマシン読取り可能なビジネスドキュメントの使用によって、エンタプライズ（企業）のアプリケーションにアクセスするためのより直観的な柔軟な方法が提供される。
【００１０】
商業ネットワーク内でのノードは、インタフェースのマシン読取り可能なスペシフィケーションから成る本発明によるトランザクションのためのインタフェースを、そのインタフェースのマシン読取り可能なスペシフィケーションのための解釈情報を含むマシン読取り可能なデータ構造とともに確立する。インタフェースのマシン読取り可能なスペシフィケーションは、入力ドキュメントの定義と出力ドキュメントの定義とを含んでおり、これらは、前記のノードがインタフェースとして動作するトランザクションプロセッサによって受入れられ、作られる。入力ドキュメントの定義及び出力ドキュメントの定義は、例えば、標準ＸＭＬ系ドキュメントに従った、記憶ユニットのセットの記述及び記憶ユニットのセットのためのロジック構造をそれぞれ包含する。本発明の種々の観点に従った解釈情報を含むマシン読取り可能なデータ構造は、入力及び出力ドキュメントの定義におけるロジック構造のためのデータタイプのスペシフィケーション（例えば、ストリングやアレイ等）、ロジック構造のためのコンテントモデル（例えば、可能な値のリスト）、及び／又は、オーダのリストの各エントリへの特定のロジック構造のための記憶ユニットの予め定義したセットをマップするデータ構造を含み、ロジック構造のセマンティック定義（例えば、ネームを生成するためのマッピングコード）を提供する。
【００１１】
本発明の他の観点によれば、インタフェースは、ネットワークの少なくとも１つのノードによってアクセスできるメモリ内のリポジトリ（これはロジック構造のライブラリ及びロジック構造の解釈情報を記憶する）を含む。このリポジトリは入力及び出力ドキュメントの定義のライブラリとインタフェースのスペシフィケーションのライブラリとネットワークの参加者のインタフェースノードのスペシフィケーションのライブラリを含むように拡張され得る。
【００１２】
従って、本発明のトランザクションフレームワークの参加者は、トランザクションに包含される複数のノード実行プロセスを含む、ネットワークの複数のノード間でトランザクションを実行する。本発明の方法は、トランザクションのためのインタフェースのマシン読取り可能なスペシフィケーションを記憶することを含み、スペシフィケーションは、入力ドキュメントの定義と出力ドキュメントの定義とを含む。入力及び出力ドキュメントの定義は、それぞれ、記憶ユニットのセットの記述と記憶ユニットのセットロジック構造とを包含する。好ましいシステムでは、それらの定義は、標準のＸＭＬドキュメントタイプの定義、すなわちＤＴＤに従うやり方で、セマンティックマッピングとコンテントモデリングといくつかのエレメントデータタイピングとによって拡張されて、表現される。トランザクションの参加者は、通信ネットワークを通してドキュメントを含むデータを受取る。参加者は、トランザクションのために記憶されたスペシフィケーションに従ってそのドキュメントを解析して、そのトランザクションのための入力ドキュメントを識別する。ドキュメントの解析後、入力ドキュメントの少なくとも一部は、出力を提供するトランザクションプロセスへマシン読取り可能なフォーマットで提供される。出力ドキュメントは、記憶されたスペシフィケーションの出力ドキュメントの定義に基づいて、トランザクションプロセスの出力を構成するように形成される。出力ドキュメントは、通信ネットワーク上に送られて、代表的には、入力ドキュメントのソースに戻され、あるいは、トランザクションの特定のタイプのニーズに合わせた他のところに送られる。
【００１３】
したがって、ビジネスインターフェースの定義は、例えばＸＭＬによって特定されるドキュメント及び特別のノードにおけるトランザクション処理サービスのフロントエンド上で実行するプログラム間のギャップをブリッジする。これらのフロントエンドは、例えば、ＪＡＶＡ仮想マシンによって、或いはネットワークの両端のシステムの相互接続に対して与える他の共通のアーキテクチャによって実現される。ビジネスインターフェースの定義は、トランザクションプロトコルがビジネスインターフェースの定義書を用いてプログラムされる技術を提供する。このトランザクションのプロトコルに対するプログラムはドキュメント形式の詳細な公式仕様書によって与えられる。
【００１４】
トランザクションのインターフェースの機械読み取り仕様書はネットワークにおける他のプラットフォームにアクセス可能にされる。参加者のプラットフォームは、補完的なノードにおいて特定されるトランザクションインターフェースによる入力ドキュメント及び出力ドキュメントを設計する資源を含む。したがって、参加者のノードは、補完的インターフェースのための入力ドキュメントの定義、及び補完的インターフェースのための出力ドキュメントの定義にアクセスする資源を含む。アクセスしている参加者ノードのためにストアされた仕様書は、その仕様書にストアされたインターフェースの入力ドキュメントの定義にある補完的なインターフェースの出力ドキュメントの定義の少なくとも一部を含むことによって確立される。
【００１５】
本発明の他の特徴によるインターフェースのストアされた仕様書を確立するプロセスは、リポジトリから機械読み取り可能な仕様書のエレメントにアクセスすることを含む。このリポジトリは論理構造、コンテントモデル、および論理構造のための概略マップのライブラリ、およびインターフェース記述書を構築するために用いられる論理構造を有するドキュメントの定義をストアする。ネットワークにおいてアクセス可能なリポジトリは、容易に共有されることができるインターフェースの記述の構築を容易にする。特別なプロセスに対して形成された入力ドキュメント及び補完的なプロセスによって、リターンとして期待される出力ドキュメント間のあらゆる相違は、ネットワーク上の通信及び特別な情報を表現する共通の論理構造に同意することによって容易に交渉される。
【００１６】
本発明の一つの特徴によるトランザクションのインターフェースの機械読み取り可能な仕様書は、ネットワークのメンバー間で共有されるインターフェースドキュメントの定義に従うドキュメントを含む。インターフェースドキュメントの定義は特別なトランザクションの識別子、及び定義の少なくとも一つ及び特別なトランザクション用の入出力ドキュメントの定義に対するレファレンスをストアするための論理構造を有する。すなわち、特別なサービスに対するインターフェース記述書は入出力ドキュメントの定義を実際に含む。代わりに、それはこのような定義のリポジトリにおける位置、またはネットワークのどこかへのポインタを含むことができる。
【００１７】
本発明の他の代替方法によると、機械読み取り可能な仕様書は、インターフェースの識別子をストアするため、および仕様書の少なくとも１つとインターフェースによってサポートされる１以上のトランザクションの組の仕様書に対するレファレンスをストアするための論理構造を含むインタフェースドキュメントの定義に従うビジネスインターフェース定義ＢＩＤドキュメントを含む。各々のサポートされたトランザクションに対して、ドキュメントは定義の少なくとも１つ及び特別なトランザクションに対する入出力ドキュメントの定義に対するレファレンスを含む。
【００１８】
本発明の他の特徴によると、入出力ドキュメントの定義書に定義された記憶ユニットは文字データをエンコードするテキスト文字を含む分析されたデータ、および入出力ドキュメントの論理構造による記憶ユニットの組を識別するマークアップデータを有する。本発明の他の特徴によると、記憶ユニットの組の少なくとも１つは、自然言語を与える複数のテキスト文字をエンコードする。これは、これらのドキュメントの人間の読者や開発者によって入出力ドキュメントの定義の使用を容易にする。
【００１９】
本発明の他の特徴によると、入出力ドキュメントの仕様書は論理構造によって識別される記憶ユニットの組の少なくとも１つに対する翻訳情報を含む。１つの例における翻訳情報は、分析された文字の組に対する定義書をエンコードする。他の例では、翻訳情報はコンテントモデル仕様書のために提供する。例えば、カタログにおける記述を作るためにマップされたコードの多くのリストを載せるように特定の論理構造に要求する。あるシステムでは、ドキュメントの論理構造における記憶ユニットは特別な実効の必要性を満足するように分析されていないデータのセットを含む。
【００２０】
本発明の他の特徴によると、特別なプラットフォームにおけるトランザクションプロセスは、複数の変形トランザクション処理アーキテクチャの１つであるトランザクション処理アーキテクチャを有する。したがって、参加者ノードは、入力ドキョメントの少なくとも一部を、情報を利用するトランザクションの変形トランザクション処理アーキテクチャに読取り可能なフォーマットに変換するための資源を含む。ドキュメント定義のエレメントは、トランザクションプロセスの変形トランザクション処理アーキテクチャによる変数及び方法を含む。トランザクションプロセスのフロントエンドとして働くＪＡＶＡ仮想マシンを有する参加者に対して、ドキュメントにおける特別なフィールドは、データを含むＪＡＶＡオブジェクトに翻訳されるばかりでなく、ＪＡＶＡオブジェクトに関連した機能を得て、設定する。本発明によってサポートすることができる他のトランザクション処理アーキテクチャは、Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ  ＣＯＲＢＡ，Ｃｏｍｐｏｎｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ  ＣＯＭ，Ｏｎ−ｌｉｎｅ  Ｔｒａｎｓａｃｔｉｏｎ  Ｐｒｏｃｅｓｓｉｎｇ  ＯＬＴＲ，およびＥｌｅｃｔｒｏｎｉｃ  Ｄａｔａ  Ｉｎｔｅｒｃｈａｎｇｅ  ＥＤＩの意味におけるインターフェース記述言語に従う処理を含む。
【００２１】
本発明の他の特徴によると、複数のトランザクションにおいて使用されるドキュメント形式をストアするリポジトリが設けられる。特別なトランザクションのための機械読み取り可能な仕様書は、リポジトリにおけるドキュメント形式を参照することによって入出力ドキュメントの少なくとも１つを定義する。他の特徴によると、リポジトリに含まれるドキュメント形式は、ネットワークにおける参加者を識別するためのドキュメント形式を有する。このようなドキュメント形式は、参加者を識別し、その参加者によって支持されるサービスを特定し、且つこれらのサービスの各々に対する入出力ドキュメントを特定するため構造を提供する。
【００２２】
上述の方法に加えて、本発明は、ネットワークインターフェース、上述したように、トランザクションのためのインターフェースの機械読み取り可能な仕様書を含むデータと命令のプログラムをストアするためのメモリ、およびメモリとネットワークインターフェースに接続されたデータプロセッサを含むノード間のトランザクションを管理する装置を提供する。本装置にストアされた命令のプログラムは、トランザクションにおける参加者のための、上述したプロセスを実行するロジックを含む。
【００２３】
本発明は、更に、トランザクション処理アーキテクチャによるトランザクション処理を実行するネットワークとデータ処理資源を含むシステム上で実行されるトランザクションのための参加者インタフェースを確立するための装置を提供する。本装置は、システムによって実効可能であり、特別のトランザクションにおける参加者のための参加者インターフェースの定義を構築するツールを提供するシステムによって、アクセス可能な媒体にストアされた命令のプログラムを含む。参加者インターフェースの定義は、入力ドキュメントの定義及び出力ドキュメント定義を含む。入出力ドキュメント定義は、記憶ユニットのセットのための論理構造における記憶ユニットのセットのそれぞれの機械読み取り可能な記述書を有し、そしてそれは、本発明の１つの特徴として、ＸＭＬドキュメント形式の定義に従うことができる。
【００２４】
また、本発明のこの形態による参加者インタフェースを設定する装置は、データ処理システムによってアクセス可能な媒体に記憶された命令のプログラムを含み、かつを入力されたドキュメントを対応するデータ構造に変換するためにシステムによって実行可能な命令をコンパイルすべく、かつトランザクション処理の出力を出力ドキュメントの記憶部及びロジック構造のセットに変換するためにシステムによって実行可能な命令をコンパイルすべくトランザクション処理アーキテクチャに順応する入力及び出力ドキュメントの論理構造及び記憶部のセットに対応しているデータ構造をコンパイルするために入力及び出力ドキュメントの定義に応答する。
【００２５】
好ましいシステムにおける参加者インタフェースの定義を構築するためのツールは、インタフェース記述を構築するために用いられる論理構造及び論理構造に対する解釈情報のライブラリを記憶するリポジトリからの及び／又は相補的ノードからの定義の構成要素をアクセスするためにシステムによって実行可能な命令を含む。本発明の種々の形態によれば、リポジトリは、論理構造のライブラリだけでなく論理構造、及び参加者インタフェースを特定するためのフォーマットを備えているドキュメントの定義も含む。本発明のこの形態によれば、ツールは、参加者ノードの記述に関連して上述した技術によるビジネス・インタフェースの仕様を構築するために設けられる。本発明のこの形態によるインタフェースを構築するためのツール及びインタフェースをトランザクション処理アーキテクチャとの通信のために必要なリソースにコンパイルするためのツールは、ｌ好ましいシステムにおける参加者ノードで実施され、かつ入力及び出力ドキュメントを定義するインタフェース記述に基づいてネットワークの使用が成長するときにインタフェース記述の開発及び最適化に利用される。
【００２６】
従って、本発明の別の形態は、参加者インタフェースの定義を構築するためのツール及びを上述した機能を実行するコンパイラを含む、メモリ及びにメモリに記憶された命令を実行するデータ・プロセッサを含む装置を提供する。
【００２７】
本発明の更に別の形態によれば、参加者インタフェース記述の使用は、マーケット・メーカ・ノードの動作を可能にする。そのようなノードにおいて、インタフェースによって支援されたトランザクション、及びそのようなトランザクションの各々の入力及び出力ドキュメントを識別する複数の参加者インタフェースの機械可読仕様を記憶することを具備する、トランザクションを管理する方法が提供される。上述したように、入力及び出力ドキュメントは、ＸＭＬ標準によるような、記憶部及び記憶部に対する論理構造のセットの各々の記述を備えている。更に、トランザクションの定義及び参加者インタフェースの定義は、全て、ＸＭＬ又は他の標準化ドキュメント表現言語に順応する技術により特定されたドキュメントを備えている。そのようなマーケット・メーカ・ノードでは、ドキュメントを備えているデータは、通信ネットワークで受信される。ドキュメントは、識別された入力ドキュメントを受入れる一つ以上のトランザクションにおいて入力ドキュメントを識別するために仕様書によりパーズされる。入力ドキュメントの少なくとも一部は、一つ以上の識別されたトランザクションに関連付けられるトランザクション処理に対して機械可読フォーマットで供給される。トランザクション処理に入力ドキュメントの少なくとも一部を供給する方法は、マーケット・メーカ・ノードにおける処理アーキテクチャによりルーティング処理を実行することを含む。本発明の一つの形態におけるルーティング処理は、特定の処理アーキテクチャにより実行され、かつ入力ドキュメントの少なくとも一部は、ルーティング処理の処理アーキテクチャのフォーマットに変換される。好ましい形態による変換は、ルーティング処理の処理アーキテクチャによる変数及び方法を含むプログラミング・オブジェクトを生成することを含む。
【００２８】
本発明の別の形態によれば、マーケット・メーカ・ノードは、また、リポジトリ構造を支持する。そこで、処理は、マーケット・メーカ・ノードに記憶されるリポジトリへのネットワークの参加者によるアクセスを許容するためにマーケット・メーカ・ノードに含まれる。上述したように、リポジトリは、トランザクション・インタフェース・ドキュメントを構築するために論理構造の定義、解釈情報、及び参加者ノード用ドキュメント定義を含みかつ参加者を識別するビジネス・インタフェース定義のインスタンス、及び各々の参加者によって実行されるトランザクションを含む。
【００２９】
ルーティング処理は、種々の代替により、ドキュメントが送られる処理の可変処理アーキテクチャへの入力ドキュメントの変換、遠隔処理ノードにネットワークでその最初のドキュメント・フォーマットで入力ドキュメントを送ること（ルーティング）、又はそのような処理の組合せを含む。代替において、ルーティング処理は、また、一つの入力ドキュメント定義により定義された入力ドキュメントを、入力ドキュメントを待機するために登録されている処理に対する異なるドキュメント仕様により定義された異なるドキュメントに変換するための技術を含む。
【００３０】
また、マーケット・メーカ・ノードは、ネットワーク・インタフェース、参加者インタフェースの仕様を含んでいる命令のプログラム及びデータを記憶しているメモリ、及びデータ・プロセッサを含む装置として本発明により提供される。ロジックは、上述したようなマーケット・メーカ処理を実行するために命令のプログラム等の形でデータ・プロセッサにより供給される。
【００３１】
従って、本発明は、入力及び出力ドキュメンテーションの仕様の共有化に基づぐ電子コマースに対する基礎を提供する。ドキュメントは、ＡＰＩｓをプログラム作成するよりも実施することがより簡単なビジネス・サービスをアクセスするための直感的かつ柔軟性のある方法を提供する。会社が既に大筋で同意しているならば、交換されるドキュメントによりそのような会社を相互接続することは、いつも異なるビジネス・システム・インタフェースよりも、更に容易である。加えて、そのようなドキュメントは、好ましい実施例ではヒューマン・リーダブル（人間が読取り可能な）・フォーマットで特定される。本発明によれば、ビジネス・インタフェースは、人間並びにコンピュータによって容易に解釈可能であるＸＭＬドキュメントのようなドキュメントで特定される。
【００３２】
本発明のドキュメント・ベース・トランザクション・アーキテクチャの利用は、ドキュメントのあらゆるソースと基本的には同じ方法で動作するパーズの使用を含み、ネットワークの各参加者から情報を抽出しかつ統合するためのカスタム・プログラムに対する多くの必要性を取り除く。そこで、会計、購入、製造、配送及び他の機能からの事業情報を統合することは、まず、各ソースを本発明によるアーキテクチャを有するドキュメントに変換し、次いでパーズされたデータ・ストリームを処理することによって達成することができる。マーケットに参加するシステムの各ノードは、その内部システムのフォーマット、並びにトランザクションにより交換のために特定されるドキュメントのフォーマットについて知ることが必要なだけである。そこで、電子コマース・ネットワークに参加することを希望する全ての他のノードのネイティブ（固有）・フォーマットを生成できることの必要性がない。
【００３３】
完全なビジネス統合のために、本発明は、ＸＭＬ構成要素、属性又はメタデータのような標準化論理構造のリポジトリを提供し、特定のコマース・コミュニティに対するセマンティック（意味）言語、異なるメタデータ記述間をマップするための手段、及びドキュメントを処理しかつ適切なアプリケーション及びサービスを呼出すためのサーバを設定する。本発明によるネットワークの基本的構築ブロックは、潜在的なトレーディング・ビジネス・パートナーにどのようなオンライン・サービスを会社が提供しかつサービスを呼出すためにどのドキュメントを用いるかを通告するインタフェース定義；及びトレーディング・コミュニティを生成するために内部及び外部ビジネス・サービスのセットを互いに結合するためにブリッジを供給するサーバを含む。サーバは、入力ドキュメントをパーズしかつ適切なサービスを呼出すために動作する。また、本発明によるサーバは、各々のホスト・システムのフォーマットへの及びそれらのフォーマットからの、受信しかつ送信するドキュメントのフォーマットからの変換タスクを取り扱う。そこで、トレーディング・パートナーは、交換したビジネス・ドキュメントの構造、内容及びシーケンシングだけに同意することが必要であり、アプリケーション・プログラマー・インタフェースの詳細に同意する必要はない。ドキュメントが処理される方法及びドキュメントの受信の結果としてもたらされるアクションは、まったくサービスを提供するビジネスによる。これは、システム・レベルからビジネス・レベルに統合を向上させる。それは、その内部技術実施、組織又は処理における変化にも係わらず、ビジネスにそのパートナーに対する明瞭かつ安定したインタフェースを提示させることができる。
【００３４】
ビジネス・インタフェース定義を構築しかつそのような記述によりサーバにコマースを管理させることができる全ての処理は、会社、サービス及び製品のようなビジネス記述プリミティブ、カタログ、購入注文、及びインボイスのようなビジネス・フォーム、並びに時間及び日付、場所及び商品の分類を含む、標準測定を含んでいる一般的なビジネス概念に対する情報モデルの共通のビジネス・ライブラリ、又はリポジトリによって容易に行われる。
【００３５】
本発明の他の形態は、以下に説明する図面、詳細な説明、及び特許請求の範囲を考慮することにより理解することができるであろう。
【００３６】
（詳細な説明）
図面との関連で本発明について詳細に説明する。図１は、ビジネスインタフェース定義の使用に基づくマーケットメーカー及びマーケット参加者のネットワーク、該インタフェースの既述にしたがって特定された入力及び出力ドキュメントのやり取りのサポートを説明するものである。該ネットワークは、インターネット１９などの通信ネットワーク、あるいはその他のテレコミュニケーションまたはデータコミュニケーションネットワークを介して相互に接続されている、複数のノード１１〜１８を含む。ノード１１〜１９の各々は、ポータブルコンピュータ、デスクトップパーソナルコンピュータ、ワークステーション、システムのネットワーク、あるいは他のデータプロセシングリソースなどのコンピュータで構成されている。該ノードは、ビジネスインタフェース定義を記憶しておくためのメモリ、ネットワーク中の他のノードとの商取引トランザクションをサポートするトランザクションプロセスを実行するためのプロセッサ、及びそのようなサービスをサポートするために該プロセッサにより実行されるコンピュータプログラムを含んでいる。さらに、各ノードは、インターネット１９あるいは他のコミュニケーションネットワークを渡るコミュニケーションを提供するための、ネットワークインタフェースを含む。
【００３７】
図１の環境においては、ノード１１、１２、１３、１４、１６及び１８は、指定されたマーケット参加者である。マーケット参加者は、本発明にしたがって確立された商取引トランザクションにしたがって取引される商品またはサービスの需要者または供給者についてのリソースを含んでいる。
この例では、ノード１５及び１７は、マーケットメーカーノードである。マーケットメーカーノードは、ＢＩＤレジストリと呼ばれるビジネスインタフェース定義を登録するためのリソースを含んでいる。参加者は、ドキュメントをマーケットメーカーに送ることが可能であり、そこで該ドキュメントは識別され、そのようなドキュメントを入力として受け取るように登録されている適切な参加者に発送される。マーケットメーカーはまた、ビジネスインタフェース定義の構築において使用するための共通ビジネスライブラリを構成する、標準フォームのリポジトリを維持することにより、商取引ネットワークを促進する。
【００３８】
この例では、マーケット参加者１８は、インターネット１９を介することなく、マーケットメーカー１７に直接接続されている。このマーケットメーカーへの直接接続は、インターネット１９などの公衆ネットワーク、及び、ローカルエリアネットワークのような私設接続あるいはノード１７と１８との間に示されているようなポイント−トゥ−ポイント接続を実際の導入することにより、商取引トランザクションをサポートするネットワークの形態が極めて多様なものになり得る、ということを示すものである。実際のコミュニケーションネットワークはかなり多様であり、本発明による商取引トランザクションネットワークを確立するために使用するのに好適である。
【００３９】
図２は、本発明によるネットワークにおけるマーケット参加者のために確立されたビジネスインタフェース定義（ＢＩＤ）における、繰り込まれた構造の発見的なダイアグラムである。図２に示されているビジネスインタフェース定義は、ＸＭＬドキュメントタイプ定義ＤＴＤなどのドキュメント構造の形式定義にしたがって配列された記憶ユニット及び論理構造からなる、データ構造である。図２の構造は、バーティを識別するための第１の論理構造２００を含んでいる。論理構造２００と関連付けられているのは、名前を搬送するための繰り込まれた論理構造２０１、物理的アドレス２０２、ネットワークのアドレスあるいは位置２０３、及び一組のサービスのためのトランザクション２０４である。サービスセット中の各トランザクションについて、トランザクションＢＩＤ２０５、トランザクションＢＩＤ２０６、及びトランザクションＢＩＤ２０７を含む、インタフェース定義が提供されている。トランザクションＢＩＤ２０５などの各トランザクションＢＩＤの中には、名前２０８、サービスが実行されるネットワーク上の位置２０９、サービスにより実行される操作２１０、及び一組のタグにより示される入力ドキュメント２１１を含むための論理構造が提供されている。また、サービスＢＩＤ２０５は、一組のタグにより示される出力ドキュメント２１２を含んでいる。一組の入力ドキュメント２１１は、入力ドキュメントビジネスインタフェース定義２１３、２１４、及び２１５を含む、サービスが応答するよう指示された、各入力ドキュメントについてのビジネスインタフェース定義を含んでいる。入力ドキュメントについてのビジネスインタフェース定義は、名前２１６、ドキュメントの記述を見出し得るネットワーク上の位置２１７、及びフィールドにより示された通りドキュメントにおいて搬送されるべきモジュール２１８を含んでいる。同様に、出力ドキュメントセット２１２は、出力ドキュメントＢＩＤ２１９、出力ドキュメントＢＩＤ２２０、及び出力ドキュメントＢＩＤ２２１を含む、出力ドキュメントについてのインタフェース定義を含んでいる。各出力ドキュメントＢＩＤについて、名前２２２、ネットワーク上または他の場所の位置２２３、及びドキュメントのモジュール２２４が特定されている。図２に示されている参加者についてのビジネスインタフェース定義は、各サービスの入力及び出力ドキュメントについて利用されるべき論理構造の実際の定義、あるいは、定義を見出し得る位置へのポインタまたは他のリファレンスを含んでいる。
【００４０】
好ましいシステムにおいては、図２のドキュメントは、ＸＭＬドキュメントタイプ定義ＤＴＤにおいて特定されるが、他のドキュメント定義アーキテクチャを使用することもでき、またドキュメントの依頼の翻訳に使用される論理構造についての翻訳情報を含んでいる。また、トランザクションＢＩＤ、入力ドキュメントＢＩＤ及び出力ドキュメントＢＩＤの各々は、ＸＭＬドキュメントタイプ定義にしたがって特定される。ＸＭＬタイプドキュメントは、マークアップデータ及びキャラクタデータを含む解析されたデータに基づくシステムの例である。マークアップデータは、ドキュメント内の論理構造を識別し、キャラクタデータの組は、論理構造の内容を識別する。さらに、解析されないデータは、様々な目的でドキュメント中を搬送され得る。例えば、ＷＷＷ．Ｗ３．ＯＲＧ／ＴＲ／１９９８／ＲＥＣ−ＸＭＬ−１９９８０２１０においてＷＣ３  ＸＭＬワーキンググループにより発行されたＥｘｔｅｎｓｉｂｌｅ  Ｍａｒｋ−ｕｐ  Ｌａｎｇｕａｇｅ  ＸＭＬ  １．０  ＲＥＣ−ＸＭＬ−１９９８０２１０の仕様書を参照のこと。
【００４１】
かくして、例示したシステムにおいては、ネットワーク中の参加者ノードは、ビジネスシステム及びサービスを、ビジネスが受容し発生するＸＭＬコード化されたドキュメントと相互接続することにより、仮想企業を設立する。例えば、特定のサービスのビジネスインタフェース定義は、カタログ記入に対する要求のＢＩＤに合致するドキュメントを受け取った場合には、カタログ記入のＢＴＤに合致するドキュメントを返送することを確立する。また、購入注文のＢＩＤに合致するドキュメントを受け取り、それが受け取った端末にとって受け入れ可能なものである場合には、請求書のＢＩＤに合致するドキュメントを返送する。ネットワーク中のノードは、ネットワーク中の任意の所定のシステムの様々なトランザクションプロセシングアーキテクチャにしたがって確立されたローカルビジネスシステムにＸＭＬドキュメントが入る前に、ＸＭＬドキュメントを加工する。かくして、システムは、ＭＩＭＥ−コード化されたＸＭＬドキュメントの組などの関連するドキュメントの組を解読し、これを解析して“マークアップメッセージ”のストリームを創作する。このメッセージは、例えば下記のようなイベントリスナーモデルを使用して、適切な用途及びサービスに発送される。
【００４２】
ビジネスサービス間で交換されるドキュメントは、より複雑なドキュメント定義が生成されうるビルディングブロックのリポジトリから生成されるＸＭＬ言語（共通のビジネス言語）を使用してエンコードされる。リポジトリは、会社、サービス、製品のようなビジネスディスクリプションプリミティブ、カタログ、購入注文、インボイスのようなビジネスフォーム、時間、日、位置のような標準の測定値、分類コード、および、ＸＭＬドキュメントの論理構造の解釈情報を与えるようなものを含む、ビジネスドメインに共通のファンクションおよび情報に焦点をあてた解釈情報のモジュールを記憶する。
【００４３】
ビジネスインターフェイス定義は、本発明に従うドキュメントを交換するインターフェイスを設計するために使用されるスキーマとしての役割を果たす更に高レベルのドキュメントである。そうして、ビジネスインターフェイスは、ＸＭＬに従って記述されるドキュメントと、特定のノードにおいてトランザクション処理サービスのフロントエンドで実行されるプログラムとの間のギャップを埋める。このようなフロントエンドはＪＡＶＡ仮想マシーン、またはネットワーク中のシステムの内部接続を規定する他の共通アーキテクチャによって実施される。そうして、ビジネスインターフェイス定義は、ビジネスインターフェイス定義ドキュメントを使用してトランザクションプロトコルをプログラムするのに用いられる技術を提供する。トランザクションのプロトコルのためのプログラムは、ドキュメントタイプの詳細な公式の仕様によって規定されている。
【００４４】
ＸＭＬフォーマットに従うマーケット関係者のドキュメントに基づく一例のビジネスインターフェイス定義ＢＩＤは、以下に与えられる。マーケット関係者ＤＴＤは、連絡先および住所情報をサービスおよび財政情報のディスクリプションと関連付けて、マーケット関係者に関するビジネス情報を分類する。このビジネス情報は、名前、コード、住所、ビジネス組織を示すための専用分類法、ビジネスのタームへのポインタから成る。加えて、マーケット関係者ＤＴＤによって識別されるサービスは、その関係者が応答し、生成する入力及び出力ドキュメントを記載する。そうして、説明に役立つ注釈付きのＸＭＬで記述されるマーケット関係者ＤＴＤ、サービスＤＴＤ、トランザクションドキュメントＤＴＤのために一例の共通ビジネス言語を使用するスキーマを規定するドキュメントは、以下に続く。
【００４５】
0004712191.tif 000002
0004712191.tif 000003
0004712191.tif 000004
0004712191.tif 000005
0004712191.tif 000006
0004712191.tif 000007
0004712191.tif 000008
0004712191.tif 000009
0004712191.tif 000010
0004712191.tif 000011
サービスＤＴＤスキーマは、共通ビジネス言語リポジトリのサービスタイプエレメントで以下のように拡張されうる。
0004712191.tif 000012
0004712191.tif 000013
上記のサービスタイプエレメントは、ビジネスインターフェイス定義によって保有される解釈情報、この例では、有効なサービスタイプのいずれか１つの識別を可能にするコンテントフォームを例示する。別の解釈情報は、例えばコンテントフォーム「ｕｒｌ」を含み、データタイプ「ｓｔｒｉｎｇ」で表されるエレメント＜Ｈ３＞Ｉｎｔｅｒｎｅｔ  Ａｄｄｒｅｓｓ＜／Ｈ３＞のような、データタイピングを含む。さらに別の解釈情報は、例えばファイル「ＣＯＵＮＴＲＹ．ＵＳ．ＳＵＢＥＮＴＩＴＹ」中の国に対するコードマッピングを含むエレメント＜Ｈ３＞Ｓｔａｔｅ＜／Ｈ３＞のような、リストのエレメントへのコードのマッピングを含む。
マーケット関係者ＤＴＤによって照会されるサービスディスクリプションは、サービスのコンペティションについてサービスが認めて生成するドキュメントを規定する。ベーシックサービスディスクリプションは、ＸＭＬドキュメントｔｒａｎｓａｃｔ．ｄｔｄとして以下に記載される。
ｔｒａｎｓａｃｔ．ｄｔｄは、インボイスのようなトランザクションディスクリプション、または値の交換のディスクリプションをモデル化する。このドキュメントタイプは、多くの用途を支援し、従って、トランザクションディスクリプションエレメントは、ユーザーがインボイス、業績、売りの申し出、取引価格の要望等を区別するのを可能にする属性を有する。交換は２人以上の関係者間で行われうるが、申し出人と相手の２人のみを登場させる。その各人は、上記に概説したマーケット関係者ＤＴＤに合致するドキュメントへのポインタによって表される。相手のポインタが、売りの申し出を受け入れるのは任意である。交換ディスクリプションは以下に挙げるｔｒａｎｐｒｉｍ．ｍｏｄに記述され、価格および小計を含む。交換ディスクリプションに続いて、全体としてトランザクションに適用される料金が備えられ、全体の料金が与えられなければならない。従って、この例のトランザクションディスクリプションスキーマドキュメントｔｒａｎｓａｃｔ．ｄｔｄは以下に表される。
0004712191.tif 000014
代表マーケット関係者およびサービスＤＴＤは、上記の定義に従って生成され、以下の通りである。
マーケット関係者ＤＴＤ
0004712191.tif 000015
0004712191.tif 000016
サービスＤＴＤ
0004712191.tif 000017
ｔｒａｎｓａｃｔ．ｄｔｄによって生成されるドキュメントの一例が続く。
0004712191.tif 000018
0004712191.tif 000019
0004712191.tif 000020
【００４６】
したがって、本発明は、マーケット参加者がそれ自身を識別し、入力ドキュメントのタイプおよび取引を行おうとしている出力ドキュメントのタイプを識別できるようにする技術を提供する。この種のドキュメントに担持された内容がこの取引での他のパーティーまたはローカルパーティーによって処理される特定の仕方は、ビジネス関係の確立には関係しないし、取引を行うことにも関係しない。
【００４７】
図３は、本発明によるネットワークにおける参加者ノードの概略図である。図３に例示されたノードは、ポート３０１にて通信ネットワークに結合されるネットワークインターフェイス３００を含む。このネットワークインターフェイスは、ドキュメントパーサー３０１に結合される。パーサー３０１は、入力ドキュメントからのロジカルストラクチャーをトランスレータモジュール３０２へ供給し、トランスレータモジュール３０２は、入力ドキュメントをホスト取引システムによって使用できるようなフォームへと変換し、また、その逆に、ホストプロセッサの出力を送り先への送信のためにビジネスインターフェイス定義での出力ドキュメントフォームへと変換するためのものである。パーサー３０１およびトランスレータ３０２は、参加者モジュール３０３に記憶されたビジネスインターフェイス定義に応答する。
【００４８】
トランスレータ３０２からの出力データストラクチャーは、パーサー３０１によってシグナリングされるエベントと共に取引プロセスフロントエンド３０４へ供給される。１つの実施例におけるフロントエンド３０４は、ネットワークにおける種々なノードの間で通信するに適したＪＡＶＡバーチャルマシンまたはその他の類似のインターフェイスからなる。取引プロセスフロントエンド３０４は、パーサー３０１およびトランスレータ３０２によって指示されたエベントに応答して、入力データを、その参加者が結合されたエンタープライズシステムおよびネットワークにおける適当なファンクションへルーティングする。こうして、図３の例における取引プロセスフロントエンド３０４は、コマーシャルファンクション３０５、データベースファンクション３０６、アカウンティングおよびビリング３０７の如きその他のエンタープライズファンクションに結合され、また、パーサーによって指示されたエベントに応答するように設計された特定のエベントリスナーおよびプロセッサ３０８に結合される。
【００４９】
パーサー３０１は、ビジネスインターフェイス定義にしたがって特定される前述の例におけるような購入注文またはその他のドキュメントを受け取り、ＪＡＶＡバーチャルマシンのためのＪＡＶＡエベントのセットの如きローカル取引処理アーキテクチャによって認識されるエベントのセットを生成する。
【００５０】
本発明のパーサーは、受信ドキュメントに基づくエベントをリスニングするプログラムから切り離される。受信ドキュメントにおける種々なマークアップピースまたは特定の仕様を満たす完全ドキュメントは、処理を開始させるリスニングファンクションのための命令として働く。こうして、リスニングプログラムは、ドキュメント情報に関連したビジネスロジックを実施する。例えば、アドレスエレメントに関連したプログラムは、データベースをチェックすることによってポスタルコードを確証するコードでありうる。これらのリスナーは、ドキュメントルーターで登録することによりエベントに加入する。ドキュメントルーターは、適切なエベントを、それらに興味のあるすべての加入者へと差し向けるものである。
【００５１】
例えば、前述したように特定された購入注文は、ドキュメントまたはその内容を注文エントリプログラムへ接続するであろうパーサーによって発生されるエベントをリスニングするプログラムによって監視されうる。その購入注文内のプロダクト記述の受領によりあるプログラムを使ってインベントリをチェックする。購入注文内のアドレス情報の受領により、あるプログラムを使ってデリバリのためのサービスの利用性をチェックする。ドキュメントにおけるバイヤー情報フィールドは、種々なプロセスを使って、クレジット価値について注文ヒストリをチェックし、または、プロモーションまたは消費者のアイデンティティを知ることに基づくような類似の処理をオファーすることができる。
【００５２】
コンプレックスリスナーは、プリミチブなリスナーのコンフィギュレーションとして生成されうる。例えば、ある購入注文リスナーは、前述したリストリスナーを含み、そのリストリスナーを使いうるし、また、リストメンバーは、それら自身に関して使われうる。リスナーがランするようなアプリケーションは、ネーチブＸＭＬプロセスまたはネーチブＪＡＶＡプロセスではないようであることに注意すべきである。これらの場合において、オブジェクトは、受信トランスアプリケーションによって必要とされるフォーマットへ変換される。そのアプリケーションが処理を完了するとき、その出力は、ネットワークにおける他のノードへの通信のためにＸＭＬフォーマットへと変換し戻される。
【００５３】
前述したようなマーケット参加者ドキュメントタイプ記述および取引ドキュメントタイプ記述としては、ドキュメントにおけるロジックエレメントのためのスキマチックマッピングがあり、また、自然言語に基づくマークアップ言語がある。自然言語マークアップおよびＸＭＬのその他の自然言語属性は、ビジネスインターフェイス定義、サービス記述および入力および出力ドキュメントの記述の仕様のためのＸＭＬタイプマークアップ言語の使用を容易とする。
【００５４】
ビジネスインターフェイス定義を記憶することに加えて、参加者モジュール３０３は、入力ドキュメントにおけるロジカルストラクチャーに対応する取引プロセスフロントエンド３０４によって使用されるオブジェクトまたはその他のデータストラクチャーを編集したり、トランスレータ３０２を編集したりするのに使用されるコンパイラーを含む。こうして、ビジネスインターフェイス定義が参加者の関係する取引の変化につれて参加者によって変更されまたは更新されるとき、トランスレータ３０２およびパーサー３０１は、自動的にアップデートに保たれる。
【００５５】
好ましいシステムにおいては、ＪＡＶＡエベントのセットは、ＳＧＭＬのグローブモデル、主として、各エレメントについてプロパティセットによって拡張された標準のエレメントストラクチャーインフォーメーションセットに対応するコンパイラによって生成される（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｓｔａｎｄａｒｄ  ＩＳＯ／ＩＥＣ  １０１７９：１９９６（Ｅ），Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ−−Ｐｒｏｃｅｓｓｉｎｇ  Ｌａｎｇｕａｇｅ−−Ｄｏｃｕｍｅｎｔ  Ｓｔｙｌｅ  Ｓｅｍａｎｔｉｃ  ａｎｄ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｌａｎｇｕａｇｅ（ＤＳＳＳＬ））。ＸＭＬドキュメントをプロセスのためエベントのセットへと戻すのは、パーサー出力がインターナルデータストラクチャーとして維持されるような構文解析の通常モデルとは異なる。各ノードの取引処理フロントエンドによって使用するのに適したＪＡＶＡエベントまたはその他のプログラミングストラクチャーへＸＭＬドキュメントのエレメントを変換することにより、トレードされるドキュメントを利用するノードでのリッチファンクショナリティが可能とされる。
【００５６】
こうして、取引プロセスフロントエンド３０４は、システムにおける他のリスニングプログラムの知識なしにまたはインパクトなしに新しいリスナープログラムを加えることができるようにするパブリッシュおよびサブスクライブアーキテクチャーにて作動することができる。図３における各リスナー３０５、３０６、３０７、３０８は、フロントエンド３０４がエベントを指揮するキューを維持する。これにより、多数のリスナーがそれら自身のペースで併行してエベントを取り扱うことができるようになる。
【００５７】
さらにまた、本発明によれば、リスナーがランするようなアプリケーションは、入力ドキュメントのフォーマットに整合するネーチブＸＭＬファンクションまたはネーチブファンクションである必要はない。むしろ、これらのリスナーは、取引プロセスフロントエンド３０４がＪＡＶＡインターフェイスである場合には、ＪＡＶＡファンクションでありうし、または、独特な取引処理アーキテクチャーにしたがってランするファンクションでありうる。これらの場合において、オブジェクトは、受信アプリケーションによって必要とされるフォーマットへ変換されうる。リスナーのアプリケーションが終わるとき、その出力は、モジュール３０３におけるビジネスインターフェイス定義によって特定されるようなドキュメントのフォーマットへと変換し戻される。こうして、トランスレータ３０２は、組み合わせたドキュメントを出力として供給するため直接的にネットワークインターフェイス３００に結合される。
【００５８】
取引処理フロントエンドに結合されたリスナーは、入力ドキュメントのためのリスナー、入力ドキュメントの特定エレメントのためのリスナーおよび入力ドキュメントの特定のエレメントに記憶されている属性のためのリスナーを含みうる。これにより、入力ドキュメントをフィルタリングしそれに応答するための特定のノードでの取引プロセスの種々な融通性のある実施が可能となる。
【００５９】
図４は、図３のシステムのための入力ドキュメントを受信して処理するためのプロセスを例示している。こうして、プロセスは、ネットワークインターフェイスでドキュメントを受信することで始まる（ステップ４００）。パーサーは、ビジネスインターフェイス定義に応答してドキュメントタイプ（４０１）を識別する。ＸＭＬフォーマットにてドキュメントのためのＤＴＤを記憶しているビジネスインターフェイス定義を使用して、ドキュメントは構文解析される（ステップ４０２）。次に、ドキュメントのエレメントおよび属性は、ホストのフォーマットへと変換される（ステップ４０３）。この例では、ＸＭＬロジックストラクチャーは、ゲットおよびセットファンクションの如きデータに関連した方法とともにＸＭＬエレメントのデータを担持するＪＡＶＡオブジェクトへと変換される。次に、ホストオブジェクトは、ホスト取引処理フロントエンドへ転送される（ステップ４０４）。これらのオブジェクトは、パーサーおよびトランスレータによって指示されるエベントに応答してプロセスへルーティングされる。ドキュメントのエレメントを受け取るプロセスは、実行され、出力を発生する（ステップ４０５）。その出力は、ビジネスインターフェイス定義によって定められるような出力ドキュメントのフォーマットへと変換される（ステップ４０６）。この例では、トランスレーションは、ＪＡＶＡオブジェクトのフォームからＸＭＬドキュメントのフォームへと進む。最後に、出力ドキュメントは、ネットワークインターフェイスを通して送り先へと送信される（ステップ４０７）。
【００６０】
図５は、図３のシステムのためのイベント発生器／イベントリスナー機構の詳細な図である。一般に、図５に示されている手法はＪＡＶＡ  ＪＤＫ１．１イベントモデルの改良である。このモデルにおいて、３種類のオブジェクトが考慮される。第１種類のオブジェクトはイベントの発生に関する情報を含むイベントオブジェクトである。発生できるイベントの異なる全種類に対応して、イベントオブジェクトの種類の数が有る。第２種類のオブジェクトは、何かが起こった時に活動を監視しイベントオブジェクトを発生するイベント発生器である。第３は、イベント発生器により発生されたイベントオブジェクトを聞くイベントリスナーである。イベントリスナーは一般に、特定のウインドウ上のマウスクリックなどのような特定のイベント発生器を聞く。イベントリスナーはイベント発生器上に「イベントリスナーを加える」方法を呼ぶ。このモデルは図３の環境に適合させることができ、ＸＭＬドキュメントにより代表されるようなオブジェクトのグラフを歩きそして構文解析することに応答してオブジェクトが発生される。
【００６１】
図５に示されるシステムは一般的なＸＭＬパーサー５００を有する。このようなパーサーは標準の呼び戻しモデルを使用して実現できる。構文解析イベントが発生する時に、パーサーはアプリケーションオブジェクト内で特定の方法を呼出し、パラメータ内の適当な情報を渡す。従って、単一のアプリケーション５０１がパーサーと共に存在する。アプリケーションはパーサーが提供する情報をＸＭＬイベントオブジェクト内にパッケージし、そしてブロック５０２により示されるように、それを自身により識別された数だけのイベントリスナーに送る。イベント５０２の組は完全にパーサーから独立している。イベント５０２はどんな数のマシン上のどんな数のリスナーおよびどんな数のスレッドへにも供給されることができる。イベントは１つの代替形式においては、エレメント構造情報セット（ＥＳＩＳ）に基づいている。従って、これらはエレメントの開始および終了などのようなドキュメント構造または属性の認識のような重要な観点のリストからなる。ＸＭＬ（そしてＳＧＭＬ）パーサーは一般にＥＳＩＳ構造をパーサーがそのアプリケーションに戻るための情報のデフォルトセットとして使用する。
【００６２】
専門化されたＥＳＩＳリスナー５０３は、イベント５０２の組に結合される。このリスナー５０３はＥＳＩＳリスナーＡＰＩを実現し、そして１または複数からの発生器からの全てのＸＭＬイベントを聞く。１つのエレメントイベント発生器５０４は専門化されたＥＳＩＳリスナーで、ＸＭＬイベント発生器でもある。そのリスナーは特定のタイプのエレメントに対するイベントにのみ興味があるオブジェクトである。例えば、ＨＴＭＬ環境においては、リスナーは指示されたリストのみ、すなわち、＜ＯＬ＞と＜／ＯＬ＞タグの間のドキュメントの部分のみに興味を有する。他の例では、リスナーは上の例のドキュメントから共通ビジネス言語に従って「ｐａｒｔｙ．ｎａｍｅ」エレメントまたは「ｓｅｒｖｉｃｅ．ｎａｍｅ」エレメントのみを聞き、エレメントのための図式的マッピングに一致するデータをエレメントが運ぶことを確実にするためにエレメントを処理し、そして受取ノードにおいて必要とされるプロセスに従って反応する。
【００６３】
これは、システムが、価格を合計するだけのようなドキュメントの特定部分のみを聞く小さいオブジェクトを有することを可能にする。リスナーが発生器からそれら自身を加えるまたは取除くことができるから、ＨＴＭＬドキュメントの例えば＜ＨＥＡＤ＞部分のみを聞くリスナーも存在できる。この理由およびＸＭＬドキュメントの高い反復性の理由により、高い目標的なコードを書くことおよび併発的なリスナーを書くことができる。例えば、＜ＯＬ＞リスナーは＜ＵＬ＞（指示されていないリスト）リスナーがその＜ＬＩ＞リスナーを設定する方法とは完全に分離して＜ＬＩ＞リスナーを設定することができる。代替方法として、図形ユーザインターフエイスを発生するリスナーおよび同じ入力を使用するデータベースを探索する別のリスナーを作成できる。従って、アプリケーションが一度に１つずつ検査する完成されたデータ構造とは反対に、ドキュメントはリスナーにより実行されるプログラムとして取扱われる。もし、アプリケーションがこの方法で書かれると、アプリケーションを実行するために全ドキュメントをメモリ内に持つ必要が無い。
【００６４】
イベント５０２の組に結合された次のリスナーは、属性フィルター５０５である。エレメントフィルタ５０４に似て属性フィルタ５０５はＥＳＩＳリスナーモデルに従い属性イベント発生器である。属性フィルタのためのリスナーはそれが興味を持つ属性を指定し、そして、指定された属性を持ついかなるエレメントのためのイベントを受取る。例えば、フォントマネージャは例えば＜Ｐ  ＦＯＮＴ＝“Ｔｉｍｅｓ  Ｒｏｍａｎ”／Ｐ＞のようなフォント属性を持つエレメントのためだけのイベントを受取るだろう。
【００６５】
エレメントイベント発生器５０４は、エレメントリスナー５０４Ａを専門化するためにそのようなエレメントオブジェクトを供給する。
【００６６】
属性イベント発生器５０５は属性イベントオブジェクトを属性リスナー５０５Ａへ供給する。同様に、属性オブジェクトは一のドキュメント形式から別へ属性を使用してＳＧＭＬ／ＸＭＬ変形する意味で「アーキテクチュア」に供給される。従って、５０５Ｂのアーキテクチュアは特定の名前を持った特定の属性を識別できるようにする。その定義された属性を持ったエレメントのみが出力ドキュメントの部分になり、そして出力ドキュメント内のエレメントの名前は、入力ドキュメント内の属性の値である。例えば、もしアーキテクチュア５０５ＢがＨＴＭＬであり、ストリングを、
＜ＰＵＲＣＨＡＳＥＳ  ＨＴＭＬ＝“ＯＬ”＞＜ＩＴＥＭ  ＨＴＭＬ＝“ＬＩ”＞＜ＮＡＭＥ  ＨＴＭＬ＝“Ｂ”＞ＳＴＵＦＦ＜／ＮＡＭＥ＞＜ＰＲＩＣＥ  ＨＴＭＬ＝“Ｂ”＞１２３＜／ＰＲＩＣＥ＞＜／ＩＴＥＭ＞＜／ＰＵＲＣＨＡＳＥ＞
翻訳すると、
＜ＯＬ＞＜ＬＩ＞ＳＴＵＦＦ＜／Ｂ＞＜Ｂ＞１２３＜／Ｂ＞＜／ＬＩ＞＜／ＯＬ＞
になり、正しいＨＴＭＬである。
【００６７】
イベント５０２の組に結合された次のモジュールはツリー（木）ビルダー５０６である。ツリービルダーはＸＭＬイベントのストリームを取り、下にあるドキュメントのツリー（木）表現を発生する。ツリービルダー５０６の一つの好ましい形式は、Ｗ３Ｃ（ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／１９９８／ＷＤ−ＤＯＭ−１９９８０７２０／ｉｎｔｒｏｄｕｃｔｉｏｎ．ｈｔｍｌ）の仕様に従ってドキュメントオブジェクトモデルＤＯＭオブジェクト５０７を発生する。イベントストリーム内のリスナーは大部分の要求を処理するのに使用できるが、ツリー形式はドキュメント回りの質問を支援するため、ノードを再順序付けるため、新ドキュメントの作成、例えばドキュメントを多数回構文解析するような、そこから同じイベントストリームを複数回発生できるメモリ内のデータ構造を支援するのに役立つ。専門化されたビルダー５０８は、特定の実施に適合するようなドキュメントの部分の特別なサブツリーを作るために、ツリービルダー５０６に結合できる。
【００６８】
入力するドキュメントに応答するのに加えて、ＸＭＬイベント５０２の他の源も供給されることができる。従って、イベントストリーム５１０はＤＯＭオブジェクトのツリー上を歩くことにより、そしてドキュメントが構文解析されいた時に作成された元のイベントストリームを再発生することにより発生される。これは、システムがドキュメントが数回構文解析されている外観を与えることを可能にする。
【００６９】
ツリーを歩きそしてイベントのストリームを発生するオブジェクトの観念は、ＤＯＭオブジェクトのツリーを越えて質問できるオブジェクトのいかなるツリーに一般化できる。従って、ＪＡＶＡウォーカー５１２は、ＪＡＶＡビーンコンポーネント５１３のツリーを歩くアプリケーションでもよい。ウォーカーは全ての公開されているフイールドおよび方法上を歩く。ウォーカーは終わりの無いサイクルに入り込まないことを確保するために既に訪問したオブジェクトの軌跡を記憶する。ＪＡＶＡイベント５１４はＪＡＶＡウォーカー５１２により発生されるイベントのタイプである。これは現在、オブジェクトから引き出すことのできる情報の種類の大部分を含む。これは、ＥＳＩＳのＪＡＶＡ等価物であり、そして、ＸＭＬに適用されたのと同じプログラム手法をＪＡＶＡオブジェクト一般に適用すること、特にＪＡＶＡビーンズにであるが、を可能にする。
【００７０】
ＪＡＶＡからＸＭＬイベント発生器５１５は、ＪＡＶＡリスナーとＪＡＶＡイベント発生器から構成される。これは、ＪＡＶＡウォーカー５１２からイベントのストリーム５１４を受取り、そしてＸＭＬドキュメントとしてＪＡＶＡオブジェクトを供給するために選択されたものを翻訳する。好ましい実施例において、イベント発生器５１５はＪＡＶＡビーンズＡＰＩを利用する。見られた各オブジェクトはエレメントとなり、エレメント名はクラス名とおなじである。そのエレメント内で、各埋め込まれた方法もまたエレメントとなり、その内容は方法を呼び起こすことにより戻された値である。もしそれがオブジェクトまたはオブジェクトの配列であると、これらは交互に歩かれる。
【００７１】
図６は、図５のフレームワーク上に構築された特定のアプリケーションの概略図である。このアプリケーションは、ＸＭＬドキュメント６００を取り込み、これをパーサ／発生器（構文解析ルーチン発生システム）６０１に適用する。ＥＳＩＳイベント６０２が発生され、且つ属性発生器６０３及びツリービルダー６０４に供給される。属性発生器は図５の発生器に対応する。この発生器５０５は、イベントを、例えば、ＸＭＬ入力からＨＴＭＬ出力に翻訳するための“アーキテクチャー”５０５Ｂに送る。これらのイベントは、ブロック６０５によって示される様に並列で処理され、且つリスナーによって処理される。リスナーの出力はドキュメントライター６０６に供給され、出力のためにＸＭＬフォーマットに戻し翻訳される。従って、例えば、図６に示されるこのアプリケーションは、ＸＭＬドキュメントを取り入れ、或るフォームを有するＨＴＭＬドキュメントを出力する。このフォームは次にブラウザに送られ、その結果がＸＭＬに戻し変換される。この運用のために、アーキテクチャコンセプトは、ＸＭＬからＨＴＭＬへのマッピングを提供する。図６に含まれる３つのアーキテクチャーは、テーブル及びリストの様なＨＴＭＬドキュメントの構造を与えるためのもの、ブラウザドキュメント上の入力フィールド用のラベルの様な表示されるべきドキュメントを特定する第２のもの、及び入力フィールド自体を記述する第３のものを含む。ＸＭＬドキュメント構造を維持するのに必要となるＸＭＬドキュメントのエレメントは、ＨＴＭＬフォーム内で不可視のフィールドとなる。このことは、サーバに送り戻されるＨＴＴＰポストメッセージにクライアントが入れる情報からＸＭＬドキュメントを再構成する際に使用するのに有用である。これらのイベントを聴取するリスナーが、ＨＴＭＬドキュメント用のイベントを出力する。このドキュメントは、ドキュメントライターオブジェクトへ行く。ドキュメントライターオブジェクトはＸＭＬイベントを聴取し、それらをＸＭＬドキュメントに戻す。ドキュメントライターオブジェクトは、この例におけるアーキテクチャーを聴取している全てのエレメント発生器に対するリスナーである。
【００７２】
図５及び６に図示される処理モジュールの構成は、図３のシステム用のパーサ及びトランザクションプロセスフロントエンドの或る実施の形態を表している。理解できる様に、極めて柔軟性のあるインタフェースが与えられ、これによってダイバース（変更）トランザクションプロセスを、入力するＸＭＬドキュメント、又は他の構造化ドキュメントフォーマットに応答して、実行することができる。
【００７３】
図７は、ビジネスインタフェース定義ビルダーモジュール７００を含むことを除いて図３と類似のノードを図示している。従って、図７のシステムは、ネットワークインタフェース７０１、ドキュメントパーサ７０２、及びドキュメントトランスレータ７０３を含む。トランスレータ７０３は、その出力をトランザクション処理フロントエンド７０４へ出力する。このフロントエンドは、商業上の機能７０５、データベース７０６、企業機能７０７、及び他の一般リスナー及びプロセッサ７０８のようなリスニング機能に結合される。図７に図示される様に、ビジネスインタフェースビルダー７００は、ユーザインタェース、共通ビジネスライブラリＣＢＬリポジトリ、相補的ビジネスインタフェース定義をを読むためのプロセス、及びコンパイラを含む。ユーザインタフェースは、ビジネスインタフェース定義の構築における企てを、共通ビジネスライブラリリポジトリ及び相補的ビジネスインタフェースの定義を読み出す能力に依存して、補助するのに使用される。従って、相補的ビジネスインタフェースの定義の入力ドキュメントは、特定のトランザクションの出力ドキュメントとして特定することが出来、相補的ビジネスインタフェースの定義の出力ドキュメントがトランザクションプロセスの様な入力として特定することができる。同様な仕方で、トランザクションビジネスインタフェースの定義がＣＢＬレポジトリから選択された成分を使用して構成することがてきる。ＣＢＬリポジトリの使用が、上述の例示案（ｂｉｄ１）ドキュメントの様な標準化されたドキュメントフォーマット、及びネットワーク内の他の人間によって直ぐに採用することの出来るビジネスインタフェースの定義の構築に於ける論理構造及び解釈情報の使用を促進する。
【００７４】
ビジネスインタフェース定義ビルダー７００は、トランスレータ７０３、ホストトランザクション処理アーキテクチャに従ってトランスレータによって処理されるべきオブジェクトを発生し、パーシング機能７０２を管理するために使用されるコンパイラーも含む。
【００７５】
図８は、ビジネスインタフェース定義ビルダー７００内のリポジトリ内に記憶される論理構造を示す発見的図式である。従って、パーティビジネスインタフェース定義８００を表すリポジトリ記憶は、例えば、消費者ＢＩＤ８０１、カタログハウスＢＩＤ８０２、ウェアハウスＢＩＤ８０３、及びアクションハウスＢＩＤ８０４を含む。従って、オンラインマーケットにおける新たな参加者は、そのビジネスと最もよく適合する標準化されたＢＩＤの一つを、ベーシックインタフェース定義として、選択する。更に、リポジトリは一組のサービスビジネスインタフェース定義８０５を記憶する。例えば、注文エントリＢＴＤ８０６、注文トラッキングＢＩＤ８０７、注文履行ＢＩＤ８０８、及びカタログサービスＢＩＤ８０９を記憶することができる。マーケットにおける新たな参加者がビジネスインタフェースの定義を構築する際に、リポジトリ内に記憶される標準化されたサービスのビジネスインタフェース定義を選択することができる。
【００７６】
パーティ及びサービスＢＩＤに加えて、入力及び出力ドキュメントＢＩＤが、フィールド８１０によって指示されるリポジトリに記憶される。従って、購入注文ＢＩＤ８１１、請求書ＢＩＤ８１２、見積り要求ＢＩＤ８１３、製品入手可能リポートＢＩＤ８１４、及び注文状態ＢＩＤ８１５をリポジトリに記憶することが出来る。
【００７７】
リポジトリは、好適なシステムにおいては、ＸＭＬに従ったドキュメント形態の定義として特定されるビジネスインタフェースの定義に加えて、フィールド８１６によって指示される様なセマンティックマップの形態で解釈情報を記憶する。従って、重量８１７、通貨８１８、サイズ８１９、製品識別８２０、及び製品特徴８２１を特定するために使用されるセマンティックマップをリポジトリ内に記憶することができる。更に、解釈情報は、ドキュメントの論理構造内のデータ構造を分類分けすることに備える。
【００７８】
更に、ビジネスインタフェースの定義を構成する際に使用される論理構造は、ブロック８２２によって指摘されるリポジトリに記憶される。従って、アドレス情報８２３を与えるためのフォーム、価格情報８２４を与えるためのフォーム、契約上関係の期間８２５を与えるためのフォームを提供することができる。ネットワークが拡張される時、ＣＢＬリポジトリも同様に拡張し、標準化は、新たな参加者が加わること及びビジネスインタフェースの定義をより容易にする。
【００７９】
図９は、図７のシステムを使用するビジネスインタフェース定義を構築するプロセスを図示している。プロセスは、ＢＩＤビルダーグラフィカルインタフェースをユーザに表示することによって開始される（ステップ９００）。システムは、グラフィカルインタフェース（ステップ９０１）によって発生された参加者、サービス及びドキュメント情報を識別するユーザ入力を受け入れる。
【００８０】
次に、如何なる参照論理構造、解釈情報、ドキュメント定義、及び／又はサービス定義は、ユーザ入力に応答してグラフィカルユーザーインタフェースを介してリポジトリから検索される（ステップ９０２）。次のステップで、相補的ビジネスインタフェース定義又はビジネスインタフェースの定義の成分が、カスタム化された検索エンジン、ウェブブラウザ、又は他の方法によって、ユーザー入力を介して選択されたネットワーク内の他の参加者からアクセスされる（ステップ９０３）。参加者に対するドキュメントの定義は、集められた情報を使用して発生される（ステップ９０４）。ドキュメントからホストへ及びホストからドキュメントへの各マッパーに対するトランスレータが、コンパイラによって発生される（ステップ９０５）。定義に対応するホストアーキテクチャデータ構造はコンパイラによって発生される（ステップ９０６）。そして発生されたビジネスインタフェースの定義は、ウェブサイト又は他の場所にポスト送付することにより、ネットワーク上にポスト送付され、ネットワーク内の他のノードにアクセス可能となるされる。（ステップ９０７）。
【００８１】
ビジネスインタフェースの定義は潜在的な商業パートナーに対して会社がオファーしたオンラインサービスを告げ、且つこれらのサービスを実施するのに使用するドキュメントを告げる。従って、サービスは、サービスが受け取り且つ発生するドキュメントによってビジネスインタフェースの定義で定められる。このことは、ＸＭＬサービスの定義の以下のフラグメントに例示されている。
【００８２】
0004712191.tif 000021
0004712191.tif 000022
【００８３】
このＸＭＬフラグメント（ｆｒａｇｍｅｎｔ）は、２つの処理からなるサービス、すなわち、１つは注文（ｏｒｄｅｒ）を取得する処理及びもう１つはそれに追従する処理を定義する。それぞれの定義は、もし正当な要求が特定のＷｅｂアドレスに提示されたなら、サービスを実行するための契約（ｃｏｎｔｒａｃｔ）又は約束（ｐｒｏｍｉｓｅ）を表現する。ここで注文サービスは、ローカルであるか、あるいはネットワーク上の産業全体のレジストリ中に記憶されたものでよいリポジトリ（ｒｅｐｏｓｉｔｏｒｙ）中に置かれている、標準の「ｐｏ．ｄｔｄ」ＤＴＤ（Ｄｏｃｕｍｅｎｔ  Ｔｙｐｅ  Ｄｅｆｉｎｉｔｉｏｎ）に適合する、入力されるドキュメント（ｄｏｃｕｍｅｎｔ）を必要とする。もし１つのノードがその注文を実行できるなら、そのノードは、定義がローカルである、カスタマイズされた「ｉｎｖｏｉｃｅ．ｄｔｄ」に適合するドキュメントを返すであろう。実際には、会社は、それが宣言するＸＭＬ仕様に適合する購入注文を提出できる誰とでも、ビジネスを行う約束をしている。事前の調整は不要である。
【００８４】
ＤＴＤは、所定の型のドキュメントのための公式の仕様すなわち文法であり、それは、要素、それらの属性、及びそれらが表示されなければならない状態を記述する。例えば、購入注文は、購入者及び販売者の名前及び住所、一組の製品説明、及び価格及び配達日のような関連する売買条件を典型的には含む。エレクトロニック・データ・インターチェンジ（Ｅｌｅｃｔｒｏｎｉｃ  Ｄａｔａ  Ｉｎｔｅｒｃｈａｎｇｅ，ＥＤＩ）では、例えばＸ１２  ８５０仕様は、購入注文のために普通に使用されるモデルである。
【００８５】
リポジトリによって、多くのビジネス領域で共通の、再使用可能な意味の成分（ｒｅｕｓａｂｌｅ  ｓｅｍａｎｔｉｃ  ｃｏｍｐｏｎｅｎｔｓ）から、ＸＭＬドキュメントモデルを開発することが促進される。そのようなドキュメントは、たとえそれらの見かけが全く異なっていたとしても、それらの共通のメッセージ要素から理解することができる。これは、コモン・ビジネス・ライブラリ・リポジトリ（Ｃｏｍｍｏｎ  Ｂｕｓｉｎｅｓｓ  Ｌｉｂｒａｒｙ  ｒｅｐｏｓｉｔｏｒｙ）の役割である。
【００８６】
コモン・ビジネス・ライブラリ・リポジトリは、以下を含む、一般的なビジネス概念のための情報モデルからなる。
・会社、サービス、及び製品のような、ビジネス記述プリミティブ（ｂｕｓｉｎｅｓｓ  ｄｅｓｃｒｉｐｔｉｏｎ  ｐｒｉｍｉｔｉｖｅ）、
・カタログ、購入注文、及びインボイスのようなビジネス形態、
・標準の測定値（ｓｔａｎｄａｒｄ  ｍｅａｓｕｒｅｍｅｎｔｓ）、日時、位置、分類コード、である。
【００８７】
この情報は、会社がＸＭＬアプリケーションを迅速に開発するためにカスタマイズしかつ組み立てることができる、拡張可能で公開されたＸＭＬ構成ブロック（ＸＭＬ  ｂｕｉｌｄｉｎｇ  ｂｌｏｃｋ）として表現される。微少の（ａｔｏｍｉｃ）ＣＢＬ要素は、国、通貨、住所（ａｄｄｒｅｓｓ）、及び時間のための標準ＩＳＯコードのような、産業界のメッセージング規格及び慣習（ｉｎｄｕｓｔｒｙ  ｍｅｓｓａｇｉｎｇ  ｓｔａｎｄａｒｄｓ  ａｎｄ  ｃｏｎｖｅｎｔｉｏｎｓ）を実行する。低レベルのＣＢＬセマンティクス（ｓｅｍａｎｔｉｃｓ）は、ダブリン・コア（Ｄｕｂｌｉｎ  Ｃｏｒｅ）のような、インターネット・リソースのための、提示されたメタデータ構成（ｍｅｔａｄａｔａ  ｆｒａｍｅｗｏｒｋ）の分析からも得られる。
【００８８】
次のレベルの要素は、これらの構成ブロックを使用して、ＯＴＰ（Ｏｐｅｎ  Ｔｒａｄｉｎｇ  Ｐｒｏｔｏｃｏｌ）及びＯＢＩ（Ｏｐｅｎ  Ｂｕｙｉｎｇ  ｏｎ  ｔｈｅ  Ｉｎｔｅｒｎｅｔ）のような、出現したインターネット規格で使用されるビジネス形態だけでなく、Ｘ１２  ＥＤＩ処理で使用されるもののような基本的なビジネス形態も実行する。
【００８９】
ＣＢＬの主眼は、全てのビジネス領域（会社、サービス、及び製品のような、ビジネス記述プリミティブ；カタログ、購入注文、及びインボイスのようなビジネス形態；標準の測定値、日時、位置、分類コード）に共通の機能及び情報にある。ＣＢＬは、可能な場合の意味論のための規格又は産業界の慣習に依存している（例えば、ヨーロッパでの「日／月／年」に対してアメリカでの「月／日／年」を指定する規則は、別個のＣＢＬモジュール中にコード化される）。
【００９０】
ＣＢＬは、アプリケーションを設計するために使用される言語である。それは、ＸＭＬの「ドキュメント・ワールド」と、ＪＡＶＡの「プログラミング・ワールド」又は他の処理プロセスアーキテクチャとの間のギャップを橋渡しするように設計されている。スキーマ（ｓｃｈｅｍａ）は、ドキュメントタイプの詳細な公式の仕様が種々の関連する形態がそこから生成されるようなマスター・ソース（ｍａｓｔｅｒ  ｓｏｕｒｃｅ）である、「ドキュメントによるプログラミング」の思想を具体化する。これらの形態は、ＣＢＬ、ＪＡＶＡオブジェクト、ＸＭＬのインスタンスと対応するＪＡＶＡオブジェクトとの間の変換プログラム、及びサポート・ドキュメントのためのＸＭＬ  ＤＴＤを含む。
【００９１】
ＣＢＬは、そこからシステムのほとんど全ての部分が自動的にコンパイラによって生成されるような単一のソースを作り出す。ＣＢＬは、それぞれの情報の要素及び属性と関連するセマンティクスの仕様を含むように、特定のドキュメントタイプの構造を公式に定義するために通常使用されるＳＧＭＬ／ＸＭＬを拡張することによって機能する。ＳＧＭＬ／ＸＭＬでの（ほとんどの）限られた組のキャラクタタイプを、任意の種類のデータタイプを宣言するために拡張することができる。
【００９２】
これは、「ｄａｔｅｔｉｍｅ」モジュールのためのＣＢＬ定義からのフラグメントである。
0004712191.tif 000023
0004712191.tif 000024
【００９３】
このフラグメントでは、ＥＬＥＭＥＮＴ”ｙｅａｒ”は、キャラクタデータ及び関連する”ｓｃｈｅｍａ”属性として定義され、キャラクタデータも、ＩＳＯ８６０１規格のセクション３．８になるように”ｙｅａｒ”のためのスキーマを定義する。
【００９４】
この”ｄａｔｅｔｉｍｅ”ＣＢＬモジュールは、実際は、スキーマＤＴＤのインスタンスとして定義される。最初に、モジュール名が定義される。次に、”ｄａｔｅｔｉｍｅ”要素の”ＹＥＡＲ”は、ＩＳＯ８６０１規格のセマンティクスに結合させられる。
【００９５】
0004712191.tif 000025
0004712191.tif 000026
【００９６】
例のマーケットの参加者及び上記のサービスモジュールも、ＣＢＬリポジトリ中に記憶される。
【００９７】
図１０では、航空貨物受取証（Ａｉｒｂｉｌｌ）１０００が、一般的な購入注文ＤＴＤ１００１をカスタマイズし、出荷重量１００２についてのより具体的な情報を追加することによって定義されているところである。一般的な購入注文１００１は、住所、日時、通貨、及び販売者及び製品説明のためのＣＢＬモジュールから、広範囲にわたって、最初に組み立てられた。このように、ＣＢＬを使用することにより、ＸＭＬ商用アプリケーションのインプリメンテーションはかなり促進される。より重要なことに、ＣＢＬによって、商用アプリケーションを相互接続することが簡単になる。
【００９８】
ＣＢＬでは、ＸＭＬはスキーマにより拡張される。拡張によって、内容を簡単に確認できるように、ＸＭＬ要素に強調タイピング（ｓｔｒｏｎｇ−ｔｙｐｉｎｇ）が追加される。例えば、＜ＣＰＵ ｃｌｏｃｋ ｓｐｅｅｄ＞と呼ばれる要素は、一組の正当な値（ｖａｌｉｄ  ｖａｌｕｅ）：｛１００，１３３，１６６，２００，２３３，２６６  Ｍｈｚ｝を有する整数として定義されることができる。スキーマは、情報をクラスの定義から簡単にインスタンス生成することができるように、クラス−サブクラスの階層も追加する。例えば、ラップトップを、ディスプレイのタイプ及びバッテリの寿命のような特徴のための追加のタグを有するコンピュータとして記述することができる。これら及び他の拡張により、ＸＭＬと伝統的なオブジェクト指向及び関係データモデルの間の自動翻訳だけでなく、データ入力も容易になる。
【００９９】
このようにして、完成されたＢＴＤは、参加者及び上記に概説したサービスの実際のインスタンス、ＤＴＤインスタンスの論理的構造に対応するＪＡＶＡビーンズ（ｂｅａｎｓ）、及びＸＭＬからＪＡＶＡに及びＪＡＶＡからＸＭＬに変換する変換コードのためのＤＴＤを作り出すコンパイラを通して実行される。他のシステムでは、オブジェクトを使用しやすくするために、ドキュメントも、ユーザインターフェース上のディスプレイのために、又はユーザによる印刷のために生成される。
【０１００】
例えば、市場参加者及び前述のサービスＤＴＤ、コンパイラによって生成されたＪＡＶＡビーンズは、（簡潔のためいくつかの修正を加えて）以下のように示される。
0004712191.tif 000027
0004712191.tif 000028
0004712191.tif 000029
0004712191.tif 000030
0004712191.tif 000031
0004712191.tif 000032
0004712191.tif 000033
0004712191.tif 000034
0004712191.tif 000035
0004712191.tif 000036
0004712191.tif 000037
0004712191.tif 000038
0004712191.tif 000039
0004712191.tif 000040
0004712191.tif 000041
0004712191.tif 000042
0004712191.tif 000043
0004712191.tif 000044
0004712191.tif 000045
0004712191.tif 000046
0004712191.tif 000047
0004712191.tif 000048
0004712191.tif 000049
0004712191.tif 000050
0004712191.tif 000051
0004712191.tif 000052
0004712191.tif 000053
0004712191.tif 000054
0004712191.tif 000055
0004712191.tif 000056
0004712191.tif 000057
0004712191.tif 000058
0004712191.tif 000059
0004712191.tif 000060
0004712191.tif 000061
0004712191.tif 000062
0004712191.tif 000063
0004712191.tif 000064
0004712191.tif 000065
0004712191.tif 000066
0004712191.tif 000067
0004712191.tif 000068
0004712191.tif 000069
0004712191.tif 000070
0004712191.tif 000071
上記したＪＡＶＡビーンに加えて、変換コードは以下に示されているように、ＪＡＶＡからＸＭＬへ、及びＸＭＬからＪＡＶＡへ翻訳するため作られる。
0004712191.tif 000072
0004712191.tif 000073
0004712191.tif 000074
0004712191.tif 000075
0004712191.tif 000076
0004712191.tif 000077
0004712191.tif 000078
0004712191.tif 000079
0004712191.tif 000080
0004712191.tif 000081
0004712191.tif 000082
0004712191.tif 000083
【０１０１】
ドラッグ、ドロップ及び形を編集するユーサインターフェースを提供する、ＢＩＤコンポーザ（ｃｏｍｐｏｓｅｒ）アプリケーションと一緒にツールを使用して、開発者は、ビジネスインターフェースの定義を作り出すことができ、及び、良好に形成された、有効なビジネスインターフェースの定義をＸＭＬドキュメントの形態で生産することができる。このように、例のランタイム・インスタンスは、ＩＢＭからラップトップコンピュータを注文するために、イングラム・マイクロ（Ｉｎｇｒａｍ  Ｍｉｃｒｏ）によって使用される、ＩＢＭのためのサービスを注文するためのビジネスインターフェースの定義である。（出願人と、ＩＢＭ又はイングラム・マイクロの間には関係はない。）これらのプロセスを利用すると、ユーザは、本発明に従って定義されたドキュメントを使用して、ビジネスインターフェースのプログラムができるシステムを構築することができる。
【０１０２】
ＸＭＬ／ＪＡＶＡ環境における本発明のＣＢＬ及びＢＩＤプロセッサの役割は購入注文の処理の以下の説明によりさらに理解できるであろう。
【０１０３】
会社ＡはＣＢＬ  ＤＴＤ及びモジュールのライブラリを含む視覚プログラム環境を使用するその購入注文ドキュメントを定義し、全ては共通のビジネス言語エレメントを使用して定義され、それらがデータタイプ及び他の翻訳情報を含むようになっている。会社ＡのＰＯはＣＢＬライブラリに付属しているより一般的なトランザクションドキュメント仕様に対してマイナなカスタマイゼイションを含むかもしれないし、或いは、アドレス、データ及び時間、電流等のためＣＢＬモジュールからのグランドから作られるかもしれない。
【０１０４】
（上記したｔｒａｎｓａｃｔ．ｄｔｄのような）一般的なトランザクションドキュメント仕様のドキュメントはＣＢＬ仕様がモジュールから作られ、他のＣＢＬ  ＤＴＤと連結される方法を類型化する。
【０１０５】
コンパイラは購入注文の定義を取り、幾つかの異なるターゲット形式を発生する。これらのターゲット形式のすべては元の仕様の「ツリーツーツリー（ｔｒｅｅ  ｔｏ  ｔｒｅｅ）」変形を介して得ることができる。この例にとって最も重要なのは、
（ａ）購入注文のためのＸＭＬ  ＤＴＤ
（ｂ）購入注文のためのデータ構造を含むＪＡＶＡビーン（Ｂｅａｎ）（ＪＡＶＡクラス、引数、データタイプ、方法、及び例外構造は購入注文のスキーマ定義の情報に対応して作り出される。）
（ｃ）購入注文ＤＴＤに従う購入注文を購入注文ＪＡＶＡビーンに変換し、又は、それらをデータベースにロードし、又は、ブラウザに購入注文を表示するためＨＴＭＬ（又はＸＳＬスタイル集）を作り出す整列プログラム
（ｄ）購入注文ＪＡＶＡビーンからデータ値を引き出し、それらを購入注文ＤＴＤに従うＸＭＬドキュメントに変換する整列しないプログラム
今、シナリオに戻ると、購入の申し込みは購入注文を発生し、該購入注文は購入注文を受け入れる供給者のためのサービスインターフェースとして明記されたＤＴＤに従う。
【０１０６】
パーサは購入注文ＤＴＤを使用し、エレメント及びそれが含む属性値についての情報ストリームへの購入注文インスタンスを分解する。その後、これらのプロパティセットはそれらをＪＡＶＡコードと重ねることにより対応するＪＡＶＡイベントオブジェクトに変換される。事実上、この変換は文法がＤＴＤにより定義される顧客プログラム言語の命令として印を付けたＸＭＬドキュメントの部分を処理する。これらのＪＡＶＡイベントはコンパイラにより生成された整列しているアプリケーションにより処理され、ＪＡＶＡビーンのデータ構造をロードすることができる。
【０１０７】
ＸＭＬドキュメントをＪＡＶＡアプリケーションのための１セットのイベントに変換し、処理することは、解析をする正常なモデルとは異なり、解析が完了するまで内部データ構造及び処理は開始しないので、パーサ出力は維持される。ＢＩＤ定義に応じたイベントベースの処理は、最初のイベントが発せられると直ぐに同時に発生のドキュメントアプリケーション処理を始めさせるので、、プロセッサの非常に優れた機能を可能にする鍵である。
【０１０８】
各種タイプのイベントに聞くＪＡＶＡプログラムはそれらのイベントのスキーマ定義から形成される。これらのリスナーはＣＢＬのＸＭＬ定義と関連するビジネス論理を実行するために作り出されたプログラムであり、例えば、アドレスエレメントと関連し、データベースをチェックすることにより郵便番号を確認するコードであってもよい。これらのリスナーはドキュメントルータで登録することによりイベントに応募し、それらに興味を示したすべての応募者に関連したイベントを割り当てる。
【０１０９】
新規のリスナーがプログラムするこの公表し、応募したアーキテクチャ手段は現存のものの知識なしに、またはそれに影響を与えることなく付加されることができる。各リスナーはルータがそのイベントを割り当てるキューを有し、複数のリスナーはそれら自身のペースで並行してイベントを取扱うことができる。
【０１１０】
ここの例示の購入注文にとって、
・注文入力プログラムにそれをつなげるであろう購入注文
・在庫をチェックするであろう製品説明書
・Ｆｅｄ  Ｅｘ又は引き渡しの有効性のための他のサービスをチェックすることができるであろうアドレス情報
・（信用貸しの価値のため、又は公告を提供するため、又は顧客が誰であるかを知ることに基づく同様の処理のため）注文の履歴をチェックすることができるであろう買い手の情報
のためのリスナーであるかもしれない。
【０１１１】
複合したリスナーは初期のものの形状として作り出されることができる。（例えば、購入注文のリスナーがここのこれらのリスナーを含み、引き合いに出してもよく、又は、それらはそれら自身で引き合いに出されてもよい。）
【０１１２】
図１１は図１のネットワークでのマーケットマーカのノードを示している。マーケットマーカのノードは図３のシステムの基本構造を含み、ネットワークインターフェース１１０１、ドキュメントパーサ１１０２、ホストへのドキュメント及びドキュメント翻訳機へのホスト１１０３、フロントエンド１１０４を有し、この例ではルータと呼ばれている。この例でのマーケットマーカモジュール１１０５は１セットのビジネスインターフェース定義、又はマーケットの参加者のためマーケットマーカの機能を支援するのに十分な他の識別子、ＣＢＬリポジトリ、及びマーケットの参加者の要求をすべて満たすコンパイラを備えている。ルータ１１０４は参加者のレジストリ及びドキュメントフィルタを備え、翻訳機の出力でパーサにより生成されたイベントに応答し、参加者のレジストリにより、及びＸＭＬイベント発生器に対するリスナーの間のエレメント及び属性フィルタにより、入力ドキュメントの経路を定める。したがって、マーケットの一定の参加者は登録し、予め特定したパラメータに合うドキュメントを受け取ってもよい。例えば、特定のＤＴＤによる入力ドキュメントは、閾値以上の購入製品数、又は購入されるドキュメント要求の最大価格等の属性を含み、ルータ１１０４でフィルタドキュメントに使用されることができる。その後、ルータ１１０４で参加者のレジストリに登録された情報に合致するようなドキュメントは登録された参加者に送られる。
【０１１３】
ルータ１１０４はまたローカルホストサービス１１０５及び１１０６の要求を満たし、例えば、マーケットマーカと同様にマーケットの参加者のように作動する。通常、ルータ１１０４により受け取られたドキュメントはトラバースされ、宛先を決定し、そのようなドキュメントは送られ、そこで再度、翻訳機１１０３を介して、必要であれば、ネットワークインターフェース１１０１からそれぞれの宛先に送られる。
【０１１４】
マーケットマーカは１セットの内部及び外部のビジネスサービスと一緒に結び付けるサーバであり、仮想の計画又はトレーディングコミュニティを作り出す。サーバは入力ドキュメントを解析し、例えば、製品データのためのリクエストをカタログサーバに渡すことにより、又は、購入注文をＥＲＰシステムに送ることにより、適当なサービスを引き合いに出す。サーバはまた翻訳タスクを取扱い、トレーディングパートナにより使用されるドキュメント書式及びそのレガシーシステムにより要求されるデータ書式に会社のＸＭＬドキュメントからの情報をマッピングする。
【０１１５】
上記サービスの定義に関して、会社が購入注文を提示したとき、サーバのＸＭＬパーサは購入注文ＤＴＤを使用し、購入注文インスタンスを情報イベントのストリームに変換する。その後、これらのイベントは所定のタイプのイベントを取扱うためにプログラムされたアプリケーションに送られ、幾つかの場合には、情報はインターネットを介して異なるビジネスに完全に送られる。購入注文の例では、幾つかのアプリケーションはパーサから来る情報で作動してもよい。
・注文入力プログラムは完全なメッセージとして購入を処理する。
・ＥＲＰシステムは購入注文に記述された製品のための在庫をチェックする。
・顧客データベースは顧客のアドレスを証明し、又は更新する。
・運送会社はアドレス情報を使用し、搬送をスケジュールする。
・銀行はクレジットカードを使用し、トランザクションを許可する。
【０１１６】
トレーディングパートナーは、彼らが交換するビジネスドキュメントの構造、内容及び順序について同意するだけでよく、ＡＰＩの詳細について同意する必要はない。ドキュメントがどのように処理されるか及びどのようなアクション結果が生じるかは、厳密にサービスを提供するビジネス次第である。これは、システムレベルからビジネスレベルへの統合を高める。それは、ビジネスが、その内部技術の履行、組織化、又はプロセスにおける変更にもかかわらず、明瞭で安定なインターフェイスをそのビジネスパートナーに提供することを可能にする。
【０１１７】
図１２、１３及び１４は、図１１のシステムのマーケットメーカーノードにおいて実行されるプロセスを示している。図１２において、入力ドキュメントが、発信参加者ノードからのネットワークインターフェイスにおいて受け取られる（ステップ１２００）。ドキュメントがパースされる（ステップ１２０１）。ドキュメントが、ホストのフォーマットへ、例えば、ＸＭＬからＪＡＶＡへ変換される（ステップ１２０２）。ホストフォーマット化されたイベント及びオブジェクトが、その後、ルータサービスへ送られる（ステップ１２０３）。ドキュメントのタイプ及びドキュメントの内容に従ってドキュメントを受け入れるように記憶されたサービスが識別される（ステップ１２０４）。ドキュメント及びドキュメントの一部が、識別されたサービスに送られる（ステップ１２０５）。ドキュメントの内容に応じてサービスが実行される（ステップ１２０６）。サービスの出力データが発生される（ステップ１２０７）。出力が、ドキュメントフォーマットへ、例えば、ＪＡＶＡフォーマットからＸＭＬフォーマットへ変換される（ステップ１２０８）。最後に、出力ドキュメントが参加者ノードへ送られる（ステップ１２０９）。
【０１１８】
レジストレーションサービスは、ルータにより管理されるそのような機能の一つである。従って、マーケット参加者ドキュメントが図１３に示されるネットワークインターフェイスにおいて受け入れられる（ステップ１３００）。マーケット参加者ドキュメントがマーケットメーカーノードについてのビジネスインターフェイス定義リポジトリに記憶される（ステップ１３０１）。加えて、ドキュメントがパースされる（ステップ１３０２）。パースされたドキュメントが、ホストのフォーマットへ変換される（ステップ１３０３）。次に、ドキュメントがルータサービスへ送られる（ステップ１３０４）。ルータサービスは、レジストレーションサービスをドキュメントのタイプ及びドキュメントの内容に従ってドキュメントの宛先であると識別するリスナーを含む（ステップ１３０５）。ドキュメント及びドキュメントのエレメントが、レジストレーションサービスに送られる（ステップ１３０６）。レジストレーションサービスにおいて、必要とされるサービス仕様がビジネスインターフェイス定義に応じてリトリーブされる（ステップ１３０７）。ステップ１３０８において、サービス仕様が集められる場合には、ビジネスインターフェイス定義及びサービス仕様に従ってルータサービスフィルタがセットされる（ステップ１３０９）。レジストレーションアクノリッジメントデータが発生される（ステップ１３１０）。レジストレーションアクノリッジメントデータが、ドキュメントフォーマットへ変換される（ステップ１３１１）。最後に、アクノリッジメントドキュメントが参加者ノードへ送られてマーケットメーカーで成功裏にレジスタされた参加者に通知する（ステップ１３１２）。
【０１１９】
必要とされるサービス仕様を集めるステップ１３０７におけるプロセスは、図１４の１つの例について示されている。このプロセスは、マーケット参加者によりサポートされるサービスビジネスインターフェイス定義を探し出すことにより始まる（ステップ１４００）。サービス定義が例えば、リポジトリノードへのＥメールトランザクション又はウェブアクセスによりリトリーブされる（ステップ１４０１）。サービス仕様がＢＩＤリポジトリに記憶される（ステップ１４０２）。サービスビジネスインターフェイス定義ドキュメントがパースされる（ステップ１４０３）。パースされたドキュメントが、ホストのフォーマットへ変換される（ステップ１４０４）。次に、ホストのオブジェクトがルータサービスへ送られる（ステップ１４０５）。レジストレーションサービスがドキュメントのタイプ及び内容に従って識別される（ステップ１４０６）。最後に、サービスビジネスインターフェイス定義ドキュメントの情報がレジストレーションサービスに送られて（ステップ１４０７）、図１３のプロセスに従って使用される。
【０１２０】
図１５は、本発明に従ってマーケットメーカーノードに入力するデータを処理するプロセッサ、コンポーネント及びシーケンスを示している。マーケットメーカーノードは、ネットワークインターフェイスにおいて通信エージェント１５００を有する。通信エージェントはＸＭＬパーサ１５０１と接続され、ＸＭＬパーサ１５０１は、イベントをＸＭＬプロセッサ１５０２に供給する。ＸＭＬプロセッサ１５０２は、イベントをドキュメントルータに供給する。ドキュメントルータは、ドキュメントサービス１５０４にフィードし、ドキュメントサービス１５０４は、受け取ったドキュメントをホストシステムのエンタープライズソルーションソフトウェア１５０５に供給するインターフェイスとなる。通信エージェント１５００は、ＨＴＴＰ、ＳＭＴＰ、ＦＴＰ又は他のプロトコルのようなプロトコルを支持する適当なプロトコルスタックを有するインターネットインターフェイスである。従って、入力するデータは、特定の通信チャンネルに適合するようにＸＭＬ構文法、ＡＳＣＩＩデータ構文法又は他の構文法で入力してもよい。非ＸＭＬ構文法で受け取ったドキュメントは全てＸＭＬに変換されてＸＭＬパーサに送られる。非ＸＭＬ形式からＸＭＬ形式への変換をサポートするために変換テーブル１５０６が使用される。
【０１２１】
変換されたドキュメントはパーサ１５０１に供給される。ＸＭＬパーサは、受け取ったＸＭＬドキュメントを、それとマッチするドキュメントタイプ定義に従ってパースする。エラーが見つかった場合には、パーサがドキュメントを通信エージェント１５００へ送り返す。ビジネスインターフェイス定義コンパイラＢＩＤＣ１５０７は、ビジネスインターフェイス定義データのためのコンパイラとして働く。ＸＭＬパーサのためのＤＴＤファイル、ＤＴＤファイルに対応するＪＡＶＡビーンズ及びＤＴＤファイルをＪＡＶＡビーンズへ変換する変換ルールは、ＢＩＤデータをコンパイルすることにより作られる。これらのツールを参照することにより、ＸＭＬインスタンスがＪＡＶＡインスタンスへ変換される。そこで、ＢＩＤコンパイラ１５０７は、ＤＴＤドキュメント１５０８を記憶して１５０９に対応するＪＡＶＡドキュメントを発生する。ＸＭＬドキュメントはプロセッサ１５０２に送られ、プロセッサ１５０２は、そのドキュメントをＪＡＶＡフォーマットに変換する。好ましいシステムでは、ＸＭＬフォーマットで受け取ったドキュメントタイプ定義と同じステータスを有するＪＡＶＡドキュメントが発生される。ＪＡＶＡビーンズがドキュメントルータ１５０３に送られる。ドキュメントルータ１５０３がＪＡＶＡビーンズを受け取り、受け取ったクラスをレジストリプログラムを使用して、例えば、上述したイベントリスナーアーキテクチャを使用して、適当なドキュメントサービスに送る。ルータ１５０３からＪＡＶＡビーンズの形式でドキュメントを受け取ったドキュメントサービス１５０４は、エンタプライズソルーションソフトウェアとして働く。これは、ＸＭＬイベントのリスナーを入力するデータ流れと結合するレジストリサービス１５１０と、入力するドキュメントの適当なサービスへのルーティングを管理するサービスマネージャ１５１１とを有する。ドキュメントサービスマネージャ１５１１は、レジストリサービスの管理及びドキュメントの一貫性の維持等を行う。
【０１２２】
ドキュメントサービスは、任意のプロプラエタリＡＰＩを使用して、又は、ＣＯＲＢＡ／ＣＯＭインターフェイスその他のアーキテクチャのようなより共通な形式を使用してバックエンドシステムと通信する。
【０１２３】
図１６は、本発明に係るマーケットメーカー及びマーケット参加者構造のヒューリスティックダイアグラムである。従って、本発明に係るＥコマーストランザクションマーケットは、図１６に示されているように論理的に組織化できる。その組織の最上部において、マーケットメーカーノード１６００が設定される。マーケットメーカーノードは、マーケットプレイス１６０１を設定するリソースを含む。このようなリソースは、マーケットレジストリサービス等を含む。ビジネス１６０２は、ビジネスインターフェイス定義をパブリッシュすることによりマーケットプレイスにレジスタする。ビジネスインターフェイス定義は、ビジネスが参加するコマーシャルトランザクションについてサービス１６０３を定義する。トランザクション１６０４及びサービス１６０３は、ドキュメント１６０５を使用して入力及び出力を定め、トランザクションにおける参加者の間の商業上の関係をアウトラインする。ドキュメントは各トランザクションの詳細を含むコンテント１６０６を有する。コンテントがマーケットの参加者により及びマーケットメーカーにより処理される方法は、本発明に従って設立されるＥコマーストランザクションネットワークに基づくドキュメントに完全に依存する。全体として、通信ネットワーク上でＥコマーストランザクション可能とするように頑強性、拡張性及び直観力に富む構造が提供される。
【０１２４】
従って、本発明は、例示のシステムにおいて、ＸＭＬプロセッサに基づくプラットフォームを提供し、疎結合されたビジネスシステムの間のインターフェイスとしてＸＭＬドキュメントを使用している。ドキュメントは、ビジネスの間で転送され、会社のビジネスシステムに入る前に特定のノードによって処理される。従って、プラットフォームは、各ビジネスシステムが異なる内部コマースプラットフォーム、処理及び意味論を使用している場合に、共通の組のビジネスドキュメント及び形式を特定することによりビジネス間のＥコマースアプリケーションを可能にする。
【０１２５】
本発明によれば、ビジネスシステムとサービスを相互接続することによりバーチャルエンタプライズが形成され、主に、ビジネスが受け入れて発生するドキュメント（ＸＭＬコード化された）に間して次のとおり定義される。
「貴社が当社にカタログを請求される場合には、貴社にカタログを送ります。」「貴社が購入の注文をされ当社がそれを受け入れことができる場合には、貴社に送り状を送ります。」
上述した本発明の好ましい実施例の説明は、本発明の解説するためになされたものである。これは、包括的であること又は発明を開示した厳密な形式に限定することを意図するものではない。当業者にとって多くの修正及び変更は明らかである。本発明の範囲は、以下の請求の範囲及びそれと等価なものによって定められるものである。
【図面の簡単な説明】
【図１】  本発明によるビジネスインタフェース定義（ＢＩＤ）を含む電子商取引ネットワークの概略図である。
【図２】  本発明によるビジネスインタフェース定義ドキュメントの概略図である。
【図３】  本発明によるネットワーク中の参加者ノードのためのサーバの概念的なブロックダイアグラムである。
【図４】  本発明による参加者ノードで受け取られたドキュメントのプロセシングを説明するフローチャートである。
【図５】  ＸＭＬベースのシステムについての構文解析プログラム及びトランザクションプロセスフロントエンドのブロックダイアグラムである。
【図６】  構文解析プログラム機能のフローの概念的なダイアグラムである。
【図７】  本発明によるビジネスインタフェース定義に使用されるサーバにおけるリソースの概略図である。
【図８】  ビジネスインタフェース定義の構築のために使用する、本発明によるリポジトリの概略図である。
【図９】  本発明によるビジネスインタフェース定義を構築するプロセスを説明するフローチャートである。
【図１０】  本発明によるリポジトリの発見的概要を提供するものである。
【図１１】  ビジネスインタフェース定義に基づく本発明のネットワークのためのマーケットメーカー機能を提供するサーバにおけるリソースの概略図である。
【図１２】  受け取られたドキュメントのマーケットメーカーノードプロセシングのフローチャートである。
【図１３】  本発明によるマーケットメーカーノードにおける参加者の登録のプロセスを説明するフローチャートである。
【図１４】  図９のプロセスによるマーケットメーカーノードにおけるサービスの仕様書の提供のプロセスを説明するフローチャートである。
【図１５】  本発明によるマーケットメーカーまたは参加者における操作のシーケンスを説明するダイアグラムである。
【図１６】  本発明によるＢＩＤに基づく商取引ネットワークの要素の概念的なダイアグラムである。
【図１】
0004712191.tif 000084
【図２】
0004712191.tif 000085
【図３】
0004712191.tif 000086
【図４】
0004712191.tif 000087
【図５】
0004712191.tif 000088
【図６】
0004712191.tif 000089
【図７】
0004712191.tif 000090
【図８】
0004712191.tif 000091
【図９】
0004712191.tif 000092
【図１０】
0004712191.tif 000093
【図１１】
0004712191.tif 000094
【図１２】
0004712191.tif 000095
【図１３】
0004712191.tif 000096
【図１４】
0004712191.tif 000097
【図１５】
0004712191.tif 000098
【図１６】
0004712191.tif 000099