Skip to end of metadata
Go to start of metadata

Objective

The e-SENS Message Exchange Protocol Architectural Building Block provides secure and reliable exchange of single or groups of payloads in any structured or unstructured format.  It is designed to support both the e-Delivery and e-Interaction SATs and supports both One Way and Two Way (Request-Response) exchanges.The ABB can be used in four-corner topologies or in point-to-point exchanges. In four-corner topologies, only the interconnect hop (corner 2 to 3) is in scope as the edge hops may use other message protocols. The ABB can be specified as a profile of open standards message protocols.  The e-SENS ABB Specification is based on a profile of the ebMS3 and AS4 OASIS Standards, which allows the ABB to be implemented using open source or closed source commercial software products compliant with these standards.


Version1.7

Interoperability

Level

Generic Requirements

The requirements for the Message Exchange Protocol ABB were first identified in D6.1, based on input from CC6.1 experts, experience from previous LSPs, and initial input from WP5 domains.

For D6.2 and D6.3, the updated WP5 domain pilot plans have been reviewed and the following list of requirements is found to be still valid.

Requirement
ID

Requirement description

Source

R-MesExc-B1

Messaging must be secure, reliable, and asynchronous and must support non-repudiation.

R5.1-UC1-1, R5.1-UC1-41,

R5.1-UC1-42,

R5.1-UC1-43,

R5.1-UC4-5,

R5.2-UC2-10,

R5.2-UC2-11,

R5.2-UC2-12,

R5.3-UC1-2,

R5.3-UC4-2,

R5.4-UC1-16,

R5.4-UC2-16

R-MesExc-B2

Payload must be unified, size-scalable, in structured and unstructured format.

R5.1-UC1-1,

R5.4-UC1-16,

R5.4-UC2-16

R-MesExc-B3

The system must support originator and recipient Authentication.

 

R-MesExc-T1

Secure Messaging

R5.1-UC1-1,

R5.2-UC2-12,

R5.3-UC1-2,

R5.3-UC4-2,

R5.4-UC1-17,

R5.4-UC1-21,

R5.4-UC2-17,

R5.4-UC2-21

R-MesExc-T2

Reliable Messaging: once-and-only-once guaranteed delivery (retries, receipts, duplicate elimination)

R5.1-UC1-41,

R5.1-UC1-42,

R5.2-UC2-10,

R5.4-UC1-16,

R5.4-UC1-20,

R5.4-UC2-16

R-MesExc-T3

Support for non-repudiation of origin and receipt (gateway to gateway)

R5.1-UC1-41,

R5.4-UC1-20

R-MesExc-T4

Support for asynchronous store-and-forward messaging

R5.1-UC1-41,

R5.1-UC4-5,

R5.2-UC2-10,

R5.3-UC1-2,

R5.3-UC4-2,

R5.4-UC1-16,

R5.4-UC2-16

R-MesExc-T5

Support for monitoring and routing based on business message metadata (identifiers, correlation, business process information and/or other)

R5.1-UC1-1,

R5.1-UC1-42,

R5.4-UC1-16,

R5.4-UC2-16

R-MesExc-T6

Support for business documents and attachments in a single message

R5.1-UC1-44

R-MesExc-T7

Support for large messages (where the definition of "large" is domain-dependent, but may be up to a few GB)

R5.1-UC1-44,

R5.1-UC4-6

R-MesExc-T8

Support for structured and unstructured payload.

R5.1-UC1-1,

R5.4-UC1-16,

R5.4-UC2-16

R-MesExc-T9

Ability to authenticate sending and receiving gateway.

 

R-MesExc-T10

Ability to authenticate the original sender.

 

 

 

Supported Features

FeaturePurposeOutcome
Transport Message Processing

Sender agent (Corner 2 or Corner 3), generates the Transport Message by using received document container and document header.

Receiving agent (Corner 2 or Corner 3), extracts the document container and document header from received Transport Message

In sender side: Transport Message is created in compliance with the Message Exchange ABB Specification.

In receiver side: Document Container and document header are extracted from Transport Message.

Message Sending

Sender agent sends the generated Transport Message to the receiving agent through a secure, reliable and asynchronous message channel of which standard complies with Message Exchange ABB specification

