james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: Merging plan (was Build process in maven?)
Date Thu, 30 Oct 2003 14:58:59 GMT
Danny Angus wrote:
> In fact the more I look at this the more tempted I am to suggest we go one
> step further and implement all of our services as EJB's (or explore what
> avenues Avalon provides for distributing our services) as this would give
> admins the choice of installing James as a single local application, or of
> distributing the services across a range of JVM's or hardware.

I'm sure others will point out we don't need to adopt EJB spec to do 
this. :)

> Imagine if James could have a POP3 or IMAP server (Both would be my
> prefrence BTW) on one machine, the incoming SMTP server on another, mailets
> capable of calling services (like outgoing SMTP) running elsewhere again,
> more than one machine acting as worksharing spool managers, and each
> repository being run directly on the hardware providing the storage.

Since EJB is a rather "loaded?" term, could you give specifics on what 
migrating to EJB means?

The two things I can think are:
1. Use session bean notion where appropriate.  For example, maybe that's 
how the spool works.
2. Adopt JMS to route messages between the different queues and spools.

JMS is probably my least familiar EJB technology, but as we've somewhat 
already agreed that we want to separate mail repository from spooling 
notions, JMS might fit very well.

> We I suspect would then be able, using our current workflow, to offer
> scaleability, redundancy and fail-over for almost every service.

Again, not sure this is directly tied to EJB.  Granted there is much 
more work (that I can see) creating EJB containers that support 
distributed notions than Avalon containers, but I don't think either 
gives up much right now.  I'm still waiting for the Avalon containers to 
stabilize basic server features like friendly configuration errors, 
logging management, stuff like that, and am looking forward to the new 
releases we'll get with 3.0.

Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com

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

View raw message