CN102065133B - 支持Portlet协作构建复杂业务逻辑的方法和系统 - Google Patents

Abstract

本发明公开了一种支持Portlet协作构建复杂业务逻辑的方法和系统，其方法包括：1)用户触发页面上的任意Portlet，Portlet处理；2)被触发的Portlet触发事件X或设置公共呈现参数；3)将X包装为消息MX，验证消息或公共呈现参数；4)将消息或公共呈现参数带回Portlet容器；5)确定接收Portlet；6)确定被触发Portlet与接收Portlet不是相同类型，进行事件转换或对公共呈现参数进行转换后发送到接收Portlet进行处理；7)处理完成后，完成页面聚合，返回给用户。本发明消除了Portlet协作中对规范的依赖。解决了联邦门户系统中本地和远程Portlet协作的问题。

Description

支持Portlet协作构建复杂业务逻辑的方法和系统

技术领域

本发明涉及一种在联邦门户环境下，支持Portlet协作构建复杂业务逻辑的方法和系统，属于计算机技术领域。

背景技术

门户(Portal)是基于组件的web应用，它可以集成Internet环境下各种现有应用系统、数据资源和网络信息资源，并为用户形成个性化的访问页面，实现信息的集成和发布(WEGE C.Portal server technology[J].IEEE Internet Computing 6(2002)：73-77.)。Portlet是门户中的可重用组件，能够提供对web内容、应用程序和其他资源的访问。JSR168规范(Portlet 1.0，JSR168：Portlet Specification1.0[S].Java Community Process，2003.)提供了Portlet的标准。

随着门户的广泛使用，仅仅本地的门户应用已经不能满足企业需求，便出现了联邦门户(Federated Portals)，联邦门户是包括远程分布资源的门户。为符合WSRP(Web Servicesfor Remote Portlets)而构建的Portlet提供了此远程功能。这些远程资源来自称为WSRP生产者的一个或多个门户服务器，在运行时被收集和组合在被称为WSRP消费者的门户应用程序中，因此，WSRP是联邦门户的基础技术，WSRP1.0规范(WSRP v1.0：Web Services for RemotePortlets Specification v1.0[S].Organization for the Advancement of StructuredInformation Standards，2003.)提供了联邦门户的标准。

但是，仅将应用进行简单集成和远程化，不能为远程Portlet之间建立联系，形成互操作环境，因此还是不能满足企业用户的需求。远程Portlet之间也必须具备交互能力，支持通过协作来组建一些复杂的业务功能。

Portlet协作，在JSR168规范和WSRP1.0规范中并没有定义，而是作为规范保留特征待下一版本中完成。JSR286规范(Portlet 2.0，JSR286：Portlet Specification2.0[S].JavaCommunity Process，2008.)和WSRP2.0规范(WSRP v2.0：Web Services for Remote PortletsSpecification v2.0[S].Organization for the Advancement of Structured InformationStandards，2008.)分别给出了Portlet的协作方法，遗憾的是，JSR286规范是针对本地Portlet的，WSRP2.0规范是针对远程Portlet的。因此，已有的规范都不能解决远程Portlet协作和本地Portlet协作的问题。

JSR286规范由JCP组织提出，它兼容了JSR168规范并进行了扩展，规范定义了Portlet2.0的实现标准。它在Portlet 1.0的基础上提供了资源服务、协作、Portlet窗口、Portlet过滤器、Portlet URL侦听器等新特性。JSR286规范指出Portlet可以采取多种方式来实现本地Portlet之间的协作：

1)采用基于事件的发布订阅方式；

2)Portlet通过公共呈现参数中的数据来实现协作。

其中，因为公共呈现参数是字符串类型，不支持协作过程中对复杂数据类型传递，所以第二种协作方式具备一定的局限性，需要依靠特定的方式完成特定应用场景中的协作。而基于事件的协作方式(PAUL C，FELIX B，LEN B.Documenting Software Architectures：Viewsand Beyond[M].Boston：Addison Wesley，2002.)可以完成跨应用的协作，支持丰富的协作内容表示，功能更完整适用更广泛，是Portlet协作的主要方式。

