SECTION II: EMCS COMMON DOMAIN ARCHITECTURE

Transcription

1 SECTION II: EMCS COMMON DOMAIN ARCHITECTURE ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 1 of 91

2 TABLE OF CONTENTS Table of Contents 1 Introduction Scope Document Structure EMCS Common Domain Architectural Elements Introduction Architectural Levels Communicating Parties NEA MSA Users Central Services Business Communication Channels [BCC] NEA to NEA [BCC2] NEA to SEED [BCC6] NEA to CS/RD [BCC12] NEA to CS/MIS [BCC19] SEED to NEA [BCC7] CS/RD to NEA [BCC10] CS/MIS to NEA [BCC20] MSA Users to SEED [BCC9] MSA Users to CS/RD [BCC11] MSA Users to CS/MIS [BCC23] MSA Users to EMCS/CO Support Services [BCC8] EMCS/CO Support Services to MSA Users [BCC13] MSA Users to MSA Users [BCC21] Infrastructure Communication Channels [ICC] CCN/CSI Services Web Services Web Interface based Interface System Architecture EMCS Common Domain Infrastructure Introduction CCN Network Overview ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 2 of 91

3 TABLE OF CONTENTS National Domain Connection Point (NDCP) Common Domain Relay Equipment Redundancy Monitoring CCN/CSI Services Intended Usage Description CSI-based Application Modes of Usage (Testing Activity) Service Level Agreement Availability Transaction Volumes - Response Time Services for the Operation and Management of CCN/CSI Quality of Service (QoS) QoS Attribute Infrastructure Protocol Security CCN Intranet Services Intended Usage Description Quality of Services (QoS) Security CCN Mail 2 Services Intended Usage Description Quality of Services (QoS) Security Public Key Infrastructure (PKI) EMCS Service Access Point Overview Introduction EMCS Common Domain Service Bus EMCS Messages EMCS-XML Message Format EMCS Message Structure Infrastructure Level Application Level (EDA) ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 3 of 91

4 TABLE OF CONTENTS Application Level (Web Service) Business Level Multilingualism Character Set Searching Issue Embedding binary data EMCS Common Domain Interface Specifications Introduction EMCS Business Interaction Paradigms [BIP] Business Process Orchestration Introduction Business Orchestration vs. Business Choreography Message Definition at Business Level Application Flow Control Introduction Message Validation Coordination Protocol Preventive Message Queuing Message Sequencing State Machine Infrastructure Message Acknowledgment Implementation Monitoring Security Message Definition at Application Level Message Routing Exception Handling Logging EMCS Common Domain Adapter Specifications Introduction EMCS Common Domain Adapter Architecture Business Process Execution Engine Flow Control Engine Exception Handler Common Domain Relay EMCS Services Interfacing Core Business Services SEED Services ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 4 of 91

5 TABLE OF CONTENTS CS/RD Services CS/MIS Services Central Support Services EMCS Business Continuity Specifications Introduction Problem Statement EMCS System Resilience CCN Redundancy Options Backup Gateway at Local Site Central Backup Site Other Equipment Redundancy ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 5 of 91

6 LIST OF FIGURES List of Figures FIGURE 1: SCOPE OF EMCS COMMON DOMAIN ARCHITECTURE... 9 FIGURE 2: EMCS ARCHITECTURE LEVELS FIGURE 3: COMMUNICATING PARTIES FIGURE 4: EMCS BUSINESS COMMUNICATION CHANNELS FIGURE 5: BUSINESS COMMUNICATION CHANNEL NEA TO NEA [BCC2] FIGURE 6: BUSINESS COMMUNICATION CHANNEL NEA TO SEED [BCC6] FIGURE 7: BUSINESS COMMUNICATION CHANNEL NEA TO CS/RD AND SEED [BCC12] FIGURE 8: BUSINESS COMMUNICATION CHANNEL NEA TO CS/MIS [BCC19] FIGURE 9: BUSINESS COMMUNICATION CHANNEL SEED TO NEA [BCC7] FIGURE 10: BUSINESS COMMUNICATION CHANNEL CS/RD TO NEA [BCC10] FIGURE 11: BUSINESS COMMUNICATION CHANNEL CS/MIS TO NEA [BCC20] FIGURE 12: BUSINESS COMMUNICATION CHANNEL MSA USERS TO SEED [BCC9] FIGURE 13: BUSINESS COMMUNICATION CHANNEL MSA USERS TO CS/RD [BCC11] FIGURE 14: BUSINESS COMMUNICATION CHANNEL MSA USERS TO CS/MIS [BCC23] FIGURE 15: BUSINESS COMMUNICATION CHANNEL MSA USERS TO EMCS/CO SUPPORT SERVICES [BCC8] FIGURE 16: BUSINESS COMMUNICATION CHANNEL EMCS/CO SUPPORT SERVICES TO MSA USERS [BCC13] FIGURE 17: BUSINESS COMMUNICATION CHANNEL MSA USERS TO MSA USERS [BCC21] FIGURE 18: EMCS INFRASTRUCTURE COMMUNICATION CHANNELS FIGURE 19: EMCS INFRASTRUCTURE COMMUNICATION CHANNELS (CSI) FIGURE 20: EMCS INFRASTRUCTURE COMMUNICATION CHANNELS (WEB SERVICES) FIGURE 21: EMCS INFRASTRUCTURE COMMUNICATION CHANNELS (WEB INTERFACE) FIGURE 22: EMCS INFRASTRUCTURE COMMUNICATION CHANNELS ( -BASED INTERFACE) FIGURE 23: NATIONAL DOMAIN CONNECTION POINT (NDCP) SYSTEM ARCHITECTURE FIGURE 24: SYSTEM ARCHITECTURE FIGURE 25: CCN NETWORK OVERVIEW FIGURE 26: NATIONAL DOMAIN CONNECTION POINT (NDCP) FIGURE 27: CCN INFRASTRUCTURE PROTOCOL: COA, COD FOR SUCCESSFUL TRANSFER FIGURE 28: CCN INFRASTRUCTURE PROTOCOL: EXCEPTION REPORT FIGURE 29: CCN NETWORK INFRASTRUCTURE CCN/CSI SERVICES FIGURE 30: CCN NETWORK INFRASTRUCTURE CCN INTRANET SERVICES FIGURE 31: CCN NETWORK INFRASTRUCTURE CCN MAIL 2 SERVICES FIGURE 32: EMCS COMMON DOMAIN SERVICE BUS FIGURE 33: EMCS MESSAGE STRUCTURE (EDA) FIGURE 34: EMCS MESSAGE STRUCTURE (WEB SERVICE) FIGURE 35: EMCS COMMON DOMAIN SERVICE BUS INTERFACE FIGURE 36: BUSINESS ORCHESTRATION VS. BUSINESS CHOREOGRAPHY FIGURE 37: COMMON DOMAIN SERVICE BUS INTERFACE AT BUSINESS LEVEL FIGURE 38: MESSAGE DEFINITION AT BUSINESS LEVEL FIGURE 39: COMMON DOMAIN SERVICE BUS INTERFACE AT APPLICATION LEVEL FIGURE 40: COORDINATION PROTOCOL - STATE MACHINE: PROCESS INSTANTIATION FIGURE 41: BUSINESS PROCESS CHOREOGRAPHY: STATE-TRANSITION DIAGRAM OF E-AD AT DISPATCH FIGURE 42: BUSINESS PROCESS CHOREOGRAPHY: STATE-TRANSITION DIAGRAM OF E-AD AT DESTINATION FIGURE 43: MESSAGE DEFINITION AT APPLICATION LEVEL FIGURE 44: COMMON DOMAIN SERVICE BUS INTERFACE AT INFRASTRUCTURE LEVEL ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 6 of 91

