How is this better than simply having each task output its processed messages to a specific queue, and routing by hooking the receiving mdb's upd to the appropriate queue? I'm assuming that it is or could be easy to manage the queue subscriptions. Then you don't need the dynamic workflow manager at all. Am I missing something?
Thanks david jencks On 2001.10.23 20:16:53 -0400 Guy Rouillier wrote: > Only the immediate state is kept in the message, not the whole workflow. > The whole workflow is potentially quite large, and you don't want these > bloated messages travelling around; the overhead is too high. Messages > should be as small as possible. So what I'm thinking is that you > distribute > the workflow config file to all servers that are potentially involved > (solves a failover scenario nicely as a side benefit.) When a new > message > arrives at A, A checks the state in the message, which will be > uninitialized, so A knows that it has to start workflow on this message > with > task A-1. When task A-1 completes, the workflow manager reads the config > and determines the next task is B2. The workflow manager attaches the > current state to the message, either the last task completed A1 or the > next > task in line B2. I'd prefer the last task completed; that way when you > are > all done, the state will be the end of the workflow B4 instead of null > again, which would be indistinguishable from a message that hasn't been > started. The workflow manager on A then sends the message on to B. > > B gets the message, sees that it's current state is set to A1, the last > task > completed, so it knows that workflow has already been started. It reads > the > config file (the same one that A read) and determines the next task is > B2. > This process continues until the workflow is finished. At that point the > state is set to complete and the message is sent back to its source. > > Tasks and messages are completely independent. The workflow manager is > what > glues them together. > > ----- Original Message ----- > From: "Dmitri Colebatch" <[EMAIL PROTECTED]> > To: "Guy Rouillier" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Tuesday, October 23, 2001 5:54 PM > Subject: Re: [JBoss-user] MDB dispatcher pattern - opinions > > > > So you're saying that the info is stored in the message, and in config > in > > the servers? ie. When a server receives a message for B-2 it knows > the > > next destination must be A-3? Doesn't quite add up... how does one > reuse > > tasks individually. > > > > What I had been thinking was having the initial destination populate > the > > complete list of tasks (based on a config file) and send the message on > > its way. So A-1 may in fact not do anything, apart from create the > > message path of B-2, A-3, B-4 and send the message again. This way the > > configuration is confined to "B". Suppose I know of a JBoss server > > somewhere accepting SOAP/SMTP messages in this format, and I want to > use > > some functionality there, before doing something, then I wouldn't > > (presumably) be able to change the cnfig on that server.... > > > > am I making sense/did I understand what you suggested? > > > > 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
