headers
Messaging Design Pattern | 1 May 2011 01:31
Picon
Favicon

Re: [gang-of-4-patterns] Live or Animated Object Design Pattern

Ralph,

Based on my earlier email, I've updated the draft. A section discussing related work (pages 12-14 in blue) has been added. This section includes detailed information comparing several models, implementations, and technologies.

http://java.net/projects/jt/downloads/download/Papers/MDPAnimated.pdf


Feel free to send any follow-up comment or concern based on the updated draft. I believe there are several differences between this approach and other approaches (in particulars with the Actors model). Hopefully I was able to capture these differences as part of the updated draft. I'll be happy to discuss these differences in order to get to the facts. Please keep in mind that this still work in progress (draft form). It is being refined based on the feedback received. Also we have something concrete (this new section) as the basis of further discussion. I just added three pages to the draft  based on your earlier message.

I agree with you earlier comments: I also think that these differences must be tangible and they should be clearly explained as part of the document. As I said earlier, I hope the new section (related work) helps in accomplishing that purpose.


Regards,

Al

--- On Tue, 4/19/11, Messaging Design Pattern <dsheppard2k-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:

From: Messaging Design Pattern <dsheppard2k-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
Subject: Re: [gang-of-4-patterns] Live or Animated Object Design Pattern
To: "Ralph Johnson" <johnson-Tmj1lob9twqVc3sceRu5cw@public.gmane.org>
Cc: gang-of-4-patterns <at> cs.uiuc.edu, patterns-discussion-Tmj1lob9twqVc3sceRu5cw@public.gmane.org, telecom-patterns-Tmj1lob9twrHfRtnQztjLA@public.gmane.orgu, ipc-patterns-Tmj1lob9twqVc3sceRu5cw@public.gmane.org
Date: Tuesday, April 19, 2011, 3:07 AM


Ralph,

I appreciate the feedback. I plan to update the draft and add detailed information comparing the design pattern with other models and technologies (similarities, differences,  advantages, disadvantages, implementation considerations, etc).


Regards,

Al
--- On Sun, 4/17/11, Ralph Johnson <johnson-Tmj1lob9twqVc3sceRu5cw@public.gmane.org> wrote:

From: Ralph Johnson <johnson <at> cs.uiuc.edu>
Subject: Re: [gang-of-4-patterns] Live or Animated Object Design Pattern
To: "Messaging Design Pattern" <dsheppard2k-/E1597aS9LQ@public.gmane.orgm>
Cc: gang-of-4-patterns-Tmj1lob9twqVc3sceRu5cw@public.gmane.org, patterns-discussion-Tmj1lob9twrHfRtnQztjLA@public.gmane.orgu, telecom-patterns-Tmj1lob9twqVc3sceRu5cw@public.gmane.org, ipc-patterns-Tmj1lob9twqVc3sceRu5cw@public.gmane.org
Date: Sunday, April 17, 2011, 9:42 AM

It seems to me to be the same thing as the actor model, but you don't mention it.  There are a variety of actor languages out there, including some built on the JVM.  Often this happens through libraries rather than through compilers.   Erlang is a good example of a hard-core actor language.   Scala has a variety of libraries that support actors.  One of the more recent and more popular is Akka.

People have been writing about this for a few decades and so I was surprised not to see any references to it.

-Ralph Johnson

On Sat, Apr 16, 2011 at 10:05 PM, Messaging Design Pattern <dsheppard2k-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:

Dear List members,

Please find enclosed a link to a draft discussing the Live or Animated object design pattern:

http://java.net/projects/jt/downloads/download/Papers/MDPAnimated.pdf

Any feedback would be appreciated. This draft also includes additional information about asynchronous concerns, best practices and implementation considerations.

Regards,
Al

Live or Animated object design pattern

