服务科学概论 第4章 面向服务的建模与架构（SOMA） 本讲义部分内容参考自IBM、哈工大徐晓飞教授、北航张莉教授、及众多网络资料，谨表感谢！

面向服务的分析与设计

以业务目标和需求为导向，推动设计、开发和测试，将业务流程转换为对业务进行了自动化和整合的复合应用程序； 面向服务的分析与设计——SOAD 以业务目标和需求为导向，推动设计、开发和测试，将业务流程转换为对业务进行了自动化和整合的复合应用程序； 跟踪整个生命周期中的需求，从业务目标到软件设计与编码资产，再到复合应用程序； 设计整合的解决方案，确保高灵活性，能够随着企业需求变更而适应； 最大限度的提高资产冲用、减少冗余； 最终，从头开始高质量的进行构建。 山东大学软件学院 SSME V4.0

BPM, EA, and OOAD positioning                                                                    流程建模(BPM)用于业务领域的分析和设计，如业务流程的定义、业务数据的定义等;企业架构(EA)和方案架构(SA)侧重在架构领域的分析和设计，如根据业务需求确定目前目标业务系统和IT系统，根据目标系统需求设计主要架构元素和它们之间的关系;面向对象的分析和设计(OOAD)则贯穿分析、设计和开发三个阶段，它主要分析细粒度的业务需求，如用例，分析和设计实现这些需求的类和对象，以及它们之间的关系。 面向服务的分析和设计贯穿项目周期的三个阶段和IT系统的三个域。这暗示着，在操作层面上，面向服务的分析和设计会和其他方法学紧密相联。 山东大学软件学院 SSME V4.0

SOAD and its ingredients: OOAD, BPM, and EA                                                                    1.BPM和SOA 业务流程建模是一个相当零散的领域，存在各种各样的方法和技术，有效的方法可以帮助企业对业务进行合理的划分，从而求得业务层面的灵活性。有些方法则侧重于流程建模本身，例如如何确定和定义业务流程中的业务活动、业务数据、业务规则、业务指标和业务事件等，但是BPM并不会帮助我们去发现和定义服务。从SOA的方法学来看，各种BPM的结果是面向服务的分析和设计的重要输入，如业务组件、业务流程和业务目标是服务发现的重要依据，而业务指标、业务数据、业务规则等是服务暴露的分析的重要依据。 2.EA和SOA 尽管和BPM一样，EA是一个零散的领域，但是当前的EA主要侧重于定义跨越业务单元边界的系统框架，企业范围内系统的主要构成元素，这些元素间的关系，以及将这些元素有机组合在一起的参考架构。但是，各种EA技术都缺乏业务领域的蓝图指导企业架构的设计。从SOA方法学来看，一方面，面向服务的分析和设计通过和BPM结合将业务分解为各种类型的服务，可以作为企业业务的蓝图指导企业架构的设计;另一方面，企业架构设计的结果，如参考架构，又是服务实现的重要依据。 3.OOAD和SOA 面向对象的分析和设计告诉我们使用Use Case捕获需求，并设计类、对象及对象间交互来满足Use Case定义的需求。但是面向对象的分析和设计往往只是局限在单个应用内部，它不会缺乏业务蓝图和企业架构蓝图的指导。从SOA方法学看，在原理层面上，OOAD中的很多设计原则，如抽象、隔离关注等被SOA继承和发扬，并应用于服务的定义和实现中。而在操作层面上，服务模型为OOAD进行类和对象设计提供了业务蓝图和企业架构蓝图，与此同时，Use Case作为对业务流程的补充说明被用于服务的发现和定义中。 山东大学软件学院 SSME V4.0

Main concepts of SOAD Main concepts Relationships between concepts Business goals Business processes Business service IT service Service comonent Component Relationships between concepts B goal – B proc B proc – B service B servise – IT service IT servise – Service component Service component - component 山东大学软件学院 SSME V4.0

Relationships between SOAD concepts - The SOAD service definition hierarchy 山东大学软件学院 SSME V4.0

Relationships between SOAD concepts – SOA layered architecture 山东大学软件学院 SSME V4.0

SOA reference architecture - Services 山东大学软件学院 SSME V4.0

Business service concept Business can understand Common language between business and IT Reusable (in multiple channels, ...) Basis of business driven development Basis of business flexibility Building blocks of business processes Like “elementary business case” see account balance, cash out from ATM, make payment (order) Clear INTERFACE for sending and giving “documents” Call style, event driven interaction point between business process and IT Has lifesycle (who owns, who pays, ...) – SOA governance 山东大学软件学院 SSME V4.0

SOAD – roles and responsibilities 山东大学软件学院 SSME V4.0

Requiremnts management 山东大学软件学院 SSME V4.0

Business proc modelling and analysis 山东大学软件学院 SSME V4.0

Service oriented modelling, analysis, design 山东大学软件学院 SSME V4.0

Business brocess choerography and mediation 山东大学软件学院 SSME V4.0

User interface development 山东大学软件学院 SSME V4.0

Test (early, often) 山东大学软件学院 SSME V4.0

本章内容 1 SOA系统分层结构 2 SOMA方法框架 3 SOMA方法实现 4 案例分析 山东大学软件学院 SSME V4.0

SOA系统分层结构

SOA应用的典型多层架构 山东大学软件学院 SSME V4.0

SOA应用的典型多层架构 山东大学软件学院 SSME V4.0

The SOA Layers Layer 1: 遗留系统 Layer 2: 企业功能构件层 Existing custom built applications, called legacy systems CRM and ERP packaged applications older object-oriented system implementations, business intelligence applications. To leverage existing systems and integrate them using service-oriented integration techniques. Layer 2: 企业功能构件层 Enterprise components that are responsible for realizing functionality and maintaining the QoS of the exposed services. Managed, governed set of enterprise assets that are funded at the enterprise or the business unit level. Typically uses container-based technologies such as application servers to implement the components, workload management, high-availability, and load balancing. 山东大学软件学院 SSME V4.0

