Service-oriented architectures promise a lot, but few have
succeeded so far.
The idea of a service-oriented architecture based on loosely bound
software services, controlled using business process management,
carries the promise of cheaper software development and better
integration with business partners.
However, this is still a distant dream for most companies. One of
the indicators is the slow take-up of UDDI (Universal Description,
Discovery and Integration) interface repository technology, in
which information about web services is supposed to be
stored.
Most suppliers have now implemented UDDI in their products: a UDDI
server is included in Windows Server 2003 and Oracle has a UDDI
directory of web services, said Andy Cleverley, UK technology
director at Oracle. Nevertheless, something is amiss.
"It has been on the back-burner in terms of speed and maturity,"
said Cleverley. "We are involved in that, but a lot of discussion
is needed. There has to be a consensus that this is going to
happen." But it is the users that appear to be hesitating. "There
needs to be some concrete business reasons for this to happen. That
is what is driving things," said Cleverley.
Changing how software is built
The biggest obstacle for many users has been the perennial problem
of the reuse of software components. Many people talk about reuse
as being "agile" and "flexible", said senior Ovum analyst Ilidio
Ferreira. "But when you look at the premise of reuse, it is almost
exactly the opposite. The more reusable you want to make your code,
the less flexibility you have in the end."
This is why companies often need to change reusable modules further
down the line to cope with diverse requirements from the
applications that use them.
Added to this is the need to reduce up-front investment in reusable
architectures by wrapping existing code as services. Todd Olsen,
chief scientist for the Together software modelling product set at
Borland, said the easiest approach to adapting existing software as
part of a service-oriented architecture is to identify the input
and output data of a particular software function and then wrap it
as a web service.
The idea of design by contract is important here, he said. Services
must treat each other as "black boxes", passing input parameters
and output expectations within an XML-based message.
"Microsoft has a good vision around that," said Ferreira. Its .net
web services architecture is evolving to support service-oriented
architectures through Indigo, the web services framework that will
ship with the Longhorn server and client operating systems. "And
the applications you already have use Biztalk. That is where the
world of enterprise application integration has an important role
to play," Ferreira said.
Lack of standardisation
Unfortunately, said Microsoft's head of technology Mark Quirk,
there are no standards dictating the granularity of a
service-oriented architecture, so services can range from just a
few lines of code to a whole application.
This constraint carries risks, said Ferreira. To be truly flexible,
services should be highly generic, which also makes them highly
granular. If the structure of your existing software architecture
makes it difficult to break it into more basic services without
extensive recoding, it will be more difficult for individual
services to meet different applications' requirements.
"You do not need to build a very granular solution, but you must be
aware of the limitations in terms of the products you have,"
Ferreira said.
The big picture
Firms hoping to reuse code face other problems. The traditional
challenges still apply: a lack of communication between different
areas of the business along with territorialism and different
design methods, makes the creation of shared reusable services
increasingly difficult as the architecture spreads throughout the
enterprise.
Jim Rivera, product manager for Weblogic at BEA, said organisations
should use a bottom-up development model, creating a shared
services architecture within smaller departments before promoting
the widescale adoption of a service-oriented architecture.
The problem is that creating shared services at a departmental or
divisional level, only to have to shoehorn them into a wider
enterprise shared service architecture later, carries the risk of
inefficiency as local efforts have to be reworked to fit into the
wider picture.
The solution to this is far from clear. "That is just the way it
is. If firms want to interoperate with other businesses, web
services are the right architecture for that and, despite the
challenges, that is what they have to do," said Charles Stack,
chief executive of asset management software supplier Flashline.
The alternative to shared services is a point-to-point model where
different units within the company expose their own services to
other departments, creating a matrix of often-duplicated services
without the unifying force of a central set of shared modules,
Stack said.
Part of the answer may lie in more mature software development
methodologies that unite business needs and technological
resources. The Object Management Group's model-driven architecture
looks promising, because it allows companies to define
platform-independent business architectures before hammering out a
system-specific model. Microsoft's Dynamic Systems Initiative works
along the same lines, generating different views of a system for
people with different developmental roles.
Nevertheless, Olsen was unconvinced about the short- to mid-term
benefits of model-driven architecture, and said the Object
Management Group may have bitten off more than it can chew.
"What model-driven architecture can do is, from scratch, depict an
application as an independent model and then target a
service-oriented architecture and have it generate a lot of the
detail-oriented code," he said. "The industry is not even close to
that point."
Combatting software reuse
Clearly, the future of service-oriented architectures rests not on
one development, but on several. First, companies have to solve the
reuse problem. To do this, they must become competent at modifying
their existing software resources to help cope with the necessary
up-front investment.
Mature development methodologies are important in a world where
many companies are still sketching out software architectures on
the back of an envelope. Until they reach this stage, they will be
unable to tackle what is perhaps the most important step: the use
of business process automation to help co-ordinate the provision of
software services.
But the onus does not rest totally on the customer base. The
industry also has to ratify more scanners to help create a robust
control layer that will enable web services to be reliably
connected together to form loosely coupled transactions, said
Ferreira.
Some of the necessary web services protocols are now working their
way through ratification, and others, in areas such as event
management, still have a long way to go. The proof is in the
pudding: Stack said that customers trying to create shared web
services as the basis for a service-oriented architecture have only
generated a handful, indicating that there is a long way to go
before service-oriented architectures find a solid commercial
footing - if at all.