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
The data store, e.g., JCR, is shared across space.
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.
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.
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).
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
