寒舍

SOA，面向服务的体系结构（service-oriented architecture）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。

对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。

虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA），它已经出现很长时间了，其定义的概念与 SOA 相似。

然而，现在的 SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（eXtensible Markup Language，XML）为基础的。通过使用基于 XML 的语言（称为 Web 服务描述语言（Web Services Definition Language，WSDL））来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 CORBA 中的接口描述语言（Interface Definition Language，IDL）可比了。

Web 服务并不是实现 SOA 的惟一方式。前面刚讲的 CORBA 是另一种方式，这样就有了面向消息的中间件（Message-Oriented Middleware）系统，比如 IBM 的 MQseries。但是为了建立体系结构模型，您所需要的并不只是服务描述。您需要定义整个应用程序如何在服务之间执行其工作流。您尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。因此，SOA 应该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。例如，给供应商付款的操作是商业流程，而更新您的零件数据库，以包括进新供应的货物却是技术流程。因而，工作流还可以在 SOA 的设计中扮演重要的角色。

此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不为您控制的外部合作伙伴进行的操作。因此，为了提高效率，您需要定义应该如何得知服务之间的关系的策略，这种策略常常采用服务级协定和操作策略的形式。

最后，所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。因此，安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。

我可以用面向服务的体系结构做什么？

对 SOA 的需要来源于需要使业务 IT 系统变得更加灵活，以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现，IT 系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。

下面举一个具体的例子。一个服装零售组织拥有 500 家国际连锁店，它们常常需要更改设计来赶上时尚的潮流。这可能意味着不仅需要更改样式和颜色，甚至还可能需要更换布料、制造商和可交付的产品。如果零售商和制造商之间的系统不兼容，那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软件流程。通过利用 WSDL 接口在操作方面的灵活性，每个公司都可以将它们的现有系统保持现状，而仅仅匹配 WSDL 接口并制订新的服务级协定，这样就不必完全重构它们的软件系统了。这是业务的水平改变，也就是说，它们改变的是合作伙伴，而所有的业务操作基本上都保持不变。这里，业务接口可以作少许改变，而内部操作却不需要改变，之所以这样做，仅仅是为了能够与外部合作伙伴一起工作。

另一种形式是内部改变，在这种改变中，零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店，这可以看作是采用店中店（store-in-store）的业务模型。这里，虽然公司的大多数业务操作都保持不变，但是它们现在需要新的内部软件来处理这样的出租安排。尽管在内部软件系统可以承受全面的检修，但是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。在这种情况下，SOA 模型保持原封不动，而内部实现却发生了变化。虽然可以将新的方面添加到 SOA 模型中来加入新的出租安排的职责，但是正常的零售管理系统继续如往常一样。

为了延续内部改变的观念，IT 经理可能会发现，软件的新配置还可以以另外的一种方式加以使用，比如出租粘贴海报的地方以供广告之用。这里，新的业务提议是通过在新的设计中重用灵活的 SOA 模型得出的。这是来自 SOA 模型的新成果，并且还是一个新的机会，而这样的新机会在以前可能是不会有的。

垂直改变也是可能的，在这种改变中，零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。如果垂直改变完全从最底层开始的话，就会带来 SOA 模型结构的显著改变，与之一起改变的还可能有新的系统、软件、流程以及关系。在这种情况下，SOA 模型的好处是它从业务操作和流程的角度考虑问题而不是从应用程序和程序的角度考虑问题，这使得业务管理可以根据业务的操作清楚地确定什么需要添加、修改或删除。然后可以将软件系统构造为适合业务处理的方式，而不是在许多现有的软件平台上常常看到的其他方式。

正如您可以看到的，在这里，改变和 SOA 系统适应改变的能力是最重要的部分。对于开发人员来说，这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生，这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发人员不同的是，架构师的作用就是引起对 SOA 模型大的改变。这种分工，就是让开发人员集中精力于创建作为服务定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起，它已经有十多年的历史了，通常用统一建模语言（Universal Modeling Language，UML），并且描述成模型驱动的体系结构（Model-Driven Architecture，MDA）。

