CN1979485A

CN1979485A - 在门户中有效处理导航状态的方法和系统

Info

Publication number: CN1979485A
Application number: CNA2006101470692A
Authority: CN
Inventors: S·贝尔; C·洛伊厄; F·波施
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2005-12-09
Filing date: 2006-11-14
Publication date: 2007-06-13
Also published as: US20070136415A1; US7801970B2

Abstract

本发明提供有效处理导航状态的方法和系统，其将最新导航状态分为基本导航状态部分和增量导航状态部分。基本导航状态描述在所有URL中相同的最新导航状态的那部分，并被编码在将被提交到客户机的浏览器的页面标记的报头中。增量导航状态部分描述特定URL的语义，并被编码在其相关的URL中。使用这种URL的每个用户交互使浏览器提交基本部分和增量部分。在服务器侧，基本部分和增量部分被合并以产生新的导航状态，作为呈现新的页面的基础。导航状态被表示为分级树型结构，其被有效地串行化并通过现有压缩技术进行压缩。由于避免了导航信息的类型转换，因此节省了处理时间。另外，本发明还包括减少必须被串行化的信息的数量的策略。

Description

在门户中有效处理导航状态的方法和系统

技术领域

本发明涉及一种用于在门户应用中有效处理导航状态的方法、系统和计算机程序产品，特别地，涉及减小门户页面的标记大小，减小URL长度，以及减少生成作为门户页面一部分的URL所需要的处理时间。

背景技术

如本发明所使用的，导航状态描述“作为特定客户机的所有导航交互的结果的门户的当前视图”。客户机可以通过与门户页面交互，例如导航到新的页面，而请求(查询)不同的视图。这种类型的交互不改变服务器侧的状态，而只是向服务器请求新的视图；因此，在HTTP方面，这是“安全的”操作。该交互的特征是：客户机可以使用其浏览器的向前和向后按钮向前和向后导航该交互的最近的视图，并且客户机可以用书签标记视图并在稍后的时间点通过调用浏览器书签返回到这些视图。

HTTP的一个主要特征在于它是无状态协议，即，在HTTP中不存在跨越多个请求/响应交互的会话的概念。但是，由于几乎所有的应用场景都要求某些机制在整个请求中保存其状态，因此已经出现了一些机制，其考虑创建(逻辑的)有状态的会话并且可确定地被当作现有技术的状态。两种最流行的现有技术的状态保存机制如下所述：

为了在客户机(通常是浏览器)和服务器之间启动逻辑会话，服务器向客户机返回额外的“set-cookie”响应报头，其主要包含名值对。客户机在文件中持久地存储该cookie，并将其与服务器的URL相关联。对于每个请求，客户机使用“cookie”请求报头将该cookie返回到服务器。通过分析cookie，服务器(不是HTTP服务器，而是诸如小服务程序(servlet)或CGI的应用程序或服务器侧脚本)可以识别包含所需要的状态信息的用户专用的会话。注意，cookie还考虑在整个会话边界上保持状态，因为在客户机上的持久的cookie文件通常比在服务器上的对应会话的存在时间长。

第二种变形在服务器和客户机之间交换整个状态信息。服务器使用(HTML)表单的隐藏输入文件将状态存储在所请求的页面的标记中。另外，该应用确保页面标记中的每个URL都启动一个表单提交，使得作为隐藏输入字段的一部分的状态与该请求一起流到HTTP服务器。

在当今的Web应用中，使用以上简述的机制之一，甚至导航状态都在整个请求中被大部分保存。然而，这两种方法在书签能力、高速缓存、向后/向前按钮和由搜索引擎索引(“爬行能力”)方面，都具有一些主要缺点。

在逻辑服务器侧HTTP会话(例如通过cookie识别的)中存储导航状态具有以下不足：

由于在服务器侧会话中保存的导航状态仅有有限的生存期，因此浏览器书签不起作用。通常，在一段不活动的时间后，会话中止。在会话中止后，导航状态不能在服务器上还原，即，服务器将传送应用的缺省视图。

使用浏览器的向后和向前按钮向后和向前导航最近的视图不起作用。注意，在那种情况下，只要保持会话，状态就不会丢失，但是向后和向前按钮的操作不对该状态产生任何影响。

由于这样的高速缓存器通常使用URL作为其高速缓存键(cache key)，所以高速缓存(浏览器侧、服务器侧和代理高速缓存)的好处被极大地降低。用几乎每一个交互重写高速缓存器条目，导致几乎为零的高速缓存器命中率。

