- Introduction
- .NET ORPC Options
- Enabling .NET Remoting Protocols
- When to Use Which Protocol
- .NET Remoting Protocols Comparison
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
When to Use Which Protocol
When I attended Microsoft TechEd 2002, I asked various speakers why programmers had so many choices and according to what metrics we should prefer one protocol over another. The funniest—yet somehow most honest—answer I got was, "You know, Microsoft is a generous company." <g> This was actually the answer that made me least upset, since the other ones I got sounded like "Use web services, always" (of course, a purely marketing-driven suggestion).
I recently attended TechEd 2003, and I've got good news for you (and for me): Microsoft is starting to unveil its vision about the future of distributed computing in a more pragmatic way. At last, each remote invocation protocol is officially given its proper usage context.
The simple, basic concept that must drive us to identify the best protocol for our needs is object distance. The distance between caller and called mustn't be considered in the strict geographical sense, however. Here's a list of what makes an object near and far.
You're near if...
You're on closely related machines and
You're in the same organization and
You're connected reliably and
You're in the same trust domain and
You're not interoperating
Otherwise, you're far.
Near communication most times uses a request/repost synchronous communication. You must still be concerned by performance issues, but it's almost like making a local call.
Preferred technologies for near communication are Enterprise Services (read: DCOM) and .NET Remoting. Specifically, they both require Windows on both sides. You might have read that using .NET Remoting with the SOAP formatter opens the doors of interoperability. This is not true. The SOAP formatter (despite its name) is CLR–centric and not XML Schema–centric. This means that only the Windows-based systems out there are capable of understanding your .NET Remoting XML payload.
In far communication, the two communications endpoints often run different operating systems, and the kind of conversation established is often message-based (larger, less frequent messages), taking the form of an asynchronous dialogue. Sometimes this kind of communication is referred to as workflow-based. Far communication is the land of web services.
We'll soon get into the technical details of these remote protocols. Before doing that, however, it's worthwhile to stress one point: Far and near communication generally are implementing two different class of business underneath. Far communication is for B2C; near is for intranet communication, most often within the same application boundaries. Different types of business imply different application functionalities and thus different architectural requirements. This is why .NET Remoting protocols are so different in the functionalities they offer; each one addresses a specific area. Think in advance about what kind of applications you're going to develop, and you'll hardly have any doubts about picking up the correct Remoting protocol.