The SOA Layers Layer 3: 服务层 Level 4: 业务过程层(服务组合与协同层) The services the business chooses to fund and expose Can be discovered or be statically bound and then invoked, or possibly, choreographed into a composite service. Mechanism to take enterprise scale components, business unit specific components, and in some cases, project-specific components, and externalizes a subset of their interfaces in the form of service descriptions. Provide service realization at runtime using the functionality provided by their interfaces. Exist in isolation or as a composite service. Level 4: 业务过程层(服务组合与协同层) Services are bundled into a flow through orchestration or choreography, and thus act together as a single application. These applications support specific use cases and business processes. 山东大学软件学院 SSME V4.0

The SOA Layers Layer 5: 访问层(表现层) Level 6: 集成 (ESB) Level 7: 服务质量(QoS) SOA decouples the user interface from the components, the layer provides an access channel to a service or composition of services. Level 6: 集成 (ESB) Enables the integration of services through the introduction of a reliable set of capabilities, such as intelligent routing, protocol mediation, and other transformation mechanisms, often described as the ESB. Level 7: 服务质量(QoS) The capabilities required to monitor, manage, and maintain QoS such as security, performance, and availability. A background process through sense-and-respond mechanisms and tools that monitor the health of SOA applications. 山东大学软件学院 SSME V4.0

SOA的分层结构 presentation Now, let's describe each layer in greater detail and discuss the composition of each of these layers. Layer 1: Operational systems layer. This consists of existing custom built applications, otherwise called legacy systems, including existing CRM and ERP packaged applications, and older object-oriented system implementations, as well as business intelligence applications. The composite layered architecture of an SOA can leverage existing systems and integrate them using service-oriented integration techniques. Layer 2: Enterprise components layer. This is the layer of enterprise components that are responsible for realizing functionality and maintaining the QoS of the exposed services. These special components are a managed, governed set of enterprise assets that are funded at the enterprise or the business unit level. As enterprise-scale assets, they are responsible for ensuring conformance to SLAs through the application of architectural best practices. This layer typically uses container-based technologies such as application servers to implement the components, workload management, high-availability, and load balancing. Layer 3: Services layer. The services the business chooses to fund and expose reside in this layer. They can be discovered or be statically bound and then invoked, or possibly, choreographed into a composite service. This service exposure layer also provides for the mechanism to take enterprise scale components, business unit specific components, and in some cases, project-specific components, and externalizes a subset of their interfaces in the form of service descriptions. Thus, the enterprise components provide service realization at runtime using the functionality provided by their interfaces. The interfaces get exported out as service descriptions in this layer, where they are exposed for use. They can exist in isolation or as a composite service. Level 4: Business process composition or choreography layer. Compositions and choreographies of services exposed in Layer 3 are defined in this layer. Services are bundled into a flow through orchestration or choreography, and thus act together as a single application. These applications support specific use cases and business processes. Here, visual flow composition tools, such as IBM® WebSphere® Business Integration Modeler or Websphere Application Developer Integration Edition, can be used for the design of application flow. Layer 5: Access or presentation layer. Although this layer is usually out of scope for discussions around a SOA, it is gradually becoming more relevant. I depict it here because there is an increasing convergence of standards, such as Web Services for Remote Portlets Version 2.0 and other technologies, that seek to leverage Web services at the application interface or presentation level. You can think of it as a future layer that you need to take into account for future solutions. It is also important to note that SOA decouples the user interface from the components, and that you ultimately need to provide an end-to-end solution from an access channel to a service or composition of services. Level 6: Integration (ESB). This layer enables the integration of services through the introduction of a reliable set of capabilities, such as intelligent routing, protocol mediation, and other transformation mechanisms, often described as the ESB Web Services Description Language (WSDL) specifies a binding, which implies a location where the service is provided. On the other hand, an ESB provides a location independent mechanism for integration. Level 7: QoS. This layer provides the capabilities required to monitor, manage, and maintain QoS such as security, performance, and availability. This is a background process through sense-and-respond mechanisms and tools that monitor the health of SOA applications, including the all important standards implementations of WS-Management and other relevant protocols and standards that implement quality of service for a SOA. At the heart of SOA is the Service Model that defines services and components that realize them 山东大学软件学院 SSME V4.0

What is a service model? The service model is a key work product used to document the results of a service modeling exercise Various decisions are made and models created during: Identification of services Specification of services Realization of services The service model documents the decisions made in this process, and captures the design aspects and models that will be used in implementing the creation and assembly of services 山东大学软件学院 SSME V4.0

Components of a service model 山东大学软件学院 SSME V4.0

SOMA方法框架

SOMA is … SOMA refers to the more general domain of service modeling necessary to design and create SOA. SOMA covers a broader scope and implements service-oriented analysis and design (SOAD) through the identification, specification and realization of services, components that realize those services (a.k.a. "service components"), and flows that can be used to compose services 山东大学软件学院 SSME V4.0

On Demand Operating Environment Service Oriented Architecture (SOA) 业务与IT的密切融合：On Demand Flexible Business Transformation Business Process Outsourcing Mergers, Acquisitions & Divestitures Composable Processes (e.g., CBM) Requires Service-Oriented Modeling (SOMA) Flexible IT Cost Containment Greater ROI for IT dollars Better Use if IT Assets Improved Quality of Deployed Systems On Demand Operating Environment Composable Services for SOA Service Oriented Architecture (SOA) Development Infrastructure Management Software Development Integration Infrastructure Management 山东大学软件学院 SSME V4.0

Service-Oriented Modeling & Architecture [SOMA] Method IBM announced Service-Oriented Modeling and Architecture (SOMA) as the first publicly announced SOA-related methodology in 2004 << Output to: SOA Implementation >> Realization Decisions Specification of Services, Components, Flows Identification of candidate Services, Components, Flows << Input from: Business Componentization/Analysis >> Identifies candidate services and enterprise components. Selects and specifies the services that will be exposed and what enterprise components are needed Captures services realization decisions 山东大学软件学院 SSME V4.0

