I began my career as a software developer long before there were fancy development tools such as Eclipse or Microsoft’s Visual Studio. If I wanted to get clever, I wrote my code in the UNIX visual editor vi, but more often than not, I used whatever text editor was available at the time. Of course, when you wrote assembler language code like the following, it really didn’t matter what tools you used.
.model small
.stack 128
.code
start: mov ax, @data
mov ds, ax
mov ah, 9
lea dx, Msg
int 21h
mov ah, 4ch
int 21h
.data
Msg byte ‘Hello, there.’, 13, 10, ‘$’
end start
That was then and thankfully, this is now. Although there are still some embedded systems programmers that do bare-metal programming, most software developers work far above the world of registers and program counters. Modern day programmers work with software development kits (SDKs) that shield them from having to understand the actual underpinnings of the hardware they are writing for.
Unfortunately, for the longest time, the folks that wrote software for communications systems weren’t afforded the luxury of such abstractions. They still needed to understand the details of how a call progressed through a telephone system. Even worse, they needed to understand how calls progressed through different telephone systems. For instance, you processed conference calls on an Avaya Communication Manager differently than on a legacy Nortel CS1000. To make matters worse, the choice of applications programming interface (API) made a huge difference in how you wrote your code. TAPI was different from TSAPI which was different from JTAPI.
I am, of course, a big proponent of SIP, but that’s doesn’t make things any easier. Yes, SIP is much easier to read than H.323 or ISDN, but the call models can be sophisticated and out of the reach of anyone but true telephony professionals.
So, what’s a body to do? Stick with the old APIs? Go out and find a bunch or programmers with years of telephony and VoIP experience? Good luck with that.
Collaboration Environment 3.0
Enter Avaya’s Collaboration Environment (CE) 3.0 for Aura. CE 3.0 allows developers to create sophisticated communications-enabled business processes (CEBP) without having to be communications specialists. Additionally, CE 3.0 provides a high availability, distributed, virtual, and integrated platform to run those applications in a secure, load-balanced manner.
CE 3.0 applications are written in Java (my absolute favorite language to write software) using the widely popular tools, Eclipse and Maven.
The CE 3.0 applications programming interface (API) is extremely comprehensive in terms of the kinds of applications that can be developed. You can put together anything from a click-to-call WebRTC button on a web page to an application that dynamically invites participants into a video conference call based on an external business trigger. Most importantly, you can do that without having to understand a lick about WebRTC function calls, codecs, or SIP call flows.
CE 3.0 exposes a number of different programming interfaces including the following:
- Call Control
- Medial Control
- Send Email methods
- Send SMS Text methods
- Create Conference
- Data Access
- Collaboration Bus
- Logging
- System Status
- Alarms
- Events
Applications are packaged into what Avaya terms as snap-ins. If you are familiar with Java, you probably know what a servlet is. A snap-in is like a servlet in that it’s a piece of Java code that is housed in a runtime environment. This environment provides a set of services that assist the servlet in starting, running, stopping, and interfacing with external functionality such as logging and managing secure connections.
Using the CE 3.0 SDK, a Java programmer that isn’t familiar with how telephone systems work, can create applications that make, redirect, fork, and alter calls. He or she can also use the SDK to play prompts, collect digits, and perform other media functions that would normally be far too complicated for non-voice professionals.
Additionally, CE 3.0 extends the same abstractions to other forms of communications such as email, text messaging, and video.
Rare is the programmer that is familiar with the ins and outs of how to develop a piece of software that can manage all these different media types. With CE 3.0, the low level communications knowledge is built into the platform allowing the programmer to stick to writing business logic.
An Interface and a Platform
CE 3.0 is more than a collection of programming interfaces. It’s a scalable platform for application deployment, management, and execution. This is a big reason why CE 3.0 is different from previous platforms that only solved one aspect of CEBP. CE 3.0 gives the developer everything that he or she needs to successfully write, launch, and maintain a new communications service.
Here are some of the aspects of the CE 3.0 platform that truly excite me.
- CE 3.0 servers are completely virtual and can be easily added to an organization’s virtual server farm .
- CE 3.0 servers can be grouped into clusters and applications can be assigned to those clusters.
- HTTP and HTTPS requests can be load balanced across all servers in a cluster.
- CE 3.0 servers can be setup as high availability.
- CE 3.0 is fully integrated with Aura System Manager.
Collaboration Designer
Snap-ins are built using Java, Eclipse, and Maven, but once created, they can be used in Collaboration Designer (CD) to create much larger solutions. CD is a graphical tool that gives non-developers the ability to “write” their own applications by dragging, dropping, and connecting existing snap-ins and built-in CE 3.0 functionality. This new arrangement can be packaged and deployed as an application tailored to meet an enterprise’s specific needs.
The following example shows how someone with no programming experience can use a palette of CE 3.0 functions to create a WebRTC application.
System Manager Integration
I mentioned that CE 3.0 is integrated with Aura System Manager. This integration provides a flexible way to deploy and manage CE 3.0 applications. You can assign applications to clusters, assign users to applications, set the preferred version of an application, assign attributes to an application, and if necessary, decommission the application.
This single point of management is consistent with all other Aura components. CE 3.0 isn’t a second cousin bolt-on. It’s as much a part of Aura as are Communication Manager and Session Manager.
Wrapping Things Up
This article is meant to be an introduction to CE 3.0 so although I could go on for many more pages, I will stop here and save the details for subsequent articles. The important thing that I want you to walk away with is that CE 3.0 enables you to create and deploy secure, scalable, and well managed rich-communications applications. And by you I mean you the programmer, or you the guy or gal who has never written a line of software in your life, but still wants to create new and unique communications applications for your business.
In today’s fast-paced world, ease of development and speed of implementation are key to the success of any new application. CE 3.0 provides both in a one-stop package.
Could you provide examples of how CE expands the capabilities of the Aura communication system?
Absolutely. CE allows you to integrate with business applications outside the realm of an Aura System. For instance, you can expand CM call blocking capabilities by dynamically searching an on-line do-not-call list. You could also integrate with an emergency response system to create ad-hoc conference calls based and external stimulus. The point is that Communication Manager has limits in how it routes and processes call. CE permits you to use lots of different sources to determine how CM should operate.