Ask ten IT professionals what excites them about today's communication technology and you might hear ten different answers. Some folks get all worked up about video and will bore you to tears with their thoughts on H.264 vs. VP8. Others are more interested in voice and get all warm and fuzzy about quality of service and wideband audio codecs (think Opus). The security-focused people pay attention to encryption, topology hiding, and certificates while the bleeding edge types are all about WebRTC and browser-based communications.
Personally, I am thrilled about all of the above and wear my communications propeller beanie with pride. However, there is one recent advancement that doesn't get nearly the attention that it deserves – Web services interfaces. Specifically, I am talking about Web services exposed by management systems. Granted, that doesn't sound as sexy as high definition video or SIP mobility, but these new interfaces open up traditionally closed systems in ways not previously possible.
The term Web services should be self-explanatory. These are services that are available over the Internet (Web) or an enterprise's intranet.
You've used Google Maps before, right? Google offers a Web services interface for map access and data retrieval. Microsoft offers a similar interface for its Bing maps. The social media giant, Twitter, advertises a myriad of Web services to retrieve tweet data and statistics based upon a variety of parameters. Think of any major player on the Web and I bet you will find that they support their own Web services for data retrieval and manipulation.
Web services are built on the same protocols that your browser uses. Http is used for unencrypted access and https is used when you require a secure, encrypted connection from client to server. Using these widely accepted protocols allows Web services to pass through intermediaries such as data firewalls.
Web services are implemented in two distinct fashions – SOAP and REST. SOAP (Simple Object Access Protocol) came first and for many years was the predominant way to create Web services. REST (Representational State Transfer) came along after SOAP, but most developers are moving to REST because of its simplicity, statelessness, and ability to scale to support large, distributed computing environments.
A comparison of SOAP and REST is beyond the scope of what I want to accomplish in this article. There are plenty of those discussions on the Internet, and I invite you to explore them. For this article, I will focus on REST, since it appears to be winning the API (Application Programming Interface) war.
RESTful Web services follow four basic design principles:
In terms of http, REST predominantly uses four methods – POST, GET, PUT, and DELETE. You will sometimes hear this referred to as CRUD -- Create, Read, Update, and Delete.
The mapping of http methods to REST functionality is as follows:
A very simplistic REST call to add a user to a contact list might look as follows:
Now that I've gotten the basics out of the way, allow me to return to my original topic – Web services management interfaces. In particular, I want to introduce you to the Web services exposed by the Avaya Aura System Manager .
As most Avaya customers know, System Manager is Avaya's unified management tool. It provides a web-based interface to configure and perform administration functions on nearly every Avaya Aura component. This gives you access to everything from Communication Manager to Session Manager to Avaya Aura Conferencing . In fact, Avaya is starting to discontinue the product specific management tools (e.g. Avaya Site Administrator) and moving everything to System Manager.
For the first few years of its existence, System Manager functionality was delivered solely through a Web interface. An administrator would sit down at a Web browser and click keys on a keyboard. However, what if you didn't want to do that? What if you wanted to automate the process or execute those administrative tasks from some other application or interface?
That's where the System Manager Web Services come in. Through a series of RESTful interfaces, Avaya exposes the following services:
With these interfaces, it's now possible to perform standard "moves, adds and changes" operations from any Web services-capable language such as Java, C#, Perl, or Python. This not only enhances an enterprise's management capabilities, but it simplifies them as well. While System Manager is not a difficult interface to learn, certain functions can now be presented in ways that even the most telecom ignorant people can easily learn and use.
Of course, you don't want just anyone manipulating your configuration data. That's why the System Manager Web Services authenticate exactly the same as if the operations were performed from the Web interface. Additionally, with System Manager's role-based administration, control over who can do what to whom is built into these new interfaces.
An API without an application is like a motor without a car: It makes a lot of noise, but in the end, it won't take you where you need to be. You must harness that power to make it work for you. Allow me to take a look at an application that does just that.
As I travel around the country speaking with communications professionals, I nearly always ask these two questions:
"How many of you set the password of your IP telephones to be the same as their extensions?" and "How many allow '1234' as the password?"
Sadly, I get raised hands and guilty smiles far more often than I would like. It's hard to blame them, though. Changing the password on an Avaya telephone is not a trivial task. In fact, it's not possible for a user to do it. He or she must ask an administrator to do it on his or her behalf. Also, that request will usually come in the form of an email containing the new password. Clearly, this is far from ideal and filled with more security violations than I care to count.
To solve this problem, my company Arrow Systems Integration created an application using the System Manager Web Services interfaces that gives users control over their telephone's password management. PasswordPro is a SaaS application that adds a much needed layer of security on top of an Avaya system.
Its features include:
In other words, PasswordPro allows a best-practices approach to Avaya passwords that hasn't been previously possible. In today's world where security concerns have risen to the top of mind of most IP directors and CIOs, it's hard to imagine any enterprise that is willing to keep the status quo of easily guessed passwords and highly vulnerable communications systems. Remember, all it takes is one weak link to break an otherwise strong chain.
The days of closed communications architectures are over and I couldn't be happier. Web services are paving the way to highly flexible systems that allow system integrators and software developers the ability to customize solutions while adding significant value to an enterprise's costly investment. Avaya's new System Manager APIs are only the beginning, but they are a good start. Over time, I expect their scope to expand, and the number of applications that use them will only grow.
Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.
Follow Andrew Prokop on Twitter and LinkedIn!
@ajprokop
Andrew Prokop on LinkedIn