基于事件的发布/订阅是一种松耦合的组件交互方式(Radestock M，Eisenbach S.Component Coordination in Middleware Systems[C]//International Conference onDistributed Systems Platforms and Open Distributed Processing(Middleware’98).Berlin：Springer，1998.)。在JSR286规范描述的Portlet组件模型中规范化定义了基于事件的协作模式，使得Portlet的协作可以在支持JSR286规范的门户系统之间移植。参与协作过程的Portlet并不需知道发布的事件将会被哪些Portlet接受处理，接受事件的Portlet也不必知道是谁发布了事件。因此该方式为Portlet实现一对多的Portlet交互。

在大多数的门户产品中，Portlet的协作由Portlet容器完成，Portlet容器用来容纳各种Portlet，并在Portlet的生命周期中，对它们进行管理。它与Portal服务器一起提供了Portlet的运行环境。

JSR286规范事件机制的流程如图1所示，Portlet页面上包含多个Portlet，分别标识为A、B、C、…。用户触发任意Portlet，假设为Portlet B上的action操作，请求由Portlet容器转发给Portlet B处理。在处理过程中Portlet B触发了事件X，X由响应对象ActionResponse带回Portlet容器。Portlet容器调用Portal服务得知Portlet A能处理该事件，将事件X发送到Portlet A处理。事件处理完成后Portlet容器依次调用页面上的所有Portlet的render过程完成页面聚合，将生成的页面片段返回给用户。在此过程中PortletC生成的页面没有被修改。

WSRP2.0规范定义了远程Portlet之间的协作。WSRP2.0规范由OASIS组织提出，它对WSRP1.0规范进行了扩展，但不兼容WSRP1.0规范。它定义了符合JSR286规范的联邦门户的实现标准。它在WSRP1.0规范的基础上提供了资源服务、协作、远程Portlet租借、远程Portlet的导入导出等新特性。WSRP2.0规范指出远程Portlet可以采用两种方式来实现远程Portlet之间的协作：

1)事件分发：这种机制使得Portlet可以产生和消费携带语义信息的事件，包括名字、数据和负荷。消费者有控制事件分发的策略。

2)状态分发：这种机制使得Portlet可以暴露相关的状态，消费者可以处理和转发状态，从而可以影响其它的Portlet。

WSRP2.0规范提供的协作机制和JSR286规范的相似，但在具体的定义上有所不同，WSRP2.0规范的协作由消费者门户负责。生产者门户不负责协作，只接收消费者门户的Web Service请求并返回响应。此外，WSRP2.0规范对事件和状态的定义和JSR286规范中的也不一样。

在大多数的门户产品中，远程Portlet的协作由消费者门户的代理容器完成，代理容器用来容纳各种远程Portlet，并对远程Portlet的生命周期进行管理。它与Portal服务器一起提供了Portlet的运行环境。当一个Portlet请求到达时，Portal服务器根据Portlet的不同类型，来调用不同的Portlet容器进行处理。这就是联邦门户系统中的多容器结构。详见图2。由于WSRP2.0规范并不兼容WSRP1.0规范，所以要同时提供支持WSRP1.0规范和WSRP2.0规范的消费者端代理容器。

WSRP2.0规范事件机制的流程如图3所示，消费者门户页面上包含三个远程Portlet A、B、C。用户触发远程Portlet B上的action操作，请求由代理容器转发给远程Portlet B处理。在处理过程中远程Portlet B触发了事件X，X由响应对象BlockingInteractionResponse带回代理容器。代理容器调用生产者Web服务得知远程Portlet A能处理该事件，将事件X发送到远程Portlet A处理。事件处理完成后代理容器依次调用消费者门户页面上的所有远程Portlet的getMarkup过程完成页面聚合，将生成的页面片段返回给用户。在此过程中远程Portlet C生成的页面没有被修改。

