SECTION II: EMCS COMMON DOMAIN ARCHITECTURE ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 1 of 91
TABLE OF CONTENTS Table of Contents 1 Introduction... 9 1.1 Scope... 9 1.2 Document Structure... 9 2 EMCS Common Domain Architectural Elements... 11 2.1 Introduction... 11 2.2 Architectural Levels... 11 2.3 Communicating Parties... 12 2.3.1 NEA... 12 2.3.2 MSA Users... 13 2.3.3 Central Services... 13 2.4 Business Communication Channels [BCC]... 14 2.4.1 NEA to NEA [BCC2]... 15 2.4.2 NEA to SEED [BCC6]... 15 2.4.3 NEA to CS/RD [BCC12]... 16 2.4.4 NEA to CS/MIS [BCC19]... 16 2.4.5 SEED to NEA [BCC7]... 16 2.4.6 CS/RD to NEA [BCC10]... 17 2.4.7 CS/MIS to NEA [BCC20]... 17 2.4.8 MSA Users to SEED [BCC9]... 17 2.4.9 MSA Users to CS/RD [BCC11]... 18 2.4.10 MSA Users to CS/MIS [BCC23]... 18 2.4.11 MSA Users to EMCS/CO Support Services [BCC8]... 19 2.4.12 EMCS/CO Support Services to MSA Users [BCC13]... 19 2.4.13 MSA Users to MSA Users [BCC21]... 20 2.5 Infrastructure Communication Channels [ICC]... 20 2.5.1 CCN/CSI Services... 21 2.5.2 Web Services... 22 2.5.3 Web Interface... 23 2.5.4 Email-based Interface... 24 2.6 System Architecture... 25 3 EMCS Common Domain Infrastructure... 29 3.1 Introduction... 29 3.2 CCN Network... 29 3.2.1 Overview... 29 ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 2 of 91
TABLE OF CONTENTS 3.2.2 National Domain Connection Point (NDCP)... 31 3.2.3 Common Domain Relay... 32 3.2.4 Equipment Redundancy... 32 3.2.5 Monitoring... 32 3.3 CCN/CSI Services... 33 3.3.1 Intended Usage... 33 3.3.2 Description... 34 3.3.2.1 CSI-based Application... 34 3.3.2.2 Modes of Usage (Testing Activity)... 34 3.3.3 Service Level Agreement... 35 3.3.3.1 Availability... 35 3.3.3.2 Transaction Volumes - Response Time... 36 3.3.3.3 Services for the Operation and Management of CCN/CSI... 36 3.3.4 Quality of Service (QoS)... 37 3.3.4.1 QoS Attribute... 37 3.3.4.2 Infrastructure Protocol... 38 3.3.5 Security... 39 3.4 CCN Intranet Services... 42 3.4.1 Intended Usage... 42 3.4.2 Description... 42 3.4.3 Quality of Services (QoS)... 42 3.4.4 Security... 43 3.5 CCN Mail 2 Services... 45 3.5.1 Intended Usage... 45 3.5.2 Description... 45 3.5.3 Quality of Services (QoS)... 45 3.5.4 Security... 46 3.6 Public Key Infrastructure (PKI)... 48 4 EMCS Service Access Point Overview... 49 4.1 Introduction... 49 4.2 EMCS Common Domain Service Bus... 50 4.3 EMCS Messages... 51 4.3.1 EMCS-XML Message Format... 51 4.3.2 EMCS Message Structure... 52 4.3.2.1 Infrastructure Level... 52 4.3.2.2 Application Level (EDA)... 52 ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 3 of 91
TABLE OF CONTENTS 4.3.2.3 Application Level (Web Service)... 52 4.3.2.4 Business Level... 53 4.3.3 Multilingualism... 53 4.3.3.1 Character Set... 53 4.3.3.2 Searching Issue... 53 4.3.4 Embedding binary data... 54 5 EMCS Common Domain Interface Specifications... 55 5.1 Introduction... 55 5.2 EMCS Business Interaction Paradigms [BIP]... 56 5.3 Business Process Orchestration... 58 5.3.1 Introduction... 58 5.3.2 Business Orchestration vs. Business Choreography... 58 5.3.3 Message Definition at Business Level... 60 5.4 Application Flow Control... 61 5.4.1 Introduction... 61 5.4.2 Message Validation... 62 5.4.3 Coordination Protocol... 62 5.4.3.1 Preventive Message Queuing... 63 5.4.3.2 Message Sequencing... 63 5.4.3.3 State Machine... 64 5.4.3.4 Infrastructure Message Acknowledgment Implementation... 66 5.4.4 Monitoring... 67 5.4.5 Security... 68 5.4.6 Message Definition at Application Level... 68 5.5 Message Routing... 70 5.6 Exception Handling... 71 5.7 Logging... 73 6 EMCS Common Domain Adapter Specifications... 75 6.1 Introduction... 75 6.2 EMCS Common Domain Adapter Architecture... 76 6.2.1 Business Process Execution Engine... 77 6.2.2 Flow Control Engine... 77 6.2.3 Exception Handler... 77 6.2.4 Common Domain Relay... 77 6.3 EMCS Services Interfacing... 78 6.3.1 Core Business Services... 78 6.3.2 SEED Services... 79 ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 4 of 91
TABLE OF CONTENTS 6.3.3 CS/RD Services... 81 6.3.4 CS/MIS Services... 84 6.3.5 Central Support Services... 86 7 EMCS Business Continuity Specifications... 88 7.1 Introduction... 88 7.2 Problem Statement... 88 7.3 EMCS System Resilience... 89 7.4 CCN Redundancy Options... 90 7.4.1 Backup Gateway at Local Site... 90 7.4.2 Central Backup Site... 90 7.4.3 Other Equipment Redundancy... 90 ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 5 of 91
LIST OF FIGURES List of Figures FIGURE 1: SCOPE OF EMCS COMMON DOMAIN ARCHITECTURE... 9 FIGURE 2: EMCS ARCHITECTURE LEVELS... 11 FIGURE 3: COMMUNICATING PARTIES... 12 FIGURE 4: EMCS BUSINESS COMMUNICATION CHANNELS... 14 FIGURE 5: BUSINESS COMMUNICATION CHANNEL NEA TO NEA [BCC2]... 15 FIGURE 6: BUSINESS COMMUNICATION CHANNEL NEA TO SEED [BCC6]... 15 FIGURE 7: BUSINESS COMMUNICATION CHANNEL NEA TO CS/RD AND SEED [BCC12]... 16 FIGURE 8: BUSINESS COMMUNICATION CHANNEL NEA TO CS/MIS [BCC19]... 16 FIGURE 9: BUSINESS COMMUNICATION CHANNEL SEED TO NEA [BCC7]... 16 FIGURE 10: BUSINESS COMMUNICATION CHANNEL CS/RD TO NEA [BCC10]... 17 FIGURE 11: BUSINESS COMMUNICATION CHANNEL CS/MIS TO NEA [BCC20]... 17 FIGURE 12: BUSINESS COMMUNICATION CHANNEL MSA USERS TO SEED [BCC9]... 17 FIGURE 13: BUSINESS COMMUNICATION CHANNEL MSA USERS TO CS/RD [BCC11]... 18 FIGURE 14: BUSINESS COMMUNICATION CHANNEL MSA USERS TO CS/MIS [BCC23]... 18 FIGURE 15: BUSINESS COMMUNICATION CHANNEL MSA USERS TO EMCS/CO SUPPORT SERVICES [BCC8]... 19 FIGURE 16: BUSINESS COMMUNICATION CHANNEL EMCS/CO SUPPORT SERVICES TO MSA USERS [BCC13]... 19 FIGURE 17: BUSINESS COMMUNICATION CHANNEL MSA USERS TO MSA USERS [BCC21]... 20 FIGURE 18: EMCS INFRASTRUCTURE COMMUNICATION CHANNELS... 20 FIGURE 19: EMCS INFRASTRUCTURE COMMUNICATION CHANNELS (CSI)... 21 FIGURE 20: EMCS INFRASTRUCTURE COMMUNICATION CHANNELS (WEB SERVICES)... 22 FIGURE 21: EMCS INFRASTRUCTURE COMMUNICATION CHANNELS (WEB INTERFACE)... 23 FIGURE 22: EMCS INFRASTRUCTURE COMMUNICATION CHANNELS (EMAIL-BASED INTERFACE)... 24 FIGURE 23: NATIONAL DOMAIN CONNECTION POINT (NDCP) SYSTEM ARCHITECTURE... 26 FIGURE 24: SYSTEM ARCHITECTURE... 27 FIGURE 25: CCN NETWORK OVERVIEW... 30 FIGURE 26: NATIONAL DOMAIN CONNECTION POINT (NDCP)... 31 FIGURE 27: CCN INFRASTRUCTURE PROTOCOL: COA, COD FOR SUCCESSFUL TRANSFER... 38 FIGURE 28: CCN INFRASTRUCTURE PROTOCOL: EXCEPTION REPORT... 39 FIGURE 29: CCN NETWORK INFRASTRUCTURE CCN/CSI SERVICES... 41 FIGURE 30: CCN NETWORK INFRASTRUCTURE CCN INTRANET SERVICES... 44 FIGURE 31: CCN NETWORK INFRASTRUCTURE CCN MAIL 2 SERVICES... 47 FIGURE 32: EMCS COMMON DOMAIN SERVICE BUS... 50 FIGURE 33: EMCS MESSAGE STRUCTURE (EDA)... 52 FIGURE 34: EMCS MESSAGE STRUCTURE (WEB SERVICE)... 53 FIGURE 35: EMCS COMMON DOMAIN SERVICE BUS INTERFACE... 56 FIGURE 36: BUSINESS ORCHESTRATION VS. BUSINESS CHOREOGRAPHY... 59 FIGURE 37: COMMON DOMAIN SERVICE BUS INTERFACE AT BUSINESS LEVEL... 59 FIGURE 38: MESSAGE DEFINITION AT BUSINESS LEVEL... 60 FIGURE 39: COMMON DOMAIN SERVICE BUS INTERFACE AT APPLICATION LEVEL... 61 FIGURE 40: COORDINATION PROTOCOL - STATE MACHINE: PROCESS INSTANTIATION... 65 FIGURE 41: BUSINESS PROCESS CHOREOGRAPHY: STATE-TRANSITION DIAGRAM OF E-AD AT DISPATCH... 66 FIGURE 42: BUSINESS PROCESS CHOREOGRAPHY: STATE-TRANSITION DIAGRAM OF E-AD AT DESTINATION... 66 FIGURE 43: MESSAGE DEFINITION AT APPLICATION LEVEL... 68 FIGURE 44: COMMON DOMAIN SERVICE BUS INTERFACE AT INFRASTRUCTURE LEVEL... 70 ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 6 of 91
LIST OF FIGURES FIGURE 45: EXCEPTION HANDLING... 71 FIGURE 46: EMCS COMMON DOMAIN SERVICE BUS ADAPTER... 75 FIGURE 47: EMCS COMMON DOMAIN SERVICE BUS ADAPTER ARCHITECTURE... 76 FIGURE 48: CORE BUSINESS SERVICES (BCC)... 78 FIGURE 49: CCN/CSI SERVICES: ONE-WAY BUSINESS INTERACTION (NEANEA)... 78 FIGURE 50: EMAIL-BASED INTERFACE: ONE-WAY BUSINESS INTERACTION (NEA NEA)... 78 FIGURE 51: CCN/CSI SERVICES: TWO-WAY BUSINESS INTERACTION (NEANEA)... 79 FIGURE 52: EMAIL-BASED INTERFACE: TWO-WAY BUSINESS INTERACTION (NEA NEA)... 79 FIGURE 53: CS/RD AND CS/RD SERVICES (BCC)... 79 FIGURE 54: CCN/CSI SERVICES: ONE-WAY BUSINESS INTERACTION (SEED NEA)... 79 FIGURE 55: EMAIL-BASED INTERFACE: ONE-WAY BUSINESS INTERACTION (SEED NEA)... 80 FIGURE 56: CCN/CSI SERVICES: TWO-WAY BUSINESS INTERACTION (NEA SEED)... 80 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: EMAIL-BASED INTERFACE: ASYNCHRONOUS TWO-WAY BUSINESS INTERACTION (NEA SEED)... 81 FIGURE 60: WEB INTERFACE: HUMAN INTERACTION (NEA SEED)... 81 FIGURE 61: CS/RD SERVICES (BCC)... 81 FIGURE 62: CCN/CSI SERVICES: ONE-WAY BUSINESS INTERACTION (CS/RD NEA)... 82 FIGURE 63: EMAIL-BASED INTERFACE: ONE-WAY BUSINESS INTERACTION (CS/RD NEA)... 82 FIGURE 64: CCN/CSI SERVICES: TWO-WAY BUSINESS INTERACTION (NEA CS/RD)... 82 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: EMAIL-BASED INTERFACE: ASYNCHRONOUS TWO-WAY BUSINESS INTERACTION (NEA CS/RD)... 83 FIGURE 68: WEB INTERFACE: HUMAN INTERACTION (NEA CS/RD)... 84 FIGURE 69: CS/MIS SERVICES (BCC)... 84 FIGURE 70: CCN/CSI SERVICES: ONE-WAY BUSINESS INTERACTION (NEA CS/MIS)... 84 FIGURE 71: CCN/CSI SERVICES: ONE-WAY BUSINESS INTERACTION (CS/MIS NEA)... 85 FIGURE 72: EMAIL-BASED INTERFACE: TWO-WAY BUSINESS INTERACTION (NEA CS/MIS)... 85 FIGURE 73: EMAIL-BASED INTERFACE: TWO-WAY BUSINESS INTERACTION (CS/MIS NEA)... 85 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)... 86 FIGURE 77: CENTRAL SUPPORT SERVICES (BCC)... 86 FIGURE 78: WEB INTERFACE: HUMAN INTERACTION (MSA USER EMCS/CO CENTRAL SERVICES)86 FIGURE 79: EMAIL-BASED INTERFACE: HUMAN INTERACTION (EMCS/CO CENTRAL SERVICES MSA USER)... 87 ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 7 of 91
LIST OF TABLES List of Tables TABLE 1: EMCS INFRASTRUCTURE COMMUNICATION CHANNELS (CSI)... 22 TABLE 2: EMCS INFRASTRUCTURE COMMUNICATION CHANNELS (WEB SERVICES)... 23 TABLE 3: EMCS INFRASTRUCTURE COMMUNICATION CHANNELS (WEB INTERFACE)... 23 TABLE 4: EMCS INFRASTRUCTURE COMMUNICATION CHANNELS (EMAIL-BASED INTERFACE)... 25 TABLE 5: QOS ATTRIBUTE AND SUB-FIELDS.... 37 TABLE 6: MESSAGE HEADER AT BUSINESS LEVEL... 60 TABLE 7: MESSAGE HEADER AT APPLICATION LEVEL... 69 TABLE 8: EMCS AVAILABILITY REQUIREMENTS VS. CCN COMMITTED SERVICE LEVEL... 89 ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 8 of 91
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
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
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
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 3.3.4 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. 2.3.1 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
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. 2.3.3 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
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 1. 1 100% - (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
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). 2.4.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-114-110). Re-synchronization of SEED data (UC1.16) where NEAs request update of register of the economic operators (UC-116-110). 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, 6.3.2 ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 15 of 91
SEED Services). 2.4.3 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-105-110). Figure 7: Business Communication Channel NEA to CS/RD and SEED [BCC12] Note: EMCS CS/RD reuses the communication channels implemented for SEED v0. 2.4.4 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 (UC0.07 - FESS [R4] Section V 2.5). 2.4.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-114-240). ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 16 of 91
Note: EMCS reuses the communication channels implemented for SEED v0. 2.4.6 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-106-110). Note: EMCS reuses the communication channels implemented for SEED v0. 2.4.7 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 (UC0.07 - FESS [R4] Section V 2.5). FRS [R7] 4.2.4 AP04: Broadcast information on unavailability. 2.4.8 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
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). 2.4.9 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). 2.4.10 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 (UC0.07 - FESS [R4] Section V 2.5). FRS [R7] 4.2.4 AP04: Broadcast information on unavailability. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 18 of 91
2.4.11 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. 2.4.12 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
2.4.13 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 4.2.6 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 3.2.3 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
according to their non-functional requirements (see 2.4 Business Communication Channels [BCC]). 2.5.1 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 3.2.3 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
Identifier From To Description [ICC5] [ICC15] [ICC16] Common Domain Relay Common Domain Relay Central Services 2.5.2 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
Identifier From To Description [ICC17] Common Domain Relay 2.5.3 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
2.5.4 Email-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 e-mail protocols (SMTP, POP3 and IMAP4). Figure 22: EMCS Infrastructure Communication Channels (Email-based Interface) National users or applications interact with the National Mail Transfer Agent (MTA) that routes the e-mail traffic to the Local CCN Mail System (LCMS). The SMTP traffic is then routed to the requested destination. MSAs are free to choose any e-mail 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
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 (Email-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 3.2.2 National Domain Connection Point (NDCP). ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 25 of 91
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
Figure 24: System Architecture ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 27 of 91
The main components addressed by the EMCS Common Domain System Architecture and identified in Figure 24 are the following: NDCP (see 3.2.2 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 e-mail traffic to the LCMS. The EMCS Central Services communicating parties (see TESS Section III EMCS Central Services Architecture) including: SEED (see TESS Section III 3.7.1 SEED) providing facilities for managing, storing, notifying, disseminating and consulting information on the Economic Operators register. EMCS CS/RD (see TESS Section III 3.7.2 Central Services/Reference Data (CS/RD)) providing management and dissemination services regarding common Reference Data. EMCS CS/MIS (see TESS Section III 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 TESS Section III 3.7.4) used for mode-2 testing (see ACS [R5] 3.1.2 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
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 e-mail 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 3.3.3 Service Level Agreement) and QoS (see 3.3.4 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 3.2.1 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 3.2.2 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
Figure 25: CCN Network Overview ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 30 of 91
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 3.2.3 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
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 e-mails through the CCN Network (see 3.5 CCN Mail 2 Services). 3.2.3 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). 3.2.4 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 3.3.3 Service Level Agreement). Once the network becomes available again, the pending messages in CCN Gateways are delivered. 3.2.5 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
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 3.3.1 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
According to the EMCS Business Communication Channels definition (see 2.4 Business Communication Channels [BCC]) and their decomposition into Infrastructure Communication Channels (see 2.5 Infrastructure Communication Channels [ICC]), CCN/CSI services are intended for the following usage: [BCC2]... NEA to NEA [BCC10]... CS/RD and SEED to NEA [BCC12]... NEA to CS/RD and SEED [BCC19]... NEA to CS/MIS [BCC20]... CS/MIS to NEA 3.3.2 Description The CCN/CSI channel topology (see Figure 29) provides a queue-based messaging model. Each queue offers persistent storage and allows applications to send and read messages. Messages are delivered in a reliable fashion between CCN gateways for processing by the target application. 3.3.2.1 CSI-based Application A CSI-based application is a program installed on an MSA Application Platforms (AP) that exchange messages with another CSI-based application (located in another MSA) over the CCN Network (see Figure 29). CSI-based applications interact with the gateways using the Common Systems Interface (CSI) programming interface. CSI offers a simplified access to CCN services and ensures interoperability between application platforms. See the relevant CSI documentation for more detail on the programming interface ([R14], [R15], [R16] and [R17]). 3.3.2.2 Modes of Usage (Testing Activity) CCN/CSI services support various modes of usage allowing CSI-based applications to interact with different CCN/CSI infrastructure resources, which are allocated to specific working environments (i.e. production, test, training). From a technical viewpoint, a single CCN instance has the capability to run in different modes (e.g. production + test), which means that the same physical machine is able to simultaneously support both production and test traffics. This capability is a recent evolution brought to the CCN software also known as multimode. The capability to handle several types of traffic is of course a key feature in the scope of the testing environments specifications, specifically with regard to the Excise Test Application (ETA) as described in TESS Section III and the Standard Excise Test Application (SETA) as described in TESS Section IV. The various test modes, which are recognised in the current CCN implementation, are identified by the following keywords: LCT... Local Client Test This mode aims at testing local client application functionality. The local CCN gateway is used as a loopback gateway (i.e. local relay) to reach a reference ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 34 of 91
server application running on a local Application Platform in the MSA. This mode is not used in the context of EMCS. LST... Local Server Test This mode aims at testing local server application functionality. The local CCN gateway is used as a loopback gateway to reach the local server application (e.g. NEA) under test from a standard application. In the EMCS context, this mode (known as mode 1) allows validating SETA NEA interactions. RST... Remote Server Test Same principle as LST, but the testing activity is conducted with reference server application made available centrally (e.g. ETA). This test mode involves real exchanges over the CCN Network. In the EMCS context, this mode (known as mode 2) allows validating NEA ETA interactions. RIT... Remote Interoperability Test This mode corresponds to the last step in the testing activity and allows testing real application-to-application interactions over the CCN backbone. This mode can also be used for training purposes. In the EMCS context, this mode (known as mode 3) allows validating NEA NEA interactions. Those keywords are also present in the naming convention applied to the persistent objects (e.g. queues) and profiles, which are defined in the CCN configuration. Note: The ACS [R5] contains more details about the specifications of the testing environments used to perform the EMCS acceptance and certification activity. 3.3.3 Service Level Agreement 3.3.3.1 Availability The level of availability of a specific service is measured as the average time this service was functioning in accordance with the specifications over a defined period. The value is expressed as the percentage of the total service time of the reference time interval: A x = the availability of the CCN gateway x A x = 100 % * (1 - t / T) t = total number of minutes that the CCN gateway was not functioning during the reference time (T) T = reference time (total number of minutes in a given month from 8:00 to 20:00 Brussels time, Mon-Fri). ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 35 of 91
The committed values are: Service Element Minimum Availability Individual CCN Gateway over 20 working days (1) 95 % Overall system availability over 20 days 97 % (1) Working day = 8:00 to 20:00 Brussels time, Monday to Friday except Christmas and New Year s Day Note: Considering that these committed values are less stringent than those required by the EMCS business, which requires a 99,75 permanent class of availability (see TESS Section I 2.6.1 Availability Requirements Classes [AR]), compensating measures have to be considered as part of the EMCS Common Domain Architecture specifications, so as to maintain the EMCS business continuity at an acceptable level (see Chapter 7 EMCS Business Continuity Specifications). 3.3.3.2 Transaction Volumes - Response Time The messages exchanged over CCN/CSI are typically small in size (several kilobytes). Larger messages have been successfully tested up to 100 MB in size, although this should not be considered as the normal operating mode. On an AP CCN CCN AP reference platform (10Mbps LAN-based), the CCN/CSI system exhibits the following values: An average message throughput of 10 messages per second (asynchronous paradigm, message size = 1 KB). An average response time 1 second (request/response paradigm, short response message 1 KB). If the size of the response message is bigger (e.g. 1 MB), the message download time has to be added to the average response time. 3.3.3.3 Services for the Operation and Management of CCN/CSI Help desk hours of coverage: o 8:00 to 20:00 Brussels time, Monday to Friday except Christmas and New Year s Day. Supported languages: o English and French Incident and problem management: o Intervention delay Urgent problem... 30 minutes Normal problem... 2 hours Not urgent problem... 8 hours o Production / Backup Gateway failover completion delay... 6 hours o Incident Progress Urgent problem... Reviewed and reported continually Normal problem... Reviewed and reported at least daily Not urgent problem... Reviewed and reported at least weekly ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 36 of 91
Other services: o Change management o Administration service o Notification service o Training service o Consulting service o Inventory management o Software configuration management o Documentation management service o Security service o Reporting service 3.3.4 Quality of Service (QoS) The Quality of Service (QoS) defines the quality of the communication relating to integrity, confidentiality, compression, and reporting. In the context of EMCS, a typical usage of the QoS concerns the various reports, which can be requested by the sending NEA, so as to be notified about the status of the message transmission (see 3.3.4.2 Infrastructure Protocol). 3.3.4.1 QoS Attribute The QoS attribute is one of the configuration items of an EMCS application based on CSI (e.g. NEA). The QoS is applied to all the messages submitted or received by the application according to the CcnDefaultQOS attribute value. This attribute is composed of 10 sub-fields. The following values (Table 5) are to be entered into the CSI-based application configuration form (part 4) and are mandatory for EMCS applications (either centrally or nationally developed). Attribute CcnDefaultQOS ClassOfTraffic Compression-Option Compression-Algo Confidentiality Integrity Priority 5 DegradedMode ReplyToQueue ReportRequest Description The default QoS is applied to all the messages submitted or received by the application. DEFAULTCOT Forbidden LZW Forbidden Forbidden NotAllowed <left blank> Exception Expiration ConfirmOnArrival ConfirmOnDelivery PassCorrelationId PassMessageId Table 5: QoS Attribute and Sub-fields. (CoA) (CoD) The production of reports specified by the ReportRequest sub-field (e.g. ConfirmOnArrival) is an integral part of the infrastructure protocol, which is outlined below (see 3.3.4.2 ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 37 of 91
Infrastructure Protocol). 3.3.4.2 Infrastructure Protocol The CCN/CSI channel provides a reliable communication mechanism and ensures that all messages are delivered to the destination. This section illustrates by means of Sequence Diagrams the CCN report messages created following the use of the QoS configuration specified in 3.3.4.1 QoS Attribute. It shows the communication between a sending CSI stack, a sending CCN stack, a receiving CCN stack and a receiving CSI stack. The term stack means the specific software installed on the CCN Gateway, which implements the CCN and CSI protocol services. It starts with the normal case (Figure 27) in which a Confirm On Arrival (CoA) and a Confirm On Delivery (CoD) reports are received. Based on this normal case, we then present a case where an exception report is produced (Figure 28). Figure 27: CCN Infrastructure Protocol: CoA, CoD for Successful Transfer For every IE message sent, a sending application (e.g. NEA) has to wait for the reception of the CoA and CoD before concluding that the message has been transferred successfully. The CoA is denoting that the IE message has reached the destination queue on the remote CCN Gateway, while the CoD is denoting that the IE message has been successfully read and deleted from the queue. If it has expired in the meantime, an Expiration Report is issued instead of the CoD. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 38 of 91
Figure 28: CCN Infrastructure Protocol: Exception Report As illustrated on Figure 28, an Exception Report is generated whenever an anomaly is detected in the internal CCN/CSI behaviour at either the sending or receiving gateway (e.g. the receiving CCN Gateway is unreachable). Exception Report generation is linked to the usage of the so-called technical queues. Indeed, when a sending application (e.g. NEA) is sending a message through CCN/CSI, the message is first stored in the internal technical queues of the CCN/CSI stack on the sending gateway. CCN/CSI then attempts to forward the message from the internal technical queues on the sending gateway to the internal technical queues on the receiving gateway, and from these to the destination queue in the receiving gateway. Any problem encountered during this queuing process will provoke the issuance of an Exception Report. Note: CCN QoS does not guarantee the ordered delivery of asynchronous exchanges. This issue is particularly significant when unavailability occurs at the infrastructure level. In such a case, IE messages are queued by CCN until the availability of the failed equipment is reestablished and at that time the probability exists that some inversions in the delivery of IE messages occur. Moreover, the CCN QoS does not assure the delivery of CoA and CoD in sequence (in rare occasions, the CoD may be returned first) and does not issue exception or expiry reports on other report messages (e.g. in the case a CoA or a CoD would get lost or improperly transmitted). To compensate these (infrastructure level) weaknesses, it is suggested that EMCS implements additional control mechanisms at a higher level (application level): this is precisely the scope of the Coordination Protocol that is specified at 5.4.3 Coordination Protocol. 3.3.5 Security The CCN/CSI channel builds on the security mechanisms already offered by CCN/CSI and used by all CSI applications. Specifically: Authentication.... CSI-based applications must authenticate before exchanging messages across the CCN network. The authentication phase ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 39 of 91
involves a unique user ID and password that is verified against a local directory of users (running on the local CCN Gateway). This ensures that only authorised applications can access the EMCS resources made available through CCN/CSI services. Authorisation... CSI-based applications access control is provided using so-called CCN profiles against which the authenticated application (basically its user ID) is checked. Only authorised applications can read and/or write to the CCN queues dedicated to EMCS applications. Integrity... CSI-based applications can specify a Quality of Service (QoS) when transmitting messages (see 3.3.4.1 QoS Attribute). The QoS attribute is transmitted through the network along with the message and allow additional integrity checks to be included that hash the contents of the message. Privacy... IPSec VPN encryption is used to encrypt all traffic over the CCN network between CCN gateways. In addition, applications can specify the level of confidentiality in the QoS parameters of a message transmission. In this case, the message contents are encrypted directly by the CSI stack, to ensure end-to-end encryption between applications. Audit... A set of audit logs on the CCN traffic that is exchanged via the CCN Gateways is maintained and consolidated centrally for audit and statistics purpose. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 40 of 91
Figure 29: CCN Network Infrastructure CCN/CSI Services ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 41 of 91
3.4 CCN Intranet Services 3.4.1 Intended Usage The CCN Intranet provides the CCN Community with a secure channel for the support of HTTP(S)-based services and therefore offers a straightforward path for the deployment of Service-Oriented Architecture (SOA), as developed in the TESS Section I General Introduction, 3.3.1. For EMCS this channel is mainly used to access Web Services (SOAP/HTTP(S)) and Web Interface (HTML/HTTP(S)), which are made available centrally to MSA applications and users (see TESS Section III EMCS Central Services Architecture for more information). More precisely, according to the EMCS Business Communication Channels definition (see 2.4 Business Communication Channels [BCC]), CCN Intranet services are intended for the following usage: [BCC8]... MSA Users to EMCS/CO SUPPORT SERVICES [BCC12]... NEA to CS/RD and SEED [BCC19]... NEA to CS/MIS [BCC11]... MSA Users to CS/RD and SEED [BCC23]... MSA Users to CS/MIS 3.4.2 Description CCN Intranet services are delivered through specialised servers, called CCN Gateways, deployed at every MSA site, and implementing AAA (Authentication, Authorisation, Accounting) and HTTP-proxy functions (Figure 30). The CCN Intranet offers a straightforward path to the deployment of Web Services that can be used by client applications that e.g. need access to excise data such as Economic Operators details, the lists of Excise Offices and Excise Products. The Web Services channel presents a synchronous interface based on SOAP (Simple Object Access Protocol) technology. The communication is provided by the HTTP(S) protocol over the CCN Network. Applications interact with the HTTP-proxy running on their local CCN Gateway that routes the HTTP(S) traffic to the requested destination. When HTTPS is used the HTTP-proxy do not decrypt the communication and an end-to-end encrypted channel (e.g. NEA NEA, NEA CEA) can therefore be established over the CCN Network between the Applications Platforms. 3.4.3 Quality of Services (QoS) Web Services implemented for EMCS use HTTP as underlying communication protocol. Therefore the Quality of Service (QoS) is limited to that offered by HTTP. Specifically, the channel does not guarantee delivery of messages between the client and the server application. Any lost message needs to be re-sent with appropriate logic on the server side to remove duplicates (typically compensation mechanisms at application level). ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 42 of 91
NEAs requiring guaranteed delivery should use the CCN/CSI channel (see 3.3 CCN/CSI Services) that supports reliable message exchange. Some additional points are worthy of note: Unidirectional... The Web Services channel is based on the client-server model. All SOAP requests must be initiated from a SOAP client (e.g. NEA) to a SOAP server (e.g. CS/RD application). Stateless... HTTP/1.0 does not provide any notion of session or state: each invocation is considered as an atomic and self-contained request; HTTP/1.1 however supports persistent connections but the beneficial effect of HTTP/1.1 cannot be experienced until all involved parties (clients and servers) are upgraded. So, most of the time session management is addressed by other relying parties (cookie, SSL identifier, etc.). Synchronous protocol... Communications between SOAP clients and SOAP server applications, such as the Central Services applications, are synchronous. A client must wait for a response from the server before continuing. 3.4.4 Security Security is provided using a combination of the CCN infrastructure and the Web server security model: Unidirectional... The Web Services channel is based on the client-server model. All SOAP requests must be initiated from a SOAP client (e.g. NEA) to a SOAP server (e.g. CS/RD application). Authentication... All users/applications must be authenticated before they can access the Central Services interface. The HTTP-proxy running on the local CCN Gateway ensures that users are correctly authenticated, using a login/password based mechanism (i.e. not X509 Certificate based) that offers both human and programmatic interfaces. Authorisation... Access to resources (e.g. EMCS Central Services) through the CCN Intranet is restricted authorised users and applications. Access control is provided using the CCN profile definitions combined with role-based security defined in the Web application server and enforced by the concerned Central Services application. Integrity... The Web Services channel does not provide any explicit support to ensure data integrity during the transfer of data. Web browsers users and applications can however use the SSL protocol to secure the access to EMCS Central Services, as this protocol automatically verifies the integrity of all communications between connection endpoints. Audit... A set of audit logs on the HTTP(S) traffic that is exchanged via the CCN-proxies is maintained and consolidated centrally for audit and statistics purpose. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 43 of 91
Figure 30: CCN Network Infrastructure CCN Intranet Services ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 44 of 91
3.5 CCN Mail 2 Services 3.5.1 Intended Usage The CCN Mail 2 system provides the MSAs with a secure channel for the support of e-mail services over the CCN Network. Concerning EMCS, the CCN Mail 2 system is mainly used for the communication between MSA Users and for the transmission of automatic e-mail notifications generated by applications. More precisely, according to the EMCS Business Communication Channels definition (see 2.4 Business Communication Channels [BCC]), CCN Mail 2 services are intended for the following usage: [BCC8]... MSA Users to EMCS/CO Support Services [BCC13]... EMCS/CO Support Services to MSA Users [BCC21]... MSA Users to Remote MSA Users The CCN Mail 2 system also provides a simple fallback solution in case of unavailability of other services. Indeed, if the access to CCN/CSI services (see 2.5.1 CCN/CSI Services) is not possible whereas e-mail services remain available, the CCN Mail 2 system could be used to ensure the business continuity of the following channels: [BCC2]... NEA to NEA [BCC10]... CS/RD and SEED to NEA [BCC12]... NEA to CS/RD and SEED [BCC19]... NEA to CS/MIS [BCC20]... CS/MIS to NEA 3.5.2 Description CCN Mail 2 services are delivered through specialised servers, called LCMS (for Local CCN Mail Server), deployed at every MSA site and implementing standard SMTP relaying functions as well as local functional mailboxes which are made accessible to MSAs through standard protocols (i.e. POP3, IMAP4, and HTTP (webmail)). Depending on MSA policy and technical environment, MSA users or NEA can interact either with their National MTA that routes the e-mail traffic to the LCMS, or directly to the LCMS, which in turn either gives access to the local resources (mailboxes) or relays the mail traffic to the right destination over the CCN backbone (Figure 31). 3.5.3 Quality of Services (QoS) The e-mail platform offered by CCN Mail 2 provides a bi-directional, asynchronous channel. Messages are delivered on a best-effort basis, but delivery cannot be guaranteed. The delivery time of e-mail cannot be guaranteed and users should not send urgent or critical messages via this channel. Messages are currently limited to maximum of 10 MB and a maximum mailbox size of 100 MB. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 45 of 91
3.5.4 Security The e-mail channel is a restricted e-mail platform and is only accessed by authorised users who have been granted permission by the MSAs. Authentication.... Users / applications provide a user ID and password before gaining access to the CCN Mail 2 services (i.e. for both accessing functional mailboxes defined on the LCMS or sending e-mail through the CCN Network). However, this cannot be used to guarantee the identity of the user / application. Authorisation... Access to the EMCS functional mailboxes defined on every LCMS is allowed only to users duly authorised by the MSA. Integrity... E-mail messages are delivered on a best-effort basis using the Quality of Service offered by SMTP. The channel cannot guarantee that messages have not been modified during transit (unlike the CCN/CSI and SOAP message integrity checks). Privacy... IPSec VPN encryption ensures privacy during transmission between LCMS (end-to-end encryption through S/MIME message encryption is not yet supported). Audit... CCN Mail 2 provides logging of e-mail traffic. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 46 of 91
Figure 31: CCN Network Infrastructure CCN Mail 2 Services ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 47 of 91
3.6 Public Key Infrastructure (PKI) The Security Requirements expressed in the SEP [R3] and further detailed in the SESS [R9] indicate some areas where specific cryptographic controls, which are usually well served by a Public Key Infrastructure (PKI), could be needed. A PKI is the combination of software, encryption technologies, processes, and services that enable an organisation to secure its communications and business transactions. A PKI solution usually meets the security requirements of authenticity (strong authentication), confidentiality (data encryption), integrity (digital signature), and non-repudiation. Clearly, the conditions for a full PKI implementation involving trust relationships with national PKI are not met today. Indeed, this would require all involved parties (i.e. MSAs, Economic Operators) to be PKI ready, which is not the case today. However, the current situation should not prevent us to make proposals about the way the interoperability between national PKIs could be established, whenever the use of cryptographic controls such as digital signature and message-level encryption would be generalised to the whole EMCS system in the future. This is the reason why an extensive description of what we called the EMCS Common Domain Public Key Infrastructure (CDPKI) is proposed in the SESS, Appendix D [R9]. Refer to it for more details. The EMCS CDPKI involves the implementation of a Bridge Certification and Validation Authority (Bridge CA/VA) as part of the Common Domain services to provide the necessary trust relationship between the national PKIs. Note: MSA representatives must confirm the proposed design through an appropriate ad-hoc working group before it can be decided to go further in the EMCS CDPKI implementation. In the meantime, the EMCS CDPKI will remain at the state of proposal without any impact on the EMCS master project plan. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 48 of 91
4 EMCS Service Access Point Overview 4.1 Introduction Even if the Common Domain Infrastructure (see Chapter 3 EMCS Common Domain Infrastructure) takes in charge the exchanges in a reliable way, it does not completely satisfy the EMCS requirements at business and application levels. Indeed, the common agreement defined at business level through the Functional Excise System Specifications (FESS [R4]) implies more than just technical exchanges of messages. It defines complex business process flows which are specific to the EMCS and which cannot be only regulated at the CCN level. A major characteristic of EMCS, and especially at the Common Domain level, is that it is mainly made up of automatic sequences of processes entrusted to different IT systems and that are automatically chained. Therefore, there is generally no intermediate business actor enabled to verify and correct movement information during the processing of a use case. Consequently, and according to the Fallback and Recovery Specifications (FRS [R7]), there must be general mechanisms to ensure that only correct data are entered into the system and that the normal sequence of states is respected. The objective of the EMCS Service Access Point is to provide an interface (see Chapter 5 EMCS Common Domain Interface Specifications) at the business level exposing an adapter (see Chapter 6 EMCS Common Domain Adapter Specifications) that covers all aspect of the business exchanges in the Common Domain (also called Business Process Choreography, see 5.3.2 Business Orchestration vs. Business Choreography). Moreover, it provides the necessary measures to correctly take charge of the continuity and integrity of EMCS business in the Common Domain where unexpected circumstances arise, and also it considers related functional, organisational, procedural, and security requirements. The set of adapters deployed in the various locations upon the CCN Network constitutes the EMCS Common Domain Service Bus (see Figure 32). ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 49 of 91
Figure 32: EMCS Common Domain Service Bus 4.2 EMCS Common Domain Service Bus The EMCS Common Domain Service Bus is the set of services provided at all levels (business, application and infrastructure levels) that enforces the reliable implementation of the EMCS requirements. It provides an interface that can be smoothly used by the national and central excise applications and that allows efficient interoperability between those applications in a loosely coupled way. The EMCS Common Domain Service Bus only deals with the EMCS requirements involved in the Common Domain. It does not dictate the way National Excise Applications (NEA) or Central Services must be implemented and how they establish the communication channels with the External Domain (Trader s interface). Considering the format and the structure of the exchanged messages (see 4.3 EMCS Messages), the interface (see Chapter 5 EMCS Common Domain Interface Specifications) and the services provided by the service bus, the following aspects of the EMCS in the Common Domain are taken into account: Business Process Management assists in the right synchronisation of the EMCS business process states maintained at the various involved locations (i.e. NEAs), ensuring the correct implementation of the EMCS Business Choreography. Exchange Coordination controls the protocol to be implemented for the messages exchanged between applications and to detect as soon as possible when failures occur. Both participate to the detection and prevention measures that are mentioned in the ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 50 of 91
Fallback and Recovery Specifications (FRS). They must be systematically applied in the course of a normal activity flow. This prevents or at least reduces the occurrence of an exception, or prepares elements that would later help in applying further measures (exception handling). Exception Handling provides the functionality to perform business and technical compensations that are required when failures are detected. According to the FRS [R7] (PRO010), any non-conformity of a process implemented following the functional specifications must be reported in order to be assessed and processed by the MSA for confirmation or rejection and possible correction (see 5.6 Exception Handling). Logging keeps track of all the activities at the various levels in order to provide statistics on EMCS operations and adjust measures maintaining the Quality of Service at the required level. Monitoring helps supervising the system and provides notification as soon as an element is unavailable. Security enforces security measures at application levels where the underlying infrastructure (i.e. CCN/CSI) does not propose it. 4.3 EMCS Messages 4.3.1 EMCS-XML Message Format The supported message format in the Common Domain is based on XML. XML offers a number of advantages to all parties and simplifies the internal implementation: Standards based. XML is widely used throughout the industry and is well supported by tools, vendors and industry-specific groups; Simple integration. XML simplifies integration with existing systems and alternative message formats. XML can be transformed using XSLT rules or manipulated using XML standards such as DOM, XPath etc; Data validation. All XML messages are specified using a well-defined and rigorous XML Schema message grammar. This grammar ensures that messages are well-formed, valid and conform to the message specifications; Minimal system requirements. XML offers powerful mechanisms for defining messages, but also imposes a few requirements on the part of the developer. XML parsers are available in most programming languages and are often integrated into products and 3rd party tools. XML can also be easily generated using simple text manipulation or with more advanced XML tools; Open & Non-proprietary. XML is defined by open-standards bodies and can be easily extended to new domains or message types. XML is non-proprietary and is not tied to any particular implementation, product or vendor. This promotes interoperability within the EMCS operating environment. Multiple character sets support. XML supports multiple character sets and in particular UTF-8 that will be used to address multilingualism issues (see 4.3.3 Multilingualism). Embedding binary data. XML supports embedding of binary data for the cases where images or documents need to be embedded within the EMCS Messages (see 4.3.4 ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 51 of 91
Embedding binary data). The EMCS-XML format is defined using XML Schema and XML namespaces. An XML Schema permits a fine-grained validation over message contents for example, validating the format of dates or Excise Numbers. Namespaces provide a method for organising the element definitions into packages of related information. This approach makes the collection of element definitions more maintainable and also avoids any potential naming conflicts. The EMCS-XML message grammars is defined in the DDNEA, along with a more detailed discussion of the design principles used to build the message formats. 4.3.2 EMCS Message Structure EMCS messages are structured in a way that must be considered at infrastructure level, application level and business level. 4.3.2.1 Infrastructure Level At this level, the message structure and format depend on the communication channel used to transport the information. The EMCS in the Common Domain supports three different message formats at the infrastructure level: CCN Asynchronous transport services aiming at direct machine-to-machine communication (see 3.3 CCN/CSI Services). HTTP providing the underlying message format for Web Services. CCN Intranet (see 3.4 CCN Intranet Services) is used to rely HTTP traffics. SMTP supported by the CCN Mail II Services (see 3.5 CCN Mail 2 Services) offering standard SMTP-based e-mail exchanges. 4.3.2.2 Application Level (EDA) At this level, the message (see 5.4.6 Message Definition at Application Level) must encompass all the elements required to satisfy the reliability of the exchanges between applications (coordination, exception handling, security, etc.). Figure 33: EMCS Message Structure (EDA) EMCS-XML-AL is used for the CCN/CSI and CCN Mail 2 Information Exchanges. 4.3.2.3 Application Level (Web Service) EMCS-SOAP defines the envelope and the error report. It is used for the Information Exchange with the Web Services deployed centrally. The SOAP format is defined using WSDL, XML Schema and XML namespaces. The SOAP message grammars is defined during low-level design, along with a more detailed discussion of the design principles used to build the message formats. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 52 of 91
Figure 34: EMCS Message Structure (Web Service) Note: SOAP has been selected because the support of WS-Security is needed should message level security be applied (e.g. field encryption, digital signature). REST does not support it. Moreover SEED communication channels already use SOAP in SEEDv0. 4.3.2.4 Business Level At this level, the EMCS-XML-BL message (see 5.3.3 Message Definition at Business Level) must comply with the rules described in the Functional Excise System Specifications (see FESS [R4] Appendix D: Functional Messages). It participates in the execution of the business processes by including all the functional attributes required to exchange the information between actors. 4.3.3 Multilingualism The multilingual aspect of the exchanges mainly concerns the messages at the business level. 4.3.3.1 Character Set By the usage of the UTF-8 encoding for the EMCS-XML message format, all the languages of the European Union are supported in EMCS. The UTF-8 encoding is defined in ISO 10646-1:2000 Annex D and also described in RFC 3629 as well as section 3.9 of the Unicode 4.0 standard. In addition, the functional message format defines some explicit elements in which language specific content can be encapsulated, including an identifier for the language used to express the content (see FESS [R4] Appendix D: Functional Messages). It is then possible to send or receive EMCS-XML messages with more than one translation of language dependant content. 4.3.3.2 Searching Issue One important issue that needs to be covered by EMCS is the capability to search and to retrieve messages in regard to multilingual aspect. For that purpose, a mature specification is available: ICU - International Components for Unicode (http://www.ibm.com/software/globalization/icu/). This Open Source solution is sponsored, supported and used by IBM and many other companies. ICU provides a set of C/C++ (ICU4C) and Java (ICU4J) libraries for Unicode support, software internationalisation and software globalisation. These libraries are widely portable to many operating systems and environments. Some of the services that ICU provides are the following: Text. Unicode text handling, full character properties and character set conversions. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 53 of 91
Comparison. Language sensitive collation and searching. Transformations. Normalization, upper/lowercase, script transliterations. Locales. Comprehensive locale data and resource bundle architecture. Complex Text Layout. Cyrillic, Hebrew, Arabic and Thai. Time. Multi-calendar and time zone. Formatting and Parsing. Dates, times, numbers, currencies, messages and rule based. Regarding EMCS requirements, ICU implements a search string algorithm that is languageaware. For example, this feature takes into account the following issues: Accentuated characters. To treat the accentuated characters depending on the language used. Conjoined letters. A single letter is treated equivalent to two distinct letters and vice versa. Ignorable punctuation. The user is able to choose to ignore punctuation symbols. Note: Refer to Section I, 4.3.3.2 The System for Exchange of Excise Data (SEED) where the application requirement regarding searching and sorting facilities is formalised. 4.3.4 Embedding binary data The Functional Excise System Specifications (see FESS [R4] Appendix D: Functional Messages) defines messages that may contain embedded images or documents. To support this requirement, binary-encoded data shall be used to embed images or documents in the EMCS-XML Message Format. The file format of binary embedded data should be limited to two specific standards based file formats: Joint Photographic Experts Group (JPEG) for images. Portable Document Format (PDF) version 1.4 for documents. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 54 of 91
5 EMCS Common Domain Interface Specifications 5.1 Introduction The EMCS Common Domain Interface is implemented by the EMCS Common Domain Service Bus. The main objective of the EMCS Common Domain Service Bus is to provide the necessary functionality to support EMCS requirements in the Common Domain. According to the identified architectural levels (see 2.2 Architectural Levels), the EMCS Common Domain Interface is modelled at three levels (Figure 35): Business Level. Represents the end-point from which the Business Processes Orchestration can be achieved (see 5.3 Business Process Orchestration). The EMCS Business processes are distributed, involving independent actors, each one responsible for the correct implementation of the functional specifications in his domain. The major objective for the Common Domain Interface at this level is to control the Business Process Flows in the Common Domain between the actors without implementing central business process coordination. In EMCS, each actor takes part in the business coordination in a distributed and collaborative way also called Business Process Choreography. Application Level. Represents the end point from which the Exchange Coordination can be achieved. The protocol that must be established between applications insures that the business process choreography is correctly supported exempting it from the management of exceptions occurring at lower levels (see 5.4 Application Flow Control). Application level is also responsible for message validation (see 5.4.2 Message Validation). Infrastructure Level. Represents the end-point from which the message interchange through the CCN Network can be technically achieved. It encompasses the implementation of the various communication protocols (CSI, HTTP and SMTP) that CCN provides (see 5.5 Message Routing). ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 55 of 91
Figure 35: EMCS Common Domain Service Bus Interface Particular attention is also given to the Exceptions Handling (see 5.6 Exception Handling), which makes possible business as well as technical compensation following the detection and the notification of exceptions. By segmenting the interface as explained previously, the EMCS Common Domain Service Bus provides flexible implementation that anticipates business changes. Indeed, while we can consider stable the implementation at infrastructure and application levels, the EMCS Business Processes are subject to evolutions independently of the underlying technology. 5.2 EMCS Business Interaction Paradigms [BIP] According to the various use cases described in the FESS [R4], communicating parties can interact using three paradigms: [BIP-1W] One-way Business Interaction where no immediate business response is expected (e.g. the dissemination of the e-ad in the UC2.01). However, according to the FRS [R7] ( 4.1.6 DP06: Business acknowledgement), a business acknowledgement must be performed for some information exchanges (see FRS [R7] Appendix B) ensuring that the recipient effectively processed the exchanged information. This requirement is implicitly covered by the coordination protocol at application level that applies to all exchanges, which will be further defined in the DDNEA. If it is felt necessary to have a specific business acknowledgement, then the FESS should be amended to include the specification of a new IE Message implementing an explicit individual business acknowledgment. This explicit business acknowledgement would take part in the Business Process Choreography and would be integrated in the Business Process Management according to each use case that requires it. In any case, the business acknowledgement consists of another One-way Business Interaction and consequently ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 56 of 91
does not imply that the original issuer waits for it before continuing the execution of the Business Process on his side. [BIP-2W] Two-way Business Interaction where a business response is expected within a short timeframe (e.g. request update of SEED in UC1.16). In this case, the business acknowledgement is implicitly performed by the receipt of the business response (see [PR2] class of response time in TESS Section I). At application level, this business interaction may involve synchronous (Request/Response) or asynchronous communications. In the latter case, the communication management requires a stateful process. [BIP-H] Human Interaction, which is similar to the 2-way business interaction paradigm except that one (or both) communication parties is (are) human. Typical human interactions are: [BIP-H2M] Human-to-Machine. This addresses human using an interactive interface (request/response). This type of interaction requires a more stringent class of response time (see [PR1] class of response time in TESS Section I) limited to a couple of seconds at the maximum. In some cases, where the processing can take a long time (more than the excepted limit of response time), the human interaction may involve an asynchronously communication. In this case, the response is temporarily stored and the user is notified or the result is asynchronously returned using another communication channel providing such a capability (e.g. CCN/CSI or email). [BIP-H2H] Human-to-Human. This addresses typically interpersonal messaging system (i.e. e-mail exchanges). ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 57 of 91
5.3 Business Process Orchestration 5.3.1 Introduction At the Business Level, the interface deals with the execution of the EMCS Business Processes as described in the Functional Excise System Specifications (FESS [R4]). Controlling those business process executions is vital for the good functioning of EMCS. Moreover, EMCS business processes involve multiple actors, each being responsible for the good execution of the business process in his domain. The aim is to enforce the synchronisation of the distributed process contexts in order to ensure that all actors have the same view on the progress (state) of the business process execution. In the FESS [R4], the business processes are defined in two combined ways: Process Flow Diagrams specify the sequence of Elementary Business Processes (EBP) executions and the exchanges occurring between them (Information Exchanges, also defined as functional messages in the FESS [R4]). State-transition Diagrams specify the possible states of the business process in each domain and the way transitions can occur according to the incoming or outgoing messages. 5.3.2 Business Orchestration vs. Business Choreography From the perspective of executing business processes, the composition of Elementary Business Process (EBP) can be combined in two ways: Orchestration. In orchestration, which is used in business processes confined to one domain, a central process takes control of the involved services and coordinates the execution of different operations on the services involved in the operation. The involved services do not "know" (and do not need to know) that they are involved in a composition process and that they are taking part in a higher-level business process. Only the central coordinator of the orchestration is aware of this goal, so the orchestration is centralized with explicit definitions of operations and the order of invocation of services. For example, the submission of the draft e-ad involves the execution of an ordered sequence of Elementary Business Processes (EBP) or services triggered by an incoming message from the External Domain. This includes in particular the validation and the safe storage of the e-ad, the submission of the validated e-ad to the MSA of destination and the activation of the risk assessment. Choreography. Choreography, in contrast, does not rely on a central coordinator. Rather, each service involved in the choreography knows exactly when to execute its operations and with whom to interact. Choreography is a collaborative effort focusing on the exchange of messages in public business processes. All participants in the choreography need to be aware of the business process, operations to execute, messages to exchange, and the timing and sequencing of message exchanges. Typically, those exchanges occur using the One-way Business Interaction [BIP-1W] paradigm. However in some cases, it is important for the EMCS business that the sending application of a given Information Exchange has a confirmation that the recipient application correctly received and processed that exchange (see FRS [R7] 4.1.6 DP06: Business acknowledgement). To address this issue, the exchange must be submitted to a ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 58 of 91
business acknowledgement. In particular, business acknowledgement is mandatory for the information exchanges where state conflicts are possible: to inform the sending application, for whatever purpose, that the conflict will not arise (see FRS [R7] 5.2 Automatic resolution of e-ad state conflicts and 5.3 Resolution of e-ad state conflicts following human decision concerning state conflicts, and Appendix B providing the list of the Information Exchanges to be covered by a business acknowledgement). According to those definitions, Business Choreography only deals with inter-domain exchanges (i.e. involving parties belonging to different responsibility domains) while Business Orchestration deals with intra-domain exchanges (see Figure 36). Figure 36: Business Orchestration vs. Business Choreography Therefore, since the EMCS Common Domain Interface is only involved in inter-domain exchanges (see Figure 37), only Business Choreography issues are addressed in TESS Section II (see 5.4.1 Introduction). Business Orchestration issues are developed in TESS Section IV Standard Excise Application Architecture. Figure 37: Common Domain Service Bus Interface at Business Level ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 59 of 91
5.3.3 Message Definition at Business Level At business level, the message contains business information required by the related business process transaction. The functional definition of the messages is described in the FESS [R4] Appendix D including the structure, the element data types, the rules and conditions. This constitutes the body part of the business message. XML Schema is used to implement the specifications and prevent syntactic errors. Figure 38: Message Definition at Business Level The business message header is simple since all required information at business level is already included in the message body. Table 6 describes the content of the message header that only aims at identifying the Information Exchange (IE). Version IE identifier Identify the Business Message Version Identify the Functional Message Type as listed in the FESS [R4] - Section D Table 6: Message Header at Business Level ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 60 of 91
5.4 Application Flow Control 5.4.1 Introduction The main objective of the Application Flow Control is to discharge the business level (Business Orchestration, see 5.3) from the reliability of the exchanges between involved parties by applying the principle of Fire and forget. From a business point of view, when information is sent to a partner (e.g.: dissemination of a validated e-ad), the use cases described in the Functional Excise System Specifications (FESS [R4]) do not take into account the technical aspects of the exchanges and consequently do not require acknowledgements. They assume that the information is finally delivered to the target service and it is processed. However, some incidents can occur during the transport or the processing of the messages. Therefore, EMCS architecture should apply measures insuring the reliability of the exchanges using the QoS offered by the CCN/CSI infrastructure (see 3.3.4 Quality of Service (QoS)) and additional measures at application level allowing the prevention, the detection and the recovery of failures. Figure 39: Common Domain Service Bus Interface at Application Level According to the above definition of choreography (see 5.3.2 Business Orchestration vs. Business Choreography), the interface of the Common Domain Service Bus deals with incoming and outgoing messages. Those messages are exchanged on the Common Domain with other MSAs (National Excise Applications) or with the central services (Central Excise Applications). At the application level, the interface is used locally to implement the inter-domains exchanges in a controlled way. The Application Flow Control intervenes between the business process and the infrastructure by providing the following features: Message Validation providing prevention and detection measures regarding exceptions at syntactic level (see 5.4.2 Message Validation). Coordination Protocol providing prevention and detection measures regarding ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 61 of 91
exceptions at Business Process Choreography level (see 5.4.3 Coordination Protocol). Logging making possible production of statistics at various levels (see 5.7 Logging). Monitoring making possible the awareness of unavailable services (see 5.4.4 Monitoring). Security implementation, in particular regarding the confidentiality and the integrity of the exchanges (see 5.4.5 Security). 5.4.2 Message Validation According to the FRS [R7] (IEX030 and 4.2.3 AP03: Reject information exchange), it must be possible to verify the syntax of all incoming information interchanges. Syntactic checks should include, at a minimum: Compliance with technical syntax and message structures. Since the supported message format in the Common Domain is based on XML (see 4.3.1 EMCS-XML Message Format), all messages are specified using a well-defined and rigorous XML Schema message grammar. This grammar ensures that messages are valid and in conformance with the message specifications. This preventive measure should be taken also at the sender s side for all outgoing information exchanges. This prevents ineffective exchanges. Compliance with the rules and the conditions specified in Appendix D of the FESS [R4]. Resources of applications are finite and processing of incoming messages has a threshold size limit. Depending on the system resources and the size of very large messages, applications may become unresponsive or even fail abruptly. Such exceptional cases hinder business continuity, hence messages exchanged over the Common Domain must not exceed a certain size limit. The threshold size limit of messages exchanged over the Common Domain is set to 21 Mbytes (2 20 bytes). Applications should not send messages over the Common Domain exceeding the threshold size limit. According to FRS [R7] ( 4.2.3 AP03: Reject information exchange), if an information interchange is illegible due to exceptions at syntactic level, this information exchange is rejected. An advice of non-acknowledgement (NACK) is then returned to the sender, to warn him about the rejection and its motives. Non-acknowledgement (NACK) should also be returned to senders of messages exceeding the threshold size limit. 5.4.3 Coordination Protocol A major part of the EMCS exchanges, especially regarding the core business, uses the CCN/CSI asynchronous paradigm in order to offer loosely coupled exchanges in the Common Domain. But in this context, potential incidents could occur between the submission of a message and its processing by the remote application. The Coordination Protocol provides preventive measures at application level avoiding incoherence at business level with the following major objectives: To significantly reduce the levels of inconsistent states in the NEA movement databases. To avoid message loss. To detect anomaly as soon as possible and consequently quickly trigger fallback and recovery procedures. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 62 of 91
To simplify the exception handling procedures (see 5.6 Exception Handling) and make sure to be able to execute compensations until the right state is restored. The Coordination Protocol consists of the combination of following mechanisms: Preventive Message Queuing insuring further recovery (see 5.4.3.1 Preventive Message Queuing). Message Sequencing insuring the ordered transmission and processing of submitted exchanges (see 5.4.3.2 Message Sequencing) using a State Machine (see 5.4.3.3 State Machine). Infrastructure Acknowledgment Mechanism Implementation insuring the delivery of message at the application level (see 5.4.3.4 Infrastructure Message Acknowledgment Implementation). 5.4.3.1 Preventive Message Queuing According to the FRS [R7] ( 4.1.5 DP05: queue message preventively for further automatic recovery), because successful transfer of an Information Exchange is considered of high importance for the complete achievement of an EMCS business process, the sending application securely stores it prior to dispatch in order to be able to re-send it in the case where the Information Exchange would abort. Such a queuing mechanism is mainly a preventive measure aiming at avoiding loss of messages in case of infrastructure unavailability, but also it is closely linked to the exception handling (see 5.6 Exception Handling) and recovery processes following detections of exceptions by the sequencing mechanism (see 5.4.3.2 Message Sequencing) described below. 5.4.3.2 Message Sequencing Message sequencing consists of regulating the exchanges between two parties concerning a particular business process instance. This feature supports the good execution of the Business Process Choreography by preserving and controlling the legal sequences of business operations. It guarantees that all IE messages are processed in the right order by the receiver, as expected at business level. Sequencing mechanism addresses: Preventive measure to prevent switching in the ordered transmission of exchanges between two parties and related to the same business process instance. Indeed, CCN QoS (see 3.3.4 Quality of Service (QoS)) does not guarantee the ordered delivery of asynchronous exchanges. This issue is particularly significant when unavailability occurs at the infrastructure level. In such a case, messages are queued by CCN until the availability of the failed equipment is re-established and probability exists that switching in the ordered delivery of messages occurs. Sequencing mechanism is taken in charge by the sender. To achieve that, the sender dispatches a message not more than one per second to the same destination. Indeed, each CCN/CSI message is time stamped with a precision limited to the second. The control of the message transmission sequence can be achieved using this feature providing the best way to know in which order the messages were transmitted. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 63 of 91
Note: A specific requirement regarding the message time stamping should be addressed to the CCN/TC in order to increase the precision of this information (e.g. millisecond). This will avoid the implementation of such preventive measure. Detection measure to control the legal sequences of exchanges between two parties and related to the same business process instance. This control is insured by a state machine (see 5.4.3.3 State Machine) that has the knowledge of the exchange sequences but only regarding inter-domains exchanges, i.e. the Business Process Choreography. 5.4.3.3 State Machine The state machine only implements a part of state-transitions defined in the FESS [R4] since this later specifies also the business process orchestration (see 5.3.2 Business Orchestration vs. Business Choreography) that is out of the Common Domain scope. The state machine (see 5.4.3.3 State Machine) can determine the state-transition to be activated thanks to the following information: The process instance identification also called Correlation Id. For example, for core business use cases, the Correlation Id should be the AD Reference Code (ARC). If when receiving a message there is not a process instance corresponding to the Correlation Id (i.e. an existing e-ad), a new instance of the process is created. The Information Exchange type. It is the main information that allows determining the state-transitions. For example, IE801 indicates that a new movement has been triggered and validated while IE810 indicates that a movement has been cancelled. The exchange direction. For example, if an IE801 is received from the National Domain, this indicates that the concerned actor must be the MSA of Dispatch (matching the country code in the ARC). Else, if the message is received from the Common Domain, this indicates that the concerned actor must be the MSA of Destination. The Actor s Role. When a process is instantiated, the exchange direction allows determining the role of the concerned actor (see above). Consequently, different statetransition diagrams are applied. The current process state. Depending on the role of the concerned actor (e.g.: MSA of Dispatch or MSA of Destination), the current process state allows determining which state(s) could be set and consequently which Information Exchange type(s) could be considered. For example, at dispatch, the Waiting for replacement state can only lead to the Cancelled state (when submitting IE810) or Replaced state (when submitting IE803). In some cases, additional message attributes are required. For example, IE818 (report of receipt) or IE819 (warning or refusal) are subject to different state-transitions according to respectively the Global Conclusion of receipt (Rule046) or the Consignment Refused flag (Boolean: Rule004). Consequently, it is possible to find out if an incoming or outgoing message is legal according to the state of the process. If it is not the case, an exception must be triggered and managed (see 5.6 Exception Handling). ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 64 of 91
Process Instantiation Each process should have a Correlation Id identifying it without ambiguity (e.g.: ARC). Each exchange must identify the Correlation Id in order to determine which process instance is concerned. When receiving a message, if the Correlation Id does not identify an existing process instance, a new one is created. At this time, the role of the concerned actor is determined according to the Information Exchange type and direction. The actor s role identifies a composite state that establishes the behaviour of the state machine. At this stage, it is possible to identify an unknown ARC. This is the case where a received information interchange refers to an ARC that is not known to the receiver (unknown Correlation Id) and that does not constitute a new e-ad (i.e. IE801). According to the FRS [R7] ( 3.1.3.1 Unknown ARC), this could result from preceding error (the e-ad did not reach the receiver) or mistake (wrong ARC has been input). Figure 40 gives for example relating to the management of an e-ad. Process Control Figure 40: Coordination Protocol - State Machine: Process Instantiation When a process is instantiated some events can occur under the form of incoming and outgoing Common Domain messages. The management of those transitory messages must be performed by a state machine according to the authorised state-transitions as defined in the FESS [R4]. Again, only the part of the specifications concerning the exchanges on the Common Domain is taken into account here. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 65 of 91
Figure 41: Business Process Choreography: State-transition Diagram of e-ad at Dispatch Figure 41 gives an example relating to the management of the events concerning an e-ad at MSA of Dispatch. This example shows how the state-transition diagram defined in the FESS [R4] can be reduced and adapted to consider only the Common Domain exchanges. Figure 42 shows another example related to the management of the events concerning an e- AD at MSA of Destination. Figure 42: Business Process Choreography: State-transition Diagram of e-ad at Destination 5.4.3.4 Infrastructure Message Acknowledgment Implementation The infrastructure message acknowledgement mechanism is implemented differently according to communication protocol that is used: CSI-based exchanges: For the issuing application, the acknowledgement is a guarantee that the message has been delivered. This is achieved thanks to the QoS of CCN, which provides Confirmation of Delivery (CoD, see Infrastructure Protocol 3.3.4.2 Infrastructure Protocol) at infrastructure level guaranteeing that the recipient MSA application has correctly received the IE Message sent by the originator MSA application. Thanks to the message preventive queuing mechanism described above (see 5.4.3.1 Preventive Message Queuing), a message can also be re-submitted in ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 66 of 91
case of exception at the infrastructure level (Exception Report, see 3.3.4.2 Infrastructure Protocol). SMTP-based exchanges: SMTP conversations take place between either a mail client and mail server or mail servers (i.e. between two LCMS or between an LCMS and a national MTA). In short, there are three steps to SMTP mail transactions. The transaction is started with a MAIL command, which gives the sender identification. A series of one or more RCPT commands follows giving the receiver information. Then a DATA command gives the mail data. And finally, the end of mail data indicator confirms the transaction. If accepted, the receiver-smtp returns a 250 OK reply (equivalent to a CoA for CSI-based exchanges). The DATA command should fail only if the mail transaction was incomplete (for example, no recipients), or if resources are not available. In this case the receiver-smtp returns a 550 Failure reply (equivalent to an Exception Report for CSI-based exchanges). SMTP does not natively provide CoDequivalent mechanisms. This feature is however implemented by many mail clients under the form of Read Receipt reports but cannot be considered as part of the infrastructure protocol. HTTP-based exchanges: HTTP messages consist of requests from client to server and responses from server to client. A request message from a client to a server includes, within the first line of that message, the method to be applied to the resource (e.g. GET, POST), the identifier of the resource, and the protocol version in use. After receiving and interpreting a request message, a server responds with an HTTP response message containing a Status-Code element (e.g. 200 OK, 403 Forbidden, 500 Internal Server Error) that can be interpreted by automatic processes on client side so as to apply technical compensation. An HTTP response message can therefore be considered as a way to acknowledge the reception of an incoming HTTP request. 5.4.4 Monitoring The EMCS Common Domain Service Bus (see 4.2 EMCS Common Domain Service Bus) must be monitored in order to detect quickly any system unavailability. The application platform supporting the system, and in particular the EMCS Common Domain Adapter (see Chapter 6 EMCS Common Domain Adapter Specifications), must provide such facilities (e.g. JMX - Java Management Extensions). The software components must regularly notify the monitoring module about their availability. Inversely, the monitoring system must regularly test the availability of the software components. As soon as unavailability is detected, the monitoring system must submit an alert to the national operational team. According to the FRS [R7] (ORG050), when operational problems visible at international level are detected, a communication mechanism must exist and related defined procedures be followed to inform all concerned parties of service(s) unavailability. The FESS [R4] (UC0.07) defines the way to inform about unavailability. It consists of the submission of the information to the CS/MIS (see TESS Section III EMCS Central Services Architecture), which is in charge of the broadcasting through all the concerned parties. The application level, and the related Application Flow Control (see 5.4 Application Flow Control), is in charge of this task. It assists in the notification of alerts, submitting them to the CS/MIS, if possible (i.e. if the required communication channel is available). ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 67 of 91
Ident ity DG TAXUD EXCISE COMPUTERISATION PROJECT 5.4.5 Security At the application level, some security requirements (expressed in TESS Section I, 4.7 EMCS Security Requirements) must be implemented in order to satisfy security at business level. Regarding the Common Domain, only information exchanged through the CCN network is considered. At this level (infrastructure), some security measures already exist. However, if other security measures must be taken (e.g. confidentiality or integrity), the application level is the right place to implement them. Indeed, it is located between the business level, where business processes should be discharged from this technical issue, and the infrastructure level, consequently not providing what is expected. Note: The detailed security specification is provided in the SESS. 5.4.6 Message Definition at Application Level At application level, the message header contains information required for the coordination protocol (see 5.4.3 Coordination Protocol) and the Application Flow Control in general (see 5.4 Application Flow Control). The message body, normally encrypted, exclusively includes the business message (see 5.3.3 Message Definition at Business Level). Figure 43: Message Definition at Application Level The message takes into account the following requirements: Routing. Information to unambiguously identify the sender and the recipient of the message. Sequencing mechanism. To ensure the ordered processing of submitted exchanges (see 5.4.3.2 Message Sequencing). Routing and correlation information needs to be inserted in the message in order to identify the context in which the state machine (see 5.4.3.3 State Machine) must occur. Exception Handling (see 5.6 Exception Handling). Information about the nature of the error in order to adequately trigger compensation. Security. If message-level protection is to be applied, contains the digital signature applied to SHA1 digest of the message fields to be protected and the sender s X.509 digital certificate, which contains the public key that allows the receiver verifying the enclosed signature. Table 7 describes the content of the message header and its purposes. Version Type Identify the Technical Message Version Identify the Technical Message Type (e.g.: IE or NACK) ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 68 of 91
Security Information Correlati on Routing DG TAXUD EXCISE COMPUTERISATION PROJECT UID Sender Recipient Timestamp Correlation Id Unique identifier of the message Identify the sender Identify the final recipient Identify the time the message was submitted. Identify the Correlation Identifier (e.g., the ARC) Related Exchange Id For IE: the IE identifier (e.g.: IE801) Error code Description Certificate For NACK: the rejected exchange UID. In case of NACK, the identifier of the error type that should distinguish semantic exceptions from syntactic or technical exceptions. Public description of the message (free text) including for NACK the readable reason of the error. Sender s X.509 Certificate Signature Digital signature Table 7: Message Header at Application Level ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 69 of 91
5.5 Message Routing At the Infrastructure Level, the interface deals with technical exchanges. It makes transparent for the higher levels (business and applications levels) the underlying technical requirements needed to achieve the information exchanges. It implements the Infrastructure Communication Channels (ICC, see 2.5 Infrastructure Communication Channels [ICC]) on which the Common Domain related Business Communication Channels (see 2.4 Business Communication Channels [BCC]) are based. Figure 44: Common Domain Service Bus Interface at Infrastructure Level In addition to the transport service itself, the Common Domain Service Bus must provide the following features at infrastructure level: Logging. Activities regarding the infrastructure protocols must be logged by the CCN logging system and regularly submitted by the CCN/TC to the CS/MIS for publication. Monitoring. Monitoring the Common Domain Service Bus in order to ensure high availability is vital regarding its position in the architecture. The CS/MIS must be notified without delay for any unavailability. Security. The infrastructure level must be trusted regarding the confidentially and the integrity of all information exchanged through the trans-european network. It must discharge all upper architectural levels from this issue, at a maximum. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 70 of 91
5.6 Exception Handling Whereas the Business Process Orchestration (see 5.3 Business Process Orchestration) and the Application Control Flow (see 5.4 Application Flow Control) provides prevention measures and exceptions detection, the resolution of the trapped exceptions are addressed by administrative and/or fallback and/or recovery procedures. According to the Fallback and Recovery Specifications (FRS [R7] 2.1 Exceptions identification and qualification), the exceptions considered at the Common Domain level have an International Business Impact because they affect the EMCS business in at least two Member States. As defined in the FRS [R7] (Chapter 3 Exceptions typology), exceptions happen at three levels: Figure 45: Exception Handling Physical: failure of the communication medium itself, or loss of the information to be exchanged. This is identified at the Infrastructure Level. For example, reason code and exception reports of CCN/CSI calls are used for CCN/CSI errors (see 3.3.4.2 Infrastructure Protocol). HTTP error codes are used for Web-based transport. Syntactic: the information interchange is written in such a way that the receiver cannot decipher it. This is identified at the Application Level. They are detected during the message parsing (see 5.4.2 Message Validation) when an Information Exchange is not well formatted. Format errors may be notified by the format layer (WSDL) or notified by a specific NACK message. Semantic: the content of the information interchange does not have any business signification to the receiver. This is identified at business level by the Business Process Orchestration (see 5.3 Business Process Orchestration) and addresses the following types of exceptions: Information refers to an ARC that is not known to the receiver. Transmitted information does not correspond with the current state of the movement. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 71 of 91
Transmitted information contains information that is not coherent with other movement data already available to the receiver. According to the FRS [R7] ( 3.1.3.2 Incorrect state), if data received about a movement are not compatible with the current state of this movement, the exception can result from: Mistake of the sender. This could be avoided if all parties implement correctly the Business Process Choreography in particular regarding outgoing messages since it should be detected before transmitting any message on the Common Domain. Sequencing error. However, this could be avoided by the good implementation of the Coordination Protocol and in particular the associated message sequencing mechanism (see 5.4.3.2 Message Sequencing). Bad communication between economic operators. This is out of scope of the Business Process Choreography in the Common Domain since it concerns the External Domain. According to FRS [R7] ( 4.2.3 AP03: Reject information exchange), if an information interchange is illegible due to exceptions at Business Process Choreography level, this information exchange is rejected. An advice of the exception is then returned to the sender, to warn him about the rejection and its motives. Whatever its level, an exception has the same functional result: a failure of the information interchange. As shown in Figure 45, depending on the level of the exception, it is notified and reported to the dedicated functional element that is in charge of the exception handling. Several situations can be encountered to handle exceptions: Business Compensation that aims at performing activities at business level in order to reestablish the business process consistency (e.g. in case of state conflicts) according to the fallback and recovery procedures specified in the FRS (see FRS [R7] 2.2 Business responses to exceptions and Chapter 5 Specific business responses). Technical Compensation that aims at performing activities at technical level in order to apply fallback or recovery measures re-establishing the system in its nominal state (e.g. restart or replace unavailable components, re-synchronise reference data, re-submit message, etc.). In any cases, where an event cannot be processed according to the authorised statetransitions (see 5.4.3.3 State Machine), technical compensation must be triggered in order to re-synchronise the concerned process instance. At this level, processes are usually long-lasting (there could be days between 2 activities), they use asynchronous messages and interact with several different services. Introducing the concept of ACID transactions in this context is quite tough. Each of the services involved can locally use its own transaction but it is impossible to control them within the process. Therefore, compensation is basically a set of activities attempting to correct operations that have already been completed inside a unit of work. Consequently, it must be possible to act, automatically or manually, on the state machine (see 5.4.3.3 State Machine) that governs the coordination and specify the set of activities that must compensate the detected exception. Automatic Compensation. Sometimes, compensations can be performed automatically. At business level, it consists in the automatic resolution of state conflicts (see FRS 5.2 ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 72 of 91
Automatic resolution of e-ad state conflicts). At technical level, it can consist of the automatic re-submission of failed or non-acknowledged exchanges (see 5.4.3.4 Infrastructure Message Acknowledgment Implementation). Manual Compensation. In some cases, compensations require human interventions. At business level, it consists mainly of the resolutions of state conflicts following business decisions (see FRS [R7] 5.3 Resolution of e-ad state conflicts following human decision and 4.2.6 AP06: Take a business decision). FRS [R7] considers also internal (posterior) controls (AP05) that lead to the detections of exceptions resulting from fraud or fraud attempt and consequently require manual compensations. When manual compensation is required, appropriate notification (typically using e-mail) should be submitted to individual(s) in charge of the system support (see FRS [R7] 4.2.7 AP07: Transfer issue to support). Assistance could be provided to those people by making available on-line documentation describing the actions to be taken in such cases (e.g. online FRS). 5.7 Logging All the activities at the EMCS Common Domain Service Bus level (see 4.2 EMCS Common Domain Service Bus) must be recorded, including: Business transactions, which typically occur at the business level where the Business Process Orchestration (see 5.3 Business Process Orchestration) is performed. For each transaction, the following information must be logged: The date and time. The type of transaction (i.e. business, application, infrastructure of exception handling). The entity identifier (e.g. AD at business level, ACK at the application level, etc.) The entity key(s) (e.g. ARC at business level, message UID at application level, etc.). Change of state associated with related key information (e.g. state of the business process at business level, state of the coordination protocol at the application level, etc.). Identification of software component that executed transaction. Identification of the actor who initially triggered the concerned transaction. Possible additional comments including the description of the problem. Application transactions, which typically occur at the application level where the Application Flow Control (see 5.4 Application Flow Control) is performed. This is implicitly performed by the Preventive Message Queuing (see 5.4.3.1 Preventive Message Queuing). Infrastructure Transactions, which typically occur at the infrastructure level where the Message Routing (see 5.5 Message Routing) is performed. Exception Handling, (see 5.6 Exception Handling) which typically occurs when compensations are triggered. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 73 of 91
During exception handling, and in order to assist the help desk in its task and the developers in the software maintenance, it should be helpful to provide the following additional information: The date and time at which the problem appeared. Category of the problem (i.e. business, application or infrastructure). Identification of software component that identified the exception. The actions taken in case of automatic compensation (see 5.6 Exception Handling). The date and time at which the actions was taken. Possible additional comments, including a description of the problem. This should ease the implementation of error handling and the reporting of statistics for problem analysis. It is under the sole responsibility of the sender of information to check the correctness and take adequate measures of compensation (see Exception Handling in 5.6 Exception Handling). The analysis of this information should provide: Statistics at the various architectural levels that must be submitted to the CS/MIS (see TESS Section III) according to FESS [R4] (Section III Management of statistics). Audit Trail allowing the follow-up of the EMCS activity and assist the system tuning according to FESS [R4] (Section V UC0.25). Problem Tracking to assist the manual compensations (see 5.6 Exception Handling) and the help desk staff according to FESS [R4] (Section V UC0.26). ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 74 of 91
6 EMCS Common Domain Adapter Specifications 6.1 Introduction The EMCS Common Domain Adapter implements the required interface of EMCS Common Domain Service Bus (see Chapter 5 EMCS Common Domain Interface Specifications). To achieve that, it encompasses a series of components dedicated to specific architectural levels: Business Level. At this level, the adapter is in charge of the execution of the Business Process Choreography (see 5.3 Business Process Orchestration). The Business Process Execution Engine (see 6.2.1 Business Process Execution Engine) implements the detection and prevention measures at semantic level. Application Level. At this level, the adapter is in charge of the Application Flow Control (see 5.4 Application Flow Control). The Flow Control Engine (see 6.2.2 Flow Control Engine) mainly manages the Coordination Protocol including preventive message queuing, sequencing and acknowledgment. It implements also other detection and prevention measures such as message validation at syntactic level, logging and monitoring. Moreover, security requirements including confidentiality and integrity are also implemented at this level. Infrastructure Level. At this level, the adapter is in charge of the Message Routing (see 5.5 Message Routing). The Common Domain Relay (see 6.2.4 Common Domain Relay) manages the messages exchanged through the CCN Network and provides detection and prevention measures including logging and monitoring. Figure 46: EMCS Common Domain Service Bus Adapter Moreover, according to the exception handling described in 5.6 Exception Handling, it ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 75 of 91
makes sense to isolate activities related to business and technical compensations in a dedicated component, the Exception Handler (see 6.2.3 Exception Handler). 6.2 EMCS Common Domain Adapter Architecture Figure 47 depicts the various EMCS Common Domain Adapter components, their interactions and the relaying parties. It indicates also the location of each component in the domains of responsibility, i.e. the place where they must be deployed. Figure 47: EMCS Common Domain Service Bus Adapter Architecture The adapter is an extension of the Common Domain infrastructure (CCN), logically represented by the Common Domain Relay. The Common Domain Relay is the only part of the adapter that is deployed in the Common Domain, and more specifically in the National Domain Connection Point (NDCP, see 3.2.2 National Domain Connection Point (NDCP)). The other adapter components must be deployed in the National Domain and consequently operated by each MSA. This Section does not provide specification about the implementation of those components since it assumes that they will be developed by each MSA in the context of a Nationally Developed Excise Application (NDEA). However, TESS Section IV provides solutions for MSAs, which are currently operating the NCTS MCC. Consequently, the following sections only provide recommendations for the Standard Excise Application (SEA) architecture, which is further described in TESS Section IV. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 76 of 91
6.2.1 Business Process Execution Engine The Business Process Execution Engine is in charge of the Business Process Orchestration (see 5.3 Business Process Orchestration) required to fulfil the various EMCS Use Cases. It constitutes the interface between the National Excise Application, in charge of the implementation of the EMCS services at the national level (NEA), and the Flow Control Engine (see 6.2.2 Flow Control Engine), in charge of the technical coordination with other relying parties through the Common Domain. TESS Section IV describes in detail the architecture of the Business Process Execution Engine and the way it could be integrated. 6.2.2 Flow Control Engine The Flow Control Engine is in charge of the Application Flow Control (see 5.4 Application Flow Control). It constitutes the interface between the Business Process Execution Engine, in charge of the Business Process Orchestration, and the Common Domain Relay (see 6.2.4 Common Domain Relay), in charge of the technical communication with the other relying parties through the Common Domain. TESS Section IV describes in more details the architecture of the Flow Control Engine and the way it could be integrated. 6.2.3 Exception Handler The Exception Handler is in charge of the Exception Handling (see 5.6 Exception Handling). It constitutes the dedicated component for the execution of the business and technical compensations required after the detections and the notifications of exceptions. TESS Section IV describes in more details the architecture of the Exception Handler and the way it could be integrated. 6.2.4 Common Domain Relay The Common Domain Relay (see 3.2.3 Common Domain Relay) is in charge of the Message Routing (see 5.5 Message Routing) through the Common Domain Infrastructure (see Chapter 3 EMCS Common Domain Infrastructure) and the existing Infrastructure Communication Channels depicted in 2.5 Infrastructure Communication Channels [ICC]. Using the Value Added Services offered by CCN, it also provides the following features: Logging. The Common Domain Relay keeps a log of exchanged messages for relating an error occurring during the message transmission, and to solve any disputes regarding exchanged messages. The error handling system is based on the CCN reports and error codes generated by the CCN infrastructure protocol according to the QoS required at application level (see 3.3.4 Quality of Service (QoS)). This log shall at least contain: The content of the messages that have been exchanged (either sent or received); The timestamp showing at which date and time the IE message has been sent or has been received; The transport parameters of the IE message, CSI header, CCN reports and queue name for CCN/CSI; URL and HTTP status for HTTP-based transport. Monitoring. Refer to 3.2.5 Monitoring for information about the monitoring of the Common Domain Relay resources. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 77 of 91
Security. Refer to 3.2.1 Overview, 3.3.5, 3.4.4, 3.5.4 Security for aspects related to the Common Domain Relay security. More detailed information is also provided in the SESS. 6.3 EMCS Services Interfacing 6.3.1 Core Business Services Core Business Services (see FESS [R4] Section II) are only addressed using Business Communication Channel [BCC2] providing required interactions between the various NEAs. Figure 48: Core Business Services (BCC) Two types of interactions can occur on this channel: One-way Business Interaction where no business response is expected. This is performed using the following Common Domain Infrastructure Communication Channels: CCN/CSI Services (see 2.5.1 CCN/CSI Services) as the nominal channel. Figure 49: CCN/CSI Services: One-way Business Interaction (NEANEA) Email-based Interface (see 2.5.4 Email-based Interface) as fallback solution. Figure 50: Email-based Interface: One-way Business Interaction (NEA NEA) Two-way Business Interaction where a business response is expected. This is performed using the following Common Domain Infrastructure Communication Channels: CCN/CSI Services (see 2.5.1 CCN/CSI Services) as the nominal channel. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 78 of 91
Figure 51: CCN/CSI Services: Two-way Business Interaction (NEANEA) Email-based Interface (see 2.5.4 Email-based Interface) as fallback solution. Figure 52: Email-based Interface: Two-way Business Interaction (NEA NEA) 6.3.2 SEED Services SEED Services are addressed using the Business Communication Channels [BCC6] and [BCC7] and [BCC9]. Figure 53: CS/RD and CS/RD Services (BCC) Three types of interactions can occur on those channels: One-way Business Interaction that addresses the dissemination of SEED data (UC1.14) by the Central Services. This is performed using the following Common Domain Infrastructure Communication Channels: CCN/CSI Services (see 2.5.1 CCN/CSI Services) as the nominal channel. Figure 54: CCN/CSI Services: One-way Business Interaction (SEED NEA) ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 79 of 91
Email-based Interface (see 2.5.4 Email-based Interface) as fallback solution. Figure 55: Email-based Interface: One-way Business Interaction (SEED NEA) Two-way Business Interaction that addresses the following use cases: Submission of updates to the SEED register (UC1.14) by the NEA. Re-synchronization of SEED data (UC1.16). Consultation of central data (Economic Operators). This is performed using the following Common Domain Infrastructure Communication Channels: CCN/CSI Services as the recommended channel providing asynchronous interactions. Figure 56: CCN/CSI Services: Two-way Business Interaction (NEA SEED) Web Services as alternative channel providing synchronous interactions and asynchronous interactions. Figure 57: Web Services: Synchronous Two-way Business Interaction (NEA SEED) Figure 58: Web Services: Asynchronous Two-way Business Interaction (NEA SEED) ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 80 of 91
Email-based Interface as fallback solution providing asynchronous interactions. Figure 59: Email-based Interface: Asynchronous Two-way Business Interaction (NEA SEED) Human Interaction provided by the Web Interfaces of the Central Services. This addresses the following use cases: Maintenance of the Economic Operators register. Consultation, download and query of central data. 6.3.3 CS/RD Services Figure 60: Web Interface: Human Interaction (NEA SEED) CS/RD Services are addressed using the Business Communication Channels [BCC10], [BCC11], and [BCC12]. Figure 61: CS/RD Services (BCC) Three types of interactions can occur on those channels: One-way Business Interaction that addresses the dissemination of reference data (UC1.06) by the Central Services. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 81 of 91
This is performed using the following Common Domain Infrastructure Communication Channels: CCN/CSI Services (see 2.5.1 CCN/CSI Services) as the nominal channel. Figure 62: CCN/CSI Services: One-way Business Interaction (CS/RD NEA) Email-based Interface (see 2.5.4 Email-based Interface) as fallback solution. Figure 63: Email-based Interface: One-way Business Interaction (CS/RD NEA) Two-way Business Interaction that addresses the following use cases: Re-synchronization of reference data (UC1.05). Consultation of central data (Excise Offices and Reference data). This is performed using the following Common Domain Infrastructure Communication Channels: CCN/CSI Services as the recommended channel providing asynchronous interactions. Figure 64: CCN/CSI Services: Two-way Business Interaction (NEA CS/RD) ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 82 of 91
Web Services as alternative channel providing synchronous interactions and asynchronous interactions. Figure 65: Web Services: Synchronous Two-way Business Interaction (NEA CS/RD) Figure 66: Web Services: Asynchronous Two-way Business Interaction (NEA CS/RD) Email-based Interface as fallback solution providing asynchronous interactions. Figure 67: Email-based Interface: Asynchronous Two-way Business Interaction (NEA CS/RD) Human Interaction provided by the Web Interfaces of the Central Services. This addresses the following use cases: Maintenance of the Economic Operators register. Consultation, download and query of central data. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 83 of 91
6.3.4 CS/MIS Services Figure 68: Web Interface: Human Interaction (NEA CS/RD) CS/MIS Services are addressed using the Business Communication Channels [BCC19], [BCC20] and [BCC23]. Figure 69: CS/MIS Services (BCC) Those channels address the following use cases: Collection and consolidation of statistics (UC3.16) Manage scheduled unavailability (UC0.07) Three types of interactions can occur on those channels: The One-way Business Interaction that is performed using the following Common Domain Infrastructure Communication Channels: CCN/CSI Services as the recommended channel providing asynchronous interactions. Figure 70: CCN/CSI Services: One-way Business Interaction (NEA CS/MIS) ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 84 of 91
Figure 71: CCN/CSI Services: One-way Business Interaction (CS/MIS NEA) Email-based Interface as fallback solution providing asynchronous interactions for: Figure 72: Email-based Interface: Two-way Business Interaction (NEA CS/MIS) Figure 73: Email-based Interface: Two-way Business Interaction (CS/MIS NEA) Two-way Business Interaction that is performed using Web Services providing synchronous interactions and asynchronous interactions. Figure 74: Web Services: Synchronous Two-way Business Interaction (NEA CS/MIS) Figure 75: Web Services: Asynchronous Two-way Business Interaction (NEA CS/MIS) ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 85 of 91
Human Interaction provided by the Web Interfaces of the Central Services. 6.3.5 Central Support Services Figure 76: Web Interface: Human Interaction (NEA CS/MIS) Central Support Services are addressed using the Business Communication Channels [BCC8] and [BCC23]. Figure 77: Central Support Services (BCC) Human Interaction provided by the EMCS/CO Web Interfaces addresses the following use cases: 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. This is performed using the following Common Domain Infrastructure Communication Channels: Web Interface of EMCS/CO as the interactive channel. Figure 78: Web Interface: Human Interaction (MSA User EMCS/CO Central Services) ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 86 of 91
Web Interface of EMCS/CO as the notification channel. Figure 79: Email-based Interface: Human Interaction (EMCS/CO Central Services MSA User) ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 87 of 91
7 EMCS Business Continuity Specifications 7.1 Introduction This Chapter aims at examining in which way the EMCS Common Domain Architecture (specified in Chapters 2 to 6) is able to answer the business continuity requirements expressed in TESS Section I. To do so, a set of business cases is considered and, for each of them, the appropriate fallback solution that can be activated to reduce the system unavailability and limit the impact on Economic Operators and MSAs activity to the maximum. In principle, those fallback solutions should be documented with a high level of details in a document called Business Continuity Plan (BCP) that should be developed in a further phase of this project. The present specification should therefore be considered as an input to the BCP elaboration. 7.2 Problem Statement A key issue to be addressed in the field of business continuity refers to the fact that most of the Availability Requirements [AR] classes derived from the FESS [R4] and taken as initial constraints to the TESS elaboration (see TESS Section I, 2.6.1 Availability Requirements Classes [AR]) impose more stringent values than those guaranteed by the Service Level Agreement on the CCN/CSI services (see 3.3.3 Service Level Agreement). The relevant differences are summarised in the Table 8. They indicate that solutions shall be found to increase the EMCS Architecture resilience (see 7.3 EMCS System Resilience) so as to compensate potential service interruptions. EMCS Availability Requirements [AR-1] Permanent Class of availability This class addresses use cases requiring availability 24 hours per day, 365 days per year (24x365). They are essential functions where the unavailability would have serious consequences on the EMCS business, either for the economic operators or for the Administrations themselves. Average availability: 99.75%, about 22 hours per year of unavailability. Maximum unavailability: 15 minutes at any time. [AR-2] High Class of availability This class addresses functions that should be permanently available, but the business is able to accept short unavailability, in particular at night. Average availability: 99%, about 4 days per year of unavailability. SLA on CCN/CSI Services Not covered by SLA Partially covered by SLA Overall system availability over 20 days: 97% Maximum unavailability: 1 hour at any time. Can be up to 6 hours (if production / backup gateway failover procedure is to be done) ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 88 of 91
EMCS Availability Requirements [AR-3] Office Class of availability This class addresses functions that need to be available only during working hours, defined by each MSA. SLA on CCN/CSI Services Partially covered by SLA (Working hours = 8:00 to 20:00 Brussels time, Mon-Fri) Average availability: 99% during office hours, typically 2 hours per month of unavailability. Maximum unavailability: 30 minutes during office hours. [AR-4] Scheduled Class of availability This class addresses functions that are not necessarily activated on-line. They should be submitted in batch mode in a given timeframe (e.g. at night). Average availability: not applicable. Maximum unavailability: the function must be started during the time window. [AR-5] Disconnected Class of availability This class addresses functions that are performed outside the EMCS application Average availability: out of scope. Maximum unavailability: out of scope. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 89 of 91 Overall system availability over 20 days: 97% Individual CCN Gateway availability over 20 working days: 95 % Can be up to 6 hours (if production / backup gateway failover procedure is to be done) Fully covered by SLA Out of scope of SLA Table 8: EMCS Availability Requirements vs. CCN Committed Service Level 7.3 EMCS System Resilience Table 8 shows that the CCN/CSI infrastructure is not able to officially guarantee the Permanent Class of availability required by EMCS. However this cannot be reasonably considered as a blocking issue for at least two main reasons: 1. The CCN/CSI Central Project is able to provide every MSA site involved in the EMCS business with the necessary equipment redundancy at all levels (i.e. firewall, gateways, routers, local loop to the CCN backbone, etc.) so as to provide on the field a higher availability rate than the one committed in the SLA. These redundancy options are described in 7.4 CCN Redundancy Options. 2. The EMCS system is designed to offer a strong resilience at application level: a. A Central Services backup site can be implemented at the EC Data Centre (BE) or eventually outsourced to external contractor to provide Reference Data mirroring facilities. In case of unavailability of the EMCS/CO master site (located at the EC Data Centre (LU)), the switch to the backup site could be made transparently to MSA applications by updating the CCN network routing configuration.
b. The Standard Excise Application (see TESS Section IV Standard Excise Application Architecture) provides data flow regulation capabilities (through the Flow Control Engine and the Business Process Execution Engine), which allow requests issued by Economic Operators to be accepted even if the communication channel is not available (e.g. if the local CCN infrastructure is down). In this case they are stored locally on the national system (persistent storage objects) and processed as soon as the situation comes back to the normal. 7.4 CCN Redundancy Options 7.4.1 Backup Gateway at Local Site A recent evolution to the CCN Gateway software called Multimode Support allows both Production and Test traffics to be handled by the same physical machine. As a result the so-called Backup CCN Gateway which was used in the past for both testing and backup purposes can now be dedicated to sole backup purpose. As the multimode support should be generalised to the whole network in the short term, it makes sense to consider that all MSA sites involved in the EMCS business will benefit from this evolution and therefore from a real local redundancy of the CCN Gateway. This will increase the overall resilience of the system since the CCN Gateway is the Common Domain Relay equipment that handles the major EMCS data flows transiting through the CCN Network (CCN Asynchronous paradigm). 7.4.2 Central Backup Site If for some reasons the fallback to the local backup CCN Gateway is not possible (e.g. backup gateway out of order, no backup gateway available locally), data flows can be redirected to a Central Backup Site. The Central Backup Site is maintained by the CCN/TC and consists of a pool of machines that can be dynamically configured to take over the CCN/CSI service in case of unavailability of a production CCN Gateway at a local site. The redirection of data flows towards the Central Backup Site is achieved by modifying the routing tables of the local security device (Firewall) deployed at every local site. It is therefore completely transparent at the National Excise Application level. The only drawback of such fallback solution (i.e. compared to the use of a local CCN backup Gateway) is that the CSI link between the national Application Platform and the central Backup gateway is established over a low-speed link (i.e. the CCN Network), hence decreasing the performance level of the communication. 7.4.3 Other Equipment Redundancy The equipment deployed within the National Domain Connection Point (see 3.2.2 National Domain Connection Point (NDCP)) can be duplicated to provide redundancy at all levels (firewall, router, access line to the CCN backbone, gateways, etc.). By default, this redundancy shall be applied to every MSA site involved in the EMCS business. ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 90 of 91
End of TESS Section II ECP1-ESS-TESS-02-SECTION-II-EMCS-COMMON-DOMAIN-ARCHITECTURE-v3.00.doc Page 91 of 91