Migrating ASMX Services To WCF services

January 17, 2012 § Leave a comment

(Source : Code Project 
http://www.codeproject.com/KB/WCF/ASMX2WCF.aspx)

Problem and Target

Many companies still have Web Services that are currently implemented with .NET2’s ASMX technology and their customers have tools that have have proxies created with .NET2 technologies. Normally introducing WCF endpoints will require these tools to be re-engineered, which is a huge problem and needs to be avoided as much as possible. There is only one modification that is considered acceptable in such a process and that is changing the endpoint url for the clients. That is because an ASMXService has normally a url like http://host/Service.asmx and a WCF Service has http://host/Service.svc. The target is to change the service implementations without the existing client tools knowing about it, at least in the sense that no code modifications are required.

This article discusses the problems, solutions and possible pitfalls while trying to implement a solution for this migration process.

Terminology

Prior to WCF, a .net2.0 web reference was created in the clients that acted as a proxy that fascilitated the communication with a web service. .NET3.5 introduced a new mechanism to create these proxies that are also compatible with WCF Server Side technologies.

For simplicity reasons in this article each technology will be referred as

  • Client20
  • Client30

Proposed Solutions

There are two ways to manage such a transition.

Solution 1

Making the ASMX and WCF layers act as wrappers layers to the actual functional implementation of the contract. That means that at any time two seperate endpoints will be exposed that will redirect calls to a common function. All existing clients will connect to the old endpoint and all new clients to the newer one.

Solution 2

Making the WCF Service act as a ASMX service

Researching into the problem

To easiest way to research about this problem is to recreate it in a simpler solution that reproduces existing infrastructure and tries to achieve valid connectivity between all parts, old and new.

ServerSide

For simplicity reasons, a common contract interface is created that is implemented by all services.

 Collapse | Copy Code
public interface IStringService
{
    string StringConcat(string value1, string value2);
}

Two different projects are created on the ServiceLayer that provide ASMX and WCF Services for theIStringService contract.

Both service implementations are provided by a function in common reference assembly.

Client Side

Different client projects are created that provide proxy classes for the above services. One project uses Client20for the proxies and the other Client30. Every proxy class should be able to implement a common interfaceAt this point these all client can connect to all services, thus having the following combinations

  • Client20 – ASMX Service
  • Client20 – WCF Service
  • Client30 – ASMX Service(obsolete)
  • Client30 – WCF Service

The combination of Client30 – ASMX Service is obsolete.

 Collapse | Copy Code
public interface IStringServiceClient
{
   string StringConcat(string value1, string value2);
}

At this point we have met the requirements of Solution1.

For Solution2 the goal is to create a WCFAsASMX service project that exposes a WCF Service implementing the IStringService contract in order to replace all above Services successfully.

  • Client20 valid connectivity without code modifications ensures backwords compatibility
  • Client30 valid connectivity without code alterations ensures that changes to WCF don’t hold back the implementation for the future. (That is we haven’t just changed technology name in the implementation but we can get all current and future benefits that WCF provides.)

This can be achieved in the steps

  • ”’Goal1 ”’with Solution2 is achieving successfull calls with changes at Client20 url endpoints.
  • ”’Goal2 ”’with Solution2 is achieving successful calls without any change.

Goal1

Force the wife service in the WCFAsASMX project to accept the the Client20‘s requests. In this case the namespace for the services is “http://tempuri.org/” but it can be a properly specified one. Based on this namespace the changes required are

  • Annotate the service with
 Collapse | Copy Code
[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
  • Annotate the method in the service with
 Collapse | Copy Code
[WebMethod]
[OperationContract(Action=@"http://tempuri.org/StringConcat")]
  • If you are using arrays of basic types, for example string[] the annotate additionally the Service with
 Collapse | Copy Code
[XmlSerializerFormat]

Now a Client20 can connect to the WCF Service with only an endpoint change. From http://host/Service.asmx to http://host/Service.svc

Goal2

This is achieved by making IIS service ASMX requests with WCF. These are the required changes:

  • Alter the web.config file by adding in the system.web/compilation node
 Collapse | Copy Code
<buildProviders>
    <remove extension=".asmx">
    <add extension=".asmx" type="System.ServiceModel.Activation.ServiceBuildProvider, System.ServiceModel.Activation, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</buildProvider>
  • Copy the content of the svc file in the asmx file

Comparing the solutions

Both solutions come with an inherent limitation. They cannot provide WCF features to both clients without breaking backwards compatibility. So it is important to understand that Client20 implementations should phase off as soon as possible, because they significantly limit the benefits of the technology transition.

Solution1

Positives

  • WCF Service implementation is kept clear of alterations that act as backwards compatibility. This is a good thing everyone wants when introducing a new solution. Existing clients need no modification

Negatives

  • Two different physical sets of Service Layers are exposed and need to be maintained, that act as wrappers for the actual functional implementation.
  • Existing clients don’t connect to the actual WCF technology Stack, thus they don’t get the benefits of the new technology such as performance.
  • There is a sense that two different technologies are supported for the proxy generation tools.

Solution2

Positives

  • Although two logical sets of Service Layers are exposed, only one actual physical is. This reduces the layers to maintain.
  • Existing tools connect to the WCF stack and benefit from the benefits of the new technology.

Negatives

  • Some minor alterations in the WCF Service have to be made. Although the changes seem simple enough they are still meant for backward compatibility and that is something that must be always be taken into account. The positive is that in the long run, once the Client20 implementations have phased off, removing these modifications is really simple.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

What’s this?

You are currently reading Migrating ASMX Services To WCF services at Naik Vinay.

meta

%d bloggers like this: