"War is Peace. Freedom is Slavery. Ignorance is Strength."
George Orwell made those words famous in his novel Nineteen Eighty-Four.
In a discussion with a colleague today, I realised that to attain the Zen-like wisdom of SOA, we need to accept similarly ridiculous-sounding Orwellian propositions. By Orwellian, I don't imply something sinister or Big Brother-like. I'm just talking about opposites being considered the same.
Try my version:
"Local is Remote. Synchronous is Asynchronous. Real-time is Batch."
Sounds ridiculous, right? But it's all true, believe me.
Take "Local is Remote". I've already blogged here and here about why the older concept of "distributed objects" and remote procedure calls (RPC) was wrong-headed. In a nutshell, it's because copies of objects can be passed either locally or across a network but memory references can only be passed around locally and cannot be passed over a network. So working with copies of objects is a more universally applicable paradigm than working with memory references to objects. In other words, treating everything as a remote object and passing around copies of it always works (even in the local case), but treating everything as a local object and passing around references to its memory location will not work in the remote case. The SOA approach, whether using the SOAP-based messaging model or the REST-based representation-transfer model, deals with passing copies of objects around rather than passing (or pretending to pass!) memory references around. In other words, the SOA approach treats local objects as if they are remote. Local is Remote.
What about "Synchronous is Asynchronous"? When we delve into the specifics of inter-system communication, we realise that all systems fundamentally communicate through messages, and messages are asynchronous. Then what causes "synchronous" behaviour? Simply put, synchronous behaviour arises when two systems agree on certain conventions when they exchange messages. Conceptually, we can layer the capability to correlate messages on top of a pure messaging system (Give every message a unique ID that travels with it. Then we can say that this message is in response to that one). Once we have the ability to correlate messages, we have a foundation on which we can then layer the capability to coordinate actions ("I'll do an action when you send me a response to my message, and I'll then respond to your message telling you I've done it, based on which you can perform some action"). Synchronous behaviour is a kind of coordination ("I won't do anything else until you respond to my message"). Another kind of coordination is the notion of transactions. Transactions can either be of the classic all-or-nothing variety or a looser style based on compensating actions. Both of them are types of coordination between systems. So peeling back the layers, synchronous interactions (even highly transactional ones) arise from nothing more than a layered set of capabilities on top of a basic messaging paradigm. This is a universal architecture regardless of the technology chosen. It is as true of TCP/IP as it is of SOAP/WS-*. Synchronous is Asynchronous.
But surely "Real-time is Batch" is a bit of a stretch?
I remember learning about the phenomenon of Diffraction in Optics many years ago. If you close a door or window so that just a tiny crack is visible, you may find that the light from the other side forms a regular, fan-shaped pattern on the floor or windowsill, with alternate dark and bright areas. My Physics textbook said this happens when the crack is "small", then asked the thought-provoking question, "Small in relation to what?"
The answer, of course, is the wavelength of light. If the width of the crack in the door or window is of a similar order of magnitude to the wavelength of light, you see a nice diffraction pattern.
Now what is "real-time"? Think of the mainframe-based batch payroll process in an organisation that must complete by 3 a.m. on Monday. How is this any less time-critical than the ABS (Anti-lock Braking System) on a car that must kick in within milliseconds whenever the wheels start to skid? Like with the diffraction example, we have to ask, "Real-time compared to what?" Again, the answer is the degree of precision with which we measure the deadline in question.
Strictly speaking, "real-time" is a requirement or a constraint. "Batch" is a processing model. But there's nothing to prevent us from using a batch processing model as long as it meets the required "real-time" deadline within the degree of precision with which the deadline is measured. Developers who work with message queues will know what I'm talking about. In large organisations, interfaces to many systems are through message queues. Place a request message on one queue and pick up the response message from another queue. And these queues are fast. They're fast enough to handle critical, "real-time" applications like Internet Banking, for example. The customer interacting with their bank using a browser and obtaining satisfactory response times is unaware that their messages are being put on queues and retrieved from queues, - effectively in batches of one. In many implementations therefore, Real-time is Batch.
What has all this to do with SOA?
Well, the SOA mindset is based upon such Inversion of Conventional Wisdom. Indeed, that's what makes SOA unique and that's why it works.
In a later entry, I'll expand on these concepts and present some more Orwellian truths.
George Orwell made those words famous in his novel Nineteen Eighty-Four.
In a discussion with a colleague today, I realised that to attain the Zen-like wisdom of SOA, we need to accept similarly ridiculous-sounding Orwellian propositions. By Orwellian, I don't imply something sinister or Big Brother-like. I'm just talking about opposites being considered the same.
Try my version:
"Local is Remote. Synchronous is Asynchronous. Real-time is Batch."
Sounds ridiculous, right? But it's all true, believe me.
Take "Local is Remote". I've already blogged here and here about why the older concept of "distributed objects" and remote procedure calls (RPC) was wrong-headed. In a nutshell, it's because copies of objects can be passed either locally or across a network but memory references can only be passed around locally and cannot be passed over a network. So working with copies of objects is a more universally applicable paradigm than working with memory references to objects. In other words, treating everything as a remote object and passing around copies of it always works (even in the local case), but treating everything as a local object and passing around references to its memory location will not work in the remote case. The SOA approach, whether using the SOAP-based messaging model or the REST-based representation-transfer model, deals with passing copies of objects around rather than passing (or pretending to pass!) memory references around. In other words, the SOA approach treats local objects as if they are remote. Local is Remote.
What about "Synchronous is Asynchronous"? When we delve into the specifics of inter-system communication, we realise that all systems fundamentally communicate through messages, and messages are asynchronous. Then what causes "synchronous" behaviour? Simply put, synchronous behaviour arises when two systems agree on certain conventions when they exchange messages. Conceptually, we can layer the capability to correlate messages on top of a pure messaging system (Give every message a unique ID that travels with it. Then we can say that this message is in response to that one). Once we have the ability to correlate messages, we have a foundation on which we can then layer the capability to coordinate actions ("I'll do an action when you send me a response to my message, and I'll then respond to your message telling you I've done it, based on which you can perform some action"). Synchronous behaviour is a kind of coordination ("I won't do anything else until you respond to my message"). Another kind of coordination is the notion of transactions. Transactions can either be of the classic all-or-nothing variety or a looser style based on compensating actions. Both of them are types of coordination between systems. So peeling back the layers, synchronous interactions (even highly transactional ones) arise from nothing more than a layered set of capabilities on top of a basic messaging paradigm. This is a universal architecture regardless of the technology chosen. It is as true of TCP/IP as it is of SOAP/WS-*. Synchronous is Asynchronous.
But surely "Real-time is Batch" is a bit of a stretch?
I remember learning about the phenomenon of Diffraction in Optics many years ago. If you close a door or window so that just a tiny crack is visible, you may find that the light from the other side forms a regular, fan-shaped pattern on the floor or windowsill, with alternate dark and bright areas. My Physics textbook said this happens when the crack is "small", then asked the thought-provoking question, "Small in relation to what?"
The answer, of course, is the wavelength of light. If the width of the crack in the door or window is of a similar order of magnitude to the wavelength of light, you see a nice diffraction pattern.
Now what is "real-time"? Think of the mainframe-based batch payroll process in an organisation that must complete by 3 a.m. on Monday. How is this any less time-critical than the ABS (Anti-lock Braking System) on a car that must kick in within milliseconds whenever the wheels start to skid? Like with the diffraction example, we have to ask, "Real-time compared to what?" Again, the answer is the degree of precision with which we measure the deadline in question.
Strictly speaking, "real-time" is a requirement or a constraint. "Batch" is a processing model. But there's nothing to prevent us from using a batch processing model as long as it meets the required "real-time" deadline within the degree of precision with which the deadline is measured. Developers who work with message queues will know what I'm talking about. In large organisations, interfaces to many systems are through message queues. Place a request message on one queue and pick up the response message from another queue. And these queues are fast. They're fast enough to handle critical, "real-time" applications like Internet Banking, for example. The customer interacting with their bank using a browser and obtaining satisfactory response times is unaware that their messages are being put on queues and retrieved from queues, - effectively in batches of one. In many implementations therefore, Real-time is Batch.
What has all this to do with SOA?
Well, the SOA mindset is based upon such Inversion of Conventional Wisdom. Indeed, that's what makes SOA unique and that's why it works.
In a later entry, I'll expand on these concepts and present some more Orwellian truths.
