Advances in web technologies are having a dramatic effect on the capabilities that developers can now deliver to end-users. New features in HTML5 (e.g., data storage, canvas, video and audio) are giving developers a much richer set of tools to build applications with. For example, the HTML5 video and audio elements allow developers to natively include video and audio into their web pages without any propriety plug-ins and their associated clumsy HTML.
WebSockets is another example – a technology that allows for bi-directional, full duplex and persistent connections between clients (in the browser) and servers. WebSockets dramatically improves on earlier techniques for moving data between the client and the server, allowing web applications to be dynamic and responsive.
Another new and disruptive technology, known as WebRTC (Web Real-time communication), in conjunction with the technologies discussed above, allow browsers (or mobile devices with browsers) to directly send video, voice, and data back and forth, from browser to browser, in a peer-to-peer manner. An example use case would be a bank employee and a bank customer being able to see and hear each other directly from their respective browsers.
WebRTC provides a standard (W3C) way to build these video, voice, and data communications applications without the use of plug-ins. Now, developers can provide features that one could only find in technologies like Skype or FaceTime, but can do it in a standard way.
IBM provides support for WebRTC in WebSphere Liberty Profile . The feature, called Rtcomm , allows enterprise developers to build WebRTC style services (in this case user interface services) in the familiar WebSphere environment. IBM has further provided a simplified API on top of WebRTC to make development even easier as well as included a host of ready-to-use components that a developer can leverage to quickly build compelling new services. These capabilities make WebSphere Liberty an ideal platform to build WebRTC services that fit very nicely into a microservices based architecture.
For this blog I decided to build a basic WebRTC service (banking use case) in order to compare the WebRTC feature of WAS Liberty against the do-it-yourself (using the WebRTC API directly) method, as well as one of our competitors in the WebRTC space. Our competitor’s WebRTC solution sits on top of either Tomcat or WildFly.
The criteria I used to evaluate the three approaches were developer productivity, proper documentation and supplementary features. And based on these factors, I found that the Liberty Rtcomm feature provides superior support to either of the other approaches.
I used the number of lines of code as one of the measures of developer productivity. And, as can be seen in the following figure, the do-it-yourself approach requires significantly more code than the other two approaches. Both Liberty Rtcomm and the other competitor provide APIs on top of WebRTC that make is much easier and faster to build WebRTC services. While the WebRTC API is a tremendous new capability, it is still fairly low level and the availability of an easier API is a great benefit to developers.
As you can see from the results of my comparison, implementing basic WebRTC with WAS Liberty requires 4.6x less code than DIY.
To that end, IBM decided to provide some pre-built, ready-to-use, AngularJS WebRTC components as part of its Rtcomm implementation . The components allow developers to get their AngularJS WebRTC services up and running quickly . You can find code samples for the DIY and Liberty Rtcomm solutions here . Note that none of the UI code was counted in the comparison of lines of code.
I tried out several of these components myself – also in a banking scenario. The following figure shows two examples of the AngularJS components I used. The component on the left shows the “presence” component, which allows bank agents to easily view all the open “click-to-chat” sessions, view which agent is having the video/audio session, and see how many sessions they currently are attending to. The component on the right is a view of what a bank customer would see (bank agent) in a live video/audio session.
These components along with all the other features of Rtcomm, clearly demonstrate its advantages over the competitors. The Do-it-yourself and our other competitor do not provide any supplemental features like the AngularJS components that IBM provides. These components clearly provide a rapid way to get a service built quickly.
The following are some other things that I encountered while evaluating our competitor and believe that one should keep these in mind when evaluating that competitor:
- The competitor’s solution sits on top of either Tomcat or WildFly meaning that there will be multiple parties to deal with for support on this technology.
- The competitor’s documentation (written and otherwise) is truly lacking and a lot of it assumes prior telecom knowledge.
- Their web sites have broken links to examples and documentation.
- Some of their instructions are old/wrong, and yet are still on their web site.
- There seems to be no cohesion between their documentation, instructions and artifacts.
Both Liberty Rtcomm and the competitor that I looked at provide comprehensive APIs on top of WebRTC that make building these types of applications much easier than DIY. However, given that Liberty Rtcomm provides many valuable supplementary features (e.g., Angular-Rtcomm) and provides appropriate documentation make it easier to use and provides a more productive developer environment.