Friday, August 16, 2002

WS-Coordination and WS-Transaction quick summaries for the COM+/Enterprise Services savvy: WS-Coordination is all about setting up contexts. WS-Coordination lets you create a "context" out of the blue that you can propagate/flow to anyone you want to talk to in "the context of what you are currently doing". That context can be used to hang any number of services on it, like, for instance, transactions. A transactional WS-Coordination context flows from participant to participant (COM+: Supported, Required) pretty much exactly like an automatic transaction flows from component to component in COM+. If you figure that the context that flowed to you is incompatible with the things you need to do, you create your own context (RequiresNew) and flow that to your underlings. WS-Transaction is three things: (a) It gives us an equivalent MSDTC's ITransaction interface for initiator of the transaction (see below) and gives the initiator "Commit" and "Abort" powers ("Completion protocol") and an optional notification on transaction outcome ("Completion With Ack"). In COM+ terms, this would be used by any interception stage on a newly created transactional context (Required,RequiresNew). It also defines a "bring your own transactions" style enlistment that allows you to import and external transaction into your local transaction monitor (TPM). (b) It gives us an equivalent to the likes of OLETx, XA and TIP and defines an XML based, TPM-to-TPM protocol (Messages: Prepare,Prepared,Commit, Committed, Abort, etc.). That is referred to as the AT protocol for atomic transactions. (c) It also gives us a pretty nice compensation based transaction coordination protocol for long running processes that is explicitly not 2PC. This called BA protocol for business activities. So, if you are not in the business of writing an infrastructure of the scale of J2EE or COM+ or are in the business of writing things like Tuxedo or MS DTC ... this is probably mostly stuff to look at for your academic enjoyment -- the exception is BA which is actually a pattern to read, understand and do daily today -- whenever you are using transactional message queues. 4:18:44 PM      comment []

So, here we have it. You easily qualify as the leader in the Web services field if you declare leeching a corporate strategy. The standards emerge by themselves, you know, and once they're done they cost nothing and then ONE only needs some volunteers to kill everyone else in the market place. I start to get the feeling that there'll be a "Hall of Fame" entry as a reward for naive thinking listed here much sooner than I ever thought. 3:26:17 PM      comment []

Reading the WS-Transaction specification: WS-Transaction and WS-Coordination are, as we say in German, "hartes Brot" (hard bread to chew on). Once potential point of confusion about the diagrams in the WS-Transaction spec is there seem to be request/response exchanges between participants -- while that's indeed not the case. Here's what I read: All of WS-Coordination and WS-Transaction does assume two-way connectivity between any two endpoints. When in Figure AT2, (step 8), CoordB sends a "Prepare" to CoordC, it will not sit there on the sending thread and wait for a "Prepared" or "Aborted" message (step 11). Instead, CoordB will send "Prepare" in a fire-and-forget, one-way fashion and just remain in phase 1 while it waits for CoordC to actively contact it with "Abort" or "Prepared" (step 11). Here's a few thoughts as I read: Not using request/response is essential for relaying WS-Transaction negotiation over protocols like HTTP, because HTTP delivery isn't a reliable transport. Mapping this to HTTP essentially means to drop packets at the remote endpoint using POST without even looking at the response body (however recognizing HTTP status classes 300/400). The remote endpoint must actively acknowledge every message on a separate connection. What's somewhat lacking in the WS-Transaction spec (as it stands) is a clear statement, that reliable messaging is required and QoS for delivery of every message must be "at least once" and better "exactly once".  Can such acknowledgements be piggybacked on the replies? Yes. However, there needs to be a logical time-instant where CoordB knows that it has CoordC in the "prepare pending" state. So, even if the ack and "Prepared" arrive in the same package, the ack must be processed before the "Prepared". Must the acknowledgements be piggybacked on the replies? No. Depending on the task, "Prepare" may take quite a bit of time and to keep the whole process short, CoordB will have a very little "time to panic" period in regards to timeout/resend for its "Prepare" message. CoordB cannot distinguish between "Prepare" getting lost and CoordC simply taking a long time to process it and therefore it's desireable that CoordC acks the message before starting its "Prepare" work. Another not-so-clear aspect is the role of context expiration of WS-Coordination in the WS-Transaction scope. By default, with no expiration time set, the operation will take forever and until done. However, if a expiration time is set, CoordA will time out at the defined time and will cause a unilateral abort by timeout. So, does reaching the expiration time-instant mean that all further messages relayed within the scope established context will be discarded? No. The context expiration time must be disregarded entirely if one or more participants are in "commit pending" or in "committed" state and the context lifetime must be considered as having been extended to "forever".  The only participant knowing whether there is potential for any other participant being in any of these two states is indeed CoordA, who listens to the completion protocol requests and is the superior coordinator. None of the participants except for CoordA may cause a unilateral abort or may refuse message relay due to timeout of the context, if they have reached "Prepared", because some other participants may already be committing/committed. Context timeout and message timeouts never have any actual relationship in phase 2 and individual message timeouts may be well past the initial context expiration time.  The context timeout is indeed of high information value for any participant before they are in "Prepared". When the context expires, they can unilaterally abort within their control scope, but must keep replying to messages until the protocol state is cleaned up. If a participant decides to unilaterally abort on context timeout before Phase 2, it must still be able to reply to "Prepare" by sending an "Abort" message. This may mean that if it doesn't find any trace of the transaction that shall be prepared (because it's been locally discarded already) it may reply with "Abort" just for that reason. 12:42:34 PM      comment []

© Copyright 2002 Clemens Vasters.