# Jetspeed-2 Architecture

David Sean Taylor david@bluesunrise.com
December 18, 2002
0.01
December 18, 2002
Initial release

## Overview

### Why Portals?

Modern software is complex and expensive, which has motivated many companies to invest in enterprise portals as a mechanism by which they can manage information in a cohesive and structured fashion. Portals offer many advantages over other software applications. First, they provide a single point of entry for employees, partners, and customers. Second, portals can access Web services transparently from any device in virtually any location. Third, portals are highly flexible; they can exist in the form of B2E intra-nets, B2B extra-nets, or B2C inter-nets. Fourth, portals can be combined to form a portal network that can span a company's entire enterprise system, allowing for access both inside and outside the firewall.

Portals have many advantages, which is why they have become the de facto standard for Web application delivery. In fact, analysts have predicted that portals will become the next generation for the desktop environment.

Portals distinguish themselves from other software systems because they provide the ability to integrate disparate systems and leverage the functionality provided by those systems. As such, they are not mutually exclusive, and do not force you into an either-or decision vis-á-vis existing software systems. This point is of paramount importance, particularly when you consider the fact that Web services are destined to fuel the explosion of Web applications. Since portals can access any Web services, the conclusion is inescapable: portals provide a unique opportunity to leverage the functionality of nascent technologies as well as mature, well-established software systems.

### Why Jetspeed-2?

Jetspeed-2 offers several architectural enhancements and improvements over Jetspeed 1.0. First, Note that some very successful Jakarta projects, including Cocoon and James, have set a precedent for adopting this approach. First, Jetspeed-2 is conformant to the upcoming Java Portlet Standard and will provide a standard mechanism for the deployment of portlets. Second, Jetspeed-2 has matured to a more scalable architecture featuring multi-threaded functionality. Third, Jetspeed-2 is decoupled from several legacy open source projects . Fourth, Jetspeed-2 leverages the functionality provided by several reputable open source projects, the most important of which is Avalon. Finally, Jetspeed-2 has a built-in Syndication Engine and pluggable CMS component services.

### What's New in Jetspeed-2?

1. Fully Compliant with Java Portlet API Standard

2. Multi-threaded Portlet Container

3. Scalable Architecture

4. Content Management Systems (CMS) Integration

5. Syndication Engine ("Push" and "Pull")

6. Pipeline-based Syndication Delivery

7. Proxy Service

8. Jakarta Struts Integration

9. Jakarta Cocoon Integration

10. Jakarta Slide Integration

11. LDAP Security Service

### What's the Same in Jetspeed-2?

While Jetspeed-2 focuses on adapting the new Portal standard, the majority of the popular features of Jetspeed-1 are still a part of Jetspeed-2. All portal resources from Jetspeed-1 port directly into Jetspeed-2, as listed below:

1. PSML

2. Portal Wide Security Constraints

3. JSP and Velocity Templates

4. Controls and Controllers

5. Skins

Portlets and registry entries require a migration process provided with Jetspeed-2.

The majority of the Jetspeed-1 services will be ported to Avalon components, including the popular pluggable Security services, Profile, and PSML Managers.

## Architectural Migration Plan from Jetspeed-1 to Jetspeed-2

This section describes the sub-systems of Jetspeed-1 that will be swapped out and migrated to the new Jetspeed-2 architecture. In essence, the Portlet Aggregation Engine of Jetspeed-1 will be replaced with a new multi-threaded and standardized engine. All couplings to the Turbine project will be removed. Avalon will replace Turbine services with a standardized component model. Deployment of new portlet applications, which was completely missing in Jetspeed-1, will be implemented to the Portlet API specification. Turbine's file-based configuration for properties will be replaced with JMX managing Avalon components.

Existing portlets will be migrating to the portlet API. The effort to migrate portlets ought to be minimal in most cases and will provide a good opportunity for refactoring.

### Remove Coupling To Turbine

