CN1605182A - 用于网络高速缓存的方法和系统 - Google Patents

Abstract

本发明提供了一种用于高速缓存片段的方法、系统、设备和计算机程序产品。当在包含高速缓存管理单元的计算设备上接收到消息之后，高速缓存消息的消息体中的片段。对高速缓存管理单元上的该片段的后续请求产生高速缓存命中。无论计算设备充当位于整个网络中的客户机、服务器还是集线器，高速缓存管理单元同等地运行来支持片段高速缓存操作。换言之，片段高速缓存技术在整个网络中是统一的。高速缓存ID规则伴随着来自原始服务器的片段；高速缓存ID规则描述用于形成片段的唯一高速缓存ID，以使动态内容能够在远离原始服务器的位置被高速缓存的方法。

Description

用于网络高速缓存的方法和系统

技术领域

本发明涉及改进的数据处理系统，尤其涉及具有改进的网络资源分配的数据处理系统。更具体地，本发明提供了用于在计算机网络内高速缓存数据对象的方法和系统。

背景技术

因特网上发送的数据量以超过因特网用户数量增长或其交易数量增长的速度持续增长。这种增长的主要因素是万维网站点本身的不断变化的性质。在万维网的早期阶段，Web页面主要包括静态内容，例如文本，图象和到其它站点的链接。用户与Web站点交互的范围是下载HTML页面及其元素。由于不管谁请求了页面，内容通常均相同，Web服务器支持许多用户的工作相对简单。然而当前趋势是走向交互式Web站点，其中Web站点的内容和外观随特定用户和/或用户输入而改变。这对于支持在线产品选择和购买的电子商务站点尤其如此。这种站点与较早的Web站点的区别在于其更多的动态内容。这种站点的一个常见的例子是在许多因特网商业站点上提供的“在线目录”。每个登录到站点以进行购买的客户有机会浏览目录，甚至细读数千种产品的详细信息。表面上，Web服务器必须为每个购物者维护和更新唯一的Web页面。因特网用户因这种可定制的交互式Web站点而得到方便，并且客户预期无疑为在Web页面中进一步使用动态内容提供了动力。

因特网Web页面中动态内容使用的增长为Web站点的操作人员带来某些实施保障问题。今天的电子商务站点的特征在于非常高的“浏览-购买比率”。对于购物站点，典型的比率是每60次不更新持久商业记录的交互(“请求”或“查询”)才有一次更新该记录的交互(“交易”)-浏览产品说明是请求的例子，而购买是交易的例子。动态内容越来越流行的一个结果是，虽然交易数量以可预测和可管理的速度增长，然而请求数量的增长是爆发式的。包含动态内容的Web页面的高用户交互性质导致每次交易的大量请求。那些Web页面内的动态内容通常是在每当用户请求浏览这些Web页面中的一个时产生的。这导致在单次会话期间必须为用户准备和传送巨大数量的内容。

用户的期望促使站点提供方响应其请求而迅速提供动态Web内容。如果潜在客户感到Web站点反应过慢，他们可能终止访问站点，从而导致业务的丧失。然而，处理巨大量的因特网业务可能对电子商务施加过度的财务负担。使电子商务满足潜在客户日益增长的信息要求的最直接方式是通过增加更多计算机、存储器和带宽来加强其服务器端的硬件。这个解决方案昂贵且低效，因而使人望而却步。

更节省成本的方案是高速缓存，这是一种通常在数字计算机中用来增强性能的技术。计算机中用于数据存储的主存储器通常比处理器慢得多。为在数据访问期间适应较慢的存储器，通常向处理器的正常指令时序加入等待状态。如果需要处理器始终从主存储器访问数据，其性能将受到显著损害。高速缓存技术使用较小但非常快速的存储缓冲器(被称作“高速缓存”)来利用被称为“数据局部性”的统计特性，以克服主存储器访问瓶颈。数据局部性是指连续数据访问涉及相同的通用存储器区域的常见倾向。这个特性有时被表述为“80/20”规则，其中80％的数据访问将针对相同的20％的存储器。

以下例子虽然与Web无关，却一般地说明了高速缓存的有益效果。假定有一个计算机程序将两个大数组相乘，并且希望考虑到可能修改计算机以允许其更快速地运行程序的方式。最直接的修改是增加处理器速度，然而这种方式是有局限的。程序中每个单独的乘运算需要处理器从存储器获取两个操作数，计算乘积，并且接着将结果回写到存储器。当处理器速度较高时，由于计算所需的时间大大减少，限制因素变成处理器与存储器交互所需的时间。虽然可以使用更快速的存储器，然而使用大量非常高速的存储器以满足所有的计算机存储器需求会非常不切实际和昂贵。有幸的是，矩阵乘法程序表现出高数据局部性，因为两个输入数组中的每个的元素占据某个存储器范围内的连续地址。因此，不是使用大量的非常高速的存储器，而是使用少量的这种存储器作为高速缓存。在程序开始时，来自主存储器的输入数组被传递到该高速缓存缓冲区。当程序执行时，处理器从高速缓存获取操作数并且将相应结果回写到高速缓存。由于数据访问使用高速度的高速缓存，处理器能够比使用主存储器时更加快速地执行程序。事实上，高速缓存的使用导致速度提高的程度几乎就象升级了全部主存储器一样，不过是以显著降低的成本。注意，仅当数据局部性的假定成立时高速缓存系统才会见效；如果处理器必须频繁地到高速缓存外部访问数据，则高速缓存的速度优势会丧失。

使用数据高速缓存的另一个问题是“高速缓存一致性”。如上所述，数据通常被复制到高速缓存以允许进行更快速访问。高速缓存中的每个数据是主存储器中原始版本的相同副本。如果计算机内的一个应用程序访问主存储器中的变量，同时另一个应用程序访问高速缓存中的副本，则可能出现问题。如果变量的任一版本以和另一个版本无关的方式发生改变，则高速缓存失去一致性，这可能产生有害结果。例如，如果变量是指向关键操作系统数据的指针，则可能发生致命错误。为避免出现这种情况，必须监视高速缓存的状态。当修改高速缓存中的数据时，使主存储器中的“陈旧”副本临时无效，直到它们能够被更新。因此，任何配备高速缓存的系统的一个重要方面是保持高速缓存一致性的过程。

鉴于这些公知问题和有益效果，已经在因特网或专用网络，包含所谓的内容分发网络(CDN)中的各个位置上的数据处理系统内实施了高速缓存。事实表明，Web业务非常适于高速缓存。大多数电子商务因特网业务包括从服务器发送到用户而不是从用户发送到服务器的数据。在大多数情况下，用户向Web站点请求信息，而用户向Web站点发送信息的情况相对很少。例如，用户频繁请求Web页面，而相对很少提交存储在Web站点上的个人信息或交易信息。因此，大多数的数据业务显示出良好的高速缓存一致性特性。此外，因为用户往往在转移到不同Web站点之前浏览和重新浏览单个Web站点的内容达一定时间，大多数的数据业务显示出良好的数据局部性特性。另外，许多用户往往请求相同的信息，因而在某个位置高速缓存信息会比重复地从数据库检索该信息更加高效。另外，大多数Web应用对数据的最新程度的要求相对宽松。例如，当产品价格改变时，此改变滞后几分钟生效是可接受的，即高速缓存一致性可以是不那么完美的，这一点也使高速缓存更有价值。

下面的讨论能够大略说明高速缓存Web内容的有益效果。来自客户端浏览器的每个请求可能流经位于整个因特网中的多个数据处理系统，例如防火墙、路由器和各种服务器，所述服务器的例子有中间服务器、呈现服务器(例如读取静态内容、建立动态页面)、应用服务器(例如检索页面数据、执行更新)和后端服务器(例如数据库、服务和传统应用)。所有这些处理阶段具有相关的成本和性能考虑。

如果根本没有高速缓存，则所有请求一直流到呈现服务器，呈现服务器能够满足某些请求，因为它们不需要动态内容。不幸的是，许多请求还需要应用服务器和后端服务器进行处理以进行更新或获得动态内容页面的数据。

然而，请求只需要传播其得到满足所需要的那么远，因而使用高速缓存，尤其是在应用提供方的站点内，能够提高性能。例如，中间服务器中的高速缓存可以满足大多数请求，这样只有少数请求传播到呈现服务器。呈现服务器中的高速缓存可以处理某些到达呈现服务器的请求，这样只有少数请求传播到应用服务器。由于应用服务器通常是事务处理型的，在应用服务器内可以实现有限的高速缓存。然而总体上说，通过在应用提供方的站点内适度使用高速缓存，可以大大节省成本。

考虑到高速缓存的优势，可以使用高速缓存技术改进包含动态Web内容的Web站点的响应特性，而无需对服务器和其它硬件进行如上所述的大的投资。然而，有关高速缓存适用性的主要考虑因素是Web内容改变的频率。一般地，当访问速度增加而更新速度降低时，高速缓存的实施变得可行。更具体地，当用户频繁地从Web站点检索静态内容并且很少发送要存储在Web站点上的数据时，Web内容的高速缓存是可行的。然而，如果Web站点包括大量动态内容，则Web站点被内在地构造成其内容频繁改变。在这种情况下，Web站点内高速缓存的更新速度显著增加，从而消除了尝试高速缓存Web站点的内容的优势。

已经提出和/或实现了用于高效高速缓存企业内的动态内容的各种解决方案。这些在Web应用服务器内高速缓存Web内容的技术明显提高了吞吐量和响应时间方面的性能。

当获得在电子商务Web站点内高速缓存动态内容的显著优点之后，在整个网络本身实现协作高速缓存，即所谓的“分布式高速缓存”，会是有利的，因为在更接近用户的位置高速缓存内容可在响应时间或时延方面产生更加远为显著的有益效果。然而，分布式高速缓存解决方案必须考虑公知的高速缓存问题。不加选择的布置和实施高速缓存会以不利于节省成本的方式提高性能。决定高速缓存效率的重要因素包括高速缓存大小、高速缓存命中路径长度(cache hit path length)、维护高速缓存内容所需的工作量、以及数据请求方和数据位置之间的距离。

在高速缓存的大小方面，存储器和盘空间的大小不断提高，但是它们从未大到不需要考虑其限制的程度。换言之，分布式高速缓存技术不应该假定大量存储器和盘空间可用于高速缓存，需要小的高速缓存通常比需要大的高速缓存更为可取。另外，存储器和盘带宽的提高速度慢于其大小的提高速度，并且任何高速缓存越来越大量的数据的尝试均会最终受到带宽因素的限制。

在高速缓存命中路径长度方面，分布式高速缓存解决方案最好应当包括轻型运行时应用，该运行时应用可以被容易地部署，然而以最小处理量确定高速缓存命中，使得高速缓存命中的吞吐量非常大。分布式高速缓存应用的期望形式不应该与同样在接近最终用户的位置“高速缓存”数据的分布式应用的其它形式相混淆。换言之，存在其它形式的、受益于将应用的各个部分及其相关数据分布到整个因特网的许多方式中的一个的应用。例如，整个应用及其相关数据库可以被复制到不同位置，并且进行部署的企业随后可以根据需要同步数据库和维护应用。在其它情况下，可以使用插件、JavaScript^TM或类似机制将应用的只读显示部分及其相关数据分布到基于客户端的浏览器，同时将业务逻辑保留在受保护的主机站点上。

在维护高速缓存内容所需的工作量方面，服务企业内的高速缓存改进了吞吐量或成本，即每秒处理的请求数量或所需服务器硬件的数量，因为每个请求需要完成的工作得到减少。在服务企业内，高速缓存的位置最好更接近企业的入口点，因为这会降低企业内任何系统的处理量，从而增加任何改进。例如，接近分配器的高速缓存能够比应用服务器内的高速缓存远为更加有效。服务企业内的高速缓存在某种程度上增加了时延，但是这通常是次要的，因为服务企业内的时延通常远小于因特网上的时延。对服务企业外部的健壮分布式高速缓存技术的考虑与这个和其它问题相纠缠。

在数据请求方和数据位置之间的距离方面，因特网中的用户可见时延主要由用户和内容之间的距离决定。这个距离更大程度上由路由跳数而不是物理距离来确定。当在诸如因特网服务提供商(ISP)的因特网的“边界”上高速缓存内容时，显著降低了用户可见时延。对于大的内容，例如多媒体文件，也可以显著降低带宽要求。健壮的分布式高速缓存解决方案应当尝试在接近用户的位置高速缓存数据。

由于用户在地理上是分散的，在接近用户的位置高速缓存内容意味着必须在整个因特网中的ISP和交换点(exchange point)的多个高速缓存中复制内容。一般说来，这可以降低高速缓存机制对内容安全性和内容更新方式，即高速缓存一致性的控制。由于服务企业内的高速缓存机制表面上在单个组织的控制下，所以能够相对容易地维护服务企业内的一致性高速缓存。然而，同时维护服务企业内部和外部的高速缓存显著增加了保证高速缓存一致性的难度和所需的工作量。虽然使用例如CDN的内容发布商(其中在远为更加受控的网络环境而不是公共因特网内出租和维护高速缓存空间)能够使安全性和一致性问题最小化，然而这种解决方案事实上取消了在公共因特网中使用开放式标准而获得的某些优势。

分布式高速缓存技术最好应当能够适当考虑企业边界而实现，并且还能够以协作的方式在整个因特网中实现。另外，高速缓存应当可部署在可能被确定为必要的各种重要位置，例如在最终用户附近(例如在客户端浏览器中)，在服务企业的分配器附近，在Web应用服务器内，或它们之间的任何地方。此外，该技术应当遵从规范，使得不同组织能够根据本地系统要求构造分布式高速缓存规范的不同实现。

以片段的形式编写和发布Web内容的趋势使有关任何可能健壮的分布式高速缓存解决方案的问题复杂化了。一部分内容被放置到一片段中，并且较大的内容实体，例如Web页面或其它文档，由一些片段组成，尽管内容实体也可以由单个片段组成。片段可以分别存储，并且随后在需要时装配到较大内容实体中。

这些运行时的优点被维护和使用片段的其它方面的复杂度所抵消。可以为片段分配不同的生存期，从而需要一致性无效机制。另外，虽然片段可以被用来分离内容的静态部分和内容的动态部分，使得静态内容可以被有效高速缓存，然而必须面临上述涉及动态内容的高速缓存的问题。最重要的是，片段装配一直限于企业边界内的位置。

因此，拥有支持片段和其它对象的高速缓存的健壮的分布式高速缓存技术会是有利的。此外，这样的方式尤其有利，其中在整个网络的诸高速缓存站点上协同定位片段装配，并根据需要或多或少地考虑企业边界，从而降低服务企业上的处理负载，并且在需要时实现分布式计算的附加益处。另外，这样的方式会是有利的，其中使用一致的命名技术，使得能够在整个因特网中唯一地标识片段，即能够一致地维护分布式高速缓存。

作为健壮分布式高速缓存解决方案的另一个问题，任何可能的解决方案均应当考虑现有编程模型的问题。例如，可能提出一种分布式高速缓存技术，其需要用与该分布式高速缓存技术协同工作的新编程模型来替换现有的Web应用服务器的编程模型。最好是分布式高速缓存技术的实现会适应各种编程模型，从而避免在编程模型中间有任何偏袒。

这样的方式会是有利的，其中分布式高速缓存技术的实现导致降低的片段高速缓存大小，这种降低的高速缓存大小可以由轻型过程在整个因特网中以标准方式极少考虑高速缓存位置地维护。另外，分布式高速缓存技术兼容于现有编程模型和因特网标准会尤其有利，这样分布式高速缓存技术的实现能够与还没有实施分布式高速缓存技术的其它系统互操作。发明内容

根据第一方面，本发明提供了一种用于在网络中的数据处理系统上处理对象的方法，该方法包括：在计算设备上接收第一消息；和确定第一消息中的消息头指示第一消息涉及一片段。

根据第二方面，本发明提供了一种用于在网络中的数据处理系统上处理对象的设备，该设备包括：用于在计算设备上接收第一消息的装置；和用于确定第一消息中的消息头指示第一消息涉及片段的装置。

根据第三方面，本发明提供了计算机可读介质中的用于在网络中的数据处理系统中处理对象的计算机程序产品，该计算机程序产品包括：用于在计算设备上接收第一消息的指令；和用于确定第一消息中的消息头指示第一消息涉及片段的指令。

最好还确定第一消息中的消息头指示第一消息的消息体部分是片段。

来自第一消息的片段最好被存储在由计算设备内的高速缓存管理单元维护的高速缓存中，其中高速缓存管理单元同等地运行来支持片段高速缓存操作，无论计算设备充当位于整个网络中的客户机、服务器还是集线器。

最好还确定第一消息中的消息头指示片段是可高速缓存的。在这种情况下，可选地，第一消息具有表明片段不可高速缓存到不支持片段的高速缓存管理单元的指示，和表明片段可高速缓存到支持片的段高速缓存管理单元的指示。例如，第一消息具有HTTP Cache-Control(高速缓存控制)头，此Cache-Control头具有针对不支持片段的高速缓存管理单元的不高速缓存指令和针对支持片段的高速缓存管理单元的进行片段高速缓存的指令。

如果在计算设备上接收到第二消息，其中第二消息包括对所述片段的请求，则最好搜索高速缓存并且从高速缓存获取片段。接着通过第三消息向第二消息的发起方发送片段，而无需向其目的地址发送第二消息。

可选地，第二消息包含指示在返回第三消息之前不必在计算设备上进行页面装配操作的信息。

可选地，第二消息具有这样的消息头，其具有指示第三消息会被具有支持片段的高速缓存管理单元的第二计算设备接收的指令。

最好在发送第三消息之前在计算设备上执行页面装配操作。

最好在计算设备上执行页面装配操作以形成装配的片段。例如，确定片段是否是包含针对下一级片段的链接的最高级片段。接着在确定片段是包含针对下一级片段的链接的最高级片段时获取下一级片段。最终，最高级片段和下一级片段被合并成装配的片段。

可选地，下一级片段的内容被嵌入到最高级片段的内容中。此外，可以根据最高级片段的属性值和下一级片段的属性值产生装配的片段的属性值。另外，可以根据最高级片段的头值或指令和下一级片段的头值或指令计算装配的片段的头值或指令。

最好产生包含装配的片段的第四消息，其中第四消息是HTTP(超文本传输协议)应答消息。

最好为最高级片段和下一级片段确定最短到期时间，并且在第四消息中将“Expires”(到期)头设定为该最短到期时间。

可选地，为最高级片段和下一级片段确定它们中最小的最大有效期，并且在第四消息中将“Cache-Control:max-age”(高速缓存控制：最大有效期)指令设定为该最小的最大有效期。

可选地，为最高级片段和下一级片段计算内容长度值的和，并且在第四消息中将“Content-Length”(内容长度)头设定为该内容长度值的和。

可选地，为最高级片段和下一级片段确定最近修改时间，并且在第四消息中将“Last-Modified”(最近修改)头设定为该最近修改时间。

可选地，从第一消息获取一组依赖关系标识符，其中依赖关系标识符是由发出片段的服务器产生的，并且以和该片段的源标识符相关联的方式存储该组依赖关系标识符。在这种情况下，可选地，可以接收一无效请求消息，从该无效请求消息中获得一依赖关系标识符。这使得能够确定与该依赖关系标识符相关的一组片段，并且因此可以从高速缓存中清除所确定的该组片段。

最好可根据第一消息确定一组片段高速缓存规则，并且根据片段高速缓存规则产生片段的高速缓存标识符。在这种情况下，例如，可以使用高速缓存标识符来唯一标识片段。进一步地，可以使用所产生的、片段的高速缓存标识符执行存储操作。

可选地，获得与片段相关的URI(统一资源标识符)的至少一路径部分以形成基础高速缓存标识符，并且一片段高速缓存规则被施加到基础高速缓存标识符以形成片段的高速缓存标识符，其中片段高速缓存规则包括一组被用来获得附加到基础高速缓存标识符上的名称-值对的查询参数名和/或cookie名。

根据第四方面，本发明提供了一种用于在网络中的数据处理系统上处理对象的方法，该方法包括：在服务器上接收请求消息，其中请求消息包括片段的源标识符；产生包括片段的应答消息；以及在应答消息中插入指示请求消息涉及片段的消息头。

根据第五方面，本发明提供了一种用于在网络的数据处理系统上处理对象的设备，该设备包括：用于在服务器上接收请求消息的装置，其中请求消息包括片段的源标识符；用于产生包括片段的应答消息的装置；以及用于在应答消息中插入指示请求消息涉及片段的消息头的装置。

根据第六方面，本发明提供了计算机可读介质中的用于在网络中的数据处理系统中处理对象的计算机程序产品，该计算机程序产品包括：用于在服务器上接收请求消息的指令，其中该请求消息包括片段的源标识符；用于产生包括片段的应答消息的指令；以及用于在应答消息中插入指示第一消息涉及片段的消息头的指令。

指示应答消息的消息体部分是片段的消息头最好被插入到应答消息中，以作为指示应答消息的消息体部分是片段的消息头。

指示片段可高速缓存的消息头最好被插入到应答消息中。

指示片段不可高速缓存到不支持片段的高速缓存管理单元，以及指示片段可以高速缓存到支持片段的高速缓存管理单元的消息头最好被插入到应答消息中。

根据第七方面，本发明提供一种被计算设备用来定义通过网络发送的消息的数据结构，该数据结构包括：表明消息是请求消息或应答消息的指示符；和片段头，其包括指示消息将被支持片段的高速缓存管理单元处理的关键字，和指示处理消息的方式的一或多个片段头指令。

无论计算设备充当位于整个网络中的客户机、服务器还是集线器，支持片段的高速缓存管理单元最好位于计算设备内，并且同等地运行来支持片段高速缓存操作。

所要求保护的数据结构最好还具有这样的片段头指令，其用于包含在请求消息中，以指示处理了请求消息的计算设备具有支持片段的高速缓存管理单元。

该数据结构最好具有这样的片段头指令，其用于包含在应答消息中以指示一组依赖关系标识符，该组依赖关系标识符被原始服务器用来从由支持片段的高速缓存管理单元所维护的高速缓存中清除应答消息内的片段。

数据结构最好具有这样的片段头指令，其用于包含在应答消息中以指示一组片段高速缓存规则，所述规则被用来形成唯一标识应答消息中的片段的高速缓存标识符。

可选地，请求消息或应答消息是HTTP(超文本传送协议)请求消息或HTTP应答消息。

根据第八方面，本发明提供了被计算设备用来定义内容对象的数据结构，该数据结构包括：用于一标记语言元素的一组定界符；用于指示该标记语言元素是针对一片段的链接的关键字；和该片段的源标识符，其中该源标识符被支持片段的高速缓存管理单元用来获得该片段。

无论计算设备充当位于整个网络的客户机、服务器还是集线器，支持片段的高速缓存管理单元最好位于计算设备内，并且同等地运行来支持片段高速缓存操作。

该数据结构最好具有该片段的一替代源标识符，其中该替代源标识符可以被支持片段的高速缓存管理单元用来获得该片段。

数据结构最好具有一组附加到源标识符上的查询参数。

