Horizontal Migration If you decide to do a horizontal migration, the first choice you need to make is whether to migrate the presentation tier or the business tier first. Depending on which tier you choose to migrate, you will have a very different set of tasks to do, and pros and cons are associated with the decision. Let's look first at migrating the presentation tier . Migrating the Presentation TierA horizontal migration of the presentation tier means to take all of your existing ASP code and convert it to use ASP.NET and/or to take all of your Visual Basic or MFC-rich clients and convert them to use Windows Forms as shown in Figure 12-7. In this migration scenario, the business tier remains as COM, MTS, or COM+ business objects. The client may communicate with the server using an RCW that will then communicate with the object through COM if the presentation layer and business layer reside on the same machine or through DCOM if they do not. If you do not want to use DCOM as your remoting technology, you have two choices:
Figure 12-7. A horizontal migration of the presentation tier.
One of the major reasons why people may choose a horizontal migration of the presentation tier is so that they can use ASP.NET, which has substantial improvements over ASP in terms of functionality, administration, ease of development, and code maintainability. One of the biggest benefits of using ASP.NET is that you can use data binding. Unfortunately, in order to use data binding, you need to convert tabular data that is returned from the middle tier to ADO.NET datasets. In most cases, this data will be returned from your unmanaged middle tier as ADO Recordsets. Therefore, you need to write code to convert ADO Recordsets to ADO.NET datasets and vice versa. As you saw in Chapter 10, the OLEDB managed provider contains a Fill method that converts an ADO Recordset to a dataset, but there is no mechanism for converting a dataset back to a Recordset. You have a number of choices as to how to tackle this problem:
If you are using ASP.NET, your UI (the HTML pages generated from the ASP.NET pages) is actually generated on the server, and you may be able to access your business objects using COM Interop. If you use this approach, you need to be aware of an issue related to threading models. Managed code, like an ASP.NET page, does not enter a COM Apartment until you call COM code. By default, it enters an MTA. If you are using an STA object, you incur a thread switch through an interapartment proxy. Note All business objects built with Visual Basic 6 are STA objects. You can force your ASP.NET page to enter an STA by using the aspcompat attribute in your page as shown in the following: <%@ Page language="c#" aspcompat="true" Codebehind="WebForm1.aspx.cs" AutoEventWireup="false" Inherits="ArithmeticClient.WebForm1" %> If the middle tier is implemented as a COM+ server (out-of-process) application and your server platform is Windows XP or .NET Server, you may instead choose to use COM+ Web services to expose your middle tier using SOAP. Unfortunately, as I showed you in Chapter 11, this functionality will not work if your COM+ application returns ADO Recordsets. One solution to this problem is to create an XML Web service or .NET remoting server manually and convert the ADO Recordset returned by the unmanaged business object to an ADO.NET dataset yourself. Unfortunately, this, too, is problematic because of threading issues. If you implement your XML Web service using an ASP.NET asmx file, you will always incur a thread switch when you call an STA object because asmx files do not support an aspcompat attribute like Web Forms and will always enter an MTA. When to UseYou should use a horizontal migration of the presentation tier in the following scenarios:
Migrating the Business TierA horizontal migration of the business tier means to take all of your existing COM, MTS, or COM+ objects and rewrite them as managed types. You may choose to use plain vanilla assemblies or serviced components or to expose your types as an XML Web service or as a .NET remoting server as shown in Figure 12-9. Figure 12-9. A horizontal migration of the presentation tier.
You have a variety of ways that you can access your managed code business objects from your unmanaged client. If your managed code objects are implemented in an XML Web service or a .NET remoting server, you can use COM Interop to call a managed proxy that you generated using wsdl.exe, soapsuds, or the Add Web Reference command in Visual Studio .NET. The proxy will reside on your client, and you will use SOAP (or possibly TCP/binary remoting) as your communication protocol. Another way to use SOAP from an unmanaged client is through the SOAP moniker or the SOAP Toolkit. If your migrated business objects are implemented as plain vanilla assemblies or serviced components, you can generate an Interop assembly using tlbimp or the Add Reference command in Visual Studio .NET. In this case, you will be using DCOM as your communication protocol. A horizontal migration of the business tier is a good approach to use if you have a complex object hierarchy with many method calls occurring between the various objects within the business tier. If you do have a complex object hierarchy and you do not migrate the entire business tier at one time, you may have to make many calls across the managed to unmanaged code boundary. If your current business tier makes extensive use of ADO Recordsets, a horizontal migration of the business tier suffers from the same problem with ADO.NET dataset to ADO Recordset conversion as when migrating the presentation tier, although the problem is slightly mitigated. The UI is likely to access most of the data in the Recordset in order to display the interface, which generates a lot of Interop calls. That's why, in general, it's not practical to continue to use ADO Recordsets on a managed client. In many cases, though, a managed business object may execute a query and then immediately return the results to the client without iterating through the data. In a case like this, no significant performance penalty is associated with just returning the ADO Recordset to the unmanaged client. When going the other way, such as when the unmanaged client passes an ADO Recordset to the managed business object, the business object can simply use ADO through Interop to persist the Recordset to the database. If it needs to operate on the data, it can use the Fill method on the OledbDataAdapter class to convert the Recordset to a dataset. When to UseYou should use a horizontal migration of the business tier in the following scenarios:
|
Team-Fly |
Top |