Provisioning Complexity in JBoss and Glassfish

Ask most enterprise IT developers how to provision their application into a telephony infrastructure and I imagine you won't get many answers. IT applications have far different implications than a telephony applications. Furthermore, most IT developers and administrators do not know much about the telephony infrastructure. This is why an IT person trying to provision their communications enabled applications into a telephony system is overly complicated and therefore expensive. This complexity is exactly what solutions such as JBoss and Glassfish are trying to pass on to enterprise IT developers and administrators.

In our Communications Enabled Applications Feature Pack, we worked hard to significantly reduce the provisioning complexity associated with creating a communications enabled application. We built our telephony access services in such a way that keeps our services out of the flow of a telephone call. We did this using SIP CTI, a standard formally called ECMA TR/87 which many unified communications vendors provide solutions for. In other words, we left the telephony call flows to the unified communications vendors and kept ourselves out of the call flow.

If your communications enabled applications require new servers or services to be provisioned into your telephony environment, you have to become a telephony expert, learn how your machine will affect real time communications, and deal with your network side of your business which may not be thrilled to have IT applications in the network. The politics alone around trying to provision your application into your telephony infrastructure may make it impossible. Our Feature Pack for CEA avoids these issues and even helps you complete a POC without having corporate telephony access through our unit test environment.

On the other hand, JBoss and Glassfish implement something such as RFC 3725. Its not important to understand that RFC, but more important to understand the implications of that RFC. The call flow of RFC 3725 looks something like this:


In that call flow, the telephony access services is in the phone call the entire time. These services must know about every piece of communications between devices. For call notifications, every call, whether the phone is being monitored or not, must go through this controller. This is a provisioning nightmare and frankly this is why telephony providers offer their systems as hardware because the standard IT administrator does not need to know how to provision a system into a real time call flow.

SIP CTI, on the other hand, works in a different manner. In this, our telephony access services connects to a SIP CTI Gateway provided by the unified communications vendor. That gateway is in the call flow while the SIP CTI client gets asynchronous messages letting it know what is going on with the call or phone.


Utilizing SIP CTI, we are able to stay out of the call flow and avoid passing the complexity of provisioning a IT application into a real time communications environment on to our users whereas with JBoss and Glassfish you are stuck knowing all the details about the call in the RFC 3725 picture. We send our messages to the SIP CTI gateway and let them deal with the details about how to connect up the call. Various vendors offer these SIP CTI Gateways, Cisco has one built into their Unified Presence Server, Nortel has one on their CS1000, Avaya has one in their Application Enablement Services, and many others also have them. These gateways keep our code out of the call flow path and significantly reduce the expertise needed to create a communications enabled application.

Does this mean we don't have the expertise in unified communications? Of course not. IBM is a leading unified communications provider with IBM Sametime, our WebSphere Application Server is used in companies like AT&T for their telecommunications services, and our services team is a leader in the unified communications space with their Converged communications services. Those services are even ready to help utilize our CEA Feature Pack today. Not only do we have the expertise to work in the unified communications space, we have the partners to make the solution work great. An example of some of our partners in unified communications can be seen here. Names like Cisco, Avaya, Nortel, Siemens, Alcatel Lucent, NEC, Mitel, and Dialogic.

Reducing the complexity of provisioning your communications enabled application will continue to be a top requirement in our communications enabled application solutions.