Software Architecture Document - · PDF fileDocument Approver(s) and Reviewer(s): ......

Commission européenne, B-1049 Bruxelles / Europese Commissie, B-1049 Brussel - Belgium. Telephone: (32-2) 299 11 11. Office: 05/45. Telephone: direct line (32-2) 2999659. Commission européenne, L-2920 Luxembourg. Telephone: (352) 43 01-1.

Software Architecture Document

CIPA e-Delivery

Date: 23/02/2015 Doc. Version: 1.0

CIPA e-Delivery Architecture Overview

RUP@EC Template V.5.0 Date: 23/02/2015 Version: 1.0 2 / 18

Document Control Information

Settings Value

Document Title: Architecture Overview

Project Title: CIPA e-Delivery

Document Author: Bram De Schouwer, Gaëtan Vernaeve

Project Owner: Tanya Chetcuti

Project Manager: Matthieu Gaeremynck

Doc. Version: 1.0

Sensitivity: <Limited DG>

Date: 23/02/2015

Document Approver(s) and Reviewer(s):

NOTE: All Approvers are required. Records of each approver must be maintained. All

Reviewers in the list are considered required unless explicitly listed as Optional.

Name Role Action Date

<Approve / Review>

Document history:

The Document Author is authorized to make the following types of changes to the document

without requiring that the document be re-approved:

Editorial, formatting, and spelling

Clarification

To request a change to this document, contact the Document Author or Owner.

Changes to this document are summarized in the following table in reverse chronological order

(latest version first).

Revision Date Created by Short Description of Changes

0.6 02/02/2015 Bram De Schouwer First draft

1.0 23/02/2015 Bram De Schouwer For final validation

Configuration Management: Document Location

The latest version of this controlled document is stored in <location>.


Date: 23/02/2015 Version: 1.0 3 / 18

TABLE OF CONTENTS

1 INTRODUCTION ................................................................................................................................... 4

1.1 Purpose ............................................................................................................................................. 4

1.2 Scope ................................................................................................................................................ 4

1.3 Intended Audience ........................................................................................................................... 4

1.4 Overview of the document ............................................................................................................... 4

2 INFORMATION SYSTEM DESCRIPTION ................................................................................................. 5

2.1 Introduction ...................................................................................................................................... 5

2.2 CIPA e-Delivery Access Point ............................................................................................................ 5

2.3 Service Metadata Publisher .............................................................................................................. 5

2.4 Service Metadata Locator ................................................................................................................. 5

3 ARCHITECTURE OVERVIEW.................................................................................................................. 6

3.1 Architectural Goals ........................................................................................................................... 6

3.2 Archimate Notation .......................................................................................................................... 6

3.3 Building Blocks .................................................................................................................................. 7

3.4 Message Flows .................................................................................................................................. 7

3.4.1 Main Scenario ............................................................................................................................ 7

3.4.2 Configuration Scenarios ............................................................................................................. 9

3.5 Logical View .................................................................................................................................... 10

3.6 Implementation View ..................................................................................................................... 16


Date: 23/02/2015 Version: 1.0 4 / 18

1 INTRODUCTION

1.1 Purpose

The purpose of this document is to document and provide a point of reference for the current software architecture of CIPA e-Delivery Software. This document will be used as the baseline for documenting future changes to the CIPA e-Delivery architecture.

1.2 Scope

In scope of this document are all the components and modules of the current CIPA e-Delivery infrastructure, as developed by DIGIT B4 and shared on the CIPA e-Delivery Joinup space1.

1.3 Intended Audience

This document is intended for readers with a technical background and an interest in the architecture of CIPA e-Delivery. Before reading this document, it is recommended to read the Vision document of CIPA e-Delivery.

1.4 Overview of the document

This document is organised according to the template provided by the Rational Unified Process for the European Commission. It starts with generic information about CIPA e-Delivery in Chapter 2 and provides an overview of the architecture of CIPA e-Delivery in Chapter 3.

1 https://joinup.ec.europa.eu/software/cipaedelivery/

https://joinup.ec.europa.eu/software/cipaedelivery/


Date: 23/02/2015 Version: 1.0 5 / 18

2 INFORMATION SYSTEM DESCRIPTION

2.1 Introduction

The CIPA e-Delivery information system consists of three large functional building blocks:

The CIPA e-Delivery access point;

The Service Metadata Publisher;

The Service Metadata Locator.

