1 / 28

CORE – COmmon Reference Environment How it works

This article explains the concept of the model-driven environment and its impact on design and implementation processes. It discusses the goals of design and implementation, platform independence, model-driven development, and the benefits of using a model-driven approach. The article also explores the interaction between different services and the role of conversions in data formats. Additionally, it covers the information model, communication channels, and messages in the model-driven environment.

gpooler
Download Presentation

CORE – COmmon Reference Environment How it works

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CORE – COmmon Reference EnvironmentHow 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

  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

  4. Design≠ Implementation • Goal of implementation • Deliver Proof Of Concept with: • Platform independence • Model-driven • Model-driven • Result: • Implementation of a subset of the model 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

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

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

  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) ?

  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

  11. CORE Run Time

  12. CORE Design time This is where GSIM comes in

  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

  15. Conversions are expensive! • Between 2 formats • A B: 2 conversions • Between 3 formats • A B: 6 conversions C • Between N formats: N2-N

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

  17. Questions (Part 2) ?

  18. CORE: the whole picture 18

  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

More Related