4

I have a WPF client that makes calls to 2 WCF services.

One service is for querying only and one service is for commands (CQS pattern).

How should I make the calls to the commands service ?

I read somewhere that all the operations in the command service must be 'One-Way', because they should not return any values. And that if something went wrong - the operation should throw a 'FaultException' to the client.

But if the commands are all One-Way - what do I do in the client ?

Say I have an 'AddProduct' window in the WPF client, and I enter information and press 'Save'.

I now call 'AddProduct(Product)' in the service, but :

  1. Should it close the window ?
  2. Should it wait for 10 seconds to see if there wasn't any FaultException ?
  3. Should the operation not be 'One-Way' ? If so - should all operations in the command service return some type of generic 'Result' object with 'succeeded' or 'failed' ?
  4. If section 3 is 'Yes' - should I call the service in a seperate thread and 'disable' all the controls on the window until I get a response back from the service ?

Thanks.

John Miner
  • 893
  • 1
  • 15
  • 32

2 Answers2

1

I would say option 3 is the way to go, but you probably do not need the generic Result object to communicate errors to the client. As you might know, exceptions are not serialized in the SOAP message so you won't get any of the usual .NET exceptions on the client side. On the other hand, you can still take advantage of SOAP Faults by catching FaultException on the client. Accordingly, if no exceptions were caught on the client, then everything went well.

For more information about fault exceptions and how you can use them to your benefit, take a look at:

Specifying and Handling Faults in Contracts and Services

Kassem
  • 8,116
  • 17
  • 75
  • 116
  • So if I understand correctly - I need all operations to NOT be One-Way, and all should return VOID. If an operation has faulted - it should return a 'FaultException', otherwise - the client knows the operation was performed correctly. – John Miner May 12 '12 at 22:02
  • So this also means that the calls should be done in a background thread - so I don't hang the UI thread in the WPF client app. right ? – John Miner May 12 '12 at 22:02
  • 1
    Correct. You definitely shouldn't hang the UI thread for user-experience purposes. – Kassem May 13 '12 at 07:01
1

I think using On-Way is fine but you have to be aware of some one-way call characteristic. If you care and can handle service exceptions then #4 is fine option.

One Way message - Once the client issues the call, WCF generates the request message but no correlated message will be ever returned to the client. Any exceptions thrown on the service side will not make it to the client.

One thing that you should have on is the reliability on your service so side so that you can insure that request has been delivered to the service.

When there is no transport session (basic or wsHttp binding) if exception occurs during the call of one-way operation client will be unaffected and it can continue sending calls on the same proxy instance.

If there is a presence of transport session - service side exception will fault the channel hence client will not be able to re-use proxy for sending more calls. This can give you an option to discover if something went wrong on the server side (but not what went wrong). Although, if service is using a FaultContracts you can still get into situation where client is unaware that something went wrong.

When service throws an exception listed in service side fault contract this will not fault the communication channel hence the client using one-way contract cannot detect communication failure.

Petar Vučetin
  • 3,555
  • 2
  • 22
  • 31
  • You said : Although, if service is using a FaultContracts you can still get into situation where client is unaware that something went wrong........ Why do you say this ? can you explain more ? – John Miner May 12 '12 at 21:57
  • A FaultException is delivered to the client as a Fault message. With one-way you are explicitly saying there is no response message - that includes a fault message. So the client will make the request and move on, it won;t wait for a response message (standard or fault). Therefore, the client will not see an error even if the service experiences one and throws a FaultException – Richard Blewett May 13 '12 at 10:44