Web services: sharp edge but not sliced bread

Web services aren’t sliced bread, nor are they the best things since. They’re just sharper knives in your IT kitchen. And as with sharp knives, you have to be careful not to hurt yourself with them. Web services give you a higher level of abstraction than an application server or middleware, such as Corba. That abstraction makes it easier for software developers to program relationships among disparate systems, because Web services offer a broader (but far from complete, mind you) set of standards.

Web services are the ideal tool for tying creaky but essential mainframe software to your spunkier e-commerce applications. One integrator told me that 25 per cent of his company’s integration work is based on Web services, and that percentage is growing quickly.

No wonder. Web services make things so easy. Just output everything in XML, and you’re halfway home, right?

Sorry. Not quite.

What XML format is your application asking for again? CXML, the Commerce XML? Would that be Version 1.0, 1.1 or 1.2? Or was that CML, the Chemical Markup Language? Maybe it was BPML? eXML? Or my personal favourite, YML, the Why Markup Language? If you’re using Web services, you still need to be keenly aware of the format of the services you intend to consume or share within applications. You can’t simply grab the data and assume that the format makes sense for your purposes. XML is good, but it’s not that good.

Mark Pezel, a senior management consultant at TUSC, eloquently summed up XML to me last month: “It’s intelligent ASCII.” Very cool. But not sliced bread.

In addition to the complex XML formats developers face, IT operations are forced to wrestle with the major problem of Web services management. As Web services proliferate and become easier to build and deploy, their application dependencies, their requirements for quality of service and service-level agreements, and their performance management will fall on IT’s shoulders. If you don’t control the source of the service your application needs in order to be fully functional, how can you possibly make promises about quality of service or service-level agreements?

Well, you can’t without ironclad agreements with your Web services provider. That’s not impossible; it’s just another item on your to-do list.

To further aggravate the management problem, there are no Web services management standards — only fledgling products and no best-practices track record to fall back on. You’re on your own.

Then there are the vendors, which are the primary drivers behind the Web services movement. They’ve already begun to squabble publicly about how far to push Web services standards. Most of the smaller companies involved are in agreement that more standards are necessary; the bigger ones less so, just like with every other vendor-driven standards process, from 802.11 to database adapters.

Security is another potential problem. Although I’ve been assured that Web services security has been well designed, we really don’t know yet because there are no significant Web services-based applications being used outside corporate firewalls.

And that’s all Web services are or ever will be: another tool for you to help users sail out to those islands or knock down those silos. Just don’t cut yourself with them.

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.
Show Comments