Web搜索引擎不能很好地索引站点。搜索引擎通过存储有关其从Web本身检索的大量Web页面的信息而工作。这些页面通过被称为“网络爬虫(Web crawler)”的Web浏览器检索，该Web浏览器跟随其在页面上看到的每一个URL(分别在标记中)。

在HTML表单的隐藏输入字段中存储导航状态具有较少的缺点，但是它也不能解决上述的所有问题。只要各个页面被高速缓存，书签能力就起作用。向后和向前按钮起作用。仍存在高速缓存和爬行能力(crawlability)问题。注意，由于该机制要求页面级的表单，因此依赖于隐藏输入字段的状态管理不能应用于门户区域。然而，页面级表单不能被使用，符合JSR168的标记的门户小程序(portlet)也可以使用HTML表单，从而导致嵌套的表单(这是HTML标准禁止的)。

发明内容

本发明的目的是提供一种用于有效地对门户的导航状态编码的方法、系统和计算机程序产品，以避免现有技术中存在的不足。

本发明提供一种用于通过将导航状态分为基本导航状态部分和增量导航状态部分而有效地处理导航状态的方法、系统和计算机程序产品。基本导航状态描述在所有URL上相同的最新导航状态的那部分，其被编码在将被提交到客户机的浏览器的页面标记的报头中。增量导航部分描述特定URL的语义，其被编码在其相关的URL中。每个使用这种URL的用户交互使浏览器提交基本部分和增量部分。在服务器侧，基本部分和增量部分被合并以产生新的最新导航状态，作为呈现新页面的基础。新的最新导航状态被表示为分级树型结构，其可以被有效地串行化并通过现有技术的压缩技术压缩。分级树型结构基于根据状态串行化优化的定义明确的状态模型。状态模型将所包含的导航状态信息安排在基于字符的信息中。由于避免了导航状态信息的类型转换，因此节省了处理时间。另外，本发明包括减少必须进行串行化的信息的数量的其它策略。

附图说明

在下面详细描写的说明书中，本发明的上述以及其它目的、特征和优点将会很清楚。

在所附的权利要求书中陈述本发明的新颖的特征。然而，当结合附图进行阅读时，通过参考下面对示意性实施例的详细说明，本发明本身以及最佳实施方式、其它目的和优点将会得到很好的理解，其中：

图1示出门户的屏幕快照，其中构成该特定视图的导航状态的多个UI部分被突出显示；

图2A示出用于实现本发明的优选门户结构；

图2B示出在根据图2A的门户中根据本发明的有效处理导航状态的方法的优选实施例的交互图；

图2C-D示出根据本发明的导航状态(状态文件)的示意性表示；

图2E示出用于如图2D所示的状态文件的示意性映射表；

图2F示出根据本发明的修改后的状态文件；

图2G示出根据本发明的优选实施例的记录状态修改的增量代理方法。

具体实施方式

当今的Web应用变得越来越复杂，特别是在几个组件(门户小程序)被合并成更大的门户应用的门户环境中。这引起了这样的问题，即，“描述”Web应用的某个视图的导航状态变得相当冗长。例如，在门户环境中，必须集合所有与用户交互的portlet的导航状态。

本发明提供一种用于有效地处理导航状态的方法，与现有技术的方案相比，其具有如下的优点：

1)减小的标记大小

将导航状态编码到每个URL中会带来这样的风险，即，极大地增加了必须传送到客户机的标记的大小。本发明将避免这种情况。

2)减小的URL长度

不考虑标记大小，保持单个URL尽可能地短也是重要的。HTTP将URL的最大长度限制为2KB。如果超过这个限度，则接收这个长URL的代理服务器通常会将该URL缩短为2KB。本发明确保不会超过这个限度。

3)减少的URL生成时间

现有技术的导航状态处理包括提供许多URL的页面(每个页面几百个URL不是异常的)。因此，生成URL所需要的处理时间对整个服务器侧呈现时间有很大的影响，并进而影响门户的整体性能。本发明使处理时间保持尽可能地短，特别是将(复杂的)导航状态串行化到URL中所需要的时间，因为这对于满足在服务器侧处理时间方面的性能要求是至关重要的。

本发明描述如何通过使用如权利要求1所述的增量编码方法实现上述有关标记大小、URL长度和URL生成处理时间的优点。