This chapter will briefly introduce the high-level functionality of each of the building blocks. Detailed information about each of these is available in the CIPA e-Delivery Vision Document.

2.2 CIPA e-Delivery Access Point

The CIPA e-Delivery access point is responsible for ensuring secure information exchange to another party. Therefore, this access point offers a back-end interface which allows communication with legacy systems. Different protocols for inter-access point communication are supported to facilitate information exchange in different environments.

The CIPA e-Delivery access point also integrates with the SMP and SML components to retrieve metadata about other access points.

2.3 Service Metadata Publisher

The Service Metadata Publisher stores and exposes information about CIPA e-Delivery participants. This metadata allows, amongst others, the identification of an access point, and the supported document types and protocols. More specifically, the following information is stored:

The URL of the CIPA e-Delivery Access Point

The certificate of the CIPA e-Delivery Access Point

The Participant ID

The supported document type

The supported protocols for each document type

2.4 Service Metadata Locator

The Service Metadata Locator (SML) is a central instance in the CIPA e-Delivery infrastructure and should be considered to be the directory of directories. The SML component maintains links between participants and their respective SMPs. This component is based on the Domain Name System (DNS) and is responsible for updating the DNS so a DNS call always returns the correct SMP for a given Participant.


Date: 23/02/2015 Version: 1.0 6 / 18

3 ARCHITECTURE OVERVIEW

3.1 Architectural Goals

The objective of CIPA is to provide a generic solution for public administrations to exchange documents in a secure, reliable and trusted way.

This means that the architectural goals of the CIPA e-Delivery platform are the following:

CIPA e-Delivery must provide a content-agnostic platform that supports the exchange of electronic documents regardless of the document type or the specific sector in which the platform is used.

CIPA e-Delivery must ensure that confidentiality of documents is preserved during transmission and that effective security measures are in place to prevent any unintended parties or malicious users to access the exchanged documents.

CIPA e-Delivery must ensure that documents are delivered to the intended recipients.

CIPA e-Delivery must ensure that a trust model is in place among all the participants, which allows exchange of documents only between trusted parties.

3.2 Archimate Notation

The architecture views in the subsequent sections, are described using the Archimate 22 notation. In the table below, we describe the meaning of the building blocks and relationships used throughout the architecture diagrams included this document.

Building Block Description

A business actor is defined as an organizational entity that is capable of performing behaviour.

Application Component

An application component is defined as a modular, deployable, and replaceable part of a software system that encapsulates its behaviour and data and exposes these through a set of interfaces.

Application Service

An application service is defined as a service that exposes automated behaviour.

An application interface is defined as a point of access where an application service is made available to a user or another application component.

The realization relationship links a logical entity with a more concrete entity that realizes it.

The used by relationship models the use of services by processes, functions, or interactions and the access to interfaces by roles, components, or collaborations.

2 http://pubs.opengroup.org/architecture/archimate2-doc/

Business Actor

Application Interface

Realization

Used By


Date: 23/02/2015 Version: 1.0 7 / 18


The assignment relationship links units of behaviour with active elements (e.g., roles, components) that perform them, or roles with actors that fulfil them.

3.3 Building Blocks

In order to achieve the goals defined in section 3.1, CIPA e-Delivery aims at creating a document exchange network. Participants can access this network through gateways, which communicate with each other using standard protocols. CIPA e-Delivery provides three main components, described in the table below.


CIPA e-Delivery Access Point

The CIPA e-Delivery Access Points (AP) are gateways through which messages are exchanged between participants. All participants joining the CIPA e-Delivery network are connected to (at least one) AP using standard or custom protocols. APs communicate with each other using standard protocols. Trust is established between Access Points by means of a closed KPI infrastructure.

Service Metadata Publisher

The Service Metadata Publishers (SMPs) contain information related to the participants. This includes the endpoint of the participant (i.e. the URL of the Access Point to which the participant is connected), the supported services (i.e. document types that can be exchanged with that participant) and the supported protocols. Each SMP contains information about a set of participants.

Service Metadata Locator

The Service Metadata Locator (SML) is the only central component of the CIPA e-Delivery platform. It is used by APs to discover, through a DNS-based mechanism, the specific SMP that contains the information related to a specific participant. Links between the participant IDs and SMPs are maintained in the SML. The SML provides services to add/update/delete participant IDs and to update the links between participant IDs and SMPs.

