Service-oriented architectures will deliver eventually, but don't hold your breath

Service-oriented architectures promise a lot, but few have succeeded so far.

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.
This was last published in March 2004

Read more on Web software

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchCIO

SearchSecurity

SearchNetworking

SearchDataCenter

SearchDataManagement

Close