Local Machine Communication Between NET Applications
Interprocess, or cross-process, communication refers to communication between two separate processes running on the same machine. Intra-process, or in-process, communication refers to communication between two software components running within one process. Together these types of communication make up what we refer to as local-machine communication (a.k.a. on-machine communication)
Application domains (a.k.a. app-domains) are a mechanism in .NET for further partitioning a Windows process to support multiple .NET applications by isolating them along security and activation boundaries. This means that app-domains are another communication boundary that can be crossed by .NET applications. Because of this we define two additional terms: inter-appdomain and intra-appdomain.
• inter-appdomain or cross-appdomain. Communication that occurs between two .NET applications that run in separate app-domains within the same Windows process. This could also be communication within a single .NET application that is designed to run within multiple app-domains.
• intra-appdomain or in-appdomain. Communication that occurs within a single .NET application that runs in a single application domain. For our discussion, think of an app-domain as being one or more .NET processes that run within a Windows process.
WCF does not make a distinction between interprocess, intraprocess, inter-appdomain and intra-appdomain communication. Instead, WCF offers a single on-machine transport channel based on named pipes. Named pipes are a standard means of interprocess communications (IPC) on Windows as well as UNIX environments. The WCF team considered an in-process binding but decided that it was not necessary for most situations. Do not concern yourself over this decision. There is no loss in functionality. The only difference between a named pipe and a true in-process binding is performance.
The performance of the named pipes binding is good enough for most in-process communication situations. If you find that a single on-machine transport is not sufficient, you have the capability of creating a custom binding that uses a custom transport channel. See the "Creating a Custom Binding" section later in this chapter for more information on creating a custom binding.
Post a comment