Visits: 633

Open PEPPOLのeDelivery関連資料は、OpenPEPPOL eDEC Specificationのページに記載。
AS4 Profileに関しては、OpenPEPPOLは、CEF eDeliveryが規定している仕様の一部を採用して運営している。

Open PEPPOLのeDelivery AS4 Profile仕様は、こちらのページ。
CENのeDelivery AS4 Profile仕様は、eDelivery AS4 – 1.15のページ。

Open PEPPOLは、2021年3月時点では、eDelivery AS4 – 1.14を使用しているが、仕様の確認は、eDelivery AS4 – 1.15を参照して調査した。
セキュリティ関連の規定がOpen PEPPOLの文書には詳細が記載されていないため、以下にeDelivery AS4 – 1.15を抄訳する。(Part 1)

3.共通プロファイル

eDelivery AS4共通プロファイルでは、OASIS ebMS3およびAS4プロファイルに準拠する。 eDelivery AS4 Common Profileは、AS4仕様[AS4]で規定されている特定の適合プロファイルであるAS4 ebHandler適合プロファイルを使用し、AS4の高度な機能を使用する。AS4使用プロファイルは、任意のペイロード（ヘッダーやトレーラを含まない本体データ）の組み合わせの一般的な交換に準拠した実装を使用する方法を定義します。このeDeliveryAS4共通プロファイルでは、AS4 ebHandlerプロファイルで使用可能な一部の機能（プル交換パターンバインディングやWS-Securityユーザー名トークン認証など）は使用されないが、その他のオプション機能（TLS、XML署名、XML暗号化）は必須であり、特定のアルゴリズムで使用される。 共通プロファイルは、いくつかの基礎となる仕様の最新バージョンを使用し、双方向MEPのサポートを義務付けることにより、AS4を拡張する。

3.1. AS4および適合性プロファイル

eDelivery AS4プロファイルは、ebMS3.0バージョン1.0 OASIS仕様[AS4]のAS4プロファイルに基づいている。 AS4は、他の仕様、特にOASIS ebXMLメッセージングサービスバージョン3.0：パート1、コア機能OASIS仕様[EBMS3]に基づいており、これはさまざまなWebサービス仕様に基づいている。

AS4仕様は、バージョン3.0 ebXMLメッセージング、コア仕様の特定の機能サブセットを定義する複数の適合プロファイルを定義する。適合プロファイルは、適合アプリケーションのクラスに対応する。 AS4のこの共通プロファイルは、AS4 ebHandler適合性プロファイルの拡張サブセット、AS4の高度な機能の選択、および使用プロファイルに基づいている。 ebMS3「プッシュ」トランスポートチャネルバインディングを使用したeDeliveryアクセスポイントを使用した送信者から受信者へのポイントツーポイント通信をサポートする。オプションのFourCorner Topology機能は、これをメッセージングインフラストラクチャの相互接続に拡張する。

「プッシュ」を使用することにより、生産者(Producer)によって送信側のebMS3メッセージサービスハンドラー（MSH）に送信されたメッセージは、「プル」トランスポートチャネルバインディングの（予測できない）遅延なしに、受信側のebMS3 MSHにすぐに送信される。受信側MSHから消費者(Consumer)への要求メッセージの送信の待ち時間は、逆の順序で、消費者による要求メッセージコンテンツの業務処理、およびMSHを使用した消費者から生産者への応答メッセージの逆フローを想定することなく最小化できるので、このプロファイルは、「対話式」の応答を必要とする、応答時間の要求が厳しい業務プロセスもサポートできる。

3.2. eDelivery AS4ebHandler機能セット

