Web services: panacea or pain?

Today's requirements for accelerated time-to-market and sharp focus on costs are rubbing off on IT departments. Businesses demand that new systems be implemented quickly, so that disruption is minimal and return on investment rapid, and it's generally a precondition that existing IT investments must also be integrated and thus leveraged. However, say the word 'integration' and there's a sharp intake of breath as custom code, middleware and large consulting fees come to mind. But it doesn't have to be like that, or so the advocates of web services would have you believe. So what's this about? Difficult to say: there's been a considerable amount of hype around web services since the concept first reared its head about four years ago. But the notion of web-served software components and the underlying technologies and standards have the potential to solve many of the problems we face in integrating computer systems, including unwieldy legacy platforms. In fact, many argue that web services are the next logical step in our use of the Internet for business. At its heart, a web service provides application logic that is accessible using XML and HTTP Internet protocols. In a typical scenario, a business application might send a request to an application service at a given URL using SOAP (the Simple Object Access Protocol, one of the trio of fundamental web services standards) over HTTP. The service receives the request, processes it and returns a synchronous response. Web services are promising revolutionary tools, allowing, for example, business applications to publish services that others can use. But while there have been early adopters, there remain issues: like the fact that established XML, SOAP and UDDI standards do not in themselves provide a foolproof way of exchanging data. There are no guarantees in relation to the quality, performance and security of components. Sadly, although software vendors' claims of enhanced interoperability coming from the underpinning technologies and standards are true, it is abundantly clear that web services have been misused in marketing terms. The nirvana of true plug-and-play between systems – accessing any information and/or application anywhere, any time – is almost as far away today as it was when the technologies first appeared. As for manufacturers, uptake has been at best sporadic, although with some vendors embedding hybrid versions of web services technology within their packaged enterprise systems, some may be unaware they're already working with aspects of the technology. But there is merit in the web services movement. Thinking of EAI (enterprise application integration), web services technologies promise to make the whole middleware exercise much cheaper and easier. It also should be the case that standard technologies and interfaces mean less requirement for wide-ranging and scarce skill sets. But we have to be clear about the context and what makes sense today. "The nirvana of web services making interoperability easy is probably too simplistic," says Ian Gale, enterprise architecture manager at Ford Europe. "What web services take out of the equation is having to have things running on the same platform. But you still have all the issues of how you manage standards, and how you ensure that all your application interfaces are properly secured. They're useful – they take away the interoperability issues at a very low level – but you still need to sort out the information that needs to be communicated both to and from the service." And he adds: "When we use web services they are sometimes implemented over less open, more proprietary channels, or using techniques other than XML over HTTP protocols – which are what people tend to think of as web services." Same service, different ERP For example, one of Ford's most intense applications is a vehicle configurator that allows customers, via the corporate website, but also dealers, via an extranet (with different views), to configure cars. "There is a whole process for content and data management, in terms of identifying what vehicle options are available, their descriptions, prices and associated graphics – all loaded through a detailed and disciplined structure to be validity checked and processed in the configurator," says Gale. That's now being spread to Land Rover, Jaguar and Volvo, via the Web Services approach, so that the application is consistent across all brands and markets, yet runs over existing back end systems. Meanwhile, people championing web services say they're all about standards, and that in three clicks of a mouse button, you'll make an application a service that can be invoked on any system – in your company or elsewhere. As usual, they are being economical with the truth. Web services provide a useful tool set, but users have to understand what they're getting and where it fits with everything else they're trying to do. Security and scalability woes are among complaints levelled at implementations within the financial services sector, the prime arena for early adoption. Which is one of the reasons why the main body of users to-date have only looked at internal deployments inside the firewall on intranets. It's true that SOA (services orientated architecture) and script-based testing offer some answers to management and quality conundrums, but they don't address performance. Of course the standards bodies – OASIS, OAGIS, WSDL – are all building up proposals on security and no doubt they will get sorted out, but for now, again, beware. Another key area that limits applicability is transaction integrity and determinism. If companies are to use web services within critical business applications then questions around how you validate and manage performance have to be resolved: external components, for example, must respond within a time frame. In short, it's early days. Incidentally, it's also important to note that web services don't exist in a vacuum. They solve some of the problems of platform incompatibility and distributed computing systems, but to be successfully implemented they need a framework – and hence the much vaunted, and similarly hyped SOA, the model that enables distributed and web-based systems to function. Whereas the strengths of web services lie in allowing functions to be made public, it is the SOA that provides the structure. Does it all matter to you? That depends on where you are now. At MG Rover, for example, technical architecture and e-business manager Andrew Bull considers web services an elegant and smart way of integration, but sees no pressing need. "We have got a set of processes that are remarkably effective at generating and delivering … files. We had an advantage as a result of what we did in breaking up the old Rover company, where we did an awful lot of consolidation of the environment." However, he does see future applications at something of a tangent. "If you have a three-tier web application – the database, the application server, both inside the firewall, and a web server sitting in the DMZ – then you talk between the web server and the application server on web services," says Bull. "You have only got one port open; you can choose what it is, and you can use a non-standard port. That is inherently more secure than putting your application server in the DMZ and having to open all the ports to talk to the database." Ultimately, the technology will prove a useful addition for IT managers and their businesses. However, rather than the promised panacea, web services now looks more like a tool set – and certainly, roll out across manufacturing is likely to be some time coming.