Designing of Portlet-basedWeb Portals

166 p.

一种支持JSR286的Portlet容器的设计与实现

门户可以将各种异构应用和数据资源集成到同一用户界面下，并根据用户或角色的不同，形成个性化访问页面，进而实现信息的有效传递。门户作为信息集成与发布的有效手段已经获得了广泛的认可。 门户采用基于组件化的方式进行构建。Portlet容器是其重要组成部分，负责管理Portlet组件的生命周期，提供Portlet组件的运行环境，同时提供容器访问接口接受来自门户服务器的容器请求，并将Portlet产生的标记片段返回给门户系统以聚合形成门户显示页面。 Portlet容器的需求来源于Portlet规范和门户两方面。门户的广泛应用对门户系统提出了新的要求，2008年3月JCP组织(Java Community Process)提出了新的Portlet规范即JSR286规范，门户系统需要修改其Portlet容器以适应这种变化。 本文从JSR286规范和门户需求出发，设计并实现了一个Portlet容器。首先根据JSR286规范对Portlet组件、界面和个性化三方面的特征进行分析；其次总结了Portlet容器的核心功能、系统边界，并给出了Portlet容器的模块设计；然后为满足生命周期状态控制和门户构建中协作重组的应用需求，对Portlet容器在这两方面进行了扩展，分别提出了容器中多粒度的生命周期状态控制以及Portlet协作时的事件转换机制；最后基于以上分析和设计，实现了一个Portlet容器，并将其应用在中科院软件所自主研发的门户产品OncePortal中。

一种面向MVC Web框架的Portlet桥接设计与实现

门户提供了对信息资源的单一访问入口， 将各种异构应用和数据资源集成到同一用户界面下，并根据用户或角色的不同，形成个性化访问页面，进而实现信息的有效传递和共享。 企业为了满足自身业务的需求而不断推出不同的业务系统，如电子商务系统、办公自动化系统、企业资源管理和财务管理系统。但是由于各个系统之间互相孤立，数据分散，形成了一个个“信息孤岛”。集成现有的应用系统成为门户中间件平台的一个重要目标。 门户中现有的集成方式，如首页集成、工作流集成，可以将已有的应用集成到门户中。但是这些方式不够灵活，表现在对于 Web 应用，不能将已有的业务逻辑和界面表现同时方便地集成到门户中。虽然JCP社区提出了 JSR 301规范，支持 JSF 框架的 Portlet 桥接，将 JSF 应用集成到门户中，但是对集成的应用系统类型有很大的限制。面对企业中不同类型的应用系统，缺少一种较为通用的解决方法。 本文针对MVC Web 框架的特性以及门户中应用集成的实际需求，提出了一种面向MVC Web 框架的 Portlet 桥接，一方面支持多种 Web 框架；另一方面在不改变原有应用系统的前提下，将该系统集成到门户环境中。通过分析和比较MVC Web 框架和Portlet 之间的工作原理以及运行环境，总结出桥接过程中必须 解决的三个关键问题：请求处理、URL 地址改写以及运行环境上下文的适配。为解决以上问题，本文设计了两阶段的请求处理方式，定义了 URL 地址的改写规则以及设计了上下文的适配器。在此基础之上，给出了 Portlet 桥接的分析与设计。 基于本文给出的 Portlet 桥接设计，在自主研发的企业门户 OncePortal 中实现了 JSF、Struts 两种具体桥接，并通过应用实例验证 Portlet 桥接的有效性，实现对 Web 应用系统的无缝集成。

支持JSR286规范的Portlet协作框架的设计与实现

Portlet是具有用户界面的可与用户多次交互的Web组件。随着Portal和Portlet在企业中的广泛应用，仅仅将各种应用和数据通过Portlet集成到Portal中已经不能满足用户的需求。用户希望这些应用之间能够相互协作，以利用现有应用组建新的业务流程。Portlet协作是指两个或多个Portlet进行信息交换并使用这些信息的能力。目前协作功能的实现方式可以分为两种：基于后端(back-end)的实现方式与基于前端(front-end)的实现方式。在这两种协作实现方式的基础上，本文提出了两种Portlet协作框架。 本文提出一种基于事件的Portlet前端协作模型，通过引入此模型，解决了Portlet前端协作中客户端与服务器端无法交互的困难，使协作动作由客户端和服务器端共同完成。基于此模型提供给开发者一种可扩展的协作框架，利用JavaScript技术使得协作的Portlet在客户端“相知”，协作的行为在客户端触发，Portlet获得协作数据后使用Ajax技术请求服务器端的资源，服务器端使用JSR286规范定义的资源服务接口响应用户的请求，进而动态更新界面。 当前的Portlet后端协作方式依赖于特定的Portal产品，针对这点不足，本文在JSR286规范定义的事件及共享渲染参数协作机制基础上，实现了一个Portlet后端协作框架。在该框架中协作服务使用消息队列保存待处理的消息，Portlet 容器作为中介实现发布事件的Portlet和订阅事件的Portlet之间松散耦合。Portlet监听协作事件，事件触发后调用事件协作服务发布事件，为了提高协作的并发性，事件协作服务使用多线程处理协作事件。该协作框架与JSR286规范兼容，具有良好的可移植性。 本文对这两种Portlet协作框架进行了实现，并将其应用于中科院软件所自主开发的门户产品OncePortal中。本文重构了OncePortal系统，给出了框架的体系结构与系统接口，描述了框架的各功能模块，并详细讨论了Portlet协作框架中的关键技术，包括事件协作流程的描述、事件处理过程、多级事件流等。

