JP4712191B2 - Definition of commercial documents and their document-based interfaces in trading partner networks - Google Patents

Description

サービスＤＴＤスキーマは、共通ビジネス言語リポジトリのサービスタイプエレメントで以下のように拡張されうる。

上記のサービスタイプエレメントは、ビジネスインターフェイス定義によって保有される解釈情報、この例では、有効なサービスタイプのいずれか１つの識別を可能にするコンテントフォームを例示する。別の解釈情報は、例えばコンテントフォーム「ｕｒｌ」を含み、データタイプ「ｓｔｒｉｎｇ」で表されるエレメント＜Ｈ３＞Ｉｎｔｅｒｎｅｔ Ａｄｄｒｅｓｓ＜／Ｈ３＞のような、データタイピングを含む。さらに別の解釈情報は、例えばファイル「ＣＯＵＮＴＲＹ．ＵＳ．ＳＵＢＥＮＴＩＴＹ」中の国に対するコードマッピングを含むエレメント＜Ｈ３＞Ｓｔａｔｅ＜／Ｈ３＞のような、リストのエレメントへのコードのマッピングを含む。
マーケット関係者ＤＴＤによって照会されるサービスディスクリプションは、サービスのコンペティションについてサービスが認めて生成するドキュメントを規定する。ベーシックサービスディスクリプションは、ＸＭＬドキュメントｔｒａｎｓａｃｔ．ｄｔｄとして以下に記載される。
ｔｒａｎｓａｃｔ．ｄｔｄは、インボイスのようなトランザクションディスクリプション、または値の交換のディスクリプションをモデル化する。このドキュメントタイプは、多くの用途を支援し、従って、トランザクションディスクリプションエレメントは、ユーザーがインボイス、業績、売りの申し出、取引価格の要望等を区別するのを可能にする属性を有する。交換は２人以上の関係者間で行われうるが、申し出人と相手の２人のみを登場させる。その各人は、上記に概説したマーケット関係者ＤＴＤに合致するドキュメントへのポインタによって表される。相手のポインタが、売りの申し出を受け入れるのは任意である。交換ディスクリプションは以下に挙げるｔｒａｎｐｒｉｍ．ｍｏｄに記述され、価格および小計を含む。交換ディスクリプションに続いて、全体としてトランザクションに適用される料金が備えられ、全体の料金が与えられなければならない。従って、この例のトランザクションディスクリプションスキーマドキュメントｔｒａｎｓａｃｔ．ｄｔｄは以下に表される。

代表マーケット関係者およびサービスＤＴＤは、上記の定義に従って生成され、以下の通りである。
マーケット関係者ＤＴＤ

サービスＤＴＤ

ｔｒａｎｓａｃｔ．ｄｔｄによって生成されるドキュメントの一例が続く。

