Why I Love CFML and Hate .NET

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.

Update
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:
GetEmailEnumeration
GetTemplateParametersByTemplateId
Send

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" />
    
      
      
        
           
        
      
      #Trim(params.message)#

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.

Comments

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 :).

Anonymous

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?

Anonymous

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.

Update. Integrate Aptana Jaxer into Default Apache Instance

NOTE: Just noticed that SyntaxHighighter isn't rendering my Apache code correctly (the directory element gets altered). The code is right but it doesn't display properly.

I had previously blogged about how to integrate Jaxer into a standard installation of Apache. When I completed my Apache + Jaxer setup, I had it configured in such a way that I had to run Jaxer at all times. This was because, in order for Jaxer to do its thing, all HTML files (often includes PHP files) run through the Jaxer server. Of course, such an approach makes sense. Jaxer executes script blocks tagged with the attribute run-at (run-at='server' or run-at='both').

When I setup Jaxer to work with my default instance of Apache, I added the following code to my Apache httpd.conf file:

<directory "/Users/myusername/Sites">
    ...other code removed for brevity...
 JaxerFilter .html .xhtml .htm .php
 JaxerFilterContentType text/html application/xhtml+xml
</Directory>

The 'problem' was that I just told Apache that for any file (of types .htm, .html, .xhtml, .php) in this directory or subdirectory to be filtered by Apache. Naturally, Apache would thrown an error if such a file was requested and the Jaxer server was not running.

It wasn't a big deal, as I set Jaxer to run at start up with the system.

As I am still increasing my knowledge of Apache (I started out using IIS and never really touched Apache until last year), I had an epiphany the other day as I was working on integrating Tomcat with my Apache. I realized that I could add a Directory tag/element to my Virtual Host elements for Jaxer-based sites...duh!!!

So, I removed the two lines from the Directory element above and added the following to all Virtual Host elements in my httpd-vhosts.conf file that use or require Jaxer.

<virtualhost *:80>
    ServerAdmin sompin@gmail.com
    DirectoryIndex index.html index.htm index.php
    DocumentRoot /Users/myusername/Sites/jaxersite1
    ServerName dev.baddogsconsulting.com
 <directory "/Users/myusername/Sites/jaxersite1">
  JaxerFilter .html .xhtml .htm .php
  JaxerFilterContentType text/html application/xhtml+xml
 </Directory>
</VirtualHost>

<virtualhost *:80>
 ServerAdmin sompin@gmail.com
 DirectoryIndex index.html index.htm index.php
 DocumentRoot /Users/myusername/Sites/jaxersite2
        ServerName dev.jax-blog.com
 <directory "/Users/myusername/Sites/jaxersite2">
  JaxerFilter .html .xhtml .htm .php
  JaxerFilterContentType text/html application/xhtml+xml
 </Directory>
</VirtualHost>

This small change alone freed me from having to start Jaxer with the system. Now, I can simply open the Jaxer Launcher application and fire up Jaxer when I am ready to code and test.

It's a small thing and, perhaps, not worth the extended post but I felt compelled to blog it in the event that someone learning about Apache and/or Jaxer might find it useful. For me, it was an important realization of what you can configure in a VirtualHost element (yes, I really should read the Apache documentation sometime!!).

Now, if I could only get Tomcat to 'see' my UrlRewriteFilter JAR/Class file so that I can finish with connecting it to my default Apache instance :)!

Flex 3/4. Working with the SOAP Response Header XML

I've blogged previously about a Flex application, on which I am currently working, that is backed by .NET Web Services. Other than the Authentication Service, the other Web Services require an authentication Token in order to execute.

Before working on this application, I never worked with Web Services as my data source in Flex (I've typically used Flash Remoting via a ColdFusion server). As such, I am no expert in SOAP requests and responses.

One of the things I had trouble with was getting the data from the SOAP response header's XML. Typically, most the data I need is in the Body of the SOAP response. However, when a user in the application is authenticated, the Token object's details are contained in the SOAP header:



  
    
      4511ec65-e25b-4c08-8f94-478df913692c</Id>
      bbd12fa7-f292-4bc5-a37f-06234e877ad8</UserId>
      user_name</UserName>
      e6b3998c-13d9-49fe-a13e-7af27c8229fd</ApplicationId>
    </Token>
  </soap:Header>
  
    
      true</AuthenticateResult>
    </AuthenticateResponse>
  </soap:Body>
</soap:Envelope></pre>
As you can see from the code above, the body's response is true (meaning we've been authenticated...naturally, this would be false if authentication failed). However, in order to make another call, I need to extract the Token XML object from the soap:Header element and store it in a Flex object (also called Token). 

The problem was that I could not take the E4X approach to XML because the SOAP namespace caused problems (I could not traverse the XML). Here's what I did previously to get around this problem (it works but I know it is 'wrong'):

private function onAuthenticateSuccess( e:ResultEvent ):void
{   
 var respXML:XML = e.headers[0] as XML;
 token = new Token0();
 token.Token = new Token();   
 token.Token.Id = new Guid(respXML.children()[0].toString());
 token.Token.UserId = new Guid(respXML.children()[1].toString());
 token.Token.UserName = respXML.children()[2].toString();
 token.Token.ApplicationId = new Guid(respXML.children()[3].toString());
}

The slightest change in the SOAP Response's Header XML would kill this (i.e., if the element ApplicationId was moved up to the 3rd spot (array index 2) and UserName was moved to the final spot). Plus, it's not only ugly to look at this code but also goes against all the goodness of E4X in AS3.