重要的是要记住，网络上最近正在创建服务和内容方面的巨大资源。这些资源包括访问SaaS(软件服务)服务、服务市场、甚至包括一些混搭的应用程序。你可以把这些应用程序与其它 Web 2.0 应用程序、API、服务或者企业应用程序、服务混合在一起快速解决企业问题。

然而，以一个宽带网连接的价格拥有这样一种资源并不意味着你能够合适地利用它的优势。确实，你的企业还需要一些时间才能准备好利用浏览器以外的混搭技术。

把SOA/混搭结合在一起的最佳方法是在考虑混搭的情况下设计和部署第一代SOA。换句话说，就是让你的企业系统“暴露”给防火墙外面的服务或者应用程序。这件事情说起来容易做起来难。你当前的系统很可能看到不自己操作系统之外的东西(如果不是防火墙的话)。

说实在的，如果正确建立的话，大多数SOA都有能够利用基于网络的服务和内容作为混搭的资源的好处。但是，你需要设计那个能力以便使你的基础设施更有效。这就意味着要制定你没有的服务的目录并且对这些服务进行测试，把你的防火墙内部和外部的系统混合搭配起来，并且保证你的安全规划也考虑到这个问题。许多没有对这种情况做出规划的人会遇到企业看不到这种新网络的问题。我认为，这些企业在未来几年里将有巨大的战略劣势。

为了准备混搭你需要做什么呢?这个事情需要解决如下一些领域的问题：要求、设计、治理、安全、部署和测试。实际上，需要一些核心的结构活动让你到达混搭的乐土。在你创建SOA的时候，这些核心的结构活动是你现有的活动以外的事情。

需要混搭的要求来理解你的企业的本地问题。许多人犯的常见的错误是按图索骥地进行管理。他们认为许多为其它企业工作的优秀人员也将适合你的公司。事实是，依据企业的不同，混搭和SOA等观点在价值上是不同的。要考虑业务推动因素和当前架构的状态。关键的问题包括：混搭对于我的企业将有什么价值?我要实现那个目标需要做多少改变?

混搭的设计是指如下过程：确定应该如何设置这个系统，如何应用实现技术和标准以便为混搭和基本的SOA的最佳价值提供一个最佳的平台。这里的关键问题是：我将暴露什么接口和如何暴露?我如何处理可伸缩性?我如何处理可视化和非可视化混搭?我如何利用在网络上提供的服务和接口?如果有必要，我如何管理我的服务和接口暴露给其他人的问题?

混搭的治理要考虑混搭的任务和如何对混搭进行管理。考虑到混搭是由许多服务组成的，可能会成为服务本身，机构现在必须管理这些服务的整个生命周期，就像一个SOA中包含的任何服务和流程一样，从开始到分析、设计、建设、测试、部署和生产执行等阶段进行全程管理。这样，在每一个阶段都必须执行某些规则和政策。这意味着选择、建设和维护一个注册表、库、强制执行政策和熟悉混搭技术的治理规则引擎。而且混搭可能也需要生命周期管理。

考虑到你要利用不是你创建也不是你拥有的接口、内容和服务，混搭的安全是非常重要的。因此，你可能会发现你与客户数据混搭在一起的看上去无恶意的AJAX接口实际上在把你的客户数据发送到远程服务器，因此会损害你的客户列表和你的企业。必须要注意采用一个能够保护你的混搭平台价值的一个全面的和系统的安全政策和技术层。这应该与你的SOA安全混搭在一起，或者成为它的扩展。

混搭的部署意味着你已经选择了适当的实现技术和标准。AJAX显然适用于这种接口，但是，并非适用于所有的企业。此外，这个技术如何与治理和安全计划联系在一起?你将利用什么产品支持你的SOA中的混搭?它们将如何与已经在你的SOA中实施的实现技术解决方案联系在一起?

混搭的测试意味着你要考虑使用和创建一个反应它们状况的各种类型的测试计划。必须非常小心地采取措施保证你的SOA和外部“可混搭的”组件能够工作并且发挥很好的作用，保证实现技术和标准达到预期的效果。这个测试计划应该与设计、治理和安全连接起来，你必须还要考虑使用的技术。实际上，你在使用所有的它支持的组件测试一个开发平台。