【００４６】
したがって、本発明は、マーケット参加者がそれ自身を識別し、入力ドキュメントのタイプおよび取引を行おうとしている出力ドキュメントのタイプを識別できるようにする技術を提供する。この種のドキュメントに担持された内容がこの取引での他のパーティーまたはローカルパーティーによって処理される特定の仕方は、ビジネス関係の確立には関係しないし、取引を行うことにも関係しない。
【００４７】
図３は、本発明によるネットワークにおける参加者ノードの概略図である。図３に例示されたノードは、ポート３０１にて通信ネットワークに結合されるネットワークインターフェイス３００を含む。このネットワークインターフェイスは、ドキュメントパーサー３０１に結合される。パーサー３０１は、入力ドキュメントからのロジカルストラクチャーをトランスレータモジュール３０２へ供給し、トランスレータモジュール３０２は、入力ドキュメントをホスト取引システムによって使用できるようなフォームへと変換し、また、その逆に、ホストプロセッサの出力を送り先への送信のためにビジネスインターフェイス定義での出力ドキュメントフォームへと変換するためのものである。パーサー３０１およびトランスレータ３０２は、参加者モジュール３０３に記憶されたビジネスインターフェイス定義に応答する。
【００４８】
トランスレータ３０２からの出力データストラクチャーは、パーサー３０１によってシグナリングされるエベントと共に取引プロセスフロントエンド３０４へ供給される。１つの実施例におけるフロントエンド３０４は、ネットワークにおける種々なノードの間で通信するに適したＪＡＶＡバーチャルマシンまたはその他の類似のインターフェイスからなる。取引プロセスフロントエンド３０４は、パーサー３０１およびトランスレータ３０２によって指示されたエベントに応答して、入力データを、その参加者が結合されたエンタープライズシステムおよびネットワークにおける適当なファンクションへルーティングする。こうして、図３の例における取引プロセスフロントエンド３０４は、コマーシャルファンクション３０５、データベースファンクション３０６、アカウンティングおよびビリング３０７の如きその他のエンタープライズファンクションに結合され、また、パーサーによって指示されたエベントに応答するように設計された特定のエベントリスナーおよびプロセッサ３０８に結合される。
【００４９】
パーサー３０１は、ビジネスインターフェイス定義にしたがって特定される前述の例におけるような購入注文またはその他のドキュメントを受け取り、ＪＡＶＡバーチャルマシンのためのＪＡＶＡエベントのセットの如きローカル取引処理アーキテクチャによって認識されるエベントのセットを生成する。
【００５０】
本発明のパーサーは、受信ドキュメントに基づくエベントをリスニングするプログラムから切り離される。受信ドキュメントにおける種々なマークアップピースまたは特定の仕様を満たす完全ドキュメントは、処理を開始させるリスニングファンクションのための命令として働く。こうして、リスニングプログラムは、ドキュメント情報に関連したビジネスロジックを実施する。例えば、アドレスエレメントに関連したプログラムは、データベースをチェックすることによってポスタルコードを確証するコードでありうる。これらのリスナーは、ドキュメントルーターで登録することによりエベントに加入する。ドキュメントルーターは、適切なエベントを、それらに興味のあるすべての加入者へと差し向けるものである。
【００５１】
例えば、前述したように特定された購入注文は、ドキュメントまたはその内容を注文エントリプログラムへ接続するであろうパーサーによって発生されるエベントをリスニングするプログラムによって監視されうる。その購入注文内のプロダクト記述の受領によりあるプログラムを使ってインベントリをチェックする。購入注文内のアドレス情報の受領により、あるプログラムを使ってデリバリのためのサービスの利用性をチェックする。ドキュメントにおけるバイヤー情報フィールドは、種々なプロセスを使って、クレジット価値について注文ヒストリをチェックし、または、プロモーションまたは消費者のアイデンティティを知ることに基づくような類似の処理をオファーすることができる。
【００５２】
コンプレックスリスナーは、プリミチブなリスナーのコンフィギュレーションとして生成されうる。例えば、ある購入注文リスナーは、前述したリストリスナーを含み、そのリストリスナーを使いうるし、また、リストメンバーは、それら自身に関して使われうる。リスナーがランするようなアプリケーションは、ネーチブＸＭＬプロセスまたはネーチブＪＡＶＡプロセスではないようであることに注意すべきである。これらの場合において、オブジェクトは、受信トランスアプリケーションによって必要とされるフォーマットへ変換される。そのアプリケーションが処理を完了するとき、その出力は、ネットワークにおける他のノードへの通信のためにＸＭＬフォーマットへと変換し戻される。
【００５３】
前述したようなマーケット参加者ドキュメントタイプ記述および取引ドキュメントタイプ記述としては、ドキュメントにおけるロジックエレメントのためのスキマチックマッピングがあり、また、自然言語に基づくマークアップ言語がある。自然言語マークアップおよびＸＭＬのその他の自然言語属性は、ビジネスインターフェイス定義、サービス記述および入力および出力ドキュメントの記述の仕様のためのＸＭＬタイプマークアップ言語の使用を容易とする。
【００５４】
ビジネスインターフェイス定義を記憶することに加えて、参加者モジュール３０３は、入力ドキュメントにおけるロジカルストラクチャーに対応する取引プロセスフロントエンド３０４によって使用されるオブジェクトまたはその他のデータストラクチャーを編集したり、トランスレータ３０２を編集したりするのに使用されるコンパイラーを含む。こうして、ビジネスインターフェイス定義が参加者の関係する取引の変化につれて参加者によって変更されまたは更新されるとき、トランスレータ３０２およびパーサー３０１は、自動的にアップデートに保たれる。
【００５５】
好ましいシステムにおいては、ＪＡＶＡエベントのセットは、ＳＧＭＬのグローブモデル、主として、各エレメントについてプロパティセットによって拡張された標準のエレメントストラクチャーインフォーメーションセットに対応するコンパイラによって生成される（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｔａｎｄａｒｄ ＩＳＯ／ＩＥＣ １０１７９：１９９６（Ｅ），Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ−−Ｐｒｏｃｅｓｓｉｎｇ Ｌａｎｇｕａｇｅ−−Ｄｏｃｕｍｅｎｔ Ｓｔｙｌｅ Ｓｅｍａｎｔｉｃ ａｎｄ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｌａｎｇｕａｇｅ（ＤＳＳＳＬ））。ＸＭＬドキュメントをプロセスのためエベントのセットへと戻すのは、パーサー出力がインターナルデータストラクチャーとして維持されるような構文解析の通常モデルとは異なる。各ノードの取引処理フロントエンドによって使用するのに適したＪＡＶＡエベントまたはその他のプログラミングストラクチャーへＸＭＬドキュメントのエレメントを変換することにより、トレードされるドキュメントを利用するノードでのリッチファンクショナリティが可能とされる。
【００５６】
こうして、取引プロセスフロントエンド３０４は、システムにおける他のリスニングプログラムの知識なしにまたはインパクトなしに新しいリスナープログラムを加えることができるようにするパブリッシュおよびサブスクライブアーキテクチャーにて作動することができる。図３における各リスナー３０５、３０６、３０７、３０８は、フロントエンド３０４がエベントを指揮するキューを維持する。これにより、多数のリスナーがそれら自身のペースで併行してエベントを取り扱うことができるようになる。
【００５７】
さらにまた、本発明によれば、リスナーがランするようなアプリケーションは、入力ドキュメントのフォーマットに整合するネーチブＸＭＬファンクションまたはネーチブファンクションである必要はない。むしろ、これらのリスナーは、取引プロセスフロントエンド３０４がＪＡＶＡインターフェイスである場合には、ＪＡＶＡファンクションでありうし、または、独特な取引処理アーキテクチャーにしたがってランするファンクションでありうる。これらの場合において、オブジェクトは、受信アプリケーションによって必要とされるフォーマットへ変換されうる。リスナーのアプリケーションが終わるとき、その出力は、モジュール３０３におけるビジネスインターフェイス定義によって特定されるようなドキュメントのフォーマットへと変換し戻される。こうして、トランスレータ３０２は、組み合わせたドキュメントを出力として供給するため直接的にネットワークインターフェイス３００に結合される。
【００５８】
取引処理フロントエンドに結合されたリスナーは、入力ドキュメントのためのリスナー、入力ドキュメントの特定エレメントのためのリスナーおよび入力ドキュメントの特定のエレメントに記憶されている属性のためのリスナーを含みうる。これにより、入力ドキュメントをフィルタリングしそれに応答するための特定のノードでの取引プロセスの種々な融通性のある実施が可能となる。
【００５９】
図４は、図３のシステムのための入力ドキュメントを受信して処理するためのプロセスを例示している。こうして、プロセスは、ネットワークインターフェイスでドキュメントを受信することで始まる（ステップ４００）。パーサーは、ビジネスインターフェイス定義に応答してドキュメントタイプ（４０１）を識別する。ＸＭＬフォーマットにてドキュメントのためのＤＴＤを記憶しているビジネスインターフェイス定義を使用して、ドキュメントは構文解析される（ステップ４０２）。次に、ドキュメントのエレメントおよび属性は、ホストのフォーマットへと変換される（ステップ４０３）。この例では、ＸＭＬロジックストラクチャーは、ゲットおよびセットファンクションの如きデータに関連した方法とともにＸＭＬエレメントのデータを担持するＪＡＶＡオブジェクトへと変換される。次に、ホストオブジェクトは、ホスト取引処理フロントエンドへ転送される（ステップ４０４）。これらのオブジェクトは、パーサーおよびトランスレータによって指示されるエベントに応答してプロセスへルーティングされる。ドキュメントのエレメントを受け取るプロセスは、実行され、出力を発生する（ステップ４０５）。その出力は、ビジネスインターフェイス定義によって定められるような出力ドキュメントのフォーマットへと変換される（ステップ４０６）。この例では、トランスレーションは、ＪＡＶＡオブジェクトのフォームからＸＭＬドキュメントのフォームへと進む。最後に、出力ドキュメントは、ネットワークインターフェイスを通して送り先へと送信される（ステップ４０７）。
【００６０】
図５は、図３のシステムのためのイベント発生器／イベントリスナー機構の詳細な図である。一般に、図５に示されている手法はＪＡＶＡ ＪＤＫ１．１イベントモデルの改良である。このモデルにおいて、３種類のオブジェクトが考慮される。第１種類のオブジェクトはイベントの発生に関する情報を含むイベントオブジェクトである。発生できるイベントの異なる全種類に対応して、イベントオブジェクトの種類の数が有る。第２種類のオブジェクトは、何かが起こった時に活動を監視しイベントオブジェクトを発生するイベント発生器である。第３は、イベント発生器により発生されたイベントオブジェクトを聞くイベントリスナーである。イベントリスナーは一般に、特定のウインドウ上のマウスクリックなどのような特定のイベント発生器を聞く。イベントリスナーはイベント発生器上に「イベントリスナーを加える」方法を呼ぶ。このモデルは図３の環境に適合させることができ、ＸＭＬドキュメントにより代表されるようなオブジェクトのグラフを歩きそして構文解析することに応答してオブジェクトが発生される。
【００６１】
図５に示されるシステムは一般的なＸＭＬパーサー５００を有する。このようなパーサーは標準の呼び戻しモデルを使用して実現できる。構文解析イベントが発生する時に、パーサーはアプリケーションオブジェクト内で特定の方法を呼出し、パラメータ内の適当な情報を渡す。従って、単一のアプリケーション５０１がパーサーと共に存在する。アプリケーションはパーサーが提供する情報をＸＭＬイベントオブジェクト内にパッケージし、そしてブロック５０２により示されるように、それを自身により識別された数だけのイベントリスナーに送る。イベント５０２の組は完全にパーサーから独立している。イベント５０２はどんな数のマシン上のどんな数のリスナーおよびどんな数のスレッドへにも供給されることができる。イベントは１つの代替形式においては、エレメント構造情報セット（ＥＳＩＳ）に基づいている。従って、これらはエレメントの開始および終了などのようなドキュメント構造または属性の認識のような重要な観点のリストからなる。ＸＭＬ（そしてＳＧＭＬ）パーサーは一般にＥＳＩＳ構造をパーサーがそのアプリケーションに戻るための情報のデフォルトセットとして使用する。
【００６２】
専門化されたＥＳＩＳリスナー５０３は、イベント５０２の組に結合される。このリスナー５０３はＥＳＩＳリスナーＡＰＩを実現し、そして１または複数からの発生器からの全てのＸＭＬイベントを聞く。１つのエレメントイベント発生器５０４は専門化されたＥＳＩＳリスナーで、ＸＭＬイベント発生器でもある。そのリスナーは特定のタイプのエレメントに対するイベントにのみ興味があるオブジェクトである。例えば、ＨＴＭＬ環境においては、リスナーは指示されたリストのみ、すなわち、＜ＯＬ＞と＜／ＯＬ＞タグの間のドキュメントの部分のみに興味を有する。他の例では、リスナーは上の例のドキュメントから共通ビジネス言語に従って「ｐａｒｔｙ．ｎａｍｅ」エレメントまたは「ｓｅｒｖｉｃｅ．ｎａｍｅ」エレメントのみを聞き、エレメントのための図式的マッピングに一致するデータをエレメントが運ぶことを確実にするためにエレメントを処理し、そして受取ノードにおいて必要とされるプロセスに従って反応する。
【００６３】
これは、システムが、価格を合計するだけのようなドキュメントの特定部分のみを聞く小さいオブジェクトを有することを可能にする。リスナーが発生器からそれら自身を加えるまたは取除くことができるから、ＨＴＭＬドキュメントの例えば＜ＨＥＡＤ＞部分のみを聞くリスナーも存在できる。この理由およびＸＭＬドキュメントの高い反復性の理由により、高い目標的なコードを書くことおよび併発的なリスナーを書くことができる。例えば、＜ＯＬ＞リスナーは＜ＵＬ＞（指示されていないリスト）リスナーがその＜ＬＩ＞リスナーを設定する方法とは完全に分離して＜ＬＩ＞リスナーを設定することができる。代替方法として、図形ユーザインターフエイスを発生するリスナーおよび同じ入力を使用するデータベースを探索する別のリスナーを作成できる。従って、アプリケーションが一度に１つずつ検査する完成されたデータ構造とは反対に、ドキュメントはリスナーにより実行されるプログラムとして取扱われる。もし、アプリケーションがこの方法で書かれると、アプリケーションを実行するために全ドキュメントをメモリ内に持つ必要が無い。
【００６４】
イベント５０２の組に結合された次のリスナーは、属性フィルター５０５である。エレメントフィルタ５０４に似て属性フィルタ５０５はＥＳＩＳリスナーモデルに従い属性イベント発生器である。属性フィルタのためのリスナーはそれが興味を持つ属性を指定し、そして、指定された属性を持ついかなるエレメントのためのイベントを受取る。例えば、フォントマネージャは例えば＜Ｐ ＦＯＮＴ＝“Ｔｉｍｅｓ Ｒｏｍａｎ”／Ｐ＞のようなフォント属性を持つエレメントのためだけのイベントを受取るだろう。
【００６５】
エレメントイベント発生器５０４は、エレメントリスナー５０４Ａを専門化するためにそのようなエレメントオブジェクトを供給する。
【００６６】
属性イベント発生器５０５は属性イベントオブジェクトを属性リスナー５０５Ａへ供給する。同様に、属性オブジェクトは一のドキュメント形式から別へ属性を使用してＳＧＭＬ／ＸＭＬ変形する意味で「アーキテクチュア」に供給される。従って、５０５Ｂのアーキテクチュアは特定の名前を持った特定の属性を識別できるようにする。その定義された属性を持ったエレメントのみが出力ドキュメントの部分になり、そして出力ドキュメント内のエレメントの名前は、入力ドキュメント内の属性の値である。例えば、もしアーキテクチュア５０５ＢがＨＴＭＬであり、ストリングを、
＜ＰＵＲＣＨＡＳＥＳ ＨＴＭＬ＝“ＯＬ”＞＜ＩＴＥＭ ＨＴＭＬ＝“ＬＩ”＞＜ＮＡＭＥ ＨＴＭＬ＝“Ｂ”＞ＳＴＵＦＦ＜／ＮＡＭＥ＞＜ＰＲＩＣＥ ＨＴＭＬ＝“Ｂ”＞１２３＜／ＰＲＩＣＥ＞＜／ＩＴＥＭ＞＜／ＰＵＲＣＨＡＳＥ＞
翻訳すると、
＜ＯＬ＞＜ＬＩ＞ＳＴＵＦＦ＜／Ｂ＞＜Ｂ＞１２３＜／Ｂ＞＜／ＬＩ＞＜／ＯＬ＞
になり、正しいＨＴＭＬである。
【００６７】
イベント５０２の組に結合された次のモジュールはツリー（木）ビルダー５０６である。ツリービルダーはＸＭＬイベントのストリームを取り、下にあるドキュメントのツリー（木）表現を発生する。ツリービルダー５０６の一つの好ましい形式は、Ｗ３Ｃ（ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／１９９８／ＷＤ−ＤＯＭ−１９９８０７２０／ｉｎｔｒｏｄｕｃｔｉｏｎ．ｈｔｍｌ）の仕様に従ってドキュメントオブジェクトモデルＤＯＭオブジェクト５０７を発生する。イベントストリーム内のリスナーは大部分の要求を処理するのに使用できるが、ツリー形式はドキュメント回りの質問を支援するため、ノードを再順序付けるため、新ドキュメントの作成、例えばドキュメントを多数回構文解析するような、そこから同じイベントストリームを複数回発生できるメモリ内のデータ構造を支援するのに役立つ。専門化されたビルダー５０８は、特定の実施に適合するようなドキュメントの部分の特別なサブツリーを作るために、ツリービルダー５０６に結合できる。
【００６８】
入力するドキュメントに応答するのに加えて、ＸＭＬイベント５０２の他の源も供給されることができる。従って、イベントストリーム５１０はＤＯＭオブジェクトのツリー上を歩くことにより、そしてドキュメントが構文解析されいた時に作成された元のイベントストリームを再発生することにより発生される。これは、システムがドキュメントが数回構文解析されている外観を与えることを可能にする。
【００６９】
ツリーを歩きそしてイベントのストリームを発生するオブジェクトの観念は、ＤＯＭオブジェクトのツリーを越えて質問できるオブジェクトのいかなるツリーに一般化できる。従って、ＪＡＶＡウォーカー５１２は、ＪＡＶＡビーンコンポーネント５１３のツリーを歩くアプリケーションでもよい。ウォーカーは全ての公開されているフイールドおよび方法上を歩く。ウォーカーは終わりの無いサイクルに入り込まないことを確保するために既に訪問したオブジェクトの軌跡を記憶する。ＪＡＶＡイベント５１４はＪＡＶＡウォーカー５１２により発生されるイベントのタイプである。これは現在、オブジェクトから引き出すことのできる情報の種類の大部分を含む。これは、ＥＳＩＳのＪＡＶＡ等価物であり、そして、ＸＭＬに適用されたのと同じプログラム手法をＪＡＶＡオブジェクト一般に適用すること、特にＪＡＶＡビーンズにであるが、を可能にする。
【００７０】
ＪＡＶＡからＸＭＬイベント発生器５１５は、ＪＡＶＡリスナーとＪＡＶＡイベント発生器から構成される。これは、ＪＡＶＡウォーカー５１２からイベントのストリーム５１４を受取り、そしてＸＭＬドキュメントとしてＪＡＶＡオブジェクトを供給するために選択されたものを翻訳する。好ましい実施例において、イベント発生器５１５はＪＡＶＡビーンズＡＰＩを利用する。見られた各オブジェクトはエレメントとなり、エレメント名はクラス名とおなじである。そのエレメント内で、各埋め込まれた方法もまたエレメントとなり、その内容は方法を呼び起こすことにより戻された値である。もしそれがオブジェクトまたはオブジェクトの配列であると、これらは交互に歩かれる。
【００７１】
図６は、図５のフレームワーク上に構築された特定のアプリケーションの概略図である。このアプリケーションは、ＸＭＬドキュメント６００を取り込み、これをパーサ／発生器（構文解析ルーチン発生システム）６０１に適用する。ＥＳＩＳイベント６０２が発生され、且つ属性発生器６０３及びツリービルダー６０４に供給される。属性発生器は図５の発生器に対応する。この発生器５０５は、イベントを、例えば、ＸＭＬ入力からＨＴＭＬ出力に翻訳するための“アーキテクチャー”５０５Ｂに送る。これらのイベントは、ブロック６０５によって示される様に並列で処理され、且つリスナーによって処理される。リスナーの出力はドキュメントライター６０６に供給され、出力のためにＸＭＬフォーマットに戻し翻訳される。従って、例えば、図６に示されるこのアプリケーションは、ＸＭＬドキュメントを取り入れ、或るフォームを有するＨＴＭＬドキュメントを出力する。このフォームは次にブラウザに送られ、その結果がＸＭＬに戻し変換される。この運用のために、アーキテクチャコンセプトは、ＸＭＬからＨＴＭＬへのマッピングを提供する。図６に含まれる３つのアーキテクチャーは、テーブル及びリストの様なＨＴＭＬドキュメントの構造を与えるためのもの、ブラウザドキュメント上の入力フィールド用のラベルの様な表示されるべきドキュメントを特定する第２のもの、及び入力フィールド自体を記述する第３のものを含む。ＸＭＬドキュメント構造を維持するのに必要となるＸＭＬドキュメントのエレメントは、ＨＴＭＬフォーム内で不可視のフィールドとなる。このことは、サーバに送り戻されるＨＴＴＰポストメッセージにクライアントが入れる情報からＸＭＬドキュメントを再構成する際に使用するのに有用である。これらのイベントを聴取するリスナーが、ＨＴＭＬドキュメント用のイベントを出力する。このドキュメントは、ドキュメントライターオブジェクトへ行く。ドキュメントライターオブジェクトはＸＭＬイベントを聴取し、それらをＸＭＬドキュメントに戻す。ドキュメントライターオブジェクトは、この例におけるアーキテクチャーを聴取している全てのエレメント発生器に対するリスナーである。
【００７２】
図５及び６に図示される処理モジュールの構成は、図３のシステム用のパーサ及びトランザクションプロセスフロントエンドの或る実施の形態を表している。理解できる様に、極めて柔軟性のあるインタフェースが与えられ、これによってダイバース（変更）トランザクションプロセスを、入力するＸＭＬドキュメント、又は他の構造化ドキュメントフォーマットに応答して、実行することができる。
【００７３】
図７は、ビジネスインタフェース定義ビルダーモジュール７００を含むことを除いて図３と類似のノードを図示している。従って、図７のシステムは、ネットワークインタフェース７０１、ドキュメントパーサ７０２、及びドキュメントトランスレータ７０３を含む。トランスレータ７０３は、その出力をトランザクション処理フロントエンド７０４へ出力する。このフロントエンドは、商業上の機能７０５、データベース７０６、企業機能７０７、及び他の一般リスナー及びプロセッサ７０８のようなリスニング機能に結合される。図７に図示される様に、ビジネスインタフェースビルダー７００は、ユーザインタェース、共通ビジネスライブラリＣＢＬリポジトリ、相補的ビジネスインタフェース定義をを読むためのプロセス、及びコンパイラを含む。ユーザインタフェースは、ビジネスインタフェース定義の構築における企てを、共通ビジネスライブラリリポジトリ及び相補的ビジネスインタフェースの定義を読み出す能力に依存して、補助するのに使用される。従って、相補的ビジネスインタフェースの定義の入力ドキュメントは、特定のトランザクションの出力ドキュメントとして特定することが出来、相補的ビジネスインタフェースの定義の出力ドキュメントがトランザクションプロセスの様な入力として特定することができる。同様な仕方で、トランザクションビジネスインタフェースの定義がＣＢＬレポジトリから選択された成分を使用して構成することがてきる。ＣＢＬリポジトリの使用が、上述の例示案（ｂｉｄ１）ドキュメントの様な標準化されたドキュメントフォーマット、及びネットワーク内の他の人間によって直ぐに採用することの出来るビジネスインタフェースの定義の構築に於ける論理構造及び解釈情報の使用を促進する。
【００７４】
ビジネスインタフェース定義ビルダー７００は、トランスレータ７０３、ホストトランザクション処理アーキテクチャに従ってトランスレータによって処理されるべきオブジェクトを発生し、パーシング機能７０２を管理するために使用されるコンパイラーも含む。
【００７５】
図８は、ビジネスインタフェース定義ビルダー７００内のリポジトリ内に記憶される論理構造を示す発見的図式である。従って、パーティビジネスインタフェース定義８００を表すリポジトリ記憶は、例えば、消費者ＢＩＤ８０１、カタログハウスＢＩＤ８０２、ウェアハウスＢＩＤ８０３、及びアクションハウスＢＩＤ８０４を含む。従って、オンラインマーケットにおける新たな参加者は、そのビジネスと最もよく適合する標準化されたＢＩＤの一つを、ベーシックインタフェース定義として、選択する。更に、リポジトリは一組のサービスビジネスインタフェース定義８０５を記憶する。例えば、注文エントリＢＴＤ８０６、注文トラッキングＢＩＤ８０７、注文履行ＢＩＤ８０８、及びカタログサービスＢＩＤ８０９を記憶することができる。マーケットにおける新たな参加者がビジネスインタフェースの定義を構築する際に、リポジトリ内に記憶される標準化されたサービスのビジネスインタフェース定義を選択することができる。
【００７６】
パーティ及びサービスＢＩＤに加えて、入力及び出力ドキュメントＢＩＤが、フィールド８１０によって指示されるリポジトリに記憶される。従って、購入注文ＢＩＤ８１１、請求書ＢＩＤ８１２、見積り要求ＢＩＤ８１３、製品入手可能リポートＢＩＤ８１４、及び注文状態ＢＩＤ８１５をリポジトリに記憶することが出来る。
【００７７】
リポジトリは、好適なシステムにおいては、ＸＭＬに従ったドキュメント形態の定義として特定されるビジネスインタフェースの定義に加えて、フィールド８１６によって指示される様なセマンティックマップの形態で解釈情報を記憶する。従って、重量８１７、通貨８１８、サイズ８１９、製品識別８２０、及び製品特徴８２１を特定するために使用されるセマンティックマップをリポジトリ内に記憶することができる。更に、解釈情報は、ドキュメントの論理構造内のデータ構造を分類分けすることに備える。
【００７８】
更に、ビジネスインタフェースの定義を構成する際に使用される論理構造は、ブロック８２２によって指摘されるリポジトリに記憶される。従って、アドレス情報８２３を与えるためのフォーム、価格情報８２４を与えるためのフォーム、契約上関係の期間８２５を与えるためのフォームを提供することができる。ネットワークが拡張される時、ＣＢＬリポジトリも同様に拡張し、標準化は、新たな参加者が加わること及びビジネスインタフェースの定義をより容易にする。
【００７９】
図９は、図７のシステムを使用するビジネスインタフェース定義を構築するプロセスを図示している。プロセスは、ＢＩＤビルダーグラフィカルインタフェースをユーザに表示することによって開始される（ステップ９００）。システムは、グラフィカルインタフェース（ステップ９０１）によって発生された参加者、サービス及びドキュメント情報を識別するユーザ入力を受け入れる。
【００８０】
次に、如何なる参照論理構造、解釈情報、ドキュメント定義、及び／又はサービス定義は、ユーザ入力に応答してグラフィカルユーザーインタフェースを介してリポジトリから検索される（ステップ９０２）。次のステップで、相補的ビジネスインタフェース定義又はビジネスインタフェースの定義の成分が、カスタム化された検索エンジン、ウェブブラウザ、又は他の方法によって、ユーザー入力を介して選択されたネットワーク内の他の参加者からアクセスされる（ステップ９０３）。参加者に対するドキュメントの定義は、集められた情報を使用して発生される（ステップ９０４）。ドキュメントからホストへ及びホストからドキュメントへの各マッパーに対するトランスレータが、コンパイラによって発生される（ステップ９０５）。定義に対応するホストアーキテクチャデータ構造はコンパイラによって発生される（ステップ９０６）。そして発生されたビジネスインタフェースの定義は、ウェブサイト又は他の場所にポスト送付することにより、ネットワーク上にポスト送付され、ネットワーク内の他のノードにアクセス可能となるされる。（ステップ９０７）。
【００８１】
ビジネスインタフェースの定義は潜在的な商業パートナーに対して会社がオファーしたオンラインサービスを告げ、且つこれらのサービスを実施するのに使用するドキュメントを告げる。従って、サービスは、サービスが受け取り且つ発生するドキュメントによってビジネスインタフェースの定義で定められる。このことは、ＸＭＬサービスの定義の以下のフラグメントに例示されている。
【００８２】