<< 输入自: 业务组件化/分析 >> <<输出至: SOA实施>> SOMA各阶段所覆盖的范围 SOMA的核心是：识别、规定和实现服务(services)、用来支持服务的构件(components)、以及服务之间形成的协同(choreography) << 输入自: 业务组件化/分析 >> 数据架构与业务智能 监控基础设施服务 QoS安全管理与 整合(企业服务总线方法) 定制 应用 成套 应用 消费者 业务流程 流程编排 服务 原子与组分 服务组件 操作系统 服务消费者 服务提供商 1 2 3 4 5 6 7 8 OO 应用 合成 服务 原子 注册 JService Portlet WSRP B2B 其他 识别 备选服务与流程 The main three activities are service identification and specification, component identification and specification of its internal attributes, rules, methods, events, flow, messages and 信息 model. The latter will collectively help realize services. Service realization is the binding of a component and the services it provides to actual instances of implementation: this service will be realized through this newly developed EJB that we will expose as a web service; this other service’s operations will be realized through the wrappering of a set of the following CICS transactions after we have componentized the legacy system to be able to expose these CICS transactions and have separated out the COBOL copybooks. 规定 服务，组件与流程 实现 决策 <<输出至: SOA实施>> 山东大学软件学院 SSME V4.0

SOMA核心思想 Links Business Intent and IT Implementation SOMA << Input from: Business Componentization /Analysis >> <<Output to: SOA Implementation >> SOMA SOMA gets inputs from business componentization and analysis activities, and produces outputs necessary for SOA implementation. The analysis and modeling performed during SOMA is technology and product agnostic, but establishes a context for making technology and product specific decisions in later phases of the lifecycle. SOMA creates continuity between the business intent and IT implementation by extending business characteristics such as goals and key performance indicators (or KPIs) into the IT analysis and architectural decisions. The outputs of business analysis and modeling efforts such as CBM are leveraged by SOMA to deliver an SOA solution. The analysis and modeling performed during SOMA is technology and product agnostic. Yet, it establishes a context for making technology specific decisions in later phases of the life cycle. 山东大学软件学院 SSME V4.0

基于服务的建模和架构过程包含三个主要的步骤：服务，组件和流程的识别，规定和实现 SOMA的三个主要的步骤 基于服务的建模和架构过程包含三个主要的步骤：服务，组件和流程的识别，规定和实现 What we do? How we do it? Realization Decisions Specification of Services, Components, and Flows Identification of Candidate Services and Flows 识别候选服务和流程 设计服务、组件和流程 用编程语言实现服务 山东大学软件学院 SSME V4.0

3个建模对象 <<Object>> 业务流程 (Flows) 服务 Atomic and Composite 服务组件 The Three Fundamental Constructs of the SOA models are services, service components that realize those services as well as the processes (flows) that string the services together. SOMA was created specifically to address modeling of all three constructs. SOMA was created to specifically address modeling (analysis, identification, and specification) of all three constructs. 山东大学软件学院 SSME V4.0

SOMA方法实现 How to combine a top-down, business-driven approach with a bottom-up approach, leveraging legacy investments

SOMA方法实现途径 SOMA：通过面向服务的建模、分析和设计技术与活动，构造SOA应用。 SOMA的途径：混合式 在每一层次作出关键的体系结构设计决策； SOMA的途径：混合式 自顶向下 从业务需求出发，通过模型驱动，构造SOA蓝图； 自底向上 充分利用遗留系统的投资，封装可被服务使用的功能； 山东大学软件学院 SSME V4.0

Activities of service-oriented modeling 山东大学软件学院 SSME V4.0

Realization Decisions SOMA里面的活动 Domain Decomposition Subsystem Analysis Service Specification message & event specification component flow service flow Realization Decisions Goal-Service Modeling Existing Asset Component information service allocation to components component layering technical feasibility exploration Identification Specification Service 鉴别 这个过程由域分解、现有资产分析和目标服务建模的自顶向下、自底向上、中间向外技术的联合组成。在 自顶向下视图中，业务用例的蓝图提供了业务服务的规范。这个自顶向下的过程作为 域分解来被引用，域分解由业务领域到它的功能区域和子系统的分解组成，包含它的流程或过程分解成过程、自过程和高级别业务用例。很多情况下，这些用例是公开在企业边缘的业务服务，或者在贯穿业务线企业边界内所用的非常好的候选。 在过程的 从下到上的部分或者 现有系统分析中，现有的系统被分析和选择作为可行的候选，来为支持业务过程的底层服务功能性实现提供低消耗的解决方案。在这个过程中，你分析和利用了来自遗留和打包应用程序的 API、事务和模块。在有些情况下，为了支持服务的功能重新模块化现有的资产需要遗留系统的组件化。 中间向外视图由 目标服务建模组成，来验证和发现自顶向下或自底向上的服务鉴别手段中没有捕捉到的其他服务。它将服务连结到目标和子目标、关键性能指示和尺度。 服务分级和分类 这个活动在服务被指定时开始。将服务分级为服务层次是非常重要的，反映了服务的复合或者不规则的本性：服务可以也应该由良好粒度的组建和服务组成，分级帮助决定合成和分层，以及基于层次的相互依赖服务的协同构建。同样，它帮助减轻服务增值综合症，这种症状中，越来越多的小粒度的服务被定义、设计和部署，却缺乏控制，导致了主要的性能、可伸缩性和管理问题。更加重要的是，服务增值未能提供服务，这些服务对业务是非常有用的。 子系统分析 这个活动获取上面域分解过程中发现的子系统，并且指定子系统之间的相互依赖和流程。它同样将域分解过程中鉴别的用例作为子系统接口上公开的服务。子系统的分析包含创建对象模型来表现内部工作方式，以及所包含的公开服务并且实现它们的子系统设计。这时，“子系统”的设计结构将实现为大粒度组件实现构造，在下面的活动中实现服务。 组件指定 在下面的主要活动中，实现服务的组件的细节将指定： 数据 规则 服务 可配置概要 变更 消息和时间指定以及管理定义出现在这一步骤中。 服务分配 服务分配包括分派服务到目前鉴别的子系统。这些子系统具有实现了他们所公布的功能的企业组件。你经常会简单化假定，子系统同企业组件有一对一的联系。 结构化组件在你使用模式来构造企业组件时会通过以下几点的联合的形式出现： 中介体 Facade 规则对象 工厂 服务分配同样由服务的指派和在 SOA 层中实现他们的组件组成。组件和服务向 SOA 层中的分配是一个关键的任务，需要关键架构决策的文件和决议，这些决策不仅仅同应用程序架构有关系，也同在运行时设计和用来支持 SOA 实现的技术操作架构有关的。 服务实现 这个步骤指出实现给定服务的软件必须被选择或者自定义构建。其他可用的选项包括使用 Web 服务来集成、转化、订阅和外购不同功能。在这个步骤中，你决定哪个遗留系统模块用来实现给定的服务，以及哪个服务将从基础来构建。服务的其他实现决策不同于业务功能包括：服务的安全、管理和监视。 事实上，项目趋向于利用任意数量的相应的努力来满足关闭的机会窗口。因此，我推荐并行的管理三个流。 自顶向下的域分解（过程建模和分解，基于变更的分析，方针和业务规则分析，领域特定行为建模（使用语法和图表））是同供组件化（模块化）和服务公开候选的现有遗留资产的分析并行控制。为了获得项目背后的业务意图和使服务同业务意图密切合作，目标服务建模可以来控制。 Realization 山东大学软件学院 SSME V4.0

