WSE Policy Assertions Execution Order analysis

I've been playing with WSE 3 because I wanted to fully understand how Policy Assertions, SoapFilters and the Pipeline work. My tools were: Reflector and a test harness example consisting of a custom Policy Assertion that creates a SoapFilter that logs to an xml file. Note: I've used WSE 3.0.5152 which is the June CTP because I was using VS 2005 Beta 2.

I recommend you reading this post from Mike Taulty so we are all on the same page.

My tests:

  1. The normal execution flow
  2. What happens when an Exception is being thrown from the webservice?
  3. What happens when an Exception is being thrown from a SoapFilter?
  4. Short-circuitingon client-output, client-input, service-input and service-output

I've created some nice drawings to illustrates what is happening in each case. So here we go...

wsep1

wsep2

wsep3

wsep4

Here  I decided to go with reflector because the short-circuiting
was not behaving as I expected, so I found the ProcessInputMessage and
ProcessOutputMessage from the Pipeline class.

ProcessOutputMessage

 using (IEnumerator enumerator1 = ((IEnumerator) this.outputFilters.GetEnumerator()))
{
while (enumerator1.MoveNext())
{
SoapFilter filter1 = enumerator1.get_Current();
SoapFilterResult result1 = filter1.ProcessMessage(envelope);
if (result1 == null)
{
throw new InvalidOperationException(string.Format("SoapFilter of type '{0}' did not return a valid result from ProcessMessage", filter1.GetType().ToString()));
}
if (result1.Stop)
{
flag1 = false;
goto Label_014A;
}
}
}


ProcessInputMessage

using (IEnumerator enumerator1 = ((IEnumerator) this.inputFilters.GetEnumerator()))
{
while (enumerator1.MoveNext())
{
SoapFilter filter1 = enumerator1.get_Current();
SoapFilterResult result1 = filter1.ProcessMessage(envelope);
if (result1 == null)
{
throw new InvalidOperationException(string.Format("SoapFilter of type '{0}' did not return a valid result from ProcessMessage", filter1.GetType().ToString()));
}
if (result1.TargetMethod != null)
{
method1 = result1.TargetMethod;
goto Label_012A;
}
}
}

Note that both methods are using either on the client-side and the service-side. What attracted my attention was that ProcessInputMessage doesn't analyze the result whether is Continue or Stop.
So I would not be able to do any short circuiting when messages get
into the service or the client. A very common use of this is doing
idempotent where I check the message id and reply with a already
processed message stored in a cache.

Am I missing something here?

Anyway, I will try again when WSE gets out on November.

Published: October 01 2005

blog comments powered by Disqus