Jason Dillon wrote:
>
> +--------+---------+-------+ bus
> | | | |
> [p1] [c1] [c2] [p2]
> | |
> DB DB
>
> [px] are message producers (clients that are making requests)
> [cx] are consumers that can process client requests
>
> If [p1] puts a message on the bus for lets say authentication, the closest
> consumer is [c1]. [c1] reads the message looks up the information in the
> database, then sends a resposne back to [p1]. The same would be true for
> [p2] and [c2]. If for some reason [c1] went down, then messages from [p1]
> would be picked up by [c2].
>
> I am wondering if you have an suggestions or comments on building such a
> Bus infrastructure on top of SwiftMQ?
SwiftMQ's JNDI works like this. Clients are publishing their request to
topic 'swiftmq.jndi' and waiting for response on a temp queue. All JNDI
Swiftlets in all connected routers are receiving the request and, if the
administered object is stored there, sent back their response. The
client receives the first response, closes the temp queue, and delivers
it back as a result of lookup(). All other responses are discarded with
closing the temp queue. I think this pattern is applicable also for your
design.
--
Andreas Mueller, [EMAIL PROTECTED], IIT GmbH, Bremen/Germany, http://www.iit.de
SwiftMQ - JMS Enterprise Messaging System, http://www.swiftmq.com
------------------------------------------------------
SwiftMQ developers mailing list * http://www.swiftmq.com
To unsubscribe from this list, send an eMail to
[EMAIL PROTECTED] and write in the body of your message:
UNSUBSCRIBE developers <your-email-address>
Archive: http://www.mail-archive.com/developers@mail.iit.de/
