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.