Microsoft Word - i.doc
Here, have some highlights:
Highlights
To participate in an ACID transaction requires a willingness to hold database locks until the transaction coordinator decides to commit or abort the transaction. For the non-coordinator, this is a serious ceding of independence and requires a lot of trust that the coordinating system will make a decision in a timely fashion.
Being constrained to hold active locks on records in the database can be devastating for the availability of a system.
In this paper we are considering the relationship across applications and data that are unwilling to trust each other enough to jointly participate in a two phase commit. The use of the word “service” in this paper is hereby clarified to carry the assumption that ACID transactions are not shared across service boundaries
This section examines the temporal implications of not sharing ACID transactions across services. We retrospectively examine the nature of work inside the boundaries of an ACID transaction and observe that this provides a crisp sense of “now” for operations against inside data.
Transactional serializability makes you feel alone. A rephrasing of serializability is that each transaction sees all other transactions in one of three categories:
• Transactions whose work preceded this one,
• Transactions whose work follows this one, or
• Transactions whose work is completely independent of this one.
There is no simultaneity at a distance!
– Similar to the speed of light bounding information
– By the time you see a distant object, it may have changed!
– By the time you see a message, the data may have changed!
Services, transactions, and locks bound simultaneity!
– Inside a transaction, things are simultaneous
– Simultaneity exists only inside a transaction!
– Simultaneity exists only inside a service!
All data seen froma distant service is fromthe “past”. By the time you see data from a distant service, it has been unlocked and may change.
Between the services, life is in the world of “then”. Operators live in the future. Operands live in either the past or the future. Life is always in the “then” when you are outside the confines of a service. This means that data on the outside lives in the world of “then”. It is past or future but it is not now.
Each separate service has its own separate “now”. The domains of transaction serializability are disjoint and each has its own temporal environment. The only way they interact is through data on the outside which lives in the world of “then”.
Services must cope with making the “now” meet the “then”. Each service lives in its own “now” and interacts with incoming and outgoing notions of “then”.
The world is no longer flat!
– SOA is recognizing that there is more than one computer working together!
– Multiple machines mean multiple time domains.
– Multiple time domains mandate we cope with ambiguity to allow coexistence, cooperation, and joint work.
One reality of messaging is that messages sometimes get lost. To ensure their delivery, they must be retried. It is essential that retries of the messages have the same contents. The message itself must be immutable.
Immutability isn’t enough to ensure a lack of confusion. The interpretation of the contents of the data must be unambiguous. Stable data has an unambiguous and unchanging interpretation across space and time.
The words “President Bush” have a different meaning in 2005 than they did in 1990. These words are not stable in the absence of additional qualifying data.
Anything called “current” (e.g. current-inventory) is not stable.
To ensure the stability of data, it is important to design for values that are unambiguous across space and time. One excellent technique for the creation of stable data is the use of time-stamping and/or versioning. Another important technique is to ensure that important identifiers are never reused.
As discussed above, when a message is sent, it must be immutable and stable to ensure the correct interpretation of the message.
In addition, the schema for the message must be immutable. For this reason, it is recommended that all message schemas be versioned and each message use the version dependent identifier of the precise definition of the message format.
Sometimes it is essential to refer to other data. When referencing other data from outside data, it is essential that the identifier used for the reference specifies data that is, itself, immutable.
Process finished with exit code 0