soa框架_SOA之外：动态业务应用程序的新型框架-第二部分

soa框架

第二部分–在实践中构建动态业务应用程序–两个自适应系统的故事

生产力的提高是提高生活水平的基石。 美国的经验表明，长期强劲的生产率增长的特征是技术创新，伴随着组织结构和商业融资安排的变化以及对人力资本的投资。 然而，这些决定生产力增长的基础是一个更为根本的因素：社会愿意进行重大变革，并充满信心，认为技术进步和随之而来的经济机会将使人们改善生活。

–小罗格·弗格森（Roger W. Ferguson Jr.）和威廉·瓦舍尔（William L. Wascher），美国经济学会杰出的政府经济学演讲：过去生产力的繁荣所产生的教训，《经济观点》（第18卷，第2期，2004年Spring）

“在使这些[企业]流程自动化时，大约有10％用于实施该技术，其余90％用于变更和流程管理”

– Tesoro石油公司首席信息官Mark Evans，管理自动化，2004年3月

第一部分摘要

在本文的第一部分中，我们介绍了一种企业框架，用于构建一种称为动态业务应用程序（DBA）的新型IT系统。 这些DBA非常适合为具有动态操作的企业提供支持，该类别包含最新的业务。 第一部分还描述了如何依赖通过用例收集的需求作为系统体系结构和设计的主要输入，从而限制了当前的企业体系结构方法。 提出的新框架以业务事件模型为起点，并将企业视为具有清晰信息体系结构的自适应系统。 该框架基于自适应系统和信息的新理论，从根本上捕获了企业流程和业务变化。 引入用例是仅在设计过程的后期改进需求的一种方法。 这种框架优先的方法受传统工程方法的启发，但经过修改后可解决诸如企业之类的自适应系统。

介绍

现在是时候放弃手Craft.io并将适当的工程学纳入软件工程了。 这是复杂软件应用程序（尤其是在企业空间中）可以按照通用标准构建的唯一方法，以使其高度可靠，易于更改和易于调试。 选择并执行正确的系统架构是最重要的因素。 我们提出的解决方案使得仅使用一种系统架构就能实现标准化，而与软件应用程序无关，并且避免了昂贵的重新架构。

如本文第一部分所述，在设计软件应用程序和设计其他工程产品之间存在根本的区别。 因为软件可以处理信息，而信息是变更的“载体”，所以必须在最基本的层次上将变更内置到系统架构中。 此外，业务操作的更改方式以及技术团队将更改引入系统的方式也有很大不同。 这两个组织，一个业务和一个技术，各自对变更做出不同的响应并具有不同的操作，可以将它们视为在架构过程中具有不同要求的两个不同的自适应系统。 这就是为什么我们在本文第二部分选择副标题“两个系统的故事”。

在设计企业应用程序时，涉及两个自适应系统

如本文第一部分所述，唯一能够成功解决构建DBA复杂性的方法是使用框架优先的方法。 几个世纪以来，工程师一直使用这种方法，但是始终设计“静态”体系结构。 应用更改后，最有可能必须停止使用该系统并进行修改。 例如，更改要由组装线组装的产品需要停止生产线，应用更改，然后重新启动生产线。

如今，为企业构建IT系统的软件工程师最有可能遵循相同的道路。 当业务变化导致需要修改应用程序时，很可能会触发代价高昂的升级。 开发人员必须从头开始，提出新的业务需求，而旧的设计通常要经过广泛的重新架构。 此升级周期可能需要几个月的时间。 如果企业应用程序是由具有自己议程的外部供应商构建的，则整个过程可能会花费更长的时间，并且结果可能无法达到业务预期。 正如Mark Evans所说的那样，这项努力的90％以上与仅应用更改直接相关。

借助自适应系统及其信息体系结构的新理论（请参阅边线），我们为企业应用程序设计提出的解决方案引入了两个互补但独特的框架。 这两个框架使我们能够有效地处理和协调业务运营和技术团队运营中的变更。 对于设计过程，可以将业务运营和技术团队运营视为两个不同的自适应系统，每个系统都有自己的要求。

业务运营可以通过基本动态业务平台的一般概念来表示。 应用自适应系统理论，任何企业业务功能都具有三种基本过程。 主要流程类型支持正常操作，而其他两个则负责引入变更：内部决策流程处理管理和其他企业变更决策，而业务环境变更流程处理客户决策和其他外部变更源。 结果，针对业务流程或价值周期构建的业务流程框架（基本动态业务平台）由两个不同的变更管理平台处理两种类型的变更。 从信息处理的角度来看，可以将支持这些操作的系统与围绕事件模型构建的“信息组装线”进行比较（请参阅第I部分）。 可以通过采用丰田精益生产最佳实践中类似于“价值流图”方法的方法来确定企业的业务运营。 结果，生命周期/事件模型成为系统设计和体系结构的主要驱动力，从而消除了不可靠的用例集合，将其作为系统体系结构的主要输入。

