【IT专家网独家】SOA在最初发展的时候，目的仅仅只是为了使应用功能可以被作为共享服务来使用，这一点牵引着这个领先的IT架构理念一步一步走到现在。不过，企业从最初开始得SOA道路到现在，都还在建立属于自己的架构体系。相比之下，不同的是在过去几年中，业务方面的需求更好的体现了这一IT技术的战略价值，而IT方面也更多的了解了业务方面需要承受多大的竞争压力。如此一来，SOA就能够提供IT与业务前所未有紧密结合的可能。

　　业务需要的是一组服务：能够重组，得出新业务流程以支持新的产品或服务组件。而SOA的职责所在就是发布这些服务，提供连贯一致的框架，使服务组件能够得到治理并重组为应用。虽然许多SOA的举措仍停留在早期阶段，它对增加业务反应度的承诺还是真是可靠的。我们看到越来越多的企业正推进更为高级的部署。以下案例研究则是最好的证明。

　　但实际SOA实施并没有像SOA厂商希望的那样迅速为人们接受。然而，推迟应用并不是因为技术问题。通过标准化流程和政策替代特殊工具和技术手段，开发人员可以更好地坚持架构的意图而不是将每个人的努力硬塞进某种特殊工具或技术的限制或假设中。在共同架构下保持技术异质也是有现实原因的

　　厂商和解决方案提供商表示，从整合厂商的角度看，这里缺少的主要东西是向用户推销SOA商务流程好处的能力，而不仅仅是技术能力。

　　据甲骨文合作伙伴CD Group公司的首席技术官Bill DeSpain称，整个企业范围内的SOA应用是有限的。我们的成功是有限的。当你决定要采用SOA方案时，购买ESB、注册库和其他工具是很具吸引力的，这样能够使其所创建的应用程序结合起来并应用到其所执行的业务流程中去。从架构入手能帮助你确保目前和将来随时间推移后，任何需要改变的时候都有一个正确的框架来指导执行。

　　CD Group部署的试验计划通常是客户机构的IT员工推动的。然而，他们的首要任务是创建一个更灵活的应用程序架构，而不是对业务部门有明显的好处。DeSpain说，当一个试验计划转变为进入全面的SOA实施的时候，这通常是因为这个实验计划没有给业务领导人留下深刻的印象。

　　DeSpain说，他们没有认识到SOA的好处，主要是因为这个计划没有业务方面的事情。

　　据SAP负责解决方案营销的副总裁Fergus Griffin说，客户有时候把SOA看作是一个问题的解决方案。这个观点给SAP及其合作伙伴带来了同样的麻烦。客户一般不把SOA列入IP或者业务部门预算。因此，厂商和解决方案提供商需要展示SOA如何能够使他们的商务流程速度更快、更容易使用和更盈利。

　　Griffin说，成功地展示一个流畅的商务流程不仅有助于完成一笔交易，而且还是让IT与商业关系更密切的一种途径。

　　CD Group使用的一个成功的战略的是以客户商务流程的工作流为起点，然后围绕这些流程建立一个SOA解决方案，而不是采取其它的方法。这样，客户的业务和IT领导人都会立即看到SOA的好处。他说，你最终是在销售两个项目。

　　DeSpain说，从最基础的地方实施SOA通常是做起来容易做起来难。因为这个技术还不存在。甲骨文的Fusion应用程序和其它企业资源规划(ERP)计划等技术将使成功地部署SOA更加容易。他说，这是甲骨文Fusion应用程序的隐性好处之一。

　　销售SOA除了要了解许多解决方案提供商之外还需要商务流程的知识。要解决这个问题，SAP有自己的商务流程专家社区。这个门户网站有通用的SOA和ERP资源以及有关不同垂直行业的具体的商务流程信息。

　　大部门的公司之所以对SOA理念情有独钟是因为清楚的认识到SOA能够大幅度缩短应用程序开发周期。但是，一些以SOA为指导的开发人员发现实际上有一些关键的服务治理如果处理不当将会严重降低开发速度，而不会带来理想中的开发速度。来自财经出版和信息服务公司，Thomson金融的产品核心服务管理副总裁Vladimir Mitevski说道，这是他们公司在开始SOA征途初期的时候所发现的一个令人惊讶的事实。

　　Mitevski指出：“如果要真的成为一个对企业产品具有指导意义的资产，一个服务需要有着许多极其严格的要求和实现策略。”很多要求看起来是非常苛刻的，比如说一些基本的XML元素名称不能用缩写，必须是字典里真正有的字，举例来说，在某些系统里的登陆程序，用户名称和密码必须是有规范要求的。之所以会有这样苛刻的要求必定是有着充足的理由。它他补充道，当你只是有着很少的一些服务时，企业的架构团队能够很容易的理解这些问题并作出正确及时的处理，但是，一旦服务开始达到一个量的时候，如果没有这些苛刻的要求，架构团队肯定则会出现种种的疏漏，工作量和工作压力都无法缓解，更严重的是如何处理服务的瓶颈将无法很好的解决。

　　Thomson金融有着无数的服务组件，但是相对的他们的架构团队成员则并不是很多，这正式缘于他们对这些服务组件有着极其标准的统一与要求，所以才能够很快的解决服务组件的一些相关问题。“我们不用担心每个服务组件的粒度问题，不用担心他们是如何在整个流程中怎样进行的。” Mitevski说道。只有当服务组件能够达到这样的一个要求时才会被允许进入到库中。同样，新的服务组件在得到应用之前也必须要经过这样的评估才会允许注册入库，然后再可供产品使用。Mitevski还说道：“因为得考虑让库中的服务组件能够有一个大的规模，但是基于这样的评估标准，这对于架构方面的工作人员而言确实是个难度不小的瓶颈问题。”