 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / ASP.NET / Web Services / February 2007Returning Dataset or Datatable via Web Service
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, 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  SignatureThanks & Regards, Mark Nelson > I'm a bit puzzled by the current recommendation not to send Datasets or > Datatables between application tiers. [quoted text clipped - 15 lines] > > - 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/library/ms996381.aspx#asmxremotes_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 - > Joseph Geretz, > [quoted text clipped - 27 lines] >> >> - Joseph Geretz - > 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 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 - >> I'm a bit puzzled by the current recommendation not to send Datasets or >> Datatables between application tiers. [quoted text clipped - 7 lines] > > John > Isn't everything fundamentally serialized as XML anyway? > [quoted text clipped - 7 lines] > 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 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 - >> Isn't everything fundamentally serialized as XML anyway? >> [quoted text clipped - 44 lines] > > John > Hi John, > [quoted text clipped - 10 lines] > 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 [quoted text clipped - 6 lines] > 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. [quoted text clipped - 10 lines] > > 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. 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 - >> Hi John, >> [quoted text clipped - 71 lines] > least not without a versioning mechanism. Again, you may get away with > things like adding columns with some clients, but maybe not with others. > Hi John, > [quoted text clipped - 8 lines] > 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 [quoted text clipped - 14 lines] > 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 [quoted text clipped - 3 lines] > 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 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 [quoted text clipped - 3 lines] > 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 - >> Hi John, >> [quoted text clipped - 122 lines] > > John > Hi John, > [quoted text clipped - 28 lines] > > 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 > 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 - >> Hi John, >> [quoted text clipped - 34 lines] > > John > 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 > 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 - >> Hi John, >> Newcomers like myself? (shrug - whatever...) [quoted text clipped - 3 lines] > > John >> 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.