JP4500842B2 - ドキュメントベースのトランザクション処理システム及び方法 - Google Patents

Description

本発明は、ネットワークに接続された多様なクライアントの間でのトランザクション（取引）をサポートするシステム及びプロトコルに係り、詳細には、異なるアーキテクチャを有するプラットフォームの間での商取引をサポートするシステム及びプロトコルに関する。

インターネットやその他の通信ネットワークは、コンピュータシステムと人との間の通信のための手段を提供し、それは、例えば参加者によって商品やサービスの売買が行われる商取引などの広範囲な種々のトランザクションに使用されている。インターネット上での商取引を促進させるために多くの努力がなされている。しかしながら、取引を実行するにあたって競合する規格が沢山あることから、その取引の関係者は、用いられるプロトコルに事前に同意しておかなければならないし、かかる取引をサポートするためにはシステム・アーキテクチャをその都度、統合再編することの要求が頻繁に生じていた。合意された規格に適合せず、特定ノードに内在してしまっている商業プロセスは、他のノードとの統合再編のために相当の手直しを必要とするかも知れない。更に、一企業が１つの規格又は他の規格にかかわると、その企業はすでに存在する規格グループの取引集団に固定化され、他の者を排除してしまうことになる。

インターネット商取引の開発に関する挑戦の概要が、「Ｅｃｏ Ｓｙｓｔｅｍ：Ａｎ Ｉｎｔｅｒｎｅｔ Ｃｏｍｍｅｒｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ」 Ｔｅｎｅｎｂａｕｍ他著：Ｃｏｍｐｕｔｅｒ，Ｍａｙ １９９７；４８〜５５ページに記載されている。

インターネット上での商取引をオープンなものにするため、アーキテクチャのフレームワークを標準化することが望ましい。そのような商業的フレームワークをサポートするために開発されたプラットフォームとして、ＩＢＭのＣｏｍｍｅｒｃｅ Ｐｏｉｎｔ；Ｍｉｃｒｏｓｏｆｔ（Ｒ） Ｉｎｔｅｒｎｅｔ Ｃｏｍｍｅｒｃｅ Ｆｒａｍｅｗｏｒｋｓ；ＮｅｔｓｃａｐｅのＯＮＥ（Ｏｐｅｎ Ｎｅｔｗｏｒｋ Ｅｎｖｉｒｏｎｍｅｎｔ）；ＯｒａｃｌｅのＮＣＡ（Ｎｅｔｗｏｒｋ Ｃｏｍｐｕｔｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ）；及びＳｕｎ／ＪＡＶＡ（Ｒ）のソフトＪＥＣＦ（ＪＡＶＡ Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｍｍｅｒｃｅ Ｆｒａｍｅｗｏｒｋ）がある。

これら専有フレームワークに加えて、ＣＯＲＢＡ ＩＩＯＰ（Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｉｎｔｅｒｎｅｔ ＯＲＢ Ｐｒｏｔｏｃｏｌ）をベースとした、共通分散オブジェクトモデルなどのプログラミング技術が推進されている。共通分散オブジェクトモデルの使用は、企業システムの移行を、電子商取引をビジネスアプリケーションレベルで相互利用できるシステムにまで単純化させることを意図したものである。しかしながら、１つのフレームワークしか用いない消費者又はビジネスにとっては、異なるフレームワーク上にある取引（トランザクション）を実行することができない。このことが、電子商取引システムが成長する上での阻害要因となっている。

１つのフレームワークを実行している企業は、他のフレームワークをサポートしているＡＰＩとは異なるアプリケーション・プログラミング・インタフェース（ＡＰＩ）をもつであろう。従って、企業は、共通のビジネス・システム・インタフェースを採用することを要求することなく、ビジネス・サービスを相互にアクセスするのは非常に困難である。ビジネス・システム・インタフェースをＡＰＩレベルで開発することは、関係者間で実際上実現不可能な程の相当の協力を要求してしまうことがある。

したがって、通信ネットワークにおける多様なプラットフォーム間での対話（インタラクション）を容易にするフレームワークを提供することが望まれている。そのようなシステムは、個別の統合再編や産業界の広範囲な規格に前もって同意することなく、取引パートナー間で自発的な取引がなされることを容易にしなければならない。更に、かかるシステムは、ビジネスの自動化に向けて前進する道を切り開き、従来のシステム統合で要されていた多大な時間やコストやリスクを排除するものでなければならない。

全体としては、専有規格をベースとする閉鎖的な商取引相手とのネットワークを、開放されたマーケットに置き換える電子商取引システムを提供することが望ましい。

本発明は、消費者、供給業者（サプライヤー）、及び取引相手とビジネス上の繋がりをもつためのインフラストラクチャ（基盤＝インフラ）を提供する。本発明のインフラストラクチャの下では、取引相手との間で容易に理解可能なことを特徴とするＸＭＬ（拡張マークアップ言語）ベースのドキュメント等の自己定義型でマシン読取り可能なドキュメントを用いて、企業間で情報及びサービスの交換を行う。交換されるべき事項が記述されたドキュメント（以下、ビジネス・インタフェース定義、即ち“ＢＩＤ”と称する）が、インターネット上に送られ、或いは、ネットワークのメンバーに通信される。ビジネス・インタフェース定義（ＢＩＤ）は、潜在的な取引相手に対して、企業が提供するサービスやそのサービスのやりとりの時に使用するドキュメントを知らせる。したがって、典型的なビジネス・インタフェース定義というのは、消費者が購買注文を提出することによって発注することができるようにさせるものであって、当該購買注文は、その購買注文を受取る取引相手のＢＩＤに表れるドキュメント定義に従っていることになる。供給業者は、在庫データを管理するビジネスシステムのＢＩＤに表れるドキュメント定義に従った在庫状況報告をダウンロードすることによって、注文の可能性を確認することが可能である。予め定義された、マシン読取り可能なビジネスドキュメントの使用によって、企業のアプリケーションにアクセスするためのより直観的で柔軟な方法が提供されることになる。

商業ネットワークにおけるノードは、本発明による取引（トランザクション）のためのインタフェースを確立する。この場合、本発明には、インタフェースの仕様のみならず、当該インタフェースを解釈するのに必要な情報をもつマシン読取り可能なデータ構造をも含んでいる。このインタフェースの仕様は入力ドキュメントの定義及び出力ドキュメントの定義を含む。トランザクションプロセッサはその仕様を受け入れ且つ生成し、前記ノードはインタフェースとして動作する。入力及び出力ドキュメントの両定義は、例えば、標準ＸＭＬ系ドキュメントに従い、記憶装置の記述や記憶装置の論理構造の記述のそれぞれを含む。本発明の様々な態様によれば、解釈情報を含むマシン読取り可能なデータ構造は、論理構造の意味定義（例えば、製品名に対するマッピングコード）を提供するために、リスト内の各エントリに対して、入力及び出力ドキュメントの定義における論理構造用のデータ・タイプ仕様（例えば、ストリングやアレイ等）、論理構造用のコンテンツモデル（例えば、取り得る値のリスト）、及び／又は特定の論理構造用の記憶装置をマップするデータ構造を含む。

本発明の他の態様によれば、インタフェースは、ネットワークの少なくとも１つのノードによってアクセス可能なメモリにリポジトリ（これは論理構造のライブラリ及び論理構造の解釈情報を記憶する）を含んでいる。このリポジトリは、入力及び出力ドキュメント定義のライブラリ、インタフェース仕様のライブラリ、及びネットワークにおける参加者インタフェースノードのための仕様のライブラリを含むように拡張することができる。

従って、本発明のトランザクション・フレームワークの参加者は、トランザクションに関係する複数のノード実行プロセスを含むネットワークにおいて、ノード間でのトランザクションを実行する。本発明の方法は、トランザクションのために、インタフェースのマシン読取り可能な仕様を記憶することを含む。その仕様は、入力ドキュメントの定義及び出力ドキュメントの定義を有する。入力及び出力ドキュメントの定義は、それぞれ、記憶装置の記述、及び記憶装置用の論理構造を含む。好ましいシステムでは、それらの定義は、標準ＸＭＬドキュメントタイプ定義であるＤＴＤに準拠したやり方で表現され、セマンティック（意味的）マッピング、コンテンツモデリング、及び幾つかのエレメントのデータタイピングによって拡張される。トランザクションの参加者は、通信ネットワークを通じたドキュメントを含むデータを受信する。参加者は、トランザクションのために記憶された仕様に従いドキュメントを構文解析し、トランザクションのための入力ドキュメントを識別する。ドキュメントの構文解析後、出力を生み出すトランザクションプロセスに、マシン読取り可能なフォーマットの入力ドキュメントの少なくとも一部が提供される。出力ドキュメントは、記憶された仕様の出力ドキュメントの定義に基づき、トランザクションプロセスの出力を含むように形成される。出力ドキュメントは、通信ネットワーク上に送信され、通常は入力ドキュメントのソースに戻されるか、そうでなければ特定のタイプのトランザクションのニーズに合わせられる。

したがって、ビジネス・インタフェースの定義は、例えばＸＭＬによって特定されるドキュメントと、特別のノードにおけるトランザクション処理サービスのフロントエンドで実行されるプログラムとの間のギャップを埋める。そのようなフロントエンドは、例えば、ＪＡＶＡ仮想マシンによって、或いはネットワークを越えて存在するシステム間の相互接続のために提供される他の共通のアーキテクチャによって実現される。ビジネス・インタフェース定義は１つの技術を提供し、この技術により、トランザクション・プロトコルがビジネス・インタフェースを定義したドキュメントを用いてプログラミングされる。トランザクション・プロトコルのためのプログラムは、ドキュメント形式の詳細な正式によって確立される。

トランザクション・インタフェースのマシン読取り可能な仕様は、ネットワークの他のプラットフォームに対してアクセス可能にする。参加者のプラットフォームは、相補的ノードで特定されるトランザクション・インタフェースに従った、入力ドキュメント及び出力ドキュメントを設計するためのリソースを含む。したがって、参加者のノードは、相補的インタフェース用の入力ドキュメント定義、及び相補的インタフェース用の出力ドキュメント定義にアクセスするリソースを含む。アクセスする参加者ノード用に記憶された仕様は、その仕様で記憶した入力ドキュメント定義に、相補的インタフェースの出力ドキュメント定義の少なくとも一部を含むことによって確立される。

本発明の他の態様によれば、インタフェースの仕様を確立するプロセスは、リポジトリから機械読取り可能な仕様の要素にアクセスすることを含む。このリポジトリは論理構造、コンテンツモデル、および論理構造のための概略マップのライブラリ、並びにインタフェース記述を構築するために用いられる論理構造を含んだドキュメント定義を記憶する。ネットワーク上アクセス可能なリポジトリは、容易に共有され得るインタフェース記述の構築を簡単にさせる。特別なプロセス用として生成された入力ドキュメントと、相補的プロセスによるリターンとして期待される出力ドキュメントとの間の相違は、ネットワーク上の通信や、特別な情報を表現するための共通論理構造に同意することによって、乗り越えられる。

本発明の一つの態様によれば、トランザクションのインタフェースのマシン読取り可能な仕様は、ネットワークのメンバー間で共有されるインタフェース・ドキュメントの定義に従うドキュメントを有する。インタフェース・ドキュメントの定義は、特別なトランザクションの識別子、少なくとも一つの定義、そして特別なトランザクションのための入力及び出力ドキュメント定義に対する参照を記憶するための論理構造を有する。すなわち、実際には、特別なサービスに関するインタフェース記述が、入力及び出力ドキュメントの定義を網羅する。あるいはまた、このようなドキュメントの定義に対するリポジトリにおける位置へのポインタであったり、ネットワークのどこかへのポインタを含むことができる。

本発明の他の代替方法によれば、マシン読取り可能な仕様は、インタフェース・ドキュメントの定義に準拠したビジネス・インタフェース定義ＢＩＤドキュメントを含み、前記インタフェース・ドキュメントには、インタフェース識別子を記憶するため、そして少なくとも１つの仕様や、インタフェースによってサポートされる１以上のトランザクションの組の仕様に対する参照を記憶するための、複数の論理構造を有する。サポートされた各トランザクションについて、ドキュメントは、少なくとも１つの定義、並びに特別なトランザクションに対する入力及び出力ドキュメント定義への参照を含む。

本発明の他の態様によれば、入出力ドキュメントの定義で規定された記憶装置は、テキスト文字をエンコードするキャラクタ・データを含む構文解析データ、および入出力ドキュメントの論理構造に従って記憶装置を識別するマークアップデータを含む。本発明の他の態様によれば、記憶装置の組の少なくとも１つは、自然言語をもたらす複数のテキスト文字をエンコードする。これは、ドキュメントの開発者や読み手が、入出力ドキュメントの定義をたやすく使用できるようにする。

本発明の他の態様によれば、入出力ドキュメントの仕様は、論理構造によって識別された記憶装置の組のうちの少なくとも１つに関する解釈情報を含む。この解釈情報は、例えば、構文解析された文字用の定義をエンコードする。別の例では、解釈情報は、コンテンツモデル仕様のために提供される。例えば、カタログの記述を作るためにマップされたコードの多数のリストを扱うために、特定の論理構造を要求したりする。あるシステムの場合、ドキュメントの論理構造にある記憶装置は、特定の実施の必要性にあわせて構文解析されたデータのセットを含む。

