Megosztás a következőn keresztül:

WCF REST Custom WebMessageFormat

  • Cikk

When web services was first introduced more than a decade ago, some people had a different understanding about it. We can't blame them since the early explanations were quite vague and it was not until the SOAP standards came to be and matured, that web services were able to be standardized.
However, it was a little late for the standards to mature as some non-standardized implementations have managed to leak to some very large systems that are powering important applications i.e. Telco applications. Not only that, as the years passed, SOAP is also deemed as complicated and heavy with more people moving to the simpler and lighter REST-based approach which is favored by modern Internet and mobile applications.

As the industry standards continue to evolve from SOAP to REST and to whatever next, the legacy non-standardized web-services are posing challenges (if not problems) for the older systems to adapt to the new technologies. With variants such as dumping XML to web pages, to dumping comma-delimited values, systems integration has become a mesh of complicated customized APIs between organizations and partners.

The legacy systems were a chain of systems integrated using .aspx pages to pass parameters and response to each other. The systems use simple comma-delimited response which is not XML or JSON, which poses some challenges to us when we first wanted to use WCF. Here's the illustration of the initial design approach if we are to use WCF to support the legacy systems.

Conveniently naming it the Adapter Interface approach, we thought of creating aspx pages to translate the querystrings into contracts which our WCF services can understand. This method works but at a very large performance cost. As illustrated, the ASPX box is a solid box (which opposed to the transparent SOAP box), which indicates an additional physical tier to relay the call. This causes 2 HTTP hops to the back-end which will degrade the performance. This approach had let us to think that might as well just stick with ASPX.
With some research, we have discovered that we can actually disguise our WCF services to enable aspx-style calls by using REST (webHttpBinding). So we started working on a second approach.

This approach has successfully allow us to pass custom-response strings to our legacy service consumers via our WCF while the consumers assumed that we are still running like aspx pages. Not only that this approach is cleaner, it also improves performance by eliminating the extra ASPX physical tier. However, this approach is not very elegant as it requires us to create 2 service contracts for our services.
The reason is REST standards supports only XML (POX) and JSON but our legacy service consumers do not use those. In order for us to expose our non-standard response strings, we will require to have service contracts that expose a Stream object (also known as WCF REST Raw programming model). This dual contract approach somewhat breaks the WCF promise of configurable endpoints that can support multiple bindings. We would like to have a single service contract that can support a mix of standardized and non-standardized service consumers.
WCF only provides XML and JSON WebMessageFormat. But fortunately with WCF's rich extensibility, I was able to come-out with something to make it more elegant by using the IDispatchMessageFormatter to tap into WCF's processing pipeline and produce a message format that I need. There are 4 classes to build for this solution.

For more details, you can check out our MVP Serena Yeoh’s her blog here .

Comments