EAI Patterns with Actor Model: Return Address

Since you understand how to implement a Request-Reply using Actor Model, what if you want your Request receiver to Reply to an Actor at an Address other than the direct message sender? Well, that’s the idea behind the Return Address pattern, and one that we can implement in a few different ways.

It’s interesting that the Actor Model actually uses Addresses to identify how to send messages to Actors. You see, each Actor has an Address, and in order to send a given Actor a message you must know its Address. One Actor can know the Address of another Actor by a few different means:

  • An Actor creates another Actor, and thus knows the Address of the Actors it has created
  • An Actor receives a message that has the Address of one or more other Actors that it will send messages to
  • In some cases an Actor may be able to look up the Address of another Actor by name, but this may create an unseemly binding to the definition and implementation of a given Actor

Anyway, the Return Address EAI Pattern name fits really well with the fundamental ideas behind Actor Model.

. . .

The full text is now available as part of my book Reactive Enterprise with Actor Model on Safari Books Online.

Comments

  1. Tristan Slominski says:

    Another consequence of looking up an Actor address by name mentioned in the beginning, aside from binding, is that such ability destroys the Object Capability Security (http://en.wikipedia.org/wiki/Object-capability_model) inherent in an actor system. As far as I understand, this means that the security of the system is no longer _easily_ provable.

    Unfortunately, having an implicit “sender” to reply to (instead of explicit return address described here) also destroys Object Capability Security.

    • Excellent point. Thanks much for your feedback. For this reason I am incorporating the principles of Object-Capability in my treatment of Content Filter, which is coming up next: https://vaughnvernon.co/?p=363

      Just one comment on your statement that a sender passing to a receiver a message that contains a reference to a reply-to “destroys the Object-Capability Model.” The basic premise of Actor Model is that Actors may know the addresses of Actors that they (1) create, and (2) receive as part of messages from another Actor. The second one is covered by rule #4, Introduction.

      • Tristan Slominski says:

        You’re right, I used imprecise language. I agree that reply-to is a valid pattern, as you pointed out.

        I meant to highlight that having an implicit “sender” (usually provided by a framework) creates an implicit Introduction. This requires the developer to be extra careful in implementing Object-Capability as it becomes easy to accidentally leak references. To contrast, a framework requiring an explicit “replyTo” requires explicit Introduction, thus, in my opinion, making it more difficult to leak references, and thus capabilities, although this may decrease programming convenience.

        • Where does the implicit sender come in to play by a framework? Do you mean that Akka/Scala sees to it that if I am “a” and I do:

          b ! message

          That “b” gets “a” as its sender? Or are you discussing some other kind of framework “feature”?

          • Tristan Slominski says:

            Yes, exactly how you described it.

            From the Akka documentation (http://doc.akka.io/docs/akka/snapshot/scala/actors.html):

            val a = actor(new Act {
            become {
            case “hello” ⇒ sender ! “hi”
            }
            })

            From my understanding (and using it a while back), “sender” is implicitly available to any actor in Akka.

            (sorry my response took a while, I don’t get email notifications of replies)