Re: [ws-caf] discussion on approaches for web services/ business transaction

["Mark Little" <mark.little@arjuna.com>]

> > just in case people have missed this point:
> > all protocol messages using the WS-CF interaction pattern
> > are AssertionTypes. What this means is that a service can elect
> > to receive only AssertionTypes without the lower levels
> > of the protocol stack determining their specific meaning
> > and impose semantics on them upon receipt.
>
> I understand WS-CF AssertionTypes.
>
> To repeat, my issue is not with either WS-CF or WS-Context, but with the
> plethora of *new* business transaction protocols in WS-TXM.

There are good reasons for having specific protocols and against generic
ones and on occassion vice versa. Hence the WS-CF approach. It's the old
static vs dynamic, compile time versus runtime, strong type-checking versus
no type checking, explicit versus implicit (you get the idea). If you want
to think of it this way, WS-CF defines one interaction protocol and the
current WS-TXM protocols refine that at the higher level (in a similar way
that would be necessary using qualifiers or some such approach).

>
> I also understand that the WS-CAF agenda calls for WS-Context and WS-CF
> to be discussed first and WS-TXM later, and so will be happy to take
> this particular thread back to the BTP list from which it sprang.

OK, but I suspect that all of the specifications in CAF will be worked on in
some degree from the start (or close to the start).

You could propose a protocol to be included in WS-TXM (even BTP I suppose)
that accomplished the things you want to see. That's the benefit on the
WS-CF approach. If in 5 years time everyone is using that protocol in
preference to others (since there may be other protocols added over and
above the 3 that currently exist) then "market forces" would obviously have
dictated the result. From the current author's perspective it is these very
forces that have driven us in the direction we're currently at and at the
moment I don't see a compelling argument to change (i.e., remove the
protocols we've got). Given feedback we've had since the release of the
specifications, it's quite the contrary actually.

Mark.

----
Mark Little,
Chief Architect, Transactions,
Arjuna Technologies Ltd.

www.arjuna.com