﻿<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>BlogJava-阳光地带-随笔分类-参考资料</title><link>http://www.blogjava.net/yiqi801218/category/29897.html</link><description>Java版</description><language>zh-cn</language><lastBuildDate>Thu, 01 May 2008 14:20:47 GMT</lastBuildDate><pubDate>Thu, 01 May 2008 14:20:47 GMT</pubDate><ttl>60</ttl><item><title>jstl 入门，就是 c:if , c:forEach 这些 tag，写得很不错</title><link>http://www.blogjava.net/yiqi801218/archive/2008/05/01/197668.html</link><dc:creator>BlueSunshine</dc:creator><author>BlueSunshine</author><pubDate>Thu, 01 May 2008 11:57:00 GMT</pubDate><guid>http://www.blogjava.net/yiqi801218/archive/2008/05/01/197668.html</guid><wfw:comment>http://www.blogjava.net/yiqi801218/comments/197668.html</wfw:comment><comments>http://www.blogjava.net/yiqi801218/archive/2008/05/01/197668.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/yiqi801218/comments/commentRss/197668.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/yiqi801218/services/trackbacks/197668.html</trackback:ping><description><![CDATA[JSTL 入门: 表达式语言
通过避免使用脚本编制元素来简化对 JSP 应用程序的软件维护
文档选项
 
 将此页作为电子邮件发送



级别： 初级
Mark A. Kolb (mak@taglib.com), 软件工程师

2003 年 5 月 27 日
JSP 标准标记库（JSP Standard Tag Library，JSTL）是一个实现 Web 应用程序中常见的通用功能的定制标记库集，这些功能包括迭代和条件判断、数据管理格式化、XML 操作以及数据库访问。在 developerWorks 上其新系列的第一篇文章中，软件工程师 Mark Kolb 向您展示了如何使用 JSTL 标记来避免在 JSP 页面中使用脚本编制元素。您还将了解如何通过从表示层删除源代码来简化软件维护。最后，您将了解 JSTL 经过简化的表达式语言，它允许在不必使用功能齐全的编程语言的情况下对 JSTL 操作指定动态属性值。
JavaServer Pages（JSP）是用于 J2EE 平台的标准表示层技术。JSP 技术提供了用于执行计算（这些计算用来动态地生成页面内容）的脚本编制元素和操作。脚本编制元素允许在 JSP 页面中包括程序源代码，在为响应用户请求而呈现页面时可以执行这些源代码。操作将计算操作封装到很象 HTML 或 XML 标记的标记中，JSP 页面的模板文本通常包含这些标记。JSP 规范只将几种操作定义成了标准，但从 JSP 1.1 开始，开发人员已经能够以定制标记库的方式创建其自己的操作了。
JSP 标准标记库（JSTL）是 JSP 1.2 定制标记库集，这些标记库实现大量服务器端 Java 应用程序常用的基本功能。通过为典型表示层任务（如数据格式化和迭代或条件内容）提供标准实现，JSTL 使 JSP 作者可以专注于特定于应用程序的开发需求，而不是为这些通用操作&#8220;另起炉灶&#8221;。
当然，您可以使用 JSP 脚本编制元素（scriptlet、表达式和声明）来实现此类任务。例如，可以使用三个 scriptlet 实现条件内容，清单 1 中着重显示了这三个 scriptlet。但是，因为脚本编制元素依赖于在页面中嵌入程序源代码（通常是 Java 代码），所以对于使用这些脚本编制元素的 JSP 页面，其软件维护任务的复杂度大大增加了。例如，清单 1 中的 scriptlet 示例严格地依赖于花括号的正确匹配。如果不经意间引入了一个语法错误，则条件内容中的嵌套其它 scriptlet 可能会造成严重破坏，并且在 JSP 容器编译该页面时，要使所产生的错误信息有意义可能会很困难。

清单 1. 通过 scriptlet 实现条件内容
<% if (user.getRole() == "member")) { %>
    <p>Welcome, member!</p>
<% } else { %>
    <p>Welcome, guest!</p>
<% } %>



修正此类问题通常需要相当丰富的编程经验。尽管通常会由十分精通页面布局和图形设计的设计人员来开发和维护 JSP，但是同一页面中的脚本编制元素出现问题时，需要程序员的介入。这种状况将单个文件中代码的责任分担给多人，因而使得开发、调试和增强此类 JSP 页面成为很麻烦的任务。通过将常用功能包装到定制标记库的标准集合中，JSTL 使 JSP 作者可以减少对编制脚本元素的需求，甚至可以不需要它们，并避免了相关的维护成本。





回页首




JSTL 1.0
JSTL 1.0 发布于 2002 年 6 月，由四个定制标记库（ core 、 format 、 xml 和 sql ）和一对通用标记库验证器（ ScriptFreeTLV 和 PermittedTaglibsTLV ）组成。 core 标记库提供了定制操作，通过限制了作用域的变量管理数据，以及执行页面内容的迭代和条件操作。它还提供了用来生成和操作 URL 的标记。顾名思义， format 标记库定义了用来格式化数据（尤其是数字和日期）的操作。它还支持使用本地化资源束进行 JSP 页面的国际化。 xml 库包含一些标记，这些标记用来操作通过 XML 表示的数据，而 sql 库定义了用来查询关系数据库的操作。 
两个 JSTL 标记库验证器允许开发人员在其 JSP 应用程序中强制使用编码标准。可以配置 ScriptFreeTLV 验证器以在 JSP 页面中禁用各种类型的 JSP 脚本元素 ― scriptlet、表达式和声明。类似地， PermittedTaglibsTLV 验证器可以用来限制可能由应用程序的 JSP 页面访问的定制标记库集（包括 JSTL 标记库）。 
尽管 JSTL 最终将会成为 J2EE 平台的必需组件，但目前只有少数应用程序服务器包括它。JSTL 1.0 的参考实现可作为 Apache 软件基金会（Apache Software Foundation）的 Jakarta Taglibs 项目（请参阅 参考资料）的一部分而获得。可以将该参考实现中的定制标记库合并到任何支持 JSP 1.2 和 Servlet 2.3 规范的服务器，以添加对 JSTL 的支持。 





回页首




表达式语言
在 JSP 1.2 中，可以使用静态字符串或表达式（如果允许的话）指定 JSP 操作的属性。例如，在清单 2 中，对 <jsp:setProperty> 操作的 name 和 property 属性指定了静态值，而用表达式指定了其 value 属性。这个操作的效果是将请求参数的当前值赋予命名的 bean 特性。以这种形式使用的表达式被称为 请求时属性值（request-time attribute value），这是构建到 JSP 规范中的用于动态指定属性值的唯一机制。 

清单 2. 合并请求时属性值的 JSP 操作
<jsp:setProperty name="user" property="timezonePref"
                 value='<%= request.getParameter("timezone") %>'/>




因为请求时属性值是用表达式指定的，所以它们往往有和其它脚本元素一样的软件维护问题。因此，JSTL 定制标记支持另一种用于指定动态属性值的机制。可以用简化的 表达式语言（EL）而不使用完整的 JSP 表达式来指定 JSTL 操作的属性值。EL 提供了一些标识符、存取器和运算符，用来检索和操作驻留在 JSP 容器中的数据。EL 在某种程度上以 EcmaScript（请参阅 参考资料）和 XML 路径语言（XML Path Language，XPath）为基础，因此页面设计人员和程序员都应该熟悉它的语法。EL 擅长寻找对象及其特性，然后对它们执行简单操作；它不是编程语言，甚至不是脚本编制语言。但是，与 JSTL 标记一起使用时，它就能使用简单而又方便的符号来表示复杂的行为。EL 表达式的格式是这样的：用美元符号（$）定界，内容包括在花括号（{}）中，如清单 3 所示。 

清单 3. 说明 EL 表达式定界符的 JSTL 操作
<c:out value="${user.firstName}"/>




此外，您可以将多个表达式与静态文本组合在一起以通过字符串并置来构造动态属性值，如清单 4 所示。单独的表达式由标识符、存取器、文字和运算符组成。标识符用来引用存储在数据中心中的数据对象。EL 有 11 个保留标识符，对应于 11 个 EL 隐式对象。假定所有其它标识符都引用 限制了作用域的变量。存取器用来检索对象的特性或集合的元素。文字表示固定的值 ― 数字、字符、字符串、布尔型或空值。运算符允许对数据和文字进行组合以及比较。 

清单 4. 组合静态文本和多个 EL 表达式以指定动态属性值
<c:out value="Hello ${user.firstName} ${user.lastName}"/>








回页首




限制了作用域的变量
JSP API 通过 <jsp:useBean> 操作允许从 JSP 容器内的四个不同作用域中存储和检索数据。JSTL 通过提供用于指定和除去这些作用域中的对象的附加操作来扩展这一能力。此外，EL 提供将这些对象作为限制了作用域的变量进行检索的内置支持。特别地，任何出现在 EL 表达式中但不对应于任何 EL 隐式对象的标识符，都被自动假定为引用存储在四个 JSP 作用域的其中某个中的对象，这四个作用域是： 
页面作用域 
请求作用域 
会话作用域 
应用程序作用域 
您可能还记得，只有在为特定请求处理页面期间才能检索存储在该页面作用域中的对象。如果对象是存储在请求作用域中的，可以在处理所有参与处理某请求的页面期间检索这些对象（譬如在对某个请求的处理中遇到了一个或多个 <jsp:include> 或 <jsp:forward> 操作）。如果对象是存储在会话作用域中的，则在与 Web 应用程序的交互式会话期间，可以由用户访问的任何页面检索它（即，直到与该用户交互相关联的 HttpSession 对象无效为止）。可以由任何用户从任何页面访问存储在应用程序作用域中的对象，直到卸载 Web 应用程序本身为止（通常是由于关闭 JSP 容器所致）。 
通过将字符串映射为期望作用域中的对象来将对象存储到该作用域。然后，就可以通过提供相同字符串来从该作用域检索该对象。在作用域的映射中查找字符串，并返回被映射的对象。在 Servlet API 中，将此类对象称为相应作用域的 属性。但是，在 EL 的上下文中，也将与属性相关联的字符串看作变量的名称，该变量通过属性映射的方式获得特定的值。 
在 EL 中，与隐式对象无关联的标识符被认为是存储在四个 JSP 作用域中的名称对象。首先对页面作用域检查是否存在这样的标识符，其次对请求作用域、然后对会话作用域、最后对应用程序作用域依次进行这样的检查，然后测试该标识符的名称是否与存储在该作用域中的某个对象的名称匹配。第一个这样的匹配作为 EL 标识符的值被返回。通过这种方法，可以将 EL 标识符看作引用限制了作用域的变量。
从更技术的方面来说，没有映射到隐式对象的标识符是用 PageContext 实例的 findAttribute() 方法求值的，该实例表示对页面的处理，在该页面上，当前正在处理用于请求的表达式。标识符的名称作为参数传递给这个方法，然后该方法依次在四个作用域中搜索具有相同名称的属性。并将所找到的第一个匹配项作为 findAttribute() 方法的值返回。如果未在这四个作用域中找到这样的属性，则返回 null 。 
最终，限制了作用域的变量是四个 JSP 作用域的属性，这些属性具有可以用作 EL 标识符的名称。只要对限制了作用域的变量赋予由字母数字组成的名称，就可以通过 JSP 中提供的用于设置属性的任何机制来创建它们。这包括内置的 <jsp:useBean> 操作，以及由 Servlet API 中的几个类定义的 setAttribute() 方法。此外，四个 JSTL 库中定义的许多定制标记本身就能够设置作为限制了作用域的变量使用的属性值。 





