Posted by haroldcarr
on April 9, 2009 at 10:36 AM PDT
Clear back in August 2007 Arun Gupta wrote a blog entry with the
title "wsHttpDualBinding - a non-interoperable binding". In point of
fact, that binding is interoperable. My current entry explains the details.
In August 2007 Arun Gupta wrote a blog entry with the title
"wsHttpDualBinding - a non-interoperable binding" .
That was written during our learning curve. It turns out that
the wsDualHttpBinding (which is the correct name, the title reversed
two words) is interoperable. The details are somewhat subtle, as
I explain below.
wsDualHttpBinding is .NET's name for addressable client
interactions. "Addressable clients" means that responses are sent to
a service, logically on the client side, which receives the responses
as requests, rather than sending the response on the connection that
made the request
wsDualHttpBinding is a .NET declaration that can be applied to any
.NET contract (not just the duplex contract discussed in Arun's blog,
which I will say more about below). WSDLs generated from
wsDualHttpBinding are standard. They contain addressing assertions
that indicate responses are "nonanonymous"---in other words, sent to a
specific address, rather than sent on the "backchannel" (the
connection on which the request was made).
When a client invokes an operation of a wsDualHttpBinding-based
service, the client side web service stack will provide a
"replyTo" address that is nonanonymous. .NET has automated this process,
so the client will automatically have a "response receiving" endpoint
ready. In Metro, one would build such an endpoint by hand.
Since we are talking about responses that implies that
wsDualHttpBinding is suited for two-way messages (even though
Arun's entry shows one-way message, which might confuse the issue).
Arun's blog example uses .NET duplex contract. That contract is
non-interoperable. The WSDL generated from duplex contract contains
output only operations. This is incompletely specified in the WSDL
1.1 specification (i.e., the specification mentions output-only but
does not give enough specifics to be normative). The .NET duplex
contract is basically a link between two one-way contracts. It
enables the service to decide which method on the callback interface
The confusion in Arun's entry arises because it is mixing
two things: wsDualHttpBinding and duplex contract
The above should clarify that wsDualHttpBinding is
ps: One-way messages are a necessary ingredient in the duplex
contract. Also, the callback contract half of a duplex contract must
have the IsOneWay attribute.
pps: One of the MSFT assertions for the wsDualHttpBinding is named
ow:OneWay and the customBinding equivalent of wsDualHttpBinding
ppps: All the one-way mentions in the original blog might obscure
the real issue: the difference between wsDualHttpBinding and duplex