After being deeply involved in the EMCS System Specification (ESS) project (executed for the European Commission / DG TAXUD during the period 2003-2007) Vivansa Experts were solicited by some National Customs / Tax authorities to deliver EMCS expertise, which led to the creation of the lxr.NEA product which provides electronic processing services for declaring, monitoring, and discharging the movements of goods transported under excise duty suspension within the EU.
lxr.NEA provides the core business services required by the National Authority to comply with EC requirements for EMCS and which (functionally speaking) are the same for every National Authority. It includes “Built-in” services which are deployed by default and which can be combined with other “To-customize” services (provided by the lxr.Portal product) answering national specific requirements for trader access.
lxr.NEA can also be complemented with other products of the Vivansa lxr. portfolio, namely lxr.SEED (which implements the System of Exchange of Excise Data), lxr.ARCfallback (which implements EMCS fallback services) and lxr.CCN (which provides connectivity services with the CCN Network).
The lxr.NEA Service Architecture covers the services that support the automation of the EMCS business processes and the way they enforce the EMCS rules. See also the lxr.NEA Technology Overview document, Chapter “lxr.NEA Services Identification” for more details.
The lxr.NEA Process Architecture covers the orchestrated business processes. The term “orchestrated” means that the processes are structured, repeatable, automatable, and also that they can be easily adapted, measured, and analysed. The approach that has been chosen is to describe the EMCS business processes implemented by lxr.NEA using the diagrammatic BPMN (Business Process Modelling Notation) representation. Such representation eases the deployment and the effective management of the business processes. See also the lxr.NEA Technology Overview document, Chapter “lxr.NEA Processes” for more details.
The lxr.NEA Application Architecture defines the software components necessary to process and exchange the data, and to implement services. The three main lxr.NEA software components are:
> EMCS Service Broker, in charge of the business process orchestration, and making use of BPEL (Business Process Execution Language) to implement such orchestration. See also the lxr.NEA Technology Overview document, Chapter “lxr.NEA EMCS Service Broker” for more details.
> EMCS Back-end Services, implementing the various business functions to be orchestrated, using Java and Web Service technologies. See also the lxr.NEA Technology Overview document, Chapter “lxr.NEA EMCS Back-end Services” for more details.
> EMCS Exception Handler, in charge of the exception handling and the execution of business or technical compensations according to the type of exceptions. See also the lxr.NEA Technology Overview document, Chapter “lxr.NEA EMCS Exception Handler” for more details.
The lxr.NEA Data Architecture covers the types and sources of data necessary to support the business processes and services, i.e.:
> Logical Data Models (see lxr.NEA Technology Overview document, Appendix B – lxr.NEA Business Documents);
> Autonomous implementation of document rules (see lxr.NEA Technology Overview document, “Appendix D – Rules and Exceptions”);
> DDL (Data Definition Language) scripts;
> XML Scheme;
> XML Transformations.
To ensure that all lxr.NEA services are properly secured, a Trusted Zone is defined in which service invocations coming from each integration point are granted or rejected according to the established security policies. The Trusted Zone prevents any access to services if it has not been duly authenticated and authorised by the so-called “Secure Proxy” (See also lxr.NEA Technology Overview, Chapter “Security Aspects”).
lxr.NEA makes use of the following technology:
> Java as the programming language, offering high portability to any JEE application server running on a very large range of operating systems and hardware.
> Web Services as the enabling technology for SOA. The main interest is that Web Services provides an underlying mechanism that uses well-defined, standardized interfaces, effectively freeing the calling program from the need to deal with the intricacies of the underlying applications. Web services are self-describing, use widely accepted standards, and are accessible over a wide variety of transports, including (and especially) HTTP.
> Enterprise Service Bus (ESB), which is at the intersection of SOA, application integration, and BPM. The ESB promotes a fast, straightforward way to build Service-Oriented Architecture, and provides a standards-based, simpler approach to application integration. ESB is an infrastructure-agnostic middleware that provide Web service enablement, processing, and monitoring capabilities, data mapping and transformation, routing, and orchestration capabilities that leverage the existing infrastructure of application servers, transports, applications, and data. It addresses On-Demand Integration reliability, scalability and performance to connect any content, services or software across the Internet (or intranet) using web services.
> Business Process Management Suite (BPMS) for creating sophisticated business processes (including long running, asynchronous processes). The modelling is achieved using BPMN as the standard graphical notation and BPEL as the serialized XML programming language for the specification of executable business processes (applied primarily to the orchestration of Web services). Those languages improve the communication and the portability of process models. They facilitate designing, defining, implementing, and deploying composite applications and services from a number of distributed and autonomous software components, thus offering a flexible way to achieve the required business collaborations.