回页首




隐式对象
表 1 中列出了 11 个 EL 隐式对象的标识符。不要将这些对象与 JSP 隐式对象（一共只有九个）混淆，其中只有一个对象是它们所共有的。
表 1. EL 隐式对象
类别 标识符 描述 
JSPpageContext PageContext 实例对应于当前页面的处理 
作用域pageScope 与页面作用域属性的名称和值相关联的 Map 类 
requestScope 与请求作用域属性的名称和值相关联的 Map 类 
sessionScope 与会话作用域属性的名称和值相关联的 Map 类 
applicationScope 与应用程序作用域属性的名称和值相关联的 Map 类 
请求参数param 按名称存储请求参数的主要值的 Map 类 
paramValues 将请求参数的所有值作为 String 数组存储的 Map 类 
请求头header 按名称存储请求头主要值的 Map 类 
headerValues 将请求头的所有值作为 String 数组存储的 Map 类 
Cookiecookie 按名称存储请求附带的 cookie 的 Map 类 
初始化参数initParam 按名称存储 Web 应用程序上下文初始化参数的 Map 类 

尽管 JSP 和 EL 隐式对象中只有一个公共对象（ pageContext ），但通过 EL 也可以访问其它 JSP 隐式对象。原因是 pageContext 拥有访问所有其它八个 JSP 隐式对象的特性。实际上，这是将它包括在 EL 隐式对象中的主要理由。 
其余所有 EL 隐式对象都是映射，可以用来查找对应于名称的对象。前四个映射表示先前讨论的各种属性作用域。可以用它们来查找特定作用域中的标识符，而不用依赖于 EL 在缺省情况下使用的顺序查找过程。
接下来的四个映射用来获取请求参数和请求头的值。因为 HTTP 协议允许请求参数和请求头具有多个值，所以它们各有一对映射。每对中的第一个映射返回请求参数或头的主要值，通常是恰巧在实际请求中首先指定的那个值。每对中第二个映射允许检索参数或头的所有值。这些映射中的键是参数或头的名称，但这些值是 String 对象的数组，其中的每个元素都是单一参数值或头值。 
cookie 隐式对象提供了对由请求设置的 cookie 名称的访问。这个对象将所有与请求相关联的 cookie 名称映射到表示那些 cookie 特性的 Cookie 对象。 
最后一个 EL 隐式对象 initParam 是一个映射，它储存与 Web 应用程序相关联的所有上下文的初始化参数的名称和值。初始化参数是通过 web.xml 部署描述符文件指定的，该文件位于应用程序的 WEB-INF 目录中。 





回页首




存取器
因为 EL 标识符是作为隐式对象或限制了作用域的变量（通过属性来实现）解析的，因此有必要将它们转换成 Java 对象。EL 可以自动包装和解包其相应的 Java 类中的基本类型（例如，可以在后台将 int 强制转换成 Integer 类，反之亦可），但大多数的标识符将成为指向完整的 Java 对象的指针。 
结果是，对这些对象的特性或（在对象是数组和集合的情况下）对其元素的访问通常是令人满意的。就为了实现这种用途，EL 提供了两种不同的存取器（点运算符（ . ）和方括号运算符（ [] ）），也支持通过 EL 操作特性和元素。 
点运算符通常用于访问对象的特性。例如，在表达式 ${user.firstName} 中，使用点运算符来访问 user 标识符所引用对象的名为 firstName 的特性。EL 使用 Java bean 约定访问对象特性，因此必须定义这个特性的 getter 方法（通常是名为 getFirstName() 的方法），以便表达式正确求值。当被访问的特性本身是对象时，可以递归地应用点运算符。例如，如果我们虚构的 user 对象有一个实现为 Java 对象的 address 特性，那么也可以用点运算符来访问这个对象的特性。例如，表达式 ${user.address.city} 将会返回这个地址对象嵌套的 city 特性。 
方括号运算符用来检索数组和集合的元素。在数组和有序集合（也即，实现了 java.util.List 接口的集合）的情况下，把要检索的元素的下标放在方括号中。例如，表达式 ${urls[3]} 返回 urls 标识符所引用的数组或集合的第四个元素（和 Java 语言以及 JavaScript 中一样，EL 中的下标是从零开始的）。 
对于实现 java.util.Map 接口的集合，方括号运算符使用关联的键查找存储在映射中的值。在方括号中指定键，并将相应的值作为表达式的值返回。例如，表达式 ${commands["dir"]} 返回与 commands 标识符所引用的 Map 中的 "dir" 键相关联的值。 
对于上述两种情况，都可允许表达式出现在方括号中。对嵌套表达式求值的结果将被作为下标或键，用来检索集合或数组的适当元素。和点运算符一样，方括号运算符也可以递归应用。这使得 EL 能够从多维数组、嵌套集合或两者的任意组合中检索元素。此外，点运算符和方括号运算符还可以互操作。例如，如果数组的元素本身是对象，则可以使用方括号运算符来检索该数组的元素，并结合点运算符来检索该元素的一个特性（例如 ${urls[3].protocol} ）。 
假定 EL 充当指定动态属性值的简化语言，EL 存取器有一个有趣的功能（与 Java 语言的存取器不同），那就是它们在应用于 null 时不抛出异常。如果应用 EL 存取器的对象（例如， ${foo.bar} 和 ${foo["bar"]} 中的 foo 标识符）是 null ，那么应用存取器的结果也是 null 。事实证明，在大多数情况下，这是一个相当有用的行为，不久您就会了解这一点。 
最后，点运算符和方括号运算符可能实现某种程度的互换。例如，也可以使用 ${user["firstName"]} 来检索 user 对象的 firstName 特性，正如可以用 ${commands.dir} 获取与 commands 映射中的 "dir" 键相关联的值一样。 





回页首




运算符
EL 还可以通过使用标识符和存取器，遍历包含应用程序数据（通过限制了作用域的变量公开）或关于环境的信息（通过 EL 隐式对象）的对象层次结构。但是，只是访问这些数据，通常不足以实现许多 JSP 应用程序所需的表示逻辑。
最终，EL 还包括了几个用来操作和比较 EL 表达式所访问数据的运算符。表 2 中汇总了这些运算符。
表 2. EL 运算符
类别 运算符 
算术运算符+ 、 - 、 * 、 / （或 div ）和 % （或 mod ） 
关系运算符== （或 eq ）、 != （或 ne ）、 < （或 lt ）、 > （或 gt ）、 <= （或 le ）和 >= （或 ge ） 
逻辑运算符&& （或 and ）、 || （或 or ）和 ! （或 not ） 
验证运算符empty 

算术运算符支持数值的加法、减法、乘法和除法。还提供了一个求余运算符。注：除法和求余运算符都有替代的、非符号的名称（为的是与 XPath 保持一致）。清单 5 中显示了一个演示算术运算符用法的示例表达式。对几个 EL 表达式应用算术运算符的结果是将该算术运算符应用于这些表达式返回的数值所得的结果。

清单 5. 利用算术运算符的 EL 表达式
${item.price * (1 + taxRate[user.address.zipcode])}




关系运算符允许比较数字或文本数据。比较的结果作为布尔值返回。逻辑运算符允许合并布尔值，返回新的布尔值。因此，可以将 EL 逻辑运算符应用于嵌套的关系或逻辑运算符的结果，如清单 6 所示。

清单 6. 利用关系和逻辑运算符的 EL 表达式
${(x >= min) && (x <= max)}




最后一种 EL 运算符是 empty ，它对于验证数据特别有用。 empty 运算符采用单个表达式作为其变量（也即， ${empty input} ），并返回一个布尔值，该布尔值表示对表达式求值的结果是不是&#8220;空&#8221;值。求值结果为 null 的表达式被认为是空，即无元素的集合或数组。如果参数是对长度为零的 String 求值所得的结果，则 empty 运算符也将返回 true 。 
表 3 显示了 EL 运算符的优先级。正如清单 5 和 6 所示，可以用圆括号对表达式分组，高于普通的优先级规则。
表 3. EL 运算符优先级（自顶到底，从左到右）
[] , . 
() 
unary - 、 not 、 ! 、 empty 
* 、 / 、 div 、 % 、 mod 
+ 、binary - 
() <</code> 、 > 、 <= 、 >= 、 lt 、 gt 、 le 、 ge 
== 、 != 、 eq 、 ne 
&& 、 and 
|| 、 or 






回页首




文字
在 EL 表达式中，数字、字符串、布尔值和 null 都可以被指定为文字值。字符串可以用单引号或双引号定界。布尔值被指定为 true 和 false 。 





回页首




Taglib 伪指令
正如我们先前讨论的，JSTL 1.0 包括四个定制标记库。为了演示 JSTL 标记和表达式语言的交互，我们将研究几个来自 JSTL core 库的标记。和使用任何 JSP 定制标记库一样，必须在您想要使用这个库标记的任何页面中包括 taglib 伪指令。清单 7 显示了用于这个特定库的伪指令。 

清单 7. 用于 JSTL core 库 EL 版本的 taglib 伪指令
<%@ taglib uri="http://java.sun.com/jstl/core" prefix="c" %>




实际上，对应于 JSTL core 库的 taglib 伪指令有两种，因为在 JSTL 1.0 中，EL 是可选的。所有四个 JSTL 1.0 定制标记库都有使用 JSP 表达式（而不是 EL）指定动态属性值的备用版本。因为这些备用库依赖于 JSP 的更传统的请求时属性值，所以它们被称为 RT库，而那些使用表达式语言的则被称为 EL 库。开发人员用不同的 taglib 伪指令来区分每个库的这两个版本。清单 8 显示了使用 core 库的 RT 版本的伪指令。但是，由于现在我们讨论的重点是 EL，所以首先需要这些伪指令。 

清单 8. 用于 JSTL core 库 RT 版本的 taglib 伪指令
<%@ taglib uri="http://java.sun.com/jstl/core_rt" prefix="c_rt" %>








回页首




变量标记
我们首先要考虑的 JSTL 定制标记是 <c:set> 操作。正如已经说明的，限制了作用域的变量在 JSTL 中起关键作用， <c:set> 操作提供基于标记的机制来创建和设置限制了作用域的变量。清单 9 中显示了该操作的语法，其中 var 属性指定了限制了作用域的变量的名称， scope 属性表明了该变量驻留在哪个作用域中， value 属性指定了分配给该变量的值。如果指定变量已经存在，则简单地将所指明的值赋给它。如果不存在，则创建新的限制了作用域的变量，并用该值初始化这个变量。 

清单 9. <c:set> 操作的语法
<c:set var="
        name" scope="
        scope" value="
        expression"/>
      



scope 属性是可选的，其缺省值是 page 。 
清单 10 中显示了 <c:set> 的两个示例。在第一个示例中，将会话作用域变量设置成 String 值。在第二个示例中，用表达式来设置数值：将页面作用域内名为 square 的变量赋值为名为 x 的请求参数的值的平方。 

清单 10. <c:set> 操作示例
<c:set var="timezone" scope="session" value="CST"/>
<c:set var="square" value="${param['x'] * param['x']}"/>