开始：Business Componentization Provides Essential SOMA Inputs << Output to: SOA Implementation >> Investment Architecture Vision /Planning Insight Interpret Business Strategy Business Strategy Summary Define Business Component Model Component Business Model with Components and Services Description “Heat” Map STEP 1 IT Infrastructure Assessment Application Systems Analysis Business Process Analysis Level 1 As-Is Process State Assessment Process Gap Analysis Level 1 to-be Business Process Leading Business Practices (Core) System to Business Component Overlay Elements of Current IT Environment Systems and Information Shortfall Assessment Roadmap Opportunities Definition List of Opportunities and Recommendations [Rationalization] Project Prioritization Criteria Multi- Generational Investment Plan STEP 2 STEP 3 STEP 4 STEP 5 STEP 6 Hygiene Factors [NFR] Business Component Collaborations As-Is Level 1 Model (within BC) Process Goals, [ KPI’s Metrics] ARC 101 Architecture Overview Diagram ApplicationServer <<component>> RelationalDBMS SecurityMgr SecurityProcessing AccountProcessing AccountMgr DialogueControl Service Component Model ARC119 Non-Functional Requirements << Input from: Business Componentization / Analysis >> SOMA Service Exposure Service Composition Service NFRs Service Messages Realization Decisions Service Model Service Portfolio Service Hierarchy Service Dependencies State Management Decisions SOMA gets essential inputs from business componentization and analysis. These inputs are transformation focus areas, business process models, and business goals and corresponding metrics. Inputs depicted here are from CBM. We do not expect you to read the details on this chart, they’re only depictions. SOMA produces outputs that are required by SOA implementation activities. The key SOMA work product is the Service Model. Note: Although CBM inputs are depicted, SOMA can be used with other business analysis techniques. 山东大学软件学院 SSME V4.0

服务识别 SOMA identifies services, component boundaries, flows, compositions, and information through complementary techniques which include domain decomposition, goal-service modeling and existing asset analysis. In the top-down view, a blueprint of business use cases provides the specification for business services. -> domain decomposition In the bottom-up portion of the process or existing system analysis, existing systems are analyzed and selected as viable candidates to the implementation of underlying service functionality that supports the business process. The middle-out view consists of goal-service modeling to validate and unearth other services not captured by either top-down or bottom-up service identification approaches. In the top-down view, a blueprint of business use cases provides the specification for business services. This top-down process is often referred to as domain decomposition, which consists of the decomposition of the business domain into its functional areas and subsystems, including its flow or process decomposition into processes, sub-processes, and high-level business use cases. These use cases often are very good candidates for business services exposed at the edge of the enterprise, or for those used within the boundaries of the enterprise across lines of business. In the bottom-up portion of the process or existing system analysis, existing systems are analyzed and selected as viable candidates for providing lower cost solutions to the implementation of underlying service functionality that supports the business process. In this process, you analyze and leverage APIs, transactions, and modules from legacy and packaged applications. In some cases, componentization of the legacy systems is needed to re-modularize the existing assets for supporting service functionality. The middle-out view consists of goal-service modeling to validate and unearth other services not captured by either top-down or bottom-up service identification approaches. It ties services to goals and sub-goals, key performance indicators, and metrics. 山东大学软件学院 SSME V4.0

怎样从商业动机和战略、业务功能性区域及已存在的资源来识别需要的功能，IBM SOMA 描述了三种技术： 服务识别 怎样从商业动机和战略、业务功能性区域及已存在的资源来识别需要的功能，IBM SOMA 描述了三种技术： Goal-service modeling, which identifies capabilities needed to realize business requirements such as strategies and goals Domain decomposition, which uses activities in business processes and other descriptions of business functions to identify needed capabilities Existing asset analysis, which mines capabilities from existing applications 通过使用目标服务建模与域分解技术，我们就可以识别需要的功能，来处理购买订单 山东大学软件学院 SSME V4.0

Service Litmus Tests (石蕊试验 SLTs) Service Litmus Tests (SLTs) Are Gating Criteria Used to Determine If a Candidate Service Should Be Exposed Service Service Litmus Tests Universal (out-of-the-box) Business Alignment Composability Externalized Service Description Redundancy Elimination/Reusability Feasibility of Implementation Business Entity based Services (for Information Services only) Custom Client/Project Defined SLTs Apply SLTs (Standard and Custom) Apply Priority, Weight & Calculate Service Rating for each litmus test Make exposure decisions Candidate Services Determine Exposure Scope Assess whether services are business aligned   Give a weight to the degree to which a given service and its operations are business aligned or in general complaint with a given litmus test Assess whether services are composable   Assess whether services are reusable   Assess whether services have externalized service description   Apply other customized service litmus tests   Create weight and ranking for each litmus test   To measure its importance of the current project/client Make exposure decisions   Apply the weight and ranking of the litmus tests to each of the services in the service portfolio. Document the exposure decisions based on results of service litmus test. In some cases, there could be a business justification to expose a service which has failed one or more service litmus tests. Document the reasons to expose a service even though it has failed one or more service litmus tests. Exposed Services Exposure Scope Department/Division Line-of- Business Enterprise Eco-system 山东大学软件学院 SSME V4.0

