Roger Sessions, noted
architectural guru, author and Microsoft Architect MVP, has posted his
latest
newsletter
on the WS-* family of specs. In typical Roger fashion, he decides to
give them his own name – WS-SCRAM with SCRAM standing for “Secure,
Coordinated, Reliable Async Messages”. (I forget where, but I once heard
Roger refer to “three-phase transactions” instead of the relatively
standard “two-phase commit transactions”.) Roger claims MS et. al. are
pushing WS-STAR where “STAR” is an acronym standing for “Secure,
Transacted, Async, Reliable”. Personally, I’ve never seen it written out
like a an acronym and I always thought the * in WS-* was used as a
wildcard, but it is true that we are focused more on transactions than
coordination. On the Longhorn
DevCenter, Indigo is
described
as providing “secure, reliable, and transacted messaging along with
interoperability.”
This is actually the second time Roger’s taken on transactions in a web
services architecture. His last
newsletter on the
topic had a much more detailed but harder to follow example. He points
out that there are two related specs in this space –
WS-AtomicTransaction
and
WS-BusinessActivity
but that he thinks only WS-BA is going to work in the long run. WS-AT
requires holding locks open in the DB, which is highly unlikely between
services in different trust boundaries communicating with async
messaging. Am I really going to lock the records in my database while I
wait for a service that I don’t trust to figure out if it is able to
commit or abort? I don’t think so. Pat’s wrote a great
scenario
showing how unrealistic the concept of long-running transactions really
are.
However, at the end of the newsletter, Roger takes Indigo to task for
implementing WS-AT and not WS-BA and I don’t agree with him. While I
think WS-AT shouldn’t be used in web services architectures, Indigo is
also responsible for moving existing technologies like COM+ forward.
Leaving out WS-AT isn’t really an option in those scenarios. As for not
implementing WS-BA, I’ve got to wonder just how valuable is WS-BA? While
WS-BA avoids the DB locking issue of WS-AT, it still doesn’t deal with
the delegation of control. WS-BA still leaves me beholden to the
decision of some outside coordinator. This seems to violate two of
Don’stenets of service
orientation:
“Boundaries are Explicit” and “Services are Autonomous”.