B/S，C/S架构混合使用

一般而言，我们平常接触的大多数项目都应该是单纯使用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 + Http Invoker。由于Hessian的序列化机制不是正统的Java序列化机制，所以当遇到传输复杂的业务模型时，就会存在各种问题，为此，Spring又提供了Http Invoker，同样是使用Http传送对象，而且是使用Java的序列化机制。相比RMI，Http对防火墙的穿透力要强。
    后来尝试了最后的这种Http Invoker方式，是在Spring2.0版本下尝试的，开发非常简单，网上也有大量的资料介绍。应该说从这里入口可以做一些尝试。目前遇到的一个项目就需要混合架构，B/S采用Spring2 + Struts2 + Hiberntae3，浏览器只提供一些查询功能和数据展现，C端采用Eclipse的RCP平台，共享服务器的业务接口，调用就采用Http Invoker远程服务，复杂的业务功能都集中在C端上。

 

 

 

以前也做过很多这处C/S和B/S混合的项目。但有些客户端使用的不是java。当然，服务端也非得使用象EJB一样的重量级组件。如我做过的一个系统C/S部分的客户端使用的是delphi，而服务端只是普通的jsp/servlet程序，也未使用web service，而是通过servlet来为C/S部分的客户端（delphi客户端）返回数据(也包括一些加密数据），而客户端通过http协议访问servlet。当然，B/S部分的还是jsp。这样实现个人感觉比较简单。

 

 

运用Swing+http invoker+spring+hibernate开发C/S架构的系统从技术上没有难度，而且java web start可以解决客户端自动升级的问题，两年前我们公司一个项目采用这种方式客户就非常喜欢，客户又感受到了传统C/S应用的用户体验，而且没有升级麻烦，只局限在局域网中使用等待一系列问题。楼主担心的问题10行代码就可以搞定（http://www.javaeye.com/topic/82492，这么笨的方法也亏这个人想的出来），首先扩展SimpleHttpInvokerRequestExecutor的openConnection（）方法把客户端的信息（登录用户，客户端选择的locale等）加到URL后面，在服务器端写一个filter把这些信息取出来放到threadlocal中，在Service中不就可以随便用了吗，httpinvoker本身就是无状态的，干嘛非把httpSession牵扯进来，想法就没对。

其实这种架构最麻烦的莫过于界面的开发，在我们原来的项目中一会儿客户想要一个可以翻页的表格，过几天他又想点击表头可以排序，单列排序他又不满足了他又想多列排序，表格搞得差不多了表单又来了，Swing的布局管理非常灵活，要做好一个表单真得费一番劲，而且客户总喜欢把他们用VB，delphi做的系统拿来跟你比，说你界面丑陋啦，日期输入不人性化啦...，用struts2半天就可以搞定的一个表单用Swing恁是搞了一个星期，写界面的痛苦啊。总之，Swing的界面开发是个大麻烦，项目完了以后将一些可重用的组件整理了一下，但还是发现界面代码一大堆，极难维护，后来的项目只要客户说C/S，我们也绝口不提C/S。

后来在javaeye首页上看到一家公司的富客户端解决方案的广告，进去看了看第一感触就是这个框架的作者当时绝对和我一样痛苦过，只不过他痛定思痛走的更远了一些，能够把控件封装起来，把项目中常见的问题在框架中一并解决了，现在只是感叹如果这个框架能在两年前出现那该有多好啊！