PLUTO architecture
We start with the architecture of Pluto and some basic concepts. First, we briefly explain the portal that runs the Pluto Reference Implementation, see where Portal will find the portlet container from the Portal architecture. Second, we will explain the architecture of Pluto in detail. Finally, we will explain how it solves a challenge of portlet containers: Portlet deployment.
Portal
Pluto is an implementation of a portlet container that meets the portlet API specification, which provides developers with a work platform running portlets. However, if there is no drive (Driver), it is also the support of Portal, the operation and test portlet container will be very troublesome. Pluto itself also provides a simple Portal module that is merely written to meet the needs of portlet containers and JSR 168. If you need a mature portal, please refer to the JetSpeed project. The JetSpeed project is concerned with Portal itself, not a portlet container.
Figure 1 is a basic architecture of Portal. Portal Web Application handles the customer's request, extracting portlets from the customer's current page, then call the portlet container to get the content of each portlet. Portal accesses the portlet container through the Invoker API of the Portlet container. These APIs are the main call interface of Portlet containers, which provide portal with some requested methods to call the portlet. The user of the container (ie Portal, Translator Note) must implement the Container Provider SPI interface of the portlet container to provide the portal information related to Portal. Finally, the portlet container calls all portlets via the Portlet API.
Portlet container
The portlet container is the runtime environment of portlets and the core components of each portal. Portlet containers need to get some information about Portal itself, and must also reuse some of the basic code of Portal. Therefore, the Portlet container ensures that it is completely separated from other portal components. That is, you can insert a separate portlet container into any portal, as long as it meets the requirements of the portlet container, such as all SPIs.
The invoker API of the Portlet container is the main call interface of the portlet container. These APIs include the lifecycle control method of portlet containers (init (), destroy ()) and request-based call methods (initpage (), performtitle (), portletService (), etc.). Since the Portlet container is finally calling a portlet, the signature of these methods and the main portlet interface of the portlet API is similar, except for a portlet ID that must be added. Portlet containers can determine which portlet calls through this additional incoming portlet ID parameter.
In addition to using the Invoker API to call the portlet container, Portal must implement the SPI defined by the portlet container. Thus, the reference implementation introduces the concept of "container service": the container service is used to define some pluggable components that can be registered in the container, and these components either provide some basic functions, either expand the container. The Pluto Reference implementation defines the following built-in container services (the first four must be implemented by running the portlet container, and the fifth is optional): Information provides: Provides Portal for Portal And the information of its framework. Some known or presence information in Portal can be obtained by this interface. This information includes a URL generation of navigation (Navigational State), portlet context, portlet mode, and Window State Control. Factory Manager (factory manager): Defines how to get an implementation through the factory (the general portal should have implemented such an interface). Log Service: Defines the method of output logs (the general portal should have implemented such an interface). Config Service: Defines how to get a configuration value (the general portal should have implemented such an interface). Property Manager (optional): This service allows Portal to get values for properties defined in the JSR 168 specification.
Strictly speaking, Portlet Object Model (portlet object model) is also a SPI, but it is in a special location than other SPIs. So we don't think it as part of the container service because it processes all portlet objects and contains some mixed interfaces.
Figure 2: Architecture of Portlet container
Portlet deployment
The Portlet container is built on the servlet container, so it can reuse the number of servlet containers. In order to achieve this, the Portlet container must inject some servlet's properties into the WAR file of each portlet application, as shown in Figure 3. The deployer of the Portlet component will inject a new or modified web.xml in the original WAR file, and then inject a servlet package for each portlet, so as the call point. The portlet deployer will then pass this modified WAR file to the deployment of the application server to deploy it to the application server. When a portlet is called, the portlet container will call the inserted servlet package, which takes this as the entry point of the WAR file deployed portlet.
Figure 3: Reference implementation portlet deployment
PLUTO and WSRP standard
JSR 168 Specifications and Web Service For Remote Portlets (WSRP) standards have a high degree of consistency. These two simultaneous standards have released an open source implementation, and their implementations have completed all the necessary features defined in the corresponding specification. Both standards will work well as their common goals. Therefore, WSRP portlets can be operated as consumers in the portlet container, or as a producer.