标记语言最好是SGML(标准通用标记语言)。标记语言元素最好兼容于HTML(超文本标记语言)。

提供了用于片段高速缓存的一种方法、系统、设备和计算机程序产品。当在包含高速缓存管理单元的计算设备上接收到消息之后，高速缓存该消息的消息体中的片段。对高速缓存管理单元上片段的后续请求产生高速缓存命中。无论计算设备充当位于整个网络中的客户机、服务器还是集线器，高速缓存管理单元同等地运行来支持片段高速缓存操作。换言之，片段高速缓存技术在整个网络中是统一的。

定义了FRAGMENT(片段)头，以被用于例如HTTP的网络协议内；该头使元数据与片段相关联，以用于涉及片段的处理和高速缓存的各种目的。高速缓存ID(标识符)规则伴随来自原始服务器的片段；高速缓存ID规则描述用于形成片段的唯一高速缓存ID，以使动态内容能够在远离原始服务器的位置被高速缓存的方法。高速缓存ID可以基于片段的URI(统一资源标识符)，但是高速缓存ID也可以基于查询参数和/或cookie。可以将不同于片段的高速缓存ID或URI的依赖关系ID与片段相关联，使得服务器可以启动从高速缓存中清除片段的无效操作。FRAGMENTLINK(片段链接)标签被用来规定在页面装配或页面呈现期间将插入的所包含片段在页面中的位置。

附图说明

现在参照本发明的如附图所示的优选实施例仅仅示例性地描述本发明，其中：

图1A描述了其中可以实现本发明的优选实施例的典型分布式数据处理系统；

图1B描述了可以在能够实现本发明的优选实施例的数据处理系统中使用的典型计算机体系结构；

图1C描述了其中在该整个分布式数据处理系统中实现了高速缓存的典型分布式数据处理系统；

图2图解了由片段组成的典型Web页面；

图3是根据本发明优选实施例的FRAGMENTLINK标签的形式化标准通用标记语言(SGML)定义；

图4是根据本发明优选实施例的FRAGMENT头的形式定义；

图5A-5G描述了对象获取路径上的一组支持片段和不支持片段的代理；

图6A描述了计算设备内用于支持片段的高速缓存的高速缓存管理单元；

图6B的流程图描述了可以被支持片段的高速缓存管理单元在处理包含片段的应答消息时使用的过程；

图6C的流程图步骤描述了用于确定消息体是否包含片段对象的优选方法；

图6D的流程图步骤描述了用于确定片段对象是否可高速缓存的更加具体的方法；

图6E的流程图步骤描述了用于确定片段对象是否可高速缓存的优选方法；

图6F的流程图描述了用于确定在特定计算设备上是否应当高速缓存一片段对象的方法；

图6G的流程图步骤描述了用于确定下游设备是否具有支持片段的高速缓存的优选方法；

图6H的流程图步骤描述了用于确定当前正在处理的片段对象是否应当只高速缓存在最接近目标用户/客户端设备的支持片段的高速缓存中的更加特定的方法；

图6I的流程图步骤描述了用于确定当前正在处理的片段对象是否应当只高速缓存在接近目标用户/客户端设备的支持片段的高速缓存中的优选方法；

图6J的流程图描述了用于确定在从当前计算设备返回应答消息之前是否需要进行页面装配的方法；

图6K的流程图步骤描述了用于确定当前正在处理的片段对象是否具有针对另一个片段的链接的更加具体的方法；

图6L的流程图步骤描述了用于确定当前正在处理的片段对象是否具有针对另一个片段的链接的另一方法；

图6M的流程图描述了用于执行页面装配的过程；

图6N的流程图描述了用于可选地将片段链接扩展为多个片段链接的过程；

图6O的流程图步骤描述了用于确定来自应答消息的当前片段中的片段链接是否指示其应当扩展为多个片段链接的优选方法；

图6P的流程图描述了用于根据与片段链接相关的信息将片段链接扩展为多个片段链接的过程；

图6Q的流程图描述了用于使用片段的源标识符获得片段的过程；

图6R的流程图描述了当在支持片段的高速缓存管理单元内高速缓存片段时执行的某些处理；

图6S的流程图描述了在片段被高速缓存在包含支持片段的高速缓存管理单元的计算设备上的情况下由该高速缓存管理单元用来获得该片段的过程；

图6T的流程图描述了用于组合与多个片段相关的头值和属性值的过程；

图6U的流程图描述了代表一系列针对头类型和属性值的组合函数的一组步骤；

图6V的流程图描述了可以由支持片段的高速缓存管理单元在处理请求消息时使用的过程；

图6W的流程图描述了可以由支持片段的高速缓管理单元在根据本发明优选实施例的实施方式处理无效消息时使用的过程；

图7A的方块图描述了Web应用服务器和客户机之间的某些数据流，以说明某些高速缓存执行片段装配的时机；

图7B的方块图描述了Web应用服务器和客户机之间的某些数据流，以说明一组设备如何能够被命令将片段高速缓存在最接近最终用户或客户端设备的高速缓存中；

图8A-8D的数据流图例描述了在客户机、中间的支持片段的高速缓存或服务器内发生的某些处理步骤，以说明能够使用本发明的优选实施例实现特定于角色或特定于类别的动态内容的高速缓存；

图9A的流程图描述了能够用来在单个请求消息中指定多个片段并且随后处理所述片段的过程；

图9B的流程图描述了能够用来在中间高速缓存管理单元处接收并且随后处理单个请求消息的过程；

图9C的流程图描述了Web应用服务器上用于处理多个片段的批请求消息的过程；

图10A-10D是一组例子，其示出了能够通过本发明的优选实施例实现的高速缓存大小的有利降低；以及

图11A-11H是一系列图例，其说明了本发明优选实施例的技术构造和使用唯一高速缓存标识符以存储和处理片段的方式。

具体实施方式

本发明涉及分布式片段高速缓存技术。通常，可以包括或涉及本发明优选实施例的设备包含多种数据处理技术。因此，在更详细地描述本发明优选实施例之前，作为背景资料，描述分布式数据处理系统内的硬件和软件部件的典型组织。

现在参照附图，图1A描述了数据处理系统的典型网络，每个数据处理系统可以实现本发明优选实施例的某个方面。分布式数据处理系统100包含网络101，网络101是可以被用来在一起连接到分布式数据处理系统100内的各种设备和计算机之间提供通信链路的介质。网络101可以包含例如电线或光纤光缆的固定连接，或通过电话或无线通信连接建立的临时连接。在描述的例子中，服务器102、服务器103和存储部件104一起被连接到网络101。另外，客户机105-107也连接到网络101。客户机105-107和服务器102-103可以表现为各种计算设备，例如大型机、个人计算机、个人数字助理(PDA)等等。分布式数据处理系统100可以包含其他的服务器、客户机、路由器、其它设备和端到端体系结构(未示出)。应当注意，图1A示出的分布式数据处理系统被考虑成完全能够支持各种端到端子网和端到端服务。

在描述的例子中，分布式数据处理系统100可以包含因特网，其中网络101代表使用各种协议彼此通信的网络和网关的全球集合，所述协议例如是轻量级目录访问协议(LDAP)、传送控制协议/网际协议(TCP/IP)、超文本传输协议(HTTP)、无线应用协议(WAP)等等。当然，分布式数据处理系统100也可以包含若干不同类型的网络，例如内部网、局域网(LAN)、无线LAN或广域网(WAN)。例如，服务器102直接支持客户机109和引入无线通信链路的网络110。启用网络的电话111通过无线链路112连接到网络110，并且PDA 113通过无线链路114连接到网络110。电话111和PDA 113也可以使用适当的技术，例如Bluetooth^TM无线技术，通过无线链路115直接在其之间传递数据，以创建所谓的个人局域网(PAN)或个人临时网络(personal ad-hoc network)。以类似的方式，PDA 113可以通过无线通信链路116向PDA 107传递数据。

本发明的优选实施例可以在各种硬件平台上实现；图1A被作为异类计算环境的一个例子并且不作为对本发明的结构限制。应当注意，后续例子具体参照了与服务器类型的功能相对的客户机类型的功能。然而如所公知的那样，某些计算设备同时表现出客户机类型的功能和服务器类型的功能，例如对等网络内的集线器或计算设备，即对等设备。本发明的优选实施例能够根据需要在客户机、服务器、对等设备或集线器上实现。

现在参照图1B，该图例描述了如图1A所示的、可以实现本发明优选实施例的数据处理系统的典型计算机体系结构。数据处理系统120包含连接到内部系统总线123的一或多个中央处理单元(CPU)122，所述内部系统总线123互连了随机存取存储器(RAM)124、只读存储器126和输入/输出适配器128，输入/输出适配器128支持各种I/O设备，例如打印机130、盘单元132或诸如音频输出系统等未示出的其它设备。系统总线123还连接提供对通信链路136的访问的通信适配器134。用户接口适配器148连接各种用户设备，例如键盘140、鼠标或诸如触摸屏、输入笔或话筒等未示出的其它设备。显示适配器144将系统总线123连接到显示器146。

本领域的普通技术人员会理解，可以根据系统实现方式改变图1B中的硬件。例如，系统可以具有一或多个处理器，例如基于Intel^Pentium^的处理器和数字信号处理器(DSP)，以及一或多个类型的易失和非易失存储器。也可以使用其它外围设备补充或取代图1B中描述的硬件。换言之，本领域的普通技术人员会期望在启用Web的或启用网络的电话内以及在全功能的台式工作站内发现某些类似部件或体系结构。所描述的例子并不意味着对本发明的优选实施例有结构性限制。

除了能够在各种硬件平台上实现之外，本发明的优选实施例可以在各种软件环境中实现。典型的操作系统可以被用来在每个数据处理系统内控制程序执行。例如，一个设备可以运行Linux^操作系统，而另一个设备包含简单的Java^运行时环境。典型的计算机平台可以包含浏览器，浏览器是公知的软件应用，用于访问具有各种格式和编码的文件、文档、对象或其它数据项，所述格式和编码例如是图形文件、字处理文件、可扩展标记语言(XML)、超文本标记语言(HTML)、手持设备标记语言(HDML)、无线标记语言(WML)。通常使用统一资源标识符(URI)寻址这些对象。URI的集合包括统一资源定位符(URL)和统一资源名称(URN)。

现在参照图1C，该图例描述了如图1A所示的典型分布式数据处理系统，其中在整个分布式数据处理系统中实现了高速缓存。分布式数据处理系统150包含产生对内容的请求的请求实体152。请求实体152可以是ISP，其服务于将所请求的内容用于各种目的的各种个人或机构客户或企业。当数据，例如一个请求从请求实体(使用实体)传送到应答实体(服务实体，例如原始服务器)时，数据被描述为“上行”传送。当数据，例如一个应答从应答实体传送到接收实体，数据被描述为“下行”传送。

来自客户端浏览器154的请求被分配器156路由，分配器156通过一组中间服务器158均匀地分配请求，以求在因特网交换点160处将请求转发通过因特网之前满足请求。每个浏览器154可以维持本地高速缓存，而每个服务器158支持正向代理高速缓存机制。因特网交换点160也包含中间服务器162和164，其每个可以维护高速缓存。在浏览器154或中间服务器158、160、162和164中实现高速缓存的各种考虑因素包含改进响应时间和/或降低带宽。

请求接着被从因特网交换点160路由到服务企业168中的分配器166。分配器166通过中间服务器170均匀分配传入请求，其中，中间服务器170尝试在转递请求到分配器172之前满足请求；每个中间服务器170支持反向代理高速缓存机制。由分配器172在Web应用服务器174中均匀分配未满足的请求，Web应用服务器174能够结合数据库服务或访问数据库176的其它应用来最终满足请求。在中间服务器170或Web应用服务器174中实现高速缓存的各种考虑因素包含提高吞吐量和/或降低成本。

在从服务企业到客户端设备的相反方向路由应答。应当注意，可以在使用企业内、整个因特网中、或服务企业内部署类似的中间服务器。还应当注意，离开客户机的、借以传递请求的每个相继阶段均增加了所感知的响应时间。

本发明的优选实施例可以在各种如上所述的硬件和软件平台上实现。然而更具体地，本发明的优选实施例是针对分布式片段高速缓存技术。但在更详细地描述本发明的优选实施例之前，简要提供有关静态和动态Web内容的某些背景信息。

包含静态文本和图形内容的Web页面的格式通常使用标记语言例如HTML来规定。标记由特殊代码或标签构成，这些代码或标签在因特网浏览器读取页面时控制文字和图象的显示。然而，Java服务器页面(JSP)和小服务程序(servlet)更适于包含动态内容的Web页面。

基本上，JSP是具有嵌入指令的标记语言文档，所述指令描述如何处理页面请求以产生包含该页面的应答。该描述混合了静态模板内容和被实现为单个文档内的Java代码的动态操作。通过使用JSP，也可以将Java代码内嵌(in-line)到页面中以作为服务器端小脚本(scriptlet)。换言之，Java标签被在Web页面上指定，并且在Web服务器上运行以便在Web页面被发送到发出请求的用户之前修改它。当编程逻辑相对较小时，这种方案是适当的。只要在标记语言文档内有超过微小数量的编程逻辑，就会丧失JSP的优势：将文档的呈现与和文档相关的业务逻辑相分离。为避免在标记语言文档中直接内嵌过量的代码，JSP启用了将业务逻辑隔离到能够在运行时使用简单的JSP标签访问的JavaBean中的能力。

更具体地，JSP使用类似标记的标签和使用Java编程语言编写的小脚本来封装产生页面的某些或所有内容的逻辑。应用逻辑可以驻留在基于服务器的资源，例如JavaBean组件中，其中页面通过这些标签和小脚本访问该资源。标记语言标签的使用允许以方便的、也可以由例如HTML页面构造器/编辑器的工具进行操纵的形式在标记语言文档内封装有用的功能。通过分离业务逻辑和呈现，支持了基于可重用组件的设计。JSP允许Web页面作者将动态内容模块插入到静态HTML模板中，于是大大简化了Web内容的创建。JSP是Sun公司的Java企业版(J2EE)编程模型的不可分割的部分。

应当注意，下面讨论的本发明优选实施例的例子可以使用JSP。然而也可以使用其它类型的服务器页面，例如微软公司的活动服务器页面(ASP)。

产品显示JSP呈现关于产品的数据。对特定产品例如扳手的请求将标识该JSP以及作为查询参数的产品ID。使用产品ID参数执行JSP会输出HTML的页面。当关于该产品的作为基础的数据改变，例如扳手价格增加时，该页面应当被无效。为此，必须通过将代表数据的依赖关系ID和页面相关联而在页面和数据之间建立依赖关系。

粒度是对于高效的高速缓存策略很重要的Web页面特性。Web页面的内容包括若干组件，其中一些组件可以频繁改变，而另一些是相对静态的。可以按照作为内容组成部分的“片段”来描述Web页面的粒度。可以通过各种方式，包括满足对JSP文件的HTTP请求，来创建片段。在上述例子中，产品显示页面是单个片段的页面。

现在参照图2，其中的方块图示出了由片段组成的Web页面。这个例子示出了片段粒度允许高速缓存页面的各个部分，即使某些片段是易失性的，并且已知是被时时更新的。换言之，各种Web内容从高速缓存而得到不同程度的益处。

产品显示Web页面包括动态内容片段200。最高级片段是Java服务器页面(JSP)204，其包含5个子片段206-214。片段208和212被高速缓存。应当注意，如附图中的时间线所示，从左到右地按照其基础数据变化速率的升序排列子片段。

产品URI 206是针对产品的图形交换格式(GIF或gif)图像文件的统一资源标识符(URI)链接。一带格式表格可以保存详细产品说明208。显示个性化问候语的片段210可以使用购物者名字。这个问候语经常改变，例如对于每个用户均不同，但是它仍然值得进行高速缓存，因为在给定购物者的会话过程中会重用其名字。

JSP 212创建简化的购物车。购物车JSP 212可以创建HTML表格以显示数据。这个内容会比个性化问候语210改变得甚至更频繁，因为它应当在购物者每次向其车中加入物品时进行更新。然而如果购物车出现在每个返回给购物者的页面上，则高速缓存JSP 212比每当显示购物车时检索相同数据更加高效。JSP204也可以包含在显示股票监视列表(stock watchlist)的Web页面上出现的广告214。由于广告每当请求页面时发生改变，更新速度会过高，以致不能从高速缓存中得到益处。

图1A-2示出各种分布式数据处理系统和动态内容的一例子以作为讨论本发明优选实施例的背景。如上所述，高效地高速缓存片段可能是困难的。本发明的优选实施例涉及这样一种技术，其使用对HTML和HTTP的扩展来高效地高速缓存片段，并特别关注于克服与高速缓存动态片段和个性化片段即动态内容相关的困难。

应当注意，下面提供的例子提及特定的协议规范，例如HTTP/1.1和HTML 4.1。然而，本领域的普通技术人员会理解，也可以使用其它提供了如本发明优选实施例所需的同等的特性和功能的最小集合的协议。

术语

“静态片段”被定义成无需使用查询参数或cookie便能够获得的片段。可以引用、高速缓存和/或完全从其URI获取静态片段。

“动态片段”是作为根据请求方提供的参数或cookie在服务器上的进行计算的结果而产生的片段。动态片段的一例子可以是体育比赛结果。动态片段的特征在于包括特定于站点的用户请求数据子集。

“个性化片段”也是作为根据请求方的参数或cookie进行计算的结果而产生的。个性化片段是动态片段的特例，因为其内容取决于用户。个性化片段可以是非易失的，例如帐号，也可以是易失的，例如购物篮(shoppingbasket)。对于定义和管理片段的目的来说，动态片段和个性化片段呈现出同等的问题；因此，术语“动态”和“个性化”将被可互换地使用。

“最高级片段”是没有嵌入任何其他片段中，但是本身可以将其它片段嵌入的片段。

“页面装配器”是从片段组成页面的程序。收集片段并组成页面的过程被称作“页面装配”。检查片段以确定是否应当获取附加片段并将其装配到文档中的过程此后被称作“分析”(parsing)，即使没有执行字面意义上的分析。例如，片段可以伴随有元信息，该元信息指出了应当获取以进行装配的附加片段，并且指定了附加片段应当插入的精确位置；为了附加片段而检查这种片段不一定是正式的计算机科学意义上的分析。

FRAGMENTLINK标签的定义

现在参照图3，根据本发明优选实施例提供了FRAGMENTLINK标签的标准通用标记语言(SGML)形式定义。FRAGMENTLINK标签被用来规定将在页面装配或页面呈现期间插入到文档中的片段的位置。新对象被分析为父文档的一部分，并且可以包含其自身的FRAGMENTLINK标签。下面讨论FRAGMENTLINK标签的属性的定义。

(应当注意，标记语言通常使用角括号(“<”和“>”)作为定界符。为了避免本文档的标记语言版本的可能的格式化问题或电子解释问题，已经在整个这个文档中使用花括号(“{”和“}”)作为替换定界符。作为另一个格式注解，某些长文本串的例子在这个文档中占据不止一个文本行；本领域的普通技术人员能够确定哪些文本例子被打算显示为单行文本，即使它们在本文档中看起来跨过了行边界。)

src=URI

SRC属性指定将被插入文档的片段的源位置；SRC属性充当用于获得片段的源标识符。如果该URI是相对URI，则绝对URI来自于父的路径和任何相关的BASE(基)标签。应当注意，如果在两个不同页面内包含单个共同的片段，这可以导致混乱。建议文档作者只编码片段URI的绝对路径名。URI的协议部分可以指定“cookie”，在这种情况下所插入的文本值是从所指出的cookie得到的。

alt=string

ALT属性指定在不能获取来自SRC属性的URI时将起替换作用的替换HTML文本。如果没有指定ALT属性并且不能获取SRC属性指定的片段，则不获取片段。

parms=%parmlist

PARMS属性指定空格定界的名字列表。每个名字对应于父片段的URI中可能存在的查询参数。当指定了PARMS属性时，认为SRC属性中指定的URI是不完整的。为了完成SRC属性，在PARMS属性中指出的每个查询参数的值应当从父文档获取，并且用来创建一名称-值对。这个名称-值对将被附加到SRC属性的URI上作为查询参数，以便完成SRC属性。如果指出的参数不存在于父URI中，则该参数不附加到片段的URI中。每个参数应当按照其在PARMS属性中出现的相同顺序附加到SRC属性的URI中。

foreach=quoted-string

FOREACH属性指定一引号中的串。该引号中的串的值最好是cookie的名字，该cookie的值是以空格定界的名称-值对的列表，其中名字和值被等号(“=”)或某种其它类型的等价定界符分隔。对于cookie中的每个名称-值对，产生一个新的FRAGMENTLINK标签，其SRC属性是添加了该名称-值对以作为查询参数的URI。这提供了用于自动产生仅在一个查询参数，例如用户股票监视列表的值方面有所不同的多个FRAGMENTLINK标签的简略的方法。

换言之，FOREACH属性将针对一个片段的单个链接扩展成针对多个片段的一组多个链接。每个名称-值对变成一对扩展参数名和扩展参数值。

showlink=(no|comment|CDATA)

SHOWLINK属性指定被用来包装所包含的片段数据的标签的名字。如果指定为“no”，则以没有包装标签的方式包含数据。如果指定为“comment”，则FRAGMENTLINK标签被改写为HTML注释。如果指定为任何其他值，则FRAGMENTLINK标签被改写为指定标签。不进行检查以验证CDATA是否为有效标签，于是留给页面作者来确切决定如何表示片段。如果省略SHOWLINK属性，则不进行包装。

id=ID

如果指定ID属性，则根据这里参考引用的、可在www.w3c.org处从环球网联盟(W3C)得到的“HTML 4.01规范”(W3C推荐，1999年12月24日)，其标识符值作为唯一名字被分配给所产生的表示这个片段的DOM元素内的该片段。

class=CDATA

如果指定CLASS属性，则根据HTML规范，它向表示这个片段的DOM元素分配一个类名字或一组类名字。

当装配页面时，页面装配器获取指定片段并且将其插入父对象中。SHOWLINK属性可被用来允许将插入数据包装在标签或HTML注释内。提供了嵌套片段，但是没有片段能够直接或间接地包含其本身。一片段空间内的所有片段的嵌套结构应当形成有向无环图(DAG)。任何伴随的HTTP应答头不被认为是文档部分，并且应当在插入到文档之前清除。高速缓存应当象对任何其他文档所做的那样保留这些头。可以指定替代片段URI。如果不能获取SRC片段，则获取和插入由ALT属性指定的片段。如果不能获取SRC属性的片段和ALT属性的片段二者，则可以象没有FRAGMENTLINK标签包含在原始文档中那样继续进行呈现。

使用动态或个性化片段的难处在于应当根据父页面所在的环境或上下文计算用来获取它们的URI。换言之，可能需要根据伴随父文档的查询参数动态创建URI；PARMS属性支持这个特性。PARMS属性包括来自父文档的将在获取片段时使用的查询参数名字列表。对于在PARMS属性中指出的每个参数形成名称-值对，并且将其作为(可能是另外的)查询参数附加到在FRAGMENTLINK标签的SRC属性中指定的URI上。这些名称-值对应当按照与其在PARMS属性中的出现相同的顺序被附加。另外，可能需要与父相关的cookie以正确获取或计算该片段。应当随同对片段的请求提供伴随父文档的所有cookie。

