Tecnologia Baseada em Especificações

Durante os treinamentos, palestras ou apresentações que venho ministrando, sempre procuro enfatizar uma das grandes vantagens de se usar a tecnologia Java, que são as especificações. Entretanto percebo que existe uma certa dificuldade em geral em entender isso, uma vez que especificações são sobre conceitos de engenharia de software, soando um tanto “estranho” à primeira vista. Para que o pessoal entenda isso, eu sempre acabo usando comparações com especificações do mundo real sobre outros assuntos… então vamos nessa:

Você se lembra qual foi a última vez que você comprou ou ganhou um CD de música de seu cantor ou banda preferida? Você teve que perguntar se este determinado CD da Banda X funcionava no seu som da marca Y? É claro que não! Sabe por quê? POR CAUSA DA ESPECIFICAÇÃO! Existe uma especificação que determina as regras de “como” um CD de música deve ser construído e de “como” os aparelhos devem fazer para tocá-los. Não sei se já parou para pensar no caos que seria se isso não fosse uma realidade? Tente imaginar um pouquinho… você poderia gostar de vários cantores ou bandas diferentes e cada qual gravaria seu CD em um formato/esquema/tecnologia diferente! Em resultado, seu aparelho de som não teria a capacidade de tocá-los! O que você acharia se isso fosse uma realidade? Seria justo os cantores forçarem os clientes a comprarem um aparelho de som compatível somente para escutar seu CD em formato proprietário? Realmente não seria justo para ninguém… nem para os cantores, nem para os clientes e principalmente para o produtores de aparelhos. A justa separação seria: o cantor tem que ganhar dinheiro em cima da musica que ele criou, a empresa que produz o aparelho tem que ganhar em cima do aparelho que ela produziu e o cliente, sendo principal articulador da historia, tem a liberdade em comprar qualquer aparelho que lhe atraia e a liberdade de comprar quantos CDs de qualquer que seja o cantor/banda. Não podemos deixam de fora a competitividade que isso geraria tantos nos cantores para produzir melhores músicas e principalmente nas empresas produtoras de aparelhos, cada um oferecendo os mais diferenciados recursos que justificariam seus preços.

A péssima noticia é que este caos existe no mundo tecnológico!

As empresas quando adotam um determinada tecnologia para a construção de um produto de software, acabam ficando amarradas com ela para sempre e ainda amarradas com a plataforma de execução (SO). Os investimentos pesados acontecem para “aprender” a determinada tecnologia, o “tempo” gasto no desenvolvimento e o “próprio produto em si”. A casa cai quando as empresas tentam mudar de fornecedor de tecnologia por algum motivo, ou seja, o conhecimento adquirido na tecnologia proprietária não é o correspondente na outra, o produto desenvolvido em si não funciona sobre a outra e todo o tempo (que também é dinheiro) investimento vai por agua abaixa! Resumindo a história: joga tudo fora e repete-se o ciclo em uma outra tecnologia proprietária mais atual ou adequada para o caso.

A Sun Microsystem, visualizando este caos, se levantou contra tudo isso estabelecendo Java e suas tecnologias baseadas em especificações, onde o órgão responsável por gerenciar é chamado de Java Comunity Process – (JCP) responsável pela elaboração, versionamento e aprovação das especificações. E atualmente não existe dúvidas que a idéia obteve sucesso, uma vez que todas as empresas mundiais então participando ativamente do processo.

Um exemplo simples disso seria o framework de conexão com banco de dados relacionais chamado JDBC. A especificação define todas as regras de como uma aplicação Java pode se conectar e trocar informações via SQL como o mesmo. Qualquer empresa produtora de banco de dados interessada tem que ser ater às regras da especificação, se quiser que o seu produto seja usado com o Java. Qualquer aplicação Java que tenha que conectar com um banco de dados relacional, tem que se enquadrar as regras da especificação. As conseqüências são as mesmas em ambos os lados:

1. Desenvolvedor aprende somente uma vez a especificação que a implementação é igual para todos.

2. A empresa vendedora do software em Java não fica amarrada com banco de dados específico.

3. A empresa produtora de banco de dados vai ganhar em cima de seu SGDB, independente de qual sistema ou tecnologia esta sendo usado.

4. O cliente que vai comprar a solução tem a liberdade de usar o produto em Java em qualquer plataforma e ainda com qualquer banco de dados.

5. Gera uma competitividade entre as empresas vendedores de sistema em Java e as empresas vendedoras de banco de dados relacionais, ninguém amarrado em ninguém, cada um gerando faturamento em cima do seu produto.

Vale ressaltar que as especificações de tecnologia de software não se enquadram 100% nas mesmas condições que o caso citado de CD de músicas, podendo possuir algumas variações específicas ocasionadas pelo próprio tipo de produto especificado (por exemplo especificações de produtos como servidores de aplicações, componentes de integração, componentes distribuídos, componentes ORM, protocolos de comunicação etc….) lembrando que a cada dia podem surgir novas especificações de novos produtos.

Outro detalhe importante é que alguns produtos contêm especificações que podem oferecer aberturas válidas para algumas características proprietárias, aumentado ainda mais a concorrência entra as empresas ofertantes, lembrando que este fato limita a portabilidade na medida que resolvemos ultrapassar a especificação, utilizando recursos extras proprietários.

E a grande pergunta fica no ar: “Mas como isso é possível? Como um desenvolvedor consegue implementar um código baseado em uma especificação, plugando diferentes implementação de fornecedores diferentes sem ocorrer quebra de código ou maiores problemas?” A resposta que faz a “ficha cair” é POLIMORFISMO! Sem este recurso, seria praticamente impossível a implementação desta filosofia.

Por hoje ficamos aqui, aquele abraço e até a próxima.