众多企业都已经创建各种实验性 Web Services 项目，事实证明，这项新兴的分布式计算技术确实能够降低集
成和开发的成本。另外，一些关键的 Web Services 标准纷纷制定，强安全(robust security)和管理方面的产品也
陆续问世。对于志向远大的企业来说，他们已经在考虑下一步了。
对大多数公司来说，下一步要考虑的不再是点对点的应用，而是 Web services 在企业间以及业务伙伴间更为宽
广的应用。这种技术的变迁需要更松散耦合、面向基于标准的服务的架构。这样一个架构要求对 IT 在组织中的
角色有新的观点和认识，而不仅仅是一种实现方法。通过对业务的敏捷反应，企业可以得到实实在在的回报，
而要达到这一点，面向服务架构设计师的角色非常关键。除此之外，潜在的回报更是不可胜数-分布计算技术能
够保证对业务需求足够灵活的反应，而这种业务上的敏捷正是各公司梦寐以求而目前还遥不可及的。
分布式计算将网络上分布的软件资源看作是各种服务。面向服务架构是一种不错的解决方案。但这种架构不是
什么新思想;CORBA 和 DCOM 就很类似，但是，这些过去的面向服务架构都受到一些难题的困扰:首先，它们是
紧密耦合的，这就意味着如分布计算连接的两端都必须遵循同样 API 的约束。打比方说，如果一个 COM 对象的
代码有了更改，那么访问该对象的代码也必须作出相应更改。其二，这些面向服务架构受到厂商的约束。
Microsoft 控制 DCOM 自不必说，CORBA 也只是一个伪装的标准化努力，事实上，实现一个 CORBA 架构，经
常都是在某个厂商对规范的实现上进行工作。
Web services 是在改进 DCOM 和 CORBA 缺点上的努力。今天应用 Web services 的面向服务架构与过去不同
的特点就在于它们是基于标准以及松散耦合的。广泛接受的标准(如 XML 和 SOAP)提供了在各不同厂商解决方
案之间的交互性。而松散耦合将分布计算中的参与者隔离开来，交互两边某一方的改动并不会影响到另一方。
这两者的结合意味着公司可以实现某些 Web services 而不用对使用这些 Web services 的客户端的知识有任何了
解。我们将这种基于标准的、松散耦合的面向服务的架构简称为 SOA。
SOA 的强大和灵活性将给企业带来巨大的好处。如果某组织将其 IT 架构抽象出来，将其功能以粗粒度的服务形
式表示出来，每种服务都清晰地表示其业务价值，那么，这些服务的顾客(可能在公司内部，也可能是公司的某
个业务伙伴)就可以得到这些服务，而不必考虑其后台实现的具体技术。更进一步，如果顾客能够发现并绑定可
用的服务，那么在这些服务背后的 IT 系统能够提供更大的灵活性。
但是，要得到种强大和灵活性，需要有一种实现架构的新方法，这是一项艰巨的任务。企业架构设计师必须要
变成“面向服务的架构设计师”，不仅要理解 SOA，还要理解 SOA 的实践。在架构实践和最后得到的架构结果之
间的区别非常微妙，也非常关键。本文将讨论 SOA 的实践，即:面向架构的设计师在构建 SOA 时必须要做的事
情。
SOA 的原则
SOA 是一种企业架构，因此，它是从企业的需求开始的。但是，SOA 和其它企业架构方法的不同之处在于
SOA 提供的业务敏捷性。业务敏捷性是指企业对变更快速和有效地进行响应、并且利用变更来得到竞争优势的
能力。对架构设计师来说，创建一个业务敏捷的架构意味着创建这样一个 IT 架构，它可以满足当前还未知的业
务需求。
要满足这种业务敏捷性，SOA 的实践必须遵循以下原则：
业务驱动服务，服务驱动技术
从本质上说，在抽象层次上，服务位于业务和技术中间。面向服务的架构设计师一方面必须理解在业务需求和
可以提供的服务之间的动态关系，另一方面，同样要理解服务与提供这些服务的底层技术之间的关系。
业务敏捷是基本的业务需求
评论0