eDelivery AS4共通プロファイルの機能セットは、いくつかの例外を除いて、AS4仕様[AS4]のセクション2.1.1で指定されているAS4ebHandler適合性プロファイルの機能セットのサブセットでである。このセクションでは、AS4ebHandlerが複数のオプションから選択できる状況で、特定のオプションを選択する。したがって、このセクションは、AS4実装で提供される機能のチェックリストとして使用できる。このセクションの構造は、ebMS3コア仕様[EBMS3]の構造を反映している。 ebMS 3.0プロトコルは、同期通信と非同期通信をサポートでき、Webサービスとの完全な統合を提供する。これは、SOAP 1.2、WS-Security 1.1、およびSOAP-with-attachments仕様を再利用する。 WS-I基本プロファイル（BP）および基本セキュリティプロファイル（BSP）に準拠し、特に、中小企業に関連する追加機能、特にメッセージ・プルを提供する。 AS4は、ユーザーメッセージの同期交換の要件を削除するが、AS4 ebHandler適合性プロファイルは、同期および非同期の信号メッセージを許可する。

AS4 ebHandler適合性プロファイルと比較して、このeDelivery Common Profileプロファイルでは、いくつかの機能を更新および追加する。

• 双方向MEPをサポートするための追加要件がある
• トランスポート層セキュリティは、AS4ハンドラーで処理される場合、プロファイルされ、その使用は必須
• WS-Securityは必須であり、WS-Security仕様バージョンは1.1.1
• メッセージレイヤーでメッセージを保護するために指定されたアルゴリズムは、現在のガイドラインに更新され、特定のアルゴリズムを使用した署名と暗号化の使用が必須
• IPv4およびIPv6のサポートが明示的に必要

また、いくつかの要件を緩和する。

• このバージョンの共通プロファイルでは、AS4でのプルモードのサポートは必要ない
• すべてのペイロード（ヘッダーやトレーラを含まない本体データ）は、SOAP本体ではなく、個別のMIME部分で交換される
• 受領応答(Receipts)とエラーは同期的にのみ報告される
• WS-Securityサポートは、X.509トークンプロファイルに限定されており、UserNameトークンの使用はサポートされていない

プル機能はeDelivery共通プロファイルの一部ではないが、オプションのプロファイル拡張機能として使用できることに注意。

3.2.1. メッセージ交換パターン

次の段落で、ebMS3.0コア仕様[EBMS3]で定義されているいくつかの重要な概念と用語を要約する。

1. メッセージングサービスハンドラー（MSH）、生産者(Producer)、消費者(Consumer)。
   MSHは、ebMS仕様に準拠するメッセージを生成または処理し、送信者または受信者として機能することができるエンティティ。 生産者(Producer)は、送信側MSH（送信する役割のMSH）と対話してユーザーメッセージの送信を開始するエンティティ（アプリケーションなど）。 消費者(Consumer)は、受信側のMSH（受信する役割のMSH）と対話して、受信したユーザーメッセージからデータを消費するエンティティ。
2. メッセージ、ユーザーメッセージ、シグナルメッセージ。
   メッセージは、ユーザーメッセージまたはシグナルメッセージ、あるいはその両方で構成される論理ユニット。 ユーザーメッセージは、ユーザーメッセージユニット（XML構造eb:Messaging/eb:UserMessage）を含むメッセージ。 シグナルメッセージは、シグナルメッセージユニット（XML構造eb:Messaging/eb:SignalMessage）を含むebMSメッセージ。 言い換えると、ebMS仕様には2つのタイプのメッセージが存在する。最初のタイプは消費者によって解釈されたデータの送信に使用し、2番目のタイプはMSHによってシグナルとして解釈されたデータの送信に使用する（プル信号、受信、エラーなど）。
3. メッセージ交換パターン（MEP）
   一方向/プッシュOne-Way/Push、一方向/プルOne-Way/Pull、双方向/同期Two-Way/Sync MEP。
   MEPは、MSHの送信と受信の間の合意。 メッセージング層でサポートされるMEPのいくつかの側面は次のとおり:
   * メッセージヘッダーで送受信されるメッセージ間の相関関係を指定
   * 基になる転送プロトコルへのメッセージバインディング
   一方向/プッシュOne-Way/Push、一方向/プルOne-Way/Pull、および双方向/同期Two-Way/Sync MEPは、MSH間の合意を記述する。
4. 処理モード（Pモード）
   Pモードは、特定のメッセージの処理を管理するコンテキスト情報（したがって、基本的には構成パラメーターのセット）。 メッセージに関連付けられたPモードは、特に、どのセキュリティおよび/または、どの信頼性プロトコルとパラメータ、およびメッセージの送信時に使用されているMEPを決定する。 P-モード構成の技術的表現は、実装に依存。

