The Orchard Way

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 ;)

8 Comments

  • Well said! Judging by the title, I was expecting some kind of manifesto here, but good enough;)
    Graph sounds pretty nice, altough maybe a bit too technical. What'd you think about "processing tree"? More expressive imo.

  • mm, I don't know, that seems to imply a root, that diverges into many branches. It doesn't necessarily capture everything that's going on: messages are broadcast, small agents hook onto those, emit other messages, and in the end you have one result.

  • i suspect a single word will not do unless one invents such a sesquipedalian for that purpose.

    to extend the metaphor, let's introduce Greg' and Elon' prime and constrain both as computer neophytes.

    both will have learning curves but Greg' will have much more to learn and build since Elon' will have off the shelf Orchard components from which to pick and choose.

    however, perhaps it's a bit of apples to oranges here since Greg' may be creating a less generic custom application for which Orchard may be only a partial fit while Elon' is creating a much more general application for which Orchard already has the right mix of Red Delicious, Golden Delicious, Northern Spy, and Granny Smith apples.

  • Ah, that's a good point, but my argument would be precisely that those principles can be implemented more generally than within the constraints of Orchard. Imagine an evolution of MVC that would be more compositional, and that could be a good foundation not just for a CMS, but also for any custom application.

  • http://en.wikipedia.org/wiki/Actor_model

  • Also:

    http://actor-framework.org/

  • Ah, great, thanks Dusan. To be clear, I'm not claiming originality. This is indeed very old, and even in CMS, Drupal was doing it ten years before us. I'll update the post to point to the Wikipedia page.

  • Great post. Thanks Bertrand!

Comments have been disabled for this content.