【００８３】
このＸＭＬフラグメント（ｆｒａｇｍｅｎｔ）は、２つの処理からなるサービス、すなわち、１つは注文（ｏｒｄｅｒ）を取得する処理及びもう１つはそれに追従する処理を定義する。それぞれの定義は、もし正当な要求が特定のＷｅｂアドレスに提示されたなら、サービスを実行するための契約（ｃｏｎｔｒａｃｔ）又は約束（ｐｒｏｍｉｓｅ）を表現する。ここで注文サービスは、ローカルであるか、あるいはネットワーク上の産業全体のレジストリ中に記憶されたものでよいリポジトリ（ｒｅｐｏｓｉｔｏｒｙ）中に置かれている、標準の「ｐｏ．ｄｔｄ」ＤＴＤ（Ｄｏｃｕｍｅｎｔ Ｔｙｐｅ Ｄｅｆｉｎｉｔｉｏｎ）に適合する、入力されるドキュメント（ｄｏｃｕｍｅｎｔ）を必要とする。もし１つのノードがその注文を実行できるなら、そのノードは、定義がローカルである、カスタマイズされた「ｉｎｖｏｉｃｅ．ｄｔｄ」に適合するドキュメントを返すであろう。実際には、会社は、それが宣言するＸＭＬ仕様に適合する購入注文を提出できる誰とでも、ビジネスを行う約束をしている。事前の調整は不要である。
【００８４】
ＤＴＤは、所定の型のドキュメントのための公式の仕様すなわち文法であり、それは、要素、それらの属性、及びそれらが表示されなければならない状態を記述する。例えば、購入注文は、購入者及び販売者の名前及び住所、一組の製品説明、及び価格及び配達日のような関連する売買条件を典型的には含む。エレクトロニック・データ・インターチェンジ（Ｅｌｅｃｔｒｏｎｉｃ Ｄａｔａ Ｉｎｔｅｒｃｈａｎｇｅ，ＥＤＩ）では、例えばＸ１２ ８５０仕様は、購入注文のために普通に使用されるモデルである。
【００８５】
リポジトリによって、多くのビジネス領域で共通の、再使用可能な意味の成分（ｒｅｕｓａｂｌｅ ｓｅｍａｎｔｉｃ ｃｏｍｐｏｎｅｎｔｓ）から、ＸＭＬドキュメントモデルを開発することが促進される。そのようなドキュメントは、たとえそれらの見かけが全く異なっていたとしても、それらの共通のメッセージ要素から理解することができる。これは、コモン・ビジネス・ライブラリ・リポジトリ（Ｃｏｍｍｏｎ Ｂｕｓｉｎｅｓｓ Ｌｉｂｒａｒｙ ｒｅｐｏｓｉｔｏｒｙ）の役割である。
【００８６】
コモン・ビジネス・ライブラリ・リポジトリは、以下を含む、一般的なビジネス概念のための情報モデルからなる。
・会社、サービス、及び製品のような、ビジネス記述プリミティブ（ｂｕｓｉｎｅｓｓ ｄｅｓｃｒｉｐｔｉｏｎ ｐｒｉｍｉｔｉｖｅ）、
・カタログ、購入注文、及びインボイスのようなビジネス形態、
・標準の測定値（ｓｔａｎｄａｒｄ ｍｅａｓｕｒｅｍｅｎｔｓ）、日時、位置、分類コード、である。
【００８７】
この情報は、会社がＸＭＬアプリケーションを迅速に開発するためにカスタマイズしかつ組み立てることができる、拡張可能で公開されたＸＭＬ構成ブロック（ＸＭＬ ｂｕｉｌｄｉｎｇ ｂｌｏｃｋ）として表現される。微少の（ａｔｏｍｉｃ）ＣＢＬ要素は、国、通貨、住所（ａｄｄｒｅｓｓ）、及び時間のための標準ＩＳＯコードのような、産業界のメッセージング規格及び慣習（ｉｎｄｕｓｔｒｙ ｍｅｓｓａｇｉｎｇ ｓｔａｎｄａｒｄｓ ａｎｄ ｃｏｎｖｅｎｔｉｏｎｓ）を実行する。低レベルのＣＢＬセマンティクス（ｓｅｍａｎｔｉｃｓ）は、ダブリン・コア（Ｄｕｂｌｉｎ Ｃｏｒｅ）のような、インターネット・リソースのための、提示されたメタデータ構成（ｍｅｔａｄａｔａ ｆｒａｍｅｗｏｒｋ）の分析からも得られる。
【００８８】
次のレベルの要素は、これらの構成ブロックを使用して、ＯＴＰ（Ｏｐｅｎ Ｔｒａｄｉｎｇ Ｐｒｏｔｏｃｏｌ）及びＯＢＩ（Ｏｐｅｎ Ｂｕｙｉｎｇ ｏｎ ｔｈｅ Ｉｎｔｅｒｎｅｔ）のような、出現したインターネット規格で使用されるビジネス形態だけでなく、Ｘ１２ ＥＤＩ処理で使用されるもののような基本的なビジネス形態も実行する。
【００８９】
ＣＢＬの主眼は、全てのビジネス領域（会社、サービス、及び製品のような、ビジネス記述プリミティブ；カタログ、購入注文、及びインボイスのようなビジネス形態；標準の測定値、日時、位置、分類コード）に共通の機能及び情報にある。ＣＢＬは、可能な場合の意味論のための規格又は産業界の慣習に依存している（例えば、ヨーロッパでの「日／月／年」に対してアメリカでの「月／日／年」を指定する規則は、別個のＣＢＬモジュール中にコード化される）。
【００９０】
ＣＢＬは、アプリケーションを設計するために使用される言語である。それは、ＸＭＬの「ドキュメント・ワールド」と、ＪＡＶＡの「プログラミング・ワールド」又は他の処理プロセスアーキテクチャとの間のギャップを橋渡しするように設計されている。スキーマ（ｓｃｈｅｍａ）は、ドキュメントタイプの詳細な公式の仕様が種々の関連する形態がそこから生成されるようなマスター・ソース（ｍａｓｔｅｒ ｓｏｕｒｃｅ）である、「ドキュメントによるプログラミング」の思想を具体化する。これらの形態は、ＣＢＬ、ＪＡＶＡオブジェクト、ＸＭＬのインスタンスと対応するＪＡＶＡオブジェクトとの間の変換プログラム、及びサポート・ドキュメントのためのＸＭＬ ＤＴＤを含む。
【００９１】
ＣＢＬは、そこからシステムのほとんど全ての部分が自動的にコンパイラによって生成されるような単一のソースを作り出す。ＣＢＬは、それぞれの情報の要素及び属性と関連するセマンティクスの仕様を含むように、特定のドキュメントタイプの構造を公式に定義するために通常使用されるＳＧＭＬ／ＸＭＬを拡張することによって機能する。ＳＧＭＬ／ＸＭＬでの（ほとんどの）限られた組のキャラクタタイプを、任意の種類のデータタイプを宣言するために拡張することができる。
【００９２】
これは、「ｄａｔｅｔｉｍｅ」モジュールのためのＣＢＬ定義からのフラグメントである。

【００９３】
このフラグメントでは、ＥＬＥＭＥＮＴ”ｙｅａｒ”は、キャラクタデータ及び関連する”ｓｃｈｅｍａ”属性として定義され、キャラクタデータも、ＩＳＯ８６０１規格のセクション３．８になるように”ｙｅａｒ”のためのスキーマを定義する。
【００９４】
この”ｄａｔｅｔｉｍｅ”ＣＢＬモジュールは、実際は、スキーマＤＴＤのインスタンスとして定義される。最初に、モジュール名が定義される。次に、”ｄａｔｅｔｉｍｅ”要素の”ＹＥＡＲ”は、ＩＳＯ８６０１規格のセマンティクスに結合させられる。
【００９５】

【００９６】
例のマーケットの参加者及び上記のサービスモジュールも、ＣＢＬリポジトリ中に記憶される。
【００９７】
図１０では、航空貨物受取証（Ａｉｒｂｉｌｌ）１０００が、一般的な購入注文ＤＴＤ１００１をカスタマイズし、出荷重量１００２についてのより具体的な情報を追加することによって定義されているところである。一般的な購入注文１００１は、住所、日時、通貨、及び販売者及び製品説明のためのＣＢＬモジュールから、広範囲にわたって、最初に組み立てられた。このように、ＣＢＬを使用することにより、ＸＭＬ商用アプリケーションのインプリメンテーションはかなり促進される。より重要なことに、ＣＢＬによって、商用アプリケーションを相互接続することが簡単になる。
【００９８】
ＣＢＬでは、ＸＭＬはスキーマにより拡張される。拡張によって、内容を簡単に確認できるように、ＸＭＬ要素に強調タイピング（ｓｔｒｏｎｇ−ｔｙｐｉｎｇ）が追加される。例えば、＜ＣＰＵ ｃｌｏｃｋ ｓｐｅｅｄ＞と呼ばれる要素は、一組の正当な値（ｖａｌｉｄ ｖａｌｕｅ）：｛１００，１３３，１６６，２００，２３３，２６６ Ｍｈｚ｝を有する整数として定義されることができる。スキーマは、情報をクラスの定義から簡単にインスタンス生成することができるように、クラス−サブクラスの階層も追加する。例えば、ラップトップを、ディスプレイのタイプ及びバッテリの寿命のような特徴のための追加のタグを有するコンピュータとして記述することができる。これら及び他の拡張により、ＸＭＬと伝統的なオブジェクト指向及び関係データモデルの間の自動翻訳だけでなく、データ入力も容易になる。
【００９９】
このようにして、完成されたＢＴＤは、参加者及び上記に概説したサービスの実際のインスタンス、ＤＴＤインスタンスの論理的構造に対応するＪＡＶＡビーンズ（ｂｅａｎｓ）、及びＸＭＬからＪＡＶＡに及びＪＡＶＡからＸＭＬに変換する変換コードのためのＤＴＤを作り出すコンパイラを通して実行される。他のシステムでは、オブジェクトを使用しやすくするために、ドキュメントも、ユーザインターフェース上のディスプレイのために、又はユーザによる印刷のために生成される。
【０１００】
例えば、市場参加者及び前述のサービスＤＴＤ、コンパイラによって生成されたＪＡＶＡビーンズは、（簡潔のためいくつかの修正を加えて）以下のように示される。

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

