The third component of the Web Integrated Telephony Architecture are Web Services. WITA based applications use Web Services to control real time telecom equipment such as switches, conferencing or messaging equipment. In addition, they also use web service APIs to interface to other critical components that have nothing to do with telephony, and are instead other web services important to customers. The web services would typically be called from a Rails application (although not strictly) to get the work of the application done. Even with closed and secured SOA architectures, WITA based applications prefer using web services to communicate with telecom equipment for scalability, reliability and to ease integration issues.
As an example of an application based on WITA, take a home delivery application that verifies that somebody would be home when the delivery would take place. In this case, the rails application would use web services to create an SMS or voice message to the customer to notify them of the delivery time. A more sophisticated application might correlate the delivery address with the phone number provided by the customer using a data service from StrikeIron, then identify non-matching deliveries for a more high-touch customer experience. This model works especially well when a company requires telephony functionality that is core to the application, but not core to the expertise of the engineering department. The classic example in this situation would be Twitter in the early days (and perhaps today - I’m not privy to the information), where SMS messaging is core to the application, yet the overhead and expense of dedicated SMS gateways and SS7 links does not make business sense. Integrating with an SMS provider using web services greatly reduces the capital requirements for the business but retains nearly all of the required functionality. This particular strategy would work for nearly every enterprise lacking the required staff telecom expertise or the sufficient telecom volume to retain it.
As an interesting benefit of moving telecom functionality into a Web services architecture is the establishment of an interface that is common between telecom and the Web world. Once architects and designers become familiar and comfortable with this model, sending a voice message is as simple as finding what movie is playing at a local theatre, the price of an Amazon product or sales tax in a particular county in Illinois. Applications now blend this functionality together without deep investment or planning, further lowering the bar to interesting applications.