Returning Dataset or Datatable via Web Service

[Joseph Geretz]

I'm a bit puzzled by the current recommendation not to send Datasets or
Datatables between application tiers.

http://support.microsoft.com/kb/306134

http://msdn2.microsoft.com/en-us/library/ms996381.aspx

Formerly, with classic Microsoft DNA architecture, the ADO Recordset was a
primary transport medium, recommended for transmitting data between
application tiers. In fact, there are whole books written on the subject.

So, I'm a bit puzzled why this hasn't been carried forward into ADO.NET. In
any case, what then is the recommended alternative? Manually serialize and
pass the XML? So why can't this happen automatically for us, just as was the
case with classic ADO recordsets?

Thanks for your advice?

- Joseph Geretz -

[=?Utf-8?B?TWFyayBOZWxzb24=?=]

Joseph Geretz,

The error message mentioned in the microsoft site is for a different cause.
You can pass DataSet / DataTable back & forth between web service.
The DataSet / DataTable serialization is supported in ADO.NET 2.0.
I'm not finding any restriction to use theam

--
Thanks & Regards,
Mark Nelson
"Joseph Geretz" wrote:

I'm a bit puzzled by the current recommendation not to send Datasets or
Datatables between application tiers.

http://support.microsoft.com/kb/306134

http://msdn2.microsoft.com/en-us/library/ms996381.aspx

Formerly, with classic Microsoft DNA architecture, the ADO Recordset was a
primary transport medium, recommended for transmitting data between
application tiers. In fact, there are whole books written on the subject.

So, I'm a bit puzzled why this hasn't been carried forward into ADO.NET. In
any case, what then is the recommended alternative? Manually serialize and
pass the XML? So why can't this happen automatically for us, just as was the
case with classic ADO recordsets?

Thanks for your advice?

- Joseph Geretz -

[Joseph Geretz]

Hi Mark,

I didn't say it wouldn't work. It does work. But it's not recommended:

http://msdn2.microsoft.com/en-us/lib...emotes_topic11

Avoid passing DataSets between services

In our tests, choosing the way the services and callers exchange data-as
DataSets or serialized structures-resulted in a much bigger performance
impact than choosing any particular distributed systems technology over
another.

From a performance perspective, we strongly urge you to limit your use of
DataSets as a data transfer mechanism to the parts of your application where
they are truly needed and that you opt for [Serializable] structures
wherever possible.

ADO.NET DataSets provide a great way to retrieve, manipulate, sort, and
shape data, store it locally for offline use, and synchronize changes back
into a central database. If this is a requirement of your application, then
of course, it's a valid choice to make. In the .NET Framework 1.x, DataSet
values are always serialized to XML (even if you state that you want them
serialized as binary or use them with ES or Remoting), and they also contain
the XSD describing the data. This, of course, impacts performance.

What's more, remember that DataSets are a .NET-specific technology and will
significantly limit your interoperability as other platforms won't
necessarily be able to serialize and parse data containing serialized
DataSets.

You can gain considerable performance improvements by instead exchanging
serialized data structures. The built-in runtime formatting and XML
serialization framework makes it easy, as shown in the tests above.

- Joe Geretz -

"Mark Nelson" <Ma********@discussions.microsoft.comwrote in message
news:4F**********************************@microsof t.com...

Joseph Geretz,

The error message mentioned in the microsoft site is for a different
cause.
You can pass DataSet / DataTable back & forth between web service.
The DataSet / DataTable serialization is supported in ADO.NET 2.0.
I'm not finding any restriction to use theam

--
Thanks & Regards,
Mark Nelson
"Joseph Geretz" wrote:

>I'm a bit puzzled by the current recommendation not to send Datasets or
Datatables between application tiers.

http://support.microsoft.com/kb/306134

http://msdn2.microsoft.com/en-us/library/ms996381.aspx

Formerly, with classic Microsoft DNA architecture, the ADO Recordset was
a
primary transport medium, recommended for transmitting data between
application tiers. In fact, there are whole books written on the subject.

So, I'm a bit puzzled why this hasn't been carried forward into ADO.NET.
In
any case, what then is the recommended alternative? Manually serialize
and
pass the XML? So why can't this happen automatically for us, just as was
the
case with classic ADO recordsets?

Thanks for your advice?

- Joseph Geretz -

[John Saunders]

"Joseph Geretz" <jg*****@nospam.comwrote in message
news:OY**************@TK2MSFTNGP04.phx.gbl...

I'm a bit puzzled by the current recommendation not to send Datasets or
Datatables between application tiers.

Joseph, have you decided that your web service will only be consumed by .NET
clients, ever?

