文章:《超越 SOA:动态业务应用的新企业应用框架》

阅读数:70 2008 年 4 月 23 日

话题:SOA架构

就在 SOA 热潮席卷全球的今天,又有人提出了“超越 SOA”。哗众取宠,还是确有真材实料?各位不妨在阅读了《超越 SOA:动态业务应用的新企业应用框架》之后自行判断。在阅读之前,不妨先看看文章自己的总结:

我们已经讨论了扁平、无状态、静态、客户端——服务器、基于 Web 的解决方案的演变方式所带来的 IT 架构和层次、有状态、动态、分布式业务的现实世界之间的脱节。我们还讨论了传统工程方法为什么不能支撑能支持动态业务的自适应系统的开发。我们展示这两个问题的可能解决方案可以用一种新的模型驱动架构方法来找到。

在参考了传统的飞机制造和桥梁建筑的工程方法之后,文章提出:设计企业系统要求框架先行。同时提出了一个以 5 个模型为基础的自适应架构:

  • 事件模型 / 生命周期—— 它是构建其他模型的基础核心。对业务用户来说,它是价值流,反映产品 / 服务生命周期和为客户创造价值的过程序列。对技术人员来说,同一事件序列反映了代表业务实体对象的状态变化。最终结果是,事件模型扮演了解耦元素,大大简化了设计和实现。事件模型还扮演了另一个重要角色。因为其他四个模型是围绕事件模型而构建的,它还扮演一个集成平台。事实上,事件模型是创造实现变更、层次和分布式组件的唯一办法。
  • 状态模型—— 对业务用户来说,这个模型扮演了企业的面板,捕获当前经营的整体状况。对技术人员来说,它是系统的整体状态,它是全部生命周期实例的当前状态,以及它们的变化之和。
  • 分布式模型 —— 对业务用户来说,这个模型捕获了其生命周期内控制产品 / 服务的各种组织。对技术人员来说,主实体只能基于分布式模型来控制。
  • 层次模型—— 所有业务都有代表管理层级的层次结构。所有系统设计应该在架构上反映这种控制层次。正如销售 VP 不能给 CEO 下命令一样,低层级的组件不能给高层级的组件发送执行“命令”。
  • 动态模型—— 继事件模型之后最重要的模型。业务用户使用它来捕获平时必须被处理的全部变更。如前所述,有两种变化类型:外部,如客户输入;内部,如管理决策。对技术人员来说,动态模型被翻译成一个匹配各种事件、生命周期和变化类型的插件架构。

阅读全文:超越 SOA:动态业务应用的新企业应用框架