Dreaming of KM services
built to Google’s specifications using a Google supplied API and XML toolkit. Figure 1 (Page 9, Vol.16, Issue 8) shows a picture of my Google home page. You can see from Figure 1 that I have set up my own Google gadgets including bookmarks, topics from NPR that are of interest to me, current moon phases, my Gmail inbox, a Google map and a translation bar.
Grouping gadgets together as I have done via iGoogle is similar to the idea of portlets and mashups; however, gadgets are not the same thing as portlets or mashups. Portlets are Java components that are modified servlets and require a portal and servlet server infrastructure. The nice thing about portlets is that they are pure Java, standards-based, use Web services and are a mature technology. The issue with portlets is that you usually have to do custom integration to get them to share data through the portal environment, which is usually not quick or easy. For that reason, mashups seem to be the most popular form of building composite applications in a Web browser.
Mashups are groupings of completely unrelated Web applications that have been tied together in a set of Web pages. For example, I could easily build a mashup using a Yahoo (yahoo.com) map component, a Google translation component and a Yahoo or Google calendar component. While mashups are similar to portlets, they are more free form in nature, not restricted to Java, JSPs and portal environments as most portlets are. If you aren’t familiar with the concept of mashups, take a look at the Web site webmashup.com for the latest on industry news and tools and technologies to help you understand and build your own mashups.
As you look through the list of example mashups on webmashup.com (they are live Web sites), you will find it no surprise that Google and Yahoo technologies are big drivers of mashed up Web services and content. Figure 2 (Page 9, Vol.16, Issue 8) shows mashedworld.com, a Web site comprised of different tools and data sources presented as a mashup. That is, they use map and search tools from Google and geospatial and product data from yet a different set of sources.
A little snag—limitations in portals and mashups
Uh-oh, there is a little snag in our delightful world of portlets and mashups. It turns out that mashups, portlets and portals don’t necessarily deliver the kind of seamlessly integrated, application-to-application communications you get with a Windows client/server application and things like object linking and embedding and dynamic data exchange. Then again, they are less complicated to implement than Windows applications, and they do fill an important niche. But is it possible to have the benefits of well integrated applications that can share information between each other with all the power and seamless integration of a Windows application?
The answer is a resounding yes, because of emerging tools and technologies that allow us to build rich Internet applications (RIAs). Web services, SOA and RIAs can give all the benefits of seamlessly integrated applications, where one application not only appears in the same windowing environment with another application, but the underlying RIA client software allows data to be shared seamlessly between them. Yes, you read that correctly, RIA applications, built to run in the Web browser can be designed so that applications can share data between themselves, either automatically or manually, at the user’s request via things like cut and paste and drag and drop.
As I mentioned earlier, portals and portlets only get us part of the way there. In a portlet application, integration usually takes place at the portal, which is a back-office application server. But back-office data and application integration to connect portlets doesn’t really help us benefit from easily integrated Web services—back-office portlet integration tends to be proprietary based on the portal being deployed. Not a long-term solution for an open and standards-based, services-oriented approach.
What if I could just tell the IT department to provide whatever services the users need and then let the integration of those components take place at the Web browser? That concept, called a services-oriented client (SOC), is part of an emerging trend for tools that allow Web services to be integrated on the client (rather than via the back office).
One technology that gets us very close to the idea of having applications that are seamlessly coupled is Yahoo Pipes (http://www.pipes.yahoo.com). Yahoo Pipes gets its name from the old Unix pipes technology that allowed the output of one Unix application to act as the input to another Unix application. As with the Unix concept of pipes, Yahoo Pipes allows the development of Web applications, through which data can be shared seamlessly between unrelated applications. But it does a lot more.
Users can do things like drag and drop data between application windows or create a permanent data link between two unrelated services. Inputs from one program or data source can be taken from the outputs of another, allowing data to be exchanged in an almost dynamic data exchange (DDE)-like manner. DDE is one of Microsoft’s techniques for using the clipboard to allow Windows users to easily share data between Windows applications. The Yahoo Pipes toolset provides a range of different, pre-defined functions, allowing Web applications to be rapidly mashed together to deliver custom composite applications.
It makes sense that Yahoo created the Pipes technology because the Yahoo public portal offers so many different (and often free) applications and data sources, which people would naturally want to tie together in unique and unusual ways. Pipes allows people to take data from many different sources and combine it into complex sets of Web content feeds (which Yahoo hopes come from its Web sites and applications), and provides the means for developers and users to mix together the tools and technologies they specifically need without complex integration activities. Best of all, Yahoo Pipes targets and takes advantage of Web services.
However, the piece de resistance for RIA Web application development is Adobe Flex, Flash, AIR. Virtually every Windows and Linux PC that runs a Web browser has a version of the Adobe Flash player installed. It is about as ubiquitous as any item of software can be, with more than 98 percent of consumer and business platforms running at least one version of the Flash player.