If you are struggling to choose the right web platform for your project, you’re not alone. There are many options to choose from, each claiming to be better than the rest. How do you choose for your specific project? The answer largely depends on the context of what you are trying to achieve. But whether you intend to build an employee intranet, e-commerce site, or anything in between, there are a few technical questions to consider.

The following 7 questions will guide you through some of the most important technical questions to consider in your portal evaluation. Our hope is that these practical tips and snippets of insight will help you better understand how to choose the right portal platform for you. Enjoy the takeaways!

1. Is the Platform Standards-Based and How are the Standards Supported?

You should select a portal platform that is based on modern technology standards rather than proprietary technology. Here’s why:

• Resources: Standards-based technology is easier to implement when finding resources with experience.
• Interoperability: Standards-based technology provides higher levels of interoperability, which provides the opportunity to fit easily into your current system architecture or adopt numerous technologies.
• Durability: Standards-based technology has a higher chance of outliving the technology platform, granting you the ability to move to another vendor platform while retaining your underlying code base.

As for key technology standards to consider when making your selection:

• JSR 168, JSR 286, JSR 362 - Java Portlet Standard
• JSR 127, JSR 314, JSR 344 - Java Server Faces
• JSR 329, JSR 378 - Java Server Faces Portlet Bridge
• WebDAV - Web-based Distributed Authoring and Versioning
• SOAP, JSON - Web Services
• HTML5, CSS3 - Web Standards

It is recommended that you find a platform that supports these listed standards. The proper support allows you to utilize modern technology standards, which could result in greater interoperability as well as money saved and escape from vendor lock-in.

2. How Does the Platform Integrate with Identity Mangement Systems?

Authentication and permissions provide the foundation for secure access to information and rich personalized experiences. Many organizations have existing personnel databases and related authentication mechanisms already in place. To reduce redundancy and drive down costs, the web platform must be able to integrate with these existing environments. Here are a few of the common identity management platforms:

• LDAP Authentication and Synchronization
• Oracle Access Manager
• CA SiteMinder
• Novell Identity Manager
• Sun Identity Manager/Open SSO
• Tivoli
• SAML, CAS, OpenID

By finding a platform that integrates with your specific identity management system, you remove the need to manage user information in two separate locations, saving you costly hours of trivial and redundant work. If you have a non-standard identity management system, understanding the platform’s security architecture will be necessary to evaluate whether integration is possible. Two-factor authentication is also becoming necessary for many systems, as increased access security is desired in many verticals, such as financial services and the government.

3. Does the Platform Support Fine-Grained Permissions?

The permission system works alongside the authentication system and is responsible for providing varying levels of entitlements to users in order to protect access to content and site functions. Some portal vendors do not provide support for granular permissions nor do they provide an easy way to extend portlet permissions. The portal platform you select should have a flexible, fine-grained permission system, allowing for very granular or wide sweeping levels of access. These fine-grained permissions should protect access to anything as large as an entire site, a singular page, a portlet, or a piece of content. Additionally, the permission system should be an integral component of the system. This is especially important when custom components are to be provided to other systems as remote services.

A good portal platform will allow for custom end-user portlets to extend the permission system that is provided by the base platform. This will allow custom portlets to provide and protect new content and features with the same mechanisms that the portal provides. Equally important is ensuring that access control is built into the platform at the service layer. This is key for solutions that strive to provide rich user interactions, where data and feature access should not be managed on the client side. A good portal will police access at the server.

Finally, fully understanding the various means in which your portal will present and segment information to your user audience is critical. Specifically, you must understand the portal security architecture and its limitations. Problems arise when the portal security architecture does not support the various ways that information needs to be segmented. For example, does the platform support segmenting users into communities or groups? Are hierarchical levels supported? Can these segments overlap each other? The platform must also provide the ability to assign permissions to these groups and user segments. This allows administrators to easily manage permissions for large groups of users quickly and easily, without the redundancy of editing the permissions of each user. In choosing the right platform, you should look for a permission system that is as flexible and fine-grained as possible.

4. Can the Platform Easily Support the Rich Interactions and Web User Experiences of Today and Tomorrow?

Web 2.0 is an overused buzz term that can mean many different things. One common characteristic of a Web 2.0 application is a good user experience. From a UI perspective, this often means reducing page transitions by relying on AJAX calls or creating an experience that performs more like that of a local desktop application.

Supporting this type of user experience requires a backend foundation that is secure, scalable and easy to maintain and manage. Although writing code to support SOAP and REST-based protocols on top of the portal platform is possible, it is better if the platform supports it directly. In supporting these protocols, not only should the base portal services be provided, but there should also be support for user-written business logic to be created and exposed in the same manner. This provides a clean architecture that keeps the business logic tier on the server side and away from the client side. Applications taking advantage of this approach are also immediately able to contribute as service providers on an Enterprise Service Bus (ESB).

The portal platform must also be able to support and adapt to web development paradigms as they arise. Single page applications, AgularJS, jQuery, and so forth: these are all technologies and frameworks that are widely adopted by today’s leading web developers. Your portal platform should be able to support these frameworks, as well as whatever you want to use on the UI layer to create rich web interactions.

