Reference Architecture for SOA (OASIS SOA-RM TC work in-progress)

1
Reference Architecture for SOA (OASIS SOA-RM TC
work in-progress)

• Frank McCabe
• Jeff Estefan
• Ken Laskey
• Danny Thornton

2
Agenda
Duration Topic Presenter
30 Introduction McCabe
30 This Architecture Estefan
45 Business via Services View McCabe
15 QA
30 Break
45 Realizing SOAs View Laskey/Estefan
30 Owning SOAs View Laskey/Thornton
15 QA
Minutes
3
Introduction

• SOA as eco system
• Primary concepts from Reference Model
• Plan for the tutorial

4
Systems and Eco-systems

• Multiple ownership domains
• No one entity controls everything
• Parallel development, deployment and usage of
  services
• A medium for people to get their business done

We include organizations and robots, but the
canonical use case is people using an SOA-based
system as a medium to act at a distance
5
Reference Model for SOA
Its an OASIS Standard
6
What is a 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.

7
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 reference model is to define the essence
  of Service Oriented Architecture

8
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

9
Key concepts
10
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.

11
Visibility
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

12
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.
13
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
14
About Services
15
Conditions and Expectations

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

16
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

17
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
18
Where the RA fits
19
Plan for Tutorial

• Structure of the Reference Architecture
• Three Views in Detail
• Business via Service View
• Realizing SOAs View
• Owning SOAs View

20
This Architecture

• Architectural goals principles
• What is a reference architecture?
• What is this RA?
• Views and viewpoints
• Three views of SOA
• Viewpoint specifications
• UML conventions

21
Goals of this Architecture
22
Architectural Principles

• Technology Neutrality
• We want to focus on the issues
• Parsimony
• Ockhams razor at work
• Separation of Concerns
• Pieces that are independent are kept separate
• Applicability
• We are looking for the 80/20 rule

23
What is a Reference Architecture?
Reference Architecture (vs.) Reference Model
Models the abstract architectural elements in the domain independent of the technologies, protocols, and products that are used to implement the domain Describes the important concepts and relationships in the domain focusing on what distinguishes the elements of the domain

• A reference architecture elaborates further on
  the modelto show a more complete picture that
  includes showing whatis involved in realizing
  the modeled entities

24
What is this RA?

• This Reference Architecture is an architectural
  description that documents (or describes) the
  abstract architectural elements of the paradigm
  that is SOA
• It focuses on the elements and their
  relationships needed to enable SOA-based systems
  to be used, realized, and owned

25
What is this RA?

• This Reference Architecture is an architectural
  description that documents (or describes) the
  abstract architectural elements of SOA-based
  systems
• It focuses on the elements and their
  relationships needed to enable SOA-based systems
  to be used, realized, and owned

26
Views and Viewpoints

• This RA uses the concepts of views and viewpoints
  as derived from the ANSI/IEEE Std 1471-2000 to
  describe system and software architectures
• A view is a representation of the whole system
  from the perspective of a related set of concerns
• Primarily comprised of models (although it has
  other attributes, e.g., textual descriptions)
• A viewpoint is a specification of the conventions
  for constructing and using a view
• Addresses stakeholders, their concerns, the
  language, modeling techniques, or analytical
  methods used in constructing views based on the
  viewpoint, and the source (if adapted from a
  viewpoint library)

27
Three Views of SOA

• Using a SOA-based system
• Captures what SOA means for people conducting
  their business
• Realizing a SOA-based system
• Deals with the requirements for constructing a
  SOA
• Owning a SOA-based system
• What are the issues involved in owning a
  SOA-based systems

28
Viewpoint Specifications
Viewpoint Element Viewpoint Viewpoint Viewpoint
Viewpoint Element Business via Services Realizing SOAs Owning SOAs
Main Concepts Captures what SOA means for people using it to conduct business Deals with the requirements for constructing a SOA Addresses issues involved in owning and managing a SOA
Stakeholders People (using SOA), Decision Makers, Enterprise Architects, Standards Architects and Analysts Standards Architects, Enterprise Architects, Business Analysts, Decision Makers, Standards Architects and Analysts Service Providers, Service Consumers, Decision Makers
Concerns Conduct business safely and effectively Effective construction of SOA-based systems Processes for engaging in a SOA are effective, equitable, and assured
Modeling Techniques UML class diagrams UML class and sequence diagrams, component and composite structure diagrams UML class diagrams
29
UML Conventions

