Prepare for a Lively SOA Request-Reply Debate

It looks like the event processing blogosphere is about to be energized with a lively discussion. Opher has opined that SOA is not inherently request-reply. Pen to paper! Let the lively debates begin!

Kindly turn your attention to IBM’s discussion of SOA and their figure below.

The IBM figure was derived from the original view of SOA, Register-Find-Bind, found here in a figure titled “SOA”.

Kindly notice that Bind, as defined by, and also represented by IBM in a similar way, has a two-way arrow. This is a request-reply architecture where the client binds to the server.

In addition, IBM (from the link referenced above) also defines these properties of an SOA:

Capability Description
Loosely coupled interactions Services are invoked independently of their technology and location
One-to-one communications One specific service is invoked by one consumer at a time. The communications are bidirectional
Consumer-based trigger The flow of control is initiated by the client (the service consumer)
Synchronous Replies are sent back to the consumer in a synchronous way




10 Responses to Prepare for a Lively SOA Request-Reply Debate

  1. peter lin says:

    Even though the article presents SOA as request/response, I’m pretty sure IBM doesn’t exclude ESB from SOA. Back when I worked at IBM, there was alot of attention on SOA and what it meant. On several occassions, we were given talks about SOA, though honestly I didn’t really get the marketing speak.

    I tend to think of service orientation as a design philosophy and less about which software stack you use. Microsoft’s original service message was also bias towards HTTP. Once Microsoft came out with Indigo, they changed their message to include message transport. From a developer perspective, SOA is webservices or request response. It’s more about composing an application into services, which third parties can use. Before SOA was big, I was doing services for mobile applications and at other places like verizon. It’s too bad SOA is clouded in marketing speak. my bias 2 bits.


  2. Tim Bass says:

    Hi Peter!

    The web page I reference from IBM seem to be from the development side of IBM, not the marketing side. Here is their concluding quote:

    “The Enterprise Service Bus is an architectural pattern that facilitates and simplifies business integration through transport, event and mediation services. It connects and mediates all communications and interactions between heterogeneous nodes, both in a Service-Oriented Architecture (synchronous one-to-one approach) and an Event-Driven Architecture (asynchronous many-to-many approach). An ESB is today’s most effective way to address complex integration challenges and is the technical solution that provides the greatest business flexibility and efficient connectivity between dissimilar applications. ”

    My editorial continuation is that even if a pub/sub model is used for the underlying communications infrastructure, SOA remains a request-reply service model. Granted, there is no traditional “bind” in this model, but there is a request to a service and a reply (response) from the service.

    Thanks for visiting and commenting!

    Yours sincerely, Tim

  3. peter lin says:

    I agree with that assessment. The services that I’ve worked on, 99% of the cases there was a request and response. Ignoring the transport mechanism, a lot of SOA does fit the request/response model. I’ve worked on some services that are one way, which didn’t have a response. I still think of service orientation as a design philosophy and not the product of a stack, but that’s just my bias perspective. I never really understood IBM’s SOA message to be blunt. There are and were different views about SOA at IBM, so I wouldn’t equate that one article with the official IBM stance on SOA.

    I don’t really get the SOA hype these days. People have been building services for a long time. Equating EDA with SOA feels pointless and counter productive me. then again, I’m not a sales guy, so what do I know.


  4. Opher Etzion says:

    Hi Tim. It seems that you have found somebody in IBM who thinks that SOA = request/response, while this person is entitled to his opinion, as others in IBM, the article published in an un-reviewed forum that every IBM-er can publish his or her opinion, and with IBM size, and diversified IBM organizations (the author you cited is from Rational, according to the IBM Blue Pages), there are many opinions.

    I also don’t give IBM’s official opinions while blogging – IBM has means to broadcast the party lines.

    I think (and this is based on the famous clarification that Roy Schulte from Gartner, who invented both terms – SOA and EDA) that the term SOA has gone trhough an evolution in thinking over the years, started with more implementation-oriented to more conceptual – thus, in current thinking there is no inehernt linkage to implementation of the interaction mode.

    Again — I don’t say that SOA and EDA are the same, IMHO, they talk about different dimensions – SOA – about modularization, and EDA about type of interaction. I still think however that it is important not to position them as contradicting paradigm, since this can be inhibitor to those who implement SOA to implement also EDA, and I do believe that they can live nicely together.


  5. Tim Bass says:

    Hi Opher,

    We can also find people at IBM who believe that SOA is both (1) request-reply and (2) event-handling invocations.

    Here is quote from SOA programming model for implementing Web services, Part 9: Integrating rules with SOA

    Services interact in two primary ways; both of these also apply to rules:

    1. Request-response style — synchronous invocation by client services. A client invokes a service that may produce a synchronous result.

    2. Event-handling style — asynchronous message processing, as found in IBM WebSphere Enterprise Service Bus. A client sends a message to a service in a fire-and-forget style. The service passes a response — if there is one — back to the client via another asynchronous message.

    My editorial comment is that if SOA is to be all things to all people, then we don’t need the term EDA at all, since SOA is also, according to the IBM person above, EDA (in a manner of speaking).

    If we take a step back and look at the roots of modern-day SOA, which was based on a desire to expand the HTTP request-reply model to underlying APIs and services, we can see that SOA was designed, from the beginning to be a request-reply model. EDA was envisioned to be a complimentary event-driven model. That is why we have SOA and EDA. They are primarily different because the invocations styles are different.

    Yours faithfully, Tim

  6. Opher Etzion says:

    Hi Tim.

    In my previous response I’ve referred to Roy Schulte – he makes distinction between “historical interpretation of SOA” and “modern iinterpretation of SOA”, while different people define SOA in different ways, my interpretation is along the “modern interpretation”, and it is a general name for modularized distributed computing. As I mentioned the term EDA is orthogonal – one can build EDA on top of SOA, or EDA within a centralized monolithic environment, likewise one can implement SOA with or without EDA.


  7. Tim Bass says:

    Hi Opher,

    Thanks for clarifying and elaborating.

    Yes, I agree there are folks out there, including our dear friend Roy Schulte of Gartner, that continue to refine and evolve the term “SOA.” These “evolutions” in terminlogy are market and marketing driven, in my opinion, not technology, engineering or engineering driven.

    From an engineering perspective, there are “services.” Services are requested. This is the basis of SOA. Also, the services need to be “discovered” or “discoverable” so they are genearally published somewhere, like a registry, or simply on the web where they are found via search engines. There are security topics and issues around all of this that are germane to the traditional form of SOA.

    EDA, on the other hand, does not require the services construct. The services construct is an “add on” (or complimentary) capability.

    Yes, folks might say that event processing services may be discovered in a registry or on the network, in theory; and folks may continue to abstract EDA and SOA and EP and CEP up to a level that make them, for all practical purposes, the term you use in your comment, “modularized distributed computing”.

    This means that we acknowledge that there are folks who are now claiming that the term “SOA” simply means “modularized distributed computing”; but this is too broad of an abstraction, in my opinion, because we don’t necessarily need a services construct to implement “modularized distributed computing,” unless of course, we want to redefine “a service” as everything under the sun related to network programming!

    This excercise, IMHO, is market driven, not technology driven, because in actual implementation, none of this really matters. Folks don’t build SOAs and EDAs for the sake of building SOAs and EDAs, they build solutions to problems and they use whatever they have on hand, whatever they are allowed to access, and whatever they can afford to buy – generally in the most economical way possible.

    Thanks for commenting, BTW.

    Yours faithfully, Tim

  8. […] While we are on the topic of SOA, or “modular distributed computing” as many friends are calling SOA these days, let us take a moment to visit SOA […]

  9. Ian Koenig says:

    I find that when smart people argue about what the “answer to a question is”, it is invariably the case that they are really arguing about the question itself (ref Deep Though in “The Hitchhikers Guide to the Galaxy”), so in the context of this discussion, I will at least define my terms.

    I think there is some move in the industry to accepting that a “Service” in an SOA is more than just the “Service Interface” (which is the way you access the service). So if we accept that a Service is a “hunk of technology (and maybe people and processes) that is highly encapsulated, loosely coupled, reusable and does something useful (Roy Shulte had a few good attributes that I should actually reference) and we accept that the Service offers up one or more “Service Interfaces” to make the useful, interesting things it does accessible by somebody else, then we have a basis for discussion.

    The discussion about Request/Reply vs EDA then really focuses on the nature of the Service Interface rather than the nature of the Service. I described this in a bit more detail in my presentation given at the Gartner event processing summit (

    And to delve into how Request/Reply vs EDA in the Service Interface relates a bit further, I like to refer back to an old friend, the OSI seven layer model (which applies to the interface stack up into the application stack). I just find it useful. And using this model and mapping to EDA and SOA, what I find is that Service Interface (in a proper SOA) type concepts (like WSDL, XSD, UDDI) that describe the domain model of the interface more or less map to layer 6 (presentation layer) in the OSI stack [okay you have to squint a teeny bit to make it fit, but go with me for a second], while Request/Reply vs Event driven type concepts really map to layer 5 (session layer) in the OSI stack. In other words, they are at different layers of abstraction and therefore should not be compared directly).

    Using this stack type model as a framework, the typical Web Service Interface in use today is:

    where SOA refers to the well defined, self-describing Interface to a Service that does something useful and interesting, (described using UDDI, WSDL, XSD)

    And if we get this far in the argument without “popping a blood vessel”, then the translation of this stack into an event driven SOA stack involves the replacement of the Request/Reply HTTP interface with a proper layer 5 event based interface, on top of which the SOA constructs can happily sit. The difficulty many of us have in this argument, is that there just is no good alternative standards-based layer 5 interface that fits the requirements. People say JMS fits here, but JMS is an API that does not prescribe the wire format, therefore does not enforce interop, and so falls short. There are several proprientary interfaces that fit here (many of which follow a pub/sub paradigm), but as an industry we lack the layer 5, event based standard interface ith the ubiquity of HTTP.

    There are ways to make HTTP act in an event based manner, and many companies are doing this (including Thomson). There have been a few WS-* attempts at defining standards at this layer (notably WS-Notification, WS-Eventing, WS-EventNotification), but no real adoption that I can see (and not even clear that the Layer 5 problem was being addressed) . We even have SOA on top of SMTP (as opposed to HTTP), which is interesting as it provides an exemplar for the stack-oriented framework that I espouse, but I just dont find SMTP to be a very interesting layer 5 protocol.

    In summary, I see no conflict at all between SOA and EDA. I do see a missing piece in the interface stack, which is a ubiquitous, event based (probably pub/sub) layer 5 interface. In advance of broad industry adoption of a standard at this layer, there are numerous more proprietary means of building event driven services and ther are many people doing just that.


  10. […] Posted also as a reply to Tim Bass’s  CEP Blog […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: