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/03/01 11:17:21 UTC
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+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 "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