james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann" <bernd.fonderm...@googlemail.com>
Subject Re: JAMES technology uplift
Date Wed, 02 May 2007 11:45:29 GMT
On 5/2/07, Noel J. Bergman <noel@devtech.com> wrote:
> So we're talking about a major technology uplift for JAMES.  One piece being
> talked about is the replacement of our data store with JCR.  There are
> others ...
>
> 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)
>
>   - Data store
>
>   - Mailet Container

other important parts are

- User DB

- Server Management

- Message Orchestration

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

+1 (minus the "Period:")

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

>From my experience EJB incl. MDB does _not_ open options for
deplyoment, they _narrow_ them.
You would need an EJB container, and add much more footprint by the
way than by adding a JMS implementation.

There are so many lightweight and more flexible component models.
Spring also offers lightweight messaging, transactions etc.

> 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.
> Internally, the spooler can be implemented however it wants to be
> implemented.  We need to have an implementation, but someone could provide
> their own if they were so inclined.  The Mailet container breaks down to:
>
>   - Spooler: mechanism for moving messages amongst units of work
>   - Processor: addressable unit of work
>   - Mailet/Matcher: actual workers
>
> There needs to be (re-)scheduling, too, as described in my revised spooler
> notes.  I have though to implement scheduling as a shared service provided
> by a mailet, but it could be moved into a formally defined part of the
> Mailet Container environment.
>
> So the touching points can be quite small: JCR for a unified data model, and
> some means of initiating message processing (JMS or other, as appropriate
> for whatever hosts the spooler).

+1 for the basic architectural approach.

One important observation to add: We are talking about general
architectural overview and what backends to use for some concerns
(storage, message proc).

But. What is completely missing is the important glue in between. The
APIs which describe how components interact and what each component
does. And I am not satisfied how it is done ATM. The object model
would need to be revisited nevertheless.

  Bernd

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


Mime
View raw message