服务实现 The software that realizes a given service must be selected or custom built. Other options that are available include integration, transformation, subscription and outsourcing of parts of the functionality using Web services. Top-down domain decomposition is conducted in parallel with a bottom-up analysis of existing legacy assets that are candidates for componentization (modularization) and service exposure. To catch the business intent behind the project and to align services with this business intent, goal-service modeling is conducted. 山东大学软件学院 SSME V4.0

在 SOMA 中，服务实现处理的是架构性决策问题，它关注的是方案的模板与模式、SOA 引用架构的具体内容、技术上的可实现性以及原型问题 A service defines a set of capabilities (provided by service providers) that meet the needs of service consumers, or users. The first step in service implementation design is to provision the services. That is, we must figure out which service providers will be providing which service capabilities. 在 SOMA 中，服务实现处理的是架构性决策问题，它关注的是方案的模板与模式、SOA 引用架构的具体内容、技术上的可实现性以及原型问题 山东大学软件学院 SSME V4.0

SOA model example: Analyze existing functions 山东大学软件学院 SSME V4.0

SOA model example: Initial service specification The activity Service Identification introduces a number of techniques for identifying the services and operations on services which are required to support a solution This example is a form of legacy renewal, the transformation of existing functionality to a services model The first aspect is to develop the set of Service Specifications that will provide the contracts for the services implementing the required functions 山东大学软件学院 SSME V4.0

SOA model example: Service design In this step, you make the transition from the set of candidate services that were identified earlier into the detailed design of the services you intend to build 山东大学软件学院 SSME V4.0

SOA model example: Message design Captures the actual messages exchanged between the operations described on the service specifications 山东大学软件学院 SSME V4.0

SOA model example: Service realization From the Service design model you can use tools to transform the model into code. The code being generated can be an EJB implementation for deployment in a J2EE environment 山东大学软件学院 SSME V4.0

SOA model example: EJB implementation 山东大学软件学院 SSME V4.0

SOMA: 方法与过程overview 山东大学软件学院 SSME V4.0

SOMA Steps Overview Steps Work Detail Domain Decomposition Decompose Business eco-system or value chain into Functional areas of the business; Decompose enterprise business process areas into sub-processes and use-cases, consider cross enterprise and similar Value-Net activities (VOA). Also, identify and validate high value reusable Enterprise Process Modules Process Definition Identify the process and decompose its data processing inputs and outputs, business rules, and business metrics against any existing process roles. Subsystem Analysis Analyze subsystems into functional & technical components and services Goal Service Models Identify business goals, sub-goals and Services required to fulfill objectives. KPI’s and their associated metrics. Service Allocation Assign services to components and recalibrate components as needed; Extricate logic and rules; Partition Components Specification Specify details of components and services Structuring Enterprise Component Use design and architectural patterns and Best-practices to design internals of service components Technology Mapping Build vs. Buy vs. Subscribe vs. Transform vs. Wrap; 如何实现构件的功能？ 山东大学软件学院 SSME V4.0

The Service Model Captures Information about Services Service Hierarchy Service Exposure Service Dependencies Service Composition Service NFRs Service Messages State Management Service Model Service Portfolio Realization Decisions Identification Specification Realization SOMA Step Description Service and Component Realization Decisions Architectural decisions about service realization, such as buy, build, and subscribe Service Specification:: State Management Decisions State management architectural decisions Service Specification:: Service Message Specification Messages that are exchanged between service consumer and service provider Service Specification:: Service Non-Functional Requirements Non-functional requirements of the service Service Specification:: Service Composition Service Specification:: Flow Choreography of services to form a composite service Service Specification:: Service Dependencies Dependencies between services in the model Service Specification:: Service Litmus Test Service Specification:: Exposure Decisions Decisions of why a given candidate service or group of services was exposed Domain Decomposition Goal-Service Modeling Existing Asset Analysis Candidate services organized using a business significant categorization scheme to make evaluation more manageable Candidate services discovered during SOMA service identification activities The Service Model captures the initial list and categorizations of candidate services, as well as the specification realization decisions for services that will be exposed. Note that realization decisions are actually documented in the Architectural Decisions work product that you should be familiar with. The service model is built incrementally as SOMA activities are iteratively carried out. It is composed of a number of elements summarized in the table. Take time to review the detailed description of each. 山东大学软件学院 SSME V4.0

Monitoring & Management SOMA 3.1 Domain Decomposition Subsystem Analysis Service Specification Message & Event Component Flow Service Flow Realization Decisions Goal-Service Modeling Existing Asset Component Information Solution Template & Pattern Selection and Instantiation Detail SOA Solution Reference Architecture Technical Feasibility Exploration Identification Realization Implementation Deployment (Packaging/Provisioning) Construction Generation User Acceptance Testing Unit Testing Integration Testing Assembly Integration Build/Assembly Governance Startup Selection of Solution Templates, Method Adoption Monitoring & Management Deployment Close Identification of candidate services and flows, existing assets Specification of services to be exposed, flows, and components (for realization of services) Arrows signify incremental iteration Realization Capture realization decisions (concurrently with first two phases), explore feasibility of realization scenarios, instantiate SOA Reference Architecture This picture illustrates the end-to-end SOMA method. They key point to note is that the method now covers the full delivery life cycle from start up to operational deployment. There are various policy and logistical reasons why this decision has been taken, but you don't need to worry that this looks like a huge new method to learn. The goal of the method is to cover all scenarios where SOA analysis and design may be required, whether this involves legacy adaptation, new build, package or process integration, or whatever. But where a task or task group directly reflects a task you will already be familiar with from the conventional lifecycle, you'll find the task name and definition also directly reflect the material you'll find in the existing methods. So in reality all you need to understand are the key new analysis design and delivery tasks, and associated techniques; plus how and where these new tasks and task groups interconnect with the wider set of conventional delivery work - in SOMA these have been tagged "Business As Usual" tasks. You'll see that the phases are named in a new way, and this reflects the underlying service oriented analysis and design process. And you will also notice the arrows. These signify that in general you should expect to be using SOMA in an iterative or incremental style, as we've previously discussed. Implementation Implement service components and services Deployment Package and provision 山东大学软件学院 SSME V4.0

