eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The next big wave in application design is out there, gathering momentum beyond the shallows of day-to-day IT.
That wave is Web services—business logic or information made available using the XML (Extensible Markup Language)-based SOAP (Simple Object Access Protocol).
In this package, eWeek Labs explains how Web services provide ways to lower costs and tighten business relationships and how and when e-businesses should figure the architecture into their strategic planning.
Until now, and for the near future at least, Web services are more hype than substance, although vendors such as Microsoft Corp. and Sun Micro- systems Inc. have built their respective .Net and Sun ONE development strategies on the concept. Theyre not alone—expect legions of Web services advocates to crop up soon, and stay away from those who arent pledging unswerving dedication to the World Wide Web Consortiums XML and SOAP standards work.
Web services are the great leveler of heterogeneous networks, a universal communicator technology for IT.
In fact, easy communication between wildly different hardware platforms is one of the most obvious—and most immediate—benefits to a Web services architecture. For example, an employee could use a J2ME (Java 2 Micro Edition)-based handheld device, such as a Motorola iDen mobile phone, to directly access services on an IBM OS/390-based mainframe (using, in this case, a J2ME SOAP client from Lutris Technologies Inc. and mainframe SOAP server software from IBM or Iona Technologies plc.).
Web services also are the most likely foundations for a new wave of e-business relationships carried out using loosely coupled IT architectures. Web services let organizations selectively provide business partners with access to internal applications or data without having to design custom, one-off gateways for each business partner. They also let organizations access these same types of services provided by others to build client applications that integrate information from a wide variety of internal and external sources in real time.
Web services as a common computing platform are still a couple of years away; the infrastructure needed for many external (though not internal) Web services, such as a licensing or payment system, isnt available yet.
A number of demonstration services are already online, however: The xmethods.net Web site provides FedEx Corp. package tracking, currency conversion and lookup of California highway road conditions; integration tools vendor Cape Clear Software Inc. provides weather conditions at airports; Continental Airlines Inc. provides flight status information; and ActiveState Corp. provides stock quote data. In addition, Microsofts HailStorm project is its initiative to provide Web services of various kinds.
At Developer Stage
At Developer Stage
Certainly, caution is warranted when it comes to deploying Web services in critical infrastructure; the technology is still in the developer-preview stage, and interoperability problems remain among different SOAP implementations. For example, handling of the HTTP SOAPAction header is required by Microsofts .Net but not provided by default with Apache Software Foundation Inc.s Apache SOAP.
Lack of developer tool support remains the biggest stumbling block to Web services deployment. Although the standards (such as XML and SOAP) and base libraries (such as Apache SOAP) for Web services are now fairly stable, mainstream development tools are still largely ignorant of the new platform. (eWeek Labs reviews of the beta versions of two major development tool releases, Microsofts Visual Studio .Net and Suns Forte for Java 3.0 Enterprise, begin on Page 60.)
One tool thats had a relatively significant lead in the Web services space is Borland Software Corp.s Delphi 6, which shipped in June with native support for creating SOAP servers and SOAP clients. Another company at the Web services edge is IBM, which shipped its WebSphere 4.0 Application Server with integrated SOAP tools last month.
However, even if the tools an organization uses dont have native Web services support, as long as the language in question has Internet protocol and XML support, Web services arent really that complicated to develop.
The point is, the time to be exploring these technologies for competitive advantage is now, and eWeek Labs recommends next year as the time to start deploying Web services in production, first for internal and then to selected outside partners.
Tackle Internal Jobs First
Tackle Internal Jobs First
Although connectivity between dissimilar hardware and distributed networks is the ultimate objective for Web services, our examination of where and how early adopters are using Web services showed a surprising finding: The most immediate benefit of Web services is for strictly internal deployments—for example, database integration jobs.
“Theres enough interest in internal uses of Web services that we decided to make it part of our whole architecture,” said Sanjay Sarathy, director of product marketing, application and integration services for iPlanet, at the Sun-Netscape Alliance, in Santa Clara, Calif. “Building inward out has a significant appeal for a lot of people. Doing it on an ad hoc basis externally and internally is difficult.”
One especially difficult interoperability barrier—the gulf between Microsofts COM (Component Object Model), used by Windows applications, and Suns JavaBeans and Enterprise JavaBeans object model—is getting much easier to bridge through SOAP.
In eWeek Labs tests, we modified a SOAP-based Java client application that was designed to call code running in iPlanet Application Server (which uses Apaches Apache SOAP tool kit for Web services support) to instead call a component we wrote in Microsofts C# .Net language running on a Windows system. (For a comparison of C++, Java and C#, see graphic below.)
Other efforts, notably Object Management Group Inc.s CORBA (Common Object Request Broker Architecture), have tried to provide distributed computing before. “The problem with CORBA was it was a little too big,” said David Young, Lutris Technologies chief evangelist, in Santa Cruz, Calif. Young was on the X/Open standards group in the early 1990s when CORBA was undergoing heavy development. “[It was] boiling the oceans,” Young said, “being everything to everybody. SOAP is a much simpler notion of implementation independence. SOAP is absolutely key to creating a bold, beautiful, interoperable world.”
Riding on SOAP
Riding on SOAP
SOAPs shoulders will need to be pretty broad to support all its been promised to do, especially for a protocol only about 2 years old. Still, its momentum is stunning, and Web services are a reality already because of how quickly and broadly SOAP and related technologies have been adopted, even by archrivals such as Microsoft and Sun. SOAP site www.soapware.org lists 71 SOAP-enabled software packages, and many others are now in development.
In addition, Web services meta- infrastructure—such as directories of available services and proposed standards on encryption, digital signing and message routing—are rapidly emerging. Directories of services are listed in Universal, Description, Discovery and Integration directories at Microsoft and IBM, with other companies soon to follow.
In two to three years, we could see a much more fluid model of where and how applications get information and carry out transactions. Well-defined interfaces based on the easily manipulated XML, combined with internal and external service directories, will make it unnecessary for the most part to reinvent the programming wheel.