【０１０１】
ドラッグ、ドロップ及び形を編集するユーサインターフェースを提供する、ＢＩＤコンポーザ（ｃｏｍｐｏｓｅｒ）アプリケーションと一緒にツールを使用して、開発者は、ビジネスインターフェースの定義を作り出すことができ、及び、良好に形成された、有効なビジネスインターフェースの定義をＸＭＬドキュメントの形態で生産することができる。このように、例のランタイム・インスタンスは、ＩＢＭからラップトップコンピュータを注文するために、イングラム・マイクロ（Ｉｎｇｒａｍ Ｍｉｃｒｏ）によって使用される、ＩＢＭのためのサービスを注文するためのビジネスインターフェースの定義である。（出願人と、ＩＢＭ又はイングラム・マイクロの間には関係はない。）これらのプロセスを利用すると、ユーザは、本発明に従って定義されたドキュメントを使用して、ビジネスインターフェースのプログラムができるシステムを構築することができる。
【０１０２】
ＸＭＬ／ＪＡＶＡ環境における本発明のＣＢＬ及びＢＩＤプロセッサの役割は購入注文の処理の以下の説明によりさらに理解できるであろう。
【０１０３】
会社ＡはＣＢＬ ＤＴＤ及びモジュールのライブラリを含む視覚プログラム環境を使用するその購入注文ドキュメントを定義し、全ては共通のビジネス言語エレメントを使用して定義され、それらがデータタイプ及び他の翻訳情報を含むようになっている。会社ＡのＰＯはＣＢＬライブラリに付属しているより一般的なトランザクションドキュメント仕様に対してマイナなカスタマイゼイションを含むかもしれないし、或いは、アドレス、データ及び時間、電流等のためＣＢＬモジュールからのグランドから作られるかもしれない。
【０１０４】
（上記したｔｒａｎｓａｃｔ．ｄｔｄのような）一般的なトランザクションドキュメント仕様のドキュメントはＣＢＬ仕様がモジュールから作られ、他のＣＢＬ ＤＴＤと連結される方法を類型化する。
【０１０５】
コンパイラは購入注文の定義を取り、幾つかの異なるターゲット形式を発生する。これらのターゲット形式のすべては元の仕様の「ツリーツーツリー（ｔｒｅｅ ｔｏ ｔｒｅｅ）」変形を介して得ることができる。この例にとって最も重要なのは、
（ａ）購入注文のためのＸＭＬ ＤＴＤ
（ｂ）購入注文のためのデータ構造を含むＪＡＶＡビーン（Ｂｅａｎ）（ＪＡＶＡクラス、引数、データタイプ、方法、及び例外構造は購入注文のスキーマ定義の情報に対応して作り出される。）
（ｃ）購入注文ＤＴＤに従う購入注文を購入注文ＪＡＶＡビーンに変換し、又は、それらをデータベースにロードし、又は、ブラウザに購入注文を表示するためＨＴＭＬ（又はＸＳＬスタイル集）を作り出す整列プログラム
（ｄ）購入注文ＪＡＶＡビーンからデータ値を引き出し、それらを購入注文ＤＴＤに従うＸＭＬドキュメントに変換する整列しないプログラム
今、シナリオに戻ると、購入の申し込みは購入注文を発生し、該購入注文は購入注文を受け入れる供給者のためのサービスインターフェースとして明記されたＤＴＤに従う。
【０１０６】
パーサは購入注文ＤＴＤを使用し、エレメント及びそれが含む属性値についての情報ストリームへの購入注文インスタンスを分解する。その後、これらのプロパティセットはそれらをＪＡＶＡコードと重ねることにより対応するＪＡＶＡイベントオブジェクトに変換される。事実上、この変換は文法がＤＴＤにより定義される顧客プログラム言語の命令として印を付けたＸＭＬドキュメントの部分を処理する。これらのＪＡＶＡイベントはコンパイラにより生成された整列しているアプリケーションにより処理され、ＪＡＶＡビーンのデータ構造をロードすることができる。
【０１０７】
ＸＭＬドキュメントをＪＡＶＡアプリケーションのための１セットのイベントに変換し、処理することは、解析をする正常なモデルとは異なり、解析が完了するまで内部データ構造及び処理は開始しないので、パーサ出力は維持される。ＢＩＤ定義に応じたイベントベースの処理は、最初のイベントが発せられると直ぐに同時に発生のドキュメントアプリケーション処理を始めさせるので、、プロセッサの非常に優れた機能を可能にする鍵である。
【０１０８】
各種タイプのイベントに聞くＪＡＶＡプログラムはそれらのイベントのスキーマ定義から形成される。これらのリスナーはＣＢＬのＸＭＬ定義と関連するビジネス論理を実行するために作り出されたプログラムであり、例えば、アドレスエレメントと関連し、データベースをチェックすることにより郵便番号を確認するコードであってもよい。これらのリスナーはドキュメントルータで登録することによりイベントに応募し、それらに興味を示したすべての応募者に関連したイベントを割り当てる。
【０１０９】
新規のリスナーがプログラムするこの公表し、応募したアーキテクチャ手段は現存のものの知識なしに、またはそれに影響を与えることなく付加されることができる。各リスナーはルータがそのイベントを割り当てるキューを有し、複数のリスナーはそれら自身のペースで並行してイベントを取扱うことができる。
【０１１０】
ここの例示の購入注文にとって、
・注文入力プログラムにそれをつなげるであろう購入注文
・在庫をチェックするであろう製品説明書
・Ｆｅｄ Ｅｘ又は引き渡しの有効性のための他のサービスをチェックすることができるであろうアドレス情報
・（信用貸しの価値のため、又は公告を提供するため、又は顧客が誰であるかを知ることに基づく同様の処理のため）注文の履歴をチェックすることができるであろう買い手の情報
のためのリスナーであるかもしれない。
【０１１１】
複合したリスナーは初期のものの形状として作り出されることができる。（例えば、購入注文のリスナーがここのこれらのリスナーを含み、引き合いに出してもよく、又は、それらはそれら自身で引き合いに出されてもよい。）
【０１１２】
図１１は図１のネットワークでのマーケットマーカのノードを示している。マーケットマーカのノードは図３のシステムの基本構造を含み、ネットワークインターフェース１１０１、ドキュメントパーサ１１０２、ホストへのドキュメント及びドキュメント翻訳機へのホスト１１０３、フロントエンド１１０４を有し、この例ではルータと呼ばれている。この例でのマーケットマーカモジュール１１０５は１セットのビジネスインターフェース定義、又はマーケットの参加者のためマーケットマーカの機能を支援するのに十分な他の識別子、ＣＢＬリポジトリ、及びマーケットの参加者の要求をすべて満たすコンパイラを備えている。ルータ１１０４は参加者のレジストリ及びドキュメントフィルタを備え、翻訳機の出力でパーサにより生成されたイベントに応答し、参加者のレジストリにより、及びＸＭＬイベント発生器に対するリスナーの間のエレメント及び属性フィルタにより、入力ドキュメントの経路を定める。したがって、マーケットの一定の参加者は登録し、予め特定したパラメータに合うドキュメントを受け取ってもよい。例えば、特定のＤＴＤによる入力ドキュメントは、閾値以上の購入製品数、又は購入されるドキュメント要求の最大価格等の属性を含み、ルータ１１０４でフィルタドキュメントに使用されることができる。その後、ルータ１１０４で参加者のレジストリに登録された情報に合致するようなドキュメントは登録された参加者に送られる。
【０１１３】
ルータ１１０４はまたローカルホストサービス１１０５及び１１０６の要求を満たし、例えば、マーケットマーカと同様にマーケットの参加者のように作動する。通常、ルータ１１０４により受け取られたドキュメントはトラバースされ、宛先を決定し、そのようなドキュメントは送られ、そこで再度、翻訳機１１０３を介して、必要であれば、ネットワークインターフェース１１０１からそれぞれの宛先に送られる。
【０１１４】
マーケットマーカは１セットの内部及び外部のビジネスサービスと一緒に結び付けるサーバであり、仮想の計画又はトレーディングコミュニティを作り出す。サーバは入力ドキュメントを解析し、例えば、製品データのためのリクエストをカタログサーバに渡すことにより、又は、購入注文をＥＲＰシステムに送ることにより、適当なサービスを引き合いに出す。サーバはまた翻訳タスクを取扱い、トレーディングパートナにより使用されるドキュメント書式及びそのレガシーシステムにより要求されるデータ書式に会社のＸＭＬドキュメントからの情報をマッピングする。
【０１１５】
上記サービスの定義に関して、会社が購入注文を提示したとき、サーバのＸＭＬパーサは購入注文ＤＴＤを使用し、購入注文インスタンスを情報イベントのストリームに変換する。その後、これらのイベントは所定のタイプのイベントを取扱うためにプログラムされたアプリケーションに送られ、幾つかの場合には、情報はインターネットを介して異なるビジネスに完全に送られる。購入注文の例では、幾つかのアプリケーションはパーサから来る情報で作動してもよい。
・注文入力プログラムは完全なメッセージとして購入を処理する。
・ＥＲＰシステムは購入注文に記述された製品のための在庫をチェックする。
・顧客データベースは顧客のアドレスを証明し、又は更新する。
・運送会社はアドレス情報を使用し、搬送をスケジュールする。
・銀行はクレジットカードを使用し、トランザクションを許可する。
【０１１６】
トレーディングパートナーは、彼らが交換するビジネスドキュメントの構造、内容及び順序について同意するだけでよく、ＡＰＩの詳細について同意する必要はない。ドキュメントがどのように処理されるか及びどのようなアクション結果が生じるかは、厳密にサービスを提供するビジネス次第である。これは、システムレベルからビジネスレベルへの統合を高める。それは、ビジネスが、その内部技術の履行、組織化、又はプロセスにおける変更にもかかわらず、明瞭で安定なインターフェイスをそのビジネスパートナーに提供することを可能にする。
【０１１７】
図１２、１３及び１４は、図１１のシステムのマーケットメーカーノードにおいて実行されるプロセスを示している。図１２において、入力ドキュメントが、発信参加者ノードからのネットワークインターフェイスにおいて受け取られる（ステップ１２００）。ドキュメントがパースされる（ステップ１２０１）。ドキュメントが、ホストのフォーマットへ、例えば、ＸＭＬからＪＡＶＡへ変換される（ステップ１２０２）。ホストフォーマット化されたイベント及びオブジェクトが、その後、ルータサービスへ送られる（ステップ１２０３）。ドキュメントのタイプ及びドキュメントの内容に従ってドキュメントを受け入れるように記憶されたサービスが識別される（ステップ１２０４）。ドキュメント及びドキュメントの一部が、識別されたサービスに送られる（ステップ１２０５）。ドキュメントの内容に応じてサービスが実行される（ステップ１２０６）。サービスの出力データが発生される（ステップ１２０７）。出力が、ドキュメントフォーマットへ、例えば、ＪＡＶＡフォーマットからＸＭＬフォーマットへ変換される（ステップ１２０８）。最後に、出力ドキュメントが参加者ノードへ送られる（ステップ１２０９）。
【０１１８】
レジストレーションサービスは、ルータにより管理されるそのような機能の一つである。従って、マーケット参加者ドキュメントが図１３に示されるネットワークインターフェイスにおいて受け入れられる（ステップ１３００）。マーケット参加者ドキュメントがマーケットメーカーノードについてのビジネスインターフェイス定義リポジトリに記憶される（ステップ１３０１）。加えて、ドキュメントがパースされる（ステップ１３０２）。パースされたドキュメントが、ホストのフォーマットへ変換される（ステップ１３０３）。次に、ドキュメントがルータサービスへ送られる（ステップ１３０４）。ルータサービスは、レジストレーションサービスをドキュメントのタイプ及びドキュメントの内容に従ってドキュメントの宛先であると識別するリスナーを含む（ステップ１３０５）。ドキュメント及びドキュメントのエレメントが、レジストレーションサービスに送られる（ステップ１３０６）。レジストレーションサービスにおいて、必要とされるサービス仕様がビジネスインターフェイス定義に応じてリトリーブされる（ステップ１３０７）。ステップ１３０８において、サービス仕様が集められる場合には、ビジネスインターフェイス定義及びサービス仕様に従ってルータサービスフィルタがセットされる（ステップ１３０９）。レジストレーションアクノリッジメントデータが発生される（ステップ１３１０）。レジストレーションアクノリッジメントデータが、ドキュメントフォーマットへ変換される（ステップ１３１１）。最後に、アクノリッジメントドキュメントが参加者ノードへ送られてマーケットメーカーで成功裏にレジスタされた参加者に通知する（ステップ１３１２）。
【０１１９】
必要とされるサービス仕様を集めるステップ１３０７におけるプロセスは、図１４の１つの例について示されている。このプロセスは、マーケット参加者によりサポートされるサービスビジネスインターフェイス定義を探し出すことにより始まる（ステップ１４００）。サービス定義が例えば、リポジトリノードへのＥメールトランザクション又はウェブアクセスによりリトリーブされる（ステップ１４０１）。サービス仕様がＢＩＤリポジトリに記憶される（ステップ１４０２）。サービスビジネスインターフェイス定義ドキュメントがパースされる（ステップ１４０３）。パースされたドキュメントが、ホストのフォーマットへ変換される（ステップ１４０４）。次に、ホストのオブジェクトがルータサービスへ送られる（ステップ１４０５）。レジストレーションサービスがドキュメントのタイプ及び内容に従って識別される（ステップ１４０６）。最後に、サービスビジネスインターフェイス定義ドキュメントの情報がレジストレーションサービスに送られて（ステップ１４０７）、図１３のプロセスに従って使用される。
【０１２０】
図１５は、本発明に従ってマーケットメーカーノードに入力するデータを処理するプロセッサ、コンポーネント及びシーケンスを示している。マーケットメーカーノードは、ネットワークインターフェイスにおいて通信エージェント１５００を有する。通信エージェントはＸＭＬパーサ１５０１と接続され、ＸＭＬパーサ１５０１は、イベントをＸＭＬプロセッサ１５０２に供給する。ＸＭＬプロセッサ１５０２は、イベントをドキュメントルータに供給する。ドキュメントルータは、ドキュメントサービス１５０４にフィードし、ドキュメントサービス１５０４は、受け取ったドキュメントをホストシステムのエンタープライズソルーションソフトウェア１５０５に供給するインターフェイスとなる。通信エージェント１５００は、ＨＴＴＰ、ＳＭＴＰ、ＦＴＰ又は他のプロトコルのようなプロトコルを支持する適当なプロトコルスタックを有するインターネットインターフェイスである。従って、入力するデータは、特定の通信チャンネルに適合するようにＸＭＬ構文法、ＡＳＣＩＩデータ構文法又は他の構文法で入力してもよい。非ＸＭＬ構文法で受け取ったドキュメントは全てＸＭＬに変換されてＸＭＬパーサに送られる。非ＸＭＬ形式からＸＭＬ形式への変換をサポートするために変換テーブル１５０６が使用される。
【０１２１】
変換されたドキュメントはパーサ１５０１に供給される。ＸＭＬパーサは、受け取ったＸＭＬドキュメントを、それとマッチするドキュメントタイプ定義に従ってパースする。エラーが見つかった場合には、パーサがドキュメントを通信エージェント１５００へ送り返す。ビジネスインターフェイス定義コンパイラＢＩＤＣ１５０７は、ビジネスインターフェイス定義データのためのコンパイラとして働く。ＸＭＬパーサのためのＤＴＤファイル、ＤＴＤファイルに対応するＪＡＶＡビーンズ及びＤＴＤファイルをＪＡＶＡビーンズへ変換する変換ルールは、ＢＩＤデータをコンパイルすることにより作られる。これらのツールを参照することにより、ＸＭＬインスタンスがＪＡＶＡインスタンスへ変換される。そこで、ＢＩＤコンパイラ１５０７は、ＤＴＤドキュメント１５０８を記憶して１５０９に対応するＪＡＶＡドキュメントを発生する。ＸＭＬドキュメントはプロセッサ１５０２に送られ、プロセッサ１５０２は、そのドキュメントをＪＡＶＡフォーマットに変換する。好ましいシステムでは、ＸＭＬフォーマットで受け取ったドキュメントタイプ定義と同じステータスを有するＪＡＶＡドキュメントが発生される。ＪＡＶＡビーンズがドキュメントルータ１５０３に送られる。ドキュメントルータ１５０３がＪＡＶＡビーンズを受け取り、受け取ったクラスをレジストリプログラムを使用して、例えば、上述したイベントリスナーアーキテクチャを使用して、適当なドキュメントサービスに送る。ルータ１５０３からＪＡＶＡビーンズの形式でドキュメントを受け取ったドキュメントサービス１５０４は、エンタプライズソルーションソフトウェアとして働く。これは、ＸＭＬイベントのリスナーを入力するデータ流れと結合するレジストリサービス１５１０と、入力するドキュメントの適当なサービスへのルーティングを管理するサービスマネージャ１５１１とを有する。ドキュメントサービスマネージャ１５１１は、レジストリサービスの管理及びドキュメントの一貫性の維持等を行う。
【０１２２】
ドキュメントサービスは、任意のプロプラエタリＡＰＩを使用して、又は、ＣＯＲＢＡ／ＣＯＭインターフェイスその他のアーキテクチャのようなより共通な形式を使用してバックエンドシステムと通信する。
【０１２３】
図１６は、本発明に係るマーケットメーカー及びマーケット参加者構造のヒューリスティックダイアグラムである。従って、本発明に係るＥコマーストランザクションマーケットは、図１６に示されているように論理的に組織化できる。その組織の最上部において、マーケットメーカーノード１６００が設定される。マーケットメーカーノードは、マーケットプレイス１６０１を設定するリソースを含む。このようなリソースは、マーケットレジストリサービス等を含む。ビジネス１６０２は、ビジネスインターフェイス定義をパブリッシュすることによりマーケットプレイスにレジスタする。ビジネスインターフェイス定義は、ビジネスが参加するコマーシャルトランザクションについてサービス１６０３を定義する。トランザクション１６０４及びサービス１６０３は、ドキュメント１６０５を使用して入力及び出力を定め、トランザクションにおける参加者の間の商業上の関係をアウトラインする。ドキュメントは各トランザクションの詳細を含むコンテント１６０６を有する。コンテントがマーケットの参加者により及びマーケットメーカーにより処理される方法は、本発明に従って設立されるＥコマーストランザクションネットワークに基づくドキュメントに完全に依存する。全体として、通信ネットワーク上でＥコマーストランザクション可能とするように頑強性、拡張性及び直観力に富む構造が提供される。
【０１２４】
従って、本発明は、例示のシステムにおいて、ＸＭＬプロセッサに基づくプラットフォームを提供し、疎結合されたビジネスシステムの間のインターフェイスとしてＸＭＬドキュメントを使用している。ドキュメントは、ビジネスの間で転送され、会社のビジネスシステムに入る前に特定のノードによって処理される。従って、プラットフォームは、各ビジネスシステムが異なる内部コマースプラットフォーム、処理及び意味論を使用している場合に、共通の組のビジネスドキュメント及び形式を特定することによりビジネス間のＥコマースアプリケーションを可能にする。
【０１２５】
本発明によれば、ビジネスシステムとサービスを相互接続することによりバーチャルエンタプライズが形成され、主に、ビジネスが受け入れて発生するドキュメント（ＸＭＬコード化された）に間して次のとおり定義される。
「貴社が当社にカタログを請求される場合には、貴社にカタログを送ります。」「貴社が購入の注文をされ当社がそれを受け入れことができる場合には、貴社に送り状を送ります。」
上述した本発明の好ましい実施例の説明は、本発明の解説するためになされたものである。これは、包括的であること又は発明を開示した厳密な形式に限定することを意図するものではない。当業者にとって多くの修正及び変更は明らかである。本発明の範囲は、以下の請求の範囲及びそれと等価なものによって定められるものである。
【図面の簡単な説明】
【図１】 本発明によるビジネスインタフェース定義（ＢＩＤ）を含む電子商取引ネットワークの概略図である。
【図２】 本発明によるビジネスインタフェース定義ドキュメントの概略図である。
【図３】 本発明によるネットワーク中の参加者ノードのためのサーバの概念的なブロックダイアグラムである。
【図４】 本発明による参加者ノードで受け取られたドキュメントのプロセシングを説明するフローチャートである。
【図５】 ＸＭＬベースのシステムについての構文解析プログラム及びトランザクションプロセスフロントエンドのブロックダイアグラムである。
【図６】 構文解析プログラム機能のフローの概念的なダイアグラムである。
【図７】 本発明によるビジネスインタフェース定義に使用されるサーバにおけるリソースの概略図である。
【図８】 ビジネスインタフェース定義の構築のために使用する、本発明によるリポジトリの概略図である。
【図９】 本発明によるビジネスインタフェース定義を構築するプロセスを説明するフローチャートである。
【図１０】 本発明によるリポジトリの発見的概要を提供するものである。
【図１１】 ビジネスインタフェース定義に基づく本発明のネットワークのためのマーケットメーカー機能を提供するサーバにおけるリソースの概略図である。
【図１２】 受け取られたドキュメントのマーケットメーカーノードプロセシングのフローチャートである。
【図１３】 本発明によるマーケットメーカーノードにおける参加者の登録のプロセスを説明するフローチャートである。
【図１４】 図９のプロセスによるマーケットメーカーノードにおけるサービスの仕様書の提供のプロセスを説明するフローチャートである。
【図１５】 本発明によるマーケットメーカーまたは参加者における操作のシーケンスを説明するダイアグラムである。
【図１６】 本発明によるＢＩＤに基づく商取引ネットワークの要素の概念的なダイアグラムである。[0001]
(Technical field to which the invention belongs)
The present invention relates to a system and protocol for supporting transactions (transactions) between various clients connected to a network, and more particularly, to a system and protocol for supporting commercial transactions between platforms having various architectures. .
[0002]
(Conventional technology)
The Internet and other communication networks provide a means for communication between computer platforms and people that are being used for a wide variety of transactions, including commerce in which participants buy and sell goods and services. Many efforts are being made to promote commercial transactions on the Internet. However, since there are many competing standards, in order to execute a transaction, participants in that transaction must agree in advance on the protocol used, and often platform architectures to support such transactions. Requires custom integration (dedicated integration). Commercial processes into certain nodes that are not compatible with the agreed standards may require considerable rework for integration with other nodes. In addition, when one company commits to one standard or another standard, that company is pinned to the standardized group of transaction participants and the others are excluded.
[0003]
An overview of the challenges encountered in the development of Internet commerce is described in “Eco System: An Internet Commerce Architecture”, Tenenbaum et al .: Computer, May 1997; pages 48-55.
[0004]
It is desirable to standardize the architecture framework in order to open up commerce on the Internet. Platforms developed to support such commercial frameworks are IBM's Commerce Point; Microsoft Internet Commerce Frameworks; Netscape's ONE (Open NetworkEurgent); (JAVA Electronic Commerce Framework).
[0005]
In addition to these proprietary frameworks, common distributed object model programming techniques based on CORBA IIOP (Common Object Request Broker Architecture Internet ORB Protocol) are being implemented. The use of the common distribution object model is intended to make it easier to migrate an enterprise system to a system that can be interoperated at the business application level for electronic commerce. However, a consumer or business using one framework cannot execute transactions on different networks. This limits the growth of electronic commerce systems.
[0006]
A company that implements one framework will have an application programming interface (API), which will be different from APIs that support other frameworks. Therefore, it is very difficult for companies to access each other's business services without having to adopt a common business system interface. Developing such business system interfaces at the API level requires considerable cooperation between the parties, but this is often not practical.
[0007]
Accordingly, it is desirable to provide a framework that facilitates interaction between various platforms within a communication network. Such a system would facilitate voluntary business among trading partners without the need for prior consent to custom integration or wide industry standards. In addition, such a system will drive progress towards business automation and eliminate much of the time, cost and risk of traditional system integration.
[0008]
In general, it is desirable to provide an electronic commerce system that replaces a closed commercial partner network based on proprietary standards with an open market.
[0009]
(Summary of Invention)
The present invention provides an infrastructure for connecting businesses to customers, suppliers and commercial partners. Under the infrastructure of the present invention, companies can communicate with each other using self-defining machine-readable documents (eg, XML (Extensible Markup Language) documents that can be easily understood by partners). And exchange services. A document describing a document to be exchanged (referred to herein as a business interface definition or BID) is sent over the Internet or communicated to members of the network. The business interface definition (BTD) tells potential commercial partners the services that the company provides and the documents to use when communicating with those services. Thus, a typical business interface definition allows a customer to place an order by submitting a purchase order (a purchase order that conforms to the document definition issued with the BID of the party receiving the purchase order). The supplier can check its validity by downloading an inventory status report according to the document definition issued with the BID of the business system management inventory data. The use of predefined machine readable business documents provides a more intuitive and flexible way to access enterprise applications.
[0010]
A node in a commercial network is an interface for a transaction according to the invention consisting of a machine readable specification of an interface, and a machine readable including interpretation information for the machine readable specification of that interface. Establish with data structure. The machine readable specification of an interface includes an input document definition and an output document definition, which are accepted and created by a transaction processor in which the node acts as an interface. The definition of the input document and the definition of the output document include, for example, a description of a set of storage units and a logic structure for the set of storage units, respectively, according to standard XML-based documents. Machine-readable data structures containing interpretation information according to various aspects of the present invention include data type specifications (eg, strings, arrays, etc.), logic structures for logic structures in the definition of input and output documents. Including a data structure that maps a predefined model of a storage unit for a specific logic structure to each entry in the list of content and / or content models (eg, a list of possible values) and / or logic Provide a semantic definition of the structure (eg, mapping code to generate a name).
[0011]
In accordance with another aspect of the invention, the interface includes a repository in memory (which stores a logic structure library and logic structure interpretation information) accessible by at least one node of the network. This repository can be extended to include a library of input and output document definitions, a library of interface specifications, and a library of specification of interface nodes of network participants.
[0012]
Accordingly, participants in the transaction framework of the present invention execute transactions between multiple nodes of the network, including multiple node execution processes included in the transaction. The method of the present invention includes storing a machine readable specification of an interface for a transaction, the specification including an input document definition and an output document definition. The input and output document definitions each contain a description of a set of storage units and a set logic structure of storage units. In the preferred system, these definitions are extended and expressed by semantic mapping, content modeling, and some element data typing in a manner that follows the standard XML document type definitions, ie DTD. Transaction participants receive data, including documents, over a communication network. Participants parse the document according to the specifications stored for the transaction and identify the input document for the transaction. After parsing the document, at least a portion of the input document is provided in a machine readable format to a transaction process that provides output. The output document is configured to configure the output of the transaction process based on the stored specification output document definition. The output document is sent over a communications network, typically back to the source of the input document, or sent elsewhere for the specific type of needs of the transaction.
[0013]
Thus, the definition of the business interface bridges the gap between documents running for example on the front end of the transaction processing service front-end at a document and a special node, for example. These front ends are implemented, for example, by JAVA virtual machines or by other common architectures that provide for the interconnection of systems at both ends of the network. Business interface definitions provide the technology by which transaction protocols are programmed using business interface definitions. The program for this transaction protocol is given by a detailed official specification in document format.
[0014]
The machine read specification of the transaction interface is made accessible to other platforms in the network. Participant platforms include resources to design input and output documents with transaction interfaces specified at complementary nodes. Thus, the participant's node includes resources that access the input document definition for the complementary interface and the output document definition for the complementary interface. A specification stored for the accessing participant node is established by including at least part of the complementary interface output document definition in the interface input document definition stored in that specification. Is done.
[0015]
The process of establishing a stored specification for an interface according to another aspect of the invention includes accessing machine readable specification elements from a repository. This repository stores a logical structure, a content model, a library of schematic maps for the logical structure, and a definition of the document having the logical structure used to build the interface description. A repository accessible in the network facilitates the construction of interface descriptions that can be easily shared. Any differences between the input document formed for the special process and the complementary process expected as a return process agree on a common logical structure that represents the network communication and special information. Easily negotiated by.
[0016]
A machine readable specification of a transactional interface according to one aspect of the present invention includes a document that conforms to the definition of an interface document shared among members of a network. The interface document definition has a logical structure for storing a special transaction identifier and a reference to the definition of the input / output document for at least one of the definitions and the special transaction. That is, the interface description for the special service actually contains the definition of the input / output document. Instead, it can include a location in the repository for such definitions, or a pointer to somewhere in the network.
[0017]
According to another alternative of the present invention, the machine-readable specification stores a reference to the specification of one or more transaction sets supported by the interface and for storing an identifier of the interface and at least one of the specifications. A business interface definition BID document that conforms to the definition of the interface document that contains the logical structure to store. For each supported transaction, the document contains at least one definition and a reference to the input / output document definition for the special transaction.
[0018]
According to another feature of the invention, the storage unit defined in the input / output document definition document identifies the analyzed data including text characters encoding the character data, and the set of storage units according to the logical structure of the input / output document. To have markup data. According to another feature of the invention, at least one of the set of storage units encodes a plurality of text characters that provide a natural language. This facilitates the use of input / output document definitions by human readers and developers of these documents.
[0019]
According to another feature of the invention, the specification of the input / output document includes translation information for at least one of the set of storage units identified by the logical structure. The translation information in one example encodes a definition for the analyzed character set. In another example, translation information is provided for the content model specification. For example, it requires a particular logical structure to place a large list of mapped codes to create descriptions in a catalog. In some systems, the storage unit in the logical structure of the document contains a set of data that has not been analyzed to meet the special needs of execution.
[0020]
According to another feature of the invention, the transaction process in a special platform has a transaction processing architecture that is one of a plurality of variant transaction processing architectures. Thus, the participant node includes a resource for converting at least a portion of the input document into a format readable to the modified transaction processing architecture of the information utilizing transaction. Document-defined elements include variables and methods according to a modified transaction processing architecture of the transaction process. For participants who have a JAVA virtual machine that acts as the front end of the transaction process, the special fields in the document are not only translated into JAVA objects containing data, but also get and set functions related to JAVA objects. . Other transaction processing architectures that can be supported by the present invention include the Common Object Request Broker Architecture CORBA, the Component Object Model COM, the On-Line Transaction Processing OLTR, and the Electronic Data Description Interface Interface in the Electronic Data Interlingual Interface Description.
[0021]
According to another aspect of the invention, a repository is provided for storing document formats used in multiple transactions. A machine readable specification for a particular transaction defines at least one of the input and output documents by referring to the document format in the repository. According to another feature, the document format contained in the repository has a document format for identifying participants in the network. Such a document format provides a structure for identifying a participant, identifying services supported by the participant, and identifying input / output documents for each of these services.
[0022]
In addition to the method described above, the present invention provides a network interface, a memory for storing a program of data and instructions, including a machine-readable specification of the interface for transactions as described above, and a memory and network interface. An apparatus for managing a transaction between nodes including a data processor connected to a network is provided. The program of instructions stored on the device includes logic to perform the above-described process for the participants in the transaction.
[0023]
The present invention further provides an apparatus for establishing a participant interface for transactions executed on a system including a network and data processing resources for performing transaction processing according to a transaction processing architecture. The apparatus is executable by the system and includes a program of instructions stored on a medium accessible by the system that provides a tool for building a participant interface definition for the participant in a particular transaction. Participant interface definitions include input document definitions and output document definitions. The input / output document definition has a machine readable description of each of the set of storage units in the logical structure for the set of storage units, and it follows the definition of the XML document format as one feature of the present invention. be able to.
[0024]
An apparatus for configuring a participant interface according to this aspect of the invention also includes a program of instructions stored on a medium accessible by a data processing system, and for converting an input document into a corresponding data structure. Input adapted to the transaction processing architecture to compile instructions executable by the system to compile instructions executable by the system and to compile the instructions executable by the system to translate the output of the transaction processing into a set of output document storage and logic structures And responding to the input and output document definitions to compile the logical structure of the output document and a data structure corresponding to the set of storages.
[0025]
A tool for building the definition of a participant interface in the preferred system is a definition from a repository that stores the logical structure used to build the interface description and a library of interpretation information for the logical structure and / or from complementary nodes. Instructions executable by the system to access the components of According to various aspects of the invention, the repository includes not only a library of logical structures, but also definitions of documents that have a format for identifying logical structures and participant interfaces. In accordance with this aspect of the invention, a tool is provided for building a business interface specification according to the techniques described above in connection with the description of a participant node. A tool for building an interface according to this aspect of the invention and a tool for compiling the interface into the necessary resources for communication with a transaction processing architecture are implemented at a participant node in a preferred system and input and Used to develop and optimize interface descriptions as the use of the network grows based on the interface descriptions that define the output document.
[0026]
Accordingly, another aspect of the present invention includes a memory and a data processor that executes instructions stored in the memory, including a tool for building a participant interface definition and a compiler that performs the functions described above. Providing equipment.
[0027]
According to yet another aspect of the present invention, the use of the participant interface description enables the operation of the market maker node. In such a node, a method for managing a transaction comprising storing a transaction supported by the interface and a machine readable specification of a plurality of participant interfaces identifying each input and output document of such transaction. Is provided. As mentioned above, the input and output documents comprise a description of each of the storage unit and the set of logical structures for the storage unit, as per the XML standard. In addition, the transaction definitions and participant interface definitions all comprise documents specified by techniques that conform to XML or other standardized document representation languages. In such a market maker node, data comprising documents is received over a communication network. The document is parsed by the specification to identify the input document in one or more transactions that accept the identified input document. At least a portion of the input document is provided in a machine readable format for transaction processing associated with one or more identified transactions. A method of providing at least a portion of an input document for transaction processing includes performing routing processing according to a processing architecture at a market maker node. The routing process in one form of the invention is performed by a specific processing architecture, and at least a portion of the input document is converted to the format of the processing architecture of the routing process. The transformation according to the preferred form involves generating programming objects including variables and methods according to the processing architecture of the routing process.
[0028]
According to another aspect of the invention, the market maker node also supports a repository structure. Thus, processing is included at the market maker node to allow access by the network participants to the repository stored at the market maker node. As described above, the repository includes instances of business interface definitions that contain logical structure definitions, interpretation information, and participant node document definitions and identify participants to build a transaction interface document, and each Includes transactions executed by participants.
[0029]
The routing process can, by various alternatives, convert the input document to a variable processing architecture of the process in which the document is sent, send the input document in its original document format over the network to the remote processing node (routing), or so A combination of different processes. In the alternative, the routing process is also a technique for converting an input document defined by one input document definition into a different document defined by a different document specification for the process registered to wait for the input document. including.
[0030]
A market maker node is also provided by the present invention as a device that includes a network interface, a memory for storing program and data of instructions including specifications for participant interfaces, and a data processor. The logic is supplied by the data processor in the form of a program of instructions or the like to perform market maker processing as described above.
[0031]
Thus, the present invention provides a basis for electronic commerce based on sharing input and output documentation specifications. The document provides an intuitive and flexible way to access business services that are easier to implement than programming APIs. If a company already agrees, interconnecting such companies with exchanged documents is always easier than a different business system interface. In addition, such documents are identified in a human readable format in the preferred embodiment. In accordance with the present invention, the business interface is specified in a document such as an XML document that can be easily interpreted by humans as well as computers.
[0032]
The use of the document-based transaction architecture of the present invention involves the use of a parse that operates in essentially the same manner as any source of the document, and a custom for extracting and integrating information from each participant in the network. • Eliminate many needs for programs. So integrating business information from accounting, purchasing, manufacturing, delivery and other functions first converts each source into a document with the architecture according to the invention and then processes the parsed data stream. Can be achieved. Each node of the system participating in the market only needs to know the format of its internal system as well as the format of the document specified for exchange by the transaction. Thus, there is no need to be able to generate a native format for all other nodes that wish to participate in the e-commerce network.
[0033]
For complete business integration, the present invention provides a repository of standardized logical structures, such as XML components, attributes or metadata, between semantic languages for specific commerce communities, between different metadata descriptions. Set up a means for mapping and a server to process the document and invoke the appropriate applications and services. The basic building block of the network according to the present invention is an interface definition that informs potential trading business partners what online services the company provides and what documents to use to invoke the services; and trading Includes a server that provides a bridge to combine a set of internal and external business services with each other to create a community. The server operates to parse the input document and invoke the appropriate service. The server according to the invention also handles the conversion task from the format of the received and transmitted documents to and from each host system format. Thus, trading partners need to agree only on the structure, content and sequencing of the exchanged business document, not the details of the application programmer interface. The way the document is processed and the actions that result from the receipt of the document depend entirely on the business providing the service. This improves integration from the system level to the business level. It can allow a business to present a clear and stable interface to its partner despite changes in its internal technology implementation, organization or processing.
[0034]
All processes that can build business interface definitions and allow the server to manage commerce with such descriptions are business description primitives such as companies, services and products, catalogs, purchase orders, and invoices. Easily done by a common business library or repository of information models for common business concepts including standard measures, including business forms and time and date, location and merchandise classification.
[0035]
Other aspects of the invention will be understood by consideration of the drawings, detailed description, and claims set forth below.
[0036]
(Detailed explanation)
The invention will be described in detail in connection with the drawings. FIG. 1 illustrates a network of market makers and market participants based on the use of business interface definitions, and support for the exchange of input and output documents specified according to the previous description of the interface. The network includes a plurality of nodes 11-18 connected to each other via a communication network such as the Internet 19 or other telecommunications or data communication network. Each of the nodes 11-19 comprises a computer such as a portable computer, desktop personal computer, workstation, system network, or other data processing resource. The node includes a memory for storing business interface definitions, a processor for executing a transaction process that supports commercial transactions with other nodes in the network, and the processor for supporting such services A computer program executed by the program is included. In addition, each node includes a network interface for providing communication across the Internet 19 or other communication network.
[0037]
In the environment of FIG. 1, nodes 11, 12, 13, 14, 16, and 18 are designated market participants. Market participants include resources for consumers or suppliers of goods or services that are traded according to a commercial transaction established in accordance with the present invention.
In this example, nodes 15 and 17 are market maker nodes. The market maker node includes a resource for registering a business interface definition called a BID registry. Participants can send documents to the market maker where they are identified and routed to the appropriate participants registered to receive such documents as input. Market makers also facilitate commerce networks by maintaining a repository of standard forms that constitute a common business library for use in building business interface definitions.
[0038]
In this example, the market participant 18 is directly connected to the market maker 17 without going through the Internet 19. This direct connection to the market maker actually uses a public network such as the Internet 19 and a private connection such as a local area network or a point-to-point connection as shown between nodes 17 and 18. The introduction shows that the form of network that supports commerce transactions can be quite diverse. Actual communication networks are quite diverse and suitable for use in establishing a commerce transaction network according to the present invention.
[0039]
FIG. 2 is a heuristic diagram of the renormalized structure in a business interface definition (BID) established for market participants in a network according to the present invention. The business interface definition shown in FIG. 2 is a data structure consisting of storage units and logical structures arranged in accordance with a document structure format definition, such as an XML document type definition DTD. The structure of FIG. 2 includes a first logical structure 200 for identifying vertices. Associated with the logical structure 200 is a renormalized logical structure 201 for carrying names, a physical address 202, a network address or location 203, and a transaction 204 for a set of services. For each transaction in the service set, an interface definition is provided that includes transaction BID 205, transaction BID 206, and transaction BID 207. Logic for including in each transaction BID, such as transaction BID 205, a name 208, a network location 209 where the service is executed, an operation 210 executed by the service, and an input document 211 indicated by a set of tags. Structure is provided. The service BID 205 includes an output document 212 indicated by a set of tags. The set of input documents 211 includes a business interface definition for each input document that the service is directed to respond to, including input document business interface definitions 213, 214, and 215. The business interface definition for the input document includes a name 216, a network location 217 where the document description can be found, and a module 218 to be carried in the document as indicated by the field. Similarly, output document set 212 includes interface definitions for output documents, including output document BID 219, output document BID 220, and output document BID 221. For each output document BID, a name 222, a location 223 on the network or elsewhere, and a document module 224 are identified. The business interface definition for the participant shown in FIG. 2 includes an actual definition of the logical structure to be used for each service's input and output documents, or a pointer or other reference to a location where the definition can be found. Contains.
[0040]
In the preferred system, the document of FIG. 2 is specified in the XML document type definition DTD, but other document definition architectures can also be used, and translation information about the logical structure used to translate the document request. Is included. Further, each of the transaction BID, the input document BID, and the output document BID is specified according to the XML document type definition. An XML type document is an example of a system based on parsed data including markup data and character data. Markup data identifies the logical structure in the document, and the set of character data identifies the contents of the logical structure. In addition, unparsed data can be transported through the document for various purposes. For example, WWW. W3. See the Extensible Mark-up Language XML 1.0 REC-XML-19980210 specification published by the WC3 XML Working Group at ORG / TR / 1998 / REC-XML-19980210.
[0041]
Thus, in the illustrated system, participant nodes in the network establish a virtual enterprise by interconnecting business systems and services with XML encoded documents that are accepted and generated by the business. For example, if a business interface definition for a particular service receives a document that matches a BID of a request for catalog entry, it establishes returning a document that matches the BTD of the catalog entry. Also, a document that matches the BID of the purchase order is received, and if it is acceptable for the terminal that received the document, the document that matches the BID of the invoice is returned. A node in the network processes the XML document before it enters the local business system established according to the various transaction processing architectures of any given system in the network. Thus, the system decodes a related document set, such as a MIME-encoded XML document set, and parses it to create a stream of “markup messages”. This message is routed to the appropriate application and service using, for example, an event listener model as described below.
[0042]
Documents exchanged between business services are encoded using an XML language (a common business language) generated from a repository of building blocks from which more complex document definitions can be generated. A repository is a business description primitive such as company, service, product, catalog, purchase order, business form like invoice, standard measurements like time, day, location, classification code, and XML document Stores modules of interpretation information focused on functions and information common to the business domain, including those that provide logical structure interpretation information.
[0043]
A business interface definition is a higher level document that serves as a schema used to design an interface for exchanging documents according to the present invention. Thus, the business interface bridges the gap between documents written according to XML and programs executed at the front end of the transaction processing service at a particular node. Such a front end is implemented by a JAVA virtual machine or other common architecture that defines the internal connections of the systems in the network. The business interface definition thus provides the techniques used to program the transaction protocol using the business interface definition document. The program for the transaction protocol is defined by a detailed official specification of the document type.
[0044]
An example business interface definition BID based on a market participant document that conforms to the XML format is given below. Market participants DTD associates contact and address information with service and financial information descriptions to categorize business information about market participants. This business information consists of a name, code, address, a dedicated taxonomy to indicate the business organization, and a pointer to the business term. In addition, the services identified by the market participant DTD describe the input and output documents that the participant responds and generates. Thus, a document that defines a schema that uses an example common business language for market participants DTD, service DTD, and transaction document DTD described in annotated XML to help explain it follows.
[0045]

