An Introduction to the OASIS Reference Model for

Скачать презентацию An Introduction to the OASIS Reference Model for

843cc49eac9e647e159656ba33d5b593.ppt

Количество слайдов: 33

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

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. 2005 Adobe Systems Incorporated. All Rights Reserved. 2

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). 2005 Adobe Systems Incorporated. All Rights Reserved. 3

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. 2005 Adobe Systems Incorporated. All Rights Reserved. 4

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. 2005 Adobe Systems Incorporated. All Rights Reserved. 6

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. 2005 Adobe Systems Incorporated. All Rights Reserved. 7

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. 2005 Adobe Systems Incorporated. All Rights Reserved. 10

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. 2005 Adobe Systems Incorporated. All Rights Reserved. 11

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” 2005 Adobe Systems Incorporated. All Rights Reserved. 12

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) 2005 Adobe Systems Incorporated. All Rights Reserved. 17

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

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

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. 2005 Adobe Systems Incorporated. All Rights Reserved. 20

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. 2005 Adobe Systems Incorporated. All Rights Reserved. 22

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! 2005 Adobe Systems Incorporated. All Rights Reserved. 23

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. 2005 Adobe Systems Incorporated. All Rights Reserved. 24

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. 2005 Adobe Systems Incorporated. All Rights Reserved. 26

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. 2005 Adobe Systems Incorporated. All Rights Reserved. 27

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. 2005 Adobe Systems Incorporated. All Rights Reserved. 28

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

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. 2005 Adobe Systems Incorporated. All Rights Reserved. 30

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

References § OASIS SOA RM TC - http: //www. oasisopen. org/committees/tc_home. php? wg_abbrev=soa-rm § Thank you – Duane Nickull, dnickull@adobe. com 2005 Adobe Systems Incorporated. All Rights Reserved. 32