Ask JP Rangaswami, global CIO at investment bank Dresdner Kleinwort Wasserstein, about some of the many once popular technology fads that he has implemented and the enquiry may be met with a stream of invective.

But ask him about web services and the reaction could not be more different.

An early adopter, Rangaswami has already used web services to deliver information services both internally at Dresdner Kleinwort and externally to the bank's clients.

Rangaswami is not alone in his enthusiasm for implementing web services. In the UK, Martin Walmsley, ebusiness development manager at financial services provider Lloyds TSB,

built an internal application called FirstCheck to enable the bank's business clients to check the credit rating and payment records of potential customers and partners.

Although a common and simple request, it used to take up to 10 days using a combination of fax and phones. The web services application has reduced this process to mere minutes, he says.

In a recent survey of senior technology decision makers conducted by Infoconomy, publisher of Information Age, only 11% of respondents said that they had no plans to implement web services over the next 12 months.

And research from analysts at Forrester Research found that a third of organisations in the US already have web services projects underway. "We found that business leaders are encouraged by web services' potential for faster and cheaper integration," says Forrester analyst Bobby Cameron.

Under-developed

However, web services technology still remains under-developed in two key areas: transaction support and security.

Standards covering transactional integrity, mirroring the robustness of database ACID (atomicity, consistency, isolation and durability) standards are required if web services are to be deployed for mission critical or transactional applications, say industry experts.

This would mean, for example, that a web service-based transaction involving multiple databases would have to be completed in its entirety. If any aspect of the transaction failed, each individual element in the web service would roll back to how it was before the transaction was initiated. This was a complicated enough capability for software vendors to implement in standard database products. To achieve it in a standardised manner across a variety of distributed application objects will take some time to develop.

"The other way of ensuring transactional integrity is to start from the assumption that things will break in this architecture and, therefore, to build in much more tolerance and the ability to perform automated workarounds in the event that things do break," says Phil Wainewright, CEO of Procullix Ventures, the publisher of web services research site, Looselycoupled.com.

What this means is that until ACID-style standards are established for web services, organisations will have to develop their web services in accordance with different structures to the ones they have traditionally used.

"In the traditional enterprise application that booked travel itineraries, for instance, the application would reserve the flight, check the hotel, book the hotel and then confirm the flight," says Wainewright. Any failure and that transaction is automatically rolled back.

"In the web services environment, the assumption is that you are offered a whole choice of hotels. You send out requests, get replies and act on the information received.

Obviously, you still have to have an architecture that means that you don't book the flight before you make sure that the hotel's available, but you have to handle it in a different way," says Wainewright.

Security headache

More worrying than the absence of transaction support is the lack of security standards integral to the core web services protocols. "They do not address security at all. It's not so much a hole [in the standards] as a void," says Wainewright.

This lack of security standards will restrict many organisations to predominantly using web services for internal integration only, at least for at least the next two years, agrees Brian Reed, vice president of market intelligence at data connectivity specialist DataDirect Technologies.

As a result, Reed expects to see a variety of competing standards emerge. "We will probably have three security standards. Number one will emerge with 60% market share, number two with 30%, and number three with 10%," says Reed.

At the moment, most early adopters are using hypertext transfer protocol over SSL (secure sockets layer), more commonly known as HTTPS, to provide 40-bit encryption of web services that are using SOAP (simple object access protocol) for object-to-object communication.

Forty-bit encryption is widely regarded as weak and this still leaves security gaps, such as authentication – making sure that someone is who they say they are. However, there are a number security standards initiatives emerging intended to patch some of these gaps.

Most of these have been around for some time and have simply been adapted or re-branded for web services. For example, the Worldwide Web Consortium's (W3C) standards covering digital signatures, encryption and key management were originally intended for public key infrastructure (PKI) environments.

More promising is WS-Security, which was developed by IBM and Microsoft. It provides a number of modules intended to enhance SOAP message integrity, confidentiality and authentication.

WS-Security has recently been extended to cover secure message exchanging and the management of trust relationships in a federated environment.

Perhaps more straightforward for many end-users are the products from third-party web services software vendors, such as Vordel. These offer graphical point-and-click tool kits to enable users to more easily build these security mechanisms into web services implementations.

As a result of the confusion surrounding security standards, users will no doubt choose carefully before selecting their underlying security standards. Selecting the wrong one means they face a major re-working of their early web services implementations further down the line. Yet waiting to see what technologies and protocols emerge is not an option either. Users who do so risk being left far behind. "What [organisations] are actually saying is that they will wait for everyone else to commit before they commit themselves," says Wainewright.

He believes web services will encourage a sea-change in the way that applications are developed, perhaps with web services-based applications being delivered by a multi-layered network of application service providers.

For example, Wainewright believes that independent software vendors will increasingly deliver software as hosted web services components – an extension of the current practice of offering applications on a hosted basis.

"The fact that software vendors deliver applications today as a pre-packaged set of functions is an accident of history, not a necessity," says Wainewright.

In time, he says, the packaged application will become a thing of the past. "The only reason buyers will continue to buy packaged suites will be convenience, but they will not want to be locked in by doing so," says Wainewright.