The service DTD schema can be extended with the service type elements of the common business language repository as follows.

The service type element above illustrates the interpretation information held by the business interface definition, in this example the content form that allows identification of any one of the valid service types. Another interpretation information includes, for example, data typing, such as the element <H3> Internet Address </ H3>, which includes the content form “url” and is represented by the data type “string”. Yet another interpretation information includes the mapping of codes to elements of the list, for example the element <H3> State </ H3> that contains the code mapping for the country in the file “COUNTRY.US.SUBENTITY”.
The service description queried by the market participant DTD defines the document that the service recognizes and generates for the service competition. The basic service description is the XML document transact. It is described below as dtd.
transact. dtd models a transaction description, such as an invoice, or a value exchange description. This document type supports many uses, so the transaction description element has attributes that allow the user to distinguish between invoices, achievements, offers for sale, transaction price requests, and the like. Exchanges can be made between two or more parties, but only the offerer and the other party appear. Each person is represented by a pointer to a document that matches the market participant DTD outlined above. It is optional for the opponent's pointer to accept the offer for sale. The replacement description is listed below in tranprim. described in mod, including price and subtotal. Following the exchange description, a fee that applies to the transaction as a whole is provided and the entire fee must be given. Therefore, the transaction description schema document transact. dtd is expressed below.

