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)

[Mark Little <Mark.Little@arjuna.com>]

I think that if we took the view that all possible interaction means are 
mandated, then it's an implementation and QA issue on the part of the 
implementors to get right. There is nothing in the specification that we can 
or should do to assist in this, and that's not a "problem" with WS-Context; 
it's something that is true with any specification/standard. At some point you 
have to assume that people can read and understand the implications of a given 
specification and if they decide to implement it, they implement it correctly. 
A non-compliant, buggy implementation is an issue for the vendor and not the 
specification authors.

But your point is well taken in that are we defining too many patterns and if 
so, which one(s) should we drop? If we're not, which one(s) should be 
mandatory and which one(s) should be optional?

Unfortunately I don't think we can continue this thread until the related 
thread on participating services has progressed a little.

Mark.

>===== Original Message From "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
>>
>>
>>