From EAI to SOA

   
 

Web services made easy
Web services has been described as ‘document centric’ computing. It is deceptively simple. Werner Vogel, a Cornell University professor, identifies four components in his weblog, ‘All things distributed’.

  1. The service. This is a software program that is capable of processing an XML (extensible mark-up language) document that has been sent to it. For example, it might carry out a credit check, a currency conversion or an address search by reading the XML code embedded in the document.
  2. The document. This must be in XML. The service that sent the document, and the service that received the document, must be able to interpret the information stored in the XML document. They do this using the WSDL (web services description language).
  3. The address. This identifies where the service can be found. This address may be discoverable through a directory.
  4. A process that separates out the XML readable information from other information, such as routing and security, in the message. The protocol that does this is misleadingly named SOAP, standing for simple object access protocol, although it has nothing to do with objects.

 

 
   

Putting a new site up on the web is a pretty straightforward process. The pages and the transport mechanism must conform to simple standards, and the site must be registered, but once this is done, visitors can find it and use it with ease. They need to know nothing about how the site was built, where the data comes from, or where or how the processing is carried out.

The ease of use of the web – and the explosive surge in Internet use that followed its development – is the blueprint for the service-oriented architecture (SOA), the new paradigm for enterprise software design and integration that is sweeping through the business world.

The goal of the SOA is no less ambitious: whenever a business needs to automate a business function or process, it merely plugs into a ‘service’, just like logging on to a web site. Sometimes that service is an existing application, maybe bespoke, maybe a commercial package; sometimes it is externally operated and accessed over the Internet. To the system accessing the service, it shouldn’t matter.

By using this ‘loosely coupled’ architecture, customers hope to dramatically slash the cost of developing, integrating and maintaining software. How? By re-using services whenever they can, rather than rebuilding or re-engineering them; by making their software accessible through standard interfaces; and by avoiding expensive engineering and project management issues every time an application needs to replaced, implemented or upgraded.

One example: Sainsbury’s, the supermarket group, is using SeeBeyond’s Ican suite, an SOA backbone, as a migration tool. As it moves to fewer and newer systems as part of a consolidation strategy, systems can be plugged in and out without creating disruption.

Another example: KarstadtQuelle, Europe’s largest department store, has implemented an SOA and has turned many of its mainframe-based applications into services. Its ‘best-of-breed’ mainframe-based address management system, for example, was developed by its mail order division but is now a service that any department can use. And its credit checking systems will soon be offered as a plug-in service in the same way.

A third example: Virgin Mobile US has built its entire IT infrastructure around an SOA, enabling it to mix and match internal applications with external services, using a BEA application server hub. When it failed to reach agreement with one service provider on pricing, it simply swapped in a cheaper service with ease.

Powerful as all this is, the SOA is about much more. As applications or automated processes are exposed as services, businesses have the opportunity to re-use them as they wish. And that means they can combine anything from a handful to hundreds or even thousands of ‘services’ into new combinations, or ‘composite applications’. That gives organisations the ability to customise their processes, even using packaged applications, as never before.

Examples of these more advanced composite applications are still rare, largely because most existing applications have yet to fully opened up, but also because the architectural decisions and platforms need to be put in place. But once this is done, composite applications should prove easier to build than completely new applications, because they use services provided by existing, stable, underlying applications.

They should also address many of the problems encountered when integrating business applications using traditional enterprise application integration (EAI) systems. These systems have often been employed with the goal of creating seamless end-to-end processes, but projects often involve ‘hard wiring’ that proves expensive and inflexible.

“The original EAI promise was never fulfilled. People had to do a lot of bespoke development. SOA [and applications platform suites] are letting us move from that,” says Mark Pritchard, director of product marketing for Europe for BEA, a supplier of development and integration software suites. Most EAI vendors agree: suppliers such as SeeBeyond, Tibco and WebMethods have all re-engineered their products around the SOA vision.

The key technological development that has made all this possible is, of course, web services. Web services, while neither entirely new nor as completely functional as some of the hype suggests, is unusual in that, like very few other Internet standards, it has the complete and committed support of every vendor in the IT industry; and second, the standards describe a way for systems to interact that is relatively simple, and non-invasive.

Both of these facts have helped to accelerate the adoption of the technology. “Pretty much every tender document we see now has web services mentioned somewhere,” says John Dillon, director of marketing for software supplier WebMethods.

But the use of web services does not make an SOA. That is a step further and, while fast emerging, is only now becoming widely understood and implemented.

“SOA is evolving from being a ‘best practice’ for the few to being the common practice for the mainstream,” says Tom McCoy, a Gartner analyst. Gartner first coined the term SOA in the mid 1990s.

Most experts now agree that user organisations that attempt to roll out web services without the support of a full SOA plan will initially squander the potentially huge business benefits to be derived from web services. “An SOA is important in the development of web services because it incorporates structural features that delve deep into the corporate IT system,” says Mike Lucas, regional technology manager at Compuware. “Where the strength of web services lies is in allowing functions to be made public: SOA considers the layering and structure of the software. Essentially, SOA underpins web services.”

“An SOA is more than just an accumulation of web services. I say, think twice before you go ahead. An architecture should help you automate the processes,” says Christopher Daerr, marketing manager for IBM’s WebSphere in Europe.

This advice is critical and widely echoed. When web services were first introduced in the late 1990s, most early advocates had public, Internet-based services in mind. Little thought was given to how complex, interdependent processes and services might interact in complex, mission-critical IT environments.

It is now clear that there is a need for a central platform that handles critical functions such as workflow and process management, to ensure reliability and security, to deal with exceptions, and to provide critical ‘service-level’ applications that are not provided by outlying services.

One example is transformation – an integration function. “SOA does not eliminate the need for integration because it simply formalises the interfaces without eliminating the semantic differences between applications,” says McCoy of Gartner. Nor, indeed, does web services deal with the transport mechanisms for ensuring message delivery.

In addition, this layer can provide certain functions – such as business activity monitoring and business process management – that can only be effectively implemented as a centralised, umbrella service.

Process management is a key issue. A repeated theme in implementing SOA is that services need to be thought of in the context of overall business processes – either as complete processes or as subsets of processes. And managing these processes effectively is now as important as managing data.

“Integration is really about having a single way to manage your processes, which are now a corporate asset,” says Ram Menon, VP for marketing at Tibco.

Providing these centralised functions, whether process management, analytics or composite application building, is now the focal point of most vendor activity. Suppliers of applications, integration suites, portal software, process management suites and complete application platform suites are all involved.

Analysts warn that the creation of a new ‘fat’ service layer will be neither easy nor cheap; nor do they think it will be homogeneous and simple. Rather it will consist of many different products working together, acting as what Forrester Research calls the “service fabric”. But they are all unanimous – the end result will be easier and faster development and integration, and far greater flexibility.

Avatar photo

Ben Rossi

Ben was Vitesse Media's editorial director, leading content creation and editorial strategy across all Vitesse products, including its market-leading B2B and consumer magazines, websites, research and...

Related Topics