Jetspeed-2 Overview

Jetspeed-2 David Sean Taylor Jetspeed-2 Enterprise Portals

Portal Integration Framework Jetspeed is an OPEN SOURCE application-integration portal framework. If you already know Spring, you can easily get started customizing your portal to your own needs. Jetspeed is entirely constructed with Spring components based on interfaces: the Jetspeed API. All aspects of the portal are configurable, including security, registries, preferences, and the core aggregation engine. Portal Integration is about customization on a solid, open framework. Customization of the portal framework is a matter of putting in your implementation at the correct integration point. Customization of the user experience is accomplished with a flexible portal personalization engine, and with deployable units of markup. All access to the portal must be secured .

Jetspeed-2 Portal Framework Design Goals Standards and Specifications Fully Compliant with Java Portlet API Standard, pass TCK WSRP-4J support (2.1) Leverage Java Security, JAAS Security Components LDAP Open Source and Portability Based on Open Source Libraries such as Jakarta Commons, Spring, OJB Run on Open Source Application Servers Component, Container Based Architecture Integrators assembly components with Spring configurations Light weight containers working on POJOs Configurable Pipeline-based Request Processing Scalability, Portability and Performance Multi-threaded Portlet Aggregation Engine Scalable Cluster Architecture (2.1)

Framework Design Goals (continued) Portal Framework Separation of Portlet Applications from Portal Live Deployment Model for Portlet Applications and Portal Layouts Interface Driven Integration Jetspeed API: component-based interface API All parts of the portal can be wired together by Jetspeed API contract Security Authentication APIs Authorization APIs JAAS Policy Support Security Constraints SSO Easy to Use, Customizable Localization Ready

Standards and Specifications Specifications – Jetspeed works with Java J2EE standards, Oasis, and WC3 standard specifications where applicable, most notably the Java Portlet API, along with providing its own specification essential for component interoperability. The Portlet API – The Java Standard Portlet API is the specification dictating how Jetspeed runs portlets and portlet applications in the portal. It is the contract between portlets and the portlet container. The Jetspeed Component API – Jetspeed provides a clear API for writing components that work inside the Jetspeed Component Portal Architectural. The Jetspeed Component API provides the contract between the portal and the component implementations. WSRP (OASIS) – not supported until 2.1+ JAAS Security – support Java Security policies, integrated support with Java Login Modules

JSR 168: The Java Standard Portlet Spec 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 supports the JSR 168 standard. This is an important initiative, introducing true portlet portability. Jetspeed-2 has passed the TCK (Test Compatibility Kit) suite and pending full CERTIFICATION to the Java Portlet Standard.

Software Architecture Design Concepts Jetspeed is founded on the following core Software Architectural Design concepts: Interface Driven Development – the Jetspeed API Lightweight Containers and Component Oriented Programming based on the Spring Framework Inversion of Control with Spring Containers Aspect-Oriented programming POJO Assembly and Dependency Injection Pipeline Driven Processing Aspect Oriented Programming Separation of Concerns: Portal vs Portlet Applications Frameworks 100% Open, Standardized Open Source Solutions

Jetspeed-2 Configurations Jetspeed-2 is built entirely of components. With these components, the entire portal is assembled together at runtime. Jetspeed is built upon a set of portal components, allowing the application assembler to use the standard Jetspeed components, or plug-in their own components. Of course Jetspeed-2 comes with a default assembly out of the box. As Jetspeed-2 progresses, several implementations of components will be available. For version 2.1, we are working two configurations : Jetspeed Light – a light weight implementation of Jetspeed with no container managed security. One self-contained web application running in Jetty. Jetspeed Enterprise – the full portal

Component Programming As of this writing, there is a revolution, or perhaps a reaction, to the heavy-weight complexities of the J2EE world. This revolution is going on right here in open source communities. The common trend is lightweight component frameworks for wiring together and managing components. Two marginally successful lightweight component frameworks are Pico Container and GBeans. The real success story is the Spring Framework. Interestingly, these component frameworks impose little or no requirements upon the components, meaning that POJO (Plain Old Java Objects) can be components. This lack of imposing framework requirements, is simple, yet leads to powerful portability possibilities. For example, the Pico and Spring frameworks are now available for Microsoft's .Net.

Spring Spring is also an open source project; however it is not housed at Apache. Spring is a unique Java application framework meant to simplify develop applications. Where as Enterprise Java Beans are very complex to use, the Spring Framework is an easy to use and understand framework for business applications. Spring focuses on: 1. Providing a simple way to manage Business objects lifetime and relationships 2. A layered architecture. Spring is comprehensive yet modular. You only use what you need. For example, you may only make use of the JDBC support without linking in an entire framework. 3. Promoting best software development practices. For example, Spring is designed to always promote test-driven development and eliminate the need for factories and singletons. 4. Inversion of Control. Spring is an application container supporting interceptions and declarative aspect oriented programming.

Inversion of Control: Spring containers 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 the component container. This pattern provides a secure method for components to interact with the container. This design pattern addresses a component's dependency resolution, configuration and life cycle. The most significant aspect to IoC is dependency resolution and most of the discussion surrounding IoC dwells solely on that. “ Simply put, a component designed according to IoC does not go off and get other components that it needs in order to do its job. It instead declares these dependencies, and the container supplies them: thus the name IoC/DIP/Hollywood Principle. The control of the dependencies for a given component is inverted. It is no longer the component itself that establishes its own dependencies, but something on the outside. That something could be a container like Spring, but could easily be normal code instantiating the component in an embedded sense.” Paul Hammatt, PICO

