Portal

I've been testing out our new product - the WSO2 Gadget Server - which is getting very close to release. What is a Gadget Server I hear you ask? Well, its basically a portal, except that instead of writing portlets you write gadgets. In fact, its a whole new way of creating a portal server, and much better than the existing approaches.

If you have ever used iGoogle you will know what a gadget is. Gadgets are simple HTML+Javascript code, wrapped up in a little XML. They are defined by the Google Gadget specification, and are part of the OpenSocial work. Here is are a couple of gadgets from my iGoogle homepage:

 As you can see, they look just like portlets. They can be simple RSS or Atom feeds, or there can be dynamic content. So why would anyone use something different than a portlet?! Three reasons:

• Portlets are written in Java - not everyone is a Java programmer. Gadgets are written in HTML+JavaScript+XML - every single web developer can handle these three.
• Portlets need to run in the server, and need to be deployed in the server. Gadgets can be loaded from any website, meaning that the world of gadgets is much wider and more distributed than portlets.
• Gadgets are inherently designed to use AJAX to talk to backend services: when this is combined with the distributed nature of gadgets, it means that they can fit into a Service Oriented or Web Oriented architecture much more effectively than portlets.
• Gadgets and the server required are much simpler and leaner than portlets.
• Yes, I know that's more than three! 

Because iGoogle uses gadgets, there are already hundreds of gadgets freely available on the web, together with editors, tools, guides and documentation.

I'm hoping you are with me so far: gadgets are a cool and webby way of creating a portal. But why do I need a Gadget Server? Basically the Gadget Server lets you run your own iGoogle-like portal inside your company, or in the cloud for your partners, or on your own machine if you really want it. What the Gadget Server does is to manage all the different users, their web settings, their per-gadget data and permissions. So each user gets a personalized homepage with their personalized gadgets.  What we have done is to take Apache Shindig, which is sort of the reference implementation for gadgets, and tie it together with our core registry. This allows us to manage permissions, store user preferences, host a gadget repository and many other cool things. As well as the integration of Apache Shindig with our Registry, we also have plugged it into our OSGi framework - WSO2 Carbon - and we provide full 24x7 support too.

You can plug this into your existing ActiveDirectory or LDAP, or you can simply allow users to self-register. And you can pre-populate the server with a list of ready-approved gadgets that are appropriate to your company.

The benefit of running this inside you company is that you can build, deploy and manage a set of gadgets that talk to your internal services - building a customizable dashboard for your users. We think this is going to be really useful to people building all kinds of applications:

• Business monitoring and dashboards
• Customer information portals
• Content aggregators
• User interfaces for SOA applications
• Human interaction with BPEL and other business processes
• and much more.

For example, you can put our Data Services together with a simple gadget to quickly expose relational data to users. Our Business Activity Monitor (also coming soon) is another great example - a system that pulls together data from your whole SOA and uses Gadgets to build an SOA dashboard. But you don't need to use it with an SOA - you can build a pure web-portal too.

If I've caught your attention and you have read this far, I'm guessing your next step is to try it out! Here is the release candidate 2. Let me know how you get on.