没有一种技术是万能的，ＳＯＡ自然也是如此。在用户面前，技术的拥有者不应该成为垄断者和洗脑者。

        在火热的推广之下，ＳＯＡ几乎成了万能的灵丹妙药。被推向神坛的ＳＯＡ大有剥夺用户对其利弊的知情权之势。在ＩＴ巨头们的吹捧和媒体的渲染下，ＳＯＡ已经从最初的一种软件系统架构的方法理念，发展到如今的产品化和企业部署实施阶段。

        但近来，我们发现，其实业内还有这样一种声音：ＳＯＡ的确能帮助企业提高系统开发和系统维护效率，但也会降低系统应用的效率。虽然这种声音不大，但是，我们觉得有必要让用户了解，并做出判断。

        站在软件开发的角度，ＳＯＡ将比业务流程更“小”的业务功能封装成服务，在应用时将这些服务通过中立的接口标准灵活地组合装配起来。一方面，这种松耦合的做法的确可以通过复用提高开发效率，实现系统敏捷地应对业务变化；另一方面，这种模块化、标准化的封装也可以提高系统的维护效率。

        但凡事有其利就有其弊。有一种看法认为，ＳＯＡ的开发和维护效率的提升所牺牲的正是应用的效率。

        最近，我们在一些技术论坛上发现了这样一些比较集中的言论：ＳＯＡＰ在性能是吃亏的，因为其原理是基于ＨＴＴＰ协议。但是它因为平台无关性也牺牲了很大的性能；ＳＯＡＰ是用ｘｍｌ作为通信内容的载体，所以其中有效信息是有限的，而大部分的信息传输的都是为了符合其规范……

        无独有偶，对ＳＯＡ的质疑不仅出现在技术细节上。在宏观架构方面，上海期货交易所ＣＩＯ李大鹏也在最近的第二届金融科技论坛上指出，ＳＯＡ给我们带来的就是松耦合的内部结构，标准化的信息连接和模块化的服务流程。对交易所来说，稳定性是要绝对保障的，响应速度是第二位的，最后才是架构的灵活性。架构灵活性往往是响应速度的反函数。ＳＯＡ这种模块化的架构方法，一定要注意模块的深度，否则嵌套多层这种模块就会影响其响应速度。比如在上海期货交易所，ＳＯＡ的架构深度只能达到两层，第一层是交易系统总架构，由信息总线连接交易、结算、风控等业务流程模块，下面一层以风险控制为例，采用ＳＯＡ架构连接数据采集、风险控制终端和风险控制数据库等模块。再往下就不能再封装和复用其程序模块了，最好用Ｃ语言等直接实现，否则响应速度会受到严重影响。我们且先不去考究这些技术问题是不是有被放大的嫌疑。这些质疑的声音的出现本身就代表着在一阵狂热的概念性的追捧过后，ＳＯＡ正进入一个实践的阶段，人们开始重视实际操作并进行反思。没有一种技术是万能的，ＳＯＡ自然也是如此。在用户面前，技术的拥有者不应该成为垄断者和洗脑者。当市场只充斥着一种声音的时候，其实已经没有赢家。无论是厂商还是用户，失去的都比得到的多。