Enterprise Software

What consultants should know about Web services standards

The alphabet soup of Web services standards continues to thicken with its latest ingredient, BPEL4WS. Find out what the experts recommend consultants know about the standards when advising clients on early Web services initiatives.


Gartner predicts that by 2007, Web services will enable simple process interconnections within and beyond the enterprise, but the development of Web services standards still will not be complete. Large companies hoping to secure their place in the Web services market have proposed a bevy of standards, such as the recently released Business Process Execution Language for Web Services (BPEL4WS), a standard proposed by Microsoft, IBM, and BEA Systems. Competing standards include:

We asked some experts which standards are receiving the most attention from Web services’ early adopters and which are the most important for consultants to know, understand, and use for fledgling Web services efforts.

What is BPEL4WS?
To find out more, read “BPEL4WS is a marriage of two rival standards.”

Time is now for pioneers to act, consultants to sell
Gartner forecasts that enterprises that are already using—or will soon begin using—Web services will be in an exceptional position by 2007 to benefit through cost savings, productivity enhancements, and new business processes. Those who wait for the standards, technologies, semantics, and business models to become stable will find themselves at a competitive disadvantage.

The time is right for consultants to begin selling Web services to their clients. TechRepublic recently provided some advice for selling Web services, especially to clients who have invested heavily in Enterprise Application Integration (EAI).

Using Web services for integration
The best projects to pursue at this point are well-defined integration projects for medium- to large-size businesses, according to Bill Ericson, vice president of development at SwapDrive, a developer of online data backup systems.

Steve Brown, the CTO of Metastorm, a business process management (BPM) vendor, and Bernhard Borges, managing director of advanced technology practice at PwC Consulting, agree that integration is the place to start. Borges added that small custom applications are another area ripe for exploration.

Don’t be deceived by Web services’ supposed simplicity
Brown advocates finding clients who have an established IT infrastructure that needs to be integrated. It’s those clients who stand to make a very early and very large return on investment, he said. Brown said that suppliers, such as SAP, and clients are using Web services for integration efforts because it’s easy not only to call, or produce, an existing Web service, but also to produce a Web service interface on top of any existing application program interface (API).

Borges warned that it’s important that consultants—and their clients—are not fooled by the “perceived simplicity of Web services.”

“The dynamics of developing and operating in a truly distributed, loosely coupled environment is something a lot of people don’t have a lot of expertise with,” he said.

He recommended that consultants spend a great deal of time in the “proof of concept” stage to ensure that the standards you use will leave your options open.

“Inevitably you will start to go down a path around design—whether it’s UDDI or otherwise—that will define a significant piece of your future as far as Web services,” Borges said.

Once a system is deployed, it’s difficult to go back and redesign. Some folks have a tendency to unknowingly lock in or create certain constraints that may create problems later, he said.

“It’s very simple to go to any vendor Web site, download the Web services or SOAP kit, and just start doing stuff, and connecting applications without taking care of what mess may be down the road,” Borges said.

Even though a Web services interface is a lot cheaper than a proprietary solution, consultants should spend just as much time in the planning stages because the client will have to deal with the longevity of the connector map.

“People underestimate the degree of granularity they need to fully exploit Web services when they start decomposing or rewriting applications,” Borges said.

“Interoperability doesn’t just fall into your lap”
Regarding which standards it’s most important for consultants to know about, Borges jokingly said he’d been trying not to think about it because the answer is, “all of them,” since they’re all in fairly nascent stages of development.

The must-know standards for any consultant are BPML, BPEL4WS, BPSS, and EDOC, according to Borges. Consultants often encounter factions in a client IT staff with an allegiance to one vendor or standard, Borges said. In those situations, consultants have to be the brokers between the different technologies and standards and be able to explain the differences. The consultants have to help the client pick the best possible solution, but they can’t do that responsibly if they’re ignorant of the options.

The standard you choose will often depend on where a client wants to go, and how fast, Borges said. If you’re working with a client’s intranet, it probably doesn’t matter because you can implement as the specs are evolving, he said. But if you’re working across an extranet or the Internet, the standard you choose is a critical issue and may depend largely on the standards being used by the client’s most closely linked business partners.

“Interoperability doesn’t just fall into your lap,” Borges said.

Keeping up with emerging standards and their practical use in the industry will be an ongoing job for quite some time. Gartner predicts that variations in vendor implementations and inconsistent and overlapping standards—specifically those that address business process execution—will continue to be issues for sophisticated development efforts through 2007.

Editor's Picks

Free Newsletters, In your Inbox