InformationWeek
Defining The Business Value Of Technology
|
February 19, 2001 |
 |
Evolution Of The Species
Major technology vendors want to replace your applications with Web services, promising rapid deployment, simplified integration, and reuse benefits. Is this just a rehash of the failed component movement? What will Web services mean for IT?
By Alan Radding (aradding@cmp.com)
 |
| More on Web services: |
|
|
magine a world without applications, one without software permanently loaded on computers. Instead, application functionality would be provided in the form of services delivered over the Internet. In this new world, IT would find itself in the service-management business. Everyone and everything would use services. Computers would access the services they needed to complete any given business task. To send a legal document, a computer would invoke an encryption and digital-signature service. To transfer funds between a U.S. company and a Japanese company, a computer would invoke a currency-conversion service. These services would flow across the network like electricity flows over the power grid.
Advocates of this great migration say that services will change the way you work and radically alter the function of IT departments. These cheerleaders promise greatly reduced cycle times and more rapid deployment of new business functionality. They say a services model will bring about simplified system administration and platform integration, and they argue that we'll finally achieve the promise of reuse of business logic and processes. Others take a more critical view of the services evolution. "Let's face it, the application model is broken," says Srinivasen Keshav, chief technology officer and co-founder of Ensim Corp., a Sunnyvale, Calif., company that makes infrastructure hardware and software for application service providers. "IT people don't want to deal with the complexity of applications. The corporate systems environment is too complex and won't scale much longer. Services will address the complexity and scalability issue," he adds.
Keshav notes it's a difficult problem, but says there will be lots of opportunities for the vendors and service providers who figure out the right business model and delivery mechanism.
More important, as online marketplace, intercompany collaboration, and E-commerce grow, IT may be able to use services to deploy more flexible systems that are easier to use and integrate. Already companies such as Bekins Co. in Hillside, Ill., are exploring the use of services to extend their applications to prospective customers.
Software services are discrete pieces of code that reside on the network and perform a specific function. They represent the latest stage in the evolution of software components that began with low-level, object-oriented programming. Objects evolved into larger-grained pieces of software that adhered to standards such as Enterprise JavaBeans, the Component Object Model, or Common Object Request Broker Architecture (Corba). The definitions evolved yet again into distributed server-side components that would execute among different computer systems.
Services provide higher levels of abstraction than standard components. As such, they're easier to use and to deploy. The key to services is that they have standard, published interfaces.
The industry's biggest system vendors--Hewlett-Packard, IBM, Microsoft, Oracle, and Sun Microsystems--have already started to beat the drums for their particular interpretation of Web services.
At Microsoft, services are central to its .Net initiative. Through .Net, computers, devices, and services are intended to collaborate directly with each other. The company expects .Net will let businesses offer their products and services in a way that allows customers to embed them in their own electronic fabric.
IBM calls its services initiative Web Services. "Services are software, but with a lot of reuse. You also have to think of them in terms of the network," says Bob Sutor, IBM's director of E-business standards strategy.
Services are central to IBM's E-business strategy. "When an online merchant wants to validate a credit card, it just wants to send information to the bank and get back a yes or no answer," he explains. Credit-card validation becomes a service provided over the Internet.
Oracle sees services as loosely coupled software components running over the Internet using HTTP and XML as the key protocols, says Bill Dwight, Oracle's VP of Java tools. The new services, whatever their underlying technology may be, will be tightly wrapped in XML to function as a service, he says.
At this point, the vendors primarily want to sell their component tools and component frameworks, which are central to building services. Down the road, the vendors will likely want to sell their software products as services if a market and an acceptable revenue model evolve.
For IT managers, the shift to software services, if it actually comes about, radically changes the way their companies must think about development, deployment, management, and software acquisition. Ultimately, software services may change the business itself; they may, in fact, become the business.
Right now, however, the concept remains "a technology concept that at some point will need to find a market. Thus far, there's no poster child for a Web service," says Evan Quinn, chief research officer at the Hurwitz Group, a consulting firm. Until there are a few business adopters to act as guides, any IT group venturing into this new software services landscape will be navigating strictly on its own.
However, the lack of models hasn't discouraged some companies from looking with curiosity at this early phenomenon. Bekins, a transportation company, is closely following IBM's Web Services initiative. "We see it as a natural progression, especially if you're already using Java and [Enterprise JavaBeans], as we are," says Randy Mowen, Bekins' director of data management and E-business architecture. He sees services as a way to extend his applications to a larger audience to attract new business.
Bekins already has a core of programs built using Enterprise JavaBeans components that would form the foundation for any software services it deploys. "In theory, our programs should be quite sharable--if we're willing to share them. We should be able to do it without too much effort if we stick to standards like Soap," Mowen says.
Soap, the Simple Object Access Protocol, is based on XML and enables the exchange of information in a decentralized, distributed environment. Soap, which is supported by IBM, Microsoft, and others, adds a process dimension to XML data exchange by including instructions on what to do with the data.
Software services, for example, may let Bekins smooth out the impact of the cyclical nature of the moving business. In the peak moving season, the company scrambles to pass off excess business. In off-peak periods, it seeks to fill idle capacity.
Bekins could attract more off-season loads if it had a service that would let a shipper determine the shipping costs for a particular item, Mowen says. The company is just beginning to explore what it would take to convert some of the self-service components it uses on its Web site into a service that a third-party shipper could access programmatically through its own internal applications.
This raises technical and operational issues. For example, the shipper would have to do some programming to use the Bekins software service. This would entail reverse engineering the existing Java code and mapping the shipper's application to the Bekins software service. Bekins would also need to advertise its service, and it's unclear how much support Bekins' IT personnel would have to provide to third parties.
Independent software developers have been quicker to test the services concept than business IT departments. Duzine LLC in New Paltz, N.Y., for instance, is deploying multicurrency exchange functionality as a network service. Problems such as multicurrency exchange represent excellent candidates for software services because while the logic for currency conversion is pretty straightforward, the data required for the conversion frequently changes. Getting the latest exchange rates to use as the basis for the conversion can be a challenge. Duzine combines the currency conversion logic with real-time prices.
To use the service, a customer downloads a Java Archive file that provides a simple interface, CTO Mark Desmery says. The customer enters the amount and the currency he wants his funds converted into. A click later, the customer gets the result. The service can be used by an application or by a Web site that wants to quote prices in a customer's local currency.
Duzine's business model is straightforward. It charges $99 for the Java Archive file and $49.95 annually for the currency rate data. Duzine refreshes the currency data once a day.
The multicurrency service provides a model for an entire category of functionality that would make ideal services, suggests Charles Stack, CEO of Flashline.com Inc. in Cleveland, an online market for software components. "These are things that can be outsourced at the component level rather than the application level," he says. "They have a data component that needs frequent updating."
Sales tax rates would be another such service. Again, an online business that had to apply the appropriate state sales tax would run the service as part of processing the transaction. Credit-card processing also lends itself to such a service.
Menerva Technologies Inc. in Redwood City, Calif., provides a software platform to facilitate contract negotiations. Built as components with tools from Oracle, Menerva can deliver its functionality either as a service or an application. "Online exchanges offer our components as a service. Enterprises, however, want them as a straight application," Menerva chief architect James Taylor says.
Right now, the earliest of the early adopters are using services where it makes sense and offers obvious efficiencies. Mainstream companies won't follow until there are some tested models for how to use services, attractive pricing, and tools to make the entire process easy. Independent software vendors will be the first to adopt services, packaging pieces of their application functionality as services.
Although nobody has pinned down a formula for building a software service or converting existing components to services, it might not be very different from what IT is doing today with distributed components. "Fundamentally, the core components are built the same way as any software components, using class libraries and object-oriented programming," Oracle's Dwight says. "The big thing is to get a really clean separation between business logic and presentation." Of course, building distributed components has proven to be a considerable challenge for a number of companies.
The key will be standards. "At the least, you will need to agree on an interface," says Stans Kleijnen, Sun's VP of Forte tools, a software suite. "This can be your own API, XML, Java, anything. But if you want services to interoperate with each other, you will need a standard."
The problem with standards at this early stage, however, "is that few vendors agree," continues Kleijnen. Adds IBM's Sutor: "You can build the service however you want internally using C++, Java, even Cobol. The key is how they're exposed to the external world." That will likely happen through an XML, Soap, or possibly ebXML, an E-business interface that, like Soap, adds process to XML.
XML will be used at the front end. On the back end, the service will receive a Soap or ebXML message. Internally, the service will do its thing in whatever way the developers want to do it, then generate a Soap or ebXML message as the response.
The biggest difficulty may be finding out about available services. "The first thought of every developer is to build it rather than try to locate it," says Flashline's Stack. To address this problem, Ariba, IBM, and Microsoft have proposed an open standard called Universal Description, Discovery, and Integration (see "Online Transaction Revolution," Oct. 2, 2000, p. 108; informationweek.com/806/ innovation.htm). UDDI is an XML-based registry for businesses worldwide to list themselves on the Internet for the purpose of making it easy for other companies to find them and their services. UDDI lets businesses list themselves, their products and services, the protocols and standards they support, and their location.
UDDI uses XML, HTTP, DNS, and Soap. About 130 companies have expressed support for UDDI. Even HP has agreed to integrate its rival registry, e-Speak, with UDDI. Ariba, Microsoft, and IBM each have a registry running.
For UDDI to be effective, however, thousands of companies must register their services. In addition, Sutor expects large application service providers, Internet service providers, and online marketplaces to operate private UDDI-compliant registries.
For IT, the practical reality of services is still far down the road. "This is not yet baked. It's really a vision for computing several years from now," says Hurwitz Group analyst Quinn.
So, while IT strategists can begin to ponder the implications of services, they need to continue building and deploying their distributed component-based apps, which will likely form the basis for any future services.
Photo of Desmery by John Bentham
 E-mail To A Friend | Printer-Friendly |  Send Us Your Feedback |
|
|
Featured Microsite
