How does SOA messaging differ from OO messaging?

In recent years, there have been two popular software paradigms: one is the distributed object paradigm that grew out of OO programming; the other is SOA (service oriented architecture). Some have presented SOA as a development of OO. It is probably more accurate and certainly more interesting to present SOA as a contrast to OO. Consider the characteristics in this table.

Paradigm	The distributed object paradigm	The SOA paradigm
As supported by	CORBA standards	Web Services standards
Software components are	Distributed objects	Services
Client-server messaging is	Synchronous	Asynchronous
An invoked component is	Stateful – maintains state and persists after replying	Stateless – does not persist after replying
The talk is of reuse by	Inheritance	Delegation

This is the first in a series of articles about why architects prefer SOA to OO.

Business services in SOA (or web services for that matter) don’t have to be asynchronous, but most architects prefer them to be. Why? And before we get to that: what is asynchronous processing anyway? I asked MJ (Martin Jewell) and DC (David Cunningham) to explain, and below is an edited version of our discussion (see below for brief biographies).

1. Two kinds of synchronicity

GB: Can you help me get to grips with the slippery concept of synchronicity? I am aware people use the terms synchronous and asynchronous to mean different things, coming at the issue from different angles.

MJ: Yes, it can be confusing. Consider Connie the consumer and Sam the server. Both have their own view of the conversation between them. And let us assume the common enterprise application pattern applies, in which Connie has many sisters competing for Sam’s services.

First, we have to define Connie’s requirement for a reply to an invocation. Will Connie wait for Sam the server to reply or not? This choice is determined by what work the Connie is doing and whether it makes good sense for Connie to do something else while Sam is busy working on the task she gave him. The decision can usually be made without reference to the available technology.

Second, we have to define Sam’s messaging mode. Will Sam accept every request message from Connie and her sisters, or listen to only one sister at a time? This decision is likely to be made by a technical architect on performance grounds. It is still technology agnostic in that there are many technology options.

GB: I understand the first well. I’m not sure I understand the second.

2. Synchronous and asynchronous invocation

I understand synchronous invocation is simpler, but it limits the amount of work Connie can do, because she has to wait for a reply. There are times when Connie really does want to press on with other work, so asynchronous invocation is better.

Asynchronous invocation introduces complexities. If Connie proceeds to do something else while Sam is working, she will have a harder job dealing with Sam’s reply. She must ask what is this reply about? She must tie the reply back to the invocation message she sent. She must also ask what effect does this reply have on what I have done since I requested the service? She may have to delay or abandon some other processing.

At the highest level of design, whether Connie uses synchronous or asynchronous invocation is so bound up with functional requirements that it can be a decision for the systems analyst. But let’s look at the concerns of the technical architect. What’s the difference between synchronous and asynchronous messaging?

MJ: Suppose Sam is a simple server (say, one 64-bit RISC CPU at 2.4GHz, 2GB RAM, 500GB hard disk). Sam can be configured to handle either synchronous or asynchronous messaging. What would the differences in behavior be?

3. Synchronous Messaging

MJ: Let’s start with synchronous invocation and synchronous messaging. That is how RPC (unix) and RMI (Java) work, and where most programmers start.

Synchronous messaging is also known as blocking mode. The key to understanding it is to know that it blocks the channel between client and server. It implies a connection-oriented network.

• Connie taps synchronous Sam on the shoulder by opening a connection.
• Sam acknowledges the connection.
• Connie says ‘do this for me’ by passing a message.
• Sam offers services on a first-come-first-served basis.
• Connie waits while Sam does his thing.
• Sam completely focuses on doing that one thing until it is done and the connection closed.
• Connie is blocked from doing anything else; other consumers have to wait.

GB: You mean a second consumer can’t make a connection whilst Sam is serving the first consumer? I can draw a table to present this design option.

Synchronous invocation over synchronous messaging
Concern	Synchronicity	Connie the consumer	Sam the server
Invocation	Synchronous	waits for Sam to reply.
Messaging	Synchronous	stops her sisters using the channel to Sam.	cannot log a new request before he has replied to the first.

MJ: Yes. Every consumer must wait for Sam to be free, and Sam will rebuff attempts to connect until then. Connie has to re-try until she gets a connection, cannot send a message before that.

GB: Let me use my table to explore what design options are possible. For example, it seems counter-intuitive to implement a requirement for asynchronous invocation by using synchronous messaging. But is it possible?

Asynchronous invocation over synchronous messaging
Concern	Synchronicity	Connie the consumer	Sam the server
Invocation	Asynchronous	Does not wait for Sam to reply.
Messaging	Synchronous	stops her sisters using the channel to Sam.	cannot log a new request before he has replied to the first.

MJ: Yes it is possible. And if all you have is a synchronous messaging technology, then you just have to make it work. Sam must send a reply as soon as he gets a message, to say he has got it, then go on to process it.

If Sam and Connie were both people, they could use the telephone system like this. Connie phones Sam, he hears the ring and picks up – this means he’s accepted the call. Connie blurts out her message then immediately puts Sam on hold, without waiting to hear what he’s got to say, while she phones someone else. Sam is left to prepare his response.

But let’s not go into the complications that ensue. Let’s turn to asynchronous messaging.

4. Asynchronous messaging

