メタモデルのもう一つのビューとして提供される仕様スキーマ(Specification Schema)は、一連のebXMLビジネストランザクションを行うための実行システムを構成する要素を、直接仕様化するために用いられます。幾つかのビューから、モデリング要素を取出すと、仕様スキーマは、ebXMLビジネスプロセス情報メタモデルの意味的なサブセットになります。

具体的に仕様スキーマが定義するのは、次の5つです。

　

　この仕様スキーマは、2つの方法、すなわちUMLプロファイル(UML Profile)とXMLのDTD(およびXMLスキーマ)の形式で表現されます。この2つの形式は双方に変換可能であり、そのために相互マッピングのための生成規則が定められています。

　仕様スキーマには、ビジネストランザクションの仕様を定義します。一連のビジネストランザクションをビジネスコラボレーション(Business Collaboration)に仕立て上げるために必要な仕様が記述されます。それぞれのビジネストランザクションは、多くの標準パターンのなかの一つを使って実現します。これらのパターンは、取引当事者間で法的に拘束され得る電子的な商取引を行うためのメッセージやシグナルの交換方法を現実に定めることになります。こうしたパターンを特定するために、仕様スキーマは1セットの標準パターン、そうした標準パターンに共通したモデリング要素のセットを参照しながら作成されることになります。したがって、ビジネスプロセスの完全な仕様は、仕様スキーマに対応するビジネスプロセスモデルや、そこで必要なパターン、パターンに適用されている共通モデリング要素を合わせたものになります。

　その中で共通モデリング要素として利用されるのが「コア構成要素(Core Components)」です。コア構成要素は、ビジネストランザクションで交換されるビジネス文書の内容を組み立てるための部品として適切に参照される必要があります。

　図2−7に示す通り、仕様スキーマ、インタラクションパターンおよび共通モデリング要素をワンセットとした仕様をベースに、取引当事者間で交換・合意するCPPやCPAが作成されるのです。

　

　あらためて、ビジネスプロセス情報モデリングの手順を整理しておきましょう。まず、ebXMLビジネスプロセス情報メタモデルに適合する形で、仕様スキーマが取出されます。取出される仕様スキーマは、別途用意されているパターンや共通モデリング要素を参照することで、完全なビジネストランザクションの仕様を与えます。また、別途、変換規則を適用することにより、UMLベースの仕様スキーマからXML形式の仕様スキーマも生成されます。このXMLベースのモデルは、各XML要素をユニークに識別する識別子をもつようになっており、ebXML　レジストリ・リポジトリシステムに登録して保存することができます。これらのXML構造では、特定のレジストリ・リポジトリアーキテクチャに準拠したUID参照リンクによる分類システムが利用されます。

　以下では、ビジネスプロセス情報メタモデリング機能と他のコンポーネントとのインタフェースを整理します。

〈CPP・CPAとの関係〉

ある取引相手のCPPは、彼がビジネスプロセスをサポートする上で有している機能上、技術上の能力と、各プロセスで、彼が果たす役割を定義するものです。また、CPAは、取引当事者間でビジネスを行う際に両者が従う条件を定めます。結果的に、ビジネスプロセスとそれが関連するビジネスプロセス情報メタモデル、そしてCPAの間のインタフェースは、ビジネスプロセス文書の一部となり、ビジネスプロセス情報メタモデルのビジネス取引レイヤを表現したXML文書となります。商取引の流れをXMLで表現した結果は、ビジネスプロセスと取引当事者情報の間で共有されます。

〈コア構成要素との関係〉

ビジネスプロセスでは、取引当事者間のビジネスデータの交換に関わる制約を仕様化します。ここで用いられるビジネスデータは、ebXMLコアライブラリの構成要素から組み上げることができます。ビジネス文書は、一意的に参照可能なコア構成要素を使用します。このコア構成要素とコアライブラリの間のインタフェースの仕組みは、各コンポーネントに付されたUIDまたはGUIDにより実現されます。

〈ebXMLメッセージング機能との関係〉

再利用可能なビジネスプロセスは、ebXMLメッセージとしてあるebXMLレジストリから別のebXMLレジストリに伝送できなくてはなりません。また、レジストリとユーザ・アプリケーションとの間、取引当事者のユーザアプリケーションとの間についても、ebXMLメッセージング機能で伝送可能でなければなりません。

〈レジストリとの関係〉

ebXML基盤のなかで利用されることを想定したビジネスプロセスは、レジストリの検索要求によって検索可能であり、各ビジネスプロセスはUIDまたはGUIDを有していなくてはなりません。

　コア構成要素は、ビジネスで扱われる用語や概念に関する情報を収集し、そのビジネス概念を定義し、加えて他のビジネス概念との関係を記述します。そしてコンテキストの記述によって、そのコア構成要素が特定のebXMLビジネスシナリオのなかで、どのように利用できるかを示します。

　コア構成要素は、個別のビジネス情報であることもありますが、複数のビジネス情報を結合した集合コンポーネントとして組み立てられることも有ります。つまり、コア構成要素は独自の属性値を持つか、別のコア構成要素を属性の一部分として持ちます。前者の場合、コア構成要素は独自のコンテキストを有し、後者の場合はそのコア構成要素が使用されているビジネスプロセスのコンテキストによって意味情報が決められます。

　例えば、取引当事者として企業を定義するには、取引先コード、企業名、住所の定義が必要です。また、住所には、郵便番号、都道府県名、市町村名、建物名の情報が必要です。これらの構造化されたデータそれぞれをコア構成要素と呼び、ebXMLのコア構成要素では、

この標準構造を定義しています。

　基本的なコンテキストは構造的であり、別のコア構成要素内部におけるコア構成要素の位置により意味情報を特定します。別のコア構成要素内部の別のレイヤでコア構成要素が再利用されている場合、コンテキストは構造的コンテキストの組み合わせになります。

　コンテキストはビジネスプロセスモデルによっても定義されます。その場合、ビジネスプロセスモデルは、コンテキストにより、コア構成要素の特定ビジネスプロセスにおける意味を特定します。ビジネスコンテキストは、上位の集約コア構成要素に意味特定のための情報を伝え、下位のコア構成要素に意味特定情報を構造的に伝達していることになります。

例えば、取引当事者は、ビジネスプロセスの中では、売り手、買い手、または運送業者の役割を持ちます。これらのビジネスプロセス定義に関連づけられる情報を役割(コンテキスト)として定義しています。

　企業内システムへの実装の観点では、ビジネスプロセス実行のための「シナリオ」が記述されます。このシナリオは素材としてビジネスオブジェクトを利用します。コア構成要素は、企業内アプリケーションで実行される処理コンポーネント「ビジネスオブジェクト」のデータ属性を定義します。またコア構成要素で定義された構造化データは、取引当事者と交換するビジネス文書を構成します。