Re: [ws-caf] Context header advantage WAS Agenda for the demo application

["Mark Little" <mark.little@arjuna.com>]

> I certainly hope that we have not reached an impasse on these important
> requests for clarification so soon!
>
> I take Peter F. to be challenging the WS-CAF TC to create a short
> "elevator pitch" for a technical audience.
>
> The advantage that Mark L. proposes is:
>
> >From a purely syntactic perspective, I'd like to have my SOAP documents
> with a well defined context element that's the same whether it's
> conveying transaction, security or session-oriented data.
>
> Peter F., however, says SOAP headers already provide adequate
> syntactical distinctness. Said another way,
> what advantage is gained by having syntactically marking headers for
> contexts to set them apart from all the other SOAP headers? I am
> sympathetic to that question because I had hoped the TC would bound the
> context header's intended area of applicability so that implementers (or
> spec writers) can clearly tell when using a context header would be an
> advantage and when the information should go into its own header. I
> assume this group does not to put
> every SOAP header module into a context header; that would violate the
> semantic principle that distinctions must embody a "non vacuous
> contrast."

Dale, I'd say the answer to your question above is: absolutely not. We're
not intending to make the SOAP header simply a block that starts
<wsctx:blah> and ends with </wsctx:blah>. I've always assumed that the
information within the context section of the header is most definitely a
subset of the information within the SOAP header. As I've said before, at
present there are things conveyed in a SOAP header that we might not
consider to be contextualisation of the associated message. I thought we'd
agreed on a definition of context that would be sufficient to allow us to
say "yes, that's context information" or "nope, that isn't context
information", and from that determine whether it should go in the normal
SOAP header, or within a context block in the header. Maybe that definition
isn't as precise as you'd like?

> Less loftily, I had presumed a tacit SOAP header processing model (maybe
> a little beyond anything explicitly in the SOAP XMLP explicit
> specification) in which the general SOAP message processor would check
> to see if it had a SOAP-context-header handler and shove off what needs
> to be done to that task module. OK, what does that module need to know
> to do its job? So far I get the feeling that all it does is hand off to
> a yet more specialized context handler for security context, transaction
> context, session context, etc. The question of real interop is then
> deferred from  whether we have the same SOAP header handler to whether
> we have the same capabilities in subhandlers of the context header. If
> all the specialized subhandlers reuse functionality present in the base
> class soap context handler, so far it does not seem that very much gets
> reused. (GET on URI?)

Possibly not, but does that negate the requirement for something that
clearly defines what is context information and what is not? If you're
heading towards a question of: maybe we don't need a separate namespace for
context, but still stick with the notion of composite services augmenting
the SOAP header, then perhaps we should discuss the pros and cons of that.

> I am trying to be antagonistic here. I am simply trying to see what
> general computational advantages attach to the context header proposal
> so that I might explain it to a software architectural-design team.
> Otherwise it is just another syntactial something or other to worry
> about.

I understand.

Thanks,

Mark.

----
Mark Little,
Chief Architect, Transactions,
Arjuna Technologies Ltd.

www.arjuna.com