Related to this is security, which is vastly important when providing services to AJAX clients. A good portal platform will provide security for these calls from a foundational perspective, making it less burdensome for your code to support. Be sure to find a platform that provides security enforcement at the service and business object model level.

5. Does the Portal Platform Support Multiple RIA Client Frameworks from an Architectural Perspective?

Technology supporting Rich Internet Applications has been around for several years making it essential for frameworks to support them. Some of the more prevalent RIA platforms are listed below:

• jQuery – A popular JavaScript framework that provides rich support for creating client-side browser applications.
• YUI – Another popular JavaScript framework, Yahoo UI Library is a high-performance and flexible framework used in highly interactive sites such as the Yahoo homepage and Yahoo mail.
• AUI – Alloy UI is an emerging framework from Liferay that enhances YUI. It provides an additional library of user interface components built on top of YUI and provided with Liferay out-of-the-box.
• GWT – Google Web Toolkit is a rich JavaScript client library that powers sites such as Google Mail and Google Maps.
• AngularJS – A widely used JavaScript framework maintained by Google and built to help facilitate the development of single-page applications.
• Vaadin – A Java server-side client framework, Vaadin provides user interface objects using a component model, similar to how Java AWT or Swing works.
• Others – (ext-js, dojo, etc)

The RIA flavor you choose to develop your application is an important decision, but it is equally important to consider how the selected portal platform supports and integrates with the chosen RIA technology. Because the RIA framework is an integral part of the portlets you develop, it is important that the framework is supported from a foundational level of the portal. In other words, the application needs to be viewed systemically rather than looking at individual portlets, especially from a performance standpoint. This becomes more critical if your application needs to scale.

Portlets are designed to be self-contained, with all of their supporting resources meant to be included. When developing an entire application, however looking at the portlets as a system can result in positive performance outcomes. Consider three portlets that utilize jQuery for their user interactions. These three portlets would normally include the jQuery JavaScript libraries individually. If all three of them are placed on the same page, the libraries will be downloaded three separate times. This design will have serious performance implications. A good platform will make it easy to coalesce the portlets into a single library while providing the ability for it to be cached.

When looking at the portal systemically, good questions to ask include:

• Does the portal provide the ability to combine all the RIA libraries into a single resource to minimize the HTTP requests needed for a single page?
• Is the portal platform intelligent enough to combine requests across portlets using the same resources into a single resource request, rather than making individual requests?
• Does the platform provide the ability to minify JavaScript resources served in order to decrease the payload size?
• Does the portal platform provide the ability to cache the resource requests on the server side and eliminate the need to once again serve those resources by using a server response such as HTTP 304?

6. Does the Portal Provide a Content Management System (CMS) and Can It Integrate with Other Systems?

Most portals and Rich Internet Applications combine functionality with content, usually a mix of HTML, documents, images or video. Earlier portal platforms relied on external Content Management Systems (CMS) to achieve this functionality. However, the convergence of CMS and portals is becoming more prevalent. Good portal platforms not only have their own content management system but also are able to integrate with external CMS platforms.

A native CMS within a portal platform should minimally support the ability to:

• Import content from existing repositories into its own repository. (E.g., via import utilities that programmatically use an API)
• Manage all CMS interaction with platform’s built-in permission system
• Manage and edit unstructured HTML content using a modern WYSIWYG editing interface
• Define and use workflows that are based on the jBPM standard
• Define and use structured content types
• The ability to create display templates for the structured content types
• An easy to use interface for editing the structured content types
• Preview content and publish it to staging and production environments
• Automatically create versions when changes are made
• Support automatic expiration of content based on a date attribute

As mentioned above, good portal platforms can also easily integrate with externally managed content. Since moving a significant amount of content from an existing CMS can be cost prohibitive, it makes more sense to manage, access, and serve the content directly from the external CMS. Ideally, the portal platform will support the external system through a native interface protocol. Alternatively, external content should be able to be accessed using the standard Content Management Interoperability Services (CMIS) protocol.

7. Does the Portal Platform Provide Integration with Social Networks and Gadgets?

Social Networking is an important feature to leverage in providing user experiences that return real business value. Leading online retailers are using YouTube, Twitter and Facebook to create powerful customer experiences that increase site traffic and business. Additionally, there is a plethora of third-party gadgets that have large user bases. Rather than write these applications and gadgets yourself, it is more efficient to use third-party gadgets directly inside your portal. A strong portal platform will be able to integrate with social networks in a variety of ways by leveraging the APIs already built out for those networks. This will allow the portal to integrate social networking features such as social bookmarking, embedding social content, and other sharing capabilities into portlets and CMS web content.

Of course, there are many portal platform questions outside of this series to consider during your portal evaluation period, many of which will pertain to your specific project context. But regardless of what you are hoping to build with your portal framework, if you hope to provide the most value to your users and help ensure your project’s success for years to come, make sure to take these portal questions into consideration.