You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Sanjiva Weerawarana <sa...@opensource.lk> on 2006/05/04 19:52:40 UTC
proposed change to
We currently have the semantic that <send/> implicitly is an end of
execution of the current ruleset. I'd like to propose we change that:
First of all, the name is not intuitive of that behavior. OK so we can
fix the name, but I'd like to separate the two actions: that of sending
a message and that of finishing execution.
What I suggest is we change <send/> to be just that: send the message
per the semantics of send. When send is done, if there are any other
rules around they keep executing.
Now, I don't want to force everyone to write <send/> either (which is
what we have now and that's cool). So how about saying that if the
ruleset completes without the message being sent, then there's an
implied <send/> at the end .. that means things work exactly as the way
it does now for when <send/> is NOT there, but if its there then one can
continue and send it to another place for example.
Note that this also has the nice feature that you can use it to send the
message, then change some stuff and send it elsewhere or send an event
somewhere or whatever.
Thoughts?
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: proposed change to
Posted by Saminda Abeyruwan <sa...@gmail.com>.
On 5/4/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>
> We currently have the semantic that <send/> implicitly is an end of
> execution of the current ruleset. I'd like to propose we change that:
>
> First of all, the name is not intuitive of that behavior. OK so we can
> fix the name, but I'd like to separate the two actions: that of sending
> a message and that of finishing execution.
>
> What I suggest is we change <send/> to be just that: send the message
> per the semantics of send. When send is done, if there are any other
> rules around they keep executing.
currently <send/> new SynapseMessage and set the response msg and inject to
the env for further processing. if to do prior we would have to change it.
Now once <send/> done we have the new response msg. Are we continuing the
rest of the ruleset with the new msg ?.
Now, I don't want to force everyone to write <send/> either (which is
> what we have now and that's cool). So how about saying that if the
> ruleset completes without the message being sent, then there's an
> implied <send/> at the end .. that means things work exactly as the way
> it does now for when <send/> is NOT there, but if its there then one can
> continue and send it to another place for example.
>
> Note that this also has the nice feature that you can use it to send the
> message, then change some stuff and send it elsewhere or send an event
> somewhere or whatever.
So we may expect more than one <send/> per ruleset per msg. ? if so that's
pretty cool.
How does Synapse know the the end o f the ruleset per given msg?
Thoughts?
>
> Sanjiva.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
Re: proposed change to
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
s/callout/invoke/
:)
Sanjiva.
On Mon, 2006-05-08 at 09:10 +0100, Paul Fremantle wrote:
> Asankha
>
> This is quite cool, but I'm concerned about putting a synchronous
> blocking into the flow. I'm also concerned we are getting very close
> to BPEL. I think it would be really good if we started thinking about
> how Synapse fits with a BPEL server and stateful/process integration.
>
> Paul
>
> On 5/8/06, Asankha C. Perera <as...@wso2.com> wrote:
> How about the introduction of a <callout/> mediator, which
> could be used to make an external service call and store the
> response into the Synapse Context?
>
> If one is to write a mediation configuration to accept a
> message, perform a lookup from another external service, and
> perform routing or transformation etc. of the original message
> based on the result received, the above would make things more
> simpler. i.e. the response received would be available just
> after the invocation of the <callout> instead of having to
> write configuration to process the response again from the top
> level <rules> (i.e. main mediator).
>
> asankha
>
>
>
> Paul Fremantle wrote:
> > I think what you are saying is exactly what I just said!
> >
> > On 5/5/06, Sanjiva Weerawarana <sanjiva@opensource.lk >
> > wrote:
> > On Fri, 2006-05-05 at 14:56 +0100, Paul Fremantle
> > wrote:
> > > Well I think we need two behaviours. One is to
> > explicitly send the
> > > current message on and do no more processing (kind
> > of like "goto
> > > end"). The second is to take a copy of the message
> > and send that
> > > somewhere without affecting the current flow.
> > However in both cases
> > > the response message gets handled as a newly
> > injected message into
> > > Synapse. In the second case you have to configure
> > Synapse to do
> > > something with the extra response.
> >
> > I don't see this- if we do what I suggested (and I
> > thought you agreed
> > with earlier in this thread!), then we have <send/>
> > basically being
> > built in. However, if the built-in <send/> is
> > reached, then the flow
> > stops. If you hit an explicit <send/>, then the flow
> > is not stopped.
> >
> > There's no "new" message created after an explicit
> > <send/> .. the
> > current message continues to get processed. (Maybe
> > there's another
> > <send/> sending it somewhere else; who knows.)
> >
> > Response has nothing to do with this discussion- if
> > the explicit <send/>
> > causes another messsage to be injected to Synapse,
> > well, cool- but that
> > has nothing to do with the current message path thru
> > Synapse.
> >
> > Sanjiva.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail:
> > synapse-dev-help@ws.apache.org
> >
> >
> >
> >
> > --
> > 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
>
>
>
> --
> 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: proposed change to
Posted by Paul Fremantle <pz...@gmail.com>.
Asankha
This is quite cool, but I'm concerned about putting a synchronous blocking
into the flow. I'm also concerned we are getting very close to BPEL. I think
it would be really good if we started thinking about how Synapse fits with a
BPEL server and stateful/process integration.
Paul
On 5/8/06, Asankha C. Perera <as...@wso2.com> wrote:
>
> How about the introduction of a <callout/> mediator, which could be used
> to make an external service call and store the response into the Synapse
> Context?
>
> If one is to write a mediation configuration to accept a message, perform
> a lookup from another external service, and perform routing or
> transformation etc. of the original message based on the result received,
> the above would make things more simpler. i.e. the response received would
> be available just after the invocation of the <callout> instead of having to
> write configuration to process the response again from the top level <rules>
> (i.e. main mediator).
>
> asankha
>
>
>
> Paul Fremantle wrote:
>
> I think what you are saying is exactly what I just said!
>
> On 5/5/06, Sanjiva Weerawarana <sanjiva@opensource.lk > wrote:
> >
> > On Fri, 2006-05-05 at 14:56 +0100, Paul Fremantle wrote:
> > > Well I think we need two behaviours. One is to explicitly send the
> > > current message on and do no more processing (kind of like "goto
> > > end"). The second is to take a copy of the message and send that
> > > somewhere without affecting the current flow. However in both cases
> > > the response message gets handled as a newly injected message into
> > > Synapse. In the second case you have to configure Synapse to do
> > > something with the extra response.
> >
> > I don't see this- if we do what I suggested (and I thought you agreed
> > with earlier in this thread!), then we have <send/> basically being
> > built in. However, if the built-in <send/> is reached, then the flow
> > stops. If you hit an explicit <send/>, then the flow is not stopped.
> >
> > There's no "new" message created after an explicit <send/> .. the
> > current message continues to get processed. (Maybe there's another
> > <send/> sending it somewhere else; who knows.)
> >
> > Response has nothing to do with this discussion- if the explicit <send/>
> > causes another messsage to be injected to Synapse, well, cool- but that
> > has nothing to do with the current message path thru Synapse.
> >
> > Sanjiva.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
>
>
> --
> 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
>
--
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
Re: proposed change to
Posted by Paul Fremantle <pz...@gmail.com>.
I think what you are saying is exactly what I just said!
On 5/5/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>
> On Fri, 2006-05-05 at 14:56 +0100, Paul Fremantle wrote:
> > Well I think we need two behaviours. One is to explicitly send the
> > current message on and do no more processing (kind of like "goto
> > end"). The second is to take a copy of the message and send that
> > somewhere without affecting the current flow. However in both cases
> > the response message gets handled as a newly injected message into
> > Synapse. In the second case you have to configure Synapse to do
> > something with the extra response.
>
> I don't see this- if we do what I suggested (and I thought you agreed
> with earlier in this thread!), then we have <send/> basically being
> built in. However, if the built-in <send/> is reached, then the flow
> stops. If you hit an explicit <send/>, then the flow is not stopped.
>
> There's no "new" message created after an explicit <send/> .. the
> current message continues to get processed. (Maybe there's another
> <send/> sending it somewhere else; who knows.)
>
> Response has nothing to do with this discussion- if the explicit <send/>
> causes another messsage to be injected to Synapse, well, cool- but that
> has nothing to do with the current message path thru Synapse.
>
> Sanjiva.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
--
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
Re: proposed change to
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Fri, 2006-05-05 at 14:56 +0100, Paul Fremantle wrote:
> Well I think we need two behaviours. One is to explicitly send the
> current message on and do no more processing (kind of like "goto
> end"). The second is to take a copy of the message and send that
> somewhere without affecting the current flow. However in both cases
> the response message gets handled as a newly injected message into
> Synapse. In the second case you have to configure Synapse to do
> something with the extra response.
I don't see this- if we do what I suggested (and I thought you agreed
with earlier in this thread!), then we have <send/> basically being
built in. However, if the built-in <send/> is reached, then the flow
stops. If you hit an explicit <send/>, then the flow is not stopped.
There's no "new" message created after an explicit <send/> .. the
current message continues to get processed. (Maybe there's another
<send/> sending it somewhere else; who knows.)
Response has nothing to do with this discussion- if the explicit <send/>
causes another messsage to be injected to Synapse, well, cool- but that
has nothing to do with the current message path thru Synapse.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: proposed change to
Posted by Paul Fremantle <pz...@gmail.com>.
Well I think we need two behaviours. One is to explicitly send the current
message on and do no more processing (kind of like "goto end"). The second
is to take a copy of the message and send that somewhere without affecting
the current flow. However in both cases the response message gets handled as
a newly injected message into Synapse. In the second case you have to
configure Synapse to do something with the extra response.
Paul
On 5/5/06, Saminda Abeyruwan <sa...@gmail.com> wrote:
>
>
>
> On 5/5/06, Paul Fremantle <pz...@gmail.com> wrote:
> >
> > Sanjiva
> >
> > We discussed this a while ago. I'm very much in favour of the default
> > behaviour to be "send". There are some added benefits to this.
> >
> > 1) Unit testing is easier.... push in a message and see what the output
> > message is without having to set up an endpoint to receive the message.
> > 2) More easily embeddable, for example inside an Axis2 server or client,
> > because you may not wish to actually "send" the message if the endpoint is
> > local.
> >
> > As regards the <send/>, then if we implement the above, it makes much
> > more sense that <send/> doesn't stop the flow. If you want that then
> > <send/><drop/> does just as well.
> >
>
> after <send/> we have the new response msg. Are we going to continue the
> rest of the ruleset if exist with the new msg or the old one ?
>
> Paul
> >
> >
> > On 5/4/06, Sanjiva Weerawarana <sanjiva@opensource.lk > wrote:
> >
> > > We currently have the semantic that <send/> implicitly is an end of
> > > execution of the current ruleset. I'd like to propose we change that:
> > >
> > > First of all, the name is not intuitive of that behavior. OK so we can
> > >
> > > fix the name, but I'd like to separate the two actions: that of
> > > sending
> > > a message and that of finishing execution.
> > >
> > > What I suggest is we change <send/> to be just that: send the message
> > > per the semantics of send. When send is done, if there are any other
> > > rules around they keep executing.
> > >
> > > Now, I don't want to force everyone to write <send/> either (which is
> > > what we have now and that's cool). So how about saying that if the
> > > ruleset completes without the message being sent, then there's an
> > > implied <send/> at the end .. that means things work exactly as the
> > > way
> > > it does now for when <send/> is NOT there, but if its there then one
> > > can
> > > continue and send it to another place for example.
> > >
> > > Note that this also has the nice feature that you can use it to send
> > > the
> > > message, then change some stuff and send it elsewhere or send an event
> > > somewhere or whatever.
> > >
> > > Thoughts?
> > >
> > > Sanjiva.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > 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
> >
>
>
--
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
Re: proposed change to
Posted by Saminda Abeyruwan <sa...@gmail.com>.
On 5/5/06, Paul Fremantle <pz...@gmail.com> wrote:
>
> Sanjiva
>
> We discussed this a while ago. I'm very much in favour of the default
> behaviour to be "send". There are some added benefits to this.
>
> 1) Unit testing is easier.... push in a message and see what the output
> message is without having to set up an endpoint to receive the message.
> 2) More easily embeddable, for example inside an Axis2 server or client,
> because you may not wish to actually "send" the message if the endpoint is
> local.
>
> As regards the <send/>, then if we implement the above, it makes much more
> sense that <send/> doesn't stop the flow. If you want that then
> <send/><drop/> does just as well.
>
after <send/> we have the new response msg. Are we going to continue the
rest of the ruleset if exist with the new msg or the old one ?
Paul
>
>
> On 5/4/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>
> > We currently have the semantic that <send/> implicitly is an end of
> > execution of the current ruleset. I'd like to propose we change that:
> >
> > First of all, the name is not intuitive of that behavior. OK so we can
> > fix the name, but I'd like to separate the two actions: that of sending
> > a message and that of finishing execution.
> >
> > What I suggest is we change <send/> to be just that: send the message
> > per the semantics of send. When send is done, if there are any other
> > rules around they keep executing.
> >
> > Now, I don't want to force everyone to write <send/> either (which is
> > what we have now and that's cool). So how about saying that if the
> > ruleset completes without the message being sent, then there's an
> > implied <send/> at the end .. that means things work exactly as the way
> > it does now for when <send/> is NOT there, but if its there then one can
> > continue and send it to another place for example.
> >
> > Note that this also has the nice feature that you can use it to send the
> > message, then change some stuff and send it elsewhere or send an event
> > somewhere or whatever.
> >
> > Thoughts?
> >
> > Sanjiva.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: synapse-dev-help@ws.apache.org
> >
> >
>
>
> --
> 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
>
Re: proposed change to
Posted by Paul Fremantle <pz...@gmail.com>.
Sanjiva
We discussed this a while ago. I'm very much in favour of the default
behaviour to be "send". There are some added benefits to this.
1) Unit testing is easier.... push in a message and see what the output
message is without having to set up an endpoint to receive the message.
2) More easily embeddable, for example inside an Axis2 server or client,
because you may not wish to actually "send" the message if the endpoint is
local.
As regards the <send/>, then if we implement the above, it makes much more
sense that <send/> doesn't stop the flow. If you want that then
<send/><drop/> does just as well.
Paul
On 5/4/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>
> We currently have the semantic that <send/> implicitly is an end of
> execution of the current ruleset. I'd like to propose we change that:
>
> First of all, the name is not intuitive of that behavior. OK so we can
> fix the name, but I'd like to separate the two actions: that of sending
> a message and that of finishing execution.
>
> What I suggest is we change <send/> to be just that: send the message
> per the semantics of send. When send is done, if there are any other
> rules around they keep executing.
>
> Now, I don't want to force everyone to write <send/> either (which is
> what we have now and that's cool). So how about saying that if the
> ruleset completes without the message being sent, then there's an
> implied <send/> at the end .. that means things work exactly as the way
> it does now for when <send/> is NOT there, but if its there then one can
> continue and send it to another place for example.
>
> Note that this also has the nice feature that you can use it to send the
> message, then change some stuff and send it elsewhere or send an event
> somewhere or whatever.
>
> Thoughts?
>
> Sanjiva.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
--
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