A Portal Solution Apt for Web2.0/AJAX
Flex has gained a lot momentum as a rich and versatile framework for rich Internet application development using AJAX. Its rich user interface capabilities and event-driven architecture and its ease of usage has scaled it over other solutions. As the portal container is a Flex application running in the client, it provides a very rich environment to manage other portlets (Flex modules). The Flex portal container depends on its server-side counterpart for authentication/persistence, etc. The architecture is pretty open as the contained portlets (Flex application modules) don’t need any container support to fetch data from their respective servers; the container only maintains the look and feel and provides the basic infrastructure to host them. Rendering a portlet asynchronously with others or rendering only a few portlets dependant on each other can be done easily with rich event support in Flex.

Code Reuse and Easy Implementation
For the JSR portlet solution, a Web application already having a UI based on JSP/Struts/Spring needs to be rewritten from scratch to enable it to deploy in a portal container. However, with the current approach, if a Flex UI for an existing Web application can be reused to put inside the Flex portal container, just a module wrapper needs to be written and a cross-domain policy file may need to be put inside the host Web application from where the portlet gets its data. This is possible only because Flex keeps it UI logic separated from data. The cross-domain policy file just enables the UI to connect to the data. This goes well with the paradigm “Write Once, Deploy Anywhere.”

Ease of Use with Web Services
Flex provides a rich framework to connect to a Web service and get data. When talking to a Web service, a Flex application can directly connect to it without the need for any cross-domain policy file. Ideally, if any portlet is designed to connect to a Web service, it can be readily deployed in the Flex portal container.

Hot Deployment/Redeployment Possible
One of the major drawbacks of a JSR portal solution is the deployment where every container provides it own rules to deploy a portlet application. However in this approach, deployment means just providing the portlet module file that contains the full portlet logic and a portlet deployment descriptor that provides the configuration and security information about the portlet. As the portlet contains only the Flex UI code and has no data logic embedded in it, the Flex container can easily hot deploy the portlet. Also the same portlet app can be redeployed in any other container without any change. If not Web services–based, the cross-domain policy file needs to be updated in the host server to expose the new deployed portal container.

Cross-Platform Support
The portal container manages the infrastructure to show and provide basic support for the portlets, and the actual rendering and UI logic is left to the individual portlet applications. This provides a flexible way to implement the contained portlets. Ideally the container can easily host portlets written to fetch data from J2EE, .NET, Web services, or any custom back-end implementation. Moreover, it can readily embed the Flex UI written for an application with minimal change. Ideally a rich portal UI can be delivered without going through complicated standards, such as WSRP, with better results.

A First Look at a Flex Portal
Let’s look into a simple Flex portal container with its basic functionalities. For brevity, it’s kept fairly simple.

The Flex Portal Container
The portal container provides the basic framework to aggregate content from different Web applications and provides the infrastructure to manage different views and orientation on a per-user basis. It also provides the common gateway to manage and restrict content depending on the logged-in user’s roles. See Figure 3 for more details.

This figure shows the various parts of the Flex portal container for a logged-in user. The log-in mechanism for the portal container may be provided inside the Flex environment or with any custom JSP/ASP page.

On the right side of the figure is a portlet pane that shows all the available portlets deployed in the portal container that can be minimized for a bigger viewing area. While deploying every portlet module, it’s required to provide the configuration detail that is used to populate each available portlet in the list. It is also possible to group some portlets for better visibility and usage.

On the left lies the portal container canvas where the actual portlet windows can be arranged. After validating the security and user role, portlets can be viewed in a portlet window after being dropped from the portlet pane on the right into the portal container canvas. For any portlet that’s dropped in the container canvas, first do all the security and validation checks and then try to load the portlet module code from the URL provided in the module info. If for some reason the portlet can not be initialized, the container provides a dialog showing the error condition. On successful instantiation, the portlet is drawn in the portlet window. Many portlets can be instantiated in the portal container embedded in their own portlet window.

Inter-Portlet Communication
Inter-portlet communication can happen very easily between portlets using rich Flex event support. To provide a simple idea on the inter-portlet communication, there are truly two kinds of intra-portlet communication possible: communication with server-side data state change and without server-side data state change. The inter-portlet communication without server-side data state change is pretty easy where the inter-portlet communication is done only in the client browser; however, inter-portlet communication that needs server-side data state change, first fires the source event that changes the data state in the server, and then on a successful return, fires the event to the destination to reflect the new change.

The portlet windows can be resized and moved according to user preference. To efficiently manage views, the user can create multiple views of portlets. To navigate one view to the other, there is tab control on the top right. All the views and the individual portlet window orientation in a view are all persisted, so the user can always come back and see the same view he or she created previously.

There are some generic options available in the container to easily arrange and manage individual portlet views. These options are shown in Figure 4.

All the options are self-explanatory. They are for arranging the portlet windows in a view and for switching from one view to other.