神马文学网Pluto Portlet容器的体系结构
来源：百度文库 编辑：神马文学网 时间：2024/04/28 04:43:44
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接口很类似，除了一个 须额外传入的portletID。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标准。
JSR168规范和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 webapplication所使用的对象，它们的行为不能干扰到portlet webapplication的工作。与servlets的另外一个区别是，portlets依赖一些portal所特有 的底层功能，诸如对userprofile信息的访问，诸如存取持久层设定的标准接口，诸如获取客户信息，等等。一般而言，与servlets相比较，portlets以一种更加动态的方式被管理。
Portlet容器为满足Portlet API规范的portlets提供了运行环境。Portlets可以在该环境中被初始化，被触发和调用，以及最终被销毁。和Servlet容器不同的是，Portlet容器不是作为一个独立可运行的容器来实现的，而是架设在Servlet容器之上的一个层，它重用了Servlet容器提 供的许多功能。
Pluto是一个满足Portlet API规范的Portlet容器的实现，它为开发者提供了一个运行portlets的工作平台。然而，如果没有一个驱动器（driver），也就是Portal，的支持的话，运行和测试Portlet容器将非常之麻烦。Pluto本身也提供了一个简单的Portal模块，该模块仅 仅是为了满足Portlet容器和JSR168的需要而写的。如果你需要一个成熟的Portal，请参考Jetspeed项目。Jetspeed项目关注的是Portal本身，而不是Portlet容器。
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接口很类似，除了一个 须额外传入的portletID。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标准。
JSR168规范和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 webapplication所使用的对象，它们的行为不能干扰到portlet webapplication的工作。与servlets的另外一个区别是，portlets依赖一些portal所特有 的底层功能，诸如对userprofile信息的访问，诸如存取持久层设定的标准接口，诸如获取客户信息，等等。一般而言，与servlets相比较，portlets以一种更加动态的方式被管理。
Portlet容器为满足Portlet API规范的portlets提供了运行环境。Portlets可以在该环境中被初始化，被触发和调用，以及最终被销毁。和Servlet容器不同的是，Portlet容器不是作为一个独立可运行的容器来实现的，而是架设在Servlet容器之上的一个层，它重用了Servlet容器提 供的许多功能。
Pluto是一个满足Portlet API规范的Portlet容器的实现，它为开发者提供了一个运行portlets的工作平台。然而，如果没有一个驱动器（driver），也就是Portal，的支持的话，运行和测试Portlet容器将非常之麻烦。Pluto本身也提供了一个简单的Portal模块，该模块仅 仅是为了满足Portlet容器和JSR168的需要而写的。如果你需要一个成熟的Portal，请参考Jetspeed项目。Jetspeed项目关注的是Portal本身，而不是Portlet容器。