Transport Message is sent from the sender agent to the receiving agent.
Message ReceivingReceiving agent receives the Transport Message by using pre-determined exchange pattern mechanisms such as push, pull and sync.Receiving agent receives the Transport Message.
Transport Message SecurityTransport Message security must be supported between sender and receiving agents by using the message layer and transport layer standards specified by Message Exchange ABB specification.Transport Message which is sent from sender agent to the receiver agent, is encrypted and then decrypted.
Non-Repudiation of Origin

Non-Repudiation of Origin (NRO) protects against the originator's false denial of having originated the message. Evidence Of Origin (EOO) is generated by the originator or a TTP on its behalf, and will be held by the recipient.

The receiver has indisputable evidence that the sender has originated the message.
Non-Repudiation of ReceiptNon-Repudiation of Receipt (NRR) is intended to protect against the recipient's false denial of having received the message. The recipient, or a TTP on its behalf generates Evidence Of Receipt EOR), and the originator will hold itThe sender has indisputable evidence that the receiver has received the message.

 

 

Application View


Figure 1. Service realization view for Message Exchange ABB.


Information View


Figure 2. Hierarchical information structure view for a Transport Message.



Figure 3. Information structure view for a Transport Message instance.

Although there are two alternatives of a transport message, "without SBDH" and "with SBDH", the SBDH business and application objects have been explicitly depicted in the above diagrams in order to be more general.

 

ABB Capability Realization

ABB SpecificationChoice CriteriaSustainability Assessment
PR - AS4

Decision Log - Message Exchange

Completed

 

 

Contributors

Name

Surname

Organisation

Country

Iva

Milutinovic

Ministry of Justice, North Rhine Westphalia

Germany

Carmen

Rotuna

ICI – National Institute for Research and Development in Informatics

Romania

Melis Ozgur

Cetinkaya Demir

Tubitak

Turkey

Muhammet

Yildiz

Tubitak

Turkey

Pim

Van der Eijk

Ministry of Justice, North Rhine Westphalia

Germany

 

 

History

Version

Date

Changes made

Modified By

0.1

30.04.2014

First draft derived from ENTSOG profile

Iva Milutinovic

0.2

11.05.2014

Enhancements for SBDH

Carmen Rotuna,

Pim van der Eijk

0.3

13.05.2014

First draft for review in CC6.1

Carmen Rotuna,

Pim van der Eijk

0.31

19.06.2014

Review comments by Martin Forsberg processed

Carmen Rotuna

0.4

21.07.2014

  • Adapted to ABB template;
  • transport separated from addressing
  • review comments from IT.NRW
  • new example message
  • editorial fixes
  • added a (fairly complete and representative) example
  • optional trackingIdentifier property

Pim van der Eijk

0.5

22.07.2014

  • ArchiMate diagrams added

Iva Milutinovic

Muhammet Yildiz

Melis Ozgur Cetinkaya Demir

0.6

23.07.2014

  • Link to CIPA and to the vendor list
  • Minor editorial updates

Pim van der Eijk

0.7

24.07.2014

  • Tubitak authors added

Pim van der Eijk

0.8

11.09.2014

  • Some WP6 internal review comments processed; This includes a name change of the ABB 
    Secure and Reliable Transport of Documents and Data“ to „Message Exchange Protocol“.

Pim van der Eijk

1.011.02.2015D6.2 comments processed.

Iva Milutinovic and Pim van der Eijk

1.113.03.2015ArchiMate diagrams updated WRT D6.2 Comments

Melis Ozgur Cetinkaya Demir

Muhammet YILDIZ

1.225.03.2015Structured according to the eSENS BB Descriptions.Melis Ozgur Cetinkaya Demir
1.330.03.2015Generated the contents of the sections "Provided Services", "Related ABBs" and "ABB Capability Realization".Melis Ozgur Cetinkaya Demir
1.403.04.2015Application View and Information View ArchiMate updated.Melis Ozgur Cetinkaya Demir
1.508.04.2015

Editorial:

  • Fixed link to decision log.
  • Bumped version
  • Updated description to be more technology-neutral.
  • Removed status as per email KVP
  • Removed sustainability assessment, as that applies to the ABB Specification.

Pim van der Eijk
1.622.04.2015

The Message Exchange requirements are matched to the domain specific requirements of

  • WP5.1
  • WP5.2
  • WP5.3
  • WP5.4

Editorial:

  • Fixed link to related ABBs and ABB Capabiltiy realization
  • Bumped version
Melis Ozgur Cetinkaya Demir
1.727.12.2016Describe the features required by the capability, and more specifically NRO and NRR

Pim van der Eijk

Eric Grandry

  • No labels