Hey Kevin,

>Only thing I'll add is that our client piece was used by 90% of users over the web, and 10% of the users from an internal location. So we had something at startup that set a property for whether 'connections' would take place via a web proxy call, or via remoting. We funneled all 'connection' calls to one function that handled either type. We found that for the 'internal' users, remoting with the application server through TCP was faster than going through the web service. (Obviously, web services can still be used for an intranet, but we found that remoting was a bit faster. Having said that, I've heard rumors that future versions of web services will perform better).

Yes, you're probably right about remoting being faster, but I think it was just easier to do it all with Web Services and not have to worry about allowing the front-end to communicate both ways. <g> Besides, by using Web Services, we've opened up some of the functionality to other users besides just our application.

~~Bonnie


>I'll toss my two pennies in...I went through the learning curve of remoting about a year ago.
>
>When one 'tier' (remote users) has to communicate with another tier over the web/HTTP, I think web services is definitely the way to go. Where remoting came in handy was when a client wanted the web server and the application server on different servers within an infastructure. In that instance, the web server remoted with the app server so that all the middle tier functions ran on an app server.
>
>While we *could* have used web services to go from the web server to the app server, that meant putting IIS on the target, which some I.S. guys are not going to like.
>
>The approach that Bonnie described is what I and others have done in the past, and seems to be a very good solution for distributed apps with a 'rich' client piece that needs to communicate via the web.
>
>Only thing I'll add is that our client piece was used by 90% of users over the web, and 10% of the users from an internal location. So we had something at startup that set a property for whether 'connections' would take place via a web proxy call, or via remoting. We funneled all 'connection' calls to one function that handled either type. We found that for the 'internal' users, remoting with the application server through TCP was faster than going through the web service. (Obviously, web services can still be used for an intranet, but we found that remoting was a bit faster. Having said that, I've heard rumors that future versions of web services will perform better).
>
>Kevin