I think I should point out why we say that Sandesha2 depends on functionalities provided by Axis2. Here are some of them,
Operation Dispatching
--------------------------------
Sandesha2 uses AddressingBasedDispatcher of Axis2 to do the operation dispatching of protocol specific messages correctly. Within our module definition file (module.xml) we define some operations (basically two RMInOnlyOperation and RMInOutOperation) and add action mappings for each of the RM protocol message types (for e.g. CreateSequence, Acknowledgement). So after finding the service (probably based on the URL or wsa:To). this mapping will be used to load a suitable operation.
Message pausing and resuming functionality
----------------------------------------------------------------
When handling an incoming or outgoing MessageContext the task of the AxisEngine it to invoke the phases (and the handlers within them) one by one. If any handler set the pause property to 'true' execution stop after that handler, and AxisEngine simply returns from its send/receive method. Currently only state saved are the names of the Phase and the Handler which paused the message. Later when if we call this send/receive method again with the same message context, the phases and handlers before the pause paint will be skipped and only the once after and including the paused handler will be invoked. We use this functionality in many plases. One example is for stopping a application message get send before sending the CS Request and getting the CS Response. Another use is for doing in-order invocation (stopping inocation of message 2 till message 1 arrives).
OM
------
All of the RMElement classes were developed based on OM (Axis2 Object model). (this include all the classes within org.apache.sandesha2.wsrm package) .
Context hierarchy
--------------------------
Sandesha2 uses the context hierarcy of Axis2 in many placese including handlers. One use of this is to pass properties around. Also when doing things like creating response messages (rm specific) and retransmission we do it in the Axis2 way and you will see many references to the context hierarchy classes.
These are just some dependencies that came to my mind. There should be more.
Thanks,
Chamikara
On 12/6/05, Aleksander Slominski <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
>Hi Alek,
>
>
hi Jaliya,
>It is true that we may be able to implement Sandesha on top of JAX-WS
>handler framework, but then IMHO it will be way different to the Sandesha2
>we have now.
>For example, Sandesha2 handle the RM related messages using Axis2's
>operation injection mechanism. In addition we pause and discard all the
>messages specific to modules at the module's phase. This way we can support
>many QoS without working about compatibilities.
>
i must admit i do not understand how policy handling is affecting WS-RM
and requires module phases?
i thought you can get the same (even if limited) functionality just by
configuring handler chain ...
>This is how we expect to
>support WS-SecureConversation and Sandesha together. So if we generalize
>Sandesha2 then we will not get any value from Axis2 for which it is intended
>to operate on.
>
>
adding WS-SecureConv should not be that complicated (?) as WS-RM is
lower level delivery mechanism and WS-SecureConv should be independent
from it?
>So I think that it is better to implement it as a separate project and for
>this we can use Sandesha1 since it does not depend on message pausing or
>operation injection capabilities of the SOAP engine.
>
>
i know that and that is what I tried to ask - is this ability to pause
message processing state (presumably into stable storage) and then
resume it the only feature required?
what are other features besides a generic capability to run a handler
chain required?
thanks,
alek
>
>----- Original Message -----
>From: "Srinath Perera" <[EMAIL PROTECTED]>
>To: < [email protected]>; "Aleksander Slominski"
><[EMAIL PROTECTED]>
>Cc: "Glynn, Eoghan" < [EMAIL PROTECTED]>
>Sent: Tuesday, December 06, 2005 7:55 AM
>Subject: Re: Use of Sandesha in Celtix?
>
>
>Hi Alek;
>mm ..They got a Handler Resolver ..but I doubt to which extent they
>will be a repalcement for phase rules. We should look in to it case by
>case.
>
>I am ok if we have a special JAX-WS relase or something .. but main
>Sandesha should run on Axis2 ..my gut feeling is otherwise we might
>not use Axis2 features to full potential
>
>Thanks
>Srinath
>
>On 12/6/05, Aleksander Slominski <[EMAIL PROTECTED]> wrote:
>
>
>>Srinath Perera wrote:
>>
>>
>>
>>>I list few main archtectural concerns .. there may be more
>>>
>>>1) Context hairachy
>>>2) Phase rules
>>>3) Operation injection
>>>4) Pausing the execution and restarting it
>>>5) possible dependancies on the messaging
>>>
>>>I do not belive it is easy to provide a mapping, and strongly
>>>desagree making Sandesha too work on non Axis2 interface. We design
>>>Axis2 to provide very high level support for SOAP extensions .. they
>>>go in to detail unlikly any spec would provide
>>>
>>>
>>>
>>>
>>i ma be totally wrong but it seems to me that of all those five aspects
>>(4) is critical - everything else can be done with JAXWS or any other
>>handler based framework ... (4) requires ability to "persist" execution
>>context of a chain of handlers (hopefully in a file or a database to
>>make the process _really_ reliable) and then resume the chain if
>>handlers execution from then "freeze" point.
>>
>>thanks,
>>
>>alek
>>
>>
>>
>>>On 12/5/05, Glynn, Eoghan < [EMAIL PROTECTED]> wrote:
>>>
>>>
>>>
>>>
>>>>Hi Sanjiva,
>>>>
>>>>I'd be interested in hearing what you see as the crucial Sandesha2/Axis2
>>>>touch-points that don't have direct JAXWS analogues, just to get a sense
>>>>of what would be involved in layering it over Celtix.
>>>>
>>>>I should declare my interest at this point ... I'm a colleague of
>>>>Andrea's on the Celtix project.
>>>>
>>>>Regards,
>>>>Eoghan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED]]
>>>>>Sent: 04 December 2005 23:39
>>>>>To: Chamikara Jayalath
>>>>>Cc: Smyth, Andrea; [email protected]
>>>>>Subject: Re: Use of Sandesha in Celtix?
>>>>>
>>>>>
>>>>>On Fri, 2005-12-02 at 08:57 +0600, Chamikara Jayalath wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Hi Andrea,
>>>>>>
>>>>>>Many parts of Sandesha2 (e.g. Handlers, Invoker, Sender) have strong
>>>>>>dependencies on Axis2. So you will have to do some work to get them
>>>>>>ported. I think this is the same for Sandesha1.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>Axis2 was carefully designed to allow and support the existence of
>>>>>components such as Sandesha2 which extend Axis2. As such,
>>>>>Sandesha2 has
>>>>>to depend on Axis2 concepts in order to do the best possible RM
>>>>>implementation for Axis2. If we were to have Sandesha2 access Axis2
>>>>>behind some standard interfaces, we'd lose all of those
>>>>>capabilities and
>>>>>instead would have to use a much more muted/weak interface.
>>>>>That doesn't
>>>>>make any sense from Sandesha2's point of view because it
>>>>>can't maximize
>>>>>the capabilities of the SOAP stack its providing RM for.
>>>>>
>>>>>Now, if someone wants to provide a layer over Sandesha2 that makes it
>>>>>JAX-WS compliant that's fine of course. However, it is not fine IMO to
>>>>>make Sandesha2 directly JAX-WS dependent instead of Axis2 dependent
>>>>>because then we'd be losing quality not gaining it.
>>>>>
>>>>>Sanjiva.
>>>>>
>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>>For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>>
>>>
>>>
>>--
>>The best way to predict the future is to invent it - Alan Kay
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