If you want to be able to take advantage of the cross-platform benefits
offered by XML Web Services, then you should stop thinking about exposing
classes and DataSets and DataTables. Instead, think about exposing XML.

John

[Joseph Geretz]

Isn't everything fundamentally serialized as XML anyway?

So the recommendation is basically to get a DataSet/Table on the server,
manually serialize to XML, receive it on the client, and then do whatever
you want with it, including de-persisting the XML into a DataSet/Table if
the client is so inclined?

But my fundamental question still exists: Regardless of how I define the
data, the response is going to come back as XML won't it? So why would a non
..NET client have more difficulty dealing with the DataSet/Table XML as
opposed to my own explicitly defined XML?

- Joseph Geretz -

"John Saunders" <john.saunders at trizetto.comwrote in message
news:uX**************@TK2MSFTNGP04.phx.gbl...

"Joseph Geretz" <jg*****@nospam.comwrote in message
news:OY**************@TK2MSFTNGP04.phx.gbl...

>I'm a bit puzzled by the current recommendation not to send Datasets or
Datatables between application tiers.

Joseph, have you decided that your web service will only be consumed by
.NET clients, ever?

If you want to be able to take advantage of the cross-platform benefits
offered by XML Web Services, then you should stop thinking about exposing
classes and DataSets and DataTables. Instead, think about exposing XML.

John

[John Saunders]

"Joseph Geretz" <jg*****@nospam.comwrote in message
news:uQ**************@TK2MSFTNGP06.phx.gbl...

Isn't everything fundamentally serialized as XML anyway?

So the recommendation is basically to get a DataSet/Table on the server,
manually serialize to XML, receive it on the client, and then do whatever
you want with it, including de-persisting the XML into a DataSet/Table if
the client is so inclined?

But my fundamental question still exists: Regardless of how I define the
data, the response is going to come back as XML won't it? So why would a
non .NET client have more difficulty dealing with the DataSet/Table XML as
opposed to my own explicitly defined XML?

Joseph,

This will become a lot clearer once you've had more experience with XML. We
all go through the stage you're in - thinking about XML as being just a text
format. It's grown way beyond that, and a lot of its power comes from this
growth.

One thing that's newly-enabled by XML is that the client of your web service
may be running on a platform you've never heard of. Because both sides are
adhering to standards, you won't actually need to know what kind of client
is consuming your service. This is possible, in part, because the metadata
of your service is described in WSDL and XML Schema, both of which are XML
languages.

Now, one aspect of the fact that you can't know who your client is, is the
fact that you can't know that they will be able to process a DataSet in any
sensible way. So, don't send them a DataSet.

Perhaps more importantly, a DataSet is a server-side, implementation-level
object. The communication between the client and server should be in terms
of the business-level concepts, not in terms of how the server happened to
implement the service.

I don't know of many businesses for which "DataSet" is a business-level
concept.

You should ideally start with the business-level concept, manually create an
XML Schema to describe it, manually create a WSDL file which will describe
the possible interactions with the service in terms of the schema, and only
_then_ go implement a service which may implement these concepts and
operations in terms of DataSets.

That way, you are in control of the contract - the promises made to your
client by your WSDL file.

John

[Joseph Geretz]

Hi John,

You should ideally start with the business-level concept, manually create
an XML Schema to describe it, manually create a WSDL file which will
describe the possible interactions with the service in terms of the
schema, and only _then_ go implement a service which may implement these
concepts and operations in terms of DataSets.

I hear what you are saying, but I'm wondering why you're saying it in a
dotnet.framework.webservices forum. The activities you describe, that is the
hand tuning of the XML schema and the WSDL file are specifically those
activities which are *not* necessary for .NET developers. We use a more RAD
approach, basically relying on the IDE to perform this for us behind the
scenes.

The application I am currently devleoping would have two target audiences.

1. Our own client application. Our developed solution would be implemented
end-to-end using Microsoft .NET technologies using the aforementioned RAD
approach.

2. Other vendors in our application market space who might want to integrate
with our application. Web Services would facilitate this type of
integration. Certain vendors might or might not be on the .NET platform
themselves. For those who are, terrific for them, they'll be able to consume
our web services quite naturally with the convenience of being able to
access tabular data in a very convenient format. Those who aren't should
still be able to consume our Web Services, however they'll have to manually
parse through tabular data themselves without the convenience of the
DataTable/DataSet structure since their environments won't provide the
convenience of an object representation of the DataTable/Set XML.

I don't know of many businesses for which "DataSet" is a business-level
concept.

