【IT168 技术文章】
在今天，很可能你已经开始着手进行一个或者两个SOA项目了。当然，这并不奇怪，在世界范围内的11000家大型企业中，有95%的企业已经开始投入某种努力去实现SOA了。
市场调研公司WinterGreen Research的高级分析师Susan Eustis介绍说：“这些SOA项目中的大部分都是以各部门之间或者是部门内部的互相协调作为开始的，随后开始逐步扩展，再后来就把用户的业务管理也包括了进去。可以说，SOA在扩大其影响力之前，也是从很小的尝试开始的。”
随着学术界和工业界的研究与实践的深入展开，原来笼罩在SOA头上的炫目光环也在渐渐褪去。仅存的一道光辉可能就是SOA被业界所接受的那条真理：对于SOA来说，网络便是一切。
事实上，并不是每一个项目都能与SOA完美地搭配，或者说，并不是所有的项目都能够很好地利用SOA这一架构模式。因为如果要想使其他项目能够重用一堆已经构建好了的服务(当然，假定这种重用并不难实现)，那么，在SOA项目或者SOA服务的初始建设阶段，往往需要花费惊人的代价。另外，那些元老级的技术，如.NET和Java，仍然流行于SOA的世界中。因此，或许有很多人会觉得自己的.NET或者J2EE程序运行得还不错，那就没有必要部署SOA了。
有分析师表示：“令人欣慰的是，SOA技术已经足够成熟了，因为它在不断地吸取实践过程中的那些经验和教训，现在已经是千锤百炼了。”而来自MindTree Consulting的CTO Kamran Ozair却表示：“在过去的几年中，SOA被吹捧成了‘下一个梦想’，因此，很多项目和工程就都被部署成为了基于Web的服务，而后来人们却感觉到，这并不是一条合适的发展之路。”
或许我们最大的教训就是学习到什么时候不应该使用面向服务的这种方法。“SOA并不是一条终结之路，你需要使用SOA的时候，往往是在你需要解决一个业务问题的背景下。”一家生产数字音频设备的厂商Crutchfield的IT主管Steven Weiskircher说。
Crutchfield公司开始SOA的破冰之旅是在两年前，那时公司升级了紧急任务目录、访问中心、电子商务和零售订单处理程序，在这些程序中90%都是自定义代码。Weiskircher介绍说，他的开发团队支持代码和对象的可重用性，而且团队中的大部分开发人员对于微软的编程工具也都比较熟悉，因此，他们选用了基于.NET的服务策略，但是后来他们马上意识到，他们不得不把关注的重点转移到业务目标上，而不是以前的技术目标。
“当然，软件开发的原则在几年之内并没有什么重大的改变。代码的可重用性，以及为了保护数据所产生需求的可持续性等，都是很有价值的设计原则。因此，对于服务来讲，有其发挥功能的地方，但也有其不适用的地方”。Weiskircher说。
在这其中，服务的延时性是问题的关键。“如果你把SOA看做是Web服务的话——不同的厂商对此有不同的争论——你应该意识到服务会给你的交易带来很大的开销。任何的传输都是依赖于多个组件的，并且会给网络造成影响，包括延时、抖动和丢包等。因为在20年前传输的是简单的ASCII文件，而现在却是时常臃肿不堪的XML文件。当你再在其上添加简单对象协议(SOAP)和Web服务的安全标准(WS-ScurITy)时，就有可能会增加延时，因为光是SOAP消息的封装和解析，就会耗费不少的处理器资源和网络资源。”Weiskircher解释说。
在决定哪一段代码应当抽象成SOA服务的时候，还需要考虑的是，服务可重用性带来的利益是否大于服务延时所带来的负面影响。如果代码主要是在同一台机器的同一个应用程序中运行，那么最好还是不要采用服务的方法; 但是如果代码被许多分布式的应用程序所重用，比如在一个工作流组件中的商业流程，那么把这段代码封装成服务就是适合的。
“比如，交易可能源自于许多不同的销售渠道，但交易所产生的工作流程却是类似的。不管销售渠道是怎样的，典型的工作流程都将包括收集资金、顾客信息和用户偏好等。这些都是共享的商业规则和可重用的业务逻辑，而基于Web的服务就会对这些流程具有重要的意义。”WeiSkircher说。
还有一些用户告诫我们说，可能很多企业的现存代码并不适合SOA。美国北卡罗来纳州夏洛特的Wachovia公司的资深系统架构师Tom Caddoo说：“我们的系统是对时间和延时很敏感的系统，这些因素往往会给我们带来非常巨大的损失。”
Wachovia公司通过考察自己的应用程序和执行环境，开始部署SOA。Wachovia认为，虽然可重用性有很大的诱惑，但是却不能够以牺牲性能作为代价。当然Wachovia也不愿意永远面对那些低效的已有代码。“我们也曾经疑问‘是简单地将现有的所有业务都封装成Web服务?还是需要将程序完全地重新设计?’然而最后的结果显示，我们的可重用程序与重新编写的程序之间的比例大约是50∶50。”Wachovia说。
