> > > > > 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. > > > > it really gets down to messaging vs typical rmi calls doesn't it? As you > > mention below, javaspaces is very much what I'm talking about, isn't > > it. I suppose what I was thinking was that when a task was finished, if > > it needed something else done, it would specify the next task to be > > done. when the dispatcher got a message with no more tasks, it would > > send > > it to the final destination. output would be put as attributes in the > > message
I think the list of tasks and their order should be done external to both the messages themselves and to the individual tasks, i.e., in a config file somewhere/somehow. That way tasks can be added, removed or reordered without changing anything other than the config file. Makes the individual tasks and messages more autonomous and therefore easier to write, and also makes the workflow easier to manage. _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
