Some Changes for Channels and Transports in the June CTP, Part 3
Today's look at recent changes covers two cool new features.
Better support out-of-the-box for building applications in the POX/REST style.
Back in March, I talked about the POX support we added for the February CTP and a bug we found in our implementation of HttpMappingMode. There were two problems in that release. The first problem was the unfortunate functional bug that made it far too easy to shoot yourself in the foot when building an application. The second problem was that the multi-state mapping mode setting was a confusing and clunky way of enabling this architectural style. It was better than having to install an unsupported POX encoder sample on your production machine, but it still was not good.
In June, you can now see our new approach to solving this problem. Support for POX is built into the normal text encoder. Fundamentally, using the POX style means that you want our messaging layer to not add the SOAP and addressing goop that it normally sticks into every outgoing message for you and not require that goop on every incoming message. We already had knobs for controlling how to format the goop in the encoder. Our solution was to add a "none of the above" option to these knobs. Setting MessageVersion to None means taking the "none of the above" option for every part of the message, or equivalently, it means "no goop please".
Better support for using packet routers.
The two major kinds of routers are circuit-based routers and packet-based routers. A circuit-based router affinitizes the incoming and outgoing connections. This makes the router almost transparent to the way we think about connectivity (the router is still not transparent to the way we think about message passing though, for instance transport security is point-to-point). A packet-based router treats everything like a datagram and doesn't care about connections.
Packet routers work well with fire-and-forget messaging. Transports that are inherently request-reply, such as HTTP, don't work so well with packet routers when they need to send back failure notifications. When an HTTP message arrives at a packet router, the router needs to make the reply immediately. Once the message moves on to the next hop, the router forgets everything about the reply connection so there's only one opportunity to send the reply message. Typically, the router just sends back an acknowledgment that the packet was received. However, if an error occurs several hops later, there's no way to route that error notification back to the originator. The router can't make a reply back without a new request.
To solve this problem, we introduced a one-way binding element that tags messages with an indication that they are safe for packet routing. Packet routers can look for this tagging and reject connections that are unsafe rather than mysteriously losing data at some point in the future. A consequence of this is that we removed the "native" one-way support in our HTTP transport and now require you to explicitly put in this binding element when you want one-way HTTP. I've only talked about HTTP in this discussion but the same binding element works with all of our transports to provide shape changing to the one-way messaging pattern.
Next time: Some Changes for Channels and Transports in the June CTP, Part 4
Comments
- Anonymous
June 29, 2006
One of the biggest changes, although hard to recognize as such, is that we had to change the behavior... - Anonymous
July 02, 2006
PingBack from http://blogs.msdn.com/drnick/archive/2006/06/30/651983.aspx - Anonymous
July 05, 2006
First of all, Happy Independence Day to all in the US! I have a lot to list here but I will likely get... - Anonymous
July 06, 2006
A few weeks ago we spent some time thinking about the right way to think about quotas. This metathinking... - Anonymous
July 07, 2006
The autoposter ate today's regular post so I decided to fill this space with a quick Q & A about...