SECTION III: EMCS CENTRAL SERVICES ARCHITECTURE

SECTION III: EMCS CENTRAL SERVICES ARCHITECTURE ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 1 of 32

TABLE OF CONTENTS Table of Contents 1 Introduction... 3 1.1 Scope... 3 1.2 Document Structure... 3 2 Central Services Overview... 4 2.1 Introduction... 4 2.2 Communicating Parties... 4 2.3 Central Services Business Communication Channels [BCC]... 6 2.4 Central Services Infrastructure Communication Channels [ICC]... 8 2.5 EMCS Central Services System Architecture... 9 3 Central Services Architecture... 12 3.1 Introduction... 12 3.2 EMCS Central Service Bus... 13 3.3 Central Services Gateway... 17 3.4 EMCS/CO Web Portal... 21 3.5 Business Process Execution Engine... 22 3.6 Flow Control Engine... 22 3.7 Central Services Back-end Applications... 22 3.8 EUROPA/DDS EMCS Services... 29 3.9 COTS... 30 List of Figures FIGURE 1: SCOPE OF EMCS CENTRAL SERVICES... 3 FIGURE 2: COMMUNICATING PARTIES... 4 FIGURE 3: CENTRAL SERVICES BUSINESS COMMUNICATION CHANNELS... 6 FIGURE 4: BUSINESS COMMUNICATION CHANNEL CEA TO EUROPA/DDS [BCC14]... 7 FIGURE 5: BUSINESS COMMUNICATION CHANNEL ECOP TO EUROPA/DDS [BCC17].. 7 FIGURE 6: CENTRAL SERVICES INFRASTRUCTURE COMMUNICATION CHANNELS... 8 FIGURE 7: EMCS CENTRAL SERVICES SYSTEM ARCHITECTURE... 11 FIGURE 8: CENTRAL SERVICES ARCHITECTURE OVERVIEW... 13 FIGURE 9: CENTRAL SERVICES COMPONENTS INTEGRATION... 14 FIGURE 10: EMCS CENTRAL SERVICE BUS... 14 FIGURE 11: CENTRAL SERVICES GATEWAY... 17 FIGURE 12: CENTRAL SERVICES GATEWAY SYSTEM ARCHITECTURE... 17 FIGURE 13: CCN BRIDGE... 18 FIGURE 14: SECURE REVERSE PROXY (SRP)... 19 FIGURE 15: CENTRAL SERVICES PORTAL... 21 FIGURE 16: BUSINESS PROCESS EXECUTION ENGINE... 22 FIGURE 17: FLOW CONTROL ENGINE... 22 FIGURE 18: CENTRAL SERVICES BACK-END APPLICATIONS... 23 FIGURE 19: EXCISE TEST APPLICATION (ETA)... 27 FIGURE 20: CS/ETA COMMUNICATION CHANNELS... 28 ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 2 of 32

1 Introduction 1.1 Scope TESS Section III specifies the IT architecture of the EMCS Central Services (see Figure 1), as a part of the overall specification activities of the project. The IT architecture establishes the core architectural principles and design choices, and identifies the main subsystems that together form the EMCS Central Services. 1.2 Document Structure Figure 1: Scope of EMCS Central Services This document is structured as follows: Chapter 1... Introduction provides a description of the scope and structure of this Section. Chapter 2... Central Services Overview provides a summary of the offered services, the description of the involved communicating parties, and the description of the communication channels established between these parties to access the services offered by the Central Excise Applications (CEA). Chapter 3... Central Services Architecture provides a description of the various components (i.e. EMCS Central Service Bus, Central Services Gateway, EMCS/CO Web Portal, Business Process Execution Engine, Flow Control Engine, Central Services Back-end Applications, and EUROPA/DDS EMCS Services) that together form the Central Services Architecture. ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 3 of 32

2 Central Services Overview 2.1 Introduction The Central Excise Applications (CEA) provide application services, that are made centrally available (i.e. in the Common Domain) to MSA and Economic Operators. At MSA level, the interactions with the CEA are achieved through the CCN Network. At Economic Operators level, the interactions with the CEA are achieved through EUROPA via Internet. 2.2 Communicating Parties Figure 2 identifies all parties that make use of the EMCS Central Services. These parties may be either located in the National Domain, the External Domain or the Common Domain. Figure 2: Communicating Parties 2.2.1 SEED The System for Exchange of Excise Data (SEED) is located in the Common Domain. It provides management and dissemination services regarding information on the Economic Operators register. This is a vital part of the EMCS Central Services because the core business processes of EMCS depend on it. 2.2.2 EMCS CS/RD The EMCS Central Services/Reference Data (CS/RD) is located in the Common Domain. It provides management and dissemination services regarding common Reference Data. 2.2.3 CS/MIS The Central Services/Management Information System (CS/MIS) is located in the Common ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 4 of 32