例如在使用股票监视列表时，经常需要许多FRAGMENTLINK标签，它们仅在一个查询参数值方面有所不同。可以使用FOREACH属性作为快速方法，以简化页面的编码，降低传输片段时的带宽要求，并且降低高速缓存中片段的大小。例如，假设产生了如下FRAGMENTLINK标签：{fragmentlink

src=″http://www.acmeInvest.com/stockQuote.jsp″

alt=″Error occurred trying to find stockQuote.jsp″

foreach=″issues″/}

并且假如存在如下cookie:

Cookie:issues=″stock=IBM stock=CSCO stock=DELL″

这会导致将FRAGMENTLINK标签扩展为一系列FRAGMENTLINK标签，这转而导致计算每个新产生的FRAGMENTLINK标签：{fragmentlink

src=″http://www.acmeInvest.com/stockQuote.jsp?stock=IBM″alt=″An error occurred trying to find stockQuote.jsp″/}{fragmentlink

src=″http://www.acmeInvest.com/stockQuote.jsp?stock=CSCO″

alt=″An error occurred trying to find stockQuote.jsp″/}{fragmentlink

src=″http://www.acmeInvest.com/stockQuote.jsp?stock=DELL″

alt=″An error occurred trying to find stockQuote.jsp″/}

通常片段的文本较小，并且可以作为cookie的值而包含，从而导致页面装配期间较大的性能增益。为此，在URI的协议中设置关键字COOKIE，例如：