The DataSet/Table isn't a business level concept, however a large amount of
business level data can be represented quite conveniently in DataSet/Table
format. With focus on devleopment convenience (RAD) for our own application
developers, I need a more compelling reason to eschew DataSet/Tables than
simply the fact that it will disadvantage other non .NET consumers of our
Web Service. If it will make it impossible for them to consume our Web
Services, that would be a different matter. But I'm not hearing that it
would be impossible for them, just marginally more inconvenient.

Am I missing anything?

Thanks,

- Joseph Geretz -

"John Saunders" <john.saunders at trizetto.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

"Joseph Geretz" <jg*****@nospam.comwrote in message
news:uQ**************@TK2MSFTNGP06.phx.gbl...

>Isn't everything fundamentally serialized as XML anyway?

So the recommendation is basically to get a DataSet/Table on the server,
manually serialize to XML, receive it on the client, and then do whatever
you want with it, including de-persisting the XML into a DataSet/Table if
the client is so inclined?

But my fundamental question still exists: Regardless of how I define the
data, the response is going to come back as XML won't it? So why would a
non .NET client have more difficulty dealing with the DataSet/Table XML
as opposed to my own explicitly defined XML?

Joseph,

This will become a lot clearer once you've had more experience with XML.
We all go through the stage you're in - thinking about XML as being just a
text format. It's grown way beyond that, and a lot of its power comes from
this growth.

One thing that's newly-enabled by XML is that the client of your web
service may be running on a platform you've never heard of. Because both
sides are adhering to standards, you won't actually need to know what kind
of client is consuming your service. This is possible, in part, because
the metadata of your service is described in WSDL and XML Schema, both of
which are XML languages.

Now, one aspect of the fact that you can't know who your client is, is the
fact that you can't know that they will be able to process a DataSet in
any sensible way. So, don't send them a DataSet.

Perhaps more importantly, a DataSet is a server-side, implementation-level
object. The communication between the client and server should be in terms
of the business-level concepts, not in terms of how the server happened to
implement the service.

I don't know of many businesses for which "DataSet" is a business-level
concept.

You should ideally start with the business-level concept, manually create
an XML Schema to describe it, manually create a WSDL file which will
describe the possible interactions with the service in terms of the
schema, and only _then_ go implement a service which may implement these
concepts and operations in terms of DataSets.

That way, you are in control of the contract - the promises made to your
client by your WSDL file.

John

[John Saunders]

"Joseph Geretz" <jg*****@nospam.comwrote in message
news:uX**************@TK2MSFTNGP05.phx.gbl...

Hi John,

>You should ideally start with the business-level concept, manually create
an XML Schema to describe it, manually create a WSDL file which will
describe the possible interactions with the service in terms of the
schema, and only _then_ go implement a service which may implement these
concepts and operations in terms of DataSets.

I hear what you are saying, but I'm wondering why you're saying it in a
dotnet.framework.webservices forum. The activities you describe, that is
the hand tuning of the XML schema and the WSDL file are specifically those
activities which are *not* necessary for .NET developers. We use a more
RAD approach, basically relying on the IDE to perform this for us behind
the scenes.

Sorry, you're mistaken. .NET does not equate to RAD, esepecially not for web
services. I practiced what I preached on one web service and am about to do
so again on at least one more. This is called contract-first development.

The application I am currently devleoping would have two target audiences.

1. Our own client application. Our developed solution would be implemented
end-to-end using Microsoft .NET technologies using the aforementioned RAD
approach.

It's not a problem if you want to tie yourself to .NET. That works very
well, until the point when you decide you need to work with something that's
not .NET.

2. Other vendors in our application market space who might want to
integrate with our application. Web Services would facilitate this type of
integration. Certain vendors might or might not be on the .NET platform
themselves. For those who are, terrific for them, they'll be able to
consume our web services quite naturally with the convenience of being
able to access tabular data in a very convenient format. Those who aren't
should still be able to consume our Web Services, however they'll have to
manually parse through tabular data themselves without the convenience of
the DataTable/DataSet structure since their environments won't provide the
convenience of an object representation of the DataTable/Set XML.

What's wrong with defining your tabular data with a schema, without relying
on a DataSet?

And, you may find some market resistance if you are asking partners to parse
through your XML.

>I don't know of many businesses for which "DataSet" is a business-level
concept.

The DataSet/Table isn't a business level concept, however a large amount
of business level data can be represented quite conveniently in
DataSet/Table format. With focus on devleopment convenience (RAD) for our
own application developers, I need a more compelling reason to eschew
DataSet/Tables than simply the fact that it will disadvantage other non
.NET consumers of our Web Service. If it will make it impossible for them
to consume our Web Services, that would be a different matter. But I'm not
hearing that it would be impossible for them, just marginally more
inconvenient.

