Procurando um Modelo Computacional para a Orientação a Serviço
Nesta terça estava participando junto ao grupo de interesse sobre aplicações compostas liderado pelo Waldemir Cambiucci quando duas figuras de seu ppt (que parecem ser de uma palestra do Atanu) me reforçaram as seguintes visões:
1) A SOA só irá cumprir sua verdadeira missão de prover agilidade à área de TI e à área de negócios quando ela der maior poder aos usuários de negócio e final para que eles criem suas aplicações. A missão é tornar a TI um habilitador (pensar em capacidades) de serviços para que o usuário final faça seus mashups, seus relatórios, seu workflow de negócios, etc. – Enterprise 2.0, dizem alguns;
2) Ainda não existe uma boa definição do modelo computacional para Orientação a Serviços assim como aconteceu com a Orientação a Objetos. A OO define objetos (objetos já incluem o conceito de classe e encapsulamento) que trocam mensagens entre si. Mas qual é a definição para a Orientação a Serviços?
Quanto a este último, uma proposta: federação de executáveis autônomos e gerenciáveis, conectados através de interfaces em redes com velocidade e latência variável.
Federação, executáveis (que trata da questão granularidade), autonomia, gerenciamento, interfaces, velocidade e latência. Como num circo chinês, temos que manter todos estes pratos girando ao mesmo tempo ao definir a arquitetura de nossas soluções.
Alguma melhoria a fazer nesta definição?
Comments
- Anonymous
October 24, 2007
Olá Otávio, tudo certo? Realmente, podemos dizer que ainda não existe uma boa definição sobre o modelo de Orientação a Serviços. Quando discutimos as forças que atuam sobre o Enterprise, vimos várias threads como:
- middleware (onde tivemos MQ, EAI, B2B, BPM, etc.);
- modelo de aplicação (onde tivevmos mainframe, client/server, web apps, etc.);
- computação distribuída (onde citamos DCE, MTS, COM+, Enterprise Services, etc.); e finalmente
- o modelo computacional, onde destacamos a programação estruturada, a orientação a objetos e uma emergente orientação a serviços. Para ampliar a discussão, veja esses 2 artigos do Journal: Modelagem Orientada a Serviços para Sistemas Conectados - Parte 1 http://www.microsoft.com/brasil/msdn/arquitetura/Journal/SistemasConectados_p1.mspx Modelagem Orientada a Serviços para Sistemas Conectados - Parte 2 http://www.microsoft.com/brasil/msdn/arquitetura/Journal/Sist_Conect_p2.mspx Seus comentários seriam valiosos... :) Por enquanto é só! Waldemir.
- Anonymous
January 21, 2008
Waldemir, Seu comentário estava como spam (???). Daí o atraso em liberá-lo. O artigo define SOA através de princípios: "os limites são explícitos; os serviços são autônomos; os serviços compartilham esquema e contrato, não classes; e a compatibilidade de serviços é determinada com base em política". Ele fala pouco de gerência do ambiente e não explicita a questão da latência variável (talvez porque a autonomia de serviços já implique nisto). Você tem razão: a diferença é pequena. O que ainda não me convencí é se estes princípios são suficientes para daí tiramos boas heurísticas de design de serviços, como aconteceu com a OO. O que vocês acham?