Domain. It provides the facilities to assist the monitoring and the reporting on the operations of EMCS. This is performed by collecting, distributing and publishing EMCS business and technical statistics (including availability statistics) and by providing information on movements (ARC follow-up). 2.2.4 ETA The Excise Test Application (ETA) is located in the Common Domain. It is used for mode-2 testing (see ACS [R5] 3.1.2 NEA testing modes) against the NEA located in the premises of the MSA. 2.2.5 EMCS/CO Support Services The Central Operation (EMCS/CO) services are the services proposed by the Excise Computerization Project (ECP) to provide the Member State Administrations (MSA) with operational and technical support during EMCS implementation and operation. The role of the EMCS/CO consists also of the management of the applications providing the central services. The Central Operation Specifications (COS [R6]) describe the organisation and activities of the Central Operation Services. 2.2.6 NEA The National Excise Application (NEA) encompasses the systems that are located in the National Domain. It regularly maintains a relation with the Central Services in order to provide data generated at the National Administration level or to obtain data managed centrally. 2.2.7 MSA Users MSA Users (including Excise Liaison Officers (ELO), Excise officers, Excise verification officers, Control officers and Customs officers) use workstations located in the National Domain. They make use of the Central Services through the Common Domain communication infrastructure. 2.2.8 Economic Operators Economic Operators use workstations located in the External Domain. They make use of the Central Services through EUROPA (see 2.2.10 EUROPA/DDS) in order to obtain limited access to excise information relating to other operators. 2.2.9 NCTS CS/RD The NCTS CS/RD application offers the functionality of managing customs offices (maintenance, download, updates, etc.) and NCTS reference data. To support the EMCS CS/RD, the NCTS CS/RD application has to manage a common list of offices (custom and excise). Excise Offices are specified by defining an additional excise role. MSAs interact directly with NCTS CS/RD for all operations relating to creation, modification and deletion of offices. This is done independently from, and without impact or any interaction with the EMCS CS/RD application. 2.2.10 EUROPA/DDS EUROPA is the official web site for the European Union and hosts a diverse set of publications and services, intended for public users. EUROPA is used to offer a limited set of EMCS Central Services: ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 5 of 32

The validation of excise authorisations provided by SEED. Consultation and download of the Customs Offices List (COL) provided by NCTS CS/RD and including Excise Offices List (EOL). ARC Follow-up provided by CS/MIS. Download of E-Form Templates (see TESS Section IV Chapter 4 EMCS Start-up Kit). The EUROPA channel is made available to all public users. EUROPA does not require users to be authenticated. Confidential information will not be offered by EUROPA. Note: EUROPA, the European Commission web portal is accessible at http://europa.eu.int/. 2.3 Central Services Business Communication Channels [BCC] Figure 3 describes the EMCS Business Communication Channels (BCC) established between the various communicating parties. Only Business Communication Channels involved by the Central Services are considered hereafter. Figure 3: Central Services Business Communication Channels Those Business Communication Channels can be considered differently according to the involved domain: Common Domain. [BCC14] CEA to EUROPA/DDS ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 6 of 32

Figure 4: Business Communication Channel CEA to EUROPA/DDS [BCC14] This channel supports the information exchanges between CEA and EUROPA/DDS in order to provide a diverse set of publications and services, intended for public users. National Domain. NEA and MSA users use the communication channels provided by the EMCS Common Domain Architecture (see TESS Section II EMCS Common Domain Architecture), including: [BCC6]... NEA to SEED. [BCC7]... SEED to NEA. [BCC8]... MSA Users to EMCS/CO Support Services. [BCC9]... MSA Users to SEED. [BCC10]... EMCS CS/RD to NEA. [BCC11]... MSA Users to CS/RD. [BCC12]... NEA to CS/RD EMCS. [BCC13]... EMCS/CO Support Services to MSA Users. [BCC19]... NEA to CS/MIS. [BCC20]... CS/MIS to NEA. [BCC23]... MSA Users to CS/MIS. External Domain. [BCC17] Economic Operator to EUROPA/DDS Figure 5: Business Communication Channel EcOp to EUROPA/DDS [BCC17] This channel provides interactive exchanges between users in the External Domain (Economic Operators) and EUROPA. It requires high performance of response time since it tightly links user s interfaces and interactive applications. It addresses the use case UC1.30 (Consultation of registration information by economic operators). ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 7 of 32

2.4 Central Services Infrastructure Communication Channels [ICC] Figure 6 shows the Infrastructure Communication Channels [ICC], which are used to establish the business relationship between communicating parties consuming Central Services. Only Infrastructure Communication Channels interfacing with the Central Services are considered hereafter. Figure 6: Central Services Infrastructure Communication Channels ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 8 of 32

Infrastructure Communication Channels relaying on the Common Domain Infrastructure are depicted in TESS Section II and categorised as following: CCN/CSI Services.... [ICC1], [ICC4], [ICC5], [ICC15] and [ICC16]. Web Services and Web Interface.... [ICC2], [ICC6], [ICC11] and [ICC17]. Email-based Interface.... [ICC3], [ICC7], [ICC8], [ICC18] and [ICC19]. Additional Infrastructure Communication Channels are required to communicate with other parties: NCTS CS/RD using CCN/CSI Services... [ICC21] and [ICC22]. EUROPA/DDS using CCN/CSI Services... [ICC20]. EMCS/CO Workstations using Web Interface... [ICC14]. Economic Operator using EUROPA through the Internet.... [ICC26]. The various ICC are combined according to the addressed Central Services (see TESS Section II 6.3 EMCS Services Interfacing). Consequently, not all ICC need to be always implemented for each BCC. 2.5 EMCS Central Services System Architecture Figure 7 presents an overview of the system architecture showing the operational environment of the EMCS Central Services architecture. Communicating Parties (see 2.2 Communicating Parties) are mapped to hardware and software resources supporting the operation of the EMCS. In this section, particular attention is given to the environment and the architectural components in terms of the location, placing of applications and physical communication links providing accesses to the Central Excise Applications and Services. The main components addressed by the EMCS Central Services System Architecture and identified in Figure 7 are the following: The EMCS Central Services communicating parties, including: SEED (see 3.7.1 SEED) providing facilities for managing, storing, notifying, disseminating and consulting information on the Economic Operators register. EMCS CS/RD (see 3.7.2 Central Services/Reference Data (CS/RD)) providing management and dissemination services regarding common Reference Data. EMCS CS/MIS (see 3.7.3 Central Services/Management Information System (CS/MIS)) providing the facilities to assist the monitoring and the reporting on the operations of EMCS. ETA (see 3.7.4 Excise Test Application (ETA)) used for mode-2 testing (see ACS [R5] 3.1.2 NEA testing modes) against the NEA located in the premises of the MSA. Bridge CA/VA (see TESS Section II 3.6.3.2 Bridge CA/VA), a key component of the EMCS Common Domain PKI (CDPKI). EMCS/CO Web Portal (see 3.4 EMCS/CO Web Portal) providing the single and unified interface offering to users (including EMCS/CO Workstations) a secure access to various central sources of information and applications. ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 9 of 32

