I love using structures to define the shape or type of data returned by web methods. Recently, Rich Turner posted a blog entitled Exchanging Data - shipping typeless containers stating his thoughts why a dataset is a poor choice for this purpose and that a serialize structure is a better choice; I couldn't agree more.
I've gotten in a habit lately of creating a folder under my web service called MessageTypes, and adding all the structures that will will be returned (and/or used as input) to the web methods. This keeps all the message definitions in one place and easy to find.
I also make a habit of NEVER returning the XML serialized instance of my business objects that the web service is using behind the scenes. I always copy the desired data from a b.o. into one of the just mentioned data structures within the web service before it is returned. At times this might seem like a ridiculous extra copy but this is very important. My business objects used by the web service will change over time, however I want it to be a planned coordinated event when I decide to extend the message and data returned by a web service. So, if my web service is returning information about a customer, and within the web service I load up a customer b.o. to do the work, it might be very compelling (at least at the beginning of a project) and easy to return the customer object and allow XML serialization to to build the message shape based on the object's public properties. This is not good. It makes much better sense to take the time to explicitly describe a data structure that will shape the return of the web method, and take the time to explicitly populate the data structure.