Why keep ASMX and WCF separate?

Topics: General Discussion Forum, July and December Releases Forum, Service Factory Modeling Edition Forum
Feb 23, 2007 at 2:18 AM
Edited Feb 23, 2007 at 2:27 AM
Hello everyone!
Let me first congratulate you for this project. I find it very very usefull not only for the rapid service development it brings, but also for its educational value.
I've reviewed it today and one of the thoughts that crossed my mind is why did you choose to implement ASMX and WCF as separate packages. The diferences between them are only at the service interface level and those are also very similar.

I did a little experiment. I've created two solutions(with identical names) using ASMX and WCF (noticed that the WCF package is slightly more advanced than the ASMX). Then I've copied the attributes from the objects in the ASMX solution to the coresponding objects in the WCF solution such that they will have both System.Web.Services and System.ServiceModel attributes.Then I've exposed the service in the same Web Project using an asmx and a svc file. The same client has a web reference to the asmx file and a service reference to the svc file.
The only choise is on the client really, in that is has to choose wich proxy to use.

Of course, this scenario may not be adequate to all situations but if you could merge the two packages into one, you would have to maintain just one, giving you more time to concentrate on the more important problems.

Thank you,
Alexandru Serban
Feb 23, 2007 at 12:12 PM
Edited Feb 23, 2007 at 12:17 PM

Thanks for your comments and as you pointed out, the two implementations are very similar, in particular the ASMX package was designed to follow the same design principles and patterns in order to ease a future migration to WCF and also to be aligned with this technology.
Regarding your question about why they were implemented in separate packages, as far as I know there were timing (ASMX in v1 of WSSF was previous) and different "community needs" (at the time of v1, WCF was still in Beta and not ready for production) that drove that decision. Now in v2, most of the effort was put on the WCF version (package, RI, guidance, etc.) and therefore both packages remained separate.

Now this might change for v3 Project Status Podcast since one of the main design changes will start the guidance (tools) from the design (Domain-Specific Language Tools) regardless of which technology you choose (ASMX or WCF). So keep in touch with WSSF and stay tuned for the upcoming v3 that will have many more features and guidance for designing and building your services.