http://winterdom.com/2007/02/urisinwcftransportscontinued by dæmons be driven Tue, 16 Mar 2010 06:33:03 +0000 http://wordpress.org/?v=2.9.2 hourly 1 http://winterdom.com/2007/02/urisinwcftransportscontinued/comment-page-1#comment-658 Scott Seely Wed, 21 Feb 2007 13:34:50 +0000 http://winterdom.com/2007/02/urisinwcftransportscontinued#comment-658 Headers in config: the <endpoint> configuration element under /system.serviceModel/services/Service can contain <headers>. These are then read in and passed to config. I think you are running into a scenario where static wsdl/policy becomes a good solution. You are designing a multi-hop scenario. Most scenarios talk about point to point communications. You are doing pub/sub (aka WS-Eventing http://www.w3.org/Submission/WS-Eventing/). Early drafts of pub/sub talked about publisher aggregators collecting a set of publishers and then making that information available to potential clients. I think that your publishers need some sort of step during initialization that tells the routers what types of messages will be published so that the consumers find out the types of things they can subscribe to. A simplistic solution for the issues you present is having the router simply get a WSDL/Policy doc from a publisher and then rewrite that doc with the router as the source. I'm assuming that the identity of the published messages doesn't need to appear to be the actual publisher but should appear to be the router. (If you want to discuss in private e-mail: sseely_at_catalystss_dot_com) Headers in config: the <endpoint> configuration element under /system.serviceModel/services/Service can contain <headers>. These are then read in and passed to config.
I think you are running into a scenario where static wsdl/policy becomes a good solution. You are designing a multi-hop scenario. Most scenarios talk about point to point communications. You are doing pub/sub (aka WS-Eventing http://www.w3.org/Submission/WS-Eventing/). Early drafts of pub/sub talked about publisher aggregators collecting a set of publishers and then making that information available to potential clients. I think that your publishers need some sort of step during initialization that tells the routers what types of messages will be published so that the consumers find out the types of things they can subscribe to. A simplistic solution for the issues you present is having the router simply get a WSDL/Policy doc from a publisher and then rewrite that doc with the router as the source. I’m assuming that the identity of the published messages doesn’t need to appear to be the actual publisher but should appear to be the router.
(If you want to discuss in private e-mail: sseely_at_catalystss_dot_com)

]]>