mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niklas Therning (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DIRMINA-160) Add support for defining higher level state machines on top of MINA
Date Thu, 08 Jun 2006 05:26:30 GMT
    [ http://issues.apache.org/jira/browse/DIRMINA-160?page=comments#action_12415278 ] 

Niklas Therning commented on DIRMINA-160:

I've checked in some code into my sandbox area which is a simple proposal for how this could
be done. Here's the Subversion URL:


I haven't had the time yet to write a good example. I guess StateMachineProxyFactoryTest could
be a good starting point. Just let me know if you have any questions. Now I'll try to explain
briefly how it works:

Basically, it let's you define a Finite State Machine (FSM) and hide that behind a dynamic
proxy which implements the interface(s) the outside world (the client) calls. In the MINA
case this interface is most likely to be IoHandler but it might as well be IoFilter or any
other interface. 

All method calls on the proxy object will be translated into Event objects which are fed to
the FSM. The method name becomes the id of the event and the method arguments become the event
arguments. So, if handler is a proxy which implements IoHandler the call handler.messageReceived(session,
message) will become the event Event("messageReceived", {session, message}).

The FSM is a directed graph where each node is a State object and the edges are Transition
objects. States can have entry and exit Actions attached to them which get executed when entering
or leaving the state. Transitions also have code attached to them which gets executed when
the transition occurs. Furthermore, a State can have a parent which makes it possible to inherit
transitions from other states.

When a new event occurs the current state will be fetched from the MINA session (it is stored
as an attribute). The state will cycle through it's transitions in the order they were added
and see whether any of the transitions can handle the event. If none of them can the state
will delegate to its parent state if there is one.

The Transition interface has a single execute() method returning a boolean which tells the
state whether the transition occured or not. 

The code so far includes one Transition implementation, MethodTransition, which let's you
point to a method on an object which you want to be executed when the transition occurs. Note
that it can be any method on any object, you don't have to implement a certain interface.

Futhermore, MethodTransition will make sure the method signature of the method you point to
matches a subset of the arguments of the event. It will also make sure the arguments passed
in the Event object are compatible with the signature of the method. E.g. if you have the
method parseError(IoSession session, ParseException pe) and you specifiy that it should be
called on exceptionCaught events it will only be called if the exception is an instance of
ParseException. If the method greetingReceived(IoSession session, POP3Greeting greeting) is
to be called for messageReceived events if will only be called if the message is an instance
of POP3Greeting. I think this is quite nice since it will eliminate a lot of type casts.

One problem with MethodTransition is that it relies heavily on reflection which can be slow.
However, I think the method matching stuff can be cached and the reflective method invocations
could be replaced with runtime generated byte code if necessary.

There are probably a bunch of other problems with this approach that I haven't thought of
myself so please have a look and let me know what you think. Is this something you would like
to see in MINA?

> Add support for defining higher level state machines on top of MINA
> -------------------------------------------------------------------
>          Key: DIRMINA-160
>          URL: http://issues.apache.org/jira/browse/DIRMINA-160
>      Project: Directory MINA
>         Type: New Feature

>     Reporter: Niklas Therning
>     Priority: Minor

> We'll have to provide some kind of FSM support. This should give users a set of best
practices for building complex protocols on top of MINA.
> Trustin had the suggestion that we could implement it very simply by implementing IoHandler
which demultiplexes events to an appropriate IoHandler implementation according to a certain
session attribute value.
> I guess we could provide some means for defining the states and transitions too.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message