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.


On 5/4/06, Sanjiva Weerawarana <> 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.



To unsubscribe, e-mail:
For additional commands, e-mail:

Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

"Oxygenating the Web Service Platform",