Michel,

I think you misunderstood Morgan's comments. His main point is that it's not a good idea for a User Group's webpage to be hitting your WebService from their web page itself ... primarily because if your web server is down or slow, it will affect their webpage (it could time out or just flat out not work). He's simply saying that you shouldn't recommend that it be done this way and that you should recommend that they cache the info locally and have their webpage hit the local cache. How often it's cached from your WebService and how it's cached either via a service or a scheduled windows event, would be up to the User Group, but you might give some examples along that line too.

~~Bonnie

>>I took a look at the page and I think the explain is very good. I might suggest a sample project that they could download and modify, instead of just code examples.
>
>Ok
>
>>There is one major concern about the whole process that I thought about, I don't think it is good practice to have a webpage call a webservice for information. If there connection to your server is down, or if they have a large load of traffic the page could time out or could crash. Even if they catch the exception, I think it is bad practice. It will cause their webpage to render slowly as well, as it has to wait to connect to your webservice, get the information and then render the page. Would I would recommend that each of the user group does, or that someone would write would be to run a service or even a scheduled windows event on their IIS server to hit the webservice say every 5 mins and cache the information. It reduces the load on their server and on your server.
>
>We follow some requests we have. We deliver that but if they wish to adjust it to have as you say, they'll be able to. Our server has proven to be high quality. We are under MCI with high speed and so far, after those years, the connection up time has been excellent. The response time of the Universal Thread engines is also extremely fast. I tested locally and live and the live connection is faster than my local connection. :)
>
>>It could be a crontab on a linux web server, or a scheduled event or a windows service on an IIS server. That way, if your server is down they have at least old cached information, and if your server is up it isn't being hammered by webservice calls. Imagine if 10 user groups have 10 people each hit their website within 1 minute, that is 100 calls to your webservice and 100*the number of database calls for your webservice to your database. It could crash pretty easily.
>
>The Web Service has been up and running for about two years now. Yes, it is true, adding that capability will increase its load request. I also have this approach on a Web site to get the exchange rate by hitting the Web Service at occurence interval. The client will have the choice to make. If they have the robot in place, event handler or similar, they'll have something to start with. Later on, they can fine tune it as you say.