SOA: Reference Model, Standards and Specifications

SOA: Reference Model, Standards and Specifications
McLean, VA May 23, 2006 Booz Allen Hamilton Standard Colors Colors should be used in the color pairs whenever possible. Do not mix and match colors, use pairs together as shown. Black, White and Gray can be used with any of the other colors. This document is confidential and is intended solely for the use and information of the client to whom it is addressed. Purple Pantone 2765 R 12 G 4 B 79 Green Pantone 357 R 15 G 67 B 24 Blue Pantone 2 88 R 11 G 31 B 101 Pantone Cool Gray 6 R 158 G 158 B 158 Black Red Pantone 485 R 252 G 5 B 14 Yellow Pantone 3965 R 232 G 244 B 4 Aqua Pantone 319 R 126 G 204 B 189 White

Table of Contents Service Oriented Architecture & Web Services
Reference Models as part of Service Oriented Architecture OASIS SOA Reference Model Standards within Service Oriented Architecture Specifications and profiles in Service Oriented Architecture

Capabilities performed by one for another to achieve a desired outcome
SOA is an integration paradigm that encourages organizations to re-think how their IT capabilities are organized SOA is an architecture approach for organizing and using services to support interoperability between enterprise data assets and applications Capabilities performed by one for another to achieve a desired outcome Service S The fundamental organization of a system by its capabilities, their interactions, and the enterprise environment Architecture A Aligning architecture to enable a collection of services to be linked together to solve a business problem Oriented O

SOA benefits uniquely address a rapidly changing environment
Agility Process Interoperability Costs Focus more on core competencies and missions by creating a network of producers-suppliers with intense interactions Improve access to information to enable faster cycle times Enable enterprises to be more agile and respond quickly to business needs Increase business flexibility through plug-and-play architecture and re-use of existing services Ensure system change is not a constraint on business or mission change Allow interoperation with other systems & partners without customization Facilitate integration with multiple solutions via open IT standards Remain platform, language, and vendor independent to remove IT barriers for using best-of-breed software packages Reduce development costs by acquiring pre-built capabilities Leverage previous IT investments through re-use of assets Lower maintenance costs and TCO through fewer “instances” of a function, and fewer software licenses IT alignment with an organization’s mission Improved agility, focus on core competencies, IT efficiencies, and ROI for IT assets

SOA allows end-to-end flexibility in meeting user needs
Web Services provide standard interfaces between disparate systems Database Network Data User Power Plant DVD Player Electric Outlet Power Grid Electricity Web Service Consumer Product Service Interface Infrastructure Provider Power SOA

Web services are a tactical means to achieve the strategic SOA goal
Web Services are a technical solution to enable SOA SOA codifies the organization’s enterprise strategy for connecting systems to provide common discovery, security, and management of those connections Web services have specific guidelines on messaging interactions between services – the tactical implementation of an SOA model Thus, Web Services are a specific subset of how an SOA can be implemented SOA Web Services

SOA transactions require answering five key questions
Application 1 “Service Consumer” How can the Consumer dynamically discover the existence of a Provider, which can provide the services being requested? Assuming the Consumer knows of the Provider’s existence, how can it locate the Provider? Assuming the Consumer has located the Provider, how can the two describe how to connect to each other, in a standard format which can be understood regardless of their IT platforms? Assuming they have described themselves, how can they exchange messages in a common messaging format which is independent of their underlying platforms? Assuming they have agreed upon a common messaging format, what data format can they use to exchange data independent of their underlying database technologies? Application 2 “Service Provider”

Foundation for SOA implementations: a reference model, reference architectures, standards and specifications Figure shows how a reference model for SOA relates to other distributed systems architectural inputs. The concepts and relationships defined by the reference model are intended to be the basis for describing references architectures and patterns that will define more specific categories of SOA designs. Concrete architectures arise from a combination of reference architectures, architectural patterns and additional requirements, including those imposed by technology environments. Architecture is not done in isolation but must account for the goals, motivation, and requirements that define the actual problems being addressed. While reference architectures can form the basis of classes of solutions, concrete architectures will define specific solution approaches. Architecture is often developed in the context of a pre-defined environment, such as the protocols, profiles, specifications, and standards that are pertinent. SOA implementations combine all of these elements, from the more generic architectural principles and infrastructure to the specifics that define the current needs, and represent specific implementations that will be built and used in an operational environment.

