The idea that you can expose functionality as components capable of being consumed 'anywhere anytime' over the Internet is incredibly attractive from an applications perspective. The nightmare of application integration disappears and you can proliferate information to anyone that needs it.

At least, that’s the theory for the benefit of those who like the idea of web services as an alternative to traditional enterprise application integration (EAI).

The enterprise applications market is dominated by a handful of players like SAP, Oracle, PeopleSoft, Siebel Systems and Manugistics. Collectively, they have invested billions of dollars in making sure that once you’ve implemented their software, you won’t go anywhere else.

They do this on a technical level by developing proprietary mechanisms that route processes and data around their systems. In addition, their applications represent monolithic structures that once installed are nigh on impossible to change. The net result is that applications from one vendor only talk to other applications from the same vendor. Taking it one step further, even the simplest of things like ‘customer’ or ‘order number’ varies from one vendor to another. Overcoming these issues requires an EAI solution – not web services. However, this is not universally true.

Core business processes in accounting, sales and manufacturing may demand a packaged application approach, but these are not really prime candidates for web services. These systems are usually about automating and improving internal processes so the need to communicate is restricted to a captive audience that can be catered for either through a traditional network or by exposing information through a browser.

Sharing
Where web services have an impact is in the sharing of information between business partners. This might be order, delivery or warehouse data, sales invoices and forecasts. Attempts have been made to make sharing these kinds of data practical. In the UK, BASDA offers eBIS-XML as an open schema that developers can use for the exchange of orders and invoices but to date the take up has been relatively poor.

BASDA quickly found that industry specific requirements overshadowed their efforts. As a result, 40 some UK house-builders, suppliers and technology companies that specialise in this field clubbed together and are busy developing a range of ‘standards’ for exchanging orders, invoices, bulk quotations and tendering documents. Under the eBUILD-XML umbrella, efforts to date have been hailed as successful with a number of companies live. But as these organisations found, reaching agreement on what can and cannot be meaningfully included in a schema is tough going.

The eBUILD-XML initiative has exposed one of the fundamental issues surrounding web services – the need for industry-specific XML schemas that may have little or no value outside the industry they serve. This is fine for markets where there’s a pressing need, where the market is so large that it can support the development effort needed or where there are dominant players who can dictate how industry participants will operate. But in many markets, it is hard to see how web services can be profitably developed.

From a technical perspective, XML brings a number of problems. While standards like SOAP, WSDL and J2EE may be understood, XML presents the potential for security issues but worse still, can lead to message size bloat. Both of these have significant implications in terms of design and network load that are not easily overcome.

Despite all these issues, there is one caveat. Microsoft has said it is looking to use all its business applications as the basis for creating ‘universal’ business components that can be assembled according to requirements. In essence, they are saying that you should be able to build up an applications suite from any components that are relevant to your business processes. These components will be classic web services, combining process and data in encapsulated objects all running on the .NET framework.

You end up with an applications suite that is unique to the business built from components that your business partners can use. And because these components share a common architecture you can use them as a series of web services.

If Microsoft delivers then it will have gone a long way towards unlocking the applications straightjacket that currently prevents many companies from benefiting from the web services promise of ‘anytime, anywhere’ connectivity.

The one niggle is that this only works if Microsoft can make these components sufficiently granular such that companies will have confidence that they truly end up with what they need. To date, no-one has achieved that so pulling it off will be one heck of a feat.