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?
Pages to are hidden for
"Reference Architecture for SOA (OASIS SOA-RM TC work in-progress)"Please download to view full document