New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
What Will it Take to Transition from Desktop-Based Application to Cloud-Based Applications?
Posted by Jean-Jacques Dubray on Mar 26, 2008
Whether you look in the enterprise space, with a fierce competition between SalesForce.com, NetSuite and SAP, in groupware, office suites (with Zoho and Google Apps), and now even in business intelligence, the transition seems inevitable. Great Applications don't fit in a box (a computer or even a server) any longer and computing devices are becoming essentially information access points.
Raju Vegesna, evangelist at Zoho, gave his perspective on the question:
We expect to see a migration to the cloud based computing the same way we saw the migration from Mainframes to PC... We are currently seeing users slowly (?) migrating from desktop applications to online applications.
The key he explains is to make this transition easy, not just easier:
We are noticing that PC App vendors are extending their offline applications to the cloud for future compatibility. Microsoft extending their MS Office with MS Office Live Workspace is a good example of this. On the other hand, online app vendors like Zoho are extending the apps to the offline mode for backward compatibility. While these are two different approaches in opposite directions, they are basically doing the same….transitioning the user.
Raju sees two important steps:
- Offline support is important, at least till we are always connected
- Make a web based application look and behave like an offline app
While Google Gears seems to become the de facto standard to address the first point, Raju points at Mozilla Prism as a possible candidate to help with the second point. With Prism, Mozilla, lets users add their favorite web apps to their desktop environment:
They are accessible with Control-Tab, Command-Tab, and Exposé, just like desktop apps. And users can still access these same applications from any web browser when they are away from their own computers.
Unlike Adobe AIR and Microsoft Silverlight, we’re not building a proprietary platform to replace the web.
For Michael Arrington, who leads TechCrunch:
Flash, Silverlight and Ajax get most web applications over the hump in terms of usability and are the technologies behind the fast transition of desktop applications to the web. But it’s not clear that they’ll ever kill off all desktop applications entirely. The bridge between them may very well be Air and/or Prism.
Michael interviewed Matt Gertner, co-founder of AllPeers, now working with Mozilla on Prism. Matt comments:
Web apps simply don’t provide the responsiveness, performance, whizzy graphics and access to local data that users crave, and they only work when you’re connected to the internet.
Single-site browsers (SSBs) [like Prism] aim to bring the best of the desktop to web applications...Creating a single-site browser for a website a one-click process that can be performed directly inside Firefox 3
Matt points to Fluid, an early SSB framework built by Todd Ditchendorf:
Perhaps the most noteworthy feature is “built-in support for Greasemonkey-compatible userscripting.” For those not familiar with Greasemonkey, this means that a web app can be modified with a simple JavaScript file that runs on the client whenever the app is loaded.
Of course, we also have to link these comments to the recent post from CogHead's CTO, Greg Olsen, who pointed out that services like Amazon's S3 will play a crucial role in the next evolution of SaaS. In the near future, it might become really difficult to see the difference between a desktop application and a web application when your storage, handled by S3, will become available to SSBs, launched seamlessly from a Start Menu near you (populated of course with your secure thumb drive).
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
It will take a platform
by
Mike Burba
Posted
Re: It will take a platform
by
Jean-Jacques Dubray
Posted
Technology isn't the problem, US law is
by
Marc Tremblay
Posted
Browsers should be just a container.
by
Jim Leonardo
Posted
Re: Browsers should be just a container.
by
Jean-Jacques Dubray
Posted
Re: Browsers should be just a container.
by
Wayne Mack
Posted
-
One of things that it will take to make this transition is a platform that makes it really easy & cost-effective to build these kind of apps. I can't describe this kind of platform better than Andreeson did here.
In your article, you mention a couple of companies that are building these kind of platforms: Coghead, Salesforce, & Zoho. Some of these will be big winners as this transition takes place.
[disclosure: DevHive is also building a web platform]
Mike
www.devhive.com -
Patriot Act haunts Google service
I'm suspect there are the same concerns in many other countries outside the US. -
Mike:
thanks for pointing out Marc A.'s post, this is definitely a great read. As Marc points out below, there might still be some issues even if we make it seamless.
IMHO, the killer "value-add" that will drive adoption is ad hoc "collaboration". If all you do is emulate desktop apps, you are not going to bring a lot more value than a laptop (or a hosted VM) brings you (access your information wherever you are), however, if you add a collaboration dimension to most apps, people might be attracted by this capability. The third dimension beyond access and collaboration is enabling people to do work for you (as collaborations get more structured and tools allow you to assign and reward work), but that will come later.
Adoption will always be driven (in the end) by the problems you solve not "how cool" something is. So yes, of course a platform is needed, but don't forget collaboration. -
IMO, to really make the jump, we need something better than the HTML/JavaScript combo for the UI. I don't personally think WWW == HTML. Rather than Google, Mozilla, Adobe, and Microsoft going in different directions, it'd be nice to see some cooperation similar to the SOAP Web Services cooperation, however imperfect it was, to bring a more flexible and predictable UI environment than HTML to the broader community. That is the REAL key to "making a web based app look and behave like an offline app". Ok, please stop laughing now...
I'll now climb back off my favorite soap box for at least 10 minutes. -
unfortunately I am not sure that will happen, I know I am going to create an outcry, but the Web architecture is optimized for pages and navigation links. Web Application Servers have been built to match this paradigm as closely as possible and application semantics had to bend to fit this paradigm. Now, I grow increasingly irritated when a page refreshes to change a little piece of information, but the reality is "that is the application model offered by the Web": for each action, return a new resource. This resource is fairly substantial since you need to get the new "entire state" of the application.
Personally, I have trouble to think that user experience will be improved by keeping the same programming paradigm (except for navigation of course), I also have trouble to think that companies will not try to differentiate their "platform". Let's face it, HTML and HTTP (and JEE) were an anomaly of the market that was tolerated as a lowest common denominator to enable the Web to grow and prosper. At best vendors interoperate, they don't comply to standards. Once people get used to a better UX (i.e., just about now), they will be no turning back. The cloud is the next battle of this industry, in case anyone would still doubt it. I have trouble to think that the Web application model will survive the cloud. -
Ding, Ding, Ding, We hae a winner! Jim Leonardo is exactly right. HTML and HTTP are simply not up to the job of providing a true user application. When I say true application, I mean one where someone sits down and uses it for 8 hours a day, 5 days a week.
Use of a sessionless protocol doesn't get the job done. We are throwing way too much complexity at making sessionless gets and puts look and act like a session based stream and we are doing a poor job of it.
Likewise, HTTP does not have the right level of data primitives to get the job done. Page-based interaction provides too much user frustration in data validation, though AJAX can address this somewhat.
Feeling old and curmudgeonly at the moment, I will say that Telnet over 9600 Baud with VT100 emulation provided a more responsive interface than most web apps over DSL or direct LAN connection.
6 comments
Watch Thread Reply