The Buzz Word

THE WEB SERVICES ADVISOR

What is service-oriented architecture?

Preston Gralla
05.06.2003
Rating: -4.29- (out of 5)

The Web Services Advisor The big buzzword these days among the Web services cognoscenti is Service Oriented Architecture, most commonly known by its acronym SOA. SOA is kind of an IT manager’s holy grail, in which software components can be exposed as services on the network, and so can be re-used time and time again for different applications and purposes. In SOA, developing new applications can be a matter of mix-and-match: decide on the application that you need, find out the existing components that can help build that application, glue them all together and you’re done. That’s the theory, anyway. In practice, things are never that neat. In this first part of a two-part column, we’ll look at what SOAs are, examine their benefits, and detail key issues surrounding with the technology. In the next column, we’ll look at SOA products and get advice from the pros on how to go about building an SOA. What SOA is SOA is an increasingly popular concept, but in fact, it isn’t a new idea at all. It’s been around since the mid-1980s. But it never really took off, because there has been no standard middleware or application programming interfaces that would allow it to take root. There were attempts to build them, such as the Distributed Computing Environment (DCE) and Common Object Request Broker Architecture (CORBA), but neither really caught on, and SOA languished as an interesting concept, but with no significant real-world applications. Then Web services came along and gave it a boost. The Web services underlying architecture dovetails perfectly with the concept of SOA —so much so, in fact, that some analysts and software makers believe that the future of Web services rests with SOA. One reason for that is how in tune the two architectures are. “SOA is an architecture that publishes services in the form of an XML interface,” explains Gregg Bjork, senior vice president of products and services for Web services vendor Systinet. In that, it’s really no different from a traditional Web service architecture, in which UDDI is used to create a searchable directories of Web services. In fact, he says, UDDI is the solution of choice for enterprises that want to make available software components as services internally on their networks in SOA. So how does SOA differ from Web services? “Most Web services implementations are point-to-point, where you have an intimate knowledge of the platform to which you’re connecting. The implementation is fairly solid and the interface doesn’t really change,” he says. That means that the Web service is not made available publicly on the network, and cannot be “discovered” — in a sense, it’s hard-coded in the point-to-point connection. In an SOA implementation, information about the Web service and how to connect to it is published in a UDDI-built directory, and so that Web service can be easily discovered and used in other applications and implementations. Why use SOA? A number of factors are driving the move toward SOA. Cost savings is one. If you can reuse services you’ve already built, then you don’t have to spend as much time and money developing new applications. Another factor is the increasing success of Web services. As companies build more Web services, unless they have an overarching architecture, serious problems can develop, says Patrick Vallaeys, vice president of marketing for Web services vendor Infravio. For example, what happens when one of those Web services has been incorporated into other applications, but then the Web service is changed without telling developers of those applications? An overall architecture needs to be built to make sure that doesn’t happen. Perhaps most importantly, says Vallaeys, is that an SOA “increases a business’s flexibility and lets it more quickly adapt to changing business needs.” Jason Bloomberg, Senior Analyst with the ZapThink research and analysis firm, adds that to date, most Web services are being used primarily “to solve point-to-point integration problems.” But these solutions “can’t solve the larger integration problems in converting hundreds of systems” to an overall, single enterprise architecture. For that, SOA is needed. But while the basic Web services architecture fits neatly into the SOA concept, there are still roadblocks to setting them up. Notable among them, Bloomberg says, are security, identity management issues, and management problems — having software that will be able to track and manage hundreds or dozens of Web services and their development and deployment. Software is just becoming available to do that. On the security side, the issues still haven’t been solved. What the Future Holds Despite these challenges, SOA will most likely become increasingly popular, especially because Web services themselves are finally starting to catch on in enterprises. The CBDI Forum recently did a survey and found that 70 percent of respondents planned to adopt an SOA. More than seventy percent of respondents said they would do so to ease integration, while more than 60 percent said they would adopt one because it would increase their business flexibility. But while those future numbers may be encouraging, SOA uptake is expected to be slow. “The number of companies that use it is small, but it is growing,” says Systinet’s Bjork. “We’re seeing an uptick, especially in companies using UDDI, so it’s clear that people are thinking more about using SOA.” Bloomberg agrees, saying SOAs “are just beginning to gain traction.” What if you’re considering an SOA architecture? How should you go about building one — and which products will help? We’ll cover that in the next column, so stay tuned.