SaaS Presentation Layers exist out of the browser

In a recent blog post, SaaS Blogger Phil Wainewright made some excellent points on what defines a SaaS client.

Some purists may disagree, but my definition of a SaaS client goes outside of the browser to include a client that runs on the desktop machine so long as it’s still controlled and managed from the Web.

Phil’s definition, reinforces the views I have repeatedly expressed in my own blog.
Webifying Desktop
Software+Services or SaaS, the key word is Service not Software.

Phil discusses the real world examples of this happening, including RightNow who have showcased their new On Demand Release which utilizes Microsoft .NET Framework capabilities.

This is still true Software as a Service, because all the benefits of the Multi-tenant single code base exist in these flavors of SaaS client.

There are viable alternatives to pure browser based solutions, which up the ante in UI presentation and brings parity between traditional Client/Server (On premise) UI and SaaS UI.

What’s next then? as per my previous posts I predict sometime in the future, Desktop and Browser will merge again. When a user boots up her computer, or utilizes their smart phone, it will be one and the same. SaaS will ensure accessibility to data in the cloud from all devices and not just via browsers. Cloud services will enable advanced deployment capabilities for SaaS client apps which will access services and data provided by a myriad of SaaS vendors.

(This post was originally published on my personal blog)

4 Comments
  • Falafulu Fisi |

    Yep, that’s right Ben. In the Java space where I do my development in, I had used Java WebStart in the past for a small desktop web-based app, that required rich scientific visualization where Java3D & JAI – Java Advanced Imaging were used which you can’t do with any other technologies (this was 4 years ago). The application sits resides at the client’s machine, and the next time he opens up the WebStart app (or starts his/her machine), it automatically checks the server where it was downloaded from to see if there is any update. If there is, then it prompts the user to download the new version. If the new version was just perhaps a single Java class file or a few that was(were) added overnight, then that is (those are) the only files being downloaded by the client’s WebStart-based app and not the whole damn thing again. In a small incremental version update, this takes less than 8 seconds to be completed so, it is unnoticeable. In the JAI website, it highlighted some proprietary technologies (user-success-stories) of using JAI in a WebStart-based app (medical imaging, document management system, etc…) since these high-end heavy numberic-based processing app, can’t be handled via browser. So, WebStart app lives on the client machine, but still connects to the internet, where the demand of heavy processing task is done locally, which makes things faster.

    The web-based that I am currently writing is applet-based, but when graphics are going to be added in the future, then I will switch to JavaWeb Start, since applet codes (Java Swing) could be converted into a JavaWeb Start easily (ie, no major overhauling).

    Overall, I agree with Phil Wainewright’s article.

  • FF – Thanks but the credit for this post has to go to fellow diversity contributor Troy Wing

    Ben

  • FF, Yes, I consider frameworks such as Java WebStart and Microsoft Clickonce as true SaaS Client Deployment options. They provide the same single source code base as traditional browser plugin based apps as well as the seamless update option, which serves to eliminate version problems of tradional desktop applications. Your point on distributing processing power to the client is correct. Although I am a fan of Cloud Computing grids, I do think the need for high powered desktops is not going away. As long as the results of the processing is persisted in the cloud not on the client, then its still SaaS.

    Troy.

  • Falafulu Fisi |

    Troy said…
    Your point on distributing processing power to the client is correct.

    I think that high-end processing task as remote automated medical imaging systems for diagnostic purposes or MRI image classification such as described here in the following JAI success story (see link), can only be done via SaaS desktop, since the heavy imaging processing would be too slow for real-time image query & retrieval, because the remote client (a rural clinic , etc) have to send the huge image file(s) over the internet to the central server somewhere, to be interrogated to find (retrieve) similar images if any that might have already been stored.

    Java Advanced Imaging In Action — Millenium Technology, Inc

    A browser based image retrieval system would almost be too slow to have a useful effect in a real-time remote clinical decision support system environment. With a SaaS desktop medical imaging app, the query image (perhaps it’s an MRI scan of a newly admitted patient to a remote clinic) is processed locally (client’s site), where the query image is converted to image features, which is a bunch of numbers in a matrix form using a method (algorithm) called feature extraction. This sets of numbers (image feature matrix) is sent from the remote client to the central server somewhere with a repository of medical images in a database. This repository of medical images have also been converted to image features (each one), which are stored in an image feature database (which is different from the actual image database itself). Each image feature IDs in the feature database points to image IDs from the actual image database. When the query image feature arrives from a remote client, it is then computed against the image feature database to find those that are similar to the query. There is only similar images retrieved, since there is hardly any 2 images with the same value pixel-by-pixel. The closest match features (say, the most similar 5 or 10 images), are then retrieved (the matched features IDs are used for retrieval).

    So, it is faster to process image locally to extract its features via the UI, then send the features (a matrix) which is a reduced dataset of the original image (this means ,less data) via the internet as a query to the central repository rather than sending the raw image itself. Image processing is quite a heavy task (memory-wise), so this the advantage of SaaS desktop compared to a browser-based system. The other advantage of dedicating some of the heavy task to the clients, is that the server won’t be overwhelmed by many requests from remote clients if the raw query images are sent instead of compressed image features , because the server might be receiving thousands of images that require feature extractions processing on the fly. The job becomes easier if feature extractions is done on the client.

    PS: We will see more of these types of SaaS desktop medical imaging decision support system being deployed for commercial use over time.

Leave a Reply