Historically, the progress of Web-based applications and the diverse nature of information from different Web applications ushered in the need to unify content to a single point of access: the Web portals.

There are several Web portal frameworks being developed in both the J2EE and .NET camp to unify Web content and provide end users with a more efficient environment to interact with the Web.

The portal technology is based on the notion of a portal container that provides the basic infrastructure to host a load of disparate applications wrapped up as portlets.

To facilitate cross-vendor Web application deployment as portlets in portal containers, a number of specs were written with several implementations in J2EE and .NET, but there still was no way to host content from both J2EE- and .NET-based Web applications in the same portal container.

To fix this issue, WSRP (Web Service Remoting Protocol) came into being. But WSRP is also pretty heavyweight and does not serve the needs of the enterprise to provide an easy portal architecture.

In general, if we look at the portal implementations mostly in the J2EE space, there are some major shortfalls:

1. The idea of a portal-type solution started early with the classical page flip kind of Web architecture and most of the portal specifications/implementations are still abiding by that. With the Web 2.0 and the AJAX push portal, solutions also need to move to an asynchronous way of request-response handling, but the most popular Java portal specifications such as JSR 168/286 does not provide the same till date.
2. With so many implementations of the portal container, it’s difficult to deploy a portlet app. The deployment procedure varies from container to container even after common standards like JSR 168/286.
3. There is no way to deploy applications written in .NET and J2EE in the same portal container.

This article looks at an easy portal infrastructure that’s built on a Flex-based portal container and portlets (individual Web applications) deployed as Flex modules. This portal framework provides full support for AJAX-type message processing with a very efficient deployment of portlets and manages the portlets so that they can logically connect to any Web application, freeing developers from routing to J2EE/.NET portal frameworks. If you need a clean way to integrate and reuse the same code for your Flex application based on either a J2EE or .NET back end inside a portal container, read on.

This article is more about Java portal containers and the J2EE back end, but the same principles may be applied to the .NET side as well.

Basic Shortfalls in Today’s Java Portal Solutions
To standardize the process of portal development and deployment, there are standards such as JSR 168/286 and WSRP. These standards are driven by a huge group of commercial portal vendors. First I’ll look at the underlying architecture of the JSR168/286-based portal solution.

JSR 168/286 relies on the classical page-flip Web architecture, where the full browser page is refreshed whenever an event happens in the page. Figure 1 shows the architecture details of a JSR 168/286 portal solution.

This portal solution is based on the server-side aggregation of content that is pushed to the browser upon request in the form of an HTML document. The container that hosts the portlets resides on the server side where the deployed portlets (individual applications) are logically managed. In this architecture, the content from different portlets is aggregated in the server and the net result is pushed back to the client browser as HTML. However, to effectively make AJAX (Asynchronous JavaScript and XML) type request/response handling work for the portal, it’s required to manage portal/portlet interactions in the client browser too. Without the notion of a client-side container present in the user browser, it will be very difficult to have an AJAX-type request/response work in the portals. With the architecture in place with JSR 168/286, we have the following shortfalls when it comes to AJAX-type request/response handling:

1. Asynchronous rendering of portlets is not currently mentioned in the Portlet Specification JSR 286/168
   
2. With non-standard work around too, it’s difficult to get AJAX working for more than one portlet on a page. This also leads to intra-portlet communication using AJAX impossible even with JSR 286 support.
3. Whenever a portlet state is updated without a server round-trip, the state that may be encoded in other portlets may be stale, which is the most severe flaw when working with AJAX.
4. Some AJAX implementations exist but are vendor-specific and non-standard. These solutions use JavaScript to tie portlets in the browser and again tie portlets using a JSR 286 kind of solution or session sharing in the server-side portal container.

How Can a Flex-Portal Solution Come to the Rescue?
To fix the above issues and provide a rich portal framework, Flex might be an ideal solution for Web applications written in Java or any other technology. Flex applications are loosely coupled from the server-side processes; they rely on the server just for data. Flex applications have self-contained UI logic, which is ideal for portlets. Unlike JSP/ASP-type rendering where the UI is closely attached to server-side processing, Flex UI logic does not depend on the server side; it only needs the server-side data to bind Flex controls with actual data. Hence, if the policy exists to fetch data from a server, Flex UI can be connected to any server from any browser-based or stand-alone application and render the same rich UI every time. This basic advantage of Flex can be exploited to come up with a robust Web2.0-compliant portal architecture as shown in Figure 2.

In the figure, the container runs in the client as a Flex application with basic support for authentication/persistence, etc., being provided by a server-side container process (may be implemented in J2EE /.NET/Web services). Individual portlets are Flex modules deployed in the server, which are instantiated in the portal container whenever needed. These individual portlets can get their data using SOAP/HTTP from any Web server. Portlets are managed by the portal container and can also be attached to an application running in the same container server or any third-party/Web services server to get the data. Portlets are designed as Flex modules to have minimum downloadable size and to enable runtime hot deployment without any need to stop or recompile the Flex portal container.

Now let’s see how this architecture scales with issues discussed earlier and how does it tackle the same.