本发明的基本思想-增量编码-是将URL必须编码的导航状态分为两个部分：所谓的基本导航状态(最新基本导航状态)描述用户当前在其客户机设备上看到的整个导航状态，所谓的增量导航状态表示URL的特定语义。换句话说，状态增量定义了在调用URL(例如通过点击它)时应当进行的状态转换。

注意，基本导航状态通常比增量导航状态更复杂，因为基本导航状态反映已经通过以前的交互逐渐积累的整个导航状态。而增量导航状态仅包含一小段信息，其表示各个URL的语义。

基本导航状态和URL专用的增量导航状态之间的区别可以在URL自身中被明确地反映。例如，URL生成实现可以选择将基本状态以及增量状态串行化到如下的URL的路径信息中(“基本”令牌指示被串行化的基本状态，“增量”令牌指示被串行化的增量状态)：http://www.myportal.com:80/portal/public/base/ajasdkjh6zuz7hjhsgiuzrak jssdfkjhsakjizutejhsdkhjjhgsdf/delta/hsdjhuh

当接收使用这样的URL的请求时，目标servlet将基本导航状态和增量导航状态合并，以获得整个导航状态或者被请求的视图(最新的新导航状态)。所产生的状态-称为新的最新导航状态-作为在该请求中生成的所有URL的新的请求专用的基本状态。为了避免串行化在呈现期间创建的每个URL的基本导航状态，基本导航状态可在动作阶段之后进行预串行化，因为在动作处理完成后，基本导航状态不能再被改变。

在呈现期间将URL写入标记取决于URL是否需要是绝对的、服务器相关的或相关的。

1)绝对URL

绝对URL是包含协议、主机名和端口的完整的URL。

2)服务器相关的URL

服务器相关的URL以servlet上下文路径开始。协议、主机名和端口信息被浏览器暗含。

3)相关URL

在相关URL的情况下，浏览器将URL附加到当前请求URL上或者HTML基本标签的值上(如果有的话)。

绝对URL和服务器相关的URL需要对基本状态和增量状态进行编码。为了创建这种URL，被预串行化的基本状态可以被原样地包括在该URL中，而URL专用的增量状态必须在将其附加到URL之前被串行化。

然而，在相关URL的常见情况下，在URL中包括被串行化的增量状态是足够的，而被预串行化的基本状态可以保存在HTML基本标签中(由于其是指作为页面的一部分的所有相关URL，因此必须每个页面只被写一次)。

下面描述的标记片段示出了相关URL的用法。当点击两个工具栏URL中的一个时，浏览器将相关URL(“delta/...”)附加到基本标签的值上。

<head>

</head>

<body>

…

<a href＝”delta/L2dJQvUasdsa！”class＝”toolbar_link”>Administration</a>

</td>

</td>

如在图2A所描述的屏幕快照中突出显示的，与所描述的视图对应的导航状态包括几个页面单元的状态，其中这些页面单元包括Portlet。通常，包含在所显示的标记中的每个URL对所有这些单元的导航状态进行编码。另外，每个URL对状态增量编码，该状态增量确定在用户点击该URL时门户应当做什么。

换句话说，页面的所有URL定义状态转换矩阵。转换的目标状态等同于可通过将增量状态和基本状态合并获得的状态。因此，根据用户所点击的URL，状态转换矩阵动态地进行扩展。

请求	所生成的URL		合并后的状态
	所生成的URL			基本状态	增量状态
	1	----		基本状态	增量状态	D₁D₂D₃D₄	B₁B₂B₃B₄
2	1	----	B₃B₃B₃B₃	D₁D₂D₃D₄	B₂₁B₂₂B₂₃B₂₄	D₁D₂D₃D₄	B₁B₂B₃B₄
2	3	B₂₄B₂₄B₂₄	B₃B₃B₃B₃	D₁D₂D₃D₄	B₂₁B₂₂B₂₃B₂₄	D₅D₆D₇	B₃₁B₃₂B₃₃
4	3	B₂₄B₂₄B₂₄	B₃₁B₃₁B₃₁	D₅D₆D₇	B₄₁B₄₂B₄₃	D₅D₆D₇	B₃₁B₃₂B₃₃