本発明の他の態様によれば、特定のプラットフォームでのトランザクションプロセスは、多数の変形トランザクション処理アーキテクチャの１つを有する。したがって、参加者ノードは、情報を用いて、入力ドキョメントの少なくとも一部を、変形トランザクション処理アーキテクチャに従って読み出し可能なフォーマットに変換するためのリソースを含む。ドキュメント定義の要素は、変形トランザクション処理アーキテクチャに従い、変数及び方法を含むプログラミング・オブジェクトに変換される。トランザクションプロセスのフロントエンドとして機能するＪＡＶＡ仮想マシンを有する参加者に対して、ドキュメントの特定のフィールドがＪＡＶＡオブジェクトに変換される。それは、データのみならず、ＪＡＶＡオブジェクトと対応付けられた関数を設定することを含んでいる。本発明に従いサポート可能な他のトランザクション処理アーキテクチャは、Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ ＣＯＲＢＡ，Ｃｏｍｐｏｎｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ ＣＯＭ，Ｏｎ−ｌｉｎｅ Ｔｒａｎｓａｃｔｉｏｎ Ｐｒｏｃｅｓｓｉｎｇ ＯＬＴＲ，およびＥｌｅｃｔｒｏｎｉｃ Ｄａｔａ Ｉｎｔｅｒｃｈａｎｇｅ ＥＤＩという意味で、インタフェース記述言語に従う処理を含む。

本発明の他の態様によれば、複数のトランザクションにおいて使用されるドキュメント形式を記憶するリポジトリが提供される。特別なトランザクション用のマシン読取り可能な仕様は、リポジトリのドキュメント形式を参照することによって、入出力ドキュメントの少なくとも１つを定義する。他の態様によれば、このリポジトリのドキュメント形式は、ネットワークの参加者を識別するためのドキュメント形式を含む。このようなドキュメント形式は、参加者を識別し、その参加者によってサポートされるサービスを特定し、そしてそのようなサービスの各々に対する入出力ドキュメントを特定するため構造を提供する。

上述の方法に加えて、本発明はノード間のトランザクションを管理する装置を提供し、前記ノードには、ネットワーク・インタフェース、トランザクション用インタフェースのマシン読取り可能な仕様を含んだ命令のプログラムやデータを記憶するためのメモリ、およびメモリとネットワーク・インタフェースとに接続されたデータ・プロセッサが含まれている。本装置に記憶された命令のプログラムは、トランザクションの参加者のために、上述したプロセスを実行するロジックを含む。

本発明は、更に、トランザクション処理アーキテクチャに従いトランザクション処理を遂行するデータ処理リソースとネットワーク・インタフェースを備えたシステム上で実行されるトランザクション用の参加者インタフェースを確立するための装置を提供する。本装置は、システムによって実効可能なプログラム命令を含む。そのプログラム命令は、特別のトランザクションの参加者用インタフェース定義を構築するツールを提供するシステムがアクセス可能な媒体に記憶される。参加者インタフェースの定義は、入力ドキュメントの定義及び出力ドキュメント定義を含む。この入出力ドキュメント定義は、記憶装置のための論理構造内で各記憶装置のマシン読取り可能な記述を有し、本発明の１つの態様では、それはＸＭＬドキュメント形式の定義に準拠する。

また、本発明の本態様によれば、参加者インタフェースを確立する装置は、データ処理システムによってアクセス可能な媒体に記憶された命令のプログラムを含み、入出力ドキュメントの定義に応答して、記憶装置の組及びトランザクション・アーキテクチャに準拠した入出力ドキュメントの論理構造に対応するデータ構造をコンパイルする。また、入力ドキュメントを対応のデータ構造に変換するために、システムによって実行可能な命令をコンパイルする。そして、トランザクション処理の出力を、出力ドキュメントの記憶装置の組及び論理構造に変換するために、システムによって実行可能な命令をコンパイルする。

好ましいシステムにおいて、参加者インタフェースの定義を構築するためのツールは、システムによって実行可能な命令を含み、論理構造やインタフェース記述を構築するのに用いられる解釈情報のライブラリを記憶したリポジトリからの、及び/又は相補ノードからの定義要素にアクセスする。本発明の様々な態様によれば、リポジトリは、論理構造のライブラリだけでなく、論理構造を含むドキュメント定義や参加者インタフェースを特定するフォーマットを有している。本発明のこの特徴によって、ビジネス・インタフェースの仕様を構築するためのツールが、参加者ノードの記述に関連する上述の技術に基づき提供される。インタフェースを構築するためのツール、及びこのインタフェースをトランザクション処理アーキテクチャとの通信のために必要とされるリソースにコンパイルするツールが、本発明の好ましいシステムの参加者ノードで実施される。そして、ネットワークの使用が入出力ドキュメントを定義するインタフェース記述に基づいて増大するとき、インタフェース記述の開発及び最適化のために用いられる。

したがって、本発明の別の態様は、メモリと、このメモリに記憶された命令であって参加者インタフェースの定義を構築するツールを含んだ命令を実行するデータ・プロセッサと、上述した機能を達成するコンパイラとを備えた装置を提供する。

本発明の更に別の態様によれば、参加者インタフェース記述の使用は、マーケットメーカー(market maker)のノードが動作することをもたらす。そのようなノードで、インタフェースによってサポートされたトランザクション、及びそのようなトランザクションの各入出力ドキュメントを識別する複数の参加者インタフェースのマシン読取り可能な仕様を記憶することを含むトランザクション管理方法が提供される。上述したように、入出力ドキュメントの定義は、例えばＸＭＬ標準に従い、記憶装置及び記憶装置のための論理構造の各記述を含んでいる。加えて、トランザクションの定義及び参加者インタフェースの定義の全ては、ＸＭＬに準拠した技術或いは他の標準化ドキュメントの表現言語に従って特定されたドキュメントを含んでいる。そのようなマーケットメーカーのノードで、ドキュメントを含むデータが、通信ネットワークを介して受信される。ドキュメントは、仕様に従い構文解析され、入力ドキュメントを受入れる一以上のトランザクションで入力ドキュメントを識別する。識別された一以上のトランザクションに関連するトランザクション処理に対し、入力ドキュメントの少なくとも一部がマシン読取り可能なフォーマットで提供される。入力ドキュメントの少なくとも一部をトランザクション処理に提供するステップは、マーケットメーカーのノードで、処理アーキテクチャに従いルーティング処理を実行することを含む。本発明の一態様の場合、このルーティング処理は、特定の処理アーキテクチャにより実行され、そして入って来るドキュメントの少なくとも一部を、ルーティング処理の処理アーキテクチャのフォーマットに変換する。好ましい態様によると、この変換は、ルーティング処理の処理アーキテクチャに基づいた変数及び方式を有するプログラミング・オブジェクトを生成することを含む。

本発明の別の態様によれば、マーケットメーカーのノードは、リポジトリ構造をサポートする。その結果、マーケットメーカーのノードで記憶されたリポジトリに対して、ネットワークの参加者がアクセスすることができるプロセスを含んでいる。上述したように、リポジトリは、トランザクション・インタフェース・ドキュメントを構築するために、論理構造の定義、解釈情報、及び各参加者ノードが使用するドキュメント定義を含み、そして、参加者を識別するビジネス・インタフェース定義のインスタンス、及び各参加者によって実行されるトランザクションを含む。

様々な代替に基づき、ルーティング処理は、入力ドキュメントを、そのドキュメントの送信先である様々な処理アーキテクチャにあわせて変換することや、元々のドキュメントフォーマットにある入力ドキュメントを、ネットワークを介して遠隔処理ノードに送信すること、或いはそれら変換処理や送信処理の両方を含む。代替として、ルーティング処理は、一つの入力ドキュメント定義に従って定義された入力ドキュメントを、入力ドキュメントを注視する処理のための異なるドキュメント仕様に従って定義される別のドキュメントに変換するための技術を含む。

また、ネットワーク・インタフェース、参加者インタフェース仕様を含む命令のプログラム及びデータを記憶しているメモリ、並びにデータ・プロセッサを含む装置として、マーケットメーカーのノードが本発明に従い提供される。その論理は、命令プログラムの形でデータ・プロセッサによって提供され、そうでなければ上述したようなマーケットメーカーの処理を実行する。

したがって、本発明は、入出力ドキュメントの仕様を共有することに基づき、電子商取引のための基礎を提供する。ドキュメントは、ビジネス・サービスをアクセスするための直感的かつ柔軟性のあるやり方をもたらすものであって、ＡＰＩをプログラミングするよりもより簡単に実施できる。企業間で既に大筋で同意しているならば、企業間の相互接続をドキュメント交換で行おうとする企業の方が、いつも異なるビジネス・システム・インタフェースの構築で実現する企業よりも格段に容易に実施可能である。加えて、好ましい実施例の場合、そのようなドキュメントは、人間が読取りることができるフォーマットで特定される。本発明によれば、ビジネス・インタフェースは、人間並びにコンピュータによって容易に解釈可能なＸＭＬドキュメントなどのドキュメントで特定される。

本発明によるドキュメントをベースとしたトランザクション・アーキテクチャの利用は、ネットワークの各参加者からの情報を抽出しかつ統合・編集するためのカスタム・プログラムに求められる要求を取り除きながら、ドキュメントのあらゆるソースのために基本的には同様の方法で動作する構文解析の使用を含んでいる。よって、会計、購入、製造、配送及び他の機能からの事業情報を統合・編集することは、まず、各ソースを本発明のアーキテクチャを有するドキュメントに変換し、次に、構文解析されたデータ・ストリームを処理することによって達成することができる。マーケットに参加するシステムの各ノードは、その内部システムのフォーマット、並びにトランザクションにあわせてドキュメント変換のために特定される筈のドキュメント・フォーマットについて知ることが要求されるにすぎない。それゆえ、電子商取引ネットワークに参加することを希望する全ての他のノードに固有なフォーマットを生成できるようにする必要性がない。

完全なビジネス統合のために、本発明は、ＸＭＬ要素、属性又はメタデータなどの標準論理構造のリポジトリを提供し、特定の商取引コミュニティのためのセマンティック（意味）言語、異なるメタデータ記述間をマップするための手段、及びドキュメントを処理しかつ適切なアプリケーションやサービスを呼出すためのサーバを設定する。本発明によるネットワークの基本的構築ブロックは、潜在的な取引ビジネスパートナーにどのようなオンライン・サービスを会社が提供し、かつサービスを呼出すためにどのドキュメントを用いるかを通告するビジネス・インタフェース定義と、そして取引コミュニティを生成するために内部／外部のビジネス・サービスの組を互いに結びつける橋渡しを供給するサーバを含む。このサーバは、入力ドキュメントを構文解析し、そして適切なサービスを呼出すよう動作する。また、本発明によるサーバは、各ホスト・システムのフォーマットへ、そして各ホスト・システムのフォーマットから、受信されたり送信されたりするドキュメントのフォーマットの変換タスクを取り扱う。それゆえ、取引パートナーは、交換されるビジネス・ドキュメントの構造や内容や順序のみに同意すればよいのであって、アプリケーションのプログラム・インタフェースの詳細にまで同意する必要はない。サービスを提供するビジネス次第で、ドキュメントがどのように処理されたかが決まり、そしてドキュメントの受信の結果としてもたらされる行動が厳しくにもなる。これは、統合・編集をシステム・レベルからビジネス・レベルへと向上させる。それは、その内部的な技術実装、組織又は処理が変化するにも係わらず、パートナーに対して明瞭かつ安定したインタフェースを提示することができる。

ビジネス・インタフェース定義を構築し、且つ上記記述に従ってサーバが取引を何とかやる全ての処理は、共通のビジネス・ライブラリ、即ちリポジトリによって容易に実現され、リポジトリには、例えば、企業、サービス及び製品、カタログ・購入注文書・請求書などのビジネス形式、日時・場所・商品分類を含む標準指標など、基本的なビジネス記述を含む汎用的なビジネス概念のための情報モデルが記憶されている。

本発明の他の特徴は、以下に説明する図面、詳細な説明、及び特許請求の範囲を考慮することにより理解することができるであろう。

図面との関連で本発明について詳細に説明する。図１は、ビジネス・インタフェース定義の使用に基づき、マーケットメーカー及びマーケット参加者のネットワークを示し、上記インタフェースに従って特定される入出力ドキュメントのやり取りをサポートしている。ネットワークは、インターネット１９などの通信ネットワーク、あるいは他の通信手段またはデータ通信ネットワークを介して相互接続された複数のノード１１〜１８を含む。ノード１１〜１９の各々は、ポータブルコンピュータ、デスクトップパーソナルコンピュータ、ワークステーション、システムネットワーク、あるいは他のデータ処理リソースなどのコンピュータで構成されている。ノードは、ビジネス・インタフェース定義を記憶しておくためのメモリ、ネットワークにおける他のノードとの商取引トランザクションをサポートするトランザクションプロセスを実行するためのプロセッサ、及びそのようなサービスをサポートするために上記プロセッサにより実行されるコンピュータプログラムを含んでいる。さらに、各ノードは、インターネット１９あるいは他の通信ネットワークにわたり通信を提供するためのネットワーク・インタフェースを含む。

図１に示す環境の場合、ノード１１、１２、１３、１４、１６及び１８は、指定されたマーケット参加者である。マーケット参加者は、本発明に基づき確立された商取引トランザクションに従って取引されるべき商品またはサービスの需要者または供給者についてのリソースを含んでいる。
この例では、ノード１５及び１７は、マーケットメーカーノードである。マーケットメーカーノードは、ＢＩＤレジストリと呼ばれるビジネス・インタフェース定義を登録するためのリソースを含む。参加者は、ドキュメントをマーケットメーカーに送ることが可能であり、そこで該ドキュメントは識別され、そのようなドキュメントを入力として受け取るように登録されている適切な参加者に転送される。マーケットメーカーは、ビジネス・インタフェース定義を構築するのに使用する共通ビジネス・ライブラリを構成するための標準形式のリポジトリをもつことにより、商取引ネットワークを手助けする。

