Reference Architecture for SOA (OASIS SOA-RM TC work in-progress) Frank McCabe Jeff Estefan Ken Laskey Danny Thornton

Agenda Duration*TopicPresenter 30IntroductionMcCabe 30This ArchitectureEstefan 45Business via Services ViewMcCabe 15Q&A 30Break 45Realizing SOAs ViewLaskey/Estefan 30Owning SOAs ViewLaskey/Thornton 15Q&A *Minutes

Introduction n SOA as eco system n Primary concepts from Reference Model n 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 n An abstract framework for understanding significant relationships among the entities of some environment. n Consists of a minimal set of unifying concepts, axioms and relationships within a particular problem domain. n Is independent of specific standards, technologies, implementations, or other concrete details.

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

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

Key concepts

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

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

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 n Policy l Constraint representing the intention of a participant in a service n Contract l 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 n Structure of the Reference Architecture n Three Views in Detail l Business via Service View l Realizing SOAs View l Owning SOAs View

This Architecture n Architectural goals & principles n What is a reference architecture? n What is this RA? n Views and viewpoints n Three views of SOA n Viewpoint specifications n 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 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 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 n This RA uses the concepts of views and viewpoints as derived from the ANSI/IEEE Std to describe system and software architectures n A view is a representation of the whole system from the perspective of a related set of concerns l Primarily comprised of models (although it has other attributes, e.g., textual descriptions) n A viewpoint is a specification of the conventions for constructing and using a view l 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 Element Viewpoint Business via ServicesRealizing SOAsOwning SOAs Main ConceptsCaptures 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 StakeholdersPeople (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 ConcernsConduct business safely and effectively Effective construction of SOA-based systems Processes for engaging in a SOA are effective, equitable, and assured Modeling TechniquesUML class diagramsUML class and sequence diagrams, component and composite structure diagrams UML class diagrams

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

UML Conventions (2)

Business via Services View n What does it mean to be part of a SOA n Ownership boundaries n Acting in a Social Context n 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 interaction and communication It is all about getting things done, in a social context

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 Service Reachability Policies and Contracts as related to Service Participants Policies and Contracts, Metrics, and Compliance Records 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

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 n Message exchange is the means by which joint actions and event notifications of real world effects are coordinated by service participants (or their agents) n 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 n Composition of services is the act of aggregating or “composing” a single service from one or more other services n There are “atomic” and “composite” services l 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 l 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 n 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 n 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 n 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 n 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 n A Policy is an enforceable constraint on the behavior and states of participants and resources that is adopted by a stakeholder n 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 n Focuses on functions required in achieve value for the enterprise by owning a SOA-based system n Significantly different challenges to owning other complex systems -- such as Enterprise suites n Strong limits on the control and authority of any one party when a system spans multiple ownership domains n Applicable when multiple internal stakeholders involved and no simple hierarchy of control and management

Governance of SOA-based systems n Governance about how decisions are made n Management is about how decisions are realized n Nested – management at one level is governance at another

How SOA Governance is Different n SOA governance is organization of services that l promotes their visibility l facilitates interaction among service participants l enforces that the results of service interactions are n those real world effects as described within the service description n constrained by policies and contracts as assembled in the execution context n SOA governance must specifically account for control across different ownership domains l All the participants may not be under the jurisdiction of a single governance authority l 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 n SOA infrastructure – the “plumbing” that provides utility functions that enable and support the use of the service n Service inventory – the requirements on a service to permit it to be accessed within the infrastructure n Participant interaction – the consistent expectations with which all participants are expected to comply

SOA Governance Model (1) Motivating GovernanceCarrying 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 n Security Concepts l e.g., Confidentiality,..., Availability n Trust Model l e.g., Trusted Actions, Trust Domain, Security Policy Mechanisms n Security Layers l e.g., Network, Transport, Application n Security Threat/Response Model l e.g. Risk analysis and threat mitigation

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

Where SOA Security is Different n Flexible and dynamically secure computing interactions in support of a computing ecosystem with multiple governance domains n Greater degree of distributed mechanisms n Additional auditing and reporting for regulatory compliance

Trust Model

Trust Domain n Policy-based security must support multiple trust domains

Centralized Trust Authority

Decentralized Trust Authority

Policy Mechanisms for Security

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

Security Threat/Response Model n Some common threats to service interaction l Insider attacks and outsider attacks l Message alteration, message interception, denial of service, false repudiation n Security Response Model l Involves risk assessment and risk mitigation and acceptable levels of costs l 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

Comments and Questions?