上表示出了简单的状态转换矩阵。第二列“所生成的URL”列出了在各个请求处理(第一列)的呈现阶段期间所生成的所有URL的基本状态-增量状态对。第三列列出了可能的结果状态，其在处理各个URL时形成新的基本状态。第一个请求表示转到门户的初始请求。通常，该初始请求由用户将门户URL输入浏览器的地址栏中触发。对该初始请求的响应传送该门户上的缺省视图。因此，所呈现的URL不包括基本导航状态(因为缺省导航状态可被该门户暗含)。假定用户点击接下来第三个URL(表中的第三行)，则新的基本导航状态B₃将与增量导航状态D₃对应(当没有要求合并时)。假定所点击的URL没有切换到不同的门户页面，则该门户可能再次呈现第四个URL。然而，这一次URL包含基本导航状态B₃，因为不考虑接着启动哪一个URL，该导航状态应当被保持。随后，用户可能点击该页面的第四个URL(表中的第八行)以引起新的基本状态B₂₄等等。

优选地，本发明在结合图2A描述的门户结构中实现。

图2A示出实现本发明的门户结构。

优选地，门户结构包括已经是每个现有技术的门户的一部分的功能组件，和为了提供创造性的功能而新增加的那些组件。

现有技术的作为每个门户的一部分的功能组件如下：

Servlet 10是前端控制器，其接收进入的HTTP请求。其通常通过初始化所包含的组件来使请求处理引擎20准备处理所接收的HTTP请求。然后，servlet 10委托请求处理引擎20处理该请求。

请求处理引擎20

请求处理引擎20也是前端控制器的一部分，其负责控制处理进入的请求。通常，它定义由几个请求处理阶段构成的请求处理生命周期。在门户中，请求必须经过四个阶段。首先，初始阶段执行请求专用的初始化任务，接着是动作阶段，其负责认证和动作执行(Portlet动作以及命令)。在动作阶段之后，通过调用集合过程来执行呈现阶段。通过执行请求专用的清理任务，终端阶段终止请求处理。

集合组件60

在请求处理生命周期的呈现阶段期间，调用集合组件60。其负责将所请求的页面的布局模型转换成表示树，并将与该表示树对应的标记写入响应。

认证组件50

认证组件50负责验证用户的身份。每个进入的请求都必须经过认证。门户2使用用户身份以确定用户被授权访问的内容和执行的命令。

Portlet容器30

Portlet容器30提供对Portlet的统一访问。特别地，它考虑了搜集某个Portlet的标记或执行Portlet动作。Portlet容器30通过Portlet API调用Portlet。

命令API 40

命令API 40(应用程序接口)向门户专用的命令提供抽象层。特别地，它考虑了通过统一的接口执行命令。命令可以用于执行管理任务，诸如创建和/或删除门户页面，向和/或从门户页面增加和/或除去Porlet，在已有的页面上设置Portlet，等等。

提供创造性的功能的新增加的功能组件如下：

导航状态管理组件70

导航状态管理组件70是在门户2中实现本发明的关键组件。该新组件的职责如下：

定义导航状态的生命周期，以及提供使请求处理引擎20能够将所定义的状态处理任务结合到整个请求处理生命周期中的接口；

定义对象模型以表示导航状态，以及提供考虑了读取和写入/修改导航状态的应用程序接口(API)；

提供考虑了有效地将导航状态的对象表示串行化到URL中、并且从(进入的)URL中反串行化导航状态以还原内部的对象表示的结构。该结构需要包括可被URL生成组件调用以创建带有导航状态的URL的接口。

URL生成API 80

如名字所暗示的，URL生成API 80提供考虑了对多个使用情况创建URL的API。它使得程序员能够将导航状态和所创建的URL相关联并将URL写入给定的目标流。这个写操作包含串行化已经与所创建的URL相关联的导航状态。除了通过程序创建URL，URL生成API通常提供一些URL标签以在JSP中创建URL。

注意，在缺省情况下，所创建的URL用请求专用的导航状态初始化，以确保以前的交互的导航状态不会丢失。为了确定URL的特定语义，该导航状态可以仅对该特定的URL改变。

图2B示出本发明的优选实施例-称为增量编码-在根据图2A的门户中的交互图。

增量编码方法可以通过定义导航状态的生命周期来实现。与特定客户机相关的导航状态的生存期是一个HTTP请求。图2B示出了组件交互图，其说明不同的步骤如何与上面的请求处理生命周期对准。

初始阶段

