从上次迭代结束（14号）到今天，基本完成了系统核心框架设计。
按照我们的计划，现在是迭代1阶段，貌似在进度上还是计划得比较好。不过，这3天一直忙着一面学习OSGi，一面重构核心框架，有的任务可能耽搁了点:-)
但是，我们的应用框架现在更合理了，呵呵。说一下目前的设计：
基于OSGi的面向服务组件模型
所有工程编译打包后都作为了一个组件，提供一定的服务。目前，我们有
DesktopApp组件：StoneAgeDict桌面版本GUI
DictsManager：词库管理器，管理用户下载的、自定义的词库
StarDictQueryEngine：StarDict（星际译王）词库的查询引擎
在没有基于OSGi框架以前，迭代0完成的时候代码量有5000多行。基于OSGi后（由于框架方面不用操心，删除了N多的工厂类，还有减少了很多 抽象类），代码量为3000多行。可以看出，重用OSGi框架不仅使我们的系统有了SOA的味道，大家都可以以相同的服务视角去看系统，易理解，而且在开 发的复杂度上大大降低了。
举个例子，以前拿到需求，都是只停留在了OO的层次上做的设计。团队开发的时候还是以类/包，或者子系统的方式分工，感觉不是很高效。特别是设计的 时候，interface类/abstract类，Factory类作为了整个系统各个部件之间解耦的关键，需要投入相当多的时间去设计和实现。即便这 样，系统以后应变的能力还是不能太好，特别是随着系统变得越来越巨大的时候，维护的代价可能是成指数倍的。而基于OSGi框架，Component- Oriented，甚至是Service-Oriented的高度去设计的话可以把整个应用的架构做得更好。对于每个素服粗件，我们都需要清晰地定义出它 Import和Export的服务，而且这是纯服务，内部实现完全被隐藏了！加上OSGi提供对于每个服务组件的版本描述，可以很好地解决组件更新的问 题。这样，我们可以实现极低耦合的系统，而且系统功能还可以无限扩展！
关于Spring与OSGi的整合
以前用Spring这个IoC容器，感觉那个神奇啊，如今用OSGi这个组件服务框架，感觉那个实用啊！
呵呵。。。。
话说回来了，如果要做Java的Web应用，Spring应该是首选框架。理论上来说，OSGi可以整合Spring进去，不过这样做貌似比较困难。。。。
还是用Spring整合OSGi，网上教程比较多，有把握。只要Spring可以调用OSGi里的各种Bundles，目的就达到了！
Flex和Spring的整合
StoneAgeDict的Web界面上，目前暂定使用Adobe Flex。接触一下RIA的技术，还是比较好的。
关于Spring和Flex整合，这个问题应该不是很复杂。这两个都是当前业界用得比较多的，所以技术上可以完成。
通过前面的介绍，我们的系统整体架构上用到的技术／框架基本就是
Web方面：Flex + Spring + OSGi
桌面方面：Swing+ OSGi
所有基础服务全部做到OSGi里，然后。。。。三个框架整合一把，不知道要有多少“胶水配置代码”，呵呵。