ebXMLのメッセージングの仕様(Message Service)はHTTPのような特定の転送プロトコルとは独立に設計されています。セキュリティ機構や信頼性通信のように、オプションで使用できる仕組みも用意されています。また、用いるメッセージの種類や交換順序の定義(ビジネスプロセス定義)は一つに決まっているわけではなく、BPSS (Business Process Specification Schema)によって様々に定義されます。

このため、取引を企業間で正しく実行するには、通信に用いる規約やパラメタ、ビジネスプロセス定義等を、取引の当事者双方で予め合意しておかなければなりません。例えば、自社の通信ソフトウェアが受領通知(acknowledgment)を必要としているのに、取引相手が受領通知を送らない設定でソフトウェアを動かしていたら、取引は全く進みません。

そこで、このような取り決めを厳密に合意し、ソフトウェアを正しく設定するための仕組みがebXMLの標準として用意されています。それがCPP (Collaboration Protocol Profile)、CPA (Collaboration Protocol Agreement)です。この二つをあわせてCPPAと呼ぶこともあります。

CPPは、取引を行う企業のメッセージ交換の能力を記述します。例えば、転送プロトコルに何を使うか、暗号化や署名はどのような方式で行うか、また、どのビジネスプロセス定義のどの役割を実行できるかといったことを表します。

CPAは、取引を行う企業双方で合意したメッセージ交換の合意内容を記述します。CPAは双方のCPPを元にして作成します。取引を実行する際は、CPAで合意した方式に則ってメッセージ交換を進めることになります。

CPP/CPAはXML文書として記述します。人間が目で読むだけでなく、ソフトウェアが読み込んで自動的に設定できるよう設計されています。

CPAには通信に使うプロトコルやパラメタが書かれています。このため、ebXML Message Service (MS)を実装するメッセージサービスハンドラ(MSH)は、CPAから情報を得て設定を行います。また、MSのメッセージヘッダに設定するServiceやActionといった要素の内容もCPAで決めます。

CPAは、各企業がビジネスプロセスのどの役割を実行するかを示します。このため、CPAにはBPSSで記述したビジネスプロセス定義への参照を含みます。各企業は、参照先のビジネスプロセス定義に従って取引を進めなくてはなりません。

つまり、MSを使うための詳細を指定するためにCPPAを利用し、CPPAはBPSSを参照するという形で、これらの仕様は関係しあっています。この様子を下図に示します。

なお、メッセージサービスやビジネスプロセス定義には、必ずしもebXMLのMS やBPSSを使う必要はなく、同等の機能を実現する仕様であればCPPAとともに使用できることになっています。

企業間で取引を開始するためにCPPAがどう使われるか、一般的なストーリーを描いてみましょう。

ebXMLで取引を行う企業は、自社のCPPを作成します。つまり、自社が実行できるビジネスプロセス定義(例えば電子部品の受発注業務)を参照し、そのプロセスのどの役割を実行できるか(発注者か受注者か)を示します。また、転送プロトコルとしてHTTPSを使い、メッセージの再送は3回までといったことや、メッセージの受信に使うURLなども指定します。

次に、取引相手との間で互いのCPPを照らし合わせて、CPAを作成します。もし複数の企業との間で似たようなCPAを作るなら、CPAのテンプレートを作成しておく方法もあります。取引相手のCPPとの間で通信方式などに食い違っている点があれば、交渉してすりあわせます。CPP/CPAはXML文書なのでテキストエディタやXMLエディタでも編集できますが、CPA専用のツールを使えばより効率的に作業できます。

取引相手との間で食い違いが解消されたら、合意に達したCPAとして完成させます。完成したCPAは、取引当事者双方が同じコピーを保存します。

CPAが完成したら、ebXMLの取引を実行するソフトウェアにCPAを入力として与え、合意内容に即して設定します。これで、取引を実行する準備が整いました。

それではCPPの具体的な構成を見ていきましょう。CPPには多くの要素・属性がありますが、ここでは細部は省略して、重要な点を中心に説明します。

CPPの最上位要素はCollaborationProtocolProfile要素です。以下の内容を持ちます。

PartyInfo要素はCPPの中心的な役割を果たす要素です。子要素として以下を含みます。

PartyId要素は、企業コードなどの識別情報を表します。例えばDUNS番号などが相当します。

PartyRef要素は企業の情報が得られるWebサイトへのリンクを表します。

CollaborationRole要素は、その企業が実行できるビジネスプロセス上の役割を示します。役割とは例えば発注者・受注者などです。外部のビジネスプロセス定義文書と、その中で定義される役割の種類とを参照することで指定します。また、メッセージ交換の際にどのチャネルを使うかということも併せて指定します。この要素は以下の子要素をもちます。