Jetspeed + Spring Jetspeed currently works with one lightweight component container framework: Spring. The Jetspeed-2 team is also looking into running Jetspeed components inside of the Geronimo GBeans component framework. The importance is that both Geronimo and Spring are COP container frameworks, supporting component assembly, configuration, and component container features such as: Decorators – or interceptors, for AOP-like chained method interception Hot swapping – allows implementation hiding and swapping Failover – failover to next component when a component fails Multicasting – multicasting of method invocation to multiple components Lifecycle management – starting, pausing and resuming components

Components run in a Spring Container Jetspeed is a collection of components, all assembled together to create a complete working portal. If you look at from this point of view, you can see the major portal components being managed by the container, which is really just a Spring container:

Jetspeed API The Jetspeed API – Separation of Interface from Implementation Jetspeed provides the interfaces to all portal components with the Jetspeed Portal API. The implementations are separated in the component modules. All components introduced to Jetspeed should become a part of the API, allowing for pluggable component implementations. Components always have their dependencies constructor (or getter) injected via interfaces, not implementation references.

Programming to the Jetspeed API Jetspeed Components always program to the Jetspeed API. First, their dependencies upon other Jetspeed components are always injected . Dependencies are declaratively managed in the Spring configuration. In Jetspeed, we support both constructor and setter dependency injection. Here is an example of a component having its dependencies constructor-injected :

Dependency Injection (Constructor) Constructor Dependency Injection is a type of dependency injection where a component receives all dependencies in the component's constructor. The benefits of Constructor Injection are: 1. It makes a strong dependency contract 2. It makes testing easy, since dependencies can be passed in as Mock Objects. 3. It's very succinct in terms of lines of code 4. Classes that rely on Constructor Injection are generally Good Citizens A dependency may be made immutable by making the dependency reference final

Wiring in XML to the Jetspeed API The Spring configuration, wiring, or injecting, dependencies in XML constructor. Note that referenced beans are by Jetspeed API interface, not implementation.

Pluggable Components and Jetspeed API LDAP User Manager Jetspeed API User Manager Role Manager Component Implementations RDBMS User Manager Custom User Manager

Component API Bus Jetspeed API User Manager Statistics Portlet Registry Page Manager SSO Aggregator Component Implementations

Spring XML Component Construction <bean id ="TemplateLocator" class ="org.apache.jetspeed.locator.JetspeedTemplateLocator" init-method ="start" destroy-method ="stop" > < constructor-arg > < list > < value >${applicationRoot}/WEB-INF/templates</value> </ list > … Id = the interface or component (bean) name Class = the implementation class Init-method = a method on the class called during container’s init phase Destroy-method = a method on the class called during container’s destroy phase list = Spring XML supports wiring standard Java collections and data types such as lists, maps, sets, properties

Example of Injecting Dependencies Example of Injecting Dependencies during Assembly of Component:  <bean id= "org.apache.jetspeed.aggregator.AsyncPageAggregator" class= "org.apache.jetspeed.aggregator.impl.AsyncPageAggregatorImpl" > <constructor-arg index= '0' > <ref bean="org.apache.jetspeed.aggregator.PortletRenderer" /> </constructor-arg> <constructor-arg index= '1' > <ref bean="org.apache.jetspeed.aggregator.ContentServerAdapter" /> </constructor-arg> </bean>

