[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Why WS-Context-Simple? (was: RE: [ws-caf] Agenda for the demo application)
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----- 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]