Funcionalidade sempre demanda complexidade?A evolução dos sistemas corporativos, e suas necessidades de integração, levaram ao desenvolvimento do SOA, ou Arquitetura Orientada a Serviços, em português.
Simplificando, peguemos os objetos criados em nossas soluções e os coloquemos nas redes. Eles atenderão as requisições através de seus métodos, ou metaforicamente, serviços.
Sistemas corporativos passam a figurar como uma coleção imensa de serviços disponíveis integrados e integrantes. Uma boa representante construtivista das necessidades operacionais de uma corporação.
Desenvolver soluções com essa arquitetura demanda planejamento, mais do que nunca. O arcabouço para contemplar todo o problema, principalmente nas densas estruturas corporativas, se torna mais complexo. A sopa de letrinhas é engrossada: WSDL, Webservices, UDDI...
Muitos desenvolvedores passaram a considerar toda a estrutura excessivamente complexa e corporativa demais. Em muitos casos, estaríamos matando mosca com bala de canhão. Em soluções menores, em ambientes mais simples, o custo de implementação da arquitetura a torna inviável.
Um solução tem sido apontada como boa opção para grande parte dos casos: a REST. A REpresentational State Transfer é uma proposta mais simples, mas mais crua também. Ela remonta os idos de 94, no início da Internet comercial, batizada à época como HTTP Object Model.
Roy Fielding, um dos principais autores da especificação do HTTP, em sua definição inicial, o REST representa um modelo de como a Web deve funcionar. Esses conceitos estendidos a sistemas distribuídos pretendem modelar uma boa alternativa aos padrões mais difundidos atualmente.
Entre prós e contras, cada proposta tem sua utilidade. Só não adianta tentar simplificar o SOA, nem começar a complicar o REST. Aliás, devemos atentar com a tentadora ilusão do segundo acrônimo. Alguém acredita existir descanso no mutante mundo da computação?
Nenhum comentário:
Postar um comentário