Transcript 服务科学与工程

服务科学概论
第4章 面向服务的建模与架构
（SOMA）
本讲义部分内容参考自IBM、哈工大徐晓飞教授、北航张莉教授、及众多网络
资料，谨表感谢！
面向服务的分析与设计
面向服务的分析与设计——SOAD
• 以业务目标和需求为导向，推动设计、开发和测
试，将业务流程转换为对业务进行了自动化和整
合的复合应用程序；
• 跟踪整个生命周期中的需求，从业务目标到软件
设计与编码资产，再到复合应用程序；
• 设计整合的解决方案，确保高灵活性，能够随着
企业需求变更而适应；
• 最大限度的提高资产冲用、减少冗余；
• 最终，从头开始高质量的进行构建。
山东大学软件学院
SSME V4.0
3
BPM, EA, and OOAD positioning
山东大学软件学院
SSME V4.0
4
SOAD and its ingredients:
OOAD, BPM, and EA
山东大学软件学院
SSME V4.0
5
Main concepts of SOAD
• Main concepts
•
•
•
•
•
•
Business goals
Business processes
Business service
IT service
Service comonent
Component
•
•
•
•
•
B goal – B proc
B proc – B service
B servise – IT service
IT servise – Service component
Service component - component
• Relationships between concepts
山东大学软件学院
SSME V4.0
6
Relationships between SOAD concepts The SOAD service definition hierarchy
山东大学软件学院
SSME V4.0
7
Relationships between SOAD concepts –
SOA layered architecture
山东大学软件学院
SSME V4.0
8
SOA reference architecture - Services
山东大学软件学院
SSME V4.0
9
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
10
SOAD – roles and responsibilities
山东大学软件学院
SSME V4.0
11
Requiremnts management
山东大学软件学院
SSME V4.0
12
Business proc modelling and analysis
山东大学软件学院
SSME V4.0
13
Service oriented modelling, analysis, design
山东大学软件学院
SSME V4.0
14
Business brocess choerography and mediati
on
山东大学软件学院
SSME V4.0
15
User interface development
山东大学软件学院
SSME V4.0
16
Test (early, often)
山东大学软件学院
SSME V4.0
17
本章内容
1
SOA系统分层结构
2
SOMA方法框架
3
SOMA方法实现
4
案例分析
山东大学软件学院
SSME V4.0
18
SOA系统分层结构
SOA应用的典型多层架构
Application 1
Application 2
Business
Process
Auto-searchable
Found
Service broker
Services
Registration
Registration
Registration
Component
Library
Organization X
Organization Y
山东大学软件学院
SSME V4.0
Organization Z
20
SOA应用的典型多层架构
山东大学软件学院
SSME V4.0
21
The SOA Layers
• Layer 1: 遗留系统
• 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
22
The SOA Layers
• Layer 3: 服务层
• 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, projectspecific 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
23
The SOA Layers
• Layer 5: 访问层(表现层)
• 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
24
SOA的分层结构
presentation
At the heart of SOA is the Service Model that defines servi
ces and components that realize them
山东大学软件学院
SSME V4.0
25
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
26
Components of a service model
山东大学软件学院
SSME V4.0
27
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
29
业务与IT的密切融合：On Demand
Flexible Business
Composable
Processes
(e.g., CBM)
Transformation
Business Process Outsourcing
Mergers, Acquisitions & Divestitures
Requires
Service-Oriented
Modeling (SOMA)
Flexible IT
On Demand Operating Environment
Cost Containment
Greater
ROIArchitecture
for IT dollars (SOA)
Service
Oriented
Better Use if IT Assets
Development
Infrastructure
Management
Improved Quality
of Deployed Systems
Software
Development
Integration
Composable
Services for
SOA
Infrastructure
Management
山东大学软件学院
SSME V4.0
30
Service-Oriented Modeling & Architecture [S
OMA] Method
<< Input from: Business
Componentization/Analysis >>
Identification
of candidate Services, Components, Flows
Specification
of Services, Components, Flows
Realization
Decisions
IBM announced
Service-Oriented
Modeling and
Architecture (SOMA) as
the first publicly
announced SOA-related
methodology in 2004
<< Output to: SOA Implementation >>
1. Identifies candidate services and enterprise
components.
2. Selects and specifies the services that will
be exposed and what enterprise components
are needed
3. Captures services realization decisions
山东大学软件学院
SSME V4.0
31
SOMA各阶段所覆盖的范围
• SOMA的核心是：识别、规定和实现服务
(services)、用来支持服务的构件
(components)、以及服务之间形成的协同
(choreography)
B2B
其他
5
服务，组件与流程
业务流程
3
原子与组分
实现
2
服
务
提
供
商
服务组件
操作系统
决策
<<输出至: SOA实施>>
8
4
服务
规定
7
消费者
流程编排
备选服务与流程
6
数据架构与业务智能
服
务
消
费
者
WSRP
QoS安全管理与
监控基础设施服务
识别
JService Portlet
整合(企业服务总线方法)
<< 输入自: 业务组件化/分析 >>
成套
成套应用
应用
定制
定制应用
应用
OO
应用
1
合成
服务
原子
注册
山东大学软件学院
SSME V4.0
32
SOMA核心思想
Links Business Intent and IT Implementation
<< Input from: Business
Componentization /Analysis >>
SOMA
<<Output to: SOA Implementation >>
• 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.
山东大学软件学院
SSME V4.0
33
SOMA的三个主要的步骤
• 基于服务的建模和架构过程包含三个主要的步
骤：服务，组件和流程的识别，规定和实现
Identification
of Candidate Services and Flows
Specification
of Services, Components, and Flows
Realization
Decisions
What we do?
•识别候选服务和流程
How we do it?
•设计服务、组件和流程
•用编程语言实现服务
山东大学软件学院
SSME V4.0
34
3个建模对象
业务流程
(Flows)
服务
Atomic and Composite
服务组件
<<Object>>
<<Object>>
<<Object>>
SOMA was created to specifically address modeling (analysis,
identification, and specification) of all three constructs.
山东大学软件学院
SSME V4.0
35
SOMA方法实现
How to combine a top-down, business-driven
approach with a bottom-up approach,
leveraging legacy investments
SOMA方法实现途径
• SOMA：通过面向服务的建模、分析和设计技术
与活动，构造SOA应用。
• 定义SOA各层次中包含的元素；
• 在每一层次作出关键的体系结构设计决策；
• SOMA的途径：混合式
自顶向下
从业务需求出发，通过模型驱动，构造SOA蓝图；
自底向上
充分利用遗留系统的投资，封装可被服务使用的功能；
山东大学软件学院
SSME V4.0
37
Activities of service-oriented modeling
山东大学软件学院
SSME V4.0
38
SOMA里面的活动
Identification
Domain
Decomposition
component flow
specification
Specification
information
specification
Goal-Service
Modeling
Subsystem
Analysis
Component
Specification
Existing Asset
Analysis
service flow
specification
Service
Specification
message
& event
specification
Realization Decisions
Realization
service
allocation
to components
technical
feasibility
exploration
山东大学软件学院
SSME V4.0
component
layering
39
开始：Business Componentization Provides
Essential SOMA Inputs
<< Input from: Business Componentization /
Analysis >>
STEP 1 STEP 2
STEP 3
STEP 4
Architecture Vision
/Planning
IT
Insight
STEP 5
STEP 6
Investment
SOMA
Infrastructure
Assessment
Interpret
Business
Strategy
Goals,
[ KPI’s
Metrics]
Component
Business Model
with Components
and Services
Description
Business
Component
Collaborations
Business
Process
Analysis
Application
Systems
Analysis
Opportunities
Definition
Leading
Business
Practices
(Core)
System to
Business
Component
Overlay
List of
Opportunities and
Recommendations
[Rationalization]
As-Is Level 1
Process
Model (within
BC)
Level 1 As-Is
Process State
Assessment
Investment
Roadmap
Project
Prioritization
Criteria
Users
Level 1 to-be
Business
Process
e-business
Services
Registration Function
Authentication and
Authorization Function
Systems and
Information
Shortfall
Assessment
Database(s)
Enterprise Update
Function
Service
Representative
System
Monitoring
Enterprise Reporting
Function
Intranet Browser
Messaging & Collaboration
Function
Internal User
Enterprise Administration
Function
Business Partner
Elements of
Current IT
Environment
<<component> >
<<component>>
SecurityProcessing
Hygiene
Factors
[NFR]
Directory
Systems
Legacy
Applications
Enterprise Inquiry
Function
Internet
Browser
MultiGenerational
Investment
Plan
Customer
Relationshup
management
External
Enterprise
System
Internet or
Extranet Browser
ARC 101 Architecture
Overview
Diagram
<<component>>
AccountProcessing
Process
Gap
Analysis
<<component>>
ApplicationServer
Service
Component
Model
Note: Although CBM inputs are depicted,
SOMA can be used with other business
analysis techniques.
山东大学软件学院
Service Exposure
Service Dependencies
Service Composition
Service NFRs
Service Messages
<<component>>
AccountMgr
<<component>>
RelationalDBMS
Service Portfolio
Service Hierarchy
Resources
Pervasive/
Wireless Devices
Customer
DialogueControl
“Heat”
Map
Delivery
Channels
Service Model
Business
Strategy
Summary
Define
Business
Component
Model
Realization Decisions
<<component>>
SecurityMgr
ARC119 NonFunctional
Requirements
State Management
Decisions
<< Output to: SOA Implementation >>
SSME V4.0
40
服务识别
• 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.
山东大学软件学院
SSME V4.0
41
服务识别
• 怎样从商业动机和战略、业务功能性区域及已存
在的资源来识别需要的功能，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
42
Service Litmus Tests (石蕊试验 SLTs)
Service Litmus Tests (SLTs) Are Gating Criteria Used to Determine
If a Candidate Service Should Be Exposed
Service
Apply SLTs
(Standard and Custom)
Service
Service
Candidate Services
Apply Priority, Weight &
Calculate Service Rating
for each litmus test
Make exposure
decisions
Determine Exposure
Scope
Service
Service
Service
Service Litmus Tests
Universal (out-of-the-box)
1.
Business Alignment
2.
Composability
3.
Externalized Service
Description
4.
Redundancy
Elimination/Reusability
5.
Feasibility of
Implementation
6.
Business Entity based
Services (for Information
Services only)
Exposed Services
Exposure Scope
1.
Department/Division
2.
Line-of- Business
3.
Enterprise
4.
Eco-system
Custom
7.
山东大学软件学院
SSME V4.0
Client/Project Defined
SLTs
43
服务实现
• 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
44
服务实现
• 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
45
SOA model example: Analyze existing functions
山东大学软件学院
SSME V4.0
46
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
47
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
48
SOA model example: Message design
• Captures the actual messages exchanged
between the operations described on the
service specifications
山东大学软件学院
SSME V4.0
49
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
50
SOA model example: EJB implementation
山东大学软件学院
SSME V4.0
51
SOMA: 方法与过程overview
Current Business and Technical Architecture
Decompose Business Domain
1a
Create Business Goal/
Service Model
3
Identify Subsystems, 2
Components, use cases
Top-down
Specify Enterprise Components
Structure Enterprise Components using Patterns
Allocate Services to Coarse-grained Components
1b
Analyze Existing Assets
Componentize Legacy Systems
Bottom-up
4
5
Leverage Component
Service repository
6
Technology Realization Mapping:
Map Components, Services to Implementation
7
Service
Repository
Future Enterprise and Application Architecture
山东大学软件学院
SSME V4.0
52
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 subprocesses and use-cases, consider cross enterprise and similar ValueNet 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
53
The Service Model Captures Information abo
ut Services
Service Model
Service Portfolio
•Description
SOMA Step
•Candidate services discovered during SOMA
service identification activities
 Domain Decomposition
 Goal-Service Modeling
 Existing Asset Analysis