Representative market participants and service DTDs are generated according to the above definitions and are as follows:
Market DTD

Service DTD

transact. An example of a document generated by dtd follows.

[0046]
Accordingly, the present invention provides a technique that allows a market participant to identify himself and to identify the type of input document and the type of output document he is trying to trade. The particular manner in which the content carried in this type of document is processed by other parties or local parties in this transaction is not related to establishing a business relationship, nor is it related to conducting the transaction.
[0047]
FIG. 3 is a schematic diagram of participant nodes in a network according to the present invention. The node illustrated in FIG. 3 includes a network interface 300 that is coupled to a communication network at port 301. This network interface is coupled to the document parser 301. The parser 301 supplies the logical structure from the input document to the translator module 302, which converts the input document into a form that can be used by the host trading system and vice versa. Is converted to an output document form in the business interface definition for transmission to the destination. Parser 301 and translator 302 respond to the business interface definition stored in participant module 303.
[0048]
The output data structure from the translator 302 is supplied to the trading process front end 304 along with events signaled by the parser 301. The front end 304 in one embodiment comprises a JAVA virtual machine or other similar interface suitable for communicating between various nodes in the network. Trading process front end 304 routes the input data to the appropriate function in the enterprise system and network to which the participant is coupled in response to an event directed by parser 301 and translator 302. Thus, the trading process front end 304 in the example of FIG. 3 is coupled to other enterprise functions such as commercial functions 305, database functions 306, accounting and billing 307, and designed to respond to events directed by the parser. Specific event listeners and processors 308.
[0049]
Parser 301 receives a purchase order or other document as in the previous example specified according to the business interface definition and is a set of events recognized by a local transaction processing architecture, such as a set of JAVA events for JAVA virtual machines. Is generated.
[0050]
The parser of the present invention is decoupled from the program listening for events based on the received document. Various markup pieces in a received document or a complete document that meets a specific specification serves as an instruction for a listening function that initiates processing. Thus, the listening program implements business logic related to document information. For example, the program associated with the address element can be a code that validates a poster code by checking a database. These listeners join the event by registering with the document router. Document routers direct appropriate events to all subscribers interested in them.
[0051]
For example, a purchase order identified as described above may be monitored by a program listening for events generated by a parser that will connect the document or its contents to an order entry program. The inventory is checked using a program upon receipt of the product description in the purchase order. Upon receipt of the address information in the purchase order, a certain program is used to check the availability of the service for delivery. The buyer information field in the document can use various processes to check the order history for credit value, or offer similar processing, such as based on knowing promotions or consumer identities.
[0052]
A complex listener can be created as a primitive listener configuration. For example, some purchase order listeners may include and use the list listeners described above, and list members may be used with respect to themselves. It should be noted that an application such as a listener that runs does not appear to be a native XML process or a native JAVA process. In these cases, the object is converted to the format required by the receiving trans application. When the application completes processing, the output is converted back to XML format for communication to other nodes in the network.
[0053]
The market participant document type description and transaction document type description as described above include a schematic mapping for logic elements in the document, and a markup language based on natural language. Natural language markup and other natural language attributes of XML facilitate the use of XML type markup languages for business interface definitions, service descriptions and specification of input and output document descriptions.
[0054]
In addition to storing business interface definitions, participant module 303 edits objects or other data structures used by trading process front end 304 corresponding to the logical structure in the input document, and edits translator 302. Including the compiler used to Thus, when the business interface definition is changed or updated by the participant as the participant's related transaction changes, the translator 302 and parser 301 are automatically kept in update.
[0055]
In the preferred system, the set of JAVA events is generated by the compiler corresponding to the SGML globe model, mainly the standard element structure information set extended by property set for each element (International Standard ISO / IEC 10179: 1996 (E), Information Technology--Processing Language--Document Style Semantic and Specification Language (DSSSL)). Returning an XML document to a set of events for processing is different from the usual parsing model where the parser output is maintained as an internal data structure. By converting XML document elements into JAVA events or other programming structures suitable for use by each node's transaction processing front end, rich functionality can be achieved at nodes that utilize the document being traded. The
[0056]
Thus, the trading process front end 304 can operate in a publish and subscribe architecture that allows new listener programs to be added without knowledge or impact of other listening programs in the system. Each listener 305, 306, 307, 308 in FIG. 3 maintains a queue in which the front end 304 directs events. This allows multiple listeners to handle events in parallel at their own pace.
[0057]
Furthermore, according to the present invention, the application that the listener will run does not have to be a native XML function or native function that matches the format of the input document. Rather, these listeners can be JAVA functions when the trading process front end 304 is a JAVA interface, or they can be functions that run according to a unique trading processing architecture. In these cases, the object can be converted to the format required by the receiving application. When the listener application finishes, its output is converted back into a document format as specified by the business interface definition in module 303. Thus, the translator 302 is directly coupled to the network interface 300 to provide the combined document as output.
[0058]
Listeners coupled to the transaction processing front end may include a listener for the input document, a listener for a specific element of the input document, and a listener for attributes stored in the specific element of the input document. This allows for various flexible implementations of the trading process at a particular node to filter and respond to input documents.
[0059]
FIG. 4 illustrates a process for receiving and processing an input document for the system of FIG. Thus, the process begins by receiving a document at the network interface (step 400). The parser identifies the document type (401) in response to the business interface definition. The document is parsed using the business interface definition storing the DTD for the document in XML format (step 402). Next, the document elements and attributes are converted to a host format (step 403). In this example, the XML logic structure is converted to a JAVA object that carries data for the XML element along with data-related methods such as get and set functions. The host object is then transferred to the host transaction processing front end (step 404). These objects are routed to the process in response to events directed by the parser and translator. The process of receiving document elements is executed and generates output (step 405). The output is converted into an output document format as defined by the business interface definition (step 406). In this example, translation proceeds from the JAVA object form to the XML document form. Finally, the output document is sent to the destination through the network interface (step 407).
[0060]
FIG. 5 is a detailed diagram of the event generator / event listener mechanism for the system of FIG. In general, the approach shown in FIG. 5 is an improvement of the JAVA JDK1.1 event model. In this model, three types of objects are considered. The first type of object is an event object that includes information regarding the occurrence of an event. There are a number of event object types corresponding to all the different types of events that can occur. The second type of object is an event generator that monitors activity and generates event objects when something happens. The third is an event listener that listens to the event object generated by the event generator. Event listeners generally listen to a specific event generator, such as a mouse click on a specific window. The event listener calls the “add event listener” method on the event generator. This model can be adapted to the environment of FIG. 3, where objects are generated in response to walking and parsing a graph of objects as represented by the XML document.
[0061]
The system shown in FIG. 5 has a general XML parser 500. Such a parser can be implemented using a standard recall model. When a parsing event occurs, the parser invokes a specific method in the application object and passes the appropriate information in the parameters. Thus, a single application 501 exists with the parser. The application packages the information provided by the parser in an XML event object and sends it to the number of event listeners identified by itself, as indicated by block 502. The set of events 502 is completely independent of the parser. Event 502 can be delivered to any number of listeners and any number of threads on any number of machines. Events are based on an Element Structure Information Set (ESIS) in one alternative format. These therefore consist of a list of important aspects such as recognition of the document structure or attributes such as the start and end of the element. XML (and SGML) parsers generally use the ESIS structure as the default set of information for the parser to return to its application.
[0062]
A specialized ESIS listener 503 is coupled to the set of events 502. This listener 503 implements the ESIS listener API and listens for all XML events from one or more generators. One element event generator 504 is a specialized ESIS listener and also an XML event generator. The listener is an object that is only interested in events for a particular type of element. For example, in an HTML environment, the listener is interested only in the indicated list, that is, only the portion of the document between the <OL> and </ OL> tags. In another example, the listener listens only to the “party.name” or “service.name” element according to a common business language from the above example document, and the element carries data that matches the schematic mapping for the element To ensure that the element is processed and reacts according to the process required at the receiving node.
[0063]
This allows the system to have small objects that only listen to specific parts of the document, such as summing prices. There can also be listeners that only listen to, for example, the <HEAD> portion of an HTML document, since listeners can add or remove themselves from the generator. For this reason and because of the high repeatability of XML documents, it is possible to write highly targeted code and concurrent listeners. For example, the <OL> listener can set the <LI> listener completely separate from the method in which the <UL> (undirected list) listener sets the <LI> listener. As an alternative, you can create a listener that generates a graphic user interface and another listener that searches a database that uses the same input. Thus, the document is treated as a program executed by the listener, as opposed to a complete data structure that the application examines one at a time. If an application is written this way, it is not necessary to have the entire document in memory to run the application.
[0064]
The next listener coupled to the set of events 502 is the attribute filter 505. Similar to the element filter 504, the attribute filter 505 is an attribute event generator according to the ESIS listener model. The listener for the attribute filter specifies the attribute that it is interested in and receives events for any element with the specified attribute. For example, the font manager will receive events only for elements with font attributes such as <PFONT = “Times Roman” / P>.
[0065]
Element event generator 504 provides such an element object to specialize element listener 504A.
[0066]
The attribute event generator 505 supplies an attribute event object to the attribute listener 505A. Similarly, attribute objects are provided to the “architecture” in the sense of transforming SGML / XML using attributes from one document format to another. Thus, the 505B architecture allows a specific attribute with a specific name to be identified. Only elements with that defined attribute become part of the output document, and the name of the element in the output document is the value of the attribute in the input document. For example, if architecture 505B is HTML,
<PURCHASES HTML = “OL”> <ITEM HTML = “LI”> <NAME HTML = “B”> STUFF </ NAME> <PRICE HTML = “B”> 123 </ PRICE> </ ITEM> </ PURCHASE>
When translated,
<OL> <LI> STUFF </ B> <B> 123 </ B> </ LI> </ OL>
It is correct HTML.
[0067]
The next module coupled to the set of events 502 is a tree builder 506. The tree builder takes a stream of XML events and generates a tree representation of the underlying document. One preferred form of tree builder 506 generates a document object model DOM object 507 according to the specification of W3C (http://www.w3.org/TR/1998/WD-DOM-199980720/introduction.html). Listeners in the event stream can be used to handle most requests, but the tree format helps with questions around the document, creating new documents, eg parsing documents many times, to reorder nodes It helps to support in-memory data structures from which the same event stream can be generated multiple times. Specialized builder 508 can be coupled to tree builder 506 to create a special subtree of the portion of the document that fits a particular implementation.
[0068]
In addition to responding to incoming documents, other sources of XML events 502 can also be provided. Thus, event stream 510 is generated by walking over the tree of DOM objects and by regenerating the original event stream that was created when the document was parsed. This allows the system to give the appearance that the document has been parsed several times.
[0069]
The notion of an object that walks the tree and generates a stream of events can be generalized to any tree of objects that can be queried beyond the tree of DOM objects. Accordingly, the JAVA walker 512 may be an application that walks the tree of JAVA bean components 513. Walker walks on all public fields and methods. The walker remembers the trajectories of objects that have already been visited to ensure that it does not enter an endless cycle. JAVA event 514 is a type of event generated by JAVA walker 512. This currently includes most of the types of information that can be extracted from an object. This is the JAVA equivalent of ESIS, and allows the same programmatic technique applied to XML to be applied to JAVA objects in general, but especially to JAVA beans.
[0070]
The JAVA to XML event generator 515 includes a JAVA listener and a JAVA event generator. It receives a stream of events 514 from a JAVA walker 512 and translates the one selected to supply a JAVA object as an XML document. In the preferred embodiment, event generator 515 utilizes the JAVA beans API. Each object seen becomes an element, and the element name is the same as the class name. Within that element, each embedded method also becomes an element whose contents are the values returned by invoking the method. If it is an object or an array of objects, these are walked alternately.
[0071]
FIG. 6 is a schematic diagram of a particular application built on the framework of FIG. This application takes an XML document 600 and applies it to a parser / generator (parser routine generation system) 601. An ESIS event 602 is generated and provided to the attribute generator 603 and the tree builder 604. The attribute generator corresponds to the generator of FIG. The generator 505 sends the event to, for example, an “architecture” 505B for translating from XML input to HTML output. These events are processed in parallel as indicated by block 605 and processed by the listener. The listener's output is supplied to the document writer 606 and translated back into XML format for output. Thus, for example, the application shown in FIG. 6 takes an XML document and outputs an HTML document having a form. This form is then sent to the browser and the result is converted back to XML. For this operation, the architectural concept provides a mapping from XML to HTML. The three architectures included in FIG. 6 are intended to give the structure of an HTML document such as a table and a list, a second specifying the document to be displayed, such as a label for an input field on the browser document. And a third describing the input field itself. The elements of the XML document that are required to maintain the XML document structure are invisible fields in the HTML form. This is useful for use in reconstructing an XML document from information that the client puts in an HTTP post message sent back to the server. A listener who listens to these events outputs events for the HTML document. This document goes to the document writer object. The document writer object listens for XML events and returns them to the XML document. The document writer object is a listener for all element generators listening to the architecture in this example.
[0072]
The configuration of the processing modules illustrated in FIGS. 5 and 6 represents one embodiment of the parser and transaction process front end for the system of FIG. As can be appreciated, a very flexible interface is provided so that a diversified transaction process can be performed in response to an incoming XML document or other structured document format.
[0073]
FIG. 7 illustrates a node similar to FIG. 3 except that it includes a business interface definition builder module 700. Accordingly, the system of FIG. 7 includes a network interface 701, a document parser 702, and a document translator 703. The translator 703 outputs the output to the transaction processing front end 704. This front end is coupled to listening functions such as commercial functions 705, databases 706, enterprise functions 707, and other general listeners and processors 708. As illustrated in FIG. 7, the business interface builder 700 includes a user interface, a common business library CBL repository, a process for reading complementary business interface definitions, and a compiler. User interfaces are used to assist in the construction of business interface definitions, depending on the ability to retrieve common business library repositories and complementary business interface definitions. Thus, the complementary business interface definition input document can be identified as an output document for a particular transaction, and the complementary business interface definition output document can be identified as an input such as a transaction process. In a similar manner, the transaction business interface definition can be constructed using components selected from the CBL repository. The logical structure and interpretation in the use of CBL repositories in the construction of standardized document formats such as the above-mentioned example (bid1) document, and business interface definitions that can be readily adopted by other people in the network Promote the use of information.
[0074]
The business interface definition builder 700 also includes a translator 703, a compiler used to generate objects to be processed by the translator according to the host transaction processing architecture and to manage the parsing function 702.
[0075]
FIG. 8 is a heuristic diagram showing the logical structure stored in the repository within the business interface definition builder 700. Accordingly, repository storage representing party business interface definition 800 includes, for example, consumer BID 801, catalog house BID 802, warehouse BID 803, and action house BID 804. Thus, a new participant in the online market selects one of the standardized BIDs that best matches the business as the basic interface definition. In addition, the repository stores a set of service business interface definitions 805. For example, an order entry BTD 806, an order tracking BID 807, an order fulfillment BID 808, and a catalog service BID 809 can be stored. As new participants in the market build the business interface definition, they can select the standardized service business interface definition stored in the repository.
[0076]
In addition to the party and service BID, the input and output document BIDs are stored in the repository indicated by field 810. Accordingly, the purchase order BID 811, the invoice BID 812, the estimate request BID 813, the product availability report BID 814, and the order status BID 815 can be stored in the repository.
[0077]
In the preferred system, the repository stores interpretation information in the form of a semantic map as indicated by field 816, in addition to the business interface definition specified as a document form definition according to XML. Thus, a semantic map used to identify weight 817, currency 818, size 819, product identification 820, and product feature 821 can be stored in the repository. Furthermore, the interpretation information provides for classifying the data structure within the logical structure of the document.
[0078]
Further, the logical structure used in constructing the business interface definition is stored in the repository pointed to by block 822. Accordingly, a form for giving address information 823, a form for giving price information 824, and a form for giving a contract-related period 825 can be provided. As the network expands, the CBL repository expands as well, and standardization makes it easier to add new participants and define business interfaces.
[0079]
FIG. 9 illustrates the process of building a business interface definition using the system of FIG. The process begins by displaying a BID Builder graphical interface to the user (step 900). The system accepts user input identifying participant, service and document information generated by the graphical interface (step 901).
[0080]
Next, any reference logical structures, interpretation information, document definitions, and / or service definitions are retrieved from the repository via a graphical user interface in response to user input (step 902). In the next step, the complementary business interface definition or components of the business interface definition are selected by a customized search engine, web browser, or other method through other user inputs in the network (Step 903). A document definition for the participant is generated using the collected information (step 904). A translator for each mapper from document to host and from host to document is generated by the compiler (step 905). A host architecture data structure corresponding to the definition is generated by the compiler (step 906). The generated business interface definition is then posted on the network by posting it to a website or other location, making it accessible to other nodes in the network. (Step 907).
[0081]
The definition of a business interface tells potential commercial partners about the online services offered by the company and the documents used to implement these services. Thus, a service is defined in the business interface definition by the documents that the service receives and generates. This is illustrated in the following fragment of the XML service definition.
[0082]

[0083]
This XML fragment defines a service consisting of two processes: one that obtains an order and one that follows it. Each definition represents a contract or promise to perform a service if a legitimate request is presented to a particular web address. Here, the order service is a standard “po.dtd” DTD (Document Type Definition) located in a repository which can be local or stored in an industry-wide registry on the network. ) Is required to be input document. If one node can execute the order, it will return a document that conforms to the customized “invoice.dtd” whose definition is local. In practice, a company promises to do business with anyone who can submit a purchase order that conforms to the XML specification it declares. Prior adjustment is not required.
[0084]
DTD is an official specification or grammar for a given type of document that describes the elements, their attributes, and the state in which they must be displayed. For example, a purchase order typically includes buyer and seller names and addresses, a set of product descriptions, and associated terms and conditions such as price and delivery date. In the Electronic Data Interchange (EDI), for example, the X12 850 specification is a commonly used model for purchase orders.
[0085]
Repositories facilitate the development of XML document models from reusable semantic components common to many business areas. Such documents can be understood from their common message elements, even if they look quite different. This is the role of the Common Business Library repository.
[0086]
The common business library repository consists of an information model for general business concepts, including:
-Business description primitives, such as companies, services, and products;
・ Business forms such as catalogs, purchase orders, and invoices,
Standard measurement values, date and time, position, and classification code.
[0087]
This information is expressed as an extensible and public XML building block that the company can customize and assemble to rapidly develop XML applications. The atomic CBL element implements industry messaging standards and conventions, such as standard ISO codes for country, currency, address, and time. Low level CBL semantics can also be derived from analysis of presented metadata frameworks for Internet resources, such as Dublin Core.
[0088]
The next level of elements uses these building blocks to make X12 as well as the business forms used in emerging Internet standards, such as Open Trading Protocol (OTP) and Open Buying on the Internet (OBI). It also performs basic business forms such as those used in EDI processing.
[0089]
CBL focuses on all business areas (business description primitives, such as companies, services, and products; business forms such as catalogs, purchase orders, and invoices; standard measurements, dates, locations, classification codes) Common functions and information. CBL relies on standards for possible semantics or industry conventions (eg, “month / day / year” in the United States versus “day / month / year” in Europe). The rules you specify are encoded in a separate CBL module).
[0090]
CBL is a language used to design applications. It is designed to bridge the gap between the XML “document world” and the JAVA “programming world” or other processing process architecture. A schema embodies the idea of “programming by document”, where a detailed official specification of a document type is a master source from which various related forms are generated. These forms include CBL, JAVA objects, conversion programs between XML instances and corresponding JAVA objects, and XML DTD for supporting documents.
[0091]
CBL creates a single source from which almost every part of the system is automatically generated by the compiler. CBL works by extending SGML / XML, which is typically used to formally define the structure of a particular document type, to include semantic specifications associated with each information element and attribute. The (most) limited set of character types in SGML / XML can be extended to declare any kind of data type.
[0092]
This is a fragment from the CBL definition for the “datetime” module.

