前几天看到了“ XMLHTTP 做表示层开发的探讨”这个文章，引发了很多对于下一代B/S技术的思考。所以几天在这里和大家做一些自己的心得分享。
我认为B/S与C/S的本质不同在于HTML，在B/S世界，HTML是client与server的一种通用语言，就好象SQL是数据库client与RDBMS的通用语言一样，B/S的客户端界面逻辑是完全由服务器动态组织并传递给客户端的，产生这些界面逻辑的程序跟数据都存在于服务端，当应用需求变化的时候，并不会影响B/S的通讯接口，所有的变化都只需要更改服务器端的软件即可。
正如dlee所言，采用类似XMLHTTP这种方式开发的B/S，实质上已经是C/S结构了，此时的客户端实际上是一个rich client，由于rich client在用户体验上与桌面应用几乎相同，所以会带给用户体验上的极大改善，但是这种“进步”实际上并非新的东西，JAVA的APPLET如果与RMI结合起来与这种方式实际上是等同的，大家都是“浏览器内嵌Rich client+远程调用”的方式，然而为什么APPLET很早就出现了却没有流行起来，反到让其他的内嵌技术（activX, flash等）后来居上呢？这里有很多历史原因和非技术因素，没有必要多谈，但是我想说的是我仍然愿意把Rich client + XMLHTTP（也包括SOAP）看做一种历史技术(applet + rmi)的翻版，他们并无本质的区别，当然请不要说RMI不是OVER HTTP的这样的话，那不是本质区别，而且也有RMI/HTTP的技术，他们本质都是远程调用。
既然本质上XMLHTTP不是新的技术，既然这种C/S模式曾经被B/S模式取代，那我们现在为什么又要回过头来采用C/S呢？C/S与B/S的本质区别又在哪里？也许有人会说B/S与C/S的本质区别在于B/S不要求客户安装任何程序可以随时随地的使用服务，而且不受操作系统限制，我想说那也许是B/S得以迅速发展的原因，但不是B/S与C/S的本质区别，否则APPLET也可以做到不要求客户安装任何程序可以随时随地的使用服务，而且不受操作系统限制，但很明显APPLET是C/S而不是B/S。
如果采用C/S + 任何一种远程调用，就意味着你必须定义远程调用接口，无论是RMI还是XMLHTTP还是SOAP，都需要这种依赖于应用的定义，而这种定义本身就是比较困难的事情，如果只是做一些简单的控制接口（如starup, shutdown）之类的还比较容易，但是数据库操作的应用接口就很难定义了，即使定义出来也很难适应需求的变化，除非你把接口定义成传递SQL，呵呵，那就跟PB，DELPHI一样了，但是PB，DELPHI人家已经帮你把这个统一接口做好了，你要自己用RMI或XMLHTTP去做不是也很麻烦吗？
总结：
从这个意义上讲，用B/S（我指的是HTML模式的B/S，不包括内嵌应用的那种B/S），也许还有它的价值，它的价值就在于HTML这种以不变应万变的统一接口，如果用XMLHTTP，即使它还在浏览器里面，它实际上已经是传统的C/S了，除了界面体验的改观（这种“改观”实际上应该是往C/S的“复古”），你能期望它给你带来什么新的开发模式的价值吗？
本文来自：ITEYE软件开发交流社区
