Interoperabilidade e portabilidade

Dois  termos: um que está na moda (interoperabilidade) e um que já está na fase madura (portabilidade). Apesar da ordem imposta pelo título, quero falar primeiro de portabilidade, com dois de seus modelos básicos: binária e de código-fonte.

A portabilidade binária nos permite mover um executável de uma máquina para outra sem que seja necessária a recompilação do código-fonte original. A atualização de hardware mantendo a mesma arquitetura de CPU com modelos mais rápidos e eficientes é um modo fácil de conseguir a portabilidade binária. Isso serve tanto para o mundo de máquinas  com arquitetura especializada (mainframes ou dispositivos embarcados, dois extremos) quanto para o mundo em que o hardware é commodity como na computação pessoal, em que a arquitetura x86 é dominante. Mas a compatibilidade binária, apesar de teoricamente fácil quando se pensa apenas em CPU, é muito mais difícil de ser conseguida quando mudamos de uma base de sistema operacional para outra (OSX vs Windows vs Linux). Difícil não, impraticável. Por que? Porque entre esses sistemas (e mesmo entre versões do mesmo sistema) não há garantia de que a mesma API esteja disponível, dificultando este tipo de portabilidade.

Muitas empresas e/ou profissionais, por esta razão, se especializaram na portabilidade de código-fonte. Escolha uma linguagem genérica, disponível em diversas plataformas de hardware e suportada em diversos sistemas operacionais, para que você possa, apenas com a recompilação e linkedição, gerar uma versão para cada plataforma. Bacana, por um tempo. Por que? Porque a busca por uma linguagem universal de programação traz como efeito colateral a dificuldade em acompanhar a evolução dos sistemas operacionais, em representar algoritmos em linguagens mais adequadas e, mais recentemente, acompanhar a evolução dos dispositivos computacionais. Não é fácil imaginar uma aplicação COBOL sendo executada em um telefone celular (sem deméritos, mas é difícil pensar em telefone celular hoje sem pensar em telas sensíveis a toque ou altamente amigáveis a vídeos e música).

Por causa disso, um mix entre esses dois tipos de portabilidade apareceu: linguagens intermediárias. É possível mover aplicativos de um lado para outro sem se preocupar com arquiteturas de CPU e sistemas operacionais quando implantamos uma abstração desses recursos, que é justamente o que a JVM (Java Virtual Machine) e o CLR (Common Language Runtime) do .Net Framework fazem. Crie um código em uma linguagem, transforme-o em uma linguagem intermediária e execute-o em diversas arquiteturas de CPU e SO com o auxílio de uma camada de abstração. Apesar deste fundamento comum, a linha de evolução de cada uma dessas duas tecnologias segue caminhos bastante distintos: JVM, mono-linguagem em sua concepção inicial adaptando-se ao mundo multi-linguagem, e .Net Framework, multi-linguagem já em sua concepção inicial.

Pensando exclusivamente no metal sobre a qual essas aplicações executam, a existência de uma camada de abstração entre o código objeto e a arquitetura de hardware/sistema operacional impõe um certo "desperdício" de recursos computacionais que, geralmente, levam a uma performance não otimizada para a máquina que está sendo utilizada. Mesmo assim, diversas técnicas de otimização e heurística dessas máquinas virtuais permitem com que os tempos de execução não fiquem tão ruins assim. A vantagem desse tipo de solução é a possibilidade de usar o mesmo código-fonte e às vezes o mesmo código intermediário para a execução em uma estação de trabalho ou em um dispositivo móvel (desde que ambos tenham instalada a mesma camada de abstração).

É bacana quando não se pensa na interação humana. Cada dispositivo possui características próprias de interação com o usuário. Agora, imaginem a dificuldade de fazer um código único para o Surface ou para um browser.

Aqui entra em ação a primeira palavra do título: interoperabilidade. Ela representa a capacidade de sistemas poderem interagir com base num conjunto bem definido de protocolos, mensagens, APIs e formatos de arquivos.

Isolemos as camadas, as funcionalidades, os dispositivos e pensemos estruturadamente para aproveitar todas as experiências que TI já tem no design de código reaproveitável, desenho de interfaces de comunicação, protocolos e afins. Por que não aproveitar o design avançado de um dispositivo para tirar o melhor proveito dele, para atrairmos mais consumidores para o nosso negócio? Por que não podemos aproveitar o que existe de melhor em tudo o que já está em produção, consumindo toda esta lógica de outra forma, compondo novos comportamentos, criando até novas lógicas apenas conectando processos já existentes em um outro fluxo lógico?

Para quem está lendo este último parágrafo e pensando em SOA, é por aí mesmo. SOA não exige, nem exigirá, que tudo seja feito na mesma plataforma nem que seja feito na mesma linguagem. SOA é fundamentado em interoperabilidade e não em portabilidade. Definam-se as interfaces (entrada e saída), definam-se os tipos aceitáveis de dados, seus domínios de valores, definam-se as políticas de acesso aos processos lógicos, seu nível de segurança e seu SLA para que, independente da plataforma consumidora ou produtora, a comunicação entre as partes funcione de forma ótima.

Este é também um dos fundamentos do que chamamos Software+Services, solução de arquitetura que tanto o Otávio quanto o Waldemir já falaram bastante. Use o melhor de cada mundo, de cada dispositivo, para criar e reaproveitar o que há de bom, sem reinventar a roda a cada novo projeto.

Evidentemente, não é nada simples e exige uma quantidade enorme de neurônios queimados em fases de arquitetura e planejamento. É necessário garantir que protocolos, interfaces, políticas de acesso, definições de dados, etc estejam utilizando esquemas comuns (bem vindo, WSDL; bem-vindo WS-Policy, bem-vindo WS Basic Profile). Este é o fundamento do mundo interoperável.

Me diga como você fala, me diga como você se comporta, que eu não preciso saber como você funciona.

Bem-vinda, interoperabilidade.