reference architecture for soa oasis soa rm tc work in progress n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Reference Architecture for SOA (OASIS SOA-RM TC work in-progress) PowerPoint Presentation
Download Presentation
Reference Architecture for SOA (OASIS SOA-RM TC work in-progress)

Loading in 2 Seconds...

play fullscreen
1 / 85

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


  • 119 Views
  • Uploaded on

Reference Architecture for SOA (OASIS SOA-RM TC work in-progress) . Frank McCabe Jeff Estefan Ken Laskey Danny Thornton. Agenda. * Minutes. Introduction. SOA as eco system Primary concepts from Reference Model Plan for the tutorial. Systems and Eco-systems. Multiple ownership domains

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Reference Architecture for SOA (OASIS SOA-RM TC work in-progress)' - oshin


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
reference architecture for soa oasis soa rm tc work in progress

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

Frank McCabe

Jeff Estefan

Ken Laskey

Danny Thornton

agenda
Agenda

*Minutes

introduction
Introduction
  • SOA as eco system
  • Primary concepts from Reference Model
  • Plan for the tutorial
systems and eco systems
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’

reference model for soa
Reference Model for SOA

It’s an OASIS Standard

what is a reference model
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.
service oriented architecture
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
why is it different
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
service
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
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
interaction
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
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

conditions and expectations
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
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
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

plan for tutorial
Plan for Tutorial
  • Structure of the Reference Architecture
  • Three Views in Detail
    • Business via Service View
    • Realizing SOAs View
    • Owning SOAs View
this architecture
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
architectural principles
Architectural Principles
  • Technology Neutrality
    • We want to focus on the issues
  • Parsimony
    • Ockham’s razor at work
  • Separation of Concerns
    • Pieces that are independent are kept separate
  • Applicability
    • We are looking for the 80/20 rule
what is a reference architecture
What is a “Reference Architecture”?
  • A reference architecture elaborates further on the modelto show a more complete picture that includes showing whatis involved in realizing the modeled entities
what is this ra
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
what is this ra1
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
views and viewpoints
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)
three views of soa
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
uml conventions
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
business via services view
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
stakeholders and participants
Stakeholders and Participants

We use a lot of UML in this RA

resources and ownership
Resources and Ownership

Resources are foundational to the RA as a whole

resources and ownership1
Resources and Ownership

Ownership is foundational to using a SOA

needs and capabilities
Needs and Capabilities

Needs and Capabilities speak to participants’ motivations

acting in a social context
Acting in a Social Context

It is all about getting things done, in a social context

It is all about interaction and communication

semantics of communication
Semantics of Communication

Communication is founded on vocabulary, semantics and intention

roles and responsibilities
Roles and Responsibilities

There is a social context for everything we do

Clarity in rights and responsibilities is the foundation for security

general description model
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
service description model
Service Description Model
  • What it does
  • How to access it
  • How to communicate with it
  • What are conditions of use
  • Where to find measurements
service interface model
Service Interface Model

Note addition of Event Model and question of how that might extend Reference Model

models relating to interaction and policies
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

service description and action relationship
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
message exchange operations
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
composition of services
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
service oriented business processes
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
service oriented business collaborations
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
policies and contracts
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
policy constraints
Policy Constraints

Its all about constraints

enforcing policy constraints
Enforcing Policy Constraints

Obligation Enforcement is based on audit

owning soa based systems
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
governance of soa based systems
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
how soa governance is different
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
what needs to be governed
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
soa governance model 1
SOA Governance Model (1)

Motivating Governance

Carrying Out Governance

SOA governance builds off general governance concepts

soa governance model 2
SOA Governance Model (2)

Carrying Out Governance

Ensuring Governance Compliance

management
Management

Management of Services rather than simply IT Management

security
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
security concepts
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
where soa security is different
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
trust domain
Trust Domain
  • Policy-based security must support multiple trust domains
security layers
Security Layers
  • Condensed Open Systems Interconnection (OSI) Basic Reference 7-Layer Model
  • SOA emphasis on trusted application layer messaging/actions/events
security threat response model
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
where we are
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