• Visual modeling notation based on Object
  Management Group (OMG) Unified Modeling Language
  (UML)
• Every effort made to be compliant with latest
  normative standard (currently, UML V2.1.2
  Superstructure)
• Class diagrams reflect key concepts and
  relationships
• Primarily use named associations (rather than
  roles) to model key relationships
• Stereotypes used to assist in ambiguity
  resolution on some classifiers and to provide
  greater domain specialization

30
UML Conventions (2)
31
Business via Services View

• What does it mean to be part of a SOA
• Ownership boundaries
• Acting in a Social Context
• The role of policies and contracts

32
Stakeholders and Participants
We use a lot of UML in this RA
33
Resources and Ownership
Resources are foundational to the RA as a whole
34
Resources and Ownership
Ownership is foundational to using a SOA
35
Needs and Capabilities
Needs and Capabilities speak to participants
motivations
36
Acting in a Social Context
It is all about getting things done, in a social
context
It is all about interaction and communication
37
Semantics of Communication
Communication is founded on vocabulary, semantics
and intention
38
Roles and Responsibilities
There is a social context for everything we do
Clarity in rights and responsibilities is the
foundation for security
39
Governance
40
Realizing SOAs View
41
General Description Model

• Everything that is part of the SOA ecosystem can
  benefit from description
• Some things, like service, require description
  for the SOA paradigm to work

42
Service Description Model

• What it does
• How to access it
• How to communicate with it
• What are conditions of use
• Where to find measurements

43
Service Interface Model
Note addition of Event Model and question of how
that might extend Reference Model
44
Models Relating to Interaction and Policies
Policies and Contracts as related to Service
Participants
Service Reachability

• These models intended to ground description in
  places where it is used
• May be moved from Service Description and as
  consistent with Service Interaction and Policy
  sections

Policies and Contracts, Metrics, and Compliance
Records
45
Service Description and Action Relationship

• Classes in blue are leaf nodes in Service
  Description
• Service Description is more than an incidental
  artifact
• Service Description as integral information that
  comes together to get things done

46
Interacting with Services
47
Interaction Dependencies
48
Message Exchange Operations

• Message exchange is the means by which joint
  actions and event notifications of real world
  effects are coordinated by service participants
  (or their agents)
• Operations are the sequence of actions a service
  must perform in order to validly participate in a
  given joint action

49
Message Exchange Patterns (MEPs)
50
Composition of Services

• Composition of services is the act of aggregating
  or composing a single service from one or more
  other services
• There are atomic and composite services
• An atomic service is a service visible to a
  service consumer (or agent) via a single
  interface and described via a single service
  description that does not use or interact with
  other services
• A composite service is a service visible to a
  service consumer (or agent) via a single
  interface and described via a single service
  description that is the aggregation or
  composition of one or more other services. These
  other services can be atomic services, other
  composite services, or a combination of both

51
An Illustrative Example (Notional)
52
Service-Oriented Business Processes

• Service orientation as applied to business
  processes (i.e., service-oriented business
  processes) means that the aggregation or
  composition of all of the abstracted activities,
  flows, and rules that govern a business process
  can themselves be abstracted as a service
• Typically use a technique known as orchestration
  to compose hierarchical and self-contained
  service-oriented business processes that are
  executed and coordinated by a single agent acting
  in a conductor role

53
An Illustrative Example (Notional)
54
Service-Oriented Business Collaborations

• Service orientation as applied to business
  collaborations (i.e., service-oriented business
  collaborations) means that the aggregation or
  composition of all of the abstracted activities,
  flows, and rules that govern a business
  collaboration (peer style interaction) can
  themselves be abstracted as a service
