DE4A Connector it2

The DE4A Connector is a technical proxy that allows the final participants (DE or DO) to send requests for evidence or responses to other final participants over an eDelivery communication environment. In addition, to handle the message exchange process, the Connector is responsible for obtaining the message routing information, by exchanging information with external components such as the IDK, the SML/DNS or the SMP.

To do so, it provides a common interface to DEs and DOs, making the complexity of the system transparent to the final participants and integration easier.

The Connector component provides the AS4 Gateway functionality, so it can assume both the role of Data Requestor and Data Transferor. This first approach makes the Connector a stand-alone web application that can be deployed on any suitable application server.

The security and integrity of messages, as well as the unique identification of the participants involved, are the cornerstones of the Connector component.

Follow the link to the Installation and configuration guide of the DE4a Connector.

Conceptual schema of the target DE4A system

Functionalities provided

The main purpose of the DE4A Connector is sending and receiving of evidence requests and their responses. The message exchange process is described in the DE4A deliverables D2.4 Project Start Architecture and D5.3 Initial technical design of interfaces.

Routing information lookup

The Connector is responsible for obtaining the Data Provider information from the IDK. It exposes a REST API /lookupRoutingInformation to get information about the Data Owners that provide a specific Canonical Evidence Type and further related information. That information is used to construct a request message to be sent through the Connector. Thus, the Data Evaluator is the only consumer of the mentioned API method.

Dynamic discovery of Services

In order for the Connector to be able to send a message to the corresponding endpoint, the eDelivery dynamic discovery mode of operation is used. This operation mode is based on the use of the SML/DNS and SMP components of the eDelivery infrastructure. The main elements stored in the SML/DNS and SMPs for this purpose are the following:

• ParticipantIdentifier: The Data Owner/Data Evaluator identifier who is publishing its AS4 communication point (of the Connector linked to it).
• DocumentTypeIdentifier: Canonical evidence type.
• ProcessIdentifier: Orchestration type (request/response).
• AS4 endpoint: AS4 service endpoint URL.
• Certificate: The X.509 certificate of the AS4 server, used to encrypt the transmitted data for this specific participant.

The information described above is managed by the SML/DNS and SMP components and is used by the Connector when working with the phase4 implementation of AS4.

Focusing on the SML/DNS/SMP data retrieval, the process will take place according to the following features:

• SSL/TLS communication is mandatory.
• Response signature validation is mandatory.
• The communication between SMP and SML requires the usage of a client certificate.

The service metadata lookup will be performed as a step prior to the AS4 message exchange. Therefore, the participant IDs and other related information must be known by the Connector in advance.

Supported interaction patterns

Interaction patterns define the flow of data through the Connector and the intercommunication between the different components. Each pattern exchanges certain types of messages, and the incoming/outgoing information will depend on the processes occurring in the external components [3].

The Connector currently supports three interaction patterns:

• Intermediation (IM) pattern
  • ­Synchronous communication between the Connector and final participant (DE or DO).
  • Data Owner endpoint must be known by the Data Transferor.
  • Since the communication is synchronous, the Data Requestor does not need to know the identifier and endpoint of the Data Evaluator.

• User supported intermediation (USI) pattern
  • Asynchronous communication between the Connector and final participant (DE or DO).
  • Data Owner endpoint must be known by the Data Transferor.
  • Since the communication is asynchronous, the Data Evaluator endpoint must be known by the Data Requestor. In addition, the Data Evaluator identifier is recovered from the request, since it is not sent in the response from the Data Transferor.

Most of the specific behaviour of each interaction pattern is independent of the Connector itself, as the Connector component is just designed to exchange messages and the main differences between the patterns take place in the external components such as the Data Evaluator and the Data Owner.

Additionally, the it2 connector offers a backwards compatibility feature for the IM pattern of it1. It can handle old messaging structure so implementation for it1 will be fully compatible with the it2 connector.