Actually, don't know what happened to my original post. I thought I replied to Messaging Design Pattern but it appears to have been sent to [email protected].
My apologies to Mr/Ms Sheppard. Phillip ----- Forwarded Message ---- From: phillip henry <[email protected]> To: Messaging Design Pattern <[email protected]> Sent: Tue, May 18, 2010 10:44:40 PM Subject: Re: [patterns-discussion] Messaging Design Pattern and transparent access to distributed components Hi, Ed, Thanks for getting back to me so promptly. > We don't believe type safety is really an issue I'm afraid that you may be in a minority. > DAO or iterator to give you a couple of examples How is the DAO pattern not type-safe? And doesn't Java use type-safety for it's Iterator (at least in JDK 1.5+)? > The implementation needs to handle any type of object Can you not achieve this with generics (eg, as in the Java API for java.util.Iterator)? I'm afraid that I don't believe that the JtInterface interface that has just one method: java.lang.Object processMessage(java.lang.Object message) constitutes a pattern. I did take a look at the JT framework. My main concern is that JT is trying to implement patterns for me. I believe this misses the point of what patterns are for. No framework can possibly know exactly what I am trying to do. If you take the Jt.JtStrategy class, for instance, how can this implement the Strategy Pattern for me if it doesn't know what particular problem I am trying to address? It can wrap my unit of work and give me a generic interface, for sure. But it lacks type-safety and replaces my self-describing method name with processMessage. How is my code any richer for this? Regards, Phillip ________________________________ From: Messaging Design Pattern <[email protected]> To: phillip henry <[email protected]> Sent: Tue, May 18, 2010 3:24:27 PM Subject: Re: [patterns-discussion] Messaging Design Pattern and transparent access to distributed components Phillip, There were several changes made to the paper based on comments received (asynchronous information). We don't believe type safety is really an issue. Many design patterns use Object for their implementation because the problem addressed is general in nature. DAO or iterator to give you a couple of examples. The implementation needs to handle any type of object. It is the same in the case of messaging. Any type of message needs to be handled. On the other hand, the implementation is not that vital when compared with the pattern/concept of messaging itself. The messaging concept is the main aspect. By the way, the type may be restricted (during implementation) to accommodate type safety. There may better implementations depending on specific requirements. Regards, Edgar --- On Sat, 5/15/10, phillip henry <[email protected]> wrote: >From: phillip henry <[email protected]> >Subject: Re: [patterns-discussion] Messaging Design Pattern and transparent >access to distributed components >To: "Messaging Design Pattern" <[email protected]>, >[email protected], [email protected], >[email protected], [email protected] >Date: Saturday, May 15, 2010, 2:00 PM > > >Ed, maybe I am reading this wrong but this is the same link and the same PDF >that you sent around on April 26. Why are you sending it again? > >I don't see the issue of type safety being addressed and I still see a > quasi-religious statement in the conclusion. I respect every man's religion > but documents that purport to be academic should really avoid such references. > >Regards, > >Phillip > > > > > > ________________________________ From: Messaging Design Pattern <[email protected]> >To: > [email protected]; [email protected]; >[email protected]; [email protected] >Sent: Fri, May 14, 2010 3:06:49 AM >Subject: [patterns-discussion] Messaging Design Pattern and transparent access >to distributed components > > >Dear List members, > >Thanks again for your feedback. Please find enclosed a link to the revised >document ( Messaging Design Pattern and a distributed component model): > >http://jt.dev.java.net/files/documents/5553/149793/distributedModel.pdf > >Additional information has been included in regards to asynchronous messaging >and fault-tolerant considerations. > >Ed > >Messaging Design Pattern and transparent access to distributed components and >services > >Abstract > >This paper discusses a distributed component model based on the > messaging design > pattern (MDP). This pattern is utilized to implement transparent and secure > access to remote components in a distributed environment. Our model also > demonstrates how software engineering processes and techniques can be > improved by using MDP. For instance, it has been used for the > implementation of Service Oriented Architecture (SAO) and Enterprise Service > Bus (ESB) technologies. At the core of these technologies lies the need for > communication between components and applications. This communication > challenge is exactly the one that MDP targets, models and solves. > >Let’s start by briefly discussing the Messaging Design Pattern. > > >Messaging Design Pattern > > >Intent: The messaging design pattern allows the interchange of information >(i.e. messages) between components and applications. > > >Motivations (forces): This design pattern can be applied to solve a great >variety of problems in many diverse scenarios. A messaging paradigm is widely >used in nature and the real world. Messages are interchanged all around us. >Entities are constantly sending, receiving and processing messages. Human >beings for instance: when we watch TV, listen to music, talk over the phone, >or communicate via the > internet. Right now, you are reading this written message. Since computer > applications seek to model the real world, it is only natural to design and > write applications using a messaging approach. We can argue that this > approach provides a more complete and accurate representation (i.e. model) of > the real world. As a consequence, 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 (Receiver): Component that receives the input message >and may produce a reply (output message) after processing it. The input >message, general in nature, may contain any type of information. The component >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. > Similar to the real world, it is often the case that the messenger is not > required. The message can be sent directly to the message recipient. Several > modes of communication are possible: synchronous, asynchronous and two-way > messaging. >d) Message: any piece of information (i.e. data) that needs to be >interchanged between sender and recipient. Two messages are usually involved: >input message and output message (or reply message). The reply message is not >required. >Structure: > > > > >
_______________________________________________ dacm-patterns mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/dacm-patterns
