SOA/Web Services

SANTA CLARA, Calif. -- Application server (A/S) vendors are hoping that Web Services-based Service Oriented Architecture (SOA) will develop in the telecom space in unison with the enterprise realm so that real-time communication services like telephony will become just another application for the operator using the same logical services bus, a leading industry official said.

 

“As the SIP application server builds, it is at a very interesting inflection point,” explained Doug Tucker, Chief Technology Officer at Ubiquity Americas.

 

During his session to kick off the Ubiquity Next-Gen SIP track at the VoIP Developer (News - Alert) Conference here, Tucker explained how SOA is revolutionizing the telecom industry, which is slowing transforming its network infrastructure into an access-agnostic platform capable of bridging the IP space that enterprises have long enjoyed.

 

The main difference between the telco and enterprise communities is that applications have always been built from the ground up in the telecom realm while enterprises use more of a top-down method to development, he said. Historically, SOA has developed as an extension of the Web Services specifications (SOAP, WSDL, UDDI, etc.) that were first standardized by organizations like W3C or OASIS.

 

And as the applications framework evolves, telecom’s evolution toward SOA will take place in a series of coordinated steps: 1) deliver reliable voice service to subscribers; 2) increase revenue by reducing infrastructure costs for delivering reliable voice service; 3) increase revenue by offering enhanced services to subscribers (***this is where Tucker believes the industry currently stands now***); 4) match services revenue model to existing voice revenue model...that is, substitute services access minutes for voice minutes.

 

To reach the level where applications can be deployed across multiple networks, applications whether data or voice need to conform to the same logical services bus … a service delivery platform like Microsoft’s (News - Alert) Connected Services Framework, for example. Using consistent languages tools like BPEL (Business Process Execution Language) or WS-CDL to create a combination of interfaces that dictate the way services, features and resources are orchestrated, network operators and developers can build and deploy more open, extensible applications while cost-effectively reusing network elements.

 

“The application developer now becomes completely decoupled from the network they are deploying it on,” Tucker said.

 

But for the telecom community to address the service, feature and resource orchestration across the board, there needs to be some level of commonality and here in lie the dilemma, he said. To help bridge the SIP A/S and help with the aforementioned orchestration, companies like Ubiquity and BEA Systems (News - Alert) have been working to define SIP Servlet containers. The problem is, because the specification bridge touches so many different elements of communications infrastructure, Tucker’s team is unsure if the new spec should be submitted to W3C to further define Web services or IETF to define SIP.

 

Back in February, BEA Systems announced that it has taken over as Spec Lead for Java Specification Request (JSR) 289, entitled Session Initiation Protocol (News - Alert) (SIP) Servlet v1.1, as well as SIP 32, entitled Java API for Integrated Networks (JAIN) SIP API Specification. JSR 289 is an enhancement to JSR 116, first developed by SIP solutions vendor Dynamicsoft to define a high-level extension API for SIP servers.

 

But after pushing through the final release of JSR 116, Dynamicsoft was acquired by Cisco Systems for its expertise in SIP-based networking. Once the acquisition was completed, Dynamicsoft became part of Cisco’s Service Exchange framework and abandoned development of its own applications infrastructure platform. Much of the work has been picked up by Ubiquity. Based on Java Specification Request (JSR) 116, Tucker and his counterparts at BEA are writing JSR 289 to define how the Servlet should interact with the SIP A/S.

 

“A lot of the newer elements weren't baked into the standard,” the Ubiquity official said. “Some of the limitations was it was a fairly narrow API. Now we know where the boundries are. It's really in the last month or so that we've learned the limitations of 289.”

 

Tucker said work on JSR 289 should be ready by the first quarter of 2007. Where it goes from there, though, is anyone’s guess.

 

----

 

Robert Liu is Executive Editor at TMCnet. Previously, he was Executive Editor at Jupitermedia and has also written for CNN, A&E, Dow Jones and Bloomberg. For more articles, please visit Robert Liu's columnist page.

 

SOA/WEB SERVICES