>>>Cool, let me know if it works out.
>>
>>Drawback to the "stateful" web service scenario is that I'll have to build a single threaded server. Could become an issue with lots of users consuming the web service - hmmm. I'll see if I can get away from the statefulness - as you first suggested. I will still use the basic idea of a second object retaining properties, but the web service itself will need to be stateless.
>
>Really building a Web Service requires rethinking how objects work. I think Microsoft is doing everyone a disfavor by promoting Web Services as taking existing objects to the Web. I would recommend to *always* create a wrapper - a Web Service is just another front (or middle tier front end) to a business service/object.
>
>As such business objects probably should be able to deal with XML as an incoming and outgoing data format so that they can pass data back and forth efficiently. In .Net you can use objects (including the new DataSet object in ADO.Net which is very powerful) but with COM you're pretty much stuck with XML because it's very difficult to dynamically create object that can persist into XML easily from binary COM objects (there are ways to do this and wwXML is one way that does, but it's not perfect).
>
>With the wrapper approach you should be able to implement just about any solution without ever having to go stateful on your objects. I've never had a sceario where more state than an ID was required which you can possibly store in a Session variable (if you're using the ASP or WWWC SOAP implementations - that won't work with the ISAPI connector though).

Exactly, that's what we do here as well. As you mentioned, we just use a Web Service as a wrapper. It contains the required methods and that's about it. Each method forwards the request to the Universal Thread server. So, we can then use the same business logic and just change something at the end for the format of the returned data. The Web Service receives the returned data and complete the transaction.