1 实现了针对MS SQL的DAO部分
2 增加了对用户的支持，可以制定与Node相关的用户
3 修改了Spring整合部分
4 新增了基于Struts2的WEB程序示例
下载地址：
http://www.blogjava.net/Files/chaocai/swf-0.94.rar
参见
SWF一个简单工作流引擎
DAO看似是一个非常简单的模式，但这个模式却十分重要，它可以帮助我们实现持久化逻辑和业务逻辑的分离；它可以帮助我们实现对多种持久化实现的支持。
同时，DAO模式并没有看起来这么简单，要真正发挥它的威力需注意的方面很多，而这些方面常常被大家忽略，以下是本人总结的一些最佳实践。
1 不要在DAO上控制事务的边界
应该在Façade层控制事务的边界，这样可以提高DAO的复用性，使它适用于不同的事务策略。
2 不要过分使用Checked Exception
开发者常常会将DAO中的各种异常通通捕捉并通过Checked Exception抛出，其实这是中不好的习惯，因为DAO中发生的异常常常是不可恢复的（如：数据库连接问题等），既然如此就应该使用RuntimeException异常抛出，使用这种异常还有一个好处就是在CMP的情况下可以自动引发事务的回滚。
3 不要在DAO中处理懒加载问题
使用Hibernate就会经常遇到懒加载问题，但是这个问题不应该在DAO中解决，这样会影响DAO的复用性，应为要加载那些对象域往往是和界面相关的，这个问题应该在Façade层中解决，应为这是离表现层较近的一层。
http://dev2dev.bea.com.cn/blog/chaocai/200806/dao_24_1070.html
蔡超
软件架构师
软件架构顾问
SCEA
IBM Certified Solution Designer for OOA&D vUML2
Chaocai2001@yahoo.com.cn
“自己实现IoC,AOP容器”（http://www.blogjava.net/chaocai/archive/2008/05/26/203020.html）文章中给出的文件下载后有问题，请从以下地址下载。
http://www.blogjava.net/Files/chaocai/mini-container-beta-0.9-a.rar
源码下载没有问题可以继续下载。
上一篇相关内容
http://www.blogjava.net/chaocai/archive/2008/05/26/203020.html
源码下载
http://www.blogjava.net/Files/chaocai/mini-container-beta0.9-src.rar
希望对大家有帮z，也期待大家的反馈！
摘要:
Mini-Container 开发者手册
(Mini-Container Beta 0.9,
下载地址：http://www.blogjava.net/Files/chaocai/mini-container-beta-0.9.rar
)
蔡超
软件架构师
软件架构咨询顾问
Chaocai2001@yahoo.com.cn
序
Mini-Container...
阅读全文
近期做了几个使用OSGi开发的应用，发现使用过细粒度的Bundle不会给项目带来任何好处，而很多设计人员实际都会在使用OSGi平台时陷入这个陷阱。
首先我们分析OSGi的特点及可以给我们应用带来的好处
1 良好的动态特性
2 更细粒度的类装载控制，多个版本组件在同一运行环境中共同运行
3 在JVM内部实现SOA（我个人倒是认为OSGi所涉及的仅仅是SOA思想的一小部分）
4 DS提供的IoC支持
请思考你的应用程序真的需要这些吗？
很多设计和开发人员都会在设计和实现时忽略应用的真正需要和OSGi的复杂性，将应用的所有内部细小划分都采用Bundle实现。
而我们除了应该注意采用OSGi开发和调试带来的复杂性；同时也要明白动态特性的支持并不是仅仅采用OSGi平台就可以搞定的，要真正实现动态特性必须注意模块的启动顺序无关性及对其所依赖服务的监听等，这些都会大大增加系统实现和调试的复杂性。
其实我们应该认真分析应用是否需要这些OSGi的特性及这些特性应该在应用的那些部分体现，例如我们可以在扩展方面采用Bundle实现扩展插件，至于其它部分则不必采用过多的Bundles（甚至可以采用一个大的Bundle，而其内部则可以采用如Spring来帮助我们实现模块化）。
同时，不要忘记其他的framework同样提供了很好的组件化的基础架构如Spring，Pico-Container，在OSGi与其它技术混合时SCA同样是很好的选择。
保持应用的简单性，不要针对特定技术进行设计，而要为设计选择适合的技术。
蔡超
Chaocai2001@yahoo.com.cn
JEE咨询顾问
SCEA(1.2&5)
IBM Certified OOA&D Solution Designer vUML2
厌倦了那些厚书（特别是那些为了赚钱而特意写厚的书），很多时候这些书让我们找不到技术要点，甚至丧失了学习的兴趣，而最终变成那些拒绝新技术的“顽固派”。
其实掌握技术的最佳方式是实践，在实践中不断的深入学习。
本教程旨在帮助哪些已经掌握了OSGi和Spring技术基础的开发人员，迅速将Spring DM应用于实际开发，这是一份入门教程，不求全面，但求简单。
并请配合本教程的实例代码一同学习。
下载教程和示例:
http://www.blogjava.net/Files/chaocai/spring-osgi.rar
蔡超
JEE咨询顾问
SCEA(1.2&5)
IBM Certified OOA&D Solution Designer vUML2
引言
分层结构是目前复杂应用系统开发时普遍使用的模式，软件中层之间的依赖关系约束是比较宽松的，并不要求上层仅可以依赖于直接下层，而是上层可以依赖于它的所有下层。
设计中我们会把各种系统的各种组件映射至不同层中，而在我所接触的一些实际项目中设计人员在映射这种组件和层间的关系时经常无意中破坏了层结构的依赖关系约束。
图表 1 典型分层结构
设计中的常见问题
问题一:数据传输对象（DTO）是否应该属于业务层？
在J2EE开发的经典著作《Core J2EE Patterns》中数据传输对象被划分在业务层模式中，那么是否数据传输对象应该被映射到业务层呢？
数据访问对象（DAO）在该著作中是被映射到整合层的，这样就会出现一个违反层依赖约束的问题，因为数据访问对象是要依赖于数据传输对象的，因此下层就会出现对上层的依赖了。
所以本人认为DTO是在各层中传输数据的，我们可以不必强求的把他们映射到上述层次中，可以把他们放置在一个公共包中。
问题二:使用POJO作业务对象的轻量级架构与上述层模型的映射
在使用POJO的轻量级结构中我们通常会使用持久化框架（如Hibernate/JPA）同时会在架构中引入仓库对象(Repository Object)，负责业务对象的获取和保存。（注意：他的功能和DAO是有区别的，仓库对象中通常只应包括业务对象的获取和保存逻辑）。
通常设计人员会把业务对象映射至业务层，而将仓库对象映射至整合层。由于仓库对象对于业务对象的依赖关系就会破坏依赖关系约束，所以这种映射方式显然不正确。
下图是作者推荐的映射方式
图表 2 轻量级架构参考模型
可以看到业务对象和仓库对象都被映射至业务层，而持久化框架被映射到了整合层。
总结
因此大家在设计过程中不要仅仅将分层结构留于形式，而要时刻注意设计是否符合这种架构模式，这样才能真正发挥这种架构模式的优势。
JavaEE 咨询顾问
SCEA (1.2&5.0)
IBM Certified Solution Designer for OOA&D UML2
http://dev2dev.bea.com.cn/blog/chaocai/200801/soa_component_28_885.html
这个考试和原来的SCEA一样分成三个部分
1 选择，基础知识
2 设计，
3 简答
感觉Beta版比正式版难度大多了，题目数量特别多。而且设计题难度也大。