Enterprise Software

Are Web services for real?

As Tim Landgrave explains, defining Web services is tough--even when you have a roomful of experts and early adopters involved. Get Tim's explanation on why Web services could ultimately end up like the ASP model.


I spent a few days in early December attending and making presentations at the CNET Networks conference “Building a Web Services Foundation.” The purpose of the conference was to help IT executives, network systems managers, and development managers plan for organizational adoption of Web services.

It became obvious very early on that most companies are still confused not only about what Web services are, but whether and when they’ll have an opportunity to deploy them.

What is a Web service?
During the opening session, the moderator invited representatives from each of the major Web services standards bodies (WS-I, OASIS, W3C, and the Liberty Alliance) to define a Web service from their perspective. After hearing the definitions and discussing them among the representatives, it became clear that the definition itself would be difficult to nail down.

Even though nailing down a definition was like nailing Jell-O to a wall, most presenters agreed on some things. The main theme was that organizations needed to prepare for a move from a systems architecture based on independent applications, tied together by custom messages or processes, to a new type of systems architecture based on independent services tied together by a standard messaging format. The common name for this new architecture is the Services Oriented Architecture (SOA).

An SOA is composed of existing software components wrapped with interfaces that use SOAP and XML standards to invoke them. The SOA will also allow developers to create new components that will automatically be exposed as services without being tied to any specific user interface.

These two base service types (legacy applications wrapped with service interfaces and new components specifically exposed as services) will be published in standard directories from which they can be discovered by other services and automatically invoked. Not only will smaller services be combined to create fully integrated services, but the services can be assembled into a business process and driven by the most appropriate user interface for a given circumstance.

Once composed, the final Service Oriented Application (an application based on an SOA) will have the benefits of a series of shared services, including XML integration and legacy systems connectivity, business process management, content management, personalization, identity management, and security. But for companies to start building these core services, they need to see incremental return on their existing investments.

Where's the ROI?
Return on investment (ROI) was the other “TLA” (three-letter acronym) that dominated conversations at the conference. It became pretty clear from both the session contents and the hallway conversations that executives were demanding to see incremental returns on their forays into existing Web services projects before committing to further investment. And keep in mind that the sentiments were from early adopters! So what did these participants see as the immediate and long-term paybacks?

Companies see both technical and business benefits. Many technical early adopters reported that they’ve been able to accelerate the development process and lower the overall development cost by implementing reusable core services using Web services technology.

Other technical early adopters have found huge paybacks in using Web services to replace internal Enterprise Application Integration (EAI) initiatives that were moving at a glacial pace. They found it easier and more cost-effective to wrap existing systems with Web services and then use standard tools to connect the processes rather than using an expensive and cumbersome messaging engine product and then defining both a messaging bus and messaging interfaces into their existing systems. Using Web services made EAI initiatives more intuitive and understandable to their development teams.

Companies looking for core business benefits point to the reduced cycle time between revisions of systems as the reuse of Web services within an SOA increases. This allows them not only to get information to their employees more quickly, but also to improve information delivery to customers, partners, and suppliers. The same services used internally to manage business processes can be exposed to their external constituents. For example, Motorola saved more than $100,000 by wrapping a credit card validation function in use by one business unit as a Web service for use by another business unit. Other companies reported similar near-term gains. And all expect additional long-term gains as they learn to leverage their SOAs to create new applications.

Will it be enough?
All of the successful Web services implementations still represent a fraction of the new deployments that have taken place in the last year. And the Web services “identity crisis,” combined with the excruciatingly slow pace of Web services security adoption and the economic recession, may keep even more companies from making an investment in developing an SOA based on Web services technology.

Web services are starting to look like another buzzword that was going to take over the world just a couple of years ago—the ASP. Concerns over security and the lack of a reliable, high-speed telecom infrastructure scuttled the ASP movement. In the end, ASP not only didn’t become a new industry, but it turned out to be nothing more than a software distribution method for vendors. And that begs the question: Will Web services become nothing more than a services delivery model for software manufacturers?

Editor's Picks

Free Newsletters, In your Inbox