Now that the July CTP is public, I can divulge the details of a feature that I added to WCF in April.
In PDC ’05 we showed how you can use WCF extensibility to send “POX” (Plain Old Xml) Messages via our runtime. However, it took some magical incantations to enable. These including setting HttpMappingMode on the HttpTransportBindingElement, and writing a custom encoder that only writes out the body of the Message.
In July CTP, you now get 1st class support for POX-style Messages. To accomplish this, we added new Addressing and Envelope Versions (AddressingVersion.None and EnvelopeVersion.None). I’m also happy to report the obsolescence and removal of HttpMappingMode (nee MapAddressingHeadersToHttpHeaders for those former Beta 1 users who have been following along).
AddressingVersion.None means that your addressing information (To, Action, etc) is transmitted out of band from the Envelope. One example of this type of addressing is BasicHttpBinding — the <To> is sent as the HTTP Request-Uri, and the <Action> is sent out as either the SOAP-Action (in SOAP 1.1), or as a parameter to the content-type (in SOAP 1.2). If a particular binding requires WS-Addressing, then they can throw on Send() for Messages with AddressingVersion.None
EnvelopeVersion applies to the basic structure of the Message. This is where SOAP can come in to play. By default, the EnvelopeVersion of a Message is EnvelopeVersion.Soap12. SOAP 1.2 includes (among other things), support for Headers, and an outer <Envelope> tag. To “wash off” the SOAP from the Message (thanks Don), you should create a Message with EnvelopeVersion.None. When using such Messages, you cannot add any Headers other than <To> and <Action>. <To> and <Action> are “special” since they are intrinsics used by the runtime system. <To> is used by default for addressing dispatch, and <Action> is used by default for Operation dispatch. Some transports (such as our HTTP Transport) will strip these header values out and lift them into their “framing layer” (i.e. the goo we put around a Message to conform to the HTTP protocol).
For our programming model, AddressingVersion and EnvelopeVersion are packaged together into a single MessageVersion that is assigned to a Message or a Binding. Enabling simple POX messaging is now simply a matter of setting up an HTTP binding on your service with a TextEncoder that uses MessageVersion.None (or messageVersion=”none” in config-speak). Viola! No SOAP!
NOTE: see here for more information about the breaking changes between Beta 2 and the June CTP.
Nice info. This is now on http://www.netfxguide.com/guide/wcf.aspx.
That’s progress, but …
” is sent out as either the SOAP-Action”
‘Action’ should go in the HTTP Request-Method if you’re trying to do POX. i.e. it should only be GET, POST, etc..
The case you describe is also possible, if a little trickier. What you’d need to do is write an IClientMessageInterceptor that removes the Action on the outgoing Message and adds an HttpRequestMessageProperty whose Method is GET, POST, etc. For example:
string action = OperationContext.Current.OutgoingMessageHeaders.Action;
OperationContext.Current.OutgoingMessageHeaders.Action = null;
HttpRequestMessageProperty httpRequestProperty = new HttpRequestMessageProperty();
httpRequestProperty.Method = “GET”; // do your custom mapping from Action->Verb here
OperationContext.Current.OutgoingMessageProperties[HttpRequestMessageProperty.Name] = httpRequestProperty;
On the server-side you can write an IDispatchOperationSelector to map from verb->Action for dispatch purposes (see the RSS Toolkit for an example of this)
Pingback: Web Things, by Mark Baker » Blog Archive » links for 2006-08-02
But what if the message contains security tokens? This will happen when the POX service acts as an intermediary and has to route incoming messages from clients to target services. So if the security tokens are removed from the headers then would not the target service fail?