技术运营有其自身的挑战和动态。 技术操作的主要目标是最大程度地提高各个团队协作以引入变更的能力。 基本动态业务应用程序是一种自适应系统，具有两种类型的流程：运营和运营变更。 这两个过程将业务用户与技术支持（运营）和开发（运营变更）联系起来。

图1.需要使用业务流程和业务系统变更管理框架来构建和维护基本业务动态平台。

这两个框架都必须合并到一个独特的系统设计中，该设计必须同时考虑技术团队操作和业务用户活动。 该系统是围绕服务器端体系结构构建的。 这是在模拟不同类型用户的结构和控件层次结构时为其提供支持的唯一方法。

设计服务器端基础结构的复杂度要比桌面应用程序高几个数量级

每个企业软件设计人员都意识到，为企业实施完整的客户端-服务器应用程序比构建桌面应用程序更加困难。 在桌面情况下，该界面围绕一个角色，一个主要任务和一个清晰的界面构建，整个应用程序都在一台计算机上运行。 该接口可以围绕一些可以实现为功能的小步骤构建。 在服务器端的情况下，实现要复杂得多。 服务器端情况的一个复杂原因是期望必须实现一个以上角色，包括管理者。 管理者不太可能扮演被动角色，并且需要一个界面，该界面允许他在需要时更改操作参数。 另外，技术支持必须监视应用程序的正常使用

为了更好地理解实现桌面应用程序和客户端-服务器应用程序之间的区别，我们可以查看桌面应用程序成为客户端-服务器应用程序所需的条件。 假设我们需要使用作为服务器端应用程序实现的MS Word来写一封信。 首先，您需要技术支持代表来设置字体，页面和所有其他设置。 每当需要其他设置时，都必须致电技术支持进行更改。 在编写时，管理员必须批准字体，字母头等。完成后，同一管理员可能需要在发送字母之前批准。 尽管此示例看起来很简单，但是当试图将在开发桌面应用程序中获得的专业知识外推到客户端-服务器应用程序时，它有助于理解软件架构师所面临的挑战。

实际上，当多个用户使用同一应用程序，业务或技术时，则需要一种完全不同的方法。 该体系结构必须为分布式（用户可能位于不同位置并使用不同机器）的任务或流程提供支持，有状态（状态不再由应用程序中硬编码的下一个Window定义），动态（经理或外部用户可能要求即时更改业务实体的实例，类似于经理可能要求不再以相同价格出售产品或服务或客户可能要求更改商品或服务的方式。顺序）和层次结构（所有组织都有控制层次结构，因此各个用户对流程的控制不同）。 所有这些新属性都必须嵌入应用程序的基础中，否则每次进行更改时都必须将其重写。

但这不是设计服务器端应用程序时的唯一区别。 当桌面应用程序崩溃时，用户只需重新启动它即可。 因为它仅执行简单的任务，所以即使丢失了大部分工作，它也可能总是重新启动工作。 用户不需要单独的技术团队来协助他运行应用程序。 对于客户端-服务器应用程序，情况完全不同。 由于多个用户同时工作，因此当出现问题时，只有具有技术知识并有权使用工具来监视应用程序的技术支持团队才能对如何使应用程序恢复正常运行做出正确的决定。 技术团队拥有自己的运营蓝图，该蓝图与业务运营蓝图完全不同。 技术团队拥有自己的受控流程层次结构，自己的分布式环境，自己的实施更改方式以及自己的状态。

结果，设计能够在企业级运行的客户端-服务器应用程序比台式机应用程序复杂几个数量级。 服务器端应用程序的主要复杂性源于以下事实：它必须支持两个自适应系统，一个用于技术团队，一个用于业务团队，每个系统都有自己的操作和受控的层次结构。 在设计同时支持管理和技术支持自适应系统的应用程序时，需要遵循适用于自适应系统及其相关信息的法律。

在设计这些类型的复杂系统时，不必在每次引入业务或技术变更时都重做理想的架构。 理想的情况是拥有一组标准组件，这些标准组件具有定义为行为模型的明确定义的行为。 这些组件通过在不同控制级别实现的事件模型以受控的层次结构链接在一起。 在桌面上时，有一组定义明确的组件及其各自的事件模型，这些组件通过清晰的受控层次结构链接在一起。 服务器端还远远不够开发。 J2EE，.NET或使用中的任何其他现有专有体系结构都缺少为以下环境提供支持的基本组件：分布式，动态，有状态和分层。 由于Web标准仅是无状态的，固定的，静态的和单服务器的，因此将它们应用于一种自适应系统（更不用说两种自适应系统）时，它们并没有太大帮助。

