Migration Strategies
| 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 |
When migrating from ASMX to WFC, you can choose among three migration strategies:
To not migrate. XML Web services will continue to be supported for many years and there may be cases where it does not make sense to migrate an existing Web service.
To maintain functional equivalence between client applications and services. With this strategy, the same operations are supported by the WCF service, but the implementation is different and not compatible with the ASMX service. For example, a client application of the ASMX service cannot call the WCF service without adding a new reference and being rebuilt. There are two approaches to implement this strategy:
- Use code to update both the client application and the service at the same time.
- Implement a second endpoint that uses WCF. This approach is feasible when using a layered design that supports the reuse of components.
To maintain wire-level compatibility between services. With this strategy, the WCF service is compatible with the ASMX service, which means that an ASMX client application can call the WCF service without changing any code. This strategy also has two different approaches for implementation:
- Use metadata from the ASMX service to generate code that can be used to implement the same service in WCF.
- Copy the ASMX code into a WCF solution and then modify the code to support WCF. In many cases, this task consists of changing an attribute on classes and members.
When implementing a migration strategy, you can modify existing code, use code generated from metadata, or use a combination of code generation and modification. When modifying existing code without using any metadata-generated code, the development approach is referred to as a code-only approach. When using metadata-generated code, the development approach is referred to as a metadata approach. The development approach you choose is based on different factors, such as the migration strategy you are using and the design of your service.
The design also plays a role in the migration strategy you might choose. For example, it is not practical to implement a second endpoint that uses WCF in a design where all business and data access logic is implemented in the ASMX WebMethod function.
If your chosen strategy is to maintain functional equivalence, it is not necessary to maintain compatibility with ASMX services. As a result, you can take advantage of new capabilities provided by WCF, such as different transport protocols and built-in security. The development approach you use can be accomplished with metadata-generated code or by modifying existing code. In many cases, you will probably use a hybrid approach. For example, you can use the SvcUtil tool with the /dconly option to generate data contracts and then modify the ASMX service interface to support service contracts.
If your chosen strategy is to maintain wire-level compatibility, the recommended approach is to use metadata-generated code to implement the service. By using code generated from metadata, you can be assured that the data types and service interface are compatible with the service's existing ASMX client applications. This approach also requires the least amount of work when performing the migration. Alternatively, you can use a code-only approach; however, it requires more effort, and you will need to make sure the new code is compatible with existing client applications.