You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by Paul Fremantle <pz...@gmail.com> on 2006/10/19 11:54:27 UTC
enableRM
I've been thinking about RM/Sandesha and Synapse.
>From an RM viewpoint, I think there are differences when we are the
server <proxy> and when we are the client <endpoint>.
So from a server perspective, I guess the only option is whether to
use a persistent or in-memory store. Maybe in the future we could
think about relaying acks instead of storing messages (in other words
we don't persistently store messages, instead we ack them when the
target server has received them). So I think we can leave the server
for the moment.
But from the client perspective, there are a few options:
1) Do we want to make an offer?
2) Do we want a separate listener - at the moment Sandesha doesn't
support two-way RM with an anon endpoint for RM1.0, because its not
really speced. Of course this is really an endpoint setting
independent of RM.
3) Do we want to use RM1.0 or RM1.1
4) [Advanced] Do we want to set an internal SequenceKey? This could be
used to ensure that for example different clients used different
sequences.
5) [Advanced] Do we want to set a sequence expiry?
So I suggest we enhance our <enableRM> tag to include:
<enableRM spec="1.0|1.1" offer="true|false">
(Both those should be optional. For spec I suggest the default is 1.0.
For offer I suggest the default is false.
We can add extras later - this seems the basic.
In addition I think we need to add a useSeparateListener="true|false"
attribute to <endpoint>.
What have I missed?
Thoughts?
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: enableRM
Posted by Paul Fremantle <pz...@gmail.com>.
> > So from a server perspective, I guess the only option is whether to
> > use a persistent or in-memory store. Maybe in the future we could
> > think about relaying acks instead of storing messages (in other words
> > we don't persistently store messages, instead we ack them when the
> > target server has received them). So I think we can leave the server
> > for the moment.
>
> Hmm. Interesting point. But if the synapse server craches it will loose the
> data of the sequence. Which may be needed to continue that sequence when the
> system comes back up. So even though the in-memory server may be ecceptable
> for now, i think the long term aim should be for a permanent storage based
> one.
+1 for the persistent store.
As for the "relaying" model, you could imagine Synapse on a router
with a very small persistent store - just enough to persist the
sequence state but not the messages. In this case it might be bridging
from JMS to RM, and the RM agent would simply ack the message once the
JMS transactionally accepted it. If the Synapse server crashed, it
would reload the sequence state and carryon.
> > But from the client perspective, there are a few options:
> >
> > 1) Do we want to make an offer?
>
> Think this should be the default. To minimize the number of messages
> transfered.
Yes, I think 2-way scenarios are more common than 1-way.
>
> > 2) Do we want a separate listener - at the moment Sandesha doesn't
> > support two-way RM with an anon endpoint for RM1.0, because its not
> > really speced. Of course this is really an endpoint setting
> > independent of RM.
> >
> > 3) Do we want to use RM1.0 or RM1.1
> > 4) [Advanced] Do we want to set an internal SequenceKey? This could be
> > used to ensure that for example different clients used different
> > sequences.
>
>
> We must. AFAIK different clients will be using the same Synapse client side
> instance. Sandesha without knowing this may try to put messages from
> different clients into the same sequence if they are targetted at the same
> endpoint. So Synapse has to use sequenceKeys to make sure that the messages
> from different clients go in different sequences.
Yes I agree.
But here is another nice scenario. I have two Synapses acting as
gateways. I just want one sequence holding them together and they
multiplex lots of traffic from each side over that sequence.
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: enableRM
Posted by Paul Fremantle <pz...@gmail.com>.
> > So from a server perspective, I guess the only option is whether to
> > use a persistent or in-memory store. Maybe in the future we could
> > think about relaying acks instead of storing messages (in other words
> > we don't persistently store messages, instead we ack them when the
> > target server has received them). So I think we can leave the server
> > for the moment.
>
> Hmm. Interesting point. But if the synapse server craches it will loose the
> data of the sequence. Which may be needed to continue that sequence when the
> system comes back up. So even though the in-memory server may be ecceptable
> for now, i think the long term aim should be for a permanent storage based
> one.
+1 for the persistent store.
As for the "relaying" model, you could imagine Synapse on a router
with a very small persistent store - just enough to persist the
sequence state but not the messages. In this case it might be bridging
from JMS to RM, and the RM agent would simply ack the message once the
JMS transactionally accepted it. If the Synapse server crashed, it
would reload the sequence state and carryon.
> > But from the client perspective, there are a few options:
> >
> > 1) Do we want to make an offer?
>
> Think this should be the default. To minimize the number of messages
> transfered.
Yes, I think 2-way scenarios are more common than 1-way.
>
> > 2) Do we want a separate listener - at the moment Sandesha doesn't
> > support two-way RM with an anon endpoint for RM1.0, because its not
> > really speced. Of course this is really an endpoint setting
> > independent of RM.
> >
> > 3) Do we want to use RM1.0 or RM1.1
> > 4) [Advanced] Do we want to set an internal SequenceKey? This could be
> > used to ensure that for example different clients used different
> > sequences.
>
>
> We must. AFAIK different clients will be using the same Synapse client side
> instance. Sandesha without knowing this may try to put messages from
> different clients into the same sequence if they are targetted at the same
> endpoint. So Synapse has to use sequenceKeys to make sure that the messages
> from different clients go in different sequences.
Yes I agree.
But here is another nice scenario. I have two Synapses acting as
gateways. I just want one sequence holding them together and they
multiplex lots of traffic from each side over that sequence.
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: enableRM
Posted by Paul Fremantle <pz...@gmail.com>.
> > So from a server perspective, I guess the only option is whether to
> > use a persistent or in-memory store. Maybe in the future we could
> > think about relaying acks instead of storing messages (in other words
> > we don't persistently store messages, instead we ack them when the
> > target server has received them). So I think we can leave the server
> > for the moment.
>
> Hmm. Interesting point. But if the synapse server craches it will loose the
> data of the sequence. Which may be needed to continue that sequence when the
> system comes back up. So even though the in-memory server may be ecceptable
> for now, i think the long term aim should be for a permanent storage based
> one.
+1 for the persistent store.
As for the "relaying" model, you could imagine Synapse on a router
with a very small persistent store - just enough to persist the
sequence state but not the messages. In this case it might be bridging
from JMS to RM, and the RM agent would simply ack the message once the
JMS transactionally accepted it. If the Synapse server crashed, it
would reload the sequence state and carryon.
> > But from the client perspective, there are a few options:
> >
> > 1) Do we want to make an offer?
>
> Think this should be the default. To minimize the number of messages
> transfered.
Yes, I think 2-way scenarios are more common than 1-way.
>
> > 2) Do we want a separate listener - at the moment Sandesha doesn't
> > support two-way RM with an anon endpoint for RM1.0, because its not
> > really speced. Of course this is really an endpoint setting
> > independent of RM.
> >
> > 3) Do we want to use RM1.0 or RM1.1
> > 4) [Advanced] Do we want to set an internal SequenceKey? This could be
> > used to ensure that for example different clients used different
> > sequences.
>
>
> We must. AFAIK different clients will be using the same Synapse client side
> instance. Sandesha without knowing this may try to put messages from
> different clients into the same sequence if they are targetted at the same
> endpoint. So Synapse has to use sequenceKeys to make sure that the messages
> from different clients go in different sequences.
Yes I agree.
But here is another nice scenario. I have two Synapses acting as
gateways. I just want one sequence holding them together and they
multiplex lots of traffic from each side over that sequence.
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: enableRM
Posted by Chamikara Jayalath <ch...@gmail.com>.
H Paul,
Some comments below.
On 10/19/06, Paul Fremantle <pz...@gmail.com> wrote:
>
> I've been thinking about RM/Sandesha and Synapse.
>
> From an RM viewpoint, I think there are differences when we are the
> server <proxy> and when we are the client <endpoint>.
>
> So from a server perspective, I guess the only option is whether to
> use a persistent or in-memory store. Maybe in the future we could
> think about relaying acks instead of storing messages (in other words
> we don't persistently store messages, instead we ack them when the
> target server has received them). So I think we can leave the server
> for the moment.
Hmm. Interesting point. But if the synapse server craches it will loose the
data of the sequence. Which may be needed to continue that sequence when the
system comes back up. So even though the in-memory server may be ecceptable
for now, i think the long term aim should be for a permanent storage based
one.
But from the client perspective, there are a few options:
>
> 1) Do we want to make an offer?
Think this should be the default. To minimize the number of messages
transfered.
2) Do we want a separate listener - at the moment Sandesha doesn't
> support two-way RM with an anon endpoint for RM1.0, because its not
> really speced. Of course this is really an endpoint setting
> independent of RM.
>
> 3) Do we want to use RM1.0 or RM1.1
4) [Advanced] Do we want to set an internal SequenceKey? This could be
> used to ensure that for example different clients used different
> sequences.
We must. AFAIK different clients will be using the same Synapse client side
instance. Sandesha without knowing this may try to put messages from
different clients into the same sequence if they are targetted at the same
endpoint. So Synapse has to use sequenceKeys to make sure that the messages
from different clients go in different sequences.
5) [Advanced] Do we want to set a sequence expiry?
>
> So I suggest we enhance our <enableRM> tag to include:
>
> <enableRM spec="1.0|1.1" offer="true|false">
>
> (Both those should be optional. For spec I suggest the default is 1.0.
> For offer I suggest the default is false.
>
> We can add extras later - this seems the basic.
>
> In addition I think we need to add a useSeparateListener="true|false"
> attribute to <endpoint>.
>
> What have I missed?
>
> Thoughts?
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
Re: enableRM
Posted by Chamikara Jayalath <ch...@gmail.com>.
H Paul,
Some comments below.
On 10/19/06, Paul Fremantle <pz...@gmail.com> wrote:
>
> I've been thinking about RM/Sandesha and Synapse.
>
> From an RM viewpoint, I think there are differences when we are the
> server <proxy> and when we are the client <endpoint>.
>
> So from a server perspective, I guess the only option is whether to
> use a persistent or in-memory store. Maybe in the future we could
> think about relaying acks instead of storing messages (in other words
> we don't persistently store messages, instead we ack them when the
> target server has received them). So I think we can leave the server
> for the moment.
Hmm. Interesting point. But if the synapse server craches it will loose the
data of the sequence. Which may be needed to continue that sequence when the
system comes back up. So even though the in-memory server may be ecceptable
for now, i think the long term aim should be for a permanent storage based
one.
But from the client perspective, there are a few options:
>
> 1) Do we want to make an offer?
Think this should be the default. To minimize the number of messages
transfered.
2) Do we want a separate listener - at the moment Sandesha doesn't
> support two-way RM with an anon endpoint for RM1.0, because its not
> really speced. Of course this is really an endpoint setting
> independent of RM.
>
> 3) Do we want to use RM1.0 or RM1.1
4) [Advanced] Do we want to set an internal SequenceKey? This could be
> used to ensure that for example different clients used different
> sequences.
We must. AFAIK different clients will be using the same Synapse client side
instance. Sandesha without knowing this may try to put messages from
different clients into the same sequence if they are targetted at the same
endpoint. So Synapse has to use sequenceKeys to make sure that the messages
from different clients go in different sequences.
5) [Advanced] Do we want to set a sequence expiry?
>
> So I suggest we enhance our <enableRM> tag to include:
>
> <enableRM spec="1.0|1.1" offer="true|false">
>
> (Both those should be optional. For spec I suggest the default is 1.0.
> For offer I suggest the default is false.
>
> We can add extras later - this seems the basic.
>
> In addition I think we need to add a useSeparateListener="true|false"
> attribute to <endpoint>.
>
> What have I missed?
>
> Thoughts?
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
Re: enableRM
Posted by Chamikara Jayalath <ch...@gmail.com>.
H Paul,
Some comments below.
On 10/19/06, Paul Fremantle <pz...@gmail.com> wrote:
>
> I've been thinking about RM/Sandesha and Synapse.
>
> From an RM viewpoint, I think there are differences when we are the
> server <proxy> and when we are the client <endpoint>.
>
> So from a server perspective, I guess the only option is whether to
> use a persistent or in-memory store. Maybe in the future we could
> think about relaying acks instead of storing messages (in other words
> we don't persistently store messages, instead we ack them when the
> target server has received them). So I think we can leave the server
> for the moment.
Hmm. Interesting point. But if the synapse server craches it will loose the
data of the sequence. Which may be needed to continue that sequence when the
system comes back up. So even though the in-memory server may be ecceptable
for now, i think the long term aim should be for a permanent storage based
one.
But from the client perspective, there are a few options:
>
> 1) Do we want to make an offer?
Think this should be the default. To minimize the number of messages
transfered.
2) Do we want a separate listener - at the moment Sandesha doesn't
> support two-way RM with an anon endpoint for RM1.0, because its not
> really speced. Of course this is really an endpoint setting
> independent of RM.
>
> 3) Do we want to use RM1.0 or RM1.1
4) [Advanced] Do we want to set an internal SequenceKey? This could be
> used to ensure that for example different clients used different
> sequences.
We must. AFAIK different clients will be using the same Synapse client side
instance. Sandesha without knowing this may try to put messages from
different clients into the same sequence if they are targetted at the same
endpoint. So Synapse has to use sequenceKeys to make sure that the messages
from different clients go in different sequences.
5) [Advanced] Do we want to set a sequence expiry?
>
> So I suggest we enhance our <enableRM> tag to include:
>
> <enableRM spec="1.0|1.1" offer="true|false">
>
> (Both those should be optional. For spec I suggest the default is 1.0.
> For offer I suggest the default is false.
>
> We can add extras later - this seems the basic.
>
> In addition I think we need to add a useSeparateListener="true|false"
> attribute to <endpoint>.
>
> What have I missed?
>
> Thoughts?
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
Re: enableRM
Posted by Paul Fremantle <pz...@gmail.com>.
Jaliya
> > But from the client perspective, there are a few options:
> >
> > 1) Do we want to make an offer?
> Not a must but if the client sends it we need to accept it.
+1. There seems to be a situation with Indigo where you need to send
an offer if there is going to be 2-way RM. So having a way of forcing
Sandesha to send an offer is important.
> >
> > 2) Do we want a separate listener - at the moment Sandesha doesn't
> > support two-way RM with an anon endpoint for RM1.0, because its not
> > really speced. Of course this is really an endpoint setting
> > independent of RM.
> >
> My idea in this aspect is yes. I am still not sure why we need RM if the
> messages are strictly request/response and almost real time.
So in RM1.1 we have the MakeConnection model, which allows an
asynchronous message interaction over HTTP.
> In addition as you have mentioned in the below it is always good to support
> the use of a listener that is available (say the RM Client is running inside
> some container)
Yes
> > 3) Do we want to use RM1.0 or RM1.1
> >
> > 4) [Advanced] Do we want to set an internal SequenceKey? This could be
> > used to ensure that for example different clients used different
> > sequences.
> +1.
>
> >
> > 5) [Advanced] Do we want to set a sequence expiry?
> >
> Could you please explain a bit more?
I'm talking about setting: <wsrm:Expires ...> xs:duration
</wsrm:Expires> in the CS message. Actually this is a setting that
applies to the server as well. Basically I might want to set a short
expiry duration for some sequences.
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: enableRM
Posted by Paul Fremantle <pz...@gmail.com>.
Jaliya
> > But from the client perspective, there are a few options:
> >
> > 1) Do we want to make an offer?
> Not a must but if the client sends it we need to accept it.
+1. There seems to be a situation with Indigo where you need to send
an offer if there is going to be 2-way RM. So having a way of forcing
Sandesha to send an offer is important.
> >
> > 2) Do we want a separate listener - at the moment Sandesha doesn't
> > support two-way RM with an anon endpoint for RM1.0, because its not
> > really speced. Of course this is really an endpoint setting
> > independent of RM.
> >
> My idea in this aspect is yes. I am still not sure why we need RM if the
> messages are strictly request/response and almost real time.
So in RM1.1 we have the MakeConnection model, which allows an
asynchronous message interaction over HTTP.
> In addition as you have mentioned in the below it is always good to support
> the use of a listener that is available (say the RM Client is running inside
> some container)
Yes
> > 3) Do we want to use RM1.0 or RM1.1
> >
> > 4) [Advanced] Do we want to set an internal SequenceKey? This could be
> > used to ensure that for example different clients used different
> > sequences.
> +1.
>
> >
> > 5) [Advanced] Do we want to set a sequence expiry?
> >
> Could you please explain a bit more?
I'm talking about setting: <wsrm:Expires ...> xs:duration
</wsrm:Expires> in the CS message. Actually this is a setting that
applies to the server as well. Basically I might want to set a short
expiry duration for some sequences.
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: enableRM
Posted by Paul Fremantle <pz...@gmail.com>.
Jaliya
> > But from the client perspective, there are a few options:
> >
> > 1) Do we want to make an offer?
> Not a must but if the client sends it we need to accept it.
+1. There seems to be a situation with Indigo where you need to send
an offer if there is going to be 2-way RM. So having a way of forcing
Sandesha to send an offer is important.
> >
> > 2) Do we want a separate listener - at the moment Sandesha doesn't
> > support two-way RM with an anon endpoint for RM1.0, because its not
> > really speced. Of course this is really an endpoint setting
> > independent of RM.
> >
> My idea in this aspect is yes. I am still not sure why we need RM if the
> messages are strictly request/response and almost real time.
So in RM1.1 we have the MakeConnection model, which allows an
asynchronous message interaction over HTTP.
> In addition as you have mentioned in the below it is always good to support
> the use of a listener that is available (say the RM Client is running inside
> some container)
Yes
> > 3) Do we want to use RM1.0 or RM1.1
> >
> > 4) [Advanced] Do we want to set an internal SequenceKey? This could be
> > used to ensure that for example different clients used different
> > sequences.
> +1.
>
> >
> > 5) [Advanced] Do we want to set a sequence expiry?
> >
> Could you please explain a bit more?
I'm talking about setting: <wsrm:Expires ...> xs:duration
</wsrm:Expires> in the CS message. Actually this is a setting that
applies to the server as well. Basically I might want to set a short
expiry duration for some sequences.
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: enableRM
Posted by Jaliya Ekanayake <jn...@gmail.com>.
Hi Paul,
Some thought inline.
Thanks,
Jaliya
----- Original Message -----
From: "Paul Fremantle" <pz...@gmail.com>
To: <sy...@ws.apache.org>; <sa...@ws.apache.org>
Sent: Thursday, October 19, 2006 5:54 AM
Subject: enableRM
> I've been thinking about RM/Sandesha and Synapse.
>
> From an RM viewpoint, I think there are differences when we are the
> server <proxy> and when we are the client <endpoint>.
>
> So from a server perspective, I guess the only option is whether to
> use a persistent or in-memory store. Maybe in the future we could
> think about relaying acks instead of storing messages (in other words
> we don't persistently store messages, instead we ack them when the
> target server has received them). So I think we can leave the server
> for the moment.
>
> But from the client perspective, there are a few options:
>
> 1) Do we want to make an offer?
Not a must but if the client sends it we need to accept it.
>
> 2) Do we want a separate listener - at the moment Sandesha doesn't
> support two-way RM with an anon endpoint for RM1.0, because its not
> really speced. Of course this is really an endpoint setting
> independent of RM.
>
My idea in this aspect is yes. I am still not sure why we need RM if the
messages are strictly request/response and almost real time.
In addition as you have mentioned in the below it is always good to support
the use of a listener that is available (say the RM Client is running inside
some container)
> 3) Do we want to use RM1.0 or RM1.1
>
> 4) [Advanced] Do we want to set an internal SequenceKey? This could be
> used to ensure that for example different clients used different
> sequences.
+1.
>
> 5) [Advanced] Do we want to set a sequence expiry?
>
Could you please explain a bit more?
> So I suggest we enhance our <enableRM> tag to include:
>
> <enableRM spec="1.0|1.1" offer="true|false">
>
> (Both those should be optional. For spec I suggest the default is 1.0.
> For offer I suggest the default is false.
>
> We can add extras later - this seems the basic.
>
> In addition I think we need to add a useSeparateListener="true|false"
> attribute to <endpoint>.
>
> What have I missed?
>
> Thoughts?
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: enableRM
Posted by Jaliya Ekanayake <jn...@gmail.com>.
Hi Paul,
Some thought inline.
Thanks,
Jaliya
----- Original Message -----
From: "Paul Fremantle" <pz...@gmail.com>
To: <sy...@ws.apache.org>; <sa...@ws.apache.org>
Sent: Thursday, October 19, 2006 5:54 AM
Subject: enableRM
> I've been thinking about RM/Sandesha and Synapse.
>
> From an RM viewpoint, I think there are differences when we are the
> server <proxy> and when we are the client <endpoint>.
>
> So from a server perspective, I guess the only option is whether to
> use a persistent or in-memory store. Maybe in the future we could
> think about relaying acks instead of storing messages (in other words
> we don't persistently store messages, instead we ack them when the
> target server has received them). So I think we can leave the server
> for the moment.
>
> But from the client perspective, there are a few options:
>
> 1) Do we want to make an offer?
Not a must but if the client sends it we need to accept it.
>
> 2) Do we want a separate listener - at the moment Sandesha doesn't
> support two-way RM with an anon endpoint for RM1.0, because its not
> really speced. Of course this is really an endpoint setting
> independent of RM.
>
My idea in this aspect is yes. I am still not sure why we need RM if the
messages are strictly request/response and almost real time.
In addition as you have mentioned in the below it is always good to support
the use of a listener that is available (say the RM Client is running inside
some container)
> 3) Do we want to use RM1.0 or RM1.1
>
> 4) [Advanced] Do we want to set an internal SequenceKey? This could be
> used to ensure that for example different clients used different
> sequences.
+1.
>
> 5) [Advanced] Do we want to set a sequence expiry?
>
Could you please explain a bit more?
> So I suggest we enhance our <enableRM> tag to include:
>
> <enableRM spec="1.0|1.1" offer="true|false">
>
> (Both those should be optional. For spec I suggest the default is 1.0.
> For offer I suggest the default is false.
>
> We can add extras later - this seems the basic.
>
> In addition I think we need to add a useSeparateListener="true|false"
> attribute to <endpoint>.
>
> What have I missed?
>
> Thoughts?
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: enableRM
Posted by Jaliya Ekanayake <jn...@gmail.com>.
Hi Paul,
Some thought inline.
Thanks,
Jaliya
----- Original Message -----
From: "Paul Fremantle" <pz...@gmail.com>
To: <sy...@ws.apache.org>; <sa...@ws.apache.org>
Sent: Thursday, October 19, 2006 5:54 AM
Subject: enableRM
> I've been thinking about RM/Sandesha and Synapse.
>
> From an RM viewpoint, I think there are differences when we are the
> server <proxy> and when we are the client <endpoint>.
>
> So from a server perspective, I guess the only option is whether to
> use a persistent or in-memory store. Maybe in the future we could
> think about relaying acks instead of storing messages (in other words
> we don't persistently store messages, instead we ack them when the
> target server has received them). So I think we can leave the server
> for the moment.
>
> But from the client perspective, there are a few options:
>
> 1) Do we want to make an offer?
Not a must but if the client sends it we need to accept it.
>
> 2) Do we want a separate listener - at the moment Sandesha doesn't
> support two-way RM with an anon endpoint for RM1.0, because its not
> really speced. Of course this is really an endpoint setting
> independent of RM.
>
My idea in this aspect is yes. I am still not sure why we need RM if the
messages are strictly request/response and almost real time.
In addition as you have mentioned in the below it is always good to support
the use of a listener that is available (say the RM Client is running inside
some container)
> 3) Do we want to use RM1.0 or RM1.1
>
> 4) [Advanced] Do we want to set an internal SequenceKey? This could be
> used to ensure that for example different clients used different
> sequences.
+1.
>
> 5) [Advanced] Do we want to set a sequence expiry?
>
Could you please explain a bit more?
> So I suggest we enhance our <enableRM> tag to include:
>
> <enableRM spec="1.0|1.1" offer="true|false">
>
> (Both those should be optional. For spec I suggest the default is 1.0.
> For offer I suggest the default is false.
>
> We can add extras later - this seems the basic.
>
> In addition I think we need to add a useSeparateListener="true|false"
> attribute to <endpoint>.
>
> What have I missed?
>
> Thoughts?
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org