What is a reference model?
Minimal set of unifying concepts, axioms and relationships within a particular problem domain Abstract framework for understanding significant relationships among the entities of some environment Independent of specific standards, technologies, implementations, or other concrete details Content Courtesy: Ken Laskey, MITRE

How a reference model complements other architecture concepts
Reference Architecture - abstract solutions (using concepts from housing RM) to the problems of providing housing General pattern for housing that addresses the needs of some set of occupants Eating area is a reference model concept, a kitchen is a realization of eating area in the context of the reference architecture More than one reference architecture addresses requirements for developing solutions Large apartment complexes – compact kitchen Suburban single family houses – large kitchen Dormitories – common kitchen Space stations – specially-equipped kitchen Content Courtesy: Ken Laskey, MITRE

The OASIS Service-Oriented Architecture Reference Model Technical Committee (SOA-RM TC) was chartered in February 2005 Charter: Developing a core reference model to guide and foster the creation of specific, service-oriented architectures Objectives: Publish a reference model for SOA. Publish a reference Service Oriented Architecture that tracks to the reference model Home page: See “Documents” section for latest version of specification Participating organizations include: Adobe - Computer Associates BEA Department of Homeland Security Boeing Fujitsu Booz Allen Hamilton - Lockheed Martin Cap Gemini - Mitre Corporation The TC is preparing for a second public review of the document

SOA-RM – Goals and motivations
Why develop SOA-RM? SOA has received significant attention within the software design and development community Proliferation of many conflicting definitions (or simply imprecise use) of SOA What intend to provide? Common conceptual framework that can be used consistently across and between different implementations Common semantics that can be used unambiguously in modeling specific solutions Unifying concepts to explain and underpin a generic design template supporting a specific SOA Definitions that should apply to all SOA Content Courtesy: Ken Laskey, MITRE

Content Courtesy: Ken Laskey, MITRE
Users of the SOA-RM Architects and developers designing, identifying or developing a system based on the service- oriented paradigm Standards architects and analysts developing specifications that rely on service oriented architecture concepts Decision makers seeking a "consistent and common" understanding of service oriented architectures Users who need a better understanding of the concepts and benefits of service oriented architecture Content Courtesy: Ken Laskey, MITRE

The perceived value of SOA is that that it provides a
The OASIS SOA Reference Model is centered around the notions of “needs” and “capabilities” SOA is “a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains” (OASIS SOA Reference Model Committee Draft) Entities (people and organizations) create capabilities to solve or support a solution for the problems they face in the course of their business Just as one person’s needs may be met by capabilities offered by someone else There is not necessarily a one-to-one correlation between needs and capabilities The granularity of needs and capabilities are driven by the business, therefore they vary from fundamental to complex Any given need may require the combining of numerous capabilities, while any single capability may address more than one need Examples: Using a hammer, purchasing a house The perceived value of SOA is that that it provides a powerful framework for matching needs and capabilities, and for combining capabilities to address those needs

The OASIS SOA reference model – Central concepts
Service Dynamics of Services Visibility Interacting with services Real World Effect About services Service description Policies and Contracts Execution context

Service description Represents the information needed in order to use a service Facilitate visibility and interaction between participants in service interactions No one “right” description Elements of description required depend on the context and the needs of the parties using the associated entity Certain elements that are likely to be part of any service description (e.g the information mode) but many elements such as function and policy may vary Best practice suggests that the service description SHOULD be represented using a standard, referenceable format standard, referenceable format - Facilitates use of common processing tools (such as discovery engines) that can capitalize on the service description

