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 13:01:14 GMT
Figure1 is attached.

On 12/22/05, Saminda Abeyruwan <samindaa@gmail.com> wrote:
>
> 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