Am I missing anything?

Have you tried strongly-typed datasets? They're nice and RAD, but they at
least define the data via XML Schema. You get to benefit from RAD, your
customers benefit from a strong schema.

John
BTW, I presume you realize that you need to be careful when changing the
structure of the data you're returning? Once you've published the WSDL, you
shouldn't really be changing the structure of the returned data, at least
not without a versioning mechanism. Again, you may get away with things like
adding columns with some clients, but maybe not with others.

[Joseph Geretz]

Hi John,

Sorry, you're mistaken. .NET does not equate to RAD, esepecially not for
web services.

I (and some other developers on the team here) don't quite understand what
you are saying. When using Visual Studio 2005 for Web Service application
development, the IDE takes care of all the wire-up necessary in order to
connect the client with the Web Service. This includes creating the WSDL on
the server and creating the proxy class for the client which consumes the
WSDL and presents a strongly typed interface to the client. Seems pretty RAD
to us.

What's wrong with defining your tabular data with a schema, without
relying on a DataSet?

There's nothing wrong with it, in general. However consider the context in
particular. The data is retrieved from the database in DataTable format. At
the (our) UI it's going to be bound to a data-bound widget (very convenient,
for us at least) in DataTable format. Given that this is the case, I'm going
to need a compelling reason to persist this into a secondary XML format, and
then to convert it back from secondary XML format into a DataTable at the
UI. And to do this again, when modified data is sent back to the server.
It'll cut down development expense significantly to just leave this in its
native format and to let the Framework take care of everything for us.

And, you may find some market resistance if you are asking partners to
parse through your XML.

But if we sent back a list of information (as opposed to scalar data item or
items) in XML format, that's exactly what the consumer would need to do in
order to process each row. This is unavoidable for any service which returns
a list or array of data. So why would our own hand-coded XML list
representation be more convenient than the native DataSet XML
representation? Tabular data representation is tabular data representation.
What's the difference whose XML format it is encoded in?

Have you tried strongly-typed datasets? They're nice and RAD, but they at
least define the data via XML Schema. You get to benefit from RAD, your
customers benefit from a strong schema.

Excellent suggestion, I will look into this - thanks!

BTW, I presume you realize that you need to be careful when changing the
structure of the data you're returning?

Remember, you're talking to an ex-COM (hey, I like that term - you heard it
here first! ;-). Keeping an interface constant (or should I say coMstant?)
is second nature to guys like me!

At the end of the day, the vast majority of our Web Services are going to be
consumed by our own application. In this context, RAD development is of
benefit to us. We can always see our way going forward to provide alternate
service methods which could be consumed by eventual partners. Even if our
own in-house services aren't suitable, having the application engineered on
the Web Services platform is going to give us a tremendous boost when it
comes to providing services to even non-.NET clients.

Thanks for your advice,

- Joseph Geretz -

"John Saunders" <john.saunders at trizetto.comwrote in message
news:eA**************@TK2MSFTNGP06.phx.gbl...

"Joseph Geretz" <jg*****@nospam.comwrote in message
news:uX**************@TK2MSFTNGP05.phx.gbl...

>Hi John,

>>You should ideally start with the business-level concept, manually
create an XML Schema to describe it, manually create a WSDL file which
will describe the possible interactions with the service in terms of the
schema, and only _then_ go implement a service which may implement these
concepts and operations in terms of DataSets.

I hear what you are saying, but I'm wondering why you're saying it in a
dotnet.framework.webservices forum. The activities you describe, that is
the hand tuning of the XML schema and the WSDL file are specifically
those activities which are *not* necessary for .NET developers. We use a
more RAD approach, basically relying on the IDE to perform this for us
behind the scenes.

Sorry, you're mistaken. .NET does not equate to RAD, esepecially not for
web services. I practiced what I preached on one web service and am about
to do so again on at least one more. This is called contract-first
development.

>The application I am currently devleoping would have two target
audiences.

1. Our own client application. Our developed solution would be
implemented end-to-end using Microsoft .NET technologies using the
aforementioned RAD approach.

It's not a problem if you want to tie yourself to .NET. That works very
well, until the point when you decide you need to work with something
that's not .NET.

>2. Other vendors in our application market space who might want to
integrate with our application. Web Services would facilitate this type
of integration. Certain vendors might or might not be on the .NET
platform themselves. For those who are, terrific for them, they'll be
able to consume our web services quite naturally with the convenience of
being able to access tabular data in a very convenient format. Those who
aren't should still be able to consume our Web Services, however they'll
have to manually parse through tabular data themselves without the
convenience of the DataTable/DataSet structure since their environments
won't provide the convenience of an object representation of the
DataTable/Set XML.

