James as a distributed enterprise application suite

[Juan Carlos Murillo <mu...@inet.co.cr>]

After reading the thread on container replacements I must say that I
have worked with Spring and it is an excellent unobtrusive container
that completely decouples your components, without introducing any
strange looking construct into your classes.  It's very noninvasive.  I
think the move to POJOs is a wise one that flows with the current
industry's inclinations.

Spring however, like other containers, assumes that the application is
not distributed.  There are reasons to think that James as a central
server, with protocol specific subservers, is a very good candidate for
becoming a distributed application.  From the enterprise level this
would be a really valuable enhancement as it would allow you to deploy
several smtp servers, for example, in separate machines, without
impacting the performance of, say, the POP or eventually IMAP servers.
This would also allow for building a central management console
(possibly web) that would control the server farm or cluster farm.  You
could do load balancing with a set up like this, for high demand
scenarios.  You could also have redundancy of services where the
independent server nodes consume from a queue.

In my mind this would mean that James would become an application in
itself, with the STMP, POP, NNTP, etc, becoming separate applications.
These applications could potentially run on a single machine or be
distributed.  They would communicate through a Message Queue mechanism
using JMS standards, thus allowing guaranteed delivery.

Such an architecture would require a rethinking of the internal
dependencies, which could not be managed by Spring in a distributed
fashion.  Hence, Spring would have to be a per application solution for
local dependencies, and some services would have to be centralized and
offered through a service locator pattern using the JMS bus.

The reason i bring this up is because it could potentially be a big plus
for the Enterprise aspect of James, but if a major refactoring is done
without planning for this type of decoupling, it will be too expensive
to try to propose it after the fact.

Any comments greatly appreciated,

-- 
Juan Carlos Murillo <mu...@inet.co.cr>


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org