服务组合：SOA和事件驱动应用程序的模块化，第一部分

模块化是良好的应用程序设计的基石。 随着系统变得更加分散，我们面临着实现有效模块化的独特挑战。 您如何组织，封装和版本化松耦合服务？

在本系列文章中，我将介绍如何为两个不同的基于Java的应用程序构建模块化体系结构：一个高度可靠的SOA税收处理平台，可与遗留系统接口； 以及低延迟，基于事件的外汇货币交易系统。 OSGi，服务组件体系结构（SCA）和Fabric3作为运行时堆栈实现了模块化。

这篇文章将首先简要介绍创建这些模块化系统所涉及的技术，然后详细讨论如何使用它们为欧洲政府构建SOA税务处理平台。 在随后的文章中，我们将介绍如何使用相同的模块化技术将低延迟外汇交易架构成功交付给主要银行。

没有一种技术可以提供完整的模块化解决方案。 这是因为模块化提供了许多功能，并且在应用程序中存在于多个级别。 就功能而言，模块化：

• 通过将代码分段为离散单元来降低复杂性
• 通过允许对应用程序组件进行版本控制， 提供了一种更改机制
• 通过定义子系统之间的合同来促进重用

模块化还存在于应用程序的不同级别：

应用程序模块化

尽管上面的许多图对于Java开发人员来说都是熟悉的，但是值得定义我们所说的服务组合和体系结构模块化。 面向服务（将应用程序逻辑组织到基于合同的单元中）和依赖注入（由Spring和Guice等框架所普及）是现代体系结构模块化的基础。 简而言之，两者都有助于解耦子系统，从而使应用程序更具模块化。

缺少的是架构封装和组合。 例如，应用程序通常需要公开本身由多个查找程序服务组成的粗粒度服务。 传统的集成平台，ESB和Java EE缺少以简单有效的方式执行此操作的工具。 通过包含数百甚至数千个bean的企业服务总线（ESB）或Spring应用程序上下文公开的服务激增，您可能已经看到了这一点。

与面向对象类似，需要的是一种将服务集合分组在一起的方法，以实现更好的管理和机制来封装特定服务的实现细节：

服务模块化

Fabric3提供了一种组合机制，该机制对SOA以及事件驱动的设计均适用。 现在，我将讨论如何在税收处理系统和FX交易平台中实现这一目标。

我故意选择了这两个示例，因为每个应用程序都有一组不同的要求。 征税系统被许多人标记为SOA集成平台：它接收对征税数据的异步请求，与许多旧系统进行接口，处理结果，并将响应发送给请求方。 相比之下，外汇交易系统则关注极高的（微秒）延迟：它接收市场数据流，对其进行处理，然后向客户系统提供衍生的外汇定价信息。

税收系统架构如下所示：

税务系统架构

税收信息请求是通过自定义的可靠消息传递层接收到网关服务的，网关服务以事务方式保留消息请求并启动处理。 使用一系列复杂的规则以及与多个遗留系统的交互，处理过程可分为多个步骤。 接收和处理数据后，将通过消息传递层将响应发送给请求者。

设计系统时面临的主要模块化挑战是将核心处理（状态机通过各个阶段转换请求）与规则评估和连接到遗留系统的逻辑分开。

模块化各个子系统的主要目标是提供一种简单的版本控制机制。 例如，税收规则通常在每个纳税年度都会更改。 因此，必须与当前年度规则一起保留现有规则（以处理涉及先前纳税年度的数据请求）。 模块化的规则允许它们在不影响系统其他部分的情况下进行更新。

与旧系统连接以检索税收数据的应用程序部分也被隔离在一个模块中。 与规则类似，这允许更改外部接口的更改方式，而不会影响系统的其余部分。 模块化还提供了另一个实际目的：与遗留系统接口的代码非常繁琐。 通过细分这种复杂性，整个系统变得更易于理解和维护。

在实践中，这种模块化意味着什么？ 开发环境设置为Maven多模块构建。 基本API模块包含用于各种服务的Java接口。 用于核心处理，规则和集成的各个模块取决于相关的API模块：

税收系统模块

多模块构建强制了开发时的模块化。 例如，规则模块不能引用集成模块中的类。 OSGI用于运行时代码模块化。 API模块导出包含服务接口的软件包，而每个从属模块均导入其所需的API接口。

OSGi进出口

税收系统使用服务组合在服务级别上实施模块化。 核心处理，规则和集成子系统均由多个细粒度服务组成。 集成子系统尤其公开单个接口，用于接收来自核心处理模块的请求。 然后，此请求通过一系列服务传递，这些服务使用Web服务（WS- *）调用旧系统：

税务系统集成模块

服务组合在Fabric3中使用SCAcomposites处理。 类似于Spring应用程序上下文，组合指定了一组组件及其连接。 在此示例中，我们使用XML定义组合（Fabric3的下一版本也将支持基于Java的DSL ）：

<composite name="IntegrationComposite" …>
        <service name="TaxSystem" promote="TaxSystem"/> 
        <component name="TaxSystem>
                <implementation.java class="…"/>
                <reference name="idprocessor" target="IdProcessor"/>
        <component/>

        <component name="IdProcessor">
                <implementation.java class="…"/>
                <reference name="locationProcessor" target="LocationProcessor"/>

                <reference name="legacySystem">
                        <binding.ws uri="…."/>
                </reference>
        </component>

        <component name="LocationProcessor >
                <implementation.java class="…"/>
                <reference name="dataProcessor" target="DataProcessor"/>
                <reference name="legacySystem">
                        <binding.ws uri="…."/>
                </reference>
        </component>
                … other components …
</composite>

集成模块组合

顾名思义，组合提供了一种从私有的，更细粒度的服务组成更粗粒度的服务的方法。 在上面的示例中， 服务元素将TaxSystem服务提升或公开为组合的公共接口。

服务推广

完成此操作后，核心处理模块中的客户端服务可以将TaxSystem集成组合作为单个服务进行引用：

<component name="MessageProcessor">
        <implementation.java class=".."/>
        <reference name="taxSystem" target="IntegrationComposite"/>
<component>

有了复合材料，税务系统就成功地从代码层到其服务体系结构提供了一致的模块化设计：

服务架构模块化

经过一年多的生产，这种模块化设计的投资获得了回报。 重新编写了集成模块，以利用新的，显着不同的旧版系统接口，而无需重构其他子系统。

在下一篇文章中，我们将介绍如何使用服务组合来模块化低延迟，基于事件的外汇交易平台。 在这种情况下，服务组合被用来简化系统架构，并提供一种编写自定义插件的机制，同时保持亚毫秒级的性能。

参考： 服务组合：SOA和事件驱动应用程序的模块化，我们的JCG合作伙伴 Jim Marino在服务机器博客上的第一部分。

翻译自: https://www.javacodegeeks.com/2013/12/service-composition-modularity-for-soa-and-event-driven-applications-part-i.html