3.2　面向服务所解决的问题

为了更好地理解为什么出现面向服务以及如何改进自动化系统的设计，我们需要比较前后的观点。通过研究历史上困扰IT的一些常见问题，我们可以开始理解这种设计范式提出的解决方案。

3.2.1　竖井式应用架构

在业务领域，交付能够自动执行业务任务的解决方案非常有意义。在IT历史进程中，大多数创建这样的解决方案的常用方法如下：通过识别要自动化的业务任务，定义其业务需求，然后构建相应的解决方案逻辑（见图3-10）。

图3-10　为每组新的自动化需求创建一个应用程序的比率是颇为常见的

此方法已被接受并被证明可以通过技术使用实现切实的商业利益，并且已经成功地提供了相对可预测的投资回报（见图3-11）。

图3-11　计算ROI的示例公式是基于可预测回报的预定投资而得出的

从这些应用程序进一步获取任何价值的能力往往会被抑制，因为它们的能力与特定的业务需求和流程（其中一些需求和流程的生命周期是有限的）相关。当新需求和流程符合业务方式的时候，我们就要对已有的应用程序做重大变化或完全建立一个新的应用程序。

在后一种情况下，尽管重复构建“一次性应用程序”不是完美的方法，但已证明此方法是自动化业务的合法手段。首先让我们从正面来探讨一些经验教训。

·解决方案可以有效地构建，因为它们只需要关注与有限业务流程相关的那组小范围需求的实现。

·涉及定义自动化流程的业务分析工作并不困难。分析人员一次只关注一个流程，因此只关注与该流程相关的业务实体和业务域。

·解决方案设计以战术为重点。虽然有时需要复合和复杂的自动化解决方案，但每个解决方案的唯一目的是仅自动化一个或一组特定的业务流程。这个预定义的功能范围简化了整体解决方案设计以及潜在的应用程序架构。

·每个解决方案的项目交付生命周期都是可精简的、相对可预测的。尽管IT项目因为其复杂的工作而臭名昭著，充满着无法预见的挑战，当交付范围明确定义（并且不改变）时，交付阶段的流程和实现很有可能按预期进行。

·从头开始构建新系统，组织就可以利用最新的技术进步。IT市场每年都在发展，我们完全可以预料今天用于构建解决方案逻辑的技术，在明天会变得不同、变得更好。因此，反复构建一次性应用程序的组织可以在每个新项目中利用最新技术创新。

传统解决方案的这些经验和其他常见特征巧妙地诠释了为什么这种方法如此受欢迎。尽管该方案已得到认可，但显然仍有很大的改进空间。

3.2.2　大量的浪费

在给定企业中创建新的解决方案逻辑通常会造成大量的冗余功能（见图3-12）。因此，构造该逻辑所需的努力和费用也是冗余的。

图3-12　独立开发不同应用可能产生大量的冗余功能。展示的应用程序交付了各种级别的解决方案逻辑，且这些解决方案逻辑在某种形式上已经存在

3.2.3　缺乏效率

由于战术重点是为特定流程需求交付解决方案，所以开发项目的范围具有高度针对性。因此，人们始终认为业务需求应尽早实现。然而，如果能避免创建冗余逻辑，那么不断地构建和重建其他地方已经存在的逻辑就是低效的（见图3-13）。

图3-13　特定于业务需求集的应用程序A已交付。由于这些业务需求的一部分在其他地方已得到实现，因此应用程序A的交付范围比原本要求的大

3.2.4　企业膨胀

每个新的或扩展应用程序都能添加到大部分IT环境系统目录中（见图3-14）。不断扩大的托管、维护和管理需求可能使IT部门在预算、资源和规模方面面临一定程度的膨胀问题，从而会使IT成为整个组织的一大消耗。

图3-14　此图简单描绘了包含冗余功能应用程序的企业环境。其实际结果是一个更大的企业

3.2.5　产生复杂的基础设施和错综复杂的企业架构

企业不得不利用各代技术构建的许多应用，并且甚至可能不同的技术平台常常强加独特的架构要求。这些“孤立”应用程序之间的差异可能导致反联合环境（见图3-15），为应对这种演变，企业发展规划和基础设施扩展变得愈加具有挑战性。

图3-15　同一企业内的不同应用环境可能引入不兼容的运行时平台，如阴影区所示

3.2.6　系统间集成成为永恒的挑战

仅考虑特定业务流程自动化而构建的应用程序通常不按照互操作性需求来设计。这些类型的应用程序在稍后共享数据时会导致许多点对点的野蛮而复杂的拼接或引入巨大的中间件层构建的集成架构（见图3-16）。

图3-16　一个供应商多样化的企业可能引入各种集成挑战，如在试图桥接专有环境时突出关注点用小闪电表示

3.2.7　面向服务的需求

随着传统分布式解决方案一代代地重复，前述问题的严重性已被放大。这就是我们构思面向服务的原因。它确实代表了IT历史的进化状态，它结合了过去成功的设计元素与利用概念上和技术上创新的新设计元素。

前面列出的8个设计原则的连续应用导致了相应设计特性的广泛扩散：

·提高了功能和数据表达的一致性。

·降低了解决方案逻辑单元之间的依赖性。

·降低了对底层解决方案逻辑设计和实现细节的关注。

·增加了在多种目标中使用一个解决方案逻辑模块的机会。

·增加了将解决方案逻辑单元组合成不同配置的机会。

·提升了行为可预测性。

·提高了可用性和可扩展性。

·提高了对可用解决方案逻辑的认知。

当这些特征作为实现服务的真实部分存在时，它们建立了共同的协同效应。因此，企业情况也会随着以下不同品质的不断提升而改变。

3.2.8　增加大量可复用解决方案逻辑

在面向服务的解决方案中，逻辑（服务）单元封装了不属于任何应用或业务流程特有的功能（见图3-17）。因此，这些服务被归类为可重用（和不可知的）IT资产。

图3-17　业务流程由一系列业务流程特定的服务（顶层）自动化完成，这些服务共享一个业务流程无关的服务池（底层）。这些层对应第5章中描述的服务模型

3.2.9　削减应用个性化业务逻辑

增加不针对任何一个应用程序或业务流程的解决方案逻辑数量，减少所需的针对应用程序（或“非不可知”）逻辑的数量（见图3-18）。减少独立应用程序的总数量模糊了独立应用程序环境之间的界限（详见3.3.1节）。

图3-18　业务流程A既可以通过应用程序A也可以通过服务组合A来自动化完成。交付应用程序A会导致所有的解决方案逻辑体都是针对业务流程定制的。服务组合A将设计为通过可重用服务和40%额外的业务流程特定逻辑组合来自动化该过程

3.2.10　削减业务逻辑的总量

解决方案逻辑的总量会被缩减，因为自动化实现多个业务流程时相同的解决方案逻辑会被共享和重用，如图3-19所示。

图3-19　随着企业向“规范化”服务组成的标准化服务目录转移，解决方案逻辑的数量逐渐收缩。（服务规范化在5.3.3节进一步解释）

3.2.11　本征互操作性

通用设计特性的一致性实现产生了自然对齐的解决方案逻辑。当这些延续到服务契约及其底层数据模型的标准化时，基本级别的自动互操作性在服务之间得以实现，如图3-20所示（详见3.3.2节）。

注意

要了解面向服务引入的常见技术挑战，请参阅《SOA Principles of Service Design》中第4章的内容。

图3-20　来自服务目录的不同部分的服务可以组合成新的服务组合。如果这些服务设计为本征可互操作的，那么将它们组装成新的组合配置就会容易很多