As I wrote to Punit Pandey (who runs this excellent blog on portals), I wonder at the fact that although so much work has been done on defining portlet standards, we do not have anything like a portal standard. A large part of a portal/portlet application has to do with menu design, page layout, portal themes, portlet skins, etc. These are not covered by the portlet spec and are left to individual portal servers to implement in their own (read: proprietary) ways.
Quite obviously, this impacts the portability of applications. I can trivially port a web application from one server product to another by just deploying a .war file, but I cannot do the same for a portal application. I would need to rebuild the portal pages from scratch and can only reuse the portlets in it. I can't see the portal vendors wringing their hands over this lack of portability. That's how they lock in their customers even while claiming to be standards-compliant.
I believe we need a portal standard in addition to portlet standards JSR 168, JSR 286 and WSRP. But we can't depend on vendors to kickstart the process. It's the users who need to set up a JSR to hammer out a portal standard, because we're the ones who lose from the absence of one.
Quite obviously, this impacts the portability of applications. I can trivially port a web application from one server product to another by just deploying a .war file, but I cannot do the same for a portal application. I would need to rebuild the portal pages from scratch and can only reuse the portlets in it. I can't see the portal vendors wringing their hands over this lack of portability. That's how they lock in their customers even while claiming to be standards-compliant.
I believe we need a portal standard in addition to portlet standards JSR 168, JSR 286 and WSRP. But we can't depend on vendors to kickstart the process. It's the users who need to set up a JSR to hammer out a portal standard, because we're the ones who lose from the absence of one.
No comments:
Post a Comment