根据自适应系统的定律及其相关信息，受控层次结构始终符合以下三种模式：

• 初始化过程始终具有相同的自顶向下顺序
• 层之间的信息传递始终遵循某些规则：命令从上至下流动，反馈从下至上流动
• 每层都有自己的常规操作，只有收到反馈或命令后，这些常规操作才会改变。 处理命令或反馈始终需要变更管理功能。 而且由于存在两种类型的交互（命令和反馈），因此存在两种不同类型的变更管理

我们将展示如何使用标准组件为基于服务器的应用程序实现标准体系结构，这些标准组件以动态，有状态和分布式的受控层次结构链接在一起。 但是首先，我们介绍了另一个计算机用户都非常熟悉的以事件为中心的平台。

微软的财富来自于一些组件和用于GUI的静态事件模型

微软取得如此成功的原因有很多，但其中一个引人注目。 他们将Windows操作系统构建为桌面标准，尽管遭到了苹果或IBM的批评和竞争。 一个解释可能是，微软不仅是第一个提供像Mac一样的操作环境的公司，而且还提供了最简单的OS和GUI组件，这些组件实现为一组可使用的API。 使用此组件模型，包括Microsoft在内的软件公司都能够构建数据库，办公应用程序和Visual Basic等开发工具。 这些应用程序能够利用结构和控件中内置的Windows嵌入式分层事件模型。

微软在开发Windows时所具有的优势是，操作系统和GUI的大多数主要元素以及它们的事件模型已经存在，或者可以凭直觉轻松构建。 对于任何桌面应用程序，受控的层次结构看起来都非常简单。 在GUI堆栈的顶部，有一些窗口，其作用类似于其余GUI组件的容器。 打开窗口，嵌入式控件也会自动初始化。 关闭窗口，所有组件也都关闭。 在API中捕获这些事件，Windows应用程序的开发成为插件体系结构。

图2. Microsoft Windows控制的层次结构模型-一个用户，一个应用程序，一个位置，一组静态功能

这些API的实现是Windows操作系统本身。 它是控制初始化过程的层，并且是最终必须处理错误而又不会崩溃和丢失数据的层。 在服务器端，由于需要为有状态，动态，分布式和分层任务提供本地支持，因此组件，它们的事件和受控层次结构变得复杂。 这是Adaptive Enterprise Operating Platform（AEOP）的主要目标。

拟议的AEOP通过围绕动态结构和控制进行设计来提高生产率

几年前，IBM招募了数千名企业架构师，以减少他们为各种垂直行业定制的解决方案的数量。 一年多之后，他们能够将申请数量从60多个减少到不到20个。 努力的程度和不那么出色的结果表明了问题的严重性。 尽管拥有大量资源，但是IBM很难创建一个适用于所有客户的通用解决方案，而不论他们的垂直行业或规模如何。 使他们的工作复杂化的一件事是，他们从一组错误的旧式解决方案开始。

我们的目标是相同的：创建几乎可以普遍适用于所有行业的通用解决方案。 有了自由思考的自由，我们专注于最重要的基础知识。 尽管大多数企业体系结构都依赖于现有技术，组件或诸如SOA之类的趋势，但AEOP体系结构却不止于此。 首先要了解技术在业务中的基本作用，即提高生产率。 此角色对所有技术解决方案（无论是否为IT部门）均有效。 在IT案例中，由于业务动态以及企业系统用户之间存在复杂的关系，因此需要围绕企业流程的结构，控制和动态来构建体系结构。

这种方法还提供了一种方法来解决由Nicholas Carr在2003年5月发表的《哈佛商业评论》上发表的“ IT无关紧要”的讨论。询问IT是否与企业相关，就像询问组装线是否在是否与企业相关。 尽管对于通用汽车或丰田汽车公司来说至关重要，但它几乎是任何制造公司的一部分，包括像英特尔这样的高科技行业的明星。 在食品或保健领域等定制产品或服务广泛普及的行业中，装配线的影响要小得多。 尽管它对通用汽车公司这样的公司很重要，但组装线无非是提高生产率的推动力。 对于IT来说也是如此，这对于一家依靠信息处理来运营的公司可能很重要，但与其他公司的相关性可能要小得多。 与IT的唯一区别在于，它比装配线还不成熟。

要分析IT如何提高生产力，就需要研究驱动技术开发后如何交付和使用的基本业务机制。 我们必须查看与信息处理相关的基本角色，并询问驱动企业运营的核心信息元素是什么。 在工程领域，此过程已广为人知，并且可以在几个示例中看到。 工程师开始设计飞机时，从来不会将飞机看作是螺母，螺栓，电线，连接器，泵，电动机，杠杆，面板等零件的集合。他着眼于将它们连接起来以及它们的作用发挥交付功能。 飞机的结构围绕机翼，发动机，驾驶舱和主体构建，并遵循可控制的层次结构，该层次结构使各个参与者之间的相互作用最大化。 建筑师设计房屋时也是如此。 直到建筑师知道所需的卧室数量以及将要居住在房屋中的家庭数量之前，空调的类型，电器或要安装的布线都不重要。

