从幻灯片到彩色电视机Web开发技术的发展与推动

 

“我说的是，能让我们把湿衣服弄干的最好办法，是来个Web开发技术式的赛跑。”渡渡鸟说。“什么是Web开发技术式赛跑？”爱丽丝问。渡渡鸟说：“为了说明它，最好的办法就是咱们亲自做一做。”它划了圆圈，然后一大群家伙就在圈子内散乱地站着，“—，二，三，开始！”大家朝着自己选定的方向就开始跑起来，谁想停下，就停下，谁想改个方向就改个方向。跑了大约半个小时，衣服大体上都干了，渡渡鸟就突然喊道：“比赛结束了！”听到这话时，它们已散开很远了，有的是独自一个，有的是前前后后一堆，大家都拉长声音问：“谁——赢——了”。渡渡鸟说：“每人都赢了，而且都有奖品！”

Web开发技术的发展如同一场无规则赛跑，技术探索没有输家，无论采用哪种技术都有其积极意义，而赢家则是在某个方向上追随着最多而跑得最远的。比赛的终点线不是在比赛之初设定，而是随着比赛进程而形成并可能继续变化。

 

 

与软件后台所经历的大型机、C/S（客户机/服务器）、B/S（浏览器/服务器）架构三个阶段相对应，软件界面经历了字符界面、客户端程序、Web（浏览器）三个阶段。字符界面过于简陋，能表征的世界狭小。客户端程序以其用户体验（展现力与操作性）为利器，迅速占领了字符界面的领地，用户习惯也随即养成。当时认为客户端程序已是极致了，直到浏览器为前端的Web应用的出现。

图 1 ：用户界面发展趋势

 

Web应用的最大优势在于部署成本低，可以通过一个浏览器终端访问若干个后台应用，而无需为每个应用事先安装客户端程序。获得这种好处也付出了牺牲操作性和展现力的代价。不争的事实是，处理同样的业务，操作Web界面比客户端要慢很多，这实际上影响了工作效率。因而，Web开发技术从一开始就着力于解决用户体验这一问题。

CGI：通用网关接口（common gate interface），最早的Web应用技术。用于定Web服务器与外部程序之间通信方式的标准，使得外部程序能生成HTML、图像或者其他内容，因此CGI程序不仅能生成静态内容同时又能生成动态内容。

早期的CGI程序主要使用C或C++编写，由于开发太不方便，90年代末逐渐有了PHP、ASP、JSP这一类服务端动态脚本技术。

PHP、ASP、JSP相对于CGI的特点是将动态的逻辑代码嵌入在大量的输出文本中，而不是将大量的输出文本嵌入在逻辑代码中。大大减少了编程的工作量。PHP、ASP都是解释执行的脚本语言，而JSP是编译执行的。所以一般而言，JSP的执行期效率略高于前两者。

随着服务端逻辑复杂度的逐步提高PHP、ASP、JSP中的代码量开始急剧的增加，动态脚本不便于管理的弊端开始暴露。于是基于PHP、ASP、JSP的编程技术从以下两个方面开始分化。

1.     数据与展现的分离：随着主流浏览器开始支持CSS（Cascading Style Sheet级联样式单），出现了HTML+CSS的页面定义方式，这实现了初步的数据与展现的分离。但是HTML本身是非严谨的标记语言，并不适合用于描述数据。所以后来又有了XML+XSLT的页面定义方式，XML用于描述纯粹的数据，而XSLT（eXtensible Stylesheet Language）用于定义数据展现方式。

2.     展现与逻辑的分离：为了实现展现与逻辑分离，开始出现了ASP+COM、JSP+Bean的编程模式。其主旨是将主要的逻辑代码从页面中剥离出来，并封装为可重用的组件。这种开发模式也被成为Model1。随着Web应用复杂度的进一步提高，页面间的协作关系开始变得越来越复杂。于是又有了Model2的设计模式，Model2也被称为MVC，这期间涌现出了大量优秀的Web框架（Struts、WebWork等）。

以上这些技术都不能解决Web应用的交互性问题

Applet 和ActiveX是最早出现的用于改善Web应用交互性的技术。Java因Applet而一炮走红。但是Applet 和ActiveX与CS应用一样存在着部署和维护不便的弊端，因此在Web应用开发方面的使用并不普及。严格意义上讲也不算作Web应用的范畴。

JavaScript: 最早由Netscape引入浏览器，并使用它来控制网页中的DHTML(Dynamic HTML)对象。M$后来模仿JavaScript创造了VBScript（目前已基本绝迹）。JavaScript诞生的早期一直只被用于开发一些网页特效，虽然应用很广，但并没有成为Web应用开发中举足轻重的技术。

Flash: 随着Flash插件的普及。基于Flash的Web客户端开始出现，目前支持这一类开发的框架主要有Flex和Lazslo。尽管Flash Client的效果非常绚丽，但是Flash插件和浏览器在结合上不及JavaScript自然，因此在AJAX出现之后已经收到了强烈的冲击。

