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控制的层次结构模型-许多用户，许多客户端应用程序，许多分布式位置，许多静态功能按更改类型动态分组

The AEOP hierarchy of components and their event model contains 5 levels:

OS Level—this is where all the OS components are found, like the kernel, file system, networking, and I/O. OS may have also GUI components which can be used to run graphical tools to monitor various applications and their activities.
Technology Level—this is where all traditional server-based components, like application servers, BPM engines, Business Rules Engine, Databases can be found. Also here are components that implement standards for Web and Web Services, Messaging, etc. They have the same role, more or less, standardized parts play in plane design. Nuts, bolts, electric motors, hydraulic pumps, electrical wires, connectors, chairs, electrical panels, actuators are generic to many other industrial equipments and are not specific to a plane. Nevertheless, they play a key role in simplifying and standardizing as much as possible the design.
AEOP Technical Operations Level—this is the top level that has components specific to the AEOP. There are three components—install/start/persist/restore platform, system platform, and operational platform. They represent the three groups collaborating to run a client-server application: business users team, technical support team, and developers team. Each component implements specific events like the ability of the technical support team to monitor for errors and restart the application. For applications required to work with external systems, there is the fourth type of component called External System Supervisor Platform. This component manages the initialization, normal operations, and error translation for interactions with external systems.
AEOP Business Operations Level—this is the top level for business implementation and the next level down for the operational platform. It also has three main components: normal operations, change management for internal decisions, and change management for the external environment interactions (ie customer decision). There are many additional components including operational translators for external systems, system map, licensing manager, etc.
AEOP Event Processing Level—this is the plug-in level for implementation. The entire normal operations for the enabled business process is implemented at this level. Because every functionality is broken down to functions at the event level, the entire architecture is decoupled around the event model. This can include operational errors, operational changes, and even security access.

Obviously, there are many components and events that are not covered in this short description of the AEOP. In the next section we will take three components and analyze them to the next level of detail.

There is a difference between the AEOP event model, and Event-Driven Architecture (EDA). EDA is a software architecture pattern promoting the production, detection, consumption of, and reaction to events (from Wikipedia). What EDA is missing is how to capture the structure and control of business processes. Also, the AEOP distinguishes between the three types of events, one for normal operations, one that drives internal changes, and one for external changes. They land on different modules to be processed versus EDA which uses the same approach to process all of them. The AEOP uses the lifecycle to group events in a structure that is distributed, hierarchical, stateful, and dynamic.

The “Assembly Line” for Information in the AEOP is Built Around The Multi-shell Container for Dynamic Lifecycle Pattern

All modern software platforms are built around some form of container pattern. The AEOP is no different. Application servers based on J2EE even have two types of containers, the Servlet and the EJB. Operating System can be considered a form of container for applications. The concept of containers has been associated with the idea that computer resources are limited. Containers are used differently in the AEOP architecture:

Objects created and managed by the container are a direct representation of business entity resources. For instance, an AEOP operational container manages an entire order lifecycle and not only objects that reflect existing computer resources.
A container is able to differentiate between calls that will change the state of a managed resource as part of a normal sequence of events versus calls that will trigger a change outside of normal operations. Because there are two types of changes, there will be two types of change management module associated with each container. The AEOP container supports dynamic lifecycles for managed resources to support the reality of enterprise dynamics better than existing static architectures.
A container is not a standalone structure like in J2EE application servers. Containers are linked according to the controlled hierarchy structure. The integrated event model drives how events generated outside the system are received and processed. In this case, a container that is neither at the top of the hierarchy or at the bottom plays a dual role, one as a resource lifecycle manager, and one as a managed resource. This is what gives the multi-shell structure to the system containers.

The entire AEOP architecture and implementation is built around the pattern that represents a container that manages resources representing real business entities, that makes a distinction between normal operations and changes, and is part of a structure that reflects the business controlled hierarchy.

Fig 4. The AEOP Multi-Shell Container Architecture places Technology Operations at the top, Business Operations in the middle, and Event Processing at the bottom

Each AEOP container may process three types of events: (1) normal operations events identified by the “Event Model” module; (2) events from internal changes sent by a container higher in the controlled hierarchy; or (3) events from external changes sent by a container lower in the controlled hierarchy.

Other than the main lifecycle and its associated event model, there are business entities that can be considered “static” for normal operations. For instance, prices for items or a physical location are not expected to change during normal operations. They are captured by a module called the “Static Model.” That doesn't mean that they are fixed and isolated from business dynamics. The Static Model is updated with internal and external changes only through the change management process.

The AEOP controlled hierarchy can be used to set the container mode: initialized, operational, and shutdown. Events can be processed only if the container is in operational mode.