虽然上述过程解耦了协作中的发布者和接收者，但该方式中存在Portlet协作对规范的依赖。以基于事件的协作为例，对于本地JSR286Portlet，在运行时，Portlet容器将根据部署描述符查找可以处理该事件的Portlet，并调用该Portlet事件处理函数执行协作业务逻辑。而对于远程的WSRP2.0Portlet，在运行时，代理容器首先通过getServiceDescription()方法或者getPortletDescription()方法获取远程Portlet的相关信息，然后根据返回的结果判断该远程Portlet所支持发布的事件和接受处理的事件。并根据具体的Portlet事件执行协作业务逻辑。可见在Portlet的运行阶段就存在对规范的依赖。若没有提供特别的支持，远程Portlet和本地Portlet不能协作。

综上，在构建门户时，开发人员通常会重用一些已有的Portlet来实现门户功能需求。这些Portlet可能来自不同的组件提供商、由不同厂商在不同时期开发完成，它们通过WSRP生产者被发布。开发人员在开发Portlet时，如果能利用远程Portlet的协作信息，再为之开发相应的本地协作Portlet，就可以极大地节省工作量。但是，由于协作需要的事件和公共呈现参数在规范各自的定义中不同，而且在这两个规范中，协作信息并不共享，因此，远程Portlet协作和本地Portlet协作方法，在目前已有的JSR286规范和WSRP2.0规范定义都无法找到定义。

如何使远程Portlet协作和本地Portlet协作，达到构建复杂业务逻辑的方法，便是本发明的关注点。

发明内容

本发明的目的在于克服现有技术中存在的问题，提供一种支持远程Portlet协作构建复杂业务逻辑的方法，该方法在联邦门户环境下，使远程Portlet和本地Portlet进行协作应用，解决了协作信息的转换和共享问题。在本发明的方法中，通过协作信息转换和协作服务作为中介，通过消息队列进行消息存储、消息验证和消息处理，实现了Portlet容器和代理容器的松散耦合，并支持远程Portlet和远程Portlet之间、远程Portlet和本地Portlet之间、本地Portlet和本地Portlet之间的协作。该方法使JSR286规范和WSRP2.0规范兼容，满足WSRP2.0模块的可插拔性，并具有良好的可扩展性和可移植性。

本发明的技术方案为：一种支持Portlet协作构建复杂业务逻辑的方法。复杂业务逻辑是指配置多个Portlet(本地Portlet或者远程Portlet)之间的协作。本发明包括如下步骤：

1)用户触发消费者页面上的任意Portlet操作，被触发的Portlet处理该操作；

2)被触发的Portlet在处理过程中触发事件X或设置公共呈现参数；

3)将X包装为消息MX，对消息或公共呈现参数进行验证；包装为消息后方便对事件进行统一管理和处理；

4)将验证后的消息或公共呈现参数由响应对象带回Portlet容器；

5)Portlet容器确定可以处理事件X或公共呈现参数的接收Portlet；

6)当被触发Portlet与接收Portlet是不同类型的Portlet，对消息MX进行事件转换或对公共呈现参数进行转换，将转换后的消息MX或公共呈现参数发送到接收Portlet进行处理；

7)处理完成后，Portlet容器依次调用门户页面上的所有Portlet的render或GetMarkup过程完成页面聚合，将生成的页面片段返回给用户。

所述的Portlet类型为本地Portlet和远程Portlet。不同类型的portlet，即一个是本地Portlet，另一个是远程Portlet。

所述Portlet容器包括本地Portlet容器和代理容器，本地Portlet容器处理本地Portlet协作，而代理容器处理远程Portlet协作。

