Gadgets have emerged as a light weight alternative to build portal like applications within the Enterprise. Driven mainly by the fact that it is much easier to develop Gadgets (and hence build applications quickly) as compared to Portlets, Gadgets are becoming increasingly popular. Many Portal vendors now support them, albeit using different names like Modules, Blocks or something else. There are some similarities between Gadgets and Portlets -- both are used to build Squares (or Rectangles) that display information from multiple other sources. However, this is probably an over simplification as there are some important differences in terms of architecture, governance, ecosystem, standards, development processes and so on.

There are two main approaches that the Portal vendors take in order to support Gadgets. We will cover the specific details in our Enterprise Portals Report but here's a summary of the approaches:

1. Many products allow you to expose Gadgets that are hosted elsewhere via their interface
2. Some products go a step further and provide a Gadget container of their own

Assuming that you do need the ability to support Gadgets, which approach should you go for while evaluating products?

The first approach is typically useful and sufficient when you want to use one of the many existing Gadgets from Google, Facebook or another provider. This improves your time to market as you can quickly cobble together composite applications. In this mechanism, the Portal server provides a wrapper that essentially opens a third party Gadget within a Portlet in your Portal. This is very similar to opening an application in an iFrame but it gives slightly more control because now you can apply your Portal server's personalization or access rules on this Gadget via your portlet wrapper. Remember though that if the third party gadget is freely available and a user knows the URL, they can access it without going through your portlet.

This approach has its limitations and so if it is not sufficient for you, you can explore the second approach in which the Portal product provides a Gadget container of its own. What this means is that the Gadgets are hosted in your environment instead of being hosted with a third party and hence you can edit or modify them. You can also create your own Gadgets and syndicate them to others who might be interested. If your organization has strict policies about using third party Gadgets, this approach can become a useful concept within the Enterprise as you can syndicate Gadgets across different business units and benefit by reusing functionality. Even with their own Gadget container, the products will usually still let you run third party Gadgets as well, either directly or by letting you import those Gadgets into a local repository.

Both the approaches above have their share of pros and cons and I will not go into details in this blog post. At this stage, the Gadgets marketplace is quite young and it is probably a safe assumption that Gadgets are going to co-exist with Portlets for reasonable amount of time. We will of course be tracking this market place more closely in our Advisories, Blogs and Reports.