Jetspeed-1 is tightly coupled to the Turbine MVC-2 framework, and this coupling permeates many areas of the Jetspeed API. Jetspeed-2 will not use Turbine as the MVC-2 controller. Most notably, the RunData class, which serves as a "wrapper" for both the servlet request and response, is used ubiquitously throughout the Jetspeed-1 API. Other dependencies on Turbine include Portlet Actions, Portlet Aggregation Engine (ECS), the Service Architecture, Configuration and Turbine Modules. Replacements for Turbine will be implemented as follows:

Jetspeed-1 Turbine component | 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 | Avalon
Service and Property Configuration | JMX and Java Preferences API
Turbine Modules (Actions) | Portlet API Actions (deprecate remaining modules)

### Portal Aggregation and Streaming

The aggregation engine in Jetspeed-1 is 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.

### Multithreaded Aggregation Engine

The Jetspeed-1 container is single-threaded. The Jetspeed-2 container engine will be rewritten, and it will be based on the contract defined by the Portlet API between a portlet and the container.

The container will be rewritten as a multi-threaded aggregation engine. Consequently, one portlet does not have to wait for content generation from another portlet.

### State and Portlet Life Cycle

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 lifetime of a portlet was nebulously defined. 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.

### Portlet Action Events

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.

### Deployment

The current version of Jetspeed does not have a standardized method of importing 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 will be the ability to deploy live portlet applications to the server in a standardized format.

## The Java Standard Portlet API

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 current goals of JSR168 are to:

- Define common Portal metaphor

- Define a standard Portlet Java API

- Ensure interoperability and portability

- Enable multiple markups support

- Ensure compatibility with other technologies

The Jetspeed-2 Portlet Server Engine will support the JSR 168 standard. This is an important initiative, introducing true portlet portability to end users. Jetspeed will now be able to plug-n-play portlets from diverse vendors.

### Jetspeed-2 Portal Server Engine

Jetspeed-2 contains an improved version of the portlet container engine of Jetspeed-1, and it will also leverage existing services and portlets from Jetspeed-1. Jetspeed-2 architecture is based on the Avalon component architecture, with extensions to support JMX configuration. The new portal container is multi-threaded and is conformant with the Portlet API specification.

### Avalon Component Architecture

Jetspeed-2 is based upon the Jakarta Avalon Framework as its service and component architecture. Avalon provides complete lifecycle management for managing components and services. Avalon is currently in the process of Java standardization as the de facto component framework at the Java Community Process as the Java Services Framework under JSR-111:

All Jetspeed components and services will be implemented as Avalon components. Avalon is built with two specific design principles as design patterns:

- Inversion of Control (IOC)

- Separation of Concerns

The Inversion of Control pattern is based on the concept that a Component is always externally managed. Every stage in the life of a component is controlled by Avalon. This pattern provides a secure method for components to interact with the system. Avalon supports the availability of multiple implementations of a component at run-time.

According to the Separation of Concerns design pattern, a problem space is viewed from distinct, identifiable. Concern viewpoints can be further abstracted to special concerns called aspects. With the absence of a stable Aspect Oriented Programming (AOP) language, aspects are provided by the Avalon container with small interfaces that a component implements.

Examples of Avalon aspects are component lifecycle, logging, exception handling, resource handling. The lifecycle aspects are very important to Jetspeed-2 service management, providing three lifecycle phases: Initialization, Active Service, and Destruction. The Active Service phase has stages to suspend, reconfigure, and resume a service in a running system.

Avalon is also the base framework for the Jakarta Cocoon project. Thus, Cocoon and Apache could share the same Avalon components within the same web application.

The diagram below shows the container inside of the Portal Server. The container is also a pluggable Avalon component, just like the four sample services.

Sample Portal Servies

### JMX Configuration

