B/S，C/S架构混合使用 (转)

http://www.blogjava.net/nighty/archive/2008/05/06/198669.html

一般而言，我们平常接触的大多数项目都应该是单纯使用B/S或是C/S，除非在特殊场合，否则比较少混合使用B/S，C/S架构。首先说一下对这二种架构特点的一些个人理解。B/S应该是目前很多项目都应用的架构，浏览器的方式使得用户的使用十分方便，用户可以何时何地通过Internet访问URL而进行相应的工作，升级维护也能比较集中，缺点就是浏览器的表现能力受限以及常常受非议的安全性问题，如果软件的应用范围区域不集中，而且用户经常变换地点进行访问，那么这种架构是非常适合的。C/S架构的C端有非常强的处理能力，所以在交互表现和安全方面可以做得比浏览器强，但是缺点也是非常明显的，安装部署、升级维护、版本兼容都是比较头大的事情，一般的适用场景是集中的办公室场所，用户使用范围相对稳定，以及一些对业务处理非常复杂的场合，为了降低服务器的负荷，同样需要C模式的支持。

以前接触过的电信领域，就有过混合架构的软件。但是都是非常宠大，一直都对其实现方案比较感兴趣，但是都没有机会进一步了解。最近搜索了一下相关的资料，总结一下混合应用的一些想法（只针对Java方向）。

①混合架构的问题集中点。服务端共享，客户端采用不同的表现方式，共享的应该是业务层接口，持久层应该是屏蔽的。应用层的消息传递就是整个应用的关键所在，虽然像Jakarta提供的httpClient这种模仿浏览器的组件，但是毕竟是模仿，在很多方面的功能还是缺失的。

②最传统的方式是采用EJB做为服务，这个宠然大物容易让人害怕，不过在分布式的系统中它还是有应用优势的，像电信和金融这种行业应用还是比较广的，而且现成的中间件和应用服务器商都比较多，像Oracel、BEA、IBM、Sun都有成熟的应用产品，当然开发的成本和人力投入也是恐龙级数据的。

③有网友说在C端直接访问数据库，B/S结构不变，也就是通过数据库进行共享。这种方式是不可取的，二个缺点：把服务器的业务逻辑搬到了C端上，严格上讲是不安全的，升级维护也非常麻烦；并发控制的压力都在数据库上。

④采用RMI，这个老古董相信应该很多人都不使用了，因为它的使用要一连串的手续，比如服务接口定义必须实现Remote接口，服务Server在实现时必须继承UnicastRemoteobject类，必须使用rmic指令产生stub和skeleton等，设置上繁杂。

⑤Spring远程服务。这个应该说是比较可取的，大家都比较喜欢轻量级的东西。就如第一点所说的，通过远程服务，我们可以在客户直接调用服务端的服务接口，就像本地调用一样，Spring对远程服务提供了好几种实现方案。

⑥WebService。适合异构环境，但是WSDL的这种方式相对来说会比较耗费资料，因为标准定义除了业务内容外，还有许多另外的说明内容。

Spring远程服务实现方案介绍：

⑴Spring+RMI。Spring把传统的RMI方式的繁杂设置去掉，只要配置Bean文件就和定义服务接口可以。RMI的服务启动和管理都交给Spring来处理。RMI访问的缺点就是对防火墙的穿透力比较差。

⑵Spring+Caucho的Hessian、Burlap。Hessian使用Http将对象以中性的二进制消息进行传送，而不像RMI使用Java的序列化格式（这种序列化是专制的，不是Sun提供的序列化机制），由于是二进制消息，所以不受限于某种实现语言，传输时所需要的带宽较小是其优点。Burlap是以XML文件格式传送对象，XML文件有较高可读性，应用程序只要能解释XML就能接收消息，当然也不限于某种语言，但是组装XML和解释XML都需要消耗资源，当传输大数据时性能应该存在问题。

⑶Spring+HttpInvoker。由于Hessian的序列化机制不是正统的Java序列化机制，所以当遇到传输复杂的业务模型时，就会存在各种问题，为此，Spring又提供了HttpInvoker，同样是使用Http传送对象，而且是使用Java的序列化机制。相比RMI，Http对防火墙的穿透力要强。

后来尝试了最后的这种HttpInvoker方式，是在Spring2.0版本下尝试的，开发非常简单，网上也有大量的资料介绍。应该说从这里入口可以做一些尝试。目前遇到的一个项目就需要混合架构，B/S采用Spring2+Struts2+Hiberntae3，浏览器只提供一些查询功能和数据展现，C端采用Eclipse的RCP平台，共享服务器的业务接口，调用就采用HttpInvoker远程服务，复杂的业务功能都集中在C端上。