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.
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.
I can take a guess...
.NET remoting is the new name for DCOM. They changed the name to lure a bunch more unsuspecting saps into using their pointless technology.
.NET-bashing, I feel the same way about EJBs.
For roughly 10 years now I've seen the promotion of remote object technologies. The pain and suffering they inflict is almost always greater than the supposed benefits.
In case you think I'm just
"No matter where you go, there you are." -- Buckaroo Banzai
Lots of reasons why I want .NET to fail and fail badly
.NET "rebuttal" that I linked to above, "For non-profit use VS.NET can be had pretty cheaply, especially if you know anyone that is in college somewhere." Pretty cheaply? For a non-profit (that means charities, churches, universities, the hobbiest who is going to give away his work for FREE)... pretty cheaply? Wow. That is well and truly pathetic. To try and justify it, and say, oh well, you can try to scam an educational discount so it won't be so dear, is even more pathetic.
.NET commercials with William H. Gacy telling you how great it is without really ever telling you anything about it? Microsoft doesn't trust .NET to stand on its own technical merits and it knows it may go like cod-liver oil down the gullets of a lot of people who have seen how the company works behind closed doors even if it were the tech shiznit.
It's benefits a criminal organization. Not one that's been found guilty of crimes once or maybe twice, but lots and lots of times. Those crimes are many and varied, but here's just a few of them: Stac Electronics v. Microsoft, DOJ v. Microsoft, Sun v. Microsoft.
P.S. If you want to split hairs, Stac v. Microsoft isn't a criminal action, it's doesn't stem from a criminal abuse of their monopoly like the other two cases. Instead it was just a case of a small company being driven out of business by willful patent infringement, theft of trade secrets, etc.
Microsoft isn't just one thing anymore. It's too damn big for that. I'm sure even Bill himself knows better than to think that he truly controls the whole ship because it's become big enough that he can't possibly know all the projects, people, etc. anymore. But even a really large company still has a kind of collective personality that it exudes and a large part of the personality both internal and external to Microsoft for many years now is that of a total control freak.
If they don't own it, if they don't control it, if they didn't create it, if it doesn't have a broad stamp from Microsoft on it, then they don't want it. Sometimes it's sufficient for the thing to merely exist and they'll refuse to acknowledge it, other times they need to actively stamp it out because they can't control it.
When was the last time you can remember Microsoft saying they supported a standard? That is, not something they invented and submitted a RFC for, an actual, take it off the shelf and re-implement it without renaming it or "improving" it so it doesn't work with anybody else standard. C++? Basic? HTML? A video or audio codec? Java? Anything?
I'm sure there's something, somebody will point out their excellent support for TCP/IP or something and I'm sure that's true. But if you were to look at Microsoft as a person in your life, you'd wonder what was wrong with him or her such that so much had to be controlled by that person.
When your business is selling the operating systems that 90+% of everybody uses, software development tools should not be a profit center.
Why should I have to plunk down a couple of thousand dollars for a "universal subscription" in order to have access to compilers and basic development information? Sun doesn't have to do that? On this point I'll quote from the
Marketing. Have you been "lucky" enough to catch one of the
So they are going to pull a page out of Intel's bum-bum-buh-bum "Intel Inside" playbook and try to sell the brand like it's sneakers and cola. Trust us, you'll look cool if you use it, and we'll keep hammering the brand on TV so somebody who doesn't have much tech savvy in your organization will ask you if you are using it, or have plans to port to it, or whatever, even if he hasn't got a clue what "it" is in this case.
They don't trust you. They don't like what they can't control and they can't control you. They can try and they always will keep trying but ultimately you are going to see them keep trying to do things and always keep a step
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.
Why am I not shocked that the *nix bent of this website (sadly) marked this as funny whereas if it was a joke about *nix it would have been marked 'troll' or 'irrelevant.' (As this post will surely be.)
Zealots suck...
Loading...