This example from 2006 sounds like the forces introduction to a new pattern: BuildBothSimulators or SimulateBothEnds
-- ChrisGarrod

This is a practice I've convinced myself to adopt simply because I've been bitten hard so many times when I didn't do it. Whenever you're building a messaging system (especially of the point-to-point variety, but this applies to all topologies) where both ends of a conversation expect data in a particular format to arrive in a particular location, you find yourself in the painful situation where it's often necessary to have one side fully up and running before the other side can be debugged. This is especially true in cases where you are performing some kind of DataReassembly and a single "conversation" may span multiple messages.

Now, a very common practice for Messaging systems is to build a "simulator" of the other end of the conversation so that you don't have to have the other side available at all times. For instance, imagine that you're building a Java web system that has to pull data from some CICS transactions. It's handy to build a "CICS Simulator" while building your Java system so that you're not always pounding CICS every time you're running a test. This especially useful since it's often difficult to "undo" things on the mainframe side or return the mainframe back to its original state.

Now, the problem is that I've often found that the OTHER side of the conversation is usually experiencing nearly as many problems as the "client" is. Most CICS systems aren't built with messaging in mind and when you add a messsaging "adapter" (either custom built or commercial) you usually have some bugs to work out with it.

So, what I've started doing is building TWO simulators every time I'm working on a messaging system. Both of them are bone-head stupid - they just look at the incoming message and then use some part of it as a Key to look up a corresponding "value" out of a hashtable and send that value as a response. The data can be stored in either flat files or a simple database table. This allows you to debug both ends more or less independently and then try hooking them together after you've gotten them working against the simulator. Of course, you also want to try hooking the simulators together to make sure that works first. :)

Also - it's often useful to have a "message recorder" to capture things to place into the flat files - once you have the code working on one end, you can record the responses to make more test cases for the other.

-- KyleBrown