Portal

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。



图1:一个集成了Pluto的简单Portal

Portlet容器

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的部署

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标准

Pluto和WSRP标准

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

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