The Java Management extension (JMX) is the specification for the instrumentation and management of Java components. Components that implement the Manageable Beans interfaces can be configured through an embedded managed object server. This server communicates with JMX-compliant Management applications, thereby providing a standard way to configure Java components and services. Jetspeed-2 will Avalon components with the JMX configuration.

### Multi-threaded Portlet Container

A Portlet Container runs portlets and provides them with the required run-time environment. The container manages the life cycle of the portlets contained within. The container can optionally cache the content of a portlet. The container manages the contract, or interface, that a portlet communicates with. The container invokes Portlet actions, events, inter-portlet communication and requests content from the portlet.

The Jetspeed-1 container is single-threaded. The Jetspeed-2 container engine will be rewritten, and it will be based on the contract defined by the Portlet API between a portlet and the container.

The container will be rewritten as a multi-threaded aggregation engine. Consequently, one portlet does not have to wait for content generation from another portlet. All requests to a portlet are handled on multiple threads by the servlet container. The servlet request thread will be further threaded to balance the retrieval of content per page. For example, if there are six portlets on a page, the container will retrieve the content of these portlets in parallel, so that the remaining portlets do not have to wait to retrieve content until the subsequent portlet(s) completes.

The lifecycle of a portlet is managed by the container. The portal server requests the portlet from the container. If the portlet is not found in the portlet cache, the portal server will fetch the portlet definition from the portlet registry, load the portlet class with the portal's class loader, and determine how long to keep the portlet in memory before it expires. The container can cache the content of a portlet if specified. Lifecycle and content caching are defined in the portlet descriptor at deployment time. Once a portlet is deployed to the system, Jetspeed keeps this information in a live and configurable registry of portlets.

### Scalability

The scalability requirements for a portal to a business's largest systems are among the most demanding ever placed on a Web platform, primarily due to the number of systems integrated and the breadth of the audience. The portal engine can be configured and deployed to multiple nodes in an application server farm. Through simple configuration settings and integration with the Apache Web Server, Jetspeed servers can be load-balanced to support round-robin and session-affinity-based balancing.

Sample Portal Servies

## Content Management

Jetspeed-2 features a family of Content Management (CMS) services. The CMS services provide an integration interface between Jetspeed and CMS catalogs and resources. The default implementation of Jetspeed CMS will be implemented using the Jakarta Slide project.

The Content Management will be implemented as a family of Avalon component services. The services are "pluggable". There can be multiple active services to support heterogeneous access to diverse CMS repositories under a common API.

All Content Management services can be partitioned into six component interface contracts:

1. Content Manager

2. Search Manager

3. Lock Manager

4. Version Manager

5. Security Manager

6. Workflow Manager

The Content Management resolution is performed in a pluggable fashion; consequently, Jetspeed applications are independent of underlying CMS technologies. New or updated technologies can be substituted without requiring modifications to the application itself. An implementation for a particular CMS technology is determined at run-time.

The CMS implementation can be conformant on three levels:

1. Level One Conformant - implements the required Content and lock component interfaces

2. Level Two Conformant - implements Search , Version and Security component interfaces in addition to Level One required interfaces.

3. Level Three Conformant - implements Workflow component interface in addition to Level One and Level Two interfaces.

A Level One Conformant service provides implementations for the i required component interfaces:

1. Content Manager

2. Lock Manager

A Level Two Conformant service provides implementations for these component interfaces:

1. Search Manager

2. Version Manager

3. Security Manager

A Level Three Conformant services provides implementations for the following component interface:

1. Workflow Manager

### CMS Features