EUROPA and DDS (see 3.8 EUROPA/DDS EMCS Services), hosting a diverse set of publications and services, intended for public users and protected by a Firewall and Reverse Proxy. NCTS CS/RD, The Central Services Gateway (see 3.3 Central Services Gateway) is the single point of contact of the EMCS Central Services infrastructure. It encompasses: CCN Bridge (see 3.3.1 CCN Bridge) in charge of the asynchronous traffic regulation. Secure Reverse Proxy (SRP) (see 3.3.2 Secure Reverse Proxy (SRP)) in charge of the HTTP traffic regulation. EC Mail Transfer Agent (MTA) that routes the e-mail traffic to Internet or the LCMS. The Central Services Gateway regulates the messages exchanged with the Common Domain Infrastructure including: CCN Gateway offering both CCN/CSI Services (see TESS Section II 3.3 CCN/CSI Services) and CCN Intranet Services (see TESS Section II 3.4 CCN Intranet Services). Local CCN Mail System (LCMS) offering CCN Mail 2 services (see TESS Section II 3.5 CCN Mail 2 Services). The National Domain communicating parties (see TESS Section IV Standard Excise Application Architecture) including: National Excise Application (NEA), providing the EMCS services at the national level. It communicates with other NEA and the Central Services using the services offered by the NDCP. Excise Office and ELO Workstations, offering user interfaces for the interactions with the NEA, through the National Network, and the Central Services, through the NDCP. National Mail Transfer Agent (MTA) that routes the e-mail traffic to the LCMS. Those elements communicate through the Common Domain infrastructure using the NDCP (see TESS Section II 3.2.2 National Domain Connection Point (NDCP)) including the national CCN Gateway, the Local CCN Mail System (LCMS), the Security Devices, such as a firewall (F/W) and encryption device, and the Customer Premises Router (CPR), establishing the TCP/IP link to the CCN backbone. The External Domain communicating parties (see TESS Section IV Standard Excise Application Architecture) including: Economic Operator Workstation addressing the NEA as well as EUROPA through the Internet. Certification Authority (CA) and Principal CA participating to the PKI (see TESS Section II 3.6.4.Certificate Management). ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 10 of 32

Figure 7: EMCS Central Services System Architecture ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 11 of 32

3 Central Services Architecture 3.1 Introduction Figure 8 illustrates the Central Services Architecture. All those services are hosted in the Common Domain by the EC Data Centre, which provides a single access point through the Central Services Gateway (see 3.3 Central Services Gateway) regulating all communications between communicating parties (see 2.2 Communicating Parties) using the available infrastructure communication channels (see 2.4 Central Services Infrastructure Communication Channels [ICC]). ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 12 of 32

3.2 EMCS Central Service Bus 3.2.1 Introduction Figure 8: Central Services Architecture Overview The exchanges with external communicating parties are managed by the Central Services Gateway (see 3.3 Central Services Gateway). However the Central Services Gateway is not built to "directly" interact with all internal Central Services components. Therefore there is a need for an intermediate component, the EMCS Central Service Bus, that would allow integrating the Central Services Gateway and the internal Central Services components in a reliable, managed and scalable way. ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 13 of 32

Figure 9: Central Services Components Integration This is the goal of the EMCS Central Service Bus, which provides features (see 3.2.2 Features) that are used to ease the development and the deployment of EMCS central services. Part of processing (such as message validation, security, message transformation, intelligent messaging brokering, etc) is deported from applications to these services. This will ease the development of new applications (or Services) that will reuse generic services offered by the Service Bus through its valued-added services. 3.2.2 Features The Service Bus is a middleware solution that implements the backbone of a loosely coupled, event-driven SOA. Figure 10: EMCS Central Service Bus In this context, service components expose well-defined, atomic and message driven interfaces for sharing data between applications, in a highly distributed environment. Those data are exchanged through synchronous (request/reply) and asynchronous (send/receive) communication channels over standard communication protocols (e.g. SOAP, HTTP, HTTPS, JMS, SMTP, POP3, IMAP4 and FTP). The messaging backbone the bus is capable of scaling up to handle a very large number of applications and services and a very high volume of message traffic. The backbone is ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 14 of 32