ProcessSpecification要素でビジネスプロセス定義を指定します。URIによるリンクと、ビジネスプロセス定義内で指定されている名前、バージョン、uuid (URI形式)を用いて指定します。

ビジネスプロセス定義の中で自社が実行する役割を、Role要素で指定します。

以下に例を示します。

<tp:ProcessSpecification tp:version="2.0" tp:name="PurchaseOrder" 　xlink:type="simple" 　xlink:href="http://some-standard.org/order.xml" 　tp:uuid="urn:somestandard:bpid:order$2.0"/> <tp:Role tp:name="Buyer" xlink:type="simple" xlink:href="http://some-standard.org/order.xml#Buyer"/>

自社の担当する役割が決まると、送受信できるメッセージの種類も定まります。そこで、実行可能なメッセージ交換のそれぞれについて、どの配送チャネルを使うかをServiceBinding要素で指定します。配送チャネルについては4.1.3節を参照してください。

配送チャネルの指定に関して、ServiceとActionという二つの概念が使われます。これらはMSのメッセージヘッダに現れる同名の要素に対応するものです。Actionは、メッセージ一つの送信または受信の種類ごとに名前を付けたものです。例えば、「見積り依頼の送信」というのが一つのActionになります。一方、Serviceはビジネスプロセス定義の中で実行可能なActionを束ねたものです。BPSSを使用する場合はProcessSpecification要素のuuid属性の値を用いることが規定されています。ActionはServiceの中で一意であるように命名されます。ServiceとActionの組み合わせによって、あるメッセージ交換が何をするものなのかを特定できます。

ServiceBinding要素では、まずService要素でServiceを指定し、次にCanSend要素とCanReceive要素とによって、送信可能および受信可能なActionのそれぞれを列挙し、各Actionに対応する配送チャネルを指定します。

次の例では、「Purchase Order Request Action」というActionに対して「ChannelA1」というIDの配送チャネルを割り当てています。メッセージのパッケージング(4.4節参照)としてID「Package_A」で示す定義を用いることも同時に指定しています。このActionがビジネスプロセス定義の中のどこにあたるものなのかは、ActionContext要素で指定しています。また、BusinessTransactionCharacteristics要素によって、ビジネスプロセス定義で指定されたtimeToPerform属性を上書きしています。

<tp:ServiceBinding> 　　<tp:Service>bpid:somestandard:order$2.0</tp:Service> 　　<tp:CanSend> 　　　<tp:ThisPartyActionBinding 　　　　tp:id="companyA_ABID1" 　　　　tp:action="Purchase Order Request Action" 　　　　tp:packageId="Package_A"> 　　　　<tp:BusinessTransactionCharacteristics tp:timeToPerform="P1D"/> 　　　　<tp:ActionContext 　　　　　tp:binaryCollaboration="Request Purchase Order" 　　　　　tp:businessTransactionActivity="Request Purchase Order" 　　　　　tp:requestOrResponseAction="Purchase Order Request Action"/> 　　　　<tp:ChannelId>ChannelA1</tp:ChannelId> 　　　</tp:ThisPartyActionBinding> 　　</tp:CanSend> 　　<!-- 以下同様に、送信可能なActionをCanSendで、受信可能なActionをCanReceiveで一つずつ指定。--> </tp:ServiceBinding>

配送チャネルとは、メッセージ交換に用いるプロトコルやURI、パラメタなどを集めて名前を付けたものです。Transport要素とDocExchange要素の組み合わせによって定義します。前者は転送プロトコル(HTTP等)に関する特性、後者はより上位のメッセージサービスで指定する内容を記述します。用いるTransport、DocExchangeはIDで指定します。この様子を下図に示します。また、子要素のMessagingCharacteristics要素によって、同期応答の使用などの指定ができます。配送チャネルは複数定義でき、上述のServiceBinding要素の中でActionの種類に応じて使い分けることができます。

下の例では、ID「transportA2」で示されるTransport要素と、ID「docExchangeA1」のDocExchange要素とを組み合わせて、「ChannelA1」というIDの配送チャネルを定義しています。また、MessagingCharacteristics要素によって、このチャネルでは非同期な通信を用いることと、毎回必ず受領通知を用いることを示しています。

<tp:DeliveryChannel 　tp:channelId="ChannelA1" 　tp:transportId="transportA2" 　tp:docExchangeId="docExchangeA1"> 　<tp:MessagingCharacteristics 　　tp:syncReplyMode="none" 　　tp:ackRequested="always"/> </tp:DeliveryChannel>

Transport要素はデータ転送に用いるプロトコル(HTTP等)や、通信層のセキュリティ機構(SSL等)を指定します。子要素のTransportSenderとTransportReceiverとで、それぞれ送信側と受信側の設定を記述します。送信側も受信側も設定できる内容はほぼ同じです。

TransportSenderは以下の内容を持ちます。

