The Portal Challenge: Integrating software developed in isolation

I have a strong interest in developing approaches where software is not only developed in a modular way, but also in a way where each module can be mashed up with other modules from other software that was developed in isolation. This interest was first sparked when I encountered the JSR286 Java Portlet specification for portals a few years ago. Portlets are a good candidate for software modules, though in order for them to become this, they need to communicate. JSR286 brought more standardised IPC (Inter-Portlet Communication) to the Java portal world, though it did not go all the way. I feel I have achieved some nice composite applications with reusable portlets by creating strategies on top of the events publishing & processing framework that JSR286 IPC brought. This approach is working well whenever a small team is developing all the portlets, but becomes more challenging when integrating portlets developed by other teams in isolation. By integrating I mean without writing code. This is where I feel the problem with JSR286 IPC resides and it is a major problem in a world where app stores are king and mashups are gaining popularity.

In 2010 I posted in this topic (Achieving a federated single view of the customer) and it remains a challenge. I still feel this is a good approach, but it does require a bit of code to be written for each integration. Can we do better?

The JSR286 specification defines a nice framework for distributing information about events, but this information lacks any kind of structure. So portal architects need to come up with a proprietary messaging payload standard dealing with the structure of this information. I think this was done intensionally by the JSR286 group with the hope that a de-facto standard would arise from one of the major Java portal vendors, though this has been slow coming. Without such a standard (or possibly a set of standards) it is difficult to assemble composite applications out of portlets developed in isolation from each other, which is crucial for mashups. I am hopeful there will be a follow on specification which deals with this. Possibly by leveraging semantic web standards like OWL and RDF.

Another challenge for portals is having the UI update in a non-disruptive way when IPC takes place between portlets. Currently there is a strong reliance on a full page refresh rather than partial browser DOM replacement using a form of AJAX. I feel JSR286 is partially to blame for this because IPC events distribution is always followed by a full page render phase. Maybe a better approach would be to introduce another phase where individual portlets are given the opportunity to signal that their view state has changed between the events and render phase. This idea still doesn’t feel quite right to me because portlets might run client side JavaScript that manipulates the browser DOM, which the portal server would be unaware of. There should be scope to involve the user in deciding when the view is updated. does this quite well by simply notifying you that there are new tweets (in real time, through reverse AJAX or Comet I presume) that you might want to view rather than forcing a view change upon you at an inconvenient time.

I’d be interested to hear your thoughts about these challenges facing Java portlet developers.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s