CMS manager | Responsibilities
Content Manager | Create, retrieve, update and delete content; Store links between contents; Provides an infrastructure for recording information about content (metadata like author(s), creation date, status, description, ...)
Lock Manager | Enable remote, collaborative authoring of any media type (HTML, XML, binaries, ...); Resources can be locked as "exclusive" or "shared"
Version Manager | Infrastructure for versioned resources : check in/ check out with comments and metadata; versioning graphs and histories; browse and retrieve old versions
Security Manager | Each CMS service implementation has to be integrated with the Jetspeed security services; Grant permissions are based on the association between a content reference, an action type (read, write, ...) and an actor type (user, group or role)
Search Manager | Query content; Possibility to implement a new query language. Minimal query language can be : Boolean search for property existence or value; or search for substring in a resource content
Workflow Manager | Content can be attached to a workflow, which is a series of tasks what must be completed. Workflow can consist of any number of manual tasks, performed by users and groups, as well as automated tasks which are performed. Workflow tasks can be assigned to groups, in which case any member of a designated groups may approve, edit, or re-route content as appropriate. The default workflow can be customized and linked for reuse in other projects. Users are notified of new tasks via email notifications or notification portlet.

Other features are :

### Folder-based, Hierarchical and Unified Model for Content

The CMS service provides a logical, hierarchical organization of content which can be stored into arbitrary, heterogeneous, distributed data stores. The Jetspeed CMS service integrates and manages data stored within external repositories, requiring only small abstraction layers to be written for each repository based on the unified model. Portlets using the CMS service work only with the unified model.

The model is based on a typical folder-based, hierarchical navigation metaphor. The model supports the following content types:

### WebDAV Support

The Jakarta project provides built-in Level 2 support. With the default Slide/Jetspeed integration, it will be possible to write a Portlet or Struts action to update content in the CMS from any application that supports WebDAV, and secure that action in the context of the portal's security constraints. A typical use case is a Microsoft Office client saving to a URL that maps to a Portlet or Struts action.

## Jetspeed Syndication Engine

The Jetspeed Syndication Engine is a replicating syndication server, capable of handling both request-driven syndication (PULL) and scheduled deliveries (PUSH) . The Engine resides between data sources of content and subscribers. The engine is capable of caching, staging, and transforming content through a configurable delivery pipeline.

In many cases, subscribing clients are other Jetspeed servers; however, the Syndication Engine also supports the FTP and SMTP protocols, ICE agents or other applications which can receive and recognize the protocol and formats supported by the engine's delivery manager.

The Syndication Engine provides its content through standard HTTP requests. Content is delivered as XML payloads or HTML snippets. The XML payloads can also be delivered as ICE payloads adhering to ICE 1.2 specification. The Engine supports both Push and Pull modes of delivery.

Major features of the Syndication Engine include:

### Delivery Pipeline

The Syndication Engine runs all delivery requests through a workflow pipeline. The pipeline's rules are defined on a per-subscriber basis. Valves on the pipeline include chained XML transformations, runtime-based rule analysis, and caching of shared content for performance.

Each time a request reaches the Syndication Engine, the pipeline associated with the request is executed. The syndicated content is accessed by the engine with a Data Source adaptor. With Jetspeed-2, file-based "Staged" Data Sources and CMS Data Sources are supported.

As the response propagates through the pipeline, pre-defined transformations or delivery rules are applied dynamically to the response, which ultimately returns the delivery payload. The pipeline has built-in valves to perform standard Jetspeed processing such as customization, localization, and media-type mappings based on the incoming request parameters.

### Subscriber-based Delivery

The delivery rules and subsequent pipeline flow is configured on a per subscriber and per resource rule pairs. Whereas some subscribers may require transformations for a particular resource, others pairs may have different rules. Subscribers naturally map into the Jetspeed Security model as Jetspeed "Users" via the Portlet API's extensible User properties.

Subscribers can have their own delivery rules in order to control the frequency of delivery, the delivery mode (Push or Pull), delivery protocol (FTP/SMTP/HTTP), and transformation rules.

### Load-Balanced Engines

The Jetspeed Syndication Engine can run inside of a Jetspeed Web Application or in multiple web applications. Engines can be replicated on heterogeneous nodes across the network. Application Server requirements necessitate full support of the Java 2.3 Servlet Standard.

