Advanced .NET Remoting

TechGuy949 writes ".NET Remoting is a technology that is often overlooked due to Microsoft's intense focus on promoting XML Web Services technology. In actual fact, .NET remoting is often a more appropriate solution than Web Services, and it certainly performs better and scales better when used properly. Ingo Rammer has written a technically sound, very informative book on .NET remoting technology, which is a good thing, given that there are still far too few titles available on this important technology." Read on for the rest of TechGuy949's review of Advanced .NET Remoting. Update: 10/23 17:28 GMT by T : Please note: the reviewer writes for Apress (publisher of this book); book reviewers are encouraged to read the book review guidelines linked below, and to disclose any such relationship. I regret not knowing this before the review ran. Advanced .NET Remoting author Ingo Rammer pages 404 publisher APress rating 8 reviewer TechGuy949 ISBN 1590590252 summary A two-part overview of .NET Remoting, from intro to advanced material.

My Overview and Summary Advanced .NET Remoting breaks out into a two-part book. The first four chapters are at the introductory level, while later chapters are considerably more advanced. The book begins with an informative conceptual discussion on what .NET remoting technology is, but then quickly moves on to more specifics, entirely focused on generous code examples (which actually work, barring one or two stray lines here and there, which I found easy to correct).

I picked up this title needing to get a solid introduction to .NET remoting, and the first part of this book does not disappoint. If you stop reading after the first four chapters (after spending time working on each and every code example). you will feel like you have a solid grasp of the basics of .NET remoting. However, you need to delve into the second part of the book to realize that .NET remoting is a deep and complex topic that is going to require considerable effort on your part to understand.

The second part of the book is not for the faint-hearted. The complexity level ratchets up several notches, and holds nothing back. It delves into advanced topics such as .NET remoting internals, including message sinks, channel sinks, formatters, and transport protocols, and shows you how to customize each part. Ingo's goal is for you to really understand how the .NET Framework implements remoting. The discussion here often borders on the theoretical, but it always stays grounded in relevant code examples.

Intermediate to advanced developers will greatly appreciate this book if they are looking for an in-depth, no holds barred discussion of .NET remoting.

What's in the Book Chapters 1-4 are an introduction to .NET remoting and configuration. Ingo starts with a conceptual discussion to help you understand how .NET remoting fits into the larger picture. He then presents a remoting example that provides an excellent introduction to the core aspects of remoting, including different types of remoting objects; marshalling objects by reference; serializing objects; and using interfaces to share type information. Chapter 4, on configuration, shows you how to use configuration files to simplify your remoting code, and to make it easier to port across different deployment environments.

Chapter 5 is about securing .NET remoting. This chapter was disappointingly short and did not provide enough depth. Also, some security implementation features have changed in v1.1 of the framework, so this section is not the most relevant one in the book. To his credit, Ingo has published a 1.1 update on his website that specifically addresses relevant changes to security implementation in the .NET framework.

Chapter 6 is where things start to get advanced. This chapter discusses object lifetime issues, and shows you how to control the lifetime of remotable objects, through "leasing" and "sponsorship." It also shows you how to implement asynchronous remoting calls using delegates and events. Chapter 6 is a must-read.

Chapter 7-10 is where things get really advanced. These chapters shows you how the .NET framework implements remoting, and it studies the 5 elements of remoting in great depth (Proxies, Messages, Message Sinks, Formatters and Transport Channels). This chapter is packed, and is a must-read for understanding advanced .NET remoting issues, especially when you need to heavily customize the implementation. Intermediate developers will have a harder time with these chapters, and may not find all of the material relevant to a basic .NET remoting implementation.

Chapter 11 closes out the book with an interesting look at how to implement .NET remoting techniques in a client application in order to manage the objects more effectively. Again, intermediate developers will have difficulty with this chapter, which is the most theoretical in the book. Advanced developers will appreciate it however, especially with Ingo's lead-in warning that 100% of the material in the chapter is undocumented by Microsoft!

Table of Contents

1. Introduction to Remoting
2. .NET Remoting Basics
3. Remoting in Action
4. Configuration and Deployment
5. Securing .NET Remoting
6. In-Depth .NET Remoting
7. Inside the Framework
8. Creation of Sinks
9. Extending .NET Remoting
10. Developing a Transport Channel
11. Context Matters

