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 <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