In the AEOP architecture, there are three relavent elements: 1) the high-level technical structure of components and control, 2) the operational platform, and 3) the event processing platform.

The high level AEOP technology represents the entire application, which can be identified with an adaptive system. It has three main platforms and each one of them can be identified with an adaptive subsystem as well, with the platform above playing the management role, and the one below the environment. Each platform has its own well defined event model that implements its own functionality and also the interaction with the other two. On each platform we find a repository, which can be a cache database or a more traditional relational database.

Integration with external systems follows the same event model. There are two integration strategies that can be used based on the types of external system. If the AEOP has access only to a persistent repository, it can use an ongoing scheduled task to look for data changes into the database records. The second approach relies on API calls and can be implemented when the external system implementation can be changed to make calls when the state of main business entity changes.

Fig 5. The high-level AEOP multi-shell container architecture

Each of the three platforms is also built around specific lifecycle elements. The Operational platform is built around the main business entities lifecycle, the System Runtime platform is built around user sessions, and the Install/Persistent platform is built around the version control lifecycle.

While data must be processed only according to the strict event model blueprints, the same data can be viewed by anyone with access to the system and having the right credentials. There are, however, few data viewer utilities targeted to platform users. For instance, the System Runtime platform has a viewer that monitors the users and the distributed systems for runtime errors. The same tool can be used to restart various subsystems when they fail.

The AEOP technology level also implements a complete initialization process. When started, an application must go through three steps before a user can run the first task:

Start Application – a system admin starts the main application. This is done by starting a container like Tomcat (the J2EE servlet container) together with Axis (the Web service platform). The application could load the Spring framework into a lightweight container and use Spring bean configuration file to load the initial “Start” module. The “Start” module initializes the “System” module. This module is responsible with the hardcoded configuration for the main application and it may include hardwired links to existing remote data sources, Web service endpoints for reading deployed remote applications versions, ways to test and open connectivity to various distributed systems, functions to provide data related to normal operations, performance, and logging. The main users for data generated are developers and technical support.
Install/Start/Persistent/Restore “System” module – this module implements the all the system-related functionality, including checking on system configuration. Its main function is to load into the cache a system map with all the resources (remote data sources, users, versions, servers in the cluster, connections, security data, etc) and their status. This is the module that provides the application monitor. The main users for this module are the technical support. 这些步骤是：
- At this stage the first step is to verify which distributed systems are up and running. If a remote system is not active, an operational change is scheduled to be sent to the operational system that will invalidate those tasks dependent on them. It will also flag their cached data as “stale.” It will send a signal to app dashboard and it will log it.
- Once that is done, it verifies that the software version for those remote data locations is correct. If not it will disable them, and it will send a signal to the app dashboard, together with a logging action.
- Last step is to check the data definition for those remote distributed systems. If they have changed, the same steps as the previous activity will take place
Start the main application operationally – this is the last step before a user can access the application. It loads into the cache the operational context, together with all the active user instances and their status. Part of the operational context are pointers to distributed systems data and their status, together with the distributed systems operational context. The main users for this module are the business users.

Fig 6. Status of the three main containers are determined by the system's controlled hierarchy

After initialization, the same framework is used to control the operational readiness of the main application. There are three scenarios for this:

An error is generated when a user runs/creates a query – this is the most common scenario. When an error is detected by the operational model sub-platform, the system is set in the “operation error” mode, a message is sent to the system model sub-platform, and the new status is displayed/alerts are sent to the tech support team that monitors the main application. The same error will be sent to the install/persist/recover model sub-platform for logging (this information is for the development team). The user will receive also a message that displays the status of the current event, together with available options. One option could be to recover the instance from the previous step. This is possible because the entire operations is built around the event model that guarantees that the previous event was completed successfully.
A manager or a data source admin makes changes to the operational context – in this case the main application is put into a special state of “operational change” mode. All current users running tasks that are affected by the changes are notified. They have two options: either run through a process to update the instances or simply ignore it.
An environment system error is generated – in this case the tech support team that monitors the IT environment is notified. This is done by having tools that monitors the cluster, or the J2EE/NET application server. In this case the main application will try to log the latest activities or the debugging application server stack.

The next to detail is the AEOP operational platform. The event model is built around the types of business entities. Each service of product type has its own lifecycle represented by its own event blueprint. An event blueprint is a well defined set of ordered events. A set of types of changes is associated to each blueprint. Internal or external events can be part of the normal operations or can represent different types of changes. Each event has to be clearly labeled because it needs to be processed by a certain module. This approach is different than the Event-Driven Architecture approach that treats events as a “notable thing that happens inside or outside of your business.” Also, EDA is focused on an events structure, like it needs to have a header, a body, a timestamp, etc. The AEOP doesn't have any of these restrictions because the entire structure is determined by its type.

