In This Article We Will First List Some Of The

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. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25.}

Locale locale = Locale.ENGLISH; if (preferredLocale != null) { locale = preferredLocale; } else if (browserPreferredLocale != null) { locale = browserPreferredLocale; } // Set the locale for the request req.setLocales(new Locale[] { locale}); // Invoke the rest of the interceptor stack invocation.invokeNext(); }

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...