Published Thursday, April 26, 2007 4:08 PM by mtaulty

"Orcas" Workflow: wsHttpContextBinding and netTcpContextBinding

I was thinking about the two bindings that look to be present with the WF bits in Fx 3.5 "Orcas" Beta 1 which are wsHttpContextBinding and netTcpContextBinding. This is purely me experimenting with the bits so apply a large(r) pinch of salt.

These are interesting to me in that (from the name) one of them is built on a duplex transport and one of them isn't. This prompted me to take me previous workflow and alter it to do;

i.e. introduce a serious delay in between receiving the request message and returning the reply and this causes problems for the wsHttpContextBinding because the HTTP response doesnt' come back in time so the client times out. It causes no trouble to the netTcpContextBinding which doesn't have the notion of a "response" as such.

It's funny to me that HTTP and it's request-response pattern still surfaces all over the place and causes pain (I remember reading this a long time ago and it still rings in my ears) and this seems to be an example of it.

In some ways it's more noticeable in Workflow because we know that in Workflow it's extremely likely that the Receive activity itself will be asynchronous and will release the Workflow scheduler's thread back to it the moment that it begins waiting for the WCF message to arrive so we have the weird (but not uncommon in today's web world) situation of perhaps something like;

    1. Workflow scheduler thread enters Receive Activity
    2. Receive Activity presumably (I haven't checked but I'd be willing to bet) sits on a Workflow Queue waiting for its message to arrive via WCF
    3. Message arrives
    4. Receive Activity presumably schedules up its child activities for execution
    5. Receive Activity returns response message when its child activities have completed or perhaps returns the fault message if the child activities fail

The weird thing in the HTTP case is that from step 3 to step 5 the client has effectively set a timer going during which it is prepared to wait for a response. Once that timer expires, the HTTP bits will return a timeout.

All this left me wondering why it's wsHttpContextBinding rather than wsDualHttpContextBinding that seems to ship in the box as that seems to be more analogous to netTcpContextBinding.