Migration versus Interop

Team-Fly    

 
.NET and COM Interoperability Handbook, The
By Alan Gordon
Table of Contents
Chapter Twelve.  Migration and Interop Strategies

Migration versus Interop

For the purposes of this chapter, migration is the process of taking unmanaged code that was written using the various technologies in Windows DNA, such as COM, MTS, COM+, ADO, ASP, or Win32, and converting that code to use managed code and the technologies in the .NET Framework, such as XML Web services, .NET remoting, serviced components, ADO.NET, and ASP.NET. Interop means using the various Interop technologies provided by the .NET Framework (primarily COM Interop and P/Invoke) to call existing COM or COM+ components and unmanaged APIs. Using migration and Interop are not mutually exclusive; in fact, they complement each other. Most software development organizations cannot afford to migrate their entire application to the .NET Framework in a single release. Because of this, many organizations will instead perform an incremental migration of their software system, migrating more and more portions of their application from unmanaged code to managed code with each release. Those portions that have been migrated to .NET in a given release will need to talk to the unmanaged portions of the application that have not been migrated using Interop. Similarly, if you do migrate certain parts of your application to .NET, there is the possibility that unmanaged portions of the application will need to interact with portions of the code that have been migrated , which means that they will also need to use Interop to call the unmanaged code from .NET.

Although an incremental migration is the only practical approach for most organizations, the problem with this gradual migration approach is that you could be left with an application that performs poorly until the application is fully migrated. A call from managed to unmanaged code or vice versa uses approximately 50 instructions, independent of marshaling. If your object contains a large number of parameters, particularly nonblittable types, marshaling Interop calls between managed and unmanaged code will burn a significant amount of time. In addition, if your current application uses ADO Recordsets to communicate between tiers, which many applications built with the Windows DNA do, migrating portions of your application to managed code may require you to perform expensive translations between ADO Recordsets and ADO .NET datasets. You have to do this, in particular, if you decide to use ASP.NET data binding. Another significant problem is that ASP and ASP.NET pages cannot share data through the session or application. Therefore, if your existing ASP application makes extensive use of the session object, you will not be able to access that session information from your ASP.NET code. These and other problems make performing an incremental migration a process fraught with peril. The rest of this chapter is devoted to providing ideas for navigating around this peril. I won't be providing new nuts and bolts information in this chapter, but rather will be showing you how best to use the Interop concepts that you learned in this book as part of an overall incremental migration strategy.

An Introduction to Migration Strategies

Microsoft recommends that you use a three-tiered logical design when you build your applications using its platforms as shown in Figure 12-1.

Figure 12-1. The canonical three-tiered architecture.

graphics/12fig01.gif

Note

A three-tiered logical design means that the three tiers have well-defined interfaces between them. It does not mean that the three tiers must run in separate processes or on separate hosts .


This is as true with .NET as it was with the Windows DNA. The three tiers are the data tier, which is typically a database; the business tier , which is usually composed of a set of COM, MTS, or COM+ business objects that implement the business logic of the application; and the presentation tier, which typically consists of ASP clients and, in many cases, rich clients that are implemented using Visual Basic or MFC.

When examining the tiers of a well-written business application, you have two choices as to how to migrate your code. You can either use a vertical migration or a horizontal migration.

In a vertical migration, you migrate an entire functional slice of your application as shown in Figure 12-2. In other words, you reimplement the portion of your client associated with a particular functionality by converting your ASP client to ASP.NET. If your application has a rich client implemented with Visual Basic or MFC, you may instead migrate it to Windows Forms using C# or Visual Basic .NET. You will also reimplement the business objects for this functionality. If your objects are implemented as regular COM objects that are accessed from your ASP pages, you will rewrite them as managed objects hosted in a DLL assembly. If your business objects were hosted in MTS or COM+, you may instead choose to reimplement them as serviced components, a Web service, or a .NET remoting server. In most cases, the data tier will be unaffected regardless of whether you choose to use a vertical or horizontal migration.

Figure 12-2. Vertical migration.

graphics/12fig02.gif

In a horizontal migration, you migrate an entire tier of your application as shown in Figure 12-3. With this approach, you may choose to rewrite the entire presentation tier of your application using ASP.NET or Windows Forms and leave your middle tier unmodified, or you may instead choose to rewrite your middle tier using XML Web services, .NET remoting, serviced components, or just plain vanilla .NET assemblies. However, you will continue to use an unmanaged client.

Figure 12-3. Horizontal migration.

graphics/12fig03.gif

The choice of which migration strategy to use is a difficult one that depends on the characteristics of the application that you are migrating. A general rule of thumb is that you should minimize the number of Interop boundaries that your application must cross when executing its most common-use cases (code paths). However, following this rule of thumb alone is not sufficient to make a good decision. Some applications are not amenable to a vertical migration because, in order to perform a vertical migration, you must be able to isolate a functional slice of your application. With some applications, this is not easy. Similarly, if your unmanaged application makes heavy use of ADO Recordsets to pass data back and forth between the presentation and middle tiers, doing a horizontal migration may cause unacceptable performance degradation because you will need to do lots of translation between ADO.NET datasets and ADO Recordsets and vice versa.

Let's look more in depth at each of these approaches and explore how each type of migration is done and the things you need to consider before deciding to perform a horizontal or vertical migration.


Team-Fly    
Top
 


. Net and COM Interoperability Handbook
The .NET and COM Interoperability Handbook (Integrated .Net)
ISBN: 013046130X
EAN: 2147483647
Year: 2002
Pages: 119
Authors: Alan Gordon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net