Architectural Prototype Design

To implement the proposed architecture, we use a proof of concept that includes sub-sets of the service, the composition and the management planes. We present some of the assumptions, and the architecture of the prototype and the software tools used to implement it.

4.2.1 General Assumptions

We assume that the infrastructure layer is composed of five substrates that are announcement player, voice recorder, key detector, extension detector and call transfer. We further assume that the substrates are supplied by substrates providers SubP1, SubP2, SubP3, SubP4 and SubP5 respectively. We further assume that we have one infrastructure provider InfP, one platform provider PP, and two service providers ServP1 and ServP2. The substrates are described using Donkey State Machine DSM that represents the substrate behavior as a state machine. The use of DSM is motivated by the fact that it is used by the SIP Express Media Server (SEMS) used in our prototyping environment, and because it eases the composition of the substrates. DSM enables a textual description of applications that can be directly executed by interpreters hosted by the SEMS.

4.2.2 Prototype Architecture

Figure 4.1 gives a general overview about the architecture of the proposed prototype. Our architecture is based on RESTFul web services. The service provider (ServP) can discover all the available IVR substrates using the GET method. The service provider can compose its new service by selecting some or all the discovered services displayed on the platform provider (PP) GUI. Then, the service will be activated and the required resources for this new substrate will be reserved. Using the PUT method the new service will be published into the broker. As a result, the ServP can be able to provide the service to the clients and other application to execute it.

Figure 4.1 General Prototype architecture

Based on the general assumptions we described above, we will present a case study which covers the application development steps including mainly the publication, and the discovery phases. For the publication and the discovery phases, Figure 4.2 depicts the interactions between the InfP, SubPs and the broker. At first, the five substrates are published into the broker so that PP and InfP can discover them later. The exchanged requests in this step are Restful (PUT and GET requests). Each substrate provider publishes its services to the broker using a PUT request with an attached WADL description of the substrate. Next, the platform provider sends a GET request to discover the list of published services. The obtained list is then available to the platform provider through the GUI.

Figure 4.2 Substrate Discovery and Publication

4.2.3 Architectural Environmental Settings

To implement the proposed prototype, we used several software tools which were used to create, manage IVR substrates and execute IVR services. This section is dedicated to describe the architectural environment settings used in the test scenarios that will be discussed in the next section.

4.2.3.1 SEMS

The Donkey State Machine (DSM) module is used to implement IVR substrates which are deployed using the Sip Express Media Server (SEMS). SEMS is a free, open source and scalable server for VoIP services. It handles the media processing for the applications using IVR services. It supports the basic call and audio functions and many types of plug-ins may extend its system. It offers also conferencing and voicemail services. Developers can extend it by creating their own plug-ins based on SEMS framework API in C++, python or the DSM.

DSM is a powerful service scripting development platform. Actually, it offers a textual description of applications which will be executed by the DSM module as application in SEMS. Service logic is considered as state machine; it contains states and transitions between the states. There are conditions between the states; they are checked when an event occurs and if the conditions matches then the transitions are made. The transitions are associated with a set of actions which are executed on entering the state and on leaving the state as illustrated in the Figure 4.3. An example of DSM file is given in this figure with two states BEGIN and END. The first state allows to play a file and then when 1 is pressed by a caller, an event is occurred, the transition is made and the action will be executed which is Stop in this case.

Figure 4.3 DSM Example 4.2.3.2 Interfaces and Repository

Interfaces in the implemented prototype are deployed using Jersey which is an open source reference implementation of JSR 311 to build RESTFul web services. The interfaces are deployed on a Glassfish Server and have a socket communication with the SEMS server. Glassfish server is an open source

application server to deploy RESTFul web services. The substrate broker or the repository is based on Jersey and Glassfish Servers.

4.2.3.3 Java

In the service plane, we choose Java to implement the graphical user interface for IVR providers, we select Helios version Eclipse IDE (Integrated Development Environment) for java. Eclipse is an open source IDE that offers featured functions to build java applications and deploy them in Glassfish Server. It supports also Jersey APIs that we use to build the RESTFul web services.

4.3 Management Prototype Design