synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saminda Abeyruwan <samin...@gmail.com>
Subject Re: Send on send back and other behaviour
Date Thu, 22 Dec 2005 12:58:49 GMT
Comments in line.

On 12/22/05, Paul Fremantle <pzfreo@gmail.com> wrote:
>
>
> The change I propose I already posted about. The feeling I have is that
> the current model of dropping messages unless they are explicitly sent on is
> probably a little confusing.


Now we have to picture this in terms of http return status. [Figure1]
As synapse is over Axis2, Synapse has the total domination over 200 OK, 202
OK and 500 Internal Server Error http POST status.
Simply terms --> with (200 OK) status POST will have a body, (202 OK) POST
does not have body, (500 Internal Server Error) POST should have a SOAP
fault, Since our medium is SOAP.

I propose that we change the behaviour as follows:
>
> 1) boolean process(SynapseMessage sm) :
>  if the response is true, continue processing.


{Synapse not completed yet}


If the response is false: check sm. If sm.getTo==null, then drop,
>

{Should send 202 OK to the initiator of the message}


> if sm.getTo!=null then send on.

 In this case message will mediate to a service, and expect an response,
Response is again either 202 OK, 200 OK and 4xx/5xx. if it's 202 OK,
Response doesn't contain any body and what initiator of the message will see
is 202 OK.

If the response is 200 OK, the reasons is again push into the Synapse Engine
for further processing.

If the repose is 4xx/5xx then what initiator must see is 5xx or Synapse can
consume the response message and do some further processing.

Anyway at the end of a "session" initiator should see a response status.

>
> 2) So then we could add the following two XML config elements:
>
>   <drop/> -- would set the To address to null and then return false. This
> drops the message immediately and ends processing


{what should be the status be ? 202 OK}

  <sendNow/> - this ends processing and sends the message on now.
> Effectively this simply returns false.


{In this case initiator might see 200/202/500}

3) This model seems to me simpler for unit test. Rather than having to fake
> up a special send() in the Axis2SynapseEnvironment, you can simply call a
> processor and check the SM and return values to see if they match what you
> expect.
>
> 4) I also think this would make it easier to embed Synapse in a
> "co-locate" model with Axis2, because the implicit send could actually be
> used to simply dispatch the message to the right Axis2 service instead of
> always opening up new connection.


Paul please  explain  act 4.

I think this is a more logical model, but I'd appreciate your thoughts. Both
> models are similar, so it just comes down to the simplest for the user. I
> think its better that you say <drop> if you want to drop it rather than it
> dropping it by default.


what will be the behavior of
<engage-addressing-in/>
<drop/>
is this valid way of writing rules

Thank you. Really appreciate your comments on prior.

Saminda

Paul
>
>
> --
> 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
>

Mime
View raw message