(Delayed): [ws-caf] RE: Whoever web services and Webber (was RE: [ws-caf] Mt Everest and WS-CF)

["Furniss, Peter" <Peter.Furniss@choreology.com>]

For some reason (or no reason ?) two of my messages from the earlier
storm don't ever seem to have got into the 
list and I've only just got the rejection messages.  The substance of
the other one has been covered since, I think, but there are some bits
of this that haven't, I think.

Peter

-----Original Message-----
From: Furniss, Peter 
Sent: 31 May 2004 12:14
To: Jim Webber; ws-caf
Subject: RE: [ws-caf] RE: Whoever web services and Webber (was RE:
[ws-caf] Mt Everest and WS-CF)


Jim,

You'll see I put in issues on the semantics of mustPropagate and the
necessity of the type identifier, so the details can be followed under
those threads.

> -----Original Message-----
> From: Jim Webber [mailto:Jim.Webber@newcastle.ac.uk]
> Sent: 31 May 2004 04:01
> To: ws-caf
> Subject: [ws-caf] RE: Whoever web services and Webber (was
> RE: [ws-caf] Mt Everest and WS-CF)
> 
> 
> Peter,
> 
> > I am not quite sure what you mean by correlate - our services are
> > stateless, and the other information in the message as a whole 
> > identifies that you are the sender, which is the only information of

> > concern to us.
> 
> Fine - I didn't presume (or want) to know the details of your 
> implementation.
>  
> > oh. this is rather awkward, as the old version spec didn't actually
> > say what the required behaviour was. Please will have you ensured 
> > clarification to the tc before the spec is finalized.
> 
> That may be a point to bring up as part of the TC effort. Certainly I 
> had a set of semantics associated with it in my head, but if they 
> don't match your assumed semantics then there is clearly a gap in the 
> written spec.
> 
> > > The point here is that I perceive value in the standardisation of
> > > mustPropagate and unique context id since they immediately
> > enable me
> > > to do message correlation in a standard way.
> > 
> > Yes, I agree there is some value, but it all depends on the
> > semantics of mustPropagate, which aren't defined anywhere in draft 
> > 0.2 (at least, "mustPropagate" occurs only in xml, with no 
> > explanation of what it means). So Whoever web services might not be 
> > doing what you hoped. I'll raise an issue on this, as it is a 
> > definable question.
> 
> As long as they propagate the context on messages that they send to me

> which are the result of actions on similarly contextualised messages I

> am happy.

"they send to me" and "result of actions" both make assumptions that
need defining if the behaviour you want them to is to be predictable.
"they send to me" requires a definition of "me" that can be
algorithmically determined by their systems. "result of actions"
requires a model of their processing that is agreed between both sides
- which is probably well defined in practice as part of their service
(it would need to 
use text, bpel or cdl, I expect).

curiously, the most effective definition of what you actually want would
be that "me" above is defined as "an address received on the message I
sent", in which case the function of WS-Address (though possibly not
some of the perceived model
implications)
is exactly what you want : put a header set by you on messages back to
you. WS-Addressing already makes exactly the demands on the receiver of
the endpoint-reference (= sender TO the
endpoint) that you need. You don't have to use it in a way that offends
you.

> > On the question of the type identification, I think you are
> > suggesting it can be omitted - I don't see how that can work.
> 
> I am indeed saying that a plain vanilla context is useful.
> 
> > It is optional in the schema; my understanding of this is that it is
> > optional because it might be absent in by-reference, though actually

> > I think that's wrong too. If it were to be omitted:
> > 
> > Suppose Whoever agreed with your interpretation, but wanted to
> > define their own activity that had independent boundaries to yours. 
> > So on a message sent back to you there are two contexts, containing 
> > identical elements apart from the value of the context-identifier. 
> > So do you correlate this both ways ?
> 
> No not necessarily - their work is not part of my activity, why would 
> they send me a context to a piece of work that I know nothing about?

That's exactly the point. They want you to propagate their context on
messages back to them resulting from the actions on they are sending to
you. Of course you know nothing about what else is involved in their
activity, or indeed what their 
"activity" means to them - it might be some kind of session dealing with
many customers - but their perception is that "vanilla context" does the
job of allowing correlation at their end of work arising from a single
event. The relationship is symmetric.

>                       Plus wouldn't the identifiers for those 
> activities be different?

yes, unless you both chanced to use the same independent ContextService.
If they are easily distinguished, you could in practice discriminate by
whether you recognised the identifier, but that's rather ugly. Three
party interactions (you -> whoever -> another -> you) need to be
considered. And you might use the same ContextService, making the
identifiers indistinguishable.

> Can we therefore boil this down to an issue: that the semantics of 
> mustPropagate are not sufficiently defined in the spec?

That would change the present situation, that vanilla context has no
shared meaningful semantics, 
so it might be. I don't see your use-case working well in general
without your type uri on it 
though - if the only behaviour you wanted from the other side was to
propagate back to you, and that were well defined, you could set an
arbitrary context type (in
http://jim.webber.name/...) and spot
your own contexts coming back very easily. (You could do the same thing
with ws-address of course)


Peter

> Jim
> --
> http://jim.webber.name
>