02/02/08 :: [Other] Trans-actions and Composition [permalink]
Peter Rosenberg asked a very interesting question. He said
you don't touch upon the nasty job of doing 'Fall Back' transactions for Loosely Coupled systems. If not at least centralized (i.e. same as Spaghetti) the 'Fall Back' transactions will never be designed nor developed, causing havoc databases over time.
he adds:
But the Web Services 'hype', seems to offer (or sell) the option of binding transactions together, to form somewhat odd 'GRAND TRANSACTION', in a loosely coupled fashion.
This is of course playing with fire since the 'owners' (i.e. Service Providers) of these Transactions may not have been orchestrated into some sort of agreement to be part of such 'Grand Transaction'. Not to mention the rules by which they can be rolled back as if they were never executed (2-Phase Commit, and similar).
If I understand correctly, Peter is basically saying that a trans-action does not exist "in isolation" of a larger choreography/collaboration. In other words, you can't arbitrarily expose actions which can be enrolled in a transaction without the knowledge of what inter-actions surround the trans-action. In particular this is how compensating trans-action can be developed.
My definition of a trans-action is the coordinated invocation of actions on resources with the purpose of aligning their state. At the end of the transaction whether the action invocations succeed or not, the state of the resources is aligned (they both know unequivocally in which state the other resources are). So a trans-action is not an inter-action, the actions being invoked are not coupled to each other, even when a compensating trans-action is invoked by the transaction coordinator, they should not have to know about each other's compensation logic.
First, I would like to point out that a good way to avoid: "causing havoc databases over time", is to use a "resource lifecycle service", if you push the responsibility of maintaining the integrity of the the resource lifecycle to the resource consumer, yes you will reach this point inevitably. The resource lifecycle has to be designed to always maintain the resource integrity. A resource lifecycle is what you mashup. The goal of the mashup is not to own the business logic of the lifecycle. Incidentally, this is why REST works so well when a user is interacting with the resource, because precisely it allows the resource to manage its lifecycle. This is also why I am so vocal against Steve Vinoski's position of a uniform interface at the resource-resource interaction level which will be used inevitably in a CRUD fashion creating a massive coupling between the two resources. Don Box suggested to use XQuery in a similar fashion, and IMHO, the resulting coupling is the same.
Now, to answer your question I would say, that yes, a "trans-action" is
definitely part of a larger choreography since actions are part of the
resource lifecycle, but I do believe that
not just one choreography is
possible and unless you are in the case of large B2B community, you are
better off giving people the flexibility to create their own assembly.
I already touched on the debate "assembly" versus "choreography"
here.
IMHO, you want to use an assembly unless the number of assemblies is
large, in that case you are better off publishing assembly patterns,
i.e. choreographies. A choreography is, IMHO, a packaged assembly.
The point to consider is that all actions are trans-actional in the
state alignment sense. When an inter-action is invoked (1PC) the state
of the initiator and target of the action need to be aligned based on
success or failure, but this kind of state alignment is self-coordinated
by the initiator (and leveraging reliable communications). The coupling
that it induces is that if the two components reach a state where they
cannot further interact, there is nothing you can do. And I think this
is the point you are making, the only way this thing can work is by
starting at the choreography level, rather than at the action level. I am
still not convinced that this is the case, I still think that assemblies
work in general though I can't prove it perfectly. My "proof" (which is
not one) is that I typically assemble resource lifecycles and work
activities. The interactions between resources themselves are mostly
event driven, in other words, it does not matter in which state the
target(s) resource end-up, they just have to be aware of the state in
which the other resource is. Let me take an example:
I have ordered two XOs for the kid back in December. My daughter asked me the other day, how do you know they did not forget about our order? This is a very logical question for a 10 year old used to always get things within days. A delay of more than a week, is so uncommon that the only logical explanation is that they "forgot" (i.e. they reached the point of database havoc). So I drew this little diagram (ok, ok, I am such a geek) for her to explain how it worked and help her understand how they did not forget.
I created the PO WSDL and the Shipment WSDL.
This little example touches on several points that I think is relevant to this discussion. So first I believe that it is a good design practice to design self-standing lifecycles. I don't want to go to shipment to figure out the state of the order. This is why "shipped" and "delivered" appear in the order lifecycle. The rationale is that you don't want to couple the order lifecycle to the shipment state machine. It has to be able to work with different types of shipments as long as their state can be aligned.
Now, if you look at the WSDLs, you'll notice a lot of notifications. This is why I always thought of that EDA did not make any sense, it is not an independent style, just like Resources are part of SOA as well. Now, I can wire the notifications together or I could use a pub/sub coordinator, it does not matter.
Let me come back to what I said earlier: the interactions between resources themselves are mostly event driven, in other words, it does not matter in which state the target(s) resource end-up. Here this would be the case if you allow an order to be paid while the "reserve" operation fails in the shipment lifecycle. This is very common, think about hotel or airplane overbooking. This "chaotic" world is best described by Mark Masterson in this post. I think where Mark and I disagree (or no longer disagree) is that yes, the world is very chaotic (and creative) in terms of work performed to transition one resource to another, however the resource lifecycle is not chaotic otherwise, my daughter will never receive her XO and yes they will forget. This is the key to enable chaos to happen actually.
In the example, I decided to use one trans-action only "cancel order". So each lifecycle exhibit a cancel operation but this is not of course designed as an inter-action (you can cancel a shipment without cancelling the order). Note that in this example, you can't cancel the order until it is shipped. So, this means that the "cancel" operation has to invoke cancel order and cancel shipment simultaneously. I can implement this in two ways: a coordination of the two operations, or I can chain them (cancel order -> cancel shipment). In any case, the result will be the same "cancel" will succeed if both succeed.
Today mash-ups are fairly trivial precisely because people don't see the deal with the mash up complex inter-actions, so end-users are provided with simple scripting (graphical or not) capabilities that amount chaining invocations with a bit of logic in between. We are "back" to the DOS -keypressed- macros. The danger as Peter pointed out will come when people will want to do "real-world" stuff with these scripting engines. We will then return to "the lost semantic vortex". Vendors will hack their scripting engine to increase the level of sophistication without ever looking back at how assemblies and choreographies work. This danger is super real if the granularity of composition is below the resource lifecycle. This is why I am so vocal about this. We have circled for over 20 years, and we are getting ready to circle again. Be assured that the "old-guard" is ready to do anything to keep their little vortex running.
Now, I don't want to underestimate how complex an assembly can be to write. We are just at the beginning of composition technologies...
Hope this helps.