AS4プロファイルのメッセージングモデルは、2つのAS4　MSH間のメッセージ交換のチャネルバインディングを制約する。 次の図は、AS4メッセージングモデル、さまざまなアクター、およびメッセージ交換の操作を示す。

生産者(Producer)として機能するビジネスアプリケーションまたはミドルウェアは、メッセージコンテンツとメタデータを送信MSHに送信する。送信側MSHは、このコンテンツをパッケージ化し、ビジネスパートナーの受信側MSHに送信する。受信側MSHは、メッセージを受信して、メッセージを消費する別のビジネスアプリケーションまたはミドルウェアに配信する。 構成に応じて、MSHの送信と受信は、特定のイベントを生産者(Producer)または 消費者(Consumer)に通知する場合がある。 SenderとInitiatorには違いがあることに注意。 プッシュ交換の場合、送信側MSHはメッセージの送信を開始する。 プル交換（eDelivery共通プロファイルではサポートされていない）の場合、送信は受信側MSHによって開始される。 また、ビジネスアプリケーションには、MSH機能を含めることができるので、MSHは抽象的な概念となることにも注意。
生産者(Producer)、送信者(Sender)、受信者(Receiver)、消費者(Consumer)の概念は、４コーナートポロジの概念のコーナーとは別のものであり、混同しないこと（セクション4.1を参照）。 個別のコンポーネントだが、メッセージ生産者(Producer)エンティティと送信側MSHエンティティは、企業内部コンポーネントのみである場合があり、異なる通信、業務、または法的IDに関連付けられていない場合がある。 MSHの送信と受信はメッセージングエンドポイントであり、仲介者ではない。
異なるメッセージ生産者(Producer)が単一の送信側MSHを共有し、単一の受信側MSHが異なるメッセージ消費者(Consumer)にサービスを提供し、メッセージメタデータまたはペイロードコンテンツをルーティング配信基準として使用して、メッセージルーティング機能を提供する場合がある。 たとえば、AS4 eb：Serviceヘッダーのさまざまな値を使用して、特定の消費者(Consumer)を選択できるが、この機能仕様は、本仕様の範囲外。
単一のMSHが、複数の送信者エンティティに代わってメッセージを送信するように構成されている場合、または異なるIDを使用して複数の受信者エンティティに代わってメッセージを受信するように構成されている場合があり、それぞれが異なる組織(Party)識別子、証明書およびエンドポイントURLを含む異なる処理モード構成に関連付けられている可能性がある。 この機能の実装と構成は、実装に依存する。
AS4 ebHandler適合性プロファイルは、プッシュチャネルバインディングを使用して、送信の役割と受信の役割のサポートを提供するAS4適合性プロファイル。 次のメッセージ交換パターンのサポートが必要。

• 一方向/プッシュ One Way/Push
• 双方向/プッシュ＆プッシュ Two Way / Push-and-Push

ebMSメッセージ交換のコンテキストでは、プッシュは送信者がメッセージ交換を開始することを意味する。 HTTPの場合、これは、送信側MSHがHTTPクライアントとして機能し、受信側MSHがHTTPサーバーとして機能していることを意味する。 プルとは、受信者がメッセージ交換を開始することを意味する。 HTTPの場合、その状況では、受信側MSHはHTTPクライアントであり、送信側MSHはHTTPサーバー。
一方向/プッシュMEPは、一方向/プッシュMEPの使用に同意した送信側MSHが、一方向/プッシュMEPの使用に同意した受信側MSHにメッセージを送信する状況を指定する。 メッセージが正常に受信された後、受信側のMSHは、受信を確認するために、非ユーザメッセージ（すなわち、信号メッセージ）を送信側のMSHに返す。 異なるユーザーメッセージは、同じ会話の一部である場合を除いて、相互に参照することはない。