您还可以将限制了作用域的变量的值指定为 <c:set> 操作的主体内容，而不是使用属性。使用这种方法，您可以重新编写清单 10 中的第一个示例，如清单 11 所示。此外，正如我们马上可以看到的， <c:set> 标记的主体内容本身也可以使用定制标记。 <c:set> 主体内生成的所有内容都将作为一个 String 值赋给指定变量。 

清单 11. 通过主体内容指定 <c:set> 操作的值
<c:set var="timezone" scope="session">CST</c:set>




JSTL core 库包含第二个用于管理限制了作用域的变量的标记 ― <c:remove> 。顾名思义， <c:remove> 操作是用来删除限制了作用域的变量的，它获取两个属性。 var 属性指定待删除变量的名称， scope 属性是可选的，它表示待删除变量来自哪个作用域，缺省为 page ，如清单 12 所示。 
清单 12. <c:remove> 操作示例 <c:remove var="timezone" scope="session"/>








回页首




输出
尽管 <c:set> 操作允许将表达式结果赋给限制了作用域的变量，但开发人员通常会希望只显示表达式的值，而不存储它。JSTL <c:out> 定制标记承担这一任务，其语法如清单 13 所示。该标记对由其 value 属性指定的表达式进行求值，然后打印结果。如果指定了可选属性 default ，那么，在对 value 属性的表达式求值所得结果为 null 或空 String 的情况下， <c:out> 将打印其值。 

清单 13. <c:out> 操作的语法
<c:out value="
        expression" default="
        expression" escapeXml="
        boolean"/>
      



escapeXml 属性也是可选的。它控制当用 <c:out> 标记输出诸如&#8220;<&#8221;、&#8220;>&#8221;和&#8220;&&#8221;之类的字符（在 HTML 和 XML 中具有特殊意义）时是否应该进行转义。如果将 escapeXml 设置为 true，则会自动将这些字符转换成相应的 XML 实体（此处提到的字符分别转换成 < 、 > 和 & ）。 
例如，假定有一个名为 user 的会话作用域变量，它是一个类的实例，该类为用户定义了两个特性： username 和 company 。每当用户访问站点时，这个对象被自动分配给会话，但直到用户实际登录后，才会设置这两个特性。假定是这种方案，请考虑清单 14 中的 JSP 片段。在用户登录之后，这个片段将显示单词&#8220;Hello&#8221;，其后是他／她的用户名和一个惊叹号。但是，在用户登录之前，由这个片段生成的内容则是短语&#8220;Hello Guest!&#8221;。在这种情况下，因为 username 特性还有待初始化，所以 <c:out> 标记将转而打印出 default 属性的值（即字符串&#8220;Guest&#8221;）。 

清单 14. 带缺省内容的 <c:out> 操作示例
Hello <c:out value="${user.username}" default=="Guest"/>!




接下来，考虑清单 15，它使用了 <c:out> 标记的 escapeXml 属性。如果在这种情况下已经将 company 特性设置成 Java String 值 "Flynn & Sons" ，那么，实际上该操作生成的内容将是 Flynn & Sons 。如果这个操作是生成 HTML 或 XML 内容的 JSP 页面的一部分，那么，这个字符串中间的&#8220;&&#8221;符号最终可能被解释为 HTML 或 XML 控制字符，从而妨碍了对该内容的显示或解析。但是，如果将 escapeXml 属性值设置成 true ，则所生成的内容将是 Flynn & Sons 。浏览器或解析器不会因在解释时遇到这种内容而出问题。假定 HTML 和 XML 是 JSP 应用程序中最常见的内容类型，所以 escapeXml 属性的缺省值是 true 就不足为奇了。 

清单 15. 禁用转义的 <c:out> 操作示例
<c:out value="${user.company}" escapeXml=="false"/>








回页首




用缺省值设置变量
除了简化动态数据的显示之外，当通过 <c:set> 设置变量值时， <c:out> 指定缺省值的能力也很有用。正如 清单 11 所示，用来赋给限制了作用域的变量的值可以指定为 <c:set> 标记的主体内容，也可以通过其值属性来指定。通过将 <c:out> 操作嵌套在 <c:set> 标记的主体内容中，变量赋值就可以利用其缺省值能力。 
清单 16 中说明了这种方法。外部 <c:set> 标记的行为非常简单：它根据其主体内容设置会话作用域 timezone 变量的值。但是，在这种情况下，主体内容是通过 <c:out> 操作生成的。这个嵌套操作的值属性是表达式 ${cookie['tzPref'].value} ，它尝试通过 cookie 隐式对象返回名为 tzPref 的 cookie 值。（ cookie 隐式对象将 cookie 名称映射到相应的 Cookie 实例，这意味着必须通过对象的 value 特性使用点运算符来检索储存在 cookie 中的实际数据。） 

清单 16. 合并 <c:set> 和 <c:out> 以提供缺省变量值
<c:set var="timezone" scope=="session">
   <c:out value="${cookie['tzPref'].value}" default=="CST"/>
</c:set>




但是，请考虑以下情况，用户是第一次尝试使用这段代码的 Web 应用程序。结果是，请求中没有提供名为 tzPref 的 cookie。这意味着使用隐式对象的查找将返回 null ，在这种情况下整个表达式将返回 null 。因为对 <c:out> 标记的 value 属性求值的结果是 null ，所以 <c:out> 标记会转而输出对其 default 属性求值的结果。在这里是字符串 CST 。因此，实际的结果是将 timezone 限制了作用域的变量设置成用户的 tzPref cookie 中存储的时区，或者，如果没有，则使用缺省时区 CST 。 
EL 和 JSP 2.0

目前，表达式语言仅可用于指定 JSTL 定制标记中的动态属性值。但 JSTL 1.0 表达式语言的一个扩展已经被提出，会把它包括到 JSP 2.0 中去，眼下正在进行最后评审。这个扩展将允许开发人员通过自己的定制标记来使用 EL。页面作者将可以在目前允许使用 JSP 表达式的任何地方使用 EL 表达式，譬如将动态值插入模板文本中： <p>Your preferred time zone is ${timezone}</p> 。 
这个 JSP 2.0 功能（就象 JSTL 本身一样）将支持页面作者进一步减少对 JSP 编制脚本元素的依赖，从而改进 JSP 应用程序的可维护性。 






回页首




结束语
EL（与四个 JSTL 定制标记库提供的操作结合起来）允许页面作者不使用脚本元素即可实现表示层逻辑。例如，对比本文开头 清单 1 中的 JSP 代码和清单 17 中显示的通过 JSTL 实现的同样功能。（JSTL core 库中其余的标记，包括 <c:choose> 及其子标记，将在本系列的下一篇文章中讨论。）尽管显然执行了条件逻辑，但是 JSTL 版本中没有 Java 语言源代码，并且标记之间的关系（尤其是关于嵌套需求）对于任何精通 HTML 语法的人都应该是熟悉的。 

清单 17. 合并 <c:set> 和 <c:out> 以提供缺省变量值
<c:choose><c:when test="${user.role == 'member'}">
    <p>Welcome, member!</p>
  </c:when><c:otherwise>
    <p>Welcome, guest!</p>
  </c:otherwise></c:choose>



通过提供大多数 Web 应用程序常用功能的标准实现，JSTL 有助于加速开发周期。与 EL 结合起来，JSTL 可以不需要对表示层程序编写代码，这极大地简化了 JSP 应用程序的维护。



参考资料 
您可以参阅本文在 developerWorks 全球站点上的 英文原文. 


Sun 的 JSP 标准标记库主页是了解关于 JSTL 的更多信息的良好起点。 



JSTL 1.0 规范是关于 EL 和四个 JSTL 标记库的最终权威文本。 



Jakarta Taglibs项目是 JSTL 1.0 参考实现的起源。 



Shawn Bayern 所著的 JSTL in Action （Manning Publications Co.，2002 年）提供了对所有 JSTL 功能的精彩论述，作者是该参考实现的领导。 



David Geary 是 Java 技术方面很受欢迎的作者，他也写了一本关于 JSTL 的书，书名是 Core JSTL 。 



JSPTags.com是 JSP 技术参考资料的目录，它尤其专注于定制标记库。 



Sun 的 Java Web Services Tutorial中包含了对 JSTL 的讨论。 



&#8220; Using JSPs and custom tags within VisualAge for Java and WebSphere Studio&#8221;（ WebSphere 开发者园地）是一篇 WBOnline 实用论文，它演示了 servlet、JSP 和定制标记库的使用。 



通过 Jeff Wilson 精彩的文章&#8220; 使用定制标记控制 JSP 页面&#8221;（ developerWorks，2002 年 1 月）了解关于定制标记库的一切。 



Noel Bergman 的文章&#8220; JSP 标记库：着意设计的更好的可用性&#8221;（ developerWorks，2001 年 12 月）向您展示了声明性标记是如何帮助提高 JSP 页面的可用性的。 



有关 EcmaScript 的更多详细信息，请参阅 Sing Li 的&#8220; 快速上手 Java 编程&#8221;（ developerWorks，2001 年 7 月）。 



在 developerWorksJava 技术专区 可以找到多达数百篇的 Java 技术参考资料。 




关于作者

