RE: [ws-caf] proposal towards a resolution for issue 132

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

Alastair and I may as well have this conversation in public - the
presence of a wider community
will probably be helpful  - I'd be interested in how some of this fits
with web-service architecture
thinking in general. Comments interspersed

> -----Original Message-----
> From: Green, Alastair J. 
> Sent: 25 June 2004 17:18
> To: Greg Pavlik
> Cc: Mark Little; ws-caf
> Subject: RE: [ws-caf] proposal towards a resolution for issue 132
> 
> 
> I care less about this subject than the volume of what 
> follows will indicate, but it's Friday afternoon and for once 
> I'm whiling away the time. And I do want to keep the content 
> of WS-Context to an absolute minimum.
>  
> My view is that the proposal should be rejected: vote No to 
> mandatory type specification on the Kavi vote that closes on 4 July.
> 
> I think that you and Peter are expressing a preference, not 
> an unambiguous need. The facility you desire (disambiguate classes of
> context) is a product of concurrent use of > 1 context. This 
> is not true of all uses. 
> 
> It is not a good idea to place the type in the extension or 
> derivation, because it subverts the useful typed behaviour of 
> the factory.

agreed (though not in dispute in this issue)

> If the type should be in the base, but is not always needed, 
> then it should be optional. 

analogy (which may in fact not be implied) with java class derivation
etc.
is not necessarily valid, since the full derivation of a language object
is
always known to the compiler

> * * *
> 
> We cannot know or assume the field of use of this 
> specification. The consuming application may be closed and 
> homogeneous; it may be heavily interpenetrated with other 
> applications and out-of-band protocols. If the former, it can 
> make do with base contexts; if the latter it and its 
> interlocutors can type away to their heart's content (will have to).
> 
> You cannot prevent the application "[attaching] a semantic to 
> the base context without identifiying the application of the 
> semantic". A simple application, which only wants one kind of 
> context, doesn't need to differentiate. 
> 
> What is a mandatory element? How can it be policed? If the 
> only consumer is the referencing 
> application/specification/protocol then how can you know (or 
> care) that it is what you consider to be a valid type 
> specification? Can I make the element empty? If "nothing" is 
> not a valid type spec, what about a single character, like a 
> full stop? The context service accepts and matches the 
> contents against some internal table of known types: it 
> should not care about the value of the known types. So why 
> shouldn't it have a null value factory? 

the type of the type element is a URI, which is the name of the protocol
in use. And a context is not being distinguished just from other
contexts
that might be accepted and processed by the receiver, but also from
others that might be sent (and probably ignored, so they better have
soap:mustUnderstand="false")

> I think Peter is wrong to decry the notion that "the meaning 
> is applied to the untyped context by reference back from the 
> application protocol to which the header has been added. That 
> seems to be contrary to the additive approach of soap headers." 
>
> Let's say I only have one context type. My infrastructure is, 
> for example, a proxy-stub pair, which add and strip contexts. 
> The infrastructure may process the untyped context, and the 
> application is
> (directly) none the wiser. 
> 
> Use of an untyped (type value is null, more correctly) 
> context is not therefore equivalent to "application consumes 
> context". True, the context may be a piece of information 
> that the application never sees or knows (e.g. security 
> context whose interpretation may prevent delivery to the application).
> 
> Contrariwise, the context may in fact be, in whole or in 
> part, a piece of application information, that *does* need to 
> be communicated to the application. Example: a transaction 
> context that emerges on thread-local storage. A correlation 
> id that is used to identify a reply. Etc.
> 
> The issue of type is orthogonal to the issue of who consumes. We don't
> (can't) have to make a rigid distinction between "the 
> application" and "the infrastructure". From the standpoint of 
> WS-Context they can always
> be interchangeable or the same thing.   

I fear you are up against the soap / web-services architecture here. You
may
be right in the sense that this would be a better way, but I'm not
sure that its orthodoxy. Maybe I'm just being too narrow-minded.

But the additiveness isn't necessarily tied to who consumes. A context
with no type element is inferring its semantics from the endpoint - so
one could say the default value is "local". But that sort of shows up
the problem - an implicitly typed context is relying on special 
knowledge and close relationship between client and service.

> (By the way, I think that the "additive" model of SOAP 
> headers is in fact an abuse of XML. XML has the virtue that 
> any element's type can be identified by its 
> namespace-qualified name. We don't need to put elements in 
> wrappers or buckets in order to figure out if they are our
> business.)

putting them in headers allows the semantics to be defined separately,
though some aspects of the application of those semantics will depend
on the application and the content of the body. If headers weren't
there,
they would immediately get re-invented. But in this case, the
namespace identification has been used for the context, so you need
another identification.

Peter



> Alastair
> 
> 
> -----Original Message-----
> From: Greg Pavlik [mailto:greg.pavlik@oracle.com] 
> Sent: 24 June 2004 16:58
> To: Green, Alastair J.
> Cc: Mark Little; ws-caf
> Subject: Re: [ws-caf] proposal towards a resolution for issue 132
> 
> 
> 
> Green, Alastair J. wrote:
> 
> >I disagree with Peter (!) The meaning of a context may be
> circumstantial
> >or implicit.
> > 
> >If all I want out of the base context is a guid, then that is 
> >reasonable. Any other information that allows me to understand the 
> >nature of the referencing specification can be supplied in the base 
> >context, but it could also be incorporated in the extension, 
> or it may 
> >not be necessary at all in a particular application, which 
> "knows" that 
> >a WS-Context is just being used as a handy guid, or (if 
> extended) is of 
> >a singular type.
> >  
> >
> 
> I think it would be a profound error to allow for services to 
> attach a 
> semantic to the base context without identifiying the 
> application of the
> 
> semantic; we would introduce a scenario that allows for ambiguity of 
> meaning in the expressed expectations of service consumer (or it's 
> hosting infrastructure).
> 
> > 
> >If I have only one type of context in my application, why 
> should I be 
> >forced to identify that type, when the knowledge of type can only be 
> >used to differentiate contexts?
> > 
> >
> >Further: the "meaning" of a context may be given by some 
> more complex 
> >deduced type resulting from particular combination of values 
> within the 
> >extended context. I do not think we can mandate a single view or 
> >expression of type.
> > 
> >I do not object to a type field, which I think makes it easy to do a 
> >popular thing (get the context service to yield up contexts of
> different
> >types), but I don't think it should be mandatory. One could 
> also "type"
> >(specialize) the yielded context after the context service 
> manufactures 
> >it, or not type it at all. All are valid approaches.
> > 
> >This does illustrate (in my view) the exiguous nature of the 
> value of 
> >the base context. That should not be concealed by 
> artificially padding 
> >the base context with more content that it must hold on grounds of 
> >universal need.
> > 
> >Alastair
> > 
> >-----Original Message-----
> >From: Mark Little [mailto:mark.little@arjuna.com]
> >Sent: 24 June 2004 12:34
> >To: ws-caf
> >Subject: [ws-caf] proposal towards a resolution for issue 132
> > 
> >http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=132
> > 
> >There was some discussion on this topic in the mailing list 
> and I agree 
> >with Peter (!) The context id is not in and of itself sufficient 
> >information to determine the meaning of a context.
> > 
> >Mark.
> > 
> >----
> >Mark Little,
> >Chief Architect, Transactions,
> >Arjuna Technologies Ltd.
> > 
> >www.arjuna.com
> >
> >  
> >
> 
>