In this article we will first list some of the offered services and then have a deeper look at an important

aspect of the
current internal architecture.

The Components
JBoss Portal comes with components and services ready to use. Here is a list of the main ones.

Portlet Container
The portlet container is an implementation of the JSR-286 specification. This component is part of JBoss Portal 2.7
(And the Enterprise Portal Platform 4.3) and is also available as a separate project without the other services. The
separate project comes with a basic tag library for themes and can be used for prototyping or development. This
component enables portlets to run on a portal. Portlets are mostly designed to provide a modular approach to portals
where components of a page can't collide but still communicate on top of which web application frameworks can be
built.

Identity (authentication/SSO)
Most portals are partially restricted to some users and require authentication. The portal framework makes sure you
can integrate with an existing identity server that is already in place or let you configure a new one without
necessarily forcing a specific scheme.

JBoss Portal will be able to store or retrieve users from databases supported by Hibernate, Red Hat Directory Server,
OpenDS, OpenLDAP, Microsoft Active Directory... But provides an SPI to implement to be able to support proprietary
identity servers.

The authentication mechanism is based on JAAS and existing JBoss Application Server identity modules can be
used, this gives a whole range of out of the box solutions for various scenarios. One major benefit is that portal
authentication benefits from modules based against JBoss AS security mechanism. (Such as Windows Desktop or
Kerberos authentication through JBoss Negotiation that still need testing though).

As far as SSO is concerned, not only all applications integrated within the portal must not require additional
authentication but the portal itself must be able to be part of an SSO infrastructure and JBoss Portal has been tested
against CAS, OpenSSO, JOSSO but again an SPI is available to plug into any solution.

CMS (And GUI)

A basic CMS/ECM/WCM/DMS (whatever we call those today) is available as part of JBoss Portal, the implementation
is based on the command pattern and can directly be used through the provided services. A GUI is also available with
workflow support and Wysiwyg editor. Integration with ECM vendors is also possible (but requires some work) to
replace the basic CMS with a full-blown ECM such as Alfresco.

WSRP (And GUI)

The Web Services for Remote Portlet implementation of the 1.0 version is embedded in JBoss Portal. It lets the portal
being able to produce content to be aggregated in other portal framework or solutions such as IBM Websphere
Portal, BEA/Oracle Portals, Microsoft Sharepoint... The other way is also possible, content provided by those
products can find its place within JBoss Portal. A relaxed mode is available to loose on the specification for better
interoperability with other providers.
Portal Object Management
An administrator of a portal or a company providing a portal solution will have to manipulate portal objects. Portal
objects are windows (that may contain a portlet), pages (composed of windows) and portals instances (composed of
pages). Those objects have properties that will define how a page should be rendered to the end user. Out of the box
JBoss Portal offers a way to populate those objects by the usage of XML files, it also provides a way through an
administration portal to create/delete/modify objects during runtime.

Depending on requirements it's possible to define pages in a a controlled way or let the users build their own pages
with the available components. Out of the box, users can drag on drop windows on the page's layout used by their
dashboard.

Security
By declaring security rules, portal objects can be secured to be available only to some users, this is a way to
customize the user experience on the portal. The error handling framework let you customize the type of answer you
want to give to the user on a security restricted object (hide the window ? Display an error message ? ...)

Theme and Layout

JBoss Portal helps organizing content on a page and also delegate the visual aspect to a different team by adding
skins to the pages. Themes and layout can be deployed separately from the portal itself and hot-(re)deployed for
faster development turnaround.

Aggregation engine
A page is built from a set of properties and a context. The Portlet specification makes sure that no part of the page
would collide with any other part so that the application in charge of producing a fragment of the page can behave like
it was the only component of a page.

Internal architecture for advanced customization

When possible, JBoss Portal doesn't enforce any behavior, there is a default behavior that can be easily replaced for
specific needs. The architecture has proved during support to handle many scenarios that haven't been thought
about during the initial design.

There are three different pipelines of commands with interceptors on those commands, the magic of customization
happens on the flexibility of those interceptors than can be easily added or removed and are usually targeted to a
simple concern.
The HTTP request sent by the client reaches the Controller through Server interceptors, this is the best place to
determine things based on the type of request itself such as what to do next, determine which locale to use or
content-type for example.

Following is a simplified version of the default interceptor to determine the locale, by default the out of the box portal
determines the locale to use for the user based on his user preferences (set in the portal itself) and falls back to the
web browser preference.

view source

print?
01.package org.jboss.portal.core.aspects.server;
02.[import ...]
03.public class LocaleInterceptor extends ServerInterceptor
04.{
05. protected void invoke(ServerInvocation invocation) throws Exception,
InvocationException
06. {
07. // Get the user profile
08. Map profile =
(Map)invocation.getAttribute(ServerInvocation.PRINCIPAL_SCOPE,
UserInterceptor.PROFILE_KEY);
09. // Get the locale preference from the user profile
10. Locale preferredLocale = (Locale) profile.get(User.INFO_USER_LOCALE);
11. // Get the locale from the web browser preference
12. Locale browserPreferredLocale =
invocation.getServerContext().getClientRequest().getLocale();
13. // Default locale
14. Locale locale = Locale.ENGLISH;
15. if (preferredLocale != null) {
16. locale = preferredLocale;
17. } else if (browserPreferredLocale != null) {
18. locale = browserPreferredLocale;
19. }
20. // Set the locale for the request
21. req.setLocales(new Locale[] { locale});
22. // Invoke the rest of the interceptor stack
23. invocation.invokeNext();
24. }
25.}

Basically we just had to extends the ServerInterceptor class and override the invoke method. We should not forget at
some point to call the next interceptor in the stack by executing “invocation.invokeNext()”. Note that you can execute
code before or after the call to the command, depending if the code is place before or after the invocation of the next
interceptor.

Once the Controller pipeline done, a portal render request might be preceded by an action phase and each phase
have different stacks of interceptors. In those interceptors we can achieve access security on some nodes (and by
pass the rest of the action phase for example) or triggering events when a node is rendered or actionned for example.

The action phase will ultimately result by triggering a single portlet (unless an interceptor stopped the call) while the
render phase will usually render multiple portlets. At this stage we can apply portlet interceptors, some features of the
portlet specification are implemented that way.

Conclusion
We have only scratched the surface of JBoss Portal, in the next article we will see how to create a customized portal
using a custom theme, localization, declarative security, a personalized portlet, a customized interceptor, a CMS
document...