Features

(SYS-CON Media) - The capabilities and advantages of using the Microsoft .NET Framework are undeniable. It provides the ability to rapidly build, deploy, manage, and use connected, security-enhanced solutions with Web Services, enabling businesses to integrate their systems more rapidly and agilely and helping them realize the promise of information anytime, anywhere, on any device.

Microsoft has devoted a great deal of time and attention to making the various aspects of .NET technology interoperate across the Microsoft platform, and it shows in important areas such as enhanced performance, memory management, ease of deployment, and security. However, these benefits can be seriously compromised when developers are working in heterogeneous environments and have to build .NET applications that must integrate with non-Microsoft technologies.

This is readily evident in database connectivity - a critical yet often overlooked aspect of Web Services integration. The business-critical data of many an enterprise resides on Oracle, DB2, and Sybase ASE relational databases, yet the ADO .NET providers that come with those databases - Oracle ODP.NET Provider, IBM DB2 .NET Data Provider, and Sybase ASE ADO.NET Data Provider - are simply incapable of availing themselves of the many benefits that .NET can provide. Using these providers can have a considerably adverse impact on the performance of your system - a highly undesirable outcome, since the slowest operations for a data-centric application (not to mention the most costly in terms of processing overhead) involve network requests and disk I/O. Using the database vendor supplied data providers also costs in terms of the manageability and security of your systems, with real potential consequences for your organization's bottom line.

Microsoft's implementation of the Common Language Infrastructure (CLI) standard for the virtual machine component of the .NET Framework, the Common Language Runtime (CLR), provides the execution environment for all .NET Framework code. Code that runs in the CLR is known as managed code. The CLR provides numerous benefits for application developers using managed code, such as:

• Side-by-side versioning of reusable components
• Evidence-based security with code identity
• Assembly-based deployment that eliminates "DLL hell"
• Code reuse through implementation inheritance
• Automatic object lifetime management
• Hardware-specific optimizations that accelerate run-time performance

Microsoft's SQL Server database has been designed to leverage the capabilities of the CLR. But what about .NET-based projects that require connectivity to databases other than SQL Server - are the full benefits of the .NET environment closed off to them? Not necessarily. It depends on the .NET data providers employed.

Factors that Commonly Prevent Other Databases from Fully Leveraging .NET
The problem with the ADO.NET providers included with Oracle, DB2, and Sybase ASE - as well as many commercially available providers designed to work with them - is that they aren't built using 100% managed code. Their unmanaged code includes database client pieces that use client libraries to access the database, or calls made to native Win32 database client pieces and other unmanaged code.

The most obvious consequence of this is that the performance advantages of the managed code environment are lost when unmanaged code is called. The CLR makes additional checks on calls to the unmanaged or native code, putting a drag on performance. Other less obvious consequences can also have real impact on the operation of your .NET environment and must also be considered.

Only when your .NET application uses components built using 100% managed code do you get the full benefits of the .NET Framework. With ADO.NET data providers, this can't be achieved unless the provider is architected to dispense with the unmanaged client element altogether.

A provider that uses the same (officially supported) protocol used by the native database clients can be designed to communicate directly with the database at the network level. This enables all the database-related application code to run entirely in the CLR - that is, it's 100% managed - eliminating the need for the driver to interact with another layer (the native database client), which can't be optimized for an ADO.NET environment.
Managed applications written to take advantage of the features of the CLR perform more efficiently and safely, and make optimal use of developers' existing expertise in languages that support the .NET Framework. ADO.NET data providers designed with 100% managed code are no exception. They can fully leverage the advantages of the .NET Framework with considerable benefits to runtime operation, application development, and deployment.

Runtime
As mentioned, ADO.NET providers running entirely in the CLR eliminate costly calls that bridge outside the CLR - in this case, application code from the provider to the native database client - with adverse impact on performance. But that isn't all. Numerous runtime services built into the CLR work to enhance the scalability, reliability, and security of managed providers. Where these are available at all to providers that rely on unmanaged code, such services require separate utilities to provide them - in other words, additional unmanaged code that further degrades performance and/or scalability.

A good example is NGEN.exe: a .NET utility that post-compiles applications. Post-compiling improves start-up performance for managed code while preserving all the security and stability advantages of managed assemblies. It also ensures that the data provider is optimized for the hardware architecture of the particular machine on which it's being installed. NGEN allows for superior use of shared memory and computing resources that are critical to optimal performance. Using data providers built with 100% managed code can leverage similar runtime features and services in the following areas:

