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 <[EMAIL PROTECTED]> wrote:
here with I have attached the pdf format. On 5/28/07, Amila Suriarachchi <[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Ajith Ranabahu --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
