Vertical Migration
Vertical Migration The most important thing you need in order to have a successful vertical migration is an application where it is easy to isolate the implementation of a functional slice of your application. Figure 12-4 shows a typical vertical migration. Figure 12-4. A detailed look at a vertical migration. Notice that, in this case, I have rewritten the client using ASP.NET or .NET Windows Forms. I have also reimplemented the business objects associated with that particular functionality as a managed object using an XML Web service or .NET remoting. You can immediately see the potential problems with this approach by looking at Figure 12-5. Figure 12-5. A detailed look at a vertical migration. If the middle- tier objects are accessed by any other portions of the application, such as a UI or an unmanaged business object for another module, you need to change those applications and/or use Interop to talk to the new managed object from the unmanaged portions of the application. This adversely affects performance, depending on how many calls you need to make to the managed object. In this example, the business object that I just migrated is accessed by other parts of the application besides the portion that I am migrating. These other parts of the application will have to access the managed object using Interop. As I show with the dotted lines on Figure 12-5, if the business object is migrated to an XML Web service using ASP.NET asmx files or .NET remoting, you have the option of using either the SOAP moniker (if the client is using Windows XP or .NET Server) or the SOAP Toolkit to access the object from an unmanaged client. You can also access the object directly using CCW. A good reason to use a vertical migration is if your existing unmanaged application uses ADO Recordsets to communicate between the presentation and business tiers. If you do a horizontal migration and use ADO.NET datasets on the managed tier, you will have to convert back and forth between the Recordsets used by the unmanaged tier and the datasets used by the managed tier. However, with a vertical migration, you will migrate the presentation and business tiers at the same time, so you can write both to use datasets. The only time that you will have to convert datasets to Recordsets (or vice versa) is if the vertically migrated portion of your application needs to use unmanaged portions of the application. Another problem with a vertical migration is the inability to share data in the session and application objects between ASP and ASP.NET code. ASP.NET made substantial improvements to the implementation of the session and application objects. You now, for instance, have the option of storing your session data in SQL Server, but a downside of these changes is that ASP and ASP.NET code cannot share information through the session object. Information that your ASP pages save to the session and application objects will not be available to your ASP.NET pages and vice versa. If your application makes heavy use of the ASP session and application objects and you still want to perform a vertical migration, you will need to remove your application's dependence on the session and application objects. You can do this by using hidden form fields, by encoding the session within your URL strings (URL munging ), or by writing your own logic to store and retrieve session from a database. You can also use cookies, but, because many people disable them on their Web browser, this is typically not a good idea. It is absolutely critical when using vertical migration that you find a portion of the application that is well isolated. You might want to perform code path analysis to see which portions of your code are the most isolated from other parts. An ideal candidate for vertical migration would be a module like that shown in Figure 12-6. Figure 12-6. An ideal candidate for a vertical migration. Because no unmanaged code needs to talk with the new managed object, no Interop boundaries need to be crossed. Unfortunately, many software systems do not have an ideal subsystem like this that immediately lends itself to a vertical migration. In most cases, identifying a candidate module for vertical migration will take some searching, and you will likely have some cross-talk between the newly migrated managed code and your unmanaged code. The best way to find a good vertical migration candidate is using code path analysis. One of the easiest ways to perform code path analysis is to use a debugger. By stepping though the code for your most popular use cases, you will get a good idea of which portions of the code are isolated enough to make them good candidates for a vertical migration. One perfect candidate for a vertical migration is a new piece of functionality. A perfectly valid migration strategy is to leave your existing code as is and use the .NET Framework for all of the tiers of any new functionality you develop, using Interop as necessary to leverage your existing functionality. With this approach, you can actually design for isolation up front and can even duplicate functionality, if necessary, in order to maintain isolation. When to UseYou should use a vertical migration in the following scenarios:
|
 | |
Team-Fly  |
| Top |
EAN: 2147483647
Pages: 119