Intent: This design pattern encapsulates component functionality, processing (threading) mechanism and the messaging functionality required to provide the component with independent behavior (a “live of its own” so to speak). This also means that the component uses its own independent processing mechanism or thread of execution. This design pattern improves decoupling, encapsulation and scalability while at the same time reducing complexity and overall implementation cost. Component functionality, processing/treading mechanism and messaging mechanism are decoupled entities, independent of one another. MDP messaging [2] allows the interchange of information (i.e. messages) between the animated component and other components or applications. Although decoupled and independent of one another, processing/threading mechanism and component functionality are completely encapsulated within a single entity: live or animated object.

 

Motivation: The implementation of traditional multithreaded applications is a complex undertaking which usually becomes costly, time consuming and prone to error. Defects related to are often encountered (thread management, synchronization, race conditions, deadlocks, etc). These software defects are difficult to avoid, reproduce and isolate.  Large multithreaded applications complicate the problem even further. The degree of complexity and risk considerably worsens as the number of threads and their interactions increases. Object oriented applications consist of a collection of components that interact with each other. In reality, some of these components should be modeled as live or animated components: They exhibit independent behavior, a “life of their own”......


_______________________________________________
gang-of-4-patterns mailing list
gang-of-4-patterns-Tmj1lob9twqVc3sceRu5cw@public.gmane.org
http://lists.cs.uiuc.edu/mailman/listinfo/gang-of-4-patterns


<div><table cellspacing="0" cellpadding="0" border="0"><tr><td valign="top"><div><table class="yiv138982624" border="0" cellpadding="0" cellspacing="0"><tr><td><div><table class="yiv138982624" border="0" cellpadding="0" cellspacing="0"><tr><td><div><table class="yiv138982624" border="0" cellpadding="0" cellspacing="0"><tr><td>Ralph,<br><br>Based on my earlier email, I've updated the draft. A
 section discussing related work (pages 12-14 in blue) has been added. This section includes detailed information comparing several models, implementations, and
technologies. <br><br><a rel="nofollow" target="_blank" href="http://java.net/projects/jt/downloads/download/Papers/MDPAnimated.pdf">http://java.net/projects/jt/downloads/download/Papers/MDPAnimated.pdf</a><br><br><br>Feel free to send any follow-up comment or concern based on the updated draft. I believe there are several differences between this approach and other approaches (in particulars with the Actors model). Hopefully I was able to capture these differences as part of the updated draft. I'll be happy to discuss these differences in order to get to the facts. Please keep in mind that this still work in progress (draft form). It is being refined based on the feedback received. Also we have something concrete (this new section) as the basis of further discussion. I just added three pages to the
 draft&nbsp; based on your earlier message. <br><br>I agree with you earlier comments: I also think that these differences must be tangible and they should be clearly explained as part of the document. As I said earlier, I hope the new section (related work) helps in accomplishing that purpose. <br><br><br>Regards,<br><br>Al<br><br>---
 On Tue, 4/19/11, Messaging Design Pattern &lt;dsheppard2k@...&gt; wrote:<br><blockquote>
<br>From: Messaging Design Pattern &lt;dsheppard2k@...&gt;<br>Subject: Re: [gang-of-4-patterns] Live or Animated Object Design Pattern<br>To: "Ralph Johnson" &lt;johnson@...&gt;<br>Cc: gang-of-4-patterns <at> cs.uiuc.edu, patterns-discussion@..., telecom-patterns@...u, ipc-patterns@...<br>Date: Tuesday, April 19, 2011, 3:07 AM<br><br><div><table border="0" cellpadding="0" cellspacing="0"><tr><td valign="top">
<br>Ralph,<br><br>I appreciate the feedback. I plan to update the draft and add detailed information comparing the
 design pattern with other models and technologies (similarities, differences,&nbsp; advantages, disadvantages, implementation considerations, etc).<br><br><br>Regards,<br><br>Al<br>--- On Sun, 4/17/11, Ralph Johnson &lt;johnson@...&gt; wrote:<br><blockquote>