7 LIST OF FIGURES FIGURE 45: EXCEPTION HANDLING FIGURE 46: EMCS COMMON DOMAIN SERVICE BUS ADAPTER FIGURE 47: EMCS COMMON DOMAIN SERVICE BUS ADAPTER ARCHITECTURE FIGURE 48: CORE BUSINESS SERVICES (BCC) FIGURE 49: CCN/CSI SERVICES: ONE-WAY BUSINESS INTERACTION (NEANEA) FIGURE 50: -BASED INTERFACE: ONE-WAY BUSINESS INTERACTION (NEA NEA) FIGURE 51: CCN/CSI SERVICES: TWO-WAY BUSINESS INTERACTION (NEANEA) FIGURE 52: -BASED INTERFACE: TWO-WAY BUSINESS INTERACTION (NEA NEA) FIGURE 53: CS/RD AND CS/RD SERVICES (BCC) FIGURE 54: CCN/CSI SERVICES: ONE-WAY BUSINESS INTERACTION (SEED NEA) FIGURE 55: -BASED INTERFACE: ONE-WAY BUSINESS INTERACTION (SEED NEA) FIGURE 56: CCN/CSI SERVICES: TWO-WAY BUSINESS INTERACTION (NEA SEED) FIGURE 57: WEB SERVICES: SYNCHRONOUS TWO-WAY BUSINESS INTERACTION (NEA SEED).. 80 FIGURE 58: WEB SERVICES: ASYNCHRONOUS TWO-WAY BUSINESS INTERACTION (NEA SEED) 80 FIGURE 59: -BASED INTERFACE: ASYNCHRONOUS TWO-WAY BUSINESS INTERACTION (NEA SEED) FIGURE 60: WEB INTERFACE: HUMAN INTERACTION (NEA SEED) FIGURE 61: CS/RD SERVICES (BCC) FIGURE 62: CCN/CSI SERVICES: ONE-WAY BUSINESS INTERACTION (CS/RD NEA) FIGURE 63: -BASED INTERFACE: ONE-WAY BUSINESS INTERACTION (CS/RD NEA) FIGURE 64: CCN/CSI SERVICES: TWO-WAY BUSINESS INTERACTION (NEA CS/RD) FIGURE 65: WEB SERVICES: SYNCHRONOUS TWO-WAY BUSINESS INTERACTION (NEA CS/RD). 83 FIGURE 66: WEB SERVICES: ASYNCHRONOUS TWO-WAY BUSINESS INTERACTION (NEA CS/RD)83 FIGURE 67: -BASED INTERFACE: ASYNCHRONOUS TWO-WAY BUSINESS INTERACTION (NEA CS/RD) FIGURE 68: WEB INTERFACE: HUMAN INTERACTION (NEA CS/RD) FIGURE 69: CS/MIS SERVICES (BCC) FIGURE 70: CCN/CSI SERVICES: ONE-WAY BUSINESS INTERACTION (NEA CS/MIS) FIGURE 71: CCN/CSI SERVICES: ONE-WAY BUSINESS INTERACTION (CS/MIS NEA) FIGURE 72: -BASED INTERFACE: TWO-WAY BUSINESS INTERACTION (NEA CS/MIS) FIGURE 73: -BASED INTERFACE: TWO-WAY BUSINESS INTERACTION (CS/MIS NEA) FIGURE 74: WEB SERVICES: SYNCHRONOUS TWO-WAY BUSINESS INTERACTION (NEA CS/MIS) 85 FIGURE 75: WEB SERVICES: ASYNCHRONOUS TWO-WAY BUSINESS INTERACTION (NEA CS/MIS)85 FIGURE 76: WEB INTERFACE: HUMAN INTERACTION (NEA CS/MIS) FIGURE 77: CENTRAL SUPPORT SERVICES (BCC) FIGURE 78: WEB INTERFACE: HUMAN INTERACTION (MSA USER EMCS/CO CENTRAL SERVICES)86 FIGURE 79: -BASED INTERFACE: HUMAN INTERACTION (EMCS/CO CENTRAL SERVICES MSA USER) ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 7 of 91

