axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ajith Ranabahu" <>
Subject Re: Axis2 Architecture problems.
Date Thu, 31 May 2007 08:38:06 GMT
Hi all,
Forgive me for the delayed answer - I was hoping to write a detailed
answer yesterday but other things kept me busy. I'm sure a voice
conversation would be much faster and comprehensive but all of us are
in different timezones that makes it quite difficult to find a
convenient time slot. Also I see that after all this is settled we can
condense the material in this mail thread and make it into a document
in the Axis2 site which should be a nice architecture reference :)

1. I'm very sure that we considered this pattern (one handler calling
the other handler) vs the engine based method in the early days of
Axis2. I'm not so sure what were the reasons then but here are a few
cases that may prove problamatic

 I . What will happen if a handler throws up an exception ? Right now
the Axis engine can catch it and deal with it accordingly. If the
handlers are to be called from one another this exception would return
back through all the executed handlers (by looking at the code sample)
which in my opinion makes it somewhat ugly and difficult to debug. At
least in this case exceptions that rise in any handler will jump out
of the first handler

 II. Things that are deemed very important and inherent part of a SOAP
engine are not put in handlers but implemented as part of the engine
(e.g mustundertand checking) Having a centralized controller makes it
easier for us to handle such things

One point that became obvious to me is that it would not make a
difference if each handler called the next or an external controller
called the next handler (provided that the next handler is provided
using the same source - i.e. the handler chain). This wasn't obvious
in our early days since we did not have anything to compare.

I'm  not sure about what you've meant about each handler knowing what
to invoke next. What I understood initially was that each handler will
call the next handler by consulting the handler chain. In contrast if
we are to keep a reference to the next handler we run into further

There are very practical scenarios where the same handler is called
several times repeatedly, sometimes consecutively , sometimes with
different handlers in between  (e.g. security - Ruchith will be the
best person to actually verify whether this is still the case). Hence
such handlers will have to keep track of where it is in the chain and
how many times it has been called etc. IMHO this is way too

As you can see each handler knowing which operation should it be
active for (the registered operations you've mentioned) does not
matter here at all since we've no clue *how many times* that handler
will be invoked even if we know which operation it belongs to.  Even
if we manage to do it it will become complicated with invocation
counters etc.

If we are after a smaller footprint what I can think of as the best to
do is to make all handlers singleton. i.e. we make sure that if a
handler is used within the engine, there is exactly one instance of
it. This shouldn't make a difference since handler are all logic and
no state!  This is the same thing done in servlets (well in a much
more sophisticated way) but it proves the concept :)

2. Why should the control be returned to the operation client ? well
for the simple reason that operation client is the only guy who knows
what to do next. The idea of the operation client is that operation
client is the only MEP specific component which know how to proceed.
This way we can support multiple MEPs without touching the rest of the
Note that in this case operation client is the ultimate controller. It
has to have that power to completely handle a MEP.

3. As for the SOAP fault detection , yes we can use a property in the
message context. However I'm not sure whether we can guarantee that
property to be set before coming to the OutInOperation (which is part
of the client API. Since it is the user who provides a message context
he can choose what to do with it) and the only reliable way to do that
would be to look at the first child of the SOAP body. I'm hoping we
can find a better way to do this but right now I don't see a better
way. (we can do that nicely in the receive path though. we can look at
the transport information (in most cases) to determine whether to call
the fault flow or the normal in flow)
I should say its not as easy as putting an *if* statement in a single
handler. This if would have to be in *all* the handlers (regardless
they do anything significant during a fault) since we have only that
flow ( for a given direction). It is very sensible to put it in a
different flow to make the code nicer and also to make the process
efficient since the number of fault flow handlers can be significantly
lesser than the number of handlers in the conventional flow.

Before concluding I should say the blame falls on us for not
documenting these facts properly. If it was difficult for a code-savvy
guy like Amila, it would be a nightmare for a complete newbie who
wants get his feet wet. IMHO we should have a few documents that
explain these architectural decisions (and the thinking behind them)
and include them in Axis2 documentation.

Finally - can we please keep the subject intact when discussing these
topics ? I've had a hard time tracking the relevant messages since
there was substantial amount of discussion in a thread with slightly
different subject !


On 5/30/07, Amila Suriarachchi <> wrote:
> hi deepl,
> I agree with you that we have already release the 1.2 and there is no way to
> do any changes (even every one agrees as well).
> this is a solution came to my mind which would adreess the two issues you
> have
> raise.
> public void next(MessageContext messageContext) throws AxisFault {
>         InvocationResponse responese = this.invoke(messageContext);
>         if (responese == InvocationResponse.CONTINUE){
>   ;
>         }else if (responese == InvocationResponse.SUSPEND){
>             // do nothing
>         }
>     }
> if we put this method to AbstractHandler we can preserve the
> API and enforce to return a value.
> thanks,

Ajith Ranabahu

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message