就在 SOA 热潮席卷全球的今天，又有人提出了“超越 SOA”。哗众取宠，还是确有真材实料？各位不妨在阅读了《超越 SOA：动态业务应用的新企业应用框架》之后自行判断。在阅读之前，不妨先看看文章自己的总结：
我们已经讨论了扁平、无状态、静态、客户端——服务器、基于 Web 的解决方案的演变方式所带来的 IT 架构和层次、有状态、动态、分布式业务的现实世界之间的脱节。我们还讨论了传统工程方法为什么不能支撑能支持动态业务的自适应系统的开发。我们展示这两个问题的可能解决方案可以用一种新的模型驱动架构方法来找到。
在参考了传统的飞机制造和桥梁建筑的工程方法之后，文章提出：设计企业系统要求框架先行。同时提出了一个以 5 个模型为基础的自适应架构：
- 事件模型 / 生命周期—— 它是构建其他模型的基础核心。对业务用户来说，它是价值流，反映产品 / 服务生命周期和为客户创造价值的过程序列。对技术人员来说，同一事件序列反映了代表业务实体对象的状态变化。最终结果是，事件模型扮演了解耦元素，大大简化了设计和实现。事件模型还扮演了另一个重要角色。因为其他四个模型是围绕事件模型而构建的，它还扮演一个集成平台。事实上，事件模型是创造实现变更、层次和分布式组件的唯一办法。
- 状态模型—— 对业务用户来说，这个模型扮演了企业的面板，捕获当前经营的整体状况。对技术人员来说，它是系统的整体状态，它是全部生命周期实例的当前状态，以及它们的变化之和。
- 分布式模型 —— 对业务用户来说，这个模型捕获了其生命周期内控制产品 / 服务的各种组织。对技术人员来说，主实体只能基于分布式模型来控制。
- 层次模型—— 所有业务都有代表管理层级的层次结构。所有系统设计应该在架构上反映这种控制层次。正如销售 VP 不能给 CEO 下命令一样，低层级的组件不能给高层级的组件发送执行“命令”。
- 动态模型—— 继事件模型之后最重要的模型。业务用户使用它来捕获平时必须被处理的全部变更。如前所述，有两种变化类型：外部，如客户输入；内部，如管理决策。对技术人员来说，动态模型被翻译成一个匹配各种事件、生命周期和变化类型的插件架构。
暂无签名
最新发布
Grails 入门指南（第二版）
2010 年 10 月 25 日
你吓着我了，MOSS
2009 年 7 月 17 日
书评：《RESTful Web Services 中文版》
2008 年 6 月 4 日
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
阿里KAN-TTS技术和落地实践
出行场景下数据智能化和生态建设历程
基于 Serverless 的腾讯在线教育中后台业务落地实践
评论