8 LIST OF TABLES List of Tables TABLE 1: EMCS INFRASTRUCTURE COMMUNICATION CHANNELS (CSI) TABLE 2: EMCS INFRASTRUCTURE COMMUNICATION CHANNELS (WEB SERVICES) TABLE 3: EMCS INFRASTRUCTURE COMMUNICATION CHANNELS (WEB INTERFACE) TABLE 4: EMCS INFRASTRUCTURE COMMUNICATION CHANNELS ( -BASED INTERFACE) TABLE 5: QOS ATTRIBUTE AND SUB-FIELDS TABLE 6: MESSAGE HEADER AT BUSINESS LEVEL TABLE 7: MESSAGE HEADER AT APPLICATION LEVEL TABLE 8: EMCS AVAILABILITY REQUIREMENTS VS. CCN COMMITTED SERVICE LEVEL ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 8 of 91

9 1 Introduction 1.1 Scope The TESS Section II specifies the Common Domain architecture of the EMCS (see Figure 1), a part of the overall specifications activities of the project. The IT architecture establishes the core architectural principles and design choices, and identifies the main subsystems that together represent the EMCS Common Domain services. 1.2 Document Structure This document is structured as follows: Figure 1: Scope of EMCS Common Domain Architecture Chapter 1... Introduction, provides a description of the scope and the structure of this Section. Chapter 2... EMCS Common Domain Architectural Elements, describes the EMCS Architectural Levels (derived from the IT urbanisation principles), the Communicating Parties, the Business Communication Channels, the Infrastructure Communication Channels, and the EMCS System Architecture. Chapter 3... EMCS Common Domain Infrastructure, describes the Common Domain infrastructure and related services including the CCN Network, the CCN/CSI services, the CCN Intranet services and the CCN Mail 2 services. Chapter 4... EMCS Service Access Point Overview, introduces the concept of EMCS Common Domain Service Bus, describes the high-level structure of EMCS messages, and presents the EMCS Common Domain Service Bus Interface and the EMCS Common Domain Service Bus Adapter concepts. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 9 of 91

10 Chapter 5... EMCS Common Domain Interface Specifications, provides the specifications of the Common Domain Interface at the Business, Application, and Infrastructure levels. Chapter 6... EMCS Common Domain Adapter Specifications, provides the specifications of the Common Domain Adapter by introducing the Business Process Execution Engine, Flow Control Engine and Common Domain Relay. Chapter 7... EMCS Business Continuity Specifications, provides an overview of the elements that should be addressed by the EMCS Business Continuity Plan and presents the possible options to be considered to offer the required equipment redundancy. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 10 of 91

11 2 EMCS Common Domain Architectural Elements 2.1 Introduction This Chapter aims at specifying architectural elements that are referred to by the subsequent Chapters, and more specifically the description of Architectural Levels (see 2.2 Architectural Levels), the Communicating Parties (see 2.3 Communicating Parties), and the Business Communication Channels (see 2.4 Business Communication Channels [BCC]) involving Common Domain exchanges. 2.2 Architectural Levels According to the principle of IT Urbanisation depicted in TESS Section I, Chapter 4, it makes sense to consider the EMCS Common Domain Architecture specifications at three different levels: business, application, and infrastructure (see Figure 2). Figure 2: EMCS Architecture Levels The Business Level deals mainly with the Functional Excise System Specifications (FESS [R4]), which describes all the business processes that EMCS must support. This level describes the services expected from the EMCS, independently from the underlying communication infrastructure. At this level, the communicating parties (see 2.3 Communicating Parties) use Business Communication Channels (see 2.4 Business Communication Channels [BCC]) where the technical aspects of the information exchanges (reliability, confidentiality, integrity, etc.) are not yet considered. Moreover, logging of business exceptions and their resolutions must be done in a consistent fashion according to the Fallback and Recovery Specification (FRS [R7]). This is essential to ensure business compliance. At this level, general purpose services are configured to deal with specific business exceptions. Defining dedicated services for the resolutions of exceptions should improve the productivity of the business by separating ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 11 of 91

12 this activity from the nominal process and in some cases (see FRS 5.2 Automatic resolution of e-ad state conflict) by reducing the number of errors that have to be resolved by human intervention. The Application Level establishes and documents how the Business Communication Channels are implemented and addressed by applicative components ensuring the reliability of the exchanges. Whereas the business level must be independent from the service offered by the infrastructure (see Quality of Service (QoS)), the application level must take care of various technical aspects such as exchange coordination, technical exception handling and security. This level is the main focus of this document. The Infrastructure Level implements the various Infrastructure Communication Channels (see 2.5 Infrastructure Communication Channels [ICC]) that are required to make the exchanges possible. It mainly concerns the enabling equipment, its location (see 2.6 System Architecture) and the software modules that support the business/application processes described before. This Section addresses only the part of the EMCS that operates using the Common Domain Infrastructure (see Chapter 3 EMCS Common Domain Infrastructure) and more particularly the Common Communications Network (CCN, see 3.2 CCN Network) and its Value Added Services (including CCN/CSI, CCN Intranet and CCN Mail 2) which are already deployed in all MSAs. 2.3 Communicating Parties Figure 3 identifies all parties that make use of Common Domain communication services. These parties may be either located in the Common Domain and/or in the National Domain NEA Figure 3: Communicating Parties National Excise Applications (NEA) encompasses the EMCS services that are located in the National Domain. These applications use the Common Domain communication services to exchange information with remote applications according to the EMCS business processes. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 12 of 91

