OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-caf] Context query


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)

The complication is who to propagate it to. Say client A sends a context
to service B, and
service B, as part of its processing then contacts services C, D and E.
E is in fact part of
A's organisation and A sent the original message in precisely to get B
to interact with E,
and wants the context to turn up there. But A has no knowledge of C and
D, whose involvement
is a private matter for B. 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.

If the rule is made that an unknown context (or one with some
mustPropagate flag) is sent
to everything, then it will have to be sent on with
soap:mustUnderstand=false, as it may
be sent to systems that don't know of context at all. But then they will
of course stop the
propagation anyway (since they will just ignore the context completely).

One could have some more complex arrangement, by which the context is
identified as being "for"
some category of services, but then there has to be some way of a
service declaring which
categories it is in.

This could all be made to work, I'm sure, but it probably needs to be
deep in the basic
infrastructure of SOAP and WSDL. It doesn't seem to be easy to add it as
a "composable" layer with 
full generality.

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.
(one of the complications of mustUnderstand is writing the rules so that
sort of behaviour is covered - I'm not sure they are)

Peter

> -----Original Message-----
> From: Kevin Conner [mailto:Kevin.Conner@arjuna.com] 
> Sent: 06 June 2005 09:52
> To: WS-CAF
> Subject: [ws-caf] Context query
> 
> 
> I have a query about a change that was made to the context 
> specification, it came to me last week while I was on holiday 
> (sad I know).
> 
> I had assumed that one of the original intentions behind 
> context was that the context could be passed around without 
> intermediates having any knowledge of the contents (by 
> intermediates in this case I mean applications, not routing). 
>  If this is the case then I believe it is no longer true.
> 
> A recent change to context removed the wsctx:context element 
> in favour of a derived type and element, specified in a 
> referencing specification. This came about in response to a 
> discussion held earlier regarding soap:mustUnderstand and 
> context types.  One major effect of this change is that it is 
> no longer possible to identify a context element, and 
> therefore propagate it opaquely, unless the referencing 
> specification is known to the intermediate application.
> 
> Should it be possible to propagate a context opaquely?
> 
> Thanks,
> 	Kev
> 
> -- 
> Kevin Conner
> Arjuna Technologies Ltd.
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]