基于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的应用，消耗客户端的资源比较大。（现在的客户端的运算能力都很强大了）

通讯协议是http?还是自定义的socket?

与更新服务器的通讯协议用http，而里面各自的RCP应用，使用什么通讯协议都可以，由各自的应用决定。
而这个框架会预先集成目前java所流行的远程通讯协议，像spring remote 之类的。每种通讯协议的集成就是一个bundle，方便各个应用之间共享。

在RCP里集成FLEX也是一种常见的方法。

楼主说的不正是 eclipse4.0吗？ 

下一代的eclipse，比你说的还要简单。
直接将eclipse rcp应用生成flex 或ajax等应用，直接就在浏览器里运行。
你说的，不现实，谁会装你的客户端呀？
类似的swing早就存在这样的框架了 ，比如echo，还有一个是基于apache授权的，名字忘了，都是直接写Java代码，然后在浏览器端就可以访问。echo效率还能勉强接受，但是灵活性就没了，这种东西适合不愿接触js的开发者，如果会js，还是自己弄的好，容易控制功能。

e4，目前情况太渺茫了，即使弄出来，可以预见 效率不会太好。
而且e4，声称不用js ajax，不过最近不是也引入js代码了吗，可见，不写js是很难控制灵活性的。e4已经改变了初衷了。
eclipse越来越复杂，难道失去方向了。我觉得一个开发工具应该在易用性上找方向，
简化开发，提高开发效率才是应该做的。相反，eclipse总是在包装，越来越复杂。
别看我这么关注eclipse，其实我是netbeans的爱好者。
       netbeans符合我的意愿。 看看.net开发工具做的简单易用，多少人在埋怨Java开发效率太低啊。  netbeans在走简化开发的道路，而eclipse真的看不出来，或许eclipse只关注Java最前沿，像什么OSGI 等等，不过话说回来，100个企业里有几个是有这种需求的企业，我想90%的都是小型企业吧，他们需要的是快速开发的工具。

比较认同，不过现在eclipse或者netbeans都没太多精力去弄，目前netbeans的前途还不好说，oracle虽然不会砍掉，但明显会减少投资。eclipse其实已经不走开发工具的道路，已经是完全平台化方向，开发工具留给像MyEclipse来做。

谢谢wsc830719的意见。
我想说两点：
1、关于这个客户端，客户愿不愿意装的问题。这个要看是什么客户，像我现在的项目接触的客户，都是企业用户，都是在局域网里或是专线，应该不成问题。

2、关于生成JS，然后再浏览器里运行的问题。我们需要的不是编译成JS然后再浏览器里运行，而是直接就是一个java程序，在客户端的虚拟机里运行（因为我们把JRE随框架一起打包下发）。转成JS的话，运行速度和控制外设都不是很理想。

说白了，就是一个C/S结构的系统。只不过有B/S结构应用的客户端快速分发部署的功能而已。并且这个框架可以当成一个内部的框架，使用这种结构的系统，而每个应用能直接在这个框架里跑。这就是“应用浏览器”和“网页浏览器”的区别。

楼主所说的和我现在正在做的SmartRCP有异曲同工之妙哦
http://www.iteye.com/news/13593-SmartRCP-Flex-Eclipse-rcp

JRE压缩后可以精简到10M
仅利用RCP的更新和插件机制，没有什么创新的

是用了Eclipse RCP的插件机制。
但不是用Eclipse 的RCP更新机制。更新机制使自己写的，可以完全控制eclipse的更新，包括整个EClipse RCP 框架的更新。对客户端完全透明的更新。
一个标准的RCP应用，所以可以使用RCP的框架的全部功能。

这年头，咱们做的东西多少是自己创新的呢？其实把该掌握的东西掌握了，就了不起了。
不是吗？