No Single Solution

Web services promise an ability to deliver the same functionality regardless of platform, language or device, and present a combination of new and legacy code in unexpected ways.

Seen this way, it is no wonder that the hype over web services has been so great over the last two or three years. Of course terming it "hype" implies a form of deception or misinformation. It suggests deception surrounding a publicity stunt that does not really warrant the amount of attention generated. The concrete fact about web services is that they are just that: services, not meant themselves to be the focus of attention. Shah and Apte were very insistent that web services are a packaging technology or a messaging technology (see page 30). The significance

43 A Google search, for REST 'web services' 2005, on December 13^th, 2005, produced 2,650,000 results. See, for example: http://www.newsgator.com/forum/shwmessage.aspx?ForumID=8&MessageID=8170,

http://groups.yahoo.com/group/rest-discuss/message/5065.

44 For Python, see: http://www.xml.com/lpt/a/2005/08/17/restful-web.html; and for Rails see http://www.xml.com/lpt/a/2005/11/02/rest-on-rails.html.

45 Sun and Microsoft have cooperated in the arena of web services more than ever this year and have been official guests at each other's major conferences. A press release on November 4^th, 2005, reveals that Sun is planning to create open-source implementations of specifications needed for interoperation with the WCF. This comes hard on the heels of the joint venture to use a single sign-on specification that will work for systems created by both vendors (see http://today.java.net/today/archive/index_11112005.html) .

of the service, however, is in the way it may be used to package – or "message" – anything, in other words its interoperability. A postal system, for instance, that worked in one location but not in another, that conveyed pink parcels but not green ones, that baulked at manila packaging but loved greaseproof paper, that interfaced with courier service X but not Y, would not be very useful. Web services without major interoperability run the risk of not justifying the hype.

Unlike universal postal systems, web services are not really a "one size fits all" solution.

Because web services provide an integration technology, they can in fact be mixed with

middleware technologies that have preceded them. Lomow and Newcomer explain very clearly that web services should not be viewed merely as a replacement technology:

Web services are not just adding more technology to the problems of IT; they are proposing a different approach to solving some of the problems of IT, especially around integration, because of new capabilities offered by the technology. Web services are not really a replacement technology; … Web services are not really a new middleware system in the sense that J2EE, CORBA, and the .NET Framework are middleware systems. Web services are XML-based interface technologies; they are not executable;

they do not have an execution environment—they depend upon other technologies for their execution environments… Using Web services successfully requires a change in thinking about technology, not simply learning a new grammar for the same old way of building and deploying systems. Web services currently and will always require a mix of technologies. Therefore, Web services need to be understood in terms of what they add to the picture, not only in the context of what they replace [Lomow and Newcomer, 2004].

The conclusion is clear: although web services bring interoperability to distributed computing in ways that earlier technologies could not, they represent not a replacement of the earlier

technologies but a paradigm shift.

However, their centrality should not be overestimated. Especially within the enterprise, they are not the only solution for distributed computing. Inside an intranet, where assumptions about language, platform and proprietary mechanisms may be made that would not hold good in a wider context, middleware solutions might perform better, as Table 8-1 suggests. There are

definitely situations in which the use of web-services technology would be inappropriate, e.g.

where large numbers of small web-service messages would carry a disproportionably verbose overhead, with multiplied serialization and parsing requirements. A white paper from Intrisync (a vendor with an alternative integration product to sell), published in mid 2005, stated that:

"Web Services can introduce known risks in deployment, complexity and scalability. The primary disadvantage is the performance overhead. With applications that have timing requirements and/or large amounts of data to transmit, Web Services is clearly not the best option" [Intrisync, 2005]. If, within an intranet, both systems are running, for example, Java, there would be performance advantages to using RMI with Enterprise JavaBeans, as Table 8-1 demonstrates. Interoperability is usually not a problem for an intranet.

SOAP/HTTP vs RMI/IIOP

1393 1333 371

206 135

1250

0 200 400 600 800 1000 1200 1400 1600

1K RMI/IIOP 1K AXIS/HTTP 5K RMI/IIOP 5K AXIS/HTTP 10K RMI/IIOP 10K AXIS/HTTP

Complexity of Payload

Operations per Second

Table 8-1:Performance Differences Between SOAP and RMI [Adapted from IBM Software Group, 2003]

There are also situations in which simple XML over HTTP, as used in REST, may be all that is required to access the functionality of a fairly simple service and in these cases the extended protocol paraphernalia that has attached itself to web services (as witness the change in the W3C definitions on page 28) would be overkill. The vast majority of service applications probably lie somewhere in-between and for them combinations of SOAP and WSDL together with quality-of-service additions such as security and transaction management provide a useful solution.

Such exceptions aside, the paradigm shift represented by web services, as discussed in this study, represents significant potential for the entire IT enterprise; but only if interoperability is assured in future developments.