Virtues of ws-context and the ws-caf demo app

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

Title: Message

I've been having a look at the proposed demo application (see Simeon's message to the ws-caf-implementor's list at http://www.oasis-open.org/archives/ws-caf-implement/200404/msg00023.html)

 

It looks realistic in terms of offering functionality that one could imagine being useful. However, it raises again my long-standing doubt over ws-context as a general facility when used in value mode - which is why I'm sending this to the main list.

 

Since I've raised the question before, and I must be seeming a broken record on it, I'll put it as a documentation question

 

Does the specification state what are the advantages of using ws-context by-value over and above using a SOAP header with the same application information. Does it state what considerations would lead a designer to choose to define a use of ws-context instead of defining a soap header.

 

Taking the particulars of the demo app, as an example:

 

It uses the context to hold the items in a shopping cart that can be loaded from multiple stores. To make it work in a mixed manner (with stores using different implementations, for example) there would need to be quite a bit of additional protocol specification, about the inter-store communications, but reasonably enough that isn't there yet.

 

When passed by reference, one can see a WS-Context might be useful - the context identifier is the key to which cart this, and stores use some (to-be-specified) Cart protocol to update the centrally stored context. To do this of course they need an address, available by configuration or passed in the reference form - but the only address one would expect in the reference form would be of the holding Context Service, though presumably that would be the same place as the Cart service (but different URI for different port)

 

But when passed by value, I don't see any virtue in using WS-Context whatever. In this case, the gradually lengthening context is passed in the headers of each addItem request and response. What use is the identifier - the list to be returned on the response is the list on the request with modifications. When it comes to check out, the individual stores might need to know which of their line item promises is being confimed (or whatever). but they don't need the cart identifier either. In fact, why are we passing them the context all the time anyway - the customer can just add things to their own list, and submit it for checkout. Even if we assume some sort of authentication mechanism round the cart (sort of analogous to requiring physical customers to use the provided wire baskets perhaps), this is still just a collection of items and could travel just as well in a soap header in its own right (or indeed in the body, since it is isn't really distinct from the addToCart semantics)

 

The example also shows that the application protocols using context-by-value and context-by-reference are completely different. The implied contract of a store adding an item to the header that is returned to the customer is quite different from adding it to the list that is held on behalf of the stores. The support protocols you need to make each of those complete are also quite different.

 

This is not meant as a criticism of the demo app as such, but just a challenge again to the question:

 

What does context-by-value give you that soap headers don't ?

 

remembering:

    the particular use of WS-Context will have to define a uri that identifies the syntax and semantics of the additional content of WS-Context, including any implied support protocols and any semantic "overload" of the WS-Context fields (the uri is the context-type uri)

    the definition of a SOAP header will have to define a uri that identifies the syntax and semantics of the header, including any implied support protocols (the uri is the namespace uri)

 

If this has been clearly answered, I'm sorry if I've forgotten, but where is it documented.

 

If the answer is "not a lot", then I suggest that context-by-value is treated as a design pattern not a syntax definition.

 

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