[jdev] Re: Re: architecture questions

[Joanne]

I know that the use of a mail server has been mentioned a few times, but that isn't the type of model we want to employ. Maybe there was some misunderstanding on what my implementation goals are. My current model implements a single jabberd 1.4.3 client that manages it's own queue to compensate for the immediate delivery mechanism of jabber. The "big" little client, as I like to call it, just does too much -- it both queues and processes. Ideally, I want to have a bunch of jabberd clients (all performing the same processing, dedicated only to processing, but totally independent of each other). These clients should all be connected to a central message server that has logic to queue messages destined only for these available clients, and to forward a message only if an available client asks for one. I don't want to lose the immediate delivery mechanism that jabber supports-- my clients all have the need be be able to deliver asynchronous messages in near real time back to a message source -- but I need the server to be able to manage the incoming delivery of messages to these specific clients.

I think my current frustration with jabber is based on what I thought it could do out of the box. It does not apparently behave like a true MOM, and in order to get it act like so, would require some real dedicated customization. While it does support store & forward, it comes with a huge *BUT* -- but only for "offline" messages.

At this point, the only way to effectively use jabber as an MOM in the type of model I wish to employ is to implement a component (as Mr. Millard suggests), which could manage the queuing, load balancing, & all that custom message request/forward stuff my scalable clients need. 

Thanks again for your comments. They have all been extremely helpful and informative. 

"Peter Millard" <me at pgmillard.com> wrote in message news:016d01c3fa6c$466d3540$e201020a at pmillard2k...
> Peter Saint-Andre wrote:
> > The whole point of Jabber is decidedly *not* store-and-forward, it is
> > immediate delivery. If you need POP, maybe implement all this using a
> > mail server.
> 
> You may also be able to get what you want by using a pubsub mechanism. See
> JEP-60:
> http://www.jabber.org/jeps/jep-0060.html
> I agree with stpeter though, jabber is designed for near-real-time delivery. If
> this doesn't fit your model, then maybe using something like an email server
> would work better. Also, if you _always_ have at least one client connected,
> offline messages would never exist. You also can comment out mod_offline in your
> config file to turn off store-and-forward. This would mean that if a "client" is
> not connected, then the message would bounce.
> 
> You could also write a component which JUST does the load-balancing stuff and
> does it's own store-and-forward... so when one of your custom clients comes
> online, it could either use JEP-013 or some custom protocol to fetch the
> messages currently stored in that component. This component could also be
> responsible for doing the round-robing load-balancing instead of relying on
> priority changes.
> 
> There are always lots of ways to solve the problem.
> 
> pgm.