Hi Eoghan,
Glynn, Eoghan wrote:
Can you expand on your preference for the In/Out model?
What specific
advantages do you see it bringing to the table?
The interceptor model as it is allows interceptors to
position themselves correctly inside the interceptor chain.
(for the axis2'ers listening in, this is one of the parts I
like about axis2...) So I can develop my own extensions and
they can just drop in. The user doesn't need to know where to
put them.
Surely the "where to put the interceptor in the chain" question is
encoded within the interceptor itself in *both* models, in the
PhaseInterceptor getPhase() and getBefore/getAfter()?
I don't see how this would be any different for separate In/Out
interceptors as opposed to a single consolidated interceptor.
Sure, but if you make interceptors both in and out, then you need to
have
getOutBefore/getOutAfter/getInBefore/getInAfter/getInPhase/getOutPhase.
This seems messier to me. Also, say we create a pipeline that isn't
in/out, but just does some transformations. In this case we would be
using the chain as more of a general purpose processing pipeline (which
was one of my original goals). I don't think the in & out semantics work
for it.
By baking In/out semantics in
you're immediately going to request/response type semantics
in my mind.
But surely both models bake in the in/out semantics, just in a different
way?
... i.e. the in/out semantics are baked in either as separate
interceptor implementations for the in and out directions, or a single
consolidated interceptor implementation that acts differently depending
on whether the direction is inbound or outbound.
I don't think so - having just phase, after, and before says nothing
about whether there is a message in bound, out bound or whether the
message is even going somewhere at all.
I very much see your point, but is it really that hard to share state?
It can just be stored on the exchange.
- Dan
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com
