There is always an abundance of vendors with products that will, ‘out of the box’, allow you to effortlessly take advantage of the many benefits the latest paradigm shift promises to deliver. Welcome to today’s incarnation of ‘the next big thing’ – Web services. Web services are being touted as a new way to enable electronic trading and application and process integration over the Internet. They are also said to have the ability to turn monolithic legacy applications into discrete components that can be accessed over the Internet.
Pretty impressive, but is it true? What actually is a Web service when one has a look at the specifications existing today and the capabilities they can deliver?
A Web service is an emerging ‘standard’ mechanism based on XML for interoperability between heterogeneous operating systems, languages, applications and business partners comprised of three component specifications. They are:
SOAP: Simple Object Access Protocol
WSDL: Web Services Description Language
UDDI: Universal Description Discovery and Integration
Great, more alphabet soup ... What do they mean?
The idea behind Web services is as follows: A software developer wishes to expose (sell?) some functionality as a ‘Web service’ that can be consumed by other applications over the Internet. Regardless of the language in which the code is written, it can be described using WSDL, which defines the interfaces in a language-neutral manner using XML.
Having described how the functionality can be accessed in a language-neutral manner, the Web Service is then listed in a repository as defined by UDDI. Think of this as a ‘yellow pages’ for Web services.
The idea, then, is an organisation in need of a particular piece of functionality can peruse the UDDI repository, find a Web Service that fulfils its needs and then invoke that Web Service directly using SOAP.
That is all there is to Web services as it stands today.
Keeping up with technology
In theory, Web services should provide a ‘standard’ mechanism to ensure one application can call services of another without having to worry about differences in languages, operating systems or organisational domains. The proponents of Web services claim this will usher in an era of unprecedented ease in collaborative electronic commerce. Are they right?
History might be instructive. If one goes back to the growth of the railroads in the 1800s, the factor probably most responsible for the rise of rail as a mode of transport was standardisation of track gauges. Before standardisation, trains from one company could not travel on tracks built by another. After track gauges were standardised, rail transport became the dominant mode of transport across continents.
The Web services concept is akin to standardising the track gauges of the electronic railroads being built today, enabling software to interoperate. The theory is, as long as we all agree to define the software to each other in a ‘standard’ way (WSDL), and agree on a common way to invoke software services (SOAP), then our interoperability problems are a thing of the past.
The Java camp can continue to develop in Java, the Microsoft camp can embrace .NET and the mainframe developers can continue with COBOL, and in theory they can all talk to each other effortlessly. Utopia!
Like standardisation of rail track gauges in the 1800s, Web services are a low level means to bridge infrastructural domains. As important and worthy this goal is, it is far from the complete picture needed to enable collaborative electronic processing.
Next month we will look at some of the limitations in the Web services model and expose some of the hype surrounding this ‘next big thing’.
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.