Ralph, I uploaded a second revision of the draft including a detailed comparison between the design pattern and the Actors model (6+ pages). I've attached a few paragraphs taken from the second revision which cover some of the criticisms attributed to the Actors model.
I'm not sure that you saw the second revision of the draft. Your browser may have saved the older revision (cache). In any case, If you happen to disagree with aspects of the detailed comparison, please send any specific comments/concerns that you may have. I'll be happy to address any specific issues in order to improve the content of the draft (as intended): http://java.net/projects/jt/downloads/download/Papers/MDPAnimated.doc Because of size limitations, I had to create an Appendix. I just uploaded another revision (3rd). I also added a list of references to the draft. Thank you for your comments. Al The pattern and the Actor model have many differences: model, abstractions, primitives, assumptions, messaging types, implementation, and results. Appendix 1) The Actor model makes the assumption that the message delivery is guaranteed (fairness). As a consequence mailboxes are infinite. Such assumption has been the source of criticism. It seems artificial, unrealistic, and not really required. The potential loss of information is a fact of life. However, there are control mechanisms that can be put in place in order to provide redundancy, reliability, fault-tolerance and ensure delivery of critical information. There is also a general consensus that such assumption poses challenges that hinders the applicability of the model 2) For example, the Actor model uses the concept of behavior. Each time an Actor accepts a message, a replacement behavior is computed. This abstraction is probably redundant within the context of object oriented technologies. It has also been the source of criticism. It introduces complexity and overhead associated with having additional abstractions and primitives. Behavior is already handled by the component functionality provided by its internal functions or methods. In other words, the component will behave according to the information received (inputs), its internal state and its collection of functions or methods. In reality, the concept of behavior is already an intrinsic aspect associated with an object (animated or not). No separate abstraction and associated set of primitives need to be modeled or implemented. 3) Animated objects and MDP messaging rely on a single information primitive: public interface JtInterface { Object processMessage (Object message); } Messaging as a concept presents many qualities including: simplicity, versatility, decoupling, encapsulation, reusability, scalability and so on. This is a simple concept with a simple implementation. A single messaging primitive also makes the proposed approach distinctively different..... 4)The pure Actor model is based on asynchronous messaging. The coordination of Actors has been criticized for its complexity. In general asynchronous messaging present complications and should not be used for all circumstances. Animated components provide transparent support for all modalities of messaging. --- On Thu, 5/12/11, Messaging Design Pattern <[email protected]> wrote: From: Messaging Design Pattern <[email protected]> Subject: Re: Fw: Re: [gang-of-4-patterns] Live or Animated Object Design Pattern To: "Ralph Johnson" <[email protected]> Cc: [email protected], [email protected] Date: Thursday, May 12, 2011, 3:20 PM Ralph, I wouldn't mind changing the name for a more appropriate one. I'm mainly concerned about the idea itself and its application. I'm interested in having it applied to a broader set of applications and real-world problems (Especially in mainstream technologies). I have to think about the name. I would have reservation in terms of using the term "Actors" for several reasons: a) It may hinder their broad application since the name actors is associated with several criticisms and shortcomings (perception), many of which I have documented as part of the draft (6+ pages). The proposed pattern does not share these shortcomings. As discussed in the draft, the Actor model was introduced in the 70's. A lot of software technology advances have come to pass since that time, specifically in the areas of Object Orientated methodologies, design patterns, distributed technologies, internet, web services, and software modeling. b) I agree that the proposed pattern and the Actor model make use of Asynchronous messaging. On the other hand, there are other systems and models that deal with Asynchronous messaging. Also, the proposed pattern is not limited to asynchronous messaging (as opposed to the pure Actor model). The pattern and the Actor model have many differences: model, abstractions, primitives, assumptions, messaging types, implementation, results (6+ pages). I hope the draft accurately reflects all the differences. It may be confusing to use the same name when there are so many differences. As I mentioned earlier, the pattern does not share the shortcomings associated with the Actor model. By the way, because of size limitations, I'll probably have to create an Appendix that includes the detailed comparison. Regards, Al
_______________________________________________ patterns-discussion mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion
