1、B/S，C/S 架构混合使用一般而言，我们平常接触的大多数项目都应该是单纯使用 B/S 或是 C/S，除非在特殊场合，否则比较少混合使用 B/S，C/S 架构。首先说一下对这二种架构特点的一些个人理解。B/S 应该是目前很多项目都应 用的架构， 浏览器的方式使得用户的使用十分方便，用户 可以何时何地通过 Internet 访问 URL 而进行相应的工作，升级维护也能比较集中，缺点就是浏览器的表 现能力受限以及常常受非议的安全性问题，如果软件的 应用范围区域不集中，而且用户经常变换地点进行访问，那么 这种架构是非常适合的。C/S 架构的 C 端有非常 强的处理能力，所以在交互表现和安全方面可以做
2、得比浏览器强，但是缺点也是非常明显的，安装部署、升级维护、版本兼容都是比 较头大的事情，一般的适用场景是集中的办公室场所，用户使用范围相对稳定，以及一些对业务处理非常复杂的场合，为了降低服务器的负荷，同 样需要 C 模式的支持。以前接触过的电信领域，就有过混合架构的软件。但是都是非常宠大，一直都对其实现方案比较感兴趣，但是都没有机会进一步了解。最近搜索了一下相关的资料， 总结一下混合应用的一些想法（只针对 Java 方向）。混合架构的 问题集中点。服务端共享，客 户端采用不同的表现方式，共享的应该是业务层接口，持久 层应该是屏蔽的。 应用层 的消息传递就是整个应用的关键所在， 虽然像 Jaka
3、rta 提供的 httpClient 这种模仿浏览器的组件，但是毕竟是模仿，在很多方面的功能还 是缺失的。最传统 的方式是采用 EJB 做为服务，这个宠 然大物容易让人害怕，不过在分布式的系统中它还是有应用优势的，像电信和金融这种行业应用还是比较广的，而且现成的中间件和应 用服务器商都比较多，像 Oracel、BEA、IBM、Sun 都有成熟的应用产品，当然开发的成本和人力投入也是恐龙级数据的。有网友 说在 C 端直接访问数据库，B/S 结构不变，也就是通过数据库进行共享。这种方式是不可取的，二个缺点：把服 务器的业务逻辑搬到了 C 端上， 严格上讲是不安全的，升级维护也非常麻烦；并发控制的压
4、力都在数据库上。采用 RMI，这个老古董相信应该很多人都不使用了，因为它的使用要一连串的手续，比如服务接口定义必须实现 Remote 接口，服务 Server 在实现时必须继承 UnicastRemoteobject 类，必 须使用 rmic 指令产生 stub 和 skeleton 等，设置上繁杂。Spring 远程服务。这个应该说是比较可取的，大家都比较喜欢轻量级的东西。就如第一点所说的，通过远程服务，我们可以在客 户直接调用服务端的服务接口，就像本地调用一样，Spring 对远程服务提供了好几种 实现方案。WebService。适合异构环境，但是 WSDL 的这种方式相对来说会比较耗费资
5、料，因为标准定义除了业务内容外， 还有许多另外的说明内容。Spring 远程服务实现方案介绍：Spring + RMI。Spring 把传统的 RMI 方式的繁 杂设置去掉，只要配置 Bean文件就和定义服务接口可以。RMI 的服务启动和管理都交给 Spring 来处理。RMI访问的缺点就是对防火墙的穿透力比较差。Spring + Caucho 的 Hessian、Burlap。Hessian 使用 Http 将对象以中性的二进制消息进行传送，而不像 RMI 使用 Java 的序列化格式（这种序列化是专制的，不是 Sun 提供的序列化机制），由于是二 进制消息，所以不受限于某种实现语言，传输时
6、所需要的带宽较小是其优点。Burlap 是以 XML 文件格式传送对象，XML文件有较高可读性，应用程序只要能解释 XML 就能接收消息，当然也不限于某种语言，但是组装 XML 和解 释 XML 都需要消耗资源，当传输大数据时性能应该存在问题。Spring + Http Invoker。由于 Hessian 的序列化机制不是正统的 Java 序列化机制，所以当遇到传输复杂的业务模型时，就会存在各种问题， 为此，Spring 又提供了 Http Invoker，同样是使用 Http 传送对象，而且是使用 Java 的序列化机制。相比 RMI，Http 对防火墙 的穿透力要强。后来尝试了最后的这种
7、 Http Invoker 方式，是在 Spring2.0 版本下尝试的，开发非常简单，网上也有大量的资料介绍。 应该说从这里入口可以做一些尝试。目前遇到的一个项目就需要混合架构，B/S 采用 Spring2 + Struts2 + Hiberntae3，浏览器只提供一些查询功能和数据展现，C 端采用 Eclipse 的 RCP 平台，共享服务器的业务接口，调用就采用 Http Invoker 远程服务，复杂的业务功能都集中在 C端上。以前也做过很多这处 C/S 和 B/S 混合的项目。但有些客户端使用的不是java。当然，服 务端也非得使用象 EJB 一样的重量级组 件。如我做过的一个系统C
8、/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 可以解决客户端自动升级的问题，两年前我们公司一个项目采用这种方式客户就非常喜欢，客户又感受到
9、了传统 C/S 应用的用户体验，而且没有升级麻烦，只局限在局域网中使用等待一系列问题。楼主担心的 问题 10 行代码就可以搞定（http:/ 展 SimpleHttpInvokerRequestExecutor 的openConnection（）方法把客 户端的信息（登录用户，客户端选择的 locale 等）加到URL 后面，在服务器端写一个 filter 把这些信息取出来放到 threadlocal 中，在Service 中不就可以随便用了吗， httpinvoker 本身就是无状态的，干嘛非把httpSession 牵 扯进来，想法就没对。其实这种架构最麻烦的莫过于界面的开发，在我们原来的
10、项目中一会儿客户想要一个可以翻页的表格，过 几天他又想点击表头可以排序，单列排序他又不满足了他又想多列排序，表格搞得差不多了表单又来了，Swing 的布局管理非常灵活，要做好一个表单真得费一番劲，而且客户总喜欢把他们用 VB，delphi 做的系统拿来跟你比，说你界面丑陋啦，日期输入不人性化啦 .，用 struts2 半天就可以搞定的一个表单用 Swing 恁是搞了一个星期，写界面的痛苦啊。总之，Swing 的界面开发是个大麻烦，项目完了以后将一些可重用的组件整理了一下，但还是发现界面代码一大堆，极难维护 ，后来的 项目只要客户说 C/S，我们也绝口不提 C/S。后来在 javaeye 首页上看到一家公司的富客户端解决方案的广告，进去看了看第一感触就是这个框架的作者当时绝对和我一样痛苦过，只不过他痛定思痛走的更远了一些，能够把控件封装起来，把项目中常见的问题在框架中一并解决了，现在只是感叹如果这个框架能在两年前出现那该有多好啊！
