You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2011/02/25 12:10:13 UTC
2.x Policy interceptors - was: Re: PolicyHandler exception handling
issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
Following up on Gang's thread about policy handling in 1.x and getting
the right effect when trying to apply security policy with the Web
Services binding I'm looking at how policy is applied in 2.x. I've
created a test case [1] which has three components with the same
implementation:
<component name="HelloworldComponent1">
<implementation.java class="sample.HelloworldImpl"/>
<reference name="hwRef"
target="HelloworldComponent2"
requires="tuscany:interaction.bindingws"
policySets="tuscany:InteractionBindingWS"/>
<property name="componentName" value="HelloworldComponent1"/>
</component>
<component name="HelloworldComponent2">
<implementation.java class="sample.HelloworldImpl"/>
<service name="Helloworld"
requires="tuscany:interaction.bindingws"
policySets="tuscany:InteractionBindingWS">
<binding.ws/>
</service>
<reference name="hwRef" target="HelloworldComponent3"/>
<property name="componentName" value="HelloworldComponent2"/>
</component>
<component name="HelloworldComponent3">
<implementation.java class="sample.HelloworldImpl"/>
<property name="componentName" value="HelloworldComponent3"/>
</component>
I've added three components so I can look at the context propagation
issue across the central component but for now I'm looking at how
policy interceptors are applied in relation to the WS binding used
between HelloworldComponent1 and HelloworldComponent2. To facilitate
this you can see that I've added an interaction policy that has parts
with are specific to binding ws. It's intended to demonstrate adding
A generic policy interceptor in the Tuscany operation chain
A binding specific policy interceptor in the Tuscany binding chain
An Axis handler added by the policy
This test policy isn't configurable and the providers are hard coded
to add the appropriate handlers [2] [3]. The result is the following
sequence for the forward an response message passing between the two
components.
TestPolicyInterceptor.processRequest()
HelloworldComponent1#reference-binding(hwRef/Helloworld) @
reference.policy
TestPolicyInterceptor.processRequest()
HelloworldComponent1#reference-binding(hwRef/Helloworld) @
reference.binding.policy
TestAxisHandler.invoke() Reference OutFlow Handler
TestAxisHandler.invoke() Service InFlow Handler
TestPolicyInterceptor.processRequest()
HelloworldComponent2#service-binding(Helloworld/Helloworld) @
service.binding.policy
TestPolicyInterceptor.processRequest()
HelloworldComponent2#service-binding(Helloworld/Helloworld) @
service.policy
TestPolicyInterceptor.processResponse()
HelloworldComponent2#service-binding(Helloworld/Helloworld) @
service.policy
TestPolicyInterceptor.processResponse()
HelloworldComponent2#service-binding(Helloworld/Helloworld) @
service.binding.policy
TestAxisHandler.invoke() Service OutFlow Handler
TestAxisHandler.invoke() Reference InFlow Handler
TestPolicyInterceptor.processResponse()
HelloworldComponent1#reference-binding(hwRef/Helloworld) @
reference.binding.policy
TestPolicyInterceptor.processResponse()
HelloworldComponent1#reference-binding(hwRef/Helloworld) @
reference.policy
Which looks OK on the face of it but looking in detail I find that the
service side binding interceptor is happening outside the context of
the Axis binding. So I'm going to look at fixing that first. Then I'll
look at each of the issues that Gang raised and see if/how this
infrastructure provides a solution.
[1] http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/testing/itest/interceptors/
[2] http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/testing/itest/interceptors/src/main/java/sample/InteractionBindingWSReferencePolicyProvider.java
[3] http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/testing/itest/interceptors/src/main/java/sample/InteractionBindingWSServicePolicyProvider.java
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
RE: 2.x Policy interceptors - was: Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
Posted by "Yang, Gang CTR US USA" <ga...@us.army.mil>.
Classification: UNCLASSIFIED
Caveats: NONE
>
> 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
Simon,
I created some JIRAs to capture the problems we have discussed (but not
yet have JIRAs) and problems I verified after some more prototyping
effort with 2.0-Beta2. I attached the policy extension prototype to the
issue, TUSCANY-3852, to demonstrate the problems. It also contains the
code that tries to access Axis2's configuration context. Hope this help.
Gang
Classification: UNCLASSIFIED
Caveats: NONE
RE: 2.x Policy interceptors - was: Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
Posted by "Yang, Gang CTR US USA" <ga...@us.army.mil>.
Classification: UNCLASSIFIED
Caveats: NONE
>
> Yep, the policy providers get the opportunity to see binding specific
> configuration. You have to know what binding you're dealing with of
> course and in the ws/axis case it's an Axis2BaseBindingProvider object
> that the policy provider sees. Once you have that you can get at the
> Axis ConfigurationContext and you're off to the races. See
>
> http://svn.apache.org/repos/asf/tuscany/sca-java-
>
2.x/trunk/unreleased/testing/itest/interceptors/src/main/java/sample/In
> teractionBindingWSServicePolicyProvider.java
>
> We may need to work on that interface a bit but you get the idea,
>
> Other policies need to do other things with the configuration such as
> turning on MTOM but without access to the whole context it's difficult
> to predict what a policy might need to do.
>
Hi, Simon,
I followed your pointer to access Axis2's configuration context. I was
able to get the configuration context on the service side, but the
configuration context on the client side is null. I'm not sure if it's
the service vs reference that made the difference or the launch
mechanism that made the difference. My testing configuration is a WAR
deployed into Jboss with policy extension applied to service and a
command line client (jar) with policy extension applied to reference.
Gang
Classification: UNCLASSIFIED
Caveats: NONE
RE: 2.x Policy interceptors - was: Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
Posted by "Yang, Gang CTR US USA" <ga...@us.army.mil>.
Classification: UNCLASSIFIED
Caveats: NONE
--- cut ---
>
> Yep, the policy providers get the opportunity to see binding specific
> configuration. You have to know what binding you're dealing with of
> course and in the ws/axis case it's an Axis2BaseBindingProvider object
> that the policy provider sees. Once you have that you can get at the
> Axis ConfigurationContext and you're off to the races. See
>
> http://svn.apache.org/repos/asf/tuscany/sca-java-
>
2.x/trunk/unreleased/testing/itest/interceptors/src/main/java/sample/In
> teractionBindingWSServicePolicyProvider.java
>
> We may need to work on that interface a bit but you get the idea,
>
> Other policies need to do other things with the configuration such as
> turning on MTOM but without access to the whole context it's difficult
> to predict what a policy might need to do.
Thanks. On the high level, I kind of understand path you are pointing
to. But I need to take a closer look or get my hands dirty to really
understand how Axis2 handles its configuration.
One comment: I guess the strategy Tuscany uses is that I, as Tuscany
core, will do least abstractions but will make everything available and
you, as extension developers, will need to figure out how to work with
what you need:-). It's smart and maybe necessary to implement SCA type
of framework. It just seems to be a lot of (potentially repeated) work
for the policy extension developers to figure out how a specific
provider does things w/o abstraction. There could be multiple different
providers for an extension point.
--- cut---
>
> OK, interesting, this would be a generic alternative to getting in and
> manipulating the Axis configuration directly (in the Axis case). I
> still come back to thinking isn't this what JAXWS is supposed to do
> but maybe I need to give it some more thought.
>
I think it all boils down to who does what. I was hoping that with the
help of Tuscany core, Axis2 WS binding provider would abstracts some
common concepts, such as handlers, and implement them once and used by
many. Compare this to the approach that each policy extension that needs
to use Axis2 WS binding provider's handler needs to understand how Axis2
does it and repeatedly implements it in their code repeatedly.
I agree that conforming to standards, such as JAX-WS, is a good
strategy. Then Axis2 WS binding provider code needs to change? Note that
this only matters to the extension developers, not component developers,
because only extension developers need to access the internals.
Gang
Classification: UNCLASSIFIED
Caveats: NONE
Re: 2.x Policy interceptors - was: Re: PolicyHandler exception
handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is
generated (UNCLASSIFIED)
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Mar 2, 2011 at 3:54 PM, Yang, Gang CTR US USA
<ga...@us.army.mil> wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> --- Cut ---
>>
>> Absolutely and we can already create Axis handlers from our policy
>> providers if required. Although these are of course specific to Axis.
>
> Really? Are you saying that I, as a policy extension developer, can
> write my own Axis2 handlers and tell Tuscany via policy extension
> artifacts to add them to the Axis2 framework in the Axis2 WS binding
> provider? Can you provide a pointer to how this can be done? I guess I
> did not know this when I was prototyping policy extension in 2.0-Beta.
Yep, the policy providers get the opportunity to see binding specific
configuration. You have to know what binding you're dealing with of
course and in the ws/axis case it's an Axis2BaseBindingProvider object
that the policy provider sees. Once you have that you can get at the
Axis ConfigurationContext and you're off to the races. See
http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/unreleased/testing/itest/interceptors/src/main/java/sample/InteractionBindingWSServicePolicyProvider.java
We may need to work on that interface a bit but you get the idea,
Other policies need to do other things with the configuration such as
turning on MTOM but without access to the whole context it's difficult
to predict what a policy might need to do.
>
>> >
>> > Another more sophisticated approach, which could potentially hide
> the
>> > underlying framework, could be to map the Tuscany's interceptors to
>> the
>> > underlying binding provider's handlers as I mentioned earlier. On
> the
>> > high level, this could involve the following:
>> >
>> > - A WS binding SPI that would allow Tuscany to inquire about the
>> > underlying provider type so Tuscany knows what type of handlers to
>> > create, say Axis2 or JAX-WS.
>> >
>> > - A WS binding SPI that would allow Tuscany to register a handler
>> with
>> > the underlying provider's framework.
>> >
>> > - When the policy extension definition is processed that requires
>> > insertion of logic into the binding provider's invocation chain,
>> Tuscany
>> > creates a corresponding underlying framework handler, which wraps
> the
>> > extension's interceptor, and registers it with the underlying
>> framework.
>> >
>> > - This underlying framework handler is created such that when called
>> by
>> > the underlying framework, it will call the extension's interceptor
>> > invoke() method with the underlying framework's message context
>> wrapped
>> > in Tuscany's generic message context for the extension's interceptor
>> to
>> > access.
>> >
>> > - Similar extension SPI/API should be provided so that the extension
>> > developer can determine the type of the underlying framework,
>> retrieve
>> > the corresponding message context and process accordingly.
>> >
>> > Hust some thoughts in a hope to help.
>>
>> Glad to have the suggestions Gang! I'm thinking that looking back to
>> our JAXWS base binding.ws may be the motivation for this kind of
>> thing. I wonder whether we, Tuscany, should define yet another SPI for
>> creating interceptors in the guts of the protocol implementation or
>> whether we should rely on some existing and relatively accepted like
>> JAXWS. What concerns we with trying to provide our own abstraction is
>> that inside the handler we're going to have to manipulate the message
>> and the context that surrounds it. Trying to wrap that would be a lot
>> of work. JAXWS has already done that. If you look at the JAXWS
>> extension that Axis provides you can get the JAXWS message context but
>> you can't get the underlying Axis context from the JAXWS context.
>> Hence they are abstracting you away from how Axis physically process
>> the JAXWS message under the convers.
>>
>
> I agree the way I described was not desirable/feasible because Tuscany
> has to be aware of each new provider type and has to add code to do the
> wrapping and abstraction for each individually. To avoid this, we can
> push the wrapping and abstraction to the WS binding provider side since
> the provider knows their implementation as well as Tuscany's SPI. To do
> this, a WS binding SPI, addHandler(Interceptor), can be added take a
> Tuscany Interceptor, wrap it in the provider's native handler and add
> the handler.
>
> The reason I mentioned these approach is to generalize the mechanism for
> all WS binding providers. This is possible because all parties involved
> here has a common base, which is the SOAP. Maybe there's other better
> ways to do this, which can move the abstraction closer toward SOAP.
OK, interesting, this would be a generic alternative to getting in and
manipulating the Axis configuration directly (in the Axis case). I
still come back to thinking isn't this what JAXWS is supposed to do
but maybe I need to give it some more thought.
>
> Gang
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
RE: 2.x Policy interceptors - was: Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
Posted by "Yang, Gang CTR US USA" <ga...@us.army.mil>.
Classification: UNCLASSIFIED
Caveats: NONE
--- Cut ---
>
> Absolutely and we can already create Axis handlers from our policy
> providers if required. Although these are of course specific to Axis.
Really? Are you saying that I, as a policy extension developer, can
write my own Axis2 handlers and tell Tuscany via policy extension
artifacts to add them to the Axis2 framework in the Axis2 WS binding
provider? Can you provide a pointer to how this can be done? I guess I
did not know this when I was prototyping policy extension in 2.0-Beta.
> >
> > Another more sophisticated approach, which could potentially hide
the
> > underlying framework, could be to map the Tuscany's interceptors to
> the
> > underlying binding provider's handlers as I mentioned earlier. On
the
> > high level, this could involve the following:
> >
> > - A WS binding SPI that would allow Tuscany to inquire about the
> > underlying provider type so Tuscany knows what type of handlers to
> > create, say Axis2 or JAX-WS.
> >
> > - A WS binding SPI that would allow Tuscany to register a handler
> with
> > the underlying provider's framework.
> >
> > - When the policy extension definition is processed that requires
> > insertion of logic into the binding provider's invocation chain,
> Tuscany
> > creates a corresponding underlying framework handler, which wraps
the
> > extension's interceptor, and registers it with the underlying
> framework.
> >
> > - This underlying framework handler is created such that when called
> by
> > the underlying framework, it will call the extension's interceptor
> > invoke() method with the underlying framework's message context
> wrapped
> > in Tuscany's generic message context for the extension's interceptor
> to
> > access.
> >
> > - Similar extension SPI/API should be provided so that the extension
> > developer can determine the type of the underlying framework,
> retrieve
> > the corresponding message context and process accordingly.
> >
> > Hust some thoughts in a hope to help.
>
> Glad to have the suggestions Gang! I'm thinking that looking back to
> our JAXWS base binding.ws may be the motivation for this kind of
> thing. I wonder whether we, Tuscany, should define yet another SPI for
> creating interceptors in the guts of the protocol implementation or
> whether we should rely on some existing and relatively accepted like
> JAXWS. What concerns we with trying to provide our own abstraction is
> that inside the handler we're going to have to manipulate the message
> and the context that surrounds it. Trying to wrap that would be a lot
> of work. JAXWS has already done that. If you look at the JAXWS
> extension that Axis provides you can get the JAXWS message context but
> you can't get the underlying Axis context from the JAXWS context.
> Hence they are abstracting you away from how Axis physically process
> the JAXWS message under the convers.
>
I agree the way I described was not desirable/feasible because Tuscany
has to be aware of each new provider type and has to add code to do the
wrapping and abstraction for each individually. To avoid this, we can
push the wrapping and abstraction to the WS binding provider side since
the provider knows their implementation as well as Tuscany's SPI. To do
this, a WS binding SPI, addHandler(Interceptor), can be added take a
Tuscany Interceptor, wrap it in the provider's native handler and add
the handler.
The reason I mentioned these approach is to generalize the mechanism for
all WS binding providers. This is possible because all parties involved
here has a common base, which is the SOAP. Maybe there's other better
ways to do this, which can move the abstraction closer toward SOAP.
Gang
Classification: UNCLASSIFIED
Caveats: NONE
Re: 2.x Policy interceptors - was: Re: PolicyHandler exception
handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is
generated (UNCLASSIFIED)
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Mar 1, 2011 at 4:51 PM, Yang, Gang CTR US USA
<ga...@us.army.mil> wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> The picture is worth thousands of words. Thanks, Simon. It really helps
> understanding the architecture and thinking process.
>
> I think the basic approach of treating Axis2 or other (JAX-WS, JAX-RPC
> etc.) binding provider module as a building block is a normal practice.
> The issue is that some special capabilities extensions needs to get in
> the middle of that building block. Luckily most, if not all, WS
> frameworks do provide a mechanism to allow access to their operation
> context and insertion of logic into their invocation chain - Axis,
> Axis2, JAX-WS and JAX-RPC all provide handlers and CXF provides
> interceptor.
Absolutely and we can already create Axis handlers from our policy
providers if required. Although these are of course specific to Axis.
>
> A simple approach can be to provide a Tuscany API to take an underlying
> provider's handler/interceptor written by the extension developer and
> register it with the underlying framework. But it does not hide the
> underlying provider's implementation from the extension developer.
+1 and I think this is our default position at the moment. Still means
we need to improve the way interceptors are positioned and the way
that we share context but it will basically work now.
>
> Another more sophisticated approach, which could potentially hide the
> underlying framework, could be to map the Tuscany's interceptors to the
> underlying binding provider's handlers as I mentioned earlier. On the
> high level, this could involve the following:
>
> - A WS binding SPI that would allow Tuscany to inquire about the
> underlying provider type so Tuscany knows what type of handlers to
> create, say Axis2 or JAX-WS.
>
> - A WS binding SPI that would allow Tuscany to register a handler with
> the underlying provider's framework.
>
> - When the policy extension definition is processed that requires
> insertion of logic into the binding provider's invocation chain, Tuscany
> creates a corresponding underlying framework handler, which wraps the
> extension's interceptor, and registers it with the underlying framework.
>
> - This underlying framework handler is created such that when called by
> the underlying framework, it will call the extension's interceptor
> invoke() method with the underlying framework's message context wrapped
> in Tuscany's generic message context for the extension's interceptor to
> access.
>
> - Similar extension SPI/API should be provided so that the extension
> developer can determine the type of the underlying framework, retrieve
> the corresponding message context and process accordingly.
>
> Hust some thoughts in a hope to help.
Glad to have the suggestions Gang! I'm thinking that looking back to
our JAXWS base binding.ws may be the motivation for this kind of
thing. I wonder whether we, Tuscany, should define yet another SPI for
creating interceptors in the guts of the protocol implementation or
whether we should rely on some existing and relatively accepted like
JAXWS. What concerns we with trying to provide our own abstraction is
that inside the handler we're going to have to manipulate the message
and the context that surrounds it. Trying to wrap that would be a lot
of work. JAXWS has already done that. If you look at the JAXWS
extension that Axis provides you can get the JAXWS message context but
you can't get the underlying Axis context from the JAXWS context.
Hence they are abstracting you away from how Axis physically process
the JAXWS message under the convers.
>
> Gang
>
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
RE: 2.x Policy interceptors - was: Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
Posted by "Yang, Gang CTR US USA" <ga...@us.army.mil>.
Classification: UNCLASSIFIED
Caveats: NONE
The picture is worth thousands of words. Thanks, Simon. It really helps
understanding the architecture and thinking process.
I think the basic approach of treating Axis2 or other (JAX-WS, JAX-RPC
etc.) binding provider module as a building block is a normal practice.
The issue is that some special capabilities extensions needs to get in
the middle of that building block. Luckily most, if not all, WS
frameworks do provide a mechanism to allow access to their operation
context and insertion of logic into their invocation chain - Axis,
Axis2, JAX-WS and JAX-RPC all provide handlers and CXF provides
interceptor.
A simple approach can be to provide a Tuscany API to take an underlying
provider's handler/interceptor written by the extension developer and
register it with the underlying framework. But it does not hide the
underlying provider's implementation from the extension developer.
Another more sophisticated approach, which could potentially hide the
underlying framework, could be to map the Tuscany's interceptors to the
underlying binding provider's handlers as I mentioned earlier. On the
high level, this could involve the following:
- A WS binding SPI that would allow Tuscany to inquire about the
underlying provider type so Tuscany knows what type of handlers to
create, say Axis2 or JAX-WS.
- A WS binding SPI that would allow Tuscany to register a handler with
the underlying provider's framework.
- When the policy extension definition is processed that requires
insertion of logic into the binding provider's invocation chain, Tuscany
creates a corresponding underlying framework handler, which wraps the
extension's interceptor, and registers it with the underlying framework.
- This underlying framework handler is created such that when called by
the underlying framework, it will call the extension's interceptor
invoke() method with the underlying framework's message context wrapped
in Tuscany's generic message context for the extension's interceptor to
access.
- Similar extension SPI/API should be provided so that the extension
developer can determine the type of the underlying framework, retrieve
the corresponding message context and process accordingly.
Hust some thoughts in a hope to help.
Gang
> -----Original Message-----
> From: Simon Laws [mailto:simonslaws@googlemail.com]
> Sent: Tuesday, March 01, 2011 5:17 AM
> To: dev@tuscany.apache.org
> Subject: Re: 2.x Policy interceptors - was: Re: PolicyHandler
exception
> handling issue - PolicyHandler.afterInvoke() is not called when
> SOAPFault is generated (UNCLASSIFIED)
>
> I put a diagram of my understanding of the current 2.x
> binding.ws/policy interceptor situation here [1] along with some
> comments relating to the issues we've been discussing (the first four
> numbered comments relate to Gang's numbered comments). Some of these
> issues are I think resolvable given the approach to Axis integration
> we have at the moment. Some of them are more problematic though.
>
> Our basic approach currently is that we do all of our processing
> outside of the Axis handlers. Our approach to WS-Security is to
> engaged Rampart (this is enabled in 1.x but not yet in 2,x) rather
> than to write it ourselves The requirement to process the SOAP message
> very close to the transport when doing bespoke encryption is the
> tricky part. To allow it all to happen in the binding wire using
> policy interceptors we'd have to be much more careful about where SOAP
> envelopes are created and read and where the operation selection is
> performed. There is a danger of re-inventing Axis.
>
> I think a sensible approach to making progress is to improve the
> things we should improve regardless of the bespoke encryption
> requirement. For example, 5/ consistency of binding context, 1/
> access to appropriate message contexts, 2/ context sharing mechanism.
> The fallback for bespoke encryption is to create Axis handlers. In
> parallel I'd like to look at how we integrate with Axis, for example,
> we could look back at the JAXWS integration approach so at least any
> handlers that are build are in some way following a standard pattern.
>
> [1]
>
https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Policy+Implemen
> tation
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Classification: UNCLASSIFIED
Caveats: NONE
RE: 2.x Policy interceptors - was: Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
Posted by "Yang, Gang CTR US USA" <ga...@us.army.mil>.
Classification: UNCLASSIFIED
Caveats: NONE
Sorry, I meant the second issue, issue number 2, regarding the policy
interceptor being called twice. Here's the original post about the
second issue.
2. On the service side, my policy interceptor was called twice, once by
RuntimeInvoker.invokeBinding() and once by
DataTransformationInterceptor.invoke(). The latter baffled me because my
policy.getPhase() returns service.binding.policy.
Gang
> -----Original Message-----
> From: Yang, Gang CTR US USA [mailto:gang.yang@us.army.mil]
> Sent: Thursday, March 24, 2011 5:10 PM
> To: dev@tuscany.apache.org
> Subject: RE: 2.x Policy interceptors - was: Re: PolicyHandler
exception
> handling issue - PolicyHandler.afterInvoke() is not called when
> SOAPFault is generated (UNCLASSIFIED)
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> >
> > 1. <binding.ws requires="intent"> did not work for me. In the
> debugger,
> > the composite builder did recognize the new policy and the fact that
> > the
> > reference/service has required intent, but matching check failed.
> > However, <binding.ws policySets="policyset"> worked.
>
>
> Never mind about the first issue. I had both
> createInterceptor(Operation) and createBindingInterceptor() defined so
> on the service side, both are activated for service.policy and
> service.binding.policy phases.
>
> However, the same policy extension is used on the reference side and
> the
> policy interceptor is called only once. I remember I had problems with
> activating the policy interceptor on the reference side (before I
> played
> with service side) if I only define createInterceptor(Operation). So I
> defined both to get reference side working. Now with both defined, it
> is
> called twice on service side. A bug on the reference side? I don't
seem
> to be able to activate the policy interceptor for reference.policy
> phase.
>
> Gang
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
Classification: UNCLASSIFIED
Caveats: NONE
RE: 2.x Policy interceptors - was: Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
Posted by "Yang, Gang CTR US USA" <ga...@us.army.mil>.
Classification: UNCLASSIFIED
Caveats: NONE
>
> 1. <binding.ws requires="intent"> did not work for me. In the
debugger,
> the composite builder did recognize the new policy and the fact that
> the
> reference/service has required intent, but matching check failed.
> However, <binding.ws policySets="policyset"> worked.
Never mind about the first issue. I had both
createInterceptor(Operation) and createBindingInterceptor() defined so
on the service side, both are activated for service.policy and
service.binding.policy phases.
However, the same policy extension is used on the reference side and the
policy interceptor is called only once. I remember I had problems with
activating the policy interceptor on the reference side (before I played
with service side) if I only define createInterceptor(Operation). So I
defined both to get reference side working. Now with both defined, it is
called twice on service side. A bug on the reference side? I don't seem
to be able to activate the policy interceptor for reference.policy
phase.
Gang
Classification: UNCLASSIFIED
Caveats: NONE
Re: 2.x Policy interceptors - was: Re: PolicyHandler exception
handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is
generated (UNCLASSIFIED)
Posted by Gang Yang <ga...@gmail.com>.
Simon,
Thank you for giving these issues expedited attention since our project has
a delivery date of end of March.
Gang
----- Original Message -----
From: "Simon Nash" <si...@cjnash.com>
To: <de...@tuscany.apache.org>
Sent: Saturday, March 26, 2011 4:39 PM
Subject: Re: 2.x Policy interceptors - was: Re: PolicyHandler exception
handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is
generated (UNCLASSIFIED)
> Yang, Gang CTR US USA wrote:
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> (cut)
>>
>> BTW, when will the Tuscan 1.6.x next release with the fixes we have
>> discussed be?
>>
> I'll work on applying the fixes for TUSCANY-3822 and TUSCANY-3838
> to the 1.x codebase this week.
>
> After these fixes have been applied and verified as working, I'd be
> willing to create a 1.6.2 release candidate from the 1.6.1 branch
> with these two fixes (only) merged in.
>
> Does anyone have any concerns about doing a 1.6.2 release using this
> approach?
>
> Simon
>
>> Thanks,
>> Gang
>>
Re: 2.x Policy interceptors - was: Re: PolicyHandler exception handling
issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated
(UNCLASSIFIED)
Posted by Simon Nash <si...@cjnash.com>.
Yang, Gang CTR US USA wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> (cut)
>
> BTW, when will the Tuscan 1.6.x next release with the fixes we have
> discussed be?
>
I'll work on applying the fixes for TUSCANY-3822 and TUSCANY-3838
to the 1.x codebase this week.
After these fixes have been applied and verified as working, I'd be
willing to create a 1.6.2 release candidate from the 1.6.1 branch
with these two fixes (only) merged in.
Does anyone have any concerns about doing a 1.6.2 release using this
approach?
Simon
> Thanks,
> Gang
>
RE: 2.x Policy interceptors - was: Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
Posted by "Yang, Gang CTR US USA" <ga...@us.army.mil>.
Classification: UNCLASSIFIED
Caveats: NONE
Having finished the dev work for the delivery for end of March, I had a
little time to pick up the Tuscany 2.0 prototype from where I left off.
I finally got my policy interceptor hooked into the invocation chain
(really hoped that there's a policy sample) and was able to see what
actually goes on in the debugger. I mainly concentrated on the area of
getting the SOAP envelope from reference and service sides. It's
interesting to map what I saw to Simon's diagram - I appreciated the
diagram even more, but at the same time I felt a little uneasy about
some of issues, which may not be easy to fix. First, this is my
configuration:
- Used Tuscany 2.0-Beta2 with Axis2 ws binding provider. I could not get
the default JAX-WS provider to work.
- Wrote a policy extension with a policy interceptor plugged in at
reference/service binding phases.
- Used Request/Response.getBindingContext() to access Axis2's
OperationClient/MessageContext to obtain SOAPEnvelope.
This is what I found:
1. <binding.ws requires="intent"> did not work for me. In the debugger,
the composite builder did recognize the new policy and the fact that the
reference/service has required intent, but matching check failed.
However, <binding.ws policySets="policyset"> worked.
2. On the service side, my policy interceptor was called twice, once by
RuntimeInvoker.invokeBinding() and once by
DataTransformationInterceptor.invoke(). The latter baffled me because my
policy.getPhase() returns service.binding.policy.
3. On the service side, after my policy's call to getNext().invoke()
returns, the response (actually the same object as request) does not
contain the response SOAP envelope (I did follow the context hierarchy
to find the right message context for response). It has not been set up
yet and it's null. I actually verified this by following the execution
and found that the SOAP envelope is constructed after the call returned
in Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic(). This
matches Simon's diagram comment number 1.
What I felt uneasy about is the issue 3. It's not because the policy
interceptor is invoked before Axis2 in the return direction, but because
there seems to be no solution because of the single-point invocation
chain architecture. Compared to the PolicyHandler's beforeInvoke() and
afterInvoke() mechanism, which allows two (2) separate opportunities to
plug in two logics at potentially two different places, the invocation
chain mechanism has only one (1) callback, invoke(), which will need to
call the "next". With this single-point mechanism, there seems to be a
no-win situation - if you plug in policy interceptor at the point the
diagram shows, the response envelope is not yet available for the
outgoing response processing; but if you plug in policy interceptor at
the point after responses envelope is constructed in Axis2, it'll be too
late for the incoming request processing:-(
Anyway, just want to bring up these issues so that they can be addressed
before our project decides to move to Tuscany 2.0.
BTW, when will the Tuscan 1.6.x next release with the fixes we have
discussed be?
Thanks,
Gang
> -----Original Message-----
> From: Simon Laws [mailto:simonslaws@googlemail.com]
> Sent: Tuesday, March 01, 2011 5:17 AM
> To: dev@tuscany.apache.org
> Subject: Re: 2.x Policy interceptors - was: Re: PolicyHandler
exception
> handling issue - PolicyHandler.afterInvoke() is not called when
> SOAPFault is generated (UNCLASSIFIED)
>
> I put a diagram of my understanding of the current 2.x
> binding.ws/policy interceptor situation here [1] along with some
> comments relating to the issues we've been discussing (the first four
> numbered comments relate to Gang's numbered comments). Some of these
> issues are I think resolvable given the approach to Axis integration
> we have at the moment. Some of them are more problematic though.
>
> Our basic approach currently is that we do all of our processing
> outside of the Axis handlers. Our approach to WS-Security is to
> engaged Rampart (this is enabled in 1.x but not yet in 2,x) rather
> than to write it ourselves The requirement to process the SOAP message
> very close to the transport when doing bespoke encryption is the
> tricky part. To allow it all to happen in the binding wire using
> policy interceptors we'd have to be much more careful about where SOAP
> envelopes are created and read and where the operation selection is
> performed. There is a danger of re-inventing Axis.
>
> I think a sensible approach to making progress is to improve the
> things we should improve regardless of the bespoke encryption
> requirement. For example, 5/ consistency of binding context, 1/
> access to appropriate message contexts, 2/ context sharing mechanism.
> The fallback for bespoke encryption is to create Axis handlers. In
> parallel I'd like to look at how we integrate with Axis, for example,
> we could look back at the JAXWS integration approach so at least any
> handlers that are build are in some way following a standard pattern.
>
> [1]
>
https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Policy+Implemen
> tation
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Classification: UNCLASSIFIED
Caveats: NONE
Re: 2.x Policy interceptors - was: Re: PolicyHandler exception
handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is
generated (UNCLASSIFIED)
Posted by Simon Laws <si...@googlemail.com>.
I put a diagram of my understanding of the current 2.x
binding.ws/policy interceptor situation here [1] along with some
comments relating to the issues we've been discussing (the first four
numbered comments relate to Gang's numbered comments). Some of these
issues are I think resolvable given the approach to Axis integration
we have at the moment. Some of them are more problematic though.
Our basic approach currently is that we do all of our processing
outside of the Axis handlers. Our approach to WS-Security is to
engaged Rampart (this is enabled in 1.x but not yet in 2,x) rather
than to write it ourselves The requirement to process the SOAP message
very close to the transport when doing bespoke encryption is the
tricky part. To allow it all to happen in the binding wire using
policy interceptors we'd have to be much more careful about where SOAP
envelopes are created and read and where the operation selection is
performed. There is a danger of re-inventing Axis.
I think a sensible approach to making progress is to improve the
things we should improve regardless of the bespoke encryption
requirement. For example, 5/ consistency of binding context, 1/
access to appropriate message contexts, 2/ context sharing mechanism.
The fallback for bespoke encryption is to create Axis handlers. In
parallel I'd like to look at how we integrate with Axis, for example,
we could look back at the JAXWS integration approach so at least any
handlers that are build are in some way following a standard pattern.
[1] https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Policy+Implementation
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: 2.x Policy interceptors - was: Re: PolicyHandler exception
handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is
generated (UNCLASSIFIED)
Posted by Simon Laws <si...@googlemail.com>.
Hi Gang
All this is coming down to being able to access the on the wire XML
that Axis naturally deals with so that a specific, i.e. non-Rampart
based, security solution can be provided. The Tuscany 2.x binding
interceptors are more closely integrated with the binding
implementation but they aren't currently in a position to take part in
the Axis handler chain although they can create Axis handles if
required. More comments in-line below.
Simon
On Fri, Feb 25, 2011 at 10:32 PM, Yang, Gang CTR US USA
<ga...@us.army.mil> wrote:
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> Hi, Simon,
>
> Very good summary. My comments follow.
>
> Gang
>
>> -----Original Message-----
>> From: Simon Laws [mailto:simonslaws@googlemail.com]
>> Sent: Friday, February 25, 2011 12:18 PM
>> To: dev@tuscany.apache.org
>> Subject: Re: 2.x Policy interceptors - was: Re: PolicyHandler
> exception
>> handling issue - PolicyHandler.afterInvoke() is not called when
>> SOAPFault is generated (UNCLASSIFIED)
>>
>> 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
>
> In addition to what is accessible, there's also a timing issue, which is
> also critical. Take the afterInvoke in 1.6.x as an example. Even though
> you may be able to get "out" MessageContext from "in" MessageContext,
> it's also critical when afterInvoke is called. Before my changes,
> afterInvoke is called at a time where "out" MessageContext has not been
> set up correctly.
Good point, I'll try and extend the current test to provide some
insight into what configuration is available at which point.
>
> Conceptually, "out" MessageContext is more natural on the return
> direction.
>
>>
>>
>> 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.
>
> The JIRA TUSCANY-3838 is only for the sub category 3 per Simon N.'s
> categorization. The other two don't have JIRA's yet.
>
> In the subsequent discussions, Simon and I had concluded that a fix for
> sub categories 1 & 2 are non-trivial because the actual AxisFault
> processing that creates the SOAPFault body happens much later on for
> afterInvoke to be invoked. But in 2.x, if a separate interceptor can be
> inserted on the return path, then this can be solved easily and
> naturally.
2.x changes will still be required. To get into the guts of Axis we
have to either use a Tuscany interceptor to add an Axis handler. We
may be able to do more to move the fault creation code so that the
Tuscany binding interceptors can see the data created. Alternatively
we may have to change the way the binding is structured, for example,
maybe we should look again at adopting the JAXWS based binding. We'll
have to experiment.
>
>>
>> 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
>
> I think the take-away from this issue is that we need to be able to
> insert security interceptors fairly close to the transport. Ideally,
> there's not interceptors/processing that would alter the SOAP message
> between the two security interceptors (the one on client side and the
> one on the service side). This is because message encryption and
> signing.
Agreed, and we might have to rely on generating Axis handlers to get
close to the transport in the Axis based binding.. This is at least
possible in 2,x
>
>>
>>
>> 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/dev@tuscany.apache.org/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.
>
> Ideally, with good abstractions, the Tuscany interceptors don't have to
> understand other provider-specific implementations. However, in reality,
> this is often hard to achieve, especially for an SCA framework like
> Tuscany, which is so extensible to brings various implementations and
> protocols together. For WS-security, I need to access SOAP message,
> which is available from Axis2's MessageContext or JAX-WS's
> MessageContext depending on the underlying provider. But for other
> message protocols, one may need to access other provider's message
> context.
>
> I would think the main message context of Tuscany interceptors should be
> Tuscany's own. From Tuscany's message context, one should be able to
> retrieve ANY underlying implementation's message context. There should
> be an API to determine the underlying implementation so interceptors can
> take appropriate actions. Just my 2 cents.
I agree this is worthy goal and it's interesting you bring up the
JAXWS angle. It's worth taking another look at this I think as at
least that is somewhat standard and understood rather than being Axis
specific. We have a basic JAXWS based binding going but It's not OASIS
compliant. Putting all of the thoughts/issues you're raised I think we
can come up with a model of what we need access to where in the
processing chain. On top of this we can assess what the different
approaches brings to the table.
>
>>
>> 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?
>
> Unlike 1.6.x, my 2.0 interceptor prototype was very primitive. I was
> stuck early on trying to have Tuscany to recognize the new policy. I
> definitely can send you that if you think it can be of help. What may be
> more helpful is when I start to put more logic in the interceptor's
> invoke(). However, the goal for me is to obtain access to the SOAP
> message.
>
>>
>> Regards
>>
>> Simon
>>
>>
>> --
>> Apache Tuscany committer: tuscany.apache.org
>> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
RE: 2.x Policy interceptors - was: Re: PolicyHandler exception handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is generated (UNCLASSIFIED)
Posted by "Yang, Gang CTR US USA" <ga...@us.army.mil>.
Classification: UNCLASSIFIED
Caveats: NONE
Hi, Simon,
Very good summary. My comments follow.
Gang
> -----Original Message-----
> From: Simon Laws [mailto:simonslaws@googlemail.com]
> Sent: Friday, February 25, 2011 12:18 PM
> To: dev@tuscany.apache.org
> Subject: Re: 2.x Policy interceptors - was: Re: PolicyHandler
exception
> handling issue - PolicyHandler.afterInvoke() is not called when
> SOAPFault is generated (UNCLASSIFIED)
>
> 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
In addition to what is accessible, there's also a timing issue, which is
also critical. Take the afterInvoke in 1.6.x as an example. Even though
you may be able to get "out" MessageContext from "in" MessageContext,
it's also critical when afterInvoke is called. Before my changes,
afterInvoke is called at a time where "out" MessageContext has not been
set up correctly.
Conceptually, "out" MessageContext is more natural on the return
direction.
>
>
> 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.
The JIRA TUSCANY-3838 is only for the sub category 3 per Simon N.'s
categorization. The other two don't have JIRA's yet.
In the subsequent discussions, Simon and I had concluded that a fix for
sub categories 1 & 2 are non-trivial because the actual AxisFault
processing that creates the SOAPFault body happens much later on for
afterInvoke to be invoked. But in 2.x, if a separate interceptor can be
inserted on the return path, then this can be solved easily and
naturally.
>
> 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
I think the take-away from this issue is that we need to be able to
insert security interceptors fairly close to the transport. Ideally,
there's not interceptors/processing that would alter the SOAP message
between the two security interceptors (the one on client side and the
one on the service side). This is because message encryption and
signing.
>
>
> 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/dev@tuscany.apache.org/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.
Ideally, with good abstractions, the Tuscany interceptors don't have to
understand other provider-specific implementations. However, in reality,
this is often hard to achieve, especially for an SCA framework like
Tuscany, which is so extensible to brings various implementations and
protocols together. For WS-security, I need to access SOAP message,
which is available from Axis2's MessageContext or JAX-WS's
MessageContext depending on the underlying provider. But for other
message protocols, one may need to access other provider's message
context.
I would think the main message context of Tuscany interceptors should be
Tuscany's own. From Tuscany's message context, one should be able to
retrieve ANY underlying implementation's message context. There should
be an API to determine the underlying implementation so interceptors can
take appropriate actions. Just my 2 cents.
>
> 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?
Unlike 1.6.x, my 2.0 interceptor prototype was very primitive. I was
stuck early on trying to have Tuscany to recognize the new policy. I
definitely can send you that if you think it can be of help. What may be
more helpful is when I start to put more logic in the interceptor's
invoke(). However, the goal for me is to obtain access to the SOAP
message.
>
> Regards
>
> Simon
>
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Classification: UNCLASSIFIED
Caveats: NONE
Re: 2.x Policy interceptors - was: Re: PolicyHandler exception
handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is
generated (UNCLASSIFIED)
Posted by Simon Laws <si...@googlemail.com>.
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/dev@tuscany.apache.org/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
Re: 2.x Policy interceptors - was: Re: PolicyHandler exception
handling issue - PolicyHandler.afterInvoke() is not called when SOAPFault is
generated (UNCLASSIFIED)
Posted by Simon Laws <si...@googlemail.com>.
I Think the following are the issues that Gang has raised across the
various mail threads. I'll add 2.x comments shortly.
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
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.
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.
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/dev@tuscany.apache.org/msg15581.html
We need to distil this into a proposal for 2.x
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.
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
In 2.x he binding chain is binding specific so has the oppotunity 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