1. 2005 Adobe Systems Incorporated. All Rights Reserved. 1 An Introduction to the OASIS Reference Model for Service Oriented Architecture (SOA) Duane Nickull Senior Technical Evangelist Adobe Systems, Inc.

2. 2005 Adobe Systems Incorporated. All Rights Reserved. 2 Before we talk about SOA and where we want to go…  Would be nice if we had consensus on what SOA is!  SOA is an architectural paradigm (model). So how do we express it as architecture?  Is it sufficiently different from other types of architecture? If SOA is “X”, what is not SOA?  SOA does not specifically mean Web Services although WS is a popular implementation of SOA.

3. 2005 Adobe Systems Incorporated. All Rights Reserved. 3 Defining SOA…  Should not do it by referencing an implementation.  If SOA is Architecture, it should be definable using a normative ADL.  A Reference Model is a good mechanism to define SOA.  Why? (next slide).

4. 2005 Adobe Systems Incorporated. All Rights Reserved. 4 The Reference Model for SOA…  Is not intended to be architecture for a single SOA system.  Is an ABSTRACT model for a range of Service Oriented architectures and analysis / comparison thereof.  Is a framework for understanding significant relationships among the entities in a SOA environment.  Is based on a small number of unifying concepts of all SOA’s.

5. 2005 Adobe Systems Incorporated. All Rights Reserved. 5 How does a RM relate to other stuff?

6. 2005 Adobe Systems Incorporated. All Rights Reserved. 6 So what is SOA exactly?  A paradigm for organizing and using distributed capabilities that may be under the control of different ownership domains.  A framework for matching needs and capabilities.  A view of architecture focusing on “Services” as a mechanism to allows interactions between those with needs and capabilities.

7. 2005 Adobe Systems Incorporated. All Rights Reserved. 7 Core Model for SOA Dynamic perspective: 3 base concepts for interacting with services: the visibility between service and consumers; the interaction between them, and real world effect of interacting with a service.

8. 2005 Adobe Systems Incorporated. All Rights Reserved. 8 Additional Service concepts

9. 2005 Adobe Systems Incorporated. All Rights Reserved. 9 Core Concepts for SOA - expanded

10. 2005 Adobe Systems Incorporated. All Rights Reserved. 10 Core Concepts of SOA (Definitions)  Service: A mechanism by which needs and capabilities are brought together.  Service Description: Artifact declaring all relevant aspects of a service required to interact with the service.  Capability: an ability to perform a specific set of functions resulting in a real world effect.  Visability: The capacity for those with needs and those with capabilities to see each other and interact.

11. 2005 Adobe Systems Incorporated. All Rights Reserved. 11 Core Concepts of SOA (DRAFT)  Execution Context: Set of technical/business elements that form path between those with needs and capabilities. Permits information to be exchanged, actions to be performed and provides a decision point for any policies and contracts that may be in force.  Policy: A set/range of constraints imposed on any entity when invoking a service. If ignored, the invocation request may be denied.

12. 2005 Adobe Systems Incorporated. All Rights Reserved. 12 Core Concepts of SOA (DRAFT)  Exchange: The act whereby two or more entities come together within the context of a single interaction.  Real World Effect: The result of an interaction with a service.  Interchange: the activity of using the capability. An “act” rather than an “object”

13. 2005 Adobe Systems Incorporated. All Rights Reserved. 13 Concepts around Visibility

14. 2005 Adobe Systems Incorporated. All Rights Reserved. 14 Interaction with Service

15. 2005 Adobe Systems Incorporated. All Rights Reserved. 15 Real World Effect – shared state

16. 2005 Adobe Systems Incorporated. All Rights Reserved. 16 Service Description

17. 2005 Adobe Systems Incorporated. All Rights Reserved. 17 Recurring Q&A…  Why are concrete things not in the reference model (security, messaging protocols etc…)?  Why don’t I see two entities in the RM (service consumer and service provider)?  How does “infrastructure” fit into the reference model?  Does the SOA reference model require definition of core infrastructure?  Why is BP* not part of SOA? (next slide)

18. 2005 Adobe Systems Incorporated. All Rights Reserved. 18 Service Capabilities Service Consumers Where do things live? Core SOA Business Process, State alignment, orchestration, choreography, etc.. Applications, ECM, DB, … In a layer diagram, layer “n” is only visible to layers (n +1) and (n – 1) VisibleVisible Not visible What services are used for Sources, functionality for capabilities

