yep - I hear what you're saying. thanks for the feedback.
cheers dim On Tue, 23 Oct 2001, 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
