胡言乱语谈SCA

发个闹骚

我们习惯把那些给企业单位做项目的公司称为集成商。

现在来看，很多集成商日子并不好过，集成商由于竞争激烈，拿到项目变得比以前困难了，再加上现在给企业和单位做项目越来越难， 一个项目的实际投入和最后的回报越来越接近相等，于是利润变得越来越少。

现在的项目开发商的投入越来越大，比如一个金融行业的项目开发商，从程序员到行业专家，各个层面的人才都要有；一个项目开发过程基本就是从无到有，而以前的项目积累，真正能复用的部分很少，最多的就是拿上一个项目的需求分析，作为这个项目开发的参考，将以前的代码摘出来，能用就用，不能用的也将就用。

为了获得最大利润，开发商想尽了一切方法：比如加强对软件开发过程的管理，尽量优化开发过程；构建自己的重用库，尽量做到一劳永逸；压缩开发人员的成本支出（薪水下降），尽可能提供工作效率（加班），但是谁有能想到，即使这么做了，还是难以应付日趋增加的项目的开发成本呢，再加上国内软件行业的不规范化，钱是越来越难挣了。

而我们这些处于低层的开发人员是直接受害者：项目奖金成为了美丽的传说，按时发放工资已经成为我们在同行面前骄傲的资本，于是开发人员纷纷以跳槽向公司提出抗议。领导们的日子更不好过，面对人才流动的加剧，项目周期不得不一拖再拖，最后也只能接受客户压价的决定，面对这种得不符失的情况，领导们开始呐喊：拿什么奉贤给你，我的员工？能 发工资就不错了，还奢望项目奖金呢。就这样，恶性循环开始了。

1.1 离职

这种现象我想并不是某一家公司是这样的，应该说在很多公司都存在这种问题。那为什么导致这种问题的存在呢？竞争激烈？客户越来越难摆平？还是公司自身存在的诸多问题呢？其实，这些都不是问题，每个行业都存在上述问题，软件企业需要做的并不是解决上述问题，而是认真思考如何去降低我们的开发成本。

开发 平台/框架的诞生

就如同上面所说的，多少年来，我们为许多企业，政府部门，银行等单位开发了一套又一套的系统，每套系统的开发过程都如出一辙：需求分析，概要设计，详细设计，编码， Debug ，交付，然后紧接着就是不停地根据用户的需求更改或者增加系统功能，假设在需求分析和设计阶段，我们做得很好，能够很容易地应付用户的需求变更，但是也不能做到应变自如。

在这种前提下，近年来，有很多公司开发研发“框架平台”类产品，这一类产品可以分到中间件的范畴，作为业务逻辑层的中间件存在，它的任务就是将一些已经成型的技术和行业业务逻辑成了组件的形式，这些组件之间有着很强的交互性能，然后通过开发工具将这些组件按照业务需要像搭积木一样组合起来，形成一套业务逻辑框架。这大大缩短了开发时间。这一类的产品目前不少，比如我以前所在公司的 ezONE 平台，普元的 EOS 平台，科诺的 KA 平台，还有东方通的 BOA 等。

而这些“平台”真的能够提高我们的开发效率吗？在一定程度上说是可以的，但是这需要我们已经拥有了大量现成的行业组件。

大量的可用组件，能够让开发人员更少地去关注技术细节，而把更多精力投入到对业务本身，让我们的项目开发不会由于技术细节而耗费更多的时间。由于组件之间的可以动态进行配置，所以用户的需求变更对于开发人员来说只不过是替换一个新的组件，再改变一下组件之间的连接调用顺序而已。

2.1 “就像搭积木一样简单”

可惜的是，这些平台都各自为战，并没有一个统一的标准。

SOA 和 SCA

SOA(面向服务)并不是什么技术标准，而是一种思想，它是方法论层面上的东西，就像当年的 OOP 一样，只是一种指导我们思考问题的方法。

上面所提到的诸多平台可以说就是基于 SOA 思想的，但是大部分还是基于构件或者组件的。它们把业务功能单元设计成了服务构件，服务之间通过明确的接口定义进行连接起来，这些粗粒度，松偶合的服务能够很容易地进行整合。

但是 SOA 仅仅是一种思想，并没有一个特定的技术规范或者标准，各个厂商为了能够尽快让 SOA “落地”，于是就由数家比较大的 IT 公司推出了一个基于 SOA 思想的 SCA 框架标准。

SCA 标准目前还在完善阶段，它于 2005 年 11 月发布了 0.9 版本，目前版本已经到了 0.96 。在 0.9 版本中， SCA 标准就提出了 Java 实现以及 C++ 实现标准，而且在以后的版本中，会陆续加入其他的实现标准，也就是说 SCA 并不是只针对某一种语言的，不同语言或者环境之间通过开放的，标准的技术来实现互操作，比如我们常见的WebService等 。

SCA 提出的这套基于 SOA 去构建企业应用的编程模型，它的基础思想就将业务功能构造成一系列的服务，并且能够很好地将这些服务组合起来，达到解决业务需求的目的。在构建这些应用时所用到的服务，不仅包含新建服务，而且可以包括已有的业务应用中的业务功能，也就是说， SCA 提供了一套针对服务组合和服务创建的模型。

目前国内的 普元 已经加入到了OSOA组织，参与到了SCA/SDO的规范制定中，而且 中企动力 和 方欣科技 也作为Supporter加入到OSOA中。

而在实际开发中，很难说真存在这种一劳永逸的开发模式

可是随着时间的推移，谁能保证这些组件库的功能还能够满足用户的需要呢？退一步说，这些粗粒度的组件库能够承担多年后的开发任务吗？而对这些组件库的维护又怎么办？

所有的一切我们只能拭目以待。

异想天开

假如真的存在一个完善的，标准化的面向服务的框架平台，那我们以后的项目开发可能会是另外一种模式。

首先，在完善的面向服务框架平下，很多服务提供商开始诞生，这些提供商都是有多年行业经验的开发商演变而来，他们将以前的项目积累作为服务发布出来，根据业务不同，创建出不同的服务，每个服务能够完成一定的业务逻辑，但是需要进行整合或者二次开发。

然后在这种环境下，行业咨询公司如同雨后春笋一般不断涌现，这些公司都是由行业内部人士为核心的咨询公司，他们将多年在行业内部的经验转变成需求，提供给集成商。

而集成商还需要一些外包开发商进行支持（不是人才外包），外包开发商具有很强的技术背景，拥有一批技术开发能力很强的开发人员，专门从事技术细节的实现，能够很好地解决较难的技术细节问题。

一个项目的开发过程变成了由企业提出需求，然后通过行业咨询公司，作出更专业需求以及解决方案，跟着企业会根据咨询公司提供的方案和建议，去采购服务提供商的产品，然后将项目发给集成商，集成商再根据需要进行服务的组装集成，然后在外包公司的协助下完成项目。

以后的项目开发，不再是一家公司从头做到尾了，开发一个项目需要设计到各个领域专业性比较强的公司，这样一来，开发任务分摊到了各个公司头上，项目开发难度大大降低。

 

 
4.1 联合起来

结束语

面向服务很有可能是以后的一种开发趋势，各位开发同仁们不妨做做技术前瞻，多关注一下SCA/SDO的发展趋势，为下一阶段的工作做好准备。

有小道消息称，现在企业的CIO一听到“基于SOA”眼睛就放光……