What's wrong with defining your tabular data with a schema, without
relying on a DataSet?

And, you may find some market resistance if you are asking partners to
parse through your XML.

>>I don't know of many businesses for which "DataSet" is a business-level
concept.

The DataSet/Table isn't a business level concept, however a large amount
of business level data can be represented quite conveniently in
DataSet/Table format. With focus on devleopment convenience (RAD) for our
own application developers, I need a more compelling reason to eschew
DataSet/Tables than simply the fact that it will disadvantage other non
.NET consumers of our Web Service. If it will make it impossible for them
to consume our Web Services, that would be a different matter. But I'm
not hearing that it would be impossible for them, just marginally more
inconvenient.

Am I missing anything?

Have you tried strongly-typed datasets? They're nice and RAD, but they at
least define the data via XML Schema. You get to benefit from RAD, your
customers benefit from a strong schema.

John
BTW, I presume you realize that you need to be careful when changing the
structure of the data you're returning? Once you've published the WSDL,
you shouldn't really be changing the structure of the returned data, at
least not without a versioning mechanism. Again, you may get away with
things like adding columns with some clients, but maybe not with others.

[John Saunders]

"Joseph Geretz" <jg*****@nospam.comwrote in message
news:Oc**************@TK2MSFTNGP04.phx.gbl...

Hi John,

>Sorry, you're mistaken. .NET does not equate to RAD, esepecially not for
web services.

I (and some other developers on the team here) don't quite understand what
you are saying. When using Visual Studio 2005 for Web Service application
development, the IDE takes care of all the wire-up necessary in order to
connect the client with the Web Service. This includes creating the WSDL
on the server and creating the proxy class for the client which consumes
the WSDL and presents a strongly typed interface to the client. Seems
pretty RAD to us.

Microsoft has sold you a bicycle with training wheels on it. Those wheels
are not welded on. Take them off.

When Microsoft first introduced .NET, Web Services were a large part of the
marketing message. In order to encourage developers to jump onto the Web
Services bandwagon, Microsoft did a number of things which I believe were
not good ideas in the long run. They introduced a way to create a web
service that screen-scrapes HTML, for instance. This is a very bad way to
create an application, but makes perfect sense back in 2001, when it was a
useful way to get developers to start using .NET.

Similarly, they introduced the ability to "magically" create web services
simply by putting a [WebMethod] attribute on the public methods to be
exposed. "Look how easy it is!", they said.

But this is not a best practice, and it leads to many of the mistakes that
you and others are making. It is only because of the "magic" going on behind
the scenes that newcomers like yourself can actually ask about how to make
the client use the same class as the server. The question actually makes no
sense at all, but because you're using the training wheels, and thinking
that's how bicycles are made, you have the illusion that the two classes
should be the same and that there's simply some setting you need to change
to make them be the same.

I have similarly heard of a developer who, when he couldn't add a web
reference via http://somewhere/something.asmx?WSDL complained that the
service didn't work, and that there was a connectivity problem. There
wasn't. The "documentation" protocol was deliberately disabled. He thought
that "?WSDL" was some standard.

BTW, the client absolutely does _not_ get a strongly-typed interface! The
interface exposed by the server is interpreted by .NET to produce a WSDL
file which the client interprets to produce proxy classes unrelated to the
original classes. If you want strongly-typed, you should use .NET Remoting,
or WCF. The proxy classes are only a convenience.

>What's wrong with defining your tabular data with a schema, without
relying on a DataSet?

There's nothing wrong with it, in general. However consider the context in
particular. The data is retrieved from the database in DataTable format.

That is an implementation detail. What happens when your implementation
changes?

At the (our) UI it's going to be bound to a data-bound widget (very
convenient, for us at least) in DataTable format.

Again, an implementation detail. Your widget will no doubt like you just as
well if you bind it to a custom object exposing strongly-typed properties.
Data binding is not unique to DataTables and DataSets.

Given that this is the case, I'm going to need a compelling reason to
persist this into a secondary XML format, and then to convert it back from
secondary XML format into a DataTable at the UI. And to do this again,
when modified data is sent back to the server. It'll cut down development
expense significantly to just leave this in its native format and to let
the Framework take care of everything for us.

Absolutely. And you will be tied to the framework. If that's part of your
requirement, then you're all set. Many people developing Web Services are
interested in at least the possibility that some client other than .NET will
use their service.

>And, you may find some market resistance if you are asking partners to
parse through your XML.

But if we sent back a list of information (as opposed to scalar data item
or items) in XML format, that's exactly what the consumer would need to do
in order to process each row.