Fig. 7. The AEOP's “Assembly Line for Information” is built around the Container for Business Operations

The operational platform automates the interaction between the three fundamental types of users: workers (they support normal operations), managers (they trigger internal operational changes), and external business parties (ie customers).

The last platform to describe in detail is the AEOP event processing. One of the main reasons why the “assembly line” concept proved so popular for over a century was because each step could be easily decoupled from the rest. Not only this, but at each “station” a worker would follow the same steps, regardless of the work he needs to perform. When the main instance of a product arrives to the “station,” it is like an empty “shell” that needs to be “filled” with various parts. Those parts are of two types: specific parts to be assembled at the current “station” and parts that only contribute to the assembly process, parts that we call “kits.” For instance, a “kit” can be some glue that will help the assembly process. The three elements to be assembled have their own warehouse, they have their own “arrival” timing, and they follow a specific logic for the assembly process. Once assembled, nothing happens to that product instance until the next “assembly station.”

The “information assembly line” is very similar to the real assembly line concept. We encounter the same types of information during an event processing: a “shell” that represents an instance of the main business entity, the information specific to an event and instance that needs to be added, and information that is only specific to an event that needs to be added called “kit.” The main characteristic for a “kit” type of information is that it is finite, it can be used multiple times for the same event, and you may “run out” of it in the middle of an event processing, similar in a way to the “glue” used to hold parts during the assembly process. An example of “kit” information in order processing is a credit line that a business gives to a customer. He may decide to use the entire available credit to pay for the product or he may decide to use only a portion of it, he may use it to pay for multiple purchases, and he may “run out” of it in the middle of a purchase.

Another similarity is with the “warehouse concept.” Information to be “assembled” has certain rules when it comes to the way it is retrieved. For instance, when a customer pays for a purchase with a credit card, the account information is retrieved in real time from the bank. A value stored in any other data “warehouse” is not a valid one.

During the processing of an event, getting the information from various systems can be accomplished by the event “location” layer, and by the event “scheduler” layer. Only after these two steps are completed can the “information” be “assembled” by following the logic. The “location” layer uses a message-centric component, the “schedule” layer uses a schedule-centric component, and the “logic” layer uses a BPM/Business Rules engine as the main component. The order is always the same.

The scheduler role in the architecture/design goes beyond timing different tasks. The other role is to help design a multi-threaded architecture in which the control over a state change is done at the event level. This is accomplished by using the scheduler as an event module that translates processes that may fork during a state change into separate “swimlanes.” This way we can implement the state change logic at the event level in the same way a scheduler handles each event sub-task. This way, a failure in a process “swimlane” will leave the entire system in a state that can be clearly identified.

Fig. 8. The AEOP Event Processing Container – Location, Schedule, and Logic

By combining all these three elements, the “assembly line of information” can be built to be generic for any enterprise system, regardless of the field or size. This is similar to the way assembly line, that started in the car manufacturing, was extended to all other manufacturing industries.

The AEOP Event Processing Container has two change management modules for internal and external changes. When an event is identified as a change, a decision table links the correct type of change to the specific event. The architecture is designed as a set of plug-ins that are called based on the state of the existing instance. For instance, in an order process, there will be a different way to process a price change for pre-paid and unpaid orders.

Conclusion – Architecture in days, design in weeks, implementation in months—building the integrated server-side for DBA infrastructure the easy way

The AEOP approach has many advantages. The primary advantage is that it standardizes the architecture for server-side applications, something that is missing from current IT. It transforms the entire server-side implementation into event plug-in code writing, similar to the way Microsoft Windows applications are written.

Fig 9. The Adaptive Operational Platform Supports a business that is dynamic, has a controlled hierarchy, is distributed, and is stateful

The three steps to implement an application using the AEOP include:

Get the object flows and change types
Get the components for the three platforms
Build the five models for each event processing

Technologies and architecture concepts like SOA play a minor role in this architecture. Components like BPM engines, schedulers, messaging have a clear role in this architecture, however they have very little impact on the design. This is similar in a way to the role various parts play in the design of a plane. Electric motors, wires, nuts and bolts are essential to the overall plane functionality, but they are not essential to the design process.

Because the approach is not dependent on the business, tools similar to the Microsoft Visual C++ wizard or Visual Basic can be built that will automate further the implementation process. This not only increases productivity of the development team, but it also helps developers to focus on the real aspect of implementation instead of “fighting” with the wrong architecture.

Coming soon Part III -- Case study and sideline
The article will continue in Part III with a case study of a real implementation and a short summary of the new theory of adaptive systems.

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