VB.Net Web Services For Dummies

Question

(Edited to add an example and hopefully make it a bit clearer)

I'm mainly a VB6 developer, but am currently trying to write a web service using VB.Net to allow for communication between our product and a third-party. The third-party software will invoke our web service to update various data.

I've read up various things on how to do this, and have successfully generated a prototype web service. What I'm now concerned about is how to do this properly. Our clients want us to provide the WSDL and XSD for our web service, so they can implement it on their end, so I want to make sure I get it right. Therefore, I have the following assumptions/questions:

The web service will receive various fields that should be updated. To keep this flexible, I thought that this could be a single XML parameter. I'm guessing this is why our clients want the XSD. Is this assumption correct? Is it good practice to pass an XML input parameter?

I created a simple class with a sample of the fields that should be updated (Title, Address1, Address2 and so on) then generated an XSD from that using XSD.Exe. This made me think - should my input parameter be an instance of this class, rather than an XML document based on the XSD?

For example, the fields to be updated relate to client data. There are many possible fields that can be updated, but only a few will probably be updated at a time. Clearly, I don't want a method with 40 parameters for each possible field, and I was also asked to only provide a single method. My idea was therefore to have a parameter naming the fields to be updated, and their values. It seemed sensible to use XML for this parameter. My assumption regarding the request from our clients for the XSD came about so that we can make sure that the XML parameter will only include valid fields. But at the same time, I generated an XSD using Visual Studio based on a sample class I created. But now I'm not sure which is best to use i.e. either:

a) XML: cliData As Xml.XmlDocument: Appears in WSDL, but how would I generate an XSD to make sure the XML is valid? Manually?

b) Class: cliData As ClientData: Serialised in WSDL so each field appears as a separate element. Presumably no need for an XSD, but I don't think this gives me the option to only includes a few fields, and isn't this equivalent to having loads of parameters?

c) String: cliData As String: Pass in some sort of string, unravel it manually, but then no validation.

I initially planned to return the status of the web service (e.g. "OK" or some failure message), though I've seen reference elsewhere to SOAP Faults. There were some links to an MSDN article discussing this, but the links seemed to be broken! Does anyone have any advice on this?

I apologise if these questions have been asked elsewhere - I trawled this site, and the internet in general, but have become so overloaded with information, that I'm ending up with more questions than answers!

Thanks, Olli

Answer 1

It really sounds like you are making your life more complicated than you have to. ASP.NET will handle all the dirty work of a web service for you. To be honest, I am not sure what the XSD is for. I would just make a method on your web service that takes either strings as arguments or takes custom classes. ASP.NET Web Services or WCF Services will handle the serialization for you. Check out the msdn site to get started with this. http://msdn.microsoft.com/en-us/library/ms972326.aspx

Answer 2

I have used services that accept XML strings as input and found it to be more of a hassle than a group of method calls with parameters. If you receive an XML string in your service, you'll have to parse it out just to get the values. I find it easier to just write one or more methods with the required parameters.

I assume your client will not be using .NET to call your webservice. If they will, you can generate a proxy for them using wsdl.exe.

Answer 3

It is a mistake to be too flexible. The service should do what the service is meant to do. If the requirements change later, then add a new operation to the service, or better still, add a new version of the service - it's cheap and easy to do so.

Also, if you are just starting out, there is no sense in starting in the past. Go straight to WCF, and pay no attention to ASMX web services, which are the next best thing to obsolete - there will be few, if any, enhancements made to them, and maybe only critical security fixes.

Basic WCF is simpler, besides. Also, to a large extent, the code you write for the simple case will also be usable, with little or no change, in the more sophisticated cases that may arise later.