by Azam A. Mirza
The three years since the Internet revolution started have radically changed the landscape for software development. Just when client/server technology was taking hold in the enterprise, the World Wide Web and its technologies have introduced a new metaphor for building, deploying, and using applications.
With its support for standards-based component software such as Java applets and ActiveX controls, its standards-based client user interface through the web browser, and its standards-based communications protocols, the web is an exciting opportunity for building applications that can be truly heterogeneous across the enterprise. By standardizing the least important aspects of software development, the web takes the focus away from delivery and presentation and puts it in the content being presented. As a developer, you don't have to worry about how to transport the content or how to fashion the user interface; instead, you can devote your efforts to building the application logic that best handles a given scenario. However, content delivery and a compelling user interface are also very important to the creation of a successful web site. The World Wide Web also presents an enormous amount of risk for enterprises moving into Internet-based software development. The rapid pace of technology change and the unending stream of product and standards upgrades makes it difficult to stay current and relevant.
Most organizations today have a large number of applications and existing systems running in the enterprise. These systems range anywhere from "old" legacy systems, such as COBOL and FORTRAN programs, to "new" legacy systems, such as Visual Basic and C applications. The last few years have seen a push to move from legacy systems to the client/server environment. Organizations have spent a considerable amount of time, money, and resources in updating their old systems for the 21st century, only to find out that the Internet has rendered their best-laid plans obsolete.
Few organizations are willing to embark on reengineering their systems from scratch again. Instead, they're looking for ways to leverage their existing applications for the Internet. Microsoft's strategy for Internet development is simple and has followed a clear path since day one: leverage the tools and technologies of today and Internet-enable them for the future. Microsoft has web-enabled its entire line of server, client, productivity software, and development tools over the last two years. It also has filled the gaps in its product line by introducing web tools such as FrontPage, Visual InterDev, and Internet Explorer to provide a comprehensive and complete solution.
Rather than retrain software professionals, you can use the existing expertise of your developers in tools such as Visual C++ and Visual Basic to make them successful web developers. The following sections discuss how to identify existing applications as candidates for migration to the Internet and how to follow a step-by-step method for doing so regardless of what development tool the applications were written in. Lastly, this chapter tackles the migration issues in the light of the Visual Basic development environment and how Microsoft provides tools and techniques for Internet-enabling your existing VB application. n
The concepts of components and multitier architectures have been the main focus of software development recently. Most software developers recognize the potential and benefits of the component-based software development approach. However, most organizations have a large installed base of legacy applications that have no concept of componentization or multitier architectures. To move into the Internet world, organizations have to rewrite or move their existing applications to the web.
The ease or difficulties of moving your existing applications to the I-net environment depend largely on the languages these applications are written in and the platforms they run on.
Traditional legacy applications are still the most widely deployed and used environment. Legacy code isn't defined by the language used or the platform being supported, however--it's identified by the method used to develop the applications. Most legacy code is written in COBOL or FORTRAN but can also include procedural programs written in C and BASIC. Most legacy applications run entirely on the server side and use the client only for display and user input. Figure 19.1 depicts a typical legacy application environment.
FIG. 19.1
Legacy systems typically placed all processing logic on the server side.
For applications written in legacy environments with third-generation languages such as COBOL or FORTRAN, it's usually a simple matter of converting the business logic into modules that can be encapsulated into components or accessed through a wrapper built by using a language such as Visual C++. A lot of work is being done in developing connectivity mechanisms for web-enabling old legacy platforms.
This discussion does beg the question, why use legacy applications and languages? Millions of lines of legacy code are in production environments, and millions more are added each year. Organizations have spent considerable time and resources building and deploying these systems and training professionals in these technologies. It's not practical or possible to throw away all that effort and expertise. For that reason, it's best to leverage these applications--by developing methods to move them into the new environment, and by building wrappers around them to provide access to the built-in logic and at the same time provide a means for moving into the latest tools and technologies. Figure 19.2 shows a sample scenario for leveraging the power of existing legacy applications in the World Wide Web environment.
As mentioned earlier, a large number of organizations are still engaged in maintaining or enhancing legacy applications. If these organizations were to move completely away from developing any new applications with legacy tools, there would still be a need to maintain current production systems. Usually, the current developers are entrusted with the task of doing maintenance work, although most developers aren't happy doing just maintenance work. They can integrate their skills and knowledge of the existing systems into the migration efforts to new systems by working with the new development teams.
FIG. 19.2
You can use Visual Basic to build wrapper DLLs around legacy code for access from
a web browser.
With the advancement in computer technology and the advent of personal computers, computer systems have moved away from the mainframe legacy model toward the networked client/server approach. In client/server systems, processing isn't limited to the servers on the back end, but is distributed among the client machines and the server machines. Figure 19.3 shows the traditional client/server environment.
FIG. 19.3
In traditional client/server architectures, clients usually encapsulate the bulk
of the processing logic, and the server stores the data.
The client/server process takes the work away from the server and distributes it more judiciously by using software components that communicate with each other with well-defined interfaces and networking protocols. The client/server approach also allows you to take advantage of the platform on which the various components will be deployed. The client/server approach requires a major shift in the development thinking process. Rather than build large, monolithic, standalone systems, you have to begin thinking in terms of components and modules that individually provide various functionality and combine to make a complete system.
The development of each component in the client/server environment can be viewed as a small standalone project independent of other projects.
Multitier systems extend the traditional client/server concept. A multitier design is one in which an application's implementation is divided into three distinct areas: user interface, business logic, and database system. These three components were initially referred to as three-tier client/server. However, the extension of three-tier in multitier is a simple matter of distributing the business logic and database systems across multiple machines in the enterprise in the form of components that perform specific tasks.
Figure 19.4 shows a sample multitier client/server architecture. This division of services allows you to logically separate the application and introduce a layer of abstraction between the enterprise data and the clients that access it.
FIG. 19.4
The multitier client/server architecture allows component-based units to provide
different functionality.
User Interface The user interface is the visual part of a multitier architecture responsible for generating output on client machines and obtaining user input. It usually resides on client machines and is responsible for displaying data to users, allowing users to manipulate the data and communicating with the business logic components to validate or generate appropriate data. The forms, controls, menus, and messages displayed on user machines are all part of the user interface. In client/server systems, developers built from scratch user interface elements. In the web-enabled environment, however, the web browser acts as a container for user interface elements. Figure 19.5 shows a typical user interface for a multitier web-enabled application.
FIG. 19.5
Internet Explorer acts as the client component in web applications.
Business Logic The business logic component of a multitier architecture houses the business-specific rules. Business rules are components designed to interact with the database to retrieve and present data to the user based on defined rules. Typical examples of business logic components include
Business logic components are nonvisual, don't have any user interface elements such as menus and text boxes, and usually reside on distributed machines across the enterprise. OLE Automation servers (also referred to as ActiveX Server Components) are examples of a mechanism used for distributing business logic.
TIP: Visual Basic Enterprise Edition includes samples that illustrate the use of business logic components in a real-world application. Refer to the Visual Basic documentation on how you can install and run these samples.
Database System The database system is primarily responsible for storing and providing data. Typical examples include the Relational Database Management Systems (RDBMS) and other storage media. The database is responsible only for data storage, recovery, validity, integrity, and replication. You can use multiple database systems within a single system, each handling the data requirements for a specific purpose. Database systems are true back-end systems that don't include any user interface or business logic systems. Database systems hold a very prominent place in the Internet-enabled application arena. As the World Wide Web moves from static content to a dynamic, ever-changing applications-based environment, more and more emphasis will be placed on using back-end databases to store data and information being supplied to users. The tight integration between Microsoft SQL Server and Internet Information Server is a good indicator of how important database systems will be in the Internet world. Also, tools such as Visual InterDev, Visual Basic, and Visual C++ provide numerous powerful methods for accessing data stored in corporate databases from web-enabled applications. These methods include the tried-and-true ODBC (Open Database Connectivity) method and the DAO (Data Access Objects), RDO (Remote Data Objects), and ADO (ActiveX Data Objects) methods.
The component-based approach to software development splits the development process into a bunch of small projects geared toward building each individual component. The concept is to be able to share these components across multiple applications, providing the much-coveted reuse of the services provided by the components. The task of building a business solution from these components is what results in a standalone application.
NOTE: The concept of sharable, reusable components for building applications was first introduced with Visual Basic in the form of VBXs (Visual Basic Custom Controls). OCXs (OLE Custom Controls), ActiveX controls, and OLE Automation Server are all enhancements of the original idea adapted to provide compatibility with emerging technologies such as the World Wide Web.
Components are usually compiled binary objects that provide runtime reuse and sharing of objects. The component-based approach provides a multitude of advantages over traditional software development methods, including the following:
As noted, the component-based software development methodology has been in existence since Visual Basic was first introduced. With the World Wide Web's popularity, Microsoft has moved quickly to adapt its component architecture to embrace the web. With the introduction of ActiveX and the embracing of Java technology through the introduction of Visual J++, Microsoft provides a strong suite of solutions for building component-based web applications. Figure 19.6 illustrates the ActiveX strategy for building component solutions for the web-based environment.
FIG. 19.6
ActiveX is a set of technologies that let you build applications for the I-net
environment.
You can develop ActiveX components in any number of tools (including Visual C++, Visual Basic, and Visual J++) and can run them on a number of platforms (including Microsoft Windows 95, Windows NT, Macintosh, and UNIX). Combining Java and OLE, ActiveX provides promising capabilities for building I-net applications while extending and enhancing the capabilities of existing tools and environments.
ActiveX allows developers to freely mix and match controls created in different development environments on clients and servers. For example, you can develop an ActiveX control in Visual Basic that provides charting capabilities on the client, an ActiveX server component that calculates the sales growth rates for the company in Visual C++, and use Visual InterDev to use both of these two components as part of a web-based application.
Web applications based on ActiveX components and Java provide benefits for all aspects of software development. End users benefit by gaining dynamic, content-rich applications for I-nets through the use of a single client interface such as Internet Explorer. You can leverage existing expertise and knowledge of tools such as Visual Basic and Visual C++ to build powerful components and applications for use in the I-net environment. Organizations gain the benefits of an open, standards-based environment and technologies, retain the investments in existing systems, and are able to build new applications with the exciting new technologies.
The first steps in migrating Visual Basic applications to the I-net environment involves identifying and targeting the project candidates for such an undertaking. The following are some guidelines that you can use to determine the most appropriate migration method:
FIG. 19.7
You can use FrontPage 97 to incorporate ActiveX controls in your applications.
TIP: This method isn't exclusive to Visual Basic and can just as easily be applied to Visual C++ or other tools. However, other tools can't match the ease associated with doing it in Visual Basic.
FIG. 19.8
An ActiveX DLL can encapsulate a set of common business rules that can be loaded
as part of an application.
FIG. 19.9
An out-of-process ActiveX component can provide server-side processing functionality.
FIG. 19.10
Microsoft Word documents are an example of an ActiveX document and container application
concept.
The rest of this chapter concentrates specifically on the ActiveX documents concepts and how you can use them to migrate your entire applications over to the I-net environment.
ActiveX documents are the oldest concept from the original OLE specification. All Microsoft products, such as Word and Excel, are based on the Document View architecture. Visual Basic ActiveX documents take the Microsoft Word metaphor to a new level and really blur the line between a document and an application. Visual Basic ActiveX documents are truly applications that behave like documents. Figure 19.11 shows an ActiveX document within the Internet Explorer environment.
FIG. 19.11
You can contain Visual Basic ActiveX documents in an ActiveX container such as
Internet Explorer.
When you create an ActiveX document-based project, you're creating a Visual Basic document that can be contained within a container. When you compile a Visual Basic ActiveX document project, a Visual Basic document file (.vbd) and its corresponding container/server (an ActiveX DLL or EXE) are created. The document file and the DLL or EXE file are similar to the Word .doc file and the Winword.exe application relationship. The .vbd file provides the document, and the DLL or EXE provides the objects that allow another ActiveX container such as Internet Explorer to host, view, and activate the document.
Several advantages to using ActiveX documents as a means of migrating your current applications to the I-net environment include the following:
The following section discusses the details of creating an ActiveX document by using Visual Basic 5.0.
Creating ActiveX Documents The process of creating an ActiveX document is like creating any other project in Visual Basic. To create an ActiveX document project, follow these steps:
FIG. 19.12
An ActiveX document can contain other ActiveX controls to provide required functionality.
FIG. 19.13
Internet Explorer functions as the container that hosts the ActiveX document.
The .exe or .dll file contains the actual compiled code. Initially, the .vbd file contains the class ID of the .exe or the .dll file. If you choose to allow users to save data (using PropertyBag), the data will also be stored in the .vbd file. Users can view your ActiveX document by opening the .vbd file in a host application.
Anatomy of an ActiveX Document The basic parts of an ActiveX document include the UserDocument objects, accompanying code, standalone code modules, and controls placed on the UserDocument and its associated code. Figure 19.14 shows a sample ActiveX document and its parts.
FIG. 19.14
Visual Basic provides a comprehensive development environment for ActiveX documents.
Similar to Visual Basic forms, document files are also stored as .dob text files and also include a supporting .dox file for storing binary objects such as bitmaps, similar to the .frx file associated with Visual Basic forms. The .dob and .dox files define the document's properties, methods, and user interface elements.
The accompanying compiled files include the .dll or .exe server component and the document file with the .vbd extension. Figure 19.15 shows what happens when you compile an ActiveX document project.
FIG. 19.15
The compiled project produces two files for the ActiveX document.
TIP: After you compile your ActiveX document, you can rename the .vbd file to any extension--for example, from MyDoc.vbd to MyDoc.htm.
Using Internet-Specific Features in ActiveX Documents ActiveX documents allow you to take advantage of the Internet through the use of two supplied mechanisms:
Private Sub img1_Click() UserDocument.Hyperlink.NavigateTo "http://www.gasullivan.com" End Sub
Private Sub UserDocument_InitProperties()
`Place this code in the InitProperties event of the UserDocument
UserDocument.AsyncRead "c:\images\gaslogo.bmp", _
vbAsyncTypeFile, "GASLogo"
End Sub
Private Sub UserDocument_AsyncReadComplete (AsyncProp As VB.AsyncProperty)
` Check to see if the call has been made to load the picture and then do so.
Select Case AsyncProp.PropertyName
Case "GASLogo"
Picture1.Picture = _
LoadPicture(AsyncProp.Value)
End Select
End Sub
As stated earlier, one very important feature of Visual Basic 5.0 is the capability to migrate an existing standard VB form to a UserDocument object. This is done by using the ActiveX Document Migration Wizard. This wizard offers great potential because large applications written in VB4, for example, can be migrated with minimal effort.
If you're concerned about version conflicts, take comfort in portability features. You can configure the Migration Wizard to disable nonportable code automatically, meaning that the wizard will flag code that's inconsistent with the properties and methods of the UserDocument object.
TIP: Most exceptions encountered during migration involve invalid form properties in UserDocuments. Let the wizard disable the code so that you can locate and replace it at a later time. Make sure that all form controls are included in the current project and referenced appropriately.
Converting a form to a UserDocument can occur in one of the following ways:
CAUTION: In any case, the form to be converted must be an object in the current Project Explorer. If it's not, you must add the form through the Project menu, but be sure to back up the form before you attempt any migration. If you're developing in an environment that uses Visual SourceSafe or another similar version control package, undo the form checkout and use the local copy of the form in case the conversion doesn't go as you want it to.
Bear the following in mind when converting a form:
NOTE: Events present on a form that aren't found on the UserDocument include Activate, Deactivate, LinkClose, LinkError, LinkExecute, LinkOpen, Load, QueryUnload, and Unload. Events present on the UserDocument but not found on a form object include AsycReadComplete, EnterFocus, ExitFocus, Hide, InitProperties, ReadProperties, Scroll, Show, and WriteProperties.
NOTE: Because the UserDocument object doesn't support embedded OLE objects, the OLE control in the toolbox is disabled whenever a UserDocument is active in the IDE.
Before you can migrate a form to a UserDocument, you have to activate the migration tool. You must activate the ActiveX Document Migration Wizard, included as an add-in to VB5, before you can use it. After it's activated, the wizard is available for every project.
To activate the wizard, choose Add-Ins, Add-In Manager from the menu. In the Add-Ins Manager dialog box, select the VB ActiveX Document Migration Wizard from the list of available entries and click OK. From this point, the Migration Wizard option will be found under the Add-Ins menu.
Visual Basic's Professional and Enterprise Editions include the ActiveX Document Migration Wizard, which is designed to help you convert your existing forms into ActiveX documents for use in I-net environments.
NOTE: The ActiveX Document Migration Wizard converts forms to ActiveX documents but doesn't create an ActiveX document-based application from your form-based project.
The following tasks are performed when you convert a regular form to an ActiveX document:
To use the ActiveX Document Migration Wizard to convert a form, follow these steps:
FIG. 19.16
The Add-In Manager allows you to add various productivity applications to your
Visual Basic development environment.
FIG. 19.17
Select the forms you want to convert to ActiveX documents from the list.
FIG. 19.18
You can remove your old forms from the project by selecting the appropriate checkbox.
FIG. 19.19
Use the Save Current Settings as Default option to save your wizard options.
FIG. 19.20
You can save the summary report for later reference by using the Save button.
The project window now includes the new UserDocument. You can test the ActiveX document by running the application, launching Internet Explorer, and then opening the UserDocument.vbd file.
TIP: The Summary Report window provides detailed steps for testing and debugging the ActiveX documents with Internet Explorer.
In this chapter, you learned about some of the current software-development technologies and how they relate to the Internet and Internet-enabled application development efforts. You also were introduced to the features built into Visual Basic for migrating traditional applications to the I-net environment. You learned about ActiveX documents and how they provide a powerful mechanism for encapsulating existing applications in the Internet framework. Other chapters in this book provide a detailed look at some of the other components of Visual Studio that allow you to take full advantage of all of Microsoft's technologies for building and leveraging the I-net environment:
© Copyright, Macmillan Computer Publishing. All rights reserved.