13 2.3.2 MSA Users MSA Users (including Excise Liaison Office (ELO), Excise officer, Excise verification officer, Control officer and Customs officer) use workstations located in the National Domain. They use the Common Domain communication services to access central services or to communicate with other MSA users using e.g. the CCN Mail 2 channel to exchange e- mails Central Services Central Services are composed of Central Excise Applications (CEA) and Central Operation Services (EMCS/CO) proposed by the Excise Computerization Project (ECP) to provide the Member State Administrations (MSAs) with operational and technical support during EMCS implementation and operation. They encompass: SEED including the collection, consolidation and distribution of registration information. This is a vital part of the EMCS Central Services and an important dependency for the EMCS core business processes. EMCS Central Services/Reference Data (CS/RD) including the collection, consolidation and distribution of the Excise Office List (EOL), the Excise products categories and codes, and the part of the lists of codes that has to be used during the exchanges. 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. Central Services/Management Information System (CS/MIS) including the monitoring of EMCS and the collection and publication of Information and Business Statistics. Excise Test Application (ETA) participating to the technical conformance of NEA by providing testing facilities in the Common Domain (see TESS Section III EMCS Central Services Architecture). EMCS/CO Support Services including the Central Service Desk and the Technical Centre. Those central services (see TESS Section III EMCS Central Services Architecture) use the Common Domain communication services to exchange information with NEAs and to provide interactive interfaces (typically web-based) for users located in the National Domains. The Central Operation Specifications (COS [R6]) describe the organisation and activities of the Central Operation Services. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 13 of 91

14 2.4 Business Communication Channels [BCC] Figure 4 describes the EMCS Business Communication Channels (BCC) established between the various communicating parties. Only BCC crossing the Common Domain network are considered hereafter. Other BCC addressing the EMCS Central Services, the National Domain and the External Domain are considered in TESS Section III and TESS Section IV. Figure 4: EMCS Business Communication Channels Later in this document (see 6.3 EMCS Services Interfacing), they are mapped with the Infrastructure Communication Channels (see 2.5 Infrastructure Communication Channels [ICC]) that technically realise the exchanges at the infrastructure level. Note: Availability and performance requirements classes indicated in the description of BCCs below are described in TESS Section I, 2.6 Compliance with Non-functional Requirements Classes. The respect of those requirements classes implies that individual services and infrastructure channels composing a BCC must have availability and performance requirements greater than the minimum availability and performance requirements of that BCC % - (unavailability of every infrastructure channel + unavailability of every service) availability of BCC. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 14 of 91

15 2.4.1 NEA to NEA [BCC2] This is one of the most important communication channels to be considered in this document. It links all the National Excise Applications through the Common Domain. It requires high availability and guarantee of delivery since it supports critical business exchanges. Figure 5: Business Communication Channel NEA to NEA [BCC2] This communication channel is applicable in most EMCS use cases relating to the core business involving system-to-system relationships. It addresses the following sets of use cases: EMCS Core Business use cases (FESS [R4] Section II). Follow-up use cases (FESS [R4] Section IV Chapter 3). Collaboration use cases including EWSE and MVS (FESS [R4] Section IV Chapter 5). Note: EWSE and MVS will be integrated with all EMCS functions (see PSS [R2] FS2). The related Common Domain exchanges occur now between applications (NEAs) to the contrary of the EMCS Phase 0 where those applications make use of an inter-personal messaging system (i.e. CCN Mail 2) NEA to SEED [BCC6] This communication channel mainly supports the submission of SEED updates by the MSAs. It addresses the use cases described in FESS [R4] Section III and in particular: Dissemination of SEED data (UC1.14) where NEAs submit update information (UC ). Re-synchronization of SEED data (UC1.16) where NEAs request update of register of the economic operators (UC ). Figure 6: Business Communication Channel NEA to SEED [BCC6] It requires high availability and guarantee of delivery since it supports critical business exchanges with SEED. Note: EMCS SEED (also known as SEED v1) central services will be available partially in the Functional Stage 0 (FS0) and completely in the Functional Stage 1 (FS1) as mentioned in the PSS [R2]. In the meantime, SEED v1 will re-use the communication channels used by SEED v0. Then, in nominal conditions, SEED v1 will make use of the CCN/CSI channel that provides the best reliability. The CCN Mail 2 channel (currently used by SEED v0) will be used by SEED v1 only as fallback solution (see 6.3 EMCS Services Interfacing, ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 15 of 91

16 SEED Services) NEA to CS/RD [BCC12] This communication channel mainly supports the submission of Reference Data updates by the MSAs. It addresses the use cases described in FESS [R4] Section III and in particular the re-synchronization of reference data (UC1.05) where NEAs request reference data (UC ). Figure 7: Business Communication Channel NEA to CS/RD and SEED [BCC12] Note: EMCS CS/RD reuses the communication channels implemented for SEED v NEA to CS/MIS [BCC19] This communication channel mainly supports the submission of logging, monitoring and statistical information captured by the NEA and transmitted to CS/MIS. Figure 8: Business Communication Channel NEA to CS/MIS [BCC19] This communication channel is applicable in the following use cases: Management of statistics (FESS [R4] Section III Chapter 5). Manage scheduled unavailability (UC FESS [R4] Section V 2.5) SEED to NEA [BCC7] This communication channel mainly supports the dissemination of SEED data maintained centrally. It requires high availability and guarantee of delivery since it supports critical business exchanges, in particular regarding SEED. Figure 9: Business Communication Channel SEED to NEA [BCC7] It addresses the use cases described in FESS [R4] Section III and in particular the dissemination of SEED data (UC1.14) where Central Services submit changes to all NEAs (UC ). ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 16 of 91

