A raging industry debate between competing development models was not the major factor in Mike Toma’s decision to rearchitect his software infrastructure around Web services – simplicity and connectivity were.
As CTO of work force management software vendor eLabor Inc. in Camarillo, Calif., and a member of the InfoWorld (U.S.) CTO Advisory Council, Toma had to find a way to efficiently share information with the company’s business partners. It had used state-of-the-art Java technology to build its applications, but that aggressive adoption of technology was not paying off outside the firewall.
The company needed to focus on automating inter-enterprise communication, one of corporate America’s biggest pain points, and one that increasingly represents the biggest payoff for IT investment.
“Our partners had proprietary interfaces that we had to write too many times. We wanted to come up with a ‘write once, use everywhere’ model,” Toma says. “We created a Web service that encompassed all of the [data flow].”
Instead of writing partner-specific interfaces, eLabor exposed its application as an XML-described Web service that uses SOAP (Simple Object Access Protocol) to communicate over the Internet. SOAP acts as the lingua franca between eLabor and its three business partners, which aggregate job requisition and candidate information for thousands of Internet job boards.
Agreeing on standard protocols gives eLabor’s network of business partners relatively inexpensive connectivity, rather than forcing them to invest in expensive, complex CORBA object middleware. The Web services transition also gives eLabor a technology architecture for integration, both to share data with future business partners and to tie together internal applications. It built a second Web services application that stores payroll information on PC clients and synchronizes data with host databases through XML.
“The problem you have when you’re in the enterprise application business is that you’re stuck with the legacy of what you already have and the existing architecture,” Toma says. “Doing a rewrite is a difficult sell. Things tend to evolve more. That’s the strategy, rather than revolution.”
A New Framework
Toma’s ability to jump on the Web services bandwagon early was made easier by the technical groundwork the eLabor team had laid in preparing for the Web and the hosted version of its applications, which launched in 2000.
In 1999, the company dropped its commitment to Sun Microsystems’ Java architecture and became a Microsoft shop and ISV partner. eLabor replaced most of the Java components and Java Server Pages in its applications and rebuilt them around Microsoft’s COM (Component Object Model) with ASP Web front ends.
With that work in place, Toma’s team needed to learn how to wrap existing applications with XML to move to a Web services framework.
“[XML wrapping] was only difficult from the standpoint that it was a new area. It’s not complex in terms of understanding how it worked. It’s a question of understanding the specifics of SOAP structures and writing the code,” Toma explains.
The conversion process was not totally seamless. Although SOAP is designed to be interoperable, the eLabor team stumbled into some specific implementations from different vendors. The company wrote its Web service in Visual Basic in the .Net environment, but had to debug problems interoperating through SOAP with a Perl shop business partner. As are other early adopters, Toma is eager for the next-generation development tools that implement SOAP automatically and are now hitting the market.
The company’s business environment was suited to a leading-edge approach. With only three data-exchange business partners, eLabor could pursue the model sometimes described as “loosely coupled technology with tightly contracted business arrangements.” In essence, eLabor could coax partners to adopt SOAP and XML with minimal impact and without a major investment on anyone’s part. The change to XML schemas also created a “black-box effect” that shields an application’s business logic and data formats, Toma says.
Still, getting partners on board with Web services required some concessions, Toma says. One vendor did not want to use SOAP to pass XML documents back and forth. Instead, that partner calls an ASP document on eLabor’s front-end server that passes the XML data, rather than performing the RPC (Remote Procedure Call) with SOAP.
The eLabor team also felt the lack of maturity in security, an area on which standards groups are hard at work. Toma’s team created a dedicated server to authenticate requests and manage the session. In the user-to-application Web service, where customers record employee time cards and billing information, a private key is generated. For the system-to-system Web services that control data flow between companies, IP addresses are restricted.
Toma doesn’t see Microsoft’s Passport user authentication service replacing eLabor’s proprietary system in the near term because it’s not robust enough and doesn’t have enough industry involvement. “It’s going to take a while for those tools and technologies to evolve far enough for us because we’ve created a specific implementation, so this particular security model works for us,” he says.
Despite the custom work, simplicity was the watchword for this project. eLabor’s application uses only what it needs from the grab bag of Web services protocols. Applications are wrapped in XML and communicate with SOAP over HTTP; WSDL (Web Services Description Language) and UDDI (Universal Description, Discovery, and Integration) were not implemented.
Looking Ahead
Toma learned that being on the bleeding edge can cause more pain than gain. The company started with Java in 1996. Because there wasn’t a standardized server component model, it was “a big leap” for eLabor to go to the EJB (Enterprise JavaBeans) standard and then to J2EE (Java 2 Enterprise Edition) standard in late 1998.
The company decided to become a Microsoft shop based on a performance study, the speed and flexibility of the Microsoft tools, and the availability in Southern California of Microsoft developers. Since that conversion, Toma considers himself on the leading, not the bleeding, edge. “We’re utilizing new technologies, but not feeling as much pain or loss of blood,” Toma quips.
Still, this Web services pioneer is looking for more from the technology. Part of the promise of Web services industry adoption is that third parties will offer services that can be called across the Internet. In Toma’s mind, billing and security top the list of network services he’d like.
Also, Toma says building XML support deeper into the database will make users’ lives easier, ultimately eliminating the conversion step from data objects stored in relational database to XML that goes on now.
“I believe the standards will evolve. The key is as more solutions are created, that’s going to dictate where [Web services are] going to go….We’re just scratching the surface of solutions now,” Toma says.
“There’s really no road map for people, just a general Web services push. It leaves it up to people to figure out for themselves and make them for themselves. That’s what we had to do.”
Building a New Framework
Although on the leading edge of the growing Web services field, Mike Toma, CTO of work force management software vendor eLabor, awaits the next-generation Web services tools to solve more business and technical issues.
