Thinking of developing new business software as a Web application? Considering a complete rewrite of that existing program so that it will run in a browser? Before you decide, you should consider the attractive alternative that Remote Services provide!

Imagine that you could connect to a remote application server from your
client machine and run Windows applications, or even a full Windows desktop, as
if it were running on your local machine. This is exactly what you can do using
remote server technologies such as Microsoft RDP (Terminal Services) and Citrix
ICA (Metaframe). Now, imagine the alternatives that these technologies open up
for delivering complex business applications to remote clients!

This article discusses the use of remote services for both the development
and deployment of client/server business applications. It provides
recommendations about when it is appropriate and desirable to consider this
architecture, and when it is not. It offers suggestions and strategies for their
effective use based on experience developing a large business system.

The conclusion presented here is that although browser-based solutions
continue to be the technology of choice for casual Internet applications, remote
deployment of stand-alone applications can be a far superior choice for more
intensive business systems that require complex interaction and
functionality.

Background

Two of the most important software design requirements are remote access to
databases and the ease of application delivery and updates. Software
architectures have evolved largely in an effort to maximize these two
requirements. Out of this evolutionary process, browser-based technologies have
emerged as the method of choice. They provide a reasonably capable function set,
server-side code maintenance, and relatively few application delivery
issues.

Given the advantages of browser-based applications and the lack of
alternatives, many professionals concluded that soon all applications would be
browser-based. Many major business system projects went browser-basedand
continue to do so. Indeed, for a while it appeared that stand-alone applications
would become obsolete. It seemed that the traditional application development
languages, such as C++ and Visual Basic, would eventually be relegated to
system, middle, and back-end components serving applications written in HTML and
browser scripting languages.

However, as business stretched browser-based technologies with more demanding
requirements for intensive business-management systems, their limitations became
apparent. Although browser-based solutions work fine for casual Internet
applications such as shopping sites, they do not scale up well into intensive
business applications. Browser-based languages and development environments are
simply not as powerful as traditional languages in terms of code development and
maintenance. As application requirements grow, the investment in the coding,
debugging, and code maintenance of browser-based applications widens in relation
to stand-alone applications. More importantly, the quality of browser-based
products drops progressively further below stand-alone quality as business
requirements become more complex. As a result, the return on investment and the
quality of browser-based systems fall dramatically as application complexity
increases.

Nevertheless, the deployment and security benefits of leveraging browser
technologies are so critical that many businesses are willing to pay more for
lower-performance software in order to take advantage of the browser. Adopters
accept compromises as unavoidable and hope that eventually the browser will
improve enough in features and performance to rival stand-alone programs.

But although it may look as though there are no compelling alternatives to
the browser, new technologies have continued to redraw the playing field.
Broadband connections and active application update technologies made it
possible to automatically deploy and patch huge client-server applications to
hundreds of thousands of client machines. On-line games such as EverQuest™
have proven this emphatically. This is an extreme example of a sophisticated
client/server application that could not have been delivered within a
browser.

Despite these "install from the Web" and "active
patching" technologies, the task of deploying and maintaining a large
client-side application is still daunting. The Microsoft.NET platform promises
to ease these installation and deployment issues. It promises the creation of
easily deployed stand-alone applications as well as browser-based
applications.

Does this mean that Microsoft.NET is the ultimate solution for business
applications at this time? It should certainly be considered, but it is not the
only alternative, nor is it the best one for every situation. Although the
Microsoft.NET platform has made tremendous strides in easing installation woes,
stand-alone Microsoft.NET applications still require a substantial client
infrastructure that is not yet part of the Windows operating system. There is no
guarantee when or if the Microsoft.NET runtimes will be available for other
operating systems.

Browser-based applications written in Microsoft.NET can be produced and
maintained more efficiently then traditional scripting languages by leveraging a
real programming language and environment, but the end result is still
restricted by the limitations inherent in the browser. Further, applications
must be written either as a stand-alone application or a browser application,
but not both.

Remote services offer another alternative. By executing your application on a
server, but simulating the interface on the client machine, stand-alone
applications can be developed without compromise, maintained entirely on the
server, delivered to any client operating system with minimal requirements, and
presented either on the desktop or in a browser.