[0093]
In this fragment, ELEMENT “year” is defined as the character data and the associated “schema” attribute, and the character data also defines the schema for “year” to be section 3.8 of the ISO8601 standard.
[0094]
This “datetime” CBL module is actually defined as an instance of the schema DTD. First, the module name is defined. Next, the “date” element “YEAR” is combined with the ISO 8601 standard semantics.
[0095]

[0096]
Example market participants and the above service modules are also stored in the CBL repository.
[0097]
In FIG. 10, an air freight receipt (Airbill) 1000 is defined by customizing a general purchase order DTD 1001 and adding more specific information about the shipping weight 1002. A typical purchase order 1001 was first assembled extensively from address, date and time, currency, and CBL module for seller and product description. Thus, the use of CBL greatly facilitates the implementation of XML commercial applications. More importantly, CBL makes it easy to interconnect commercial applications.
[0098]
In CBL, XML is extended by a schema. The extension adds strong-typing to the XML element so that the contents can be easily confirmed. For example, <CPU clock The element called speed> can be defined as an integer with a set of valid values: {100, 133, 166, 200, 233, 266 Mhz}. The schema also adds a class-subclass hierarchy so that information can be easily instantiated from class definitions. For example, a laptop can be described as a computer with additional tags for features such as display type and battery life. These and other extensions facilitate data entry as well as automatic translation between XML and traditional object-oriented and relational data models.
[0099]
In this way, the completed BTD is transformed from the participant and the actual instance of the service outlined above, the JAVA beans corresponding to the logical structure of the DTD instance, and from XML to JAVA and from JAVA to XML. This is done through a compiler that creates a DTD for the conversion code to do. In other systems, documents are also generated for display on the user interface or for printing by the user to make the object easier to use.
[0100]
For example, JAVA beans generated by market participants and the aforementioned service DTD, compiler, are shown as follows (with some modifications for brevity):

In addition to the JAVA beans described above, conversion codes are created for translation from JAVA to XML and from XML to JAVA as shown below.