AS4ebHandlerは双方向MEPのサポートを必要としないが、このMEPのサポートはこのeDelivery共通プロファイルで必要。 要求メッセージと応答メッセージの相関ペアを含むビジネスプロセスに使用できる。 双方向MEPをサポートするメッセージハンドラーを使用すると、応答ユーザーメッセージユニットを送信する生産者(Producer)は、eb:MessageInfoセクションのオプションのeb:RefToMessageId要素を設定して、対応する要求ユーザーメッセージユニットを識別できる。
PMode.MEPでは、次の値についてのサポートが必要：

• http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/oneWay
• http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/twoWay

PMode.MEPbindingでは、次の値についてのサポートが必要：

• http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/push
• http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/pushAndPush

これらのURI値は識別子のみであり、ebMS3仕様のセクション2.2.8で定義されていることに注意。 OASISサイトのコンテンツには解決されない。
時間の制約が厳しなプロセスでは、送信者がメッセージの送信のタイミングを制御できるように、プッシュチャネルバインディングが必要。 組織Aと組織Bの間の対話型の要求/応答通信は、2つのプッシュメッセージの組み合わせとして提供できる。Aに代わって送信側MSH（これは、Bの受信者として機能する）、から受信側MSHに送信されるメッセージに続いて、BからMSHを使用してAのMSHへの個別の（非同期）応答メッセージが送られる。

— 以降のTwo-Way/Sync MEP 及び Two-Way/Push-and-Push MEP の記載は、Open PEPPOLでサポートしていないので省略 —

3.2.2. AS4メッセージ構造とUserMessage

AS4メッセージ構造は、一般的なデータ交換要件に対応する標準のメッセージヘッダーを提供し、SOAPおよびMIME封書に基づく柔軟なパッケージ化メカニズムを提供する。 オプションのメッセージコンポーネントを破線で示す。

UBLで表現された電子インボイスは、XML構造PEPPOL Business Message Envelope (SBDH)の中に包含されており、そのXMLファイル（SBDH）は、圧縮されて、MIME封書のペイロード（ヘッダーやトレーラを含まない本体データ）として送付される。
SBDHについては、こちらのページで説明。

SOAP封筒はUTF-8としてエンコードする必要がある（[EBMS3]のセクション5.1.2.5参照）。 SOAP封書がUTF-8で正しくエンコードされ、文字セットヘッダーがUTF-8に設定されている場合、受信者はUnicodeバイトオーダーマーク（BOM、[BP20]、セクション3.1.2参照）の存在をサポートする必要がある。

AS4は、ebMS3 eb:Messaging SOAPヘッダーを定義する。これは、ユーザーメッセージでは、ペイロード（ヘッダーやトレーラを含まない本体データ）を交換するためのビジネスメタデータを提供するXML構造eb:UserMessageの封書。 AS4では、受信またはエラー以外のebMS3メッセージは単一のeb：UserMessageを伝送する。
送信側MSHとして機能する準拠実装は、ユーザーメッセージを送信するときに、生産者(Producer)が次のことを許可する必要がある。

• eb:ConversationIdの値を設定する。 これにより、消費者(Consumer)は、ユーザーメッセージを同じ会話の一部である関連するユーザーメッセージに関連付けることができる。
• Two WAY MEPのビジネス応答メッセージのeb:RefToMessageIdの値を設定する。 これにより、消費者(Consumer)は、ユーザーメッセージが応答している、以前のAS4要求ユーザーメッセージを示すことができる。 eb:ConversationIdの共有値は、単一の会話に複数の未処理の要求が存在する可能性があるため、要求と応答を相互に関連付けるには不十分であることに注意。

受信側MSHとして機能する準拠実装は、eb:MessageId、eb:ConversationId、および利用可能な場合はeb:RefToMessageIdの値を、消費者(Consumer)に配信するユーザーメッセージのメタデータとして提供する必要がある。
ビジネス応答メッセージをその前の業務要求メッセージに関連付けるには、生産者(Producer)はこの要求メッセージのeb:MessageIdを知っている必要がある。 この要件の実装は実装に任されているが、次のいずれかになる。

• MSHは、生産者(Producer)がユーザーメッセージユニットを送信するときに、eb:MessageIdに使用する特定の値を指定できるように許可する
• MSHは、eb:MessageId値を生成し、生成された値をプロデューサーに通知する

