>To me, it is very impressive and interesting that you built your Web Service in .NET and the data is in VFP database/tables (correct me if I am wrong). Since I plan to provide my application data (which is also VFP) to my customers via WS, I would be interested to learn how you did it. Do you plan to write an article in UT Magazine with code examples on how you built your UT WB?

A lot of people are mixing tiers in Web Service and I really don't think it should be used that way. To me, a Web Service should be a wrapper only, one tier, which serves for the purpose of connecting the client with an application. This is how we use it. I've built several versions of Web Services and I always built them like that.

For example, a Web Service is a new environment at every hit. So, it's stateless. So, the best is to keep it at the minimum. You want to obtain the maximum performance as possible.

For every hit of UT WS, there is about 25 tables that are used. I wouldn't want to have to deal with opening those tables are every hit at the WS. That would be a really poor design. So, we simply use it as a wrapper to exchange data with XML with our application that already have a full framework loaded in memory.

So, no data tier and no business tier appears at the WS level. The WS level is only responsible for exposing its methods, setting up the cookies, the error handling and some sort of related things.

So, as you might have guessed, the WS is built with VB.NET which generates an ASP.NET WS. Then, by XML is gets data from an VFP application. The VFP application handles also all the business tier. By that, I can easily have my WS on my test server to work with the live data when I want to. Or, I can use it directly on the server itself. So, on the first approach, the data travels across a WS which is miles away from the data tier. On the second approach, it's the same server. Interesting? :)