SOA is like the Night Sky...
I frequently find that people have a different perspective of computing than I do. When I think about it, I am struck by the independence and separation that different systems (i.e. independent services) have from each other. In many ways, this reminds me of the night sky.
Imagine a single service in which you have a bunch of code and a bunch of data. In this discussion, I am using the word service as a bar from the previous blog. By that, I mean the aspect of a service dealing with explicit boundaries and autonomy. Being a service with explicit boundaries, there is a collection of data completely encapsulated within it. This is a set of tables that is owned by this service (bar) and not any other service. Under no circumstances do we have a transaction (i.e. an atomic database transaction with ACID properties) that spans the data contained in these tables and stuff outside of this service (or bar).
So, we can perform an ACID transaction against the fully contained data (inside the fully contained set of tables) and that’s about it. We also have the ability to transactionally consume incoming messages and transactionally enqueue outgoing messages. What we cannot do is directly examine or directly modify the data in any other service. We must rely on messaging to humbly request that the other service supply an image of some data (again via messaging) or that it accept our humble request that it consider the possibility of performing a business operation that may result in some change to the remote services data. Sometimes a partner will regularly send us messages containing images of some data that it wishes to export. These images of data are, of course, images of the way the data looked at the time of transmission to us. The data has since been unlocked and may have changed since it was transmitted.
So let’s examine this again. The act of sending a message by the remote service involves its unlocking of the records containing the data being transmitted. The message to our service is prepared and as it is enqueued for sending, the data being copied is unlocked. This is a natural consequence of the fact that the two services do not share transactions. It is impossible to see the current value of a distant record! Just as it is impossible to know if the sun blew up 5 minutes ago (since it takes 8 minutes to know at the speed of light), it is impossible to see the current value of a record in a distant service. You can see how the sun was 8 minutes ago and you can see the value of the record at the time it was unlocked. This is a new phenomenon that was not part of our psyche when we were just plain old building mainframe apps or client-server apps. In those days, we could see God’s Truth about the state of the record. We began a transaction, looked at the record, acted on the information gleaned by looking at the record, and committed the transaction (which unlocked the records).
Computing within an SOA is like the night sky. We know the state of the stuff within easy reach (we can lock that stuff that is in our service). Just like when we look up in the sky and see the light from this star that is 10 years old (the star is 10 light years away) and the light from that star is 10,000 years old, we look at the messages received from remote services and consider what they used to look like. Based upon this stale (and of various vintage) information, and the stuff we know about the local data we have, we perform a transaction. This transaction makes changes to the local data and enqueues outgoing messages. This is our star shining forth its light to arrive later at our partner services.
In summary, computing in SOA is like the night sky. We act on our local information and the information we know about what the other services used to look like. While this is a different computing model, it is the only possible computing model in a loosely-coupled and distributed world.
Love,
Pat
Comments
Anonymous
March 18, 2004
Excellent and very useful analogy. I tend to use a service-as-registrar analogy to illustrate similar ideas.
You ask the registrar a question and you get an anwser. The answer you get is what the registrar had as "current data" at the time it processed your request. Its notion of "current data" is independent of any enqueued transactions (pending updates) that may change the current value.
By the time you get the current value, the registrars notion of current value may well have changed but c'est la vie in a distributed world.
regards,
Sean McGrathAnonymous
March 18, 2004
The comment has been removedAnonymous
March 18, 2004
Pat, what you are saying is very clear. Please could you comment on what appears in a related MS blog by Ramkumar Kothandaraman's which seems contradictory:
http://blogs.msdn.com/ramkoth/archive/2004/03/08/85802.aspx
Regards,
Marcus Mac InnesAnonymous
March 18, 2004
The comment has been removedAnonymous
March 18, 2004
John is my hero.Anonymous
March 18, 2004
The comment has been removedAnonymous
April 01, 2004
The comment has been removedAnonymous
April 01, 2004
This brings up a lot of interesting questions when it is extended to the user interface. If you really can't tell what the state is on the other side, how to you inform the user of what they can and cannot do. Enabling menu items based on some state reported by the service is a problem.Anonymous
April 14, 2004
Very nice analogy. I've been thinking about all the stuff that can go wrong with compensation. (Double Faults, Subsytems withing the external system already running with the updated data, etc)
Kind of like rolling back a supernova....Anonymous
July 15, 2004
The comment has been removedAnonymous
June 08, 2009
PingBack from http://insomniacuresite.info/story.php?id=5642Anonymous
June 15, 2009
PingBack from http://workfromhomecareer.info/story.php?id=8505Anonymous
June 18, 2009
PingBack from http://barstoolsite.info/story.php?id=245