-----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 <[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] >> >> > > -----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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