compliant with the Java Message Service (JMS) specification and based on Message-Oriented Middleware (MOM). Such middleware is able to process synchronous, asynchronous as well as publish/subscribe communication patterns. Therefore, the scalability is easy to achieve because this distributed infrastructure is loosely coupled, hardware- and OS-independent. The Service Bus is designed (see 3.9 COTS) to connect and streamline applications, data and business systems across the network within a loosely coupled architecture. For that purpose, the Service Bus supports the development of composite applications that may involve new code built on top of existing applications such as legacy applications (e.g. NCTS CS/RD, SEED v0, etc.). In addition to the business services provided by the back-end applications (see 3.7 Central Services Back-end Applications), the service bus will integrate the following architectural components: EMCS/CO Web Portal (see 3.4 EMCS/CO Web Portal) that integrates the user interface and exposes services through a single point of access. Flow Control Engine (see 3.6 Flow Control Engine) that mainly manages the Coordination Protocol (see TESS Section II) with communicating parties (i.e. NEA) including preventive message queuing, sequencing and acknowledgment. It implements also other detection and prevention measures such as message validation at syntactic level and exception handling. Moreover, security requirements including confidentiality and integrity are also implemented at this level. Business Process Execution Engine (see 3.5 Business Process Execution Engine) that provides the Business Process Orchestration of the business process sequences, which is required to perform the exchange of messages with communicating parties. Moreover, the Service Bus presents the following characteristics: Security: The Security Server provides mechanisms to secure data exchange between consumers and producers of services such as: authorisation, authentication, and data encryption. Transformation: This service is embedded within the Service Bus to achieve message transformation. Its goal is to convert the message to one expected by the target system. This operation is not only linked to XML transformation (i.e. through XSLT) but also to other format (e.g. EDIFACT). Routing: This service determines the network destination of messages by converting logical destination to the specific Uniform Resource Identifier (URI). Directory Services: The directory serves as storage for service definitions accessible via UDDI, users data accessible via LDAP, schema, etc. Service Management: In addition to the Security Server, the Service Management s function is used to remotely monitor, configure and control the network activity of the Service Bus (e.g. security threat, availability of services, loading indication, auditing, etc). To achieve that, it supports instrumentation agents such as JMX, and provides logging, auditing and statistics capabilities. 3.2.3 CEA Integration Requirements In a Service-Oriented Architecture, the cornerstone is the standardisation of the interfaces in order to publish services in an unambiguous, common and predictable way. Therefore, the ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 15 of 32

EMCS Central Service Architecture proposes the following standards: Web Services. Web Services are defined using WSDL. WSDL is an XML format for the description of network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate. JMS. The Java Message Service (JMS) provides a standard Java-based interface to the message services of a MOM (Message Oriented Middleware). With JMS, both Publish- Subscribe Messaging and Point-To-Point are supported as well as Request-Reply Messaging. JMS defines the concept of a Topic or a Queue as the target for a Message. Topics are used for Publish-Subscribe Messaging. Queues are used for Point-to-Point Messaging. JMS provides also support for distributed transactions between Central Services components. Each Central Excise Application must expose its services through those standards, either directly or using adapters wrapping the internal service interface. ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 16 of 32

3.3 Central Services Gateway The Central Services Gateway is the single point of contact of the EMCS Central Services infrastructure. It is in charge of transforming the invocation protocols to the internal ones. This transformation is achieved through the services provided by: The CCN Bridge (see 3.3.1 CCN Bridge), which manages the asynchronous exchanges with Common Domain Relay (i.e. CSI, SMTP and POP3). The Secure Reverse Proxy (see 3.3.2 Secure Reverse Proxy (SRP)), which manages HTTP/S exchanges with the Common Domain Relay. Figure 11: Central Services Gateway Figure 12 depicts an overview of the system architecture that supports the Central Services Gateways. This shows how the components are mapped to hardware and software resources. Figure 12: Central Services Gateway System Architecture 3.3.1 CCN Bridge The CCN Bridge is a component of the Central Services Gateway in charge of the ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 17 of 32

asynchronous traffic regulation. It provides standard and homogeneous interface for the backend services, in particular the Flow Control Engine (see 3.6 Flow Control Engine), namely JMS (see 3.2.3 CEA Integration Requirements). Figure 13: CCN Bridge Typically, the asynchronous paradigm of CCN is accessible using the CSI Client Stack (see TESS Section II 2.5 CCN/CSI Services) that must be installed on the Application Platform. It offers high Quality of Service but unfortunately it has also the following disadvantages: It requires proprietary client stack supported on a limited set of platforms. It provides an interface (CSI) that is not standard (i.e. requiring developer s specific skills) and that does not allow a standard integration of the Common Domain infrastructure. It does not support transaction management (XA) that is generally useful on the application side to make CCN resources (i.e. CCN queues) participating in a transaction together with other resources (e.g. RDMBS). Even if CSI is considered as a de facto standard in the Common Domain, it is not an industry standard and it cannot be seen as such regarding applications integration. The Central Services Architecture is centred on the EMCS Central Service Bus (see 3.2 EMCS Central Service Bus). The bus provides message delivery services, based on standards (including JMS). Therefore, the interface for the CCN asynchronous paradigm should be JMS that provides a standard client API delimiting distributed transactions and offering the ability of a resource to participate in a distributed transaction. The CCN Bridge provides protocol transformations between CSI, used to communicate with external communicating parties (e.g. NEAs, NCTS CS/RD, DDS, etc.), and JMS, used to interact with the Central Services components. Moreover, CCN Mail 2 (see TESS Section II 3.5 CCN Mail 2 Services) is used for human-tomachine interactions or machine-to-machine interactions, typically as fallback solutions in the case where CCN/CSI (the recommended channel) is not available. In order to preserve the Central Services from this issue, the CCN Bridge provides protocol transformations between LCMS (SMTP, POP3 and IMAP4), part of the Common Domain Relay, and JMS, the standard Message Service used in the Central Services Architecture. Note: The COTS proposed for the Central Service Bus (see 3.9 COTS) supports the routing of email-based exchanges (POP/SMTP/IMAP). Therefore, the CCN Bridge should only regulate the CSI-based exchanges. ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 18 of 32

