.NET Remoting

You have been introduced to several areas where distributed processing is sup ported in the .NET development arena. For example, an application that uses .NET XML Web services is supporting a distributed processing model. The book's pre vious discussions about MSMQ and COM+ introduced ways to use .NET- and Windows-based products with distributed processing models. With that, it would be a disservice ^[11] to you if I did not introduce to you the newest .NET distributed processing feature: . NET Remoting.

Note  

.NET Remoting is .NET's replacement for the Distributed Component Object Model (DCOM) Windows legacy feature.

The distributed processing feature .NET Remoting is primarily available for .NET client applications to be able to communicate with .NET server applications, potentially in a loosely coupled design. Such communication can occur between applications hosted on the same machine, on the same LAN, or on remotely located machines. On the other hand, XML Web services (and even MSMQ) fills the gap when disparate types of applications, runtimes , and even platforms need to communicate. You should consider .NET Remoting as one of your alternatives for distributed processing, particularly when each application involved is a "managed" application (i.e., a .NET application).

Note  

You can use .NET Remoting over TCP or HTTP network protocols.

You will notice that the .NET Framework provides significant support for .NET Remoting. The System.Runtime.Remoting namespace provides the basis from which to build these types of distributed applications. The System.Runtime.Remoting "supporting" namespaces are as follows :

• System.Runtime.Remoting.Activation

• System.Runtime.Remoting.Channels

• System.Runtime.Remoting.Channels.Http

• System.Runtime.Remoting.Channels.Tcp

• System.Runtime.Remoting.Contexts

• System.Runtime.Remoting.Lifetime

• System.Runtime.Remoting.Messaging

• System.Runtime.Remoting.Metadata

• System.Runtime.Remoting.Metadata.W3cXsd2001

• System.Runtime.Remoting.MetadataServices

• System.Runtime.Remoting.Proxies

• System.Runtime.Remoting.Services

As you can see from the impressive preceding list, there is certainly support available in the .NET Framework for Remoting. If you look at the naming con vention used in the list of namespaces, you will get an idea of the topical nature taken with further learning into the area of Remoting. In other words, drilling down into the collection of Remoting namespaces will take you down the learning path of the following .NET Remoting technologies:

• Object activation: Client-side versus server-side, using marshal by value or marshal by reference.

• Transport channels: Using the TcpChannel or HttpChannel .NET Framework classes depending on the chosen protocol.

• Contexts: Context-bound objects (versus context-agile objects) and the proper use of the SynchronizationAttribute attribute. You will learn about the synchronization domain when you explore the SynchronizationAttribute attribute. ^[12]

• Object lifetime: Use of lease periods and determining whether to use SingleCall objects or Singleton call objects.

• Messaging: Working with the AsyncResult class for asynchronous processing. Also, using the Message object for remote calls and passing data.

• Metadata and proxies: Using SoapSuds.exe to extract and convert metadata to/from XML Schema. Using proxies to forward your object calls.

• Sinks: Creating and registering your sink to be on the receiving or sending end of your transport channels. Also creating message sinks and formatter sinks.

• Formatters: Using SoapFormatter or BinaryFormatter to serialize and deserialize your objects depending on the format of your message.

Please consider exploring the previously listed Remoting namespaces. You will find that, for Microsoft, this technology was not an afterthought. For you, learning about this technology should not be an afterthought either.

Tip  

In Chapter 18, you were introduced to the Microsoft .NET Framework Configuration tool. As you explore and learn more about .NET Remoting, you will eventually come across the need to use this tool again. You will discover that developing a .NET Remoting application typically includes the need to configure communication channels. This tool exposes an option for Remoting Services. Recall that you access the Microsoft .NET Framework Configuration tool by clicking the Start button and selecting Programs Administrative Tools Microsoft .NET Framework Configuration.

I wish I could say that that was it. But there is more. Any serious attempt to learn about .NET Remoting should be accompanied by a comfortable under standing of several .NET topics not specific to .NET Remoting: application domains, synchronization domains, marshaling and serialization concerns, and object interfaces. In the simplest of terms, you will turn to .NET Remoting when you need to enable communication from one application domain to another application domain.

Note  

I briefly cover the topics application domains, marshaling and serialization concerns, and object interfaces in this book. Please use available references (including the references in the "To Learn More" section) for additional details.

Now, I need to bring this .NET Remoting discussion to an end and limit the coverage of this topic to a high-level introduction. To go much further into the details of .NET Remoting here would be going a bit beyond the scope of this book. Further learning of the topic .NET Remoting will certainly justify the use of the "To Learn More" references that I have provided. Expect to see the .NET Remoting technology implemented in your more sophisticated enterprise-level distributed applications.

Tip  

If there is just one point to take from this section it is this: .NET Remoting is one of several choices for building .NET distributed applications. You have been introduced to ASP.NET XML Web services, COM+, and MSMQ. These other technologies also support the distributed processing model. Each technique is available to address different business needs.

I have one additional enterprise development topic to cover: multithreading.

^[11] By just introducing a topic and not providing a thorough and complete discussion, I equally run the risk of doing you a disservice. Bear in mind, this book is designed to be a guide, not a complete reference. Please approach this discussion with that perspective. I can't emphasize enough that you should take advantage of the end-of-chapter references.

^[12] Interestingly enough, there are two SynchronizationAttribute classes. One lives in the System.EnterpriseServices namespace. The other lives in the System.Runtime.Remoting.Contexts namespace. The former is used for COM+ (Enterprise Services) synchronous scenarios. The latter is used both for asynchronous and synchronous needs, as long as the object is context bound.