Web services on the event horizon: Web services are set to evolve from a service-oriented architecture to real-time event-driven architecture , but EDAs are more likely to complement SOAs than replace them—once they're standardized

Telecom Asia, Sept, 2004 by Fiona Chau

Web services platforms are becoming more and more common in the enterprise space these days. Thanks chiefly to standardization into a Basic Profile based on protocols such as WSDL, UDDI, XML and SOAP, enterprises are seeing Web services not just as a means of solving integration problems within their LANs, but also a key component of applying the same concept on an inter-organizational level. Web services mean greater flexibility in their business processes and easier integration of applications, both of which also translate into lower network costs.

However, the concept of Web services is continuing to evolve, driven in no small part by one of the paradigm's shortcomings: the inability to deal with real-time events within the network.

Web services are typically built around a service-oriented architecture (SOA), in which a client (that is, a Web services user) invokes a service from the server. The client holds information about the state of the business process, while the server essentially responds to whatever service request the client makes.

The downside of this approach is that it's reactive rather than proactive, says Aiaz Kazi, general manager of business integration at Tibco Software.

"The key component the SOA infrastructure vendors are missing today is the support for events [such as] asynchronous business messages and real-time events, including the ability to monitor, filter, analyze, correlate and respond to events in real-time," Kazi says.

Consequently, enterprises and the Web services vendor community are turning their attention to event-driven architecture (EDA).

"Event driven architecture is an approach to deploying solutions, whereby an event triggers a message which is distributed to subscribers to that message via some sort of middleware software bus," explains Nell Macehiter, research director of Ovum.

In other words, rather than simply waiting around for a client to order a service, the server could respond to events taking place in the network in anticipation that a service may be needed by the client.

EDA is not new--vendors such as IBM and Tibco have featured this capability in their message-oriented middleware for a number of years. But some say EDA is already becoming the next major stage in the development of Web services--though not necessarily to the point of replacing SOA, and not until it is standardized.

A world of events

EDA hasn't been widely implemented to date mainly because enterprises haven't had the processing power, network bandwidth, sophisticated integration middleware, Internet standards and low-cost sensors necessary to make it work well until recently, says Dion Wiggins, vice president and research director at Gartner Hong Kong. However, he says there is a definite need for EDA in the enterprise.

"Event-driven business processes are well-suited to our event-titled world," he explains. "The real world is chaotic and unpredictable because no one can know the future or even exactly measure the present. Conventional processes are static and imprecise because they impose a pre-planned sequence of actions, regardless of current conditions. Event-driven processes react to conditions as they are, rather than as they are supposed to be."

While an event-driven approach can't automatically resolve problems that arise from extreme conditions, Wiggins adds, it can detect and report exceptions earlier than conventional systems, "providing more time and data to enable better responses when human involvement is required."

The chief difference between how SOA and EDA work, says Macehiter, lies in the "coupling" between consumers and providers (i.e. clients and servers).

Side by side

That said, SOA and EDA are not polar opposites of one another.

"SOA and EDA are equally important. There's no one tool that is going to make your life easy," says Dan Finerty, director of product management at Neon Systems. "it's when you put both together you'll get what people need, which is that on-demand, real-time environment."

Wiggins of Gartner says SOA and EDA have many things in common because "they both are ways of combining multiple software modules into large distributed applications."

However, Wiggins adds, they differ in the way they structure the relationships among the modules, which makes them appropriate for different purposes. So, for example, enterprises should use SOA when the nature of the business problem requires a request/response relationship in which the client module gets some answer--immediate or deferred--from a subordinate procedure before it can complete its work.

"Applications that draw data from new and old resources are well-suited for SOA," he says. "Older applications can be wrapped and modernized to expose their functionality through programmatic interfaces, then accessed from new calling applications. Multichannel and composite applications are the best candidates for SOA."

EDA, meanwhile, is better designed for building autonomous business components that operate independently, Wiggins says.