Service Oriented Architecture Reference Model

Slides:



Advertisements
Similar presentations
TWO STEP EQUATIONS 1. SOLVE FOR X 2. DO THE ADDITION STEP FIRST
Advertisements

Overview: Guide for applying RM-ODP with UML Profile for EDOC
Software Requirements
SOA Masterclass - Fundamentals of SOA |11 February 2009 | Page 1 Fundamentals of SOA.
© 2005 by Prentice Hall Appendix 3 Object-Oriented Analysis and Design Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.
Distributed Systems Architectures
Chapter 7 System Models.
1 Copyright © 2010, Elsevier Inc. All rights Reserved Fig 2.1 Chapter 2.
By D. Fisher Geometric Transformations. Reflection, Rotation, or Translation 1.
2005 Adobe Systems Incorporated. All Rights Reserved.Adobe Confidential Duane Nickull Adobe ® Service Oriented Architecture Reference Model (SOA RM)
SDI Business Phases and derived INSPIRE Horizontal Services Relates to INSPIRE DT Network Services, DT Sharing Relates to OGC GeoDRM WG, Price & Order.
2/11/2014 8:44 AM The CDA Release 3 Specification Stack September 2009 HL7 Services-Aware Enterprise Architecture Framework (SAEAF)
Business Transaction Management Software for Application Coordination 1 Business Processes and Coordination.
SOA for EGovernment 1 Emergency Services Enterprise Framework: A Service-Oriented Approach Sukumar Dwarkanath COMCARE Michael Daconta Oberon Associates.
Copyright © 2006 Data Access Technologies, Inc. Open Source eGovernment Reference Architecture Approach to Semantic Interoperability Cory Casanave, President.
Page 1 Copyright © 2010 Data Access Technologies, Inc. Model Driven Solutions May 2009 Cory Casanave Architecture of Services SOA for E-Government Conference.
Presented to: By: Date: Federal Aviation Administration Registry/Repository in a SOA Environment SOA Brown Bag #5 SWIM Team March 9, 2011.
EA Demonstration Study : Dissemination Forum – 8 June EA Views and Sub-views Patrick Bardet EA Unit.
Jeopardy Q 1 Q 6 Q 11 Q 16 Q 21 Q 2 Q 7 Q 12 Q 17 Q 22 Q 3 Q 8 Q 13
Jeopardy Q 1 Q 6 Q 11 Q 16 Q 21 Q 2 Q 7 Q 12 Q 17 Q 22 Q 3 Q 8 Q 13
Title Subtitle.
0 - 0.
DIVIDING INTEGERS 1. IF THE SIGNS ARE THE SAME THE ANSWER IS POSITIVE 2. IF THE SIGNS ARE DIFFERENT THE ANSWER IS NEGATIVE.
Addition Facts
1 Learning Touchmath *Graphics taken from
|epcc| NeSC Workshop Open Issues in Grid Scheduling Ali Anjomshoaa EPCC, University of Edinburgh Tuesday, 21 October 2003 Overview of a Grid Scheduling.
UKOLN, University of Bath
COBIT® 5 for Assurance Introduction
Micro Focus Research 1 As far as youre aware, how does your organization plan to drive business growth over the next three years? (Respondents' first choices)
Construction process lasts until coding and testing is completed consists of design and implementation reasons for this phase –analysis model is not sufficiently.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design 1.
Chapter 5 – Enterprise Analysis
A Roadmap to Successful Implementation Management Plans.
Table 22.1 Stakeholder summary for the Odd Shoe Company
© 2011 TIBCO Software Inc. All Rights Reserved. Confidential and Proprietary. Towards a Model-Based Characterization of Data and Services Integration Paul.
1 UML ++ Mohamed T IBRAHIM University of Greenwich -UK.
Component-Based Software Engineering Main issues: assemble systems out of (reusable) components compatibility of components.
SAI Performance Measurement Framework
IONA Technologies Position Paper Constraints and Capabilities for Web Services
Software Requirements
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 28 Slide 1 Process Improvement 1.
Lecture 5: Requirements Engineering
Addition 1’s to 20.
25 seconds left…...
Copyright 2001 Advanced Strategies, Inc. 1 Data Bridging An Overview Prepared for DIGIT By Advanced Strategies, Inc.
Week 1.
We will resume in: 25 Minutes.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 31 Slide 1 Service-centric Software Engineering 1.
OASIS Reference Architecture for SOA
Overview of OASIS SOA Reference Architecture Foundation (SOA-RAF)
OASIS Reference Model for Service Oriented Architecture 1.0
OASIS Service Oriented Architecture Reference Model Technical Committee (SOA-RM) BOOT CAMP April DRAFT: Not approved by the OASIS SOA RM TC.
Ken Laskey, co-editor 5th SOA for E-Government Conference 1 May 2008
Reference Models مدل های مرجع معماری.
Web Service Architecture Part I- Overview and Models (based on W3C Working Group Note Frank.
Foundations This chapter lays down the fundamental ideas and choices on which our approach is based. First, it identifies the needs of architects in the.
SOA Reference Model Generic Presentation DRAFT: Not approved by the OASIS SOA RM TC.
2005 Adobe Systems Incorporated. All Rights Reserved. 1 An Introduction to the OASIS Reference Model for Service Oriented Architecture (SOA) Duane Nickull.
2005 Adobe Systems Incorporated. All Rights Reserved. Duane Nickull Adobe ® An Introduction to the OASIS Reference Model for Service Oriented Architecture.
95-843: Service Oriented Architecture 1 Master of Information System Management Service Oriented Architecture Lecture 3: SOA Reference Model OASIS 2006.
2005 Adobe Systems Incorporated. All Rights Reserved. Duane Nickull Adobe ® An Introduction to the OASIS Reference Model for Service Oriented Architecture.
Service Service metadata what Service is who responsible for service constraints service creation service maintenance service deployment rules rules processing.
© 2009 The MITRE Corporation. All rights reserved Approved for Public Release; Distribution Unlimited Considerations for Versioning SOA Resources Ken Laskey.
OASIS Service Oriented Architecture Reference Model Technical Committee (SOA-RM) BOOT CAMP May DRAFT: Not approved by the OASIS SOA RM TC.
© Drexel University Software Engineering Research Group (SERG) 1 The OASIS SOA Reference Model Brian Mitchell.
Reference Architecture for SOA (OASIS SOA-RM TC work in-progress) Frank McCabe Jeff Estefan Ken Laskey Danny Thornton.
Overview of OASIS SOA Reference Architecture Ken Laskey OASIS SOA-RM RA Subcommittee 19 February 2008 Ken Laskey OASIS SOA-RM RA Subcommittee 19 February.
1 SOA Seminar Seminar on Service Oriented Architecture SOA Reference Model OASIS 2006.
 Copyright 2005 Digital Enterprise Research Institute. All rights reserved. SOA-RM Overview and relation with SEE Adrian Mocan
Models of the OASIS SOA Reference Architecture Foundation Ken Laskey Chair, SOA Reference Model Technical Committee 20 March 2013.
Presentation transcript:

Service Oriented Architecture Reference Model An informal SOA Ontology

Reference Model An abstract framework for understanding significant relationships among the entities of some environment. Consists of a minimal set of unifying concepts, axioms and relationships within a particular problem domain. Is independent of specific standards, technologies, implementations, or other concrete details.

Reference Model

Service Oriented Architecture Service Oriented Architecture is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. Goal of this reference model is to define the essence of Service Oriented Architecture

Why Service Oriented Architecture? Drivers: Large scale Enterprise systems Internet scale provisioning of services Reduce the cost of doing business Benefits Build scalable, evolvable systems Scalable because minimizes assumptions Manage complex systems Encourage re-use of business function 

Why is it different? SOA reflects the reality of ownership boundaries CORBA, RMI, COM, DCOM, etc. all try to implement transparent distributed systems Ownership is of the essence in SOA SOA is task oriented Services are organized by function Getting something done SOA is inspired by human organizations It worked for us, it should work for machines

What is not in the RM Service composition Organizational framework Choreography, orchestration Process Oriented Architecture Organizational framework Who is doing what to whom Specific technologies not even specific architectures

Key concepts

Service A mechanism to enable access to one or more capabilities using a prescribed interface consistent with constraints and policies as specified by the service description.

Visibility Awareness Willingness Reachability Visibility is the relationship between service participants that is satisfied when they are able to interact with each other Awareness Service description Discovery Willingness Policy & contract Reachability Communication

Interaction Interacting with a service involves performing actions against the service The extent to which one system can effectively interpret information from another system is governed by the semantic engagement of the various systems. The semantic engagement of a system is a relationship between the system and information it may encounter.

Real World Effect The purpose of using a capability is to realize one or more real world effects. At its core, an interaction is “an act” as opposed to “an object” and the result of an interaction is an effect (or a set/series of effects). The real world effect is couched in terms of changes to the state shared by the participants and stakeholders in a service interaction

About Services

Conditions and Expectations Policy Constraint representing the intention of a participant in a service Contract Constraint representing an agreement between two or more participants.

Description The service description represents the information needed in order to use, manage or provide a service. Service reachability Service Functionality Service Policies Service Interface

Execution Context The execution context is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interaction, and thus forms a path between those with needs and those with capabilities

Is a Reference Model an Ontology? Establishing a vocabulary A lot of definitions The RM glossary has 28 entries Formality was considered Audience is not formal Mechanical processing of RM not expected

What about UML UML obvious choice for an architecture spec But, Inheritance (is-a) relationship almost never used Extraneous precision E.g. we tried to define Service, not count the number of service providers It’s so ugly <duck/>

An early concept map

Concepts Maps Concepts maps were excellent graphical indices to text Concepts, and relationships. All we needed

On the cutting-room floor…

Where we are Committee Specification published Reference Architecture effort started http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm