Welcome!

Adobe Flex Authors: Shelly Palmer

Related Topics: AJAX & REA, Java, Adobe Flex

AJAX & REA: Article

A New Way to Look at Portals

This portal framework provides full support for AJAX-type message processing

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.

More Stories By Indroniel Deb Roy

Indroniel Deb Roy works as an UI Architect for BlueCoat Systems.He has more than 10 years of development experience in the fields of J2EE and Web Application development. In his past he worked in developing web applications for Oracle, Novell, Packeteer, Knova etc. He has a passion for innovation and works with various Web2.0 & J2EE technologies and recently started on Smart Phone & IPhone Development.

More Stories By Alex Nhu

Alex Nhu works as a manager, UI Development at Packeteer Inc. He has more than 11 years of work experience designing and architecting complex server-side J2EE and XML applications. He loves developing Web applications with Flex now after getting a taste of developing UI using other RIA platforms.

Comments (9) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
srinuguda 08/21/09 12:46:00 AM EDT

Hi,

Kindly post the some sample on portlet implementation in flex.

Regards,

Lord1984 03/13/09 11:59:40 AM EDT

Hi,

very good article...

When you talk about portlet window you mean that portlet window is a mx panel and it contains a module, is it true?
how to achieve direct module to module communication?

Where download the source?

thanks.

sreiner 11/09/08 07:12:47 PM EST

Is the source available? The link mentioned in the feedback only runs a demo (with no flex "view src"). The article mentioned "source code for the interfaces can be found in the annexure-1". Thanks.

Indroniel Deb Roy 04/03/08 07:04:27 AM EDT

Try the following URL:
http://www.portalcontainer.com/portalcontainer

Sujit Reddy G 03/31/08 04:02:04 AM EDT

This is a awesome idea. The link is broken. can you please post the URL to the implementation.

Indroniel Deb Roy 12/20/07 06:22:09 AM EST

Here is the link to a basic flex container implementation showing some portlets based on the Amazon Web Service.

http://www.portalcontainer.com/portalcontainer/pc.html

Indroniel Deb Roy 12/18/07 06:24:21 PM EST

I got a preliminary version of the Flex Container up and running with stuff discussed in the article with some sample portlets. I will post the URL soon, so that everyone can get a feel of it!

Andrea Bosio 12/01/07 04:28:58 AM EST

Great article and excellent idea! Our company could be very interested and actively involved in this open source porject. At the moment we are setting up and deploing Liferay Portals as intranet system to our customers. Please contact me if you decide to start the project or if you are looking for partners.

Luke 11/23/07 07:26:33 AM EST

Excellent overview article. We're looking at Flex as a portal/portlet technology for the next overhaul of our intranet system, I would be very keen to be involved in a dedicated container. Please let me know if you decide to post this as an open source project.