Màquines d'estat en JAVA

Gestionar els estats dels objectes en un entorn multi-thread, orientat a events, és complexe. Especialment si el mateix event pot provocar diferents accions depenent de l'estat sobre el que s'aplica.

Potser si parlem d'un problema en concret resultarà més fàcil comprendre la problemàtica. Vaig començar a enfrontar-me a aquest repte quan desenvolupava protocols en temps real per a la transmissió de veu. En concret, si miren la RFC sobre SIP, https://www.ietf.org/rfc/rfc3261.txt, una transacció servidor de SIP INVITE estaria descrita per:

                               |INVITE

                               |pass INV to TU

            INVITE             V send 100 if TU won't in 200ms

            send response+-----------+

                +--------|           |--------+101-199 from TU

                |        | Proceeding|        |send response

                +------->|           |<-------+

                         |           |          Transport Err.

                         |           |          Inform TU

                         |           |--------------->+

                         +-----------+                |

            300-699 from TU |     |2xx from TU        |

            send response   |     |send response      |

                            |     +------------------>+

                            |                         |

            INVITE          V          Timer G fires  |

            send response+-----------+ send response  |

                +--------|           |--------+       |

                |        | Completed |        |       |

                +------->|           |<-------+       |

                         +-----------+                |

                            |     |                   |

                        ACK |     |                   |

                        -   |     +------------------>+

                            |        Timer H fires    |

                            V        or Transport Err.|

                         +-----------+  Inform TU     |

                         |           |                |

                         | Confirmed |                |

                         |           |                |

                         +-----------+                |

                               |                      |

                               |Timer I fires         |

                               |-                     |

                               |                      |

                               V                      |

                         +-----------+                |

                         |           |                |

                         | Terminated|<---------------+

                         |           |

                         +-----------+

O bé dones amb una manera senzilla d'implementar aquest problema o acabaràs tenint codi difícil d'escriure, mantenir, propens a errors, dificil de testejar i impossible de tracejar. T'adonaràs que estàs en aquesta situació si téns un munt de if/else, synchronized i t'has passat els últims 2 dies intentant entendre perquè la teva aplicació ha arribat a un estat concret que no esperaves.

Si t'has trobat en algun moment en aquesta situació, hauries de fer un cop d'ull a la meva llibreria https://bitbucket.org/xferro/sicoris-statemachine . Fins i tot, hi ha un SNAPSHOT disponible en cas que vulguis començar a provar-la.

Qualsevol comentari és benvingut. Espero que ho gaudiu!

Máquinas de estado para JAVA

Manejar los estados de los objetos en un entorno multi-thread, orientado a eventos, es duro. Especialmente si este evento puede provocar diferentes acciones dependiendo del estado sobre el que se aplique.

Quizás sea más fácil entenderlo con un problema concreto. Empecé a pensar sobre este problema cuando desarrollaba protocolos en tiempo real para voz. En concreto, si miramos la RFC sobre SIP https://www.ietf.org/rfc/rfc3261.txt, una A SIP INVITE server transaction tendría una pinta como sigue:

                               |INVITE

                               |pass INV to TU

            INVITE             V send 100 if TU won't in 200ms

            send response+-----------+

                +--------|           |--------+101-199 from TU

                |        | Proceeding|        |send response

                +------->|           |<-------+

                         |           |          Transport Err.

                         |           |          Inform TU

                         |           |--------------->+

                         +-----------+                |

            300-699 from TU |     |2xx from TU        |

            send response   |     |send response      |

                            |     +------------------>+

                            |                         |

            INVITE          V          Timer G fires  |

            send response+-----------+ send response  |

                +--------|           |--------+       |

                |        | Completed |        |       |

                +------->|           |<-------+       |

                         +-----------+                |

                            |     |                   |

                        ACK |     |                   |

                        -   |     +------------------>+

                            |        Timer H fires    |

                            V        or Transport Err.|

                         +-----------+  Inform TU     |

                         |           |                |

                         | Confirmed |                |

                         |           |                |

                         +-----------+                |

                               |                      |

                               |Timer I fires         |

                               |-                     |

                               |                      |

                               V                      |

                         +-----------+                |

                         |           |                |

                         | Terminated|<---------------+

                         |           |

                         +-----------+

Si no das con una solución fácil para implementar esta máquina de estados, acabarás teniendo un código: difícil de escribir, difícil de mantener, error-prone, difícil de probar y imposible de tracear. El signo que estás en una situación similar es que tienes un montón de if/else, synchronized y y te has pasado 2 días intentando encontrar cómo has podido entrar en un estado que no tenías previsto.

Por tanto, si te has encontrado con este problema, deberías mirar mi solución. Acabo de finalizar una nueva iteración sobre el código y estoy muy satisfecho del resultado: https://bitbucket.org/xferro/sicoris-statemachine . Hay un SNAPSHOT disponible si quieres empezar a probar.

Cualquier comentario es bienvenido! Espero que lo disfrutéis!

State machines for Java

Managing object states for multi-threaded applications is hard. Especially, when this state can transition to another state depending on multiple events. 

I started thinking about this problem when implementing SIP protocol solutions. A SIP INVITE server transaction would look like:

                               |INVITE

                               |pass INV to TU

            INVITE             V send 100 if TU won't in 200ms

            send response+-----------+

                +--------|           |--------+101-199 from TU

                |        | Proceeding|        |send response

                +------->|           |<-------+

                         |           |          Transport Err.

                         |           |          Inform TU

                         |           |--------------->+

                         +-----------+                |

            300-699 from TU |     |2xx from TU        |

            send response   |     |send response      |

                            |     +------------------>+

                            |                         |

            INVITE          V          Timer G fires  |

            send response+-----------+ send response  |

                +--------|           |--------+       |

                |        | Completed |        |       |

                +------->|           |<-------+       |

                         +-----------+                |

                            |     |                   |

                        ACK |     |                   |

                        -   |     +------------------>+

                            |        Timer H fires    |

                            V        or Transport Err.|

                         +-----------+  Inform TU     |

                         |           |                |

                         | Confirmed |                |

                         |           |                |

                         +-----------+                |

                               |                      |

                               |Timer I fires         |

                               |-                     |

                               |                      |

                               V                      |

                         +-----------+                |

                         |           |                |

                         | Terminated|<---------------+

                         |           |

                         +-----------+

If you don’t think of an easy approach to representing/coding these state machines, you will end up having something: difficult to write, error prone, difficult to test and impossible to trace. The main sign that you are doing it wrong is when your code is full of if/else, synchronized blocks and you had to debug for 2d to find out how the hell you ended up in such an unexpected state.

So, if you happen to have to manage complex state objects, you should take a look to my library. I just finished a new iteration to the code and. Much happier than ever with it: https://bitbucket.org/xferro/sicoris-statemachine . There's already a SNAPSHOT version available, so you can use it already.

Any feedback is more than welcome!