•Candidate services organized using a business
significant categorization scheme to make
evaluation more manageable
 Domain Decomposition
 Goal-Service Modeling
 Existing Asset Analysis
•Decisions of why a given candidate service or
group of services was exposed
 Service Specification::
Service Litmus Test
 Service Specification::
Exposure Decisions
•Dependencies between services in the
model
 Service Specification::
Service Dependencies
•Choreography of services to form a
composite service
 Service Specification:: Service
Composition
 Service Specification:: Flow
•Non-functional requirements of the service
 Service Specification::
Service Non-Functional
Requirements
•Messages that are exchanged between
service consumer and service provider
 Service Specification::
Service Message
Specification
•State management architectural decisions
 Service Specification:: State
Management Decisions
•Architectural decisions about service realization,
such as buy, build, and subscribe
 Service and Component
Realization Decisions
Identification
Service Hierarchy
Service Exposure
Service Dependencies
Specification
Service Composition
Service NFRs
Service Messages
State Management
Realization
Realization Decisions
山东大学软件学院
SSME V4.0
54
SOMA 3.1
Governance
Startup
Selection of Solution Templates, Method Adoption
Identification
of candidate services and
flows, existing assets
Identification
Specification
of services to be exposed,
flows, and components (for
realization of services)
Specification
Domain
Decomposition
Component Flow
Subsystem
Specification
Analysis
Information
Specification
Existing Asset
Analysis
Goal-Service
Modeling
Component
Specification
Service
Specification
Service Flow
Specification
Message & Event
Specification
Realization
Capture realization decisions
(concurrently with first two
phases), explore feasibility of
realization scenarios,
instantiate SOA Reference
Architecture
Realization Decisions
Realization
Implementation
Solution Template
& Pattern
Selection and
Instantiation
Technical Feasibility
Exploration
Detail SOA Solution
Reference
Architecture
Construction
Generation
Assembly
Integration
Build/Assembly
Unit Testing
Integration Testing
User Acceptance
Testing
Testing
Implementation
Implement service
components and services
Deployment
Deployment
Package and provision
Arrows
signify
incremental
iteration
Deployment (Packaging/Provisioning)
Close
Monitoring & Management
Governance
山东大学软件学院
SSME V4.0
55
SOMA 3.1
Solution Startup
1
Identification
8
4
Initiate
Project
Management
Activities
Conduct
Goal-Service
Modeling
Select
Solution
Templates and
Patterns
9
13





