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.
Isn't this the same as Java RMI?
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
.NET Remoting
I already emailed the editors about it, techguy hasnt posted from what I can tell ever before, and his user id link leads to a web page selling a book. I dont know how this made it up as a post, but its obvioously an infomercial. I realize that /. is a much bigger beast than when I first started reading it 6 years ago, but I never thought I would see shiate like this
dimes
oh, never mind.
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!
.Net remoting is basically a method of sharing objects between applications and/or processes that is independant of the transport. In other words, you would use it to build an application in which various portions of the application could reside on different computers, on an internal or external network (though it should be noted that it could all reside on one computer as well, and the application wouldn't care).
One application or part of an application requests a remotable object from another application (or part of the application) and that application 'remotes' the object, sending it to the other application either on the same computer or over the network.
-PainKilleR-[CE]
Ref: Amazon has this book for $5 cheaper than bn and with free shipping.
... would it have killed ya to explain what ".NET remoting" is, exactly?
It's another lousy product pushed onto the world by a monopolistic software company. Happy?
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...
Airzooka Remoting
Who could have seen that one coming? =P
Would someone please review either a flawless book or even one that is below above-average?
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.
Sure would be nice if the review happened to mention what .NET remoting is.
Also why it's so important that a book was written about it.
Is NetRemoting anything like BackOriface?
Trolling is a art,
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.
OK this .NET remoting doesn't use XML but what does it use? Some secret MSFT protocol?
In other words you mean it's just like good, old-fashioned RPC.
"Only in their dreams can men truly be free 'twas always thus, and always thus will be."
--Tom Schulman
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
So is this what they are calling Passport account cracking, now?
Healthcare article at Kuro5hin
Wow. It's a troll, but for once it listed a person who actually died.
FYI, .net remoting is the sucessor to DCOM.
.NET framework. Think RMI/Corba for java.
Basically it is RPC related to the
Bye!
Buy his book already! He's had to live his life named "Ingo Rammer"! Where's the love?!
.NET remoting? Isn't that, like, patented or something?
Tired of FB/Google censorship? Visit UNCENSORED!
And if the stuff behind the scenes breaks, then you're up a creek and don't know why. I'm glad MS hasn't deviated from their design methodology. "I'm sure a reboot and/or re-install will fix it..."
the good ground has been paved over by suicidal maniacs
The guy is a bit obvious in the way he consistently uses the term ".NET remoting" everywhere. I also suspect he deliberately didn't tell us what remoting is so we'd go find out.
FWIW, now I know, so I guess he succeeded in his efforts. That bastard!
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
Your trash pick up day next week will be the same as this weeks.
So what.
Um, dude, the "editors" have long ago announced that they sell about one front-page story per day. Did you think the stories about ThinkGeek's latest gadgets or the newest silent-harddrive product were grassroots submissions?
[
Ingo Rammer? Come on, this one is just too easy...
There's a growing sense that even if The Future comes,
most of us won't be able to afford it.
-- Lemmy
Which has a better API? Higher performance? More reliable? Easy to develop/debug? Most developers will avoid using RMI directly if they can, lots of J2ee stuff uses it underneath the interfaces though.
TallGreen CMS hosting
Doesn't this just boggle the mind? Why would Slashdot talk about .NET? Don't we want this technology to be swept under the carpet like so much XBOX?
*sigh*
I suppose it's news for nerds. I guess the MS nerds are the ones that shouldn't inhierit the world.
Remoting is faster, because it is [can be] binary. Web services have a huge overhead, because all objects are sent in XML. So a simple object will be sent as
.NET-native, so you have more flexibility - you only get basic object features (polymorphism for instance doesn't work with .NET web services). Remoting lets you forget about the boundaries to a much greater extent.
For binary you can reduce, say FirstName down to 1 byte (rather than 9). XML required for web services will typically be at least twice as bulky.
In addition, remoting is
In fact, unless you have a good reason to use Web Services - that you will *definitely* be integrating the whole program with non-.NET legacy software - you shouldn't use it. Even if you need Web Services for a small part of the app, use Remoting for the rest of it.
You know, I had to do a project with .NET Remoting, and none of the documentation or samples in MSDN make absolutely any sense. I started searching newsgroups and whatnot for answers to my questions and Ingo had pretty much all of the answers. I got a copy of this book, and it was more of the same. His sample code was clean, understandable, and unlike most everything else out there it worked!
Anyway, yeah. Ingo rules.
...just to use all the remote (RPC and other) exploits?
For the love of $DEITY, loose != not win!!!!!
that Inga Rammer is kin to Dirk Diggler?
vbRad.com has another review of this book:
d va ncedRemoting.htm
http://www.vbrad.com/pf.asp?p=Reviews/books/brA
Parent is a troll
OH THE SHAME I fell off the wagon and use sigs again!
Well at least noone has started a dishonest ".NET is dying" like they did with BSD, the other wildly successfull technology that tech-weenies love to declare deceased so they won't have to deal with it. (I just want my linux and my java...anything else is bad!bad!bad!...Mommmmy!)
If it were done when 'tis done, then t'were well it were done quickly... MacBeth
There is a new law which, when it passes congress, will require that you DEFINE WTF ("slang, What The Fsck") an SMS ("Stupid Marketing Speech (TM)") acronym or buzzword actually IS within the first 100 words of any document describing a technology.
It's obvious that common courtesy doesn't work, nor did any of you pay attention when you were forced to take that technical writing class in college. Soooo, a law is required.
".NET remoting" means absolutely nothing to those of us who don't spend 25 hours a day in Marketroid Communion, and thus don't have every industry buzzword downloaded directly into our cerebral cortex with each new press release.
It's not an issue. When using webservices, you are bound to use the XmlSerializer, or better: please the XmlSerializer. It will generate XML from your objects, and often fails to do so because it can't deal with interfaces for example. Also, serializing objects to the client via xml webservices is not the right thing to do: what if that client isn't a .NET application? It then can't deserialize your object anyway. So Webservices are GREAT when communicating DATA in a standarized format in XML. Not Objects. So remoting isn't an option for these situations anyway.
.NET (thus client and server are both written in .NET) are using webservices because they think it's best. For THESE people remoting is better, because both sides are .NET and thus can deserialize objects directly or work with marshalled objects remotely. Therefore, for these setups it's not an issue being locked into a single vendor's universe, because client and server are already of that vendor.
However, a lot of people who want to write a distributed application with
Never underestimate the relief of true separation of Religion and State.
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
This book has been out for ages, and though it was groundbreaking at the time, (and Ingo Rammer is now firmly established as a .NET Remoting Guru) time has moved on and there are more (and better and cheaper) books on the market.
I.e. this post is not especially timely...
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.
Speaking of marketing, today my college's local .NET User Group (NUG) is/was apparently having meeting today and the NUG was advertising the hell out of it. There were fliers everywhere and they took the time to write directions to the meeting on some sidewalk with chalk. And it wasn't a simple message like "NUG meeting this way -->". It was essientially their flier "HACKED! Learn about network security in ..." or something like that.
.NET.
Anyway, I think there is a marketing conspiracy for
What do you suggest we use instead?
VOS/Interreality project: www.interreality.org
"Remote" is an adjective (or sometimes a noun, if you're referring to the TV variety).
It is not a verb.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
He suggests a new Open Source Remote Computing Transport technology professionally and appropriately named GSquimp that combines Cutting edge and legacy technology to create a stable series of component communication layers.
It looks like this:
UserInput -> LPT1 -> Printer -> Paper -> Envelope -> USPostalService -> IndiaOutsourceWebProvider -> 30CentPerHourTechnician -> Eyeballs -> stdin -> ServerApplicationQuery -> Aha! -> stdout -> Eyeballs -> 30CentPerHourTechnician -> IndiaOutsourceWebProvider -> USPostalService -> etc... etc...
First you must tell me the problem. Problems using remove object technologies can often be solved in much simpler ways.
For example, I had a need for a very simple remote procedure call in a past job. It was only one procedure with fairly simple inputs. I didn't want to suffer the pain of Corba. Instead, I wrote a simple socket interface and protocol to send the requests. The cost of coding that solution was less than the cost of learning and deploying Corba, as well as forcing users to deploy Corba as well.
Why bring in a 10-ton coal-mine dumptruck to haul a shovel-full of sand?
"No matter where you go, there you are." -- Buckaroo Banzai
The book was a decent reference, for it's time.
.NET framework that some of the examples in the book will no longer work. Fortunately, Ingo has some comments about that on his website:
. html
Note that if you are using the 1.1
http://www.ingorammer.com/remotingFAQ/changes2003
This is a really sorry review for what is considered the .NET Remoting "Bible". Ingo Rammer is considered THE authority on remoting, and his book really describes the subject like no other text currently on the market. If you want to know anything about this topic, buy this book!
-jerdenn
yeah that's the problem.. it's supposed to be EASIER to slap a pre-made RPC system onto your program, but it's usually easier just to invent something close to your problem domain.
though I have had good luck with XML-RPC on open source, somewhat plug and play, but only for lightweight XML stuff (i.e., query server with a small piece of data like a MAC or IP address, get response which is a small XML document to begin with).
This is actually a book that has been around for the while and the author is a bit of a celebrity. Anyone that is going to do anything serious with
The best stuff is in the back, how you can plug in your own protocols. IIRC he does a distributed object call using a SMTP as a protocol. Interesting stuff.
The performance advantages of
I'd say to the people used to doing sockets in C, well, you missing the boat.
This is my sig.
Web services can be scaled. Check out what bluetitan (http://www.bluetitan.com) is doing for managing web services. You route web service calls through the Blue Titan rounters and switches and you can scale by simply adding new end points. This is a much better solution to scaling web services than .Net approach, which is not scalable.
Web services can be scaled and Blue Titan Softare is doing it. Check out what bluetitan (http://www.bluetitan.com) is doing for managing web services, such as routing web service calls through the Blue Titan routers and switches and you can scale by simply adding new end points. You can deploy web sercvices to multiple endpoints, do provisioning, etc with this flexible framework. This is a much better solution to scaling web services than .Net approach, which is not scalable. Sony, UCSD Super Computing center, etc are using this stuf.
That's it. I'm changing my name to Ingo Rammer.
Troll. Ha! That's funny. You really think there aren't going to be any security holes with .Net remoting? Who are you kidding?
-----
Web Hosting @ HostForADollar.com
I've been doing a ton of benchmarks at work to test the scalability of webservices using SOAP and the scalability sucks ass. That theoritical 5-10 isn't just theoritical. From first hand experience, it's atleast 5x and closer to 10x. The situation gets worse as messages exceed 15K. MS webservices using SOAP sucks in the scalability and shouldn't be considered for anything remotely important. It's fine for syndicating someone's blog, but not for real business applications.
The learning curve is a lot shallower for .NET remoting than for doing CORBA, especially if you just want to do relatively simple things. I think it might actually be quicker to develop simple requests with .NET remoting than sockets, and you get to avoid the error proneness of marshalling your own data.
-- Will quantum computers run imaginary-time operating systems?
Sheesh people, save your thunder for when M$ really does something bad.
I read this book cover to cover over a year ago when I started a .NET Remoting project and it allowed me to gracefully solve some interesting problems in our implementation. I'd definitely recommend it to someone with past RPC development experience that is getting ready to take on .NET Remoting.
.NET Remoting is - it's very similar to Java RMI only the framework is more extensible (thanks to features like custom client and server sinks and stuff). Also, you have the option of hosting your Remoting components inside of IIS so you get SSL encryption and stuff for free (undoubtedly at the cost of having to deal with IIS security problems :) without changing any of your code - just a couple of configuration options.
There are probably other good books on the subject available now (like I said, I read this one over a year ago), but this one is definitely a winner.
For the people asking what
-Zak
To whoever wrote that title -- You might want to acquire another book "2nd grade grammar" It's quite usefull, just to make sure you stop verbing your nouns.