THE WEB SERVICES ADVISOR
What is service-oriented architecture?
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
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?
Why use SOA?
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
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.