[EMAIL PROTECTED] wrote:
Hi Alek,
Please see my comments below.
Thanks,
Jaliya
----- Original Message -----
From: "Aleksander Slominski" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Srinath Perera" <[EMAIL PROTECTED]>; <[email protected]>;
<[EMAIL PROTECTED]>; "Eoghan" <[EMAIL PROTECTED]>
Sent: Tuesday, December 06, 2005 11:51 AM
Subject: Re: Use of Sandesha in Celtix?
[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 ..
WS-RM's CreateSequence , TerminateSequnce and other protocol specific
messages all are targetted to the same Web Service and all these messages
have SOAP body elements.
i think that this can be done (with more or less effort) in any SOAP
stack that expose to handlers enough information about SOAP message and
allows to control a message flow and start new flows (for WS-RM operations)
The way we handler them in Axis2 is by means of
adding these operations to the Actual Service by the modules. (Implemntation
of the logic can be either in these new operations or in handler level)
OK but that seems to be independent of QoS?
In Sandesha1 we don't have this option and we use "Provider" to handler the
pausing and resuming since that is the only place where we can stop a
message inside Axis1.
yes - and as far as i can see it is the only *critical* feature needed
for WS-RM implementation that is not present in JAXWS or other SOAP
stack that has handler chains.
In addition, both implementations uses the context hierarchy of the Axis
engine to store information. So IMHO, separation may not be that straight
forward.
well it is all more about setting clear what are hard dependencies and
what are soft ones - good to know if somebody would like try to port
Sandesha2 to another SOAP stack ...
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?
Yes,
ok so we agree :)
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?
We need,
pausing and resuming
Some mechanism to dispatch protocol specific messages to the same service
Context hierarchy (may be able to change)
I am not sure how these features are going to be supported in a generic
handler frame work though.
yes it is tricky but it looks to me that it is really the only
requirement (capability to do pausing and resuming implies some kind of
persistence for handler chain state - as serialization of context of
whatever - details does not really matter ...)
best,
alek
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
--
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]
