RE: [ws-caf] Context query

["Newcomer, Eric" <Eric.Newcomer@iona.com>]

Yes, I think it's still a good idea to support opaque context passing
through intermediaries.  

Thanks,

Eric

-----Original Message-----
From: Kevin Conner [mailto:Kevin.Conner@arjuna.com] 
Sent: Monday, June 06, 2005 7:39 AM
To: Furniss, Peter
Cc: WS-CAF
Subject: Re: [ws-caf] Context query

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.