在初始阶段期间，导航状态必须从进入的请求URL中解码。状态解码被委托给导航状态管理组件70，并包括反串行化基本导航状态B和增量导航状态D，在反串行化后，将增量导航状态D和基本导航状态B合并以获得该请求的新的基本导航状态B′。在初始化完成后，表示新的最新基本导航状态B′的对象被传送到动作阶段用于进一步的处理。

动作阶段

在动作阶段期间执行商业逻辑。通过Portlet容器调用portlet动作，并通过命令API调用命令(注意，为了简化，这些步骤没有在图中描述)。在动作处理期间，基本状态B′可能被修改，假定B″是这些修改的结果。

由于在动作处理之后基本状态B″一定不能再改变，因此在开始呈现之前，基本状态B″被串行化。假定被串行化的基本状态B″是B″_ser。

呈现阶段

在呈现阶段一开始，更准确地，当写出应当被显示的页面的HTML报头时，被预串行化的基本导航状态B″_ser被包括在HTML<base(基本)>标签中，作为绝对URL的一部分。

随后执行的实际呈现包含多个URL的生成。在图2B中，该步骤已经被交给生成URL的组件。实际上，这些组件根据URL是否是Portlet标记的一部分，通过Portlet容器或者集合组件被间接地调用。对于通过URL生成API 80所创建的每个URL，执行如下步骤：在改变导航状态以指定特定URL的语义之前，创建所谓的增量代理。增量代理B″_i是封装导航状态对象B″的外壳，其记录应用于B″的状态修改。

随后，URL生成组件通过将所需要的变化(根据URL生成API的用法)应用于所获得的增量代理B″_i来创建各个URL的目标导航状态。

最后，所创建的URL被写入标记中。这包含串行化由增量代理B″_i记录的增量状态D_i，并在URL不能是相关的情况下，预先考虑被预串行化的基本状态B″_ser。

增量编码的关键步骤如下：在状态解码(初始阶段)期间执行的合并步骤确保在呈现期间创建的增量导航状态是最小的增量。这意味着被串行化的增量导航状态在长度方面保持最小，在状态解码期间的合并步骤和在动作阶段末尾的基本状态预串行化步骤确保URL可在呈现期间非常快地生成。如果是非相对URL，则已经被串行化的基本状态可以被原样地包括在URL中。在呈现阶段期间创建相对URL使URL保持地短，从而极大地减小了所呈现的页面的标记大小，因为URL仅需要包含最小增量状态，而相当长的被串行化的基本状态是包含在基本标签中的URL的一部分。

图2C-D示出根据本发明的导航状态(状态文件)的示意性表示。这一节处理对象模型中的导航状态的内部表示。选择合适的对象表示对于协调在前面几节中描述的增量编码方法的单个步骤是至关重要的。所推荐的设计方案是基于典型的门户页面包含许多URL的假定，即，导航状态的对象表示必须根据URL编码优化。将该假定应用于上述增量编码方法意味着对象表示必须考虑有效地记录和串行化增量状态以及串行化基本状态。因此，推荐使用分级文件模型模拟导航状态，该模型包含表示为字符(或Java中的字符串)的无类型状态信息。基于字符的存储器表示允许将导航状态有效地串行化到URL中，因为它避免在串行化过程期间进行对象-字符串转换所消耗的时间和CPU。

图2C示出示意性的简化的状态文件模型。注意，所描述的状态文件是简化后的。该文件包含正好两个Portlet的导航状态，以及页面选择信息和主题信息。在实际的商业情形下，门户页面通常集合多个导航控件、工具栏和portlet(达到平均20个portlet)，这可能使状态文件更加复杂。

一种普通的面向对象的设计模式是从读写接口(控制器)中分离只读接口。因此，所使用的对象模型应当向状态文件提供两个接口。

DocumentModel接口提供对提供如下方法的状态文件的读访问(UML表示)：

getRoot()：Node-返回状态文件的根节点；getChildren(parent：Node)：List-返回表示给定父节点的子节点的节点列表；getParent(node：node)：Node-返回表示给定节点的父节点的节点。如果给定节点与文件根节点对应，则该方法返回空(null)。

其它方法有诸如hasChildren、hasAttributes和getAttributes。

DocumentController接口提供读写访问，即，另外考虑了修改分级状态文件。

DocumentController接口提供如下的方法：

insert(new：Node；next：Node；parent：Node)：Node-在指定的位置将给定节点newNode插入状态文件；

remove(node：Node)：Node-从状态文件中除去给定节点；

