See responses below. I've removed older discussion to make this easier to follow.
Simon Yang, Gang CTR US USA wrote:
Classification: UNCLASSIFIED Caveats: NONE (cut)
>
Thinking about this some more, I believe it's also possible for the policy handler to get outMC from inMC for the in-out case. This means that we could still call afterInvoke(inMC) for the in-out case as we do at present, but make sure that outMC is fully populated with the response data before we make this call. The policy handler could get outMC from inMC and do whatever processing it wants on the contents of outMC. GY: I guess it's concept and design issue. I think there are two things that we have been putting together in our discussion. The first is the message pattern: in-only, in-out and out-only. What goes with this is the direction of the message. For in-only, there's only one direction, inbound. For in-out, there's inbound and outbound. For out-only, there is only outbound. This is where I'm interested for WS-security. From a service viewpoint looking at the in-out pattern, I would like to think processes in terms of inbound and outbound, which would correspond to two handler methods in the design, let's say inInvoke() and outInvoke() for the inbound and outbound respectively. Naturally I would like to access inbound context, inMC, and outbound context, outMC in these two methods respectively rather than always inbound context, inMC. That's where I came from.
On the service side, before/after corresponds to in/out. However, on the reference invoker side, before/after corresponds to out/in. I don't think we should attempt to redesign this in the 1.x codebase, but it could be a useful discussion for the new 2.0 model.
GY: Then there's the second thing in our discussion, which the timing of invocation of the handler's methods relative to the invocation of the endpoint via wire. I guess that's why the current methods names are called before/afterInvoke(). I had mapped "before" to "in" and "after" to "out". This probably explains why I see it the way I did.
Bearing in mind that policy handlers aren't just for security, I think the before/after terminology does have some justification. When writing security policy handlers for the service side, I agree that before==in and after==out.
GY: Back to what should it be moving forward, my opinion is that if we keep the methods names as is, then In-only: beforeInvoke(inMC) / afterInvoke(inMC)
> +1
In-out: beforeInvoke(inMC) / afterInvoke(outMC)
> I don't feel strongly about this. It's more consistent with the in-only case on the service side to use afterInvoke(inMC). However, the reference side invoker for the in/out case calls beforeInvoke() with requestMC and calls afterInvoke() with responseMC, which would be consistent with the service side calling afterInvoke(outMC). Another advantage of calling afterInvoke(outMC) on the service side is that it makes it easy for the afterInvoke() handler to see whether it needs to deal with a response as well as a request. So on balance I'm inclined to agree that this change makes sense.
Out-only: beforeInvoke(outMC) / afterInvoke(outMC)
It wouldn't be possible to do this, as the service binding only gets one shot at calling a handler (before the outbound message is sent). Also, the names beforeInvoke and afterInvoke aren't meaningful because there's no service invocation. We can defer this for now as there's not much likelihood of out-only being added to 1.x.
GY: Here we combined the two semantics, inbound/outbound and before/after into one. One other note on afterInvoke() calling position, it needs to be moved from Axis2ServiceProvider.invokeTarget() to a later time because outMC, if it's directly passed into afterInvoke() or obtained from inMC, has not be setup correctly.
I think this change is necessary, as the current positioning of the afterInvoke() call means that it couldn't (for example) add headers to the response. I'd be inclined to put the afterInvoke() call after the code that sets up the SOAP envelope in outMC but before the code that sets the "response written" flag in the operation context. Simon
