利用Eclipse的Update组件实现适合企业应用的更新组件(1)

tag: java,eclipse,rcp,ibm,client,wed,expeditor,liveupdate,update

 

有关Eclipse RCP的废话少说，直接进入正题。

做一个商业软件，应用更新组件是必不可少的，包括windows,Norton等软件都有自己很好的自动更新体系，它们都做得很复杂，简单的也有，如QQ，360安全卫士，由于是轻量级的客户端，更新时只是些版本判断和简单的替换即可，不涉及太多的其它问题。

如果做过某些企业应用，则会发现软件更新会有其更特殊的一面。除了某些通用的如版本管理，兼容性管理，平台版本管理，签名检查，冲突检测及解决外，我们可能需要更多的定制特性，比如：基于权限的更新，定向更新（只向某些固定的用户更新），对更新的时机和动做也千差万别，比如，在启动前更新（跑跑卡丁车），启动后立即更新，定时自动更新（提供非常灵活的机制，如一个月的某天某个时间，每天的某时，每周六的某时，非周某的某个时间等），更新动作的定制，如完成免干扰，即一切进种都接某种配置进行（类似于silent installation），应用出错了（BUG）/网络问题等，需要重启（提示/不提示？），在某些无人值守的终端，可能不需要提示，而在有人值守的终端，则需要提示避免丢失数据，提示/不提示客户端，从而不打扰客户端进行正常工作，有些地方要求由管理员集中控制每个端终/用户的更新策略（如某些企业版的杀毒软件）等等。

以上列举了一些企业软件同通用软件相比在自动更新组件上的一些不同。然而无论是选取什么样的开发工具/开发语言/架构，完全满足上述需求的现成组件都不存在。它们大多提供一个较通用的更新架构，可定制性不强，本文以Eclipse为例说明有何种途径去达成上述目标。如果你的客户端基于Eclipse RCP架构，希望本文可以做为参考，帮助你尽快实现你的更新需求。如果你已经开发更好的解决方案或有更好的建议，也在此留言交流（http://blog.csdn.net/mudboy/）。

Eclipse的更新机制基于Feature，一个Feature是一个功能部件，是若干个plugin的组合，若干个Feature可以组成一个更新站点（site）部署在可以基于http访问的服务器上。利用ECLIPSE可以方便的生成Feature和site。

以org.eclipse.update为前缀的五六个插件是Eclipse 更新组的的主要部分。就象前面所说的，它提供了一个更新组件所需要的主要功能：但它提供给最终用户的界面相对较专业，不适合企业的一般操作者。

1、              基于现有Feature的更新功能，系统按照Fearture.xml中指定的URL寻找更新，但如果更新站点变化呢？或是需要不同的用户找不同的站点呢？可以用policy，指定policy，但policy只是指定哪些插件去什么站点更新之之类的问题，依然不方便动态的更改policy

2、              寻找新的更新，这个界面要求用户新建站点再查找更新，这对普通用户不适合。

3、              自动更新：自动更新的时间设置灵活性不大，自动更新大多基于现有特性的更新，无法自动查找新的特性，定制站点也不太多便。

4、              无法进行免干扰更新，也就是说，在一个更新进程中，很多过程都需要用户干预，比如选择站点，选择要安装的部件，签名警告（可通过设置去除），重启应用等，虽说这给用户更大的自由度，但有时并不适合企业应用。

应该说，核心的功能已经足够用了，我们需要改善的只是皮毛，如果我们没有特殊需求的话，则只需要乎出几个菜单就可以实现更新功能了，有一篇文章写了相关的内容（http://www.ibm.com/developerworks/cn/opensource/os-ecl-rcpum/）。

由于Eclipse现成的更新应用集成了很多的UI，因此利用表层的实现无法达到要求，必须从底层一些构造更新组件，但可以参照现有的表层实现，主要可以借鉴的类有：

UpdateJob

UpdateSearchRequest

UpdateUtils

InstallWizardOperation

InstallWizard

InstallWizard2

仅需参照这几个类，我们就可以构造一个完全可控的更新组件。

 

（未待续完）

 

发表于 @ 2007年03月23日　16:59:00 | 评论( loading... ) | 编辑| 举报| 收藏

旧一篇:上班路上的抉择----无解的CSP? | 新一篇:购房经历（合集）