Slashdot Mirror
Advanced .NET Remoting
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
- Introduction to Remoting
- .NET Remoting Basics
- Remoting in Action
- Configuration and Deployment
- Securing .NET Remoting
- In-Depth .NET Remoting
- Inside the Framework
- Creation of Sinks
- Extending .NET Remoting
- Developing a Transport Channel
- 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.
... would it have killed ya to explain what ".NET remoting" is, exactly?
Jeez.
There are plenty of ways to "remotely access" a .NET system...too bad Microsoft keeps patching them away.
The way Microsoft will control your TV set.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
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.
The phrase ".NET remoting" appears twenty-two .NET remoting times in this review of .NET remoting while the simple, one or two sentence, .NET remoting-compliant explanation of what .NET remoting is, what .NET remoting does and why the .NET remoting I would want to know about .NET remoting and how .NET remoting would meet my .NET remoting needs (which include .NET remoting for customers who require .NET remoting, as well as .NET remoting) appears to be missing.
.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.
Pimpin' all the Karma Hoes!
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,
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...
I can't believe it!
Say it isn't so!
include $sig;
1;
So far I've not seen even one windows worm that uses ".NET Remoting" to spread.. Is it being used at all??
SCO employee? Check out the bounty
My eyes went cross for a minute and I read, "Advanced .NET rooting". I thought, "great, another round of critical patches to install this week".
I used to wonder what was so holy about a silent night, now I have a child.
".NET remoting is often a more appropriate solution than Web Services, and it certainly performs better and scales better when used properly."
.NET remoting in those situations for which it was designed. Back to you, Timothy.
This just in: software works better when used correctly. In related news, analysts say it is appropriate to use the tool known as
-theGreater CheekTonguer.
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.
Well, he's not selling the book he's reviewing!!! I'm not sure I see the problem here. Authors of books in a particular field can't post a review of anything similar?
eh?? it's a decent review of the book in question (save for the fact that he never actually says wtf .NET Remoting is, or why anyone would be interested in knowing more about it.).
he doesn't mention the book he's selling in his user id link AT ALL. don't click on the user id links if you don't want to know what he has to say about himself (I sure as hell didn't.) by that standard your "fallenbit.com" link is a "sleazy infomercial advert"... only with no interest to anyone anywhere.
unbunch thy panties, please.
Published in July 2002...now this is news? I guess we have to suffer with these infomercials instead of popups...or are those next too?
In a nutshull;
.NET equivalent of a Java's RMI.
.NET this interaction between the two objects can either use a binary protocol or SOAP.
.NET Remoting vs Web Services can be found at http://www.developer.com/net/net/article.php/22017 01
Remoting is the
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
A comparison of
[)amien
I agree with your RMI analogy to Remoting, that's pretty much what it is. .NET are each good for different reasons.
.NET, queuing designed for asynchronous calls
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
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
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.
I have a couple of questions. "...... then quickly moves on to more specifics, entirely focused on generous code examples (which actually work....." Is that a feature of the book? -This is obligatory for Tech-Literature (if it wants to be taken seriously). "Ingo's goal is for you to really understand how the .NET Framework implements remoting."
Does anyone here refer to authors (which they respect) by their first name?
-It rather seems to me, that TechGuy949 is doing a friend a favor, promoting his book.
"......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."
Im sorry, but if these are the key features of .Net remoting, i dont see anything new, or extraordinary about it.
greets DaisyCutter.
... except with new and unpatched security holes ...
-----
Web Hosting @ HostForADollar.com
The point that was missed was that the problem defines the solution. Argue all you want that Remoting should be used and I can give you an example when it shouldn't or can't. That's why there are so many distributed programming methods.
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.
"No matter where you go, there you are." -- Buckaroo Banzai