Online Application Registry for Office 2.0

This post is in response to a post by Ismael Ghalimi on his IT|Redux blog, and seems to be a recurring theme for him with respect to Office 2.0.

For the uninitiated (a large proportion of the readers of this blog) Office 2.0 is in its most basic form productivity applications like the MS Office suite, completely hosted online and not requiring any local installation. Many people are familiar to the concept with Hotmail, Yahoo Mail and Gmail - fully featured email clients you can access anywhere in the world. Well, try Zoho Writer, which I wrote this on, for a lightweight alternative to Word available anywhere.

My aim is not to reiterate all of the great information and brainpower that many technologists and bloggers have contributed to promoting (and even writing code) for this concept. This is not my core area of expertise. But maybe I do have a little something to offer.

How does this relate to New Account Opening or any other enterprise process?

Most business processes are being presented on the intranet using web technology, enabling enterprises to avoid the costs of installing BPM client applications on hundreds or thousands of desktops. To enable the ad-hoc document production and collaborative requirements of these processes to be exposed online as well an approach is needed for the BPM, productivity and business applications to work together effectively, without the need for proprietary interfaces or browser plug-ins.

(Note that over time I will discuss on this blog the specifics of collaborative tools in structures business processes in more depth).

Passing files between online applications

In its raw form, Ismael, in assembling a bunch of decent online applications, has found that a basic capability of a Windows (or Linux or Mac) client is not easily translated to an online world. That is, the ability to produce a document of some form in one application and pass it into another application through a single/double click. An example is the need to be able to receive an attachment in an email, received in Hotmail in my case, and rather than having to save it to my desktop and upload it into my favorite online word editor (in this example, Zoho Writer) as is the case now, being able to just click it and have it open in Zoho (see Ismael's post).

In the thick client world this is done by registering which application you want to use to open a particular file type, then every time you open a file of that type (online or from your desktop) the OS launches the right application for you. And most of the time that is so invisible that you don't notice it. In the online world of Office 2.0 this doesn't happen yet.

One approach

An approach Ismael and his team have proposed (and pretty much rejected) has been to utilize a form of generic browser plug in to pass a file from one online app to another. This depends on a near impossibility - being able to persuade all browser creators to accept this as a standard approach, and implement it to the letter.

The other approach the team suggested is that the email application directly pipes the information to the word editing application behind the scenes. This requires each application to know how to communicate with every other (possibly competing) application.

My proposed approach for the transfer of files from Client Application to Editor Application

My suggestion is to use the successful implementation of the thick client world and mix it with the technologies of the thin client. This is going to take a few components to work. This is the first time I have seem this approach described in completeness for online user applications, Office 2.0 or Rich Internet Applications from different vendors.

Online Application Registry maps applications to file types

The key to the approach is the use of an Online Application Registry (OAR) service. This in its simplest form allows a user to create their own personal account recording their Editor Application (e.g. word, spreadsheet, etc) preferences. On signing up they go through each file type they might want to open in the future and select an Editor Application to open it with (from a directory of appropriate online applications). Extend this slightly so that the user can select from a list of online service providers for each application. And finally give them the option of just pointing the mapping at a service URL, for example for services they themselves host, or are not recognized by the directory.

Online Client and Editor Applications talk the talk

Editor Applications that can open documents (like a spreadsheet) need to provide a standard approach to consuming documents passed from a third party and opening in the browser on request.

This could take any number of forms, including being passed the URL of the document on a secure third party site, to being passed the document through a web service call. The result of this makes the document available to the Editor Application. The Editor Application generates a key, which it passes back to the Client Application to enable the Client Application to refer to this file transfer in the next step.

Much like feed-readers accept RSS feeds and blog update pings, editor applications could eventually converge on an accepted standard or two to achieve this.

Now Client Applications (e.g. an email client, or a wordprocessor with embedded spreadsheet) can be sure that they don't need to write a pipe connector to every other application their customers may ever want to use. And by adhering to the standard, Editor Applications can be sure that they are actually used at all.

Piping data in

When a user clicks to open an Open Office format file (e.g) they have received in an email in Yahoo Mail, the email client has to know what to do with that file. Now we have made it easy for the this Client Application - it just has to look at the user's profile, and pull out the URL to their preferred Online Application Registry, once and once only for all file-types. The Client Application queries the Online Application Registry for the user's Editor Application preference based on the file-type to open. Again this would be done through a standard interface (HTTP, Web Services, etc).

Now, through the magic of the standard interface described in the previous section, the Client Application requests that the preferred Editor Application, at its registered URL, consume the file using the appropriate interface. The key that is produced that references the 'transferred' file is used by the Client Application to open the URL of the Editor Application in the browser with the required file.

Custody and In-Place-Editing

If I suggested that the Client Application should request the file to open to the Editor Application as a URL there may be an advantage. First, the Client Application could retain 'custody' of the file, and the Editor Application would not have to deal with the random timing issues associated with clean up. Second, if the WebDAV standard was used to open the file, in-place-editing could be provided. OK, so I may have abused another term here, but what I mean is the ability to open and save files at a URL through HTTP standard WebDAV, without having to explicitly copy them locally then copy them back. WebDAV also provides the requisite file locking protocol.

And even better, this would open the interface up to a range of off the shelf, currently available document repositories as well. A simple HTML page could make a form based request to an Editor Application with a URL to open, and hey presto, it would open, be editable, and saveable, without having to go through the standard Editor Application interface.

Extending the Online Application Registry

What happens if the Client Application requests the preferred application for a file type the user has not registered? Many approaches could enable a user to select a new service, a default service provided by the Client Application service provider or Online Application Registry provider, or some other approach. Either way, the result should be that a user should be able to open ANY type of document in an online service. Last resort is to allow the file to be saved to the user's thick client desktop and opened in a locally installed application.

Single Sign-On

Identity of the user, and single sign on are an issue, as with any multi-party services. The smart Identity guys can answer this better than me. So I won't even pretent to know what the answer is.

Final Comments

I believe that this proposal represents a decent approach to solving the Client Application to Editor Application document transfer problem. It is obviously based on a range of concepts including Office 2.0, Web Services, UDDI, client application registration and Software as a Service (SaaS), and I do not proclaim to be an expert in any of these.

I believe that the Online Application Registry (OAR) is a service that could viably be provided by independent service providers (compare with how Feedburner sits as a feed intermediary), Client Application providers, and Editor Application 'suite' providers. As long as they play by the rules and enable user preferences to be set for file to application mappings, and accept request to query this database from anywhere, all will be good.

By publishing this, the idea is now in the public domain, so I hold no rights to its proprietary usage and neither should any one else. But if you like the idea then please at least mention my name to the next guy you tell. Especially if it is the CTO of a very forward-thinking, progressive enterprise!

Technorati tags: Financial Services Technology New Account Opening BPM Office-2.0 UDDI RIA SaaS