この例では、マーケット参加者１８は、インターネット１９を介するよりはむしろ、マーケットメーカー１７に直接接続されている。このマーケットメーカーへの直接接続は、インターネット１９などの公衆ネットワーク、及びローカルエリアネットワークのような私設接続、あるいはノード１７と１８との間に示されているようなポイント−トゥ−ポイント接続を組み入れることにより、商取引トランザクションをサポートするネットワーク構成を極めて多様にし得るということを示す。実際の通信ネットワークはかなり多様であることから、本発明による商取引トランザクションネットワークを確立する上で使用するのが適していると言えよう。

図２は、本発明によるネットワークのマーケット参加者のために確立されたビジネス・インタフェース定義（ＢＩＤ）において、ネスト(nested)構造のヒューリスティックダイアグラムを示す。図２に示されたビジネス・インタフェース定義は、ＸＭＬドキュメントタイプ定義（ＤＴＤ）などのドキュメント構造の形式定義にしたがって整えられた論理構造と記憶装置とで構成されるデータ構造である。図２の構造は、パーティ(party)を識別するための第１の論理構造２００を含む。論理構造２００と関連付けられているのは、名前を送信するためのネスト論理構造２０１と、物理的アドレス２０２と、ネットワークのアドレス又は位置２０３と、一組のサービス・トランザクション２０４とである。サービスセット中の各トランザクションのためには、トランザクションＢＩＤ２０５、２０６、２０７を含むインタフェース定義が提供される。トランザクションＢＩＤ２０５などの各トランザクションＢＩＤの中には、名前２０８と、サービスが実行されるネットワーク上の位置２０９と、サービスにより実行される操作２１０と、及びタグにより示される一組の入力ドキュメント２１１とを含むための論理構造が提供される。また、サービスＢＩＤ２０５は、タグにより示される一組の出力ドキュメント２１２を含む。一組の入力ドキュメント２１１は、入力ドキュメント・ビジネス・インタフェース定義２１３、２１４、２１５など、サービスが応答するよう指定された各入力ドキュメントのためのビジネス・インタフェース定義を含む。入力ドキュメントのための各ビジネス・インタフェース定義は、名前２１６と、ドキュメントの記述を見出し得るネットワーク上の位置２１７と、フィールドにより示されるようなドキュメントにおいて送信されるべきモジュール２１８とを含む。同様の方法で、出力ドキュメントセット２１２は、出力ドキュメントＢＩＤ２１９、２２０、２２１を含む出力ドキュメントのためのインタフェース定義を含む。各出力ドキュメントＢＩＤのために、名前２２２と、ネットワーク上または他の場所の位置２２３と、ドキュメントのモジュール２２４とが特定されている。図２に示されている参加者についてのビジネス・インタフェース定義は、各サービスの入出力ドキュメントのために使用される論理構造の実際の定義や、あるいはその定義を見出し得る位置へのポインタまたは他の参照を含んでいる。

好ましいシステムにおいて、図２のドキュメントは、ＸＭＬドキュメントタイプ定義（ＤＴＤ）で特定されるが、他のドキュメント定義アーキテクチャを使用することもでき、またドキュメントのインスタンスの解釈のために使用する論理構造についての解釈情報を含んでいる。また、トランザクションＢＩＤ、入力ドキュメントＢＩＤ、出力ドキュメントＢＩＤの各々は、ＸＭＬドキュメントタイプ定義に従って特定される。ＸＭＬタイプドキュメントは、マークアップデータ及びキャラクタ・データを含む構文解析データに基づいたシステムの一例である。マークアップデータは、ドキュメント内の論理構造を識別し、そしてキャラクタ・データの組は、論理構造の内容を識別する。加えて、非構文解析データが、様々な目的で、ドキュメントにおいて送信され得る。例えば、ＷＷＷ．Ｗ３．ＯＲＧ／ＴＲ／１９９８／ＲＥＣ−ＸＭＬ−１９９８０２１０において、ＷＣ３ ＸＭＬワーキンググループにより発行されたＥｘｔｅｎｓｉｂｌｅ Ｍａｒｋ−ｕｐ Ｌａｎｇｕａｇｅ ＸＭＬ １．０ ＲＥＣ−ＸＭＬ−１９９８０２１０の仕様書を参照することができる。

したがって、例示したシステムにおいては、ネットワーク中の参加者ノードは、ビジネスシステム及びサービスを、ビジネス上了解され且つ生成されるＸＭＬコード化ドキュメントと相互接続することにより、仮想企業を確立する。例えば、特定のサービスのビジネス・インタフェース定義は、カタログ記入に関する要求のＢＩＤに合致したドキュメントが受信された場合、カタログ記入のＢIＤに合致するドキュメントが返信されることを確立する。また、購入注文のＢＩＤに合致するドキュメントが受信された場合であって、且つそれが受信端末にとって受け入れ可能なものであれば、請求書のＢＩＤに合致するドキュメントが返信されるだろう。本ネットワーク中のノードは、ネットワークにおける任意の所与のシステムの様々なトランザクション処置アーキテクチャに従って確立されたローカルビジネスシステムにＸＭＬドキュメントが入る前に、そのＸＭＬドキュメントを処理する。その結果、本システムは、ＭＩＭＥコード化されたＸＭＬドキュメントの組などの関連するドキュメントの組を復号化し、これを構文解析して、“マークアップメッセージ”のストリームを生成する。このメッセージは、例えば後述するイベント・リスナー・モデルを用いて、適切なアプリケーション及びサービスに送信される。

ビジネス・サービス間で交換されるドキュメントは、より複雑なドキュメント定義が生成されるビルディング(building)・ブロック（共通のビジネス言語）のリポジトリから構築されたＸＭＬ言語を使用して、エンコードされる。このリポジトリは、ビジネス領域に共通な機能および情報に焦点があてられた解釈情報のモジュールを記憶する。なお、ビジネス領域には、例えば、企業・サービス・製品、カタログ・購入注文書・請求書などのビジネス形式、日時・場所などの標準指標、分類コード、及びＸＭＬドキュメントの論理構造のために解釈情報を与えるような基本的なビジネス記述を含む。

ビジネス・インタフェース定義は、本発明に従ってドキュメントを取引するインタフェースを設計するために使用されるスキーマとして機能するより高レベルのドキュメントである。したがって、ビジネス・インタフェース定義は、ＸＭＬに従って特定されるドキュメントと、特定のノードにあるトランザクション処理サービスのフロントエンドで実行されるプログラムとの間のギャップを埋める。このようなフロントエンドは、ＪＡＶＡ仮想マシンよって、或いはネットワークにわたりシステムの内部接続を提供する他の共通アーキテクチャによって実行される。ゆえに、ビジネス・インタフェース定義は、ビジネス・インタフェース定義ドキュメントを用いてトランザクション・プロトコルがプログラムされる技術を提供する。トランザクションのプロトコルのためのプログラムは、ドキュメントタイプの詳細な正式仕様によって確立される。

ＸＭＬフォーマットに適合するマーケット参加ドキュメントに基づいたビジネス・インタフェース定義ＢＩＤの一例は、以下に与えられる。マーケット参加者ＤＴＤは、連絡先および住所情報を、サービスおよび財政情報の記述と関連付けながら、マーケット参加者に関するビジネス情報にグループ分けする。このビジネス情報は、名前、コード、住所、ビジネス組織を示すための専用分類メカニズム、及びビジネス用語へのポインタとから成る。加えて、マーケット参加者ＤＴＤによって識別されるサービスは、参加者がそれに応答し且つ生成することを期待される入出力ドキュメントを特定する。その結果、注釈的なコメントをもつＸＭＬ内で特定されたマーケット参加者ＤＴＤ、サービスＤＴＤ、及びトランザクションドキュメントＤＴＤのための典型的な共通ビジネス言語を用いた、スキーマを定義するドキュメントは、以下のとおりである。

サービスＤＴＤスキーマは、共通ビジネス言語リポジトリのサービスタイプ要素によって、以下のように拡張される。

上記のサービスタイプ要素は、ビジネス・インタフェース定義によってもたらされる解釈情報を示し、本例の場合、有効なサービスタイプのいずれか１つの識別を可能にする内容形式を表す。別の解釈情報はデータ型定義を含み、例えば、内容形式“ｕｒｌ”を含む要素、＜Ｈ３＞Ｉｎｔｅｒｎｅｔ Ａｄｄｒｅｓｓ＜／Ｈ３＞）を、データ型“ｓｔｒｉｎｇ”で表したりする。さらに別の解釈情報は、リスト要素へのコードマッピングを含み、例えば、ファイル「ＣＯＵＮＴＲＹ．ＵＳ．ＳＵＢＥＮＴＩＴＹ」に存在する州に対してのコードマッピングを含む要素、＜Ｈ３＞Ｓｔａｔｅ＜／Ｈ３＞がある。
マーケット参加者ＤＴＤによって照会されるサービス記述は、サービスとしてその競合が受容され、且つ生成されるためのドキュメントを定義することである。基本的なサービス記述は、ＸＭＬドキュメントのｔｒａｎｓａｃｔ．ｄｔｄとして以下で詳述する。
ｔｒａｎｓａｃｔ．ｄｔｄは、請求書等のトランザクション記述、或いは値を交換する記述をモデル化する。このドキュメント型は多くの用途をサポートし、従ってトランザクション記述要素は、請求書、性能、販売の申し出、見積もりの要望等がある中でユーザが他のものと区別して特定できそうな属性を有する。２人以上の関係者間で交換が行われるが、二人のみが申込者とその相手として対象となり、その各人は、上述したマーケット参加者ＤＴＤに一致するドキュメントへのポインタによって表される。販売の申し出を承諾するための相手のポインタは任意である。交換のための記述は、以下に挙げるｔｒａｎｐｒｉｍ．ｍｏｄにおいて示されるように、価格および小計を含んでいる。交換のための記述に続き、取引全体に適用される課金が提供されるようにしてもよく、そして全体の課金を与えなれなければならない。従って、本例におけるトランザクション記述のスキーマドキュメントｔｒａｎｓａｃｔ．ｄｔｄは、以下のように示される。

上記の定義に従って生成される典型的なマーケット参加者およびサービスＤＴＤは、以下の通りである。

＜マーケット参加者ＤＴＤ＞

＜サービスＤＴＤ＞

ｔｒａｎｓａｃｔ．ｄｔｄに従って生成されたドキュメントの一例は次のように示される。

したがって、本発明は、マーケット参加者が自分自身を識別し、そしてビジネスを取引したいと思っている入出力ドキュメントのタイプを識別できるようにする技術を提供する。この取引に対する他の関係者によって或いは一部の関係者によってドキュメントにもたらされた内容が処理されるといった特定のやり方は、ビジネス関係の確立にも取引を行う上でも影響を及ぼさない。

図３は、本発明によるネットワークの参加者ノードの概略図を示している。図３に例示されたノードは、ポート３０１で、通信ネットワークに結合されるネットワーク・インタフェース３００を含む。このネットワーク・インタフェースは、ドキュメントの構文解析器（パーサー）３０１と結合する。パーサー３０１は、入力ドキュメントからの論理構造を変換モジュール（トランスレータ）３０２に供給し、変換モジュール３０２は、入力ドキュメントをホスト取引システムによって使用できる形式へ変換するとともに、その逆のホストプロセッサの出力を、送り先への送信のために、ビジネス・インタフェース定義に規定された出力ドキュメントフォームに一致するドキュメント形式へ変換する。パーサー３０１およびトランスレータ３０２は、参加者モジュール３０３に記憶されたビジネス・インタフェース定義に応答する。

トランスレータ３０２からの出力データ構造は、パーサー３０１によって合図されたイベントと一緒に、取引プロセス・フロントエンド３０４へ供給される。一実施例におけるフロントエンド３０４は、ネットワークの様々なノードの間で通信するのに適したＪＡＶＡ仮想マシン、またはその他の同様のインタフェースから構成される。取引処理フロントエンド３０４は、パーサー３０１およびトランスレータ３０２によって示されたイベントに応答し、企業システムや参加者を結合するネットワークの適当な機能に対して入力データを転送する。その結果、図３に示す取引処理フロントエンド３０４が、コマーシャル・ファンクション３０５、データベース・ファンクション３０６、会計／請求書作成等の他の企業ファンクション３０７と結合し、パーサーが示したイベントに応答するように設計された特定のイベントリスナー／プロセッサ３０８と結合する。

パーサー３０１は、上述したような購入注文、又はビジネス・インタフェース定義に従って特定された他のドキュメントを受け取り、そしてＪＡＶＡ仮想マシン用ＪＡＶＡイベント等のローカル取引処理アーキテクチャによって認識されるイベントを生成する。

本発明のパーサーは、受信されたドキュメントに基づくイベントを知ろうとするリスニングプログラムとは非結合である。受信ドキュメント又はある仕様に適合する完全ドキュメントに存在するマークアップ言語の構成一つ一つは、処理を開始させるリスニング機能のための命令として作用する。したがって、リスニングプログラムは、ドキュメント情報に関連したビジネス論理を実行する。例えば、アドレス要素に関連したプログラムは、データベースをチェックすることによって、郵便コードを認証するコードである。これらのリスナーは、ドキュメントルータに登録しておくことによりエベントに加入し、ドキュメントルータは、関連エベントを興味のあるすべての加入者に差し向ける。

