I came accross Spring state machine a few days ago. I was trying to use it in a project I was involved in. That seems, at first glance, to be a perfect fit given we are using spring boot in the project.
Unfortunately, I quickly found few important problems for meeting our requirements.
- I find it was difficult to manage custom exception without doing some hacking in the framework
- I need to instanciate a couple of state machines using a pool as it is recommended to not maintained state machine by sesssion or by thread.
- A spring state machine can only send one event a given time. That seems to me very inconvenient even if changing state is quite a quick task.
- In one work : the framework is state full and I don't know why it has to be that way
Discussion
When I dig a bit into the code source, I realized spring state machine is wrong to manage transitions along with the current state. From my understanding, transitions could be implemented as likely static configurations that is not subject to modification while the current entity may be changed. If transitions are practically immutable, they can then be shared accross threads without any concerns.
So, I implement a simpler solution that keeps the transitions in a good Map like Object. I have update this post to call it a state manage. With this set up, there is no need for synchronisation. A single instance of this State machine can be shared accross thread or create on fly.
Here is how the transitions could look like for simple states :
[Source states, event] --> targetState
So a simple get with the event and the current state of your domain object allows to create build the key for the Map.
Adding Guards actions to the state machine is just a decoration of the initial get of the map like object.
This is a very basic solution that works well for simple state machine. This would not probably about handle complex with regions and sub states. Higher abstractions may be needed. But this a very good starting point.
This is a very basic solution that works well for simple state machine. This would not probably about handle complex with regions and sub states. Higher abstractions may be needed. But this a very good starting point.
Conclusion
State Machine is very usefull programming tool and they appear so often in business requirements. But for me, it's a mistake to meld them within business code. They need to be isolated. Unfortunately, I have not found so far a good and easy implementation in java.
In the next post, I will try to demo a more involved version I have successfully implemented as a state manager to maintain and extend an existing approbation system . I've put the code in github. Work in progress...
I really think that a simple state manager which works as an internal application service class is a better solution than a full state as described in the literature. It allows to reuse existing application solution for persistence, business rules, object scope and so on.
In the next post, I will try to demo a more involved version I have successfully implemented as a state manager to maintain and extend an existing approbation system . I've put the code in github. Work in progress...
I really think that a simple state manager which works as an internal application service class is a better solution than a full state as described in the literature. It allows to reuse existing application solution for persistence, business rules, object scope and so on.
Thanks for your comments.
See post :
See post :