“一头大猪与一头小猪在同一片土豆地里翻土豆吃。一天小猪问大猪：“我怎样吃饱呢？你土豆翻得多、啃得快。你吃一口抵得上我吃五口。”大猪说：“传说在山的那边有一块大得多的红薯地，如果你能忍饥挨饿找到那里，就可以独占那一片的红薯。”小猪困惑道：“你说你当年也是从另一块小得多的花生地找过来的。现在为什么不去呢？”

商业产品可能滥觞于一个创意，而到直正为市场所接受，其间需要各种资源的投入。这是一个“蝴蝶效应”加上“风厚而北冥之鲲化鹏”的故事。事实标准由厂商制定与维护，产业标准大多由非盈利性的标准化组织制定与维护。厂商或直接投资捐助，或派驻人员，或委托测试与起草等，与这些组织有着千丝万绥的联系，很多技术标准出自于厂商的实验室。厂商影响了这些技术标准的制定，再从竞争市场中通过技术标准壁垒等获得利润与技术声誉等回报。成熟产业关系如同原始森林般复杂多样而相互依存，本土软件业也正在成熟之中。

按厂商的盈利模式与主要客户对象的差异，可以大致分为三类，当然实际有所交叉。以企业客户为最终用户的代表是IBM与ORACLE，以个人消费者为最终用户的（可能通过企业采购）代表是微软，以软件开发者（通软件开发商采购）为最终用户的代表是Borland。第一类厂商的收费模式的基准是服务器的CPU数目，以IBM主打的软件平台产品为例：前后为OS/360（大型机操作系统1960年左右），DB2（数据库1970年左右），WebSphere Application Server（应用服务器2000年左右），WebSphere Process Server（BPEL流程引擎，包括对WebSphere Portal Server的支持，2006年），明显地由后向前层层推进，除Portal之外均是纯后台产品，其捐助项目如struts倒是对Web开发技术贡献良多。第二类厂商有界面开发的传统，其收费模式的基准是用户数目，通过既有装机基础推新产品新技术，通过新产品新技术巩固装机基础。Microsoft与Adobe对Web开发技术的项献都源于此思路。但这也削弱了浏览器的最初的价值——低部署成本。第三类厂商的收模模式的基准是开发者数量，但eclipse模式的出现使第三类厂商的生存与发展面临新的挑战与机遇，曾在C/S开发技术上创造辉煌的Delphi，迟迟没有出现在B/S领域中。

现阶段的Web开发技术是以技术为主，而不是以平台为主。平台的出现标志技术趋于成熟。比如对数据的管理可以自己编一个数据结构，通过自己写的函数进行增查改删，也可以基于某种数据库产品，通过SQL标准语言操作，前者是技术，后者是平台。在平台成熟之前，编写这样的数据结构与函数是有意义的，也存在大量拥有这种技能的程序员，而掌握SQL的则较少；在平台成熟之后，前述技能的价值迅速折减，程序员不再积累这种技能，转而学习基于平台的技能如SQL，懂得自行开发类数据库的程序员少，懂得操作数据库的程序员多。现在Web开发程序员的技术储备构成非常类似于数据库未成熟之时。

Fact Became History, History Became Legend, and Legend Became Myth.过去的新技术变成现在的标准，又会成为未来遗产。现在以页面频繁刷新的Web开发技术，如同幻灯片一般，在彩色电视机（RIA，Rich Internet Application富互联网应用）出现之后会收缩到一个很小的领域。而表现层的中间件平台——展现中间件便是RIA的核心。其特点应是： 1，在保持低部署成本的前提下，降低开发复杂性，提高开发速度。 2，提高系统可用性，支持比拟于C/S的操作效率与展现能力。 3，平台式产品并有相应的技术标准。

在C/S时代，Delphi+数据库+WINDOWS平台构成了一个快速开发的完整架构，到B/S时代，却找不到支持Web应用快速开发的完整架构，其间出现了某个分层的缺失。

展现中间件的出现填补了这一空白，展现中间件 + 后台业务逻辑框架 + 应用服务器 + 数据库，形成了完整的支持Web应用快速开发的架构。其中后台业务逻辑框架可以为struts、webwork、spring、Hibernate、iBatis、WfMC标准的工作流引擎、BPEL标准的流程引擎、软件开发商自有框架等的一种或数种组成。如此就打通了Web快速开发的最后一关。

在此之后这套平台组合将走向融合。展现中间件起步晚，比起与行业经验密切关联业务逻辑中间件更易于抽象剥离出来，而成为纯标准技术平台。那时的应用服务器将在提供分布式资源的调配、基于交易的操作的基础上增加业务对象建模、流程建模与默认展现等新能力，软件的开发也会进入更准确更快捷的时代。可能到那时，人人可以说“In my spare time, I design Web Applications.”