在当今的方法中，企业软件主要是通过专注于技术组件和标准来进行架构/设计的。 需求是在事后评估提高生产力或企业软件结构，控制和动态的。 实际上，高级体系结构建议仅围绕表示，业务和持久层。 当前的体系结构方法都没有提供支持动态，分布式，有状态和分层业务流程体系结构现实的解决方案。

要使用更好的类比，请看工程师如何设计装配线。 首先，它们的设计易于维护和维修。 这就是为什么装配线体系结构和设计围绕可互换，模块化和标准化的组件构建的原因。 由于装配线不会动态变化，因此第二个条件是易于为新模型重新配置。 这就是为什么机器人在装配线上如此受欢迎的原因。 不论它们多么复杂，都可以轻松地对它们进行重新编程，以应对当前和将来的各种任务。 仅在满足这两个条件后，设计工程师才评估并尝试优化每个特定任务。

为了设计/设计通用的AEOP，我们确定了设计中需要考虑的三个基本因素，它们对提高生产率有很大的影响。 不论其领域或规模如何，对于所有企业而言，它们几乎都是相同的：

1）通过为技术支持，开发人员和业务用户之间的协作事件提供支持来提高技术团队运营的生产力

对整个体系结构的最大影响是不同技术团队与业务用户之间的关系以及如何引入需求变更。 因为IT团队是花费最多时间在应用程序上的团队，所以提高其生产率应该是该体系结构的最高标准。

在这种情况下，技术团队的正常运作的结构和控制很简单。 业务用户打开一个触发业务事件的应用程序。 这些事件使应用程序处理信息。 技术支持团队将监视应用程序。 在应用程序投入生产时，开发团队通常会计划下一次升级并实施新的需求变更。

整个过程的控制遵循相同的层次结构：控制金字塔的顶部是开发人员团队。 他们拥有对实现的全部控制权，因为它们是对未来功能进行硬编码的控件。 接下来是技术支持团队，因为他们可以停止并重新启动服务器或更改某些系统配置。 对应用程序控制最少的团队包括业务用户，经理或工作人员。 他们只能遵循应用程序脚本。

由于业务是动态的，因此更改系统功能的请求可能会很早提出，甚至在应用程序安装和运行之前。 实际上，要求仅在下一次会议召开之前才有效。 因此，当我们查看驱动生产力的因素时，如何将更改转换为代码是一个重要因素。 在AEOP中，引入更改后会找到相同的用户组。 开发团队是接收更改请求的团队，负责监视应用程序的团队将其安装并接受培训以支持它，然后培训业务用户以使用新功能。

由于这种结构和受控的层次结构，企业应用程序的顶层始终围绕三个平台构建：一个为开发团队实现功能，一个为技术支持团队实现功能，以及一个为业务用户提供支持的平台。 每个人都有自己的主要生命周期和事件模型来驱动设计。

因为AEOP的构建主要是为了支持技术团队运作的动态，所以三平台结构，其组件和事件模型是围绕变更请求的生命周期构建的。

2）通过为三种基本类型的业务用户之间的协作事件提供支持来提高业务运营的生产率

基本业务用户类型之间的协作对生产力产生了第二大影响。 在任何企业过程中，最多都存在三种基本用户类型，分别代表自适应系统的三个领域：代表业务的工人，代表决策过程的经理，代表价值循环的经济环境。 价值周期的其他业务参与者，例如供应商和政府机构，都扮演着次要角色，可以用三个基本流程之一（运营，管理和环境）来确定其流程。

业务是动态的。 业务中最大的生产力杠杆之一是引入变更的流程的效率。 企业有两种类型的变更：经理引入的内部变更和客户引入的外部变更。 这些更改有时是作为企业应用程序的更新引入的。 有效的架构/设计必须考虑到这种动态。 企业应用程序的理想体系结构能够以最少的代码和配置更改适应大多数更改。 由于企业越来越依赖于技术来进行运营，因此快速有效地更新应用程序的方法对于提高整体生产力至关重要。

基于此，AEOP仅定义了三种类型的企业体系结构用于业务运营中的高级协作：

