As far back as four years ago, Sprint’s IT staff was already headed toward SOA (service-oriented architecture). They just didn’t know it yet.
When developers first began exposing Sprint’s back-end systems as reusable components, the concept of Web services was still largely unproven. Previously, they had connected the company’s departments, customers, and partners to its mainframe systems through a series of stand-alone Web sites and b-to-b interfaces. For one of the U.S.’s largest telecom providers, with a customer base of more than 10,000 companies, such a one-off approach wouldn’t be sustainable for long, however.
Four years ago, the local phone-service business unit began developing Java applications for such basic functions as log-in and password reset, as well as customer tasks such as service ordering and account updates. Seeing the wisdom in this modular approach, other business units quickly followed suit. Unfortunately, multiple, parallel Web-services development efforts resulted. Sprint developers were creating the same modules over and over again, often without knowing it, wasting development time and dollars.
“We had lots of different platforms and technologies as each design progressed for its line of business and customer requirements,” recalls Edmund Vazquez, Web services program manager for the enterprise-focused Sprint Business Services (SBS) unit. “Often, core functionality was projectized. There was no incentive for reuse of core infrastructure assets or components.”
To rationalize its Web services deployments, SBS decided to create a common architecture to provide a framework for identifying, developing, and managing its services. A solid SOA underpinning would let SBS break services down to reusable components that would reduce overall development efforts, although it would also requires a clear understanding of business needs and the services required to meet them.
To manage the SOA and the services developed on it, SBS created two distinct IT groups. One focuses on the overall architecture and strategy, while the other concerns itself with service development and integration. This ensures that the architecture is maintained and applied consistently while still allowing development teams to focus on their specific business-logic areas.
Of course, the transition didn’t happen overnight. According to Vazquez, it didn’t have to. “One of the nice things about SOA adoption is that adoption, implementation, and deployments can be incremental as long as you keep your eye on the bigger picture,” he says.
Building for manageability
Architecturally, SBS defines three kinds of services: atomic, aggregate, and composite. Atomic services might expose a single API and are usually transactional in nature. Aggregate services may involve calling sequences of atomic services, much like one Java class calling other classes. Composite services, on the other hand, require orchestration or choreography.
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.
Because vendors interpret standards differently and because over time vendors will likely diverge on which standards they support, Vazquez expects that it will become more difficult to maintain interoperability between trading partners, resulting in a more conservative approach to the adoption of standards. When necessary, he says, SBS will create multiple versions of services, each of which supports distinct standards, rather than trying to develop a single service that can support multiple standards or variations. Otherwise, he says, the benefits of a component-based Web services platform will be negated by the complexity of ensuring interoperability across so many technology variations. Similarly, to keep its development efforts manageable, SBS tries to develop its Web services in Java and its wrappers to legacy systems in EJB, to maintain J2W (Java to Windows) compliance.
The company typically uses BEA WebLogic as its application server for the EJB wrappers, due to its strong interoperability, but it also uses IBM WebSphere application servers in some areas, depending on the specific application or transaction mix.“The idea is to insulate the Web services layer from the underlying technology platform, whether it’s WebLogic, WebSphere, or a mainframe,” Vazquez says.
The use of Web services has also helped to remove a labor-intensive, frustrating aspect of providing external customers access to SBS systems. Before the WSM was in place, SBS would have to reconfigure the firewall protecting each affected server to allow access to each individual customer. With a WSM, Vazquez says, direct access by the external customer is eliminated, as is the need to configure firewalls for each service. Instead, SBS limits the customer to a broker service hosted in the DMZ, which then calls up services inside the SBS network as needed.
A platform for the long term
When Sprint realized it needed a common architecture for its emerging Web services, it already had a key SOA requirement in place: tight integration between business logic and application development. Sprint historically has been a process-oriented company, Vazquez says, adding that its business development teams have traditionally specified their own application requirements, often working with a development staffer sitting nearby.
“We have four process design tools,” Vazquez says, explaining that Sprint already had the process orientation required to effectively deploy an SOA. He credits that readiness for Sprint’s fairly fast ramp-up when the SOA effort began in earnest two years ago.
Today, the SOA lets Sprint use services in two ways: directly, or through an external Web-based interface for customers that don’t yet have the ability to integrate with Web services on their own. According to Jeff Lentz, who manages services architects at SBS, customers gain the most when they can consume Web services directly, because that approach allows them to encapsulate Sprint’s services in their own applications. That eases data integration, and it also frees their staffs from the need to learn new interfaces or processes, as they must if they access services through a Web site. Because most customers are only now starting to develop their own Web-services platforms, however, the Web interface means that Sprint gets immediate ROI.
What’s more, Sprint’s foresight in implementing SOA will help it in its next big challenge: the union of Sprint with its recently acquired subsidiary, Nextel. “The icing on the cake is that internal consumption of the services can accelerate the legacy migration we face with the merger,” notes Gayle Sweeney, director of Web presence at the carrier.
The flexibility of the SOA approach means SBS no longer needs to reinvent the wheel every time it’s challenged with integrating a new project or initiative. And in the often-chaotic world of enterprise IT, if Vazquez can be certain of one thing, it’s that he’ll have no shortage of those. “In an enterprise of 70,000 people, we’ll always find new applications or efforts under way,” he says.