[Axis2] Infoset layering? [Re: [Axis2] Some review notes from me

[Aleksander Slominski <as...@cs.indiana.edu>]

Eran Chinthaka wrote:

>Hi Venkat,
>
>C my comments below.
>
>  
>
>>Hello folks :-)
>>
>>First off, apologies for being a long-time lurker without much active
>>participation in Axis2 due to some other priorities. Indeed, you folks
>>made tremondous progress in seeding and shaping out the next
>>generation SOAP processor.
>>
>>Now, that one more round of discussions are round the corner, I just
>>gone through the code and made a list of notes or observations, which
>>could be  purely a result of my limited knowledge of the code and
>>please consider these as my humble attemt at ramping up with the
>>things. If you guys feel any of these notes are useful, i'm willing to
>>submit any needed changes.
>>
>>Client-side
>>---------------
>>1. ExecutionChain.invoke() might need to skip the current phase while
>>calling phase.revoke(), because revoking the handlers in the current
>>phase is already taken care of, inside the Phase.invoke().
>>
>>2. Similarily, the handler.invoke() may have the code to revert the
>>actions in a catch block, thus making the handler.revoke() unnecessary
>>for the *current* handler.
>>
>>3. o.a.axis.engine.Dispatch: This is seemingly being used as handler
>>for receiving the message instead of what its name suggests. The
>>AxisEngine.receive method creates a dispatcher phase with the name
>>"DispatchPhase". I think this should be named as "ReceivingPhase". the
>> Phase class also has two phases named as "DispatchPhase" and
>>"SendPhase", which tend to mean the same but actually being used as
>>symmetrically opposite phases.
>>
>>4. o.a.axis.engine.receive() does not add service-specific phases to
>>the chain, unlike what  executeOutFlow() does.
>>
>>5. o.a.axis.engine.receive() doesn't appear to the opposite of
>>executeOutFlow() both in terms of the name and in its input
>>parameters. May be we can have consistent naming and signature,
>>becuase they seem to do the same stuff, but in opposite order.
>>
>>6. The instance variable registry in AxisEngine classs seems unused,
>>though we can't construct the engine object without passing registry.
>>Mostly we are using the registry contained in MsgCtx for message
>>processing.
>>
>>7. Looks like our SOAP* classes are not implementations for
>>javax.xml.soap.* but something specific to Axis OM. May be its better
>>to move closer to SSAZ as early as possible.
>>    
>>
>
>I can't understand what you meant by specific to OM. SOAP specific OM
>classes will implement only the required stuff. And I will try my level best
>to make all the SOAP specific OM classes, SOAP 1.2 compliant soon.
>  
>
so if there is SOAP 1.1 then it may fail?

i thin kkeeping XML Infoset and SOAP layers is good idea.

what about supporting "new and cool" POX (Plain Old Xml) and more 
RESTful interactions (including those that can be desribed in WSLD with 
HTTP GET/POST bindings)?

alek

>  
>
>>8. We need to have TCK tesing also planned out and in-built into the
>>milestone releases right from the beginning. I can take this up, with
>>my experience with the TCK testing for 1.2.
>>
>>Thats all for now :) And i said at the beginning, all this is strictly
>>my two cents, and could be way off :)
>>
>>- venkat
>>    
>>
>
>
>
>  
>


-- 
The best way to predict the future is to invent it - Alan Kay