Tripping over Missing Servers

re: Tripping over Missing Servers

Tobias — Fri, 22 May 2009 21:16:23 GMT

The problem with servers can be solved with a central UDDI and dynamic WCF clients. After some tweaking we got a reliable plattform. A bunch of "unreliable" services grouped by a UDDI can make a pretty reliable service. See http://www.codeproject.com/KB/WCF/uddiservicefactory.aspx for code and details.

This "all is static approach" of standard WCF implementation is its biggest conceptual weakness and imo not suited for serious enterprise apps.

The first call is slow problem. Before the first call the client is in "Created" state. First call establishes the connection which can consist of a couple of calls between service and client (encryption) and thus can be very time consuming.

This can be partially solved by calling the the proxies .Open() method before the first method call.

But be careful. There is a nasty caching bug waiting. Check http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/49c6683d-043b-4358-ae3c-3f75bfb34cb0 for a workaround.

re: Tripping over Missing Servers

Tobias Manthey — Sat, 23 May 2009 00:13:59 GMT

I would go even one step further...

If a distributed system is for you a system one in which the failure of a computer you didn't even know existed can render your own computer unusable, you have a major design flaw in your distributed system.

Distributed systems are by definition systems in which you do not control every node and hence redundancy and a fail over mechanisms are essential components.

But then a distributed system can be a source of impressive quality of service. Guess you have a crappy service with a availability of 90%. Having 4 services of them with a fail over mechanism turns down the probability of a total service failure to 0.1^4 = 0.0001 or the service availability to 99.99%. This makes the difference between crap and high availability.

But regarding the proxy I definitely agree. Especially in enterprise environments using a proxy should be very common. Proxy and WCF does not go very well together and by default all .Net HTTP requests use your Internet Explorer settings. Not only that proxies slow down things significantly, especially "1 out 100 service calls fails" errors can be caused by proxies.

Either turn off the proxy usage in code by setting

Webrequest.DefaultProxy = null;

or switch it off in configuration...

<system.net>

</defaultProxy>

</system.net>

Use Fiddler on your client computer to confirm that you were successful.

re: Tripping over Missing Servers

Udi Dahan — Sat, 23 May 2009 14:56:04 GMT

If you were doing queued messaging between your services, these technical problems would just disappear.

Of course, you'd have to rethink your service contracts to move to a more one-way model (possibly with callback contracts), but that's actually a good thing - technical decoupling leading to greater logical decoupling.

<a href="http://www.nservicebus.com">NServiceBus</a> is a messaging framework which is based on these two principles - technical and logical decoupling, which is designed to make building robust and scalable distributed systems easier by preventing you from making decisions that can get you in trouble later.

re: Tripping over Missing Servers

Nicholas Allen — Tue, 26 May 2009 23:43:17 GMT

Hi Tobias,

Replication is indeed a common way of improving reliability beyond that of the individual components in the system. There are some restrictions to this approach (for example, replicated systems frequently need to trade off consistency of write visibility to achieve adequate performance) but there's a very large number of applications for which these restrictions are acceptable. A client might still have single points of failures even in a replicated system though, including some of the examples in the article. DNS is a highly replicated distributed system but a client might not have a mechanism for retrying after the name servers it has been configured with fail to respond.

re: Tripping over Missing Servers

Nicholas Allen — Tue, 26 May 2009 23:53:52 GMT

Hi Udi,

I agree with you that more people should be thinking about queued topologies that provide decoupled messaging than do so today. I avoid calling queues a generic resolution to the problem though because replacing connected messaging with queued messaging is a semantic change to the application. Adding a queue to the system can change the boundaries for transactions and acknowledgments, as well as some of the properties of message delivery sessions. Application changes or additional protocols may be needed, which you might not always have the design freedom to introduce. That's why more people need to think about these problems up front because it is often hard to switch to a better approach after the problem is seen in deployment.