SOMA 3.1 山东大学软件学院 SSME V4.0

案例1 车辆保养服务

阶段1：业务建模 当顾客打电话预约时创建工作订单。 为每个计划的维修活动或操作创建一个独立的工作订单项，其中包括需要使用的零件、备件和劳务的详细情况。 在安排预约之前确保所有必需的零件都有库存。 需要为每个工作订单项安排具有适当的装备的维修间以及具备适当的条件的机器。 计算估计的总成本，接着顾客认可该预约；或者方案终止，随即取消工作订单。 在预约之前，立即在选定的维修间装配必需的零件、备件、工具和设备。 当顾客到达时，进行计划的活动以及在检查交通工具时显得有必要的任何其他活动。 记录所用的零件和备件的实际价值以及劳务。 在完成所有的维修时计算总费用。 创建发票并且将其交给顾客。 山东大学软件学院 SSME V4.0

阶段1：业务建模 山东大学软件学院 SSME V4.0

阶段2：OO设计 采用面向对象的系统分析与设计方法 山东大学软件学院 SSME V4.0

阶段3：服务识别与实现 将多个Object聚集在一起，形成一个个独立的服务； 确定每个服务的外部接口、内部实现； 采用特定的技术标准来开发每一个服务； 书写每一个服务的WSDL。 山东大学软件学院 SSME V4.0

阶段3：服务识别与实现 山东大学软件学院 SSME V4.0

阶段4：服务编排 按照业务流程， 将多个服务 编排在一起。 山东大学软件学院 SSME V4.0

基于SOA的服务系统构建过程 山东大学软件学院 SSME V4.0

案例2 帐户开立项目

Sandy Osbourne-Archer，首席技术架构师 Edmund Smythe-Barrett，企业架构师 人员和角色 一个虚拟的公司（JKHL） Sandy Osbourne-Archer，首席技术架构师 Edmund Smythe-Barrett，企业架构师 Ursula DeBarry，软件架构师兼服务设计团队主管 Henry Lee，业务分析人员 Jason Smith，集成开发人员 Willy Li，应用程序开发人员 山东大学软件学院 SSME V4.0

SOA 设计场景 软件架构师兼服务设计团队主管 Ursula DeBarry 从业之初担任的是 J2EE™ 开发人员，后来成为了软件架构师。她拥有娴熟的设计技能，对专门从事 SOA 设计方面的工作特别感兴趣 Ursula从应用程序开发人员 Willy Li——那里了解到，JKHL Enterprises 正在寻找有经验的软件架构师和服务设计师来实施 SOA 计划。Ursula 前去 JKHL Enterprises 应聘。 首席技术架构师 Sandy Osbourne-Archer 对 Ursula 进行了面试，由于她本身具有丰富的经验、娴熟的技能，并且有 Willy Li 推荐，因此当场就被录用了。Ursula 非常高兴能担任软件架构师兼服务设计团队主管。 在与 Sandy 的首次会面中，Ursula 了解了帐户开立项目的目标和挑战。Sandy 表示，自己对业务和 IT 之间存在的语义差异和细节差异不甚满意，因为这些差异容易出现不同步或不完全一致的现象 Sandy 强调了保持业务设计和 IT 解决方案一致的需求，以便保持企业对新业务机会的敏捷性和响应能力 山东大学软件学院 SSME V4.0

SOA 设计场景 当前业务和 IT 不同步（不一致）                                                                       山东大学软件学院 SSME V4.0

Sandy 列出了帐户开立项目的高级业务目标 目标 1：降低成本： 1.1: 降低创建和管理帐户的成本 1.1.1: 降低帐户激活的成本 1.2: 减少纸质文档的数量 1.2.1: 增加电子应用程序的数量 目标 2：提高每个客户拥有的产品数量 目标 3：提高可用性 目标 4：减少不遵从法律法规的风险 目标 5：增加客户自助服务 目标 6：加快上市时间 山东大学软件学院 SSME V4.0

Sandy 总结了高级设计目标和挑战 业务设计： IT 解决方案设计： 清楚地定义业务战略和目标 以业务驱动的方式对服务需求、设计和实现进行优先排序 提高服务重用，以加速上市时间并降低成本 IT 解决方案设计： 为关键业务活动的服务提供显式的可跟踪性 可重复且可扩展的设计方法 能实现更好重用的服务组合 用于多通道访问的服务绑定策略 方便组装、部署和管理的解决方案 山东大学软件学院 SSME V4.0

Ursula 和企业架构师 Edmund Smythe-Barrett 共同制定了 SOA 设计场景的帐户开立计划。 他们与业务分析人员 Henry Lee 进行了讨论，对为帐户开立项目定义的关键业务需求有了更好的理解 山东大学软件学院 SSME V4.0

Ursula 希望能够利用经过验证的 SOMA 方法进行帐户开立服务设计 SOA 设计场景模型的基本构造包括流、服务和组件 流或流程表示完成某个业务流程所需要的活动流。流是旨在实现业务目标的相关和集成服务的组合 服务是代表性的可重复业务任务。通过提供定义良好并且与实现无关的接口，从而将服务用于封装应用程序的功能单元。服务可由其他服务或客户端应用程序调用（使用） 组件表示服务向服务使用者公开的功能，以及由实现服务的服务提供者提供的服务质量 (QoS) 山东大学软件学院 SSME V4.0

