Skip to Content.
Sympa Menu

patterns-discussion - Re: [patterns-discussion] MDP feasibility questions (was: Messaging Design Patterns (MDP) reusability and QA)

patterns-discussion AT lists.cs.illinois.edu

Subject: General talk about software patterns

List archive

Re: [patterns-discussion] MDP feasibility questions (was: Messaging Design Patterns (MDP) reusability and QA)


Chronological Thread 
  • From: Messaging Design Pattern <dsheppard2k AT yahoo.com>
  • To: Al Boldi <a1426z AT gawab.com>
  • Cc: patterns-discussion AT cs.uiuc.edu
  • Subject: Re: [patterns-discussion] MDP feasibility questions (was: Messaging Design Patterns (MDP) reusability and QA)
  • Date: Mon, 13 Dec 2010 18:08:28 -0800 (PST)
  • List-archive: <http://lists.cs.uiuc.edu/pipermail/patterns-discussion>
  • List-id: General talk about software patterns <patterns-discussion.cs.uiuc.edu>

Al,

I'll be happy to discuss any implementation/applicability considerations. I believe it will also benefit the group. Several people have mentioned implementation considerations. The MDP papers are mainly geared towards the messaging concept based on a realistic model. I tend to place a lot of emphasis on the concept, abstraction and realistic model. In my opinion, concept and interface are the main aspects in order to achieve a successful implementation. On the other hand, I agree that  implementation considerations are also key aspects. They should not be overlooked.

In terms of implementation, I would also recommend taking a look at the Jt design pattern framework (user's manual, software, examples, applications). This framework implements many of the technologies mentioned in the paper:

Distributed Component Model based on MDP
Secure Web Services
Restful Web Services
Design Pattern Implementation (including GoF, Data Access Object and J2EE design patterns)
Enterprise Service Bus
BPEL (A Process is modeled as a set of components interchanging messages)
Multi-Threading applications.

The software is public. The same framework has bee utilized for production quality applications. It should give you a fairly complete idea on how MDP has been implemented.
This MDP framework should clarify many of the implementation/applicability considerations. Several reference applications based on MDP are included. Keep in mind that this framework is "only" one of the potential implementations of MDP. The implementation of MDP is up to the implementer's imagination.

In terms of the differences between Observer and Messaging:

Observer:
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

If we think in terms of a realistic model, the communication between Observer and dependents (notifications, etc) should be modeled via messaging. Therefore MDP can be used to implement observer in a realistic fashion. As discussed in the paper, MDP improves reusability, encapsulation and decoupling. A generic implementation becomes possible. The Jt framework includes an implementation of Observer based pn MDP.

MDP messaging, on the other hand, is about the interchange of information. If we think in terms of a realistic model. Observer and Messaging apply to different scenarios. In a sense, Messaging has a broader scope because messages are not limited to notifications. Messaging can be used for any type of information exchange. Also, Messaging is not designed to model the dependency relationship between Observer and dependents. Messaging models the information exchange between sender and receiver.

I'm afraid I won't be able to give you a precise list of areas where MDP is applicable . The concept of messaging (interchange of information) is very broad: Messaging is about interchanging information. In the real world, this happens everywhere. The list of technologies above gives you an idea of areas where messaging can be applied. I can give you one specific application area though. If the technology is based on Remote Procedure Calls (RPCs), it should be replaced with MDP because of complexities and shortcomings associated with RPCs. RPCs provide an incomplete and limited model. I'm afraid this is also a broad application area.  

Again, I would try to review the Jt design pattern framework, in order to get a precise idea on how MDP has been implemented. It also implements multi-threading while at the same time avoiding complexity. 

Please don't hesitate to send any additional comments or questions that you may have. I'll try to answer any specific implementation/applicability aspects that you are facing based on your specific application.

Best regards




 


--- On Mon, 12/13/10, Al Boldi <a1426z AT gawab.com> wrote:

From: Al Boldi <a1426z AT gawab.com>
Subject: Re: MDP feasibility questions (was: Messaging Design Patterns (MDP) reusability and QA)
To: "Messaging Design Pattern" <dsheppard2k AT yahoo.com>
Cc: patterns-discussion AT cs.uiuc.edu
Date: Monday, December 13, 2010, 4:55 PM

Messaging Design Pattern wrote:
> 1) No. Observer and messaging are two separate design patterns (concepts).

Separate concepts yes, but both could conceivably be used to implement the
same project.  When would we prefer the ODP over the MDP and vice/versa.

The reason I am questioning is that I see many developers picking the wrong
pattern for their implementation rendering the result a failure.  What we
need are clear instructions of when the MDP is applicable and when it is not.

> In terms of performance and resource usage, MDP is very light and
> efficient. Keep in mind that messaging (core functionality) can be
> implemented with a single messaging interface:
>
> public interface JtInterface  {
> /**
>   * Jt messaging interface used for the implementation
>   * of the messaging design pattern.
>   * Process an input message and return a reply (output message)
>   */
>
>   Object processMessage (Object message);
> }

Yes, both the interface and the concept itself look simple, yet when trying to
implement this interface it quickly mushrooms into a multi-threaded endeavor.

What is needed is more detail about the design pattern specifics, i.e.
associated sub-patterns needed to guide the developer to a successful
implementation.


Thanks!

--
Al





Archive powered by MHonArc 2.6.16.

Top of Page