The Web Services Advisor
(To receive this column in your inbox,
click Edit your Profile and subscribe.).
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.
Continues in Part Two
About the Author
Preston Gralla, a well-known technology expert, is the author of more than 20 books, including "How the Internet Works," which has been translated into 14 languages and sold several hundred thousand copies worldwide. He is an expert on Web services and the author of a major research and white paper for the Software and Information Industry Association on the topic. Gralla was the founding managing editor of PC Week, a founding editor and then editor and editorial director of PC/Computing, and an executive editor for ZDNet and CNet. He has written about technology for more than 15 years for many major magazines and newspapers, including PC Magazine, Computerworld, CIO Magazine, eWeek and its forerunner PC Week, PC/Computing, the Los Angeles Times, USA Today, and the Dallas Morning News among others. As a well-known technology guru, he appears frequently on TV and radio shows and networks, including CNN, MSNBC, ABC World News Now, the CBS Early Show, PBS's All Things Considered and others. He has won a number of awards for his writing, including from the Computer Press Association for the Best Feature in a Computer Publication. He can be reached at email@example.com.
- Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
- Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
- For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
- Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
- Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
- Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest industry lingo.
- Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
- Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.