服务需求的主要工作是基于SOA的需求分析方法论，以流程和业务驱动IT的指导思想，对业务系统进行业务建模，用例建模和业务实体建模，形成企业级需求和业务功能清单，作为后续服务识别的输入。

对于服务需求，以流程分析为基础，通过流程的逐层分解，细化出关键的业务活动，将流程活动识别为业务用例，并对业务用例进行建模。用例建模本身可以作为业务系统功能开发的需求规格说明书，同时对用例分析和功能操作的识别形成业务域-》流程分解-》用例-》业务操作的分解过程，用于后续服务的识别。

在整个分析过程中，流程的关键活动或业务用例的操作都会涉及到业务实体对象，因此需要对业务实体对象进行单独建模，分析实体对象的关键属性和对象间关系，同时分析实体对象和业务操作间的U/C矩阵，作为后续公用服务提取的基础。

服务识别开始于需求分析，终止于识别出的候选服务列表。为了有效的实施SOA工程，应用不能孤立于其他应用而独立开发。SOA的应用应该可以共享服务，这些服务不单单属于某个独立的应用，并且有自己的生命周期，能够被独立的管理。在SOA工程中，为了有效的管理需求，各个项目必须知道其他已经存在的项目、正在开发的项目以及未来将要开发的项目需求。所以，与SOA服务相关的需求应该在企业级层面管理。

候选服务是被识别出用于系统重用的业务功能。一个候选服务不一定一对一的对应到实际交付的服务，比如，在分析阶段，一个粗粒度的服务可能对应到需求中两个或两个以上的初始候选服务。另一方面，服务识别并不是简单的识别出候选服务，也包括了一系列的校验和评估。

1.数据服务识别

数据服务为以实现业务系统底层数据集成为目的，以业务实体为核心的数据对象传输为主的SOA服务。数据服务没有明确的业务规则和含义。一般服务消费方在消费数据服务后都需要将数据同步到本地数据表，再根据业务系统自身需要对数据服务进行相关业务规则的封装和实现。

a.业务实体确认

在业务建模和数据建模阶段，已经对业务实体进行了分析，包括业务实体的类型，业务实体和业务功能的U/C矩阵分析等。业务实体是识别数据服务的基础，因此需要对业务建模阶段识别的业务实体进行确认。业务实体完全是业务视角的业务对象，而不是数据库设计中的数据库表，如采购订单业务实体可能涉多层结构和多张数据库表，但是在此处的分析只需要考虑采购订单业务实体对象。

b.服务重用性分析

在业务建模构建的U/C矩阵的基础上，可以从两个层面分析服务的重用性。

一个是跨业务系统的服务重用性，一个是在一个业务应用内部业务模块间的服务可重用性。当一个业务主数据或一个核心业务单据需要跨多个业务系统或业务模块使用的时候，则该业务实体识别为数据服务是可重用的。

c.服务实现方法分析

在服务实现的时候，一方面是考虑服务的可重用性，一方面是考虑业务敏捷要求。对于数据类服务一般可以实现为查询类数据服务，也可以实现为导入类数据服务。

当业务数据的业务敏捷性和时效性要求高时候，优先考虑实现为导入和分发类服务满足业务敏捷性的要求。

d.服务大数据量传输分析

对于底层数据集成类服务，可能涉及到大数据量传输，这种数据对实时性要求不高，但是任何一个批次传输可能都在10万级以上的数据量。对于这种情况要单独进行分析，分析服务数据量，调用频度，数据同步机制等。

对于大数据量传输在识别为数据服务的时候可以考虑ODI服务，JMS消息，数据分页等多种方式来实现。

2.业务服务识别

业务服务是有明确业务含义的，含具体业务规则和逻辑的，实现一个有价值的业务活动的一系列业务操作的组合。业务服务具有明显的高业务内聚性，粗粒度特征。

a.业务组件确认

业务组件是实现多个业务功能的，高内聚松耦合的业务功能模块单元。业务组件是可以进行独立需求分析，设计，开发，测试和部署的组件管理单元。对于一个完整的业务系统或业务流程是通过业务组件的交互和协同来完成。业务组件之间的交互则通过标准的SOA服务方式进行。即业务组件中包含了技术组件和服务组件，其中服务组件暴露业务服务。

b.业务服务识别

对于业务服务识别分为两个层面的内容。其一是为了实现跨业务组件的业务流程分析出来的业务组件之间的业务交互。其二是在用例建模阶段我们对业务操作进行了详细分析，对于这些分析整理出业务操作清单，对于业务操作清单中的可重用的业务操作识别为关键的业务服务。具体识别步骤为：

1. 根据业务流程或业务用例，绘制相应的跨业务组件协作的业务交互图。

2. 对所有的业务交互点识别为潜在的业务服务。

对业务操作活动列表进行分析，将可重用的业务操作识别为潜在的业务服务。

3.UI组件服务识别

UI组件是可以完成独立的业务功能的小业务应用。UI组件可以独立进行需求分析，设计，打包，部署和运行。UI组件是一种页面内嵌的方式在多个业务系统中运行，因此在UI组件复用的情况下，基本不需要进行底层的数据集成和同步操作，可以更好的保证数据的一致性和时效性。

对于UI组件的识别主要分为两个层面进行：

a.从顶向下识别

对于业务系统在构建中的业务系统和系统需求进行分析，在系统需求阶段会进行详细的功能需求描述和UI界面描述。可以针对这些需求文档分析重复的业务功能界面，将其识别为潜在的UI组件服务。

b.从下向上识别

该方法是首先对业务系统中的平台化功能模块进行抽象，如工作流管理，系统管理，公共技术服务等都是可以进行平台化的组件功能模块。

对于平台化的组件功能模块需要和业务系统进行界面层的交互，因此对于这些界面层交互可以由平台层提供UI组件服务内嵌到各个业务系统中使用。

4.技术服务识别

技术服务是和业务无关的，提供某种技术能力的服务。技术服务一般包括消息，安全，日志，会话，规则，异常，数据库管理等多个方面的内容。对于技术服务的识别仍然是包括了两个层面：

a.从顶向下识别

在业务建模和业务系统需求分析过程中，需要关注业务系统非功能性需求的描述，这些非功能需求包括了异常，日志，安全，性能，可靠性，高可用性，可扩展性，大数据量处理等多个方面的内容。对于这些非功能需求如果有多个业务系统或模块提出，则可以考虑抽象识别为公有的技术服务。

b.从下向上识别

该方法是从平台层面进行考虑，企业在业务系统建设过程中一般会分为产品层和平台层，对于平台层又包括了产品平台和技术平台。在进行平台化功能构建的过程中，平台层需要朝产品层提供能力，这些能力的提供都可以考虑以技术服务的方式统一提供。以实现产品层和平台层的集成。

返回上页