Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Case study: From standalone Websites and B2B interfaces to SOA

Sprint rationalizes infrastructure with service-oriented architecture

By Galen Gruman, IDG News Service, 09/12/05

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 backend 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 standalone Websites and business-to-business 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, 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 require 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 (enterprise application integration) 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 business-to-business deployments.

The IDG News Service is a Network World affiliate.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.