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.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
