On 5/2/07, Noel J. Bergman <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
