从服务的粒度说开去
服务在SOA的架构体系中是处在一个核心的地位，SOA架构体系中的所有基础设施都是围绕着服务来转。SOA服务是为了提供业务逻辑和数据的一系列的远程调用，这个定义可能不是很准确，但从技术角度上来看，它还是能说明一些问题的。
在SOA服务从事务的角度上看，我们会把服务分有原子服务和组合服务。原子服务主要是由各个应用系统提供的一些数据和业务逻辑的一个最小的单元。我们可能通过BPM和一些建模工具对这些原子服务进行组合，获得一个组合服务。组合服务也会为两种形式，一种为有状态的，它主要是把分离出单个应用系统中的工作流，让企业有一个统一的流程定义的过程，通过重用的不同原子服务，可以达到水平整合企业内部流程的能力，也就是我们常提到的BPR(Business Process Reengineering/BusinessProcess Re-engineering，业务流程重组)。另一种形式是无状态的，它只是一个个服务的互相调用，来成生一个组合服务，在重用原有的业务逻辑的情况下快速的适应系统需求的变化。
不管是哪一种类型的组合服务，都会涉及到原子服务的粒度的问题。我个人觉得服务的粒度的问题应该SOA体系架构应用的好与坏的一个非常重要的因素。为了解决这个问题可能在整个公司的层面可能需要组成一个委会来，统一的对服务进行定义。还有一方面就是我们应该整理出一些方法论，在这里此之前我们应该有一些概念上的认识。
我们应该把服务从功能上会为两类，一类是为了提供一些业务逻辑的，一类是为了提供数据转输。我们应该对不同的服务的类型使用不同的粒度，
如果是业务逻辑，我们当然希望，业务逻辑的原子服务能尽量的小，这样才能达到一个更好重用的目的，但这样会带来很高的管理成本和性能的成本，在定义一个以业务逻辑为主的服务的时候，我们应该找到一个平衡点，这个平衡点在不同的企业或者环境下都可能是不一样的，我们不能使用一种很死板的思维来把一个企业的服务粒度直接套到另一个企业中去，我们应该在实践中找到一个方法论，来指导我们的服务粒度的拆分。
????????如果主要是为了提供数据传输的能力，我们当然希望这个粒度大一点比较好，比如，要查询一个合同，我们当然希望把所有的合同信息都查出来，这样不同的服务使用这个原子服务时，可以根据自己的需要来获取合同的信息。这当然还会带来一个安全的问题，如一个合同有一些保密信息，比如一些关于钱的部分，并不能让所有的服务都可以看到。这时候应该怎么处理呢，这时候，我们应该使用ESB的过滤器，根据不同的系统对信息进行一下过滤。因为数据传输的服务，在EAI这样的企业应用集成已经用得很多了，所以，相对来说比上一类的粒度来说还是比较容易去定义的。
?
