Re: [ws-caf] Context query

[Kevin Conner <Kevin.Conner@arjuna.com>]

Furniss, Peter wrote:
> I believe it was one of the original intentions, and it sounds a very
> nice idea but it turns out not to be so easy to fit into a
> service-oriented world as it first seems. (there was some earlier
> discussion
> on the list, I think)

I did have a look but couldn't find it, I'll go back and search again.

> In general, how can it be determined whether it is appropriate to
> pass on the context - which might be to do with security, charging,
> transactions or whatever.

I had assumed that any implementation of context would also include the ability to restrict the propagation of the context for precisely the reasons you state.  I believe that both implicit and explicit propagation will have similar requirements whether this decision is based on the context type, endpoint address, application semantics or other criteria.  

The question is really about whether we should be excluding an opaque and generic handling of the context element as this appears to be the only use case not covered by the requirement to specify a derived context type/element.  The change means that each context must be explicitly identified as such before any decision regarding propagation can be made.

> Of course, there is nothing to stop an implementation "partly"
> understanding a context, such that it
> knows to propagate it appropriately, but that's all. So a service could
> choose, for example, to 
> propagate a transaction context, but not itself registering any
> participants. Or it might recognise
> only that this was a company-internal security token, and send it on
> (without doing any checking itself) to all services marked (by
> configuration) as internal but not to outsiders.

This still hangs on the original question of identifying the context element as a context.  You couldn't write an implementation that allowed the propagation of all contexts to internal endpoints without first identifying the headers as such.

	Kev

-- 
Kevin Conner
Arjuna Technologies Ltd.