Passing XML Strings to Webservices - a bad practice?

[Arno Huetter]

Hi there,

when I design webservices, I usually pass simple data container types
to the webservice (one or several objects containing primitive type
members) - this simplifies client- and server-side code, and still
ensures interoperability, e.g. between Java callees and .NET callers,
vice versa, as those data types exist in both worlds.

But what I have noticed is that most of the time I have to integrate
third party webservices (those that have more complex parameter
structures than just an Integer or two), do so by simply defining a
string as the one and only werbservice parameter. which is then
expected to contain XML data in a certain format.

Reluctantly (having no choice) I ususally implement the calling side
that way (assembling the XML string required), but I consider that a
big contradiction to the original design goals of webservices resp.
SOAP. Not only that type-safety is lost, the werbservice
implementation must ensure XML validity and run some XML parsing on
each call - something that I would prefer SOAP to take care of.

I would like to know whether this is considered bad pratice, or not.

Thank you!

Kind regards,
Arno Huetter

 

[Frank Drebin]

I've never even heard of MSDN TV - those are some really great videos!!!!!
Really good stuff - thanks!

In my eyes, this is not a good practice, no. But it is a viable option,

though ... there is a lot to talk about this issue.

Additionally, I would recommend to watch Doug's MSDNTV show on how to

design loosely coupled and extensible Web services - very good stuff.

http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20030722WEBSVCSDP/manifest.xml

Cheers,
--
Christian Weyer
Microsoft .NET & Service Oriented Architectures

[Microsoft Regional Director, Germany]
http://www.regionaldirectors.de/

* XML Web Services: http://www.xmlwebservices.cc/
* Weblog: http://weblogs.asp.net/cweyer/

Hi there,

when I design webservices, I usually pass simple data container types
to the webservice (one or several objects containing primitive type
members) - this simplifies client- and server-side code, and still
ensures interoperability, e.g. between Java callees and .NET callers,
vice versa, as those data types exist in both worlds.

But what I have noticed is that most of the time I have to integrate
third party webservices (those that have more complex parameter
structures than just an Integer or two), do so by simply defining a
string as the one and only werbservice parameter. which is then
expected to contain XML data in a certain format.

Reluctantly (having no choice) I ususally implement the calling side
that way (assembling the XML string required), but I consider that a
big contradiction to the original design goals of webservices resp.
SOAP. Not only that type-safety is lost, the werbservice
implementation must ensure XML validity and run some XML parsing on
each call - something that I would prefer SOAP to take care of.

I would like to know whether this is considered bad pratice, or not.

Thank you!

Kind regards,
Arno Huetter