SOA não é e também não promove uma nova tecnologia. Também é equivocada sua apresentação como uma nova “metodologia”. Trata-se de um conceito ou, como colocado anteriormente, uma Estratégia de TI. A principal motivação para sua implementação é a realização do tão sonhado (e raramente concretizado) Alinhamento Estratégico de TI com o Negócio. Entende-se que tal alinhamento acontece de fato quando :
• TI agrega real valor ao plano de negócios;
• Não resiste às mudanças;
• Combate a resistência às mudanças; e
• É planejado.
Os três primeiros itens da lista são traduzidos em considerável ganho de Agilidade. SOA promete a criação de uma estrutura que reproduz fielmente, em mapeamento um-para-um, os processos e atividades de negócios. Tamanha aproximação deve gerar uma arquitetura flexível, que favorece as mudanças. Mas os ganhos possibilitados pela implementação de uma Arquitetura Orientada a Serviços não ocorrem por acaso ou de forma pontual. Uma implementação SOA é uma iniciativa de longo prazo – é a execução de um bem elaborado Plano Estratégico.
SOA é uma arquitetura de software. Uma arquitetura de software é “um conjunto de definições que descreve componentes de software e associa a funcionalidade do sistema a tais componentes. Descreve a estrutura técnica, restrições e características dos componentes e das interfaces entre eles. A arquitetura é uma ‘planta baixa’ para o sistema e um plano de alto nível para sua construção” .
Serviços em uma SOA são a representação direta de entidades, tarefas, atividades ou processos de negócio. Por representação direta entende-se a paridade em sua granularidade e o uso de um vocabulário comum, que deve ser a terminologia padrão do negócio. São características-chave de uma Arquitetura Orientada a Serviços:
• Acoplamento fraco dos serviços;
• Independência de tecnologias e protocolos;
• Uso irrestrito de padrões; e
• Incentivo à reutilização de ativos.
SOA é composta de quatro elementos principais: Frontends de Aplicações, Serviços, um Repositório de Serviços e um Mecanismo de Execução e Comunicação (Bus) para os serviços.
Os Frontends de Aplicações representam a “ponta do iceberg” de uma SOA. Eles são a interface dos serviços para os usuários finais. Portanto são de sua responsabilidade a iniciação e o controle da execução dos Serviços.
Os Serviços são componentes de software que representam um processo, entidade, atividade ou tarefa de negócio. É importante salientar que são componentes de alto nível, diferentes daqueles existentes em plataformas como o J2EE e o Microsoft .NET, que são muito granulares e mais orientados a tecnologia, não ao negócio. Existem quatro tipos de Serviços:
• Básicos: que representam os elementos básicos de um processo de negócio, como Entidades e Tarefas básicas de Negócios;
• Intermediários: são o único tipo de Serviço mais orientados a tecnologia em uma SOA. Fornecem pontes, conversores ou funcionalidades adicionais aos demais serviços;
• Processos: são os serviços que representam de forma direta um processo ou atividade de negócio, do início ao fim.
• Públicos: extensão aos serviços do tipo Processo que possibilita sua exposição para clientes (usuários) que estejam fora das fronteiras da organização.
Todo serviço, independente de seu tipo, é sempre composto por três partes principais, como ilustrado na Figura 1 acima. A primeira parte é um Contrato, um acordo que é fechado entre os consumidores de um serviço e seus provedores. Este documento explica os propósitos do serviço, contexto, regras de utilização, restrições, níveis de serviço esperados, além de apresentar uma definição formal da interface do serviço.
Interface esta que é implementada em separado, sendo o segundo elemento de construção de um serviço. Trata-se do único meio de comunicação com um serviço, seja seu cliente um frontend de uma aplicação ou outro serviço. A terceira e última parte de um Serviço é sua Implementação propriamente dita, através da realização da Lógica do Negócio e acesso e manutenção de seus Dados, de forma a atender todos os objetivos fixados no Contrato.
O Repositório armazena todos os Contratos dos Serviços disponíveis, o que o torna o ponto de partida para utilização destes. Além dos Contratos, o Repositório pode armazenar informações adicionais e mais específicas acerca dos serviços, como localização física, restrições de uso e segurança etc. Apesar de ser apresentado por alguns autores como um elemento opcional em uma SOA, o Repositório pode ser fator crítico de sucesso em grandes implementações, principalmente naquelas que envolverem a disponibilização de serviços do tipo Público.
Por fim temos o Mecanismo de Execução e Comunicação para os Serviços, ou simplesmente Bus, que interconecta todos os participantes de uma SOA, abstraindo a complexidade técnica que existe nas camadas inferiores. Um Bus pode ser constituído de várias tecnologias e/ou produtos, dependendo da infra-estrutura existente e dos requerimentos de distribuição dos serviços.
>>>>>>>>>> SOA #3 – É o Negócio, Estúpido!
2. “The Squandered Computer”, Paul Strassmann
The Information Economics Press (1997).
3. “Enterprise SOA – Service-Oriented Architecture Best Practices”, Dirk Krafzig, Karl Banke e Dirk Slama
Prentice Hall (PTR) (2005).
