Dear List and Conference members
I'm glad that the real world analogies served their purpose. At the very least they encouraged the reader to think in terms of a realistic software model (based on messaging) that mimics the world around us. The main goal of this discussion is the to clarify or expand on specific points not covered by the paper. In terms of reusability, there are several areas where the messaging design pattern (MDP) provides improvements: - Reusable implementation of other design patterns. As covered by the paper, the implementation of the J2EE design patterns and the remote Proxies are 100% reusable. There is no need to reimplement a remote Proxy for each remote component. "Design patterns implemented using MDP can be reused as building blocks. A generic pattern implementation becomes possible. Complex applications can be built based on these building blocks which share a simple way of interconnecting them (i.e. common messaging interface)." "Reusability. MDP improves reusability. ..... Components that use MDP can be interchangeably plugged into complex applications. 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 can be extracted from another application, provided that the messaging design pattern is being used." In a sense MDP components act like electronic components that can be reused and replaced interchangeably. This applies to large and small components. We just need to know the inputs/outputs that the electronic component is supposed to handle. All the components use a similar interface. - MDP can also be easily plugged into applications based on multiple technologies/languages/protocols/etc. For instance a component based on the Java architecture can be easily invoked remotely from a .net applications: MDP and a distributed Component/Service Model https://jt.dev.java.net/files/documents/5553/149793/MDPdistributedModel.pdf These are specific examples where MDP improves reusability. I'm afraid that for this specific paper, testing/QA was not one of the main areas of focus: I realize that there is not enough detail in terms of how MDP can benefit application testing/QA. It is only mentioned briefly as one of the consequences of the messaging design pattern. It would take several pages (probably a separate write up) to cover this topic in detail. The main difference is that all MDP components share the same messaging interface: "QA/Testing process. MDP 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). In general, 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." I can provide a specific example that may clarify this aspect. It is related to the Remote Procedure call (RPC) examples covered in the paper. MDP distributed components can be tested locally/independently because messaging and component functionally are decoupled. This is usually very difficult to do when traditional mechanisms based on RPCs are used. The components and the RPCs need to be tested together because they are tightly coupled. The testing process becomes more difficult. It is time-consuming, tedious and prone to error. Also Keep in mind that the messaging mechanism can be provided by a messaging framework (similar to the phone company). The framework should be designed and built to provide a reliable service. For instance, The phone company ensures communication quality and reliability (most of the time :-)). The communication framework doesn't need additional testing by the user. The same applies to MDP frameworks. The user is only responsible for testing their specific business components (the plumbing is already provided). I would suggest to check the Jt Design Pattern Framework (reference) for MDP testing. The framework comes with a testing hardness that may provide additional clarification for the testing/QA aspects. As I mentioned earlier, I'm also glad that the main aspects of the paper were conveyed. Feel free to send any additional comments/questions that you may have. Please try to be as specific as possible so we can have a discussion based on factual/specific points and considerations. Happy Holidays for everyone
_______________________________________________ telecom-patterns mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/telecom-patterns