SOA 设计场景的关键元素是服务设计 服务设计以及最终的服务通过在业务流和目标与 IT 组件之间提供桥梁，从而提供一致性能力 用于服务设计的 SOMA 实现特别利用了 SOMA 标识、规范和实现阶段来交付所需的 SOA 设计成果 SOMA 通过服务、组件和流的标识、规范和实现来完成此任务。SOMA v3.1 扩展了 SOMA，以提供同时还包括实现、测试、部署、监视和管理活动的端到端方法 山东大学软件学院 SSME V4.0

SOMA 方法 山东大学软件学院 SSME V4.0

SOMA 是 SOA 解决方案设计模式的基础 山东大学软件学院 SSME V4.0

服务标识 服务标识的目标是创建候选服务及其对业务有意义的关联操作的初始集合。服务标识主要由软件架构师来完成，并且通常包括业务分析人员以支持角色形式的参与。 在服务标识期间，将创建服务模型工作产品，并移交给负责服务规范的软件架构师。服务标识与产生服务模型的分析级别同义，而服务规范则是设计级别。 服务标识的关键输入包括： 业务分析和建模 用于定义业务体系结构。CRM 通常用于业务分析，以帮助客户了解其业务和能力，并确定能力差距。也可以使用其他方法来进行业务分析。 服务注册中心和存储库 现有的服务和有关它们的信息通常存储在服务注册中心和存储库中。该帐户开立项目是第一次采用 SOA；因此不存在现有的服务。 让我们进一步了解三种用于确定候选服务的补充技术： 目标-服务建模 领域分解 现有资产分析 山东大学软件学院 SSME V4.0

目标-服务建模 目标-服务建模的关键目标是证明服务的可跟踪性和与业务目标的一致性。目标-服务模型是一种由内向外 (middle-out) 的方法，在相应输出可用时迭代地用于验证通过领域分解和现有资产分析技术确定的候选服务列表的完整性。 在开发目标-服务模型时，您通常与业务主管、业务分析人员和主题专家紧密合作，以确定范围内的业务目标和项目的阶段。对于每个目标和子目标，您将确定可用于评估业务性能的关键性能指标 (KPI) 和度量。 JKHLE 销售管理业务组件中的服务标识重点目标是确定支持该业务组件的服务。 山东大学软件学院 SSME V4.0

领域分解 对于领域分解，我们采用自顶向下的方式工作，将业务领域分解为主要的功能区域和子系统。在下一个级别，我们进一步将功能区域分解为流程、子流程和高级业务用例。 领域分解使用并增强领域分析和领域工程方法的子集，包括： 功能区域分析 将领域分解为功能区域可以为 IT 子系统及其实现服务的对应服务组件的设计提供业务边界。如果没有提供 CBM，则为 SOMA 合作项目执行领域分析。 流程分解 执行业务流程建模以将流程分解为子流程和任务。对于初始的候选服务列表，三个级别的分解通常就足够了。 面向变化的分析 全面观察流程、规则、策略和结构（数据），以确定候选共性。下一步，分离出流程、规则和结构的变化 山东大学软件学院 SSME V4.0

流程分解 山东大学软件学院 SSME V4.0

分解集中于“帐户开立”流程以及“帐户激活”和“验证”功能区域 帐户开立流程和功能区域的领域分解输出 分解集中于“帐户开立”流程以及“帐户激活”和“验证”功能区域 山东大学软件学院 SSME V4.0

现有资产分析 现有资产分析的主要目标是最大限度地重用现有的应用程序事务、现有系统中的模块和打包的应用程序。在执行现有资产分析时，我们采用自底向上的方法以确定候选服务。可能会确定一些新服务，并且在其他情况下，该技术将确认前一项技术的标识结果。 Ursula 与 Edmund 使用自底向上的方法，共同确定 JKHLE 环境中的现有应用程序和事务，以最大限度地实现重用。许多现有的中间件和后端应用程序，例如 CICS、IMS、SAP 和 Siebel。 Ursula 评估每个现有的应用程序，以确定应该将哪些应用程序作为帐户开立流程应用程序的服务公开，其目的是促进和了解哪些资产可以成为可重用组件并作为服务公开。 现有资产分析并不只是将现有的应用程序接口作为 Web 服务公开。需要周密考虑以确定现有应用程序的接口是否允许良好的服务设计 山东大学软件学院 SSME V4.0

将现有应用程序作为服务公开的选项 将现有应用程序包装为服务 将现有功能包装并替换为服务 使用更适合于服务调用的适配器 将功能集成到服务中 将功能保留原样，但是使用工具或中间件将现有功能作为服务公开。例如，将 CICS 应用程序作为 SOAP Web 服务公开（也称为直接公开）。 将现有功能包装并替换为服务 按上述方式包装功能，但是在以后使用最终的服务规范来重新开发服务。然后，替换原始服务，并将客户端重定向到新的实现。 使用更适合于服务调用的适配器 在某些情况下，无法包装某个功能并将其作为服务公开。但是，能够以更容易集成的形式包装该功能，例如消息队列接口或 （Java Connector Architecture，JCA），允许新服务就地访问该功能（也称为间接公开）。 将功能集成到服务中 在某些情况下，只需将现有的功能用作服务实现中的一个逻辑组件，即可让新服务就地访问该功能。 山东大学软件学院 SSME V4.0

服务规范定义依赖关系、组合、公开决策、消息、服务质量约束以及与服务状态管理相关的决策。服务规范任务的目标是详细描述服务模型。 服务规范包括以下子任务： 应用 Service Litmus Test 以做出公开决策 确定服务依赖关系 确定服务组合和流 确定非功能性需求 指定服务消息 编写状态管理决策文档 山东大学软件学院 SSME V4.0

应用 Service Litmus Test 以做出公开决策 要公开的服务 山东大学软件学院 SSME V4.0

