You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Eran Chinthaka <ch...@opensource.lk> on 2007/05/28 23:30:16 UTC
Re: Axis2 Architecture problems. ... not any more ;)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Amila, Ajith and all,
First Amila great work. You should be real smart to figure the
architecture, just looking at the code :)
1. There is a similarity between what you've proposed and the current
engine. Even though you have put TransportSender out of the handler
chain, it is also a handler.
2. Ajith also have mentioned, you have burnt IN-OUT in to your
architecture. The OperationClient is the one who handles the MEP. As I
always say, We have two pipes and you plumb them together in any
combination to come up with any MEP. That is what the OperationClient in
the client side, and the MessageReceiver in the server side does.
3. we need to get back the control to the Client once the message is
sent. If you can remember, we do provide transport level asynchrony and
non-blocking invocations. What you've proposed has ignored both of them.
4. In the current system also handlers are stateless and message context
has all the states. AxisEngine is just an invoker/controller. But why
have you mentioned that it is not the case?
5. Again, as Ajith mentioned also, we do not know the handler chain
before hand. IIRC, we have templates of handler chains and we clone from
it to get the fixed set of handlers. But after that we need to include
service and operation specific handlers. Ajith, yes we do have service
specific handlers and it is useful. For example engaging modules per
service basis using WS-Policy. It is not just a "possible" use case,
people do use it.
6. About faults, yes I also agree with you for some extent. When Deepal
initially put that we had some discussions on that.
Thanks,
Chinthaka
Ajith Ranabahu wrote:
> Hi Amila,
> Here are some of the answers to your questions. I believe other will
> chip in with whatever they can contribute (and ofcourse correct me if
> I'm wrong :)) but I will try to answer as many of your questions as
> possible.
>
> 1. AFAIR the primary reason why the operation client is implemented as
> a centralized controller is that we need to support different MEPs.
> Axis engine nor the handlers would know nothing about the MEPs and
> there would be no need. The only MEP specific implementation would be
> the operation client and that will invoke the Axis engine as many
> times as needed to complete the MEP. This is not so obvious right now
> since the primary MEPs we encounter are in-only and in-out. But
> WSDL2.0 is around the corner and supporting multiple MEPs would be of
> great importance to a framework that supports WSDL2.0.
>
> 2. I believe the reason to clone and add the handlers as a new list
> was that it was expected that there would be service specific and
> operation specific handlers. I'm not sure how much we've seen this
> being useful, or even whether we support this in the current code. We
> may need to take a look at this code once again though.
>
> 3. Fault flow is separated (treated specially) since there could be a
> need for the handlers to make use of the fact that its a fault (Say
> something like a rollback of some database update which happened
> during the inflow). If we use the usual message path, this will
> require a number of logical statements to determine whether its a
> fault or in the worst case, reading upto the first child of the SOAP
> body to determine whether its a fault (which destroys our advantage of
> streaming). Treating faults separately gives us the advantage of
> tackling that case easily.
> However there is an issue when the message cannot be determined before
> hand to be either a fault or a non-fault response. This particularly
> happens in the asynchronous reply case (over HTTP) where there is no
> HTTP information regarding the nature of the message.(in contrast, the
> sysnchronous HTTP case can be dealt with very easily since the HTTP
> code 500 will indicate a SOAP fault). I'm not sure what happens when
> the messages are encrypted (whether the HTTP code will still be
> indicating the fault). We once discussed this in much detail and the
> decision was (AFAIR) is to switch the flow as soon as possible (i.e.
> the first point we detect the message to be a fault)
> I think this is something we should look back at but I psersonally
> think keeping a fault flow will be useful.
>
> Thanks
>
> Ajith
>
> On 5/28/07, Amila Suriarachchi <am...@gmail.com> wrote:
>>
>> here with I have attached the pdf format.
>>
>>
>> On 5/28/07, Amila Suriarachchi <amilasuriarachchi@gmail.com > wrote:
>> > hi,
>> > here with I have attached an document which describes some of the
>> problems
>> > I see with the current axis2 architecture and a possible solution.
>> >
>> > Please have a look and put your comments.
>> >
>> > Amila.
>> >
>> > --
>> > Amila Suriarachchi,
>> > WSO2 Inc.
>> >
>>
>>
>>
>> --
>> Amila Suriarachchi,
>> WSO2 Inc.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGW0nojON2uBzUhh8RAjxIAJ4imM7L/qppxk7geoQLdtn8Ol0LzwCgjFpO
bN/5tmsevH0qqFk7sITWIPE=
=EM40
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Axis2 Architecture problems. ... not any more ;)
Posted by Davanum Srinivas <da...@gmail.com>.
Samisa,
think of this situation, we need to add a rampart handler for
encrypting a response back to the client and we don't want to do any
encryption if there is a fault. currently if we just add a handler in
the out flow, we are all set. otherwise, we need to add additional
logic in the handler for detecting faults. Also say, there is a
logging handler needs to be added for faults ONLY, we don't want that
handler to be called under normal conditions as we don't want the over
head of checking if the current flow is fault or normal. that was the
reason we added it, (if i renenver right). of course there's nothing
wrong in writing only one set of handlers for doing everything...i
guess.
-- dims
On 5/28/07, Samisa Abeysinghe <sa...@gmail.com> wrote:
> Eran Chinthaka wrote:
> > 6. About faults, yes I also agree with you for some extent. When Deepal
> > initially put that we had some discussions on that.
> >
> "Why there is a separate flow to handle the Faults?"
> With my understanding, the handers to be invoked when there is a fault,
> could be different form the handlers that could be invoked when there is
> no fault.
> (Going by the definition, a flow is a collection of phases and a phase
> is a collection of handlers). Now it is questionable if it is really
> necessary to have different handlers for fault path or the same set of
> handlers could deal with both fault cases and non fault cases.
>
> Samisa...
>
> --
> Samisa Abeysinghe : http://www.bloglines.com/blog/samisa
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Axis2 Architecture problems. ... not any more ;)
Posted by Eran Chinthaka <ch...@opensource.lk>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sanjiva Weerawarana wrote:
> It is necessary .. we already have scenarios where the security policy
> for faults is different from normal messages.
I agree. This is just question of where to put the if statement
if(envelope.getBody().hasFault()). If this is in the engine, then we
will have two flows, if not this if statement will go inside handler.
I do not have specific plus points for both of them. That is why I
mentioned like that earlier :)
Chinthaka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGXO9SjON2uBzUhh8RAuMLAJ95JZH3wxwU3/jGQSeY2CbVdQ8HSwCeKGVD
/JBCcozoUhoXR6GFc2CwFqM=
=jc5Q
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Axis2 Architecture problems. ... not any more ;)
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Samisa Abeysinghe wrote:
> Eran Chinthaka wrote:
>> 6. About faults, yes I also agree with you for some extent. When Deepal
>> initially put that we had some discussions on that.
>>
> "Why there is a separate flow to handle the Faults?"
> With my understanding, the handers to be invoked when there is a fault,
> could be different form the handlers that could be invoked when there is
> no fault.
> (Going by the definition, a flow is a collection of phases and a phase
> is a collection of handlers). Now it is questionable if it is really
> necessary to have different handlers for fault path or the same set of
> handlers could deal with both fault cases and non fault cases.
It is necessary .. we already have scenarios where the security policy for
faults is different from normal messages.
On the topic of operation level flows- again we already have cases where
people are setting different policies on a per-operation basis and, in
some cases, only for the input of a certain operation. The handler chain
needs to be available locally at each level in order to make it work right.
SAnjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Axis2 Architecture problems. ... not any more ;)
Posted by Amila Suriarachchi <am...@gmail.com>.
hi Rajith.
Thanks for your reply.
Sorry for late replying. I tried to reply once but missed it and fogotten.
On 5/29/07, Rajith Attapattu <ra...@gmail.com> wrote:
>
> Amila,
>
> First of all I want to make sure I understand your idea properly. Based
> on my understanding I have put down my comments.
> Is this what u are proposing?I am putting them down in point form to make
> it simple and easy to understand. Please shout if I have misunderstood you.
>
> 1. You want a single set of handlers that are determined at deployment
> time.
yes.
2. You register operations against each handler. (So instead of each
> operation O1 having (H1,H2..Hn) you are inverting the relationship and
> proposing H1 (O1,O3,Om) and H2(O2,O3,On) ..etc
yes.
3. As u say "they know next handler and registered operations but they *do
> not change* when processing the messages."
> This means the handler chain is static
and is aware of the next handler in line.
>
> Here are my comments.
> 1. Since u are having only one set of handlers, u will have to include all
> the handlers in the chain. This is not efficient and will force the message
> ctx to flow through all handlers irrespective of their interest and needs to
> look up the operations map to figure out whether this operation is
> registered with the particular handler.
This depends tipically how much handler can there be in a server and how
long would it be. I belive it is less than 40. of course if there are more
than 100 handlers this is a problem.
2. For different flows the order and composition of handlers can change. Ex
> read Sanjiva and Dims email.
> Ex - composition - We only want to log fault messages
> order - for fault messages we may want to have a custom phase
> before policy determination phase and for normal messages we want the custom
> phase after the policy determination phase.
> Considering your 3rd point above, how are u going to handle this
> situation?
can you please discribe this bit more. What happens at the policy
determination phase?
3. If u have a single handler chain it will also be the bottle neck as all
> your messages will now flow through a single instance of the handler chain
> in serial order.
> To increase performance now u will have to clone (create several
> instances of) this handler chain to process messages parallel.
No. we can use the same handler chain. This is the idea behind keep its
state unchanged during the message process
How different is this from creating a custom handler chain for each
> operation?
With your proposal u can reuse from a pool of handler chain instances and
will not be quite as expensive as creating every time., but if we cache
custom handler chains then we can achieve the same performance. So If we are
incurring the more or less the same cost then why not go for the added
flexibility?
The main difference between the handler chain currently have and what I am
proposing is the flow. In current case is invoked by the Axis2 Engine and
hence has no control to handlers. But on the new way each handler call to
next and have a more controll. So what type of handler chain you are talking
about?
if you proposing to keep a special handler chain (as I have told)for each
operation. (or in the Axis2Engine in a hash map indexed with the operation
Qname) that is also a possibility. this will reduce the chain length.
But the problem comes when receiving messages, without knowing the operation
before invoking and may be a problem.
> If you are worried about memory and performance due to creating the
> handler chain each time a message comes (for the current architecture), why
> not we cache a particular handler chain? We can use a LRU algorithm to weed
> out the cache. We can make this feature configurable, so people who don't
> want caching can turn it off.
It clones the handler chain always simply becauce it can not use same
handler set. So caching is not a solution.
Actually It was disscussed to put a flag to use either cloning or not in
this thread.
thanks,
Amila.
Regards,
>
> Rajith Attapattu.
> Red Hat.
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: Axis2 Architecture problems. ... not any more ;)
Posted by Davanum Srinivas <da...@gmail.com>.
Am usually awake at that time...except when you need me of course :)
On 6/2/07, Eran Chinthaka <ch...@opensource.lk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Sanjiva Weerawarana wrote:
> > While there are many challenges in this medium, the biggest advantage is
> > that the history is recorded. This is a good conversation to either
> > (re-)rationalize the current architecture or improve it. Given the
> > globally distributed nature of this community, its virtually impossible
> > to find a single happy slot for a telecon anyway!
>
> If we really want to have an audio chat, the best I'd suggest is 0000h EDT.
>
> 0000 EDT = 0930 SLT = 2100 PDT. Assuming no-one from UK (Paul I didn't
> see you in this) this can be the best time. The worst time is for me and
> Dims :)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGYhhejON2uBzUhh8RAmABAJ9AUJ7wiRZQvnUMSTxVyOWT5J5wQgCfUJuh
> +DPkDVKKZ8CegBhGKm7m2/A=
> =+Vec
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Axis2 Architecture problems. ... not any more ;)
Posted by David Illsley <da...@gmail.com>.
It's an interesting discussion but I'm happy not to be involved (I'm
not expecting big changes to the axis2 architecture to happen, expect
some followup on the list if there is:-)
David
On 03/06/07, Eran Chinthaka <ch...@opensource.lk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Sanjiva Weerawarana wrote:
> > While there are many challenges in this medium, the biggest advantage is
> > that the history is recorded. This is a good conversation to either
> > (re-)rationalize the current architecture or improve it. Given the
> > globally distributed nature of this community, its virtually impossible
> > to find a single happy slot for a telecon anyway!
>
> If we really want to have an audio chat, the best I'd suggest is 0000h EDT.
>
> 0000 EDT = 0930 SLT = 2100 PDT. Assuming no-one from UK (Paul I didn't
> see you in this) this can be the best time. The worst time is for me and
> Dims :)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGYhhejON2uBzUhh8RAmABAJ9AUJ7wiRZQvnUMSTxVyOWT5J5wQgCfUJuh
> +DPkDVKKZ8CegBhGKm7m2/A=
> =+Vec
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Axis2 Architecture problems. ... not any more ;)
Posted by Eran Chinthaka <ch...@opensource.lk>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sanjiva Weerawarana wrote:
> While there are many challenges in this medium, the biggest advantage is
> that the history is recorded. This is a good conversation to either
> (re-)rationalize the current architecture or improve it. Given the
> globally distributed nature of this community, its virtually impossible
> to find a single happy slot for a telecon anyway!
If we really want to have an audio chat, the best I'd suggest is 0000h EDT.
0000 EDT = 0930 SLT = 2100 PDT. Assuming no-one from UK (Paul I didn't
see you in this) this can be the best time. The worst time is for me and
Dims :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGYhhejON2uBzUhh8RAmABAJ9AUJ7wiRZQvnUMSTxVyOWT5J5wQgCfUJuh
+DPkDVKKZ8CegBhGKm7m2/A=
=+Vec
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Axis2 Architecture problems. ... not any more ;)
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
While there are many challenges in this medium, the biggest advantage is
that the history is recorded. This is a good conversation to either
(re-)rationalize the current architecture or improve it. Given the
globally distributed nature of this community, its virtually impossible to
find a single happy slot for a telecon anyway!
So, despite all the pain I think we need to continue on this path :(.
Sanjiva.
Eran Chinthaka wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Now I can feel the real barriers of communication when we are far away :).
>
> Since this is a revisit of the architecture, and all the replies are
> very long, can we have an audio chat.
> We used to have weekly IRC chats, but not anymore. So how about having
> an audio conference?
>
> Chinthaka
>
> Rajith Attapattu wrote:
>> Amila,
>>
>> First of all I want to make sure I understand your idea properly. Based
>> on my understanding I have put down my comments.
>> Is this what u are proposing?I am putting them down in point form to
>> make it simple and easy to understand. Please shout if I have
>> misunderstood you.
>>
>> 1. You want a single set of handlers that are determined at deployment
>> time.
>>
>> 2. You register operations against each handler. (So instead of each
>> operation O1 having (H1,H2..Hn) you are inverting the relationship and
>> proposing H1 (O1,O3,Om) and H2(O2,O3,On) ..etc
>>
>> 3. As u say "they know next handler and registered operations but they
>> *do not change* when processing the messages."
>> This means the handler chain is static and is aware of the next
>> handler in line.
>>
>> Here are my comments.
>> 1. Since u are having only one set of handlers, u will have to include
>> all the handlers in the chain. This is not efficient and will force the
>> message ctx to flow through all handlers irrespective of their interest
>> and needs to look up the operations map to figure out whether this
>> operation is registered with the particular handler.
>>
>> 2. For different flows the order and composition of handlers can change.
>> Ex read Sanjiva and Dims email.
>> Ex - composition - We only want to log fault messages
>> order - for fault messages we may want to have a custom phase
>> before policy determination phase and for normal messages we want the
>> custom phase after the policy determination phase.
>> Considering your 3rd point above, how are u going to handle this
>> situation?
>>
>> 3. If u have a single handler chain it will also be the bottle neck as
>> all your messages will now flow through a single instance of the handler
>> chain in serial order.
>> To increase performance now u will have to clone (create several
>> instances of) this handler chain to process messages parallel.
>>
>> How different is this from creating a custom handler chain for each
>> operation? With your proposal u can reuse from a pool of handler chain
>> instances and will not be quite as expensive as creating every time.,
>> but if we cache custom handler chains then we can achieve the same
>> performance. So If we are incurring the more or less the same cost then
>> why not go for the added flexibility?
>>
>> If you are worried about memory and performance due to creating the
>> handler chain each time a message comes (for the current architecture),
>> why not we cache a particular handler chain? We can use a LRU algorithm
>> to weed out the cache. We can make this feature configurable, so people
>> who don't want caching can turn it off.
>>
>> Regards,
>>
>> Rajith Attapattu.
>> Red Hat.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGXPBdjON2uBzUhh8RAiafAJ9a53WxSay1IPjTZs2yPrJeCvNlnACgqULM
> lfz1iCLMDrtbq7FKRaFe1Hc=
> =H+gG
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Axis2 Architecture problems. ... not any more ;)
Posted by Eran Chinthaka <ch...@opensource.lk>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Now I can feel the real barriers of communication when we are far away :).
Since this is a revisit of the architecture, and all the replies are
very long, can we have an audio chat.
We used to have weekly IRC chats, but not anymore. So how about having
an audio conference?
Chinthaka
Rajith Attapattu wrote:
> Amila,
>
> First of all I want to make sure I understand your idea properly. Based
> on my understanding I have put down my comments.
> Is this what u are proposing?I am putting them down in point form to
> make it simple and easy to understand. Please shout if I have
> misunderstood you.
>
> 1. You want a single set of handlers that are determined at deployment
> time.
>
> 2. You register operations against each handler. (So instead of each
> operation O1 having (H1,H2..Hn) you are inverting the relationship and
> proposing H1 (O1,O3,Om) and H2(O2,O3,On) ..etc
>
> 3. As u say "they know next handler and registered operations but they
> *do not change* when processing the messages."
> This means the handler chain is static and is aware of the next
> handler in line.
>
> Here are my comments.
> 1. Since u are having only one set of handlers, u will have to include
> all the handlers in the chain. This is not efficient and will force the
> message ctx to flow through all handlers irrespective of their interest
> and needs to look up the operations map to figure out whether this
> operation is registered with the particular handler.
>
> 2. For different flows the order and composition of handlers can change.
> Ex read Sanjiva and Dims email.
> Ex - composition - We only want to log fault messages
> order - for fault messages we may want to have a custom phase
> before policy determination phase and for normal messages we want the
> custom phase after the policy determination phase.
> Considering your 3rd point above, how are u going to handle this
> situation?
>
> 3. If u have a single handler chain it will also be the bottle neck as
> all your messages will now flow through a single instance of the handler
> chain in serial order.
> To increase performance now u will have to clone (create several
> instances of) this handler chain to process messages parallel.
>
> How different is this from creating a custom handler chain for each
> operation? With your proposal u can reuse from a pool of handler chain
> instances and will not be quite as expensive as creating every time.,
> but if we cache custom handler chains then we can achieve the same
> performance. So If we are incurring the more or less the same cost then
> why not go for the added flexibility?
>
> If you are worried about memory and performance due to creating the
> handler chain each time a message comes (for the current architecture),
> why not we cache a particular handler chain? We can use a LRU algorithm
> to weed out the cache. We can make this feature configurable, so people
> who don't want caching can turn it off.
>
> Regards,
>
> Rajith Attapattu.
> Red Hat.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGXPBdjON2uBzUhh8RAiafAJ9a53WxSay1IPjTZs2yPrJeCvNlnACgqULM
lfz1iCLMDrtbq7FKRaFe1Hc=
=H+gG
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Axis2 Architecture problems. ... not any more ;)
Posted by Rajith Attapattu <ra...@gmail.com>.
Amila,
First of all I want to make sure I understand your idea properly. Based on
my understanding I have put down my comments.
Is this what u are proposing?I am putting them down in point form to make it
simple and easy to understand. Please shout if I have misunderstood you.
1. You want a single set of handlers that are determined at deployment time.
2. You register operations against each handler. (So instead of each
operation O1 having (H1,H2..Hn) you are inverting the relationship and
proposing H1 (O1,O3,Om) and H2(O2,O3,On) ..etc
3. As u say "they know next handler and registered operations but they *do
not change* when processing the messages."
This means the handler chain is static and is aware of the next handler
in line.
Here are my comments.
1. Since u are having only one set of handlers, u will have to include all
the handlers in the chain. This is not efficient and will force the message
ctx to flow through all handlers irrespective of their interest and needs to
look up the operations map to figure out whether this operation is
registered with the particular handler.
2. For different flows the order and composition of handlers can change. Ex
read Sanjiva and Dims email.
Ex - composition - We only want to log fault messages
order - for fault messages we may want to have a custom phase
before policy determination phase and for normal messages we want the custom
phase after the policy determination phase.
Considering your 3rd point above, how are u going to handle this
situation?
3. If u have a single handler chain it will also be the bottle neck as all
your messages will now flow through a single instance of the handler chain
in serial order.
To increase performance now u will have to clone (create several
instances of) this handler chain to process messages parallel.
How different is this from creating a custom handler chain for each
operation? With your proposal u can reuse from a pool of handler chain
instances and will not be quite as expensive as creating every time., but if
we cache custom handler chains then we can achieve the same performance. So
If we are incurring the more or less the same cost then why not go for the
added flexibility?
If you are worried about memory and performance due to creating the handler
chain each time a message comes (for the current architecture), why not we
cache a particular handler chain? We can use a LRU algorithm to weed out the
cache. We can make this feature configurable, so people who don't want
caching can turn it off.
Regards,
Rajith Attapattu.
Red Hat.
Re: Axis2 Architecture problems. ... not any more ;)
Posted by Amila Suriarachchi <am...@gmail.com>.
hi all,
Let me present this in a different way.
In the current architecture we can say "Operation has a set of handlers".
So it is represented as inflow/outflow in the AxisOperation.
we can say the first statement again as "hadler has a set of operations"
If we represent this then, Handler have set of registered Operations.
former is the way that current axis2 implementation has look into it. and
letter is the
way I am going to say.
In the current implementation at the deployment time it determines the
handler chain for the operation
and put it in the Operation. Which means it is possible to determine the
handler order at the deployment
time.
So when it processing the messages Axis2 Engine invoke the handlers of the
operation by taking one
by one. Here Axis2 Engine and handlers does not keep any data (i.e totally
stateless). i.e All the processing is done at the message processing time.
To do this it has introduced a lot of control variables.
In the new way What it does at the deployment time is it process the handler
details (in the operations) and
creates an Axis2 Engine which is capable of processing messages straight a
way. In fact this way handlers are state full.i.e they know next handler and
registered operations but they *do not change* when processing the messages.
As a result of this prepossessing we can reduce the message processing time.
and the complexity of the system. As a result . there is no need to keep the
handler information with the Axis2 operations.
As I have explained above this is about the re factoring the Axis2 Engine
and handler flow pattern.
So this should not make any harm to MEP processing and other stuffs (as I
believe).
So please try to think in the way I have given it here.
thanks,
Amila.
On 5/29/07, Deepal Jayasinghe <de...@opensource.lk> wrote:
>
>
>
> Samisa Abeysinghe wrote:
> > Eran Chinthaka wrote:
> >> 6. About faults, yes I also agree with you for some extent. When Deepal
> >> initially put that we had some discussions on that.
> >>
> > "Why there is a separate flow to handle the Faults?"
> > With my understanding, the handers to be invoked when there is a
> > fault, could be different form the handlers that could be invoked when
> > there is no fault.
> > (Going by the definition, a flow is a collection of phases and a phase
> > is a collection of handlers). Now it is questionable if it is really
> > necessary to have different handlers for fault path or the same set of
> > handlers could deal with both fault cases and non fault cases.
> Same handler chain can do the processing of fault and non-fault case ,
> but need to have if statement to check whether it is processing a fault
> or not.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: Axis2 Architecture problems. ... not any more ;)
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Samisa Abeysinghe wrote:
> Eran Chinthaka wrote:
>> 6. About faults, yes I also agree with you for some extent. When Deepal
>> initially put that we had some discussions on that.
>>
> "Why there is a separate flow to handle the Faults?"
> With my understanding, the handers to be invoked when there is a
> fault, could be different form the handlers that could be invoked when
> there is no fault.
> (Going by the definition, a flow is a collection of phases and a phase
> is a collection of handlers). Now it is questionable if it is really
> necessary to have different handlers for fault path or the same set of
> handlers could deal with both fault cases and non fault cases.
Same handler chain can do the processing of fault and non-fault case ,
but need to have if statement to check whether it is processing a fault
or not.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Axis2 Architecture problems. ... not any more ;)
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Eran Chinthaka wrote:
> 6. About faults, yes I also agree with you for some extent. When Deepal
> initially put that we had some discussions on that.
>
"Why there is a separate flow to handle the Faults?"
With my understanding, the handers to be invoked when there is a fault,
could be different form the handlers that could be invoked when there is
no fault.
(Going by the definition, a flow is a collection of phases and a phase
is a collection of handlers). Now it is questionable if it is really
necessary to have different handlers for fault path or the same set of
handlers could deal with both fault cases and non fault cases.
Samisa...
--
Samisa Abeysinghe : http://www.bloglines.com/blog/samisa
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Axis2 Architecture problems. ... not any more ;)
Posted by Amila Suriarachchi <am...@gmail.com>.
Hi ajith and chinthaka and all,
I really appreciate your comments on this since this helps me (and lot of
new comers to Axis2 )
to learn about the Axis2 core and the reasons behind some design decisions.
Please have a look at what I thought about the things you have specified.
On 5/29/07, Eran Chinthaka <ch...@opensource.lk> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Amila, Ajith and all,
>
> First Amila great work. You should be real smart to figure the
> architecture, just looking at the code :)
>
> 1. There is a similarity between what you've proposed and the current
> engine. Even though you have put TransportSender out of the handler
> chain, it is also a handler.
No. The thing I want to emphasise here is not the handler concept. which is
already there and
it is a brilliant idea. But the difference is the flow. I my way each
handler invokes the next and
in current way all of them invoked by the engine and engine is the
centralized controller. if you
think you are a RM developer you can relay feel the difference.
2. Ajith also have mentioned, you have burnt IN-OUT in to your
> architecture. The OperationClient is the one who handles the MEP. As I
> always say, We have two pipes and you plumb them together in any
> combination to come up with any MEP. That is what the OperationClient in
> the client side, and the MessageReceiver in the server side does.
Why Operational client can not handle the mep in the way I have proposed?
there also operational
client sends the requests and get them. I think that is totally correct and
that can be there with the new
layout as well.
3. we need to get back the control to the Client once the message is
> sent.
Why?
If you can remember, we do provide transport level asynchrony and
> non-blocking invocations. What you've proposed has ignored both of them.
No. I don't have detailed understanding of this. But My guess is Axis2 use a
table to keep the
MessageIDs and MessageContextes. and retrieve the correct out message
context and operational
context from this. So why can't in the second way?
> 4. In the current system also handlers are stateless and message context
> has all the states. AxisEngine is just an invoker/controller. But why
> have you mentioned that it is not the case?
yes I agree. I think I did not mean it is statefull. if so my mistake.
sorry for that.
5. Again, as Ajith mentioned also, we do not know the handler chain
> before hand. IIRC, we have templates of handler chains and we clone from
> it to get the fixed set of handlers. But after that we need to include
> service and operation specific handlers. Ajith, yes we do have service
> specific handlers and it is useful. For example engaging modules per
> service basis using WS-Policy. It is not just a "possible" use case,
> people do use it.
I tried to mention this but may not be clear to you. This is what I want to
say.
Lets say we have two operations O1, O2 and have operational level handlers
in the order H1 H2 H3 and H2 H1.
So in the current system what we do is determine these handler chains at the
deployment
time and put to the operation and invoke them accordingly. This is an
operation centric way of thinking.
This is what I am suggesting.
here, We have tree handlers and to operations. So in each hanlder we keep
the registered services and operations.
and create the handler chain accordingly. So when the message context passes
through this handler chain it do operations on message only if the operation
is registered. For this case handler chain would look like this
hanlder (in order) registered operations
H1 O1
H2 O1,O2
H3 O1
H1 O2
As you can see when messages passes through it correct handlers invoke in
correct order. (we can have a simple algorithm to build this chain) So no
need to create handler chains for each and every message. This would greatly
improve the memory and performance.
6. About faults, yes I also agree with you for some extent. When Deepal
> initially put that we had some discussions on that.
>
> Thanks,
> Chinthaka
>
> Ajith Ranabahu wrote:
> > Hi Amila,
> > Here are some of the answers to your questions. I believe other will
> > chip in with whatever they can contribute (and ofcourse correct me if
> > I'm wrong :)) but I will try to answer as many of your questions as
> > possible.
> >
> > 1. AFAIR the primary reason why the operation client is implemented as
> > a centralized controller is that we need to support different MEPs.
> > Axis engine nor the handlers would know nothing about the MEPs and
> > there would be no need. The only MEP specific implementation would be
> > the operation client and that will invoke the Axis engine as many
> > times as needed to complete the MEP. This is not so obvious right now
> > since the primary MEPs we encounter are in-only and in-out. But
> > WSDL2.0 is around the corner and supporting multiple MEPs would be of
> > great importance to a framework that supports WSDL2.0.
> >
> > 2. I believe the reason to clone and add the handlers as a new list
> > was that it was expected that there would be service specific and
> > operation specific handlers. I'm not sure how much we've seen this
> > being useful, or even whether we support this in the current code. We
> > may need to take a look at this code once again though.
Compare the solution I have suggested above. which will create an Engine
which can invoke
handlers in order of all the messages and the performance we get from it.
>
> > 3. Fault flow is separated (treated specially) since there could be a
> > need for the handlers to make use of the fact that its a fault (Say
> > something like a rollback of some database update which happened
> > during the inflow). If we use the usual message path, this will
> > require a number of logical statements to determine whether its a
> > fault or in the worst case, reading upto the first child of the SOAP
> > body to determine whether its a fault (which destroys our advantage of
> > streaming).
See the code. Axis2 branch 1.2 OutInAxisOperation 388
if (resenvelope.getBody().hasFault()||responseMessageContext.isProcessingFault())
{
engine = new AxisEngine(msgctx.getConfigurationContext());
engine.receiveFault(responseMessageContext);
if (options.isExceptionToBeThrownOnSOAPFault()) {
// does the SOAPFault has a detail element for Excpetion
AxisFault af = Utils.getInboundFaultFromMessageContext
(responseMessageContext);
throw af;
}
} else {
engine = new AxisEngine(msgctx.getConfigurationContext());
engine.receive(responseMessageContext);
if(responseMessageContext.getEnvelope
().getBody().hasFault()){
if (options.isExceptionToBeThrownOnSOAPFault()) {
// does the SOAPFault has a detail element for
Excpetion
AxisFault af =
Utils.getInboundFaultFromMessageContext(responseMessageContext);
throw af;
}
}
if (responseMessageContext.getReplyTo() != null) {
sc.setTargetEPR(responseMessageContext.getReplyTo());
}
}
always it access the fault body element before it goes to recive path.
correct me if I have misunderstood.
Treating faults separately gives us the advantage of
> > tackling that case easily.
> > However there is an issue when the message cannot be determined before
> > hand to be either a fault or a non-fault response. This particularly
> > happens in the asynchronous reply case (over HTTP) where there is no
> > HTTP information regarding the nature of the message.(in contrast, the
> > sysnchronous HTTP case can be dealt with very easily since the HTTP
> > code 500 will indicate a SOAP fault). I'm not sure what happens when
> > the messages are encrypted (whether the HTTP code will still be
> > indicating the fault). We once discussed this in much detail and the
> > decision was (AFAIR) is to switch the flow as soon as possible (i.e.
> > the first point we detect the message to be a fault)
> > I think this is something we should look back at but I psersonally
> > think keeping a fault flow will be useful.
My suggestion is to set a variable in message context to say it is a fault
or not.
so if the handler is not intended to process it they can use this variable
an ignore it.
The main point I want to say that this system is very complex to me.
Therefore I believe any new commer can not start work in it without breaking
the system.
I accept that I don't have indepth knowlege about all the code. But any way
your comments on these
things greatly help me to improve our knowledge.
Thanks,
Amila.
>
> > Thanks
> >
> > Ajith
> >
> > On 5/28/07, Amila Suriarachchi <am...@gmail.com> wrote:
> >>
> >> here with I have attached the pdf format.
> >>
> >>
> >> On 5/28/07, Amila Suriarachchi <amilasuriarachchi@gmail.com > wrote:
> >> > hi,
> >> > here with I have attached an document which describes some of the
> >> problems
> >> > I see with the current axis2 architecture and a possible solution.
> >> >
> >> > Please have a look and put your comments.
> >> >
> >> > Amila.
> >> >
> >> > --
> >> > Amila Suriarachchi,
> >> > WSO2 Inc.
> >> >
> >>
> >>
> >>
> >> --
> >> Amila Suriarachchi,
> >> WSO2 Inc.
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-dev-help@ws.apache.org
> >>
> >>
> >
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGW0nojON2uBzUhh8RAjxIAJ4imM7L/qppxk7geoQLdtn8Ol0LzwCgjFpO
> bN/5tmsevH0qqFk7sITWIPE=
> =EM40
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: Axis2 Architecture problems. ... not any more ;)
Posted by Deepal Jayasinghe <de...@opensource.lk>.
Samisa Abeysinghe wrote:
> Ajith Ranabahu wrote:
>>
>> However we may be able to improve a bit of the code :) Since the
>> handlers are stateless replicating them would not mean anything
>> (shouldn't make a difference).
> +1. I too agree.
>> Should we able to create a read-only
>> List implementation where only one of the handler instances exist in
>> the engine ?
> Looking at the logic:
> ArrayList outPhases = new ArrayList();
> outPhases.addAll((ArrayList) executionChain.clone());
> outPhases.addAll((ArrayList) msgContext.getConfigurationContext()
> .getAxisConfiguration().getGlobalOutPhases().clone());
> msgContext.setExecutionChain(outPhases);
>
> It does not look like we do any changes to the list after cloning.
> Hence would be better off to drop cloning.
Yes, you can see this code at the sending path. There we get the handler
chain from operation and merge that with the global out chain. But in
the receiving path logic is other way round , first we invoke the global
chain and after dispatch phase we merged operation specific handler chain.
Thanks
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Axis2 Architecture problems. ... not any more ;)
Posted by Samisa Abeysinghe <sa...@gmail.com>.
Ajith Ranabahu wrote:
>
> However we may be able to improve a bit of the code :) Since the
> handlers are stateless replicating them would not mean anything
> (shouldn't make a difference).
+1. I too agree.
> Should we able to create a read-only
> List implementation where only one of the handler instances exist in
> the engine ?
Looking at the logic:
ArrayList outPhases = new ArrayList();
outPhases.addAll((ArrayList) executionChain.clone());
outPhases.addAll((ArrayList) msgContext.getConfigurationContext()
.getAxisConfiguration().getGlobalOutPhases().clone());
msgContext.setExecutionChain(outPhases);
It does not look like we do any changes to the list after cloning. Hence
would be better off to drop cloning.
Samisa...
--
Samisa Abeysinghe : http://www.bloglines.com/blog/samisa
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: Axis2 Architecture problems. ... not any more ;)
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi,
>
> 5. Again, as Ajith mentioned also, we do not know the handler chain
> before hand. IIRC, we have templates of handler chains and we clone from
> it to get the fixed set of handlers. But after that we need to include
> service and operation specific handlers. Ajith, yes we do have service
> specific handlers and it is useful. For example engaging modules per
> service basis using WS-Policy. It is not just a "possible" use case,
> people do use it.
>
Thanks for the clarification :) I was actually thinking more of the
operation specific handlers. I believe the reason why we replicate
that handler chain at the operation level is to support not just
service specific handlers but also operation specific handlers. Now
that I've taken a closer look again at the things, I see that we
provide the functionality to engage specific modules 'per operation'
(in which case a operation specific handler chain is needed). Anyway
there is always the possibility that a user may need his/her own
handlers to be engaged per operation.
However we may be able to improve a bit of the code :) Since the
handlers are stateless replicating them would not mean anything
(shouldn't make a difference). Should we able to create a read-only
List implementation where only one of the handler instances exist in
the engine ?
--
Ajith Ranabahu
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org