On 2001.10.23 23:27:28 -0400 Dmitri Colebatch wrote:
> On Tue, 23 Oct 2001, David Jencks wrote:
>
> > 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?
>
> so say one task is a "retrieve user info" task. This task needs to be
> executed before a number of other tasks, "login", "send password",
> etc... So I should send a message to the retrieve user info task, which
> then populates the message with the user info, and sends it to its output
> queue. I should then configure the login and send password MDBs to both
> listen to that queue (topic would be required here wouldn't it?). I'm
> not
> sure how you propose which subsequent task is executed. Is it the case
> that there is something int he message, and some filtering done at the
> next MDB, or is there something else I'm missing?
>
> cheers
> dim
This is my first adventure with ASCII art....
lets try thinking of this as a finite state machine and draw pictures (even
if all the transitions are triggered internally by "I did my task"). Start
with two tasks A and B. As I understand your dispatcher idea it looks like
this.
A
/ \
/ \
\ /
\ /
input ----- Dispatcher ------output
/ \
/ \
\ /
\ /
B
I'm suggesting
input ------ A ----- B ----output
With either state machines or jms, I don't know of a way to wait for two
inputs to perform a state transition/do a task.
You can do
B -------
/ \
/ \
input ----- A E---output
\ /
\ /
C ------D
where B and D feed into to the same output queue, or you could have 2
copies of E listening to 2 output queues. (E here only takes one input, but
that one input can come from B or D).
It seems to me that the essential difference here is that in your proposal
the Dispatcher has all knowledge of what to do next, whereas in mine this
is set up in the queue subscriptions (or the state machine transitions).
So, my question is, what do you gain by having a dispatcher? It seems to
me that most or all of the time it will be computing dynamically what is
set up statically in its absence. What kind of computations could it do to
determine the next task that would not be more appropriate in one of the
tasks? (the result of this computation by the task would be the selection
of the output queue). I could easily be missing the point, but I don't get
it yet.
If the connection of mdb to input queues is currently hard to configure,
maybe an easier to use configuration tool would be appropriate.
Thanks
David Jencks
>
>
>
> _______________________________________________
> 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