[0101]
Using tools along with a BID composer application that provides a user interface to edit drags, drops and shapes, developers can create business interface definitions and are well-formed Effective business interface definitions can be produced in the form of XML documents. Thus, the example runtime instance is the definition of a business interface for ordering services for IBM, used by Ingram Micro to order a laptop computer from IBM. . (There is no relationship between the applicant and IBM or Ingram Micro.) With these processes, users can build systems that can program business interfaces using documents defined according to the present invention. can do.
[0102]
The role of the CBL and BID processors of the present invention in an XML / JAVA environment will be further understood from the following description of purchase order processing.
[0103]
Company A defines its purchase order document using a visual programming environment that includes a library of CBL DTDs and modules, all defined using common business language elements, which contain data types and other translation information It is like that. Company A's PO may include minor customizations to the more general transaction document specification that comes with the CBL library, or the ground from the CBL module for address, data and time, current, etc. May be made from.
[0104]
General transaction document specification documents (such as transact.dtd described above) typify how CBL specifications are created from modules and concatenated with other CBL DTDs.
[0105]
The compiler takes purchase order definitions and generates several different target formats. All of these target types can be obtained via a “tree to tree” variant of the original specification. The most important for this example is
(A) XML DTD for purchase order
(B) JAVA bean containing data structure for purchase order (JAVA classes, arguments, data types, methods, and exception structures are created corresponding to information in the purchase order schema definition)
(C) An alignment program that converts purchase orders according to the purchase order DTD into purchase order JAVA beans, or loads them into a database or creates HTML (or XSL style collections) to display the purchase order in a browser
(D) Unaligned program that extracts data values from a purchase order JAVA bean and converts them into XML documents according to the purchase order DTD
Now returning to the scenario, the purchase application generates a purchase order, which follows the DTD specified as the service interface for the supplier accepting the purchase order.
[0106]
The parser uses the purchase order DTD to decompose the purchase order instance into an information stream about the element and the attribute values it contains. These property sets are then converted into corresponding JAVA event objects by overlaying them with JAVA code. In effect, this transformation processes the portion of the XML document whose grammar is marked as a customer programming language instruction defined by DTD. These JAVA events can be processed by the aligned application generated by the compiler to load the JAVA bean data structure.
[0107]
Converting and processing an XML document into a set of events for a JAVA application is different from the normal model for parsing, and the internal data structure and processing does not start until the parsing is complete, so the parser output is maintained. Is done. Event-based processing according to the BID definition is the key to enabling a very good function of the processor, as it starts document application processing that occurs as soon as the first event is fired.
[0108]
A JAVA program that listens to various types of events is formed from the schema definitions of those events. These listeners are programs created to perform the business logic associated with the CBL XML definition, for example code associated with the address element and checking the zip code by checking the database. . These listeners apply for events by registering at the document router and assign events related to all applicants who have shown interest in them.
[0109]
This published and applied architectural means programmed by new listeners can be added without knowledge of existing ones or without affecting them. Each listener has a queue to which the router assigns its events, and multiple listeners can handle events in parallel at their own pace.
[0110]
For the example purchase order here,
・ Purchase orders that will connect it to the order entry program
・ Product manual that will check stock
Address information that could check Fed Ex or other services for delivery validity
・ Buyer information that could check the order history (for credit worth or to provide public notice or for similar processing based on knowing who the customer is)
Might be a listener for.
[0111]
A composite listener can be created as an initial shape. (For example, purchase order listeners may include these listeners here and quote them, or they may quote themselves.)
[0112]
FIG. 11 shows market marker nodes in the network of FIG. The market marker node includes the basic structure of the system of FIG. 3 and includes a network interface 1101, a document parser 1102, a host to document and document translator host 1103, and a front end 1104, in this example called a router. ing. The market marker module 1105 in this example provides a set of business interface definitions, or other identifiers sufficient to support the market marker functionality for market participants, CBL repositories, and market participant requests. Has a satisfying compiler. The router 1104 comprises a participant registry and document filter, responds to events generated by the parser at the output of the translator, by the participant registry, and by element and attribute filters between listeners to the XML event generator, Define the path of the input document. Thus, certain participants in the market may register and receive documents that meet pre-specified parameters. For example, an input document with a specific DTD may include attributes such as the number of purchased products above a threshold, or the maximum price of a document request to be purchased, and may be used by the router 1104 for a filter document. Thereafter, a document that matches the information registered in the participant's registry by the router 1104 is sent to the registered participant.
[0113]
The router 1104 also satisfies the requirements of the local host services 1105 and 1106 and operates like a market participant as well as a market marker, for example. Typically, documents received by the router 1104 are traversed to determine destinations and such documents are sent where they are sent again via the translator 1103, if necessary, from the network interface 1101 to the respective destination. It is done.
[0114]
A market marker is a server that links together with a set of internal and external business services, creating a virtual planning or trading community. The server parses the input document and references the appropriate service, for example, by passing a request for product data to the catalog server or by sending a purchase order to the ERP system. The server also handles translation tasks and maps information from the company's XML document to the document format used by the trading partner and the data format required by its legacy system.
[0115]
With respect to the above service definition, when the company submits a purchase order, the server's XML parser uses the purchase order DTD to convert the purchase order instance into a stream of information events. These events are then sent to an application programmed to handle a given type of event, and in some cases the information is sent completely to different businesses over the Internet. In the purchase order example, some applications may operate with information coming from a parser.
• The order entry program processes the purchase as a complete message.
• The ERP system checks inventory for the product described in the purchase order.
The customer database verifies or updates the customer's address.
・ The shipping company uses the address information and schedules the transportation.
・ Banks use credit cards and allow transactions.
[0116]
Trading partners need only agree on the structure, content and order of the business documents they exchange, not the API details. How the document is processed and what action results will occur is strictly up to the business providing the service. This enhances integration from the system level to the business level. It enables a business to provide its business partner with a clear and stable interface despite changes in its internal technology implementation, organization, or process.
[0117]
12, 13 and 14 illustrate the processes performed at the market maker node of the system of FIG. In FIG. 12, an input document is received at a network interface from an originating participant node (step 1200). The document is parsed (step 1201). The document is converted to a host format, eg, XML to JAVA (step 1202). Host formatted events and objects are then sent to the router service (step 1203). Services stored to accept the document according to the document type and document content are identified (step 1204). The document and part of the document are sent to the identified service (step 1205). A service is executed according to the contents of the document (step 1206). Service output data is generated (step 1207). The output is converted to a document format, for example, from a JAVA format to an XML format (step 1208). Finally, the output document is sent to the participant node (step 1209).
[0118]
The registration service is one such function managed by the router. Accordingly, a market participant document is accepted at the network interface shown in FIG. 13 (step 1300). The market participant document is stored in the business interface definition repository for the market maker node (step 1301). In addition, the document is parsed (step 1302). The parsed document is converted to the host format (step 1303). Next, the document is sent to the router service (step 1304). The router service includes a listener that identifies the registration service as the document destination according to the document type and document content (step 1305). The document and document elements are sent to a registration service (step 1306). In the registration service, the required service specifications are retrieved according to the business interface definition (step 1307). If service specifications are collected in step 1308, a router service filter is set according to the business interface definition and service specifications (step 1309). Registration acknowledgment data is generated (step 1310). Registration acknowledgment data is converted into a document format (step 1311). Finally, an acknowledgment document is sent to the participant node to notify the participant successfully registered with the market maker (step 1312).
[0119]
The process in step 1307 for collecting required service specifications is shown for one example in FIG. The process begins by locating service business interface definitions supported by market participants (step 1400). The service definition is retrieved, for example, by email transaction or web access to the repository node (step 1401). The service specification is stored in the BID repository (step 1402). The service business interface definition document is parsed (step 1403). The parsed document is converted to the host format (step 1404). Next, the host object is sent to the router service (step 1405). A registration service is identified according to the document type and content (step 1406). Finally, the service business interface definition document information is sent to the registration service (step 1407) and used according to the process of FIG.
[0120]
FIG. 15 illustrates a processor, component and sequence for processing data input to a market maker node in accordance with the present invention. The market maker node has a communication agent 1500 at the network interface. The communication agent is connected to the XML parser 1501, and the XML parser 1501 supplies an event to the XML processor 1502. The XML processor 1502 supplies the event to the document router. The document router feeds to the document service 1504, and the document service 1504 serves as an interface for supplying the received document to the enterprise solution software 1505 of the host system. Communication agent 1500 is an Internet interface with a suitable protocol stack that supports protocols such as HTTP, SMTP, FTP, or other protocols. Thus, the data to be entered may be entered in XML syntax, ASCII data syntax, or other syntax to suit a particular communication channel. All documents received in non-XML syntax are converted to XML and sent to an XML parser. A conversion table 1506 is used to support conversion from non-XML format to XML format.
[0121]
The converted document is supplied to the parser 1501. The XML parser parses the received XML document according to the matching document type definition. If an error is found, the parser sends the document back to the communication agent 1500. The business interface definition compiler BIDC 1507 serves as a compiler for business interface definition data. Conversion rules for converting DTD files for XML parsers, JAVA beans corresponding to DTD files, and DTD files into JAVA beans are created by compiling BID data. By referring to these tools, an XML instance is converted into a JAVA instance. Therefore, the BID compiler 1507 stores the DTD document 1508 and generates a JAVA document corresponding to 1509. The XML document is sent to the processor 1502, and the processor 1502 converts the document into a JAVA format. In the preferred system, a JAVA document is generated that has the same status as the document type definition received in XML format. JAVA beans are sent to the document router 1503. Document router 1503 receives the JAVA beans and sends the received classes to the appropriate document service using a registry program, for example using the event listener architecture described above. The document service 1504 that receives the document in the form of JAVA beans from the router 1503 works as enterprise solution software. It has a registry service 1510 that couples to the data stream that enters the listener for XML events, and a service manager 1511 that manages the routing of incoming documents to the appropriate service. The document service manager 1511 performs management of the registry service and maintenance of document consistency.
[0122]
The document service communicates with the backend system using any proprietary API or using a more common form such as a CORBA / COM interface or other architecture.
[0123]
FIG. 16 is a heuristic diagram of the market maker and market participant structure according to the present invention. Accordingly, the e-commerce transaction market according to the present invention can be logically organized as shown in FIG. A market maker node 1600 is set at the top of the organization. The market maker node includes resources for setting the market place 1601. Such resources include market registry services and the like. Business 1602 registers with the marketplace by publishing the business interface definition. The business interface definition defines a service 1603 for commercial transactions in which the business participates. Transaction 1604 and service 1603 use document 1605 to define inputs and outputs and outline commercial relationships between participants in the transaction. The document has a content 1606 that contains details of each transaction. The manner in which content is processed by market participants and by market makers is entirely dependent on documents based on an e-commerce transaction network established in accordance with the present invention. Overall, a robust, scalable, and intuitive structure is provided that allows for e-commerce transactions over a communications network.
[0124]
Accordingly, the present invention provides a platform based on an XML processor and uses XML documents as an interface between loosely coupled business systems in the exemplary system. Documents are transferred between businesses and processed by specific nodes before entering the company's business system. Thus, the platform enables cross-business e-commerce applications by identifying a common set of business documents and formats where each business system uses a different internal commerce platform, processing and semantics.
[0125]
According to the present invention, a virtual enterprise is formed by interconnecting business systems and services, mainly defined as follows for documents (XML coded) that are accepted and generated by the business. .
“If you are requesting a catalog from us, we will send you a catalog.” “If you have ordered your purchase and we can accept it, we will send you an invoice.”
The foregoing description of the preferred embodiment of the invention has been made for the purpose of illustrating the invention. This is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations will be apparent to the practitioner skilled in the art. The scope of the present invention is defined by the following claims and their equivalents.
[Brief description of the drawings]
FIG. 1 is a schematic diagram of an electronic commerce network including a business interface definition (BID) according to the present invention.
FIG. 2 is a schematic diagram of a business interface definition document according to the present invention.
FIG. 3 is a conceptual block diagram of a server for a participant node in a network according to the present invention.
FIG. 4 is a flowchart illustrating processing of a document received at a participant node according to the present invention.
FIG. 5 is a block diagram of a parser and transaction process front end for an XML based system.
FIG. 6 is a conceptual diagram of the flow of a syntax analysis program function.
FIG. 7 is a schematic diagram of resources in a server used for business interface definition according to the present invention.
FIG. 8 is a schematic diagram of a repository according to the present invention for use in building a business interface definition.
FIG. 9 is a flowchart illustrating a process for building a business interface definition according to the present invention.
FIG. 10 provides a heuristic overview of repositories according to the present invention.
FIG. 11 is a schematic diagram of resources in a server that provides a market maker function for the network of the present invention based on business interface definitions.
FIG. 12 is a flowchart of market maker node processing of a received document.
FIG. 13 is a flowchart illustrating a process for registering a participant in a market maker node according to the present invention.
14 is a flowchart illustrating a process for providing a service specification in a market maker node according to the process of FIG. 9;
FIG. 15 is a diagram illustrating a sequence of operations at a market maker or participant according to the present invention.
FIG. 16 is a conceptual diagram of elements of a BID-based commerce network according to the present invention.

Claims (10)

A system for executing a commercial transaction through exchange of input and output documents between trading partners connected to a communication network,
One or more client computers (11) for transmitting and receiving input and output document data defined by the trading partner over the communication network;
A server having a transaction processor front end ( 304 ) for processing input and output document data for transactions associated with the client computer;
A repository server for storing definitions for an interface between the client computers , the definitions comprising logical structure information about the input document (211) and output document (212) used in a transaction between the trading partners; With the repository server containing mapping (corresponding) data,
The server
(1) data input means for referring to logical structure information regarding input and output documents in the repository server and receiving an input document generated based on a user input;
(2) a parsing means ( 301 ) for parsing the input document;
(3) using the mapping data in the repository server, the parsed the input document, and converts it to an internal data structure that is designed to receive data from the input document, the transaction data, the output Translator means ( 302 ) for converting to a data structure designed to provide data for the document;
(4) Event listener means ( 308 ) for receiving the input document converted into the internal data structure , wherein each listener module executed by the event listener means is different from other parts of the input document. The event listener means operating independently of each other and generating transaction data ;
(5) an information providing (publishers) means for transmitting the output document to the client computer,
Including system. The apparatus of claim 1, wherein the repository server is accessible to the logical structure information about input and output documents stored in the repository server via the client computer . The repository server apparatus according to claim 2, characterized in that memorize data for further define the input and output document including a logical structure information. The server may further include accessing the repository server to obtain the logical structure information of the input and output documents from other client computers regarding supplemental (Complementary) transactions,
As the logical structure information of the input document data, by including the logical structure information of the output document of the supplementary transactions, wherein for storing a definition for an interface between the input and output documents of the trading partner on the repository server Item 2. The apparatus according to Item 1. The repository server is a logical structure information of the output document, according to claim 4 for storing a logical structure information of the input document of the supplementary transaction. Said data input means accepts the documents for defining an interface between the input and output document data having a logical structure for memorize a certain transaction identifier, the syntax analysis means, for said particular transaction the apparatus of claim 1, comprising parsing using at least one reference to the definition and the definition between the input and output document data. The server, the transaction remembers the identifier of the partner, and at least one remembers documents of references to one or more transaction sets of specifications and specification the supported by trading partner, the logical structure The apparatus of claim 1 for processing according to information mapping data . The input and output document in accordance with the definition for an interface between the input and output document data of the trading partner may include a reference to the specifications of a particular transaction, and wherein the specifications of a particular transaction, the specific 8. The apparatus of claim 7, including logical structure information for recording at least one of a definition between input and output document data for a transaction and a reference to the definition. The logical structure information of the input and output document A device according to claim 1 that generates a programming object that contains variables and methods in accordance with the variable transaction processing architectures. The apparatus according to claim 9, wherein the variable transaction processing architecture executes processing according to an interface description language.

Images