One of the most difficult decisions facing any organization that’s considering a move to .NET is how to handle existing applications. Such legacy applications generally fall into three categories: non-Microsoft, desktop, and Windows DNA.
Of course, we all recognize that the last category spans a wide array of subtypes that include everything from simple Web applications to client-server applications to real three-tier implementations. When evaluating applications that your shop developed using the Windows DNA toolset to operate across two or more tiers, it’s helpful to make a couple of basic assumptions about how you will move these applications to .NET. You can then evaluate the applications themselves to see which ones are the best candidates for migration.
Perhaps the single most important assumption for migrating an existing Windows DNA application to .NET is that you’ll take advantage of XML Web Services, which were designed to handle issues like latency, asynchronicity, security, and interoperability with other platforms. These are the issues that gave designers of Windows DNA systems the most difficulty as they developed Internet-scale applications.
The second core assumption that we’ll make about .NET applications involves state management. Scalable applications must be designed in a way that minimizes the need to maintain state information between any two physical tiers of the application. In other words, it’s desirable to use a presentation facade that resides on the same physical machine as the presentation layer to maintain state for the presentation layer. It’s undesirable, however, to maintain state information for the presentation layer in the business or database layer, since there’s a high likelihood that the objects representing those layers will be on different machines than the presentation layer.
The good news here is that if you can migrate the objects in existing Windows DNA applications to use the inherently stateless XML Web Services paradigm, you’ll probably be able to update other application components to function properly in a stateless environment. The first step in determining whether a Windows DNA application is a good candidate for a migration to .NET is simply deciding whether the application needs the benefits of XML Web Services and stateless architecture. If not, the application probably can continue running in its current environment until it’s either no longer necessary or needs to be replaced for a business reason. The major architectural area to consider here is the Windows DNA application’s existing object model.
Evaluating the object model
When evaluating the object model, you want to look at the return data types, the size of the data, how the model handles errors, and the current state model. If existing objects are designed to return simple data types or disconnected recordsets, a .NET migration will be easier. Simple data types will map directly to their XML equivalents, and you can use .NET datasets to represent disconnected recordsets. But if the existing object model returns complex COM data types, connected recordsets, or other complex structures, the migration will not be trivial. In the latter case, you should investigate the option of maintaining the COM objects in their current state and wrapping them with XML Web Services that include functionality to translate from COM data types to XML data types that other layers can consume.
Since the values returned between layers in an XML Web Services infrastructure are represented as text strings, the amount of data returned becomes critical. Returning 1,000 4-byte integers from a Windows DNA object will never take more than 4,000 bytes, but the text representations of those same numbers may need 16,000 bytes. It doesn’t take too many 400 percent increases in data storage to make an application slow down quickly. Fine-grained objects that return small numbers of rows with only the columns necessary for specific calling functions are better candidates for .NET migration than coarse-grained objects intended to be reused by multiple generic functions.
Another important aspect of the existing object model is the way in which it reports error information. The XML Web Service will need a way to trap the error and pass back an XML package that the consumer can use efficiently. Your existing objects probably return either a Boolean indication of success or failure and a reference pointer to the error data, or simply return null data in case of a failure. Neither is wrong per se, but the ideal application for migration implements the same error mechanisms consistently.
As with the complex data type issue, the best way to deal with stateful object models is to provide XML interfaces for the existing code. You implement the XML interface in a Web Services wrapper. The wrapper manages the state between for the existing code and can even make multiple method calls, if necessary, before returning a stateless data object in XML to the Web service consumer.
Once you’ve worked out the migration details for the Windows DNA application’s object model, you can consider its security model and transaction model. Since .NET extends the existing COM-based security and transaction models but supports existing functionality, you’ll find these issues easy to resolve.