3.3.2 Secure Reverse Proxy (SRP) The Secure Reverse Proxy (SRP) is a component of the Central Services Gateway in charge of the HTTP traffic regulation. It provides the following features: Reverse Proxying The SRP proxies on behalf of the back-end HTTP server and not on behalf of the outside client s request (as a proxy would), hence the term reverse. It is an application proxy for servers using the HTTP protocol. It acts as a gateway to an HTTP server or HTTP server farm by acting as the final IP address for requests from the outside. A firewall should work tightly with the SRP to protect it from unwanted access from the external world and to ensure that only the SRP can access the HTTP servers located behind it. From the outside client s point of view, the SRP is the actual and only HTTP server. Instead of multiple machines directly handling the requests from clients, a single machine is responsible for accepting and redirecting the requests to the real servers. This means that a single domain continues to appear as a single machine, while still having the flexibility of multiple machines working behind the scenes to honour the actual requests. Security As security device, the SRP implements the authentication, authorisation and accounting measures necessary to fulfil the EMCS security requirements at the Central Services level regarding web-based interoperability. Figure 14: Secure Reverse Proxy (SRP) Consequently, it discharges the rest of the infrastructure from an important part of the security aspects establishing a so-called Implicit Trusted Zone. In this zone, the various services, in particular the EMCS/CO Web Portal (see 3.4 EMCS/CO Web Portal), can proceed securely by only dealing with functional requirements, keeping to the SRP the responsibility of the security. This solution provides an easy way to change or adapt the authentication mechanism (e.g. using X509-Certificate rather than login/password) without impacting the back-end services. Moreover, it hides eventually heterogeneous authentication mechanisms, possible mix of security measures according to the trust level of the partner s origin (e.g. Common Domain or Internet). ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 19 of 32

However, in order to be able to fulfil requested services, back-end applications need often to identify the requesting party. Therefore, the SRP inserts the identity deduced from the authentication mechanism (e.g. using cookie) in the request before forwarding it to the back-end server. Load Balancing In addition to the above considerations, the SRP can distribute the load to several servers, each server serving its own application area. Caching The reverse proxy can offload the back-end web servers by caching static content, such as images. Proxy caching of this sort can often satisfy a considerable amount of website requests, greatly reducing the load on the central web server. However, the implementation of the caching mechanism must not affect the security of the system. Note: The sequence of exchanges between the SRP and the HTTP Proxy (specifically with regards to the authentication phase) is described in the SESS [R9]. ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 20 of 32

3.4 EMCS/CO Web Portal The EMCS/CO Web Portal supports web-based User-to-Application interactions. It provides the single and unified interface offering to users a secure access to various central sources of information and applications (see 3.7 Central Services Back-end Applications). Figure 15: Central Services Portal While the Secure Reverse Proxy (see 3.3.2 Secure Reverse Proxy (SRP)), part of the Central Services Gateway, insures authentication and access authorisation aspects, the portal will deliver services according to the user s identity. This identity is forwarded by the SRP (e.g. in a cookie or in the HTTP header) and can be used by the portal to access ACL (Access Control List, e.g. located in a directory) that defines which services can be delivered to the identified user. According to the type of service requested by the user, the portal integrates the services exposed by: The Business Process Execution Engine (see 3.5 Business Process Execution Engine) when the request consists of a composite process involving several services, resources or partners. The Back-end Applications (see 3.7 Central Services Back-end Applications) when the request consists of a simple and atomic function (e.g. download Reference Data). When the Portal communicates with above mentioned services, it enriches the request by adding the user s identity. In this way, the executed process is able to adapt its behaviour according to this information. ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 21 of 32

3.5 Business Process Execution Engine The Business Process Engine is in charge of the Business Process Orchestration required to fulfil the various EMCS use cases at the Central Services level. Figure 16: Business Process Execution Engine The Business Process Execution Engine implements in particular long-running business processes. It maintains persistently the state of processes and manages all the events, which occur according to rules previously established. By deporting this activity from the applications to the Business Process Execution Engine, this offers flexibility in the composition and the evolution of the business processes at the functional stage (e.g. processing of submitted SEED updates requiring quick dissemination (UC1.14)). It allows the IT infrastructure to be business-driven. 3.6 Flow Control Engine The Flow Control Engine (see 3.9 COTS) is in charge of the Application Flow Control (see TESS Section II 5.4 Application Flow Control). It constitutes the interface between the Business Process Execution Engine, in charge of the Business Process Orchestration, and the Central Services Gateway (see 3.3 Central Services Gateway), in charge of the technical communication with the other communicating parties through the Common Domain. Figure 17: Flow Control Engine The Flow Control Engine controls asynchronous exchanges with communicating parties. Thanks to the CCN Bridge (see 3.3.1 CCN Bridge), incoming and outgoing messages are managed through JMS queues, abstracting the original protocols used to communicate with the relaying parties (e.g. CSI or SMTP). 3.7 Central Services Back-end Applications The Central Services Back-end Applications implement services which are integrated at the ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 22 of 32

