Resumo

  • Mary Shaw chamou a chamada de procedimento de linguagem de montagem da interconexão: um mecanismo de baixo nível usado para codificar relações muito mais ricas.
  • Seu vocabulário distingue componente, conector, ponto participante, papel, protocolo, configuração, estilo arquitetural, interface de módulo e propriedade do sistema.
  • Um conector de primeira classe é uma relação arquitetural especificada; não é automaticamente microsserviço, service mesh, gateway de API ou verificação formal.

Desenhe duas caixas e uma linha. Logo as caixas ganham nomes: analisador, repositório, controlador. A linha permanece vaga. Ela transporta um fluxo ou invoca uma operação? Pode reordenar, repetir, bloquear ou transmitir? Quem inicia a troca e qual garantia resiste a uma falha? O traço não responde.

Essa assimetria abre o relatório que Mary Shaw publicou no Software Engineering Institute em janeiro de 1994, Procedure Calls Are the Assembly Language of Software Interconnection: Connectors Deserve First-Class Status. A engenharia de software já descrevia bem computação e dados dentro de uma unidade. As relações entre unidades continuavam espalhadas pelo código, implícitas em convenções ou reduzidas a setas anônimas.

A metáfora da linguagem de montagem não rejeita a chamada de procedimento. Ela marca uma diferença de nível. Pipeline, eventos, conversa cliente-servidor e acesso a uma representação compartilhada impõem obrigações distintas. Reduzir tudo a “A chama B” apaga informação sobre ordem, entrega, sincronização, vinculação e comportamento global.

O que a linha não explica

Uma interface de módulo enumera procedimentos, tipos ou variáveis expostos. Ela descreve uma unidade de código, mas não necessariamente o protocolo completo de uma interação, a responsabilidade de cada parte ou a propriedade esperada do conjunto.

Um filtro, por exemplo, pode consumir e produzir um fluxo sob determinada disciplina. Empacotá-lo como procedimento não elimina a necessidade de definir buffer, escalonamento, contrapressão e fim do fluxo. Se essas obrigações vivem apenas no código de ligação, o contrato mais importante da arquitetura não tem nome.

Eventos, repositórios compartilhados e protocolos de rede apresentam o mesmo problema. O mecanismo realiza a conexão; não esgota seu significado. Tornar o conector de primeira classe é permitir que a relação seja nomeada, especificada, instanciada e examinada diretamente.

Um vocabulário para separar níveis

O componente é o lugar da computação e do estado. Seus pontos visíveis de participação são os players: procedimentos, portas ou extremidades de fluxos.

O conector é o lugar da relação entre componentes. Seu protocolo define a interação permitida e as garantias; seus papéis descrevem responsabilidades como cliente e servidor, produtor e consumidor, editor e assinante.

A configuração monta o projeto ao ligar players de componentes a papéis de conectores. É nesse vínculo que se pergunta se o participante satisfaz o papel, se protocolos são compatíveis e se a topologia sustenta o comportamento pretendido.

Um estilo arquitetural define uma família reutilizável, restringindo tipos de componentes e conectores e a forma de organizá-los. Pipe-and-filter, cliente-servidor, camadas e blackboard são estilos, não configurações individuais.

A interface de módulo diz o que uma unidade expõe. Uma propriedade do sistema — capacidade, vazão, consistência, confiabilidade ou compatibilidade — surge da montagem. Uma assinatura pode passar na checagem de tipos enquanto a conversa trava. Duas APIs válidas podem discordar sobre a segurança de repetir uma operação. O defeito pode estar no protocolo ou no vínculo entre player e papel.

Do argumento à linguagem

O relatório de Shaw fazia parte de um programa coletivo na Carnegie Mellon. David Garlan e Mary Shaw apresentaram a arquitetura de software como o nível de projeto dedicado à organização em grande escala, às interações e aos estilos recorrentes. O trabalho dos dois sobre linguagens arquiteturais de nível superior mostrou por que módulos e desenhos informais não captavam bem protocolos e alternativas.

Robert Allen e David Garlan levaram o conector à semântica formal. No artigo de 1994 para a ICSE, o conector é uma coleção de protocolos organizada por papéis, e a compatibilidade pode ser analisada de forma análoga à checagem de tipos. Essa é uma contribuição de Allen e Garlan; atribuir todo o programa a Shaw apagaria a colaboração central à pesquisa.

O UniCon tornou a proposta concreta. Mary Shaw, Robert DeLine, Daniel V. Klein, Theodore L. Ross, David M. Young e Gregory Zelesnik assinam o trabalho. Componentes e conectores são construções paralelas; configurações ligam players a papéis; fluxo de dados e escalonamento aparecem no mesmo nível de projeto das chamadas de procedimento.

Os limites eram igualmente explícitos. O UniCon oferecia tipos primitivos de conector predefinidos, não conectores arbitrários criados pelo usuário; aquela versão não suportava conectores compostos, e certas saídas genéricas reduziam o que as ferramentas conseguiam verificar. Especificar abre caminho para análise, mas não produz prova automática.

Não é sinônimo de produto moderno

Um microsserviço delimita computação, implantação e responsabilidade; ele se parece mais com um componente. Um service mesh pode implementar transporte, identidade, telemetria e repetição. Um gateway de API pode mediar entrada, roteamento e políticas. Ambos podem realizar parte de um conector, mas não definem por si só ordem de negócio, idempotência, transições de estado ou invariantes entre serviços.

O status de primeira classe também não garante verificação formal. Uma especificação precisa pode viabilizar análise, teste de contrato ou revisão rigorosa. A força da conclusão depende da semântica, da propriedade formulada e da ferramenta empregada.

O gesto duradouro de Shaw foi redistribuir atenção. As caixas não devem possuir todos os substantivos e deixar a linha como pontuação. É preciso nomear a relação, o protocolo e os papéis; declarar como os players se vinculam; identificar qual propriedade sistêmica depende da montagem. Muitos sistemas falham não porque um componente não calcula, mas porque dois componentes localmente sensatos se encontram por meio de um contrato de ordem, tempo, estado ou recuperação que nunca foi explicitado.

Fontes