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.