0

I'm extend the WCF transport over a message bus, the request-reply mode works well to me. When I'm implementing the input-output mode I met a problem. The situation is:

1, I created the InputChannel and OutputChannel and let the TransportBindingElement return them.

2, I created a contract interface, which has two methods. One has the attribute said IsOneWay = true, let's say it's Method1; the other was not which named Method2.

3, If I invoked Method1, I can see that it gave me a RequestChannel and ReplyChannel instead of InputChannel and OutputChannel. And the reply channel can receive the WCF message and return the RequestContext back. But the service code was not invoked.

4, If I set IsOneWay = false on Method1, it works well.

4, If I invoked Method2, it works well.

5, I created another service contract which have only one method with IsOneWay = true. If I invoked this method WCF gave me InputChannel and OutputChannel, and it works well (service code executed).

So my question is: 1, If I have a service with IsOneWay = true methods and IsOneWay = false methods, the WCF will give me request-reply channel, is that correct?

2, How can I handle the service invoke, which the method was IsOneWay = true, but also has IsOneWay = false methods in the same service contract?

BTW, I noticed that for the request messages to the IsOneWay = true method, the MessageID was NULL. I set a new ID to the request message but no luck, the service code still wasn't invoked.

Shaun Xu
  • 4,476
  • 2
  • 27
  • 41

2 Answers2

2

Well I finally got the reason and the solution.

The WCF will chose the best channel shape based on the whole service contract, instead of which service operation you invoked. So if I have a service contract with IsOneWay = true and IsOneWay = false methods mixed, WCF will use request-reply mode since it can cover all possible invokes.

Next, when WCF using the request-reply mode to handle the one way message, the reply message will be null. Which means in the RequestContext.Reply method the incoming message from the parameter is null. So we cannot handle it as in the normal request-reply mode (in that mode the reply message shouldn't be null). Now we need to send a blank message to the underlying transportation, to make the server side process continue.

And on the client side, in RequestChannel.Request method we should also handle the blank message we sent from the RequestContext.Reply in this case. Just return null should be OK.

Shaun Xu
  • 4,476
  • 2
  • 27
  • 41
1

You kind of have, in my opinion, a solution which works already - decouple your one way operations from your request-response operations into different service contracts.

The difference in communication patterns between your operations suggests that regardless of whether it is technically possible or not, you should not expose these operations together in the same service.

UPDATE

It sounds from your comment like you are trying to implement sime kind of forwarding service? If so have you read this? https://dzone.com/articles/single-wcf-generic-endpoint-on

Luciox
  • 63
  • 7
tom redfern
  • 30,562
  • 14
  • 91
  • 126
  • Yes, in practice the best way is to have the service only for request-reply and another only for one way. But you know I'm implementing a customized transport layer, which means I'd better support all kinds of service implementation and host. If the WCF allows the user to have request-reply and one-way in one service, I should support it, even though it's not the best way. – Shaun Xu Feb 20 '12 at 09:22
  • Thanks Hugh, but I'm not implementing a routing service. In fact, I'm trying to extend the WCF to use an enterprise message bus as the transport layer. Hence my extension should be able to let the developer run their vary services over my transport. If it's OK to define both IsOneWay = true and false in one service contract, I must support it. And I think the build-in transport, such as HTTP, NET.TCP and MSMQ should all support. – Shaun Xu Feb 21 '12 at 01:00