Our time spent working with the Wholesale Markets arm of a major UK banking group is worthy of mention as it demonstrates the company's ability not only to apply prior knowledge and experience to a business requirement, but to actively seek out new knowledge in order to solve previously unseen problems.
One such issue was that the Pricing Data Services team had released a API, which was exposed over WCF, to other teams within the bank who were using it to obtain pricing data. When they wanted to change the API in a way which was not backwards compatible, they were faced with an issue of how to arrange for the many projects using the API to simultaneously upgrade to the new version of the API. The solution which the company proposed and implemented was to intercept calls which use the old contract and transform them into a call to the new contract on-the-fly, using an IDispatchMessageInspector. By implementing this interface, WCF allows us to both inspect and modify messages after they've been received by the service but, crucially, before they've been forwarded to an operation. We implemented a solution which inspected the incoming request to establish which version of the WCF contract it was targeting, and use XSLT to transform any requests targeting the old contract into a request to the new contract. This approach is the subject of a blog, Implementing IDispatchMessageInspector, by the company's principal consultant.
Another interesting requirement of this project was a plain text expression parser. The API exposed by the Pricing Data Services team allowed callers to pass in query expressions which could be used to specify exactly what data they were looking to obtain. These expressions were in the form of an object model representing a logical expression. For example:
That's a fairly simply example, and its obvious what the expression is trying to do. When the criteria because more complex, with expressions nested within each other, it becomes quite cumberson for the caller to define their query criteria in this way. Hence it was suggested that the caller be able to specify it as plain text, similar to a WHERE clause in SQL:
Enter Coco/R, a complier generator developed at the University of Linz in Austria. It allows you to define the syntax and grammar of an arbitrary language, and have it generate a parser for that language. This clearly sounds like Coco/R was doing all the heavy lifting with respect to this requirement, and in many ways it was, but defining the language was a challenge in itself - as was debugging that language by debugging the C# parser generated to parse it.
⮜ Previous: Case Study 4 New Tax Credits Project at Microsoft UK |