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 = "http://localhost:8080/JtPortal/JtRestService";;
// 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
_______________________________________________
patterns-discussion mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion
