Layered Architecture in Service Design: A Framework for Interoperability and Integration
This document presents a foundational framework for implementing a layered architecture in service design, focusing on extracting common elements from project artifacts to develop a platform-specific model. It aims to identify platform-independent components while considering specific models that cater to various implementation environments. The framework leverages a decision tree mechanism for analyzing choices within the architecture stack and promotes interoperability among disparate systems. The use of BPMN and SBVR methodologies further enhances process and business vocabulary modeling for effective service architecture development.
Layered Architecture in Service Design: A Framework for Interoperability and Integration
E N D
Presentation Transcript
Draft 02 X Paradigm layered architecture Starting Point S. Lotti HL7 Italia Chair Enterprise Architect at Invitalia – Government Agency for Inward Investment Promotion and Enterprise Development HSSP
Objective of Layered Architecture (from wiki) • The overall approach to layered service architecture is to extract common elements from project artefacts performing similar capabilities into a “platform specific model” and consider a multiplicity of platform specific models based upon the differences. • Initial ideas are: • Map artefacts into the SAIF framework as was done in Practical Guide Part II with an eye to separating platform independent elements from platform specific ones. • A decision tree through the stack will be graphed. The output of task #1 may or may not be appropriate as a starting point. Particular paths of choices through the stack may represent particular existing artifact choices (example: IHE XDS profile). Again the purpose is to find the common elements vs. differences and provide raw material for generating a deployment that enables disparate systems to interoperate. HSSP
X Paradigm specs in SAIF ISM Common part (Platform indipendent) Conformance assertion analysis Platform Specific part ? ? • Mixed implementation environments are also theoretically possible HSSP
Logical progession (partial) Bottom up With existing specs HSSP
e.g. Service architecture design • Layered Service Inventory • BPMN2 Choreograpy • BPMN2 Collaboration • Service Architecture (SoaML from STMs PIM) - Use case (narrative) • Business Vocabulary (SBVR) Process Services Entity services Utility services HSSP
Business Vocabulary (SBVR) • The Vocabulary will be designed with SBVR (with a simple UML profile) • SBVR will be used for role/actor modeling and also for conceptual information modeling HSSP
BPMN2 Collaboration • Business Vocabulary (SBVR) Narrative Use Case • The processes will be derived from narrative use cases and vocabulary (participants) HSSP
Service Architecture • BPMN2 Collaboration • Service Contracts & • From BPMN collaborations will be identified the operations and mapped on the service architecture and contracts (from STMs) Service architecture Contract Retro-modeling from existing standard specs is necessary HSSP
BPMN2 Collaboration • BPMN2 Choreograpy • From BPMN collaborations will be defined the choreography or the orchestration(s) (if possible or useful) HSSP
Resulting Service Inventory Layered Service Inventory Paradigm X Inform IHE Profile OMG Standards … HSSP Services (logicaldimension) Implementabledimension HSSP
