| Interstage Application Server ebXML Message Service ユーザーズガイド |
|
目次
索引
|
| 第3章 環境作成 | > 3.1 ebMSの環境作成 | > 3.1.4 CPA管理 |
CPAは取引当事者（2者）ごとに作成します。CPAには当事者双方の通信条件が記述され、両当事者は同内容のCPAを参照します。当事者はCPAから取引に用いる通信条件を抽出します。
CPAの記述形式は“Collaboration-Protocol Profile and Agreement Specification Version 2.0”に従います。詳細は同文書を参照してください。なお、CPAの記述のうちebMSで必要とする部分については“付録B CPA記述条件”を参照してください。
以下に、基本的なCPAの作成方法を示します。ここでは、新規にebMSの動作に必要なCPAを作成するプロセスを示します。なお、ebMSが要求するCPAの記述条件については、“付録B CPA記述条件”を参照してください。
CPA内の記述の対応関係は以下の図のようになっています。取引当事者はPartyと呼ばれ、それぞれのPartyについての情報をCPA中のPartyInfo要素内に記述します。
CPAに記述される通信条件はServiceとActionによって特定されます。実際の取引においては、ServiceとActionはebMSを利用するアプリケーションにより、通信パラメタとして与えられます。通信パラメタについては“6.2 データ形式”を参照してください。
ServiceとActionが指定されると、それに伴ってDeliveryChannel、Packaging、Transport、DocExchangeの各要素が一意に決定され、それらの要素の記述内容から通信の条件が特定されます。各要素の関連付けは要素に付与されたIDにより行われます。
例えば、ServiceとActionが指定された場合、それらはCPA記述条件としてPartyInfo要素内で一意であるため、対応するPartyInfo要素内のThisPartyActionBinding要素を一意に定めることができます。ThisPartyActionBinding要素はpackageId属性と子要素のChannelId要素を持っているため、それらに指定されているIDREFから、該当するIDを持つPackaging要素とDeliveryChannel要素を一意に決定することができます。さらに、DeliveryChannel要素はtransportId属性とdocExchangeId属性を持っているため、Transport要素とDocExchange要素も一意に決定することができます。図では、これらの関連付けられた要素間の対応関係を矢印で模式的に示しています。各要素でのIDやIDREFの記述形式については、“付録B CPA記述条件”を参照してください。
CPAを作成する際には、IDによる要素間の関連付けを適切に行う必要があります。IDによって要素を関連付けたCPAの基本的な構造については、“B.2.1 CPAサンプル”を参考にしてください。
ここでは図中、Service1のAction1に着目します。Action1はParty A側ではCanSend要素に属しています。一方のParty B側ではCanReceive要素に属しています。従って、このActionを利用する場合はParty Aが送信側、Party Bが受信側になります。このように、同名のService・Actionの組み合わせでは、片方が送信側、他方が受信側になるようにCPAを設計してください。ServiceはServiceBinding/Service要素に記述します。ActionはThisPartyActionBinding/action属性に記述します。
図の設定では、Party AからAction1を用いるメッセージを送信する場合、DeliveryChannel A-1、そしてそれに関連付けられたTransport A-1、DocExchange A-1を利用します。
一方、Party BでAction1のメッセージを受信するにはDeliveryChannel B-2、Transport B-1、DocExchange B-2を利用します。
これらから、Action1のメッセージ送受信では、DeliveryChannel A-1とB-2、Transport A-1とB-1、DocExchange A-1とB-2について設定が整合していなければなりません。
以降の節では、図中のAction1のメッセージ送信時を例に、要素作成の概要を示します。
Transport要素には通信プロトコルやあて先URLを記述します。
Transport要素の内部はTransportSenderとTransportReceiverに分かれています。Action1の例では、Party Aは送信側となるため、Transport A-1のTransportSenderを利用します。一方、Party Bは受信側となるため、Transport B-1のTransportReceiverを利用します。
ebMSでは、通信プロトコルはHTTPのみをサポートしています。Action1の例では、送信側となるTransport A-1のTransportSender/TransportProtocolと、受信側となるTransport B-1のTransportReceiver/TransportProtocolに共にHTTPを指定する必要があります。
あて先URLを記述するEndpoint要素はTransportReceiverのみに記述できます。前述のAction1のメッセージは、Transport B-1のTransportReceiverに含まれるEndpointのURLに送信されることになります。
DocExchange要素には、ebXMLメッセージサービス仕様によってサポートされている機能の適用条件を記述します。
DocExchange要素の内部は、ebXMLSenderBindingとebXMLReceiverBindingに分かれています。Action1の例では、Party Aは送信側となるため、DocExchange A-1のebXMLSenderBindingを利用します。一方、Party Bは受信側となるため、DocExchange B-2のebXMLReceiverBindingを利用します。
通信時に直接対応するDocExchange同士の設定は、送信側と受信側で一致している必要があります。Action1の例では、送信側となるDocExchange A-1のebXMLSenderBinding/ReliableMessaging/Retriesに20を指定した場合、受信側となるDocExchange B-2のebXMLReceiverBinding/ReliableMessaging/Retriesにも20を指定する必要があります。他の要素・属性についても同様です。一致していない設定がある場合、CPA登録時にエラーになります。
DeliveryChannelの主な目的は、IDによってTransportとDocExchangeへのリンクを提供することです。また、リンク以外の記述要素であるMessagingCharacteristicsには、一部メッセージングの特性が記述されます。
MessagingCharacteristicsは必須記述要素です。通信時に直接対応するDeliveryChannel同士のMessagingCharacteristics要素に記述される通信条件は、送信側と受信側で一致している必要があります。Action1の例では、送信側となるDeliveryChannel A-1のMessagingCharacteristics/ackRequestedにalwaysを指定した場合、受信側となるDeliveryChannel B-2のMessagingCharacteristics/ackRequestedにもalwaysを指定する必要があります。MessagingCharacteristicsの他の属性についても同様です。一致していない設定がある場合、CPA登録時にエラーになります。
ebMSでサポートするCPAの要素・属性には、記述の省略が可能なものが存在します。それらを省略した場合、その要素・属性にはデフォルト値が設定されます。例えば、DeliveryChannel/MessagingCharacteristics/ackRequestedについてはneverがデフォルト値であるため、送信側がackRequested="never"と明記し、受信側はackRequestedの記述を省略した場合でも、双方のackRequestedはneverで整合しているとみなされ、エラーにはなりません。CPAで記述する各設定のデフォルト値については、“付録B CPA記述条件”を参照してください。
|
目次
索引
|