Ec.europa.eu
Partner’s name: Statistics Netherlands
WP number and name: 5 Implementation library for generic interface and production chain in .NET
Deliverable number and name: 5.1 CORE implementation in .NET
CORE implementation in .NET
|Partner in charge |Statistics Netherlands |
|Version |v 1 |
|Date |February 2012 |
|Version |Changes |Date |
| | | |
| | | |
[pic] [pic]
This document is distributed under Creative Commons licence
"Attribution-Share Alike - 3.0 ", available at the Internet site:
Contents
Introduction 3
Logical View 4
Overview 4
Subsystems 6
Process View 7
Implementation View 9
Deployment View 10
Security 11
Data View 12
CORE Repository 12
Local storage of CORE and non-CORE data 12
Introduction
This document gives an architectural description of the .NET implementation of the CORE system (in this document referred to as ). This scope of this implementation is limited to a proof of concept of some of the aspects of CORE. It is not intended to be used directly as part of a statistics production system, but can be used as a starting point to build from.
The description contains several views on the system, highlighting different aspects of the system. Chapter 0 contains a logical view on the system, showing the logical components of the system. Chapter 0 contains a Process view, showing the details of the main process implemented by the system. Chapter 0 contains remarks and observations in the context of the Implementation of the system. Chapter 0 highlights some Deployment aspects of the system. Finally, Chapter 0 contains a view on the data used in the system.
Logical View
1 Overview
Figure 1 shows all components in the system, and the dependencies between them:
[pic]
Figure 1: Components in the system and their dependencies
The components in the system are described in the following table:
|Component |Description |
|eu.cora.model.data |Contains the Cora Dataset class, which is the heart of the Cora data model, and classes used by |
| |it. The code for this component is fully generated from the xml schema cora.data.model.xsd |
|eu.cora.domaindescriptor |Contains the Core Schema class, used for defining Core datasets, and classes used by it. The code|
| |for this component is fully generated from the xml schema cora.domain.descriptor.xsd |
|eu.cora.model |Helper and handler classes for the core objects in eu.cora.model.data and |
| |eu.cora.domaindescriptor. All code in this component was directly translated from the |
| |corresponding Java package eu.cora.model. |
|eu.cora.mapping.csv |Contains the CsvFile class, used to define mappings between Cora Datasets and csv files, and |
| |classes used by it. Code for these classes is fully generated from the xml schema |
| |cora.mapping.csv.xsd. Furthermore, this component contains classes which handle these mappings, |
| |and perform the transformations between Cora Datasets and Csv files. Code for these classes was |
| |directly translated from the corresponding Java package eu.cora.mapping.csv.operations. |
|eu.cora.domain |Defines the domain objects of the system. In the Java system, the code for these |
| |classes was generated using Hibernate. Since the .NET system doesn’t use NHibernate, the code for|
| |this component was not generated, but directly translated from the Java package eu.core.domain. |
|eu.cora.util |Contains the helper class Utils, in which some generic helper functions are defined. Code for |
| |this class is translated from the Java package eu.cora.utility (NB: the class Constant.java in |
| |this package is not present in the .NET system) |
|eu.cora.runtime |Contains classes that facilitate the execution of Cora Processes, defining a runtime environment |
| |for them. Code for these classes was translated form the Java package eu.cora.runtime; some minor|
| |modifications were made after the translation. |
|eu.cora.service |Contains the RuntimeService class, responsible for setting up the runtime environment for process|
| |execution. The code consists partly of translated code from the Java class |
| |eu.cora.service.RuntimeService. |
|eu.cora.dataaccess |Contains classes providing functionality to read and write some of the Cora objects from and to |
| |the repository. In the Java system, this functionality is offered by the Hibernate dependency, |
| |but since NHibernate is not used in the .NET system, there is need for these data access objects.|
| |Only the support needed for the runtime to function is implemented (i.e. reading CoreProcess |
| |objects, and writing CoreOperationalDataInstance and CoreProcessInstance objects). |
|eu.cora.controller |Contains controller classes for the runtime client application, in which a process can be picked,|
| |input files can be coupled to the process, and execution of a process instance can be triggered. |
| |Also contains interface definitions for the views used by the runtime application. |
|eu.cora.runtime.gui |Executable component of the runtime client application. Implements the views (using WinForms) |
| |used to interact with the user of the application. |
|eu.cora.processengine.ws |Web service (using ), containing functionality to start and stepwise execute a Cora |
| |Process instance. NB: in order to be able to give feedback during the execution of a process, |
| |this web service is stateful; it uses the Session object to store state. Callers of the web |
| |service should be aware of this. |
Table 1: Description of all components in the system
2 Subsystems
The system can be roughly divided into two subsystems. On the one hand, there is functionality to pick a process from the available processes, view the services of a selected process, and attach (input) files as operational data instances to the selected process. On the other hand, there is functionality to execute a fully prepared process instance (i.e. an instance of a process with all necessary operational data instances set). In terms of components, the subsystems are defined as follows:
|Subsystem: |Components used |
|Viewing process and setting up operational data |eu.cora.runtime.gui |
| |eu.cora.controller |
| |eu.cora.dataaccess |
| |eu.cora.domain |
|Process execution |eu.cora.processengine.ws |
| |eu.cora.service |
| |eu.cora.runtime |
| |eu.cora.dataaccess |
| |eu.cora.mapping.csv |
| |eu.cora.util |
| |eu.cora.model |
| |eu.cora.model.data |
| |eu.cora.domaindescriptor |
| |eu.cora.domain |
Table 2: Subsystems of the system, and their components
Process View
In the system, the most important process is the actual execution of a Core Process instance. This process is split into two parts: the first being the preparation/starting of the execution, and the second being the actual execution of a process step (in the form of a Core Service). Figure 2 and Figure 3 show sequence diagrams for the two parts.
[pic]
Figure 2: Sequence diagram for starting the execution of a process
Execution of a Core Process is prepared by calling the StartProcess method of the web service. Firstly, the Core Process to be executed is read from the repository. After that, the RuntimeService prepares the execution runtime by uploading the operational data instances to the local runtime environment. Also, the process instance object is written to the repository. Finally, the ProcessInstance object is set up to prepare for the execution of the first step.
[pic]
Figure 3: Sequence diagram for executing a process step
Each process step is executed by calling the ExecuteStep method of the web service. The ProcessInstanceRuntime object is retrieved from the Session state, and the step is executed by calling the execute method of the appropriate ServiceRuntime object (which for now can only be LocalServiceRuntime objects). The LocalServiceRuntime first transforms (if needed) Cora datasets to csv, then starts a new .NET process to run the tool wrapped by the service, waits for this process to exit, and (if needed) transforms csv output of the tool to Cora datasets. The process output is interpreted and finally, the web service gives the proper feedback to the caller.
Implementation View
Concerning the implementation of the system, the following considerations can be made:
• The solution consists of 13 C# projects (one for each component, plus one for the deployment package of the client application) developed in Visual Studio 2005 using .NET runtime version 2.0. One of the projects (eu.cora.processengine.ws) is an web service project, which was tested using Visual Studio’s Development Server.
• To generate the code (from xsd files) for the components eu.cora.model.data, eu.cora.mapping.csv and eu.cora.domaindescriptor, the tool XSDObjectGen (version 1.4.4.0) was used. Due to some differences in the naming conventions compared to the tool used to generate the Java classes, class names (casing) and hierarchies are not always the same in the Java and the .NET implementation
• As the standard component log4j was used to support logging of information in the Java project, the .NET solution uses log4net for logging.
• The .NET implementation of the CORE runtime consists of a WinForms based client application for setting the runtime parameters and receiving process execution feedback, and a server-side process engine/runtime, which is called through web services. This differs from the Java implementation, where the application for setting runtime parameters is a web application. A different implementation was chosen deliberately, to demonstrate the idea that platform-independent specifications of functionality can lead to completely different implementations on different platforms, but still lead to reproducible and interchangeable results.
Deployment View
Figure 4 shows a schematic overview of the deployment model for the system.
[pic]
Figure 4: Deployment model for
Three machines play a role for the deployment. The client machine contains the Client runtime application. It communicates with the database server (reading Core Process objects from the repository), and with the web/application server (by calling the ProcessEngine web service). The web/application server reads Core Process data from the repository, and writes instance data to it.
Table 3 contains a more detailed overview of the deployment model, including the components installed on each machine.
|Machine |Components installed |Prerequisites |
|Web/application server |eu.cora.processengine.ws |Internet information server (version 5 or |
| |eu.cora.service |higher) |
| |eu.cora.runtime |.NET framework 2.0 |
| |eu.cora.dataaccess | |
| |eu.cora.util | |
| |eu.cora.domain | |
| |eu.cora.mapping.csv | |
| |eu.cora.model | |
| |eu.cora.domaindescriptor | |
| |eu.cora.model.data | |
| |All tools wrapped by local services (R, SAS, …) | |
|Database server |CORE repository |Any DBMS with OleDB support (e.g. MS SQL |
| | |Server, Oracle, MySQL, MS Access, …) |
|Client machine | client tool, containing: |.NET framework 2.0 |
| |eu.cora.runtime.gui | |
| |eu.cora.controller | |
| |eu.cora.dataaccess | |
| |eu.cora.domain | |
Table 3: Components installed on the machines involved
For the client tool, a deployment package (MSI installer) is included in the system (eu.cora.runtimeclient.setup component). The components on the web/application server can be installed by simply copying the contents of the web service directory. Finally, database-scripts for creating the CORE repository (MS SQL Server syntax) are also included, as well as scripts that fill the repository with some testing content.
1 Security
In the system, no specific security model is implemented. Access control can be configured at the web service level (through IIS configuration) or at the database level (through configuration of the connection string). When using integrated security and impersonation at the web service level, one should consider that generally network access is limited using impersonating accounts, and extra measures should be taken to get the proper access (these measures are outside the scope of this document however).
Data View
1 CORE Repository
The CORE Repository is used for the persistence of CORE objects (both at design time and at runtime), and consists of a set of tables and constraints, directly corresponding to the (Hibernate-generated) classes of the eu.cora.domain component. Access to the repository is implemented in a highly generic way, using OleDb connection strings. This means that any database management system for which proper OleDb support (i.e. an OleDb provider) is present, can be used with great ease; only the connection string in the configuration files need to be adapted. Included in the implementation package, there are MS SQL Server creation scripts, as well as an MS Access database containing the repository.
2 Local storage of CORE and non-CORE data
All data files (both CORE data and non-CORE data) which are used or generated during the execution of a Core process, is stored in the local runtime environment; each process instance has its own, isolated space there. Before the start of the execution, input files are uploaded to the runtime environment. The output (csv) files, generated during execution of a service, are also written there, as well as the CORE data (in xml format) produced by transformation from csv. The root directory of the runtime environment storage can be set in the web configuration file.
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- sql server according to bob two guys who work on sql server
- ps1 prototype science archive design
- data structure for ctpp 2012 2016 data set
- gpseismic is a suite of survey mapping and data
- building your first microsoft azure search application
- the sloan digital sky survey
- relational database rdbms via odbc interface to pi system
- sql sentry overhead analysis
- computer science engineering notes