19. 2005 Adobe Systems Incorporated. All Rights Reserved. 19 BPM is a layer over SOA. Data Server Service Server Courtesy Booz Allen Hamilton – http://www.bah.comhttp://www.bah.com Business & Application Tier Service Oriented Tier Business Process Acquisition Business Process Human Resources Business Process Grants Management Business Process Customer Service Business Process Budgeting and Forecasting Process & Orchestration Tier Service

20. 2005 Adobe Systems Incorporated. All Rights Reserved. 20 Processes can be in front of OR behind services  Processes aggregate multiple services and can themselves be exposed as services.  Since services hide the resources behind them, not all details of the process may be available.

21. 2005 Adobe Systems Incorporated. All Rights Reserved. 21 About Reference Models

22. 2005 Adobe Systems Incorporated. All Rights Reserved. 22 Reference Model  A reference model is an abstract framework for understanding significant relationships among the entities of some environment, and for the development of consistent standards or specifications supporting that environment.  A reference model is based on a small number of unifying concepts and may be used as a basis for education and explaining standards to a non-specialist.  A reference model is not directly tied to any standards, technologies or other concrete implementation details, but it does seek to provide a common semantics that can be used unambiguously across and between different implementations.

23. 2005 Adobe Systems Incorporated. All Rights Reserved. 23 Where would the housing industry be?  Implied reference model means architects know their blueprints will be understood and that manufacturer’s are ready to supply the parts needed.  “Palette” of items to work from in model:  Doors, Windows, frames, Gyproc, Flooring, Plumbing etc.  Vendors are aligned with architects views. Entire industry wins!

24. 2005 Adobe Systems Incorporated. All Rights Reserved. 24 Reference Models are Abstract  The RM for “house” is not specific enough for a contractor to build a house.  The RM aides the architect to make a specialized architecture for a specific set of requirements, using elements of the RM.  Most industries have an implied or explicit reference model:  Automobile, Aerospace, Logistics, Bicycle, Skis, etc.

25. 2005 Adobe Systems Incorporated. All Rights Reserved. 25 OASIS SOA RM TC (optional slides)

26. 2005 Adobe Systems Incorporated. All Rights Reserved. 26 OASIS SOA Reference Model TC  Chartered February 2005  Problem to be solved:  "Service Oriented Architecture" (SOA) as a term is being used in an increasing number of contexts and specific technology implementations, sometimes with differing or conflicting understandings of implicit terminology and components.  The proposal to establish a Reference Model is intended to encourage the continued growth of specific and different SOA implementations whilst preserving a common layer that can be shared and understood between those or future implementations.

27. 2005 Adobe Systems Incorporated. All Rights Reserved. 27 OASIS SOA Reference Model TC  Purpose:  The SOA-RM TC will deliver a Service Oriented Architecture Reference Model (SOA-RM).  The TC may also create sub-committees, promotional material, liaisons or other promulgation of the TC's work, in order to promote the use of the SOA Reference Model.  May help vertical industries develop SOA for their requirements.

28. 2005 Adobe Systems Incorporated. All Rights Reserved. 28 To develop a Reference Model for SOA  The TC is asking itself these questions:  What elements are common in all implementations of SOA? ( be careful – think about this) (Paraphrased) What are the core things that make SOA service oriented?  How do we describe those as abstract concepts?  What relationships exist amongst those concepts?  How do we represent those concepts without referencing concrete implementations.

29. 2005 Adobe Systems Incorporated. All Rights Reserved. 29 Existing situation in Web Services WSDL XML & Schema SOAP Base Standards WS-RM WS Addressing Reg/Rep UDDI WS-Security WS-Trust WS-* Requirements Question: How do I account for my requirements and organize components when building a concrete architecture?

30. 2005 Adobe Systems Incorporated. All Rights Reserved. 30 Thoughts on developing specific SOA’s  Probably not logical to try and develop a “one size, fits all” architecture for SOA or WS.  Not rational to develop multiple architectures in standards bodies for every set of requirements.  Best solution: develop an SOA reference Model.  Used by architects to guide development of specific service oriented architectures.  Model for a “way of thinking” when architecting.  Re-useable by multiple architects writing SOA for multiple domains.  Helps architects slot existing standards into their architectures.

31. 2005 Adobe Systems Incorporated. All Rights Reserved. 31 SOA RM used for range of service oriented architectures WSDL XML & Schema SOAP Base Standards WS-RM WS Addressing Foo UDDI WS-Security WS-Trust WS-* Requirements Guides developments of SOA-RM Specific Architectures Uses Input for

32. 2005 Adobe Systems Incorporated. All Rights Reserved. 32 References  OASIS SOA RM TC - 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  Thank you – Duane Nickull, dnickull@adobe.comdnickull@adobe.com

33. 2005 Adobe Systems Incorporated. All Rights Reserved. 33