Let me try that again with formatting and with 2.x comments....
As previously discussed the 2,x binding specific interceptor model
is different from the 1.x model. Policy processing can intercept the
message flow in two places
Generically on the operation specific wire
In a binding specific way on the binding wire
The binding specific processing is free to (re-)configure the binding
as appropriate. For example it can add Axis handlers. Back to the
issues. This time with 2.x comments attached.
TUSCANY-3822 - Service side afterInvoker should be called with the
outbound Axis MC
Gang has correct the call to afterInvoke. Demonstrated in two
attachments to JIRA. There is some discussion of what the sequence
of calls should be for different MEPs, for example,
in-only: beforeInvoke(inMC) / afterInvoke(inMC)
in-out: beforeInvoke(inMC) / afterInvoke(outMC)
out-only: beforeInvoke(outMC)
Gang's summary comment
======================
1. PolicyHandler.afterInvoke() needs to be called with the
outbound MessageContext instead of the inbound MC.
This is critical for WS-security. I have provided my fixes
in the JIRA. With some generalization we discussed,
I think this should be fixable in 1.6.x
2.x comments
===========
Binding interceptors have access to the binding context
which in the reference side is OperationClient which
holds "out" and "in" MessageContext. On the service
side it's the "in" MessageContext from which I believe you
can get the "out" MessageContext. We need to look whether
this asymmetry is necessary
TUSCANY-3838 - Reference side afterInvoke is skipped when AxisFault occurs
Gang has corrected the call to afterInvoke in a patch attached to the JIRA
Sub categories of this issue
1. On the service side, any business exceptions from the implementation
cause afterInvoke() to be skipped. Tuscany creates an AxisFault
wrapping the business exception, and throws this back to Axis2
for it to generate the on-the-wire fault.
2. On the service side, any system exceptions from the implementation
(e.g., ServiceRuntimeException) or from beforeInvoke() cause
afterInvoke() to be skipped. Tuscany creates an AxisFault by calling
AxisFault.makeFault() and throws this back to Axis2 for it to
generate the on-the-wire fault.
3. On the reference side, any AxisFault (either created by Axis2 or
created by Tuscany on the service side because of cases 1 or 2)
causes afterInvoke() to be skipped.
Gang's summary comment
======================
4. PolicyHandler.afterInvoke is not called when Fault is
generated. So far, I have no workaround on this and would
like a fix. If I remember the code correctly, a quick fix is possible if
Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic()
can catch the exception, create the Fault body and call
PolicyHandler.afterInvoke() on the service side. I'm not sure how
the client (requester) side works, but the PolicyHandler.afterInvoke()
is also skipped on the return with the Fault.
2.x comments
===========
We're going to have to think through this one. We instigated a
pattern for the async work that we can potentially exploit. I'll
add faults to the test.
TUSCANY-???? - Default dispatching mechanism in Axis depends on
looking at the wrapper element name
Gang added @WebMethod to the interfaces to drive the generation
of SOAPAction which Axis will use to select the service operation
The alternative is to use MessageContext.setSoapAction() in the
interceptor that does the encryption
Gang's summary comment
======================
2. SOAP message encryption is not supported because the
PolicyHandler.beforeInvoke() is called after Axis2 dispatching
phase, which needs to analize SOAP body in order to determine
the endpoint method. This can be worked around by defining
SOAPaction in WSDL or Java interface using @WebMethod.
However, a future fix is still nice to have.
2.x comments
===========
I need to run some experiments on this but it looks like the
TuscanyDispatcher in 2.x is coded to dispatch off the URL. I don't
know under what circumstances this is used and whether we
support other dispatching mechanisms
TUSCANY-???? - We need to be able to pass context "through" a
component implementation so, for example, the security context
established when a service is called is available to references
of that service.
(1) service binding.ws ->
(2) handlers ->
(3) component implementation ->
(4) handlers ->
(6) reference binding.ws
Lots of discussion see, for example,
http://www.mail-archive.com/[email protected]/msg15581.html
Gang's summary comment
======================
3. A state-sharing mechanism is needed to allow sharing states
among service side interceptors/handlers, component and
reference side interceptors/handlers. I'm currently using the
ThreadLocal as a workaround, which I wish to have your blessing
- for now, it's only used from the service handler to component
and then to reference handler and I hope you can confirm that
the same thread is used for processing. However, we all agreed
that this is not desirable to use ThreadLocal in the service
framework and a state-sharing mechanism is needed.
2.x comments
===========
The problem remains. We need to bring all the ideas together
into a proposal
TUSCANY-???? - Where should interceptors be looking for message
information. Axis MC, Tuscany Message or both and should
the interceptor be fixing up the relationship between the two when
encrypting/decrypting
2.x comments
===========
In 2.x he binding chain is binding specific so has the opportunity
to do whatever it needs to do with both structures. We would expect
the writier of one of these interceptors to understand both Axis and
Tuscany internals.
Gang, you offered to send in you 2.0 policy prototype code a one stage
in the various conversations. Could you do this bay attaching it to a
new JIRA?
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
