《Distributed Programming With Ruby》读书笔记一Drb:Hellowold and Pass by Reference(Part1.1-1)

《Distributed Programming With Ruby》Mark Bates

Preface:

• The author was using Java and RMI(remote method invocation) as distributed interface in 2001. To solve performence problems, he found DRb. "I was already impressed with Ruby for being a terse language, but when I found the DRb(Distributed Ruby, also known as dRuby)package, I became a believer. "
• This book is quite simply written for the intermediate to advanced Ruby developer who wants to start developing distributed applications.
• You'll learn about RMI, message queues, and MapReduce, among others.
• Unless otherwise stated, you should be able to take any code sample, copy it into a Ruby  file, and run it using the ruby command, like this:

$ ruby foo.rb 

Part I standard Library

     The first part of this book takes a deep dive into two main libraries: DRb and Rinda

• Chapter1: Distributed Ruby(DRb)
  • Including 6 parts:
    • 　　Hello World
    • 　　Proprietary Ruby Objects
    • 　　Security
    • 　　ID Conversion
    • 　　Conclusion
    • 　　Endnotes
  • 
  • Here is what the documentation says when introducing DRb:
    • dRuby is a distributed object system for Ruby. It allows an object in one Ruby  process to invoke methods on an object in another Ruby process on the same ora different machine.
  • Hello World
  • Example: Using Java RMI to write a distributed program
    • Difine interface
    • Sever
    • Client
    • Whe you start doing something more complex, you can quickly become swamped with overwhelming interfaces, classes, stubs, registries, and so on.
  • Example: DRy
    • Server:
      • 
    • Client:
      • 
      • #=> "Hello, world!"
    • When we call DRbObject.new_with_uri("druby://127.0.0.1:61676"),we actually get back an instance of DRb::DRbObject and not the HelloWorld-Server class. If we "puts server.inspect" in Client, we will see:"#<DRb::DRbObject:0x1ebc328 @uri=\"druby://127.0.0.1:61676\", @ref=nil>"
    • 
  • Example: Distributed Logger
  • Including "Logger" Module
    • Server:
      • 
    • Client:
    • • 
    • If we were to run our client application, we would see something like the following show up in our server logs:
    • • 
  • Proprietary Ruby Objects
    • Include DRbUndumped
    • Class User
    • • 
        
    • Server
    •     　
    • Client
    • • 
        
    • Error
      • 　
  • • 
      
    • In our “User Server” example, the User class can be serialized, but it can't be deserialized in the client, because the client does not have the class definition for User in its virtual machine. That's why the inspect on the User class comes back with  DRb::DRbUnknown and you get a NoMethodError when you try to call the username method on the returned class.
    • How do we solve this problem? We could, of course, copy the User class definition from the UserServer to the client. That would work. The problem with this approach is that it starts to get unwieldy after a while, depending on the size of your application. Plus, you are duplicating code and generally confusing the issue.
    • Modify:
    • 
    • Output
    • 
    • Normally when an object is returned by a method called over DRb, the object is marshaled, sent over the connection, and run on the client side. As mentioned earlier,this works wonderfully if the object returned has a class definition that exists on the client side. When we include DRbUndumped into a class, as we did with the User class, we tell DRb that the object cannot be marshaled and that DRb should send a reference to it instead. The object then stays on the server side, and the  reference on the client side then proxies the method calls back and forth to the server
    • 

      

       

转载于:https://www.cnblogs.com/nightcatcher/p/6105021.html