-----Original Message-----
From: Mark Little [mailto:mark.little@arjuna.com]
Sent: 28 May 2004 10:40
To: Greg Pavlik
Cc: Green, Alastair J.; ws-caf
Subject: Re: [ws-caf] Coordination Contexts
There is no broad functional utility to climbing mt.
everest, merely
subjective utility in the more or less Mengerian sense of
the term. As
much as I enjoy mountaineering, this is not an appropriate
analogy for
structuring the discussion moving forward. Apologies, but
I'm changing
the thread title to reflect the issue at hand more directly.
I didn't there would be any utility in this excercise of
climbing, only that it's possible ;-)
I did think that we had gotten through this "is context
useful" debate, since whenever it has come up before (along
with any related issues), a majority of this TC has either
expressed or voted that the answer is "yes". How many times
do we need to go around this before we can move on?
Mark.
As I understand it, Alastair's position is that we require a
Coordination context, but that it ought not derive from WS-Context,
but should be invented, along with necessary control interfaces and
semantics, afresh strictly for application to protocols
that require
coordination signals to be sent in the lifecycle of an --
and I'm not
sure what term we would apply here without either subsuming or
referencing WS-Context -- activity. Is this correct or have
I grossly
misrepresented the position?
Greg
Mark Little wrote:
Alastair, I'm happy to discuss climbing Everest in the context (no
pun
intended) of WS-CF iff that does not impede the progress of
WS-Context.
Mark.
----
Mark Little,
Chief Architect, Transactions,
Arjuna Technologies Ltd.
www.arjuna.com
----- Original Message -----
From: Green, Alastair J.
To: Mark Little ; ws-caf
Sent: Thursday, May 27, 2004 1:07 PM
Subject: RE: [ws-caf] Mt Everest and WS-CF
Mark,
I am not asking for anything to be revisited (at least
fundamentally:
if it turns out there are unturned model issues or bugs in
WS-Context over time, I'm sure we will all be happy to
entertain them).
I am content that WS-Context exists, and that you think it is
valuable,
while I question its value.
Like Mt Everest, it is there. That may not mean that I want to
climb
it.
My current concern is precisely the relationship between
WS-Context
and
WS-CF, which you take as given, and which I wish the TC to question.
If you look again at my mail you will see that I am making two
points,
which I think you are missing.
1) I am not discussing whether to use by-value or
by-reference. I
am
discussing whether to use WS-Context at all. (I assume
by-reference is idiosyncratic with respect to WS-CF etc; I
see no proven worth in WS-Context-by-value over plain old
SOAP header elements.)
2) I am specifically raising whether WS-CF should reference
WS-Context,
or whether it should not reference WS-Context. I see no need
for WS-CF to do so, and I believe that doing so causes
unnecessary complexity and implementation effort for WS-CF
and WS-TXM. The relationship is artificial.
I believe that the model of WS-Coordination and its
relationship to
the
coordination protocols in the WS-Transaction family is
correct; that is to say - all that is required. We should
apply Occam's razor here. If in the mists of the pre-history
of WS-CAF and WS-C+T IBM and Microsoft sheared away the
predecessor of WS-Context, then I think they were right to do
so (for the purposes of defining coordination protocols).
In addition, and with reference to the political
concerns you raise
about impeding adoption:
3) I believe that if other standards bodies adopt
WS-Context then
they
are probably not looking hard enough at the value they will
obtain by doing so. The tough job is to define the content,
nature and meaning of context information for a particular
higher-level protocol; not to define a generic wrapper
element to hold all such contexts, nor to define an
interoperable factory interface.
Alastair
PS It is always a good idea, as Peter points out, to justify the
existence of a specification in the specification or
accompanying material.
-----Original Message-----
From: Mark Little [mailto:mark.little@arjuna.com]
Sent: 27 May 2004 11:42
To: Green, Alastair J.; ws-caf
Subject: Re: [ws-caf] Mt Everest and WS-CF
Alastair, I understand why you may want to revisit this, but
obviously
disagree and don't want the TC process to be unduly stalled.
I cannot see what adverse effect going forward with the
specification as it currently stands has on any referencing
specification that decides not to use context by value but
instead chooses context by reference (and vice versa). It
does neither impinges on the readability of the specification
nor on the understandability IMO.
I re-iterate that I believe we have already discussed
this subject
over
the past 2/3 months in teleconferences and face-to-face
meetings. I don't believe that revisiting it will benefit us
or the WS-Context specification at this stage. What it will
do is delay the adoption of WS-Context by other interested
groups and by other referencing specifications (e.g., WS-CF).
I see that as a big disadvantage.
Mark.
----
Mark Little,
Chief Architect, Transactions,
Arjuna Technologies Ltd.
www.arjuna.com
----- Original Message -----
From: Green, Alastair J.
To: Mark Little ; ws-caf
Sent: Thursday, May 27, 2004 11:28 AM
Subject: [ws-caf] Mt Everest and WS-CF
Hi Mark,
You pointed the list at an interesting document by
Savas et al. I
commented upon it, as did Peter upon the interop demo,
because it illustrates a fundamental issue for any potential
user of WS-CAF: what is the worth of WS-Context context-by-value?
The argument for this feature seems to resemble the motivation
for
climbing Mt Everest: "because it's there".
I don't think that this question can be circumvented, and it is
relevant to WS-CF. Should WS-CF have a necessary dependency
on WS-Context? After all, WS-Coordination manages to create a
generic tree-building
(address-exchange) protocol without use of a layer like
WS-Context. I think this is a better model. Then those who
wish to wrap context information in standard wrappers can do
so (use WS-Context), and those who don't wish to do so, don't
need to (ignore WS-Context as adding little real value).
My interest in this is far from academic. If WS-CAF
transaction
or
coordination protocols gain traction at some future date,
then I would like to make our engineers' lives as easy as
possible, by streamlining the work needed to the strictly
necessary (after all, it will only be the third set of
two-phase outcome protocols we have to add to our product, in
order to accommodate the jostling of the software industry
majors). I cannot see how WS-Context contributes to WS-CF or WS-TXM.
Incidentally, I made no mention of context by
reference. I view
this
as an interesting possibility fraught with problems, which I
predict will not be widely used. Every example of WS-Context
use that I see discussed uses "by value". I certainly think
that coordination protocols need by-value contexts (which of
course can be carried in SOAP headers directly).
Alastair
-----Original Message-----
From: Mark Little [mailto:mark.little@arjuna.com]
Sent: 27 May 2004 10:20
To: Green, Alastair J.; ws-caf
Subject: Re: [ws-caf] interesting document
Alastair, is this interesting for a purely academic
standpoint? I
believe that the TC already discussed these issues and voted
on them, so it seems like going back over old stuff to me. To
summarise what this TC already agreed on, since we neither
mandate context-by-value nor context-by-reference in the
base-line context document, it is up to referencing
specifications to determine which format they wish to use. I
think that arguing this again is not going to be fruitful and
I'd like to see this TC move on to the coordination
specification (which was agreed at New Orleans).
Mark.
----
Mark Little,
Chief Architect, Transactions,
Arjuna Technologies Ltd.
www.arjuna.com
----- Original Message -----
From: Green, Alastair J.
To: Mark Little ; ws-caf
Sent: Wednesday, May 26, 2004 6:03 PM
Subject: RE: [ws-caf] interesting document
I have to believe I'm missing something or being
plain stupid,
but
here goes ...
It would be interesting, in light of Peter's recent
mail on the
value of WS-Context context-by-value, to examine what would
change in these scenarios if the <ctx:context/> were to be
replaced by a simple SOAP header element. Strip out
<ctx:context/>, replace the placeholder "context state" with
<protocol:context/>, place this element in the SOAP header,
and proceed. This would be a less restrictive, but I believe
legal, use of WS-I (i.e. move protocol-specific context info
from body to header).
It would also be interesting to consider, in the
light of Jim
and
Guy's exchanges, what role activity completion plays, if any?
Activity completion can only be communicated to context
recipients if they are registered with the context service
that knows that the activity is now complete. WS-Context does
not define such a registration-notification mechanism. This
continues to leave in question the independent value of
WS-Context context-by-value. This type of functionality must
reside in the surrounding protocol (session, coordination
etc) that in my example is denoted by the namespace URI
indicated by the prefix "protocol" (the "referencing
specification"). An example of such a protocol is WS-CF, or
in truncated form, WS-Coordination.
As there is no bundle of contexts specified by
WS-Context (if
my
understanding has kept pace with the spec changes), the
argument that value is provided by easing interception
(simpler to identify the group of contexts that must be
processed by a set of interceptors), becomes a non-argument.
Where does this leave the independent value of WS-Context
context-by-value?
These points are orthogonal to the issue: header
element in the
raw, body element in the raw, or element embedded in an address.
Alastair
-----Original Message-----
From: Mark Little [mailto:mark.little@arjuna.com]
Sent: 26 May 2004 16:45
To: ws-caf
Subject: [ws-caf] interesting document
http://forge.gridforum.org/projects/dais-wg/document/draft-ggf