Reliability of .Net Webservices

Hi, Just a general question, .Net 3.5 has lots of enhancements on secure and transacted webservices ? Does anyone here have experience of this ? does it add overhead ? Can these webservices (in a LAN environment and assumed stateless / lightweight) be relied upon to be used in realtime (by realtime I mean response of 1 second or less ?). I realise that this cannot be guaranteed as it depends heavilly on what the service is doing and what network it is deployed upon etc etc etc, but assuming there are no issues here, what I am simply asking is, is the benefit of 'knowing' your webservice will return impaired by any overhead that prevent such a webservice from being generally reliable enough to be used in a real time application ?

If not, are there any other recommened architectures / methodologies I can take a look at ? (remoting for example) or should I simply stick with a tcp socket and build-my-own ?? :)

Thanks

Chub.

The answer really does depend on what you are doing. With 3.5, MS is pushing the whole WCF concept, which wraps all kinds of different communications methods under one common framework. Is that a good thing? Well, there certainly does appear to be some overhead to get the common functionality, and that will have some impact on performance. However, if you are using one of the faster bindings, like TCP, performance should be ok.

Having said that, I see the major advantage of WCF as being a consistent means to communicate using a variety of protocols. If you are already using TCP or UDP for LAN communications, I see little or no real benefit to using WCF, instead. Once you are up to speed on WCF, it probably is considerably easier to set up a channel using TCP bindings, but it probably isn't faster, and may not be in any other way superior. Furthermore, if you want great speed, and are dealing with small data packet size, then there is also UDP. While you can get UDP bindings for use with WCF, it isn't part of the standard package.

A webservice is only as reliable as the website that host it. And the reliability of a website is dependent on the server, network... which is hard to say. As for speed, I'd say it's not very fast but again, this greatly depends on the server and network speed. If your application consumes a webservice, it also takes significantly longer to load.

I've been using WCF for the past few weeks (as Shaggy says, WCF is basically what you are talking about) and I agree that the main benefit of a framework like WCF is the ease of use (although it doesnt seem very easy to use at first!) and performance probably does suffer a little compared to just a plain old socket connection. However, assuming that your server can do all of its processing that is required before each 'update' is sent to the client application in well under a second then if you are using the net.tcp binding and this is only used in a LAN environment (ie no VPN or internet use etc) then I think it should be able to cope. I have a system that uses WCF that communicates with the client apps every 10 seconds and have had no issues at all.