Hi,
Um, I'm wondering what kind of feedback you are expecting. Normally,
one
submits something like this to a PLoP conference, where you will get
one-on-one shepherding, as well as extensive feedback in the
conference.
May I
suggest that you consider submitting this to a PLoP conference,
where
you will get a lot of help with your pattern. When you submit works,
they initially
can be in draft form -- shepherding will help you improve them.
See www.hillside.net, and see the list of conferences. For example, you
can
submit this right away to EuroPLoP; the deadline for initial
submissions is in a
few days.
Cheers,
Neil Harrison
>>> On 2/9/2010 at 7:50 PM, "David S" <
dsheppard2k AT yahoo.com> wrote:
> Dear List Members,
>
> Please find enclosed a draft document covering the Messaging Design
Pattern.
> Any feedback would be appreciated.
>
> Best regards,
>
> Ed
> dsheppard2k at yahoo.com
>
>
> Messaging Design Pattern (draft)
>
> Intent:
The messaging design pattern allows the interchange of
information
> (messages) between components and applications.
>
>
> Motivations (forces): This design pattern can be applied to solve a
great
> variety of problems in many diverse scenarios. The messaging paradigm
is
> widely used in the real world. Messages are interchanged all around
us.
> Entities are constantly sending, receiving and processing messages:
when we
> watch TV, when we talk to a friend or send a message. Right now, you
are
> reading this written message. Since computer applications seek to
model the
> real world, it is only natural to design/write applications using a
messaging
> approach. We can argue that messaging provides a better and more
accurate
> representation (i.e. model) of the real world. As a consequence of
having a
> better model, 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: Component that receives the input message
and
> produces a reply (output message) after processing it. The input
message,
> general in nature, may contain any type of information. The
components 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.
>
>
>
> --message -> --message ->
> Sender Messenger
> Recipient
> <- reply -- <- reply --
>
> <UML diagram will replace this diagram>
>
>
>
>
>
> Consequences:
>
> - Encapsulation. The messaging design pattern
maximizes
encapsulation. Each
> component is a self-contained/independent unit. The only mechanism of
> communication with other components and applications is via
messaging.
>
> - Decoupling. The messaging design pattern minimizes coupling. Again
each
> component is a self-contained unit that can perform independently
from the
> rest of the system.
>
> - Reusability. The messaging design pattern improves reusability.
Components
> that use the messaging design pattern can be interchangeably plugged
into
> complex applications. This is similar to the building blocks in a
“lego” set.
> The components can be assembled in a limitless variety of
configurations. The
> user of a component only needs to know the input/output messages that
the
> component handles. Applications are also able to reuse components
from other
>
applications at the component level: a single component
(self-contained) can
> be extracted from another application, provided that the messaging
design
> pattern is being used.
>
> - QA/Testing process. The messaging design facilitates testing and
debugging
> efforts. Components are tested as independent units by sending
messages to
> the component and verifying the expected reply messages (black box
testing).
> Unit testing can be performed via a testing harness. No need to
include
> testing code inside the component code which can be time consuming
and lead
> to the unexpected introduction of software defects.
>
> - Design process. Components that use the messaging design pattern
improve
> and simplify the design process. The bulk of the design work becomes
defining
> the set of components needed to meet the system requirements and
the
> input/output messages that each component needs to handle. There is a
tight
> correspondence between UML design diagrams and the components needed
for the
> implementation. Since all components share the same messaging
interface they
> can also be easily added to BPM process diagrams. Again this is
similar to
> ‘lego’ pieces that can be reused and connected in many different
ways.
>
> - Development process. Since each component that relies on messaging
is
> self-contained, a large number of people can cooperate in the
development
> effort without stepping on each other's code/work. In the ideal
situation,
> responsibility for one component/package can be given to an
individual. The
> rest of the team only needs to know the input/output messages that
someone
> else’s component is supposed to handle. No need to change
someone
else’s
> code. The need for creating, maintaining and merging several versions
of the
> code is also minimized or eliminated. Testing/QA engineers can do
their
> testing independently via a testing harness. No need to add testing
code.
>
> - Logging and Debugging. Since all the components use the same
messaging
> interface, messages can be logged automatically. This minimizes the
need for
> print/logging statements inside the code which can be time consuming
and
> error prone. By taking a look at the messages being logged, the user
is
> usually able to quickly track down the message/component that is
causing the
> problem (with minimum or no extra effort).
>
> - Security. Well-known encryption and authentication mechanisms fit
in well
> with the messaging design pattern. Strong security can be provided
by the
> framework that implements the messaging design pattern. The sender
and the
> recipient don’t need to be concerned with how secure messaging is
> implemented. This provides strong security while at the same time
simplifying
> the implementation of security. Custom security mechanisms are also
easy to
> incorporate: sender and receiver need to agree on and implement the
message
> encryption/authentication mechanism to be used.
>
> - Multithreading and asynchronous messaging. The messaging design
pattern is
> able to handle multithreading and asynchronous messaging. Components
that
> implement the messaging design pattern are able to execute in a
> separate/independent thread. This is a natural representation of the
real
> world: each component (entity) is a self-contained unit and executes
> independently for the rest of the system.
Messages can be processed
> asynchronously using the component’s own independent thread. This
capability
> is usually implemented in the context of a component framework. The
component
> doesn’t need to add separate logic to handle multithreading which
is time
> consuming, complex and prone to error.
>
> - Speed of development and cost. Because of all the reasons outlined
above,
> the messaging design pattern is able to substantially improve the
speed of
> development and reduce cost.
>
> - Quality and software maintenance. Quality and software maintenance
efforts
> are also improved as a result of the all of the above.
>
>
>
>
>
>
>
> Known uses:
>
> - Design patterns. The messaging design pattern has been used to
> implement and/or facilitate the implementation
of other well-known
design
> patterns like Gang Of Four design patterns (GoF), DAO, J2EE Design
patterns,
> etc. The messaging design pattern also provides a more natural,
streamlined
> and straightforward implementation of other design patterns. Again,
we can
> argue that this is possible because messaging provides an accurate
> representation of the real world.
>
> - Remote proxies and application interfaces. The messaging design
pattern
> is particularly well suited for the implementation of remote access.
It is
> able to provide transparent access to remote components regardless of
the
> protocol, technology and communication mechanism being used: remote
framework
> objects are treated as local objects. Messages can be transferred via
Web
> services, EJBs, RMI, HTTP, Sockets. SSL or any other communication
interface.
> Design patterns implemented using messaging (adapters, remote proxies
and
> facades) make this possible by hiding the complexities associated
with remote
> APIs. The messaging design pattern solves a whole set of problems
dealing
> with remote application interfaces. It also provides significant
improvements
> over traditional methods and technologies. Sender and recipient
don’t need to
> be concerned with how messages are transferred.
>
> - Component based frameworks and design/BPM tools. The messaging
design
> pattern can be utilized to implement component based frameworks:
components
> can be interchangeably plugged into complex framework applications
using the
> “Lego” architecture previously described. These components can
also be
> readily incorporated into UML/BPM diagrams in order to design and
implement
>
complex applications. Notice that for components to be used
interchangeably,
> they need to share the same interface. The messaging design pattern
provides
> this common interface.
>
> - Secure Web Services. The messaging design pattern has been
utilized to
> implement secure web services. This includes Restful web services. A
Web
> service is just another mechanism of communication between
heterogeneous
> applications. Notice that the messaging design pattern doesn’t
place any
> restrictions on the message sender and recipient. These components
can be
> running on multiple computers and operating systems. They can also be
> implemented using multiple computer languages.
>
> - Enterprise Service Bus (ESB) components and applications.
Messaging has
> been used to implement ESB components and applications.
Once all the
building
> blocks are present (remote proxies, adapters, facades, etc), they can
be
> assembled to create a new application in a fraction of the time. This
is
> possible thanks to the messaging design pattern and the “Lego”
architecture.
>
> - Secure and Multithreaded applications. Again the messaging
design
> pattern provides the building blocks required to assemble secure and
> multithreaded applications in a fraction of the time required by
traditional
> methods. These building blocks are usually provided within the
context of a
> messaging framework.
>
>
>
>
>
>
>
>
>
>
>
>
> Code examples:
>
>
> The messaging design pattern is implemented using the Jt messaging
interface
> (JtInterface). This interface
consists of a single method:
>
>
>
> 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);
>
>
> }
>
> The JtInterface is simple but powerful. The simplicity of this
interface can
> be deceiving. One method is all that is needed (dry). It acts as a
universal
> messaging interface that applies to remote and local framework
components.
> This interface handles any type of message (Object class).
>
> The following example sends a message to a remote component/Restful
service
> via a remote proxy. The
messaging design pattern is able to handle
any
> communication protocol/technology (Web Service, EJBs, RMI, sockets,
SSL,
> etc.).
>
> /**
> * Send a message to a remote component/Restful service using
> * a remote proxy. Secure/Encrypted messaging may be used.
> * The messaging design pattern provides transparent access
> * to remote components.
> */
>
> public static void main(String[] args) {
>
> JtFactory factory = new JtFactory ();
> String sReply;
> JtRestProxy proxy;
> String url = """;
>
> // Create an instance of the remote Proxy.
>
> proxy = (JtRestProxy)
> factory.createObject (JtRestProxy.JtCLASS_NAME);
>
> proxy.setUrl(url);
> proxy.setClassname ("Jt.examples.Echo");
>
> // Specify that secure/encrypted messaging should be
used.
>
> proxy.setEncrypted(true);
>
> // Send the message
to the remote component/service
via
> // the remote proxy.
>
> sReply = (String)
> factory.sendMessage (proxy, "Welcome to Jt messaging
...");
>
> // The remote component will echo the input message.
>
> System.out.println ("Reply:" + sReply);
>
>
> }
>
>
>
> --message -> --message -> --message
->
>
--message ->
> Sender Messenger Proxy
> HTTP Adapter ....network…. Remote Component
> <- reply -- <- reply -- <-
reply --
> <- reply --
>
> Note: Any other communication protocol/technology can be handled
(EJB, RMI,
> sockets, SSL, etc). It is just a matter of replacing the HTTP Adapter
and
> plugging another component or building block. The messaging design
pattern
> and the “Lego”
architecture make this possible. This design
pattern solves a
> whole family of problems associated with remote APIs.
>
> <UML diagram will replace this diagram>
>
>
>
>
> Related design patterns:
>
> - Command
> - Proxy
> - Adapter
> - Bridge
> - Façade
>
>
>
>
>
>
