Santosh Benjamin's Weblog

I’m delighted to announce that MockingBird v2.0 is now available as a Release Candidate.   This is the long awaited ( ) version that adds a WCF Message Interceptor that now sits alongside the HttpHandler and uses the same generic simulation engine.

I owe this release pretty much entirely to the stellar contributions of Bram Veldhoen who wrote the entire WCF interceptor and dived into the Unity based dependency resolution and fixed a number of issues with threading and concurrency and even introduced me to the awesome (and scary) Microsoft CHESS concurrency testing tool which I’m still trying to get my head around.

Basically we have now added 2 things to the mix namely a “SimulatorService” (.svc) endpoint that implements a generic contract. The message exchange patterns are modeled after the BizTalk WCF adapters and the current set is : IOneWay, IOneWayDuplex,  IOneWaySession, ITwoWay, ITwoWayVoid and the corresponding Async interfaces (for example ITwoWayAsync ). The SimulatorService.svc can be hosted in IIS or in a ‘SimulatorHost’ console application (which also supports http and https). Although both are installed, it is not possible to run them simultaneously because of port sharing issues, so if you want to run the SimulatorHost ensure that the website that contains the ASMX and SVC is stopped.

The high level design of the system is shown in the following diagram

(If you are not familiar with it from previous versions, essentially it consists of a generic HttpHandler and a generic WCF message interceptor that can pick up any message sent to the endpoint and to respond to this message it looks at a model XML file that instructs it how to respond. All it needs to function straight out of the box is the model file which is very simple to setup)

In terms of the physical layout MockingBird is manifested as follows

• A virtual directory : This contains the SimulatorService.svc file (the WCF message interceptor)  and in the bin folder we have the Interceptor.dll which contains HttpHandler (implemented as a class that inherits the IHttpHandler interface rather than an .ashx) . The bin folder also contains the WCF Simulator Host application and a simulator host tester application. The .svc and the httpHandler both share the web.config and as explained in the technical documentation, there are a number of other .config files
• A folder (usually in Program Files) containing the Service Studio GUI application.

Please note that in the RC, due to the single package and co-location of the WCF SimulatorHost with the web application, the 4 config files are duplicated in the root of the web app as well as in the bin folder. This is intentional because the system looks for ‘sibling’ configuration files and for web apps they need to be in the root whereas for the Simulator Host they need to be co-located with the .exe.config which happens to be in the bin folder of the web app.

In v2 RTM we plan to split this up so that the simulator host is installed in a separate folder (under Program Files). This will avoid the confusion that may appear when the user sees the config files in 2 adjacent folders, however, the apps still need their own copies of the configuration files. Perhaps in a future version, we will build some advanced centralized configuration so that irrespective of the simulator chosen, the configuration is always taken from a single central location.

I hope you find this new version useful. Looking forward to the bug reports and feedback. I hope to be able to get the RTM out in a month or so (approx 20 April 2o10). Do check it out and let us know what you think of it.