Service-Oriented Architecture Steps into the Future
By Jeff Merron
When USinternetworking, an application service provider (ASP) to more than 150 companies, was still very small, software architects and programmers were able to keep track of the available application codes and figure out how to make them work together. But as the Annapolis, Md. based company grew, the task rapidly became unmanageable.
USi "had a lot of legacy code and a lot of different systems that we connected together in a variety of ways," explains Michael Rulf, vice president of advanced engineering at USi (acquired by AT&T in October 2006). "We were using SSH and various types of network calls. The lines between applications had started to blur."
Different parts of the organization had begun using different vendors for similar operations, such as those involving Customer Relationship Management (CRM), but these applications still needed to be able to work together. "I had to figure out how to get the data from one system to the other, and each one of them made very different transformations to the data. It rapidly became very messy. I found that SOA helps you a lot with that integration process," says Rulf.
Service-Oriented Architecture, aka SOA, is a system that enables companies to isolate and define sections of program code -- the services, which are usually part of large applications -- and then implement a standard form of communication, allowing data to pass between the different services. A service can exist anywhere -- inside or outside an enterprise or made accessible via the Web -- and can be used for a variety of purposes by those who have permission to access it. (article continues)
Next Page >>
