|
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
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 -----
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
|