Resumo

  • A RFC 5381 contrasta o desenvolvimento top-down, guiado por WSDL, com o bottom-up, em que uma implementação gera sua descrição e pode carregar decisões específicas de fornecedor.
  • Mesmo uma dupla top-down gerada do mesmo contrato adotou cookie para manter sessão e, segundo o próprio RFC, deixou de interoperar com implementações conformes à RFC 4743.

O calendário escolhe uma arquitetura

No desenvolvimento bottom-up, a equipe escreve o serviço em Java e deixa a ferramenta produzir o WSDL. O resultado aparece cedo: métodos já existem, o contêiner sobe, a descrição pode ser entregue aos consumidores. A RFC 5381 reconhece a vantagem de velocidade e facilidade.

No top-down, o contrato vem primeiro. A partir do WSDL, a ferramenta gera skeleton no servidor e stub no cliente. O processo obriga fornecedores a mirar a mesma descrição e, por isso, favorece interoperabilidade.

Essa comparação não é uma disputa abstrata de metodologia. Ela mostra onde a organização permite que decisões locais se tornem públicas. No bottom-up, nomes, tipos, exceções e estruturas do código de um fornecedor podem virar a interface de todos. No top-down, essas escolhas são discutidas no contrato antes de existir um serviço. A primeira rota antecipa a entrega; a segunda antecipa a governança.

Mas a RFC 5381 também impede uma conclusão cômoda: top-down não garante conformidade por si só.

Um contrato comum ainda pode abrigar uma regra privada

O caso concreto usava Apache Axis para gerar classes Java. O cliente recebia objetos como NetconfBindingStub, Hello, GetConfigType e EditConfigType. O servidor recebia skeletons que precisavam ser completados com funções NETCONF. Ambos os lados partiam da mesma família de WSDL e schemas.

Mesmo assim, o tratamento de sessão divergiu da RFC 4743. A norma vinculava o estado NETCONF à conexão persistente. A implementação descrita na RFC 5381 colocou o identificador de sessão também em um cookie HTTP. O equipamento o criava depois de hello; o NMS o repetia em pedidos posteriores; o fechamento eliminava o valor.

Essa regra funcionava para os dois produtos que a conheciam. O texto, porém, afirma que a binding alternativa não interoperava com uma implementação conforme à RFC 4743. Um contrato compartilhado no nível das mensagens não havia impedido uma decisão privada no nível do estado.

O episódio revela a dívida mais difícil de inventariar: semântica que não aparece na assinatura do método. O WSDL pode dizer quais mensagens existem e onde enviá-las. Ele não garante que duas implementações atribuam a mesma autoridade à conexão, ao cookie e ao elemento XML.

Código gerado não é serviço acabado

O WSDL principal citado no RFC não continha sozinho o elemento de serviço. Outro arquivo precisava declarar o endpoint e importar a definição. Os modelos de dados de cada função do equipamento tinham de ser descritos em XML Schema. O skeleton gerado continuava sendo um molde; funções reais precisavam ser acrescentadas.

É possível, portanto, cumprir uma série de marcos e ainda não possuir um serviço de gestão completo. O gerador termina. O compilador termina. O Ant copia classes. O Tomcat torna o endpoint acessível. O módulo SOAP recebe uma mensagem. Só então o provedor NETCONF interpreta a operação e tenta configurar o equipamento.

Quando a gestão trata todos esses eventos como “deploy”, cria uma ilusão de progresso linear. Na verdade, cada etapa muda o tipo de evidência. Acessibilidade não é semântica. Semântica não é autorização. Autorização não é commit. Commit não é realização no hardware. Realização não é resultado para o serviço.

A conveniência tem superfície de saída

Ferramentas de geração criam dependências além do código. Versão do Axis, bibliotecas JAX-RPC e SAAJ, opções de geração, particularidades do WSDL, modificações manuais e comportamento do contêiner passam a formar um ecossistema. A API parece estável porque a ferramenta esconde esses elementos do desenvolvedor de aplicação.

Na migração, eles reaparecem. Um gerador novo pode interpretar tipos de forma diferente. Um runtime pode tratar cookies ou conexões de outro modo. Uma implementação independente pode rejeitar a binding privada. Sem as entradas exatas e sem testes externos, a organização não sabe se está migrando um contrato ou reproduzindo uma coincidência.

Essa é a relação com lock-in: não basta possuir o código-fonte. É preciso possuir a prova de como a interface foi produzida e quais convenções fora do contrato mantinham os dois lados alinhados.

Segurança não resolve portabilidade

A RFC 5381 exige TLS para autenticação e criptografia no transporte SOAP. É uma base indispensável. Ainda assim, o canal protegido não escolhe entre conexão e cookie como dono da sessão. Também não concede automaticamente poder para alterar a configuração.

Uma credencial válida identifica um par. A política NETCONF deve decidir o que ele pode fazer. O datastore registra uma mudança. O equipamento a realiza. Uma observação independente confirma o efeito. Quando os recibos são separados, uma falha pode ser atribuída. Quando são fundidos, qualquer resposta HTTPS vira um falso êxito.

A nota do IESG também dizia que suporte apenas a SOAP, sem pelo menos SSH, não satisfazia o requisito NETCONF vigente. Uma integração segura e útil podia continuar incompleta perante o perfil maior.

O fim público não liquida a dívida privada

RFC 6241 e RFC 6242 atualizaram NETCONF e seu transporte SSH. Mais tarde, RFC 9900 tornou históricos os transportes SOAP e BEEP e liberou suas portas. Isso alterou o contrato público e o registro.

Não removeu automaticamente WSDLs, stubs, skeletons, cookies, appliances ou regras internas. O artigo BTW sobre RFC 9900 já pertence ao problema de retirada local após liberação de porta. Aqui, a questão é a portabilidade da implementação que restou. Se apenas o par original consegue conversar, a dívida de interface continua existindo mesmo sem tráfego público.

Heng Lu insiste em separar a declaração do código em execução. Para RFC 5381, é preciso acrescentar o gerador e a convenção de estado à separação. O documento descreve. A ferramenta transforma. O código correlaciona. A autoridade decide. O equipamento realiza.

Fontes