例えば、上述した購入注文は、パーサーが生成したイベントをリスニングするプログラムによってモニタされるものであり、パーサーは、ドキュメントまたはその内容を注文エントリプログラムに接続させる。購入注文の製品記述を受信することは、在庫をチェックするためのプログラムと関係がある。購入注文のアドレス情報を受信することは、配送サービスの可能性をチェックするためのプログラムと関係する。ドキュメントにおける購入者情報フィールドは、注文経緯をチェックしてクレジットを無価値にしているかどうかや、消費者のＩＤを把握していることに基づいて宣伝や同様の処理を申し出るプロセスを呼び出すことができる。

複雑なリスナーは、基本的なリスナーの構成として生成される。例えば、ある購入注文のリスナーは、前段落で述べたリスト・リスナーを含んでいたり呼び出すことができるし、リスト・メンバーは、かれら自身を呼び出すこともできる。リスナーが実行するアプリケーションは、本来のＸＭＬプロセスまたは本来のＪＡＶＡプロセスの可能性が低いことに注意すべきである。これらの場合、オブジェクトは、受信する取引アプリケーションが要求する形式に変換されるであろう。そのアプリケーションが処理を完了するとき、その出力は、ネットワークの他のノードに対する通信のためにＸＭＬフォーマットに変換し直される。

上述したような、マーケット参加者ドキュメントタイプ記述および取引ドキュメントタイプ記述には、ドキュメントの論理要素のための概略マッピングを含むとともに、自然言語に基づくマークアップ言語を含む。自然言語マークアップ、およびＸＭＬの他の自然言語属性は、ビジネス・インタフェース定義・サービス記述・入出力ドキュメント記述の仕様について、ＸＭＬ型マークアップ言語の使用を容易にする。

参加者モジュール３０３は、ビジネス・インタフェース定義を記憶することに加えて、入力ドキュメントの論理構造に一致する取引プロセス・フロントエンド３０４が使用するオブジェクトや他のデータ構造をコンパイルしたり、トランスレータ３０２をコンパイルするために用いるコンパイラを含む。その結果、参加者が関係する取引の変遷に応じて、ビジネス・インタフェース定義がその参加者によって変更されたり更新されたりするとき、トランスレータ３０２及びパーサー３０１は、自動的にアップデートに保たれる。

好ましいシステムにおいては、ＪＡＶＡイベントは、ＳＧＭＬのグローブモデル(grove model)、主として、各エレメント（要素）の“property set”によって拡張された標準のエレメント・ストラクチャー・インフォーメーション・セットに対応するコンパイラによって生成される−Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｔａｎｄａｒｄ ＩＳＯ／ＩＥＣ １０１７９：１９９６（Ｅ），Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ−−Ｐｒｏｃｅｓｓｉｎｇ Ｌａｎｇｕａｇｅ−−Ｄｏｃｕｍｅｎｔ Ｓｔｙｌｅ Ｓｅｍａｎｔｉｃ ａｎｄ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｌａｎｇｕａｇｅ（ＤＳＳＳＬ）。
ＸＭＬドキュメントをプロセスのためイベントに変えることは、パーサーの出力が内部データ構造として維持される構文解析の通常モデルとは異なる。ＪＡＶＡイベント又は、各ノードの取引処理フロントエンドが使用するのに適した他のプログラミング構造に、ＸＭＬドキュメント要素を変換することにより、取引されるべきドキュメントを用いるノードで、豊富な機能性を利用できるようになる。

よって、取引プロセス・フロントエンド３０４は、システムの他のリスニングプログラムについての知識やインパクトが無くても、新たなリスナープログラムを加えることを可能にするパブリッシュ(publish)及び加入者アーキテクチャにおいて動作できる。図３の各リスナー３０５、３０６、３０７、３０８は、フロントエンド３０４がイベントを指揮するキュー(queue)を保持する。これは、多数のリスナーがそれら自身のペース(pace)で併行してイベントを取り扱うことができるようにする。

さらにまた、本発明によれば、リスナーが実行するアプリケーションは、本来のＸＭＬ機能（ファンクション）、または入力ドキュメント形式に一致する本来の機能である必要はない。むしろ、取引プロセス・フロントエンド３０４がＪＡＶＡインタフェースである場合には、これらのリスナーは、ＪＡＶＡ機能であり、或いは固有の取引処理アーキテクチャに従って実行する機能である。これらの場合において、オブジェクトは、受信アプリケーションが必要とする形式に変換されるであろう。リスナーのアプリケーションが完了するとき、その出力は、モジュール３０３におけるビジネス・インタフェース定義が特定するようなドキュメント形式に変換し直される。その結果、トランスレータ３０２は、合成されやドキュメントを出力として提供するために、ネットワーク・インタフェース３００に直接的に結合される。

取引処理フロントエンドに結合されたリスナーは、入力ドキュメントのためのリスナー・入力ドキュメントの特定要素（エレメント）のためのリスナー・入力ドキュメントの特定のエレメントに記憶された属性のためのリスナーを含む。これは、入力ドキュメントをフィルタリングしたり応答するための特定のノードで、取引プロセスの実行を多様化し且つフレキシブルにするものである。

図４は、図３のシステムのための入力ドキュメントを受信し処理するためのプロセスを例示している。したがって、本プロセスは、ネットワーク・インタフェースでドキュメントを受信することで始まる（ステップ４００）。パーサーは、ビジネス・インタフェース定義に応答してドキュメントタイプ（４０１）を識別する。ＸＭＬフォーマットでドキュメントのためのＤＴＤを記憶するビジネス・インタフェース定義を使用して、ドキュメントは構文解析される（ステップ４０２）。次に、ドキュメントの要素（エレメント）および属性は、ホストのフォーマットに変換される（ステップ４０３）。この例では、ＸＭＬ論理構造は、getおよびset関数などのデータに関連した方法とともに、ＸＭＬエレメントのデータをもたらすＪＡＶＡオブジェクトに変換される。次に、ホストオブジェクトは、ホスト取引処理フロントエンドへ転送される（ステップ４０４）。これらのオブジェクトは、パーサーおよびトランスレータによって示されるイベントに応答して、プロセスに送信される。ドキュメント要素を受信するプロセスが実行され且つある出力を生成する（ステップ４０５）。その出力は、ビジネス・インタフェース定義によって定められる出力ドキュメントのフォーマットに変換される（ステップ４０６）。この例では、トランスレーションは、ＪＡＶＡオブジェクト形式からＸＭＬドキュメント形式に遷移する。最後に、出力ドキュメントは、ネットワーク・インタフェースを介して送信先に転送される（ステップ４０７）。

図５は、図３のシステムのためのイベント発生器／イベントリスナーのメカニズムの詳細図をあらわす。一般に、図５に示された手法は、ＪＡＶＡ ＪＤＫ１．１イベントモデルの改良である。このモデルにおいて、３種類のオブジェクトが考慮される。第１のオブジェクトは、イベントの生成に関する情報を含むイベントオブジェクトである。生じ得る異なるイベントの全種類に対応して、任意の数の種類のイベントオブジェクトが有る。第２のオブジェクトは、何かが起こった時に活動をモニタし、イベントオブジェクトを生成するイベント発生器である。第３は、イベント発生器により生成されたイベントオブジェクトを聞くイベントリスナーである。イベントリスナーは一般に、特定のウインドウ上でマウスクリックなどの特定のイベント発生を知ろうとする。イベントリスナーは、イベント発生器上に「イベントリスナーを加える」方法をコールする。このモデルは、図３の環境に適合させることができ、ＸＭＬドキュメントにより代表されるようなオブジェクトのグラフを辿りそして構文解析することに応答して、オブジェクトを発生する。

図５に示されるシステムは、一般的なＸＭＬパーサー５００を有する。このようなパーサーは、標準の呼び戻し(call back)モデルを使用して実現できる。構文解析イベントが発生する時に、パーサーはアプリケーションオブジェクト内で特定の方法を呼出し、パラメータ内の適当な情報を渡す。従って、単一のアプリケーション５０１がパーサーと共に存在する。アプリケーションは、パーサーが提供する情報をＸＭＬイベントオブジェクト内にパッケージし、そしてブロック５０２により示されるように、それを自身により識別された数だけのイベントリスナーに送る。イベント５０２の組は完全にパーサーから独立している。イベント５０２は、どんな数のマシン上のどんな数のリスナーおよびどんな数のスレッドにも供給されることができる。イベントは１つの代替形式においては、エレメント構造情報セット（ＥＳＩＳ）に基づいている。従って、これらはエレメントの開始および終了などのようなドキュメント構造または属性の認識のような重要な観点のリストからなる。ＸＭＬ（そしてＳＧＭＬ）パーサーは一般にＥＳＩＳ構造をパーサーがそのアプリケーションに戻るための情報のデフォルトセットとして使用する。

特定ＥＳＩＳリスナー５０３は、イベント５０２の組に結合される。このリスナー５０３はＥＳＩＳリスナーＡＰＩを実現し、そして１または複数からの発生器からの全てのＸＭＬイベントを聞く。１つのエレメントイベント発生器５０４は特定ＥＳＩＳリスナーで、ＸＭＬイベント発生器でもある。そのリスナーは、特定のタイプのエレメントに対するイベントにのみ興味があるオブジェクトである。例えば、ＨＴＭＬ環境においては、リスナーは指示されたリストのみ、すなわち、＜ＯＬ＞と＜／ＯＬ＞タグの間のドキュメントの部分のみに興味を有する。他の例では、リスナーは上の例のドキュメントから共通ビジネス言語に従って「ｐａｒｔｙ．ｎａｍｅ」エレメントまたは「ｓｅｒｖｉｃｅ．ｎａｍｅ」要素のみを聞き、要素のための図式的マッピングに一致するデータを要素がもたらすことを確実にするために要素を処理し、そして受取ノードにおいて必要とされるプロセスに従って反応する。

これは、システムが、価格を合計するだけのようなドキュメントの特定部分のみを聞く小さいオブジェクトを有することを可能にする。リスナーが発生器からそれら自身を加えるまたは取除くことができるから、ＨＴＭＬドキュメントの例えば＜ＨＥＡＤ＞部分のみを聞くリスナーも存在できる。この理由およびＸＭＬドキュメントの高い反復性の理由により、高い目標的なコードを書くことおよび併発的なリスナーを書くことができる。例えば、＜ＯＬ＞リスナーは＜ＵＬ＞（指示されていないリスト）リスナーがその＜ＬＩ＞リスナーを設定する方法とは完全に分離して＜ＬＩ＞リスナーを設定することができる。代替方法として、図形ユーザインタフェースを発生するリスナーおよび同じ入力を使用するデータベースを探索する別のリスナーを作成できる。従って、アプリケーションが一度に１つずつ検査する完成されたデータ構造とは反対に、ドキュメントはリスナーにより実行されるプログラムとして取扱われる。もし、アプリケーションがこの方法で書かれると、アプリケーションを実行するために全ドキュメントをメモリ内に持つ必要が無い。

イベント５０２の組に結合された次のリスナーは、属性フィルタ５０５である。エレメントフィルタ５０４に似て属性フィルタ５０５は、ＥＳＩＳリスナーモデルに従い属性イベント発生器である。属性フィルタのためのリスナーは、それが興味を持つ属性を指定し、そして、指定された属性を持つあらゆる要素のためのイベントを受取る。例えば、フォントマネージャは例えば＜Ｐ ＦＯＮＴ＝“Ｔｉｍｅｓ Ｒｏｍａｎ”／Ｐ＞のようなフォント属性を持つエレメントのためだけのイベントを受取るだろう。

エレメントイベント発生器５０４は、エレメントリスナー５０４Ａを特殊化するためにそのようなエレメントオブジェクトを供給する。

属性イベント発生器５０５は属性イベントオブジェクトを属性リスナー５０５Ａへ供給する。同様に、属性オブジェクトは一のドキュメント形式から別へ属性を使用してＳＧＭＬ／ＸＭＬ変形する意味で「アーキテクチュア」に供給される。従って、５０５Ｂのアーキテクチュアは、特定の名前を持った特定の属性を識別できるようにする。その定義された属性を持ったエレメントのみが出力ドキュメントの部分になり、そして出力ドキュメント内の要素（エレメント）の名前は、入力ドキュメント内の属性の値である。例えば、もしアーキテクチュア５０５ＢがＨＴＭＬであり、ストリングを、
＜ＰＵＲＣＨＡＳＥＳ ＨＴＭＬ＝“ＯＬ”＞＜ＩＴＥＭ ＨＴＭＬ＝“ＬＩ”＞＜ＮＡＭＥ ＨＴＭＬ＝“Ｂ”＞ＳＴＵＦＦ＜／ＮＡＭＥ＞＜ＰＲＩＣＥ ＨＴＭＬ＝“Ｂ”＞１２３＜／ＰＲＩＣＥ＞＜／ＩＴＥＭ＞＜／ＰＵＲＣＨＡＳＥ＞
変換（翻訳）すると、
＜ＯＬ＞＜ＬＩ＞ＳＴＵＦＦ＜／Ｂ＞＜Ｂ＞１２３＜／Ｂ＞＜／ＬＩ＞＜／ＯＬ＞
となり、正しいＨＴＭＬである。

イベント５０２の組に結合された次のモジュールはツリー（木）ビルダー５０６である。ツリービルダーはＸＭＬイベントのストリームを取り、下部のドキュメントのツリー（木）表現を発生する。ツリービルダー５０６の一つの好ましい形式は、Ｗ３Ｃ（ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／１９９８／ＷＤ−ＤＯＭ−１９９８０７２０／ｉｎｔｒｏｄｕｃｔｉｏｎ．ｈｔｍｌ）の仕様に従ってドキュメントオブジェクトモデルＤＯＭオブジェクト５０７を発生する。イベントストリーム内のリスナーは大部分の要求を処理するのに使用できるが、ツリー形式はドキュメント回りの質問をサポートするため、ノードを再順序付けるため、新ドキュメントの作成、例えばドキュメントを多数回構文解析するような、そこから同じイベントストリームを複数回発生できるメモリ内のデータ構造をサポートするのに役立つ。特定ビルダー５０８は、特定の実施に適合するようなドキュメントの部分の特別なサブツリーを作るために、ツリービルダー５０６に結合できる。