create(namespace：String；name：String)：Node-用给定的名称和名称空间创建新的节点并返回所创建的节点对象。随后，所创建的节点可以使用insert方法插入状态分级结构中。

其它方法如setValue、addAttribute、setAttributes、removeAttribute和clearAttributes。

所使用的接口Node模拟文件模型分级结构中的单个节点。该节点不知道自己在分级结构中的位置或属性，但只知道内容。

Node接口提供下面的方法：

getNodeName()：String-返回节点的限定名称。

getNodeValue()：String-返回节点的值。

getNamespaceURI：String-返回节点的名称空间URI。

该接口可以应用于如图2C所示的示例性状态。

串行化基本状态

当串行化基本导航状态时，整个状态文件必须被串行化以在呈现期间被包括在URL或HTML基本标签中。所需要的串行化机制必须串行化最小的信息(所谓的“熵”)，其是在接收URL时还原(反串行化)整个状态文件所需要的。这包括文件结构，即，父子关系和文件内容数据，即，节点名称、值和属性。

为了使URL保持短，该信息必须被尽可能压缩地编码。文件结构的压缩编码可以通过使用简单的位编码实现，该简单的位编码使用给定的遍历算法(例如深度优先遍历)写出每个单元的级别(相对于根的深度)。

然而，文件内容数据不能被容易地串行化。仅遍历状态文件和写出构成节点的全部信息会导致非常长的串行化表单。

优选实施例是将节点名称、属性名称和预定义的值映射到短字符表示。为此，状态文件的结构必须在文件类型定义(DTD)或XML模式(XSD)中准确地指定。根据该规范，可以得到映射表，其可用于状态串行化和状态反串行化。图2D中所描述的文件类型定义示出了状态文件的示例性结构。图2D中所描述的树示出了这种结构。

创建所需要的映射表的优选实施例是解析DTD，并将找到的每个单元名称、属性和值映射到短字符表示。然而，也可以使用DTD的分级结构，并建立对应的分级映射树。将诸如UTF 8的字符组作为短字符表示的基础，可以定义非常复杂的状态结构，而无需使用比一个字符长的字符表示(因为该映射需要在特定单元的一组子女中是唯一的)。

在图2E中示出了与上面的状态结构对应的映射树的例子(通过缩进模拟分级结构)。

记录增量状态并对其串行化

假定页面上的Portlet，其想要提供URL，该URL将该Portlet设置成Portlet模式“Configure”以使用户能够切换到考虑了配置该Portlet的视图。为了创建这个URL，该Portlet使用URL生成API以请求Portlet模式改变URL。该URL生成API实现在内部使用DocumentController接口执行模式改变。实际上，该Portlet使用Portlet API以生成URL。然而，在下面该门户将该请求委托给该门户的中央URL生成API。

令该portlet的标识符为“5”。假定主要的基本状态是这样的：其对应于图2C所示的文件，结果导航状态(基本+增量)类似如图2F所示的状态文件。portlet模式改变导致添加了突出显示红色的节点和边缘。

根据增量编码方法，所生成的URL应仅仅反映该改变(该改变当然不应修改已经在请求处理时被预串行化的基本状态)。

优选实施例是得到URL生成实现，以相信它真正修改了它在上面运行的状态文件。然而，在下面，各个修改操作被截取并特别处理。这可以通过使用代理模式，即，通过创建封装真实状态文件的“代理”文件容易地实现。

图2G示出了代理方法。对每个应被创建的URL创建增量代理。该增量代理也露出DocumentModel(DM)和DocumentController(DC)接口。然而，该代理实现仅将DocumentModel(读取)调用委托给表示基本状态的基本状态文件。通过DocumentController接口进行的修改操作被截取并记录在内部修改历史中。

图2G会导致以下的修改历史：

●创建节点“portlet”

●将具有值“5”的属性“id”添加到所创建的节点

●插入节点“portlet”，作为节点“state”的最后一个子节点

●创建节点“portlet-mode”

●设置值“configure”

●插入节点“portlet-mode”，作为所创建的节点“portlet”的最后一个子节点

当将增量状态编码到URL中时，串行化所记录的修改操作序列就足够了。为了获得压缩串行化的表单，可以使用如下的策略：

1.将修改操作映射到短标识符。这可通过对修改操作进行编号容易地进行：

