Dave is beginning to work on a new email application. Eventually, the server will need to expose a mail API, so the browser can query for recent messages and upload new ones. However, that will require email expertise, and Dave wants to focus on the user-interface in the browser for now. Thus, he hard-codes the responses he'd like in a "fake" server-side service. This allows him to proceed with user-interface development while his colleague takes care of the real server implementation.

How can you develop the browser script in parallel with the services it uses?

Develop the browser application against "fake" web services that simulate the actual services used in production. A Simulation Service is typically a hard-coded response that ignores any input parameters. So instead of:

    $taxRate = calculateTaxRate($userId, $year);
    print $taxRate;

a simulation service would just say:

    print "0.1235";

It's also possible to do all this in a browser. If you use a library to perform ???, you could make the implementation produce a hard-coded response, and ignore the server altogether.

In some cases, you might make the service more flexible, e.g. it can expose an operation to let the browser tell it what to output later on.

Simulation Service decouples the server and browser components of the application. Once the interface is defined, each can be developed in parallel. Moreover, this pattern paves the way for an agile process for building the application, based loosely on concepts such as Test-Driven Design (TDD) and lean manufacturing.

Conventional web development is usually a bottom-up approach: first comes the database, then the data layer to access it, then the business components on top of that, and finally the user-interface. This sequence might seem like the most logical thing to do, given the dependency relationships involved. But the problem is that the user-interface is really the whole point of the application, so there's a good argument for starting there instead. For a given feature, flesh out the user-interface, and use that work to drive the service interface. So instead of designing the server-side first and forcing the browser script to work with whatever interface arises, let the needs of the browser script drive the interface design. Consequently, the service will not only contain the precise functionality required by the browser, but also expose it with the most suitable interface.

Starting development in the browser sounds like a good idea until you realise the browser depends on the service, which doesn't yet exist! That's where a Simulation Service comes in: it lets you define what the service offers, not how the service achieves it. As you develop the browser script, you'll continue to come across refinements to the service - an extra operation here, a different response format there. In each case, changing the Simulation Service is usually as simple as editing the hard-coded response. Once you're confident with the requirements for the Service, you - or someone else - can go build the real thing.

Another application is in “Browser-Side Test”s. When testing a browser component, it's important to test only the component itself, and not the services it depends on. Imagine you're testing a browser component that renders news arriving from an RSS web service. An automated test could then interrogate the DOM and run a bunch of assertions to ensure it was formatted correctly. But if the component uses the real service, the resulting DOM will reflect the news of the hour. A human could manually verify it, but automation wouldn't be possible. A hard-coded response would eliminate that problem, allowing the assertions to be consistent with the simulated RSS. Furthermore, there's no dependence on the real implementation - no matter how complex the actual search algorithm, the rendering component will always be tested on its own merit.

The Ajax Pattern Reader runs against a couple of “Cross-Domain Proxy” services. They fetch information from the AjaxPatterns.org website and returning them in a format easily parsed by the browser. For development purposes, the Basic version uses Simulation Service.

The first service produces a “Plain-Text Message” containing the patterns in a pipe-separated list. A hand-created simulation is used instead of fetching the page from ajaxpatterns.org, parsing the HTML, and reformatting it.

    Periodic Refresh|||One-Second Spotlight|||Slider

For comparison, the real service outputs a list looks similar, but is much longer, and, of course, not hard-coded.

    Ajax Stub|||Browser-Side Cache|||Browser-Side Templating||| ... |||XML Message|||XMLHttpRequest Call

Similarly, there's a simulation of the summary service, whose job is to produce an “HTML Message” summarising a given pattern. The simulation includes some rudimentary logic to make the response vary according to the input:

    <?  $patternName = urlDecode($_GET["patternName"]); ?>
      <h1><?= $patternName ?></h1>
    <?  if ($patternName=="Periodic Refresh") { ?>
        With periodic refresh, it's all about the timer.
    <?  } else if ($patternName=="Slider") { ?>
       <p>The slider slides from left to right.</p>
       ...
    <?  } else {
        print ("Text goes here.");
      }
   
    ?>

The output from the real service is in the same format, but as with the list service, it's fetched from AjaxPatterns real-time.