SCA对于SOA的意义

申请免费试用、咨询电话：400-8352-114

SOA在新一代的架构理念因为其先进性站到了技术的前沿，是各大技术厂商紧跟的开发方式。当然同时也因为其先进性，使得其成为本世纪最为模糊的概念。个人都有自己的理解，使得 SOA在很大程度上给人的感觉是可以听得见，却摸不着的“神秘技术”。笔者分析其主要原因是因为Web service给人的影响太大了，大多数人对SOA的理解都差不多，觉得SOA=Web service，其实这就是最典型的理解。大家之所以觉得Web service牛，技术很强，除了因为它是一个标准和规范外，还因为大家在开发中使用到的都仅仅是Web service里的消息通讯框架，靠该消息通讯框架让普通的开发者看到了跨应用、跨解决方案，做集成的好处。自然开发者就被“蒙住了眼睛”，觉得靠使用了 Web service技术，就利用到了SOA的各种好处。这无异于金庸小说里的，只练招数，而不修炼内功修为，前期进展不错，但随着时间的推移就会发现发展潜力 不足，就那两下空招数。

下面我们来看看面向服务的设计，SOA之所以在实践中难以实施的关键症结在于面向服务分析设计并没有形成统一的指导路线。而面向对象技术之所以有现在的普及，得益于各种开发过程的方法论，比如RUP，XP等。但现阶段对于面向服务的分析设计却没有成型的指导出现。当然笔者也不排除一些有经验的技术作家有写 出来，但毕竟没有形成知识系统和知识体系。所以，开发者有些彷徨，想利用SOA的好处，但又不知道如何去做。其实随着SOA技术慢慢在案例中使用，部分敢 于探索的技术作家的行文中，偶尔给出一丝SOA技术的分析设计经验之谈。

任何一种技术的出现，其实都是对开发内容进行相关分类和归类，以便减少代码冗余，增加代码复用的机会。所以我们在做面向服务的分析与设计工作时，也应该做相应的分层归类工作。本人在《面向服务设计原则遐想》中提到：

业务流程层 联合运用下层服务接口层

服务接口层 作用是起到封装抽象下层应用逻辑，对上层提供接口

应用层 如：应用A、应用B等

这个还处于高层抽象的分层，我们的关注点应该在服务接口层，需要继续细分该层。暂且将该层分为

编排服务层

业务服务层

应用服务层

通过这个比较粗略的分层，可以看出各个服务层有了上下关系和归类条件。具体就是：应用服务层放一些公共的、与解决方案无关的工具服务，比如负载均衡服务、 或者是专门用于向员工发送短信息的服务(它会被多处服务所调用)等。业务服务层则放一些有业务含义的原子性业务服务，所谓原子性业务服务就是不可再分解的 业务服务，其中的分析建模技术包括“按业务实体进行分析和建模”和“按特定任务进行分析和建模”的两种方式。一般来说“按业务实体进行分析和建模”比“按 特定任务进行分析和建模”方式使得服务的复用机会更多些。毕竟“按特定任务进行分析和建模”的方式得到的服务自然是满足特定任务的大的子流程，含有了业务 流程，其实业务服务层如果严格来说只能包含业务实体，而不应该包含业务流程，因为业务流程将在编排服务层里进行归类。

这里自然有个难点，就是我们做纯粹的面向服务分析时，是要求自顶向下分解，而要求实现SOA承诺的服务可复用性是核心，必须保证分解出来的大部分服务要有 机会复用，而我们知道原子性服务的复用性机会自然更大，然后才可以随着需求的变更来组合现有的原子性服务来实现企业业务敏捷性。这种自顶向下分析，自下向 上复用的现状几乎把我们搞糊涂了。所以将服务接口层细分为更为具体的三层意义重大，否则业务流程与业务逻辑单元都揉在一块，自然难以提高复用率。

现在已经粗略地谈到了面向服务的分析设计，那么与SCA有什么关系。SCA其实为不同粒度的复用提供了条件。

SCA从不同的粒度复用方面提供的益处得归因于它的递归复用模式，这也与面向服务的分析设计方式有一定的映射，便于自顶向下或自下而上的分析设计工作。 SCA除了这些外，最重要的则是统一了各种不同语言实现的规范，同时利用现阶段比较优秀的IOC，DI原则来管理服务之间的引用关系，最大程度地支持面向 服务开发模式中对服务的测试，当然也是便于服务功能复用了。而服务功能复用的先决条件是服务发现，如果服务都发现不了如何复用，则块工作也是SCA的重中之重。自然，将通讯框架不仅仅局限与Web service的通讯框架，支持众多的binding类型，将通讯的代码量减至最小，也为服务的复用提供了前提条件，让开发者与分析设计者更能集中精力于 业务建模，当然也一定程度增加了代码的复用性。（IT专家网）