Central Services Portal (see 3.4 EMCS/CO Web Portal) level, so as to provide web services or to participate to more complex business processes orchestrated by the Business Process Execution Engine (see 3.5 Business Process Execution Engine). Figure 18: Central Services Back-end Applications These services must be designed in such a way that they can be easily integrated to the Service-oriented Architecture. Consequently, they should be designed as Web Services or Message-beans (JMS) in order to be directly addressed by the EMCS Service Bus (see 3.2 EMCS Central Service Bus) using standards connectors such as: J2EE Connector Architecture, SOAP, JMS, etc. Example: WebLogic Tuxedo Connector (WTC) provides such capabilities, allowing the integration of BEA Tuxedo services with new and existing J2EE solutions. This simplifies Web Services generation, Web page flow application development, and portal and integration projects. 3.7.1 SEED SEED services provide facilities for managing, storing, notifying, disseminating and consulting information on the Economic Operators register. The role of this application is to provide a scalable and efficient platform to facilitate the exchange of SEED information between MSA. In this respect, SEED focuses on offering stable persistence mechanisms and a robust communications model for exchanging information between users. In all cases, MSAs remain the owners and maintainers of any business data stored by SEED the SEED application is the mechanism for storing and propagating consolidated information between interested parties. SEEDv0 already provides functionality for the central management of SEED. SEEDv0 will be reused in order to maintain the current communication channels (see TESS Section II 6.3.2 SEED Services). Consequently, the integration of the new SEED application (SEEDv1), as well as the required migration, will be easier. Moreover, SEEDv0 implements Web Services (SOAP), making it ready for an easy integration in the Central Services Architecture. According to the FESS [R4], the core services of SEED can be summarised to: Collecting. SEED information must be submitted by national administrations via their NEA as soon as changes have an impact at international level. The following kind of technical interactions between NEA and SEED can be identified: ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 23 of 32

Asynchronous Interaction using CCN/CSI Services. Fallback Asynchronous Interaction using CCN Mail 2. Web Services (synchronous or asynchronous) and Web Interfaces accessible through the CCN Intranet and published by the EMCS/CO Web Portal. Consolidating and Maintaining. Central Services are responsible for the consolidation and the maintenance of the SEED. Information is maintained in a central repository, which must be replicated to all MSAs in order to satisfy EMCS Business Processes at the national level. Notifying. When the central repository is updated, MSAs should be notified, as well as users having subscribed to this service. Users should be able to subscribe to this service through the portal in order to receive e-mails each time the accessible information is updated. Disseminating. This process consists of the replication of the SEED maintained centrally to the NEA in the national administrations. The following kind of technical interactions between SEED and NEA can be identified: Asynchronous Interaction using CCN/CSI Services via the CCN Bridge (see 3.3.1 CCN Bridge). Fallback Asynchronous Interaction using CCN Mail 2. Synchronous Interaction with the SEED Web Services and Web Interfaces accessible through the CCN Intranet and published by the EMCS/CO Web Portal. This can occur after notification. Publishing. In addition to the publishing of SEED and Reference Data in the Central Services Portal, information is regularly submitted to the DDS in order to make it accessible by the Economic Operators through the EUROPA web site (see 3.8 EUROPA/DDS EMCS Services). SEED is a vital part of the EMCS Central Services because it supports the management of information required at strategic steps of the EMCS core business processes (e.g. validation of a draft e-ad submitted by the Consignor). Moreover, as this information can change frequently and consequently, the accurate and prompt dissemination of SEED updates is very important. Therefore, the various services described above will be orchestrated in order to provide SEED with an automated and eventdriven dissemination process. This process can be implemented with the Business Process Execution Engine (see 3.5 Business Process Execution Engine) and takes into account the following requirements: Each time a NEA submits SEED updates using any provided channel, the process is activated. According to the use case UC1.14 (Dissemination of SEED data, see FESS [R4] Section III 3.2 CCN Network) and the urgency of the dissemination of such updates, as soon as the submitted data is validated and integrated to the central repository, it is dispatched to all NEAs. The data dissemination is automatically performed using CCN/CSI services, and alternatively CCN Mail 2 as fallback solution (see TESS Section II 6.3.2 SEED Services). ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 24 of 32

