Jim,
I think you corner one of the
issues being discussed very nicely. But I am not sure your answer to the issue
is correct.
Your applications (chains of XML
processors) do have to be "aware of every possible type of context that they
might encounter". Have to be,
in order to be able to usefully work (on security, on transactional control,
on sessional data etc etc). There is no way round that “right royal pain”. It’s
an irreducible part of the overall problem, and WS-Context doesn’t make it go
away.
Here (reduced to its essentials)
is one key benefit currently being described for what I think of as
“WS-Context-Simple” (no ALS):
<SOAP-ENV:Header>
<wsctx:Context>
...
</myprot:MyContext>
</wsctx:Context>
</SOAP-ENV:Header>
versus
<SOAP-ENV:Header>
</myprot:MyContext>
</SOAP-ENV:Header>
So, as Mark points out in his
thread with Peter, it comes down to the
following:
Do I like to look first for the
SOAP header, then for the contexts bucket, then for a context wrapper, and
then for the specific context (i.e. I have a context processing "stream", even
though it will have to despatch off to security, and transactions, and
replication [if we actually have multiple concurrent
contexts])?
Or am I happy to look first for
the SOAP header, and then for the specific context element(s)? I.e. I have a
SOAP Header processing “stream” which dispatches off to security etc etc.
The answer to this question
derives either from taste, or from objective considerations. On grounds of
taste, I don’t like the syntactic salt that these extra wrappers put in the
way.
The only objective consideration
being raised here is speed/convenience. It's faster/easier to track the
contexts if I know where to find them. (Similar argument to SOAP headers:
better to get the header stuff processed early, because it might vitiate
processing the body).
In my view, there's a limit to the
amount of header information I am typically going to have. It seems like a
very fine foundation upon which to erect an edifice of standardization.
I have to have a security context
processor anyway, I have to have a transaction context processor anyway, each
of them is capable of parsing the Header, so why have
a context processor get in the way by handing off one part of the header to
the security context processor and the transaction context
processor?
* * *
I do believe there is real value
in the idea of passing-by-reference. I accept that the social fact of SOAP and
WSDL means that the RESTful notion of operating on a
naked URI is via the HTTP verbs is not a viable approach.
However, I wonder whether we would
be better off creating a standard called WS-REST, which defined inserting,
amending, reading and deleting any old document, at any old
endpoint?
The absence of such a simple
general facility doesn’t seem to me to justify creating an interoperable
standard called WS-Context[-Simple], which is
overloaded or narrowed by its association with the idea of “context”.
* * *
My final point is: there is more
to say, because there is also something I think of as WS-Context-Advanced,
which brings in ALS registration etc. I would like to address this in
subsequent posts.
Alastair
-----Original
Message-----
From: Jim Webber [mailto:Jim.Webber@newcastle.ac.uk]
Sent: 13 February
2004 03:35
To: Furniss, Peter;
ws-caf@lists.oasis-open.org
Subject: RE: [ws-caf] Agenda for the demo
application
Peter:
The WS-GAF proposal used WS-Context because it enables
us to link
together services in an ad-hoc way withouth having to
resort to ad-hoc
methods to do it. Sure we use SOAP headers (that's
what the spec tells
us), but our services are all aware of the format of
WS-Context
contexts, whereas it would be a right royal pain if we
had to make them
aware of every possible type of context that they
might encounter.
Perhaps therefore it is the demo application which
should be altered?
There is little value in showcasing WS-Context for a
single service,
since WS-RF is already optimised for that use case
;-)
Any thoughts Malik?
Jim