• 静态架构：完全可操作-当前所有企业软件都属于此类。 通过向IT部门提出请求（通常至少导致停止应用程序），可以完成对业务流程的更改，而不仅仅是最琐碎的配置更改。 静态体系结构行为类似于在引入新模型时在汽车制造商处停止的装配线。
• 仅内部（内部决策）驱动的动态体系结构：为动态操作提供支持，并实现经理与工人之间的关系。 在这种情况下，将在正常操作期间自动考虑经理的决策，并将更改即时应用于所有当前实例。 由于经理和工人的工作时间不同，因此他们需要一个变更管理平台来处理内部决策，以桥接他们的活动。 此类流程不属于客户不直接扮演的角色。
• 扩展（内部和外部决策）动态体系结构：为动态操作提供支持，并使用户，工作人员，经理和客户这三种基本类型之间的协作自动化。 这是业务运营最复杂的架构。 它具有两种不同的变更管理平台，一种用于内部决策应用于常规操作的方式，另一种用于希望在常规操作期间更改其订单执行方式的客户。

请注意，在任何企业中，无论其类型如何，业务流程始终总是“连接”到管理“命令和控制”结构以及客户反馈。 结果，每个应用程序都属于“完全动态”类别，而不管其目标业务流程如何。

运营平台体系结构的动态围绕业务变更生命周期进行。 它们由内部决策（经理做出内部决策）和外部变更（客户可以决定将变更应用于正在进行的现有订单和服务）驱动。

3）通过提供在生命周期/事件级别完全分离的架构来提高开发团队的生产力

以前的生产率因素与业务变更对体系结构/设计的影响有关。 理想情况下，可以通过更改管理模块的接口将业务更改容纳在体系结构/设计中。 这些界面使管理人员和客户可以将更改自动应用于所有进行中的操作。

有时，更改需要开发团队实施新功能。 实施新功能时，应用程序体系结构/设计应支持高生产率。

当前的方法是将几个可以访问数据库的组件组合在一起，称为“业务层”。 此设计存在一个基本错误。 此设计中使用的数据库很可能是关系数据库，其存储历史或状态信息的能力非常差。 他们主要依靠缓存机制，这是计算资源的巨大消耗者，它们在后台不断更新大量数据。

企业中的所有业务流程都以一种或另一种方式链接到主要业务实体，即产品或服务。 对于链接到主要业务实体的业务流程，最重要的方面是现有历史。 即使是最简单的交易也是如此。 去商店购买商品时，假定您以前的财务资源历史记录将为您提供足够的财务“资源”来购买产品，而商店具有要“出售”的产品。 实体的历史由最终描述其整个生命周期的事件组成。 因为可能更改实体状态的事件可以在业务结构内的任何地方触发，也可以在多个控制级别上触发，所以围绕此业务实体动态构建的AEOP架构必须是有状态的，分层的和分布式的。

因为生命周期是围绕事件构建的，所以整个AEOP都可以围绕事件构建。 任何事件实现都可以通过使用相同的通用方法来完成：整个生命周期可以被视为反映主要业务实体转换的信息的“装配线”。 结果，该事件可以用相同的结构来实现，组合信息元素1）从某个位置（分布式）需要检索的信息元素2）在某个特定时刻存在（例如，检索信用卡交易的帐户信息）必须实时完成）； 3）可以由某个业务流程实施； 4）已应用某些业务规则。

AEOP的另一个优点是能够围绕同一事件模型设计两种类型的变更管理。 最后，可以在事件级别分离操作平台的整个实现。 可以将操作平台构建为插件API基础结构，类似于围绕桌面集成事件模型构建Windows API的方式。

重要的是要注意，文献中发现的EDA（事件驱动体系结构）模型与AEOP事件模型不同。 EDA围绕一系列非结构化事件构建，而AEOP围绕一系列结构化事件构建，这些事件通过一组清晰的生命周期模板链接在一起。

图3. AEOP控制的层次结构模型-许多用户，许多客户端应用程序，许多分布式位置，许多静态功能按更改类型动态分组

组件的AEOP层次结构及其事件模型包含5个级别：

• 操作系统级别-在这里可以找到所有操作系统组件，例如内核，文件系统，网络和I / O。 操作系统可能还具有GUI组件，可用于运行图形工具来监视各种应用程序及其活动。
• 技术级别-在这里可以找到所有传统的基于服务器的组件，例如应用程序服务器，BPM引擎，业务规则引擎，数据库。 这里还有实现Web和Web服务，消息传递等标准的组件。它们在平面设计中起着相同的作用，或多或少地发挥了标准化的作用。 螺母，螺栓，电动机，液压泵，电线，连接器，椅子，配电盘，执行器是许多其他工业设备通用的，并非特定于飞机。 尽管如此，它们在简化和标准化设计中起着关键作用。
• AEOP技术操作级别-这是具有特定于AEOP组件的顶层。 有三个组件-安装/启动/持久性/还原平台，系统平台和操作平台。 它们代表三个团队的协作以运行客户端服务器应用程序：业务用户团队，技术支持团队和开发人员团队。 每个组件都实现特定的事件，例如技术支持团队监视错误并重新启动应用程序的能力。 对于需要使用外部系统的应用程序，有第四种类型的组件称为“外部系统管理程序平台”。 该组件管理初始化，正常操作和与外部系统交互的错误转换。
• AEOP业务运营级别-这是业务实施的最高级别，而运营平台则是下一个级别。 它还具有三个主要组件：正常操作，用于内部决策的变更管理和用于外部环境交互（即客户决策）的变更管理。 还有许多其他组件，包括用于外部系统的操作翻译器，系统图，许可管理器等。
• AEOP事件处理级别-这是实现的插件级别。 已启用的业务流程的整个正常操作都在此级别实现。 因为每个功能都分解为事件级别的功能，所以整个架构在事件模型周围是分离的。 这可能包括操作错误，操作更改甚至安全访问。

