基于Eclipse RCP的应用平台

B/S结构的应用的优势和劣势是什么？呵呵，优势我不说了。在开发企业应用时，有一些情况下BS是不能胜任的，或者是说需要花很大的代价才能做到，比如驱动外设，打印，复杂的页面控制等。而传统的C/S结构的应用可以很好的解决这些问题，能不能把这两者的优点结合起来呢？

 

有这样一个想法，就是设计一个基于Eclipse RCP的应用平台，暂时叫它“Eclipse Application Planform”吧。设计的思路是这样的：它的功能就是一个“浏览器”，不过它浏览的不是网页，而是一个Eclipse RCP应用，就像使用浏览器一样，首先得下载一个Eclipse RCP 框架，大概15M左右，另外，为了屏蔽客户端的JRE的差异，可以把JRE（1.6版本，解压后大概80M）也打到框架里，一起下发给客户端。ok，框架下发到客户端了，就像装好了IE浏览器一样，可以浏览应用了。第一次使用某个应用时，输入应用名称和更新服务器的地址，（服务端需要有一个版本更新服务器，可以是一个web应用，提供http或FTP文件下载，作为各个应用的版本管理）。然后客户端框架就自动下载对应的java class文件，然后启动Eclipse RCP应用。一旦某个应用有更新，只需要在服务端版本服务器上做更新，客户端就会自动更新(当然，支持全量和增量更新)。这样岂不是解决了客户端部署维护的难题？还有一点：Eclipse RCP 是一个标准的框架，只要基于他开发的应用都可以导出成单个应用bundle，然后发布到版本更新服务器，供客户端使用，而这个过程不需要额外对客户端的部署，只需要告诉客户端应用名称和更新服务器的地址就行了。

 

平台的优点：

1、客户端操作简单，第一次只需下载框架，然后解压就可以运行（已经自带JRE）。

2、一个框架，可以运行不同的应用，（当然这些应用都是基于Eclipse RCP开发的，而且版本兼容）。

3、BS结构和CB结构应用的优势互补。（也可以叫BS与CS的折中吧）

 

平台的缺点：

1、框架太大，加上JRE的话，可能会超过100M。（对于企业内部的应用，这个不算什么，毕竟就下载一次）。

2、基于Eclipse的应用，消耗客户端的资源比较大。（现在的客户端的运算能力都很强大了）

其实很多企业的C/S应用都带有自动更新的功能，而这里强调的是：它是一个平台，可以浏览不同的应用，只要应用按照Eclipse RCP 规范开发的即可。不知大家对这个思路有什么看法。