17 Note: EMCS reuses the communication channels implemented for SEED v CS/RD to NEA [BCC10] This communication channel mainly supports the dissemination of reference data maintained centrally. Figure 10: Business Communication Channel CS/RD to NEA [BCC10] It addresses the use cases described in FESS [R4] Section III and in particular the dissemination of reference data (UC1.06) where Central Services submit changes to all NEAs (UC ). Note: EMCS reuses the communication channels implemented for SEED v CS/MIS to NEA [BCC20] This communication channel mainly supports the dissemination of centrally consolidated statistics and monitoring information regarding the availability of the infrastructure. Figure 11: Business Communication Channel CS/MIS to NEA [BCC20] This communication channel is applicable in the following use cases: Management of statistics (FESS [R4] Section III Chapter 5). Manage scheduled unavailability (UC FESS [R4] Section V 2.5). FRS [R7] AP04: Broadcast information on unavailability MSA Users to SEED [BCC9] This channel provides interactive exchanges between users in MSA and SEED. It requires high performance of response time since it tightly links user s interfaces and interactive applications. Figure 12: Business Communication Channel MSA Users to SEED [BCC9] It addresses the use cases described in FESS [R4] Section III and in particular: Dissemination of SEED data (UC1.14). ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 17 of 91

18 Re-synchronization of SEED data (UC1.16). Consultation of SEED information by officials (UC1.22). Note: EMCS (SEED) reuses the communication channels implemented for SEED v0 regarding human-to-system interactions (see TESS Section III EMCS Central Services Architecture for more details) MSA Users to CS/RD [BCC11] This channel provides interactive exchanges between users in MSA and the CS/RD services. It requires high performance of response time since it tightly links user s interfaces and interactive applications. Figure 13: Business Communication Channel MSA Users to CS/RD [BCC11] It addresses the use cases described in FESS [R4] Section III and in particular: Dissemination of reference data (UC1.06). Re-synchronization of reference data (UC1.05). Consultation of reference data by officials (UC1.23). Note: EMCS CS/RD reuses the communication channels implemented for SEED v0 regarding human-to-system interactions (see TESS Section III EMCS Central Services Architecture for more details) MSA Users to CS/MIS [BCC23] This channel provides interactive exchanges between users in MSA and the CS/MIS services. It requires high performance of response time since it tightly links user s interfaces and interactive applications. Figure 14: Business Communication Channel MSA Users to CS/MIS [BCC23] This communication channel is applicable in the following use cases: Management of statistics (FESS [R4] Section III Chapter 5). Manage scheduled unavailability (UC FESS [R4] Section V 2.5). FRS [R7] AP04: Broadcast information on unavailability. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 18 of 91

19 MSA Users to EMCS/CO Support Services [BCC8] This communication channel provides collaborative means of exchanges between individuals located in the MSAs and the Central Support Services provided by the EMCS/CO (see COS [R6]). Figure 15: Business Communication Channel MSA Users to EMCS/CO Support Services [BCC8] It addresses the use cases described in FESS [R4] Section V and COS [R6], and in particular: Problem tracking (UC0.26). Service Call (Help Desk). Management of user accounts of officials (UC0.01). Management of access rights of officials (UC0.03). EMCS Monitoring EMCS/CO Support Services to MSA Users [BCC13] This communication channel provides collaborative means of exchanges between the Central Support Services provided by the EMCS/CO (see COS [R6]) and individuals located in the MSAs. Figure 16: Business Communication Channel EMCS/CO Support Services to MSA Users [BCC13] It addresses the use cases described in FESS [R4] Section V and COS [R6] where the EMCS/CO Support Services needs to notify users, and in particular: Problem tracking (UC0.26). Service Call (Help Desk). Management of user accounts of officials (UC0.01). Management of access rights of officials (UC0.03). EMCS Monitoring. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 19 of 91

20 MSA Users to MSA Users [BCC21] This communication channel provides collaborative means of exchanges between individuals. It allows users in the MSA to asynchronously communicate with people in the other MSA. Figure 17: Business Communication Channel MSA Users to MSA Users [BCC21] It supports in particular the information exchanged for the resolutions of exceptions (e.g. state conflicts) following business decisions (see FRS [R7] 5.3 Resolution of e-ad state conflicts following human decision and AP06: Take a business decision). 2.5 Infrastructure Communication Channels [ICC] Figure 18 describes the Infrastructure Communication Channels (ICC) established between the various communicating parties (see 2.3 Communicating Parties). All those channels are provided by the Common Domain Relay (see Common Domain Relay) and are managed and monitored by the CCN/TC. Figure 18: EMCS Infrastructure Communication Channels The Common Domain Relay is the logical entity offering interoperability means through the Common Domain using the CCN Network. The different protocols supported by the Common Domain Relay are used to implement the required EMCS Communication Channels ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 20 of 91

