A quick definition re-cap

Web services is an umbrella term for software that use a set of XML-based standards and protocols that allow different systems to interact with each other over the Internet, sharing data and services without the need for manual intervention or translation. These data "conversions" allow applications to simply bypass operating systems, programming languages and middleware, delivering "second generation" usage of the web to connect things - now instead of connecting a company with HTML web pages, it's connecting that company's business applications with those of customers, partners and suppliers.

XML(eXtensible Markup Language) is at the heart of web services and emerged in late 1996 as a way to create structured Web documents that could contain arbitrary data in standard ways. By agreeing on schema - sets of rules in XML- two or more companies wishing to share data in machine-readable ways could do so over the Net using standard tools.

XML is necessary to describe data and make it interoperable, but web services tools are used to describe what can be done with that data, producing a much deeper level of interaction. Rather than merely passing information around, tools such as SOAP (Simple Object Access Protocol) WSDL (Web Services Description Language) and to a lesser extent, UDDI (Universal Description, Discovery and Integration) can now invoke commands to manipulate that data without the need for separate system programming.

...and our survey says:

If the above definition re-cap leaves you somewhat breathless or just plain baffled, don't worry you're in good company.

In a recent survey conducted by web services solution provider webMethods amongst 116 senior UK IT decision-makers, only 5% of respondents think they can easily explain what web services are, 84% think they can "probably" do so and 11% "would not know where to begin."

Nevertheless, 54% (hopefully from those who say they can easily or probably explain what they are) said they were using web services in a major, minor or pilot project capacity. Whilst the main barrier to adoption among the remaining 46% was an inability to quantify return on investment (unsurprising if you are only probably able or incapable of explaining what web services are...)

Reasons to be cheerful

If e-mail and the World Wide Web have become the enormous success they are precisely because the protocols were universal, scalable and truly, purely open, then web services can do the same for what has been dubbed a service-oriented architecture (SOA). 

A SOA is a technology infrastructure that depends less on how or where you implement the pieces of your business and more about what the pieces are supposed to do and the level of service that is needed from them. As such an SOA should be unfettered by issues of interface selection, lack of accepted standards,  lack of system openess etc. and should instead bridge the systems that different teams develop or different vendors provide. Like it or not, web services is the best way we have of  delivering this.

Indeed, web services has been making steady progress within enterprises for integration projects using the now well-established XML, Soap, WSDL and UDDI specifications, new versions of which are advancing all the time. But the next major shift for web services is likely to come when quality of service (QoS) standards are in place. QoS will be for instance what guarantees that a message sent over the Internet reliably reaches its intended destination, fear about which has been probably the biggest barrier to web services up-take. 

For the software vendor too one would think that there is good news in the fact that there will surely be a bigger software market if systems work together and attract business value much quicker in an open and non proprietorial way? Not so fast.

Reasons to be less cheerful

The interoperability dream is the by-product of same standards support. For example, if a web service is developed to comply with the Web Services Interoperability Organisation (WS-I) Basic Profile for Web services, it significantly increases the odds that one web service can talk to another and the other talks back in the expected way. But progress on web services is suffering as rival alliances push separate standards.

For example, the issue of QoS has split the increasingly contentious standards-setting process into two factions. On one side, Microsoft in partnership with IBM, BEA Systems and Tibco delivered a specification called WS-ReliableMessaging (WS-RM) and on the other, Sun Microsystems alongside Oracle, Fujitsu, Hitachi, NEC and Sonic Software had already introduced a rival specification called Web Services Reliable Messaging. (Good job they decided to call it something so different to avoid unnecessary confusion!)

The fact that the Sun and Oracle-backed specification had already been submitted to the Organisation for the Advancement of Structured Information Standards (OASIS) for development as an industry standard prompted Sun to say in a statement : "There is absolutely no reason for these vendors to duplicate efforts that are currently underway in recognised standards bodies..."

....But clearly there clearly is and it's got little to do with superiority of various technical approaches.

It may be viewed as somewhat politically incorrect nowadays to create proprietary systems, the correct attitude being to encourage open systems that anyone can use - provided, however, they are your open systems and you have the privileged position. Competitive instincts exacerbated by lack of communication have led to conflicts and incompatibilities in standards that threaten to undermine the very concept at the heart of web services.

Despite pledges to support standards for the greater good of the industry, the only way to create a standard seems to be compete hard enough and sell enough product so that your competitors have no choice but to support your technology. One can claim 100% compliance to open standards by using XML for everything but still create a de-facto controlled system by defining and controlling schema, hence the conflict between open systems that developers and companies want and closed proprietary areas of influence that the vendors want.

In addition two international bodies - the World Wide Web Consortium (W3C) and OASIS - each have scope over different web services standards, adding to the political confusion.