对所谓“下一代B/S技术”的思考，欢迎讨论

看了dlee写的关于基于 XMLHTTP 做表示层开发的探讨 一文，本人也想发表一点意见。

正如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。

我认为B/S与C/S的本质不同在于HTML，在B/S世界，HTML是client与server的一种通用语言，就好象SQL是数据库client与RDBMS的通用语言一样，B/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的“复古”），你能期望它给你带来什么新的开发模式的价值吗？

这个问题我想了很久，也困惑了很久，欢迎拍砖，呵呵！

这里需要更加详细的分析。

1、服务器端生成的HTML里，只有HTML，没有JavaScript。
2、有JavaScript，但是只控制界面元素
3、不但控制界面元素，而且写Cookie
4、不但控制界面元素，而且包含调用后台页面的逻辑(form.action='XXXX.jsp'之类)
5、包含调用后台程序的逻辑（不只是设置跳转的页面，也包括取得数据）
你认为纯粹的B/S的界限在哪里？

Applet没有发展起来，我不去理会那些非技术因素，就论技术因素它也有足够的理由被淘汰。

体积太大，客户端加载缓慢。
一般来说，界面还是比较丑陋的（加载的时候先出来一块灰色的，实在难看），而且和页面融合度也不高。
并不是所有的用户在浏览器中都愿意安装javaplugin。

就以上几条足以让我放弃在页面中嵌入applet。


我不认为xmlhttp能归结于CS模式，但从不需要安装客户端软件，就应该划分到bs一类，与传统bs不同的是，它能够实现页面的局部与server通信。这便是它强于普通的bs的地方，如果不是js编写代码比较麻烦（诸如调试，测试不方便），我会尽可能多的使用xmlhttp却代原有的bs的代码。



。。。我不太明白使用，xmlhttp需要定义什么接口。客户端只是从服务端取得一个xml对象，并那来在页面上处理而已，我不认为非常困难－或许是我的应用太简单把。而且这种模式将得到数据和显示数据分离的非常完整。




xmlhttp绝对不是cs的复古，反而是cs和bs优点的结合。而且xmlhttp对于机器而言，和html毫无区别，它只是通过http协议传递的文本，只不过这些文本的内容是xml格式，为什么要把它理解成另外一种接口？

再说，界面上的改观对于用户来说就是最重要的改观（偏激了一点），也是最直接改观。
问问很多windows用户，他们从95到98到2000主要所能感受到的是什么？

带来的价值，不好说是开发模式上的。这只是一项技术而已。

APPLET体积大吗，我看FLASH体积更大，造成这种印象是因为早期的网络带宽很小，所以大家认为APPLET体积大，这不是非技术因素吗？至于界面美丑那是SUN没做好，而且后来的SWING也还可以，另外还有SWT啊，Javaplugin按理说应该是操作系统自带的，也属于非技术因素啊，当然，我认为APPLET本来可以发展很好的，比如APPLET做矢量动画的话还会有今天的FLASH吗？可是今天我们看到FLASH不仅仅做动画也要做成应用程序，FLASH把JAVA灭了，实在是SUN自己不争气，也是非技术因素啊，要说思想的话，我不认为FLASH应用和APPLET有本质区别，这种远程下载运行的思想就是SUN的，可惜都被别人抢去了。



如果这样讲的话，APPLET早就可以局部与SERVER通信了，XMLHTTP也不是什么新的东西啊。你这种对B/S和C/S的划分观点我前面已经谈过了，如果仅仅按照是否在浏览器内来分，那连微软将来的操作系统可能都是B/S，这是从用户使用角度来看的，但是从技术原理和开发模式上看，XMLHTTP确实应该属于C/S。


这个XML对象就是你定义的接口啊，一旦需求变化你就得定义一个新的XML对象，如果你用SOAP的话就应该明白了，实际上就是远程调用的参数发生变化，这种模式确实对显示和数据分离得很好，但同时却将数据传递的接口与应用需求绑定了，除非你直接传SQL，:)


对HTML来说，浏览器可以直接解释显示，而XMLHTTP还需要你开发Rich client来组织数据显示啊。（不过老实说我不了解XMLHTTP具体怎么用，我仅仅理解成跟SOAP一类的，不知道对不对？）



我没有说用户体验不重要，但这不是“改观”，而是“复古”，因为C/S模式的用户体验就已经很好了不是吗？只不过我们抛弃了C/S转向B/S，现在又回到C/S而已。

应该说这是B/S模式的重要特性也是得以发展的原因，但不是B/S与C/S的本质区别，否则APPLET也可以算B/S，但你觉得APPLET和HTML开发是一回事吗？


这一点没有什么，你做C/S也可以让通讯协议OVER HTTP走80端口啊，QQ就是这样做的。


主要还是APPLET生得太早，是个早产儿。

相同功能的话，applet大。丑我就不说了，至于说它是早产的话，应该说早产比晚产有优势，不过sun搞不定micromedia罢了。


