Thanks for your comment.

This blog posting was excerpted from Chapter 5 of the book and I was too lazy to convert the Postscript images into a web format, so I removed the description of how to refine connectors and show how they are implemented. Here’s the text that describes it:

In this example the translation between the sensor domain and the alarm domain was rather simple, but in other cases it will be complex. Is it ok for a connector to be large and complex? Yes. We have already seen how a component can be refined to show its internal design, and the same refinement process can be used for connectors. In fact, connectors can be themselves implemented using components, as seen in Figure [fig:Connector-refinement]. An enterprise service bus guarantees properties like durability and in-order delivery, and that communication infrastructure is complex so it is implemented using many distributed components and data stores.

The example diagram shows what you are talking about — components that create and interpret deltas. There’s no right way or wrong way to build software in any objective sense, but we do build up conventional wisdom about best practice. Right now, best practice says it is normal to nest boxes in boxes and recursively assign responsibilities. By applying this to connectors we get similar benefits. The drawbacks are similar too: You cannot see what’s inside and doing the work. David Garlan, by the way, has increasingly been drawing his connectors not just as simple lines but as other shapes to help emphasize that they’re not just simple data movers. You can see this in the Acme Studio screenshots.