The key to giving good advice is knowing what matters most. It's possible to be 100% correct in what you say and still give stunningly bad advice if your focus is on the minutia of a topic. Rich Turner falls into this trap in his article over on MSDN called "
Developing Distributed Services Today". The self-proclaimed goal of the article is to "help you make the best choices when deciding how to build distributed systems today on the Microsoft platform." As such, the article is a miserable failure even though almost all of what it says is accurate. I want to examine what Rich's article leaves unsaid because if you really want to make the best choices about building distributed systems you can safely ignore almost everything in Rich's article, but there are some huge issues that you will have to address.
Distributed Systems
Microsoft has learned a lot about what works and what doesn't in building distributed systems. Unfortunately, the real lessons of the past 10 years don't seem to have permeated throughout the organization. Looking at things from the outside, I would say the BizTalk team and the folks who designed WSE get it, the folks who designed DCOM, .NET Remoting, ASMX, and Indigo (Windows Communication Foundation) don't.
Distributed Objects
They suck. They sucked 10 years ago, they suck today, they'll suck 10 years from now. If you want an accessible platform-independent explanation of why, go read Ted Neward's
blog. Here's a bit of advice for architects and developers. If the programming model for your distributed technology of choice includes the concept of a proxy, you're being forced into distributed object semantics. You can build good distributed systems that way, but you'll have ignore all its RAD features and spend a lot of time building your own programming model on top of it.
Services
The key features of services are the messages they understand (i.e. receive and transmit), the operations they perform, and the events they respond to or initiate. Everything is else is just icing on the cake.
Guidance - Building Services Today
My advice assumes you want to build non-trivial distributed applications on Microsoft's platform. Don't worry as much about "future-proofing" applications as you do about actually meeting today's requirements.
Guidance Summary
- Decide if you need BizTalk Server. BizTalk is a high value and high cost addition to your infrastructure.
- Use System.Messaging for reliable communication between tiers under your control.
- Use WSE when MSMQ is not available.
- Use ASMX web services only as a façade layer.
- Don't use .NET Remoting.
- Don't use COM+ and Enterprise Services unless you have to.
- Design your systems around messages, not objects
- Prefer asynchronous communication strategies
Build Code Using .NET
Here's the one important thing that Rich gets right.
Build Web Services
The best thing about ASMX web services is that, if you use a little care, you can do simple communication with many platforms. Unfortunately, if you use them the way Microsoft encourages you to (both by their advice and their tool support), you will end up with tightly-coupled applications that use a distributed object paradigm. If you want to integrate with other platforms in any but the most simplistic ways, you really ought to be looking at BizTalk.
Enhance Your Services with WSE If You Need to Support WS-*
Actually, the best thing about WSE is that has a really nice message-oriented programming model and an excellent extensibility mechanism.
Keep Objects and Components Inside Your Services
Great advice. Unfortunately Rich goes on to contradict himself later in the article.
Use Enterprise Services & COM+ When Appropriate
The marriage of .NET and COM+ has been an uneasy one at best. The mismatch between the two systems assumptions (particularly, but not limited to, the difference between garbage collection and ref counting) is so great that complex interactions are typically plagued by nasty bugs. Avoid building systems that require frequent, fine-grained crossing of that border.
Flowing Transactions
Don't use distributed transactions unless you absolutely have to. Avoid designs that allow the caller to initiate transactions. Resources that are that tightly coupled belong on the same system, if at all possible.
Use .NET Remoting When Appropriate
Except that it is never appropriate. Well, it is theoretically possible that it might be the best solution to some problem, but I doubt it. Sure, there are lots of situations where building a system on .NET Remoting won't be a disaster, but why invest in a dead-end technology that won't scale, has no reasonable security story, and forces you into an inappropriate programming model.
Use System.Messaging/MSMQ for Queued Messaging
System.Messaging and MSMQ are Microsoft's most under-utilized technologies. They've done an excellent job steering developers away from it by failing to show the best way to use it. Here's what you need to know:
- Use private queues. Very few applications need public queues and the performance hit is substantial.
- Use non-transactional queues. Again, very few applications need transactional queues.
- System.Messaging is messed up in a lot of ways, but you can work around that.
- Use the asynchronous methods of System.Messaging (BeginReceive and BeginPeek) where possible.
- Learn to build your own formatter for System.Messaging.
The Future of Microsoft Distributed Systems Technologies
The future is pretty much irrelevant to building distributed systems today, so I'll ignore the rest of Rich's article.
Posted
Aug 04 2005, 07:40 AM
by
john-cavnar-johnson