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.
"There's 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. "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 Microsoft's COM (Component Object Model), used by Windows applications, and Sun's 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 Apache's Apache SOAP tool kit for Web services support) to instead call a component we wrote in Microsoft's C# .Net language running on a Windows system.
Other efforts, notably Object Management Group'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. 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."