ebMS3およびAS4仕様は、インターネットメッセージ形式[RFC2822]への準拠を要求する以外に、eb:MessageIdの値を制約しない。これは、値が一意であり、[RFC2822]のセクション3.6.4で定義されているmsg-id形式を使用する必要がある。 値には、msg-id識別子のid-left部分にUUID(ユニバーサル一意識別子)
を含めることを勧める。
準拠する実装は、該当するPMode.Agreementパラメーターを構成することにより、eb:AgreementRefヘッダーコンテンツとそのタイプ属性の存在と値を構成できる必要がある。
準拠した実装では、生産者(Producer)がメッセージを送信するときに、eb:AgreementRefの値を設定し、これを使用して特定のPモードを選択できるようにする必要がある。
受信者(Receiver)として機能する適合実装は、該当するPモードを選択するときは、eb:From/eb:PartyID、eb:From/Role、eb:To/PartyID、eb:To/Role、eb:Service、eb:Action、およびeb:AgreementRefヘッダーを考慮に入れて、P-Modeパラメーターを使用して、設定されたすべてのebMS3ヘッダーの存在、値、および属性値を取得する必要がある。eb:AgreementRefのオプションのpmode属性が設定されていないメッセージを送受信できる必要がある。
AS4 ebHandlerプロファイルと同様に、このプロファイルではeb:MessagePropertiesのサポートが必要。 メッセージプロパティのtype属性を設定できる必要がある（https://issues.oasis-open.org/browse/EBXMLMSG-2を参照）。 この共通プロファイルでは特定のメッセージプロパティの使用は指定されていないが、この機能はオプションの４コーナートポロジー拡張機能で使用される。

3.2.3. ペイロードのパッケージ化

ebMS3コア仕様[EBMS3]のセクション5.1.1では、非マルチパート（単純なSOAP）メッセージとマルチパート（添付ファイル付きSOAP）メッセージの両方を処理する実装が必要であり、これはAS4ebHandler適合性プロファイルの要件。 このeDeliveryAS4プロファイルに基づくAS4メッセージは、SOAP本体にペイロード（ヘッダーやトレーラを含まない本体データ）コンテンツを含めてはならない（MUSTNOT）。 このプロファイルではAS4圧縮機能が必須であるため（セクション2.2.3.3を参照）、XMLペイロードはバイナリデータに変換される場合がある。バイナリデータは、SOAP本体ではなく個別のMIME部分で伝送される。 したがって、準拠したeDelivery AS4メッセージには、常に空のSOAP本文がある。
ハイパーリンク参照を介して「外部」ペイロードをサポートするebMS3メカニズム（ebMS3コア仕様[EBMS3]のセクション5.2.2.12に記載）は使用しないこと。
AS4を使用して1つのメッセージで複数のペイロード部分を交換し、Content-IDリソースロケーター構文[RFC2392]を使用してエンコードされたペイロード間に相互参照がある場合、送信側の生産者(Producer)は、MIMEペイロード部分のContent-ID値を設定できなければならない。 受信側のMSHは、ペイロード部分のContent-ID情報を消費者(Consumer)が利用できるようにする必要がある。 MIME Content-ID AS4を使用する代わりに、メッセージに含まれる各ペイロードにパーツプロパティを割り当てるオプションがあり、ペイロード間の相互参照にも使用できることに注意。 ペイロード間の相互参照の必要性をなくすために、生産者(Producer)は、MSHに送信する前にペイロードを1つのコンテナーパーツにパッケージ化することもできる。
複数のペイロードを含むメッセージをMSHに送信する生産者(Producer)は、ebMS3 eb:PayloadInfo要素内の対応するeb:PartInfo要素の順序を制御できなければならない（MUST）。 複数のペイロードを持つメッセージを消費者(Consumer)に配信するMSHは、ebMS3 eb:PayloadInfo要素内の対応するeb:PartInfo要素の順序に関する情報を提供する必要がある。
eb:PartPropertiesのサポートが必要。 生産者(Producer)は送信されたペイロードパーツのプロパティと値を指定できなければならず、消費者(Consumer)は、配信されたペイロードパーツの指定されたプロパティと値を読み取れなければならない。