Today's look at recent changes covers two cool new features. #1: 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". #2: 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
Read More...