{"id":123,"date":"2006-06-06T17:41:52","date_gmt":"2006-06-07T00:41:52","guid":{"rendered":"http:\/\/kennyw.com\/indigo\/123"},"modified":"2006-06-06T17:41:52","modified_gmt":"2006-06-07T00:41:52","slug":"building-a-composite-transport","status":"publish","type":"post","link":"https:\/\/kennyw.com\/?p=123","title":{"rendered":"Building a "Composite" Transport"},"content":{"rendered":"

I’ve often written about how to write custom channels; transports in particular. In all of the examples I’ve given, the same transport is used for both sending and receiving messages (i.e. HTTP out, HTTP in). This parallelism fails in certain scenarios. For example, WS-Discovery<\/a> defines a pattern where you send out a UDP Multicast probe (a broadcast request to find a peer), and expect (one or more) HTTP unicast responses back.<\/p>\n

Constructing a binding for this scenario requires three pieces:<\/p>\n

    \n
  1. An outgoing transport<\/li>\n
  2. An incoming transport<\/li>\n
  3. A correlation mechanism to tie the request to the response<\/li>\n<\/ol>\n

    For the transports, you need a BindingElement<\/code> that returns the outgoing transport from BuildChannelFactory<\/code> and the incoming transport from BuildChannelListener<\/code>. One way of doing this is with a CompositeTransportBindingElement<\/strong>. A CompositeTransportBindingElement uses two bindings to build its runtime components. For example, you can pass in a binding that consists of OneWayBindingElement + HttpTransportBindingElement. Or one that contains UdpBindingElement.<\/p>\n

    For correlation, if you add CompositeDuplexBindingElement<\/code> to the stack, you can configure a ClientBaseAddress and Service Model will provide correlation using WS-Addressing. You could also provide correlation yourself (which is actually a good topic for later this week :))<\/p>\n

    The relevant pieces of CompositeTransportBindingElement (posted here<\/a>) are:<\/p>\n

    class<\/code> CompositeTransportBindingElement\n        : <\/code>TransportBindingElement<\/code>\n{\n    <\/code>Binding<\/code> channelBinding;\n    <\/code>Binding<\/code> listenerBinding;\n\n<\/code>    public<\/code> CompositeTransportBindingElement(\n        Binding channelBinding,\n        Binding listenerBinding)\n    {\n        this.channelBinding = channelBinding;\n        this.listenerBinding = listenerBinding;\n    }<\/code>\n\n    public override<\/code> IChannelFactory<TChannel>\n             BuildChannelFactory<TChannel>(<\/code>BindingContext<\/code> context)\n    {<\/code>\n        return<\/code> channelBinding.BuildChannelFactory<TChannel>(\n            context.BindingParameters);\n    }<\/code>\n\n    public override<\/code> IChannelListener<TChannel>\n            BuildChannelListener<TChannel>(<\/code>BindingContext<\/code> context)\n    {<\/code>\n        return<\/code> listenerBinding.BuildChannelListener<TChannel>(\n            context.ListenUriBaseAddress,\n            context.ListenUriRelativeAddress,\n            context.ListenUriMode,\n            context.BindingParameters);\n    }\n}<\/code>\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
    I’ve often written about how to write custom channels; transports in particular. In all of the examples I’ve given, the same transport is used for both sending and receiving messages (i.e. HTTP out, HTTP in). This parallelism fails in certain scenarios. For example, WS-Discovery defines a pattern where you send out a UDP Multicast probe […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[],"class_list":["post-123","post","type-post","status-publish","format-standard","hentry","category-indigo"],"_links":{"self":[{"href":"https:\/\/kennyw.com\/index.php?rest_route=\/wp\/v2\/posts\/123","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/kennyw.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kennyw.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kennyw.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/kennyw.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=123"}],"version-history":[{"count":0,"href":"https:\/\/kennyw.com\/index.php?rest_route=\/wp\/v2\/posts\/123\/revisions"}],"wp:attachment":[{"href":"https:\/\/kennyw.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=123"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kennyw.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=123"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kennyw.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=123"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}