Valor Whisler and Jim Soiland
August 30, 1997
Valor Whisler is an applications architect specializing in user interface and system design and development. Valor has designed and developed numerous successful commercial products including VB AppFramework and the Repository Browser. Jim Soiland is a software engineer specializing in Visual Basic and Microsoft BackOffice technologies. Valor can be reached at valorw@ix.netcom.com.
The sample application that accompanies this paper provides the opportunity to take a detailed look at the migration process and development techniques discussed in this article. Two readme files provide instructions to set up both the original Visual Basic application and the migrated Visual InterDev Web application.
Click here to view or copy the sample files related to this technical article.
This document describes how Microsoft® Visual Basic®, combined with Microsoft Visual InterDev™ and Microsoft BackOffice® technologies, can be used to build cross-platform Web applications. In doing so it shows how Visual Basic developers can use their existing code and skills to build fully encapsulated, Visual Basic server-side components that provide the business logic for the application, while using Microsoft Visual InterDev to integrate and manage these components within a Web application.
The compulsion to move to the Web is so overpowering that it is safe to say that every software engineer will be faced with the prospect of Web development. Most developers have their opinion of the value of the Web—it may be over-hyped—but one thing is crystal clear: it is a powerful communications channel that we can count as we develop our next generation of systems. While communication is one compelling benefit contributing to the continued growth of the Web, seamless distribution of application logic is another particularly compelling benefit of moving to an intranet architecture for applications traditionally deployed as pure client/server applications. For example, organizations are able to dramatically reduce their deployment and maintenance cost by building their applications in such a way that the logic is centralized on controlled servers. Users need only a standard Web browser in order to access and use that application over the corporate network. If that application functionality is later updated, instead of deploying the new application to potentially tens of thousands of desktops across the organization, information systems (IS) managers need only update the logic running on the server, and the next time any user accesses that application over the intranet they are running the new version.
The Web forms a communications medium that allows for distributed objects to be easily brought together. Almost every page you view utilizes this fundamental architecture to combine text, graphics, and active objects into a single presentation. This capability requires a change in the way that an application is designed and developed.
The logical architecture of a Web application is very similar to that of a client/server, or n-tiered architecture. There are, however, some key physical differences. For example, a traditional Visual Basic client/server application has a user interface constructed in the Visual Basic forms environment. For a Web application, the user interface is defined using the Hypertext Markup Language (HTML) standard. In such an architecture, the HTML page provides a user interface and a Web server, such as the Microsoft Internet Information Server (IIS), facilitates the back-end processing. The following diagrams help to illustrate the differences and similarities between Web and client/server architectures. These diagrams illustrate one simple usage scenario—there are many other possible types of architectures.
Figure 1. Client/server architecture
In client/server architecture, a Visual Basic application sends requests to a Microsoft SQL Server™ using a private network. This is usually some type of local area network (LAN) or wide area network (WAN). The server processes these requests and returns data. It is completely up to the Visual Basic application to interpret and display this data.
Figure 2. Web architecture
In Web architecture, an HTML form in a Web browser serves as the user interface and is served up to the user on demand by IIS. The user submits the form, and the information that is entered is returned to IIS using HTML methods such as Post. IIS can then use an Active Server Page (ASP) to process the input data and return a result page to the user.
Notice that within the Web architecture diagram (Figure 2) there is no logic being invoked on the client side. The Internet browser is merely displaying HTML pages and transporting data to and from the server. There are several ways to utilize logic on the client side, including scripting (Microsoft JScript™ or Microsoft Visual Basic, Scripting Edition [VBScript]), Java applets, and ActiveX™ controls, but the diagram reflects one of the most typical usage scenarios found today, where all application logic is server-based (the thinnest client possible).
Another key difference in the scenario above is that the communication between the Web browser and server is over the HTTP protocol, and there is no persistent connection between the clients and the server. This has several advantages, especially in terms of scalability, but also introduces development hurdles such as the need to manage user/session states as individual users navigate between pages.
Here are some key characteristics of Web architectures:
This section describes a simple Visual Basic application that was built as a stand-alone application and how it can be moved to the Web. There is source provided for the Visual Basic application, the Visual Basic components, and the Web application created using Visual InterDev. The following section outlines the methodology used to create both applications.
Figure 3. A Visual Basic application
Figure 3 shows a Visual Basic application that employs a component architecture that is used to separate the business logic from the user interface. Generally, business logic is more sophisticated, but for demonstration purposes, the business logic has been limited to validation routines. This is done to take advantage of the reusability potential of the validation objects and to physically segment the development workload in a team development environment. In addition, this architecture supports distribution of the validation objects onto separate machines, providing a more scaleable architecture. In this example, for simplicity there is no database interaction, but typically the business logic components would also interface with a back-end DBMS.
The two validation objects are constructed as ActiveX DLLs (they are Component Object Model (COM) components) but they could also be made into ActiveX EXEs. They are: (1) a Name & Address Validation Server and (2) a Credit Card Validation Server. The Name & Address Validation Server uses sets of business rules to determine the validity of the name and address. If the data is invalid an error message is generated. The Credit Card Validation Server is called to validate a credit card. One could envision that this server could, in turn, call up an external credit card validation service bureau to perform this task.
Figure 4. A Visual InterDev Web application with Visual Basic components
Figure 4 shows the same Visual Basic application re-architected for Web deployment using Visual InterDev. The name, address, and credit card input have been redone as an HTML form. Information entered into this form is sent to an ASP. The ASP invokes the two Visual Basic validation DLLs. If either server does not validate the data, it provides an error message that can be propagated back to a user via the ASP. Note that the two validation DLLs shown in the Web architecture are physically the exact same DLLs used in the stand-alone Visual Basic application. Thus, the original component architecture that was employed in the stand-alone application can be reused in the Web application.
Note Business objects can perform any type of task that is possible using the Visual Basic programming environment—in this example they merely perform validation tasks.
Figure 5. The Visual Basic form
Figure 6. The Web form
Due to the open nature of the Web’s architecture, there are many possible ways to design and develop an application. This section introduces one possible methodology—one that effectively uses existing Visual Basic skills, tools training, and existing code base—by using Visual InterDev to create and manage the HTML and Active Server Pages. Here is a high-level view of the methodology that we used:
a.User interface
b.Web
c.Business rules
d.Data
Define the functions that are to be provided by each service.
Note With Active Server Pages, all the glue code that invokes and uses the components can be defined in VBScript, which in most cases can be easily re-used from existing Visual Basic applications.
Figure 7. Application services
The Web is a powerful medium—an open communications channel with a standardized set of protocols. In many situations, monolithic or even locally componentized applications will give way to highly distributed, asynchronous, Web-based applications. Yes, the specific architectures and methodologies will change dramatically, but the underlying way that a user interacts with an application will not. The benefits of this migration include the ability for customers and business partners to participate as users of the application over the Internet, and the ability for corporations to dramatically reduce their deployment and maintenance costs for internal, intranet applications.
It is important to use existing skill sets and tool sets during this migration and to pick the best-of-breed tools with which to move ahead. Microsoft Visual Basic provides a mature development platform for Web development in terms of building the hard-core business logic behind a Web application in the form of server-side components. Microsoft Visual InterDev provides a development platform for building and managing the overall Web application in the form of a Web site with an HTML user interface and Active Server Pages to invoke and integrate the back-end components. This combination enables existing Visual Basic developers to realize all the benefits of cross-platform Web applications while using their existing code, expertise, and tools.