• Typically use a technique known as choreography
  to characterize and to compose service-oriented
  business collaborations based on ordered message
  exchanges between peer entities in order to
  achieve a common business goal

55
An Illustrated Example (Notional)
56
Service Reachability Model
57
Visibility Model
58
Awareness Model
59
Description and Willingness
60
Policies and Contracts

• A Policy is an enforceable constraint on the
  behavior and states of participants and resources
  that is adopted by a stakeholder
• A Contract is an enforceable constraint on the
  behavior and states of participants and resources
  that is agreed to by two or more participants

61
Policies and Contracts
62
Interacting with Services
63
Message Exchange
64
Policy Constraints
Its all about constraints
65
Enforcing Policy Constraints
Obligation Enforcement is based on audit
66
Owning SOAs View
67
Owning SOA-based systems

• Focuses on functions required in achieve value
  for the enterprise by owning a SOA-based system
• Significantly different challenges to owning
  other complex systems -- such as Enterprise
  suites
• Strong limits on the control and authority of any
  one party when a system spans multiple ownership
  domains
• Applicable when multiple internal stakeholders
  involved and no simple hierarchy of control and
  management

68
Governance of SOA-based systems

• Governance about how decisions are made
• Management is about how decisions are realized
• Nested management at one level is governance at
  another

69
How SOA Governance is Different

• SOA governance is organization of services that
• promotes their visibility
• facilitates interaction among service
  participants
• enforces that the results of service interactions
  are
• those real world effects as described within the
  service description
• constrained by policies and contracts as
  assembled in the execution context
• SOA governance must specifically account for
  control across different ownership domains
• All the participants may not be under the
  jurisdiction of a single governance authority
• Participants must agree to recognize authority of
  the Governance Body, operate within the
  Governance Framework and through the Governance
  Processes

70
What Needs to be Governed

• SOA infrastructure the plumbing that provides
  utility functions that enable and support the use
  of the service
• Service inventory the requirements on a service
  to permit it to be accessed within the
  infrastructure
• Participant interaction the consistent
  expectations with which all participants are
  expected to comply

71
SOA Governance Model (1)
Motivating Governance
Carrying Out Governance
SOA governance builds off general governance
concepts
72
SOA Governance Model (2)
Carrying Out Governance
Ensuring Governance Compliance
73
Management
Management of Services rather than simply IT
Management
74
Security

• Security Concepts
• e.g., Confidentiality, ..., Availability
• Trust Model
• e.g., Trusted Actions, Trust Domain, Security
  Policy Mechanisms
• Security Layers
• e.g., Network, Transport, Application
• Security Threat/Response Model
• e.g. Risk analysis and threat mitigation

75
Security Concepts

• Confidentiality protection of privacy
• Integrity information exchanged has not been
  altered
• Availability prevention of denial of service
  attacks
• Authentication identification and credentials
• Authorization approval exchanged of
  information, actions, and events
• Non-repudation can not deny action

76
Where SOA Security is Different

• Flexible and dynamically secure computing
  interactions in support of a computing ecosystem
  with multiple governance domains
• Greater degree of distributed mechanisms
• Additional auditing and reporting for regulatory
  compliance

77
Trust Model
78
Trust Domain

• Policy-based security must support multiple trust
  domains

79
Centralized Trust Authority
80
Decentralized Trust Authority
81
Policy Mechanisms for Security
82
Security Layers

• Condensed Open Systems Interconnection (OSI)
  Basic Reference 7-Layer Model
• SOA emphasis on trusted application layer
  messaging/actions/events

83
Security Threat/Response Model

• Some common threats to service interaction
• Insider attacks and outsider attacks
• Message alteration, message interception, denial
  of service, false repudiation
• Security Response Model
• Involves risk assessment and risk mitigation and
  acceptable levels of costs
• Example mitigation of common service interaction
  threats

84
Where we are

• Been active for nearly two years
• Most of the material is in place
• 100 page document
• Plan to issue first OASIS Public Review in early
  May
• Emphasis on the relationship between people and
  the systems they live with

85
Comments and Questions?