Reference Architecture in Sweden janne.sillanpaa@intersystems.com
Reference architecture What is a reference architecture? A blueprint for an architecture that can be implemented in different ways (as long as you stay within the frames of the architecture). Guidelines A reference architecture in the field of software architecture or enterprise architecture provides a template solution for an architecture for a particular domain. It also provides a common vocabulary with which to discuss implementations. [wikipedia]
Purpose of reference architecture Reference architecture = Building norm Rule set for development of integrations X Integration platform Reference architecture for integration describes the architecture in the grey box (as we want it to be).
Organizational needs 1. Kraven på att snabbt och säkert dela information mellan landsting och invånare ökar kontinuerligt, mycket på pga. den nationella IT- strategin (e-hälsa). Stora krav på realtidskommunikation online, synkron, stora krav på prestanda och stora krav på tillgänglighet samt krav på färskhet av data. T.ex. elektroniska sjukintyg, e-recept, mina vårdkontakter, nationell patientöversikt 2. Behoven på integration ökar även inom vår egen verksamhet (ÖLL, PDL, Socialstyrelsen etc) då landstinget använder IT i större uträckning ställer stora krav på att dela information mellan system.. T.ex. Labbsvar, kvalitetsregister, recept, medicinsk tekniska produkter (Dicom)
National requirements www.cehis.se
National requirements http://www.inera.se/
Architecture National guidelines created by Center for ehealth Business architecture Information architecture Technical architecture Security architecture Local guidelines created by county councils How, when and where to follow/implement national guidelines Develop a reference architecture for integration Create integration strategy
National technical architecture
National architecture General structure
Structure of service contracts
Example crm Scheduling GetBookingDetails In: BookingId Ut: Timeslot
National and local
National service platform
Local service platform
Service catalog
Services and contracts
What does a service contract consist of? Service contract description (eg. Service domain description) Template and instructions in RIV-method (Cehis web page) Documentation of all contracts Name, in and out messages Processing rules that need to be followed Technical definition per contract Instructions in RIV Technical Guidelines WSDL-file (metadata for envelope, communication protocol and security) XML Schemas (metadata for request and response messages) Exemple messages
Service interactions Service interactions are created from contracts Three types: Request-Response Response (most common) Synchronous service whole task is performed while waiting Spread information Asynchronous service Information is received, but is handled later Task Result Two way interaction Consumer gives producer a task (asynchrounously) Producer gives result by becoming consumer and consumer becomes producer (of result service) -> I.e. two service contracts that cooperate
What are RIV technical guidelines? Transport Today focused on SOAP-based web services over https: -Interop -Security Guideline -profile RIV Tekniska 2.0 Anvisningar - RIV Tekniska Basic Profile Anvisningar - Profil - Profil Message Envelope Header Technical aspects on content: -Interop -Versioning Guideline Service schema 2.0 Body
Documentation VIT-Boken RRR:er T-Boken Anvisning VIT-bokens tekniska arkitektur Nationell Tjänsteplattform och RIV- SHS-Växel RRR TA2 hänvisar till Referensarkitekturens adresseringsmodell ställer krav på Förutsätter följsamhet mot RIV Tekniska Anvisningar Anvisning Tjänsteschema 2.0 Översikt 2.0 - Motiv, Principer Anvisning Webserviceprofil Anvisningar RIV 2.0 Tekniska RIV Tekniska - Anvisningar - Basic Profile - Profil Hänvisar till Baseras på HCC Certifikat fo r svensk va rd och omsorg W3C, Oasis, WS-I m.fl. internationella standarder inom XML och webservices RIV Metoden Hänvisar till
Maintenance and support Maintained by Cehis Maintenance conducted openly at EU:s project place for open source http://rivta.forge.osor.eu All work results are Public Domain Different types of support Help forum Service contract generator on the web
Versioning Forward-backward-compatibilitycompatibility - mechanisms Namespace controls main version Schema name (file) and version attribute controls minor version Extension element (any-element) last in every sequence Forward/backward compatible change New, non-mandatory element in a structure Non-compatible change Mandatory elements needed Schema is unchanged but sematics different I.e. other rules for what consumers / producers must do
Local technical architecture
Integration methodology National architecture ÖLL BP Business plan National BP Business plan ÖLL IT-strategi ÖLL needs Direct/ Indirect requirements Business Strategy for integration Principles, goals, maturement step Reference architecture SAD Goals Logical(information) & Technical view: Patterns, Platform, Architecture principles Use cases Concrete & clear goals Clarify ref. arch. Organization ICC Roles Competence, Support processes and Routines Security/IT- infrastructure Non functional req. Topology, DMZ Detailed req. spec. Clear req., generic ESB Current situation Operation, etc Gap analysis: Current situation vs. needs, Strategy, Architecture, Requirements Product choice Other critera for evaluation Competence, product strategy, simplicity, other regions, cost etc Action plan Introduction of new product, update organization, introduction plan, budget
Integration strategy No standard exists today Differs per company, authority, county council But there is a red thread Focus on product strategy e.g. Biztalk Focus on architecture e.g.. ESB, service orienterad, patterns Focus on technology e.g. security Focus on business Focus on rules, integration principles Focus on action plan, roadmap, maturement step Focus on strategic decisions Focus on work methodology, processes Focus on economy model Focus on business needs
Purpose for an integration strategy 1. Management: Long term plan for handling integration control on costs and delivery regarding integration 2. Maintenance/architecture/development: Mainly a guidance document for developers and architects = forces the management to make decisions on principles and policies. Necessary to be able to succeed with introducing an integration platform or to introduce an organization for integration.
Integration domains
Process Engine BAM ESB - Broker ESB - Transportation Connectivity Transformation Protocol Conversion Routing Error Handling Logging/ monitoring Application Application Application Application Application Application Application Application Application Application
Service registry SOA Governance Reference architecture for service platform, example Surveillance and monitoring Graphical monitoring 1:line support. Dashboard Security modules such as SITHS, certificates Graphical Workflow / Orchestration / BPM Graphical mapping, support HL7, 13606, DICOM B2B Enrichment Graphical monitorering 2:line support, grafically follow flows, trace BAM KPIs trends Op.Env. Performance, services, loads ESB Connectivity (Webservice) Routing Conversation protocol transformation Transformation message Transport Adapters Transport managment Secure transport Queue-handler Development Hot deployment Testdriven Patterns HP Open View Operation HA high availbility environment Message level never loose Physical: Load balancing, failover 125 requirements
Main pattern SOA ( online services ) SOA = Service-oriented architecture
Main pattern EDA ( subscription services ) EDA = Event-driven architecture
ESB Support for technical integration patterns. Routing Enterprise Service Bus Transformat ion Integration logic Aggregator Enrichment Support for synchronous and asynchronous connections of building blocks to integration flows that implement integration services. Here prerequisites are created for BAM and statistics for SOA Governance. Technical connection WS SFTP ODBC HTTPS Adapters Clinical portal Care system Data warehouse Support service Service consumers and producers that are connected through the ESB s technical adapters
Integration platform as receipient of integration components of the five different types Every integration service becomes an integration component in the platform. The blueprint controls how the architecture becomes in the platform (what components are developed and how the interact)
Structure of virtual service Virtual service
Structure of connection service Connection service
DEMO of (part of) service platform
Questions? Janne Sillanpää janne.sillanpaa@intersystems.com