对于数据集成类服务，由于数据集成类服务本身不承载业务规则，因此这类服务的粒度越粗，越适合重用。比如合同信息查询服务，把合同信息全部信息在服务中传递，服务消费方把数据取过去后可以按自己的需要使用，这样所有需要合同信息的消费方都能够满足。

　　因此对于数据集成类一般是安装粗粒度设计的方式来增加服务的可重用性。但是要看到很多时候需要在粗粒度的基础上增加其它的一些细粒度服务，比如合同信息有部分属性字段有安全性，不是所有的消费方都能查询；比如合同信息，80%的消费方都是仅仅获取合同编号和合同名称，20%的才需求获取完整合同信息，为了考虑SOA平台本身服务的性能问题，需要拆分些细粒度的服务出来。

　　对于业务类服务，则刚刚相反，业务服务的粒度越细，越有利用服务的重用。因为业务服务本身已经承载了业务规则，而业务规则粒度必须细化才能够考虑复用，复用的场所可能是在制作组合服务的时候，也可以是在进行BPEL业务流程编排的时候。举例来说，有一个业务服务叫获取客户的信用额度，这个服务在实现的过程中可能涉及到如下一些原子服务，比如：

• 　　需要获取客户本身的类型信息
• 　　获取客户的信用等级信息
• 　　获取客户的已有的交易记录信息
• 　　获取客户的信用额度信息

　　我们看到获取信用额度下的获取客户类型，信用等级，客户交易记录才是最基础的原子服务。如果有这些原子服务存在，再在这些服务的基础上增加适当的业务规则，即可以组合或编排出获取客户信用额度的服务。而客户类型获取，客户交易记录获取本身又是可以在其它业务场景重复使用的服务。

　　为何数据集成类服务，粒度越粗越容易复用，原因是业务规则已经在业务系统方实现。而业务类服务本身承载了业务规则，当业务规则一有变动往往就会影响到服务本身或产生新的服务。

　　按道理，当所有的数据集成类服务都存在的时候，业务类服务将完全可以依赖已有的数据集成类服务通过BPEL编排或组合服务来完成。原因大家可以类别传统开发过程，数据访问层的方法对应的是数据集成类服务，数据访问层的方法可以组合多个业务逻辑层的方法和函数。业务逻辑层不直接再和数据库打交道，而是直接通过数据访问层获取到需要的数据。逻辑层的方法可能会很复杂，我们可以将这些方法拆分为子方法(子方法都是单独的业务规则和校验)，这样大的业务方法只需要通过子方法组装就可以完成，也就是大的业务方法又隔离了一层，连数据层的方法都不会在调用。

　　从上面这个场景可以看到一种理想的数据服务到业务服务到组合服务的过渡方式。即数据集成类服务粗粒度，重要就是覆盖所有数据的获取；业务服务细粒度，保证业务本身的原子性和可复用性；组合类服务和应用类服务通过服务组合和服务编排完成，细粒度业务服务重用率越高越说明粒度把握的越好。

　　对于SOA的服务粒度，我们谈的比较多的是SOA本身是一种粗粒度服务设计的思路。内部的业务规则和操作可能比较复杂，但是组件之间的交互需要屏蔽这些复杂性，是粗粒度的一种服务。

　　首先再解释下怎样来界定粗粒度这个词？对于粗粒度我们还是从两个方面来看，首先是服务传递的数据的数据结构的复杂程度，以供应商查询服务来举例，如果我一次查询的是供应商基本信息+联系信息+地址地点信息+财务信息的复合实体，那么数据结构是比较复杂的，可以看做是比单纯查询供应商基本信息更加粗粒度的服务；其次可以看要实现服务所需要的结果，服务在内部所需要执行的业务操作和逻辑多少来确定，以查供应商基本信息和校验供应商信用两个服务来举例，第一个内部设计的业务操作和逻辑少，而第二个则设计到需要查询供应商交货，货品质量，材料成本等多个相关信息，经过相关规则处理后才能返回供应商信用评级，那么第二个服务可以作为是粗粒度服务，这类服务可以通过细粒度的原子服务组合或编排生成。

　　从服务的分层来看，包含有数据服务，业务服务，业务组合服务，流程服务，对于流程服务一般都是粗粒度的服务，这类服务本身可重用性已经很低，一般是个别的子流程服务可以重用，流程服务本身就是重用其它业务服务，通过BPEL编排来完成的。所以随着流程服务的不断增加，业务服务和组合服务本身的可重用性讲直接影响到系统本身的复杂度和管理难度。

　　SOA从短期来看仍然是以解决跨系统的流程集成为主，如果业务系统本身全部SOA化完全可能导致过渡设计，但是业务系统本身仍然可以参考IBM 的SOMA方法论的思路，以流程驱动和业务建模的思路来考虑CBM组件化业务模型，分析和识别关键业务组件，通过流程交互分析识别用例，通过用例进一步分析识别用例到服务模型的一个转化。对于业务系统本身的架构并不一定要完全SOA化，但是需要预留服务层，方便已有的业务逻辑方法方便的暴露为web service服务。

　　服务本身的可重用性要从两个方面来考虑，其一是该服务用于流程编排的时候的可重用性，一个可重用的服务可以用于多个业务流程；其二不是体现在流程编排上的可重用，而是体现在对服务消费方的可重用，还是举供应商查询的例子，如果ERP系统提供这个服务可以被SRM，CRM，PDM等多个系统消费和使用，则服务的可重用性高。

　　数据服务重要体现在数据集成通过服务提供和消费的方式进行。数据服务最大的特点是数据传递本身不承载业务规则，如果仅仅是数据服务即和传统的数据交换平台无异，虽然数据服务进行需要传递相应的数据表，但是我们发现仅仅是数据服务会导致本来属于某个业务系统的业务规则和逻辑外漏，而且数据服务本身虽然可重用性可能很高，但是数据服务往往却很难直接应用到服务编排。

　　业务服务同数据服务的最大区别就是业务服务本身是承担了业务规则，具有完整的业务事务处理能力。由于业务服务有明确的事务性，因此业务服务本身并不会有太大的数据量。业务服务粒度粗的时候可以屏蔽内部的业务操作的复杂性，仅仅暴露简单的业务服务接口，但是可能会导致业务服务的重用性低；但是如果业务服务的粒度太细，虽然可重用高，但是开发和集成成本也会很大。这个时候我们考虑的关键问题是一个业务组合服务是否一定要拆分出原子服务? 这些原子服务本身的可复用性和管理这些原子服务的成本如何进行权衡。

　　流程服务封装完整的业务流程或独立定义的子流程，所有需要保存服务调用之前的状态和调用结束之后的状态，并最终向客户应答的服务，都应该设计为流程服务。同时，流程服务的状态在任何一个时间点都应该是能够监控的，流程服务中本身还可能涉及到HWF人工工作流节点，调用多个业务服务或原子服务，流程服务本身一般已经是粗粒度服务。