无论是在JSR286还是在WSRP2.0，Portlet协作过程中，以事件处理为例，都要分为三个步骤：事件的发布、事件的验证和事件的处理。三个步骤是一个有序的过程，但两个规范定义不一样。在JSR 286中，事件的发布由本地Portlet产生，发布的事件要通过本地Portlet容器的验证，然后才能被订阅该事件的本地Portlet处理。在WSRP2.0中，事件的发布由远程Portlet产生，发布的事件要通过代理容器的验证，然后请求WSRP生产者的Web服务，才能够被订阅该事件的远程Portlet处理。

如果以公共呈现参数处理为例，则都要分为两个步骤，在JSR286和WSRP2.0 Portlet协作过程中，公共呈现参数的处理比较简单，首先执行验证，然后将其设置到Portlet所对应的Request/Response中。这个过程只需要公共呈现参数的验证即可。

远程Portlet和本地Portlet类型不同，在构建复杂业务逻辑过程中，如果事件X的生产者即被触发的Portlet与接收Portlet不是同一类型，即一个是本地Portlet，另一个是远程Portlet，就需要解决JSR286规范和WSRP2.0规范所定义的协作信息相互转换的(GREGORH，BOBBY W，Enterprise Integration Patterns：Designing，Building，and DeployingMessaging[M].Boston：Addison Wesley，2003.)问题。经过事件转换或公共呈现参数转换即可达到远程Portlet和本地Portlet协作的目的。

所述事件转换是指事件内容的转换。

所述事件内容的转换是指Java对象和XML字符串之间的转换。

在JSR286规范中，事件需要在Portlet部署描述符文件中声明，创建一个Portlet事件对象需要实现javax.portlet.Event接口。它包含了两类信息：

QName：事件的标识符

Serializable：事件封装的Java对象

而在WSRP2.0规范中，生产者门户发布一个Portlet时，需要提供Portlet所支持的事件描述。事件对象由Event数据类型所定义，它包括如下信息：

QName name：事件的标识符(必需)

QName type：事件封装的对象类型(可选)

EventPayload payload：事件封装的对象(可选)

Extension[] extensions：事件的扩展内容(可选)

由此可见，事件对象包括两个要素：事件的标识符和事件的内容。事件的标识符在两种规范中都是QName数据类型，值也一样，无须转换。而事件的内容在两个规范中是不一样的，在JSR286规范中，内容是可序列化的Java对象，而在WSRP2.0规范中，事件的内容是可通过Web Service传输的对象。由于Web Service一般使用XML传输信息，因此JSR286规范和WSRP2.0规范之间的事件内容的转换可归结为是Java对象和XML字符串的转换。JSR286规范推荐使用JAXB 2.0进行事件内容的XML封送和解封送。可以将其应用到WSRP2.0规范的事件对象中。

所述公共呈现参数转换是指，为了让远程Portlet和本地Portlet能够在设置和获取参数时保持一致，需要按照各自的规范获取和设置公共呈现参数。

在JSR286规范中，公共呈现参数需要在Portlet部署描述符中声明，通过Portet请求和Portlet响应可以获取和设置公共呈现参数。

而WSRP2.0规范的公共呈现参数在NavigationalContext数据类型中定义：

String opaqueValue：导航状态(可选)

NamedString publicValues[]：公共呈现参数数组(可选)

Extension extensions[]：扩展内容(可选)

由此，在WSRP2.0规范中，公共呈现参数信息包括参数的名-值对。

通过比较可以看出，两个规范中提供了不同的获取和设置公共呈现参数的方法。如果远程Portlet要设置本地Portlet的公共呈现参数的时候，它遵循的是WSRP对公共呈现参数的设置方法，但是正确的做法需要按照JSR286的规范设置公共呈现参数，因此，公共呈现参数转换的作用就类似适配器，实现这种设置方法的转换。同理，如果本地Portlet要设置远程Portlet的公共呈现参数的时候，也需要公共呈现参数转换来充当适配器。

根据上述对比设计转换，可以达成JSR286规范和WSRP2.0规范之间数据类型的转换。

