Web services that take and return XML documents - why?

Question

Are there benefits of writing a web service interface whose methods all take and return XML documents, rather than the more usual parameter lists of native types and classes?

We have some existing web services that are designed like this. The XML documents that are passed to their methods are typically large (as in they contain maybe 100 pieces of data that are relevant to the method calls). We have XSD files that we use to validate the XML documents, but the overall client developer experience is poor and slow. Surely it would be preferable to have a strongly-typed interface?

The web services are written in C#, and the clients are written in C# and also Java (some of our business partners use Java).

Answer 1

A couple of reasons, and some related thoughts:

• Interoperability. It surely can speed up with some rough edges, but if you stick to simple classes you shouldn't have issues. There is also the possibility to go contract first, but then again you have to understand the limitations, there are some cases where the class generator doesn't work that well :(. But even then, you could load that piece as XML, instead of doing it for the whole thing.
• You want to use it to process different type of messages. Those messages might even be aggregated. Its not the only solution though, as with a bit of work on the definition you can have those scenarios into typed messages.
• It doesn't needs to understand all the bits involved, just send appropriate pieces to appropriate systems. This one is compelling, but even then I don't think it justifies not looking at how to aggregate the xsd for the different systems and consolidate them for your web service definition. This probably needs to be done anyway.

On interoperability, note that you can stick to simple schema's and still have it typed. If that's the concern you don't need to loose support for the rich clients, its for simple schemas that is works the bests. And those are the type of schemas that you want for some languages.

Answer 2

If you absolutely know for sure what your end-user/client technology is (for example pure .NET and Java where the feature set is probably the richest) then by all means go ahead and take advantage of strongly typed interfaces where available. But if your client base is a mixed bag of Perl, PHP, ASP, Python etc, then I'd keep life simple and accessible for these folks.

We have a number of web services that have to be consumable by this sort of mixed bag of clients, and whilst I'd love to make life simple for us, we have to dumb down a bit purely to ensure maximum interoperability.

HTH
Kev

Answer 3

Another reason would be certain very complicated XML documents that could be represented as classes, but which would be awkward. Deeply nested documents with many repeating elements, for instance: doc.a[3].b.c[4].d[52].e, for instance, gets tiresome very quickly.

Additionally, keep in mind that not all XML schema constructs can translate directly to classes. They're not meant to. An XML Schema that was built to be XML and not types may very well not translate into classes at all.

Answer 4

I once heard compare a service method with "string xml" in/out this compares to writing a C# function like this:

public object DoSomething(object o){

}

I guess it might have it's usages sometimes, in case you want your service to support multiple versions of a schema for example, but it's not really a transparent design and should therefore be avoided.

I've even seen organizations that define web-service standards for insurance companies design services like this. [Sigh]