1. McLean, VA May 23, 2006 SOA: Reference Model, Standards and Specifications This document is confidential and is intended solely for the use and information of the client to whom it is addressed.

2. 1 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

3. 2 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

4. 3 SOA benefits uniquely address a rapidly changing environment Agility  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  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 Process  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  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 Interoperability  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  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 Costs  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  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

5. 4 SOA allows end-to-end flexibility in meeting user needs Web Services provide standard interfaces between disparate systems DatabaseNetworkDataUser Power PlantDVD Player Electric Outlet Power GridElectricity Web Service ConsumerProductService InterfaceInfrastructureProvider Power SOA

6. 5 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

7. 6 SOA transactions require answering five key questions 1.How can the Consumer dynamically discover the existence of a Provider, which can provide the services being requested? 2.Assuming the Consumer knows of the Provider’s existence, how can it locate the Provider? 3.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? 4.Assuming they have described themselves, how can they exchange messages in a common messaging format which is independent of their underlying platforms? 5.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 1 “Service Consumer” Application 2 “Service Provider”

8. 7 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

9. 8 Foundation for SOA implementations: a reference model, reference architectures, standards and specifications

10. 9 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

11. 10 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

12. 11 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

13. 12 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: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rmhttp://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm –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

14. 13 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

15. 14 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

16. 15 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 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

17. 16 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

18. 17 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

19. 18 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

20. 19 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 1.That the service exists and is reachable 2.That the service performs a certain function or set of functions 3.That the service operates under a specified set of constraints and policies 4.That the service will (to some implicit or explicit extent) comply with policies as prescribed by the service consumer 5.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

21. 20 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

22. 21 Standardization plays a key role in realization of SOA architectural characteristics Benefits Leverages existing IT investments Break down data silos Promote agile business practices to meet changing business needs Emphasis on business logic and less on plumbing Reuse functions both internally and externally Bring new functionality online without disrupting existing business Reduce resources needed to complete existing work Increased cross-organizational information visibility Abstract heterogeneity “ 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 1471-2000 Characteristics High Interoperability Loose Coupling Location Transparency

23. 22 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)

24. 23 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

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

26. 25  How do web services know where to “locate” another web service? Web Service standards today address key SOA-RM concepts Key Question Nature of Standards Required Standards  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  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 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 SOA-RM Concept Visibility Service Description

27. 26 Key standards work together to realize web services interaction 1 2 3 5 8 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  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 1 2 3 4 5 6 7 8 Application 1 “Service Consumer” Application 2 “Service Provider” UDDI Service Registry 4 67

28. 27 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

29. 28 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

30. 29 Service specifications bring together standards as part of a technical solution to a business problem  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 Reference Model 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

31. 30 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

32. 31 How should I apply this knowledge to my organizations SOA initiatives? Start today, be decisive, and follow a methodology Formulate SOA Solution Strategy Build SOA Business Case Establish Program Management Architect SOA Solution Operate SOA Environment Implement SOA Solution SOA 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 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 1 2 3 4 5 6 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

33. 32 Acknowledgements  SOA-RM Editors –C. Matthew MacKenzie, Adobe Systems Incorporated, mattm@adobe.commattm@adobe.com –Ken Laskey, MITRE Corporation, klaskey@mitre.orgklaskey@mitre.org –Francis McCabe, Fujitsu Limited, frank.mccabe@us.fujitsu.comfrank.mccabe@us.fujitsu.com –Peter Brown, peter@justbrown.netpeter@justbrown.net –Rebekah Metz, Booz Allen Hamilton, metz_rebekah@bah.commetz_rebekah@bah.com  Other members of the SOA-RM TC here –Chris Bashioum, MITRE, cbashioum@mitre.org –Joe Chiusano, Booz Allen Hamilton, chiusano_joseph@bah.com

34. 33 Questions? Rebekah Metz Booz Allen Hamilton Telephone: 703.377.1471 Email: metz_rebekah@bah.com