Service Description – What goes into it
Service description makes available critical information that a consumer needs to decide whether or not to use a service That the service exists and is reachable That the service performs a certain function or set of functions That the service operates under a specified set of constraints and policies That the service will (to some implicit or explicit extent) comply with policies as prescribed by the service consumer How to interact with the service in order to achieve the required objectives, where how-to information includes the format and content of information exchanged the sequences of information exchange that may be expected Each of these items SHOULD be represented in any service description Details can be included through references (links) to external sources and are NOT REQUIRED to be incorporated explicitly Inclusion by reference enables reuse of standard definitions, such as for functionality or policies importance of consumer description Following discussion is how each of 5 concept relates to description: some have already been defined and others will be shortly how does exists and reachable translate to visibility

Standardization plays a key role in realization of SOA architectural characteristics
“An architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.” IEEE STD Benefits Characteristics Reduce resources needed to complete existing work Increased cross-organizational information visibility Abstract heterogeneity Location Transparency Leverages existing IT investments Break down data silos Promote agile business practices to meet changing business needs High Interoperability Emphasis on business logic and less on plumbing Reuse functions both internally and externally Bring new functionality online without disrupting existing business Loose Coupling

Open standards play a key role in shaping today’s SOA landscape
A standard is a set of detailed technical guidelines that establishes uniformity Define a shared meaning that can drive commoditization of services Reflects horizontal requirements from a generic problem domain Considers broader applications and process models Encourages levels of interoperability Characteristics Publicly available Developed by a process which sought a high level of consensus from a wide variety of sources Supported by a range of readily available products “Open standards are important to help create interoperable and affordable solutions for everybody.” (Source: Erkki Liikanen World Standards Day, 14 October 2003)

Several industry consortia develop standards to shape the technology landscape
World Wide Web Consortium (W3C): W3C was created in October 1994 to lead the World Wide Web to its full potential by developing common protocols that promote its evolution and ensure its interoperability Organization for the Advancement of Structured Information Standards (OASIS): OASIS is a not-for-profit, global consortium that drives the development, convergence, and adoption of e-business standards Web Services Interoperability Organization (WS-I) : WS-I is an open, industry organization chartered to promote Web services interoperability across platforms, operating systems, and programming languages

Web Services standards are still emerging and being adopted by business
Need Standard = In place Business Semantics Identity Mgmt Liberty, Passport Building Trust WS-Security, Security Assertions Markup Language (SAML) Emerging User Interface Web Services for Remote Portals (WSRP), Web Services User Interface (WSUI) Process Interaction WS-Transaction, BPEL4 WS, WSCI Established Search & Find Universal Description, Discovery & Integration (UDDI) Description Web Services Definition Language (WDSL) Message SOAP Entrenched Format Extensible Markup Language (XML) Transport Common internet protocols (TCP/IP, HTTP, etc) Source: Gartner

Web Service standards today address key SOA-RM concepts
Key Question Nature of Standards Required Standards Visibility How can web services dynamically “discover” the existence of other web services? Standard method for defining and identifying web services Public registry of web services and their locations, which can be queried by any web service over HTTP Universal Discovery, Description and Integration (UDDI) How do web services know where to “locate” another web service? Service Description How can web services universally “describe” how to connect to themselves ? Standard language to describe how to connect to a web service Web Services Description Language (WSDL) What “data formats” can web services universally use? Standard data format transportable over Internet protocols Extensible Markup Language (XML) What “messaging formats” can web services universally use? Standard messaging format which conveys instructions on what to do with the data SOAP

Key standards work together to realize web services interaction
High Level Description Web Service Provider (Provider) develops its description and specifies its interfaces using WSDL, and registers itself in the public UDDI registry Web Service Consumer (Consumer) queries the UDDI registry in real time, and discovers that Provider has services it is looking for Consumer downloads Provider’s WSDL specification from the Provider (including the format of SOAP messages the Provider can accept) Consumer then develops a request in the form of an XML based SOAP message (using a SOAP engine to translate from its native format to SOAP) Consumer then “calls” Provider by sending the SOAP message over HTTP Provider receives the SOAP message and translates to its own native format using a SOAP decoder Provider composes a reply as a SOAP message in a format which can be understood by Consumer (the incoming SOAP message from Consumer also includes information on the format of SOAP messages it can accept) Provider then “replies” to Consumer by sending the SOAP message over HTTP Application 1 “Service Consumer” 1 4 2 3 3 2 4 UDDI Service Registry 5 8 5 6 1 7 6 7 8 Application 2 “Service Provider”