DocumentController	ID
DocumentController	ID	Insert	0
Create	1	Insert	0
Create	1	Remove	2
SetValue	3	Remove	2
SetValue	3	AddAttribute	4
ClearAttributes	5	AddAttribute	4
ClearAttributes	5	SetAttributes	6
removeAttribute	7	SetAttributes	6

2.将所包含的操作变元(节点)映射到短标识符。

在增量所指的基本状态文件中已经存在的节点可以容易地通过整数引用，该整数例如与在使用某个遍历算法(例如深度优先遍历)遍历基本文件时的访问位置对应。新的节点可以使用新的未分配的整数引用。由于DocumentController接口也接受空值，因此必须引入特定整数(例如“0”)来表示空。

3.重复使用基本状态串行化的映射树以将固定标记(即，节点名称、属性名称、预定义的节点值、预定义的属性值)映射到短字符表示。

使用这些策略，被串行化的增量状态可具有形式

<操作>/<节点>/<标记>。

在开始时，编码的操作暗含属于这些操作的节点号。例如，如果操作序列以“0”开始(对应于insert)，则头三个变元必须属于它，因为DocumentController的insert方法需要三个变元。同样的策略可以应用于标记-如果是被编码的create方法，则增量解码可意味着有两个指定应被创建的节点(限定名称和名称空间)的标记。

如下所示的表列出对于每个操作需要多少个变元和标记：

DocumentController操作	ID	需要的数量	需要的数量
DocumentController操作	ID	需要的数量	需要的数量	Insert	0	3	0
Create	1	1(新ID！)	2	Insert	0	3	0
Create	1	1(新ID！)	2	Remove	2	1	0
SetValue	3	1	1	Remove	2	1	0
SetValue	3	1	1	AddAttribute	4	1	2
ClearAttributes	5	1	0	AddAttribute	4	1	2
ClearAttributes	5	1	0	SetAttributes	6	1	取决于属性的数量
removeAttribute	7	1	1	SetAttributes	6	1	取决于属性的数量

假定采用上面列出的映射表并将其应用于上述修改历史，则增量状态被编码如下：

140130/11，11，11，0，1，12，12，12，0，1/ZAA5ZBC使用例如GZIP压缩被串行化的数据将进一步地缩短被串行化的表单。

附图包括说明根据本发明的实施例的方法、装置和计算机程序产品的方框图。可以理解，附图中的每个方框以及这些方框的组合可以通过计算机程序指令实现。这些计算机程序指令可以被装载到计算机或者其它可编程数据处理装置上以产生一种设备，使得在计算机或者其它可编程数据处理装置上执行的指令创建用于实现在方框中指定的功能的装置。这些计算机程序指令也可以存储在计算机可读存储器中，其可以引导计算机或其它可编程数据处理装置以特定的方式运行，使得存储在计算机可读存储器上的指令产生一种包括实现在方框中指定的功能的指令装置的产品。计算机程序指令也可以装载到计算机或者其它可编程数据处理装置上，以使一系列操作步骤在计算机或者其它可编程数据处理装置上执行，从而产生计算机实现的过程，使得在计算机或者其它可编程数据处理装置上执行的指令提供用于实现在方框中指定的功能的步骤。

本领域的技术人员应当容易地知道，定义本发明的功能的程序可以采用多种形式传递到计算机；包括但不限于：(a)永久存储在不可写存储介质(例如计算机内的只读存储器，诸如ROM或可由计算机I/O附属设备读取的CD-ROM)上的信息；(b)可改变地存储在可写存储介质(例如软盘和硬盘驱动器)上的信息；或者(c)通过例如使用无线、宽带信令或广播信令技术的通信介质传送到计算机的信息，上述技术包括诸如通过计算机或者经由调制解调器的电话网络的载波信令技术。

尽管通过上述示例性的实施例描述了本发明，但是本领域的普通技术人员可以理解，在不脱离在此所公开的发明概念的情况下，可以对示例性的实施例进行修改和变化。另外，尽管连同多种示意性的程序命令结构描述了优选实施例，但是本领域的技术人员将认识到可以使用各种特定的命令结构实现。

Claims