Absolutely not! Why would they need to do any parsing if you've given them a
schema? They'll no doubt do the same thing that you would do - run their
equivalent of XSD.EXE to produce classes from the schema! No parsing
(manual) required.

>This is unavoidable for any service which returns a list or array of data.
So why would our own hand-coded XML list representation be more convenient
than the native DataSet XML representation? Tabular data representation is
tabular data representation. What's the difference whose XML format it is
encoded in?

>Have you tried strongly-typed datasets? They're nice and RAD, but they at
least define the data via XML Schema. You get to benefit from RAD, your
customers benefit from a strong schema.

Excellent suggestion, I will look into this - thanks!

>BTW, I presume you realize that you need to be careful when changing the
structure of the data you're returning?

Remember, you're talking to an ex-COM (hey, I like that term - you heard
it here first! ;-). Keeping an interface constant (or should I say
coMstant?) is second nature to guys like me!

That's what I thought. I'd just point out to you, that the namespace is
somewhat equivalent to the IID - if you change the interface, you need to
change the namespace.

At the end of the day, the vast majority of our Web Services are going to
be consumed by our own application. In this context, RAD development is of
benefit to us. We can always see our way going forward to provide
alternate service methods which could be consumed by eventual partners.
Even if our own in-house services aren't suitable, having the application
engineered on the Web Services platform is going to give us a tremendous
boost when it comes to providing services to even non-.NET clients.

Just keep in mind that the web services platform doesn't include the
training wheels. In fact, you'll find that the aftermarket assumes you've
taken the training wheels off!
John

[Joseph Geretz]

Hi John,

A lot of what you are saying makes sense. It's the same philosophy which has
led many of my fellow VB6 developers toward exploration of Windows
internals. It's useful to have this knowledge for application when
necessary; But by no means have we discarded VB6 in favor of Visual C++ and
MFC for Windows application development.

Microsoft has sold you a bicycle with training wheels on it. Those wheels
are not welded on. Take them off.

Basically, what you see as 'training wheels' I (and others I am sure, as
well) see as valuable aids toward rapid application development.

you and others are making. It is only because of the "magic" going on
behind the scenes that newcomers like yourself can actually ask about how
to make the client use the same class as the server. The question actually
makes no sense at all, but because you're using the training wheels, and
thinking that's how bicycles are made, you have the illusion that the two
classes should be the same and that there's simply some setting you need
to change to make them be the same.

Although, to be sure I am not averse to 'taking off the training wheels when
necessary'. I am assuming that you allude to my advice to Josh in his topic
'Sharing web-service class between two local assemblies'? Please take a look
at my latest reply, where I demonstrate that, contrary to your assertion,
this is indeed possible with just a bit of simple hand-tuning of the
'magically' generated proxy class. As you can see, I am not averse to
'taking off the training wheels' when necessary.

Newcomers like myself? (shrug - whatever...)

- Joseph Geretz -

"John Saunders" <john.saunders at trizetto.comwrote in message
news:up**************@TK2MSFTNGP06.phx.gbl...

"Joseph Geretz" <jg*****@nospam.comwrote in message
news:Oc**************@TK2MSFTNGP04.phx.gbl...

>Hi John,

>>Sorry, you're mistaken. .NET does not equate to RAD, esepecially not for
web services.

I (and some other developers on the team here) don't quite understand
what you are saying. When using Visual Studio 2005 for Web Service
application development, the IDE takes care of all the wire-up necessary
in order to connect the client with the Web Service. This includes
creating the WSDL on the server and creating the proxy class for the
client which consumes the WSDL and presents a strongly typed interface to
the client. Seems pretty RAD to us.

Microsoft has sold you a bicycle with training wheels on it. Those wheels
are not welded on. Take them off.

When Microsoft first introduced .NET, Web Services were a large part of
the marketing message. In order to encourage developers to jump onto the
Web Services bandwagon, Microsoft did a number of things which I believe
were not good ideas in the long run. They introduced a way to create a web
service that screen-scrapes HTML, for instance. This is a very bad way to
create an application, but makes perfect sense back in 2001, when it was a
useful way to get developers to start using .NET.

Similarly, they introduced the ability to "magically" create web services
simply by putting a [WebMethod] attribute on the public methods to be
exposed. "Look how easy it is!", they said.

But this is not a best practice, and it leads to many of the mistakes that
you and others are making. It is only because of the "magic" going on
behind the scenes that newcomers like yourself can actually ask about how
to make the client use the same class as the server. The question actually
makes no sense at all, but because you're using the training wheels, and
thinking that's how bicycles are made, you have the illusion that the two
classes should be the same and that there's simply some setting you need
to change to make them be the same.

