This is very interesting. As I understand your proposal, it has or can have a centralized facility that knows and sets a stack of tasks that need to be done on each message, and puts all the messages in whatever state of progress throught their task stack into the same queue. Did I get it?
Alternatively, your message could have no knowledge about what needed to happen to it, each task could put its output into a unique queue (or one of several depending on the final state, e.g. ok vs error), and all the routing could be done by selecting which queue an mdb listens on. Maybe my interpretation that your idea involves putting all the messages through the same queue several times is wrong or not essential? It seems to me as if this could lead to fast steps waiting for slow steps, since the messages have to be delivered in order. One possible advantage of your scheme is that if a message didn't need a particular task done on it, it would never get to that task: with the queue connections the unnecessary task would have to know to do nothing except pass along that message. I'm not sure what other people think, but it has always seemed to me that javaspaces provide a more elegant way of doing this kind of stuff. However, I haven't had time yet to write a javaspace connector or find a fast persistent free javaspace implementation. Thanks for posting this interesting suggestion. david jencks On 2001.10.21 21:59:44 -0400 Dmitri Colebatch wrote: > I'm playing catch up with designing MOM style systems, and looking at > approaches for using MDB. What I'm thinking is having a "dispatcher > mdb" that receives the JMS message, and passes them on to the appropriate > SLSB that implements the logic. > > So here's a framework I imagine. > > All messages should be object messages, and the contained object must > implement the MethodInvocation interface, which has the following > methods: > > // the next thing on the list > public String nextTask(); > > // where should this go when finished > public Destination finalDestination(); > > // if something else needs to be done next > public void insertTask(String target); > > // a mechanism to stop the rest of the chain > public void error(); > > public Object getAttribute(String name); > public void setAttribute(String name, Object value); > > This object represents the invocation that needs to be done. > > The "task" represents a method that needs to be invoked. The context is > provided by the set/get attribute (like servlet chaining). A config file > maps the tasks to the class that provides the "message > handler" interface. This interface has two methods: > > public void init(HomeInterfaceProvider p); > public void handle(MethodInvocation mi); > > the first method provides a way for the handler to access a home > interface > it needs. This is simply a cache of home interfaces looked up by the MDB > and the MDB itself implements this interface. > > The second method is where the handler extracts the contents of the > message, and calls the appropriate SLSB. At this point, not all the > required information might be available int he invocation, a target can > be > inserted to gather than information, and another to retry with the > information present. For instance, in a typical e-commerce purchase, we > would need to: > - check the stock > - check the user's credit > - debit the user's credit card and place the order > > The servlet (or struts/webwork action class) sends a JMS message > somewhere > containing the request to place the order. The invocation object contains > the list of goods that need to be ordered, and is simply a request to > "place the order". The mapper knows what needs to be done, and inserts > the > tasks that need to be done (check stock/credit). > > This example probably doesn't do it justice, as its very simple, but I'm > thinking that something like this might be worthwhile. If you disagree, > or > there's something out there that does the same thing anyway, let me know > - > constructively please (o: > > cheers > dim > > > > > > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > > _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