1.一种用于在门户中有效地对导航状态编码的方法，其中，所述门户在服务器系统中运行；其中所述服务器系统包括通信组件，其允许通过通信信道在所述门户和客户机的浏览器之间进行通信；其中所述门户确定所请求的门户页面的布局，调用属于所述门户页面的各个页面单元的呈现，并将所述门户页面传输到所述客户机的浏览器以显示，其中所述门户页面的至少一个页面单元提供用于由所述门户初始化呈现新页面或者新页面单元的URL功能，其中每个用户交互通过在所述页面单元点击所述URL而在所述门户侧生成新的导航状态，其中最新导航状态描述作为特定客户机的所有以前的导航交互的结果的所述门户的当前视图，其中所述至少最新导航状态由所述门户保存，其中响应于请求新的门户页面的客户机请求，所述方法的特征在于以下步骤：

创建基本导航状态，其描述在所述新的门户页面的所有URL中相同的所述最新导航状态的那部分；

对包括在所述新的门户页面中以呈现并且不包含在所述基本导航状态中的每个URL，创建URL特定的增量导航状态，其描述在所述特定URL被调用时所述特定URL的状态转换；

将所述基本导航状态编码到所述门户页面的报头中一次；

将每个URL特定的增量导航状态编码到其所分配的作为所述门户页面的一部分的URL中；以及

生成并向所述客户机的浏览器传输响应，其包括用于由所述客户机的浏览器显示的所述新的门户页面。

2.根据权利要求1所述的方法，其中，所述基本导航状态和所述增量导航状态在所述门户页面中被编码到串行化表单中。

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

接收请求新的门户页面的客户机请求，其包括所述基本导航状态和所述增量导航状态；

反串行化所述基本导航状态和所述增量导航状态；

将所述增量导航状态和所述基本导航状态合并，产生新的最新基本导航状态；

在分级树型对象表示中显示所述新的最新基本导航状态用于串行化；

在开始呈现所述门户页面之前，预串行化所述新的最新基本导航状态；以及

将所述被预串行化的新的最新基本导航状态包括在所述门户页面的HTML基本标签中。

4.根据权利要求2所述的方法，其中，所述每个URL特定的增量导航状态的编码是基于在增量代理对象上运行的串行化方法，所述增量代理对象记录对表示所述新的最新基本导航状态的基本分级树型对象表示的修改。

5.根据权利要求4所述的方法，其中，所述分级树型对象表示包含由名称、值和属性描述的节点，所述名称、值和属性都由基于字符的字符串表示。

6.根据权利要求5所述的方法，其中，所述结构和/或所述分级树型对象表示的所述结构中的节点通过只读编程接口读取，并通过读写编程接口修改。

7.根据权利要求2所述的方法，其中，所述URL特定的增量导航状态的串行化方法在呈现将被提交到所述客户机的浏览器的所述门户页面期间执行。

8.根据权利要求2所述的方法，其中，所述串行化结果还通过一个或多个标准压缩算法进行压缩。

9.根据权利要求8所述的方法，其中，所述压缩算法是Gzip、Zip、RLE。

10.根据权利要求9所述的方法，其中，表示所述增量导航状态的所述被压缩的串行化结果被编码到所述URL的路径信息中。

11.一种用于在门户中有效地对导航状态编码的系统，其中所述门户在所述系统中运行，其中所述系统包括通信组件，其允许通过通信信道在所述门户和客户机的浏览器之间进行通信，其中所述门户确定所请求的门户页面的布局，调用属于所述门户页面的各个页面单元的呈现，并将所述门户页面传输到所述客户机的浏览器以显示，其中所述门户页面的至少一个页面单元提供用于由所述门户初始化呈现新的页面或者新的页面单元的URL功能，其中每个用户交互通过在所述页面单元点击所述URL而在所述门户侧生成新的导航状态，其中最新导航状态描述作为特定客户机的所有以前的导航交互的结果的所述门户的当前视图，其中所述至少最新导航状态由所述门户保存，其中，所述系统的特征在于以下的组件：

用于创建基本导航状态的组件，所述基本导航状态描述在所述新的门户页面的所有URL中相同的所述最新导航状态的那部分；

用于对包括在所述新的门户页面中以呈现并且不包含在所述基本导航状态中的每个URL创建URL特定的增量导航状态的组件，所述URL特定的增量导航状态描述在所述特定URL被调用时所述特定URL的状态转换；

用于将所述基本导航状态编码到所述门户页面的报头中一次的组件；

用于将每个URL特定的增量导航状态编码到其所分配的作为所述门户页面的一部分的URL中的组件；以及

用于生成并向所述客户机的浏览器传输响应的组件，所述响应包括用于由所述客户机的浏览器显示的所述新的门户页面。

12.根据权利要求11所述的系统，其中，所述组件是所述门户的一部分。