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

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 Result: – Implementation of a subset of the model 4 design environment execution environment

What is Platform Independence ? Once implemented, a service can run on any platform (e.g..Net, Java,...) 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

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

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 well- tested 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

11 CORE Run Time

12 CORE Design time This is where GSIM comes in

13 CORE: the whole picture

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 Tool X Input (X)Output (X) Model (CORE) Convertor Input (CORE) Output (CORE) Model (X) Convertor Convertor is tool-specific – not service-specific Model (X) Model (CORE) Convertors are format-specific, not service-specific

Questions (Part 2) ? 17

18 CORE: the whole picture

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