Jetspeed-2 is a new project, written from groundup and does not have any dependencies on Jetspeed-1. Jetspeed-2 is based on industry standards, designed for high-volume enterprise portals applications. The foremost difference is Jetspeeds Component Oriented Architecture, all assembled together with Spring. Components replace Turbine services with a standardized component model. Deployment of new portlet applications, which was completely missing in Jetspeed-1, is implemented to the Portlet API specification. Turbines file-based configuration for properties are replaced managed components. Jetspeed-2 is fully decoupled from the legacy projects that were intertwined in the Jetspeed-1 architecture.
Not much.
In fact Jetspeed-2 does not re-use any of the code in Jetspeed-1. Some concepts are continued in Jetspeed-2, but with new design and implementations. The table below shows some of the concepts continued in Jetspeed-2 from Jetspeed-1. Note that even though the concepts are continued, they are have changed, in some cases significantly:
Jetspeed-1 is tightly coupled to the Turbine MVC-2 framework, and this coupling permeates many areas of the Jetspeed API. Jetspeed-2 does not rely on Turbine as the MVC-2 controller. Instead, we follow the separation of concerns pattern, and concentrates on doing one thing and doing it well. That is, implementing a portal. Where as Jetspeed-1 coupled MVC Controller, portal engine, and portlet container all into one deeply coupled servlet, Jetspeed-2 separates these concerns clearly in its architecture. The portal engine is Jetspeed-2. It is the MVC for page aggregation, leveraging the dispatching nature of the servlet architecture, and delegating the actual rendering of portlets to portlet application frameworks. These portlet applications can in turn have their own MVC frameworks, such as Struts portlet applications, JSF portlet applications, or Turbine portlet application frameworks.
Most notably missing from Portlet API portlets is the RunData class. The Jetspeed-1 API uses the RunData class ubiquitously, serving as a wrapper for both the servlet request and response. Other dependencies on Turbine include Portlet Actions, Portlet Aggregation Engine (ECS), the Service Architecture, Configuration and Turbine Modules. None of these exist in the newer version.
| Jetspeed-1 | Jetspeed-2 |
|---|---|
| Run Data | Portlet API: Portlet Request and Portlet Response |
| Portlet Aggregation Engine (ECS) | Jetspeed-2 Multi-threaded Portlet Container Engine |
| Turbine Service Architecture | Jetspeed-2 Components |
| Property Configuration Files | Spring Configurations, JMX |
| Turbine Modules (Actions) | Portlet API Actions |
The Jetspeed-2 portal does not implement the Portlet container. Pluto implements the JSR 168 interface contract for portlets running inside our portal. The Pluto container handles all communication with portlets for the portal.
The aggregation engine and the Jetspeed-1 Portlet API are both coupled to a deprecated Jakarta package ECS (Element Construction Set). ECS generates HTML with Java code, storing the content in temporary Java objects before sending the HTML out to the servlet output stream. This wasteful use of Java objects leads to fragmentation on memory, accelerated garbage collection, and paging in high volume sites. The servlet API clearly provides a content stream for streaming out portlet content. Jetspeed-2 models its aggregation engine upon the Portlet APIs streams and readers, analogous to the stream-based Servlet API for rendering content.
The Portlet API clearly defines the lifecycle of a portlet, the event sequences for actions, and how the container can cache content from a portlet. The Portlet Lifecycle was not clearly defined in Jetspeed-1. The portlet API clearly states that only one instance of a portlet will reside in memory inside a container. The state of the portlet is directly related to the servlet state for the current user session. While this may seem obvious, portlet state and lifetime was not clearly defined in Jetspeed-1.
In version 1, actions were coupled to Turbine and not properly integrated into the Portlet class. In fact, actions were separate objects from portlets. In the Portlet API, actions are methods on the portlet. Action event handling and sequencing is clearly defined in the specification.
Jetspeed-1 does not have a standardized method of deploying portlets and their supporting files, commonly referred to as portlet applications. In order to import an application, one must package registry files, class and jar files, PSML and templates so that they match the Jetspeed web application format.
In Jetspeed-2, the Portlet API defines a standard deployment descriptor for deploying Portal Applications into Jetspeed. Portal applications must be deployed to the portal. Analogous to the servlets packaged in a web-application (WAR) deployment model, portals support portlets packaged in a portal-application deployment model. The Portal Application archive follows the same format as the WAR format defined in the Servlet specification with an additional Portlet deployment descriptor file. The clear advantage in Jetspeed-2 is the ability to deploy live portlet applications to the server in a standardized format.
Jetspeed-1 resources such as portal templates, images, skins, controllers, controls, are all merged into the single Jetspeed web application with no deployment model. For example, to override the default skin or top banner, the resource files are copied into the portal directory, property files updated to point to the new resources, and the server must be restarted. This made for the process of tailoring Jetspeed-1 portals to real production portals a process of property and file merging. In fact Jetspeed-1 now has a Maven plug-in to manage production portals separately from the core Jetspeed-1 portal. The need for this kind of tool covers up the fact that Jetspeed-1 is missing a good deployment model for portal resources, requiring difficult portal maintenance procedures.
For a Jetspeed-2 production portal, portal resources are packaged in a Jetspeed-specific archive format. Thus portal resources (top banners, skins, images, style sheets) can all be deployed to dynamically tailor the portal at runtime.
JSR168 is the Portlet specification enables interoperability between Portlets and Portals. The specification defines a set of APIs that addresses standardization of portlet aggregation, personalization, presentation and security. The goals of JSR168 are to:
The Jetspeed-2 Portlet Server supports the JSR 168 standard. This is an important initiative, introducing true portlet portability.