what is the convention for returning .NET only data types from web service

[Tarren]

Hi:

What would be some standard convention to follow when writing web services
for return types for .NET only data types? I initially wrote my web service
that returns some XML as System.XML.XMLDocument and some lists as
System.Data.Datasets. I realized this would be precluding any non-.NET apps
from using it.

Is it generally considered OK to have web services take and return data
types that are .NET only? Doesn't it negate the idea of web services in
general of being platform independent?

Has anyone dealt with this type of issue?

Thanks

[Sami Vaaraniemi]

"Tarren" <no*****@thankyou.com> wrote in message
news:eA**************@TK2MSFTNGP10.phx.gbl...

Hi:

What would be some standard convention to follow when writing web services
for return types for .NET only data types? I initially wrote my web service that returns some XML as System.XML.XMLDocument and some lists as
System.Data.Datasets. I realized this would be precluding any non-.NET apps from using it.
Returning an XmlDocument is fine as far as interoperability goes. An
XmlDocument serializes itself as plain XML so the client can read the
response using the usual XML techniques. With an XmlDocument, you are not
tying yourself to .NET.

A DataSet, on the other hand, is problematic from non-.NET-client's point of
view (for more information on this, read
http://msdn.microsoft.com/library/de...e02112003.asp).
Is it generally considered OK to have web services take and return data
types that are .NET only? Doesn't it negate the idea of web services in
general of being platform independent?

It does negate the idea of platform independency, but it really depends
entirely on your specs. Is interoperability a requirement now or in the
future? If so, don't return .NET-only types. If interoperability is not a
requirement, then .NET Remoting might be more appropriate for your needs.

Regards,
Sami

[Tarren]

thanks for the response - very helpful
"Sami Vaaraniemi" <sa**********@pleasejippii.fi> wrote in message
news:u$**************@TK2MSFTNGP12.phx.gbl...

"Tarren" <no*****@thankyou.com> wrote in message
news:eA**************@TK2MSFTNGP10.phx.gbl...

Hi:

What would be some standard convention to follow when writing web
services
for return types for .NET only data types? I initially wrote my web

service

that returns some XML as System.XML.XMLDocument and some lists as
System.Data.Datasets. I realized this would be precluding any non-.NET

apps

from using it.

Returning an XmlDocument is fine as far as interoperability goes. An
XmlDocument serializes itself as plain XML so the client can read the
response using the usual XML techniques. With an XmlDocument, you are not
tying yourself to .NET.

A DataSet, on the other hand, is problematic from non-.NET-client's point
of
view (for more information on this, read
http://msdn.microsoft.com/library/de...e02112003.asp).

Is it generally considered OK to have web services take and return data
types that are .NET only? Doesn't it negate the idea of web services in
general of being platform independent?

It does negate the idea of platform independency, but it really depends
entirely on your specs. Is interoperability a requirement now or in the
future? If so, don't return .NET-only types. If interoperability is not a
requirement, then .NET Remoting might be more appropriate for your needs.

Regards,
Sami