入力するドキュメントに応答するのに加えて、ＸＭＬイベント５０２の他のソースも供給することができる。従って、イベントストリーム５１０は、ＤＯＭオブジェクトのツリー上を歩くことにより、そしてドキュメントが構文解析されていた時に作成された元のイベントストリームを再発生することにより発生される。これは、システムにより、ドキュメントが数回構文解析されている外観を与えることを可能にする。

ツリーを辿りそしてイベントのストリームを発生するオブジェクトの観念は、ＤＯＭオブジェクトのツリーを越えて質問できるオブジェクトのいかなるツリーにも一般化できる。したがって、ＪＡＶＡウォーカー５１２は、ＪＡＶＡビーン(bean)コンポーネント５１３のツリーを辿るアプリケーションでもよい。ウォーカーは全ての公開されているフィールドおよび方法上を辿る。ウォーカーは終わりの無いサイクルに入り込まないことを確保するために、既に訪問したオブジェクトの軌跡を記憶する。ＪＡＶＡイベント５１４は、ＪＡＶＡウォーカー５１２により発生されるイベントのタイプである。これは現在、オブジェクトから引き出すことのできる情報の種類の大部分を含む。これは、ＥＳＩＳのＪＡＶＡの均等物であり、そして、特にＪＡＶＡビーンズであるのだけれども、ＸＭＬに適用されたのと同じプログラム手法をＪＡＶＡオブジェクト一般に適用することを可能にする。

ＸＭＬイベント発生器５１５に対するＪＡＶＡは、ＪＡＶＡリスナーとＪＡＶＡイベント発生器から構成される。これは、ＪＡＶＡウォーカー５１２からイベントのストリーム５１４を受取り、そしてＸＭＬドキュメントとしてＪＡＶＡオブジェクトを供給するために選択されたものを変換（翻訳）する。好ましい実施例において、イベント発生器５１５はＪＡＶＡビーンズＡＰＩを利用する。見られた各オブジェクトはエレメントとなり、エレメント名はクラス名とおなじである。そのエレメント内で、各埋め込まれた方法もまたエレメントとなり、その内容は方法を呼び起こすことにより戻された値である。もしそれがオブジェクトまたはオブジェクトの配列であると、これらは交互に辿られることになる。

図６は、図５のフレームワーク上に構築された特定のアプリケーションの概略図である。このアプリケーションは、ＸＭＬドキュメント６００を取り込み、これをパーサー／発生器（構文解析ルーチン発生システム）６０１に適用する。ＥＳＩＳイベント６０２を発生し、且つ属性発生器６０３及びツリービルダー６０４に供給される。属性発生器は図５の発生器に対応する。この発生器５０５は、イベントを、例えば、ＸＭＬ入力からＨＴＭＬ出力に変換（翻訳）するための“アーキテクチャ”５０５Ｂに送る。これらのイベントは、ブロック６０５によって示される様に並列で処理され、且つリスナーによって処理される。リスナーの出力はドキュメントライター６０６に供給され、出力のためにＸＭＬフォーマットに戻し変換（翻訳）される。従って、例えば、図６に示されるこのアプリケーションは、ＸＭＬドキュメントを取り入れ、或るフォームを有するＨＴＭＬドキュメントを出力する。このフォームは次にブラウザに送られ、その結果がＸＭＬに戻し変換される。この運用のために、アーキテクチャコンセプトは、ＸＭＬからＨＴＭＬへのマッピングを提供する。図６に含まれる３つのアーキテクチャは、テーブル及びリストなどのＨＴＭＬドキュメントの構造を与えるためのもの、ブラウザドキュメント上の入力フィールド用のラベルなどの表示されるべきドキュメントを特定する第２のもの、及び入力フィールド自体を記述する第３のものを含む。ＸＭＬドキュメント構造を維持するのに必要となるＸＭＬドキュメントのエレメントは、ＨＴＭＬフォーム内では不可視のフィールドとなる。このことは、サーバに送り戻されるＨＴＴＰポストメッセージにクライアントが入れる情報からＸＭＬドキュメントを再構成する際の使用に有用である。これらのイベントを聴取するリスナーが、ＨＴＭＬドキュメント用のイベントを出力する。このドキュメントは、ドキュメントライターオブジェクトへと進む。ドキュメントライターオブジェクトはＸＭＬイベントを聴取し、それらをＸＭＬドキュメントに戻す。ドキュメントライターオブジェクトは、この例におけるアーキテクチャを聴取している全てのエレメント発生器に対するリスナーである。

図５及び６に図示される処理モジュールの構成は、図３のシステム用のパーサー及びトランザクションプロセスフロントエンドの或る実施の形態を表している。理解できる様に、極めて柔軟性のあるインタフェースが与えられ、これによってダイバース（変更）トランザクションプロセスを、入力するＸＭＬドキュメント、又は他の構造化ドキュメントフォーマットに応答して、実行することができる。

図７は、ビジネス・インタフェース定義ビルダーモジュール７００を含むことを除いて、図３と類似のノードを図示している。従って、図７のシステムは、ネットワーク・インタフェース７０１、ドキュメントパーサー７０２、及びドキュメントトランスレータ７０３を含む。トランスレータ７０３は、その出力をトランザクション処理フロントエンド７０４へ出力する。このフロントエンドは、コマーシャル機能部７０５、データベース７０６、エンタープライズ機能部７０７、及び他の一般リスナー及びプロセッサ７０８のようなリスニング機能に結合される。図７に図示される様に、ビジネス・インタフェースビルダー７００は、ユーザインタェース、共通ビジネス・ライブラリＣＢＬリポジトリ、相補的ビジネス・インタフェース定義を読むためのプロセス、及びコンパイラを含む。ユーザインタフェースは、ビジネス・インタフェース定義の構築における計画を、共通ビジネスライブラリリポジトリ及び相補的ビジネス・インタフェースの定義を読み出す能力に依存して、補助するのに使用される。従って、相補的ビジネス・インタフェース定義の入力ドキュメントは、特定のトランザクションの出力ドキュメントとして特定することができ、相補的ビジネス・インタフェース定義の出力ドキュメントがトランザクションプロセス等の入力として特定することができる。同様なやり方で、トランザクションビジネス・インタフェース定義は、ＣＢＬリポジトリから選択された構成要素を使用して構成することができる。ＣＢＬリポジトリの使用は、上述の例示スキーマ（ｂｉｄ１）ドキュメントなどの標準ドキュメント形式、及びネットワーク内の他の人間によって容易に採用されることのできるビジネス・インタフェース定義を構築することにおける論理構造及び解釈情報の使用を容易くする。

ビジネス・インタフェース定義ビルダー７００は、トランスレータ７０３、ホストトランザクション処理アーキテクチャに従って、トランスレータによって処理されるべきオブジェクトを発生し、構文解析機能７０２を管理するために使用されるコンパイラも含む。

図８は、ビジネス・インタフェース定義ビルダー７００のリポジトリ内に記憶される論理構造を示すヒューリスティックダイアグラムである。したがって、パーティビジネス・インタフェース定義８００を表すリポジトリ記憶は、例えば、消費者ＢＩＤ８０１、カタログハウスＢＩＤ８０２、ウェアハウスＢＩＤ８０３、及びアクションハウスＢＩＤ８０４を含む。したがって、オンラインマーケットにおける新たな参加者は、そのビジネスと最もよく適合する標準化されたＢＩＤの一つを、基本インタフェース定義として選択する。更に、リポジトリは一組のサービスビジネス・インタフェース定義８０５を記憶する。例えば、注文エントリＢＩＤ８０６、注文トラッキングＢＩＤ８０７、注文履行ＢＩＤ８０８、及びカタログサービスＢＩＤ８０９を記憶することができる。マーケットにおける新たな参加者がビジネス・インタフェースの定義を構築する際に、リポジトリ内に記憶される標準化されたサービスのビジネス・インタフェース定義を選択することができる。

パーティ及びサービスＢＩＤに加えて、入力及び出力ドキュメントＢＩＤを、フィールド８１０によって指示されるリポジトリに記憶する。したがって、購入注文ＢＩＤ８１１、請求書ＢＩＤ８１２、見積り要求ＢＩＤ８１３、製品入手可能リポートＢＩＤ８１４、及び注文状態ＢＩＤ８１５をリポジトリに記憶することができる。

リポジトリは、好ましいシステムにおいては、ＸＭＬに従ったドキュメント形態の定義として特定されるビジネス・インタフェースの定義に加えて、フィールド８１６によって指示されるようなセマンティック（意味）マップの形態で解釈情報を記憶する。したがって、重量８１７、通貨８１８、サイズ８１９、製品識別８２０、及び製品特徴８２１を特定するために使用されるセマンティックマップをリポジトリ内に記憶することができる。更に、解釈情報は、ドキュメントの論理構造内のデータ構造を分類分けを提供する。

更に、ビジネス・インタフェースの定義を構成する際に使用される論理構造は、ブロック８２２によって指摘されるリポジトリに記憶される。したがって、アドレス情報８２３を与えるためのフォーム、価格情報８２４を与えるためのフォーム、契約上関係の期間８２５を与えるためのフォームを提供することができる。ネットワークが拡張される時、ＣＢＬリポジトリも同様に拡張し、標準化は、新たな参加者が加わること及びビジネス・インタフェースの定義をより容易にする。

図９は、図７のシステムを使用するビジネス・インタフェース定義を構築するプロセスを図示している。プロセスは、ＢＩＤビルダー・グラフィカルインタフェースをユーザに表示することによって開始する（ステップ９００）。システムは、グラフィカルインタフェースによって発生させた参加者、及びサービス／ドキュメント情報を識別するユーザ入力を受信する（ステップ９０１）。

次に、ユーザ入力に応答して、参照論理構造、解釈情報、ドキュメント定義、及び／又はサービス定義が、グラフィカルユーザーインタフェースを介してリポジトリから検索される（ステップ９０２）。次のステップで、相補的ビジネス・インタフェース定義又はビジネス・インタフェースの定義の構成要素が、カスタム化された検索エンジン、ウェブブラウザ、又は他の方法によって、ユーザ入力を介して選択されたネットワーク内の他の参加者からアクセスされる（ステップ９０３）。参加者に対するドキュメントの定義を、集められた情報を使用して発生させる（ステップ９０４）。コンパイラは、ドキュメントからホストへ、及びホストからドキュメントのマッパー(mappers)に対するトランスレータを発生させる（ステップ９０５）。また、コンパイラは、定義に対応するホスト・アーキテクチャデータ構造を発生させる（ステップ９０６）。そして発生されたビジネス・インタフェースの定義は、ウェブサイト又は他の場所にポスト送付することによりネットワーク上にポスト送付され、ネットワーク内の他のノードにアクセス可能とされる。（ステップ９０７）。

ビジネス・インタフェースの定義は、潜在的な商業パートナーに対して企業が提示したオンライン・サービスを伝え、且つこれらのサービスを実施するのに使用するドキュメントを伝える。したがって、ビジネス・インタフェースの定義で定義したサービスが、ドキュメントによって定められる。このことは、ＸＭＬサービス定義の以下に示す部分に例示されている。

このＸＭＬ部分（ｆｒａｇｍｅｎｔ）は、２つの処理からなるサービス、すなわち、１つは注文（ｏｒｄｅｒ）を取得する処理、及びもう１つはそれに追従する処理を定義する。それぞれの定義は、もし正当な要求が特定のＷｅｂアドレスに提示されたなら、サービスを実行するための契約（ｃｏｎｔｒａｃｔ）又は約束（ｐｒｏｍｉｓｅ）を表現する。ここで注文サービスは、リポジトリに置かれた標準の“ｐｏ．ｄｔｄ”ＤＴＤ（Ｄｏｃｕｍｅｎｔ Ｔｙｐｅ Ｄｅｆｉｎｉｔｉｏｎ）に一致する入力されるドキュメントを必要とする。それは、ローカルであっても、或いはネットワーク上の産業に関係する広範囲なレジストリ内に記憶されたものでもよい。もし１つのノードがその注文を実行できるなら、そのノードは、その定義がローカルなカスタマイズされた「ｉｎｖｏｉｃｅ．ｄｔｄ」に一致するドキュメントを返すであろう。実際には、企業は、宣言されたＸＭＬ仕様に一致する購入注文を提出できる誰とでも、ビジネスを行う約束をしている。事前の調整は不要である。

ＤＴＤは、所定のタイプのドキュメントのための正式仕様すなわち文法であり、それは、要素、属性、及び表示されなければならない状態を記述する。例えば、購入注文は、典型的には、購入者及び販売者の名前や住所、一組の製品説明、並びに価格や配達日などの関連する売買条件を含む。電子データ交換（Ｅｌｅｃｔｒｏｎｉｃ Ｄａｔａ Ｉｎｔｅｒｃｈａｎｇｅ，ＥＤＩ）は、例えばＸ１２ ８５０仕様では、購入注文のために普通に使用されるモデルである。

リポジトリは、多くのビジネス領域に対し、再使用可能であって且つ共通のセマンティック（意味的な）構成要素から、ＸＭＬドキュメントモデルを開発することを容易にする。そのようなドキュメントは、たとえそれらが全く異なっていると見えても、共通のメッセージ要素から理解することができる。これは、共通ビジネスライブラリリポジトリの役割を果たしている。

