The Nine Rules of Remoting ( by Ingo Rammer)

 

The Nine Rules of Remoting  -- Ingo Rammer

Remoting provides a number of features whose applicability differs for a number of usage scenarios. To ensure that your application is reliable, stable, and scalable, you should follow these nine rules if you are communicating between different machines:

·       Use only server-activated objects configured as SingleCall
·       Use the HttpChannel with the BinaryFormatter. Host your components in IIS if you need scalability, authentication and authorization features.
·       Use IIS' ability to deactivate HTTP KeepAlives for maximum scalability.
·       Use a Network Load Balancing cluster of servers during development if you want to achieve scalability. Make sure to deactivate any client affinity and make sure that you deactivate http keepalives during development!
·       Do not use client-activated objects and don't pass any MarshalByRefObject over a remoting boundary. You will easily trap this if you use the .NET Framework version 1.1 which will throw a SecurityException or a SerializationException in this case. (Yes, you could change this setting - but you shouldn't!)
·       Do not use events, callbacks and client-side sponsors.
·       Do not use static fields to hold state. Instead put ALL state information in your database. If you keep state in memory, you will run into problems if you try to scale your application out to a cluster of servers. Cache information only if it's not going to change (like a list of states or cities) - else you will run into cache-synchronization nightmares on your cluster.
·       Do not use Remoting for anything else apart from .NET to .NET communications. Use ASP.NET Web Services and the Web Services Enhancements (WSE) for anything related to SOAP, Service Oriented Architectures and platform independence.
·       Do not try to fit distributed transactions, security, and such into custom channel sinks. Instead, use Enterprise Services if applicable in your environment. .NET Remoting isn't a middleware, it is just a transport protocol - if you need services, use a service-oriented framework!

If you follow these guidelines, your Remoting application will be perfectly stable, reliable and scalable.

 

这些规则主要针对那些cross machine boundaries的分布式应用，cross local  machine process/appDomain 不在考虑范围之内

公司里面的Remoting项目基本上都符合了这些rule,只是最后一条偶们通过custom sink去处理安全，授权等内容，一是MS enterprise service研究还不够深入，另外一个是现在有些应用层的IOC/AOP容器也没深入研究过不知道好不好用。另外有些从数据库取出来的枚举值一类的东西Cache在服务器端，是通过Singlteon访问的