Those tools proliferate. Visual Studio .Net — Microsoft’s Web services-friendly IDE (integrated development environment) — is in its second version, with a third version, code-named Whidbey, shipping in 2004 with major enhancements, including a graphical tool to help developers design and build SOAs. On the J2EE side, the latest versions of application servers and IDEs from BEA Systems, Borland, IBM, and Oracle enable developers to create and deploy Web services without knowing a lick of the underlying XML vocabulary.
In other words, even Joe Developer can now wrap a COM object or a JavaBean in SOAP and publish it as a Web service. The hard part is envisioning how a given organization’s ever-expanding set of Web services will work together in an SOA and devising enterprisewide guidelines for writing the WSDL interfaces that describe what each Web service does. An SOA requires an enterprise to re-examine its business processes and to devise a strategy for expressing them in software.
“You need to think about what you want to make available and start there,” says Ted Schadler, director of research at Forrester. “The way that I hear that expressed from people who have already done it is, ‘Start with a schema. Start from the outside in. Start with a definition of the service.’ ”
At RouteOne, a startup that relies on Web services in handling consumer loan applications for auto dealers, Chief Architect T.N. Subramaniam still wrestles with the XML schema and WSDL interfaces that define Web services capabilities. “An XML schema is a definition of a document. WSDL is actually the entire transaction between two parties,” Subramaniam explains. His system hinges on the exchange of Web services documents, which exposes a WSDL limitation. He has found it quite difficult to shoehorn document schema into WSDL descriptions.
Scott Dietzen, CTO of BEA, cites a related pitfall. “The biggest problem we see right now across our customer base is schema proliferation,” he says. In some cases, “developers are introducing them at will, one for each application that’s developed,” Dietzen laments. That may ease integration in the short run, but it flies in the face of the universal interoperability promised by SOA.
Bob Sutor, director of WebSphere infrastructure at IBM, admits that wrong turns are likely. “You can create really terrible interfaces if you’re not careful — [interfaces] that nobody can use or that expose so much of the way you’re actually doing the process underneath that you can tie your hands.”
“Developers have a tendency to expose what’s easiest, and that may not be the best, longer-lived contract,” Dietzen says. “You might be better off doing more work to implement a particular Web service. Getting the right Web services contract [or WSDL description] can deliver the right long-term value.”
Safe at any speed
SOA goals on the horizon seem esoteric compared with two more immediate concerns: security risks and reduced performance. Both objections stem from the fact that Web services deal in text-based XML documents — unlike conventional middleware, which transmits data wrapped in binary protocols. Should a Web service’s XML payload fall into the wrong hands, it can be easily read. And, of course, text-based documents are fatter than binary data.