Microsoft stakes its claim in the enterprise-wide application development landscape.
Microsoft Visual Basic was one of the first tools that brought drag-and-drop component-based RAD (rapid application development) to the Windows 3.0 revolution. Long the 300-pound gorilla of client/server development, it extended client/server capabilities to grab a large portion of that market--a market it still holds today.
The Visual Basic revolution of the early '90s paved the way for today's evolution. Earlier versions of Visual Basic, while providing an easy-to-use development environment for Windows, could not comfortably scale to the enterprise. Visual Basic became a niche player in RAD and workgroup client/server development. With the release of its latest rendering, Visual Basic 4.0, Microsoft may prove that it is a player in the multi-tiered client/server development market.
But is Visual Basic 4.0 really ready for the enterprise? And, more important, is the enterprise ready for Visual Basic 4.0? Let's explore the new features of Visual Basic 4.0, including its new reliance on OLE, latest database features, language enhancements, and new application partitioning capabilities for multi-tiered development; then you can decide for yourself.
Of the many new features that you would expect with a new release, the most significant is that Microsoft rewired Visual Basic 4.0 for OLE (Object Linking and Embedding). For the last two years OLE, which is a standard of "interoperation" among applications and application components, has been the mantra of Microsoft. It was not until the release of Windows 95, and now Visual Basic 4.0, that developers could finally release the potential of OLE for component-based development and object distribution.
All of the Visual Basic controls are now based on OLE. The benefit is that all OLE controls are managed by Windows itself. Therefore, they are easier to find and reuse, and Windows does the version control for you. In addition, Visual Basic itself is an OLE server, meaning that it exposes objects, properties, and methods that applications can use to customize Visual Basic.
With Visual Basic 4.0, you can also write OLE servers that can provide functionality to other applications. Later in this article, I describe how to create OLE servers. Having created part or all of a Visual Basic application as an OLE server, other developers can use it locally or over a network.
Developers can now create and distribute OLE objects and share them with other applications on the network. Through these distributed OLE objects (using a variety of object-access and data-access tools), Visual Basic 4.0 finally supports multi-tier client/server development.
The widely popular VBXs (Visual Basic controls) are no longer the staple of Visual Basic. OCXs (OLE custom controls), which use subsets of OLE technology, replace VBX building blocks for applications. Although VBXs have been adopted in other development environments such as PowerBuilder, Delphi, Microsoft Visual C++, and Borland C++, many developers consider the VBX standard a kludge. (VBXs are not based on a widely accepted standard. They are really designed just for Visual Basic, and they were never designed to be used with other development environments. Moreover, every VBX that interacts with its environment assumes that it is interacting with Visual Basic.)
The OLE standard that is built into OCXs is much broader than the VBX standard (OCXs are 32-bit, while VBXs are 16-bit). The OLE standard enables other applications to incorporate OCXs into their environments, because OLE is built directly into Windows 95 and Windows NT. Plus, the operating system itself is able to track OLE components for the applications implementing them, whereas the operating system does not keep track of VBXs.
Microsoft has made a firm commitment to an OLE-based future. As a result, hundreds of companies that currently sell VBXs are now scrambling to rewrite their VBXs as OCXs for the new market. Fortunately, Microsoft provides a migration toolkit that makes the move relatively painless. If you've written your own VBXs, it's time to think about converting.
But OLE is only part of the story. With release 4.0, developers can create DLLs entirely within Visual Basic, thereby avoiding clumsy 3GLs. There are several database improvements as well, from replication and "fat" cursors to enhanced referential integrity. (Using "fat" cursors, developers can customize the size of the local data cache to maintain more data from an answer set on the client, thus reducing network traffic. However, this approach does require more local resources.) The rebuilt 32-bit JET 3.0 database engine is the power behind these new database features.
Visual Basic also comes with new migration tools that let developers compile conditionally. This approach lets developers deploy a single code base on both Windows 3.1 (Win16) and Windows 95 (Win32). Visual Basic is ready to take your existing 16-bit Visual Basic applications to 32-bit. For example, when you open a Visual Basic 3.0 application, Visual Basic 4.0 prompts you to replace all existing VBXs with OCXs.
Finally, Visual Basic opens up the menu API (using OLE, of course), and has a new category of complementary products known as add-ins. Not to be confused with VBXs or OCXs, add-ins connect directly into the Visual Basic 4.0 IDE and provide services such as data modeling tools, code management, and project management. The best known add-in is the SourceSafe version-control tool (which Microsoft includes with the Enterprise addition of Visual Basic).
You can purchase Visual Basic 4.0 in three packages: the Standard Edition ($99), for those of you who need only 32-bit development; the Professional Edition ($499), which supports both 32-bit and 16-bit development with conditional compilation options; and the Enterprise Edition ($999), which includes a code profiler and SourceSafe.
If you want to become a great Visual Basic 4.0 developer, you'll need to learn how OLE fits into the tool. The success of Visual Basic 4.0 is directly linked to the success of OLE, even though OLE has been difficult to implement thus far. The API is difficult to use and understand, and OLE support among tools has been erratic.
But Visual Basic 4.0 could be the first development tool that makes OLE a reality for most organizations. OLE is also the middleware layer for distributed Visual Basic applications using Distributed OLE. Moreover, the OLE technology lets developers encapsulate things such as legacy code and business processes into OLE Automation Servers, which are reusable across the enterprise.
Automation Servers can be single- or multi-user, and they can provide services requested by other objects, either locally or over a network. Basically, any portion of an application that you need to share with other applications is a good candidate for OLE Automation Servers. In a nutshell, OLE Automation Servers let developers "componentize" applications. This lets developers isolate chunks of application logic, which can later be modified independently. For example, developers of a tax application may want to place the tax calculation logic that changes yearly into its own OLE Automation Server, which can then share several applications (locally or centrally). Therefore, if developers need to change the tax logic for all client applications, they would have to change only one OLE Automation Server.
Another example is an OLE Automation Server that is set up to monitor realtime financial feeds. As market prices change, the OLE Automation Server would update itself with the new information, as well as update any application that is using the Automation Server.
I should mention here that an OLE Automation Server is not the same as Distributed OLE. Rather, it is a server that is accessible locally or over a network. Distributed OLE is an OS-level feature that performs many of the same functions, but will incorporate more features when it appears in future releases of Visual Basic.
When you create an OLE Automation Server, you have the option of turning it into an OLE in-process server or an out-of-process server. The difference is that in-process servers (also known as OLE DLLs) share the same address space as the applications they support; an out-of-process server exists in its own address space. That's why in-process OLE servers can't be distributed without an application, and out-of-process OLE servers can.
Out-of-process servers are executables that have predefined OLE interfaces. These interfaces let developers browse methods and properties of OLE applications using the Visual Basic Properties browser.
Visual Basic's ability to create OLE Automation Servers is the real selling point of this tool, especially for those of you already in Microsoft shops. Components are now reusable from other applications and development environments that support OLE. (See Figure 1, page 46.) Creating OLE Automation Servers is easy. You begin by adding a new class module to the project (for object definition). Then you define the methods and properties to be encapsulated inside of the object. Next, you set the "Class Public" property to True, and define Project StartMode to OLE Server. Although it sounds complex, I created a simple OLE Automation Server in just a few minutes.
After you define your OLE Automation Server as an in-process or out-of-process server, you can test it. After chasing all the bugs in the standard modules, you begin another instance of Visual Basic. After that, you must reference the OLE Automation Server using References from the Tools menu. Then it's time to create a test control application, and test the methods and properties encapsulated inside the OLE Automation Server.
Debugging OLE components is easy with Visual Basic because of the new enhancements in error-handling. The Err object now provides developers with more information, such as source applications, descriptions, and online help.
The real benefit of out-of-process servers is that they can execute on remote machines and are accessible over a network, thus enabling Visual Basic's new application partitioning capabilities. Remote Automation takes OLE Automation requests from the client, sends them across the network using remote procedure calls (RPCs), and receives them on the server. (See Figure 2, page 46.) The distributed Automation Server objects communicate with one another using asynchronous notification, or through OLE callbacks. Also, flexible protocol support is provided via TCP/IP, NetBEUI, IPX/SPX, and Named Pipes. Using this model, any Visual Basic application can pass an object reference to any remote OLE server that is accessible over the network. The idea is that Visual Basic 4.0, with Windows 95, will finally provide the back-end application processing that was missing from earlier Microsoft client/server products.
If you don't need to distribute OLE Automation Servers (that is, if you use a single machine), then an in-process server (or OLE DLL) will do just fine because it's addressable by a local application only. The in-process servers are automatically loaded into the same address space as the application, which results in better performance.
This does not mean that you can't use an in-process server on remote machines. However, a remote application must load the in-process server into its local address space to make it accessible to other applications on the network. In contrast, out-of-process servers don't need a host application. Plus, while out-of-process servers are useful for application partitioning, they are also useful for delivering applications in discrete pieces (on a single machine). By having out-of-process servers, you can deliver pieces of application code that will not interfere with other application servers; also, developers can revise them more quickly and easily.
Using this multi-tier client/server model, developers can place several business processing functions contained inside OLE Automation Servers on any available computer. Thus, updating applications is simply a matter of changing the logic in a shared distributed object. Referring back to the tax application example, you could place tax law logic inside OLE Automation Servers that are accessible over the network from several Visual Basic front-end applications. As the laws change, you can update the logic in the central OLE Automation Servers, and thus propagate the new functionality (assuming that parameter interfaces remain the same).
With OLE Automation Servers, it's important to note that if two users access the same remote function over the network, the requests are placed in a queue--first come, first served. Plus, if someone shuts down a server machine in the middle of an operation, data may become corrupted, depending on what the Automation Server is doing. It's the developer's responsibility to create the logic to handle this problem.
As developers understand the benefits of this architecture, many Visual Basic client/server developers will move much of the logic that currently resides on the database server as stored procedures and triggers to distributed Visual Basic OLE Automation Servers. How you would set this up really depends on the application. For instance, if you have a lot of users going directly to the database (such as with a DSS application), you should place your integrity constraints there. In a transaction-processing environment, you could use the middle tier (for example, OLE servers) to funnel the transactions to the database. Moreover, because this is an open architecture, any tool that uses OLE (such as Microsoft Access, Visual FoxPro, PowerBuilder, Excel, and so on) can use the Visual Basic OLE Automation Servers as well.
Visual Basic 4.0 also provides several tools for managing remote data access, including a remote data controller. This data controller is similar to the JET database engine found in version 3.0. However, the controller provided with Visual Basic 4.0 can populate data-aware controls for ODBC data sources. Using this mechanism, developers may place an interface wrapper around the ODBC API, and thus access the database as a component. This is similar to the database access features found in Smalltalk-based tools, which treat relational databases as objects using wrappers.
The question is, how does Visual Basic manage complex, multi-tiered distributed applications? Visual Basic uses a Component Manager to keep track of OLE servers on the network. In addition to the Component Manager, Visual Basic uses a Pool Manager that lets you build pools of OLE objects and distribute them to clients. This Pool Manager exists to optimize network performance by helping you avoid the bottlenecks that you may run across when managing so many complex objects over a network. In addition, Visual Basic provides an Automation Manager for managing remote procedure calls to OLE servers.
Visual Basic proves that it's ready for your client/server database application by providing several new features. The most significant features include Data Access Objects (DAOs) and the JET Database Engine version 3.0, as well as several handy database tools such as enhanced data control, new bound controls (including a new data-aware grid control), a database forms generator, and an improved database management utility. Visual Basic's Database Manager provides complete control over any database to which Visual Basic can connect. (See Figure 3.)
The heart of Visual Basic's database capabilities is JET. JET's database deftnition features support the creation, modification, and deletion of tables, indexes, and queries. Also, JET provides attribute-level and record-level data validation. To manipulate data, JET supports SQL, but the SQL is not fully ANSI-compliant.
Visual Basic and JET coordinate database activities using DAOs. These objects enable developers to manipulate information in the database by letting them set properties and access methods encapsulated inside of objects. The DAO 2.0 object model is revamped from Visual Basic 3.0's DAO. New features include multiple workspaces, generic Recordsets, security and referential-integrity objects, property collections, and ODBC SQL pass-through features.
Security and referential integrity in the previous release of Visual Basic were available only if you set them up using Microsoft Access. Visual Basic 4.0 now provides all of these feature through DAOs. The Groups and Users collections of the Workspace objects allow maintenance of the security objects. Also, the database object's Relations collection provides one-to-one and one-to-many referential-integrity constraints, including cascading updates and deletes.
JET 3.0's data replication features are outstanding. JET can make entire copies of a database and reconcile data and schema differences on the fly. Developers need only invoke the MakeReplica method to replicate the database. By invoking the Synchronize method, developers can reconcile an original database with the replicated database. Synchronization can occur between any supported database files, or any database servers using ODBC. Also, JET allows the entire database to be password protected. Prior to JET 3.0, developers could restrict access only to those objects inside the database by granting or denying access to specific users.
But JET 3.0 is not just what you can see, it's also what you can't see. There are several performance enhancements, including a new index structure designed to take up less space and enable faster index creation when keys occur several times in a single table. A new algorithm recycles the deleted pages' IDs, which speeds things up significantly when users are deleting a lot of data. JET can also delete data faster. Also, when compacting the database, JET will actually sort data physically on their primary keys. Thus, the primary key becomes a virtual cluster index.
Other performance enhancements include JET's new-found ability to employ the multithreading capabilities of Windows 95 and Windows NT. JET can also perform database transactions internally to speed-up processing, and employ many sort algorithms now found in the well-tested FoxPro engine. Finally, JET's data cache is limited only by the amount of available resources (memory and disk).
If you spring for the Enterprise Edition, Visual Basic provides a Remote Data Object (RDO) and a Remote Data Control (RDC). These features let you bypass JET 3.0 to take advantage of engine-driven cursors on the server, thus speeding up data access and minimizing network traffic. If you need a reporting tool, Visual Basic bundles Crystal Reports (from Crystal Services, a Seagate Software Company, Vancouver, British Columbia, Canada).
VBA (Visual Basic for Applications), the language that drives Visual Basic, is much improved with 4.0. For those of you already programming in VBA, the changes are substantial, and it's not a quick read to get up to speed.
Visual Basic 4.0 is backward-compatible, and you can use the Visual Basic 3.0 style to build applications. However, those of you looking to use Visual Basic 4.0 to its maximum advantage must unlearn the workarounds that were required in 3.0 in order to take full advantage of the new VBA features of 4.0.
For example, Visual Basic 3.0 offered no simple method of passing data from one form to another. Many developers, using workarounds, resorted to using invisible labels to hold shared data, tag properties, or global variables. When using Visual Basic 4.0, forms are objects that developers may extend with custom properties and new methods. Visual Basic developers can add public variables easily, which are referable from any other form in the application. In addition to sharing data from form to form, developers may add custom methods to forms, and these methods can receive parameters passed from other forms.
For those of you starting from scratch, you'll be happy to know that many of the drawbacks in earlier versions of VBA are history with Visual Basic 4.0. The language is fully functional for all application development requirements, and I could not find significant limitations. However, I would not call it a 4GL. With its roots planted firmly in the Basic language, it appears somewhat cryptic. And it will take you some time to get up to speed with VBA. In many respects, it is similar to its main competitor, Borland's Delphi. Delphi is also based on the Object Pascal 3GL.
For those of you who want to build simple client/server applications quickly, you can't do much better than Visual Basic 4.0. Building a Visual Basic application is as easy as it was with the previous version. The Visual Basic 4.0 IDE is well designed and lets developers build most of the application visually using a development method that I call "drag, drop, and define." (See Figure 4.)
The first step in building a Visual Basic application is to design the forms for the application. If you're building a database application, it's better to define the database and the database connection first. However, it's certainly acceptable to build the forms before worrying about the database.
The Toolbox found on the IDE contains the Visual Basic controls. If the Toolbox is closed, you can open it by choosing Toolbox from the View menu. To place a control on a form, you can either double-click the control, or drag and drop the control onto the form. Visual Basic uses several independent applications running concurrently to make up the development environment. This approach is very different from other tools that provide a single monolithic development environment with MDI child windows.
The power of Visual Basic is that when the Toolbox is open, you can place new controls in it to extend the capabilities of your development environment. The Professional Edition of Visual Basic provides numerous custom controls. You can also purchase custom controls from third parties. There are hundreds of companies that build custom controls for Visual Basic 4.0 (in both VBX and OCX incarnations). For example, some custom controls provide VCR buttons for applications that use video, controls that provide prebuilt calendars, controls that provide an interface to information servers, and so on. Currently, VBX controls dominate the market, but the majority of third-party control vendors are shifting to OCXs.
The second step in building your Visual Basic application is to set the properties for the objects you have created. Some properties can be set up at design time. To set these properties, you can use the Properties window or property pages. (See Figure 5, page 50.) You may also set properties for multiple controls at one time. To do this, simply click and drag the mouse to select multiple controls on the form. The Properties window displays only the properties common to all the controls, and any change you make to a property applies to all controls.
Depending on your application, you may have to place code behind the controls. For simple applications, you may get away without coding. However, most client/server applications require a significant amount of custom programming for database manipulation and interface processing.
To add a menu to your form, click the Menu Editor button on the toolbar. The Menu Editor is an interactive tool, and you can add new commands to existing menus, replace existing menu commands with your own, create new menus and menu bars, and change and delete existing menus and menu bars.
Having done all that, it's time to test your application and create an executable. The executable, of course, is a misnomer. Visual Basic applications still use a p-code interpreter. This is a major drawback when considering similar competing development environments such as Delphi, which can create standalone native .exes. Performance was okay on a 100 MHz Pentium with 16MB of RAM, but seemed very slow on a 33 MHz 486 with 8MB of RAM (both running Windows 95). So, if you want to deploy Visual Basic on low-powered clients, beware.
Visual Basic 4.0 is a major upgrade, and it incorporates several new features that make client/server development quick and easy. Moreover, it's now 32-bit and provides much more flexibility for application development. If you're already a Visual Basic developer you should strongly consider an upgrade.
However, there are some things to be concerned about with this release, such as performance and VB's new partitioning features. When comparing the performance of Visual Basic 3.0 with 4.0, the interface performance is slightly worse with the new version, for both the development environment and the runtime. This may be due to the facts that Microsoft expects everyone to use Pentiums and that the tool supports several new power-hungry features. But those of you deploying in the real world will know that everyone has not upgraded to faster processors. However, many of the JET enhancements make up for the slow interface processing.
Visual Basic's partitioning capabilities enable developers to distribute processing on many computers, but, for now, Visual Basic supports only Windows-based servers that can run the OLE Automation Servers. High-end Unix server support would be a nice addition. I would also like to see a transaction-processing object provided with Visual Basic 4.0.
I believe that Visual Basic 4.0 will continue to dominate much of the client/server development market OLE seems to be the direction of the desktop, and Visual Basic 4.0 makes using OLE a cinch. What it comes down to is, where does a 300-pound gorilla sit? Anywhere it wants to.
* Microsoft Corp., One Microsoft Way, Redmond, WA 98052-6399; 206-882-8080 or fax 206-936-7329.