For a technology concept that was meant to set the world alight, web services have not exactly delivered. So far there has been a lot of supplier hype, but relatively few full-scale deployments. However, this could all change with the introduction of service-oriented architectures (SOAs).
The SOA concept has been around since the early days of the Object Management Group's Corba standard, when object-oriented computing advocates first proposed the idea of software modules that could be re-used and accessed by different enterprise applications.
Olga Londer, principal technologist at training company QA, said the theory behind architectures such as Corba was good, but companies experienced problems implementing it.
The biggest problem was the linking between objects. Object-oriented systems link software modules together based on the name of the object and the type of data it holds. This can make software difficult to write and maintain, she said.
Gordon Van Huizen, chief technology officer at Sonic Software, agreed. "In object-oriented software the interfaces were too fine-grained and required too much dependency on the object," he said. Developers needed to know too much about what was behind the interface. "A message-style approach forces you to work in more abstract terms," he added.
XML-based web services
The messaging interface behind the revamped SOA model comes from XML, which has formed the basis for the web services frenzy over the past three years.
XML-based messages can be used to communicate between services, said Van Huizen, presenting input data and yielding results that can then be used by other parts of the business application. In this way, applications can be built up on a modular basis, and these modules can be re-used by other applications.
The difference between modern-day XML-based messaging and messaging interfaces such as Corba's Interface Definition Language, is that today messages can be built to describe the data to be processed and what needs to be done with it, rather than explicitly stating what object should be used to process the data and what methods that object should use.
The result is called "loose binding" or "loose coupling", and Londer believes it will lead to a more flexible software architecture where the services used do not have to be hard-coded into the application that calls them.
Instead, companies can specify the services using external resources that can be changed more easily. Such resources include XML-based configuration files that use workflow rules to route queries to different services. Information about the services (including URLs that point to their online location) would be stored in a separate repository called a UDDI (Universal Description, Discovery and Integration) directory.
Advantages of SOAs
The benefits of such an approach are varied. According to Londer, "It is time to market, agility and the ability to add and delete services from these systems without affecting the stability of the system are among the benefits." But the biggest advantage that the modern-day SOA concept promises is autonomy.
Mark Quirk, head of technology at Microsoft UK, said that because services built using a loosely coupled model do not rely on any other service, they can be built by different departments, divisions or even companies.
One attraction of the autonomous service model is that it helps development teams break through organisational boundaries that have represented an obstacle to re-use. As developers of tightly-bound object-oriented services are placed further apart, it becomes increasingly difficult for them to create software objects that can interact effectively with each other.
Ultimately, the idea is to move from service interaction behind the company firewall to interaction between services run by close business partners, and finally to the use of services from online providers.
A real-world example would be the provision of an online postal address validation or equity settlement service for a corporate application. The corporate customer could use such a service from a third-party provider as a part of their enterprise application, rather than having to build it themselves, thereby reducing their time to market.
The next step involves loosely coupled transactions using such services. If two loosely coupled services can talk to each other, why can't several interact over a longer period of time?
One result of this could be an online travel booking application that could handle flights and hotel bookings. The booking service could check flight availability before checking with hotels to see if a room is available. If it finds one, it goes back to the airline and confirms the flight booking, and if not, the whole transaction is rolled back.
Seeing through the hype
At this point, people who followed the development of web services the first time around may be wondering what the difference is. Everything that has just been described was on the agenda when Microsoft first announced its .net initiative.
The problem was that more experienced IT managers saw through the hype to the underlying problems. Loosely coupled transactions between companies sound great, but what about reliability, security, data integrity or service level agreements?
"It was always the intention to do loosely coupled transactions but no one had the spec at first, only the vision," said Quirk.
Microsoft and IBM have been trying to solve these problems since 2001, when both companies presented their Global XML Web Services Architecture paper to the World Wide Web Consortium. It outlined some answers in the form of XML-based schemas describing the data necessary to govern these issues. Out of that came schemas such as WS-Security, WS-Reliability, WS-Co-ordination (for co-ordinating long transactions) and others now making their way through the standards bodies.
Web services have barely hit the crest of analyst firm Gartner's hype curve, meaning that they still have to go through the "trough of disillusionment", where the majority of customers spot the gap between the supplier hype and the reality.
From that point on, technologies have two futures; if the gap between promise and reality is too great, they die or stay restricted to a niche (which is what happened to service-oriented architectures in the first place).
If the gap is narrow enough, the growth in business will be slow but steady as the product category matures. In developing the standards for orchestrating web services as part of a service-oriented architecture, Microsoft, IBM and their partners are clearly attempting to give web services the momentum they need to get through the dark days.
But there are many other problems to solve - as indicated by the fact that few people seem to be running UDDI repositories. Re-use has always been an organisational nightmare, and the cultural and technological difficulties in moving from a tightly bound monolithic applications architecture to a loosely coupled service-based model are huge.
Add or remove services without affecting stability
Organise teams of developers to work independently
Allow business-to-business IT interaction.