支持事件转换机制的Portlet协作的设计

Portlet2.0规范JSR286中定义了基于事件的发布/订阅的Portlet协作方式,但协作依赖于协作事件的定义,降低了Portlet的交互能力,不支持通过Portlet协作重组创建新的协作页面。通过在现有协作框架中引入事件转换机制,解除Portlet协作与事件之间的依赖关系,提高Portlet协作的可重用性,同时给出门户系统中支持事件转换机制的Portlet协作的设计与实现。

Plug-and-play remote portlet publishing

Web Services for Remote Portlets (WSRP) is gaining attention among portal developers and vendors to enable easy development, increased richness in functionality, pluggability, and flexibility of deployment. Whilst currently not supporting all WSRP functionalities, open-source portal frameworks could in future use WSRP Consumers to access remote portlets found from a WSRP Producer registry service. This implies that we need a central registry for the remote portlets and a more expressive WSRP Consumer interface to implement the remote portlet functions. This paper reports on an investigation into a new system architecture, which includes a Web Services repository, registry, and client interface. The Web Services repository holds portlets as remote resource producers. A new data structure for expressing remote portlets is found and published by populating a Universal Description, Discovery and Integration (UDDI) registry. A remote portlet publish and search engine for UDDI has also been developed. Finally, a remote portlet client interface was developed as a Web application. The client interface supports remote portlet features, as well as window status and mode functions. Copyright (c) 2007 John Wiley & Sons, Ltd.

支持WSRP 2.0规范的联邦门户的设计与实现

门户（Portal）是基于组件的web应用，它可以集成Internet环境下各种现有应用系统、数据资源和网络信息资源，并为用户形成个性化的访问页面，实现信息的集成和发布。Portlet是门户中的可重用组件，能够提供对web内容、应用程序和其他资源的访问。JSR168规范（Portlet 1.0）和JSR286规范（Portlet 2.0）提供了Portlet的标准。 随着门户的广泛使用，门户已经成为获取信息，巩固和整合IT基础设施的平台。于是来自于同一公司的、自主的、分散的多个部门都部署了自己的门户，但这些门户之间却无法进行内容共享，即Portlet在门户之间的集成。于是出现了联邦门户（Federated Portals），它是由多个分散的门户构成的网络，这些门户基于共同的标准协同工作。联邦门户实现了在异构门户之间共享远程内容，这些远程内容来自于名为生产者的门户，被收集、组合和运行在名为消费者的门户中。 联邦门户的基本特征是基于规范实现跨门户的系统联合。因此联邦门户的关键在于对门户间互操作标准的制定。这个标准就是OASIS推出的WSRP（Web Services for Remote Portlets）规范。WSRP规范提供了门户间互操作标准，成为联邦门户的基础技术。它有1.0和2.0两个版本，分别产生于2003年和2008年。 为了提高联邦门户应用的构建效率，增强异构门户互操作性的能力，完善联邦门户的用户友好性，需要为OncePortal提供支持WSRP 2.0规范的联邦门户。 本文从WSRP 2.0规范和联邦门户的需求出发，设计并实现了支持WSRP 2.0规范的联邦门户。首先根据WSRP 2.0规范对远程Portlet的语法模型、交互模型和生命周期模型三个方面进行特征分析；其次总结了联邦门户的核心功能、系统边界，并给出了联邦门户的设计；然后从Portlet URL的生成与改写、Portlet统一协作框架、远程Portlet资源服务、WSRP容器和代理容器以及Portlet缓存共5个方面介绍了联邦门户的关键技术；最后基于以上分析和设计，实现了联邦门户扩展应用，并将其应用在中科院软件所自主研发的门户产品OncePortal中。

一种多门户环境下服务资源管理框架的设计与实现

