Pluto Portlet容器的体系结构

1．pluto技术验证。

1 ． 1 什么是 pluto 。

Pluto 是一个满足 Portlet API 规范的 Portlet 容器的实现，它为开发者提供了一个运行 portlets 的工作平台。然而，如果没有一个驱动器（ driver ），也就是 Portal ，的支持的话，运行和测试 Portlet 容器将非常之麻烦。 Pluto 本身也提供了一个简单的 Portal 模块，该模块仅仅是为了满足 Portlet 容器和 JSR 168 的需要而写的。如果你需要一个成熟的 Portal ，请参考 Jetspeed 项目。 Jetspeed 项目关注的是 Portal 本身，而不是 Portlet 容器。

1 ． 2 Portal 的基本体系结构。

Portal Web Application 处理客户的请求，从客户的当前页中提取出 portlets ，然后调用 portlet 容器来获得每一个 portlet 的内容。 Portal 通过 Portlet 容器的 Invoker API 来访问 portlet 容器。这些 API 是 portlet 容器的主要调用接口，它们为 Portal 提供了一些基于请求的方法来调用 portlet 。容器的使用者（即 Portal ，译者注 ）必须实现 portlet 容器的 Container Provider SPI （ Service Provider Interface ）回调接口，来为 portlet 容器提供与 Portal 相关的信息。最后， portlet 容器通过 Portlet API 调用所有的 portlets 。

1. 3 portal 的基本体系结构图解。

2. portlet 技术验证。

2. 1 portlet 容器。

Portlet容器是portlets的运行时环境，也是每一个Portal的核心组件。Portlet容器需要获 取有关Portal本身的一些信息，还必须重用Portal的一些基本代码。因此，Portlet容器可以 保证自己与其它的Portal组件之间是完全分开的。也就是说，你可以把一个独立的Portlet容器 插入到任何一个Portal中去，只要它可以满足Portlet容器的要求，比如实现了所有的SPI。

Portlet容器的Invoker API（也被称为进入点）是Portlet容器的主要调用接口。这些API包 含Portlet容器的生命周期控制方法（init()，destroy()）和基于请求的调用方法 （initPage()，performTitle()，portletService()等等）。由于Portlet容器最终是 去调用一个portlet，故这些方法的签名和Portlet API的主要portlet接口很类似，除了一个 须额外传入的portlet ID。Portlet容器可以通过这个额外传入的portlet ID参数来决定调用 哪一个portlet。

除了可以使用Invoker API来调用Portlet容器外，Portal还必须实现Portlet容器定义的SPI。 因此，参考实现引入了“容器服务”的概念：容器服务用来定义一些能够在容器中注册的可插的组件， 这些组件要么提供一些基本的功能，要么对容器进行扩展。Pluto参考实现定义了下面这些内建的 容器服务（前四个是运行Portlet容器所必须实现的，而第五个则是可选的）：

Information Provider （信息提供者） ：为 Portlet 容器提供关于 Portal 及 其框架的信息。通过该接口只能够获得一些已知的或存在 Portal 中的信息。这些信息包括带 导航状态（ navigational state ）的 URL 生成、 portlet 上下文（ portlet context ）、 portlet 模式（ portlet mode ）和窗口状态（ window state ）控制。

Factory Manager （工厂管理者） ：定义了如何通过工厂获得一个实现（一般的 Portal 应该已经实现了这样的接口）。

Log Service （日志服务） ：定义了输出日志的方法（一般的 Portal 应该已经实 现了这样的接口）。

Config Service （配置服务） ：定义了如何获得配置值（一般的 Portal 应该已 经实现了这样的接口）。

Property Manager （属性管理者，可选） ：该服务让 Portal 可以获得 JSR 168 规范中定义的属性的值。

严格的说，Portlet Object Model（Portlet对象模型）也是一个SPI，但与其它的SPI相比， 它处在一个特殊的位置上。因此我们不把它看成是容器服务的一部分，因为它处理所有的portlet 对象，并包含了一些混杂的接口。

2 ． 2 portlet 容器的体系结构。

2 ． 3 portlet 的部署。

Portlet容器是构建在Servlet容器之上的，所以它可以重用Servlet容器的许多功能。为了达到 这一点，portlet容器必须把一些servlet的属性注入到每一个portlet应用的war文件中，如 图所示。Portlet组件的部署器将在原先的war文件中注入一个新的或者修改过的web.xml，再 为每个portlet注入一个servlet包裹器，以此作为调用点。然后，portlet部署器将把这个修 改过的war文件传给应用服务器的部署器，以此来把它部署到应用服务器的系统中。当一个 portlet被调用时，portlet容器将调用注入的servlet包裹器，把这作为被部署的portlet的 war文件的进入点。

2 ． 3 portlet 的部署图解。

3．Pluto和WSRP标准。

JSR 168规范和Web Service for Remote Portlets（WSRP）标准有高度的一致性。这两 个同时出现的标准都发布了开放源码的实现，它们的实现都完成了在相应的规范中定义的所有必要 功能。这两个标准都把能很好的互相协作作为它们共同的目标。因此，WSRP portlets在 portlet容器中既可以作为消费者运行，也可以作为生产者运行。

Pluto项目必须支持在一个Portal中运行多个portlet容器。因此，Pluto Portlet容器可以 被多次初始化。更重要的是，它可以以不同的方式运行，每个portlet容器都使用一个不同的SPI 实现。

4 ． 总结 。

Pluto项目是Java Portlet规范的参考实现（Reference Implementation）。该规范目前 的版本是 JSR 168。

Portlets是一种运行在portal环境下的对象，它们通过与Servlet API相似的Portlet API 编写。与servlets不同的是，portlets有很多不能做的事情，比如直接向浏览器发送重定向应答 或错误，比如转发请求，比如往应答的输出流中写入任意的markup标签，等等。这是因为 portlets是被portal web application所使用的对象，它们的行为不能干扰到portlet web application的工作。与servlets的另外一个区别是，portlets依赖一些portal所特有 的底层功能，诸如对user profile信息的访问，诸如存取持久层设定的标准接口，诸如获取客户 信息，等等。一般而言，与servlets相比较，portlets以一种更加动态的方式被管理。

Portlet容器为满足Portlet API规范的portlets提供了运行环境。Portlets可以在该环境中 被初始化，被触发和调用，以及最终被销毁。和Servlet容器不同的是，Portlet容器不是作为一 个独立可运行的容器来实现的，而是架设在Servlet容器之上的一个层，它重用了Servlet容器提 供的许多功能。

Pluto是一个满足Portlet API规范的Portlet容器的实现，它为开发者提供了一个运行 portlets的工作平台。然而，如果没有一个驱动器（driver），也就是Portal，的支持的话， 运行和测试Portlet容器将非常之麻烦。Pluto本身也提供了一个简单的Portal模块，该模块仅 仅是为了满足Portlet容器和JSR 168的需要而写的。如果你需要一个成熟的Portal，请参考 Jetspeed项目。Jetspeed项目关注的是Portal本身，而不是Portlet容器。