Design Patterns discussion

[phillip henry <ph1ll1phenry AT yahoo.com>]

Actually, don't know what happened to my original post.

I thought I replied to Messaging Design Pattern but it appears to have been sent to dsheppard2k AT yahoo.com.

My apologies to Mr/Ms Sheppard.

Phillip

----- Forwarded Message ----
From: phillip henry <ph1ll1phenry AT yahoo.com>
To: Messaging Design Pattern <dsheppard2k AT yahoo.com>
Sent: Tue, May 18, 2010 10:44:40 PM
Subject: Re: [patterns-discussion] Messaging Design Pattern and transparent access to distributed components

Hi, Ed,

Thanks for getting back to me so promptly.

> We don't believe type safety is really an issue

I'm afraid that you may be in a minority.

> DAO or iterator to give you a couple of examples

How is the DAO pattern not type-safe?

And doesn't Java use type-safety for it's Iterator (at least in JDK 1.5+)?

> The implementation needs to handle any type of object

Can you not achieve this with generics (eg, as in the Java API for java.util.Iterator)?

I'm afraid that I don't believe that the JtInterface interface that has just one method:

java.lang.Object processMessage(java.lang.Object message)

constitutes a pattern.

I did take a look at the JT framework. My main concern is that JT is trying to implement patterns for me. I believe this misses the point of what patterns are for. No framework can possibly know exactly what I am trying to do.

If you take the Jt.JtStrategy class, for instance, how can this implement the Strategy Pattern for me if it doesn't know what particular problem I am trying to address? It can wrap my unit of work and give me a generic interface, for sure. But it lacks type-safety and replaces my self-describing method name with processMessage.

How is my code any richer for this?

Regards,

Phillip

---

From: Messaging Design Pattern <dsheppard2k AT yahoo.com>
To: phillip henry <ph1ll1phenry AT yahoo.com>
Sent: Tue, May 18, 2010 3:24:27 PM
Subject: Re: [patterns-discussion] Messaging Design Pattern and transparent access to distributed components

Phillip,

There were several changes made to the paper based on comments received (asynchronous information).  We don't believe type safety is really an issue. Many design patterns use Object for their implementation because the problem addressed is general in nature. DAO or iterator to give you a couple of examples. The implementation needs to handle any type of object.  It is the same in the case of messaging. Any type of message needs to be handled. On the other hand, the implementation is not that vital when compared with the pattern/concept of messaging itself. The messaging concept is the main aspect. By the way, the type may be restricted (during implementation) to accommodate type safety. There may better implementations depending on specific requirements.


Regards,

Edgar


--- On Sat, 5/15/10, phillip henry <ph1ll1phenry AT yahoo.com> wrote:

From: phillip henry <ph1ll1phenry AT yahoo.com>
Subject: Re: [patterns-discussion] Messaging Design Pattern and transparent access to distributed components
To: "Messaging Design Pattern" <dsheppard2k AT yahoo.com>, patterns-discussion AT cs.uiuc.edu, telecom-patterns AT cs.uiuc.edu, ipc-patterns AT cs.uiuc.edu, gang-of-4-patterns AT cs.uiuc.edu
Date: Saturday, May 15, 2010, 2:00 PM

Ed, maybe I am reading this wrong but this is the same link and the same PDF that you sent around on April 26. Why are you sending it again?

I don't see the issue of type safety being addressed and I still see a quasi-religious statement in the conclusion. I respect every man's religion but documents that purport to be academic should really avoid such references.

Regards,

Phillip

---

From: Messaging Design Pattern <dsheppard2k AT yahoo.com>
To: patterns-discussion AT cs.uiuc.edu; telecom-patterns AT cs.uiuc.edu; ipc-patterns AT cs.uiuc.edu; gang-of-4-patterns AT cs.uiuc.edu
Sent: Fri, May 14, 2010 3:06:49 AM
Subject: [patterns-discussion] Messaging Design Pattern and transparent access to distributed components

Dear List members,

Thanks again for your feedback. Please find enclosed a link to the revised document ( Messaging Design Pattern and a distributed component model):

http://jt.dev.java.net/files/documents/5553/149793/distributedModel.pdf

Additional information has been included in regards to asynchronous messaging and fault-tolerant considerations.

Ed

Messaging Design Pattern and transparent access to distributed components and services

Abstract

This paper discusses a distributed component model based on the messaging design pattern (MDP). This pattern is utilized to implement transparent and secure access to remote components in a distributed environment. Our model also demonstrates how software engineering processes and techniques can be improved by using MDP.  For instance, it has been used for the implementation of Service Oriented Architecture (SAO) and Enterprise Service Bus (ESB) technologies. At the core of these technologies lies the need for communication between components and applications. This communication challenge is exactly the one that MDP targets, models and solves.

Let’s start by briefly discussing the Messaging Design Pattern.


Messaging Design Pattern


Intent: The messaging design pattern allows the interchange of information (i.e. messages) between components and applications.


Motivations (forces):  This design pattern can be applied to solve a great variety of problems in many diverse scenarios. A messaging paradigm is widely used in nature and the real world. Messages are interchanged all around us. Entities are constantly sending, receiving and processing messages. Human beings for instance:  when we watch TV, listen to music, talk over the phone, or communicate via the internet. Right now, you are reading this written message. Since computer applications seek to model the real world, it is only natural to design and write applications using a messaging approach. We can argue that this approach provides a more complete and accurate representation (i.e. model) of the real world. As a consequence, software engineering processes are significantly improved by the use of the messaging design pattern.



Participants:

a)    Message Sender: Component that sends the message.
b)    Message Recipient (Receiver): Component that receives the input message and may produce a reply (output message) after processing it.  The input message, general in nature, may contain any type of information. The component may be instructed to perform computations based on the input message.
c)    Messenger: Intermediary that transfers the message from the sender to the recipient. The sender and the recipient don’t need to be concerned about how the message is transferred (communication protocol, message format, encryption/security mechanism, etc.) and the transformations performed on the message along the way. This is the messenger’s purpose and responsibility. Similar to the real world, it is often the case that the messenger is not required. The message can be sent directly to the message recipient. Several modes of communication are possible: synchronous, asynchronous and two-way messaging.
d)    Message: any piece of information (i.e. data) that needs to be interchanged between sender and recipient. Two messages are usually involved: input message and output message (or reply message). The reply message is not required.
Structure: