Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Microsoft Books Media Programming Book Reviews IT Technology

Advanced .NET Remoting 171

Posted by timothy from the at-a-distance dept.
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.
This discussion has been archived. No new comments can be posted.

Advanced .NET Remoting More

Advanced .NET Remoting

Comments Filter:

  • Especially in the fog of marketese that is .NET... (Score:5, Funny)

    by Jim Morash ( 20750 ) on Wednesday October 22, 2003 @11:47AM (#7282047)
    ... would it have killed ya to explain what ".NET remoting" is, exactly?

    Jeez.
    • The way Microsoft will control your TV set.

    • Re:Especially in the fog of marketese that is .NET (Score:1, Informative)

      by Anonymous Coward
      .NET Remoting [developer.com]

    • Re:Especially in the fog of marketese that is .NET (Score:5, Informative)

      by mikera ( 98932 ) on Wednesday October 22, 2003 @11:54AM (#7282093) Homepage Journal
      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.
      • 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 b
        • 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

          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 .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 boun

    • Re:Especially in the fog of marketese that is .NET (Score:5, Informative)

      by AlabamaMike ( 657318 ) * on Wednesday October 22, 2003 @11:58AM (#7282117) Journal
      .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.
    • .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

    • Re:Especially in the fog of marketese that is .NET (Score:1, Funny)

      by Anonymous Coward
      ... 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?
    • 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 thi

    • .NET remoting is Microsoft's latest exploit goldmine.

    • FYI, .net remoting is the sucessor to DCOM.

      Basically it is RPC related to the .NET framework. Think RMI/Corba for java.
    • 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.

      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 .NET-bashing, I feel the same way about EJBs.
    • .NET is shorthand for .NET Framework, which is essentially a Virtual Machine and standardized API like Java. MS tends to append ".NET" to anything thats deployed supporting any .NET Framework applications.

      .NET Remoting is the MS equivalent for Java RMI, except that instead of making function calls only binary, they allow serialization to XML and greater control over instantiation of objects. The XMl serialization is important because it allows third party applications running on non-MS OSes to inter-op

  • .NET remoting? (Score:5, Funny)

    by Anonymous Coward on Wednesday October 22, 2003 @11:47AM (#7282049)
    There are plenty of ways to "remotely access" a .NET system...too bad Microsoft keeps patching them away.

    • Re:.NET remoting? (Score:2, Insightful)

      by Assmasher ( 456699 )
      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...

  • Equivalent in Java? (Score:1, Informative)

    by Anonymous Coward
    Isn't this the same as Java RMI?

  • .NET? book review?! on /.?! (Score:3, Funny)

    by GillBates0 ( 664202 ) on Wednesday October 22, 2003 @11:51AM (#7282072) Homepage Journal
    did hell just freeze over?

  • This is a sleazy Advert (Score:1, Informative)

    by Dimes ( 10216 ) *
    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
    • 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?
    • I dont know how this made it up as a post

      Did you stop to think that maybe it was a 'good' book review? (by slashdot standards)
      • I dunno. On the surface this looks like a good review, but enough factors are there to suggest that this is, indeed, a somewhat underhanded advertising tactic. I used to work at an online shopping site that did this sort of guerilla marketing all the time.

        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!

    • Re:This is a sleazy Advert (Score:5, Interesting)

      by nehril ( 115874 ) on Wednesday October 22, 2003 @12:23PM (#7282286)
      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.
      • When I click on your id(nehril) or on mine(dimes) I get /. comment/journal page for that user. Gives me a sense of whether or not the person has any histroy at all with slashdot. Whether its one post or 1000 posts, it lets me know that they are a real person(at least to some vague degree(heck even by your id# I know you have been arround for 3 to 4 years now). When you click on this submitters user id(TechGuy949), I get a page pushing a book. Not even their own personal website or what not, a page pushing a
        • Actually I take that back, I missed a digit on you id #, so I don't have any idea of how long you have been arround. Though considering that /. id's appear to be well past the 700k mark, I would still guess you to be from arround 2001 or so. Blind guess and all.

          Dimes
    • If it's really an ad (I don't see it that way), then I hope its paid for.

      If so, then great! It's an innovative way to earn income, with only marginal (IMO) impact on the quality of the site.

      It's not like /. all of a sudden sucks.
    • 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?

  • Hmm. (Score:5, Funny)

    by Minwee ( 522556 ) <dcr@neverwhen.org> on Wednesday October 22, 2003 @11:58AM (#7282115) Homepage
    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.

    • Re:Hmm. (Score:3, Funny)

      by kfg ( 145172 )
      You can acquire that information by .NET remoting money from your wallet to bn.com who will .NET remote you the book.

      Pretty good .NET remoting marketing scam, eh?

      In fact, I have a sneaking suspicion I've just answered your qestion as to what .NET remoting actually is.

      KFG

    • NewsFlash (Score:5, Funny)

      by theGreater ( 596196 ) on Wednesday October 22, 2003 @12:11PM (#7282229) Homepage
      ".NET remoting is often a more appropriate solution than Web Services, and it certainly performs better and scales better when used properly."

      This just in: software works better when used correctly. In related news, analysts say it is appropriate to use the tool known as .NET remoting in those situations for which it was designed. Back to you, Timothy [monkey.org].

      -theGreater CheekTonguer.
    • I had the same impression, and I figure this is either just tricky marketting as others have suggested, or since the book actually explains what it is, the author was reluctant to give out the contents of the book for free.

      Similarly, how many book reviews say "Java is a programming language intended for cross platform compatibility"
      or
      "Apache is a webserver"
      or

      See my point? If you wanna know what it is, google it [google.com].

  • Undocumented? (Score:4, Funny)

    by Linux_ho ( 205887 ) on Wednesday October 22, 2003 @12:04PM (#7282177) Homepage
    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!
    Whaaaaaa? A Microsoft API with incomplete documentation?

    I can't believe it!

    Say it isn't so!
    • .. that it's internal and NOT part of the API. If I describe the internals of Linux device driver, warn you that that internals may change in the next release, but that the user won't see the difference, there's nothing bad about that. Same thing.

      Sheesh people, save your thunder for when M$ really does something bad.

  • But where are the applications? (Score:5, Funny)

    by wfberg ( 24378 ) on Wednesday October 22, 2003 @12:07PM (#7282203)
    So far I've not seen even one windows worm that uses ".NET Remoting" to spread.. Is it being used at all??

  • Advanced .NET rooting (Score:3, Funny)

    by CyberGarp ( 242942 ) <Shawn.Garbett@org> on Wednesday October 22, 2003 @12:07PM (#7282204) Homepage
    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".
  • 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?

  • Just another name (Score:4, Informative)

    by tobybuk ( 633332 ) on Wednesday October 22, 2003 @12:12PM (#7282239)
    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's new is the highly "pluggable" nature of remoting in .NET. Just because the concept isn't new doesn't mean there isn't value in explaining or investigating a particular implementation. Hell, how many OpenGL books are there? For that matter, how many on Java Remoting? It's a complicated subject which you aren't just going to automagically know everything about simply because you are familiar with DCOM or some other type of remoting.
  • OK this .NET remoting doesn't use XML but what does it use? Some secret MSFT protocol?
    • No.

      ".NET Remoting" is fairly broad. It covers everything from Web Services down to old fashioned RPC. The protocols you can select from for your purposes include (but is not limited to) SOAP/XML down to a binary protocol for higher performance.
    • OK this .NET remoting doesn't use XML but what does it use?

      I believe it does use XML/SOAP as one of the options.

      It also has an option to use binary protocol for efficiency if XML is too slow for you. Not sure whether it is secret or not, but this one is proprietary.

    • The data serialization format is pluggable. Out of the box, you may use the binary serializer, the xml serializer, or the soap xml serializer. Or you may write your own.
  • 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?

  • What .NET Remoting is (Score:5, Informative)

    by damieng ( 230610 ) on Wednesday October 22, 2003 @12:31PM (#7282324) Homepage Journal
    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
    • How is .NET Remoting any different from DCOM, is my question.
      • .NET Remoting is obviously a lot newer and fits in with Microsoft's .NET strategy but it's a lot less mature than DCOM.

        There is no support for transactions, load balancing or object pooling in remoting - all were all present in DCOM.

        At least remoting has the SOAP option - anyone who's ever tried to get DCOM working through a firewall will give that a thumbs up.

        No doubt it will gain DCOM's missing features in time.
        • 1. True, but remoting learns a lot from DCOM's mistakes.
          2. Not entirely true, if you consider System.EnterpriseServices.ServicedComponent (aka COM+) or the BYOT option.
          3. There is an http transport for DCOM.
          4. If you stipulate #2, what missing features remain to be gained?
      • 1. The wire protocol and the data serialization format are decoupled from the remoting mechanism - ie you can do remoting using the xml formatter over msmq, or the soap formatter over http, or you can use the binary formatter over tcp, or you can use [your custom formatter] over [your custom channel].

        2. It can be DCOM, but it doesnt have to be.
    • I've read about .NET remoting and maybe I just don't know the subtleties enough but it seems to me to just be a wrapper for SOAP and a different transport protocol option ( the binary one ). I've used SOAP in the past and even found it a little over the top. Most of time when I have RPC type stuff to do I just use XML-RPC. It's so simple and small.

      I use XML-RPC to bridge programs like getting a C and Java program to communicate across the network and even on the localhost and soon i'll be using it with C
    • .NET is equivalent in functionality to RMI but, IMHO, it seems to be more complex to use than RMI. Perhaps that makes it more flexible but having to register a service type (instead of using a common interface) and having to register a channel (instead of doing a lookup into an RMIRegistry) makes using .NET especially onerous after using RMI.
    • More to the point, .Net remoting is much like RMI which is much like Corba RPCs which is much like NIDL (Network Interface Definition Language) RPCs from Domain/OS circa 1985. In fact, Corba was directly based on Apollo's work on NIDL which was bought by HP. .Net and RMI may have developed independantly, I'm not sure, but the ground work for all of this was mid-80s technology.

      Domain/OS was so far ahead of its time, that even today most UNIX-like systems cannot profide some of Domain/OSes features (e.g. a t
    • 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.
      Not completely true, you can also use remoting and work with the objects by value. This means that the object is created on teh server, marshalled by value to the client, there it is for example filled with data and then marshalled back to the server by

  • Pardon my scepticism, but.. (Score:3, Insightful)

    by daisycutter ( 714815 ) on Wednesday October 22, 2003 @12:50PM (#7282458)
    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.

  • Poor guy... (Score:1, Funny)

    by Anonymous Coward
    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?
  • Ingo Rammer? Come on, this one is just too easy...
  • 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.
    • If performance on the one of the platforms .Net runs on is important to you, YOU would do well to properly test scenarios important to you on those platforms, in both Java and .Net. If portability to arbitrary platforms is important to you, then .Net is out of the picture. If you currently posses either .Net or Java expertise, you would likely be wise to leverage that expertise to craft more efficient designs than to rely on one rmi implementation vs another.

      Repeat after me: there is no silver bullet.
  • 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?
  • that Inga Rammer is kin to Dirk Diggler?
  • vbRad.com has another review of this book:

    http://www.vbrad.com/pf.asp?p=Reviews/books/brAd va ncedRemoting.htm
  • In actual fact, .NET remoting is often a more appropriate solution than Web Services,
    I would dispute the characterization of this statement as a "fact". .NET remoting locks you into a single operating system vendor, which for many developers outweighs any technical advantages it may have.
    • 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.
      • It is an issue, and you haven't contradicted what I wrote.
        • You wrote that it forces you into using .Net for both sides and that's a problem. The person who replied to you wrote that it doesn't really matter, because both ends were going to end up being written in .Net anway.

          Seems to me like he did a pretty good job of contradicting what you wrote.

          But if that isn't enough, I'll go one further. The .Net remoting mechanism is pluggable. You can write code to perform remoting via RMI, so the other end of your .Net code can actually be written in Java.
          • If I have a choice between developing a system using .Net and .Net remoting, or a system using web services, I'm going to build the system that does not tie me to a single software vendor, and that will not be the .Net solution.

            The .Net remoting mechanism is pluggable. You can write code to perform remoting via RMI, so the other end of your .Net code can actually be written in Java.

            If I wanted to waste a bunch of time developing my own infrastructure, I wouldn't use either .Net or web services.

            • In other words you're saying that the question isn't using .Net and .Net remoting (using RMI locks you into Java using your logic). Your question is a decision between using a remoting solution vs a webservice solution.

              The problem is that webservices don't offer the performance some applications require.

              • using RMI locks you into Java using your logic

                It does lock me into Java, but not into any particular vendor. There are perfectly good independent Java implementations from companies other than Sun.

                Someone pointed out the existence of Mono, an independent implementation of part of .Net, but it does not appear to me to be sufficiently complete to allow me to build complete systems without having to use some Microsoft components.

                The problem is that webservices don't offer the performance some applica

                • It does lock me into Java, but not into any particular vendor. There are perfectly good independent Java implementations from companies other than Sun.

                  Java is not an open standard -- you're locked into a technology controlled by Sun in much the same way that when you write .Net code you're using technology controlled by Microsoft. The fact that there are non-Sun implemented versions of that standard doesn't mean jack -- Sun is still at the wheel.

                  Someone pointed out the existence of Mono, an independen
    • Actually it is a fact. There are situations where web services make no sense but Remoting does exactly what you need. As for your statement about locking into a single OS vendor (which is completely orthogonal to the point), that is simply untrue. I've written several applications which use .NET Remoting and they all run great on my Linux box using Mono.
  • 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 da
  • 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

  • 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 .NET probably already has or should have this book.

    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 .NET remoting versus Web servers are not theoretical. You can get anywhere 5-10 times the performance. Because you can i

Slashdot Top Deals

Beware of all enterprises that require new clothes, and not rather a new wearer of clothes. -- Henry David Thoreau

Close