Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
| Retired Content |
|---|
The Web Service Software Factory is now maintained by the community and can be found on the Service Factory site. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. Retired: November 2011 |
The introduction of XML Web services has made a significant impact on the way that distributed applications are developed today, and it will continue to play an important role in the future. XML Web services implemented with ASP.NET are typically referred to as ASMX services, which is a reference to the file name extension used for services in ASP.NET. As a result, the remainder of this guidance uses the term ASMX services when discussing XML Web services.
The programming model provided by ASMX services has been very successful, but it also represents the first step in support for service-oriented architectures (SOA). To support SOA, Microsoft developed the next-generation programming model named Windows Communication Foundation (WCF). WCF is comprised of class libraries, tools, hosting facilities, and other components that are used to provide a foundation for applications that use SOA. An enhancement provided by WCF is built-in support for multiple transport protocols and the ability to use custom protocols.
The decision to migrate an existing ASMX service to WCF is based on different factors. In many cases, there is no need to migrate; however, when you are planning to migrate, you can do several things to facilitate the migration process. Learning about differences between ASMX and WCF can help with any type of migration. When developing new ASMX services, you can write code that is compatible with WCF. When migrating an existing ASMX service, the knowledge about differences helps you target specific areas that need to be modified, which speeds the process.
Another consideration when migrating ASMX services to WCF is the level of compatibility you want to maintain. If migrating both client applications and services to WCF at the same time, you need to maintain functional equivalence with only the original service. If you are migrating the service only and do not want to affect existing client applications, you need to maintain wire-level compatibility.
Basically, you must decide among the following three different strategies when migrating ASMX services to WCF:
- You can choose to not migrate.
- You can choose to maintain functional equivalence between client applications and services.
- You can choose to maintain wire-level compatibility between services.
In addition to knowing the compatibility requirements, you also have to determine the best approach for implementing the migrated service. Will the design have any influence over the strategy? Do you want to modify existing code, or can you use metadata and tools to generate the code? The answer to the first question is yes; if the ASMX service used a layered approach, you will have fewer components to migrate than with a design that is not layered. Deciding whether to use metadata to generate code instead of manually modifying it depends on your migration strategy. If you need to only maintain functional equivalence and you want to use only WCF serialization, you might need to manually modify the code. However, in most cases, generating code from metadata is the easiest approach to implement.
A solid understanding of differences between ASMX and WCF services is very helpful for determining your migration strategy and development approach. For example, if you want to use a wire-level migration strategy, and the data types in your service use XML attributes, you will need to use the XmlSerializer. If you want to maintain only functional equivalence, you can modify the structure to use elements instead of attributes, which is required when using WCF data contracts.