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 <[EMAIL PROTECTED]> 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 <[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]
--
Amila Suriarachchi,
WSO2 Inc.