Back Office

Back Office building blocks are integrated within the existing environment of a service provider or consumer. Back Office building blocks communicate with the CIPA e-Delivery Access Points to initiate message exchange or receive messages which were sent by other participants. Back Office building blocks will integrate with one of the services exposed by the CIPA e-Delivery Access Point. Since the CIPA e-Delivery building blocks are context agnostic, the content of the messages will be defined and interpreted at the level of the Back Office.

3.4 Message Flows

3.4.1 Main Scenario

In this section, the main scenario of the CIPA e-Delivery infrastructure is described. This scenario covers the use of the CIPA e-Delivery components to exchange messages between two participants at run-time. For completeness, a back-office component has been included to show the interaction with the existing environments of participants.

Assignment


Date: 23/02/2015 Version: 1.0 8 / 18

The CIPA e-Delivery components provide a set of services and functionalities to allow message exchange between two participants. This scenario is mainly deriving from the architecture of the PEPPOL Transport Infrastructure. However, additional services have been added to the CIPA e-Delivery Infrastructure, to allow the use of different protocols and enhance interoperability with existing European and national systems.

The sequence diagram below shows the different steps to send and receive messages.

Backoffice (A) Access Point (A) Access Point (B)SMP Backoffice (B)

1. send(message)

4. getReceiverMetadata()

3. lookupSMPAddress()

5. dispatch(message)

Acknowledgement

7. listPendingMessages()

8. downloadMessage(messageId)

6. storeMessage()

2. validate(message)

ALT

[IF PROTOCOL = �AS4 ]

Figure 1 Sequence Diagram

The following list describes the different steps depicted in the previous picture.

1. A back-office node (A) sends a message by invoking a web service on the access point’s send servlet.

2. The access point validates the message SBDH headers and processes the request. To retrieve the metadata of the recipient, such as the IP address or the type of communication protocol to use (e.g. AS2 or AS4), three options are provided:

a. The metadata of the recipient of the message is already present in the local cache. The scenario continues from step 5.

b. At this point, the metadata of the recipient needs to be fetched from an SMP server. If the SMP server is unknown, the scenario continues from step 3 (SMP address is fetched from DNS server). Otherwise, the scenario continues from step 4 (Direct SMP, the address of the SMP server is provided in the message).


Date: 23/02/2015 Version: 1.0 9 / 18

c. No SMP is used and the direct address to endpoint is provided. The scenario continues from step 5.

3. Depending on the configuration of the Access Point, the SMP address will be available in the message or should be obtained from the DNS server.

4. Once the SMP address is known, a request is made to the SMP server to retrieve the recipient’s metadata.

5. Based on the recipient’s metadata, the transport protocol is selected, AS2 or AS4:

a. If the AS2 transport protocol is selected the message is forwarded to the Mendelson gateway, which will send the message in line with the AS2 specifications. Upon receipt of a message, the receiving access point verifies the headers to ensure that the received message is a valid AS2 package. Afterwards the certificate is checked against the root certificate of the network PKI to make sure that the certifier and the sender are the same participants. If all checks passed, the message is forwarded to the Mendelson gateway and is stored on the local filesystem. If needed, missing partners are dynamically created in Mendelson.

b. If the AS4 transport protocol is selected, the message is forwarded to the Domibus gateway, which will send the message in line with the AS4 specifications. Upon receipt of a message, the receiving access point verifies the headers to ensure that the received message is a valid AS4 package. Afterwards the certificate is checked against the root certificate of the network PKI to make sure that the certifier and the sender are the same participants. If all checks passed, the message is forwarded to the to the Domibus gateway which will also store the message on the local filesystem. If needed, missing partners are dynamically created in Domibus.

Acknowledgements are sent by the respective AS4 & AS2 gateways, Domibus for AS4 and Mendelson for AS2.

c.

6. If the received message passed all checks described in step 6, it is stored on the file system of the receiving access point and a record is created in the local database.

7. To retrieve AS4 messages, backoffice nodes regularly invoke the “List Messages” web service of the access point. This service will return the list of available message ids. There is no web service available for AS2 messages which are stored on the local file system.

8. Based the received list of AS4 message ids, the backoffice node invokes the access point’s downloadMessage() web service to retrieve the full AS4 message. When an AS4 message has been downloaded, it is automatically removed from the access point

3.4.2 Configuration Scenarios

