Skip to end of metadata
Go to start of metadata

从幻灯片到彩色电视机
——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."

Labels
  • No labels