General talk about software patterns

[phillip henry <ph1ll1phenry AT yahoo.com>]

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: