Some days I feel that all I do for a living is talk. Conference calls with coworkers, vendors, and customers fill my calendar. If there was a Fitbit for my mouth, it would far outpace anything I do with my arms and legs.
It wasn't always like this, though. I began my career as a software developer and spent the first 26 years of my working life writing code for enterprise and carrier solutions. Starting with assembler language for Intel 8085 processors and ending with Java code for carrier-grade SIP solutions, I've written for dozens of platforms using five different programming languages. While nearly every one of the products I helped create would seem quaint by today's standards, each was once considered cutting edge -- and I am still proud of my contributions.
I recently reconnected with my programming roots at an Avaya Breeze for Java Programmers boot camp. For three long days, I immersed myself in the world of editors, compliers, debugging tools, and trace utilities to write applications that do everything from make telephone calls to send RESTful Web services calls. I will admit to being a bit rusty on the first day of class, but before long I was feeling comfortable back in the Java saddle again.
If you aren't familiar with Breeze, you may know it from its previous names, Engagement Development Platform (EDP) and Collaboration Environment (CE). The platform has evolved over the years, but it's still essentially a portal into Avaya Aura that allows developers to write applications that can climb into the middle of a call flow to perform all kinds of amazing tricks.
Breeze connects to an Aura system with SIP messages to and from the Avaya Session Manager. However, that doesn't mean that Breeze developers need to understand SIP. On the contrary, unless the developer brings up the low-level debugging tool, traceCE, he or she would have no notion that SIP is even part of a Breeze application. The Breeze API completely hides SIP requests, responses, and call state information to allow the programmer to focus on an application's business logic while ignoring the sometimes complicated underpinnings of call control messages.
Drop and Write Me 50 Lines of Code
For me, the best way to learn a new technology is to immerse myself in the nuts and bolts -- and that's exactly what I was able to do at the boot camp. With access to a fully loaded Breeze server, I could exercise just about anything Breeze was capable of doing.
I began by intercepting and changing the caller ID of an inbound call, and by the end of the week I had an application capable of using speech recognition to take specific actions upon detecting certain spoken phrases. Between those two extremes, I spent my time converting calls into text messages, forking calls to multiple destinations, playing prompts, collecting digits, and manipulating database records. In other words, I worked on everything that an actual application might do to process real-time communications as it interfaces with backend data services.
Breeze applications, called Snap-ins, are created outside the Breeze platform. I built my applications on a Windows machine, but others in the boot camp preferred Apple Macintoshes. In all cases, developers load Snap-ins onto a Breeze server and assign ranges of telephone numbers to them. This enables the phone system to invoke Snap-ins during call origination or call termination.
Additionally, since Breeze is built around IBM WebSphere, it acts as a typical application server. This means a Snap-in can do things outside the realm of strict real-time communications. For instance, Snap-ins can bring up Web pages, invoke external data services, and implement RESTful Web services -- i.e., anything a WebSphere Java servlet can do.
With a Little Help From Their Friends
As with any API, the Breeze objects and their exposed functions are merely templates, and the real work occurs at a level below the API calls. In some cases, the underlying operations are implemented by Avaya-supplied technology, but that's not necessarily a requirement.
For example, a Snap-in is made aware of an incoming call through the SIP infrastructure supplied by Aura and the Breeze platform. When the Session Manager receives a SIP INVITE, it forwards it to Breeze for conversion to the more abstract callintercepted() API callback.
In other cases, Avaya components external to Breeze come into play. A good example of this would be the media APIs. With these, the Breeze platform invokes the Avaya Media Server to do such things as play prompts and collect digits.
The creators of Breeze realized that even though Avaya could provide a great deal of the underlying functionality, attempting to deliver everything wasn't practical. For this, they came up with the concept of a connector. Simply put, a connector is an externally developed piece of software that implements pieces of the API.
In the boot camp, I wrote a Snap-in that created and sent SMS text messages using a connector developed by the folks at Webtext. While my Snap-in used Avaya-defined SMS API functions, underneath the covers the Webtext connector (which is itself a Snap-in) intercepted and implemented functions such as sendSMS().
The Webtext connector uses RESTful Web services to communicate to a cloud-based SMS gateway, but like the rest of Breeze, the gory details are hidden from the Snap-ins. So, while it's technically possible to add this functionality directly into a Breeze application, the use of connectors removes the complexity and greatly decreases development time.
A similar example would be the ability for Snap-ins to send emails. Avaya defines the email interfaces that Snap-ins use, but leaves the actual work of sending and receiving emails to third-party developers.
Snap-ins communicate with these external services over a Collaboration Bus. While Breeze hides the existence of this bus from Snap-ins, Avaya provides tools to monitor the traffic that flows across it. This low-level tracing may be useful during debugging.
A Cool Breeze
As the boot camp progressed, so did the power and scope of my application. By the time I was finished, my "simple" Snap-in could send SMS texts, emails, do data dips, update database records, play prompts, collect digits, fork calls in either a sequential or parallel manner, route on a user's presence, route calls based on spoken phrases ("Call my assistant"), change caller ID, send and receive RESTful Web services calls, and act as an application server for Zang (an article for a later day). Whew!
Despite this kitchen sink approach to application development, I learned quite a bit in those three days. First, Breeze can do just about anything I would want it to do as part of a call flow. Second, despite the fact that I haven't programmed professionally for quite a few years, developing sophisticated Breeze applications was not beyond my ability. Lastly, Avaya has thought through the Snap-in development process and has gathered together an impressive number of tools useful during application development, deployment, and maintenance. No matter what I wanted to do, there appeared to be a way to do it along with techniques to verify that I was doing it correctly.
That said, writing Breeze applications in Java is not for everyone. This is real programming, and only skilled programmers should attempt it. Avaya has made the API fairly easy to understand, but you need a decent background in software development to use it.
For non-software engineers, Avaya has a drag-and-drop development tool that doesn't require a lick of programming knowledge (another article for another day). Stay tuned for an even deeper dive into Breeze and Snap-in development.
For related No Jitter posts, see:
Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.