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.
http://fisheye6.cenqua.com/browse/openejb/trunk/openejb3/container/
openejb-core/src/test/java/org/apache/openejb/core/stateful/
Compat3to2Test.java
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 :)
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