In one of my iterations, since bagged, I used a Regular Expression to manually remove the namespace from the XML. This sort of worked but when there were multiple namespaces in use, I still ran into problems. So, I stuck with my crappy approach (above).

While working on migrating this application to Flex 4, I started digging into the Flex LiveDocs again today. In so doing, I came across an entry about working with XML data. Specifically, it related to parsing XML data in RSS feed.

While this wasn't directly related to what I was doing, I found a tidbit on namespaces in XML. In short, I learned how to simply reset the XML namespace to a blank namespace (i.e., remove the namespace altogether). As soon as I did this, I was able to use the E4X approach to XML in my ActionScript to cleanly and clearly extract the Token object from the SOAP response's header XML.

Note:
The following code is a little different from the previous block in that it's from Flex Builder 4 (Gumbo), which parsed the Web Services in a different manner than Flex Builder 3 does/did. Specifically, Gumbo produces a cleaner Token object than Flex Builder 3 did. As a result, I did not need to create sub-objects (above is token = new Token0() and then token.Token = new Token()).

private function authResult( evt:ResultEvent ):void
{
 var tokenXML:XML = new XML(evt.headers[0]);
 if( tokenXML.namespace("") != undefined )
 {
  default xml namespace = tokenXML.namespace("");
 }
 token.ApplicationId = tokenXML.ApplicationId;
 token.Id = tokenXML.Id;
 token.UserId = tokenXML.UserId;
 token.UserName = tokenXML.UserName;
}

The key to this solution starts in the second line of the above function (the if statement). I check to see if the XML from the SOAP header has a namespace: if it's not undefined, then we've got a namespace in play. If we find a namespace, the default XML namespace is set to a blank string. Once that's taken care of, it's easy to take the E4X approach, treat my XML (tokenXML) as an object and grab the values from the XML and store in the respective properties of the Token object. This code is SO much cleaner and it has the added benefit of not caring about the order of the XML in the SOAP Header. The server-side developers can make changes and, so long as the properties do not change, my code doesn't care. 

I realize this is pretty basic stuff for many who've worked with Web Services in Flex as their data model/source over the years, however, my hope is that it might save someone new to this part of the Flex world a bit of time!</div>
Comments


Anonymous

This comment has been removed by a blog administrator.


Craig Kaminsky

@anon: Thanks for your comment. 

In FB3, I did use the WSDL introspection tool, which does indeed create the classes like you describe (I had a problem with the Auth service classes that the WSDL introspection created, which is why I had to go to the XML--there were no classes to get the Token object from the header). 

In FB4, it's a bit different. You select an option to "Connect to a Web Service" and then enter the WSDL. However, it does not create these classes any longer. Through the Data/Services view, you are supposed to be able to set the return data type from the service. 

In fact the content property of the headers object doesn't exist in FB4! I can see it, however, in FB3. Its interesting where there going with data services in Gumbo and, for the most part, it seems like a major improvement but I'm still trying to figure it all out :)


Anonymous

Craig,

I noticed that you mentioned that Flex Builder parsed yr webservices and was wondering if you meant the WSDL introspection tool in FB3/4.

If so, then you won't be needing to deal with XML at all really. The introspection strong types all the available elements declared in the WSDL of the web service allowing you to treat that Token soap element as the generated Token class. But you have to use the generated Service classes as well in order to be able to take advantage of those benefits. I noticed the typed ResultEvent and assumed you are not, because the response events are also typed to classes and use a naming scheme like AuthenticateResultEvent, where the result property is of course typed. In this case would be a boolean.

If you choose to use the generated services, you can simply access the already typed return token via the headers property of the result event like so:

evt.headers[0].content

If the only returned header is indeed the authenticated token, then can always expect an object of that class, without have to create it yrself.

This comment has been removed by a blog administrator.

@anon: Thanks for your comment.

In FB3, I did use the WSDL introspection tool, which does indeed create the classes like you describe (I had a problem with the Auth service classes that the WSDL introspection created, which is why I had to go to the XML--there were no classes to get the Token object from the header).

In FB4, it's a bit different. You select an option to "Connect to a Web Service" and then enter the WSDL. However, it does not create these classes any longer. Through the Data/Services view, you are supposed to be able to set the return data type from the service.

In fact the content property of the headers object doesn't exist in FB4! I can see it, however, in FB3. Its interesting where there going with data services in Gumbo and, for the most part, it seems like a major improvement but I'm still trying to figure it all out :)

Craig,

I noticed that you mentioned that Flex Builder parsed yr webservices and was wondering if you meant the WSDL introspection tool in FB3/4.

If so, then you won't be needing to deal with XML at all really. The introspection strong types all the available elements declared in the WSDL of the web service allowing you to treat that Token soap element as the generated Token class. But you have to use the generated Service classes as well in order to be able to take advantage of those benefits. I noticed the typed ResultEvent and assumed you are not, because the response events are also typed to classes and use a naming scheme like AuthenticateResultEvent, where the result property is of course typed. In this case would be a boolean.

If you choose to use the generated services, you can simply access the already typed return token via the headers property of the result event like so:

evt.headers[0].content

If the only returned header is indeed the authenticated token, then can always expect an object of that class, without have to create it yrself.

Why I Love CFML and Hate .NET

Comments

Disclaimer

Comments

Author

Craig Kaminsky

Why I Love CFML and Hate .NET

Comments

Disclaimer

Older · View Archive (109)

Update. Integrate Aptana Jaxer into Default Apache Instance

Comments

Newer

Flex 3/4. Working with the SOAP Response Header XML

Comments

Author

Craig Kaminsky