When you are implementing a phone self-service application, it is virtually certain that your application will need to communicate with some kind of back-end system. You might need to read data from your CRM system to get customer information, read data from your billing system to present information about the caller’s last bill, make transactions (e.g. book a flight, change a price plan, or transfer money), read or write to a database, etc. Except for services that are just presenting static information, back-end integration is required everywhere. So as this topic seems to be omnipresent, let’s take a closer look at how you can integrate back-end systems with VoiceObjects.

This post is the first one in a series about back-end integration with VoiceObjects (based on release 9.1). The series will give a detailed overview of the different ways that VoiceObjects provides for back-end integration. It will explore the differences between the approaches, provide guidelines when to use which approach, and provide detailed use-case driven examples for each of them.

The following sections provide a brief overview of the types of back-end integration available with VoiceObjects.

Java Connector

A Java Connector allows the execution of a Java Bean for back-end integration. The Java Bean is executed directly in the Java virtual machine of the VoiceObjects Server instance and contains the integration code for the communication with the back-end system. The VoiceObjects Connector object directly calls the business method of the Java Bean to communicate with the back-end. As the integration code is pure Java, it allows all integration protocols that can be implemented in Java.

When to use a Java Connector?

• If you want to avoid an additional dedicated integration layer (2-tier instead of 3-tier)
• If your backend integration will be based on pure Java
• If you can’t afford any additional overhead like HTTP requests, assembling and parsing XML, web services calls, etc
• If your integration code does not change frequently

CGI Connector

A CGI Connector uses a web server as back-end integration layer. The VoiceObjects Connector object sends HTTP requests containing a VoiceObjects specific XML structure to the integration layer in the web server. When the integration layer receives the HTTP request, it processes the request XML document, it connects to the back-end system, calls the business method, and returns a response XML document via HTTP to the VoiceObjects Server instance.

As an alternative to the VoiceObjects specific XML structure, request parameters can also be sent as plain CGI parameters, and responses can be any XML structure.

As the CGI Connector only relies on HTTP requests/responses containing XML documents, the integration layer can be implemented using any programming language and technique that allows processing HTTP requests (e.g. Java Servlets, ASP, PHP, Perl, etc.).

When to use a CGI Connector?

• If you prefer a 3-tier integration architecture with a dedicated, decoupled backend integration layer
• If you want to eliminate the risk of bad integration code affecting stability and performance of the VoiceObjects Server
• If you are looking for maximum flexibility for the choice of programming language, application servers, and interfaces for the implementation of the backend integration layer

Web Service Connector

A Web Service Connector uses document-style SOAP web services for back-end integration. The VoiceObjects Connector object directly connects to the web service. If your back-end system already provides a document-style SOAP web service interface, no additional integration layer is required. If the back-end system does not provide a web service interface, an integration layer based on web services can be implemented (similar to the integration layer of a CGI Connector).

When to use a Web Service Connector?

• If your backend system already provides a document-style web service interface
• If you prefer a 3-tier integration architecture based on web services
• If you want to eliminate the risk of bad integration code affecting stability and performance of the VoiceObjects Server

Database Object

The Database object (introduced in VoiceObjects 9.1) allows direct access to a relational database management system (RDBMS) from a VoiceObjects application. The VoiceObjects Database object has direct JDBC connections to the database and uses SQL statements that are defined in the VoiceObjects application to retrieve, store, and manipulate data in the database. The results of Select statements are directly accessible in the VoiceObjects application.

When to use a Database Object?

• If your back-end integration is pure database access (i.e. your back-end is an RDBMS and you are accessing it directly)
• If you have to access a database and don’t want any additional overhead
• If you don’t require a dedicated data access layer
• If you want to avoid programming

Feature Matrix

The following table shows a comparison of some of the features of the different types of back-end integration.

	Java Connector	CGI Connector	Web Service Connector	Database Object
No additional components/integration layers required	X	-	(X) if back-end already provides web service interface	X
No communication overhead	X	-	-	X
Independent of programming language for integration	-	X	X	-
Works with virtually any type of back-end system	X	X	X	-
No stability or performance impact on VO Server due to bad integration code	-	X	X	X
Architecture with dedicated data access layer	X	X	X	-
No programming required	-	-	(X) if back-end already provides web service interface	X (SQL only)

What’s Next?

Following this introduction and overview post, there will be four more parts – one for each of the integration options – covering the details like architecture and concepts, sample code, as well as advantages and disadvantages of each approach:

• Part II: Java Connector
• Part III: CGI Connector
• Part IV: Web Service Connector
• Part V: Database Object

So stay tuned for the upcoming posts in this series.

Tags: Back-end integration, VoiceObjects 9.1

This entry was posted on Wednesday, March 17th, 2010 at 2:22 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.