An order for an electric conversion of a vintage Porsche just arrived at Greg’s workshop. He follows a script that will implement the transformation of the car. He looks at the order, and sees that the customer bought the 70kWh battery. He picks up the right number of cells, and re-orders more to refill the stock. The batteries are secured in the trunk. Then, he removes the car’s engine, and disposes of it. He fits the electric motor in its place, and proceeds to route wires from the trunk to the engine’s compartment. The control system is then assembled. All these operations are done sequentially by Greg. In a few weeks, the car is ready.
Meanwhile, a few kilometers away, another order for a brand new electric car arrives at Elon’s factory. It should be an obsidian black metallic all-wheel drive with a 85kWh battery, panoramic roof, silver cyclone wheels, black leather seats, carbon fiber décor, black alcantara headliner, autopilot, and subzero weather package. That’s a lot of little independent details.
As soon as the order comes in, several people and robots look at it, and focus on the details that are relevant to them. The wheel guy gets the silver cyclone wheels, and adds it to the assembly line. The engine guy gets the two engines. The interior decor guy gets all the right materials. The multitude of little special tasks get picked up by the actors who can handle them. They don’t need to talk to each other, just to read the order and hand over the results of their work to the assembly line. Then, other agents can pick up those results and assemble them.
Everyone in this picture has a single responsibility (which can be producing the right part, orchestration, or assembly), tasks are easily parallelized, and the whole process is modular and decoupled. It is easy to change anything without fear of breaking the rest of the process.
Greg’s workshop, of course, is an analogy for the classical Web server pipeline, where a request comes in, gets analyzed, routed, processed by a single controller action that implements a fixed algorithm, and then the resulting view model gets rendered by a view.
Elon’s factory is a representation of how Orchard (and DecentCMS) are handling requests: a multitude of small, decoupled agents, work together to compose a Web page. It may seem unfamiliar, if you’re used to a more linear pipeline, but it’s way more flexible, clean, and manageable.
By the way, why are we so often trapping our own minds with vocabulary? The term “pipeline” seems to tell us that there is only one way to handle a request: make it go through a linear series of operations.
[updated]A more accurate expression for non-linear, collaborative processes such as the one Orchard and DecentCMS implement is "actor model", although the actor model has been built to handle concurrency, and as such has slightly different implementations, based on messages and asynchronicity. There is a common pattern at the root of both models, but I'm not sure what a good name would be for it. Please comment if you have an idea.[/updated]
Disclaimer: this is not about cars, the manufacturing of which I know nearly nothing about, it’s a metaphor ;)