From: "Adrian Crum" <adrian.c...@yahoo.com>
--- On Thu, 4/1/10, Jacques Le Roux <jacques.le.r...@les7arts.com> wrote:
> Adam Heath wrote:
>> So each entity creation itself was a separate work
unit. Once an
>> entity was created, you could submit the primary
key creation as well.
>> That's simple enough to implement(in theory,
anyways). This design
>> is starting to go towards the Sandstorm(1)
approach.
>
> I just looked at that site briefly. You're right - my
thinking was a lot like that. Split up the work with queues
- in other words, use the provider/consumer pattern.
>
> If I was designing a product like OFBiz, I would have
JMS at the front end. Each request gets packaged up into a
JMS message and submitted to a queue. Different tasks
respond to the queued messages. The last task is writing the
response. The app server's request thread returns almost
immediately. Each queue/task could be optimized.
This makes remind me that it's mostly what is used
underneath in something like ServiceMix or Mule (ESBs).
ServiceMix is Based on the JBI concept
http://servicemix.apache.org/what-is-jbi.html
and uses http://activemq.apache.org/ underneath
Actually, the goals and designs are quite different. The goal of ESB is to have a standards-based message bus so that applications
from different vendors can inter-operate. The goal of SEDA (Adam's link) is to use queues to provide uniform response time in
servers and allow their services to degrade gracefully under load.
Yes, I saw that. It's only that it reminded me the matter of queues use also in
ESBs.
My idea of using JMS is for overload control. Each queue can be serviced by any number of servers (since JMS uses JNDI). In
effect, the application itself becomes a crude load balancer.
I see
Jacques
-Adrian
