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:40:26 GMT

On May 2, 2007, at 10:29 PM, David Blevins wrote:

> 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.

Here we go, here's a small example that configures/creates a stateful  
container and related support (transaction, security, jca connection  
manager) and then deploys an bean in and immediately looks it up and  
invokes it.  No config files required, you get full programatic  
control if you want it.


This example doesn't use business interfaces, but you probably  
wouldn't use session beans anyway (guessing MDBs) unless you wanted  
to write say an admin console that you could wrap with fat client,  
web, or web services front ends.

Ok, I'll leave you alone now :)


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

View raw message