----- Original Message -----
Sent: Sunday, August 11, 2002 7:34
PM
Subject: Re: [business-transaction] Re:
[bt-spec] WS-X
Alastair,
I agree with your points but I should clarify my
statement around WS-Context. My reading of WS-Context lead me to
understand that WS-Context provides a generic means of coordinating context,
not one specifically tied to WS-Transaction (although they do reference it in
their example).
Correct. The structure of the context is
defined by the service that uses it. If it's a transaction service then it's
going to add transactional information to it. If it's a security service, then
it may add different data. Same for replication, cacheing, ...
While it is true, in the BTP namespace, the
context, is transmitted as well but perhaps a little more focused on the
transaction. In short, BTP could adopt WS-Context as a more generalized
means to transmit context of any kind, not just those involving
transactions.
If there had existed a Web Services context in the web services
architecture before BTP began then I think we would have had to have a good
argument for not using it.
One could always do this with an element
reference from one context to the other (from the general to the specific
context). Correct me if I'm off base, but isn't this an area where BTP
could be amended to play in a consistent fashion with other standards that
also involve context?
If a Web Services architecture appears that has a context service within
it, then I think any Web Services specification that created and propagates
contexts will have to address it somehow. Even if it is to say that the
functionality provided by WS-CX (say) isn't powerful enough for them. Negative
responses for good reasons are as important as positive ones since (I'd hope)
they would get fed back into the development of that specification.
I appreciate your thoughts and
feedback and do hope this discussion is helpful.
Best Regards,
Bill Flood Sybase
Mark.
---------------------------------------------- Dr. Mark Little,
Distinguished Engineer, Transactions Architect, HP Arjuna Labs Email: mark_little@hp.com Phone: +44 191
2606216 Fax : +44 191 2606250
| Alastair Green
<alastair.green@choreology.com>
08/10/2002 02:31 PM
| To:
bill.flood@sybase.com cc: Mark
Little <mark_little@hp.com>,
business-transaction@lists.oasis-open.org, Mark Potts
<mark.potts@talkingblocks.com>, Peter Furniss
<peter.furniss@choreology.com>, "Cho, Pyounguk"
<pyounguk.cho@iona.com> Subject:
[business-transaction] Re: [bt-spec] WS-X
|
Dear Bill,
I find
your analysis of the current (largely predictable) situation very interesting.
We have the WS-Security business as an unfinished template.
Of course,
the most important thing about WS-C/T (like Web Services as a whole) is that
is backed by IBM and Microsoft. The value of WS for customers will drop
radically if the industry titans manage to reproduce the old CORBA vs. DCOM
battles somewhere down the line. The second most interesting thing is BEA's
role.
WS-T unfortunately ignores much of what is useful, clarifying
and novel in BTP. This means that several features that reflect some serious
collective examination of the new problems thrown up in a highly autonomous
service-oriented environment are put aside. WS-T also makes a complicating and
unnecessary distinction between "atomic transactions" and "business
activities". I guess we are going to have to rehearse all of those old
discussions about 2PC does not equal 2PL. It seems under-specified. All
in all, a splendid example of the "Not invented here" mindset, in high gear.
But hey, it's the software industry. What's new?
One of your remarks
is, I think, somewhat mistaken.
WS-Coordination - This proposal is unique and stands on its own as a
way of setting up "distributed SOAP transaction servers" - aka a
VAN.
WS-Coordination replicates
the context creation, propagation, enrollment and interposition features of
BTP (well, apart from the fact that most things have a different name). The
only aspect of WS-C which differs is the ability to type the context by
coordination protocol type, and the implication that different coordination
protocols will use the same coordinator-resource mutual-awareness scheme.
(The name "WS-Coordination" is confusing. The specification uses
"coordination protocols" in the way that I would, and just have: namely, to
identify protocols that run between coordinator and participant to create a
coordinated outcome across the participants. Such coordination protocols are
not described by this specification. It would be more accurate to describe
its protocol as WS-Infection or WS-Propagation, or the like.)
I
view the desire to permit multiple underlying coordination protocols as a
harmless eccentricity (reuse before the reuse case). Let us hope it's only use
is not wstx vs btp. In all other circumstances I suspect that the registration
or enrollment facility will be, de facto, part of the coordination protocol
per se.
From which standpoint, I would argue, it would save everyone a
lot of bother if this idea of a different "coordination" specification was
dropped in favour of a single specification a la BTP, which enables business
transactions for web services and application coordination.
I've copied
this up to the main list, because I think that the wider audience deserves to
eavesdrop or participate (I hope the
latter).
Yours,
Alastair
--
Alastair Green CEO, Choreology Ltd
Cohesions 1.0
(TM) Business transaction management software for application
coordination
+44 207.670.1679 +44 207.670.1785 (fax)
|