The CIPA e-Delivery infrastructure implements several configuration scenarios, which allow the management of the information contained in the different components:

Service Metadata and Service Group management: the SMP allows authorised users to manage (add/remove) the metadata of a participant (Service Metadata and Service Group) inside the SMP.

Participant Identifier management: the SML allows authorised users to manage (add/remove/update) participant identifiers of the CIPA network. Every participant identifier needs to be added to the SML and linked to the related SMP that contains its metadata. Adding a participant identifier (and its link to the corresponding SMP) to the SML triggers the creation of a new DNS entry for that participant. This allows Access


Date: 23/02/2015 Version: 1.0 10 / 18

Points to discover the SMP containing the metadata of that participant via a DNS lookup.

Migration: a further use case, implemented by SML, is the migration of the metadata of one participant identifier to from an SMP to another. As the migration needs to be reflected in the SML (and in the DNS), the SML offers services to the SMPs to securely initiate and finalise the migration.

3.5 Logical View

This section describes the logical view of the components of CIPA e-Delivery. It shows the main sub-components of every component and the interfaces between them. A complete overview of the CIPA e-Delivery access point, SMP and SML can be found in the picture below. Note that this picture only shows information flows in one direction from the sender (left) to the recipient (right). The same information flows exist from the right to the left but have been left out of the picture to avoid confusion.


Date: 23/02/2015 Version: 1.0 11 / 18


Date: 23/02/2015 Version: 1.0 12 / 18

Legend

Domibus Gateway Components

Back-office Components

SMP Components

Dispatcher Components

Mendelson Gateway Components

DNS Server Components


Date: 23/02/2015 Version: 1.0 13 / 18

The table below explains the purpose and behaviour of the components in the diagram.

Component Description

The back-office (BO) Sender is a component integrated in the existing environment of the party which initiates the information exchange between two CIPA e-Delivery access points. The BO sender is responsible for sending messages to a service provider: the CIPA e-Delivery access point Send Servlet. Messages sent from the BO Sender to the Sent Servlet are sent using the Standard Business Document Header (SBDH) protocol.

This Send Servlet component receives an SBDH request (as a REST call) from the BO. Firstly, this component performs local caching operations to verify if that recipient is present (known) or not. If not, three scenarios can occur:

The URL of the SMP is known, so the SMP can be directly contacted to get its metadata

The address of the SMP is retrieved through the DNS by using the DNS Caller component

No SMP is used, this situation is only for testing purposes

Based on the endpoint metadata, the transport protocol (AS2 or AS4) is deduced and the appropriate interface is called:

The Domibus Interface for AS4

The AS2 Endpoint Send Interface for AS2

Before accessing the AS4 Domibus Interface, an additional step is performed for adding a PMode (Process Mode parameter) for establishing the connection to the recipient. A similar step can be performed for AS2 if a message is being sent to a new partner. In this case, this new partner is created in the Mendelson gateway.

This component is used to access the DNS infrastructure and retrieve the URL of an SMP.

The DNS Server manages (contact) information regarding the different SMP instances of the different parties involved in the e-Delivery environment and their domain mapping.


Date: 23/02/2015 Version: 1.0 14 / 18


The SMP server component of a party involved in e-Delivery is responsible for storing and publishing metadata regarding identification of that party. The SMP server also provides information regarding the supported document types and protocols.

The SML component is responsible for keeping the DNS records of the e-Delivery participants up to date. The SML is not directly involved in the process of information exchange but required for ensuring that the different SMPs are accessible.

The Domibus Interface component is responsible for encapsulating requests received via the Send Servlet in a new BackendMessage. The interface submits these messages In a queue to be picked up by the Domibus server, which is responsible for message delivery to another AS4 party The Domibus Interface also provides back-office facing operations to list and retrieve messages received by the Domibus server. For this purpose, the following operations are available:

ListPendingMessages: Returns a list of all available messages on the local Domibus server, each of them with a MessageID

DownloadMessage: Returns the message with the requested MessageID. When the message is taken from the server, it is deleted.

The Domibus gateway has two main functionalities:

Message delivery: The Domibus gateway is responsible for delivering messages to another AS4 compliant party. This party is not necessarily another CIPA e-Delivery access point but can also be a third party which is AS4 compliant.

Message receipt: Incoming messages from other AS4 parties which were received by the AS4 Receiver Servlet are delivered to the Domibus Server. The Domibus Server stores these and makes them available for listing and retrieval through the Domibus Interface.

