Saturday, March 22, 2008

Weakly typed webservices

Weakly typed programming versus strongly typed programming is one of the many religious wars fought by programmers. In my opinion it's all a matter of personal preference and I myself prefer strongly types languages. They give me the compile-time errors when I do something really stupid and I like that, even if it means I must work a little harder to convert one type to another.

On the other hand, I have found out that I don't like strongly typed webservices. What is a strongly typed webservice? Well, consider that a webservice is basically just some XML send over an HTTP connection (yes I know there are a lot more varieties, but when most people talk about webservices they tend to mean SOAP over HTTP), so everything is basically a string. A weakly typed webservice would have all its inputs and outputs defined as strings. A strongly typed webservice on the other hand would have its inputs and outputs defined as the type of data it's supposed to represent: ints, bools, DateTimes, etc.

To make the discussion a little more clear, here is a weakly typed webservice (in C#):

[WebMethod]
public string WeakWebservice(string inputDate);
And this is a stronly typed webservice:
[WebMethod]
public int StrongWebservice(DateTime inputDate);
So why would I want a weakly typed webservice?

Consider that all values are sent over HTTP as text, so that DateTime parameter 'inputDate' for the strongly typed webservice is possibly sent as "2008-03-20T18:39:12Z".

The SOAP stack at the webservice side will then take this string and interpret it so it can be turned into a DateTime object and given to the webservice entry point. At that point the code you or me wrote will get in on the action and is allowed to do stuff. Everything before that is done by the SOAP stack (in my case the ASP.NET SOAP stack).

Since everything is sent as text, there is no objection to calling the webservice using a client that doesn't understand the .NET DateTime class. All goes well as long as the client sends the text formatted in a way the SOAP stack expects it (as is defined in the SOAP specification). For as long as my client sends "2008-03-20T18:39:12Z", it will be interpreted and turned into a DateTime object for me. But what happens when I make an error in my string and I send something that can't be interpreted as a .NET DateTime object?

You'll get an error:

System.Web.Services.Protocols.SoapException: Server was unable to read request. ---> System.InvalidOperationException: There is an error in XML document (11, 74). ---> System.FormatException: Input string was not in a correct format. at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal) at System.Number.ParseInt64(String value, NumberStyles options, NumberFormatInfo numfmt) at System.Xml.XmlConvert.ToInt64(String s) at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read3_CustomerInfo(Boolean isNullable, Boolean checkType) at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read21_IptvGetAccountInfo() at Microsoft.Xml.Serialization.GeneratedAssembly.ArrayOfObjectSerializer.Deserialize(XmlSerializationReader reader) at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events) --- End of inner exception stack trace --- at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events) at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle) at System.Web.Services.Protocols.SoapServerProtocol.ReadParameters() --- End of inner exception stack trace --- at System.Web.Services.Protocols.SoapServerProtocol.ReadParameters() at System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest()

I don't know about you, but I find this error hardly useful. Now consider a webservice function with 3 objects as parameters, each object containing more parameters a few levels deep. How useful is this error then in finding which of the parameters is wrong? Granted this is specific for .NET and I have no idea how Java for example would handle this, but you see my point?

I my company we return error codes and error messages as part of the return value of the webservice. We call these "functional errors". We decide which error code means which error situation and we don't use SOAP Faults or HTTP error codes. That is, we don't want to. If the webservice isn't available, or the authentication goes wrong you'll still get an HTTP error and in the error shown above, you'll get a SOAP fault.

But if the specification says you need to send a string no more then 10 characters long, we check that in de code and return an error code if the string is to long. But if the specification says you need to send a number, but you send a word, then you'll get a SOAP Fault. That's not consistent.

The next time I'm tasked with creating a new webservice, I will make it weakly-typed. All the input and output will be defined as strings. That way I can validate the input myself and return a nice functional error when it's incorrect.

Sunday, March 16, 2008

Stored procedures, faster or not? (SQL Server)

I'm not really that knowledgeable about databases. I can do a select or two and I understand joins, but anything more complex that then that and I won't like it. I don't really like SQL. The language seems very illogical to me for some reason.

We do have a lot of discussion at work about databases. A colleague of mine really loves delving into database problems and he even made a list of SQL standard practices. One of these standard practices says that we should always use stored procedures instead of dynamical SQL statements.

I always want to know the 'why'. Why are we supposed to use only stored procedures? And the reasons invariably are:

  1. Stored procedures are not susceptible to SQL injection.
  2. Stored procedures are safer because you can secure them on the database level.
  3. Stored procedures enable us to update database logic or fix a bug without having to release a new version of the software.
  4. Stored procedures are faster then dynamic SQL.

Almost two years ago and ran into a weblog post that debunked all of these points: Stored procedures are bad, m'kay?.

Given this article, there is still a lot of discussion at the office and people generally still say stored procedures are faster and safer. So yeah, stored procedures are faster then SQL created by adding SQL statements and their parameters together with string concatenations, but according to the article they're not faster then properly parameterized SQL queries. And as for security at the stored procedure level, we don't do that in our office, so that shouldn't be a concern. Also, when changing a stored procedure, we still need to create a new release of the software, even though only a SQL script changed. That's just the way we work. So the 'software release' argument is also nonsense.

I will agree that stored procedures are faster in that you only send the name of the query and the parameters, while with dynamic SQL you'd need to send the entire query with the parameters. So it's faster in that you save a few bytes sent over the wire. And for some really rare cases those few bytes can make a difference, but not in the applications we make.

In the end it's a discussion about what 'feels' better I think. One of the many religious wars fought in the field of software development.

Thoughts on Coding

I've been programming for close to 14 years now. I started programming in x86 assembly, then moved to Turbo Pascal, then Turbo C++, Visual C++, PHP and finally C#. It started out as a hobby and finally it turned into work.

I still program for fun, although not nearly as much as I used to. I'm very busy at work, so when I get home I'd rather play some video-game, watch a movie or spend some time with friends.
I do read a lot about programming or programming-related stuff though. I read a whole host of different weblogs and try to keep up on the latest advancements and technologies.

So, why the weblog? Well, there have been countless times where I ran into a problem, or didn't know how to fix a particular problem and finally found the answer on some persons weblog. These things have been of tremendous value to me. Since I also figure things out on my own on an almost daily basis and since I think a lot about design stuff and a lot of other things programmers have to deal with, I thought: "why not put these on a weblog?" I mean, maybe someone out there has the same problem and maybe I can help him out by explaining my solution. And maybe I have a really crazy idea and I would like some feedback on it by other programmers. A weblog is a dialogue after all.

So, if anyone has questions, or remarks about anything I post here. Leave them in the comments and we can discuss them. I'm looking forward to it.