【IT专家网独家】SOA在最初发展的时候，目的仅仅只是为了使应用功能可以被作为共享服务来使用，这一点牵引着这个领先的IT架构理念一步一步走到现在。不过，企业从最初开始得SOA道路到现在，都还在建立属于自己的架构体系。相比之下，不同的是在过去几年中，业务方面的需求更好的体现了这一IT技术的战略价值，而IT方面也更多的了解了业务方面需要承受多大的竞争压力。如此一来，SOA就能够提供IT与业务前所未有紧密结合的可能。
业务需要的是一组服务：能够重组，得出新业务流程以支持新的产品或服务组件。而SOA的职责所在就是发布这些服务，提供连贯一致的框架，使服务组件能够得到治理并重组为应用。虽然许多SOA的举措仍停留在早期阶段，它对增加业务反应度的承诺还是真是可靠的。我们看到越来越多的企业正推进更为高级的部署。
大部门的公司之所以对SOA理念情有独钟是因为清楚的认识到SOA能够大幅度缩短应用程序开发周期。但是，一些以SOA为指导的开发人员发现实际上有一些关键的服务治理如果处理不当将会严重降低开发速度，而不会带来理想中的开发速度。来自财经出版和信息服务公司，Thomson金融的产品核心服务管理副总裁Vladimir Mitevski说道，这是他们公司在开始SOA征途初期的时候所发现的一个令人惊讶的事实。
Mitevski指出：“如果要真的成为一个对企业产品具有指导意义的资产，一个服务需要有着许多极其严格的要求和实现策略。”很多要求看起来是非常苛刻的，比如说一些基本的XML元素名称不能用缩写，必须是字典里真正有的字，举例来说，在某些系统里的登陆程序，用户名称和密码必须是有规范要求的。之所以会有这样苛刻的要求必定是有着充足的理由。它他补充道，当你只是有着很少的一些服务时，企业的架构团队能够很容易的理解这些问题并作出正确及时的处理，但是，一旦服务开始达到一个量的时候，如果没有这些苛刻的要求，架构团队肯定则会出现种种的疏漏，工作量和工作压力都无法缓解，更严重的是如何处理服务的瓶颈将无法很好的解决。
Thomson金融有着无数的服务组件，但是相对的他们的架构团队成员则并不是很多，这正式缘于他们对这些服务组件有着极其标准的统一与要求，所以才能够很快的解决服务组件的一些相关问题。“我们不用担心每个服务组件的粒度问题，不用担心他们是如何在整个流程中怎样进行的。” Mitevski说道。只有当服务组件能够达到这样的一个要求时才会被允许进入到库中。同样，新的服务组件在得到应用之前也必须要经过这样的评估才会允许注册入库，然后再可供产品使用。Mitevski还说道：“因为得考虑让库中的服务组件能够有一个大的规模，但是基于这样的评估标准，这对于架构方面的工作人员而言确实是个难度不小的瓶颈问题。”
降低这些服务组件的顺从性并不是一个好的解决方法，这都是由所需要面对的关键应用的性质所决定的，诸如单点服务登陆，对于分析师和交易人员的基于金融市场信息的Web服务，基于网络的财务分析和服务……这些都是服务组件严谨性的苛刻前提。
Thomson公司对于遵从工作量问题的解决方案是求助于自动化、使用WebLavers的政策评估工具。Mitevski说：“这些工具是很有效的，不会错过任何一个违反案例。”为这些工具标准的遵从性制定政策是需要时间的，更关键的是架构师需要评估工具分析来确定特定的事件是否重复出现，这是否意味着开发人员对于关键政策的理解不够或者架构中的模糊点存在。尽管Mitevski发现许多违反政策案例都有由于开发人员走捷径而造成的，他还是指出：这能帮助我们看到应该怎么做更好，而一些政策的确需要调整。除少数发生的违反规定的情况外，架构师还将决定甚么时候给与开发人员例外的权限，而这些额外权限将被写上注册表以告知其他用户。
让服务组件顺从性自动化给Thomson金融带来的最大好处则是服务组件开始变得更加灵动。Mitevski说：“曾经需要20个人参与的大的流程项目，在自动化实现了之后仅仅只是需要一个人就能顺利完成。”
IT专家网原创文章，未经许可，严禁转载!
