Web service platforms take root in enterprise: move toward event-driven architecture predicted

America's Network, Nov 1, 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.

EDA RISES

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 Neil 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.

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 research firm Gartner. However, he says there is a definite need for EDA in the enterprise.

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.," 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 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.

"Enterprises should use events for applications in which multiple processing streams may execute simultaneously; the timing of events, such as the beginning or end of a step, or the arrival of additional external input, is unpredictable; or there is a need to dynamically add, drop or modify processing steps without changing any running modules in any way," he says.

Kazi of Tibco Software, which has been providing EDA solutions for the past decade, agrees that SOA and EDA are complementary rather than competitive.

"We see support for EDA as a critical component of an enterprise architecture," Kazi says.

Mark Glikson, strategic architect for developer & platform evangelism at Microsoft Asia Pacific, goes further, arguing that SOA and EDA are really two sides of the same coin. With EDA, Glikson says, a publish/subscribe approach is typically discussed, and there is no reason why this is specific to EDA and mutually exclusive to SOA.