共通ビジネスライブラリリポジトリは、以下のものを含む汎用的ビジネス概念のための情報モデルからなる。即ち、
・企業、サービス、及び製品のようなビジネス記述プリミティブ、
・カタログ、購入注文、及び請求書のようなビジネス形式、
・日時、位置、分類コードなどの標準の指標、
である。

この情報は、企業がＸＭＬアプリケーションを迅速に開発するためにカスタマイズ化し且つ組み立てができる拡張可能な公式のＸＭＬ構成ブロックとして表わされる。アトミック（ａｔｏｍｉｃ）なＣＢＬ要素は、国・通貨・住所・時間に関する標準ＩＳＯコードなどのメッセージ規格及び協定を実装する。低レベルのＣＢＬセマンティクス（意味論）は、Ｄｕｂｌｉｎ Ｃｏｒｅ等のインターネット・リソースのメタデータ構成を分析することからも得られる。

次のレベルの要素は、これらの構成ブロックを使用して、ＯＴＰ（Ｏｐｅｎ Ｔｒａｄｉｎｇ Ｐｒｏｔｏｃｏｌ）及びＯＢＩ（Ｏｐｅｎ Ｂｕｙｉｎｇ ｏｎ ｔｈｅ Ｉｎｔｅｒｎｅｔ）等の既にあるインターネット規格で使用されるビジネス形態だけでなく、Ｘ１２ ＥＤＩ取引で使用されるような基本的なビジネス形態も実装する。

ＣＢＬの焦点は、全てのビジネス領域（企業・サービス・製品などの基本的なビジネス記述；カタログ・購入注文・請求書などのビジネス形式；標準指標・日時・位置・分類コード）に共通の機能及び情報にある。ＣＢＬは、意味論のための規格又は業界協定上に構築されている（例えば、ヨーロッパでの「日／月／年」に対してアメリカでの「月／日／年」を特定するルールは、別個のＣＢＬモジュールでエンコードされてしまう）。

ＣＢＬは、アプリケーションを設計するために使用される言語である。それは、ＸＭＬの“ドキュメント世界”と、ＪＡＶＡの“プログラミング世界”或いは他の取引処理アーキテクチャとの間のギャップを埋めるように設計されている。スキーマは、“ドキュメントを備えたプログラミング”の思想を具体化する。その思想においては、ドキュメントタイプの詳細な正式仕様は主なソースであり、当該ソースから多くの関連する形式が生成される。これらの形式は、ＣＢＬ、ＪＡＶＡオブジェクト、対応のＪＡＶＡオブジェクトへ／対応のＪＡＶＡオブジェクトからＸＭＬインスタンスを変換するためのプログラム、及びサポート・ドキュメントのためのＸＭＬ ＤＴＤを含む。

ＣＢＬは単一のソースを生成し、そこからシステムのほとんど全ての部分が自動的にコンパイラによって生成される。ＣＢＬはＳＧＭＬ／ＸＭＬを拡張することによって機能し、それは、特定のドキュメントタイプの構造を正式に定義するため、そしてそれぞれの情報の要素及び属性と関連するセマンティクス（意味的な）仕様を含むために、使用されるのが通常である。任意の種類のデータ型を宣言するために、ＳＧＭＬ／ＸＭＬにおける（ほとんどの）制限キャラクタタイプを拡張することができる。

以下は、“ｄａｔｅｔｉｍｅ”モジュール用のＣＢＬ定義からの一部である。

この一部には、要素“ｙｅａｒ”が、キャラクタ・データとして定義され、“ｓｃｈｅｍａ”属性と関連する。また、キャラクタ・データは、ＩＳＯ８６０１規格の３．８章である”ｙｅａｒ”用のスキーマを定義する。

この“ｄａｔｅｔｉｍｅ”ＣＢＬモジュールは、実際にはスキーマＤＴＤのインスタンスとして定義される。最初に、モジュール名が定義される。次に、“ｄａｔｅｔｉｍｅ”要素の“ＹＥＡＲ”は、ＩＳＯ８６０１規格の意味に結びつけられる。

また、上述した例示のマーケット参加者及びサービスモジュールは、ＣＢＬリポジトリ中に記憶される。

図１０では、航空貨物受取証（Ａｉｒｂｉｌｌ）１０００が、一般的な購入注文ＤＴＤ１００１をカスタマイズし、出荷重量１００２についての具体的な情報を追加することによって定義されている。一般的な購入注文１００１は、当初、住所、日時、通貨、販売者及び製品記述のためのＣＢＬモジュールから徹底的に組み立てられるものだった。ＣＢＬを使用することにより、ＸＭＬ商用アプリケーションの実現は格段にスピードアップされる。より重要なことは、ＣＢＬによって、商用アプリケーションを相互接続することが簡単になるということである。

ＣＢＬでは、ＸＭＬはスキーマにより拡張される。この拡張は、内容を簡単に認証できるようにするため、ＸＭＬ要素に対する強い型付けを追加する。例えば、＜ＣＰＵ ｃｌｏｃｋ ｓｐｅｅｄ＞と呼ばれる要素（エレメント）は、一組の有効値｛１００，１３３，１６６，２００，２３３，２６６Ｍｈｚ｝を有する整数として定義することができる。また、スキーマは、情報をクラスの定義から簡単にインスタンス生成化できるようにするため、クラス−サブクラスの階層化を追加する。例えば、ラップトップは、ディスプレイのタイプ及びバッテリ寿命等の特徴のための追加タグを有するコンピュータとして記述されることができる。これらの拡張及び他の拡張により、ＸＭＬと伝統的なオブジェクト指向及びリレーショナルデータモデルの間の自動変換だけでなく、データ入力も容易になる。

その結果、上述したように、完成されたＢＩＤは、参加者及びサービスの実際のインスタンス、ＤＴＤインスタンスの論理構造に一致するＪＡＶＡビーンズ（ｂｅａｎｓ）、及びＸＭＬからＪＡＶＡ／ＪＡＶＡからＸＭＬに変換する変換コードのためのＤＴＤを作り出すコンパイラを介して実行される。他のシステムでは、オブジェクトを使用しやすくするために、ユーザインタフェース上のディスプレイのために、或いはユーザによる印刷のために、ドキュメントが生成される。

上述した例示のマーケット参加者及びサービスＤＴＤについて、コンパイラが生成したＪＡＶＡビーンズは、（簡潔のためいくつかの修正を加えて）以下のように示される。

上記したＪＡＶＡビーンに加えて、変換コードは以下に示されているように、ＪＡＶＡからＸＭＬへ、及びＸＭＬからＪＡＶＡへ変換するため作られる。

ドラッグ(drag)、ドロップ(drop)、及びフォーム編集のユーザインタフェースを提供するＢＩＤ構成アプリケーションと一緒にツールを使用して、開発者は、ビジネス・インタフェース定義を作り出したり、その上手く生成された有効なビジネス・インタフェース定義を、ＸＭＬドキュメント形式で生み出すことができる。したがって、例示の実行インスタンスは、ＩＢＭからラップトップコンピュータを注文するために、イングラム・マイクロ（Ｉｎｇｒａｍ Ｍｉｃｒｏ）及びその他が使用するＩＢＭのための注文サービス用のビジネス・インタフェース定義である。（出願人と、ＩＢＭ又はイングラム・マイクロの間には関係はない。）これらのプロセスを利用すると、ユーザは、本発明に従って定義されたドキュメントを使用して、ビジネス・インタフェースのプログラミングを可能とするシステムを構築することができる。

ＸＭＬ／ＪＡＶＡ環境における本発明のＣＢＬ及びＢＩＤプロセッサの役割は、購入注文の以下に示す処理の説明によりさらに理解できるであろう。

会社Ａは、ＣＢＬ ＤＴＤ及びモジュールのライブラリを含む可視化プログラム環境を使用してその購入注文ドキュメントを定義する。共通のビジネス言語エレメントを使用してすべて定義され、データ型及び他の解釈情報が含まれるようになっている。会社Ａの購入注文は、ＣＢＬライブラリに付属する一般的な取引ドキュメント仕様に対して僅かなカスタマイズを含むかもしれないし、或いは、住所、日時、通貨等のためのＣＢＬモジュールから徹底的に構築することもできる。

（上述したｔｒａｎｓａｃｔ．ｄｔｄのような）一般的な“取引ドキュメント”仕様のためのドキュメントは、ＣＢＬ仕様がモジュールから作られ、そして他のＣＢＬ ＤＴＤと内部連結されるやり方の特徴をあらわしている。

コンパイラは購入注文の定義を受取り、幾つかの異なる目標形式を発生させる。これらの目標形式のすべては、本来の仕様の“ツリー対ツリー（ｔｒｅｅ ｔｏ ｔｒｅｅ）”変換を介して得ることができる。この例にとって最も重要なのは、
（ａ）購入注文のためのＸＭＬ ＤＴＤ、
（ｂ）購入注文のためのデータ構造を含むＪＡＶＡビーン（ＪＡＶＡクラス、引数、データ型、メソッド、及び購入注文のスキーマ定義における情報に一致して作り出された例外の構造。）、
（ｃ）購入注文ＤＴＤに準拠する購入注文を、購入注文ＪＡＶＡビーンに変換したり、或いはそれらをデータベースにロードしたり、或いはブラウザに購入注文を表示するＨＴＭＬ（又はＸＳＬスタイルシート）を作り出す“マーシャリング(marshaling)”プログラム、
（ｄ）購入注文ＪＡＶＡビーンからデータ値を抽出し、それらを購入注文ＤＴＤに準拠したＸＭＬドキュメントに変換する“アンマーシャリング(unmarshaling)”プログラム、である。
今、シナリオに戻ると、購入アプリケーションは、購入注文を受け入れる供給者のためのサービスインタフェースとして特定されたＤＴＤに従う購入注文を発生させる。

パーサーは購入注文ＤＴＤを使用して、購入注文インスタンスを、エレメント及びそれが含む属性値についての情報ストリームに分解する。次に、これらの“property sets”は、ＪＡＶＡコードと重ねることにより、対応のＪＡＶＡイベントオブジェクトに変換される。実際、この変換は、ＤＴＤによってその文法が定義される顧客プログラム言語にある命令として、マークアップＸＭＬドキュメントの一部を取り扱う。これらのＪＡＶＡイベントは、コンパイラにより生成されたマーシャリングアプリケーションにより処理することができ、ＪＡＶＡビーンのデータ構造を“ロード”する。

ＸＭＬドキュメントをＪＡＶＡアプリケーションのための一組のイベントに変換し処理することは、パーサーの出力が内部データ構造として維持され、且つ構文解析が完了するまで処理が開始しない通常のモデルの構文解析とは異なるものである。ＢＩＤ定義に応じて、イベントをベースとした処理が、プロセッサの非常に優れた機能性を利用可能にする鍵となる。なぜなら、最新のドキュメントアプリケーション処理が、最初のイベントが発せられるとすぐに開始できるからである。

様々なタイプのイベントを“聞く”ＪＡＶＡプログラムは，それらのイベントのスキーマ定義から形成される。これらのリスナーは，ＣＢＬのＸＭＬ定義と関連するビジネス論理を実行するために作り出されたプログラムであり、例えば、“アドレス”エレメントと関連し、データベースをチェックすることにより郵便コードを認証するコードであってもよい。これらのリスナーは、ドキュメントルータによって登録することによりイベントに“加入”し、それらに興味を示したすべての加入者に対して関連のイベントを差し出す。

この情報提供（パブリッシュ：publish)及び加入アーキテクチャは、新規のリスナープログラムが既存のプログラムに対して何の知識もなく、或いはインパクトを与えることもなく加えられることができる。各リスナーは、ルータがそのイベントを指揮するキュー(queue)を有し、複数のリスナーがそれら自身のペース(pace)で併行してイベントを取り扱うことができるようにする。

例示の購入注文に関し、以下に示すもののためのリスナーがある。
・注文入力プログラムに接続する購入注文、
・在庫をチェックする製品説明書、
・宅配便又は他の配送サービスの可能性をチェックするアドレス情報、
・注文経緯をチェックすることができる購入者情報（クレジットを無価値にしているかどうかや、誰が消費者であるかを把握していることに基づいて宣伝や同様の処理を申し出ることのために）。

複雑なリスナーは、基本的なリスナーの構成として生成される。例えば、ある購入注文のリスナーは、これらのリスナーを含んでいたり呼び出すことができるし、彼らはかれら自身を呼び出すこともできる。）

図１１は、図１のネットワークにおけるマーケットマーカのノードを示している。マーケットマーカのノードは、図３のシステムの基本構造を含み、ネットワーク・インタフェース１１０１、ドキュメントパーサー１１０２、ドキュメントからホストへ／ホストからドキュメントへのトランスレータ１１０３、この例ではルータと称されるフロントエンド１１０４を有する。この例でのマーケットマーカモジュール１１０５は、一組のビジネス・インタフェース定義、又はマーケットの参加者のためマーケットマーカの機能をサポートするのに十分な他の識別子、ＣＢＬリポジトリ、及びマーケットの参加者の要求をすべて満たすコンパイラを備えている。ルータ１１０４は、参加者のレジストリ及びドキュメントフィルタを備え、それらはトランスレータの出力及びパーサーが生成したイベントに応答し、参加者のレジストリに従って且つＸＭＬイベント発生器に対するリスナーの間のエレメント及び属性フィルタに従って、入力ドキュメント転送する。したがって、マーケットのある参加者は所定のパラメータに適合するドキュメントを受信するよう登録することができる。例えば、特定のＤＴＤに従う入力ドキュメントは、ある閾値以上に購入された製品数、又は購入されるドキュメント要求の最大価格等の属性を含み、ルータ１１０４でドキュメントをフィルタするために使用される。次に、ルータ１１０４で参加者レジストリに登録された情報に合致するドキュメントだけが、登録された参加者に送られる。

