Hi Neil, I believe this is an excellent idea. I appreciate it. I think we'll pursue it.
Regards, Ed --- On Wed, 2/10/10, Neil Harrison <[email protected]> wrote: From: Neil Harrison <[email protected]> Subject: Re: [patterns-discussion] Messaging Design Pattern To: [email protected], "David S" <[email protected]> Date: Wednesday, February 10, 2010, 3:00 PM 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" <[email protected]> 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 = "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
