Yang, Gang CTR US USA wrote:
Classification: UNCLASSIFIED
Caveats: NONE
Simon,
I certainly do not have broad-enough knowledge about Tuscany internals
to determine if the changes I made was consistent. It only serves as a
code snippet to demonstrate my issue, but not necessarily final code to
fix the problem. Simon L. said he was going to play with it to see if
there's any problem. The key issue is that for the outbound (response)
processing, the outbound context should be provided.
Hi Gang,
My comment wasn't intended as any criticism of the code you have
written, which fixes an important problem in the case of adding
WS-Security to response messages. I was trying to progress the
discussion to reach a conclusion among the Tuscany community on
what final code change needs to be applied.
Regarding to the Axis2ServiceInOutSyncMessageReceiver vs
Axis2ServiceInMessageReceiver, why would afterInvoke() be even called
for inbound-only message pattern?
>
Possibly because someone might want to write log entries both
before and after the service method has been invoked, to record the
fact that the service request has completed and returned.
Is there a
Axis2ServiceOutMessageReceiver that process the outbound-only message
pattern? I would think that the outbound-only processing needs some
consideration.
That's a good point. Tuscany currently doesn't support out-only.
If this were to be added, it would probably be necessary to call
beforeInvoke() with outMC to give the policy handler the opportunity
to add the necessary security information to the outbound message.
So perhaps the sequence should be:
in-only: beforeInvoke(inMC) / afterInvoke(inMC)
in-out: beforeInvoke(inMC) / afterInvoke(inMC) / beforeInvoke(outMC)
out-only: beforeInvoke(outMC)
Simon
Thanks,
Gang
-----Original Message-----
From: Simon Nash [mailto:n...@apache.org]
Sent: Tuesday, February 01, 2011 10:58 AM
To: dev@tuscany.apache.org
Subject: Re: An issue with PolicyHandler extension framework - a bug or
design flaw? (UNCLASSIFIED)
Yang, Gang CTR US USA wrote:
Classification: UNCLASSIFIED
Caveats: NONE
Hi, Simon,
I have created the JIRA, TUSCANY-3822
(https://issues.apache.org/jira/browse/TUSCANY-3822), and included the
two classes that I changed in order to access the outbound
MessageContext in afterInvoke().
I've also successfully integrated our WS-Security solution with
Tuscany 1.6.1 (with the fix) using the PolicyHandler approach in a
prototype and have indicated to our project management that there's
solution based on Tuscany 1.6.1 (with the fix). We got a "go" to proceed
down this path and our delivery date is the end of March. Our
WS-Security project is to support other projects that are already using
Tuscany 1.6 and needed the government-specific WS-Security solution.
I'm not sure if there's another more "formal" channel to push for the
fix, but I would appreciate it if you or someone from Tuscany could
provide the next release information (Tuscany 1.6.2? and date) and would
like to make sure that the fix be included. If there's anything else I
could do to further help on this, please let me know.
I've been thinking about the consequences of moving the position
of the afterInvoke() call. I can see that it works for a security
policy handler, but it could cause problems for some other kind of
policy handler such as logging.
At present there's a pair of beforeInvoke() and afterInvoke() calls
for every inbound method invocation, whether or not the method
produces a response. These calls are made by the invokeTarget()
method of Axis2ServiceProvider, which can be called from either
Axis2ServiceInOutSyncMessageReceiver or Axis2ServiceInMessageReceiver.
With the proposed change, the afterInvoke() call would be part of
Axis2ServiceInOutSyncMessageReceiver and would therefore be made only
for inbound methods that produce responses, not for inbound methods
that don't produce responses. For a logging policy handler, this
doesn't seem correct.
Perhaps it would be better to arrange the logic so that afterInvoke()
is still called by Axis2ServiceProvider for both the in-only case
and the in-out case, and change the signature of the afterInvoke()
call to include outMC if the method is in-out. This would require
passing outMC to Axis2ServiceProvider.invokeTarget() and moving the
logic that sets up outMC from Axis2ServiceInOutSyncMessageReceiver
into Axis2ServiceProvider.
Simon N.
Thanks again.
Gang
-----Original Message-----
From: Simon Laws [mailto:simonsl...@googlemail.com]
Sent: Monday, January 24, 2011 5:01 PM
To: dev@tuscany.apache.org
Subject: Re: An issue with PolicyHandler extension framework - a bug
or design flaw? (UNCLASSIFIED)
On Mon, Jan 24, 2011 at 9:51 PM, Yang, Gang CTR US USA
<gang.y...@us.army.mil> wrote:
Classification: UNCLASSIFIED
Caveats: NONE
Hi, Simon and others,
I'm reposting this because I found my earlier post was grouped under
an old
topic and it may be why I did not receive any response, which I badly
hope
to hear. To provide a background, I'm trying to write a Policy
extension to
add a new WS-security implementation to WS binding in Tuscany. In my
earlier
post (see
http://www.mail-archive.com/dev@tuscany.apache.org/msg15333.html),
I described the problems with Tuscany 1.6.x Policy extension
framework using
PolicyInterceptor approach and got some pointers from Simon, one is
to try
Tuscany 2.0 and the other is to use the PolicyHandler extension in
Tuscany
1.6.x.
I did not get any response for my request for help on the 2.0 Policy
issues (see
http://www.mail-archive.com/dev@tuscany.apache.org/msg15353.html), so
I went
ahead down to
the second path Simon suggested - to work with PolicyHandler
extension
point in 1.6.x.
Everything went well on the reference side until I was testing on the
service side. I think the current PolicyHandler extension framework
has
a defect when processing the PolicyHandler.afterInvoke() call for the
service side and the model does not fit the need to add WS-security
to the
binding.ws.axis2 binding implementation. Today
PolicyHandler.afterInvoke()
is call with the OMElement response and MessageContext inMC, which is
still
the message context for the inbound request. In order to add
WS-security to
the response, I need to access the message context for the outbound
response.
So I modified Axis2ServiceInOutSyncMessageReceiver and
Axis2ServiceProvider classes to delay the calling of
PolicyHandler.afterInvoke()
from inside Axis2ServiceProvider.invokeTarget() before outMC is
constructed
to after outMC has been constructed in
Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic(). After the
change, my prototype worked and it also passed all unit tests.
Now I would like to hear Tuscany developers' opinions and/or get your
blessing. If this change is fine, how can it be pulled back into the
code
base? If not, what can be done to support what I would like to do,
which is
pretty natural and generic.
I would really appreciate responses so our project can make a
decision.
Thanks in advance,
Gang
PS:
The following is the code segments to high light the change I made
(with
"Gang: ..." comments):
Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic(...) {
....
OMElement responseOM =
(OMElement)provider.invokeTarget(operation, args, inMC);
/*
for ( PolicyHandler policyHandler : policyHandlerList ) {
policyHandler.afterInvoke(operation, args, inMC,
responseOM);
}
*/
SOAPEnvelope soapEnvelope =
getSOAPFactory(inMC).getDefaultEnvelope();
if (null != responseOM ) {
soapEnvelope.getBody().addChild(responseOM);
}
outMC.setEnvelope(soapEnvelope);
outMC.getOperationContext().setProperty(Constants.RESPONSE_WRITTEN,
Constants.VALUE_TRUE);
// Gang: Added
for ( PolicyHandler policyHandler : policyHandlerList ) {
policyHandler.afterInvoke(responseOM, outMC);
}
...
}
Axis2ServiceProvider.invokeTarget(...) {
...
// find the runtime wire and invoke it with the message
RuntimeWire wire =
((RuntimeComponentService)contract).getRuntimeWire(getBinding());
Object response = wire.invoke(op, msg);
// Gang: Commented out
// for ( PolicyHandler policyHandler : policyHandlerList ) {
// policyHandler.afterInvoke(response, inMC);
//}
return response;
}
Classification: UNCLASSIFIED
Caveats: NONE
Hi Gang
It seems reasonable to me at first glance.
I'd like to see it running. A way for me to do this and to get it into
Tuscany is for you to create a JIRA and attach your patch to it. I can
then apply it locally and take a look at it.
Sorry I didn't notice your 2.x question. It is in my reader but I just
missed it amongst other stuff. I'd like to make sure that we can do
the same thing in 2.x as that is where most development is happening.
What I could possibly do when I get 5 minutes is create some policy
interceptors which shows you how to get hold of the MC at the before
and after locations on reference and server. If in the future you want
to move up to 2.x then we'd be more comfortable that the code does
what you need it to.
Regards
Simon
Classification: UNCLASSIFIED
Caveats: NONE
