james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anagha Mudigonda <anaghamudigo...@yahoo.com>
Subject Re: [ GSoC - failfast SMTP ] Architecture and suggestion
Date Thu, 14 Jul 2005 16:14:50 GMT
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 <james@mcbeelen.net> 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 <Danny_Angus@slc.co.uk> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message