Consume a dataset in unmanaged C++ client (MFC)

[geilen]

I'm trying to use a dataset returned from a web service in an unmanaged C++
(MFC) client. The dataset is returned as a BSTR, and I'm having trouble
reading the BSTR into an XML document for processing. The data looks correct
in the BSTR. Can anyone help point me in the right direction on this?

[Stuart Celarier]

> I'm trying to use a dataset returned from a web service in an unmanaged

C++
(MFC) client. The dataset is returned as a BSTR, and I'm having trouble
reading the BSTR into an XML document for processing. The data looks
correct
in the BSTR. Can anyone help point me in the right direction on this?

If you start from the premise that Web services are designed for software
integration and interoperabilit y that should be vendor, language, platform
and transport neutral, then exposing a DataSet as XML through a Web service
is not a great idea. It only works so long as both endpoints are the same
platform, namely .NET. Sure there are any number of Web services examples
that show a DataSet being sent between services endpoints, but that should
be in no way considered a best practice from a service-orientation
standpoint. You are seeing this platform disconnect, and there never will be
a good solution for consuming a DataSet from a platform that is not .NET.

Moreover, a DataSet is a pretty heavy-weight object to be passing around. It
is really designed for making a round trip with disconnected data: it
supports changing the data while it is disconnected and then reconnecting
and having data resynchronize back up. That takes a fair bit of plumbing in
the DataSet, such as encapsulating multiple tables, relationships, etc.,
providing schema for the data in the document, and maintaining diffgrams of
data as it is changed in the DataSet. All that capability comes at a price,
such as much larger SOAP messages on the wire. I think in the vast majority
of cases where DataSets are shown in Web services examples, they are not
being used to make roundtrip changes in disconnected relational data, they
are merely the container for more or less flat data in one direction. In
such situations you are much better off creating your own light-weight
business- or domain-specific objects, or, if you are using SQL Server,
executing SELECT statements with the FOR XML specification. Not only will
they result in smaller messages on the wire, they will be consumable from
platforms other than .NET.

Cheers,
Stuart Celarier, Fern Creek

[geilen]

Thank you Stuart!

I was starting to come to the same conclusion myself. I've started looking
at using an XmlDataDocument as the return type for my data. I'm not sure if
that's a better solution than using my own structures. Any thoughts? One
article I read prefererred the XmlDataDocument approach, because it used less
memory on the server...

Gordon

"Stuart Celarier" wrote:

I'm trying to use a dataset returned from a web service in an unmanaged
C++
(MFC) client. The dataset is returned as a BSTR, and I'm having trouble
reading the BSTR into an XML document for processing. The data looks
correct
in the BSTR. Can anyone help point me in the right direction on this?

If you start from the premise that Web services are designed for software
integration and interoperabilit y that should be vendor, language, platform
and transport neutral, then exposing a DataSet as XML through a Web service
is not a great idea. It only works so long as both endpoints are the same
platform, namely .NET. Sure there are any number of Web services examples
that show a DataSet being sent between services endpoints, but that should
be in no way considered a best practice from a service-orientation
standpoint. You are seeing this platform disconnect, and there never will be
a good solution for consuming a DataSet from a platform that is not .NET.

Moreover, a DataSet is a pretty heavy-weight object to be passing around. It
is really designed for making a round trip with disconnected data: it
supports changing the data while it is disconnected and then reconnecting
and having data resynchronize back up. That takes a fair bit of plumbing in
the DataSet, such as encapsulating multiple tables, relationships, etc.,
providing schema for the data in the document, and maintaining diffgrams of
data as it is changed in the DataSet. All that capability comes at a price,
such as much larger SOAP messages on the wire. I think in the vast majority
of cases where DataSets are shown in Web services examples, they are not
being used to make roundtrip changes in disconnected relational data, they
are merely the container for more or less flat data in one direction. In
such situations you are much better off creating your own light-weight
business- or domain-specific objects, or, if you are using SQL Server,
executing SELECT statements with the FOR XML specification. Not only will
they result in smaller messages on the wire, they will be consumable from
platforms other than .NET.

Cheers,
Stuart Celarier, Fern Creek

[Stuart Celarier]

Gordon wrote:

... I've started looking at using an XmlDataDocument as the return type
[of a WebMethod] for my data. I'm not sure if that's a better solution
than using my own structures. Any thoughts?
Go ahead and try to create a WebMethod that returns
System.Xml.XmlD ataDocument like this:

[WebMethod]
public XmlDataDocument GetXmlDataDocum ent()
{
return new XmlDataDocument ();
}

Compile and run. You get back this:

Server Error in '[...]' Application
Cannot serialize type System.Xml.XmlD ataDocument. Please consider using
XmlDocument, XmlElement or XmlNode instead.

So that's not very promising. : ) Let's back up and look at the
architecture. There are four different concepts that should be kept
distinct. From the backend working forwards, there is the data source (e.g.,
database), a data access layer (e.g., ADO.NET), your business entities, and
finally a service interface that exposes entity services. These are
illustrated in Figure 1 in [1]. The service interface is explored in depth
here [2].

One way to approach service interface design is referred to as
contract-first [3]. This parallels the best practice of COM components to
design the the interface first and do it in the interface language. In other
words, approach this problem from how you'd like to consume the service, not
how you intend to implement the service.

Cheers,
Stuart Celarier, Fern Creek

[1]
http://msdn.microsoft.com/library/en...redSvcsApp.asp
[2]
http://msdn.microsoft.com/library/en...eInterface.asp
[3] http://weblogs.asp.net/cweyer/archiv.../21/39070.aspx