本发明的另一目的是提供一种支持Portlet协作构建复杂业务逻辑的系统，包括本地Portlet容器、代理容器、协作服务、协作信息转换器、消息验证器、消息处理器和公共呈现参数验证器，本地Portlet容器和代理容器连接协作服务并调用协作服务；协作服务连接并调用协作信息转换器、消息验证器、消息处理器和公共呈现参数验证器，其中，

PortletContainer：本地Portlet容器。

ProxyContainer：代理容器，用于运行远程Portlet。

CoordinationinfoUtil：协作信息转换器，进行事件和公共呈现参数的转换。

Message：消息，实现了对协作事件的封装。

MessageBus：消息队列，提供了添加和处理消息的功能。

MessageVerifier：消息验证器，对消息进行验证。

MessageProcessor：消息处理器，确定处理消息的Portlet。

PRPVerifier：公共呈现参数验证器，验证公共呈现参数。

CoordinationService：协作服务，包装事件X为消息，连接并调用消息验证器、消息处理器和公共呈现参数验证器。

本地Portlet容器或代理容器相互独立，并不共享资源。因此，需要将两种容器的协作处理接口开放，使用一个通用的协作服务CoordinationService来完成。这就是服务注册机制。

协作服务随着应用服务器的启动而启动；而对于每一种Portlet容器而言，都能实现消息验证、消息处理、以及公共呈现参数验证，并在Portlet容器启动的时候将消息验证器、消息处理器和公共呈现参数验证器注册到协作服务中，在Portlet容器销毁的时候从协作服务中注销。

本地Portlet容器或代理容器上设置有消息验证器接口、消息处理器接口及公共呈现参数验证器接口。

这样，当一个协作Portlet发布事件时，协作服务会调用相应的事件验证器进行验证，并调用所有的事件处理器进行处理；当一个协作Portlet设置公共呈现参数时，协作服务会调用对应的公共呈现参数验证器进行验证。它们的关系如图4所示。

系统采用的协作方式是对JSR286 Portlet协作和WSRP2.0 Portlet协作的扩展，门户系统为支持协作功能需要对Portlet容器和代理容器进行修改，增加协作信息转换、资源共享等功能。协作信息转换发生在Portlet协作过程中且相对独立，在容器中也仅与协作服务有交互。

本发明具有如下意义：

随着联邦门户系统的出现，要求门户能提供一个通用的Portlet协作框架，但JSR286和WSRP2.0的协作都存在对规范的依赖，使得门户开发人员在门户构建中不能有效使用可协作的远程Portlet构建业务页面。本文的支持Portlet协作构建复杂业务逻辑的方法和系统通过引入了事件转换和公共呈现参数转换，消除依赖关系。文中给出了协作信息转换和服务注册的原理，同时对联邦门户系统中的Portlet容器和代理容器进行扩展以支持远程Portlet和本地Portlet的协作。该方法已很好的解决了联邦门户系统中协作的问题。

附图说明

图1是现有技术中本地Portlet事件协作序列流程图。

图2是现有技术中消费者门户系统中的多容器结构。

图3是现有技术中远程Portlet事件协作序列图。

图4是本发明的系统的结构示意图。

图5是本发明的Portlet事件协作序列图。

图6是实施例中生成的联邦门户的协作示例页面。

具体实施方式

以下结合具体实施例和附图对本发明进行详细说明。

基于事件转换机制协作流程如图5所示，消费者门户页面上包含三个Portlet A、B、C，这三个Portlet可能是本地的，也可能是远程的，

1)当用户触发Portlet B上的action操作时，请求由Portlet容器转发给Portlet B处理。这个Portlet容器可以是本地Portlet容器，也可以是处理远程Portlet的代理容器。

2)在处理过程中Portlet B触发了事件X，

3)X需要通过协作服务包装为消息MX，并调用相应的消息验证器进行验证。通过Portlet容器上的消息验证器接口调用消息验证器。

