subscribe
 

Lowering IT costs by deploying desktop LIMS software via the web

1st April 2013


With the advent of AJAX (Asynchronous JavaScript and XML) and other innovative web technologies which allow for a fundamental shift in what is possible on the Web, web-based line-of-business applications have gained momentum and market presence as never before.

While the ease of deployment and maintenance advantages of web-based applications are undeniable, there are other ways to achieve the same benefits without compromising product features or performance. Recent research has shown that IT decision makers are seeking software applications that leverage the transport capabilities of the web, but provide the rich user experience of the desktop client. Technologies are available today that can enable the creation of such applications.

Many businesses today are experiencing productivity crises. Budgets are being cut. Nowhere is this more apparent than in the pharmaceutical sector, with many blockbuster drugs coming to the end of their revenue-generation cycles and fewer big drugs in the pipeline than before.

One of the consequences of this is that IT staffs have more of a say in laboratory software purchasing decisions than heretofore. They are looking for easier, faster and cheaper ways to deploy the software they buy. In this article, we focus on how web solutions are influencing how decisions are being made in the laboratory.

The influence of web solutions

The original concept of the web, as evidenced in the two founding technologies HTTP and HTML (Hyper Text Transfer Protocol and Hyper Text Markup Language) was to link disparate pages of static content. Web pages were conceived as a means of displaying information in an easy-to-navigate fashion, rather than providing the level of interaction required for a business application such as a LIMS.

With the advent of technologies like JavaScript and AJAX, a much more dynamic user experience became possible. JavaScript allows computation and manipulation of the content of a web page to take place after that page has been sent from the web server to the browser. AJAX provides communication “behind the scenes” between the browser and the web server, allowing parts of a web page to be updated without having to refresh the entire page.

Even though JavaScript and AJAX provide the possibility of rich, interactive business applications, there are some drawbacks to their use. JavaScript is an interpreted language running within the browser and different browsers have different scripting engines, so JavaScript is not guaranteed to execute in the same way on different browsers and platforms, resulting in potentially unpredictable application behaviour. AJAX depends on constant communication between client and server to update parts of the user interface, which can add time lags or delays to the user experience in high latency or low bandwidth environments.

Web versus desktop

Desktop applications have been around for a long time – in fact, since the advent of the personal computer. The power of the PC, and in particular the user interfaces made possible by operating systems such as Microsoft Windows and Mac OS brought about a revolution in end user software.

Today, desktop applications still provide more power, flexibility and a richer user experience than web applications. It is easy to see why this is the case: desktop applications can harness all of the power provided by the personal computer hardware, whereas web applications are limited by the capabilities of the web browser they are running in.

With a web application, deployment can appear to be easier. The application only needs to be installed once – to the web server. Client-side installations are no longer needed. The same is true for maintenance and upgrades. In reality, however, setting up and deploying web solutions can end up being more difficult than at first appearance, with multiple web server products and browsers (and various versions of each) adding complexity.

From a validation perspective, web applications are perceived to have no conflicts with other applications on the client machine. It is worth bearing in mind, however, that the more products an application depends on, the more difficult it is to maintain a validated environment. Adding dependencies on web servers and web browsers can only increase validation complexity, not reduce it. Additionally, from a development perspective, architectural issues and security concerns or exploits tend to be greater with web applications than desktop applications.

Despite these disadvantages, and with the web user experience generally not being as rich as the desktop client user experience, the perceived deployment benefits (no matter how misunderstood) still tend to sway IT staff towards web applications. There are, however, some technologies designed specifically for rolling out desktop client applications via web mechanisms. One such technology is Microsoft’s ClickOnce.

Microsoft ClickOnce

Microsoft’s ClickOnce technology is part of the .NET2.0 framework. It is used to launch Windows applications directly from the web browser. The launched application does not run within the browser itself, but instead is launched directly on the user’s computer.

Since ClickOnce is bundled with .NET2.0, it is a standard feature on Windows Vista (which comes with .NET pre-installed) and since .NET is the Microsoft development platform of choice today, it is usual to find it installed on WindowsXP and even Windows2000 desktops.

ClickOnce works by using two signed XML manifest files, the first being the application manifest which is authored by the developer and specifies which components make up the application, and the second being the deployment manifest which is authored by the developer or by a system administrator and specifies how the application should be deployed to the end user's machine – for example, which version should be installed, what security permissions are required, whether the application should be cached, whether updates should be downloaded automatically, and so on. When the user clicks a web link which points to a deployment manifest file, the browser passes that file to the .NET runtime, which parses it, then downloads the application manifest and finally downloads the application itself from the web server. The application then runs normally as a Windows application (Fig.1).

From the perspective of the user, the process is completely transparent: clicking on the link runs the application. It is also possible to configure the deployment manifest to start running the application before it has completely downloaded.

Although the security permissions required by the application can be specified in the deployment manifest (anything from a low level of trust to full trust, which the user may be prompted to grant to the application the first time it is run), there are some things that a ClickOnce application cannot do on download, such as install device drivers or register COM objects. This can be overcome by using a ‘bootstrap’ or stub application that can install the drivers and then kick off the application proper.

The deployment manifest also specifies whether the application should be completely removed after the user has exited it (thus providing a true ‘zero-touch’ deployment and effectively reducing the validation burden to the same level as that of a pure web application), or whether it should be cached to save on download time for subsequent executions. Automatic application updates are supported, thereby providing relatively pain-free upgrades and maintenance.

From the server side, ClickOnce supports any web server technology, and though it is most commonly deployed from Microsoft’s Internet Information Server (which is bundled with their server OS products) there is no reason that Apache on Linux or Solaris, for example, cannot be used for server deployments.

The idea of browser-based applications is an attractive one. AJAX and the newer rich HTML technologies go a long way towards improving the user experience for web applications, but come with some disadvantages, as noted.

New technologies such as Windows Presentation Foundation and Silverlight from Microsoft offer the promise of delivering identical user experiences within the browser and on the desktop, even extending that promise to operating systems and web browsers other than Microsoft’s own.

Early previews of the software appear to bear this out, and though much of the functionality is centered on media delivery, there is plenty to support business applications as well. It is, however, early days, and only time will tell if this promised shift in the way we write and deliver applications will live up to all expectations.

In the meantime, with ClickOnce-enabled desktop solutions such as Thermo Scientific LIMS, organisations now have access to a full-featured LIMS with an efficient and cost-effective deployment mechanism. Thermo Fisher Scientific is additionally implementing other Microsoft technologies, such as the .NET Framework3.0, SQL Server, Office Open XML, Windows Presentation Foundation and Office SharePoint Server to future-proof its customers’ IT investments.

Seamus Mac Conaonaigh is Director, Technology-Informatics, Thermo Fisher Scientific, Philadelphia, PA, USA. www.thermo.com/informaticsu





Subscribe

Subscribe



Newsbrief

FREE NEWSBRIEF SUBSCRIPTION

To receive the Scientist Live weekly email NewsBrief please enter your details below

Twitter Icon © Setform Limited
subscribe