リポジトリ(Repository)は、ebXMLに関するデータベース倉庫であり、レジストリ(Registry)はその登録簿です。レジストリ・リポジトリには以下の3種類のデータが格納されます。

　ebXMLリポジトリによって提供される分散サービスを利用すると、ビジネスの当時者間での情報共有が可能となり、ebXML仕様の共有を通じてビジネスプロセスの統合が実現されます。共有される情報は、ebXMLレジストリサービスによって管理され、ebXMLリポジトリ内のオブジェクトとして保守されます。ebXMLリポジトリへのアクセスは、ebXMLレジストリサービスのインタフェース(API)を通じて行われます。

　レジストリとリポジトリは構造的に密接に関連したコンポーネントです。レジストリにはアクセスサービスとのインタフェース、情報システムと参照システムの実装などの機能があり、リポジトリはバックエンド情報の物理的な保存場所を提供します。例えば、ebXMLレジストリは検索要求への応答として、リポジトリからCPPを取り出します。一方、ebXMLリポジトリには、メタデータの検索結果としてレジストリによって取り出される参照DTDとXMLスキーマが保存されています。図2−13に、レジストリとリポジトリの関係を示します。

　情報の保存と取り出しを正確かつ整合的に行うために、レジストリには情報モデルに基づく正規のアーキテクチャが必要です。従来のリレーショナルSQLデータベースでは、テーブル、インデックス、カラム定義などから構成されるごく単純な情報モデルを使用して、情報の保存と取り出しが行われています。一方、XML構造を使用して情報の保存や管理を行うときは、情報をレジストリに登録するのに、ほとんど無限の方法がありえます。したがって、XMLの構造機能を通じて、レジストリ内の情報を管理しなければなりません。また、それらの機能はレジストリへのインタフェースに使用するアクセス手順とも関連します。XML構造で表されるビジネス機能をサポートするメカニズムを提供し、そのメカニズムを正しく機能させることが、情報モデルの重要な役割です。

　ebXMLレジストリの情報モデルは、ビジネス情報コンテンツの保存と取り出しを主な目的として、既存のOASIS　レジストリ情報モデルを参照したものです(OASISモデルは汎用的な情報コンテンツの処理を目的として設計されたスーパーセット)。ebXMLレジストリの情報モデルは簡単に実装できるようにデザインされており、ebXMLメタモデルに準拠した構造が組み込まれているため、ebXMLコンテンツの保存や取り出しを効率的に実行することができます。

　レジストリには、分類(Classification)があり、リポジトリの内容(オブジェクト)とURLなどのアクセスインデックスでリンクされています。検索時は、検索条件として、ビジネス領域(業界)、ビジネスプロセス、バージョン番号、検索範囲、検索制約条件、検索結果出力内容指定などを指定して要求します。検索アプリケーションは、検索条件に従い、レジストリにリンクされているリポジトリから、自動的に当該項目を検索し、検索結果(コンテンツ)と検索状況が通知されます。

　登録されたオブジェクトのメタデータはレジストリによって保守され、登録されたオブジェクトを含むファイルはリポジトリに保管されます。登録されたオブジェクトのメタデータ(このメタデータはレジストリ内に存在)には、そのオブジェクトを含むファイル(このファイルは特定のリポジトリ内に存在)をグローバルに識別する一意のロケータが含まれているという観点で、レジストリとリポジトリは密接に関係しています。

　レジストリの項目には、登録された各オブジェクトを識別/特定/説明する情報が含まれています。レジストリの項目によって、各オブジェクトの管理/アクセス状態の開示、持続期間や易変性の定義、指定された分類基準に従ったカテゴリ分け、ファイル表現タイプの宣言、管理組織の指定などが行われます。

　検索したいオブジェクトは、レジストリインタフェース・システムを通じて開示されます。レジストリインタフェースは、マシンからレジストリへの自動アクセスシステムと人間からレジストリへの対話型ビジュアル・アクセスシステムを提供するコンポーネントです。レジストリインタフェース・システムは、トランスポート層に依存しないXMLべ−スの基本インタフェースとしてデザインされています。同様に、レジストリアクセス機構によって使用される情報検索構文はXMLだけに基づく中立的な構文であり、バックエンドのリポジトリシステムの物理的な実装からは独立しています。

　

　レジストリとリポジトリ間のすべての対話は、当事者間のビジネストランザクションとして取り扱われます。したがって、レジストリによってサポートされるプロセスは、次のような観点から記述されます。

9	レジストリとリポジトリ間の特殊なCPA
10	レジストリとリポジトリに関連するビジネス機能プロセスの集合
11	特定のビジネス機能プロセスの一部として、レジストリとリポジトリ間で交換されるビジネス文書の集合
12	ビジネス文書と検索・応答メカニズムをサポートする基本的なインタフェース・メカニズムの集合
13	連携動作する2つのレジストリ間の特殊なCPA
14	レジストリ間対話に関連する機能プロセスの集合
15	エラー修復アクションに関連するエラー応答と条件の集合

　ここでサポートされるレジストリ対話は、ebXML要件書で定義された全機能のうち一部分の機能に相当します。また、アーキテクチャは、ebXML要件書で定義されたebXMLアーキテクチャとビジネス対話を概念的にサポートするものです。

　リポジトリ内に存在しレジストリによって管理される対象として、つぎのようなものがあります。

　

　リポジトリオブジェクトとそのメタデータの作成、変更、削除を効率的に行うには、レジストリ用の管理メッセージが必要になります。レジストリによってアクセスされるときに、リポジトリの認証と保護を実現するには、適切なセキュリティプロトコルを配備する必要があります。

