Fwd: Synapse Model and Unit Test (not truncated!)

[Paul Fremantle <pz...@gmail.com>]

At the moment the Synapse model is that the message is processed by whatever
processors are defined and the processors have to explicitly send on.

I was thinking about ways of making it easier to test, and it occurred to me
that maybe the model where the Synapse engine sends it on would be more
valuable. So then the processors can be tested without (1) mocking up
send(), or (2) without having to set up a network environment, sockets etc.

However, there are two different aspects a processor needs to indicate when
it finishes processing.

Firstly, it can indicate whether or not to stop processing (e.g. the false
response). And then there is the question of whether the message should be
sent or not.

Let me give some use cases:

1) I am a log processor. I don't want to stop processing or stop a message
being sent on.
2) I am a fault processor. I want to stop processing the message (no further
rules/mediators evaluated) but I do want the fault message sent.
3) I am a spam message detector. I want to stop processing the message and I
want to drop it immediately.

I don't know if there is a use case for when the message is not sent but
processing continues. That seems wierd.

Anyway... what about...

boolean process(SynapseMessage sm)

if I return false that means stop processing and send now.
and then if smc.To=null that means dont send the message on. Otherwise do.

Comments?

Paul

Re: Synapse Model and Unit Test (not truncated!)

[ant elder <an...@gmail.com>]

On 11/30/05, Saminda Abeyruwan <sa...@gmail.com> wrote:
>
>
>  Isn't this the time to move it to main trunk and do the imporvements
> there after. {Just a thought :)}
>

I agree 100% with not adding any more function to the prototype code. There
needs to be a clean code base that everyone is happy with, and thats not
happening while new function keeps getting added instead of spending the
time to clean up whats there.

   ...ant

Re: Synapse Model and Unit Test (not truncated!)

[Saminda Abeyruwan <sa...@gmail.com>]

On 11/29/05, Paul Fremantle <pz...@gmail.com> wrote:
>
>
> At the moment the Synapse model is that the message is processed by
> whatever processors are defined and the processors have to explicitly send
> on.
>
> I was thinking about ways of making it easier to test, and it occurred to
> me that maybe the model where the Synapse engine sends it on would be more
> valuable. So then the processors can be tested without (1) mocking up
> send(), or (2) without having to set up a network environment, sockets etc.


+1

Let me give some use cases:
>
> 1) I am a log processor. I don't want to stop processing or stop a message
> being sent on.
> 2) I am a fault processor. I want to stop processing the message (no
> further rules/mediators evaluated) but I do want the fault message sent.
> 3) I am a spam message detector. I want to stop processing the message and
> I want to drop it immediately.
>
> I don't know if there is a use case for when the message is not sent but
> processing continues. That seems wierd.
>
> Anyway... what about...
>
> boolean process(SynapseMessage sm)


At the moment all the processors except SendProcessor uses
SynapseEnvironment to SendBack or SendOn. If SynapseEngine gonna do send on,
which is appropriate at the moment, above method signature is fine.

if I return false that means stop processing and send now.
> and then if smc.To=null that means dont send the message on. Otherwise do.


That would cover the above use cases.

Comments?


Since prior proposal is improve the functionality of Proto3. Isn't this the
time to move it to main trunk and do the imporvements there after. {Just a
thought :)}

Saminda

Re: Synapse Model and Unit Test (not truncated!)

[Vikas <vi...@apache.org>]

Hi, 

    Comments inline.
  ----- Original Message ----- 
  From: Paul Fremantle 
  To: synapse-dev@ws.apache.org 
  Sent: Tuesday, November 29, 2005 11:16 PM
  Subject: Fwd: Synapse Model and Unit Test (not truncated!)



  At the moment the Synapse model is that the message is processed by whatever processors are defined and the processors have to explicitly send on.

  I was thinking about ways of making it easier to test, and it occurred to me that maybe the model where the Synapse engine sends it on would be more valuable. So then the processors can be tested without (1) mocking up send(), or (2) without having to set up a network environment, sockets etc. 

  However, there are two different aspects a processor needs to indicate when it finishes processing.

  Firstly, it can indicate whether or not to stop processing (e.g. the false response). And then there is the question of whether the message should be sent or not. 

  Let me give some use cases:

  1) I am a log processor. I don't want to stop processing or stop a message being sent on. 
  <Vikas> This is a very normal scenario, the usual..Everything is fine type. </Vikas>
  2) I am a fault processor. I want to stop processing the message (no further rules/mediators evaluated) but I do want the fault message sent. 
  <Vikas> In this case the message is sent not to the actual ProviderEndPoint which is being mediated but to the consumer/client which made the request. Something like the OutFaultFlow </Vikas>
  3) I am a spam message detector. I want to stop processing the message and I want to drop it immediately.
  <Vikas> I think we had something along these lines discused in the initial IRCs. Authentication was the base scenario for it. </Vikas>

  I don't know if there is a use case for when the message is not sent but processing continues. That seems wierd. 
  <Vikas> This one would make sense. The Authentication fails, you don't want the message to goto the ProviderEndPoint but would like to log it, count the number of failed requests  (or) unsuccessful requests, etc; </Vikas>

  Anyway... what about... 

  boolean process(SynapseMessage sm)

  if I return false that means stop processing and send now.
  and then if smc.To=null that means dont send the message on. Otherwise do.

  Comments?
  <Vikas> Sounds good, but who does the checks, the sendMediator or the SynapseProcessor ? </Vikas>
  Paul