• 転送プロトコル(HTTP等)
• 認証方式(HTTPのBasic認証等)
• セキュリティ機構(SSL等)

TransportReceiver要素の例を以下に示します。

<tp:TransportReceiver> 　<tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol> 　<tp:AccessAuthentication>basic</tp:AccessAuthentication> 　<tp:AccessAuthentication>digest</tp:AccessAuthentication> 　<tp:Endpoint 　　tp:uri="https://www.CompanyA.com/ebxmlhandler" 　　tp:type="allPurpose"/> 　<tp:TransportServerSecurity> 　　<tp:TransportSecurityProtocol tp:version="3.0">SSL</tp:TransportSecurityProtocol> 　　<tp:ServerCertificateRef tp:certId="CompanyA_ServerCert"/> 　　<tp:ClientSecurityDetailsRef tp:securityId="CompanyA_TransportSecurity"/> 　</tp:TransportServerSecurity> </tp:TransportReceiver>

DocExchange要素はメッセージサービスに応じた特性の指定を行います。今のところ、ebXMLのMSに対応したebXMLSenderBindingならびにebXMLReceiverBinding要素が子要素として用意されています。将来的には異なるメッセージサービスのための指定方法が用意される可能性があります。

ebXML{Sender|Receiver}Binding要素では、以下の内容が指定できます。

• 信頼性通信 (Reliable Messaging)―再送回数、再送間隔、順序保証の有無
• メッセージ保存期間
• 否認拒否―XML Signatureの使用、用いるハッシュ関数等
• デジタルエンベロープ―S/MIME等
• 使用するXML名前空間

MSHレベルのAction (受領通知、エラー通知等)に使うチャネルはPartyInfo要素の属性で設定しますが、このデフォルト値をOverrideMshActionBinding要素によって上書きすることができます。action属性でActionの種類を指定し、channelId属性でそのActionに用いるチャネルをID参照します。なお、MSHのActionの値はMSの仕様で定められています。

CPPで用いる証明書の情報をCertificate要素で表します。この要素の内容はXML Signatureのds:KeyInfo要素です。Certificate要素は必要な数だけ記述できます。各々にID型のcertId属性を設定し、他の要素から参照します。

SecurityDetails要素にはTrustAnchors要素とSecurityPolicy要素が入ります。

TrustAnchorsには、その企業が信頼する証明書(Certificate要素)への参照が複数入ります。これは証明書の連鎖を検証する際に用い、証明書がTrustAnchorsのいずれかへ至らなければ検証が失敗したことになります。

SecurityPolicyはセキュリティポリシーを指定するための要素ですが、将来のための予約として用意されているもので、まだ使い方は決まっていません。

メッセージを送る際は通常、ebXMLメッセージヘッダと本文(伝票)、もし必要なら添付ファイルが付くという構成になります。このような、メッセージのパッケージングを定義するのがSimplePartとPackaging要素です。SimplePart要素はMIMEにおける個々のパートに相当し、各パートをどのように組み合わせるかをPackaging要素で指定します。

定義したPackaging要素はIDで他の要素から参照します。具体的には、ThisPartyActionBinding要素で各Actionごとに対応するパッケージを指定します。

このCPPのデジタル署名です。Signature要素の中に、XML Signatureのds:Signature要素が入ります。

このCPPについてのコメントを、人間が読むテキストとして入れることができます。xml:lang属性で言語の指定(日本語、英語など)ができます。

CPAはCPPを元に作成するので、構成要素はCPPとほぼ同じです。ただし、2社分のPartyInfoが入ることと、CPA特有の情報がいくつか入る点が異なります。

CPAの最上位要素はCollaborationProtocolAgreement要素です。その中に以下の要素が入ります。

このCPAの現在の合意の状況を示します。“proposed”(交渉中)、“agreed”(合意に達した)、“signed”(署名済み)のいずれかの値をとります。

CPAが効力をもつ期間を、Start要素とEnd要素のそれぞれに開始・終了の日時を設定することで表します。日時はXMLスキーマのdateTime型で表します。

このCPAのもとで行う会話の最大数や、並行して行える会話の最大数を制限することができます。

CPPに出てきたPartyInfo要素を、取引を行う企業それぞれについて記述します。

CPAの場合、相手側PartyInfoの中を指すID参照もあります。したがって、相手の定義内容から対応するID値を取得してきて自社のPartyInfoに入れる必要があります。このような要素としては、例えばCanSend要素の中のOtherPartyActionBindingがあります。

CPAにおいては、自社の送信と相手の受信、自社の受信と相手の送信の設定について、整合性がとれていなければなりません。

SimplePart要素とPackaging要素でメッセージのパッケージングを定義します。これはCPPと同様です。

このCPAのデジタル署名を付けることができます。

CPPと同様、CPAのコメントを記述することができます。