• Scalability - The .NET Framework comes with built-in support for creating threads and using the system-provided thread pool, an important scalability feature of using managed code (see the sidebar). The CLR can also contribute to scalability by allowing managed data providers to take full advantage of processor features. Its just-in-time (JIT) compiler translates the Common Intermediate Language (CIL) directly into optimized x86 native instructions (which is what lets managed code run in different environments safely and efficiently). When the JIT encounters an Intel processor, for example, the code generated takes advantage of hyper-threading technology.
• Reliability - The .NET runtime automatically performs numerous checks on managed code to ensure that it's written correctly and that applications always access allocated objects appropriately. One of the most significant features of managed code is automatic memory management; the CLR garbage collection automatically frees allocated objects having no outstanding references to them, freeing developers from spending large amounts of time debugging memory leaks. Memory leaks are virtually eliminated in 100% managed code.
• Security - The many automatic checks conducted by the .NET runtime also figure into the security advantages derived from data providers that use managed code. A common Denial of Service attack involves making API methods operate out of specification, causing buffer overruns - theoretically impossible with managed code.

But that's merely one reason why data providers that use managed code are much safer. Managed code has no direct access to memory, machine registers, or pointers. The .NET Framework security enforces security restrictions - called Code Access Security (CAS) - on managed code. CAS protects code and data from being misused or damaged by other code. Finer-gained Code Access Security has become increasingly important for .NET applications. Administrators can define a security model to grant or revoke permissions at every level: enterprise, machine, assembly, or user.

Calling unmanaged code, which takes place when a data provider calls a client library, bypasses the .NET CLR security. This doesn't necessarily mean that a security problem exists, of course; only that it opens a door to potential problems due to the functionality of the unmanaged code that has direct access to memory or machine registers, or uses pointers. Once that code is executing, the CLR can no longer check it.

Development and Deployment
Eliminating the need to deploy native database clients, along with subsequent patches or upgrades, obviously reduces the use of staff resources and potential problem areas. But using ADO.NET providers designed with 100% managed code results in other important advantages that should also be examined. A key advantage of the .NET Framework is its ability to eliminate the shared file conflicts that happen when different versions of Dynamic Link Libraries are run on the same machine - the situation commonly referred to as "DLL hell."

When Oracle's ODP.NET data provider is used, it calls the unmanaged Oracle client pieces specific to a particular version of the Oracle database. Running two versions of the unmanaged data provider - for example, Oracle 9i and Oracle 10g - on the same machine results in conflict because each data provider will require a particular version of the clients, which in turn are native Win32 DLLs. Organizations typically address the issue of conflicts by deploying multiple mid-tier servers, each running different database client software; this makes for a more costly, convoluted, and difficult-to-manage environment having multiple combinations of provider and native clients.

This brings up versioning issues beyond the scope of a single application project, intended to address a single business solution. However, anyone tackling business problems in an actual multi-application environment must realistically consider such issues. Applications are tested and/or certified against specific versions of the database and corresponding middleware. So how, for instance, do you address different or unrelated applications being developed and/or updated on different schedules when it comes to data connectivity? Do you force all applications to use the same version of the database? If this isn't the case, do you segregate the applications on different machines since each server can only run one version of the native database client?

Faced with these questions, it isn't hard to see the impediments to deployment flexibility when unrelated applications (and development teams) must coordinate their upgrade efforts. In nearly every project involving data connectivity, a myopic focus on solving the immediate challenge at hand is a non-strategy that can cause trouble and expense down the road. Other commonly employed non-strategies include never upgrading the database client software (which forces you to use older software with more limited features and will eventually cause support issues), or simply upgrading the client in hopes it won't break something from an existing application unrelated to the project underway.

Using ADO.NET data providers designed with 100% managed code eliminates or solves all these issues, as follows:

• You no longer have to deploy and maintain native database client software. Application deployment is easier since the data provider can be deployed along with the application components using your deployment method of choice (including the ClickOnce deployment provided by the .NET Framework, described in the sidebar). Additionally, having to deploy patches and new versions of the native database client is eliminated, along with the associated effort and expense.
• You can maintain side-by-side versions of data providers on a single machine and no longer need to re-certify and test all applications when upgrading data access middleware because those applications can each use different versions of the data providers.
• You can use a single version of the data provider regardless of the database version or operating system platform, letting you consolidate applications on a single server or server farm. Versioning issues are essentially eliminated.

Conclusion
In planning .NET-based projects for organizations, data connectivity should be carefully considered. This is particularly true now that - with the strides made in processing power and database design - performance and scalability bottlenecks have moved to the connectivity layer in well-designed applications. As this article makes clear, falling back on the data providers that come with the Oracle, DB2, and Sybase ASE databases prevent your solutions from fully leveraging the many advantages built into the .NET Framework's Common Language Runtime. These advantages can give a needed boost to the performance and scalability of data connectivity in .NET-based solutions. By using data providers built with 100% managed code that runs entirely in the .NET CLR, organizations incorporating Oracle, DB2, and/or Sybase ASE data resources into their solutions can fully leverage these performance and scalability advantages, along with a wealth of additional advantages that make their applications perform more efficiently and safely. (See Sidebar)