There are a few videos on youtube that explain the demo at:
https://www.youtube.com/watch?v=F19xFQIjNPM
https://www.youtube.com/watch?v=QmbKacwwSPk
https://www.youtube.com/watch?v=Urbztn0Wsac
See Also: https://github.com/Estafet-LTD/scribble-tool-chain-fsm
General description of the project: com.estafet.fsm.example is the main package with the finite state machine demo. test-data contains the scribble source file SupplierInfoNoFairBeta.scr, which is really the subject of the videos above.
FSMServer.java a basic FSM that runs taking a role name, an FSM config file, a fake DNS service as inputs and runs as either a client (waiting for user input from the command line) or a server (waiting for input from a socket or some other comms mechanism).
Sockets are fully implemented as a comms mechanism. I plan to add various other mechanism from JMS topics/queues as well as kafka.
The cloned repo is an eclipse project so installation right now is through exporting to an appropriate deployment folder. So the best way to set all of this up is to create, from the project zip file, the following folder structure and set up your env accordingly.
Deployment: Three simple steps to deploy: 1. export the runtime-folders to a suitable target folder. 2. make sure SCRIBBLEDIR is set to point to this folder. 3. refreshing the jar is a case of exporting the source as a jar into the lib folder as fsm.jar overwriting the one in the lib folder.
Running: To generate the behaviours from scribble you need to look at the STC project.
You can run any of the roles as finite state machines, which will communicate with others, pretty easily by doing the following for each role: ./fsm.sh role fsmConfig dnsConfig client|server delay
For example fsm.sh loginsvc loginsvc_config.txt ipconfig.txt server fsm.sh requestor requestor_config.txt ipconfig.txt client
A role maps to a role in the Scribble description. The fsmConfig is generated by the scribble compiler. The dnsConfig is specific to the Scribble example but can be edited as needed. The dnsConfig really maps roles to IP addresses and ports to facilitate communication amongst the roles running as separate processes. The client|server optional parameter tell the FSM instance to behave as a server and wait on a comms channel for input or as a client and wait for a user to do something (see below on ":" vs "?"). The delay just slows it down so you can see what is happening more easily, otherwise it happens way to fast.
The FSM instances will automatically progress to a next state if they have no other option.
There is a doall.sh script in the bin folder of the deployment and it generates the fsmConfig files and also generates a png finite state machine diagram in standard dot notation.
The running FSM will output "Command:" to indicate it is ready to move states based on a message from another FSM.
The running FSM will output "Command?" when it requires you to choose. The options are numerically encoded.