また、ルータ１１０４は、ローカルホストサービス１１０５,１１０６の要求を満たし、例えば、マーケットマーカのみならずマーケットの参加者として動作する。通常、ルータ１１０４により受信されたドキュメントは、送信先を決定するために追跡され、追跡されるべきそのようなドキュメントはその送信先に送られる。そして、再度、必要であれば、トランスレータ１１０３を経由して戻され、ネットワーク・インタフェース１１０１からそれぞれの送信先に送られる。

マーケットマーカは一組の内部及び外部ビジネス・サービスを一緒に結びつけるサーバであり、仮想企業又は取引コミュニティを作り出す。サーバは入力ドキュメントを解析し、例えば、製品データのための要求をカタログサーバに渡すことにより、又は購入注文をＥＲＰシステムに送ることにより、適切なサービスを呼び出す。また、サーバは変換（翻訳）タスクを処理し、企業のＸＭＬドキュメントからの情報を、取引パートナーが使用するドキュメント形式に、そしてそのレガシーシステムが要求するデータ形式にマッピングする。

上記サービスの定義に関して、企業が購入注文を提示したとき、サーバのＸＭＬパーサーは、購入注文ＤＴＤを使用して購入注文インスタンスを情報イベントのストリームに変換する。次に、これらのイベントは所与のタイプのイベントを処理するようプログラムされた任意のアプリケーションに送られる。ある場合に、インターネットを介して異なるビジネスに情報を完全に送る。購入注文の例では、幾つかのアプリケーションはパーサーからやってくる情報で機能する。
・注文入力プログラムは、完全なメッセージとして購入注文を処理する。
・ＥＲＰシステムは、その購入注文に記述された製品の在庫をチェックする。
・顧客データベースは、顧客のアドレスを検証したり更新したりする。
・運送会社はアドレス情報を使用し、配送を計画する。
・銀行はクレジットカード情報を使用し、トランザクションを許可する。

取引パートナーは、彼らが交換するビジネスドキュメントの構造、内容及び順序について同意するだけでよく、ＡＰＩの詳細について同意する必要はない。ドキュメントがどのように処理されるか、どのようなアクションが結果として生じるかは、完全にサービスを提供するビジネス次第である。これは、システム・レベルからビジネス・レベルへの統合・編集を向上させる。それは、内部的な技術の遂行上、組織化上、又はプロセス上でビジネス変更があるにもかかわらず、明瞭で安定したインタフェースをそのビジネスパートナーに提供することを可能にする。

図１２、１３及び１４は、図１１のシステムのマーケットメーカーノードで実行されるプロセスを示している。図１２において、ネットワーク・インタフェースで、発信参加者ノードからの入力ドキュメントを受信する（ステップ１２００）。ドキュメントがパースされる（ステップ１２０１）。そのドキュメントをホストのフォーマットに変換する。例えば、ＸＭＬからＪＡＶＡへと変換する（ステップ１２０２）。次に、ホストのフォーマット化されたイベント及びオブジェクトをルータサービスに送信する（ステップ１２０３）。ドキュメントのタイプや内容に従いドキュメントを受入れるために登録されたサービスを識別する（ステップ１２０４）。ドキュメント及びドキュメントの一部が、その識別されたサービスに送られる（ステップ１２０５）。ドキュメントの内容に応じてサービスを実行する（ステップ１２０６）。そのサービスの出力データが作られる（ステップ１２０７）。その出力データをドキュメントフォーマットに変換する。例えば、ＪＡＶＡフォーマットからＸＭＬフォーマットへ変換する（ステップ１２０８）。最後に、出力ドキュメントを参加者ノードに送る（ステップ１２０９）。

登録サービスは、ルータが管理する機能の一つである。したがって、図１３に示すように、マーケット参加者ドキュメントがネットワーク・インタフェースで受入れられる（ステップ１３００）。マーケット参加者ドキュメントは、マーケットメーカーノードのためにビジネス・インタフェース定義リポジトリに記憶される（ステップ１３０１）。加えて、ドキュメントが構文解析される（ステップ１３０２）。構文解析されたドキュメントをホストのフォーマットに変換する（ステップ１３０３）。次に、そのドキュメントをルータサービスに送る（ステップ１３０４）。ルータサービスは、ドキュメントのタイプ及びドキュメントの内容に従い、上記登録サービスをドキュメントの宛先であるとして識別するリスナーを含む（ステップ１３０５）。ドキュメント及びドキュメントの要素（エレメント）を登録サービスに送る（ステップ１３０６）。登録サービスにおいて、ビジネス・インタフェース定義に従い、必要とされるサービス仕様を検索する（ステップ１３０７）。ステップ１３０８で、サービス仕様が集められた場合には、ビジネス・インタフェース定義及びサービス仕様に従ってルータサービスフィルタがセットされる（ステップ１３０９）。登録に対する肯定応答のデータが生成される（ステップ１３１０）。この肯定応答のデータをドキュメントフォーマットに変換する（ステップ１３１１）。最後に、マーケットメーカーで登録が上手くいったことを参加者に通知するために、肯定応答のドキュメントを参加者ノードに送信する（ステップ１３１２）。

ステップ１３０７で、必要なサービス仕様を集めるプロセスが図１４の一例として示されている。このプロセスは、マーケット参加者によりサポートされるサービスビジネス・インタフェース定義を探し出すことにより開始する（ステップ１４００）。例えば、リポジトリノードに対するＥメールトランザクション又はウェブアクセスにより、サービス定義を検索する（ステップ１４０１）。サービス仕様がＢＩＤリポジトリに記憶される（ステップ１４０２）。サービスビジネス・インタフェース定義ドキュメントが構文解析される（ステップ１４０３）。構文解析されたドキュメントをホストのフォーマットに変換する（ステップ１４０４）。次に、ホストのオブジェクトがルータサービスへ送られる（ステップ１４０５）。ドキュメントのタイプ及び内容に従い、登録サービスを識別する（ステップ１４０６）。最後に、図１３のプロセスによる使用のために、サービスビジネス・インタフェース定義ドキュメントの情報が、登録サービスに送られる（ステップ１４０７）。

図１５は、本発明により、マーケットメーカーノードでの入力データを処理するプロセッサ、コンポーネント及びシーケンスを示した図である。マーケットメーカーノードは、ネットワーク・インタフェースで通信エージェント１５００を有する。通信エージェントはＸＭＬパーサー１５０１と接続し、ＸＭＬパーサー１５０１は、イベントをＸＭＬプロセッサ１５０２に供給する。ＸＭＬプロセッサ１５０２は、イベントをドキュメントルータに供給する。ドキュメントルータは、ドキュメントサービス１５０４にそれを入力する。このドキュメントサービス１５０４は、受け取ったドキュメントをホストシステムのエンタープライズソルーションソフトウェア１５０５に供給するインタフェースを提供するものである。通信エージェント１５００は、ＨＴＴＰ、ＳＭＴＰ、ＦＴＰ又は他のプロトコル等のプロトコルをサポートする適切なプロトコルスタックを有するインターネットインタフェースである。したがって、入力するデータは、特定の通信チャンネルに適合するようにＸＭＬ構文、ＡＳＣＩＩデータ構文、又は他の構文で受け入れ可能である。非ＸＭＬ構文で受信されたすべてのドキュメントは、ＸＭＬに変換され、ＸＭＬパーサー（構文解析器）に転送される。非ＸＭＬ形式からＸＭＬ形式への変換をサポートするために、変換テーブル１５０６が使用される。

変換されたドキュメントは、パーサー１５０１に供給される。ＸＭＬパーサーは、受信されたＸＭＬドキュメントに一致するドキュメントタイプ定義に従って、当該ＸＭＬドキュメントを構文解析する。エラーが見つかった場合には、パーサーはドキュメントを通信エージェント１５００へ送り返す。ビジネス・インタフェース定義コンパイラＢＩＤＣ１５０７は、ビジネス・インタフェース定義データのためのコンパイラとして機能する。ＸＭＬパーサーのためのＤＴＤファイル、ＤＴＤファイルに対応するＪＡＶＡビーンズ、及びＤＴＤファイルをＪＡＶＡビーンズへ変換する変換ルールは、ＢＩＤデータをコンパイルすることにより作られる。これらのツールを参照することにより、ＸＭＬインスタンスがＪＡＶＡインスタンスに変換される。したがって、ＢＩＤコンパイラ１５０７は、ＤＴＤドキュメント１５０８を記憶し、対応のＪＡＶＡドキュメントを生成する１５０９。ＸＭＬドキュメントはプロセッサ１５０２に送られ、プロセッサ１５０２は、そのドキュメントをＪＡＶＡフォーマットに変換する。好ましいシステムでは、ＸＭＬフォーマットで受取ったドキュメントタイプ定義と同じステータスを有するＪＡＶＡドキュメントが生成される。ＪＡＶＡビーンズをドキュメントルータ１５０３に送る。ドキュメントルータ１５０３がＪＡＶＡビーンズを受け取り、その受取ったクラスを、レジストリプログラムを使用して（例えば、上述したイベントリスナーアーキテクチャを使用して）、適切なドキュメントサービスに送る。ルータ１５０３からＪＡＶＡビーンズの形式でドキュメントを受取ったドキュメントサービス１５０４は、エンタプライズソルーションソフトウェアとして機能する。これは、ＸＭＬイベントに対するリスナーを入力データ・ストリームと結合するレジストリサービス１５１０と、適切なサービスに入力ドキュメントの送信がなされるよう管理するサービスマネージャ１５１１とを有する。ドキュメントサービスマネージャ１５１１は、レジストリサービスの管理及びドキュメントの一貫性の維持等を提供する。

ドキュメントサービスは、任意の専有ＡＰＩを使用して、或いはＣＯＲＢＡ／ＣＯＭインタフェース又はその他のアーキテクチャ等の共通形式を使用して、バックエンドシステムと通信する。

図１６は、本発明に係るマーケットメーカー及びマーケット参加者構造のヒューリスティック（発見的）ダイアグラムである。従って、本発明に係る電子商取引マーケットは、図１６に示されているように論理的に組織化できる。その組織の最上部において、マーケットメーカーノード１６００が設定される。マーケットメーカーノードは、マーケットプレイス１６０１を設定するリソースを含む。このようなリソースは、マーケット登録サービス等を含む。ビジネス１６０２は、ビジネス・インタフェース定義をパブリッシュ(publish)することによりマーケットプレイスに登録する。ビジネス・インタフェース定義は、ビジネスが参加する商取引についてサービス１６０３を定義する。トランザクション１６０４及びサービス１６０３は、ドキュメント１６０５を使用して入力及び出力を定め、トランザクションにおける参加者の間の商業上の関係をアウトラインする。ドキュメントは各トランザクションの詳細を含むコンテンツ１６０６を有する。コンテンツがマーケットの参加者により及びマーケットメーカーにより処理される方法は、本発明に従って確立される電子商取引ネットワークに基づくドキュメントに完全に依存する。全体として、通信ネットワーク上で電子商取引が可能となるように頑強性、拡張性及び直観力に富む構造が提供される。

したがって、本発明は、例示のシステムにおいて、ＸＭＬプロセッサに基づくプラットフォームを提供し、疎結合されたビジネスシステムの間のインタフェースとしてＸＭＬドキュメントを使用している。ドキュメントは、ビジネスの間で転送され、企業のビジネスシステムに入る前に特定のノードによって処理される。したがって、プラットフォームは、各ビジネスシステムが異なる内部的なコマースプラットフォーム、処理及びセマンティック（意味論）を使用している場合に、共通の組のビジネスドキュメント及び形式を特定することによりビジネス間の電子商取引アプリケーションを利用可能にする。

本発明によれば、ビジネスシステムとサービスを相互接続することによりバーチャルエンタプライズが形成され、主に、ビジネスが受入れて生成するドキュメント（ＸＭＬコード化された）に関し、次のとおり定義される。
「貴社が当社にカタログを請求される場合には、貴社にカタログを送ります。」「貴社が購入の注文をされ当社がそれを受け入れことができる場合には、貴社に送り状を送ります。」
上述した本発明の好ましい実施例の説明は、本発明の解説するためになされたものである。これは、包括的であること又は発明を開示した厳密な形式に限定することを意図するものではない。当業者にとって多くの修正及び変更は明らかである。本発明の範囲は、特許請求の範囲及びそれと等価なものによって定められるものである。

本発明によるビジネス・インタフェース定義（ＢＩＤ）を含む電子商取引ネットワークの概略図である。 本発明によるビジネス・インタフェース定義ドキュメントの概略図である。 本発明によるネットワーク中の参加者ノードのためのサーバの概念的なブロックダイアグラムである。 本発明に係る参加者ノードで受取られたドキュメントの処理を説明するフローチャートである。 ＸＭＬベースのシステムについての構文解析プログラム及びトランザクション処理フロントエンドのブロックダイアグラムである。 構文解析プログラム機能フローの概念的なダイアグラムである。 本発明に係るビジネス・インタフェース定義に使用される、サーバにおけるリソースの概略図である。 ビジネス・インタフェース定義の構築のために使用する、本発明に係るリポジトリの概略図である。 本発明に係るビジネス・インタフェース定義を構築するプロセスを説明するためのフローチャートである。 本発明に係るリポジトリのヒューリスティックな概要を提供するものである。 ビジネス・インタフェース定義に基づく本発明のネットワークのためのマーケットメーカー機能を提供するサーバのリソースについての概略図である。 受取られたドキュメントのマーケットメーカーノードの処理に関するフローチャートである。 本発明に係るマーケットメーカーノードの参加者の登録プロセスを説明するためのフローチャートである。 図９のプロセスに従った、マーケットメーカーノードにおけるサービスの仕様を提供するプロセスを説明するためのフローチャートである。 本発明に係るマーケットメーカーまたは参加者における操作シーケンスを説明するダイアグラムである。 本発明に係るＢＩＤに基づく商取引ネットワークの要素の概念的なダイアグラムである。

