Figure1 is attached.

On 12/22/05, Saminda Abeyruwan <[EMAIL PROTECTED]> wrote:
Comments in line.

On 12/22/05, Paul Fremantle < [EMAIL PROTECTED]> 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
[EMAIL PROTECTED]

"Oxygenating the Web Service Platform", www.wso2.com


Attachment: Figure1.png
Description: PNG image

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to