21 according to their non-functional requirements (see 2.4 Business Communication Channels [BCC]) CCN/CSI Services The CCN/CSI services (see 3.3 CCN/CSI Services) offer direct system-to-system communication. They are not intended for interactive use and do not offer a user-interface. Consequently, they are intended to establish communication channels between National Excise Applications (NEAs) as well as with EMCS Central Services (i.e. [BCC2], [BCC10], [BCC12], [BCC19] and [BCC20]). More specifically, those applications use the CCN/CSI asynchronous transmission mode [ICC1] to interact with other relaying parties through the CCN Network. This mode provides a reliable communications mechanism and ensures that all messages are delivered to the destination. Moreover, this mode significantly reduces the coupling between applications. Applications do not wait for immediate responses from other parts of the system before continuing, which makes the entire platform more tolerant of any application or system failure. Figure 19: EMCS Infrastructure Communication Channels (CSI) Applications interact with the Common Domain Relay using the Common Systems Interface (CSI) programming interface provided by the CSI Client Stack to be installed in the application platforms (see Figure 19). CSI offers a simplified access to CCN services through the Remote API Proxy (RAP) located in the CCN Gateway (see Common Domain Relay). See the relevant CSI documentation: [R14, R15, R16, and R17]. The CCN/CSI model is widely used for existing applications and MSAs already use the CSI API. The CCN gateways and associated components are already in place at each National Administration. Identifier From To Description [ICC1] Common Domain Relay Common Domain Relay [ICC4] NEA Common Domain Relay This channel is transparent for the communicating parties. It transmits asynchronously on the CCN Network the message submitted via [ICC4] (NEA) and [ICC16] (Central Services) This channel is controlled by the CSI Client stack that communicates with the RAP located in the CCN Gateway. It allows applications to queue messages to be asynchronously dispatched to a specific destination through [ICC1]. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 21 of 91

22 Identifier From To Description [ICC5] [ICC15] [ICC16] Common Domain Relay Common Domain Relay Central Services Web Services NEA Central Services Common Domain Relay This channel is controlled by the CSI Client stack that communicates with the RAP located in the CCN Gateway. It allows applications to de-queue incoming messages asynchronously submitted by another party through [ICC1]. This channel is controlled by the CSI Client stack that communicates with the RAP located in the CCN Gateway. It allows applications to de-queue incoming messages asynchronously submitted by another party through [ICC1]. This channel is controlled by the CSI Client stack that communicates with the RAP located in the CCN Gateway. It allows applications to queue messages to be asynchronously dispatched to a specific destination through [ICC1]. Table 1: EMCS Infrastructure Communication Channels (CSI) The Web Services channel presents a synchronous interface using HTTP/S as the underlying communications protocol. In the Common Domain, this is offered by the CCN Intranet services (see 3.4 CCN Intranet Services). The quality of service is limited to that provided by HTTP. Specifically, the channel does not guarantee delivery of messages. The definition of EMCS Web Services allows the creation of a programmatic API for interacting with EMCS Central Services ([BCC12] and [BCC19]). Figure 20: EMCS Infrastructure Communication Channels (Web Services) Applications interact with the HTTP proxy located on the CCN Gateways and the HTTP traffic is routed to the requested destination. Identifier From To Description [ICC2] Common Domain Relay Common Domain Relay [ICC6] NEA Common Domain Relay This channel is transparent for the communicating parties. It relays HTTP/S traffic on the CCN Network interfacing [ICC6] and [ICC17]. This channel is controlled by the CCN HTTP Proxy that manages HTTP/S traffic coming from the National Domain and entering in the Common Domain. Typically, HTTP/S traffic is forwarded to the target HTTP server through [ICC2]. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 22 of 91

23 Identifier From To Description [ICC17] Common Domain Relay Web Interface Central Services This channel is controlled by the CCN HTTP Proxy that manages HTTP/S traffic coming from the CCN Network through [ICC2] and destined to an HTTP server of the EMCS Central Services. Table 2: EMCS Infrastructure Communication Channels (Web Services) Central Services provide Web interface to access Central Excise Applications functionality. This channel is offered via the standard CCN/HTTP model (see 3.4 CCN Intranet Services) and it is synchronous by nature. The quality of service is limited to that offered by HTTP. Figure 21: EMCS Infrastructure Communication Channels (Web Interface) Web browsers connect to a local HTTP proxy on the CCN Gateway, and traffic is forwarded to the Central Web application. The information is presented using simple HTML 4 text and graphics. Identifier From To Description [ICC2] [ICC11] [ICC17] Common Domain Relay MSA Workstation Common Domain Relay Common Domain Relay Common Domain Relay Central Services This channel is transparent for the communicating parties. It relays HTTP/S traffic on the CCN Network interfacing [ICC11] and [ICC17]. This channel is controlled by the CCN Proxy that manages HTTP/S traffic coming from the National Domain (official s workstations) and entering in the Common Domain. Typically, HTTP/S traffic is forwarded to the target HTTP server through [ICC2]. This channel is controlled by the CCN HTTP Proxy that manages HTTP/S traffic coming from the CCN Network through [ICC2] and destined to an HTTP server of the EMCS Central Services. Table 3: EMCS Infrastructure Communication Channels (Web Interface) ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 23 of 91

