Legacy assets meet SOAP

THE ONGOING CONVERSATION about Web services invariably turns to barriers to adoption. A major roadblock, people say, is that would-be consumers of services find few available. This classic chicken-and-egg dilemma may shortly untangle itself. Many existing assets, including SQL stored procedures and CORBA, COM (Component Object Model), and EJB (Enterprise JavaBeans) components, can now be offered as Web services with very little effort. Simply wrapping Web services interfaces around legacy assets is no panacea. But services created in this way, although unglamorous and easy to overlook, are about to become common. And they may be more important than we think.

Consider how much of the world’s middle-tier business logic lives in the stored procedures of databases. The real number may be impossible to know, but it’s a safe bet that for logic that touches transacted data the answer is lots. Today in Oracle, IBM DB2, and Microsoft SQL Server, it is possible to export a stored procedure as a WSDL (Web Services Description Language)-defined, SOAP (Simple Object Access Protocol)-callable service. OpenLink Software’s Virtuoso, the forward-looking universal server featured in our Test Center Analysis ” Across the universe “), provides Web services encapsulation for the stored procedures of Oracle and SQL Server as well as those residing in its own native database. “No company can afford to rewrite time-tested functionality for a new Web-services-oriented environment,” says Kingsley Idehen, CEO of OpenLink Software in Burlington, Mass.

Database vendors have always recommended the encapsulation of queries and updates in stored procedures. Developers have only sometimes followed that advice. Foot-dragging, when based on fear of lock-in, may be rational. When there is no such objection, however, the prospect of hungry hordes of Web services consumers just might be the best incentive yet to convert good intentions into best practices.

A stored procedure is a choke point that’s useful not only to guarantee data integrity but also to enforce security. Alexander Vaschillo, lead program manager for SQL Server at Redmond, Wash.-based Microsoft, points out that standard user-level security applies. “The DBA [database administrator] knows who can access the stored procedure, but doesn’t know or care whether the call is direct or SOAP-mediated,” he says. There is still the matter of authenticating to the SOAP intermediary, of course, but authorization is governed by an existing and well-understood security system.

For DB2 users, the capability of exposing stored procedures as Web services has been available for about a year, as part of the DB2 XML Extender. IBM has, of course, long been working to unify SQL and XML data management, and this work continues under the name Xperanto. “But when I talk to customers, the first Web services they are deploying are doing [conventional] data access,” says Nelson Mattos, the distinguished IBM engineer responsible for the XML Extender.

The analogous Microsoft SQL Server add-on, SQLXML Version 3, has been available since February. In May, the latest release of Oracle’s application server brought the same exposure capability to authors of PL/SQL procedures. “Web services are about being open to any programming language,” says Steve Muench, an Oracle consulting product manager and the company’s XML evangelist. “Now we’ve brought PL/SQL into the fold.”

There’s nothing magical about turning stored procedures into Web services, but then again there’s nothing magical about Web services, either. In 1999 you could, and some people did, offer XML-over-HTTP interfaces to applications and data. But the network effects we’re eagerly awaiting will happen only when applications and data can be exposed in a standard way without much head-scratching. Doing SOAP encapsulation of stored procedures may not be sexy. But now that it’s a no-brainer, the universe of Web services can expand in an important way.

Other legacy assets now being made into Web services include Java classes, EJB, CORBA objects, and COM components. Wrapping these as Web services is “the ultimate new coat of paint on some key systems,” says Annrai O’Toole, executive and co-founder of Campbell, Calif.-based Cape Clear Software, whose CapeConnect platform works with existing Java, EJB, and CORBA systems. Although the legacy assets themselves need not and should not be modified, the process of wrapping them is a great opportunity to tweak the interfaces (or “facades”) exported to consumers. “It’s effectively screen-scraping,” O’Toole says. “But we can use XSLTs [Extensible Stylesheet Language Transformations] to make the interfaces more presentable, and that’s a powerful benefit.”

Screen-scraping is quite literally one of the ways that SilverStream’s eXtend family of integration tools brings terminal-style applications into the Web services era. When middleware APIs such as CICS (Customer Information Control System) and MQSeries are available, eXtend can intercept these as well. Companies moving from one style to the other can use a Web services facade to shield users from the transition, notes Fred Holahan, vice president and general manager of e-business integration at Billerica, Mass.-based SilverStream. “There’s no need to wait until you’ve completed the move to MQSeries,” he says. As does Cape Clear, SilverStream stresses that Web services wrappers are a great way to refactor your assets. You can map a product lookup, a credit check, and an order entry into three equivalent Web services, but you might prefer to present them as a single coarse-grained operation.

In the Microsoft world, Windows XP and the forthcoming .Net Server can wrap WSDL and SOAP interfaces around COM and COM+ components. Although Microsoft argues otherwise, many independent observers think that COM+ components — which, similar to Java’s EJB, tap into middleware functions such as transactions and instance management — haven’t reached the critical mass that ordinary COM components have. In any case, the .Net strategy for advancing the COM+ agenda is threefold. First, XP and .Net Server can be used to manage ordinary COM components within the COM+ administrative toolset. Second, the .Net Framework makes it dramatically easier than with classic COM to create new COM+ components. Third, COM+ components made in either of these ways can be easily exposed as Web services.

Enterprises that shun .Net Server because they don’t like Microsoft’s licensing policies or because they’re suspicious of Windows 9.x skeletons rattling inside XP-derived .Net Server may have valid concerns. But Windows’ COM+ middleware, a shining yet underappreciated technology, is significantly enhanced in Microsoft’s new servers and is cleverly integrated with Web services.

So where are all the Web services? They’re crawling out of the woodwork. Virtually every software asset can now be offered, or soon will be able to be offered, as a Web service. We’ll have to look elsewhere to find those barriers to adoption.