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.
Thursday, February 12, 2009
Why JSR-286 is irrelevant and how to fix it
Subscribe to:
Post Comments (Atom)
This work is licensed under a
Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.
3 comments:
It has been some time since people started calling that mashups, which has the added benefit that anybody can implement his/her own added value system integrating parts of others in a way that it was not planned for. Plus, it saves bandwidth on the server.
I checked it out on Devoxx, the portlets talk was almost empty. People have moved on.
There is another thing that needs to be done to keep portlets alive.
We are using portlets in our products and have put a lot of efford in making the portlets usable in a web2.0ish matter.
Doing this, you quickly notice that the Portlet standard has a blind spot: there is no common framework on the client side. Defining this inside a JSR process may be not practical (as is means we need a javascript API), but i strongly believe that there is a need for a standard to let portlets stay interesting to developers and customers (in that order, of course ;-).
Actually, we are considering to open up our library to the public as an open source project.
See our blog for some articles about portlet development and javascript. Leave a comment if you are interested in details, this may speed the process of releasing our libs to the public up...
Wouldn't this be an answer to your quest for common data access across vendor implementations?
Map userProps = (Map) portletRequest.getAttribute(PortletRequest.USER_INFO)
Post a Comment