这项功能上，的确不是新的，正是因为想保留applet这个优点，才出现了这个东西嘛－当然还有其他产生原因。


这个无所谓，怎么分都好。


我不喜欢用soap，麻烦。xmlrpc就是一个简单的soap实现，据说可以支持更多的浏览器，但当时我在xmlhttp和xmlrpc之间就选择了前者，理由就是方便，我是个懒人。

HTML来说，浏览器可以直接解释显示，而XMLHTTP还需要你开发Rich client来组织数据显示啊。

是啊，而且js我又不熟悉，加上不好调试和测试，真是抓狂。。。。。


那我觉得你可以写一个简单的例子，具体体会一下，那样感受会真切一些。
我简单的理解是，和soap干同样的活，但比soap简单－－或许soap能干更复杂的活把。

B/S和C/S的区别真的只在客户端上么？我想他们的本质区别不在于叫什么、客户端使用了哪一种技术，而是是否有Web App或者其它的服务器组件作为中间层。
Brows是浏览的意思，难道就一定非限定到IE, Navigator上面。我自己做浏览器行不？

OK，看来我还表述不够清楚，大家没有明白我真正想讨论的问题，我并不想说B/S与C/S谁好谁坏的问题，我想说明的是“浏览器内嵌Rich client + 某种远程调用”这种应用模式并不是什么新的模式，如果大家认为B/S就是跨平台和无需安装客户端的话，那JAVA APPLICATION早就可以跨平台了，而APPLET也早就跨平台并无需安装客户端了，我真正想和大家讨论的是为什么这种模式在早期没有得到认可，而现在有被别的技术推崇起来？仅仅是因为APPLET本身的问题呢还是因为这种模式有问题？

我们没有必要执着于B/S与C/S的定义，我只想从开发角度来看“浏览器内嵌Rich client + 某种远程调用”的模式与C/S是等同的，这一点总不可否认吧？那我关心的是为什么早期人们对这种应用视而不见，纷纷投向HTML模式的B/S怀抱，然后现在又拿着另一个雷同的东西当作一个新的宝贝？到底是仅仅因为某些具体技术细节的发展呢还是对这种开发模式的认同回归，如果是后者的话那我们就必须比较两种开发模式（即HTML模式和Rich client模式(不管是否嵌入浏览器)）的内涵差异，那就会引出我前面发的话题来，请大家替我解惑！

从结果上看确实是一种模式的回归，我想可能是有以下几个原因：

从环境上讲，我们国内web应用是在互联网高峰期开始的，那时候的应用基本很少涉及到企业的管理应用软件，实际上两种类型的软件开发模式是不同的。企业应用软件的合理模式我认为还是C/S，当时使用这种模式进行Web开发，主流还是applet，我看了一些国外的企业管理软件产品，也都是applet为主，和国内的不同，可能是因为我们的技术套路很多还是以前做互联网时的思想，有经验的很多都是那个年代出来的，可是算算能有几年？在对web的应用开发上，我们往往不能跳出站点开发的思路。

从技术上讲，我以前不用applet的原因有两条：一则开发过程让我痛苦，我很害怕学习界面编程技术，而且开发工具不能做到象PB数据窗口那样的水准，很多东西要学，做界面程序和做业务程序是完全不同的思路，我不想浪费时间做这个工作（性能问题，只不过是因为技术能力不够，找个借口说说而已，做的好的速度也很快，再说是企业网里面带宽高着呢）；二则是商务方面，MS在浏览器中对JAVA一直没有明确的表示支持，而MS在浏览器的垄断地位，很难保证它对applet能够支持得很好，做个什么手脚，出了问题，怎么解决都不知道。

在以前没有用xmlhttp的时候，只能用标准的mvc方式进行开发，说起来还是要感谢MS，如果没有它大力推它的xml技术和web service，我们也没有什么好的办法来解决C/S模式的web开发。

所以我认为模式的回归也是一种自然形成的结果，存在就是合理，对applet我不是很看好，因为如果要用浏览器，MS的态度和技术在这段时间内将决定你采用什么客户端技术。

你的解释有一定的道理，但如果仅仅是这样的话，这种回归有什么价值吗？换句话说，B/S的核心价值在哪里？C/S的核心价值又在哪里？我认为他们的区别绝对不是用不用安装客户端跨平台地随意使用的问题，因为那样的话B/S和浏览器内嵌的C/S都能做到，所以我觉得B/S的核心价值就在于HTML，而C/S的核心价值在于丰富的表现方式和无需每次向服务器索取界面，而他们的优点正是对方的缺点。

所以在看到这种历史回归现象的时候，我们期望的是什么？应该是回归的后的缺点被解决掉，那才有意义，这就要求XMLHTTP或者其他任何远程调用不仅仅是提供一个远程调用的功能，还必须提供类似SQL或者CMIP这样的原始的数据操作功能，而不能期望所有的数据传递都依靠依赖于具体应用的远程调用来解决，问题是XMLHTTP能吗？