RE: [ws-caf] three forms of context (was RE: [ws-caf] [Bug 135] New: participating-services list needs to have defined semantics and modification mechanisms or be removed)

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

I think there are others in the tc who hold this view even more strongly
than I do, though
I'm sure they can speak for themselves.

True, if you require all the options of all compliant implementations,
there is theoretcially no
risk to interoperability - it's a form of "receiver-makes-right". The
disadvantages
then are that you increase implementation effort, and far more, increase
testing. 

Requiring all options for compliance also causes problems with
implementations that 
implement a base protocol (like ws-ctx) only
in support of a particular higher protocol, or set of related protocols
which restricts
(profiles) the options. If ws-xyz requires the by-reference,
context-manager form (for
reasons that make good sense for the purposes of xyz), is an
implementation of xyz that
only uses ws-ctx context-manager, and doesn't support the http behaviour
compliant with
ws-context ?  (this is a conceptual rather than practical problem, but
I've spent too
much time arguing with angels-on-pinheads conformance testers to give
them space if
I can help it)

What is a practical problem is that any particular implementation is
likely to usually
(or perhaps invariably) choose one of the options - perhaps encouraged
by an API default
- and is of course most commonly used (or at least tested) with Context
Service and 
web service "interceptor" from the same source. So that form gets
thoroughly tested, and
the other form less so. Then, in the field it meets another
implementation that made the 
opposite choice and some incompatibilities turn up.

You can, supposedly, get round these problems by making everyone really
implement everything, 
even if they never use it and imposing a rigorous conformance testing
regime. This makes
the products more expensive, larger and much later than they need be.
(It was another
part of the downside of OSI - and the fact that some OSI conformance
people, right at the end
started to work on "cost-effective conformance testing" says a lot about
what had gone before).

I don't go as far as some, who claim that any spec that needs, or can
be, profiled wasn't 
done right in the first place. But they're not far off. (It's really an
editorial style
question - is it better to have the common base in one document, with
alternative derivations
in other documents, or have a single document with options.  But in
either case, be very 
careful the common base is worth distinguishing).

If, instead, you keep the alternatives as options, so each
implementation can choose its own
thing, you obviously have interoperation problems - though this is just
the obvious,
hard-and-fast extreme of the practical problems that turn up.

Peter

> -----Original Message-----
> From: Mark Little [mailto:Mark.Little@arjuna.com] 
> Sent: 27 June 2004 19:16
> To: Furniss, Peter; ws-caf@lists.oasis-open.org
> Subject: RE: [ws-caf] three forms of context (was RE: 
> [ws-caf] [Bug 135] New: participating-services list needs to 
> have defined semantics and modification mechanisms or be removed)
> 
> 
> Peter, I agree that we need to discuss this. In that light, 
> can you expand on 
> why you think having multiple protocols inhibits 
> interoperability? Ignore the 
> mandated versus optional argument at the moment, and let's 
> assume all are 
> mandated to be a compliant implementation (we can relax 
> restrictions later).
> 
> Mark.
> 
> >===== Original Message From "Furniss, Peter" 
> ><Peter.Furniss@choreology.com>
> =====
> >In considering the slightly-RESTful participating-services facility 
> >(see other message) I realised we have now got three 
> different forms of
> >context:
> >	propagated by value
> >	propagated by reference, dereferenced by ContextManager 
> getContents
> >	propagated by reference, dereferenced by http get
> >
> >As the p-s discussion I think shows, those have distinctly different 
> >implications of implementations. Particularly for the last two, is a 
> >ws-context implementation required to handle both ? Do we 
> actually want 
> >all this "flexibility" - it looks nice, but in fact it inhibits 
> >interoperablity and makes it more difficult to get things to work 
> >together. You can't just mix-and-match, because they won't match.
> >
> >Of course, a referencing specification can nail things down 
> (as in the 
> >p-s facility), but then it becomes doubtful how much ref specs that 
> >choose different options are actually benefitting from the "common" 
> >base. We don't want ws-context to end up like OSI Session, which was 
> >pretty much two different protocols munged together in the same 
> >document, but with different app protocols choosing different 
> >"functional units" to get back to the session protocol they were 
> >actually using. No-one benefitted from that - implementors, users, 
> >other standardisers (not even the techno-politicians who had 
> insisted 
> >on it originally, as far as I know)
> >
> >A common base assists implementation if the implementor of a higher 
> >spec can use the implementation of the lower. But if the 
> lower is full 
> >of options that doesn't actually help - its quicker to implement the 
> >specific as part of the higher than make an all-possibilities lower 
> >first and choose from it.
> >
> >On the specific, I think we should drop one of the two dereferencing 
> >mechanisms. I could put this in as an issue, but lets chase 
> it round a 
> >bit first.
> >
> >Peter
> 
> 
>