24 based Interface The CCN Mail 2 (see 3.5 CCN Mail 2 Services) provides an asynchronous, SMTP based interface for interacting with EMCS Services. This bi-directional communication channel is supported by standard protocols (SMTP, POP3 and IMAP4). Figure 22: EMCS Infrastructure Communication Channels ( -based Interface) National users or applications interact with the National Mail Transfer Agent (MTA) that routes the traffic to the Local CCN Mail System (LCMS). The SMTP traffic is then routed to the requested destination. MSAs are free to choose any reader that is appropriate. Identifier From To Description [ICC3] Common Domain Relay Common Domain Relay [ICC7] NEA Common Domain Relay [ICC8] [ICC9] [ICC10] Common Domain Relay Common Domain Relay MSA Workstation NEA MSA Workstation Common Domain Relay This channel is transparent for the communicating parties. It relays SMTP traffic on the CCN Network interfacing [ICC7], [ICC9], [ICC10], [ICC12], [ICC13], [ICC8], [ICC18] and [ICC19]. This channel is controlled by the LCMS that manages SMTP traffic coming from the National Domain and entering in the Common Domain. SMTP traffic is forwarded to the destination (remote LCMS) through [ICC3]. This channel is controlled by the LCMS that manages SMTP traffic coming from the Common Domain and addressed to the National Domain (NEA). Messages are stored in mailboxes and available through POP3 or IMAP4 protocols. This channel is controlled by the LCMS that manages SMTP traffic coming from the Common Domain and addressed to the National Domain. Messages are stored in mailboxes and available through POP3 or IMAP4 protocols. This channel is controlled by the LCMS that manages SMTP traffic coming from the National Domain (user s workstation) and entering in the Common Domain. SMTP traffic is forwarded to the destination (remote LCMS) through [ICC3]. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 24 of 91