3.7.2 Central Services/Reference Data (CS/RD) The Reference Data Management Central Services provide information relating to: Excise Offices already maintained by NCTS CS/RD. Reference Data including the Excise products categories and codes, and the part of the lists of codes that has to be used during the exchanges (see FESS [R4] Appendix B List of Codes). SEEDv0 already provides management of such information. SEEDv0 will be reused in order to maintain the current communication channels (see TESS Section II 6.3.3 CS/RD Services). Consequently, the integration of the new CS/RD application, as well as the required migration, will be easier. Moreover, SEEDv0 implements Web Services (SOAP), making it ready for an easy integration in the Central Services Architecture. However, EMCS CS/RD and SEEDv1 will be distinct applications using the same underlying technology. Moreover, the data model of SEEDv0 must be extended in order to integrate all information required for EMCS CS/RD. The decision to integrate Excise Office information into NCTS CS/RD provides numerous advantages: Coherent and single domain model. Most Excise Offices serve a dual-purpose as customs offices. It is more logically coherent to offer a single list of offices, instead of requiring users to connect to two disparate systems and merge the lists themselves. Unique data definition. Office information is defined once and in a single place (NCTS CS/RD). Any changes are made available immediately and there is no need for multiple updates of redundant information (with the associated risk of errors). Re-use of code and existing investment. NCTS CS/RD provides all of the functionality that is required for Excise Office management and so direct re-use allows a more costeffective and efficient development. Minimal impact to MSAs. MSAs use NCTS CS/RD and exchange NCTS CS/RD messages regularly. By building on NCTS CS/RD to provide Excise Office support, this reduces the impact of any changes on National Administrations. MSAs can continue to use NCTS CS/RD messages as before. In addition, EMCS CS/RD offers SOAP API. Clients wishing to use the programmatic access to CS/RD require a full API with access to Excise Offices. NCTS CS/RD does not offer any SOAP services and so all Web Services are implemented in their entirety by the EMCS CS/RD. The EMCS CS/RD application maintains a read-only replication of the Excise Offices List, to avoid repeatedly accessing data in CS/RD over the network each time. Users cannot modify NCTS data via the EMCS CS/RD channels. This complete decoupling of both applications provides advantages in terms of availability and performance requirements. EMCS CS/RD and NCTS CS/RD communicate using the CCN/CSI Services, and consequently the CCN Bridge (see 3.3.1 CCN Bridge). The communication re-uses existing XML formatted NCTS messages. The process to be established between both parties can be implemented with the Business Process Execution Engine (see 3.5 Business Process Execution Engine), providing mediation between services, including message transformations. ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 25 of 32

3.7.3 Central Services/Management Information System (CS/MIS) The Central Services / Management Information System (CS/MIS) is a system in the Common Domain, which provides facilities needed to monitor and report on the operation of the EMCS at business, application and infrastructure levels: EMCS Monitoring. The Functional Excise System Specification (see FESS [R4] Section V: UC0.07) describes the way the EMCS Monitoring must be managed. It consists of messages exchanged between communicating parties (NEA and CS/MIS) transporting alerts or notifications about scheduled or unscheduled unavailability of EMCS components. EMCS Statistics. The Functional Excise System Specification (see FESS [R4] Section III: UC3.16) describes the way the EMCS Statistics must be managed. It consists of messages exchanged between communicating parties (NEA and CS/MIS) transporting information about operational, application and business statistics. ARC follow-up. It is a utility offered through CS/MIS and used to monitor the current status of a consignment based on its ARC. The CS/MIS receives the ARC as input and produces the relevant consignment data as output. EMCS CS/MIS reuse the existing NCTS CS/MIS that is functionally very similar. However, the data model must be adapted in order to integrate specific EMCS requirements regarding, statistics and unavailability data. CS/MIS is based upon 3-tier software architecture: The client tier is based upon a standard Web browser. The application tier is implemented by means of Java Servlets supported by a Web Server. The data storage tier is implemented as a RDBMS. NCTS CS/MIS is mainly a web-based application providing interface to upload or encode, and browse or download information concerning statistics and availabilities. Moreover, specific Import Agents are responsible for retrieving information from CCN/TC (i.e. CCN/CSI audit files and technical statistics) posted in CCN queues. EMCS CS/MIS provides additional communication channels (see TESS Section II 6.3.4 CS/MIS Services): CCN/CSI Services providing reliable asynchronous exchange while CCN Mail 2 offers a fallback solution in case of unavailability of the nominal channels. Those asynchronous interactions are supported by the CCN Bridge (see 3.3.1 CCN Bridge) transforming them in JMS at the Central Services side. Web Services, similar to SEED, providing synchronous and asynchronous interactions. EMCS CS/MIS will provide Web Services by wrapping one or more existing J2EE components. The wrapper acts as a bridge between the SOAP world and the CORBA world. Service consumers send SOAP requests to the wrapper, and the wrapper translates them into CORBA requests to the EJB components. ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 26 of 32

Note: The BEA WebLogic Adapter for CORBA facilitates the integration of existing CORBA services with WebLogic Integration to enable existing IT investments to be integrated into J2EE applications and deployed as Web services. The adapter allows the CORBA-based applications to communicate with the other applications and resources. 3.7.4 Excise Test Application (ETA) The ETA is deployed in the EMCS/CO premises and is integrated in the Central Services architecture (chapter 3 Central Services Architecture). It is used for mode-2 testing against the NEA located in the MSA premises (see the EMCS ACS Acceptance and Certification Specification [R5]). It supports testing of EMCS components and services by driving exchanges of EMCS messages with National Excise Applications (NEA). Note: ETA re-uses the Transit Test Application (TTA, see [R23] Detailed Design for TTA for NCTS) architecture (NCTS Project), which is extended to support the new requirements of EMCS. Figure 19: Excise Test Application (ETA) The testers in the National Domain monitor the execution of ETA using a Remote Console ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 27 of 32

