[已更新Demo附件]生命周期组件框架——关系型状态机服务

 

让写业务代码变得再简单一些！

 

关系型状态机服务的生命周期（Lifecycle）组件框架开启一个新的维度，与各种框架提供的通用非功能服务（比如事务服务，安全性服务）等略有区别，它更贴近于业务建模本身，而又能通过代码以元数据的形式描述一组业务对象的生命周期。元数据的表达使得对状态机的实现更像是文档而非指令式的源代码。如果要更改业务对象的生命周期，只需要更改这份元数据描述，增加或修改相应的业务方法，而不包括对生命周期状态的检查和赋值，这将减少很多代码修改量，并且更安全可靠。该框架的代码量很小，但可以在另一个基础层面提供强大的服务。

 

生命周期组件框架，透明的帮助业务逻辑进行业务对象本身的生命周期状态检测以及关系生命周期的检测。后者尤为重要，往往是一个系统开发了5~6年大量的推广普及以后，最终发现面临很多新的功能或者增强的功能时，开发者都是那么的无力回天，多次研讨会议最终也是说如果当初那样设计就不会造成现在的局面；产品经理们最后面对这头大象也只能装作没有看见。而生命周期组件框架在运行时，作为一个高“情商”的顾问，会在“不适合发生”方法调用时阻止方法调用，保护应用程序的正确状态。

 

此外，生命周期组件框架还提供丰富的事件和回调机制。对于业务对象本身，生命周期组件框架提供状态转换的回调方法，可以极大的利用业务对象本身的上下文来极为方便的表达和完成更多的任务和工作。而对于其他业务模块对三大事件源之一的状态变化事件的需求，生命周期组件框架同样提供松耦合的事件传播。

 

对于一个长时间运行的进程或者过程，往往它的完整性约束和一致性约束不能由系统的事务服务来满足。尤其是宕机出现时，这些进程或者过程大多都表现为不准确的状态。解决这些问题，这更是生命周期组件框架大显身手的战场，在与系统的生命周期事件结合之后，生命周期组件框架可以帮助那些“在飞行的”进程或者过程完美的恢复，而程序员只需要提供很简单的元数据描述以及相应的纯粹的业务方法，甚至是现有的可重用的方法。

生命周期组件框架可以集成不同环境下的锁机制，比如JavaSE环境下的简单的可重入锁，比如JavaEE环境下的JPA的锁，尤其是乐观读写锁，它在验证庞大的关系层级生命周期时，尤为重要。当你深入的了解到生命周期组件框架在关系生命周期的验证方面所做的工作之后，相信你一定更加清楚的认识到过去所写的业务代码的正确性是多麽的有限。如果这一切都不能满足，还可以自定义锁机制，毕竟并发的情况可以非常的复杂，生命周期组件框架只做它应该做的一部分，不需要的情况下它不会多管闲事。

 

生命周期组件框架并不需要业务对象POJO实现任何多余的接口，只需要对现有的POJO进行标注即可。就像很多流行的组件框架一样，它在运行时在字节码层面拦截方法执行。除了添加生命周期描述以外，就只有减少代码量。

 

最重要的是生命周期组件框架是开源的，免费的，任意修改发行的。开源地址如下：

https://github.com/zhongdj/Swordfish/tree/master/Platform/Lifecycle 

此刻Lifecycle Framework核心功能第一个版本现在可以尝试了。虽然它的测试覆盖率还没有超过90%，或许性能也还有很大提升的空间，与其他流行组件框架的兼容性还需要进一步测试。但这都只是时间的问题。与其所提供的概念和服务相比，那都是微不足道的。生命周期组件框架可以像其他组件框架一样，提供一种基础层面的服务，这种基础的服务，不仅仅可以减少编码量，还可以产生新的编程实践，使得架构更简洁，促使应用程序设计变得更健壮。希望生命周期状态机服务可以成为JCP的一个规范，使得更多的开发者从中受益。

 

注：如需要尝试需要注意两方面： 

1. 正确打包和配置manifest文件。目前如果checkout整个工程，那么该部分工作pom文件已经帮您做了。
2. 运行时需要正确的依赖jar包类路径的正确设置，应该跟manifest文件保持一致。目前如果checkout整个工程，那么该部分工作pom文件已经帮您做了。

详情请参看pom文件。

 

• 简单状态机示例代码
• 复合状态机示例代码
• 关系型状态机示例代码
• 继承状态机示例代码
• 条件转移以及生命周期回调示例代码
• 生命周期事件示例代码
• 简单状态机并发加解锁示例代码 
• 关系型状态机加解读写锁示例代码 
• 带有多个状态机的实现类示例代码