The engine is implemented as a servlet, optionally running inside the same container as one or more Jetspeed Portal server instances. The engine works as a dispatching servlet, including the generated content into the servlet response and sending it back to the agent.

Syndication Engines can be configured to share the workload across multiple nodes on a portal network. Workload sharing configurations are balanced in one of two ways:

1. By Subscriber Group. A engine will only deliver to one or more groups of subscribers

2. By Work Group. Two or more engines access the same queue of incoming requests.

The advantage of option 2 is that it provides fault tolerance; i.e., if one engine fails (for whatever reason), the other engines will continue to process requests located in the same work queue.

## Remote Portlets and UDDI Registries

The second phase of development will emphasize conformance to the new remote portlet standard from Oasis, (Web Services for Remote Portlets). Remote Portlet Web Services are visual, user-facing web service-centric components that "plug-n-play" with portals or other intermediary web applications that aggregate content or applications from different sources. They are designed to enable businesses to provide content or applications in a form that does not require manual content or application-specific adaptation by intermediate applications.

Since WSRP provides presentation, the service provider determines how content and applications are visualized for end-users and to which degree adaptation and translation are allowed.

Remote Portlets are published to the Jetspeed UDDI Registry. Universal Description, Discovery and Integration, or , is the name of a group of web-based registries that expose information pertaining to a business or other entity and its technical interfaces (or API's). These registries are run by multiple Operator Sites, and can be used by anyone who wants to publish information regarding one or more businesses or entities, as well as anyone who wants to discover that information.

By publishing remote portlets in the Jetspeed UDDI Registry, other portals can find portals through UDDI discovery and aggregate the remote portlet's content seamlessly.

## Glossary

portal

  A portal is a web-based application that provides personalization, single sign-on, content aggregation from different sources and hosts the presentation layer of information systems.

portal container

  A portlet container runs portlets and provides them with the required run-time environment.

portlet

  A portal may have sophisticated personalization features to provide customized content to users

portlet lifecycle

  A portlet is managed through a well-defined life cycle that defines how it is loaded, instantiated and initialized, how it handles requests from clients, and how it is taken out of service. This life cycle of a portlet is expressed through the init, processAction, render, and destroy methods of the Portlet interface.

portlet application

  A portlet application is a web application, as defined in Servlet Specification 2.3) containing portlets and a portlet deployment descriptor in addition to servlets, JSPs, HTML pages, classes and other resources normally found in a web application.

PSML

  Portal Structure Markup Language. It was created to allow content structure and abstraction within Jetspeed.

skins

  An aggregate of user-selected presentation styles, which normally includes such things as font style, font size, etc, that can be applied to a single portlet or multiple portlets.

WebDAV

  An acronym for "Web-based Distributed Authoring and Versioning". It is a set of extensions to the HTTP protocol which allows users to collaboratively edit and manage files on remote web servers.

Web application

  A collection of servlets, JSP pages, HTML documents, and other web resources which might include image files, compressed archives, and other data. A web application may be packaged into a web application archive ("WAR" file) or reside in an open directory structure. All compatible servlet containers must accept a web application and perform a deployment of its contents into their run-time. A container can run the application directly from a web application archive file or it may move the contents of a web application into the appropriate location for that particular container.

## Reference

API

  The Java Portlet API Standard

Avalon

  Jakarta Avalon

Cocoon

  Jakarta Cocoon

Catalina

  Jakarta Tomcat Servlet Runner

ECS

  Element Construction Set

J2EE

  Java 2 Platform Enterprise Edition

James

  Jakarta James

JSP

  Java Server Pages

Jetspeed

  Jakarta Jetspeed Home

Portlet API

  Java Portlet API Standard

Servlets

  Java J2EE Servlet Technology

Slide

  Jakarta Slide

Struts

  Jakarta Struts

Turbine

  Jakarta

Velocity

  Jakarta Velocity