详细的服务检查可以揭示对用于实现服务功能的其他服务或应用程序的服务依赖关系。 存在两种需要考虑的依赖关系类型： 确定服务依赖关系 详细的服务检查可以揭示对用于实现服务功能的其他服务或应用程序的服务依赖关系。 存在两种需要考虑的依赖关系类型： 功能依赖关系是这样的服务之间的依赖关系，即这些服务彼此依赖以交付所需交付的服务。例如，AccountActivation 组合服务具有对 ARSetup、AccountSetup 和 CreateAccount 服务的依赖关系。 流程依赖关系是这样的服务之间的依赖关系，即这些服务编排在一起以构成业务流程。例如，帐户开立流程依赖“确定资格”前提条件和“创建帐户”流程依赖关系。 山东大学软件学院 SSME V4.0

确定服务组合和流 检查功能区域和业务流程可以帮助详细描述服务及其流的组合。服务流规范描述服务之间的编排。例如，帐户激活组合服务是一个长时间运行的可中断流程宏流。“帐户查询”是一个短时间运行的不可中断流程（微流）。 山东大学软件学院 SSME V4.0

确定非功能性需求 服务模型必须考虑用于指定服务质量 (QoS) 的非功能性需求。例如，“帐户查询”服务可用性需求为 99.999%，帐户激活服务的帐户激活性能需求为在四天内激活。 山东大学软件学院 SSME V4.0

指定服务消息 服务模型中的数据流通常以在服务之间流动的消息的形式表示。在确定服务规范的过程中，存在数据模型未完成的情况。要考虑有关将实现的服务的详细信息在此时间点不足够的情况。虽然如此，仍然需要考虑用于服务输入和输出的数据和消息。下表指定了 AccountInquiry 服务的服务消息。 山东大学软件学院 SSME V4.0

在某些情况下，服务组合需要编写状态管理文档，例如有状态、无状态、带有缓存状态的状态等等。 编写状态管理决策文档 在某些情况下，服务组合需要编写状态管理文档，例如有状态、无状态、带有缓存状态的状态等等。 例如，存在流程的某些部分的状态管理可能由组合服务或其他元素控制的情况。 山东大学软件学院 SSME V4.0

服务规范任务的最后一部分是组件规范。孤立地执行此任务通常是非常困难的，因此实现任务通常并行地执行并且是迭代的。服务组件规范包括以下子任务： 确定组件属性 确定事件和消息 确定组件内部流 创建组件类关系图 面向变化的设计 山东大学软件学院 SSME V4.0

在确定并指定服务以后，需要做出有关每个组件如何实现功能的关键体系结构决策。 服务实现 在确定并指定服务以后，需要做出有关每个组件如何实现功能的关键体系结构决策。 山东大学软件学院 SSME V4.0

服务分配 在整个生命周期中以迭代的方式将服务分配到组件，以执行用于将服务分配到企业组件的服务分配。例如，帐户查询服务被分配到客户 CICS 后端系统 技术可行性探索 需要确定并评估技术约束，以确保公开候选服务在技术上是可行的，对于在现有系统分析期间确定的服务尤其是如此。通常使用技术原型来探索技术可行性。 将组件分配到各层 将组件分配到应用程序体系结构中的各个 SOA 参考体系结构层是在指定组件并编写实现决策文档之后执行的 山东大学软件学院 SSME V4.0

注意：用于流程组合的业务服务设计实现演示了使关键业务度量与业务目标保持一致的流程建模和模拟。 Ursula 从业务分析人员那里了解到需要对帐户验证流程进行流程改进。Ursula 使用 流程建模器 来模拟现有的流程，然后在通过关键度量模拟来实现的流程优化基础上创建了建议的流程。 山东大学软件学院 SSME V4.0

当前帐户验证流程 当前帐户验证流程 当前流程中存在多处流程改进余地。 帐户协调人员检查客户申请，并研究有关多个不同系统的信息，以确定是否需要信用报告。 如果不需要信用报告，则客户申请将跳过该流程的大部分内容。如果需要信用报告，则帐户协调人员将向信用调查机构打电话或发送传真，以请求信用报告。由于通信方法（传真或电话）问题，信用调查机构没有为 JKHLE 提供针对其服务的优惠定价。获得多个信用报告非常昂贵并且耗时。 JKHLE 无法区分高风险和中等风险的客户，从而导致远高于行业平均水平的大量拒绝受理请求。最后，帐户协调人员发出了批准。批准的定价是通过参考一组复杂的纸质手册来确定的。 当前流程中存在多处流程改进余地。 缺乏单一客户视图和信用流程业务规则导致我们定购了超过需要的信用报告。 手动的信用报告检索流程高度不一致、代价昂贵并且非常耗时。 太多的客户请求被拒绝，导致潜在客户不愉快并导致销售代表不满。 虽然定价和帐户规则相当简单，但是其值更改得非常频繁。由于该过程是手动的，很难实现快速更改 山东大学软件学院 SSME V4.0

帐户验证（现有） 山东大学软件学院 SSME V4.0

预期的帐户验证流程 Ursula 在流程建模器中修改了模拟的帐户验证流程来处理上述流程改进，并通过更改流程中的关键度量或值，从而试着优化该业务流程。这称为流程优化 优化后的流程具有以下改进： 自动化的完整客户视图减少了需要信用报告的客户数量。 自动化的信用报告显著降低了成本并更加快速。 批准更大比例的客户请求。 基于规则的动态定价，可在业务需求的基础上根据需要进行更改。 平均持续时间变化百分比：加速 97.6% 加权平均利润：增加 84.7% 山东大学软件学院 SSME V4.0

帐户验证（预期） 山东大学软件学院 SSME V4.0

帐户验证——用于优化的流程模拟 最后，集成开发人员 Jason Smith 根据前面的实现中描述的方法，使用指定的服务和实现的组件组装并组合了该业务流程 山东大学软件学院 SSME V4.0

本章描述了SOMA的基本思想，方法基本内容，最后通过一些案例，讨论了其主要特点 本章小结 本章描述了SOMA的基本思想，方法基本内容，最后通过一些案例，讨论了其主要特点 山东大学软件学院 SSME V4.0