accessible through the CCN, under the assumption that he/she has remote login (telnet, secure telnet or an Xterm window) access to the ETA host machine. The ETA Remote Console allows the following actions without intervention of an operator at the EMCS/CO: Start/stop test sessions (ETA scenario executions). View the results of the test scenarios. The ETA Administrator at the EMCS/CO is responsible for the following: Supervising the execution of test sessions. Viewing the test execution log files to verify the test results. Resolving configuration or other problems encountered during the test sessions. Performing remote user management. Upgrading the reference data set and/or the test scenarios. The ETA addresses only the Common Domain Information Exchanges. Consequently, it deals only with the Infrastructure Communication Channels interfacing the Common Domain (see Figure 20). Figure 20: CS/ETA Communication Channels However, together with the SETA (see TESS Section IV Chapter 5 Standard Excise Test Application (SETA)), it is possible to test complete Business Scenario, including External Domain Exchanges. Moreover, because SETA implements a Web-based Remote Console (see TESS Section IV 5.3 Web-based Remote Control), EMCS/CO operators can execute test scenarios without intervention of an operator at the MSA premises. During testing, the NEA interacts with the ETA through the various Common Domain communication channels interfacing the Common Domain Relay in Test Mode. Note: The Common Domain Relay is able to manage both production and test traffics. While ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 28 of 32

the CCN Backup Gateway should be only used for business continuity purposes, the CCN Production Gateway should be used for testing activities thanks to its Multimode capability (see TESS Section II, Chapter 3 EMCS Common Domain Infrastructure). 3.8 EUROPA/DDS EMCS Services The decision to provide EMCS services via EUROPA was taken primarily for the following reasons: Robust and stable platform. EUROPA is designed to support large numbers of users and provide a reasonable response time. This is a key requirement for the large numbers of economic operators that can potentially use this service. Functional coverage. EUROPA is widely used and offers many of the features required by these limited SEED services (multi-language support and easy-to-use interface). Minimal client requirements. The platform does not impose any client requirements. All services can be accessed using a standard web browser. The decision to implement EUROPA access on the DDS application provides numerous advantages: Re-use of code and existing investment. DDS provides the functionality that is required for publication of information of Excise information on the EUROPA portal: CCN access, robustness and security; Coherent domain model. The whole Excise domain (Economic Operators, Excise Offices and Reference Data) is published on EUROPA by the same application and cross references are possible; Coherent architecture. The DDS application is the reference architecture to disseminate DG TAXUD information on EUROPA. The integration of the EUROPA Web site with EMCS provides the following services available in the External Domain through the Internet: The validation of excise authorisations. The validation of excise authorisations is implemented using the same DDS architecture for publishing data on EUROPA. This requires the DDS application to receive and store the Economic Operators information from SEED and to provide a Web interface for the validation of excise authorisations. Note: The validation services offered via EUROPA are publicly available, even though they are intended primarily for Economic Operators. As such, the type of information made available via this channel is reduced to avoid misuse. The validation is restricted to specific criteria and only returns a confirmation. If the system confirms the validity of the excise authorisation, then the system will provide the list of excise products for which the target economic operator is authorised. ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 29 of 32

Consultation and download of the Customs Offices List (COL). The decision to integrate the Excise Offices List (EOL) and the Customs Offices List (COL) into a single list has the advantage of providing Excise Offices with a single interface for the consultation and download. ARC Follow-up. This service is made available by publishing information (CCN Audit) gathered and consolidated by CS/MIS. The integration of EUROPA Web site with EMCS requires from the Central Excise Applications (CEA) to produce and send data using CCN/CSI Services. The interaction between EMCS Central Services and EUROPA is asynchronously performed using CSI through the CCN Bridge (see 3.3.1 CCN Bridge). The process to be established between both parties can be implemented with the Business Process Execution Engine (see 3.5 Business Process Execution Engine), providing integration of EUROPA in the various processes disseminating data in the Common Domain. 3.9 COTS BEA AquaLogic Service Bus (ALSB) is a configuration-based, policy-driven Enterprise Service Bus, based on WebLogic Server 9, with message brokering and web service management (WSM) features. It supports Xquery-based routing, many transports including filesystem, FTP, HTTP/S, JMS (including Websphere MQ and JMS/XA), and Email (POP/SMTP/IMAP), many messaging approaches including REST-style XML, WSDLdefined SOAP/XML, plain text or binary, dispatching based on header, XSD type, WSaddressing, transport header, or dynamically based on the message shape. ALSB supports synchronous, asynchronous and pub/sub message exchange patterns, full XQuery-based transformation of XML, text, and/or binary data, WS-security authentication, encryption, and signatures, logging, monitoring, and SLA enforcement. Note: Detailed information about BEA AquaLogic Service Bus is available on the BEA Web Site. BEA AquaLogic Service Bus should be associated with: BEA WebLogic Integration providing in particular: Business Process Management, providing tools for the implementation of the Business Process Orchestration. BEA WebLogic adapters to connect existing applications (e.g. CS/MIS) and databases. Message Broker allowing the routing of messages between the various central services components. Data Transformation. Native Web Services. Transactional Process Engine. ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 30 of 32

Access to portal framework through interoperability with BEA WebLogic Portal. Web-based integration management console. Data Archiving. BEA WebLogic Portal providing in particular: Federated Portals publishing and subscribing to portlets, offering tools for the implementation of the EMCS/CO Web Portal. Unified security model, providing the EMCS Central Services Security Server. BEA WebLogic single sign-on. Web integration for reuse and modification of existing Web content and applications. Portal Lifecycle Management. Content Management. Collaboration facilities including collaborative desktops, discussion forums, whiteboard, chat, etc. Test and control delivery. ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 31 of 32

End of TESS Section III ECP1-ESS-TESS-03-SECTION-III-EMCS-CENTRAL-SERVICES-ARCHITECTURE-v3.02.doc Page 32 of 32