Construct,
Generate &
Assemble
Services
17
Establish
Realization
Decisions
Analyze
Sub-systems
19
Deploy
Services
20
Execute
Unit Test
Execute
User Acceptance
Test
Analyze
Existing
Assets
10
Conduct
Method
Adoption
Workshop
16
Refine &
Detail
Components
Deployment
6
Decompose
Domains
3
12
Implementation
 Composition  Messages
 Flows
 NFRs
 Operations
Service Model
5
Realization
Specify
Services
Business Domains & Processes In Scope
2
Specification
Functional Area
Process
Information
Rules
Variations
14
Specify
Components
Service Model
Perform
Technical
Feasibility
Exploration
18
Execute
Integration
& System Test
 Customize Delivery
Method
7
11
Re-factor
& Rationalize
Services
 Service Litmus Test
15
Re-factor
& Rationalize
Services
Detail SOA
Solution
Stack Layers
 Service Litmus Test
山东大学软件学院
SSME V4.0
56
案例1
车辆保养服务
阶段1：业务建模
• 当顾客打电话预约时创建工作订单。
• 为每个计划的维修活动或操作创建一个独立的工作订单
项，其中包括需要使用的零件、备件和劳务的详细情况。
• 在安排预约之前确保所有必需的零件都有库存。
• 需要为每个工作订单项安排具有适当的装备的维修间以及
具备适当的条件的机器。
• 计算估计的总成本，接着顾客认可该预约；或者方案终
止，随即取消工作订单。
• 在预约之前，立即在选定的维修间装配必需的零件、备
件、工具和设备。
• 当顾客到达时，进行计划的活动以及在检查交通工具时显
得有必要的任何其他活动。
• 记录所用的零件和备件的实际价值以及劳务。
• 在完成所有的维修时计算总费用。
• 创建发票并且将其交给顾客。
山东大学软件学院
SSME V4.0
58
阶段1：业务建模
山东大学软件学院
SSME V4.0
59
阶段2：OO设计
采用面向对象的系统分析与设计方法
山东大学软件学院
SSME V4.0
60
阶段3：服务识别与实现
1.
2.
3.
4.
将多个Object聚集在一起，形成一个个独立的服务；
确定每个服务的外部接口、内部实现；
采用特定的技术标准来开发每一个服务；
书写每一个服务的WSDL。
山东大学软件学院
SSME V4.0
61
阶段3：服务识别与实现
山东大学软件学院
SSME V4.0
62
阶段4：服务编排
按照业务流程，
将多个服务
编排在一起。
山东大学软件学院
SSME V4.0
63
基于SOA的服务系统构建过程
服务需求模型
服务行为与
能力模型
服务构件识别
多层次业务服务模型
(模型环境)
服务执行模型
服务协同模型
服务系统
Choreography
服务
目录
服务构件规范
Orchestration
(复合构件)
复合构件)
服务构件
动态查询
Site 1
多层次IT服务模型与系统
(e-ESB环境)
服务构件集合
Site n
山东大学软件学院
分布式服务构件
(Internet环境)
SSME V4.0
64
案例2
帐户开立项目
人员和角色
•
•
•
•
一个虚拟的公司（JKHL）
Sandy Osbourne-Archer，首席技术架构师
Edmund Smythe-Barrett，企业架构师
Ursula DeBarry，软件架构师兼服务设计团队主
管
• Henry Lee，业务分析人员
• Jason Smith，集成开发人员
• Willy Li，应用程序开发人员
山东大学软件学院
SSME V4.0
66
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
67
SOA 设计场景
• 当前业务和 IT 不同步（不一致）
山东大学软件学院
SSME V4.0
68
Sandy 列出了帐户开立项目的高级业务目标
• 目标 1：降低成本：
• 1.1: 降低创建和管理帐户的成本
• 1.1.1: 降低帐户激活的成本
• 1.2: 减少纸质文档的数量
• 1.2.1: 增加电子应用程序的数量
•
•
•
•
•
目标 2：提高每个客户拥有的产品数量
目标 3：提高可用性
目标 4：减少不遵从法律法规的风险
目标 5：增加客户自助服务
目标 6：加快上市时间
山东大学软件学院
SSME V4.0
69
Sandy 总结了高级设计目标和挑战
• 业务设计：
• 清楚地定义业务战略和目标
• 以业务驱动的方式对服务需求、设计和实现进行优先排
序
• 提高服务重用，以加速上市时间并降低成本
• IT 解决方案设计：
•
•
•
•
•
为关键业务活动的服务提供显式的可跟踪性
可重复且可扩展的设计方法
能实现更好重用的服务组合
用于多通道访问的服务绑定策略
方便组装、部署和管理的解决方案
山东大学软件学院
SSME V4.0
70
SOA 设计场景的帐户开立计划
• Ursula 和企业架构师 Edmund Smythe-Barrett
共同制定了 SOA 设计场景的帐户开立计划。
• 他们与业务分析人员 Henry Lee 进行了讨论，对
为帐户开立项目定义的关键业务需求有了更好的
理解
山东大学软件学院
SSME V4.0
71
应用 SOMA 进行服务设计
• Ursula 希望能够利用经过验证的 SOMA 方法进
行帐户开立服务设计
• SOA 设计场景模型的基本构造包括流、服务和组
件
流或流程表示完成某个业务流程所需要的
活动流。流是旨在实现业务目标的相关和
集成服务的组合
服务是代表性的可重复业务任务。通过提
供定义良好并且与实现无关的接口，从而
将服务用于封装应用程序的功能单元。服
务可由其他服务或客户端应用程序调用
（使用）
组件表示服务向服务使用者公开的功能，
以及由实现服务的服务提供者提供的服务
质量 (QoS)
山东大学软件学院
SSME V4.0
72
SOA 设计场景的关键元素是服务设计
• 服务设计以及最终的服务通过在业务流和目标与 IT 组件
之间提供桥梁，从而提供一致性能力
• 用于服务设计的 SOMA 实现特别利用了 SOMA 标识、规
范和实现阶段来交付所需的 SOA 设计成果
• SOMA 通过服务、组件和流的标识、规范和实现来完成此
任务。SOMA v3.1 扩展了 SOMA，以提供同时还包括实
现、测试、部署、监视和管理活动的端到端方法
山东大学软件学院
SSME V4.0
73
SOMA 方法
山东大学软件学院
SSME V4.0
74
SOMA 是 SOA 解决方案设计模式的基础
山东大学软件学院
SSME V4.0
75
服务标识
• 服务标识的目标是创建候选服务及其对业务有意义的关联操作的初始
集合。服务标识主要由软件架构师来完成，并且通常包括业务分析人
员以支持角色形式的参与。
• 在服务标识期间，将创建服务模型工作产品，并移交给负责服务规范
的软件架构师。服务标识与产生服务模型的分析级别同义，而服务规
范则是设计级别。
• 服务标识的关键输入包括：
• 业务分析和建模
• 用于定义业务体系结构。CRM 通常用于业务分析，以帮助客户了解其业务和
能力，并确定能力差距。也可以使用其他方法来进行业务分析。
• 服务注册中心和存储库
• 现有的服务和有关它们的信息通常存储在服务注册中心和存储库中。该帐户开
立项目是第一次采用 SOA；因此不存在现有的服务。
• 让我们进一步了解三种用于确定候选服务的补充技术：
• 目标-服务建模
• 领域分解
• 现有资产分析
山东大学软件学院
SSME V4.0
76
目标-服务建模
• 目标-服务建模的关键目标是证明服务的可跟踪性和与业务
目标的一致性。目标-服务模型是一种由内向外 (middleout) 的方法，在相应输出可用时迭代地用于验证通过领域
分解和现有资产分析技术确定的候选服务列表的完整性。
• 在开发目标-服务模型时，您通常与业务主管、业务分析人
员和主题专家紧密合作，以确定范围内的业务目标和项目
的阶段。对于每个目标和子目标，您将确定可用于评估业
务性能的关键性能指标 (KPI) 和度量。
• JKHLE 销售管理业务组件中的服务标识重点目标是确定支
持该业务组件的服务。
山东大学软件学院
SSME V4.0
77
领域分解
• 对于领域分解，我们采用自顶向下的方式工作，将业务领
域分解为主要的功能区域和子系统。在下一个级别，我们
进一步将功能区域分解为流程、子流程和高级业务用例。
• 领域分解使用并增强领域分析和领域工程方法的子集，包
括：
• 功能区域分析
• 将领域分解为功能区域可以为 IT 子系统及其实现服务的对应服务组
件的设计提供业务边界。如果没有提供 CBM，则为 SOMA 合作项目
执行领域分析。
• 流程分解
• 执行业务流程建模以将流程分解为子流程和任务。对于初始的候选服
务列表，三个级别的分解通常就足够了。
• 面向变化的分析
• 全面观察流程、规则、策略和结构（数据），以确定候选共性。下一
步，分离出流程、规则和结构的变化
山东大学软件学院
SSME V4.0
78
流程分解
山东大学软件学院
SSME V4.0
79
帐户开立流程和功能区域的领域分解输出
• 分解集中于“帐户开立”流程以及“帐户激活”
和“验证”功能区域
山东大学软件学院
SSME V4.0
80
现有资产分析
• 现有资产分析的主要目标是最大限度地重用现有的应用程
序事务、现有系统中的模块和打包的应用程序。在执行现
有资产分析时，我们采用自底向上的方法以确定候选服务。
可能会确定一些新服务，并且在其他情况下，该技术将确
认前一项技术的标识结果。
• Ursula 与 Edmund 使用自底向上的方法，共同确定
JKHLE 环境中的现有应用程序和事务，以最大限度地实现
重用。许多现有的中间件和后端应用程序，例如 CICS、
IMS、SAP 和 Siebel。
• Ursula 评估每个现有的应用程序，以确定应该将哪些应用
程序作为帐户开立流程应用程序的服务公开，其目的是促
进和了解哪些资产可以成为可重用组件并作为服务公开。
• 现有资产分析并不只是将现有的应用程序接口作为 Web
服务公开。需要周密考虑以确定现有应用程序的接口是否
允许良好的服务设计
山东大学软件学院
SSME V4.0
81
将现有应用程序作为服务公开的选项
• 将现有应用程序包装为服务
• 将功能保留原样，但是使用工具或中间件将现有功能作为服务公开。例
如，将 CICS 应用程序作为 SOAP Web 服务公开（也称为直接公开）。
• 将现有功能包装并替换为服务
• 按上述方式包装功能，但是在以后使用最终的服务规范来重新开发服务。
然后，替换原始服务，并将客户端重定向到新的实现。
• 使用更适合于服务调用的适配器
• 在某些情况下，无法包装某个功能并将其作为服务公开。但是，能够以更
容易集成的形式包装该功能，例如消息队列接口或 （Java Connector
Architecture，JCA），允许新服务就地访问该功能（也称为间接公
开）。
• 将功能集成到服务中
• 在某些情况下，只需将现有的功能用作服务实现中的一个逻辑组件，即可
让新服务就地访问该功能。
山东大学软件学院
SSME V4.0
82
服务规范
• 服务规范定义依赖关系、组合、公开决策、消息、
服务质量约束以及与服务状态管理相关的决策。
服务规范任务的目标是详细描述服务模型。
• 服务规范包括以下子任务：
•
•
•
•
•
•
应用 Service Litmus Test 以做出公开决策
确定服务依赖关系
确定服务组合和流
确定非功能性需求
指定服务消息
编写状态管理决策文档
山东大学软件学院
SSME V4.0
83
应用 Service Litmus Test 以做出公开决策
• 要公开的服务
山东大学软件学院
SSME V4.0
84
确定服务依赖关系
• 详细的服务检查可以揭示对用于实现服务功能的
其他服务或应用程序的服务依赖关系。
• 存在两种需要考虑的依赖关系类型：
• 功能依赖关系是这样的服务之间的依赖关系，即
这些服务彼此依赖以交付所需交付的服务。例如，
AccountActivation 组合服务具有对 ARSetup、
AccountSetup 和 CreateAccount 服务的依赖关
系。
• 流程依赖关系是这样的服务之间的依赖关系，即
这些服务编排在一起以构成业务流程。例如，帐
户开立流程依赖“确定资格”前提条件和“创建
帐户”流程依赖关系。
山东大学软件学院
SSME V4.0
85
确定服务组合和流
• 检查功能区域和业务流程可以帮助详细描述服务
及其流的组合。服务流规范描述服务之间的编
排。例如，帐户激活组合服务是一个长时间运行
的可中断流程宏流。“帐户查询”是一个短时间
运行的不可中断流程（微流）。
山东大学软件学院
SSME V4.0
86
确定非功能性需求
• 服务模型必须考虑用于指定服务质量 (QoS) 的非
功能性需求。例如，“帐户查询”服务可用性需
求为 99.999%，帐户激活服务的帐户激活性能需
求为在四天内激活。
山东大学软件学院
SSME V4.0
87
指定服务消息
• 服务模型中的数据流通常以在服务之间流动的消
息的形式表示。在确定服务规范的过程中，存在
数据模型未完成的情况。要考虑有关将实现的服
务的详细信息在此时间点不足够的情况。虽然如
此，仍然需要考虑用于服务输入和输出的数据和
消息。下表指定了 AccountInquiry 服务的服务
消息。
山东大学软件学院
SSME V4.0
88
编写状态管理决策文档
• 在某些情况下，服务组合需要编写状态管理文档，
例如有状态、无状态、带有缓存状态的状态等等。
• 例如，存在流程的某些部分的状态管理可能由组
合服务或其他元素控制的情况。
山东大学软件学院
SSME V4.0
89
服务组件规范
• 服务规范任务的最后一部分是组件规范。孤立地
执行此任务通常是非常困难的，因此实现任务通
常并行地执行并且是迭代的。服务组件规范包括
以下子任务：
•
•
•
•
•
确定组件属性
确定事件和消息
确定组件内部流
创建组件类关系图
面向变化的设计
山东大学软件学院
SSME V4.0
90
服务实现
• 在确定并指定服务以后，需要做出有关每个组件
如何实现功能的关键体系结构决策。
山东大学软件学院
SSME V4.0
91
• 服务分配
• 在整个生命周期中以迭代的方式将服务分配到组件，以
执行用于将服务分配到企业组件的服务分配。例如，帐
户查询服务被分配到客户 CICS 后端系统
• 技术可行性探索
• 需要确定并评估技术约束，以确保公开候选服务在技术
上是可行的，对于在现有系统分析期间确定的服务尤其
是如此。通常使用技术原型来探索技术可行性。
• 将组件分配到各层
• 将组件分配到应用程序体系结构中的各个 SOA 参考体
系结构层是在指定组件并编写实现决策文档之后执行的
山东大学软件学院
SSME V4.0
92
用于流程组合的业务服务设计
• 注意：用于流程组合的业务服务设计实现演示了
使关键业务度量与业务目标保持一致的流程建模
和模拟。
• Ursula 从业务分析人员那里了解到需要对帐户验
证流程进行流程改进。Ursula 使用 流程建模器
来模拟现有的流程，然后在通过关键度量模拟来
实现的流程优化基础上创建了建议的流程。
山东大学软件学院
SSME V4.0
93
当前帐户验证流程
• 当前帐户验证流程
• 帐户协调人员检查客户申请，并研究有关多个不同系统的信息，以确定是
否需要信用报告。
• 如果不需要信用报告，则客户申请将跳过该流程的大部分内容。如果需要
信用报告，则帐户协调人员将向信用调查机构打电话或发送传真，以请求
信用报告。由于通信方法（传真或电话）问题，信用调查机构没有为
JKHLE 提供针对其服务的优惠定价。获得多个信用报告非常昂贵并且耗
时。
• JKHLE 无法区分高风险和中等风险的客户，从而导致远高于行业平均水平
的大量拒绝受理请求。最后，帐户协调人员发出了批准。批准的定价是通
过参考一组复杂的纸质手册来确定的。
• 当前流程中存在多处流程改进余地。
• 缺乏单一客户视图和信用流程业务规则导致我们定购了超过需要的信用报
告。
• 手动的信用报告检索流程高度不一致、代价昂贵并且非常耗时。
• 太多的客户请求被拒绝，导致潜在客户不愉快并导致销售代表不满。
• 虽然定价和帐户规则相当简单，但是其值更改得非常频繁。由于该过程是
手动的，很难实现快速更改
山东大学软件学院
SSME V4.0
94
帐户验证（现有）
山东大学软件学院
SSME V4.0
95
预期的帐户验证流程
• Ursula 在流程建模器中修改了模拟的帐户验证流
程来处理上述流程改进，并通过更改流程中的关
键度量或值，从而试着优化该业务流程。这称为
流程优化
• 优化后的流程具有以下改进：
• 自动化的完整客户视图减少了需要信用报告的客户数
量。
• 自动化的信用报告显著降低了成本并更加快速。
• 批准更大比例的客户请求。
• 基于规则的动态定价，可在业务需求的基础上根据需要
进行更改。
• 平均持续时间变化百分比：加速 97.6%
• 加权平均利润：增加 84.7%
山东大学软件学院
SSME V4.0
96
帐户验证（预期）
山东大学软件学院
SSME V4.0
97
帐户验证——用于优化的流程模拟
最后，集成开发人员 Jason Smith 根据前面的实现中描
述的方法，使用指定的服务和实现的组件组装并组合了
该业务流程
山东大学软件学院
SSME V4.0
98
本章小结
• 本章描述了SOMA的基本思想，方法基本内容，
最后通过一些案例，讨论了其主要特点
山东大学软件学院
SSME V4.0
99