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

VIEWS: 36 PAGES: 85

									                     www.oasis-open.org




Reference Architecture for
SOA (OASIS SOA-RM TC work
in-progress)
  Frank McCabe
  Jeff Estefan
  Ken Laskey
  Danny Thornton
Agenda
  Duration* Topic                        Presenter
  30        Introduction                 McCabe
  30        This Architecture            Estefan
  45        Business via Services View   McCabe
  15        Q&A
  30        Break
  45        Realizing SOAs View          Laskey/Estefan
  30        Owning SOAs View             Laskey/Thornton
  15        Q&A

*Minutes
Introduction
   SOA as eco system
   Primary concepts from Reference
    Model
   Plan for the tutorial
 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
                   It’s an OASIS Standard
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 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?
   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
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
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
Where the RA fits
Plan for Tutorial
   Structure of the Reference Architecture
   Three Views in Detail
       Business via Service View
       Realizing SOAs View
       Owning SOAs View
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
Goals of this Architecture
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”?
  Reference Architecture (vs.) Reference Model
  Models the abstract           Describes the important
  architectural elements in     concepts and
  the domain independent        relationships in the
  of the technologies,          domain focusing on what
  protocols, and products       distinguishes the
  that are used to              elements of the domain
  implement the domain

 A reference architecture elaborates further on the model
  to show a more complete picture that includes showing what
  is involved in realizing the modeled entities
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 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
   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
  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
  Viewpoint Specifications

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




We use a lot of UML in this RA
  Resources and Ownership




Resources are foundational to the RA as a whole
Resources and Ownership




                   Ownership is foundational
                   to using a SOA
     Needs and Capabilities




Needs and Capabilities speak to participants’
motivations
     Acting in a Social Context




                                  It is all about getting things done, in a
It is all about interaction and   social context
communication
Semantics of
Communication




  Communication is founded on vocabulary, semantics and intention
     Roles and Responsibilities
                                                There is a social context for everything we do




Clarity in rights and responsibilities is the
foundation for security
Governance
Realizing SOAs View
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
•   What it does
•   How to access it
•   How to communicate with it
•   What are conditions of use
•   Where to find measurements
   Service Interface Model




Note addition of Event Model and question of how that might extend Reference Model
       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
                      • 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
Interacting with Services
Interaction Dependencies
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
Message Exchange
Patterns (MEPs)
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
An Illustrative Example
(Notional)
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
An Illustrative Example
(Notional)
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
An Illustrated Example
(Notional)
Service Reachability Model
Visibility Model
Awareness Model
Description and
Willingness
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
Policies and Contracts
Interacting with Services
Message Exchange
Policy Constraints




                     Its all about constraints
Enforcing Policy
Constraints




  Obligation Enforcement is based on audit
Owning SOAs View
    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 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
   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
   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)




      Motivating Governance                      Carrying Out Governance



 SOA governance builds off general governance concepts
SOA Governance Model (2)




  Carrying Out Governance




                            Ensuring Governance Compliance
     Management




Management of Services rather than simply IT Management
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
   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
   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 Model
Trust Domain

   Policy-based security must support
    multiple trust domains
Centralized Trust Authority
Decentralized Trust
Authority
Policy Mechanisms for
Security
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
   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
  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
                  www.oasis-open.org




Comments and Questions?

								
To top