The AS2 Endpoint Send Interface prepares an AS2 message for sending through the Mendelson Server. To start, the metadata of the message destination (another AS2 party) is verified in the Mendelson DB:

If the record doesn’t exist yet, the party record is


Date: 23/02/2015 Version: 1.0 15 / 18


added based on the provided metadata;

If the record exists but is different, the party record is updated based on the provided metadata.

If the record exists and is the same, no action is taken

After this validation, the pending message is stored in the local file storage component of the Mendelson Server.

The Mendelson gateway component has two key functions:

Message delivery: Message received through the AS2 Endpoint Send Interface are read from the file system and delivered to the specified AS2 party. This party is not necessarily another CIPA e-Delivery access point but can also be a third party which is AS2 compliant.

Message receipt: Upon receipt of a message from the AS2 Receiver Servlet, the Mendelson gateway will process the request. The current implementation does not foresee a specific interface for listing and retrieving received messages from the Mendelson gateway. These messages are therefore stored on the local file system.

The Mendelson gateway contains two main subcomponents:

The Mendelson DB which stores information about other AS2 parties and the status of messages.

The local file storage component for storing AS2 messages.

The Session Callback Handler component is responsible for capturing and storing the status of an AS2 message delivery (success or error).

The Dispatcher component is responsible for receiving both AS4 and AS2 messages. Its main sub-components are the AS2 Receiver Servlet and the AS4 Receiver Servlet.

The AS2 Receiver Servlet receives messages from other AS2 parties. First of all the headers are validated to ensure they are correct and the message is indeed an AS2 message. Next, the certificate of the sending party is validated. If the sender is not known yet by the local Mendelson gateway, the party is added to the Mendelson DB. Finally, the message is transferred to the


Date: 23/02/2015 Version: 1.0 16 / 18


Menselson gateway.

Comparable to the AS2 Receiver Servlet, the AS4 Receiver Servlet receives a POST request from the sending AS4 party. First of all the certificate of the sending is validated. A PMode (Process Mode parameter) is created for receiving the message and for sending back the receipt after which the message is forwarded to the Domibus gatewayof the receiving CIPA e-Delivery Access Point. This is done by setting up an SSL connection to the Domibus gateway

A back-office (BO) consumer component is able to consume messages received through AS4. For AS4, the following operations are available for retrieving messages:

ListPendingMessages: Returns a list of all available messages on the local Domibus gateway, each of them with a MessageID

DownloadMessage: Returns the message with the requested MessageID. After downloading the message from the server, it is automatically deleted.

Note: No AS2 interface is currently foreseen. Messages are recovered via the file system (directly from local Mendelson gatewayfile storage)

3.6 Implementation View

The following figure provides the implementation view of the eDelivery access point.


Date: 23/02/2015 Version: 1.0 17 / 18

Figure 2 Implementation View

The following table provides an explanation of the building blocks illustrated in the previous picture.


eDelivery Core The eDelivery core is a java-based implementation which includes a message dispatcher for AS2 and AS4 messages as well as a send servlet for back office nodes and a DNS caller.

Mendelson Gateway

Java-based implementation of the AS2 protocol. This component is used to send and receive AS2 messages. There is no interface for back office nodes to retrieve received messages. Messages are stored on the file system.

Domibus Gateway

Java-based implementation of the AS4 procotocol. Domibus is a fork from the open-source implementation of AS4, Holodeck. It is based on the Apache AXIS2 core engine for web service calls. This component is used to send and receive messages. It also includes a web service interface for the back-office node to retrieve messages, through a pull mechanism (listMessages and downloadMessage service operations).

Back-Office Node This component represents the back-office node. It communicates with the eDelivery access point through web services to send and receive messages.


Date: 23/02/2015 Version: 1.0 18 / 18

SMP

The SMP component is a Java based implementation of a directory of participants which stores the following participant’s metadata:

URL of the AP

Participant ID

Document Type

Protocol

It contains the exact location and the capabilities of participants.

SML

The SML server is java-based implementation used to add/update/delete IDs of participants, and offers a DNS-based mechanism to discover the SMP where the specific participant data is described.

Software Architecture Document - · PDF fileDocument Approver(s) and Reviewer(s): ......

Documents

Transcript of Software Architecture Document - · PDF fileDocument Approver(s) and Reviewer(s): ......