显然，在AEOP的简短描述中没有涉及许多组件和事件。 在下一节中，我们将采用三个组成部分，并对它们进行更深入的分析。

AEOP事件模型和事件驱动体系结构（EDA）之间存在差异。 EDA是一种软件架构模式，可促进事件的产生，检测，使用和响应（来自Wikipedia）。 EDA缺少的是如何捕获业务流程的结构和控制。 此外，AEOP区分三种事件，一种是正常操作，一种是驱动内部更改，另一种是外部更改。 与使用相同方法来处理所有模块的EDA相比，它们位于要处理的不同模块上。 AEOP使用生命周期将事件分组为分布式，分层，有状态和动态的结构。

AEOP中信息的“组装线”围绕动态生命周期模式的多壳容器构建

所有现代软件平台都是围绕某种形式的容器模式构建的。 AEOP也不例外。 基于J2EE的应用服务器甚至具有两种容器，即Servlet和EJB。 操作系统可以被视为应用程序的一种容器形式。 容器的概念与计算机资源有限的想法相关联。 在AEOP架构中，容器的用法有所不同：

• 容器创建和管理的对象是业务实体资源的直接表示。 例如，AEOP操作容器管理整个订单生命周期，而不仅管理反映现有计算机资源的对象。
• 容器能够区分将作为正常事件序列的一部分更改托管资源状态的调用与将触发正常操作之外的更改的调用之间的区别。 因为存在两种类型的更改，所以每个容器都将具有两种类型的更改管理模块。 AEOP容器支持托管资源的动态生命周期，以比现有的静态体系结构更好地支持企业动态的现实。
• 容器不是像J2EE应用程序服务器中那样的独立结构。 容器根据受控的层次结构链接。 集成事件模型驱动如何接收和处理系统外部生成的事件。 在这种情况下，既不在层次结构的顶部也不在底部的容器扮演双重角色，一个充当资源生命周期管理器，另一个充当托管资源。 这就是为系统容器提供多外壳结构的原因。

整个AEOP体系结构和实现都是围绕模式构建的，该模式表示一个容器，该容器管理代表真实业务实体的资源，区分正常操作和变更，并且是反映业务控制层次结构的一部分。

图4. AEOP多壳容器架构将技术操作放在顶部，业务操作放在中间，事件处理放在底部

每个AEOP容器可以处理三种类型的事件：（1）由“事件模型”模块标识的正常操作事件； （2）来自受控层次结构中较高级别的容器发送的内部更改的事件； 或（3）来自受控层次结构中较低容器的外部更改发出的事件。

除了主要生命周期及其关联的事件模型外，对于正常操作，还有一些业务实体可以被视为“静态”。 例如，在正常操作期间，预计商品或实际位置的价格不会改变。 它们被称为“静态模型”的模块捕获。 这并不意味着它们是固定的，并且与业务动态无关。 仅通过变更管理过程，才能使用内部和外部变更来更新静态模型。

AEOP控制的层次结构可用于设置容器模式：初始化，操作和关闭。 仅当容器处于操作模式时，才能处理事件。

在AEOP体系结构中，涉及三个相关元素：1）组件和控件的高级技术结构； 2）操作平台； 3）事件处理平台。

高级AEOP技术代表了整个应用程序，可以通过自适应系统进行识别。 它具有三个主要平台，其中每个平台都可以通过自适应子系统进行标识，上方的平台扮演管理角色，而下方的平台扮演环境角色。 每个平台都有自己定义的事件模型，该模型实现自己的功能以及与其他两个程序的交互。 在每个平台上，我们都找到一个存储库，该存储库可以是缓存数据库或更传统的关系数据库。

与外部系统的集成遵循相同的事件模型。 根据外部系统的类型，可以使用两种集成策略。 如果AEOP仅可以访问持久性存储库，则它可以使用正在进行的计划任务来查找数据库记录中的数据更改。 第二种方法依赖于API调用，并且当外部系统实现可以更改为在主业务实体的状态更改时进行调用时可以实现。

图5.高级AEOP多壳容器架构