4)验证通过后X由响应对象ActionResponse/BlockingInteractionResponse带回Portlet容器。

5)Portlet容器调用协作服务，通过协作服务调用消息处理器得知Portlet A能处理事件X；

6)当Portlet B和Portlet A不是相同类型Portlet，即其中一个为本地Portlet，另一个为远程Portlet，协作信息转换器对消息MX进行事件转换，即进行事件内容的转换，将Java对象和XML字符串进行转换，符合Portlet A对事件处理的要求。转换后将事件X发送到Portlet A处理；

7)事件处理完成后Portlet容器依次调用门户页面上的所有Portlet的render/GetMarkup过程完成页面聚合，将生成的页面片段返回给用户。在此过程中Portlet C生成的页面没有被修改。

Portlet容器包括本地Portlet容器和代理容器，无论是Portlet容器还是代理容器都具有消息验证器接口、消息处理器接口以及公共呈现参数验证器接口。

本发明的支持Portlet协作构建复杂业务逻辑的系统，包括本地Portlet容器、代理容器、协作服务、协作信息转换器、消息验证器、消息处理器、公共呈现参数验证器和消息队列。，本地Portlet容器和代理容器连接协作服务并调用协作服务；协作服务连接并调用协作信息转换器、消息验证器、消息处理器和公共呈现参数验证器。协作信息转换器能够完成事件对象和公共呈现参数对象在不同规范之间的转换。消息验证器对消息进行验证。消息处理器确定能处理事件的Portlet。公共呈现参数验证器验证公共呈现参数。协作服务，包装事件X为消息，连接并调用消息验证器、消息处理器和公共呈现参数验证器。消息队列，能添加和处理消息。

消息验证器、消息处理器和公共呈现参数验证器在Portlet容器启动时注册到协作服务，在Portlet容器销毁时从协作服务注销。

上述过程以事件协作为例描述了本发明的方法和系统，而公共呈现参数协作与事件协作原理是相同的，本领域技术人员可以根据本发明的方法和系统实现基于公共呈现参数的远程和本地Portlet协作。

下面以门户中一个Portlet协作页面的构建为例说明本发明的方法。这里，协作页面可以视为复杂业务逻辑。协作方式选择基于事件的协作，因为这是常用的协作方式。如果是公共呈现参数，原理相同。

在联邦门户系统中，需要一个协作页面提供世界地图信息(ContinentPortlet)、各大陆的地图信息(ContinentMapPortlet)和各大陆的文字信息(ContinentInfoPortlet)。当用户用鼠标点击世界地图信息时，各大陆的地图信息和各大陆的文字信息会自动更新。其中ContinentPortlet为远程Portlet，ContinentPortlet接受用户的鼠标点击并进行处理，产生事件DetailEvent，ContinentPortlet的代理容器对DetailEvent进行验证后，由响应对象将事件DetailEvent带回代理容器；代理容器确定可以处理事件的是ContinentInfoPortlet，ContinentInfoPortlet为本地Portlet，则需要对事件进行转换，将Java对象转换为XML字符串。事件转换后，ContinentInfoPortlet处理该事件。事件处理完后，Portlet容器依次调用门户页面上的所有Portlet的render或GetMarkup过程完成页面聚合，将生成的页面片段返回给用户。这个过程中ContinentMapPortlet生成的页面未被修改。在协作页面构建过程中，由于ContinentPortlet和ContinentMapPortlet都为远程Portlet，因此它们之间的协作可以依据WSRP2.0规范进行处理。最终可以得到图6的协作页面。

为减少开发量，我们可以重用在其他远程门户中的Portlet(ContinentPortlet、ContinentMapPortlet)，这些Portlet通过WSRP2.0规范被发布，因而可以被消费者门户所使用。因此开发者只需要开发ContinentInfoPortlet即可。

