Hi Al,
I've been taken some time off during the holidays. I'm
glad that you agree with the premises and conclusion used to present
the Messaging Design Pattern: "messaging is part of reality and
software should mimic this reality". I believe that we need to get this
in order to fully understand the messaging concept (applicability,
consequences, implementation, best practices, etc.). As I mentioned
earlier, I'm glad if everyone get this and the messaging design pattern
right away. In my view, it is one of the main purposes of the
discussion. As one of the next steps, we can discuss a set of best
practices for implementation. I believe this will help the discussion.
I plan to go over implementation related questions soon. This may be an
appropriate place to start.
When I think about a software model,
I think about Object Oriented technologies and distributed
component/service technologies (Java, C++, Web Services/SOA, ESB, RMI,
CORBA, .NET, EJBs, etc). These technologies run on windows. On the
other hand, they put most of their emphasis on components/objects and
overlook messaging for most part. For instance, these technologies are
usually based on the RPC abstraction (remote Procedure Call) as opposed
to messaging. This results in complexity and limitations.
When
I talk about messaging I think about it as defined by a "realistic
model" and the messaging design pattern (MDP): Components, Message, and
messaging mechanism are independent entities, fully decoupled. This
definition of messaging mirrors reality:
Messaging Design Pattern (MDP)
|
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.
The term messaging is sometimes used in the context of software
models and technologies. On the other hand, most of these models and
technologies are based on the RPC abstraction (remote procedure
Calls). It is a different abstraction. This is not "real" messaging as
found in the real world (and defined by MDP). The MDP papers cover the
RPC limitations in detail.
A simple concept has a simple implementation. In general, two basic primitives are
required:
sendMessage (component, message) // Send a message to a component local or remote
// component
processMessage (message) // process the message.
Implementation should also mimic reality. This is only one potential
implementation of messaging. Messaging is about transferring or
exchanging information. The generic primitives above are able to
accomplish the goal and transfer the information (message). Component,
message and messaging mechanism are decoupled. Conceptually the
receiver component can be local or remote. Components communicate only
via messaging (realistic model). Messaging is also efficient (little
overhead required - 2 simple primitives).
Happy new year for everyone,
Al |
--- On Sat, 1/1/11, Al Boldi <a1426z AT gawab.com> wrote:
From: Al Boldi <a1426z AT gawab.com>
Subject: Re: [patterns-discussion] MDP feasibility questions
To: "Messaging Design Pattern" <dsheppard2k AT yahoo.com>
Cc: patterns-discussion AT cs.uiuc.edu
Date: Saturday, January 1, 2011, 1:38 PM
Messaging Design Pattern wrote:
> The particular point in discussion
> was whether or not messaging needs to be part of the software model:
As far as I can see, Messaging is already part of the software model.
It has been part of the software model for a very long time.
Windows is based on messaging.
All the new Linux desktops are now messaging based, i.e. dbus.
Mind you, when they
switched to a messaging based model we got a noticeable
performance hit.
So, I am not sure what your objective is now?
If your objective is to convince people that messaging is part of reality and
that software should mimic this reality, then I think you are wasting your
time because people already know this.
OTOH, if your objective is to define a set of best practices to achieve a
successful implementation of a messaging sub-system, then I think that your
efforts are worthwhile and much appreciated.
Thanks!
--
Al
|
