On Tue, Feb 22, 2011 at 9:03 AM, Simon Nash <n...@apache.org> wrote:
> Gang Yang wrote:
>>
>> --- Cut ---
>>>
>>> How about plugging your code into an Axis2 handler instead of a Tuscany
>>> handler? Is there is a way to get control after Axis2 has built the
>>> SOAPFault and before the fault is sent on the wire?
>>>
>>> Simon
>>>
>>
>> Our security software has been integrated with Axis2 and other WS
>> frameworks such as JAX-WS and JAX-RPC. The problem here is that we are
>> supposed to integrate with Tuscany. Axis2 is just a ws binding provider and
>> it's hidden behind Tuscany:-). In an earlier quick effort, I have modified
>> tuscany-sca-all-1.6.jar to add Axis2 handlers in a hard-coded way. But
>> that's not a good solution and it's not flexiable.
>>
>>
> Why do the Axis2 handlers need to be part of the Tuscany jar? Is this
> a classloader issue? Perhaps there is a way to customize Tuscany's use
> of classloaders to allow Axis2 handlers to be loaded from outside the
> Tuscany jar. For example, it's possible to set up Tuscany 1.x to run with
> a different version of Axis2 from that included with the tuscany-sca-all
> jar, as described in [1] (please read the whole thread).
>
> Simon
>
> [1] http://www.mail-archive.com/user@tuscany.apache.org/msg02597.html
>
>
Trying to catch up....
I think there is a question here of how generic the security code is.
If it's common code that is intended to encrypt messages regardless of
what binding is used then it needs to be independent of the binding.
It it does depend on the type of binding then things are different.
For WS Security support in 1.x we chose to use the Rampart module of
Axis so our security policies in that area just provide configuration
to the Rampart module. Hence we allow the guts of Axis to do whatever
it needs to do and just provide the appropriate configuration.
This case of providing a bespoke policy that has to run in the context
of a binding is, as we are finding here, tricky because in 1.x we
started out with an infrastructure model that treated the binding as a
black box. The policy handlers beforeInvoke/afterInvoke were a first
attempt to resolve it but we added then in a very binding specific
way. I.e. where they appear and get called is binding dependent.
We backed away from this approach for the JMS and HTTP bindings in 1.x
and created the binding chain [1]. We went this route to support
features, such as wireFormat and operationSelection, that the OASIS
specifications introduced. What it does is introduce the familiar
handler infrastructure into the guts of the binding implementation so
opening up the black box and making it more pluggable. So, for
example, on the reference side you might find that a binding does the
following
Set up the binding context -> some arbitrary handlers (policy,
wireFormat etc) -> transport processing
And on the service side the reverse is true.
transport processing -> some arbitrary handlers (policy, wireFormat
etc) -> Operation selection
In 2.x the JMS and HTTP binding came over from 1.x pretty much as is
and we started converting the ws-axis binding to this pattern. The new
PolicyProvider interface has extra methods [2] which still support
policy interceptors being created for the normal operation chain but
adds the ability to create interceptors for the binding chain and also
allows the provider the opportunity to configure a binding directly if
required.
Another thing we started looking at in 2.x was alternative
implementations of binding.ws. In particular we started looking at
what it would take to build the binding on top of JAXWS. We have a
simple JDK/RI based version running but didn't get the Axis/JAXWS
version running. We redirected our effort to getting the existing
binding-ws-axis2 binding to being compliant with the OASIS specs. If
someone were to finish off the JAXWS support then in theory you could
add JAXWS interceptors directly the ws binding
None of this information is directly helping solve Yang's immediate
problem but I want to make sure issues raised on this thread are
resolved in 2.x. I suspect that some of these issues are still
relevant.
Re. the question of calling afterInvoke() in fault cases. Would there
be problem with letting the infrastructure continue to do the fault
processing but give afterInvoke() a chance to process any faults
created, for example, in Axis2ServiceInOutSyncMessageReceiver ..
} catch (InvocationTargetException e) {
Throwable t = e.getCause();
if (t instanceof FaultException &&
((FaultException)t).getFaultInfo() instanceof OMElement) {
OMElement faultDetail =
(OMElement)((FaultException)t).getFaultInfo();
inMC.setProperty(Constants.FAULT_NAME,
faultDetail.getQName().getLocalPart());
AxisFault f = new AxisFault(null, e.getMessage(),
"faultNode", "faultRole", faultDetail);
*** throw f;
}
if (t instanceof Exception) {
*** throw AxisFault.makeFault((Exception)t);
}
logger.log(Level.SEVERE, e.getMessage(), t);
*** throw new ServiceRuntimeException(e);
} catch (Throwable e) {
logger.log(Level.SEVERE, e.getMessage(), e);
*** throw AxisFault.makeFault(e);
}
give afterInvoke the chance to process here ***. A similar thing could
be done in the invoke() operation of Axis2BindingInvoker. What
processing are you expecting to do on the fault? If you're intending
to encrypt the fault response then this isn't going to work on the
service side as the operation is expecting to throw and exception in
the fault case.
[1]
https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Request+Response+Binding
[2]
http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/core-spi/src/main/java/org/apache/tuscany/sca/provider/PolicyProvider.java
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