目前添加了部分代码示例到附件中,可以使用JDK7 + Eclipse打开

评论

4 楼 barryzhong 2013-11-24  

superdingdang 写道

引用

“在飞行的”进程或者过程

指的是？

有一些应用场景涉及到长时间在内存中运行的任务，即使是在业务（事务）系统中。往往对于这样长时间运行的任务而言，它的生命周期会包含类似于“运行中”的状态（就是在飞行的状态）。这种任务都有两个共性：第一不能使用“事务模型”来简单处理，做了两个小时，任务完成了89%，不可能因为接下来的故障而回滚前2个小时的工作（对于整个任务不能Rollback）。第二既然是长时间运行，又不能采用事务服务来保证一致性，持久性和完整性，那么就需要自身来维护自己的生命周期。假使在运行中出现断电，重启等状况，这些长时间处于运行态的任务应该能够恢复自身的运行状态。简单地说就像是下载程序一样，在支持断点续传的前提下，每一个下载任务都能够记录当前下载的区块的偏移量，一旦故障重启，程序仍然可以根据之前记录的偏移量继续从支持断点续传的下载服务继续执行任务。虽然，之前下载任务未记录偏移量的缓存部分会丢掉，但是这本身最小化了故障恢复的成本。而另外一种，对于不支持断点续传的下载服务，应用程序就没有办法恢复(Resume)之前的下载状态，要想恢复之前的任务，只能重新下载(Redo)。

生命周期框架的Recover机制，在集成服务器生命周期扩展或者独立应用程序的生命周期扩展之后，就可以在合适的时机，自动的修复(Recover):包扩基本的Resume和Redo

3 楼 barryzhong 2013-11-24  

superdingdang 写道

引用

生命周期组件框架，透明的帮助业务逻辑进行业务对象本身的生命周期状态检测以及关系生命周期的检测。

中的关系生命周期指的是什么？

关系指的就是面向对象设计建模中的对象与对象之间的“关系”：包括依赖，关联，聚合以及组合。而关系的确立也由对象与对象的交互过程决定的。交互所涉及到双方生命周期的交集与交互双方本身的生命周期共同决定了关系的类型。

比如打印机与纸，他们各自有自己独立的生命周期，仅仅是在打印过程中才发生交互。纸的存在不依赖于打印机的存在；打印机的存在也不依赖于纸的存在。但是它们的生命周期可以有交集，就是在打印的过程中，两者发生交互。而交互所覆盖的生命周期仅仅是打印机和纸生命周期中的一小部分。这种就是除了没有关系以外最弱的关系——依赖。

当然这也可以被设计成关联，比如，打印的人并不是每次使用打印机时才放进去一张纸（笔者在很多农村的打印社看到的就是这样的使用方式），而是把一打纸放在打印机的纸盒里，当有打印要求发生的时候，打印者通常不会自己拿一张白纸放到打印机里，而是直接要打印机打印。那么实际上打印机就负责了纸张的一部分管理任务。此时纸张与打印机的生命周期覆盖显然要比第一种情况的生命周期交集要大一些，但是两者的生命周期的开始，即打印机的诞生和纸张的诞生还是没有关系，打印机的销毁和纸张的销毁还是没有关系。但是在打印服务运行过程中，打印机又多出一部分关于纸盒的管理，在向外提供打印服务时，纸并不是一个输入状态，而是打印机自身维护的一个状态，这就构成了一个比较弱的has a 的语义——关联关系。

众所周知，随着生命周期覆盖的增加，关系也就渐强。从无缘对面不相逢（没有关系），到萍水相逢路见不平拔刀相助（依赖），到同舟共济（关联），到一个家庭（聚合），再到同生共死（组合）。（比喻未必恰当）

而生命周期组件框架扩展了传统UML状态机，增加了对关系约束的检查。保证一个对象的行为发生时，这个行为依赖到的关系必须处在恰当的生命周期状态。比如打印服务在打印之前，纸张必须是有单面空白的，才能打印。或者在一个人求另一个人办事之前，需要确认另一个人的心情很好时才去找此人谈这件事等等。

2 楼 superdingdang 2013-11-24  

引用

“在飞行的”进程或者过程

指的是？

1 楼 superdingdang 2013-11-24  

引用

生命周期组件框架，透明的帮助业务逻辑进行业务对象本身的生命周期状态检测以及关系生命周期的检测。

中的关系生命周期指的是什么？