I have similarly heard of a developer who, when he couldn't add a web
reference via http://somewhere/something.asmx?WSDL complained that the
service didn't work, and that there was a connectivity problem. There
wasn't. The "documentation" protocol was deliberately disabled. He thought
that "?WSDL" was some standard.

BTW, the client absolutely does _not_ get a strongly-typed interface! The
interface exposed by the server is interpreted by .NET to produce a WSDL
file which the client interprets to produce proxy classes unrelated to the
original classes. If you want strongly-typed, you should use .NET
Remoting, or WCF. The proxy classes are only a convenience.

>>What's wrong with defining your tabular data with a schema, without
relying on a DataSet?

There's nothing wrong with it, in general. However consider the context
in particular. The data is retrieved from the database in DataTable
format.

That is an implementation detail. What happens when your implementation
changes?

>At the (our) UI it's going to be bound to a data-bound widget (very
convenient, for us at least) in DataTable format.

Again, an implementation detail. Your widget will no doubt like you just
as well if you bind it to a custom object exposing strongly-typed
properties. Data binding is not unique to DataTables and DataSets.

>Given that this is the case, I'm going to need a compelling reason to
persist this into a secondary XML format, and then to convert it back
from secondary XML format into a DataTable at the UI. And to do this
again, when modified data is sent back to the server. It'll cut down
development expense significantly to just leave this in its native format
and to let the Framework take care of everything for us.

Absolutely. And you will be tied to the framework. If that's part of your
requirement, then you're all set. Many people developing Web Services are
interested in at least the possibility that some client other than .NET
will use their service.

>>And, you may find some market resistance if you are asking partners to
parse through your XML.

But if we sent back a list of information (as opposed to scalar data item
or items) in XML format, that's exactly what the consumer would need to
do in order to process each row.

Absolutely not! Why would they need to do any parsing if you've given them
a schema? They'll no doubt do the same thing that you would do - run their
equivalent of XSD.EXE to produce classes from the schema! No parsing
(manual) required.

>>This is unavoidable for any service which returns a list or array of data.
So why would our own hand-coded XML list representation be more convenient
than the native DataSet XML representation? Tabular data representation is
tabular data representation. What's the difference whose XML format it is
encoded in?

>>Have you tried strongly-typed datasets? They're nice and RAD, but they
at least define the data via XML Schema. You get to benefit from RAD,
your customers benefit from a strong schema.

Excellent suggestion, I will look into this - thanks!

>>BTW, I presume you realize that you need to be careful when changing the
structure of the data you're returning?

Remember, you're talking to an ex-COM (hey, I like that term - you heard
it here first! ;-). Keeping an interface constant (or should I say
coMstant?) is second nature to guys like me!

That's what I thought. I'd just point out to you, that the namespace is
somewhat equivalent to the IID - if you change the interface, you need to
change the namespace.

>At the end of the day, the vast majority of our Web Services are going to
be consumed by our own application. In this context, RAD development is
of benefit to us. We can always see our way going forward to provide
alternate service methods which could be consumed by eventual partners.
Even if our own in-house services aren't suitable, having the application
engineered on the Web Services platform is going to give us a tremendous
boost when it comes to providing services to even non-.NET clients.

Just keep in mind that the web services platform doesn't include the
training wheels. In fact, you'll find that the aftermarket assumes you've
taken the training wheels off!
John

[John Saunders]

"Joseph Geretz" <jg*****@nospam.comwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...

Hi John,

A lot of what you are saying makes sense. It's the same philosophy which
has led many of my fellow VB6 developers toward exploration of Windows
internals. It's useful to have this knowledge for application when
necessary; But by no means have we discarded VB6 in favor of Visual C++
and MFC for Windows application development.

>Microsoft has sold you a bicycle with training wheels on it. Those wheels
are not welded on. Take them off.

Basically, what you see as 'training wheels' I (and others I am sure, as
well) see as valuable aids toward rapid application development.

>you and others are making. It is only because of the "magic" going on
behind the scenes that newcomers like yourself can actually ask about how
to make the client use the same class as the server. The question
actually makes no sense at all, but because you're using the training
wheels, and thinking that's how bicycles are made, you have the illusion
that the two classes should be the same and that there's simply some
setting you need to change to make them be the same.

Although, to be sure I am not averse to 'taking off the training wheels
when necessary'. I am assuming that you allude to my advice to Josh in his
topic
'Sharing web-service class between two local assemblies'? Please take a
look at my latest reply, where I demonstrate that, contrary to your
assertion, this is indeed possible with just a bit of simple hand-tuning
of the 'magically' generated proxy class. As you can see, I am not averse
to 'taking off the training wheels' when necessary.

