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

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

3. 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

4. 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

5. 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

6. 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

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

8. 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

9. Questions (Part 1) ? 9

10. 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. 11 CORE Run Time

12. 12 CORE Design time This is where GSIM comes in

13. 13 CORE: the whole picture

14. 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

15. 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

16. 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

17. Questions (Part 2) ? 17

18. 18 CORE: the whole picture

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

20. Data set definition package

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

22. 5 types of channels

23. 4 types of messages Service signature message Service configuration message Service execution message Service output message

24. 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”

25. 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

26. 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

27. 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.

28. Questions (Part 3) ? 28