菜鸟也谈架构之C/S三层架构的轮回

菜鸟也谈架构

本人06年毕业 一直做JavaWeb应用的项目 大大小小做了5、6个吧

感觉B/S结构的应用 项目实施下来都不是很理想 虽然都验收了 但我觉得这些项目也顶多能给个百分制及格分 60分

主要弊端：

（1）实时响应速度差
（尽管已经做了集群、机器是小型机）

（2）人机交互能力太弱，有些特殊的地方还不得不借助鸡勒技术ActiveX和Applet。使得B/S仅有的一点点部署方便的优势荡然无存。
（尽管现在已经有很多RIA技术手段,比如EXT、Flex等~ 但都有各种问题。论证下来实施这些技术还是性价比不够理想。）

我的想法：

C/S三层架构应该要轮回崛起了。
理论上说,B/S其实也是属于C/S三层架构的应用。但他的C这一层实在让人不爽。

扪心自问，你为什么要选择B/S来做行业应用系统(特质运行在专用网里的特定行业应用系统)
(1)、为了跟时髦。觉得JavaEE(B/S)代表了时尚潮流，代表了先进。
扯淡。JavaEE并非就得把C做成浏览器应用。评价系统优劣最直接的三要素：方便、快捷、稳定（我一客户和我说话聊的，我决定很有道理）
(2)、为了数据和业务逻辑集中，实现部署、升级的方便。
这恐怕是针对C/S原始2层架构而言.而且是因为你技术部到位不能做到完美的自动升级而把这一功能通过b/s模式变相解决吧。至于数据和业务逻辑的集中如果是C/S三层架构的话，B/S根本没有这一优势可言。C/S三成架构一样可以做到。
(3)、为了应用服务器集中、方便做集群和各种负载均衡。
C/S三层一样可以。

居然如此：我们为什么还要选择B/S 。

我的想法：
做一个c/s三层架构。总的方向还是基于Java。

方案一：用SWT/Jface和EclipseRCP技术做为UI层技术。实现一个纯粹的UI客户端。通过RPC调用JavaEE应用服务器发布的方法进行业务处理。此方案的问题：选择一种高性能且易于异构系统集成的RPC方法。（初定的方法是使用httpinvoker作为架构内部的RPC调用，并支持 webservice满足其他异构系统调用需求）不知道hprpse是否能同时兼顾高性能且易于异构系统集成？

方案二：用SWT/Jface和EclipseRCP技术做为UI层技术。实现一个纯粹的UI客户端。然后自己实现一个类似中间件或者应用服务器概念的东西，但不走http协议。考虑其他通信方式。我的业务逻辑组件也不希望再借助于Java应用服务器。而是直接将我的业务逻辑组件发布到这个中间件上作为服务提供给客户端调用。这只是偶的想法，不知具体怎么实现 不知道hprose是否能再这方面做点什么？