对面向服务模式寄予很高期望是理所当然的。但同时,在成功应用之前,还有很多东西需要学习和理解。下面探讨一些更常见的示例。
刚刚说过重用不是绝对的要求,重要的是要承认这样一个事实,即面向服务强调重用,而且是前所未有的重视。通过建立具有高百分比的可重用和不可知服务的服务目录,我们现在将这些服务定位为主要(或唯一)方式,通过这种方式它们所代表的解决方案逻辑可以并且应该被访问。
因此,我们非常从容地远离了应用程序以前存在的竖井。因为我们希望尽可能共享可重用逻辑,所以我们通过服务组合自动化实现现有的、新的和增强的业务流程。这样会使越来越多的业务需求并非通过构建或扩展应用程序,而是通过简单地将现有服务组合到新的组合配置中而得到满足。
当组合服务愈加普遍时,应用程序、系统或解决方案的传统概念实际上会随着容纳它们的竖井逐渐消失。应用程序不再由负责自动化实现特定任务集的程序逻辑自包含体组成(见图3-21)。应用程序现在只是另一种服务组合,其中一些可能参与其他组合(见图3-22)。
因此,应用程序失去其独立性。可以认为面向服务的应用程序实际上不存在,因为它实际上只是许多服务组合中的一个。然而,仔细思考,我们可以看到一些服务(基于第5章中建立的服务模型)实际上不是不可知的业务流程。例如,一个服务是代表专用于一个业务任务自动化实现的逻辑,因此没必要重用。
图3-21 传统应用程序,用于自动化实现特定的业务流程逻辑
图3-22 服务组合,倾向于利用服务目录中的不可知和非不可知服务来扮演传统应用的角色。这在本质上是建立了一个“复合应用程序”
因此,单用途服务仍然可以与应用程序的概念相关联。然而,在面向服务计算中,该术语的含义可以改变以反映一个事实,即潜在的大部分应用逻辑不再属于应用程序。
让我们重新回顾一下服务目录的概念,服务目录由面向服务原则的服务和已被塑造成标准化及(大部分)可重用的解决方案的逻辑单元组成,我们可以看到,这将挑战传统的“集成”观念。
在过去,集成意味着将两个或更多个兼容或不兼容的应用程序连接起来(见图3-23)。也许它们是基于不同的技术平台,或者它们对外连接的设计都没有做以致无法连接内部边界之外的任何东西。随着组合不同软件、建立可靠数据交换水平需求的增长,集成将成为IT工业重要、备受瞩目的一部分。
服务被设计为“本征可互操作”并构建成完全认知的,因为它们将要与潜在的大范围服务消费者交互,其中大多数在其最初交付时是未知的。如果企业解决方案逻辑的重要部分由本征可互操作的服务目录表达,那么我们就能够自由地将这些服务混合并匹配到无限组合配置中,以满足任何自动化需求。
图3-23 传统的集成架构,包括两个或多个以不同方式连接的应用程序,以满足新的自动化需求(如新业务流程G所规定的)
结果,集成概念开始消逝。在解决方案不同的逻辑单元之间交换数据成为自然的次级设计特性(见图3-24)。同样,虽然这只有当一个组织解决方案逻辑的相当大百分比由一个服务目录来表达时才会产生。努力实现这种环境,针对现有遗留系统之间的传统集成以及遗留系统和这些服务之间的传统集成可能有很多要求。
应用程序、集成应用程序、解决方案、系统——所有这些术语和它们传统上表示的内容都可以直接与服务组合相关联(见图3-25)。随着SOA化举措在企业内继续发展,有必要明确区分传统应用程序(可能存在于SOA实现中或可能实际上由服务封装)以及最终会变得更普遍的服务组合。
图3-24 将服务组合起来成为新的组合体以扮演传统集成应用的角色
图3-25 面向服务的解决方案、应用程序或系统相当于一个服务组合