Pluto项目介绍(2)-Pluto体系结构

 

                            Pluto体系结构

我们从阐述Pluto的体系结构和一些基本概念入手。首先，我们简要的解释一下运行Pluto参考实现的Portal，看一看在Portal的体系结构中，Portal将从哪里找到portlet容器。其次，我们将详细的说明Pluto的体系结构。最后，我们将说明它是如何解决portlet容器的一个挑战性的问题：portlet的部署。

Portal

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

图1是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。

 

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：Portlet容器的体系结构 

Portlet的部署

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

 图3：参考实现中portlet的部署 

Pluto和WSRP标准

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

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