Type fidelity - reusing mechanism used by framework to serialize Datasets ??

[Matt]

Hi,

Can anyone please tell me if you can use the same method that
Microsoft uses to ensure the client/server type fidelity of 'Dataset'
for custom types ?

i.e. Wsdl.exe somehow knows not to generate a proxy class for the
Dataset type. Can you use attributes or interfaces on your own
serialized types that force the same behavior ??

I know that you can edit the wsdl generated proxy to achieve the same
effect. I also know that using Datasets is not a good thing to do
from an interoperability view point.

I cannot find any explanation of how this is done. There are plenty
of explanations of XML serialization over Web Services but the
mechanism used to ensure type fidelity of Datasets is glossed over.

Surely there is not code hardwired into wsdl.exe and the Remoting
Framework to specifically handle Datasets?? This would seem to be
inconsistent with the design of the rest of .net that allows
extensibility/reuse wherever possible ??

Thanks in advance,

Matt.

 

[Dan Rogers]

Hi Matt,

The best advice I can offer here is to use datasets inside of your own
applicaiton domains, but not across your web service boundaries. This is
advice centered in maximizing cross-platform, cross tool-version interop
based on well defined data contracts.

As for specific questions about how to decode a dataset, my advice is to
use a dataset to decode a dataset. The WSDL for a contract that involves a
dataset describes an "any" (e.g. an untyped object) - making this a loosely
coupled interface that is not suitable for tool-supported cross platform
interop.

You may wish to consider the WS-I.org basic profile 1.0 guidelines, which
steer you away from using framework specific "smart types" such as the .NET
dataSet, the java Hash table, etc. These require specific implementations
to work with, and thus impede the goals that one would use a web service
interface to solve.

I hope this helps

Dan Rogers
Microsoft Corporation
--------------------

 

[Matt]

Dan,

Thanks for your reply.

As you suggest, I would not use Datasets for any outward facing web
services due to the obvious interoparibility problems.

I am still curious as to how the Dataset marshalling is implemented in
the framework and if that functionality is exposed so it can be used
in other classes. ie. can you stop WSDL.EXE generating a proxy by
marking up the class to be marshalled in some way and hence
automatically gaurantee type fidelity ??

From further investigations, I have come to the conclusion that it
must be hacked into the proxy generator. Maybe you (microsoft)
decided the dataset marshalling was a 'special' type as it is used so
frequently when you have .net on both ends of the wire ??

I am suprised this approach was taken as the design of the web
services framwork (and the whole of .net for that matter) is so
'clean' that this seems to be an anomalous case.

Thanks,

Matt.

 

[Dan Rogers]

Hi Matt,

The specifics of marshalling dataset are covered by patent and trade
secret. As you can see if you look on the wire, it is a pretty complicated
set of data, and the special logic that it takes to understand that
specific type requires .NET on both sides. For web services that are
intended to be used in this environment - .NET on both sides - exposing
data sets directly is a net positive and lets you take full advantage of an
investment in a .NET.

As for cross platform, however, exposing a dataset instead of a schema
defined complex type consisting of well known cross-platform types (as
mentioned previously) will be problematic. The best practices that I've
been seeing has companies exposing service methods both ways - that is,
pure .NET using data sets, and also with strongly typed, cross platform
friendly interfaces. The added investment is minimal - one can facade the
code of the other, so logic doesn't need to be repeated. The benefits of
the added cross-tool, cross language, or cross platform (e.g.
windows<->mainframe, etc) of this approach is well worth the minor
technical investment.

I hope this helps

Dan Rogers
Microsoft Corporation
--------------------