james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <nor...@apache.org>
Subject Re: As Above, So Below
Date Fri, 20 Nov 2009 18:13:24 GMT
Hi Simon,

im still confused, But sometimes a little Bit Code can help others to
get it.... So please show us some code.

Bye
Norman
2009/11/20, Simon Funnell <simonfunnell@googlemail.com>:
> Hi,
>
> I've been studying the code base and evaluating which approach is the
> best to take. At present, I will try to clarify the framework
> architecture I am using as 'evangelising' might actually be quite
> effective. Firstly, there is nothing new to learn, the architecture is
> exactly the same as the internet. Applications are networks of machines
> and each machine on the network is a component of one or more
> applications. Each machine/component specialises in doing one small job
> very well, for example you could have a network of machines/components
> that do something like the following.
>
> Machine 1's job is to listen on a port for new client connections, when
> a new client comes along, it is accepted and the resulting socket is
> contextualised. A context is basically an object that maintains state,
> such as application/session/request or whatever is relevant. This
> context/state is then dispatched to Machine 2.
>
> Machine 2 will now alter the context state by reading bytes from the
> socket and buffering them in some suitable form before dispatching to
> Machine 3.
>
> Machine 3 is responsible for taking the buffered content and parsing
> into some sort object model, like an email. If an error occurs this
> machine will forward it to an exception handling machine which
> implements the exception policy of the system (Machine 4?). Otherwise,
> it is sent to the next machine (Machine 5?) which does some sort of
> matching or something
>
> And so on.
>
> Now if we want to do some logging at any time, we just put a logging
> machine in between Machine 1 and 2 or between 2 and 3 to check socket
> state, buffer state or some other combination of properties.
>
> To relate this somewhat to James, you are currently using Guice to wire
> components together and.this is equivalent to defining a network. With
> the design I am following there is not really a configuration as such,
> they are basically replaced with policy statements and change logs,
> which are a kind of configuration. Its fair to say James would be a
> network of machines defined by a policy statement. These policy
> statements can be large or small and applied to new or already running
> systems. Newer policy statements always supersede older ones (unless a
> prior policy forbids it). James already has a fairly substantial default
> policy statement like thing, its configuration files. However, to
> understand the benefits of policy statements, instead of configurations,
> it is worth looking at a small example.
>
> In this example I have an installation of James, it does not do any
> logging at present but I want to do some. And this is what I want to do:
>
> For the next two days, between the hours of the 3-5 pm, if a client
> using the SMTP service invokes the Expn command and has a IP address
> matching some address log some information to this file in this format
> and if its between 3.45pm and 4.00pm send me an email with such and such
> information.
>
> This policy is expressed (but doesn't have to be) as an XML document.
> The document is evaluated and the necessary machines are added to the
> network to implement the policy. How the policy is defined and
> implemented is system independent. The new machines added to the network
> that implement the policy usually simply fit in between two existing
> machines and do stuff like filtering, logging, security and anything
> that makes logical sense (putting a logging machine that records
> information about a http request in an smtp service doesn't make logical
> sense). Here, Java is used to create very small, highly robust units of
> functionality with XML policy statements (closer to natural language and
> easy to learn for users) stating how the machines should interact. The
> sophistication of policy statements is increased as the size and
> collective ability of a community of machines/components in a given
> installation grows.
>
> The current mailets and matchers are sort of ideal for use in this
> system as they can (in principle) be easily wrapped/adapted or what not
> to become a network machine. A machine here is simply an object with a
> single method (I've been thinking about using the reflection api's to
> extract individual methods from existing James classes and assign them
> to individual machines but its not straight forward as the existing
> methods in James classes tend to mix concerns together, like application
> logic and writing to an output in a single method)
>
> I hope this is of interest, declarative logging is really easy to
> implement and requires no learning, only a subtle shift in approach.
> James could be implemented as a guice module and a policy statement, in
> fact it would probably would be fairly easy to generate guice modules
> from a policy statement. Its not a direct translation but they are not
> dissimilar in nature. Also I am actually thinking of employing guice
> myself to do a few things, I am not in competition with guice. I am not
> in competition with spring either because its got a load of stuff with
> it mine doesn't. That said, Platformed is not 'just another framework',
> it has features (an architecture) that make it distinct.
>
> I'm thinking about a re-factoring strategy but I am still learning James
> under the hood. Ideally I would like to convince you of the benefits,
> they are fairly obvious.
>
> Regards,
>
> Simon
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>

---------------------------------------------------------------------
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