这三个平台均围绕特定的生命周期元素构建。 运营平台围绕主要业务实体生命周期构建，系统运行时平台围绕用户会话构建，而安装/持久平台围绕版本控制生命周期构建。

尽管必须仅根据严格的事件模型蓝图来处理数据，但是有权访问系统并具有正确凭据的任何人都可以查看相同的数据。 但是，针对平台用户的数据查看器实用程序很少。 例如，系统运行时平台具有查看器，该查看器监视用户和分布式系统的运行时错误。 当各种子系统出现故障时，可以使用相同的工具来重新启动它们。

AEOP技术级别还实现了完整的初始化过程。 启动后，应用程序必须经过三个步骤，用户才能运行第一个任务：

• 启动应用程序 –系统管理员启动主应用程序。 通过启动像Tomcat这样的容器（J2EE servlet容器）和Axis（Web服务平台）来完成此操作。 应用程序可以将Spring框架加载到轻量级容器中，并使用Spring bean配置文件加载初始的“启动”模块。 “启动”模块将初始化“系统”模块。 该模块负责主应用程序的硬编码配置，并且可能包括到现有远程数据源的硬线链接，用于读取已部署的远程应用程序版本的Web服务端点，测试和打开与各种分布式系统的连接性的方式以及与数据相关的功能正常运行，性能和日志记录。 生成数据的主要用户是开发人员和技术支持。
• 安装/启动/永久/还原“系统”模块 -此模块实现所有与系统相关的功能，包括检查系统配置。 它的主要功能是将包含所有资源（远程数据源，用户，版本，集群中的服务器，连接，安全数据等）及其状态的系统映射加载到缓存中。 这是提供应用程序监视器的模块。 该模块的主要用户是技术支持。 这些步骤是：
  • 在此阶段，第一步是验证哪些分布式系统已启动并正在运行。 如果远程系统未处于活动状态，则计划将操作更改发送到操作系统，这将使依赖于它们的那些任务无效。 它还会将其缓存的数据标记为“陈旧”。 它将向应用程序仪表板发送信号并将其记录下来。
  • 完成后，它将验证那些远程数据位置的软件版本是否正确。 如果不是，它将禁用它们，并将与记录操作一起向应用仪表板发送信号。
  • 最后一步是检查那些远程分布式系统的数据定义。 如果它们已更改，则将执行与上一个活动相同的步骤
• 操作上启动主应用程序 –这是用户访问应用程序之前的最后一步。 它将操作上下文以及所有活动用户实例及其状态加载到缓存中。 操作上下文的一部分是指向分布式系统数据及其状态以及分布式系统操作上下文的指针。 该模块的主要用户是业务用户。

图6.三个主要容器的状态由系统的受控层次结构确定

初始化之后，将使用相同的框架来控制主应用程序的操作就绪状态。 有以下三种方案：

• 用户运行/创建查询时会生成错误-这是最常见的情况。 当操作模型子平台检测到错误时，将系统设置为“操作错误”模式，将消息发送到系统模型子平台，并显示新状态/将警报发送给技术人员。监视主要应用程序的支持团队。 相同的错误将发送到install / persist / recovery model子平台进行日志记录（此信息适用于开发团队）。 用户还将收到一条消息，该消息显示当前事件的状态以及可用选项。 一种选择是从上一步恢复实例。 这是可能的，因为整个操作都是围绕事件模型构建的，该模型保证了先前事件已成功完成。
• 管理员或数据源管理员对操作环境进行更改–在这种情况下，主应用程序处于“操作更改”模式的特殊状态。 将通知所有当前用户，这些用户正在运行受更改影响的任务。 它们有两个选择：要么运行一个过程来更新实例，要么干脆忽略它。
• 生成环境系统错误–在这种情况下，将通知监视IT环境的技术支持团队。 这可以通过使用监视集群或J2EE / NET应用程序服务器的工具来完成。 在这种情况下，主应用程序将尝试记录最新活动或调试应用程序服务器堆栈。

接下来要详细介绍的是AEOP操作平台。 事件模型是围绕业务实体的类型构建的。 每个产品类型的服务都有自己的生命周期，并由自己的事件蓝图表示。 事件蓝图是一组定义良好的有序事件。 一组更改类型与每个蓝图相关联。 内部或外部事件可以是正常操作的一部分，也可以代表不同类型的更改。 每个事件都必须清楚地标记，因为它需要由某个模块处理。 这种方法不同于事件驱动的架构方法，后者将事件视为“发生在企业内部或外部的重要事件”。 同样，EDA专注于事件结构，就像它需要具有标题，正文，时间戳等一样。AEOP没有任何这些限制，因为整个结构由其类型决定。

图7. AEOP的“信息组装线”围绕业务运营容器构建

运营平台自动实现三种基本类型的用户之间的交互：工人（他们支持正常运营），经理（他们触发内部运营变更）和外部业务方（即客户）。

