下面我们来看看面向服务的设计，SOA之 所以在实践中难以实施的关键症结在于面向服务分析设计并没有形成统一的指导路线。而面向对象技术之所以有现在的普及，得益于各种开发过程的方法论，比如 RUP，XP等。但现阶段对于面向服务的分析设计却没有成型的指导出现。当然笔者也不排除一些有经验的技术作家有写出来，但毕竟没有形成知识系统和知识体 系。所以，开发者有些彷徨，想利用SOA的好处，但又不知道如何去做。其实随着SOA技术慢慢在案例中使用，部分敢于探索的技术作家的行文中，偶尔给出一丝SOA技术的分析设计经验之谈。
任何一种技术的出现，其实都是对开发内容进行相关分类和归类，以便减少代码冗余，增加代码复用的机会。所以我们在做面向服务的分析与设计工作时，也应该做相应的分层归类工作。本人在《面向服务设计原则遐想》中提到
业务流程层 联合运用下层服务接口层
服务接口层 作用是起到封装抽象下层应用逻辑，对上层提供接口
应用层 如：应用A、应用B等
这个还处于高层抽象的分层，我们的关注点应该在服务接口层，需要继续细分该层。暂且将该层分为
编排服务层
业务服务层
应用服务层
通过这个比较粗略的分层，可以看出各个服务层有了上下关系和归类条件。具体就是：应用服务层放一些公共的、与解决方案无关的工具服务，比如负载均衡服务、 或者是专门用于向员工发送短信息的服务(它会被多处服务所调用)等。业务服务层则放一些有业务含义的原子性业务服务，所谓原子性业务服务就是不可再分解的 业务服务，其中的分析建模技术包括“按业务实体进行分析和建模”和“按特定任务进行分析和建模”的两种方式。一般来说“按业务实体进行分析和建模”比“按 特定任务进行分析和建模”方式使得服务的复用机会更多些。毕竟“按特定任务进行分析和建模”的方式得到的服务自然是满足特定任务的大的子流程，含有了业务 流程，其实业务服务层如果严格来说只能包含业务实体，而不应该包含业务流程，因为业务流程将在编排服务层里进行归类。
这里自然有个难点，就是我们做纯粹的面向服务分析时，是要求自顶向下分解，而要求实现SOA承 诺的服务可复用性是核心，必须保证分解出来的大部分服务要有机会复用，而我们知道原子性服务的复用性机会自然更大，然后才可以随着需求的变更来组合现有的 原子性服务来实现企业业务敏捷性。这种自顶向下分析，自下向上复用的现状几乎把我们搞糊涂了。所以将服务接口层细分为更为具体的三层意义重大，否则业务流 程与业务逻辑单元都揉在一块，自然难以提高复用率。
现在已经粗略地谈到了面向服务的分析设计，那么与SCA有什么关系。SCA其实为不同粒度的复用提供了条件。
看看下图先
图1
SCA里的composite与component是核心概念，具体可以说component是可以设计为原子性服务的载体，而利用composite来做组合性服务的载体，来复用低层component的服务功能。同时SCA认为粗粒度的流程服务也可以用来作为基石来组合出其他的component与composite，所以BPEL也是component的一种实现方式。
如下图
SCA从不同的粒度复用方面提供的益处得归因于它的递归复用模式，这也与面向服务的分析设计方式有一定的映射，便于自顶向下或自下而上的分析设计工作。SCA除 了这些外，最重要的则是统一了各种不同语言实现的规范，同时利用现阶段比较优秀的IOC，DI原则来管理服务之间的引用关系，最大程度地支持面向服务开发 模式中对服务的测试，当然也是便于服务功能复用了。而服务功能复用的先决条件是服务发现，如果服务都发现不了如何复用，则块工作也是SCA的重中之重。自然，将通讯框架不仅仅局限与Web service的通讯框架，支持众多的binding类型，将通讯的代码量减至最小，也为服务的复用提供了前提条件，让开发者与分析设计者更能集中精力于业务建模，当然也一定程度增加了代码的复用性。
文章来源于领测软件测试网 https://www.ltesting.net/
