james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: JAMES technology uplift
Date Thu, 03 May 2007 05:29:59 GMT

On May 2, 2007, at 3:36 AM, Stefano Bagnara wrote:

> Noel J. Bergman ha scritto:
>> [..]
>> Conceptually, JAMES is made up of the following pieces:
>>   - Wire level protocol handlers, which break down into:
>>     - Incoming Message Acceptors (e.g., SMTP)
>>     - Incoming Message Providers (e.g., POP3)
>>     - Outgoing Message Delivery (e.g., RemoteDelivery)
> We have all of them (you forgot fetchmail)
> - Outgoing messages via PUSH model (remotedelivery)
> - Outgoing messages via POP model (pop3server/imapserver)
> - Incoming messages via PUSH model (smtpserver)
> - Incoming messages via POP model (fetchmail)
>> [...]
>> The parts can be implemented as POJOs, but they need to know how to
>> communicate.  We need to balance flexibility with implementation  
>> of random
>> ad hoc interfaces.  For example, if we adopt JCR, we should  
>> document how we
>> are using it, and provide some convenience wrappers for common  
>> things that
>> we do, but we should not try to create another abstraction for  
>> storage.  The
>> JCR *would be* the abstraction.  Period.  In other areas,  
>> POJOfication
>> allows a lot of flexibility, but we still have to build a working  
>> server.
> About JCR being the abstraction "period", I would say.. "maybe comma"
> ;-) Let's see it working before placing periods.
>> Danny raised an interesting idea, which would be to host the  
>> mailet pipeline
>> in an EJB container, e.g., OpenEJB.  My revised spooler notes from  
>> way back
>> when also made some mention of the possibility of using an MDB,  
>> but I hadn't
>> really given much thought to actually running JAMES in an EJB  
>> container.
>> However, although there may be some initial resistance, it does  
>> make some
>> sense.  For one thing, it provides a standard platform for JAMES,  
>> and opens
>> up lots of options for deployment.  So how might this work?
>> Once the SMTP server has put the message into JCR, a JMS message  
>> can be sent
>> to a destination attached to an MDB, which in turn invokes the  
>> spool manager
>> to start processing the message.  By providing two standalone  
>> methods:
>> message storage (JCR) and messge processing initiation (JMS), any  
>> Java code
>> could provide messages for a pipeline.  A pipeline, not *the*  
>> pipeline,
>> because the JMS destination would be a configurable means to  
>> determine where
>> the message starts processing.
> So you revamped JMS, too ;-)
> I'm fine with JCR and JMS (if they satisfy our requisites). I  
> prefer to
> not require a full J2EE stack for running it.

Just an FYI, OpenEJB is extremely non-intrusive and it's very easy to  
use as "just a library" in various ways.  We of course support the  
standard "setup the server, put apps in server" model, but the "put  
ejb container into the app" is just really handy in many a case;  
junit test cases for one, but also for projects that are more or less  
platforms themselves and aren't interested in loosing the spot of top  
dog :)

Don't know what you all had in mind, but I figured I'd let you know  
that it is possible to invert the whole container/app relationship  
with OpenEJB.


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

View raw message