　また、レジストリ・リポジトリに保存されるすべてのコンテンツは暗黙的に開示されるオープンな情報です。また、ebXMLレジストリに情報を送信するユーザは、情報管理に関する適切な権限を持っていなければなりません。ebXMLレジストリに情報を送信してコンテンツを変更するには適切な管理アクセス権限が必要ですが、レジストリからの情報の取り出しには特に制限は必要ありません。そのため、ebXMLレジストリにはパブリック情報であるCPPだけが保存され,取引相手の機密情報であるCPAは保存されないでしょう。

　

　アプリケーションによる自動化インタフェースや手作業によるGUIインタフェースを通じてリポジトリオブジェクトとそのメタデータに関する情報を取り出すには、レジストリ検索機構を使用します。

　リポジトリオブジェクトとそのメタデータは、レジストリに送信されるebXMLメッセージを通じて参照可能になります。HTTPだけを使用する単純な直接アクセスでは、リボジトリオブジェクトとそのメタデータをXMLベースのURI参照として検索することもできます。個々のリポジトリオブジェクトは一意の識別(UID)キーによって識別されます。UIDキーに対する検索を実行すると、一意のリポジトリオブジェクトが返されます。

　メタデータに対する検索では、管理対象オブジェクトについて定義されたメタデータ(メタデータの保守はオブジェクトの外部で行われる)に基づいてオブジェクト検索が実行されます。

　Webを使った手作業によるレジストリ検索では、主にブラウズ検査とドリルダウン検索が使用されます。その場合、ユーザはWebブラウザを使用し、HTTPプロトコルを通じてリポジトリの内容をブラウズする。最初は、組み込みの分類スキームに基づいて、リポジトリの内容をブラウズすることもできます。

　メッセージングサービスでは、さまざまな通信手順(SMTP,HTTP/S,FTPなど)を通じて取引当事者間でビジネス文書を交換するときに、メッセージの安全性と信頼性が保証されなければなりません。ebXMLメッセージングサービス仕様では、ebXML準拠メッセージを相互に交換するときに必要となるメッセージヘッダ情報とMIMEパッケージングが定義されています。ebXMLメッセージングサービスでは、ebXMLシステムの分散コンポーネント(レジストリ・リポジトリ、ebXML準拠アプリケーションなど)の間で交換されるすべてのメッセージがサポートされます。

　メッセージの交換時には、コラボレーションプロトコル合意書(CPA)で定義された実施ルールが適用されます。ebXMLメッセージングサービスでは、単純な片方向のメッセージ交換と要求・応答形式(同期または非同期)のメッセージ交換がサポートされます。ebXMLメッセージングサービスのインタフェースは、MIMEを転送する機能を持つ任意の通信サービスにマッピングすることができます。

　概念上、ebXMLメッセージングサービスは次の3つの部分に分解されます。

　図2−15に、抽象サービスインタフェース、メッセージングサービス層、通信サービスの相互関係を示します。

　

　ebXMLメッセージングサービスの抽象インタフェースでは、抽象レベルで次のような機能を使用できます。

　

　ebXMLメッセージングサービス層では、ebXMLメッセージのライフサイクル全体を管理するのに必要なサービスと機能がすべて提供されます。メッセージングサービス層によって提供される主な機能は次の通りです。

　図2−16に、ebXMLメッセージングサービスのアーキテクチャ内部に存在する機能モジュールの論理的配置を示します。これらの機能モジュールは、各モジュール間の相互関係と従属関係を表すように配置されています。このアーキテクチャ図はebXMLメッセージングサービスの柔軟性を示すもので、ebXMLシステムに実装できる広範なサービスや機能を表しています。

　

　ebXMLメッセージは、通信手順に依存するオプションの通信手順エンベロープと、プロトコルに依存しないebXMLメッセージエンベロープから構成されます。ebXMLメッセージエンベロープは、MIME multipart/relatedコンテンツ・タイプを使用してパッケージされます。電子ビジネス環境のパートナー間ではさまざまな種類の情報が交換されるため、MIMEがパッケージング方式として使用されます。例えば、二人以上の取引当事者間の複雑なB2B取引では、複数のビジネス文書(XMLや他の文書フォーマット)、バイナリ画像、設計図など、大量の情報(ペイロード)が必要となりえます。

　ebXMLメッセージエンベロープは、ebXML準拠メッセージの各コンポーネントをカプセル化するために使用されます。このような構造によって、ebXMLヘッダ情報がメッセージの内容から切り離されます。ヘッダのコンテナとメッセージ内容(ペイロード)のコンテナを分離すると、ヘッダ情報だけを使用してメッセージを処理すればよいため、ebXMLメッセージングサービスの処理効率が向上します。また、ebXMLメッセージングサービスの内部でペイロードを処理しないで、適切なビジネスサービスにさまざまなペイロードを透過的に転送する柔軟なメカニズムが実現されます。さらに、暗号化または署名されたペイロードを処理負荷なしで交換または転送することもできます。

　ebXMLペイロードコンテナはebXMLメッセージのオプション部品です。ebXMLメッセージ内にペイロードコンテナが存在する場合は、ebXMLペイロードエンベロープがebXMLメッセージの実際の内容(ペイロード)を含むコンテナとして機能します。ebXMLペイロードエンベロープは、MIMEヘッダ部分とコンテンツ部分(ペイロード自身)からなります。ebXMLメッセージングサービスでは、ペイロードの構造や内容について特に制限はありません。