Portal Zone will now focus on social app development

Portal Zone was launched in 2006 when I was a part of the Sun's Web Portal team (this was the initial blog: The Old Portal Zone). The intent was to share what I learnt as a part of my day job (Portlets, WSRP, Ajax and such) and also, to be honest, provide a little bit for marketing for Sun's Portal product.

In 2007, I moved to another group in Sun and later quit Sun. However, I still continued blogging on the subject (albeit sparingly) on this blog. This was primarily driven by two factors - My interest in the subject + the large readership the blog had attained.

Of late, not only has my interest in this subject been waning, I am no longer actively involved in portlet development. However, there are other related areas that have piqued my interest.

Hence, I have decided to shift the focus of this blog. Portal Zone will no longer be actively covering the Java Portlets/WSRP space. Instead this blog will be focus on the subject of social web app development - viz OpenSocial , Facebook Platform and related topics.

If you have subscribed to this blog and are not interested in social app development, do unsubscribe.

Why JSR-286 is irrelevant and how to fix it

Today I came across an interesting article on java.net :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 java.net 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.

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.

Portal Technology Predictions for 2009

1. Portlets will lose ground. Opensocial gadgets / widgets will catch up.
I blogged about this sometime back. With announcements like Sun's SocialSite and eXo Social, this seems to be already happening.

2. WSRP will die.
WSRP is a web services standard which allows a web portal to aggregate content from externally hosted applications into it's own. To me this is the Facebook platform gone wrong. It will die.

3. Goodbye Sun, IBM - Welcome Google, Yahoo
We will witness the shift of power from large IT vendors like Sun and IBM to large consumer facing Internet companies like Google, Yahoo and Facebook, with respect to defining Web technology.

4. Federated Identity via Google Friend Connect and Facebook Connect
Expect these technologies to take off, in a big way.

Happy New Year !