I agree with Peter (!) that the type field can't
really be optional if there are different ways in which the context ID by itself
can be interpreted. Now are we saying that apart from "correlation of
invocations" the base context ID can be used for other things? I'm not sure. I'd
be happy to make the type field mandatory just in case we are hamstringing
ourselves though (and to move on!)
Arjuna Technologies Ltd.
----- Original Message -----
Sent: Monday, May 31, 2004 4:35 PM
Subject: RE: [ws-caf-editors] [Fwd:
[ws-caf] Whoever web services and Webber (was RE: [ws-caf] Mt Everest and
wonder whether this is an omission related to the context type ID/context
instance ID issue? Meaning that I think we actually need two IDs, one
for the type and the other for an instance of the type. Would that help
clear this up?
is the type meant to be optional? Or is this
simply a mistake?
-------- Original Message --------
changing the subject to distinguish the thread
> -----Original Message-----
> From: Jim Webber [mailto:Jim.Webber@newcastle.ac.uk]
> Sent: 30 May 2004 03:36
> To: ws-caf
> Subject: RE: [ws-caf] Mt Everest and WS-CF
> > I see from our server logs that you have been using our aestivation
> > and quadration web services, in accordance with our agreements and
> > the published interface definitions.
> > As you are obviously aware, our services support WS-Context, and I
> > see that you include a WS-Context header in the SOAP messages you
> > send us. These headers have ctx:context-type URI of
> > http://jim.webber.name/conjoint123. We are quite happy to accept
> > SOAP messages with this context, but we are not sure what effect you
> > intend this to have, since we do not have any information about what
> > processing is required for
> > http://jim.webber.name/conjoint123. Our services are highly
> > configurable and extensible, so I'm sure we will be able to
> > enhance our services to support your needs, but we do need to
> > know what we are supposed to do with the context. Do you just
> > wish us to record the activity identifier in our service logs
> > ? Do you want your itemised bill to include the identifier ?
> > Should our systems be invoking operations on the context
> > service identified in the context ? Or are your expectations
> > of our behaviour covered entirely by the mustUnderstand and
> > mustPropagate flags.
> > I gather that some assert that placing a WS-Contet value indicates
> > that the operation invocations are part of the activity identified
> > in the context. This is may be very nice, but our services make no
> > use of this indication, and can make no use of it without some
> > further definition of their expected behaviour.
> What a highly original and amusing way to make a point. I propose this
> be known as the Furniss Gambit in all future TCs :-)
glad you like it. It's a sort of use case :-)
> Anyway in the spirit that it was sent, I will answer:
reverting to the persona of customer services of Whoever Web Services:
> Dear Service Provider,
> I have no idea what you will do with the contexts that I send you,
> perhaps like me you will use them to correlate messages that happen in
> the same activity (a distributed session). I will leave that for you
> to decide.
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.
> However since you correctly implement the mustPropagate parts of the
> specification I do not require anything further from you.
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.
> Yours faithfully,
> Dr. J. Webber
> PS - the context type that I am using is not the one you identify, it
> is in the namespace
we have examined the old versions of the spec, and we cannot find a
value for the type uri in it. The context itself is in that namespace,
but we were referring to the value for the type (aka protocol-type,
ALS-configuration-identifier) that distinguishes what the context is
being used for.
Customer services manager
> PPS - I am using an old version of the 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.
On the question of the type identification, I think you are suggesting
it can be omitted - I don't see how that can work. 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 ?
> I therefore would take the side of preserving WS-Context as being
> useful in its own right.