MJ: Asynchronous messaging is also known as non-blocking mode. The key to understanding it is to know it does not block the channel between client and server. It implies a connection-less network.

GB: So, suppose Connie want to sends a request to a printer, then get on with other work. Connie has a requirement for asynchronous invocation. It would be natural for the architect to implement this requirement by using asynchronous messaging. I can show this design option in my table like this.

Asynchronous invocation over asynchronous messaging
Concern	Synchronicity	Connie the consumer	Sam the server
Invocation	Asynchronous	Does not wait for Sam to reply.
Messaging	Asynchronous	does not stop her sisters using the channel to Sam.	can log a new request before he has replied to the first.

MJ: For this design option, Sam will need a queue to hold requests from Connie and her sisters. Suppose all messages are equally important and of equal priority, there are no special service level agreements. Asynchronous Sam works like this:

• Sam boots up, and all his queues are empty.
• Consumers place service requests in a queue in a first-come-first-served free-for-all.
• Sam has no say over the sequence messages arrive in the queue.
• Sam takes each message, one at a time, off the front of the queue and deals with it.

GB: Suppose instead that Connie needs Sam to provide a customer name and address before she can proceed. The requirement is for synchronous invocation. But can the architect implement this requirement by using asynchronous messaging? My table now looks like this.

Synchronous invocation over asynchronous messaging
Concern	Synchronicity	Connie the consumer	Sam the server
Invocation	Synchronous	waits for Sam to reply.
Messaging	Asynchronous	does not stop her sisters using the channel to Sam.	can log a new request before he has replied to the first.

MJ: Again yes. And if all you have is an asynchronous messaging technology, then you have to make it work! Noting that you want to contrast SOA with distributed objects, this is perhaps the most interesting design option. And it is the design option favored by many architects.

GB: What’s better about using asynchronous messaging to implement a synchronous invocation?

MJ: The architect is responsible for ensuring a solution meets non-functional requirements by way of flexibility and performance. Generally speaking – asynchronous messaging is the better option here.

GB: I’ll ask you to explain that next time. I think we’d better stick for now to starting to understand how the SOA paradigm differs from the distributed object paradigm.

5. The synchronous nature of distributed objects

GB: My own experience as a programmer has been limited to synchronous invocation and synchronous messaging. For distributed programming, both RPC (unix) and RMI (Java) work on the basis of synchronous invocation and synchronous messaging. What about the CORBA standard for distributed objects? Does it assume synchronous invocation at the consumer end? Must Connie must wait for Sam?

DC: Yes. The client object sends a request message to a known but remote server in order to execute a specified procedure using supplied parameters. The server returns a response to the client, at which point the client resumes its own process. It is important to understand there is blocking of the client, or waiting time, until the server application responds with the required information.

The idea of the distributed object paradigm is that a client object invokes a server object in the same way regardless of whether the server object is local (on same computer) or remote. This paradigm is supported by CORBA standards. A CORBA compliant technology will handle the extra complexities involved when the client and server objects are remote from each other.

GB: I’m wary of the idea that a design or solution that works at one level can be scaled up to work at the next level. So often, it just isn’t true. And there can be problems scaling down too. Surely, if we code a system as though every component in it might be distributed, then we’re likely to pay a penalty where the components are not distributed? Our local invocations might become wastefully expensive. Imagine you and I had to use the telephone even when we are in the same room! But let me focus here just on understanding the nature of distributed objects.

Does CORBA assume synchronous messaging at the server end, so none of Connie’s sisters can talk to Sam while Connie is waiting?

DC: There is nothing in the CORBA architecture to prevent a server accepting multiple synchronous requests. However, in regular OO programming, you would not usually expect an object (one instance of a class) to accept a second message while it is processing the first.

There is no doubt CORBA expects the server object to be stateful – to have state, behavior and identity – and expects data integrity to be preserved. This has always been a problem for me with this architecture. The server object has to know not only that it is of type (or class) “Customer”, but that it has the identity “Fred”. To maintain data integrity, to ensure correct update behavior, Fred has to be able to negotiate with any other candidate Fred. I can speak for hours on this.

GB: Hold on! Let me put worries about stateful objects to one side. We can talk about them later. I’m content for now to have started presenting SOA as a contrast to OO, rather than a development of it. To summarise, in enterprise applications, the pressure to perform is usually on Sam the server rather than Connie the client. So, technical architects are keen to use the most performant message mode – which is asynchronous. This does not block a channel; it gives flexibility and performance advantages. It is expected in SOA, but not in the distributed object paradigm. Thanks Martin and Dave. I’ll ask about performance differences next time.

---

Graham Berrisford has for many years pulled senior IS/IT professional together in projects and workshops designed to help them understand their challenges and improve their organisation’s response. He is the main facilitator of the Improve your Enterprise Architecture workshop advertised in our event listing. Graham has asked us to point out that this event addresses higher CIO-level issues and concerns than those discussed in the above article.

Dave Cunningham works as a principal architect for a major IT services company, specialising in the health sector and currently delivering major projects to Connecting for Health.

Martin Jewell is a Consultant IT Architect with a major IT Services Supplier. He has 25 years of experience in Enterprise-scale Solutions and Architecture, and is currently working on the Technical Directorate of a UK central government client as Prime Integration Architect.