This post isn't meant to be a rant against .NET; rather, it's an expression of general frustration with the .NET Web Services I have been forced (project requirements) to work with the past two months.

I received some good comments (below) that pointed the issues I've dealt with are more design than .NET. That's actually great to hear because it's been incredibly frustrating. As a CFML and PHP developer (learning Ruby and Java in greater depth this year), I would look at these services I've been dealing with and think "this could be so much simpler...and easier to work with". Thanks for the feedback!

The Background
I'm working on a Flex application to be used in a medical research project. The back end technology driving the application are .NET Web Services. Until last Friday, I was working with two Web Services: one for authorization and another for dealing with the main user type (a researcher).

The authentication service is pretty generic. Collect and user name and password and pass to the service, which returns a boolean indicating whether or not the authentication was successful or not.

The researcher service is a bit more complex. It enables the application to get and set a wide range of data related to the researcher's study. It's been a bit of a pain for two reasons: first, many of the methods are, in my opinion, quite convoluted. One way I think they're convoluted is in the returned data type. For many of the methods, what comes back is dependent upon what you request. Second, dealing with conditional data types being returned (or expected in a call) from .NET Web Services can, depending on your setup, result in encoding and decoding errors. These are known bugs in Flex 3.x (it's supposedly fixed in 4). Still a pain, even if it is Adobe's 'fault', because I can't help but think that the Web Service methods could be less complex, yet equally robust.

Going Over The Edge
The third service, a messaging service, was deployed last Friday to our test environment. This is the Web Service that just killed me. The entire purpose of this Web Service is to take a string and send this string, via email, to a pre-determined recipient (it's not even a dynamically generated email address to which we send the note).

Following are the methods in this service:

Seriously?! .NET needs three methods to send an email? Seems like overkill to me.

Here's the process I have been instructed to take:
First, call GetEmailEnumeration() to get the EmailId class, which contains all the Email templates. This class returns a few names of templates. Fine. But if I have to call this method and still set which one I want to use, why can't I just pass a string parameter to the send method to get the freaking template?

Second, call GetTemplateParametersByTemplateId() to get an array of Parameter objects which are the email template parameters for sending out the email. The resulting array of Parameter objects just contains name/value pairs I need. Again, why not just let me set these as parameters of the send method without making a call to the server to get, essentially, static data?

Third, call the send method, passing in the email id and the parameters object (array of parameters). The user content is set as a pre-defined parameter named 'Verbatim'.

In summation, I need to make two server calls to get information that I know anyway (we know what parameters we are going to receive and then regurgetate the name/value pairs we receive when calling the send method. This just seems ridiculous to me, not to mention inefficient. Why force the server to handle two extra calls when, for the life of me, I cannot see why we need them.

Less Code, Greater Efficiency: The ColdFusion Way
Here's a basic CFML version of a similar Web Service:

<cfargument name="params" type="struct" required-"true" />


Of course, I have only stubbed this out with the most basic of functionality but, really, how much functionality is needed to send a "Contact Us" email? That's all we're doing on the client side. Sending a freaking generic contact us note to a dedicated email address.

I just don't see the benefits, on any level, to the .NET Web Service's approach. Why make something that is so bloody common and easy to do, so difficult and cumbersome.

While it's frustrating to have to deal with .NET Web Services on any level, I must say that this experience (and others like it) deepen my appreciation for ColdFusion, as both a language and server-side platform.


Craig Kaminsky
@k: you are absolutely right. This is an annoyance with the API design. Good point.

@anon1: very true (bad designs are all over the place).

@anon2: I don't think they have heard of WCF. I'm going to check that out and see if I can't get them to improve these services. Thanks (unfortunately, I can't change the consultants :).
The problem sounds like you have a bad .net programmer; all of the points you made and blamed on .net were due to bad service contract design - not bad .net framework.

The bad message service design alone should merit a change of .net consultant.

Haven't they heard of wcf?
Sorry but your example merely shows a bad design on the webservice's programmer's part, this has absolutely nothing to do with .NET itself. Its just poor design, which is possible on any platform you imagine...
K Oyedeji
I'm guessing your annoyance is with the people who designed the .NET api you have to use and has nothing really to do with .NET (after all the same Api could have been written in ColdFusion), there is nothing in .NET preventing you from passing multiple parameters.