第二部分：动态业务应用构建实践——两个自适应系统的故事
生产力提高是生活水平提高的基本组成。美国的经验表明，长期的生产力强劲增长表现为伴随组织结构和企业资金安排变化的技术革新，以及人力资本的投
入。但是，支撑这些生产力增长的决定因素的是一个更基本的因素：社会对其自身进行重大转变的意志，以及对技术进步和随那个进步而来的经济机会将使人们改善
其生活的信心。
–Roger W. Ferguson Jr.和William L. Wascher，美国经济学会在政府中做的经济专题演讲：过去生产力大爆炸的教训，《经济学展望杂志》，2004年春季18卷，第2期
“一旦着手自动化这些[企业]流程，技术实现大约占10%，其余90%都是变更和流程管理”
–Mark Evans，Tesoro Petroleum的CIO，管理自动化，2004年3月
第一部分总结
在本文的第一部分，
我们介绍了一种构建新型IT系统的企业架构，我们称之为动态业务架构（DBA）。这些DBA非常适合支持具有动态操作（包含最新业务的一个分类）的企业。
第一部分还指出，用例是当前系统架构和设计的基本输入，并描述了依赖通过它收集的需求对当前企业架构方法的种种制约。这一新提出的新框架使用企业事件模型
作为起点，并将企业视为一个具有清晰信息架构的自适应系统。以新的自适应系统和信息理论为基础，在基础层级，该框架同时捕捉企业流程和业务变更。用例仅在
设计过程的后期作为一种需求细化方法被引入。这种框架优先的方式受到了传统工程方法学的启发，但针对像企业这样的自适应系统进行了修改。
介绍
告别手工作坊并向软件工程加入正确工程技术的时候到了。这是将复杂软件应用（尤其是在企业领域中）构建成高度可靠、易于改变和方便调试的公共标准的
唯一方法。选择并执行正确的系统架构是使这种方法发挥作用的最重要因素。我们建议的解决方案使得围绕唯一一个系统架构进行标准化（不考虑软件应用）并避免
成本高昂的重新构架成为可能。
正如本文第一部分提到的，构架软件应用和设计其它工程产品之间有一个根本性的区别。因为软件是和信息打交道，而信息是变更的“载体”，那么必须在最
基础的级别将变更构建到信息架构之中。此外，业务操作变更的方式和技术团体将变更引入系统的方式走得是完全不同的路径。它们各自都是对变更反应不同并具有
不同操作的组织（一个是业务和一个是技术）。在构架过程中，可以把这两个组织作为两个不同的自适应系统对待。这正是我们选择“两个自适应系统的故事”作为
本文第二部分副标题的原因。
在设计企业应用的过程中涉及两个自适应系统。
本文第一部分提到，能成功应对构建DBA复杂性的唯一方法是使用架构先行的方法论。几个世纪以来，工程师们一直在使用这种方法论——但总是设计“静
态”架构。一旦要应用变更，系统极可能必须先停止工作再进行修改。例如，要改变由装配线组装的产品必须先停止装配线，然后应用变更，最后重新启动装配线。
当今为业务构建IT系统的软件工程师们很可能就是遵循的同样套路。当业务变化提出了修改应用的需求时，它很可能就触发了一个成本高昂的升级。开发者
必须从头开始一个新业务需求，并且旧的设计常常经受大量的重新构架。这种升级周期可能需要几个月。如果企业应用是由外部开发商按照自己的日程构建的，那么
整个过程可能耗时更长而且结果可能达不到业务预期。Mark Evans说得好，超过90%的努力只直接和应用变更相关。
籍由新的自适应系统理论和它们信息架构（参见局外人观点）的帮助，我们建议的企业应用设计解决方案引入了两个互补但唯一的框架。这两个框架让我们可
以有效地处理和协调业务操作和技术团体操作中的变更。对设计过程而言，业务操作和技术团体操作可以被视为两个截然不同的自适应系统，它们各自都有自己的需
求。
业务操作可由基础动态业务平台的通用概念来表示。根据自适应系统理论，任何企业业务功能均有3类基础流程。主流程类型支持正常操作，而其他两个则负
责引入变化：内部决策制订流程处理管理和其他企业变更决策；业务环境变更流程处理客户决策和变更的其他外部来源。因此，我们提出的业务流程框架（基本动态
业务平台）是围绕着业务操作或价值循环构建起来的，它包含的两类变更由两个不同的变更管理平台来处理。从信息处理观点来看，实现这些操作的系统可以比作围
绕事件模型构建的“信息装配线”（参见第一部分）。企业的业务操作可以按照类似源自丰田精益制造最佳实践的价值流程图（Value Stream
Mapping）方法论的方法来识别。结果是，生命周期/事件模型成为系统设计和架构的主要驱动力，不可靠的用例集合不再是系统架构的主要输入。
技术操作有其自身的挑战和独特的动态性。技术操作的主要目标是如何使不同的团队在引入变更的过程中能最大限度的合作。基础动态业务应用是具有两类流程的自适应系统：操作和操作变更。这两个流程将技术支持（操作）和技术开发（操作变更）与业务用户联系在了一起。
图1. 构建和维护基础业务动态平台既需要业务流程框架，也需要业务系统变更管理框架。
两个框架必须合并到一个既考虑技术团队操作，又考虑业务用户活动的独特系统设计中。这个系统是围绕服务器端架构设计的。虽然仿效了它们的结构和控制层次，但是这是为不同类型用户合作提供支持的唯一方法。
设计服务器端基础设施的复杂性比桌面应用的要高几个数量级
每个企业软件的设计者都认识到，实现完整的企业客户/服务器应用要比构建桌面应用更复杂。对于桌面应用，接口是围绕一个角色、一个主要任务和一个清
晰接口构建的，整个应用运行在单独一台机器之上。接口可以通过一系列函数实现来构建。对于服务器端应用，实现要复杂得多。复杂性的来源之一就是，服务器端
应用要实现包括管理员在内的多个角色。管理员不可能扮演一个被动角色，他需要一个可以在必要时改变操作参数的界面。此外，为了保证正常使用，技术支持必须
对应用进行监测。
要更好地理解实现桌面应用和实现客户/服务器应用之间的区别，我们可以看看将一个桌面应用变成客户/服务器应用需要经过哪些步骤。假设我们需要使用
作为服务器端应用实现的MS
Word写信。首先，你需要一个技术支持负责设置字体、页面和所有其他设置。每当你需要不同设置的时候，你都必须请求这个技术支持完成变更。在你写信时，
管理员必须审定字体，信头等等。一旦完成这些，同一管理员可能还需在它发送前对其进行审核。这个例子虽然看起来简单，但是它可以帮助我们理解当试图将桌面
开发过程中获得的知识外推到客户/服务器应用时，软件架构师面临的挑战。
事实上，当多个用户在使用同一个应用时（业务上或技术上），它需要完全不同的方法。架构必须是分布式（用户可能在不同地点、使用不同机器）、有状态
（状态不再由硬编码到应用中的下一个窗口来定义）、动态性（管理员或外部用户可能需要一个业务实体能在运行时被改变，类似经理可能要求一个产品或服务不能
再以相同价格出售或客户可能要求订单改变的方式）和层次性（所有组织有一个控制层级，这样不同用户就能对流程进行不同控制）的任务或流程提供支持。所有这
些新性质都必须被内嵌至应用的基础之中，否则它就必须在每次进行变更时被重写。
但是这并非设计服务器端应用的唯一区别。当桌面应用崩溃时，用户只需重启它就行了。因为它实现的是简单任务，重新做一遍即可，即便丢失了大部分数
据。用户并不需要一个专门的技术团队来帮助他运行应用程序。对于客户/服务器应用而言，情况就完全不一样了。由于多个用户同时工作，一旦出现问题，只有具
有技术知识和有权使用工具监测应用的技术支持团队能够制定如何使应用恢复正常操作的决策。并且技术团队自己的操作蓝图完全不同于业务操作蓝图。技术团队有
自己的流程控制层次、自己的分布式环境、自己实现变更的方法和自己的状态。
结果是，构架一个能在企业级运行的客户/服务器应用要比构架一个桌面应用复杂几个数量级。服务器端的主要复杂度源于它必须支持两个自适应系统，一个
是技术团体，另一个是业务团队，他们各自又都有自己的操作和控制层次。在构架同时支持管理和技术支持两个自适应系统的应用时，需要遵守应用于自适应系统及
其相关信息的法则。
在构架这类复杂系统的过程中，如果有一个理想的架构，那么就用不着在每次业务或技术引入变更时重新返工了。理想情形是拥有一个标准组件集合，它具有
用事件模型实现的定义良好的行为。在不同控制级别实现的事件模型将这些组件链接到一个控制层次中。在桌面中，一组自身具有事件模型的定义良好的组件由一个
清晰的控制层级链接到了一起。服务器端就要落后得多了。使用中的J2EE、.NET或其它现存专有架构都缺少为分布式、动态性、有状态和层次性环境提供支
持的基本组件。由于Web标准是无状态、扁平、静态和只针对单服务器的，它们对单个自适应系统都无法提供很大帮助，更别提两个了。
根据自适应系统及其关联信息的法则，一个控制层次总是符合3个模式：
- 初始化过程总是相同的自顶向下顺序
- 层级之间的信息传播总是遵照确定的规则：命令流自顶向下，反馈流自底向上
- 每个层级有其自身的正常操作，它们在收到一个反馈或命令之前不会改变。处理命令或反馈总是需要变更管理的能力。并且由于有两类交互——命令和反馈——因而需要两类不同的变更管理
我们将展示如何使用标准组件（它们一起被链接在一个动态、有状态且分布式的控制层次中）为服务器端应用实现一个标准架构。但是首先，我们将先给出另一个任何计算机使用者都熟悉的以事件为中心的平台。
微软将它的未来建立在了针对GUI的一系列组件和一个静态事件模型之上
微软之所以如此成功有许多原因，但是其中一点非常突出。他们不顾来自Apple和IBM的诸多批评和竞争，将Windows操作系统构建成了一个桌
面标准。一种解释可能是，微软是第一家不仅提供与Apple利用Mac完成的工作类似的操作环境，而且还拥有一组最方便的OS和GUI组件的公司。这些组
件被实现成了可供调用的API。利用这个组件模型，包括微软在内的软件公司就能够构建数据库、办公应用和类似Visual
Basic这样的开发工具。这些应用都能利用被构建成结构体和控件的Windows内置层次事件模型。
在开发Windows时，微软拥有的优势在于，大多数OS和GUI的主要组件，连同它们的事件模型一起，要么已经是现成的，要么就是可以凭直觉方便
地构建。对于任何桌面应用来说，控制层次看起来异乎寻常的简单。在GUI栈的顶端是扮演其余GUI组件容器的各个窗口。打开窗口，内嵌的控件也就自动地被
初始化。关闭窗口，每个组件也跟着一起关闭。用API捕获那些事件以及Windows应用的开发都和一个插件架构十分相称。
图2. 微软Windows控制层次模型——一个用户、一个应用、一个位置、一组静态功能
这些API的实现就是Windows操作系统自身。它是控制初始化过程的那个层级，也是最终必须处理错误而不是崩溃或丢失数据的层级。在服务器端，
组件、它们的事件和控制层次被一个需求搞复杂了，那就是为有状态、动态、分布式和层次性任务提供本地支持。这正是自适应企业操作平台（AEOP）的主要目
标。
围绕动态结构和控制进行设计，AEOP提高了生产力
一些年前，IBM招募了上千名企业架构师决心降低它们各垂直行业的客户化解决方案个数。一年多之后，他们将它们的数目由超过60个降低到了不到20
个。付出巨大的努力和不算优秀的结果显示了问题的巨大。尽管投入了庞大的资源，但IBM确实难以创建能对他们客户都适用的通用解决方案，不管他们在行业的
深度和公司大小。一种可能令他们努力复杂化的一件事是，他们是以一组不完善的遗留解决方案开始的。
我们的目标是相同的：创建一个几乎普遍适用于所有行业的通用解决方案。如果有从一个新鲜想法开始的自由，我们一开始就会关注那些我们认为最重要的基
本原则。大多数企业架构虽然依赖现有技术、组件或象SOA这样的趋势，但是AEOP架构要优于它们。它从一开始就认识到技术在企业中扮演的根本角色就是提
高生产力。这个角色对所有技术解决方案（不论它是否是IT）都是有效的。在IT情形下，由于业务的动态性和存在于企业系统各用户之间的复杂关系，架构需要
围绕企业流程的结构、控制和动态性来构建。
这种方法还提供了一种手段来解决由Nicholas Carr的《IT没什么大不了的（IT doesn't
matter）》产生的讨论，该文发表于2003年5月的《哈佛商业评论》。询问IT是否是业务相关的，就好像询问装配线是否是业务相关的一样。它不仅对
诸如通用或丰田这样的公司至关重要，而且是任何一家制造业公司的一部分，包括象Intel这样的高科技行业明星。装配线的影响力对那些定制产品或服务无处
不在的行业（如食品或保健领域）来说要小得多。虽然在象通用这样的公司看来装配线是重要的，但是它不过是高生产力的促成因素。相同的事实也适用于IT，它
可能对那些依赖信息处理运营的公司来说是一回事，但是对其他公司可能就无关紧要了。IT唯一的不同之处在于，它远没有装配线技术成熟。
要分析IT如何能提高生产力，就要了解那些决定了技术如何被交付和使用的基本商业机制。我们必须看看信息处理的基本角色，并询问驱动企业运营的核心
信息元素是什么。在工程领域，这一过程得到了相当好的理解，可以从几个例子看出这一点。当一个工程师开始设计一架飞机时，他从来不会把飞机看作一个诸如螺
母、螺钉、电线、连接器、泵、电动发动机、杠杆、面板等这样零件的集合。他查看连接它们的方式和它们在交付功能过程中扮演的角色。一架飞机的结构是围绕机
翼、引擎、座舱和主机身建造的，并采用一种能够最大化不同参与者间交互的控制层级。建筑师在设计一栋房子时也是这样。在建筑师清楚房中需要的卧室数目和生
活的家庭人员个数之前，待安装的空调、器具或电线型号都不重要。
在当今的方法中，企业软件大多都是围绕技术组件和标准被构架/设计的。需求是一种评估生产力增长或企业软件结构、控制和动态性的一种补救方法。事实
上，高级别架构推荐只以表现层、业务层和持久层为中心。当前还没有一种架构方法提供一个解决方案来支持现实中的动态、分布式、有状态和层次的业务流程架
构。
为了更好地类比，不妨让我们看看工程师是如何设计装配线的。首先，它们以易于维护和维修为设计目标。这就是为什么装配线架构和设计是围绕可交换性、
模块化和标准化组件建造的原因。由于装配线不会动态变化，那么第二个标准就是要易于针对新模型重新进行配置。这正是机器人在装配线上如此流行的原因。不管
任务有多复杂，都可以方便地针对范围广泛的当前和将来任务重新编程。只有在这两个标准被满足之后，设计工程师才会着手努力最优化每个特殊的任务。
为了构架/设计一个通用的AEOP，我们识别出了3个需要在设计中被解决的基本因素，它们对生产力的提高有重大影响。它们几乎对所有企业都是相同的，不论这些企业涉及的领域或生产规模：
1）通过为技术支持、开发人员和业务用户之间的合作操作提供支持，提高技术团队操作的生产力
对整个架构影响最大的是不同技术团队和业务用户之间的关系以及需求变更引入的方式。由于IT团队是在应用上花费时间最多的一个团队，提高它的生产力应该是架构的首要任务。
在这一背景下，技术团队正常操作的结构与控制并不复杂。业务用户打开一个触发业务事件的应用。这些事件使应用处理信息。技术支持团队监测应用。应用虽然处于生产环境，但是开发团队常常要计划下次升级并实现新的需求变更。
整个处理的控制遵循相同的层次架构：在控制金字塔的顶端是开发者团队。因为是他们实现未来的功能，他们对实现拥有所有控制权。接下来是技术支持团
队，因为他们可以停止和重启服务器或改变部分系统配置。对应用拥有最小控制权的团队包括业务用户、经理或工人。他们对应用脚本只能唯命是从。
由于企业是动态的，功能变更的请求可能出现得非常早，甚至在应用安装和运转之前。事实上，需求只有在下次开会的时候才生效。结果，在我们查看什么对
生产力有驱动作用的时候就会发现，如何将变更转换为代码是一个重要因素。在AEOP中，当发生变更时，你会发现总是存在同样的用户组。开发团队是接受变更
请求的团队，监测应用的团队安装它并接受配置来支持它，接着是业务团队接受培训来使用新功能。
作为这个结构和控制层级的结果，企业应用的顶层总是围绕3个平台构建的：一个为开发团队实现功能、一个为技术支持团队实施它和一个支持业务用户。它们每个都有自己的主生命周期和驱动设计的事件模型。
因为AEOP主要是支持技术团队操作的动态性，所以这种“3个平台”的结构、它们的组件和事件模型都是围绕变更请求的生命周期而构建的。
2）通过为3类基本业务用户之间的合作事件提供支持，提高业务操作的生产力
不同类型基本业务用户间合作是生产力的第二大影响因素。在任何企业流程中最多有3类基本用户，分别代表了自适应系统的3个方面：代表操作的工人、代
表决策制定流程的经理和代表经济环境（它使价值循环成为闭环）的客户。价值循环的其他业务参与者，如供应商和政府代理，都扮演次要角色，并且它们的流程都
可以使用这3种基本流程（操作、管理和环境）中的一个标识。
业务是动态的。业务中最大的生产力杠杆之一是变更引入流程的效率。业务中有两类变更：经理引入的内部变更和消费者引入的外部变更。这些变更在某个时
间作为更新被引入到企业应用中。一个有效的架构/设计必须解决这种动态性。一种理想的企业应用架构能够只需最少的代码和配置改变就能适应大多数变更。由于
业务日益依赖支持它们运营的技术，一个快速而有效的更新应用方法对整个生产力十分重要。
基于这一点，AEOP针对业务操作中的高级合作只定义了3类企业架构：
- 静态架构：纯操作性的——目前所有的企业软件都属于此类。除了最简单的配置变更之外，完成业务流程变更通常都至少要求IT部门停止应用的运转。静态架构的行为类似于汽车制造商在引入新模型时停止装配线。
- 仅
内部（内部决策）驱动的动态架构：提供了对动态操作的支持并实现了经理和工人之间的关系。在这种情况下，在正常操作期间，以及在变更动态应用于当前所有实
例时，经理决策是被自动考虑到的。因为经理和工人在不同的时间线上操作，他们需要处理内部决策的变更管理平台来嫁接他们的活动。客户在其中不扮演指导角色
的那些流程都属于这个类别。
- 扩展的（内部和外部决策）动态架构：提供了对动态操作的支持并使全部3类基本用户（工人、经理
和客户）之间的合作自动化。这是最复杂的业务操作架构。它有两个不同的变更管理平台，一个针对正常操作应用于内部决策的方式，另一个针对那些希望改变订单
在正常操作时的执行方式的客户。
注意，在任何企业中，不论什么类型的业务流程，它总是与管理“命令和控制”的结构和客户反馈“相连”的。结果，不论应用的目标业务流程是什么，每个应用都属于“全动态类别”。
操作平台架构的动态性是以业务变更生命周期为中心的。它们受内部决策（经理制定内部决策）和外部变更（客户可以决定给进行中的已有订单和服务施加变化）驱动。
3）通过提供在生命周期/事件级别完全解耦的架构，提高开发团队的生产力
前一个生产力因素跟业务变更对架构/设计的影响息息相关。理想情况下，架构/设计中的业务变更可以通过变更管理模块的界面来完成。该界面使经理和客户有权自动向工作中所有操作应用变更。
有时，变更需要开发团队实现新功能。在实现新功能时，应用的架构/设计应该支持高生产力。
当前方法是将一系列组件归到有数据库访问权限的“业务层”上。这种设计有一个基本错误。在这一设计中的数据库很可能是关系数据库，它保存层次性信息或有状态信息的能力很差。它们很可能依赖缓存机制，它们需要消耗惊人的计算资源，在后台持续更新大量数据。
无论怎样，企业中的所有业务流程都会链接到主业务实体（一个产品或一个服务）。对于一个链接到主业务实体的业务流程来说，现有历史是最重要的方面。
即使对最简单的交易来说也是如此。去一个商店买东西的前提是，你的金融资源将为你提供购买产品所需的足够金融“资源”，而且商店有“待售”的产品。一个实
体的历史由最终描述它整个生命周期的事件组成。由于可能改变实体状态的事件可以在业务结构内的任何位置和多个控制级别被触发，围绕这个业务实体动态构建的
AEOP架构必须是有状态、层次性和分布式的。
由于生命周期围绕事件而构建，围绕它们可以构建整个AEOP。任何事件实现都可以按照同一种通用方法完成：整个生命周期可以被认为是反映主业务实体
转换信息的“装配线”。因此，可以用相同的结构来实现事件，并装配：1）从各需要位置（分布式）检索出来的信息元素；2）在某一时刻瞬间存在的（如，检索
一张信用卡交易的账户信息必须以实时方式完成）信息元素；3）可由一定的业务流程实现的信息元素；4）已经应用了一定的业务规则的信息元素。
AEOP的另一个优势是能够围绕同一个事件模型设计两类变更管理。最终，这个操作平台的实现可以在事件级别解耦。操作平台可以作为一个插件API基础设施来构建，就像Windows API是围绕着桌面集成事件模型构建的一样。
需要注意的是，文献中记载的EDA（事件驱动架构）跟AEOP事件模型是不一样的。EDA是围绕非结构化事件流构建的，而AEOP是围绕由一组生命周期模板链接在一起的结构化事件流构建的。
图3. AEOP控制层次模型——按变更类型分组的多个用户、多个客户端应用、多个分布地点、多个静态功能
组件及其事件的AEOP层级包含5级：
- OS级：在这里可以找到所有OS组件，如内核、文件系统、网络和I/O。OS可能还有GUI组件，运行监测各种应用及其活动的图形化工具时会用到它们。
- 技
术级：在这里可以找到所有传统的基于服务器的组件，如应用服务器、BPM引擎、业务规则引擎、数据库。这儿还有实现了Web和Web服务、消息传递等标准
的组件。它们或多或少扮演了和飞机设计中标准零部件相同的角色。螺母、螺钉、电动发动机、液压泵、电线、连接器、座椅、电子面板、马达对许多其他工业设备
都是通用的，不只限于飞机。可是它们在尽可能简化和标准化设计的过程中扮演了一个关键角色。
- AEOP技术操作级：这是拥有
特定于AEOP组件的顶级级别。这里有3种组件——安装/启动/持久化/恢复平台、系统平台和操作平台。它们分别代表了合作运行客户/服务器应用的3个小
组：业务用户团队、技术支持团队和开发团队。每个组件实现了特定的事件，如技术支持团队能监测错误和重启应用。对于那些需要和外部系统合作的应用，还存在
被称为外部系统监督者平台的第4类组件。这个组件管理与外部系统交互的初始化、正常操作和错误翻译。
- AEOP业务操作级：它是业务实现的顶级级别，在操作平台之下的一级。它也包含了3个主要组件：正常操作、内部决策管理变更和外部环境交互（即客户决策）管理变更。这里包括许多其他组件，如外部系统操作翻译器、系统Map、许可证管理器等。
- AEOP事件处理级：这是实现的插件级。在这一级实现了被激活业务流程的整个正常操作。由于每个功能被分解成了事件级的函数，整个架构围绕事件模型被解耦了。这可以包括操作错误、操作变更，以及甚至安全访问。
显然，在这个AEOP的简短描述中还有很多组件和事件没有被覆盖到。在下一节我们将围绕这3个组件进一步分析其细节。
AEOP事件模型和事件驱动架构（EDA）之间存在着差异。EDA是一种提倡产生事件、检测事件、消费事件、对事件做出反应的软件架构模式（来自维
基百科）。EDA缺失的是如何捕捉业务流程的结构和控制。此外，AEOP区别了3类事件，一个针对正常操作、一个驱动内部变更和一个针对外部变更。它们负
责不同的待处理模块，而EDA则使用相同的方法处理所有模块。AEOP使用生命周期在一个分布式、层次、有状态和动态的结构中将事件分组。
AEOP中的信息“装配线”是围绕动态生命周期模式的多联装（Multi-shell）容器构建的
所有现代软件平台都是围绕某种形式的容器模式构建的。AEOP也不例外。基于J2EE的应用服务器甚至有两类容器：Servlet和EJB。操作系
统可被视为是一种应用程序的容器。容器的概念和“计算机资源是有限的”这一思想有一定联系。容器在AEOP架构中的使用是不同的：
- 容器创建和管理的对象是业务实体资源的直接表示。例如，AEOP操作容器管理整个订单生命周期，不仅仅是反映现有计算机资源的对象。
- 容器可以区分作为正常事件序列一部分、改变受管资源状态的调用和触发正常操作之外变更的调用。由于存在两类变更，因而每个容器都关联两类变更管理模块。为了提供比现有静态架构更好的企业动态现实支持，AEOP容器支持受管资源的动态生命周期。
- 容
器并非类似J2EE应用服务器中的单独结构。各容器按照控制层次链接在了一起。集成的事件模型驱动了系统外产生事件的接收和处理。在这种情况下，既不在最
顶端也不在最底端的容器扮演了双重角色，一个作为资源生命周期管理器，另一个作为受管理的资源。这就是给予系统容器的多联装（Multi-shell）结
构。
整个AEOP架构和实现是围绕描述容器（它管理代表真实业务实体的资源）的模式而构建的，对正常操作和变更进行了区别，是反映业务控制层级的结构的一部分。
图4. AEOP多联装（Multi-shell）容器架构将技术置于顶端，业务操作置于中间，事件处理置于底部
每个AEOP容器可能处理3类事件：（1）由“事件模型”模块标识的正常操作；（2）来自由控制层级中上层容器发出的内部变更的事件；或（3）来自由控制层级中下层容器发出的外部变更的事件。
除了主生命周期及其关联的事件模型，那里还有被认为是正常操作“静态部分”的业务实体。例如，在正常操作期间不期望改变的项目价格或物理位置。它们
是通过所谓的“静态模型”的模块捕捉到的。这并不意味着它们就是固定且隔离于业务动态之外。静态模型只有通过变更管理流程使用内部和外部变更来更新。
AEOP控制层次可被用来设置容器的模式：初始化、操作和关闭。只有处于操作模式的容器才能处理事件。
在AEOP架构中，有3个相关元素：1）组件和控制的高级别技术结构，2）操作平台，3）事件处理平台。
高级别AEOP技术代表整个应用，该应用可被认为是一个自适应系统。它有3个主要平台，并且它们各自也都可被认为是一个自适应子系统：上面的平台扮
演了管理角色，下面的平台扮演了环境角色。每个平台自己都有定义良好的、实现了自身功能的事件模型，并且它还要和其他两个进行交互。在每个平台上我们都可
以发现一个仓储，它可以是一个缓存数据库或一个较传统的关系数据库。
与外部系统的集成遵循相同的事件模型。根据外部系统类型的不同，可以使用的集成策略有两种。如果AEOP只有访问持久化仓储的权限，它可以使用始终
运行的调度任务来查看数据库记录中的数据变更。第二个方法依赖API调用，如果可以将外部系统实现改成在主业务实体变更时发起调用，那么就可以实施这个策
略。
图5. 高级别AEOP多联装（Multi-shell）容器架构
这3个平台中的每一个也都是围绕特定生命周期元素构建的。操作平台围绕主业务实体生命周期，系统运行时平台围绕用户会话，安装/持久化平台围绕版本控制生命周期。
虽然数据只能按照苛刻的事件模型蓝图来处理，但是相同的数据却可以被任何有权访问系统且有正确证书的用户访问。但是，很少有针对平台用户的数据查看
工具。例如，系统运行时平台有一个针对运行时错误的查看器，它被用来监测用户和分布式系统。这一工具也可在各子系统失效时重新启动它们。
AEOP技术级还实现了一个完整的初始化过程。启动过程中，在用户可以运行第一个任务之前，应用必须经历3个步骤：
- 启动应用：系统管理员启动主应用。这是通过启动像Tomcat（J2EE
servlet容器）以及Axis这样的容器（Web服务平台）做到的。应用可以将Spring框架加载到一个轻量级容器中，并使用Spring
bean配置文件加载初始的“启动”模块。“启动”模块初始化“系统”模块。该模块负责主应用的硬编码配置。它还可能包含对现有远程数据源的硬连接、读取
远程部署的应用版本的Web服务端点、测试方法和对各种分布式系统的开放互联性，以及提供正常操作、性能和日志相关数据的功能。产生数据的主要用户是开发
者和技术支持。
- 安装/启动/持久化/恢复 “系统”模块：这个模块实现了所有系统相关的功能，包括检查系统配置。它的主要功能是将一个包含所有资源（远程数据源、用户、版本、集群中的服务器、连接、安全数据等）及其状态的系统Map载入缓存。该模块提供了应用监视器。这个模块的主要用户是技术支持。步骤：
- 此阶段的第一个步骤是验证分布式系统上线并正在运行。如果远程系统没有激活，一个被调度的操作变更将被发送给操作系统，由它使那些依赖它们的任务无效。它还将把它们的缓存数据设为“过时”。它还将给应用仪表盘发送一个信号，并在日志中记录。
- 一旦这个工作完成，它就验证那些远程数据位置的软件版本是否正确。如果不正确，它将使它们失效，并给应用仪表盘发送一个信号和日志记录的动作。
- 最后一步是检查那些远程分布式系统的数据定义。如果它们改变了，将采取同前一活动相同的步骤。
- 启动主应用运转：这是用户可以访问应用之前的最后一个步骤。它将操作上下文，连同所有激活的用户实例和它们的状态载入缓存。操作上下文的一部分是指向分布式系统数据及其状态，以及这些分布式系统操作上下文的指针。这个模块的主要用户是业务用户。
图6. 系统控制层级确定的3个主要容器的状态
初始化之后，同一架构被用来控制主应用的操作就绪状态。它有3个场景：
- 用户运行/创建查询时产生的错误：这是最普通的场景。一旦错误被操作模型子平台检测到，系统就被设置成“操作错误”模式，一
条消息将被发送给系统模型子平台，并且待显示的新状态/警报被发送给监测主应用的技术支持团队。出于日志记录的目的（这是给开发团队的信息），同一错误将
被发送给安装/持久化/恢复模型子平台。用户也将收到一条显示当前事件状态以及可用选择的消息。一个选择是由前一步恢复实例。因为整个操作是围绕保证前一
事件被成功完成的事件模型构建而成的，这令这一选择成为可能。
- 经理或数据源管理员改变操作上下文：在这个情况下，主应用被设置成特殊的“操作变更”模式。当前受变更影响、正在运行任务的所有用户都将被通知。他们有两个选择：要么经历一个实例更新过程，要么简单地忽略。
- 产生了一个环境系统错误：在这个情况下，监测IT环境的技术支持团队会得到通知。它是通过能够监测集群或J2EE/NET应用服务器的工具做到的。此时，主应用将试图记录最近的活动或帮助调试的应用服务器堆栈信息。
接下来的细节是关于AEOP操作平台的。事件模型是围绕业务实体的类型构建的。每个产品类型的服务有其自己的生命周期，它由自己的事件蓝图表示。事
件蓝图是定义良好的有序事件集合。每个蓝图关联一组变更类型。内部或外部事件可以是正常操作的一部分，或可以代表不同类型的变更。每个事件必须被清晰地标
出，因为它是要被一定的模块处理的。这种方法不同于事件驱动的架构方法，后者将事件视为“在你的企业内部或外部发生的值得注意的东西”。它也不同于
EDA，EDA是以事件结构为中心的，比如它需要有事件头、事件体、事件时戳等。AEOP没有任何这些限制，因为整个结构是由它的类型决定的。
图7. AEOP的“信息装配线”是围绕业务操作的容器被构建的
操作平台使得3类基本用户——工人（他们支持正常操作），经理（他们触发内部操作变更）和外部业务团体（即用户）——之间的交互自动化。
最后一个要详细描述的平台是AEOP事件处理。“装配线”概念能在超过一个世纪的时间里如此流行，其中一个原因就是，每一步可以轻易地和其余的步骤
解耦。除此之外，不管他需要执行什么工作，每个“岗位”的工人都将遵循相同步骤。当一个产品的主实例到达这个“岗位”，它就像一个需要使用各种零件“填充
”的空
“壳”一样。这些零件有两类：在当前“岗位”待组装的特殊零件；对装配过程只起帮助作用的零件，我们称这些零件为“工具”。例如，一个“工具”可能是帮助
装配过程的某种胶水。这三个待组装元素有它们自己的仓库，它们有自己的“到达”时间安排，并且它们遵循特殊的装配过程逻辑。一旦组装完成，在到达下一个“
组装岗位”之前，那个零件实例不会发生任何事情。
“信息装配线”跟真实的装配线概念非常相似。在事件处理期间，我们遇到的是同类信息：代表主业务实体的“壳”，特定于一个事件和需要被增加实例的信
息，以及被称为“工具”、只特定于需要被增加事件的信息。“工具”类型信息的主要特征是，它是有限的，可以为同一事件多次使用它，并且在处理事件过程中你
可能把它“用光”，在某种程度上类似装配过程期间用来粘住零件的“胶水”。在订单处理中，“工具”信息的一个例子就是企业给客户的赊账限额。他可能一次性
使用所有可用赊账限额支付产品，或者他可能决定只使用部分，他可以使用它支付多次购买，并且在一个购买过程中他可能把它“用光”了。
另外它与“仓库概念”也很相似。“待装配”信息对何时开始检索它有明确的规则。例如，当客户用信用卡支付帐单时，账户信息是实时从银行检索出来的。保存在任何其他数据“仓库”中的值都不是一个有效的值。
处理事件期间，从各系统取信息可以通过事件“定位”层和事件“调度器”层来完成。只有在完成这两步之后，“信息”才能按照逻辑进行“装配”。“定位
”层使用一种面向消息的组件，“调度器”层使用以调度为中心的组件，“逻辑”层使用BPM/业务规则引擎作为主组件。次序总是不变的。
调度器在架构/设计中的任务不仅仅是安排不同任务的时间，它的另一个任务是帮助设计一个在事件层完成控制状态变化的多线程架构。这是通过使用调度器
作为一个事件模块做到的，它把在状态变化期间可能有并行任务的流程转换成单独的“泳道”。这样，我们就可以在事件层像调度器处理每个事件子任务那样来实现
状态变化逻辑了。这样，流程“泳道”中的失效将使整个系统处于一个清晰可辨的状态中。
图8. AEOP事件处理容器——定位、调度和逻辑
结合所有这3个元素，“信息装配线”可以被构建成对任何企业系统都是通用的，不论企业涉足的领域和规模大小。这与装配线的方法类似，起源于汽车制造业，后来扩展至所有其他制造行业。
AEOP事件处理容器针对内外部变更有两类变更管理模块。假如一个事件被标识为一个变更，决策表将把具体的变更类型和特殊事件联系起来。这个架构是
作为一组插件来设计的，它是根据现有实例的状态被调用的。例如，在订单处理中，对于预付和未付订单而言，处理价格变更的方法是不同的。
总结——数天内完成架构、数周内完成设计、数月内完成实现——构建集成的DBA服务器端基础设施的简易之道
AEOP方法有诸多优点。主要优点是它标准化了服务器端应用的架构，这正是当今IT所缺失的。它将这个服务器端实现转变成事件插件代码的编写，类似微软Windows应用的编写方式。
图9. 自适应操作平台支持动态、拥有控制层级、分布式和有状态的业务
使用AEOP实现应用的3步骤包括：
- 获取对象流和变更类型
- 获取3个平台的组件
- 构建每个事件处理的5个模型
在这个架构中，像SOA这样的技术和架构概念扮演配角。像BPM引擎、调度器、消息传递这样的组件在架构中有明确的角色，但是它们对设计的影响很
小。这类似于飞机设计中各零件扮演角色的方式。电动发动机、电线、螺母和螺钉对整个飞机的功能至关重要，但是它们对设计过程却非如此。
由于这种方法不依赖于业务，可以构建类似微软Visual C++向导或Visual Basic这样的工具进一步使实现过程自动化。这不仅提高了开发团队的生产力，而且还有助于开发者关注实现的真实方面，而不是与错误的架构“搏斗”。
即将到来的第三部分——案例研究和局外人观点
本文将在第三部分继续，它探讨一个真实实现的案例研究和新的自适应系统理论的简要总结。
查看英文原文：Beyond SOA, a New Type of Framework for Dynamic Business Applications - Part II。
转自：http://www.infoq.com/cn/articles/beyond-soa-dba-part-2