Returning and Sending data from an ASP.net Web Service

Question

Hi,

At present, we have a number of web services where when we send data to them, we send it as a string which is an XML block and the web service parses and does some work.

Similarly, when we need data from a web service, we are returning a string which is again an XML block which the client application parses.

Are there disadvantages in doing it this way. Also should we be returning types that get serialized to xml?

JD

Answer 1

I prefer the serialized method when using this type of webservice. However, you might look at WCF since it offers many advantages over an ASMX web service.

Answer 2

If you send XML as a string and return it as a string, you may as well use REST.

The whole point of webservices is that the XML serialization and deserialization (marshalling/unmarshalling) is taken care of for you, so simply pass complex types around, or a Request object as input and return a Response object.

And you get strong typing without any effort.

Answer 3

A couple of disadvantages:

• In order to call the web service a client needs to know the structure of the XML passed as argument as well as the structure of the XML returned in order to make any sense
• You are performing double serialization/deserialization which reflects on performance

Answer 4

I've done the xml in/out method before for web services as. When I did it was to try out the "covenant" model of parameter passing. It worked out pretty well overall, made things fairly easy to implement and revision.

The implementaiton that I followed was to create the schema for my input/output xml, and then use xsd to generate classes for serialization. So within my web service I just worked with strongly typed objects and serialized to/from xml to handle the actual request and response.

Some pros

1. Easy to revision parameters both inbound and outboud by creating a new version of the namespace in the parameter schema. As a result you never have to change the web method that a client calls (they just change how they handle your inputs and outputs which they would have to do anyway)
2. Helps with backwards compatibility - you send in a 1.0 namespace request and you alwasy get a 1.0 namespace response.
3. You can validate your input xml against the schema, and add additional validation in the object type.

Some cons

1. Same revision issues that COM had (you can easily get to a point where you have a number of different versions of your web service parameters floating around, when can you get rid of them completely?)
2. Serialization can have an impact on performance. For my web service it was not a huge impact, but your web serivce may have different throughputs/needs than mine did.