3. 電子取引合意システム
当事者双方の間の情報交換の際には、個々の当事者が相手がサポートしている取引コラボレーション、その取引コラボレーションにおける相手の役割、および相手がメッセージを送受信する方法に関する技術的な詳細を知る必要がある。また、この詳細について当事者双方が合意に達する必要がある。
取引コラボレーションの手続きにおいて個々の当事者が情報を交換する方法は、コラボレーションプロトコルプロファイル(CPP)に記述できる。また、当事者の間の合意は、コラボレーションプロトコル合意書(CPA)として表現できる。
当事者は、1つのCPPにおいて記述される場合もあり、また、例えばCPPがサポートする別の取引コラボレーション、世界の異なる地域での運用、あるいは組織の異なった部署などを記述する複数のCPPを作成する場合もある。
取引を希望する当事者が適切な取引当事者となり得る相手を見つけることができるようにするために、CPPを、ebXMLレジストリ[ebRS]に含まれているようなリポジトリに格納することが望ましい。当事者は、リポジトリの仕様の一部として提供されている発見プロセスを用いて、リポジトリを使用して取引当事者の存在を発見しできる。
2つの当事者間のやりとりを定義する文書は、『ebXMLビジネスプロセス仕様スキーマ』[ebBPSS]に準拠するプロセス仕様文書である。CPPおよびCPAには、このプロセス仕様文書の参照が含まれる。プロセス仕様文書は、ebXMLレジストリなどのリポジトリに格納される。
図3は、ebXMLレジストリにおける、CPPと、A1およびA2という2つのプロセス仕様文書の関係を示している。左側の「A」というCPPには、異なる当事者として表わされる1つの企業内の2つの部門に関する情報が含まれている。右側の2つの四角は、プロセス仕様文書である。CPP内のPartyInfo要素はそれぞれ、これらのプロセス仕様文書のうちの1つへの参照を含んでいる。この情報によって、当事者が実行できる取引コラボレーションが特定される。
Repository
(拡大画面:11KB) |
|
図3:ebXMLレジストリのCPPとビジネスプロセス仕様の構造
CPPでは、個々の当事者の能力を記述する。CPAで、特定の取引コラボレーションの実行のために使用することが当事者双方によって合意された機能を記述する。これらのCPAによって、取引文書を電子的に当事者間で交換するための、「情報技術条件」が定義される。CPAで示される情報の内容は、電子データ交換(EDI)の『取引当事者合意書』(TPA)に含まれる可能性のある情報技術仕様と類似している。ただし、これらのCPAは紙の文書ではない。これらの文書は、当事者のサイトにあるコンピュータによって処理し、必要なビジネス情報の交換を設定し実行できる電子文書である。取引合意書の条件についての「法律的な」記述は、本書の範囲外であり、したがって、CPPおよびCPAには含まれない。
1つの企業を複数の当事者として表現することもできる。また、本社の調達部門と製造現場の調達部門を別の当事者として表現することもできる。次に、別々の当事者として表現された部門をすべて包含するCPPを構築してもよい。そのCPPの中で、これらの部門をそれぞれ異なるPartyInfo要素で表現することになる。
一般に、CPAの当事者は、クライアントとサーバの両方の特徴を持つ可能性がある。クライアントはサービスを依頼し、サーバは依頼元の当事者にサービスを提供する。アプリケーションによっては、一方の当事者はサービスを依頼するのみであり、他方の当事者はサービスを提供するのみである場合もある。そのようなアプリケーションの場合、伝統的なクライアント/サーバアプリケーションとある程度類似している。しかし、他のアプリケーションでは、両方の当事者がそれぞれ相手にサービスを依頼してもよい。その場合、2当事者間の関連は、クライアント/サーバ関係ではなくピアツーピア関係として記述できる。
次に、取引相手を発見し、2当事者のCPPからCPAを作成するプロセスを要約する。
図4に、CPPの作成手順を示す。当事者Aが発見プロセスのリポジトリに配置する情報をXMLの形式にし、その情報を含むCPPを構築し、当事者に関する追加情報と合わせてebXMLレジストリなどのリポジトリに入力する。この情報には、この当事者が関わっている取引に関する記述が含まれている。当事者Aの情報がリポジトリに格納されると、そのリポジトリの発見サービスを用いて、相手が当事者Aを発見できるようになる。
(拡大画面:9KB) |
|
図4:コラボレーションプロトコルプロファイル(CPP)の概要
図5では、当事者Aと当事者Bが、それぞれのCPP内の情報の共通部分を抽出することで、同一のCPAを共同で構築している。構築されたCPAには、当事者双方が取引コラボレーションの実行に際してどのように振舞うかが定義されている。
(拡大画面:15KB) |
|
図5:コラボレーションプロトコル合意書(CPA)の概要
図6:ebXMLレジストリのあるCPP/CPAのアーキテクチャの概要
1. Any Party may register its CPPs to an ebXML Registry.
2. Party B discovers trading partner A (Seller) by searching in the Registry and downloads CPP (A) to Party B's server.
3. Party B creates CPA (A, B) and sends CPA (A, B) to Party A.
4. Parties A and B negotiate and store identical copies of the completed CPA as a document in both servers. This process is done manually or automatically.
5. Parties A and B configure their run-time systems with the information in the CPA.
6. Parties A and B do business under the new CPA.
図6に、プロセスの全体を示す。各ステップが左側に列挙されている。プロセスの最後には、当事者双方が、合意に至った同一のCPAから自社のシステムを構成している。この時点で取引を実行する準備が完了する。
CPAによって、当事者の間の有効で可視なすべてのやりとり、およびそれらのやりとりの実行方法を記述する。この記述は、個々の当事者によって実行される内部プロセスとは独立である。個々の当事者はそれぞれの内部プロセスを実行し、CPAおよびプロセス仕様文書で記述される取引コラボレーションとのインターフェイスを取得する。CPAは、当事者の内部プロセスについての詳細を相手に開示しない。CPAの目的は、人間が容易に理解でき、かつコンピュータによる実現が可能なほど十分精密な、高いレベルの仕様を提供することにある。
CPA情報を使用して、当事者のシステム構成が設定され、その結果、取引コラボレーションの実行におけるメッセージ交換が可能になる。通常、メッセージ交換を実行するか、または当事者間のやりとりを実行するためのソフトウェアは、任意の取引コラボレーションをサポートできるミドルウェアである。このミドルウェアのコンポーネントの1つとして、ebXMLメッセージ取扱サービスハンドラ[ebMS]がある。
参照されているCPAおよびプロセス仕様文書によって、当事者間のやり取りが定義される。やり取りは、プロセス仕様文書のコラボレーションコンポーネントの定義に従い、ビジネスの単一ユニットを表す。やり取りは、一方の当事者からの依頼メッセージおよび相手からの応答メッセージを表す、1つ以上の取引トランザクションから成る。プロセス仕様文書では、特に、各取引トランザクション内の依頼メッセージと応答メッセージ、および取引トランザクションの順序が定義される。
CPAは、実際には、複数のプロセス仕様文書を参照してもよい。CPAがプロセス仕様文書を参照する際には、それぞれのプロセス仕様文書で別々のやり取りの型を定義する。1つのやり取りには、1つのプロセス仕様文書しか含まれない。
新しいビジネスのユニットが開始されるごとに新しいやり取りが開始される。取引コラボレーションによって、やり取りの終了時点も指定される。当事者Aと当事者Bの間のCPAの見地から見ると、当事者Aが最初の依頼メッセージを当事者Bに送信した時点でやり取りが開始される。一方、当事者Bにおいては、当事者Aからビジネスユニットの最初の依頼を受信した時点でやり取りが開始される。そして、当事者がビジネスのそのユニットを終了した時点でやり取りが終了する。
各当事者サイトの企業間(B2B)サーバ上に、CPAおよびプロセス仕様文書が実装される。B2Bサーバには、実行時ソフトウェア(相手当事者との通信をサポートするミドルウェア)、CPAで指定された機能の実行、各当事者のバックエンドプロセスとのインターフェイス、監査や復旧などのための当事者間のやりとりのログ記録が含まれる。
|