>
>
>
> -----Original Message-----
> From: Mark Little [mailto:mark.little@arjuna.com]
> Sent: Friday, February 13, 2004 5:24 AM
> To: Furniss, Peter; ws-caf@lists.oasis-open.org
> Subject: Re: [ws-caf] Agenda for the demo application
>
>
> Peter, I think we're about to start going round in circles here. What
> your example does show is one of the benefits of WS-Context: the fact
> that because context is standardised (I'm assuming it is), all users of
> it (end-users, other specifications, whatever), have a well defined way
> to scope (namespace) their contexts into their messages. Currently some
> context information in apps. goes in the body of a message, which makes
> it more difficult (slower) to locate.
>
> Fairly obviously the users of ServiceContexts (e.g., the OTS) had to do
> some work to use them, but the fact that they came along facilitated
> interoperability for contexts. SOAP headers don't just contain context
> information at the moment, and as I said above, don't even have to
> contain context information. Addressing that is part of what we're
> looking at. And then there's the composite nature of the context
> augmentation that I mentioned previously.
>
> But like I said at the start, I think we're not going to agree on this
> (again). As Eric pointed out, of course you can do context today with
> what's around, and what we're trying to do in WS-Context isn't
> necessarily rocket science or re-inventing the wheel; it's agreeing on a
> standard format for contexts that can be used by all specifications and
> applications. From a purely syntactic perspective, I'd like to have my
> SOAP documents with a well defined context element that's the same
> whether it's conveying transaction, security or session-oriented data.
>
> Mark.
>
> ----
> Mark Little,
> Chief Architect, Transactions,
> Arjuna Technologies Ltd.
>
> www.arjuna.com
>
> ----- Original Message -----
> From: Furniss, Peter
> To: Mark Little ; ws-caf@lists.oasis-open.org
> Sent: Friday, February 13, 2004 12:12 PM
> Subject: RE: [ws-caf] Agenda for the demo application
>
>
>
>
> Ok, maybe I have misunderstood. Let's try a little example (related to
> one of the example scenarios), of what looks like a light-weight
> context-using requirement and show what I meant about wrapping:
>
> Users initiate web-service using tasks that may involve indeterminate
> numbers of systems. To help with error tracking etc, each system is to
> be told the users identity and some task-identification chosen by them
> (or their initiating software). It's a benign environment and
> masquerading won't benefit the attacker, so its just an assertion
> Supporting systems can put this information in access and error logs,
> printers could include it on a banner page etc. Sort of thing that might
> be useful in academic computer services.
>
> So the fields we need are, say,  username, a string; an identifier for
> the task (could be string or uri); and  to allow username assignment to
> be unambiguous and decentralised, identification of the naming authority
> - a URI, given by the institution, company or isp. (There are various
> other ways you could partition the information here)
>
> But, to allow a receiver of this information to know what it supposed to
> be, we need to have an identifier to say what it is - some unambiguous
> value assigned by whoever defined this use -(a fictitious entity called
> Webservices Things, who call this their "User Labelling" facility)
>
> Now, if WS Things has bought into WS-Context, that last identification
> is the "type", the task identifier will be the "context-identifier" and
> username and authority-identifier will be additional elements, and
> messages that are to be user-labelled will be like this:
>
> <soap:Envelope xmlns:soap="http://www.w3.org/2002/12/soapenvelope";>
> <soap:Header>
>  <ctx:Context
> xmlns:ctx="http://www.webservicestransactions.org/schemas/wsctx/2003/03";
> >
>
> <ctx:context-identifier>http://pluto.ulcc.ac.uk/task/EJ4439kjsf9/prf</ct
> x:context-identifier>
>   <ul:Label
> xmlns:ul="http://webservicethings.org/util/userlabelling/2004/02";>
>    <ul:user>cziwprf</ul:user>
>    <ul:authority>http://ulcc.ac.uk</ul:authority>
>   </ul:Label>
>  </ctx:Context>
>  ... other headers ...
> </soap:Header>
> <soap:Body>
>  ... message body ...
> </soap:Body>
> </soap:Envelope>
>
> (using my identity from when I was in that world :-)
>
> Whereas if Webservices Things had decided not to go with WS-Context, the
> user-labelled soap messages would be like
>
> <soap:Envelope xmlns:soap="http://www.w3.org/2002/12/soapenvelope";>
> <soap:Header>
>  <ul:Label
> xmlns:ul="http://webservicethings.org/util/userlabelling/2004/02";>
>
> <ul:task-identifier>http://pluto.ulcc.ac.uk/task/EJ4439kjsf9/prf</ul:tas
> k-identifier>
>       <ul:user>cziwprf</ul:user>
>       <ul:authority>http://ulcc.ac.uk</ul:authority>
>   </ul:Label>
>  ... other headers ...
> </soap:Header>
> <soap:Body>
>  ... message body ...
> </soap:Body>
> </soap:Envelope>
>
> The thing is, not only is that exactly the same information, but WS
> Things specification in the first case is no simpler or shorter.
>
> You seem to be saying in "is the format of that element and how it can
> be located in the header" that it is harder to locate the information in
> the second case. But it's already in the header, and identified by the
> top-element of the header and its namespace. It isn't scattered at some
> random point in the message as a whole, because soap headers define
> where to look.
>
>
>
> Touching the IIOP ServiceContext comparison - ServiceContext alone
> didn't make for interoperable transactions (say)- there also needed to
> be the work of the OTS group to specify what went in a transaction
> context. Their deliberations on how to transmit that context were
> simplified because they could just say "its a Service Context" - if
> they'ed done it earlier, they'ed have had to invent something of their
> own.  But with the SOAP world, we started off with SOAP Headers (perhaps
> in the knowledge of what was needed for IIOP) and there isn't a need for
> another layer of the same.
>
> The only virtue for WS-Context is if the other things it brings are
> useful for many cases, and I've not seen evidence of that - those extra
> features nearly all seem to be specific to particular uses.
>
> Peter
>
>
> -----Original Message-----
> From: Mark Little [mailto:mark.little@arjuna.com]
> Sent: 13 February 2004 10:41
> To: Furniss, Peter; ws-caf@lists.oasis-open.org
> Subject: Re: [ws-caf] Agenda for the demo application
>
>
>
>
> CORBA ServiceContext corresponds more or less exactly to SOAP Header -
> it is an opportunity to information to the main data message to support
> a supporting or adjunct protocol. The particular adjunct protocol in
> question is identified by a value of the ServiceContext or Header that
> is unambiguous among the set of possible adjuncts - one of the neat
> things about the XML world is that registration is devolved, so unlike
> CORBA, there is no need for a central registry of header
> identifications.
> There is no difference between a propagated IIOP CORBA ServiceContext
> that contains security and transaction information, from a propagated
> XML WS-Context that contains security and transaction elements. The
> point I was originally making was that prior to ServiceContext, you had
> companies like Visigenic, Iona, IBM, HP, Nortel etc. propagating context
> information in a proprietary manner and format simply because they had
> no choice. Then ServiceContext came along and made interoperability a
> possibility because it standardised that format and manner. As Eric has
> pointed out already, that's pretty much what we're trying to do.
> But I don't think there were suggestions of a hyper-service-context in
> CORBA - a wrapper ServiceContext whose real meaning was determined by
> the contained information. Each context travelled naked. (In fact, given
> the registration requirement, a wrapper conceivably could have been
> useful in CORBA allowing devolved registration, but that isn't needed
> with SOAP and XML).
> Maybe you've got a slight misunderstanding of what the WS-Context will
> look like, or maybe I just can't see what your wrapper is all about. If
> we consider pass-by-value for the context, then there'll be a context
> element in the header for each context type (security, transactions,
> replication, etc.) What we're defining is the format of that element and
> how it can be located in the header. Seems like the same as locating the
> ServiceContext in IIOP.
>
> Once you've got the basic means of passing identified information, the
> real fun is in the specification of the the adjunct protocol of course,
> but that wouldn't be WS-Context but it's user - or a SOAP Header user,
> or in the old world, a ServiceContext user, with its own interfaces and
> methods, using the information received in the header/servicecontext.
>
> WS-CF and WS-TXM fall into this category, I'd presume.
>
> Mark.
>
> ----
> Mark Little,
> Chief Architect, Transactions,
> Arjuna Technologies Ltd.
>
> www.arjuna.com
>
>
> Peter
> -----Original Message-----
> From: Mark Little [mailto:mark.little@arjuna.com]
> Sent: 12 February 2004 16:37
> To: Furniss, Peter; ws-caf@lists.oasis-open.org
> Subject: Re: [ws-caf] Agenda for the demo application
>
>
> Peter, interesting discussion, but I think it comes down to utility,
> ease of use and extensibility. If you look at CORBA for example, you
> could probably make the same arguments for why ServiceContext shouldn't
> have been added to the architecture and why existing schemes at that
> time (vendor/specification specific) were fine. Only time will tell, of
> course, but I believe that context is a basic requirement for all
> distributed systems and WS-Context is definining a pretty good model for
> Web services on which to build.
>
> Mark.
>
> ----
> Mark Little,
> Chief Architect, Transactions,
> Arjuna Technologies Ltd.
>
> www.arjuna.com
>
> ----- Original Message -----
> From: Furniss, Peter
> To: Mark Little ; malik saheb ; ws-caf@lists.oasis-open.org
> Sent: Thursday, February 12, 2004 3:26 PM
> Subject: RE: [ws-caf] Agenda for the demo application
>
>
> Mark,
>
> I've had a look and I still don't see a clear added-value of WS-Context
> itself, or statement of what is deficient in using headers directly.
> There are assertions, as in your first paragraph that WS-Context could
> be used for various things, but I don't see what features it adds that
> aren't there already or which have to be specified in some other
> document known to the various parties.
>
>
> The problem is that the additional specification (it is not necessarily
> an ALS, it may just be specification - the GAF proposal is an example of
> the sort of thing) has to define the interpretation and purpose of the
> attributes and elements in the context. You could write virtually the
> same specification text saying "this value is put in a SOAP header with
> top-element qname" instead of "this value is put in a context with type
> uri".
>
> That would certainly seem to be the case for pass-by-bulk.
> Pass-by-reference, once it's sorted out, comes down to the
> general-purpose semantics of "here is a soap header with an element that
> is a URI that can be dereferenced to give you more information."
> Everything else is left to the addtional specification.
>
> Undoubtedly the various specs that have context-like behaviour *could*
> function with WS-Context, but I don't see what they would gain other
> than "namespace paint" .
>
>
> Peter
>
> -----Original Message-----
> From: Mark Little [mailto:mark.little@arjuna.com]
> Sent: 12 February 2004 14:16
> To: Furniss, Peter; malik saheb; ws-caf@lists.oasis-open.org
> Subject: Re: [ws-caf] Agenda for the demo application
>
>
> Peter, I think you missed the point. I realise you weren't at the first
> face-to-face, (and I've no idea if you'll be at the next one where I'm
> sure the demo app will be described), but this kind of discussion came
> up in Boston. It was also one of the original FAQ questions (can't say
> for sure if it's on the current TC FAQ though). One of the intentions of
> WS-Context is to try to provide a standard way of approaching context,
> rather than the ad hoc mechanisms that currently exist. For example, it
> would be great if WS-Security adopted WS-Context, for example; though
> whether that actually happens is a different issue entirely. WS-RF as
> another example may be able to utilise WS-Context.
>
> An aim would be to provide a standard that allows existing and new uses
> of context to be more easily created and to work collectively. I find it
> strange to be going back over what the aims of this TC is, since we're
> 4+ (?) months into it, but: we'll define a standard context
> representation that all users will agree upon and can augment if
> required; the location of context will also be precisely defined such
> that it is no longer a hit-and-miss thing to be able to identify
> pertinent "context" information in a header or body. I don't think this
> is a waste of time and effort, and just looking outside of this TC
> neither do the various companies that we have talked to.
>
> And with regard to my comments on the demo. application: as I said, I
> can see how context could be used in the way currently described, I just
> think that an alternative approach may well be easier to describe and
> understand.
>
> Oh, and WS-Context can be used entirely by itself, i.e., without any
> ALS-es. It was designed to. Check out
> http://www.arjuna.com/library/reports/2003-08-12-GAF-v1_0.pdf for
> example.
>
> All the best,
>
> Mark.
>
> P.S. If we're going to discuss the demo. specifically then let's take it
> to the separate working group.
>
> ----
> Mark Little,
> Chief Architect, Transactions,
> Arjuna Technologies Ltd.
>
> www.arjuna.com
>
> ----- Original Message -----
> From: Furniss, Peter
> To: Mark Little ; malik saheb ; ws-caf@lists.oasis-open.org
> Sent: Thursday, February 12, 2004 1:46 PM
> Subject: RE: [ws-caf] Agenda for the demo application
>
>
> WS-CAFites,
>
> The proposed demo application, and Mark's comments on it are very
> interesting as showing two different approaches by the author companies
> (who are to be congratulated on having such discussions in the open,
> rather than huddling away in a corner :-). But they raise a query I've
> had in my mind about WS-Context.
>
> By design WS-Context can't be used completely alone - there has to be
> some additional specification known to the various parties - so in the
> demo application, the client and the retailers all know of the shopping
> cart application. Exactly what behaviour is required of them differs
> slightly between the demo as written and Mark's suggestions - but the
> client has at least to know that it has to put the context on the
> messages to the retailers, and the retailers to know they must make
> their supplying part of the cart.
>
> The problem I have is that I can't quite work out what WS-Context adds
> that isn't already available in SOAP headers. The WS-Context-using
> shopping cart specification will be identified by a URI (the "type" in
> the context -this is probably the same as, or related to, the
> ALS-context identifier). A service receiving a context with that uri (or
> finding it after dereferencing a pass-by-reference context) will thus
> know what it has to do, as specified by the shopping cart spec: but
> that's all part of the shopping cart spec, and not WS-Context
> (especially if, as Mark suggests the shopping cart ALS offers its own
> service, with addToCart, removeFromCart).
>
> Compare that with exactly the same shopping cart service specified using
> SOAP header, and able to generate a unique shopping cart identifier. The
> shopping cart specification defines a soap header, using the namespace
> uri to identify it's headers among all the other that exist. The header
> includes the URI of the shopping cart service and any other identifiers
> - in fact exactly the same information that it would need to specify as
> being contained in the context had it used WS-Context. A service
> receiving a shopping cart header does exactly the same things as one
> receiving a shopping cart context.
>
> The demo app as described does have the Context Service doing more, but
> that seems to be what can be done with http anyway - the context
> identification URI labels a resource that can be fetched (get) or
> changed (put) (but no equivalent of post at ctx level).
>
> The shopping-cart service is using the Context-service to generate the
> unique identifier, but that isn't difficult to do itself (and might well
> be counter-productive to take one in from the Ctx service, since if the
> shopping cart chose its own URI's it could put locally-meaningful (but
> externally opaque) information in them, whereas if the URI is given to
> it by a Context Service the cart service must indirect through a hash or
> whatever.)
>
> To summarise:
>
> What gain does a WS-Context-using specification gain from WS-Context
> that it could not have got from the combination of:
>
>     - SOAP Headers, which identify, by the namespace URI which
> specification they refer to and can contain elements and attributes of
> use to that specification
>
>     - HTTP Get, Put and Post which can fetch, set and modify a
> remotely-held body of information unambiguously identified by a URI
>
> Good grief, I've turned into a RESTafarian !
>
>
> This isn't to say there might not be something in the higher levels of
> WS-CAF (I have thoughts on that too :-), but I have a suspicion that by
> the time you've generalised the context-layer sufficiently to make it
> general (i.e. to justify ws-context as a separate spec), there isn't
> anything left worth specifying. Yes, several things need to pass around
> identifications, and associated information and there are some protocol
> design issues that are worthy of summarising (e.g. rules about
> unambiguity must be precise, implications of id exchange) but there
> isn't anything worth making into a distinct protocol.
>
> Peter
>
> ------------------------------------------
> Peter Furniss
> Chief Scientist, Choreology Ltd
> web: http://www.choreology.com
> email: peter.furniss@choreology.com
> phone: +44 870 739 0066
> mobile: +44 7951 536168
>
>
> -----Original Message-----
> From: Mark Little [mailto:mark.little@arjuna.com]
> Sent: 11 February 2004 11:53
> To: malik saheb; ws-caf@lists.oasis-open.org
> Subject: Re: [ws-caf] Agenda for the demo application
>
>
> I've attached comments to the document. As far as I can see, this still
> needs work. The architecture of the application seems to be a very
> strange use of context in general, and WS-Context specifically. Maybe
> this is a carry-over from the WS-I demo?
>
> Mark.
>
> ----
> Mark Little,
> Chief Architect, Transactions,
> Arjuna Technologies Ltd.
>
> www.arjuna.com
>
> ----- Original Message -----
> From: malik saheb
> To: ws-caf@lists.oasis-open.org
> Sent: Monday, February 09, 2004 7:00 PM
> Subject: [ws-caf] Agenda for the demo application
>
>
> Hi All
>
> I have attached the document explaining how the demo application can use
> the WS-Context.
> The way the demo will use the other specifications will be provided
> later according to the schedule described below and that follow the
> following steps.
>
> - Before a meeting we will produce a document describing the demo
> application using a particular specification (deadline 1 week before the
> meeting)
> - During a meeting the document made previously available will be
> discussed
> - Show a demo application with a particular specification (no demo for
> the Paris meeting)
>
> In other words:
> 2nd meeting - Paris
> - Before the meeting - we provide the demo application with the WS-CTX.
> - During the meeting - Discuss the demo application with WS-CTX
>
> 3rd meeting New Orleans
> - Before the meeting - produce a document of the demo application with
> WS-CF
> - Discuss of the application with WS-CF
> - Show the Demo Application with the WS-Context (described in the
> previous meeting)
>
> 4th F2F meeting (date to be determined) -
> - Before the meeting - produce a document of the demo application with
> WS-TXM
> - Discuss of the application with WS-TXM
> - Show the Demo Application with the WS-CF (described in the previous
> meeting)
>
> 5th F2F meeting (date to be determined) -
> - Show the Demo Application with the WS-TXM (described in the previous
> meeting)
>
> Malik
>
>