最后要详细描述的平台是AEOP事件处理。 一个多世纪以来，“装配线”概念如此受欢迎的主要原因之一是因为每个步骤都可以很容易地与其他步骤分离。 不仅如此，工人在每个“工位”都将遵循相同的步骤，无论他需要执行什么工作。 当产品的主要实例到达“工作站”时，它就像一个空的“外壳”，需要用各种零件“填充”。 这些零件有两种类型：要在当前“工位”组装的特定零件和仅有助于组装过程的零件，我们称为“套件”。 例如，“套件”可以是有助于组装过程的胶水。 这三个要组装的元素都有自己的仓库，有自己的“到达”时间，并且在组装过程中遵循特定的逻辑。 组装后，该产品实例将不会发生任何变化，直到下一个“组装工位”。

“信息组装线”与实际组装线的概念非常相似。 在事件处理过程中，我们会遇到相同类型的信息：代表主要业务实体的实例的“外壳”，特定于事件的信息和需要添加的实例，以及仅特定于事件的信息。需要添加称为“套件”。 “成套”信息类型的主要特征是它是有限的，对于同一事件它可以多次使用，并且您可以在事件处理过程中“用完”它，类似于在组装过程中用来固定零件的“胶水”。 订单处理中“套件”信息的一个示例是企业给予客户的信用额度。 他可能决定使用全部可用信用来购买产品，或者他可能决定仅使用其中的一部分，他可能会使用它来支付多次购买的费用，并且他可能会在一次购买中间“用光”该产品采购。

另一个相似之处是“仓库概念”。 在检索信息时，要“组合”的信息具有某些规则。 例如，当客户用信用卡付款时，将从银行实时检索帐户信息。 存储在任何其他数据“仓库”中的值不是有效值。

在事件处理期间，可以通过事件“位置”层和事件“调度器”层来完成从各种系统中获取信息的过程。 只有完成了这两个步骤，才能按照逻辑“组装”“信息”。 “位置”层使用以消息为中心的组件，“计划”层使用以日程表为中心的组件，而“逻辑”层使用BPM /业务规则引擎作为主要组件。 顺序总是相同的。

在体系结构/设计中，调度程序的作用不仅限于安排不同的任务。 另一个作用是帮助设计多线程体系结构，其中对状态更改的控制在事件级别完成。 这可以通过将调度程序用作事件模块来完成，该模块将状态更改过程中可能分叉的进程转换为单独的“ swimlane”。 这样，我们可以在事件级别实现状态更改逻辑，就像调度程序处理每个事件子任务一样。 这样，过程“ swimlane”中的故障将使整个系统处于可以清楚识别的状态。

图8. AEOP事件处理容器–位置，时间表和逻辑

通过结合所有这三个要素，可以将“信息组装线”构建为任何企业系统通用的，而不论其字段或规模如何。 这类似于从汽车制造开始的装配线扩展到所有其他制造业的方式。

AEOP事件处理容器具有两个用于内部和外部更改的更改管理模块。 当事件被识别为变更时，决策表将正确的变更类型链接到特定事件。 该体系结构被设计为一组插件，这些插件根据现有实例的状态被调用。 例如，在订单处理中，将有不同的方式来处理预付款和未付款订单的价格更改。

结论–数天即可完成架构，数周即可完成设计，数月即可完成实施—通过简便的方法为DBA基础架构构建集成服务器端

AEOP方法具有许多优点。 主要优点是它可以标准化服务器端应用程序的体系结构，这是当前IT所缺少的。 它将整个服务器端实现转换为事件插件代码编写，类似于Microsoft Windows应用程序的编写方式。

图9.自适应运营平台支持动态，具有受控层次结构，分布式且有状态的业务

使用AEOP实施应用程序的三个步骤包括：

1. 获取对象流并更改类型
2. 获取三个平台的组件
3. 为每个事件处理构建五个模型

SOA之类的技术和体系结构概念在此体系结构中仅扮演次要角色。 BPM引擎，调度程序，消息传递等组件在此​​体系结构中扮演着明确的角色，但是对设计的影响很小。 在某种程度上，这类似于飞机各部分在平面设计中所扮演的角色。 电动机，电线，螺母和螺栓对于整个平面功能至关重要，但对于设计过程却不是必需的。

因为该方法不依赖于业务，所以可以构建类似于Microsoft Visual C ++向导或Visual Basic的工具，这些工具将进一步自动化实现过程。 这不仅提高了开发团队的工作效率，而且还帮助开发人员将精力集中在实现的真正方面，而不是与错误的体系结构“打架”。

即将推出第三部分-案例研究和副业
本文将在第三部分继续进行，其中包括一个实际实现的案例研究和自适应系统新理论的简短摘要。

翻译自: https://www.infoq.com/articles/beyond-soa-dba-part-2/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

soa框架