ContinentInfoPortlet是一个本地Portlet，开发者首先要通过WSRP2.0的getServiceDescription()方法得到ContinentPortlet和ContinentMapPortlet所能发布和处理的事件信息，并根据事件的XML定义开发能够处理该信息的ContinentInfoPortlet。在开发完成后，按门户系统要求部署即可。图6给出了运行截图，它由1个本地Portlet和2个远程Portlet组成。

根据以上例子可知，在传统的联邦门户环境中，消费者门户虽然可以订阅生产者门户的Portlet，但不能针对远程Portlet的协作特性进行二次开发，因为远程Portlet和本地Portlet不具备协作能力，这样就为Portlet的再利用增加了额外的迁移和开发负担。而本发明的方法和系统增强了异构门户的互操作性，能够支持远程Portlet和本地Portlet的协作，使得Portlet开发人员能够复用远程Portlet的协作能力，促进Portlet的在再利用，从而达到节省工作量、充分整合遗留IT资源的目的。

Claims (4)

1.一种支持Portlet协作构建复杂业务逻辑的方法，包括如下步骤：

1）在JSR286和/或WSRP2.0规范下，用户触发消费者页面上的任意Portlet的操作由本地或远程Portlet产生发布事件，所述发布事件通过代理容器的验证，被触发的Portlet处理该操作；

2）所述被触发的Portlet在处理过程中触发事件X或设置公共呈现参数；

3）通过协作服务将事件X包装为消息MX，对消息或公共呈现参数进行验证；

4）根据响应对象将验证后的消息或公共呈现参数由响应对象带回Portlet容器；

5）Portlet容器通过调用协作服务，确定可以处理事件X或公共呈现参数的接收Portlet；所述协作服务随着触发消费者页面上的任意Portlet的操作启动；对于每一种Portlet容器实现消息验证、消息处理、以及公共呈现参数验证，并在Portlet容器启动的时候将消息验证器、消息处理器和公共呈现参数验证器注册到协作服务中，在Portlet容器销毁的时候从协作服务中注销；

6）当被触发Portlet与接收Portlet是不同类型Portlet，对消息MX进行事件转换或对公共呈现参数进行转换，将转换后的消息MX或公共呈现参数发送到接收Portlet进行处理，所述的Portlet类型为本地Portlet或远程Portlet，所述事件转换是事件内容的转换，所述事件内容的转换是指Java对象和XML字符串之间的转换；将事件X发送到代理容器，由代理容器转发给WSRP生产者，然后WSRP生产者交由WSRP容器，然后WSRP容器转发给接收Portlet处理；

7）处理完成后，Portlet容器依次调用门户页面上的所有Portlet的render或GetMarkup过程完成页面聚合，将生成的页面片段返回给用户。

2.一种如权利要求1所述的Portlet协作构建方法对应的复杂业务逻辑的系统，其特征在于包括本地Portlet容器、代理容器、协作服务、协作信息转换器、消息验证器、消息处理器、公共呈现参数验证器和消息队列，本地Portlet容器和代理容器连接协作服务并调用协作服务；协作服务连接并调用协作信息转换器、消息验证器、消息处理器和公共呈现参数验证器，其中，

本地Portlet容器，运行本地Portlet；

代理容器，运行远程Portlet；

协作信息转换器，进行事件和公共呈现参数的转换；

协作服务，包装事件X为消息MX，连接并调用消息验证器、消息处理器和公共呈现参数验证器；

消息验证器，验证消息MX；

消息处理器，确定处理消息MX的Portlet；

公共呈现参数验证器，验证公共呈现参数；

消息队列，添加和处理消息。

3.根据权利要求2所述的系统，其特征在于所述本地Portlet容器或代理容器上设有消息验证器接口、消息处理器接口及公共呈现参数验证器接口。

4.根据权利要求2所述的系统，其特征在于所述消息验证器、消息处理器和公共呈现参数验证器在Portlet容器启动时注册到协作服务，在Portlet容器销毁时从协作服务注销。

Images