Mega Code Archive

 

Categories / Delphi / Examples

 

The Problem of Web Application deployment

Title: The Problem of Web Application deployment Question: The complexity of the current Web Architecture is such that it becomes difficult to create, manage and test web applications written in the traditional manner. Here is an alternative Answer: Introduction When Borland (now Inprise) first released Delphi, I was so delighted by the ease with which I could develop windows-based applications that Delphi became my main development environment. Soon after, I concentrated on developing components that extended the Delphi component suite. I became rather ambitious and encapsulated an entire database report designer in a single component. The successful deployment of that single component led me towards researching the possiblility of encapsulating well-defined business functionality into a suite of components that would permit developers to built entire business application without code. Borland's object technology proved ideal for that purpose and when the Internet became the newest environment for applications, I was saddened by the lack of Internet development environments. Having tried JBuilder, I soon discovered that the available components were not of the same calibre as those available under Delphi. I began thinking of ways to distribute applications across the web - but I had to conceed that in order to do so, I would need to either create my own browser and depart from the Web standards or to send and install something on the client system that would permit the creation and running of an application locally. There were some fundamental issues that needed to be addressed. I therefore asked myself the following questions; 1. What is the current Web Architecture? Typically, the whole system depends on having a server that stores the Web pages and is able to intercept, interpret build and respond to a client's request. This puts the processing power on some server machine. On the client, one needs a browser that can display the Web page and permit interaction with the user. The whole is similar to the "ancient" model of a central computer to which dumb terminals are attached. 2. What does a Web Application do? Typically a Web Application resides and runs on the server and builds response Web pages that are sent to the client based on the client's actions. Since the processing power is concentrated on the server, the client is not fully utilized at all, yet the client is capable of running an application and must run the browser software in order for a Web application to work. This appears to be quite wasteful of local resources. 3. How can this be improved? One could utilize the power of the local computer to run applications that are downloaded from the Web. In fact that is the manner in which ActiveX components and applications are distributed and these run within Web pages. 4. What is the problem with ActiveX? ActiveX works fine for many different kinds of applications - but the problem with ActiveX becomes obvious when one develops similar applications. The problem is that a lot of duplication of functionality exists between different ActiveX applications that perform similar functions. Therefore, the space requirements for downloaded ActiveX components becomes quite large. How can this be solved? Forget ActiveX for the moment and think of a Delphi Application compiled with component packages. This is not so different from an application that uses DLL's, yet there is a major difference in that component packages hold components and not just common code. Fully functional component libraries permit the construction of applications from simple definitions and it is here that one can improve Web application distribution. Therefore, if component libraries were installed on the client system as well as a mechanism that read and constructed applications from simple and small definition files, one could construct fully functioning applications on the client and run these applications locally. This would shift the processing requirements from the server to the client, permit the client to work in a stand-alone mode and provide the user with an application interface that is akin to the current look and feel of local applications. Communication to remote databases can be achieved via either local database interfaces (e.g. Direct Oracle Access) or via some middle tier server communication. Since component libraries on the client will hold more components than may be used in any one application, many different applications may utilize a single component library which in turn increases the applications that a user may run without impacting on the size that each application will need on the hard-drive. What about CGI, ISAPI, XML and ActiveX? I am certain that these technologies will continue to provide Web based applications. With Microsoft's latest offereing of XML development and dedicated server technology, I forsee an ever increasing dependence on specialized server hardware and software that provides and subsequently controls information distribution. In the future we may be so dependent upon being connected to the Web that we will not have local applications at all. Rather we would run applications from the Web and these would work only if we paid for them via some kind of rental scheme. I am certain that this is the eventual goal of Microsoft and I am not encouraged by this concept as it would destroy application diversity and the small developer. To counter this trend, let us look at alternatives that can achieve similar functionality but also provide the end-user with the ability to develop and run applications from the Web as well as locally on their own systems without the need to pay a kind of toll on application usage. The development of a Web Application Designer and Run-Time System Using the Borland Component Package technology, one could develop a Rapid Application Development Interface that would permit the creation of and deployment of Web based applications. Using the same technology, one could develop a run-time system that would load, construct and run such application definitions. It is therefore possible to build application development and run-time systems that could be distributed across the Web and installed on a client system. We have built such a system and now have the ability to run applications locally via an application runner that builds the final user interface from instructions stored in small project definition and unit files. These files, when compressed and transferred across the Web via activity related to hyperlinks, may call the application runner and pass the uncompressed files to it for execution. This results in the construction and execution of a running application on the client system. The applications built in this manner are identical to local applications installed on the client system, yet their size is much smaller due to the use of component libraries. With the addition of Server based data connectivity and components that can communicate to such servers, applications that are instantiated on the client via the application runner, can access remote data in the same manner as locally installed applications. We can therefore develop quite complex applications that meet the needs of the end-user and duplicate the functionality currently embedded in a typical application suite residing on each client system. Applications such as Word Processors and Spreadsheets could be called to run either from the Web or locally (without a Web connection) using a single installed application that is able to construct such end-user applications from definition files. This could lead to a client system only ever needing a browser and the run-time system. The need to constantly upgrade applications for every new version of an operating system and to wrestle with conflicting DLL versions would become a thing of the past. With the extensibility of package libraries loaded by the run-time system, an end-user would simply download a new version of a library package, or even a totally new library package along with a new application definition in order to run the latest version of an end-user application. Components being what they are, can easily acommodate backward compadibility so that existing application definitions would not be affected by newer version of components. Current Distribution At present we (MorphTek) distribute the Wondgena Designer and Run-time system with a rich set of components that permit the development of fully functional database applications that communicate to a remote database via TCP/IP. We also distribute a central BDE Server that enables these components to communicate with a BDE-registered database. Both the BDE Server and the BDE are intended to reside on a middle-tier server but can also run on the development system. This TCP/IP database connectivity is derived from the ASTA component suite that are distributed in accordance with the royalty-free distribution license. In fact all third-party components we distribute along with the Wondgena project are distributed inside special compiled runtime packages that encapsulate not only the base components but also the registration code for public procedures and functions. We are therefore not on-selling these third-party components, nor will the source code for these components be available through us. Rather the source code must be purchased from the original vendor. We will only distribute re-compiled component packages with the inclusion of public procedure and function registration. Our Future Developments We intend to distribute a very large range of third-party components in re-compiled runtime packages to augment the Wondgena project. Our goal is to produce components that, when combined, will provide a business with the required management functionality. To this end, we are currently developing components that encapsulate business accounting functionality, expanding into retail and manufacturing areas. It is our intention to build components that are not only useful via the Wondgena project but can also be used with Delphi and the Kylix cross-platform development tool. It is our intention to make Wondgena available for both the Windows and the Linux OS and to make Wondgena also run with all popular Internet browsers.