Ignoring Bad Requests
I have a one-way operation that processes requests and can sometimes fail. When the operation fails, the client receives a fault notification. How can I make the operation ignore the bad requests and not send back a fault notification?
This question indicates some confusion over what it means to be a one-way operation. There are actually several different concepts that you could label as one-way.
- An operation contract with a void return type is one-way in the sense that there is no normal application data to be sent back as part of the operation response.
- An operation contract declared as IsOneWay is one-way in the sense that execution of the operation does not result in an application message.
- An operation contract instantiated over a binding offering up IInputChannel is one-way in the sense that there is no path for communicating an operation response back to the client.
As you get further down the list, the definition of one-way becomes more encompassing. The first type of one-way prevents sending normal application data but permits sending an operation response and infrastructure messages. The second type of one-way prevents sending any type of application-level response but permits sending infrastructure messages. The third type of one-way prevents sending any kind of message.
If a fault notification is getting back to the client, then we know that the question is implying the first type of one-way operation. That's the only type that permits returning an exceptional application response. Changing the service to use one of the later types of one-way operations would prevent those fault notifications from being returned.
Next time: Detecting ASP.NET Compatibility
Comments
Anonymous
November 01, 2007
When authorizing a client, how do I tell the difference between a connection with anonymous securityAnonymous
November 02, 2007
My answer to this question would have been to issue the request asynchrously (say with a client proxy generated with svcutil /a) so as to avoid blocking the client. Do you think this is a good or bad design? Thanks :)Anonymous
November 02, 2007
Hi Mike, Blocking the client isn't the problem so calling the method asynchronously doesn't help. Being asynchronous only affects the local programming model. It doesn't change what the operation does or returns. In this case, it would just push the fault notification to the method completion.