140 likes | 238 Views
Service Modelling Team (SMT#3). Topic: Service Architecture. Walter Van Hamme WP8 contributor 7 May 2014. From wiki. http://im.eurocontrol.int/wiki/index.php/ISRM/Modelling_and_Collaboration/Consolidation/1.1/Service_Architecture Points to consider / discuss
E N D
Service Modelling Team (SMT#3) Topic: Service Architecture Walter Van Hamme WP8 contributor 7 May 2014
From wiki http://im.eurocontrol.int/wiki/index.php/ISRM/Modelling_and_Collaboration/Consolidation/1.1/Service_Architecture • Points to consider / discuss • Service architecture diagrams within ISRM. • Making clear the intention of the Service Architects. • In particular in showing several services together (similarity, difference, dependency, alternative, and much more) without having to go to fine details. • This is usally a good entry point for newcomers and external stakeholders. • How should these diagrams be handled in the next phases? enter your presentation title
Generic content • Objective & content • Improving understanding of ISRM services • Putting services in context & Promoting SOA • Status & problem / issue • ISRM focuses on isolated services • Architecture diagrams not in ISRM 1.1 Foundation • Examples • From FT9 & FT10 • Discussion • Usefulness • Alternatives • Way Forward • Decisions & Actions enter your presentation title
FT9 – OFA 05.03.01 ASM & aFUA • Service Architectures • We used the SoaML service architecture diagram which is a collaboration diagram that depicts the high level functions (=role) that ATM participants provide to achieve a certain goal via service contracts. We have created a separate architecture for each business collaboration. The first reason is for readability. The second reason, more important, it to concentrate on specific business collaboration and to view the roles that are directly required to achieve the collaboration. • We leave the EAEA to depict the global service architecture and we concentrate on the service design making sure that the appropriate SOA design principles are applied. • The architecture diagrams are placed in the collaboration sections of the document. • Manage Airspace Reservation • Consolidate AUP • Manage Airspace Activation enter your presentation title
Manage Airspace Reservation enter your presentation title
Consolidate AUP enter your presentation title
Manage Airspace Activation enter your presentation title
FT10 – OFA 05.01.01 AIOM & A-CDM • Usage • Provide an overview of the services and the actors • Stress similarity, difference, dependency, alternative, and much more • Put services in context • Focus from 1 service several services • Usually before looking into the detail of a service enter your presentation title
Visual overview of the Identified Services enter your presentation title
NSOV-5 Service BehaviourFunction and Service Category enter your presentation title
The Consolidator checks incoming partner values and calculated results based on (local) business rules and combine them to provide one consolidated output that will become the reference value. Uses Business Logic to validate / filter the values: eg value in the past, max number of TOBT update after TSAT issue, etc.. The A-CDM Publisher collates all consolidated information in a global picture. That global picture, or part of it, is then published to internal and external stakeholders that have subscribed to it. Simplified view of the pattern service architecture The Calculator uses the raw information to provide calculated results following some Business logic. Examples are the Automatic TOBT Calculation, or the Pre-Departure Sequencer that calculates TTOT and TSAT. enter your presentation title
Identified Services mapped to the Service Architecture The diagram shows a complete picture. It is not necessary to implement each of the depicted services to be compliant with this architecture. The local situation at the Airport may dictate what is actually applicable. At some airport, there may be no need for Partner TSAT set, at some others the PDS may be within the ACISP, etc. enter your presentation title
Discussion • Usefulness of Service Architecture diagrams • Understanding • External stakeholder • SOA • Alternatives about Service Architecture diagrams • Disregard - Remove useful information for our stakeholders • Put outside of ISRM - Where? Consistency? Complete logical view? • Allow within ISRM - Adapt Foundation • Other? - Any? enter your presentation title
Way forward • Decisions • Actions • Concerning • Existing architecture diagrams • New architecture diagrams • ISRM Foundation enter your presentation title