Extending .NET Remoting

If you use .NET Remoting then you no doubt know the name Ingo Rammer.  Ingo's book is to Remoting what David Sceppa's book is to ADO.NET.  I was fortunate enough to receive a few advance chapters of the Second Edition and I'm totally impressed.  Apress is doing some really wonderful work and I think I'm 1-1 on Apress books I read vs. Really Loved. 

The chapters I read are on Extending .NET Remoting.  When I first came across it in Ingo's first book - I kind of chickened out.  That's really the only word for it unless you want to get crass.  I had some nightmare experiences with DCOM and Windows DNA and it left me with a bad taste in my mouth.  So I shyed away from Remoting totally - until I moved to TiBA and under the tutelage of Phil Hunt - learned that there's more to fear by not using Remoting then there ever is by using it.  Phil and a few of my other co-workers really helped me out at first, and Ingo's book was always there to help me understand the theoretical aspects of why things worked the way they did (or in my case - why things didn't work the way they should have).  So when I started reading about writing my own sinks - my inner chickensh1t came out and I came up with 1000000 rationalizations on why I didn't need to bother with such stuff quicker than you can blink.

However that is a quirk of my personality - I am quick to write stuff off if I don't think I can get it - and then immediately I start telling myself what a pu55y I'm being and usually end up going gangbusters on it.  This happened with Remoting big time.

I don't want to delve too far into the subject without checking with Apress first but since he's touched upon all of this in the first book - I don't think it's a big deal. 

Let me start out with an analogy.  Most of us know a 'know it all' programmer who is all about the latest greatest thing.  They usually are the first out of the gate on anything that appears in MSDN Magazine or Slashdot and they usually have some degree of talent.  More often then not though - they are usually what my friend Caustic Phil refers to as Blunderman (Incidentally - if you were wondering why Phil doesn't blog much anymore I have the answer.  His wife is a Goddess and they are newlyweds - you can do the math).  These are the types of folks that can recompile their kernels (or so they tell you every day) but can't seem to get away from overwriting array boundaries or putting exit conditions in their recursive algorigthms. 

Well, being able to Remote an object from one machine to another is worth about the same as this if that's as far as your Remoting game goes.  You'll definitely sound like a big shot at User Group meetings.  You'll definitely have all of the VB6 guys who've just come over to .NET oooohing and aaaahing over your game.  You'll definitely be able to criticize any architecture that isn't real n-tier and intimidate folks that are pure client/server types.  But if you don't look further into learning Remoting, you'll basically be a lot of hot air with a good parlor trick.  If you Read Ingo's book though - you can save yourself from this fate.  Remoting, just like Web Services, is great for tasks that it was designed to do.  It can be very easy to implement and can work wonders for your apps with very little effort in some scenarios.  It's precisely because it's usually so easy to get up and running that it can make you think you're better at it than you really are.  In many instances, you may design a really complex architecture that looked really cool in Visio - but is sluggish and unresponsive in practice.  At this point - You will NOT LOOK GOOD No matter how much Buzzword Bingo you play.  In order for Remoting (or anything else) to be of value, it needs to provide functionality that wasn't there before, or greatly enhance what was there while making it easier to develop and debug.  My point is simply that in and of itself, no technology has value.  It's value totally resides in your ability to solve problems with it and ostensibly do it in a better way than was done previously.  And just like threading - Remoting can SAVE the day in many scenarios - but if you don't understand what you're doing and why it's working the way it is - you're likely to be headed for trouble.  Fortunately, these disasters are largely avoidalbe if you do your homework.

So why would you want to extend remoting? (I'm paraphrasing from Ingo's first edition - page 249  - Chapter 9)

• Compression/Encryption
• Passing additional information.  In my opinion - this is one of the more important cases.  Ingo uses the example of passing the client-side thread priority to the server so they can both be performed using the same thread priority.
• Extending the look and feel of .NET Remoting.  He mentions using a Per Host authentication model vs. a per object model.  This seems to be one of the weaker arguments IMHO but I'm not really qualified to write it off.  It just seems from what I've been exposed to, that this is a solution that adds a fair deal of complexity without an equal amount of value - at least in most of the cases I've come across.  Again though - my experience with Remoting started in August of this year so there's a good chance I just haven't run into a scenario where this would be a big issue
• Debugging your apps and sending the message contents to the console window or a logger.  This is not something I'd want to do on a application by application basis,  but building some internal components that will be reused over and over makes this well worth doing IMHO.
• Custom Sinks and Providers.  Well - you saw how I went gaga over Sahil's MSMQ Data Adapter or N Software's ADO.NET Provider which can read RSS Feeds for instance.

Of the lot, I think the last one is the most cool/fun but probably not the most necessary - there's plenty of native support to push things back and forth over the wire as they stand now.  However changing things over to a MSMQ implementation could definitely be useful in more than a few cases - and hopefully over the holidays I'll have some time to work with it a little more.

The most practical IMHO regards Compression/Encryption and Debuggging.  I've worked through his Encryption/Compression example originally and then through what was done on the updated work.  It's pretty straightforward to get working - and unlike a lot of other remoting stuff - I got it working with very little hassle.  I think that's mainly because the real 'bitch' of remoting is getting everything right in your configuration files ;-)  To use the Compression example, you need to use Mike Kreuger's SharpZipLib which is pretty helpful - or if you want to be a little more ambitious - you could write your own. He runs through a comparison/proof -of-concept that illustrates a pretty dramatic decrease in size once you use the compression sink - and if you chose to do it in Binary you'd see even more of a difference.

To get this part working it'll take you about 20 minutes to an hour assuming you are somewhat familiar with Remoting Configuration and Remoting in general.  However the Encryption section is what really rocks.  It's definitely a more complex area and something you need to put a little more thought into - but it's covered in a component based way - so once you  write it once - you can reuse it all over the place - an investment of time I think is well worth it.

Instead of regurgitating everything, I should probably finish up the encryption piece and walk through it.  I give you fair warning - covering some of the more advanced areas of Remoting makes you quickly realize how much power you have with it - and that power - can be as addictive as crack.  (Something tells me that when i finally fall asleep around 4:00 am - I realize how addicitive Remoting really is).