David E. Y. Sarna and George J. Febish
ObjectSoft Corporation
January 1996
For years, desktop applications were developed for use by individuals or small workgroups. The applications were rarely mission-critical, and development teams were generally small enough to sit around a table. Informality was the rule, and the benefits of informality seemed well worth the costs.
No longer. Applications for the Microsoft® Windows® operating system have become an integral part of mission-critical, enterprise-wide systems, and development projects often involve dozens or even hundreds of staff members. Moreover, users want solutions now. But development has become a bottleneck. To reduce development times, lower costs, and respond more quickly to change requests, large-scale code reuse is necessary. Before the release of the Microsoft Visual Basic® programming system version 4.0, Enterprise Edition, however, the tools needed for large-scale code reuse simply were unavailable together in a single integrated product. Some tools were unavailable, period.
The purpose of this technical paper is twofold: (1) to identify some of the special problems and needs of enterprise-wide development; and (2) to describe how Visual Basic 4.0, Enterprise Edition addresses them, with particular emphasis on OLE technology and component-based development. Also included are numerous code examples.
Businesses are investing heavily in enterprise-wide Windows-based development, and for it management requires adequate controls, reliable operation, rapid development, and a decent return on its code investment. However, a mix of development tools is in use throughout these organizations, and reusable components must work with all of them.
A number of requirements are present in such development efforts, primarily the need for support of shared code; separation of the user interface from the business rules and data; support of extensive database activity and a multitier architecture; and management of a large code base.
User-driven, graphical user interface (GUI) applications and distributed development offer well-appreciated advantages over the monolithic, character-based applications and centralized development that characterize the mainframe environment. Yet the mainframe environment provides a certain framework for needs that still must be met. For example, corporate policies must be uniformly enforced. Interest must be calculated in the same way across the board. Credit must be authorized according to uniform standards. Shipping charges must be figured uniformly, and so on. Furthermore, enterprises require a similar look across all applications to reduce time spent on learning to decrease errors, and to accommodate an increasingly mobile work force.
Therefore, an enterprise needs a library of standard forms and business rules that can be shared by many applications, and reliable ways to ensure that corporate standards and forms are followed uniformly. This means that enforcement of coding and design standards is a priority. Once the umbilical cord to the mainframe is cut, however, such enforcement becomes very difficult. Unless specific tools and practices are put into place, corporate policies are apt to be observed more in the breach than in the practice; tight version control and regular nightly backups become goals rather than reality; and flexibility can quickly and easily deteriorate into anarchy, chaos, or even litigation.
Enterprises also must be able to share code cross-enterprise, cross-division, or cross-workgroup, that is, throughout any level of the organizational hierarchy—the more that an enterprise can share code, the less overall code it must develop, the only sure way to reduce development expense and time. Consequently, traditional-style development, where each developer works in nearly complete isolation and fabricates his or her own tools along the way, is simply unacceptable today. Instead, responsible managers everywhere are insisting on reusable and pretested components. To date, the most successful example of a reusable component is the Visual Basic control, which provides straightforward and shareable encapsulation.
As client/server architecture has come to dominate new development efforts, a three-tier approach has become increasingly commonplace (see the Microsoft technical paper “Enterprise Computing with Microsoft Visual Basic" for a fuller discussion of this topic). Essentially this approach calls for a services model with three parts: the user interface, also known as “user services”; the business rules, also known as “business services”; and the data, also known as “data services.” Development tools need to support this approach, not fight it.
This approach contrasts with traditional two-tier architecture, which has either “fat clients” or “fat servers.” "Fat clients" have business rules built into the user interface, an approach that is hard to maintain and can negatively affect performance. This is because too much data needs to be passed to the client. “Fat servers” have business rules built into the database. This too is hard to maintain; it also is hard to program. In addition, the rules of this approach cannot be shared across databases.
The advantage of a three-tier approach is that any tier can be changed with minimal or no impact on other tiers in the hierarchy. Further, a multitier structure is inherently more scaleable, because under it all tiers can coexist on the same physical machine or can be separated as performance considerations require. In addition, the three-tier approach facilitates all enterprise applications using the same business rules, which are enforced by a common set of code.
The challenge then is to enable an application to easily access objects that embody within them the business rules of the organization. These objects can be centrally maintained, while they are used enterprise-wide.
Business rules updates also should be easy to accomplish and should not require recompilation. Therefore, it’s vital that the tools for maintaining business rules be sufficiently robust to provide the full range of language features necessary to develop the complex rules that an enterprise requires. (SQL stored procedures, for example, fall short in this regard.) At the same time, the tools must enable rule changes to be accomplished independently, without recompiling or even communicating with the myriad applications that may be relying on the integrity of these rules. Finally, business rules must be enforced cross-database. This means that stored procedures are not always optimal for business-rule enforcement.
Large enterprises typically support existing databases with many gigabytes of data and high volumes of transactions. Many personal computer-based solutions lack the performance necessary to interact with these databases and are thus limited to operation in a workgroup rather than an enterprise environment. To optimize performance and to increase scalability, “heavy” client code can be moved to the middle tier.
Also commonly found in the enterprise environment are databases that may be distributed in a number of physical locations and may need to be kept synchronized. Often, subsets of data are commonly accessed at specific locations while also needing to be accessible offline. In addition, increasingly mobile employees or contractors must be able to easily disconnect from a central database, continue to access their local database, and then resynchronize upon reconnection.
In a related development, data may be spread across multiple database management systems in multiple locations. In response, “industrial strength” solutions must support a “two-phase” commit strategy that can properly back out of partially completed transactions, even those involving multiple databases, multiple computers, and multiple locations. Furthermore, data must be capable of being moved from one computer to another—for performance or other reasons—without requiring reprogramming of the applications that use the database.
Modern applications for Windows have dozens or even hundreds of software assets: registry files, help files, OLE objects, forms, source modules, project files, resource files, specifications, test plans, documentation, and external DLLs. Each of these assets changes many times throughout the project life cycle. All the changes must be tracked, and it must be easy to return to a previously working release. While existing source-control systems can perform software-asset management, many of them are stand-alone and overly complex, thus discouraging their use.
Also typical in the enterprise environment is the sharing of software assets among developers and across applications. This sharing is not a trivial activity. Each software “build” must be reconstructible in its entirety, that is, the correct version of each resource that went into cutting a specific release must be retrievable. Accordingly, even while one developer is working on a “checked out” asset, other developers may need to perform independent work on their own copies of that asset, with the capability of merging all copies once the independent development is completed. As previously alluded to, most existing version-control and configuration-management software can accomplish these tasks, but at a very high cost in terms of complexity. As a result, busy developers often “work around” their version-control software and thus defeat its purpose.
Together, the Enterprise Edition of Visual Basic 4.0 and OLE technology address enterprise development through support for encapsulation, 32-bit addressing, and three-tier architecture and business-rules enforcement.
Building on the concept of the Visual Basic Custom Control, OLE technology helps facilitate large-scale code reuse by providing for encapsulation. Through encapsulation, a component developer can place specific, tested software functionality in an environment protected from penetration by other software, while providing a well-defined public interface for methods and properties that can be exposed to other developers. Through the OLE standard defining specifications for intercomponent communication, independently developed components can interoperate safely and seamlessly even if none of them has “knowledge” of the others. The components are independent of the tools that use them.
By packaging functionality as OLE components, enterprise developers can easily make the functionality reusable throughout the organization by any tool supporting interoperability with OLE Automation servers. Such tools include all the Microsoft development tools, Microsoft Office for Windows 95, and numerous third-party products. (For more information on OLE components, see the Microsoft technical paper “OLE and Development Tools.”
ole components are maintained separately and independently from ole client applications and can be accessed from anywhere in the enterprise. OLE components are packaged as separate dynamic-link libraries (DLL) or executable files (.exe). They are not compiled into the application that uses them; only the call to the OLE component is bound in. This means that merely installing an updated DLL or .exe on a processor and then updating the registry ensures that its enhanced functionality will be available to calling applications. There is no need to recompile the calling application.
This feature enables multiple levels of control. For example, a department can control its own application while retrieving the latest business rules from an updated OLE component that was installed automatically by the Systems Management Server component of the Microsoft BackOffice™ integrated family of server software.
OLE components written to support modern 32-bit processors and the Microsoft Windows 95 or Windows NT® operating system also can improve the performance and security of enterprise applications. Such components can take full advantage of the 32-bit addressing, more powerful instruction set, increased security, and multitasking and multithreading that modern processors and operating systems provide. In turn, such components can substantially increase the performance of the applications they are used in. This is particularly important because shared OLE components can be called by multiple applications and therefore must operate at top performance.
Traditionally, multiple applications might share a single database, with each application contacting the database individually. In this approach, each application needs some understanding of the database’s underlying structure, its data elements, and its stored procedures. Unfortunately, changes to the database can directly affect the many different applications. Without a central registry to track the applications using a database or in a position to be affected by database changes, such changes can create an administrative nightmare for database administrators and developers alike.
Not so with an OLE-based three-tier architecture. By providing an OLE component that interacts with the database used by multiple applications, individual developers must know (or find out) only about those data elements that are exposed as properties, which they can read or update (with the appropriate permission) by calling standard methods for creating, changing, or deleting records.
In today’s enterprises, data can come from many sources: mainframes, relational database management systems, spreadsheets, word-processing documents, the Internet, and flat files. An OLE-based approach can encapsulate all these kinds of data, freeing users from any need to understand or interact with the various data sources.
Visual Basic 4.0, Enterprise Edition includes the technology Remote Automation, which enables developers to deploy OLE objects across the network, without any changes to the coding of the OLE Automation server. (Of course, no changes are required to the client, either.) This technique facilitates scalability and makes the encapsulated data easily and uniformly accessible across the network.
As a result, internal database structures are of no consequence to the application developer. Structural changes to the database—such as migration of a table from one database to another—affect only one piece of code: the OLE component. Such changes are totally transparent to all the object’s developer-users, whose code is not touched.
In addition, ole-based business rules can be called identically from any application supporting ole Automation servers without regard to programming language and without any knowledge of the server’s internals. This is handy since different tools may be needed for different applications and no one tool can meet all needs. However, because all tools that support calling OLE Automation servers call them identically, this approach eliminates the need for writing a multitude of proprietary wrappers for accessing the same data from multiple solutions created with different tools. In turn, development is quickened and simplified, and identical access is provided to the power user, the corporate developer, and the component builder. This is especially important in an enterprise environment, where different tools may be used in different parts of the organization.
Visual Basic 4.0, Enterprise Edition was designed specifically to address the needs of enterprise-wide development. It does so through a number of features, including built-in source-control software, support for the easy creation of reusable OLE components and in-process servers, network support, security and remote procedure calls, simplified implementation of true three-tier applications, fast and simple database access, streamlined testing, extensibility, and a built-in profiler.
Visual SourceSafe™ is Microsoft’s project-oriented version control software answer for supporting large-scale team development. Thoroughly and seamlessly built into Visual Basic 4.0, Visual SourceSafe enables developers to take advantage of source-code control without having to leave their development environment. Developers can add files and projects, check in and check out files, share files among projects, view project history, protect code, and visually compare and merge different versions of code without having to leave the Visual Basic environment. As a result, developers can create a “release,” which identifies the exact versions of each of the various software assets (code, files, documentation, and so on), by doing nothing more than labeling it. These features are far more robust than those provided in competing version-control products; at the same time, they are so simple to use and so tightly integrated into the environment that there is no temptation to “work around” them.
A key Visual SourceSafe feature enables developers to easily reintegrate copies of code that have been checked out to multiple developers—these developers can work on a single set of code modules in an orderly and controlled fashion. Supporting this feature is a “visual difference” engine enabling easy visual comparison of the difference among multiple versions of the same code. Visual SourceSafe also supports the easy merging of different branches of a module being worked on by different developers, greatly facilitating parallel development.
Last, Visual SourceSafe provides version control for all software assets associated with a release, including documentation and include files—Visual SourceSafe can operate both inside and outside the Visual Basic development environment. As a result, collateral assets such as help files, test plans, and documentation can be kept controlled for version and tightly integrated as a single project in much the same way as the project code itself.
Visual Basic 4.0 enables the easy creation of OLE components that can be reused in many environments, and provides the tools for their automatic registration. This feature is important to the enterprise environment because reusable OLE components (as explained earlier in this paper) are ideal for implementing business rules.
A unique and important feature of Visual Basic 4.0 in both the Professional Edition and the Enterprise Edition is support for the creation of OLE Automation servers.
When an OLE Automation server is created in Visual Basic 4.0, Visual Basic automatically creates a type library describing the exposed OLE interface, thus making components self-documenting. Visual Basic 4.0 also manages all the details of registration during both development and in production with a setup wizard initiating the setup program to properly register all clients as users install them.
Visual Basic 4.0, Enterprise Edition supports the creation of in-process servers, which are OLE Automation servers that can be run as DLLs in the same process as the calling program. This vastly improves OLE performance compared with out-of-process, or .exe, servers. From within Visual Basic 4.0, Enterprise Edition, in-process servers can be created easily by clicking the Make OLE DLL File command on the File menu; they also can be supported in any environment that supports an in-process server. In-process servers are particularly suitable for creating a corporation's standard dialog boxes, data-entry forms, menu structures, and so on. Note, however, that like other DLLs they are not used remotely, because they run inside the client’s own address space.
Creating reusable OLE components with Visual Basic 4.0, Enterprise Edition and organizing them into an object hierarchy requires only a few lines of incremental code. For example, the following code does two things: (1) creates a simple, yet industrial-strength function calculating volume, given length, width, and height; and (2) turns that function into an OLE Automation server, showing the use of both a method and a property.
The example code calculates volume and tracks the sum of volumes from all previous calls:
Public Function Volume(H As Long, W As Long, L As Long) As Long
' Calculate volume from passed height, width, and length.
On Error GoTo BadArg
Volume = H * W * L
SumOfVol = SumOfVol + Volume
Exit Function
BadArg:
Volume = -1
Exit Function
End Function
This function can be executed through the following GUI:
Figure 1. GUI for executing the Volume function
The next code is written for the Volume and Get Sum buttons, respectively, to service the Click events:
Private Sub Command1_Click()
Dim rc As Long
rc = Volume(TxtHeight, TxtWidth, TxtLength)
If rc < 0 Then
MsgBox "Error calculating volume"
Else
MsgBox "Volume = " & Str(rc)
End If
End Sub
Private Sub Command2_Click()
MsgBox "Sum Of All Volumes = " & Str(GetSumOfVolume())
End Sub
Only a few changes are needed to make this functionality available to all development tools by turning it into an OLE server:
The form and related code (which exercises the OLE object) becomes the client and is separated from the server, which contains the actual functionality. It might execute on the same client through OLE or on a different processor from the client using Remote Automation.
Looking at the client first, note that it contains a similar form:
Figure 2. GUI for executing the Volume function
The Form_Load event procedure has these definitions:
Option Explicit
Public VolObj As New VolumeServer.Volume
Whereas Visual Basic 3.0 used the CreateObject function to link to an OLE Automation object, Visual Basic 4.0 has this capability built in. The Dim statement was always able to create a new instance of a form or internal Visual Basic object by use of the New keyword. Visual Basic 4.0 extends this capability to external OLE objects as well. The Public statement in the preceding example defines a new object variable, called VolObj, which is set to a new instance of the volume class in the VolumeServer object. The component called VolObj must be registered in the registration database; another developer uses the References command on the Visual Basic Tools menu to make this object known to the client code.
The code behind the Volume button reads as follows:
Private Sub Command1_Click()
MsgBox "Volume = " & Str(VolObj.Volume(TxtHeight, TxtWidth, TxtLength))
End Sub
The code behind the Get Sum button reads as follows:
Private Sub Command1_Click()
MsgBox "Volume = " & Str(VolObj.Volume(TxtHeight, TxtWidth, TxtLength))
End Sub
All the user interface is controlled by the client, which calls the server and puts the results into a message box—all with a single line of code!
The server itself has no user interface (so it can be used remotely on a different processor on the network). It also contains code very similar to that used in the old-fashioned function call:
Option Explicit
Private SumOfVol As Long
Public Property Get GetSumOfVolume()
' Declare GetSumofVolume as a read-only OLE property.
' Declaring a Public Property Let GetSumOfVolume()allows
' changes to this property.
' Return sum of all volume calculations.
GetSumOfVolume = SumOfVol
End Property
Public Function Volume(H As Long, W As Long, L As Long) As Long
' Calculate volume from passed height, width, and length.
On Error GoTo BadArg
Volume = H * W * L
SumOfVol = SumOfVol + Volume
Exit Function
BadArg:
Err.Raise vbObjectError + 10, "VolumeObject.Volume", _
"Error calculating volume"
Exit Function
End Function
In either case, the same messages will be displayed from the GUI.
In the past, writing an OLE server might have required several thousand lines of difficult C++ code. Here, it took only a few lines of code beyond that needed to code the application itself.
It’s worthwhile to note that not only can developers create OLE components easily through Visual Basic 4.0, Enterprise Edition, but also that they can use those components in any environment supporting OLE Automation. Such environments include Office for Windows 95, Visual Basic 3.0 and 4.0, Microsoft Access 2.0, Microsoft Access for Windows 95, Microsoft Visual C++®, and Microsoft Visual FoxPro™. They also include third-party development tools and applications such as Lotus Approach, Sybase PowerBuilder, Borland C++ and Paradox, and WordPerfect Office. The same OLE component created with the preceding code can be called as-is from within any of these environments.
Visual Basic 4.0, Enterprise Edition supports Remote Automation over both local and wide area networks, facilitating centralized control and access from many calling objects. No code changes are necessary to support an OLE object using Remote Automation, and any “cross-process” OLE server (an .exe, for example) can be supported “over the wire” with no code changes to either client or server. Most standard network protocols, such as TCP/IP and Named Pipes, are supported.
Remote Automation essentially replaces the local procedure call used by OLE when the client and the server are physically executing on the same processor with a full-featured remote procedure call (RPC). Remote Automation supports all seven levels of security defined for RPCs, ranging from unprotected access to encrypted, authorized, and authenticated access—whatever is most appropriate for the specific application.
In addition, Visual Basic 4.0, Enterprise Edition provides simple tools for managing objects on remote clients. One such tool, the Component Manager, enables developers to catalog, identify, locate, and distribute OLE servers in a networked environment. Another tool, the Pool Manager, optimizes OLE performance in a distributed environment by maintaining pools of objects that can be distributed to clients on demand. A third tool, the Automation Manager, is a multithreaded application that runs on the remote (server) computer and replaces the original OLE proxy and stub with RPCs that communicate over the network.
By enabling developers to use OLE objects for business services and data services, Visual Basic 4.0, Enterprise Edition greatly simplifies the programming required for implementing true three-tier applications. For example, business objects are typically represented by nouns, such as Customer, Employee, Product, Invoice, and Order. Actions or methods that an object can be asked to perform are represented by verbs, such as Purchase, Ship, Generate, Pay, Print, and Fax.
Properties, which are the individual fields describing an instance of an object, may be represented by the following forms, for example: Employee_Number, Base_Pay, Policy_Number.
For data service, typical methods might be the following: Create, Read, Update, or Delete.
The rules associated with a method, such as the business rules Purchase or Pay, can be changed without negatively affecting the user services. Similarly, how Create or Read work can be changed (for example, by moving something from one table to another) without affecting either the business services or the user services. Also an object often has two roles. It can be a supplier of services to users as well as a consumer of other services, thus creating a hierarchy that is naturally scaleable and screens unnecessary detail.
Visual Basic 4.0, Enterprise Edition builds on the database support of Visual Basic 3.0 and provides a rich set of tools that provide great flexibility to developers. In addition to the Data control feature supported in all editions of Visual Basic 4.0, the Enterprise Edition provides a new RemoteData control feature connecting directly to the ODBC driver manager. All data-aware bound controls can use RemoteData control as a data source and thereby greatly improve the performance of access to such client/server databases as Microsoft SQL Server™ 6.0, Oracle®, and ODBC through grids, list boxes, and other easy-to-program bound controls.
Moreover, the Microsoft Jet database engine that comes with Visual Basic 4.0 provides some functionality unavailable in ODBC. For example, the new, high-performance 32-bit version of the Jet engine (version 3.0) facilitates heterogeneous joins across dissimilar databases. Direct calls to the ODBC API and the Visual Basic Library for SQL Server API continue to be supported too.
Also in Visual Basic 4.0, Enterprise and Professional Editions, is automatic synchronization of multiple replicas of the same database. This can improve the way users share data. Replicas can be located on different computers anywhere there is network connectivity, yet stay synchronized with each other. This is a very useful technique for enabling database access by dispersed users, such as mobile salespeople. The technique also can be used to improve performance, by sharing the workload across multiple systems where immediate updating is not required. Replicas can be synchronized using the Windows Briefcase and Microsoft Access for Windows 95, or the Synchronize method provided with Visual Basic 4.0. Note, however, that transactions are not processed across replicas, making the technique unsuitable for such real-time systems as money transfers.
Creating a multiple-processor environment for testing client/server applications can be complex, time-consuming, and expensive. Visual Basic 4.0, Enterprise Edition addresses this problem by enabling developers to run multiple copies of Visual Basic 4.0 on a single processor, even in debug mode. Consequently, developers can perform complete testing of distributed applications—end to end—on a single processor, independent of network and connectivity issues, greatly simplifying and shortening the testing process.
As an OLE server itself, Visual Basic 4.0 provides native support for add-ins that can enforce corporate standards or otherwise add value by providing custom features, such as form generators, templates, or style enforcers. The add-ins can be created using Visual Basic 4.0. Conditional compiler instructions enable developers to maintain the same piece of code for 16-bit applications and for 32-bit applications, or for different variants of the same theme.
With its built-in profiler, Visual Basic 4.0, Enterprise Edition provides details of coverage, such as how much of a certain code segment was executed and information on resource usage, showing exactly where time is spent, for example. For developing complex client/server applications, such features are a must—they help developers identify resource bottlenecks that are candidates for optimization and highlight untested portions of code so as to improve test scripts.
Visual Basic 4.0 provides a speedy and robust platform for addressing the complex requirements of enterprise-wide, multideveloper, client/server projects. Such features as high-performance remote data control, support for building and deploying reusable components enterprise-wide, and versatile built-in source-control software—together with all the traditional advantages of Visual Basic in terms of ease of development, debugging, and maintenance—set a new standard for enterprise-wide development tools.