Kevin Junghans

Have you ever looked back at old code you wrote and asked yourself, "Why did I do it that way?"  I do that quite a bit and found myself doing just that on the open source project VoiceModel  that I coordinate and contribute to.  I think it is healthy to question your method of coding as it can lead to refactoring that makes the code easier to understand and maintain, to name just a few benefits of refactoring. The section of code in question had to do with how states where created in a state machine.  VoiceModel has a built-in state machine that make it easy to build voice application call flows .  You add states to the state machine that represent actions like playing a prompt to the user or get input from the user from a telephone keypad or using speech recognition.  These states are specific to the voice part of the application, but you can also have states that perform background operations, such as a query a database.  The states that are u...

A while back we added support in VoiceModel for Reusable Dialog Components (RDC), which I discussed in a previous blog post .  It was an effective implementation but I kept thinking there must be an easier way to create and use RDC's.  After a looking more closely at SCXML and state machines  the answer came to me; composite state machines.  Harel State Machines allow for superstates which are composed of nested state machines.  When a superstate becomes active it first runs the nested state machine that is composed of.  This seemed like a natural fit for RDC's; just make them a nested state machine of the main state machine (call flow).  VoiceModel has been updated to provide support for composite state machines. A lot of other changes have been made to VoiceModel's state machine to make it easier to persist to something like SCXML, actions are now implemented with delegates or lambda expression, and conditions on transitions now support expressions ...

I have been doing some work with workflow engines lately and it got me thinking; what is the difference between a workflow and a state machine? Further reflection had me wondering whether a voice application call flow is best represented by a state machine or a workflow. Discussions I had while working with the VoiceXML Forums Tools Committee raised a third option of using rules engines for more complex applications.  So what is the best option for implementing a voice application? To determine this lets examine what each method of modeling application logic actually is.  But first lets make sure we are on the same page as to what a voice application call flow is. Voice/IVR application call flows are usually designed on paper prior to implementation. This design shows the possible paths a user can take through the voice application depending upon their responses and data that is returned by external and internal systems. A common method of depicting call flow is to use...