Fragmental

7/05/2005

O SOA Nosso de Cada Dia

Você ouve, ouve, ouve... mas cadê o SOA de verdade?

Assim como os componentes que nos prometeram que iam abundar as prateleiras, o tal do SOA parece não sair do papel, primeiro dos PDFs de teses acadêmicas, agora do papel brilhante e caro das revistas "top de linha".

Mas, assim como a componentização, só parece que não está acontecendo. Olhe em volta.

O problema dos componentes e todo o hype formado ao redor deles foi que os componentes tomaram outra forma. Componentes de lógica de negócio são raros, mas qualquer outra coisa pode ser comprada ou obtida de terceiros (ninguém que eu tenha lido falava em como o software livre iria influenciar o mercado de componentes), de geradores de relatórios até clientes HTTP, raramente se precisa escrever algum componente de baixo nível hoje em dia, basta procurar um pronto.

E o SOA? Você já reparou que estamos vivendo na onda das APIs?


E muitas outras, estãos são apenas as dos sites que eu uso constantemente.

Perceba um padrão: são sites. Eles têm uma interface (no caso do flickr uma interface digna de respeito), e teoricamente seu serviço deveria incluir o uso desta. Uhm...deveria?

O que estes sites "vendem" não é a interface. O que o Google Search oferece não é uma caixinha de texto, é uma pesquisa na internet! O maps fotos por satélite e mapas interativos, o flickr organização de fotos por tags... etc.

Isso já atinge o desenvolvedor diretamente em como é importante separar interface de negócio. Interfaces mudam e a tendência hoje é ter algo como o del.icio.us, uma interface web bem fraquinha, mas uma senhora API que pode ser extendida em por browsers, aplicativos desktop e outros sites.

Esqueça a era do VB (ou Delphi se você, como acredito que sim, mora no Brasil ou Rússia). Com o advento dos computadores baratos com monitores coloridos, interface amigável virou lei, a lógica era o de menos (ok, geralmente é o bom e velho "coloca-no-banco-lista-tira-do-banco"). Hojeelinhas bonitinhas são facilmente construídas em segundos com editores gráficos, a lógica de negócios e a integração destas é o que importa.

Essas APIs são baseadas em protocolos leves sobre HTTP, que apesar de bem problemático para aplicações de verdade continua sendo padrão na Internet. Por enquanto, são serviços únicos mas logo em breve você poderá solicitar uma pesquisa assim:

  1. Envia ao Yahoo! e Google um pedido de numero de resutlados para pesquisar "frango da malasia"
  2. Yahoo! informa que achou 482 resultados, Google 379.
  3. Você cancela a pesquisa no Google e pede os resultados do Yahoo!
  4. O Yahoo! debita o referente a consulta (seja dinheiro, seja númerod e consultas/dia) e retorna os resultados num formato XML

Sua aplicação final (o que 99% dos programadores vai fazer nas empresas) vai ser uma telinha chamando serviços disponíveis na rede da empresa e emr edes externas. Hoje você já pode fazer isso.

Bom, eu sou técnico, mas vamos tentar dar uns palpites no ramo dos negócios.

Todos os citados acima são serviços gratuitos ou possuem versões gratuitas. Imaginar um modelo de negócios viável para serviços não é difícil, se baseie em coisas do mundo real. Quando você compra um ticket do metrô, você não compra nada além do serviço de transporte.

Venda tickets para sua aplicação.


 
f