25 Identifier From To Description [ICC12] [ICC13] [ICC18] [ICC19] Common Domain Relay EMCS/CO Workstation Central Services Common Domain Relay EMCS/CO Workstation Common Domain Relay Common Domain Relay Central Services This channel is controlled by the LCMS that manages SMTP traffic coming from the Common Domain and addressed to the National Domain. Messages are stored in mailboxes and available through POP3 or IMAP4 protocols. This channel is controlled by the LCMS that manages SMTP traffic coming from the National Domain (EC workstation) and entering in the Common Domain. SMTP traffic is forwarded to the destination (remote LCMS) through [ICC3]. This channel is controlled by the LCMS that manages SMTP traffic coming from the CS/RD and transmitted through the Common Domain. SMTP traffic is forwarded to the destination (remote LCMS) through [ICC3]. This channel is controlled by the LCMS that manages SMTP traffic coming from the Common Domain and addressed to the CS/RD. Messages are stored in mailboxes and available through POP3 or IMAP4 protocols. Table 4: EMCS Infrastructure Communication Channels ( -based Interface) 2.6 System Architecture Figure 24 presents an overview of the system architecture, or operational environment of the EMCS architecture. This shows how Communicating Parties (see 2.3 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 communication channels between applications interacting through the Common Domain infrastructure. The cornerstone of the EMCS Common Domain System Architecture is the National Domain Connection Point NDCP (Figure 23), which groups all devices necessary to the deployment of the EMCS Common Domain Infrastructure (see Chapter 3 EMCS Common Domain Infrastructure) in the National Domain. More details about the NDCP are provided at National Domain Connection Point (NDCP). ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 25 of 91

26 Figure 23: National Domain Connection Point (NDCP) System Architecture ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 26 of 91

27 Figure 24: System Architecture ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 27 of 91

28 The main components addressed by the EMCS Common Domain System Architecture and identified in Figure 24 are the following: NDCP (see National Domain Connection Point (NDCP)) including: CCN Gateway offering both CCN/CSI Services (see 3.3 CCN/CSI Services) and CCN Intranet Services (see 3.4 CCN Intranet Services). Local CCN Mail System (LCMS) offering CCN Mail 2 services (see 3.5 CCN Mail 2 Services). Security Devices, such as a firewall (F/W) and encryption device, which enforce the CCN/CSI General Security Policy. Customer Premises Router (CPR), establishing the TCP/IP link to the CCN backbone. 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 traffic to the LCMS. The EMCS Central Services communicating parties (see TESS Section III EMCS Central Services Architecture) including: SEED (see TESS Section III SEED) providing facilities for managing, storing, notifying, disseminating and consulting information on the Economic Operators register. EMCS CS/RD (see TESS Section III Central Services/Reference Data (CS/RD)) providing management and dissemination services regarding common Reference Data. EMCS CS/MIS (see TESS Section III Central Services/Management Information System (CS/MIS)) providing the facilities to assist the monitoring and the reporting on the operations of EMCS. ETA (see TESS Section III 3.7.4) used for mode-2 testing (see ACS [R5] NEA testing modes) against the NEA located in the premises of the MSA. EMCS/CO Web Portal (see TESS Section III 3.4 EMCS/CO Web Portal) providing the single and unified interface offering to users a secure access to various central sources of information and applications. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 28 of 91

29 3 EMCS Common Domain Infrastructure 3.1 Introduction EMCS is designed to use the Common Communications Network (CCN) infrastructure (see 3.2 CCN Network) and dependent services, which are of three types; CCN/CSI Services (see 3.3 CCN/CSI Services), which offer a secure and reliable communication channel for the asynchronous/synchronous exchange of messages; CCN Intranet Services (see 3.4 CCN Intranet Services) used for HTTP/HTTPS (synchronous) exchanges and access to Web Services (e.g. those offered by Central Services applications as described in TESS Section III); CCN Mail 2 Services (see 3.5 CCN Mail 2 Services) offering standard SMTP-based exchanges (e.g. exchange between national officials). As CCN/CSI Services offer the main communication channel to EMCS applications, a stronger attention is given to their characteristics in terms of Service Level Agreement (see Service Level Agreement) and QoS (see Quality of Service (QoS)). The description of a possible EMCS Common Domain Public Key Infrastructure (PKI), which could be made available to users and applications to securely access Central Services and to allow the interoperability between National Domain PKIs (when available), is provided at 3.6 Public Key Infrastructure (PKI). Refer also to the SESS for the detailed specifications of the EMCS Common Domain PKI. 3.2 CCN Network Overview The Common Communication Network (CCN) is a closed, secured network that is provided by the Common Domain to facilitate the exchange of information between the national administrations of the Customs and Taxation area. Access to the CCN Network is implemented through National Domain Connection Points (NDCP) located at the MSA premises (see National Domain Connection Point (NDCP)). Each NDCP is designed to provide gateways and security services and is connected to the CCN Backbone (full-mesh IP VPN) through a local loop (Figure 25). The local loop is made of a leased line connecting the NDCP to the CCN Backbone local Point of Presence (PoP). Local network redundancy is ensured by the means of a 64K backup ISDN line. Moreover, MSA Organisational Units (located in the National Domain) connect to the NDCP through a national firewall (F/W) that may provide additional measures to protect the National Domain from unwanted access coming from the Common Domain. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 29 of 91

30 Figure 25: CCN Network Overview ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 30 of 91

31 3.2.2 National Domain Connection Point (NDCP) The National Domain Connection Point (NDCP) is located at the MSA premises but centrally managed by the CCN/TC as part of the Common Domain. As illustrated on the Figure 26, the NDCP contains: Common Domain Relay devices (located in a DMZ) offering routing, proxy and gateway services (see Common Domain Relay). Security Devices, such as a firewall (F/W) and encryption device, which enforce the CCN/CSI General Security Policy. Customer Premises Router (CPR), establishing the TCP/IP link to the CCN backbone. Figure 26: National Domain Connection Point (NDCP) The only protocols that are authorised to access the CCN Network (through the Common ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 31 of 91

32 Domain Relay) are: CSI (Common System Interface). A programmatic proprietary interface to allow synchronous and asynchronous exchange of application messages between national Application Platforms through the CCN Network (see 3.3 CCN/CSI Services). HTTP / HTTPS. Transport protocols for web-based applications and Web Services accessible through the CCN Network (see 3.4 CCN Intranet Services). POP3 / IMAP4 / SMTP. Standard transport protocols for the exchange of s through the CCN Network (see 3.5 CCN Mail 2 Services) Common Domain Relay The Common Domain Relay is the logical entity located on the DMZ created inside the NDCP and that is composed of the following physical devices: CCN Gateways, which is a pair of specialised equipment deployed at every MSA site offering both CCN/CSI Services (see 3.3 CCN/CSI Services) and CCN Intranet Services (see 3.4 CCN Intranet Services). Local CCN Mail System (LCMS), which is the specialised equipment deployed at every MSA site offering CCN Mail 2 services (see 3.5 CCN Mail 2 Services). Other equipment may be added on the DMZ as part of the Common Domain Relay entity, according to business needs. Note: The concept of Common Domain Relay is used to simplify the representation of the EMCS Infrastructure Communication Channels (see 2.5 Infrastructure Communication Channels [ICC]) and to specify the EMCS Common Domain Adapter (see 6 EMCS Common Domain Adapter Specifications) Equipment Redundancy Equipment redundancy (typically 1 production + 1 backup CCN Gateway) is offered at every CCN/CSI site to reduce service interruption in case of failure. For critical sites, the redundancy may be extended to other NDCP equipment, including the security device (F/W) and the local loop router (CPR). However, the failover from production to backup CCN Gateway may be not transparent at application level as it may take up to 6 hours for the failover procedure to complete (see Service Level Agreement). Once the network becomes available again, the pending messages in CCN Gateways are delivered Monitoring To ensure the operational efficiency of the whole CCN information system, the CCN/TC applies a proactive approach to the management of incidents. The objective is to detect as early as possible the minor incidents that could impede the CCN/CSI service, so that they do not turn into blocking problems. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 32 of 91

33 To reach this goal the CCN/TC uses an open source Linux-based solution, called Big Brother, which implements system and network monitoring facilities. In the current implementation, Big Brother is embedded in the CCN Gateway standard package and therefore provides CCN administrators with near real-time monitoring facilities (through a web-based interface) of local resources of the Common Domain Relay including: app... Monitoring of predefined list of processes cda... Monitoring of the Cache Directory Access clfs... Monitoring of the Common Logging Facilities Subsystem cpu... Monitoring of the CPU usage disk... Monitoring of the disk space usage mem... Monitoring of the memory mqm... Monitoring of MQSeries processes ping... Monitoring of the network connectivity proc... Monitoring of active processes que... Monitoring of the application queues sched... Monitoring of the scheduler sts... Monitoring of the statistics generation trigger... Monitoring of the trigger monitor tuxedo... Monitoring of the Tuxedo transactional monitor usr... Monitoring of the validity of local users ldap... Monitoring of the LDAP directory (Netscape Directory Service) A consolidated view of all local Big Brother instances is also provided by a central monitoring platform located at the CCN/TC, which performs a polling of all CCN/CSI critical resources and provides the central support team with a global view of the whole CCN/CSI infrastructure. Alarms issued by the local instances are sent to the central monitoring platform for further processing by the support team. 3.3 CCN/CSI Services Intended Usage CCN/CSI services aim at providing machine-to-machine communication in heterogeneous environments using both synchronous and asynchronous paradigms. CCN/CSI services are not intended for (human) interactive use and do not offer any user-interface. CCN/CSI services offer the main communication channel to EMCS applications. More specifically National Excise Applications (NEA) must use the CCN/CSI asynchronous transmission mode to interact with other NEAs through the CCN Network (e.g. transmission of a locally validated e-add to the concerned NEAs at MSA of Destination). ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 33 of 91