.NET 远程处理与 SOA
我试图理解 .NET 远程处理（和类似技术）与 SOA 之间的概念（相似点和差异）。有人可以解释一下细节吗？
I am trying to understand concepts (similarities and differences) between the .NET remoting (and similar technology) compared to SOA. Can someone please explain the details?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
它们没有可比性。
.NET 远程处理是一种用于调用远程服务的（已过时，使用 WCF）技术。您可以在 SOA 环境以及纯客户端-服务器通信（更可能在客户端-服务器通信中）中使用 .NET 远程处理。 .NET 远程处理不讨论它们为什么相互通信，而只讨论如何通信。
SOA 是一个关于多个不同服务如何相互协作的概念（或企业架构）。它并没有过多讨论使用什么技术，而是讨论如何用统一的业务对象和统一的接口连接不同的服务的结构。 SOA是如何建模和提取那些公共接口和公共业务对象的过程。
They are not comparable.
.NET remoting is an (obsolete, use WCF) technique for calling remote services. You can use .NET remoting in a SOA environment as well as in a pure client-server communication (more likely in client-server communication). .NET remoting does not talk about why they talk to each other, just how.
SOA is a concept (or enterprise architecture) about how several different services cooperate with each other. It does not talk very much about what technique to use, rather about the structure how to connect different services with unified business objects and unified interfaces. SOA is a process of how to model and extract those common interfaces and common business objects.
SOA 比远程处理更具企业规模——在 SOA 中，您可能拥有许多组件来支持服务发现、工作负载和方法调用管理以及资源管理等。
SOA is rather more enterprise scale than remoting -- in SOA you might have a number of components that enable service discovery, workload and method invocation management, and resource management, among other things.
简而言之，Remoting 具有紧密耦合的组件，而 SOA 具有松散耦合的组件。
在 Remoting 中，它只是 .Net 或 Java（或 C++ 等）中常见的过程调用开发风格的扩展，扩展为允许远程过程调用。双方（客户端和服务器）通常构建在同一平台上，并且调用并非旨在与其他平台互操作。
在 SOA 中，构建服务的目的是调用它们的客户端可能不会构建在同一平台上。通常，SOA 解决方案的构建理念是：客户端和服务器之间的调用被视为消息，并且消息本身与操作同样重要。
将客户端到服务器的调用视为消息的好处是，当消息从客户端路由到服务器时，可以使用其他服务与消息进行交互，从而更容易注入新功能，而无需重写客户端或服务器。您可以使用 Remoting 来完成其中的一些工作，但它不像 SOA 那么容易，因为客户端和服务器端可能在构建时都没有考虑到可扩展性。话虽如此，SOA 确实增加了架构的复杂性。不复杂的情况可能不值得额外的投资。优秀的架构师将帮助您确定项目的每种开发风格的优缺点，从而帮助确定何时使用每种风格。
In simplest terms, Remoting has tightly coupled components, and SOA has loosely coupled components.
In Remoting, it is just an extension of the procedure call style of development typically found in .Net or Java (or C++, etc.), extended to allow for remote procedure calls. Both sides (the client and the server) are typically built on the same platform, and the calls are not designed to interoperate with other platforms.
In SOA, services are built with the intent that the clients calling them may not be built on the same platform. Typically, a SOA solution is built around the idea that the call between a client and a server is treated as a message, and that the message itself is just as important as the operation.
The benefit of treating the call from client to server as a message is that other services can be used to interact with the message as it is routed from client to server, making it much easier to inject new functionality, without having to rewrite either the client or the server. You can do some of this with Remoting, but it isn't as easy as SOA, because both the clientside and server side were probably not built with that extenibility in mind. That being said, SOA does add complexity to the architecture. Complexity that is not may not be worth the extra investment. A good architect will help you determine the pros and cons for each development style for your project, helping to determine when to use each style.