Gadgets and Widgets as an alternative to Portlets
A new trend that I am seeing these days is emergence of gadgets (widgets, dashlets, blocklets) and mashups. These basically provide a quick and dirty way to create portal *like* applications. They are light weight and less expensive as compared to your typical portal servers.
iGoogle is probably the biggest example of their success on the consumer internet. For usage within the enterprise, IBM has a Mashups as well as a Widget platform. You develop components using widget factory which is based on portlet factory (erstwhile Bowstreet) and deploy them on the platform that runs on the embedded Websphere application server. Kapow Technologies and quite a few other vendors (including my company) also have a similar offering. Apache’s Shindig is an open source implementation of Open Social and Google’s gadget specification and lets you build iGoogle type applications.
Many customers are considering these for building their next generation of web properties. Many of them have been asking about Google’s and Yahoo’s offerings as well for their usage within the enterprise. The biggest reason is probably the fact that small applications can be relatively quickly built and mashed up at the client side using light weight technologies based on Web Oriented Architecture (WOA) like REST, RSS etc instead of more involved server side technologies. A widget can be written in many ways (java, ruby, php,…) but a J2EE portal’s portlet is *generally* written in JAVA and that gives more flexibility for bringing in or integrating with non java applications. So potentially, different technologies can co-exist and their functionality exposed via a uniform web interface. You can also integrate a gadget which is actually hosted by a 3rd part provider (like Google) within your environment.
Many Portal servers have been offering the ability to include Google gadgets within the portal server. So essentially they provide a gadget portlet using which you can integrate gadgets. IBM and Liferay both have this capability.
So will these replace portal technologies? I don’t think that is going to happen in the near future and the reason for that is the fact that portal ecosystem is much more evolved and matured as compared to gadgets/widgets. There are certain standards (e.g., JSR 286) that govern the portal world (at least the java portal world) and most portals support that. There are no standards yet in the gadget/widget world and if you really want to use, say a Google gadget within your environment, there would be non trivial issues to take care of. So for example, how do you do an inter gadget communication between your gadget and that hosted by a 3rd party provider? Even though a portlet and a gadget can co-exist within the portal server, getting your portlet to send an event (or talk to a gadget) is a different matter that needs to be addressed (okay – Google and IBM have cooperated on IBM portlet Google gadget communication but it is still a non-standard way). IBM is working on a specification called iwidget but i do not think any other vendor supports that as yet. Similarly, Google also has a gadget specification.
There are also other issues related to integration with back end applications and more sophisticated personalization that need to be addressed. Till these are addressed, i think both have a place in targeting specific scenarios.