{fragmentlink src=″cookie://cookiename″/}

FRAGMENT头的定义

现在参照图4，根据本发明优选实施例提供了FRAGMENT头的形式定义。本发明的实施例可以使用新的HTTP头和对现有“Cache-Control”头的扩展。FRAGMENT头兼容于HTTP规范，“超文本传送协议-HTTP/1.1”(意见征集2616(RFC2616)，互联网工程任务组，1999年6月)，这里参考引用了该规范，并且可在www.ietf.org处从互联网工程任务组得到该规范。

涉及作为片段的对象的所有信息被封装在称作FRAGMENT的头中。这个头被用来标识客户机、服务器或某个中间高速缓存是否具有页面装配能力。该头还规定用于形成片段的高速缓存标识符的规则(根据URI的查询参数和伴随对象的cookie)。另外，该头规定了用于支持主机启动的无效的、对象对其基础数据的依赖关系。仅当“Cache-Control:fragmentrules”(高速缓存控制：片段规则)指令生效时才使用FRAGMENT头。图4中示出了FRAGMENT头的完整语法。下面讨论FRAGMENT头的属性的定义。

contains-fragments(包含片段)：这个属性规定应答的主体包含可以被页面装配器使用的片段指令。

supports-fragments(支持片段)：这个属性规定原始请求方或数据流中的高速缓存支持页面装配。这个指令可以被任何完全支持页面装配的高速缓存或客户机插入。

dependencies(依赖关系)：这个属性规定应答主体所依赖的依赖关系名列表。

cacheid(高速缓存ID)：这个属性规定将用于形成对象的高速缓存ID的规则列表。如果一规则被规定为“URI”，则应答的完整URI将被用作高速缓存ID。如果高速缓存ID被规定为一规则，则如下面更详细地描述的，规则被应用于请求URI以形成高速缓存ID。

在本发明的优选实施例中，用于片段的高速缓存规则不同于用于其它类型的对象的高速缓存规则，如果高速缓存支持页面装配的话。因此，“Cache-Control”头被扩展以指示适用片段高速缓存规则。这将通过覆盖不高速缓存指令的一扩展来实现。实现称作“fragmentrules”(片段规则)的新的高速缓存请求指令，作为对HTTP/1.1规范的14.9.6节中规定的“Cache-Control”通用头字段的扩展。这个扩展的意图是修改在支持片段装配的高速缓存中的不高速缓存指令的行为。不支持片段装配的高速缓存将忽略“fragmentrules”指令，这是HTTP/1.0和HTTP/1.1的基本缺省行为。支持片段装配的高速缓存将忽略伴随有“fragmentrules”指令的“no-cache”(不高速缓存)指令(和任何“Pragma:no-cache”(附注：不高速缓存)头，如果存在的话)，并且根据伴随应答的任何其他头应用高速缓存规则。“Cache-Control”头的一个例子是：

Cache-Control:no-cache，fragmentrules

确定页面装配能力和责任

本发明优选实施例提供的优点是能够定义片段包含，使得可以在从页面编写到浏览器呈现的事件链中的任意点处，包括片段可能存在的所有高速缓存(包括浏览器高速缓存)上，实现页面装配。可以进行页面装配的软件实体被定义为装配点。

该特性提供以下可能的情景：

1.没有比提供页面的HTTP服务器更接近浏览器的装配点。在这种情况下，服务器应当自己进行装配并且提供完全装配的页面。

2.存在某种代理，其能够为原始服务器执行页面装配。这个代理能够变成站点的装配点。原始服务器可以向这个代理提供片段，并且不需要进行任何页面装配。

3.用户的浏览器可以执行页面装配。在这种情况下，没有网络高速缓存或服务器需要执行页面装配。

为了确定如何提供一个片段，即提供完全装配的片段还是提供未装配的片段，服务器和高速缓存应当能够确定是否上行代理中的至少一个正充当装配点。本发明的优选实施例使用HTTP请求头，使得有能力充当服务器的装配点的任何代理可以使用该头指示其能够接受片段，因而不需接收完整的页面。FRAGMENT头的“supports-fragments”指令可以由任何客户机或高速缓存插入以向下行高速缓存指示其为装配点。“supports-fragments”指令的一个例子是：

fragment:supports-fragments

仅仅处理器支持页面装配这一事实并不意味着其应当对从服务器接收的所有对象进行页面装配。分析从服务器接收的每个文档并且尝试对其进行装配，这既是对资源的浪费，又是潜在的问题源。因此，服务器应当在提供对象前指示对象需要装配。FRAGMENT头的“contains-fragments”包含片段指令应当由需要在高速缓存或浏览器中进行页面装配的任何服务器插入。“contains-fragments”指令的一个例子是：

fragment:contains-fragments

多数当前的HTTP高速缓存，包含浏览器高速缓存，均假定具有查询参数的所有对象均是不可高速缓存的。HTTP/1.1扩展和普遍化了高速缓存能力以允许高速缓存对其成功获取的任何对象进行高速缓存。然而，甚至HTTP 1.1高速缓存通常也被构造成不高速缓存其认为是动态的对象，其根据的假设是高速缓存动态对象是对资源的不良使用。这个假定无效的情况的一个例子是个性化数据。个性化页面的创建方法是将查询参数或cookie与页面相关联，借此将页面确定为更通用页面的特定的个性化实例。页面为个性化页面的事实并未使页面内在地是不可高速缓存的。仅当页面所基于的数据是非常易失的情况下，页面才是不可高速缓存的。在仅仅高速缓存特定企业的Web内容的企业服务器中尤其是这样。

反对高速缓存这种页面的通常理由是这种页面的重用的发生率过低，以致不应当占用高速缓存中的空间。这个理由因若干理由而是不充分的。

1.文档从首先创建到最终在浏览器中呈现的成本仅仅在极小的程度上是文档大小的函数。如果文档在某种程度上是“动态”的，则大部分成本发生在起初创建文档时。因此，即使很低的重用也可导致服务器上显著的成本节省。

2.高速缓存的容量已显著增加，并且继续以非常高的速度增加。

3.片段技术的采用可通过消除相同HTML内容的冗余实例来实际减少高速缓存的数据量。

片段的引入有可能使规定高速缓存策略极大地复杂化，尤其是在页面装配器要被构造于高速缓存内的情况下。页面的每个片段可能需要不同的高速缓存策略。本发明的优选实施例使用HTTP应答头来增加高速缓存策略的粒度，以超过现有技术可得到的粒度。

有两个影响高速缓存、必须传送给所实现的页面装配器的因素：(1)片段生存期；和(2)对象的显式的服务器启动的无效。在没有服务器启动的无效的情况下，用于规定其它对象在高速缓存中的对象生存期的相同机制能够应用于片段。如果重要的是防止片段被高速缓存在不显式支持片段的高速缓存中，则在应答中应当包含具有指令“no-cache”和“fragmentrules”的“Cache-Control”头。“no-cache”指令防止未实现片断支持的高速缓存对片段进行高速缓存，而“fragmentrules”指令允许实现片断支持的高速缓存覆盖“no-cache”指令。

服务器启动的无效

可以通过来自服务器的显式控制来通知支持服务器启动的无效的高速缓存哪些片段将被无效。为了保持与不识别或支持服务器启动的无效的现有的和更旧的高速缓存的兼容性，这种被服务器无效的片段应当被提供有HTTP/1.1“Cache-Control”头和“no-cache”指令。如果希望高速缓存覆盖“no-cache”指令并且应用特定于片段的规则，则这些片段应当被提供有扩展指令“fragmentrules”。实现本发明优选实施例的片段高速缓存技术的任何高速缓存还应当实现基于如HTTP/1.1规范中描述的HTTP/1.1可高速缓存性规则的功能。

被服务器无效的片段可以依赖于多个数据源，并且多个片段可以依赖于相同数据。非常希望能够通过向高速缓存发送单个无效命令来找到基于共同数据的所有片段，从而无效多个片段。为高效地达到此目的，服务器将向一片段分配一或多个无效ID。实现高速缓存使用无效ID为高速缓存的项提供次级索引。当服务器启动的无效命令到达时，通过该无效ID索引的所有高速缓存的项被无效。无效ID是通过FRAGMENT头的“dependencies”指令指定的。“dependencies”指令的用法的一个例子是：

fragment:dependencies=″dep1 dep2″

实现服务器使用“dependencies”指令指示服务主机将显式无效对象。如在HTTP/1.1规范中定义的正常时效和可高速缓存性不受这个指令的影响，所以可以在没有服务器启动的无效的情况下，从高速缓存中清除很少被无效的对象。如果指定“dependencies”头，则高速缓存可以忽略任何“Cache-Control:no-cache”头。

无效ID、URI和高速缓存ID具有各自的作用。提供用于指定这些中的每个的分立机制防止了可能难以解决的不必要的应用设计冲突。

动态片段高速缓存标识符

可以在不同于其URI的标识符下高速缓存一个对象。也可以根据URI自身的内容对形成高速缓存ID的精确方式施加约束。这是由于通常使用不应该被用作唯一高速缓存ID的一部分的查询参数来形成动态对象的URI。如果在高速缓存之前不从URI中清除这些参数，则能够出现虚假的高速缓存未命中，从而导致相同对象的多个副本被存储在多个ID下。

为避免这个问题，一组用于形成高速缓存ID的规则应当被设置在其URI不能直接被用作高速缓存ID的动态对象的应答头中。每个规则包括查询参数名和cookie名的一列表。在现有技术中，cookie不被用作高速缓存ID的一部分，但是在许多应用中，使一个请求区别于其它请求的信息是cookie内的数据。因此，cookie的值能够被指定为高速缓存ID的一部分。将被用作高速缓存ID的一部分的任何cookie应当具有名称-数值对的形式。

换言之，CACHEID指令由一或多个规则集构成。规则集由一或多个规则构成。一个规则由一个串列表构成，其中每个串是来自请求URI的查询参数或伴随的cookie的名称。CACHEID指令的一个例子是：

fragment:cacheid=″(pl[p2]，c4)(p3，c4[c5])URI″

这个指令包括3个规则：(p1[p2]，c4)；(p3，c4[c5])；和URI。规则中的“p_”项是查询参数的参数名，而“c_”项是cookie的cookie名。

为产生高速缓存ID，高速缓存从片段的URI的路径名部分开始。然后它尝试应用一个规则列表内的每个规则。如果能够应用规则列表内的每个规则，则来自这个操作的串被用作高速缓存ID。如果规则列表的某个规则不能应用，则跳过该规则列表，应用下一个规则列表，以此类推。如果不存在能够应用其每个非可选规则的规则列表，则对象不可高速缓存；否则，成功应用的第一个规则集被用于形成高速缓存ID。

方括弧(“[”和“]”)中包括的规则是应当尽可能应用的可选规则，但是可选规则的失败不造成规则列表的失败。如果没有CACHEID指令伴随对象，则在其包含查询参数的完整的URI下高速缓存对象。

为应用规则，高速缓存应当首先通过从原始URI中清除全部查询参数来形成基础高速缓存ID。为应用参数规则，高速缓存寻找具有参数名中指定的名称的查询参数。如果名称存在，则来自原始URI的相应名称-数值对被附加到基础高速缓存ID以形成新的基础高速缓存ID。这个过程继续进行，直到全部规则已经成功应用。如果不能应用一个非可选规则，则将基础高速缓存ID恢复到其初始状态并且应用下一个规则列表。为应用cookie规则，高速缓存寻找具有cookie名参数中指定的名称的名称-数值对形式的cookie。如果它存在，则名称-数值对被附加到基础高速缓存ID以形成新的基础高速缓存ID。这个过程继续进行，直到全部规则已经成功应用。如果不能应用一个非可选规则，则将基础高速缓存ID恢复到其初始状态并且应用下一个规则列表。如果规则列表包括串“URI”，则应答的整个URI被用作高速缓存ID。在上述例子中，如果其它两个规则列表均不能被成功应用，则使用请求的完整URI。

当对一个对象的请求到达高速缓存时，高速缓存，即高速缓存管理单元或高速缓存的维护者，首先进行检查以确定对象是否被高速缓存在其完整URI下。如果是，则返回对象；如果不是，则根据片段的URI的路径部分形成基础高速缓存ID，并且再次执行查找。如果没有发现对象，则在与高速缓存相关的规则表中搜索基础高速缓存ID。如果基础高速缓存ID已注册在高速缓存的规则表中，则如前面描述的那样应用该URI的规则。如果一规则列表被成功应用，则再次在新高速缓存ID下寻找对象。如果没有找到，则高速缓存认为这是一次未命中，并且请求被转发给服务器；否则，如果找到对象，则对象被返回到请求方。

继续上述例子，假定对象的完整URI是：

http://foo.bar.com/buyme?p1=parm1&p3=parm3并且应答具有值为“cookie4”、名为“c4”的伴随的cookie。在这种情况下，高速缓存ID可被形成为：

http://foo.bar.com/buyme/p1=parm1/c4=cookie4因为第一个规则适用，即“(p1[P2]，c4)”。

通过多个高速缓存进行的页面装配

现在参照图5A-5G，对象获取路径上的一组支持片段和不支持片段的代理被示出，作为关于能够在各种处理环境中成功实现本发明优选实施例的片段高速缓存技术的方式的讨论的基础。

当在客户端浏览器和服务器之间的路径上存在多个高速缓存，其中某些高速缓存声明支持页面装配而某些高速缓存未声明支持页面装配时，会出现某些复杂因素。对于例如图象或多媒体的其它类型的嵌入对象则不出现这些问题，因为高速缓存和浏览器始终将这些对象视作独立无关的对象。甚至当在浏览器中呈现之后，初始对象在浏览器的高速缓存中仍然是分立的。然而如果页面包括最高级片段“p”和子片段“c”，则使用“p”的URI来请求对象可能返回片段“p”或者完整组合的页面“P”，这取决于开始于浏览器并且终止于目标服务器的代理链中页面装配的支持水平。

图5A-5G图示了代理的各种配置，其具有不同的能力和本发明的优选实施例能够处理它们的方式。在每个附图中，第一高速缓存“高速缓存1”和第二高速缓存“高速缓存2”位于客户端浏览器和服务器之间。在这些例子中，“f”表示支持片段的代理；“nf”表示不支持片段的代理；“p”表示父片段；“c”表示子片段；而“P(p，c)”表示通过将子片段“c”嵌入父片段“p”而组成的页面。

图5A表示最简单的情况。在这个例子中，服务器支持片段，2个高速缓存和浏览器可以支持或不支持片段。有一个包含子片段“c”的最高级片段“p”。服务器分别地存储“p”和“c”，但是知道它们是相关的。对于针对“p”的特定请求，如果浏览器和服务器之间的任何代理(在任何级数上的)支持片段，则返回分立的片段；否则，服务器装配片段并且返回完整装配的页面。

参照图5B，浏览器支持片段，但是高速缓存1和高速缓存2不支持。

在浏览器请求p(并且在尝试装配p之后，接着请求c)之后，每个代理高速缓存了“p”和“c”的副本。服务器返回了分立的片段，因为浏览器会已指示了其支持片段。然而高速缓存1和高速缓存2的表现就好象它们正高速缓存2个独立HTTP对象那样，尤其因为它们是被浏览器分别地请求的，而浏览器和服务器知道“p”和“c”的副本是相关的。浏览器分别地高速缓存它们，但是当需要时组合它们。

参照图5C，浏览器不支持片段，但是高速缓存1和高速缓存2支持片段。在这种情况下，服务器返回了分立的片段，因为高速缓存2会已指示了片段支持。高速缓存2返回了分立的片段，因为高速缓存1会已指示了片段支持。高速缓存1根据“p”和“c”组成最终页面“p(p，c)”，然后将该最终页面返回到浏览器，因为浏览器未指示片段支持。

参照图5D，浏览器和高速缓存2不支持片段，但是高速缓存1支持片段。服务器返回了分立的片段，因为高速缓存1会已指示了片段支持，并且会已在HTTP头中携带了该指示通过高速缓存2。高速缓存2的表现就好象其正高速缓存2个独立HTTP对象那样，但是浏览器、高速缓存1和服务器知道分立片段是相关的。高速缓存2传递分立的片段，因为它们被分别存储，并且它不知道它们是相关的。高速缓存1根据“p”和“c”组成最终页面“p(p，c)”，然后将该最终页面返回到浏览器，因为浏览器未指示片段支持。

参照图5E，浏览器和高速缓存1不支持片段，但是高速缓存2支持片段。服务器返回了分立的片段，因为高速缓存2指示了片段支持。高速缓存2根据“p”和“c”组成最终页面“p(p，c)”，然后将该最终页面传递到高速缓存1，因为浏览器和高速缓存1均未指示片段支持。高速缓存1和浏览器将组合成的片段存储为单个HTTP对象，即最终页面“P(p，c)”。

参照图5F，单个浏览器被两个浏览器“浏览器1”和“浏览器2”替换。浏览器2发出将映射到父片段“p”的页面请求。高速缓存1向高速缓存2转递请求，该请求会携带浏览器2发出的“supports-fragments”头。高速缓存2向高速缓存1返回具有针对片段“c”的片段链接的片段“p”；高速缓存1将其返回到浏览器2。浏览器2分析片段“p”并且接着发出针对子片段“c”的请求。

如果不是为片段处理而设置的浏览器1现在发出针对该页面的请求，则会出现潜在的问题。浏览器1发出包含的URI与浏览器2发出的相同的请求，并且这个URI会匹配于片段″p″的高速缓存ID。如果高速缓存1已将p片段高速缓存，则高速缓存1会发送包含用于片段″c″的FRAGMENTLINK标签的高速缓存片段到浏览器1。由于浏览器1不理解FRAGMENTLINK标记，浏览器1会忽略它，从而导致呈现不完整的页面。

这种情况可推及到网络内的任何这样的配置，其中支持片段的代理和不支持片段的另一个代理连接到不支持片段的高速缓存，如图5G更一般地所示的。如果浏览器2请求片段“p”，则支持片段的高速缓存1会接收片段“p”和“c”并且装配它们，之后高速缓存1将页面“P(p，c)”传送到浏览器2。来自浏览器1的通过高速缓存1的针对片段“p”的后续请求会导致传送未装配的页面。

为解决这个潜在问题，来自支持页面装配的服务器的任何最高级片段应当将最高级片段标记为不可高速缓存，例如使用“Cache-Control:no-cache fragmentrules”。支持页面装配的高速缓存会识别指令中的“fragmentrules”，从而覆盖“no-cache”指令并且对对象应用正确的行为。应当注意，为处理这种情况，只有最高级片段应当被标记为不可高速缓存的。其原因在于由于全页面的URI与最高级片段的URI相同而可能导致的歧义；也就是说，URI会指两个不同的对象。嵌入的片段从不以不止一种形式存在，因此对于嵌入的片段不会出现这种歧义。

关于防止不适当的高速缓存的考虑

如紧接着的上面所述，来自支持页面装配的服务器的任何最高级片段应当将最高级片段标记为不可高速缓存的。这防止了出现不支持片段的高速缓存试图高速缓存包含其它片段的最高级片段的潜在问题；如果出现此问题，如图5G所示，则可能从不包含支持片段的高速缓存的浏览器沿着一个路径访问最高级片段，从而不适当地呈现具有FRAGMENTLINK标签、而不是由FRAGMENTLINK标签指定的内容的页面。

另外，不支持片段的高速缓存通常会使用与对象相关的URI或URI路径作为高速缓存索引/关键字；不为高速缓存所知地，对象可以是片段。由于对象是片段，有可能不适当地只使用URI或URI路径作为不支持片段的高速缓存中的高速缓存ID；在支持片段的高速缓存中，会根据与对象，即片段相关的片段高速缓存规则形成高速缓存ID。换言之，不支持片段的高速缓存继续根据其针对所有高速缓存的对象的高速缓存ID算法形成其高速缓存索引，然而本发明优选实施例的技术旨在在产生用于在高速缓存内放置片段的高速缓存索引之前，使用片段高速缓存规则来形成可高速缓存片段的高速缓存ID。因此，不支持片段的高速缓存有可能在作为高速缓存命中的结果的应答中返回其实际为片段的对象。然后就可能在下游出现各种偏差或呈现错误。为了防止这种错误，应当在不适合进行高速缓存时防止进行高速缓存。

通常，通过包含“Cache-Control:no-cache fragmentrules”头和通过包含“Pragma:no-cache”头，能够防止在不支持片段的高速缓存中进行高速缓存。第二个头告诉不支持HTTP/1.1的高速缓存不要高速缓存片段；支持片段的高速缓存也应当支持HTTP/1.1。如以上参照图5G所简述的，第一个头中的“no-cache”指令告诉支持HTTP/1.1但不支持片段的高速缓存不要高速缓存片段，而“fragmentrules”指令告诉支持片段的高速缓存应当根据片段高速缓存规则来高速缓存片段。

有关高效高速缓存的考虑

对于由多个用户共享的片段，例如产品说明或股票行情，最高效的方式是允许在浏览器和Web应用服务器之间的大多数或所有高速缓存中进行高速缓存。片段可以被视作分布于一个树结构上，在该树结构中，每个高速缓存扇出到其它高速缓存。针对特定片段的第一请求会填充用户和Web应用服务器之间的路径上的诸高速缓存。其它用户针对相同片段的后续请求会在这些高速缓存中找到该片段，而不必一直被传送到Web应用服务器。

对于特定于用户的片段，例如诸如股票监视列表的个性化片段，最高效的方式是允许只在最接近最终用户的支持片段的高速缓存中进行高速缓存，因为针对相同片段的所有后续请求都将沿着相同的路径。否则，中间高速缓存会填充以这些特定于用户的片段，即使这些中间高速缓存永远不会看见针对这些特定于用户的片段的后续请求，因为这些片段由远为更接近用户的高速缓存提供了，从而从中间高速缓存排挤出了共享片段。

具有“private”(私有)指令的HTTP“Cache-Control”头先前已经被用来为页面指定这个相同的特定于用户的特性，使得只有浏览器高速缓存才会高速缓存这种页面。这个相同的头被本发明的优选实施例用来指示支持片段的高速缓存在最接近用户的支持片段的高速缓存中高速缓存内容。应当注意，在特定于用户的片段中包含“Cache-Control:private”是一项可选的性能优化。

关于复合文档的考虑

当获取用于片段装配的片段时，应当形成HTTP请求。用于该应答的头的大部分可以从最高级片段中的应答头继承。然而某些应答头涉及正被获取的特定对象，因而当从父片段继承它们时应当注意。类似地，可以丢弃多数应答头，并且当向客户机返回应答时可以使用伴随最高级片段的应答头。再次地，某些应答头是特定于单个对象的，并且可以影响整个文档的状态。

本节讨论有关在片段装配中处理HTTP请求/应答头的问题。术语“向下传播”被用来表示针对嵌入对象的请求从父或最高级片段继承请求头。术语“向上传播”被用来表示从嵌入对象到父或最高级片段的应答头解析。

对于cookie，涉及复合文档的一个特殊问题是在页面装配期间，不能得到原始的“set-cookie”(设置cookie)应答头。只能从客户机得到作为结果的cookie请求头。特别，实际的“path”(路径)、“domain”(域)或“expires”(过期)值均不能得到。如果嵌套层次较浅的片段中嵌入了另一个片段，而该另一个片段不满足施加在伴随请求而来的cookie上的限制，则将该cookie传递到该子片段是不适当的。因为不存在所有的原始信息，所以通常不可能确定是否传递cookie是适当的。类似地，嵌套的片段可以具有伴随的“set-cookie”头。可能需要该cookie的实际值来计算该片段的高速缓存ID。另外，可能需要该cookie的值以获取嵌套层次更深的片段。然而某些信息是可以推断出来的。可以假定cookie的“expires”部分还没有生效；如果已生效，则请求中不会存在该cookie。可以假定域是请求中的域的某个部分，并且也可以假定路径是请求中的路径的某个部分。

通常，浏览器检查对cookie的约束，如果请求不满足约束，则cookie不被包含在请求头中。然而在页面装配高速缓存中，具有伴随的cookie的文档中包含的FRAGMENTLINK标签有可能引用不满足该原始cookie的约束的URI。因为FRAGMENTLINK标签中引用的对象可能需要父的cookie才能被适当地求值，所以应当从嵌套层次较浅的片段向嵌套层次较深的片段传送cookie。为保证页面装配器不以违反对cookie的约束的不适当方式传递该cookie，指导原则是嵌套片段的URI的路径和域应当满足最高级片段的路径和域的最保守部分。换言之，嵌套片段的URI中的域应当匹配其父的域或为其超集，并且URI的路径部分应当匹配其父的路径或为其超集。这可以被称作“cookie的向下传播”。

相反，下面描述了“cookie的向上传播”。当从主机获取片段时，应答有可能包含“set-cookie”头。这个cookie本身可能是为正确求值新返回的片段内的嵌套层次更深的片段所需要的。因此，页面装配器应当将“set-cookie”头转换成“cookie”头以便获取嵌套层次更深的片段。可能因至少两个目的而需要这个新的cookie：(1)在服务器上对嵌套层次更深的片段的求值；和(2)为该最近获取的片段或嵌套层次更深的片段生成高速缓存ID。在为高速缓存ID的生成而需要cookie的情况下，需要将新cookie与所装配的页面一起发回到请求方。这是由于该cookie应当伴随下一个针对该页面、或针对引用高速缓存的该片段的任何页面的请求，以便在尝试从服务器获取该页面之前根据请求计算高速缓存ID。

将“set-cookie”头中的cookie转换成对嵌套片段的请求中的“cookie”头构成了隐含地代表用户接受cookie的动作。处理这种情况的指导原则包括：(1)最高级片段应当已经具有具有该名称的cookie；和(2)片段的路径和域应当符合最高级片段的路径和域的最保守部分。

如果满足这些约束，新“set-cookie”头的效果将是简单地改变现有cookie的值。从应用的角度看，这只是意味着可能需要“哑”cookie来伴随最高级片段。在获取嵌套片段的过程中，以及当片段的″set-cookie″头被传送回到用户时，这些“哑”cookie将使其值得到更新。

复合文档的除cookie以外的另一个特殊考虑涉及“if-modified-since”(如果自…时已修改)头。“if-modified-since”头被请求方用来指示仅当自特定日期与时间后对象已被修改时才返回该对象。如果自该时间后对象没有被修改，则认为该对象是“新鲜”的，并且通常从服务器返回HTTP 304“Not Modified”(未修改)应答，从而节省传送较大应答体将会需要的带宽。

在复合文档中，某些组件可以是“新鲜的”，而其它组件则是“陈旧的”，并且其它组件的状态可能是不确定的。如果任何组件不能被确定为“新鲜的”，则应当返回整个文件以作为完整的应答(HTTP 200)。如果所有组件已经确定为“新鲜的”，则可以返回HTTP 304应答。然而，为确定片段是否是新鲜的，可能需要执行页面装配，从而注意到组件的HTTP应答代码。如果一个组件是“新鲜的”，则在组件不是叶节点的情况下仍然需要其内容，以找到和获取被嵌套的组件。

因此，会返回HTTP 304应答的对高速缓存的请求应当也返回片段的文本，以使得页面装配可以继续。例如作为高速缓存未命中的结果的对服务器的请求应当以没有“if-modified-since”头的方式发出，因为否则的话，当需要片段的文本以继续页面装配时服务器可能返回HTTP 304应答。换言之，对于复合文件不能向下传播“if-modified-since”头，因为HTTP 304应答会导致对客户机的无效应答。

针对复合文件的另一个特殊考虑类似于“if-modified-since”头的问题，但是不同的是涉及“last-modified”(最后修改)头。页面装配器也应当理解哪些片段返回“last-modified”头，并且将结果合并成一个用于组合成的页面的、具有最近日期的、合并的“last-modified”头。如果有任何片段不返回“last-modified”头，则整体装配页面必须不返回“last-modified”头。这一点是重要的，因为如果浏览器发现“last-modifed”头与其本地高速缓存中的文件相同，则它将会忽略内容。

例如，考虑包含一段动态内容(没有“last-modifed”头)和一段具有“last-modifed”头的静态内容(来自HTML)的页面。如果返回具有静态页面的“last-modifed”头的页面，则浏览器会忽略对相同页面的后续请求，并且会显示来自浏览器高速缓存的旧页面。换言之，如果所有片段都包含“last-modifed”头，则其应当被向上传播并且调整以反映任何组成片段的最近修改时间。如果有任何片段不包含“last-modifed”头，则不可以返回“last-modifed”头。

对于编程模型的考虑

本发明的优选实施例描述了用于分布式片段高速缓存的技术。然而，本发明的优选实施例旨在尽可能是与编程模型无关的，以便任何Web应用服务器编程模型均可以用其向例如中间服务器和浏览器委派高速缓存功能。本发明的优选实施例使用对HTML的扩展，即FRAGMENTLINK标签，以及对HTTP的扩展，即新的片段高速缓存头，这些也是与编程模型无关的。

当对片段编程时，Web应用开发人员应当规定下面两种信息：

1.包含机制。这规定包含哪个片段以及将其包含在另一个片段内的何处。因为其在页面上的位置是重要的，此信息必须嵌入在诸如JSP模板或小服务程序类等代码内。

2.高速缓存控制元数据。这规定片段的条件，例如时间限制。此信息可以嵌入在代码中，也可以通过使其与诸如JSP文件名等模板名称或servlet类相关来单独地规定。

如果使用J2EE编程模型来实现本发明的优选实施例，则可以通过下面的机制支持这两个特性：

1.对于包含机制，J2EE编程模型已经具有Web应用服务器内的用于规定所包含片段的包含构造，例如“jsp:include”标签或“RequestDispatcher.include”方法。可以修改J2EE运行时程序以在适当时将J2EE包含构造改写成FRAGMENTLINK标签。

2.高速缓存控制信息可以从系统管理控制台规定，并且与每个片段模板/类相关，而不是嵌入在代码中。Web应用服务器可以将此信息插入适当的头中。与将此信息放到代码中相比，此方案具有以下优点：

A.它允许通过管理控制台进行动态改变，而不是因其被编程到代码中而必须使程序员介入。

B.它避免了向J2EE编程模型添加新机制。

将J2EE包含构造改写为FRAGMENTLINK标签需要以下考虑。用于查询参数的J2EE语义规定从父片段向子片段递归传递所有查询参数。当J2EE Web应用服务器产生FRAGMENTLINK标签时，SRC属性应当是附加有父的查询参数的、J2EE包含构造的URI。非J2EE Web应用服务器会产生符合其编程模型的SRC属性。通过这种方式，不管是否存在代理(surrogate)均会出现相同语义，因为应用程序代码看见的请求在任一情况下均是相同的。FRAGMENTLINK标签具有的若干属性，例如ALT、FOREACH、SHOWLINK、ID和CLASS，不具有相应的“jsp:include”属性。为用于J2EE环境，这些特性需要对“jsp:include”的扩展。

不同Web应用服务器可以支持其它编程模型(例如ASP)，这些编程模型具有类似但是不同的、用于包含嵌套片段的机制。对于这些编程模型中的每个，Web应用服务器应当产生符合该编程模型的规则的FRAGMENTLINK标签。

关于无效的考虑

为保持高速缓存是最新的，当其内容不再有效时，高速缓存项需要被无效或盖写。无效可以是基于时间的，也可以由外部事件触发。时间可以是在高速缓存中的最大生存期，例如不长于10分钟，也可以是绝对时间，例如不超过02/05/2001中午。最大生存期是使用具有标准HTTP“max-age”指令的标准HTTP“Cache-Control”头规定的。绝对时间是使用标准HTTP“Expires”头规定的。

作为一个例子，可能可接受产品说明过期最高达10分钟。这会被规定为“Cache-Control:max-age=600”，意味着这个片段将保持高速缓存不超过600秒。作为另一个例子，销售可以持续到东部时间12/24/2001，星期一，11:00pm。这会被规定为“Expires=Mon，24 Dec 2001 23:00:00 EST”。在任一情况下，可以通过高速缓存的替换算法从高速缓存中清除片段，以为新片段让出空间。

对于事件触发的无效，应用服务器启动无效。应用服务器可以使用数据库触发器、由更新HTTP请求调用的应用编程接口(API)或任何其他机制来确定内容已变得过时。

本发明优选实施例的技术对于多种无效机制均是开放的。类似地，本发明优选实施例的技术不规定应用服务器用于向支持片段的高速缓存发送无效消息的协议。

片段的依赖关系是被用来产生片段的某些基础数据的标识符。作为依赖关系的一个例子，几个页面可能使用相同的基础用户简档，但是使用不同的片段，因为使用了该用户简档的不同子集，或以不同方式对它们进行了格式化。应用程序可以确定用户简档和使用该用户简档的所有片段之间的映射，并且每当用户简档改变时建立这些片段的高速缓存ID。然而，更好的软件工程是将作为每个依赖关系的源的这种映射设置在每个片段中。这允许应用程序简单地通过使用与用户简档相关的用户ID进行无效，并且使高速缓存将所有依赖于该用户ID的片段无效。当添加使用用户简档的新片段或清除一个片段时，依赖关系是局部于该片段的，并且应用程序的无效机制不变。例如，可以按照下面的方式针对特定用户简档声明这种依赖关系：

fragment:

dependency=″http://www.acmeStore.com_userID=@($*!%″

多个依赖关系被规定为以空格分隔的列表。依赖关系是大小写敏感的。支持片段的高速缓存将允许根据这些依赖关系进行无效。

为使用盖写方法将高速缓存项无效，不需要新的头信息。支持片段的高速缓存需要允许添加新高速缓存项的协议。类似于上述无效协议，这种盖写协议也不由本发明优选实施例的技术规定。

关于安全问题的考虑

支持片段的高速缓存应当遵守潜在的安全要求。当用户操作浏览器型的应用并且点击URI时，用户信任应用设计人员根据应用的安全策略来处理要使用的URI或用户的cookie中提供的任何信息。对于FRAGMENTLINK标签，应用设计人员向高速缓存委派了适当使用这种信息的某些责任；根据本发明优选实施例实现的高速缓存应当执行FRAGMENTLINK标签不能链接到不同于其父的域的域的规则。

包含其它片段的页面最终被装配成完全扩展的页面，并且这可以在浏览器和应用服务器之间的路径上的任何地方发生。为了确保安全，应用开发人员应当遵从以下规则：如果一个片段包含另一个要求HTTPS的片段，则该片段要求HTTPS。这个规则应当递归应用，使得其一直传播到最高级片段。这个规则防止从无保护片段内看到受保护片段。

对于HTTPS请求，仅在高速缓存能够终结HTTPS会话的情况下，才应当包含具有“supports-fragments”指令的FRAGMENT头。否则，它不能看见FRAGMENTLINK以处理它们。不终结HTTPS的高速缓存仍然可以针对HTTP请求支持片段。

有关用于支持片段的高速缓存的高速缓存管理单元的说明

现在参照图6A，其中的方块图描述了根据本发明的优选实施例的计算设备内用于支持片段的高速缓存的高速缓存管理单元。可以是客户机、服务器或者可能同时具有客户机和服务器功能的计算设备600包含支持片段的高速缓存管理单元602，该高速缓存管理单元602包含代表计算设备600高速缓存对象的功能。例如，高速缓存管理单元602可以充当其它支持高速缓存的设备之间的数据路径上的中间高速缓存；在其它情况下，高速缓存管理单元602可以代表最终用户在客户端设备中高速缓存对象。

支持片段的高速缓存管理单元602包括用于存储/高速缓存对象的对象数据库604，其可以包含与对象相关的元数据和与对象一起接收到的网络头。支持片段的高速缓存管理单元602也包括用于存储与高速缓存管理操作的有关的信息的数据库，这里提及了所述操作，并在下面参照图6B-6D更详细地对其进行描述。规则列表数据库606存储URI路径608及其相关的规则列表610。高速缓存ID数据库612存储高速缓存ID614及其相关的高速缓存索引616。依赖关系数据库618存储依赖关系ID和高速缓存ID之间的映射。多个高速缓存ID可以与单个依赖关系相关，多个依赖关系可以与单个高速缓存ID相关。

有关用于支持片段的高速缓存的高速缓存管理单元内的某些过程的说明

现在参照图6B，其中的流程图描述了根据本发明优选实施例当处理包含片段的应答消息时支持片段的高速缓存管理单元可以使用的过程。换言之，图6B描述了可以被用来确定在支持片段的高速缓存上是否应当以及如何处理和/或高速缓存应答消息中的对象的过程。

在包含如图6A所示的支持片段的高速缓存管理单元的计算设备接收到诸如HTTP应答消息的应答消息(步骤6002)时，该过程开始。接着确定高速缓存管理单元是否应当将应答消息中的消息体或有效负载部分处理为片段或非片段(步骤6004)。

如果应答消息应当被处理为包含非片段，则使用现有的HTTP 1.1规则确定非片段对象是否应当并且能够在这个计算设备上高速缓存，即被高速缓存管理单元高速缓存(步骤6006)。例如，包含非片段对象的应答消息可以具有表明其不应该被高速缓存的指示；在HTTP应答消息中，“Cache-Control”头可以具有“no-cache”指令。如果对象应当被高速缓存并且能够将其高速缓存，则由高速缓存管理单元将其适当存储(步骤6008)。在任一情况下，对对象的高速缓存操作完成，并且过程进行分支转移以完成对应答消息的任何其他操作。

如果应答消息应当被处理为包含片段，则确定片段是否可高速缓存(步骤6010)。如果否，则处理进行分支转移以完成针对应答消息的任何其他操作。如果片段可高速缓存，则确定这个特定片段是否应当在这个特定计算设备的高速缓存中被高速缓存(步骤6012)。如果否，则过程进行分支转移以完成针对应答消息的任何其他操作。如果当前处理的片段应当在当前计算设备上高速缓存，则由高速缓存管理单元将其存储在计算设备的高速缓存中(步骤6014)。

如果出现以下任一种情况：片段已经被高速缓存，被确定为将不在当前计算设备上高速缓存，或被确定为不可高速缓存，则确定转发应答消息之前是否需要对片段进行页面装配(步骤6016)。如果需要页面装配，则执行页面装配(步骤6018)。在任一情况下，来自应答消息的片段或非片段对象已由当前计算设备的高速缓存管理单元完全处理，并且在必要时修改应答消息，并且将其转递到其目的地(步骤6020)，从而完成了该过程。

现在参照图6C，其中的流程图步骤描述了用于确定消息体是否包含片段对象的优选方法。图6C提供了可以替换图6B中的步骤6004的步骤。在一个优选实施例中，确定接收到的应答消息是否包含将有效负载或消息体标识为片段的消息/协议头(步骤6022)。具体如图4所示，可以将FRAGMENT头放在HTTP消息中以指示消息的有效负载包含片段对象。

现在参照图6D，其中的流程图步骤描述了用于确定片段对象是否可高速缓存的更加具体的方法。图6D提供了可以替换图6B中的步骤6010的步骤。在这个实施例中，确定接收的应答消息是否包含用于高速缓存控制的协议头的指令，该指令将片段标识为可高速缓存的(步骤6024)。

现在参照图6E，其中的流程图步骤描述了用于确定片段对象是否可高速缓存的优选方法。通过类似于图6D的方式，图6E提供了可以替换图6B的步骤6010的步骤。在一个优选实施例中，确定接收的应答消息是否具有用于消息/协议头的指令，该指令将片段标识为对于支持片段的高速缓存而言是可高速缓存的，而对于不支持片段的高速缓存而言是不可高速缓存的(步骤6026)。具体如上所述，“Cache-Control”头可以被包含在HTTP消息中，并且标准的实践是将“no-cache”指令放在“Cache-Control”头中以防止对对象进行高速缓存；本发明的优选实施例对不支持片段的高速缓存保持这种实践，而将“Cache-Control”头的使用扩展为包含″fragmentrules″指令，以指示消息中的片段是可根据片段高速缓存规则高速缓存的。

现在参照图6F，其中的流程图描述了用于确定片段对象是否应当在具体计算设备上高速缓存的方法。图6F描述了可以替换图6B中的步骤6012和6014的过程；当启动该过程时，已经确定了应答消息包含可高速缓存的片段。

该处理以确定下游设备是否具有支持片段的高速缓存为开始(步骤6028)。下游设备是当前计算设备将向其转发应答消息的计算设备。如果下游设备不具有支持片段的高速缓存，则当前计算设备的高速缓存管理单元将当前正处理的片段对象高速缓存(步骤6030)，并且过程完成。

如果下游设备具有支持片段的高速缓存，则确定当前正处理的片段对象是否只应当被高速缓存在最接近目的用户/客户端设备的支持片段的高速缓存中(步骤6032)。如果不是，则当前片段对象也可以高速缓存在当前计算设备上，并且过程分支转移到步骤6030以将片段高速缓存。然而如果片段只应当被高速缓存在最接近目的用户/客户端设备的支持片段的高速缓存中，则当前计算设备不高速缓存片段，并且过程完成。

现在参照图6G，其中的流程图步骤描述了用于确定下游设备是否具有支持片段的高速缓存的优选方法。图6G提供了可以替换图6F中的步骤6028的步骤。图6F和图6G描述了在接收了应答消息之后启动的处理；作为当前计算设备先前接收和转递请求消息的结果，会接收到该应答消息。因此，当应答消息被接收时，高速缓存管理单元已保存了先前接收的请求消息的某种形式的状态信息。

对于确定下游设备是否具有支持片段的高速缓存，在一个优选实施例中，确定先前接收的请求消息是否包含具有指示支持片段的指令的消息/协议头(步骤6034)。具体如图4所示，FRAGMENT头可以被放在HTTP消息中，并且FRAGMENT头可以包含“supports-fragments”指令。

现在参照图6H，其中的流程图步骤描述了一个更加具体的方法，其用于确定当前处理的片段对象是否应当只被高速缓存在最接近目的用户/客户端设备的支持片段的高速缓存中。图6H提供了可以替换图6F中的步骤6032的步骤。在这个实施例中，当前计算设备当前正处理的应答消息具有包含来自原始服务器的指令的消息/协议头，该指令指示应答消息中的片段只应当被高速缓存在接近目的用户/设备的支持片段的高速缓存中(步骤6036)。

现在参照图6I，其中的流程图步骤描述了一个优选方法，其用于确定当前正处理的片段对象是否应当只被高速缓存在最接近目的用户/客户端设备的支持片段的高速缓存中。通过类似于图6H的方式，图6I提供了可以替换图6F中的步骤6032的步骤。在一个优选实施例中，当前计算设备当前正处理的应答消息具有包含来自原始服务器的“private”指令的HTTP“Cache-Control”消息/协议头，该指令向该支持片段的高速缓存指示应答消息中的片段只应当被高速缓存在接近目的用户/设备的支持片段的高速缓存中(步骤6038)。

现在参照图6J，其中的流程图描述了用于确定在从当前计算设备返回应答消息之前是否需要页面装配的方法。图6J描述了可以替换图6B中的步骤6016和6018的过程；当启动这该过程时，来自应答消息的片段已经在必要时被高速缓存了。

通过例如以类似于图6F中的步骤6028的方式确定下游设备是否具有支持片段的高速缓存(步骤6040)，过程开始。如果下游设备具有支持片段的高速缓存，则不需要页面装配，并且过程完成。如果下游设备不具有支持片段的高速缓存，则确定当前处理的片段是否具有针对另一个片段的链接(步骤6042)。如果没有，则不需要页面装配，并且过程完成。如果当前片段中存在针对另一个片段的链接，则执行页面装配(步骤6044)，并且过程完成。

现在参照图6K，其中的流程图步骤描述了用于确定当前正处理的片段对象是否具有针对另一个片段的链接的更加具体的方法。图6K提供了可以替换图6J中的步骤6042的步骤。在这个实施例中，确定当前片段是否具有一个标记语言元素，其包含指示将要被包含的片段的源标识符或源位置的标记元素(步骤6046)。具体如图3所示，可以将FRAGMENTLINK元素放在HTML对象的主体内以指示针对另一个片段的链接。在HTTP规范中，源标识符被称作“Request-URI”(请求URI)，即标识要在其上施加请求的资源的标识符。

现在参照图6L，其中的流程图步骤描述了用于确定当前处理的片段对象是否具有针对另一个片段的链接的另一个方法。通过类似于图6K的方式，图6L提供了可以替换图6J中的步骤6042的步骤。在这另一个实施例中，确定当前正处理的应答消息是否包含具有一个指令的消息/协议头，该指令指示应答消息的消息体中的片段，即当前正处理的片段，具有针对另一个片段的链接(步骤6048)。通过扫描该片段以查找FRAGMENTLINK可以确定这一点。然而，远为更加高效的方式是使用应答头指示这一点，从而避免了不必要的扫描。具体如图4所示，可以将FRAGMENT头放在HTTP消息中，并且该FRAGMENT头可以包含“contains-fragments”指令。这个指令使得当前计算设备的高速缓存管理单元放弃用于搜索FRAGMENTLINK元素的当前片段扫描。

现在参照图6M，其中的流程图描述了用于执行页面装配的过程。图6M提供了可以替换图6B中的步骤6018或图6J中的步骤6044的步骤。通过获得来自应答消息的当前片段中包含的链接片段的源标识符，例如URI，该过程开始(步骤6050)。接着使用该源标识符获得链接片段(步骤6052)。接着组合获得的片段和来自应答消息的当前片段以形成装配页面(步骤6054)，即新片段，并且过程完成。

组合诸片段的内容取决于用于片段内容类型的编码规则。例如，标记语言中的每个元素可以被认为是一个片段，并且通过在父元素的定界标签间插入标记元素，可以在父元素内嵌入子元素。然而对片段进行组合还需要考虑对片段的头和属性值进行组合的方式，如下面更详细地讨论的。

现在参照图6N，其中的流程图描述了用于可选地将一个片段链接扩展为多个片段链接的过程。回来参照图6M，如果当前片段包含多个片段链接，则可不断重复步骤6050和6052，直至获得该多个链接片段，所有这些链接片段接着可以被组合以形成单个装配页面。相反，图6N描述了一个过程，其被用来将单个片段链接紧凑表示成包含针对多个片段的引用，其中该多个片段被组合以形成装配页面。

通过确定来自应答消息的当前片段中的片段链接是否指示其应当扩展到多个片段链接(步骤6062)，过程开始。如果未指示，则过程完成；如果指示，则使用与该片段链接相关的信息将该片段链接扩展到一组多个片段链接(步骤6064)。

接着在一个循环中处理所述多个片段链接。获得该组多个片段链接中的下一个片段链接(步骤6066)，并且获得该片段链接的源标识符(步骤6068)。接着使用该源标识符获得所标识的片段(步骤6070)。确定该组多个片段链接中是否存在另一个片段链接(步骤6072)，并且如果存在，则过程分支转移回到步骤6066以处理另一个片段链接。如果不存在剩余的片段链接，即已经获得了所有片段，则将所有获得的片段与来自原始应答消息的片段相组合(步骤6074)，并且过程完成。

现在参照图6O，其中的流程图步骤描述了一个优选方法，其用于确定来自应答消息的当前片段中的片段链接是否指示其应当被扩展为多个片段链接。图6O提供了可以替换图6N中的步骤6062的步骤。在一个优选实施例中，确定来自应答消息的片段中的片段链接的标记语言标记的元素是否包含指示应当扩展片段链接的属性(步骤6076)。具体如图3所示，FRAGMENTLINK元素可以具有FOREACH属性。

现在参照图6P，其中的流程图描述了用于根据与片段链接相关的信息将该片段链接扩展为多个片段链接的过程。图6P提供了可以替换图6N中的步骤6064的一系列步骤。

通过从所包含的、片段链接的、标记语言标记的元素获得cookie名(步骤6078)，过程开始。如图3所示，FOREACH属性可以提供被解释为cookie的名称的串。获得cookie的值(步骤6080)；cookie的值是表示名称-值对列表的串，这些名称-值对接着在一个循环中被处理。从cookie值获得下一个名称-值对(步骤6082)，并且通过使用该名称-数值对，例如将名称-值对用作查询参数，产生片段链接(步骤6084)。接着确定cookie值中是否存在另一个名称-值对(步骤6086)，并且如果存在，则过程分支转移回到步骤6082以处理另一个名称-值对。例如，可以对每个名称-值对产生一个FRAGMENTLINK元素，从而将原始FRAGMENTLINK元素扩展为替换原始FRAGMENTLINK元素的一组多个FRAGMENTLINK元素。如果不存在剩余的名称-值对，则过程完成。

现在参照图6Q，其中的流程图描述了用于使用片段的源标识符得到片段的过程。图6Q给出了可以替换图6M中的步骤6052或图6N的步骤6070的过程。图6Q中的过程在已经确定片段的源标识符之后开始。

通过确定在当前计算设备的本地高速缓存内是否存在涉及源标识符的高速缓存命中(步骤6092)，过程开始。如果存在，则能够从高速缓存获得片段(步骤6094)，并且获得的片段被返回给调用例程(步骤6096)。如果获得的片段包含片段链接，则过程循环回到步骤6092以获得该片段链接所标识的片段(步骤6098)，从而继续过程以获得所有子片段。

如果在步骤6092确定本地高速缓存内存在涉及源标识符的高速缓存未命中，则产生请求消息(步骤6100)，并且通过使用该源标识符作为目的标识符来发送该请求消息(步骤6102)。如参照图4所述，请求消息会包含“supports-fragments”指令，因为当前计算设备包含支持片段的高速缓存管理单元。高速缓存管理单元接着等待对请求消息的应答(步骤6104)。最好为请求产生一个线程，并且该线程在等待应答时休眠，同时计算设备执行其它操作。

在接收到应答消息之后，获得应答消息的消息体中的片段(步骤6106)并且将其高速缓存(步骤6108)。如上所述，获得的片段被返回给调用例程，并且如果获得的片段包含片段链接，则过程循环回到步骤6092以获得由该片段链接标识的片段，从而继续该过程以获得所有子片段。否则，获得片段的过程完成。

现在参照图6R，其中的流程图描述了当在支持片段的高速缓存管理单元内高速缓存片段时执行的某些处理。图6R提供了可以替换图6B中的步骤6014或图6F的步骤6030的过程。在已经在当前计算设备上的应答消息中接收到片段之后，开始图6R中的过程。

通过获得与片段相关的源标识符，例如应答消息中的URI(步骤6112)，以及与片段相关的规则列表(如果应答消息中存在规则列表的话)(步骤6114)，过程开始。以和URI路径相关的方式在规则列表数据库中存储规则列表(步骤6116)，以便以后当尝试为正处理的请求产生高速缓存命中时使用。使用规则列表来指导生成高速缓存ID，该高速缓存ID用于高速缓存应答消息内的片段(步骤6118)。

接着使用高速缓存ID来产生高速缓存索引(步骤6120)；高速缓存索引被用来确定片段存储器，即高速缓存存储器内应当存储来自应答消息的片段的位置。通过用散列算法处理高速缓存ID，可以产生高速缓存索引。本发明优选实施例的技术的灵活之处在于，在以符合使用伴随片段的高速缓存ID规则的技术的方式产生了高速缓存ID之后，高速缓存管理单元的每个实现可以使用其自己的算法计算高速缓存索引。

接着片段和任何其他必要信息或元数据(包括伴随片段的HTTP应答消息中的头或等价信息)被存储在高速缓存中(步骤6122)，并且以和高速缓存索引关联的方式存储新产生的高速缓存ID(步骤6124)。或者，可以每当必要时计算高速缓存索引，因而可能不必存储高速缓存索引。作为另一个替代方案，高速缓存ID可以直接被用作某种类型的存储器索引或数据库标识符，因而可以不必计算单独的高速缓存索引。

如果存在任何与应答消息内的片段相关的依赖关系，则获得该依赖关系(步骤6126)，并且以和片段的高速缓存ID关联的方式存储该依赖关系(步骤6128)。

现在参照图6S，其中的流程图描述了一个过程，其中如果在包含高速缓存管理单元的计算设备上高速缓存了片段，则支持片段的高速缓存管理单元可以使用该过程获得此片段。换言之，图6S描述了可以被用来例如响应对请求消息的检查而确定是否能够在支持片段的高速缓存上产生高速缓存命中的过程。

通过获得与请求相关的源标识符，例如URI路径(步骤6132)，过程开始。接着搜索规则列表数据库以确定在规则列表数据库内是否存在用于该URI路径的高速缓存ID规则列表(步骤6134)。如果不存在与该URI路径相关的规则列表，则返回高速缓存未命中指示(步骤6136)，并且过程完成。

如果存在与URI路径相关的规则列表，则使用规则列表内的规则来产生高速缓存ID(步骤6138)，其中假定能够产生高速缓存ID，即存在成功计算至少一个规则所需的所有必要信息。接着确定高速缓存ID先前是否已经被用来存储片段(步骤6140)，即是否存在高速缓存命中。如果没有，则返回高速缓存未命中指示，并且过程完成。

如果存在高速缓存命中，则获得与高速缓存ID相关的高速缓存索引(步骤6142)，这使得能够随后使用高速缓存索引以获得适当片段(步骤6144)。接着将该片段返回给请求方(步骤6146)，从而完成过程。

现在参照图6T，其中的流程图描述了用于组合与多个片段相关的头值和属性值的过程。图6T提供了可以替换图6M中的步骤6054或图6N中的步骤6074的过程。无论是通过应答消息接收的，还是从计算设备的高速缓存中获得的，每个将被组合的片段均具有与应答消息中的每个片段一起接收到的相关的一组协议头。这些头和属性的值被合并成针对每个头或属性的单个指令/值。

通过获得将被组合的所有片段的下一个头类型的各头值(步骤6152)，过程开始。接着将适当的组合函数应用于全部这些头值(步骤6154)，并且接着设置组合头值或者说使其与装配页面或片段相关(步骤6156)。接着确定是否存在另一个将被处理的头类型(步骤6158)，并且如果存在，则过程分支转移回到步骤6152以处理另一个头类型。

在已经处理了所有的头之后，过程接着获得将被组合的所有片段的下一个属性类型的诸属性值(步骤6160)。接着将适当的组合函数应用于全部这些属性值(步骤6162)，并且接着设置组合属性值或者说使其与装配页面或片段相关(步骤6164)。接着确定是否存在另一个将被处理的属性类型(步骤6166)，并且如果存在，则过程分支转移回到步骤6160以处理另一个属性类型；否则，过程完成。

现在参照图6U，其中的流程图描述了代表一系列针对头类型和属性值的组合函数的一组步骤。图6U表示可以在图6T的步骤6154或6162中使用的某些组合函数；所示出的组合函数并不是旨在作为高速缓存管理单元中可能存在的组合函数的完整列表。

通过确定是否正在组合HTTP“Content-Length”字段(步骤6168)，过程开始。如果未组合，则跳过下一个步骤；否则，组合的“Content-Length”字段的值是所有“Content-Length”字段的和(步骤6170)。

通过确定是否正在组合HTTP“Last-Modified”字段，过程继续执行(步骤6172)。如果未组合，则跳过下一个步骤；否则，组合的“Last-Modified”字段的值是所有“Last-Modified”字段中最近的(步骤6174)。

通过确定是否正在组合到期时间值，过程继续执行(步骤6176)。如果未在组合，则跳过下一个步骤；否则，根据以下考虑设置组合的到期时间值的值(步骤6178)。支持片段的高速缓存应当尊重根据片段中的时间进行无效的应答头和装配页面中的应答头之间的关系。装配过程应当按照下面的方式确定装配页面的无效时间。首先，根据每个片段的作为绝对时间的“Expires”头、具有作为相对时间的“max-age”指令的“Cache-Control”头、和“Date”头，计算所有片段的短路等价时间间隔，其中包含最高级片段和所有递归包含的片段。这是通过使用“Date”头值将绝对时间转换成增量时间来进行的。这个值可以被称作“minimumRelativeTime”(最小相对时间)。接着，装配页面的“Expires”头中的值被设置成“Date”头中的值加上该计算的minimumRelativeTime值。这是不支持HTTP/1.1“Cache-Control”头的高速缓存所需的。接着，装配页面的″max-age″指令被设置成该计算的minimumRelativeTime值，因为HTTP/1.1规范规定“max-age”指令覆盖“Expires”头，即使“Expires”头限制性更强。这是支持HTTP/1.1的高速缓存所需的。

过程中的最后步骤将内容编码类型设置成适当值(步骤6180)。在第一方案中，根据HTTP/1.1规范，如果已知新编码是客户机可接受的，高速缓存可以修改内容编码，只要在正被组合的头中的任一个内不存在“no-transform”(无转换)高速缓存控制指令。在第二方案中，将包含的片段的内容编码改变成与最高级片段相同。

现在参照图6V，图6V的流程图描述了当处理请求消息时支持片段的高速缓存管理单元可以使用的过程。与描述对应答消息的处理的图6B相反，图6V描述了与请求消息的处理相关的某些步骤。

通过接收请求消息来开始该过程(步骤6192)，之后从请求消息获得源标识符(步骤6194)。使用源标识符来从本地高速缓存获得标识的对象或片段，即发生了高速缓存命中，或者通过请求获得对象或片段，即发生了高速缓存未命中(步骤6196)。前面参照图6Q描述了与高速缓存命中或高速缓存未命中相关的过程。在任一情况下，如果需要页面装配，则执行此页面装配(步骤6198)；前面参照图6T描述了与页面装配相关的过程。接着针对所接收的请求消息返回应答消息(步骤6200)，从而完成该过程。

现在参照图6W，其中的流程图描述了根据本发明优选实施例当处理无效消息时支持片段的高速缓存管理单元可以使用的过程。如上所述，本发明优选实施例的技术不规定任何具体的无效算法，并且图6W中描述的过程仅仅是使用依赖关系ID的例子。

通过在计算设备上从已发布或提供了可能高速缓存在该计算设备中的片段的原始服务器接收无效请求消息(步骤6202)，过程开始。这个请求包含依赖关系ID的一列表。假定原始服务器不产生冲突的依赖关系；通过用包含至少其域名的应用ID限定依赖关系，假定能够维护全球唯一的依赖关系。通常需要进行验证以使应用ID与无效方相关，使得无效方只能无效其自己的内容。

接着确定依赖关系数据库中的任何依赖关系是否匹配接收到的消息内的一或多个依赖关系(步骤6210)，并且如果匹配，则获得与匹配一或多个依赖关系相关的高速缓存ID列表(步骤6212)。接着使用高速缓存ID来从高速缓存中清除相关片段(步骤6214)。如果需要或适当，也可以清除相关规则列表和依赖关系。

可以将可选应答返回给无效请求消息的发起方(步骤6216)。如果没有依赖关系匹配，则过程分支转移到步骤6216。在任一情况下，过程完成。支持片段的高速缓存的高速缓存管理单元之间的某些协同的例子

现在参照图7A，图7A的方块图描述了Web应用服务器和客户机之间的某些数据流，以说明某些高速缓存执行片段装配的时机。客户端设备700包括不支持片段的高速缓存管理单元702，其产生页面请求并且向中间服务器704发送请求。不为该客户端设备所知的是，请求的页面实际包括父片段和针对子片段的链接。中间服务器704接收请求，但是高速缓存管理单元706不支持片段，也不具有所请求页面的高速缓存版本。

请求接着被转发到中间服务器708，其包括支持片段的高速缓存管理单元710。中间服务器708不具有所请求页面的高速缓存版本；中间服务器708在向中间服务器712发送请求消息之前向请求消息加入“Fragment:supports-fragments”头，中间服务器712包括不支持片段的高速缓存管理单元714。中间服务器712不具有所请求页面的高速缓存版本，并且向包括支持片段的高速缓存管理单元718的Web应用服务器716发送/转发请求消息。

根据包含“Fragment:supports-fragments”头的传入请求消息，Web应用服务器716可以确定一下游计算设备具有能够充当页面装配器的支持片段的高速缓存管理单元。因此，不是在应答中返回整个装配页面，而是由Web应用服务器716返回具有包含FRAGMENTLINK子片段的父片段的应答。中间服务器712不支持片段，所以它仅仅转发应答。

支持片段的高速缓存管理单元710认识到它是最接近最终用户或客户机的支持片段的高速缓存；原始请求不包含“Fragment:supports-fragments”头，所以支持片段的高速缓存管理单元710确定它应当在返回应答之前执行页面装配。在页面装配过程期间，支持片段的高速缓存管理单元710请求和接收链接到父片段的子片段。子片段和父片段被合并成单个装配页面，并且装配页面被返回到客户端设备。中间服务器704转递应答到客户端设备700，客户端设备700接着向最终用户呈现装配页面。中间服务器704和客户端设备700均不会高速缓存装配页面，因为应答会标记有将防止这些设备高速缓存装配页面的“no-cache”指令。中间服务器708将会高速缓存父片段和子片段二者。

现在参照图7B，图7B的方块图描述了Web应用服务器和客户机之间的某些数据流，以便说明如何控制一组设备以在最接近最终用户或客户端设备的高速缓存中高速缓存片段。客户端设备720包括不支持片段的高速缓存管理单元722，其产生对对象的请求并且发送请求到中间服务器724。不为客户端设备所知的是，所请求对象实际是片段。中间服务器724接收请求；由于高速缓存管理单元726支持片段但是没有所请求片段的高速缓存版本，高速缓存管理单元726向请求加入“Fragment:supports-fragments”头并且转发请求到目的服务器。

中间服务器728接收请求；由于高速缓存管理单元730不具有所请求片段的高速缓存版本，支持片段的高速缓存管理单元730确保“Fragment:supports-fragments”头被包含在请求消息中，并且转发请求消息到目的服务器。中间服务器732包含不支持片段并且没有所请求对象的高速缓存版本的高速缓存管理单元734，因而它转发请求。

根据包含“Fragment:supports-fragments”头的传入请求消息，Web应用服务器736可以确定下游计算设备具有支持片段的高速缓存管理单元。因此，Web应用服务器736可以确定返回包含片段的应答是适当的。然而Web应用服务器736将应答消息标记上“Cache-Control:private”头，这会导致应答中的片段仅被最接近最终用户或客户端设备的支持片段的高速缓存来高速缓存；高速缓存管理单元738不高速缓存应答中的片段。

中间服务器732不支持片段。高速缓存管理单元734识别出“private”指令，所以它不高速缓存片段，而中间服务器732仅仅转发应答。相反，高速缓存管理单元730支持片段，但是它认识到原始请求被标记上“Fragment:supports-fragments”头，因此下游设备可以在更接近最终用户或客户端设备的位置高速缓存片段。这样，高速缓存管理单元730将“private”指令解释为指示其不要高速缓存应答中的片段。

高速缓存管理单元726也支持片段，但是它认识到原始请求未标记上“Fragment:support-fragments”头，因此没有下游设备可以在更接近最终用户或客户端设备的位置高速缓存片段。因此，高速缓存管理单元726将“private”指令解释为指示其高速缓存应答中的片段。中间服务器724接着转发应答到客户端设备720；高速缓存管理单元722不支持片段，所以它将“private”指令解释为指示其不要高速缓存片段。

被用来支持特定于角色或特定于类别的内容的高速缓存的支持片段的高速 缓存的例子

现在参照图8A-8D，其中的数据流图描述了在客户机、中间的支持片段的高速缓存或服务器内发生的某些处理步骤，以说明能够根据本发明的优选实施例实现特定于角色或特定于类别的动态内容的高速缓存。某些Web内容可以进行分类，使得根据用户与特定机构的关联或用户在机构内的角色，将Web内容专用于一组用户。例如，企业可以向第一公司发布其产品的定价数据库的一个版本，而向第二公司发布其产品的定价数据库的第二版本。例如，第二公司可以由于购买大量的该企业产品而得到很大的批量折扣。

当第一公司的第一雇员访问该企业的Web站点时，这个雇员应当接收到显示针对第一公司的价格信息的Web页面。价格信息可能相对频繁地改变，所以和静态内容相比较，价格信息更加难以进行高速缓存。当第二公司的雇员访问企业的Web站点时，这个雇员应当接收到显示针对第二公司的价格信息的Web页面。

在本发明的优选实施例中，可以高速缓存针对不同客户公司的雇员产生的Web页面，使得它们可被相同公司的其它雇员得到。当第一公司的第二雇员访问企业的Web站点时，这个雇员可以接收到为该相同公司的第一雇员高速缓存的Web页面。换言之，已经对企业的内容进行了分类，以由不同机构，即不同客户公司所使用。

使用第二个例子，一公司可以具有包含人力资源信息的Web站点，但是某些信息应当限于仅仅由公司的管理层雇员来查看。然而，即使管理层信息可能是动态内容，也不必为查看信息的每个管理人员高速缓存管理层信息的多个副本。根据本发明的优选实施例，可以高速缓存例如管理或者非管理的特定于角色的内容，并且用户在组织内的角色可以被用来协助确定返回给用户哪一组高速缓存内容。

可以使用类别区分以一般方式来描述这些例子。根据可以应用于正访问内容的用户的特征，可以将内容类别的概念应用于用户角色、机构实体等等。图8A-8D提供了有关使用本发明的优选实施例高速缓存特定于类别的内容的方式的一般例子。

参照图8A，例如浏览器的客户端应用程序产生页面请求(步骤802)并且将其发送给应用服务器(步骤804)。中间的支持片段的高速缓存不具有所请求页面的副本，所以它不能返回高速缓存的副本。应用服务器确定所请求页面被限制为由某个类别的用户来查看，但是应用服务器检测出请求没有伴随有将请求方标识为限制用户类别的成员的所需cookie(步骤806)。服务器产生验证质询页面(步骤808)并且将其发送给客户机(步骤810)；验证质询页面被标记为不可高速缓存的，所以中间高速缓存不高速缓存该页面。

客户机接收验证质询页面并且呈现给用户(步骤812)，用户接着提供用户ID和口令(步骤814)，用户ID和口令被发回到服务器(步骤816)。服务器验证用户的信息(步骤818)并且使用用户ID确定所标识的用户所属的用户类别(步骤820)。在确定了诸如管理角色的用户类别之后，服务器产生类别cookie，其包含允许标识所确定的用户类别的信息(步骤822)。还产生最初请求的页面(步骤824)，并且将该页面和类别cookie发送给客户机(步骤826)。

直到此时，中间高速缓存还没有高速缓存任何内容。然而，当前返回的页面被标记为可根据支持片段的高速缓存规则高速缓存的，所以中间高速缓存使用页面的标识符、伴随页面的类别cookie、和伴随给客户机的应答消息的片段高速缓存规则中规定中间高速高速缓存使用的任何其他适当信息，存储页面(步骤828)。在客户机接收到所请求页面之后，它被呈现给用户(步骤830)，并且伴随的类别cookie被客户端应用程序存储在其cookie高速缓存中(步骤832)。

参照图8B，其中示出一个用于更新先前发出的类别cookie的例子。客户端应用程序产生页面请求(步骤842)，该页面请求类似于图8A示出的、例如来自相同域的页面请求。然而，用户已经执行了导致用户类别改变的某种操作。例如，用户可能本来在查看与作为某个雇员组的管理人员的用户角色有关的页面，并且用户可能接着决定查看与作为财务主管的用户角色有关的页面。由于用户先前已经通过验证，服务器不应该执行另一个验证过程。然而服务器应当发出针对该用户的新类别cookie。

页面请求和伴随的类别cookie被发送给服务器(步骤844)。中间高速缓存不具有所请求页面，所以它发生高速缓存未命中。服务器确定客户机正请求需要新类别cookie值的操作(步骤846)，并且发出新的类别cookie(步骤848)。还产生所请求页面(步骤850)，并且所请求页面和新发出的类别cookie被返回(步骤852)。中间高速缓存接着根据新cookie值存储页面(步骤854)。客户机接收和呈现所请求页面(步骤856)，并且新cookie值被存储在客户机的cookie高速缓存中(步骤858)。通过这种方式，当更新类别cookie时更新中间高速缓存。

参照图8C，其中示出了有关继续使用相同类别cookie仍然会导致高速缓存未命中的方式的例子。客户端应用程序产生页面请求(步骤862)，该页面请求和伴随的类别cookie被发送给服务器(步骤864)。中间高速缓存不具有所请求页面，所以它发生高速缓存未命中。服务器使用类别cookie中的值动态确定某个内容类型并且产生适当的页面(步骤866)，并且产生的页面和未改变的类别cookie被返回(步骤868)。中间高速缓存存储页面(步骤870)并且将其转发给客户机。客户机接收和呈现所请求页面(步骤872)；由于类别cookie没有改变，未将客户机示出为盖写cookie高速缓存中的类别cookie。

根据本发明的优选实施例，在步骤828、854和870，中间高速缓存已根据由服务器放在应答消息中的片段高速缓存规则存储了来自应答消息的页面的副本。本发明的优选实施例允许将cookie用于高速缓存ID操作，以区分类似页面的两个不同版本，这两个不同版本在只有与页面相关的URI被用于高速缓存目的的情况下本来会被识别为相同的。更加重要的是，可以以和类别cookie相关的方式高速缓存页面，使得可以随后在高速缓存查找过程中使用类别cookie，从而允许根据所声明的类别cookie中的相似性确定高速缓存命中，如图8D所示。

参照图8D，其中示出了有关两个不同用户使用相同类别cookie仍然会导致不同用户对单个页面的访问中的高速缓存命中的方式的例子。在这个例子中，不同用户正访问和图8C示出的先前例子中的第一用户访问的相同的页面。然而，第二用户与第一用户属于相同的用户类别。换言之，两个用户可以被描述为属于相同用户类别或被分配了相同的角色。例如，这两个用户可以是正查看公司管理人员备忘录的管理人员，其中备忘录包含专门针对这两个用户所属的部门中的管理人员定制的动态内容。不是为每个管理人员产生和高速缓存备忘录，而是预先使备忘录与管理人员角色相关。在第一管理人员访问了备忘录之后，它已经被高速缓存，而相同类别中其它管理人员获得备忘录的后续尝试会导致高速缓存命中。不同类别中其它管理人员访问备忘录的后续尝试会导致高速缓存未命中，因为后续管理人员会具有不同的类别cookie，即使备忘录的两个不同版本可以与相同的URI相关。

客户端应用程序产生页面请求(步骤882)，该页面请求和属于第二用户的伴随类别cookie被发送给服务器(步骤884)。在这种情况下，中间高速缓存具有由请求内的URI路径和相关联的类别cookie所标识的所请求页面的副本，所以它发生高速缓存命中(步骤886)。中间高速缓存能够无需向服务器转发请求而立即返回所请求页面(步骤888)，并且客户机接收并向第二用户呈现所请求页面(步骤890)。

通过这种方式，中间高速缓存可以实际存储相同片段的多个版本，并且根据用户的声明的类别cookie将适当版本的片段返回给用户，即仅由类别cookie来确定在其他方面相似的片段的不同版本之间的选择。下面具体针对购物者组类别进一步提供了使用cookie区分片段的进一步例子。

处理单个消息中多个片段的效率增强

现在参照图9A，其中的流程图描述了可在单个请求消息中指定多个片段并且随后处理所述片段的过程。图9A示出的过程可以和图6N示出的过程，或其中特别在组合多个片段为单个片段之前需要获得的这些片段的任何其他过程结合使用。

在从应答消息或高速缓存获得片段之后，通过检查“contains-fragments”指令以确定其是否是叶片段或包含其它片段，过程开始。如果它包含其它片段，对其进行分析以找到这些包含的片段。

在收集到所有下一级片段的源标识符之后，产生单个批请求(步骤904)；批请求可以包含将用于获得片段的批服务器端程序，即小服务程序。批请求包含下一级片段的所有源标识符，例如URI。假定已经检查了本地高速缓存，以发现对于这些下一级片段中的任何一个的高速缓存命中；如果存在对于一个下一级片段的高速缓存命中，则不将该片段包含在批请求中。

批请求消息接着被发送给服务器(步骤906)，并且高速缓存管理单元等待接收多部分MIME(多用途网际邮件扩展)应答(步骤908)。最好为请求产生一个线程，并且在等待应答时线程休眠，同时计算设备正执行其它操作。

在接收到应答之后，高速缓存管理单元逐个检查应答中的每个片段。从多部分的应答消息获得下一片段(步骤910)并且接着将其高速缓存(步骤912)。接着确定是否多部分的应答消息中还存在任何其它要被处理的片段(步骤914)，并且如果存在，则过程分支转移回到步骤910以处理另一个片段。否则，可以分析或检查新接收的片段以确定这些片段是否包含针对下一级片段的链接(步骤916)，并且如果包含，则过程分支转移回到步骤902以在必要时通过批请求请求更多的片段。否则，在页面装配操作中组合新接收的片段(步骤918)，并且过程完成。

现在参照图9B，其中的流程图描述了可在中间高速缓存管理单元上接收单个请求消息并且随后进行处理的过程。图9B示出的过程可以和图6V示出的过程，或其中在中间高速缓存上处理请求消息的任何其他过程结合使用。

当在中间的支持片段的高速缓存上接收到批请求时(步骤922)，过程开始。接着在循环中处理批请求内的源标识符集合。从请求消息获得针对所请求片段中的一个的下一源标识符(步骤924)，并且确定本地高速缓存中是否存在高速缓存命中(步骤926)。如果不存在高速缓存命中，则可以跳过下一步骤；如果存在高速缓存命中，则可以从批请求消息中清除该源标识符(步骤928)。确定是否批请求消息中还存在任何其它要被处理的源标识符(步骤930)，并且如果存在，则过程分支转移回到步骤924以处理另一个源标识符。

确定是否已经在本地高速缓存中找到了所有的所请求片段(步骤932)。如果是，则不必转发批请求，并且过程进行分支转移以准备应答消息。如果存在至少一个高速缓存未命中，则其中清除过一个或多个源标识符的修改的批请求被转发给服务器(步骤934)。可选地，如果存在单个的剩余源标识符，则批请求可以被改变为普通请求消息。高速缓存管理单元等待接收多部分MIME应答(步骤936)；最好为请求产生一个线程，并且在等待应答时线程休眠，同时计算设备执行其它操作。

在接收应答之后，高速缓存管理单元逐个检查应答中的每个片段。从多部分的应答消息获得下一片段(步骤938)，并且接着将其高速缓存(步骤940)，假定在本地高速缓存内高速缓存片段是适合的。确定是否多部分的应答消息中还存在任何其它要被处理的片段(步骤942)，并且如果存在，则过程分支转移回到步骤938以处理另一个片段。假定不分析或检查新接收的片段以确定这些片段是否包含针对下一级片段的链接，因为可以假定这个过程将在产生了原始批请求的高速缓存管理单元上执行；或者，这个过程可以通过类似于参照图9A描述的方式在当前高速缓存管理单元上执行。在任一情况下，产生具有对应于在原始批请求中接收的源标识符的片段的多部分MIME应答(步骤944)，并且返回多部分MIME应答(步骤946)，从而完成过程。

现在参照图9C，其中的流程图描述了Web应用服务器上用于处理对多个片段的批请求消息的过程。可以在批请求消息已经过具有支持片段的高速缓存管理单元的多个计算设备之后执行图9C示出的过程，其中所述多个计算设备未能满足片段请求，即多个设备可能已发生高速缓存未命中。

通过在服务器上接收批请求(步骤952)来开始过程；批请求包含多个片段请求，其中依次处理所述片段请求。从批请求消息获得下一片段请求(步骤954)并且执行它(步骤956)，其中可能包括产生片段，之后可选地，可能需要为发送而对片段进行格式化或标记(步骤958)，虽然片段可能已经预先在服务器上被高速缓存了。确定是否批请求消息中还存在另一个片段请求(步骤960)，并且如果存在，则过程进行分支转移以处理另一个片段请求。否则，产生具有所有请求的片段的多部分MIME应答消息(步骤962)，并且返回该应答消息，从而完成过程。

降低高速缓存大小的例子

现在参照图10A-10D，其中提供一组例子以说明可以通过本发明的优选实施例实现的降低高速缓存大小的有利效果。用于在特定应用中选择什么来构成片段的一个准则是一段内容被不同页面共享的频度。如果一段内容被频繁共享，则使其成为片段会大大降低高速缓存的大小，因为可以将该片段存储一次，而不是在许多页面中重复该片段。于是，片段提供了在许多页面之间的一种压缩形式以降低高速缓存大小。这种压缩的优点可以被视作成本降低，例如对于固定命中率降低高速缓存大小，性能改进，例如增加固定大小高速缓存的命中率，或其组合。图10A-10D示出了本发明优选实施例的使用的各种情景，以及与同等的现有技术情景相比较可以实现的高速缓存大小的降低。

参照图10A，其中示出了共享的侧条(sidebar)情景。每个页面包括侧条部分和其它页面部分；根据现有技术，每个页面在不支持片段的高速缓存中被存储为具有所有从属对象的完整页面。在本发明的优选实施例中，每个页面被组成为包含侧条片段和其余页面片段，所有这些被存储在支持片段的高速缓存中。显然，在本发明的优选实施例中，侧条片段只存储一次。换言之，特定站点上的所有页面共事相同的侧条片段。如果侧条是每个页面的20％，则将其从所有页面中提取出可以把高速缓存的大小降低大约20％，因为不复制侧条。

参照图10B，其中示出了购物者组的情景。产品说明页面对于每个购物者组有不同的价格，但是产品说明的其余部分是独立于购物者组的。根据现有技术，对产品和购物者组的每个组合有一个产品页面，这些产品页面的每一个都有可能被高速缓存在不支持片段的高速缓存中。相反，根据本发明优选实施例的支持片段的高速缓存只需要存储针对产品-组组合的价格数据片段和产品说明片段，而不需要存储所有的整个页面组合。

潜在的存储空间节省可以估计如下。每个价格为100 B(s1)，其余产品说明为10kB(s2)。有10,000个产品(p)和5个购物者组(g)。如果存储完全扩展的页面，则总共可能有(10,000×5)＝50,000(p*g)个大小均大约为10kB的项(s2大约等于s1+s2)，其具有大约500,000kB(p*g*s2)的总大小。反之，如果将价格存储在与其余产品说明不同的单独片段中，则在高速缓存中有10,000(p)个均为10kB(s2)的产品片段，其具有100,000kB(p*s2)的大小，加上10,000×5＝50,000(p*g)个均为100B(s1)的价格，其具有5,000kB的大小。使用片段时的总大小为这些的和，或105,000kB。在实现了支持片段的高速缓存之后，高速缓存的大小降低了几乎5倍。

参照图10C，其中示出了一个性化情景。产品说明页面包含个性化部分，并且有10,000个产品(p)和100,000个用户(u)。根据现有技术，如果存储完全扩展的页面，则在高速缓存中可能总共有10,000×100,000＝1,000,000,000(u*p)个项。

相反，使用根据本发明优选实施例实现的支持片段的高速缓存，可以将页面存储为分立的片段。在这种情况下，在高速缓存中总共只有10,000+100,000＝110,000(u+p)个项，并且每个项更小。这产生大约20,000倍的大小降低。

继续同一例子，可以使用其SRC属性标识cookie，例如src=″cookie://{cookie name}″，或标识URI查询参数，例如src=″parm://{parm name}″的FRAGMENTLINK标签来替换该cookie或查询参数的值。在这种情况下，如果个性化信息小到足够成为cookie值，则可以使用这种变量替换来消除向Web应用服务器请求个性化片段和对其进行高速缓存的开销。例如，可以用其名称为“userName”并且值为″John Smith″的cookie，通过下面的HTML语句，完成象“Hello，John Smith.Welcome to our store!!!”这样的问候语：

Hello，{fragmentlink src=″cookie://userName″}.Welcome to ourstore!!!

参照图10D，其中示出了股票监视列表情景；股票监视列表可在许多Web门户上得到。页面包含个性化的股票行情列表。这个情景类似于个性化情景，例外之处是特定于用户的信息与最高级片段而不是包含的片段相关。每个用户具有单独的股票列表，但是每个股票被许多用户列表共享。有100,000个用户(u)和1,000个股票(s)。每个用户说明为1kB(s1)，而每个股票行情为100B(s2)。用户在其列表(1)中平均有10个股票。如果存储完全扩展的页面，高速缓存大小为100,000*1kB＝100,000kB(u*s1)，加上100,000*10*100B＝100,000 kB(u*l*s2)，总共为200,000kB。相反，如果将各个股票行情存储为单独的片段，则高速缓存大小为特定于用户的片段的100,000×1kB＝100,000kB(u*s1)，加上股票行情片段的1,000*100B＝100kB(s*s2)，总共100,100kB。由于不复制股票行情，这大约有2倍的大小降低。

通过使用片段的FOREACH特性可以进一步改进股票监视列表情景。在这种情况下，消除了所有特定于用户的片段。图10D也图解了这种情况。FOREACH特性指定了其值为由“=”分隔的名称-值对的以空格定界的列表的cookie。对于每个名称-值对，产生一个片段，其附加有该名称-值对作为URI查询参数。在这种情况下，名为“stocks”的cookie会具有股票符号参数列表作为其值，例如“symbol=IBM symbol=CSCOsymbol=DELL”。这会产生3个片段，cookie中的每个股票符号有一个片段。高速缓存的大小为单个非特定于用户的模板片段的1kB(s1)，加上股票行情片段的100kB(s*s2)，总共为101kB。这粗略有1000倍的大小降低，因为特定于用户的股票列表片段被单个股票列表片段替代。

本发明的优选实施例还降低了维护高速缓存内容所需的工作量。用于在特定应用中选择什么来构成片段的一个准则是一部分内容改变的频度。当内容改变过于频繁以至于不能每次人工发布时，应用通常使用访问数据库以产生内容的模板，例如JSP，以及当数据库改变或时间界限到期时自动无效内容的机制。这种动态内容方案使人摆脱出来，并且允许频繁更新。

当前，多数高速缓存不高速缓存具有查询参数的请求，因为其通常指示动态内容。然而动态内容通常是高速缓存的良好候选。虽然内容以某种速度改变(例如价格可能每周改变，共同基金每天改变，股票每几分钟改变)，然而在改变之间可能有大量的高速缓存命中，使得高速缓存仍然提供显著的性能改进。

当内容可快速改变时，重要的是减少每次改变导致的工作。将页面分隔成片段允许递增地生成内容。当改变发生时，只有直接受影响的那些页面中的那些部分必须再次生成。如果一段内容快速改变，则可以使其成为分立片段。

再次参照图10A中的侧条情景，侧条包含每隔几分钟改变的内容，例如新闻头条。如果存储完全扩展的页面，则当侧条改变时，必须再次产生和替换所有页面。相反，如果侧条是分立的片段，则当侧条改变时只需产生和替换一个片段。

再次参照图10B中的购物者组情景，购物者组价格可能根据该购物者组内的销售量每分钟改变。如果存储完全扩展的页面，则每分钟必须产生所有50,000个页面。这导致每分钟产生和替换500,000kB的高速缓存。相反，如果价格被存储为分立的片段，则仍然会产生和替换50,000个片段，但是只会产生和替换5,000kB的高速缓存。这在需要的带宽方面是100倍的降低。如果产品说明的非价格方面改变了，只需产生和替换一个片段，而不是5个页面。这在带宽方面是5倍的降低。

再次参照图10C中的个性化情景，产品可能每几秒改变，而特定于用户的个性化可能每天改变。如果高速缓存扩展的页面，则每次产品改变会导致产生和替换该产品的所有100,000个页面，而每次个性化信息改变会导致产生和替换该用户的所有10,000个页面。相反，如果产品说明和个性化信息被存储为分立的片段，则每次产品改变将只导致产生和替换一个片段(100,000倍的改进)，而每次个性化信息改变将只导致产生和替换一个片段(10,000倍的改进)。

再次参照图10D中的股票监视列表情景，股票价格可能每20秒改变。如果在高速缓存中存储扩展页面，则每20秒必须产生所有100,000个用户页面(100,000kB)。相反，如果股票被存储为分立的片段，则每20秒只需产生和替换1,000个股票片段(100kB)。这在带宽方面是超过1,000倍的改进。如果修改单个用户股票监视列表，例如用户在监视列表中加入或清除股票，则在任一情况下，只需产生和替换一个片段。

产生和使用片段高速缓存标识符的例子

如上所述，高速缓存信息与每个片段相关，该信息指示高速缓存如何高速缓存该片段。对于静态内容，高速缓存信息与每个片段相关。动态内容是由模板或程序(JSP、CGI等)产生的，并且高速缓存信息将与该模板相关。这可以是固定信息，这样该模板产生的所有片段将具有相同的值。或者，该模板可以具有确定高速缓存信息的代码，使得高速缓存信息能够根据某种算法对于每个产生的片段是不同的。在任一情况下，特定片段具有固定值。

片段可以被定义成已经被定界以与另一个部分内容组合的一部分内容。在本发明的优选实施例中使用了标准化的片段命名技术；该技术根据前面更加正式地描述的技术来产生高速缓存ID。这个部分通过再下面的一系列例子描述高速缓存ID的使用，虽然首先提供了对高速缓存ID的形成和确定的简要重述。

高速缓存以某种方式使用高速缓存ID来存储片段。足够信息应当被包含在高速缓存ID中，以使其在使用高速缓存的所有应用中是唯一的。例如，单独的产品ID可能与另一个商店的产品ID或全然不同的其它东西发生冲突。由于片段的URI路径通常必须至少部分地解决这个相同名称范围的问题，将URI路径包含为片段的高速缓存ID的一部分是方便的。

如下面的例子所示，高速缓存ID的信息内容决定片段共享的范围的大小。

(A)如果用户ID被包含在高速缓存ID中，则片段只用于该用户。

(B)如果购物者组ID被包含在高速缓存ID中，则在该购物者组的所有成员中共享此片段。

(C)如果没有用户ID或购物者组ID被包含在高速缓存ID中，则在所有用户中共享此片段。

Web应用开发人员可以通过片段的具有CACHEID指令的HTTPFRAGMENT头中的规则规定高速缓存ID的信息内容，所述CACHEID指令指明什么被包含在片段的高速缓存ID中。规则允许任何URI查询参数或cookie被附加到URI路径上，或允许完整的URI(包含查询参数)。不存在规则意味着不要高速缓存。当使用多个规则时，按出现顺序试用规则。第一个成功起作用的规则确定高速缓存ID。如果没有规则成功起作用，则不高速缓存片段。当查询参数或cookie被包含在高速缓存ID中时，它可以是必需的，也可以是可选的，如下所述。

(A)未出现在父的请求中的必需查询参数导致规则失败。

(B)未出现在父的请求或结果中的必需cookie导致规则失败。

(C)未出现的可选查询参数或cookie不被包含在高速缓存ID中。

高速缓存ID是大小写敏感的，除了某种标准已经声明为大小写不敏感的那些部分之外。HTTP规范规定URI的协议和主机名称是大小写不敏感的，而URI的其余部分，包含查询参数名，是大小写敏感的。根据规范“HTTP状态管理机制”(HTTP State Management Mechanism)，RFC2109，互联网工程任务组，1997年2月，cookie名是大小写不敏感的。通过将这些大小写不敏感的部分转换成统一的大小写，高速缓存实现可以容易地实施此规定。本发明优选实施例的片段高速缓存技术优选地使查询参数值和cookie值是大小写敏感的。

现在参照图11A-11H，其中一系列图例被用来图解本发明优选实施例的技术构造和使用用于存储和处理片段的唯一高速缓存标识符的方式。

参照图11A，站点上的所有父片段包含相同的侧条子片段。在本情景下，除了所有父片段包含相同的侧条片段外，不对父片段进行规定，所以只讨论子片段。子片段由其URI逻辑地限定。由于它是静态内容，它的高速缓存ID是完整的URI。高速缓存ID规则会是：

Fragment:cacheid=″URI″

换言之，高速缓存ID是包含所有查询参数的完整URI。高速缓存ID的一例子是：

http://www.acmeStore.com/sidebar.html

参照图11B，产品说明页面不包含嵌入或子片段，即该页面是唯一片段。它由productID逻辑地限定。页面URI具有productID查询参数。页面请求具有在登录期间由Web应用服务器产生的加密userID cookie。userID cookie允许特定于用户的状态(购物车、用户简档等)与用户相关。userID被用作cookie而不是查询参数，因为它可能用于几乎每个请求，因而将其放入每个链接中对于Web应用开发人员而言是乏味的。用于产品页面的单个高速缓存ID规则可以使用完整的URI作为高速缓存ID，其包含productID查询参数，这样可以用正确的限定来将其高速缓存。对于这个单个片段的页面，高速缓存ID可以是其URI。高速缓存ID规则会是：

Fragment:cacheid=″URI″

换言之，高速缓存ID是包含所有查询参数的完整URI。该高速缓存ID的一例子是：

http://www.acmeStore.com/productDesc.jsp?productID=AT13394

为这个最高级片段指定高速缓存ID的另一个方式是商家使用的作为URI查询参数的产品ID，例如AT13394，加上固定URI路径以保证唯一性，例如，http://www.acmeStore.com/productDesc。在这种情况下，高速缓存ID规则会是：

Fragment:cacheid=″(productId)″

换言之，高速缓存ID是串接在一起的以下部分：

(A)URI路径；和

(B)productID查询参数的名称和值。

规则中没有方括弧表示应当存在productID参数。否则规则失败，并且不会高速缓存片段。高速缓存ID的一例子是：

http://www.acmeStore.com/productDesc.jsp_productlD=AT13394

应当注意，Web应用开发人员只指定高速缓存ID的信息内容，而不是其精确的格式。高速缓存实现可以选择其自身的方式来编码高速缓存ID中的指定的信息内容。上述例子使用以下划线字符(“_”)作为分隔定界符的简单串接。Web应用开发人员不需要知道这种编码。

参照图11C，其中提供了产品说明情景的扩展。价格现在由用户所属的购物者组来确定，但是产品说明的其余部分独立于购物者组。父产品说明片段包含子价格片段。父被productID逻辑地限定。子由productID和groupID逻辑地限定。页面URI具有productID查询参数。页面请求具有加密的userID和groupID cookie。groupID cookie是由Web应用在登录期间根据用户简档产生的。使groupID成为cookie而不是查询参数，因为它可能用于几乎每个请求，因而将其放入每个链接中对于Web应用开发人员而言是乏味的。

价格应当在被父包含的分立子片段中。父片段的单个高速缓存ID规则将与产品显示情景中的相同。子片段的单个高速缓存ID规则将使用URI路径以及productID查询参数和groupIDcookie，使得它可以用正确的限定来高速缓存。应当注意，高速缓存ID不包含用户ID，因为那样的话片段只能被单个用户而不是属于相同购物者组的所有用户使用，从而导致更大的高速缓存，和更多工作量来保持高速缓存最新。该高速缓存ID规则会是：

Fragment:cacheid=″(productID，[groupID]″

换言之，高速缓存ID是串接在一起的以下部分：

(A)URI路径；

(B)productID查询参数的名称和值；和

(C)groupID cookie的名称和值，如果请求中出现的话。

逗号将URI查询参数与cookie分隔开。规则中的方括弧表示cookie是可选的。如果这个cookie不存在，则规则仍然可以成功，并且高速缓存ID将不包含cookie名称-值对。这允许商家具有非按组的价格以及按组的价格。该高速缓存ID的一例子可以是：

http://www.acmeStore.com/productDesc.jsp_productID=AT13394_groupID=*@#!

参照图11D，其中提供了购物者组情景的扩展。已经添加了对多个商家的支持；例如，应用服务提供商(ASP)在相同Web应用服务器中使用多种语言支持多个商家。父产品说明片段再次包含子价格片段。父由productID、merchantID和languageID逻辑地限定。子由productID、groupID、languageID和merchantID逻辑地限定。页面URI具有produ ctID和merchantID查询参数。请求具有加密userID、groupID和languageIDcookie。LanguageIDcookie是由Web应用在登录期间根据用户简档产生的。languageID被用作cookie而不是查询参数，因为它用于每个请求，因而将其放入每个链接中对于Web应用开发人员而言是乏味的。

用于父片段的单个高速缓存ID规则将使用URI路径和productID与merchantID查询参数，以及languageID cookie，使得可以用正确的限定将其高速缓存。父高速缓存ID规则会是：

Fragment:

cacheid=″(productID merchantID，[languageID])″

换言之，高速缓存ID是串接在一起的以下部分：

(A)URI路径；

(B)productID查询参数的名称和值；

(C)merchantID查询参数的名称和值；和

(D)languageID cookie的名称和值，如果它在请求中出现的话。

父高速缓存ID的一例子是：

http://www.acmeMall.com/productDesc.jsp_productID=AT13394_merchantID=MyStore languageID=eng

子片段的单个高速缓存ID规则会使用URI路径连同productID和merchantID查询参数、以及groupID和可选的languageID cookie，使得它可以用正确的限定来高速缓存。高速缓存ID规则会是：

Fragment:cacheid=″(productID merchantID，[groupID][languageID])″

换言之，高速缓存ID是串接在一起的以下部分：

(A)URI路径；

(B)productID查询参数的名称和值；

(C)merchantID查询参数的名称和值；

(D)groupID cookie的名称和值，如果它在请求中出现的话；和

(E)languageID cookie的名称和值，如果它在请求中出现的话。

高速缓存ID的一例子是：

http://www.acmeMall.com/productDesc.jsp_productID=AT13394_merchantID=MyStore_languageID=*@#!_languageID=eng

参照图11E，其中提供了ASP和多语言情景的扩展。已经添加了对标识产品的多个方式的支持。父产品说明片段包含子价格片段。父由产品(存在2个方式来指定这个)、languageID和merchantID来逻辑地限定。子由产品、groupID、languageID和merchantID逻辑地限定。产品或者由productID查询参数或者由partNumber和supplierNumber查询参数来标识。请求具有userID、groupID和languageID cookie。父片段会需要2个规则，其被指定为：

Fragment:cacheid=

″(productID merchantID，[languageID])

(partNumber supplierNumber merchantID，[languageID])″

尝试第一规则。如果它成功，则它确定高速缓存ID。如果它失败，则尝试第二规则。如果第二规则成功，则它确定高速缓存ID。如果第二规则失败，则不高速缓存片段。第一规则意味着高速缓存ID是串接在一起的以下部分：

(A)URI路径；

(B)productID查询参数的名称和值；

(C)merchantID查询参数的名称和值；和

(D)languageID cookie的名称和值，如果它在请求中出现的话。

第一规则的高速缓存ID的一例子是：

http://www.acmeStore.com/productDesc.jsp_productID=AT13394_merchantID=MyStore_anguageID=eng

第二规则意味着高速缓存ID是串接在一起的以下部分：

(A)URI路径；

(B)partNumber查询参数的名称和值；

(C)supplierNumber查询参数的名称和值；

(D)merchantID查询参数的名称和值；和

(E)languageID cookie的名称和值，如果它在请求中出现的话。

第二规则的高速缓存ID的一例子是：

http://www.acmeStoreo.com/productDesc.jsp_partNumber=22984z_supplierNumber=339001_merchantID=MyStore_languageID=eng

子片段需要2个规则，其被规定如下：

Fragment:cacheid=

″(productID merchantID，IgroupID][languageID])

(partNumber supplierNumber merchantID,[groupID][languageID])″

尝试第一规则。如果它成功，则它确定高速缓存ID。如果它失败，则尝试第二规则。如果第二规则成功，则它确定高速缓存ID。如果第二规则失败，则不高速缓存片段。第一规则表示高速缓存ID是串接在一起的以下部分：

(A)URI路径；

(B)productID查询参数的名称和值；

(C)merchantID查询参数的名称和值；

(D)groupID cookie的名称和值，如果它在请求中出现的话；和

(E)languageID cookie的名称和值，如果它在请求中出现的话。

第一规则的高速缓存ID的一例子是：

http://www.acmeStore.com/productDesc.jsp_productID=AT13394_merchantID=MyStore_groupID=*@#!_languageID=eng

第二规则意味着高速缓存ID是串接在一起的以下部分：

(A)URI路径；

(B)partNumber查询参数的名称和值；

(C)supplierNumber查询参数的名称和值；

(D)merchantID查询参数的名称和值；

(E)groupID cookie的名称和值；和

(F)languageID cookie的名称和值。

第二规则的高速缓存ID的一例子是：

http://www.acmeStore.com/productDesc.jsp_partNumber=22984Z_supplierNumber=339001_merchantID=MyStore_groupID=*@#!_language=eng

参照图11F，其中提供了使用个性化的产品说明情景的扩展。父产品说明片段包含子个性化片段。父片段被productID逻辑地限定。子片段被userID逻辑地限定。页面URI具有productID查询参数。请求具有userIDcookie。

父高速缓存ID包含productID查询参数。用于父片段的高速缓存ID规则会是以下2个情况中的任意一个：

Fragment:cacheid=″URI″

换言之，高速缓存ID是具有所有查询参数的完整URI。

另一个潜在规则会是：

Fragment:cacheid=″(productId)″

换言之，高速缓存ID是串接在一起的以下部分：

(A)URI路径；和

(B)productID查询参数的名称和值。

应当注意，即使对这个页面的请求包含userID cookie，它仍然不包含在任一片段的高速缓存ID中，因为片段是特定于产品的而不是特定于用户的。如果包含它，则这个片段只可被该用户访问，从而导致更大的高速缓存和用于保持高速缓存最新的更多工作量。高速缓存ID的一例子是：

http://www.acmeStore.com/productDesc.jsp_productID=AT13394

子个性化片段的高速缓存ID包含userID cookie。子片段的高速缓存ID规则会是：

Fragment:cacheid=″(,userId)″

换言之，高速缓存ID是串接在一起的以下部分：

(A)URI路径；和

(B)userID cookie的名称和值。

高速缓存ID的一例子是：

http://www.acmeStore.com/personalization.jsp_userID=@($*!%

在这个个性化例子中，个性化片段应当被标记为私有数据，例如通过使用“Cache-Control:private”。

参照图11G，简单门户页面上的父股票监视列表片段包含多个子股票行情片段。父片段还包含用户的名称以作为简单的个性化信息。父由userID逻辑地限定即股票符号的列表是特定于用户的。用户名称由userID逻辑地限定。每个子由其股票符号逻辑地限定，即股票的价格不是特定于用户的。页面URI不包含查询参数。请求具有userID cookie。

最高级片段包含所需的特定于用户的股票行情列表。最高级片段的URI不包含查询参数。最高级片段的高速缓存ID包含名称为userID的加密的cookie。高速缓存ID规则会是：

Fragment:cacheid=″(，userld)″

换言之，高速缓存ID是串接在一起的以下部分：

(A)URI路径；和

(B)userID cookie的名称和值。

高速缓存ID的一例子会是：

http://www.acmeInvest.com/stockList.jsp_userID=@($*!%

对于每个股票行情片段，高速缓存ID包含“symbol”(符号)参数。高速缓存ID规则会是完整的URI或URI路径加上stockSymbol查询参数：

Fragment:cacheid=″(stockSymbol)″

换言之，高速缓存ID是串接在一起的以下部分：

(A)URI路径；和

(B)符号查询参数的名称和值。

高速缓存ID的一例子会是：

http://www.acmeInvest.com/stockQuote.jsp_stockSymbol=IBM

这个情景可以被修改成使用FOREACH特性；股票行情片段将不改变，但是父片段可以高度优化。只存在一个静态最高级片段。会使用stockSymbols(股票符号)cookie，其值是用户的空格分隔的股票符号列表。对于所有用户只会有一个相当静态的父片段，其包含FRAGMENTLINK标签，FRAGMENTLINK标签的FOREACH属性会指明stockSymbols cookie。这为每个股票符号动态产生一个简单的FRAGMENTLINK，该FRAGMENTLINK的SRC属性与包含该FOREACH属性的FRAGMENTLINK的SRC相同，只是添加了股票符号作为查询参数。因为这个父片段对所有用户是相同的，可以使用单个高速缓存规则以正确的限定将其高速缓存，该高速缓存规则使用其没有查询参数的URI作为高速缓存ID，如下所示：

Fragment:cacheid=″URI″

stockSymbols cookie包含父片段的所有特定于用户的信息，并且随页面请求传递，所以它满足父的逻辑userID限定。

其值是用户名称的userName cookie会在用于简单个性化的FRAGMENTLINK标签中使用，该FRAGMENTLINK标签的SRC属性标识该userName cookie。这个片段不被高速缓存，因为它可以容易地由userName cookie产生。userName cookie包含这个片段的所有特定于用户的信息，并且随页面请求传递，所以它满足父的逻辑userID限定。

子片段的单个高速缓存ID规则使用其URI作为高速缓存ID，使得可以用正确的限定将其高速缓存，如下所示：

Fragment:cacheid=″URI″

在这个股票监视列表情景中，当不使用FOREACH特性时，最高级的股票监视列表片段会被标记为私有的，例如通过使用“Cache-Control:private”。当使用FOREACH特性时，只有一个最高级片段被共享，所以它不被标记为私有的。

参照图11H，其中的例子描述了类似于个性化门户页面例如myYahoo!的情景。第一级门户片段包含多个中级主题片段，例如股票、天气、体育，其每个包含多个叶项片段。父片段还包含用户的名称。最高级的门户片段由userID逻辑地限定，即主题的列表是特定于用户的。用户名称由userID逻辑地限定。中级主题片段由topicID和userID逻辑地限定，即主题中项的列表是特定于用户的。叶项片段由itemID逻辑地限定，即项的值不是特定于用户的。页面URI不包含查询参数。页面请求具有userID cookie。通过使用FOREACH特性，父片段可以被高度优化。

通过使用FOREACH特性，会使用主题cookie(在登录期间根据用户简档产生的)，其值为空格分隔的、该用户的topicID列表。对于所有用户会只有一个相当静态的父片段，其包含FRAGMENTLINK标签，该FRAGMENTLINK标签的FOREACH属性会指明主题cookie。这为每个topicID动态产生一个简单的FRAGMENTLINK，该FRAGMENTLINK的SRC属性与包含FOREACH属性的FRAGMENTLINK的SRC相同，只是附加有topicID作为查询参数。因为这个父片段对所有用户是相同的，可以使用单个高速缓存规则以正确的限定将其高速缓存，该高速缓存规则使用其没有查询参数的URI作为高速缓存ID，如下所示：

Fragment:cacheid=″URI″

主题cookie包含父片段的所有特定于用户的信息，并且随页面请求传递，所以它满足父的逻辑userID限定。其值是用户名称的userName cookie会在其SRC属性标识该userName cookie的用于简单个性化的FRAGMENTLINK标签中使用。这个片段不被高速缓存，因为它可以容易地从userName cookie产生。userName cookie包含这个片段的所有特定于用户的信息，并且随页面请求传递，所以它满足父的逻辑userID限定。

针对每个主题，存在一个主题片段。由于FOREACH特性，每个主题片段可以被高度优化。对于每个主题，会使用一个cookie(在登录期间根据用户简档产生的)，其值为空格分隔的、该用户和主题的itemID列表。对于每个主题，会只有一个用于所有用户的相当静态的主题片段，其包含一FRAGMENTLINK，该FRAGMENTLINK的FOREACH属性会指明该主题的相应cookie。这为每个itemID动态产生一简单的FRAGMENTLINK，该FRAGMENTLINK的SRC属性是包含该FOREACH属性的FRAGMENTLINK的SRC，只是附加有itemID作为查询参数(topicID查询参数已经在那里了)。因为每个主题片段对所有用户是相同的，可以使用单个高速缓存规则以正确的限定将其高速缓存，该高速缓存规则使用其具有其topicID作为查询参数的URI作为高速缓存ID。主题cookie包含主题片段的所有特定于用户的信息，并且随页面请求传递，所以它满足主题片段的逻辑userID限定。

每个项片段的URI包含其topicID和itemID作为查询参数。每个项片段的单个高速缓存ID规则使用其URI作为高速缓存ID，使得用正确的限定来将其高速缓存。

FRAGMENTLINK标签的规定的例子

再次参照图11A中的侧条例子，单个FRAGMENTLINK会被放在页面而不是侧条中，并且放在与侧条的期望位置相同的位置上，例如：

{fragmentlink

src=″http://www.acmeStore.com/sidebar.html″}

再次参照图11C中的购物者组例子，单个FRAGMENTLINK会被放在价格将出现的位置上，例如：

{fragmentlink

src=″http://www.acmeStore.com/productPrice.jsp″}

为特定价格片段构造的URI会如下所示：

http://www.acmeStore.com/productPrjce.jsp?productID=AT13394

对该片段的请求包含父的所有查询参数，即“productId”，和cookie，即“groupId”，使得它们可以在应用服务器中的productPrice.jsp的执行期间得到。

再次参照图11F中的个性化例子，最高级片段会包含位于个性化片段的期望位置的FRAGMENTLINK，例如：

{fragmentlink

src=″http://www.acmeStore.com/personalization.jsp″}

为特定的特定于用户的个性化片段构造的URI如下所示：

http://www.acmeStore.com/personalization.jsp?productID=AT13394

对该片段的请求包含父的所有查询参数(即“productId”)和cookie(即“userId”)。在personalization.jsp的执行期间，“userId”cookie被使用，但是“productId”查询参数被忽略。

再次参照图11G中的股票监视列表例子，最高级片段会包含可变数量的FRAGMENTLINK标签，这取决于用户想要多少股票行情。每个FRAGMENTLINK标签会位于股票行情将出现的位置。每个将如下所示：

{fragmentlink

src=″http://www.acmeInvest.com/stockQuote.jsp?symbol=IBM″}

针对特定股票行情片段构造的URI将如下所示：

http://www.acmeInvest.com/stockQuote.jsp?symbol=IBM

这个情景可以被修改成使用FOREACH特性；可变数量的FRAGMENTLINK标签被单个FRAGMENTLINK标签替代，该单个FRAGMENTLINK标签具有指明一cookie的名称(stocks)的FOREACH属性，该cookie的值为空格分隔的股票符号参数列表：

{fragmentlink

src=″http://www.acmelnvest.com/stockQuote.jsp″

foreach=″stocks″}

如果名称为“stocks”的cookie的值为

symbol=IBM symbol=CSCO symbol=DELL

则这等价于以下一组FRAGMENTLINK标签：

{fragmentlink

src=″http://www.acmelnvest.com/stockQuote.jsp?symbol=IBM″}

{fragmentlink

src=″http://www.acmelnvest.com/stockQuote.jsp?symbol=CSCO″}

{fragmentlink

src=″http://www.acmelnvest.com/stockQuote.jsp?symbol=DELL″}

再次参照图11H中的完整门户的例子，FOREACH特性可以被用于会被所有用户共享的单个静态最高级片段。会使用以下标识了一userNamecookie的FRAGMENTLINK来包含最高级片段中的userName，该userName cookie包含用户的名称：

{fragmentlink

src=″cookie://userName″}

最高级片段还会具有其FOREACH属性标识主题cookie的FRAGMENTLINK标签，该主题cookie包含该用户的主题列表：

{fragmentlink

src=″http://www.acmePortal.con/portalPage.jsp″

foreach=″topics″}

这个cookie包含topicID的列表。对于一个其值如下所示的主题cookie:

topjc=stocks topic=weather topic=tv

上述包含FOREACH属性的FRAGMENTLINK会产生以下一些简单的FRAGMENTLINK:

{fragmentlink

src=″http://www.acmePortal.com/portalPage.jsp?topic=stocks″}

{fragmentlink

src=″http://www.acmePortal.com/portalPage.jsp?topic=weather}

{fragmentlink

src=″http://www.acmePortal.com/portalPage.jsp?topic=tv″}

每个动态产生的SRC属性定位一个处理指定主题的片段。

Web应用服务器中“portalPage.jsp”的实现充当根据查询参数调用片段的调度器。没有参数返回最高级片段。“topic=stocks”查询参数返回股票主题片段。以股票主题片段为例，并且再次使用FOREACH特性，股票主题片段包含其FOREACH属性标识一股票cookie的FRAGMENTLINK，该股票cookie包含该用户的该主题的股票符号列表：

{fragmentlink

src=″http://www.stockQuotes.com/stockQuote.jsp″

foreach=″stocks″}

其示例性使用会是产生一个表的各行，其中股票coolie中的每个股票符号均有一行。对于其值如下的“stocks”cookie

symbol=IBM symbol=DELL symbol=CSCO

上述包含FOREACH属性的FRAGMENTLINK会动态产生以下一些FRAGMENTLINK:

{fragmentlink

src=″http://www.stockQuotes.com/stockQuote.jsp?symbol=IBM″}

{fragmentlink

src=″http://www.stockQuotes.com/stockQuote.jsp?symbol=DELL″}

{fragmentlink

src=″http://www.stockQuotes.com/stockQuote.jsp?symbol=CSCO″}

从父片段向子片段传递数据的例子

片段应当尽可能是自包含的。这是因为2个原因。第一个原因是良好的软件工程规定软件模块应当尽可能独立。模块之间的约定的数量和复杂度应当最小化，使得一个模块中的改变保持在局部，而不传播到其它模块。例如，应用可能从父模块获得数据，并且将这个数据传递到对其进行格式化的子模块。当进行此操作时，必须有描述数据是什么以及将如何将其传入的约定。子模块需要什么数据方面的任何改变均需要对两个模块进行改变。相反，如果子模块获得其自身的数据，则改变被保持在局部。如果需要使任一模块与获得其数据的方式无关，或使获得其数据的代码在若干模块中相同，则可以使用单独的数据bean(豆)对象和相应的约定来实现这些要求中的任何一个。然而，在父和子模块之间再添加另一个约定只会增加复杂度，而不会有任何益处。

片段应当是尽可能自包含的第二个原因是，为了使高速缓存高效，产生片段的代码应当是自包含的。在上述例子中，如果父模块为子模块获得所有数据，并且将其传递到子模块，则子模块本身只进行格式化。由于模块之间的这种依赖关系，如果子模块需要的数据变得过期了，则父和子都必须被无效和再次产生。这种依赖关系极大地降低了单独片段的高速缓存的效率。由多个父共享的片段使上述两个问题更加复杂。

JSP编程模型允许通过请求属性或会话状态在JSP之间传递数据。对于嵌套片段，请求属性机制不起作用，因为父和子JSP可能是在对应用服务器的不同请求中获得的。并且，如果父和子可以在不同会话中执行，则会话状态机制会不起作用。相反，应当传递的任何信息均应当使用URI查询参数或cookie。即使先前使用请求属性从父向子传递的复杂数据结构，仍然可以通过对其进行串行化并且将其包含为FRAGMENTLINK标签的SRC属性中的URI中的查询参数而传递。

即使在片段获得其自身的数据时，仍然需要在它们之间传递某些控制数据。再次参照上述例子，在侧条情景中，没有数据从最高级片段传递到侧条。在购物者组情景中，最高级的产品说明片段需要知道产品ID，而作为子的特定于组-产品的价格需要产品ID和购物者组ID二者。产品ID由外部请求提供。购物者组ID由应用使用用户ID产生，这二者都在登录时产生。产品ID和购物者组ID应当通过产品说明片段传递到价格片段。所有URI查询参数和cookie被自动传递到子片段。

在个性化情景中，最高级产品说明片段需要知道产品ID，子个性化片段需要知道用户ID。这些参数均由外部请求提供，所以用户ID应当通过产品说明片段向个性化片段传递。这是通过将名称为“userId”的cookie传递到子片段来实现的。

在股票监视列表情景中，最高级股票监视列表片段需要知道用户IDcookie，而每个子股票监视列表片段需要知道股票符号。股票符号和包含它们的FRAGMENTLINK标签是作为最高级的股票监视列表片段的一部分产生的。股票符号应当被传递到股票行情片段。这是通过将股票符号放置作为在FRAGMENTLINK的SRC属性中的URI的查询参数来实现的。

FRAGMENTLINK标签和FRAGMENT头的例子

现在参照表1A-1C，其中示出了用于上述侧条例子的一组HTML和HTTP语句。这个情景内的两个片段是静态的。父最高级片段会是JSP，因为它通过使用“jsp:include”包含另一个的片段，并且因为高速缓存控制信息需要与父片段相关。子侧条片段也是JSP，因为高速缓存控制信息需要与之相关，但是它不包含任何JSP标签。

表1A示出了一个JSP，该JSP包含用于包含侧条片段的最高级片段的HTML语句。

------------------------------

{html}

{head}

    {title}包含侧条的页面。{/title}

{/head}

{body}

    {!添加侧条。}

    {jsp:include page=″/sidebar.html″}

    {p}这是正文的其余部分。

{/body}

{/html}                           表1A

---------------------------------

表1B示出了会由Web应用服务器为最高级片段产生的HTTP输出。

---------------------------------

HTTP/1.1 200 OK

Date:Mon,23 Apr 2002 17:04:04 GMT

Server:IBM_HTTP_Server/1.3.6.2 Apache/1.3.7-dev(Unix)

Last-Modified:Wed,11 Apr 2001 21:05:09 GMT

ETag:″b7-d8d-3ad4c705″

Accept-Ranges:bytes

Content-Length:246

Content-Type:text/html

Cache-Control:no-cache fragmentrules

Pragma:no-cache

Fragment:cacheid=″URI.″

Cache-Control:max-age=600

Fragment:contains-fragments

{html}

{head}

    {title}包含侧条的页面。{/title}

{/head}

{body}

{％--添加侧条--％}

     {fragmentlink src=″http://www.acmeStore.com/sidebar.html″}

     …这是正文的其余部分…

{/body}

{/html}                          表1B

-------------------------------

表1C示出了会由Web应用服务器为侧条片段产生的HTTP输出。

-------------------------------

HTTP/1.1 200 OK

Date:Mon,23 Apr 2002 17:04:04 GMT

Server:IBM_HTTP_Server/1.3.6.2Apache/1.3.7-dev(Unix)

Last-Modified:Wed,11 Apr 2001 21:05:09 GMT

ETag:″b7-d8d-3ad4c705′

Accept-Ranges:bytes

Content-Length:82

Content-Type:text/html

Cache-Control:no-cache fragmentrules

Pragma:no-cache

Fragment:cacheid=″URL″

Cache-Control:max-age=6000

{html}

{body}

   {p}这是侧条主体。

{/body}

{/html}                            表1C

-------------------------------------

现在参照表2A-2D，其中示出了用于上述购物者组例子的一组HTML和HTTP语句。这个情景内的两个片段都是动态的。一个JSP被用于包含特定于产品-组的价格片段的最高级片段。子片段也是JSP，因为它包含用于获得适当价格的商务应用逻辑。

表2A示出了一个包含HTML语句的JSP，所述HTML语句用于包含子片段的最高级产品说明片段。

-------------------------------------

{html}

{head}

    {title}产品说明。{/title}

{/head}

{body}

{h}带有购物者组的产品。{/h1}

{%@page language=″Java″

        import=″com.acmeStore.databeans.*″

%}

{%

  //添加产品说明。ProductSGDataBean databean=new ProductSGDataBean();databean.setProductId(request.getParameter(″productId″));databean.execute();out.println(″{p}Product id is″+databean.getProductId());%}

{%--添加价格--%}

{jsp:include page=″/groupPrice.jsp″}

{/body}

{/html}                           表2A

--------------------------------

表2B示出了会由Web应用服务器为产品说明片段产生的HTTP输出。

--------------------------------

HTTP/1.1 200 OK

Date:Mon,23 Apr 2002 17:04:04 GMT

Server:IBM_HTTP_Server/1.3.6.2 Apache/1.3.7-dev(Unix)

Last-Modified:Wed,11 Apr 2001 21:05:09 GMT

ETag:″b7-d8d-3ad4c705″

Accept-Ranges:bytes

Content-Length:82

Content-Type:text/html

Cache-Control:no-cache fragmentrules

Pragma:no-cache

Fragment:cacheid=″(productId)″

Cache-Control:max-age=600

Fragment:contains-fragments

{html}

{head}

   {title}产品说明。{/title}

{/head}

{body}

{h1}带有购物者组的产品。{/h1}

    …格式化的产品说明会在这里…

    {fragmentlink src=″http://www.acmeStore.com/groupPrice.jsp″}

{/body}

{/html}                     表2B

----------------------------

表2C示出了一个包含HTML语句的JSP，所述HTML语句用于特定于子产品-组的价格片段。

----------------------------

{html}

{body}

{%@page language=″java″

         import=″com.acmeStore.databeans.*″%}

{%//从其cookie得到GroupId。

      Cookie[]cookies=request.getcookies();

      String groupId=null;

for(int i=0;i{cookies.length;i++){

    if(cookies[i].getName().equals(″groupId″)){

        groupId=cookies[i].getValue();

    }

}

//获得价格。

GroupPriceDataBean databean=newGroupPriceDataBean();

databean.setGroupId(groupId);

databean.execute();

String price=databean.getprice();

out.println(″{p}Price is″+price);%}

{/body}

{/html}                     表2C

------------------------------

表2D示出了会由Web应用服务器对特定于产品-组的价格片段产生的HTTP输出。

------------------------------

HTTP/1.1 200 OK

Date:Mon,23 Apr 2002 17:04:04 GMT

Server:IBM_HTTP_Server/1.3.6.2 Apache/1.3.7-dev(Unix)

Last-Modified:Wed,11 Apr 2001 21:05:09 GMT

ETag:″b7-d8d-3ad4c705″

Accept-Ranges:bytes

Content-Length:82

Content-Type:text/html

Cache-Control:private

Cache-Control:no-cache fragmentrules

Pragma:no-cache

Fragment:cacheid=″(productId,groupId)″

Fragment:dependencies=″http://www.acmeStore.com_groupid=*@#!″

{html}

{body}

    价格为$24.99

{/body}

{/html}                       表2D

---------------------------

现在参照表3A-3D，其中示出了用于上述个性化例子一组HTML和HTTP语句。这个情景内的两个片段都是动态的。一个产生最高级的产品片段的JSP包含单个特定于用户的个性化片段。子片段也是JSP，因为它包含用于获得用户的适当个性化数据的商业应用逻辑。

表3A示出了一个包含HTML语句的JSP，所述HTML语句用于包含子片段的最高级产品说明片段。

---------------------------

{html}

{head}

{title}产品说明。{/title}

{/head}

{/body}

{%@page language=″java″

     import=″com.acmeStore.databeans.*,com.acmeStore.formatters.*″

％}

{%

    //添加产品说明。

    ProductDataBean databean=new ProductDataBean();

    databean.setProductId(request.getParameter(″productld″));

    databean.execute();

    ProductFormatter productEormatter=new productFormatter();

   out.println(productFormaatter.format(databean));

%}

{%--添加个性化信息--%}

{jsp:include page=″/personalization.jsp″}

{/body}

{/html}                           表3A

-----------------------------

表3B示出了会由Web应用服务器为产品说明片段产生的HTTP输出。

-----------------------------

HTTP/1.1 200 OK

Date:Mon,23 Apr 2002 17:04:04 GMT

Server:IBM_HTTP_Server/1.3.6.2 Apache/1.3.7-dev(Unix)

Last-Modified:Wed,11 Apr 2001 21:05:09 GMT

ETag:″b7-d8d-3 ad4c705″

Accept-Ranges:bytes

Content-Length:82

Content-Type:text/html

Cache-Control:no-cache fragmentrules

Pragma:no-cache

Fragment:cacheid=″(productId)″

Cache-Control:max-age=600

Fragment:contains-fragments

{html}

{head}

    {title}产品说明。{/title}

{/head}

{body}

{h1}具有购物者组的产品。{/h1}

    …格式化的产品说明会在这里…

    {fragmentlinksrc=″http://www.acmeStore.com/personalization.jsp″}

{/body}

{/htm1}                        表3B

----------------------------------

表3C示出了一个包含用于特定于用户的子片段的HTML语句的JSP。

----------------------------------

{htm1}

{body}

{%@page language=″java″

         import=″com.acmeStore.databeans.*″%}

{%//从userld cookie获得userID。

     Cookie[]cookies=request.getCookies();

     String userld=null;

    for(int i=0;i{cookies.length;i++){

        if(cookies[i].getName().equals(″userId″)){

             userld=cookies[i].getValue();}}

     ″dependencies=\″http://www.acmeStore.com/userId=@($*!%\″″);

     response.addHeader(″Fragment″,″cacheid=\″(,userld)\″″);

     //这个取决于userld:

    response.addHeader(″Fragment″,″dependencies=\″http://www.acmeStore.com/userId=″+userId+″\″″);

    //产生个性化信息。

    PersonalizationDataBean databean=newPersonalizationDataBean();

    databean.setUserId(userId);

    databean.execute();

    String personalization=databean.getPersonalization();

    out.println(personalization);%}

{/body}

{/html}                      表3C

--------------------------------

表3D示出了会由Web应用服务器为子片段产生的HTTP输出。

--------------------------------

HTTP/1.1 200 OK

Date:Mon,23 Apr 2002 17:04:04 GMT

Server:IBM_HTTP_Server/1.3.6.2 Apache/1.3.7-dev(Unix)

Last-Modified:Wed,11 Apr 2001 21:05:09 GMT

ETag:″b7-d8d-3ad4c705″

Accept-Ranges:bytes

Content-Length:82

Content-Type:text/html

Cache-Control:private

Cache-Control:no-cache fragmentrules

Pragma:no-cache

Fragment:cacheid=″(,userId)″

Fragment:dependencies=″http://www.acmeStore.com_userId=@($*!%″

{html}

{body}

   …个性化信息在这里…

{/body}

{/html}                     表3D

----------------------------

现在参照表4A-4F，其中示出了用于上述股票监视列表例子的一组HTML和HTTP语句。这个情景内的两个片段都是动态的。

表4A示出了一个产生包含多个股票行情片段的最高级的股票监视列表片段的JSP。“jspext:cookie”标签显示名称为“userName”的cookie中的用户名称。这个例子动态产生可变数量的“RequestDispatcher.include”方法调用，每个均在输出中产生一个FRAGMENTLINK标签。

----------------------------

{html}

{head}

{title}股票查看列表。{/title}

{/head}

{body}

{%@page language=″java″

         import=″com.acmeInvest.databeans.*″

%}

{%

//从userId cookie获得userId。

Cookie[]cookies=request.getCookies();

String userId=null;

for(inti=0;i{cookies.length;i++){

    if(cookies[i].getName().equals(″userId″)){

         userId=cookies[i].getValue();

    }

}%}{table border}{tr}

{th colspan=2 align=center}

{jspext:cookie name=″userName″}的股票查看列表：

{/th}{/tr}{tr}

{th align=center}Symbol{/th}

{th align=center}Price{/th}{/tr}{%

//向表中添加股票查看列表行。

StockListDataBean databean=newStockListDataBean();

databean.setUserId(userId);

databean.execute();

String[]symbols=databean.getStockSymbolList();

for(inti=0;i{symbols.lengyh;i++){

String url=″/stockQuote.jsp?stockSymbol=″+symbols[i];

ServletContext servletContext=getServletContext();

RequestDispatcher requestDispatcher=servletContext.getRequestDispatcher(″/stockQuote.jsp″);

          requestDispatcher.include(request,response);

    }

%}

{/table}

{/body}

{/html}                          表4A

----------------------------

表4B示出了会由Web应用服务器为股票监视列表片段产生的HTTP输出。

----------------------------

HTTP/1.1 200 OK

Date:Mon,23 Apr 2002 17:04:04 GMT

Server:IBM_HTTP_Server/1.3.6.2 Apache/1.3.7-dev(Unix)

Last-Modified:Wed,11 Apr 2001 21:05:09 GMT

ETag:″b7-d8d-3ad4c705″

Accept-Ranges:bytes

Content-Length:82

Content-Type:text/html

Cache-Control:private

Cache-Control:no-cache fragmentrules

Pragma:no-cache

Fragment:cacheid=″(,userId)″

Fragment:contains-fragments

{html}

{body}

{table border}{tr}

     {th colspan=2 align=center}

     {fragmentlink src=″cookie://userName″}的股票查看列表：

     {/th}

{/tr}

{tr}

    {th align=center}Symbol{/th}

    {th align=eenter}Price{/th}

  {/tr}

  {fragmentlink src=″http://www.acmeInvest.com/stockQuote.jsp?symbol=IBM″}

  {fragmentlink src=″http://www.acmeInvest.com/stockQuote.jsp?symboi=CSCO″}

  {fragmentlink src=″http://www.acmeInvest.com/stockQuote.jsp?symbol=DELL″}

{/table}

{/body}

{/html}                           表4B

-------------------------------

表4C示出了一个产生引入FOREACH属性的最高级的股票监视列表片段的JSP。

-------------------------------

{html}

{head}

{title}股票查看列表。{/title}

{/head}

{body}

{%@page   language=″java″

          import=″com.acmeInvest.databeans.*″%}

{table border}

     {tr}

        {th colspan=2 align=center}

        {jspext:cookie name=″userName″}的股票查看列表：

        {/th}

{/tr}

{tr}

     {th align=center}Symbol{/th}

     {th align=center}Price{/th}

{/tr}

{jspext:include page=″/stockQuote.jsp″foreach=″stocks″}

{/table}

{/body}

{/html}                           表4C

---------------------------

表4D示出了会由Web应用服务器针对引入FOREACH属性的最高级的股票监视列表片段产生的HTTP输出。

---------------------------

HTTP/1.1 200 OK

Date:Mon,23 Apr 2002 17:04:04 GMT

Server:IBM_HTTP_Server/1.3.6.2 Apache/1.3.7-dev(Unix}

Last-Modified:Wed,11 Apr 2001 21:05:09 GMT

ETag:″b7-d8d-3ad4c705″

Accept-Ranges:bytes

Content-Length:246

Content-Type:text/html

Cache-Control:no-cache fragmentrules

Pragma:no-cache

Fragment:contains-fragments

Fragment:cacheid=″URL″

Cache-Control:max-age=600

{html}

{head}

    {title}股票查看列表。{/title}

{/head}

{body}

    {table border}

        {tr}

           {th colspan=2 align=center}

           {fragmentlink src=″cookie://userName″}的股票查看列表：

           {/th}

    {/tr}

    {tr}

       {th align=center}Symbol{/th}

       {th align=center}Price{/th}

  {/tr}

  {fragmentlink

         src=″http://www.acmeInvest.com/stockQuote.jsp″foreach=″stocks″}

   {/table}

{/body}

{/html}                         表4D

------------------------------

表4E示出了产生各个股票行情的JSP。

------------------------------

{html}

{body}

{%@page  language″java″

          import=″com.acmeInvest.databeans.*″

%}

{%

   //添加股票行情。

   StockQuoteDataBean databean=newStockQuoteDataBean();

   String symbol=request.getParameter(″symbol″);

   databean.setStockSymbol(symbol);

   databean.execute();

   String quote=databean.getStockQuote();

   String rtn=

      ″{tr}″+

     ″{td align=center}″+symbol+″{/td}″+

     ″{td align=right}″+quote+″{/td}″+

     ″{/tr}″;

  out.println(rtn);

%}

{/body}

{/html}                                表4E

---------------------------------

表4F示出了会由Web应用服务器为针对符号查询参数“IBM”产生的HTTP输出。

----------------------------------

HTTP/1.1 200 OK

Date:Mon,23 Apr 2002 17:04:04 GMT

Server:IBM-HTTP_Server/1.3.6.2 Apache/1.3.7-dev(Unix)

Last-Modified:Wed,11 Apr 2001 21:05:09 GMT

ETag:″b7-d8d-3ad4c705″

Accept-Ranges:bytes

Content-Length:82

Content-Type:text/html

Cache-Control:private

Cache-Control:no-cache fragmentrules

Pragma:no-cache

Fragment:cacheid=″(,userId)″

Cache-Control:max-age=1200

{html}

{body}

   {tr}

       {td align=center}IBM{/td}

       {td align=right}$112.72{/td}

   {/tr}

{/body}

{/html}                           表4F

--------------------------------

结论

通过前面提供的对优选实施例的详细描述，应当可理解本发明的优选实施例的优点。可以在部署于整个网络的计算设备内的高速缓存管理单元内实现片段高速缓存技术，使得这些高速缓存管理单元提供分布式片段高速缓存机制。

FRAGMENT头被定义成用于例如HTTP的网络协议内；该头使元数据与片段相关，以用于涉及片段的处理和高速缓存的各种目的。例如，该头被用来标识客户机、服务器或某个中间高速缓存是否具有页面装配能力。该头也指定用于形成片段的高速缓存标识符的高速缓存ID规则；这些规则可以基于片段的URI，或者URI路径和来自URI的诸查询参数以及伴随请求的诸cookie的某种组合。另外，该头可以规定片段的依赖关系以支持主机启动的无效。

FRAGMENTLINK标签被用来指定页面中用于在页面装配或页面呈现期间将插入的所包含片段的位置。FRAGMENTLINK标签被定义成包含足够信息，以或者找到高速缓存中的链接片段或者从服务器获得该片段。当将片段存储在高速缓存中时，以及当处理来自请求的源标识符以找到高速缓存内的片段时，都使用高速缓存ID规则。为找到高速缓存中的片段，使用与片段的URI路径相关的高速缓存ID规则来确定高速缓存ID。这些规则允许在形成片段的高速缓存ID时具有高度灵活性，而无需部署强制实施用于高速缓存ID形成的标准实现的计算机程序。可以使用多个高速缓存ID规则。高速缓存ID规则允许高速缓存ID是片段的完整URI，或是URI和诸查询参数或诸cookie的组合。这一方案允许相同的FRAGMENTLINK根据父片段的查询参数和cookie定位不同的片段；例如，对产品说明页面的请求中的用户ID cookie可以被用来形成用于个性化片段的高速缓存ID。

必须注意，虽然前面在一个全功能数据处理系统的情境下描述了本发明的优选实施例，但本领域的普通技术人员会理解到，可以以计算机可读介质中的指令的形式和其它多种形式分发与本发明的优选实施例相关的某些处理，无论实际被用来进行分发的信号承载介质的具体类型是什么。计算机可读介质的例子包含诸如EPROM、ROM、磁带、纸张、软盘、硬盘驱动器、RAM和CD-ROM的介质，以及诸如数字和模拟通信链路的传输类型介质。

Claims (26)

1.一种用于在网络中的数据处理系统上处理对象的方法，该方法包括以下步骤：

在计算设备上接收第一消息；以及

确定第一消息中的消息头指示第一消息涉及一片段。

2.如权利要求1所述的方法，还包括以下步骤：

确定第一消息中的消息头指示该片段是可高速缓存的。

3.如权利要求1或2所述的方法，还包括以下步骤：

在由计算设备内的高速缓存管理单元维护的高速缓存中存储来自第一消息的片段，其中高速缓存管理单元同等地运行来支持片段高速缓存操作，无论计算设备充当位于整个网络中的客户机、服务器还是集线器。

4.如权利要求3所述的方法，还包括以下步骤：

在计算设备上接收第二消息，其中第二消息包括针对该片段的请求；

响应接收到第二消息而搜索高速缓存；

响应搜索高速缓存而从高速缓存中获得该片段；以及

在第三消息中向第二消息的发起方发送该片段，而无需向第二消息的目的地址发送第二消息。

5.如权利要求1所述的方法，还包括以下步骤：

确定该片段是否是包含针对下一级片段的链接的最高级片段；

响应确定该片段是包含针对下一级片段的链接的最高级片段，获得下一级片段；以及

将最高级片段和下一级片段组合成装配的片段。

6.如权利要求1至3中任何一个所述的方法，还包括以下步骤：

从第一消息中获得一组依赖关系标识符，其中依赖关系标识符是由发出该片段的服务器产生的；以及

以和该片段的源标识符相关的方式存储该组依赖关系标识符。

7.如权利要求6所述的方法，还包括以下步骤：

接收无效请求消息；

从无效请求消息中获得依赖关系标识符；

确定与该依赖关系标识符相关的一组片段；以及

响应确定出与该依赖关系标识符相关的该组片段而从高速缓存中清除该组片段。

8.如权利要求1至3中任何一个所述的方法，还包括以下步骤：

从第一消息中获得一组片段高速缓存规则，其中片段高速缓存规则确定用于为该片段产生高速缓存标识符的方式；以及

根据一片段高速缓存规则产生该片段的高速缓存标识符。

9.如权利要求8所述的方法，还包括以下步骤：

使用所产生的用于该片段的高速缓存标识符执行存储操作。

10.如权利要求1所述的方法，其中第一消息包括该片段的源标识符，该方法还包括以下步骤：

产生包括该片段的应答消息；以及

在应答消息中插入指示第一消息涉及一片段的消息头。

11.如权利要求10所述的方法，还包括以下步骤：

在应答消息中插入指示该片段可高速缓存的消息头。

12.一种用于在网络中的数据处理系统上处理对象的设备，该设备包括：

用于在一计算设备上接收第一消息的装置；以及

用于确定第一消息中的消息头指示第一消息涉及一片段的装置。

13.如权利要求12所述的设备，还包括：

用于确定第一消息中的消息头指示该片段可高速缓存的装置。

14.如权利要求12或13所述的设备，还包括：

用于在由计算设备内的高速缓存管理单元维护的高速缓存中存储来自第一消息的片段的装置，其中高速缓存管理单元同等地运行来支持片段高速缓存操作，无论计算设备充当位于整个网络中的客户机、服务器还是集线器。

15.如权利要求14所述的设备，还包括：

用于在计算设备上接收第二消息的装置，其中第二消息包括针对该片段的请求；

用于响应接收到第二消息而搜索高速缓存的装置；

用于响应搜索高速缓存而从高速缓存中获得该片段的装置；以及

用于在第三消息中向第二消息的发起方发送该片段，而无需向第二消息的目的地址发送第二消息的装置。

16.如权利要求12所述的设备，还包括：

用于确定该片段是否是包含针对下一级片段的链接的最高级片段的装置；

用于响应确定该片段是包含针对下一级片段的链接的最高级片段，而获得下一级片段的装置；以及

用于将最高级片段和下一级片段组合成装配的片段的装置。

17.如权利要求12到14中任何一个所述的设备，还包括：

用于从第一消息中获得一组依赖关系标识符的装置，其中依赖关系标识符是由发出片段的服务器产生的；以及

用于以和该片段的源标识符相关的方式存储该组依赖关系标识符的装置。

18.如权利要求17所述的设备，还包括：

用于接收无效请求消息的装置；

用于从无效请求消息获得依赖关系标识符的装置；

用于确定与依赖关系标识符相关的一组片段的装置；以及

用于响应确定出与依赖关系标识符相关的该组片段而从高速缓存中清除该组片段的装置。

19.如权利要求12到14中任何一个所述的设备，还包括：

用于从第一消息获得一组片段高速缓存规则的装置，其中片段高速缓存规则确定用于产生该片段的高速缓存标识符的方式；以及

用于根据片段高速缓存规则为该片段产生高速缓存标识符的装置。

20.如权利要求19所述的设备，还包括：

用于使用所产生的用于该片段的高速缓存标识符执行存储操作的装置。

21.如权利要求12所述的设备，其中请求消息包括片段的源标识符，该设备还包括：

用于产生包括该片段的应答消息的装置；以及

用于在应答消息中插入指示第一消息涉及一片段的消息头的装置。

22.如权利要求21所述的设备，还包括：

用于在应答消息中插入指示该片段可高速缓存的消息头的装置。

23.一种计算机可读介质中的用于在网络中的数据处理系统中处理对象的计算机程序产品，该计算机程序产品包括用于执行如权利要求1到11中任何一个所述的方法的指令。

24.一种被计算设备用来定义通过网络发送的消息的数据结构，该数据结构包括：

表明消息是请求消息或应答消息的指示符；以及

片段头，其包括指示消息将由支持片段的高速缓存管理单元处理的关键字，和指示将处理消息的方式的一或多个片段头指令。

25.如权利要求24所述的数据结构，还包括：

片段头指令，其包含在应答消息中以指示一组依赖关系标识符，所述依赖关系标识符被原始服务器用来从支持片段的高速缓存管理单元所维护的高速缓存中清除应答消息中的片段。

26.如权利要求24所述的数据结构，还包括：

片段头指令，其包含在应答消息中以指示一组片段高速缓存规则，所述片段高速缓存规则被用来形成唯一标识应答消息中的片段的高速缓存标识符。

Images