The other day I wrote about sharing types between web services to simplify implementation of consumers of these services. You can read about it Multiple web service references sharing typeshere[/intlink]. I mentioned a nicer way to accomplish almost the same thing and I will present it here, by giving an example.
The biggest difference is that you have to define an interface, let all web service producers implement this interface and you as a consumer will be left with a minimal amount of work to consume all these web services as long as their end points are well known.
In this article I would like to point out a useful way to accomplish something that would be really easy, but still have been annoying me for the last couple of months. Imagine that you would like to get some data of some type from one web service and pass it on to another. The data types on both server sides are the same, but the compiler won’t let you pass the type from the first service on to the next one. Casting won’t work either, not without implementing some kind of home made casting method.
This article presents nothing new at all, but sometimes it is nice to freshen your memory when it comes to smooth stuff available in the .NET Framework. I will give a couple of examples to select, count and look up elements in a collection of objects, both using regular functions and by using lambda expressions. The methods I will use are available when using .NET Framework 3.5.
Coming back from a little break during Christmas I looked around on the ASP.NET web site (
The other day I got a question from a colleague of mine, regarding the XML schema usage when defining a web service interface, like the one defined in series. The question was something like this: “How will the consumer of the web service react if the, from the XSD file, auto-generated class used as in and return parameters is updated?” I couldn’t give a straight answer, other than that I assumed it would be transparent to the consumer as long as no nodes were changed or removed and only new nodes were added to the schema. I decided to give it a try, using a really simple XSD and a couple of really simple web methods. I will give a schematic picture of the scenario that I will test out later on. 
Right after I published the previous post on the spatial data and BLToolkit components I decided to write a follow-up on that post. I wasn’t happy about the way I described the implementation of the new property and field attribute to support the SQL Server UdtTypeName property and spatial data types. I hope I will make it more clear how I accomplished the support for this here. Please read the previous post about this on, . 
I decided to start the process of creating a web service using an MVC like design pattern by specifying the interface towards the consumers. The interface has to be “nice”, and by that I mean that the parameters and return values should be easy to understand and use.