By Tim Landgrave

In well-architected three-tier systems based on ASP front ends, the architect has successfully decomposed the business and data layers into appropriate COM components. These systems can be migrated efficiently because new ASP.NET front ends can call these components with minimal modification. But if you didn’t do the proper architecture work in your ASP applications, ASP.NET won’t help you much in a migration.

If you do the right thing architecturally for ASP, there are two ways that you can reuse the COM components but also position yourself for a .NET future. Let’s look at these two strategies.

Strategy 1: .NET adapters
Although your ASP.NET application can use the COM Interoperability layer to communicate with the COM layer directly, you will build inefficiency into your systems if your existing COM layer uses VB6 business components that extensively use Variants.

The best way to create an efficient and reusable business layer is to develop a set of strongly typed .NET components that wrap the underlying VB6 components. Your ASP.NET applications then call these adapters, which, in turn, call the VB6 components and perform data conversion to strong types. Using this methodology, your ASP.NET code can be fully typed, and other groups who want to reuse these components with their ASP.NET applications don’t have to be concerned with the issues surrounding the COM Interoperability layer.

Moreover, you can then move forward with a project to develop a set of .NET business components that keep the same strongly typed interface without affecting other applications. Once this is completed, you’ll have completely replaced your COM business layer with one based on .NET without waiting for a complete rewrite before reusing it.

Strategy 2: Web services
You may find that the business processes wrapped by the existing COM-based business layer have applicability well beyond a rewrite of the current system. If you’re embarking on a strategy that depends on Web services technology as either your internal or external integration conduit, it may make sense to use Web services rather than .NET components to wrap your COM components. Doing so provides the additional advantage of naturally separating your application into physical tiers (i.e., dedicated application servers running your Web services) as well as separating them logically.

You should use Web services if you want non-Microsoft systems to be able to access the new business components. But if you’re a pure Microsoft shop, you should consider using .NET Remoting to separate the physical tiers. For these purposes, you can think of Remoting as .NET DCOM.

Remoting is significantly faster than Web services because you have more control over the marshalling format (e.g., SOAP or binary) and you can optimize some of the communications settings. In testing for our customers, we found TCP binary Remoting to provide a 200 to 300 percent performance increase over standard Web services using SOAP formatting. The only significant drawback we had to overcome was that calling a component through Remoting doesn’t maintain transactional integrity and the security context. As with the adapter strategy, once you have your Web Services or Remoting layer in place, you can replace the COM components with native .NET components to increase your performance and remove the dependency on COM.

Don’t forget the data layer
You can continue using ADO, including recordsets, with .NET, but you’ll want to move as rapidly as possible toward ADO.NET as your preferred data access API. In addition to being faster and requiring less memory on the server, ADO.NET also has a more robust and better-defined disconnected data strategy.

The combination of these factors allows you to create more scalable systems that consume fewer databases and server resources, thereby giving you a more robust .NET-based system than the one you can create with COM applications and ADO. By using one of these migration strategies initially and then using ADO.NET as part of your COM-to-.NET conversion, you’ll be able to build a business layer quickly that will serve as the foundation for a conversion to .NET when it makes business and technical sense.