A composite Web service implements a process or workflow involving multiple atomic or aggregate Web services, including managing data flow among them. In a few cases, SBS uses the Vitria EAI platform to implement a composite service’s process at the Web service level, Vazquez says. SBS also uses BPEL (Business Process Execution Language) to orchestrate services in b-to-b deployments.
In retrospect, Vazquez says going the atomic route is the best option, even though initial development takes longer because of the time it takes to break down the functions into their basic components. Doing so lets developers create the most reusable components, enabling them to then build up aggregate and composite components easily when it’s clear that entire sequences of services are reusable.
By comparison, Vazquez recalls some early Web services that were so specific to their customers that no one else could use them. “They’re technically Web services ... but they’re really just applications,” he says.
For messaging among services, SBS relies on a WSM (Web services manager) based on the X-broker platform from Infravio, which handles the atomic and aggregate services and also provides a Web services registry.
SBS encapsulates its mainframe applications as “virtual services” within EJB wrappers that expose the functionality of the applications using SOAP, WSDL, and XML schema. This presentation meets two needs: It keeps the EJBs’ internal business logic private while also offering trading partners a standards-based approach to consuming the service, Vazquez says.
The system supports several data exchange standards, since SBS service providers and customers use a wide range of technologies. Flat-file text and basic XML are the most common choices.
“We are leveraging specific XML standards for specific types of domains or transactions, such as TML, eTom, ngOSS, and others developed by telecom industry consortia,” Vazquez says. “The challenge here, as in all standards, is the rate of adoption among trading partners.”
In the telecom industry, Vazquez explains, adoption of such specific extensions to XML is widespread because customer data and voice communications typically traverse multiple carrier networks and service providers. “But we haven’t done much in terms of defining standard enterprise XML schema,” he adds, explaining that the multitude of functional and customer differences make development of such XML schema standards too unwieldy.
Standards and practices
Although SBS has “a world-class IT services R&D group that actively researches and monitors emerging standards,” Vazquez notes, “in some cases we simply choose to hold our integration vendor accountable for keeping us interoperable.” The reason is complexity: As more and more WS-* standards are proposed or approved, organizations are faced with increasing development burdens, as well as greater risk of incompatibility with external users.
For example, SBS uses WSDL 1.1 because that’s what the Infravio platform supports, and Infravio supports it rather than WSDL 2.0 because “that’s what the WS-I organization has done the most compatibility testing with,” Vazquez says. “The only standards that we are really focusing on today are SOAP, WSDL, WS-Interoperability, and WS-Security,” he adds, explaining that those are widely applicable and adopted technologies.