CORE COmmon Reference Environment How it works JeanPierre

CORE – COmmon Reference Environment How it works Jean-Pierre Kent 11 January 2012 1

Contents • Introduction – Design ≠ implementation • Overview – A model of the user’s experience • Presentation of the information model 2

Design ≠ Implementation • Goal of design: – Deliver a concept apt to contribute to the industrialisation of official statistics (ref: HLG-BAS Vision) • Result: – A model that exceeds the capacity of a 1 -year project 3

Design ≠ Implementation • Goal of implementation – Deliver Proof Of Concept with: • Platform independence • Model-driven design environment • Model-driven execution environment • Result: – Implementation of a subset of the model 4

What is Platform Independence? • Once implemented, a service can run on any platform (e. g. . Net, Java, Eclipse, . . . ) • A process engine running on a platform (e. g. Java) can control services running on another platform (e. g. . Net) • A process can be distributed: – Manage microdata at Statistics Netherlands – Do aggregation at ISTAT – Produce the SDMX output at Eurostat – Under control of a process engine running at INSEE 5

Model-Driven: cutting costs • Traditionally: 1. Designer makes models 2. Developer creates the system 3. System runs. • In a model-driven environment: 1. Designer makes models 2. System runs 6

Flexibility Model-Driven: effectivity Taylormade Model. Driven Standard package, ERP, CRM, DMS. . . Spaghetti Standardisation 7

Model-driven: benefits • Cost reduction: less manual work • Reliability: manual work is error prone • Time to market: less manual work • Standardisation: system enforces standards • Flexibility: incremental development, agile maintenance • Reliability: build processes from well-designed and welltested services • Strict separation of design and execution • Focus on process quality as a source of product quality • … and some more

Questions (Part 1) ? 9

Overview • What users see and use – This is not the information model – Nor the technical model – But a model of the user’s experience 10

CORE Run Time 11

CORE Design time This is where GSIM comes in 12

CORE: the whole picture 13

How do services interact? • You can use different tools for different services – e. g. SPSS, SAS, R. . . • Different tools expect different data formats • Conversions are inevitable 14

Conversions are expensive! • Between 2 formats –A B: 2 conversions • Between 3 formats –A B: 6 conversions C • Between N formats: N 2+N 15

CORE reduces N 2+N to 2*N • Standard CORE data format • Conversion to and from CORE format Input (CORE) Model (CORE) Convertor Model (X) Input (X) Output (CORE) Model (X) Tool X Convertor is tool-specific – not service-specific Output (X)

Questions (Part 2) ? 17

CORE: the whole picture 18

The information model • What the designer sees – Data set description and data set kind – Service and data set kind

Data set definition package

Communication channels • Manage communication between a service and the execution environment • Give support to Plug-and-Play coupling • Implement messaging

5 types of channels

4 types of messages • Service signature message • Service configuration message • Service execution message • Service output message

Service signature message • Service communicates to its environment the channels that it supports. • Channels constrain the kinds of information – expected during execution or during configuration • e. g. data set kind “microdata” – to produce during execution. • e. g. data set kind “aggregate”

Service configuration message • Environment communicates details about data sets that will be offered to the service during execution. – e. g. number of columns of a data set – value types for each of these columns • This information must fit in the channels specified in the service signature message – e. g. a data set description must match the expected data set kind

Service execution message • Service is requested to execute itself • Service is offered a number of data sets and business objects as input. • This information must comply with the service's signature message • It must be consistent with the data set and business object details the service is configured with through the service configuration message – e. g. a data set must match the expected data set description

Service output message • A service ends its execution by sending a service output message. • The result of the service execution is documented by data sets which match the service's configuration message. – e. g. the output data sets are consistent with their data set descriptions.

Questions (Part 3) ? 28