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容器是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 实现。