What does Rivr buy me? Part 1

In the previous post, we’ve given you an overview of how Rivr works. We’ve seen that in order to realize an IVR dialogue, the developer simply needs to exchange various turns objects through the Rivr API.

Whether you are a Java IVR developer, a Java architect or a technical decision-maker, you should consider the following benefits of using Rivr:

Smooth learning curve

Learning Rivr is easy. You can begin by running a working example from the Rivr Cookbook. When compared to VoiceXML, Rivr has a smaller number of concepts. You can gradually explore features by looking at other examples and explore the API.

Simple tool set

Rivr only requires you to have 2 jar files. You probably already have your Java IDE and that’s all you need to develop your IVR application with Rivr. Since Rivr artifacts are pure Java code, you already have the tools for debugging, documenting, testing, reviewing, storing, sharing, packaging, verifying, building and refactoring. Rivr leverages all your Java tools and practice.

Vendor lock-in avoidance / portability

If you are unsure about a long-term commitment towards a VoiceXML vendor, Rivr can ease the switch to another platform. Since, as opposed to some graphical environments, the generated VoiceXML doesn’t target a specific VoiceXML platform, developing your IVR applications with Rivr is a strategy to protect your investment. Nevertheless, Rivr allows you to exploit any platform-specific extension if they need to be used. If you use any platform-specific extension, migrating to another platform only means finding another way to achieve the same result with the new platform.

Simplicity

A Rivr dialogue is just a regular Java method in which the developer performs calls on the dialogue channel in order to interact with the VoiceXML platform. To make a fully functioning application, you only need to write one single Java class, create a web.xml as you would do for any web application and your are ready to go. An application can thus be as small as required. By contrast, approaches where projects are generated from a graphical tool can make the simplest project huge and any newcomer can easily get lost in this jungle of generated (and mostly unused) artifacts, not being able to distinguish what parts are provided by the tool and what parts are application-specific.

Simplicity can also be observed at run-time. If you need to take a look at them, the generated VoiceXML documents are actually easy to understand. Since Rivr generates small focused VoiceXML documents, it’s easy to figure out what happens when the application runs. Each time an event occurs, it is sent back to the application. So you don’t need to figure out what has happened on the VoiceXML platform since the dialogue logic is implemented on the Java side. Most of the time, a simple look at the logs is enough to explain the observed behaviour.

Power and flexibility

Rivr comes with a predefined set of OutputTurns: speech-recognition and DTMF interactions, recording, call transfers (blind, consultation, bridge), subdialogue calls, messages (using audio files or speech synthesis) and client-side Javascript execution. With these primitive actions, you can do virtually everything you could do if you were authoring VoiceXML documents directly. If for some reason you wish to add other primitives to this built-in palette, Rivr allows it. Simply create a new class for an OutputTurn and specify how VoiceXML should be generated for this kind of turn. It is also possible to subclass an existing turn and tweak the VoiceXML generation. If you want to add proprietary extensions of your VoiceXML platform, you can use those customization mechanisms. So you can’t really get trapped; there is always a way to code your way out.

Better abstractions

Since everything is done on the Java side, it is much easier to create abstractions. For example, you can make an abstract base class for some kind of dialogue and add specific implementations which share a common dialogue logic. This illustrates that you can reuse your OOP skills in dialogue design.

Another idea: create a method that takes two dialogues as input: a collection dialogue and a confirmation dialogue. The method will invoke the collection dialogue and will then call the confirmation dialogue if necessary. This is dialogue composition. Think of all abstractions mechanisms in Java and use them in the design of your dialogues.

Better modularity and reusability

Dialogues can be placed in various methods within various classes. Reusable parts of the dialogue can be extracted into methods (static or not, as you like). The only constraint is that this method should have access to the DialogueContext, which can be solved by passing the latter to the method.

With such simple mechanisms, it’s easy to build a large library of reusable dialogue components.

Better integration in build and deployment process

Building a Rivr application simply means to compile the Java code and create a WAR (or an EAR). This is probably something you already do if you have in-house Java web development. So nothing new here, Rivr will fit nicely in your release engineering process. No need to figure out a way to integrate artifacts generation into an existing automated build process or using error-prone practice like relying on developers to manually trigger code generation from the diagrams.

Deployment process across different environments is as simple as deploying the web application on the appropriate web application server. Rivr isn’t tied to anything else.

Cleaner data flow and control flow

Vendors often sell graphical tools by pretending that “no developer skills are needed”. However, when you try to draw a callflow, you soon realize that you will need to deal with variables and flow control sooner or later.

Variable handling in graphical tools is usually a mess. They are defined here and there, they are global (they apply for all the diagram, and sometimes for sub-routine diagrams as well). What makes things worse is that diagrams don’t show them. You have to use many clicks on each box in order to figure out what happens to these variables. In short, you can’t follow you data flow. With Rivr, the data flow is clean because we are relying on a real programming language for that. The Java lexical scoping lets programmers declare and use variables where appropriate. When looking at code, it’s easier to follow assignments to variables.

Control flow blocks in graphical tools make simple things complicated. You need to edit the box to enter conditions, then you need to add arrows pointing to appropriate actions, add labels on the arrows, and add actions. If you are accustomed to use a programming language, you know that everything mentioned above can fit in a few lines of codes. Using Rivr, the control flow of your dialogue is simply expressed with the control flow mechanisms of Java (if/else, switch, for/foreach/do/while, try/catch/finally).

The fact that Rivr fixes the flow problems is the inspiration for its name (river, flow).


In the next post, we’ll look at more good reasons to use Rivr.

Share this:

About the author

Dominique Boucher
I am the CTO of Nu Echo, where I am in charge of leading the technology directions and help turn customer requirements into truly effective products and solutions.

Leave a Reply