Skip to Content.
Sympa Menu

patterns-discussion - Re: [patterns-discussion] MDP feasibility questions (type safety & compilation error)

patterns-discussion AT lists.cs.illinois.edu

Subject: General talk about software patterns

List archive

Re: [patterns-discussion] MDP feasibility questions (type safety & compilation error)


Chronological Thread 
  • From: Messaging Design Pattern <dsheppard2k AT yahoo.com>
  • To: patterns-discussion AT cs.uiuc.edu
  • Subject: Re: [patterns-discussion] MDP feasibility questions (type safety & compilation error)
  • Date: Mon, 10 Jan 2011 09:55:51 -0800 (PST)
  • List-archive: <http://lists.cs.uiuc.edu/pipermail/patterns-discussion>
  • List-id: General talk about software patterns <patterns-discussion.cs.uiuc.edu>

Folks,


In terms of implementation, we have discussed several aspects:


1) There are several potential ways in which MDP messaging can be implemented.

2) The Jt Design Pattern framework is a reference implementation of MDP. It
is also a good source for implementation information, documentation,
examples, applications, etc.


The following section deals with some implementation related questions. In
particular, it deals with type safety and detection of errors during
compilation. Feel free to let me know if you have any additional
questions/comments on this topic.


On terms of the example contained in the paper, processMessage/sendMessage
are used for communication (messaging) only. You will need other primitives
for component lookup, creation, read, update and deletion. In Java for
instance, you will usually have getters and setters to set and retrieve the
value of component attributes. Other technologies/languages provide similar
facilities to access/update components. These additional primitives do not
impact coupling(communication between independent/decoupled components is
performed via messaging). I hope this clarifies some of the questions related
to the example contained in the paper. In summary, getters and setters are
OK. They are used to initialize the components before the message is
transferred to the remote component/service. On the other hand, local
component, remote component and messaging mechanism are independent entities,
fully decoupled via MDP.Conceptually you are sending a message to a remote
component/service via its proxy:


sendMessage (proxy, message);


The MDP framework is responsible for delivering the message.


Best Regards,


Al




MDP Implementation



Similar to the software model, the MDP implementation should also mimic the
reality being modeled. There will probably be some implementation differences
depending on the specific application. There are many factors to consider
based on the type of messaging being implemented and the technology/language
in use: messaging delivery characteristics, streaming, messaging reliability,
asynchronous messaging, security, etc.



The MDP interface (JtInterface) is mainly a reference implementation and
there are other potential implementations of the messaging abstraction:



public interface JtInterface { Object processMessage (Object message); }



The generic type object is used. This is similar to the implementation of
other design patterns (Iterator, for instance). In reality, the component may
only be able to process and return specific types of message. In that case,
appropriate types may be specified. For instance:


public interface MyMessagingInterface {

MyOutputType processMessage (MyInputType message); }



This is also a valid implementation of messaging. Advanced object oriented
technologies provide features like Java generics which allow the types to be
parameterized:



public interface MDPInterface<Type, Type1> { Type1 processMessage (Type
msg); }



Notice that any computer language or technology can be used to implement MDP
messaging including plain old java objects (POJOs):



public Object processMessage (Object message)



Depending on the application, a second messaging primitive may be needed:



public Object sendMessage (Object component, Object message);



This primitive sends a message to a local or remote component. Although MDP
messaging features a simple implementation, based on basic primitives, it is
able to transparently handle complex real-world scenarios: remote
components, synchronous/asynchronous/two-way communication, component
interoperability, multithreading, streaming, authentication, encryption,
exception handling, reliable messaging, etc. As mentioned earlier, the
concept, messaging is simple, versatile, robust, etc. Messaging can also be
made reliable, secure, redundant and fault-tolerant. By including messaging,
the model and the implementation absorb its inherent qualities.











Archive powered by MHonArc 2.6.16.

Top of Page