Todd Biske: Outside the Box

In the recently released SOA Insights Podcast, Dana and guests discussed the wacky world of mashups and composite applications. The panelists all agreed that mashups and composite applications are effectively the same thing, however, they did state that mashups tend to be associated with web-based presentation more so than composite applications. The debate moved into a discussion of SaaS providers (e.g. Salesforce.com) and aggregators like StrikeIron. Google apps was also thrown into the mix, however, I don’t consider that a mashup or a composite application. Google Calendar or Google Spreadsheet are really just hosted versions of traditional desktop applications. Given that the conversation went this direction, it surprised me that the discussion did not go down into the area of Widgets and Gadgets, depending on which operating system you like.

Before we go there, let’s first look features of mashups. The most familiar notion of a mashup is a geographic overlay of some information on a Google map. This is possible through the availability of data as XML from simple HTTP calls, the scriptability of a web-based presentation component, such as Google maps, and the use of AJAX technologies to tie the two together. How does this relate to SOA? The most direct connection is in the first item: data services making data available as XML over HTTP. Without this, everything needs to move to the server side where data access frameworks like ADO.NET, Hibernate, etc. can be leveraged. The other half of this is the presentation tier, where the combination of JavaScript and CSS now allows HTML-based components to effectively expose an API that can be executed within a browser. This is in contrast to Portal technology, which is still a predominantly server-side technology. Effectively, JavaScript and CSS now allow a component-based model for web-based application development.

To make this more applicable in the corporate world, we need to look at the corporate problems. Many enterprise IT department are not creating applications for an end user on the internet, but rather for their own corporate employees. Frequently, these applications are used for simple tasks (think data entry) associated with the execution of a business process. Unfortunately, those applications take time to run. If they’re desktop applications, there’s probably a lot of bloat in them and they take a lot of time to startup. On the consumer side of things, I’ll use Quicken as an example. I may only need to enter one or two transactions, but I used to have to start the whole bloated application with all of its features to do so. Something that should take 30 seconds winds up taking 2-3 minutes.

Now, let’s enter the world of Widgets and Gadgets. It really started with a program called Konfabulator (which was eventually acquired by Yahoo), continued with Apple’s Dashboard, and most recently was continued with Microsoft Vista’s dashboard. Effectively, these platforms leverage DHTML, JavaScript, CSS, and if necessary, some platform specific APIs (mainly for saving preferences, but can be used to access local desktop resources), to present web-based applications that are very narrow in function. For example, the latest release of Quicken for the Mac included a Dashboard Widget that allows data entry. I no longer have to start all of Quicken simply to enter a transaction. This results in increased efficiencies. Because these Widgets and Gadgets are built using DHTML, JavaScript, and CSS, they can pull in data on the fly via XML over HTTP, instead of having the user navigate through endless pages to get to what they need to do. Furthermore, the platform integration allows data to be carried in to the widget and be “mashed” on the fly.

I believe these technologies have the most potential within the enterprise. I can’t drag an Word document into a browser window normally, but I can drag it onto on Apple Dashboard Widget (I don’t know about Vista Gadgets). Secondly, their lightweight nature and immediate access makes them extremely well-suited for workflow tasks. Theoretically, the widget itself could be embedded in a task notification message. The task manager for the user (which could be a widget/gadget as well, or it could be something like Outlook) would leverage the native HTML/CSS/JavaScript engine to generate the UI on the fly, pull in the data via XML/HTTP and allow the user to directly execute the task without all of the overhead of launching applications and navigating through web pages.

There are certainly still challenges that exist before this becomes mainstream, security being the largest, along with the risk of badly coded widgets consuming resources. If you’ve ever tried to do some AJAX programming and used timers, you’ll know that it’s easy to make a mistake and wind up with a ton of background HTTP calls trying to get XML data that just grinds the system to a halt. This is just the normal maturity curve for technology usage, however. As someone with interest in user productivity and efficiency, I’m excited about the opportunities that Widgets and Gadgets may provide for all of us, both corporate user and home user, in the future.

5 Responses to “Widgets, Gadgets, Mashups, and Composite Applications”