只是业务而已
SOA 的支持者不断不畏余力地宣传 SOA 的主要技术优势:松散绑定，能够通过组件封装可重用业务功能，最后(但没有像通常那样刻意强调)还能提供更好的集成。
包括我自己也是 SOA 的支持者之一，但我不断在问自己一个问题:客户真的对这种技术推论感兴趣吗? 数据挖掘研究院
在过去两年，我一直在与希望获得 SOA 产生的价值主张的客户全面合作。在与客户沟通时，我经常发现客户认为，有很多其他体系结构能提供比我所提到的更多的技术价值。有些客户可能一厢情愿地得出结论，认为非常有经验的架构师和开发团队可以通过使用传统企业应用程序集成 (EAI) 体系结构获得很大价值。很多客户会争辩说，这些方法经过验证，实现风险并没有直接采用 SOA 进行设计的风险大。
这个观点可能会让架构师认识到在有些情况下，SOA 是错误的选择，或者，至少不是最好的选择。SOA 的技术可行性是否是选择其作为解决一系列业务问题的体系结构方法的原因?我会说不是:很多业务及 IT 相关的问题(例如缺乏有力的企业控制模型和策略)将减慢或阻碍任何构思良好的技术 SOA 活动的实现。 数据挖掘实验室
在最近一次为期三天的 SOA 研讨会上，一位汽车行业的首席技术官 (CTO) 告诉我下面的话:“我对 SOA 看法是‘只是业务而已’。”他告诉我他采用 SOA 的原因在于: 数据挖掘研究院
﹡ 提高他和他的团队实现新产品和流程或更改现有项目的速度
﹡ 降低实现和拥有成本
﹡ 通过外包业务元素或从固定定价改为可变定价(根据业务量)，从而支持灵活的定价模型
﹡ 简化合并和收购所需的集成工作
﹡ 实现更好的 IT 使用率和投资回报 数据挖掘研究院
这位 CTO 和他的团队仅关心如何使用其现有的技能(而不必放弃其现有的基础结构)在预算内按时达成这些目标。他们已经在其现有 EAI 基础结构中进行了大量投资。 数据挖掘实验室
这位特别的 CTO 的话与很多其他人的说法都不一样。他们只关心关键之处:我如何为股东提供回报? 数据挖掘研究院
当然，作为一个有经验的架构师(微笑)，我知道一些解决此问题的体系结构备选方案: 数据挖掘研究院
1. 扩展其现有的 EAI 基础结构
2. 计划采用更多的事件驱动体系结构(完全分离的、发布/订阅，等等)
3. 或许可采用 SOA
由于这是一个 SOA 研讨会，而客户为此付费，因此我最初准备选择第三个选项。实际上，对于这个情况，我使用了一点 EAI，一点事件驱动和很多 SOA 方面的东西。SOA 允许在必要时包含 EAI 和事件驱动方法。 数据挖掘研究院
对于高速发展的汽车行业，为了保持竞争优势和按时在预算内提供产品，企业必须具有灵活性。这个客户的难点集中在对其业务流程进行管理和合并。正如我的同事在此讨论中指出的，将 IT 基础结构与核心业务流程结合，对于达成目标十分关键。SOA 相关的原则已被证明可以简化业务操作，能减少与实际代码关系很小而集中在人机交互和人员活动上的冗余项。在资金有限的业务环境中，几乎没有客户能为解决特定的业务问题无限制地投入资金，而有时间并愿意对其控制流程进行修整的客户则更少了。这样做听起来不错，但却不会实际这样做。
关键在于对现有基础结构、流程和现有控制模型加以利用和扩展。通过恰当地使用现有 SOA 原则，可以对整个设计和实现流程进行管理，如: 数据挖掘研究院
1. 标识问题。 数据挖掘研究院
2. 标识组成业务并是难点所在的流程。
3. 对这些流程进行建模，以对其进行简化。
4. 标识现有服务，并编写表示这些流程的其他服务。
5. 将这些服务部署到可提供运行时功能且操作效率高的环境中。
6. 监视这些服务和流程，以获得更高的效率。
那么，网络呢?虽然我们不知道其解决方案到底是什么样的，但应当客观地看待每一个问题。请同时根据技术指标和业务指标来确定是否采用 SOA。如果合适，就使用它。如果不合适，就不用它。SOA 概念和原则将始终可以通过某种方式应用到您的体系结构中。
康庄大道 数据挖掘研究院
我们现在都应该知道了整个行业对 SOA 的 ROI 和采用的赞颂之词——松散耦合、重用更好、推向市场的时间更短、易于集成以及互操作性更好。不过，务必了解，我们目前对 SOA 的关注只是实现即插即用企业(或者说是按需企业)的历程中重要的一步而已。
随着我们进入下一个十年，我们将开始着手大幅度减少将来自不同 IT 供应商的产品或组件组合成可行的有价值的端到端解决方案所需的工作量。供应商提供的业务组件将不依赖于基础结构，可以在各种平台上执行。因此，软件开发人员会将更多的精力放在有效集成供应商组件和确保有效的互操作性上。 数据挖掘研究院
客户的 IT 操作部门将主要负责选择最适合业务需求的运行时平台;即提供恰当部署和管理业务组件所需的必要服务质量和运行时支持的平台。 数据挖掘实验室
相反，IT 业务操作部门将主要关注如何通过定义业务组件(将由其对应的操作人员部署和管理)中包含业务规则实现组织的业务策略。这将通过 WebSphere Business Process Server 之类的业务流程管理系统完成。 数据挖掘研究院
IT 业务操作部门所属的人员将是业务和企业体系结构专业人士。无论您是如何定义业务或企业架构师的:为了实现这个远景，整个行业将需要更多的具有 IT 和企业体系结构背景的人士。
虽然这个远景可能十分诱人，仍然存在很大的风险，在进入组件天堂之前，我们必须小心地减小这些风险。在开始进行实现模型服务的体系结构的任务时，最重要的减小风险方法可能就是要求有强有力的管理良好的控制流程和策略。只有通过强有力的企业服务控制策略才能够避免更改管理问题、服务间的语义不匹配和系统功能结合方面出现的难于调试的问题。IT 部门可以通过制定的控制策略来减少风险，这些控制策略由执行监督团队(其中包括 CIO、CTO 和业务线执行官)提出并加以支持。
改善信息 数据挖掘研究院
当然，您已经对 SOA 有所了解了。您也知道 Web 服务、业务流程的重要性、模型驱动的体系结构和所有这些让人诚惶诚恐的 WS-* 标准。
但或许您是一名信息人员。您需要负责组织的信息的完整性和对其进行分析。您关心表示业务状态的数据库的性能和稳定性。正如您所知的，真正重要的部分。因此，您可能会问:“为什么我应该关心 SOA?” 数据挖掘研究院
作为信息人员，我很关心SOA。我之所以关心SOA，是因为SOA 具有直接和间接影响信息管理系统的能力——事实上可以影响信息本身。为了获得成功，我们需要在业务服务所涉及的信息的上下文中对其进行考虑。我们需要知道检索到的信息是准确的。被更新的信息经过了验证。交换的信息的意义对于服务提供者和使用者都是一样的。如果忽略了这些事情，服务的价值和可重用性就会减少。 数据挖掘实验室
直接来说，使用SOA 时，我们需要在提供者和使用者之间形成一个信息协定，以便让各方知晓信息意义的内涵，并且仍然支持异构系统——换句话说，我们必须假定世界是杂乱无章的，必须对其进行整理，以提高信息的价值，了解不同的结构和意义之间的关系，并在可能的情况下就公共对象达成一致。 数据挖掘实验室
将信息作为服务公开还将让我们配备额外的信息服务器拓扑来容纳增加的信息负载。它还会要求我们建立可以对信息访问进行虚拟的点(这样用户就无需知道信息的真正位置以及其组织方式)。它还引入了一些方法，允许我们有效地对这些信息进行组合——通过集合或联合。如果没有建立更多的公共机制或引入经过改进的清除机制，则我们稍后很可能被迫投入巨额的额外资金和资源进行清除，从而导致将来的灵活性下降。
可以采用很多办法实现信息协定。其中一个变得越来越重要的就是主数据管理 (MDM) 领域。MDM 系统可为业务应用程序或服务提供经过清除、整合且特定于域的信息。最常见的 MDM 系统是作为客户和产品信息的信息集线器使用的系统。每个集线器都作为中心点使用，可以在此对信息进行添加、更新、审核、清除、搜索和查询。集线器放置于可以将更改传播到相关数据库或可以生产相关服务的事件的位置。MDM 系统可以是事务型的(在操作业务流程的主线中更新)，也可以是引用型的(提供业务流程所引用的信息的一致来源)。但最重要的是，我们可以将 MDM 系统看作其本身提供了一个一致的服务集，以供在各种业务流程内使用和进行重用。
通过 MDM 等方法显式地实现信息提供者和使用者之间的协定，可以帮助我们实现 SOA 所承诺的灵活业务流程和服务可重用性，并同时为我们提供提高所管理信息的质量的机会。
适合与不适合的场合，以及需要注意的地方
SOA 是一种组织化的方法，用于应用到由面向服务和分布式对象计算组合而成的应用程序体系结构中。让我们来将这个定义分为几部分进行分析。应用程序体系结构 是应用程序各部分的宽泛组织，通常作为层实现。体系结构指定包含哪些部分以及它们如何一起工作。面向服务将功能封装为服务——宽泛的可重用任务，可以在没有任何前一上下文(除承载服务的系统的当前域状态外)的情况下运行。服务的上下文是作为从调用方传递的参数提供的，和函数调用的参数非常相似。分布式对象 以特定方式运行在独立进程中，通过这种方式，一个进程中的对象可以调用另一个进程中的对象上的方法。
SOA 向分布式对象添加面向服务，从而可以在进程之间调用服务。它是一种用于设计应用程序体系结构的方法，以便应用程序的各个部分可以在不同的进程中运行，而且还允许不同的应用程序共享和重用正在运行的部分。它是分布式对象计算的演变，用以在多个对立方之间获得更好的平衡:需要访问彼此功能的应用程序;需要封装自己功能的应用程序;需要限制在其应用程序编程接口 (API) 中描述的对外公开的功能的应用程序;需要限制分布式调用的交互应用程序。服务支持访问通过各种任务定义良好的 API 公开的封装良好的功能，从而可以通过低频率的调用实现功能的高重用性。SOA 或许是所有方法中最好的一个。 数据挖掘研究院
以下给出了一些简单的技巧，用以确定何时采用 SOA 和何时不应采用 SOA 以及需要提高警惕的情况。
首先，适合采用 SOA 的情况:
﹡ 当数据分布程度非常高时，使用 SOA。将操作数据的代码放置在与数据较近的位置，然后将其包装为服务，以供在任何地方进行访问。
﹡ 希望功能具有高可用性时，使用 SOA。将功能作为服务部署在多个冗余的提供程序中，以在其中一些不可使用时，可以使用其他的对等服务。
﹡ 当应用程序的各个部分需要独立开发、维护和更新时，使用 SOA。只要保持各个部分之间的接口，每个团队(如两个不同的 B2B 公司)就可以使用其喜爱的技术按照自己的计划实现各自的部分。
﹡ 当多个应用程序需要重用功能和数据时，使用 SOA。共享的代码仅重用功能;服务则允许各个独立应用程序重用一组共享的企业数据，而无需将数据分发给所有应用程序。
以下是不适合使用 SOA 的情况:
﹡ 当希望开发尽可能简单时，不要使用 SOA。使用一种语言实现，在单个线程中运行，且没有远程访问问题的应用程序复杂性较低一些，因此构建和调试更为方便。
﹡ 当希望操作环境尽可能简单时，不要使用 SOA。要对松散耦合、事件驱动的分布式应用程序进行故障排除要困难得多，要求对应用程序实现细节和操作环境配置细节及其当前状态有全面的了解。
﹡ 当网络不可靠或网速慢时，不要使用 SOA。服务组件运行于独立的计算机上，通过网络进行通信，因此，其速度和可靠性依赖于这些计算机及连接这些计算机的网络。
(注:分布式冗余服务可以帮助减少硬件不可靠和网络延迟的影响。)
﹡ 进行原型设计时，不要使用 SOA。原型开发应该简单，而 SOA 并不简单。 数据挖掘研究院
对于何时需要提高警惕的问题，坦白地说，随时都要提高警惕才行。以下是一些需要谨慎行事的具体情况: 数据挖掘研究院
﹡ 当服务接口不确定时，使用 SOA 需小心。服务接口允许使用者和提供者独立地进行更改，但接口本身必须稳定。SOA 中的接口变化比在单个应用程序(特别是非分布式应用程序)中复杂得多，因为有很多在其他情况下不相关的开发团队必须就接口的更改进行合作。
﹡ 当安全性极为重要时，使用 SOA 需小心。每个服务都是一个新的易受攻击的点，必须保证其安全性。可以轻易访问服务的人越多(如在公共 Internet 上的服务)，可以尝试攻击该服务的人就越多。
﹡ 当性能极为重要时，使用 SOA 需小心。进程之间的每个服务调用都比进程内的方法慢得多。
希望功能具有高可用性时，使用 SOA 需小心。正如所指出的，冗余服务可以提高可靠性;但同时，活动部分越多出现故障的可能性就大。SOA 应用程序只与其服务一样可靠。 数据挖掘研究院
这些列表根本不足以包含所有方面，但我希望这能让您更好地了解什么是 SOA 以及适合使用 SOA 的情况。如果您需要这方面的专业帮助，请访问 IBM Software Services for WebSphere，在其中可以找到各种参考资料。
