超越SOA：动态业务应用的新企业应用框架.docVIP

超越SOA：动态业务应用的新企业应用框架 作者 Vasile Buciuman-Coman, Michael Chervenic译者 胡键 发布于 2008年4月23日 下午10时21分一部分——即使拥有全部需求和最佳设计，你的架构仍然很可能失败，原因在于…… 目前的管理学校，教育培养的是公司经营者。设计公司几乎没有引起重视……几乎从来没有任何人为了取得计划的增长和稳定性，有意识和有思想地设计一个组织。 Jay W. Forrester，设计未来（1998）介绍 在一篇名为《动态业务应用势在必行（The Dynamic Business Applications Imperative）》的论文中，Forrester的高级分析师John R. Rymer指出了当今应用的一个致命缺陷： 当今应用迫使人们去寻找一种将孤立的信息和功能组映射到他们任务和过程的方法，它们强迫IT人员花高额预算来跟踪不断变化的市场、策略、规章制度和业务模型。 在下一个5年内，IT的主要目标应该是发明新一代企业软件，适应业务和业务工作，同时能随业务演变而演变。 Forrester称这个新生代为动态业务应用， 强调了和业务过程及工作（为人而设计）的紧密配合，对业务变化的自适应（为变化而构建）。在这个阶段，动态业务应用的需求比创建它们所需的设计实践更清 晰。工具都是现成的：面向服务架构（SOA）、业务过程管理（BPM）和业务规则领域中的先驱——包括独立软件开发商（ISV）——已经开始向我们展示了 这种方法。现在就是开始这段旅程的时候。 在这篇由两部分组成的文章中，我们会从架构和方法论的角度，采用历史的观点来看待这些动态业务应用（DBA）的发展。我们的目标是获得一种能使应用容易适应业务变化和其他必要修改的构建方法。随着企业在21世纪关注灵活性，DBA是使业务和IT在未来几十年内成功的关键。 图 1. 灵活性和效率——21世纪企业的两个主要驱动力 动态性对我们意味着什么？ 在软件工程领域，许多框架或产品都声称具有自适应性。在我们设法理解一个解决方案在适应变化方面究竟有多好之前，需要给系统是如何变化的——它们的动态性——下一个可靠的定义。 早期的面向对象方法论认识到[1]：为了使系统分析中立，它必须基于两类现实世界的需求： 现实世界的实体 —— 收集现实世界实体的信息和它们间的关系，有助于分析师开始以一种系统的、结构的、客观的观点来看待需求，而非一种技术的、主观的观点 现实世界的事件 —— 系统行为只由改变现实世界实体状态的事件的出现来驱动 在这样的背景下，对于每一个被分析的系统，我们总能识别一个或多个最重要的实体。每个实体都又包含3个关联元素：事件、状态和生命周期。每个事件代 表状态中的一个变化，所有普通实体状态的有序和代表了一个生命周期。但是，那些触发状态变化且是正常流程一部分的事件与那些触发状态变化但不是正常流程一 部分的事件之间有明显的差异。例如，当一个产品订单被提交之后，一组可能发生的事件包括付费处理和订单交付。当一个用户变更订单或当企业改变价格时，我们 不能认为这些动作是正常流程的一部分，因此它们与实体（如订单）的生命周期无关。核心实体实例的生命周期单独定义了在正常操作中系统最有可能处理的东西。 所有其他事件类型，如变化或中间步骤，被区别对待。 这个场景对很多工程师都不陌生：一个系统模型包含一个核心实体结构，该实体具有一组事件，这些事件组成了实体的生命周期。这个系统模型对分析师和设 计者都很清晰且易于理解。建模工具，如有限状态机、实体关系图、实体状态转换图和数据流图，为了帮助这种方法已经经过了快20年的完善。那些为复杂系统 （如空客380或F-22，后者是世界上最高级的战斗机）服务、拥有数十亿行代码的软件就是这样被编写出来的。使用对象流图（它是捕获事件和状态转换的基 础模型）虚拟化实体生命周期是这个模型的关键。在这个情况下，架构可以被认为是静态的，因为整个系统状态在时间轴上的任意一点都是确定的。 图 2. 事件模型、状态变化和生命周期是正常操作的核心 普通事件、状态、生命周期间的关系，以及从其他事件类型中分出的普通事件是理解所建议的动态操作框架的基础。正如James Martin 和James Odell很久以前在《面向对象分析设计》中所写的，分析师、设计师和实现者都应该使用同一系统模型。分析师使用数据流图思考，设计师使用结构图思考，程 序员使用Java和SQL思考。在数据流上下文中，分析师识别对象类型，并思考改变对象状态的事件。最终用户也理解这个相同的认识。他们也应该按照对象类 型、事件、对象状态的变化，以及触发和控制事件的业务规则进行思考。Martin和Odell强调了对象流图对系统设计师的重要性：“事件模式适合按照事 件、触发器、条件和操作来描述过