Mark Kolb 是一名在德克萨斯州奥斯汀工作的软件工程师。他经常就服务器端 Java 主题在业界发表演讲，并且与人合著了 Web Development with JavaServer Pages，第二版 一书。可通过 mak@taglib.com与 Mark 联系。 <img src ="http://www.blogjava.net/yiqi801218/aggbug/197668.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/yiqi801218/" target="_blank">BlueSunshine</a> 2008-05-01 19:57 <a href="http://www.blogjava.net/yiqi801218/archive/2008/05/01/197668.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>O’Reilly总裁提姆-奥莱理：什么是Web 2.0</title><link>http://www.blogjava.net/yiqi801218/archive/2008/03/05/183878.html</link><dc:creator>BlueSunshine</dc:creator><author>BlueSunshine</author><pubDate>Wed, 05 Mar 2008 02:50:00 GMT</pubDate><guid>http://www.blogjava.net/yiqi801218/archive/2008/03/05/183878.html</guid><wfw:comment>http://www.blogjava.net/yiqi801218/comments/183878.html</wfw:comment><comments>http://www.blogjava.net/yiqi801218/archive/2008/03/05/183878.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/yiqi801218/comments/commentRss/183878.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/yiqi801218/services/trackbacks/183878.html</trackback:ping><description><![CDATA[<h1 id="header">&nbsp;</h1>
<div id="content">
<div class="post" id="post-21">
<h3 class="storytitle"><a href="http://lib.xiaop.net/article/web20/" rel="bookmark">O&#8217;Reilly总裁提姆-奥莱理：什么是Web 2.0</a></h3>
<div class="storycontent">
<p>译者序：Web 2.0这一概念，由O&#8217;Reilly媒体公司总裁兼CEO提姆&#183;奥莱理提出。他是美国IT业界公认的传奇式人物，是&#8221;开放源码&#8221;概念的缔造者，一直倡导开放标准，并活跃在开放源码运动的最前沿。</p>
<p>这篇由提姆&#183;奥莱理亲自执笔、创作于上个月由他主办的Web 2.0会议前夕的文章，一经发出就引发了热烈的讨论，被视为Web 2.0迄今为止的经典之作。</p>
<p></p>
<p><strong>Web2.0的一个关键原则是用户越多，服务越好</strong></p>
<p>作者｜提姆&#183;奥莱理(Tim O&#8217;Reilly) 翻译作者｜玄伟剑</p>
<p>2001年秋天互联网公司（dot-com)泡沫的破灭标志着互联网的一个转折点。许多人断定互联网被过分炒作，事实上网络泡沫和相继而来的股市大衰退看起来像是所有技术革命的共同特征。股市大衰退通常标志着蒸蒸日上的技术已经开始占领中央舞台。假冒者被驱逐，而真正成功的故事展示了它们的力量，同时人们开始理解了是什么将一个故事同另外一个区分开来。</p>
<p>&#8220;Web 2.0&#8243;的概念开始于一个会议中，展开于O&#8217;Reilly公司和MediaLive国际公司之间的头脑风暴部分。所谓互联网先驱和O&#8217;Reilly公司副总裁的戴尔&#183;多尔蒂(Dale Dougherty)注意到，同所谓的&#8221;崩溃&#8221;迥然不同，互联网比其他任何时候都更重要，令人激动的新应用程序和网站正在以令人惊讶的规律性涌现出来。更重要的是，那些幸免于当初网络泡沫的公司，看起来有一些共同之处。那么会不会是互联网公司那场泡沫的破灭标志了互联网的一种转折，以至于呼吁&#8221;Web 2.0&#8243;的行动有了意义？我们都认同这种观点，Web 2.0会议由此诞生。</p>
<p>在那个会议之后的一年半的时间里，&#8221;Web 2.0&#8243;一词已经深入人心，从Google上可以搜索到950万以上的链接。但是，至今关于Web 2.0的含义仍存在极大的分歧，一些人将Web 2.0贬低为毫无疑义的一个行销炒作口号，而其他一些人则将之理解为一种新的传统理念。</p>
<p>本文就是来尝试澄清Web 2.0本来意义。</p>
<p>在我们当初的头脑风暴中，我们已经用一些例子，公式化地表达了我们对Web 2.0的理解</p>
<table cellspacing="0" cellpadding="3" align="center" border="1">
    <tbody>
        <tr>
            <td bordercolor="#3399ff" bgcolor="#ccffff">Web 1.0</td>
            <td bordercolor="#3399ff" bgcolor="#ccffff">Web 2.0</td>
        </tr>
        <tr>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">DoubleClick</td>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">Google AdSense</td>
        </tr>
        <tr>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">Ofoto</td>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">Flickr</td>
        </tr>
        <tr>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">Akamai</td>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">BitTorrent</td>
        </tr>
        <tr>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">mp3.com</td>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">Napster</td>
        </tr>
        <tr>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">大英百科全书在线（Britannica Online）</td>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">维基百科全书（Wikipedia）</td>
        </tr>
        <tr>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">个人网站</td>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">博客(blogging)</td>
        </tr>
        <tr>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">evite</td>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">upcoming.org和EVDB</td>
        </tr>
        <tr>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">域名投机</td>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">搜索引擎优化</td>
        </tr>
        <tr>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">页面浏览数</td>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">每次点击成本</td>
        </tr>
        <tr>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">屏幕抓取（screen scraping）</td>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">网络服务（web services）</td>
        </tr>
        <tr>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">发布</td>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">参与</td>
        </tr>
        <tr>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">内容管理系统</td>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">维基</td>
        </tr>
        <tr>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">目录（分类)</td>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">标签（&#8221;分众分类&#8221;，folksonomy）</td>
        </tr>
        <tr>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">粘性</td>
            <td bordercolor="#3399ff" bgcolor="#ffffcc">聚合</td>
        </tr>
    </tbody>
</table>
<p>这个列表还会不断继续下去。但是到底是什么，使得我们认定一个应用程序或一种方式为作所谓&#8221;Web 1.0&#8243;，而把另外一个叫做&#8221;Web 2.0&#8243;呢？（这个问题尤为紧迫，因为Web 2.0的观念已经传播的如此广泛，以至于很多公司正在将这个词加到他们的行销炒作中，但却没有真正理解其含义。同时这个问题也尤为困难，因为许多嗜好口号的创业公司显然不是Web 2.0，而一些我们认为是Web 2.0的应用程序，例如Napster和BitTorrent，甚至不是真正适当的网络程序！）我们首先来探讨一些原则，这些原则是通过Web 1.0的一些成功案例，以及一些最为有趣的新型应用程序来体现的。</p>
<p style="text-align: center"><img id="LinkImage" height="450" src="http://images.csdn.net/20051125/1132629709780.jpg" width="600" border="0" name="LinkImage"  alt="" /></p>
<p><strong>1. 互联网作为平台</strong></p>
<p>正如许多重要的理念一样，Web 2.0没有一个明确的界限，而是一个重力核心。不妨将Web 2.0视作一组原则和实践，由此来把距离核心或远或近的网站组成为一个类似太阳系的网络系统，这些网站或多或少地体现着Web 2.0的原则。</p>
<p>图1为Web 2.0的&#8221;模拟图&#8221;，该图是在名为&#8221;O&#8217;Reilly的朋友&#8221;（Friend Of O&#8217;Reilly, FOO）的会议的一个研讨会上产生的。这个图基本上仍处于演化阶段，但已经描绘出了 从Web 2.0核心理念中衍生出的许多概念。</p>
<p>例如，在2004年10月的第一次Web 2.0的会议上，约翰&#183;巴特利（John Battelle）和我在我们各自的开场白中列举了一组初步的原则。</p>
<p>这些原则中的第一条就是&#8221;互联网作为平台&#8221;。这也曾是Web 1.0的宠儿网景公司（Netscape)的战斗口号，而网景在同微软的大战中陨落了。此外，我们早先的Web 1.0的楷模中的两个，DoubleClick和Akamai公司，皆是将网络当作平台的先驱。人们往往不认为这是一种网络服务，但事实上，广告服务是第一个被广泛应用的网络服务，同时也是第一个被广泛应用的混合处理（mashup），如果用另一个近来流行的词来说的话。每个旗帜广告（banner ad)都是用来在两个网站之前无缝合作，向位于另外一台计算机上的读者传递一个整合好的页面。</p>
<p>Akamai也将网络看作平台，并且在一个更深入的层次上，来搭建一个透明的缓存和内容分发网络，以便降低宽带的拥塞程度。</p>
<p>虽然如此，这些先驱提供了有益的对比，因为后来者遇到同样问题的时候，可以将先驱们的解决方案进一步延伸，从而对新平台本质的理解也更为深刻了。 DoubleClick和Akamai都是Web 2.0的先驱，同时我们也可以看到，可以通过引入更多Web 2.0的设计模式，来实现更多的应用。</p>
<p>让我们对这三个案例中的每一个都作一番深究，来探讨其间的一些本质性的差别。</p>
<p><strong>Netscape 对 Google</strong></p>
<p>如果Netscape可以称为Web 1.0的旗手，那么Google几乎可以肯定是Web 2.0的旗手，只要看看他们的首次公开上市（IPO)是如何地揭示了各自的时代就清楚了。所以我们就从这两个公司和其定位的差别入手。</p>
<p>Netscape以传统的软件摹本来勾勒其所谓&#8221;互联网作为平台&#8221;：他们的旗舰产品是互联网浏览器，一个桌面应用程序。同时，他们的战略是利用他们在浏览器市场的统治地位，来为其昂贵的服务器产品建立起市场。从理论上讲，在浏览器中控制显示内容和程序的标准，赋予了Netscape一种市场支配力，如同微软公司在个人计算机市场上所享受的一样。很像当初&#8221;自行的马车&#8221;（horseless carriage）将汽车描绘为一种熟知事物的延伸，Netscape曾推销一种网络桌面（webtop）来替代传统的桌面（desktop），并且计划借助信息更新，以及由购买了Netscape服务器的信息提供者来推送的各种小程序，来开发推广这种网络桌面。</p>
<p>最终，浏览器和网络服务器都变成了&#8221;日用品&#8221;，同时价值链条也向上移动到了在互联网平台上传递的服务。</p>
<p>作为对比，Google则以天生的网络应用程序的角色问世，它从不出售或者打包其程序，而是以服务的方式来传递。客户们直接或间接地为其所使用的服务向 Google付费。原有软件工业缺陷荡然无存。没有了定期的软件发布，只需要持续的改善。没有了许可证或销售，只需要使用。没有了为了让用户在其设备上运行软件而不得不进行的平台迁移，只需要搭建宏大的、由众多个人计算机组成的、可伸缩的网络，其上运行开源操作系统，及其及自行研制的应用程序和工具，而公司之外的任何人则永远无法接触到这些东西。</p>
<p>在其底层，Google需要一种Netscape从未需要过的能力：数据库管理。Google远远不只是一个软件工具的集合，它是一个专业化的数据库。没有这些数据，那些工具将毫无用武之地；没有这些软件，数据也将无可控制。软件许可证制度和对应用程序接口（API）的控制&#8211;上一个时代的法宝&#8211;已经毫不相关了，因为Google的软件只需要执行而从不需要分发，也因为如果不具备收集和管理数据的能力，软件本身就没有什么用处了。事实上，软件的价值是同它所协助管理的数据的规模和活性成正比的。</p>
<p>Google的服务不是一个简单的服务器，虽然其服务是通过大规模的互联网服务器集合来传递的；其服务也不是一个浏览器，虽然这种服务是被用户在浏览器中体验到的。Google的旗舰产品&#8211;搜索服务，甚至不托管它让用户来搜寻的内容。很像一个电话通话过程，不仅发生在通话的两端，而且发生在中间的网络上。作为用户和其在线体验的一个中介，Google作用于浏览器、搜索引擎和最终的内容服务器之间的空间中。</p>
<p>虽然 Netscape和Google都可以被描述为软件公司，但显然Netscape可以归到Lotus，Microsoft，Oracle，SAP，以及其他发源于上个世纪八十年代软件革命的那些公司所组成的软件世界。而Google的同伴们，则是像eBay，Amazon，Napster，及至 DoubleClick和Akamai这样的互联网公司。</p>
<p><strong>DoubleClick对Overture和AdSense</strong></p>
<p>同Google类似，DoubleClick是一个名副其实的互联网时代的孩子。它把软件作为一种服务，在数据管理方面具有核心竞争力，并且正如上文所述，它是一个早在连网络服务的名字还不曾有的时候，就已然开始其服务的先驱。然而，DoubleClick最终还是被其商业模式局限住了。它所贯彻的是九十年代的互联网观念。这种观念围绕着出版，而不是参与；围绕着广告客户，而不是消费者，来进行操纵；围绕着规模，认为互联网会被如MediaMetrix 等网络广告评测公司尺度下的所谓顶级网站所统治。</p>
<p>结果是，DoubleClick得意地在其网站上引用道：&#8221;超过2000种的成功应用&#8221;。而相对比的是，Yahoo!公司的搜索市场（从前的Overture）和Google的AdSense产品，已经在为几十万的广告客户服务。</p>
<p>Overture和Google的成功源自于对克里斯&#183;安德森（Chris Anderson）提到的所谓&#8221;长尾&#8221;的领悟，即众多小网站集体的力量提供了互联网的大多数内容。DoubleClick的产品要求一种签订正式的销售合同，并将其市场局限于很少的几千个大型网站。Overture和Google则领会到如何将广告放置到几乎所有网页上。更进一步地，它们回避了发行商和广告代理们所喜爱的广告形式，例如旗帜广告和弹出式广告，而采用了干扰最小的、上下文敏感的、对用户友好的文字广告形式。</p>
<p>Web 2.0的经验是：有效利用消费者的自助服务和算法上的数据管理，以便能够将触角延伸至整个互联网，延伸至各个边缘而不仅仅是中心，延伸至长尾而不仅仅是头部。</p>
<p>毫不奇怪，其他Web 2.0的成功故事也显示着同样的轨迹。eBay扮演着一个自动的中间媒介的角色，使个体之间发生的几个美元的偶然性的交易成为可能。Napster（虽然已经出于法律原因而关闭）将其网络建立在一个集中的歌曲数据库之上，但是它让每一个下载者都成为一台服务器，从而使其网络逐渐扩大。</p>
<p><strong>Akamai 对 BitTorrent</strong></p>
<p>同DoubleClick类似，Akamai的业务重点面向网络的头部，而不是尾部；面向中心，而不是边缘。虽然它服务于那些处于网络边缘的个体的利益，为他们访问位于互联网中心的高需求的网站铺平了道路，但它的收入仍然来自从那些位于中心的网站。</p>
<p>BitTorrent，像P2P风潮中的其他倡导者一样，采用了一种激进的方式来达到互联网去中心化（internet decentralization）的目的。每个客户端同时也是一个服务器；文件被分割成许多片段，从而可以由网络上的多个地方提供，透明地利用了网络的下载者来为其他下载者提供带宽和数据。事实上，文件越流行下载得越快，因为有更多的用户在为这个文件提供带宽和各个片段。</p>
<p>BitTorrent由此显示出Web 2.0的一个关键原则：用户越多，服务越好。一边是Akamai必须增加服务器来改善服务，另一边是BitTorrent用户将各自的资源贡献给大家。可以说，有一种隐性的&#8221;参与体系&#8221;内置在合作准则中。在这种参与体系中，服务主要扮演着一个智能代理的作用，将网络上的各个边缘连接起来，同时充分利用了用户自身的力量。</p>
<p><strong>2. 利用集体智慧</strong></p>
<p>在诞生于Web 1.0时代并且存活了下来，而且要继续领导Web 2.0时代的那些巨人的成功故事的背后，有一个核心原则，就是他们借助了网络的力量来利用集体智慧：</p>
<ul>
    <li>超级链接是互联网的基础。当用户添加新的内容和新的网站的时候，将被限定在一种特定的网络结构中，这种网络结构是由其他用户发现内容并建立链接的。如同大脑中的神经突触，随着彼此的联系通过复制和强化变得越来越强，而作为所有网络用户的所有活动的直接结果，互联的网络将有机地成长。
    <li>Yahoo!是第首例伟大的成功故事，诞生于一个分类目录，或者说是链接目录，一个对数万甚至数百万网络用户的最精彩作品的汇总。虽然后来Yahoo!进入了创建五花八门的内容的业务，但其作为一个门户来收集网络用户们集体作品的角色，依然是其价值核心。
    <li>Google在搜索方面的突破在于PageRank技术，该技术令其迅速成为搜索市场上毫无争议的领导者。PageRank是一种利用了网络的链接结构，而不是仅仅是使用文档的属性，来实现更好的搜索效果的方法。
    <li>&#8211; eBay的产品是其全部用户的集体活动，就向网络自身一样，eBay随着用户的活动而有机地成长，而且该公司的角色是作为一个特定环境的促成者，而用户的行动就发生在这种环境之中。更重要的是，eBay的竞争优势几乎都来自于关键性的大量的买家和卖家双方，而这正是这一点使得后面许多竞争者的产品的吸引力显著减低。
    <li>Amazon销售同Barnesandnoble.com等竞争者相同的产品，同时这些公司从卖方获得的是同样的产品描述、封面图片和目录。所不同的是，Amazon已然缔造出了一门关于激发用户参与的科学。Amazon拥有比其竞争者高出一个数量级以上的用户评价，以及更多的邀请来让用户以五花八门的方式，在近乎所有的页面上进行参与，而更为重要的是，他们利用用户的活动来产生更好的搜索结果。 Barnesandnoble.com的搜索结果很可能指向该公司自己的产品，或者是赞助商的结果，而Amazon则始终以所谓&#8221;最流行的&#8221;打头，这是一种实时计算，不仅基于销售，而且基于其他一些被Amazon内部人士称为围绕着产品&#8221;流动&#8221;（flow）的因素。由于拥有高出对手一个数量级的用户参与， Amazon销售额超出竞争对手也就不足为奇了。 </li>