随着企业信息化建设的快速发展，门户系统在实际中的应用越来越广泛。服 务是门户系统重要的组成部分之一，对门户系统的功能提供支撑作用。要维持门 户正常的运行管理维护，门户系统就需要提供相应的服务。 多门户系统是指在一个门户平台上运行多个虚拟门户。 通过用户数据资源的 相对隔离，门户系统在逻辑上划分成多个虚拟门户。每个虚拟门户由多个Portlet应用组成。在多门户环境下，服务具有如下特点：服务分散部署在门户平台和多 个 Portlet 应用中，服务之间存在依赖关系，而且不同应用间存在服务的共享； 随着虚拟门户数量的增加，服务的数量也在不断动态增加，对门户系统的压力也 在不断增加。与一般 Web 应用中的服务相比，多门户环境下不同的应用之间存在 服务交互。同不支持多门户的门户系统相比，多门户环境下服务有作用范围，服 务的数量大且动态变化。因此，根据多门户环境下服务的特点，要实现对服务资 源的管理需要解决如下问题：如何管理服务的依赖关系，如何确定服务的作用范 围，如何实现对服务资源的访问控制，如何实现对服务资源的动态管理,以及如 何减轻服务对门户系统的压力。 本文提出了一种多门户环境下服务资源管理框架，能够有效地解决上述问 题。该服务资源管理框架包含对服务生命周期的管理，对服务的访问控制，基于 事件的服务管理，以及服务的热部署。且本文对其中的服务依赖关系管理，事件 运行监控问题等关键技术点进行了探讨，采用相关的算法解决相应的问题。而且 本文实现了服务资源管理框架，部署在门户中间件 OncePortal 中，从而实现对服务资源的有效管理。

基于产品线工程的组件容器开发方法研究

近年来，随着Internet规模的增长，分布式组件技术快速发展，新的组件模型不断涌现，现有的组件模型也持续更新。组件容器为组件及组件应用提供部署和运行环境，是基于组件分布式应用开发的核心。组件模型的多样化和快速演化要求组件容器的开发方法将研究范围扩大到整个领域。产品线工程是基于软件核心资产构建软件产品系列的工程方法，将产品线工程方法应用于组件容器领域可以促进组件容器的系统化复用，获得更高的生产效率和产品质量。 由于组件容器领域的特点，应用过程中现有的产品线工程方法体现出一些不足。产品线工程包括领域工程和应用工程，其中领域工程又由领域分析、领域设计和领域实现构成。组件模型是组件容器需求的主要来源，但目前缺乏对组件模型的统一认识和详细分析；领域分析建模要求领域模型有效地刻画领域需求的组织结构、相互关系和变化性，并提供具体的建模过程指导，现有的面向特征、基于用例等领域建模方法存在语义模糊、粒度不当、缺乏具体流程指导等不足。 针对上述问题，论文按照软件开发流程顺序，从需求分析、领域建模、领域设计等方面，对组件容器设计和开发的若干关键问题进行了重点研究，包括组件模型分析、基于原子需求的领域建模方法、组件容器产品线体系结构等。 首先，由于组件模型是组件容器需求的主要来源，针对现有的组件模型分析方法粒度较大的问题，通过分析相关软件实体可能具有的各种约束，选择从语法、部署和交互三个方面，得到构成组件模型的模型元素，提出了一个细粒度的组件模型分析框架。将该分析框架应用于目前有代表性的分布式组件模型，基于分析结果提炼了分布式组件模型的主要公共特征，并与其他分析方法做了对比。 另一方面给出了基于原子需求的领域建模方法。以原子需求概念为基础，提出了一个多层次的领域需求描述模型，从用例、原子需求等多个层次刻画领域需求，并基于变化点建立独立的变化性描述机制。介绍了相应的领域建模过程，包括其建模步骤、建模原则和描述规范，为领域分析人员提供具体指导。并结合领域实例探讨了领域建模的过程。 基于以上工作，本文设计了组件容器产品线体系结构PLACE。首先将基于软件实体的组件模型分析框架与基于原子需求的领域建模方法相结合，建立组件容器领域模型，进而提出了组件容器产品线体系结构PLACE，从体系结构、模块功能、变化性设计和变化性管理等方面介绍了其设计。具体组件容器的设计实例表明，PLACE通过在组件模型和体系结构间建立直接的对应关系，有效促进了组件容器领域内的系统化复用。 最后，我们将上述方法应用于网驰平台中组件容器产品系列包括Web容器、EJB容器、BPEL容器和Portlet容器等的设计。实验结果证实了基于PLACE的开发方法在保证产品功能正确性的同时，提高了组件容器领域内的结构复用性，获得了更高的生产效率和产品质量。

Smart-RBAC

Generally, smart campus applications do not consider the role of the user with his/her position in a university environment, consequently irrelevant information is delivered to the users. This dissertation proposes a location-based access control model, named Smart-RBAC, extending the functionality of Role-based Access Control Model (RBAC) by including user’s location as the contextual attribute, to solve the aforementioned problem. Smart-RBAC model is designed with a focus on content delivery to the user in order to offer a feasible level of flexibility, which was missing in the existing location-based access control models. An instance of the model, derived from Liferay’s RBAC, is implemented by creating a portal application to test and validate the Smart-RBAC model. Additionally, portlet-based applications are developed to assess the suitability of the model in a smart campus environment. The evaluation of the model, based on a popular theoretical framework, demonstrates the model’s capability to achieve some security goals like “Dynamic Separation of Duty” and “Accountability”. We believe that the Smart-RBAC model will improve the existing smart campus applications since it utilizes both, role and location of the user, to deliver content.