Hi Marco,
Thank you for your comments.
>From what I understand you are proposing an
architecture based on MINA. Currently JAMES is built
on Avalon 4.0 server frame work. I have designed the
protocol handler framework in such a that it can be
ported to MINA as well.
The IN protocol framework expects the following 3
things from the underlying server kernel
ProtocolHandler to be run as separate thread
Socket object is passed to it
A mechanism to read the XML config file
In future if JAMES migrates to MINA architecture, I
think James.java can be modified and no change need be
done to the protocol handler framework that I am
proposing.
Best Regards
Anagha
--- Marco Beelen <[EMAIL PROTECTED]> wrote:
> Hello Anagha ( and of course many others ),
>
> Although I'm not an active developer for james yet (
> besides being an
> active user, which already is the case and very
> satisfied one ), I've
> been monitoring the mailing-list for some while and
> do have some ideas
> about the architecture of the product.
>
> Your design for the fail-fast SMTPServer triggered
> me to post my ideas.
> I'll start by some general outline of my vision
> about the architecture
> and finish with a suggestion for the Summer of Code
> proposal.
>
> Juan Carlos Murillo posted a message about James as
> a distributed
> enterprise application suite, which I agree upon.
> (
>
http://www.mail-archive.com/server-dev@james.apache.org/msg04325.html
> )
>
> I think implementations for a handler of a network
> protocol ( SMTP,
> POP3, IMAP and NNTP ) should be loosly coupled from
> spoolmanager and
> user- or mail-repositories. Access to the
> spoolmanager,
> user-repositories and mailrepositories should be
> able to be done eighter
> locally within the same JVM (
> single-machine-configuration ) of remotely
> ( possible using JMS ) in a 'clustered enterprice
> environment'.
> In order to make this work, we would have to
> seperate the front-end (
> the actual handling of the network protocol ) from
> the back-end (
> reading and writing to JamesConfiguration,
> UserRepositories,
> MailRepositories and the SpoolManager ). During the
> startup of a Server
> it should be configured on how to access the
> backend. Dependancy
> Injection ( by usage of Spring ) seems like a
> logical solution for that
> part.
>
> By doing this you could concentrate on the actual
> SMTP-protocol when
> writing an implementating for a SMTPProtocolHandler
> and delegate
> backend-interaction to a implementation of some
> 'JamesBackendInterface'.
>
> This could simplify the implementation of the
> failfast SMTP-server,
> especially since your design for the ProtocolHandler
> looks very simular
> to the design of MINA.
>
> "MINA is a network application framework to resolve
> all the issues
> concerned with implementing any protocol stack in
> Java without
> sacrificing performance nor scalability." MINA has
> been developed as a
> sub-project of the directory project of the ASF. ( I
> consider this as an
> indication of the quality of your design. )
>
> Therefor I would like to suggest that you take a
> look at Mina and
> consider it as the basis for your implementation.
>
> This is something which should be agreed upon by you
> and the active
> james-committers.
>
> Suggested materials for reading about MINA:
>
http://directory.apache.org/subprojects/network/index.html
> http://wiki.apache.org/directory/MinaTutorial
>
>
>
> I know this is properably a fuzzy description about
> my ideas for the
> architecture and I'm willing to clearify any
> questions about it.
> I'll start working on some UML-diagrams to improve
> the 'readibility' and
> put those up for discussion in a seperate threat.
>
> With kind regards,
> Marco Beelen
> The Netherlands ( GMT +1:00 )
>
>
>
> Anagha Mudigonda wrote:
>
> >Hi,
> >I did a little more work on the design and fixed
> some
> >mistakes. Attached is an updated design.
> >
> >awaiting comments ...
> >-- anagha
> >
> >--- Danny Angus <[EMAIL PROTECTED]> wrote:
> >
> >
> >
>
>------------------------------------------------------------------------
> >
> >
> >Introduction:The redesign of the SMTP protocol
> handler has the following design goals
> > - to enable in-protocol handling
> > - to have enough flexibility to implement SMTP
> protocol extensions without changing protocol
> handling code.
> >
> >The new framework is designed to address these. The
> framework contains the following classes
> > - CommandHandler
> > - ConnectionHandler
> > - SMTPSession
> > - SMTPProtocolHandler
> > - SMTPOutputStream
> > - SMTPInputStream
> > - an XML configuration file.
> >
> >The main change:
> > - Introduction of SMTPSession as a new interface.
> > - Things are more CommandHandler centric. The
> command handler has access to the SMTPSession. So,
> the command handler now has freedom
> to close a message or even close a session. But the
> SMTPSession interface is implemented in the
> james core code.
> >
> >Class ConnectionHandler
> >-----------------------
> >1. Registers to handle a connection
> >2. Registers to handle a message
> >
> >interface ConnectionHandler
> >{
> >void init(String configStr);
> >void processConnection(String local_hostname, int
> local_port, String remote_hostname, int
> remote_port);
> >void setSMTPSession(SMTPSession session);
> >void processMessage(Mail Obj);
> >}
> >
> >Class CommandHandler
> >--------------------
> >
> >A Commandhandler class
> >
> >1. Registers to handle a command ( may process or
> validate the command arguments)
> >2. Registers to handle a message (validate message
> or modify message header or body)(this is needed for
> situations like SPF failure, where the headers are
> updated if SPF fails.)
> >
> >interface CommandHandler
> >{
> > void init(String configStr);
> > void processCommand(String cmdString);
> > void setSMTPSession(SMTPSession session);
> > void processMessage(Mail Obj);
> >}
> >
> >Description: There can be more than one command
> handler registered for a command.
> >CommandHandlers can be registered to validate
> commands or modify message.
> >CommandHandler's *process* methods can trigger
> events like message start , message end and message
> abort
> >and session end, session abort.
> >
> >Class SMTPSession
> >-----------------
> >The SMTP protocol session maintains the state
> information and ensures that
> >the commands are executed in proper order. Also it
> provides controlled
> >access to I/O streams.
> >
> >The SMTP session can be in one of the 4 states:
> >1. SESSION_START ( as soon as the client connects
> to server)
> >2. SESSION_END ( as soon as the client Sends QUIT
> command or closes connection)
>
=== message truncated ===
Asatoma Satgamaya (Lead me From falsehood to truth)
Tamasoma Jyotirgamaya (From darkness to light)
Mryutorma Amrutangamaya (From death to immortality)
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
