Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (herse.apache.org: domain of ajith.ranabahu@gmail.com
 designates 64.233.184.224 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=cuy7IQpSLlm1bYrpPb+YOp/kGwAZYx1g2ji4joj3VSntG8HnGwutwHM2J7nFb0ruxq32rRUYFzy8fZV0mnLB7tVt9DWrX599qn2SSIBDLGKgE5C7GLayULvb+cuQCJqbcvNCKTPxPo9fN5ioP/Wwyn8JvJ94sDDTRIsj3xPKeag=
Message-ID: <f43ea5790706031215i321fcc03tb7b2c8922c4822d9@mail.gmail.com>
Date: Sun, 3 Jun 2007 12:15:19 -0700
From: "Ajith Ranabahu" <ajith.ranabahu@gmail.com>
To: axis-dev@ws.apache.org
Subject: Re: Axis2 Architecture problems.
In-Reply-To: <60708f4b0705310556n4cb1c3b4pfb8e858edea6221b@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <60708f4b0705280730y70802142jab0894b693781444@mail.gmail.com>
	 <60708f4b0705280744t148e463fxe8e0745537083df0@mail.gmail.com>
	 <465BC1B8.8080603@opensource.lk>
	 <60708f4b0705300819y557f3b7ep9931bdf1922e56d5@mail.gmail.com>
	 <f43ea5790705310138r7363b5c9w9b4787b1e1ba67c0@mail.gmail.com>
	 <60708f4b0705310556n4cb1c3b4pfb8e858edea6221b@mail.gmail.com>

Hi,
I will write a summary of the discussion to the list later today (if
anyone else wants to go ahead please do  - don't wait for me :)) but
let me just answer a few concerns first.

First of all I was mistaken about the handlers during the last
conversation. Now the handlers are stateful (i.e. we are talking about
the handler instances) and the different instances of the same handler
now have different 'next handler' references. So the issue I was
thinking of - single handler being invoked multiple times, can be done
without a problem even with this approach.

However I have an issue with exception processing. If you look at the
current approach the unhandled exceptions thrown by a handler is
caught by the engine. (See the while loop from lines 185-229 in class
AxisEngine). The engine knows exactly which point of the execution the
exception occurred and can take necessary action. However if we do the
handler - next approach we cannot get the exception out of the handler
that actually threw it. Even if you put a catch block in the previous
handler it may not be generic or scalable since there is no  guarantee
what the next handler is going to be. We can find a way to deal with
this (perhaps by sending the exception to a different exception
handler utility) but the bottom line is that any unhandled  exception
will travel upstream and come out of the first handler.

The other concern is that now we have to have multiple handler
instances. We can patch the current implementation easily to use only
one instance of a given handler without incurring any cost (if the
current approach of cloning causes memory footprint to increase).
However if we adopt this approach of stateful handlers we *have* to
make separate handler instances, for the operations that needs it.

>
> Remember ajith what you now have is some thing design by many people
> over the years with the experience they have time to time. So I can not give
> give you and in detail design on the first place.
> What I am basically telling is if you think in the way I have explained
> earlier
> you would have find easier solutions than given in this solution.

Yes - The architecture needs to evolve over iterations. There is no
way of figuring out the absolutely correct architecture at the first
run :) I also believe that we need to revisit some of the architecture
decisions and reconsider some of our decisions since we have a better
idea of how things are right now.

> > 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
>
> that is your perception. and that is what we are talking about.
>  for me I would suggest to put these to the final handler.
> which could be a default handler for all messages and which calls to the TS.

The thinking behind this was that if such controls were enforced as
handlers there is a possibility of users skipping those making the
SOAP processing procedure invalid.

>
> yes agree. As I explained earlier it is about changing the handler flow. How
> it affects
> to the MEP? The only  question (with the current Axis2) I have is  when we
> get a request back
> why it directly goes to the Operational client and invoke receive than doing
> this at the
> Transport Receiver. Which we do at the server side.

This I'm not so sure why. Deepal will be able to answer this question correctly

> have a look at this jira
> https://issues.apache.org/jira/browse/AXIS2-2703
> when we receive messages at the server we do not know the operation. So do
> not know the
> operational level handler chain to invoke. So what we does is we first
> invoke global handlers and after dispatching operational handlers.

Yes  - The service / operation level handlers gets plugged onto the
handler chain as soon as the service and the operation is found. (i,e.
after dispatching)

 but we
> can't mix them. (please correct me if I wrong).
>
> if I understood correctl (again please correct me if I wrong) this is the
> reason why we have some
>  constrains for placing handlers.

Partly yes . If you want to put a service specific handler then it has
to be placed after the dispatching phase because there is no way of
knowing the service (or the operation) before dispatching. In other
words if you put something in the global phases it always will always
be executed , regardless of the operation and the service.
There are some exceptions though. If you take security , if the
message is encrypted, there is no way of dispatching (except if the
transport provides dispatching information - such as the SOAPAction
header in SOAP 1.1 HTTP binding) without decrypting the message. So
some handlers for the security module are placed in pre-dispatch phase
to avoid this problem. Ruchith will correct me if what I've said right
now if not correct ;)

Thanks

-- 
Ajith Ranabahu

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org