Specifications: Harmonize standards within an architecture context
Define fundamental functionality What standards address the capabilities and requirements? What are the communication patterns? Stipulate interfaces as selection of options within a set of standards What are the public interfaces for the service? What are the calling mechanisms? Address dependencies between functionality and interfaces What are the significant architectural decisions to analyze? What are the dependencies and interrelationships between applicable standards? A specification defines the interfaces thru which existing standards (or set of standards) are applied as a solution to a particular integration challenge

Reference Architecture
Service specifications bring together standards as part of a technical solution to a business problem Reference Model Service specifications establish architectural requirements, document functionality to support them, and identify the standards which facilitate Encourage implementation of appropriate information technology to meet business needs Consider organization-specific requirements, implementations, and business rules Aggregate applicable standards into cohesive units of functionality Harmonize standards to achieve a particular architectural goal Reference Architecture Messages XML (standard data representation) SOAP Headers, Body & Extensions Descriptions Web Service Interfaces (WSDL) Processes Discovery, Aggregation, Choreography Communications & Standards Networking Layer MANAGEMENT SECURITY (Authentication, Authorization, Policy…) Specification Based Architecture

A specification describes a capability defined by the architecture
Describe and communicate, in varying levels of abstraction, the context in which a service operates; the boundaries across which interaction occurs; meanings that are described in terms of observable effects Information Model (The information exchanged) Describe the capability provided by the service in terms of inputs and outputs Describes the expected input and output data model Outlines the available metadata for the service that will be published and searchable Interface Model (That the service exists) Describes the interface Describes available operations Describes any faults that may be generated by an individual operation Behavior Model (How to interact with the service) How the service interacts with other services Describes the underlying processing rules of the service Describes the multiple integration patterns available to use this service Fault Model (How the service fails) Describes how the service will handle faults Describe under which conditions a fault may be returned to the consumer Quality Model (Constraints and policies) Describes the security requirements of the service Describe the quality of service provided Describes any performance considerations for deploying the service Recall that SOA is about organizing capabilities and needs Ties back to the main concepts for a service description as part of the SOA-RM Example: Maps to the Service Description Framework currently being vetted within the DOD Interface Security Service Level Implementation POC Service Access Point

How should I apply this knowledge to my organizations SOA initiatives
How should I apply this knowledge to my organizations SOA initiatives? Start today, be decisive, and follow a methodology Perform technology portfolio assessment Evaluate current technology environment and build a service portfolio Determine SOA related criteria for services portfolio analysis Complete portfolio analysis to establish service fielding priorities Develop a SOA roadmap and strategic guidance 1 2 Formulate SOA Solution Strategy Operate SOA Environment Build SOA Business Case Develop business case to support SOA investment Support SOA strategy with rigorous business case analysis Establish pertinent business case metrics Account for cost, ROI, and risk management in SOA investment decisions 6 SOA Methodology 3 Establish Program Management Implement SOA Solution Architect SOA Solution Develop and implement change management strategy Engage stakeholders continuously Create needed collaborations and governance structures Incentivize participation Identify progress metrics and milestones Reinforce organizational changes Establish management controls 5 4

Acknowledgements SOA-RM Editors
C. Matthew MacKenzie, Adobe Systems Incorporated, Ken Laskey, MITRE Corporation, Francis McCabe, Fujitsu Limited, Peter Brown, Rebekah Metz, Booz Allen Hamilton, Other members of the SOA-RM TC here Chris Bashioum, MITRE, Joe Chiusano, Booz Allen Hamilton,

Questions? Rebekah Metz Booz Allen Hamilton Telephone: 703.377.1471

SOA: Reference Model, Standards and Specifications

Similar presentations

Presentation on theme: "SOA: Reference Model, Standards and Specifications"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

SOA: Reference Model, Standards and Specifications

Similar presentations

Presentation on theme: "SOA: Reference Model, Standards and Specifications"— Presentation transcript:

Similar presentations

About project

Feedback