Developing and Deploying Applications Using Remote Services
- Background
- Case Study: Interior Specialists Management System
- Remote Services
- Benefits of Deployment Under Remote Services
- Issues of Application Deployment using Remote Services
- Application Design Considerations
- Application Development Under Remote Services
- Conclusions and Recommendations
- Further Reading
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.