You can purchase Advanced .Net Remoting from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Re:Especially in the fog of marketese that is .NET

[mikera]

Broadly speaking, it's the ability to call methods on remote objects (e.g. a separate machine over the network). Think of it as something like Java RMI. The framework takes care of things like serializing the parameters and return values.

I think it's a decent technology for the right kind of applications, e.g. a cluster of servers that need to share data. However, if you want to expose services to other systems in a more general way, web services are probably a much better way to go.

Re:Especially in the fog of marketese that is .NET

[AlabamaMike]

.NET Remoting is one of Microsoft's solutions for the problem of inter-process (or application) communication. The writer of this review paid cursory attention to this fact when he made analogy to the promotion of XML Web Services (a technology that solves the same problem.) Think of .NET remoting as MS's RMI. The book that is reviewed here actually comes in two flavors, a VB.NET flavor and a C# flavor. Although the underlying framework (the .NET class library) supports both languages, the structure of the resulting code is different enough to call for such as thing. As for Ingo's book, this was the seminal tome for those looking into implementing programs that leveraged the Remoting technology. Ingo spent a good deal of his own time research the book, even digging to the level of examining the MSIL for the Remoting namespace. Support efforts such as this. This book is not a retelling of the MSDN documentation ... it's a product of a great undertaking.
-A.M.

Re:Especially in the fog of marketese that is .NET

[the quick brown fox]

It's basically a framework for remote procedure calls, over either TCP sockets or on top of HTTP. You can use it in a way similar to Java's RMI, or like SOAP (web services), or you can provide your own protocol.

If that's still too jargony for you, then think of it as a way for objects in different processes or machines to interact with each other (almost) as if they lived in the same process. For example,

StockQuotes stockQuotes = new StockQuotes();
double ibmPrice = stockQuotes.GetLatest("IBM");

In this example, the StockQuotes object could actually be running on a different machine. In .NET, all you have to do is make the StockQuotes class extend a special system-provided class, and then add a configuration file to the server .exe and the client .exe. The rest is "magic"--you can even use ordinary constructors.

Note that unlike Java RMI, you don't have to declare an extra interface, run an extra compilation step, etc. It all just sorta happens behind the scenes...

Just another name

[tobybuk]

Please people, don't get too excited. This technology has been around for many years in different forms. RPC, DCOM, etc. It's nothing new really, just the same ideas dressed slightly differently.

What .NET Remoting is

[damieng]

In a nutshull;

Remoting is the .NET equivalent of a Java's RMI.

This means you work on an object in your local address space but the object you are working with is in fact sending off your method calls to the real object elsewhere (another machine, another address space, whatever) that performs the necessary operations.

In .NET this interaction between the two objects can either use a binary protocol or SOAP.

A comparison of .NET Remoting vs Web Services can be found at http://www.developer.com/net/net/article.php/22017 01

Re:Especially in the fog of marketese that is .NET

[matchlight]

I agree with your RMI analogy to Remoting, that's pretty much what it is.
But as I disagree with the author that Remoting is usually best, I disagree that Web Services are much better way to go.
No offense, it's just that each part of the MS distributed programming elements of .NET are each good for different reasons.
Remoting: state and stateless, local and remote object calls for security
Web Services: stateless, designed for heterogeneous environment
COM+: pooling, jit activation
MSMQ: not a runtime but a message service built into .NET, queuing designed for asynchronous calls
ADO.NET: data access driven, built in SQL support, can be modified for other purposes.

These are just a few things to show the differences. These differences tend to define what problem they are best suited to solve.

Re:I'll tell you what he suggests...

[tedgyz]

Ironically, I have witnessed something close to what you describe. I work for a company that has a HUGE India workforce - roughly 1/3 of the company. The company was founded by an Indian, so I can't bitch too much. :-|

Anyway, India was initially used for data gathering, which involved taking large catalogs and entering the data manually. To speed this up they would scan the catalog pages and view them electronically.

When PDFs starting entering the process, guess what they did. This is no joke...
Print PDF -> Scan printed pages -> View scanned pages -> Enter data manually

All of this India outsourcing is going to come full circle when the (rotten) fruits of their labor become apparent. As a Software Engineer in a 1/3 India-labor company, I am not afraid. Sure they can pay 4 of them for 1 of me, but the mythical man-month applies here. The sum of the parts does not equal the whole.