I’ve spent few days trying to figure out why when I change the WS-Addressing information of an outgoing SOAP message from an output WSE filter, the changes are not picked up by the underlying SOAP transport used. Well, after lots of experimentation and an IM discussion with John Bristowe who gave me some good pointers (thanks John), I’ve figured out that WSE does something strange in the way it creates a channel for the outgoing messages.
In WSE, one can send a message using instances of the SoapSender class. The constructor of the class requires endpoint information. This endpoint information is used to create a channel over which the outgoing SoapEnvelope will be created. After the channel is created, the pipeline of custom filters is processed. Even if a filter changes the addressing information in the SoapEnvelope, those changes are not reflected at the already created channel.
A solution is to do the following in your custom filter…
SoapOutputChannel
channel = SoapContext.Current.Channel asSoapOutputChannel;
channel.RemoteEndpoint.Address = epr.Address;
I would have expected the processing of the filter pipeline to be done before the channel and any other transport specific objects were created. I am sure there was a good reason it was done this way.
I am going to talk about the piece of infrastructure I am working on at the moment when I finish the implementation (it still doesn’t work). Hopefully very soon.
There’s a unique energy that comes with starting something new — a blend of excitement,…
As I continued work on BrainExpanded and its MCP service, I came to realize that…
Just over a month ago, I published "Playing with graphs and Neo4j". Back then, it…
After my initial implementation of some BrainExpanded-related ideas on top of dgraph using its GraphQL…
Say hello to the Graph Model Domain Specific Language (GMDSL), created with the help of…
As I wrote in previous posts, the manual recording of memories for BrainExpanded is just…