Pluto is the Reference Implementation of the Java Portlet Specification. The current version (2.0) of this specification is known as JSR-286. The previous specification version, JSR-168, covers version 1.0 of the specification. Pluto implements and is fully compliant with both the 1.0 and 2.0 specifications.
A portlet container provides a runtime environment for portlets implemented according to the Portlet API. In this environment portlets can be instantiated, used and finally destroyed. The portlet container is not a stand-alone container like the servlet container; instead it is implemented as a thin layer on top of the servlet container and reuses the functionality provided by the servlet container. Architecturely, it provides an interface between the portal and portlets.
Pluto serves as the portlet container for many portals, including Apache Jetspeed. To accommodate the aggregation and display of diverse content in a dynamic manner, a portal such as Jetspeed must provide a framework that integrates the various pluggable parts into a consistent user interface for the portal user. The pluggable parts are called portlets. The contract, or programming API, between these portlets and a portal is known as the Portlet API. Pluto is the implementation of this contract or API.
Pluto fully implements the Portlet API specification and offers developers a working example platform from which they can test their portlets. However, it is cumbersome to execute and test the portlet container without a driver such as a full running portal. Pluto's simple portal component is built only on the portlet container's and the JSR 286's requirements.
If you want to get started with rapid portlet development with Pluto, see the documentation on Developing with Pluto
In contrast to servlets, portlets may not do things like sending redirects or errors to browsers directly, forwarding requests or writing arbitrary markup to the output stream to assure that they don't distract the portal web application which uses them. Another difference compared to servlets is that portlets rely on portal specific infrastructure functions such as access to user profile information, standard interface for storing/retrieving persistent settings, getting client information, etc. Generally, portlets are administrated more dynamically than servlets.