</ul>
<p>现在，具备了这种洞察力，并且可能会将之延伸开来的那些创新型的公司，正在互联网上留下他们的印迹。</p>
<p>维基百科全书（Wikipedia）是一种在线百科全书，其实现基于一种看似不可能的观念。该观念认为一个条目可以被任何互联网用户所添加，同时可以被 其他任何人编辑。无疑，这是对信任的一种极端的实验，将埃里克&#183;雷蒙德（Eric Raymond）的格言（源自开放源码软件的背景之下）：&#8221;有足够的眼球，所有的程序缺陷都是肤浅的&#8221;（with enough eyeballs, all bugs are shallow）运用到了内容的创建之中。维基百科全书已然高居世界网站百强之列，并且许多人认为它不久就将位列十强。这在内容创建方面是一种深远的变革。</p>
<p>像del.icio.us（美味书签）和Flickr这样的网站，其公司已经在近期获得了广泛的关注，并且已经在一种被人们成为&#8221;分众分类&#8221;（folksonomy，有别于传统分类法）的概念上成为先行者。&#8221;分众分类&#8221;是一种使用用户自由选择的关键词对网站进行协作分类的方式，而这些关键词一般称为标签（tags)。标签化运用了像大脑本身所使用的那种多重的、重叠的关联，而不是死板的分类。举一个经典的例子，在 Flickr网站上，一幅小狗照片可能被加上&#8221;小狗&#8221;和&#8221;可爱&#8221;这样的标签，从而允许系统依照用户行为所产生的自然的方式来进行检索。</p>
<p>协作式垃圾信息过滤产品，例如Cloudmark，就聚集了电子邮件用户们对于&#8221;一封邮件是或者不是垃圾邮件&#8221;的众多相互独立的决策，从而胜过了依赖于分析邮件本身的那些系统。</p>
<p>伟大的互联网成功者并不主动地到处推销其产品，这几乎成为公理。他们采用&#8221;病毒式营销&#8221;（viral marketing）的方式，也就是说，一些推介会直接从一个用户传播到另外一个用户。如何一个网站或产品依赖广告来进行宣传，你几乎可以断定它不是Web 2.0。</p>
<p>即便许多互联网基础设施本身，包括在大多数网络服务器中用到的Linux，Apache，MySQL，以及Perl，PHP或Python代码，也都依靠开放源码的对等生产（peer-production）的方式。其中包含了一种集体的、网络赋予的智慧。在SourceForge.net网站上列有至少10万种开放源码软件项目。任何人都可以添加一个项目，任何人都可以下载并使用项目代码。</p>
<p>同时，由于作为用户使用的结果，新的项目从边缘迁移到中心。一个对软件的有机的接受过程几乎完全依靠病毒式营销。同时，作为用户应用的结果，新的项目从边缘迁移到中心，这是一种几乎完全依靠病毒式营销的，有机的软件采用过程，。</p>
<p>经验是：源于用户贡献的网络效应，是在Web 2.0时代中统治市场的关键。</p>
<p><strong>平台总是打败应用程序</strong></p>
<p>在过去每次同对手的竞争中，微软都成功地打用了平台这张牌，打败了即便是最占主导地位的应用程序。Windows平台让微软以Excel取代了 Lotus 1-2-3，以Word取代了WordPerfect,，以Internet Explorer取代了Netscape浏览器。</p>
<p>不过这次，冲突不是在平台和应用程序之间，而是在两种平台之间。每个平台皆有一种截然不同的商业模式：一方面，一个独立软件商具有广泛的用户基础并且将应用程序接口和操作系统紧密集成，从而对程序设计模式予以控制；另一方面，是一个没有所有者的系统，由一组协议、开放标准和对合作的共识来连结到一起。</p>
<p>Windows系统代表了由软件程序接口来进行专有控制的高峰。Netscape曾尝试用微软当初对付其对手所使用的手段，来同微软进行争夺，但是失败了。然而拥有互联网开放标准的Apache却已经繁荣了起来。此番上演的战局，已经不再是实力悬殊的平台对决孤立的软件了，而是变成了平台对决平台。问题在于，哪个平台，或者更深远地来说哪个体系，以及哪个商业模式，最能适应未来的机遇。</p>
<p>Windows对于早期的PC时代的问题是一种卓越的解决方案。它统一了程序开发者的竞技场，解决了很多困扰这个领域的问题。但这种由单一供方控制的一刀切的方法，已经不再是适宜的解决方案，而成为了一种问题。面向交流的系统需要协同性，互联网作为一个平台当然也是如此。除非供方可以控制每一例交互的两个终端，这种通过软件的程序接口来锁定用户的可能性微乎其微。</p>
<p>任何企图通过控制平台来推销应用程序的Web 2.0提供商，从定义上讲，已经丧失了这个平台的优越性。</p>
<p>这并不是说锁定和竞争优势的机会不复存在了，而是说我们相信这种机会不是通过控制软件程序接口和协议来取得的。新的游戏规则正在浮现。那些能够理解这些新的游戏规则，而不是企图回到PC软件时代旧有规则的公司，才有可能在Web 2.0时代获得成功。</p>
<p><strong>博客和大众智慧</strong></p>
<p>Web 2.0时代一项最受追捧的特性就是博客的兴起。个人主页从互联网早期就已经存在了，而个人日记和每日发表观点的专栏就更渊源久远了，那么到底有什么让人大惊小怪的呢？</p>
<p>归根底地，博客只是一种日记形式个人网页。但正如里奇&#183;斯格仁塔（Rich Skrenta）指出的，博客的按时间顺序来排列的结构&#8221;看起来像是一个微不足道的变化，但却推动着一个迥然不同的分发、广告和价值链。&#8221;</p>
<p>其中一大变化就是一项称为RSS的技术。RSS是自早期计算机高手们认识到CGI（公共网关接口）可用来创建以数据库为基础的网站以来，在互联网根本结构方面最重要的进步。RSS使人们不仅仅链接到一个网页，而且可以订阅这个网页，从而每当该页面产生了变化时都会得到通知。斯格仁塔将之称为&#8221;增量的互联网&#8221;（incremental web）。其他人则称之为&#8221;鲜活的互联网&#8221;（live web）。</p>
<p>当然，现在所谓&#8221;动态网站&#8221;（即具有动态产生的内容的、由数据库驱动的网站）取代了十年前的静态网站。而动态网站的活力不仅在于网页，而且在链接方面。一个指向网络博客的链接实际上是指向一个不断更新的网页，包括指向其中任何一篇文章的&#8221;固定链接&#8221;（permalinks），以及每一次更新的通知。因此，一个RSS是比书签或者指向一个单独网页的链接要强大得多。</p>
<p>RSS同时也意味着网页浏览器不再只是限于浏览网页的工具。尽管诸如Bloglines之类的RSS聚合器（RSS aggregators）是基于网络的，但其他的则是桌面程序，此外还有一些则可以用在便携设备上来接受定期更新的内容。</p>
<p>RSS现在不仅用于推送新的博客文章的通知，还可以用于其他各种各样的数据更新，包括股票报价、天气情况、以及图片。这类应用实际上是对RSS本源的一 种回归：RSS诞生于1997年，是如下两种技术的汇合：一种是戴夫&#183;温纳（Dave Winer）的&#8221;真正简单的聚合&#8221;（Really Simple Syndication）技术，用于通知博客的更新情况；另一种是Netscape公司提供的&#8221;丰富站点摘要&#8221;（Rich Site Summary）技术，该技术允许用户用定期更新的数据流来定制Netscape主页。后来Netscape公司失去了兴趣，这种技术便由温纳的一个博客先驱公司Userland承接下来。不过，在现在的应用程序实现中，我可以看出两者共同的作用。</p>
<p>但是，RSS只是令博客区别于同普通网页的一部分原因。汤姆&#183;科特斯（Tom Coates）这样评论固定链接的重要性：</p>
<p>&#8220;现在它可能看上去像是一项普普通通的功能，但它却有效地将博客从一个易于发布（ease-of-publishing）的现象，进一步转变为互相交叉的社区的一种对话式的参与。这是首次使得对其他人的网站上的很特定的帖子表态和谈论变得如此地容易。讨论出现了，聊天也出现。同时，其结果是出现了友谊或者友谊更加坚定了。固定链接是第一次也是最为成功的一次在博客之间搭建桥梁的尝试。&#8221;</p>
<p>在许多方面，RSS同固定链接的结合，为HTPP（互联网协议）增添了NNTP（新闻组的网络新闻协议）的许多特性。所谓&#8221;博客圈&#8221;（blogosphere），可以将其视作一种同互联网早期的、以对话方式来灌水的新闻组和公告牌相比来说，新型的对等（peer-to-peer）意义上的等价现象。人们不仅可以相互订阅网站并方便地链接到一个页面上的特定评论，而且通过一种称为引用通告（trackbacks）的机制，可以得知其他任何人链接到了他们的页面，并且可以用相互链接或者添加评论的方式来做出回应。</p>
<p>有趣的是，这种双向链接（two-way links）曾是象Xanadu之类的早期超文本系统的目标。超文本纯粹论者已然将引用通告颂扬为向双向链接迈进了一步。但需要注意的是，引用通告不是一个真正的双向链接，确切地讲是一种（潜在地）实现了双向链接效果的对称式单向链接。其间的区别看起来可能很细微，但实际上却是巨大的。诸如 Friendster, Orkut和LinkedIn那样的社交网络系统（social networking systems），需要接受方做出确认以便建立某种连接，从而缺少像互联网架构本身那样的可伸缩性。正如照片共享服务Flickr网站的创始人之一卡特里纳&#183;费克（Caterina Fake）所指出的，注意力仅在碰巧时才礼尚往来。（Flickr因此允许用户设置观察列表，即任何用户都可以通过RSS来订阅其他所有用户的照片流。注意的对象将会被通知，但并不一定要认可这种连接。）</p>
<p>如果Web 2.0的一个本质是利用集体智慧，来将互联网调试为一种所谓的全球的大脑，那么博客圈就是前脑中喋喋不休的呓语，那种我们整个头脑中都能听到的声音。这可能并不反映出大脑的往往是无意识的深层结构，但却是一种有意识的思考的等价物。作为一种有意识的思考和注意力的反映，博客圈已经开始具有强有力的影响。</p>
<p>首先，因为搜索引擎使用链接结构来辅助预测有用的页面，作为最多产和最及时的链接者，博客们在修整搜索引擎结果方面充当着一种不成比例的角色。其次，因 为博客社区是如此多地自相引用，关注其他博客的博客们开阔了他们的视野和能力。此外，评论家们所批判的&#8221;回音室&#8221;（echo chamber）也是一种放大器。</p>
<p>如果只是一种放大器，那么撰写博客将会变得无趣。但是像维基百科全书一样，博客将集体 智慧用作一种过滤器。被詹姆士&#183;苏瑞奥维奇（James Suriowecki）称为&#8221;大众智慧&#8221;（the wisdom of crowds）的规律起了作用，并且就像PageRank技术所产生的结果胜过分析任何单一文档一样，博客圈的集体关注会筛选出有价值的东西。</p>
<p>虽然主流媒体可能将个别的博客视为竞争者，但真正使其紧张的将是同作为一个整体的博客圈的竞争。这不仅是网站之间的竞争，而且是一种商业模式之间的竞 争。Web 2.0的世界也正是丹&#183;吉尔默（Dan Gillmor）的所谓&#8221;个人媒体&#8221;（We，the media)的世界。在这个世界中，是所谓&#8221;原本的听众&#8221;，而不是密实里的少数几个人，来决定着什么是重要的。</p>
<p><strong>3. 数据是下一个Intel Inside</strong></p>
<p>现在每一个重要的互联网应用程序都由一个专门的数据库驱动：Google的网络爬虫, Yahoo!的目录（和网络爬虫），Amazon的产品数据库，eBay的产品数据库和销售商，MapQuest的地图数据库，Napster的分布式歌曲库。正如哈尔&#183;瓦里安（Hal Varian）在去年的私人对话中谈到的，&#8221;SQL是新的HTML&#8221;。数据库管理是Web 2.0公司的核心竞争力，其重要性使得我们有时候称这些程序为&#8221;讯件&#8221;（infoware）而不仅仅是软件。</p>
<p>该事实也引出了一个关键问题：谁拥有数据？</p>
<p>在互联网时代，我们可能已经见到了这样一些案例，其中对数据库的掌控导致了对市场的支配和巨大的经济回报。当初由美国政府的法令授权给 Network Solutions公司（后被Verisign公司收购）的对域名注册的垄断，曾经是互联网上的第一个摇钱树。虽然我们在争论通过控制软件的API来形成商业优势在互联网时代会变得困难得多，但是对关键数据资源的控制则不同，特别是当要创建这些数据资源非常昂贵，或者经由网络效应容易增加回报的时候。</p>
<p>注意一下由MapQuest, maps.yahoo.com，maps.msn.com，或者maps.google.com等网站提供的每张地图下面的版权声明，你会发现这样一行字 &#8220;地图版权NavTeq，TeleAtlas&#8221;，或者如果使用的是新的卫星图像服务，则会看到&#8221;图像版权Digital Globe&#8221;的字样。这些公司对其数据库进行了大量的投资。（仅NavTeq一家，就公布投资7.5亿美元用于创建其街道地址和路线数据库。 Digital Globe则投资5亿美元来启动其自有卫星，来对政府提供的图像进行改进。）NavTeq竟然已做了很多模仿Intel的耳熟能详的Intel Inside标识的事：例如带有导航系统的汽车就带有&#8221;NavTeq Onboard&#8221;的印记。数据是许多此类程序事实上的Intel Inside，是一些系统的唯一的信息源组件，这些系统的软件体系多数是开放源码的，也有商业化的。</p>
<p>当前竞争火热的网络 地图（web mapping）领域显示着，对拥有软件核心数据的重要性的疏忽大意，将最终削弱其竞争地位。MapQuest在1995年率先进入地图领域，随后是 Yahoo!，再后来是Microsoft，而最近Google也决定挺进这一市场，他们可以轻松地通过对同一数据的授权来提供一个具有竞争力的程序。</p>
<p>然而，作为对比的是Amazon.com的竞争地位。像Barnesandnoble.com这样的竞争者一样，其原始数据库来自于ISBN注册商. R. Bowker。但是同MapQuest不同，Amazon大力增强其数据，增加出版商提供的数据，例如封面图片，目录，索引，和样张材料。更重要的是，他们利用了其用户来评注数据，以至于十年之后，是Amazon而不是Bowker，成为图书文献信息的主要来源，一个学者、图书管理员和消费者的参考书目来源。Amazon还引入了其专有的标识符，即ASIN，该标识符在ISBN存在时与之对应，而当产品不带有ISBN时，就创建出一个等价的命名空间。 Amazon从而有效地&#8221;吸收和拓展了&#8221;其数据提供商。</p>
<p>设想如果MapQuest也已做了同样的事情，利用他们的用户来评注地图和路线，添加新的价值层面。那么对仅仅通过授权使用基础数据来进入这一市场的其他竞争者，将造成远远大得多的困难。</p>
<p>近期Google地图的引入，为应用程序销售商和其数据提供商之间的竞争，提供了一个活生生的实验室。Google的轻量型编程模型已经引发了不计其数 的增值服务的出现，这些服务以数据混合的方式，将Google的地图同其他可以通过互联网访问的数据源相结合。保罗&#183;拉特马赫（Paul Rademacher）的housingmaps.com是这种混合的一个上佳范例，其网站将Google的地图同Craigslist的公寓出租，以及住宅购买数据相结合，来创建一种交互式的房屋搜索工具。</p>
<p>目前，这些混合大多是由程序高手们实现的创新性的实验产品。但是企业行动将紧随其后。并且，人们已经可以从至少一类开发者中发现这一点。Google已经将数据源提供者的角色从Navteq那里夺走，并且将自己定位为一个令人喜爱的中介者。在以后几年里，我们将会看到数据提供商和程序销售商之间的斗争，因为两大阵营都认识到了，特定的数据类别在作为搭建Web 2.0程序的积木时是多么的重要。</p>
<p>这场竞赛已经涉及到拥有特定类别的核心数据：位置、身份、公共事件日历、产品标识和命名空间等。在许多情况下，在那些创建数据需要巨额成本的地方，也可能存在一种如同Intel Inside方式一样凭借单一数据源来所有作为的机遇。其他情况下，胜者将是那些通过用户聚合来达到临界规模，并且将聚合的数据融入系统服务中的公司。</p>
<p>比如，在身份标识领域，PayPal，Amazon的一键式，以及拥有数百万用户的交流系统，都有可能成为创建整个网络范围的身份标识数据库的正当竞争者。（关于此，Google最近使用手机号码作为Gmail账号标识的尝试，可能就是朝借鉴和拓展电话系统所迈出的一步。）同时，像Sxip这样的创业公司，正在探索联合身份标识的可能性，以寻求一种&#8221;分布一键式&#8221;，从而提供一个无缝的Web 2.0标识子系统。在日历领域，EVDB则是通过维基式参与体系来搭建世界上最大的共享日历的一种尝试。虽然评判者尚在观望着任何一个特定创业公司或方式的成功是否，但很显然，这些领域的标准和解决方案，有效地将某些数据转变为&#8221;互联网操作系统&#8221;（internet operating system）的可靠的子系统，并将促成下一代的应用程序。</p>
<p>关于数据，必须注意一个进一步的方面，那就是用户关心其隐私和对自己的数据的权限。在许多早期的网络程序中，版权只被松散地执行。例如，Amazon宣称对任何提交到其网站的评论的所有权，但却缺少强制性，人们可以将同样的评论转贴到其他任何地方。然而，随着很多公司开始认识到，对数据的掌控有可能成为他们首要的竞争优势来源，我们将会看到在此类控制方面强度更大的尝试。</p>
<p>正如专有软件的增长而导致自由软件运动一样，在下一个10年中我们会看到专有数据库的增长将导致自由数据运动。在像维基百科全书这样的开放数据项目、创作共用（Creative Commons）、以及像Greasemonkey（让用户决定如何在其计算机上显示数据）这样的软件项目中，我们可以看到这种对抗势头的前兆。</p>
<p><strong>参与的体系</strong></p>
<p>一些系统被设计为鼓励参与。在丹&#183;布莱克林（Dan Bricklin）的论文&#8221;共用的丰饶&#8221;（The Cornucopia of the Commons）中，他指出有三种创建大型数据库的方式。第一种，已经由Yahoo!来体现了，就是付费给人们来实现。第二种，由开放源码社区的经验启发而来，就是让志愿者来完成同样的任务。开放目录项目（Open Directory Project），一个Yahoo的开放源码竞争者，就是该方式的产物。但是Napster体现了第三种方式。因为Napster将其默认设置为自动为任何已经下载的音乐服务，任何用户都自动地帮助建立共享数据库的价值。同样的方式已经被其他所有P2P文件共享服务所采用。Web 2.0时代的一个关键经验在于：用户增加价值。但是只有很小一部分用户会有意来为你的程序增加价值，而不怕麻烦。因而，Web 2.0公司均进行了这样的默认设置，即作为程序通常使用方式的副产品，来聚合用户数据并创造价值。正如上面所指出的，他们在搭建那种用户越多则效果越好的系统。</p>
<p>米切尔&#183;卡普尔（Mitch Kapor）曾经指出&#8221;体系是策略&#8221;。参与是Napster的本质，其根本体系的一部分。</p>
<p>同更经常被引用的所谓&#8221;吸引志愿精神&#8221;的原因相比，这种体系结构上的洞察力可能更能抓住对开放源码软件成功的本质。互联网、万维网（World Wide Web）、以及像Linux、Apache和Perl这样的开放源码软件项目的体系结构，均是这样一种设计，使得作为一种自动产生的副产品，谋求其自身利益的用户们创建着集体的价值。这些项目中的任何一个都有一个很小的核心、一种设计良好的扩展机制、和一种让任何人来添加任何合乎规定的组件的方式，不断增长着被Perl语言的创始人拉里&#183;沃尔（Larry Wall）称为&#8221;洋葱头&#8221;（the onion）的外部层面。换句话说，这些技术通过他们本来的设计方式，体现着网络的效应。</p>
<p><strong>4. 软件发布周期的终结</strong></p>
<p>如上文在对Google和Netscape的比较中谈到的，互联网时代软件的代表性特征就是它应该被作为服务来交付。这种事实导致这类公司的商业模式上很多根本性的变化。</p>
<p>1. 运营必须成为一种核心竞争力。Google或者Yahoo!在产品开发方面的专门技术，必须同日常运营方面的专门技术相匹配。从软件作为制造品到软件作为服务的变化是如此地根本，以至于软件将不再能完成任务，除非每日加以维护。Google必须持续抓取互联网并更新其索引，持续滤掉链接垃圾和其他影响其结果的东西，持续并且动态地响应数千万异步的用户查询，并同步地将这些查询同上下文相关的广告相匹配。</p>
<p>所以，Google的系统管理、网络、和负载均衡技术，可能比其搜索算法更被严加看管，也就不足为奇了。Google在自动化这些步骤上的成功是其同竞争者相比更有成本优势的一个关键方面。</p>
<p>同样也不足为奇的是，像Perl、Python、PHP、和当前的Ruby这样的脚本语言在Web 2.0公司中扮演着重要角色。Sun公司的第一个网管哈桑&#183;施罗德（Hassan Schroeder）曾对Perl有一个著名的形容：&#8221;互联网的管道胶带&#8221;（the duct tape of the internet）。事实上，动态语言（常常被称为脚本语言，并被软件制品时代的软件工程师所贬低），是系统和网络管理员，以及创建可经常更新的动态系统的程序开发者们所喜爱的工具。</p>
<p>2. 用户必须被作为共同开发者来对待，这是从对开放源码开发实践的一种反思中得出的（即便所涉及的软件不太可能以开放源码授权方式来发行）。开放源码的格言 &#8220;早发布并常发布&#8221;（release early and release often）事实上已经演变成一种更为极端的定位&#8221;永远的测试版&#8221;（the perpetual beta）。其中产品在开放状态下开发，新的功能以每月、每周、甚至每天的速度被加入进来。Gmail、Google Maps、Flickr、del.icio.us，和其他类似的服务，可能会在某个阶段打着测试版的标识多年。</p>
<p>故此，实时地监测用户行为，来考察哪些新特性被使用了，以及如何被使用的，将成为另外一种必须的核心竞争力。一位工作于一个主要在线服务网络商的开发者评论道： &#8220;我们每天在网站的某些部分提供两到三个新的特性，而且如果用户不采用它们，我们就将其撤掉。如果用户喜欢它们，我们就将其推广到整个网站。&#8221;</p>
<p>Flickr的总开发师卡尔&#183;亨德森（Cal Henderson），近来透露了他们是如何在短至每半个小时就部署一个新版本的。显而易见，这是同传统方式有天壤之别的开发模式。虽然不是所有的网络程序都以像Flickr这样的极端方式来开发，但几乎所有网络程序都有一个同任何PC或者客户-服务器时代截然不同的开发周期。正因如此，ZDnet杂志才论断Microsoft不会打败Google：&#8221;Microsoft的商业模式依赖于每个人在每两到三年都升级他们的计算环境。Google的模式则依靠任何人每天在其计算环境中自行探索新东西。&#8221;</p>
<p>虽然Microsoft已经体现了从竞争中学习并最终做得最好的强大能力，但是毫无疑问这一次的竞争要求Microsoft（可以扩展到任何现存的软件公司）来成为一种在深入层面上显著有别的公司。天生的Web 2.0公司在享受自然而然的优势，因为它们不需要去摆脱陈旧的模式（及其相应的商业模式和营收来源）。</p>
<p><strong>5. 轻量型编程模型</strong></p>
<p>一旦网络服务的观念深入人心，大型公司将以复杂的网络服务堆栈来加入到纷争之中。这种网络服务堆栈被设计用来为分布式程序建立更可靠性的编程环境。</p>
<p>但是，就像互联网成功正是因为它推翻了许多超文本理论一样，RSS以完美的设计来取代简单的实用主义，已经因其简单性而成为大概是应用最广泛的网络服务，而那些复杂的企业网络服务尚未能实现广泛的应用。</p>
<p>类似地，Amazon.com的网络服务有两种形式：一种坚持SOAP(Simple Object Access Protocol，简单对象访问协议）网络服务堆栈的形式主义；另一种则简单地在HTTP协议之外提供XML数据，这在轻量型方式中有时被称为REST （Representational State Transfer，代表性状态传输）。虽然商业价值更高的B2B连接（例如那些在Amazon和一些像ToysRUs这样的零售伙伴之间的连接）使用 SOAP堆栈，但是根据Amazon的报道，95%的使用来自于轻量型REST服务。</p>
<p>同样的对简易性的要求，可以从其他&#8221;朴实的&#8221;网络服务中见到。Google近来的Google地图的推出就是一个例子。Google地图的简单AJAX（Javascript和XML的结合）接口迅速被程序高手们破译，被随即进一步将其数据混合到新的服务之中。</p>
<p>地图相关网络服务已经存在了一段时间，例如像ESRI那样的GIS（地理信息系统），以及从MapQuest和Microsoft的 MapPoint。但是Google地图以其简洁性而让世界兴奋起来。虽然从前销售商所支持的网络服务都要求各方之间的正式约定，但Google地图的实现方式使数据可以被捕获，于是程序高手们很快就发现了创造性地重用这些数据的方法。</p>
<p>这里有几条重要的经验：</p>
<ol>
    <li>支持允许松散结合系统的轻量型的编程模型。由企业开发的网络服务堆栈的复杂设计是用来促成紧密结合的。虽然这在许多情况下是必须是，但是许多最重要的应用程序可以事实上保持松散结合，甚至是脆弱的结合。Web 2.0的理念同传统的IT的理念迥然不同。
    <li>考虑聚合（syndication）而不是协调（coordination）。简单的网络服务，例如RSS和基于REST的网络服务，是用来向外聚合数据，但并不控制其达到连接的另外一端时发生的事情。这种想法是互联网本身的基础，一种对所谓端到端原则的反映。
    <li>可编程性和可混合性设计。像最初的互联网一样，RSS和AJAX这样的系统，都有此共同点：重用的障碍非常低。许多有用的软件事实上是开放源码的，而即便它不是，也没有许多东西来保护其知识产权。互联网浏览器的&#8221;查看源文件&#8221;选项，使得许多用户可以复制其他任何用户的网页；RSS被设计得使用户能够在需要的时候查看所需要的内容，而不是按照信息提供者的要求；最成功的网络服务，是那些最容易采纳未被服务创建者想到的新的方向。同更普遍的&#8221;保留所有权利&#8221; （all rights reserved）相比，随着创作共用约定而普及的&#8221;保留部分权利&#8221;（Some Rights Reserved）一词成为一个有益的指路牌。 </li>
</ol>
<p><strong>装配中的创新</strong></p>
<p>轻量型商业模型是对轻量型编程和轻量型结合的一种自然产物。Web 2.0的理念善于重用。一种像housingmaps.com这样的新服务，是通过将两个现存服务抓取到一起来简单地创建起来的。 Housingmaps.com还没有商业模式（目前为止），但对于许多小规模的服务，Google的AdSense（或Amazon的 associates fees计划，或者两者都是）为同类服务提供了营收模式。</p>
<p>这些案例为Web 2.0的另外一个关键原则提供了启发，我们将之称为&#8221;装配中的创新&#8221;。当商品组件充裕时，你可以通过以新颖的或者有效的方式来装配这些组件来创建价值。很像PC革命为硬件商品装配提供了许多创新的机会，其中像Dell这样的公司创造了这种装配的科学，并从而打败了那些商业模式上要求产品开发方面的创新的公司，我们相信Web 2.0为各个公司提供了，通过在利用和整合由其他人提供的服务方面逐渐完善，来赢得竞争的机会。</p>
<p><strong>6. 软件超越单一设备</strong></p>
<p>另外一个值得一提的Web 2.0特性是Web 2.0已经不再局限于PC平台这样一个事实。在对Microsoft的告别建议中，长期的Microsoft开发者戴夫&#183;斯塔兹（Dave Stutz）指出：&#8221;超越单一设备而编写的有用软件将在未来很长一段时间里获得更高的利润&#8221;。</p>
<p>当然，任何的网络程序都可被视为超越单一设备的软件。毕竟，即便是最简单的互联网程序也涉及至少两台计算机：一个负责网络服务器，而另一个负责浏览器。而且就如我们已经探讨过的，在将网络作为平台的开发中，把这个概念拓展到由多台计算机提供的服务而组成的合成应用程序中。</p>
<p>但是如同Web 2.0的许多领域一样，在那些领域中&#8221;2.0版的事物&#8221;（2.0-ness）并不是全新的，而是对互联网平台真正潜能的一种更完美的实现，软件超越单一设备这一说法赋予我们为新平台设计程序和服务的关键性的洞察力。</p>
<p>迄今为止，iTunes是这一原则的最佳范例。该程序无缝地从掌上设备延伸到巨大的互联网后台，其中PC扮演着一个本地缓存和控制站点的角色。之前已经有许多将互联网的内容带到便携设备的尝试，但是iPod/iTunes组合却是这类应用中第一个从开始就被设计用于跨越多种设备的。TiVo则是另外一个不错的例子。</p>
<p>iTunes和TiVo也体现了Web 2.0的其他一些核心原则。它们本身都不是网络程序，但都利用了互联网平台的力量，使网络成为其体系中无缝连接的、几乎不可察觉的一部分。数据管理显然是它们所提供的价值的核心。它们也是服务，而非打包的程序（虽然对于iTunes来说，它可以被用作一个打包的程序来仅仅管理用户本地的数据）。不仅如此， TiVo和iTunes都展示了一些集体智慧的方兴未艾的应用。虽然对于每个情况，其实验都是同网络IP入口的周旋。iTunes中只有有限的参与体系，虽然近来增加的播客（podcasting）将这一规则规律性了不少。</p>
<p>这正是我们希望看到伟大变革的Web 2.0领域中的一个，随着越来越多的设备正连接到这个新的平台中来。当我们的电话和汽车虽不消费数据但却报告数据时，可能会出现什么样的程序呢？实时的交通监测、快闪暴走族（flash mobs）、以及公民媒体，只不过是新平台的能力的几个早期警示。</p>
<p><strong>一篇Web 2.0的投资论文</strong></p>
<p>风险投资家保罗&#183;科德罗斯基（Paul Kedrosky ）写道：&#8221;关键在于去寻找一种你共识相左的，具有可操作性的投资&#8221;。有趣的是，我们注意到Web 2.0的每个方面都涉及到同共识的分歧：每个人都在强调保持数据隐私的重要性，而Flickr/Napster等等，却使其公开化。这并非只是为了分歧而分歧（比如追求宠物食在线），而是在可以从中创建出一些东西的地方发生分歧。Flickr缔造了社区，Napster创造了收藏的广度。</p>
<p>另外一种看待这种现象的方式，就是成功的公司都放弃了一些昂贵但被认为重要的东西，以便免费获得一些有价值的曾经昂贵过的东西。例如，维基百科全书放弃了集中的编审控制，以作为对速度和广度的回报。Napster放弃了&#8221;目录册&#8221;的想法（列出所有销售商正在销售的歌曲），并因此获得了广度。Amazon 放弃了用于一个实体店面的想法，却从而服务于整个世界。Google放弃了大宗用户（开始的时候），却得到了80%的，其要求从前未被满足的用户。下面的说法很有一些合气道（借力打力）的精神：&#8221;你知道，你是对的&#8211;整个世界的人都绝对可以更新这篇文章。而且你猜怎么着，这对你是个坏消息&#8221;。</p>
<p>&#8211;内森&#183;托克英顿（Nat Torkington）</p>
<p><strong>7. 丰富的用户体验</strong></p>
<p>最早可以追溯到1992年魏裴（Pei Wei）开发的Viola浏览器，互联网就被用来在网页浏览器中传送&#8221;小程序&#8221;（applet）和其他一些活动内容。1995年Java的引入就是围绕着这样的小程序的传送。JavaScript和后来的DHTML都被作为轻量型方式引入，来为客户端提供可编程性和丰富的用户体验。几年以前， Macromedia缔造出&#8221;丰富的互联网应用程序&#8221;（Rich Internet Applications）一词（该词也被Flash的竞争者开放源码的Laszlo系统使用），以便凸显Flash不仅可传送多媒体内容，而且可以是 GUI（图形用户界面）方式的应用程序体验。</p>
<p>然而，互联网传递整个应用程序的潜能在Google引入Gmail之前，一直没有成为主流，紧接着就是Google地图程序，一些基于互联网的带有丰富用户界面以及PC程序等同的交互性的应用程序。在网络设计公司 Adaptive Path的耶希?詹姆斯?加莱特（Jesse James Garrett）的一个讨论会论文中，Google所使用的这组技术被命名为AJAX。他写道：</p>
<p>Ajax不是一项技术。它其实是几项技术，每项技术自身都很繁荣，它们以强有力的全新方式结合起来。Ajax涵盖：</p>
<ul>
    <li>运用XHTML和CSS实现基于各种标准的展示。
    <li>运用文档对象模型（Document Object Model）实现动态显示和交互。
    <li>运用XML和XSLT实现数据交换和操作。
    <li>运用XMLHttpRequest实现异步数据检索。
    <li>JavaScript将所有这些绑定到一起。 </li>
</ul>
<p>AJAX也是Web 2.0程序的一个关键组件，例如现在归属Yahoo!的Flickr，37signals的程序basecamp和backpack，以及其他 Google程序，例如Gmail和Orkut。我们正在步入一个史无前例的用户界面创新阶段，因为互联网开发者们终于可以创建，像本地基于PC的应用程序一样丰富的网络程序了。</p>
<p>有趣的是，许多现在正被探索的功能已经存在了很多年了。90年代后期，Microsoft和 Netscape，都对现在终于被认识到的那些功能有所洞察，但是它们对于所要采用的标准的争斗，使得实现跨浏览器的应用程序变得困难。仅在当初 Microsoft确定无疑地赢得了浏览器之战的时候，而且那时事实上只需要针对一个浏览器标准，编写这种程序才成为可能。同时，虽然Firefox在浏览器市场中重新引入了竞争，但至少在目前我们还没有看到对互联网标准的破坏性的争夺以至于我们倒退到90年代。</p>
<p>在接下来的几年中，我们会看到许多新的网络程序，不仅确实是新颖的程序，而且是对PC程序丰富的网络再现。到目前为止，每个平台的变革也都为改变那些在旧平台中占主导地位的程序的领导地位创造了机会。</p>
<p>Gmail已经在电子邮件中提供了一些有意思的创新，将互联网的力量（随处可访问、深层的数据库能力、可搜索性）与在易用性方面同PC界面接近的用户界 面相结合。同时， PC平台上的其他邮件程序，正在从另一端通过增添IM和呈现能力，来蚕食着这一领域。我们离集成通信客户端有多少远呢？这些集成通信客户端应是整合了电子邮件、即时通信和手机，并且应使用VoIP以便向网络程序的丰富功能中添加语音能力。这种竞赛已经开始。</p>
<p>我们也很容易看 到Web 2.0是如何重新打造地址簿的。一个Web 2.0风格的地址薄将把PC或电话上的本地地址簿，仅仅当作一种你显式要求系统记忆的联系人的缓存。同时，一个基于互联网的Gmail风格的异步代理，将保存发送或者接收的每个消息，每个电子邮件地址和每个使用过的电话号码，并且创造出社交网络的启发性算法，来决定当一个答案不能在本地缓存中找到时，应该提供哪个作为替代。在缺少答案的情况下，该系统会查询更广阔的社交网络。</p>
<p>一个Web 2.0的字处理程序将会支持维基风格的协作编辑，而不仅仅是处理独立的文档。但是该程序也会支持我们期望在基于PC的字处理器中得到的那种丰富格式。Writely是这种程序的一个优秀范例，虽然它尚未引起广泛关注。</p>
<p>此外，Web 2.0革命不会局限于PC程序。例如，在CRM这样的企业级应用程序中，Salesforce.com展示了网络是如何被用来以服务的方式来传递软件的。</p>
<p>对新的进入者来说，竞争机会在于充分开发Web 2.0的潜能。成功的公司将创建可以向其用户学习的程序，利用可供参与的体系来建立一种决定性的优势，不仅在软件的界面方面，而且在共享数据的丰富程度方面。</p>
<p><strong>Web 2.0公司的核心竞争力</strong></p>
<p>在探索上述七大原则的过程中，我们已经强调了Web 2.0的一些主要特性。我们探讨的每一个例子都体现着这些原则中的一个或多个，但是可能不满足其他的原则。因此，让我们通过总结我们认为是Web 2.0公司核心竞争力的一些方面，来结束本文。</p>
<ul>
    <li>服务，而不是打包的软件，具有高成本效益的可伸缩性。
    <li>控制独特的、难以再造的数据源，并且用户越多内容越丰富。
    <li>把用户作为共同开发者来信任。
    <li>利用集体智慧。
    <li>通过客户的自服务来发挥长尾的力量。
    <li>软件超越单一设备。
    <li>轻量型用户界面、开发模式、和商业模式。 </li>
</ul>
<p>今后一个公司要宣称是&#8221;Web 2.0&#8243;，就要将其特性同上述列表相测试。越符合就越名副其实。不过要记住，在某一个领域的卓越表现，可能会比对七大原则中的每个都浅尝则止，要更为有效。</p>
<p><strong>Web 2.0的设计模式</strong></p>
<p>在&#8221;模式语言&#8221;（A Pattern Language）一书中，克里斯多夫?亚历山大（Christopher Alexander）为精炼描述对于体系结构问题的解决方案，开了一种格式上的处方。他写道：&#8221;每个模式都描述着一种在我们的环境中一遍又一遍地出现的问题，并因此描述了对该问题的核心解决方案。以此方式你可以使用该方案上百万次，而从不需要重复作同样的事情。&#8221;</p>
<p>1. 长尾</p>
<p>小型网站构成了互联网内容的大部分内容；细分市场构成了互联网的大部分可能的应用程序。所以，利用客户的自服务和算法上的数据管理来延伸到整个互联网，到达边缘而不仅仅是中心，到达长尾而不仅仅是头部。</p>
<p>2. 数据是下一个Intel Inside</p>
<p>应用程序越来越多地由数据驱动。因此：为获得竞争优势，应设法拥有一个独特的，难于再造的数据资源。</p>
<p>3. 用户增添价值</p>
<p>对互联网程序来说，竞争优势的关键在于，用户多大程度上会在你提供的数据中，添加他们自己的数据。因而，不要将你的&#8221;参与的体系&#8221;局限于软件开发。要让你的用户们隐式和显式地为你的程序增添价值。</p>
<p>4. 默认的网络效应</p>
<p>只有很小一部分用户会不嫌麻烦地为你的程序增添价值。因此：要将默认设置得使聚合用户的数据，成为用户使用程序的副产品。</p>
<p>5. 一些权力保留</p>
<p>知识产权保护限制了重用也阻碍了实验。因而，在好处来自于集体智慧而不是私有约束的时候，应确认采用的门槛要低。遵循现存准则，并以尽可能少的限制来授权。设计程序使之具备可编程性和可混合性。</p>
<p>6. 永远的测试版</p>
<p>当设备和程序连接到互联网时，程序已经不是软件作品了，它们是正在展开的服务。因此，不要将各种新特性都打包到集大成的发布版本中，而应作为普通用户体 验的一部分来经常添加这些特性。吸引你的用户来充当实时的测试者，并且记录这些服务以便了解人们是如何使用这些新特性的。</p>
<p>7. 合作，而非控制</p>
<p>Web 2.0的程序是建立在合作性的数据服务网络之上的。因此：提供网络服务界面和内容聚合，并重用其他人的数据服务。支持允许松散结合系统的轻量型编程模型。</p>
<p>8. 软件超越单一设备</p>
<p>PC不再是互联网应用程序的唯一访问设备，而且局限于单一设备的程序的价值小于那些相连接的程序。因此：从一开始就设计你的应用程序，使其集成跨越手持设备，PC机，和互联网服务器的多种服务。</p>
<p><strong>奥莱理媒体公司（O&#8217;Reilly Media Inc.) 主席兼CEO 提姆&#183;奥莱理（Tim O&#8217;Reilly）授权刊登,美国密西根大学资深软件分析师玄伟剑提供全文翻译。</strong></p>
<p><strong>节略版请参见1121期杂志</strong></p>
</div>
</div>
</div>
   <img src ="http://www.blogjava.net/yiqi801218/aggbug/183878.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/yiqi801218/" target="_blank">BlueSunshine</a> 2008-03-05 10:50 <a href="http://www.blogjava.net/yiqi801218/archive/2008/03/05/183878.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss>