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.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
