
Signature
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
wostaney@gmail.com wrote,
>> It means I can send any command in any time and receive messages
>> anytime if there are.
> That means you need at least two threads to deal with this. You might
> implement this with a queue you can add messages to be later sent ,
[quoted text clipped - 3 lines]
> Read about consumers and producers and queues. See
> http://mindprod.com/jgloss/queue.html
There is a resource-manager pattern that might work here, too, albeit somewhat
more complicated. It may be too much for this particular challenge, but it
comes in handy for all sorts of things.
Consider two programs that communicate via messages. With only those two, you
have two threads for duplex communication, a receive and a transmit channel,
as Roedy suggests.
You can also create a third program, a strictly server-mode, listen-only
"resource manager", call it M, that acts as a message broker (yes, like ORBs).
Both A and B operate in strict send mode with M. One channel is the "OUT"
box - it posts messages either synchronously or asynchronously to M for
further distribution to other participants. The other channel is the "IN" box
- it posts a synchronous request for incoming messages to M. M replies if and
only if it has something for the requestor, say A for now. A gets the
message, passes it through some processing logic possibly in another thread,
then immediately sends for another. Both the "IN" and "OUT" threads strictly
send to M, i.e., they are in client mode only.
M sits in a tight loop listening for messages or requests for messages from
its clients, and immediately forwarding the posted messages to agents or other
recipients for action.
The architecture is fan-in, fan-out. Messages and requests for messages fan
in to M and out to other participants. Participants can be segmented into
groups that have specialized purposes. A simple example is a dual population
of participants; on one side of M reside all the cconsumers, on the other side
all the provider agents. It's like a taxicab company, where all the riders
call in to Dispatch to ask for a taxi, and all the drivers call in to Dispatch
to announce their readiness for the next fare.
This is easily scalable to group communications (C, D and on can join in), and
to clustered M instances.

Signature
Lew
Lew - 29 Mar 2008 04:29 GMT
> M sits in a tight loop listening for messages or requests for messages
> from its clients, and immediately forwarding the posted messages to
> agents or other recipients for action.
"What if the destination isn't ready yet?" you ask? Excellent question.
M will need some storage to hold messages until their destinations finally
request them.
Likewise, if A calls for messages and there aren't any, M will put A on hold
until there are, then go back to looping for incoming dispatch orders.
M's loop is very fast, but it needs capacity to handle latency between its
clients. This is where Roedy's suggestion to use queues can be useful, also
stacks and deques. Java 6 has a panoply of such interfaces and their
implementations, e.g.,
<http://java.sun.com/javase/6/docs/api/java/util/Stack.html>
<http://java.sun.com/javase/6/docs/api/java/util/Deque.html>
I admit, it weirds me out that Stack inherits from Vector. Then again, it
does date from 1.0. Then again again, in Stack's Javadocs Sun advises
> A more complete and consistent set of LIFO stack operations is provided by
> the Deque interface and its implementations, which should be used in preference to this class.
It looks like Deque is Stack's ArrayList.
If you need concurrency, omigosh, there's a ton of that over in
<http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-frame.html>
Just read the class names down the list out loud: "AbstractExecutorService,,
ArrayBlockingQueue, ConcurrentHashMap, ConcurrentLinkedQueue, ...,
LinkedBlockingDeque, LinkedBlockingQueue, PriorityBlockingQueue, ...,
SynchronousQueue, ..."
Sheer poetry.

Signature
Lew