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.

7 thoughts on “Gadgets and Widgets as an alternative to Portlets”

  1. I am much more optimistic that gadgets will replace portlets in most scenarios. On the one hand, with OpenSocial there is a gagdet standard that is getting traction, which makes it an attractive development platform, on the other hand does Apache Shindig provide a low-cost way of integrating this feature in your application, which means gadget containers will start popping up where portlet containers would be way to heavyweight. As for the missing inter-gadget communication: this is something that is also missing from portlet standards and we have found ways to cope with it.

  2. Apoorv, I mostly agree with what you say except for the fact that I am more excited about the gadget world – pretty much like Lars. I like the Gadget world more because of the relative ease in pulling together a decentalized architecture involving Gadgets. While WSRPv2 affords some of that in the conventional Portlet world, we have spent quite a bit of time making that work while experimenting with leading Portal servers of today. In contrast, we liked our experience with Apache Shindig server while creating Wipro Web2Works. If you build your own Gadget Manager, Layout Manager and Security Manager on top of Shindig, you can have a Gadget container that can truly match any good Portal server. That said, you are so correct that gadget world lacks maturity. Security could be its Achilles heel – especially when you are trying to mashup Gadgets hosted on servers spread around the world. Gadget certification itself can be an interesting service area. On the problem of Inter-Gadget/Portlet communication, I think that the solution is not easily forthcoming, if are focusing on visually mashup of presentation nuggets – all on a browser, WYSIWIG. Firstly we need to evolve a metadata representation framework (may be some semantic agent) that can introspect a Gadget and discover the Mashable parts.Secondly we need to think of a visual interface that allows those Mashable parts of different Gadgets come together based on simple user intent. It is the constraint of human imagination that impedes us most in Visual Mashup interface construction.

  3. Apoorv,

    Will Gadgets and Widgets be a boon for start-up firms who don’t have enough capital ? Just to see the market response a startup firm can build a quick portal * like * applications. And based on the response they can go for a full fledged portal implementation. This way a firm need not invest more on the Portals when they are skeptical about the responses which they get from the market.

    Here is one article on building cost effective websites using blogs and widgets

    And below is a start-up’s website which is built with widgets.


  4. Lars,

    If my reading of the standard is right JSR268 adresses the inter portlet communications issues. This is an interesting advantage in favore of portlets to build more interactive portal apps in the near future bases on real standards, I for one believe portlets and Widgets/Gadgets can co-exits. It is a question of using the right tool for the job.

  5. Good post. Not sure if anyone is still engaging with this given the last comment was in 2009, but I just read it and thought it was good conversation … would be interesting to hear if any of your views have changed since 2009, mine haven’t changed drastic, mostly because of the lack of standardisation.

    I am portal developer and especially interested in the JSR286 IPC (Inter Portlet Communications). I feel I have achieved some nice composite applications with reusable portlets by creating strategies on top of the events publishing & processing framework that JSR286 brings. And that is where the problem with JSR286 IPC resides. The specification defines a nice framework for distributing information about events, but this information lacks any kind of structure. So portal architects need to come up with a proprietary messaging payload standard dealing with the structure of this information. I think this was done intensionally by the JSR286 group with the hope that a de-facto standard would arise from one of the major Java portal vendors, though this has been slow coming. Without such a standard (or possibly a set of standards) it is difficult to assemble composite applications out of portlets developed in isolation from each other, which is crucial for mashups. I am hopeful there will be a follow on specification which deals with this. Possibly by leveraging semantic web standards like OWL and RDF.

    The other challenge for portals is having the UI update in a useful way when IPC takes place between portlets. Currently there is a strong reliance on a full page refresh rather than partial browser DOM replacement using a form of AJAX. I feel JSR286 is partially to blame for this because IPC events distribution is always followed by a full page render phase. Maybe a better approach would be to introduce another phase where individual portlets are given the opportunity to signal that their view state has changed between the events and render phase. This idea still doesn’t feel quite right to me because portlets might run client side JavaScript that manipulates the browser DOM, which the portal server would be unaware of. This of course is less of a problem for gadgets because the view state is entirely orchestrated by the browser.

Comments are closed.

If you would like to get short takes directly in your mailbox, please do consider subscribing to my newsletter. I won’t spam you and your information will be safe. I usually send it like once a week (or once in 15 days).

%d bloggers like this: