web services中如果用.NET的话，DataSet可以作为与客户端交互的一个返回值，因为DataSet实质上是XML。而SOAP WSDL等都是基于XML的。
-----------------------------------
实际的设计根本不是纠结这个。比如说你打过电话，那么请问是你通过移动运营商的网络来给对方打电话快呢？还是你直接跟对方用对讲机快呢？
使用一个业务服务器架构，在于服务设计。而不在于什么增删改查。用服务设计，就可以“通过你自己智慧提供越来越丰富的服务，同时很好地控制客户端”。
--------------------------------------
比如说你想发布一个服务，通过“照片+简单提示”就可以在全世界范围内找人，你的webservice可以到许多大公司的几百PB、几万台服务器的数据库上去搜索，可以使用许多搜索引擎搜索，也可以让你的坐席人员花10分钟时间帮用户把信息完善一下再搜索，等等，但是用户看到的就是一个webservice服务，它根本不用扯到什么“有没有、有几个、有什么种类的关系数据库”的问题上。用户可以是个人，也可以是企业软件。
学会开发和发布服务，一个公司用于发布自己可控制的平台。根本不争论什么“增删改查”问题。
-------------------------------------------
短处一：单机应用程序
目前，企业和个人还使用着很多桌面应用程序。其中一些只需要与本机上的其它程序通信。在这种情况下，最好就不要用WebService，只要用本地的API就可以了。COM非常适合于在这种情况下工作，因为它既小又快。运行在同一台服务器上的服务器软件也是这样。最好直接用COM或其它本地的API来进行应用程序间的调用。当然WebService也能用在这些场合，但那样不仅消耗太大，而且不会带来任何好处。
短处二：局域网的同构应用程序
在许多应用中，所有的程序都是用VB或VC开发的，都在Windows平台下使用COM，都运行在同一个局域网上。例如，有两个服务器应用程序需要相互通信，或者有一个Win32或WinForm的客户程序要连接局域网上另一个服务器的程序。在这些程序里，使用DCOM会比SOAP/HTTP有效得多。与此相类似，如果一个.NET程序要连接到局域网上的另一个.NET程序，应该使用.NETremoting。有趣的是，在.NETremoting中，也可以指定使用SOAP/HTTP来进行WebService调用。不过最好还是直接通过TCP进行RPC调用，那样会有效得多。
总之，只要从应用程序结构的角度看，有别的方法比WebService更有效、更可行，那就不要用WebService