Summary

  • Mary Shaw's 1994 report argued that procedure calls had become the assembly language of software interconnection: a low-level mechanism forced to encode much richer relations.
  • Her vocabulary separates components from connectors, component players from connector roles, connector protocols from configurations, and architectural styles from ordinary module interfaces.
  • A first-class connector is a specified architectural relation. It is not automatically a microservice, service mesh, API gateway or formal proof.

Draw two boxes and a line between them. The boxes will soon acquire names: parser, store, controller, indexer. The line is more likely to remain a line. Does it carry a stream or invoke an operation? Can it reorder messages, replay them, share mutable state, block, broadcast, drop, retry or synchronize? Who initiates the exchange, and which promise survives failure? The picture gives no answer.

Mary Shaw's January 1994 Software Engineering Institute report, Procedure Calls Are the Assembly Language of Software Interconnection: Connectors Deserve First-Class Status, begins from that asymmetry. Software engineering had developed strong ways to describe computation and data inside units. Relations among those units were still often implicit, distributed across code, or represented by anonymous arrows. When a programming language offered only a few native forms of connection, designers encoded everything else as sequences of calls and shared conventions.

The title was not an attack on procedure calls. Assembly language is valuable. The criticism was that procedure calls had become the substrate into which higher-level structures were compiled by hand. A pipeline, an event system, a client-server conversation and access to a shared representation all impose different obligations. Treating each as “A calls B” erases precisely the information needed to reason about ordering, delivery, synchronization, binding and system-wide behavior.

The line that diagrams leave unexplained

Shaw located the problem at the architecture level of design. A conventional module interface can enumerate exported procedures, types or variables. That is necessary information about one module. It does not necessarily state the protocol of a multi-step exchange, the responsibilities of every participant, or the property the assembled system is meant to deliver.

The distinction becomes clearer in a data-flow system. A filter may promise to consume and produce streams under a particular discipline. Packaging that filter as a procedure does not transform its architectural relation into an ordinary call. The caller may still need to supply buffering, scheduling and end-of-stream behavior. If those duties appear only in scattered glue code, the architecture's most consequential contract has no name.

The same problem appears with events and shared data. A broadcaster and its listeners need rules about subscription, ordering and delivery. Users of a shared repository need rules about representation, consistency and notification. A network exchange may have handshakes, framing and failure behavior. The programming mechanism realizes the connection; it does not exhaust its meaning.

That is why Shaw argued for making connectors first-class. First-class here means that a connection can be named, typed, specified, instantiated and inspected as an architectural entity rather than recovered from the implementation after the fact.

A vocabulary for the architecture level

The vocabulary matters because several nearby concepts are easy to collapse.

A component is the locus of computation and state. It performs work. The visible named points through which it participates in an architecture are its players: a procedure, a port, a stream endpoint or another externally relevant element.

A connector is the locus of relations among components. It mediates interaction rather than supplying the main computation. Its protocol specifies the permitted pattern of interaction and its guarantees. Its roles describe the responsibilities expected of participants—client and server, producer and consumer, reader and writer, publisher and subscriber.

A configuration is the assembled design. It attaches component players to connector roles. This attachment is not clerical wiring. It is where an architect can ask whether a player can satisfy the role, whether two protocols are compatible, and whether the resulting topology supports the intended behavior.

An architectural style is more general. It defines a reusable family by constraining component and connector types and how they may be arranged. Pipe-and-filter, client-server, layered and blackboard systems are not individual configurations. They are design vocabularies with characteristic rules.

A module interface remains a description of what a code unit exposes. It may contribute to a component specification, but it should not be mistaken for the entire architecture. A system-level property—capacity, throughput, consistency, reliability or compatibility—arises from the configuration and the interaction among parts. It usually cannot be read from any single module interface.

The separation prevents a common category error. An endpoint signature can type-check while the conversation deadlocks. Two services can each implement a valid API while disagreeing about retry safety. A queue can deliver bytes while violating the ordering on which a downstream state machine depends. The component interfaces may all be locally correct; the connector protocol or the player-to-role attachment can still be wrong.

From argument to language and formal semantics

Shaw's report was one strand in a broader Carnegie Mellon programme. David Garlan and Shaw's introduction to software architecture framed the field around large-scale organization, interaction and recurring styles. Their report on higher-level architecture languages argued that module mechanisms and informal diagrams did not adequately capture system organization, protocols or design alternatives.

Robert Allen and David Garlan pushed the connector idea toward formal semantics. Their 1994 ICSE paper, Formalizing Architectural Connection, treated a connector as a collection of protocols governing roles and explored compatibility in a form analogous to type checking. This was a contribution by Allen and Garlan, not a result to be silently absorbed into Shaw's individual biography. Its importance was to show that the line could have semantics strong enough to analyze.

UniCon made the vocabulary concrete. The work credited Mary Shaw, Robert DeLine, Daniel V. Klein, Theodore L. Ross, David M. Young and Gregory Zelesnik. In UniCon, components and connectors were parallel architectural constructs: components had interfaces and players; connectors had protocols and roles; configurations attached one to the other. Data flow and scheduling could appear at the same design level as procedure calls, and existing code could still be used.

The project also exposed the distance between a promising abstraction and a universal solution. UniCon provided a fixed set of primitive connector types rather than arbitrary user-defined connector implementations. Composite connectors were not supported in that version. General escape hatches reduced what tools could check, and some analyses depended on external facilities. Those limits are evidence of intellectual honesty, not failure: once the relation is explicit, the boundary of automation becomes visible too.

What first-class connectors do not mean

The idea is often made less precise by translating it directly into contemporary product categories.

A microservice is a deployment and ownership boundary around computation. It is closer to a component than to a connector, although its operation depends on many connectors. Splitting a system into more services does not automatically improve the specification of the relations among them.

A service mesh can implement transport, identity, telemetry and retry policy. An API gateway can mediate ingress, routing and policy. Either may realize part of a connector. Neither is the connector by definition. If the intended protocol includes application ordering, idempotency, state transitions or cross-service invariants, infrastructure alone may not express it.

Nor does first-class status guarantee formal verification. A precise connector specification may enable compatibility checks or an external analysis. It may also remain a disciplined, reviewable design description. The strength of the proof depends on the semantics, the properties stated and the tool that analyzes them. Naming the contract is a prerequisite for some forms of verification; it is not verification itself.

Finally, connectors are not just middleware. Shaw's examples range across language mechanisms, shared data representations, remote calls, pipelines, document exchange and network protocols. Their implementations may be libraries, tables, buffers, processes, system calls, initialization parameters or linker instructions. The architectural identity lies in the relation and its obligations, not in one technology layer.

The durable design move

Carnegie Mellon's later history of the field places this work in a programme that began in the late 1980s and turned software architecture into a systematic subject. Shaw's own research framing has remained consistent: engineering improves when recurring design knowledge is progressively codified and when the representation matches the level of the problem.

The durable move in the 1994 report is therefore an allocation of attention. Do not let the box own every noun while the line remains punctuation. Give the relation a name, a protocol and roles. State how players attach to it. Say which system-level property depends on the assembly. Then keep the model honest about what the implementation and tools can actually guarantee.

That discipline is more demanding than adding another infrastructure layer, because it identifies a party responsible for the semantics of interaction. It is also more useful. Systems rarely fail only because one component cannot compute. They fail because two locally reasonable components meet through a relation whose ordering, timing, state or recovery contract was never made explicit.

Sources