Introduction

In this post I will share my considerations for upgrading an ASMX Web Service to WCF in an existing product. Following the upgrade I encountered a little hitch with Flash and cross domain policies. In this later post I demonstrate how overcome the hitch with WCF.

Motivation for the Upgrade

When I started working on the project, the architecture had been set and a first version of the product had already been released. A Flash client interacted with an ASMX Web Service hosted by ASP.NET. My part was to make additions to the UI, but I couldn’t help reviewing the architecture to see what I could learn and improve.

An important first observation was that the Flash-ASMX combination works. Microsoft and Adobe are fierce competitors, so I think that deservers mention. Having said that, there are some limitations in the Flash support for SOAP Web Services which were disappointing.

For instance, in a Web Service you can define enums, and through the WSDL, these can be treated as enums on a Microsoft client. However enums are not supported by Flash clients. See the bug report here. Trivial as that may seem, the impact on design is significant. It encouraged the original designers to use strings and integers in the interface. With very little strong-typing in the API, maintenance and debugging became difficult indeed.

Quite early on I decided to upgrade the ASPX Web Service to WCF. I had three reasons for this:

1. WCF supports multiple concurrent end-points.
2. WCF implements singleton behavior with a mere attribute, saving coding.
3. WCF can be self-hosted and doesn’t require IIS.

Multiple end-points

The need for multiple end-points in this project was due to the internal architecture on the Server. The service actually had two clients. One was the RIA hosted in Web page, invoked from a remote client, another was a Windows Service running on the Server. The original solution involved an additional Remoting server with the same interface as the Web Service with which the Web Server and the local client interacted. Managing multiple servers, contracts and implementations was tough.

This problem is a natural fit for WCF: All I needed to do was implement one server with WCF and to add endpoint definitions to a configuration file. I defined a standard endpoint for the Flash client using basicHttpBinding and an efficient, proprietary endpoint for the local client using NetNamedPipeBinding.

One contract, one service implementation – just two endpoints.

Singleton Behavior

In the original design, the designers created the service as a Singleton and syncronized accesses to the service from the two clients in code. Rather than clutter the code with locks I preferred to use WCF’s ServiceBehavior attribute with InstanceContextMode.Single and ConcurrencyMode.Single. WCF handles the implementation.

Self-Hosting - No Need for IIS

Actually, this reason was not in my original list. But then, as I approached the design review for the new GUI, the Product Manager of the product and the Technical Writer asked me if they could get a mock-up of the application to review and to document following the review.

This wouldn’t usually be a problem, because, following good practice in GUI development, I was developing against an interface and not a real server. I had already implemented the Web Service contract with a Mock so there would be no need to install any business layer components with the mock-up.

But there was still one hitch. In order to run the mock-up, I needed IIS to host the ASMX web service. My clients would have to install IIS, or I would have to do it for them. What a pain : )

Well, with WCF that was easy to solve – a simple Console Application could host the service in 1-2-3 (or should I say A-B-C).

Summary

In this post I described some very practical reasons why I upgraded an ASMX Web Service to WCF in an existing product. In the next post I will show you how I used WCF to solve a cross-domain problem that I encountered with the Flash client.