[ 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: https://svn.apache.org/repos/asf/directory/sandbox/niklas/mina-sm/ 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: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
