.Net Distributed Application Design Guide

.Net Distributed Application Design Guide

 

 

What .Net Framework provides for distributed application design

As far as I’m aware, there are four different technologies, which can be used to build distributed applications in .Net platform. These technologies are .Net Remoting, Enterprise Services (COM+), Web Services and MSMQ (Microsoft's Message Queuing) respectively. It’s hard to say which one is better than other. Which one will be used to in a distributed application is depend on actual situation and requirements.

 

Use the right technology for the right thing

1, If you need to interact between tiers that are inside your application but across the network, then use remoting. Just avoid creating custom sinks or formatters because the way you extend remoting (creating remoting sinks, custom formatters, etc) will change with Indigo in a couple years. (which most people don't do, so this is typically a non-issue).

如果需要在同一个application内，不同层之间跨网络进行交互，采用Remoting技术比较合适。但是避免使用定制的sinks或formatter，因为Microsoft的Indigo团队可能在未来几年改变这一方式。不过，一般情况下我们不需要定制Sinks/Formatter。

 

2, If you need to communicate between applications (even .NET apps) then use web services. Note this is not between tiers, but between applications – as in SOA (Service-Oriented Architecture). SOA is not useful INSIDE applications. It is only useful BETWEEN applications.

如果需要在不同的application交互，采用web services技术比较合适。这是application之间的交互，而不是层与层之间的交互。

 

Tiers within an application trust each other. That’s why they are tiers. Applications don’t trust each other. They can’t, since there’s no way to know if different applications implement the same rules the same ways.

 

3, If you need ES (Enterprise Services), then use it. This article may help you decide if you need any ES features in your app. The thing is, if you do use ES, your client still needs to talk to the server-side objects. In most cases remoting is the simplest and fastest technology for this purpose. This article shows how to pull ES and remoting together.

在需要ES的时候，则采用ES。Reference 2可以帮助你分析是否你的application需要采用ES的特性和功能。如果的确需要采用ES技术，Client仍需要访问Server端的对象。多数情况下，Remoting技术可以简单并实现这一目的。Reference 3告诉你如何集成ES和Remoting技术。

 

4, Microsoft's Message Queuing (MSMQ) is part of the Windows Server operating system. Many distributed applications need the ability to handle delays between a request and a response. This is because all the steps in a distributed application process may not need to be, or cannot be, completed at one time. MSMQ allows applications to use components that communicate with one another using queued messages. Like e-mail messages that sit in an inbox, messages can exist on dissimilar systems that may not even be directly connected to each another. Message servers offer a full featured package for managing and monitoring messages that guarantees the delivery even if the destination system is temporarily unavailable.

MSMQ是Windows Server的一部分。因为在分布式应用进程中，所有的步骤可能不需要、或不能够在同一时间完成，因此，许多分布式应用需要处理Request/Response之间的延迟。MSMQ允许应用程序使用消息队列来通信，就像收件箱的email一样，消息可以存在于相异的系统中，甚至相互之间无法进行之间连接。消息服务器提供了完整的功能包，用来管理和监控消息，确保消息的发送，即使目的系统临时不可得到。

 

 

Using the Component (Enterprise Services)

It’s not very difficult to create enteprise services in .Net framework by adding a reference to System.EnterpriseServices.dll. Any class that will use or participate in EnterpriseServices features must be a subclass of System.EnterpriseServices.ServicedComponent. We can find a lot of related documents which provide how to write enterprise services. So these contents are omitted over here.

 

Of course just having the assembly written is only half the battle. We still need to figure out how we want to call it from our client code.

 

While technically we can use DCOM to call the assembly, that would require that we expose our .NET objects through COM interop, which is not ideal unless we are trying to call them from COM clients, such as Visual Basic 6.0 or ASP.

 

With .NET client applications, it is appropriate to use more native .NET technologies to communicate with the component. This leaves us with three main options:

 

从Client端application调用Enterprise Services推荐方法：

(1) Direct call from the same machine

(2) XML Web services

(3) .NET Remoting

All three options involve some code running on the same server as the component running in COM+ to make the actual call to the component.

 

In the first case, we have a client application running on the same machine, which means it can simply use EnterpriseServices to call the component directly.

 

We can construct an XML Web service that allows clients from other machines to use XML and SOAP to invoke the component. This won't directly expose the component, instead we'll construct a Web service that takes the client call and delegates it to the component running in COM+.

 

.NET Remoting allows a remote client to directly invoke our component in a manner similar to how DCOM worked in Visual Basic 6.0. We can construct a Remoting host application that directly exposes the component to clients, allowing them to interact across the network with the object as it runs on our server in COM+.

 

 

Appendix about the article

It’s just a brief introduction to those technologies related .Net distributed application design. The article shows you how to use right technology for your project, instead of how to use those technologies step by step. Maybe next posts will focus on those topics in detail.

 

Any questions or opinions, please make comments below. Thanks.

 

 

References:

1, Rockford Lhotka, http://www.lhotka.net/WeBlog/PermaLink.aspx?guid=0830a0e4-18bb-4182-99a7-a0c727fb913a

2, Rockford Lhotka, O COM+, Where Art Thou?, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnadvnet/html/vbnet04232002.asp

3, Rockford Lhotka, Applied Remoting, http://msdn.microsoft.com/vbasic/using/columns/adventures/default.aspx?pull=/library/en-us/dnadvnet/html/vbnet05272003.asp

4, MSDN, Understanding Messaging with MSMQ, http://www.microsoft.com/windows2000/technologies/communications/msmq/msmqoverview.asp