Horizontal Migration

Team-Fly    

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

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 Tier

A 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:

  • If your business objects are hosted in a COM+ application and you are able to use Windows XP or Windows .NET Server as your server host, you can use COM+ Web services (as explained in Chapter 11) to expose your business objects as an XML Web service. You can then create a proxy using the Add Web Reference command in Visual Studio .NET or the Web Services Description Language Tool (wsdl.exe) in the .NET Framework SDK.

  • You can build a custom managed wrapper for the COM component implemented within a .NET remoting server as shown in Figure 12-8. With this approach, you can both move the remoting boundary so that you use .NET remoting (with all of its flexibility and ease-of-configuration advantages) as your networking infrastructure and create a more natural interface for your managed client. You can convert a chatty interface (one with lots of property sets and gets, for instance) to a more chunky one (one that requires fewer method calls to get anything done). A chunky interface will have less network traffic than a chatty interface. You can also use implementation inheritance where appropriate. Creating a custom managed wrapper for your business tier is not the same as migrating the business tier because you do not need to reimplement any of the business rules in the business tier. Your wrapper will delegate all of its business- related work to the existing unmanaged business objects.

    Figure 12-8. Using .NET remoting through a custom managed wrapper.

    graphics/12fig08.gif

Figure 12-7. A horizontal migration of the presentation tier.

graphics/12fig07.gif

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:

  • Perform a brute force translation, that is, create a new ADO Recordset, add columns to the Recordset, and then iterate over the records in the dataset by adding new rows to the Recordset and populating it with the values from the dataset.

  • Leave the dataset as XML and then use XSLT to convert the XML to the ADO Recordset schema and then load the XML into the Recordset.

  • Write custom marshaling code that translates ADO.NET datasets to Recordsets. This topic is outside the scope of this book, see the documentation for the ICustomMarshaler interface in the .NET Framework SDK.

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 Use

You should use a horizontal migration of the presentation tier in the following scenarios:

  • If you want to make maximum use of the functionality, ease of development, and deployment advantages of ASP.NET.

  • If your application does not make heavy use of ADO Recordsets to transmit data between the application and business tiers.

  • If your existing application makes heavy use of the ASP session or application objects.

  • If your existing application does not use STA COM objects, it is much more efficient to use this approach (although there are workarounds). In most cases, your managed client enters an MTA prior to calling your COM objects, so a thread switch will be required.

Migrating the Business Tier

A 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.

graphics/12fig09.gif

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 Use

You should use a horizontal migration of the business tier in the following scenarios:

  • If you want to immediately leverage the cross-platform potential and firewall friendliness of XML Web services.

  • If your application has a complex object hierarchy. The .NET Framework supports implementation inheritance, which makes it easier to handle complex object hierarchies in your business tier. Moreover, a vertical migration will be inefficient if your object hierarchy is complex because there will be a significant amount of Interop calls.

  • If you want to get started with a .NET migration, but a vertical migration of your application is difficult because your application makes extensive use of the ASP session or application objects and/or makes extensive use of ADO Recordsets to communicate between the presentation and business tiers. Many Windows DNA applications fit this profile.

  • If your application requires a rich client, that is, you must use Windows Forms, and if you must support Windows 95 as a client, a horizontal migration of the business tier may be your only option because the .NET Framework will not run on Windows 95.


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