<br>From: Ralph Johnson &lt;johnson <at> cs.uiuc.edu&gt;<br>Subject: Re: [gang-of-4-patterns] Live or Animated Object Design Pattern<br>To: "Messaging Design Pattern" &lt;dsheppard2k@...m&gt;<br>Cc: gang-of-4-patterns@..., patterns-discussion@...u,
 telecom-patterns@..., ipc-patterns@...<br>Date: Sunday, April 17, 2011, 9:42 AM<br><br><div>It seems to me to be the same thing as the actor model, but you don't mention it. &nbsp;There are a variety of actor languages out there, including some built on the JVM. &nbsp;Often this happens through libraries rather than through compilers. &nbsp; Erlang is a good example of a hard-core actor language. &nbsp; Scala has a variety of libraries that support actors. &nbsp;One of the more recent and more popular is Akka.<div>
<br>
</div>
<div>People have been writing about this for a few decades and so I was surprised not to see any references to it.</div>
<div><br></div>
<div>-Ralph Johnson<br><br><div class="yiv138982624gmail_quote">On Sat, Apr 16, 2011 at 10:05 PM, Messaging Design Pattern <span dir="ltr">&lt;<a rel="nofollow">dsheppard2k@...</a>&gt;</span> wrote:<br><blockquote class="yiv138982624gmail_quote">
<table border="0" cellpadding="0" cellspacing="0"><tr><td valign="top">
<br>Dear List members,<br><br>Please find enclosed a link to a draft discussing the Live or Animated object design pattern:<br><br><a rel="nofollow" target="_blank" href="http://java.net/projects/jt/downloads/download/Papers/MDPAnimated.pdf">http://java.net/projects/jt/downloads/download/Papers/MDPAnimated.pdf</a><br><br>Any feedback would be appreciated. This draft also includes additional information about asynchronous concerns, best practices and implementation considerations.<br><br>Regards,<br>Al<br><br>Live or Animated object design pattern<br><br>Intent: This design pattern encapsulates component functionality, processing (threading) mechanism and the messaging functionality required to provide the component with independent behavior (a &ldquo;live of its own&rdquo; so to speak). This also means that the component uses its own independent processing mechanism or thread of execution. This design pattern improves decoupling, encapsulation and scalability while at the same time
 reducing complexity and overall implementation cost. Component functionality, processing/treading mechanism and messaging mechanism are decoupled entities, independent of one another. MDP messaging [2] allows the interchange of information (i.e. messages) between the animated component and other components or applications. Although decoupled and independent of one another, processing/threading mechanism and component functionality are completely encapsulated within a single entity: live or animated object.<br><br><p class="yiv138982624MsoNormal"><span>&nbsp;</span></p>

<p class="yiv138982624MsoNormal"><span>Motivation: </span><span>The
implementation of traditional multithreaded applications is a complex undertaking
which usually becomes costly, time consuming and prone to error. Defects
related to are often encountered (thread management, synchronization, race
conditions, deadlocks, etc). These software defects are difficult to avoid,
reproduce and isolate.<span>&nbsp; </span></span><span>Large multithreaded
applications complicate the problem even further. <span>The
degree of complexity and risk considerably worsens as the number of threads and
their interactions increases. Object oriented applications consist of a
collection of components that interact with each other. In reality, some of
these components should be modeled as live or animated components: They exhibit
independent behavior, a &ldquo;life of their own&rdquo;......</span></span><br></p>
</td></tr></table>
<br>_______________________________________________<br>
gang-of-4-patterns mailing list<br><a rel="nofollow">gang-of-4-patterns@...</a><br><a rel="nofollow" target="_blank" href="http://lists.cs.uiuc.edu/mailman/listinfo/gang-of-4-patterns">http://lists.cs.uiuc.edu/mailman/listinfo/gang-of-4-patterns</a><br><br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</td></tr></table></div>
</blockquote>
</td></tr></table></div></td></tr></table></div></td></tr></table></div></td></tr></table></div>
Permalink | Reply |

Gmane