Claims (16)

1. 処理サーバ上で動作するフロントエンド・トランザクションプロセッサの部分を構築し、且つ少なくとも１つのバックエンドプロセッサ上で実行される少なくとも１つのオペレーションと１以上のクライアントコンピュータ(11)とをネットワークを介して接続するシステムであって、
   処理サーバ上で実行するためのトランザクション処理フロントエンドモジュール(704)を構築する前記ネットワークに接続されたビルダー・サーバ(700)を備え、
   当該ビルダー・サーバ(700)が、
   (1)前記ビルダー・サーバ上で実行する設計ツール手段(901)であって、前記バックエンドプロセッサによって実行されるべきオペレーションを記述するとともに、記憶装置の組のデータマップ及び前記オペレーション用の入力(211)/出力(212)ビジネスドキュメントに用いられる前記記憶装置の論理構造の選択又は記述の指示を、前記ネットワークを介した端末から受信する、当該設計ツール手段(901)と、
   (2)前記ビルダー・サーバ上で実行するインタフェース定義構築手段であって、前記バックエンドプロセッサで実行されるオペレーションの記述を、前記データマップ又は前記入力/出力ビジネスドキュメント用のデータマップに対するポインタと組み合わせて、インタフェースが前記ネットワークを介してクライアントコンピュータにアクセスするよう定義されたデータ構造のインタフェース定義を生成する、当該インタフェース定義構築手段と、
   (3)前記ビルダー・サーバ上で実行するコンパイラ手段(906)であって、前記データマップを、
   (a)前記入力ビジネスドキュメントからの未体系化データに対するアクセスを提供し、且つ体系化データを前記出力ビジネスドキュメントに移動させる前記フロントエンド・トランザクションプロセッサが用いる内部用データオブジェクトクラス定義を生成するために、
   (b)前記入力ビジネスドキュメントを解析し、その内容及び論理構造へのアクセスを提供する構文解析器（パーサ）を管理するために、
   (c)前記ビルダー・サーバ上で実行する入力/出力トランスレータが、前記入力/出力ビジネスドキュメントから前記内部用データオブジェクトクラスに合致する内部用データオブジェクトに変換し、またこれとは逆に内部用データオブジェクトから前記入力/出力ビジネスドキュメントへと変換し、また前記入力トランスレータが前記構文解析器からの入力ドキュメントの内容及び論理構造を受信する当該入力/出力トランスレータをアセンブルするために、使用する当該コンパイラ手段と、
   (4)前記クライアントコンピュータに向けて前記データ構造のインタフェース定義を送信する、前記ビルダー・サーバで実行される情報提供手段(907)と、
   を含むシステム。
2. 消費者端末上で動作する消費者サービスモジュールの部分を構築するシステムであって、前記消費者端末は処理サーバ上で動作するプロバイダーサービスにアクセスし、
   消費者端末上で実行するための消費者サービスモジュール(704)を構築するビルダー・サーバ(700)と、
   前記ネットワークを介して前記消費者端末にアクセス可能なインタフェースを定義するプロバイダーサービス・インタフェースデータ構造を構築するために組み合わされる、データマップ（DTD)或いは記憶装置のデータマップに対するポインタ及びビジネスドキュメント用の記憶装置の論理構造を記憶する少なくとも１つのディレクトリサーバー(700)とを備え、 当該ビルダー・サーバ(700)が、
   (1)前記ネットワークを介して端末から指示を受信する前記ビルダー・サーバ上で実行する設計ツール手段(901)であって、前記指示は、処理サーバー上で実行されるべきオペレーションを選択し、且つ前記ディレクトリサーバーをアクセスすることによって、前記プロバイダーサービス・インタフェースデータ構造に含まれる入出力ビジネスドキュメントのデータマップを検索する当該設計ツール手段と、
   (2)前記ビルダー・サーバ上で実行する相補コンパイラ手段(906)であって、前記データマップを、
   (a)体系化されるデータを前記入力ビジネスドキュメントにもたらし、且つ前記出力ビジネスドキュメントからの未体系化されるデータに対してアクセスを提供する前記消費者サービスによって使用される内部用データオブジェクトクラス定義を生成するために、
   (b)前記プロバイダーサービスからの出力ビジネスドキュメントを解析し、その内容及び論理構造へのアクセスを提供する構文解析器（パーサ）を管理するために、
   (c)前記消費者端末上で実行し、前記入力/出力ビジネスドキュメントから前記内部用データオブジェクトクラスに合致する内部用データオブジェクトに変換し、そして前記入力トランスレータが前記構文解析器からの出力ビジネスドキュメントの内容及び論理構造を受信する入力/出力トランスレータをアセンブルするために
   使用する当該コンパイラ手段と、を含むシステム。
3. 再使用可能なビジネスドキュメントのデータマップを記憶する少なくとも１つのリポジトリサーバを更に含み、前記設計ツール手段が前記リポジトリサーバにアクセスする端末からの指示を受け入れ、そして前記再使用可能なビジネスドキュメントの少なくとも１つを前記記憶装置の記述及び論理構造と組み合わせて、少なくとも１つの入出力ドキュメントを形成することを特徴とする請求項１又は２に記載のシステム。
4. 再使用可能なセマンティック(意味的な）構成要素を記憶する少なくとも１つのリポジトリサーバを更に含み、前記設計ツール手段が前記リポジトリサーバにアクセスする端末からの指示を受け入れ、そして前記再使用可能なセマンティック構成要素の少なくとも１つを前記記憶装置の記述及び論理構造と組み合わせて、少なくとも１つの入出力ドキュメントを形成することを特徴とする請求項１〜３の何れか１項に記載のシステム。
5. 前記ビルダー・サーバによってアクセス可能なリポジトリ記憶手段に記憶されたリポジトリを更に含み、前記設計ツール手段が、前記リポジトリから得られる前記オペレーションインタフェース仕様で使用される要素にアクセスし、前記リポジトリは論理構造のライブラリを記憶し、論理構造のための解釈情報がオペレーションインタフェース使用を構築するために使用される、ことを特徴とする請求項１〜４の何れか１項に記載のシステム。
6. 前記オペレーションの記述は前記オペレーションのタイトル及び概要を含む、請求項１〜５の何れか１項に記載のシステム。
7. 情報提供手段は、前記インタフェース定義データ構造が、前記クライアントコンピュータにアクセス可能な少なくとも１つのリポジトリサーバ上へ提供されるように、前記クライアントコンピュータに向けて前記インタフェース定義データ構造を送信する、ことを特徴とする請求項１及び３〜６の何れか１項に記載のシステム。
8. 前記インタフェース定義データ構造が、前記入出力ドキュメントの論理構造用の解釈情報又はその解釈情報に対するポインタを更に含む、請求項１〜７の何れか１項に記載のシステム。
9. 消費者サーバ上で動作する消費者サービスによってリクエストされたオペレーションをネットワークを介して実行する方法であって、
   プロバイダーサーバ上で実行可能なオペレーションインタフェースであって、処理サーバ上で実行中のオペレーションに対するアクセスを提供する当該オペレーションインタフェースを、ネットワークを介して少なくとも１つの消費者サービスに呈示する処理を含み、
   前記オペレーションインタフェースは、インタフェース記憶手段上のオペレーションインタフェース定義データ構造に記憶されたインタフェース定義を実装し、そして前記インタフェース定義データ構造は、入出力ビジネスドキュメントの定義を含み、そして前記定義は、記憶装置の記述及び論理構造を含み、
   前記ネットワークを介し、前記プロバイダーサーバで、前記消費者サーバからの入力ビジネスドキュメントを受信し、
   前記入力ビジネスドキュメントの内容及び論理構造に対するアクセスを提供するため、前記プロバイダーサーバで、前記入力ビジネスドキュメントの定義に従って前記入力ビジネスドキュメントを構文解析し、そして前記構文解析された入力ビジネスドキュメントの少なくとも部分を、内部用入力データオブジェクトに変換し、
   前記内部用入力データオブジェクトを、前記プロバイダーサーバから前記処理サーバ上で実行するオペレーションに送信し、
   前記ネットワークを介して、前記出力ビジネスドキュメントの定義に合致する出力ビジネスドキュメントを前記消費者サーバに転送する、
   ことを特徴とする方法。
10. 前記プロバイダーサーバは、前記処理サーバから内部用出力データオブジェクトを受信し、
    前記プロバイダーサーバで、前記内部用出力データオブジェクトを、前記消費者サーバに送信される前記出力データオブジェクトに変換する、ことを特徴とする請求項９に記載の方法。
11. ネットワークを介して、消費者サーバ上で動作する消費者サービスから、プロバイダーサーバのオペレーションインタフェースに送信されるリクエストに応じて実行されるオペレーションを生じさせる方法であって、
    前記オペレーションインタフェースは、インタフェース記憶手段上のオペレーションインタフェース定義データ構造に記憶されたオペレーションインタフェース定義を実装し、そして前記インタフェース定義データ構造は、入出力ビジネスドキュメントの定義を含み、そして前記定義は、記憶装置の記述及び論理構造を含み、
    第１の内部用データオブジェクトからの前記消費者サーバにあるデータを、入力ビジネスドキュメントの前記オペレーションインタフェース定義に合致する入力ビジネスドキュメントに体系化し、
    前記消費者サーバからの前記入力ビジネスドキュメントを、前記プロバイダーサーバに、前記ネットワークを介して送信し、
    前記消費者サーバで、出力ビジネスドキュメントの前記オペレーションインタフェース定義に合致する出力ビジネスドキュメントを、前記プロバイダーサーバから受信し、
    前記出力ビジネスドキュメントの内容及び論理構造に対するアクセスを提供するため、前記消費者サーバで、前記出力ビジネスドキュメントの定義に従って前記出力ビジネスドキュメントを構文解析し、そして前記構文解析された出力ビジネスドキュメントの少なくとも部分を、第２の内部用データオブジェクトに変換する、
    ことを特徴とする方法。
12. ネットワークを介して、クライアントコンピュータから受信された入力ビジネスドキュメントを、処理サーバ上で実行する１以上のオペレーションに送信する方法であって、
    オペレーションインタフェース仕様を含む複数のオペレーションインタフェース仕様データ構造をインタフェース記憶手段に記憶し、ここで、前記オペレーションインタフェース仕様は、オペレーションの記述及び入出力ビジネスドキュメントの定義を含み、前記入出力ビジネスドキュメントの定義は、記憶装置の記述及び論理構造を含んでおり、
    サーバで、クライアントコンピュータからのドキュメントを含むデータをネットワークを介して受信し、
    前記サーバで、入力ビジネスドキュメントを識別するために、前記オペレーションインタフェース仕様に従い前記ドキュメントを構文解析し、そして前記識別された入力ビジネスドキュメントを受け入れ可能な処理サーバで実行されるオペレーションを識別し、
    前記サーバからの入力ビジネスドキュメントの少なくとも部分を、前記サーバから、前記識別された入力ビジネスドキュメントを受け入れ可能な処理サーバで実行される１以上のオペレーションに送信する、
    ことを特徴とする方法。
13. 前記入出力ビジネスドキュメントは、標準拡張マークアップ言語のＸＭＬフォーマットに合致する、請求項９〜１２の何れか１項に記載の方法。
14. 前記記憶装置は構文解析されたデータを含む、請求項９〜１３の何れか１項に記載の方法。
15. 前記記入出力ビジネスドキュメントの少なくとも１つにある前記構文解析されたデータは、
    前記入出力ビジネスドキュメントの一つにおいて、テキスト文字をエンコードするキャラクタ・データと、
    前記入出力ビジネスドキュメントの一つの論理構造に従い、記憶装置を識別するマークアップデータとを含む、請求項１４に記載の方法。
16. 処理サーバ上で機能するトランザクション処理フロントエンドのオペレーションを含むドキュメントを送信し、そしてネットワークを介して、１以上のクライアントコンピュータを少なくとも１つのバックエンドプロセッサで実行する少なくとも１つのオペレーションと結びつけるシステムであって、
    オペレーションインタフェース仕様を含むインタフェース記憶手段に記憶された複数のオペレーションインタフェース仕様データ構造であって、ここで、前記オペレーションインタフェース仕様は、オペレーションの記述及び入出力ビジネスドキュメントの定義を含み、前記入出力ビジネスドキュメントの定義は、記憶装置の記述及び論理構造を含んでいることを特徴とするオペレーションインタフェース仕様データ構造と、
    前記インタフェース記憶手段に接続された前記処理サーバ上で実行する前記トランザクション処理フロントエンドが、
    (1)前記ネットワークを介してクライアントコンピュータからドキュメントを受け入れるネットワークインタフェースと、
    (2)前記オペレーションインタフェース仕様に従い前記ドキュメントを解析し、入力ビジネスドキュメントを識別し、そして前記識別された入力ビジネスドキュメントを受け入れ可能な処理サーバで実行される１以上のオペレーションを識別する、前記処理サーバ上で動作する構文解析器と、
    (3)前記処理サーバから、前記識別された入力ビジネスドキュメントを受け入れ可能なバックエンドサーバで実行される１以上のオペレーションに対して前記入力ビジネスドキュメントの少なくとも部分を送信する、前記処理サーバ上で動作するドキュメントルーターと、を備えたことを特徴とするシステム。

Images