One article I read prefererred the XmlDataDocument approach, because it used
less
memory on the server...

Gordon

"Stuart Celarier" wrote:

> I'm trying to use a dataset returned from a web service in an unmanaged
> C++
> (MFC) client. The dataset is returned as a BSTR, and I'm having
> trouble
> reading the BSTR into an XML document for processing. The data looks
> correct
> in the BSTR. Can anyone help point me in the right direction on this?

If you start from the premise that Web services are designed for software
integration and interoperabilit y that should be vendor, language,
platform
and transport neutral, then exposing a DataSet as XML through a Web
service
is not a great idea. It only works so long as both endpoints are the same
platform, namely .NET. Sure there are any number of Web services examples
that show a DataSet being sent between services endpoints, but that
should
be in no way considered a best practice from a service-orientation
standpoint. You are seeing this platform disconnect, and there never will
be
a good solution for consuming a DataSet from a platform that is not .NET.

Moreover, a DataSet is a pretty heavy-weight object to be passing around.
It
is really designed for making a round trip with disconnected data: it
supports changing the data while it is disconnected and then reconnecting
and having data resynchronize back up. That takes a fair bit of plumbing
in
the DataSet, such as encapsulating multiple tables, relationships, etc.,
providing schema for the data in the document, and maintaining diffgrams
of
data as it is changed in the DataSet. All that capability comes at a
price,
such as much larger SOAP messages on the wire. I think in the vast
majority
of cases where DataSets are shown in Web services examples, they are not
being used to make roundtrip changes in disconnected relational data,
they
are merely the container for more or less flat data in one direction. In
such situations you are much better off creating your own light-weight
business- or domain-specific objects, or, if you are using SQL Server,
executing SELECT statements with the FOR XML specification. Not only will
they result in smaller messages on the wire, they will be consumable from
platforms other than .NET.

Cheers,
Stuart Celarier, Fern Creek

[geilen]

Stuart,

Sorry it has taken so long for me to respond. I vey much appreciate your
thoughtful response. You've given me a lot of useful information to digest.
Now, I've got a lot of work to do!

Gordon

"Stuart Celarier" wrote:

Gordon wrote:

... I've started looking at using an XmlDataDocument as the return type
[of a WebMethod] for my data. I'm not sure if that's a better solution
than using my own structures. Any thoughts?

Go ahead and try to create a WebMethod that returns
System.Xml.XmlD ataDocument like this:

[WebMethod]
public XmlDataDocument GetXmlDataDocum ent()
{
return new XmlDataDocument ();
}

Compile and run. You get back this:

Server Error in '[...]' Application
Cannot serialize type System.Xml.XmlD ataDocument. Please consider using
XmlDocument, XmlElement or XmlNode instead.

So that's not very promising. : ) Let's back up and look at the
architecture. There are four different concepts that should be kept
distinct. From the backend working forwards, there is the data source (e.g.,
database), a data access layer (e.g., ADO.NET), your business entities, and
finally a service interface that exposes entity services. These are
illustrated in Figure 1 in [1]. The service interface is explored in depth
here [2].

One way to approach service interface design is referred to as
contract-first [3]. This parallels the best practice of COM components to
design the the interface first and do it in the interface language. In other
words, approach this problem from how you'd like to consume the service, not
how you intend to implement the service.

Cheers,
Stuart Celarier, Fern Creek

[1]
http://msdn.microsoft.com/library/en...redSvcsApp.asp
[2]
http://msdn.microsoft.com/library/en...eInterface.asp
[3] http://weblogs.asp.net/cweyer/archiv.../21/39070.aspx

One

article I read prefererred the XmlDataDocument approach, because it used
less
memory on the server...

Gordon

"Stuart Celarier" wrote:

> I'm trying to use a dataset returned from a web service in an unmanaged
> C++
> (MFC) client. The dataset is returned as a BSTR, and I'm having
> trouble
> reading the BSTR into an XML document for processing. The data looks
> correct
> in the BSTR. Can anyone help point me in the right direction on this?

If you start from the premise that Web services are designed for software
integration and interoperabilit y that should be vendor, language,
platform
and transport neutral, then exposing a DataSet as XML through a Web
service
is not a great idea. It only works so long as both endpoints are the same
platform, namely .NET. Sure there are any number of Web services examples
that show a DataSet being sent between services endpoints, but that
should
be in no way considered a best practice from a service-orientation
standpoint. You are seeing this platform disconnect, and there never will
be
a good solution for consuming a DataSet from a platform that is not .NET.

Moreover, a DataSet is a pretty heavy-weight object to be passing around.
It
is really designed for making a round trip with disconnected data: it
supports changing the data while it is disconnected and then reconnecting
and having data resynchronize back up. That takes a fair bit of plumbing
in
the DataSet, such as encapsulating multiple tables, relationships, etc.,
providing schema for the data in the document, and maintaining diffgrams
of
data as it is changed in the DataSet. All that capability comes at a
price,
such as much larger SOAP messages on the wire. I think in the vast
majority
of cases where DataSets are shown in Web services examples, they are not
being used to make roundtrip changes in disconnected relational data,
they
are merely the container for more or less flat data in one direction. In
such situations you are much better off creating your own light-weight
business- or domain-specific objects, or, if you are using SQL Server,
executing SELECT statements with the FOR XML specification. Not only will
they result in smaller messages on the wire, they will be consumable from
platforms other than .NET.

Cheers,
Stuart Celarier, Fern Creek