Newcomers like myself? (shrug - whatever...)

Joseph, as I replied in that thread, you've just given some very bad advice.
The edited proxy class will be destroyed as soon as an Update Web Reference
is done, if not before.

John

[John Saunders]

"Joseph Geretz" <jg*****@nospam.comwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...

Hi John,
Newcomers like myself? (shrug - whatever...)

BTW, I meant newcomers to .NET. You obviously have a lot of experience in
VB6 and COM, and I'm afraid it's not serving you well.

John

[Joseph Geretz]

The edited proxy class will be destroyed as soon as an Update Web

Reference is done, if not before.

And I've responded in place. Of course, this is the obvious caveat. The
proposed solution requires direct involvement in the construction of the
proxy whenever the proxy is created; that is, during initial reference and
any subsequent update of the reference. Implementing this solution requires
that one unbolt the 'training wheels'. In general, this is an approach which
you favor, no?

Joseph, as I replied in that thread, you've just given some very bad
advice.

What I did was present the facts, not simply make unsubstantiated
assertions. I will allow others to choose, depending upon their particular
circumstances, whether or not this can be implemented successfully for them.

- Joseph Geretz -

"John Saunders" <john.saunders at trizetto.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

"Joseph Geretz" <jg*****@nospam.comwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...

>Hi John,

A lot of what you are saying makes sense. It's the same philosophy which
has led many of my fellow VB6 developers toward exploration of Windows
internals. It's useful to have this knowledge for application when
necessary; But by no means have we discarded VB6 in favor of Visual C++
and MFC for Windows application development.

>>Microsoft has sold you a bicycle with training wheels on it. Those
wheels are not welded on. Take them off.

Basically, what you see as 'training wheels' I (and others I am sure, as
well) see as valuable aids toward rapid application development.

>>you and others are making. It is only because of the "magic" going on
behind the scenes that newcomers like yourself can actually ask about
how to make the client use the same class as the server. The question
actually makes no sense at all, but because you're using the training
wheels, and thinking that's how bicycles are made, you have the illusion
that the two classes should be the same and that there's simply some
setting you need to change to make them be the same.

Although, to be sure I am not averse to 'taking off the training wheels
when necessary'. I am assuming that you allude to my advice to Josh in
his topic
'Sharing web-service class between two local assemblies'? Please take a
look at my latest reply, where I demonstrate that, contrary to your
assertion, this is indeed possible with just a bit of simple hand-tuning
of the 'magically' generated proxy class. As you can see, I am not averse
to 'taking off the training wheels' when necessary.

Newcomers like myself? (shrug - whatever...)

Joseph, as I replied in that thread, you've just given some very bad
advice. The edited proxy class will be destroyed as soon as an Update Web
Reference is done, if not before.

John

[Joseph Geretz]

BTW, I meant newcomers to .NET. You obviously have a lot of experience in

VB6 and COM, and I'm afraid it's not serving you well.

When faced with a set of inconvenient facts and ideas, the last refuge is
always an attempt to discredit their presenter.

Thanks John, for demonstrating that for us.

- Joseph Geretz -

"John Saunders" <john.saunders at trizetto.comwrote in message
news:OQ**************@TK2MSFTNGP05.phx.gbl...

"Joseph Geretz" <jg*****@nospam.comwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...

>Hi John,
Newcomers like myself? (shrug - whatever...)

BTW, I meant newcomers to .NET. You obviously have a lot of experience in
VB6 and COM, and I'm afraid it's not serving you well.

John

[John Saunders]

"Joseph Geretz" <jg*****@nospam.comwrote in message
news:eL**************@TK2MSFTNGP03.phx.gbl...

>BTW, I meant newcomers to .NET. You obviously have a lot of experience in
VB6 and COM, and I'm afraid it's not serving you well.

When faced with a set of inconvenient facts and ideas, the last refuge is
always an attempt to discredit their presenter.

How is thiis an attempt to discredit you? I just got through praising your
experience!

I have experience in both sets of technology, and can see from your posts
over the past few weeks that you are attempting to apply your experience in
COM to the problem at hand. Unfortunately, in my opinion, there is such a
huge gap between the world of COM and the modern world, that I believe you'd
be better served by ignoring your experience and starting from scratch.

I had the benefit of learning .NET back in 2001. The gap between COM and
..NET 1.0 was large, but many resources were focused on bridging that gap.
The gap between COM and .NET 2.0 (and 3.0!) is much larger, and Microsoft no
longer spends quite as much time bridging the gap. This is why you might be
better off jumping the gap, rather than trying to use the bridge.

Good luck, in any case.

John