The Constructor public class AsyncPageAggregatorImpl implements PageAggregator { private final static Log log = LogFactory.getLog(AsyncPageAggregatorImpl.class); private PortletRenderer renderer; private ContentServerAdapter contentServer; private List fallBackContentPathes; public AsyncPageAggregatorImpl( PortletRenderer renderer , ContentServerAdapter contentServer ) { this.renderer = renderer; this.contentServer = contentServer; }

Transactions and Interception Interception begins and commits transaction: grantPermission User Registration Portlet Permission Manager storeUser Spring TX Proxy BEGINTX JOINTX User Manager COMMIT TX

Declarative Transaction via Interception

Jetspeed Components All Jetspeed components are configured and wired together in a collection of XML files found under the Jetspeed web application directory: WEB-INF/assemblies. There are quite a few XML files there, as we like to break down the assembly of components by category, making it easier to override component assemblies by simply replacing the component-specific XML file. Jetspeed runs with 2 Spring containers: The boot container The default container The boot container holds all components that are required to be loaded before any other components. The data source component is loaded here.

The Jetspeed Engine The Jetspeed Engine starts up the Jetspeed portal. We usually embed the engine inside of a servlet, giving us the standard MVC model. We have also embedded the Jetspeed Engine into several other open and closed source solutions including: Jetspeed Fusion – running Jetspeed-2 engine inside of Jetspeed 1.6 giving 1.6 JSR-168 support via a Jetspeed-2 engine Jahia Portal The real job of the engine is to: Create an integration point for embedding Jetspeed into other technologies Provide entry point for pipeline-based processing Abstract the concept of a Spring light weight container with the Component Manager Provide basic lifecycle management of the Jetspeed portal

Jetspeed Engine bootstrap The Jetspeed Servlet is configured in the portal application web.xml to load at startup. The engine bootstraps the Spring configuration. engine = new JetspeedEngine(properties, applicationRoot, config, initializeComponentManager(config, applicationRoot, properties));

Pipelines Jetspeed-2 Pipelines are based on the inversion of control pattern. The request processing pipeline is assembled to run in the Spring container. A portal is largely driven by a request/response processing data flow, much like the servlet or HTTP request/response paradigm. Requests are made by client agents such as HTML or WAP browsers, and the portal processes the request on the thread provided by the application server for which Jetspeed is running. Request processing is achieved in a workflow like pipeline, where valves are plugged into the request pipeline. The workflow of the valves is configurable just like any other Spring component. Pipelines reference (via Spring constructor based dependency) one or more valves. Valves are also Spring components.

Pipeline Driven Processing Requests to the portal always come in via a Portal URL. Jetspeed has URI entry points. The servlet context (/jetspeed) is also easily configurable. Additionally, the request URL can be mapped to a portlet pipeline. The default pipeline aggregates portlet pages. Portlet pages are usually defined with the extension .PSML. If a page is not supplied, default pages can be configured. Jetspeed Portal Request to: /jetspeed/portal/home.psml Page Pipeline Portlet App #1 Portlet App #2 Portlet 1A Portlet 2A Portlet 2B Portlet1A Client (browser) Page Dispatcher Portlet2A Portlet2B Portlet 1B Portlet1B

Pipeline Architecture In Jetspeed-2 request are processed through a series of Valve assembled together as a pipeline.

Jetspeed Render (Page) Pipeline 1. Render Pipeline - The default Jetspeed request pipeline. This pipeline processes the render phase as defined in the Portlet API specification. It does the typical aggregation of content rendered by each portlet.

Action Pipeline 2. Action Pipeline – This pipeline processes the Action phase as defined in the Portlet API specification. Only one portlet may execute the action phase. All other portlet rendering threads are blocked during the action phase.

Desktop Pipeline 2. Desktop Pipeline – This pipeline processes the Action or Render phase for the Jetspeed Desktop. The Jetspeed Desktop is a AJAX based, client-rendering (Java-script) implementation of a JSR-168 portal. Portlets are rendered individually, as opposed to a full page rendering engine such as the Page Pipeline. If you have n portlets on a page, during the initial rendering of a desktop page, n desktop pipeline requests will be made. However, if you go to render just one portlet, other portlets will not be rendered unless their cache has expired. For actions, all one action request is made, and then n render requests are made for each portlet on the desktop. This leads to a more distributed rendering engine. However, it may put higher load on your network.

Portlet Pipeline 3. Portlet Pipeline – This pipeline is used to render the contents of a single portlet. This pipeline is used by several portal vendors to embed JSR-168 support in their portal via Jetspeed-2 technology. It is the foundation for the Desktop pipeline. The portlet pipeline is also embedded in Jetspeed 1.6 (Fusion) to give JSR168 support to Jetspeed 1.6 portals.

AJAX Pipeline The AJAX Pipeline processes AJAX requests. We are developing an AJAX XML API for Jetspeed-2, to process requests for AJAX customizers such as portlet layouts and portlet placement. (Note that security should be enabled) The AJAX pipeline hooks into an AJAX service, which can then delegate to AJAX actions. These action build XML response packets (with Velocity and Java Beans) which are sent back to the AJAX client.

File Server Pipeline Retrieves requests for a particular file, using portal security. Requests can be mapped here for non-PSML file types automatically such as /jetspeed/portal/content/story.html

Pipeline Mappings Pipelines mappings allow for prefixed mappings of /context path + servlet path to be mapped to a pipeline. For example: /jetspeed/portal --> Jetspeed Pipeline /jetspeed/ajax --> Ajax Pipeline /jetspeed/portlet --> Portlet Pipeline /jetspeed/fileserver/file.pdf --> File Servlet Pipeline /jetspeed/fileserver.file.html --> File Servlet Pipeline /jetspeed/desktop -  Desktop Pipeline

Pipeline Mapping Configuration

Pipeline Examples /jetspeed/portal /jetspeed/desktop

Pipeline Examples (continued) /jetspeed/portlet

Valves and the Request Context Valves are units of work along the pipeline workflow. Typically valves represent access to a Jetspeed feature or component, such as aggregation, security, action processing, or device capabilities. The Jetspeed Pipeline has a request context associated with the entire request pipeline. Using the Request Context API, valves can add or retrieve bits of information to the pipeline request process. Pipeline Profiler Valve Request Context Set Page Aggregator Valve Get Page

Pipeline Valves Identifies the Capability Map, character encoding, media and Mime types for the browser to the Request Context, sets the content type in the response. Capabilities Valve Creates the internal Portal URL from the request URL and parameters using the Navigational State component Portal URL Valve Builds the Java Security subject for the request, and runs all remaining valves for this request under a privileged action, enabling Java Security checks against the default Jetspeed (JAAS) security policy, or, if configured, another standard JAAS policy. Security Valve Sets the Locale (java.util.Locale) into the request context for Java standard internationalization support Localization Valve

Pipeline Valves (continued) Uses the Profiler, Site Manager, and Page Manager components to locate the requested page and menu ‘site’ navigations Profiler Valve Determines the targeted action window in the request, if found, executes the action via the portlet container. This is the standard “ action phase ”, blocking all rendering. At completion of the action phase, the action valve redirects back to the portal to process the render phase. Action Valve Builds the actions available on the page and all portlet windows Decorator Valve Executes the standard “ render phase ”, where the actual rendering of all portlets and page decorations occurs. Aggregator Valve

Pipeline Valves (Desktop) Renders the skeleton of the Jetspeed Desktop. All desktop portlet rendering is controlled on the client side, with javascript and the portlet pipeline Desktop Valve Executes Jetspeed Desktop actions over the span of one request. The client-side desktop controls the execution of the action phase, and then the subsequent render phases, achieving parallel processing from the client-side. Desktop Action Valve

Jetspeed Components: Core Engine Wrapper around Pluto Container to enable Spring configuration of Pluto DesktopPortletContainer Wrapper around Pluto Container to enable Spring configuration of Pluto PortletContainer The Pluto portlet container for the desktop (requires different action handling) DesktopPluto The Pluto portlet container Pluto Handles all access to portlet windows. Portlet windows are temporary objects representing a portlet and its preferences for a particular window or fragment PortletWindowAccessor The Jetspeed Engine (not configured in Spring. The Jetspeed bootstrap servlet adds the engine to the Spring container) Engine

Jetspeed Components: Core Engine Handles caching of PSML files Page File Cache Generates Unique Ids for pages and fragment IdGenerator The Jetspeed Power Tool factory Powertools Handles algorithms for locating language, country, media-type specific decorations DecorationLocator Handles algorithms for locating language, country, media-type specific Jetspeed web application templates (JSP, Velocity) TemplateLocator Wire in the Servlet configuration from the Jetspeed servlet webapp javax.servlet.ServletConfig Wire in global properties configuration from a file portal_configuration

Jetspeed Components: Core Engine Alternative property configuration for production systems ProductionConfiguration Allows components to participate in the creation of the <HEAD> markup, supplying scripts and CSS into the header area. (NOTE: a header phase will be added to the Portlet API 2.0 spec) HeaderResourceFactory Request Context Factory RequestContextComponent

Administration Velocity engine for merging emails adminVelocityEngine Spring email component mailSender Provides general purpose portal administration functions: Send emails Find a user given an email Register New Users PortalAdministration

Aggregation Handles the “ render phase ” of the Portlet API, aggregating content of all portlets and decorations on a page PageAggregator Renders single portlets from all pipelines PortletRenderer Handles aggregation processing of single portlet requests from the portlet pipeline PortletAggregator

Ajax Actions AjaxChangeWindow AjaxGetPages AjaxGetPage List is growing, under development AjaxGetPortlets AjaxRequestService AjaxRemovePortlet AjaxGetMenu AjaxAddPortlet AjaxGetMenus AjaxMove*

Jetspeed AJAX XML API The Jetspeed XML AJAX API – an XML-based API for AJAX clients to make asynchronous requests to Jetspeed-2 services. Typical usage: Page Customization and Portlet Placement (move/add/remove Portlet) Layout Selection (change layout for a page) Decorations – select decorators for a portlet or page Portlet Selectors Security Configuration for a Portlet or Page Menu Configuration Page Ordering in a Folder

AJAX APIs and Security AJAX APIs are secured just like any other portal request. The security is the same Jetspeed security as used to protect your portal. For example, requests for page content use the same page security constraints as would be applied to rendering a page. Likewise for portlet security permissions.

Capabilities Jetspeed-2 capabilities provides a mechanism for mapping the client used to access Jetspeed-2 to media types for page rendering. The Jetspeed-2 capability engine maps clients to media types to mime types. Here are some more detailed definitions: Clients : The application that initiates a request to the Jetspeed-2 portal engine. Jetspeed-2 uses the User-Agent to determine the client that initiates a request. Media Type : The type of media requesting the content (HTML, WML, etc.). Content in Jetspeed-2 can be requested by different type of devices through different media. Mime Type : The type of content being requested. Supported Media Types: HTML, XHTML-BASIC, XML, WML, VXML

Deployment Deploying custom portlets in Jetspeed-2 is simple. Portlets are very similar to servlets. They require a deployment descriptor, portlet.xml which goes in WEB-INF and need to be packaged in a war-like format. In order to deploy a portlet, Jetspeed-2 requires the user to follow those steps: 1. Build your portlets as a portlet application just as you would a web application. 2. Package your portlet application into a .war file. 3. Copy the .war file to Jetspeed's deployment directory, by default this is WEB-INF/deploy. Jetspeed will take care of automatically deploying the portlet application into the application server, and then registering the portlets into the portlet registry. You can also copy over a portlet-application’s web.xml or portlet.xml to cause re-registration of the portlet application.

Deployment (continued) The Deployment Manager is configured with the properties specified in WEB-INF/conf/jetspeed.properties (this should probably change) autodeployment.staging.dir: The directory scanned for autodeployment. autodeployment.delay: The frequency of the deploy directory scanning.

Deployment (continued) The DeploymentManager is also configured with 2 types of listeners: The DeployPortletAppEventListener handles the hot deployment of portlet applications . The DeployDecoratorEventListener: handles the hot deployment of decorators .

Portlet Application Management Handles lifecycle of portlet application, including registration: startPortletApplication stopPortletApplication registerPortletApplication unregisterPortletApplication PortletApplicationManager (PAM) Currently only Tomcat 5.5.x and 5.0.x supported. (Working on Jetty support.) Provides hooks into the application server to help us deploy portlet applications as web application into that server. ApplicationServerManager

Other Application Servers and the Deploy Tool Websphere, JBoss, Weblogic requires App-server specific deployment. With Websphere for example, we have to package up the portlet applications into an EAR file, which takes specific deployment tools for Websphere (or using the Websphere administrative UI). Since the portlet applications are not deployed into the Jetspeed Deployment Manager, instead we must infuse registration code into the portlet application before it is packaged and deployed to Websphere. Jetspeed provides a Deploy Tool to run during the build process of your portlet application: java -jar jetspeed-deploy-tools-<version>.jar -s inputWarPath outputWarPath where: -s: flag indicating whether or not to strip to loggers from the application. When the flag is present, the loggers available in the application will be removed. inputWarPath: the path of the war to process. outputWarPath: the path of the processed war.

Deploy Tool changes to web.xml The deploy tool adds the following servlet to your portlet application. This servlet allows Jetspeed to communicate with your portlet application to invoke cross-context portlet phases (action, render). Additionally, the deploy tool instructs the servlet to attempt to register this portlet application during the servlet initialization phase. A check-sum value on the portlet.xml, web.xml, and jetspeed-portlet.xml for changes, determining if re-registration is necessary.

Deployable Applications The Portal and Portlet Applications are implemented as separate web applications. Jetspeed runs as a MVC-Controller-type servlet, running in a standalone web(portlet) application. Each portlet application runs in its own web application. The Portal then dispatches to portlets using cross-context invocation Application Server Jetspeed Portal Portlet App #1 PA WAR #1 PA WAR #2 Portlet App #2 Portlet Registry Deploy Deploy Register-> Register-> Jetspeed Cluster Clustered App Servers [JSR-88 J2EE Deployment]

Jetspeed and Cross Context Concerns The Portlet API strongly suggests that all portlet applications are each stored in different web applications. This means that parts of Jetspeed must exist in common class loaders shared amongst all web applications in the application server. Tomcat Application Server Shared Lib: Jetspeed-API jar Pluto JAR Jetspeed Commons Bridges Commons Jetspeed Webapp * Jetspeed Implementation Portlet Application #1 Portlet Application #1 PA #1 Class Loader PA #2 Class Loader

Local Portlet Applications Local Portlet Applications are deployed directly into the Jetspeed web application and class and jar files are stored under the WEB-INF/apps directory. Resource files, such as HTML, CSS, images and JSP, must be stored in Jetspeed’s web application directory structure. The downside is that collisions of resource files from different web applications is possible. Class loader concerns are handled by Jetspeed correctly. Advantages of this approach: ‘ Jetspeed Lite’ solutions: deploy Jetspeed in one simple WAR file. As of 2.0 and 2.1-dev, only Jetspeed layouts are deployed locally.

Pluto Pluto is the Reference Implementation of the Java Portlet Specification. The current version of this Portlet specification is 1.0. Portlets are designed to run in the context of a portal. They are written to the Portlet API. Pluto implements the contract, the Portlet API, between portlets and portals. Pluto is a portlet container. Jetspeed embeds Pluto into the Jetspeed portal. Pluto is the default Container component in the Spring assembly, it is just another component.

Pluto API: Portal to Portlet-Container Interface The Pluto API is currently a set of not-so-well documented interfaces in Pluto. These interfaces can be categorized into the following groups: 1. Container Invoker APIs - provides ability to render portlets and perform actions on portlets. 2. Container Services APIs - provides a way to enhance the portlet container with services implemented in the portal. 3. Common Object Model APIs - provides a common object model to the Portlet API model defined by the portlet specification's deployment descriptor, and used by Pluto and Jetspeed as a common object model to share portlet applications, portlet descriptions, and portlet entity information between the portal, container, and the portal's persistent registry. 4. Factory APIs - Allows the entire container implementation to be plugged in and implemented by the portal, or default to the Pluto implementations The goal is for Jetspeed and Pluto, through the open source community, to pave the way for a standardized portal to portlet container API.

Pluto Spring-ized org.apache.pluto.util.NamespaceMapper org.apache.pluto.invoker.PortletInvoker InformationProviderService StaticInformationProvider DynamicTitle Service LogService ServletResponseFactory ServletRequestFactor javax.portlet.PortletPreferences javax.portlet.PortletURL javax.portlet.ActionResponse javax.portlet.PortalContext javax.portlet.PortletContext javax.portlet.PortletConfig javax.portlet.PortletSession javax.portlet.RenderResponse javax.portlet.RenderRequest javax.portlet.ActionRequest ServletPortletInvokerFactory LocalPortletInvokerFactory

Navigational State Navigational state holds: All portlet Request Parameters for all portlets Windows states for all portlets on the current page Portlet Modes for all portlets on the current page Jetspeed supports several algorithms for encoding Nav state: PathNavigationalState : All fully encoded on URL: SessionNavigationalState : Only portlet window state (window state and portlet mode) are saved in the session, parameters are encoded on the url SessionFullNavigationalState : State and parameters are saved in the session ( the default ) See portal-url-generation.xml for full Spring configuration

Transitional Navigational State Transitional navigational state can be seen encoded on the URL. Here is an example: http://localhost:8080/jetspeed/portal/_ns:YWRwLTd8YzB8ZDB8Zg__/

Portlet Preferences Component Portlet Preferences are a feature of the Portlet API for providing a custom view or behavior of portlets for different users. The configuration is represented as a persistent set of name-value pairs. Jetspeed handles are persistence and retrieval of portlet preferences. The Jetspeed Preferences component stores its preferences in a relational database. All Jetspeed database access is done through Spring + OJB. Programming with portlet preferences will be covered in the section on the Portlet API (JSR-168).

Java Preferences API The Java Preferences API (java.util.prefs) provides a generic mechanism for storing user and system preferences, as well as configuration data. Jetspeed 2 relies on this API to provide a wide ranging of functionality to higher level services. Some of the Jetspeed components leveraging the Preferences API are: 1. Portlet Preferences : Portlet preferences are stored in the system preferences tree. The following path structure is used to establish the location of a given portlet preference in the preferences tree: /portlet_application/${PortletAppName}/portlets/${PortletName}/preferences/${Pref Name}/values The preferences values are stored under the values node as a map of key/values. 2. User Attributes : User attributes are stored in the user preferences tree as follows. The following path structure is used to stored a user's attributes: /user/${User Name}/userinfo The user attributes are stored as a preferences key/values map under the userinfo node. 3. Roles and groups hierarchy

Preferences Database All Preferences are stored in the following two database tables:

Portlet Registry The Portlet Registry persists the entire contents of the portlet deployment descriptors in the Jetspeed database: portlet.xml jetspeed-portlet.xml (Jetspeed-specific extensions) When a portlet application is deployed, Jetspeed updates the registry with the definitions defined in these portlet descriptors including: One Portlet Application definition One or more portlet definitions Supported User Attributes Supported custom portlet modes and window states Details of the portlet.xml will be covered in more detail in the section on JSR-168 (Portlet API).

Portlet.xml Portlet Name, description, display name Implementing class Init Parameters Supported Mime Types / Modes Supported Locales Resource Bundle Information / Localization (titles, keywords) Default Portlet Preferences

Jetspeed-Portlet.xml We allow for extended metadata to attribute portlets and portlet applications. This metadata conforms to the "Dublin Core" DCMI format: http://dublincore.org/ DCMI allows for extended metadata such as subject, contributor, language, publisher, relation, …) Map user attribute names to other attribute names Define Jetspeed Services used by this portlet.

Jetspeed Services Jetspeed provides a way for portlets to access Jetspeed components, or services, from a portlet. Although this is a Jetspeed-specific feature, it is how Jetspeed Administrative portlets can work with customizing Jetspeed. For example, the Group Administration portlet below uses a Jetspeed service to manipulate Jetspeed groups. All services must be exported by Jetspeed in the jetspeed-services.xml file. All services required by a portlet must be specified in the jetspeed-portlet.xml

Jetspeed Services defined in Spring

Jetspeed Services (cont.) Portlet applications requiring a jetspeed service must define it in their jetspeed-portlet.xml deployment descriptor: <js:services> <js:service name= 'ApplicationServerManager' /> <js:service name= 'PageManager' /> <js:service name= 'PermissionManager' /> <js:service name= 'PortalAdministration' /> <js:service name= 'UserManager' /> </js:services>

Jetspeed Services And then get the service in the portlet init phase: groupManager = (GroupManager) getPortletContext().getAttribute( CommonPortletServices. CPS_GROUP_MANAGER_COMPONENT);

Managing the Registry Jetspeed provides two portlets for managing the Portlet Registry: 1. Portlet Application Browser 2. Portlet Application Details

Managing the Registry, Details

Search Component Jetspeed-2 provides an integration with the popular Apache Lucene search engine, a high-performance, full-featured text search engine library written entirely in Java; a technology suitable for nearly any application that requires full-text search, especially cross-platform.. By default, Jetspeed-2 indexes all registry information: portlet instances and portlet definitions as searchable entities.

User Information (Attributes) The Portlet API defines an interface for providing user information to portlets. Portlets can access this user information via the portlet API: User information can be edited with the User Manager portlet Map userInfo(Map) request.getAttribute(PortletRequest.USER_INFO); String givenName = (String)userInfo.get("user.name.given"); String email = (String)userInfo.get("user.home-info.online.email") ;

Profiler The Jetspeed Profiler is a portal resource location rule-based engine. The profiler locates the following kinds of portal resources: PSML pages Folders Menus When a request is received by the portal, the profiler will map the request to a resource based on a normalized set of runtime parameters and state such as request parameters, HTTP headers, and session attributes. The Profiler is invoked during the Jetspeed request processing pipeline in the profiler valve. This valve requires that the request context is already populated with the portal request and response, capabilities, language and user information. The runtime parameters make up the profile criterion which the profiler uses to locate portal resources. The profiler works hand in hand with the Site and Page Manager components.

Profiler Rules and Rule Criteria A Profiling Rule defines a list of criteria used when evaluating a request to determine the location of a specific resource. Profiling rules are used by the profiler to generically locate portal resources based on the decoupled criteria for known portlet request data. A rule consists of an ordered list of criteria which should be applied in a given order. Following this rule's order, the profiling engine applies each criteria of the rules using a less-specific algorithm until the least specific resource criterion is considered. When all criteria are exhausted, the rule will fail and a fallback resource will be required. Rule Criteria are templates for locating profile properties. Jetspeed has a profiling policy based on resource-specific URLs, Mime-Types and language preferences. More complex implementations will need to use other inputs in mapping to resources such as Cookies, IP Address Ranges, Statistical Resource Usage Analysis, Business Rules inside of servlets or EJBs,...

Rule Criterion Resolvers Resolvers are Java classes that try to match criteria to find resources

Directories of PSML Pages The Profiler searches over a directory tree of PSML pages trying to locate a PSML page to be displayed. By default, this directory structure is found under WEB-INF/pages . The ‘directory’ can also be stored in the database. There are several system directories known by the profiler: _user – holds all user-specific pages 2. _role – holds all role-specific pages 3. _group –holds all group-specific pages 4. __subsite-root – contains complete subsite trees, exactly like root tree

Common Profiler Rules Provided J1 – uses a most-specific to least-specific algorithm from Jetspeed-1 Page-Path + User + Media Type + Language + Country J2 – Default. Looks at the URL path combined with User + Media Page-Path + User + Media Type Role Fallback - Look for page in each role dir for the given user User-Role Fallback – Look for page in user’s home dir, if not found, look in each role dir for the given user Variants: Path, Group Fallback, User-Role-Combo Fallback, Subsite-Roll Fallback

A Path-MediaType Role Fallback Example Path Profiler Media Type Page Role Fallback Repeat over each role for user

Profiler Rule Example Path : /my-page.psml Profiler Roles : Admin, Tester /roles/admin/html/my-page.psml Media : HTML, XHTML Page Manager Profile Locator

Page Manager The Page Manager persists and secures access to pages. Pages are the basic resource for storing one or more portlets for viewing. By default, pages are stored on the file system in the web application under WEB-INF/pages. This location should be moved in production systems. See page-manager.xml for changing this configuration. The File System Page Manager will scan for new PSML every 10 seconds (configurable) There is a second Page Manager implementation, the Database Page Manager. This alternate Page Manager stores all data in a relational database. To use the Database Page Manager: 1. Run the database importer to import PSML into the database 2. Swap the assembly/alternate/db-page-manager.xml with the file system version NOTE: you can also export out from the database to the file system.

Security and the Page Managers The Page Managers support two kinds of security: Permission Security (Java Security Policy) Constraints Security (PSML Constraints) In the page manager’s Spring configuration, you can enable either one of these, or turn them both off (not recommended) Example Security Constraint: <security-constraints-def name="manager"> <security-constraint> <roles>manager</roles> <permissions>view</permissions> </security-constraint> </security-constraints-def>

Jetspeed Database The Jetspeed Database is configured in Spring under : WEB-INF/assembly/boot/datasource.xml By default, we use Spring to configure a JNDI data source. This data source needs to be configured on your application server. <bean id=" JetspeedDS " class="org.springframework.jndi.JndiObjectFactoryBean"> <property name="resourceRef"><value>false</value></property> <property name=" jndiName "> <value> java:comp/env/jdbc/jetspeed </value> </property> </bean>

Tomcat’s JNDI JDBC Configuration Jetspeed creates a Tomcat context file for the Jetspeed web application and deploys it to Tomcat automatically. This context file holds the JDBC configuration for the database used by Jetspeed internally. Note in our example below, we have renamed the default Jetspeed context to “/fep”. The Jetspeed custom build automatically handles context renaming.

OJB OJB, the Object Relational Bridge, is an object-relational mapping tool from the Apache Software Foundation. All database access in Jetspeed runs thru OJB. Mapping is controlled with a simple XML mapping file, which tells OJB how to map from database tables to Java classes. Each component in the system has its own OJB mapping file. It can be found in the component’s jar under the JETSPEED-INF directory. Here is an example mapping :

OJB Support OJB supports the most popular open source and proprietary databases. OJB will automatically figure out which database is in use by looking at the JDBC data sources metadata. OJB is a powerful object-relational tool supporting associations such as one to many, and mapping those associations to Java Collections. You can also set associations to be auto-retrieved or lazy-loaded.

Supported Database and Torque The Torque project is another database project from Apache. It is used to generate database specific schema for your portal. This is done by simply setting a property, and then using the Jetspeed custom build to build your custom portal with proper database support. By default, Jetspeed now uses the Derby database. Although OJB and Torque support more database, the list of supported and tested databases with Jetspeed are: Oracle MySQL Microsoft SQL PostgreSQL DB2 Hypersonic Derby

XML Torque files Torque uses XML files to generically define the database definitions (DDL), table and indexes: <table name='PORTLET_STATISTICS'> <column name='IPADDRESS' type='VARCHAR' size="80"/> <column name='USER_NAME' type='VARCHAR' size="80"/> <column name='TIME_STAMP' type='TIMESTAMP'/> <column name='PAGE' type='VARCHAR' size="80"/> <column name='PORTLET' type='VARCHAR' size="255"/> <column name='STATUS' type='INTEGER'/> <column name='ELAPSED_TIME' type='INTEGER'/> </table>

Database Population Scripts The database population scripts are still specific for each supported database. Because of the non-standard-ness of the SQL standard, we need to have different seed population scripts for each database flavor. A lot of the population scripts that come with Jetspeed out of the box may not be applicable in your portal, such as the default roles and groups and administrative users. We hope to phase out SQL population scripts in version 2.1

Jetspeed XML Jetspeed XML and the Jetspeed Serializer component will phase out database population scripts. Jetspeed XML is an XML format for importing and exporting Jetspeed data such as: Users User Information Roles Groups Profiling Rules and Criterion Permissions Note: Jetspeed serialization is still under development at this time

Websphere configuration Websphere requires a special configuration: WEB-INF/assembly/wps.xml <beans>  </beans> The Portal Request Factory is replaced with Websphere because of the way that Websphere 5.x derives the context path during cross-context requests to render portlets.

Jetspeed Security Jetspeed 2 security leverages J2EE authentication and authorization standards for both authentication and authorization through the implementation of a default Login Module and a default Authorization Policy . Authentication establishes the identity of the user and populates the Subject with all the user principals. In a portal context, the populated Subject is added to the session in the Security Valve implementation. The Subject principals are then used to authorize the user's access to a given resource. Jetspeed Security leverages JAAS authorization by checking the user's permission with the Java Access Controller. The Authorization policy is a standard Java Security Policy. The Jetspeed implementation of this policy a RDBMS policy, stored in the Jetspeed database.

Jetspeed Security Layers Jetspeed Security can be accessed at the Java API layer: the JAAS API We implement both a Login Module and Security Policy Jetspeed Security Managers are configured in security-managers.xml Security managers are high-level APIs, used to manage users, roles, groups and permissions Jetspeed provides a Security Service Provider Interface ( SPI ) for layered handlers of security services. See the security-providers.xml and security-spi-*.xml

JAAS Login Module Configuration Jetspeed security architecture is fully JAAS compliant. Integrators can replace Jetspeed security architecture with their own LoginModule and Policy implementation. To configure the login module, edit security-atn.xml. The Login Module proxy bootstraps the Login Module into the Spring initialization life cycle. You can disable Jetspeed’s login module by removing this file in your deployment. <bean id="org.apache.jetspeed.security.LoginModuleProxy" class="org.apache.jetspeed.security.impl.LoginModuleProxyImpl" > <constructor-arg index="0"> <ref bean="org.apache.jetspeed.security.UserManager"/></constructor-arg>  <constructor-arg index="1"><value>portal-user</value></constructor-arg> </bean>

JAAS Security Policy Configuration The JAAS Security policy is implemented as a RDBMS security policy. It bootstraps during the Spring initialization life cycle. You can disable Jetspeed’s security policy by removing this file in your deployment.  <bean id="org.apache.jetspeed.security.impl.RdbmsPolicy" class="org.apache.jetspeed.security.impl.RdbmsPolicy" > <constructor-arg > <ref bean="org.apache.jetspeed.security.PermissionManager"/></constructor-arg> </bean>

Permission Manager Security Permissions in Jetspeed are standard Java permissions. We support 3 kinds of permissions: 1. Portlet Permission 2. Folder Permission 3. Page Permission Permissions are stored in the RDBMS Security Policy. They protect resources for given actions. Permissions are RBAC (Role-based Access Controls) applied to portlet actions (view, edit, help, configure) AccessController.checkPermission(new PortletPermission(portlet.getUniqueName(), JetspeedActions.MASK_VIEW));

User, Role and Group Managers Jetspeed provides its own User management out of the box. Many deployed systems replace the user management with their own database, or LDAP implementations. Role and Group managers are also provided out of the box along with administrative tools.

Login Module For authentication, Jetspeed 2 provide a default login module implementation. Login modules provide a standard way to expose authentication services for java application. Configuration is central to JAAS authentication. By default, Jetspeed 2 is configured to use its DefaultLoginModule implementation. The configuration file (l ogin.conf ) for the login module ship with the jetspeed2-security-{version}.jar component and provide the following configuration: Jetspeed { org.apache.jetspeed.security.impl.DefaultLoginModule required; }; In order to override this configuration, you can place your own login.conf file in your web application class path under WEB-INF/classes. The location of the login.conf file is configured in the security-providers.xml file.

Login Module + User Manager The login module leverages the User Manager to authenticate users

Authentication SPI Authentication service providers are configured in security-spi-atn.xml file. Here the user management handler is configured as well credentials handlers

Credentials Jetspeed provides quite a few features for managing credentials: A custom password credential implementation Configurable Password Encoding with standard SHA-1 or Base-64 Enforced Password Value Rules (not blank, minimum length, minimum numeric characters) Interception framework for handling credential life cycle events: Validate Password on login load and force change if invalid Encode Password on first load Password Expiration enforces lifespan for passwords managing expiration date Max Password Failures enforces maximum number of invalid password attempts in a row Password History forces unique passwords in respect to previously used passwords

Login Validation The Login Validation Valve provides feedback to the user about the cause of an failed login attempt. It retrieves the User Principal and its current Password Credential for the specified user name, and (if found) determines an specific error code based on its state. This error code is communicated back to through the session so an appropriate error message can be presented to the user. The following possible error codes can be returned : ERROR_UNKNOWN_USER ERROR_INVALID_PASSWORD ERROR_USER_DISABLED ERROR_FINAL_LOGIN_ATTEMPT ERROR_CREDENTIAL_DISABLED ERROR_CREDENTIAL_EXPIRED Of the above error codes, the ERROR_FINAL_LOGIN_ATTEMPT will only be reported if the valve is configured with the same maxNumberOfAuthenticationFailures value as used for the related MaxPasswordAuthenticationFailuresInterceptor described above:

Managing Password Expiration If the PasswordExpirationInterceptor is used, password expiration for a certain user can be directly managed through the UserDetailPortlet provided with the security portlet application. If enabled, this portlet can display the current expiration date of a password and also allows to change its value:

Single Sign on Jetspeed-2 Single Sign-on (SSO) feature is a credential store implemented as a component. It uses J2 security implementation for storing credentials. A management portlet allows the editing of SSO sites and remote credentials. It supports Basic Authentication and Form Based authentication and supports cookies . The SSO Management administrative feature enables you to configure "single sign-on" access interactively.

Web Content Portlet + SSO Jetspeed comes with a sample Web Content Portlet that uses SSO. Enter the following credentials on the setup screen: username = jetspeed_test0 password = jetspeed

Web Content Portlet + SSO (continued) Once the credentials are entered, you will no longer need to enter them for this user. The user will be automatically logged on to the NY Times site Credentials can be configured for a group of users as well as a single user in the SSO admin

Portlet Statistics Jetspeed gathers statistics about portlet activity and logs it to either a database or a CLF file. The portlet can gather statistics over time periods as well as the top hit portlets. Of course you can use your own tools or queries to gather this information from the database. Statistics for portlets display hit counts and render times in milliseconds

User Statistics Jetspeed gathers statistics about user activity and logs it to either a database or a CLF file. Statistics for users display session counts and time logged on in minutes

Page Statistics Jetspeed gathers statistics about page activity and logs it to either a database or a CLF file. Statistics for pages display hit counts and render times in milliseconds

Jetspeed-2 Overview

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Jetspeed-2 Overview (20)

Recently uploaded (20)

Jetspeed-2 Overview