Thursday, February 12, 2009

Why JSR-286 is irrelevant and how to fix it

Today I came across an interesting article on :JSR-286: The Edge of Irrelevance. It also seems to have sparked some discussions in the community: In response to JSR-286: The Edge of Irrelevance.

In the article, the author talks about how the Portlet spec is losing it's edge and makes his point by listing the number of organizations supporting the spec (for Portlet 1.0 it was 24 and for Portlet 2.0, it is just 6). He also goes about explaining the "higher than normal learning curve" for portlets and the "monolithic architecture" that portlets dictate. The community discussions around this article also seems to focus on the same lines : bad design, too much of constraints etc.

However, in my opinion, the reason why portlets are getting irrelevant is something different.

Portlets focus on solving one part of the problem, the integration of UI (it doesn't solve this very well either) between the portal and the portlets. However, it has no notion of standardizing on the data it operates on. For example, there is no reliable way for portlet to get the email id of a user who has logged in into the portal and viewing the portlet.

What sort of real-world, portable, business applications would you expect developers to build with such restrictions ? The most important aspect of a Portal is not only it's aggregation abilities but also the data that lies underneath. Yet, the portlet spec does not have any notion of portal data.

Therefore the only portable portlets that you can realistically build is a stock ticker or a weather portlet. Any portlet that is built to actually use data from the portal becomes proprietary.

The "fix" is to come up with a standard that can actually helps portlets (or "applicationlets" as I would like to call it ) to be able to query the portal for it's data. This is not something new. This is how third party developers build applications on Facebook and Myspace (on the enterprise front the Zoho Marketplace is a great example). These applicationlets are provided with an API that can query Facebook/Myspace about the details of the user who is viewing it, get the users friends, message them etc. That is all that is needed for developers to come up with interesting social apps.

So, let us assume that the portal vendors define a standard to akin to OpenSocial. Let's call it OpenEnterprise. All OpenEnterprise applicationlets must have the ability to query the details of an employee who is using the portal (email id, employee number, etc), query the employee's boss, query the employees subordinates if any, message any employee in the organization (via IM, email) and perhaps post documents, spreadsheets etc on behalf of the employee.

This would be enough to provide a platform to build a rich set of portable enterprise applications: Time sheets, Reporting tools, HR tools , you name it. It will also encourage developers to build apps that can integrate deeply with the portal and not just superficially. Portal vendors will start supporting the spec because of the rich set of applications that can be made available to the users. Third party vendors are bound to pop-up, building specialized business applications that can actually be plugged in to your portal and developers will learn the spec even if the programming model is not perfect !

In short, this is actually a business problem, not a technology problem.

Saturday, February 7, 2009

Portlet 2.0 on JBoss

Packt Publishing recently published "JBoss Portal Server Development". The books covers Portlet 2.0 on JBoss. Grab the free sample chapter here : "Portals and Ajax" and let me know if you find it useful.