soa,一种结构化商业方法

　　一种soa方法在企业和it之间建立了一种紧密的关系，提高企业的灵活性，改善软件的重复使用性，让更高程度的灵活性适应企业的需求。

　　soa的强大和灵活性将给企业带来巨大的好处。如果某组织将其it架构抽象出来，将其功能以粗粒度的服务形式表示出来，每种服务都清晰的表示其业务价值，那么这些服务的顾客(可能在公司内部，也可能是在公司的某个业务伙伴)就可以得到这些服务，而不必考虑其后台实现的具体技术。更进一步，如果顾客能够发现并绑定可用的服务，那么在这些服务背后的it系统能够提供更大的灵活性。

　　soa需要完成从以it为中心的技术向业务加速器解决方案的转型。从大与小的思路出发， soa对应bpm，it必须要注重soa的真正商业价值之所在。这意味着soa需要帮助。bpm能将部分soa价值提升到业务层面。正如一些企业ajax公司能够证明，诸如silverlight, flash/flex, 和ajax等丰富的互联网应用(ria)工具也能成为很好的soa使用者。但是一些ria应用程序并不认可企业范围内的多年性soa成果。我们需要一些商业人士像谈论crm与erp那样谈论soa，这也是他们工作的关键之处。

　　soa不需要对企业的整个it治理模型进行重大的改变。但是，soa需要在it治理做法方面以及与运营的it互动方面进行重要的改变。向soa过渡意味着在整个公司范围内进行永久性的改变。这将伴随着风险，需要有一个强大的有关安全、质量和遵守法规等事情的it治理观念。

　　soa的消费者不需要再花钱买老式的昂贵的软件堆栈了。soa设计需要一个好的方式来创造和配制可再利用性服务，无论何时何地只要有需要就能够很简易并且直接地拿出来用的方式。消费者需要成本低的选项，可以让他们从小规模开始，随需要逐渐增加对它的采用，运用点对点通讯方案可以避免使用昂贵的新服务器和集成线路，根据需求增加服务的质量和其他性能。总而言之，他们需要soa的基础构架，它能够真正符合一个soa固有的分布式特征。

　　通常，什么应该是服务这个问题的答案并不明显。功能应该与一组可重复的业务任务匹配。服务的边界应当封装一项可重用、不受上下文约束的功能。接口应该公开服务进行的工作，但要隐藏服务是如何实现的，并允许更改实现或采用替代实现。从头设计服务时，可以将其设计成对业务进行建模;包装现有服务时，创建并实现好的业务接口可能会更难。定义服务边界的潜在困难的一个有意思的例子就是在何处设置事务边界。服务通常在自己的事务中运行，确保其工作要么完全完成，要么完全回滚。不过，服务协调程序(也称为协调器或编排器)可能希望在单个事务中调用多个服务(最好是通过指定的交互，如 ws-atomictransactions)。此任务要求服务接口公开其事务支持，以便能参与调用方的事务。但这样的公开要求对调用方信任，对提供者具有很大的风险。例如，提供者可能会锁定执行服务的资源，但如果调用方永远不完成事务(没有提交或回滚)，提供者将很难干净地释放资源锁定。正如这种情况所表明的，服务的范围以及谁具有控制权有时候并不太容易确定。