IT managers have not been using web services, despite the supplier
hype, but XML service-oriented architectures could give the
technology a new lease of life.
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.
SOA benefits
Add or remove services without affecting stability
Organise teams of developers to work independently
Allow business-to-business IT interaction.