面向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。 这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。 对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（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）。
面向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。 这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。 对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（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）。
选择SOA的原因和时机面向服务的体系结构 (SOA) 已成为了一项事实标准，用于开发基于组件的应用程序，可使用标准接口通过网络(Internet 或其他网络)访问这些应用程序。至少 IBM 高级管理人员和很多其他供应商、分析师、顾问和软件开发人员都这么说。他们还将告诉您，整个行业都在逐步采用 SOA，如果您尚未开始 SOA 开发，将很快跟不上时代的步伐了。 赞誉之词。但这些看法是否真的很有吸引力，能让您开始着手您自己的 SOA 吗?让我们来看看一位参加 Open Group 主办的 SOA 大会的架构师的问题。在 IBM Global Services 副总裁 Michael Liebow 的主题发言后的提问期间，这位架构师问道:“SOA 是不是我们需要知道的唯一体系结构?(顺便提一下，Liebow 先生的回答是“是的”)在稍后，另一位架构师大声问道:“SOA 和我们多年前就知道的组件体系结构很相似。如果我们采用了它，是否意味着我们又多添了一个技术竖井(另一个开发死胡同)，从而需要进行更多的集成?”(而这次，会议参加者——包括平台供应商、企业 IT 架构师、顾问、系统集成商和其他人员——回答的是“不是。”) 这就提出了我们本月要向我们的专家询问的问题。如果您和 IBM 最近接触的很多架构师一样，那么您可能正在评估甚至采用 SOA 的过程中。但您可能仍在怀疑这是否是体系结构样式的必由之路，新东西很快由更为流行的东西取代，或者，这个体系结构是否真的适用。 我们的专家对此问题的回答包含了很多您之前听到的说法:SOA 促进了可重用性，提供了接口和实现之间的抽象级别以最小化依赖关系，将业务需求与 IT 功能结合，从而可以为您提供用于将业务需求转换为编程服务来实现流程自动化的机制，以及当前竞争激烈且快速变化的业务环境中所必需的灵活性，等等。另外，这些专家还根据他们与 IBM 内外开发先驱合作的实践经验提供了一些新颖的看法，将帮助您了解 SOA 在何时如何(甚至为什么)适合在您的 IT 体系结构和开发计划中使用。 在此对本月的专栏供稿编辑 Holt Adams 表示感谢。Holt 是 IBM Software Group 团队一位经验丰富的 IT 架构师，就您将要读到的内容为内部 IBM 社区提供了指导。他还提供了他自己对这个问题的回答“何时采用 SOA，何时不采用 SOA。” 好了，不再多说，下面就请了解一下我们的专家的观点吧。(有关回答问题的专家的更多信息，请参阅本专栏最后的关于专家。)我们邀请您就 SOA 提出您的看法。您可以访问我们的 IT 体系结构讨论论坛，或通过以下地址给我发电子邮件:[email protected]。 何时采用 SOA，何时不采用 SOA IBM 的目标之一是在其产品内开发和采用开放标准。通过这样做，就能在您公司的 IT 基础结构中实现 SOA 的价值主张。SOA 能够优化业务需求与 IT 的一致性，能够将业务流程活动从服务实现中分离出来，还能够降低操作成本。只有在不固定供应商的情况下才能真正实现这些功能，此时面向 SOA 实现的技术可以无缝集成(考虑:“开放标准”)，以构造全面的端到端解决方案。 当考虑了策略业务目标和活动时，理论上的 SOA 概念非常具有吸引力，更加容易得到支持。不过，不可轻易决定要实现 SOA。这与改变生活方式有些类似，因为开发和操作团队遵循的 IT 控制模式将完全不同。我提倡进行业务驱动开发。此过程涉及到将业务需求细化为 IT 要求，然后将 IT 要求细化为 IT 功能，以确定满足这些需求所需的技术。根据我过去四年开发基于 Web 服务的解决方案和更为成熟的基于 SOA 的解决方案的经验，以下这些相关因素通常会让我建议采用面向服务的体系结构: ﹡ 集成成本持续增长，而并未因为可提供真正投资回报 (ROI) 的新业务机会而得到缓解。 ﹡ 兼并和收购是您公司扩大市场份额和获得新发展机会的业务模式的核心。 ﹡ 解决方案要求对来自异构系统和编程模型的业务功能进行集成。 ﹡ 业务的生存依赖于根据市场变化快速调整或即时响应竞争威胁的能力。 ﹡ 全球经济的影响要求您的公司事半功倍地开展业务，而且有必要依赖业务合作伙伴提供非核心业务功能。 ﹡ 就提高收益而言，与业务合作伙伴协作的效率对您的公司十分关键。 ﹡ 您公司业务资产的价值在减少，因为不能对其进行评估，以在最初用途之外的其他地方使用。 ﹡ 您公司员工的效率出现了问题，因为他们的大部分时间并没有花在提供公司业务模型的核心功能和服务上。 ﹡ 您公司的业务充满了机会型的业务工作。 ﹡ 您公司从头开始开发新应用程序。(我认为 SOA 应当作为定位将来的新应用程序的缺省体系结构样式，业务条件有其他限制时除外。) 在理想情况下，您和您的业务合作伙伴间没有预算限制、计划期限、技能差距和优先级差异，我想，此时完全可以说每个人都会采用 SOA，或者至少会考虑采用 SOA。不过，我们的选择实际上经常受到过去的决策的影响和限制(例如，技术投资、编程模型采用、服务的合同协定等)。因此，我们并不能总是自由地采用看起来能满足某个业务需求或技术要求的最佳选项。以下的注意事项会让我不建议采用面向服务的体系结构或说明现在实现 SOA 的边际收益: ﹡ 您公司只将小部分 IT 预算用于集成活动。 ﹡ 您公司的大部分流程都是手动的或以文档为中心的，自动化的机会几乎为零。 ﹡ 您公司的大部分应用程序开发都使用相同的编程模型。 ﹡ 您公司的操作由一个或两个客户关系管理 (CRM) 和企业资源规划 (ERP) 应用程序管理，几乎没有集成要求。 ﹡ 您公司的现有技能库与实现支持 SOA 的基础结构所需的技能库之间存在重大差异。 ﹡ 未发现可从 SOA 提供的功能受益的业务需求或机会。 ﹡ 新业务服务的可用性将对现有的收益流带来负面影响。 ﹡ 您公司依赖的业务合作伙伴对公司间流程的自动化采用了不同的优先级。 ﹡ 您公司的主要业务的开展涉及到海量且同步性和实时性要求非常高的事务。 前面的列表只是一个示例，用以说明 SOA 是否是您公司最佳选择的原因。当然，每个合同或项目都具有唯一的要求，因此关于何时采用 SOA 的决策取决于您公司的业务状况。SOA 的价值主张十分诱人，但选择何时让您的公司采用 SOA 必须考虑业务环境的实际情况。采用 SOA 不一定要跨一大步，而通常是采用循序渐进的方式进行的。首先找到可以利用 SOA 概念和原则的项目，然后使用主要性能指标测定其价值，这是一种让大家受益的好方法。 将业务与 IT 结合起来 SOA 不仅是一个开发范例。该体系结构用于在业务和 IT 之间构建中间地段，其中包含双方都同意的一组与业务一致的 IT 服务，这些服务结合在一起，以实现组织的业务流程和目标。此范例提供了前所未有的灵活性:它允许将业务流程的结构化组成从为流中每个活动提供功能的服务中分离出来。它还允许将业务实现与其描述分离开来。进行了此分离后，公司能以增量的方式更改其后端遗留系统，并添加新功能来支持新需求，而不用受到供应商选择的限制。因此，可以在最小化对业务流程和 IT 系统的影响的前提下对软件包和自定义应用程序进行替换。 将访问功能从其实现分离的下一步工作就是 SOA。而且，除了此功能方面外，我们还可以将非功能方面外部化。例如，我们可以根据建立的业务策略确定哪些人应该可以访问特定的功能。我们还可以定义如何管理希望以灵活的、可重构的方式访问的技术资源。 软件工程发展的下一步就是此体系结构。它使我们从结构化对象转向分布式对象和组件，然后以一组公共服务为中心来将业务和 IT 加以结合(这些服务结合在一起，可以实现组织的流程和目标)。SOA 还允许将公司的部分业务流程向生态系统中的合作伙伴公开。 当需要支持业务灵活性的 IT 灵活性时，就可以使用 SOA。因此，对于两个程序需要进行通信并访问组合业务流程的行业应用程序而言，就非常适合选择 SOA。 使用 SOA 技术时，实时或被动系统通常不是进行实现的最佳选择，因为当前的技术不支持将 SOA 用于有大量并发使用情况的实时系统。不过，这些系统的建模也可以从 SOA 提供的分离和独立概念获益。 SOA 非常适合用于消除冗余及将业务与未紧密耦合到特定服务实现的 IT 功能相结合。它可以允许服务使用者选择后备服务提供者(不仅基于功能进行选择——我需要类似的功能，但不要此版本的服务中的额外依赖项，还可以基于设计及运行时策略和 Web 服务管理功能进行选择)。 企业体系结构基于 SOA 的公司具有稳定的基础，能从现有系统概念地抽象业务功能。它们还具有允许随着新软件包、系统和资产的提供和新需求的出现以增量的方式进行业务驱动的 IT 转换的基础。 一个重要但略显不足的机制 在企业范围中，大量的创新都出现在以下两个方面:企业边缘和企业之间。在边缘上，我们可以看到在中间件之上的框架投入了很多精力(独立于领域的框架，如 Ajax，以及特定于领域的框架，以特定行业为中心进行结合)，也投入了很多精力进行与设备相关的工作 [ 典型的移动设备和具有无线频率识别(Radio Frequency Identification，RFID)标记的设备 ]。而在企业之间，我们可以看到系统(遗留系统和新系统)的系统的形成。 在此类以 Web 为中心的系统中，服务已被证实为这两个方面的重要机制。在边缘，服务提供超越基础技术的行为。而在企业之间，服务提供了各种系统间语义丰富的强大通信方式。 虽然这样说，但在系统的构造中，服务是一个重要却略显不足的机制。这样说有些过于简单化，但总的说来，服务对于高频率或非常小粒度的连接而言，并不非常适合。而且，服务当然不是唯一适合各个系统的体系结构的分解机制。
面向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。 这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。 对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（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）。
但是soa不局限于SOA这个WEB 实现
对 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）。
对 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）。
﹡ 兼并和收购是您公司扩大市场份额和获得新发展机会的业务模式的核心。
﹡ 解决方案要求对来自异构系统和编程模型的业务功能进行集成。
﹡ 业务的生存依赖于根据市场变化快速调整或即时响应竞争威胁的能力。
﹡ 全球经济的影响要求您的公司事半功倍地开展业务，而且有必要依赖业务合作伙伴提供非核心业务功能。
﹡ 就提高收益而言，与业务合作伙伴协作的效率对您的公司十分关键。
﹡ 您公司业务资产的价值在减少，因为不能对其进行评估，以在最初用途之外的其他地方使用。
﹡ 您公司员工的效率出现了问题，因为他们的大部分时间并没有花在提供公司业务模型的核心功能和服务上。
﹡ 您公司的业务充满了机会型的业务工作。
﹡ 您公司从头开始开发新应用程序。(我认为 SOA 应当作为定位将来的新应用程序的缺省体系结构样式，业务条件有其他限制时除外。) 在理想情况下，您和您的业务合作伙伴间没有预算限制、计划期限、技能差距和优先级差异，我想，此时完全可以说每个人都会采用 SOA，或者至少会考虑采用 SOA。不过，我们的选择实际上经常受到过去的决策的影响和限制(例如，技术投资、编程模型采用、服务的合同协定等)。因此，我们并不能总是自由地采用看起来能满足某个业务需求或技术要求的最佳选项。以下的注意事项会让我不建议采用面向服务的体系结构或说明现在实现 SOA 的边际收益: ﹡ 您公司只将小部分 IT 预算用于集成活动。
﹡ 您公司的大部分流程都是手动的或以文档为中心的，自动化的机会几乎为零。
﹡ 您公司的大部分应用程序开发都使用相同的编程模型。
﹡ 您公司的操作由一个或两个客户关系管理 (CRM) 和企业资源规划 (ERP) 应用程序管理，几乎没有集成要求。
﹡ 您公司的现有技能库与实现支持 SOA 的基础结构所需的技能库之间存在重大差异。
﹡ 未发现可从 SOA 提供的功能受益的业务需求或机会。
﹡ 新业务服务的可用性将对现有的收益流带来负面影响。
﹡ 您公司依赖的业务合作伙伴对公司间流程的自动化采用了不同的优先级。
﹡ 您公司的主要业务的开展涉及到海量且同步性和实时性要求非常高的事务。 前面的列表只是一个示例，用以说明 SOA 是否是您公司最佳选择的原因。当然，每个合同或项目都具有唯一的要求，因此关于何时采用 SOA 的决策取决于您公司的业务状况。SOA 的价值主张十分诱人，但选择何时让您的公司采用 SOA 必须考虑业务环境的实际情况。采用 SOA 不一定要跨一大步，而通常是采用循序渐进的方式进行的。首先找到可以利用 SOA 概念和原则的项目，然后使用主要性能指标测定其价值，这是一种让大家受益的好方法。 将业务与 IT 结合起来 SOA 不仅是一个开发范例。该体系结构用于在业务和 IT 之间构建中间地段，其中包含双方都同意的一组与业务一致的 IT 服务，这些服务结合在一起，以实现组织的业务流程和目标。此范例提供了前所未有的灵活性:它允许将业务流程的结构化组成从为流中每个活动提供功能的服务中分离出来。它还允许将业务实现与其描述分离开来。进行了此分离后，公司能以增量的方式更改其后端遗留系统，并添加新功能来支持新需求，而不用受到供应商选择的限制。因此，可以在最小化对业务流程和 IT 系统的影响的前提下对软件包和自定义应用程序进行替换。 将访问功能从其实现分离的下一步工作就是 SOA。而且，除了此功能方面外，我们还可以将非功能方面外部化。例如，我们可以根据建立的业务策略确定哪些人应该可以访问特定的功能。我们还可以定义如何管理希望以灵活的、可重构的方式访问的技术资源。 软件工程发展的下一步就是此体系结构。它使我们从结构化对象转向分布式对象和组件，然后以一组公共服务为中心来将业务和 IT 加以结合(这些服务结合在一起，可以实现组织的流程和目标)。SOA 还允许将公司的部分业务流程向生态系统中的合作伙伴公开。 当需要支持业务灵活性的 IT 灵活性时，就可以使用 SOA。因此，对于两个程序需要进行通信并访问组合业务流程的行业应用程序而言，就非常适合选择 SOA。 使用 SOA 技术时，实时或被动系统通常不是进行实现的最佳选择，因为当前的技术不支持将 SOA 用于有大量并发使用情况的实时系统。不过，这些系统的建模也可以从 SOA 提供的分离和独立概念获益。 SOA 非常适合用于消除冗余及将业务与未紧密耦合到特定服务实现的 IT 功能相结合。它可以允许服务使用者选择后备服务提供者(不仅基于功能进行选择——我需要类似的功能，但不要此版本的服务中的额外依赖项，还可以基于设计及运行时策略和 Web 服务管理功能进行选择)。 企业体系结构基于 SOA 的公司具有稳定的基础，能从现有系统概念地抽象业务功能。它们还具有允许随着新软件包、系统和资产的提供和新需求的出现以增量的方式进行业务驱动的 IT 转换的基础。 一个重要但略显不足的机制 在企业范围中，大量的创新都出现在以下两个方面:企业边缘和企业之间。在边缘上，我们可以看到在中间件之上的框架投入了很多精力(独立于领域的框架，如 Ajax，以及特定于领域的框架，以特定行业为中心进行结合)，也投入了很多精力进行与设备相关的工作 [ 典型的移动设备和具有无线频率识别(Radio Frequency Identification，RFID)标记的设备 ]。而在企业之间，我们可以看到系统(遗留系统和新系统)的系统的形成。 在此类以 Web 为中心的系统中，服务已被证实为这两个方面的重要机制。在边缘，服务提供超越基础技术的行为。而在企业之间，服务提供了各种系统间语义丰富的强大通信方式。 虽然这样说，但在系统的构造中，服务是一个重要却略显不足的机制。这样说有些过于简单化，但总的说来，服务对于高频率或非常小粒度的连接而言，并不非常适合。而且，服务当然不是唯一适合各个系统的体系结构的分解机制。
对 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）。